Le goulot d'étranglement a changé. L'IA est en train de redéfinir le cycle de vie du développement logiciel

Si tu as lu notre précédent article sur les 8 étapes de maturité de l'ingénierie IA, tu sais où en est ton équipe. En fait, adopter l'IA, c'est la partie la plus facile ; c'est en s'adaptant à ses conséquences que la plupart des entreprises rencontrent des difficultés.

Pendant plus d’une décennie, les entreprises de logiciels se sont optimisées autour d’un seul postulat : les capacités de mise en œuvre étaient limitées. Les outils de productivité des développeurs, l’ingénierie des plateformes et l’automatisation sont tous issus de la même logique sous-jacente : l’écriture de logiciels constituait la principale contrainte de livraison, et tout le reste était conçu pour y remédier. Alors que l’IA a commencé à réduire cette contrainte, le goulot d’étranglement n’a pas disparu. Il s’est simplement déplacé, et il continue de se déplacer.

Au cours des derniers mois, Fabien Potencier, CTPO chez Upsun, et moi-même — accompagnés d’une petite équipe curieuse — on s’est lancés dans des discussions avec des responsables Produit et Ingénierie pour comprendre comment l’IA est en train de transformer leurs organisations. On a parlé à plein de gens, posé plein de questions, et on en a tiré plein de matière à réflexion. Cet article de blog, c’est notre façon de partager ce qu’on a appris. 

Ce qu’on a découvert nous a surpris — pas tant par une révélation spectaculaire, mais par la cohérence de quelques signaux qui revenaient sans cesse, quelle que soit la taille des entreprises. 

Greg Gambatto, fondateur de Ctrl+G, l’a dit sans détour : « Notre équipe produit et ingénierie dépense désormais plus en jetons qu’en salaires. » Pas l’hébergement cloud, ni les charges sociales. Les jetons : un coût opérationnel dont personne n’avait prévu qu’il augmenterait aussi vite, et pour lequel aucun système financier n’avait été conçu pour le suivre, encore moins le gérer.

Les ingénieurs ont gagné en rapidité. L’entreprise, elle, non.

L’adoption a commencé là où la plupart des évolutions technologiques commencent : chez les contributeurs individuels. Les ingénieurs ont fait des essais, la productivité s’est améliorée, et les utilisateurs les plus avancés sont passés de l’utilisation de l’IA comme assistant à la gestion simultanée de plusieurs agents — générant du code, écrivant des tests, évaluant les risques architecturaux et déployant dans le cloud. Les gains étaient réels et visibles. Ce qui n’a pas changé, c’est tout ce qui les entourait.

Les processus de révision, les chaînes d’approbation et les contrôles de déploiement étaient toujours conçus pour un monde où les humains écrivaient chaque ligne de code. À mesure que la production augmentait, les files d’attente de révision s’allongeaient en parallèle, et les ingénieurs seniors se sont retrouvés à passer moins de temps à développer et plus de temps à valider du travail qu’ils n’avaient pas écrit. Comme l’a dit un directeur technique : « On peut générer une semaine de code en un après-midi. Mais notre processus de révision est le goulot d’étranglement. Ça prend une éternité et ça part toujours du principe que tout a été écrit par des humains. » 

La contrainte n’avait pas disparu ; elle s’était simplement déplacée de la création vers la validation, et ce changement a mis en évidence un défi que la plupart des équipes n’avaient pas anticipé, ce qui a submergé les membres les plus expérimentés de l’équipe.

Le problème de confiance que personne n’avait prévu

Les relecteurs n’évaluent plus seulement la logique et le style. Ils traquent les erreurs, les incohérences architecturales et les failles de sécurité enfouies au cœur d’implémentations par ailleurs convaincantes — des résultats qui semblent corrects à première vue, mais qui nécessitent davantage d’examen minutieux, et non l’inverse.

