Methode de Modélisation informatique avec UML (2ème partie)

Le modèle métier

La MOA est responsable du modèle métier, qui n’est rien d’autre qu’une expression de besoin précise et ne considère les contraintes techniques que de façon approximative.

Pascal Roques et Franck Vallée ont proposé un schéma en Y de la modélisation. La réalisation du modèle métier occupe la branche gauche ; la prise en compte des contraintes techniques occupe la branche droite ; la réalisation du modèle complet est la branche verticale.

Le modèle métier ne peut être que provisoire : il arrive que l’on doive le réviser pour tenir compte des contraintes techniques ou du coût que fait apparaître l’élaboration du modèle complet.
Le modèle métier est susceptible d’être modifié par la prise en compte des contraintes techniques. Est-il inutile pour autant ?

Supposer le modèle métier inutile, cela reviendrait à dire que l’informatique peut travailler à partir d’une expression de besoin sommaire, avec les ambiguïtés du langage naturel, et qu’il lui reviendrait de modéliser les processus des métiers et de déterminer leurs concepts structurants.

C’est ainsi que les choses se sont passées lorsque l’informatique équipait les grandes applications de support de l’entreprise (paie, comptabilité, gestion des stocks etc.) qui, tout en étant complexes, varient peu d’une entreprise à l’autre. Il ne peut en être de même lorsque l’informatique pénètre les processus de production, lorsqu’elle équipe le cœur de métier sur lequel l’entreprise possède des compétences spécifiques et « pointues ».

La modélisation du processus prendra d’ailleurs des formes diverses selon que celui-ci :
– met en œuvre un automate pur (cas du logiciel embarqué dans une machine),
– associe l’automate à des êtres humains pour mettre en oeuvre les procédures internes à l’entreprise (back-office),
– reçoit des messages provenant d’acteurs externes, et qu’il faut transcrire dans le système d’information de l’entreprise (cas de la première ligne face à des clients, fournisseurs, partenaires),
– traverse les frontières de l’entreprise pour pénétrer chez des partenaires, fournisseurs ou clients (interopérabilité).

En outre dans chaque cas il faudra tenir compte d’exigences spécifiques de synchronisme, qualité des données et homogénéité des codages.

Considérons par exemple les processus qui prennent leur source à la première ligne. La modélisation doit définir conjointement les tâches qui reviennent à l’être humain et celles qui reviennent à l’automate. Un des points délicats est alors de placer raisonnablement la frontière de l’automatisation : cela suppose une connaissance très fine des pratiques professionnelles.

La modélisation est par ailleurs pour un métier l’occasion d’une réflexion sur les procédures et d’une révision des processus. Elle permet de mettre à plat des habitudes qui se sont stratifiées dans l’histoire de l’entreprise et dont certaines ont perdu leur raison d’être, de détecter et corriger des défauts (bras mort où se perdent les dossiers, redondances, erreurs d’adressage etc.), de rétablir la qualité des référentiels qui se dégrade toujours au long de la vie de l’entreprise. Il arrive même que la modélisation incite l’entreprise à relancer la réflexion stratégique sur son positionnement, la diversification de son offre et la définition de ses partenariats.

Ainsi s’élabore la pertinence de l’expression de besoin, son adéquation aux besoins pratiques du métier. La mise en lumière des priorités du métier permet d’apporter au modèle la sobriété. La restauration de la qualité des référentiels garantit la cohérence du SI.

Ces qualités cruciales, observons-le, dépendent toutes trois de la maîtrise d’ouvrage. Elles sont conditions nécessaires de la qualité du SI – mais non conditions suffisantes : il faut encore que la faisabilité technique soit élaborée par la maîtrise d’œuvre, qui doit vérifier si l’automate pourra exécuter les opérations qui lui sont demandées et si l’interopérabilité avec les autres entreprises sera assurée.

Le modèle métier devra donc être révisé pour tenir compte des contraintes techniques et élaborer le modèle complet. Le plus souvent, les modifications n’excèdent pas 10 à 20 % de la documentation du modèle métier, qui n’est donc pas remis en question de fond en comble.

