On a tous vécu cette phase d’ivresse. Tu ouvres ton éditeur de code, tu lances Cursor, Claude ou Gemini, tu tapes trois lignes de prompt à moitié floues en mode « fais-moi un tableau de bord dynamique pour mes abonnements », et boom : 200 lignes de code apparaissent sous tes yeux ébahis. C’est magique, c’est grisant… C’est le Vibe Coding.

Mais quiconque a poussé ce délire sur un vrai projet en production connaît la suite : la sale gueule de bois du lundi matin. Tu te retrouves avec des fonctions clonées en triple, du code mort partout, des réécritures complètes pour corriger une pauvre virgule, et une facture d’API qui donne des sueurs froides à la comptabilité.

En 2026, la fête est finie. Le freestyle conversationnel avec les LLM montre ses limites systémiques. Pour continuer à profiter de la puissance des IA sans transformer ton projet en décharge publique, il faut changer de paradigme. C’est là qu’intervient le Spec-Driven Development (SDD), ou le développement piloté par les spécifications.

Ne pars pas ! On ne parle pas ici de rédiger un cahier des charges poussiéreux de 300 pages sous Word. On parle de transformer la spécification en source unique de vérité exécutoire pour les IA. Voyons comment ça marche, quels outils utiliser, et comment automatiser tout ça sans y laisser son slip.

Les 3 niveaux de maturité du SDD : Tu te situes où ?

Le concept a été décortiqué par les équipes de Thoughtworks. L’idée est simple : mesurer à quel point ta spécification technique et ton code source sont verrouillés ensemble.

NIVEAUX DE RIGUEUR SDD

Niveau 1Spec-FirstManuel / Éphémère
Niveau 2Spec-AnchoredContrat Vivant Git
Niveau 3Spec-as-SourceCode compilé généré
  • Niveau 1 : Le Spec-First (Le mode « Bon élève ») : Tu rédiges une spécification claire en Markdown avant de l’envoyer à l’IA. Elle code la fonctionnalité en se basant dessus, tout le monde est content. Le problème ? Une fois le code généré, la spec est oubliée, prend la poussière dans un coin et le code dévie rapidement.
  • Niveau 2 : Le Spec-Anchored (Le mode « Contrat Vivant ») : La spécification coexiste activement avec le code. C’est un fichier vivant, versionné dans ton dépôt Git (au même titre que tes contrôleurs ou tes entités). Tu veux modifier un comportement ? Tu modifies d’abord la spécification, et des tests d’acceptation automatisés vérifient en permanence que le code ne dévie pas de la spec.
  • Niveau 3 : Le Spec-as-Source (Le Graal absolu) : L’humain ne touche plus jamais au code source. La spécification est le code source de haut niveau. Tu modifies l’architecture ou les règles métiers dans ton Markdown, et des agents spécialisés compilent le code d’implémentation de manière déterministe. La mention // GENERATED FROM SPEC - DO NOT EDIT devient ta meilleure amie.

La transition vers les niveaux Spec-Anchored et Spec-as-Source apporte un contrôle rigoureux pour les systèmes soumis à des contraintes réglementaires ou de haute sécurité.

Pourquoi vos agents IA font n’importe quoi (L’histoire des 10% d’échecs)

Tu as déjà essayé de filer une grosse TODO liste technique à un agent autonome (comme Hermes ou Antigravity) en le laissant bosser tout seul dans son coin ? Si oui, tu as sûrement remarqué que le taux d’échec unitaire frôle les 10%. assez pour passer a côter.

L’agent commence à coder, il hallucine une fonction, il invente des routes d’API, il s’enfonce dans son erreur (le fameux biais de fixation), et il finit par te dire fièrement « C’est bon, j’ai fini ! » alors que le projet ne compile même plus.

Pour régler ça, le SDD impose deux règles d’ingénierie cognitive :

1. La Double Boucle (SDD + TDD)

Un agent ne doit pas coder au hasard. Il doit avancer selon une double validation :

  • La boucle externe (SDD) : L’agent vérifie que ce qu’il fait correspond aux critères d’acceptation globaux décrits dans la spécification (les scénarios fonctionnels).
  • La boucle interne (TDD) : C’est le cycle classique Red-Green-Refactor. L’agent écrit d’abord le test unitaire, constate qu’il échoue, écrit le code minimal pour le faire passer, puis nettoie sa syntaxe.

