Le rapport était vert. Quatre-vingt-quatorze exigences, quatre avertissements de mots faibles, un doublon signalé, pis on a vidé la liste au complet en une vingtaine de minutes un mardi après-midi avant d'envoyer le paquet à l'équipe de développement avec une note qui disait, en gros, celle-là est propre. Six semaines plus tard, un billet de soutien rentre et personne sait où le router. Un client avait déménagé de l'Ontario vers le Québec en plein milieu de son abonnement, la TVQ était censée s'appliquer au cycle de facturation suivant, et pas une seule exigence dans ce beau paquet propre ne disait ce que « cycle suivant » voulait dire pour quelqu'un qui avait déjà été facturé. Pas ambigu. Absent.
Soyons justes envers l'outil, parce que j'ai vu du monde blâmer la mauvaise affaire là-dessus. Il a lu quatre-vingt-quatorze exigences pis il a noté quatre-vingt-quatorze exigences. Il n'y a jamais eu de quatre-vingt-quinzième à lire. Un analyseur d'exigences qui inventerait celles que vous avez oubliées serait un produit pas mal pire que celui qui se tait, fait que le silence était le bon comportement, et c'est moi qui ai lu ce silence comme un signal d'exhaustivité. Moi. Pas le fournisseur.
La nuance a l'air pointilleuse jusqu'à ce qu'elle vous coûte un trimestre. L'analyse automatisée des exigences est une vraie catégorie qui fait du vrai travail : des outils comme ScopeMaster lisent ce que vous avez écrit, notent l'ambiguïté et la testabilité, signalent les doublons et mesurent la taille fonctionnelle, plus vite et pas mal plus constamment qu'un réviseur humain rendu au troisième jour d'une revue. Je recommande cette couche. Ce que je conteste, ce n'est pas un produit, c'est une erreur de catégorie : croire qu'un rapport propre dit quoi que ce soit sur les exigences qui ne sont pas dedans.
Que fait vraiment l'analyse automatisée des exigences ?
Elle lit les exigences que vous avez déjà écrites et les note selon des règles linguistiques et structurelles. Des mots faibles. Des tournures passives, des pronoms sans antécédent clair, des critères d'acceptation qu'aucun test ne pourrait jamais infirmer, deux exigences qui disent la même chose avec un vocabulaire différent, une taille fonctionnelle qui n'a rien à voir avec l'estimation que quelqu'un a mise dans le plan. C'est du travail ingrat et payant, et le résumé honnête, c'est que les machines sont meilleures que nous là-dedans, parce que la constance à 16 h, c'est une propriété de machine, pas une propriété humaine.
Les chiffres de performance sont meilleurs que ce que les sceptiques imaginent, mais moins bons que ce qu'un tableau de bord laisse entendre. Max Unterbusch et Andreas Vogelsang, de l'Université de Duisbourg-Essen, ont testé la prédiction de défauts sur le banc d'essai QuRE en janvier 2026, avec 1 266 exigences Mercedes-Benz annotées pour les mots faibles par jusqu'à trois testeurs internes. Leur meilleure configuration atteint 0,686 de précision pour 0,967 de rappel. Relisez ça lentement. Près de trois signalements sur dix n'étaient pas des défauts pantoute, ce que les auteurs expliquent au lieu de le cacher : les règles de base sur-signalent volontairement, parce que dans les faits la plupart de ce qu'elles attrapent est inoffensif dans son contexte.
Tenez les deux faits ensemble, l'argument tient là-dessus. La couche fonctionne. Et chaque vérification qu'elle exécute, sans une seule exception parmi l'ambiguïté, la testabilité, les doublons et la taille fonctionnelle, prend comme intrant une phrase que quelqu'un a déjà tapée.
Qu'est-ce qu'un correcteur d'exigences ne pourra jamais attraper ?
L'exigence qui n'a jamais été écrite. C'est toute la réponse, et ce n'est pas une limite que quelqu'un va faire disparaître avec un meilleur modèle, parce que c'est une propriété de l'intrant et non de l'algorithme. Un correcteur ne peut pas signaler l'exception que personne n'a documentée, la partie prenante que personne n'a interviewée, la condition réglementaire que tout le monde pensait être le problème de quelqu'un d'autre, ou l'état dans lequel votre système tombe deux fois par année pendant la conciliation. Aucune phrase n'annonce sa propre absence. Rien à noter.
Je veux éviter d'exagérer, parce que la version honnête est plus intéressante que la version absolutiste. Certaines absences laissent une trace : une exigence qui référence un statut jamais défini, un terme de glossaire employé une fois et jamais lié, un critère d'acceptation dont la précondition n'apparaît nulle part. Les bons attrapent ça. Ce qu'aucun ne peut attraper, c'est la spécification propre, cohérente et bien formulée qui s'arrête simplement trop tôt, et c'est justement ce mode de défaillance qui survit à la revue parce qu'il a l'air fini.
Le 19 juillet 2024, CrowdStrike a livré le fichier de canal 291. Un validateur de contenu automatisé l'a vérifié. Il a passé. Des millions de machines Windows ont ensuite refusé de démarrer, environ 8,5 millions d'appareils selon le chiffre avancé plus tard par Microsoft, pendant que des compagnies aériennes, des hôpitaux et des banques passaient la fin de semaine à les récupérer à la main.
Le mécanisme, c'est le boutte qui vaut la peine. L'analyse de cause racine publiée par CrowdStrike décrit un type de gabarit qui déclarait 21 champs de paramètres d'entrée, alors que le code qui l'appelait n'en fournissait que 20. Le validateur vérifiait le fichier contre 21. L'interpréteur en recevait 20. Quand une instance a fini par arrêter d'utiliser un joker et est allée chercher pour vrai cette vingt-et-unième valeur, il n'y avait rien là, pis une lecture hors limites a fait tomber la machine au complet.
Voici pourquoi c'est une histoire d'exigences et pas une histoire de gestion mémoire. L'écart était resté latent à travers la validation de build, les tests de charge et plusieurs déploiements réussis sur le terrain, parce que les instances précédentes utilisaient un joker sur ce vingt-et-unième champ et n'allaient jamais chercher de valeur. La validation a roulé. La validation a passé. Ce qui n'était écrit nulle part, c'était le contrat lui-même : le nombre de champs déclarés par le gabarit doit égaler le nombre fourni par l'appelant. Personne n'a écrit cette exigence-là, fait que rien ne la testait, fait que chaque coche verte cette fin de semaine-là était une vraie réponse à la mauvaise question.
Sources : CrowdStrike, External Technical Root Cause Analysis, Channel File 291, publiée le 6 août 2024, pour le mécanisme (analyse du fournisseur sur son propre incident, identifiée comme telle), et Microsoft, « Helping our customers through the CrowdStrike outage », 20 juillet 2024, pour l'estimation de 8,5 millions d'appareils. Industrie : logiciel de sécurité des terminaux.
Pourquoi un rapport d'analyse vert ne veut pas dire un ensemble complet ?
Parce que la qualité et la couverture sont deux mesures différentes, et qu'une seule des deux a été prise. Un rapport vert est un énoncé précis et fiable qui vient avec une portée que presque personne ne lit : les exigences présentes dans ce document sont bien formulées. Une portée. Pas une couverture. On sait dire ça dans tous les autres contextes d'ingénierie, et on le répète tout le temps : cent pour cent des tests qui passent ne vous dit absolument rien sur le comportement pour lequel personne n'a pensé à écrire un test.
Les chiffres d'Infineon rendent la chose inconfortablement concrète. Ce qu'un correcteur mesure le mieux, c'est la surface linguistique d'une exigence, et dans ce jeu de données la surface n'était que faiblement corrélée à la difficulté réelle de raffinement. L'incomplétude contextuelle était corrélée plus de deux fois plus fort. La verbosité ? Presque rien. L'outillage vise la variable qui compte le moins, pas parce que quelqu'un l'a mal conçu, mais parce que c'est la seule variable qu'un document expose.
Il y a un coût psychologique par-dessus le coût de mesure, et je le soupçonne d'être le plus gros des deux. Le vert met fin aux conversations. Point final. La revue qui aurait fait sortir le cas de la TVQ n'a jamais lieu, parce que l'artéfact est revenu propre et que l'invitation de rencontre se fait décliner sans bruit, et la confiance est exactement le mauvais extrant à donner à une équipe dont le vrai risque est invisible pour l'instrument qui vient de la rassurer.
Comment l'intelligence des exigences produit ce que l'analyse ne fait que vérifier ?
En travaillant une couche plus tôt, sur la matière qui existait avant la spécification. Des transcriptions d'entrevues. Des fils de billets, la politique interne que personne n'a ouverte depuis le dernier audit, la chicane dans un canal qui s'est réglée parce que quelqu'un a tapé en dernier, la contrainte qui vit dans la tête d'un seul architecte. L'analyse prend un document en entrée et retourne une note. L'intelligence prend le désordre en entrée et retourne les questions qui auraient dû être posées, ce qui est une autre job complètement et ce qui produit l'artéfact que l'analyseur va valider ensuite.
Concrètement, trouver une absence veut dire comparer avec quelque chose, parce qu'une absence toute seule est invisible. Trois méthodes aident. Passez une liste explicite de catégories de contexte sur chaque exigence, comme les chercheurs d'Infineon l'ont fait, et les trous cessent d'être invisibles pour devenir une liste. Mettez sur le même matériel des réviseurs qui ont des mandats vraiment différents, ce qui est l'argument qu'on a défendu pour l'IA multi-agents en analyse d'affaires et la raison pour laquelle ces agents-là doivent avoir le droit d'être en désaccord. Ensuite, traitez chaque fil non résolu dans une transcription comme une question ouverte plutôt que réglée.
Rien là-dedans ne remplace l'analyseur, pis je vendrais quelque chose de malhonnête en laissant entendre le contraire. Faites rouler les deux. La découverte en premier, pour que l'ensemble soit le bon, ensuite l'analyse, pour que l'ensemble soit bien écrit, ce qui est la séquence que décrit l'intelligence des exigences et celle que la plupart des équipes font présentement à l'envers, ou avec la première moitié qui manque. La défaillance en ouverture n'a pas été causée par un mauvais outil. Elle a été causée par un bon outil qui répondait à une question que je ne lui avais pas posée.
L'analyse note la page. L'intelligence décide ce qui doit être dessus.
L'analyse automatisée des exigences lit, corrige et note les exigences qu'une équipe a déjà écrites, et c'est vraiment utile : détection d'ambiguïté, testabilité, doublons, taille fonctionnelle, tout ça plus vite et plus constamment qu'un réviseur humain. Chacune de ces vérifications a besoin d'une phrase existante comme intrant. Elle ne peut pas signaler l'exigence qui n'a jamais été écrite. L'absence ne laisse rien.
Pas une erreur d'arrondi. Sur les 3 688 exigences de parties prenantes retenues pour raffinement chez Infineon, le contexte opérationnel manquait dans 81,5 % d'entre elles, et l'incomplétude contextuelle prédisait la difficulté de raffinement plus de deux fois plus fort que la verbosité, qui est justement ce que les correcteurs mesurent le mieux. Traitez un rapport vert comme une porte franchie, pas comme un certificat d'exhaustivité. Découverte en premier pour que l'ensemble soit le bon, analyse ensuite pour qu'il soit bien écrit.
Quelles sont les questions les plus fréquentes sur l'analyse automatisée des exigences ?
