Le cahier des charges qui empêche de comprendre le besoin
Un document de quarante pages listant des fonctionnalités décrit une solution déjà choisie. Il masque le problème qu'il fallait résoudre.
Le document fait quarante pages. Il liste deux cent douze fonctionnalités, numérotées, avec des niveaux de priorité. Il a demandé trois mois de travail interne.
Il ne dit nulle part ce qui ne va pas aujourd’hui.
Une solution déguisée en besoin
« Le site devra comporter un moteur de recherche à facettes avec filtres multicritères » est une solution. Le besoin sous-jacent — « les clients n’arrivent pas à retrouver un produit dont ils ont oublié la référence » — permettrait d’en envisager cinq autres, dont certaines coûtent dix fois moins.
En écrivant la solution, l’auteur du document ferme la discussion avant qu’elle commence. Le prestataire chiffre ce qui est demandé, livre ce qui est demandé, et le problème reste entier.
Ce qu’un bon document contient
Le problème, avec sa mesure. « 40 % des appels au standard concernent le suivi de commande » est exploitable. « Améliorer la relation client » ne l’est pas.
Le contexte d’usage. Qui, où, sur quel matériel, à quelle fréquence, en combien de temps. Une saisie faite debout sur un chantier avec des gants n’appelle pas la même interface qu’une saisie au bureau.
Les contraintes réelles. Les systèmes avec lesquels il faut dialoguer, les obligations réglementaires, les échéances qui ne bougeront pas. Ce sont elles qui excluent des solutions.
Le critère de réussite. Quel signe montrera, dans six mois, que le projet a servi ? Si personne ne sait répondre, la question mérite d’être tranchée avant de dépenser.
Les fonctionnalités viennent après
Elles sont le résultat de la conception, pas son point de départ. Les figer avant d’avoir examiné le problème revient à commander des matériaux avant d’avoir dessiné le bâtiment.
Un document de quatre pages bien écrit produit de meilleures propositions qu’un document de quarante pages qui décrit une solution. Il permet aussi de comparer les prestataires sur leur compréhension, et non sur leur capacité à recopier une liste.
Le piège de la liste exhaustive
Une liste de deux cents fonctionnalités contient toujours un cinquième d’éléments que personne n’utilisera. Ils sont chiffrés, développés, testés et maintenus.
Le repérage est simple : pour chaque ligne, demander qui s’en servira, à quelle fréquence, et ce qui se passe si elle n’existe pas. Les réponses évasives désignent les lignes à supprimer.
Ce qui ne se met pas dans un document
La conviction que le besoin exprimé est le vrai. Un cahier des charges décrit ce que l’organisation croit savoir d’elle-même à un instant donné. Une demi-journée d’observation sur le terrain le corrige plus efficacement que trois réunions de cadrage.