2. Le Trio Infernal (Coordinateur – Implémenteur – Vérificateur)

Faire confiance à un seul agent pour concevoir, coder et vérifier son propre travail, c’est comme demander à un étudiant de noter son propre examen. Le workflow moderne sépare les rôles :

  • Le Coordinateur prend la spec globale et la découpe en sous-tâches chirurgicales.
  • L’Implémenteur prend une tâche isolée et modifie le code dans un bac à sable (Sandbox).
  • Le Vérificateur (un agent ou un pipeline CI/CD) fait tourner les tests et valide le résultat par rapport au contrat initial. Si ça casse, il rejette le code.

La Boîte à Outils du « Spec-Architect »

Le marché s’est structuré autour de frameworks taillés pour le SDD. Voici un résumé rapide de ce qui tourne en 2026 :

OutilNiveau SDDArchitecture PrincipaleCommandes / FluxLimites Identifiées
KiroSpec-FirstExtension VS Code / CLI. Génère un triptyque Markdown strict.requirements.md (fonctionnel), design.md (technique), tasks.md (découpage).Un peu rigide pour les petites corrections rapides.
Spec-kit (GitHub/Microsoft)Spec-First / AnchoredCLI en Python gérée par uv. Intégration multi-agents./speckit.specify (cahier des charges), /speckit.plan (technique), /speckit.tasks.Risque d’inflation de fichiers Markdown.
TesslSpec-as-SourceCLI et serveur compatible avec le protocole MCP.tessl init, puis utilisation de liens d’ancrage @test reliant exigences et tests.Dépend de modèles à très fort raisonnement.
OpenSpecSpec-AnchoredCLI Node.js. Organisation modulaire par dossier fonctionnel.Dossier dédié openspec/changes/<feature>, avec /opsx:propose et /opsx:apply.Demande une hygiène stricte pour ne pas polluer l’espace de travail.
GSD CoreSpec-First & Spec-AnchoredSDK et CLI optimisés pour l’agent Claude Code.Commandes avec espace de noms /gsd:<command> orchestrées par un routeur central.Projet archivé et déplacé vers une maintenance communautaire.

📈 Le cas d’école industriel : IA-Veu (Fluendo)

La société Fluendo a déployé Spec-kit sur son projet de synthèse vocale (Django REST Framework, React, Docker, Celery). Ils ont inscrit dans leur charte (constitution.md) une règle stricte : la couverture de code backend devait respecter l’équation suivante :

$$\text{Couverture}_{\text{Backend}} = \frac{\text{Lignes de code testées}}{\text{Lignes de code totales}} \times 100 \ge 64\%$$

Les résultats réels après avoir bridé les agents avec cette méthode :

  • 10 Spécifications fonctionnelles et 10 principes constitutionnels appliqués.
  • 363 / 363 tests backend passés (Zéro régression).
  • Une couverture réelle montée à 69,8% (dépassant l’objectif des 64%).
  • 109 / 116 tests End-to-End Frontend validés sur React.

Le Hack Budgétaire : Diviser sa facture d’API par 100

Le Vibe Coding coûte une blinde parce qu’on utilise des modèles premium (comme Claude 3.5 Sonnet ou GPT-5) pour faire des boucles de réflexion infinies sur des tâches de routine. L’ingénierie moderne propose une orchestration multi-modèles beaucoup plus intelligente et économique :

  1. Conception & Architecture (Humain + Modèle Premium à coût fixe) : Tu passes une heure avec un modèle doté d’une immense fenêtre de contexte (comme Gemini et son million de tokens pour le prix d’un abonnement standard) pour ingérer toute ta base de code, analyser l’impact et rédiger la spécification (spec.md) et le plan (tasks.md).
  2. Exécution Matérielle (Agent Persistant + Modèle Low-Cost) : Tu confies le plan de tâches à un agent local (comme Hermes Agent). Ce dernier va lire la spec et déléguer l’écriture pure des lignes de code à des modèles ultra-rapides et extrêmement économiques (comme Minimax 2.7 ou DeepSeek Flash). Le coût d’exécution s’effondre à 0,02 $ par run, contre parfois plus de 7,00 $ pour une boucle agentique non cadrée sur un modèle premium.

Sécuriser la bête : Le mode Sandbox obligatoire

Laisser un agent IA exécuter des commandes dans ton terminal sans surveillance, c’est jouer à la roulette russe avec ta machine. Un prompt injecté ou une mauvaise interprétation, et c’est le drame.

