Comment rédiger un cahier des charges pour une application web (avec modèle)

Vous contactez un prestataire pour développer une application sur-mesure, et la première question qu'on vous pose, c'est : "Envoyez-moi votre cahier des charges." Si vous n'en avez jamais rédigé, ça peut être intimidant. Par où commencer ? Quel niveau de détail ?

Un cahier des charges vague produit un devis vague. Et un devis vague, c'est un projet qui dérape en budget, en délais, parfois les deux en même temps. À l'inverse, un document structuré vous permet de comparer les prestataires sur les mêmes bases et de garder le contrôle sur ce qui est livré.

On passe en revue les huit sections d'un bon cahier des charges, avec un modèle à copier-coller à la fin.

À quoi sert un cahier des charges ? 📋

Un cahier des charges (souvent abrégé "CdC") sert à trois choses dans un projet d'application web.

D'abord, il aligne la vision. Quand plusieurs personnes participent au projet (fondateur, chef de projet, responsable métier), chacun a sa propre idée de ce que l'application doit faire. Le CdC pose les choses par écrit. Ce qui est écrit existe, ce qui ne l'est pas n'existe pas. Ça évite les "mais je pensais que…" trois mois plus tard.

Ensuite, il permet de comparer les devis. Si vous sollicitez plusieurs prestataires, un CdC commun leur donne le même cadre pour répondre. Sans ça, vous comparez des pommes et des oranges : l'un chiffre un périmètre large, l'autre un périmètre réduit, et les montants ne veulent plus rien dire.

Enfin, il sert de référence pendant le développement. "Est-ce que cette fonctionnalité était prévue ?" On ouvre le cahier des charges, on vérifie, on tranche. C'est aussi simple que ça.

Le CdC est idéalement rédigé après une phase de cadrage de projet qui permet de clarifier les besoins. Mais même si vous partez de zéro, un document structuré vaut mieux que rien.

Les 8 sections d'un bon cahier des charges 🧩

Un cahier des charges complet couvre huit thématiques. Voici le résumé avant d'entrer dans le détail :

1. Présentation du projet

C'est la mise en contexte. Le prestataire doit comprendre qui vous êtes, ce que fait votre entreprise, et pourquoi vous avez besoin de cette application. Un ou deux paragraphes suffisent.

Un exemple. Une PME de logistique gère ses plannings de livraison avec des tableurs Excel partagés entre trois agences. Les fichiers se désynchronisent, les chauffeurs reçoivent des consignes contradictoires, et le service client passe son temps à vérifier les statuts par téléphone. L'objectif : remplacer ces tableurs par une application web qui centralise la planification.

Ce type de description donne au prestataire le contexte métier dont il a besoin. Il comprend le problème, il comprend l'environnement, il peut commencer à réfléchir.

Mentionnez aussi l'existant : quels outils utilisez-vous aujourd'hui ? Qu'est-ce qui fonctionne, qu'est-ce qui ne fonctionne plus ? Ces informations orientent la suite.

2. Objectifs et indicateurs de succès

Un objectif sans indicateur mesurable, c'est un vœu pieux. "Améliorer la productivité" ne veut pas dire grand-chose. "Réduire le temps de traitement des commandes de 40 %", ça se vérifie.

Associez chaque objectif à un indicateur chiffré :

Ces indicateurs serviront aussi après le lancement pour mesurer si le projet a tenu ses promesses. Sans eux, vous n'avez aucun moyen de savoir si l'investissement a porté ses fruits.

3. Public cible et utilisateurs

Qui va utiliser l'application ? La réponse change tout. Un outil pour des comptables sur grand écran ne se conçoit pas de la même façon qu'une application pour des techniciens de terrain sur smartphone.

Pour chaque profil d'utilisateur, précisez :

