Cahier des charges d'un outil métier : guide simple + modèle
Un cahier des charges de logiciel n'a pas besoin de 40 pages. Pour une PME, un document de 4 à 6 pages suffit s'il contient le bon contenu : votre contexte, les personnes qui utiliseront l'outil, vos processus décrits en scénarios « aujourd'hui / demain », les données à reprendre, les intégrations, vos contraintes, votre budget et vos critères de succès. Cet article détaille cette structure section par section, avec un exemple rédigé pour chacune, puis résume le modèle complet dans un tableau.
Faut-il vraiment un document de 40 pages ?
Non. Les cahiers des charges de 40 pages sont un héritage des grands projets informatiques. Pour un outil métier de PME, ce format joue contre vous : personne ne le lit en entier, il fige des détails que vous découvrirez faux en cours de route, et il vous coûte des semaines de rédaction.
Le rôle réel du document est plus modeste et plus utile : donner à un prestataire de quoi comprendre votre métier, poser les bonnes questions et chiffrer honnêtement. Pour cela, 4 à 6 pages bien construites suffisent. Comptez une à deux demi-journées de rédaction, pas plus.
Pour illustrer chaque section, nous suivrons un exemple volontairement fictif : Chauffage Dubois, une entreprise d'installation et d'entretien de chaudières de 14 personnes, qui gère aujourd'hui ses interventions avec trois fichiers Excel et une boîte mail partagée.
Que mettre dans un cahier des charges de logiciel ? Le modèle section par section
Voici les huit sections qui composent un bon cahier des charges d'application métier. Pour chacune : les questions à se poser, puis un exemple rédigé tel qu'il pourrait figurer dans le document.
1. Le contexte et le problème
Qui êtes-vous, que faites-vous, qu'est-ce qui coince aujourd'hui et pourquoi agir maintenant ? Une demi-page suffit. L'essentiel est de chiffrer le problème : du temps perdu, des erreurs, un risque.
Chauffage Dubois installe et entretient des chaudières en région bruxelloise. L'équipe compte 14 personnes, dont 9 techniciens sur la route. La planification des interventions se fait dans un fichier Excel partagé, les demandes arrivent par téléphone et par mail. Chaque semaine, 2 à 3 rendez-vous sont perdus ou encodés en double. La personne qui tient le planning part à la retraite dans 8 mois et elle est la seule à maîtriser le système.
2. Qui utilisera l'outil, et pour quoi faire ?
Listez chaque type d'utilisateur, son quotidien et ce qu'il doit pouvoir faire dans l'outil. Précisez le contexte d'usage : au bureau, sur chantier, sur téléphone. Un outil pensé pour un écran de bureau et utilisé dans une camionnette est un outil raté.
Trois profils. L'assistante de direction (1 personne) : crée les interventions, gère le planning, répond aux clients. Les techniciens (9 personnes) : consultent leur tournée du jour sur leur téléphone, notent ce qui a été fait et les pièces utilisées. Le gérant (1 personne) : voit la charge de la semaine et les interventions non facturées.
3. Les processus à couvrir, décrits en « aujourd'hui / demain »
C'est la section la plus importante du document. Choisissez 3 à 5 processus clés et décrivez chacun en deux temps : comment cela se passe aujourd'hui, concrètement, puis comment vous aimeriez que cela se passe demain. Ce format oblige à décrire des faits plutôt que des fonctionnalités imaginées, et il montre au prestataire où se cache la vraie complexité. Dans le projet mené pour l'Entrela', le centre culturel d'Evere, c'est la description précise du double encodage entre la base interne et la billetterie qui a orienté toute la solution (étude de cas de la plateforme de l'Entrela').
Prise de rendez-vous, aujourd'hui : le client appelle, l'assistante note sur un post-it, vérifie le fichier Excel, rappelle le client pour confirmer, puis encode le rendez-vous dans Excel et dans l'agenda du technicien. Quatre manipulations, deux oublis par mois. Demain : la demande est encodée une seule fois, le créneau se choisit dans un calendrier qui connaît les disponibilités des techniciens, le client reçoit une confirmation automatique par mail.
4. Les données à reprendre
Où vivent vos données aujourd'hui, en quel volume et dans quel état ? Fichiers Excel, ancien logiciel, carnets papier : dites tout, y compris ce qui vous gêne. La reprise de données est le poste le plus sous-estimé des projets sur mesure, et un prestataire ne peut le chiffrer que si vous décrivez la réalité.
Environ 1 800 fiches clients dans un fichier Excel, avec des doublons (le même client existe parfois sous deux orthographes). Historique des interventions depuis 2019 dans un second fichier, sans lien fiable avec les fiches clients. Les contrats d'entretien sont des PDF dans un dossier partagé.
5. Les intégrations avec vos outils existants
Avec quels logiciels le futur outil doit-il échanger des données ? Comptabilité, agendas, boîte mail, terminal de paiement. Distinguez ce qui doit être connecté automatiquement de ce qui peut rester un export manuel mensuel : la différence de coût est réelle.
L'outil doit générer les factures ou, au minimum, exporter les données de facturation vers notre logiciel comptable (Yuki). Les rendez-vous doivent apparaître dans les agendas Google des techniciens. Pas d'autre intégration indispensable au lancement.
6. Les contraintes
Tout ce qui limite les choix : matériel existant, connexion mobile des équipes, exigences légales (RGPD pour les données clients, conservation des documents), personnes peu à l'aise avec l'informatique, périodes où il est impensable de changer d'outil.
Les techniciens travaillent parfois en cave, sans réseau : la tournée du jour doit rester consultable hors connexion. Deux techniciens sont réfractaires aux outils numériques : l'écran mobile doit tenir en trois actions maximum. Aucun changement d'outil entre novembre et février, notre pleine saison.
7. Le budget et l'échéance, assumés
Annoncez une fourchette de budget et une échéance, même approximatives. Beaucoup de dirigeants cachent leur budget par peur de « donner le prix ». C'est une erreur : sans fourchette, le prestataire ne peut pas proposer un découpage adapté, et vous recevrez des devis inutilisables. Pour calibrer votre fourchette, appuyez-vous sur les prix d'un logiciel sur mesure en Belgique ; pour l'échéance, sur les délais réalistes d'un développement sur mesure.
Budget envisagé : entre 15 000 et 25 000 € pour une première version utile. Échéance souhaitée : outil en service pour septembre, avant la pleine saison. Le remplacement du planning Excel est prioritaire ; la facturation peut attendre une deuxième phase.
8. Les critères de succès mesurables
Comment saurez-vous, six mois après le lancement, que le projet est une réussite ? Trois à cinq critères chiffrés suffisent. Ils serviront de boussole à chaque arbitrage pendant le projet.
Zéro rendez-vous perdu ou doublé après trois mois d'utilisation. Encodage d'une intervention en moins de 2 minutes, contre 10 aujourd'hui. Le planning peut être tenu par deux personnes différentes, sans dépendre d'une seule. 9 techniciens sur 9 consultent leur tournée dans l'outil, sans impression papier.
Le modèle en un coup d'œil
| Section | Les questions à se poser | Longueur |
|---|---|---|
| 1. Contexte et problème | Qui sommes-nous ? Qu'est-ce qui coince, chiffres à l'appui ? Pourquoi maintenant ? | Une demi-page |
| 2. Utilisateurs | Qui utilisera l'outil ? Pour faire quoi ? Dans quel contexte (bureau, mobile, terrain) ? | Une demi-page |
| 3. Processus aujourd'hui / demain | Comment cela se passe-t-il concrètement ? Comment devrait-il en aller demain ? | 1 à 2 pages |
| 4. Données à reprendre | Où vivent nos données ? Quel volume ? Quel état (doublons, trous) ? | Une demi-page |
| 5. Intégrations | Quels logiciels doivent échanger avec l'outil ? Automatique ou export manuel ? | Quelques lignes |
| 6. Contraintes | Matériel, réseau, légal, humain, calendrier : qu'est-ce qui limite les choix ? | Une demi-page |
| 7. Budget et échéance | Quelle fourchette assumée ? Quelle date butoir réelle ? Quelles priorités ? | Quelques lignes |
| 8. Critères de succès | À quoi mesurera-t-on la réussite dans six mois, en chiffres ? | Quelques lignes |
Quelles erreurs plombent la plupart des cahiers des charges ?
Trois erreurs reviennent dans la majorité des documents que nous recevons.
Lister des fonctionnalités au lieu de décrire des problèmes. « Nous voulons un module de planning avec vue calendrier, un module clients et des notifications » décrit une solution imaginée, pas votre besoin. Le prestataire ne peut ni la questionner ni proposer mieux. « Nous perdons 2 à 3 rendez-vous par semaine à cause du double encodage » ouvre la discussion : peut-être que la bonne réponse n'est pas le module que vous imaginiez.
Tout classer en « indispensable ». Si les vingt lignes de votre liste sont prioritaires, aucune ne l'est. Le budget explose, le délai aussi, et les fonctions vraiment vitales ne reçoivent pas plus d'attention que les gadgets. Forcez-vous à trois catégories : indispensable au lancement, utile en phase 2, idée à discuter. Une répartition honnête ressemble à 30 / 40 / 30, pas à 100 / 0 / 0.
Copier un modèle générique trouvé en ligne. Les trames imposées (architecture technique, diagrammes, clauses juridiques) produisent des documents remplis de sections vides ou recopiées, où votre réalité n'apparaît nulle part. Un prestataire préfère 4 pages qui racontent votre entreprise à 25 pages de cases cochées. La structure ci-dessus suffit.
Comment un bon prestataire se sert-il de votre document ?
Comme d'une base de discussion, pas d'un contrat figé. Un studio sérieux qui conçoit des outils de gestion sur mesure pour PME lit votre cahier des charges, puis revient vers vous avec des questions : des points à préciser, des scénarios à challenger, parfois des sections entières à réécrire ensemble. C'est bon signe. Le document final, celui qui sert de référence au projet, s'écrit à deux.
Méfiez-vous du signal inverse : un prestataire qui chiffre votre document tel quel, sans une seule question, n'a probablement pas cherché à comprendre votre métier. Le devis paraîtra précis ; il sera surtout fragile, et chaque imprévu deviendra un supplément.
Attendez-vous aussi à ce qu'un professionnel honnête remette en cause le projet lui-même. Si vos scénarios « aujourd'hui / demain » révèlent qu'un outil standard bien paramétré règle 90 % du problème, un bon prestataire vous le dira. Un cahier des charges clair rend cette conversation possible.
Par où commencer ?
Bloquez une demi-journée au calme et rédigez d'abord les sections 1 et 3 : le contexte chiffré et deux ou trois processus en « aujourd'hui / demain ». C'est le cœur du document, le reste en découle. Faites ensuite relire chaque scénario par la personne qui fait ce travail au quotidien : elle corrigera des détails que vous croyiez connaître.
Complétez avec les données, les intégrations et les contraintes, puis forcez-vous à écrire la fourchette de budget et les critères de succès, même imparfaits. Un document de 4 pages avec des chiffres discutables vaut mieux qu'un document parfait qui n'existe pas : il sera corrigé lors du premier échange avec le prestataire, et c'est précisément à cela qu'il sert.
Questions fréquentes
Quelle longueur doit faire un cahier des charges de logiciel ?
Pour une PME, 4 à 6 pages suffisent largement. Au-delà de 10 pages, le document fige des détails que le projet fera de toute façon évoluer, et plus personne ne le lit en entier. La bonne mesure : assez court pour être relu par toute l'équipe, assez précis pour qu'un prestataire puisse poser des questions pertinentes et chiffrer honnêtement.
Faut-il chiffrer soi-même le budget dans le cahier des charges ?
Oui, au moins sous forme de fourchette. Annoncer « entre 15 000 et 25 000 € » ne vous désavantage pas : cela permet au prestataire de proposer un découpage réaliste plutôt qu'un devis hors sol. Un professionnel sérieux ne gonfle pas son prix pour atteindre votre plafond, il ajuste le périmètre. Cacher son budget fait surtout perdre du temps aux deux parties.
Qui doit écrire le cahier des charges ?
La personne qui connaît le terrain, pas un consultant externe seul. En pratique, le dirigeant ou un responsable rédige, puis fait relire chaque scénario par les personnes qui feront le travail au quotidien. Une secrétaire qui corrige un scénario de planification vous évite des semaines de développement à côté de la plaque. Le prestataire complète ensuite le document avec vous.
Que faire si vous n'arrivez pas à décrire vos processus ?
Décrivez une journée type plutôt qu'un processus abstrait. Suivez une commande réelle de son arrivée à sa facturation et notez chaque étape, chaque fichier ouvert, chaque ressaisie. Si cela reste difficile, c'est une information en soi : un bon prestataire peut mener cette observation avec vous lors d'un atelier de cadrage, souvent en une demi-journée.