Les frameworks comme Antigravity permettent de verrouiller l’environnement via un fichier de configuration settings.json. On désactive l’accès réseau non contrôlé et on restreint les accès aux fichiers uniquement au dossier de travail actuel (${workspaceFolder}) :

JSON

{
  "allowNonWorkspaceAccess": false,
  "enableTerminalSandbox": true,
  "permissions": {
    "allow": {
      "network": false,
      "fsRead": ["${workspaceFolder}"],
      "fsWrite": ["${workspaceFolder}"]
    }
  },
  "trustedWorkspaces": ["${workspaceFolder}"]
}

En couplant ce cloisonnement à des schémas de validation stricts (comme Pydantic ou Zod) pour filtrer les arguments passés aux outils de l’agent, et à des hooks de pré-commit (Semgrep, Bandit), on élimine les risques d’injection de commandes système. De plus, lancer vos agents via des sessions tmux ou avec l’option de journalisation (agy -p) permet de capturer un historique plat des logs pour des audits externes réguliers.

🛠️ Le Blueprint du Terrain : La Méthode « Zéro Blabla » en 5 Étapes

Assez de théorie. Voyons comment appliquer ce workflow de manière ultra-concrète. C’est la méthode exacte que j’utilise au quotidien pour dompter mes agents IA sur mes projets en production, même ceux qui frôlent les 1,5 million de tokens.

Sortez vos carnets, voici le guide pas-à-pas à suivre à la lettre :

Étape 1 : L’extraction chirurgicale du contexte

Pas question de balancer tout votre dépôt en vrac.

  • Utilisez CodeFusion pour sélectionner uniquement l’arborescence et les fichiers concernés par votre fonctionnalité.
  • Exportez le tout en un fichier unique.
  • Le Hack : Si votre sélection dépasse les 50 000 tokens, l’interface de Chrome va laguer si vous faites un copier-coller dans le chat. Prenez votre fichier unique généré par CodeFusion, et glissez-déposez-le directement dans Gemini.

Étape 2 : Le brainstorming intensif (1h à 2h)

Une fois le code ingéré par Gemini, la phase de cadrage commence. C’est ici que vous lancez les hostilités en copiant-collant l’invite prompt_1_alignment.md (que vous trouverez juste en bas).

Ne lui demandez surtout pas de code. Dites-lui ce que vous voulez, comment vous voyez les choses, et répondez à ses questions de clarification. Bouclez. Laissez-le vous cuisiner. Quand Gemini n’a plus de questions et que tout est clair pour vous, passez à la suite.

Étape 3 : La sainte trinité (CDCT + TODO)

C’est le moment de figer le contrat textuel :

  1. Envoyez l’invite prompt_2_spec_generation.md pour forcer Gemini à rédiger le CDCT (Cahier des Charges Technique). Lisez-le et ajustez s’il y a des manques (comptez 2 ou 3 allers-retours en général).
  2. Une fois le CDCT validé, injectez l’invite prompt_3_todo_list.md pour obtenir la TODO liste technique détaillée et ultra-séquencée. Lisez-la et ajustez si nécessaire (comptez 1 ou 2 allers-retours).

Étape 4 : Le piège du plan de l’agent (Le double check obligatoire)

Donnez votre CDCT et votre TODO liste fraîchement générés à votre agent autonome (Antigravity ou Hermes Agent).

  • Attention : Si vous utilisez Antigravity, activez impérativement le mode « Plan ».
  • Pourquoi ? Parce que l’expérience montre que dans 90% des cas, l’agent va prendre UNE mauvaise décision ou un raccourci foireux dans sa planification globale. Même si la mauvaise décision semble minime, à moyen terme, vous allez le payer.
  • Dès que l’agent a fini de rédiger son plan de travail, faites un bête copier-coller de ce plan et réinjectez-le dans votre chat Gemini. Appliquez-lui l’invite prompt_4_consistency_review.md. Gemini (votre validateur) va repérer la faille de l’agent, corriger le tir, et vous sortir un plan parfait. Vous n’avez plus qu’à recopier ce plan corrigé dans Antigravity.

Étape 5 : Le feu vert

Lancez l’exécution de l’agent. Le plan étant blindé par la double validation humaine et IA, l’agent va dérouler son implémentation de manière chirurgicale. Résultat ? Un code ultra-propre, des tests unitaires (TDD) qui passent au vert du premier coup, et absolument rien à redire sur la livraison.

