← Tous les articles
Construire le bon produit
Comment rédiger un brief produit d'une page qui soit vraiment utilisé
Par l'équipe FabricLoop · Mai 2026 · 4 min de lecture
La plupart des briefs produit partagent le même destin : rédigés soigneusement avant le démarrage d'un projet, relus une fois en réunion de lancement, et jamais ouverts à nouveau. Au moment où l'équipe est en plein développement, le brief est devenu un artefact historique — cité occasionnellement lors de disputes sur le périmètre, mais rarement traité comme un guide vivant pour la prise de décision.
C'est un échec de processus, pas de format. Le brief n'est pas utilisé parce qu'il n'a pas été rédigé pour être utilisé. Il a été rédigé pour satisfaire un processus — pour cocher la case « nous avons défini les exigences » — pas pour aider concrètement l'équipe à prendre de meilleures décisions dans l'incertitude.
Un brief que l'on consulte vraiment est court, opinioné et structuré autour des questions que l'équipe posera réellement en cours de développement : que résolvons-nous, pour qui, et comment saurons-nous si ça a fonctionné ?
« Un brief n'est pas un document d'exigences. C'est une référence de prise de décision — une seule page à laquelle l'équipe peut revenir chaque fois qu'elle n'est pas sûre qu'un choix de design ou une décision de périmètre soit juste. »
Les cinq sections qui comptent
Tout ce que contient un brief produit doit répondre à l'une des cinq questions suivantes. Si une section ne répond à aucune d'elles, elle n'appartient probablement pas à un brief d'une page — elle appartient à une spécification séparée et plus détaillée.
Problème
Les utilisateurs manquent des mises à jour importantes parce qu'ils ne peuvent pas distinguer les notifications à fort signal (quelqu'un leur a assigné une tâche) de celles à faible signal (un commentaire dans un fil qu'ils suivent). Résultat : ils ignorent toutes les notifications ou les désactivent complètement. Les tickets de support sur le thème « je n'étais pas au courant » représentent 18 % de toutes les plaintes produit ce trimestre.
Utilisateurs
Primaire : responsables d'équipe et chefs de projet fréquemment mentionnés qui ne parviennent pas à suivre le volume. Secondaire : contributeurs individuels qui veulent le calme par défaut mais ont besoin de ne pas rater les assignations critiques. Pas ciblé pour les utilisateurs admin — leurs besoins en notifications sont gérés par le panneau d'administration.
Métrique de succès
Primaire Les tickets de support liés aux notifications baissent de 40 % dans les 60 jours suivant le lancement.
Secondaire Les utilisateurs actifs hebdomadaires ayant personnalisé leurs préférences passent de 12 % à 35 %.
Indicateur avancé Le taux de désactivation (utilisateurs qui désactivent toutes les notifications) baisse de 23 % à moins de 15 %.
Hors périmètre
- Préférences de notifications par e-mail (poste de travail séparé — infrastructure différente)
- Paramètres de notifications par workspace (futur ; cette version est par utilisateur uniquement)
- Planification des notifications / heures de ne-pas-déranger (besoin validé, roadmap T3)
- Granularité des notifications push mobiles (web d'abord ; mobile à suivre si validé)
Questions ouvertes
Bloquant Regroupons-nous les notifications en 2 niveaux (critique / tout le reste) ou autorisons-nous un contrôle granulaire par type ? Les entretiens utilisateurs suggèrent 2 niveaux, mais l'engineering préfère le granulaire pour la flexibilité. Décision nécessaire avant le démarrage du design.
Non bloquant Les changements de préférences s'appliquent-ils rétroactivement aux notifications existantes ? Peut être décidé pendant le développement en fonction du coût technique.
Pourquoi « hors périmètre » est la section la plus importante
Les équipes passent beaucoup de temps à écrire ce qu'elles vont construire. Elles passent très peu de temps à écrire ce qu'elles ne vont pas construire — et cette asymétrie est la cause de la plupart des dérives de périmètre. Quand le designer ajoute un bouton « heures calmes » parce que ça semble évident, ou que l'ingénieur ajoute des paramètres par workspace parce qu'il est déjà dans la zone, c'est généralement parce que personne n'avait explicitement décidé que c'était hors périmètre.
Écrire les éléments hors périmètre force une conversation sur les limites qui aurait autrement lieu en plein développement, quand le coût d'un changement de cap est bien plus élevé. Cela donne aussi au PM une base claire et documentée pour dire non aux ajouts : « Nous avons décidé que c'était hors périmètre dans le brief — voici pourquoi. »
Comment bien rédiger les éléments hors périmètre
Ne listez pas seulement ce que vous ne construisez pas — notez brièvement pourquoi. « Préférences e-mail (infrastructure séparée) » indique au lecteur que la décision était délibérée et réfléchie, pas un oubli. Cela évite que la même question de périmètre refasse surface trois fois pendant le sprint.
Questions ouvertes : la section que la plupart des briefs omettent
Chaque projet démarre avec des questions non résolues. La plupart des briefs font semblant du contraire — ils sont rédigés comme si toutes les décisions avaient été prises, même quand l'auteur sait que ce n'est pas le cas. Le résultat : les équipes découvrent les questions ouvertes en plein développement, quand elles sont le plus perturbantes.
Lister explicitement les questions ouvertes fait deux choses. D'abord, cela fait remonter les questions qui doivent être résolues avant le démarrage (bloquantes) par rapport à celles qui peuvent être décidées pendant le développement (non bloquantes). Ensuite, cela signale à l'équipe que le brief est un document vivant, pas une spécification terminée — ce qui la rend plus susceptible d'y revenir et de le mettre à jour au fil des décisions.
Le piège de la longueur
Un brief qui dépasse une page n'est plus un brief — c'est un document de spécification. Les spécifications ont leur place, mais elles servent un objectif différent. Si vous avez besoin de plus d'une page, extrayez le détail dans une annexe liée et gardez le brief aux cinq sections essentielles.
Comment FabricLoop maintient le brief vivant
Un brief ne reste utile que si l'équipe peut le trouver et le mettre à jour. FabricLoop épingle le brief dans le fil du projet pour qu'il soit toujours accessible en un clic — et la conversation autour de lui (décisions prises, questions ouvertes résolues, changements de périmètre) se trouve juste là en contexte, plutôt que dispersée dans des e-mails et des canaux.
10 points à retenir de cet article
- La plupart des briefs produit sont rédigés pour satisfaire un processus, pas pour aider les équipes à prendre de meilleures décisions. C'est pourquoi ils ne sont plus jamais utilisés.
- Un brief est une référence de prise de décision, pas un document d'exigences. Il doit répondre aux questions qui surgissent en cours de développement.
- Les cinq sections qui comptent : Problème, Utilisateurs, Métrique de succès, Hors périmètre, Questions ouvertes. Tout le reste est une spécification.
- La section Problème doit décrire la douleur de l'utilisateur de façon concrète — avec des données si possible — pas simplement nommer le domaine traité.
- Nommer pour qui vous ne construisez pas est aussi important que nommer pour qui vous construisez. L'ambiguïté sur les utilisateurs cause des dérives de périmètre dans le design.
- Les métriques de succès doivent être mesurables, limitées dans le temps et convenues avant le démarrage — pas inférées des données d'usage après coup.
- La section hors périmètre est la plus importante. Les limites de périmètre non écrites s'élargissent systématiquement pendant un développement.
- Étiquetez les éléments hors périmètre avec de brèves justifications pour éviter que les mêmes questions refassent surface pendant le sprint.
- Les questions ouvertes doivent être explicitement taguées comme bloquantes (décider avant le développement) ou non bloquantes (décider pendant le développement).
- Un brief qui dépasse une page est devenu une spécification. Extrayez le détail dans une annexe et gardez le brief concis.
