Brief de développement - 15 questions au client

Un bon brief de développement économise des semaines d'allers-retours et protège le budget du « et aussi ça ». Sans réponses aux questions de base, l'équipe devine les exigences et le client s'étonne des délais et du prix. Ci-dessous - 15 questions à poser avant le devis et le kick-off. Les réponses transforment une idée en périmètre clair, pas en liste de souhaits.

• Pourquoi le brief - figer l'objectif, les limites et les critères de succès
• Quand demander - avant la proposition commerciale et avant le kick-off
• Qui répond - le décideur et le product owner, pas « un peu tout le monde »
• Ce que vous obtenez - périmètre clair, délai réaliste, budget transparent
• Règle - pas de réponse = risque de reprises et de coûts cachés

Pourquoi collecter le brief avant le démarrage

Développer un site, un service ou une intégration bute presque toujours sur l'incertitude, pas sur le code. Si l'objectif est flou, les priorités changent chaque semaine et le « must-have » arrive en fin de course - délais et coût augmentent.

Le brief n'est pas de la bureaucratie. C'est un court contrat sur le sens du projet : quoi faire, pour qui, vers quel résultat, sous quelles contraintes. Plus tôt ces questions sont closes, plus l'estimation est précise et plus les deux parties sont sereines.

15 questions au client

1. Quel problème métier résolvons-nous ?

Pas « il faut un site », mais ce qui fait mal maintenant : peu de leads, chaos dans les demandes, processus manuels, catalogue obsolète. Le problème façonne l'architecture et les priorités fonctionnelles.

2. Qui est l'audience cible et quel est son scénario principal ?

Qui est l'utilisateur : acheteur B2B, client retail, employé, partenaire. Un scénario principal compte plus que dix secondaires.

3. Comment saurons-nous que le projet a réussi ?

Il faut des critères mesurables : nombre de leads, conversion, temps de traitement des commandes, moins d'erreurs, vitesse de publication. Sans KPI, « terminé » reste subjectif.

4. Quel délai, et y a-t-il une deadline dure ?

Un lancement pour un salon, une saison ou une release produit change le plan : MVP maintenant ou périmètre complet plus tard. Une deadline sans priorités signifie souvent des reprises.

5. Quelle fourchette budgétaire est réaliste ?

Un corridor budgétaire aide à couper un scope irréaliste dès le départ. Une fourchette honnête bat « à peu près pas cher » sans chiffres.

6. Que existe déjà : site, CRM, ERP, API, contenu ?

L'inventaire économise de l'argent. Intégrer un CRM vivant et migrer un catalogue sont des volumes à part, pas « un détail à la fin ».

7. Quelles intégrations sont obligatoires au lancement ?

Paiements, stock, 1C/ERP, e-mail, analytics, messageries. La liste d'intégrations influence plus le délai que le choix du framework.

8. Y a-t-il des contraintes de stack, d'hébergement et de sécurité ?

Standards corporate, on-premise, exigences SSI, interdiction du cloud - tout doit être dans le brief avant l'estimation, pas après le choix du prestataire.

9. Qui décide et qui valide les étapes ?

Un seul décideur accélère le projet. Si la validation passe par cinq services sans owner - prévoyez un buffer pour l'attente et les changements d'avis.

10. Qu'est-ce qui est must-have en v1, et que peut attendre ?

Séparez « nécessaire au lancement » de « souhaitable plus tard ». Un MVP au noyau clair livre plus vite et coûte moins que « tout d'un coup ».

11. Y a-t-il des références « comme ça » et des contre-exemples « pas comme ça » ?

Des liens vers sites et produits économisent des heures de débats UX et de ton. Les contre-exemples aident aussi : ils marquent les limites de goût et d'attente.

12. Qui prépare le contenu, les textes, les photos et les accès ?

Le contenu devient souvent le goulot. Si textes et accès arrivent tard - design et développement s'arrêtent.

13. Quels rôles utilisateurs et niveaux d'accès faut-il ?

Invité, client, manager, admin, partenaire - tableaux de bord et droits différents. Décrivez le modèle de rôles avant de concevoir les écrans.

14. Y a-t-il des exigences légales, données personnelles ou sectorielles ?

RGPD / lois locales, santé, finance, secteur public - changent l'architecture de stockage, consentements, logs et contrats. On ne peut pas « ajouter ça après ».

15. Qui assure le support du produit après le lancement ?

Mises à jour, monitoring, édition de contenu, réponse aux incidents. Si le support n'est pas dans le plan - le produit en production vieillit vite.

Comment utiliser les réponses en pratique

Résumez les réponses sur une page :

Avec ce tableau, proposition et roadmap se construisent facilement. Si une case est vide - ce n'est pas « un détail pour plus tard », c'est un risque ouvert.

Erreurs typiques dans le brief

• Confondre un souhait (« faites beau ») avec un résultat (« +30 % de leads »).
• Traiter les intégrations comme « un bouton », pas comme un flux de travail séparé.
• Ne pas nommer de product owner côté client.
• Construire le must-have avec tout le backlog sans priorisation.
• Ignorer le support : lancer sans owner de support = dette dès le premier jour.

Conclusion

Un brief de développement, ce sont 15 questions courtes mais fermes sur l'objectif, l'audience, les KPI, les délais, le budget, les intégrations, les contraintes, les rôles et le support. Plus les réponses sont complètes avant le démarrage, plus l'estimation est précise et moins il y a de surprises en cours de route.

Si vous avez besoin d'aide pour bâtir le brief, prioriser le MVP ou estimer le développement à partir de vos réponses - contactez-moi.

Questions fréquemment posées

Combien de temps faut-il pour remplir le brief ?

En général 1-2 jours ouvrés s'il y a un décideur et l'accès aux données de base. C'est plus difficile quand les décisions sont dispersées entre services : alors un court atelier de 1-2 heures bat des semaines d'e-mails.

Peut-on estimer un projet sans brief ?

On peut donner une fourchette de-à, pas un chiffre précis. Sans objectif, intégrations et critères de succès, l'estimation flotte presque toujours. Le brief réduit l'incertitude et protège les deux parties des fausses attentes.

Le brief remplace-t-il le cahier des charges technique ?

Non : le brief est l'entrée du cahier des charges. Il fige le sens et les limites. Le cahier des charges décrit ensuite écrans, données, API, rôles et critères d'acceptation. Sans brief, le cahier gonfle souvent et change en cours de route.

Que faire si le client ne connaît pas le budget ?

Proposez un corridor et des options de périmètre : MVP / standard / étendu. Un scope réaliste se choisit alors plus facilement. « Budget illimité » signifie en pratique presque toujours que les priorités ne sont pas encore alignées.

Faut-il mettre à jour le brief pendant le développement ?

Oui, si l'objectif, la deadline ou le must-have changent. Le brief est un document vivant de limites. Toute extension de scope doit modifier explicitement le délai ou le budget, sinon l'équipe travaille à crédit.