Du recueil des besoins au cahier des charges

Je publie ci-dessous la préface qu'Yves Constantinidis m'a aimablement demandée pour un ouvrage publié par les éditions Eyrolles, Expression des besoins pour le système d'information : le guide du cahier des charges.

*     *

D'après le Standish Group les projets informatiques connaissent un taux d'échec qui ne serait toléré dans aucun autre domaine de l'ingénierie : de ses enquêtes, on peut retenir qu'en gros 25 % des projets échouent, 50 % aboutissent avec un délai et un coût très supérieurs à la prévision, 25 % seulement sont convenablement réussis.

En cas d'échec, on entend souvent dire « c'est la faute de l'informatique » mais en fait il convient de dire que, par principe, c'est toujours la faute du métier que le produit informatique devait outiller (maîtrise d'ouvrage, MOA). Certes il arrive que le réalisateur du produit (maîtrise d'œuvre, MOE) soit défaillant, mais alors la MOA aurait dû prendre en temps utile des mesures pour redresser la situation.

Souvent, d'ailleurs, le seul tort de la MOE sera d'avoir accepté un contrat impossible car l'ingénierie des besoins a été défaillante et le projet était donc condamné dès le départ : la MOA s'est lancée dans le projet sans savoir ce qu'elle voulait faire, sans avoir exprimé ses priorités ni levé les ambiguïtés du vocabulaire, puis par la suite elle a été versatile etc.

Une expression de besoin bien faite garantit le succès ou du moins (car on ne peut jamais se prémunir contre toutes les surprises) une probabilité de succès de l'ordre de 90 % : on mesure l'enjeu si l'on compare ce taux aux données du Standish Group.

*     *

Jean-Pierre Meinadier est l'un des maîtres français les plus respectés en ingénierie des systèmes industriels [1]. Invité à participer à un projet de système d'information (SI), il fut immédiatement congédié pour avoir posé une question jugée incongrue : « qui est responsable ? ».

Il a alors compris alors que contrairement à un projet d'automobile ou d'avion, dont les enjeux techniques sont mesurables et « froids », un SI est « chaud » : chaque projet comporte implicitement de tels enjeux « politiques » de légitimité, de découpage des pouvoirs et des responsabilités, que l'entreprise préfère souvent laisser implicites les données nécessaires à son succès.

C'est cette « chaleur » du SI qui explique le taux d'échec extravagant des projets. Les acteurs ne manquent ni de bon sens ni d'intelligence, mais ils les mettent au service de priorités qui ne sont pas celles de l'efficacité de la production de l'entreprise ni de la qualité de ses produits - objectifs qui, par contre, sont précisément ceux que sert un SI.

L'enjeu de l'ingénierie des besoins n'est donc pas purement technique : il s'agit de promouvoir des priorités (efficacité, qualité) qui sans doute devraient être celles de toute entreprise, mais à qui s'opposent d'autres formulations de sa mission (produire « de l'argent » ou « de la valeur pour l'actionnaire ») ainsi que les intérêts des corporations professionnelles.

*     *

Pour pouvoir agir dans les sables mouvants de la sociologie et de l'idéologie, il faut des idées claires et des principes fermes : c'est ce que nous propose ici Yves Constantinidis.

On peut en effet désamorcer les pièges de la « politique » si l'on sait s'y prendre à temps, dans l'étape préliminaire et relativement « froide » de l'expression de besoins, si l'on se donne la peine d'éliminer les défauts du vocabulaire et les malentendus qu'ils provoquent, si l'on s'est enquis de la pertinence des besoins et priorités, si l'on a obtenu les validations qui, étant authentiques, scellent l'accord ultérieur des dirigeants et leur soutien au projet.

Le pivot de cette affaire, c'est la personne morale que Constantinidis nomme « assistance à maîtrise d'ouvrage » et que je préfère nommer « maîtrise d'ouvrage déléguée » (MOAD) car elle a reçu du directeur, stratège et responsable suprême de la MOA qu'il engage par sa signature, délégation du soin de l'expertise en SI.

