Template : le cahier des charges parfait pour vos projets web
Un cahier des charges mal rédigé est la première cause de dépassements de budget et de délais sur les projets web. Voici la structure complète, section par section, avec les questions à poser et les pièges à éviter pour briefer votre partenaire développement avec précision.
Un projet web mal briefé coûte en moyenne 30 à 40 % de plus que prévu. Pas à cause des développeurs, pas à cause des outils : à cause d'un cahier des charges incomplet qui laisse trop de zones d'ombre.
Si vous travaillez avec un partenaire développement externe, qu'il soit white-label ou non, la qualité de votre cahier des charges est le facteur qui détermine le plus directement la qualité du livrable. Ce document est votre interface entre le besoin de votre client et la réalité technique du développeur.
Ce guide vous donne la structure complète d'un cahier des charges opérationnel pour vos projets web, avec les questions à poser à chaque étape et les erreurs les plus fréquentes à éviter.
Pourquoi votre brief actuel coûte de l'argent
Les chiffres que peu d'agences regardent
Une étude du Standish Group sur les projets IT montre que 52 % des projets web dépassent leur budget initial, et que la cause principale est une définition insuffisante des exigences en amont. Ce n'est pas un problème de compétences techniques : c'est un problème de communication.
En pratique, voici ce que génère un cahier des charges lacunaire.
Les reprises techniques : une fonctionnalité développée différemment de ce que le client attendait doit être entièrement refaite. Ce n'est pas un bug, c'est une incompréhension. Elle ne sera jamais facturée au client, mais elle sera absorbée par votre marge ou votre partenaire.
Les réunions de cadrage en cours de projet : chaque question que le développeur pose pendant la production est une zone floue que le cahier des charges aurait dû couvrir. Ces échanges fragmentent le planning et rallongent les délais.
Les mauvaises surprises à la livraison : quand le client découvre que le site ne fait pas exactement ce qu'il attendait, même si les spécifications techniques étaient respectées, c'est votre relation commerciale qui en pâtit.
La règle du coût de correction
Corriger une erreur de spécification pendant la phase de brief coûte 1. La même correction pendant le développement coûte 10. La même correction après la livraison coûte 100. Investir du temps dans le cahier des charges est le meilleur retour sur investissement d'un projet web.
Pourquoi les agences sous-investissent dans le brief
Trois raisons reviennent systématiquement.
La première est la pression commerciale : une fois le devis signé, l'envie de démarrer vite prend le dessus. Rédiger un cahier des charges de 15 pages semble ralentir la mise en route alors que le client est impatient.
La deuxième est l'illusion de la compréhension commune : après plusieurs échanges avec le client, on a souvent l'impression d'avoir compris le projet. Mais ce que vous avez compris et ce que le client a en tête sont rarement identiques jusqu'au moindre détail.
La troisième est l'absence de template : sans structure de référence, rédiger un cahier des charges from scratch prend trop de temps et produit des documents inégaux selon les projets et les chefs de projet.
Ce guide résout le troisième problème. Et en résolvant le troisième, il facilite les deux premiers.
La structure d'un cahier des charges complet
Un cahier des charges pour projet web doit couvrir six domaines. Chaque domaine correspond à une section du document.
Contexte business et objectifs
Qui est le client, quel problème ce site doit résoudre, comment mesurer le succès. C'est la fondation de tout le reste.
Spécifications techniques
Stack technologique, hébergement, performances attendues, contraintes d'intégration avec les outils existants.
Fonctionnalités et parcours utilisateurs
Liste exhaustive des fonctionnalités, priorité de chacune, description des parcours principaux.
Design et guidelines de marque
Charte graphique, références visuelles, contraintes d'identité, éléments à réutiliser ou à recréer.
Planning et livrables
Jalons, délais par phase, format des livrables intermédiaires, critères d'acceptation.
Budget et modalités
Enveloppe totale, répartition par phase, conditions de facturation, gestion des évolutions de scope.
Chaque section doit être complétée avant de transmettre le document au développeur. Une section manquante n'est pas un oubli anodin : c'est une source de décision arbitraire pendant le développement.
Contexte business et objectifs
C'est la section la plus importante du cahier des charges, et souvent la moins bien remplie. Un développeur qui comprend pourquoi un site est créé prend de meilleures décisions techniques que celui qui ne voit que les spécifications.
Les informations indispensables
Présentation du client : secteur d'activité, taille de l'entreprise, positionnement sur le marché, concurrents directs. Cette contextualisation aide le développeur à comprendre les attentes implicites du secteur.
L'objectif principal du site : un seul objectif, mesurable. Pas "avoir un beau site" mais "générer 20 demandes de devis par mois" ou "réduire les appels au support de 30 % via une FAQ dynamique" ou "permettre aux revendeurs de commander en ligne sans passer par le téléphone". Un objectif mesurable permet de définir des critères d'acceptation objectifs.
Les objectifs secondaires : deux ou trois objectifs complémentaires, hiérarchisés. Ils servent à arbitrer les choix fonctionnels quand le budget est contraint.
Les utilisateurs cibles : qui va utiliser ce site, dans quel contexte, avec quels appareils. Une agence immobilière dont les clients consultent principalement depuis mobile a des exigences différentes d'un cabinet comptable dont les clients travaillent sur desktop.
Les sites de référence : trois à cinq sites que le client admire, avec une description de ce qu'il y apprécie. Ces références évitent des heures de discussion sur le style, le ton et la densité d'information.
La question du "non-objectif"
Incluez également ce que le site ne doit pas faire ou devenir. Cette section évite le scope creep : le client qui demande en cours de projet "et si on ajoutait un espace membre ?" n'avait peut-être pas anticipé cette fonctionnalité, mais elle n'était pas non plus explicitement exclue dans les spécifications initiales.
Formuler les non-objectifs
Exemples de non-objectifs utiles : "Ce site ne comprend pas de fonctionnalité e-commerce (ajout au panier, paiement en ligne)" ou "Ce projet n'inclut pas la création de contenus rédactionnels" ou "La version anglaise du site est hors périmètre de ce projet."
Spécifications techniques
Cette section est la traduction technique des objectifs business. Elle définit les contraintes dans lesquelles le développeur devra travailler.
Le stack technologique
Précisez le CMS ou le framework retenu, avec une justification courte. Si le client hésite entre WordPress et un développement sur mesure, c'est à vous d'arbitrer avant de transmettre le cahier des charges, pas au développeur.
Pour les projets gérés par Kayden Digital, le stack standard est Next.js (React) pour les sites à fort besoin de performance, et WordPress (avec ou sans headless) quand le client a besoin d'autonomie de gestion de contenu.
Les contraintes d'hébergement
Hébergeur actuel ou retenu, contraintes de l'hébergement (certains hébergeurs mutualisés ne supportent pas Node.js, par exemple), accès FTP/SSH disponibles, contraintes de déploiement.
Les exigences de performance
| Indicateur | Minimum acceptable | Cible recommandée | Impact si non atteint |
|---|---|---|---|
| Score Lighthouse Performance | 80/100 | 90+/100 | Classement Google dégradé, taux de rebond élevé |
| Temps de chargement (3G) | < 4 secondes | < 2,5 secondes | Abandon utilisateur avant affichage |
| Score Accessibilité | 75/100 | 90+/100 | Risque légal (EAA 2025), exclusion d'utilisateurs |
| Score SEO Lighthouse | 85/100 | 95+/100 | Indexation partielle, pénalités techniques |
| Core Web Vitals (LCP) | < 3 secondes | < 2,5 secondes | Non-conformité Google Page Experience |
Ces seuils doivent figurer dans le cahier des charges comme critères d'acceptation. Un livrable qui ne les respecte pas n'est pas accepté, et la correction est à la charge du développeur.
Les intégrations tierces
Listez tous les outils avec lesquels le site doit communiquer : CRM, outil d'emailing, plateforme de réservation, Google Analytics, Meta Pixel, chat en direct, système de paiement. Chaque intégration doit mentionner si une API est disponible, si des identifiants d'accès existent déjà, et si une documentation technique est fournie.
La conformité réglementaire
En Europe, plusieurs obligations légales impactent le développement d'un site web en 2026.
Le RGPD impose des règles sur les cookies, les formulaires de collecte de données et le stockage des informations personnelles. La bannière cookies doit être implémentée correctement et le formulaire de contact doit mentionner la base légale du traitement.
L'European Accessibility Act (EAA), entré en application en juin 2025, rend obligatoire la conformité WCAG 2.1 niveau AA pour les sites de services aux consommateurs. Vérifiez si votre client est concerné et incluez les exigences dans le cahier des charges.
Fonctionnalités et parcours utilisateurs
C'est la section la plus détaillée du cahier des charges. Elle décrit ce que le site fait, pas comment il le fait techniquement.
La liste des fonctionnalités
Présentez chaque fonctionnalité avec quatre informations.
Description : en une phrase, ce que la fonctionnalité permet à l'utilisateur de faire. "L'utilisateur peut soumettre une demande de devis via un formulaire en 3 étapes."
Priorité : Must-have (indispensable pour la mise en ligne), Should-have (important mais le site peut fonctionner sans), Nice-to-have (souhaitable si le budget le permet). Cette hiérarchie vous permet de gérer les arbitrages budgétaires sans remettre en question l'ensemble du projet.
Complexité estimée : faible, moyenne, élevée. Cette information n'est pas destinée au client mais guide le développeur dans sa planification.
Critère d'acceptation : comment vous allez vérifier que la fonctionnalité est correctement implémentée. "Le formulaire envoie un email de confirmation à l'utilisateur et une notification à l'adresse admin dans les 30 secondes."
Must-have
Fonctionnalités sans lesquelles le site ne peut pas être mis en ligne. Elles définissent le MVP du projet.
Should-have
Fonctionnalités importantes qui améliorent significativement l'expérience, mais dont l'absence ne bloque pas le lancement.
Nice-to-have
Améliorations souhaitables, à réaliser si le budget et le planning le permettent, ou à reporter en phase 2.
Hors périmètre
Fonctionnalités explicitement exclues du projet, pour éviter tout malentendu pendant le développement.
Les parcours utilisateurs principaux
Pour chaque type d'utilisateur (visiteur anonyme, prospect qualifié, client existant, administrateur), décrivez le parcours principal en 5 à 8 étapes. Ce n'est pas un wireframe, c'est une description textuelle des actions et des écrans traversés.
Exemple pour un site de cabinet d'avocats :
Visiteur anonyme cherchant un avocat spécialisé en droit du travail : (1) arrive sur la homepage via Google, (2) lit le bloc "Nos domaines d'expertise", (3) clique sur "Droit du travail", (4) consulte la page de l'avocat spécialisé, (5) clique sur "Prendre rendez-vous", (6) remplit le formulaire de contact avec description de la situation, (7) reçoit un email de confirmation avec délai de réponse.
Ce niveau de détail révèle immédiatement les pages nécessaires, les fonctionnalités impliquées et les contenus à prévoir.
La structure du site (sitemap)
Listez toutes les pages du site avec leur URL prévue, leur type (statique, dynamique, générée depuis un CMS) et les fonctionnalités qu'elles contiennent. Un tableau simple suffit.
| Page | URL | Type | Fonctionnalités clés |
|---|---|---|---|
| Accueil | / | Statique | Hero, services, témoignages, CTA |
| Services | /services/ | Statique | Liste des services avec liens |
| Service détail | /services/[slug]/ | Dynamique CMS | Description, tarifs, CTA contact |
| Contact | /contact/ | Statique | Formulaire, carte, coordonnées |
| Blog | /blog/ | Dynamique CMS | Liste articles, pagination, filtres |
Ce tableau évite les oublis et sert de référence pour estimer le volume de travail.
Design, UX et guidelines de marque
Cette section définit les contraintes visuelles et d'expérience utilisateur. Elle est souvent sous-documentée, ce qui génère des allers-retours coûteux sur le design.
Ce que cette section doit contenir
La charte graphique : couleurs principales et secondaires (codes hexadécimaux), typographies (noms et variantes), logo en formats vectoriels. Si une charte graphique existe déjà, joignez le fichier. Si elle n'existe pas encore, précisez-le et intégrez la création de la charte dans le périmètre du projet.
Les contraintes d'identité : éléments à réutiliser depuis le site existant (si refonte), éléments à ne pas modifier (logo, couleurs institutionnelles), éléments à moderniser. Soyez précis : "le logo doit être utilisé tel quel" et "la typographie actuelle peut être remplacée" sont deux contraintes très différentes.
Les références visuelles : trois à cinq captures d'écran annotées de sites que le client apprécie. Mentionnez ce qu'il y aime spécifiquement : la densité d'information, le style des boutons, l'utilisation des images, la navigation. Ne laissez pas le développeur interpréter seul "je veux quelque chose dans ce genre".
Les contraintes d'accessibilité visuelle : contrastes minimum (WCAG AA exige un ratio de contraste de 4,5:1 pour le texte normal), taille minimum des éléments cliquables (44px x 44px selon les guidelines Apple et Google), comportement sur les réductions de mouvement (préférence utilisateur prefers-reduced-motion).
La maquette ou les wireframes
Pour les projets de plus de 5 000 euros, des wireframes des pages principales (homepage, page type, formulaire) réduisent considérablement les divergences d'interprétation. Ils ne doivent pas être des designs finis : des schémas en niveaux de gris qui montrent la structure et la hiérarchie de l'information suffisent.
Wireframe vs Design : ne pas confondre
Un wireframe montre la structure (où sont les éléments, quelle est leur hiérarchie). Un design montre le rendu visuel final (couleurs, typographies, images). Pour un brief technique, le wireframe est plus utile que le design car il précise ce que le développeur doit implémenter, pas comment ça doit être beau.
Le comportement responsive
Définissez les points de rupture prioritaires et le comportement attendu sur mobile. En Belgique, la part du trafic mobile dépasse 60 % pour la plupart des secteurs B2C. Précisez si le design doit être "mobile-first" (conçu d'abord pour mobile, adapté ensuite pour desktop) ou "desktop-first" avec une adaptation mobile.
Listez les composants dont le comportement mobile doit être décrit explicitement : navigation (hamburger menu, navigation par onglets), tableaux (scroll horizontal, affichage empilé), formulaires multi-étapes, galeries d'images.
Planning, budget et livrables
Cette section cadre les engagements mutuels. Elle doit être rédigée de manière à éviter les disputes sur ce qui était inclus et ce qui ne l'était pas.
La décomposition en phases
Découpez le projet en phases avec un livrable et une date pour chacune. Ce découpage vous permet de facturer par jalons et de contrôler l'avancement.
Phase 1 : Setup et intégration (semaine 1-2)
Configuration de l'environnement de développement, mise en place du repository, intégration des maquettes en HTML/CSS statique. Livrable : pages statiques validées sur desktop et mobile.
Phase 2 : Développement fonctionnel (semaine 3-5)
Implémentation des fonctionnalités, connexion au CMS ou à la base de données, intégrations tierces. Livrable : site fonctionnel en environnement de staging.
Phase 3 : Tests et optimisation (semaine 6)
Tests cross-browser, correction de bugs, optimisation des performances (Lighthouse 90+), audit SEO technique. Livrable : rapport de tests et scores Lighthouse.
Phase 4 : Mise en production (semaine 7)
Déploiement sur l'hébergement de production, configuration du domaine, vérification post-déploiement. Livrable : site en ligne et accessible.
Les critères d'acceptation globaux
Au-delà des critères par fonctionnalité, définissez les critères d'acceptation du projet dans son ensemble. Voici les standards que nous recommandons et que nous appliquons chez Kayden Digital.
| Critère | Standard minimum | Méthode de vérification |
|---|---|---|
| Performance Lighthouse | 90/100 | Test sur PageSpeed Insights en mode incognito |
| Accessibilité Lighthouse | 90/100 | Test automatique + vérification manuelle clavier |
| Rendu mobile | Sans scroll horizontal, éléments lisibles | Test sur iPhone SE (375px) et Samsung Galaxy (360px) |
| Formulaires | Envoi fonctionnel, emails reçus | Test de bout en bout avec adresse réelle |
| Liens internes | Aucun lien cassé | Vérification avec outil de crawl (Screaming Frog) |
| Images | Toutes optimisées, attributs alt renseignés | Audit manuel et Lighthouse |
La gestion du scope creep
Précisez explicitement comment les demandes de modifications hors périmètre seront traitées. Deux approches courantes.
L'approche forfait fixe : tout ce qui est dans le cahier des charges est inclus. Toute demande supplémentaire fait l'objet d'un devis complémentaire avant réalisation. Simple et prévisible, mais peut créer des tensions si le cahier des charges est imprécis.
L'approche réserve de modifications : un budget d'heures est inclus pour couvrir les ajustements raisonnables (10 à 15 % du budget total). Au-delà, un avenant est nécessaire. Plus souple, mais nécessite une bonne communication sur l'utilisation de la réserve.
Pas de date de mise en ligne dans le brief
Sans date cible pour la mise en production, le projet n'a pas de sens d'urgence. Le développeur planifie en fonction de ses autres projets, pas en fonction de vos engagements client. Toujours inclure une date de mise en ligne ferme.
Budget communiqué sans décomposition
Un budget global sans ventilation par phase ne permet pas d'arbitrer si le client demande des modifications. Décomposez le budget par phase et précisez ce que couvre chaque enveloppe.
Critères d'acceptation absents
Sans critères précis, la livraison donne lieu à des discussions interminables sur ce qui est 'fini' ou non. Les critères d'acceptation transforment une opinion en fait vérifiable.
Utiliser ce template avec un partenaire white-label
Si vous externalisez le développement à un partenaire white-label, le cahier des charges joue un rôle encore plus central. Il remplace une grande partie des échanges informels qui seraient possibles avec un développeur interne.
Adapter le cahier des charges à l'externalisation
Quelques ajustements rendent le cahier des charges plus efficace dans un contexte white-label.
Anonymisez les informations client si nécessaire. Si votre NDA avec le client est strict, vous pouvez transmettre le cahier des charges avec le nom du client remplacé par un code projet. Les informations business restent pertinentes pour le développeur sans révéler l'identité du client final.
Précisez les contraintes de confidentialité. Mentionnez explicitement dans le cahier des charges que le projet est réalisé en mode white-label et que le partenaire n'a aucun contact direct avec le client final. Ce point doit figurer dans le NDA, mais le rappeler dans le brief renforce la compréhension du cadre.
Ajoutez vos standards de livraison. En tant qu'agence, vous avez probablement des standards techniques propres : convention de nommage des fichiers, structure des repositories Git, format de documentation, outils de déploiement. Documentez-les dans une annexe technique et joignez-la à chaque cahier des charges. Cela évite de répéter les mêmes instructions projet par projet.
Définissez le process de validation. Avec un partenaire externe, la validation se fait généralement en deux temps : validation intermédiaire sur l'environnement de staging, puis validation finale avant mise en production. Précisez qui valide (vous seul, ou vous et le client), dans quel délai, et comment les retours sont communiqués.
Le cahier des charges comme outil de montée en puissance
Une fois que votre partenaire white-label comprend votre façon de travailler, le cahier des charges devient plus efficace à chaque projet. Votre partenaire anticipe vos exigences, pose des questions plus ciblées, et produit des livrables plus proches de vos attentes dès la première version.
C'est l'un des avantages majeurs d'une relation white-label stable sur le long terme par rapport à une relation transactionnelle avec plusieurs prestataires différents. La documentation s'accumule, les standards s'affinent, et le temps de briefing diminue.
Le partenaire idéal lit votre cahier des charges en entier
Un bon partenaire white-label pose des questions pertinentes après avoir lu le cahier des charges, pas avant. Si votre partenaire répond à un brief de 15 pages par "tout est clair, on démarre quand ?" sans aucune question, c'est un signal d'alerte. Un document de cette densité contient toujours des zones d'ombre que seul un développeur attentif peut identifier.
Les questions qu'un bon partenaire posera
Pour vous aider à évaluer la qualité de lecture de votre cahier des charges par votre partenaire, voici les questions qu'un développeur attentif posera systématiquement.
Sur les fonctionnalités : "Avez-vous des exemples de sites avec une implémentation similaire de cette fonctionnalité ?" ou "La fonctionnalité X doit-elle fonctionner hors connexion ?"
Sur les intégrations : "Avez-vous accès aux clés API pour l'intégration CRM ?" ou "Quelle version de l'API doit être utilisée ?"
Sur les performances : "Les scores Lighthouse sont-ils mesurés en environnement de production ou sur staging ?" ou "Le score de performance doit-il être maintenu avec les scripts tiers (Analytics, Pixel) actifs ?"
Sur la livraison : "Qui a accès au repository Git après la livraison ?" ou "Qui gère les mises à jour de sécurité après la mise en production ?"
Ces questions révèlent qu'un développeur a lu votre document avec attention et pense à l'ensemble du cycle de vie du projet. Pour en savoir plus sur les critères de sélection d'un bon partenaire, consultez notre checklist des 15 critères pour choisir votre partenaire développement.
Combiner le cahier des charges avec un projet pilote
Si vous démarrez avec un nouveau partenaire, le premier projet est aussi une occasion d'évaluer comment il utilise votre cahier des charges. Observe-t-il les priorités Must/Should/Nice-to-have ? Respecte-t-il les critères d'acceptation définis ? Signale-t-il les zones d'ombre avant de prendre des décisions arbitraires ?
Notre guide sur le programme pilote pour tester un partenaire white-label détaille comment structurer cette évaluation et quels critères surveiller.
Un cahier des charges complet est un investissement de deux à quatre heures au démarrage d'un projet. En échange, il vous évite des semaines de reprises, des conversations tendues avec votre client et des marges grignotées par des corrections non prévues.
La structure décrite dans ce guide fonctionne pour les sites vitrines comme pour les projets e-commerce ou les applications web. Adaptez le niveau de détail à la complexité du projet, mais ne supprimez aucune section : chaque domaine couvert est un risque en moins.
Si vous externalisez votre développement, ce document devient votre principal outil de pilotage. Plus il est précis, plus votre partenaire peut travailler de manière autonome et vous livrer ce que votre client attend, sans allers-retours inutiles.
Questions fréquentes sur le cahier des charges web
Articles complémentaires
Étude de cas : comment une agence SEO
Une agence SEO de Liège, 3 consultants, un plafond de croissance bien visible. En 6 mois, en externalisant le développement web en white-label, elle a multiplié son portefeuille de clients par trois sans recruter. Voici le détail de ce qui s'est passé, et comment reproduire ce résultat.
White-LabelWhite-label, freelance ou agence offshore :
Vous avez besoin de renforcer votre capacité de développement web, mais vous hésitez entre un freelance, une agence offshore et un partenaire white-label ? Ce comparatif objectif analyse les trois options sous tous les angles : coûts réels, fiabilité, discrétion, et adéquation selon votre profil d'agence.
White-LabelProgramme pilote : comment tester un partenaire
Avant de confier votre réputation à un partenaire white-label, il existe une méthode éprouvée pour valider la collaboration sans mettre vos clients en danger. Le programme pilote est cette méthode. Voici comment le structurer, l'exécuter et en tirer les bonnes conclusions.