Un document de besoins métier (BRD) est le lien entre les parties prenantes métier et les équipes techniques : il décrit ce dont l’entreprise a besoin et le traduit en exigences que les développeurs peuvent construire. Avec Trupeer, vous pouvez gagner des heures sur la rédaction de vos BRD en commençant par un modèle gratuit de document de besoins métier, en le personnalisant avec vos directives de marque, puis en transformant de longs BRD en visites vidéo que tout le monde peut réellement consulter.

Les projets échouent rarement parce que personne n’a écrit les exigences. Ils échouent parce que ce qui a été écrit était trop vague pour être contesté. Tout le monde a signé un document indiquant que le système devait être « convivial et rapide », puis quatre mois plus tard, ils découvrent qu’ils n’entendaient pas la même chose.

Un document de besoins métier vaut la peine d’être rédigé lorsqu’il rend le désaccord possible avant le début de la construction, plutôt qu’après. Ce modèle est conçu pour cela : chaque exigence est numérotée, priorisée et accompagnée de critères d’acceptation suffisamment précis pour être discutés dès maintenant.

Télécharger le modèle de document de besoins métier

Gratuit, modifiable, sans filigrane. La plupart des équipes utilisent Word pour le document et Excel pour le tableau des exigences une fois que le volume dépasse environ trente pages.

Qu’est-ce qu’un document de besoins métier ?

Un document de besoins métier, ou BRD, indique ce dont l’entreprise a besoin pour un projet et pourquoi, avant que quiconque ne décide comment le construire. Il définit le problème, le périmètre, les parties prenantes, les exigences elles-mêmes et les critères selon lesquels le résultat sera évalué.

Sa fonction réelle est de parvenir à un accord. Un BRD est le document que tout le monde signe pour confirmer qu’il comprend la même chose, c’est pourquoi le test utile d’un BRD n’est pas de savoir s’il se lit bien, mais s’il est suffisamment précis pour que quelqu’un puisse y faire objection.

Comment personnaliser ce modèle dans Trupeer

Étape 1 : Ouvrir la section Modèles

Accédez à la section Modèles depuis la navigation principale.

Étape 2 : Sélectionner et ouvrir un modèle

Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.

Étape 3 : Développer l’affichage du modèle

Si nécessaire, développez l’affichage du modèle pour voir clairement la mise en page complète et les détails.

Étape 4 : Modifier le modèle

Cliquez sur Modifier pour commencer à apporter des changements au modèle sélectionné.

Dans l’éditeur, vous pouvez :

• Ajouter de nouvelles sections

• Définir ou mettre à jour des règles de mise en forme

• Ajouter un logo et ajuster sa position ainsi que les paramètres associés

Étape 5 : Enregistrer votre modèle personnalisé

Après avoir effectué tous les changements nécessaires, cliquez sur Enregistrer pour stocker le modèle mis à jour comme le vôtre.

Étape 6 : Aperçu et ajustements fins du modèle

Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez l’Aperçu.

Depuis l’écran d’aperçu, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle s’affiche exactement comme vous le souhaitez.

Avec un modèle de document de besoins métier, vous pouvez :

• Gagner du temps sur la rédaction : évitez la page blanche grâce à une structure utilisée par des BAs et des PM expérimentés.

• Aligner le métier et la technique : des sections intégrées relient les objectifs métier aux exigences fonctionnelles.

• Rester conforme à votre marque : appliquez votre logo, vos polices et vos couleurs à l’aide du brand kit de Trupeer.

• Communiquer clairement : transformez des BRD denses en visites vidéo pour les revues des parties prenantes.

• Standardiser sur tous les projets : utilisez le même modèle de BRD pour chaque initiative.

• Atteindre des équipes internationales : traduisez vos BRD en 65+ langues en un clic.

Pourquoi vous avez besoin d’un document de besoins métier

• Le périmètre devient quelque chose sur lequel vous pouvez vous appuyer plutôt que quelque chose à retenir. La plupart des litiges sur le périmètre sont des échecs de documentation, pas une mauvaise foi.

• Les exigences obtiennent des priorités : lorsque le temps manque, vous coupez de manière délibérée plutôt que de supprimer ce qui reste.

• Les hypothèses sont consignées, c’est à ce moment-là que quelqu’un remarque la mauvaise.

• Les critères d’acceptation existent avant la construction : ainsi, « terminé » n’est pas décidé par la personne la plus bruyante à la fin.

• La passation résiste aux départs. Les projets qui perdent leur analyste métier en cours de route sont ceux pour lesquels un BRD s’amortit immédiatement.

