Du code à la méthode : Anthropic dévoile sa vision du génie logiciel sous IA à travers un guide en six étapes et ses propres configurations en clair. Ce qui est intéressant c'est qu'on sort de la documentation classique fonctionnelle d'un produit pour remonter sur le process. Analyse pas à pas d'un changement de paradigme qui bouscule le SDLC traditionnel.
Au moment où j'écris cet article, le constat est dorénavant quasi unanime : le code n'est plus le goulot d'étranglement.
Les PRD, les rituels d'estimation, les revues de sécurité produit existent parce que le build dure des semaines, et il faut donc construire un ensemble de rituels qui s'assure que ce temps de build est utilisé de la meilleure manière possible. Mais si le build tombe à quelques heures, tout ce process perd son sens. Cependant il ne disparaît pas complètement, il déménage vers les étapes qui tournent encore à vitesse humaine. Sur le sujet de la sécurité par exemple : une équipe sécurité est dimensionnée pour un débit humain, et quand les agents multiplient le volume de code, soit la file d'attente s'allonge, soit le code part en production sous-revu.
Ce playbook d'Anthropic formalise cette évolution de process d'un mode séquentiel avec des gates humains à une vraie "loop" où le passage entre les étapes se fait de manière beaucoup plus fluide, rapide et automatisée. Pour les Product people de la première heure, c'est un fantasme qui se réalise. Nous avons tous rêvé de cette boucle de feedback quasi permanente sans jamais vraiment réussir à l'implémenter.
Leur réponse tient en six étapes, de la planification à la maintenance. Un fil les traverse : chaque étape se termine en écrivant un fichier dans le contrôle de version, la suivante commence en le lisant, et la suite des commits fait office de piste d'audit.
| Étape | Cycle traditionnel | Cycle AI-native |
|---|---|---|
| Plan | Besoins recueillis en comité, distillés en ateliers, rédigés à la main | L'agent synthétise les irritants depuis la source et les consigne dans un fichier d'intention |
| Design | Spec rédigée par des analystes, retraduite par des designers | Besoins et design fusionnés en une session, encadrée par les standards de l'entreprise écrits en skills |
| Build | Code et tests écrits à la main, documentation produite après coup | Code et tests générés, savoir collectif maintenu dans des fichiers de contexte |
| Test | Portes qualité aux frontières d'étape | Évaluations continues tissées dans l'implémentation |
| Deploy | Revue humaine de chaque ligne, gouvernance en cycles de validation inégaux | Revues agentiques empilées, humain sur le critique, gouvernance appliquée au moment où l'agent agit |
| Maintain | Des humains surveillent la production | Des agents surveillent, et toute dérive repart en amont sous forme d'intention |
Voici notre analyse de chacune de ces étapes.
- Plan : le fichier d'intention, et ce qui devrait le précéder
- Design : la fin du mur entre besoins et design
- Build : les skills d'un côté, les sessions parallèles de l'autre
- Test : la qualité du code n'est pas celle du produit
- Deploy : la gouvernance devient du code
- Maintain : une boucle qui surveille la mécanique
- Ce que le playbook ne fera pas à votre place
- Questions fréquentes
Plan : le fichier d'intention, et ce qui devrait le précéder
Chez Anthropic, tout commence par un fichier d'intention. Quelqu'un a une idée, un ticket arrive ou une alerte se déclenche, et cette personne discute avec l'agent au lieu de chercher un créneau avec l'équipe produit. Elle en ressort un texte court dans ses propres mots, que le Product Owner, le terme employé par Anthropic dans son article, même si on pourrait parler de Product Manager ou de Product Builder, corrige avant de le committer : le problème, le résultat attendu, les utilisateurs et systèmes concernés, les contraintes, les questions ouvertes. Ce qui prenait plusieurs semaines de recueil et de raffinage tient en quelques heures.
Dans le cycle classique, celui qui repère un irritant doit trouver quelqu'un pour l'écrire avec lui, et le texte qui arrive chez l'engineering se trouve à trois poignées de main de ce qu'il voulait dire. Là, l'auteur reste l'auteur. Le Produit garde le dernier mot, mais il arbitre au lieu de se faire scribe.
En revanche, ce que le playbook ne prévoit à aucun moment, c'est d'aller vérifier que le problème existe. Leur seul indicateur de qualité pour cette étape est le taux de survie des intentions, la part de celles que le Produit accepte plutôt qu'il ne ferme. Le critère porte sur l'accord d'une personne, pas sur l'existence du besoin. Rien n'empêche pourtant de confier à des agents une partie du travail de discovery, analyse de verbatims ou synthèse d'entretiens : le playbook ne s'y intéresse pas.
Sur le terrain, cette omission coûte cher. Pierre Sur, Product Builder chez Thiga, a passé six mois chez un acteur MedTech et en tire la leçon principale de sa mission : des specs floues donnent du code qui tourne et ne sert à rien, tandis que des priorités mal posées donnent des fonctionnalités inutiles, livrées en quelques heures au lieu de quelques semaines. À l'inverse, un PRD nourri de personas, de cas limites et d'histoires utilisateur tirées de vrais entretiens lui a donné un prototype exploitable dès la première itération.
Design : la fin du mur entre besoins et design
Leur deuxième étape fait tomber le mur entre les besoins et le design. L'agent lit l'intention validée et produit une spec : parcours utilisateur, contrats d'API, modèle de données, critères d'acceptation. Il travaille sous la contrainte des skills qui portent les règles de marque, de sécurité, de conformité et d'expérience. Le Produit relit sans écrire, traite en priorité les points que l'agent a signalés comme problématiques, arbitre avec les propriétaires des politiques concernées, et décide du passage au build. À noter au passage, le playbook conserve toute la nomenclature classique, Product Owner, tech lead, platform engineer : il redistribue les tâches entre les rôles existants sans jamais envisager qu'ils fusionnent, là où le débat sur les frontières entre Forward Deployed Engineer, Product Engineer et Product Builder part de l'hypothèse inverse.
Cette séparation, celle entre la personne qui écrit ce qu'il faut faire et celle qui conçoit comment le faire, avait ses raisons de responsabilité. Elle était aussi lente et coûteuse : l'analyste formalisait le besoin, le designer le retraduisait en parcours, et il fallait un aller-retour de plus à chaque fois que la traduction s'éloignait de l'intention. Produire les deux dans la même session supprime le passage de main, donc la perte.
Leur choix de l'artefact de décision se discute davantage. La chaîne intention, spec, plan, diff, pull request est propre et auditable, et le markdown a un mérite certain : un diff de spec se relit comme un diff de code, donc les besoins passent par le même circuit de revue que l'implémentation. Le playbook connaît le prototype et lui réserve une place, celle du front-end maquetté à partir de l'intention avant export vers l'agent de code.
Le curseur peut se placer ailleurs. La spec cadre et donne à l'agent de quoi produire, mais la décision peut tout aussi bien s'appuyer sur quelque chose qui tourne, branché aux briques du SI et construit avec les composants d'interface de la maison : un Product Owner (ou plutôt Product Builder dans ce cas) ne défend pas la même chose devant son comité selon qu'il arrive avec un document validé ou avec un objet manipulable qui fait office de preuve de concept.
Build : les skills d'un côté, les sessions parallèles de l'autre
C'est l'étape la plus fournie du document, qui contient plusieurs idées intéressantes.
La meilleure, ce sont les skills. Le principe : prendre une règle appliquée de façon inégale aujourd'hui, une norme de sécurité ou une convention d'API par exemple, l'écrire dans un fichier dont l'en-tête indique quand il se déclenche, la ranger dans le dépôt ou la diffuser à toute l'organisation, et faire valider chaque évolution par le propriétaire de la politique comme il validerait du code. Le savoir cesse de vivre dans la tête de trois personnes, et l'agent l'applique sans qu'on ait à le lui rappeler à chaque session. Écrire ses propres skills est d'ailleurs ce que le POM-AI appelle traduire les standards de l'entreprise en skills.
Anthropic est honnête sur la limite, ce qui n'est pas si courant. Une skill reste un contrôle indicatif : elle rend l'application de la règle probable pendant l'écriture du code, rien n'oblige une session à s'y conformer. Pour une politique qui doit tenir sans exception, il faut un mécanisme déterministe derrière, un hook qui bloque ou une passe de revue qui vérifie à nouveau. Peu de vendeurs de framework écrivent noir sur blanc que leur brique principale ne garantit rien !
L'écosystème open source, lui, s'arrête plus tôt. Pierre Sur a passé une semaine sur BMAD en début de mission, dont six heures de configuration pour accoucher d'un PRD générique de qualité moyenne. Son verdict sur les frameworks du marché, BMAD, OpenSpec ou Speckit : tout s'arrête au code généré, personne ne parle de tests, de validation qualité ni de monitoring. Il a fini par construire ses propres briques, calibrées sur les contraintes du projet.
La partie contestable, c'est le travail en parallèle. Chaque session tourne dans son propre espace de travail Git, isolée des autres, et la seule chose qu'elles partagent est l'ingénieur qui les pilote. Deux ou trois pour commencer, avec pour plafond le nombre de flux qu'une personne peut relire correctement. Le métier devient l'orchestration.
Bien qu'Anthropic retienne une limite, la capacité de revue de chaque personne, la productivité individuelle explose dans ce modèle. Pour autant, cela ne doit pas être vu comme une invitation à réduire une équipe à une seule personne. Si la taille des équipes peut diminuer, certaines compétences doivent continuer à y être représentées, notamment pour des produits critiques.
À titre d'exemple, sur un outil interne de génération de données de démo pour des commerciaux, sans passé et sans enjeu, un Product Builder seul peut expédier un produit en quelques jours. Mais sur le backoffice MedTech de Pierre Sur, avec dix ans de code existant et une exigence de fiabilité supérieure à la vélocité, le bon dispositif était un PM entouré de deux développeurs rompus à l'IA : pour un tel produit, la one-man team reste une utopie.
Le rôle bouge autant que le process. Cinq concepts pour comprendre ce que l'IA change dans la fabrication d'un produit, avec les 5 mots-clés du Product Builder.
Test : la qualité du code n'est pas celle du produit
Anthropic déplace les checks de qualité. Dans le cycle classique, ils se posaient aux frontières d'étape : le code est fini, on teste, on valide, on passe. Chez eux, l'évaluation se tisse dans l'implémentation. L'agent écrit le test avec le code, et l'indicateur de référence devient la part de changements qui passent du premier coup. Une sorte d'Evaluation Driven Development en quelque sorte (ce qui parlera aux amoureux du TDD).
Le principe se défend sans difficulté. Les vérifications en fin de parcours étaient un héritage du temps où le contrôle coûtait cher : on regroupait les vérifications pour amortir la mobilisation d'une équipe QA. Ce calcul ne tient plus quand l'agent écrit le test en même temps que la fonction.
Là où le playbook laisse une zone floue, c'est sur ce qu'il appelle qualité. Tout ce qu'il mesure porte sur le code : le test passe, la chaîne d'intégration est verte, le changement franchit la revue du premier coup. Sauf qu'un produit peut cocher les trois cases et rater complètement sa cible ! Sur les produits reposant sur des LLMs, cette limite est encore plus nette, puisque la fiabilité en production dépend surtout de la couche qui entoure le modèle, ce que le harness engineering désigne précisément.
Chez TheFork, la fonctionnalité de recherche par IA a passé toutes les gates techniques du premier coup. C'est en entretien utilisateur que les équipes ont découvert le vrai problème : les gens ne comprenaient pas pourquoi tel restaurant leur était proposé. La correction, afficher une photo ou un extrait d'avis qui justifie le résultat, ne relevait d'aucun test automatisé. Aucun indicateur du playbook ne l'aurait signalée.
Deploy : la gouvernance devient du code
C'est l'étape où le playbook descend le plus bas dans l'implémentation.
La mécanique repose sur un des artefacts clés de Claude : les hooks. Ils interceptent l'action de l'agent avant qu'elle se produise et rendent un verdict : autorisé, soumis à approbation, ou bloqué avec le motif et la route à suivre pour obtenir le feu vert. Les hooks d'équipe vivent dans le repository et se relisent comme du code. Les non négociables vivent dans des réglages administrés que l'ingénieur ne peut pas désactiver. Leur configuration type pour entreprise régulée refuse la lecture des fichiers de secrets, coupe l'accès réseau depuis la ligne de commande, empêche l'agent de démarrer si le bac à sable ne s'initialise pas, et n'accepte que les extensions passées par la place de marché interne. Le principe qui tient l'ensemble : l'agent va jusqu'à la porte de la production et ne la franchit pas.
Le hook demande un arrêt, parce que c'est le seul dispositif du playbook qui sorte du probabiliste. Une skill rend l'application d'une règle probable, un eval mesure après coup avec une marge de tolérance. Un hook est du code qui s'exécute avant l'action et rend un verdict binaire. Anthropic indique d'ailleurs que pour une politique qui doit tenir sans exception, le skill ne suffit pas, il faut un hook derrière. La recherche académique s'est d'ailleurs emparée du sujet, avec des travaux qui cherchent à exprimer ces frontières humain-agent sous forme de protocole exécutable.
La revue suit la même logique d'empilement. Plusieurs agents passent sur le même diff avec des mandats différents, sécurité, performance ou style, et l'humain n'intervient que sur ce qui reste. Le playbook précise que l'agent ne relit pas son propre travail, ce qui évite le point aveugle.
Ce niveau de détail change quelque chose de concret pour les organisations contraintes. Le backoffice MedTech où intervenait Pierre Sur exigeait une traçabilité complète avec journal d'audit, de la pseudonymisation par défaut et une gestion fine des permissions. Faute de trouver ça dans les frameworks du marché, il a fallu écrire les garde-fous à la main, projet par projet, sans garantie qu'ils tiennent d'une session à l'autre. C'est le trou que les hooks et les réglages administrés viennent combler.
Maintain : une boucle qui surveille la mécanique
La dernière étape est la plus ambitieuse du document. Un script déterministe surveille une métrique dont il connaît la moyenne glissante et appelle l'agent dès que la bande de contrôle est franchie. Un écart-type, il journalise. Deux, l'agent diagnostique en lecture seule. Trois, il propose une correction par pull request. La boucle se referme sur elle-même : toute dérive détectée en production repart à l'étape Plan sous forme d'intention, et le cycle recommence.
Le mécanisme est astucieux, et les seuils progressifs évitent le piège du système qui s'affole au premier soubresaut. Reste à savoir ce qu'on lui donne à surveiller. Les trois exemples cités par le playbook, taux d'échec des tests, taux d'erreurs serveur après déploiement, temps de cycle des pull requests, mesurent la même chose : la santé technique de la chaîne de production. Un produit peut les garder au vert pendant des mois tout en perdant ses utilisateurs, et rien dans la boucle ne s'en apercevra.
Une autre dérive échappe à cette surveillance, et sur celle-là le playbook n'a pas l'excuse du périmètre puisqu'elle appartient bien au cycle de développement : le coût de fonctionnement. Un produit qui embarque des appels de modèle voit sa facture bouger toute seule. Un prompt système qui gagne du contexte à chaque itération, un usage qui décolle, et la dépense mensuelle glisse sans qu'aucun test échoue ni qu'aucune erreur serveur remonte. C'est pourtant le type de signal que leur bande de contrôle traiterait très bien : une moyenne glissante, un seuil, un agent qui va chercher d'où vient l'écart. Le playbook ne le propose nulle part, et sur les cinq étapes précédentes, aucun de ses indicateurs ne parle en euros.
Ce que le playbook ne fera pas à votre place
Là où les frameworks open source s'arrêtent au code généré, celui-ci va jusqu'aux fichiers de configuration, aux hooks qui bloquent une action avant qu'elle se produise, et aux réglages qu'un ingénieur ne peut pas contourner. Une organisation contrainte y trouvera de quoi laisser des agents travailler sans renoncer à sa traçabilité, ce qui n'était pas gagné il y a un an.
Son titre annonce sa limite : software development lifecycle. Un cycle de développement logiciel commence quand on sait quoi construire et s'arrête quand c'est en production. Personne n'attend d'un manuel de développement qu'il fasse de la discovery, et le reprocher au playbook serait de mauvaise foi. Le risque est ailleurs, chez celui qui le lira comme un modèle opérationnel complet, parce qu'il en a la forme et l'apparente exhaustivité.
Chez Club Med, où Thiga a déployé des agents dans les équipes Produit et Tech, rien n'a été branché avant que les équipes soient interrogées et leurs rituels observés pour trouver où ça frottait vraiment. Puis les processus ont été cartographiés, jaugés à leur complexité et à leur récurrence, et seulement après sont venus les ateliers de priorisation. Les tâches de contenu et de documentation sont passées de trois à cinq jours à une demi-journée. Aucune des six étapes du playbook ne décrit ce travail-là, et c'est lui qui a déterminé sur quoi les agents seraient braqués.
Les six étapes marchent. La question qu'elles ne posent jamais est celle de savoir si ce qu'on va construire mérite de l'être, et elle reste entière une fois le playbook adopté.
Questions fréquentes
Qu'est-ce que le SDLC ?
Le software development lifecycle désigne l'ensemble des étapes que suit une équipe pour transformer une idée en logiciel en production : planification, conception, développement, test, déploiement, maintenance. C'est un cadre de gestion du développement, distinct du cycle de vie du produit, qui englobe aussi la stratégie et la discovery.
Qu'est-ce qu'un SDLC AI-native ?
Un cycle de développement dans lequel les agents ne sont plus des outils d'assistance mais des participants de plein droit à chaque étape. Concrètement, les artefacts deviennent des fichiers versionnés lisibles par une machine, les standards de l'entreprise sont encodés en skills, la gouvernance s'exécute sous forme de contrôles automatisés, et l'humain intervient sur les décisions plutôt que sur la production.
Quelles sont les six étapes du playbook d'Anthropic ?
Plan, Design, Build, Test, Deploy, Maintain. Chaque étape se termine en écrivant un fichier dans le contrôle de version, et la suivante commence en le lisant, ce qui fait de la suite des commits une piste d'audit.
Quelle est la différence entre une skill et un hook ?
Une skill est un fichier d'instructions qui rend l'application d'une règle probable pendant l'écriture du code : c'est un contrôle indicatif. Un hook est du code qui s'exécute avant l'action de l'agent et rend un verdict binaire, autorisé ou bloqué. Pour une politique qui doit tenir sans exception, la skill ne suffit pas.
Le playbook d'Anthropic remplace-t-il un modèle opérationnel produit ?
Non. Il couvre le développement logiciel, donc ce qui se passe entre le moment où l'on sait quoi construire et la mise en production. Il ne traite ni la discovery, ni la validation du besoin, ni la mesure de la valeur pour l'utilisateur, qui relèvent d'un modèle opérationnel produit.
Faut-il un ingénieur ou une équipe pour piloter des agents ?
Cela dépend de la criticité du produit. Sur un outil interne sans enjeu, un Product Builder seul suffit. Sur du code existant avec une exigence de fiabilité forte, il faut une équipe réduite réunissant toutes les expertises nécessaires, la capacité de relecture d'une seule personne n'étant pas le bon critère.
Six étapes, ça ne dit pas par où commencer. Chez Club Med, la cartographie des irritants a précédé le moindre agent : le déroulé complet de la mission.
