OpenSpec, Spec Kit, BMAD, Superpowers : quel cadre pour piloter un agent de code ?

Un agent de développement moderne sait lire un dépôt, écrire vingt fichiers, lancer la suite de tests et ouvrir une pull request. Ce qu'il ne sait pas faire, c'est se souvenir de ce que le système est censé faire. L'intention vit dans l'historique du chat, elle disparaît avec la fenêtre de contexte, et la session suivante redémarre en redéduisant les règles métier à partir du code, bugs compris.

Quatre cadres se disputent aujourd'hui ce problème : OpenSpec, GitHub Spec Kit, BMAD Method et Superpowers. Ils sont souvent présentés comme interchangeables. Ils ne le sont pas forcément : deux d'entre eux répondent à la question « que doit faire le système ? », un troisième à « comment l'agent doit-il travailler ? », le quatrième à « qui décide quoi ? ». Cet article compare les quatre, puis se concentre sur OpenSpec : son modèle de données, son workflow, ses commandes, et la différence concrète entre l'amorcer sur un projet neuf ou sur un existant.

Le problème que ces outils prétendent résoudre

Le goulot d'étranglement du développement agentic n'est pas la génération de code. C'est la mémoire d'intention. Trois symptômes le signalent, et ils sont universels.

La dérive de périmètre. On demande un endpoint, on reçoit un endpoint plus un refactor de la couche d'accès aux données plus un système de cache. Rien de tout cela n'est faux, rien n'était demandé, et cela se découvre dans un diff de quarante fichiers. Les harnais et les prompts système des providers LLM tendent à résoudre ou, du moins, à minimiser ce problème.

La reprise impossible. Une session interrompue à 70 % ne se reprend pas correctement: l'état mental qui justifiait les choix n'existe nulle part. La session suivante recommence l'exploration et tranche différemment.

La documentation qui ment. Le seul artefact qui décrit le comportement réel du système, c'est le code. Toute autre documentation diverge dès le deuxième sprint, et un agent qui la lit produit du code faux avec une confiance intacte.

Les quatre cadres répondent en externalisant quelque chose hors du chat, dans des fichiers Markdown versionnés avec le code. Leur différence tient entièrement à ce qu'ils externalisent.

Trois familles, pas quatre outils

flowchart LR
  A["Intention produit"] --> B["Spécification"]
  B --> C["Plan technique"]
  C --> D["Implémentation"]
  D --> E["Revue"]
  E --> F["Vérité courante"]
  F --> B

Chaque outil couvre une portion différente de cette chaîne. BMAD commence tout à gauche, à l'intention produit. OpenSpec et Spec Kit occupent le segment spécification-plan-tâches. Superpowers vit sur les deux étapes de droite, implémentation et revue. Seul OpenSpec referme la boucle en consolidant une vérité courante réutilisable.

La conséquence pratique est qu'il n'y a qu'une seule vraie concurrence frontale dans ce paysage : OpenSpec contre Spec Kit. Superpowers ne spécifie rien, il discipline l'exécution ; BMAD couvre la phase produit que les deux autres supposent déjà faite. Combiner OpenSpec ou Spec Kit avec Superpowers est tout à fait possible pour créer un environnement complet.

Un repère d'adoption: Superpowers 286 000+ étoiles, Spec Kit 136 000+, OpenSpec 68 000+, BMAD Method 53 000. Ces chiffres mesurent la visibilité, pas la pertinence pour un projet donné ni le contexte d’entreprise dans lequel celui-ci évolue.

Les concurrents

GitHub Spec Kit

Le principe. Spec Kit est l'implémentation canonique du Spec Driven Development telle que GitHub la promeut : un pipeline imposé qui va des principes du projet jusqu'à l'implémentation, en passant par une spécification et un plan technique. C'est un CLI Python; uv tool install specify-cli qui installe des slash commands dans l'assistant de votre choix, avec une compatibilité annoncée pour plus de trente agents.

Le cycle nominal tient en cinq commandes.

S'y ajoutent des commandes optionnelles utiles : /speckit.clarify pour lever les ambiguïtés avant le plan, /speckit.analyze pour vérifier la cohérence entre spec, plan et tâches, /speckit.checklist pour générer des listes de contrôle, et /speckit.converge qui compare le code réel aux artefacts et rouvre les écarts sous forme de tâches.

