Cahier des charges application web : guide complet + modèle

TL;DR

• Un cahier des charges (CDC) est le document de référence que vous remettez à votre développeur avant tout devis : il décrit votre projet, vos fonctionnalités, vos contraintes techniques et vos critères de succès.
• Son vrai rôle : mettre les deux parties d'accord sur le même périmètre. Il sert de point de référence commun en cas de désaccord en cours de projet.
• Sans CDC, les devis varient du simple au triple et le développeur livre souvent autre chose que ce que vous aviez en tête.
• Un bon CDC pour une application web couvre 8 sections clés : contexte, périmètre fonctionnel, contraintes techniques, UX/UI, sécurité/RGPD, budget, planning et critères d'acceptation.
• Inutile de viser un document de 30 pages : pour la plupart des projets, une liste à puces claire des fonctionnalités requises suffit. Visez l'exhaustivité, pas le volume.
• Vous n'avez pas besoin de compétences techniques pour le rédiger : une formulation claire en langage métier suffit.
• L'IA aide à rédiger un CDC plus vite, mais sans direction elle ajoute des fioritures et des fonctionnalités inutiles. Gardez la main sur le périmètre.
• Une fois votre CDC prêt, vous pouvez choisir entre no-code/IA, agence, freelance ou une offre packagée selon votre budget et vos délais.

---

Pourquoi rédiger un cahier des charges avant de recruter

La plainte la plus fréquente des fondateurs après un premier projet web : "le développeur a livré autre chose que ce que j'avais en tête". Ce n'est pas forcément la faute du développeur.

Sans document de référence, chaque prestataire interprète votre idée à sa façon. L'un chiffre 8 000 €, l'autre 35 000 €. Les deux ont raison : ils n'ont pas compris le même projet.

Avec un CDC, vous obtenez :

• Des devis comparables sur un périmètre identique
• Un périmètre clair qui évite les demandes de modifications non prévues (le fameux scope creep)
• Une livraison plus rapide, car le développeur ne perd pas de temps à deviner vos intentions
• Un document de référence en cas de désaccord

Sans CDC, vous risquez :

• Des surcoûts liés aux allers-retours et aux fonctionnalités mal comprises
• Des délais allongés par les questions répétitives
• Une application qui ne correspond pas à vos besoins métier réels

Rédiger un CDC prend entre 2 et 10 heures selon la complexité du projet. C'est le meilleur investissement avant de dépenser quoi que ce soit en développement.

---

Un cahier des charges n'a pas besoin d'être compliqué

Avant de détailler les sections, une mise au point : un cahier des charges ne doit pas vous faire peur, et il n'a pas besoin d'être un pavé de 30 pages.

La taille du CDC dépend de l'enjeu du projet. Pour un projet à 100 000 €, un cahier des charges détaillé est un investissement évident : il cadre un budget important et plusieurs mois de travail. Mais pour la majorité des projets web, une simple liste à puces claire des fonctionnalités requises suffit largement. L'important n'est pas le volume, c'est l'exhaustivité : avez-vous listé tout ce dont vous avez réellement besoin ?

Acceptez que tout ne sera pas prévu d'avance. Dans n'importe quel projet web, vous découvrez des choses en cours de route : un cas d'usage oublié, une contrainte technique qui change la donne, un retour utilisateur qui invalide une hypothèse. C'est précisément pour cette raison que les méthodes en cascade (waterfall), où tout est figé dès le départ, échouent si souvent. Les méthodes agiles ont été inventées pour ça : des sprints courts (souvent deux semaines), des cahiers des charges plus légers et des ajustements réguliers. Un bon CDC vise l'exhaustivité, mais il reste un document vivant.

Le vrai rôle du CDC : se mettre d'accord. Au fond, le cahier des charges sert surtout à aligner les deux parties, vous et votre prestataire, sur le même périmètre. C'est un point de référence commun : en cas de désaccord ou de litige en cours de projet, c'est le document qui tranche. Voyez-le moins comme une spécification gravée dans le marbre que comme un contrat de confiance entre vous et votre développeur.

---

Les 8 sections indispensables d'un cahier des charges application web

1. Contexte et objectifs du projet

Décrivez votre entreprise en 3 ou 4 phrases, le problème que vous résolvez et ce que l'application doit accomplir concrètement.

