Trois façons de briefer un agent de programmation : spécification, modèle de produit ou relecture à froid

Un agent de programmation qui livre la mauvaise chose a généralement compris la demande et mal compris le produit. Fin 2026, la question intéressante n'est plus de savoir quel agent utiliser mais comment le briefer, et trois réponses distinctes ont émergé. Elles diffèrent sur un point : ce que vous écrivez, et combien de temps cela vit.

Piloté par les spécifications : un document par changement

L'approche la plus adoptée rédige une spécification pour chaque fonctionnalité, puis un plan et une liste de tâches, et fait construire l'agent à partir de ces documents. Spec Kit (4,3) est la version de GitHub, avec environ 143 000 étoiles et une étape de convergence qui vérifie l'implémentation par rapport aux documents ; il prend en charge plus de 40 agents nommés. BMAD-METHOD (3,8) couvre un terrain similaire avec une distribution de personas. Son point fort : le contrat vit dans git et passe par des pull requests comme du code. Son coût : le temps de lecture. L'essai publié par Scott Logic a évalué la relecture humaine à environ deux à trois heures et demie par fonctionnalité, ce qui explique que les deux outils proposent des parcours plus légers pour les petites corrections.

Piloté par le produit : un modèle permanent

Une école plus récente soutient qu'une spécification décrit le changement, pas le produit, si bien que le produit est sans cesse reconstruit de zéro. pdd-kit (3,7) tient un modèle de produit unique, suivi dans git, avec entités, parcours, règles métier et variantes, que chaque agent lit au lieu de deviner, avec une étape de vérification qui contrôle le code par rapport à lui. L'idée est plus fine qu'un dossier de spécifications, mais le projet est jeune : environ 97 étoiles et un seul mainteneur, et un modèle qui prend du retard sur le code induit davantage les agents en erreur que l'absence de modèle. Il est rentable sur des produits à réelle complexité métier, pas sur une application CRUD.

La relecture d'abord : laisser un regard neuf trouver les failles

La troisième approche admet que l'agent rédacteur ne verra pas ses propres angles morts, et fait intervenir un relecteur qui n'a jamais vu la conversation. Elephant-Goldfish Model (4,2), un plugin open source de Google, rédige une conception avec un agent doté d'un contexte riche (l'Éléphant), puis la confie à des sous-agents sans contexte (les Poissons rouges) qui ne lisent que le document et ses sources citées. Comme ils ne peuvent pas s'appuyer sur la discussion qui a produit la conception, ils font remonter les hypothèses implicites. La méthode est bien argumentée et compte déjà environ 6 500 étoiles ; le hic est qu'il faut un harnais capable de lancer de nouveaux sous-agents, et qu'elle s'arrête plutôt que de simuler une relecture quand elle ne peut pas en faire.

La place des packs de workflow

À côté de ces approches se trouvent des installeurs de workflows généralistes comme Superpowers (4,7), qui donnent à un agent des habitudes de planification et d'autocontrôle sans imposer de format de spécification. Ils se combinent avec n'importe lequel des trois styles de brief au lieu de les concurrencer, et constituent le point de départ le moins exigeant.

Laquelle utiliser

Pour une correction d'une ligne, rien de tout cela : git, les tests et une consigne courte qui nomme les fichiers l'emportent. Pour une fonctionnalité qui exige des décisions de conception avant le code, la relecture d'abord repère le plus de vrais bugs pour le moins d'écriture, à condition que votre agent prenne en charge les sous-agents. Pour un changement réglementé qu'un auditeur lira plus tard, la trace écrite de l'approche par spécifications est justement l'intérêt. Et pour un produit complexe où les agents réinventent sans cesse les mêmes règles, un modèle de produit vaut son entretien, si, et seulement si, quelqu'un le tient à jour.