Cahier des charges site internet : un modèle simple

À quoi sert vraiment un cahier des charges de site internet ?

Un cahier des charges n’est pas un document réservé aux grands projets ni une façon de transformer une idée en dossier de cinquante pages. C’est un point de départ écrit : il explique le problème à résoudre, les personnes concernées et le résultat attendu. Son rôle est de rendre les échanges plus concrets avant de parler d’outil, de maquette ou de prix.

Sans ce cadre, deux personnes peuvent entendre « refaire le site » et imaginer deux projets opposés. L’une pense à moderniser quelques pages ; l’autre imagine une nouvelle identité, un espace client et une reprise de contenus. Poser les éléments à plat évite de comparer des devis qui ne couvrent pas le même travail.

Le document n’a pas besoin d’être parfait pour être utile. Il doit plutôt distinguer ce qui est déjà certain de ce qui reste une question. Une création de site internet se cadre beaucoup mieux avec des réponses honnêtes et incomplètes qu’avec une liste de fonctions copiée sur le site d’un concurrent.

• Le problème à résoudre en une ou deux phrases.
• Le résultat concret attendu pour les visiteurs et pour l’équipe.
• Les points certains, et les décisions encore à prendre.
• Une personne qui peut valider le périmètre au fil du projet.

Commencer par l’objectif et les personnes qui utiliseront le site

La première question n’est pas « quelles pages faut-il ? », mais « qu’est-ce qu’une personne doit réussir à faire ici ? ». Demander un devis, prendre rendez-vous, comprendre une offre, acheter un produit, déposer un dossier ou accéder à un espace privé ne produisent pas le même parcours.

Décrivez ensuite les personnes concernées avec des mots simples : un prospect qui ne connaît pas encore l’entreprise, un client déjà engagé, un revendeur, une équipe interne, un candidat. Pour chacun, notez ce qu’il cherche, ce qui peut le bloquer et l’action qui compte. Cette étape donne une architecture plus solide que la reproduction d’un menu existant.

Un objectif principal peut cohabiter avec des objectifs secondaires, mais il faut les classer. Un site qui essaie de vendre, recruter, informer, recruter des partenaires et servir d’outil interne dès sa page d’accueil peut tout faire moins bien. Le cahier des charges aide précisément à choisir ce qui doit passer en premier.

• Quelle action principale doit faire un visiteur en moins de deux minutes ?
• À qui le site parle-t-il en priorité ?
• Quelles informations doivent rassurer avant cette action ?
• Quelle mesure dira que le site rend réellement service ?

Définir le bon format : site vitrine, boutique ou application

Un cahier des charges utile précise la nature du projet sans se précipiter sur la technologie. Un site vitrine présente une activité et facilite une prise de contact. Une boutique ajoute un catalogue, un panier, un paiement et une gestion de commande. Une application fait travailler des personnes avec des comptes, des données, des droits ou des règles qui évoluent.

Cette frontière est importante car elle change les questions à poser. Un site de présentation a surtout besoin de contenus clairs, de preuves et d’un parcours de contact. Une boutique doit aussi traiter les produits, les livraisons, les retours et la relation après achat. Un outil avec des comptes demande de définir les rôles, les données visibles, l’historique et les responsabilités.

Le guide des technologies web vient seulement après cette décision : il aide à choisir le socle adapté. Lorsque le cœur du besoin consiste à faire circuler des données ou à appliquer des règles métier, un développement d’application web peut être plus cohérent qu’un site auquel on ajoute des contournements.

Lister les contenus à prévoir avant de parler de design

Les contenus sont souvent ce qui bloque un lancement : textes, photos, fiches produit, tarifs, études de cas, avis, documents ou traductions. Le cahier des charges doit indiquer ce qui existe déjà, ce qui doit être réécrit et qui peut le valider. Ce n’est pas une formalité éditoriale : une page sans contenu prêt ne devient pas claire parce que sa maquette est terminée.

Il est utile d’écrire une première arborescence, même imparfaite. Accueil, offres, réalisations, à propos, ressources, contact : ces intitulés ne sont pas une obligation. Ils servent à vérifier que chaque information a une place et que les visiteurs n’ont pas à deviner où aller. Si une section ne peut pas être décrite en une phrase, elle n’est probablement pas encore prête à devenir une page.

Pour chaque contenu important, notez un responsable et un moment de livraison. Cela permet d’organiser les validations sans demander à la fin du projet des textes, photos ou traductions qui n’avaient jamais été anticipés.

• Pages ou sections attendues, même sous forme de brouillon.
• Textes, images, documents et données déjà disponibles.
• Contenus à produire, à relire ou à traduire.
• Une personne identifiée pour chaque validation.

Décrire les fonctions par usage, pas par noms de modules

Écrivez ce que la personne doit pouvoir faire, plutôt que le nom d’un plugin ou d’une technologie. « Le visiteur peut choisir un créneau et reçoit une confirmation » est plus utile que « intégrer un agenda ». « L’équipe peut modifier une fiche produit sans casser la mise en page » décrit mieux le besoin qu’une liste d’extensions.