• Les prestataires peuvent chiffrer sur quelque chose de réel. Un BRD vague génère un devis large et un projet lourd en demandes de changement.

Ce que contient un document de besoins métier

• Contrôle du document : version, auteur, date, diffusion et statut d’approbation.

• Résumé exécutif : ce qu’est le projet et pourquoi, en un paragraphe.

• Objectifs métier, exprimés comme des résultats mesurables plutôt que des activités.

• Contexte et énoncé du problème : ce qui se passe actuellement et ce que cela coûte.

• Périmètre : ce qui est inclus, et explicitement ce qui ne l’est pas.

• Parties prenantes : qui est concerné, qui décide, qui signe.

• État actuel, tel qu’il est réellement.

• Exigences métier, numérotées, priorisées, chacune avec des critères d’acceptation.

• Hypothèses, contraintes et dépendances.

• Risques, avec des responsables.

• Résumé des coûts et des bénéfices, et retour attendu.

• Calendrier et jalons clés.

• Critères de succès pour l’ensemble du projet.

• Glossaire, car la moitié des litiges sur les exigences sont des litiges de vocabulaire.

• Bloc de validation.

• Annexes : schémas de processus, données, écrans, analyse complémentaire.

La structure du modèle

Dix à vingt pages, c’est la norme pour un projet de taille intermédiaire. Au-delà de trente, le tableau des exigences a généralement absorbé des décisions de conception qui relèvent plutôt d’une spécification fonctionnelle.

Comment rédiger une exigence qui résiste à la relecture

C’est l’ensemble du savoir-faire. Une exigence est bien rédigée lorsque deux personnes qui ne sont pas d’accord savent, en la lisant, qu’elles ne sont pas d’accord.

Faible : Le système doit être convivial.
Mieux : Un nouvel utilisateur doit pouvoir soumettre une demande sans formation, mesuré par 8 utilisateurs sur 10 terminant la soumission sans aide en moins de 3 minutes.

Faible : Les rapports doivent se charger rapidement.
Mieux : Le rapport récapitulatif mensuel doit s’afficher en moins de 4 secondes pour un jeu de données allant jusqu’à 50 000 lignes.

Faible : Les managers doivent avoir une visibilité sur les approbations.
Mieux : Un manager doit pouvoir voir toutes les demandes en attente de son approbation, triées par date de soumission, sur un seul écran, sans filtrage.

Faible : Le système doit s’intégrer à la comptabilité.
Mieux : Les demandes approuvées doivent être transmises au système de comptabilité dans les 15 minutes, y compris le centre de coûts et le code TVA, avec les échecs consignés et relancés automatiquement.

Le schéma de chaque amélioration est le même. Nommez qui en a besoin, ce qui est précisément attendu, et la condition dans laquelle vous accepteriez que cela soit atteint. Les mots à ne pas croire dans vos propres brouillons : convivial, robuste, fluide, intuitif, rapide, flexible, scalable, facile. Chacun cache une décision que quelqu’un prendra plus tard sans vous.

Prioriser les exigences avec MoSCoW

Les exigences sans priorités deviennent toutes obligatoires par défaut, puis la première pression du planning impose des coupes arbitraires.

La discipline qui fait fonctionner MoSCoW : pas plus d’environ 60 % des exigences devraient être des Indispensables. Si tout est un Indispensable, vous avez une liste de souhaits avec une colonne de priorité. Et la liste « Pas cette fois-ci » est la plus précieuse, car c’est le registre écrit de ce qui a été consciemment reporté plutôt qu’oublier.

Le tableau des exigences

Chaque exigence a besoin d’un ID, car « l’exigence de reporting » est ambigu dès qu’il y en a deux. La source compte : au mois quatre, quelqu’un demandera qui a demandé cela, et « l’entreprise » n’est pas une réponse.

Matrice de traçabilité

Le contrôle qui vérifie que rien n’a été abandonné discrètement, et que rien n’est construit sans raison.

Deux échecs apparaissent immédiatement. Une exigence sans cas de test ne sera pas vérifiée, et un élément de spécification fonctionnelle qui ne renvoie à aucune exigence correspond à quelque chose qui est construit alors que personne ne l’a demandé. Les deux sont fréquents et les deux sont faciles à repérer de cette manière.

Exemple de document de besoins métier

Un exemple travaillé abrégé, pour que vous puissiez voir le niveau de précision.

