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 pour préciser les besoins et supprimer toute ambiguïté avant de communiquer le modèle au maître d’œuvre chargé de la réalisation. 

Pour construire le modèle, on utilisera de préférence le langage UML ("Unified Modeling Language") qui permet de mettre en forme les concepts propres à la programmation objet (classes, composants, attributs, liens etc.). Ce langage permet de formaliser la description de la demande de l’utilisateur ; la première description sera réutilisée et précisée lors des étapes ultérieures de la modélisation, ce qui permet une démarche cohérente et cumulative, donc un gain en temps et en efficacité. 

La maîtrise du langage UML est une étape importante de la professionnalisation des maîtrises d’ouvrage. Alors qu'auparavant les expressions de besoins étaient souvent imprécises et versatiles, le maître d’œuvre va désormais disposer de descriptions établies selon une procédure qui garantit leur pérennité. UML devient alors le langage dans lequel le métier se structure et se décrit.

Il permet ainsi (ou plutôt il permettra, 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 on peut dire que le modèle écrit en UML transcrit la stratégie de l’entreprise, dont il donne une description assez précise pour guider la réalisation technique.

Convergence du modèle

Pour élaborer la première version du modèle, on constitue des équipes de deux personnes responsables chacune d'une partie du modèle (par exemple, de la partie relative à une activité) : un modélisateur, expert dans la manipulation de l’outil graphique et le langage UML, et un expert métier venu du terrain. Le modélisateur demande à l’expert métier les informations nécessaires pour préciser le modèle. 

L’expérience montre qu’au bout de quelques semaines de travail en commun à plein temps, l’expert métier utilise spontanément le langage UML (« classe », « lien », « attribut » etc.), ce qui prouve que ce langage n’est pas difficile à assimiler pour peu que l’on y consacre du temps.

Le "modèle métier"

A la fin du processus, la maîtrise d’ouvrage dispose d’un "modèle métier" qui peut être livré à la maîtrise d’œuvre. les deux parties du modèle (modèle formel et expression de besoins 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 et 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 ".

Le "modèle d'analyse"

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 d'analyse stabilisé, bien assimilé par les deux parties, et qui servira de fondement à la réalisation.

Suite de l’histoire

Il est important de voir la succession des démarches qui conduisent à la réalisation. Le vocabulaire comporte des synonymes, mais l'enchaînement est clair :

- 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 des besoins est définitivement finalisée lorsque ce modèle est établi, et elle est parfaitement cohérente avec le modèle formel (elle est donc beaucoup plus complète que la première expression de besoins qui a été établie au tout début de la démarche, avant que la décision de lancement du projet ne soit prise). 

- 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, et il tient compte notamment des contraintes propres à l'intégration de l'application sur la plate-forme informatique de l'entreprise. Il est interne à la réalisation et n’a pas en principe à être validé par le maître d’ouvrage.

Toute réalisation doit parcourir ces trois étapes. L'idéal serait qu'elle fût conduite de sorte que l’on n'ait jamais à mettre en cause les choix opérés lors des étapes précédentes ; parfois, cependant, une étape aval fait apparaître des contraintes qui conduisent à revenir sur un choix opéré dans un modèle amont et à le modifier, mais c'est toujours un épisode pénible et coûteux et il faut s'efforcer de l'éviter. 

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 partage des rôles doit être clair dans l’esprit de chacun. Il ne signifie pas qu’il existe une cloison étanche entre maîtrise d’ouvrage et maîtrise d’œuvre : 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 (voir "Conduite de projet"). 

Le cahier des charges

Le cahier des charges, c'est le modèle communiqué à l'entreprise chargée de la maîtrise d'œuvre de la réalisation ("réalisateur") ; il est annexé au contrat passé avec cette entreprise. 

En fait, un projet informatique a deux maîtrises d'œuvre : la direction informatique, qui après la livraison du produit sera chargée de son exploitation sur les machines de la plate-forme technique, d'une part ; le réalisateur, d'autre part. La direction informatique se trouve dans une sorte d'entre-deux, intermédiaire entre la maîtrise d'ouvrage pour qui le produit est réalisé, et le réalisateur. 

Dans un premier temps, lorsque le contrat avec le réalisateur n'est pas encore passé, l'informatique représente le pôle maîtrise d'œuvre ; lorsque le contrat a été passé, elle se range du côté de la maîtrise d'ouvrage qu'elle assiste en assurant les parties techniques du suivi de projet et de la recette, et en s'assurant que le produit est bien exploitable sur la plate-forme technique de l'entreprise. 

Le contrat peut être passé soit dès que le modèle métier est disponible, soit lorsque le modèle d'analyse est disponible. Dans le premier cas, le cahier des charges est composé du modèle métier, auquel l'informatique ajoute l'indication des contraintes techniques propres à sa plate-forme, et le réalisateur établit le modèle d'analyse, puis le modèle technique ; dans le second cas, le cahier des charges est composé du modèle d'analyse et de l'indication des contraintes techniques, et le réalisateur établit le modèle technique.

Dans tous les cas, le modèle technique doit être établi par le réalisateur, car il doit intégrer, outre les contraintes techniques de la plate-forme, les spécificités des outils (générateur de code, "middleware" etc.) que le réalisateur va utiliser. 

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 devenir douteuse, ce qui interdit la convergence du modèle métier.

- 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 rapide et superficielle et risque donc d'être remise en cause par la suite : un dirigeant ne pourra en effet jamais tolérer que l’application soit en contradiction avec la stratégie de l’entreprise (voir "Pour une validation authentique"). 

- on prend en compte les contraintes techniques de façon trop précoce. 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 devront ê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 même 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 faut 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.