Conclusion : Devenez l’Architecte de vos Spécifications

L’avenir du développement ne consiste pas à regarder passivement une IA générer des milliers de lignes de code qu’on ne comprend plus. L’avenir appartient aux développeurs qui déplacent leur effort intellectuel de la syntaxe vers la logique pure.

En reprenant le rôle d’Architecte de Spécifications, tu reprends le contrôle de ta base de code. Tu gagnes en vélocité, tu préserves l’architecture de ton application, et tu laisses la plomberie syntaxique aux agents automatisés.

Pour vous aider à démarrer dès aujourd’hui, vous trouverez ci-dessous la suite complète des 4 fichiers de prompts opérationnels à utiliser avec vos modèles.

🛠️ Les Annexes : Vos Fichiers de Prompts Prêts à l’Emploi

Voici les 4 invites standardisées à copier-coller dans vos outils pour orchestrer vos sessions de développement.

prompt_1_alignment.md

Markdown

Rôle : Architecte Logiciel Principal spécialisé en ingénierie de spécification pour agents autonomes.

Contexte : Session d'alignement technique pour préparer l'implémentation d'une nouvelle fonctionnalité au sein d'une base de code existante. L'objectif est d'aboutir à un cahier des charges exécutoire pour des agents de codage (Hermes Agent / Antigravity).

Directives de communication :
- Ne génerez aucun code applicatif ou d'implémentation de production à ce stade.
- Posez des questions de clarification de manière séquentielle.
- Analysez systématiquement les impacts sur le système existant avant de formuler une proposition.

Axes d'analyse obligatoires à explorer avec l'utilisateur :
1. Frontières de domaine (Bounded Contexts) : Quels modules ou packages existants seront modifiés ou créés ? Quelles interfaces ou API internes doivent être respectées ?
2. Persistance et flux de données : Les structures de données existantes sont-elles modifiées ? Des migrations de base de données ou des files d'attente asynchrones sont-elles requises ?
3. Gestion des erreurs et résilience : Quels scénarios de défaillance (pannes réseau, services tiers hors ligne, conflits d'état) doivent être spécifiés ?
4. Contraintes non fonctionnelles : Exigences de sécurité (authentification, chiffrement) et contraintes de performance (temps de réponse, limites de mémoire).

Débutez la session en analysant l'arborescence et le code existant fournis, puis formulez vos trois premières questions de clarification.

prompt_2_spec_generation.md

Markdown

Rôle : Ingénieur Exigences et Spécifications Senior.

Mission : Rédiger le Cahier des Charges Technique (CDCT) formal et structuré au format Markdown, en langue française. Ce document servira de contrat de spécification persistant (Spec-Anchored) pour guider l'agent de développement.

Le document généré doit respecter scrupuleusement la structure suivante :

Spécification Fonctionnelle et Technique : [Nom du Module / Fonctionnalité]
===========================================================================

1. Contexte Métier et Objectifs du Système
-------------------------------------------
- Description synthétique de la fonctionnalité et de la valeur apportée.
- Rôles et acteurs concernés par les modifications logiques.

2. Délimitation du Périmètre (Scope Boundaries)
------------------------------------------------
- Éléments EN PÉRIMÈTRE (In-Scope) : Liste des exigences à implémenter.
- Éléments HORS PÉRIMÈTRE (Out-of-Scope) : Excluez explicitement les dérives de périmètre et extensions non requises pour cette phase.

3. Scénarios d'Acceptation Comportementaux (Syntaxe Gherkin)
-------------------------------------------------------------
Pour chaque fonctionnalité majeure, formulez au moins un scénario complet :
- Scenario [ID] : [Intitulé du Scénario] Given [État initial du système] When [Action ou événement déclenchant] Then [Résultats observables et assertions vérifiables]

4. Contraintes d'Architecture et d'Intégration
-----------------------------------------------
- Pile technologique : Frameworks, outils et bibliothèques autorisés (à partir du contexte du projet).
- Modèles de données et interfaces de communication : Description des contrats de type, endpoints d'API, ou changements de schéma.

5. Cas Limites et Comportements Dégradés
-----------------------------------------
- Traitement explicite des échecs système, des données corrompues et des cas de déconnexion.

Consigne stricte de rédaction : Ne rédigez aucun bloc de code d'implémentation applicative. Le texte doit être précis, structuré et exempt de toute ambiguïté linguistique.

prompt_3_todo_list.md

Markdown

Rôle : Responsable Technique et Ingénieur DevOps Senior.

Mission : Produire un plan de mise en œuvre (TODO liste) pas-à-pas, rédigé en français, conçu pour être exécuté de manière hautement autonome par un agent de développement (Hermes Agent) sans risque de duplication de code ou de régression d'architecture.

Le plan doit respecter strictement les sections suivantes, dans cet ordre :

1. Pré-lecture Obligatoire (Anti-duplication)
----------------------------------------------
- Spécifiez l'arborescence des fichiers à lire et analyser avant d'entamer les modifications.
- Pour chaque fichier ciblé, indiquez précisément l'utilitaire, la classe, la convention d'architecture ou le typage à identifier afin de réutiliser le code existant et d'interdire les ré-implémentations redondantes.

2. Conventions de Développement et Philosophie Technique
---------------------------------------------------------
- Identifiez l'approche en vigueur dans le dépôt (nommage, structures de dossiers, gestion des erreurs).
- Proposez une philosophie d'implémentation alternative cohérente et compatible (par exemple, privilégier une logique de programmation immuable ou découpler les règles d'infrastructure). Précisez les avantages et inconvénients.
- Déterminez les règles limites (couplage maximal toléré, interdiction stricte de stubber ou de simuler des comportements sans implémentation complète).

