Modèle de cahier des charges pour la création d’un site internet

Un cahier des charges pour un site internet transforme une intention en commande vérifiable : quelles pages créer, quels contenus préparer, quels parcours permettre et quels éléments remettre à la livraison. Pour un site vitrine ou éditorial, la précision vient surtout des relations entre arborescence, gabarits, publication et validation. Une liste de fonctionnalités ne suffit pas si personne ne sait qui fournit les textes ou décide de conserver une ancienne adresse.

Ce modèle original proposé par la rédaction d’Anaska, se complète par rubriques. Les champs entre crochets sont à renseigner ou à supprimer lorsqu’ils ne concernent pas votre projet. Les formulations présentées comme exemples sont pédagogiques. Les contrôles proposés constituent des recommandations de la rédaction : adaptez leur périmètre avec les intervenants avant de les retenir comme critères de livraison.

1. Définir la finalité et les limites du site

Commencez par la situation du visiteur. Que cherche-t-il à comprendre, comparer ou demander ? Retenez une action principale par parcours, puis décrivez les informations nécessaires pour y parvenir. Cette formulation aide à arbitrer une page supplémentaire : répond-elle à une question identifiée ou reproduit-elle un contenu déjà prévu ? Un objectif de visibilité peut orienter le projet, mais ne décrit pas un livrable.

Champs à compléter : activité [description] ; publics [profils concernés] ; besoin principal [question du visiteur] ; action attendue [prise de contact, lecture, téléchargement] ; création ou refonte [choix] ; responsable du projet [fonction] ; personne habilitée à arbitrer [fonction]. Ajoutez les contraintes connues et leur motif, notamment lorsqu’une publication dépend d’un événement ou d’un contenu encore indisponible.

Exemple pédagogique : le site doit permettre à une personne de comprendre les prestations proposées, de vérifier leur adéquation avec son besoin et de transmettre une demande. Le paiement et l’espace personnel sont exclus. Cette phrase délimite une commande sans présumer la solution technique.

Livrable et validation recommandés : une fiche de cadrage distinguant inclusions, options et exclusions. Faites confirmer les frontières du projet par les personnes qui valideront ensuite le site. Évitez les expressions telles que « toutes les fonctionnalités habituelles » : elles masquent des attentes différentes et rendent les propositions difficiles à examiner.

2. Dessiner l’arborescence et les chemins de navigation

Construisez une liste de destinations avant de dessiner le menu. Pour chaque page, notez son sujet, sa page parente, ses points d’entrée et la prochaine action possible. Une page peut être accessible depuis un article sans figurer dans la navigation principale. À l’inverse, un intitulé de menu peut regrouper plusieurs pages sans constituer lui-même une destination.

Champs à compléter : intitulé [texte] ; adresse envisagée [chemin] ; parent [rubrique] ; question traitée [besoin] ; accès prévu [menu, lien contextuel, pied de page] ; responsable de validation [fonction]. Précisez le traitement des rubriques vides et des pages retirées. Pour un site éditorial, indiquez aussi si les catégories possèdent une présentation rédigée ou servent uniquement à regrouper des publications.

Validation recommandée : simulez un parcours depuis une page intérieure, sans passer par l’accueil. Le visiteur doit pouvoir situer le contenu et poursuivre sa recherche. Évitez de reproduire automatiquement l’organigramme interne : les noms de services ne décrivent pas toujours les questions du public.

3. Spécifier les gabarits et leurs variantes

Distinguez le nombre de pages du nombre de gabarits. Un gabarit définit une structure réutilisable ; chaque page intégrée reçoit ses propres informations. Demandez séparément quels modèles seront conçus, quelles variantes sont prévues et quels contenus seront effectivement saisis. Cette distinction évite de découvrir à la livraison qu’une partie des pages reste à remplir.

Fiche de gabarit à compléter : nom [type de page] ; blocs indispensables [liste] ; blocs facultatifs [liste] ; ordre modifiable [oui ou non, avec limites] ; contenus associés [règle de sélection] ; état vide [comportement] ; variante particulière [description]. Décrivez aussi les éléments communs : en-tête, pied de page, fil de navigation éventuel et appels à l’action.