Avantages. La constitution est une excellente idée, sous-estimée ailleurs : elle fixe une fois pour toutes ce que l'agent n'a pas le droit de faire, indépendamment de la fonctionnalité en cours. Le pipeline est strict, donc reproductible d'un développeur à l'autre. /speckit.analyze est un vrai filet, une passe de cohérence croisée que personne ne fait à la main. Et le projet est porté par GitHub, ce qui pèse sur la question de la pérennité.

Inconvénients. Le cadre raisonne par fonctionnalité neuve. Chaque feature produit son dossier d'artefacts ; au bout de trente features, on possède trente dossiers qui racontent trente décisions, mais aucun document qui dise ce que le système fait aujourd'hui. Sur un existant, cette absence d'état consolidé se paie : rien ne signale que la feature 12 a invalidé la moitié de la feature 4. Ajoutez une dépendance Python/uv là où le reste de la chaîne est en Node, et une verbosité d'artefacts qui pèse en tokens sur les petites tâches.

BMAD Method

Le principe. BMAD (Breakthrough Method for Agile AI-Driven Development) ne cherche pas d'abord à écrire des spécifications, mais à rejouer une organisation produit avec des agents spécialisés : analyste, product manager, architecte, scrum master, développeur, QA. La phase amont produit un PRD et un document d'architecture ; ceux-ci sont découpés en stories auto-portantes, chaque story embarquant le contexte nécessaire pour être implémentée sans relire le reste.

La v6 a réorganisé le projet en écosystème de modules: méthode principale, builder pour fabriquer ses propres extensions, suite créative, architecte de test, boucle d'amélioration, studio jeu vidéo; et introduit un fonctionnement scale-adaptive : un petit changement va directement à l'implémentation, un chantier complexe traverse toutes les phases. L'installation passe par la CLI skills avec npx skills add bmad-code-org/BMAD-METHOD, ou par une marketplace de plugins.

Avantages. C'est le seul des quatre qui traite sérieusement l'amont produit. Si le problème est « je ne sais pas encore ce que je construis », BMAD est le seul à proposer une démarche plutôt qu'un formulaire. Le découpage en stories auto-portantes est une réponse intelligente à la fenêtre de contexte : chaque unité de travail se suffit à elle-même. Le fonctionnement scale-adaptive corrige le principal reproche fait aux versions précédentes, qui imposaient le cérémonial complet même pour un correctif.

Inconvénients. La courbe d'apprentissage est la plus raide des quatre : rôles, modules, workflows, vocabulaire propre. Le volume documentaire produit est considérable, et ce volume est relu par le modèle à chaque étape, la facture suit. Il faut aussi garder la tête froide sur la mise en scène : ce ne sont pas six experts qui délibèrent, c'est un seul modèle qui joue six rôles, avec les mêmes angles morts dans chacun. Enfin, le projet bouge vite, et ses réorganisations entre versions majeures ont déjà cassé des habitudes établies. Un point d’attention, cependant : la quantité de texte à relire étant très importante, beaucoup de personnes ont tendance à faire confiance au modèle et à lire en diagonale, voire à ne pas relire du tout. Cela casse le principe de cette méthodologie et peut entraîner une surconsommation non négligeable de tokens pour rattraper les erreurs.

Superpowers

Le principe. Superpowers, de Jesse Vincent, n'est pas un cadre de spécification : c'est une méthodologie d'ingénierie livrée sous forme de skills. Le plugin impose un enchaînement de phases, chacune portée par une skill, et refuse de passer à la suivante tant que la précédente n'est pas terminée.

1. Brainstorming socratique : l'agent interroge l'intention avant d'écrire quoi que ce soit.

2. Worktree git : le travail est isolé sur une branche dédiée.

3. Rédaction du plan : découpage en tâches de deux à cinq minutes, spécifiées précisément.

4. Exécution par sous-agents : un sous-agent frais par tâche, ce qui évite la pollution de contexte.

5. TDD strict : cycle rouge-vert-refactor, avec suppression du code écrit avant son test.

6. Revue de code : par un agent qui n'a pas écrit le code, avec classement par sévérité.

7. Clôture de branche : vérification des tests, puis options de fusion.

L'installation se fait par plugin, avec /plugin install superpowers@claude-plugins-official sur Claude Code et des équivalents sur une douzaine d'autres agents.

