Envoyez un brief flou à trois développeurs, et vous recevrez trois devis qui varient du simple au quintuple — non pas parce que quelqu’un se trompe, mais parce que chacun a imaginé un projet différent. Un bon brief règle ce problème. Il se rédige en une heure ou deux et épargne des semaines d’allers-retours.
Voici la structure que j’aimerais recevoir de chaque client. Copiez-la, remplissez-la, et envoyez le même document à tous vos interlocuteurs.
Pourquoi un brief compte plus qu’un budget
Un budget dit au développeur combien vous voulez dépenser. Un brief lui dit ce dont vous avez besoin. Sans le second, le premier n’est qu’un chiffre à viser. Avec les deux, vous obtenez un devis qui explique ce que vous obtenez pour votre argent, et vous pouvez comparer les devis ligne par ligne.
Ce qu’il faut mettre dans un brief de site web
1. Qui vous êtes, en trois phrases
Qui vous êtes, ce que vous vendez, et qui l’achète. Passez l’historique de l’entreprise. « Nous sommes un studio de design de deux personnes à Belgrade, et nous vendons du mobilier sur mesure aux restaurants » : c’est parfait.
2. L’objectif du site
Choisissez un objectif principal et deux objectifs secondaires au maximum :
- Générer des demandes de contact ou des réservations
- Vendre des produits en ligne
- Asseoir votre crédibilité (portfolio, études de cas)
- Recruter
- Expliquer un produit pour que les gens s’inscrivent
Puis associez-y un chiffre si possible : « 20 demandes qualifiées par mois » vaut mieux que « plus de prospects ».
3. Le public
Qui visite le site, ce que ces personnes veulent trouver, et ce qui les fait partir. Deux ou trois courtes descriptions suffisent : « Restaurateurs de 35 à 55 ans, sur leur téléphone entre deux services, qui veulent voir rapidement les prix et les délais. »
4. Pages et fonctionnalités
Listez les pages que vous prévoyez et, séparément, tout ce qui fait quelque chose :
- Formulaire de contact ou de réservation (où doivent arriver les envois ?)
- Paiement en ligne ou boutique (combien de produits ? de déclinaisons ?)
- Blog ou actualités (qui écrit, à quelle fréquence ?)
- Plusieurs langues (lesquelles, et qui traduit ?)
- Comptes ou espaces membres
- Intégrations : CRM, newsletter, agenda, statistiques
Les fonctionnalités pèsent bien plus sur le coût que les pages : soyez précis ici.
5. Le contenu : qui fournit quoi
Pour chaque page, indiquez si vous fournissez les textes, les images et les vidéos, ou s’il faut les créer. Le contenu manquant est la première cause de retard des mises en ligne.
6. La direction artistique
Partagez trois à cinq sites que vous aimez et, pour chacun, ce que vous aimez — la typographie, la mise en page aérée, la façon de montrer les photos produits. Ajoutez un site que vous n’aimez pas, et pourquoi. Si vous avez un logo et une charte graphique, joignez-les ; sinon, dites-le, car le travail d’identité est une prestation à part (voir l’identité de marque dont une startup a besoin au lancement).
7. Les contraintes techniques
- Avez-vous un nom de domaine ? Un hébergement ?
- Qui modifiera le site après le lancement, et avec quel niveau technique ?
- Y a-t-il quelque chose à conserver : une boutique existante, un système de réservation, une messagerie ?
- SEO : remplacez-vous un site déjà bien référencé ? (Alors les redirections comptent.)
8. Budget et calendrier
Donnez une fourchette, pas un montant unique, et précisez si la date est fixe (un événement de lancement, un salon) ou flexible. Une fourchette permet au développeur de proposer ce qui y tient, au lieu de deviner.
9. Comment vous décidez
Qui valide les maquettes, et en combien de temps ? Un seul décideur qui répond dans la journée vaut plus que n’importe quel outil de gestion de projet.
Ce qu’il faut laisser de côté
- Des choix techniques sans raison. Écrivez plutôt « l’équipe doit pouvoir modifier les pages sans développeur » que de nommer un CMS, sauf si vous en utilisez déjà un.
- Une arborescence complète de 40 pages. Commencez par les pages qui servent l’objectif principal ; les autres viendront ensuite.
- Toutes les idées que vous avez jamais eues. Rangez les envies dans une liste à part, pour qu’elles soient chiffrées séparément.
Le modèle
Copiez ceci dans un document et remplissez-le :
# Brief site web — [Nom de l’entreprise]
## Qui nous sommes
[Trois phrases : qui vous êtes, ce que vous vendez, qui l’achète]
## Objectif
Principal : [un objectif + un chiffre si possible]
Secondaires : [deux au maximum]
## Public
- [Type de visiteur 1 : qui, ce qu’il cherche, ce qui le fait partir]
- [Type de visiteur 2]
## Pages
- [Page] : [rôle]
## Fonctionnalités
- [Fonctionnalité] : [détails, ex. « formulaire de contact → e-mail à commercial@ »]
## Contenu
| Page | Textes | Images | Vidéo |
| ---- | ------ | ------ | ----- |
| Accueil | fournis par nous | photos à prévoir | — |
## Direction artistique
- On aime : [URL] — [quoi exactement]
- On n’aime pas : [URL] — [pourquoi]
- Éléments de marque : [joints / pas encore]
## Technique
Domaine : [oui/non] · Hébergement : [oui/non] · Modifications après lancement : [qui]
À conserver : [systèmes existants]
Remplace un site bien référencé : [oui/non]
## Budget et calendrier
Fourchette de budget : [de–à] · Lancement : [date, fixe ou flexible]
## Décisions
Décideur : [nom] · Délai de réponse habituel : [ex. 1 jour]
## Envies (à chiffrer séparément)
- [...]Et ensuite ?
Avec un brief de ce type, un bon développeur peut répondre par une proposition cadrée plutôt que par une liste de questions : ce qui est inclus, ce qui ne l’est pas, un calendrier et un prix pour chaque partie. Si deux devis restent très éloignés, demandez à chacun d’expliquer sa ligne la plus élevée : vous en apprendrez plus dans cette conversation qu’en comparant les totaux.
Vous construisez une application plutôt qu’un site ? Les mêmes principes s’appliquent, avec davantage d’attention aux parcours utilisateur — voir combien coûte vraiment un MVP.
Votre brief est prêt ? Envoyez-le-moi.
