Un SDLC piloté par l'IA : le cycle SFEIR à 11 phases (et pourquoi l'industrie y converge)

Dans la plupart des DSI, l'année 2025 a été celle des preuves de concept. Un assistant de code ici, un agent de migration là, une démo qui arrache des applaudissements en comité. Et pourtant, douze mois plus tard, le cycle de production logicielle — la façon dont une idée devient un service en production — ressemble trait pour trait à celui d'avant. Les tickets suivent le même chemin, les revues prennent le même temps, la dette s'accumule au même rythme. Les outils ont changé ; le modèle opératoire, non.

C'est exactement le paradoxe que résume une formule devenue un point de ralliement : « Tout change… et rien ne change ». Le sujet de l'IA en ingénierie logicielle n'est pas un sujet d'outil, c'est un sujet de modèle opératoire. Et ce modèle a un revers brutal : tous ces relâchements que le rythme humain absorbait tant bien que mal — une spec floue, une revue expédiée, une doc remise à plus tard — deviennent, à la vitesse de l'IA, des défauts industriels.

Autrement dit : tant qu'on greffe l'IA sur un cycle pensé pour des humains, on n'obtient pas un facteur 10. On obtient un goulot d'étranglement qui produit ses erreurs dix fois plus vite. La question n'est donc pas « quel assistant déployer ? » mais « à quoi ressemble un cycle de développement conçu pour être piloté par l'IA ? »

Pourquoi maintenant : trois signaux convergents

Trois signaux, indépendants, pointent dans la même direction.

Le signal marché. La barrière de rentabilité qui protégeait le logiciel standard — ce qu'on appelle le « moat » — s'effrite. Quand produire une fonctionnalité coûte une fraction de ce qu'elle coûtait, la valeur ne réside plus dans le code lui-même mais dans la maîtrise du contexte métier : savoir quoi construire, pour qui, sous quelles contraintes.

Le signal interne. La production manuelle de code est devenue le goulot dans la chaîne de valeur. Les meilleurs ingénieurs passent leurs journées à livrer « à la main » ce qu'un agent produit en quelques heures. Le facteur limitant n'est plus la capacité à écrire, mais la capacité à spécifier et à vérifier.

Le signal client. Les clients n'attendent plus 10 % de gain, ils attendent un effet 10x — et la facturation au temps passé ne tient plus quand la machine fait le gros du travail. Ce n'est pas une lubie française : McKinsey décrit ouvertement sa propre bascule « d'un travail d'advisory pur vers un modèle basé sur les outcomes », et revendique un effectif hybride de « 60 000 personnes — 40 000 humains et 20 000 agents ». Quand un cabinet de conseil compte ses agents dans ses effectifs, le débat sur la nature du travail livré est déjà tranché.

Le SDLC augmenté : 11 phases, 3 gates humains, 2 capitalisations

Repenser le cycle, ce n'est pas ajouter une couche d'outil. C'est redéfinir qui fait quoi, et où l'humain décide. Le cycle de développement augmenté tel que SFEIR le pratique se décompose en onze phases, trois gates humains et deux moments de capitalisation.

La frise va de 0 à 10 : 0 Setup (la stack est détectée, la mémoire du projet initialisée) · 1 Define · 2 Plan · 3 Build · 4 Verify · 5 Review · 6 Compound-1 · 7 Ship · 8 Ops · 9 Compound-2 · 10 Deprecation. Les agents exécutent ; l'humain intervient à trois gates inviolables — la spécification (Define), le plan (Plan), et la validation des modifications avant livraison (Ship). Tout le reste est automatisé ; la responsabilité, elle, reste humaine.

Deux phases ne produisent pas de code mais du capital : les capitalisations. Compound-1 récolte les leçons statiques — ce que la revue révèle, avant la livraison. Compound-2 récolte les leçons runtime — ce que seule la production révèle, sous charge réelle. Et surtout, les deux alimentent la mémoire rechargée au PLAN du cycle suivant. C'est là que se joue la différence avec un pipeline classique : « un bug vu deux fois n'est pas un bug, c'est un trou dans le système », qui devient une règle automatique.

