Blog Post

L’essentiel en 30 secondes

• Le cahier des charges d’un logiciel sur mesure décrit ce que l’outil doit faire, pour qui, sous quelles contraintes et selon quels critères il sera accepté.
• Pour une PME, 15 à 30 pages suffisent. Au-delà, le document est rarement lu en entier.
• Il se rédige en 7 étapes, de l’atelier de cadrage à la consultation des prestataires.
• En France, il doit traiter le RGPD (articles 25 et 28), l’accessibilité (obligatoire pour de nombreux services depuis le 28 juin 2025) et la cession des droits sur le code.
• Une checklist de 12 points, en fin d’article, permet de vérifier le document avant envoi.

Un cahier des charges pour un logiciel sur mesure est le document qui fixe le besoin avant le développement : objectifs, utilisateurs, fonctionnalités, contraintes techniques et réglementaires, budget, calendrier et critères de recette. Il sert de base aux devis, puis de référence pendant tout le projet.

Cet article s’adresse aux dirigeants de PME et d’ETI, aux DSI et aux chefs de projet en France qui préparent un appel d’offres ou un premier échange avec une société de développement. Vous y trouverez un modèle en 10 rubriques, la méthode de rédaction, les points propres au droit français et une checklist à copier.

Nous lisons beaucoup de cahiers des charges chez Feel IT. Les plus utiles ne sont pas les plus longs. Ce sont ceux qui disent clairement quel problème coûte de l’argent aujourd’hui.

Sommaire

• Qu’est-ce qu’un cahier des charges de logiciel sur mesure ?
• Pourquoi ce document pèse sur la réussite du projet
• Modèle de cahier des charges : les 10 rubriques
• Comment rédiger un cahier des charges en 7 étapes
• RGPD, accessibilité, propriété du code : les exigences françaises
• Cahier des charges et méthode agile
• 6 erreurs fréquentes
• Checklist avant envoi
• Questions fréquentes

Qu’est-ce qu’un cahier des charges de logiciel sur mesure ?

En France, la référence reste la norme AFNOR NF X50-151, reprise au niveau européen par la NF EN 16271. Elle présente le cahier des charges fonctionnel comme le document dans lequel le demandeur exprime son besoin en fonctions de service et en contraintes, sans imposer de solution technique. Pour le logiciel, la norme internationale ISO/IEC/IEEE 29148, qui a remplacé l’IEEE 830 en 2011, précise comment écrire des exigences vérifiables.

Dans la pratique, on distingue deux documents :

• le cahier des charges fonctionnel (CDCF), qui décrit ce que le logiciel doit permettre du point de vue des métiers. Exemple : « un commercial crée un devis en moins de 3 minutes depuis son téléphone » ;
• le cahier des charges technique, qui couvre l’architecture, l’hébergement, les intégrations et la sécurité. Il est souvent co-écrit avec le prestataire retenu.

Pour un premier projet, commencez par le fonctionnel. La partie technique se précise mieux une fois que le prestataire a compris votre métier.

Pourquoi ce document pèse autant sur la réussite du projet

Les chiffres les plus cités viennent du rapport CHAOS du Standish Group. Dans sa première édition (1994), seuls 16,2 % des projets logiciels étudiés avaient été livrés dans les délais et le budget, et 31,1 % avaient été abandonnés en cours de route. Parmi les causes d’abandon, les exigences incomplètes arrivaient en tête, avec 13,1 % des réponses.

Ces données ont plus de trente ans et les méthodes ont changé. Le constat de fond se vérifie pourtant encore sur le terrain : quand le besoin est flou, les devis ne sont pas comparables, les arbitrages se font pendant le développement et la recette tourne à la négociation.

Un cahier des charges bien construit sert d’abord à obtenir des devis comparables. Ensuite, il tranche les désaccords en cours de projet. À la fin, il dit si le logiciel livré est conforme ou non.

Modèle de cahier des charges : les 10 rubriques

Voici la trame que nous recommandons pour un logiciel métier, un extranet client ou une application interne. Adaptez la profondeur de chaque rubrique à la taille du projet.

Rubrique	Contenu attendu	Exemple
1. Contexte et objectifs	Situation actuelle, problème à résoudre, indicateurs de succès	Réduire de 50 % le temps de traitement d’une commande
2. Périmètre	Ce qui est inclus et ce qui ne l’est pas	Pas de module de paie dans la version 1
3. Utilisateurs et rôles	Profils, volumes, droits d’accès	40 commerciaux, 5 administrateurs, 300 clients en lecture seule
4. Processus actuels	Description ou schéma du fonctionnement actuel	Commande reçue par e-mail, ressaisie dans Excel puis dans l’ERP
5. Exigences fonctionnelles	Fonctionnalités classées par priorité (MoSCoW)	Must : générer un devis PDF avec signature électronique
6. Exigences non fonctionnelles	Performance, sécurité, disponibilité, accessibilité	Page chargée en moins de 2 secondes, disponibilité de 99,5 %
7. Données et intégrations	Sources, reprise des données, API, connecteurs	Synchronisation avec Sage 100 et HubSpot
8. Contraintes réglementaires	RGPD, accessibilité, règles sectorielles	Données de santé : hébergeur certifié HDS
9. Budget, planning, livrables	Enveloppe, jalons, documentation attendue	Première version (MVP) en 4 mois, documentation technique fournie
10. Recette et maintenance	Critères d’acceptation, garantie, support, réversibilité	Garantie de 3 mois, correction des anomalies bloquantes sous 48 h

