Tout le monde a l’IA, et l’entreprise n’apprend toujours rien

Les licences Copilot sont déployées, ChatGPT Enterprise tourne, Claude est dans toutes les poches. Et pourtant : qu’est-ce qui a vraiment changé dans le produit, dans l’organisation, dans la qualité ? Une étude récente montre que face à une réponse IA fausse, 73% des participants l’acceptent quand même — et leur confiance augmente [2]. La courbe de productivité monte. Le delta sur le produit, lui, ne suit pas.

Le K qui dérange

Avant Robert Glaser et Ethan Ding, il y a une donnée. Sur les commits par ingénieur, depuis l’arrivée des LLMs en 2023, la trajectoire ressemble à un K : les seniors décollent, les juniors stagnent ou régressent [3].

Dax (qui construit opencode.ai), Karri Saarinen (CEO de Linear), David Cramer (fondateur de Sentry) — aucun n’est critique de l’IA. Tous voient le même pattern : si les ingénieurs sont plus productifs, le rythme d’amélioration du produit par ingénieur devrait monter. Il ne monte pas [3].

Lines of code produced per hour might not be the right thing to measure at all.

On mesure ce qui est facile à mesurer — vitesse de PR, volume de commits — et on rate ce qui compte : la qualité, la cohérence, le produit qui s’améliore vraiment.

La capitulation cognitive

Pourquoi le delta de productivité ne se transforme pas en delta de qualité ? Parce qu’au niveau individuel, quelque chose de plus profond se joue. Steven Shaw et Gideon Nave (Wharton) ont mis un mot dessus : cognitive surrender [2].

La distinction est précieuse. Cognitive offloading : tu délègues le “comment” et tu gardes le “quoi”. Tu juges le résultat, tu le corriges. Cognitive surrender : tu arrêtes de construire la réponse. Le résultat de l’IA devient ton résultat. Il n’y a plus rien à corriger, parce que tu n’as jamais formé une opinion indépendante à comparer.

Là où la chose mord, c’est dans nos métiers. La PR de 600 lignes que tu scannes en diagonale parce que les noms de variables sont raisonnables et que les tests passent. La transition d’état à la frontière d’une transaction que tu ne valides plus. Le code qui a l’air propre. Tu n’as pas formé l’opinion. Tu as récupéré la confiance du modèle [2].

Les gains individuels ne deviennent pas des gains organisationnels

Robert Glaser pose la question franchement : est-ce que les gens utilisent l’IA, ou est-ce que l’organisation apprend de l’IA ? [1]

Ethan Mollick a passé deux ans à le documenter : les gains de productivité individuels ne deviennent pas automatiquement des gains organisationnels. Les gens deviennent plus rapides, écrivent mieux, automatisent plus, deviennent silencieusement des cyborgs. La boîte, elle, n’apprend presque rien.

Le management voit l’usage de licences (“où est le ROI sur les 2 millions d’euros qu’on a payés à Anthropic ?”), des comptes de prompts, peut-être un sondage, quelques PoCs encourageants en steering committee. Pendant ce temps, les vraies découvertes restent dans la tête de l’engineer qui les a faites — et partent quand il quitte la boîte [1].

Ce qui manque, ce n’est pas l’outil. C’est le mécanisme qui transforme une découverte individuelle en capacité d’équipe, puis en capacité d’organisation.

Repenser le SDLC, pas juste l’ajouter à côté

Tim Bozarth (CVP CoreAI chez Microsoft), Nancy Wang (CTO 1Password) et Taroon Mandhana (CTO AI chez Atlassian) viennent d’apporter leur réponse à DX Annual : il faut redessiner l’organisation, pas plaquer l’IA dessus [4].

Le constat de Bozarth est saisissant : sur les cinq étapes plan / create / validate / deploy / operate, historiquement 80% du temps part dans operate, 10-15% dans create, le reste se partage. Dans les équipes les plus efficaces aujourd’hui, c’est inversé : plan et validate deviennent majoritaires. Parce que c’est là que les humains restent les “tastemakers”. Et ne pas déléguer la sécurité à l’IA — utilisez-la pour le pen testing, pas pour livrer du code sécurisé tout seul [4].

