【Goulot d’étranglement en déplacement】Quand le code devient presque gratuit, où se situe le goulot d’étranglement du génie logiciel — L’évolution du génie logiciel à l’ère de l’IA — Apprendre l’IA pas à pas 173
Quand le code devient presque gratuit, le goulot d’étranglement se déplace vers la demande, l’intégration, la validation et l’alignement
Quand la production de code devient presque gratuite, le goulot d’étranglement de la livraison logicielle se déplace ailleurs que sur « l’écriture du code » : définir le bon problème, assembler les morceaux en un tout fonctionnel, vérifier que c’est bien juste, et aligner l’organisation. C’est la théorie des contraintes qui se rejoue dans le logiciel. L’industrie manufacturière a déjà parcouru ce chemin il y a 40 ans : chaque fois qu’une étape devient moins chère, le goulot ne disparaît pas, il se déplace simplement vers l’étape la plus coûteuse suivante. Comprendre cela permet d’expliquer une confusion répandue : les outils de programmation IA sont déployés dans toute l’entreprise, l’écriture de code est visiblement plus rapide, mais la vitesse de livraison, elle, n’a presque pas bougé.
Un DSI d’un groupe industriel m’a montré ses données des six derniers mois. Son équipe IT de plus de 80 personnes a adopté les outils de programmation IA à grande échelle. Rien qu’en termes de production de code, le nombre de commits par personne et la vitesse de fusion ont augmenté de plus de 30 %. Mais du côté métier, le ressenti est tout autre : une petite fonctionnalité d’ordonnancement intelligent prend toujours au moins 3 mois entre la conception et la mise en production. Il s’attendait à un doublement de la vitesse grâce aux outils, mais n’a obtenu que « du code écrit plus vite ». Ses mots sont directs : « J’ai dépensé des millions en licences, et tout ce que j’ai obtenu, c’est des développeurs plus débordés et des métiers plus pressés. »
Il s’est trompé sur l’emplacement du goulot d’étranglement. Son vrai goulot était ailleurs : chaque nouvelle fonctionnalité devait passer par le MES, l’ERP, le système qualité, les terminaux d’atelier, sans compter un jeu de reporting réglementaire — l’intégration et les tests de bout en bout bouffaient l’essentiel du délai. Et pour le code généré par IA, aucune porte de validation formelle ne se dressait entre lui et la production. Écrire du code plus vite, c’est juste faire la queue derrière le mauvais goulot.
1. L’industrie manufacturière le savait déjà il y a 40 ans : le goulot se déplace
Pour comprendre le présent, empruntons d’abord les lunettes que l’industrie porte depuis quatre décennies.
En 1984, Eliyahu Goldratt, consultant israélien de formation physicien, publie le roman Le But (The Goal), l’histoire d’un directeur d’usine au bord de la faillite qui sauve son site. Le message central tient en une phrase : le débit d’un système est déterminé par son maillon le plus étroit (la contrainte, autrement dit le goulot). Élargir les maillons non critiques ne change rien au débit global ; seul l’élargissement du goulot accélère l’ensemble. Et dès que vous élargissez ce goulot, il se déplace aussitôt vers le prochain maillon le plus serré. C’est la théorie des contraintes (Theory of Constraints, TOC).
Après 40 ans d’automatisation dans le secteur manufacturier, l’histoire ressemble à une succession de goulots d’étranglement qui se déplacent. Quand les machines-outils à commande numérique ont rendu l’usinage moins cher, le goulot s’est déplacé vers le changement d’outillage et le contrôle qualité. Quand les lignes de production flexibles ont accéléré les changements d’outillage, le goulot s’est déplacé vers l’ordonnancement et la coordination de la chaîne d’approvisionnement. Quand les MES ont rendu l’ordonnancement plus précis, le goulot s’est déplacé vers la prévision de la demande et la gestion inter-usines. Chaque segment automatisé en révèle un autre. L’automatisation n’élimine jamais les goulots d’étranglement — elle leur trouve simplement un nouvel emplacement.
Cette règle ne concerne pas que l’industrie. En juillet 2026, dans le podcast d’a16z Software in the Age of Agents, Steven Sinofsky, ancien président de Windows chez Microsoft, est arrivé indépendamment à la même conclusion, en s’appuyant sur l’exemple des logiciels d’entreprise. Ses propos exacts :
« The long tail got no shorter. It just got longer in a different way. » (La longue traîne n’a pas raccourci. Elle s’est simplement allongée autrement.)
Il a cité l’exemple du service client d’Amazon : supprimer le téléphone, laisser le chatbot renvoyer directement le produit. À première vue, on économise de la main-d’œuvre, mais en coulisses surgit immédiatement un besoin d’analyse des causes profondes — « comment éviter que ce type de problème ne se reproduise » —, bien plus complexe que de décrocher le téléphone. Même chose pour les notes de frais : une fois la saisie automatisée par OCR, le travail de la finance se déplace vers l’optimisation des déplacements professionnels et la comparaison dynamique des prix. Le travail ne disparaît pas, il remonte de la « saisie » vers « l’analyse et la décision ». Un vétéran de Microsoft, devenu associé chez a16z, sans jamais avoir lu Goldratt, est arrivé à la même conclusion que l’industrie manufacturière il y a quarante ans. L’un vient de l’atelier, l’autre du logiciel d’entreprise : deux chemins indépendants, une même loi.
Mais il faut nuancer cette loi, pour éviter qu’elle ne soit lue comme une vérité absolue. Certains goulots d’étranglement sont bel et bien éliminés pour de bon : dactylographes, standardistes, typographes au plomb — ces métiers-là n’ont pas « remonté », ils ont réellement disparu. Pour savoir si un travail va être déplacé ou supprimé, le critère est simple : la capacité libérée par l’automatisation génère-t-elle de nouveaux besoins (ce que les économistes appellent le paradoxe de Jevons), ou fait-elle simplement rétrécir la demande ? La plupart des métiers autour des systèmes centraux d’entreprise relèvent du premier cas : plus la comptabilité est rapide, plus le patron veut d’analyses, et plus elles sont fines. La conclusion tient donc en une phrase : déplacer les personnes et les budgets de la couche automatisée vers la couche qui émerge. (Pour la version longue du déplacement en queue de distribution côté logiciel d’entreprise, voir l’épisode bonus La vélocité des logiciels d’entreprise.)
Ce sujet est plus proche du logiciel que vous ne le pensez. En 2013, Gene Kim a presque transposé tel quel le récit d’usine de Goldratt dans l’exploitation informatique, en écrivant The Phoenix Project : l’histoire d’un DSI qui, grâce à la théorie des contraintes, sauve un département IT sur le point de faire sombrer toute l’entreprise. Autrement dit, « appliquer la logique des goulots d’étranglement de l’industrie manufacturière au logiciel » est une voie déjà éprouvée, pas une métaphore sortie de nulle part.
Deuxième partie — Retour au logiciel : écrire du code devient l’étape la moins chère
Quatre chiffres suffisent pour expliquer que « le coût de production du code tend vers zéro ». Ajoutez-y une cinquième série de données sur la structure du marché au premier semestre 2026, et vous verrez à quel point il est cher.
- Copilot : Les propres recherches de GitHub montrent que, dans les fichiers où Copilot est activé, environ 46 % du code est généré par Copilot. Attention au périmètre : il s’agit de la part au sein des fichiers activés, pas de 46 % de tout le code sur GitHub.
- Stripe : leur agent de codage interne « Minions » produit et fusionne plus de 1 300 PR par semaine. Lors de la démonstration publique de ce système en février 2026, l’ingénieur de Stripe Steve Kaliski a déclaré : « Personnellement, je ne me souviens plus de la dernière fois où j’ai commencé une tâche directement dans l’éditeur. » Le point de départ du travail des ingénieurs est passé de l’IDE aux fils Slack, aux Google Docs et aux tickets. Un détail clé à retenir : chaque PR passe par une revue humaine avant d’être fusionnée. Stripe a automatisé l’écriture, mais a laissé la validation aux humains. On y reviendra dans la section 4.
- NVIDIA : Jensen Huang a déclaré publiquement que 100 % des ingénieurs de NVIDIA utilisent des outils de programmation IA comme Cursor — « travailler sans IA » n’est tout simplement plus acceptable chez NVIDIA.
- Le paysage à trois acteurs au premier semestre 2026 (ceci est un complément de perspective, pas un nouvel argument) : Anysphere, la maison mère de Cursor, était valorisée à 29,3 milliards de dollars lors de son tour de série D en novembre 2025 ; en avril 2026, les discussions pour un nouveau tour évoquaient une valorisation de 50 milliards de dollars ; en juin 2026, SpaceX a annoncé son acquisition en actions pour 60 milliards de dollars. Parallèlement, Claude Code d’Anthropic a atteint 2,5 milliards de dollars d’ARR (revenu annualisé récurrent) en février 2026, et l’ARR global d’Anthropic a atteint 30 milliards de dollars en avril — à lui seul, Claude Code dépasse déjà les revenus totaux d’Anthropic au début de 2025. GitHub Copilot reste le standard de fait en termes d’installation. Ensemble, ces trois acteurs représentent un volume de marché qui frôle le total des éditeurs logiciels d’entreprise traditionnels.
En empilant les trois premières données, la conclusion est sans appel : le coût unitaire de production d’une ligne de code s’approche rapidement de zéro. Ajoutez la dernière donnée, et un constat s’impose : le prix unitaire de ce métier plafonne rapidement au niveau des logiciels traditionnels. L’argent à gagner au niveau des outils est déjà bien récolté — la prochaine couche, celle de la validation, de l’alignement et de l’orchestration, ne fait que commencer à être tarifée.
La question qui pique s’impose alors : si écrire du code ne coûte presque plus rien, pourquoi les logiciels restent-ils si chers, si lents et si difficiles à livrer ? La réponse est exactement celle de la théorie des contraintes : vous avez élargi l’étape « écrire du code », le goulot d’étranglement s’est simplement déplacé. Mais vers où ?
III. Le goulot s’est déplacé vers quatre endroits
Cette fois, le goulot se concentre sur quatre étapes. Aucune d’elles n’est accessible à l’IA à court terme.
Première étape : définir le bon problème. L’IA peut écrire en quelques secondes « la fonctionnalité que vous décrivez de vive voix », mais elle ne peut pas écrire « la fonctionnalité dont vous avez réellement besoin ». La plupart des échecs de projets logiciels viennent du fait que le produit final n’est utilisé par personne — dès le départ, on n’a pas suffisamment réfléchi au problème à résoudre. Maintenant que la production de code est devenue moins chère, « transformer un vague problème métier en une spécification claire, soluble et digne d’intérêt » (problem formulation) est devenu la compétence la plus rare et la plus chère. Les industriels ne sont pas dépaysés : si la gamme de fabrication et les plans d’ingénierie sont mal définis, même l’atelier le plus efficace produira en série des pièces rebutées.
Deuxième obstacle : l’intégration système. L’IA excelle à générer « un bout de code », « une fonction », « une page ». Mais un système prêt à être mis en production, c’est l’intégration de plusieurs centaines de fragments qui doivent échanger des données, gérer les cas limites, rester cohérents et encaisser les pannes. Générer des fragments coûte peu ; les assembler en un tout fiable coûte cher. Ce coût trouve sa racine dans l’alignement organisationnel et architectural — c’est précisément ce que traitent la loi de Conway et la Team Topologies (voir les deux premiers articles de cette série). Revenons au CIO du secteur manufacturier évoqué en introduction : son calendrier n’a pas été consommé par l’écriture de code, mais par l’interopérabilité entre les systèmes MES, ERP, contrôle qualité et reporting.
Troisième obstacle : la validation. Le volume de code explose, la fiabilité est inégale. Qui décide que « c’est bon » ? Tests, revues de code, observabilité, déploiements progressifs (canary) : le poids de ces tâches de « validation » ne fait qu’augmenter. C’est le goulot d’étranglement le plus sous-estimé, et celui où le miroir avec le secteur manufacturier est le plus profond. Nous y consacrerons la section 4.
Quatrième obstacle : l’alignement organisationnel. Quand des agents IA rejoignent l’équipe, qui décide de ce qui doit être fait, qui révise, qui est responsable des résultats ? C’est encore une extension de la loi de Conway et de la Team Topologies : l’alignement organisationnel devient lui-même le goulot d’étranglement. Le 11e article de la série y sera dédié : quand les nœuds de l’organisation ne sont plus tous humains, la gouvernance devient un avantage concurrentiel clé.
3.5 — La preuve de la généralisation au premier semestre 2026 : ce que le CIO de l’introduction a vu est déjà une réalité au niveau entreprise.
Le CIO dont je parlais en ouverture m’a confié, six mois plus tard, un changement notable : il a remonté le problème « on écrit vite, mais on ne livre rien de plus » lors de la réunion mensuelle de pilotage du groupe. Résultat, une cellule d’intégration transversale a été créée, réunissant autour d’une même table les responsables d’interface des systèmes MES, ERP, qualité et reporting, pour aligner tout le monde. Son histoire n’est plus un cas isolé — au premier semestre 2026, plusieurs des plus grands cabinets de services professionnels en Europe et aux États-Unis en ont déjà fait une priorité stratégique au niveau du groupe.
EY (Ernst & Young), la première « entreprise pionnière » à avoir déployé l’orchestration d’agents IA à l’échelle de toute l’organisation, en tant que « client zéro ». Microsoft l’a citée comme étude de cas de référence dans son bilan de l’exercice fiscal 2026 (FY26) : EY a déployé Microsoft 365 Copilot auprès de 150 000 employés, économisant environ 2,5 millions d’heures et 250 millions de dollars de coûts opérationnels ; elle a ensuite étendu Microsoft 365 Frontier Suite à plus de 400 000 employés dans le monde. Une fois intégrés aux systèmes de production internes, les chiffres parlent d’eux-mêmes : le délai de livraison de bout en bout a été accéléré de 95 %, les coûts d’exploitation financière ont baissé de 37 %, et la charge de travail manuelle sur les processus métier clés a été réduite jusqu’à 90 %. En un an, EY est passée d’un gain purement technique — « l’IA code plus vite » — à des résultats financiers concrets : « les processus métier tournent plus vite ». À noter : ce qui fait la force du cas EY, ce n’est pas le volume de code écrit, mais la façon dont l’entreprise a repensé l’orchestration entre systèmes, processus et fonctions.
Atos, intégrateur de systèmes mondial d’origine française, a dévoilé en juin 2026 sa pratique de « client zéro » : déployer Microsoft 365 Copilot auprès de ses 56 000 collaborateurs répartis dans 54 pays, et héberger jusqu’à 19 000 agents IA internes via Microsoft Agent 365, un plan de contrôle de gouvernance unifié. C’est l’illustration la plus directe du fait que « l’alignement organisationnel est le goulot d’étranglement » — gérer les points d’accès, les permissions, l’observabilité et les frontières de sécurité de 19 000 agents est bien plus difficile que de faire écrire du code à 19 000 agents. Atos le souligne lui-même : « La gouvernance et la sécurité sont le premier verrou de l’IA agentique. »
KPMG, de son côté, a annoncé au même moment un partenariat mondial avec Microsoft pour déployer Agent 365 et Copilot auprès de plus de 100 000 professionnels à travers le monde. C’est un geste emblématique qui fait passer l’orchestration des agents du statut de « projet IT » à celui d’« infrastructure d’exploitation métier ».
Trois événements se produisent dans la même fenêtre d’un mois — ce n’est pas un rythme marketing, c’est le niveau réel de l’IT en entreprise. Le consensus des grands cabinets professionnels occidentaux est clair : l’orchestration des agents, la validation inter-domaines et l’observabilité conformité sont le prochain goulot d’étranglement majeur de l’ère de l’IA — et aussi la destination du prochain gros budget. Cela rejoint directement la conclusion de la fin de la section 2 : « l’argent de la prochaine couche commence tout juste à être valorisé ».
Revenons au CIO du début : son vrai goulot d’étranglement est ailleurs — chaque nouvelle fonctionnalité doit traverser le MES, l’ERP, le système qualité, les terminaux d’atelier, plus tout un ensemble de contraintes de reporting réglementaire. L’intégration et les tests de bout en bout consomment l’essentiel du calendrier. Six mois plus tard, il a mis sur pied son « bureau d’intégration » — il a tracé tout seul le chemin qu’EY / Atos avaient déjà balisé. La seule différence, c’est qu’il l’a fait en solo, alors que les grands cabinets occidentaux en ont fait une stratégie de groupe. C’est pour ça que la phrase d’ouverture — « on a choisi le mauvais endroit pour le goulot d’étranglement » — est si importante : le goulot que tu crois voir a déjà été déplacé par la réalité vers l’étape suivante.
Cette section fait écho à l’étude mise à jour publiée par METR en février 2026 : dans les premières recherches, les développeurs seniors étaient ralentis de 19 % par l’IA. En février 2026, avec un nouvel échantillon plus large, les mêmes développeurs seniors sont passés à une accélération de 18 % (intervalle de confiance de -38 % à +9 %, preuves faibles) ; les nouveaux développeurs, eux, affichent -4 % d’accélération. Le fait que le signe passe de négatif à positif reflète précisément le changement de niveau observé au premier semestre 2026 — l’IA est passée d’un frein à un accélérateur. Pour le dire autrement : la concrétisation de l’accélération dépend étroitement du fait que vous ayez installé ou non la porte de la validation/alignment. C’est exactement ce que font EY et Atos — ils installent la porte, et l’accélération se libère ; sans cette porte, l’accélération n’est qu’un beau chiffre sur le papier.
Quatrième partie : la coupe la plus profonde — la validation, et ce que le “Jidoka” de Toyota enseigne vraiment
Parmi les quatre goulots d’étranglement, le plus mal interprété est la validation. Beaucoup la comprennent comme “puisque l’IA écrit vite, on multiplie les cycles de test”. C’est vrai à moitié. Pour comprendre pourquoi la validation coûte plus cher, il faut d’abord bien expliquer le concept de Toyota le plus cité, et le plus mal compris : le Jidoka (自働化).
Corrigeons d’abord une erreur de lecture largement répandue. Le Jidoka ne consiste pas à “remplacer l’humain par l’IA ou la machine”, ni à “transformer l’humain en machine, à le faire travailler sans relâche comme un automate”. Ces deux interprétations vont dans le mauvais sens.
L’autonomation, rien que dans son écriture, contient la réponse. En japonais, « automatisation » se dit jidōka (自動化), mais Toyota utilise volontairement jido-ka avec le caractère 働, qui comporte la clé de l’humain (亻). C’est une « automatisation avec une touche humaine » (automation with a human touch). Sa signification précise est la suivante : lorsqu’une machine ou une ligne de production détecte une anomalie, elle s’arrête automatiquement, laisse un humain intervenir, résout la cause racine, puis reprend la production. Deux mécanismes fonctionnent en parallèle : la machine est équipée de détection d’anomalies et s’arrête d’elle-même ; et si quelqu’un sur la ligne repère un problème, il tire la corde andon (アンドン) et toute la ligne s’immobilise immédiatement. La qualité n’est pas vérifiée en bout de chaîne : elle est intégrée à chaque étape, et traitée sur place.
Voici une conclusion contre-intuitive, qui fait directement écho au logiciel : plus l’automatisation est poussée, plus le rôle du contrôle qualité et de l’intervention humaine prend de l’importance. L’autonomation libère l’humain des tâches répétitives pour le repositionner là où il compte vraiment : détecter l’anomalie, arrêter la ligne, résoudre la cause racine. Si Toyota donne à ses opérateurs de terrain le pouvoir d’arrêter toute la chaîne, c’est précisément parce qu’il sait que, même avec une automatisation avancée, il faut quelqu’un pour dire « stop » quand ça coince. C’est tout le sens du slogan « donner de l’intelligence à la machine » : lui donner la capacité de s’arrêter et d’appeler un humain. L’humain reste toujours dans la boucle, chargé de résoudre la cause racine.
Le logiciel emprunte aujourd’hui cette même trajectoire, et il la parcourt à toute allure. Les études de GitClear sur la qualité du code assisté par IA ont déjà observé une augmentation des blocs de code dupliqués et une hausse du code « churn » à court terme : l’IA écrit vite, mais elle écrit aussi « du plausible ». Au premier semestre 2026, CodeRabbit a analysé 470 PR open source dans son propre benchmark, et a constaté que les PR collaboratives avec IA présentent en moyenne 1,7 fois plus de problèmes que les PR humaines, concentrés sur les erreurs logiques, les omissions de gestion d’exceptions et les failles de sécurité. Le chiffre avancé par Addy Osmani, responsable ingénierie chez Google, est encore plus frappant : le taux d’erreurs logiques dans le code généré par IA est supérieur de 75 % à celui du code humain. Le marché de la revue de code par IA affichait un ARR total d’environ 420 millions de dollars en 2026, et 44 % des équipes de développement utilisent déjà une forme de revue de PR par IA. À lui seul, CodeRabbit compte environ 140 000 développeurs payants sur GitHub. C’est le marché qui vote avec les pieds pour vous dire ceci : le coût réduit de la génération de code se paie en coût de vérification. Lorsqu’une masse considérable de code n’est plus relue ligne par ligne par un humain, le mécanisme de confiance traditionnel — « le développeur sait ce qu’il fait » — cesse de fonctionner. Ce qu’il vous faut alors, c’est l’équivalent logiciel de la corde andon et du mécanisme d’arrêt de chaîne.
- Les tests (unitaires, d’intégration, de bout en bout) passent de « si possible » à un seuil dur : pas de merge sans validation ;
- Le code review se recentre de « vérifier le style » vers « vérifier l’intention et les cas limites » : qu’est-ce que ce code cherche réellement à résoudre, et les conditions aux limites sont-elles couvertes ?
- Les outils de code review assistés par IA (CodeRabbit, Greptile, Copilot Reviews) assurent un premier tri grossier — mais il faut en connaître les limites : l’IA qui relit du code généré par l’IA laisse passer une catégorie spécifique de problèmes. Premier passage par l’outil, deuxième passage par un humain ;
- L’observabilité (monitoring, logs, tracing) devient la norme, car le comportement en production en dit plus long que le code lui-même ;
- Le déploiement progressif / les feature flags permettent de valider ce que l’IA génère sur un petit périmètre d’abord, puis d’étendre une fois que tout est confirmé.
Revenons aux 1 300 PR de Stripe dans la section 2 : l’écriture est déléguée à l’agent, mais la porte de la fusion reste entièrement entre les mains de la review humaine. C’est l’autonomation appliquée au logiciel, en version concrète : automatiser la production, garder la validation côté humain, et donner à l’humain le pouvoir de « bloquer ». Produire coûte moins cher, contrôler la qualité coûte plus cher : c’est une loi qui n’a pas changé depuis 40 ans.
Cinq — La prime de la « définition du problème » : une compétence qui vaut plus cher qu’un prompt
Si l’on dit souvent que la validation est le goulot d’étranglement le plus sous-estimé, la « définition du problème » est, elle, une compétence gravement sous-estimée.
Le prompt engineering a connu son heure de gloire, et beaucoup ont cru que « savoir écrire des prompts » était la compétence clé. Mais le prompt n’est qu’une technique pour « formuler ce qu’on veut ». Ce qui manque vraiment, c’est un cran au-dessus : la formulation du problème — transformer un vague souci métier en une question claire, résoluble et digne d’être résolue. Cette étape, l’IA ne peut pas la faire à court terme, car elle doit d’abord attendre que vous lui disiez « quel est le problème ».
Les vétérans de l’industrie manufacturière sentent le poids de cette étape mieux que quiconque. Une fois qu’un plan technique ou une gamme de fabrication est mal défini, même les étapes aval les plus efficaces ne feront que produire des erreurs en série. C’est pareil en logiciel : si le cahier des charges est mal spécifié, l’IA vous aidera à fabriquer, dix fois plus vite, un produit dont personne ne veut.
Le critère est simple : arrêtez de vous focaliser sur la « vitesse d’écriture du code », entraînez-vous à la « clarté de décomposition des problèmes ». En entreprise, cela signifie ériger la « définition du besoin » et la « validation / recette » en postes à part entière, au lieu de laisser les développeurs s’en occuper au passage. Maintenant que l’IA rend l’implémentation moins chère, ce sont ces deux rôles dont le retour sur investissement grimpe le plus vite.
Six — À quoi ressemblent les vrais goulots d’étranglement dans quatre secteurs
Si l’on applique ce principe de « déplacement du goulot » à quatre secteurs, on constate que, dans chacun, le vrai frein ne se situe pas dans l’écriture de code.
Industrie manufacturière. Le fil conducteur, c’est le CIO évoqué en introduction. Des fonctionnalités comme l’ordonnancement intelligent, la traçabilité qualité ou l’optimisation énergétique ne présentent pas de difficulté technique majeure — beaucoup de modèles existent déjà. Le vrai goulot d’étranglement se situe au niveau de l’intégration et des tests de bout en bout entre les systèmes MES / ERP / contrôle qualité / reporting, ainsi que dans la validation terrain sur les postes en atelier. Dans ce type de projet, le code s’écrit souvent très vite, mais l’interfaçage entre les différents systèmes MES/ERP peut prendre plusieurs fois le temps consacré à l’écriture du code. En plaçant les points de contrôle directement sur les postes de l’atelier et au niveau de l’intégration, on peut intercepter les défauts sur place, au lieu de les laisser remonter jusqu’à la mise en production.
Télécoms / Opérateurs. Une simple modification de forfait ou l’activation d’une ligne d’entreprise passe par plusieurs domaines : distribution, facturation, CRM, activation réseau, planification des interventions terrain. L’IA accélère le développement dans chacun de ces domaines, mais c’est l’intégration de bout en bout entre les domaines et les tests de cohérence qui représentent l’essentiel du calendrier. Les opérateurs ont aussi un goulot d’étranglement qui leur est propre : la conformité et le rapprochement comptable. Une erreur d’un centime sur une facture est un incident majeur — la validation y pèse plus lourd que dans n’importe quel autre secteur. Prenons l’activation d’une ligne d’entreprise : l’IA accélère le développement dans chaque domaine, mais l’intégration de bout en bout, couplée au rapprochement de facturation, occupe souvent encore la majeure partie du calendrier.
Finance. Un ajustement d’une règle de contrôle du crédit ou de lutte contre le blanchiment d’argent touche l’ensemble de la chaîne : applications, systèmes centraux, moteurs de risque, plateformes de données, reporting réglementaire. Le niveau d’exigence y est extrêmement élevé, car une seule erreur peut se transformer en incident de conformité. Le vrai goulot d’étranglement se situe dans l’explicabilité, l’auditabilité et la traçabilité : une règle générée par l’IA, aussi précise soit-elle, ne sera jamais mise en production si elle ne peut pas répondre à la question du régulateur : « pourquoi cette décision ? ». L’itération des règles anti-blanchiment en est l’illustration parfaite. Prenons une règle de détection des « transactions suspectes de gros montant » : l’IA peut produire en quelques heures le brouillon de la règle et le feature engineering. Mais c’est l’examen d’explicabilité qui suit qui constitue le véritable obstacle. Le régulateur exige, pour chaque alerte, trois éléments de preuve : la contribution des features, le chemin de décision du modèle, et des cas historiques similaires. Tant que ces trois éléments ne sont pas réunis, la règle ne peut pas être déployée ; si l’un d’eux ne colle pas, on repart de zéro. L’IA accélère la rédaction des règles, mais l’audit d’explicabilité du modèle et l’alignement avec le reporting réglementaire, cumulés, engloutissent souvent la majeure partie du cycle.
E-commerce. Une fonctionnalité de promotion ou de campagne commerciale touche le catalogue, les transactions, le marketing, l’entrepôt et le service client. L’IA permet d’écrire les pages et les API à toute vitesse, mais le goulot d’étranglement se déplace vers les tests de charge, la cohérence des stocks, la lutte contre la fraude aux promotions et le rapprochement comptable. Le soir d’une grande vente, ce qui plante n’a jamais été du code écrit trop lentement, mais des cas limites non validés. La préparation d’une grande campagne en est le parfait exemple : l’IA génère la page promotionnelle en un rien de temps, mais les tests de charge de bout en bout et la vérification de la cohérence des stocks mobilisent souvent la majorité des heures de préparation.
Les similitudes entre les quatre secteurs sont évidentes : l’IA accélère l’« écriture », mais bute sur l’« assemblage, la vérification et l’alignement ». Réinvestir la capacité de développement ainsi économisée dans ces trois domaines, voilà la vraie productivité.
Si vous êtes le DSI d’une entreprise de télécoms chinoise ou d’une banque par actions, vous vous demandez sans doute : est-ce que nous aussi, on est comme ça ? Pour être honnête, on est un cran derrière les leaders occidentaux, mais la structure est identique. Côté opérateurs, l’ouverture des lignes dédiées aux entreprises et le rapprochement de facturation en bout en bout restent le gros du calendrier ; l’IA accélère le développement par domaine, mais la cohérence inter-domaines devient le goulot d’étranglement. Pas mal de filiales provinciales ont d’ailleurs rattaché un « bureau d’intégration » ou un « PMO inter-domaines » directement au DSI. Côté finance, les itérations sur les champs de reporting réglementaire, les revues d’explicabilité pour les règles anti-blanchiment, et l’alignement des périmètres lors des inspections de la Banque centrale ou de l’Autorité de régulation, représentent souvent plus de 60 % du temps sur une fonctionnalité. Dans les deux cas, ce n’est pas un problème d’outils — c’est la porte de l’alignement organisationnel qui n’a jamais été posée. Et cette porte, c’est exactement ce que les EY et Atos occidentaux ont déjà installée.
Sept. Et si on se trompe ? Les trois erreurs de cadrage les plus courantes
Première erreur : confondre « écrire du code plus vite » avec « livrer plus vite ». C’est l’illusion la plus répandue. Le code n’est qu’un maillon de la chaîne de livraison. Élargir ce maillon ne rend pas toute la chaîne plus rapide ; cela ne fait qu’accumuler davantage de demi-produits derrière le goulot d’étranglement. La théorie des contraintes appelle cela du stock ; en logiciel, on parle de PR non validées et de branches jamais intégrées. Résultat : des développeurs plus débordés, des métiers plus pressés, et une production qui ne bouge pas — exactement la situation du CIO évoqué en introduction.
Deuxième erreur : accélérer la production en supprimant les contrôles qualité. C’est l’erreur typique qui va à l’encontre du jidoka. Certains pensent : « L’IA écrit plus vite et mieux, donc on peut simplifier la revue de code et supprimer les tests. » C’est tout le contraire. Plus la production est rapide, plus la corde d’andon doit être tendue. Les chiffres de CodeRabbit en 2026 le montrent : la densité de défauts dans les PR assistées par IA est 1,7 fois plus élevée que dans les PR humaines. Supprimer les étapes de validation, c’est laisser une chaîne de production tourner à plein régime sans personne pour tirer la sonnette d’alarme — les défauts se déverseront d’autant plus vite en production.
Troisième erreur : investir massivement sur les maillons non critiques. L’intégration est le goulot d’étranglement, mais vous achetez davantage de licences d’IA de codage. La validation est le goulot, mais vous recrutez plus de développeurs. La théorie des contraintes l’a déjà démontré : investir sur un maillon non critique ne contribue en rien à la production globale, et ne fait qu’aggraver les chiffres. La bonne démarche consiste d’abord à identifier le goulot, puis à concentrer toutes les ressources dessus.
VIII. Ce que les décideurs doivent retenir
Leçon n° 1 : avant d’acheter un outil, dessinez d’abord une carte des goulots d’étranglement. Décomposez vos trois dernières livraisons qui ont coincé et regardez où le temps est réellement passé. Est-ce que vous n’arrivez pas à écrire le code, ou bien à l’assembler, à trouver quelqu’un pour valider, ou à clarifier le besoin ? Si vous n’arrivez pas à le pointer du doigt, c’est que vous devinez à l’aveugle au niveau technique. Une carte des goulots d’étranglement vaut plus que n’importe quelle liste d’achats d’outils : elle permet d’éliminer au moins la moitié des investissements IT inefficaces dans une grande entreprise.
Leçon n° 2 : investissez la capacité libérée dans la définition du besoin et la validation. L’IA accélère le développement, ce qui veut dire que vous pouvez dégager des effectifs. Intégrez officiellement ces personnes dans deux postes — « définition du besoin » et « validation / recette » — et ne les laissez pas continuer à écrire toujours plus de code. Le retour sur investissement de ces deux postes est ce qui progresse le plus vite à l’ère de l’IA.
Leçon n° 3 : installez un cordon d’arrêt (andon) sur vos logiciels. La mise en œuvre la plus directe du jidoka, c’est de poser des garde-fous stricts dans votre CI/CD : pas de merge sans tests verts, une review qui vérifie l’intention et les limites, un déploiement progressif sur une petite population d’abord, et une observabilité systématique. Plus la production est automatisée, plus cette barrière doit être solide. Il s’agit d’empêcher que « le code gratuit » ne devienne « les incidents gratuits ».
Leçon n° 4 : repositionnez les gens, ne les retirez pas. Le jidoka mène à la même conclusion : plus l’automatisation est profonde, plus les humains doivent être placés en position de jugement, de validation et d’analyse des causes racines. Libérer les gens des tâches répétitives pour les redéployer sur la validation et l’alignement, c’est l’action centrale de conception organisationnelle à l’ère de l’IA — et c’est ce que développeront les prochains articles de cette série.
IX. Vous vous demandez peut-être
« On ne fait qu’un pilote IA à petite échelle, pas besoin de cartographier tous les goulots d’étranglement de l’entreprise, si ? » Même pour un pilote, il faut d’abord y voir clair : l’étape testée est-elle réellement le goulot d’étranglement ? Si le point de blocage se situe en réalité au niveau de l’intégration ou de la validation, alors piloter l’IA sur « l’écriture de code », c’est investir là où ça ne bloque pas — exactement le troisième type de désalignement décrit dans la section 7. Un diagnostic ciblé des goulots d’étranglement, même à petite échelle, permet de dépenser l’argent des outils à bon escient.
« Les portes de validation ne vont-elles pas ralentir la livraison ? » À court terme, il y aura des frictions ; à long terme, c’est une accélération. La « rapidité » sans portes d’acceptation, c’est une rapidité qui pousse les défauts en production, avec des coûts de reprise au moins dix fois supérieurs. L’expérience du jidoka (autonomation) le montre : corriger un défaut sur place ne coûte qu’une fraction de ce qu’il en coûte de le laisser descendre en aval.
« Quel est le lien avec notre transformation IA en cours ? » Le lien est direct. L’écueil le plus courant dans une transformation IA, c’est de supposer que le goulot se situe dans « l’écriture de code / la capacité de production », puis d’acheter une pile d’outils pour élargir ce segment. Faites d’abord un diagnostic des goulots d’étranglement, ensuite décidez où investir. C’est aussi pour cela que j’ai placé « l’évaluation des capacités » et « l’identification des cas à valeur » en tête du Cadre d’accompagnement en 7 étapes pour la transformation IA : on regarde d’abord où se trouve le goulot, ensuite on parle des outils.
Auto-vérification inversée (ne pas embellir en répondant) : lors de ta dernière livraison bloquée, le temps a-t-il été passé à écrire le code, ou à assembler, valider, aligner ? Tes outils d’IA génèrent un tas de code — combien de ce code est réellement déployé en production de manière stable et utilisé par de vrais utilisateurs ? Dans ton CI/CD, y a-t-il un contrôle strict du type « pas de merge sans tests verts » ? Si tu as un doute sur au moins une de ces trois questions, ne te précipite pas pour acheter plus d’outils d’IA — identifie d’abord ton goulot d’étranglement.
Prochaine étape
Ceci est le troisième article d’une série de 15 sur la transformation du génie logiciel à l’ère de l’IA. Après Conway (l’organisation détermine l’architecture) et les topologies d’équipe (comment concevoir l’organisation), on en arrive au déplacement des goulots d’étranglement (quand le code devient quasi gratuit, où se situe le goulot ?). Le prochain article (n° 4) adopte une perspective plus opérationnelle : comment choisir les principaux outils de programmation IA. Mais la conclusion pourrait être contre-intuitive : le choix relève en fin de compte d’une décision organisationnelle — il faut sélectionner selon ton niveau de maturité et de gouvernance, pas selon « qui écrit le code le plus impressionnant ».
La structure du marché au premier semestre 2026 a propulsé cette urgence sur le bureau des CIO : l’acquisition de Cursor par SpaceX pour 60 milliards de dollars, les 2,5 milliards de dollars d’ARR de Claude Code, et le rapport conjoint Gartner-Microsoft identifiant la « gouvernance de l’IA » comme premier goulot d’étranglement — trois signaux qui se cumulent pour dire une chose : l’argent de la couche « génération de code » est déjà fait, la prochaine valeur se joue sur la validation, l’alignement et l’orchestration. Les prochains articles (épisode 9 de la série, Maturité des outils de programmation IA ; épisode 11, Quand les nœuds de l’organisation ne sont pas tous humains ; et le hors-série La vélocité des logiciels d’entreprise) développeront chacun de ces points.
Note de série : Cette série suit en continu les dernières évolutions des outils de programmation IA, des structures organisationnelles et des paradigmes d’ingénierie logicielle — notamment les nouvelles déclinaisons de la loi de Conway à l’ère des agents IA et la maturité de l’écosystème d’outils. Suivez cette série pour des recherches actualisées en permanence.
Si ce que vous lisez ici évoque exactement le piège dans lequel votre entreprise est en train de tomber — « un an d’outils déployés, des millions de dollars de licences, et aucun changement dans le rythme de livraison » — alors lisez la suite.
Ancien ingénieur IBM, coach certifié ICF, j’ai mené des projets IA / transformation numérique pour des opérateurs télécoms et de grandes entreprises. Trois façons d’avancer :
- Formation interne en entreprise (30 000 ¥/jour, 3 jours ≈ 90 000 ¥) : parcours complet de « reconception des goulots d’étranglement + capacités des outils vs déploiement à grande échelle », avec analyse appliquée à vos scénarios métiers réels.
- Consultation ponctuelle (5 000 ¥/heure) : focus sur une question clé qui vous préoccupe (ex. « Nous achetons des outils d’IA depuis un an, pourquoi la livraison ne s’est-elle pas accélérée ? »).
- Conférences gouvernementales / forums : interventions sur les thèmes de la transformation IA.
Contact : coach@iaiuser.com, ou laissez un commentaire décrivant votre situation spécifique.
Complément de la série B : voir la méthodologie signature v1.0 (Apprendre l’IA pas à pas 187).
À propos de cette série
« La transformation de l’ingénierie logicielle à l’ère de l’IA » est une série de recherche approfondie destinée aux CIO/CDO/CTO et responsables de la transformation numérique dans les secteurs des télécommunications, de la finance, de la fabrication, du e-commerce, etc. Composée de 15 articles, elle s’appuie sur plus de 200 articles académiques et rapports sectoriels, offrant des références décisionnelles avec niveaux de preuve clairement indiqués.
Je suis ancien ingénieur IBM, coach certifié ICF, et j’ai mené des projets d’IA / transformation numérique pour des opérateurs télécoms et de grandes entreprises. Tout ce qui est écrit ici repose sur des jugements pratiques forgés au contact réel des entreprises, y compris dans les moments difficiles.
Ces dernières années, j’ai accompagné des projets aussi variés que des lignes dédiées entreprises / des projets de rapprochement de facturation chez des opérateurs télécoms, des règles de lutte anti-blanchiment et des reportings réglementaires auprès de la banque centrale dans une banque par actions, des projets d’intégration inter-domaines MES / ERP / contrôle qualité dans un groupe industriel, ainsi que des tests de charge et la gestion de la cohérence des stocks pendant la préparation des grandes promotions e-commerce. Le scénario classique, c’est : on déploie l’outil pendant un an, on dépense plusieurs millions en licences, et le rythme de livraison ne change pas d’un iota — le problème vient de ce dont parle cet article : « le goulot d’étranglement a été mal placé ».
Sources de référence (toutes vérifiées)
- a16z (2026). Software in the Age of Agents. Le podcast a16z. (La phrase culte de Steven Sinofsky, ancien président de Windows chez Microsoft : « The long tail got no shorter, it just got longer in a different way » — une confirmation indépendante, du point de vue des logiciels d’entreprise, de la loi du déplacement des goulots d’étranglement de la TOC ; source primaire — extrait audio du podcast. Mention de position : associé chez a16z / ancien cadre dirigeant chez Microsoft, position VC. Invités vérifiés : Seema Amble, associée de l’équipe entreprise chez a16z, Steven Sinofsky, ancien président de Windows chez Microsoft (board partner), et Elena Burger, rédactrice chez a16z ; diffusion en juillet 2026.)
- Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (La source originale de la Théorie des Contraintes (TOC), source primaire ; un roman dont le cadre est une usine de fabrication.)
- Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press.（Transposition directe de la TOC de Goldratt dans l’IT Ops — le pont entre manufacture et logiciel ; source primaire.）
- Toyota. Toyota Production System — Jidoka. toyota-global.com（自働化 = automatisation avec une touche humaine : arrêt de ligne sur anomalie + intervention humaine pour analyser la cause racine ; système Andon ; source primaire.）
- GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle.（Copilot complète environ 46 % du code dans les fichiers où il est activé, au sens « fichier avec complétion activée » ; source primaire.）
- Stripe (2026-02). Minions : les agents de codage de bout en bout, en un seul passage, chez Stripe. stripe.dev/blog.（Plus de 1 300 PR par semaine générées par Minions, toutes relues par des humains ; niveau 1 + vidéo « How I AI » de mars 2026 où Steve Kaliski confirme de visu : « Personnellement, je ne me souviens plus de la dernière fois où j’ai commencé une tâche dans un éditeur. »）
- NVIDIA / Jensen Huang. Déclaration publique (de première main) confirmant que 100 % des ingénieurs utilisent des outils de programmation IA comme Cursor.
- Anysphere / Cursor (série D novembre 2025 / négociations avril 2026 / acquisition par SpaceX juin 2026). Valorisation : 29,3 milliards → 50 milliards en négociation → 60 milliards lors de l’acquisition ; ARR supérieur à 1 milliard fin 2025, puis à 2 milliards début 2026. Positionnement : intégré à SpaceX sous la filiale SpaceXAI ; sources de valorisation : Accel / Coatue / a16z / Thrive / Nvidia / Google. Wikipedia + tech-insider.org + valueaddvc.com (recoupement multi-sources, secondaire)
- Anthropic (février 2026). L’ARR de Claude Code atteint 2,5 milliards de dollars ; l’ARR global d’Anthropic s’élève à 30 milliards de dollars en avril 2026. Positionnement : communication officielle d’Anthropic + presse secondaire (Time Magazine / Reuters). Les abonnements professionnels ont quadruplé au cours de l’année 2026, et le nombre d’utilisateurs actifs hebdomadaires a doublé depuis janvier.
- GitClear (2025). Recherche sur la qualité du code assistée par IA. (Observation d’une hausse du code dupliqué / du churn à court terme avec l’assistance IA, appuyant l’idée que « la validation devient plus coûteuse », source secondaire)
- Microsoft (2026-07-28). Retour sur l’exercice fiscal 26 de Microsoft : de l’expérimentation IA à la transformation de pointe. (Déploiement de Copilot auprès de 150 000 employés chez EY + 2,5 millions d’heures économisées / 250 millions de dollars d’économies + réduction de 95 % des délais de livraison + baisse de 37 % des coûts financiers + jusqu’à 90 % de réduction de la charge de travail manuelle ; article bilan de l’exercice fiscal 26, source primaire). Note de positionnement : blog officiel de Microsoft, point de vue d’un éditeur d’outils.
- Microsoft / Atos (2026-06-09). Atos Group and Microsoft expand strategic collaboration to scale secure agentic AI.（56 000 employés Atos + 19 000 agents, tous gouvernés de manière unifiée via Agent 365 ; 54 pays ; premier intégrateur de systèmes mondial français à déployer à cette échelle, annonce officielle de premier rang + analyse indépendante de Futurum Group en date du 2026-06-09）**Positionnement : annonce conjointe Microsoft-Atos, point de vue éditeur + intégrateur de systèmes.
- Microsoft 2026 Work Trend Index (2026-05). *2026 Work Trend Index Annual Report.*（les Frontier Professionals représentent 16 à 19 % des effectifs ; les Frontier Firms constituent la « zone idéale » où capacités organisationnelles et individuelles sont toutes deux élevées ; croissance de 15× du nombre d’agents en glissement annuel, et de 18× dans les grandes entreprises ; 66 % des utilisateurs d’IA déclarent libérer du temps pour des tâches à plus forte valeur ajoutée, rapport de deuxième rang）
- METR (2026-02-24). Nous repensons la conception de notre expérience sur la productivité des développeurs. (Juillet 2025 : les développeurs seniors ralentis de -19 % → Février 2026 : les mêmes développeurs seniors accélèrent de -18 % (CI de -38 % à +9 %, preuves faibles) ; les nouveaux développeurs accélèrent de -4 % ; prépublication de premier niveau / mise à jour expérimentale)
- METR (2026-05-11). Mesure de l’impact auto-déclaré de l’IA de début 2026 sur la productivité des travailleurs techniques. (349 travailleurs techniques déclarent une valeur médiane de l’IA de 1,4x à 2x ; biais cognitif « auto-déclaré supérieur à la mesure réelle », niveau secondaire)
- CodeRabbit (2026). Benchmark de 470 PR open source : les PR collaboratives avec IA génèrent 1,7 fois plus de problèmes que les PR humaines ; le marché total de la revue de code par IA en 2026 s’élève à 420 millions de dollars ; environ 140 000 développeurs payants. Positionnement : données propres à CodeRabbit + évaluation Git AutoReview du 29/04/2026 (niveau secondaire). Données d’Addy Osmani (responsable ingénierie chez Google) : les codes générés par IA présentent un taux d’erreurs logiques supérieur de 75 %, niveau secondaire / déclaration directe.
- Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (La performance de livraison est déterminée par la culture, le flux et le feedback, et non par la vitesse de codage individuelle, niveau primaire.)
Lorsqu’on parle de modèles de langage, on évoque souvent leur capacité à « raisonner ». Mais concrètement, qu’est-ce que cela signifie ? Un modèle ne « pense » pas au sens humain du terme ; il génère du texte en s’appuyant sur des probabilités. Pourtant, avec l’introduction de mécanismes comme le chain-of-thought (CoT), ces systèmes parviennent à décomposer des problèmes complexes en étapes intermédiaires, un peu comme un élève qui pose ses calculs avant de donner la réponse finale.
Prenons un exemple simple. Si vous demandez à un GPT de résoudre un problème de logique, sans CoT, il risque de répondre directement, avec un taux d’erreur non négligeable. Avec le CoT, le modèle va d’abord énumérer les hypothèses, puis les confronter, avant de conclure. Cette approche, bien que plus lente, améliore nettement la précision sur des tâches nécessitant plusieurs étapes.
Cela dit, tout cela repose sur des tokens — ces unités de texte que le modèle traite. Plus la séquence est longue, plus le coût computationnel augmente. C’est un équilibre délicat entre performance et efficacité. Et si les avancées récentes impressionnent, il faut garder en tête que le « raisonnement » reste une simulation statistique, pas une véritable compréhension.
buymeacoffee
