Logiciel sur mesure
Le cahier des charges d'un logiciel, sans jargon et sans 40 pages
Vous envisagez de faire développer un outil, et tout le monde vous dit qu'il faut un cahier des charges. C'est vrai, et c'est là que beaucoup de projets prennent leur premier mauvais virage : des semaines passées sur un document de quarante pages que personne ne lira en entier, ou à l'inverse un mail de dix lignes qui laissera le prestataire deviner l'essentiel. Cette page donne la mesure juste : à quoi sert vraiment un cahier des charges, les six parties qui comptent, un plan à recopier, qui doit l'écrire, et les erreurs qui font déraper les projets avant la première ligne de code. Tout tient dans une conviction simple : un bon cahier des charges est un document court, plein de vos faits, et vide de généralités.
À quoi il sert vraiment
Un cahier des charges de logiciel a un seul vrai travail : faire que vous et votre prestataire parliez du même projet. Pas décrire chaque écran, pas prévoir chaque cas, pas servir d'arme au premier litige : aligner. Le document réussi est celui qui évite le dialogue de sourds où vous pensiez acheter une chose et où l'équipe en a construit une autre, de bonne foi des deux côtés. Ce malentendu-là coûte plus cher que toutes les erreurs techniques réunies, et il se joue avant le premier euro dépensé.
Il sert ensuite à comparer les devis. Deux prestataires qui chiffrent sur le même document produisent des devis comparables ; deux prestataires qui chiffrent sur deux conversations téléphoniques produisent des chiffres qui ne parlent pas du même projet, et l'écart de prix ne vous apprend rien.
Il sert enfin de mémoire. Six mois après le lancement, quand une discussion s'ouvre sur ce qui était prévu ou pas, le document tranche en une minute ce que les souvenirs disputeraient pendant une réunion. C'est sa fonction contractuelle, et elle marche d'autant mieux que le document est court : on ne s'appuie que sur ce qu'on a lu, et personne n'a jamais relu quarante pages au milieu d'un désaccord.
Ce que le cahier des charges n'est pas : une garantie contre les découvertes. Un projet de logiciel sur mesure apprend des choses en avançant, c'est sa nature, et le document doit organiser cette découverte au lieu de prétendre l'interdire. Les meilleures pages d'un cahier des charges moderne disent ce qu'on sait, ce qu'on ne sait pas encore, et comment on décidera.
Le malentendu des quarante pages
Le cahier des charges épais rassure : tout ce papier semble prouver le sérieux du projet. Il produit en réalité trois effets pervers, connus de tous les gens du métier.
Personne ne le lit en entier, à commencer par les développeurs qui construiront l'outil : ils survolent, retiennent ce qui les arrange, et les pages 23 à 31 ne seront découvertes qu'au moment du désaccord. Un document que personne ne lit n'aligne personne, il donne juste l'illusion de l'avoir fait.
Il fige des décisions prises au plus mauvais moment : avant le projet, quand on en sait le moins. Les quarante pages spécifient des écrans que personne n'a encore essayés, des cas que le terrain démentira, et chaque page devient un argument pour construire ce qui était écrit plutôt que ce qui est juste.
Et il coûte l'énergie qui manquera ensuite : des semaines de rédaction, des réunions de relecture, un essoufflement avant même le début. Le bon cahier des charges d'un outil de PME tient en dix à quinze pages aérées, s'écrit en quelques ateliers, et laisse des forces pour le vrai travail : construire, tester, corriger.
Les six parties qui comptent
Voici la colonne vertébrale du document, six parties dans cet ordre. Si l'une manque, le projet part avec un angle mort ; si vous n'écrivez que ces six-là, le document fait son travail.
1. Le contexte et le problème
Une page qui raconte l'entreprise, l'équipe concernée, et surtout la douleur : ce qui coûte du temps ou de l'argent aujourd'hui, avec des exemples concrets, si possible des chiffres, et une phrase sur ce qui arrivera si rien ne change. « Trois personnes passent chacune une heure par jour à recopier des commandes » vaut mieux que « optimiser le traitement des commandes » : le prestataire qui lit la première phrase comprend le métier, celui qui lit la seconde comprend qu'il pourra vendre n'importe quoi.
2. Les utilisateurs et leurs scènes
Qui se servira de l'outil, et pour faire quoi, raconté en scènes courtes : « le conducteur de travaux, sur le chantier, prend une photo et la rattache au dossier en trente secondes ». Une dizaine de scènes de ce type décrivent mieux un outil que cinquante captures d'écran annotées, parce qu'elles décrivent le travail, pas une interface imaginée d'avance. Pour les récolter, rien ne vaut une heure passée à côté de chaque poste concerné : les scènes qu'on invente en réunion décrivent le travail rêvé, celles qu'on observe décrivent le travail réel, et l'outil doit servir le second.
3. Les règles du métier
Les règles que l'outil devra respecter : les seuils, les validations, les calculs, les interdits. « Une facture de chantier ne part jamais avant la réception des travaux » est une règle métier ; il y en a dix ou vingt comme elle dans votre entreprise, souvent dans la tête des anciens ou dans les formules d'un tableur. Les écrire ici est la partie la plus précieuse du document, et celle que le gabarit trouvé sur internet ne vous donnera jamais. Numérotez-les : « règle 7 » se cite dans un mail, se teste dans le logiciel et se corrige dans le document, quand « nos procédures habituelles » ne se vérifie nulle part. C'est le même travail d'extraction que pour remplacer un tableur central, et il rapporte au-delà du projet : vos règles écrites survivent aux départs.
4. Les connexions et les données
Avec quoi l'outil devra parler : la comptabilité, la messagerie, la banque, le site. Et quelles données existantes il devra reprendre, dans quel état elles sont, où elles vivent. Cette partie évite les deux surprises les plus chères des projets, la connexion découverte en cours de route et la reprise de données jamais budgétée. Précisez aussi vos exigences d'hébergement si vous en avez : des données en France ou en Suisse, des obligations sectorielles. Deux lignes ici épargnent une négociation au milieu du chantier.
5. Ce qui est hors périmètre
La partie la plus courte et la plus rentable du document : la liste de ce que le projet ne fera PAS, ou pas dans sa première version. Chaque ligne écrite ici est une négociation évitée plus tard, et une liste d'attente toute prête pour la suite. Un cahier des charges sans section hors périmètre est un périmètre ouvert, et un périmètre ouvert est un budget ouvert. Remplissez-la en atelier, en fin de séance : « et on est bien d'accord qu'on ne fait PAS quoi ? » est la question qui produit les meilleures lignes du document.
6. Les critères de réussite
Comment vous saurez, trois mois après la livraison, que le projet a réussi : les heures rendues, les erreurs disparues, l'usage constaté. Deux ou trois critères mesurables suffisent, et ils changent la nature du chantier : l'équipe construit pour atteindre un résultat, pas pour épuiser une liste de fonctions. Ce sont aussi eux qui rendront la réception sereine : on constate, on ne débat pas.
Un plan à recopier
Pour transformer ces six parties en document, voici le plan type avec les longueurs qui marchent. Page de garde avec le nom du projet, la date et un contact. Contexte et problème : une à deux pages. Utilisateurs et scènes : deux à trois pages, une scène par paragraphe. Règles du métier : deux à quatre pages, une règle par ligne, numérotées pour pouvoir s'y référer. Connexions et données : une à deux pages, un tableau fait très bien l'affaire. Hors périmètre : une page de liste. Critères de réussite : une demi-page. Total : dix à quinze pages, écrites en français courant.
Deux ajouts utiles selon votre cas. Si l'outil remplace un fichier Excel central, joignez le fichier ou sa description : il contient vos règles réelles, et la page remplacer Excel de ce guide explique comment les en faire sortir. Si l'outil doit reprendre un logiciel existant, l'état des lieux de l'ancien système devient une annexe indispensable.
Ce qui ne va PAS dans le document : les choix techniques, langage, hébergeur, architecture, qui appartiennent à la discussion avec le prestataire et évoluent avec le projet. Les maquettes détaillées, qui naîtront du travail commun. Et les clauses juridiques, propriété du code et réversibilité, qui vivent dans le contrat, pas dans le cahier des charges, même si les deux documents se répondent.
Bien écrit, mal écrit : trois exemples corrigés
La différence entre un cahier des charges qui aligne et un cahier des charges qui décore se joue phrase par phrase. Trois exemples, avant et après, pour attraper le geste.
Sur le problème. Avant : « Le processus de gestion des devis doit être optimisé et digitalisé. » Après : « Chaque devis passe par le bureau d'études, prend deux à trois heures, et deux devis sur dix partent avec un poste oublié ; l'outil doit ramener le devis courant sous la demi-heure et rendre l'oubli impossible. » La première phrase peut se vendre à n'importe quelle entreprise de France ; la seconde ne décrit que la vôtre, et elle contient déjà deux critères de réussite.
Sur une scène. Avant : « Le module planning devra être ergonomique et intuitif. » Après : « La responsable d'exploitation prépare le planning de la semaine le jeudi après-midi ; elle doit voir en un écran qui est disponible, qui a quelle habilitation, et être bloquée si elle affecte quelqu'un déjà pris ailleurs. » L'ergonomie n'est pas une exigence, c'est un résultat ; la scène, elle, se construit et se vérifie.
Sur une règle. Avant : « L'outil devra respecter les procédures internes de validation. » Après : « Règle 12 : toute commande au-dessus de 5 000 euros exige la validation du gérant avant envoi au fournisseur, sans exception, y compris pour les clients historiques. » La règle numérotée se code, se teste et se discute ; la procédure invoquée en bloc ne fait rien de tout ça.
Le geste commun aux trois corrections : remplacer le vocabulaire de projet par les faits du terrain. Chaque fois qu'une phrase de votre brouillon pourrait figurer telle quelle dans le document d'une autre entreprise, elle est à récrire avec vos chiffres, vos gens et vos règles. C'est un travail moins long qu'il n'y paraît : les faits existent déjà, il suffit d'aller les chercher là où ils vivent, dans les journées de votre équipe, et de les écrire comme on les raconterait.
Les questions qu'un bon prestataire vous posera
Le cahier des charges se juge aussi à la conversation qu'il déclenche. Un prestataire sérieux qui reçoit votre document ne renvoie pas un devis dans la journée : il revient avec des questions, et la qualité de ces questions vous dit à qui vous avez affaire.
Les bonnes questions creusent le métier : « que se passe-t-il aujourd'hui quand la règle 12 n'est pas respectée ? », « qui corrige les erreurs de recopie, et combien de temps ça lui prend ? », « montrez-moi un devis raté, qu'est-ce qui a manqué ? ». Elles prouvent que le document a été lu, et que l'équipe cherche à comprendre avant de chiffrer.
Les questions absentes sont un signal aussi : un devis qui arrive sans qu'on vous ait demandé de précision sur vos données existantes, vos connexions ou votre hors-périmètre a été chiffré au forfait de l'espoir, et l'écart se paiera en avenants. À l'inverse, méfiez-vous des questions qui ne portent que sur la technique et jamais sur le métier : elles annoncent un outil construit pour plaire à ses développeurs.
Ce dialogue est si révélateur qu'il vaut la peine d'envoyer le document à deux ou trois prestataires même si vous avez déjà votre favori : les questions des uns enrichissent le document pour tous, et vous signez en sachant qui a vraiment lu.
Le cas particulier de la refonte
Quand le projet remplace un outil existant, le cahier des charges change de nature sur un point : l'existant devient le premier chapitre. Ce que l'ancien outil fait, qui s'en sert encore, quelles données il contient et dans quel état, ce qui doit survivre et ce qui peut disparaître : sans cet état des lieux, le devis de refonte est une estimation de loin.
Ajoutez-y deux listes propres à la refonte : les reprises de données, comptées et localisées, et les habitudes à préserver, celles que l'équipe tient et qu'un nouvel outil ne doit pas casser sans raison. La refonte réussie change l'outil et respecte les gestes ; le cahier des charges est l'endroit où les gestes s'écrivent.
Et si l'ancien outil souffre surtout de vieillissement, faites d'abord le tri entre refonte et remboursement de dette technique : il arrive qu'un bon état des lieux remplace le projet entier par un chantier d'entretien, et c'est le meilleur cahier des charges qui soit, celui qu'on n'a pas eu à écrire.
Après la signature : le document vit
Le cahier des charges ne meurt pas au démarrage du chantier, il change de rôle. Pendant la construction, il sert d'arbitre : quand une question surgit, on regarde d'abord ce qui était écrit, et la discussion part d'un texte commun au lieu de partir de deux mémoires.
Il évolue aussi, et c'est normal : chaque découverte du chantier qui change le périmètre s'écrit, en une ligne datée, dans le document ou son annexe. Ce journal des décisions coûte cinq minutes par semaine et vaut de l'or au moment de la réception : personne ne débat de ce qui a été convenu, tout y est.
La liste hors-périmètre, elle, devient votre feuille de route pour la suite : les demandes écartées de la première version y attendent leur tour, déjà formulées, et la deuxième tranche du projet se cadre en une réunion au lieu de repartir de zéro. Un bon cahier des charges sert ainsi deux fois : il cadre le projet d'aujourd'hui et pré-écrit celui de demain. Rangez-le avec le contrat, tenez-le à jour, et dans trois ans, au moment d'agrandir l'outil, vous remercierez celui qui a écrit ces quinze pages.
Qui doit l'écrire : vous, le prestataire, ou les deux
Trois écoles existent, et elles ne se valent pas. Le client écrit tout seul : il connaît son métier mieux que personne, mais il spécifie sans savoir ce qui est simple ou coûteux à construire, et le document mélange le besoin réel et des solutions imaginées devant la machine à café. Le prestataire écrit tout seul : il structure bien, mais il écrit ce qu'il a compris en deux réunions, et ce qu'il vend le mieux.
La bonne méthode est l'atelier commun : vous apportez le métier, les scènes et les règles, le prestataire apporte les questions qui font sortir ce que vous ne pensez pas à dire, celles qu'on ne se pose jamais sur son propre travail parce que tout y semble évident, et le document s'écrit à quatre mains en quelques séances. C'est le format de notre cadrage, et le résultat appartient à vous seul : un cahier des charges que vous pouvez montrer à d'autres prestataires, y compris pour nous mettre en concurrence.
Une règle quelle que soit l'école : les personnes qui feront le travail participent. Le cahier des charges écrit par la direction seule décrit le travail tel qu'on l'imagine d'en haut, et le terrain le démentira à la livraison, au prix fort. Deux heures d'atelier avec les futurs utilisateurs valent dix pages de suppositions.
Expression de besoin, cahier des charges, spécifications
Trois mots que les prestataires emploient, parfois l'un pour l'autre, et qui désignent trois niveaux de détail. Les confondre fait perdre du temps dans les deux sens : on exige des spécifications là où une expression de besoin suffisait, ou on chiffre un projet entier sur deux paragraphes. L'expression de besoin tient en une ou deux pages : le problème, l'objectif, le budget envisagé. C'est le bon format pour un premier contact, et il suffit largement pour un appel découverte.
Le cahier des charges est le document de cette page : dix à quinze pages, les six parties, la base du devis et du contrat. Les spécifications détaillées, elles, décrivent chaque écran et chaque comportement, et dans un projet moderne elles s'écrivent au fil du chantier, tranche par tranche, juste avant de construire chaque morceau, quand on en sait assez pour ne pas se tromper.
L'ordre a son importance : beaucoup de projets s'épuisent à écrire des spécifications complètes là où une expression de besoin puis un cahier des charges auraient suffi à démarrer. Le niveau de détail se gagne en avançant ; le seul document qui doit exister avant de signer, c'est le deuxième.
Les erreurs qui font déraper les projets
Cinq erreurs reviennent dans les cahiers des charges qui finissent en litige ou en tiroir, et toutes s'évitent au moment de l'écriture.
Tout spécifier d'avance. Le document prétend prévoir chaque cas, fige des choix pris au moment où l'on en sait le moins, et transforme chaque apprentissage du chantier en avenant. On écrit ce qu'on sait, on nomme ce qu'on ne sait pas, et on prévoit comment on tranchera.
Recopier un gabarit trouvé en ligne. Les modèles génériques remplissent des pages avec des généralités, et oublient l'essentiel qui n'y figure jamais : vos règles métier et vos scènes. Un document à moitié pré-rempli rassure et n'aligne rien. Le test est le même que pour toute cette page : si la phrase pouvait figurer dans le document d'une autre entreprise, elle ne protège pas la vôtre.
Écrire le cahier des charges après avoir choisi la solution. Le document devient alors la justification d'une décision prise, en général autour d'une démonstration séduisante, et le besoin se tord pour entrer dans l'outil déjà élu. Le besoin d'abord, la solution ensuite, même quand la démonstration était belle.
Oublier le hors-périmètre et les critères de réussite, les deux parties courtes : la première absence ouvre le budget, la seconde rend le succès indiscutable puisque indéfini. Et confier la rédaction à quelqu'un qui ne verra jamais l'outil fonctionner : consultant de passage, stagiaire, cousin qui s'y connaît. Le document engage des mois de travail et des dizaines de milliers d'euros ; il mérite les deux ou trois ateliers de celui qui vivra avec le résultat.
Le cahier des charges à l'heure de l'IA
Les outils d'IA savent aujourd'hui produire un cahier des charges d'apparence très convenable en dix minutes, et il est tentant de leur confier la corvée. Le résultat ressemble au gabarit trouvé en ligne, en mieux tourné : la structure est propre, les généralités sont bien écrites, et vos règles métier n'y sont toujours pas, puisque l'outil ne les connaît pas.
Le bon usage est inverse : l'IA aide à mettre en forme ce que le terrain a dit. Enregistrez l'atelier, faites-en extraire les scènes et les règles, faites reformuler vos notes en parties numérotées : des heures de mise au propre disparaissent, et le contenu reste le vôtre. L'outil tient la plume ; le métier dicte, et cette répartition ne changera pas de sitôt.
Méfiez-vous en revanche du cahier des charges adverse entièrement généré : il se reconnaît à ses pages impeccables qui ne citent ni un chiffre de l'entreprise, ni une scène de travail réelle, ni une règle qu'on ne trouve pas ailleurs. Face à un tel document, les bonnes questions d'un atelier valent mieux qu'un devis poli.
La relecture finale, en sept vérifications
Avant d'envoyer le document, une passe de dix minutes avec cette liste attrape l'essentiel de ce qui traîne. Le problème est-il chiffré, avec au moins un nombre d'heures ou d'euros qui vient de chez vous ? Chaque scène nomme-t-elle une vraie personne ou un vrai poste, dans une vraie situation ? Les règles métier sont-elles numérotées, une par ligne, relues par quelqu'un du terrain ?
Ensuite : la section hors-périmètre existe-t-elle, avec au moins cinq lignes dedans ? Les données existantes sont-elles localisées et décrites, même grossièrement ? Les critères de réussite pourraient-ils se vérifier par un tiers, sans débat ? Et la dernière, la plus cruelle : existe-t-il dans le document une seule phrase qu'une autre entreprise pourrait recopier telle quelle ? Si oui, elle est à récrire avec vos faits.
Un document qui passe ces sept vérifications fait son travail, quelle que soit sa mise en page. Un document qui en rate trois gagnera plus à un atelier de deux heures qu'à une semaine de peaufinage solitaire, parce que ce qui lui manque ne se trouve pas dans un traitement de texte : il se trouve chez les gens qui font le travail.
Combien de temps, et combien ça coûte
Écrit avec la méthode de cette page, un cahier des charges de premier outil demande deux à trois ateliers de deux heures, plus la mise au propre : une à deux semaines de calendrier, en comptant les relectures. C'est un investissement que vous pouvez faire seul et qui ne coûte que du temps, le vôtre et celui des personnes du terrain.
Quand le périmètre est plus large ou les avis internes divergents, le cadrage à quatre mains prend le relais : nos ateliers de cadrage produisent le document en quelques séances, et pour les situations où il faut d'abord démêler les processus eux-mêmes, un audit de 5 000 à 15 000 euros remet tout à plat avant d'écrire quoi que ce soit. Dans les deux cas, le document final vous appartient et peut servir à consulter qui vous voulez.
Et si vous ne savez pas si votre projet mérite déjà un cahier des charges, le diagnostic en ligne situe votre besoin en huit questions, et un appel de trente minutes avec une expression de besoin d'une page suffit pour vous dire par quel bout commencer. Beaucoup de projets démarrent ainsi, par une page honnête plutôt que par quarante pages fatiguées.
Questions fréquentes
Que doit contenir un cahier des charges de logiciel ?
Six parties : le contexte et le problème avec des chiffres, les utilisateurs et leurs scènes de travail, les règles du métier, les connexions et les données à reprendre, ce qui est hors périmètre, et les critères de réussite mesurables. Les choix techniques et les maquettes détaillées n'en font pas partie : ils naissent du travail avec le prestataire.
Quelle longueur doit faire un cahier des charges ?
Dix à quinze pages aérées pour un outil de PME, en français courant. En dessous de cinq pages, le prestataire devine trop de choses ; au-delà de vingt, plus personne ne lit, et un document que personne ne lit n'aligne personne. La partie la plus précieuse est souvent la plus courte : la liste de ce que le projet ne fera pas.
Qui doit écrire le cahier des charges, nous ou le prestataire ?
Les deux, en atelier : vous apportez le métier, les scènes et les règles, le prestataire apporte les questions et la structure. Écrit par le client seul, le document mélange besoin et solutions imaginées ; écrit par le prestataire seul, il reflète ce qu'il a compris et ce qu'il vend. Dans tous les cas, les futurs utilisateurs participent, et le document final vous appartient.
Faut-il tout spécifier avant de commencer ?
Non, et c'est même l'erreur classique : tout figer au moment où l'on en sait le moins. Le cahier des charges écrit ce qu'on sait, nomme ce qu'on ne sait pas encore, et prévoit comment on décidera. Les spécifications détaillées s'écrivent ensuite au fil du chantier, tranche par tranche, juste avant de construire chaque morceau.
Combien coûte la rédaction d'un cahier des charges ?
Écrit vous-même avec un plan solide, il coûte deux à trois ateliers de deux heures et une mise au propre. Accompagné, il s'inscrit dans un cadrage en quelques séances, et quand les processus eux-mêmes sont à démêler, dans un audit de 5 000 à 15 000 euros. Le document vous appartient et sert à consulter plusieurs prestataires.
Quelle différence entre cahier des charges et expression de besoin ?
L'expression de besoin tient en une ou deux pages : le problème, l'objectif, le budget envisagé. Elle suffit pour un premier contact. Le cahier des charges, dix à quinze pages en six parties, est le document sur lequel on chiffre et on s'engage. Les spécifications détaillées viennent encore après, au fil du chantier.
Peut-on démarrer un projet sans cahier des charges ?
Un tout petit périmètre, une automatisation simple, peut démarrer sur une expression de besoin et un atelier, et c'est même le format de beaucoup de premiers outils. Dès qu'il y a plusieurs utilisateurs, des connexions ou une reprise de données, l'absence de document se paie en malentendus, et le malentendu coûte toujours plus cher que les ateliers qui l'auraient évité. La vraie question n'est pas d'avoir un document, c'est d'être alignés : le cahier des charges est le moyen le plus court d'y arriver par écrit.
On continue la lecture ?
- Logiciel sur mesure : le guide pour décider si c'est votre cas
- Application métier : l'outil qui épouse votre façon de travailler
- Remplacer Excel : les signes que le tableur ne suffit plus
- La dette technique, expliquée à un dirigeant qui ne code pas
- Refonte d'un logiciel : réécrire, moderniser, ou remplacer ?
- Le cahier des charges d'un logiciel, sans jargon et sans 40 pages