Le développement piloté par spécifications à l'ère de l'IA

Le mois dernier, j’ai observé un développeur passer un après-midi entier à se débattre avec un agent de codage IA. Il le sollicitait, recevait 200 lignes de code, se rendait compte qu’il avait mal compris les exigences, revenait en arrière, recommençait, obtenait 200 nouvelles lignes, et ainsi de suite. À la fin de la journée, il avait épuisé ses jetons, accumulé de la frustration, et n’avait livré strictement rien.

Son problème, ce n’était pas l’IA. Son problème, c’est qu’il n’avait pas de spécification.

Les agents de codage IA en 2026 sont remarquablement compétents. Claude Code, Cursor, Copilot, Kiro, OpenCode. Ils peuvent échafauder des fonctionnalités entières, refactoriser des bases de code complexes et écrire des tests qui détectent réellement les bugs. Mais ils partagent tous la même limitation fondamentale : ils font exactement ce qu’on leur dit. Et la plupart d’entre nous sommes terribles pour exprimer ce que nous voulons réellement.

Le développement piloté par spécifications est la pratique consistant à rédiger des spécifications structurées et explicites avant de commencer à coder, et il est en train de devenir rapidement la compétence la plus importante du flux de travail de développement assisté par IA.

Ce qu’est réellement le développement piloté par spécifications

Soyons clairs sur ce dont je ne parle pas. Je ne parle pas de documents d’exigences à l’ancienne, dignes du modèle en cascade, qui prennent six mois à rédiger et sont obsolètes avant le premier sprint. Je ne parle pas non plus de diagrammes UML ou de PRD de 80 pages que personne ne lit.

Le développement piloté par spécifications à l’ère de l’IA est léger, itératif et conçu pour être consommé à la fois par les humains et par les machines. Une spécification est un document structuré qui répond à trois questions :

Quoi construisons-nous ? (Exigences)
Comment doit-il fonctionner ? (Conception)
Dans quel ordre le construisons-nous ? (Tâches)

C’est tout. Le format peut être Markdown, YAML ou texte brut. L’essentiel est qu’elle soit explicite, sans ambiguïté, et qu’elle vive dans votre dépôt aux côtés du code.

Voici un exemple minimal de ce à quoi ressemble la spécification d’une fonctionnalité :

feature: user-notifications
version: 1.0

requirements:
  - Users receive real-time notifications for mentions
  - Notifications appear in a dropdown from the header
  - Unread count displays as a badge on the bell icon
  - Users can mark individual or all notifications as read
  - Notifications persist for 30 days

design:
  components:
    - NotificationBell: header icon with unread badge
    - NotificationDropdown: scrollable list, max 50 items
    - NotificationItem: individual notification with timestamp
  data:
    store: notifications table in Postgres
    realtime: WebSocket via existing pub/sub infrastructure
  constraints:
    - Must not add more than 50ms to initial page load
    - WebSocket reconnection must be automatic

tasks:
  - id: 1
    description: Create notifications database table and migration
    depends_on: []
  - id: 2
    description: Build NotificationItem component with read/unread states
    depends_on: []
  - id: 3
    description: Build NotificationDropdown with virtual scrolling
    depends_on: [2]
  - id: 4
    description: Build NotificationBell with unread count badge
    depends_on: [3]
  - id: 5
    description: Implement WebSocket subscription for real-time updates
    depends_on: [1]
  - id: 6
    description: Integration tests for full notification flow
    depends_on: [4, 5]

Rien de révolutionnaire dans ce document. Ce qui est révolutionnaire, c’est de le donner à un agent IA et de le voir exécuter tâche après tâche, avec le contexte complet des exigences, des contraintes de conception et de l’ordre des dépendances. Aucune ambiguïté. Aucune dérive. Aucun « j’ai supposé que vous le vouliez ainsi ».

Pourquoi les spécifications comptent plus que jamais

Il y a un dicton dans la communauté du codage par IA : la spécification, c’est le prompt. Je trouve que cela en sous-estime la portée. La spécification, c’est le contrat.

Lorsque vous travaillez avec un développeur humain, il apporte des années de contexte implicite. Il connaît les conventions de votre base de code, il peut déduire l’intention d’un message Slack, il posera des questions de clarification quand quelque chose n’a pas de sens. Les agents IA ne font rien de tout cela à moins que vous ne le leur disiez explicitement.

Voici le problème central. Les agents IA amplifient tout, y compris l’ambiguïté. Donnez à un développeur junior une exigence vague et il construira une mauvaise chose. Donnez à un agent IA une exigence vague et il construira la mauvaise chose avec assurance en 30 secondes, accompagnée de tests qui valident le mauvais comportement. La vitesse sans direction n’est qu’un échec plus rapide.

