Décrire le problème avant la solution
Présentez une situation observée : qui perd du temps, quelle information manque, quelle action échoue ? Décrivez comment les personnes s’en sortent aujourd’hui et pourquoi vous souhaitez changer cela.
Évitez les objectifs impossibles à vérifier comme « une application intuitive et innovante ». Préférez un résultat observable, par exemple permettre à une équipe de suivre une demande sans échanger plusieurs fichiers.
Raconter un parcours utilisateur
Choisissez un cas représentatif et racontez-le du début à la fin. Précisez ce que l’utilisateur sait déjà, ce qu’il saisit et ce qu’il obtient. Ajoutez les erreurs ou exceptions fréquentes.
Si plusieurs rôles interviennent, expliquez qui peut lire, modifier et valider. Les règles d’accès influencent souvent davantage le travail que l’apparence d’un écran.
Lister les dépendances
Un projet peut attendre un accès, une validation ou une source de données. Les rendre visibles tôt permet d’organiser le travail.
- Outils existants, documentation disponible et interlocuteurs.
- Données à importer et personne qui les connaît.
- Contenus, identité visuelle et traductions à fournir.
- Décideurs et personnes disponibles pour la recette.
- Contraintes de date et raison concrète de cette échéance.
Distinguer indispensable et souhaitable
Pour chaque fonctionnalité, demandez si la première version peut atteindre son objectif sans elle. Gardez une liste de souhaits, mais séparez-la clairement du périmètre de lancement.
Une contrainte budgétaire peut aussi être utile à partager. Elle permet d’explorer des compromis sur la portée, le niveau de finition ou l’ordre des étapes. Elle ne remplace pas la définition des livrables.
Un modèle de brief à copier
Complétez les phrases suivantes avec des exemples concrets. Quelques lignes par point suffisent pour préparer un premier échange.
- Nous aidons [utilisateurs] à [résultat attendu].
- Aujourd’hui, ils utilisent [solution actuelle] et rencontrent [problème].
- Le premier parcours doit permettre de [action de bout en bout].
- Le produit doit se connecter à [outils ou données].
- La première version doit être prête pour [échéance et raison].
- Nous validerons le résultat en vérifiant [critères observables].
- Les décisions seront prises par [rôle] et testées par [utilisateurs].
Ce que le premier échange doit produire
Le but n’est pas de résoudre immédiatement tous les détails techniques. Cherchez à identifier les questions ouvertes, les risques et la prochaine étape qui permettra de préciser le périmètre.
Vous devez repartir avec une compréhension commune du problème et des éléments à approfondir. N’envoyez pas de mots de passe ou de données sensibles dans votre premier message : une description des systèmes concernés suffit.