Convergence 2026 : quand l'ADLC et l'industrie redécouvrent le cycle agentique de SFEIR

En juin 2026, un ingénieur publie sur son blog personnel — voodootikigod.com — une série de sept billets sur un cycle de développement logiciel entièrement repensé pour des agents. Il l'appelle l'ADLC, pour Agentic Development Lifecycle. Aucune marque derrière, aucune offre à vendre. Juste un praticien qui formalise ce qu'il observe : « tout le monde qui fait tourner des agents depuis plus d'un mois » bute sur les mêmes échecs, et finit par dessiner les mêmes défenses.

Le détail troublant n'est pas le contenu de ces billets, mais leur ressemblance avec d'autres cadres écrits ailleurs, par des équipes qui ne se connaissent pas : un framework open-source nommé Lattice, une doctrine baptisée PROJ-AI, une « usine logicielle augmentée » décrite par un cabinet d'architecture, une offre formalisée par un grand acteur du conseil. Tous décrivent, à quelques détails près, le même cycle : une intention qu'un humain valide, une exécution massivement automatisée, une revue adversariale, et un contexte qui grossit à chaque passage.

Le poids lourd de cette convergence, lui, n'est pas anonyme. En mai 2026, Google publie The New SDLC With Vibe Coding, signé notamment par Addy Osmani. Le document décrit, sans jamais citer SFEIR, un cycle où « la production première du développeur n'est plus le code, mais le système qui produit le code » — l'exacte reformulation de la thèse selon laquelle le code est le sous-produit et la connaissance l'actif. Il pose même l'équation « Agent = Model + Harness », où le harnais (prompts, outils, garde-fous, observabilité) pèse l'essentiel et le modèle presque rien. Qu'un acteur de cette taille décrive indépendamment le même cycle ne valide pas l'approche par autorité ; cela confirme que l'objet a une forme stable, qu'on l'observe depuis Mountain View ou ailleurs.

Quand des gens qui ne se parlent pas dessinent la même chose, ce n'est plus une tendance qu'on suit : c'est une propriété du problème qu'on découvre. Et pour qui pratique déjà un tel cycle, cette convergence pose une question utile : comment lire un cadre tiers sans se contenter de s'y reconnaître ?

La règle de lecture : convergence n'est pas fusion

Une doctrine interne ne prouve rien : n'importe quelle organisation peut décrire son propre cycle comme « le bon », chiffres à l'appui. Ce qui rend une approche solide, ce n'est pas qu'elle se cite elle-même, c'est qu'elle est redécouverte, indépendamment, ailleurs. La valeur d'un cadre tiers tient précisément à ce qu'il n'a rien à vendre de commun avec vous.

Mais lire un cadre externe impose une discipline, sous peine de tomber dans le travers inverse : l'auto-congratulation déguisée en preuve. Deux règles tiennent l'exercice. La première : on met en lecture, on ne fusionne pas. Les chiffres d'un cadre tiers restent les siens — étiquetés à sa source, jamais agrégés à des mesures internes pour gonfler un résultat composite. Un recall de revue mesuré par un auteur sur ses propres jeux de tests ne devient jamais une « performance SFEIR ». La seconde : mesure n'est pas illustration. Un cadre sérieux distingue ce qu'il a mesuré de ce qu'il avance en exemple pour faire comprendre une mécanique ; confondre les deux transforme un raisonnement honnête en argument marketing.

C'est avec ces deux garde-fous qu'on peut « lire » l'ADLC — et les cadres qui l'entourent — comme une caution externe du cycle que SFEIR pratique déjà : le SDLC augmenté à onze phases, trois gates humains et deux capitalisations, présenté dans notre article pilier. Le but n'est pas de prouver que SFEIR a raison parce qu'un autre dit pareil, mais de montrer que l'objet — le cycle agentique — a une forme stable, que plusieurs observateurs retrouvent sans se concerter.

L'ADLC, en détail : huit phases, deux gates, une obsession de la preuve

