Votre document de requis est un cimetière d'hypothèses

Qu'est-ce qui transforme un document de requis en cimetière d'hypothèses?

Prenez n'importe quel document de requis. Page deux. Deuxième paragraphe. Trouvez la ligne qui dit quelque chose comme "Le système doit fournir une validation robuste des données saisies par l'utilisateur." Arrêtez-vous. Honnêtement: savez-vous exactement ce que "robuste" signifie dans cette phrase, à un niveau de précision tel que si on déployait demain du code qui valide les adresses courriel mais pas les numéros de téléphone, qui rejette les champs vides mais accepte les espaces, qui affiche un message d'erreur en anglais pour tous les paramètres régionaux, ça compterait comme "robuste"? Non. Le document ne le dit pas. Chacun interprète ce mot à travers son propre prisme. La personne en tests le lit autrement. La partie prenante commerciale en a une troisième version dans sa tête depuis six mois, non écrite et jamais contestée. Résultat. Le document ressemble à une décision. C'est en réalité une hallucination collective.

Ça arrive parce que les ateliers de collecte des requis ne sont pas des sessions de découverte structurées. Pantoute. C'est du théâtre. L'équipe s'assoit dans une salle, l'analyste d'affaires passe en revue une liste de fonctionnalités, tout le monde hoche la tête (parce que s'arrêter pour poser des questions de clarification semble impoli quand tout le monde veut partir avant 17h), et on repart tous convaincus d'avoir dit la même chose. Ce n'est pas ce qui s'est passé. On a rempli un document avec des mots qui sonnent précis, puis chaque personne a comblé les lacunes à partir de son propre bagage, de ses projets passés, de ses hypothèses sur ce que l'équipe voulait dire. Ça arrive environ quarante fois par projet. Quand le développement commence, la spécification, c'est peut-être 40 pour cent d'accord réel et 60 pour cent de mines antipersonnel invisibles.

À quoi ressemblent vraiment les hypothèses cachées?

Voici trois exemples tirés de conversations qu'on a eues avec des équipes au cours des 18 derniers mois. Les noms des entreprises sont changés. Les hypothèses sont des copies exactes de leurs documents réels.

Exemple 1: La réinitialisation de mot de passe qui voulait dire trois choses différentes

D'une startup fintech qui construisait la récupération de compte.

"Les utilisateurs peuvent réinitialiser leur mot de passe par vérification par courriel."

Bon. On livre ça. Sauf que: le courriel part-il immédiatement ou après un délai? Pendant combien de temps le jeton de réinitialisation reste-t-il valide (une heure, un jour, jamais)? Si l'utilisateur clique sur le lien de réinitialisation mais n'effectue pas la nouvelle saisie de mot de passe pendant 30 minutes, le jeton expire-t-il? Si l'utilisateur demande une réinitialisation, puis en demande une deuxième avant de compléter la première, est-ce que les deux jetons fonctionnent, ou le premier est-il invalidé? Si le système détecte la réinitialisation à partir d'une adresse IP inhabituelle, demande-t-il une vérification supplémentaire ou envoie-t-il une notification? Que se passe-t-il si le service de messagerie échoue et que le courriel de réinitialisation n'arrive jamais?

L'analyste d'affaires avait un modèle mental. La développeuse principale en avait un différent. La personne responsable de la sécurité en avait un troisième. Chaque hypothèse a divergé. Le requis semblait terminé parce qu'une phrase le couvrait. C'était en réalité 11 requis séparés cachés sous une seule phrase.

Exemple 2: La fonctionnalité de recherche qui a figé en production

D'une entreprise de logiciel-service entreprise à entreprise dans le secteur de l'énergie.

"La boîte de recherche retournera les résultats rapidement."

Que signifie "rapidement"? Moins de 500 millisecondes? Moins de 2 secondes? Que se passe-t-il si l'index de recherche est corrompu ou lent? La recherche expire-t-elle ou attend-elle indéfiniment? Quel est le nombre maximum de résultats que le système retourne (10, 100, tous les enregistrements correspondants)? Quand l'utilisateur saisit des caractères spéciaux (esperluettes, guillemets, antislashs), comment la recherche les gère-t-elle?

L'équipe de développement a supposé que "rapidement" signifiait "aucun délai artificiel." Zéro. Elle a construit le système pour retourner chaque résultat sans limite. Un client avec un million d'enregistrements dans la base de données a exécuté une recherche et a planté son instance. Le requis était dans le document. Le problème vivait à l'intérieur du mot.

Exemple 3: Le modèle de permissions qui assumait une hiérarchie

D'un fournisseur de logiciels de santé gérant les contrôles d'accès.

"Le contrôle d'accès basé sur les rôles doit être mis en oeuvre."

Basé sur les rôles, ça veut dire quoi exactement? Des rôles hiérarchiques (Admin > Gestionnaire > Utilisateur, chacun avec des permissions croissantes)? Ou des rôles plats (Clinicien, Pharmacien, Administrateur, chacun avec des permissions indépendantes)? Un utilisateur peut-il avoir plusieurs rôles en même temps? Un gestionnaire peut-il déléguer des permissions spécifiques sans assigner un rôle complet? L'assignation de rôles se fait-elle au niveau utilisateur ou au niveau département? Si un utilisateur change de département, ses rôles se transfèrent-ils ou se réinitialisent-ils?