Certaines équipes ont réagi en automatisant la couche de relecture elle-même, à l’aide d’agents en cascade qui génèrent, critiquent et notent les résultats avant que quoi que ce soit n’atteigne un humain. Ça marche, mais ce n’est pas une simple amélioration du processus existant. C’est un tout nouveau processus, construit à partir d’hypothèses différentes, et sa mise en place demande du temps et des ressources que la plupart des équipes n’avaient pas prévues dans leur budget.

Pendant que les ingénieurs s’occupaient de ça, une pression d’un autre genre s’exerçait de l’autre côté du processus.

Le produit est devenu la nouvelle contrainte

Plusieurs organisations ont commencé à signaler un phénomène qui aurait semblé inhabituel il y a encore quelques années : l’équipe d’ingénierie était prête à livrer des fonctionnalités que l’équipe produit n’avait pas encore fini de définir.

Historiquement, la mise en œuvre a toujours été le facteur limitant. Cette relation s’est discrètement inversée. Les systèmes IA ne gèrent pas l’ambiguïté comme le font les ingénieurs expérimentés ; les développeurs humains comblent les lacunes par la discussion et leur jugement, tandis que les systèmes IA exécutent ce qui est écrit, répercutant ainsi le flou directement dans le résultat. La qualité des spécifications est devenue une préoccupation majeure pour les ingénieurs, et les organigrammes commencent à en tenir compte : les chefs de produit réalisent directement des prototypes, les designers valident des commits, et les ingénieurs passent plus de temps à définir les systèmes qu’à écrire eux-mêmes chaque ligne de code. Quand la mise en œuvre devient plus facile, c’est la clarté qui devient la ressource rare.

Le coût a rattrapé tout le monde

Pour la plupart des équipes en phase de démarrage, l’aspect financier semble gérable : abonnements, coûts prévisibles, gains de productivité qui justifient les dépenses. Mais tout change dès que l’orchestration entre en jeu. La consommation de jetons ne suit pas la même évolutivité que les effectifs, contrairement aux licences logicielles. Elle évolue en fonction de l’utilisation, de l’autonomie et de l’ambition, augmentant à chaque nouvelle tentative, à chaque exécution ratée et à chaque agent qui s’est aventuré plus loin qu’il n’aurait dû.

Certaines entreprises signalent déjà que les coûts liés à l’ingénierie de l’IA passent de quelques centaines à plusieurs milliers de dollars par ingénieur et par mois. Le directeur technique d’Uber a déclaré à The Information que l’entreprise avait déjà épuisé tout son budget IA pour 2026 dès la mi-avril. Dans le podcast All-In, le PDG de Salesforce, Marc Benioff, a indiqué que l’entreprise prévoyait de dépenser 300 millions de dollars en jetons Anthropic en 2026, presque exclusivement pour le codage. Les jetons sont discrètement devenus un poste stratégique au point de rivaliser avec la masse salariale, et la plupart des équipes financières ne s’y attendent pas.

Un nouveau cycle de développement logiciel (SDLC) voit le jour

Ce qui change, ce n’est pas l’existence des revues, de la gouvernance ou de la définition du produit — c’est leur poids relatif. Pendant des années, la vitesse de mise en œuvre était la principale contrainte, et tout le secteur s’est organisé pour y remédier. L’IA a considérablement réduit cette contrainte et, ce faisant, a mis à nu tout ce qui se cachait discrètement derrière.

Les organisations qui s’adaptent le plus vite ne sont pas celles qui ont les meilleurs modèles. Ce sont celles qui sont prêtes à repenser les hypothèses sous-jacentes à la façon dont les logiciels sont développés : leurs processus, la structure de leurs équipes, leur modèle économique, et à prendre cette remise en question aussi au sérieux que n’importe quelle décision technique.

Le goulot d’étranglement n’a pas disparu. Il s’est déplacé vers les processus de validation, les spécifications produit et les budgets symboliques que personne n’avait prévus. Les équipes qui prennent de l’avance ne se distinguent pas par les outils qu’elles utilisent. Elles se distinguent par la rapidité avec laquelle elles ont remarqué où la contrainte s’était déplacée.