Le brief. Ce document qu'on rédige en 20 minutes entre deux calls, qu'on envoie en PDF au client, et qu'on retrouve six semaines plus tard quand le projet déraille. Ca m'agace profondément : la majorité des litiges en agence naissent d'un brief ambigu, pas d'une mauvaise exécution. L'équipe a livré ce qu'elle avait compris. Le client attendait autre chose. Personne n'a tort. Et pourtant tout le monde y perd.
J'ai eu une directrice commerciale d'une agence de 12 personnes qui m'expliquait avoir perdu 34 000 euros de marge sur un projet e-commerce parce que le brief initial ne précisait pas si le module de filtrage produits était inclus ou non. Trente-quatre mille euros. Pour une ligne floue dans un document de quatre pages.
Pourquoi la plupart des briefs ne fonctionnent pas
Le problème n'est pas la forme, c'est la philosophie. La plupart des templates de brief circulent comme des formulaires administratifs : quelques cases à remplir, un champ 'objectifs', un champ 'budget', et basta. Résultat : le client écrit ce qu'il croit vouloir, le chef de projet lit ce qu'il a envie de comprendre, et les deux parties signent un accord sur deux réalités parallèles.
Un brief efficace, c'est avant tout une conversation transcrite. Pas une liste de souhaits. La différence est fondamentale : le client qui demande 'un site moderne' n'a aucune idée de ce que ça implique techniquement. Votre job, c'est de transformer cette intention floue en spécification actionnable. Et ca ne se fait pas par email.
Les 6 composantes d'un brief béton
Après avoir accompagné des dizaines d'agences digitales, j'ai identifié six éléments qui, quand ils sont absents, garantissent presque à coup sûr un projet chaotique. Pas besoin d'un document de 40 pages. Ces six points suffisent, à condition d'être traités en profondeur.
- Le problème réel du client (pas sa solution proposée) : 'on veut refaire notre site' cache souvent 'on perd des leads à cause du formulaire de contact cassé'
- Les critères de succès mesurables : +20% de taux de conversion sur mobile d'ici 90 jours, pas 'améliorer l'expérience utilisateur'
- Le hors-périmètre explicite : tout ce que le projet NE couvre PAS, noir sur blanc
- Les contraintes techniques et organisationnelles : stack existant, accès serveur, interlocuteurs côté client, délais réels vs délais annoncés
- Le processus de validation : qui valide quoi, en combien de jours, combien de rounds de retours inclus
- Les définitions partagées : qu'est-ce qu'une 'page', qu'est-ce qu'une 'révision', qu'est-ce qu'un 'bug' dans ce contexte
On avait un brief de 8 pages avec des moodboards, des personas, des benchmarks. Magnifique. Et personne n'avait précisé que le client voulait gérer le contenu lui-même. On a livré un site sur mesure sans CMS. Le client a refusé la livraison. Ce brief ne valait rien. -- Romain, directeur technique, agence 20 personnes, Lyon
La session de brief : comment la conduire
Oubliez le formulaire en ligne envoyé par email. Un bon brief se construit en call ou en présentiel, 60 à 90 minutes, avec les vrais décideurs côté client. Pas le chef de projet qui relaie. Le CMO, le DG, la personne qui a le problème et qui signera la facture.
La technique qui m'a le plus aidé : la question des cinq pourquoi, appliquée au contexte agence. Pourquoi ce projet maintenant ? Parce qu'on lance une offre en septembre. Pourquoi septembre ? Parce qu'on a un salon. Pourquoi ce salon est critique ? Parce que c'est là qu'on signe 60% de nos contrats annuels. Voilà : le vrai driver du projet, c'est le salon, pas le site. Ca change tout l'angle de priorisation.
Pendant le call, prenez des notes brutes. Après, reformulez et renvoyez un compte-rendu de brief au client avec la formulation suivante : 'Voici ce qu'on a compris. Si vous validez ce document, on considère que c'est la base contractuelle du projet.' Ca oblige le client à lire, à corriger, à s'engager. Avec Clynt, ce document peut être joint directement à la phase projet et signé électroniquement avant le démarrage.
Brief et gestion Agile : comment les articuler
Il y a une tension réelle entre le brief figé et les méthodes Agile. En Scrum, on accepte que le backlog évolue. Mais ca ne veut pas dire que le brief peut rester flou. Au contraire : en Agile, le brief doit être encore plus rigoureux sur les objectifs et les critères de succès, justement parce que le 'comment' va évoluer.
Ce que je conseille : un brief en deux niveaux. Le brief stratégique (vision, OKR, contraintes majeures) est fixé avant le sprint 0 et ne change pas sans avenant. Le brief opérationnel (user stories, spécifications de chaque feature) est affiné sprint par sprint. Cette distinction permet de rester agile sur l'exécution tout en ayant un cadre contractuel stable. J'ai vu des agences gagner 25 à 40% de temps en réunions de recalage juste en appliquant cette séparation.
Les erreurs qui coûtent le plus cher
Confondre 'validé' et 'lu'. Un client qui répond 'ok merci' à votre email de brief n'a pas validé. Il a accusé réception. La validation, c'est une signature, un commentaire détaillé, ou a minima un call de confirmation explicite. Sans ca, vous travaillez sur une base fragile.
Ne pas traiter les briefs partiels. Quand le client dit 'on verra pour le module CRM plus tard', ce n'est pas une information anodine. Ca signifie que le scope peut doubler en cours de route. Acte 2, scène classique du scope creep. La bonne pratique : noter explicitement les zones grises dans le brief et les chiffrer en option, même approximativement. Ca éduque le client sur le coût réel des 'petits ajouts'.
Enfin, ne pas impliquer l'équipe de production dans le brief. Le brief qui passe du commercial au chef de projet sans jamais avoir été lu par le développeur ou le DA, c'est une bombe à retardement. Depuis que certaines agences que j'accompagne organisent une session de kick-off technique 48h après la signature du brief, les alertes remontent avant le démarrage, pas à mi-projet.
Transformer le brief en outil de pilotage
Un brief bien construit ne sert pas qu'à démarrer le projet. Il sert à le piloter. A chaque demande de modification client, la première question doit être : 'Est-ce que c'est dans le brief ?' Si oui, on le fait. Si non, c'est un avenant avec un TJM et un délai. Point.
Ca peut sembler brutal aux équipes habituées à dire oui à tout. Mais c'est précisément ce flou qui fait descendre la rentabilité des projets sous les 30%, là où les agences saines tournent à 45-55% de marge brute. Clynt permet d'ailleurs de lier chaque tâche directement au périmètre validé, ce qui rend visible en temps réel tout débordement par rapport au brief initial. Le chef de projet n'a plus à trancher seul : les données parlent.
Un brief n'est pas une formalité administrative. C'est le contrat intellectuel du projet. Traitez-le comme tel et vos projets s'en porteront mieux. Vos marges aussi.
FAQ
Combien de temps faut-il consacrer à la rédaction d'un brief client ?
Comptez minimum 2 à 3 heures au total : 60-90 minutes de session avec le client, puis 1 heure de reformulation et rédaction du compte-rendu de brief. C'est un investissement qui se rembourse dès la première demande de modification évitée.
Que faire quand le client refuse de passer du temps sur le brief ?
C'est un signal d'alarme à ne pas ignorer. Un client qui ne peut pas consacrer 90 minutes à définir ce qu'il veut sera le premier à contester la livraison. Proposez un mini-brief de 30 minutes en visio comme étape non négociable avant toute proposition commerciale. Si le client refuse ca aussi, reconsidérez sérieusement le projet.
Comment gérer les modifications du brief en cours de projet Agile ?
Distinguez les évolutions légitimes du backlog (affinement de user stories) des modifications de périmètre stratégique. Les premières font partie du processus Agile. Les secondes déclenchent systématiquement un avenant tarifé. Cette distinction doit être expliquée au client avant le sprint 0, idéalement dans le brief lui-même.
Quel outil utiliser pour stocker et partager le brief avec l'équipe ?
Notion est très populaire pour la centralisation documentaire côté agences, mais il manque de lien direct avec le suivi de projet et la facturation. Clynt permet d'attacher le brief validé à la fiche projet et de le rendre accessible à toute l'équipe, du commercial au développeur, sans duplication ni version obsolète qui circule en pièce jointe.