Décrire le contexte et les visiteurs
Présentez l’activité, les publics et les raisons qui les amèneront sur le site. Précisez les questions auxquelles ils doivent trouver réponse. Ces éléments permettent de discuter les pages et fonctionnalités sur la base de leur utilité.
Lister les besoins avec leur priorité
Séparez les fonctions indispensables des possibilités futures. Pour chacune, décrivez un usage concret : demander un rappel, consulter une réalisation ou trouver des coordonnées. Évitez de choisir une fonctionnalité uniquement parce qu’un autre site la possède.
Préciser les conditions du projet
Indiquez les contenus disponibles, les personnes qui valident, les échéances envisagées et les modalités de gestion attendues. Notez aussi les sujets encore ouverts. Le document doit faciliter une discussion, pas masquer les incertitudes.
Le tableau qui rend les devis comparables
Préparez une ligne par élément : objectif du site, publics, pages, rédaction, images, formulaire, gestion des contenus, accès, hébergement et entretien. Ajoutez trois colonnes : fourni par vous, réalisé par le prestataire, critère de réception. Pour un formulaire, le critère peut être une demande de test reçue par la bonne personne avec un retour compréhensible pour le visiteur. Évitez « site moderne » comme seul critère : deux interlocuteurs peuvent lui donner des sens très différents.
Écrire les exclusions et les dépendances
Exemple hypothétique : le projet présente quatre services et permet de demander un rappel. Il ne comprend ni paiement, ni compte client, ni réservation de créneau. La disponibilité des photographies conditionne la validation des pages. Ces exclusions ne réduisent pas l'ambition : elles précisent ce qui sera livré. Faites également écrire qui achète et renouvelle le domaine, qui détient les accès et comment récupérer les contenus si la collaboration change.
Recevoir une version qui se teste
Lors de la relecture, suivez un parcours complet sur téléphone : comprendre une prestation, retrouver une information, joindre l'entreprise. Le cours Learn Forms de web.dev est la référence technique pour les formulaires ; il ne certifie pas la qualité commerciale du site. Archivez la version du brief qui sert de référence, puis notez chaque modification de périmètre et sa conséquence sur le devis. Le résultat utile est une base commune de décision, pas un inventaire interminable de fonctions.
Votre grille de travail
Une trame proposée par koldia, à adapter à votre situation.
| Élément | À préciser dans le brief | Contrôle |
|---|---|---|
| Page de prestation | Public, question traitée, contenu fourni | Un lecteur peut expliquer l’offre |
| Formulaire | Champs, destinataire, confirmation, erreur | La demande fictive est reçue |
| Transmission | Domaine, accès, contenus et entretien | Le responsable retrouve les accès utiles |
Avant de passer à la suite
Cochez les points vérifiés pendant votre lecture.
Questions pratiques
Faut-il un document très long ?
Non. Une version courte et précise peut suffire pour un site simple. Ajoutez du détail lorsque la complexité du projet le justifie.
Références officielles
Liens consultés le 20 octobre 2026.
- Google web.dev — conception et tests des formulaires
Repères techniques pour la saisie, les libellés, la validation et les essais.
- France Num — cahier des charges d’un site
Portail public français : une ressource méthodologique pour cadrer le projet web.
Vous souhaitez avancer sur ce sujet ?
Un premier échange offert de 15 minutes par téléphone, sans engagement.
Parlons de votre projet