Rédiger un cahier des charges logiciel : le guide complet 2026
Un cahier des charges logiciel est le document qui décrit ce que le logiciel doit faire, pour qui, et sous quelles contraintes. Il sert de référence commune entre l'entreprise et son prestataire pendant tout le projet, puis de base à la recette finale. Sa norme de référence est NF EN 16271. Il n'a pas de longueur imposée : l'effort consacré à l'expression de besoin varie de 5 % à 55 % de l'effort total du projet.
La plupart des guides sur le cahier des charges s'adressent à un chef de projet informatique entouré d'une DSI, d'une maîtrise d'ouvrage et d'un comité de pilotage. Si vous dirigez une PME et que vous écrivez votre premier cahier des charges pour un logiciel métier, ils vous parlent une langue qui n'est pas la vôtre. Celui-ci part de votre situation : vous savez ce qui ne va pas dans votre organisation, vous ne savez pas comment le formuler pour qu'un prestataire puisse le chiffrer.
📋 Qu’est-ce qu’un cahier des charges logiciel ?
Un cahier des charges logiciel est un document qui exprime un besoin, pas une solution. Il décrit ce que le futur logiciel doit permettre de faire, pour quels utilisateurs, dans quel contexte et sous quelles contraintes, sans dicter comment le construire. Rédigé par l’entreprise qui achète, il devient la référence partagée avec le prestataire qui développe, puis le document contre lequel on vérifie que le travail livré correspond à la commande.
La distinction entre le besoin et la solution est la seule règle qui compte vraiment. Écrire « il nous faut un module de planification avec un calendrier en glisser-déposer » revient à choisir une réponse avant d’avoir posé la question. Écrire « nos techniciens doivent voir leurs interventions de la semaine et un responsable doit pouvoir les réaffecter en cas d’absence » laisse au prestataire la latitude de proposer mieux que ce que vous aviez imaginé.
La norme applicable est NF EN 16271, publiée en février 2013 par l'AFNOR. Un point mérite d'être signalé, car beaucoup d'articles français se trompent encore : la norme NF X50-151 est annulée. Son édition de septembre 2007 a été remplacée par NF EN 16271, après avoir elle-même remplacé une édition de décembre 1991.
Cahier des charges, expression de besoin, spécifications : qui écrit quoi
Trois documents portent des noms proches et ne se confondent pas. L’expression de besoin vient en premier : elle décrit le problème métier, souvent en quelques pages, parfois en quelques phrases. Le cahier des charges la formalise et y ajoute le périmètre, les contraintes, le budget et les attentes envers le prestataire. Les spécifications fonctionnelles viennent après la signature : elles traduisent le besoin en écrans, en règles de calcul et en comportements précis.
La conséquence pratique est simple. Vous écrivez l’expression de besoin et le cahier des charges. Vous ne devez pas écrire les spécifications fonctionnelles : c’est le travail du prestataire, et le lui imposer revient à payer pour un travail que vous aurez fait vous-même, moins bien.
Le cahier des charges a-t-il une valeur contractuelle ?
Un cahier des charges n’a de valeur contractuelle que s’il est annexé au contrat et que le contrat y renvoie explicitement. Seul, c’est un document de travail. Annexé, il devient la définition de ce qui a été commandé, et donc la référence en cas de désaccord sur ce qui devait être livré.
C’est la raison pour laquelle le chapitre consacré à vos attentes envers le prestataire mérite autant de soin que la liste des fonctionnalités. Un point en particulier ne se rattrape pas après coup : la cession des droits sur le code. La dévolution automatique des droits patrimoniaux à l’employeur ne vaut que pour les logiciels créés par ses salariés. Pour un prestataire externe, l’article L113-9 du Code de la propriété intellectuelle impose une clause de cession explicite. Sans elle, le client qui paie n’est pas titulaire des droits sur ce qu’il a payé.
🤔 Faut-il vraiment en écrire un ? Les trois cas
Non, pas toujours. C’est le point que les guides écrits par des prestataires évitent, parce qu’ils vendent la prestation qui suit. Un cahier des charges détaillé est indispensable dans certains cas, inutile dans d’autres, et parfois franchement nuisible. Savoir dans lequel vous êtes vous fera gagner plusieurs semaines.
Une question se tranche d’ailleurs avant le cahier des charges : celle de savoir si vous construisez ou si vous assemblez. Le comparatif no-code ou développement sur mesure la traite en détail, et la réponse change le contenu de votre document.
Chez OTTOPILOTE, le brief initial tient en quelques phrases, sans vocabulaire technique, et le devis arrive sous 24 heures ouvrées. Le cahier des charges proprement dit se construit ensuite, en semaine 1 du projet, avec un document clair et un devis signé avant la première ligne de code.
🧰 Ce qu’il faut réunir avant d’écrire la première ligne
La préparation détermine la qualité du document bien plus que le talent de rédaction. Un cahier des charges se remplit avec de la matière collectée sur le terrain, pas avec des intentions. Cette matière se rassemble en deux temps : ce que vous produisez seul, à votre bureau, et ce qui ne peut sortir que d’échanges avec les personnes qui utiliseront l’outil.
Ce que vous rassemblez seul
- La cartographie de vos processus réels. Qui fait quoi, dans quel ordre, avec quel outil. Un schéma sur une page vaut mieux que trente pages de prose. L’erreur classique consiste à décrire le processus tel qu’il devrait être plutôt que tel qu’il est : le logiciel construit sur cette base ne correspondra à la réalité d’aucune équipe.
- L’inventaire des outils en place et de leurs exports. Nom de chaque outil, ce qu’il contient, qui y a accès, et surtout dans quel format il permet de sortir vos données. Un outil dont vous ne pouvez pas extraire l’historique transforme une reprise de données simple en chantier.
- Le volume réel. Nombre d’utilisateurs, nombre de dossiers ou de clients traités par mois, taille des fichiers manipulés. Ces trois chiffres changent l’architecture du logiciel et donc son prix.
- Les irritants documentés. Pas « c’est lourd », mais « la saisie d’une commande demande de rouvrir trois fichiers et prend vingt minutes ». Un irritant chiffré devient un objectif mesurable au chapitre 2.
- Vos contraintes non négociables. Une échéance réglementaire, une saison haute pendant laquelle rien ne doit changer, une intégration comptable obligatoire. Elles pèsent plus lourd que la moitié de vos fonctionnalités.
Ce qui se produit avec les utilisateurs
🗂️ La trame : les 9 chapitres d’un cahier des charges logiciel
Un cahier des charges logiciel utile tient en neuf chapitres. Cette trame suit l’ordre dans lequel un prestataire a besoin de comprendre votre projet : d’abord pourquoi vous agissez, ensuite ce que vous attendez, puis dans quelles conditions. Chaque chapitre ci-dessous indique ce qu’il contient, l’erreur qui revient le plus souvent, et une formulation qui fonctionne.
1. Contexte et problème à résoudre. Décrivez votre activité en dix lignes, puis ce qui ne fonctionne pas aujourd’hui. Un lecteur extérieur doit comprendre votre métier et votre problème sans vous connaître. Erreur courante : ouvrir sur la solution envisagée. Formulation qui marche : « Nos quinze techniciens saisissent leurs interventions sur papier, puis une assistante les ressaisit dans un tableur. » Si votre problème part d’un tableur devenu ingérable, le mécanisme est décrit ici.
2. Objectifs mesurables. Trois à cinq objectifs, chacun avec un chiffre et une échéance. Erreur courante : des objectifs invérifiables du type « améliorer la productivité ». Formulation qui marche : « Supprimer la double saisie, soit environ dix heures par semaine, avant la fin du premier trimestre suivant la mise en service. » Ces objectifs deviennent aussi la base du calcul de rentabilité, dont la méthode est détaillée ici.
3. Périmètre : ce qui est dedans et ce qui n’y est pas. Le chapitre le plus rentable du document. Listez ce que le projet couvre, puis ce qu’il ne couvre pas, explicitement. Écrire « la facturation n’entre pas dans cette phase » vous épargne des semaines de discussions. C’est aussi ce chapitre qui rend le document exploitable comme base d’appel d’offres, puisque tous les prestataires chiffrent alors exactement le même périmètre.
Écrire les exclusions est la seule protection réellement efficace contre la dérive de périmètre, qui touche 52 % des projets selon le PMI, contre 43 % cinq ans plus tôt. Un paragraphe explicite sur ce que le projet ne fera pas vaut mieux que dix pages sur ce qu'il fera.
4. Utilisateurs et parcours. Décrivez chaque type d’utilisateur, ce qu’il fait dans la journée, et ce qu’il doit pouvoir faire dans l’outil. Erreur courante : ne décrire que l’utilisateur administrateur, celui qui rédige le document. Formulation qui marche : « Le technicien, en déplacement, avec un téléphone et parfois sans réseau, doit pouvoir consulter sa tournée et saisir son compte rendu. »
5. Fonctionnalités attendues, priorisées. Listez les fonctions par groupe, et classez-les en trois niveaux : indispensable au démarrage, souhaitable, envisageable plus tard. Erreur courante : une liste à plat de soixante lignes toutes également importantes, qui rend tout arbitrage budgétaire impossible. La priorisation est ce qui vous permettra de couper sans casser le projet quand le devis dépassera l’enveloppe.
6. Données et existant à reprendre. Quelles données doivent être récupérées, depuis quel outil, sur quelle profondeur d’historique, et dans quel état elles sont. Erreur courante : traiter la reprise de données comme un détail technique. C’est régulièrement le poste qui déborde, parce que les données existantes sont incomplètes ou en double, et que personne ne l’a vérifié avant.
7. Contraintes techniques et sécurité. Les outils avec lesquels le logiciel doit dialoguer, les obligations réglementaires applicables, le RGPD en premier lieu dès que vous manipulez des données personnelles, et les exigences d’accès et de confidentialité. Erreur courante : imposer une technologie précise sans raison. Sauf contrainte réelle de votre part, laissez ce choix au prestataire et jugez-le sur ce qu’il propose.
8. Budget, délais et jalons. Donnez une fourchette budgétaire et vos échéances. Erreur courante : cacher son budget en croyant négocier. En réalité, un prestataire qui ignore votre enveloppe vous propose une solution au hasard, et vous perdez un cycle entier de discussion. Pour situer votre projet avant d’écrire ce chapitre, consultez les fourchettes de prix d’un logiciel sur mesure, ou le détail poste par poste d’un SaaS si votre projet est un produit destiné à être commercialisé.
9. Ce que vous attendez du prestataire. Livrables, documentation, formation, garantie après mise en service, maintenance, et cession des droits sur le code. Erreur courante : oublier ce chapitre. C’est pourtant celui qui détermine si vous pourrez, un jour, changer de prestataire sans tout reconstruire.
⏱️ Combien de temps, et jusqu’où descendre dans le détail ?
Il n’existe pas de durée standard, et c’est une information en soi. La seule étude ayant mesuré l’effort consacré à l’expression de besoin dans des PME logicielles trouve une dispersion considérable : de 5 % à 55 % de l’effort total du projet, avec une moyenne de 18 %. Autrement dit, deux projets comparables peuvent légitimement demander un travail de cadrage dix fois différent. Toute personne qui vous annonce une durée type invente.
Cette étude porte sur trente entreprises néo-zélandaises et date de 2011. Son intérêt n’est pas sa moyenne, trop fragile pour être citée comme une norme, mais l’ampleur de son écart, qui reflète une réalité que tous les prestataires observent.
Les étapes 2 à 4 forment ce qu’on appelle le cadrage. Accompagné, il tient en une semaine maximum pour un logiciel métier, avec plusieurs séances réparties à raison d’environ une par jour. C’est la durée que nous appliquons sur nos projets, et elle bouge selon qu’il s’agit d’un outil interne, d’une application mobile ou d’un SaaS. Seul, sans ateliers préparés, la même matière se rassemble par intermittence sur plusieurs semaines : c’est le calendrier qui s’étire, pas le travail.
Combien de pages viser
La bonne longueur est celle qui permet à un prestataire de chiffrer sans revenir vers vous dix fois. Pour un logiciel métier de PME, un document de quinze à vingt-cinq pages couvre généralement les neuf chapitres avec le niveau de détail utile. Ce n’est pas une norme, c’est un ordre de grandeur : aucune source publique n’établit de longueur de référence.
Le vrai critère n’est pas le nombre de pages mais la densité de décisions. Un document de dix pages qui tranche clairement le périmètre et priorise les fonctions vaut mieux qu’un document de soixante pages qui décrit tout sans hiérarchiser.
Le risque de sur-spécifier
Trop de détail nuit autant que pas assez, et cette erreur est moins souvent signalée. Un cahier des charges qui décrit les écrans, les boutons et l’enchaînement précis des clics fait deux dégâts. Il transfère vers vous une responsabilité de conception que vous n’êtes pas en position d’assumer. Et il interdit au prestataire de proposer mieux, puisque vous avez déjà tranché.
Vous décrivez le quoi et le pourquoi. Le prestataire propose le comment. Chaque fois que vous vous surprenez à écrire une solution technique, remontez d'un cran et écrivez le besoin qui l'a motivée.
💶 Ce que le cahier des charges coûte, et ce que son absence coûte
Le cahier des charges ne se facture pas, il se paie en temps. C’est la seule manière honnête de présenter son coût pour une PME, et cela explique pourquoi si peu d’articles y répondent : il n’existe pas de tarif de marché pour un document que le client produit lui-même.
Un dernier repère : avec OTTOPILOTE, obtenir un ordre de grandeur ne coûte rien et ne demande pas de document. Le brief initial tient en quelques phrases, sans vocabulaire technique, et le devis arrive sous 24 heures ouvrées. Le cadrage complet est ensuite la semaine 1 du projet, incluse, avec un document clair et un devis signé avant la première ligne de code.
⚖️ Ce qu’un bon cahier des charges vous permet d’obtenir
🔍 Transformer votre cahier des charges en devis comparables
Le cahier des charges n’est pas une fin, c’est l’outil qui vous permet de décider. Or la plupart des dirigeants l’envoient à trois prestataires puis comparent trois montants, ce qui est exactement la mauvaise façon de s’en servir. Un devis se lit d’abord sur ce qu’il contient, ensuite seulement sur ce qu’il coûte.
Préparez une grille de dépouillement avant de recevoir les réponses. Cinq critères suffisent :
| Critère | Ce que vous vérifiez |
|---|---|
| Périmètre couvert | Les fonctions de niveau 1 sont-elles toutes chiffrées, ou certaines sont-elles renvoyées à une phase ultérieure ? |
| Ce qui est exclu | Que dit le devis sur la reprise de données, la formation et la maintenance ? Un silence est une exclusion. |
| Compréhension du métier | Le prestataire a-t-il reformulé votre problème, ou seulement recopié votre liste ? |
| Questions posées | Un prestataire qui ne pose aucune question n’a pas lu le document, ou n’a pas l’intention de discuter le périmètre. |
| Droits et réversibilité | Cession du code, accès aux hébergements, documentation livrée. |
La colonne « questions posées » est la plus révélatrice. Un prestataire qui revient avec cinq questions précises sur vos processus a compris votre projet. Un devis renvoyé en vingt-quatre heures sans une seule question porte sur un projet imaginaire.
⚠️ Les 6 pièges les plus fréquents
Ces six pièges se recoupent avec les causes classiques de dépassement budgétaire. Aucun n’est une fatalité technique : tous se jouent avant la première ligne de code.
🎯 En résumé
📚 Sources
- AFNOR, NF EN 16271 (février 2013) et NF X50-151, annulée
- Project Management Institute, Requirements Management: Core Competency for Project and Program Success, 2014
- Project Management Institute, Pulse of the Profession 2018, dérive de périmètre
- Talbot & Connor, Requirements Engineering Current Practice and Capability in Small and Medium Software Development Enterprises, 2011
- Experian Data Quality, Data migrations face challenges as organizations seek better data insight, 2015
- Article L113-9 du Code de la propriété intellectuelle, Légifrance
- Standish Group, CHAOS Report 2020 (rapport édité et vendu par le Standish Group, pas librement consultable)
❓ Questions fréquentes
L'entreprise qui achète le logiciel, parce qu'elle seule connaît ses processus, ses contraintes et ses priorités. Dans une PME sans DSI, c'est le dirigeant ou le responsable du service concerné, avec la contribution des personnes qui utiliseront l'outil au quotidien. Le prestataire, lui, rédige les spécifications fonctionnelles après la signature : ce n'est pas votre travail.
Aucune longueur n'est imposée et aucune source publique n'établit de référence. Pour un logiciel métier de PME, quinze à vingt-cinq pages couvrent généralement les neuf chapitres utiles. Le vrai critère n'est pas le nombre de pages mais la densité de décisions : un document de dix pages qui tranche le périmètre et priorise les fonctions vaut mieux que soixante pages qui décrivent tout sans hiérarchiser.
Il n'existe pas de durée standard. La seule étude ayant mesuré l'effort consacré à l'expression de besoin dans des PME logicielles trouve une dispersion de 5 % à 55 % de l'effort total du projet, avec une moyenne de 18 % (Talbot & Connor, 2011). Deux projets comparables peuvent légitimement demander un cadrage dix fois différent. Toute durée type annoncée est inventée.
Seulement s'il est annexé au contrat et que le contrat y renvoie explicitement. Seul, c'est un document de travail sans portée juridique. Annexé, il définit ce qui a été commandé et devient la référence en cas de désaccord sur le périmètre livré. C'est aussi le bon endroit pour exiger la cession des droits sur le code.
Le cahier des charges exprime le besoin : ce que le logiciel doit permettre de faire, pour qui, sous quelles contraintes. Il est écrit par le client, avant la signature. Les spécifications fonctionnelles traduisent ce besoin en écrans, règles de calcul et comportements précis. Elles sont écrites par le prestataire, après la signature. Les rédiger vous-même revient à payer deux fois le même travail.
Oui, un cahier des charges figé n'est pas nécessaire en approche itérative. Mais l'absence de document ne signifie pas l'absence de cadrage : il faut un périmètre initial court, une liste de besoins priorisés et des arbitrages pris à chaque itération. Une approche agile sans besoin formulé ne produit pas de la souplesse, elle produit de la dérive.
Oui, sous forme de fourchette. Cacher son budget en croyant mieux négocier fait perdre un cycle entier de discussion : le prestataire propose une solution au hasard, et vous découvrez à la réponse que vous n'étiez pas dans le même ordre de grandeur. Une fourchette annoncée vous vaut des propositions adaptées et vous montre immédiatement qui sait travailler dans votre enveloppe.
Un projet en tête ? Parlons-en.
Un brief, une lecture honnête et un devis gratuit sous 24 h. On vous aide à choisir — ou à construire — le bon outil.
LinkedIn
Instagram
OTTOPILOTE