Les quatre temps : amont · cœur · capitalisation · aval

On peut lire ces onze phases en quatre temps. L'amont (Setup, Define, Plan) cadre, contractualise, explore — c'est là que l'humain pèse le plus : une idée devient un contrat (hypothèses explicites validées avant la spec), puis le Plan ouvre trois explorations parallèles — code existant, pratiques, frameworks — dont les conflits sont mis à plat avant l'arbitrage. Le cœur (Build, Verify, Review) construit, vérifie, audite : on bâtit une tranche à la fois, sans scope creep ; on exécute les tests avec mesure de couverture ; on consolide quatre revues parallèles en un verdict. La capitalisation (Compound-1 et 2) transforme le travail en savoir réutilisable. L'aval (Ship, Ops, Deprecation) livre, observe, retire : une checklist de mise en production, un rollback écrit à froid, un déploiement progressif de 5 à 100 %, une observation de sept à quatorze jours, puis un retrait de code annoncé et capitalisé — car le code est une dette. Chaque temps fera l'objet d'un article dédié de cette série ; retenons ici la structure d'ensemble.

Trois convictions : l'IA exécute, l'humain encadre, le projet apprend

Sous cette frise, trois convictions de fond.

L'IA exécute, elle n'assiste pas. La différence n'est pas cosmétique. Un assistant propose une suggestion à valider ligne par ligne ; un exécutant produit des artefacts — du code, des tests, de la documentation — sur l'ensemble du cycle. Mais cette autonomie n'a de valeur que sous discipline de preuve : la sortie réelle de chaque étape est capturée, jamais la déclaration de l'agent. On ne croit pas un agent sur parole quand il affirme « les tests passent » ; on capture la sortie d'exécution. C'est un principe de fonctionnement, pas un indicateur — la nuance compte, et nous y reviendrons.

Cette discipline a une vertu inattendue : elle rend l'autonomie sûre. Un agent peut se tromper avec aplomb, approuver par réflexe la demande de son interlocuteur, ou « optimiser » une métrique au lieu de résoudre le problème. Capturer la preuve plutôt que la déclaration, c'est neutraliser ces modes d'échec à la racine — la même intuition qui conduit l'ADLC à traiter chaque finding de revue comme une accusation : à reproduire ou à abandonner, jamais à croire sur parole. Sur la mécanique de la vérification, voir notre article sur la revue à l'ère de l'IA.

L'humain garde le contrôle. Les trois gates ne sont pas négociables. Entre eux, l'automatisation est totale ; à eux, la décision est humaine. L'intention de produit, l'arbitrage d'architecture, l'acceptation d'une modification : ces actes restent la prérogative — et la responsabilité — d'une personne. Ce n'est pas une concession craintive à l'humain : c'est reconnaître que l'intention ne se délègue pas. Une machine optimise une fonction ; elle ne décide pas ce qui mérite d'être construit.

Le système apprend du projet. Chaque cycle enrichit le suivant : leçons consignées, règles automatiques, standards versionnés. Le centième cycle est meilleur que le premier, par construction. C'est le cœur de ce que SFEIR appelle sa stratégie AI for IT — le 10x : viser un facteur dix, pas des gains marginaux, en passant de la production manuelle de code au pilotage du contexte. (Pour le mécanisme d'apprentissage lui-même, voir notre article sur le Compound Engineering.)

Ce qu'on a mesuré — et ce que l'industrie confirme

Un cycle ne vaut que par ses résultats. Voici ce qui a été mesuré chez SFEIR, avec le contexte qui en fixe la portée.

Une refonte de site corporate menée en 6 mois → 1 jour : un cas précis, mesuré, dans un contexte métier strict. Il illustre le potentiel quand le contexte est maîtrisé — il ne promet pas ce ratio sur tout projet. Sur la durée, − 30 % d'itérations de correction après dix cycles : la preuve, mesurable, que la capitalisation paie. Une revue menée sur « + de 4 » angles parallèles — code, sécurité, tests, performance. Et un ordre de grandeur budgétaire pour le poste augmenté, ~ 10 €/h, à comparer au coût horaire chargé d'un ingénieur, jamais à zéro.