Commençons par le cadre le plus complet et le plus frontal : l'ADLC. Sa thèse de départ est une provocation. Le SDLC tel qu'on le connaît, écrit l'auteur, c'est soixante ans de défenses contre les modes d'échec humains — l'oubli, l'ego, la fatigue. Or les modèles n'échouent pas comme nous : ils hallucinent avec aplomb, approuvent par réflexe la demande de leur interlocuteur, trichent une métrique chiffrée dès qu'on la leur impose comme objectif. Appliquer le SDLC humain à des agents, c'est donc se défendre contre les mauvais risques.

D'où une première loi : « chaque phase, chaque gate, chaque boucle doit se rattacher à un mode d'échec précis du modèle — ou à une propriété qu'on exploite. Sinon, on la coupe. » Et un fil rouge en une formule : remplacer la confiance par la structure, et la structure par la mesure.

Le cycle qui en résulte compte huit phases (« Industrie · ADLC ») : Triage, Interrogate, Decompose, Rail, Build, Prosecute, Integrate, Distill. Entre chaque jointure, un point de contrôle déterministe — compilateur, suite de tests, validateur — car « un passage de relais d'un LLM à un autre, sans point de contrôle déterministe, multiplie les taux d'erreur ». La machine vérifie la machine ; l'humain n'intervient qu'à deux endroits.

Ces deux gates humains sont le cœur du cadre. L'ADLC en fait sa devise : l'intention est vérifiée exactement deux fois. Une première fois à la spécification (Interrogate), où un agent interroge les parties prenantes après avoir lu le code existant, jusqu'à ce que chaque critère d'acceptation nomme sa méthode de vérification. Une seconde fois à l'intégration (Integrate), où l'humain accepte — ou non — le comportement observé en exécution réelle ; la question posée y est limpide : « est-ce bien ce que je voulais, en train de tourner ? » Entre les deux, rien que des gates déterministes.

Trois idées-forces structurent l'intérieur du cycle.

Les tests sont la spec. Optionnel pour du code humain, le TDD devient ici « le mécanisme de confiance porteur de tout l'édifice ». Tests, types et contrats sont écrits depuis la spec, en isolation, puis gelés — hors de portée de l'agent qui code. La raison tient en une phrase : « une contrainte qui vit dans la couche du prompt est une requête ; une contrainte qui vit dans la couche outil est un fait. » Un agent peut ignorer une consigne ; il ne peut pas réécrire un test que le système refuse de lui laisser toucher.

La revue devient une prosecution. Pas une évaluation collaborative — une mise en accusation. Demander à un modèle « passe en revue ce code » provoque de la complaisance avec un barème ; il faut lui dire « trouve ce qui cloche, et si tu ne trouves rien, dis-le ». Plusieurs procureurs travaillent en parallèle, chacun à contexte frais, sur une seule dimension — correction, sécurité, conformité de contrat, qualité des tests. Et un finding n'est pas une opinion : « preuve, ou ça n'a pas eu lieu » — tout signalement doit être reproduit par un test rouge avant d'être traité. C'est l'intuition qu'on retrouve dans notre article sur la revue à l'ère de l'IA.

Le cycle distille ses leçons. Une phase finale transforme les findings récurrents en règles de lint, compétences réutilisables et nouvelles questions de spécification. Chaque leçon n'est payée qu'une fois, puis rétrogradée d'une détection probabiliste coûteuse vers une prévention déterministe gratuite. La maxime qui gouverne cette phase est un avertissement : « un coût plat est un échec. » Un cycle sain coûte mesurablement moins cher par changement à chaque run ; s'il ne baisse pas, c'est que le système n'apprend pas.

Sur ce dernier point, l'ADLC ose un chiffre — et c'est là que la discipline de lecture compte. Son auteur mesure le recall de sa pile de revue : une pile de modèles de milieu de gamme en trois passes attrape 0,85 des bugs plantés dans le code, contre 0,6 pour une seule passe d'un modèle de pointe (« Industrie · ADLC »). D'où sa maxime : « mesurez la pile, jamais le modèle. » Ce 0,85 contre 0,6 est un chiffre attribué à l'auteur, sur ses propres jeux de bugs : il vaut comme illustration de sa thèse, pas comme une norme de marché — et il ne se mélange à aucune mesure d'aucun autre cadre.