Wang ajoute une donnée concrète : chez 1Password, on n’écrit plus de PRDs longs. Les équipes construisent des prototypes et les mettent devant les clients. Cela élimine la moitié des allers-retours produit/engineering. Mais attention : le SDLC est un pipe. Plus de makers en amont = plus de PRs en aval = plus de reviews. Si tu ne réponds pas au goulot d’étranglement de la review, tu ne fais que déplacer le problème.

Compounder, pas juste prompter

Eugene Yan répond avec un mot clé : compound. Chaque artefact fini — code, doc, analyse, décision — devient le contexte de la session suivante. Chaque correction met à jour une config qui réduit les erreurs futures [5].

Ce n’est pas spécifique à l’IA. C’est exactement ce qu’on fait avec un nouveau collaborateur : donner du contexte, encoder son goût en règles, rendre la vérification facile, déléguer des tâches plus grosses, fermer la boucle. Sauf qu’avec l’IA, la mémoire est dans des fichiers — INDEX.md, STYLE.md, CONFIG.md — et la “configuration” est un livrable de l’équipe, pas un document personnel.

Le message implicite : si chacun bricole ses prompts dans son coin, vous restez au stade individuel. Pour que la boîte apprenne, il faut traiter le contexte comme une infrastructure partagée [5].

L’accountability comme garde-fou

Et puis il y a la phrase qui devrait être épinglée dans toutes les retros agiles. La semaine dernière, un thread viral montrait un agent Cursor/Claude qui avait supprimé une base de prod. Le développeur cherchait la confession de l’agent. Ibrahim Diallo répond sèchement : AI didn’t delete your database, you did [6].

Pourquoi ton agent a-t-il un endpoint qui supprime la prod entière ? Pourquoi pas de garde-fou ? Pourquoi cette permission ?

Diallo raconte une mésaventure de 2010 où il a effacé trunk en SVN par erreur. Le lendemain, son lead lui a demandé d’écrire un script pour automatiser le déploiement et empêcher ce genre d’erreur. C’est devenu un CI/CD complet. L’automatisation élimine les erreurs bêtes. L’IA ne les supprime pas — elle les amplifie si tu ne mets pas les barrières [6].

Apprendre, vraiment

Si je relie tous ces fils — le K-shape qui montre des gains individuels qui ne se traduisent pas en produit, la cognitive surrender qui désactive le jugement, le gap entre individu et organisation, la nécessité de redessiner le SDLC, la compounding, l’accountability — ce qui se dessine, c’est une seule question : qu’est-ce que mon entreprise apprend de tous ces tokens dépensés ?

Ce n’est pas la technologie qui répondra. C’est un mécanisme : qui transforme une découverte individuelle en capacité d’équipe, puis en pratique d’organisation. Sans ce mécanisme, vous payez très cher pour faire la même chose plus vite — pas pour faire mieux.

Et chez vous, qu’est-ce que l’organisation a appris de l’IA cette année ?

---

Sources

1. When everyone has AI and the company still learns nothing
2. Cognitive Surrender
3. claude code is not making your product better
4. Designing the AI-native engineering organization
5. How to Work and Compound with AI
6. AI didn’t delete your database, you did

Pour aller plus loin

• 10 Lessons for Agentic Coding — Dix principes condensés pour coder avec un agent : implémenter pour apprendre, documenter l’intention, garder les specs synchronisées. Une checklist à imprimer.
• Programming in 2026: excitement, dread, and the coming wave — Andrew Montalenti compile 40+ retours de programmeurs sur ce qu’il vient de se passer en quelques mois. Lecture longue, mais salutaire pour replacer le moment présent.
• The AI Correction Will Not Be Evenly Distributed — Quand la bulle IA se dégonflera, certains tomberont plus bas que d’autres. Argumentation sur les valorisations et les vrais usages.
• ServiceNow adds agent kill switches to AI control tower — La gouvernance des agents devient un produit. ServiceNow ajoute des “kill switches” : pendant qu’on apprend à les utiliser, il faut aussi savoir les arrêter.

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.