Le recours à des agents de code exige de mettre l'accent sur la qualité

Selon un récent sondage JetBrains (AI Coding Agents: Adoption Trends - The JetBrains Blog (nouvel onglet)), 90% des développeurs professionnels utilisent des agents de code au travail au moins une fois par semaine, et 68% d'entre eux quotidiennement.

Les habitués le savent. Les agents de code transforment la manière d'aborder le développement logiciel. Il y a du bon et du mauvais, comme toujours.

Je suis un enthousiaste de l'IA, mais il est vrai que certains aspects ne doivent pas être sous-estimés.

Ce qui est indéniable, c'est que du code se crée plus vite qu'auparavant. Et surtout, plus fréquemment. Et ce code doit être vérifié. Seulement voilà, la vitesse de production du code dépasse largement les capacités de relecture humaine. La revue est devenue un goulot d'étranglement majeur. Selon le rapport Global AI Diffusion Q1 2026 (nouvel onglet) de Microsoft, les "git pushes" ont augmenté de 78% sur un an à l'échelle mondiale. Et les pull requests associées à des agents de code ont été multipliées par 28 en dix mois.

Ces risques sur la qualité ne sont pas hypothétiques. Depuis 2023, la duplication de blocs de code a progressé de 81%, pendant que la part de code refactoré tombait de 21% à 3,8% des lignes modifiées (GitClear (nouvel onglet)). On duplique au lieu de réutiliser.

En plus des risques que cela fait peser sur la qualité, il y a également un impact sur le moral des développeurs. Le temps passé à valider le code généré par l'IA peut engendrer de la frustration et un sentiment de dévalorisation. 66% des développeurs sont frustrés par des solutions IA "presque justes, mais pas tout à fait" et 45% estiment que le débogage du code généré prend plus de temps que prévu (Stack Overflow, Developer Survey 2025 (nouvel onglet)).

Certains misent sur une automatisation des revues pour tenter de diminuer la charge. L'adoption d'outils IA pour la revue de code s'installe. CodeRabbit revendique plus de 2 millions de dépôts connectés et 13 millions de pull requests analysées (CodeRabbit (nouvel onglet)).

Les projets Brownfield sont davantage impactés que les projets Greenfield car le contexte est difficile, complexe, éparpillé et nécessite davantage d'expertise. Selon Dex Horthy (HumanLayer), les agents IA excellent sur les projets Greenfield (prototypes, code propre), mais rencontrent des limites majeures en Brownfield (code legacy, complexité). Le défi n'est pas la qualité du modèle mais la gestion du contexte : sans une bonne méthodologie, les agents produisent du "slop" (code de mauvaise qualité) et découragent les ingénieurs seniors (AI Engineer, 2026 (nouvel onglet)).

Restent les gains de productivité. On peine encore à les mesurer. Au point que le laboratoire METR, dont c'est le métier, a dû revoir son protocole. Son essai de 2025 mesurait 19% de temps en plus là où les développeurs croyaient en avoir gagné 20% (METR, juillet 2025 (nouvel onglet)). Le second bute sur l'adoption elle-même : trop de participants refusent désormais de travailler sans IA. Les résultats bruts penchent cette fois vers une accélération, mais METR les juge trop biaisés pour conclure (METR, février 2026 (nouvel onglet)).

Cet écart a un coût. Uber a épuisé son budget IA 2026 en 4 mois, sans parvenir à relier cette consommation aux fonctionnalités réellement livrées (Developpez.com (nouvel onglet)).

Ces défis illustrent un changement de paradigme. La valeur se déplace de l'écriture du code vers sa conception et sa vérification. "Ne corrigez plus le code, corrigez le système qui l'écrit et le vérifie" : l'usine logicielle devient l'élément critique.

Patrick Debois, à l'origine du mouvement DevOps, rappelle qu'un agent ne passe pas à l'échelle tout seul, et une équipe non plus : cela se construit à l'échelle de l'organisation, pas seulement du poste de travail (Coding Agents Don't Scale Themselves. Neither Do Your Teams. (nouvel onglet)). Et même bien outillé, ce système ne se passera pas de nous, pour l'instant. Dex Horthy prévient que le harness ne sera pas suffisant, tant que les modèles sont récompensés sur des tests qui passent et non sur la qualité de conception (Why Software Factories Fail (nouvel onglet)). Reste que c'est en construisant ce système et en l'éprouvant qu'on saura ce qu'on peut lui confier.

---

Ce que cela implique pour les organisations et développeurs

• Prioriser la qualité : Définir ce qui est "bon". Intégrer la qualité dès le départ. S'appuyer sur des outils de test et d'analyse partout où c'est possible.
• Investir dans le contexte : Sans une bonne méthodologie les agents produisent du code coûteux à maintenir, surtout sur les projets Brownfield.
• Mesurer les coûts réels : Les gains de productivité perçus sont souvent contrebalancés par des coûts cachés. Il est crucial de trouver les bons indicateurs, la vitesse ne doit pas compromettre la qualité.
• Former les équipes : Spécification, architecture et vérification deviennent les compétences clés. Distribuer des outils ne suffit pas, il faut reprendre les processus en impliquant ceux qui les vivent.
• Construire la confiance : Comme le relaie Kent Beck, "We're accumulating code faster than we are accumulating trust" (Trust Factory (nouvel onglet)). La confiance ne se construit pas par la vitesse, mais par la discipline, l'environnement et la compréhension partagée, des éléments qui prennent du temps.