Stratégie digitale
Cahier des charges de refonte de site B2B : modèle complet et critères d’acceptation
Un cahier des charges de refonte B2B devient utile lorsqu’il rend les offres et la recette comparables. Une liste de souhaits — moderne, rapide, intuitif — ne suffit pas à décider si le résultat livré est acceptable.
Cette méthode relie chaque exigence critique à cinq champs : résultat attendu, critère d’acceptation, preuve, responsable et statut bloquant. Le modèle DOCX de huit pages est accessible sans formulaire.
Épisode long
Approfondir l’analyse avec l’épisode Edikka.
Une version longue pour replacer les chiffres, les arbitrages et les conséquences opérationnelles de cette analyse.
Durée : 8:57.
Compagnon audio
Une exigence utile prépare déjà sa propre recette.
L’épisode 12 resserre le cahier des charges autour d’une règle opérationnelle : chaque attente critique doit produire un résultat observable, une preuve et une décision attribuée.
Le document ne remplace ni la conception ni le conseil de l’agence. Il sépare ce que l’entreprise décide de ce que le prestataire recommande, puis rend les engagements comparables.
Une liste de souhaits décrit une ambition. Un cahier des charges vérifiable prépare une décision et une recette.
Règle des cinq champs
Transformer chaque exigence critique en contrôle rejouable.
| Champ | Question | Sortie attendue |
|---|---|---|
| Exigence | Quel besoin doit être satisfait ? | Un résultat, sans imposer trop tôt la solution. |
| Acceptation | Dans quelles conditions le résultat est-il acceptable ? | Un comportement observable et testable. |
| Preuve | Quelle trace permettra de rejouer le contrôle ? | Scénario, rapport, journal, export ou accès contrôlé. |
| Responsable | Qui réalise, vérifie et décide ? | Des rôles nommés des deux côtés du projet. |
| Blocage | L’écart empêche-t-il la mise en ligne ? | Oui, non ou conditionnel, avec la condition explicitée. |
Comparer les propositions
Trois conditions éliminatoires avant de comparer les prix.
La propriété et les modalités de transfert sont explicites.
Domaines, dépôts, code, contenus, comptes, données, licences et formats de restitution sont inventoriés.
La validation et la migration sont décrites avant le lancement.
Critères d’acceptation, environnement, anomalies, mapping d’URL et décision de mise en ligne sont documentés.
Chaque livrable possède des acteurs, des dépendances et des exclusions.
Le prix devient comparable lorsque les responsabilités et les hypothèses le sont aussi.
Passer à l’action
Partir d’un modèle court, puis déplacer le détail vers des annexes utiles.
Réponse courte
Un bon cahier des charges ne décrit pas seulement le site attendu. Il rend chaque engagement vérifiable.
Pour cadrer une refonte B2B, ne demandez pas seulement une page d’accueil moderne, un site rapide ou un formulaire relié au CRM. Pour chaque exigence importante, précisez le résultat attendu, le critère d’acceptation, la preuve à fournir, le responsable et le caractère bloquant ou non.
Cette structure transforme un document d’intention en outil de décision. Elle permet de comparer des propositions, de limiter les zones grises pendant le projet et de prononcer une recette sur des faits plutôt que sur des impressions.
Le modèle DOCX prêt à compléter accompagne ce guide. Il tient en huit pages et reste volontairement indépendant d’un CMS ou d’une agence.
Exigence · critère d’acceptation · preuve attendue · responsable · bloquant.
Rôle du document
Le cahier des charges fixe le problème et les règles de décision, pas une solution technique inventée trop tôt.
France Num présente le cahier des charges comme un support pour formaliser les besoins, comparer les prestataires, piloter le projet et encadrer la relation. Dans une refonte B2B, sa valeur tient surtout à la séparation entre ce que l’entreprise doit décider et ce que le prestataire doit recommander.
| L’entreprise décide | Le prestataire recommande | La proposition doit expliciter |
|---|---|---|
| Objectifs d’affaires, publics prioritaires, contraintes métier, responsables internes, enveloppe et échéances impératives. | Architecture, parcours, méthode de conception, socle technique, dispositif de mesure et séquence de migration. | Hypothèses, inclusions, exclusions, dépendances, livrables, validations, propriété, maintenance et conditions de changement. |
Exprimez le besoin d’administration, les rôles, les intégrations, la réversibilité et les contraintes de sécurité. Demandez ensuite à chaque candidat de justifier sa solution. Un nom de technologie n’est ni un besoin utilisateur ni un critère d’acceptation.
Structure vérifiable
Remplacer les adjectifs par des conditions observables.
« Rapide », « intuitif », « sécurisé » ou « optimisé SEO » sont des intentions. Elles ne disent ni ce qui sera testé, ni par qui, ni avec quel résultat attendu. Le tableau ci-dessous montre comment passer d’une demande vague à une exigence contrôlable.
| Exigence | Critère d’acceptation | Preuve attendue | Responsable | Bloquant |
|---|---|---|---|---|
| Formulaire commercial | Un envoi valide crée le contact attendu, affiche une confirmation compréhensible et déclenche la notification prévue. Les erreurs sont annoncées et associées aux champs. | Scénarios de recette horodatés et contact de test visible dans l’outil cible. | Agence + référent CRM | Oui |
| Administration | Un éditeur autorisé peut créer, prévisualiser, corriger et publier un contenu type sans intervention technique. | Test utilisateur sur le back-office et guide de prise en main livré. | Agence + éditeur métier | Oui |
| Contenus et gabarits | Pour tout gabarit déclaré prioritaire et bloquant, les champs obligatoires, les règles d’affichage, les preuves, l’appel à l’action, le propriétaire éditorial et la règle de mise à jour convenus sont présents. | Inventaire des gabarits, contenus de test intégrés et revue éditoriale sur les pages représentatives. | Agence + responsables contenus | Conditionnel |
| Recherche interne | Lorsque la recherche interne appartient à un parcours déclaré critique, le corpus de requêtes convenu renvoie des résultats pertinents, l’état sans résultat propose une issue utile et le parcours reste utilisable au clavier. | Corpus de tests daté, résultats observés, anomalies et contre-vérification après correction. | Agence + référent métier | Conditionnel |
| Accessibilité | Le périmètre, le référentiel et sa version, l’échantillon, la méthode de test et le niveau attendu sont définis avant la recette. Toute anomalie classée bloquante par le protocole convenu empêche le go tant qu’elle n’est pas corrigée ou couverte par une dérogation documentée. | Rapport de contrôle, anomalies classées, corrections et contre-vérification. | Prestataire désigné | Conditionnel |
| Performance | Les pages et conditions de mesure sont fixées, ainsi que les seuils contractuels retenus. Les seuils qui conditionnent le go/no-go sont nommés avant les mesures. Une note Lighthouse isolée n’est pas utilisée comme unique preuve. | Rapport reproductible, environnement précisé et relevés réels après disponibilité suffisante. | Agence | Conditionnel |
| Migration SEO | Chaque ancienne URL critique reçoit une décision documentée : maintien, 301/308 directe, consolidation ou 404/410. | Matrice validée, crawl de recette, codes HTTP et destinations finales. | Agence + référent contenu | Oui |
| Mesure et consentement | Les événements autorisés remontent avec les paramètres attendus. Aucun traceur soumis à consentement n’est déclenché avant le choix de l’utilisateur. | Plan de marquage, journal de tests et inspection du navigateur avant/après consentement. | Agence + DPO ou conseil | Oui |
| Sécurité et restauration | Les rôles, sauvegardes, délais de reprise, perte de données maximale admise et procédure d’incident sont définis puis un scénario de restauration convenu est rejoué. Le blocage s’applique aux scénarios déclarés critiques avant la recette. | Journal du test de restauration, durée observée, écarts, corrections et responsables d’escalade. | Hébergeur + agence + référent sécurité | Conditionnel |
| Propriété et réversibilité | Les dépôts, comptes, données, domaines, licences et livrables prévus sont détenus ou transférables selon les conditions écrites dans la proposition. | Inventaire de restitution, accès contrôlés, exports ouverts et procédure de transfert testée sur le périmètre convenu. | Direction cliente + agence | Oui |
La colonne « Bloquant » accepte uniquement trois valeurs : Oui, Non ou Conditionnel. Lorsqu’une exigence est conditionnelle, la condition figure dans le critère d’acceptation, jamais dans le statut. Ces formulations montrent une méthode, pas des garanties prêtes à copier : les seuils et obligations doivent être adaptés au projet puis écrits dans la proposition retenue.
Trame complète
Les huit parties d’un cahier des charges de refonte B2B exploitable.
Contexte et existant
Décrire l’entreprise, le rôle du site actuel et les contraintes déjà connues.
Offres, marchés, langues, gouvernance, technologies, hébergement, outils tiers, dette connue, accès disponibles et raisons de la refonte.
Objectifs et référence
Hiérarchiser les résultats recherchés et conserver la situation avant refonte.
Demandes qualifiées, usages, téléchargements, visibilité, coûts d’administration, données actuelles, mode de calcul et fenêtre de comparaison.
Publics et parcours B2B
Nommer les décideurs, utilisateurs, prescripteurs et objections qui structurent le parcours.
Contexte de recherche, niveau de maturité, informations nécessaires, preuves attendues, action suivante et contraintes d’accessibilité ou de langue.
Contenus et périmètre
Inventorier les contenus, les gabarits et les responsabilités éditoriales.
Pages conservées, fusionnées, supprimées ou créées, langues, médias, preuves, auteurs, validation, reprise de contenu et volume par type.
Fonctions et connexions
Décrire les scénarios métier et les systèmes reliés, pas seulement une liste de modules.
Formulaires, recherche, espace privé, CRM, ERP, recrutement, newsletter, consentement, rôles, erreurs, sécurité, données entrantes et sortantes.
Qualité et conformité
Définir comment seront contrôlés l’UX, l’accessibilité, la performance, la sécurité et la vie privée.
Référentiels et versions, échantillons, appareils, navigateurs, outils, tests humains, seuils, anomalies bloquantes, traces et responsabilités de validation. Pour une recette prévue en 2027, prévoir une clause de réexamen à la publication du RGAA 5 afin de décider explicitement des critères applicables.
Visibilité et mesure
Préparer SEO, citabilité, migration, données structurées et analytics avant le développement final.
Inventaire d’URL, mapping, canonicals, hreflang, maillage, métadonnées, données structurées, accès robots, sitemaps, événements et tableau de bord.
Projet et après-projet
Fixer livrables, acteurs, validations, propriété, budget, calendrier, maintenance et réversibilité.
Jalons, disponibilité client, délais de réponse, format des livrables, critères d’acceptation, corrections, transfert d’accès, documentation et responsabilités après lancement.
État de référence
Aucune promesse de progrès n’est interprétable sans mesure avant la refonte.
Un objectif comme « augmenter les demandes qualifiées » reste incomplet si le projet ne conserve pas la définition d’une demande qualifiée, la période de référence, les sources de données et les événements effectivement mesurés. Le cahier des charges doit demander la conservation de cet état avant que le site actuel ne soit remplacé.
| Dimension | État à conserver | Limite à documenter |
|---|---|---|
| Commercial | Formulaires commencés et envoyés, rendez-vous, téléchargements, appels identifiables et qualification manuelle. | Définition, consentement, doublons, saisonnalité et part non attribuable. |
| Contenu | Pages, gabarits, propriétaires, dates, preuves, liens entrants, usages et décisions de migration. | Inventaire incomplet, données absentes ou contenus hors site. |
| Recherche | Impressions, clics, requêtes, pages, indexabilité, canonicals, liens et sitemaps. | Fenêtre, agrégation, retard des outils et changement de canonique. |
| Expérience et qualité | Parcours testés, irritants connus, performance terrain disponible, anomalies d’accessibilité et incidents. | Échantillon, appareils, réseau, trafic insuffisant et tests non rejouables. |
Comparer les réponses
Demander la même structure de réponse à chaque agence, sans fabriquer un score global trompeur.
Un total sur 20 donne une apparence de précision à des décisions hétérogènes. Utilisez plutôt trois conditions éliminatoires, puis une revue de complétude documentaire. Le prix n’est comparable que lorsque les hypothèses et exclusions le sont aussi.
| Condition | Réponse minimale attendue | Signal d’arrêt |
|---|---|---|
| Propriété et réversibilité | Qui possède le code, les contenus, le domaine, les comptes, les données et les accès ; dans quel format ils sont restitués. | Dépendance non déclarée ou accès essentiels détenus sans procédure de transfert. |
| Recette et migration | Critères d’acceptation, responsabilités, matrice d’URL, environnement de test, correction des anomalies et décision de mise en ligne. | Mise en ligne assimilée à une simple vérification visuelle ou migration repoussée après le développement. |
| Périmètre et responsabilités | Livrables, acteurs réellement mobilisés, dépendances client, exclusions, options et procédure de changement. | Formulations globales impossibles à rattacher à un livrable ou à un responsable. |
Edikka est une agence de refonte. Cette méthode n’est donc pas présentée comme un classement indépendant. Notre page d’offre documente publiquement les familles de livrables, la méthode, des projets accessibles et le déroulé du premier échange. Le budget, le calendrier détaillé, l’équipe nominative, les seuils de recette, les responsabilités et les exclusions figurent dans chaque proposition. Le socle technique et les critères précis dépendent du diagnostic.
Limites utiles
Cinq demandes à ne pas transformer en obligations aveugles.
| Demande fragile | Formulation plus utile |
|---|---|
| « Lighthouse 100 partout » | Définir les pages, appareils, conditions, métriques, seuils et preuves nécessaires à l’usage réel. |
| « Première position Google » | Exiger les livrables et contrôles SEO maîtrisables ; aucun prestataire ne contrôle un classement. |
| « Site cité par les IA » | Demander accessibilité technique, réponses sourcées, preuves, suivi daté et limites d’attribution ; aucune citation n’est garantie. |
| « Design validé au pixel près avant exploration » | Fixer les objectifs, contenus, composants, principes de marque, parcours et étapes de validation. |
| « Toutes les anciennes URL vers l’accueil » | Décider URL par URL selon l’équivalence d’intention ; conserver, rediriger, consolider ou supprimer correctement. |
Modèle ouvert
Télécharger le cahier des charges éditable ou consulter sa version Markdown.
Le DOCX est conçu comme un document de travail de huit pages. Supprimez les rubriques sans objet, conservez les décisions inconnues comme questions ouvertes et demandez aux agences de distinguer clairement ce qui est inclus, optionnel ou exclu.
Le modèle DOCX et sa version Markdown sont proposés sous licence Creative Commons Attribution 4.0 International. Vous pouvez les adapter et les redistribuer, y compris commercialement, à condition de créditer Edikka et de relier la page canonique de cet article.
Limite volontaire
Ce modèle n’est ni un contrat, ni un audit juridique, ni une garantie de résultat.
Le document aide à cadrer une consultation. Les obligations applicables en matière d’accessibilité, de données personnelles, de sécurité, de propriété intellectuelle ou de conservation dépendent de l’organisation, des publics, des données et des services concernés. Elles doivent être validées par les personnes compétentes puis reprises dans les pièces contractuelles.
Les exemples de critères permettent une recette rejouable. Ils ne prouvent pas un gain avant/après et ne garantissent ni conversion, ni position dans un moteur, ni citation par un service d’IA.
Sources de référence
Les recommandations externes utilisées pour construire la trame.
- France Num — Bâtir le cahier des charges du site internet de son entreprise, publié le 20 mars 2026 et mis à jour le 23 mars 2026.
- France Num — Modèles de cahiers des charges pour un site internet d’entreprise, mis à jour le 7 mai 2026.
- Google Search Central — Site moves and migrations, pour la préparation, le mapping, les redirections et le suivi.
- DINUM — Référentiel général d’amélioration de l’accessibilité, RGAA 4.1.2, pour la méthode de contrôle.
- DINUM — Une nouvelle version du RGAA prévue fin 2026, pour anticiper contractuellement la transition vers le RGAA 5 sans présumer de son application au projet.
- CNIL — Questions-réponses sur les cookies et autres traceurs, mise à jour le 29 avril 2026.
Conclusion
Le meilleur cahier des charges réduit les ambiguïtés sans empêcher le conseil.
Une refonte B2B réussie n’est pas la simple exécution d’une liste de pages. C’est une succession de décisions sur les objectifs, les parcours, les contenus, les fonctions, la qualité, la migration et l’après-projet. Le cahier des charges doit rendre ces décisions visibles, attribuées et vérifiables.
La méthode de refonte Edikka réunit stratégie, UX/UI, développement et SEO/GEO dans un même périmètre. Le modèle ci-dessus peut être utilisé avant de nous consulter, y compris pour comparer Edikka à d’autres agences.
Position Edikka
Un bon cahier des charges réduit les ambiguïtés sans empêcher le conseil.
Il fixe les objectifs, les contraintes et les règles de décision. Il demande ensuite à chaque agence de justifier sa méthode et sa solution.
Hiérarchiser le besoin
Objectifs, publics, contraintes et hors-périmètre deviennent visibles avant la solution.
Nommer les responsabilités
Chaque livrable, validation, dépendance et décision appartient à une personne identifiée.
Prouver l’acceptation
Les critères et traces attendues remplacent les adjectifs impossibles à contrôler.
Pour aller plus loin sur ce sujet
Des réponses complémentaires pour clarifier les points essentiels abordés dans cet article.