L'auteur avance aussi un toolkit de 18 outils (« Industrie · ADLC »), construits par le cycle lui-même et intégrables en CI. Et il propose un exemple chiffré — à présenter comme tel, jamais comme une mesure — d'une échelle d'escalade de modèles qui réduirait le coût d'environ 45 % face à l'usage direct d'un modèle de milieu de gamme. À l'inverse, sur le travail qui résiste à l'automatisation, son « compte de pertes honnête » est sobre : environ 5 % du travail tourne sous supervision maximale. Cette rigueur à distinguer mesure, illustration et principe est, en soi, un signal de sérieux.

La même forme, partout : le tableau des isomorphismes

Si l'ADLC était isolé, on pourrait y voir une curiosité d'auteur. Ce qui frappe, c'est qu'il rejoint un faisceau de cadres construits séparément, convergeant sur deux invariants : un pipeline isomorphe design → build → review, et un contexte vivant qui s'enrichit à chaque feature.

Prenons Lattice, un framework open-source qui veut « installer de la discipline d'ingénierie dans n'importe quel assistant de code IA ». Son architecture tient en trois tiers : des Atoms (garde-fous mono-principe — clean code, sécurité, qualité des tests), des Molecules (workflows qui les composent : design, implement, refactor, fix, review) et des Refiners (entretiens guidés qui produisent les standards propres au projet). Son pipeline canonique — design-blueprint → code-forge → review — est, à la nomenclature près, le cœur de n'importe quel cycle agentique. Et son principe le plus parlant est un dossier .lattice/ qui, dit la documentation, « devient plus intelligent au fil des cycles de feature » — l'un de ses aphorismes le résume : « du contexte vivant plutôt qu'une configuration figée. »

Prenons PROJ-AI, une doctrine portée par WEnvision, dont la formule centrale renverse l'ordre habituel : « le projet n'est pas un sous-produit du livrable. Le projet EST le livrable. » Sa triade — un dépôt git versionné, un agent qui relit la doctrine à chaque session, une doctrine en markdown — fait du contexte la matière première ; son cycle, DPEV (Décider, Promettre, Exécuter, Vérifier), referme la boucle par une vérification. Avec un avertissement salutaire sur la part des choses : « 20 % de technologie, 80 % de discipline d'équipe. »

Prenons enfin l'offre AI/works d'un grand acteur du conseil technologique : une Super Spec, spécification dynamique unifiée qui sert de source de vérité et régénère le code impacté plutôt que de le rapiécer, doublée d'un plan de contrôle pour gouverner les agents et d'une boucle où la production met à jour la spec. Le slogan, « nous le refaisons, pour l'ère de l'IA », dit l'ambition de redéfinir le cycle.

Au-dessus de ces cadres opérationnels, les analystes posent le décor. Un fonds d'investissement de premier plan décrit la pile de développement IA comme un marché « à mille milliards de dollars » (« Industrie · a16z »), structuré par couches d'outillage. Un grand cabinet de conseil revendique un effectif hybride de « 60 000 personnes, dont 40 000 humains et 20 000 agents » (« Industrie · McKinsey ») et une bascule « d'un travail d'advisory pur vers un modèle basé sur les outcomes ». Quand un cabinet compte ses agents dans ses effectifs et facture au résultat, le débat sur la nature du travail livré est tranché.

Reste un dernier témoin, plus mesuré : le rapport DORA de Google Cloud, dont la thèse tient en trois mots — « l'IA est un amplificateur » (« Industrie · DORA ») — qui magnifie autant les forces des organisations performantes que les dysfonctionnements des autres. Il observe au passage que « le code est souvent vu comme un passif, pas comme un actif » : exactement le renversement que tous ces cadres opèrent en faisant du contexte, et non du code, l'actif réel.

Le seul vrai désaccord : deux gates, ou trois ?