L'auteur de la spécification pensait hiérarchique. L'équipe d'implémentation a construit des rôles plats. En fait, ni l'une ni l'autre n'avait tort selon le requis de quatre mots: les deux construisaient simplement des produits différents. Quand les tests d'acceptation ont révélé l'écart, le code a nécessité six semaines de remaniement majeur.

Pourquoi les parties prenantes confondent-elles hypothèses et accords?

Ce n'est pas de la stupidité. Pas de la paresse non plus. C'est simplement la façon dont la communication humaine fonctionne sous pression de délai, et on l'observe dans pratiquement tous les projets qu'on accompagne, que ce soit à Montréal, en Ontario ou à l'international.

Quand une partie prenante dit "Le système devrait être convivial", elle n'est pas vague intentionnellement. Elle utilise un mot qui signifie quelque chose de précis dans son contexte de domaine. Pour la personne en interface, "convivial" signifie peut-être un flux en deux étapes avec des info-bulles. Pour la personne en accessibilité, ça signifie du HTML sémantique et des étiquettes ARIA. Pour l'équipe de succès client, ça signifie que l'intégration aide les nouveaux utilisateurs à atteindre leur premier jalon de valeur en moins de cinq minutes. Les trois interprétations sont raisonnables. Aucune n'est mutuellement exclusive. Ce sont simplement des points focaux différents, et dans un atelier lent et structuré où chaque interprétation reçoit un nom et est testée, l'équipe converge vers une définition partagée, tandis que dans une réunion de 90 minutes avec 12 personnes sur Zoom, l'équipe repart avec 12 définitions privées.

Le hochement de tête. C'est lui le tueur. Un hochement ressemble à un accord. Ce n'en est pas un. Un hochement de tête, c'est un délai d'attente: ça signifie "je ne veux pas retarder la réunion, et cette phrase est assez proche de mon modèle mental que je ne vais pas m'objecter." C'est radicalement différent d'un véritable alignement.

Ajoutez la pression de temps, la distance (les appels Zoom aplatissent le contexte), un backlog Slack qui attend que les requis se concrétisent, et le comportement par défaut devient: écrivez-le et passez à autre chose. L'enfouissement des hypothèses se produit non pas parce que l'équipe est mauvaise. Il se produit parce que le système est brisé.

Comment une session équipe rouge surface-t-elle ce que personne n'a remis en question?

La méthode la plus fiable pour trouver les hypothèses cachées, c'est de rassembler des perspectives d'experts distincts dans une session de défi structurée. Pas une réunion. Une session. Une réunion porte sur l'alignement. Une session de défi porte sur les tests de résistance. Ce n'est pas la même chose.

Voici le modèle qui fonctionne:

1. On prend un seul requis. On choisit celui qui semble le plus critique ou le plus vague. "L'API doit supporter les mises à jour en temps réel."
2. On assigne des rôles de perspective. Chaque personne incarne une lentille différente:
   • Analyste d'affaires: "Qu'est-ce que l'utilisateur essaie de faire? Comment mesure-t-il le succès?"
   • Chercheur en expérience utilisateur: "Quel modèle mental l'utilisateur apporte-t-il? Où sera-t-il confus?"
   • Architecte de solutions: "Quels systèmes ça touche? Que se passe-t-il si l'un d'eux tombe? Quel est le rayon d'impact?"
   • Analyste en sécurité: "Qui a la permission? Que se passe-t-il si quelqu'un avec moins d'autorité essaie de faire ça? Peut-il le contourner?"
   • Critique de l'équipe rouge: "Quelle est la pire interprétation de ce requis qu'un développeur pourrait faire et rester techniquement correct?"
3. Chaque perspective pose des questions pendant 10 minutes. Pas de réponses encore. On collecte les questions.
4. On groupe les questions par thème. "Ces cinq questions portent toutes sur l'expiration du jeton." "Ces trois portent sur les limites de quota."
5. Pour chaque thème, on choisit une question comme test. Si la réponse à cette question change, le requis change. On l'écrit.
6. On marque les hypothèses comme découvertes. "On suppose que l'expiration du jeton est de 15 minutes. Si cette hypothèse change, l'implémentation change. On veut documenter ça?"

L'approche de l'équipe rouge fonctionne parce qu'elle rend les hypothèses visibles avant qu'elles ne se transforment en bogues. Visible. Nommée. Avec un propriétaire désigné. Elle crée aussi une piste d'audit: quand le développement commence et que quelqu'un demande "pourquoi a-t-on décidé que l'expiration du jeton est de 15 minutes", on a un dossier. Ce dossier empêche trois semaines de refonte.

Quelles sont les cinq questions qui révèlent les hypothèses cachées?

Pas besoin d'une session complète d'équipe rouge pour commencer à trouver des hypothèses. Ces cinq questions, posées sur n'importe quel requis qui compte, suffisent à amorcer le travail.

