Votre restaurant n’a pas besoin d’un dossier technique de cinquante pages pour démarrer. Il a besoin d’un document commun qui évite les malentendus. « Nous voulons un beau site » laisse ouvertes presque toutes les décisions. « Un client doit trouver notre formule du midi et réserver depuis son téléphone » donne un point de départ beaucoup plus utile au designer comme au développeur.
Commencer par la salle, la cuisine et les clients
Décrivez le concept avec des éléments observables : cuisine, ambiance, services, capacité et moments importants. Une brasserie avec un déjeuner rapide et une pizzeria tournée vers l’emporté n’ont pas les mêmes priorités. Notez ce que les clients demandent déjà au téléphone. Les questions qui reviennent fournissent souvent le meilleur plan de contenu.
Ajoutez les contraintes de l’équipe : qui peut répondre aux demandes de groupe, quand la carte change et qui contrôle les disponibilités ? Un site peut simplifier un processus défini. Il ne peut pas décider seul de règles qui restent floues au sein de l’établissement.
Décrire les parcours avec des critères observables
Pour chaque besoin, formulez un résultat que vous pourrez tester. Évitez les termes vagues comme « intuitif » sans exemple. Un parcours doit prévoir sa fin : confirmation, rappel, refus ou attente de validation. Le visiteur doit savoir si sa table est réservée ou si sa demande doit encore être acceptée.
| Besoin | Critère de validation |
|---|---|
| Consulter la carte | Prix et catégories lisibles sur téléphone sans ouvrir une photo géante. |
| Réserver | Date, nombre de personnes et confirmation compréhensibles. |
| Demander une privatisation | Informations utiles transmises à la bonne personne. |
| Actualiser le site | Une personne désignée sait changer un horaire sans assistance. |
Inventorier ce qui existe et ce qui manque
Rassemblez le logo dans un format exploitable, les couleurs, la carte à jour, les photos autorisées et les coordonnées. Pour les outils, indiquez les noms des fournisseurs et les interlocuteurs ; ne mettez pas les mots de passe dans le brief. Préparez un transfert d’accès séparé lorsque le prestataire est choisi.
Marquez chaque contenu comme prêt, à corriger ou à produire. Désignez une personne qui arbitre les retours. Plusieurs validations contradictoires peuvent bloquer un projet simple. Fixez un calendrier de retour réaliste autour des services et des jours de fermeture.
Préparer la livraison et les évolutions
Ajoutez une liste des opérations que votre équipe doit maîtriser après livraison. Demandez une courte documentation et une séance de prise en main. Le site doit garder des titres et des repères de navigation cohérents ; le guide de structure du W3C explique leur rôle pour les utilisateurs.
- Propriétaire du domaine, hébergement et accès administrateur identifiés.
- Contenus et photos validés par l’établissement.
- Tests de réservation et de contact réalisés.
- Responsable des mises à jour nommé.
- Fonctions futures séparées du périmètre de lancement.
Questions pratiques
Dois-je choisir un CMS dans le brief ?
Décrivez surtout qui mettra le site à jour et à quelle fréquence. Le choix de l’outil doit répondre à ces besoins.
Peut-on commencer sans toutes les photos ?
Oui pour la conception, si les emplacements et le calendrier sont prévus. La publication doit utiliser des images dont vous disposez des droits.
Sources et repères
Ces documents précisent les règles et repères techniques cités. Les méthodes et exemples proposés dans ce guide sont ceux de Norpat.
- W3C WAI — Structurer une page web ↗
Des titres hiérarchisés et des éléments HTML adaptés aident à parcourir une page et à comprendre son organisation.