Le cahier des charges : à quoi ça sert ?
Un nouveau projet, un nouveau logiciel, un appel d’offre, … le cahier des charges est le document incontournable. Beaucoup se posent des questions sur son contenu et souvent les réponses sont intéressantes mais incomplètes et passent à côté de l’essentiel.
Une recherche sur internet vous permettra de trouver des dizaines de sites qui vous fournissent des explications, des exemples de plans de cahiers des charges. Bien entendu, il en existe pour des centaines de métiers. Notre propos, ici, est d’évoquer le système d’information, les logiciels.
La norme, le GRAAL ? AFNOR NF X50-151, NF EN 16271, …
“Génial ! Voici un canevas. Il ne reste plus qu’à remplir les cases et nous obtiendrons un cahier des charges de bon aloi…” Eh non. Pas si simple. La norme est importante. Elle va vous fournir une check-list de point à ne pas oublier.
Mais il importe de faire entrer les utilisateurs dans la boucle. Sans eux, point de salut. Et quand on parle de les faire intervenir ce n’est pas pour qu’ils décrivent leur quotidien en 2 lignes qu’on va coller dans le document. Il va falloir détailler en les interviewant. Ils diront s’ils sont satisfaits de telle ou telle fonction du logiciel existant, si la fonction doit être repensée et comment ils imaginent le produit idéal.
Surtout, ne pas évoquer les solutions ?
Beaucoup avancent l’argument qu’un cahier des charges doit aborder les exigences et pas des solutions. Mais que faut-il comprendre par solution ?
Tout dépend de votre projet.
- Envisagez vous d’acquérir un logiciel pour le paramétrer ? Vous devrez peut-être vous adapter à la technologie utilisée, à l’ergonomie.
- Envisagez-vous le developpement d’un nouveau logiciel spécifique ? Laissez peut-être les prestataires vous proposer les meilleures technologies pour vos besoins présents et futurs.
Pour le reste, le “comment”, votre métier et ce qui vous rend efficace, allez-y. Ecrivez tout ce dont l’utilisateur a besoin pour être performant dans ses tâches quotidiennes.
Exemple, votre processus de saisie de facture. Il commence par une catégorie client parce que c’est comme ça et c’est très important pour l’utilisateur. Ensuite, il faut saisir un numéro de client. Etc. Peut-être aurez vous besoin de décrire précisément un véritable workflow. Si c’est le cas, alors faites-le dès le cahier des charges.
A quoi bon mettre une banale exigence “le logiciel doit permettre de choisir la catégorie du client pendant la saisie de facture” dans le cahier des charges ? Vous pourriez faire croire à un prestataire que la saisie de facture se passe d’une manière standard (comme dans 90% des cas pour lui) et qu’il peut mettre le choix de la catégorie n’importe où sur l’écran, alors que pour vous, il vous faut un workflow complexe.
Vous pouvez et, même devez, écrire les exigences fonctionnelles précises si elles conditionnent la productivité de vos utilisateurs dans leurs habitudes de travail.
Pour cela, écrivez des cas d’utilisation.
Si vous le faîtes vous vous éviterez de nombreux malentendus qui pourraient mener à l’échec de votre projet.
Distinction entre cahier des charges général et cahier des charges détaillé
A ce stade de l’article, il convient d’aborder un point pratique. On se rend bien compte que placer en détail toutes les fonctions risque d’allourdir le cahier des charges.
D’où l’utilité d’avoir 2 documents bien distincts.
- La partie générale,
- La partie détaillée
Cette façon de faire à plusieurs avantages.
Premièrement, dans la gestion de l’appel d’offre, vous pouvez transmettre la partie générale à tous les prestataires, la partie détaillée à ceux qui veulent en savoir plus (attention au cadre des marchés publics cependant ).
Deuxièmement, la partie détaillée sera réutilisable à plusieurs étapes du projet. Bien rédigée, elle deviendra un guide pour vos tests fonctionnels, puis un guide utilisateur.
Référentiels porteurs de valeur
Trop souvent, une énergie importante est déployée pour produire des documents qui, de part leur contenu et leur structure, deviennent obsolètes dès le démarrage du projet, puis disparaissent dans les limbes des disques durs.
Au contraire, il faut avoir pour objectif de faire de ces documents, de véritables référentiels porteurs de valeur. Ces documents pourront ainsi continuer à vivre pendant et après le projet.