Question 1: À quoi ressemble le succès pour chaque persona?

Pas pour le système. Pour la personne qui l'utilise. "Le système doit fournir des mises à jour en temps réel" ne dit pas ce que l'analyste d'affaires doit voir, ce que le développeur doit voir, ni ce que l'utilisateur final doit voir. On suppose que différents personas ont des critères de succès différents. On force le requis à énoncer ce que chacun mesure.

Question 2: Quel est le mode d'échec?

Qu'est-ce qui se passe quand ce requis n'est pas respecté? Quand le système est lent? Quand le réseau est en panne? Quand l'utilisateur a des permissions pour seulement une partie de ce qu'il essaie d'accéder? Les bons requis décrivent ce que le système fait quand le chemin heureux échoue. La plupart des requis ignorent ça complètement. C'est là que les hypothèses se cachent.

Question 3: Quel est le cas limite qui est hors portée?

Chaque requis a une frontière. "Les utilisateurs peuvent réinitialiser leur mot de passe" n'aborde pas: et si l'utilisateur a oublié le courriel avec lequel il s'est enregistré? Et si l'adresse courriel a été supprimée par le fournisseur? On définit la portée explicitement. On dit ce qui est dedans, ce qui est en dehors, et pourquoi. "Hors portée par décision" est une entrée de document très différente de "hors portée parce que personne n'y a pensé."

Question 4: Qui a l'autorité pour changer ça plus tard?

Si une hypothèse s'avère erronée pendant le développement, qui décide de la changer? Le chef de produit? L'équipe de sécurité? Le client? Sans réponse à ça, on crée un deuxième problème: l'équipe fait un changement unilatéral qui entre en collision avec l'attente d'une partie prenante, et personne ne le sait avant les tests d'acceptation.

Question 5: À quoi ressemblerait une implémentation conservatrice, et à quoi ressemblerait une agressive?

Conservatrice: le système rejette l'entrée invalide et affiche un message d'erreur. Agressive: le système corrige automatiquement l'entrée et continue. "Le système gère l'entrée invalide" pourrait signifier l'une ou l'autre. On force le requis à choisir une position. Puis on demande pourquoi on l'a choisie. La raison révèle l'hypothèse.

Comment intégrer la découverte d'hypothèses dans votre liste de contrôle?

Faites-le une fois sur un petit projet. Vous ne le ferez plus jamais de la même façon. Mais le modèle tient:

1. Avant de démarrer le développement, on prend les 10 requis les plus critiques.
2. Pour chacun, on demande: "Qu'est-ce qu'on suppose ici qu'on n'a jamais énoncé?"
3. On écrit ces hypothèses explicitement. On les nomme. On les rend testables.
4. On obtient l'accord d'une partie prenante sur chaque hypothèse. Pas un hochement de tête. Un courriel qui dit "Oui, c'est ce que je voulais dire."
5. On donne la liste à l'équipe de développement. On leur dit: "Si vous découvrez qu'on s'est trompés sur une de ces hypothèses, arrêtez et demandez avant de changer de cap."

Ce n'est pas du travail supplémentaire. C'est prévenir la refonte. Quand une équipe passe trois semaines à construire quelque chose et découvre que le requis a été mal compris, c'est catastrophique. Quand une équipe passe quatre heures en découverte et surface une hypothèse, c'est quatre heures bien investies. Le calcul est simple. La discipline, c'est plus difficile.

Qu'est-ce qui change quand les équipes surfacent les hypothèses tôt?

Les équipes qui surfacent les hypothèses tôt rapportent un résultat constant: la refonte diminue, mais le temps de découverte augmente. On passe plus de temps à poser des questions avant que le code commence. On passe moins de temps à corriger des bogues pendant les tests. L'échange est presque toujours favorable. Un projet qui passe trois semaines sur des requis validés prend huit semaines à construire et livrer. Un projet qui saute la découverte et passe deux semaines sur des spécifications remplies d'hypothèses prend 12 semaines à construire, tester, reprendre et livrer. L'investissement en amont comprime le temps total de livraison.

Ce qui compte encore plus: l'équipe livre ce que la partie prenante voulait réellement. Pas ce qu'elle pensait vouloir. Pas ce que les développeurs ont deviné qu'elle voulait. La vraie chose.

C'est ce que 25 ans à regarder des projets échouer m'ont enseigné: les spécifications qui causent le plus de dégâts ne sont pas les vagues. Ce sont celles qui sonnent précises mais qui contiennent 40 hypothèses invisibles. Votre prochain document en a probablement 40 en ce moment. Ouvrez-le et commencez à les compter. C'est la première étape pour construire quelque chose qui n'a pas besoin d'être reconstruit.

Quelles sont les questions les plus fréquentes sur les hypothèses dans les requis?

Nicolas Payette

PDG et fondateur, Specira AI

Nicolas Payette a 25 ans d'expérience dans la livraison de logiciels d'entreprise, menant des transformations numériques dans les services financiers, la logistique et les secteurs technologiques. Il a fondé Specira AI pour résoudre la cause profonde des échecs de projets : des requis flous, incomplets et non testés.