Quelle est la différence entre Spec-Driven Development et TDD ?

Le TDD (Test-Driven Development) écrit des tests avant le code. Le SDD écrit la spec du livrable avant tout, et les tests deviennent un des outputs de cette spec. Le SDD est plus large : il couvre l'intention métier, pas seulement la validation technique. Pour un cabinet, la spec couvre l'audience, la longueur, le ton, les données autorisées et les critères d'acceptation.

Quelle différence entre vibe coding et Spec-Driven Development ?

Le vibe coding consiste à prompter à l'improvisation et à itérer sur ce que l'IA renvoie. C'est l'opposé du SDD. Le SDD acte la spec en amont, le vibe coding la découvre en cours de route. Pour un livrable client signé par un associé, le vibe coding est ingérable : aucune trace de l'intention initiale.

Le Spec-Driven Development est-il applicable hors développement logiciel ?

Oui. Le principe (spec écrite avant prompt) est agnostique du domaine. Les toolkits officiels comme GitHub Spec Kit ou OpenSpec sont code-first, mais la méthode se transpose à n'importe quel livrable formel : mémo stratégique, due diligence, conclusion d'avocat, dossier d'audit fiduciaire.

Comment le Spec-Driven Development aide-t-il à la conformité RGPD ?

La spec acte par écrit quelles données entrent dans le prompt, quel est le but du traitement et quel outil est utilisé. Elle matérialise le privacy by design recommandé par la CNIL dans ses recommandations du 7 février 2025 et devient une preuve documentaire opposable en cas de contrôle ou de demande client.

Combien de temps faut-il pour rédiger une spec ?

Pour un livrable récurrent (mémo, due dil, audit annuel) : 10 à 20 minutes une fois le template établi. La première spec d'un type de livrable prend plus de temps (1 à 2 heures) car elle sert de template pour toutes les suivantes.

Faut-il un outil dédié ou un Google Doc suffit ?

Pour démarrer, un Google Doc ou un Notion partagé suffit. Les outils comme GitHub Spec Kit ou OpenSpec deviennent utiles quand plusieurs personnes versionnent des dizaines de specs ou orchestrent des agents IA en chaîne. Commencer simple est presque toujours la bonne décision.

Spec-Driven Development pour cabinets conseil : la méthode 2026

TL;DR

