# Développement piloté par les spécifications pour agents d'IA

Canonical: https://specscore.md/fr/spec-driven-development/

SpecScore est un format de fichier ouvert et vérifiable par un linter pour les spécifications, écrit en Markdown et YAML (YAML Ain't Markup Language), avec une interface en ligne de commande (CLI) qui les contrôle. **Le développement piloté par les spécifications (SDD) est une pratique dans laquelle une spécification écrite et testable — exigences et critères d'acceptation — constitue la source de vérité contre laquelle le code est construit et vérifié.** Plutôt que de passer directement d'un prompt ou d'un ticket au code, vous convenez d'abord de ce que le logiciel doit faire, puis vous construisez selon cette spécification. Alors que les agents d'IA écrivent une part croissante du code, la spécification est ce qui leur permet de construire ce qu'il faut.

- La spécification est la source de vérité ; le code en dérive et s'y conforme.
- Les exigences s'accompagnent de critères d'acceptation explicites, ainsi l'état « terminé » est testable et non subjectif.
- Les agents d'IA interrogent la spécification pour en saisir l'intention au lieu de la déduire du code — moins d'erreurs de construction.
- C'est un complément au développement piloté par les tests, pas un substitut.

Dernière mise à jour : 30 octobre 2026

## Qu'est-ce que le développement piloté par les spécifications ?

Le développement piloté par les spécifications inverse l'ordre habituel du travail. Au lieu de traiter la spécification comme une documentation rédigée a posteriori — ou de la négliger entièrement —, le SDD en fait l'artefact principal. Le code, les tests et la révision s'y réfèrent tous.

Une spécification en ce sens n'est pas un pavé de texte. Elle est structurée : un ensemble d'**exigences**, chacune dotée de **critères d'acceptation** explicites précisant, en termes vérifiables, ce qui doit être vrai pour que l'exigence soit satisfaite. C'est cette structure qui permet à un réviseur, à une suite de tests et à un agent d'IA d'interpréter le même document de façon identique.

La spécification est en outre un **artefact vivant**. Lorsque les besoins évoluent, la spécification est modifiée en premier et le code suit — évitant ainsi que la spécification ne devienne obsolète ou fictive.

## Pourquoi c'est capital aujourd'hui : l'IA a changé la donne

Les agents d'IA génèrent du code bien plus vite qu'un humain ne peut le lire. Le goulot d'étranglement s'est déplacé. La difficulté ne consiste plus à écrire l'implémentation — elle consiste à**spécifier l'intention avec suffisamment de précision pour que le code généré soit celui attendu**. Face à un prompt imprécis, un agent produira assurément un résultat plausible mais erroné, et ce à la vitesse de la machine.

La spécification est le garde-fou. Dès lors que le comportement attendu et les critères d'acceptation sont couchés par écrit, l'agent dispose d'une cible sans ambiguïté vers laquelle converger et d'une checklist de validation — et le réviseur humain dispose d'une base stable à approuver avant qu'aucune ligne de code n'existe. Le SDD est le moyen pour les équipes d'éviter que la rapidité de l'IA ne se transforme en réécriture permanente.

## Comment fonctionne le développement piloté par les spécifications

Le workflow forme une boucle, pas un document ponctuel :

- **Capturer l'intention.** Consignez l'orientation encore brute — le problème, l'objectif, les questions ouvertes — avant de vous engager sur une solution.
- **Spécifier le comportement.** Transformez l'orientation convenue en exigences, chacune dotée de critères d'acceptation explicites et testables.
- **Décomposer en un plan.** Divisez la spécification en tâches ordonnées, chacune citant les critères d'acceptation qu'elle satisfait.
- **Implémenter.** Construisez tâche par tâche — un humain ou un agent d'IA — selon la spécification.
- **Vérifier par rapport aux critères.** Contrôlez le résultat face aux critères d'acceptation, pas au jugé.
- **Garder la spécification vivante.** Lorsque les exigences changent, mettez à jour la spécification d'abord ; le code suit.

## Bénéfices du développement piloté par les spécifications

- Les désaccords surgissent lors de la révision de la spécification — peu coûteuse — plutôt qu'après l'implémentation — très coûteuse.
- L'état « terminé » est objectif car les critères d'acceptation sont vérifiables.
- La spécification constitue un contexte partagé par tous : produit, ingénierie et agents d'IA.
- Les changements sont traçables — chaque tâche renvoie aux critères qu'elle remplit.

### Pourquoi cela aide tout particulièrement les agents d'IA

- **Intention lisible par machine :** l'agent lit directement les exigences au lieu de les inférer du code.
- **Moins de contexte à charger :** l'agent interroge la portion utile de la spécification au lieu du dépôt entier.
- **Sortie vérifiable :** les critères d'acceptation fournissent à l'agent un objectif précis de succès ou d'échec.
- **Traçabilité :** le code généré peut être rattaché à l'exigence qui l'a justifié.

## Développement piloté par les spécifications face aux pratiques voisines

 Pratique Source de vérité Relation avec le SDD Développement piloté par les tests Tests qui échouent au niveau du code Complémentaire — les critères d'acceptation deviennent les tests. PRD traditionnel Prose rédigée pour des humains Moins structuré ; pas directement testable ni lisible par machine. Prompts seuls (« vibe coding ») Le prompt et l'intuition du modèle Sans cible durable ni révisable — ce que le SDD vise à corriger.

Pour une comparaison détaillée de SpecScore face à d'autres outils de spécification, consultez[les pages de comparaison](/fr/vs/).

Voir aussi les comparaisons avec [Kiro](/fr/vs/kiro/), [Tessl](/fr/vs/tessl/), [BMAD Method](/fr/vs/bmad-method/), [Task Master AI](/fr/vs/task-master-ai/).

Pour l’ensemble des outils — GitHub Spec Kit, OpenSpec, Kiro et les autres — voir[les meilleurs outils de développement piloté par les spécifications en 2026](/fr/spec-driven-development/tools/).

Pour écrire des critères d’acceptation qu’un agent d’IA peut vérifier, voir[comment écrire des critères d’acceptation](/fr/articles/acceptance-criteria/).

Les patrons de phrase EARS que les exigences Kiro utilisent sont expliqués dans [la syntaxe des exigences EARS](/fr/articles/ears-requirements/).

Pour lancer ce linter de spécifications en intégration continue, voir [linter des spécifications en CI](/fr/articles/lint-specs-in-ci/).

Pour un modèle de spécification de fonctionnalité en Markdown — un document d’exigences produit (PRD) avec exigences, critères d’acceptation, un plan et des tâches — voir [modèle de PRD en Markdown](/fr/articles/feature-spec-template/).

Pour le développement piloté par les spécifications avec Claude Code et Cursor — ce qui va dans le fichier de fonctionnalité, ce que `specscore agent setup` écrit, et comment `specscore spec lint` tourne dans la boucle et en CI — voir [développement piloté par les spécifications avec Claude Code et Cursor](/fr/articles/claude-code-specs/).

## Compromis et quand ne pas l'utiliser

Le développement piloté par les spécifications n'est pas gratuit. Il reporte l'effort vers la réflexion et l'écriture avant que le moindre code ne tourne, ce qui est inadapté pour un script jetable ou une expérimentation rapide. Et une spécification n'aide que si elle reste à jour — une spécification abandonnée devient trompeuse, pire que l'absence de spécification. Le SDD vaut la peine quand le travail est assez vaste pour être planifié, est destiné à être maintenu, ou doit être délégué à un agent d'IA pour une construction à grande échelle.

## Pratiquer le développement piloté par les spécifications avec des agents d'IA

Pour pratiquer le SDD avec des agents d'IA, vous avez besoin de deux éléments : un **format de spécification lisible par machine** que votre équipe et vos agents comprennent, et un **moyen pour les agents de lire, écrire et valider** ces spécifications.

**SpecScore** en est précisément une implémentation. C'est un format ouvert Markdown + YAML pour les features, exigences et critères d'acceptation — de simples fichiers dans votre dépôt — associé à un CLI que vos agents appellent pour les interroger, les modifier et les passer au linter. La structure étant lisible par machine, un agent peut demander « sur quoi devrais-je travailler ensuite ? » et recevoir les exigences ouvertes avec leurs critères d'acceptation, puis vérifier son travail par rapport à eux. Il est agnostique vis-à-vis des outils et [open source](https://github.com/specscore/specscore).

Commencez avec les [Skills IA pour votre agent de programmation](/fr/ai/) ou[installez le CLI](/fr/cli/).

## Questions fréquentes

Le développement piloté par les spécifications est-il identique au développement piloté par les tests ?

Non. Le TDD guide l'implémentation à partir de tests qui échouent au niveau du code. Le développement piloté par les spécifications intervient un niveau au-dessus : il fige d'abord le comportement prévu et les critères d'acceptation dans une spécification écrite. Ils sont complémentaires — les critères d'acceptation d'une spécification deviennent souvent les tests qui guident ensuite le TDD.

Le développement piloté par les spécifications vous ralentit-il ?

Il demande du temps avant d'écrire le code et élimine le temps passé à reconstruire ce qui n'allait pas. Pour des scripts jetables, le coût n'en vaut pas la peine. Pour tout ce qu'un agent d'IA génère à grande échelle, ou qu'une équipe doit maintenir, écrire la spécification en premier s'avère généralement plus rapide de bout en bout.

Quelle est la différence entre une spécification et un PRD ?

Un PRD est le plus souvent une prose rédigée pour des humains. Une spécification dans le développement piloté par les spécifications est structurée et testable — des exigences distinctes assorties de critères d'acceptation explicites — afin que réviseurs et agents d'IA puissent agir dessus avec précision.

Comment les agents d'IA de codage utilisent-ils une spécification ?

Quand la spécification est lisible par une machine, l'agent l'interroge pour obtenir les exigences et critères d'acceptation pertinents pour sa tâche actuelle plutôt que de charger tout le codebase, puis compare sa production à ces critères — un garde-fou face au code plausible mais incorrect.

Qu'est-ce que SpecScore ?

SpecScore est un format de fichier ouvert et lintable pour les spécifications, écrit en Markdown et YAML, avec une interface en ligne de commande (CLI) qui les interroge, les modifie et les lint. Le format est dans le dépôt public [specscore/specscore](https://github.com/specscore/specscore).

Quelle est la licence de SpecScore ?

La spécification et la documentation du dépôt public [specscore/specscore](https://github.com/specscore/specscore) sont sous [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE). L'interface en ligne de commande (CLI) de référence dans [specscore/specscore-cli](https://github.com/specscore/specscore-cli) est sous [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE).

Le développement piloté par les spécifications impose-t-il un fournisseur d'IA ?

Non. Les spécifications sont des fichiers texte dans le dépôt. La CLI est un binaire local. Les AI Skills de ce site enveloppent cette CLI pour les agents qui savent exécuter des skills. Le format n'impose pas un fournisseur.

Comment installer la CLI ?

Suivez [/fr/cli/install/](/fr/cli/install/), ou commencez par les [AI Skills](/fr/ai/). Le binaire de la CLI est publié depuis [specscore/specscore-cli](https://github.com/specscore/specscore-cli).