Avantages. C'est le cadre qui améliore le plus visiblement la qualité du code produit, parce qu'il attaque le vrai problème de l'exécution : l'agent qui déclare victoire trop tôt. Le TDD réellement appliqué, la revue par un agent frais et l'isolation en worktree sont trois garde-fous qu'aucune spécification ne remplace. Il ne demande aucun apprentissage : c'est l'agent qui porte la méthode, pas le développeur. Suivant le harnais que vous utilisez, le bénéfice peut être plus ou moins important.

Inconvénients. Aucune mémoire de produit. Le plan est un artefact de branche : il meurt avec la fusion, et rien ne consolide « ce que le système fait ». Sur la durée, on obtient des commits impeccables et toujours aucune source de vérité. Le coût est élevé, sous-agents multipliés, TDD intégral, double revue et le dogmatisme TDD s'adapte mal à certains travaux réels : intégration d'une API tierce, mise au point d'interface, exploration. C'est un excellent comment, pas un quoi.

Les autres

Le paysage ne s'arrête pas là. Kiro, l'IDE agentique d'AWS, embarque un mode spec qui décompose une demande en exigences, conception et tâches, avec des exigences formulées en notation EARS : la démarche est proche, mais elle est liée à l'outil. Des approches plus légères existent aussi : un AGENTS.md discipliné, une constitution maison, un dossier d'ADR. Pour un projet solo de taille modeste, cette option mérite d'être considérée sérieusement avant d'installer quoi que ce soit, la moitié du bénéfice vient du fait d'écrire l'intention, pas de l'outil qui la range.

Tableau comparatif

OpenSpec : le pari du delta

Ce que c'est

OpenSpec est un CLI Node publié par Fission AI sous le paquet @fission-ai/openspec. Pas de clé API, pas de service tiers, pas de base de données : un dossier openspec/ de Markdown versionné avec le code, plus un jeu de commandes installées dans votre assistant.

npm install -g @fission-ai/openspec@latest
openspec init

openspec init demande quels assistants configurer : la liste dépasse la trentaine, de Claude Code à Cursor, Copilot, Codex, opencode, Gemini CLI, Amazon Q, Zed ou Kiro et écrit les commandes au format attendu par chacun. L'option --language fixe la langue de rédaction des artefacts : un projet francophone écrit ses spécifications en français sans avoir à le redemander à chaque prompt.

Le pari central

Les autres cadres écrivent une spécification par fonctionnalité. OpenSpec sépare deux objets qui n'ont pas la même durée de vie.

• openspec/specs/ : la vérité courante, organisée par capacité : ce que le système fait aujourd'hui, un fichier par domaine fonctionnel.

• openspec/changes/ : le travail en cours, exprimé en delta : non pas une nouvelle version de la spec, mais ce que ce changement ajoute, modifie ou supprime.

À l'archivage du changement, le delta est fusionné dans la spec principale. Cette mécanique a une conséquence qui justifie à elle seule l'outil : le seul moyen de modifier la vérité courante est de passer par un changement archivé. La documentation ne peut pas diverger silencieusement, parce qu'il n'existe pas de chemin prévu pour l'écrire à la main.

C'est aussi ce qui rend le cadre utilisable sur un existant. Spécifier un système déjà construit est un chantier infini ; spécifier ce qu'on y change est un travail borné.

L'arborescence

openspec/
├── config.yaml                   # contexte projet + règles de rédaction
├── specs/                        # la vérité courante, par capacité
│   └── user-auth/
│       └── spec.md
└── changes/
    ├── add-oidc-login/           # un changement en cours
    │   ├── .openspec.yaml        # métadonnées (schéma, date de création)
    │   ├── proposal.md           # pourquoi et quoi
    │   ├── design.md             # comment (conditionnel)
    │   ├── specs/
    │   │   └── user-auth/
    │   │       └── spec.md       # le delta, pas la spec complète
    │   └── tasks.md              # la checklist d'implémentation
    └── archive/
        └── 2026-09-12-add-oidc-login/

Une capacité est un domaine fonctionnel cohérent, pas un fichier ni une couche technique. user-auth, billing, notifications sont des capacités ; services, controllers, utils n'en sont pas. C'est le découpage le plus structurant du dispositif, et celui qu'on rate le plus souvent au démarrage.

Le format d'une spécification

Une spec est du Markdown, avec deux conventions : des exigences normatives en SHALL, et au moins un scénario par exigence, formulé en WHEN/THEN.

# user-auth Specification

## Purpose
Authentifier les utilisateurs de l'application et protéger les routes privées.

## Requirements

### Requirement: Connexion par mot de passe

