Investir et choisir
Comment rédiger un cahier des charges pour la création de son site internet ?
Un bon cahier des charges décrit ce que le site doit permettre de faire, les contraintes à respecter et la manière de vérifier le résultat. Il ne consiste pas à décider chaque écran avant de rencontrer un prestataire. Son rôle est de rendre les besoins comparables, discutables et réalisables.
L'essentiel.
- Partez des décisions de vos visiteurs, pas d’une liste de fonctionnalités copiée sur un autre site.
- Séparez les exigences du lancement, les options et les points qui restent à étudier.
- Précisez qui fournit les contenus, qui valide et quels tests permettront d’accepter la livraison.
Commencez par une phrase qui oblige à choisir
« Nous voulons un site moderne » exprime une envie, pas un résultat vérifiable. Écrivez plutôt : « Notre site doit permettre à un responsable d’hôtel de comprendre notre offre de luminaires sur mesure et de transmettre les éléments nécessaires à une première étude. »
Cette phrase désigne un public, une décision et une action. Elle ne garantit pas des commandes. Elle aide à choisir les pages, les preuves et le formulaire. Une fonctionnalité qui ne sert aucune de ces étapes devra justifier sa présence.
Décrivez aussi la situation actuelle. Existe-t-il un site, des contenus réutilisables, une identité, un outil de réservation ou une base de produits ? Ce qui fonctionne mérite d’être conservé. Le cahier des charges n’est pas une autorisation implicite de tout reconstruire.
Une trame courte, mais complète
Voici une structure de travail proposée par LVX. Le nombre de pages du document importe moins que la précision des réponses.
| Rubrique | Ce qu’il faut écrire | Comment le vérifier |
|---|---|---|
| Objectif et publics | Qui doit pouvoir décider quoi ? | Un scénario prioritaire explicite |
| Offre et preuves | Services, réalisations, références autorisées | Une liste de contenus disponibles |
| Périmètre | Pages, langues, fonctions incluses et exclues | Une arborescence et des parcours |
| Fonctionnement | Outils connectés, accès, mises à jour | Des responsabilités identifiées |
| Livraison | Tests, transmission, documentation | Une liste de critères d’acceptation |
Ajoutez les contraintes de budget et de calendrier que vous connaissez réellement. Une date de salon peut être impérative ; une date choisie par préférence ne l’est pas de la même façon. Cette distinction permet au prestataire de proposer un lancement cohérent plutôt que de promettre un périmètre irréaliste.
Décrivez les usages avant de prescrire les outils
« Il faut un espace client » reste une hypothèse. « Le client doit retrouver ses plans validés sans redemander le fichier » décrit un besoin. Un outil déjà utilisé peut y répondre ; un développement spécifique n’est pas automatiquement nécessaire.
Pour chaque fonction envisagée, notez l’utilisateur, son point de départ, l’action attendue et la confirmation obtenue. Ajoutez les cas moins agréables : fichier trop lourd, créneau indisponible, paiement refusé, message non envoyé. Un parcours ne se résume pas à son état idéal.
Le choix entre site vitrine, boutique et application web intervient à ce niveau. Il doit suivre la nature du service rendu, pas un goût préalable pour une plateforme.
Exemple : transformer une demande floue
Prenons un atelier fictif qui écrit : « Nous voulons montrer nos projets et recevoir des demandes. » Une version exploitable précise que les visiteurs doivent pouvoir distinguer les collections disponibles des réalisations sur mesure, consulter des dimensions et déposer un brief sans créer de compte.
L’atelier fournit les photographies autorisées et les caractéristiques techniques. Le studio organise les contenus et conçoit le parcours. Une personne nommée valide les textes. Le formulaire reçoit un fichier dans un format défini, affiche un accusé de réception et transmet la demande à son destinataire.
Le projet peut alors être testé : un visiteur trouve-t-il une référence adaptée ? Comprend-il ce qui peut être personnalisé ? L’équipe reçoit-elle assez d’informations pour répondre ? Aucun de ces critères n’exige d’inventer un taux de conversion cible.
Rendez les responsabilités visibles
Un calendrier peut se bloquer sur une décision, pas seulement sur une tâche technique. Listez le décideur final, les personnes consultées et les contributions attendues : rédaction, traduction, photographie, validation réglementaire, reprise des données.
Prévoyez une règle pour les demandes nouvelles. Un changement n’est ni automatiquement gratuit ni automatiquement hors sujet. Il doit être décrit, évalué puis accepté avec son effet sur le périmètre. Notre article sur la maîtrise du budget d’une refonte approfondit ce point.
L’accessibilité doit également entrer dans le cadrage. Le W3C recommande de planifier les responsabilités et les vérifications tout au long du projet, plutôt que d’en faire seulement un contrôle final. W3C WAI — Planning and Managing Web Accessibility
Écrivez ce que signifie « terminé »
Remplacez « site performant et administrable » par des critères observables : pages attendues présentes, formulaires testés, accès transmis, procédures de mise à jour expliquées, sauvegarde et restauration prévues selon le dispositif retenu. Les exigences techniques chiffrées doivent préciser leurs conditions de mesure.
Faites relire le document à quelqu’un qui ne connaît pas le projet. S’il ne sait pas ce qui sera livré, ce qui ne le sera pas et ce qu’on attend de lui, le cadrage reste incomplet. Les inconnues peuvent demeurer, à condition d’être nommées et assorties d’une décision à prendre.
LVX peut vous aider à passer d’une intention générale à ce périmètre de conception. Le bon livrable n’est pas un dossier intimidant : c’est un accord de travail suffisamment clair pour protéger la qualité, le budget et votre disponibilité.
Cadrez avec LVX un site dont les objectifs, les responsabilités et la qualité attendue sont explicites dès le départ.