J’ai vu ce scénario se rejouer maintes fois :

Prompt : « Ajoute l’authentification à l’application. » Résultat : l’agent installe trois bibliothèques d’authentification différentes, crée une implémentation JWT personnalisée et ignore complètement le middleware de session existant.
Spécification : « Ajoute l’authentification par e-mail/mot de passe en utilisant le middleware de session Express existant. Stocke les mots de passe hachés avec bcrypt. Ajoute les routes login, register et logout sous /auth. Protège toutes les routes /api avec un middleware requireAuth. » Résultat : exactement ce qui a été demandé, en une seule passe.

La différence n’est pas l’intelligence. C’est le contexte.

Le paysage de l’outillage

L’industrie prend conscience de cela. Plusieurs outils ont émergé spécifiquement pour soutenir les flux de travail pilotés par spécifications avec des agents IA.

Kiro : piloté par spécifications dès le départ

AWS a lancé Kiro en tant qu’IDE IA qui place les spécifications au centre de l’expérience de développement. Son flux de travail est explicite : vous commencez par les exigences (user stories et critères d’acceptation), vous passez à un document de conception (composants, flux de données, architecture), puis vous générez une liste ordonnée de tâches. L’agent IA exécute ces tâches séquentiellement.

Ce qui rend Kiro intéressant, c’est que les spécifications ne sont pas optionnelles. Elles sont l’interface principale. Vous ne sollicitez pas l’agent en langage naturel en espérant le meilleur. Vous définissez ce que vous voulez dans un format structuré, et l’agent suit le plan.

C’est un écart philosophique par rapport à l’approche « il suffit de discuter avec l’IA » que la plupart des outils adoptent par défaut. Cela échange la spontanéité contre la prévisibilité, et dans les bases de code en production, la prévisibilité l’emporte à tous les coups.

Spec Kit : des spécifications pour n’importe quel éditeur

Spec Kit adopte une approche différente. Au lieu de construire un IDE complet autour des spécifications, il fournit un framework open source qui fonctionne avec n’importe quel outil de codage IA. Vous définissez les spécifications dans votre dépôt, et Spec Kit génère des fichiers de contexte que les agents IA peuvent consommer, que vous utilisiez Cursor, Claude Code, Copilot ou tout autre outil.

La philosophie est que les spécifications doivent être indépendantes de l’éditeur. Vos spécifications sont une propriété de votre projet, pas de votre IDE.

AGENTS.md et le motif des fichiers de convention

Le développement le plus organique dans cet espace est peut-être l’émergence des fichiers de convention. Claude Code lit AGENTS.md. Cursor lit .cursorrules. OpenCode lit également AGENTS.md. GitHub Copilot lit .github/copilot-instructions.md.

Ces fichiers sont des spécifications, même si personne ne les appelle ainsi. Ils indiquent à l’agent IA comment fonctionne la base de code, quels motifs suivre et ce qu’il faut éviter. Un fichier AGENTS.md bien rédigé est une spécification pour l’ensemble du projet :

## Project Configuration

- **Language**: TypeScript
- **Package Manager**: npm
- **Framework**: SvelteKit 2 with Svelte 5 (runes)

## Conventions

- Use Svelte 5 syntax only ($props, $derived, $effect, $state)
- All UI strings must use paraglide-js m.message_key() pattern
- All internal links must use localizeHref() for locale-prefixed URLs
- CSS custom properties for theming (var(--accent), var(--text-heading))
- Blog posts are .svx files with YAML frontmatter

## Do NOT

- Use Svelte 4 legacy syntax (no export let, no $: reactive statements)
- Install new dependencies without explicit approval
- Modify the i18n configuration

C’est une spécification. Elle est légère, elle vit dans le dépôt, et elle améliore considérablement la qualité du code généré par l’IA. Toute équipe utilisant des outils de codage IA devrait en avoir une.

Un flux de travail pratique pour les équipes

Voici comment je recommande aux équipes d’adopter le développement piloté par spécifications sans se noyer dans le processus.

Étape 1 : commencez par une page unique

Avant de toucher au moindre code, rédigez un document d’une page qui couvre :

Problème : quel problème utilisateur résolvons-nous ?
Solution : que construisons-nous, en langage clair ?
Périmètre : qu’est-ce qui est explicitement hors périmètre ?
Critères d’acceptation : comment savons-nous que c’est terminé ?

Cela prend 15 minutes. Cela fait gagner des heures. Les seuls critères d’acceptation préviendront la moitié des allers-retours avec l’agent IA.

Étape 2 : rédigez les contraintes de conception

Pas un document d’architecture complet. Juste les contraintes :

