8 novembre 1999

Exposé au club des maîtres d’ouvrage des systèmes d’information

 Lorsque l’on parle des " utilisateurs " du système d’information, il faut distinguer deux catégories de personnes :

- les utilisateurs " de terrain ", ceux qui en pratique feront fonctionner le système et s’en serviront pour leur travail quotidien ;

- les " concepteurs ", généralement affectés à la direction générale et chargés de concevoir les nouvelles applications en fonction des orientations stratégiques des métiers de l’entreprise.

Les concepteurs ne sont pas des utilisateurs finals, mais ils sont chargés de transcrire les besoins de l’entreprise en termes de fonctionnalités à fournir par l’application.

Les relations entre maîtrise d’ouvrage et utilisateurs comportent des étapes que l'on peut énumérer dans l’ordre chronologique :

• l’expression des besoins,
• la recette fonctionnelle, qui permet aux utilisateurs de vérifier si l’application correspond bien à leur demande,
• la formation des utilisateurs " de terrain ",
• le déploiement,
• la conduite du changement,
• l’aide aux utilisateurs,
• l’exploitation technique de proximité.

Nous considérerons dans cette fiche uniquement la première de ces étapes, l’expression de besoins.

Étapes de l’expression des besoins

L’expression de besoins se fait en plusieurs étapes :

- une première expression, dite " informelle " (mais qui doit néanmoins être rigoureuse) permet de comprendre de quoi il s’agit . Exprimée en langage courant, elle est compréhensible à la lecture par tout le monde y compris les dirigeants. Ils doivent la valider de telle sorte que l’on soit sûr qu’elle correspond aux priorités et à la stratégie de l’entreprise. Sans cette validation, on courrait le risque d’un désaveu après des mois de travail dans une direction erronée.

- on établit ensuite une expression dite " formalisée " en utilisant un langage que nous allons décrire ci-dessous. La formalisation peut faire apparaître certaines lacunes de l’expression informelle : il faut itérer jusqu’à ce que l’on dispose d’une expression informelle et d’une expression formelle cohérentes.

- jusqu’ici le travail a été fait par la maîtrise d’ouvrage, responsable de l’expression des besoins. Une fois établie, l’expression de besoins est communiquée à la maîtrise d’œuvre ; il faut alors s’assurer que celle-ci la comprend bien. Un échange de questions et réponses conduit à l’expression des besoins définitive, dûment comprise et validée par la maîtrise d’œuvre.

Nous allons reprendre l’une après l’autre ces diverses étapes.

Première expression des besoins

Pour rédiger l’expression de besoins, il est utile de consulter des personnes du terrain et les concepteurs. Les informations qu’apportent ces deux catégories d’utilisateurs ne sont pas les mêmes : les personnes du terrain indiquent dans le détail comment les choses se passent, ce qui permet d’éviter des erreurs de conception pratique. Les concepteurs indiquent comment les choses devraient se passer, ou comment elles devront évoluer, ce qui permet d’éviter des erreurs stratégiques (c’est-à-dire des erreurs concernant le positionnement et les orientations de l’entreprise).

La consultation des experts, les entretiens, les séances de validation, la rédaction et la vérification des comptes rendus représentent une tâche matérielle considérable. La logistique des recueils d’expertise, consultations et validations, est le talon d’Achille de la maîtrise d’ouvrage : l’expression des besoins peut échouer, en qualité ou en délai, si cette logistique n’est pas bien organisée. On pense trop souvent que cela va marcher tout seul, c’est une grave erreur. Il ne faut pas sous estimer les effort nécessaires pour obtenir que des personnes compétentes se rendent disponibles, pour s’assurer de leur ponctualité et de leur assiduité aux réunions ; les comptes rendus, portant sur des questions précises et parfois délicates, sont difficiles à rédiger de façon claire et synthétique.

