Créer un Cahier des Charges et Spécifications Fonctionnelles (ou BRD) pour un site internet

Le Cahier des Spécifications (ou « Business Requirements Document – BRD » en anglais) est un outil très puissant qui vous permettra de valider vos livrables par rapport aux demandes initiales. Le but est d’y articuler très clairement ce qui doit être livré en fin de projet, vu par les commanditaires du projet. Cette étape de formalisation est absolument critique dans ce qui vous permettra de dire si tel ou tel point est atteignable dans le temps / ressources / budget imparti et en définitive, si le projet est un succès ou non.

Il y a de nombreux paramètres à prendre en compte si l’on veut bien faire les choses. La liste variera de projets en projets mais quelques aspects majeurs ressortent au fil des épreuves et c’est d’ailleurs pour cela que l’on pourra retrouver dans la culture Six Sigma (le DMAIC : Define, Measure, Analyze, Improve & Control).

Un cahier des charges, pour faire quoi ?

• S’aligner avec les clients, équipes impactées et son équipe
• Jeter les bases de la communication avec un prestataire technologique
• Alimenter les futures phases du projet
• Décrire les Cas Typiques d’Utilisation (« Use Cases » en anglais) et préparer le « comment » d’un point de vue technique

On voit bien que le BRD est la base qui permet au projet de se nourrir et surtout de se construire durablement. Pour autant, on reste dans la zone du « quoi » et on n’effleure qu’à peine le « comment ». On distingue un Cahier des Charges et Spécifications Fonctionnelles (BRD, donc) d’un Cahier des Charges et Spécifications Techniques (Product Requierements Document, PRD). Pour reprendre un exemple cité sur le net, imaginons un département événementiel qui souhaite avoir à sa disposition 100 bouteilles de vin par soir lors d’une conférence de 3 jours, le vin devant être porté à 14° : il s’agit du BRD. Le PRD étant l’expression technique du même besoin, à savoir la mise à disposition d’un espace de stockage approprié ayant telle ou telle particularité.

Qui doit créer le BRD ?

On s’en doutera, la liste des auteurs d’un tel document est l’un des ingrédients les plus délicats. D’une part, on veut s’assurer d’avoir une répartition représentative du « business », mais d’un autre côté, on veut s’assurer aussi d’avoir en face de soi des experts opérationnels et autres équipes étant liées à l’ampleur des changements. S’il n’y a pas de recette magique, voilà déjà des pistes:

• Le noyau dur de votre projet
• Vos homologues côté Business
• Les responsables des processus actuels ?
• Des experts ?
• Des groupes supports ? (IT / RH / légal / finance)

J’ai mon équipe, c’est bon ?

Que l’on soit prestataire ou interne, le fait d’avoir une équipe de responsables ne signifie malheureusement pas que vous ayez toutes les cartes en main. Pour garder le parallélisme avec la méthodologie Six Sigma, on va commencer par un audit -rapide- de la situation. Idéalement, les informations devront être chiffrées et comparables. Plus vous pourrez réunir d’informations quantifiables sur le « avant », plus il sera simple et flatteur de comparer avec le « après ». Cela peu paraître un peu racoleur, mais dites-vous que votre communication vers votre hiérarchie s’en trouvera facilitée si vous pouvez aligner les « +162% de taux de conversion & -17% de variation de semaine en semaine » au lieu d’un email élogieux venant d’un de vos partenaires.

Pour ceux familiers avec Six Sigma, cette étape de documentation couvre les outils suivants:  AS IS, IS / IS NOT, Fishbone Diagram, 5 Whys et autres du même genre.

J’ai de tout dans mon cahier de spécifications, comment garder de l’ordre ?

Un BRD n’est juste un défouloir pour le business, bien que cela puisse être un excellent moyen de commencer à récupérer des retours. Les éléments pris en compte doivent répondre -idéalement- au points suivants:

1. Unilatéral : Chaque point doit adresser une seule demande. La réciproque est fausse.
2. Complet : Même avec un système de suivi de versions de fichiers, si une définition n’est pas complète, finie, elle n’est pas recevable.
3. Persistent : Chaque point est intègre et ne vient pas contredire une autre demande faite dans le même document.
4. Partagé : la requête est partagée, validée par les autres parties.
5. A jour : la requête est en phase avec les versions pertinentes des applications en question.
6. Réaliste : la demande doit être en phase avec l’ambition et les ressources du projet.
7. Limpide : Il faut arriver à donner de la lumière à chaque point. Si quelque chose n’est pas clairement explicité, il le sera officieusement par l’équipe technique. C’est un point qu’il est facile de mettre en avant auprès du business qui voit souvent cette tâche comme un point de pénibilité… mais le sentiment de contrôle est très souvent le plus fort !
8. Obligatoire : comme abordé dans le point précédent, si une demande n’est pas exprimée mais seulement attendue ou évoquée, c’est un peu comme dire que le projet ne sera pas un succès pour cette raison. Vous avez des ressources pour ce qui n’est pas demandé ?

Comment organiser votre BRD ?

Un Cahier des Charges et Spécifications Fonctionnelles doit être accessible pour ceux qui vont devoir vivre avec au quotidien. Il doit par exemple couvrir les points suivants:

• But du projet
• Périmètre
• Équipes impliquées
• Résultat des audits (y compris les AS IS, IS / IS NOT, Fishbone, …)
• Planning général
• Processus de validation

L’exercice étant assez pénible tant qu’on a pas d’exemple sous la main, je vous offre gracieusement un modèle de cahier des charges et des spécifications fonctionnelles. Il est au format Microsoft Word, ce qui devrait convenir au plus grand nombre. Il est également sensé fonctionner sur PC comme sur Mac, mais je n’ai pas testé. Il ne vous reste plus qu’à vous lancer et à remplir furieusement chaque point. Il va de soi que tout n’est pas forcement applicable à votre projet. D’ailleurs, je n’ai pas inclue de vraie grille de demande parce qu’on est dans le cas par cas à ce niveau là. Mon seul conseil c’est qu’Excel est votre ami !

Un dernier conseil ? Pour la route ?

1. Valider le périmètre: revoir et préciser le périmètre du projet en fonction des demandes. En se basant sur l’ampleur ou la diversité des demandes, certains objectifs auront un impact trop important sur d’autres équipes pour pouvoir être traité dans votre projet. A partir de là, soit vous pouvez entamer une discussion avec le business pour revisiter le périmètre, soit vous acceptez de coacher un autre chef de projet pour qu’il gère une piste pour votre projet. Cela peut paraître flatteur et évident mais attention aux dépendances, si le sous-projet prend du retard ou se fige, votre projet en pâtira.
2. Définissez les acronymes, les KPIs, assurez-vous de faire circuler un certain niveau de connaissances dans le groupe.
3. Communiquez très fréquemment sur des bases factuelles. Par exemple, dans le cas d’un site internet, les statistiques hebdomadaires peuvent être une excellente raison d’envoyer un email de rappel à votre liste mais aussi au-delà de vos interlocuteurs habituels pour dire ce qui se passe.

N’hésitez pas à partager vos retours d’expérience. Je me ferai un plaisir de mettre à jour le document ou cet article.

Bons projets
Greg