Du Spec-Driven à l'Issue-Based : l'évolution du développement IA

Le code comme anti-pattern : un changement de paradigme radical

Il y a quelques années, optimiser le cycle de développement logiciel signifiait gagner quelques pourcents de productivité ici et là : meilleurs outils, meilleures pratiques, CI/CD plus rapide. Aujourd'hui, cette logique d'amélioration continue est devenue, selon les termes de Didier Girard, une erreur de stratégie.

La question n'est plus "comment écrire du code plus vite ?" mais "comment ne plus écrire du code du tout ?" L'IA générative ouvre une porte vers un facteur multiplicateur de x10 sur la productivité — non pas en accélérant la production manuelle, mais en la remplaçant structurellement par une approche radicalement différente.

Chez SFEIR, nous accompagnons nos clients dans cette transition. Et ce qui nous frappe le plus, ce n'est pas la technologie elle-même — c'est à quel point les équipes qui réussissent ont rompu avec leurs réflexes antérieurs. Cet article explore les fondements de cette rupture : la fin du Spec-Driven, l'essor de l'Issue-Based, et le rôle central du Context Engineering dans ce nouveau paradigme.

Pourquoi l'amélioration continue ne suffit plus

Le constat est brutal mais nécessaire : chercher des gains marginaux dans un monde où l'IA peut changer d'échelle, c'est optimiser un modèle dépassé. C'est comme améliorer le rendement d'un cheval à vapeur alors que le moteur à explosion vient d'être inventé.

La production manuelle de code est devenue un frein à plusieurs niveaux :

• La vitesse d'exécution : un développeur humain, aussi talentueux soit-il, ne peut pas itérer à la vitesse d'un agent IA bien configuré.
• La cohérence systémique : les équipes fragmentées en silos (front, back, API, sécurité) génèrent des frictions et des délais d'attente structurels.
• La dette technique cumulative : chaque fonctionnalité ajoutée manuellement sans vision d'ensemble alourdit le codebase plutôt que de le consolider.

Face à ce constat, la stratégie du 10x ne propose pas d'optimiser ces points un par un. Elle propose de changer la nature même de l'activité : passer de la production de code à l'orchestration de contexte.

C'est un changement philosophique avant d'être un changement technique. Et il implique de repenser le rôle du développeur, la structure des équipes, et la façon dont on définit une tâche de développement.

Spec-Driven vs Issue-Based : deux visions du développement

Pour illustrer concrètement ce changement de paradigme, considérons deux approches face à un même besoin fonctionnel.

L'approche Spec-Driven (hier)

Dans un modèle Spec-Driven, l'équipe rédige une spécification fonctionnelle détaillée — souvent une user story ou un cahier des charges — et demande à l'IA (ou au développeur) de l'implémenter telle quelle. L'IA reçoit une instruction du type : "Ajoute une fonctionnalité de gestion des salles de bain à l'application."

Le résultat ? L'IA colle la fonctionnalité sur la façade existante, sans comprendre l'architecture sous-jacente, les patterns déjà en place, ni les contraintes implicites du système. On obtient ce que les praticiens appellent une verrue logicielle : fonctionnellement correcte, mais structurellement incohérente.

Ce mode de travail, encore dominant en 2025, traite l'IA comme un exécutant avancé. On lui donne une tâche isolée ; elle l'exécute isolément. Le contexte global est absent, et les hallucinations — ou pire, les incohérences silencieuses — s'accumulent.

L'approche Issue-Based (demain)

Dans un modèle Issue-Based, on ne demande plus à l'IA quoi faire, mais on lui signale un état : un manque, un bug, une opportunité d'amélioration. L'IA analyse alors l'existant, mobilise le contexte structuré mis à disposition, et produit une solution cohérente avec l'ensemble du système.

La différence est fondamentale : l'unité de travail n'est plus la fonctionnalité demandée, mais le problème observé. L'IA devient l'analyste et l'architecte, pas seulement le codeur.

Ce passage du Spec-Driven à l'Issue-Based est rendu possible par une condition sine qua non : l'existence d'un contexte riche, structuré et versionné que l'IA peut exploiter. C'est là qu'entre en scène le Context Engineering.

Le Context Engineering : le nouvel actif stratégique de l'IT

Si écrire du code est désormais un anti-pattern, quelle est la nouvelle compétence centrale de l'ingénieur ? La réponse tient en deux mots : Context Engineering.

Le Context Engineering consiste à construire et maintenir un environnement structuré — composé de fichiers Markdown, de spécifications d'architecture, de règles métier, de conventions de code, de décisions techniques documentées — qui permet à l'IA d'opérer avec un niveau de précision et de cohérence maximaux. L'objectif est simple : supprimer les hallucinations en donnant à l'IA les informations dont elle a besoin pour raisonner correctement dans le contexte spécifique de votre projet.

