5 mars 2004

1) Que signifie « modéliser » ?

Un « modèle » est la représentation mentale d’un être du monde réel et de son fonctionnement : quand on dispose d’un modèle, on peut simuler mentalement le comportement de cet être.

La modélisation, ce n’est donc rien d’autre que la pensée organisée en vue d’une finalité pratique. Modèle est synonyme de théorie, mais avec une connotation pratique : un modèle, c’est une théorie orientée vers l’action qu’elle doit servir.

Dans la vie courante, nous modélisons tous et tout le temps : à chacun des êtres qui nous entourent, qu’il s’agisse d’objets matériels, de personnes ou d’institutions, nous associons une image mentale qui nous permet d’anticiper son comportement. Nous faisons des simulations pour évaluer les conséquences de nos décisions et choisir parmi les décisions possibles, en tenant compte des incertitudes. Lorsque nos modèles nous semblent faux ou trop grossiers, nous les modifions.

Explicitons. Modéliser un être c’est définir :
- les concepts qui permettent de le décrire ;
- les relations fonctionnelles qu’entretiennent ces concepts.

Cette démarche, intuitive et rapide dans la vie personnelle, n’est explicitée que lorsque l’on réalise un travail professionnel ou scientifique. Alors le vocabulaire devient technique, « abstrait » et éloigné du langage courant. Cette technicité rend la modélisation (sous sa forme explicite) difficile à comprendre pour certaines personnes.

Le modèle en économie : Dans un modèle économique on définit les nomenclatures qui permettent de décrire les êtres que le modèle recouvre (segmentation des consommateurs, classification des produits et activités, rubriques comptables etc.), ainsi que les « lois » (éventuellement probabilistes) qui relient ces divers concepts (exemple : l’épargne est égale au revenu multiplié par le taux d’épargne, lui-même fonction d’autres variables). Parmi les variables, on distingue les exogènes qui décrivent le contexte et les endogènes produites par modèle. Une fois étalonné en calant les exogènes sur des données observées, on utilise le modèle pour simuler les conséquences endogènes d’hypothèses diverses sur les exogènes. Les économistes évaluent ainsi, par exemple, les conséquences d’hypothèses sur le prix du pétrole, la législation fiscale etc.

Dans le cas particulier d’une entreprise, modéliser l’entreprise revient à définir :
- les processus de production, en identifiant les événements déclencheur et final de chaque processus, en distinguant produit final et produits intermédiaires. Le plan de masse ainsi obtenu est « l’urbanisme » de l’entreprise ;
- le parcours de chaque processus, avec l’enchaînement des activités humaines et opérations informatiques qu’il comporte ainsi que les dossiers (ou « objets ») qu’il manipule (représentation des clients, produits, entités de l’organisation, salariés etc.) : c’est la « modélisation » proprement dite du processus ;
- le référentiel de l’entreprise : les attributs qu’elle associe à chaque objet, notamment leurs identifiants et les nomenclatures qui permettent de coder leurs attributs ;
- les « règles de gestion » dont la mise en œuvre propulse ces objets dans leur cycle de vie.

La modélisation implique donc que l’on se représente, définisse et documente les tâches effectuées dans l’entreprise, tant par l’être humain que par l’informatique. Pour éviter l’illimité du détail, cette démarche doit procéder du plus agrégé au plus détaillé et s’arrêter au niveau de détail jugé raisonnable[1].

2) Pourquoi modéliser ?

Certaines entreprises ne modélisent pas

Beaucoup d’entreprises ne modélisent pas. Elles croient inutile de savoir comment elles font ce qu’elles savent faire (de même, personne ne sait vraiment comment son corps respire ou digère : cela n’empêche pas de vivre).

Quand un salarié arrive dans une telle entreprise, il est mis au travail[2]. Il adhère alors à une organisation locale sans pouvoir prendre une vue d’ensemble. Il se forme par imitation des anciens : le savoir est « dans les murs » de l’entreprise, sans être explicité. Des choix structurants ont été faits dans le passé, par une petite équipe d’organisateurs, mais l’architecture qui en résulte est considérée par la suite comme un état de la nature.

Lorsqu’on présentera un modèle à ce salarié, il le jugera « abstrait » et déroutant car le modèle relativisera des conventions et règles d’organisation qu’il a pris l’habitude de considérer comme des absolus.

Certaines entreprises doivent impérativement modéliser

