Onze personnes ont signé le module d'expédition. Trois jours d'ateliers dans un entrepôt de Boucherville, un mur de post-it, une trentaine de stories dans le backlog et une carte de processus imprimée collée à côté du quai de chargement, et tous ces artefacts-là s'accordaient entre eux. Le cahier à spirale à côté du terminal ne s'accordait avec rien, parce que personne ne l'avait mentionné une seule fois. Fait que j'ai demandé. Les commandes qui partent en deux boîtes, qu'elle m'a dit : le système imprime une étiquette, et la deuxième boîte voyage avec une étiquette écrite à la main. Depuis 2019.
Personne ne cachait ça. N'importe lequel des onze m'aurait parlé de la deuxième étiquette si j'avais posé la question sur la deuxième étiquette, et pas un n'a pensé à l'offrir, parce qu'une affaire que tu fais tous les mardis depuis six ans, ça arrête d'être une décision et ça devient du mobilier. C'était sur aucune liste. Ça n'allait jamais se retrouver sur une liste. Et c'était l'exigence qui aurait fait planter la mise en production.
C'est pour ça que le mot m'achale. On appelle ça de la collecte, comme si les exigences étaient des pommes tombées sous l'arbre, déjà mûres, qui attendent quelqu'un avec un panier pis un après-midi. Cette image-là fixe tranquillement la définition de « terminé » : tu finis quand tu as ramassé tout ce qui traîne. Les meilleurs analystes que j'ai vus en 25 ans dans la livraison de logiciels d'entreprise n'agissent pas pantoute comme des ramasseurs. Ils agissent comme des enquêteurs. Et ça paraît dans ce qu'ils trouvent. C'est là le problème de l'IA en analyse des exigences : un ramasseur plus rapide reste un ramasseur.
Pourquoi « collecte des exigences » est la mauvaise expression ?
Parce qu'elle suppose trois affaires en même temps, et que la plupart des exigences qui décident d'un projet en cassent au moins une. Un : l'exigence existe déjà sous forme finie. Deux : quelqu'un sait où elle est. Trois : il va la donner si on la demande. Le cahier de Boucherville échouait aux trois, et il échouait en silence, ce qui en fait un problème de connaissance et non un problème de rigueur, parce qu'aucune quantité de questions posées dans la même direction n'allait le faire apparaître.
Le vocabulaire de la recherche est plus honnête que le nôtre. Dans une expérience contrôlée publiée en juin 2026, Manoel Salgado Neto, Alan Araujo et Ronnie de Souza Santos décrivent l'élicitation comme des parties prenantes qui communiquent des besoins, négocient des priorités et construisent ensemble une connaissance qui devient ensuite un artefact. Construire. Pas localiser. Si la connaissance doit se bâtir entre des gens qui en détiennent chacun un morceau, un processus dont le critère de succès est « on a ramassé tous les intrants » mesure la mauvaise affaire, et il va déclarer victoire exactement au moment où il arrête d'être utile.
Longtemps, j'ai classé ça dans la chicane de vocabulaire. De la police du dictionnaire. Puis j'ai regardé ce que le mot fait à un calendrier et j'ai changé d'idée, parce que la collecte se budgète exactement comme de la logistique : deux ateliers, un sondage, une signature, fini. Personne ne bloque quatre heures pour s'asseoir à côté de quelqu'un et le regarder travailler. Regarder, ce n'est pas ramasser. Pantoute. Il n'y a pas de ligne pour ça dans le plan, fait que ça n'arrive pas, et le seul objet dans la bâtisse qui savait pour la deuxième étiquette n'entre jamais dans la salle.
Quelle est la différence entre collecter et découvrir des exigences ?
La collecte ramasse ce que le monde est capable de formuler. La découverte vise ce qu'il n'est pas capable de formuler, ce qui demande une autre posture, d'autres questions et un test complètement différent pour savoir si on a fini. Les exigences collectées sont réelles et ça vous en prend. La connexion marche, le rapport s'exporte, le taux de taxe se configure. Ce sont aussi, mot pour mot, celles que l'équipe de votre compétiteur a écrites le trimestre passé, avec le même monde, dans le même genre de salle. Même liste.
La découverte vit dans l'écart entre ce que le monde dit faire et ce qu'il fait. Ça sort dans les exceptions. Le contournement devenu routine, le champ que tout le monde remplit avec une valeur bidon, le rapport que quelqu'un refait à la main chaque mois parce que le vrai est subtilement croche, la règle qui se déclenche juste quand un client déménage de province en plein cycle. Demandez à un analyste d'expérience ce qu'il fait pour vrai : il va décrire quelque chose de plus proche d'un audit que d'une entrevue. Il remonte chaque anomalie jusqu'à son origine et demande depuis quand elle est vraie.
| Collecte | Découverte | |
|---|---|---|
| Ce qu'elle demande | Qu'est-ce que le système doit faire ? | Pourquoi cette exception existe, et depuis quand elle est vraie ? |
| Où elle regarde | Le monde invité à l'atelier | Le travail lui-même, les exceptions, le monde que personne n'a invité |
| Quand c'est fini | Quand la liste arrête de grossir | Quand les questions arrêtent de surprendre |
| Ce qu'elle produit | Les exigences que tout le monde savait déjà | Les exigences que personne n'a pensé à dire |
| Qui peut le faire | N'importe qui, y compris un modèle, vite | Celui qui accepte de s'asseoir devant le travail et de rester curieux |
Il y a une deuxième raison, commerciale celle-là. Ce qui se ramasse se ramasse par n'importe qui. Les exigences que personne ne formule sont les seules qui portent de l'information que vos compétiteurs n'ont pas, ce qui fait de la capacité de découverte un avantage durable et de la capacité de collecte une commodité qu'un modèle de langage exécute maintenant pour le prix d'un abonnement mensuel.
Que fait vraiment l'IA en analyse des exigences, et qu'est-ce qu'elle manque ?
L'IA en analyse des exigences accélère tout ce qui vient après la conversation, et elle est excellente là-dedans. Transcrire, structurer, dédoublonner, transformer quatre-vingt-dix minutes de discussion qui tourne en rond en spécification propre avec des identifiants traçables : un modèle fait ça en secondes, sans fatiguer à 16 h, et je ne reviendrais pas en arrière. Le trouble commence quand un outil qui rend la collecte pas chère se fait traiter comme une preuve que la collecte était la partie difficile.
Une équipe menée depuis l'Université de Pékin a mis un chiffre sur l'écart en mai. Ils ont bâti un agent d'entrevue qui questionne le long d'une ontologie explicite de préoccupations, et l'ont comparé à l'entrevue libre menée par un modèle sur 101 scénarios d'élicitation web. Le point de comparaison, un modèle de pointe laissé seul pour mener l'entrevue, a sorti 13 % des exigences implicites de référence. Le même modèle, questionnant avec une structure, a atteint 69 %.
Regardez la forme du résultat, pas juste le chiffre. La puissance était constante. Ce qui a fait passer la couverture de 13 % à 69 %, ce n'est pas un modèle plus fort, c'est une règle sur quelle question vient ensuite, et c'est exactement ce qu'un analyste senior traîne dans sa tête et qu'un junior n'a pas encore. Les auteurs le disent sans détour : le clavardage libre peine à faire ressortir les exigences implicites de façon systématique. Systématique, c'est le mot important. Parce que le clavardage libre en trouve, des exigences implicites. De temps en temps. Comme on trouve des chanterelles en marchant dans le bois sans carte.
Deux bémols, parce que j'aime mieux que vous fassiez confiance à l'argument qu'au chiffre. C'est un banc d'essai de scénarios web avec une référence connue, pas une étude sur des projets vivants avec du vrai monde, et une vraie entrevue a une dynamique sociale qu'aucun banc d'essai ne modélise. Et 69 %, ce n'est pas 100 %. La lecture honnête, c'est que même un agent bien structuré manque à peu près le tiers de ce que les auteurs considéraient comme trouvable. La structure aide énormément. Elle ne ferme pas l'écart.
Petit échantillon, et je le signale au lieu de m'appuyer dessus. N'empêche que l'ordre est intéressant : le meilleur artefact est venu du modèle à qui on avait donné une conversation humaine, et le modèle qui travaillait seul à partir d'un énoncé propre a perdu contre lui sur la complétude. La discussion d'abord. La synthèse ensuite. C'est la séquence que l'analyse automatisée des exigences suppose elle aussi et n'obtient à peu près jamais, parce qu'un outil qui note votre spécification ne vaut que ce que vaut la découverte qui l'a produite.
Qu'est-ce que la découverte d'abord change dans ce que vous construisez ?
La découverte d'abord change le produit, pas juste le document. Quand on collecte, on bâtit ce que la salle a demandé, c'est-à-dire une version plus rapide de ce qui existe déjà. Quand on découvre, on tombe parfois sur le fait que ce que le monde fait pour vrai n'a rien à voir avec ce que tout le monde pensait qu'ils faisaient. Et ce genre de trouvaille-là ne raffine pas une feuille de route. Elle la réécrit.
Intuit avait bâti Quicken pour les ménages. Puis les données de sondage sont devenues bizarres : les acheteurs faisaient rouler un logiciel de finances personnelles dans un bureau plutôt qu'à la maison. Personne n'avait conçu ça. Personne ne l'avait demandé non plus.
Scott Cook est allé leur parler. Ils s'en servaient pour la tenue de livres, au travail, volontairement. L'hypothèse interne était que toute entreprise utilisait un logiciel comptable. Le résumé de Cook sur ce qu'il a trouvé à la place tient en quatre mots : « No, they hate accounting. » Non, ils haïssent la comptabilité.
Personne n'avait collecté cette exigence-là, parce qu'aucun propriétaire de PME n'allait entrer dans un atelier pour dire « je veux un logiciel comptable sans comptabilité dedans ». Cette phrase-là n'existe qu'après que quelqu'un a observé le comportement et a raisonné à l'envers. Intuit a sorti QuickBooks en 1992 exactement sur ce positionnement, et selon Cook le produit dépassait la compétition en deux mois.
Source : Wisconsin School of Business, « Savor Surprises: A Conversation with Intuit Co-founder Scott Cook », 23 mai 2022, pour le récit de première main de Cook, la citation et la vente en deux mois, qui est son souvenir et non un chiffre audité. Secteur : logiciels comptables pour PME.
Trois habitudes font la job, et aucune ne demande un outil. Regarder, en premier. Regardez le travail avant de poser des questions dessus, parce que le monde décrit le processus qu'il pense suivre, pas celui qu'il roule. Traitez chaque exception comme une boîte pas ouverte : qui l'a créée, quand, et est-ce que la condition qui l'a causée tient encore ? Puis mettez sur le même matériel des relecteurs qui ont des jobs vraiment différentes, ce qui est l'argument derrière l'analyse d'affaires multi-agents et la raison pour laquelle un relecteur unique, humain ou modèle, hérite en général de l'angle mort qui a créé le trou.
Ensuite, servez-vous du modèle. Sans gêne, pour tout ce qu'il fait bien : structurer le fouillis, repérer les contradictions entre deux transcriptions, rédiger les critères d'acceptation, vérifier la spécification contre une grille de couverture. C'est du vrai levier et c'est disponible aujourd'hui. Le mode de défaillance, ce n'est pas d'utiliser l'IA pour l'élicitation. C'est de laisser un ramasseur rapide décider de ce qui compte comme « fini », et de partir en production sur la foi d'une liste qui s'était fermée avant que le cahier sur le bureau soit mentionné une seule fois.
Les exigences ne se ramassent pas. Elles se construisent, et les utiles résistent.
Collecter suppose que l'exigence existe, que quelqu'un sait où elle est, et qu'il va la donner si on la demande. Celles qui décident d'un projet échouent à ces suppositions en silence : elles vivent comme une habitude plutôt qu'une connaissance, fait que personne ne les cache et personne ne les dit non plus. Renommer l'activité n'est pas cosmétique, parce que le nom fixe la définition de « terminé ».
La version mesurée de cet écart : sur un banc d'essai de 101 scénarios d'élicitation, un modèle de pointe menant seul l'entrevue a trouvé 13 % des exigences implicites de référence, alors que le même modèle questionnant le long d'une structure explicite en a trouvé 69 %. La puissance était constante. Juste la discipline du questionnement a changé. Utilisez l'IA pour ce qui vient après la conversation, et gardez la main sur quelle conversation a lieu, parce que c'est la couche d'intelligence des exigences que rien en aval ne peut reconstruire.
Quelles sont les questions les plus fréquentes sur l'IA et l'analyse des exigences ?