Concrètement, un bon contexte d'ingénierie comprend :

• La description de l'architecture applicative et des choix technologiques
• Les règles métier critiques et les contraintes implicites du domaine
• Les conventions de nommage, patterns architecturaux et standards de code
• L'historique des décisions techniques importantes (ADR — Architecture Decision Records)
• Les tests et comportements attendus documentés

Ce contexte n'est pas un document statique. Il est vivant, versionné dans Git, et enrichi à chaque cycle de développement. C'est là que réside sa valeur stratégique : contrairement au code, qui peut être régénéré, le contexte encode la connaissance accumulée du projet et de l'organisation. C'est un asset qui se bonifie avec le temps.

Chez SFEIR, nous insistons particulièrement sur ce point auprès de nos clients : le Context Engineering doit être traité avec le même soin que le code source. Il doit être reviewé, maintenu, et considéré comme un livrable à part entière — non pas un artefact annexe.

Le SDLC Augmenté : un cycle de développement repensé de bout en bout

L'intégration de l'IA dans le cycle de développement logiciel ne se résume pas à "utiliser Copilot pour compléter du code". Elle implique une refonte complète du SDLC — Software Development Life Cycle — que nous appelons le SDLC Augmenté.

Ce nouveau cycle s'articule autour de cinq phases interdépendantes :

1. Plan — Transformer les idées en plans d'implémentation

Avant toute ligne de code, l'IA est mobilisée pour transformer une idée ou un problème signalé en un plan d'implémentation détaillé. Cette phase intègre l'analyse de l'existant, l'identification des dépendances, et la proposition d'une approche cohérente avec l'architecture en place. Le développeur valide, challenge, et affine ce plan. C'est ici que se joue l'essentiel de la valeur ajoutée humaine.

2. Work — Exécuter via des agents spécialisés

L'exécution est déléguée à des agents IA travaillant sur des worktrees isolés avec un task tracking précis. Le développeur supervise, débloque les situations ambiguës, et valide les choix intermédiaires. L'humain n'est plus dans la boucle d'exécution ; il en est l'architecte.

3. Review — Une revue de code multi-agents

La revue de code devient elle-même augmentée : des agents IA analysent le code produit sous différents angles — sécurité, performance, cohérence architecturale, couverture de tests — avant que l'humain n'effectue sa propre revue. Ce filtre multi-couches améliore drastiquement la qualité et réduit le temps de review humaine.

4. Compound — Documenter pour les cycles suivants

Chaque cycle se clôt par une phase de capitalisation : les apprentissages, les décisions prises, les patterns découverts sont intégrés au contexte partagé. C'est le mécanisme qui transforme un outil IA en un partenaire qui s'améliore avec le projet.

5. Repeat — L'accélération par l'effet cumulatif

Chaque itération, enrichie par les cycles précédents, est plus rapide et plus précise que la précédente. Ce n'est pas une amélioration linéaire — c'est une accélération exponentielle rendue possible par l'accumulation de contexte.

Ce modèle implique une réallocation radicale du temps de l'équipe : 80% sur le planning et la review, 20% sur l'exécution. C'est l'inverse exact du modèle traditionnel, où l'essentiel du temps était consacré à écrire et corriger du code.

Le Compound Engineering : quand l'IA devient un investissement qui s'apprécie

Le concept de Compound Engineering — littéralement l'ingénierie cumulative — est peut-être la notion la plus importante à comprendre pour saisir l'avantage concurrentiel que procure une bonne utilisation de l'IA.

Dans un modèle traditionnel, l'IA mal utilisée accumule de la dette technique : chaque fonctionnalité générée sans contexte ajoute de la complexité, crée des incohérences, et rend les évolutions futures plus coûteuses. Le codebase devient un frein.

Dans un modèle de Compound Engineering, c'est l'inverse : chaque unité de travail rend les suivantes plus faciles. Le savoir est codifié, versionné, et rendu accessible à l'IA comme aux humains. Le contexte s'enrichit. Les patterns se consolident. La vélocité augmente de cycle en cycle.

La règle d'or de ce modèle est simple mais exigeante : "Maintenir une qualité maximale aujourd'hui pour garantir la vélocité de demain." Il n'y a pas de raccourci. Le Compound Engineering requiert une discipline rigoureuse sur la qualité du contexte et la documentation des décisions — précisément parce que ces efforts se capitalisent et génèrent des rendements croissants.

Des initiatives comme le Compound Engineering Plugin d'EveryInc illustrent concrètement comment cette philosophie peut être outillée et intégrée dans un workflow quotidien.

La Sandwich Team : repenser l'organisation autour d'un seul owner augmenté

Le SDLC Augmenté et le Context Engineering ne produisent leur plein effet que si l'organisation elle-même évolue. C'est ici que le modèle de la Sandwich Team entre en jeu.