Ce − 30 % mérite qu'on s'y arrête, car il dit l'essentiel du modèle. Il ne vient pas d'un modèle plus intelligent, mais du fait que les leçons d'un cycle — un bug récurrent, une revue qui bute toujours au même endroit — sont consignées en règles automatiques rechargées au plan suivant. La courbe ne descend pas par magie : elle descend parce que le système se souvient. C'est la différence entre un outil qu'on rachète chaque trimestre et un actif qui se valorise.

Ces chiffres sont des mesures de première main, pas des promesses. À côté, des repères publics confirment la trajectoire. Salesforce rapporte + 79 % de production de modifications, une valeur livrée d'environ deux fois le volume, et des incidents en baisse de 5 % ; ainsi qu'une migration accélérée × 18 (33 endpoints passés de ~231 jours-homme à 13 jours, avec 100 % de couverture de tests).

Un mot sur ce qu'on ne dira pas : « 100 % des sorties capturées » n'est pas un pourcentage de performance, c'est l'énoncé de la discipline de preuve. La présenter comme une métrique serait un contresens. La rigueur sur les chiffres fait partie de la méthode.

La preuve par la convergence : ADLC, DORA, et les autres

Tout cela pourrait n'être qu'une doctrine maison. Ce qui rend l'approche solide, c'est qu'elle est redécouverte, indépendamment, ailleurs.

Le cas le plus frappant est le cadre ADLC (Agentic Development Lifecycle), publié en sept billets par un auteur tiers en 2026. Construit sans aucun lien avec SFEIR, il aboutit à un cycle agentique de huit phases et — c'est sa formule — « l'intention est vérifiée exactement deux fois » : approbation de la spec, puis acceptation comportementale. Il pose que les tests sont la spec, que la revue doit devenir une « prosecution » adversariale, et que le cycle doit distiller ses leçons. Il avance même une mesure : une pile de modèles mid-tier en trois passes atteint 0,85 de recall sur des bugs plantés, contre 0,6 pour une passe d'un modèle frontier unique — d'où sa maxime, « measure the stack, never the model ».

Plus lourd encore : en mai 2026, Google publie The New SDLC With Vibe Coding (signé notamment par Addy Osmani). Le document décrit un cycle où « la production première du développeur n'est plus le code, mais le système qui produit le code » — mot pour mot notre thèse — et pose l'équation « Agent = Model + Harness ». Il chiffre l'ampleur du basculement : 41 % du code neuf serait désormais généré par l'IA, et 85 % des développeurs utiliseraient des agents (Industrie · Google). Quand Mountain View et un cycle pratiqué à Paris décrivent la même chose, l'hypothèse d'une mode s'effondre.

La convergence ne s'arrête pas là. Le rapport DORA 2025 de Google Cloud résume sa thèse en trois mots — « AI is an amplifier » — et observe que l'IA magnifie autant les forces des organisations performantes que les dysfonctions des autres ; il note au passage que « le code est souvent vu comme un passif, pas comme un actif ». a16z cadre la pile de développement IA comme un marché « à mille milliards de dollars », structuré par couches d'outillage. Thoughtworks formalise son propre cycle agentique en offre, « AI/works ». Et des frameworks open-source comme Lattice — ou la doctrine PROJ-AI — réinventent, chacun de leur côté, le même pipeline design → build → review doublé d'un « contexte vivant » qui grossit à chaque feature.

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

Quand des équipes qui ne se parlent pas dessinent le même cycle, ce n'est plus une mode, c'est une propriété du problème. Le seul écart notable est instructif : l'ADLC tient deux gates humains (spec, acceptation) ; SFEIR en tient trois, en isolant explicitement le plan d'architecture comme un point de décision à part. Désaccord de surface — les deux cadres s'accordent sur le fond : l'humain décide l'intention, la machine prouve le reste.

