L'IA double le code, mais ralentit la production : un paradoxe en 2026

L'illusion des tableaux de bord en ingénierie

Lors d'une récente conversation avec un fondateur, j'ai été témoin d'une scène révélatrice. Lors d'un appel vidéo, il a partagé son tableau de bord d'ingénierie, affichant fièrement une augmentation notable du volume des commits et des pull requests. Les outils d'IA comme Copilot, Cursor et Claude étaient utilisés par tous. Cependant, lorsque j'ai posé la question cruciale sur le nombre de ces pull requests réellement mises en production ce mois-là, un silence s'est installé. Après quelques clics, il a simplement répondu par un "Huh", résumant ainsi la situation actuelle de la productivité en ingénierie en 2026.

Cette scène n'est pas isolée. Les tableaux de bord que j'ai examinés cette année racontent tous une histoire similaire. Les équipes produisent plus de code que jamais, mais peu de dirigeants vérifient si ce code est effectivement déployé. Et souvent, la réponse est décevante.

La réalité derrière les chiffres flatteurs

L'industrie technologique est confrontée à une réalité paradoxale. Selon le rapport 2026 de CircleCI sur la livraison de logiciels, basé sur plus de 28 millions de workflows CI/CD, le nombre moyen de workflows quotidiens a bondi de 59 % par rapport à l'année précédente, un record. L'IA a indéniablement modifié la donne. Cependant, le même rapport révèle que pour l'équipe médiane, le débit des branches de fonctionnalités a augmenté de 15 %, tandis que celui de la branche principale a diminué. Plus de code est intégré, mais moins est effectivement livré.

Les équipes les plus performantes, représentant 5 % du total, ont presque doublé leur production. En revanche, le quart inférieur n'a constaté aucun gain significatif. L'IA n'a donc pas bénéficié à tout le monde de manière égale, mais a plutôt accentué les différences entre les équipes bien structurées et celles qui ne le sont pas.

L'adoption des assistants IA et ses conséquences

J'ai observé ce phénomène chez une startup cliente dont l'équipe d'ingénierie a pleinement adopté les assistants de codage IA. Le rapport mensuel destiné au conseil d'administration montrait une vélocité de commits impressionnante. Pourtant, le rythme des mises en production a ralenti. Chaque pull request générée par l'IA devait encore passer par les mêmes deux réviseurs qui procédaient à la révision de code de manière traditionnelle depuis trois ans. Ces réviseurs n'ont pas accéléré leur rythme simplement parce que le code arrivait plus vite. Au contraire, chaque pull request nécessitait plus de temps pour être examinée, car une plus grande partie du code devait être vérifiée pour les erreurs typiques des outils IA.

Le goulet d'étranglement n'a pas disparu, il a simplement changé de place. Si votre équipe a adopté des outils IA et que vos chiffres de vélocité ont augmenté, mais que vous ressentez une plus grande confusion, vous n'êtes pas seul. Ce schéma se répète à travers l'industrie.

Réévaluer la productivité avec l'IA

Face à ce constat, de nombreux CTO commettent l'erreur d'investir dans un autre outil IA pour accélérer l'écriture du code, alors que ce n'est pas là que réside la contrainte. La contrainte s'est déplacée en aval, vers la révision, les tests ou d'autres obstacles qui séparent le code écrit du code expédié. Kent Beck a exprimé cette idée avec justesse, soulignant que lorsque tout le monde peut construire n'importe quoi, savoir ce qui vaut la peine d'être construit devient crucial. J'ajouterais que savoir ce qui est sûr à expédier est tout aussi essentiel, et peu d'organisations en tiennent compte dans leur budget.

Pour mesurer efficacement la productivité des développeurs avec des outils de codage IA, il faut cesser de considérer le débit comme un simple chiffre global. Il est crucial de le décomposer en fonction de l'endroit où il se produit dans le pipeline. L'activité de la branche de fonctionnalités indique la vitesse d'expérimentation de l'équipe, tandis que celle de la branche principale montre la rapidité de livraison. Ces deux éléments évoluaient autrefois de concert, mais ce n'est plus le cas depuis que l'IA a rendu l'expérimentation presque gratuite.

L'écart entre ces deux lignes est le signal le plus honnête que vous puissiez obtenir, mais il est souvent masqué par un graphique unique de "vélocité". L'enquête 2026 du Pragmatic Engineer, menée auprès de plus de 900 ingénieurs, confirme que la plupart des entreprises ne suivent pas cet écart. Un ingénieur principal a décrit comment la révision de code a évolué dans son entreprise : "J'avais l'habitude de faire des révisions de code approfondies, mais je n'ai plus la motivation de le faire pour des pull requests massives où même l'auteur original n'a pas pris cette peine." Ce n'est pas un gain de productivité, mais une dette qui s'accumule discrètement.

Le véritable déplacement du goulet d'étranglement

Il est crucial de clarifier que l'IA ne crée pas simplement du code désordonné. Les données de CircleCI et l'enquête du Pragmatic Engineer montrent que l'IA amplifie la culture d'ingénierie préexistante. Les équipes avec de bons tests, une architecture claire et une révision de code rigoureuse sont devenues plus rapides et ont maintenu la qualité. En revanche, les équipes sans ces éléments sont devenues plus rapides mais aussi plus désordonnées.

Pour les équipes déjà laxistes sur le processus, la solution n'est pas de réduire l'utilisation de l'IA, mais de corriger ce que l'IA a mis en lumière. Un indicateur clé à surveiller est le taux de réussite de la branche principale, avec un objectif sain d'environ 90 %. Actuellement, la moyenne de l'industrie est de 71 %. Cet écart, et non le nombre de commits, est le véritable indicateur de la productivité liée à l'IA pour la plupart des équipes.

Les métriques qui comptent vraiment

Les commits et le volume de pull requests sont des chiffres faciles à gonfler avec l'IA, mais ils n'apportent pas nécessairement de valeur ajoutée. Ce sont aussi les métriques qui embellissent les rapports pour les conseils d'administration, expliquant leur persistance malgré leur perte de signification. Si je devais reconstruire un tableau de bord d'ingénierie aujourd'hui, je mettrais en avant le taux de réussite de la branche principale, suivi par d'autres indicateurs pertinents pour évaluer la véritable productivité.