Anthropic dévoile son playbook SDLC natif IA : ce que ça change pour vos projets
Anthropic vient de publier un playbook complet sur le SDLC natif IA, porté par Boris Turnney, responsable de Claude Code et de l'équipe Entropy. Le SDLC, ou Software Development Life Cycle, c'est ce cycle classique qu'on connaît tous : planification, conception, construction, tests, déploiement et maintenance. Sauf que ce cycle, pensé pour des humains, est en train d'être profondément redessiné par les agents IA. Le playbook contient 14 leçons et décrit précisément comment l'équipe d'Anthropic utilise ce cycle pour construire des applications avec Claude Code.
Ce qui change fondamentalement, c'est la vitesse. Avant les agents IA, chaque étape avançait à la vitesse humaine. Le plus gros goulot d'étranglement, c'était la construction. Avec l'IA, cette phase de construction se réduit considérablement. Le cycle entier devient beaucoup plus court. Et c'est exactement là qu'Anthropic concentre ses recommandations : raffiner la collecte des exigences, améliorer la revue du code généré par l'IA, et mieux gérer la mise en production.
La planification : passer des réunions aux sessions de questionnement
Dans le SDLC traditionnel, la planification implique de parler aux parties prenantes, aux clients, aux chefs de projet, et d'écrire des exigences à la main. C'est long, c'est flou, et il manque toujours des morceaux.
Avec le SDLC natif IA, l'IA peut poser les questions elle-même. Grâce à des compétences comme le grooming skill, l'agent IA vous interviewe. Il plonge en profondeur dans chaque aspect du plan, parcourt les arbres de décision branche par branche, jusqu'à atteindre une compréhension partagée entre vous et l'agent.
Une fois que l'agent a collecté tout le contexte, Anthropic recommande de capturer ces conversations, décisions et éléments de contexte dans un fichier unique : le fichier intent MD. Ce fichier est lisible par un humain et actionnable par une machine. C'est le point de bascule entre le flou initial et le travail exécutable.
Deux clarifications importantes ici. D'abord, le fichier intent MD n'est pas limité à un par projet. Vous pouvez avoir plusieurs fichiers intent MD, un par changement, dans un dossier dédié appelé dossier intent. Ensuite, ce fichier n'a pas besoin d'être stocké dans le dépôt de code. Si vous utilisez Jira, GitHub Projects ou Linear, la source de vérité peut vivre directement dans le ticket. Vous n'êtes pas obligé de stocker un fichier statique dans le repo.
Anthropic fournit un template pour ce fichier intent MD. Il commence par l'intention, le titre, le problème, les résultats proposés, les utilisateurs affectés, les contraintes et les questions ouvertes. C'est une structure claire qui force à clarifier le pourquoi avant de passer au quoi.
La conception : transformer le pourquoi en quoi
Une fois le fichier intent MD créé, on passe à l'étape de conception. Cette étape convertit tout ce qui est dans l'intent en une spécification propre, le fichier spec MD.
La différence entre les deux est simple mais essentielle. Le fichier intent MD clarifie le pourquoi : pourquoi on fait ce changement. Le fichier spec MD définit le quoi : les exigences techniques précises et le comportement attendu.
Anthropic fournit un prompt clair pour convertir l'intent en spec. Mais ce n'est pas une obligation. Si vous utilisez déjà des compétences comme les Matt Poc skills ou les Superpower skills, vous pouvez utiliser vos propres templates et formats. L'important est d'avoir un processus de conversion fiable, pas de copier aveuglément le prompt d'Anthropic.
La construction : le plan MD comme pont vers l'exécution
Après l'intent et la spec, on crée le fichier plan MD. Ce fichier prend tout ce qui a été discuté avant, l'intent et la spec, et le convertit en tâches actionnables que l'agent IA peut suivre, soit en parallèle, soit étape par étape.
Le template d'Anthropic pour le plan MD contient plusieurs sections : le titre du plan, les fichiers qui vont être modifiés avec leur emplacement exact, l'ordre du travail, les risques à considérer, et la preuve que le travail est terminé. Cette preuve peut être un fichier de test qui vérifie certaines zones du code et démontre que tout fonctionne.
Le prompt fourni par Anthropic prend l'intent MD et la spec MD, applique les compétences, et génère un plan MD complet. Mais là encore, il n'y a pas de solution universelle. Si vous utilisez déjà des frameworks de développement pilotés par les specs, comme les compétences de Matt Poc ou le skill d'écriture de plan de Superpower, utilisez-les. Ces outils prennent la spec et la convertissent en plan d'implémentation avec une structure propre : objectif, architecture, stack technique, contraintes globales, et structure des tâches. Chaque tâche précise le fichier à modifier, l'interface, et une checklist de ce qu'il faut faire en premier, en second.
La recommandation d'Anthropic est claire : utilisez ce qui fonctionne déjà chez vous, et servez-vous de ce playbook comme référence pour identifier les zones à raffiner dans votre cycle actuel. Ne remplacez pas tout d'un coup.
Les tests : le feedback loop avant tout
Avant de passer à l'implémentation, Anthropic insiste sur le développement piloté par les tests (TDD). Le principe : écrire les tests d'abord, avant le code. Créer la vérification avant de créer l'implémentation.
L'objectif est de créer une boucle de feedback. Tant que les tests échouent, l'IA corrige le code qu'elle a écrit jusqu'à ce que les tests passent. La citation exacte d'Anthropic est limpide : « Donnez à Claude une boucle de feedback. Donnez toujours à Claude un moyen de vérifier son propre travail, que ce soit des tests, un build, du linting ou une capture d'écran. Et la session vérifie son propre travail, corrige ses propres erreurs avant que nous ayons à les voir. »
On délègue donc à l'automatisation des tests avant qu'un humain n'intervienne pour vérifier les changements. Plusieurs compétences de TDD existent déjà, comme celles de Matt Poc ou de Superpower, qui font exactement cela. La version Anthropic ajoute le linting et le build. Le build ici n'est pas du code, c'est simplement une compilation pour vérifier que le logiciel est exécutable, que les sorties ont du sens, et que le programme se comporte correctement.
L'évaluation : ne jamais casser ce qui marche
Après les tests, vient l'évaluation. Anthropic recommande de mettre en place un eval skill. Pourquoi ? Parce que quand vous changez de modèle, le nouveau modèle pourrait négliger des choses qui fonctionnaient déjà. Il faut savoir exactement ce qui marche.
La recommandation est de prendre 20 à 50 tâches réelles que Claude a déjà complétées et de les utiliser comme évaluation pour le nouveau modèle. Ça peut être des pull requests, des issues GitHub que vous suivez. L'IA lit ces tâches, et grâce au skill creator, vous configurez l'évaluation pour vérifier que le nouveau modèle arrive à faire ce qui était fait avant.
Anthropic suggère aussi d'exécuter ces évaluations en intégration continue, dans votre pipeline CI/CD. Un workflow GitHub peut être créé pour évaluer si le skill fonctionne toujours après un changement de modèle ou de règles. Pour chaque évaluation, Claude tourne en mode headless avec tous les outils autorisés, et vérifie si le modèle ou les règles modifiées satisfont l'évaluation définie.
La revue de code : un fichier review MD comme standard
Une fois l'évaluation en place, l'étape suivante est la revue des pull requests par l'IA. Le point clé ici : faire écrire à Claude un fichier review MD unique qui définit exactement ce qu'il faut filtrer.
Ce fichier contient des instructions de revue : passer les trois tests, taguer chaque découverte (bugs, sécurité, conformité), distinguer ce qui est important de ce qui est mineur, et surtout, ne pas signaler les fichiers générés ou les fichiers temporaires.
La vraie valeur ajoutée : un humain, par exemple le tech lead de l'équipe, écrit ce review MD pour définir la procédure standard de revue des pull requests. L'IA suit ensuite ce fichier pour revoir ce qu'elle écrit.
La recommandation pratique : prenez les pull requests passées où des humains ont laissé des commentaires, et laissez l'IA analyser ces commentaires pour identifier les patterns récurrents. Ces patterns alimentent le review MD, pour que chaque nouvelle pull request soit revue selon les mêmes critères.
Les hooks : des garde-fous avant la production
La revue ne suffit pas. Anthropic recommande d'ajouter des hooks pour approuver les actions avant que l'IA ne fusionne une pull request en production.
Concrètement, quand l'IA essaie de faire quelque chose de sensible, comme toucher une base de données de production ou fusionner une pull request, un hook peut bloquer l'action. Par exemple, quand un agent reviewer envoie des commentaires à un agent builder pour corriger la pull request, le builder peut exécuter un linter pour vérifier le formatage, s'assurer que les tests passent, ou empêcher l'écriture de credentials dans le code.
Les hooks servent à empêcher les bugs ou les données sensibles d'atteindre la production. C'est une couche de garde-fous qui protège le système sans ralentir le flux de travail.
Le déploiement : avant et après la mise en production
Le déploiement se divise en deux phases : avant et après.
Avant le déploiement, le workflow appelle Claude en mode headless pour examiner le build complet, identifier pourquoi il a échoué, créer une pull request et la soumettre pour revue. Le processus de déploiement reprend ensuite, avec les corrections, jusqu'à ce que la fonctionnalité soit prête pour la production.
Après le déploiement, Claude appelle un outil de statut. Ça peut être Datadog, Sentry, ou n'importe quel outil de suivi de performance. Claude examine les métriques pour détecter tout problème dramatique après la sortie de la fonctionnalité. Si quelque chose casse, Claude peut effectuer un rollback, trouver la cause racine, créer une pull request et relancer le processus de déploiement.
La maintenance : boucler la boucle avec les métriques
La dernière étape du cycle est la maintenance. C'est là que le playbook boucle sur les métriques.
Un fichier YAML d'exemple regarde les 30 derniers jours de données. Claude examine les logs, identifie les erreurs récurrentes, les requêtes de données qui deviennent lentes, ou les points où les utilisateurs abandonnent l'application. Quel que soit le problème, Claude crée un nouveau fichier intent MD et repart dans le cycle SDLC complet pour améliorer l'application.
C'est la boucle qui se referme. Le SDLC natif IA n'est pas un processus linéaire avec une fin, c'est un cycle continu où chaque itération alimente la suivante.
Points clés à retenir
- Le SDLC natif IA raccourcit massivement la phase de construction, ce qui oblige à raffiner la collecte des exigences, la revue de code et la mise en production.
- Le fichier intent MD capture le pourquoi d'un changement, tandis que le spec MD définit le quoi technique. Le plan MD convertit le tout en tâches actionnables.
- Le développement piloté par les tests est non négociable : donnez toujours à Claude une boucle de feedback pour vérifier son propre travail avant qu'un humain ne regarde.
- Les évaluations avec 20 à 50 tâches réelles protègent contre les régressions quand vous changez de modèle.
- Un fichier review MD écrit par un humain standardise la revue des pull requests et évite de signaler les fichiers générés.
- Les hooks bloquent les actions sensibles comme toucher une base de production ou écrire des credentials dans le code.
- Le déploiement se fait en deux temps : avant, Claude corrige les builds échoués ; après, il surveille les métriques et peut rollback en cas de problème.
- La maintenance boucle sur les métriques : Claude analyse les logs des 30 derniers jours, identifie les problèmes, et crée un nouvel intent MD pour repartir dans le cycle.
Le playbook d'Anthropic n'est pas un ensemble de règles rigides à appliquer aveuglément. C'est un cadre de référence pour identifier où l'IA peut automatiser chaque étape du cycle de développement, et où l'humain doit garder le contrôle. La clé est de prendre ce qui fonctionne déjà dans votre organisation et de le raffiner avec ces principes, pas de tout remplacer d'un coup.