Il n’est donc pas inutile que la maîtrise d’ouvrage produise le modèle métier : d’une part cela l’incite à tirer au clair ses propres processus et priorités ; d’autre part, même si elle doit soumettre le modèle métier à une critique portant sur sa faisabilité technique, cette critique n’aboutit pas en général à la destruction d’une part importante du modèle.

Par la suite, le modèle métier devra s’adapter aux évolutions de l’entreprise. Il est utile de distinguer ici divers niveaux de stabilité. Les choix techniques ont le niveau de stabilité le plus bas, car ils doivent évoluer rapidement pour assurer le maintien de l’entreprise à l’état de l’art ; le découpage des domaines de légitimité de l’entreprise, que l’on nomme souvent « organisation », un peu plus stable que les choix techniques, est cependant évolutif. Le référentiel des données et des notions que le modèle manipule, étant pour l’essentiel indépendant des choix techniques comme de l’organisation, est la partie la plus stable du modèle et sera le socle sur lequel on peut le bâtir.

Modélisation et évaluation du coût

L’évaluation du coût du projet progresse à mesure que se précise la définition de celui-ci.

Considérons les étapes successives dans un cas type, sachant qu’il est susceptible de variantes selon la taille du projet, la maturité de la maîtrise d’ouvrage, la nature interne ou externe de la MOE etc. :

1) au début, l’expression de besoin n’est accompagnée d’aucune évaluation du coût ; on peut tout au plus lui associer une indication qualitative comme « petit projet », « projet moyen », « gros » ou « très gros ».

2) si l’expression de besoins passe le cap de la première sélection, une « étude préalable » est lancée. La maîtrise d’œuvre fournit alors, en s’appuyant sur son expérience et sur des « règles de pouce », une esquisse de solution et une première évaluation du coût. La marge d’erreur est de 50 % (si l’on estime le coût à 10 M€, le coût véritable se situera vraisemblablement dans une fourchette de 5 à 20 M€ : les deux bornes de la fourchette sont donc dans un rapport 4). Tout imprécise qu’elle soit, cette estimation sert à évaluer la rentabilité du projet (l’estimation des gains que l’on peut en attendre est d’ailleurs, à ce stade, tout aussi imprécise).

3) Si l’étude préalable est convaincante, l’entreprise lance la première modélisation, opération d’un coût significatif. La réalisation du modèle complet permet de resserrer la fourchette d’évaluation :
– le modèle métier permet de mieux évaluer les gains ainsi que le coût de la maîtrise d’ouvrage (formation, déploiement etc.) ;
– la prise en compte des contraintes techniques lors de la construction du modèle complet permettent de mieuax évaluer le coût de la réalisation.
Le modèle ainsi enrichi, comportant une évaluation plus précise des gains, des coûts et de la rentabilité ainsi qu’un ou deux scénarios d’architecture, constitue le cœur du cahier des charges de la réalisation.

4) Si l’entreprise décide de lancer le projet au vu du modèle complet, la MOE consulte des entreprises. Leurs réponses permettront de préciser encore le scénario d’architecture ainsi que l’évaluation du coût.

5) Il arrive enfin souvent que l’on soit contraint de réviser l’évaluation du coût lors de la réalisation : on ne connaîtra vraiment celui-ci qu’à la fin du projet.

L’évaluation du coût du projet est donc continue ; floue dans les premières étapes, elle gagne progressivement en précision. Il est bien sûr souhaitable d’utiliser des méthodes aussi rigoureuses que possible, un « modèle de coût » étalonné et condensant l’expérience des informaticiens. Cela ne supprime pas l’incertitude, mais cela peut la réduire et améliorer d’autant la qualité des décisions relatives au lancement des projets. Il est d’ailleurs salubre, lorsque les décisions sont prises sur la base d’une évaluation imprécise, que cette imprécision soit considérée comme l’un des risques associés au projet.

  Revenir à la première partie de l’article

Methode de Modélisation informatique avec UML (2ème partie)