Le cahier des charges décrit ce que votre application web doit faire, pour qui et avec quelles contraintes. Plan type, méthode pour décrire les fonctionnalités et erreurs qui font déraper les projets.
Un cahier des charges d’application web décrit ce que l’application doit faire, pour qui, dans quelles conditions et avec quelles contraintes (budget, délais, sécurité, hébergement). Pour le rédiger : partez des objectifs et des utilisateurs, décrivez les fonctionnalités sous forme de parcours ou de « user stories », hiérarchisez-les, puis ajoutez les exigences techniques et les critères de validation. Il doit décrire des besoins, pas imposer des solutions techniques.
Un bon cahier des charges fait gagner du temps, de l’argent et beaucoup de malentendus : les prestataires peuvent chiffrer sur une base commune, et vous pouvez vérifier à la livraison que ce qui a été commandé a bien été réalisé. On détaille son rôle, sa structure type, la bonne façon de décrire les fonctionnalités et les erreurs qui font déraper les projets.
- À quoi sert un cahier des charges d’application web ?
- Quelle différence avec l’expression de besoin et les spécifications ?
- Que faut-il écrire dans un cahier des charges ?
- Comment décrire les fonctionnalités ?
- Quelles exigences techniques et réglementaires prévoir ?
- Quelles règles de rédaction suivre ?
- Quelles erreurs éviter ?
- Un cahier des charges est-il compatible avec un projet agile ?
- Questions fréquentes
- Sources
À quoi sert un cahier des charges d’application web ?
Le cahier des charges est le document de référence entre vous (le client, ou maître d’ouvrage) et l’équipe qui développe (le prestataire, ou maître d’œuvre). Il remplit trois rôles :
- Communiquer : plus le document est clair, plus la compréhension du projet par l’équipe de développement est rapide, en particulier lors de la première étape, l’analyse des exigences.
- Vous protéger : les développeurs ne lisent pas dans les pensées. Sans description précise, vous risquez de recevoir une application dont les écrans et les fonctionnalités ne correspondent pas à ce que vous aviez en tête, et de payer des modifications.
- Cadrer le travail des développeurs : une demande précise évite de deviner, donc de réécrire du code déjà livré. C’est aussi la base de comparaison des devis et de la recette (la phase de tests avant mise en ligne).
Rédiger un bon cahier des charges demande du temps. C’est pourtant moins coûteux que de corriger une incompréhension découverte après plusieurs semaines de développement : plus une erreur de besoin est découverte tard dans le cycle de vie du logiciel, plus elle coûte cher à corriger.
Quelle différence avec l’expression de besoin et les spécifications ?
Trois documents se succèdent souvent dans un projet, et sont souvent confondus :
| Document | Qui le rédige | Contenu | Quand |
|---|---|---|---|
| Expression de besoin | Le client | Le problème, les objectifs, les utilisateurs, les contraintes, en quelques pages | Avant de consulter des prestataires |
| Cahier des charges (fonctionnel) | Le client, souvent avec un accompagnement | Les fonctionnalités attendues, les parcours, les exigences de qualité, le budget, le planning | Pour obtenir des devis comparables |
| Spécifications fonctionnelles et techniques détaillées | Le prestataire, validées par le client | Les écrans, les règles de gestion, l’architecture, les choix techniques | Pendant le cadrage, avant le développement |
Si votre projet en est encore au stade de l’idée, commencez par une expression de besoin : elle est plus courte et suffit pour un premier échange avec des prestataires. En France, la démarche d’expression fonctionnelle du besoin et de cahier des charges fonctionnel est normalisée par la norme NF EN 16271, qui a remplacé l’ancienne norme NF X50-151. Vous n’êtes pas obligé de la suivre, mais son principe est utile : exprimer des besoins et des fonctions, pas des solutions.
Que faut-il écrire dans un cahier des charges ?
Voici un plan type, à adapter à la taille du projet. Pour une petite application, chaque partie peut tenir en quelques lignes.
- Sommaire et glossaire : les parties numérotées, puis la définition des abréviations et du vocabulaire métier. Un terme compris différemment par deux personnes suffit à créer un malentendu.
- Contexte et objectifs : qui vous êtes, pourquoi ce projet, quel problème il résout, et comment vous mesurerez le succès (temps gagné, nombre de commandes, réduction des erreurs de saisie…).
- Utilisateurs : qui utilisera l’application, dans quel contexte, sur quel appareil, à quelle fréquence. Distinguez les rôles (client, administrateur, commercial, partenaire) et leurs droits.
- Périmètre : ce qui est inclus, et surtout ce qui ne l’est pas. Une liste « hors périmètre » évite bien des discussions.
- Fonctionnalités : les parcours et fonctionnalités attendus, hiérarchisés (voir la section suivante).
- Contenus et données : quelles données sont saisies, importées ou échangées, qui les fournit, et s’il faut reprendre des données d’un ancien outil.
- Intégrations : les outils avec lesquels l’application doit communiquer (CRM, ERP, paiement, facturation, messagerie, cartographie), en précisant les informations échangées. Vous n’avez pas besoin de savoir ce qu’est une API : décrivez quelle information doit venir d’où et aller où.
- Design et ergonomie : charte graphique existante, exemples d’applications qui vous plaisent (et pourquoi), wireframes si vous en avez. Précisez si l’application doit fonctionner sur mobile, tablette et ordinateur.
- Exigences techniques et réglementaires : hébergement, sécurité, performances, RGPD, accessibilité (voir plus bas).
- Modèle économique si l’application est commercialisée : abonnement, paiement à l’acte, freemium, publicité.
- Budget et planning : une fourchette de budget et les dates clés (maquettes, version de test, mise en ligne). Donner un budget n’est pas un piège : c’est ce qui permet au prestataire de proposer la solution adaptée.
- Organisation : qui décide de votre côté, qui fournit les contenus, qui teste, à quel rythme se font les points d’avancement.
- Après la mise en ligne : maintenance, corrections, évolutions, hébergement, propriété du code source et des accès.
- Annexes : maquettes, organigramme des écrans, exemples de documents, captures de l’outil actuel.
Comment décrire les fonctionnalités ?
C’est le cœur du document. La méthode la plus lisible pour un non-développeur est la user story, une phrase construite ainsi : « En tant que [type d’utilisateur], je veux [action] afin de [bénéfice] ». Par exemple :
- En tant que client, je veux réserver un créneau en ligne afin de ne pas avoir à téléphoner.
- En tant qu’administrateur, je veux bloquer des créneaux pendant les congés afin d’éviter les réservations impossibles.
- En tant que client, je veux recevoir un rappel par e-mail la veille afin de ne pas oublier mon rendez-vous.
Ajoutez à chaque story ses critères d’acceptation : les conditions vérifiables qui diront si elle est terminée. Par exemple : « le rappel part à 18 h la veille ; il contient la date, l’heure, l’adresse et un lien d’annulation ; aucun rappel n’est envoyé si le rendez-vous a été annulé ».
Hiérarchisez ensuite. La méthode MoSCoW, créée par Dai Clegg en 1994, classe chaque fonctionnalité en quatre catégories : Must have (indispensable), Should have (important), Could have (souhaitable si le budget le permet) et Won’t have (pas pour cette version). Les « Must have » forment en général votre produit minimum viable : la première version que vous mettez entre les mains des utilisateurs.
Pensez aussi aux cas particuliers, souvent oubliés : que se passe-t-il sans connexion internet, en cas d’erreur de paiement, quand un utilisateur oublie son mot de passe, quand une donnée attendue d’un outil externe n’arrive pas ? Et pour chaque notification, dans quels cas elle se déclenche : informative, pas envahissante.
Quelles exigences techniques et réglementaires prévoir ?
Ce sont les exigences dites « non fonctionnelles » : elles ne décrivent pas ce que fait l’application, mais comment elle doit le faire.
- Performances et volumes : nombre d’utilisateurs simultanés attendus, volume de données, temps de réponse acceptable.
- Sécurité : gestion des comptes et des droits, authentification, sauvegardes, journalisation des actions sensibles.
- Données personnelles : l’article 25 du RGPD impose la protection des données dès la conception et par défaut. Listez les données personnelles collectées, leur finalité et leur durée de conservation, et ne collectez que ce qui est nécessaire.
- Accessibilité : depuis le 28 juin 2025, la directive européenne 2019/882 impose des exigences d’accessibilité à certains services en ligne, dont le commerce électronique, les microentreprises de services en étant exemptées. Même hors obligation, une application accessible est plus facile à utiliser pour tout le monde.
- Environnements : un serveur de préproduction pour tester, distinct du serveur de production.
- Compatibilité : navigateurs et appareils à prendre en charge, application web ou application mobile.
- Réversibilité : pouvoir récupérer vos données et votre code si vous changez de prestataire.
Quelles règles de rédaction suivre ?
- Soyez précis et mesurable. Évitez « rapide », « simple », « moderne ». Préférez « la recherche affiche les résultats en moins de deux secondes pour 10 000 fiches » ou « la commande se passe en trois écrans maximum ».
- Décrivez le besoin, pas la solution. « Les clients doivent pouvoir payer en ligne par carte » laisse au prestataire le choix de la meilleure solution. « Utiliser tel module » peut vous enfermer dans un mauvais choix.
- Un document, pas un forum. N’y posez pas de questions ouvertes du type « quelle serait la meilleure option ? ». Écrivez « à déterminer avec le prestataire » et traitez le point en réunion.
- Restez concis. N’incluez rien d’inutile : plus le projet est complexe, plus le détail est nécessaire, mais chaque ligne doit servir.
- Numérotez les exigences pour pouvoir y faire référence dans les devis, les échanges et la recette.
- Acceptez que le document évolue. Il sera enrichi lors des échanges avec l’équipe : versionnez-le et datez chaque modification.
- Faites-vous accompagner si besoin, par un profil technique de votre entreprise ou par un prestataire, lors d’une phase de cadrage.
Quelles erreurs éviter ?
- Tout mettre en priorité haute : si tout est indispensable, rien ne l’est, et le budget explose.
- Oublier l’administration : qui crée les comptes, modifie les contenus, exporte les données ? Le back-office représente souvent une part importante du travail.
- Passer sous silence la reprise de données d’un ancien fichier Excel ou logiciel.
- Ne pas donner de budget : vous recevrez des devis impossibles à comparer.
- Copier le cahier des charges d’un autre projet sans l’adapter à vos utilisateurs.
- Négliger l’après-lancement : maintenance, mises à jour de sécurité et hébergement ont un coût récurrent à prévoir.
Pour estimer le budget à indiquer, notre article sur le coût de développement d’une application web détaille les postes à prévoir.
Un cahier des charges est-il compatible avec un projet agile ?
Oui, à condition de ne pas le figer. En méthode agile, on développe par cycles courts et on ajuste les priorités au fil des retours. Le cahier des charges fixe alors le cap (objectifs, utilisateurs, contraintes, budget, fonctionnalités indispensables) et alimente le « backlog », la liste priorisée des user stories. Le détail de chaque fonctionnalité est précisé juste avant son développement, ce qui évite de spécifier pendant des semaines des éléments qui changeront.
Chez Osmova, on vous aide à décider quelles fonctionnalités doivent figurer dans la première version pour atteindre vos objectifs, puis on développe des applications web sur mesure à partir de ce cadrage. Si votre besoin consiste surtout à connecter des outils existants, notre service d’intégration et d’automatisation couvre aussi l’intégration API simple, avec un budget qui dépend du projet. Le premier contact se fait par e-mail à contact@osmova.com ou via notre formulaire de contact.
Questions fréquentes
Combien de pages doit faire un cahier des charges d’application web ?
Il n’y a pas de norme de longueur. Une petite application peut être décrite en une dizaine de pages ; un projet avec de nombreux rôles et intégrations en demande davantage. Le bon critère : un prestataire doit pouvoir chiffrer sans devoir deviner.
Qui doit rédiger le cahier des charges ?
Le client, car c’est lui qui connaît le métier et les utilisateurs. Il peut se faire accompagner par un consultant ou par le prestataire lors d’une phase de cadrage, qui produit ensuite les spécifications détaillées.
Faut-il des maquettes dans le cahier des charges ?
Ce n’est pas obligatoire, mais quelques croquis ou wireframes des écrans principaux (y compris connexion, menu et paramètres) aident beaucoup l’équipe à comprendre ce que vous voulez. Le détail visuel reste le travail du designer.
Cahier des charges fonctionnel ou technique : lequel rédiger ?
Côté client, rédigez le cahier des charges fonctionnel (ce que l’application doit faire). Ajoutez les contraintes techniques que vous connaissez (hébergement imposé, outils à connecter). Le détail technique est en général produit par le prestataire.
Peut-on modifier le cahier des charges en cours de projet ?
Oui, mais chaque modification doit être tracée et peut avoir un impact sur le coût et le délai. Datez les versions et faites valider les changements par les deux parties.