Projet : Remplacement du système de notes de frais. Version : 1.2. Auteur : Analyste métier. Approbateurs : Directeur Financier, Directeur des Systèmes d’Information, Directeur RH.

Objectifs métier. Réduire le délai moyen de remboursement des notes de frais de 24 jours ouvrés à 10. Réduire de 50 % le temps passé par l’équipe finance sur le traitement des notes de frais, actuellement 14 heures par semaine. Atteindre 95 % de conformité à la politique sur les notes de frais soumises, actuellement 71 %.

Énoncé du problème. Les notes de frais sont soumises via un tableur et envoyées par e-mail. Le routage des approbations est manuel, les justificatifs arrivent séparément, et 29 % des notes de frais enfreignent la politique sans être détectées avant le paiement. La finance passe environ 14 heures par semaine à relancer, et le remboursement dure en moyenne 24 jours ouvrés contre un engagement de 10 jours dans le manuel du personnel.

Dans le périmètre. Soumission des notes de frais, capture des justificatifs, validation de la politique, routage des approbations, transmission au système comptable, notification aux employés.
Hors périmètre. Rapprochement des cartes corporate, paramétrage des taux kilométriques, intégration à la paie, migration des notes de frais historiques au-delà de 12 mois.

Exigences.

Hypothèses. La structure organisationnelle actuelle dans le système RH est exacte et maintenue. Le système comptable expose une API prise en charge. Les limites de la politique ne changeront pas pendant la mise en œuvre.

Contraintes. Budget de £85 000. Mise en production avant le nouvel exercice financier. Aucun recrutement supplémentaire côté finance.

Risques. Les données de la ligne de reporting RH se révèlent peu fiables, sous la responsabilité du Directeur RH, atténué par un audit avant la construction. L’adoption par les approbateurs est lente, sous la responsabilité du Directeur Financier, atténué par la formation des managers et une exécution parallèle de deux semaines.

Critères de succès. Remboursement moyen à 10 jours ouvrés ou moins dans le trimestre suivant la mise en production. Temps de traitement finance à 7 heures hebdomadaires ou moins. Conformité à la politique à 95 % ou plus.

Besoins métier vs exigences fonctionnelles vs exigences techniques

La source la plus courante de confusion sur ce sujet, et la raison pour laquelle de nombreux BRD sont en réalité des spécifications portant le mauvais titre.

Le test : si une exigence mentionne un écran, un champ, un bouton ou un composant système, elle a dérivé vers le territoire fonctionnel. Les besoins métier doivent résister à un changement complet de solution. Si vous changez de prestataire et que la moitié de votre BRD devient invalide, alors la moitié n’était jamais un besoin métier.

Qui prépare un document de besoins métier, et qui le signe

Préparé par l’analyste métier, ou par le responsable produit ou le chef de projet lorsqu’il n’y a pas d’analyste. Rédigé avec les parties prenantes plutôt que pour elles, car un BRD produit en vase clos est signé sans être lu, ce qui est pire que l’absence totale de BRD.

Signé par les personnes auxquelles on peut demander des comptes : le sponsor métier, le responsable du budget et les responsables de chaque fonction dont le travail change. Ajoutez le responsable IT ou le responsable de la livraison, en confirmant que les exigences sont comprises plutôt que simplement réalisables.

La signature la plus importante est celle de la personne à qui l’on demandera au mois quatre si cela a bien été validé.

Comment rédiger un document de besoins métier

1. Commencez par établir l’objectif métier, sous forme de nombre. Si personne ne peut exprimer le résultat mesurable, la collecte des exigences produira une liste de fonctionnalités plutôt qu’un document.

2. Identifiez les parties prenantes et les droits de décision avant de collecter quoi que ce soit. Savoir qui peut dire oui évite la plupart des revirements tardifs.

3. Documentez honnêtement l’état actuel, y compris les solutions de contournement. C’est là que se cachent les vraies exigences.

4. Collectez les exigences via des entretiens et de l’observation, pas seulement via un atelier. Les ateliers font remonter ce que les gens disent vouloir. L’observation fait remonter ce qu’ils font.

5. Rédigez chaque exigence avec des critères d’acceptation associés, dans la même session. Ajouter des critères plus tard revient à les rédiger de mémoire.

6. Priorisez avec MoSCoW et tenez la ligne sur la proportion « Indispensable ».

7. Consignez explicitement les hypothèses, contraintes et dépendances. Les hypothèses non écrites deviennent des litiges.

8. Construisez la matrice de traçabilité au fur et à mesure plutôt qu’à la fin.