Le Spec-Driven Development (SDD) est une méthode d’ingénierie logicielle formalisée par GitHub en septembre 2025, dans laquelle la spécification écrite du livrable précède tout prompt envoyé à un modèle d’IA et sert de source de vérité unique. Le toolkit officiel GitHub Spec Kit dépasse 103 000 étoiles GitHub et supporte plus de 30 agents IA dont Anthropic Claude Code, GitHub Copilot, Cursor, Gemini, Qwen et Mistral [source: https://github.com/github/spec-kit]. Doctolib a déployé Claude Code à l’ensemble de son équipe développement après un pilote de 30 ingénieurs [source: https://claude.com/customers/doctolib]. Le protocole en 4 étapes (Specify, Plan, Implement, Validate) se transpose à un mémo stratégique, une due diligence M&A, une conclusion d’avocat ou un dossier d’audit fiduciaire : c’est exactement ce que recouvre la pratique du spec driven development pour un cabinet conseil, un cabinet avocat, une fiduciaire ou une agence communication. La spec écrite répond à deux trous de gouvernance documentés par le Spark Report 2026 : 52 % des agences utilisent l’IA sans gouvernance formelle et 75 % n’ont pas mis à jour leurs contrats clients [source: https://www.wearespark.ai/the-spark-report-ai-in-agencies-benchmark]. Côté conformité, la spec matérialise le privacy by design exigé par la CNIL dans ses recommandations du 7 février 2025 [source: https://www.cnil.fr/fr/ia-et-rgpd-la-cnil-publie-ses-nouvelles-recommandations-pour-accompagner-une-innovation-responsable].

Key Takeaways

Définition. Le Spec-Driven Development est une méthodologie où la spécification écrite est l’artefact source et le code (ou le livrable) est généré contre cette spec, et non l’inverse [source: https://github.com/github/spec-kit/blob/main/spec-driven.md].
Origine. GitHub a publié Spec Kit en open source en septembre 2025. Den Delimarsky, Principal Product Manager chez GitHub, en est l’auteur principal [source: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/].
Adoption mesurée. GitHub Spec Kit cumule 103 000 étoiles et 9 000 forks ; OpenSpec, maintenu par Fission AI, cumule 49 100 étoiles et 3 500 forks [source: https://github.com/Fission-AI/OpenSpec].
Cas d’usage entreprise. Doctolib a déployé Anthropic Claude Code à l’ensemble de son équipe développement après un pilote de 30 ingénieurs ; Julien Tanay, Staff Engineer chez Doctolib, rapporte une migration des tests de régression visuelle « completed in hours, not weeks » [source: https://claude.com/customers/doctolib].
Pression marché. 49 % des métiers analysés exécutent désormais au moins 25 % de leurs tâches via Claude selon l’Anthropic Economic Index de mars 2026 [source: https://www.anthropic.com/research/economic-index-march-2026-report].
Conformité. La CNIL exige depuis le 7 février 2025 le privacy by design dès la conception de l’usage IA, et publie 13 fiches pratiques actualisées [source: https://www.cnil.fr/fr/les-fiches-pratiques-ia].

Le Spec-Driven Development en 2 minutes : pourquoi Doctolib bascule son équipe dev

Le spec driven development, dans sa méthode française adaptée aux services professionnels PME, désigne une discipline dans laquelle la spécification écrite du livrable est rédigée avant tout prompt à l’IA et sert de source de vérité unique pour la production et la validation. La spec décrit le résultat attendu, les contraintes, les données autorisées et les critères de validation. Le code, le mémo ou la note que l’IA produit n’est qu’un output généré contre cette spec.

GitHub a formalisé l’approche en septembre 2025 avec son toolkit open source Spec Kit. La position est nette : selon la documentation Specification-Driven Development de GitHub, « Specifications don’t serve code, code serves specifications » [source: https://github.com/github/spec-kit/blob/main/spec-driven.md]. Den Delimarsky, Principal Product Manager chez GitHub, résume le shift dans le billet de lancement : « Instead of reviewing thousand-line code dumps, you review focused changes that solve specific problems » [source: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/]. Le repo Spec Kit dépasse 103 000 étoiles GitHub et supporte plus de 30 agents IA, dont Anthropic Claude Code, GitHub Copilot, Cursor, Google Gemini, Qwen et Mistral [source: https://github.com/github/spec-kit]. En parallèle, OpenSpec maintenu par Fission AI propose un workflow alternatif en quatre étapes (Propose, Plan, Apply, Archive) et cumule 49 100 étoiles GitHub [source: https://github.com/Fission-AI/OpenSpec].

Doctolib a appliqué ces principes à grande échelle. L’entreprise a démarré par un pilote de 30 ingénieurs avant de déployer Anthropic Claude Code à l’ensemble de son équipe développement [source: https://claude.com/customers/doctolib]. Julien Tanay, Staff Engineer chez Doctolib, rapporte trois résultats vérifiables : migration des tests de régression visuelle « completed in hours, not weeks », onboarding sur de nouveaux projets ramené « de semaines à jours », setup IDE auto-onboardé en moins de 5 minutes [source: https://claude.com/customers/doctolib]. L’objectif n’est pas de remplacer les ingénieurs. C’est de leur faire produire un cahier des charges exécutable que l’IA traduit mécaniquement, avec une revue humaine concentrée sur l’intention plutôt que sur des milliers de lignes de code. Pour comprendre comment la même CLI est utilisée hors développement pur, voir notre revue Claude Code pour cabinets conseil : cas d’usage.

Pourquoi cette méthode tech se transpose aux cabinets conseil, agences et fiduciaires

Un livrable de cabinet est une spec implicite. Une note de cadrage stratégique, une due diligence, un audit fiduciaire ou une conclusion d’avocat répond à un cahier des charges qui vit aujourd’hui dans la tête de l’associé responsable et dans des emails clients dispersés. Quand un collaborateur ou une IA produit un brouillon, il est comparé à une intention floue. D’où les allers-retours, les corrections de dernière minute et la sensation persistante que « ce n’est pas exactement ce que je voulais ».

Le SDD matérialise cette intention en amont. La spec devient l’artefact partagé entre l’associé, le collaborateur et l’IA : c’est la base pour structurer les prompts IA d’un cabinet conseil sans réinventer la consigne à chaque mission. Trois données récentes valident l’urgence du sujet.

Le marché bouge vite. Selon l’Anthropic Economic Index de mars 2026, 49 % des métiers analysés exécutent désormais au moins 25 % de leurs tâches via Claude. Les tâches de management dans Claude.ai sont passées de 3 % à 5 % du trafic en trois mois. Les occupations légales atteignent 20,4 % d’exposition observée à l’IA, contre 89 % de capacité théorique [source: https://www.anthropic.com/research/economic-index-march-2026-report].

La gouvernance manque cruellement. Selon le Spark Report 2026 sur l’IA en agence, 70 % des agences restent au stade Expérimentation, 52 % de l’usage IA n’a aucune gouvernance formelle, 75 % n’ont pas mis à jour leurs contrats clients. Pendant ce temps, 89 % des employés économisent du temps chaque semaine, jusqu’à 10 heures hebdomadaires [source: https://www.wearespark.ai/the-spark-report-ai-in-agencies-benchmark]. L’usage existe partout. Le cadre n’existe nulle part.

La valeur du temps d’associé. Un associé qui facture 350 à 500 euros de l’heure passe encore beaucoup de temps à relire des brouillons IA dont la consigne initiale était floue. Une spec écrite en 15 minutes en amont change la nature de la relecture : on coche des critères au lieu de réinventer l’attendu à chaque tour (observation Kreante, à mesurer sur votre propre périmètre avant d’en faire une promesse). Pour creuser la différence avec une approche purement contextuelle, voir prompt engineering vs context engineering pour cabinets.

Le protocole en 4 étapes adapté aux livrables clients

Le protocole SDD adapté aux cabinets et agences est une boucle en quatre étapes (Specify, Plan, Implement, Validate) qui reprend la structure officielle de GitHub Spec Kit en remplaçant le code par le livrable client [source: https://github.com/github/spec-kit].

1. Specify : écrire la spec. L’associé responsable rédige ou dicte en 10 à 20 minutes : type de livrable, audience, longueur cible, ton, données autorisées, données interdites, sources à citer, critères d’acceptation. Aucun prompt IA à ce stade. C’est l’étape la plus rentable du protocole.

2. Plan : faire générer un plan par l’IA. Vous envoyez la spec à l’outil (Anthropic Claude, ChatGPT Enterprise ou Mistral selon votre stack) et vous demandez un plan d’exécution structuré : table des matières du mémo, séquence des tests de due dil, points juridiques à traiter, calendrier. Le plan est validé ou ajusté. Toujours pas de production.

3. Implement : laisser l’IA produire le brouillon contre la spec et le plan validés. Le collaborateur ou l’associé pilote la génération section par section. Chaque output référence explicitement quelle partie de la spec il sert. Si une section ne peut pas se rattacher à une exigence de la spec, c’est qu’elle ne devrait pas exister, ou que la spec était incomplète.

4. Validate : vérifier le livrable contre la spec initiale. Si la spec disait « trois scénarios chiffrés », on coche trois scénarios chiffrés. Si elle disait « aucune donnée client nominative », on cherche les noms et on les retire. La revue devient mécanique sur la conformité, et concentrée sur le jugement métier là où il a réellement de la valeur.

Cette boucle reprend les principes posés par GitHub dans la définition officielle : specs comme lingua franca entre humains et IA, raffinement continu, feedback bidirectionnel entre production et spec [source: https://github.com/github/spec-kit/blob/main/spec-driven.md]. Concrètement, ce qui sort d’une mission (commentaires client, points qui ont manqué) nourrit la spec de la mission suivante.

Cas pratiques : mémo stratégique, due diligence, conclusion juridique, dossier d’audit

Voici quatre transpositions concrètes du protocole SDD aux livrables formels d’un cabinet, chacune avec sa spec type.

Mémo stratégique pour un comité de direction

Spec : note de 5 pages maximum, audience CODIR, hypothèse centrale plus 3 alternatives chiffrées, données autorisées issues du dossier client X uniquement, ton factuel sans recommandation finale, citation systématique des sources. L’IA génère le plan, l’associé valide, puis le collaborateur senior produit chaque section et vérifie les chiffres contre les sources fournies. C’est typiquement le livrable d’un cabinet conseil ou d’une agence communication qui peut absorber la méthode dès la semaine 1.

Due diligence M&A

Spec : checklist de 80 points sur la cible Y, focus financier, juridique et commercial, exclusion explicite de la fiscalité (traitée à part), citation systématique de la pièce du data room, score de risque par point. La spec sert aussi de bordereau de traçabilité pour le client : elle prouve ce qui a été regardé, et ce qui ne l’a pas été.

Conclusion juridique (cabinet avocat)

Spec : avis sur la qualification contractuelle d’une clause, droit applicable français, sources limitées aux arrêts postérieurs à 2020, structure question juridique / règles applicables / application au cas / conclusion. La spec acte par écrit le périmètre couvert et celui qui ne l’est pas. C’est précisément ce que les avocats font déjà dans leurs lettres de mission, formalisé pour l’IA. Le spec driven development pour un cabinet avocat ne change pas la rédaction juridique, il rend opposable la consigne donnée à l’outil.

Dossier d’audit fiduciaire ou expert-comptable

Spec : revue analytique des comptes 2025, comparatif 3 ans, identification des écarts supérieurs à 10 %, conformité aux normes locales applicables (PCG en France, Swiss GAAP RPC en Suisse, Lux GAAP au Luxembourg). La spec inclut la liste exacte des fichiers comptables transmis et le périmètre exclu. Pour une fiduciaire ou un expert-comptable, la spec sert de pièce de dossier permanent et facilite la revue qualité du superviseur.

Dans chaque cas, la spec elle-même devient un livrable secondaire. Elle peut être annexée au dossier client pour prouver la rigueur méthodologique, ou conservée en interne pour la revue qualité.

Spec écrite = bouclier RGPD et AI Act : ce que la CNIL attend vraiment

La CNIL a publié le 7 février 2025 ses recommandations actualisées IA et RGPD, qui imposent deux exigences directement applicables aux cabinets et agences utilisant l’IA générative [source: https://www.cnil.fr/fr/ia-et-rgpd-la-cnil-publie-ses-nouvelles-recommandations-pour-accompagner-une-innovation-responsable].

Le privacy by design dès la conception du modèle. La CNIL demande aux organisations de « faire tous leurs efforts pour prendre en compte la protection de la vie privée dès le stade de la conception du modèle ». Pour un cabinet qui n’entraîne pas de modèle mais l’utilise, la traduction concrète est de documenter en amont quelles données entrent dans le prompt, lesquelles sont interdites, quel est le but du traitement et quelle est la durée de conservation des échanges [source: https://www.cnil.fr/fr/ia-et-rgpd-la-cnil-publie-ses-nouvelles-recommandations-pour-accompagner-une-innovation-responsable].

La qualification des rôles et la transparence. Selon les 13 fiches pratiques IA de la CNIL, chaque organisation doit qualifier son rôle (responsable de traitement, responsable conjoint, sous-traitant) et informer les personnes concernées dès que des données personnelles sont utilisées par un système d’IA susceptible de les mémoriser. Une AIPD (analyse d’impact) est recommandée pour les traitements à risque élevé [source: https://www.cnil.fr/fr/les-fiches-pratiques-ia].

La spec écrite répond directement à ces deux exigences. Elle acte par écrit, avant chaque mission IA-assistée :

la nature des données envoyées (anonymisées, pseudonymisées, clients nommés) ;
l’outil utilisé, sa localisation et son statut contractuel (Anthropic Claude Enterprise, OpenAI ChatGPT Enterprise, Mistral hébergé) ;
la base légale invoquée ;
la durée de conservation des prompts et outputs ;
la mention faite ou non au client final.

En cas de contrôle CNIL ou de question d’un client, la spec devient une preuve documentaire. C’est précisément le point que nous détaillons dans la checklist RGPD IA générative pour cabinet conseil et dans notre lecture de ce que l’AI Act change pour les PME FR/CH/BE/LU. Elle est aussi la pièce idéale à annexer à un avenant contractuel, à l’heure où 75 % des agences n’ont pas encore mis à jour leurs contrats clients selon le Spark Report 2026 [source: https://www.wearespark.ai/the-spark-report-ai-in-agencies-benchmark]. Une seule pratique (la spec en amont) ferme deux trous de gouvernance d’un coup, et matérialise concrètement la conformité RGPD IA attendue.

Outils concrets : Claude Code, Spec Kit, OpenSpec, BMAD, lequel pour un cabinet de 15 personnes

Le marché des outils SDD est dominé par quatre offres principales, toutes conçues à l’origine pour des équipes de développement. Pour un cabinet de 15 personnes, le critère de choix est la transposabilité au livrable cabinet, pas le respect du jargon technique.

Outil	Maintenu par	Volumétrie GitHub	Workflow	Pertinence cabinet 15 personnes
GitHub Spec Kit	GitHub	103 000 étoiles, 9 000 forks	Specify, Plan, Tasks, Implement	Référence méthodologique. La documentation officielle est lisible par un associé non-tech. Le toolkit en lui-même reste code-first [source: https://github.com/github/spec-kit].
OpenSpec	Fission AI	49 100 étoiles, 3 500 forks	Propose, Plan, Apply, Archive	Plus léger, CLI npm, support de 20+ assistants IA. L’étape Archive est intéressante pour la traçabilité audit [source: https://github.com/Fission-AI/OpenSpec].
Anthropic Claude Code	Anthropic	CLI Anthropic	Spec, Agent, Output	L’outil retenu par Doctolib. Demande une vraie configuration mais s’intègre à VSCode, JetBrains et CLI en moins de 5 minutes selon le case study [source: https://claude.com/customers/doctolib]. Connectable à des sources internes via intégration MCP Anthropic pour cabinets conseil.
BMAD, Kiro (AWS), Task Master	Divers	Variable	Variantes du SDD	Mention contextuelle. Pas de retour public vérifié sur leur usage hors développement pur. À surveiller, mais pas par où commencer.

Recommandation pragmatique Kreante. Pour un cabinet qui démarre, l’outil le plus sophistiqué n’est pas le bon. Le plus important est d’écrire des specs en français clair dans Notion, Google Docs ou un template Word partagé. Les outils GitHub deviennent utiles quand 3 à 5 personnes écrivent des specs régulièrement, qu’il faut versionner les modifications et orchestrer plusieurs agents IA en chaîne. Pour la phase 1, un template de spec et de la discipline valent mieux qu’un toolkit mal calibré. Si vous voulez voir comment nous l’opérationnalisons côté Kreante, voir Kreante, agence AI-native pour services professionnels.

Plan de mise en route 30 jours pour un associé de cabinet

Le plan de mise en route SDD pour un cabinet de 10 à 50 personnes tient en quatre semaines, chacune dédiée à un livrable mesurable.

Semaine 1 : Cadrer. Choisir trois types de livrables récurrents dans le cabinet (par exemple : note de cadrage, mémo client, audit annuel). Rédiger pour chacun un template de spec en français, deux pages maximum, en s’inspirant du workflow GitHub Spec Kit [source: https://github.com/github/spec-kit]. Pas d’outil, juste un document partagé sur le drive.

Semaine 2 : Tester sur une mission réelle. Un associé prend une mission en cours et applique le protocole Specify, Plan, Implement, Validate avec Anthropic Claude, ChatGPT Enterprise ou Mistral selon le setup. L’équipe documente le temps passé sur chaque étape et le nombre d’itérations avant validation. C’est la première fois que le cabinet aura un chiffre objectif sur sa productivité IA.

Semaine 3 : Étendre à un collaborateur senior. Le collaborateur écrit la spec, l’associé valide en 10 minutes, le collaborateur exécute les étapes 2 à 4. C’est ici que le vrai gain se mesure. Le Spark Report 2026 cite jusqu’à 10 heures économisées par semaine en moyenne dans les agences [source: https://www.wearespark.ai/the-spark-report-ai-in-agencies-benchmark]. Le gain réel dépendra de la complexité des livrables et de l’historique IA de l’équipe.

Semaine 4 : Formaliser la gouvernance. La spec type devient une pièce du process qualité, archivée par mission. Le cabinet ajoute une clause à ses contrats clients sur l’usage de l’IA, ce que 75 % des agences n’ont pas encore fait [source: https://www.wearespark.ai/the-spark-report-ai-in-agencies-benchmark]. La conformité aux recommandations CNIL du 7 février 2025 est documentée par mission [source: https://www.cnil.fr/fr/ia-et-rgpd-la-cnil-publie-ses-nouvelles-recommandations-pour-accompagner-une-innovation-responsable].

Au bout de 30 jours, le cabinet n’a pas révolutionné son fonctionnement. Il a fait une seule chose : écrire ce qu’il attendait de l’IA avant de lui parler.

Le calcul ROI. Faisons le calcul : un associé à 400 euros de l’heure qui économise 2 heures de relecture par mission, sur 4 missions par mois, récupère 3 200 euros mensuellement. Avec une heure de spec en amont par mission (4 heures, soit 1 600 euros de temps investi), le retour net est de 1 600 euros dès le premier mois, sans compter la valeur de gouvernance et la conformité documentée. Hypothèses illustratives, à recaler sur vos taux horaires et vos volumes réels. Pour modéliser cette projection plus en détail, voir ROI 2026 des agents IA en cabinet conseil.

Prochaine étape pratique aujourd’hui : prenez 15 minutes, choisissez le livrable le plus répétitif de votre cabinet, et écrivez la spec correspondante dans un document partagé. C’est tout. Vous verrez à la prochaine mission si vos itérations baissent. Si elles baissent, vous tenez le bout du fil. Si elles ne baissent pas, votre spec n’est pas assez précise : raffinez-la.

Question pour les commentaires : quel type de livrable de votre cabinet vous semble le plus difficile à « spécifier en amont » ? Les réponses honnêtes à cette question valent souvent plus qu’un protocole théorique.