On a reçu des centaines de briefs projet au fil des années. Certains ont mené à des premiers appels productifs et des projets signés en quelques semaines. D'autres ont mené à trois réunions où personne ne savait ce qu'on construisait vraiment.
La différence ne vient presque jamais de la taille du projet ou du budget. Elle vient du brief.
Un bon brief fait gagner du temps à tout le monde — le vôtre et le nôtre. Un mauvais brief crée un cycle d'attentes mal alignées, d'estimations vagues et de réunions inutiles. Et le pire : la plupart des mauvais briefs ne sont pas écrits par des gens qui ne savent pas ce qu'ils veulent. Ils sont écrits par des gens qui savent exactement ce qu'ils veulent mais le décrivent d'une façon impossible à cadrer.
Cet article est le guide qu'on aimerait pouvoir envoyer à chaque prospect avant le premier appel. On l'a aussi transformé en template Word à remplir que vous pouvez télécharger et envoyer à n'importe quelle agence — y compris nous.
À quoi sert réellement un brief
Un brief n'est pas un contrat. Ce n'est pas un cahier des charges. Ce n'est pas un PDF de 40 pages avec des wireframes et des schémas de base de données.
Un brief est un point de départ pour une conversation. Son rôle est de donner à l'agence assez de contexte pour avoir une première réunion intelligente — une où on pose les bonnes questions au lieu de passer une heure à comprendre les bases.
Les meilleurs briefs sont courts, clairs, et honnêtes sur ce qui est connu et ce qui ne l'est pas.
Les 7 questions auxquelles votre brief doit répondre
Pas besoin de template. Pas besoin de titres et de mise en forme. Il suffit de répondre à ces sept questions clairement. Une ou deux pages suffisent.
1. Quel problème résolvez-vous ?
Pas « qu'est-ce que vous voulez construire » — quel problème existe aujourd'hui ? « Notre équipe commerciale suit les prospects dans des tableurs et perd 30 % des relances » est utile. « On a besoin d'un CRM » ne l'est pas — parce que la solution n'est peut-être pas un CRM du tout.
Commencez par la douleur. La solution vient après.
2. Qui utilisera ce logiciel ?
Listez les personnes concrètes. « Notre équipe opérationnelle de 12 personnes » est clair. « Divers intervenants à travers l'organisation » ne l'est pas. Quel est leur niveau technique ? À quelle fréquence l'utiliseront-ils ? Sont-ils des employés internes ou des clients externes ?
Le profil utilisateur conditionne chaque décision de design et de technique.
3. Qu'est-ce qui existe aujourd'hui ?
Qu'est-ce que les gens utilisent actuellement pour gérer ce problème ? Des tableurs ? L'outil d'un concurrent ? Du papier ? Rien ? S'il y a un système existant, qu'est-ce qui fonctionne et qu'est-ce qui ne fonctionne pas ?
Ça indique à l'agence si elle remplace quelque chose, améliore quelque chose, ou construit à partir de zéro — trois projets très différents.
4. À quoi ressemble le succès ?
Pas des fonctionnalités — des résultats. « Notre temps de traitement des commandes passe de 3 jours à 4 heures. » « On arrête de perdre des données clients entre les départements. » « On peut intégrer un nouveau collaborateur sans une semaine de formation. »
Si vous ne pouvez pas décrire le succès sans lister des fonctionnalités, vous cherchez peut-être une solution plutôt que de résoudre un problème.
5. Quelle est votre fourchette budgétaire ?
C'est la question que tout le monde évite, et c'est celle qui compte le plus.
Pas besoin d'un chiffre exact. Mais « quelque part entre 20K et 50K € » est infiniment plus utile que « on discutera du budget plus tard. » Voici pourquoi : une solution à 20K et une solution à 200K pour le même problème sont complètement différentes. Sans fourchette, l'agence se trompe ou vous donne une proposition qui ne correspond pas à votre réalité.
Être transparent sur le budget n'est pas un désavantage en négociation. C'est un gain de temps. Une bonne agence vous dira ce qui est possible dans votre fourchette — et ce qui ne l'est pas.
6. Quel est votre calendrier ?
Y a-t-il une deadline ferme — une exigence réglementaire, un lancement produit, une date de début de contrat ? Ou le calendrier est-il flexible ? Les deux sont acceptables, mais l'agence doit savoir lequel avant de cadrer.
« On a besoin que ce soit en production en septembre » et « on aimerait commencer quand le bon partenaire est disponible » mènent à des plans projet très différents.
7. Qu'avez-vous déjà décidé — et qu'est-ce qui est ouvert ?
Avez-vous déjà choisi une plateforme ? Le logiciel doit-il fonctionner avec des outils spécifiques ? Le design est-il fait ? Y a-t-il des contraintes techniques de votre équipe IT ?
Et tout aussi important : sur quoi n'êtes-vous pas sûr ? Où voulez-vous l'avis de l'agence ? Les meilleurs projets sont ceux où le client est honnête sur ce qu'il ne sait pas.
Ce qu'il faut laisser de côté
Un brief n'est pas un cahier des charges. Résistez à l'envie d'inclure :
Des wireframes écran par écran que vous avez dessinés vous-même. Ça verrouille la conversation sur une solution spécifique avant que le problème soit pleinement compris. Partagez-les en référence si vous voulez, mais ne les traitez pas comme des exigences.
Des exigences techniques détaillées trouvées en ligne. « Doit utiliser une architecture microservices » ou « doit être construit en React » — sauf si vous avez une équipe technique qui a pris cette décision, laissez la tech à l'agence. C'est pour ça que vous la recrutez.
Un document de 30 pages. Si votre brief fait plus de 3 pages, ce n'est plus un brief. C'est un cahier des charges que l'agence devra valider de toute façon.
Ce qui nous fait prendre un brief au sérieux
Après des années de lecture de briefs projet, voici les signaux qui nous indiquent que le prospect a réfléchi :
Il décrit le problème avant la solution. Il est honnête sur ce qu'il ne sait pas. Il inclut une fourchette budgétaire sans qu'on la demande. Il a expliqué qui sont les utilisateurs et ce qu'ils utilisent aujourd'hui. Et le brief est concis — parce que la clarté demande un effort, et un brief concis signale un client qui respecte le temps de tout le monde.
À l'inverse, les briefs qui disent « on a besoin d'une app » sans contexte, les briefs de 40 pages de specs copiées d'un autre projet, et les briefs sans budget ni calendrier — ceux-là mènent généralement à des cycles de vente longs et des attentes mal calibrées.
Téléchargez le template
On a transformé ces 7 questions en un template d'une page à remplir et à envoyer à n'importe quelle agence — y compris nous. C'est un simple document Word avec des invites guidées pour chaque section. Pas d'email requis, pas d'inscription.
Télécharger le Template de Brief Logiciel (Word) →
Utilisez ceci comme checklist
Avant d'envoyer votre prochain brief à une agence — pas seulement nous — passez en revue les sept questions ci-dessus. Si vous pouvez répondre aux sept en langage simple, votre première réunion sera productive, votre estimation sera plus précise, et le projet démarrera sur de meilleures bases.
On a écrit sur comment on livre les projets une fois le travail lancé et sur comment on évalue les décisions build-vs-buy. Mais tout ça commence par un brief clair. Le plafond de qualité du projet est fixé avant la première ligne de code.
Vous avez un projet en tête et voulez en discuter ? Commençons la conversation →