Cahiers des charges

La question pourrait être la même lorsqu’il s’agit de construire un immeuble, une voiture ou n’importe quel autre objet : pourquoi faut-il faire des plans ? Il faut faire des plans parce que cela permettra déjà de savoir quel est le produit fini attendu et surtout, cela permettra de faire une estimation de coûts et de délais.

En d’autres termes, si votre budget et vos délais sont très extensibles (ce qui est plutôt rare), il est possible de ne pas réaliser de cahier des charges. Cela signifie que vous avez les moyens de payer pour demander aux réalisateurs de casser tout ou partie de ce qui a été élaboré pour le refaire d’une autre façon. Réaliser un cahier des charges nécessite du temps et de la réflexion. Cela requiert donc un effort et il est en effet très séduisant de penser que par miracle, il serait possible de s’affranchir de formaliser ses besoins. Personnellement, je ne connais aucun métier dans lequel il est possible d’obtenir quelque chose pour un délai et un cout donné sans l’avoir préalablement décrit avec un minimum de précisions.

Si les besoins ne sont pas précisément décrits, le risque est bien évidemment d’obtenir un service qui ne répond pas aux besoins ou qui y répond mais de façon partielle. Comment expliquer et démontrer alors que les besoins attendus ne sont pas pris en compte si aucun cahier des charges n’a été rédigé. Ainsi à la question « Pourquoi est-il nécessaire de faire un cahier des charges ?», il est possible de répondre avec une autre question « Comment puis-je faire pour vérifier que mes besoins ont bien été pris en compte et comment démontrer qu’il existe des manques le cas échéant ?».

Ne pas réaliser de cahier des charges va à l’encontre des bonnes pratiques reconnues au plan international. Cf  ITIL service design page 28. Chapitre 3.3 : identifying service requirements : “The need for accurate and representative information from the business is paramount”.

Il ne faut cependant pas confondre cahier des charges et carcan. Si certains considèrent parfois le cahier des charges comme un carcan trop rigide, ce n’est pas le cahier des charges en lui-même qui est trop rigide mais bien souvent le budget du projet et le délai associé.

En effet, tant que le cahier des charges n’est pas validé, il est toujours possible de modifier les besoins qui le composent (en réajustant le délai de livraison associé). Après validation du cahier des charges, il doit toujours être possible d’apporter des modifications au projet pour autant que cela ait été prévu dans le projet. Ces modifications seront alors à traiter en tant qu’évolutions. Cependant, pour que tout cela soit possible, encore faut-il l’avoir prévu en amont. Ainsi, dès le début du projet, en plus du coût du projet lui-même, il convient de prévoir un coût d’évolutions. Deux grandes erreurs sont souvent commises : le refus des évolutions en cours de projet (après rédaction du cahier des charges) et le refus des  évolutions à l’issue de la mise en production. Cela provient essentiellement du fait que l’on pense que les personnes qui rédigent le cahier des charges disposent d’une boule de cristal qui leur permettra de préciser 100% des besoins. Dans la pratique, ce n’est jamais le cas. En 20 ans d’expérience, je n’ai jamais vu un projet aboutir sans un minimum d’évolutions.

Lorsque les enveloppes de budget d’évolutions ne sont pas prévues au début du projet, cela génère systématiquement des tensions entre maitrise d’œuvre et maitrise d’ouvrage avec des personnes qui finissent parfois par travailler les unes contre les autres. Or, comment est-il possible de réussir un projet lorsque les parties prenantes travaillent les unes contre les autres au lieu de travailler ensemble ? Bien entendu, toute nouvelle application induit un changement et il existe toujours des utilisateurs réfractaires. Si les évolutions ne sont pas possibles ou trop limitées, ils vont alors trouver là une aubaine formidable pour enterrer définitivement le projet.

Le fonctionnement basé sur la prévision des évolutions s’apparente un peu au fonctionnement des méthodes agiles avec 3 itérations. Une première qui couvre 80% des besoins et qui découle du cahier des charges initial.

Une seconde qui devrait couvrir environ 10% de besoins supplémentaires découverts après la rédaction du cahier des charges. Une troisième qui doit permettre de mettre en œuvre les 10% restants. Ainsi, dans ce type de démarche, le nombre d’itérations est connu et fixé d’avance, ce qui permet un bon cadrage du budget global.

Il existe également un risque très important lié au fait de ne pas (ou mal) faire de cahier des charges : il se peut tout simplement qu’une fonction fondamentale ne soit tout simplement pas réalisable avec l’outil de développement retenu. Si cette fonction est identifiée par les utilisateurs alors que 80% du projet est déjà réalisé, tout peut alors être mis à la poubelle… Si le choix d’un outil est généralement fait en amont du cahier des charges, dans le cadre d’une étude d’opportunité par exemple, c’est pendant ou à l’issue du cahier des charges (tant que rien n’a été construit) qu’il est encore temps de changer d’outil de construction si nécessaire. En l’absence de cahier des charges, cette nécessité de changement risque fort d’intervenir trop tard.

Enfin, le cahier des charges permet aussi de détecter si le besoin est suffisamment mûr ou non. En effet, le simple fait de mettre les besoins par écrit permet parfois de détecter des avis divergents ou des changements d’avis intempestifs. Il est bien entendu nettement préférable de traiter ces divergences et incertitudes dans le cadre de la rédaction d’un cahier des charges plutôt que de construire directement pour tout casser ensuite.