Un cahier des charges d’application métier décrit d’abord le problème, le travail tel qu’il se fait aujourd’hui, les utilisateurs, les règles métier et le résultat attendu. Il n’impose ni langage ni architecture : il donne au prestataire assez de matière pour comprendre, proposer un périmètre et chiffrer sans deviner.
Un document trop vague crée des malentendus entre l’entreprise et le développeur. Un document trop technique fige une solution avant que le besoin réel ait été vérifié. Les dix points ci-dessous visent l’entre-deux.
1. Commencez par le problème
« Nous voulons une application moderne avec intelligence artificielle » ne dit rien du besoin. « Trois personnes vérifient chaque semaine 400 documents et reportent à la main six informations dans un tableau » décrit une situation que le développeur peut analyser, mesurer et résoudre de plusieurs façons.
2. Décrivez le fonctionnement actuel
Racontez le processus comme si vous formiez un nouveau salarié :
- ce qui déclenche le travail ;
- les informations saisies ou consultées ;
- les vérifications effectuées ;
- ce qui sort à la fin ;
- les outils utilisés à chaque étape.
Joignez des exemples réels. Un vrai fichier, même imparfait, en apprend souvent plus qu’une page de description.
3. Expliquez ce qui ne fonctionne pas
« Excel est pénible » ne permet pas de chiffrer. « Nous copions trois fois la même donnée », « deux collaborateurs peuvent modifier le même dossier sans savoir ce que l’autre a changé » ou « nous ne retrouvons pas rapidement les dossiers incomplets » décrivent des problèmes que l’on pourra vérifier après la livraison.
4. Listez les utilisateurs
Dirigeant, salarié, manager, client, partenaire : chaque profil n’a probablement pas besoin des mêmes écrans ni des mêmes informations. La CNIL recommande d’ailleurs de définir les profils d’accès et les habilitations dès la conception d’une application. Notez pour chaque rôle ce qu’il consulte, ce qu’il modifie et ce qu’il valide.
5. Décrivez les règles métier
C’est souvent la partie la plus importante, parce que le développeur ne connaît pas votre métier comme vous. Écrivez surtout les règles qui vous paraissent évidentes, en particulier celles qui commencent par « toujours », « jamais », « sauf », « uniquement si » ou « dans ce cas ». Les exceptions contiennent une grande part du savoir-faire réel.
6. Donnez les cas particuliers
Supposons que le fonctionnement standard couvre la grande majorité des dossiers. Décrivez ce qui se passe pour les autres : pièce manquante, client hors catégorie, double validation. Un outil métier qui ne marche que lorsque tout va bien sera contourné dès la première semaine.
7. Distinguez indispensable et souhaitable
Classez chaque demande dans l’une de trois colonnes :
- Version 1 indispensable : ce sans quoi l’outil ne résout pas le problème de départ ;
- Évolutions possibles : ce qui apportera du confort plus tard ;
- Hors périmètre : ce qui ne sera pas fait, écrit noir sur blanc.
Cette séparation protège le budget et le délai. Pour éviter une première version trop grande, choisissez un parcours prioritaire et reportez les fonctions qui n’y contribuent pas directement.
8. Précisez les logiciels existants
CRM, facturation, stockage documentaire, messagerie : indiquez ce qui doit rester et les informations qui doivent circuler entre ces outils et la future application. Il ne sert à rien de reconstruire ce qui fonctionne déjà.
9. Décrivez le résultat attendu
À quoi reconnaîtrez-vous que le projet est réussi ? Par exemple :
- un collaborateur traite seul un dossier ;
- un contrôle est effectué à chaque fois ;
- une donnée n’est saisie qu’une fois ;
- un client accède directement à son résultat.
Ces critères valent bien mieux qu’un vague « application intuitive ».
10. Ce que vous n’avez pas besoin d’écrire
Le langage informatique, la base de données, l’architecture et le fournisseur technique ne sont pas à décider dans le cahier des charges. Chez ClosiQode, je vous demande de décrire le besoin métier, puis je choisis la solution technique adaptée, plutôt que de faire entrer le projet dans un catalogue prédéfini.
Vous avez seulement quelques notes ?
Ce n’est pas un problème. Un cadrage sert justement à transformer votre réalité métier en périmètre exploitable.
Trame d’un cahier des charges d’application métier
- Contexte : activité, équipe concernée et raison du projet.
- Situation actuelle : étapes, outils, données entrantes et résultat produit.
- Problèmes observés : exemples, fréquence et conséquences.
- Utilisateurs : rôles, droits et environnement de travail.
- Règles métier : validations, calculs, exceptions et obligations.
- Périmètre de la première version : indispensable, souhaitable et hors périmètre.
- Intégrations : logiciels à conserver et échanges attendus.
- Critères d’acceptation : scénarios concrets permettant de vérifier la livraison.
Ajoutez des pièces réelles : modèle de document, capture d’écran, tableau ou exemple de dossier. Anonymisez-les si nécessaire en remplaçant noms, coordonnées et identifiants, mais conservez la structure, les formats et les cas particuliers : ce sont eux qui lèvent les ambiguïtés.
Transformer une attente vague en critère d’acceptation
Un critère d’acceptation décrit une situation vérifiable, sans imposer la solution technique. Il permet au métier et au développeur de parler du même résultat.
| Formulation vague | Formulation vérifiable |
|---|---|
| « L’application doit être intuitive. » | « Un responsable peut identifier un dossier incomplet, la pièce manquante et la personne à relancer depuis le même écran. » |
| « Il faut sécuriser les données. » | « Un client connecté ne peut consulter que ses propres dossiers ; chaque tentative d’accès refusée est journalisée. » |
| « Le contrôle doit être automatique. » | « Pour les cinq cas d’essai fournis, le système signale les trois anomalies attendues et indique la règle appliquée. » |
| « Nous devons rester autonomes. » | « Le code livré, les accès d’hébergement au nom de l’entreprise, l’export des données et une procédure de reprise figurent dans la liste des livrables. » |
Pour chaque parcours prioritaire, notez le contexte, l’action de l’utilisateur et le résultat observable. Le critère le plus parlant que j’aie reçu venait d’un bureau d’études : pour tester l’outil de contrôle documentaire, le client m’a envoyé trois fiches dont une contenait une anomalie volontaire, sans me dire laquelle, et l’outil l’a trouvée (le cas est raconté dans l’article sur l’application métier).
Comment vérifier que le cahier des charges est exploitable ?
Demandez à une personne qui ne connaît pas le processus de le reformuler. Si elle ne retrouve pas le déclencheur, le responsable, les exceptions et le résultat final, le document doit encore être précisé. Avant de l’envoyer pour un devis, passez aussi cette liste :
- le problème et ses conséquences sont illustrés par des cas réels ;
- les futurs utilisateurs et leurs droits sont identifiés ;
- les règles habituelles et les principales exceptions sont décrites ;
- la version 1 a un objectif mesurable et un périmètre limité ;
- les logiciels à conserver et les données à échanger sont listés ;
- les critères de recette sont compréhensibles par le métier ;
- la propriété, les accès, la maintenance et la réversibilité seront écrits au contrat (voir à qui appartient le code d’un logiciel sur mesure).
Si plusieurs points restent inconnus, ce n’est pas un motif d’arrêt : prévoyez une phase de cadrage avant le développement. Un bon cahier des charges n’élimine pas les échanges, il les rend productifs.
Questions fréquentes
Quelle longueur faut-il prévoir ?
La longueur dépend du processus. Un document court accompagné d’exemples précis vaut mieux qu’un dossier volumineux rempli de formulations générales.
Le cahier des charges doit-il être définitif avant le premier échange ?
Non. Il sert de base au cadrage. Les ateliers peuvent révéler des dépendances ou des cas particuliers, qui doivent ensuite être arbitrés et consignés.
Faut-il choisir la technologie avant de consulter un développeur ?
Non. Un outil populaire ne correspond pas forcément à votre projet. Décrivez le besoin et laissez le prestataire justifier ses choix techniques au regard de vos règles, de vos volumes et de vos logiciels existants.