AI Insights

Donner à l’IA quelque chose qui mérite d’être amplifié : trois priorités pour les responsables techniques

La plupart des organisations demandent ce que l’IA peut faire pour leurs développeurs. Une question plus complexe est : qu’est-ce que vos développeurs apportent à l’IA ?

Le rapport 2025 sur le modèle des capacités de l’IA de DORA soutient que l’IA ne nivelle pas les équipes ; elle amplifie ce qu’elle y trouve. Les organisations les plus performantes en tirent davantage parti, tandis que les faiblesses des équipes en difficulté deviennent plus visibles. 

Il semble qu’il en va de même au niveau individuel. L’analyse de GitClear de janvier 2026 portant sur 2 172 semaines de développement a révélé que les utilisateurs réguliers de l’IA produisaient environ 320 % (4,2 fois) plus de code durable que les non-utilisateurs. Ces mêmes utilisateurs ont également augmenté leur production de 25 % entre 2024 et 2025. Il s’agit d’une amélioration significative, mais qui n’explique pas à elle seule l’ensemble de l’écart. La conclusion de GitClear est que l’IA a accentué une différence de performance qui existait déjà. Les ingénieurs expérimentés et très productifs ont souvent été les premiers à adopter l’IA.   

Cela compte, car l’IA ne fonctionne pas dans le vide. Elle vient se superposer aux habitudes, systèmes et contraintes déjà présents dans votre équipe. Si les fondations sont solides, l’IA peut aider. Si elles sont fragiles, l’IA donne simplement plus d’espace aux faiblesses pour se propager. 

Certaines de ces fondations sont faciles à voir. L’infrastructure apparait sur votre bilan et les outils peuvent être inventoriés. Cet article se concentre sur trois domaines plus faciles à négliger : la révision du code, la dette technique et le jugement des développeurs. Ces problèmes ne sont pas nouveaux, mais l’IA les rend plus faciles à ignorer tout en rendant leurs conséquences plus difficiles à éviter.

Priorité n° 1 : renforcer la révision du code

L’IA permet aux développeurs d’écrire plus de code plus vite, mais cela n’est utile que si le processus de révision peut gérer le volume supplémentaire. Si le pipeline de révision est déjà sous pression, l’IA ne résout pas le problème : elle envoie simplement plus de code dans le même goulot d’étranglement. Des lots de modifications plus importants arrivent plus rapidement, la responsabilité devient plus floue et les révisions se limitent à repérer les signaux d’alerte évidents au lieu de comprendre globalement les changements.

Les données le montrent déjà. Le Rapport 2026 sur les benchmarks en en ingénierie logicielle de LinearB a constaté que les pull requests contenant du code assisté par IA attendaient environ 2,5 fois plus longtemps avant d’être révisées que celles écrites sans IA. Lorsque les agents d’IA avaient écrit le code de manière autonome, ce délai montait à 5,3 fois plus. Leur explication est simple : les développeurs hésitent à prendre en charge une tâche de révision perçue comme plus longue et plus risquée. 

Le problème ne vient donc pas seulement du volume. C’est le volume combiné à l’incertitude, injecté dans un processus qui n’a pas changé. 

C’est pourquoi la réponse réside dans les processus, pas dans les effectifs.

Prochaines actions à envisager :

• Mettre en place ou resserrer votre norme de taille de lot maximale pour les pull requests. DORA a déterminé que les petits lots formaient l’une des meilleures protections contre les pavés de code difficiles à réviser, et l’IA facilite la création de ces pavés. 

• Faire de l’analyse statique une véritable barrière, pas une suggestion. Les évaluations des réviseurs ne permettent pas à elles seules de distinguer de manière fiable les pull requests de haute qualité des autres. Une étude de 2019 portant sur 4,7 millions de problèmes de qualité du code dans 36 000 pull requests a montré que les pull requests acceptées et rejetées se ressemblaient étonnamment sur le plan des indicateurs de qualité. Une étude réalisée en janvier 2026 a confirmé ce schéma pour le code généré par IA. L’analyse statique réduit la part de subjectivité dans la décision d’accepter ou non une modification.