Quand on aligne ces cadres, l'accord est presque gênant de netteté. Tous séparent un travail de jugement, réservé à l'humain, d'un travail d'exécution confié à la machine sous contrôle déterministe ; tous font du contexte un actif qui se valorise ; tous refusent de mesurer la valeur au temps passé. L'écart le plus visible — et le plus instructif — porte sur le nombre de moments humains.

L'ADLC en tient deux : la spec, et l'acceptation comportementale. Le SDLC augmenté de SFEIR en tient trois : la spécification, le plan d'architecture, et la validation des modifications. La différence se loge dans ce gate intermédiaire. Là où l'ADLC traite l'architecture comme une conséquence de la spec, vérifiée en aval par les tests gelés, SFEIR l'isole en point de décision à part entière — parce que l'arbitrage entre plusieurs pistes d'architecture engage des choix structurels qu'aucun test ne rattrape après coup. C'est l'objet de l'amont du cycle, que détaille notre article sur le Define et le Plan : trois explorations parallèles, leurs conflits mis à plat, puis un arbitrage humain.

Désaccord de surface, accord de fond. Que l'humain décide à deux moments ou à trois, le principe est identique : l'humain décide l'intention, la machine prouve le reste. Et cet écart même est rassurant : si tous les cadres étaient rigoureusement identiques, on pourrait soupçonner une copie. Qu'ils divergent sur un point précis, en argumentant chacun son choix, confirme qu'ils ont été pensés séparément.

Reste une mise en garde que la convergence elle-même impose : s'accorder sur la forme du cycle ne dit rien sur la qualité de son exécution. C'est tout le sens de la thèse DORA — l'IA amplifie. Adoptez un cycle augmenté avec une spec bâclée, une preuve approximative et une capitalisation négligée, et vous amplifierez vos dysfonctionnements aussi sûrement que vos forces. DORA décrit même la trajectoire : une courbe en J, un creux de productivité avant la remontée — le « coût d'apprentissage » de la transformation. Le danger n'est pas le creux ; c'est le dirigeant qui l'interprète comme un échec et coupe le financement au pire moment. La convergence dérisque le choix du cycle ; elle ne dispense pas de l'exécuter avec rigueur.

Ce que la convergence change pour un décideur

Pour qui pilote une transformation, lire cette convergence a trois conséquences.

D'abord, elle déplace la nature du pari. Adopter un cycle augmenté n'est plus miser sur la doctrine d'un éditeur ou la mode d'un fournisseur : c'est s'aligner sur un invariant que le marché, la recherche et le terrain valident en parallèle. Le risque n'est plus dans le choix du cycle — il fait consensus — mais dans la qualité de son exécution.

Ensuite, elle invite à mesurer le système, pas l'outil. L'ADLC le formule pour la revue — « mesurez la pile, jamais le modèle » — et DORA pour l'organisation — mesurez les goulots que l'IA débloque, pas le code qu'elle écrit. La bonne unité de compte n'est donc ni le nombre de tokens par développeur, ni le nombre de licences, mais le coût par changement livré et vérifié : un cycle qui n'apprend pas a un coût plat ; un cycle qui apprend voit ce coût baisser.

Enfin, séquencer l'adoption par le soulagement. L'ADLC recommande de commencer par le point le moins disruptif — faire prosecuter par des agents les pull requests déjà existantes, sans toucher au flux de travail — avant d'imposer rails, interrogation et parallélisme. Mandater le cycle complet dès le premier jour est l'anti-pattern garanti. Et tout au long, traiter le contexte comme l'actif : le .lattice/, le dépôt-doctrine, la Super Spec, les capitalisations du cycle convergent vers la même idée — ce qui se valorise n'est pas le code, mais la connaissance accumulée.

La mise en lecture, comme posture

