Aller au contenu principal

Cahier des charges d’un site web : modèle pour PME

Préparez votre site avec une trame de cahier des charges : objectifs, pages, contenus, intégrations, recette, maintenance et comparaison des devis.

Publié le
9 min de lecture

Un cahier des charges de site web décrit le besoin, les pages attendues, les contenus disponibles, les fonctions et les critères de validation. Pour une TPE ou une PME, commencez par ce que le visiteur doit comprendre et réussir. Le document permet ensuite de comparer les propositions sur un périmètre commun, de répartir les responsabilités et de décider ce qui doit être prêt au lancement.

La trame ci-dessous est une proposition de préparation, pas une offre commerciale ni un contrat. Vous pouvez la compléter avec vos informations puis l’utiliser pour demander un devis. France Num propose également des modèles de création et de refonte, avec objectifs, organisation des contenus, outils, livrables et budget. Modèles de cahiers des charges France Num.

Quel objectif donner au site avant de lister les pages ?

Écrivez une phrase observable : « un visiteur doit comprendre notre prestation, vérifier que nous intervenons pour son besoin, puis envoyer une demande avec les informations nécessaires ». Un projet de vente ou un espace métier demande un autre parcours. Évitez un objectif qui ne permet pas de choisir les fonctions ou de tester le résultat.

Précisez le public, ses questions, les offres réelles et la prochaine action. Décrivez séparément les visiteurs, les personnes qui mettent à jour le site et celles qui reçoivent les demandes. Cette distinction évite d’oublier l’interface d’administration ou le traitement des contacts.

Séparez les indispensables au lancement des évolutions envisagées. « À prévoir plus tard » ne signifie pas « inclus dans le prix » : une fonction reportée doit avoir un statut explicite. Notre guide de création de site professionnel détaille les étapes et les facteurs qui influencent le budget.

Quelle trame de cahier des charges compléter ?

Pour chaque rubrique, écrivez ce qui est connu, ce qui manque et qui valide la réponse. Une incertitude visible est plus utile qu’une exigence improvisée. Ce tableau sert de modèle de travail ; il ne fixe aucun prix ni délai.

Rubrique Informations à renseigner Décision attendue
Activité et public Offres réelles, besoins des visiteurs, interlocuteur du projet Objectif principal et public prioritaire
Existant Site, pages, outils, domaine, contenus et accès disponibles Éléments à conserver ou améliorer
Pages Sujet, utilité, contenu et action de chaque page Arborescence et limites du périmètre
Contenus Textes, photos, documents, langues et droits de publication Responsable de production et de validation
Fonctions Parcours, données, erreurs possibles et outils connectés Indispensable, option ou évolution
Conception Identité, usages mobiles, navigation et accessibilité Maquettes et critères de validation
Technique Hébergement, comptes, sauvegardes et restrictions connues Responsabilités et conditions de reprise
Recette Scénarios représentatifs et résultats attendus Critères d’acceptation et réserves
Livraison et suivi Documents, formation, maintenance et modalités de sortie Livrables, calendrier et budget détaillés

Ajoutez une date, une version du document et un responsable de validation. Lorsque le besoin change, consignez la décision et son incidence sur coût, délai et recette ; ne laissez pas plusieurs versions concurrentes décider du périmètre.

Comment décrire les fonctionnalités sans vocabulaire technique ?

Pour chaque fonction, décrivez le point de départ, les étapes, le résultat attendu et les cas qui doivent être pris en charge. Nommez les outils existants avec lesquels les informations doivent circuler. Un « formulaire relié au CRM » reste incomplet si personne ne sait quel contact créer ou comment traiter un doublon.

Exemple illustratif fictif : un atelier imaginaire veut recevoir des demandes de réparation. Le formulaire recueille le moyen de réponse et une description du besoin. Après validation, le visiteur voit une confirmation ; l’équipe reçoit la demande dans sa boîte de traitement. Si l’envoi échoue, le visiteur retrouve un moyen de contact et un message compréhensible. Aucun gain commercial n’est présumé.

La recette peut alors vérifier une demande complète, un champ obligatoire absent et un service d’envoi indisponible. Un choix d’architecture viendra ensuite selon le besoin, les connecteurs disponibles et les contraintes d’exploitation. Notre service de développement web présente les types de projets concernés.

Comment préparer les contenus et les références à publier ?

Listez les textes, photographies, logos, documents et langues nécessaires. Pour chaque élément, précisez s’il existe, qui peut le fournir, qui vérifie son exactitude et si sa publication est autorisée. Un portfolio ou un témoignage nécessite des informations confirmées ; une maquette peut utiliser un exemple explicitement fictif sans le présenter comme un client réel.

Conservez les titres, sujets et URLs utiles de l’existant. Si le projet est une refonte, joignez l’inventaire des pages et préparez les déplacements au lieu de faire disparaître les contenus par défaut. Le guide de refonte et migration SEO explique les correspondances d’URL et leur vérification.

Définissez qui écrit, qui relit et combien de validations sont prévues dans la proposition. Distinguez rédaction, traduction, intégration et achat éventuel de visuels. Ajouter un champ « contenu fourni par le client » ne suffit pas à fixer sa date de disponibilité.

Quels critères d’expérience utilisateur et d’accessibilité inclure ?

