lundi 16 août 2010

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.

10 commentaires:

  1. Bonjour Mr Volle,

    vous touchez là un point d'une sensibilité gigantesque, à tel point que je n'arrive toujours pas à comprendre pourquoi les entreprises entretiennent un tel obscurantisme. Les modèles de gestion d'entreprise sont-ils en cause ? La "sagesse des anciens" serait-elle prise en défaut ? J'en doute. Peut-être une éducation d'entreprise sclérosée et frileuse accompagnée d'un égocentrisme grandissant de la société actuelle. Qui sait.

    Le MOAD, que j'appelle moi "le chef d'Orchestre" (je ne suis pas fan des acronymes et la langue française est tellement riche), est souvent manquant dans les entreprises. Comme le chef d'un orchestre, cette personne, pas nécessairement spécialiste, mesure, retransmet, fait comprendre d'harmonie et les couacs de l'entreprise dans son fonctionnement optimal. Et dans son évolution future, elle image les travaux à entreprendre et les résultats, non pas poste à poste mais dans son ensemble et la nouvelle harmonie qui s'en dégagera.

    Dans votre métaphore, je ne dirais pas qu'il souhaite 4 prises dans la pièce de la maison mais qu'il souhaite y brancher tant d'appareils et pourquoi. Qu'il faille ensuite 4 prises ou plus n'est pas trop son affaire je pense.

    Depuis le 1er janvier 2009, je suis directeur de l'association Espace Numérique de l'Isère (www.espace-numérique-isere.fr) parceque son but rejoignait le mien à savoir non pas comment informatiser une entreprise mais plutôt pourquoi, dans quel sens, par quel bout et pour quelle valeur ajoutée.
    Pour reprendre une métaphore, nous nous adressons aux entrepreneurs et aux décideurs (entreprises, tpe, pme, artisans, commerçants, agriculteurs, collectivités, etc...) et le but est de leur permettre d'acquérir des outils informatiques aussi bien qu'une voiture. Ils ne savent pas forcément démonter et remonter une voiture mais in savent pertinemment à quoi elle va leur servir et permettre de gagner. Quand nous avons regarder autour de nous dans le département l'état de l'offre, nous avons trouvé une multitude d'offres du "comment faire" mais aucune sur le "pourquoi faire".
    Surprenant, inquiétant et révélateur.

    Cordialement.

    Philippe.

    RépondreSupprimer
  2. La remarque de philippe est interessante concernant la métaphore :
    - La MOA doit-elle dire combien de prise elle veut ou combien d'appareil elle veut brancher?

    - En fonction de mon expérience dans le 2ème cas si l'on demande à la DRH un besoin trop précis elle peut paniquer en disant qu'elle ne peut pas le dire à l'avance.

    - Je dirais qu'elle doit dire combien de prise et qu'elle doit préciser en détail si il y a un four à cet endroit précisément car dans ce cas il faut des prises spéciales.

    RépondreSupprimer
  3. Bonjour M. Volle et à tous les lecteurs de ce blog,
    Votre image de nombre de prise et de placement est très bonne je l’utilise moi-même. Mais pour dire une chose complètement différente ou complémentaire, je ne sais pas. Dans la pratique, c’est dans la pièce construite que l’on est mieux à même de juger de la pertinence du nombre et de l’emplacement des prises de courant. Il y a une rétroaction entre l’objet du projet et les besoins. Ce n’est pas moi que le dit c’est Gaston Bachelard dans Le Nouvel Esprit scientifique (1934) : « la méditation de l'objet par le sujet prend toujours la forme du projet » . Cette méditation est un processus récursif, c’est à mon sens ce caractère qui est complètement ignoré de la MOAD, il est tellement facile de concevoir un cahier de rêves, plutôt qu’un cahier des charges. L’ingénierie des besoins dans l’industrie, autre que logicielle, s’appuie sur l’analyse fonctionnelle, une véritable classification des besoins (la recherche des buts, des fins puis de moyens), une analyse de la valeur, une AMDEC, etc … Puis d’une rétroaction très importante avec la MOE au moment de l’appel d’offres qui aboutit à un enrichissement du cahier des charges. Quels sont les outils de la MOAD pour les projets SI? Sur le terrain il y a prévalence des outils de conception purement technique.
    En conclusion je pense maintenant que les liens entre une MOAD déficiente et une MOE bien peu efficace font un système pervers ou chacun tire un avantage. La MOAD stratosphérique peut critiquer à loisir la MOE, la MOE elle maximise sont chiffre d’affaires. J’ai un exemple très précis de ce type de comportement dans une grande administration. Le fait pour la MOAD d’accompagner sur tous le long du projet le processus de conception et de réalisation est inacceptable du point de vue des acteurs. Mais un espoir existe avec les méthodes itératives (SCRUM et autres) …
    Bon courage à tous dans vos projets,
    Encore merci pour ce blog si rafraichissant.
    Marc Divet.

    RépondreSupprimer
  4. Bonjour à tous,

    Au cours de mes pérégrinations du net j'ai découvert cette discussion forte intéressante. La préface qui entame la discussion pose relativement bien le contexte d'un « système à faire » avec l'ensemble des parties prenantes. Pour ma part je préfère « l'assistance à maîtrise d'ouvrage » à la « maîtrise d'ouvrage déléguée » car si la première désigne bien l'acteur qui par son activité va aider les parties prenantes à réaliser leur système à faire,...la deuxième a plus une connotation de procuration donnée par une partie des parties prenantes,...et cela me gêne, car l'AMOA( ou MOAD) s'insère dans le bocal alors qu'il doit s'en extraire pour prendre le recul nécessaire à tout projet. Je m'explique,...
    Pour moi, l'acteur qui doit être l'interlocuteur privilégié des donneurs d'ordres et des MOE métiers et informatiques, doit être découplé fonctionnellement et hiérarchiquement (càd sans délégation de quiconque), il doit être au dessus des parties prenantes. Cet acteur doit avoir une vue globale du « système à faire » pour mieux mettre en place le « système pour faire » (projet, outil, méthodes). Cet acteur, doit être un ingénieur système (architecte de SI par ex.), qui par son expérience métier et ses qualités humaines, va être le liant entre les parties prenantes pour mieux formaliser la finalité du système à faire, ses missions dérivées et ses différents points de vu techniques. Ces points de vu doivent être formalisés au travers d'un framework (Zachman, TOGAF, ou autre) et en respectant des standards de formalisation (UML, SysML, BPMN, …)
    C'est cette ingénierie basée sur les modèles (et non pas dirigée par les modèles) qui est à la base de tous « systèmes à faire », Elle doit garantir la cohérence entre des modèles (formalisation normée) métier différents.

    Bien à vous
    JP Auzelle

    RépondreSupprimer
  5. Bonjour

    Problème fréquent avec les MOAD, ce sont souvent (en tout cas dans les PME) des informaticiens à qui les responsables métiers délèguent s'estimant eux mêmes incompétents. Ce sont donc des spécialistes du câblage que vous avez comme interlocuteur en tant que prestataire en câblage.

    Le MOAD présente ainsi tous les inconvénients : il est dépourvu d'expertise fonctionnelle, il n'a pas de pouvoir de décision, et il s'appuie sur une expertise technique qu'on ne lui demande pas d'avoir puisque vous êtes là pas ça.

    La plupart des MOAD sont des goulets d'étranglement qui ralentissent les projets cependant que le rôle d'interface obligée filtre et déforme en permanence ce qui devrait être le souci exclusif dès lors que les objectifs stratégiques du projet sont définis à savoir la réalité vécue et le besoin de l'utilisateur.

    Quel rôle alors pour la MOAD ? de l'interface, de l'explication, de la gestion relationnelle.

    Pourquoi la MOAD est souvent si mauvaise ? c'est qu'il faut être très sûr de soi et ne pas avoir de problème d'égo pour assumer un rôle dont tout l'art tient à la capacité de s'effacer.

    ERGOL

    RépondreSupprimer
  6. @ERGOL
    Quelqu'un qui a une formation d'informaticien peut faire un excellent MOAD mais il faut que son poste soit inséré dans l'organigramme du métier (si le MOAD dépend hiérarchiquement de la DSI, il est écartelé entre deux loyautés), et aussi qu'il possède les qualités que vous évoquez.
    Tant que les entreprises ne l'auront pas compris, elles ne sauront ni recruter ni former convenablement les MOAD et elles rencontreront les problèmes que vous évoquez.

    RépondreSupprimer
  7. Bonjour.

    J'arrive un peu tard dans cette discussion.

    Je suis un professionnel des projets informatiques d'entreprise, et mon expérience est qu'il est peu utile de demander à la maîtrise d'ouvrage combien de prises électriques elle veut.

    En effet, on a la plupart du temps les réponses suivantes :

    - "le même nombre qu'actuellement" (on reporte les contraintes et arbitrages antérieurs, parfois très anciens, sur le nouveau schéma) ;
    - "10" (pensée de la MOA : si j'en demande 10, j'en aurai 5 après arbitrage, de toutes façons il vaut mieux en avoir trop que pas assez, même si cela conduit à une inflation des coûts du projet) ;
    - "je ne sais pas quels seront mes besoins dans 3 ans, le business évolue si vite !" (et de toutes façon, j'ai des problèmes plus urgents à traiter que de répondre à ces questions sans intérêt) ;
    - "il faut monter des groupes de travail représentatifs de toutes les tendances de l'entreprise pour répondre à cette question peu consensuelle" (courage, fuyons !).

    J'ai donc tendance à prévoir le nombre de prises correspondant au standard de l'industrie pour ce type de pièces et à faire valider globalement le design (nombre de prises, surface, couleur des murs, etc.) à la MOA.

    Je sais, c'est une vue un peu cynique, mais souvent le client est reconnaissant qu'on lui enlève cette épine du pied.

    RépondreSupprimer
    Réponses
    1. Pour le coup effectivement, il ne semble pas que ce soit à la MOA d'indiquer combien et où sont les prises. C'est l'expertise technique de la MOE qui doit établir en fonction des besoins de la MOA (j'ai x machines de telles dimensions, telles puissances à installer disposées de telles manières). La MOA doit exprimer des besoins (Une expression de besoin bien faite garantit le succès).
      Après elle peut-DOIT se faire aider pour rédiger ou décoder les spécifications détaillées de la MOE (interne ou externe). La AMOA(D) est vraiment le lien entre les deux avec une double expertise, voir une triple ... dans l'art divinatoire :>).

      Supprimer
  8. Bonjour M. Volle,

    Je serais très heureux de voir s'ouvrir sur votre blogue un débat circonstancié sur la débâcle du projet LOUVOIS (logiciel de paie des soldes militaires).

    Sylycate, auteur/rédacteur technique.

    RépondreSupprimer
    Réponses
    1. J'ai bien l'intention d'ouvrir ce débat ! Mais il faut d'abord que je prenne le temps de me documenter.

      Supprimer