Cahier des charges d'application web : comment le rédiger (et ce qu'il faut éviter)

Le cahier des charges est souvent vécu comme une corvée administrative : un long document qu’on rédige parce qu’il « en faut un », puis qu’on oublie dans un dossier partagé. C’est dommage, car c’est l’outil le plus efficace pour réussir un projet d’application web. Un bon cahier des charges aligne les équipes internes, permet aux prestataires de chiffrer sérieusement et sert de référence quand les arbitrages deviennent difficiles.

Un mauvais cahier des charges, à l’inverse, produit des devis incomparables, des malentendus en cours de route et une application qui répond à la lettre du document mais pas au besoin réel. Voici comment rédiger le vôtre, ce qu’il doit contenir, et les erreurs que nous rencontrons le plus souvent.

Le principe de base : décrire des besoins, pas des solutions

Avant d’entrer dans le détail, retenez une règle : votre rôle est d’expliquer le problème et le résultat attendu, celui du prestataire est de proposer la meilleure façon d’y arriver.

« Nous voulons un menu déroulant avec la liste des clients » est une solution. « Le commercial doit retrouver un client en quelques secondes, même s’il ne se souvient que d’une partie de son nom » est un besoin. Le second laisse la place à une meilleure réponse (une recherche instantanée, par exemple) et rend le critère de réussite vérifiable.

Cela ne veut pas dire que vous n’avez pas d’avis. Vous pouvez tout à fait signaler une préférence ou une contrainte. Mais présentez-la comme telle, en expliquant pourquoi.

Ce que doit contenir un bon cahier des charges

1. Le contexte et les objectifs

Commencez par expliquer pourquoi ce projet existe. Qui êtes-vous, quelle est votre activité, quel problème rencontrez-vous aujourd’hui ? Comment le traitez-vous actuellement (tableurs, outil vieillissant, processus papier) ?

Puis formulez les objectifs du projet, idéalement de façon mesurable : réduire le temps de traitement d’une commande, supprimer une double saisie, permettre aux clients de suivre eux-mêmes leur dossier. Ces objectifs serviront de boussole pour toutes les décisions suivantes.

2. Les utilisateurs et leurs profils

Listez les différents types d’utilisateurs (on parle souvent de personas) et ce qui les caractérise :

• qui ils sont : collaborateurs internes, clients, partenaires, administrateurs ;
• combien ils sont, approximativement, et à quelle fréquence ils utiliseront l’application ;
• dans quel contexte : au bureau sur grand écran, sur le terrain avec un smartphone, avec une connexion instable ;
• leur aisance avec le numérique, qui influence fortement la conception de l’interface.

Une application utilisée par des techniciens sur un chantier ne se conçoit pas comme un outil de pilotage pour la direction financière.

3. Les user stories

La user story (récit utilisateur) est un format simple et redoutablement efficace pour exprimer un besoin fonctionnel :

En tant que [type d’utilisateur], je veux [action] afin de [bénéfice].

Par exemple : « En tant que responsable d’agence, je veux voir les demandes de devis en attente depuis plus de 48 heures afin de relancer l’équipe avant que le client ne s’impatiente. »

Ce format oblige à préciser qui a besoin de quoi, et surtout pourquoi. Le « afin de » est la partie la plus précieuse : c’est elle qui permet au prestataire de proposer une solution plus simple, ou de repérer une fonctionnalité inutile.

4. Le périmètre fonctionnel, avec des priorités

Regroupez les user stories par grands domaines (gestion des comptes, catalogue, commandes, facturation, reporting…) et attribuez une priorité à chacune. La méthode MoSCoW est simple à appliquer :

• Must have : indispensable au lancement ;
• Should have : important, mais peut suivre de peu ;
• Could have : souhaitable si le budget le permet ;
• Won’t have (this time) : explicitement exclu de cette version.

La dernière catégorie est sous-estimée. Écrire noir sur blanc ce que l’on ne fera pas évite bien des discussions en cours de projet.

5. Les exigences non fonctionnelles

Ce sont les qualités attendues de l’application, au-delà de ce qu’elle fait. Elles sont souvent oubliées, et pèsent pourtant lourd dans la conception et le budget :

• Performance : temps de réponse attendus, volumes de données, nombre d’utilisateurs simultanés, pics d’activité prévisibles.
• Sécurité : niveaux d’authentification (double facteur ?), gestion des rôles et des droits, journalisation des actions sensibles.
• RGPD : nature des données personnelles traitées, durées de conservation, droits des personnes (accès, rectification, suppression), sous-traitants impliqués. Si l’application intègre de l’IA, consultez aussi notre article sur l’IA, le RGPD et l’AI Act.
• Accessibilité : niveau de conformité visé, en particulier si l’application est utilisée par le public ou si vous êtes concerné par les obligations d’accessibilité numérique.
• Hébergement : contraintes de localisation des données (en France, en Europe), exigences de disponibilité, sauvegardes, plan de reprise.
• Compatibilité : navigateurs, appareils, usage mobile ou hors connexion.

6. Les intégrations

Une application web vit rarement seule. Listez les outils avec lesquels elle doit échanger : ERP, CRM, logiciel de comptabilité, outil de paiement, messagerie, annuaire d’entreprise, API de partenaires.