Décrivez les parcours à réaliser sur mobile et sur ordinateur : trouver une offre, lire ses conditions, naviguer et contacter l’équipe. Demandez des états visibles pour les actions : chargement, réussite, erreur et absence de résultat. La conception UI/UX permet de travailler ces parcours avant le développement.

Préparez des critères d’accessibilité, notamment navigation au clavier, noms des champs, focus visible, structure des titres et alternatives utiles aux images. Le W3C recommande une évaluation tôt et tout au long du projet ; un outil automatique seul ne peut pas déterminer la conformité complète. Prévoyez donc une vérification humaine adaptée. W3C : évaluer l’accessibilité web.

Écrivez le périmètre d’évaluation et les corrections attendues dans la recette. Une formulation telle que « site accessible » ou « design moderne » doit être accompagnée de critères vérifiables. Les obligations propres à l’entreprise et au service doivent être examinées pour définir le besoin applicable.

Que demander pour le SEO et la visibilité dans les IA ?

Précisez les pages destinées à être publiques, leurs sujets et les réponses attendues par les visiteurs. Demandez des titres descriptifs, des URLs cohérentes, des liens internes utiles et un contrôle des règles d’indexation. Identifiez aussi qui vérifie les résultats et dispose des comptes de suivi.

Le guide d’audit SEO PME aide à identifier les priorités ; le guide GEO distingue exploration, indexation et utilisation des contenus par les moteurs de réponse. Une première place ou une citation par un LLM n’est pas garantie par une liste de livrables techniques.

Faites distinguer la préparation SEO initiale du travail continu de mesure et d’amélioration. Un article apporte une réponse propre à une question réelle ; recopier le même contenu pour des variantes de mots clés n’est pas un objectif éditorial utile. Google : créer du contenu utile et fiable.

Comment cadrer les données, les accès et l’après-livraison ?

Recensez les données collectées et leur destination : formulaire, compte client, newsletter ou statistiques selon le site. Demandez pourquoi chaque champ est nécessaire, qui consulte l’information et combien de temps elle est conservée. Prévoyez l’information des personnes au point de collecte, avec des indications compréhensibles sur le traitement et les droits. CNIL : informer les personnes et assurer la transparence.

Le cahier des charges peut nommer les propriétaires des comptes sans contenir leurs secrets. Préparez les invitations et un canal sécurisé pour les accès indispensables. Faites préciser la remise du code, des fichiers, de la configuration et de la documentation, ainsi que les droits et licences associés, dans les conditions contractuelles.

Ajoutez le périmètre de maintenance : mises à jour, sauvegardes, restauration, disponibilité et corrections selon le contrat. Notre checklist de maintenance et sécurité aide à poser ces questions. Un compte propriétaire ou un dépôt de code ne remplace pas une procédure de reprise documentée.

Comment comparer deux devis sur le même périmètre ?

Demandez une réponse qui indique inclusions, options, exclusions, coûts récurrents et conditions de validation. Vérifiez quelles tâches sont à votre charge : contenus, achat de licences, outils tiers, facturation des emails ou suivi technique. Si une fonction a un coût d’usage variable, faites expliquer ce qui le déclenche.

Comparez les livrables et critères de recette avant le total. Une proposition moins chère peut couvrir un périmètre plus restreint ; une proposition plus longue peut inclure des opérations dont vous n’avez pas besoin. Les dates dépendent aussi des validations et contenus que vous devez fournir.

Quelle checklist utiliser avant l’envoi ?

  • L’objectif et le public prioritaire sont décrits.
  • Chaque page a un sujet, un contenu attendu et une action.
  • Les fonctions de lancement et les évolutions sont distinguées.
  • Les textes, visuels et autorisations de publication ont un responsable.
  • Les outils à connecter et les données nécessaires sont identifiés.
  • La recette comprend des cas de réussite et d’échec.
  • Les critères mobile, clavier et accessibilité sont explicités.
  • Les responsabilités pour comptes, maintenance et reprise sont préparées.
  • Les livrables, coûts récurrents et validations sont demandés dans le devis.
  • Aucun mot de passe ni clé technique ne figure dans le document.

Questions fréquentes sur le cahier des charges

Faut-il choisir la technologie avant de demander un devis ?

Pas nécessairement. Décrivez d’abord le besoin et les outils existants. Signalez les contraintes imposées ; demandez ensuite une proposition justifiant le choix technique et les conditions de maintenance.

Que faire si je ne connais pas encore toutes les pages ?

Écrivez les offres à expliquer et les questions des visiteurs. Indiquez les points ouverts et demandez une phase de cadrage dans la proposition. Les pages pourront être validées avant le design et le développement.

Le cahier des charges remplace-t-il le contrat ?

Non. Il décrit votre besoin. Le devis et le contrat doivent confirmer le périmètre accepté, le prix, les responsabilités, les conditions de livraison et les droits applicables.

Comment présenter ce document à WebAiLab ?

Commencez par l’objectif, l’existant, les fonctions essentielles et les contraintes connues. Décrivez votre projet ; les documents complémentaires et les accès nécessaires pourront être transmis par un canal adapté, sans placer de secret dans le formulaire.

Découvrez les accompagnements WebAiLab en lien avec le sujet de cet article.

Partagez cet article

Aidez vos collègues à découvrir ce contenu

Articles similaires

Continuez votre lecture avec ces articles connexes