9. Faites circuler pour relecture avec une date limite et un relecteur nommé par section. « Des commentaires ? » envoyé à une liste de diffusion produit du silence.

10. Faites passer les parties prenantes en revue lors d’une session avant de demander les signatures, puis validez la version et gérez formellement les changements à partir de ce moment-là.

Variantes du modèle de document de besoins métier

Note sur la version Agile : un BRD et un backlog ne sont pas en concurrence. Le BRD capture pourquoi et ce dont l’entreprise a besoin, ce qui évolue lentement. Le backlog capture ce qui sera construit ensuite, ce qui change en permanence. Les équipes qui abandonnent entièrement le BRD ont tendance à perdre le fil du « pourquoi », puis à le redécouvrir comme un argument.

Bonnes pratiques

• Rédigez des exigences que quelqu’un pourrait refuser. L’imprécision est perçue comme un accord et génère des litiges plus tard.

• Une exigence par ligne. Tout ce qui contient « et » est probablement deux.

• Ajoutez immédiatement des critères d’acceptation, jamais plus tard.

• Numérotez tout et ne renumérotez jamais. Mettez les ID au rebut au lieu de les réutiliser.

• Consignez la source de chaque exigence.

• Gardez les solutions hors du document. Dès que vous nommez un écran ou un champ, vous commencez à concevoir.

• Définissez chaque terme ambigu dans le glossaire. Des mots comme « note de frais », « utilisateur » et « approuvé » ne signifient pas la même chose selon les départements.

• Validez la version au moment de la validation et gérez formellement les changements ensuite.

• Gardez la liste hors périmètre visible. Elle empêche plus de dérive du périmètre que n’importe quelle autre section.

Erreurs courantes

• Exigences impossibles à réfuter. « Intuitif » et « robuste » ne peuvent pas être testés : ils sont donc interprétés au moment de la construction par la personne la plus proche.

• Pas de priorités : tout devient obligatoire jusqu’à ce que la date limite impose des coupes arbitraires.

• Des solutions déguisées en exigences. Elles contraignent la conception avant même que quelqu’un ait évalué les options.

• Pas de critères d’acceptation : « terminé » devient une négociation.

• Section hors périmètre manquante. C’est la prévention la moins coûteuse contre la dérive du périmètre.

• Rédigé pour les parties prenantes au lieu d’être rédigé avec elles. Signé sans être lu.

• Hypothèses laissées non écrites. Chaque projet en a, et celles qui ne sont pas consignées sont celles qui le font échouer.

• Jamais mis à jour après la validation. Les exigences changent, et une base non maintenue cesse d’être la référence en laquelle personne n’a confiance.

• Pas de traçabilité : les abandons discrets sont découverts lors des tests d’acceptation utilisateur.

Consignez l’état actuel en l’enregistrant

Ouvrez le modèle dans Trupeer AI, appliquez votre brand kit pour que le BRD corresponde à vos autres documents de projet, puis modifiez directement n’importe quelle section. La configuration se trouve dans le guide du modèle.

La section « état actuel » est l’endroit où les BRD sont les plus faibles, car écrire comment quelque chose fonctionne aujourd’hui prend plus de temps que personne ne prévoit, et omet toujours les solutions de contournement. Enregistrez le processus existant une seule fois, et Trupeer AI génère la documentation écrite de l’état actuel avec des captures d’écran capturées automatiquement, ainsi qu’une visite vidéo commentée que vous pouvez joindre en annexe. Les prestataires qui chiffrent à partir de votre BRD comprennent un enregistrement de deux minutes plus vite que quatre pages de texte.

Enregistrez-le. Documentez-le. Traduisez-le en 65+ langues pour les équipes de livraison offshore. Stockez-le dans votre base de connaissances. Trupeer it.

Questions fréquentes

Existe-t-il un modèle gratuit de document de besoins métier dans Word ?

Oui. Word est le format principal, avec des notes d’orientation dans chaque section que vous supprimez au fur et à mesure que vous écrivez, ainsi que le tableau des exigences et le bloc de validation préconfigurés. Téléchargement gratuit, sans inscription, sans filigrane.

Puis-je télécharger gratuitement un modèle de document de besoins métier dans Word ?

Oui. Chaque format est un téléchargement gratuit sans compte requis. Utilisez-le sur autant de projets que vous le souhaitez.

Existe-t-il un modèle de document de besoins métier au format Word doc ?

Oui, une version .doc est incluse pour les anciens systèmes de documents et les bibliothèques qui ne gèrent pas correctement .docx.