Cependant certaines entreprises doivent modéliser ; ce sont celles :
1) qui sont placées dans un contexte évolutif (concurrence, innovation technique, réglementation) et doivent donc être « agiles » ;
2) qui partagent avec d’autres entreprises la production d’un produit (partenariats) et doivent assurer l’« interopérabilité » de leurs processus.

Il est en effet indispensable d’avoir modélisé ses processus pour pouvoir les faire évoluer comme pour pouvoir les partager.

Or aujourd’hui la plupart des entreprises se trouvent ou se trouveront bientôt dans l’un ou l’autre de ces deux cas, ou dans les deux, car l’évolutivité et les partenariats sont une contrainte de l’économie actuelle. Alors qu’autrefois les entreprises pouvaient plus ou moins bien marcher en inculquant à leurs salariés des habitudes professionnelles, il importe maintenant qu’elles élucident leurs processus pour que leurs salariés puissent se les approprier[3].

Finalités de la modélisation

Tout modèle a deux finalités, l’une technique, l’autre intellectuelle :
1) finalité technique : fournir des spécifications claires pour produire, puis exploiter, l’application informatique qui outille chaque processus ;
2) finalité intellectuelle : fournir au métier une élucidation de ses objets, de ses concepts, de son référentiel, de ses processus.

L’application informatique équipe en effet le processus d’une « doublure informationnelle » dont la définition suppose, de la part du métier, un effort intellectuel. 

La trivialité du « business is business » incite à ignorer la finalité intellectuelle du modèle. Or cette finalité est essentielle : l’évolution de l’emploi vers le tertiaire, corrélative d’une organisation des compétences en spécialités, a introduit dans l’entreprise le risque d’un autisme professionnel qui la paralyse et que seul l’appropriation collective du modèle, référence et langage communs, permet de surmonter.

L’appropriation du modèle permet à chacun de concevoir clairement :
- le processus pour lequel il travaille et le produit que ce processus élabore ;
- son propre rôle dans le processus ainsi que les rôles des autres acteurs et les relations entre les divers rôles (notamment entre son propre rôle et ceux des autres) ;
- l’ensemble des processus de l’entreprise et leurs relations mutuelles.

3) Qui modélise ?

La modélisation est souvent faite par la maîtrise d’œuvre informatique (MOE). C’est malencontreux, car les priorités de la MOE résident dans le fonctionnement de la plate-forme informatique et non dans les processus de l’entreprise.

Il est préférable que la modélisation soit réalisée par la maîtrise d’ouvrage (MOA) de sorte que le métier soit maître de ses propres concepts. La MOE doit intervenir dans le modèle lorsque, après avoir défini les concepts du métier, on doit introduire les contraintes propres à la plate-forme informatique.

Il est vrai que les métiers, dont les priorités sont opérationnelles, ne disposent pas toujours de la capacité d’abstraction, de la rigueur conceptuelle nécessaires à la formalisation. La professionnalisation de la MOA a pour but de les doter de ces compétences.

Certains auteurs proposent une démarche en Y : la branche de gauche, qui fournit les spécifications fonctionnelles, est produite par la MOA ; la branche de droite, qui décrit les contraintes techniques, est produite par la MOE ; le modèle technique qui sera fourni au producteur du logiciel est établi par la MOE qui fusionne les résultats des deux branches[4]. Le « modèle métier », le « modèle d’analyse » et le « modèle technique » correspondent chacun à une des étapes de la modélisation. On doit pour chaque étape distinguer celui qui produit le modèle et celui qui le valide[5] :

4) Comment modéliser ?

Un modèle est un être idéal, décrit par un document (texte et graphique) qui le présente selon des « vues » destinées chacune à un interlocuteur particulier, et définies de telle sorte qu’il puisse s’approprier, en les visualisant, le dessin du processus et l’architecture des concepts.

L’élaboration du modèle doit procéder de telle sorte que l’ensemble de ces vues soit cohérent, et qu’elles se réfèrent donc toutes à un même être idéal (mais invisible[6]).

Langage de modélisation

Le langage UML (« Unified Modeling Language ») a défini des vues utiles (diagramme d’activité, cas d’utilisation, diagramme de classes etc.) ainsi que les commentaires qui doivent leur être associés. L’utilisation de ce langage s’impose même s’il est encore imparfait : il a l’avantage d’être un standard (ce qui évite la cacophonie). En outre les logiciels de modélisation[7] sont conçus de telle sorte que la cohérence soit garantie. Il importe que la MOA se forme à UML, et l’utilise pour communiquer avec la MOE.

