L'intelligence des exigences est la discipline qui combine découverte guidée par l'IA, analyse multi-expert et mémoire organisationnelle pour produire des exigences logicielles prêtes à implémenter. Version courte. La version longue commence au neuvième étage d'une tour à bureaux au centre-ville de Montréal, il y a treize ans, avec une démo que j'ai jamais vraiment réussi à oublier.
La revue de sprint devait durer trente minutes. Je m'en souviens parce que j'avais un appel avec un fournisseur à 15 h 30, et je pensais sortir avec du temps en banque. Au lieu de ça, j'ai regardé sept développeurs, deux analystes d'affaires, un propriétaire de produit et un chargé de projet s'asseoir dans une salle sans fenêtres au neuvième étage d'une tour à bureaux au centre-ville de Montréal pendant que le développeur principal présentait une démo qui n'avait rien à voir avec ce que le client voulait. Rien. Pas « c'était proche ». Pas « il manquait quelques cas limites ». La fonctionnalité sur laquelle on avait passé onze semaines résolvait un problème que le client n'avait pas. Le visage de la chargée de projet s'est figé. Un des analystes d'affaires a dit, à voix haute : « C'est pas ce que je voulais dire. » Cette phrase-là, ça fait peut-être treize ans qu'elle me suit.
J'ai 25 ans dans la livraison de logiciels d'entreprise. J'ai vu ce pattern se reproduire dans des organisations de toutes tailles, dans toutes les industries, sur quatre continents. Des gens brillants qui construisent la mauvaise affaire parce que les exigences étaient incomplètes, ambiguës, ou bâties sur des suppositions que personne n'a contestées. Et voici ce qui m'a poussé à bout : la recherche PMI de 2025 montre que seulement 50 % des projets dans le monde sont considérés comme réussis, et 39 % des échecs sont attribués directement à une mauvaise collecte d'exigences. Cause numéro un. Pas les coupures budgétaires. Pas les mauvais développeurs. Pas le scope creep (qui est généralement un symptôme, pas une cause). Les exigences.
Cinquante et un millions par milliard. C'est pas une erreur d'arrondi. C'est le budget annuel d'un département au complet qui s'évapore parce que quelqu'un n'a pas posé les bonnes questions au bon moment, ou les a posées mais n'a pas capturé les réponses d'une façon qui survit au transfert vers l'équipe de développement. Pendant 25 ans, je me suis dit que les outils allaient finir par rattraper le retard. Non. Les outils se sont améliorés pour suivre les exigences après leur rédaction. Personne ne s'occupait de la rédaction elle-même.
C'est pour ça que j'ai commencé à penser à l'intelligence des exigences comme discipline. Pas un outil. Pas une fonctionnalité. Une discipline.
Qu'est-ce que l'intelligence des exigences, et pourquoi maintenant ?
L'intelligence des exigences logicielles, c'est la discipline qui utilise la découverte structurée guidée par l'IA, l'analyse multi-expert et l'ancrage dans les connaissances organisationnelles pour produire des exigences complètes, validées et prêtes à l'implémentation. Cette définition est précise exprès. Chaque mot gagne sa place.
Guidée par l'IA veut dire que le processus est dirigé par l'intelligence artificielle, pas juste assisté par elle. L'IA n'attend pas que quelqu'un colle un prompt dans ChatGPT en espérant le meilleur. Elle guide activement l'élicitation : poser des questions de suivi, identifier les trous dans ce qui a été fourni, signaler les contradictions, faire remonter les risques qu'aucune personne seule ne verrait parce qu'aucune personne seule ne détient le portrait complet. Découverte structurée veut dire que l'élicitation suit un cadre répétable et vérifiable, pas une conversation qui disparaît quand l'onglet du navigateur se ferme. Analyse multi-expert veut dire que les exigences sont évaluées depuis plusieurs perspectives spécialisées simultanément. Et ancrage des connaissances veut dire que chaque exigence est rattachée à l'historique de l'organisation, aux décisions prises sur les projets précédents, aux patterns qui ont fonctionné, aux erreurs qui ont coûté cher.
Pourquoi maintenant ? Deux forces ont convergé. Premièrement, le coût de se tromper dans les exigences n'a pas changé depuis des décennies (c'a toujours été catastrophique), mais la vitesse à laquelle les équipes construisent à partir de ces exigences a accéléré de façon dramatique. Les outils de codage IA permettent aux développeurs de produire du code fonctionnel en heures. Si les exigences sous ce code sont mauvaises, on génère de la dette technique à une vitesse sans précédent. Deuxièmement, les grands modèles de langage ont enfin la capacité de raisonnement pour participer de façon significative à l'analyse des exigences. Pas pour remplacer l'analyste. Pour travailler à côté de lui, en tenant cinq perspectives spécialisées en parallèle, sans jamais oublier une contrainte mentionnée au paragraphe 47 d'un document de 200 pages. Ça, c'était pas possible il y a trois ans.
Bon, je vais être honnête : j'ai résisté à ce cadrage pendant un moment. Je continuais à appeler ça « exigences assistées par l'IA » ou « collecte intelligente d'exigences ». Mais ces expressions décrivent une fonctionnalité, pas une discipline. Et ce qu'on construit, c'est une discipline, avec ses propres principes, sa propre méthodologie, et ses propres critères de succès.
L'intelligence des exigences, est-ce la même chose que les besoins en renseignement ?
Non. Deux disciplines sans aucun lien qui se rentrent dedans dans une boîte de recherche, fait qu'aussi bien les séparer tout de suite. L'intelligence des exigences logicielles, le sens utilisé partout dans cet article, c'est une pratique de livraison logicielle : découvrir, valider et ancrer ce qu'un système doit faire avant que quelqu'un le construise. Le résultat, c'est un ensemble d'exigences complètes, testables et traçables.
En cybersécurité, on parle plutôt de besoins en renseignement, et surtout de besoins prioritaires en renseignement : les questions auxquelles une équipe de renseignement sur les menaces doit répondre pour appuyer une décision de sécurité. Quels adversaires nous visent ? Quels indicateurs surveiller ? Ça, c'est de la collecte et de l'analyse sur des menaces. Rien à voir avec la spécification d'un logiciel.
Mêmes mots, univers différent. Si vous cherchiez du renseignement de sécurité, vous êtes à la mauvaise place. Si vous cherchiez plutôt comment une équipe arrête de construire le mauvais logiciel, vous êtes en plein dedans, et la suite pratique de l'intelligence des exigences logicielles se trouve dans comment réduire la reprise des exigences et ce que fait vraiment un outil d'analyse des écarts d'exigences.
Quels sont les trois piliers de l'intelligence des exigences ?
Trois piliers. Pas cinq, pas sept, pas un « cadre exhaustif » avec douze sous-composantes. Trois, parce que chaque couche de complexité qu'on ajoute à une méthodologie est une couche que les équipes vont ignorer sous pression de délai. J'ai vu trop de processus lourds s'effondrer dès qu'un projet chauffe. Ces trois-là tiennent parce que chacun résout un mode de défaillance distinct, et en retirer un seul brise le système.
Pilier 1 : Découverte structurée
La collecte traditionnelle d'exigences dépend de la compétence de la personne qui anime l'atelier. Un bon analyste d'affaires pose des questions incisives, attrape les contradictions en temps réel, et sait quand tenir tête à un stakeholder qui confond sa préférence avec un besoin d'affaires. Un analyste moyen note ce que les gens disent et passe à autre chose. La découverte structurée élimine cette dépendance. L'IA guide le processus d'élicitation à travers une séquence de questions calibrées selon le type de projet, le contexte de l'industrie, et la complétude de ce qui a été fourni jusqu'ici.
Pensez-y comme un protocole diagnostique en médecine. Un bon médecin ne pose pas des questions au hasard. Il suit un arbre de décision qui s'adapte selon vos réponses, bifurquant vers un territoire plus spécifique à mesure que les symptômes réduisent les possibilités. La découverte structurée fait la même chose pour les exigences. « Vous avez mentionné une intégration avec votre ERP. Quels modules ? Quelle fréquence d'échange de données ? Y a-t-il des contraintes de latence ? Est-ce que cette intégration a été tentée avant, et si oui, qu'est-ce qui a planté ? » Chaque réponse ouvre une nouvelle branche. Chaque branche est suivie, horodatée, et rattachée à l'exigence qu'elle informe.
La différence pratique, c'est la vitesse et la complétude. Dans un atelier traditionnel, on couvre peut-être 60-70 % de la surface des exigences dans une session de deux heures, et on passe les trois semaines suivantes à courir après le 30 % restant par messages Slack et réunions de suivi que la moitié des parties prenantes manquent. La découverte structurée ne vous laisse pas avancer tant que les branches critiques ne sont pas résolues. Elle est implacable, d'une façon qu'un analyste poli ne l'est souvent pas.
Pilier 2 : Analyse multi-expert
C'est là que la plupart des approches actuelles échouent complètement. Un analyste d'affaires rédige une exigence. Peut-être qu'un architecte de solutions le révise. Peut-être. Dans mon expérience (et je dis ça ayant travaillé sur probablement deux cents projets au cours de ma carrière), la révision est superficielle. « Ça a l'air correct. » L'architecte vérifie les impossibilités techniques évidentes et passe à autre chose. Personne ne vérifie l'exigence du point de vue UX. Personne ne le stress-teste pour les implications de sécurité. Personne ne joue l'avocat du diable en demandant : « Et si cette exigence était fausse ? »
L'analyse multi-expert règle ça en faisant passer chaque exigence à travers cinq perspectives spécialisées simultanément. Je vais les décrire en détail dans la prochaine section, mais le principe est simple : une exigence qui survit à l'examen d'un analyste d'affaires, d'un chercheur en expérience utilisateur, d'un architecte de solutions, d'un analyste de sécurité, et d'un critique Red Team, c'est une exigence qui a été contestée sous tous les angles qui comptent. Les lacunes qui survivent à un seul réviseur ne survivent pas à cinq.
Pilier 3 : Ancrage des connaissances
Celui-là, c'est personnel pour moi parce que j'ai vu la même erreur se répéter sur trois projets successifs dans la même organisation, plus souvent que je peux compter. Littéralement. Le même pattern d'intégration qui a planté en 2019 est reproposé en 2022 parce que l'équipe qui a appris la leçon est partie et personne n'a documenté pourquoi la décision avait été prise.
L'ancrage des connaissances connecte chaque nouvelle exigence à l'historique de l'organisation. Décisions passées. Contraintes architecturales. Leçons apprises. Limitations de fournisseurs. Changements réglementaires. L'IA ne vérifie pas seulement si l'exigence est cohérente en interne; elle vérifie si elle contredit quelque chose que l'organisation sait déjà. « Cette approche a été tentée dans la migration paiements du T3 2023. Elle a échoué parce que l'API du fournisseur ne supporte pas le traitement par lots au-dessus de 10 000 enregistrements. Voulez-vous continuer quand même, ou ajuster l'approche ? » Ça, c'est l'ancrage des connaissances. C'est la mémoire organisationnelle rendue actionnable.
Sans ça, chaque projet repart de zéro. Avec, chaque projet construit sur tout ce que l'organisation a déjà appris. La différence dans les résultats est énorme.
En quoi l'intelligence des exigences diffère-t-elle de la gestion des exigences ?
Je tiens à être clair : c'est pas une critique de Jira, DOORS, Azure DevOps, ou de quelque plateforme de gestion des exigences que ce soit. Je les ai tous utilisés. Ils sont bons pour ce qu'ils font. Le problème, c'est ce qu'ils ne font pas.
Les outils de gestion des exigences sont conçus pour le cycle de vie après qu'une exigence existe : la stocker, la versionner, la lier à des cas de test, suivre son statut pendant le développement. Ils répondent à « où est cette exigence ? » et « est-ce qu'elle a été implémentée ? » Ce sont des questions utiles. Mais ils présument que l'exigence est déjà rédigée, déjà complète, déjà correcte.
L'intelligence des exigences opère en amont. Elle aide à créer de meilleures exigences dès le départ.
| Capacité | Gestion des exigences | Intelligence des exigences |
|---|---|---|
| Focus principal | Suivi, stockage, versionnage après rédaction | Découverte, analyse, validation pendant la rédaction |
| Détection des lacunes | Manuelle (dépend du réviseur) | Systématique (guidée par IA, multi-perspective) |
| Réutilisation des connaissances | Recherche manuelle dans les anciens docs | Ancrage automatique dans l'historique org. |
| Perspectives d'experts | Qui est assigné à la révision | Cinq agents spécialisés en parallèle |
| Support à l'élicitation | Gabarits et listes de vérification | Entrevues guidées adaptatives et ramifiées |
| Prêt à l'emploi | Exigences formatées (peuvent contenir des lacunes) | Exigences validées, prêtes à l'implémentation |
Les deux sont complémentaires. L'intelligence des exigences produit de meilleurs intrants. La gestion des exigences suit ces intrants dans leur cycle de vie. Idéalement, on utilise les deux. Le problème que je vois sans arrêt, c'est des équipes qui investissent massivement dans l'outillage de gestion en présumant que la qualité de ce qui entre dans ces outils, c'est le problème de quelqu'un d'autre. C'est le problème de personne. C'est ça, le trou.
Voici la façon la plus nette que je connais de tracer la ligne. La gestion répond à ce qui est arrivé à une exigence. L'intelligence répond à ce que cette exigence devrait dire, et à ce qui manque dedans. Un bord, c'est un registre, et un bon registre vaut de l'or, parce que la traçabilité en contexte d'audit, c'est pas optionnel chez Desjardins, dans un hôpital, ou partout où un régulateur peut cogner à la porte. L'autre bord, c'est la découverte. Deux jobs différentes.
Bon. La confusion se comprend, parce qu'il y a maintenant plein d'outillage qui s'assoit entre les deux. L'analyse automatisée qui note les phrases déjà écrites, c'est une vraie capacité et ça attrape de vrais défauts, mais corriger un texte qui existe, c'est pas la même job que trouver l'exigence que personne n'a écrite, une distinction que je décortique dans pourquoi l'analyse automatisée des exigences n'est pas de l'intelligence des exigences. Un correcteur peut pas signaler une absence. Rien. Pas tant que quelque chose va la chercher exprès.
Je pensais que les équipes devaient choisir. Non. Les organisations de livraison les plus solides que j'ai vues font les deux : l'intelligence en amont pour produire la spec, la gestion en aval pour la tracer à travers le build, les tests et la mise en production. Pour le comparatif détaillé de là où chacune commence et s'arrête, lisez intelligence des exigences ou gestion des exigences.
Pourquoi une approche multi-agent produit-elle de meilleures exigences ?
Gartner prédit que 40 % des applications d'entreprise intégreront des agents IA spécifiques d'ici la fin 2026, en hausse par rapport à moins de 5 % en 2025. C'est une accélération stupéfiante. Mais la plupart des implémentations traitent les agents comme des assistants à usage unique : un agent pour la revue de code, un agent pour le service à la clientèle, un agent pour l'analyse de données. L'intelligence des exigences utilise plusieurs agents travaillant de concert sur le même artefact, chacun apportant une lentille professionnelle différente.
Cinq agents. Voici ce que chacun fait, et (plus important) pourquoi chacun compte.
L'agent analyste d'affaires évalue la complétude fonctionnelle. Est-ce que l'exigence spécifie ce qui arrive quand l'utilisateur clique sur « soumettre » ? Et quand il clique sur « annuler » ? Et quand il ferme le navigateur en pleine transaction ? Et quand deux utilisateurs soumettent le même formulaire en même temps ? Cet agent pose les questions qu'un analyste d'affaires rigoureux poserait, sauf qu'il ne se fatigue jamais à 16 h un vendredi et il ne présume jamais que « l'équipe va régler ça pendant l'implémentation. »
L'agent chercheur UX vérifie les lacunes d'utilisabilité. Est-ce que l'utilisateur peut vraiment accomplir son objectif avec ces exigences ? Y a-t-il un workflow qui demande sept clics quand deux suffiraient ? Est-ce que l'exigence tient compte de l'accessibilité, du mobile, de l'utilisateur qui fait cette tâche pour la première fois versus l'utilisateur expérimenté qui la fait deux cents fois par jour ? J'étais sceptique au début. Je pensais que le UX était trop subjectif pour un agent IA. J'avais tort. L'agent attrape les problèmes UX structurels (chemins de navigation manquants, terminologie incohérente entre les écrans, workflows qui finissent en cul-de-sac) avec une constance remarquable.
L'agent architecte de solutions évalue la faisabilité technique et le risque d'intégration. Est-ce que cette exigence peut être implémentée dans l'architecture existante ? Est-ce qu'il nécessite des changements d'infrastructure que personne n'a budgétés ? Est-ce qu'il entre en conflit avec une limitation d'API, une contrainte de base de données, un seuil de performance ? Cet agent prévient la catégorie la plus coûteuse d'échec d'exigence : l'exigence qui est parfaitement claire mais techniquement impossible (ou techniquement possible seulement à dix fois le coût estimé).
L'agent analyste de sécurité scanne les surfaces de menace. Est-ce que l'exigence expose des données sensibles ? Est-ce qu'il crée une faille d'authentification ? Est-ce qu'il introduit un nouveau vecteur d'attaque ? Dans mon expérience, la révision sécurité des exigences est l'étape qui se fait sauter le plus souvent sous pression de délai. « On fera la révision sécurité en QA. » Rendu là, l'architecture est figée. Corriger une faille découverte en QA, c'est une refonte. La détecter dans les exigences, c'est un paragraphe à modifier.
L'agent critique Red Team est la couche adversariale. Sa job, c'est de trouver l'exigence la plus faible et de l'attaquer. « Cette exigence suppose que l'API du fournisseur va toujours répondre en moins de 200 millisecondes. Qu'est-ce qui arrive quand c'est pas le cas ? C'est quoi le plan B ? Qui a décidé que 200 millisecondes était le bon seuil, et quelles données supportent ça ? » Le critique n'accepte pas « ça devrait être correct. » Le critique demande des preuves ou signale la lacune. J'ai ajouté cet agent en dernier, et honnêtement, c'est celui qui produit les insights les plus inconfortables (et les plus précieux).
Cinq perspectives. Un ensemble d'exigences. Les lacunes qui passent à travers un agent se font attraper par un autre. C'est pas un bénéfice théorique; c'est une garantie structurelle qui découle de l'architecture du processus lui-même.
À quoi ressemble l'intelligence des exigences en pratique ?
Je vais vous donner un pattern que j'ai vu se répéter peut-être vingt ou trente fois dans différentes organisations, différentes industries, différentes décennies. Une entreprise décide de moderniser un système central. Ça peut être leur plateforme de facturation, leur workflow d'intégration client, leur gestion d'inventaire. Ça change rien. Le pattern est le même.
Dans une grande transformation d'entreprise à laquelle j'ai participé (services financiers, environ 3 000 employés, migration d'un mainframe vers une architecture de microservices), la phase d'exigences a duré quatorze semaines. Quatorze. Quatre analystes d'affaires à temps plein. Ils ont produit un document de spécifications de 340 pages que l'équipe de développement a passé trois semaines juste à lire. Quand l'implémentation a commencé, l'équipe a découvert dès le premier sprint que le document contenait 23 exigences qui se contredisaient. Pas subtilement. Directement. L'exigence 147 disait que le système devait traiter les transactions par lots la nuit. L'exigence 203 disait que le système devait traiter les transactions en temps réel. Les deux avaient été approuvés par des parties prenantes différentes qui ne se parlaient jamais.
Les contradictions ont coûté onze semaines de reprise. Onze semaines, quatre développeurs, un commanditaire de projet très frustré. Et c'était un projet bien géré selon les standards de l'industrie. Les analystes étaient expérimentés. Les parties prenantes étaient engagées. Le processus n'était tout simplement pas conçu pour attraper les contradictions transversales dans un document de 340 pages. Aucun processus humain ne l'est, à cette échelle.
Une approche d'intelligence des exigences aurait signalé la contradiction entre les exigences 147 et 203 avant que le document ne quitte la phase de découverte. L'analyse multi-expert l'aurait détectée parce que l'agent architecte de solutions évalue la faisabilité d'implémentation (on ne peut pas être à la fois batch et temps réel), et le critique Red Team aurait signalé le décalage d'hypothèses. Quatorze semaines de découverte compressées. Onze semaines de reprise évitées.
Voici ce qui change avec l'intelligence des exigences dans ce scénario. La phase de découverte structurée s'adapte à la complexité du projet. Au lieu de quatorze semaines d'ateliers qui produisent un document de 340 pages que personne ne peut garder en tête, l'élicitation guidée par IA fait remonter chaque exigence individuellement, la valide contre ce qui a déjà été capturé, et signale les contradictions immédiatement. Pas après que le document soit « fini. » Pendant la conversation elle-même.
L'analyse multi-expert roule en parallèle avec la découverte, pas après. Chaque exigence obtient cinq perspectives avant d'être considérée complète. L'agent analyste d'affaires vérifie la complétude fonctionnelle. L'agent architecte de solutions vérifie la faisabilité technique. L'agent analyste de sécurité vérifie l'exposition. L'agent chercheur UX vérifie l'utilisabilité. Le critique Red Team conteste les hypothèses sous-jacentes. Quand une exigence est marquée « validée », elle a été stress-testée plus rigoureusement que la plupart des exigences le sont pendant tout leur cycle de vie.
Et la couche d'ancrage des connaissances empêche l'organisation de faire la même erreur deux fois. « Ce pattern d'intégration a été essayé en 2021. Il a échoué parce que l'API du fournisseur avait une limite de 5 000 enregistrements par lot qui n'était pas documentée. La contrainte existe toujours. » C'est le genre de connaissance institutionnelle qui vit normalement dans la tête d'une seule personne. Quand cette personne part (et elle part toujours), la connaissance part avec elle. L'intelligence des exigences la capture et la rend disponible pour chaque futur projet.
Je m'attendais à ce que la plus grande valeur vienne de l'analyse multi-agent. J'avais partiellement tort. Le pilier d'ancrage des connaissances a produit les résultats les plus surprenants dans chaque implémentation dont j'ai été proche, parce que le coût de répéter une erreur connue est toujours plus élevé que le coût d'en attraper une nouvelle.
À retenir : l'intelligence des exigences est une discipline, pas une fonctionnalité
L'intelligence des exigences, c'est pas un plugin qu'on ajoute à Jira. C'est pas un prompt ChatGPT. C'est une discipline qui combine trois capacités : la découverte structurée (l'élicitation guidée par IA qui fait remonter les lacunes systématiquement), l'analyse multi-expert (cinq agents spécialisés qui contestent chaque exigence sous différentes perspectives professionnelles), et l'ancrage des connaissances (la mémoire organisationnelle qui empêche de répéter les erreurs passées).
La discipline existe parce que le trou qu'elle comble a été la cause numéro un des échecs de projets pendant des décennies : 51 millions de dollars gaspillés par milliard dépensé, 39 % des échecs attribués à de mauvaises exigences. Les outils traditionnels suivent les exigences après leur rédaction. L'intelligence des exigences les améliore pendant qu'ils sont rédigés. C'est ça la distinction. Et si vous retenez une seule chose de cet article, retenez ceci : les exigences les plus coûteuses sont celles qui ont l'air complètes mais ne le sont pas.
Comment l'intelligence des exigences s'insère-t-elle dans les workflows pilotés par specs ?
Une couche en amont. C'est exactement là que vit l'intelligence des exigences par rapport à tous les outils de développement piloté par specs dont on parle cette année. AWS Kiro, GitHub Spec Kit, toute la vague spec-first : ça part d'une spec et ça pousse un agent vers du code qui la respecte. Honnêtement, c'est utile. Mais voici le bout que l'outillage tient pour acquis : la spec doit être correcte avant qu'on puisse l'imposer. L'intelligence des exigences, c'est la couche de découverte qui la rend correcte.
Pensez-y deux secondes. Une spec, c'est quoi ? C'est l'enregistrement de décisions que quelqu'un a déjà prises. Un outil piloté par specs garde l'agent honnête face à ces décisions, ce qui tue la dérive d'intention et la perte de contexte. Mais il ne peut pas, jamais, aller demander au superviseur pourquoi la règle FIFO a une exception. Il ne peut pas interviewer la seule personne qui se souvient de l'exigence réglementaire de journalisation. Ça, c'est de la découverte. Et la découverte, c'est le trou. Quand AWS a vérifié les premiers brouillons d'exigences qui nourrissaient Kiro, la majorité avaient besoin d'être retravaillés avant même d'être sécuritaires à bâtir. On a creusé ce constat, et ce qu'il signifie pour quiconque mise sur les specs, dans Vos specs sont le problème, pas vos agents IA. La version courte ? Une spec structurellement parfaite d'une mauvaise exigence reste une mauvaise exigence. Juste plus vite.
Fait que les deux disciplines se battent pas. Elles s'empilent. L'intelligence des exigences fait rouler la découverte structurée, l'analyse multi-expert et l'ancrage des connaissances pour produire un ensemble d'exigences validées. Ensuite, l'outil piloté par specs prend cet ensemble validé et tient l'implémentation responsable. Découverte d'abord, application ensuite. Sautez la première moitié et vous obtenez un chemin magnifiquement gouverné vers la mauvaise destination. J'ai vu des équipes adopter Kiro ou Spec Kit, sentir la vitesse, et présumer que la vitesse voulait dire justesse. C'était pas le cas. La spec était propre. L'exigence en dessous n'avait jamais été remise en question.
Quelles sont les questions les plus fréquentes sur l'intelligence des exigences ?