Exemple : "Notre startup propose une plateforme de mise en relation entre artisans et particuliers. L'objectif de l'application est de permettre aux artisans de gérer leurs devis en ligne et aux clients de suivre l'avancement de leurs travaux en temps réel. Indicateur de succès : 500 artisans inscrits dans les 6 premiers mois."

Précisez aussi : qui sont vos utilisateurs cibles, quel est le modèle économique (SaaS, marketplace, outil interne) et si l'application est un MVP ou une refonte.

2. Périmètre fonctionnel (user stories ou liste de fonctionnalités)

C'est la section la plus importante. Listez toutes les fonctionnalités attendues, idéalement sous forme de user stories : "En tant que [rôle], je veux [action] afin de [bénéfice]."

Exemple :

• En tant qu'artisan, je veux créer un devis en ligne afin de l'envoyer directement au client par email.
• En tant qu'administrateur, je veux voir le tableau de bord des inscriptions afin de suivre la croissance.

Distinguez les fonctionnalités indispensables (MVP) des fonctionnalités souhaitables (V2). Cela aide le développeur à prioriser et vous évite de payer pour des fonctionnalités non essentielles dès le départ. Une liste à puces priorisée est déjà un excellent point de départ. Pour aller plus loin sur ce sujet, consultez notre article sur le MVP.

3. Contraintes techniques (stack, hébergement, intégrations)

Précisez les contraintes que vous avez déjà identifiées :

• Stack technologique : avez-vous une préférence (React, Next.js, Vue) ou laissez-vous le choix au développeur ?
• Hébergement : Vercel, AWS, OVH, hébergement mutualisé ?
• Intégrations tierces : Stripe pour les paiements, Twilio pour les SMS, une API existante de votre CRM, un ERP interne ?
• Compatibilité : l'application doit-elle s'intégrer à un outil existant ?

Si vous n'avez pas de préférence technique, dites-le clairement. Un bon développeur vous proposera la stack adaptée à votre cas d'usage.

4. Exigences UX/UI (wireframes, charte graphique, responsive)

Décrivez le niveau de finition attendu :

