Cahier des charges d’une application web : les rubriques à prévoir

Le cahier des charges d’une application web décrit ce que l’application doit permettre de faire, pour qui et sous quelles contraintes, avant qu’un prestataire propose une solution. Il sert à consulter, à cadrer le contrat, puis à recetter. Ce guide dit ce qui le distingue d’une spécification technique, les rubriques à prévoir, comment écrire des exigences vérifiables et les erreurs qui coûtent cher ensuite.

Il s’adresse aux dirigeants, aux DSI et aux chefs de produit qui préparent le développement d’une application web sur mesure : un portail client, un outil métier, une plateforme. Un site vitrine demande un document plus léger ; les principes restent les mêmes.

Qu’est-ce qu’un cahier des charges d’application web ?

Un cahier des charges d’application web est le document par lequel une entreprise exprime son besoin avant de faire développer une application : les utilisateurs, ce qu’ils doivent pouvoir faire, les contraintes à respecter et les critères qui diront si le résultat convient. Il précède le choix d’une solution et sert de référence tout au long du projet.

La norme NF EN 16271, publiée par l’AFNOR en 2013 en remplacement de la norme française NF X50-151, définit le cahier des charges fonctionnel comme l’expression du besoin en termes de fonctions de service et de contraintes. Pour chaque fonction, elle demande des critères d’appréciation, avec un niveau attendu et sa flexibilité : ce qui se négocie et ce qui ne se négocie pas.

Le document sert trois fois : pour consulter des prestataires sur une base commune et comparer leurs réponses, pour cadrer le contrat, puis pour recetter, c’est-à-dire vérifier à la livraison que ce qui était demandé est bien là.

Cahier des charges fonctionnel ou technique : quelle différence ?

Le cahier des charges fonctionnel dit ce que l’application doit faire ; la spécification technique dit comment elle le fera. Le premier appartient à celui qui exprime le besoin, la seconde à ceux qui conçoivent la solution.

Mélanger les deux est l’erreur la plus courante : imposer un langage ou un outil dans le cahier des charges fonctionnel ferme la porte à de meilleures solutions et brouille la comparaison des offres. Une contrainte réelle, comme l’intégration à votre ERP ou un hébergement imposé, y a sa place ; une préférence sans raison, non.

Quelles rubriques prévoir dans le cahier des charges d’une application web ?

Le cahier des charges d’une application web tient en dix rubriques, de la raison du projet aux conditions de l’après-livraison. Toutes ne demandent pas la même longueur ; aucune ne doit manquer.

• Le contexte et les objectifs. L’entreprise, le problème à résoudre, ce qui existe aujourd’hui, et les objectifs mesurables du projet.
• Le périmètre. Ce que couvre l’application, et ce qu’elle ne couvre pas : la liste de ce qui est hors périmètre évite autant de malentendus que le reste.
• Les utilisateurs et leurs rôles. Qui se sert de l’application (clients, équipes internes, partenaires, administrateurs) et ce que chacun a le droit de voir et de faire.
• Les parcours et les fonctions. Ce que chaque utilisateur doit pouvoir faire, parcours par parcours, avec les règles métier qui s’appliquent.
• Les données. Les informations que l’application crée, reçoit ou affiche, leur origine, leur durée de conservation, et la reprise des données existantes.
• Les échanges avec d’autres outils. ERP, CRM, paiement, authentification, outils internes : ce qui s’échange, dans quel sens et à quel rythme.
• Les exigences non fonctionnelles. Performances attendues, disponibilité, sécurité, accessibilité, navigateurs et appareils, langues.
• Les contraintes. Techniques (existant, hébergement imposé), réglementaires, budgétaires et de calendrier, chacune avec sa raison.
• Les priorités et la recette. Ce qui est indispensable à la première version, ce qui peut suivre, et comment chaque fonction sera vérifiée à la livraison.
• La consultation et l’après-livraison. Ce que la réponse du prestataire doit contenir, la propriété du code, la documentation, la maintenance et la réversibilité.

