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.

Fishbone Diagram

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

Créer un Cahier des Charges et Spécifications Fonctionnelles (ou BRD) pour un site internet 1L’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

9 thoughts on “Créer un Cahier des Charges et Spécifications Fonctionnelles (ou BRD) pour un site internet”

  1. Hello, merci pour cet article, il m’aide pas mal en ce moment. Je dois rédigé mon premier et c’est un peu le stress mais avec ton aide… 😉

    Un index de vocabulaire serait le bienvenue car le word contient certains mots non expliqué c-dessus.

    voila voila, et merci encore

  2. intéressant !
    Et pour aller plus loin…Question : Quelle différence entre BRS (Business Requirements Specification) et URS (Users Requirements Spécifications) ?

    Et en digestif…quelle parallèle avec le CdCf (Cahier des Charges fonctionnelles) ?

    • Outre le 2ème degré (nécessaire) par rapport à la palanquée d’acronymes utilisés ici, je préciserai simplement que le “BRS” fait référence aux specifications, “brS”, venant remplir le document, “brD” (ou CdCF :)), décrit dans cet article. Jamais entendu parlé de “URS” et je ne trouve que peu de littérature venant le différencier d’un cahier des charges classique. Bonne digestion tout de même !

  3. bonjour
    je cherche un livre de reference pour rediger des specifications fonctionnelles en anglais dans le cadre d un projet IT Finance

    • Bonjour, je ne saurais dire s’il existe un livre traitant des BRDs financiers en particuliers mais il existe énormément d’ouvrages pour approfondir le sujet, surtout en anglais. Sans nul doute, ce livre (ainsi que les propositions de livres similaires) couvrent tout ça en détail : http://amzn.to/17r8UOx. En version Kindle, il existe ces deux là : http://amzn.to/1vj9KIt. Il y en a aussi en français mais si le livrable doit être en anglais, autant utiliser une documentation dans la même langue.

  4. Merci pour ce beau travail.
    Le document français equivalent, c’est quelle reference s’il vous plait ?
    Connaitriez vous un bon dictionnaire technique pour faire des BRS bilingue (FR/Uk).

Leave a Comment