Le développement piloté par des spécifications avec des agents de codage IA : un guide pratique
Développement piloté par des spécifications avec des agents de codage IA : un flux de travail en quatre phases, fichiers AGENTS.md et SPEC.md, rôles des multiples agents, niveaux de maturité et moyens de détecter les écarts.
Sources: Spec-Driven Development with AI Coding Agents: The Definitive Guide
Des outils tels que Claude Code, GitHub Copilot, Cursor et Windsurf génèrent, restructurent et testent du code bien plus rapidement que n’importe quel être humain. Cependant, la vitesse sans précision devient souvent un inconvénient. De nombreuses équipes utilisant ces outils travaillent en boucle : elles posent des demandes, reçoivent des résultats, corrigent les erreurs, puis posent à nouveau des demandes, et cette boucle s’aggrave à mesure que la base de code s’élargit. La cause n’est généralement pas le modèle lui-même, mais plutôt le fait que personne n’a de méthode structurée pour indiquer clairement à l’agent ce qui est souhaité.
Le développement guidé par des spécifications (SDD) constitue une solution. Il considère une spécification structurée comme le produit principal du processus de livraison : le document à partir duquel le code est développé, vérifié et géré.
Les fondements conceptuels
Pourquoi le coding par ambiance échoue
Le « codeur de vibe » consiste à décrire le résultat souhaité de manière conversationnelle et à guider la sortie à l’aide de questions informelles. Il fonctionne bien pour des tâches isolées, des prototypes rapides et des expériences en une seule session. Il échoue cependant gravement à grande échelle, et la raison en vaut la peine d’être comprise.
Dégradation du contexte
Chaque session a lieu à l’intérieur d’une fenêtre de contexte, c’est-à-dire de la quantité limitée d’informations que l’agent peut prendre en compte à un moment donné. Lors du codeur de vibe, l’état du projet n’existe que dans l’historique de la conversation. À mesure que la conversation s’allonge, les décisions architecturales initiales, les contraintes de sécurité et les choix de bibliothèques disparaissent de cette fenêtre. L’agent substitue alors des alternatives plausibles, souvent sans le dire. C’est ce qu’on appelle la dégradation du contexte.
Son symptôme typique est l’écart d’implémentation : une séparation progressive entre ce que l’agent croit construire et ce que l’entreprise avait initialement demandé. Le code passe ses tests, fonctionne seul et semble correct, mais il enfreint des règles structurelles ou métier établies précédemment. Dans les systèmes d’entreprise, c’est ce type de défaut qui est le plus difficile à diagnostiquer et le plus coûteux à corriger.
L’idée fondamentale
SDD repose sur un principe architectural : la spécification est l’artefact principal, et l’implémentation en découle. Il s’agit de bien plus qu’un simple ajustement du flux de travail. Cela inverse le modèle traditionnel, où le code vient en premier et la documentation suit ensuite.
Dans cette approche, la spécification est lisible par machine, contrôlée en version, dynamique et exécutable. Elle agit comme un contrat entre l’intention humaine et l’exécution par l’agent, qui travaille dans les limites de ce contrat plutôt que de deviner. Un contrat précis produit des résultats prévisibles, tandis qu’un contrat ambigu entraîne des variations. En bref, on ne peut pas contrôler ce que construit un agent tant que l’on n’a pas défini avec précision ce que l’on souhaite voir construit.
Six éléments d’une spécification lisible par machine
Une spécification destinée à un agent doit surmonter l’ambiguïté du langage naturel. Les six éléments généralement considérés comme nécessaires pour empêcher l’agent de faire des suppositions indésirables sont :
- Résultats, les résultats que le travail doit atteindre.
- Champ d’application, y compris ce qui est explicitement exclu.
- Contraintes, telles que les technologies requises, les règles de sécurité et les limites de performance.
- Décisions déjà prises, qui ne sont donc pas rouvertes.
- Tâches, le travail divisé en étapes.
- Critères de vérification, les contrôles qui indiquent qu’une tâche est terminée.
Le flux de travail SDD
Quatre phases avec des points de contrôle humain
Le flux de travail comporte quatre phases successives, chacune incluant un point où une personne doit intervenir. Ces points de contrôle humain ne sont pas une bureaucratie. Ils empêchent que les erreurs ne s’accumulent plus loin dans le processus, et passer outre l’un d’eux pour « aller plus vite » a généralement l’effet inverse.
Phase 1 : spécification détaillée. Le développeur expose l’objectif de manière globale, puis soit l’agent, soit le développeur lui-même le développe en une spécification fonctionnelle structurée : parcours des utilisateurs, résultats commerciaux, critères d’acceptation et limites claires du périmètre. La tâche de cette personne consiste à effectuer une revue architecturale, en examinant le résultat à la recherche d’hallucinations, d’omissions ou de malentendus avant tout démarrage de planification. Reportez la phase 2 jusqu’à ce que la phase 1 soit dépourvue d’ambiguïtés : une spécification vague mène rarement à une implémentation vague, mais plutôt à une implémentation trop sûre d’elle et donc erronée.
Phase 2 : planification. Une fois la spécification approuvée, l’agent rédige un plan technique qui couvre les décisions architecturales, les modèles de données, les contrats API et les choix technologiques. Ce plan intègre également des contraintes organisationnelles telles que « conserver les données dans PostgreSQL » ou « chaque point d’entrée API nécessite une authentification JWT ». Une révision humaine à ce stade permet de détecter les erreurs architecturales avant qu’elles ne soient intégrées dans les milliers de lignes générées.
Phase 3, décomposition des tâches. Le plan approuvé est divisé en petites tâches qui peuvent chacune être testées indépendamment. La granularité est probablement la variable la plus sous-estimée dans le développement dirigé par les tests. Une tâche doit pouvoir être mise en œuvre et vérifiée au cours d’une seule exécution de l’agent ; si elle oblige l’agent à gérer plus de trois problématiques distinctes, elle est trop volumineuse. Une liste bien structurée sert également de cadre pour le développement dirigé par les tests, car chaque tâche dispose d’une condition de succès claire avant même de commencer à être travaillée, ce qui permet au projet d’avoir des points de validation fréquents.
Phase 4, mise en œuvre et vérification. L’agent écrit du code tâche par tâche, en produisant des résultats ciblés qui peuvent être audités et rattachés à une exigence spécifique. Cette phase s’accompagne d’un schéma de vérification, où un agent génère du code tandis qu’un autre agent ou un ensemble de tests automatisés le vérifie par rapport aux critères d’acceptation.
Mise à jour de la spécification dans les deux sens
L’une des pratiques les plus importantes, mais aussi celle qui est le plus souvent négligée, est la mise à jour bidirectionnelle. Supposons que, durant la phase 4, l’agent prenne une décision non couverte par la spécification, comme choisir une bibliothèque pour des raisons de performance ou gérer un cas limite d’une manière peu évidente. Cette décision doit être immédiatement réintégrée dans la spécification.
Si ce n’est pas le cas, une « dette de spécification » s’accumule : l’intention documentée et le comportement réel s’éloignent l’un de l’autre. Cette divergence transforme une spécification vivante en un fichier obsolète en qui personne ne a confiance et que finalement personne ne lit, devenant inutile précisément au moment où il est le plus nécessaire, lors des modifications ultérieures assistées par l’IA. La règle est simple : lorsque l’implémentation s’écarte de la spécification, mettez à jour la spécification immédiatement, et non au prochain sprint. La dette de spécification croît plus rapidement que la dette technique, car elle contamine le point de départ de chaque génération ultérieure.
Artefacts de persistance et constitution du projet
Pourquoi les agents ont besoin d’une constitution
Un agent de codage n’a pas de mémoire entre les sessions. Chaque nouvelle session débute uniquement avec ce que vous y insérez dans son contexte. Sans mécanisme de persistance, chaque session est une page blanche, sans connaissance de vos normes de sécurité, de vos conventions de nommage, des bibliothèques interdites ou de vos décisions architecturales.
La « constitution du projet » est un ensemble d’artefacts persistants qui résout ce problème. Il s’agit de fichiers structurés stockés dans le répertoire à côté du code source, fournissant à l’agent les connaissances institutionnelles nécessaires pour agir comme un membre de l’équipe informé et non comme un étranger.
Les artefacts principaux
AGENTS.md ou CLAUDE.md, le manuel d’utilisation. C’est le document le plus important : un README destiné à l’agent, à lire au début de chaque session pour comprendre le fonctionnement de ce projet en particulier. Il doit être rédigé en priorité pour être analysé par la machine, avant d’être lisible par un humain. Un fichier efficace contient trois types d’informations :
- Des détails opérationnels que l’agent ne peut pas déduire : les commandes de compilation exactes avec leurs paramètres, la manière dont les tests sont exécutés, la configuration du linter ainsi que les noms des variables d’environnement.
- Des conventions de nommage et de structure : à quoi sert chaque dossier, comment les fichiers sont nommés et comment les modules sont organisés.
- Une hiérarchie de gravité pour les actions des agents, utilisant un système de signaux cohérent. Toujours effectuer des tâches telles que le contrôle de qualité, l’exécution des tests concernés et le respect des conventions de nommage. Demander l’autorisation avant de modifier les schémas de base de données, d’ajouter des dépendances ou de changer les contrats API. Jamais enregistrer des secrets, modifier les fichiers
.envou changer la logique d’authentification sans examen préalable.
SPEC.md, la spécification vivante. Il s’agit de la description officielle de ce que le système doit faire. Ce n’est pas un document historique. Il reflète le comportement souhaité actuellement, y compris toutes les décisions prises lors de la mise en œuvre. Si le code s’écarte de SPEC.md, le fichier est mis à jour, et lorsque les exigences changent, c’est d’abord SPEC.md qui est modifié, suivie de la mise en œuvre.
PLAN.md, le document d’architecture. Il contient les décisions architecturales, les choix technologiques et les contraintes à l’échelle du système. Il répond à la question « pourquoi a-t-il été conçu de cette manière ? », en fournissant les raisons qui empêchent les agents et les ingénieurs ultérieurs de revenir sur des choix soigneusement faits.
Fichiers de configuration spécifiques aux outils. Chaque outil possède ses propres conventions pour les fichiers de règles. Le format .mdc de Cursor mérite d’être mentionné, car il combine Markdown avec du YAML pour associer des règles à des motifs de fichiers. Les règles liées au backend, telles que les exigences d’authentification et les schémas d’accès à la base de données, ne s’appliquent alors que lorsque l’agent travaille sur des fichiers backend, évitant ainsi que des informations non pertinentes n’influencent sa mémoire de travail lors du travail sur le frontend.
Orchestration multi-agents
Pourquoi un seul agent ne suffit pas
Un seul agent chargé de l’ensemble du code d’une entreprise atteint une limite stricte : la fenêtre de contexte. Un système volumineux comptant plus de 100 000 fichiers, plusieurs services, des flux de données complexes et un ensemble complet de tests ne peut pas tenir dans le contexte d’un seul agent. Cet agent doit choisir ce qu’il inclut, et ces choix créent des points aveugles.
L’idée à l’origine de l’orchestration multi-agents est d’imiter le fonctionnement d’une équipe humaine efficace, avec des rôles définis, des transferts de tâches organisés et une spécification que tout le monde considère comme vérité absolue.
Trois rôles
Coordonnateur. Cet agent joue le rôle de chef de projet et d’architecte. Il possède la vision d’ensemble, c’est-à-dire la spécification complète, la liste des tâches et les contraintes architecturales. Il divise la spécification en sous-spécifications, les transmet aux implémentateurs, surveille les conflits entre les flux de travail parallèles et s’assure que l’achèvement d’une tâche ne compromet pas l’architecture dans son ensemble.
Implémentateur. Les implémentateurs sont des spécialistes. Chacun reçoit une sous-spécification couvrant une tâche ou un petit groupe de tâches liées, et travaille dans un arbre de travail Git isolé afin de ne pas entrer en conflit au niveau des fichiers avec d’autres implémentateurs travaillant en parallèle. Il ne connaît rien des tâches en dehors de sa mission et n’en est pas responsable. Cette isolation n’est pas une limitation ; c’est ce qui rend le résultat déterministe, testable et soumis à révision.
Vérifier. Le vérificateur a un objectif opposé. Alors que l’implémenteur cherche à terminer la tâche, le vérificateur s’efforce de déterminer où le résultat ne respecte pas la spécification. Cette approche antagoniste est empruntée à la vérification formelle et à la recherche en sécurité, et elle fait partie des mécanismes de qualité les plus efficaces offerts par SDD. Le vérificateur teste la sortie par rapport aux critères d’acceptation et recherche des lacunes fonctionnelles, des violations des politiques de sécurité, des dépassements des contraintes de performance ainsi que des écarts par rapport à la spécification. Lorsqu’il détecte une disparité, il ne corrige pas le code ; il renvoie plutôt au coordinateur une description structurée qui retrace l’échec jusqu’à une exigence spécifique.
Pour les systèmes de production, ce vérificateur adversarial ne devrait pas être optionnel. Un agent qui écrit et vérifie son propre code jugera presque toujours son travail acceptable, et la valeur du vérificateur réside dans son indépendance par rapport à l’implementeur et son opposition à ce dernier.
Exécution parallèle avec des worktrees
L’une des capacités les plus précieuses des SDD multi-agents est le parallélisme : plusieurs implementeurs travaillent simultanément sur différentes fonctionnalités ou services, chacun dans son propre worktree. Pour de grands projets présentant peu de dépendances entre tâches, le délai de livraison peut être considérablement réduit.
Les worktrees de Git rendent cela possible. Chaque agent dispose d’un répertoire de travail distinct attaché au même dépôt, ce qui permet d’éviter les conflits de fichiers, tandis que le coordinateur surveille l’avancement de toutes les tâches depuis un seul endroit. Une fois que le vérificateur a donné son accord, le coordinateur fusionne les worktrees terminés et maintient la branche principale propre.
Diagrammes en tant que code
Pourquoi les diagrammes doivent figurer dans la spécification
Traditionnellement, les diagrammes d’architecture étaient dessinés a posteriori, en tant que documentation du code déjà existant. Dans le SDD, ils sont intégrés dès le début, en tant que partie de la spécification et du plan, avant toute mise en œuvre.
La raison en est diagnostique. Demander à un agent de générer un diagramme Mermaid valide à partir d’une spécification le force à réfléchir explicitement au flux de données, aux dépendances entre services et aux transitions d’état avant d’écrire du code. Un diagramme confus ou incohérent à ce stade est un signe fiable que la spécification est ambiguë ou structurellement défectueuse, et corriger de tels problèmes dans un diagramme coûte bien moins cher que de les corriger dans du code déployé.
Formats
Les formats basés sur du texte, en particulier Mermaid et D2, sont supérieurs aux images binaires à cette fin. Ils peuvent être versionnés et comparés, et les agents peuvent les lire directement. Ils peuvent également être mis à jour au fur et à mesure que les spécifications évoluent, ce qui permet de maintenir la documentation structurelle en parfaite adéquation avec l’implémentation.
Trois niveaux de maturité
Les professionnels ont défini trois niveaux de SDD. Il ne s’agit pas d’une échelle que chaque équipe doit gravir dans l’ordre. Ce sont plutôt des profils de compromis différents adaptés à des contextes variés, et savoir lequel convient à votre situation est essentiel avant toute mise en œuvre.
Niveau 1, spécifications en priorité. Une spécification détaillée est rédigée pour une tâche donnée. Une fois l’implémentation terminée et vérifiée, la spécification est considérée comme jetable : elle peut être conservée à titre de référence mais n’est pas maintenue. Ce niveau convient aux fonctionnalités isolées, aux migrations ponctuelles et aux expérimentations où le maintien requis par le Niveau 2 n’est pas justifié. Ses partisans affirment que ce niveau permet d’obtenir environ 60 % de la valeur des SDD à un coût bien moindre, ce qui en fait un point de départ judicieux pour les débutants. L’utilisez pour une nouvelle fonctionnalité bien définie, avec des critères d’acceptation clairs, sans dépendances inter-services et dont la livraison s’effectue en quelques jours.
Niveau 2, ancré sur la spécification (la valeur par défaut recommandée). La spécification occupe une place égale au code tout au long de la vie du projet, et tous deux sont maintenus. Lorsque les exigences changent, c’est d’abord la spécification qui est modifiée ; lorsque l’implémentation s’éloigne, la spécification est immédiatement mise à jour pour enregistrer le comportement réel ainsi que les raisons qui l’expliquent. Cela peut sembler impliquer une double maintenance, mais en pratique cela réduit le coût total : cela empêche le déclin du contexte au fil des sessions, permet aux nouveaux membres de l’équipe (humains et IA) de s’intégrer de manière fiable, et rend les modifications ultérieures assistées par l’IA beaucoup plus fiables. C’est la référence de base pour les systèmes en production, les projets d’équipe et tout ce qui est censé continuer à évoluer.
Niveau 3, spécification en tant que source (expérimental). La spécification est le seul artefact principal. Le code est traité comme un résultat compilé, régénéré sur demande et jamais modifié manuellement. C’est l’objectif théorique du SDD, où les ingénieurs gèrent les spécifications tandis que l’IA s’occupe des implémentations. Un problème non résolu persiste : le déterminisme. Des spécifications identiques peuvent produire, d’exécution en exécution, des codes syntaxiquement différents mais fonctionnellement équivalents, ce qui rend les comparaisons, le débogage et les revues très difficiles. Considérez-le comme une solution expérimentale. Il pourrait convenir aux projets novateurs disposant de spécifications très complètes, d’une gouvernance AI solide et d’une tolérance envers des outils immatures, mais il n’est pas recommandé pour les systèmes de production critiques en 2026.
Guides par rôle
Ingénieurs et architectes
La principale compétence de l’ingénieur se déplace vers l’ingénierie de contexte. Écrire une syntaxe correcte est quelque chose que les agents font à vitesse machine, donc la valeur de l’ingénieur réside dans la définition d’un contexte architectural précis, la sélection de ce que l’agent peut voir et la vérification que ses résultats correspondent à l’intention structurelle du système. Cela inclut l’élaboration de bons fichiers AGENTS.md et SPEC.md, l’établissement de règles de gouvernance pour les bibliothèques (une liste explicite des dépendances autorisées et interdites), la formulation des exigences en matière de sécurité et de conformité sous une forme lisible par machine, ainsi que la structuration des tâches afin que les différents aspects restent distincts.
Routine de départ pour les ingénieurs :
- Avant toute fonctionnalité assistée par l’IA, créer ou mettre à jour SPEC.md afin qu’il contienne les six éléments décrits précédemment.
- Revoir AGENTS.md et s’assurer que les commandes de compilation, les modèles de test, les règles de nommage et la hiérarchie de gravité reflètent toujours la réalité.
Un bloc de contraintes est un modèle pratique à inclure dans toute spécification. Il énumère la pile technologique (toutes les technologies requises), les bibliothèques interdites (détaillées), les exigences de sécurité (mode d’authentification des utilisateurs, type d’encodage attendu, manière de traiter les données), les limites de performance (latence et débit cibles), les exigences de test (seuil de couverture et types de tests requis) ainsi que les patterns architecturaux (ceux qui sont obligatoires et ceux à éviter).
Responsables techniques du produit
Des documents de spécifications de produit aux briefs comportementaux. Un document classique de spécifications de produit suppose l’existence d’ingénieurs humains qui le liront, en discuteront et l’implémenteront en se fiant à leur propre jugement. Dans le SDD, la sortie d’un TPM doit être un brief comportemental : une description lisible par une machine indiquant comment le produit doit répondre à des besoins d’utilisateurs spécifiques, avec la précision requise par l’exécution des agents.
La différence dépasse le simple style. Un document de spécifications de produit peut indiquer « améliorer l’expérience de paiement ». Un brief comportemental doit préciser ce que fait actuellement le flux de paiement, quels problèmes il cause aux utilisateurs, quels changements comportementaux constituent une amélioration, comment mesurer le succès, quels cas limites doivent être gérés et ce que le système ne doit absolument pas faire.
La boucle de prototype. SDD permet à un TPM de raccourcir le processus habituel de transfert des données du stade de conception à celui de l’ingénierie. Au lieu d’attendre les maquettes du concepteur puis que l’ingénieur les mette en œuvre, le TPM peut générer des prototypes interactifs directement à partir d’une description comportementale et évaluer le fonctionnement réel plutôt que des écrans statiques. Si le prototype ne correspond pas à la vision initiale, la spécification est mise à jour et l’agent régénère l’implémentation, de sorte que la boucle de retours s’appuie sur la spécification et non sur le code. Cela élimine plusieurs étapes de traduction (PRD, transfert de conception, transfert d’ingénierie) où l’intention initiale risque généralement de se perdre.
Directeurs techniques et chefs d’équipe d’ingénierie
Gouvernance. La priorité d’un CTO au sein d’une organisation axée sur les agents est un cadre de gouvernance qui permet à l’IA d’accélérer la livraison sans compromettre la qualité, la sécurité ou la conformité. SDD fournit la couche de contrôle, mais uniquement avec une discipline organisationnelle stricte. Trois mécanismes sont essentiels à grande échelle :
- Contrôle de version pour les spécifications. SPEC.md, PLAN.md et AGENTS.md se trouvent dans le même répertoire que le code et passent par les mêmes processus d’examen et d’approbation.
- Journal d’audit. Chaque modification générée par l’IA doit être rattachée à une exigence spécifique, ce qui n’est pas optionnel dans les secteurs réglementés.
- Contrôles humains à chaque transition de phase. Rien ne peut passer automatiquement de la phase de spécification à celle de planification puis d’implémentation sans approbation à chaque étape.
Les CTO devraient également évaluer les outils de codage basés sur l’IA selon ce cadre, en se demandant dans quelle mesure chacun prend en charge les fichiers de règles persistants, les points de contrôle, la traçabilité et les workflows multi-agents.
Évaluer le retour sur investissement. Les organisations qui adoptent le SDD rapportent souvent que le développement semble plus lent pendant les deux à quatre premières semaines, car les ingénieurs passent du temps à rédiger des spécifications au lieu de se concentrer directement sur le code. Cette observation est juste, mais son interprétation est trompeuse. Le travail de spécification n’est pas une charge supplémentaire nouvelle ; il s’agit d’un travail qui était auparavant effectué de manière informelle, incohérente et après l’implémentation, au moment où il coûtait le plus cher. Les indicateurs qui montrent le véritable retour sur investissement se trouvent plutôt à un stade ultérieur :
- le temps écoulé entre l’établissement des exigences et la création d’un code prêt pour la production, c’est-à-dire un code vérifié, examiné et déployé, et non simplement écrit,
- pourcentage de retravail : proportion de fonctionnalités achevées qui doivent être refaites en raison d’une mauvaise compréhension des exigences,
- temps de récupération du contexte : durée nécessaire pour qu’un développeur ou un agent devienne productif sur du code non modifié depuis 30 jours, et
- taux d’échappement des défauts : proportion de défauts détectés lors de l’examen des spécifications par rapport à ceux découverts après déploiement.
Les équipes ayant une pratique avancée de SDD constatent selon les rapports une baisse du retravail de 40 à 60 % ainsi qu’une réduction significative du temps de récupération du contexte, car les spécifications fournissent les informations nécessaires qui, autrement, exigeraient des heures de recherche dans le code. Ces chiffres proviennent de rapports de praticiens et non d’études contrôlées, il convient donc d’établir sa propre référence.
Dérive des intentions
Qu’est-ce que c’est
Le dérive d’intention correspond à l’écart progressif qui se crée entre les exigences initiales de l’entreprise et le comportement du code en production. Ce phénomène n’est pas nouveau dans le travail assisté par l’IA et fait partie des problèmes les plus anciens de l’ingénierie logicielle, mais les agents de codage y ajoutent un accélérateur dangereux. Ils se concentrent sur la plausibilité et le passage des tests, plutôt que sur l’alignement avec les objectifs commerciaux. Si l’on demande à un tel agent de développer un système de traitement des paiements, il écrira du code qui réussit tous les tests et couvre tous les cas spécifiés. Si les spécifications sont incomplètes ou obsolètes, l’agent comble les lacunes en utilisant des valeurs par défaut statistiquement probables issues de ses données d’entraînement. Ces valeurs conviennent bien aux systèmes génériques, mais peuvent s’avérer désastreuses pour les règles commerciales spécifiques à une entreprise. La pire forme de dérive est celle qui n’est détectée que lorsque cela entraîne des pertes pour un client, une audit de conformité ou un incident en production, car les agents sont très doués pour produire du code qui semble correct tout en étant subtilement erroné.
Defense
- Une spécification vivante. La première défense consiste en une spécification mise à jour en temps réel au fur et à mesure que des décisions sont prises. Toute déviation par rapport à SPEC.md, aussi infime soit-elle ou aussi bien justifiée soit-elle, est enregistrée immédiatement, de sorte que le fichier décrit toujours le comportement actuel et non l’intention initiale.
- Vérification adverse. Le modèle de vérification sert également à détecter les écarts. Vérifier la sortie par rapport à la spécification à chaque tâche permet de repérer ces écarts au plus petit niveau possible, avant qu’ils ne s’accumulent au cours de plusieurs cycles d’implémentation.
- Suivi de la couverture des spécifications. Les configurations plus avancées suivent la fraction des exigences pour lesquelles des tests automatisés et vérifiables existent. Une exigence sans test peut évoluer sans être détectée, et viser une couverture complète correspond à une méthode de développement pilotée par les tests appliquée au niveau des exigences.
Un AGENTS.md minimal
Un AGENTS.md prêt à être utilisé peut être court. Il doit au minimum inclure une description en un paragraphe du projet, les commandes exactes pour compiler, tester et vérifier la syntaxe, les conventions de nommage et d’organisation des dossiers, les listes « toujours », « demander d’abord » et « jamais », des liens vers SPEC.md et PLAN.md, ainsi que les règles de gouvernance des bibliothèques. Adaptez chaque partie en fonction de votre stack technique et des exigences de votre organisation.
Où cela vous mène
Le développement guidé par des spécifications n’est ni une mode passagère ni une simple amélioration des habitudes existantes. Il transforme la nature même du travail d’ingénierie. Avec les agents de codage, le goulot d’étranglement dans la livraison n’est plus la vitesse à laquelle la syntaxe est générée, mais plutôt la précision avec laquelle l’intention est définie. La spécification est le produit, le code est ce qui la met en œuvre, et dans la construction de logiciels assistés par des agents, la spécification constitue le résultat le plus important pour l’ingénieur.
Lectures complémentaires
- Notes pratiques : Je lance un agent de codage IA localement et cela fait presque deux fois — Guide pas à pas des Notes pratiques : Je lance un agent de codage IA localement et cela fait presque deux fois : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes utilisant ce modèle.
- L’ingénierie agente en cinq couches : des spécifications et des agents parallèles aux règles et à la supervision — Karpathy décrit le passage au-delà du codage basé sur des vibes. Découvrez les cinq couches de l’ingénierie agente : spécifications, orchestration, règles codifiées, révision humaine et observabilité, ainsi qu’un plan sur une semaine.