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. La séparation des tâches est posée en invariant — l'agent qui écrit le code ne peut pas l'approuver — et le texte se clôt sur *« The loop keeps running. Human judgement stays above it. »* Le corpus tient déjà [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] sur le versant sécurité du même cycle et [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] sur le même découpage en six étapes vu par un concurrent.
#SDLC AI-native#cycle de vie logiciel#plays
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
Décryptage SFEIR (voix cabinet, « lecture d'ingénieurs ») articulant deux cadres trop souvent confondus : le **SDLC** (Software Development Life Cycle — *construire le logiciel correctement et de façon fiable*) et le **PDLC** (Product Development Life Cycle — *construire le bon produit et réussir sur le marché*). Thèse centrale : les deux cycles ne sont pas concurrents mais **emboîtés** — le SDLC est le sous-ensemble du PDLC **logé sous sa phase développement** ; quand une équipe produit atteint le stade « build », un cycle SDLC complet (conception → build → tests → revue → déploiement) s'exécute à l'intérieur. Le SDLC est normé (**ISO/IEC/IEEE 12207**, éditions 2017 et 2026), avec sa lignée de modèles (Waterfall 1970, cycle en V, itératif/spirale, **Agile 2001**, **DevOps/DevSecOps 2009+**) et ses métriques **DORA** (débit, stabilité, MTTR, change failure rate). Le PDLC, englobant, va de l'**idéation/discovery** au **retrait du marché** (à ne pas confondre avec le **PLC** marketing de Theodore Levitt, 1965, qui décrit une *courbe commerciale*, pas un *travail organisé* : « le PLC observe une courbe ; le PDLC organise un travail »). **Point de bascule** : le SDLC ne traite nativement **qu'un risque sur quatre** — via le cadre des **« Four Big Risks » de Marty Cagan** (Valeur → PM, Utilisabilité → Designer, Faisabilité → Lead Engineer, Viabilité business → PM), une organisation excellente en SDLC mais aveugle au PDLC produit « du logiciel dont personne ne veut » — la **« feature factory »** de John Cutler (succès mesuré à l'output, pas à l'outcome). **Pourquoi l'IA change tout** : l'IA générative **comprime le SDLC** (données Google/JetBrains mai 2026 : **~85 % des devs** utilisent régulièrement des agents de code, **~41 % du nouveau code** est généré par IA ; implémentation de semaines → heures), donc le **goulot d'étranglement se déplace vers l'amont** — décider *quoi* construire (Marty Cagan, avril 2026 : « quand le coût du delivery s'effondre, le goulot se déplace vers la discovery »). Conséquences : DORA 2025 (~5 000 pros, 90 % d'adoption IA) montre une **corrélation positive au débit mais négative à la stabilité** (plus de features non validées = instabilité + retravail) ; Andrew Ng (AI Startup School, juil. 2025) rapporte des équipes **inversant le ratio « 1 PM pour 4 ingénieurs » vers « 2 PM pour 1 ingénieur »** ; et avec le **spec-driven development**, la frontière PDLC/SDLC devient **poreuse** (la spec produit devient directement exécutable par des agents). **Ce qu'une DSI doit en retenir** : un SDLC augmenté devient **norme de marché, pas différenciateur** — il faut instrumenter la jonction avec le produit, exiger des **spécifications exécutables** en entrée, croiser métriques techniques et métriques d'outcome, et **refuser le rôle de « fournisseur de features »**. Pour un CPO : le déplacement du goulot vers la discovery est à la fois **promotion** (le jugement produit redevient rare) et **mise en demeure** (industrialiser la discovery pour atteindre la parité avec le SDLC). Le cadre maison SFEIR (« Concevoir et fabriquer à l'ère de l'agentique » — **cycle à 11 phases** + **Software Factory 10x**) est positionné comme réponse au versant ingénierie, le levier suivant étant l'**articulation des deux cycles**. Conclusion : « à mesure que le code devient une commodité, la marge se déplace vers le jugement produit et la gouvernance ».
#SDLC#Software Development Life Cycle#PDLC
SFEIR (voix éditoriale du cabinet)
Papier arXiv (cs.SE) de Martin Monperrus défendant une thèse radicale pour le SDLC : les agents de codage ont franchi un seuil de capacité tel que **la revue de code humaine n'est plus un composant nécessaire** d'un pipeline qualité. Deux affirmations : (1) des systèmes autonomes à base de LLM atteignent tous les objectifs de la revue (détection de défauts, qualité, conformité) à coût moindre et débit supérieur ; (2) le modèle hybride « l'agent écrit, l'humain relit » est intenable — il n'assure pas une vraie qualité et ne passe pas à l'échelle de la vélocité IA, créant une « fausse sécurité ». Monperrus oppose à l'inspection de Fagan (1976) un **pipeline de vérification adversariale multi-agents** (agent générateur + agents reviewers indépendants + tests/méthodes formelles + consensus par vote). L'humain se recentre sur la spec, les arbitrages d'architecture, l'approbation des domaines critiques et les cas limites. Recommandations : piloter d'abord sur composants à faible risque, mesurer agent vs humain, expliciter les décisions de rejet.
#revue de code#code review#inspection de Fagan
Martin Monperrus
Étude data d'Atlassian (Inside Atlassian) mesurant le retour réel d'un **SDLC AI-native** outillé par **Rovo Dev**. Sur 3 400 dépôts de 2 500 clients (quasi-expérience avec appariement par score de propension), les dépôts adoptants mergent **19 % de PR en plus par mois** ; jusqu'à **37-51 %** sur les dépôts peu/moyennement actifs et **59-87 %** quand **3 à 5 membres** de l'équipe adoptent l'outil. Côté efficience, les développeurs gagnent **2-3 h/semaine** (≈10 % des 24 h consacrées au code et à la revue), soit 20-30 h/semaine réinvesties pour une équipe de 10. La thèse : résoudre le « paradoxe de la productivité » de Solow (1987) en passant de **métriques d'usage** (tokens) à des **métriques d'impact** (throughput, heures gagnées, taux d'échec, satisfaction). Recommandation : démarrer par une **équipe** (pas un individu) et mesurer 2-3 mois après.
#SDLC AI-native#Rovo Dev#agents de codage
Robbie Geoghegan · Fan Jiang (Atlassian)