Exemple pédagogique : une fiche de prestation comporte une introduction, le détail du service, ses limites et un accès au contact. Un article comporte une introduction, un corps structuré et des lectures associées. Ces structures répondent à des usages différents, même si elles partagent certains composants visuels.

Livrable et validation recommandés : un inventaire des gabarits accompagné de pages représentatives. Examinez un titre long, une page sans photographie et un contenu comportant des sous-titres. Évitez de valider uniquement une maquette idéale avec un texte très court. Un gabarit est accepté lorsque ses variantes prévues restent lisibles et que ses limites de composition sont expliquées.

4. Répartir la production des textes et des médias

Pour chaque contenu, attribuez la collecte des informations, la rédaction, la relecture, la validation et l’intégration. Une responsabilité collective sans interlocuteur désigné laisse les décisions en suspens. Précisez également qui vérifie les coordonnées, descriptions de prestations et documents téléchargeables avant publication. La validation du fond et celle de la mise en page constituent deux étapes distinctes.

Champs à compléter : contenu [page ou document] ; état [existant, à réviser, à produire] ; informations attendues [liste] ; rédacteur [fonction] ; validateur [fonction] ; intégrateur [fonction] ; emplacement de remise [support choisi] ; dépendance [élément manquant]. Pour les médias, ajoutez la provenance, les conditions d’utilisation à vérifier par votre équipe, la légende et le rôle de l’image.

Conseil de la rédaction : joignez une courte fiche éditoriale précisant le vocabulaire, le ton et les formulations à éviter. Exemple pédagogique de consigne : expliquer le service avec des termes compréhensibles avant d’introduire son nom technique. Demandez des intitulés de liens qui annoncent leur destination plutôt que des invitations vagues à cliquer.

Livrable et validation recommandés : un registre des contenus avec un statut explicite. Un contenu accepté doit être identifiable sans rechercher la bonne version dans plusieurs échanges. Évitez de traiter un texte provisoire comme validé par défaut. Si une information manque, choisissez entre reporter la page, réduire son périmètre ou obtenir un arbitrage ; ne laissez pas l’intégrateur inventer la réponse.

5. Préparer la migration des pages et des documents

En refonte, construisez un inventaire de l’existant distinct de la future arborescence. Incluez les pages, documents et médias encore utiles. Attribuez à chaque élément une décision : conserver, réécrire, fusionner, archiver hors du site ou retirer. Une page absente du futur menu peut encore nécessiter un examen avant suppression.

Champs à compléter : adresse actuelle [chemin] ; sujet [description] ; décision [choix] ; destination future [chemin ou retrait motivé] ; contenu à reprendre [éléments] ; responsable [fonction] ; contrôle attendu [vérification]. En cas de fusion, indiquez quelle information chaque ancienne page apporte à la nouvelle. Une destination vaguement proche ne suffit pas à justifier un regroupement.

Exemple pédagogique : deux anciennes présentations d’une même prestation deviennent une fiche commune. Le dossier de migration précise les informations conservées, les répétitions supprimées et les anciennes adresses à traiter. La rédaction recommande de faire confirmer le comportement des redirections par l’intervenant technique et de contrôler les destinations retenues.

Livrable et validation recommandés : une table de correspondance accompagnée d’un relevé des éléments non repris. Vérifiez aussi les liens vers les documents depuis les pages migrées. Définissez qui reporte les modifications intervenues entre l’inventaire initial et la publication. Évitez de promettre un maintien des positions dans les moteurs : la validation porte ici sur la reprise convenue et les comportements observables.

6. Décrire les formulaires et la réception des demandes

Définissez chaque formulaire par son usage : quelles demandes accepte-t-il et qui les traite ? Sélectionnez ensuite les informations nécessaires à cette prise en charge. Pour chaque champ, indiquez son libellé, son caractère requis ou facultatif et l’aide utile. Les pièces jointes restent une décision particulière à justifier, avec formats acceptés, limites et traitement à préciser.

