L'IA ne supprime pas les goulots, elle les déplace

Il y a une promesse implicite derrière chaque démo d’agent : « tu vas coder plus vite ». C’est vrai, et c’est à côté de la plaque. Écrire le code n’a jamais été la partie lente.

Quand je regarde mes propres sessions plutôt que les captures d’écran marketing, le tableau est moins glorieux et bien plus utile.

Ce que disent les chiffres (les miens, pas ceux d’un keynote)

Sur 267 sessions tracées : 62 % durent moins de dix minutes. La session longue et immersive avec l’agent, celle qu’on imagine, est minoritaire. Le travail agentique réel, c’est beaucoup de courtes interactions.

Sur les sessions que je score, 53 % portent une friction « mauvaise approche » — l’agent (ou moi, en le briefant) part sur une piste qui ne tient pas, et l’essentiel de la session sert à s’en rendre compte et à réorienter. Et une session sur sept, environ, produit effectivement un commit. Le reste, c’est de l’exploration, du cadrage, des allers-retours.

Ces nombres viennent d’un seul dev, d’une stack précise, sur une durée qui lisse les cas isolés (niveau de certitude : mesuré, pas ressenti). Les tiens seront différents. Ce qui généralise, ce n’est pas le pourcentage — c’est la direction.

Le goulot a déménagé

Avant, le point lent était l’écriture : produire le code correct, ligne à ligne. L’agent a pulvérisé ça. Résultat, le blocage s’est déplacé vers trois endroits que personne ne met sur une slide :

• Le cadrage. Formuler le problème assez précisément pour que l’agent ne parte pas de travers. La moitié de mes sessions ratées se jouent là, dans les trente premières secondes.
• La gestion du contexte. Décider ce que l’agent doit voir, et surtout ce qu’il ne doit pas voir. Trop de contexte le noie, trop peu l’aveugle.
• Le pivot. Reconnaître qu’un run part mal et l’abandonner — au lieu de s’acharner à rattraper une mauvaise approche parce qu’on y a déjà mis dix minutes.

Aucun de ces trois n’est un problème de vitesse de frappe. Ce sont des compétences de jugement. C’est là qu’est passé le travail difficile.

Un exemple, volontairement générique : un refactor où l’agent choisit une abstraction plausible mais fausse. La session ne sert pas à écrire — elle sert à comprendre pourquoi c’est faux et à le rediriger. Le code sort vite ; c’est le discernement qui prend le temps. C’est ça, la verification tax : relire du code qui ressemble dangereusement à du code correct.

Pourquoi « donnez Claude à tout le monde » ne suffit pas

C’est le pont avec l’adoption en équipe, et il compte. Si le goulot était l’écriture, distribuer un abonnement à chacun réglerait le problème. Mais le goulot est le jugement — cadrer, contextualiser, savoir abandonner. Ça, un accès ne le donne pas ; ça s’apprend, ça se transmet, ça se documente.

C’est exactement pour ça que la plupart des déploiements IA déçoivent : on a résolu la partie qui n’était pas le problème, et laissé intacte celle qui l’était. L’enablement qui marche n’est pas « voici l’outil » — c’est « voici comment on cadre, comment on décide qu’un run est mort, comment on ne se noie pas dans son propre contexte ».

Ce que ça change concrètement

Arrête de mesurer ta productivité IA en lignes générées ou en heures « passées avec l’agent » — ce sont des métriques vanité. Mesure ce qui corrèle avec du travail livré : combien de tes sessions aboutissent, combien partent mal et pourquoi. Le jour où tu traces ça, tu arrêtes d’optimiser la vitesse de frappe (déjà résolue) pour travailler le cadrage (le vrai sujet).

L’agent m’a rendu plus rapide à écrire du code. C’est précisément la partie qui comptait le moins.