Comment briefer un développeur web pour éviter les malentendus

Il y a quelques années, un client m'a dit : « Je veux un site moderne et rapide. » J'ai livré un site propre, performant, responsive. Il n'en voulait pas. Pas parce qu'il était raté. Parce que ce n'était pas le bon site. Le problème n'était pas le développement. Le problème, c'était le brief.

La plupart des projets web qui dérapent ne dérapent pas à cause du code. Ils dérapent à cause de ce qui a été dit – ou pas dit – avant la première ligne de code.

Pourquoi les projets web échouent (et ce n'est pas un problème technique)

Le rapport CHAOS 2020 du Standish Group, basé sur l'analyse de plus de 50'000 projets informatiques, montre à quel point les projets dérapent facilement sur les délais, le budget ou le périmètre. Parmi les facteurs de succès identifiés depuis des décennies, trois reviennent systématiquement en tête : un sponsor impliqué, une équipe compétente, et des exigences clairement formulées. Autrement dit : dans beaucoup de projets, le vrai point de rupture n'est pas technique. Il apparaît plus tôt, quand les objectifs sont flous, que le périmètre bouge, ou que personne ne sait vraiment qui décide.

Le problème de fond est simple : vous savez ce que vous voulez. Votre développeur sait ce qu'il peut faire. Mais vous ne mettez pas forcément les mêmes choses derrière les mêmes mots. Et souvent, personne ne le voit avant qu'il soit trop tard.

Brief initial et cadrage : deux étapes différentes

Avant d'entrer dans le contenu d'un bon brief, clarifions un point que beaucoup de clients confondent.

Le brief initial, c'est le document que vous rédigez avant de contacter un développeur. C'est votre expression de besoin : ce que vous voulez accomplir, pour qui, dans quelles contraintes. Il n'a pas besoin d'être technique.

Le cadrage (ou scoping), c'est l'étape qui vient après le premier contact. C'est un travail commun : le développeur prend votre brief, pose des questions, identifie les zones floues, propose des approches. C'est là qu'on transforme votre vision en plan d'action réaliste.

Votre rôle, c'est de fournir un brief clair sur le quoi et le pourquoi. Le rôle du développeur, c'est de transformer ça en comment pendant le cadrage.

Ce qu'un bon brief contient

Un bon brief n'a pas besoin d'être un document de cinquante pages. Il doit répondre clairement à quelques questions essentielles.

Votre brief n'a pas besoin de contenir une arborescence complète, des wireframes ou des choix techniques. Si vous avez cela, tant mieux. Sinon, ce n'est pas bloquant.

Le pourquoi avant le quoi. Quel problème business ce site doit résoudre ? Comment saurez-vous que le projet est un succès ? « Plus de ventes » n'est pas un objectif. « Doubler les demandes de devis en douze mois » en est un.

Votre audience (pas vous). Qui sont vos visiteurs ? Quel âge ont-ils, dans quel contexte consultent-ils votre site – sur mobile dans le train, ou sur un écran 27 pouces au bureau ? Votre développeur ne connaît pas votre métier. Ces informations lui sont indispensables.

Le périmètre – ce qui est inclus ET ce qui ne l'est pas. Le scope creep – l'extension progressive et non maîtrisée du périmètre – est la cause numéro un des dépassements de budget. Dire « on verra plus tard pour le e-commerce » est une bombe à retardement. Dites plutôt : « Le e-commerce est explicitement hors périmètre pour cette version. »

L'identité visuelle et les contenus. Avez-vous une charte graphique ? Des exemples de sites qui vous inspirent et, surtout, ce que vous aimez dedans ? « J'aime bien le site d'Apple » ne dit rien d'utile. « J'aime la clarté de la navigation et l'espace entre les éléments » est exploitable. Et la question que tout le monde esquive : qui fournit les contenus, et quand ? Un site livré avec du lorem ipsum est un site à moitié fini.

Les contraintes techniques. Hébergement existant, nom de domaine, intégrations nécessaires avec d'autres outils (CRM, newsletter, paiement), exigences de conformité (nLPD, accessibilité). Les découvrir en cours de projet, c'est du retravail, du retard, et du budget en plus.

Le budget et le calendrier. Un budget réaliste, même approximatif, aide votre développeur à calibrer sa proposition. Sans indication budgétaire, il ne sait pas s'il doit vous proposer une Fiat ou une Mercedes. Les deux roulent, mais ce n'est pas le même projet.

Un interlocuteur unique. Qui décide ? Qui valide ? Si la réponse est « tout le comité de direction », vous avez un problème. Nommez une personne avec l'autorité de prendre des décisions. Un projet avec cinq validateurs est un projet qui n'avance pas. Sur les projets plus conséquents, définissez aussi qui fournit les contenus et qui gère les accès techniques – ces rôles ne sont pas toujours les mêmes.

L'angle contrat : ce qui doit être écrit noir sur blanc

En Suisse, la plupart des projets web entre un indépendant et une PME relèvent du contrat d'entreprise au sens des art. 363 ss CO. Quelques points à aborder dans le devis ou le contrat :

• Périmètre précis : la liste des livrables, ni plus ni moins. Tout ce qui n'est pas listé est hors périmètre.
• Processus de changement : toute demande en cours de route fait l'objet d'une estimation de coût et de délai supplémentaire. Pas de surprise.
• Recette et validation : une période définie pendant laquelle vous testez le site et signalez les défauts. Passé ce délai, le site est considéré comme accepté.
• Propriété intellectuelle : la question des droits sur le code, les contenus et les livrables doit être réglée explicitement dans le contrat. Si la cession de certains droits est importante pour vous, faites-la préciser noir sur blanc.
• Garantie et maintenance : qu'est-ce qui est couvert après le lancement, et pendant combien de temps ?

Collaborer pendant le projet

Le brief lance le projet. La suite compte tout autant. Un bon brief suivi de trois mois de silence radio, c'est la recette du malentendu.

Pour un projet classique de site vitrine PME, un point toutes les deux semaines suffit – en visio, trente minutes. L'idée n'est pas de micro-gérer, mais de traiter les blocages avant qu'ils ne s'accumulent. En pratique, il vous faut quatre choses : un rythme de points, un canal unique pour les échanges, une méthode claire pour faire des retours, et une personne qui valide côté client. « Je t'ai envoyé un e-mail lundi, un SMS mercredi, et un WhatsApp vendredi » – c'est le meilleur moyen de perdre une information.

Pour les retours, soyez précis et localisé. « Je n'aime pas trop la page d'accueil » n'aide personne. « Le bloc de témoignages est trop proche du pied de page, et j'aimerais que le bouton de contact soit dans une couleur plus contrastée » – ça, c'est actionnable.

Les trois anti-patterns qui font exploser le budget

En treize ans de métier, j'ai identifié trois schémas récurrents qui transforment un projet à 8'000 CHF en projet à 15'000 CHF (ou de 250K à près d'un million d'euros dans le cas le plus grave).

Le brief par comité. Le projet commence avec un interlocuteur. Puis le directeur veut voir les maquettes. Puis le responsable marketing a des remarques. Puis le conjoint du patron donne son avis sur les couleurs. J'ai vécu un projet où la page d'accueil a été redessinée quatre fois parce que chaque membre du comité de direction avait une vision différente. Le budget design a doublé. La parade : un seul décideur, avec un mandat clair. Les autres peuvent donner leur avis en amont, mais une seule personne tranche.

Le « tant qu'on y est ». Le site est presque fini, et le client se dit : « Tant qu'on y est, on pourrait ajouter un blog. Et une newsletter. Et peut-être un espace membres. » Chaque ajout semble petit vu de l'extérieur. J'ai eu un projet de site vitrine à 6'000 CHF qui a fini à 12'000 CHF par petits ajouts successifs, jamais formalisés. La parade : le périmètre est écrit dans le devis. Toute demande supplémentaire fait l'objet d'un avenant. Ce n'est pas de la rigidité – c'est de la transparence.

L'attente des contenus. Le développement est terminé. Le site est prêt sur l'environnement de test. Il ne manque que les textes et les images du client. Et on attend. Une semaine. Deux semaines. Un mois. Sur un de mes projets, le lancement a été repoussé de trois mois parce que les contenus n'arrivaient pas. La parade : définir dans le contrat qui fournit les contenus, avec un calendrier. Et prévoir dès le départ si un rédacteur externe doit s'en charger.

Ces trois schémas ont un point commun : le brief ne répond pas clairement à la question « qui décide quoi, et quand ? ». Si vous me dites « faites au mieux », je ne sais pas ce que ça veut dire. Un brief flou ne me donne pas plus de liberté. Il augmente surtout les chances que je parte dans la mauvaise direction. Et parlez-moi du budget. Je préfère largement un client qui me dit « j'ai 8'000 francs » qu'un client qui attend trois devis pour jouer les enchères.

Votre brief en dix questions : le template

Si tout cela vous semble beaucoup, voici l'essentiel condensé en dix questions. Répondez-y honnêtement, même brièvement, et votre développeur aura 80 % de ce dont il a besoin pour bien travailler.

Si vous ne savez pas tout répondre, commencez par trois éléments : votre objectif, votre public, et ce qui doit absolument être prêt au lancement.

Le brief minimum viable

• L'objectif principal du site
• Le public cible
• Les pages ou fonctionnalités indispensables
• Les contenus déjà disponibles
• Le budget indicatif
• La date cible
• La personne qui décide côté client

Template de brief – à copier et remplir

1. Quel est l'objectif principal de ce site ?
Décrivez le problème business que le site doit résoudre. Exemple : « Générer des demandes de devis pour notre activité de menuiserie. »

2. Qui sont vos visiteurs cibles ?
Âge, métier, contexte d'utilisation (mobile ou desktop ?). Exemple : « Propriétaires de maisons individuelles dans le canton de Fribourg, 35–60 ans, consultent surtout sur mobile. »

3. Quelles actions doivent-ils faire sur votre site ?
Quelles conversions attendez-vous ? Exemple : « Remplir le formulaire de contact, consulter nos réalisations, télécharger notre brochure. »

4. Avez-vous une identité visuelle existante ?
Logo, couleurs, typographies, charte graphique. Si oui, joignez les fichiers. Si non, indiquez-le – c'est une prestation à prévoir.

5. Quels sites vous inspirent (et pourquoi) ?
Listez 2 à 3 sites et précisez ce que vous aimez : la navigation ? Le style visuel ? La manière de présenter les services ? Soyez précis.

6. Quelles fonctionnalités sont indispensables ?
Listez ce qui est nécessaire dès le lancement. Exemple : « Formulaire de contact, galerie de réalisations, page de témoignages, plan d'accès. »

7. Quelles intégrations sont nécessaires ?
Outils existants à connecter : CRM, newsletter, système de réservation, ERP, outil de paiement. Listez tout, même si vous n'êtes pas sûr de la faisabilité.

8. Qui fournit les contenus (textes, images, vidéos) ?
Si c'est vous, prévoyez le temps nécessaire. Si vous avez besoin d'aide, dites-le – ça s'intègre au projet.

9. Quel est votre budget indicatif ?
Même une fourchette aide. Exemple : « Entre 5'000 et 10'000 CHF. » Cela permet au développeur de calibrer sa proposition.

10. Quelle est votre date de lancement souhaitée ?
Y a-t-il une contrainte forte (événement, saison) ou est-ce flexible ? Exemple : « Idéalement avant septembre, pour la rentrée. »

Un bon brief ne demande pas d'être technique. Il demande d'être clair sur ce que vous voulez accomplir, pour qui, et dans quelles contraintes. Quand les attentes sont bien posées, le développeur peut se concentrer sur ce qu'il fait de mieux : construire.

Vous préparez un projet web et vous ne savez pas par où commencer ? Parlons-en. Le cadrage fait partie du travail – et c'est souvent là que tout se joue.