Le développement piloté par la spécification est la discipline qui consiste à traiter une spécification exécutable comme l'artéfact principal dont une équipe est propriétaire, le code étant généré comme une projection en aval de cette intention. Lorsqu'une spécification porte suffisamment de précision pour régénérer l'implémentation, la spec devient la source de vérité — l'objet que les humains versionnent, relisent et débattent — tandis que le code se positionne comme une couche dérivée et remplaçable en dessous.
- La spécification devient l'artéfact durable ; le code devient une projection régénérable de celle-ci.
- La revue se déplace vers le haut, des diffs d'implémentation vers les diffs d'intention.
- La déterminisme de la régénération importe plus que l'élégance d'une sortie particulière.
- Les spécifications accumulent leur propre dette lorsque l'intention diverge de ce qui s'exécute.
- La gestion de versions de la spec change la signification d'« un changement » au sein d'un système.
- À mesure que les systèmes grandissent, les coutures entre spécifications se tendent avant que le code ne le fasse.
Why the specification, not the code, becomes the source of truth
Une spécification exécutable désigne une description du comportement attendu suffisamment précise pour qu'un générateur puisse produire une implémentation fonctionnelle à partir d'elle sans besoin d'intervention humaine supplémentaire. Le renversement qu'elle introduit est discret mais structurel. Pendant des décennies, le code était l'artéfact qui survivait ; les commentaires, documents de conception et tickets se dégradaient autour de lui, et le programme en fonctionnement restait le seul enregistrement honnête de ce que faisait un système. L'approche spécification d'abord inverse cette relation.
Quand l'intention est capturée sous une forme que la machine peut exécuter, la spécification cesse d'être de la documentation et devient un actif. Le code est régénéré à partir d'elle, et l'implémentation qui existe à un instant donné est l'une des nombreuses projections valides. Ce qui survit aux régénérations, c'est la spec. C'est le cœur du changement : la chose la plus durable dans le dépôt n'est plus la chose la plus détaillée.
Cela réorganise en général la propriété. L'artéfact qu'une personne défend en revue est l'énoncé du comportement, pas les lignes qui le satisfont. Une équipe qui intègre cela cesse de traiter le code généré comme précieux et commence à le considérer comme la météo — présent, conséquent et censé changer. L'instinct de polir une fonction à la main s'estompe, car le poli se trouve à une régénération de disparaître.
What changes when review moves from code to intent
Une fois que la spec est la source de vérité, le centre de gravité de la revue se déplace avec elle. Les relecteurs cessent de parcourir les diffs d'implémentation ligne par ligne et commencent à lire les changements de la spécification — ajouts de comportements, contraintes resserrées, hypothèses supprimées. Le diff d'implémentation devient une sortie à vérifier ponctuellement plutôt que l'objet d'un examen approfondi.
Cela est plus difficile qu'il n'y paraît. Un diff de spécification paraît souvent petit tandis que le code régénéré en dessous change substantiellement. Une seule phrase ajoutée à une clause comportementale peut se répercuter sur des centaines de lignes générées. Les relecteurs apprennent à raisonner sur le rayon d'impact d'un changement d'intention sans lire chaque ligne projetée, ce qui est une compétence différente de la lecture de code, et qui demande du temps pour se développer.
Un compromis qui émerge est la traçabilité. Lorsqu'un défaut apparaît dans du code généré, la question n'est plus « qui a écrit cette ligne » mais « quelle clause de la spécification l'a produite ». Les équipes qui pratiquent la spec-first prennent l'habitude de tracer les défauts jusqu'à l'intention, puis de décider si la spécification était erronée ou si le générateur a mal interprété une spécification correcte. Ce second cas est une catégorie de bug en soi — une défaillance de fidélité — et n'a pas d'équivalent dans le code écrit à la main.
How regeneration determinism shapes whether the spec can be trusted
Pour qu'une spécification serve de source de vérité, la régénération doit être suffisamment prévisible pour qu'on puisse s'y fier. Si la même spec produit des implémentations matériellement différentes à chaque fois, la spec n'est pas vraiment la source de vérité — c'est l'humeur du générateur. La discipline met donc un poids important sur le déterminisme : sorties stables, comportement de génération figé, et tests qui lient la projection à l'intention.
Il existe un spectre ici. La régénération eager reconstruit l'implémentation à chaque changement pertinent de la spec et traite le code comme entièrement jetable. La régénération lazy conserve une base générée et reprojette uniquement les parties touchées par un changement. Chacune a des coûts, et le choix tend à suivre la taille du système plus que la préférence de l'équipe.
| Property | Eager regeneration | Lazy regeneration |
|---|---|---|
| Code permanence | Fully disposable; rebuilt wholesale | Partially retained between changes |
| Drift risk | Low; output always tracks the spec | Higher; stale regions can linger |
| Cost per change | High compute, low reasoning | Low compute, higher reasoning |
| Failure mode | Whole-system surprises | Localized inconsistencies |
Aucune extrémité n'est correcte en soi. Les petits systèmes tolèrent la régénération eager à faible coût et en tirent l'avantage: la garantie que la sortie suit toujours la spec. Les grands systèmes ne peuvent souvent pas se permettre de reprojeter tout et penchent vers des stratégies lazy, ce qui réintroduit une partie de la divergence que l'approche spec-first visait à éliminer.
Where specifications accumulate their own kind of debt
La dette de spécification est l'écart qui s'ouvre quand l'intention écrite ne correspond plus à ce dont le système en fonctionnement a réellement besoin. C'est l'analogue spec-first du code legacy, et elle s'accumule de façons familières. Des clauses se contredisent. Les cas limites sont ajoutés comme exceptions plutôt que d'être intégrés au modèle. La spécification grossit par accrétion jusqu'à ce qu'aucune personne ne tienne sa forme complète en tête.
L'échec est plus subtil que le code embrouillé parce qu'une spécification peut sembler claire tout en codant une intention incohérente. Une spec bien formatée, pleine de contradictions silencieuses, génère toujours quelque chose — elle génère juste la mauvaise chose avec assurance. Les relecteurs peuvent être apaisés par une prose qui semble délibérée, et le générateur ne s'opposera jamais à une contradiction comme le ferait un compilateur face à une erreur de type.
- Specification drift
- La divergence lente entre l'intention déclarée et le comportement dont le système a réellement besoin en pratique.
- Projection fidelity
- Le degré auquel le code généré réalise fidèlement la spécification sans ajouter ni omettre de comportement.
- Intent surface
- L'ensemble des clauses et contraintes qu'un changement doit toucher pour modifier délibérément le comportement du système.
Gérer cette dette signifie refactorer les spécifications comme les équipes refactoraient autrefois le code : consolider les clauses, supprimer les contraintes mortes et nommer le modèle pour que sa forme reste lisible en grandissant. Le travail est peu flatteur et facile à différer, et le différer est précisément la façon dont une spec propre devient opaque.
How a deliberate spec-first change tends to proceed
L'ordre des opérations dans un flux de travail spec-first mature tend à suivre une forme cohérente, quel que soit le domaine. La séquence maintient la spécification comme autorité et empêche le code généré de devenir silencieusement une seconde source de vérité qui rivalise avec la spec. Ce qui importe est moins les étapes exactes que la direction vers laquelle chaque étape pointe : les changements entrent par l'intention et s'écoulent vers l'implémentation, jamais l'inverse.
- Formulez le changement de comportement comme un amendement à la spécification, pas comme une modification de code.
- Encodez la nouvelle intention en contraintes et exemples lisibles à la fois par un générateur et une suite de tests.
- Régénérez la projection affectée et laissez les tests de liaison confirmer la fidélité.
- Inspectez le diff de comportement, pas le diff de lignes, par rapport à l'intention déclarée.
- Intégrez toute surprise de nouveau dans la spec afin que la prochaine régénération porte l'enseignement.
La discipline vit à l'étape cinq. Lorsqu'une régénération vous surprend, la tentation est de patcher la sortie à la main. Chaque patch manuel qui ne revient pas à la spécification rouvre l'écart que le spec-first cherchait à fermer, et la spec cesse silencieusement d'être la vérité. La ligne patchée fonctionne aujourd'hui et mentira demain, au moment où quelque chose déclenche une nouvelle régénération. Les équipes qui tiennent la discipline traitent une projection surprenante comme un signal que l'intention était sous-spécifiée, et elles fournissent l'effort nécessaire pour préciser ce qu'elles voulaient plutôt que de remplacer la sortie en aval.
Where the model strains as systems grow larger
À petite échelle, une seule spécification contient confortablement tout un système et la régénération est peu coûteuse. La tension apparaît aux coutures. Les grands systèmes ne sont pas une seule spécification mais beaucoup, composées ensemble, et les contrats entre spécifications deviennent la surface fragile — exactement là où les architectures ordinaires échouent aussi, mais maintenant un niveau au-dessus, dans le langage de l'intention plutôt que des interfaces.
La composition bornée, où chaque spécification possède une interface claire et se reprojette indépendamment, a tendance à bien monter en charge. La composition non bornée, où les spécifications empiètent sur les hypothèses les unes des autres, produit des régénérations qui sont individuellement valides mais collectivement inconsistantes. Le couplage se déplace du code vers l'intention, et le couplage d'intention est plus difficile à voir parce que rien dans une spec isolée ne paraît erroné.
L'autre tension est humaine. Une spécification qui dépasse ce qu'un lecteur peut tenir devient sa propre forme de legacy opaque, et la promesse que la spec est l'artéfact lisible et détenu s'érode. Garder les spécifications suffisamment petites pour être raisonnées devient une préoccupation de premier ordre, pas une préférence stylistique, et les équipes qui l'ignorent reconstruisent le même brouillard dont elles sont parties. La discipline de décomposition qui gouvernait autrefois le code gouverne maintenant l'intention, et elle arrive avec le même avertissement : une frontière mal tracée est plus coûteuse à déplacer qu'aucune frontière du tout.
What the field is becoming as the spec hardens into the product
La trajectoire tend vers le traitement de la spécification comme le produit livré et du code comme artefact de construction, comme les binaires compilés ont été relégués il y a des décennies. À mesure que cela se stabilise, les problèmes difficiles migrent vers le haut. La gestion de versions de l'intention, le diff de comportement et la revue des contraintes deviennent l'artisanat quotidien, tandis que la lecture des implémentations générées devient un acte occasionnel et diagnostique réservé aux ruptures de fidélité. Les outils suivront ce centre de gravité, et les artéfacts dont une équipe sera fière seront les spécifications propres et lisibles plutôt que le code ingénieux en dessous.
Ce qui devient plus difficile, c'est la gouvernance du sens. Quand la spec est le produit, la question de qui peut modifier quelle clause, et comment un changement d'intention est validé avant qu'il ne reprojette, devient la discipline centrale. L'autorité sur une spécification porte le poids qu'avait autrefois l'autorité sur une branche de release, car une seule édition peut remodeler le comportement partout où la spec projette.
Les systèmes qui tiennent seront ceux qui traitent leurs spécifications avec la rigueur autrefois réservée au code de production — versionnées soigneusement, relues sérieusement et gardées suffisamment petites pour rester honnêtes. La force contraire existe bel et bien : une spec qui génère un logiciel fonctionnel invite l'hypothèse qu'elle doit être saine. Cette hypothèse est là où la prochaine décennie d'enseignements difficiles atterrira, et les équipes qui y résisteront tôt dépenseront le moins pour les apprendre.
FAQ