Un cahier des charges d’application web est le document dans lequel une entreprise décrit le problème qu’elle veut résoudre, les personnes qui utiliseront l’outil, ce qui existe déjà, ce que l’application doit permettre de faire et les contraintes à respecter. Il ne décrit pas la solution technique : il exprime un besoin, assez précisément pour que plusieurs prestataires puissent proposer une réponse comparable. Un bon cahier des charges tient souvent en 10 à 20 pages, s’organise en six parties et se termine par des priorités claires.
Ce guide vous donne le plan, des exemples de formulations qui fonctionnent, les erreurs qui faussent les devis, et un modèle de cahier des charges gratuit à remplir.
À quoi sert vraiment un cahier des charges ?
Le cahier des charges a trois fonctions, et elles ne sont pas toutes évidentes.
- Vous obliger à décider. Écrire « les commerciaux saisissent leurs devis dans l’outil » force à répondre à des questions qu’on évitait : qui valide un devis au-delà d’une certaine remise ? que se passe-t-il quand un client a deux adresses de livraison ? Joel Spolsky, dans un article de référence sur les spécifications fonctionnelles, résume l’idée : la fonction la plus importante d’une spécification est de concevoir le produit, car réviser un texte coûte quelques minutes, alors que réviser du code coûte des semaines.
- Obtenir des propositions comparables. Sans document commun, chaque prestataire chiffre sa propre interprétation du projet. Les écarts de devis reflètent alors des périmètres différents, pas des niveaux de prix différents.
- Créer une mémoire partagée. Le document sert de référence aux décideurs, aux futurs utilisateurs et à l’équipe de développement. Il évite que chaque nouvel interlocuteur reformule le projet à sa manière.
Ce que le cahier des charges n’est pas : un contrat figé qui décrirait chaque écran. Dans un projet mené par itérations, il est le point de départ de la phase de cadrage, pendant laquelle le besoin est affiné, découpé et priorisé avec le prestataire retenu.
Fonctionnel ou technique : quel cahier des charges rédiger ?
La distinction est ancienne. En France, la démarche d’expression fonctionnelle du besoin et le cahier des charges fonctionnel sont normalisés : la norme NF X50-151, longtemps citée, a été remplacée par la norme européenne NF EN 16271, publiée par l’AFNOR en 2013. Son principe reste d’actualité : exprimer un besoin en termes de fonctions attendues et de contraintes, sans présumer de la solution.
| Cahier des charges fonctionnel | Spécifications techniques | |
|---|---|---|
| Question traitée | Que doit permettre l’outil, pour qui, sous quelles contraintes ? | Comment le construire ? |
| Rédacteur | L’entreprise (direction et métiers) | Le prestataire, pendant le cadrage |
| Contenu type | Objectifs, utilisateurs, processus, règles de gestion, volumes, intégrations | Architecture, technologies, modèle de données, hébergement |
| Moment | Avant la consultation | Après le choix du prestataire |
| Risque si mal fait | Devis incomparables, oublis découverts en cours de projet | Choix techniques inadaptés, dette technique |
Pour une application sur mesure, rédigez le fonctionnel et laissez le technique au prestataire. Si vous avez des contraintes techniques réelles (hébergement imposé, annuaire d’entreprise, outil existant à conserver), indiquez-les comme des contraintes, pas comme des choix d’architecture.
Le plan type en six parties
Ce plan reprend la structure de notre modèle de cahier des charges, construit autour de 24 questions. Chaque partie doit pouvoir être lue seule.
1. Contexte et objectifs
Présentez l’entreprise en quelques lignes, puis le problème : ce qui ne fonctionne pas aujourd’hui et ce que cela coûte, en temps, en erreurs ou en opportunités perdues. Formulez deux à quatre objectifs vérifiables : « ramener le délai d’émission d’un devis de trois jours à un jour », plutôt que « gagner en efficacité ».
2. Utilisateurs
Listez les profils (commerciaux, techniciens, comptabilité, clients externes), leur nombre, leur contexte de travail (bureau, atelier, déplacement, connexion instable) et leur aisance avec le numérique. Cette partie conditionne l’ergonomie : un outil utilisé huit heures par jour ne se conçoit pas comme un formulaire rempli deux fois par an, ce que nous détaillons dans notre article sur l’UX des applications métier.
3. Existant
Décrivez les outils en place (ERP, CRM, tableurs, outils du marché), ce qu’il faut conserver, remplacer ou connecter, et les données à reprendre, avec leurs volumes. Joignez des exemples réels : un fichier Excel anonymisé, un bon de commande, une capture d’écran. Ces pièces valent souvent plus qu’une page de description.
4. Besoins fonctionnels
C’est le cœur du document. Organisez les besoins par processus métier (de la demande client à la facture, par exemple), pas par écran. Pour chaque besoin : qui, quoi, pourquoi, un exemple, et une priorité.
5. Intégrations
Listez chaque échange de données avec un autre outil : quelle donnée, dans quel sens, à quelle fréquence, et ce qui se passe en cas d’échec. Une intégration oubliée est l’une des causes les plus fréquentes de dépassement. Notre article sur la connexion entre outils aide à poser ces questions.
6. Contraintes
Délais et échéances non négociables, budget indicatif, sécurité, données personnelles, accessibilité, hébergement, réversibilité. Les contraintes réglementaires ne sont pas un détail : la CNIL rappelle dans son guide RGPD du développeur que la protection des données se prépare dès la conception, ce qui suppose de savoir très tôt quelles données personnelles l’outil traitera.
Comment formuler un besoin : exemples avant et après
La qualité d’un cahier des charges se joue phrase par phrase. Un besoin bien formulé est compréhensible par un nouvel arrivant, vérifiable une fois livré, et ne dicte pas la solution.
| Formulation floue | Formulation utile |
|---|---|
| « L’outil doit être simple et ergonomique. » | « Un technicien doit pouvoir clôturer une intervention sur smartphone, sans réseau, en moins de deux minutes. » |
| « Gestion des devis. » | « Le commercial crée un devis à partir du catalogue ; toute remise supérieure à 15 % doit être validée par le directeur commercial avant envoi. » |
| « Tableau de bord complet. » | « Le directeur des opérations consulte chaque lundi le nombre d’interventions en retard par agence et par motif. » |
| « Export Excel. » | « La comptabilité récupère chaque fin de mois les factures émises au format attendu par l’outil comptable, sans ressaisie. » |
| « Connexion avec l’ERP. » | « Les commandes validées sont transmises à l’ERP dans les dix minutes ; en cas d’échec, l’administrateur est alerté. » |
Trois réflexes rendent un besoin solide :
- un acteur précis (« le chef d’équipe », pas « l’utilisateur ») ;
- un exemple réel, avec des données plausibles ;
- les cas particuliers : annulation, doublon, absence, client sans numéro SIREN, commande partiellement livrée.
Si vos équipes connaissent déjà le format des user stories, il convient parfaitement à cette partie : voir notre guide sur les user stories et critères d’acceptation.
Comment prioriser sans tout déclarer indispensable ?
Un cahier des charges où tout est prioritaire n’aide personne à arbitrer. La méthode MoSCoW, issue du cadre DSDM et documentée par l’Agile Business Consortium, classe chaque besoin en quatre catégories :
- Must have (indispensable) : sans lui, l’outil ne vaut pas la peine d’être mis en service ;
- Should have (important) : son absence est pénible, mais un contournement existe ;
- Could have (souhaitable) : utile, et premier candidat à être reporté ;
- Won’t have this time (hors périmètre pour cette version) : écarté explicitement, pour qu’il ne revienne pas par la petite porte.
Le même référentiel recommande que les besoins indispensables ne représentent généralement pas plus de 60 % de l’effort, afin de garder une marge de manœuvre. Le test pratique : si vous déclarez indispensables plus de la moitié des besoins, demandez-vous lesquels vous accepteriez de livrer trois mois plus tard. Ce sont rarement des indispensables.
Les erreurs qui faussent les devis
Certaines erreurs reviennent dans la plupart des cahiers des charges que reçoivent les prestataires. Elles ont toutes le même effet : des devis incomparables, puis des surprises en cours de projet.
- Décrire la solution au lieu du problème. « Un menu déroulant avec les 400 références » ferme la porte à une recherche plus rapide. Décrivez la tâche, pas l’écran.
- Copier un outil existant. « Comme notre outil actuel, mais en mieux » reproduit les contournements accumulés au fil des années. Demandez-vous pourquoi chaque étape existe.
- Oublier les volumes. 50 commandes par mois ou 5 000 par jour ne donnent pas le même outil. Indiquez les volumes actuels et attendus à trois ans.
- Passer sous silence les intégrations. Chaque échange avec l’ERP, le CRM ou la comptabilité est un chantier à part entière.
- Ignorer les cas particuliers. Ce sont eux qui consomment le temps de développement : avoirs, retours, multi-sociétés, droits d’accès fins.
- Rédiger sans les utilisateurs. Un document écrit uniquement par la direction décrit le processus théorique. Une heure passée à observer le travail réel corrige souvent des pages entières.
- Taire le budget et les échéances. Sans enveloppe indicative, chaque prestataire devine ; avec, il peut proposer un périmètre réaliste et dire ce qu’il ferait en premier.
- Viser l’exhaustivité. Un document de 80 pages donne une illusion de maîtrise, fige des choix prématurés et n’est relu par personne.
Que faire du cahier des charges une fois rédigé ?
Le document sert d’abord à consulter. Envoyez-le à trois ou quatre prestataires, avec une date limite et une liste de questions à leur poser ; notre article sur le choix d’une agence de développement en propose une. Les questions qu’ils vous renvoient sont un bon indicateur : un prestataire qui interroge vos cas particuliers a lu votre document, celui qui envoie un devis le lendemain sans question l’a moins lu.
Ensuite, le cahier des charges entre dans le cadrage. Les besoins y sont découpés en lots, illustrés par des maquettes, puis estimés plus finement. C’est à ce moment que se réduit l’incertitude d’une estimation, et donc que le budget devient fiable. Le document évolue : conservez-le à jour plutôt que de le laisser se périmer dans un dossier partagé.
La checklist avant envoi
Avant de diffuser votre cahier des charges, vérifiez ces points :
- Les objectifs sont vérifiables (un chiffre, un délai, une fréquence).
- Chaque profil d’utilisateur est décrit avec son nombre et son contexte de travail.
- Les outils existants et les données à reprendre sont listés, avec leurs volumes.
- Chaque besoin a un acteur, un exemple et une priorité.
- Les cas particuliers des processus principaux sont décrits.
- Chaque intégration précise la donnée, le sens et la fréquence.
- Les contraintes (sécurité, données personnelles, accessibilité, hébergement, échéances) sont explicites.
- Une enveloppe budgétaire indicative et un calendrier cible sont indiqués.
- Au moins deux futurs utilisateurs ont relu le document.
Vous n’avez pas encore de cahier des charges, ou vous voulez savoir si le vôtre suffit pour obtenir des devis fiables ? Partez de notre modèle gratuit, ou décrivez votre projet dans notre diagnostic en ligne : en deux minutes, vous saurez quelles questions restent à trancher avant de consulter.