Du langage à la méthode

Cependant UML, pur langage, n’est pas une méthode : la documentation d’UML ne décrit pas dans quel ordre la modélisation doit procéder.

En fait il serait dangereux de modéliser selon une succession de phases qui s’enchaîneraient du début à la fin : lorsque l’on produit les spécifications fonctionnelles d’un grand modèle, on risque de perdre le sens du terrain. Il faut savoir s’arrêter à certains niveaux d’analyse pour faire une étude d’implémentation avant de reprendre la progression. On travaillera alors non selon une succession de phases, mais selon une boucle que l’on parcourt plusieurs fois en progressant d’un parcours à l’autre.

Toute entreprise, tout projet constitue d’ailleurs un cas particulier : la méthode doit fournir des points de repère qui permettront d’orienter la réalisation. Elle s’appuiera sur les éléments les plus stables du cycle de développement, seuls susceptibles de servir de points de repère.

Mieux vaut par exemple définir ce qu’est un bon dossier de spécifications que dire comment faire ce dossier : plus on entre dans le détail de la prescription, plus celle-ci risque d’être instable. Une fois défini le produit à livrer, il revient à l’entreprise de s’organiser pour le produire à sa façon.

Quand on modélise un processus logiciel, on fournit des produits types qui sont des éléments stables du cycle :

-         produits de développement, dont les « livrables » sont un cas particulier ;

-         outils de « guidance » : par exemple plan type d’une spécification bien faite ;

-         organisation et définition des rôles dans un processus de développement ;

-         définition du cycle de vie, des phases, des activités.

Il est notoirement difficile de lire, valider ou corriger un modèle formellement explicite. Le modèle risque de n’être qu’un dépôt pour la mémoire, et non une étape d’un travail coopératif. C’est pourquoi il ne faut pas se contenter du formalisme : la production du modèle formel doit être accompagnée de la fourniture de produits intermédiaires qui sont comme l’échafaudage nécessaire à la construction d’un bâtiment, et qui ont pour but de garantir la pertinence des spécifications comme l’authenticité des validations.

Il existe autour de la modélisation des outils annexes, le plus souvent Open Source, utiles mais non prévus dans la norme : documentation des Use Cases ; expression de besoin ; production du cahier de tests ; validation ; appropriation etc. Il faut que le modélisateur puisse choisir parmi ces outils un ensemble commode et, si possible, compatible.

Quelles sont les vues sur le SI que le modèle doit représenter ?

En revenant aux deux finalités du modèle évoquées ci-dessus (technique, intellectuelle), on conçoit que les vues devront être très différentes :

1) Le modèle doit faciliter le travail des techniciens qui produisent ou exploitent le logiciel : certaines vues (diagramme de classe, diagramme d’état etc.) permettront d’alimenter des logiciels qui produisent automatiquement une partie des lignes de code dans le langage choisi (C++, Java etc.). D’autres vues documenteront la tâche d’exploitation du programme.

2) Le modèle complet doit être présenté aux responsables hiérarchiques pour validation ultime avant la réalisation proprement dite : cette validation constitue le bouclage du processus de modélisation. Elle s’appuie sur un rappel de l’expression de besoins et  sur une présentation du modèle en langage naturel, illustrée par le diagramme d’activité, complétée par une description explicite des choix fonctionnels, des fonctionnalités auxquelles on a dû renoncer (soit pour des raisons techniques, soit pour des raisons de coût), des problèmes que risque de comporter la mise en œuvre du processus etc.

Il faut prévoir plusieurs niveaux de validation : par le niveau n du directeur métier, maître d’ouvrage stratégique ; par le niveau n – 1 des chefs de service ; par le niveau n – 2 des maîtres d’ouvrage opérationnels, spécialistes du processus. Les documents à préparer pour ces validations sont synthétiques pour le niveau n, plus détaillés pour le niveau n – 1, plus détaillés encore pour le niveau n – 2 ; dans tous les cas il s’agit de textes en langage naturel, illustrés par un choix sélectif de graphiques.

3) Il est souvent nécessaire que les salariés aient sur le SI une vue d’ensemble leur permettant de situer leur propre activité : l’entreprise doit faire en sorte que le SI soit approprié par ces personnes. On peut par exemple mettre à leur disposition, sur l’Intranet de l’entreprise, une représentation graphique des processus. Cela leur permettra d’accéder à une connaissance intuitive de l’entreprise semblable à celle qui se trouve dans la tête des modélisateurs.