Un cahier des charges utile permet de comprendre le processus, de discuter les choix et de vérifier le résultat. Il n’a pas besoin de figer chaque écran. Il doit expliquer qui travaille, quelles règles doivent tenir et comment l’application sera utilisée après le lancement. Le modèle proposé ci-dessous sert à préparer ce cadrage avec vos équipes.
Les repères pour décider.
- Décrire un parcours complet et ses exceptions.
- Identifier les sources de données et les responsables de validation.
- Rendre les critères de recette observables dès le cadrage.
Fichier Markdown modifiable dans un éditeur de texte, sans inscription. À compléter avec votre équipe.
Télécharger le modèle gratuit1. Poser le problème et le résultat attendu.
Commencez par expliquer le fonctionnement actuel et la friction que vous souhaitez résoudre. « Développer un outil moderne » donne peu de repères. « Retrouver l’état d’un dossier sans consulter trois fichiers » décrit un changement concret que les utilisateurs pourront vérifier.
Associez au problème une situation de départ : personnes impliquées, fréquence des opérations, temps d’attente et erreurs observées. Ces éléments n’ont pas besoin d’être parfaits ; précisez leur source et la période d’observation. Définissez aussi ce que le projet ne cherche pas à changer. Vous éviterez d’absorber progressivement tous les besoins de l’entreprise.
- Le problème rencontré aujourd’hui et ses conséquences.
- Le premier parcours que l’application doit rendre possible.
- Les indicateurs observés avant le projet.
- Les sujets exclus de la première version.
2. Décrire les personnes, les rôles et les décisions.
Listez les profils qui utiliseront l’application, ceux qui administreront les accès et ceux qui recevront les résultats. Un même collaborateur peut cumuler plusieurs rôles. Décrivez qui consulte, crée, corrige, valide, exporte ou supprime une information, ainsi que les éventuelles restrictions par équipe ou périmètre.
Identifiez les personnes capables de trancher une règle et de valider une version. Si personne ne peut décider ce qu’il faut faire lorsqu’un dossier est modifié après validation, le développement devra attendre cette décision. L’organisation du projet fait donc partie du cahier des charges, au même titre que les fonctions.
3. Écrire les parcours avec leurs exceptions.
Pour chaque parcours, notez le déclencheur, les entrées, les étapes, la sortie et les cas particuliers. Utilisez le vocabulaire des équipes. Un schéma simple peut compléter le texte ; il doit rester compréhensible par une personne qui n’a pas participé aux ateliers.
Exemple illustratif : une coordinatrice crée une demande d’intervention, affecte un technicien et suit la clôture. Si une pièce manque, la demande reste en attente ; si le technicien est indisponible, l’affectation est reprise ; si l’intervention est annulée, l’historique est conservé. Ces exceptions définissent davantage le produit que le seul écran de création.
Faites défiler le tableau horizontalement pour lire toutes les colonnes.
| Champ | Contenu attendu |
|---|---|
| Déclencheur | Événement qui lance l’opération. |
| Acteurs | Profils impliqués et droits nécessaires. |
| Entrées | Données disponibles et informations obligatoires. |
| Règles | Conditions, validations et décisions à appliquer. |
| Exceptions | Données manquantes, doublons, interruptions, corrections. |
| Sortie | Résultat attendu et personne qui le vérifie. |
4. Inventorier les données et les logiciels à connecter.
Listez les fichiers, bases, outils et documents qui alimentent le processus. Pour chaque source, précisez le propriétaire, les identifiants, les formats et les volumes connus. Indiquez la source qui fait référence lorsqu’une même information est présente à plusieurs endroits.
Une intégration doit préciser le sens de l’échange, le déclencheur, la fréquence et le comportement en cas d’échec. Demandez si un environnement de test et une documentation API sont disponibles. Si l’accès n’a pas encore été vérifié, marquez-le comme une dépendance à lever plutôt que comme une fonction acquise.
5. Préparer des critères de recette observables.
Remplacez les formulations comme « interface intuitive » par des scénarios à réaliser. Décrivez les données de départ, l’action et le résultat attendu. Ces critères peuvent être affinés au fil des ateliers, mais ils doivent exister avant la réception finale.
Exemple illustratif : avec un compte de technicien, seules les interventions affectées à ce compte sont visibles. Une tentative d’accès direct à une autre intervention est refusée. Après une modification autorisée, l’historique permet de retrouver l’auteur et les champs modifiés. On peut vérifier ce comportement dans l’interface et au niveau de l’application.
- Un scénario normal par parcours prioritaire.
- Un scénario avec donnée manquante ou incorrecte.
- Un scénario de droits d’accès avec un autre profil.
- Une interruption et une reprise lorsque le parcours le nécessite.
- Une procédure de migration ou de restauration lorsque celle-ci fait partie du périmètre.
6. Anticiper la vie de l’application après livraison.
Précisez les horaires d’usage, les contraintes de disponibilité, les responsabilités de support et les données à sauvegarder. Décrivez qui sera alerté en cas d’erreur et qui pourra remettre le service en fonctionnement. Les besoins de sécurité et de protection des données doivent être examinés selon les informations réellement traitées.
Préparez la remise des accès, la documentation, la formation et les conditions de transfert à une autre équipe. Discutez les livrables et les droits sur le code dans le cadre contractuel du projet. Un lancement réussi inclut les personnes qui utiliseront et exploiteront l’outil, pas seulement celles qui l’ont commandé.
7. Indiquer les contraintes et garder une liste d’inconnues.
Donnez les contraintes de calendrier, de disponibilité des équipes et de budget lorsqu’elles sont connues. Expliquez la raison d’une date importante : fin d’un contrat, nouvelle activité ou période de migration possible. Une contrainte justifiée aide à proposer un découpage adapté.
Le document doit aussi exposer ce qui reste à vérifier : accès à un logiciel, qualité d’un fichier, règle métier non décidée. Une liste d’inconnues est utile pour organiser le cadrage et comparer les hypothèses d’un devis. Le modèle téléchargeable fournit cette structure ; apportez-le même incomplet à une première discussion.