Jour 11. C'est là que quelqu'un a fini par le remarquer. Un dev que je connais à Montréal avait nourri une spec magnifiquement structurée à un agent de codage la semaine d'avant, le genre de spec qui te fait hocher la tête en la lisant, chaque critère d'acceptation à sa place, chaque cas limite étiqueté, chaque comportement écrit en « quand ceci, alors cela » bien propre. L'agent avait retourné du code rapide, cohérent, qui passait les tests, trois fois de suite. Puis un réviseur conformité a posé une question : où est la journalisation d'audit? Nulle part. La spec n'en parlait pas. Personne.
La spec n'était pas bâclée. Pantoute. Selon toutes les mesures structurelles, elle était excellente, testable et traçable et sans ambiguïté, exactement l'artefact qu'un flux piloté par specs est conçu pour produire. L'obligation de journalisation réglementaire, elle, n'a jamais été découverte. Et ce vide, la distance entre une spec bien écrite et une spec bien découverte, c'est précisément ce que tout le mouvement du développement piloté par specs présume réglé.
Le développement piloté par specs a la cote, et c'est mérité. Le Spec Kit de GitHub a passé 90 000 étoiles et plus de 8 000 forks début mai 2026, moins d'un an après son lancement (Visual Studio Magazine, mai 2026). AWS a livré Kiro. BMAD et Tessl ont bâti des méthodologies entières sur une seule idée : la spec, pas le code, est la source de vérité durable. J'adhère à tout ça. Sincèrement. Le mouvement vise juste sur un point que l'industrie a échappé pendant vingt ans.
Puis AWS a publié un chiffre qui devrait te figer. Quand l'équipe Kiro a passé sa nouvelle fonction d'analyse des exigences sur 35 projets internes couvrant plus de 1 400 critères d'acceptation, environ 60% des premières versions d'exigences ont dû être raffinées avant de pouvoir être implémentées en sécurité (The New Stack, mai 2026). Soixante pour cent. Pas le code. Les exigences elles-mêmes, écrites par des professionnels, étaient fautives plus souvent qu'à leur tour, dès la première version.
Qu'est-ce que Kiro d'AWS a vraiment trouvé dans 60% des exigences?
De l'incohérence. Surtout la sorte discrète. L'analyse des exigences de Kiro est une vraie belle pièce d'ingénierie, et ça vaut la peine de comprendre ce qu'elle fait et, plus important, ce qu'elle ne peut pas faire. La fonction utilise un grand modèle de langage pour traduire des exigences en français clair vers de la logique formelle, puis remet cette logique à un solveur SMT (Satisfiability Modulo Theories), un moteur de raisonnement automatisé et déterministe qui mûrit dans la recherche universitaire depuis une cinquantaine d'années, pour prouver mathématiquement si les exigences se contredisent ou laissent des trous démontrables.
Le côté langage naturel s'appuie sur EARS, l'Easy Approach to Requirements Syntax, une notation qu'Alistair Mavin a introduite pour forcer les exigences dans des moules du genre « QUAND [déclencheur] LE SYSTÈME DOIT [réponse] ». Propre. Quand le solveur dit qu'un ensemble d'exigences est cohérent, il ne devine pas comme un robot conversationnel devine ; il a roulé une vraie preuve. C'est une avancée réelle par rapport au « ça m'a l'air correct », et je ne veux pas la minimiser, parce que la plupart des équipes n'ont jamais eu aucune vérification mathématique sur leurs exigences.
Sauf qu'il y a une frontière. Le solveur ne peut raisonner que sur les exigences présentes dans le document. Il confronte les exigences que tu as écrites les unes aux autres. Il est éblouissant pour attraper « l'exigence 14 contredit l'exigence 31 ». Il n'a rien à dire sur l'exigence que personne n'a écrite, parce que personne ne savait qu'il fallait la poser. Le trou de journalisation d'audit de mon ami montréalais serait passé tout droit dans l'analyse de Kiro, sans alerte, parce qu'il n'y avait aucune clause contradictoire à signaler. Le 60% que Kiro attrape, c'est le 60% visible. Les exigences dangereuses, ce sont celles qui ne sont jamais entrées dans la pièce.
Pourquoi le développement piloté par specs échoue-t-il encore à la découverte?
Parce que le SDD règle un autre problème que celui que la plupart des équipes ont vraiment. Soyons précis. Le développement piloté par specs, au fond, corrige deux modes d'échec très réels et très douloureux des agents de codage IA : la dérive d'intention, où l'agent s'éloigne tranquillement de ta demande sur une longue session, et la perte de contexte, où il oublie les décisions d'avant à mesure que la fenêtre de jetons se remplit. Ancrer l'agent à une spec persistante règle les deux. C'est toute la proposition de valeur, et elle livre.
Rien de tout ça ne touche la découverte. Pense à la séquence. La découverte, c'est l'étape où un humain détermine ce que le système doit vraiment faire : quelles réglementations s'appliquent, quels intervenants divergent, quelle hypothèse « évidente » est sur le point d'exploser, quel système legacy personne n'a mentionné. Ensuite la spec capture cette compréhension. Ensuite l'agent exécute la spec. Le SDD rend fiables les étapes deux et trois. Il ne dit rien de l'étape un, celle où l'obligation de journalisation est surfacée ou ne l'est pas.
Je vais pousser mon propre argument un peu, parce que ce serait trop beau autrement. Un bon gabarit de spec et quelques prompts bien aiguisés, ça ne pousse pas un peu vers une meilleure découverte? Un peu, oui. Forcer un auteur à écrire « QUAND l'utilisateur exporte des données LE SYSTÈME DOIT... » le fait penser au cas d'exportation. Mais un gabarit ne peut t'inviter à considérer que les catégories que tu as déjà imaginées. Il ne peut pas t'inviter à penser à une réglementation dont tu n'as jamais entendu parler, ni à une équipe en aval dont tu ignorais qu'elle consommait tes données. La structure t'aide à organiser ce que tu sais. Elle ne fait à peu près rien pour surfacer ce que tu ignores.
Quelles sont les trois lacunes que les outils SDD ne peuvent pas corriger?
Trois, d'après mon expérience, et elles partagent une racine. Aucune n'est un défaut des outils. Ce sont des défauts dans ce vers quoi les outils sont pointés. Les voici, les trois endroits où un pipeline piloté par specs déraille en silence, tirés de vingt-cinq ans à voir des specs atterrir sur le bureau des développeurs.
L'exigence manquante. C'est l'histoire de la journalisation d'audit, et c'est la plus mortelle des trois. Une exigence jamais découverte ne peut pas être écrite, ne peut pas être spécifiée, ne peut être vérifiée par aucun solveur sur Terre. Elle surface en production. Ou dans un audit. Ou dans une poursuite. Kiro prouve que les exigences que tu as sont cohérentes. Il est muet sur celle que tu n'as pas.
L'exigence à faux consensus. Trois intervenants lisent « le système doit supporter les mises à jour d'inventaire en temps réel » et hochent la tête. Ils sont d'accord. Sauf qu'un veut dire sous la seconde, un veut dire en moins de cinq minutes, et un veut dire « avant que le client le remarque », et la spec, structurellement impeccable, encode les trois lectures à la fois dans une seule ligne propre. Le solveur voit une exigence cohérente. Les humains en voyaient trois. Cette ambiguïté se livre.
L'arbitrage sans propriétaire. Tout vrai système force des choix que personne ne veut rendre explicites : vitesse contre coût, flexibilité contre sécurité, ce segment de clientèle contre cet autre. Une spec écrite sans propriétaire pour ces arbitrages les tranche en silence, d'habitude vers ce qui était le plus facile à formuler. Puis un agent implémente le choix par défaut à la vitesse de la machine, et tu découvres la décision que tu n'as jamais prise quand la facture arrive. J'ai vu celle-là se jouer plus de fois que je peux compter.
Donnons à AWS le crédit qui lui revient, parce que l'histoire de Kiro est vraiment encourageante. Quand Amazon a fait face à des questions sur la fiabilité du code généré par IA, la réponse du groupe de raisonnement automatisé n'a pas été « ajoutons plus d'IA ». C'était des maths. Ils ont sorti un solveur SMT (Satisfiability Modulo Theories), le genre de moteur logique prouvablement correct que la recherche universitaire raffine depuis les années 1970, et l'ont câblé dans le flux de specs pour que « ces exigences sont cohérentes » devienne une preuve plutôt qu'une opinion.
Les scientifiques appliqués d'AWS ont posé l'enjeu clairement dans le billet de Kiro : un prompt vague produit une spec vague, et l'agent qui implémente cette spec produit du code plein de décisions non divulguées prises en ton nom, sans que tu le saches ni que tu sois d'accord. C'est exactement le bon diagnostic. C'est l'honnêteté de l'aveu qui rend la fonction digne de confiance, et c'est rare qu'un fournisseur dise tout haut la partie qui dérange.
Voici le bout sur lequel il vaut la peine de s'asseoir. Kiro prouve la cohérence entre les exigences qui existent. Sur 35 projets, 60% de ces premières versions avaient quand même besoin de travail, et c'est la part que le solveur pouvait voir. Les décisions non divulguées qui me font le plus peur, ce sont celles complètement en amont du solveur : l'exigence que personne n'a écrite, parce que personne dans la pièce ne savait qu'elle y avait sa place. AWS a bâti un vérificateur brillant pour la spec. La découverte qui remplit la spec, c'est encore à nous de la faire.
Comment l'intelligence des exigences comble-t-elle le vide avant la spec?
En travaillant une couche en amont du point de départ de chaque outil SDD. C'est toute la raison d'être de Specira, alors prends le biais comme déclaré. L'intelligence des exigences, c'est la discipline qui mène une découverte structurée et multi-experts avant qu'une seule ligne de spec soit écrite : surfacer les hypothèses cachées, les questions réglementaires jamais posées, les définitions d'intervenants qui se contredisent en secret, et consigner les décisions d'arbitrage avec un propriétaire attaché à chacune.
Reprends les trois lacunes, mais avec la découverte faite d'abord. L'obligation de journalisation manquante est surfacée parce qu'une passe de découverte structurée demande, chaque fois, « quelles obligations de conformité ou de journalisation touchent ces données? ». Le faux consensus sur « temps réel » est attrapé parce que la découverte force chaque intervenant à définir le terme en chiffres avant qu'il atteigne une ligne de spec. L'arbitrage sans propriétaire en obtient un, parce que la découverte refuse de laisser un choix aussi gros se trancher en silence. Même Kiro. Même Spec Kit. Soudain pointés vers le bon système.
Je veux être juste envers la contre-objection, parce que des gens brillants la soulèvent. C'est juste « faire de la bonne analyse d'affaires », déguisé, non? En partie, oui, et je ne vais pas faire semblant du contraire. La discipline est vieille. Ce qui est neuf, c'est que l'IA rend enfin la découverte structurée assez rapide pour suivre le rythme de l'exécution agentique. Douze semaines de découverte nourrissant un pipeline qui livre en un après-midi, ça allait casser de toute façon ; la découverte doit comprimer aussi, et cette compression, faite sans perdre la rigueur, c'est la vraie frontière. On en a écrit plus dans ce qu'est l'intelligence des exigences et comment comprimer des semaines de découverte en heures.
À quoi ressemble vraiment un flux découverte-vers-spec?
Découverte, puis spec, puis agent. Dans cet ordre, sans sauter d'étape. La séquence est assez simple pour tenir sur un Post-it, et presque toutes les équipes en 2026 la roulent à l'envers, en partant de la spec parce que c'est là que les beaux outils neufs commencent.
Voici l'ordre qui marche. D'abord, la découverte structurée surface et valide l'ensemble des exigences, avec les conflits résolus, les hypothèses consignées et les arbitrages attribués à des propriétaires nommés. Ensuite, cet ensemble validé coule dans un outil piloté par specs comme Kiro ou Spec Kit, qui fait ce pour quoi il est vraiment excellent : formaliser les exigences, prouver la cohérence interne et générer des critères d'acceptation propres et traçables. Puis l'agent de codage exécute une spec qui décrit enfin le bon système, vite et sans dérive d'intention. Chaque couche fait la job pour laquelle elle est bonne, et aucune n'a à couvrir pour celle d'avant.
L'ordre, c'est tout l'enjeu
Le développement piloté par specs est réel, et vous devriez l'adopter. Kiro, Spec Kit, BMAD et Tessl ne sont pas le problème. Le problème, c'est de pointer une couche d'exécution impeccable vers des exigences jamais découvertes, puis d'être surpris que le code soit faux dans les délais.
Réglez la découverte d'abord. Placez la couche spec en aval. Laissez l'agent rouler en dernier. Une équipe qui place l'ordre comme il faut transforme le même outillage que tout le monde possède en avantage durable, et une équipe qui l'inverse livre juste la mauvaise chose plus vite que jamais. C'est le même fil que dans nos textes sur la règle du 29x et sur pourquoi les agents IA ne savent toujours pas poser les bonnes questions.
Quelles sont les questions les plus fréquentes sur la qualité des exigences en SDD?