On mobilise parfois des " clubs d’utilisateurs " pour l’expression des besoins. L’expérience incite à se méfier de cette formule, même si elle a une allure sympathique et démocratique. En rassemblant des utilisateurs, on les pousse en effet à exprimer une demande inflationniste, chacun demandant ce que d’autres n’ont pas encore pensé à demander. Il peut arriver aussi que certains informaticiens manipulent les clubs d’utilisateurs pour faire passer leurs propres préférences : les utilisateurs demandant " tout et le reste ", l’informaticien peut choisir ce qu’il a envie de faire. Pour amener un club d’utilisateur à travailler raisonnablement, la règle d’or est de lui demander ses priorités, d’indiquer ce qui lui paraît indispensable. On ne retiendra, pour faire la " version 1 ", que cet indispensable… et bien souvent il ne sera pas nécessaire d’aller plus loin.

Validation du besoin par les responsables

Nous appelons " dirigeant responsable " (ou " dirigeant " pour faire court) la ou les personnes qui dirigent le métier utilisateur de l’application, et que l’on appelle aussi " maîtrise d’ouvrage stratégique " (à ne pas confondre avec la " maîtrise d’ouvrage transverse ", qui coordonne les maîtrises d’ouvrage des divers métiers de l’entreprise. La " maîtrise d’ouvrage stratégique ", c’est la ou les personnes qui, au sein d’un métier, portent la responsabilité des orientations stratégiques de celui-ci.)

Il n’est pas facile d’obtenir des dirigeants responsables une validation authentique, c’est-à-dire faite en connaissance de cause. Si on leur donne un épais classeur rempli de documents techniques, ils ne feront que le survoler sans aller au fond des choses ; ils valideront de confiance, quitte à découvrir par la suite que les décisions prises ne correspondaient pas aux priorités stratégiques.

Il importe donc de présenter aux dirigeants des documents sur lesquels ils puissent exercer leur jugement de telle sorte que leur validation ne soit pas remise en cause plus tard. Chacun doit ici pouvoir faire son travail clairement et pleinement : au politique de fixer les orientations, au métier de dire comment il s’y prendra, au technique de déterminer les moyens. Pour que la validation " politique " soit bonne, il faut que les techniciens (métier et informatique) fassent un effort de clarté, de simplicité et de pédagogie. Ils doivent mettre en évidence les implications politiques des choix techniques, proposer des choix alternatifs.

Les textes présentés aux dirigeants doivent être rédigés en français et illustrés par des graphiques simples ; les compléments techniques éventuels sont à mettre dans des annexes qu’ils consulteront s’ils éprouvent le besoin d’aller au détail, mais sur lesquelles il ne leur est pas demandé d’apposer leur signature.

Formalisation du besoin

Une fois l’expression de besoin en langage naturel rédigée et validée, il faut la modéliser de façon formelle. On dispose maintenant avec UML (Unified modeling language) d’un langage de modélisation bien adapté. Il permet de préciser les besoins en supprimant toute ambiguïté pour le maître d’œuvre chargé de la réalisation. Ce langage utilise les concepts propres à l’orienté objet (classes, composants, attributs, liens etc.) ; proche de l’utilisateur, dont il formalise la demande, il fournit à la réalisation la base conceptuelle qui sera réutilisée et précisée lors des étapes ultérieures, ce qui permet un gain en temps et en efficacité.

La maîtrise du langage de modélisation UML (ou de tout autre langage futur analogue ; pour le moment, c’est UML qui s’impose) sera une étape importante de la professionnalisation des maîtrises d’ouvrage. Auparavant les expressions de besoins étaient souvent imprécises et versatiles. Le maître d’œuvre va désormais disposer de descriptions complètes établies selon une procédure qui garantit leur pérennité. Le modèle devient le langage dans lequel le métier structure et décrit ses fondations conceptuelles.

Il sert aussi (ou plutôt il servira, car nous sommes ici en avance par rapport à la pratique des entreprises) à mettre en forme les choix stratégiques et à les expliciter. Dès lors le modèle est la transcription de la stratégie de l’entreprise, dont il donne une description précise propre à guider la réalisation technique qui lui fait suite.

Modèle UML