Le système SHALL authentifier un utilisateur sur présentation d'un identifiant
et d'un mot de passe valides. Après cinq échecs consécutifs en moins de dix
minutes, le système SHALL verrouiller le compte pendant quinze minutes.

#### Scenario: Identifiants valides

- **WHEN** un utilisateur soumet un identifiant et un mot de passe valides
- **THEN** une session est ouverte et l'utilisateur atteint son tableau de bord

#### Scenario: Verrouillage après échecs répétés

- **WHEN** cinq tentatives échouent en moins de dix minutes
- **THEN** les tentatives suivantes sont refusées pendant quinze minutes, même
  avec un mot de passe correct

Le SHALL n'est pas une coquetterie normative : il force une formulation vérifiable. « Le système gère les erreurs » ne s'écrit pas avec un SHALL sans devenir visiblement creux. Le scénario WHEN/THEN joue le même rôle un cran plus bas : s'il n'est pas transposable en test automatisé, c'est que l'exigence est encore floue. openspec validate --strict refuse d'ailleurs une exigence sans scénario.

Le format d'un delta

C'est la partie qui surprend au début, et celle qui porte toute la valeur du cadre.

## ADDED Requirements

### Requirement: Connexion par fournisseur OIDC

Le système SHALL permettre la connexion via un fournisseur OIDC configuré et
SHALL rattacher l'identité externe à un compte existant lorsque l'adresse
e-mail vérifiée correspond.

#### Scenario: Première connexion OIDC

- **WHEN** un utilisateur inconnu se connecte via le fournisseur
- **THEN** un compte est créé et la session est ouverte

## MODIFIED Requirements

### Requirement: Connexion par mot de passe

Le système SHALL authentifier un utilisateur sur présentation d'un identifiant
et d'un mot de passe valides, sauf si le compte est rattaché à un fournisseur
OIDC exclusif, auquel cas la connexion par mot de passe SHALL être refusée.

#### Scenario: Compte OIDC exclusif

- **WHEN** un utilisateur d'un compte OIDC exclusif tente une connexion par
  mot de passe
- **THEN** la connexion est refusée et le fournisseur lui est proposé

## REMOVED Requirements

### Requirement: Connexion par lien magique

Trois pièges méritent d'être connus avant le premier delta, parce qu'ils ne se révèlent qu'à l'archivage :

• Un bloc MODIFIED contient le texte complet de la nouvelle exigence, pas un diff. L'archivage remplace l'exigence existante par ce bloc : ce qui n'y figure pas est perdu.

• Le titre de l'exigence sert de clé de correspondance. Un titre reformulé côté delta ne modifie pas l'exigence existante, il en crée une seconde.

• On n'inclut jamais de section ## Purpose dans un delta portant sur une capacité déjà existante : cette section ne sert qu'à amorcer une capacité nouvelle.

Les quatre artefacts d'un changement

Le schéma par défaut s'appelle spec-driven et enchaîne quatre artefacts dans un ordre de dépendances : proposal → specs → design → tasks.

La qualité d'un tasks.md se joue sur un détail : chaque tâche porte son critère de vérification. Comparez ces deux formulations de la même tâche.

3.2 Ajouter l'authentification par clé sur l'endpoint.

3.2 Extraire l'en-tête Authorization: Bearer, résoudre la clé par empreinte, répondre 401 en JSON si elle est absente ou invalide ; vérifier par test fonctionnel l'accès autorisé avec une clé valide, et le refus 401 sans clé puis avec une clé inconnue.

La première autorise l'agent à décider lui-même qu'il a fini. La seconde lui impose une condition de sortie qu'il ne peut pas négocier avec lui-même. C'est le meilleur rapport effort/bénéfice de tout le cadre.

Le workflow

Les commandes d'agent

OpenSpec installe un jeu de commandes appelé opsx dans l'assistant. Le profil par défaut, dit core, en expose six.

Un profil expanded ajoute six commandes plus fines, activables via openspec config profile : /opsx:new pour créer la coquille d'un changement sans rien générer, /opsx:continue pour produire un seul artefact suivant dans la chaîne de dépendances, /opsx:ff pour tout générer d'un coup quand la vision est déjà claire, /opsx:verify pour confronter l'implémentation aux artefacts, /opsx:bulk-archive pour solder plusieurs changements terminés, et /opsx:onboard pour un tour guidé de bout en bout.