Priorité n° 2 : faire preuve de discipline en matière de dette technique 

L’IA peut aider à réduire la dette technique existante, à améliorer la documentation, à ajouter des tests et à effectuer un nettoyage répétitif. Mais elle peut aussi faciliter l’accumulation d’une nouvelle dette plus rapidement que la base de code ne peut l’absorber. Trois séries de données indépendantes vont dans ce même sens. 

• L’analyse longitudinale de 211 millions de lignes de code réalisée par GitClear en 2025 a révélé que le volume de modifications du code a augmenté de 84 % entre 2020 et 2024. La refactorisation a fortement chuté, passant de 25 % des lignes modifiées en 2021 à moins de 10 % en 2024. On trouve plus de 10 fois plus de blocs de code dupliqués en 2024 qu’en 2022. GitClear relie ces changements à l’essor de la programmation assistée par IA après 2022.
• L’analyse de télémétrie réalisée par Faros AI en 2025, portant sur plus de 10 000 développeurs a révélé que les équipes passant d’une faible adoption de l’IA à une forte adoption de l’IA ont constaté 9 % de bugs supplémentaires par développeur, des pull requests d’une taille supérieure de 154 % en moyenne ainsi que des délais de révision allongés de 91 %. La production individuelle a augmenté, mais pas la performance organisationnelle.
• Une étude réalisée en 2025 par Carnegie Mellon a abouti à des conclusions similaires. Les chercheurs ont suivi 806 équipes ayant adopté un outil de programmation par IA et les ont comparées à 1 380 équipes qui ne l’avaient pas fait. Les avertissements de l’analyse statique ont augmenté d’environ 30 % après l’adoption et sont restés élevés. La complexité cognitive a augmenté d’environ 41 % et est restée élevée, même après la prise en compte de la croissance de la base de code par les chercheurs. Le code n’était pas juste plus volumineux, il était aussi plus difficile à comprendre. 

Le schéma est difficile à ignorer : la production augmente plus vite que les mécanismes de contrôle de la qualité qui l’entourent.

Cela n’implique pas que les équipes ont besoin de moins d’IA. Cela signifie qu’elles ont besoin de plus de discipline dans l’allocation de leur temps.

Prochaines actions à envisager :

• Protéger explicitement la capacité de sprint pour réduire la dette technique. Si l’IA augmente la pression pour livrer rapidement, alors la refactorisation et l’analyse statique deviennent plus importantes, pas moins.

• Cartographier les risques liés aux connaissances avant que l’IA ne les aggrave. Demandez à vos développeurs quelles parties du code ils hésiteraient à modifier sans une longue phase d’apprentissage. Utilisez ces informations pour prioriser la refactorisation, la documentation et la rotation volontaire des réviseurs.

Priorité n° 3 : donner un terrain d’expérimentation au jugement des développeurs

Une meilleure révision du code et une meilleure discipline en matière de dette technique dépendent d’un élément plus fondamental : des personnes capables de réellement comprendre ce qu’elles regardent. Cette compétence n’arrive pas automatiquement, et l’IA permet d’éviter plus facilement de la travailler.

• L’essai contrôlé randomisé réalisé par Anthropic en janvier 2026 rend ce risque concret. Les chercheurs ont réparti des développeurs juniors apprenant une nouvelle bibliothèque Python en deux groupes, l’un assisté par IA, l’autre codant manuellement. Les développeurs qui avaient délégué la génération de code à l’IA avant de passer à autre chose ont obtenu un score compris entre 24 % et 39 % lors d’une évaluation ultérieure de leur compréhension. Les développeurs qui avaient utilisé l’IA tout en développant activement leur compréhension ont obtenu un score compris entre 65 % et 86 %. La conclusion d’Anthropic est sans détour : « Les gains de productivité peuvent se faire au détriment des compétences nécessaires pour valider le code écrit par l’IA ».  