• Avez-vous déjà une charte graphique (logo, couleurs, typographies) ?
• Des wireframes ou maquettes Figma sont-ils fournis, ou le développeur doit-il les créer ?
• L'application doit-elle être responsive (mobile, tablette, ordinateur) ?
• Y a-t-il des références visuelles (applications existantes dont vous aimez l'interface) ?

Joindre des captures d'écran d'applications que vous appréciez vaut souvent mieux qu'un long paragraphe descriptif.

5. Sécurité et conformité (RGPD, authentification, rôles)

Ce point est systématiquement sous-estimé, surtout pour les startups. Pourtant, depuis 2026, la CNIL intensifie ses contrôles sur les petites structures et les sanctions peuvent atteindre 20 millions d'euros ou 4 % du chiffre d'affaires annuel.

Précisez dans votre CDC :

• Authentification : email/mot de passe, OAuth (Google, GitHub), SSO, MFA ?
• Gestion des rôles : qui peut voir quoi ? (admin, utilisateur standard, invité)
• Données personnelles collectées : emails, numéros de téléphone, données de paiement ?
• Conformité RGPD : bandeau cookies, politique de confidentialité, droit à l'effacement
• Hébergement des données : en Europe obligatoirement si vous traitez des données de résidents européens

La ressource officielle de référence sur ce sujet reste le site de la CNIL.

6. Budget et fourchette de prix

Indiquer votre budget n'est pas une faiblesse : c'est un filtre efficace. Un développeur qui sait que vous avez 15 000 € ne vous proposera pas une architecture à 80 000 €.

Donnez une fourchette réaliste. Pour vous aider à calibrer, consultez notre article sur les fourchettes de prix 2026.

Précisez aussi si le budget inclut le design, les licences de services tiers (Stripe, Twilio) et la maintenance après le lancement.

7. Planning et jalons

Indiquez :

• La date de lancement souhaitée (et si elle est fixe ou flexible)
• Les jalons intermédiaires attendus : maquettes validées, version bêta, mise en production
• La disponibilité de votre côté pour les retours et validations

Un planning irréaliste est l'une des premières causes de friction avec un prestataire. Soyez honnête sur vos contraintes.

8. Critères d'acceptation et tests

Comment saurez-vous que l'application est "finie" ? Définissez des critères précis :

• "Le formulaire d'inscription envoie bien un email de confirmation dans les 30 secondes."
• "Le paiement Stripe fonctionne en mode test avec une carte de test 4242 4242 4242 4242."
• "L'application charge en moins de 3 secondes sur une connexion 4G."

Ces critères deviennent la base de la recette : la phase de validation avant de payer le solde.

---

CDC léger ou CDC complet : que choisir ?

Pour un premier MVP, un CDC léger suffit largement. L'objectif est de valider l'idée, pas de tout spécifier à l'avance.

---

Les erreurs les plus fréquentes (et comment les éviter)

Être trop vague sur les fonctionnalités. "Une interface intuitive" ou "un tableau de bord complet" ne veulent rien dire pour un développeur. Décrivez chaque fonctionnalité avec un verbe d'action et un résultat attendu.

Oublier les cas limites et les erreurs. Que se passe-t-il si un utilisateur entre un email déjà existant ? Si le paiement échoue ? Si la session expire ? Ces cas représentent souvent 30 % du travail de développement.

Ne pas préciser les intégrations tierces. Stripe, Auth0, une API de cartographie, un webhook Zapier : chaque intégration représente plusieurs jours de travail supplémentaires. Si vous les oubliez dans le CDC, elles apparaîtront en "extra" sur la facture.

Confondre CDC et maquette. Le CDC décrit ce que l'application fait. La maquette montre comment elle le fait visuellement. Les deux sont complémentaires, mais ce n'est pas la même chose. Un CDC sans maquette est acceptable ; une maquette sans CDC laisse trop de zones grises.

Ne pas inclure de critères d'acceptation. Sans définition claire du "fini", chaque partie a sa propre interprétation. Résultat : des litiges en fin de projet sur ce qui était "inclus" ou non.

Sous-estimer la partie sécurité et RGPD. Beaucoup de fondateurs ajoutent "conformité RGPD" comme une case à cocher en fin de projet. C'est une erreur. La gestion des consentements, des rôles et du chiffrement des données doit être pensée dès l'architecture.

Tout déléguer à l'IA. L'IA peut vous aider à rédiger un cahier des charges plus vite, et c'est une bonne chose. Mais utilisée sans direction, elle a tendance à ajouter des fioritures : des fonctionnalités que vous n'avez pas demandées, des sections inutiles, parce qu'elle cherche à produire un document "complet". Le résultat est un CDC gonflé qui fait grimper les devis pour des fonctionnalités dont vous n'avez pas besoin. L'IA ne connaît ni votre métier ni les enjeux réels du projet : elle est un bon copilote, jamais le pilote.

---

Modèle de cahier des charges (à copier-coller)

Voici un modèle prêt à copier et adapter. Remplacez les textes entre crochets par vos informations.

# Cahier des charges : [Nom du projet]
Version : 1.0 | Date : [JJ/MM/AAAA] | Auteur : [Votre nom]

---

### 1. Contexte et objectifs

Présentation de l'entreprise :
[Décrivez votre activité en 2 ou 3 phrases.]

Problème résolu :
[Quel problème concret votre application résout-elle ?]

Objectif principal de l'application :
[Ex : permettre aux utilisateurs de réserver un service en ligne sans appel.]

Indicateurs de succès :
- [Ex : 200 utilisateurs actifs dans les 3 premiers mois]
- [Ex : taux de conversion du formulaire supérieur à 15 %]

Type d'application : [ ] MVP  [ ] Refonte  [ ] Nouvelle fonctionnalité
Modèle économique : [ ] SaaS  [ ] Marketplace  [ ] Outil interne  [ ] Autre

---

### 2. Périmètre fonctionnel

Fonctionnalités indispensables (MVP)

| # | User story | Priorité |
|---|---|---|
| 1 | En tant que [rôle], je veux [action] afin de [bénéfice]. | Haute |
| 2 | ... | Haute |

Fonctionnalités souhaitables (V2)

| # | User story | Priorité |
|---|---|---|
| 1 | ... | Moyenne |

---

### 3. Contraintes techniques

Stack souhaitée : [Ex : Next.js + PostgreSQL, ou "au choix du développeur"]
Hébergement : [Ex : Vercel, AWS, OVH]
Intégrations tierces :
- Paiement : [Ex : Stripe]
- Authentification : [Ex : Auth0, NextAuth]
- Emails transactionnels : [Ex : Resend, SendGrid]
- Autres API : [listez-les]

Contraintes de performance : [Ex : chargement en moins de 2 s, 500 utilisateurs simultanés]

---

### 4. Exigences UX/UI

Charte graphique disponible : [ ] Oui  [ ] Non
Maquettes fournies : [ ] Oui (Figma)  [ ] Non (à créer)
Responsive : [ ] Ordinateur uniquement  [ ] Ordinateur + Mobile  [ ] Mobile first
Références visuelles : [Liens vers des applications dont vous aimez l'interface]

---

### 5. Sécurité et conformité

Authentification : [ ] Email/MDP  [ ] OAuth Google  [ ] SSO  [ ] MFA
Gestion des rôles :
- Rôle 1 : [Admin] : peut [lister les permissions]
- Rôle 2 : [Utilisateur] : peut [lister les permissions]

Données personnelles collectées : [Ex : email, nom, numéro de téléphone]
Conformité RGPD : [ ] Bandeau cookies  [ ] Politique de confidentialité  [ ] Droit à l'effacement
Hébergement des données : [ ] Europe  [ ] Autre (préciser)

---

### 6. Budget

Fourchette de budget : [Ex : 8 000 € - 12 000 €]
Le budget inclut : [ ] Design  [ ] Licences tierces  [ ] Maintenance 3 mois
Le budget exclut : [précisez]

---

### 7. Planning

Date de lancement souhaitée : [JJ/MM/AAAA]
Jalons :
- Maquettes validées : [date]
- Version bêta : [date]
- Mise en production : [date]

Disponibilité pour les retours : [Ex : 2 à 3 heures par semaine, réponse sous 48 h]

---

### 8. Critères d'acceptation

- [ ] [Fonctionnalité X] fonctionne sur Chrome, Firefox et Safari (dernières versions)
- [ ] Le formulaire d'inscription envoie un email de confirmation en moins de 30 secondes
- [ ] Le paiement Stripe fonctionne avec la carte de test 4242 4242 4242 4242
- [ ] L'application est responsive sur mobile (iPhone 14, Samsung Galaxy S23)
- [ ] Aucune donnée personnelle n'est stockée sans consentement explicite

---

### Annexes

- Maquettes Figma : [lien]
- Charte graphique : [lien ou fichier joint]
- Documentation API tierce : [lien]
- Exemples d'applications de référence : [liens]

---

Quel prestataire choisir après avoir rédigé votre CDC ?

Votre CDC est prêt. Maintenant, à qui le confier ?

No-code et IA (Bubble, Lovable, v0)

Ces outils permettent de construire une application sans écrire de code, et ils ont beaucoup mûri. Ils sont excellents pour valider une idée rapidement et, pour des applications relativement standard (formulaires, tableaux de bord, workflows métier), ils peuvent très bien tenir sur la durée. C'est souvent le choix le plus malin quand vous démarrez avec un budget serré.

Leur limite n'est pas une question de qualité, c'est une question de périmètre. Dès que vous avez besoin d'une authentification multi-tenant fine, d'une logique de paiement avancée, d'une API sur mesure ou de performances élevées, vous sortez de leur zone de confort. C'est là qu'un développement sur mesure reprend l'avantage. L'idéal est souvent de démarrer en no-code, puis de basculer quand le produit le justifie.

Agence web

Une agence offre une équipe complète (chef de projet, designers, développeurs, testeurs). C'est adapté aux projets complexes avec un budget supérieur à 20 000 €. Comptez entre 2 et 6 mois de délai, et entre 20 000 € et 80 000 € selon la complexité.

L'inconvénient : les interlocuteurs changent, la communication est souvent moins directe, et les coûts de gestion de projet s'ajoutent au développement réel.

Développeur freelance

Plus direct, plus flexible, souvent moins cher qu'une agence pour un périmètre équivalent. Idéal pour les startups qui ont un CDC clair et veulent avancer vite. Le risque principal : la disponibilité et la fiabilité varient beaucoup d'un freelance à l'autre.

Pour un développement d'application web sur mesure avec un développeur senior, comptez entre 500 € et 900 € par jour selon l'expérience et la stack.

Offre packagée type Startup Express

Si vous avez un MVP bien défini et un budget autour de 7 000 €, une offre à périmètre fixe est souvent la solution la plus efficace. L'offre Startup Express, MVP en 10 jours est conçue exactement pour ce cas : un périmètre clair, un délai garanti, sans les aléas d'un projet en régie.

C'est adapté si votre CDC léger est prêt, que vous avez besoin d'une première version fonctionnelle rapidement, et que vous voulez éviter les mois de négociation avec une agence.

---

FAQ

Combien de pages fait un cahier des charges pour une application web ?

Un CDC léger pour un MVP fait entre 3 et 5 pages. Un CDC complet pour un projet établi peut atteindre 15 à 20 pages. La longueur n'est pas un gage de qualité : un CDC de 4 pages bien structuré vaut mieux qu'un document de 30 pages vague et répétitif. Pour beaucoup de projets, une liste à puces priorisée des fonctionnalités est déjà suffisante.

Faut-il des compétences techniques pour rédiger un cahier des charges ?

Non. Le CDC est un document métier, pas technique. Vous décrivez ce que l'application doit faire, pas comment elle le fait. Utilisez un langage simple, des user stories et des exemples concrets. Le développeur traduit ensuite en spécifications techniques.

Quelle est la différence entre un cahier des charges et des spécifications techniques ?

Le CDC décrit les besoins fonctionnels et les objectifs métier : c'est vous qui le rédigez. Les spécifications techniques décrivent l'architecture, les modèles de données et les choix d'implémentation : c'est le développeur qui les produit, à partir de votre CDC. Les deux documents sont complémentaires.

Peut-on rédiger un cahier des charges avec l'IA ?

Oui, l'IA est un bon copilote pour structurer vos idées et aller plus vite. ChatGPT ou Claude peuvent vous aider à formuler vos user stories, repérer des cas limites oubliés ou reformuler des sections floues. Attention toutefois à un piège : livrée à elle-même, l'IA cherche à produire un document "complet" et ajoute volontiers des fonctionnalités et des sections que vous n'avez jamais demandées. Ces fioritures gonflent inutilement le périmètre, et donc les devis. L'IA ne connaît ni votre métier ni les enjeux réels du projet : elle génère une structure, c'est à vous (ou à quelqu'un qui comprend bien le projet) d'apporter et de filtrer le contenu. Relisez toujours le résultat avec votre regard métier et coupez ce qui n'est pas nécessaire.

Combien coûte la rédaction d'un cahier des charges par un consultant ?

Un consultant spécialisé (product manager freelance ou consultant fonctionnel) facture généralement entre 800 € et 2 500 € pour rédiger un CDC complet. Pour un CDC léger, certains développeurs l'incluent dans une phase de cadrage à 500-800 €. Pour un MVP simple, vous pouvez tout à fait le rédiger vous-même en utilisant le modèle de cet article.

Mon cahier des charges est prêt : quelle est la prochaine étape ?

Envoyez votre CDC à 2 ou 3 prestataires pour obtenir des devis comparables. Pour identifier les bons candidats, consultez notre guide pour trouver un développeur freelance fiable. Évaluez non seulement le prix, mais aussi la clarté des questions posées en retour (un bon développeur pose des questions précises), les délais proposés et les références sur des projets similaires. Si vous avez un MVP bien délimité et souhaitez avancer vite, l'offre Startup Express, MVP en 10 jours est faite pour vous.

---

Sources utiles

• CNIL : le RGPD, de quoi parle-t-on ? : référence officielle sur la conformité RGPD pour les applications web
• CNIL : la sécurité des données personnelles : recommandations techniques pour l'authentification, le chiffrement et la gestion des accès
• Atlassian : guide des user stories : méthodologie et exemples concrets pour rédiger des user stories efficaces
• Fondation Afnic : livre blanc cahier des charges : modèle de cahier des charges pour plateforme web, téléchargeable gratuitement