Un conseil qui surprend souvent : donnez une fourchette de budget. Cela n’affaiblit pas votre position. Sans elle, deux prestataires peuvent chiffrer deux logiciels très différents à partir du même document.

Comment rédiger un cahier des charges en 7 étapes

Étape 1 : Lancer un atelier de cadrage

Réunissez 4 à 8 personnes : un sponsor qui tranche, des utilisateurs de terrain et la personne qui gère l’informatique. Deux demi-journées suffisent souvent pour poser les objectifs et lister ce qui fait perdre du temps aujourd’hui.

Étape 2 : Cartographier les processus actuels

Décrivez ce qui se passe aujourd’hui, étape par étape, y compris les fichiers Excel et les ressaisies. C’est souvent là que se cache le retour sur investissement du futur logiciel.

Étape 3 : Rédiger les besoins sous forme de user stories

Formulez chaque besoin ainsi : « En tant que [rôle], je veux [action] afin de [bénéfice] ». Ajoutez à chaque exigence un critère d’acceptation que l’on peut vérifier.

Étape 4 : Prioriser avec la méthode MoSCoW

Classez chaque exigence en Must, Should, Could ou Won’t. Notre règle : si plus de 60 % des lignes sont en Must, la priorisation n’est pas encore faite.

Étape 5 : Fixer les exigences non fonctionnelles

Performance, sécurité, RGPD, accessibilité, hébergement, réversibilité. Ce sont elles qui expliquent le plus souvent les gros écarts entre deux devis.

Étape 6 : Définir budget, planning et critères de recette

Indiquez une fourchette de budget, une date cible et la façon dont vous validerez chaque livraison.

Étape 7 : Faire relire, puis consulter les prestataires

Faites relire le document par un utilisateur qui n’a pas participé aux ateliers, puis envoyez-le à 3 ou 4 prestataires avec la même grille d’évaluation.

RGPD, accessibilité, propriété du code : les exigences françaises à ne pas oublier

RGPD : la protection des données dès la conception

L’article 25 du RGPD impose la protection des données dès la conception et par défaut. Concrètement, le cahier des charges doit lister les données personnelles traitées, leur durée de conservation, les droits d’accès et le lieu d’hébergement. Si le prestataire manipule ces données, l’article 28 exige un contrat de sous-traitance qui précise ses obligations. La CNIL publie un guide RGPD du développeur et un guide du sous-traitant, très pratiques pour formuler ces exigences. Pour un traitement à risque (données de santé, profilage, surveillance), prévoyez une analyse d’impact (AIPD).

Accessibilité : obligatoire pour de nombreux services depuis le 28 juin 2025

La directive (UE) 2019/882, dite European Accessibility Act, s’applique en France depuis le 28 juin 2025. Elle couvre notamment le commerce électronique, les services bancaires, les livres numériques et certains services de transport. Les microentreprises de services (moins de 10 salariés et chiffre d’affaires ou bilan annuel inférieur ou égal à 2 millions d’euros) en sont exemptées. Si votre logiciel s’adresse à des clients finaux, demandez une conformité au RGAA, le référentiel français fondé sur les WCAG.

Propriété du code et réversibilité

En droit français, un logiciel développé par un prestataire extérieur n’appartient pas automatiquement au client. L’article L131-3 du Code de la propriété intellectuelle exige que chaque droit cédé soit mentionné (reproduction, modification, diffusion) avec son étendue, sa destination, son territoire et sa durée. Écrivez-le dans le cahier des charges, puis dans le contrat. Ajoutez une clause de réversibilité : remise du code source, de la documentation et des accès en fin de relation.

Chez Feel IT, le client est propriétaire du code source livré. Posez la question à chaque prestataire consulté, la réponse est révélatrice. Pour les applications exposées sur Internet, prévoyez aussi un test d’intrusion avant la mise en production.

Cahier des charges et méthode agile : faut-il choisir ?

Non. L’idée qu’un projet agile se passe de cahier des charges vient d’une confusion. Ce qui disparaît en agile, c’est la spécification figée de 150 pages, pas l’expression du besoin.

Le compromis qui fonctionne : un cahier des charges fonctionnel de 15 à 30 pages qui fixe les objectifs, le périmètre, les priorités et les contraintes. Il devient ensuite le backlog initial. Chez Feel IT, ce backlog est découpé en sprints de deux semaines, avec une démonstration à la fin de chacun. Les détails se précisent au fil des sprints, sans perdre de vue le cadre de départ.

Le modèle contractuel suit la même logique. Au forfait, le document doit être très précis, car chaque écart devient un avenant. En régie ou en agile avec un budget plafonné, il peut rester ouvert sur les détails, jamais sur les objectifs.

