Comment briefer une agence de développement web : les questions auxquelles répondre avant de commencer

Le brief est le document le plus important de tout projet de développement web, et la plupart des clients le rédigent mal. Un mauvais contrat peut être renégocié. Un mauvais brief, non — au moment où vous réalisez que le périmètre était erroné, l'agence a déjà construit la mauvaise chose. Chaque conversation sur les demandes de modification, les dépassements et les attentes déçues remonte à quelque chose qui n'a pas été résolu dans le brief. Si vous êtes sur le point de commander un site ou une application web, rédiger un brief correct n'est pas une formalité : c'est l'acte le plus protecteur que vous puissiez faire pour votre budget.

Avant qu'une agence ne touche à votre projet, vous devez répondre à un ensemble de questions précises — pas vagues. Pas "nous voulons toucher plus de clients", mais : qui sont réellement les utilisateurs, c'est-à-dire quel est leur appareil, leur niveau de lecture, leur raison d'être sur le site, et que cherchent-ils à faire dans les 30 premières secondes ? À quoi ressemble le succès à trois mois, et pouvez-vous y mettre un chiffre — pas "plus de leads" mais "20 demandes qualifiées par mois" ? Qu'est-ce que votre entreprise fait qu'aucun concurrent direct ne fait, et pourquoi est-ce aujourd'hui invisible sur votre site ? Ces questions sont inconfortables parce qu'elles exposent des lacunes dans votre propre stratégie. C'est précisément l'intérêt. Mieux vaut trouver les failles dans un document que dans un produit déployé.

Les contraintes techniques les plus dures doivent être documentées avant que l'agence ne chiffre le travail. Avez-vous un CRM existant auquel le site doit se connecter ? Une passerelle de paiement avec des exigences d'API spécifiques ? Un environnement d'hébergement imposé par votre service informatique ? Une obligation légale de stocker les données à Maurice ou dans votre juridiction ? Un système de design ou une charte de marque à respecter ? Chacune de ces contraintes élimine certaines approches techniques et modifie le profil de coût du projet. Une agence qui découvre une contrainte dure à mi-parcours vous facturera la ré-architecture, ou contournera mal le problème. Les deux issues étaient évitables.

L'une des erreurs les plus coûteuses est de spécifier des solutions plutôt que des problèmes. "Nous avons besoin d'un chatbot" est une solution. "Les clients nous appellent constamment pour poser les cinq mêmes questions et nous ne pouvons pas faire évoluer notre support" est un problème. Une bonne agence lira un problème et proposera la bonne solution — qui pourrait être un chatbot, ou une meilleure FAQ, ou une navigation réorganisée qui rend les réponses trouvables. Quand vous spécifiez la solution dans le brief, vous retirez à l'agence sa capacité à faire son travail le plus précieux, et vous endossez la responsabilité de savoir si cette solution était la bonne. Décrivez ce qui est cassé ou manquant. Laissez l'équipe technique vous dire comment y remédier.

La dérive du périmètre ne commence pas pendant le projet — elle commence dans le brief. Chaque fonctionnalité vaguement décrite ("une sorte de tableau de bord", "un genre de système de réservation") s'étendra pendant le développement parce que personne n'en a défini les limites. Pour chaque fonctionnalité majeure, le brief devrait préciser ce qu'elle fait, ce qu'elle ne fait pas, et à quoi ressemble sa version minimale. Il ne s'agit pas de brider l'ambition, mais de la rendre assez lisible pour que l'agence puisse la chiffrer honnêtement et la construire correctement. Si vous ne pouvez pas décrire la version minimale viable d'une fonctionnalité, vous ne la comprenez pas encore assez pour la commander.

Le budget et le calendrier ont leur place dans le brief, et la plupart des clients évitent de les inclure en pensant que cela affaiblit leur position de négociation. C'est faux. Une agence qui ignore votre budget devinera haut pour protéger sa marge, ou bas pour gagner le projet et récupérer le coût en demandes de modification plus tard. Mettre un vrai chiffre dans le brief — "notre budget pour cette phase est de 12 000 EUR" — élimine les agences incapables de livrer dans cette fourchette et invite les autres à proposer la meilleure version du projet dans cette contrainte. Sur le calendrier : si vous avez une échéance ferme (un lancement, un salon, une obligation réglementaire), dites-le. Les agences doivent savoir si la vitesse est une vraie contrainte ou une préférence.

Comment juger si une agence a réellement lu votre brief ? C'est simple : ses questions révèlent-elles une compréhension de votre activité, ou seulement qu'elle a lu les exigences techniques ? Une bonne agence interrogera vos clients, votre position concurrentielle, vos données existantes et les hypothèses que vous faites et qui pourraient être fausses. Une mauvaise agence demandera les couleurs de la marque et le CMS que vous préférez. La proposition d'une bonne agence sera spécifique à votre brief — elle citera les contraintes que vous avez mentionnées et proposera des réponses aux problèmes que vous avez décrits. Les propositions génériques aux slides standardisées sont un signal fiable que le brief n'a pas été lu attentivement.

Pour les entreprises de l'océan Indien — Maurice, La Réunion, Madagascar, les Seychelles, les Comores — le brief doit aussi traiter explicitement l'exigence bilingue. Quelle langue est primaire ? Le contenu français est-il traduit de l'anglais ou rédigé indépendamment ? Y a-t-il des obligations légales de langue (par exemple, les sociétés de services financiers à Maurice ont des exigences de divulgation spécifiques dans les deux langues) ? Le marché de la région est rarement monolingue, et un projet qui suppose une seule langue se heurte tôt ou tard à cette réalité. Les exigences bilingues documentées dans le brief sont un poste du devis. Les mêmes exigences qui émergent pendant le développement sont une demande de modification — même résultat, mais coût et friction très différents.

Si vous êtes prêt à démarrer le processus de briefing, notre page de développement web sur-mesure détaille la façon dont Studio Hachi aborde chaque projet et à quoi ressemble une mission bien structurée. Vous pouvez aussi entamer une conversation directement — nous répondons sous un jour ouvré et vous dirons honnêtement si nous sommes le bon partenaire pour ce que vous construisez, où que vous soyez dans l'océan Indien.