Cahier des charges d'un projet web : ce qui doit y figurer (et ce qui l'alourdit)

Le cahier des charges souffre de deux caricatures : le document de quatre-vingts pages que personne ne lit et qui fige des choix prématurés, et son absence totale — « on verra en avançant » — qui transforme le projet en négociation permanente. Entre les deux, il existe un format court et réellement utile : celui qui permet à un prestataire de chiffrer juste, et à vous de recetter sans débat. Voici sa structure.

Ce qu'un cahier des charges doit faire

Trois fonctions, et seulement trois : aligner (tout le monde comprend le même projet), faire chiffrer (des devis comparables, car assis sur le même périmètre), permettre la recette (à la livraison, on sait dire si c'est conforme). Tout contenu qui ne sert aucune des trois fonctions alourdit le document.

Corollaire important : le cahier des charges décrit le problème et les exigences, pas la solution technique. Imposer un framework, une architecture ou un hébergeur dans le document, c'est payer un expert pour lui interdire d'exercer son expertise — sauf contrainte réelle (un existant, une politique interne), qui elle doit y figurer.

La structure en sept sections

# Cahier des charges — [Projet]

## 1. Contexte et objectifs

Qui nous sommes, le problème à résoudre, et 2-3 objectifs MESURABLES :
« générer 30 demandes de devis qualifiées/mois » — pas « moderniser
notre image ».

## 2. Utilisateurs et parcours

Chaque type d'utilisateur, et ce qu'il doit pouvoir accomplir :

- Un prospect trouve le service X et demande un devis en < 2 min.
- Un commercial consulte les demandes et y répond depuis son mobile.
- Un admin met à jour les contenus sans intervention technique.

## 3. Périmètre fonctionnel

La liste de ce qui est inclus… ET la liste de ce qui est EXCLU de
cette version (la section la plus rentable du document).

## 4. Contenus et données

Qui produit les textes/visuels ? Que reprend-on de l'existant ?
Quelles données à migrer, en quel volume ?

## 5. Contraintes

Existant technique, intégrations obligatoires (CRM, paiement…),
exigences légales (RGPD, accessibilité), charte graphique, langues.

## 6. Critères d'acceptation

Comment on validera : performance chiffrée, compatibilités navigateurs
et mobiles, scénarios de test par parcours du §2.

## 7. Cadre du projet

Budget (fourchette assumée), échéance et son motif, interlocuteur
décisionnaire, propriété du code et réversibilité attendues.

Pour la plupart des projets de PME, ce document tient en cinq à dix pages. Au-delà, demandez-vous quelle section fige une solution au lieu d'exprimer un besoin.

Les trois sections que tout le monde bâcle

Les exclusions (§3). Écrire ce que le projet ne fait pas — « pas de paiement en ligne en v1 », « pas de version anglaise », « l'application mobile est hors périmètre » — prévient les malentendus qui coûtent le plus cher. Chaque exclusion écrite est un conflit évité.

Les contenus (§4). Premier facteur de retard des projets web, loin devant la technique : des textes et visuels promis « pour bientôt » qui bloquent la mise en ligne pendant des mois. Nommez un responsable et une échéance par lot de contenu, dans le document.

Le budget (§7). L'omettre « pour ne pas influencer les devis » produit l'inverse : des propositions incomparables, de 8 000 à 80 000 €, chacune ayant deviné un projet différent. Une fourchette assumée cadre le dialogue ; un prestataire sérieux vous dira ce qui rentre dedans et ce qui n'y rentre pas.

Un document vivant, pas un contrat figé

Le cahier des charges initial est nécessairement incomplet : on découvre en faisant. La pratique saine n'est pas de l'interdire mais de l'organiser — chaque évolution de périmètre est écrite, chiffrée (délai et coût) et validée par l'interlocuteur du §7. Ce mécanisme, posé dès le départ, transforme « le client change d'avis » et « le prestataire facture des extras » en une conversation normale et tracée.

Ce qu'il faut retenir

Un bon cahier des charges est court, orienté problème, mesurable, et explicite sur les exclusions autant que sur le contenu. Il ne garantit pas un bon projet — mais son absence garantit des devis incomparables, une recette conflictuelle et des attentes divergentes. Une journée de travail pour l'écrire, à comparer au coût du premier malentendu venu : c'est probablement l'heure la mieux payée de votre projet.