• Les rôles : administrateur, gestionnaire, utilisateur standard, client externe…
• Le volume : combien d'utilisateurs simultanés ? 10, 100, 10 000 ?
• Le niveau technique : des gens habitués aux interfaces complexes, ou des utilisateurs qui découvrent le numérique ?
• Le contexte d'utilisation : au bureau sur un poste fixe, en déplacement sur mobile, dans un entrepôt avec des gants ?

Un prestataire qui connaît bien vos utilisateurs fera de meilleurs choix d'interface.

4. Périmètre fonctionnel

C'est la section la plus dense du document. Ici, vous listez ce que l'application doit faire concrètement.

Pour chaque module, détaillez les fonctionnalités et attribuez-leur un niveau de priorité. La méthode MoSCoW fonctionne bien pour ça : chaque fonctionnalité est classée en Must Have (indispensable), Should Have (important mais pas bloquant), Could Have (si le budget le permet) ou Won't Have (explicitement exclu).

Prioriser, c'est accepter que tout ne sera pas dans la première version. Le but est de livrer un MVP fonctionnel, puis d'itérer.

Soyez précis dans les descriptions. "Gestion des utilisateurs" peut vouloir dire beaucoup de choses. "Créer, modifier, désactiver un compte utilisateur et lui attribuer un rôle parmi admin, gestionnaire et chauffeur" est bien plus exploitable pour un devis.

Un projet d'application web en tête ?

On vous aide à cadrer vos besoins, structurer votre cahier des charges et passer du besoin au prototype.

Planifier un RDV

5. Contraintes techniques

Même si vous n'êtes pas développeur, certaines contraintes techniques sont de votre ressort. Le prestataire a besoin de les connaître dès le départ pour éviter les mauvaises surprises en cours de route.

• Hébergement : des exigences particulières ? Hébergement en France pour la conformité RGPD ? Cloud ou serveur dédié ?
• Intégrations : l'application doit-elle se connecter à un ERP, un CRM, une solution de paiement, une API tierce ?
• Navigateurs et appareils : quels navigateurs supporter ? L'application doit-elle fonctionner sur mobile ?
• Performance : des attentes sur les temps de chargement ou le nombre d'utilisateurs simultanés ?
• Sécurité : des données sensibles à protéger ? Des certifications à respecter (ISO 27001, HDS pour la santé) ?

Si vous voulez comprendre les options techniques, l'article sur le choix du langage de développement peut vous aider. Sinon, laissez le prestataire faire sa recommandation.

6. Design et ergonomie

Le design sera travaillé en détail lors de la phase de prototypage. Mais le cahier des charges doit poser les bases :

• Charte graphique : avez-vous des couleurs, une typographie, un logo à respecter ?
• Références visuelles : y a-t-il des applications dont vous aimez l'interface ? Fournissez des captures d'écran ou des liens.
• Responsive : l'application doit-elle s'adapter au mobile et à la tablette, ou uniquement au desktop ?
• Accessibilité : des exigences RGAA ou WCAG à respecter ?

Même quelques wireframes dessinés à la main aident le prestataire à comprendre ce que vous avez en tête. Pas besoin que ce soit joli, il faut que ce soit lisible.

7. Planning et jalons

Indiquez les dates qui comptent pour vous. Un planning réaliste aide le prestataire à organiser son travail et à repérer les risques de retard en amont.

Les jalons qu'on retrouve dans la plupart des projets web :

• Cadrage et spécifications : finalisation du périmètre détaillé
• Maquettes et prototype : validation de l'interface avant développement
• Développement : itérations successives avec démos intermédiaires
• Recette : tests et corrections avant mise en production
• Mise en production : lancement de l'application
• Garantie : période de correction des anomalies post-lancement

Si vous avez une date butoir (un salon, un lancement commercial, une obligation réglementaire), dites-le. Elle conditionne tout le reste.

8. Budget

La question du budget met souvent mal à l'aise. Beaucoup de porteurs de projet préfèrent ne pas communiquer de chiffre, de peur que le prestataire "gonfle" le devis pour atteindre l'enveloppe. En pratique, c'est le contraire qui se passe.