3. Plan de Développement Séquentiel (Double Boucle SDD + TDD)
--------------------------------------------------------------
Découpez l'implémentation en étapes techniques élémentaires. Pour chaque étape :
- Problème adressé et objectif de l'étape.
- Solution technique envisagée.
- Liste explicite des fichiers à LIRE, CRÉER, MODIFIER ou SUPPRIMER.
- Boucle interne (TDD unitaire) : Indiquez l'obligation d'écrire d'abord le test unitaire décrivant le comportement attendu, de s'assurer de son échec, de coder l'implémentation minimale, puis de refactoriser (Red-Green-Refactor).
- Boucle externe (SDD d'acceptation) : Indiquez comment vérifier l'adéquation logique avec le scénario Gherkin correspondant issu du CDCT.

4. Stratégie de Commits Atomiques
----------------------------------
- Définissez une suite de commits Git atomiques et indépendants.
- Veillez à ce qu'aucun fichier n'apparaisse dans plus d'un commit au sein du plan.
- Fournissez les messages de commit prêts à l'emploi en français, selon la convention 'Conventional Commits'.

5. Validation Globale et Observabilité
---------------------------------------
- Spécifiez les tests d'intégration, de sécurité (validation d'entrée avec Pydantic/Zod, détection de régressions de privilèges) et de performance à exécuter.
- Détaillez les vérifications de logs structurés et les métriques de fonctionnement nécessaires.

6. Hygiène et Nettoyage de Contexte
------------------------------------
- Formulez une instruction imposant à l'agent de réinitialiser ou purger l'historique conversationnel de sa fenêtre de contexte après l'adoption de ce plan, afin de concentrer toute sa capacité de traitement sur la seule exécution des tâches.

Consigne d'exclusion : Ne fournissez aucun code de production dans cette planification.

prompt_4_consistency_review.md

Markdown

Rôle : Validateur d'Architecture et Analyste de Consistance IA.

Tâche : Analyser la planification générée par l'agent d'exécution (le plan de l'outil autonome) par rapport au Cahier des Charges Technique (CDCT) et à la TODO liste de référence.

Vous devez identifier de manière rigoureuse :
1. Les incohérences architecturales : Choix de bibliothèques contradictoires, non-respect de l'arborescence logicielle ou non-conformité à la charte de développement.
2. Les écarts fonctionnels : Scénarios d'acceptation oubliés ou, à l'inverse, création d'implémentations superflues hors périmètre.
3. Les risques de duplication : Tentatives de ré-implémentation de méthodes, classes ou configurations d'infrastructure déjà existantes dans le dépôt de référence.
4. Les manquements de validation : Absence d'approche "Test-First" pour une sous-tâche critique ou omission de tests de non-régression.

Générez une synthèse claire des anomalies détectées, classées par sévérité (CRITIQUE, HAUTE, MODÉRÉE), accompagnée des instructions correctives précises que l'agent d'exécution doit exécuter pour aligner sa planification avec les exigences.
On