Champs à compléter : objectif [usage] ; champs [liste] ; destinataire [fonction ou boîte dédiée] ; confirmation affichée [texte à rédiger] ; message en cas d’échec [texte à rédiger] ; solution alternative de contact [choix] ; services externes éventuels [inventaire]. Faites préciser les données enregistrées, leur emplacement et les personnes disposant des accès, puis soumettez les décisions nécessitant une expertise spécifique aux responsables concernés.

Exemple pédagogique : après un envoi réussi, afficher une confirmation de transmission. Si la transmission échoue, expliquer la situation et proposer l’alternative convenue. Ne présentez pas une confirmation d’envoi comme une acceptation de la demande ou un engagement de réponse.

Validation recommandée : réaliser des essais autorisés avec des données fictives, vérifier la réception effective, les erreurs de saisie et le comportement après un échec. Demandez comment les protections contre les envois indésirables affectent l’usage du formulaire. Évitez de conclure à son bon fonctionnement sur la seule apparition d’un message à l’écran. Le livrable attendu comprend le parcours complet et les consignes de réception.

7. Définir le responsive et l’accessibilité attendue

Selon MDN, le responsive design consiste à adapter la présentation aux tailles et résolutions d’écran en préservant l’usage. Traduisez cette approche en situations concrètes : ouvrir le menu sur écran étroit, lire un article long, consulter un tableau et remplir le formulaire. Une image réduite ne suffit pas à démontrer que le parcours reste utilisable.

Champs à compléter : environnements de contrôle [navigateurs et appareils convenus] ; contenus représentatifs [pages] ; comportements du menu [description] ; traitement des tableaux [choix] ; recadrage des médias [règle] ; animations [utilité et comportement attendu]. Préférez des critères liés au contenu plutôt qu’une demande de reproduction identique sur tous les écrans.

Les WCAG 2.2, recommandation du W3C du 12 décembre 2024, proposent des critères vérifiables et des niveaux A, AA et AAA. Elles ne couvrent pas tous les besoins. La rédaction recommande de préciser la cible retenue, les pages évaluées et la méthode de contrôle, sans déduire de ce choix les obligations juridiques de l’organisme.

Livrable et validation recommandés : un relevé des vérifications et des limites constatées. Incluez des essais au clavier, un examen des intitulés et des alternatives textuelles, ainsi qu’une lecture avec agrandissement. Évitez de réduire l’évaluation à un contrôle automatique ou à une appréciation esthétique.

8. Formaliser le SEO technique et la performance

Décrivez les possibilités attendues plutôt qu’un résultat de classement. La rédaction recommande de préciser la modification des titres de pages, descriptions, adresses et liens internes, ainsi que le traitement des pages retirées. Demandez une proposition pour les adresses de référence, le plan de site destiné aux moteurs et les règles d’indexation, adaptée aux contenus réellement publiés.

Champs à compléter : éléments modifiables [liste] ; responsable des réglages [fonction] ; pages destinées à être publiques [périmètre] ; environnement de préparation [conditions d’accès] ; contrôles avant ouverture [liste]. Faites expliciter la manière dont les restrictions de préparation seront revues lors de la publication. Évitez une exigence générale de « SEO inclus » sans tâches ni livrables identifiés.

La documentation Web Vitals, mise à jour le 31 octobre 2024, distingue les mesures de laboratoire et celles recueillies en conditions réelles. Les indicateurs présentés concernent le chargement, l’interactivité et la stabilité visuelle. Un contrôle simulé ne remplace donc pas l’observation des visites réelles.

Validation recommandée : convenir des pages mesurées, du contenu utilisé, des conditions d’essai et des critères retenus. Demandez un compte rendu permettant de reproduire les contrôles et d’identifier les éléments externes concernés. Prévoyez le traitement d’un résultat insuffisant et l’absence éventuelle de données réelles. Le livrable est un protocole documenté, pas une promesse de rapidité identique pour chaque visite.