Quels systèmes existants cela touche-t-il ?
Quels motifs l’implémentation doit-elle suivre ?
Quelles sont les exigences de performance ?
Quels sont les cas limites que nous connaissons déjà ?

Ces contraintes sont en or pour les agents IA. Un agent qui sait « cela doit fonctionner avec notre couche de cache Redis existante » produira un code fondamentalement différent de celui qui ne le sait pas.

Étape 3 : décomposez en tâches

C’est là que le développement piloté par spécifications est le plus rentable. Décomposez la fonctionnalité en tâches atomiques et ordonnées. Chaque tâche doit pouvoir être accomplie en une seule session d’agent IA. Chaque tâche doit avoir une condition d’achèvement claire.

## Tasks

1. [ ] Create database migration for notifications table
   - Done when: migration runs successfully, table has correct schema
   
2. [ ] Build NotificationItem component
   - Done when: component renders with mock data, has read/unread visual states
   
3. [ ] Build NotificationDropdown component
   - Done when: displays list of NotificationItems, supports virtual scrolling
   - Depends on: task 2

Vous pouvez maintenant confier chaque tâche à un agent IA avec le contexte complet de la spécification. L’agent sait ce qu’il construit, pourquoi, et quelles contraintes respecter. Il sait aussi ce qui vient avant et après sa tâche, ce qui lui permet de prendre les bonnes décisions d’interface.

Étape 4 : exécutez, examinez, itérez

Donnez la spécification et la tâche en cours à votre agent IA. Examinez la sortie. Si la sortie est incorrecte, la question n’est pas « comment puis-je mieux formuler mon prompt ? » mais « qu’est-ce qui manque dans ma spécification ? » Mettez à jour la spécification, relancez. La spécification s’améliore au fil du temps à mesure que vous découvrez ce que l’IA a besoin de savoir.

C’est le changement de mentalité clé. Lorsque la sortie de l’IA est incorrecte, le bug est dans la spécification, pas dans l’IA.

Quand NE PAS rédiger de spécifications

Je veux être honnête sur les compromis. Le développement piloté par spécifications ajoute de la surcharge, et cette surcharge n’est pas toujours justifiée.

Sautez les spécifications quand vous explorez. Si vous ne savez pas encore ce que vous construisez, une spécification est prématurée. Prototypez d’abord. Codez à l’instinct. Explorez l’espace de solutions. Puis rédigez la spécification quand vous savez quelle est la bonne approche.

Sautez les spécifications pour les changements triviaux. Corriger une faute de frappe, mettre à jour une dépendance, changer une valeur de couleur. Cela ne nécessite pas de spécifications structurées. Faites preuve de bon sens.

Sautez les spécifications quand vous êtes seul et que la fonctionnalité est petite. Si la fonctionnalité tient entièrement dans votre tête et que vous êtes le seul à y travailler, la surcharge d’une spécification formelle ne vaut peut-être pas la peine. Un modèle mental est aussi une spécification, simplement non partageable.

En revanche, rédigez des spécifications quand :

Plusieurs personnes (ou agents IA) travailleront sur la fonctionnalité
La fonctionnalité touche plusieurs systèmes ou comporte des exigences complexes
Vous avez besoin que le travail soit examinable et auditable
Vous voulez confier une tâche à un agent IA et vous éloigner en toute confiance

La vue d’ensemble

Le développement piloté par spécifications n’est pas une idée nouvelle. Ce qui est nouveau, c’est le public. Pendant des décennies, les spécifications étaient rédigées pour des développeurs humains. Maintenant, elles sont rédigées pour des agents IA qui sont littéraux, infatigables et incapables de lire entre les lignes.

Les équipes qui livreront le plus rapidement avec l’IA ne seront pas celles qui ont les meilleures compétences en formulation de prompts. Ce seront celles qui peuvent clairement articuler ce qu’elles veulent dans un format structuré et sans ambiguïté. C’est de la rédaction de spécifications. C’est une compétence d’ingénierie, pas une astuce de prompt.

Les outils convergent vers cela. Kiro l’intègre à l’IDE. Spec Kit le rend portable. Les fichiers de convention comme AGENTS.md le rendent accessible. Le motif est clair : l’avenir du développement assisté par IA n’est pas de meilleurs prompts. Ce sont de meilleures spécifications.

Commencez dès aujourd’hui par un fichier AGENTS.md dans votre dépôt. Notez-y comment fonctionne votre projet, quelles conventions suivre, ce qu’il faut éviter. Cela seul améliorera chacune de vos interactions avec l’IA. Ensuite, pour votre prochaine fonctionnalité, essayez de rédiger une spécification d’exigences et de tâches avant de commencer à coder.

Vous serez surpris de voir à quel point la planification « lente » vous rend plus rapide.