Les fonctionnalités utiles à préciser sont celles qui changent vraiment le périmètre : formulaires, prise de rendez-vous, paiement, catalogue, langues, connexion à un CRM, espace client, rôles d’accès, import de données, signature ou automatisations. Elles doivent être accompagnées de règles simples : qui y accède, quelles données sont nécessaires, qu’est-ce qui déclenche une action, et que se passe-t-il en cas d’erreur.

Une idée future peut être mentionnée sans être financée tout de suite. Séparez les indispensables au lancement, les améliorations à prévoir ensuite et les hypothèses encore floues. Cette distinction protège le budget comme le calendrier, tout en gardant une trajectoire visible.

• Fonctions indispensables au lancement.
• Fonctions souhaitables, mais reportables.
• Données à saisir, à lire, à importer ou à exporter.
• Rôles et droits de chaque personne qui se connecte.

Prévoir le référencement et la reprise de l’existant dès le départ

Le référencement ne se résume pas à ajouter des mots-clés à la fin. Il commence avec les sujets que les pages doivent traiter, les titres compréhensibles, les contenus réellement utiles et des adresses stables. Dans le cahier des charges, notez les services ou questions que le site doit expliquer, les zones géographiques réellement couvertes et les pages qui portent déjà de la visibilité.

Lors d’une refonte, l’inventaire du site existant est aussi important que la nouvelle maquette. Les anciennes adresses, contenus qui reçoivent des visites, formulaires, documents et outils de mesure doivent être identifiés avant la bascule. Le guide de refonte sans perte de référencement détaille cette préparation.

Il faut enfin prévoir qui mettra les contenus à jour après livraison. Un site que personne ne peut faire vivre perd rapidement son intérêt, quelle que soit sa base technique. Le référencement SEO se travaille dans la durée, avec des pages utiles et des décisions observées plutôt qu’avec des promesses de position.

• Pages existantes à conserver, améliorer, fusionner ou rediriger.
• Requêtes et sujets réellement liés à l’offre.
• Accès aux statistiques, au nom de domaine et à l’hébergement.
• Personne responsable des publications après la mise en ligne.

Parler budget et calendrier sans demander un chiffre au hasard

Un budget utile n’est pas forcément un montant arrêté. Il peut prendre la forme d’une enveloppe, d’un ordre de grandeur ou de plusieurs scénarios : une première version essentielle, une version plus complète et une extension ultérieure. L’important est de dire ce qui est compris : contenus, design, développement, migration, hébergement, maintenance, formation et suivi.

Le calendrier doit également s’appuyer sur des dépendances réelles. Une date de lancement ne dit pas si les textes, photos, traductions, produits, accès et validations seront prêts à temps. Notez les contraintes externes — événement, ouverture, fin de contrat, campagne — puis les personnes qui doivent valider chaque étape.

Cette transparence permet de comparer des propositions sur le même périmètre. Un devis moins élevé n’est pas nécessairement moins adapté ; il peut simplement inclure moins de pages, moins de reprise, moins d’accompagnement ou moins de fonctions. Une estimation aide à remettre ces paramètres dans un ordre concret avant de demander un chiffrage détaillé.

• Enveloppe ou scénarios de budget plutôt qu’un prix isolé.
• Date cible, contraintes externes et marges de validation.
• Ce qui est inclus après la mise en ligne.
• Ce qui dépend de contenus, d’accès ou de décisions côté équipe.

Un modèle simple à remplir avant le premier rendez-vous

Vous pouvez tenir le premier cahier des charges sur quelques pages. L’objectif n’est pas de produire une spécification technique exhaustive : l’équipe qui réalisera le projet doit encore proposer et expliquer les choix. Ce document sert à ce que tout le monde commence avec le même problème, le même ordre de priorité et les mêmes contraintes visibles.

Commencez par répondre avec vos propres mots. Les zones où vous hésitez sont précieuses : elles deviennent les premières questions du rendez-vous. Un prestataire sérieux ne vous demandera pas de choisir seul l’hébergement, le CMS ou le framework avant d’avoir compris les usages ; il vous aidera à traduire ce document en solution et en périmètre.

• 1. Contexte : activité, déclencheur et problème actuel.
• 2. Objectif : résultat attendu pour le visiteur et pour l’entreprise.
• 3. Publics : personnes visées, besoins et actions attendues.
• 4. Contenus : pages, documents, photos, preuves et responsables.
• 5. Fonctions : indispensables, souhaitables et plus tard.
• 6. Contraintes : langues, outils existants, données, délais et accès.
• 7. Budget et suite : enveloppe, date, personnes qui valident et prochaines décisions.

Le document ouvre la discussion ; il ne remplace pas le cadrage

Un cahier des charges réduit les zones floues, mais il ne remplace ni l’échange ni les arbitrages. Certaines réponses apparaissent seulement en regardant les contenus, les contraintes techniques ou les parcours réels. Le bon signe n’est pas un document rempli de jargon : c’est la capacité de comprendre ce qui doit être décidé maintenant et ce qui peut attendre.

Si vous avez déjà ces éléments, même sous forme de notes, vous pouvez les utiliser pour parler de votre projet ou lancer une estimation. Le premier échange peut alors se concentrer sur les priorités, les risques et la première version utile plutôt que sur une liste abstraite de technologies.