La syntaxe d'invocation varie selon l'outil : /opsx:propose sur Claude Code, /opsx-propose sur Cursor, Copilot ou opencode, @opsx-propose sur Amazon Q, $openspec-propose sur Codex. openspec init affiche la forme correcte pour les outils sélectionnés.

Le point important n'est pas la liste : c'est que ces commandes portent une frontière de planification explicite. La commande propose a l'interdiction d'écrire du code, même si la demande initiale disait « ajoute l'authentification OIDC ». Elle produit les artefacts, puis s'arrête et attend. C'est ce refus qui crée le moment de revue.

Le cycle complet

flowchart TD
  I["Idée"] --> E["/opsx:explore"]
  E --> P["/opsx:propose"]
  P --> R{"Revue humaine du proposal"}
  R -- "périmètre à corriger" --> U["/opsx:update"]
  U --> R
  R -- "validé" --> A["/opsx:apply"]
  A --> T{"Tests et vérifications"}
  T -- "rouge" --> A
  T -- "vert" --> Z["/opsx:archive"]
  Z --> S["specs/ mis à jour"]
  S --> I

Le losange Revue humaine est le seul endroit du cycle où corriger une erreur de conception coûte cinq minutes. Passé ce point, la même correction coûte une implémentation. C'est la raison d'être de tout le dispositif : déplacer la revue d'un diff de 900 lignes vers deux pages de Markdown.

Avertissement sur les sessions : utilisez une session neuve entre chaque étape du cycle. Cela évite d'accumuler un contexte devenu inutile, de réduire les erreurs parasites liées aux échanges précédents et d'optimiser le coût en tokens. Ne faites circuler entre les étapes que les artefacts nécessaires, plutôt que de prolonger indéfiniment la même conversation.

L'archivage, ou ce qui se passe vraiment à la fin

openspec archive n'est pas un git mv. La commande applique chaque section du delta à la spec principale correspondante : les exigences ADDED sont ajoutées, les MODIFIED remplacent leurs homonymes, les REMOVED sont supprimées. Puis le dossier du changement part dans changes/archive/ préfixé par sa date. Si une capacité perd sa dernière exigence et que le changement déclare retire_capabilities: true dans son .openspec.yaml, le fichier de spec disparaît entièrement.

Deux options méritent d'être connues : --skip-specs pour les changements qui ne modifient aucun comportement, outillage, CI, documentation, et -y pour un archivage non interactif dans un script.

Le fichier de configuration, le plus rentable du dossier

openspec/config.yaml injecte du contexte et des règles dans toutes les générations d'artefacts. C'est le seul endroit où l'on écrit une fois ce qu'on répéterait sinon à chaque prompt.

schema: spec-driven

context: |
  Application de gestion interne.
  Stack : AdonisJS 7 + TypeScript, Inertia/React 19, PostgreSQL via Lucid.
  Langue de rédaction des artefacts OpenSpec : français.

rules:
  proposal:
    - Rédiger en français.
    - Lister dans Capabilities les chemins exacts des specs existantes modifiées.
    - Marquer les changements de comportement par **BREAKING**.
  specs:
    - Formulations normatives avec SHALL.
    - Chaque exigence a au moins un scénario WHEN/THEN.
    - Ne jamais inclure `## Purpose` dans un delta pour une capacité existante.
  tasks:
    - Chaque tâche porte son critère de vérification.

operations:
  apply:
    guidance: Lancer lint, typecheck et tests avant de cocher la dernière tâche.

Les entrées de rules ne s'appliquent qu'à l'artefact correspondant, ce qui évite de noyer chaque génération sous des consignes hors sujet. context est global. operations.apply.guidance et operations.archive.guidance ajoutent des conseils à l'exécution, sans valeur contraignante.

Greenfield ou brownfield

Projet neuf : le piège du découpage

Sur un projet qui démarre, specs/ est vide et le restera jusqu'au premier archivage. Tout passe par des changements, et les premiers d'entre eux créent les capacités. Le seul vrai risque à ce stade est le découpage.

Trop fin, on obtient trente capacités d'une exigence chacune, et chaque changement touche quinze fichiers de spec. Trop gros, une capacité app finit par contenir tout le système et ne dit plus rien. Le repère qui fonctionne : une capacité regroupe les comportements qu'un même responsable métier voudrait relire ensemble. Si deux exigences ne seraient jamais discutées dans la même réunion, elles n'appartiennent pas à la même capacité.