6 erreurs fréquentes dans un cahier des charges logiciel

• Décrire la solution au lieu du besoin : « un bouton vert en haut à droite » au lieu de « valider une commande en un clic ».
• Classer toutes les fonctionnalités en priorité haute.
• Oublier les utilisateurs secondaires : comptabilité, support, clients externes.
• Ne rien dire des données existantes ni de leur reprise.
• Taire le budget, ce qui rend les devis impossibles à comparer.
• Laisser la recette sans critères mesurables. « Rapide » ou « intuitif » ne se vérifient pas.

Checklist : 12 points à vérifier avant d’envoyer votre cahier des charges

Copiez cette liste dans votre document et cochez chaque point avant la consultation.

• ☐ Les objectifs sont chiffrés (délai, coût, volume, taux d’erreur).
• ☐ Le périmètre précise ce qui est exclu de la version 1.
• ☐ Chaque rôle utilisateur est décrit avec ses droits.
• ☐ Les processus actuels sont schématisés.
• ☐ Chaque exigence fonctionnelle a une priorité MoSCoW.
• ☐ Chaque exigence a un critère d’acceptation vérifiable.
• ☐ Les performances et la disponibilité attendues sont chiffrées.
• ☐ Les données personnelles, leur durée de conservation et leur hébergement sont listés.
• ☐ L’obligation d’accessibilité (RGAA) a été vérifiée.
• ☐ Les intégrations (ERP, CRM, API) sont nommées, avec leur version.
• ☐ Une fourchette de budget et une date cible figurent dans le document.
• ☐ La cession des droits sur le code et la réversibilité sont demandées.

Questions fréquentes sur le cahier des charges d’un logiciel sur mesure

Combien de pages doit faire un cahier des charges pour un logiciel sur mesure ?

Pour une PME, 15 à 30 pages suffisent en général. Ce qui compte, c’est que chaque exigence soit claire, priorisée et vérifiable. Un document de 100 pages que personne ne relit crée plus d’ambiguïtés qu’il n’en résout. Les maquettes et exemples de fichiers peuvent aller en annexe.

Qui doit rédiger le cahier des charges d’un logiciel ?

Le client, parce que c’est lui qui connaît le métier. Un chef de projet interne pilote la rédaction avec les futurs utilisateurs. Une assistance à maîtrise d’ouvrage (AMOA) ou le prestataire peut aider sur la partie technique, mais les objectifs et les priorités doivent venir de l’entreprise.

Combien de temps faut-il pour rédiger un cahier des charges ?

Comptez 2 à 6 semaines pour un projet de taille moyenne : une à deux semaines d’ateliers et d’entretiens, puis la rédaction et une relecture. Les projets avec beaucoup d’intégrations ou de fortes contraintes réglementaires (santé, finance) demandent plus de temps.

Quelle différence entre cahier des charges et spécifications fonctionnelles détaillées ?

Le cahier des charges exprime le besoin et les contraintes avant le choix du prestataire. Les spécifications fonctionnelles détaillées (SFD) décrivent comment le logiciel y répondra : écrans, règles de gestion, cas d’erreur. Le prestataire les rédige en général après la signature.

Faut-il un cahier des charges pour un projet agile ?

Oui, sous une forme plus légère. Il fixe les objectifs, le périmètre, les priorités et les contraintes réglementaires, puis sert de backlog initial. Le détail de chaque fonctionnalité se précise ensuite sprint par sprint avec l’équipe de développement.

Existe-t-il un modèle de cahier des charges logiciel gratuit ?

Oui. Les 10 rubriques et la checklist de cet article forment un modèle réutilisable pour un logiciel métier ou une application interne. Copiez la trame, adaptez la profondeur de chaque rubrique à votre projet et faites relire le tout par un futur utilisateur.

Conclusion : un cahier des charges court, précis et vérifiable

Le cahier des charges d’un logiciel sur mesure n’a pas besoin d’être long. Il doit dire quel problème vous voulez résoudre, pour qui, avec quelles priorités et selon quels critères vous accepterez le résultat. Ajoutez les points propres au contexte français (RGPD, accessibilité, cession des droits) et vous aurez une base solide pour comparer les devis.

Vous avez déjà un premier brouillon ? L’équipe Feel IT peut le relire et vous dire ce qui manque avant la consultation. Contactez-nous ou découvrez nos services de développement de logiciels en France.

Pour aller plus loin : développement logiciel sur mesure en France : méthode, coûts et RGPD et comment choisir la bonne société de développement logiciel.

Sources

• AFNOR, NF EN 16271 : expression fonctionnelle du besoin et cahier des charges fonctionnel
• IEEE, ISO/IEC/IEEE 29148 : ingénierie des exigences
• The Standish Group, The CHAOS Report (1994)
• CNIL, Guide RGPD du développeur
• CNIL, Guide du sous-traitant
• EUR-Lex, directive (UE) 2019/882 relative aux exigences en matière d’accessibilité
• DINUM, Référentiel général d’amélioration de l’accessibilité (RGAA)