Un cahier des charges utile décrit les situations que le logiciel doit prendre en charge et les limites du projet. Il n’a pas besoin de prévoir chaque pixel. Son rôle est de rendre les attentes vérifiables, de révéler les inconnues et de permettre à l’équipe de comparer les solutions proposées.
1. Décrire le problème avec un dossier concret
Commencez par une situation récente : une demande reçue, les personnes impliquées, les fichiers échangés et le moment où le suivi devient difficile. Ajoutez ce que cette difficulté provoque : double saisie, attente, manque de visibilité ou impossibilité de retrouver une décision.
Une phrase comme « nous voulons centraliser les informations » est trop large. Préférez : « lorsqu’un dossier change de statut, le responsable doit retrouver la décision, la pièce jointe et la prochaine action sans demander à trois collègues ». Cet exemple permet de discuter d’un parcours précis et de vérifier le résultat après livraison.
2. Identifier les utilisateurs et leurs responsabilités
Listez les rôles, pas seulement les services de l’entreprise. Un responsable peut consulter tous les dossiers sans avoir le droit de modifier une facture. Un partenaire peut déposer une pièce sur ses propres dossiers sans voir ceux d’une autre organisation.
Pour chaque rôle, indiquez ce qu’il peut consulter, créer, modifier, valider et exporter. Distinguez les droits nécessaires au quotidien des droits exceptionnels d’administration. Cette matrice est particulièrement importante pour un portail client ou un extranet B2B.
3. Rédiger les parcours prioritaires
Utilisez une fiche reproductible :
- Utilisateur : la personne qui commence le parcours.
- Déclencheur : ce qui lui donne besoin d’agir.
- Données requises : les informations indispensables.
- Étapes : les actions et validations attendues.
- Résultat : l’état observable à la fin du parcours.
- Exceptions : pièce absente, saisie incorrecte, refus ou interruption.
- Critère de recette : le test qui permet d’accepter le résultat.
Exemple illustratif : un chargé de dossier demande une validation. Le responsable voit la version du document et le motif de la demande, puis accepte ou refuse en laissant un commentaire. Le chargé de dossier retrouve la décision et sa date. Le test de recette vérifie qu’une décision ne peut pas être attribuée à un utilisateur qui n’a pas ce droit.
4. Inventorier les données et les connexions
Décrivez les objets manipulés : clients, contacts, dossiers, interventions, commandes ou documents. Indiquez où se trouve aujourd’hui l’information de référence, qui la met à jour et ce qu’il faut conserver dans l’historique. Joignez quelques exemples anonymisés pour rendre les formats compréhensibles.
Pour chaque connexion, précisez la direction de l’échange, sa fréquence et ce qui doit arriver en cas d’échec. Une synchronisation bidirectionnelle exige notamment une règle lorsqu’une même information est modifiée dans deux outils. L’intégration API doit être cadrée comme un parcours métier à part entière.
5. Définir ce qui est indispensable au lancement
Classez les besoins en trois groupes : nécessaire pour terminer le parcours principal, utile mais reportable, et hypothèse à tester. Expliquez pourquoi une fonction appartient au premier groupe. Une liste où tout est « obligatoire » ne permet pas d’arbitrer le budget ou le calendrier.
Précisez aussi les exigences d’usage : navigateurs et appareils réellement utilisés, volumes attendus, besoins d’accessibilité, recherche, exports et indisponibilité acceptable. Il est préférable d’écrire une hypothèse de volume à vérifier plutôt que d’exiger une capacité illimitée sans contexte.
6. Organiser la recette et la transmission
Désignez les personnes qui testeront chaque parcours et les jeux de données nécessaires. Une validation doit porter sur les erreurs, les droits et les exceptions autant que sur le parcours réussi. Préparez les conditions de mise en service et la conduite à tenir si la migration présente un écart.
Listez enfin les éléments à transmettre : accès, documentation, procédure de déploiement, sauvegardes, exports et modalités de maintenance. Les responsabilités après lancement doivent être comprises avant la livraison, même si le contrat de suivi est distinct.
La trame à reprendre pour votre projet
- Contexte et difficulté observée.
- Objectif et indicateurs de départ.
- Rôles et droits d’accès.
- Trois parcours prioritaires avec leurs exceptions.
- Données, historique et reprise de l’existant.
- Connexions aux autres applications.
- Périmètre initial et besoins reportés.
- Conditions d’usage et d’exploitation.
- Critères de recette, responsables et livrables.
- Questions ouvertes et décisions à prendre.
Cette trame sert de support de travail. Elle peut rester courte au départ, puis être complétée lors du cadrage d’un logiciel sur mesure. Le bon document n’est pas celui qui paraît exhaustif : c’est celui qui permet aux personnes concernées de prendre les mêmes décisions sur le projet.