Quelques conseils pour rédiger un cahier des charges fonctionnel

S’il y a bien une charge pesante, c’est celle de rédiger un cahier… des charges. Cela porte bien son nom ! Et pourtant c’est un exercice aussi imposé qu’essentiel puisque c’est le point de départ d’une relation potentielle…

Dont on aimerait qu’elle se passe bien évidemment. Seulement voilà, on le sait les contrats de mariage ce n’est pas fait pour les mariages mais pour les divorces ! Alors si jamais cela se passait mal, on y reviendra au cahier des charges

Et autant faire en sorte que ça parte dans le bon sens avant d’en arriver là et le cahier des charges sert à cela.

Mais à en voir passer régulièrement, ressemblant parfois à la liste des courses au père Noël… On se dit que ce n’est pas si facile à faire. Alors, quelques conseils pour rédiger un cahier des charges fonctionnel, c’est quoi l’histoire ?

Commençons par une précision. Il peut y avoir de multiples formes de cahier des charges. Cela dépend évidemment de la prestation attendue. Un cahier des charges techniques pour une prestation d’hébergement par exemple, avec des attentes de disponibilité, etc.

N’a rien à voir avec un cahier de charges fonctionnel, qui décrit un besoin fonctionnel. C’est de ce type de cahier des charges dont nous allons parler ici.

Commençons par une anecdote, je me souviens avoir reçu un cahier des charges pour un projet de digitalisation des entretiens annuels et de gestion des compétences. Bon j’avoue, le choix de la police de caractère Comic Sans MS aurait dû mettre la puce à l’oreille.

Quoique la première page avait tous les atours du truc sérieux : le versionning du document, les initiales de la revue par les pairs et la date… Ils avaient bien appris leur leçon qualité… Sauf que le versionning c’est bien, encore faut-il avoir quelque chose à « versionner »…

Parce que dès la deuxième page, là tu te dis, c’est du vide et ce n’est pas bien barré cette affaire. Une phrase laconique du genre l’objectif c’est « d’acquérir un logiciel de gestion des compétences »… Comme si ton objectif c’était d’acheter un fer à repasser…

Non ton objectif c’est d’avoir une chemise présentable… Bref, et dans la foulée, brut de tout décoffrage, un paragraphe de description de l’existant… Et tiens-toi bien…

Une copie d’écran des champs de la base de données Access qu’ils utilisent… Bon, on arrête les frais. Pas la peine de lire la suite.

Avant de passer en revue quelques conseils de bon sens prenons le sujet par le bon bout, donc dans le bon sens, en commençant par une question simple : à quoi ça sert un cahier des charges fonctionnel ?

A décrire ce dont tu as besoin pour que celui qui va essayer d’y répondre le fasse au mieux. Donc l’objectif premier c’est qu’il comprenne ce dont tu as vraiment besoin. Et comme ce qu’il fait ce n’est pas ton métier, ce n’est pas la peine de lui expliquer comment il doit le faire…

Si tu pars en vacances et que tu te dis, j’ai besoin d’un cabriolet. Tu ne vas pas expliquer dans ton cahier des charges comment doit marcher un clignotant. Les constructeurs automobiles le savent mieux que toi.

Tu vas exprimer ton souhait de rouler tranquille au soleil… Les éditeurs de logiciels c’est pareil. Bon commence par le début.

1. Décrire ce que tu vises. Ton ambition, ou ce que tu cherches à résoudre comme problème. Avec tous les éléments de contexte qui permettent de bien le comprendre, de l’appréhender, d’en toucher la substantifique moëlle.

Le but n’est pas que tu dises ce que tu veux mais qu’ils comprennent ce dont tu as besoin. Donc évite ton jargonnage interne, décris ton entreprise, la place qu’y prend le projet, ce qu’on en attend, l’existant qui peut permettre de mieux cerner l’ambition, les ressources disponibles, les utilisateurs ciblés etc.

Au besoin fournis la cartographie applicative de ton SIRH pour que l’on s’y repère, pour identifier ce avec quoi cela va échanger ou pas etc. et tu spécifieras les détails plus loin dans les contraintes et caractéristiques plus détaillées de ton projet.

2. Après tu dois décrire ton besoin. Les fameuses charges, le fonctionnel, ce que tu veux qu’on te délivre. Or, là tu dois comprendre plusieurs choses.

La première c’est que tu t’adresses à des éditeurs qui partent d’une solution existante, plus ou moins customisable. Ce n’est pas du développement à façon. Donc ce n’est pas la peine de décrire le moindre détail de « comment ça doit faire » tel ou tel truc mais bien le résultat dont tu as besoin.

Cela ne sert à rien d’expliquer que tu veux que « quand on clique ici cela ouvre un popup qui fait ci ou ça ». Tu ne conçois pas une application informatique, tu décris un besoin. Tu diras par exemple plutôt que tu attends « la possibilité de sélectionner une compétence du référentiel à partir de la fiche de poste ».

Et ça te fait une ligne dans ton fichier de suivi pour la recette quand tu seras livré.

La seconde chose que tu dois avoir en tête c’est que celui qui répond à peut-être plusieurs manières de répondre à un même besoin et que, normalement, il connait le potentiel de son outil. C’est donc essentiel qu’il comprenne ce que tu veux pouvoir faire et surtout pourquoi.

Parce qu’il peut avoir une idée sur la manière de traiter autrement ton besoin que ce que tu as imaginé et c’est peut-être un meilleur compromis in fine.

Un troisième point sur cette étape de description de ce dont tu as besoin : n’hésite pas à illustrer et détailler. Le détail des référentiels utilisés, la cartographie et les flux d’informations nécessaires…

Fournis ton formulaire actuel, décris les processus et qui fait quoi à chaque étape, sois précis dans la description des rôles et des habilitations attendues, ton organisation, les référentiels que tu utilises etc.

3. Explique les contraintes et caractéristiques de ton projet. A commencer par tous les éléments de dimensionnement : combien de personnes concernées, par rôle, etc. La volumétrie de ton projet conditionne beaucoup de choses et plus tu permets au prestataire de l’apprécier, mieux il te servira.

Tes contraintes en termes de ressources aussi. Genre on est deux et on fera la recette fonctionnelle au mois d’août quand on sera tous en vacances… Pas gagné là encore. Un projet cela mobilise des ressources en interne, sur lequel ton prestataire s’appuiera. Autant prévenir.

Donc ton macro-planning aussi et ce qui n’est pas négociable comme jalon, et en étant réaliste. Cela ne sert à rien de demander un projet paie pour la semaine prochaine…

4. Là, enfin, tu challengeras ce que tu as écris en demandant à d’autres de relire, amender ce que tu as fait. Et n’oublie surtout pas ta DSI… Il paraît même qu’il connaisse un peu l’informatique, leur regard est donc utile et ils t’aideront.

Ah si enfin, un conseil avant de commencer, même si ce n’est pas du même ordre. Regarde un peu le marché et ce qu’il peut te fournir avant de te dire que tu as besoin d’un mouton à cinq pattes…

Parce que cela ne sert à rien d’écrire un super cahier des charges qui décrit tous tes rêves et auquel personne ne répond… Un peu de réalisme avant de définir son besoin ne nuit pas.

En résumé, un cahier des charges fonctionnel a pour objectif d’aider un prestataire à comprendre le besoin réel qu’il doit essayer de satisfaire. On l’écrit donc dans cette optique, pour qu’il comprenne, pas pour dire à sa place comment il doit faire son métier.

J’ai bon chef ?

Oui tu as bon mais on ne va pas en faire toute une histoire.