Un modèle UML se compose de plusieurs documents en langage courant et d’un document formalisé : il ne se limite en aucun cas au seul document formalisé car celui-ci est pratiquement incompréhensible si on le présente seul - sauf peut-être pour un expert en UML, mais ces experts sont rares.

Le premier document est la présentation stratégique, expliquant pourquoi l’entreprise a voulu se doter de l’outil considéré, les buts qu’elle cherche à atteindre, le calendrier de réalisation qu’elle a prévu, etc.

Le second document est une présentation des processus de travail par lesquels la stratégie entend se réaliser. Pour permettre au lecteur de voir comment l’application va fonctionner en pratique, il doit être illustré par une présentation des écrans qui seront affichés devant les utilisateurs de terrain.

Le troisième document est une explication des choix et des méthodes utilisées pour la modélisation formelle : il s’agit de synthétiser, sous les yeux du lecteur, les discussions qui ont présidé à ces choix.

Le quatrième document est le modèle formel lui-même. Il comporte essentiellement des diagrammes équipés de liens hypertextes permettant l’ouverture de contenus textuel. On doit présenter en premier le " diagramme d’activité " qui montre l’enchaînement des " use cases " au sein du processus, car cet enchaînement est immédiatement compréhensible ; puis le " diagramme de séquence ", qui montre l’enchaînement des opérations à l’intérieur d’un " use case ". Enfin, le diagramme de classes, qui est le plus précis conceptuellement mais aussi le plus difficile à lire : il montre les relations entre composants et classes, et les relations d’héritage et d’association qui relient celles-ci.

Convergence du modèle

A la fin du processus, la maîtrise d’ouvrage dispose d’un modèle livrable à la maîtrise d’œuvre, et ses deux parties (formelle et en langage naturel) sont dûment cohérentes. Avant la livraison du modèle à la maîtrise d’œuvre, les documents en langage naturel doivent être validés par les dirigeants.

Cette élaboration demande une gestion documentaire attentive : il importe que les diverses versions des textes soient numérotées, leur cohérence garantie, de sorte que le destinataire n’ait pas à vérifier la cohérence de ce qui lui est livré.

Le livrable fourni par la maîtrise d’ouvrage à la maîtrise d’œuvre s’appelle " modèle métier ", " modèle fonctionnel " ou encore " spécifications générales " ; ces divers termes sont synonymes, et nous utiliserons ici l’expression " modèle métier ".

Lorsque le modèle métier est fourni au maître d’œuvre, celui-ci doit se l’approprier et s’assurer qu’il l’a bien compris. Il peut ainsi relever des points obscurs. On entre donc dans un cycle de remarques du maître d’œuvre adressées au maître d’ouvrage, auxquelles celui-ci répond en précisant et adaptant le modèle.

A la fin de ce cycle, on dispose d’un modèle métier stabilisé, bien compris par les deux parties, et qui servira de fondement à la réalisation.

Suite de l’histoire

Il est important de voir la chaîne des démarches qui conduisent ensuite à la réalisation. Le vocabulaire comporte des synonymes, mais la démarche est claire :

- le " modèle métier " (ou " spécifications générales ") est celui qui est livré par la maîtrise d’ouvrage à la maîtrise d’œuvre. C’est le " modèle métier stabilisé " décrit ci-dessus. L’expression de besoins, objet de la présente fiche, se termine lorsqu’il est établi.

- le " modèle d’analyse " (ou " spécifications détaillées ") est ensuite rédigé par le maître d’œuvre, puis validé par le maître d’ouvrage. Il a pour but d’apporter au modèle métier des précisions techniques (cardinalité des liens, définition des classes etc.) en vue d’une réalisation efficace. Il doit être validé par la maîtrise d’ouvrage et devient ensuite le modèle sur lequel fournisseur et client se seront mis d’accord, et qui servira de charte à la réalisation.

- le " modèle technique " (ou " spécifications techniques ") est le document qui sera fourni aux développeurs pour la réalisation. Il précise les choix techniques. Il est interne à la réalisation et n’a pas en principe à être validé par le maître d’ouvrage.

