AIDiveLe playbook que personne n'a mesuré
Anthropic a publié un playbook du SDLC AI-native pour Claude Code : six étapes, chacune terminée par un fichier commité, enseignées dans un cours gratuit. Sa thèse centrale : le code n'est plus le goulot d'étranglement, et c'est la chaîne d'artefacts commités qui gère ce qui l'est devenu. Le document lui-même ne contient aucune mesure, ni durée, ni coût, ni benchmark. Nous avons mené le premier test chronométré sur un vrai dépôt : seize sessions Claude Code chronométrées, chaque gate chiffré, et un verdict qui coupe la chaîne en deux. En chemin, un correctif de deux minutes passé dans toute la chaîne a mis un prix sur la cérémonie, et notre propre déploiement a été bloqué deux fois, dont une par quatre lignes de shell.
Le playbook et le banc d'essai
Le banc d'essai : seize sessions Claude Code chronométrées, environ $12 de calcul, un vrai dépôt. Le playbook compte six étapes : plan, conception, build, test, déploiement, maintenance. Chaque étape se termine par un fichier commité, et l'étape suivante le lit : intent, spec, plan, la pull request, le rapport d'incident. Les commits sont la piste d'audit. Anthropic l'enseigne dans un cours gratuit de 14 leçons, environ une heure, écrit pour des entreprises dotées de gates de review ; nous avons testé ce qui survit au contact d'un seul développeur.
Le dépôt est l'app de démonstration RealWorld (Express, TypeScript, Prisma, Postgres) : un vrai projet avec de vrais tests, et une suite cassée dès le clone (quatre suites qui passent, 14 tests verts, deux secondes d'exécution). Ce bug devient plus tard le groupe témoin. La règle de notation : un gate est rentable quand sa sortie change ce qui est livré, pour moins que ce qu'il coûte.
Le ticket d'entrée est un fichier de mémoire à la racine du dépôt : commandes, conventions, architecture, les erreurs que le modèle répète, le tout en moins d'une page. Le nôtre a été écrit et commité en 63 secondes pour $0.44. Une réserve honnête sur la méthode : les exécutions headless compressent les entretiens du playbook en prompts uniques.
Plan : intent.md en vingt-neuf secondes
Le premier gate capture l'idée avant que quiconque conçoive quoi que ce soit. La demande de fonctionnalité : les lecteurs veulent masquer les auteurs qui inondent leur fil. Le playbook appelle le résultat une proto-spec, écrite avec le modèle, détenue par vous, et admet trois origines : une idée, un ticket déposé ou une alerte d'incident. Le template comporte cinq sections dont les titres font tout le travail de réflexion : problème, résultat proposé, utilisateurs et systèmes concernés, contraintes, questions ouvertes. La boucle de travail tient en cinq gestes : décrire, brainstormer, générer à partir du template, corriger, commiter.
| intent.md | durée | coût |
|---|---|---|
| Fonctionnalité mute-authors | 29 s | $0.18 |
| Suite de tests cassée | 39 s | — |
La valeur se trouve en bas, dans les questions ouvertes : que deviennent les favoris d'un auteur masqué ? Ses pages restent-elles accessibles ? Ce sont des décisions qu'un agent de code prendrait sinon en silence, désormais écrites et datées. Le fichier est commité, donc l'auteur et l'horodatage survivent au chat, et le product owner corrige le brouillon avant de l'accepter. L'objectif d'Anthropic pour cette étape est une élicitation en heures plutôt qu'en semaines ; en solo, elle prend moins d'une minute.
Conception : la spec signale son propre prérequis
Le gate deux transforme l'intent en spec avec un seul prompt du cours : lire l'intent, produire une spec d'exigences et de conception, appliquer les skills disponibles, ces skills censés porter votre marque, votre politique de sécurité et d'UX. Deux minutes plus tard, nous avions environ 2 300 mots de spec compétente : endpoints, modèle de données, comportement du fil, cas limites. Elle a même consigné ce qu'elle ne pouvait pas satisfaire, exactement comme le prompt le demande.
Le rebondissement se trouve dans ses points signalés, écrits par le modèle lui-même : « C0. No org skills available. This spec has not been checked against any policy. » Toute la prémisse de l'étape suppose des fichiers qui n'existent pas dans la plupart des configurations ; les vidéos explicatives passent ce prérequis sous silence, l'agent, lui, l'a mis par écrit. Le second signalement était plus bénin : les valeurs par défaut des questions ouvertes doivent être validées par le produit avant le build.
La leçon est stricte sur l'appariement (la spec et l'intent sont commités ensemble, un humain approuve le passage au build), et il y a une facture de lecture : environ 12 minutes de temps de product owner par spec. Le playbook suit même la reprise de travail : les commits de spec datés après le début du build comptent contre vous. Dans une équipe qui a encodé ses politiques, ce gate est l'endroit où elles s'exécutent. En solo, vous payez une promesse que votre configuration ne peut pas encore tenir.
Build : plan mode, TDD, et ce que la boucle vérifie vraiment
Le gate trois, c'est le Plan Mode, et l'exigence est brutale et utile : un ingénieur qui n'a jamais vu la conversation doit pouvoir implémenter à partir du plan seul. Le Plan Mode impose lui-même la moitié lecture : le modèle ne peut pas modifier de fichiers tant que le plan n'est pas accepté. Le nôtre a fait environ 4 000 mots en quatre minutes, nommant les fichiers modifiés, l'ordre du travail, les risques et la preuve, et consignant trois écarts étiquetés par rapport à la spec, qui reviennent plus tard en review.
Le build tourne sur une boucle : écrire le test qui échoue, le faire passer, une seule cible, tout au vert, sinon la tâche n'est pas terminée. La boucle est protégée (un agent qui corrige du code ne doit pas affaiblir la vérification de ce code) et associée à un vérificateur : un second contrôle dans un contexte neuf, non influencé par la session qui a écrit le code.
| Résultat du build | valeur |
|---|---|
| Temps agent | ~9 min, 91 turns |
| Coût | ~$2 |
| Changement | 15 fichiers, table Mutes, deux endpoints, les deux fils filtrés |
| Tests | 5 suites, 50 tests, tous verts lors d'une réexécution indépendante |
| Merge au premier passage | oui |
L'astérisque : le vert prouve ce que la boucle contient, rien de plus. Le end-to-end n'a jamais été exécuté : il exige un serveur actif et une base peuplée, et une boucle visant des faux périmés brillerait tout aussi vert. À l'échelle d'une équipe s'ajoutent des sessions parallèles dans des worktrees (deux ou trois est le plafond annoncé) ; nous ne l'avons pas testé.
Deploy : la review, et le gate qui a dit non
Le gate de déploiement a deux couches, et les deux nous ont dit non. La couche un lit le diff selon une politique écrite à la racine du dépôt : trois passes (bugs, sécurité, conformité à la spec et au plan), « Important » réservé au comportement cassé, aux données qui fuient ou à une politique violée, cinq nits au maximum et le reste résumé sous forme de compteur : la politique plafonne son propre bruit. Deux minutes de review, $0.80, et elle a lancé les vrais contrôles : tests, build, lint par rapport à la base de référence consignée dans le plan, formatage sur neuf fichiers. Verdict : zéro constat Important, six nits, dont un au-dessus du plafond, résumé. Elle a terminé par une ligne que nous n'avions pas demandée : cet agent n'approuve pas, l'approbation reste à un code owner humain derrière la protection de branche.
La couche deux est le gate lui-même. Nous avons demandé le déploiement ; le modèle a refusé de lui-même, parce que la fonctionnalité n'était pas sur la branche de livraison. C'est du jugement, pas de l'application de règle. Nous avons donc mergé et redemandé : quatre lignes de shell ont répondu en 14 secondes : bloqué, autorisation de release requise. Le code de sortie 2 arrête l'appel d'outil et la raison revient au modèle. Le côté pipeline a reçu le même traitement : un build cassé trié en headless en 11 secondes pour $0.13, il a lu le log, nommé la cause exacte et proposé le diff sans toucher à un fichier. Le déterministe bat le poli ; un hook ne vaut que ce que vaut son pattern, et le nôtre ne correspondait qu'à un seul script.
La taxe des gates
Même bug, même départ cassé, deux routes : l'expérience témoin. Route un : corriger directement. Route deux : toute la chaîne, de l'intent au build.
| correctif direct | chaîne complète | multiplicateur | |
|---|---|---|---|
| Temps réel | 2:13 | 11:31 | ×5.2 |
| Coût | $0.70 | $3.46 | ×4.9 |
| Turns | 40 | 169 | — |
| Résultat | suite verte | suite verte | identique |
La facture machine n'est que la petite moitié. La chaîne a écrit environ 5 500 mots d'artefacts pour un correctif d'une ligne : environ 27 minutes de lecture humaine pour un diff qu'on parcourt en une. La chaîne convertit du temps d'écriture en temps de lecture ; voilà la taxe des gates.
Le playbook ajoute une charge récurrente : les evals continues. Vingt à cinquante tâches réelles, rejouées à chaque changement de configuration : chaque cas est une vraie tâche passée, avec le prompt tel qu'il était, exécutée depuis le commit précédant le changement, avec une acceptation vérifiable. Écrire cinq cas depuis l'historique a pris cinq minutes ; les exécuter correctement est moins simple : notre premier harnais a visé deux cas sur le mauvais commit, et les deux agents l'ont signalé au lieu de simuler une réussite. À environ une minute par cas, une suite complète coûte jusqu'à une heure de temps agent par exécution, et chaque incident de production est censé rejoindre la suite comme eval de régression permanente. Dans une équipe réglementée, cette lecture est le livrable ; en solo, c'est du surcoût.
Verdict : trois gates sur six paient
Trois gates sur six se rentabilisent :
| Étape | verdict | preuve |
|---|---|---|
| Plan | garder | 40 s achètent les questions que personne n'a posées |
| Build | garder | plan mode + boucle de tests ont livré 50 tests verts |
| Deploy | garder | review à $0.80 avec de vrais contrôles, blocage déterministe en 14 s |
| Conception | à sauter en solo | vous facture des politiques que vous n'avez pas encodées |
| Test (evals continues) | peut attendre | jusqu'à une heure par exécution, facile à mal viser |
| Maintenance | non prouvé | exige des semaines de télémétrie de production |
Maintenance est élégante sur le papier (des scripts déterministes surveillent des bandes de contrôle, et un dépassement écrit un nouveau fichier intent), mais la prouver demande une télémétrie de production que nous n'avons pas. Le document d'Anthropic, comme l'a dit un analyste, ne contient aucune mesure nulle part ; voici les premiers chiffres, avec les limites évidentes : un dépôt, un développeur, une journée.
Les données extérieures disent que la pression est réelle. Faros a suivi plus de 10 000 développeurs dans plus de 1 200 équipes : les équipes à forte adoption mergent 98% de pull requests en plus, le temps de review augmente de 91%, et la pull request moyenne plus que double de taille. Le dernier rapport DORA va dans le même sens : débit en hausse avec l'IA, stabilité en baisse. La review devient le goulot, et le playbook vise exactement là. Des variantes communautaires réduisent déjà la chaîne à deux décisions humaines : l'une fournit des templates et un registre de gates, l'autre ne garde les humains qu'à la conception et au test. Adoptez les trois gates qui paient, et étendez-vous aux autres quand votre équipe le fera. La phrase de conclusion d'Anthropic est la bonne épitaphe : la boucle continue de tourner, le jugement humain reste au-dessus.