Deuxième conseil pour un projet neuf : archiver au fil de l'eau, pas en fin de sprint. Tant qu'un changement n'est pas archivé, il n'a rien écrit dans specs/ ; le changement suivant ne peut donc pas produire de delta MODIFIED contre une exigence qui n'existe pas encore officiellement. On se retrouve à écrire des commentaires du type « ce point sera couvert quand le changement précédent sera archivé », c'est exactement ce qui arrive quand on empile cinq changements avant le premier archivage, et le rattrapage se paie en consolidation manuelle.

Existant : ne rétro-spécifiez pas tout

La tentation, sur un dépôt de trois ans, est de lancer l'agent sur le code et de lui demander de produire les specs de l'existant. C'est le principal anti-pattern du cadre, pour trois raisons.

• Le code ne dit pas l'intention. Il dit l'implémentation, y compris ses bugs. Une rétro-spécification transforme les défauts actuels en exigences officielles, et les grave dans la source de vérité.

• Le résultat est plausible et invérifiable. Un agent produira cinquante pages parfaitement formées. Personne ne les relira sérieusement, et une exigence non relue est pire que pas d'exigence : elle sera opposée aux changements futurs.

• Le rendement est nul sur le code froid. Les zones qu'on ne touche pas n'ont aucun besoin d'être spécifiées.

La stratégie qui fonctionne est l'adoption par incrément : on ne spécifie que ce qu'on touche. Le premier changement sur le module de facturation crée la capacité billing avec les exigences concernée, celles qu'on modifie, plus celles qu'on doit préserver et qu'on tient donc à écrire. Après une dizaine de changements, les zones chaudes du système sont spécifiées, les zones froides n'ont rien coûté, et chaque exigence présente a été relue par quelqu'un.

Un compromis raisonnable existe pour les domaines critiques : authentification, facturation, droits d'accès : un atelier avec l'agent en mode explore, qui propose une ossature d'exigences à partir du code, suivi d'une relecture ligne à ligne par un humain qui connaît le métier. La relecture n'est pas optionnelle : c'est elle qui fait la différence entre une spécification et une paraphrase du code.

flowchart TD
  A["Dépôt existant"] --> B{"Zone touchée par le prochain chantier ?"}
  B -- non --> C["Ne rien spécifier"]
  B -- oui --> D{"Domaine critique ?"}
  D -- non --> E["Capacité créée par le changement lui-même"]
  D -- oui --> F["Ossature en mode explore"]
  F --> G["Relecture humaine ligne à ligne"]
  G --> E

Ce que le cadre apporte de plus sur un existant

Un bénéfice qu'on ne mesure qu'après quelques semaines : changes/archive/ devient le registre du pourquoi. Un git log dit qu'une contrainte de verrouillage a été ajoutée en mars ; l'archive dit pourquoi, ce qui avait été écarté, et quel risque avait été accepté. C'est la documentation que personne n'écrit jamais, produite ici comme sous-produit du processus.

Retour d'expérience sur un projet réel

J'utilise OpenSpec sur des outils personnels, notamment le dernier en date : une application AdonisJS et Inertia, pilotée avec opencode et initialisée avec le cadre dès le premier jour. Voici quelques chiffres après un peu plus d'une semaine de travail sur cet outil : 14 capacités, 90 exigences, 12 changements archivés. Cinq enseignements s'en dégagent.

Le changement est la bonne unité de session. Une session agentique qui commence par « reprends le changement x, tâche 4.2 » n'a pas besoin de reconstituer d'état mental. C'est le gain le plus immédiat, et il est indépendant de la qualité des specs.

Les critères de vérification associés aux tâches transforment la manière d’implémenter. On sait dès le départ ce qu’il faudra contrôler. Par exemple, un élément insuffisamment précisé dans le prompt peut conduire à une interprétation erronée et à un résultat incorrect, mais ici le cas ne se produit plus si le document initial a bien été relu.

Le config.yaml rapporte plus que tout le reste. Langue, conventions, interdits, format attendu : trente lignes qui évitent trente rappels par jour, et qui rendent les artefacts comparables entre eux.

L'archivage tardif se paie. Les premiers changements ont été empilés sans archivage, avec pour conséquence des deltas MODIFIED impossibles à écrire et des commentaires d'excuse dans les proposals.

