Ce que 100 000 développeurs viennent de révéler sur le code IA
Donnez GitHub Copilot et Cursor à une équipe, et le graphe de commits s'illumine presque du jour au lendemain. C'est la partie que tout le monde met en capture d'écran pour la all-hands. Celle que personne ne met sur un slide, c'est ce qui arrive deux mois plus tard : la file de revue a triplé et le calendrier de release ressemble étrangement à celui d'avant.
Une vaste étude du MIT, qui a suivi plus de 100 000 développeurs, a posé des chiffres sur cette intuition. Les agents de code IA ont fait grimper le volume de code écrit d'environ 180 %. Le code qui a réellement atteint la production, lui, a progressé d'environ 30 %. Autrement dit, l'écriture est devenue six fois plus rapide que la livraison, et l'essentiel de cette nouvelle production n'a jamais vu un seul utilisateur.
Ces 150 % manquants ne se sont pas volatilisés. Ils dorment dans des branches à moitié fusionnées, dans des pull requests que trois relecteurs ont ouvertes puis refermées sans un mot, dans les reprises qui ont effacé le gain avant même qu'on pense à le mesurer.
Écrire n'a jamais été l'étape lente
Voilà ce que le chiffre de 180 % oublie commodément : taper n'a presque jamais été ce qui nous ralentissait. Les étapes lentes, c'était comprendre le problème, se mettre d'accord sur l'approche, relire le changement et lui faire suffisamment confiance pour le poser devant des clients. Tout cela coûtait cher bien avant qu'un modèle sache compléter une fonction.
Les assistants IA excellent justement sur la seule étape qui était déjà bon marché. Un développeur lâche un changement de 600 lignes avant le déjeuner, et deux ingénieurs seniors passent ensuite deux jours à reconstituer pourquoi il existe, à sonder les cas limites que le modèle n'a jamais envisagés, et à se demander si la moitié a vraiment sa place dans la base de code.
Rendez l'écriture gratuite et vous n'avez pas supprimé le goulot. Vous l'avez poussé en aval, sur les gens qui doivent vérifier la sortie.
C'est le même piège que derrière le nouveau visage de la dette technique : du code qui paraît fini en surface mais qui traîne un coût de compréhension que personne n'a chiffré.
La vraie contrainte, c'est comprendre, pas produire
Dans une équipe assistée par IA, la ressource rare est la compréhension. Un relecteur lit et comprend vraiment du code bien plus lentement qu'un agent n'en crache, et cet écart n'est pas un problème d'outillage qu'on règle à coups de licences.
Cette asymétrie construit un backlog de travail non vérifié. Tout le monde se sent productif parce que les commits défilent dans Slack, mais la part des changements qui atteignent de vrais utilisateurs bouge à peine. Le vibe coding ne sauvera pas votre produit quand la contrainte qui bloque, c'est le jugement et non la génération.
Le programme de recherche DORA de Google(lien externe, nouvel onglet) défend une version de cet argument depuis dix ans : la livraison d'élite vient du flux et de la stabilité, pas de l'activité brute. L'IA change ce qu'on met dans le pipeline, pas sa physique. Le débit reste gouverné par l'étape vérifiée la plus lente.
Faites le calcul, il devient gênant. Disons que trois relecteurs absorbent vraiment 200 lignes par jour chacun. Ça fait 600 lignes relues, point final, que les agents leur en aient livré 600 ou 6 000. Le surplus n'accélère rien. Il forme une file qui vieillit, entre en collision avec d'autres changements, et finit jetée puis réécrite. Votre courbe de vélocité part à la verticale pendant que ce que les clients peuvent réellement toucher reste plat.
Ce qui fait vraiment bouger le taux de livraison
Les équipes que j'ai vues refermer l'écart écriture-livraison ont changé leur façon de travailler, pas seulement leurs achats. Trois habitudes font le gros du boulot.
Elles gardent des changements petits, parce qu'un diff IA de 150 lignes, un humain peut le tenir en tête, alors qu'un diff de 800 lignes est une supposition déguisée en revue. Elles font expliquer le raisonnement de l'agent dans la description de la pull request, pour que la revue de code(lien externe, nouvel onglet) parte de l'intention annoncée plutôt que de la rétro-ingénierie. Et elles investissent dans les tests et l'observabilité, pour qu'une partie de la vérification se fasse toute seule au lieu de retomber entièrement sur des humains fatigués à 17h.
Rien de tout ça ne consiste à générer plus de code. Il s'agit de rendre le code généré digne de confiance plus vite, et c'est là que se trouve le vrai levier. C'est aussi une bonne raison pour laquelle le sprint de deux semaines se termine doucement : une fois que la cadence cesse de suivre la vitesse de frappe, l'ancien rythme se met à sonner arbitraire.
Mesurez ce qui est livré, pas ce qui est tapé
La mauvaise métrique fera passer l'IA pour une victoire nette pendant que le business ne voit rien changer. Lignes écrites, prompts envoyés, suggestions acceptées : tout cela flatte l'outil et ne prouve rien sur l'impact.
Les métriques qui méritent confiance vivent en aval. Le délai de livraison, le taux d'échec des changements, le ratio de reprise, et le pourcentage de code généré qui survit à la revue et atteint la production. Si ces chiffres ne bougent pas, les 180 % sont du théâtre bien éclairé. C'est exactement la ligne où les agents IA passent des démos aux vrais workflows ou se font démasquer comme des tours de magie coûteux.
Le takeaway
Choisissez un chiffre cette semaine et surveillez-le : la part des changements générés par IA qui ont réellement été livrés. Si votre volume de code grimpe de 180 % et que ce chiffre n'a pas bougé, ce n'est pas un gain de productivité que vous regardez. C'est une crise de revue que personne n'a encore nommée.