Les dernières rubriques sont souvent les plus courtes et les plus oubliées. Ce sont pourtant elles qui décident de ce qui se passe après la livraison : qui détient le code, qui le maintient, et comment on change de prestataire. Notre guide du contrat de maintenance applicative détaille ces clauses.

Comment rédiger les exigences fonctionnelles d’une application web ?

Une exigence fonctionnelle bien écrite dit qui fait quoi, dans quel but, et à quoi on reconnaîtra qu’elle est remplie. La norme ISO/IEC/IEEE 29148, consacrée à l’ingénierie des exigences, demande notamment qu’une exigence soit sans ambiguïté et vérifiable.

Dans les projets web, la forme la plus répandue est la user story, suivie de ses critères d’acceptation et de sa priorité :

Trois règles évitent la plupart des exigences inutilisables : une exigence par phrase ; aucun mot qui ne se mesure pas (« rapide », « intuitif », « moderne ») sans dire comment on le mesure ; une priorité pour chacune. La méthode MoSCoW, qui classe chaque exigence en indispensable, importante, souhaitable ou exclue de cette version, est un repère simple.

Que prévoir pour les données, la sécurité et l’accessibilité ?

Les données personnelles, la sécurité et l’accessibilité s’écrivent dans le cahier des charges parce qu’elles coûtent bien plus cher à ajouter après coup. Pour les données personnelles, c’est une obligation : l’article 25 du RGPD impose de les protéger dès la conception et par défaut.

• Les données personnelles. Lesquelles sont collectées, pourquoi, combien de temps elles sont gardées, qui y accède, et comment une personne exerce ses droits. Les environnements de test comptent aussi : voir notre article sur les données de test et le RGPD.
• La sécurité. L’authentification, les rôles et les droits, la trace des actions sensibles, les sauvegardes, et ce qui se passe quand une faille est découverte.
• L’accessibilité. Le niveau visé et les parcours concernés. Pour certains services en ligne, dont le commerce électronique, l’European Accessibility Act en fait une obligation depuis le 28 juin 2025 : notre checklist de l’European Accessibility Act détaille qui est concerné.
• La reprise des données existantes. D’où viennent les données à reprendre, dans quel état elles sont, et qui les valide avant la mise en service.

Quelles erreurs éviter dans un cahier des charges ?

Les erreurs qui coûtent le plus cher dans un cahier des charges sont celles qui ne se voient qu’à la livraison : un besoin décrit par une solution, un périmètre sans limites, une exigence impossible à vérifier.

• Décrire une solution au lieu d’un besoin. « Un menu déroulant », « une base MySQL » : sans dire à quoi cela sert, le prestataire ne peut pas proposer mieux.
• Laisser le périmètre ouvert. Ce qui n’est pas écrit hors périmètre finira par être discuté, au pire moment.
• Tout mettre au même niveau de priorité. Le prestataire ne peut plus proposer de première version réaliste.
• Écrire sans les utilisateurs. Les règles métier réelles sont chez ceux qui font le travail chaque jour.
• Oublier l’après. Sans propriété du code, documentation ni maintenance prévues, une application devient vite une dette technique, et sa reprise par un autre prestataire coûte cher.
• Figer le document. Un cahier des charges se met à jour quand le besoin change, avec une version datée.

Questions fréquentes

Cahier des charges : partez du besoin, pas de la solution

Un bon cahier des charges d’application web ne prévoit pas tout : il dit ce qui compte, pour qui, comment on le vérifiera, et ce qui se passera après la livraison. Le reste se construit avec le prestataire retenu.

L’équipe iones développe des applications web sur mesure en nearshore depuis la Tunisie, pour des entreprises françaises et européennes, et peut commencer par un audit de votre existant ou de votre besoin. Vous pouvez aussi nous écrire pour un premier échange.