J'ai lu le rapport d'Anthropic sur les tendances du codage agentique 2026 deux fois cette semaine. Une fois dans l'avion. Une fois à ma table de cuisine, un café qui refroidissait à côté du portable, et les deux fois j'ai hoché la tête à presque chaque page. Les specs battent le vibe coding. L'intention structurée bat un prompt d'une ligne et une prière, et le rapport le prouve avec de vrais chiffres : des équipes qui livrent des changements dans une base de code de 12,5 millions de lignes en une seule run de sept heures. Bon, et vrai. Ça mérite d'être célébré.
Ensuite j'ai lu les études de cas. Rakuten, Augment Code, Fountain, trois vraies entreprises qui font des affaires vraiment impressionnantes avec Claude Code, et j'ai remarqué un truc que le rapport ne dit jamais tout haut : chaque exemple commençait de la même façon, une équipe qui savait déjà exactement quoi construire, fait que l'agent n'avait jamais à trouver l'exigence, juste à en exécuter une qu'un humain avait déjà clouée avant même que l'agent ouvre un seul fichier. C'est ça, le signe qui trahit tout. Cherche dans tout le rapport un cas où l'agent sauve une équipe d'une mauvaise exigence. T'en trouveras pas.
C'est pas un coup bas contre Anthropic, ni contre GitHub, ni contre aucun des outils spec-driven qui se lancent ce trimestre. C'est juste des maths. Une spec, c'est l'encodage précis d'une décision que quelqu'un a déjà prise. Encode la mauvaise décision avec assez de précision, pis un agent va construire la mauvaise affaire plus vite, plus proprement, et avec plus de confiance qu'un humain n'en aurait jamais eu un mauvais mardi.
Qu'est-ce que le rapport 2026 d'Anthropic a vraiment prouvé sur les specs ?
Ça a prouvé que les specs marchent mieux que les prompts, net, et que les équipes avancent vite grâce à ça. Les ingénieurs utilisent maintenant l'IA dans environ 60 % de leur travail, selon le rapport, et environ 27 % de ce travail, c'est de l'ouvrage que personne n'aurait tenté sans un agent qui fait le gros du travail. Ça, c'est du vrai levier. Spec Kit à lui seul est devenu le point de départ par défaut pour les équipes qui se sont fait brûler une fois par le vibe coding pis qui ont décidé plus jamais, et AWS Kiro, BMAD, Tessl, pis Antigravity de Google ont tous sorti leur propre version de la même idée dans la dernière année. Le vrai constat du rapport, par contre, se cache une couche plus bas que le titre : la discipline de processus, ça s'accumule. Ça n'invente pas un jugement que personne n'avait.
Je veux être précis sur ce que cet écart veut dire, parce que c'est facile de le lire comme une plainte contre les outils. C'en est pas une. Une run de sept heures sur 12,5 millions de lignes, c'est un vrai exploit, pas une erreur d'arrondi, et personne chez Specira veut des agents plus lents. Le point est plus étroit et plus difficile à écarter : le rapport mesure une capacité d'exécution qui explose pendant que la délégation du jugement bouge à peine, et ce sont deux courbes différentes qui portent le même titre.
Pourquoi une spec écrite précisément peut-elle quand même livrer la mauvaise chose ?
Parce qu'une spec, c'est une traduction, pas un processus de découverte. Ça prend une décision qui existe déjà quelque part, dans la tête d'une partie prenante, dans une politique que personne n'a écrite, dans une hypothèse coulée dans le béton pendant une conversation de corridor trois semaines avant que quelqu'un ouvre Spec Kit, et ça la transforme en quelque chose qu'un agent peut exécuter. La traduction peut être impeccable. La chose traduite, elle, peut encore être fausse.
Une spec ne fait qu'encoder une décision que quelqu'un a déjà prise. Encode la mauvaise avec assez de précision, et un agent va la construire plus vite, plus proprement, et avec plus de confiance qu'aucun humain n'aurait jamais pu.
L'aéroport international de Denver voulait une chose : un système de tri de bagages automatisé, plus rapide que n'importe quelle équipe humaine, construit à l'origine pour United Airlines, pour une seule nouvelle aérogare, prêt pour l'ouverture d'octobre 1993. Ils ont engagé BAE Automated Systems pour le construire. Livré. Et de la vraie ingénierie en plus : dix-sept miles de rails, quatre mille chariots télécommandés indépendants, plus d'une centaine d'ordinateurs en réseau pour les empêcher de se rentrer dedans, le tout dans un chantier de deux ans que l'étude de cas appelle carrément "le système de bagages le plus complexe jamais construit" (SEBoK, étude de cas sur le système de Denver).
Puis, en plein chantier, la ville a élargi la portée : pas juste United, tout l'aéroport, toutes les compagnies. Personne n'est retourné refaire la découverte avec les transporteurs qui dépendaient maintenant du même système. L'ingénierie a tenu. Les bagages, eux, non. Écrasés, coincés, mal routés, parce que la spec n'avait jamais défini ce que "toutes les compagnies, tous les types de bagages, toutes les heures de pointe" voulait dire une fois le devis signé, scellé, gelé. Denver a ouvert seize mois en retard, et le retard à lui seul est habituellement chiffré à environ 560 millions de dollars, en plus du système lui-même (University of Maryland, étude de cas Denver).
Personne n'a livré une mauvaise spec. Ils en ont livré une excellente, pour une exigence qui avait cessé d'être vraie la semaine où la portée a changé, et personne n'est retourné demander ce que ce changement exigeait vraiment.
Qu'est-ce que l'écart de délégation mesure vraiment ?
Ça mesure exactement où le jugement habite encore, et le chiffre est pas subtil pantoute. Les chercheurs d'Anthropic ont trouvé que les ingénieurs utilisent l'IA dans environ 60 % de leur travail, mais rapportent pouvoir déléguer entièrement seulement 0 à 20 % des tâches sans supervision active. Cet écart, quarante points de large au plus serré, c'est pas une erreur d'arrondi ni une limite technique temporaire. C'est l'espace où quelqu'un doit encore décider ce que "correct" veut dire avant que l'agent puisse aller le chercher.
Anthropic a aussi trouvé qu'environ 27 % du travail assisté par IA, c'est de l'ouvrage que personne n'aurait tenté sans un agent qui fait le gros du travail. Mets ce chiffre à côté de celui de la délégation, pis un pattern apparaît. Les équipes tentent plus de choses, plus vite, avec la même bande passante de découverte qu'avant. Personne a ajouté du monde du côté de la cueillette des exigences juste parce que le côté code a eu un multiplicateur par dix. Plus de décisions se prennent chaque semaine. La rigueur par décision, elle, n'a pas suivi.
Je pensais que la solution, c'était juste de ralentir avant de spécifier. C'est pas tout à fait vrai, pis le dire de même blâme la mauvaise couche. Personne veut des agents plus lents, et personne devrait vouloir ça. La solution, c'est de rendre la couche de décision, celle qui se passe avant que Spec Kit ou Kiro ouvre un seul fichier, aussi rigoureuse que la couche d'exécution l'est devenue. Une découverte structurée qui roule en quelques jours. Pas des mois. Juste assez réelle pour attraper la mauvaise hypothèse avant que quelqu'un la formalise.
Qu'arrive-t-il quand l'exécution dépasse la découverte ?
La vitesse attend pas poliment que le jugement la rattrape. Quand générer du code est presque instantané et que la découverte demande encore de vraies conversations avec de vraies parties prenantes, de vraies priorités contradictoires, pis de vraies exceptions que personne n'a écrites nulle part, le mode d'échec naturel, c'est pas "l'agent écrit du mauvais code". C'est "l'équipe bâcle la seule étape qui n'a jamais été automatisable au départ", et elle livre la spec qui en résulte avec une confiance totale. On a déjà vu une version de ça arriver, quand l'industrie a déclaré le vibe coding mort et le développement piloté par specs comme son remplaçant, et j'ai expliqué pourquoi ce cadrage était juste à moitié vrai dans Le vibe coding est mort. Les specs sont toujours brisées. Passer des vibes aux specs a changé où l'ambiguïté habite. Ça l'a pas enlevée.
Où se situe vraiment le plafond de qualité ?
Il se situe à la découverte, point final, et chaque couche bâtie par-dessus hérite de la hauteur qu'on lui a donnée. Les outils spec-driven ont relevé le plancher : moins de fautes de frappe, moins de cas limites oubliés à l'intérieur d'une exigence donnée, une itération plus rapide une fois la décision verrouillée. Rien de tout ça relève le plafond, parce que le plafond n'a jamais été un problème de format. J'ai fait le même argument quand l'industrie était occupée à célébrer les chiffres d'AWS Kiro comme une victoire de qualité des specs, dans Vos specs sont le problème. Pas vos agents IA, et les données 2026 d'Anthropic, c'est la même leçon dans un rapport plus gros et mieux financé.
C'est la couche où Specira opère : au-dessus de la spec, avant le plan, au point où une exigence se fait soit valider par une découverte structurée et multi-experte, soit passer parce que la date limite tombait un mardi. Fais cette couche comme du monde, et Spec Kit, Kiro, Claude Code, n'importe quel outil qui gagne le prochain trimestre, tous héritent d'un plafond qui vaut la peine d'être construit. Fais-la mal, et tu viens juste d'automatiser la façon la plus rapide de livrer la mauvaise affaire.
Les specs ont gagné. Le plafond, lui, n'a pas bougé.
Le rapport 2026 d'Anthropic sur les tendances du codage agentique et la montée de Spec Kit prouvent tous les deux que les flux de travail structurés, pilotés par specs, battent le prompt improvisé. Aucun des deux ne prétend régler la qualité des exigences, et les chiffres du rapport montrent pourquoi : les ingénieurs utilisent l'IA dans environ 60 % de leur travail, mais peuvent en déléguer entièrement seulement 0 à 20 %, exactement l'espace où la découverte et le jugement habitent encore.
Une spec ne fait qu'encoder une décision que quelqu'un a déjà prise. Encode la mauvaise avec précision, et un agent la livre plus vite et avec plus de confiance qu'un prompt vague n'aurait jamais pu. Le plafond de qualité n'a jamais été le format de la spec. Il se fixe en amont, à la découverte, exactement là où Specira opère.
Je vais lire la version de l'an prochain de ce rapport aussi, et je m'attends à ce qu'elle dise quelque chose de semblable : l'exécution devient encore plus rapide, plus autonome, plus impressionnante. Tant mieux. Je l'espère, sincèrement. Mélange juste pas une spec plus rapide et plus confiante avec une spec validée, parce que le rapport qui prouve que les specs gagnent, c'est jamais le même rapport qui prouve que ton exigence était la bonne, et prétendre le contraire, c'est comme ça qu'un bon outil livre une mauvaise décision à vitesse record.
Quelles sont les questions les plus fréquentes sur les limites du développement piloté par specs ?