Le proposal est le document à relire, pas les specs. En pratique, 90 % des corrections utiles portent sur la section What Changes du proposal : un périmètre trop large, une fonctionnalité ajoutée d'initiative, un impact sous-estimé. Les deltas, eux, sont plutôt bien produits dès lors que le config.yaml impose le format.

Il convient évidemment de nuancer tout cela selon votre expérience, la qualité des prompts, l'activation ou non du mode plan natif des harnais pour les tâches complexes, ainsi que la qualité du harnais utilisé. Soyons honnêtes : sur un outil de cette ampleur, cela ne bouleverse pas vraiment le Vibe Coding classique ; la plus-value apparaîtra surtout avec le temps, lorsque l'outil aura traversé un cycle de vie et continuera d'intégrer de nouvelles fonctionnalités. Les specs rendent également envisageable le recodage relativement aisé de l'application dans un autre langage ou framework.En l'utilisant, vous faites toutefois un premier pas dans la cour du Vibe Engineering.

Les limites d'OpenSpec

Un article qui ne liste pas les limites de l'outil qu'il défend n'est pas un article, c'est une brochure. Voici les miennes.

Aucun lien mécanique entre spec et code. Rien n'empêche l'implémentation de diverger de l'exigence archivée. Le seul lien réel est le test : d'où l'importance des critères de vérification dans les tâches, et l'intérêt de faire pointer les tests vers les scénarios qu'ils couvrent. L'utilisation d'un bon modèle permet de minimiser ce risque.

Le coût n'est pas nul. Quatre documents, une revue, une validation, un archivage : sur un correctif d'une ligne, c'est du pur surcoût. Le seuil de rentabilité est stable et facile à mémoriser, le cadre devient payant dès que la tâche touche plus de trois fichiers, introduit une notion de domaine, ou modifie un contrat : schéma de base, endpoint, format d'événement.

Les conflits de fusion sur specs/. Deux changements parallèles sur la même capacité produisent deux deltas qui se marchent dessus à l'archivage. La parade est organisationnelle : sérialiser par capacité, ou archiver le premier avant de rebaser le second.

Une surface qui grossit vite. Stores, worksets, schémas personnalisés, profils de workflow : le projet ajoute des concepts à bon rythme. Tout adopter d'emblée revient à remplacer un problème de discipline par un problème d'outillage. Épinglez une version dans les projets d'équipe, et lancez openspec update en connaissance de cause après chaque montée.

Comment choisir

flowchart TD
  A["Un chantier à lancer"] --> B{"Moins de trois fichiers, pas de contrat modifié ?"}
  B -- oui --> R1["Aucun cadre : demande directe"]
  B -- non --> C{"Le quoi est-il déjà tranché ?"}
  C -- non --> D{"Besoin produit amont réel, plusieurs parties prenantes ?"}
  D -- oui --> R2["BMAD Method"]
  D -- non --> R3["OpenSpec en mode explore puis propose"]
  C -- oui --> E{"Code existant à faire évoluer ?"}
  E -- oui --> R4["OpenSpec"]
  E -- non --> F{"Pipeline imposé souhaité par l'équipe ?"}
  F -- oui --> R5["Spec Kit"]
  F -- non --> R4

Et surtout, la combinaison qui a le plus de sens en pratique : OpenSpec pour le quoi, Superpowers pour le comment. Le premier décide et mémorise ce que le système doit faire ; le second impose au moment d'implémenter un TDD réel, une isolation en worktree et une revue par un agent frais. Ils ne se recouvrent pas, et chacun bouche exactement le trou de l'autre, l'absence de discipline d'exécution chez OpenSpec, l'absence de mémoire produit chez Superpowers.

Ce que je retiens

Le débat public oppose des outils. Le vrai choix porte sur ce qu'on accepte d'écrire avant de générer, et personne ne peut y couper : un agent qui ne sait pas ce que le système doit faire l'invente, et il l'invente bien, c'est précisément ce qui rend l'erreur coûteuse.

OpenSpec a le meilleur rapport contrainte/bénéfice des quatre parce qu'il ne demande qu'une chose : que la modification du comportement passe par un document relu. Le reste : format des exigences, scénarios, archivage n'est que la mécanique qui rend cette règle applicable. Et son pari sur le delta est le seul qui produise, sans effort supplémentaire, une documentation qui n'a pas le droit de mentir.

Mais la mécanique ne remplace pas la relecture. Le seul moment qui compte dans tout ce cycle tient en cinq minutes : celles pendant lesquelles un humain lit la section What Changes d'un proposal et dit non.