Les organisations ont commencé à utiliser l'IA pour écrire du code à une vitesse impensable il y a un an, pourtant les processus entourant le code n'ont pas évolué au même rythme.
Le cycle de vie du développement logiciel (SDLC) est le processus qui fait passer un logiciel de l'idée à la production. La plupart des organisations suivent une version des six mêmes étapes, couvrant la planification, la conception, la construction, les tests, le déploiement et la maintenance des logiciels.
Les changements
Le tableau ci-dessous met en évidence les extrêmes du spectre entre le SDLC traditionnel et le SDLC natif de l'IA, pris en charge par Claude. La plupart des organisations se situent quelque part entre les deux colonnes.
| Étape | SDLC traditionnel | SDLC natif de l'IA |
|---|---|---|
| Planifier | Exigences recueillies par comité, distillées à travers des ateliers et des validations, rédigées à la main | Claude synthétise les points de friction directement à partir des sources et les consigne dans intent.md, qui est lisible par l'humain et exploitable par la machine |
| Concevoir | Spécification rédigée par des analystes, interprétée par des concepteurs | Exigences et conception compressées en une seule session de travail avec un agent, guidée par des standards encodés sous forme de Compétences, versionnés dans Git |
| Construire | Les tests et le code sont écrits à la main, et la documentation est rédigée après le développement principal | Les tests et le code sont générés par l'IA, et le savoir institutionnel est maintenu sous forme de fichiers CLAUDE.md versionnés et lisibles par machine, ainsi que de Compétences |
| Tester | Points de contrôle qualité aux frontières des étapes | Évaluations continues tissées à travers l'implémentation |
| Déployer | Les humains relisent chaque ligne de code, et la gouvernance se fait lors de cycles de revue, souvent de manière incohérente | Des couches de revue agentique, la revue humaine étant réservée au code réglementé et critique. La gouvernance est appliquée au fur et à mesure que l'IA agit, avec des hooks comme portes d'approbation |
| Maintenir | Les humains surveillent la production pour détecter les bugs | Des agents surveillent les déploiements en production. Toute bande de contrôle franchie est diagnostiquée et réinjectée dans la boucle sous forme d'un nouveau intent.md |
Les humains restent responsables de chaque décision qui requiert un jugement.
Comment fonctionnent les plays
Les plays constituent le cœur du playbook et sont regroupés en six étapes non linéaires (Planifier, Concevoir, Construire, Tester, Déployer, Maintenir), qui couvrent ensemble l'intégralité du cycle de vie.
Chaque play couvre :
- Ce qui change
- Comment démarrer
- Des étapes concrètes de mise en œuvre
- Des considérations de gouvernance
- Comment mesurer si cela a fonctionné
Chaque play nomme ses dépendances sous « Prérequis », que le graphe de dépendances illustre davantage.
Le graphe de dépendances des plays. Les plays de la rangée supérieure n'ont aucun prérequis ; une flèche pleine pointe vers les plays qui s'appuient sur lui, une flèche pointillée signifie que cela aide mais n'est pas requis.
Choisissez votre premier play
Les plays sont modulaires, et les organisations peuvent choisir de prioriser la transformation de différentes étapes à différents moments en fonction de leurs besoins spécifiques.
Les six plays de la rangée supérieure du graphe ci-dessus n'ont aucun prérequis :
- Planifier : Capturer sous forme d'intent.md
- Construire : Le mode plan de Claude Code comme point de départ par défaut
- Construire : Le CLAUDE.md
- Construire : Les Compétences comme savoir institutionnel
- Tester : Donner à Claude une boucle de rétroaction
- Déployer : Les hooks comme portes d'approbation