Décrire un problème, pas une solution
Le réflexe le plus courant est d'écrire « je veux une application mobile avec un tableau de bord ». C'est déjà une solution, et elle ferme la porte à toutes les autres — dont certaines coûtent dix fois moins cher.
Écrivez plutôt ce qui ne va pas aujourd'hui : qui perd du temps, sur quoi, combien de fois par semaine, et ce que cela produit à la fin du mois. Un prestataire qui lit cela peut proposer autre chose que ce que vous aviez en tête. C'est précisément ce que vous achetez.
Gardez la formulation en solution pour la fin du document, sous un titre honnête : « ce que nous imaginions ». Elle a sa place — elle dit vos contraintes implicites — mais elle ne doit pas ouvrir le texte.
Ce qui doit être tranché avant de consulter
Ces points-là ne sont pas des détails d'exécution : ils changent l'architecture, donc le prix. Les laisser ouverts garantit un devis qui ne veut rien dire, puis une renégociation.
- Qui utilisera l'outil, et depuis quel matériel ? Un usage sur téléphone en extérieur n'a rien à voir avec un usage au bureau.
- Combien de personnes en même temps, aux heures de pointe ?
- Quelles données entrent, d'où viennent-elles, et existe-t-il déjà un fichier ou un logiciel qui les contient ?
- Qui a le droit de voir quoi ? Les niveaux d'accès sont l'une des sources principales de complexité.
- Y a-t-il une échéance imposée de l'extérieur — une obligation légale, une saison commerciale, un événement ?
- Que se passe-t-il si l'outil est indisponible une demi-journée ? La réponse fixe le niveau d'exigence, et son coût.
Ce qu'il vaut mieux laisser ouvert
Les technologies, sauf contrainte réelle. Imposer un langage parce qu'on en a entendu parler écarte des prestataires compétents et n'améliore rien. En revanche, si votre équipe informatique devra reprendre le code, dites-le : c'est une contrainte réelle, et elle se justifie en une phrase.
Le détail des écrans. Un cahier des charges qui décrit chaque bouton fige des choix avant que quiconque ait vu un utilisateur s'en servir. Décrivez ce que la personne doit pouvoir accomplir, pas où cliquer.
Le nombre de jours. C'est au prestataire de l'estimer ; l'imposer revient à choisir la réponse avant d'avoir posé la question.
La section que presque personne n'écrit
Ce qui est hors périmètre. Un cahier des charges dit ce qu'il faut faire ; il dit rarement ce qu'il ne faut pas faire, et c'est de là que viennent la plupart des désaccords de fin de projet.
Écrivez noir sur blanc ce que vous n'attendez pas : la reprise de l'historique, la formation des équipes, l'hébergement, la maintenance après livraison, la rédaction des contenus. Chacune de ces lignes coûte de l'argent. Les nommer, même pour les exclure, évite qu'elles apparaissent en cours de route comme des évidences — pour vous seulement.
Longueur
Quelques pages suffisent pour la plupart des projets. Un document de cinquante pages n'est pas plus précis : il est simplement plus long à lire, et personne ne le relira au moment où une question se posera.
Le bon critère n'est pas le volume mais celui-ci : un prestataire qui ne vous connaît pas peut-il, après lecture, poser trois questions pertinentes ? Si ses questions portent sur des choses que vous croyiez avoir écrites, le document n'est pas trop court, il est mal ordonné.