Pour comprendre cette succession, prenons une métaphore inspirée de la vie courante. Supposons que vous fassiez construire une maison. Vous avez le plan sous les yeux, et vous dites : " dans cette chambre, il faudra quatre prises de courant, un interrupteur commandant une prise, et une applique commandée par un interrupteur ". Ce sont vos spécifications générales.

L’électricien vous demande de dire où il faut installer les prises, les interrupteurs et l’applique. Marquer sur le plan ces emplacements précis, c’est établir les spécifications détaillées.

Puis l’électricien fera le plan de câblage : il déterminera le parcours des goulottes et saignées. Ce sont les spécifications techniques, qui n’intéressent pas le client (mais l’électricien vous demandera toutefois peut-être de donner votre accord avec l’emplacement de l’armoire de raccordement où se trouveront les disjoncteurs).

Toute réalisation doit parcourir ces trois étapes, et être conduite de sorte que l’on n'ait jamais à mettre en cause les choix opérés lors des étapes précédentes.

La maîtrise d’ouvrage est responsable à la fois de la production et de la validation du modèle métier ; pour le modèle d’analyse, la responsabilité est partagée : production par la maîtrise d’œuvre, validation par la maîtrise d’ouvrage. Enfin, la maîtrise d’œuvre est responsable à la fois de la production et de la validation du modèle technique.

Ce découpage des rôles doit être très clair dans l’esprit de chacun. Précisons toutefois qu’il ne signifie pas qu’il existe une cloison étanche entre maîtrise d’ouvrage et maîtrise d’œuvre : au contraire, les flux d’information et les consultations doivent être réguliers tout au long de la démarche.

A la fin du processus ci-dessus, quand le modèle technique est élaboré, on entre dans la phase de réalisation (développement), qui sera suivie du déploiement, de la formation des utilisateurs, etc. Ceci est une autre histoire ; elle est importante mais sort des limites de cette fiche.

Quelques pièges

Signalons les pièges dans lesquels on tombe parfois :

- on sous-estime souvent la difficulté de la logistique de consultation et de validation auprès des experts du métier : les rendez-vous sont difficiles à obtenir, les personnes ne sont pas assidues, ou bien elles ne se sentent pas autorisées à donner un avis parce que leur mandat n’est pas clair, ou bien elles sont désavouées après l’avoir donné, etc. Les délais peuvent s’allonger démesurément, la qualité de l’expression des besoins peut être douteuse.

- on présente aux dirigeants des documents d’une lourde technicité qui ne correspondent ni à leur langage, ni à leurs préoccupations. Dès lors la validation prend beaucoup de temps, ou bien au contraire elle est trop rapide et superficielle et sera remise en cause par la suite : un dirigeant ne pourra en effet jamais tolérer que l’application ne soit pas conforme à la stratégie de l’entreprise.

- on prend en compte les contraintes techniques de façon trop précoce. Nous avons vu la succession modèle métier - modèle d’analyse - modèle technique. Lorsque l’on fait le modèle métier, l’objectif est de donner une bonne expression de besoin, non d’optimiser les solutions techniques qui doivent être examinées ensuite. Il peut arriver que sous prétexte de " sérieux ", de " rigueur " ou encore de " méthodologie ", l’informatique veuille imposer au métier des règles de modélisation anticipant sur les choix à réaliser dans le modèle d’analyse ou le modèle technique. Des choix techniques précoces devront alors être révisés par le maître d’œuvre, d’où travail en double et perte de temps.

- cloison étanche entre maîtrise d’ouvrage et maîtrise d’œuvre : même si la maîtrise d’œuvre n’est pas responsable du modèle métier, il est utile que le maître d’ouvrage la consulte pour s’assurer de la faisabilité de ce qu’il envisage ; par ailleurs, même si le modèle technique ne concerne pas le maître d’ouvrage, il est utile qu’il soit informé de choix qui ont pour lui des conséquences directes (en termes de performances, fiabilité etc.). La spécialisation des rôles ne doit pas exclure la collaboration.