The AI-Native SDLC playbook: How to transform your software development lifecycle with AI—stage by stage
Guide long-form d'Anthropic signé Louis Claxton (équipe Applied AI), publié le 21 août 2026 sur le blog claude.com : 40 minutes de lecture annoncées, environ 64 000 caractères, présenté comme un recueil de plays tirés du travail de l'équipe avec ses clients. (A) Le diagnostic : le code n'étant plus le goulot, celui-ci se déplace vers les étapes situées à gauche et à droite du build (plan, revue/test, déploiement), les contrôles ligne-à-ligne cessent de tenir dès que l'agent écrit l'essentiel du diff, et le coût de gouvernance monte, les exceptions passant encore par des comités périodiques. (B) La réponse : six étapes (Plan, Design, Build, Test, Deploy, Maintain) organisées en boucle et non en chaîne, chacune se terminant par un artefact committé que la suivante lit — intent.md, spec.md, plan.md, le diff et ses tests, la PR et ses constats, l'enregistrement d'incident. (1) Le savoir institutionnel devient des fichiers versionnés : CLAUDE.md, skills, REVIEW.md, bands.yaml. (2) La gouvernance se scinde en deux couches, la skill posée comme contrôle consultatif et le hook comme couche déterministe derrière elle.
Louis Claxton, de l'équipe Applied AI d'Anthropic, publie le 21 août 2026 un guide de mise en œuvre d'un cycle de vie logiciel « AI-native ». Le point de départ est un déséquilibre : les organisations écrivent désormais du code à une vitesse inconcevable un an plus tôt, mais les processus qui l'entourent — portes d'approbation, revues, passations, politiques — n'ont pas bougé. Le SDLC traditionnel a été conçu pour un monde où l'écriture du code était l'étape la plus longue et la plus coûteuse ; ses contrôles supposent en outre que chaque geste est posé par un humain.
Trois conséquences en découlent. Le goulot se déplace vers les étapes qui tournent encore à vitesse humaine, de part et d'autre du build. Les contrôles cessent d'être applicables : relire chaque ligne avait un sens quand une personne l'avait écrite. Et le coût de gouvernance augmente, les exceptions passant par des comités périodiques.
The loop keeps running. Human judgement stays above it.
— Louis Claxton , claude.com
La réponse conserve les objectifs de contrôle et change le mode d'exécution. Le processus devient une boucle, avec l'IA embarquée en chaque point, organisée en six étapes — Plan, Design, Build, Test, Deploy, Maintain — décomposées en plays suivant tous la même grille, jusqu'à la mesure. Le fil conducteur est l'artefact committé. L'intention est captée par son auteur d'origine comme intent.md ; exigences et design fusionnent en une session produisant spec.md, contrainte par les skills de marque, sécurité, conformité et UX ; le build démarre en plan mode et fige plan.md avant toute écriture de code. La chaîne de commits tient lieu de piste d'audit.
Le savoir institutionnel devient des fichiers versionnés : CLAUDE.md pour le contexte du dépôt, les skills pour les politiques transverses, REVIEW.md pour la doctrine de revue, bands.yaml pour les seuils de production. La gouvernance se scinde en deux couches, la skill étant un contrôle consultatif et le hook la couche déterministe qui bloque ou demande une approbation. Un exemple de managed settings détaille clé par clé ce que chaque réglage achète en contrôle, du refus de lecture des secrets à la version plancher imposée.
L'étape Maintain ferme la boucle : un script déterministe surveille une métrique, et le franchissement d'une bande invoque Claude sans humain dans le chemin d'appel, à une autonomie fonction du palier. Ce que l'agent trouve est réécrit en intent.md et repart dans le cycle. Claude Tag, en bêta publique sur Slack, étend le schéma aux incidents arrivant par messagerie. Aucun résultat chiffré n'est avancé : le guide livre des indicateurs à mesurer et nomme leur source.
À retenir
Trois conséquences quand le build cesse d'être la contrainte. (1) le goulot se déplace vers les étapes qui tournent encore à vitesse humaine (plan, revue/test, déploiement) ; (2) les contrôles deviennent inapplicables — relire chaque ligne avait un sens quand un humain l'avait écrite ; (3) le coût de gouvernance monte, les exceptions passant par des comités périodiques. Exemple donné : une équipe sécurité dimensionnée pour du débit humain, face à quoi soit la file de revue s'allonge, soit le code part sous-revu.
Le fil conducteur est l'artefact committé. , pas l'outil : chaque étape se termine en écrivant dans le contrôle de version, la suivante commence en le lisant, et la chaîne de commits est la piste d'audit. Le .md domine en amont parce que le product owner et l'agent lisent le même fichier ; à partir du build, l'artefact est le code et ses traces.
Déclencheurs en cascade. un intent.md accepté déclenche la passe exigences/design, un spec.md approuvé déclenche le plan mode, une PR mergée déclenche le pipeline, une bande franchie en production écrit l'intent.md suivant. On commence en promptant chaque étape à la main ; l'état cible est la boucle où chaque artefact accepté arme la barrière suivante.
Skill vs hook — la distinction porte l'édifice de contrôle. la skill rend l'application de la politique probable sans obliger une session à s'y conformer ; le hook est déterministe et bloque l'action. Une politique qui doit toujours tenir a besoin d'un hook ou d'une passe de revue derrière la skill. Corollaire : un hook qui demande une approbation humaine appartient au déploiement, pas au build, où il remettrait une personne sur le chemin critique de toutes les sessions parallèles.
Systèmes légataires. pour chaque artefact, nommer un système comme source de vérité (le dépôt, ou Jira/ServiceNow avec les .md en copies de travail), le reste ne détenant qu'un lien. Le simple chaînage — l'artefact porte l'ID de l'enregistrement, l'enregistrement porte le SHA du commit — est donné comme barre minimale de démarrage.
Test. la boucle de rétroaction (tests, build, diff de capture d'écran) tourne pendant toute la tâche ; le sous-agent vérificateur est une passe finale à contexte neuf, pour que le verdict ne soit pas teinté par les hypothèses qui ont produit le code. Pour un correctif, écrire d'abord le test qui échoue, le committer, puis interdire à l'agent de le modifier via un hook. Les evals sont le pendant AI-native des portes QA : 20 à 50 tâches réelles rejouées à chaque changement de CLAUDE.md, de skill ou de hook, chaque incident devenant un eval permanent.
Maintain, la fermeture de boucle. la détection reste déterministe (moyenne et écart-type sur fenêtre glissante, règles Western Electric, script versionné et testé, aucun modèle impliqué) ; Claude n'est invoqué qu'une fois la bande franchie, et le palier fixe ce qu'il peut faire — 1σ journalise, 2σ diagnostique en lecture seule, 3σ propose (PR ou runbook pré-approuvé). Le rollback est désigné comme le chemin qui doit être le plus répété du pipeline.
⚠️ Ce que le texte ne chiffre pas : aucun résultat quantifié, ni gain de délai ni taux d'adoption. Les nombres du guide sont des paramètres de mise en œuvre (20-50 evals, deux ou trois sessions parallèles pour commencer) ; les résultats restent des indicateurs à mesurer soi-même, dont la source est nommée à chaque fois (git log, métadonnées de PR, export OpenTelemetry, DORA, outil de suivi d'incidents).
À relier. [[sfeir-sdlc-ia-cycle-11-phases-2026-06-16]] (découpage concurrent, en onze phases) et [[sfeir-code-review-anneau-contraintes-2026-07-30]] (l'anneau de contraintes autour de l'agent, dont hooks et revue sont ici deux anneaux distincts).
Chiffres clés
performance de livraison, indicateur retardé du play CI/CD