C'est précisément cette discipline que SFEIR adopte vis-à-vis de l'ADLC, avec WEnvision : non pas brandir un cadre tiers comme un trophée, mais le mettre en lecture parce qu'il rejoint, indépendamment, le SDLC AI qu'on pratique déjà. Les chiffres de l'ADLC restent ceux de l'ADLC ; la mécanique du cycle SFEIR — onze phases, trois gates, deux capitalisations — reste mesurée à ses propres résultats, sans emprunt. L'intérêt n'est pas d'additionner des preuves de provenances différentes : c'est de constater qu'un objet observé depuis plusieurs angles garde la même silhouette. La posture a un nom : on standardise le contexte et la preuve, pas l'outil — les outils changeront, la structure du cycle et la discipline de preuve qui l'irrigue, non.

Quand sept billets anonymes décrivent votre cycle

Revenons à notre praticien et à ses sept billets. Ce qui rend son travail précieux, ce n'est pas qu'il valide une approche particulière : c'est qu'il démontre, par sa ressemblance avec une dizaine d'autres cadres, que le cycle agentique a une forme stable, que des équipes isolées retrouvent en partant de leurs propres échecs — une intention validée par un humain, une exécution prouvée par la machine, une revue qui réfute, un contexte qui apprend.

Le jour où des billets anonymes, des frameworks open-source, des cabinets d'architecture et des analystes financiers décrivent tous le cycle que vous pratiquez, la question stratégique se déplace. Elle n'est plus « quel cycle adopter ? » — la réponse fait consensus. Elle devient « savez-vous l'exécuter ? ». Et sur ce terrain, aucune convergence ne vous aidera : il n'y a que la rigueur de la spec, la solidité de la preuve, et la patience de laisser le système apprendre. La forme est connue de tous ; l'exécution, elle, reste un avantage.

Cet article appartient à une série sur le SDLC augmenté : la vue d'ensemble dans l'article pilier, le détail des gates amont dans Define & Plan, la mécanique de la revue dans la revue à l'ère de l'IA, et l'apprentissage du système dans le Compound Engineering.

Sources

1. Chris Williams, Stop Running the SDLC on Models That Aren't Human (série ADLC, volet 1) — voodootikigod.com, 12 juin 2026.
2. Chris Williams, Two Human Gates and Everything Between Is Machine-Checked (série ADLC, volet 2) — voodootikigod.com, 12 juin 2026.
3. Chris Williams, Tests Are the Spec in the Only Language the Builder Can't Argue With (série ADLC, volet 3) — voodootikigod.com, 12 juin 2026.
4. Chris Williams, Prosecution, Not Code Review (série ADLC, volet 4 ; recall illustratif 0,85 vs 0,6 mesuré par l'auteur sur ses propres jeux de bugs) — voodootikigod.com, 12 juin 2026.
5. Chris Williams, The Lifecycle That Gets Cheaper Every Run (série ADLC, volet 6 ; « flat cost is failure », exemple chiffré d'escalade ≈ 45 % à présenter comme illustration, non comme mesure) — voodootikigod.com, 12 juin 2026.
6. Chris Williams, The ADLC Toolkit (série ADLC, volet 7 ; 18 outils, « honest loss account » ≈ 5 % du travail à supervision maximale) — voodootikigod.com, 12 juin 2026.
7. Addy Osmani, Shubham Saboo & Sokratis Kartakis (Google), The New SDLC With Vibe Coding — From ad-hoc prompting to Agentic Engineering — kaggle.com, mai 2026.
8. techygarg, Lattice — Composable AI skills that teach assistants structured thinking — github.com, 5 mai 2026.
9. Antoine Habert (WEnvision), Un repo, un agent, un IDE — pourquoi PROJ-AI ? — wenvision.com, 5 mai 2026.
10. Thoughtworks, AI/works™ — Thoughtworks' Agentic Development Platform — thoughtworks.com, 12 mai 2026.
11. Aaron Levie, Building for trillions of agents — x.com, 7 mars 2026.
12. OfficeChai Team, McKinsey Now Has 60,000 People, But 20,000 Of Them Are AI Agents (déclarations de Bob Sternfels, McKinsey & Company) — officechai.com, 14 janvier 2026.
13. DORA & delta team (Google Cloud), The ROI of AI-assisted Software Development — cloud.google.com, 21 avril 2026.