Le document n’a pas besoin d’être long. Il doit réduire les ambiguïtés qui changent le coût, l’architecture ou la responsabilité du produit.
Commencer par le problème et le résultat
Expliquez le processus actuel, ses limites et le changement attendu. Ajoutez les indicateurs qui permettraient de constater une amélioration : délai, erreurs, conversion, satisfaction, capacité ou visibilité.
Une phrase telle que « centraliser toutes les demandes et réduire la double saisie » oriente mieux le projet qu’une liste de boutons.
Décrire les utilisateurs et leurs droits
- profils et responsabilités ;
- actions autorisées ;
- données visibles ou modifiables ;
- appareils et contexte d’usage ;
- exceptions et besoin d’assistance.
Les permissions sont une composante de l’architecture, pas un détail à ajouter après les écrans.
Cartographier les parcours et les états
Pour chaque objet important, indiquez les états possibles et qui peut provoquer une transition. Une demande peut être brouillon, soumise, validée, refusée ou archivée. Chaque état peut déclencher notifications, délais ou actions.
Un workflow clair révèle souvent davantage de complexité qu’une maquette complète.
Lister les données, intégrations et migrations
Identifiez la source de vérité, les fichiers existants, la qualité des données, les imports et exports. Pour chaque intégration, précisez l’objectif et non seulement le nom de l’outil.
Ajoutez les exigences de conservation, suppression, sauvegarde et journalisation adaptées au projet.
Écrire des critères d’acceptation vérifiables
Un bon critère décrit une situation, une action et un résultat observable. Par exemple : « un responsable peut refuser une demande avec un motif obligatoire ; l’auteur reçoit une notification et voit le motif dans son espace ».
Questions fréquentes
Qui doit rédiger le cahier des charges ?
Le métier apporte les objectifs et règles ; l’agence aide à les transformer en parcours, données et décisions techniques.
Faut-il inclure des maquettes ?
Elles sont utiles pour clarifier les parcours, mais ne remplacent pas les règles, états et permissions.
Doit-on choisir la technologie dans le document ?
Seulement si une contrainte réelle l’impose. Sinon, décrivez les besoins et critères.
Comment gérer les changements après validation ?
Avec une procédure qui évalue l’impact sur le périmètre, le calendrier, le budget et les risques.