Pour un décideur, cette convergence change la nature du pari. Adopter un cycle augmenté n'est pas miser sur une doctrine d'éditeur ou sur 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 ne se situe plus dans le choix du modèle de cycle — il fait consensus — mais dans la qualité de son exécution : la rigueur de la spec, la solidité de la preuve, la fidélité de la capitalisation. C'est précisément là que se joue l'écart entre une organisation qui voit l'IA amplifier ses forces et une autre qui la voit amplifier ses dysfonctions.

Où ça s'applique — et où l'on n'y va pas (encore)

Un discours honnête doit nommer ses limites. Le cycle augmenté excelle là où le contexte métier est explicitable (back-offices, APIs, portails, modernisation de legacy), là où le volume est répétitif et traçable (tests, migrations, documentation, conformité), et partout où le résultat se prouve automatiquement.

Il n'a pas sa place — ou pas encore — ailleurs. L'inédit sans spec possible reste humain : l'IA explore, elle ne décide pas l'intention. Le safety-critical certifiable demande la prudence : tant que la chaîne d'outils n'est pas qualifiée au sens des normes comme DO-178C (avionique) ou EN 50128 (ferroviaire), l'IA renforce la vérification et la validation sans s'y substituer. Et les données non gouvernées sont un préalable, pas un terrain de jeu : la gouvernance de la donnée passe d'abord. Reconnaître ces frontières n'affaiblit pas l'approche — c'est ce qui la rend déployable.

Par où commencer : le cycle comme actif, pas comme outil

Si une seule idée doit rester, c'est celle-ci : le code est le sous-produit ; l'actif réel est la connaissance que le projet accumule. L'IA exécute, l'humain encadre, le projet apprend.

Concrètement, par où démarrer ? Pas par l'achat d'un outil. Par la mise en place d'un gate de spécification digne de ce nom et d'une discipline de preuve sur les sorties — ce sont les deux fondations que tout le reste vient outiller. La règle directrice : on standardise le contexte et la preuve, pas l'outil. Le goulot se déplace alors de l'écriture du code vers la spec et la validation — c'est-à-dire vers ce que l'humain fait de mieux.

Sur ce point, SFEIR a un parti pris assumé : se l'appliquer d'abord à elle-même. L'objectif affiché est de 850 consultants 100 % augmentés par l'IA fin 2026, avant de déployer le modèle chez ses clients. Car la promesse n'est pas un meilleur assistant. C'est un cycle qui transforme chaque unité livrée en capital pour la suivante — un système qui, au lieu de répéter ses erreurs dix fois plus vite, apprend dix fois plus vite. Vos pilotes IA, eux, marchaient déjà. La vraie question était ailleurs : votre cycle, lui, apprend-il ?

Cet article est la tête d'une série sur le SDLC augmenté : l'exécution autonome sous preuve, l'amont (Define & Plan), la capitalisation (Compound), l'aval (Ship, Ops, Deprecation), les limites du certifiable, l'économie d'investissement (CapEx/OpEx) et la convergence des cadres (ADLC). Voir aussi : « Écrire du code est un anti-pattern » et le SDLC augmenté : discipline, architecture, apprentissage.

Sources

1. Olivier Rafal (WeNvision, groupe SFEIR), L'ingénierie logicielle à l'ère de l'IA : tout change… et rien ne change — cio-online.com, 1er juin 2026.
2. 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.
3. SFEIR — SDLC piloté par l'IA : cycle à 11 phases (one-pager) et deck SDLC v3 (refonte 6 mois → 1 jour, −30 % d'itérations après 10 cycles, « + de 4 » angles de revue, ~10 €/h), matière first-party, juin 2026.
4. Srini Tallapragada, How Salesforce Engineering Became Truly Agentic — salesforce.com, 27 mai 2026.
5. Chris Williams, Stop Running the SDLC on Models That Aren't Human (série ADLC, partie 1) — voodootikigod.com, 12 juin 2026.
6. Addy Osmani, Shubham Saboo, Sokratis Kartakis (Google), The New SDLC With Vibe Coding — kaggle.com, mai 2026.
7. DORA × delta team (Google Cloud), The ROI of AI-assisted Software Development — cloud.google.com, 21 avril 2026.
8. Aaron Levie, Building for trillions of agents — x.com, 7 mars 2026.