9. Organiser l’administration et l’exploitation technique

Listez les opérations que votre équipe devra effectuer sans intervention extérieure : corriger un texte, remplacer une photographie, publier un article ou modifier une information pratique. Pour chacune, précisez qui agit et quelles erreurs l’interface devrait aider à éviter. Demandez la démonstration de ces tâches dans la solution proposée plutôt que de présumer les capacités de tous les outils de publication.

Champs à compléter : profils d’accès [fonctions] ; actions autorisées [liste] ; validation avant publication [circuit] ; prévisualisation [attente] ; sauvegardes [périmètre et responsabilité] ; restauration [procédure à décrire] ; mises à jour [intervenant] ; services externes [dépendances]. Distinguez les accès éditoriaux des accès techniques et nommez le responsable de leur gestion.

Conseil de la rédaction : demandez un inventaire des composants et services nécessaires au fonctionnement du site, avec leur rôle et les modalités de suivi proposées. Une intégration externe mérite un comportement prévu lorsqu’elle devient indisponible. Si une vidéo, une carte ou un service de mesure est envisagé, faites examiner son utilité et ses conséquences avant de l’ajouter.

Livrable et validation recommandés : une fiche d’exploitation et une démonstration sur des contenus représentatifs. Vérifiez qu’une personne désignée peut accomplir les tâches convenues avec le guide remis. Évitez de considérer la sauvegarde comme validée par sa seule mention : demandez comment une restauration pourra être contrôlée dans un environnement approprié, sans perturber le site public.

10. Construire une recette fondée sur des preuves

Préparez les critères de recette pendant la rédaction du cahier des charges. Chaque exigence retenue doit correspondre à un résultat observable et à une personne responsable de sa validation. Distinguez une anomalie par rapport à la commande d’une nouvelle demande. Cette séparation permet de traiter les écarts sans modifier silencieusement le périmètre.

Champs complémentaires : référence de l’exigence [identifiant] ; environnement [description] ; résultat observé [constat] ; anomalie [description] ; décision [correction ou arbitrage] ; nouveau contrôle [résultat]. Définissez les écarts qui empêchent la publication et la manière de consigner les réserves acceptées.

Validation recommandée : conserver un état partagé des contrôles et des corrections. Évitez les retours limités à « cela ne fonctionne pas » : indiquez la page, l’action effectuée et le résultat obtenu. Le livrable final de recette relie chaque décision à une vérification identifiable, y compris lorsqu’une limite reste acceptée.

11. Préparer la publication et la passation

Rédigez une fiche de publication qui répartit les interventions sur le domaine, l’hébergement, les contenus et les services associés. Indiquez qui donne l’accord de publication et quelles validations doivent être disponibles. Décrivez la reprise des dernières modifications éditoriales et la procédure envisagée si une difficulté impose de revenir à une situation précédente.

Champs à compléter : responsable de publication [fonction] ; intervenants techniques [fonctions] ; prérequis [liste] ; contenus approuvés [référence] ; contrôles après ouverture [parcours] ; procédure de retour [description] ; destinataire des incidents [fonction]. La rédaction recommande de vérifier après ouverture les principales destinations migrées et la réception des demandes, dans les conditions convenues.

Définissez ensuite la remise : accès attribués aux bonnes personnes, fichiers prévus, inventaire technique, documentation éditoriale et procédure de sauvegarde. Précisez ce que comprend l’accompagnement et comment seront demandées les interventions ultérieures. Évitez une passation réduite à l’envoi d’un mot de passe sans explication des responsabilités.

Validation recommandée : faire réaliser une opération courante par le futur administrateur et confirmer la disponibilité des éléments remis. Pour consulter des prestataires, demandez une réponse suivant vos rubriques : périmètre, livrables, exclusions, contributions attendues et modalités de validation. Les questions ouvertes doivent porter un responsable d’arbitrage. La méthodologie d’Anaska peut compléter votre lecture du comparateur ; le document préparé peut accompagner votre démarche pour déposer un projet.