Existe-t-il un modèle gratuit de document de besoins métier en PDF ?

Oui. Le PDF est le format de base en lecture seule : c’est celui que vous diffusez après la validation afin que la version approuvée ne puisse pas être modifiée par accident.

Existe-t-il un exemple de document de besoins métier en PDF ?

Oui. L’exemple complet du système de notes de frais présenté ci-dessus est inclus en tant qu’exemple PDF, avec dix exigences, des critères d’acceptation, des priorités MoSCoW, ainsi que des hypothèses et des risques. Lire un BRD final est le moyen le plus rapide d’évaluer le niveau de précision dont le vôtre a besoin.

Où puis-je télécharger un modèle de document d’exigences dans Word ?

Sur cette page, dans Word, .doc, Google Docs, Excel et PDF. Tous gratuits. Si vous avez besoin de la spécification fonctionnelle plutôt que des besoins métier, il s’agit d’un document distinct, et la différence est expliquée ci-dessus.

Qu’est-ce qu’un BRD ?

Un document de besoins métier. Il indique ce dont l’entreprise a besoin pour un projet et pourquoi, avant que des décisions ne soient prises sur la manière de le construire, et sert de document de référence que les parties prenantes signent pour confirmer une compréhension partagée.

Que doit inclure un document de besoins métier ?

Le contrôle du document, le résumé exécutif, des objectifs métier mesurables, l’énoncé du problème, le périmètre avec des exclusions explicites, les parties prenantes, l’état actuel, des exigences numérotées avec priorités et critères d’acceptation, les hypothèses, contraintes, dépendances, risques, coûts et bénéfices, le calendrier, les critères de succès, le glossaire et la validation.

Quelle est la différence entre besoins métier et exigences fonctionnelles ?

Les besoins métier indiquent ce dont l’entreprise a besoin et pourquoi, indépendamment de toute solution. Les exigences fonctionnelles indiquent ce que le système doit faire pour répondre à ces besoins. « Les notes de frais doivent être remboursées sous 10 jours ouvrés » est un besoin métier. « Le système route les notes de frais vers l’approbateur nommé dans la ligne de reporting RH » est fonctionnel. Un besoin métier doit résister au changement de prestataires.

Quelle doit être la durée d’un document de besoins métier ?

Dix à vingt pages pour un projet de taille intermédiaire. Les petits projets peuvent être réalisés en cinq. Au-delà de trente, la section des exigences a généralement absorbé une conception fonctionnelle qui relève d’ailleurs.

Qui rédige le document de besoins métier ?

L’analyste métier, ou le responsable produit ou le chef de projet lorsqu’il n’y a pas d’analyste. Il doit être rédigé avec les parties prenantes plutôt que pour elles, car un BRD produit en vase clos est signé sans être lu.

Qui valide un BRD ?

Le sponsor métier, le responsable du budget et le responsable de chaque fonction dont le travail change, ainsi que le responsable de la livraison ou IT confirmant que les exigences sont comprises. La validation doit suivre une session de revue, et non un e-mail de diffusion.

Combien d’exigences un BRD doit-il contenir ?

Autant que le périmètre en a réellement besoin, mais si vous dépassez environ quatre-vingts, vérifiez si des détails fonctionnels se sont glissés. Un signal utile est la proportion « Indispensable » : au-delà d’environ 60 %, la priorisation n’a pas été faite correctement.

Qu’est-ce qu’une matrice de traçabilité ?

Un tableau qui relie chaque exigence à l’objectif métier qu’elle sert, à la spécification fonctionnelle qui y répond, et au cas de test qui la vérifie. Il permet de repérer les exigences qui ne seront jamais testées, ainsi que le travail qui est construit sans renvoyer à une exigence.

Puis-je personnaliser ce modèle de document de besoins métier ?

Oui, chaque version est entièrement modifiable. Supprimez les sections qui ne s’appliquent pas plutôt que de laisser des titres vides, et adaptez le tableau des exigences à votre propre système de priorités si vous n’utilisez pas MoSCoW. Dans Trupeer AI, vous pouvez aussi appliquer votre brand kit pour que le BRD corresponde à vos autres documents de projet.

Modèles associés

• Modèle de plan de projet

• Modèle de plan de gestion de projet

• Modèle de documentation de projet

• Modèle de documentation technique

• Modèle de documentation logicielle

• Modèles de documentation de test

• Modèle de processus métier

• Modèle de plan de conduite du changement

• Modèle de business plan