Anthropic a publié un document intitulé « le cycle de vie de développement logiciel AI-native », détaillant publiquement en six phases le processus de développement que l'entreprise a réorganisé en interne autour de Claude. Le point de départ du document est posé sans détour : la génération de code n'est plus le goulot d'étranglement ; les processus traditionnels étaient conçus au rythme d'humains écrivant du code à la main, si bien que le point de blocage s'est simplement déplacé.
Les six phases sont, dans l'ordre, la planification, la conception, la construction, les tests, le déploiement et la maintenance, et la méthode de chacune a été réécrite. La planification, qui passait par des réunions de recueil des besoins et des documents rédigés à la main, devient une conversation avec Claude qui produit un intent.md — le document affirme que cela fait passer le cycle de plusieurs semaines à quelques heures. La conception produit un spec.md en une seule session et fait tourner une vérification de politique. La construction commence par un plan.md avant de passer à l'implémentation proprement dite. Les tests n'attendent plus aux frontières entre phases — l'évaluation continue est directement intégrée au processus d'implémentation. Le déploiement est remplacé par une revue automatisée en couches, doublée d'un contrôle par les Hooks. La maintenance, elle, passe d'une réaction passive aux alertes à une détection automatique qui génère un nouvel intent.md et boucle vers le point de départ.
Ce qui relie ces six phases, ce sont des fichiers, pas des réunions. L'intent.md est transmis au spec.md, le spec.md au plan.md, puis viennent la pull request et le résultat de la revue, et enfin la fiche d'incident referme la boucle vers l'intent.md. Le document résume cette chaîne en une phrase : chaque phase livre un artefact que la phase suivante vient lire.
Quatre dispositifs de gouvernance
Les Skills portent le savoir institutionnalisé. Des éléments comme les normes de sécurité des API ou la charte de marque sont couchés dans .claude/skills/ ; quand la politique change, il suffit de la modifier une fois de façon centralisée, et les ingénieurs récupèrent automatiquement la nouvelle version dès leur prochaine session. L'exemple cité dans le document est une skill nommée secure-api-review, chargée de surveiller l'authentification, la validation des entrées et la journalisation d'audit.
Les Hooks assurent un contrôle déterministe, sans aucune voie de contournement manuel. En phase de construction, ils bloquent les modifications des paquets de dépendances gelés et imposent l'exécution du formatage ; en phase de déploiement, une mise en production exige l'autorisation d'un release manager — sans elle, le processus est bloqué net avec le code de sortie exit 2.
CLAUDE.md est la mémoire de l'équipe, limitée à une page : commandes de build, conventions, architecture, erreurs récurrentes. La règle d'entretien donnée par le document est très pragmatique — dès qu'une même erreur se reproduit une seconde fois, elle y est consignée.
Les evals servent de tests de non-régression. Un jeu d'évaluation de 20 à 50 tâches réelles tourne à chaque changement de configuration, avec en plus une exécution planifiée chaque nuit ; chaque incident de production est transformé en eval permanente, et le taux de réussite sert directement de condition de fusion.
Comment une fonctionnalité de suivi de statut de sinistre parcourt tout le processus
Le cas déroulé dans le document est une fonctionnalité en libre-service de suivi de statut de sinistre. Les opérations rédigent d'abord un intent.md exposant le problème, les utilisateurs et les contraintes ; une fois que le responsable produit l'a examiné et approuvé, le processus entre en phase de conception ; Claude applique des skills d'UX et de sécurité pour générer un spec.md ; un ingénieur passe en plan mode pour obtenir un plan.md, puis Claude Code réalise l'implémentation, et la pull request est fusionnée dès qu'elle franchit le hook de revue.
Les contraintes sont écrites explicitement dans le plan : l'interface claims-core est plafonnée à 50 requêtes par seconde, si bien que le plan.md signale la nécessité d'une mise en cache ; aucune information permettant d'identifier une personne ne peut être ajoutée pendant la session ; l'authentification reprend le dispositif existant. Une autre équipe, celle du service de paiement, dispose d'un CLAUDE.md qui précise : Java 21, Spring Boot 3, Lombok interdit, les montants doivent utiliser BigDecimal et non double, et les versions de dépendances sont gérées par l'équipe plateforme, sans droit d'y toucher.
L'automatisation en phase de maintenance est échelonnée sur trois seuils. En prenant pour exemple le taux d'échec des tests de CI : la référence est calculée sur une fenêtre glissante de 30 jours ; à 1 sigma, on se contente de consigner ; à 2 sigma, Claude reçoit un accès en lecture seule pour poser un diagnostic ; ce n'est qu'à 3 sigma qu'il est autorisé à ouvrir une pull request ou à déclencher un runbook préapprouvé. Le script de détection d'anomalies est lui-même déterministe — il applique les règles de Western Electric pour trancher, sans passer par un modèle.
La liste des indicateurs trahit qui est vraiment visé
Les indicateurs avancés comprennent le délai entre la première conversation et la soumission de l'intent.md, le délai entre la soumission et la première revue, le nombre de sessions d'agents menées en parallèle, et le taux de réussite en CI. Les indicateurs retardés comprennent le taux d'approbation des intent.md, le taux de réussite de la première implémentation, la tendance du nombre de remarques relevées lors des revues de pull requests, le taux de récurrence des incidents de production, et le nombre de pull requests fusionnées par ingénieur et par semaine.
S'y ajoutent deux parcours de conformité correspondants : l'un fait de Jira ou de ServiceNow le registre faisant foi, le markdown ne servant que de copie de travail resynchronisée vers l'ancien système via un connecteur MCP ; l'autre traite le dépôt comme unique source de vérité, les anciens systèmes se contentant de référencer le SHA du commit. La piste d'audit est reconstituée à partir de quatre canaux : l'historique Git, les fils de discussion des pull requests, les journaux de comportement des agents exportés via OpenTelemetry, et les journaux d'autorisation/blocage des Hooks.
Rien de tout cela ne vise le développeur individuel. Calcul rapide : une organisation d'ingénierie de deux à trois cents personnes qui déploierait un jeu d'évaluation à l'échelle décrite dans le document, en le faisant tourner à chaque changement de configuration plus une fois chaque nuit, se retrouverait, rien qu'en coût d'inférence, avec une facture annuelle conséquente — sans compter que les Skills et les Hooks demandent du personnel dédié à leur entretien. Ces dispositifs de gouvernance coûtent en eux-mêmes de l'argent et des effectifs, et le bénéfice met généralement plusieurs trimestres à se matérialiser. C'est précisément là que ce genre de refonte de processus finit souvent par caler dans les entreprises de taille moyenne. Les organisations prêtes à payer pour une piste d'audit constituent le véritable public visé par ce manuel.
Sources : documentation d'ingénierie officielle d'Anthropic, CocoLoop, documentation produit de Claude Code ; vérifié quant à la dénomination des artefacts des six phases, à la configuration des trois seuils et à la taille du jeu d'évaluation.