Écrire la spec avant de laisser l'IA coder

Un développeur à qui l'on donne une consigne floue pose des questions. Un agent IA, lui, comble les vides : il choisit une interprétation plausible et la code avec aplomb. Le résultat compile, les tests qu'il a écrits passent, et pourtant ce n'est pas ce que vous vouliez. La parade est simple et ancienne : écrire ce qu'on attend avant de coder, sous une forme qu'on peut vérifier.

Pourquoi l'IA a besoin d'une spec, encore plus qu'un humain

Un modèle de langage est entraîné à produire la suite la plus probable. Face à « empêche de publier un post vide », il doit décider seul : un post avec une image mais sans texte, c'est vide ? Et une vidéo sans légende ? Il tranchera, sans vous le dire.

C'est pour cela que l'agent qui rédige mes spécifications a une consigne inhabituelle pour une IA : s'arrêter. Après ses questions, son fichier de rôle lui impose : « Attendre les réponses de l'utilisateur avant de continuer. » Puis de nouveau avant de découper le travail en tâches : « Attendre validation utilisateur avant de continuer vers Phase 4 ». Les décisions métier restent humaines.

Le format : Given, When, Then

C'est le format du BDD (développement piloté par le comportement). Il se lit sans être développeur, et chaque ligne « Then » se transforme en test. Voici un extrait réel d'une story de PostOwl :

Story 15.3 : Protection contre la création de posts vides
 
Scénario : l'utilisateur n'a saisi aucun contenu
  Given la page de création sans texte, sans version générée, sans média
  When l'utilisateur est à l'étape d'édition
  Then « Publier maintenant », « Publier plus tard » et « Sauver en brouillon » sont désactivés
  And une infobulle indique « Ajoutez du contenu avant de publier »
 
Scénario : un post vidéo avec un média mais sans légende
  Given une vidéo courte importée, sans texte
  When l'utilisateur tente de publier
  Then la publication est autorisée : le média suffit comme contenu

La question « une vidéo sans légende, c'est vide ? » est tranchée noir sur blanc. L'agent n'a plus à deviner.

Une story, c'est une tâche à la bonne taille pour un agent

« Construis l'application » est une consigne impossible. « Implémente la story 15.3 » est une consigne vérifiable. Sur PostOwl et BookFlow, j'utilise la méthode BMad, une méthode open source qui structure ce découpage : document produit, architecture, epics, puis stories. Chaque story contient ses critères, les tâches techniques, des notes pour le développeur, et un journal que l'agent remplit en codant.

Pour la story 15.3, le journal de l'agent dit : 11 tests pour la fonction qui décide si un post a du contenu, 6 pour le garde-fou de navigation, « 108 tests pass, 0 regressions ».

Et c'est la revue qui a trouvé le vrai problème. Dans le code de l'agent, une condition vérifiait qu'un identifiant de post n'était pas vide, à un endroit où il ne pouvait jamais l'être : la condition était toujours vraie, donc inutile, et masquait l'intention. Les tests passaient quand même. La revue, faite contre la spec, l'a repérée et corrigée, avec un nom de test trompeur renommé et un test ajouté pour le scénario « l'utilisateur efface tout ».

Quand la réalité contredit la spec

Une spec n'est pas un monument. Sur Le Limier, la spec du pipeline d'ingestion des données publiques (Sirene, BODACC) proposait une arborescence de fichiers ; le code a suivi la convention déjà en place dans le projet, ce qui était le bon choix. Deux sources prévues dans la spec n'ont pas été construites en V1. Et la checklist d'acceptation n'a jamais été cochée jusqu'au bout.

Ce n'est pas un drame, à une condition : décider lequel a raison quand les deux divergent. L'historique du projet garde la trace de ces décisions, comme ce commit : « test: réaligne la spec origine radar sur le comportement réel ». Le comportement réel était le bon ; la spec et ses tests ont été mis à jour. L'inverse arrive aussi, et c'est alors le code qu'on corrige.

Ce que vous y gagnez si vous êtes client

• Vous validez des phrases, pas du code. Les critères s'écrivent dans votre vocabulaire, et vous pouvez les contester avant que la moindre ligne soit écrite.
• « Fini » a une définition. Une fonctionnalité est livrée quand ses scénarios passent, pas quand le développeur a le sentiment d'avoir terminé.
• Moins d'allers-retours. Les malentendus coûtent quelques minutes de discussion sur une spec, au lieu de jours de reprise sur une fonctionnalité livrée.

La spec est la première étape de notre méthode. Elle s'appuie sur une architecture qui isole le métier et elle n'a de valeur que si des tests la vérifient.