Un prestataire qui ne connaît pas votre budget va soit viser trop haut (et vous perdez du temps), soit proposer une solution low-cost qui ne correspond pas à vos attentes. Partager une fourchette, même large, permet d'orienter la proposition vers quelque chose de réaliste.

Vous n'avez pas besoin d'annoncer un montant exact. Une fourchette du type "entre 30 000 € et 50 000 €" suffit à cadrer les échanges. Le prestataire pourra proposer une première version dans la fourchette basse, avec des options pour aller plus loin.

Précisez aussi le modèle de tarification que vous privilégiez : forfait, régie, ou un mix des deux. Et si le budget inclut la maintenance et l'hébergement, ou uniquement le développement initial.

Modèle de cahier des charges prêt à l'emploi 📄

Voici un modèle à copier-coller et adapter. Remplacez les exemples entre crochets par vos propres informations.

# Cahier des charges — [Nom du projet]
 
## 1. Présentation du projet
 
**Entreprise** : [Nom, secteur d'activité, taille]
**Contexte** : [Décrivez la situation actuelle et le problème à résoudre]
**Existant** : [Outils utilisés aujourd'hui, ce qui fonctionne et ce qui ne fonctionne plus]
**Vision** : [En une phrase, à quoi ressemble le succès de ce projet ?]
 
## 2. Objectifs et indicateurs de succès
 
| Objectif | Indicateur | Cible |
|----------|-----------|-------|
| [Objectif 1] | [KPI mesurable] | [Valeur cible] |
| [Objectif 2] | [KPI mesurable] | [Valeur cible] |
| [Objectif 3] | [KPI mesurable] | [Valeur cible] |
 
## 3. Utilisateurs
 
| Rôle | Description | Volume estimé | Niveau technique |
|------|-------------|---------------|------------------|
| [Admin] | [Gère les paramètres et les utilisateurs] | [2-3] | [Élevé] |
| [Utilisateur] | [Utilise l'application au quotidien] | [50-100] | [Moyen] |
| [Client] | [Consulte son espace personnel] | [500+] | [Faible] |
 
**Contexte d'utilisation** : [Bureau / Mobile / Terrain / Mixte]
 
## 4. Fonctionnalités
 
| Module | Fonctionnalité | Priorité | Détail |
|--------|---------------|----------|--------|
| [Module 1] | [Fonctionnalité] | Must Have | [Description précise] |
| [Module 1] | [Fonctionnalité] | Should Have | [Description précise] |
| [Module 2] | [Fonctionnalité] | Must Have | [Description précise] |
| [Module 2] | [Fonctionnalité] | Could Have | [Description précise] |
| [Module 3] | [Fonctionnalité] | Won't Have | [Raison de l'exclusion] |
 
**Priorités MoSCoW** :
- **Must Have** : indispensable pour la V1
- **Should Have** : important, prévu si le budget le permet
- **Could Have** : souhaitable, reportable
- **Won't Have** : exclu de ce projet
 
## 5. Contraintes techniques
 
- **Hébergement** : [Cloud / Serveur dédié / France obligatoire / Autre]
- **Intégrations** : [ERP, CRM, API tierces à connecter]
- **Navigateurs** : [Chrome, Firefox, Safari, Edge — versions minimales]
- **Mobile** : [Responsive obligatoire / Application native / PWA]
- **Performance** : [Temps de chargement max, utilisateurs simultanés]
- **Sécurité** : [RGPD, certifications, données sensibles]
- **Stack technique** : [Préférence ou contrainte, sinon "à la discrétion du prestataire"]
 
## 6. Design et ergonomie
 
- **Charte graphique** : [Lien vers le brand book ou fichiers joints]
- **Références visuelles** : [URLs ou captures d'écran d'interfaces appréciées]
- **Responsive** : [Oui / Non — quels appareils]
- **Accessibilité** : [RGAA / WCAG AA / Pas d'exigence spécifique]
- **Wireframes** : [Joints en annexe / À réaliser par le prestataire]
 
## 7. Planning
 
| Jalon | Date souhaitée |
|-------|---------------|
| Réponse des prestataires | [Date] |
| Choix du prestataire | [Date] |
| Cadrage et spécifications | [Date] |
| Maquettes et prototype | [Date] |
| Développement | [Date début — Date fin] |
| Recette | [Date] |
| Mise en production | [Date] |
 
**Date butoir** : [Date impérative et raison, ou "flexible"]
 
## 8. Budget
 
- **Enveloppe** : [Fourchette budgétaire]
- **Modèle** : [Forfait / Régie / Mixte]
- **Inclus** : [Développement uniquement / Maintenance incluse / Hébergement inclus]
- **Facturation** : [Modalités souhaitées : acompte, jalons, mensuel]

Ce modèle n'est pas rigide. Ajoutez des sections si votre projet le demande, retirez celles qui ne s'appliquent pas.

Un conseil : commencez par les sections que vous maîtrisez (présentation, objectifs, utilisateurs). Les sections plus techniques peuvent se remplir avec votre équipe ou lors d'un premier échange avec le prestataire.

Les erreurs qui plombent un cahier des charges ⚠️

Rester trop vague

"L'interface doit être intuitive." C'est le type de phrase qu'on retrouve dans neuf cahiers des charges sur dix, et qui ne veut rien dire. Intuitive pour qui ? Dans quel contexte ? Avec quel niveau de compétence ?

Remplacez les adjectifs creux par des comportements observables. Au lieu de "intuitif", écrivez : "Un nouvel utilisateur doit pouvoir créer sa première commande en moins de 3 minutes, sans aide." Ça, un prestataire sait quoi en faire.

Décrire la solution au lieu du problème

"Il faut un bouton vert en haut à droite qui ouvre un menu déroulant avec trois options." Ce type de description prescrit une solution technique sans expliquer le besoin. Le prestataire n'a aucune marge pour proposer mieux.

Décrivez plutôt le problème : "L'utilisateur doit pouvoir passer rapidement entre ses commandes en cours, ses commandes archivées et ses brouillons." Le prestataire trouvera peut-être une meilleure solution que votre menu déroulant : des onglets, un filtre, une barre latérale.

Oublier les utilisateurs

Un cahier des charges qui ne mentionne jamais les utilisateurs finaux décrit une application pour personne. Qui va s'en servir, et dans quel contexte ? Sans cette information, le prestataire conçoit dans le vide.

Ne pas prioriser

Quand tout est prioritaire, rien ne l'est. Si votre liste de fonctionnalités ne distingue pas ce qui est indispensable de ce qui est accessoire, le prestataire va devoir tout chiffrer comme si c'était obligatoire. Le budget explose, les délais avec.

Utilisez la méthode MoSCoW ou un système équivalent. Classez chaque fonctionnalité, et assumez que certaines choses attendront la V2.

Et après le cahier des charges ? 🚀

Une fois le CdC rédigé, voici la suite des opérations :

1. Transmettez-le à deux ou trois prestataires pour obtenir des propositions comparables.
2. Comparez les réponses sur le périmètre, le planning, le budget et l'approche technique.
3. Le prestataire retenu reprend le CdC et le transforme en spécifications techniques lors d'une phase de cadrage de projet.
4. Les maquettes et le prototype permettent de valider l'interface avant d'écrire la moindre ligne de code.
5. Le développement démarre, avec des livraisons régulières et des retours à chaque étape.

L'article créer votre logiciel sur-mesure détaille tout ce parcours si vous voulez aller plus loin.

Un cahier des charges n'a pas besoin d'être parfait. Il doit être suffisamment précis pour que deux personnes qui le lisent comprennent la même chose. Si c'est le cas, vous avez fait le plus dur. Et si vous voulez un regard extérieur avant de l'envoyer, parlons-en.