Un bon brief de projet explique qui a besoin d’aide, ce que ces personnes doivent faire et à quoi ressemble un résultat réussi. Quelques paragraphes clairs, un croquis rapide et un exemple concret suffisent pour commencer.
Ce contexte me permet de poser des questions et de définir le travail avec vous avant de proposer un périmètre et un calendrier. Ce guide montre ce qu’il faut y mettre, à partir d’un produit de réservation imaginaire. Les mêmes questions valent pour une nouvelle application, un bot ou une fonctionnalité dans un produit existant.
Commencez par le problème et par les personnes
Dites-moi qui utilisera le produit, ce que ces personnes cherchent à faire et comment elles s’y prennent aujourd’hui. Pour notre exemple de réservation : « Les clients écrivent à notre équipe pour demander un créneau. L’équipe consulte un agenda partagé, envoie un lien de paiement et confirme chaque réservation à la main. » Cela explique le travail que le logiciel doit faciliter.
Décrivez le résultat que vous voulez obtenir. Ce peut être moins d’étapes manuelles, un parcours de réservation qui fonctionne ou un moyen pour les clients de suivre leur commande. Si vous mesurez déjà quelque chose, partagez le chiffre. Sinon, décrivez à quoi ressemblerait un bon résultat.
Déroulez une tâche importante
Choisissez une tâche qui compte et décrivez-la du début à la fin. Par exemple : un client choisit une prestation, sélectionne un créneau disponible, paie et reçoit une confirmation. Ensuite, une personne de l’équipe peut consulter ou annuler la réservation.
Mentionnez aussi les exceptions. Que se passe-t-il si le paiement échoue, si le client change d’avis ou si deux personnes choisissent le même créneau ? Vous n’avez pas à résoudre chaque cas vous-même. Soulever la question nous aide à repérer le travail avant de nous engager sur un calendrier.
Décidez de ce dont la première version a besoin
Séparez ce qui est indispensable à une première version utile de ce qui peut venir ensuite. Un produit de réservation peut n’avoir besoin que d’un seul prestataire de paiement au lancement, alors que les abonnements et les récompenses de parrainage peuvent attendre. Vos priorités m’aident à proposer une version utile en elle-même.
Le nom d’une fonctionnalité peut cacher plusieurs décisions. Pour des « comptes clients », dites-moi qui peut s’inscrire, ce que chacun peut voir, si l’équipe a des droits différents et ce qui se passe quand quelqu’un perd son accès. Ces points peuvent rester des questions ouvertes que nous réglerons ensemble.
Écrivez comment vous vérifierez qu’une fonctionnalité est terminée. « Envoyer les e-mails de réservation » laisse place à des attentes différentes. Une vérification plus claire serait : « Après un paiement réussi, le client reçoit un e-mail avec la référence de réservation, la date et les instructions d’annulation. »
Ces vérifications s’appellent souvent des critères d’acceptation. Leguide de GOV.UK sur les user stories explique la même idée : décrire le besoin de l’utilisateur, puis lister les résultats qui confirment qu’il est satisfait.
Partagez ce qui existe déjà
Votre site ou application actuel, et s’il est déjà utilisé.
Les maquettes, éléments de marque, contenus et exemples d’interfaces qui vous plaisent. Expliquez ce qui vous plaît dans chaque exemple.
Les services à connecter au produit, comme le paiement, l’e-mail, un CRM ou un bot Telegram.
Les données existantes à migrer, et à qui appartiennent les comptes concernés.
Les contraintes comme les langues nécessaires, les appareils, les exigences d’accessibilité ou un choix technique déjà fait.
Si vous améliorez un produit existant, dites-le d’emblée. Une fonctionnalité peut entraîner des changements dans les données, les droits et les processus actuels. Examiner le système existant fait partie de la compréhension du périmètre.
Expliquez l’échéance et qui décide
S’il y a une date de lancement, dites-moi pourquoi elle compte et ce qui doit être prêt à ce moment-là. Une date liée à un événement n’entraîne pas les mêmes choix qu’une date souhaitée. Une fourchette de budget, si vous en avez une, nous aide aussi à parler des priorités avant que je prépare une proposition.
Indiquez la personne qui peut confirmer les priorités et valider le travail. Parlez-moi aussi des dépendances : contenus en attente, accès à récupérer auprès d’un ancien développeur, ou autre équipe chargée d’une intégration. Elles peuvent peser sur le planning autant que le code.
À quoi ressemble un bon brief de départ
Nous proposons des prestations sur rendez-vous. Aujourd’hui, les clients réservent par message et l’équipe vérifie les disponibilités à la main.
Dans la première version, les clients devraient choisir une prestation et un créneau disponible, payer via notre prestataire actuel et recevoir une confirmation de réservation. L’équipe doit pouvoir consulter les réservations et gérer les annulations.
Nous avons déjà un site, une identité visuelle et un compte de paiement. Les formules d’abonnement et les récompenses de parrainage peuvent venir plus tard.
Nous avons besoin d’aide pour décider comment gérer les annulations et les paiements échoués. Nous avons une date de lancement souhaitée, mais nous voulons convenir de ce qui est réaliste une fois ces questions tranchées.
Cet exemple laisse encore des points à définir : règles de disponibilité, remboursements, droits de l’équipe et contenu de chaque confirmation. C’est normal. Un brief de départ donne assez de contexte pour repérer ces décisions.
Un brief à copier
Nous voulons créer ou améliorer : …
Les personnes qui l’utilisent sont : …
Le problème du processus actuel est : …
La tâche la plus importante pour un utilisateur est : …
Pour la première version, nous avons besoin de : …
Ces fonctionnalités peuvent attendre : …
Ce qui existe déjà, y compris maquettes et intégrations : …
Notre échéance, nos contraintes et notre fourchette de budget, si nous les connaissons : …
Nous considérerons que c’est réussi quand : …
La personne qui prend les décisions est : …
Laissez une ligne vide si vous ne connaissez pas encore la réponse. Les questions ouvertes doivent rester visibles. Une fois le périmètre convenu, chaque nouvelle demande devrait s’accompagner d’une discussion sur son effet sur le travail et le calendrier avant d’être ajoutée.
Vous pouvezenvoyer votre brief ici. Je travaille par écrit : pas de présentation ni d’appel à préparer. Je vous répondrai avec des questions et les prochaines étapes avant que nous convenions du travail.