Tout le monde code plus vite avec l’IA. Pourquoi votre boîte, elle, n’avance pas ?

Demandez à n’importe quel développeur de votre équipe : il est plus productif qu’il y a un an. Sur 400 000 sessions de Claude Code analysées, la valeur d’une tâche type a grimpé de 25 % en sept mois [1].

Alors pourquoi l’organisation, elle, n’avance pas plus vite ?

Le piège de la productivité individuelle

Un ingénieur doit écrire une note technique pour une migration de base de données. Avant, ça lui coûtait un après-midi : lire le code, peser les options, écrire, supprimer, réécrire. Le résultat tenait en quelques lignes, et chaque mot avait survécu au contact de son cerveau.

Aujourd’hui, il colle le contexte dans un modèle. Quelques minutes plus tard, il récupère un plan trois fois plus long que ce qu’il aurait écrit à la main [2].

Il est plus productif, non ? Sauf que les relecteurs, eux, ouvrent un document interminable avec cette odeur d’IA reconnaissable. Et comme c’est généré, ils doivent tout vérifier : la note dit que le job traite les événements séquentiellement — vraiment ? Qu’elle touche neuf tables — c’est bien neuf ? Quand un collègue écrit ça à la main, on lui fait confiance, parce que quelqu’un a compté et mis son nom dessus.

On va plus vite en refilant la partie lente — la lecture, la compréhension réelle — à celui qui vient après. Une chaîne de Ponzi ?

Le temps n’a pas disparu. Il a été transféré [2]. Et comme un document a un auteur et plusieurs lecteurs, le raccourci de l’un devient le problème de tous les autres.

L’expertise ne disparaît pas — elle compose

Voilà le contre-intuitif. On nous avait vendu l’IA comme le grand niveleur : plus besoin de savoir coder, l’agent s’en charge. Les données disent autre chose.

Dans une session type, l’humain prend la plupart des décisions de planification (quoi faire), l’agent celles d’exécution (comment le faire). Et plus la personne apporte d’expertise métier, plus l’agent abat de travail par instruction [1]. L’expertise ne devient pas obsolète : elle se transforme en levier.

Autre signal fort : en sept mois, la part des sessions passées à déboguer a chuté de près de moitié, et l’usage a glissé vers du bout-en-bout — déployer, faire tourner, analyser des données [1]. On ne demande plus à l’IA de réparer ; on lui confie des chaînes entières. Mais ce sont les experts qui savent où poser les garde-fous.

La discipline d’ingénierie, ce vrai accélérateur

C’est là que la nuance compte. Votre première feature a pris dix minutes. Votre cinquième, deux jours — l’IA n’arrêtait plus de casser ce qui marchait [3]. La courbe que tout le monde finit par toucher.

La réponse n’est pas un meilleur prompt, c’est de la méthode. Le Specification Driven Development — écrire la spec avant de laisser l’agent coder — fait partie de ces réflexes d’ingénierie qui tiennent une fois que de vrais utilisateurs dépendent du produit [3].

Même chose pour les evals. Construire un outil dopé à l’IA, c’est facile ; savoir s’il améliore vraiment la vie de celui qui l’utilise, beaucoup moins — surtout quand la sortie change à chaque exécution [4]. La parade ? Des fixtures comme états de départ, et le diff git comme source de vérité de ce qui a réellement changé [4]. Bref, du test sérieux appliqué à du non-déterministe. Encore une compétence d’ingénieur, pas de prompteur.

Le modèle n’est plus le différenciateur

Et le plus gros mythe à tomber, c’est celui du modèle roi. L’idée reçue veut que l’intelligence réside dans le modèle, le harnais n’étant qu’une tuyauterie minimale. Faux, selon l’auteur de Dirge : une bonne partie de ce qui rend un agent efficace tient à la façon dont le harnais répond aux attentes du modèle — le guider avant qu’il agisse, corriger ses erreurs mécaniques, gérer le contexte intelligemment [5]. Avec ce travail, un modèle open source bon marché se met à se comporter comme un modèle bien plus coûteux.

Et inversement : un Qwen local n’est pas un « Opus du pauvre », c’est un outil différent. Des reçus d’une vraie petite entreprise le montrent — il paie sa carte graphique en deux ou trois mois sur des cas précis, mais reste impossible à laisser tourner sans supervision, avec ses boucles infinies et son risque d’hallucination dès qu’on le quantize trop [6]. Le bon réflexe n’est pas « quel est le meilleur modèle ? » mais « quel outil pour quel usage ? ». Encore un jugement d’expert.

Le modèle, tout le monde y a accès. Le harnais, la spec, les evals, le bon outil au bon endroit : voilà ce qui se travaille, et ce qui se transfère mal d’une équipe à l’autre.

Alors la vraie question pour 2026 n’est peut-être pas « est-ce que mon équipe va plus vite ? », mais : qui, dans votre organisation, paie la facture de la vitesse des autres ?

---

Sources

1. Agentic coding and persistent returns to expertise
2. You Got Faster. Your Company Didn’t.
3. The First Step to Keep AI Coding Fast as Your Project Grows
4. Writing my first evals
5. Making budget models punch above their weight with a smart Rust harness
6. Local Qwen isn’t a worse Opus, it’s a different tool

Pour aller plus loin

• Brain the Size of a Planet: Are LLMs Thonking too Hard? — plus d’effort de raisonnement n’est pas toujours mieux : un benchmark qui invite à choisir le bon réglage plutôt que le plus gros.
• The founder’s playbook: Building an AI-native startup — comment des équipes pensent l’organisation autour de l’IA dès le départ, et pas l’inverse.
• 2026 State of AI Agent Pricing Report — où va vraiment la valeur quand les agents deviennent un poste de coût à part entière.
• Building TREX: Code execution and artifact generation for AI code review — quand la revue de code ne se contente plus de lire le diff mais exécute réellement le programme.

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.