Cahier des charges site web :le modèle que j'envoie aux prestataires

Un cahier des charges site web mal fait ne se voit pas tout de suite. Vous recevez trois devis, l'un deux fois plus cher que les autres, et vous découvrez en lisant le détail que chaque prestataire a compris un site différent. Si vous devez faire chiffrer une création ou une refonte, c'est ce document qui décide si vos devis sont comparables.

Mes missions commencent par quelques jours de diagnostic, et le cahier des charges en sort souvent. Je vous donne ici le modèle en huit parties que j'utilise, la façon de décrire les fonctionnalités sans écrire la technique à la place du prestataire, et la liste de contrôle que je passe avant l'envoi. Il ne remplace pas une note de cadrage : il vient juste après.

01À quoi sert un cahier des charges, et ce qu'il ne fera pas

Le document a deux usages. Avant le projet, il permet à plusieurs prestataires de chiffrer la même chose. Pendant le projet, il sert de référence quand une demande nouvelle arrive : on regarde si elle y figure, et si non, on décide de l'ajouter en connaissance de cause.

France Num rappelle qu'un cahier des charges n'a pas besoin d'être un document technique de cent pages : pour une TPE ou une PME, cinq à dix pages bien structurées suffisent pour un site vitrine ou un e-commerce simple. Je suis d'accord, et j'ajouterais que les documents longs sont rarement relus.

Ce qu'il ne fera pas : choisir à votre place entre deux objectifs qui se contredisent. Si le marketing veut un site qui génère des contacts et la direction un site qui rassure les investisseurs, le cahier des charges additionnera les deux. Cette décision se prend avant, dans une note de cadrage de deux pages.

02Les huit parties de mon modèle

France Num propose une trame proche : contexte, objectifs, structure et fonctionnalités, outils tiers, grille d'évaluation, livrables et calendrier, budget. J'y ajoute les parcours et le hors périmètre, parce que ce sont, à mon sens, les deux endroits où les devis divergent le plus.

1. Le contexte. Qui vous êtes, ce que vous vendez, à qui, et pourquoi le site actuel ne suffit plus. Une page au plus.
2. Les objectifs, classés. Trois au maximum, dans l'ordre, chacun avec une mesure. « Plus de demandes de démonstration » plutôt que « moderniser notre image ».
3. Les publics et leurs parcours. Pour chaque public, deux ou trois tâches qu'il doit pouvoir accomplir sur le site.
4. L'arborescence et les contenus. La liste des pages, et pour chaque type de page : qui écrit, qui valide, qui fournit les images.
5. Les fonctionnalités, par priorité. Indispensable, souhaitable, plus tard.
6. Les outils avec lesquels le site doit fonctionner. CRM, outil d'e-mailing, ERP, prise de rendez-vous, et pour chacun la donnée qui circule.
7. Les contraintes et le hors périmètre. Obligations légales, langues, hébergement, et la liste de ce que le site ne fera pas.
8. Ce que vous attendez des prestataires. Livrables, calendrier, budget estimé, critères de choix, et la façon dont la recette sera faite.

La partie 7 vient de mes machines de contenu. Le brief de chaque article y contient un champ obligatoire qui liste ce que le texte s'interdit d'affirmer, et le brief est refusé tant qu'il est vide. Écrire les limites avant de commencer évite les promesses glissées en route. Pour un site, « pas d'espace client », « pas de version anglaise au lancement » ou « pas de migration des anciens articles » coupent court à des semaines de discussion.

Le niveau de détail qui suffit

Un prestataire doit pouvoir chiffrer sans vous appeler pour chaque ligne. Si une fonctionnalité tient en un mot (« blog », « recherche »), elle sera chiffrée de trois façons différentes. Si elle tient en une page, vous avez probablement commencé à concevoir à la place de l'équipe qui va construire. Entre les deux, trois ou quatre lignes par fonctionnalité me paraissent suffire.

03Décrire les fonctionnalités sans écrire la technique

Vous n'êtes pas obligé de savoir sur quelle technologie reposera le site. France Num le dit clairement, en ajoutant qu'il est en revanche indispensable de préciser avec quels autres outils le site devra fonctionner. C'est la bonne frontière : vous décrivez le besoin, le prestataire propose la solution.

Pour décrire le besoin, j'emprunte le format des user stories du manuel de service britannique. Une story nomme l'utilisateur, ce qu'il veut faire et pourquoi. Le manuel insiste sur un point que je trouve très utile : si vous peinez à écrire le but, revoyez la raison pour laquelle vous pensez avoir besoin de cette fonctionnalité. Appliquée à un cahier des charges, cette question fait tomber les fonctionnalités ajoutées « parce que les autres sites les ont ».

