Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Gratuit ! • 60 modèles de livrables prêts à l’emploi • un outil de création de

Gratuit ! • 60 modèles de livrables prêts à l’emploi • un outil de création de business plan Y V E S C O N S T A N T I N I D I S P r é f a c e d e M i c h e l V o l l e Guide d’élaboration du cahier des charges Expression des besoins pour le système d’information V Préface D’après le Standish Group, les projets informatiques connaissent un taux d’échec qui ne saurait être toléré dans aucun autre domaine de l’ingénie- rie : 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 infor- matique 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 pro- babilité 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 industriels1. Invité à participer à un projet de sys- tè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 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 de responsabilité, 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 pro- jets. 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, en revanche, sont précisément ceux que sert un SI. 1. Jean-Pierre Mei- nadier, Ingénierie et intégration des systèmes, Hermes, 1998. Expression des besoins pour le système d’information VI 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éo- logie, 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éli- minaire 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, stra- tè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 uti- lisateurs (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 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, une mise en forme qui concrétise l’expression de besoin en schématisant le métier tel qu’il fonc- tionnera 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 à perce- voir la finalité du système et l’étendue de sa responsabilité personnelle, Préface VII 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écifica- tions 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 vali- dé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 dia- gramme 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 cer- tains stratèges prennent cela comme une atteinte à 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 uploads/Management/ syst-me-d-information-1652611254.pdf