La MOAD a trois interlocuteurs : les stratèges (celui du métier et le DG, stratège de l'entreprise), les utilisateurs (qui se subdivisent en plusieurs catégories) et l'informatique (c'est-à-dire la MOE qui peut être, selon les cas, soit la DSI de l'entreprise, soit un fournisseur). Elle doit savoir parler les langages de ces divers interlocuteurs et assurer entre eux la fonction d'interprète.

La fonction de MOAD est donc une vraie spécialité, et celui qui a exercé cette fonction pendant quelques années acquiert une connaissance approfondie de l'entreprise et du métier pour lesquels il travaille, y compris dans leurs dimensions « politiques » et symboliques qu'il sait gérer avec souplesse et discrétion.

Malheureusement les entreprises n'ont pas encore toutes compris la nécessité de cette fonction, ni perçu les compétences qu'elle exige : sa dénomination change d'une entreprise à l'autre, et cela montre bien la perplexité des DRH.

*     *

L'outil fondamental de la MOAD est un modèle, mise en forme qui concrétise l'expression de besoin en schématisant le métier tel qu'il fonctionnera une fois outillé par le SI.

Tout comme une base de données, ce modèle est un être que personne ne peut voir en entier mais qui présente à chaque catégorie d'acteurs la vue qui lui convient : à l'informaticien, le diagramme de classe, étape initiale de la programmation dans un langage à objets (et quelques autres diagrammes) ; au stratège, le diagramme d'activité qui décrit le processus. Pour les utilisateurs, la vue pourra être audiovisuelle : en plaçant sur l'Intranet un dessin animé complété par une documentation et un outil d'autoformation, on aide chacun à percevoir la finalité du système et l'étendue de sa responsabilité personnelle, on élucide le processus de production dans lequel il intervient.

*     *

Le cahier des charges est, sur ce modèle, la vue qui précise et récapitule toutes les exigences auxquelles le produit doit satisfaire, qu'elles soient propres au métier ou à la plate-forme technique de l'informatique. Ce document peut prendre une forme contractuelle, mais mieux vaut le concevoir comme une étape nécessaire de la coopération entre la MOE et la MOAD.

Pour prendre une métaphore dans la vie courante, supposons que vous fassiez construire une maison. Vous avez établi son plan avec l'aide d'un architecte et dites : « dans cette pièce, il faudra quatre prises de courant et une applique commandée par un interrupteur ». Ce sont là des spécifications générales, produites par la MOAD avec le conseil de la MOE et validées par le stratège.

Puis la MOE demande à la MOA de dire où installer les prises, les interrupteurs et l'applique. Marquer ces emplacements sur le plan, c'est établir les spécifications détaillées, produites par la MOE et validées par la MOAD. Enfin la MOE fera le plan de câblage qui précise le parcours des goulottes et saignées : ce sont des spécifications techniques qui n'intéressent pas la MOA mais qui sont indispensables pour passer à la réalisation.

Il importe de respecter cette progression : comme le dit Donald Knuth, « l'optimisation prématurée est la racine de tous les maux » et certains projets s'enlisent parce que l'on se préoccupe, dès une phase initiale, de choix techniques qui devraient intervenir plus tard.

*     *

Il faut, nous l'avons dit, que les validations soient authentiques : chacun des responsables doit pouvoir comprendre les documents qu'on lui soumet, et se savoir engagé par sa signature. Il ne convient pas, par exemple, de soumettre le diagramme de classe à un stratège car cette vue sur le modèle n'est pas faite pour lui : comme il ne la comprendra pas, sa signature sera passive et il n'hésitera pas par la suite à remettre le modèle en question alors que les travaux sont déjà engagés.

La MOAD doit donc lui présenter à l'appui du diagramme d'activité une synthèse en français, claire et en quelques pages, qui indique ce qu'il s'agit de faire, comment on envisage de le faire et pourquoi il ne convient pas de le faire autrement. Il sera également utile de lui présenter le processus sous la forme d'un dessin animé, même si certains stratèges croient cela contraire à leur « sérieux ».

*     *

Entre le stratège et la MOAD, le rapport est celui qui existe entre le décideur et l'expert. La décision revient au stratège qui, ayant la vue d'ensemble, peut tenir compte de contraintes et d'opportunités que l'expert ignore ; mais le stratège doit écouter l'expert qui, mieux que lui, se tient au courant de l'état de l'art des SI.

Il ne suffit pas de réussir des projets : il faut encore que l'informatique soit bien utilisée. La MOAD a donc avec les utilisateurs une relation continue : elle les forme, observe leur relation avec le poste de travail, promeut les bonnes pratiques et combat les mauvaises.

Pour la MOE, la MOAD doit être un client compétent qui sache ce qu'il veut et connaisse assez d'informatique pour en comprendre les contraintes, mais qui se garde d'imposer des choix techniques.

Enfin, et même si le cahier des charges précise les obligations de chacun, la relation entre la MOAD et la MOE doit être plus partenariale que contractuelle. Il convient qu'elles travaillent en tandem dès le début du projet, la responsabilité du travail passant de l'une à l'autre selon l'étape considérée.

*     *

Certains SI sont étonnamment bien réussis. Lorsqu'on interroge les utilisateurs, ils disent « on sait ce qu'on a à faire », « le travail est clair », « l'entreprise est bien dirigée », « on est bien outillés » etc. Et si l'on s'enquiert de la cause de cette réussite, on reçoit toujours la même réponse : « le DG (ou le directeur) s'est impliqué personnellement, il a mis le poids de son autorité dans la balance, il a réglé les problèmes politiques ».

Un SI n'est pas en effet seulement une affaire d'informatique : sa conception inclut la définition du travail humain, l'organisation du processus de production et de son contrôle.

C'est pourquoi il faut considérer que la responsabilité globale du SI appartient à la MOA, personne morale, et nommément à son directeur, personne physique qui engage la MOA par sa signature. Nos entreprises auront fait un grand pas lorsqu'elles sauront qu'un directeur ou un DG qui dit « c'est la faute de l'informatique » révèle une incompétence…

---

[1] Ingénierie et intégration des systèmes, Hermes, 1998.