Un projet WordPress sans cahier des charges, c’est un chantier sans plan d’architecte. Tout le monde a une idée de ce que le résultat devrait être — le client, le développeur, le graphiste — et ces idées ne coïncident presque jamais. Ce qui s’ensuit est prévisible : des allers-retours interminables, des délais dépassés, des budgets explosés, et un site livré qui ne correspond pas aux attentes initiales.
Le cahier des charges n’est pas un document administratif qu’on produit pour faire sérieux. C’est l’outil qui force toutes les parties à aligner leur compréhension du projet avant que le premier centime soit dépensé et la première ligne de code écrite. Et pour un projet WordPress, il a des spécificités que les modèles génériques de cahier des charges ne couvrent pas.
Chiffre clé : selon McKinsey, 45 % des projets web dépassent leur budget initial, et 7 % coûtent le double de ce qui était prévu. Dans la quasi-totalité des cas, l’absence ou la faiblesse du cahier des charges est la cause principale de ces dérives.
Ce guide vous donne le modèle complet — section par section — pour rédiger un cahier des charges WordPress qui protège votre projet, cadre votre prestataire et maximise vos chances de succès.
Pourquoi le cahier des charges WordPress a ses propres spécificités ?
Un cahier des charges pour un site sur mesure en React ou en Laravel n’est pas structuré comme un cahier des charges WordPress. Pourquoi ? Parce que WordPress repose sur un écosystème de thèmes, de plugins et de configurations qui influencent directement les décisions de conception.
Préciser dans un cahier des charges WordPress si vous utilisez un constructeur de blocs Gutenberg natif ou un page builder comme Elementor change la façon dont un développeur évalue la charge de travail. Préciser si vous avez besoin de WooCommerce, de multilingue avec WPML ou d’un espace membre change radicalement l’architecture du projet. Ces précisions n’ont pas d’équivalent dans un projet de développement sur mesure.
Un bon cahier des charges WordPress doit donc couvrir à la fois les dimensions universelles de tout projet web (objectifs, cible, contenu, budget) et les dimensions spécifiques à l’écosystème WordPress (choix du thème, liste des plugins, structure des permaliens, configuration SEO, hébergement).
Section 1 — Présentation du projet et contexte
C’est la section que tout le monde rédige trop vite — et qui est pourtant la plus lue par les prestataires pour évaluer si le projet leur correspond.
Ce qu’elle doit contenir :
La description de l’entreprise ou de l’activité en quelques lignes — secteur, taille, zone géographique, positionnement. L’objectif principal du site formulé de façon précise et mesurable : « générer 20 demandes de devis par mois via le formulaire de contact », « vendre directement en ligne avec un objectif de 50 commandes mensuelles dans les six premiers mois », « positionner l’entreprise sur les trois premières pages Google pour cinq requêtes prioritaires dans notre secteur ».
La formulation de l’objectif est critique. « Avoir un beau site professionnel » n’est pas un objectif — c’est un résultat subjectif non mesurable. Un objectif de cahier des charges doit être spécifique, mesurable et temporellement borné.
Incluez également le contexte du projet : s’agit-il d’une création from scratch, d’une refonte d’un site existant, d’une migration depuis une autre plateforme (Wix, Squarespace, Joomla) ? Si c’est une refonte, listez les éléments à conserver impérativement — notamment les URLs existantes qui ont du trafic organique, pour éviter une migration SEO catastrophique.
Section 2 — Définition de la cible et des personas
Un site WordPress efficace est un site conçu pour une audience précise, pas pour tout le monde. Cette section oblige à formaliser ce que vous savez (ou devez découvrir) sur vos visiteurs cibles.
Ce qu’elle doit contenir :
La description de un à trois personas — profils types de vos visiteurs idéaux. Pour chaque persona : âge, profession, niveau de maturité digitale, appareil utilisé (mobile ou desktop), intention de recherche principale et objections courantes avant de passer à l’action.
L’intention de recherche est particulièrement importante pour orienter la stratégie de contenu et la structure des pages. Un visiteur en phase de découverte (intention informationnelle) n’arrive pas sur les mêmes pages et ne convertit pas via les mêmes mécanismes qu’un visiteur en phase de décision (intention transactionnelle).
Précisez également la répartition mobile/desktop attendue. Chiffre clé : selon Statista, 58 % du trafic web mondial provient des appareils mobiles en 2024. Un cahier des charges qui ne mentionne pas explicitement la priorité mobile laisse une zone d’ambiguïté sur les choix de design et de performance — et ce sont les Core Web Vitals sur mobile qui comptent pour le référencement naturel.
Section 3 — Architecture et arborescence du site
C’est la section technique qui structure toute la réflexion sur le cocon sémantique et le maillage interne. Elle doit être rédigée avant de choisir un thème ou de commencer le développement.
Ce qu’elle doit contenir :
La liste exhaustive des pages du site, organisées en arborescence hiérarchique. Pour chaque page : son titre provisoire, son URL cible (ex : /services/creation-site-wordpress/), son objectif de conversion, et sa position dans l’architecture (page pilier ou page satellite).
Un exemple d’arborescence pour un site vitrine d’agence web WordPress :
- Accueil →
/ - Services →
/services/- Création de site WordPress →
/services/creation-site-wordpress/ - Refonte de site →
/services/refonte-site-web/ - Maintenance WordPress →
/services/maintenance-wordpress/
- Création de site WordPress →
- Réalisations →
/realisations/ - Blog →
/blog/ - À propos →
/a-propos/ - Contact →
/contact/
Cette arborescence doit être validée par toutes les parties avant le début du projet. La modifier en cours de développement a un coût — la modifier après la mise en ligne a un coût encore plus élevé en redirections 301 et en travail de reconstitution du jus SEO.
Précisez également dans cette section la structure des permaliens choisie — typiquement « Nom de l’article » pour le blog et des URLs courtes et descriptives pour les pages statiques.
Section 4 — Fonctionnalités et spécifications techniques WordPress
C’est la section qui différencie un cahier des charges WordPress d’un cahier des charges générique. Elle doit lister explicitement les choix techniques qui vont structurer le développement.
Ce qu’elle doit contenir :
Un tableau des fonctionnalités par ordre de priorité (indispensable / souhaitable / optionnel) :
| Fonctionnalité | Priorité | Solution envisagée | Commentaire |
|---|---|---|---|
| Formulaire de contact | Indispensable | WPForms | Avec notifications email |
| Blog avec catégories | Indispensable | WordPress natif | — |
| Optimisation SEO | Indispensable | Rank Math | Config complète incluse |
| Cache et performance | Indispensable | WP Rocket | Budget plugin à prévoir |
| Sauvegardes auto | Indispensable | UpdraftPlus | Stockage Google Drive |
| Sécurité | Indispensable | Wordfence | — |
| E-commerce | Optionnel | WooCommerce | Phase 2 si pertinent |
| Multilingue | Optionnel | WPML | Selon développement international |
| Réservation en ligne | Souhaitable | Amelia | À confirmer selon budget |
Précisez également : le thème WordPress retenu ou les critères de sélection, le constructeur de blocs utilisé (Gutenberg natif recommandé ou page builder si justifié), la version PHP cible, l’hébergeur et le plan retenu.
Section 5 — Stratégie SEO et contenu
Un cahier des charges qui ne mentionne pas le SEO livre un site techniquement fonctionnel mais invisible. Cette section doit être rédigée en cohérence avec l’arborescence (section 3) et les personas (section 2).
Ce qu’elle doit contenir :
La liste des mots clés prioritaires par page stratégique — idéalement issus d’une recherche de mots clés préalable via Ahrefs, SEMrush ou Ubersuggest. Pour chaque page : le mot clé principal, les mots clés secondaires associés, le volume de recherche mensuel estimé et l’intention de recherche (informationnelle, commerciale, transactionnelle).
La description du cocon sémantique envisagé : quelles sont les pages piliers, quelles sont les pages satellites, et quel est le maillage interne prévu entre elles — avec les ancres de lien descriptives à utiliser.
Les spécifications SEO techniques à inclure dans le développement : balises title et meta description personnalisées pour chaque page, données structurées Schema.org adaptées au type de site (Organisation, LocalBusiness, Article, Product selon les cas), sitemap XML automatique, balise canonical configurée, et connexion à Google Search Console et Google Analytics 4.
Section 6 — Charte graphique et identité visuelle
Cette section évite les allers-retours infinis sur le design — à condition d’être suffisamment précise.
Ce qu’elle doit contenir :
Les éléments existants à intégrer : logo (formats vectoriels SVG ou AI demandés), palette de couleurs (codes hexadécimaux), typographies utilisées, éléments de charte graphique disponibles. Si ces éléments n’existent pas encore, précisez si leur création est incluse dans le périmètre du projet ou gérée séparément.
Des références visuelles : trois à cinq URLs de sites dont vous appréciez le design — avec une note sur ce qui vous plaît spécifiquement (la mise en page, les couleurs, la typographie, la façon dont les services sont présentés). Ces références sont bien plus utiles qu’une description verbale du style souhaité.
Les contraintes d’accessibilité : conformité WCAG 2.1 niveau AA si votre audience inclut des personnes en situation de handicap, ou si vous êtes soumis aux obligations légales d’accessibilité (secteur public, grandes entreprises).
Section 7 — Budget, planning et livrables
La section que tout le monde évite de rédiger précisément — et qui est pourtant celle qui protège le plus le projet.
Ce qu’elle doit contenir :
Le budget global : une fourchette réaliste, pas un plafond arbitraire. Un budget affiché de 1 500 € pour un site e-commerce multilingue avec espace client est une contradiction — elle génère des devis bâclés ou des prestataires qui acceptent en sachant qu’ils sur-factureront les modifications.
Le découpage par poste si vous le connaissez : conception graphique, développement, intégration du contenu, configuration SEO, formation, maintenance la première année.
Le planning cible avec les jalons clés :
- Date de validation du cahier des charges
- Date de livraison des maquettes graphiques
- Date de livraison du site en recette (environnement de test)
- Date de validation client
- Date de mise en ligne
- Période de garantie post-livraison
Les livrables attendus : fichiers sources du design (Figma), accès hébergeur et FTP, accès administrateur WordPress, documentation d’utilisation, session de formation, contrat de maintenance.
FAQ — Cahier des charges WordPress : les vraies questions
Avant — sans exception. Contacter des prestataires sans cahier des charges génère des devis incomparables, basés sur des interprétations différentes du même projet. Vous ne pouvez pas évaluer la pertinence d'un devis si vous n'avez pas défini précisément ce que vous demandez. Le cahier des charges est le document de référence qui permet de comparer des offres sur une base commune. En pratique, une première version sommaire suffit pour un premier contact — mais la version complète doit être finalisée avant toute validation de devis.
La réponse courte : le client rédige la partie métier (objectifs, cible, contenu, budget, planning), le prestataire peut contribuer à la partie technique (choix des plugins, architecture, spécifications de développement). Un prestataire qui propose de rédiger l'intégralité du cahier des charges à votre place travaille dans son intérêt, pas nécessairement dans le vôtre — il définira les spécifications selon ses compétences et ses habitudes, pas selon vos besoins réels. Des outils comme Notion ou Google Docs facilitent la co-rédaction collaborative.
Oui — et c'est l'un des oublis les plus fréquents. La livraison du site n'est pas la fin du projet : c'est le début de sa vie opérationnelle. Le cahier des charges doit préciser ce qui se passe après la mise en ligne : qui gère les mises à jour WordPress, les sauvegardes, la surveillance de sécurité, les corrections de bugs. Si un contrat de maintenance WordPress est prévu, ses modalités (fréquence, périmètre, tarif, délai d'intervention) doivent être définies dès le cahier des charges — pas négociées dans l'urgence quand le premier problème arrive.
