L’IA a mangé la couche traduction du métier. Reste le jugement.

Et si le vrai goulot d’étranglement n’était plus d’écrire le code, mais de le relire ?

Pendant trente ans, l’organigramme d’une boîte tech a toujours eu la même forme : un petit groupe décide le pourquoi, un groupe un peu plus grand décide le quoi, et toute la masse en dessous fait le comment — la traduction de l’intention business en specs, en tickets, en PR, en notes de release. L’IA vient de rendre cette traduction quasi gratuite [1]. La question, maintenant, c’est ce qui survit à ce séisme.

Ce que l’IA a vraiment dévoré

Ajey Gore le formule mieux que moi : on a longtemps été des « traducteurs glorifiés » [1]. Prendre une chose dans un langage, la sortir dans un autre. Recommencer. Tout un secteur — Agile, SAFe, le modèle Spotify — s’est construit pour rendre ce pipeline de traduction plus efficace.

Le débat sur les agents est toujours posé comme « l’IA remplace les ingénieurs ». C’est légèrement à côté. L’IA n’est pas venue chercher un métier, elle est venue chercher une forme de travail : la conversion. Et c’est précisément la couche du milieu de la pyramide qui était faite de ça.

Ce qui survit, donc, c’est le jugement aux deux bouts : définir pourquoi construire quelque chose, et décider à quoi ressemble le bon [1]. Les équipes rétrécissent. Le manager qui ne fait que coordonner aura du mal à justifier son siège. Et l’ingénieur qui sait concevoir des systèmes de qualité n’a jamais autant compté.

Le code de première passe est gratuit. Le code qui marche, non.

Will Larson tire les mêmes conclusions, mais côté terrain. Sa première règle révisée du leadership technique : une migration complexe peut désormais être détenue à 95 % par un seul individu, en 10 % du temps [2]. L’impact du jugement individuel sur l’entreprise n’a jamais été aussi élevé.

Mais il enchaîne immédiatement avec la nuance qui change tout :

Tant que le code de première passe est quasi gratuit, le coût du code qui fonctionne dépend de ton harnais de développement, et lui n’est pas gratuit.

Tests, CI/CD, environnements de validation, capacité à prévisualiser un changement : ce qui rendait l’ingénierie rapide il y a deux ans est exactement ce qui la rend rapide aujourd’hui [2]. L’agent accélère la génération. Il n’accélère pas magiquement la confiance.

Le nouveau goulot, c’est la relecture

Et c’est là que ça se corse. Quand l’implémentation devient instantanée, le vrai bottleneck se déplace vers le volume de code à relire — y compris ton propre git diff après que ton agent a fini [3].

Vinícius le dit sans détour : il lui arrive de rejeter du code IA même quand il marche. Ses critères sont d’une clarté qui devrait être affichée dans toutes les équipes [3] :

• quand il ne peut pas expliquer l’approche avec ses propres mots,
• quand le diff est plus gros que le problème,
• quand le code introduit des abstractions avant d’avoir prouvé qu’elles servent,
• quand il fait davantage confiance à l’output qu’à sa propre compréhension.

Du code qui tourne et qui fait passer la CI au vert peut quand même être une mauvaise solution. L’ingénierie a toujours consisté à livrer des solutions adéquates, scalables, maintenables — pas juste « vertes » [3].

Ce n’est pas l’IA le problème. C’est l’humain derrière.

Le contre-exemple le plus parlant vient d’un mainteneur open source. Thomas raconte sa rencontre avec dirge, un projet « assumé comme développé massivement à l’IA, dans le code comme dans les PR ». Réflexe initial : passer son chemin, trop de slop. Sauf que derrière le projet, il y avait quelqu’un qui se souciait du métier et avait des objectifs précis [4].

Résultat : deux bugs signalés, l’un corrigé 1h30 après, l’autre 3h après — avec un test de non-régression complet. Sa conclusion désarmante : ses propres PR étaient devenues inutiles. Un bon ticket bien écrit est littéralement un prompt pour l’agent du mainteneur [4].

J’ai autant confiance dans du code IA supervisé par un bon développeur que dans le code qu’il aurait tapé à la main.

La fracture n’est plus humain vs IA. Elle est entre un agent supervisé par quelqu’un qui sait ce qu’il fait, et un agent laissé en roue libre.

Pour superviser, il faut industrialiser

Reste à passer du principe à la pratique. Et là, deux leviers concrets émergent.

D’abord, la standardisation. Selon une étude sur les équipes AI-native, 55 % des leaders craignent que leurs équipes perdent la compréhension partagée de l’évolution du code, et 39 % s’inquiètent de livrer avec confiance à mesure que les agents écrivent davantage [5]. Le problème n’est pas que l’IA génère du mauvais code : c’est que sans standards, l’agent de chaque dev prend des décisions différentes. L’un teste avec Jest, l’autre avec Mocha. Ça marche, mais la base de code perd sa cohérence.

Ensuite, l’application déterministe des règles. Parce qu’un AGENTS.md ou un CLAUDE.md, c’est une instruction — et l’agent l’ignore parfois. Zarar propose une solution radicale : les Agent Hooks, qui s’insèrent pendant le travail de l’agent (un PreToolUse qui bloque une écriture, un hook qui empêche l’agent de se déclarer « terminé » tant qu’un test échoue) [6]. La différence avec les instructions ? Un hook, c’est déterministe. Ça marche 100 % du temps.

C’est exactement la leçon que Bayer a tirée en construisant PRINCE, son système agentique de recherche préclinique : la fiabilité ne vient pas du modèle, mais du harness engineering autour — orchestration, frontières des outils, persistance d’état, retries, fallbacks, validation, boucles de réflexion, observabilité et revue humaine [7]. Le modèle génère. C’est l’échafaudage qui rend fiable.

Alors, on garde quoi ?

L’IA a rendu l’écriture de code presque gratuite. Mais elle a rendu le jugement, la supervision et le harnais plus précieux, pas moins. La couche traduction disparaît ; la couche responsabilité, elle, ne bouge pas.

La vraie question pour ton équipe n’est donc pas « combien de code l’IA peut-elle écrire ». C’est : qui, chez toi, est encore capable de dire non à un diff qui marche — et de l’expliquer ?

---

Sources

1. The Anatomy of an AI-Native Org
2. Revised rules of engineering leadership.
3. When I reject AI code even if it works
4. When it’s the maintainer who’s AI-pilled
5. How to standardize AI code generation across your development team
6. Don’t rely on instructions, use Agent Hooks to enforce guardrails
7. Building Reliable Agentic AI Systems

Pour aller plus loin

• Why is Meta destroying its engineering organization? — le contre-modèle : ce qui arrive quand on traite l’ingénierie comme un centre de coûts et qu’on force l’IA par le haut.
• Leaked OpenAI financials put a hard number on Altman’s compute burn — 38,53 Mds$ de pertes en 2025 : le rappel que « presque gratuit » côté usage cache une facture colossale côté infrastructure.
• Cleaning up after AI rockstar developers — la version humaine et intemporelle du code que personne ne peut relire : applicable mot pour mot aux agents.
• Why Amazon hates ‘human-in-the-loop’ AI governance — la tension de fond : jusqu’où garder l’humain dans la boucle quand les agents montent en autonomie ?

Cet article a été rédigé en m’appuyant sur une IA pour m’aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.