À quoi sert un cahier des charges de logiciel métier ?
Il sert à transformer une intention (« on veut sortir d'Excel ») en une description vérifiable de ce que le logiciel devra faire, pour qui, avec quelles données et avec quelles limites.
Pour un site internet, le document décrit surtout des pages, un design et des contenus ; c'est l'objet de notre modèle de cahier des charges de site web. Pour un logiciel métier, l'essentiel est ailleurs : dans les flux de travail, les statuts d'un dossier, les droits de chacun et les exceptions. Un bon cahier des charges sert à trois choses :
- obtenir des propositions comparables de plusieurs prestataires ;
- servir de référence pendant la construction et lors de la recette (la vérification finale) ;
- trancher un désaccord : ce qui est écrit est dû, ce qui est exclu ne l'est pas.
Les 8 rubriques d'un bon cahier des charges logiciel
Un cahier des charges utile pour un logiciel métier tient en huit rubriques, et chacune répond à une question que le prestataire se posera de toute façon.
| Rubrique | Question à laquelle elle répond | Exemple |
|---|---|---|
| Contexte et objectifs | Pourquoi ce projet maintenant ? | Réduire le délai entre fin d'intervention et facture |
| Processus actuels | Comment ça se passe aujourd'hui, vraiment ? | Bon papier, photo par messagerie, ressaisie le soir |
| Utilisateurs et rôles | Qui fait quoi, depuis quel appareil ? | Technicien sur téléphone, planificatrice au bureau |
| Fonctionnalités attendues | Que doit permettre l'outil, étape par étape ? | Signature client, envoi automatique du rapport |
| Données et reprise | Quelles informations, d'où viennent-elles ? | Fichier clients, historique des chantiers sur 3 ans |
| Intégrations | Avec quels logiciels échanger ? | Logiciel comptable, ERP, paiement en ligne |
| Contraintes | Qu'est-ce qui est non négociable ? | Fonctionnement sans réseau, données de santé |
| Hors périmètre | Qu'est-ce qui n'est pas demandé ? | Pas de module de paie, pas de version anglaise |
Comment décrire les processus et les règles de gestion
Décrivez ce que font les gens, dans l'ordre, avec leurs mots, puis notez chaque règle qui fait changer le dossier d'état.
Une bonne description de processus ressemble à un récit précis : « Le client appelle, l'assistante crée la demande, le responsable affecte un technicien selon la zone et la compétence, le technicien intervient, fait signer le client sur son téléphone, et la facture part si le bon est signé et complet. » De ce récit, on extrait :
- les statuts du dossier : demandée, planifiée, réalisée, signée, facturée ;
- les règles : qui peut passer d'un statut à l'autre, à quelle condition ;
- les exceptions : client absent, pièce manquante, intervention en deux fois, annulation tardive.
Les exceptions sont la partie la plus précieuse. C'est là que les logiciels du marché cèdent et que les projets mal cadrés dérapent.
Données, intégrations et reprise de l'existant
Listez chaque objet manipulé (client, site, contrat, intervention, article), ses champs importants et sa source actuelle, puis chaque logiciel avec lequel l'outil devra échanger.
- Source de vérité : pour chaque donnée, quel outil fait foi ? Les tarifs viennent-ils de l'ERP ou du nouveau logiciel ?
- Sens des échanges : lecture seule, écriture, synchronisation dans les deux sens, fréquence.
- Reprise : volume, qualité, doublons, historique à conserver ou à archiver.
- Données personnelles : quelles catégories, combien de temps, qui y accède. Le guide RGPD et logiciel métier détaille ce qu'il faut prévoir.
Joindre des exemples réels anonymisés (un bon, un export, une facture type) vaut mieux que deux pages de description.
Pourquoi écrire noir sur blanc ce qui est hors périmètre
Parce qu'un périmètre sans limites écrites est un périmètre que chacun interprète à sa façon, et que ces écarts finissent en avenants ou en conflits.
La rubrique « hors périmètre » est courte et décisive : pas d'application iOS dans la première version, pas de reprise des archives antérieures à une date, pas de module comptable, pas de traduction. Elle protège les deux parties. Le client sait ce qu'il n'aura pas, le prestataire sait ce qu'il n'a pas chiffré. Elle prépare aussi la suite : ce qui est exclu aujourd'hui devient la liste des évolutions de demain.
Les erreurs courantes
- Imposer une solution technique au lieu de décrire le besoin (« en React avec telle base ») sans raison métier.
- Copier un logiciel concurrent écran par écran, avec ses défauts.
- Décrire le processus idéal plutôt que le processus réel, exceptions comprises.
- Oublier les utilisateurs du terrain dans la rédaction : l'outil sera pensé pour le bureau.
- Tout mettre au même niveau de priorité : sans distinction entre indispensable et souhaitable, impossible de construire une première version utile, comme expliqué dans le guide sur le MVP.
- Rédiger 80 pages que personne ne relit, au lieu d'un document précis et tenu à jour.
Cahier des charges et cadrage : quelle différence ?
Le cahier des charges est écrit par le client à partir de ce qu'il sait ; le cadrage est mené avec le prestataire pour vérifier, compléter et chiffrer.
Même excellent, un cahier des charges laisse des angles morts : des exceptions que personne ne pense à mentionner, des contraintes techniques des logiciels existants, des volumes de données réels. Le cadrage consiste à aller voir le terrain, interroger les utilisateurs, cartographier les processus et produire un périmètre fonctionnel détaillé. Un prix au forfait sérieux ne peut venir qu'après. Le comparatif forfait ou régie explique pourquoi.
Check-list avant d'envoyer votre cahier des charges
- Les objectifs sont mesurables (délai, nombre de ressaisies, erreurs évitées).
- Chaque processus est décrit tel qu'il se passe, avec ses exceptions.
- Les rôles, droits et appareils utilisés sont listés.
- Les données, leur volume et leur source sont identifiés, avec des exemples joints.
- Les logiciels à connecter sont nommés.
- Les priorités distinguent l'indispensable du souhaitable.
- Le hors périmètre est écrit.
- La propriété du code et la réversibilité sont demandées explicitement.
Ce que fait YMHB Web
YMHB Web accepte les cahiers des charges complets comme les simples descriptions de problème. Dans les deux cas, la première étape est un cadrage : entretiens avec vos équipes, observation du terrain, cartographie des processus réels, puis un périmètre fonctionnel détaillé où ce qui est exclu est écrit aussi clairement que ce qui est inclus. Le chiffrage vient après, jamais avant. La méthode complète est publiée.
Questions fréquentes
- Qui doit rédiger le cahier des charges d'un logiciel métier ?
- Le cahier des charges d'un logiciel métier est rédigé par l'entreprise qui exprime le besoin, idéalement par la personne qui connaît le mieux le processus, avec la contribution des futurs utilisateurs. Le prestataire ne devrait pas l'écrire seul, car il ne connaît pas encore le métier. Il le complète ensuite pendant le cadrage, en vérifiant les exceptions, les données réelles et les contraintes des logiciels existants.
- Quelle longueur pour un cahier des charges de logiciel métier ?
- Un cahier des charges de logiciel métier n'a pas de longueur idéale : il doit être assez précis pour que deux prestataires comprennent la même chose. Un document court avec des processus bien décrits, des exceptions listées et des exemples réels joints vaut mieux qu'un long document générique. La rubrique hors périmètre, même brève, est indispensable.
- Faut-il un cahier des charges pour demander un devis de logiciel sur mesure ?
- Un cahier des charges n'est pas obligatoire pour demander un devis de logiciel sur mesure, mais il accélère et fiabilise le chiffrage. Sans document, une description du problème, des utilisateurs concernés et des outils actuels suffit pour un premier échange. Dans tous les cas, un prix sérieux suppose un cadrage préalable où le prestataire comprend le métier et ses cas particuliers.
- Quelle différence entre cahier des charges fonctionnel et technique ?
- Le cahier des charges fonctionnel décrit ce que le logiciel doit faire du point de vue des utilisateurs : processus, règles, écrans attendus, documents produits. Le cahier des charges technique décrit comment le faire : architecture, technologies, hébergement, sécurité. Pour une PME, le premier relève du client et le second se construit avec le prestataire, sauf contrainte technique imposée par l'existant.
- Le cahier des charges a-t-il une valeur contractuelle ?
- Le cahier des charges a une valeur contractuelle claire lorsqu'il est annexé au contrat de développement ou expressément visé par lui ; à défaut, sa portée peut être discutée en cas de litige. Il sert alors de référence pour la recette et en cas de désaccord sur ce qui était dû. Il est préférable que le contrat vise la version finale issue du cadrage, qui intègre les précisions et le hors périmètre validés par les deux parties.