Collecter les exigences est un premier défi; les organiser dans les bons livrables, pour les bonnes audiences, au bon moment du cycle de vie projet, en est un second. La plupart des guides de gestion de projet insistent sur les techniques de collecte (entretiens, ateliers, observation) mais passent rapidement sur la question des livrables: quel type de document produire, à quel niveau de détail, et pour qui?
La littérature professionnelle identifie neuf types de documents d’exigences. Ce chiffre peut sembler excessif, mais chaque document répond à un besoin précis dans la chaîne qui relie la stratégie métier à l’implémentation technique.
Trois niveaux, trois audiences
Les documents d’exigences ne sont pas interchangeables parce qu’ils ne s’adressent pas aux mêmes personnes et ne répondent pas aux mêmes questions.
Au niveau stratégique, le BRD (Business Requirements Document) et le MRD (Market Requirements Document) s’adressent aux décideurs. Le BRD documente le problème métier, les objectifs du projet et les bénéfices attendus. Le MRD remplit une fonction similaire pour les projets orientés marché, en s’appuyant sur des données concurrentielles et des analyses de besoins clients. Ces documents permettent de valider le bien-fondé du projet avant d’investir dans la spécification détaillée.
Au niveau fonctionnel, le FRD (Functional Requirements Document) et le PRD (Product Requirements Document) décrivent ce que le système ou le produit doit faire. Le FRD détaille les exigences fonctionnelles sous forme de cas d’usage ou de règles métier. Le PRD adopte une perspective plus large, intégrant la priorisation, la segmentation utilisateurs et la roadmap produit. Le Quality Requirements Document complète ce niveau en spécifiant les exigences non fonctionnelles: performance, disponibilité, sécurité. Le UIRD (User Interface Requirements Document) se concentre sur l’ergonomie et les interactions.
Au niveau technique, la SRS (Software Requirements Specification) et le TRD (Technical Requirements Document) traduisent les exigences fonctionnelles en spécifications que les équipes de développement et d’infrastructure peuvent implémenter.
Le Customer Requirements Document occupe une place à part: il formalise les attentes d’un client externe et sert de base contractuelle. Son niveau de détail se situe généralement entre le BRD et le FRD.
Pourquoi la plupart des projets n’ont pas besoin de neuf documents
Le BABOK Guide, référence mondiale de l’analyse métier publiée par l’IIBA (International Institute of Business Analysis), insiste sur un principe fondamental: la proportionnalité. Les livrables documentaires doivent correspondre à la taille, la complexité et le profil de risque du projet. Produire neuf documents d’exigences pour un projet de taille moyenne ne renforce pas la rigueur: cela crée de la redondance, ralentit la prise de décision et multiplie les surfaces de contradiction.
En pratique, la majorité des projets fonctionnent avec deux à quatre documents d’exigences, sélectionnés selon le contexte.
Un projet de transformation interne s’appuie typiquement sur un BRD (pour cadrer la justification métier) et un FRD (pour détailler les exigences fonctionnelles). Si un développement logiciel significatif est impliqué, une SRS complète l’ensemble. Pour un produit logiciel commercial, le PRD remplace souvent le FRD en intégrant des dimensions de stratégie produit, et le MRD peut précéder le BRD pour valider l’opportunité de marché. Les projets réalisés pour un client externe ajoutent un Customer Requirements Document qui sert de référence contractuelle pour les critères d’acceptation.
Le piège inverse existe aussi: trop peu de documentation, ou une documentation mal positionnée. Un projet qui saute directement du besoin exprimé par le sponsor à la spécification technique sans passer par un FRD prend le risque de construire une solution techniquement cohérente mais fonctionnellement inadaptée.
BRD, FRD et SRS: les confusions classiques
La frontière entre ces trois documents est la source de confusion la plus fréquente.
Le BRD reste au niveau du problème métier. Il décrit pourquoi le projet existe, quels bénéfices il doit produire et quelles contraintes métier s’appliquent. Il ne décrit pas le système. Un BRD qui commence à détailler des écrans ou des flux de données a dépassé son périmètre.
Le FRD décrit ce que le système doit faire, dans le langage des utilisateurs métier. “Le système permet à un gestionnaire de soumettre une demande de remboursement en sélectionnant le type de dépense, en joignant un justificatif et en validant la soumission” est une exigence fonctionnelle. Elle décrit un comportement observable sans prescrire la solution technique.
La SRS prend le relais en spécifiant comment le système réalisera ces comportements: architecture, protocoles, formats de données, contraintes de performance. C’est un document technique destiné aux équipes de développement.
La traçabilité des exigences (le lien documenté entre chaque besoin métier et les spécifications qui en découlent) est ce qui garantit que le besoin d’origine n’est ni perdu ni déformé au fil des traductions. Quand un projet déborde de son périmètre, le diagnostic passe presque toujours par la vérification de cette chaîne: chaque exigence du BRD est-elle couverte par le FRD? Chaque exigence du FRD est-elle spécifiée dans la SRS?
La question de la terminologie francophone
Les praticiens francophones naviguent entre deux systèmes de référence. Le “cahier des charges fonctionnel” (CDCF) correspond au FRD dans ses grandes lignes, mais avec une nuance importante: en France et en Suisse, le CDCF a souvent une portée contractuelle, particulièrement dans les marchés publics. Le FRD anglo-saxon est davantage un document de pilotage interne, modifiable au fil des itérations. “L’expression des besoins” française se rapproche du BRD, sans en être un synonyme exact.
Cette ambiguïté terminologique n’est pas anodine. Quand une équipe utilise “cahier des charges” pour désigner indistinctement le BRD, le FRD et parfois même la SRS, la confusion sur les attentes et les responsabilités est presque garantie. Nommer explicitement le type de document et son périmètre, même si l’on n’adopte pas la terminologie anglo-saxonne, reste la meilleure protection contre les malentendus.
Ce que le chef de projet doit surveiller
Le chef de projet ne rédige pas la plupart de ces documents. Le BRD relève du business analyst ou du sponsor, le FRD de l’analyste métier, la SRS de l’équipe technique, le PRD du product manager. En revanche, le chef de projet est responsable de la cohérence de l’ensemble documentaire.
Trois signaux d’alerte doivent retenir son attention: un BRD approuvé sans FRD correspondant (les exigences métier ne sont pas déclinées), un FRD qui reformule le BRD au lieu de le décliner en comportements observables (l’analyse fonctionnelle n’a pas eu lieu), et une SRS qui n’est plus alignée avec le FRD après des modifications de périmètre (la traçabilité est rompue).
Le nombre de documents importe moins que leur articulation. Deux documents bien articulés, avec une traçabilité claire entre les niveaux, valent mieux que six documents produits indépendamment les uns des autres sans lien de cohérence.