Bloomberg affirme que l'IA de programmation provoque une panique de productivité. Ils se trompent de diagnostic.
L'écran brille dans l'obscurité, tout le monde a décroché depuis des heures. Je scrolle sur tech Twitter quand Bloomberg lâche sa bombe : "Claude Code et la Grande Panique Productivité de 2026."
J'ai tout lu. Et j'ai eu cette réaction partagée qu'on a quand un médecin décrit parfaitement nos symptômes, puis prescrit le mauvais médicament. Oui, la douleur est réelle. Non, ce n'est pas pour ça que ça fait mal.
Bloomberg a pondu 3 000 mots sur les agents IA qui produisent trop de code trop vite. Pas une seule fois ils n'ont mentionné que personne ne dit aux agents quoi produire. Trois mille mots sur une maladie, et ils ont oublié l'agent pathogène.
TL;DR - L'article "panique productivité" de Bloomberg cerne parfaitement les symptômes mais rate complètement le diagnostic. La panique ne vient pas du fait que l'IA code trop vite. Elle vient de l'absence de spécifications. Coder à l'instinct sans contrats produit du code avec 2,74x plus de vulnérabilités de sécurité, rend les développeurs expérimentés 19% plus lents (alors qu'ils se croient 24% plus rapides), et crée un écart perception-réalité de 40%. La solution n'est pas de ralentir vos agents. C'est de leur dire quoi construire avant qu'ils commencent à construire.
Les symptômes sont réels. La cause est ailleurs.
Je gère mes propres projets. Pas de VP qui me respire dans le cou sur les taux d'utilisation des agents. Et pourtant, pendant la majeure partie de 2025, l'IA m'a rendu plus lent.
Pas sur le papier. Sur le papier, tout avait l'air incroyable. Des fonctionnalités livrées en quelques heures. Les commits qui s'empilent. Le git log ressemblait à celui d'une équipe de cinq personnes. Mais je passais plus de temps à déboguer qu'à construire. Je lisais du code que je ne reconnaissais pas dans mes propres repos. Je passais le mardi à réparer ce que la session "productive" du lundi avait cassé.
Si vous avez été dans cette boucle, vous savez déjà que l'article de Bloomberg touche dans le mille.
Une étude UC Berkeley a suivi une organisation de 200 personnes et a découvert que même quand les employés déléguaient du travail aux agents IA, ils travaillaient plus longtemps. Les chercheurs appellent ça "l'expansion des tâches". L'IA crée de la production, la production crée du nettoyage, le nettoyage crée des heures sup. Un VP chez DocuSketch a dit à Bloomberg qu'il avait besoin de "quelques interactions IA de plus avant de se coucher", ce qui ressemble à de l'addiction mais se lit comme de la peur si vous vous êtes déjà inquiété de prendre du retard sur un outil que tout le monde semble déjà maîtriser.
Donc oui. La panique est réelle.
Mais Bloomberg s'arrête à "les agents créent de la pression" et ne pose jamais la question qui suit : pourquoi plus de production crée plus de travail ?
Parce que la production n'a pas de spec. C'est toute la réponse. Un agent sans contraintes, c'est un dev junior avec une énergie infinie et zéro contexte. Il va produire. Il va produire avec confiance. Et ce qu'il produit sera presque juste, ce qui est pire que faux, parce que vous ne vous en rendrez compte qu'en production.
Bloomberg ne dit jamais ça. En partie parce que Bloomberg est un média financier et le public visé n'est pas l'ingénieur qui débogue à 2h du matin, c'est l'investisseur qui recalibre un portefeuille. Cet article est sorti six jours après que Claude Code Security ait fait chuter les actions cybersécurité de 5-9%. Le timing n'est pas du journalisme. C'est du contexte de marché.
Et en partie parce que nommer la vraie cause, "personne n'écrit de specs avant de prompter", ça fait un titre barbant. "Panique Productivité" vend des abonnements. "Écrivez de Meilleurs Prompts" non.
Bloomberg vend la panique. Personne ne vend la solution.
Les données que Bloomberg aurait dû mettre en avant
Tout le monde gagne à entretenir la panique. Les consultants "transformation IA" ont un nouveau marché. Les vendeurs de gouvernance ont un nouveau segment. Les médias financiers ont de l'engagement. Les devs seniors ont une raison de se sentir indispensables. Personne n'a intérêt à souligner que la solution est barbante.
Mais les données pointent vers le barbant quand même.
METR a mené une des rares études rigoureuses là-dessus, un essai contrôlé randomisé avec 16 développeurs open-source expérimentés sur 246 tâches réelles. Les développeurs utilisant les outils IA étaient 19% plus lents que sans. Mais voici la partie qui devrait vous terrifier : ils se percevaient comme 24% plus rapides. Ça fait un écart de 40% entre la réalité et ce que votre cerveau vous dit.
Je connais cet écart. J'ai vécu dedans. Du code apparaît à l'écran, votre cerveau enregistre "progrès", et vous sautez la vérification parce que tout semble rapide. Vous devenez votre propre pire département QA.
Veracode a testé du code généré par IA sur plus de 100 LLMs dans quatre langages. 45% contenaient des vulnérabilités de sécurité. 2,74 fois plus de vulnérabilités que le code écrit par des humains. Et pas parce que les modèles sont stupides. Personne n'avait spécifié les contraintes. Un LLM va joyeusement construire un flux de connexion sans limitation de débit, sans assainissement d'entrée, avec des identifiants en texte brut. On ne lui a pas dit de ne pas le faire. Donc il ne l'a pas fait.
CodeRabbit a analysé plus de 10 millions de pull requests et a trouvé que le code IA produit 2,25 fois plus de bugs de logique métier. "Logique métier" c'est littéralement ce qu'une spécification définit, des trucs comme les permissions utilisateur, les cas limites, les transitions d'état. Exactement le territoire que le codage à l'instinct évite parce que "l'IA va comprendre".
Et la propre étude d'Anthropic de janvier 2026 a trouvé que les développeurs utilisant l'IA scoraient 17% plus bas aux quiz post-tâche. Plus gros écart : les questions de débogage. On comprend moins ce qu'on livre. On a arrêté de définir ce qu'on attend avant d'appuyer sur entrée, et après on s'étonne que le résultat ne corresponde pas.
Aucun de ces chiffres ne dit "l'IA est dangereuse". Chacun d'eux dit "l'IA sans spec est dangereuse".
Bloomberg a confondu l'outil avec l'usage. Ces études ont des limites, METR c'était 16 développeurs, Veracode a testé des LLMs variés avec on ne sait quels prompts. Le propre suivi de METR de février 2026 suggère des accélérations à mesure que les outils évoluent, mais leurs données montrent aussi que l'écart de perception persiste, les développeurs ne peuvent toujours pas dire à quelle vitesse ils vont vraiment. Les chiffres exacts sont discutables. La direction ne l'est pas.
Comment je suis devenu étranger dans ma propre base de code
Voici ma vraie histoire et elle est plus bête que vous ne pensez. Le gars qui écrit sur les contrats de prompt s'est fait démolir en n'en utilisant pas. Les cordonniers les plus mal chaussés, tout le cliché.
Je construisais un tableau de bord pour une de mes apps SaaS. Du standard : page de métriques, backend Convex, auth Clerk, quelques graphiques. Le genre de truc que j'ai fait assez de fois pour être dangereux. C'était avant que je formalise les contrats de prompt, à l'époque où chaque session était du pur instinct.
J'ai ouvert Claude Code en mode instinct total. Pas spécifié l'architecture. Pas listé les librairies que je voulais. Juste "construis-moi un tableau de bord avec auth et graphiques." Vingt minutes plus tard, page qui marche. Données qui coulent. Graphiques qui s'affichent. J'avais l'impression d'avoir débloqué un code de triche.
Trois jours plus tard j'avais besoin d'ajouter un filtre. Fonctionnalité simple. Ça devrait prendre 10 minutes.
J'ai ouvert la base de code et j'ai trouvé TanStack Query partout.
Je n'utilise pas TanStack Query. Je n'ai jamais utilisé TanStack Query. Je savais à peine ce que c'était TanStack Query. Claude avait décidé que ma couche de récupération de données avait besoin d'un framework de cache et synchronisation que je n'avais jamais touché, l'avait câblé dans chaque composant, et avait construit toute la gestion d'état autour.
Le tableau de bord marchait. Je ne pouvais pas expliquer pourquoi. Je ne pouvais pas le modifier sans casser quelque chose parce que je ne comprenais pas les abstractions qui le tenaient ensemble. Ajouter un filtre de date signifiait comprendre les patterns d'invalidation de TanStack Query, et je googlais des concepts de base sur un outil dans mon propre projet comme un touriste qui lit un guide de conversation dans un pays où il est censé vivre.
Deux jours à apprendre un framework que je n'avais jamais choisi, pour modifier du code que j'étais censé avoir écrit, dans un projet que je suis censé posséder. En fait, laissez-moi reformuler ça. Deux jours à payer la taxe sur une décision que je n'avais jamais prise.
Une spec de trois lignes aurait tout évité : "Utilise fetch + hooks Convex pour les données. Pas de librairies de gestion d'état externes. Garde ça assez simple pour que je puisse le déboguer à 1h du matin sans documentation."
Ce n'était pas un cas isolé. Au cours des deux mois suivants j'ai tracké mes sessions. Le pattern était toujours identique. Lancer l'agent avec un objectif vague. Obtenir du code qui compile. Déployer. Découvrir l'écart entre ce que je voulais dire et ce que j'ai dit. Déboguer quelque chose dont je ne savais même pas que c'était là.
Le pire ce n'est pas le temps perdu. C'est la sensation. Vous l'avez construit mais vous ne le possédez pas. Votre repo ressemble à la maison de quelqu'un d'autre. Les données METR sur les développeurs qui pensent être plus rapides prennent soudain tout leur sens, vous croyez vraiment que vous livrez, jusqu'au moment où vous devez changer quelque chose.
L'agent n'était pas le problème. Mon prompt l'était.
La solution : des contrats, pas des conversations
C'est là que j'ai arrêté de traiter Claude Code comme un chatbot et que j'ai commencé à le traiter comme un entrepreneur qui va absolument carreler votre salle de bain en marbre si vous ne spécifiez pas céramique.
Avant chaque session : ce que l'agent doit produire, ce qu'il ne doit pas toucher, comment je vérifie le résultat. J'appelle ça un contrat de prompt. Pas parce que c'est légalement contraignant, mais parce que ça force la même clarté. Les deux parties connaissent le périmètre. Personne ne se réveille avec un framework qu'il n'avait pas invité.
J'ai construit le framework complet des contrats de prompt après assez de ces désastres. La version courte : objectif, contraintes, format de sortie attendu, conditions d'échec. Quatre champs. Quatre-vingt-dix secondes à écrire. Économise des heures de débogage et zéro framework surprise.
Je ne suis pas le seul à arriver à ça.
Un papier arXiv de janvier 2026 a documenté une équipe de services financiers qui est passée du prompting IA libre à des workflows spec-first avec des contrats OpenAPI. Le temps de cycle d'intégration a chuté de 75%. L'IA n'est pas devenue plus intelligente. Les humains sont devenus plus clairs.
Kent Beck, le gars derrière TDD et Extreme Programming, a publié "Augmented Coding: Beyond the Vibes" où il a construit une librairie B+ Tree compétitive en production en Rust en utilisant du prompting IA structuré. Son cadrage : le codage à l'instinct produit du code qui marche. Le prompting structuré produit du code que vous pouvez maintenir. Il y a une différence, et ça se voit au troisième mois.
Et c'est exactement ce que Red Hat a trouvé. Les projets codés à l'instinct frappent systématiquement un mur vers le troisième mois. Le code marche, puis il ne marche plus, et personne ne peut expliquer pourquoi parce que les prompts originaux ont disparu et la base de code n'a pas d'intention documentée. Juste de l'instinct. De l'ancien instinct. De l'instinct mort.
Les contrats de prompt ne vous sauveront pas en exploration. Quand vous ne savez vraiment pas ce que vous construisez, suivez votre instinct. Rapide, pas cher, jetable. Le problème commence quand l'instinct devient le défaut pour tout, y compris le code qui va en production et le code dont d'autres personnes dépendent. Ce n'est pas de l'exploration. C'est de la négligence avec des étapes supplémentaires.
Les specs ne sont pas de la bureaucratie. C'est le chemin le plus court vers la livraison.
Les cadavres que le codage à l'instinct a laissés derrière
Bloomberg couvre le capital. Ces histoires parlent d'artisanat. Panique différente, même cause racine.
Daniel Stenberg maintient cURL, l'outil qui tourne sur environ 20 milliards d'appareils. En juillet 2025 il a documenté que 20% des soumissions de bug bounty étaient du slop généré par IA. Confiant, détaillé, complètement fabriqué comme rapports de vulnérabilité. Chacun bouffait 3-4 membres de l'équipe sécurité pendant des heures. Le taux de confirmation s'est effondré sous les 5%. Il a fermé tout le programme en janvier 2026. Ses mots : "Du temps et de l'énergie complètement gaspillés tout en sapant notre envie de vivre."
Les rapporteurs n'étaient pas malveillants. Ils ont pointé une IA sur cURL sans spec de ce qui constitue une vraie vulnérabilité. Le modèle a généré des ordures plausibles. Même pattern que mon désastre TanStack, juste à l'échelle de l'écosystème.
Puis il y a Adam Wathan, qui a créé Tailwind CSS. Janvier 2026 : 75% de son équipe d'ingénierie, licenciée. Tailwind était plus populaire que jamais, plus de téléchargements, plus de projets, plus d'adoption. Revenus en baisse de 80%. Trafic docs en baisse de 40%. Les outils IA ont mémorisé Tailwind et génèrent les classes inline, donc plus personne ne visite les docs. Le modèle économique n'a pas échoué. Il a été consommé par l'IA sans attribution, contexte, ou paiement. J'y pense souvent en fait, parce que ça veut dire que vous pouvez gagner le jeu de l'adoption et quand même perdre 💀
Mitchell Hashimoto, co-fondateur de HashiCorp (qui a construit Terraform et Vagrant), gère Ghostty, un émulateur de terminal. En janvier 2026 il se noyait dans les pull requests drive-by générées par IA. Peu d'effort, non revues, cassées. Sa réponse : bans permanents. Son cadrage : "Ce n'est pas une position anti-IA. C'est une position anti-idiot."
Trois cas. Trois domaines. Une structure : production générée sans définition de ce que "bon" veut dire. Code sans contrats. Rapports sans critères. PRs sans standards.
L'IA a produit du volume. Les humains se sont noyés dedans. Bloomberg n'a couvert aucun de ça parce que Stenberg qui ferme un bug bounty ne fait pas bouger les cours. Mais si vous construisez des trucs, c'est la panique qui compte vraiment.
Si vous voulez voir la structure plutôt que l'instinct appliquée aux outils, le même principe tient : définissez l'interface avant de construire la fonctionnalité.
Ce que Bloomberg aurait dû écrire
La "panique productivité" n'est pas un problème d'IA. C'est un problème de transition. Nous sommes dans la phase où tout le monde a l'outil et personne n'a la méthode.
Bloomberg ne nomme pas ça parce qu'un article sur la panique sans solution génère plus d'engagement qu'un article pratique avec une solution. Décrire l'anxiété, vendre l'abonnement, passer à autre chose. C'est le modèle. Un article diagnostique avec un remède est moins partageable qu'un qui laisse chaque lecteur projeter sa propre peur dessus.
Pensez à ce que "fatigue IA" décrit vraiment. Le VP de DocuSketch qui dit qu'il a besoin de plus d'interactions IA avant de se coucher n'est pas accro. Il a peur. Si je ne maîtrise pas cet outil, quelqu'un qui le fait prendra ma place. Bloomberg cadre ça comme un problème de bien-être parce que "travailleurs terrifiés par l'obsolescence" se vend moins bien au public C-suite qui paie l'accès Bloomberg Terminal.
La seule vraie réponse à la remplaçabilité c'est la compétence. Pas la panique. Pas plus d'heures. Pas plus de prompts avant de se coucher.
La compétence ça veut dire savoir comment diriger l'outil, pas juste comment le faire tourner. Ça veut dire écrire une spec de trois lignes avant de lancer un agent. Ça veut dire posséder vos choix d'architecture au lieu de les découvrir trois jours plus tard dans le framework de quelqu'un d'autre. Ça veut dire traiter l'IA comme un entrepreneur, pas comme un associé.
Ce n'est pas compliqué. C'est juste pas viral 🤷♂️
La panique est réelle. Le diagnostic est faux. Et l'article est le produit.
J'écris sur ce qui marche vraiment quand on construit avec des agents IA, pas de hype, pas de "10x votre productivité" à la con, juste les trucs que j'ai testés et les trucs qui ont cassé. Le bouton s'abonner est juste là si c'est votre truc.
*Cette image de couverture est générée par IA parce que mes compétences en design ont atteint leur pic en centrant une div en 2019 et ça a été la descente depuis.
Dans un monde où l'IA génère du code à toute vitesse, la vraie question est : avez-vous les bons garde-fous pour guider vos agents ?