Le même manuel propose d'écrire les critères d'acceptation sous la forme « c'est fait quand… ». Voici ce que cela donne pour une prise de rendez-vous. La story : « En tant que prospect, je veux réserver une démonstration de 30 minutes sans échanger d'e-mails, pour choisir un créneau qui me convient. » Et ses critères, c'est fait quand :

• le prospect voit les créneaux libres des deux commerciaux ;
• la réservation crée un contact dans le CRM, avec la page d'origine ;
• le prospect et le commercial reçoivent une invitation de calendrier ;
• une annulation libère le créneau sans intervention.

Ces quatre lignes se chiffrent, et elles serviront telles quelles à la recette. Pour un parcours qui change d'état sur une même page (un tunnel de commande, des filtres de catalogue), Nielsen Norman Group décrit un format utile : le wireflow, qui combine des écrans en basse fidélité et les flèches de l'interaction, là où un wireframe seul montre mal ce qui se passe après un clic. Un croquis de ce genre en annexe vaut une page de texte.

04Ce qui manque presque toujours

Les contenus, d'abord. Le cahier des charges détaille les gabarits de pages et oublie de dire qui écrit les textes, qui les valide et pour quand. Le calendrier glisse ensuite à cet endroit, et le prestataire attend.

Les données de référence, ensuite. Sur un projet, j'ai vu un mélange de centimètres et de millimètres entre deux outils déformer tout un rendu de produits. Personne n'avait écrit quelle source faisait foi, ni dans quelle unité. Pour un site relié à un catalogue ou à un CRM, je note pour chaque donnée l'outil qui la possède et celui qui la recopie. J'en parle plus en détail à propos de la spécification d'une intégration entre un ERP et un site marchand.

Les obligations légales, enfin. Service Public Entreprendre rappelle qu'un site d'entreprise doit notamment présenter l'entreprise, informer sur les données personnelles et les cookies, et afficher les CGV en cas de vente en ligne. Ajoutez l'accessibilité : l'acte européen sur l'accessibilité est entré en vigueur le 28 juin 2025 et couvre notamment le e-commerce, les très petites entreprises étant exclues. Si ces points ne figurent pas dans le document, ils ne sont pas dans le devis.

05Avant d'envoyer : la liste de contrôle

Dans mes machines de contenu, une commande relit le brief et répond « refusé » avec la liste de ce qui manque. Je passe la même relecture sur un cahier des charges avant l'envoi :

• chaque objectif a une mesure, et ils sont classés ;
• chaque fonctionnalité indispensable a un but et des critères « c'est fait quand » ;
• chaque type de page a un responsable des contenus et une date ;
• chaque outil relié au site est nommé, avec la donnée qui circule et la source qui fait foi ;
• les mentions légales, les cookies et l'accessibilité sont listés ;
• le hors périmètre tient en une liste explicite ;
• la façon de comparer les réponses est écrite ;
• le document porte un numéro de version et une date.

Le dernier point paraît administratif. Sur une intégration entre un ERP et un site marchand, la spécification a bougé presque à chaque réunion. Je l'ai fait évoluer version après version, pour que tout le monde parle du même document. Si vous envoyez une version 2 à un prestataire et une version 3 à un autre, vos devis ne se comparent plus.

06Quand le cahier des charges ne suffit pas

Un document écrit décrit mal ce qui se joue à l'écran. Quand un parcours est au cœur du projet, un prototype cliquable avant le développement règle en une séance ce que trois allers-retours sur un PDF n'auraient pas réglé. Pour l'apparence, montrer plusieurs directions de maquette au même niveau de finition débloque une décision mieux qu'une description de l'ambiance souhaitée.

Le cahier des charges fixe aussi le projet au moment où vous l'écrivez. Sur un produit conçu à partir de ses utilisateurs, comme l'API de paie de Moonworkers, les besoins changent au fil de ce qu'on apprend d'eux, et un document figé vieillit vite : une liste de priorités tenue à jour sert mieux. Le format convient à un site dont le périmètre peut être décidé d'avance.

Enfin, il ne vérifie rien tout seul. À la livraison, je reprends les critères « c'est fait quand » un par un, en naviguant comme un visiteur non connecté, parce qu'un site peut sembler normal à l'équipe connectée et être cassé pour le public. La checklist de recette et de mise en production part de là.

07Par où commencer cette semaine

Ouvrez un document et écrivez d'abord les parties 2 et 7 : trois objectifs classés et la liste de ce que le site ne fera pas. Si vous n'arrivez pas à les écrire, le reste attendra, et c'est une information utile. Remplissez ensuite les parcours, une story par tâche, avec leurs critères. La technique viendra des réponses des prestataires.

Si plusieurs prestataires doivent travailler ensemble ensuite, gardez une seule version du document pour tous, comme je le décris pour coordonner plusieurs prestataires. Et si vous voulez un regard extérieur sur le vôtre avant de l'envoyer, c'est le genre de diagnostic court que je fais dans mes missions de direction de projet. On peut en parler.