Le modèle traditionnel — la "Pizza Team" — repose sur une équipe de 6 à 10 personnes spécialisées : un designer UX, un développeur front, un développeur back, un expert API, un ingénieur sécurité, un PO… Chaque spécialiste tient son silo, le travail passe de main en main, les délais de coordination s'accumulent. C'est efficace dans un modèle de production manuelle ; c'est un frein structurel dans un modèle IA agentique.

La Sandwich Team repose sur une logique radicalement différente : un seul développeur augmenté — l'"App Owner" — est responsable de 80% de l'application : UX, UI, front, API, back et sécurité. L'IA est son partenaire constant, comblant ses lacunes de compétences et exécutant les tâches à faible valeur ajoutée. Des contributeurs spécialisés interviennent ponctuellement — 20% du volume — sur des sujets où leur expertise pointue est indispensable.

Ce modèle supprime les temps d'attente inter-équipes, élimine les frictions de coordination, et concentre la responsabilité et la vision sur une seule personne capable de maintenir la cohérence systémique du produit.

L'analogie du bûcheron illustre bien cette transformation : dans l'ancien modèle, le bûcheron abat, le débardeur transporte, le scieur transforme — chacun attend l'autre. Dans le nouveau modèle, la machine abat, ébranche et sort le bois seule. Le bûcheron coordonne la production totale.

Cette évolution redéfinit également les métiers. Le Software Engineer classique, centré sur l'écriture de code, migre vers un profil de Product Engineer — capable de piloter l'ensemble d'une chaîne de valeur produit, de la conception à la mise en production, en s'appuyant sur l'IA pour les tâches d'exécution.

Comment SFEIR accompagne cette transformation

Chez SFEIR, nous ne théorisons pas ces concepts depuis une tour d'ivoire. Nous les expérimentons avec nos clients, dans des contextes réels, sur des projets critiques. Et nous observons que la transformation vers ce nouveau paradigme comporte des défis spécifiques qui nécessitent un accompagnement structuré.

Le défi du contexte initial

La première difficulté est de construire le premier contexte d'ingénierie. Sur un projet greenfield, c'est une opportunité : on peut poser les bases correctement dès le départ. Sur un projet existant, il faut auditer, documenter l'implicite, et formaliser des années de décisions non tracées. C'est un investissement initial significatif — mais qui se rentabilise rapidement dans les cycles suivants.

Le défi organisationnel

Passer d'une Pizza Team à une Sandwich Team est un changement humain autant que technique. Cela implique de redéfinir les rôles, d'accepter une montée en polyvalence, et parfois de renoncer à des spécialisations qui constituaient des identités professionnelles. Notre approche chez SFEIR est d'accompagner ce changement progressivement, en montrant par l'exemple les gains obtenus, plutôt qu'en l'imposant top-down.

Le défi de la qualité du contexte

Un contexte mal construit est potentiellement pire que pas de contexte du tout : il peut orienter l'IA dans de mauvaises directions avec une grande confiance. Nous aidons nos clients à définir des standards de qualité pour leur Context Engineering — notamment sur la précision des règles métier, la cohérence des conventions architecturales, et la gestion des conflits entre sources de contexte.

Le défi de la gouvernance IA

Enfin, déléguer 80% de la production à des agents IA pose des questions sérieuses de gouvernance : traçabilité des décisions, auditabilité du code généré, gestion des risques de sécurité. Ces questions ne sont pas des obstacles à l'adoption — ce sont des conditions de succès que nous intégrons dès la conception des workflows.

Conclusion : le temps de la transformation, c'est maintenant

Le passage du Spec-Driven à l'Issue-Based n'est pas une évolution progressive du développement logiciel. C'est une rupture de paradigme qui touche simultanément les méthodes, les outils, les organisations et les métiers.

Les équipes qui adoptent dès aujourd'hui le SDLC Augmenté, qui investissent dans le Context Engineering comme actif stratégique, et qui s'organisent autour du Compound Engineering, ne gagneront pas 20% de productivité sur leurs concurrents. Elles changeront d'échelle — visant le facteur 10x qui sépare les organisations qui subissent la disruption de celles qui la pilotent.

Le code n'est plus la valeur. Le contexte l'est. Et construire ce contexte avec rigueur, le versionner, l'enrichir à chaque cycle — c'est le nouveau cœur de métier de l'ingénierie logicielle.

Chez SFEIR, nous sommes convaincus que cette transformation est à la fois urgente et accessible. Elle demande moins de technologie qu'on ne le croit, et plus de clarté stratégique qu'on ne l'imagine. Si vous souhaitez explorer comment initier ce shift dans votre organisation, nos équipes sont prêtes à vous accompagner — non pas avec des recommandations théoriques, mais avec des expérimentations concrètes, mesurables, et capitalisables.

Parce que l'objectif n'est pas de coder mieux. C'est de créer plus de valeur — et beaucoup plus vite.