• Le CTO d’Azure et vice-président de la communauté des développeurs de Microsoft a décrit ce constat comme un « changement technologique biaisé par l’ancienneté ».Les ingénieurs seniors en bénéficient, car ils ont déjà le jugement nécessaire pour orienter, vérifier et intégrer les résultats de l’IA. C’est rarement le cas des ingénieurs moins expérimentés. Pour eux, les mêmes outils peuvent devenir un frein plutôt qu’un levier.

Cela crée une logique tentante à court terme : embaucher des profils seniors, automatiser les tâches confiées aux juniors et passer à autre chose. Cela peut sembler pertinent pendant un trimestre ou deux, mais cela risque aussi de vider le pipeline dont vous aurez besoin à l’avenir. Le jugement qui rend l’IA utile doit être développé avant d’être amplifié.

Prochaines actions à envisager :

• Réexaminer votre stratégie de recrutement junior sous l’angle de la continuité métier. D’où viendront vos développeurs seniors dans quatre ans ? Une étude de Stanford Digital Economy de 2025 a révélé une baisse relative de l’emploi de 16 % parmi les personnes âgées de 22 à 25 ans dans les professions exposées à l’IA, même après la prise en comte des tendances d’embauche plus générales.

• Réduire le déficit de mentorat créé par l’IA. Le rapport 2025 sur l’impact de l’IA de LeadDev a révélé que 38 % des responsables d’ingénierie estimaient que les outils d’IA avaient réduit le mentorat direct pour les ingénieurs juniors. Ce transfert de connaissances ne se fait pas tout seul lorsque les deux parties ont un assistant d’IA sous la main. 

• Sélectionner et intégrer les candidats en fonction de leur capacité de jugement de l’IA, et non pas seulement de leur connaissance des outils d’IA. La question n’est plus de savoir si quelqu’un utilise l’IA, mais s’il sait quand ne pas le faire.

Remarque tactique : définissez l’orientation, pas les outils

La façon d’appliquer ces priorités a son importance. Les développeurs ressentiront la différence entre le leadership et le contrôle. L’enquête 2025 de Stack Overflow auprès des développeurs a révélé que « l’autonomie et la confiance » étaient les principaux facteurs de satisfaction professionnelle des développeurs.

On retrouve cette même envie d’indépendance dans le choix des outils d’IA. Le rapport 2025 sur l’état de la livraison de logiciels de Harness a révélé que 52 % des développeurs n’utilisent pas les outils d’IA fournis par leur service informatique. Ce n’est probablement pas sur ce point qu’il faut tenter d’imposer une standardisation.

N’imposez pas un choix de modèle. N’imposez pas un assistant. Vos normes doivent concerner la couche d’accès. 

Offrez à votre équipe un espace de travail compatible avec tous les outils d’IA

Les JetBrains IDEs offrent à vos développeurs un environnement cohérent pour travailler avec pratiquement n’importe quel LLM ou agent de programmation compatible avec l’ACP. Cela leur permet d’essayer de nouveaux outils sans avoir à reconstruire leur workflow à chaque évolution du marché. 

Sous cette flexibilité se cache quelque chose de plus stable : le modèle structurel de l’IDE pour votre base de code. Il n’essaie pas de deviner pas ce que le code peut signifier. Il comprend réellement le code en tant que tel. Si l’IA génère quelque chose de plausible mais qui casse quelque chose ailleurs, l’IDE peut le signaler avant que la modification arrive en révision. Ajoutez JetBrains Qodana, et ce même modèle structurel s’étend à l’analyse statique continue de l’ensemble de votre base de code.  

Le point essentiel, en pratique : standardisez seulement que ce qui doit l’être, et préservez la flexibilité pour le reste. Le All Products Pack s’inscrit dans la même logique. Il inclut tous les IDE JetBrains dans un seul abonnement, chacun étant conçu pour un langage majeur utilisé aujourd’hui ou nécessaire demain. Lorsqu’un développeur change de stack, il n’y a ni demande de licence, ni délai d’approvisionnement, ni nouveau cycle d’approbation. 

La décision est déjà prise. Les outils sont déjà là.

En savoir plus sur le All Products Pack.

Auteur de l’article original en anglais :