Pour chacun, précisez le sens des échanges (lecture, écriture, les deux), la fréquence (temps réel, quotidienne) et, si vous la connaissez, l’existence d’une API documentée. Les intégrations sont une source fréquente de mauvaises surprises : plus elles sont décrites tôt, mieux elles sont chiffrées.

7. Les données

Quelles données l’application va-t-elle manipuler ? Existe-t-il des données à reprendre depuis un ancien système, et dans quel état sont-elles ? Une migration de données mal anticipée peut représenter une part importante d’un projet. Joignez des exemples anonymisés de fichiers ou d’exports quand c’est possible.

8. Les contraintes

Soyez transparent sur ce qui encadre le projet :

• le calendrier : une date de lancement imposée (salon, saison, échéance réglementaire) ?
• le budget : donner une enveloppe, même large, permet aux prestataires de proposer une réponse adaptée plutôt qu’un chiffrage théorique ;
• les contraintes techniques : technologies imposées par votre DSI, environnement existant ;
• les ressources internes : qui sera disponible côté client pour répondre aux questions, tester et valider ?

9. Les critères de succès

Comment saurez-vous que le projet est réussi ? Reprenez vos objectifs et associez-leur des critères vérifiables : délais de traitement, taux d’adoption par les équipes, suppression d’un outil existant. Ces critères orienteront aussi la recette, c’est-à-dire la phase de tests et de validation avant mise en production.

Les pièges à éviter

Surspécifier l’interface

Joindre des maquettes détaillées écran par écran semble rassurant. En pratique, cela fige des choix d’ergonomie avant que quiconque ait réfléchi aux parcours. Des croquis ou des captures d’outils que vous appréciez suffisent largement pour exprimer vos attentes. Laissez la conception de l’interface aux designers, en leur donnant le contexte.

Décrire des solutions au lieu de besoins

C’est l’erreur la plus fréquente, et nous y revenons parce qu’elle coûte cher. Un cahier des charges rempli de solutions techniques prive le projet de l’expertise du prestataire et conduit souvent à reproduire numériquement un processus qui mériterait d’être simplifié.

Ne pas prioriser

Si tout est indispensable, rien ne l’est. Sans priorités, le prestataire chiffre tout au même niveau, le budget explose, et les arbitrages se font dans l’urgence en fin de projet, rarement au profit de l’essentiel.

Écrire seul, dans son bureau

Le cahier des charges rédigé par une seule personne reflète une seule vision. Impliquez les futurs utilisateurs, même brièvement : ce sont eux qui connaissent les cas particuliers, les contournements et les irritants du quotidien.

Viser l’exhaustivité

Un document de cent pages n’est pas lu en entier, ni par vos équipes, ni par les prestataires. Mieux vaut un document clair et hiérarchisé, complété par des échanges, qu’une somme indigeste.

Forfait ou régie : ce que cela change pour votre cahier des charges

Le niveau de détail attendu dépend du mode de contractualisation :

	Forfait	Régie (temps passé)
Principe	Un prix fixe pour un périmètre défini	Une facturation selon le temps réellement consacré
Exigence sur le cahier des charges	Très élevée : tout ce qui n’est pas écrit n’est pas inclus	Plus souple : le périmètre s’affine en cours de route
Gestion des changements	Par avenants, souvent sources de tensions	Naturelle, par repriorisation régulière
Risque principal	Un périmètre figé qui ne correspond plus au besoin	Une dérive si le pilotage est faible
Adapté à	Projets bien connus, au périmètre stable	Produits innovants, besoins qui vont évoluer

Pour beaucoup de projets d’application web, une approche mixte fonctionne bien : une phase de cadrage au forfait qui transforme votre cahier des charges en périmètre détaillé et chiffré, puis un développement par lots, chacun cadré et validé. Nous en parlons aussi dans notre article sur le choix d’un prestataire web.

Un modèle de plan prêt à l’emploi

Voici une trame que vous pouvez reprendre telle quelle :

1. Présentation de l’entreprise et du contexte du projet
2. Problème actuel et fonctionnement existant
3. Objectifs du projet et critères de succès
4. Utilisateurs : profils, volumes, contextes d’usage
5. Périmètre fonctionnel : user stories regroupées par domaine, avec priorités MoSCoW
6. Exigences non fonctionnelles : performance, sécurité, RGPD, accessibilité, hébergement, compatibilité
7. Intégrations avec les outils existants
8. Données : nature, volumes, reprise de l’existant
9. Contraintes : calendrier, budget indicatif, technique, ressources internes
10. Modalités de réponse : contenu attendu des propositions, calendrier de consultation, interlocuteurs
11. Annexes : exemples de documents, exports anonymisés, captures, croquis

Dix à vingt pages bien écrites suffisent pour la grande majorité des projets de PME.

En résumé

Un bon cahier des charges d’application web :

• explique le contexte et des objectifs mesurables ;
• décrit les utilisateurs et leurs besoins sous forme de user stories ;
• priorise chaque fonctionnalité, y compris ce qui est exclu ;
• n’oublie pas les exigences non fonctionnelles, les intégrations et les données ;
• décrit des besoins plutôt que des solutions ;
• s’adapte au mode de contractualisation choisi.

Si vous préférez être accompagné, c’est précisément l’objet de la phase de cadrage de nos projets d’applications web : ateliers avec vos équipes, user stories, priorisation et chiffrage par lots. Vous avez déjà un premier document, même incomplet ? Envoyez-le-nous, nous vous ferons un retour concret.