Modélisation et système d'information

20 décembre 2002

On peut résumer les diverses étapes de la conception d'un système d'information par le mot "modélisation" : l'essentiel du contenu d'un SI réside dans les abstractions qu'il a fallu construire pour représenter, au sein d'un outil informatique de dimension finie, la diversité des êtres du monde réel (clients, produits, fournisseurs, partenaires, organisation interne, salariés etc.) avec lesquels l'entreprise entretient des relations. Le support fourni par la technique informatique (mémoires, processeurs, réseaux) confère à ces abstractions une sorte de réalité physique (les "données" peuvent être saisies, traitées, consultées, elles occupent un volume en mémoire, elles ont un nom et une adresse, leur transport suscite du débit dans les réseaux), mais la fonction essentielle du système d'information réside dans la sémantique, dans l'articulation de l'abstraction et de l'action, du contenant et du contenu, du concept et de sa représentation, de l'être humain et de l'automate. 

Obstacles à la modélisation

Cette articulation ne va pas de soi et elle rencontre de sévères obstacles. D'abord un obstacle sociologique : tout système d'information suppose une mise en ordre de l'organisation, une délimitation claire des frontières entre les institutions qui se partagent le pouvoir de décision légitime. Cette clarification n'est pas la bienvenue dans des entreprises, des administrations où la paix entre les dirigeants est maintenue par des compromis boiteux et des non-dits : en révélant que tel territoire relève diverses sphères de légitimité, la clarification risque de réveiller d'anciens conflits, risque auprès duquel l'enjeu du système d'information paraîtra souvent secondaire (voir "Le compromis managérial"). 

Puis un obstacle intellectuel : il n'est pas facile de définir les concepts pertinents, le vocabulaire adéquat à l'action. Cela implique le sacrifice de certains aspects du réel, mais lesquels ? cela suppose que l'on renonce à aller plus loin qu'un certain degré de détail, mais comment définir le "grain de photo" auquel il convient de s'arrêter (voir "Comment concevoir un référentiel") ? Outre ces questions de définitions, se posent aussi des questions pratiques : si tout est simple en principe dans le domaine conceptuel, en fait tout devient très compliqué dès que le nombre des classes s'accroît, les liens se multiplient : les "diagrammes de classes" d'UML illustrent bien cette complexité. Il faut, pour la maîtriser, avoir l'esprit très clair et une bonne méthode de travail, qualités élémentaires sans doute, mais peu répandues. 

Enfin, et surtout, se présente un obstacle philosophique. Certaines personnes éprouvent une répugnance profonde devant la démarche d'abstraction ; elles acceptent évidemment l'abstrait, les abstractions institutionnels et figées au milieu desquelles nous vivons (frontières de l'organisation, règles juridiques etc.), mais elles ne supportent pas que l'on produise de l'abstrait neuf, de nouvelles abstractions. Elles sont comme ces gens qui aiment les vielles maisons mais ne supportent pas la vue d'un chantier. Il y a, derrière cette répugnance qui bloque ou retarde souvent l'élaboration du SI, une option métaphysique qui concerne la façon dont on doit se représenter le monde réel (voir "Complexité et complication"). 

Étapes de la modélisation

Supposons que nous ayons pu surmonter les divers obstacles qui s'opposent à la modélisation, et que nous nous soyons engagés dans cette démarche. On voit alors qu'elle comporte deux étapes : l'une concerne la modélisation du système d'information lui-même, que l'on appelle "urbanisme" (en effet cela ressemble à la modélisation d'une ville), l'autre concerne la modélisation d'un processus en vue de la réalisation du produit informatique qui l'équipera : elle recouvre les trois moments de la "spécification" ("modèle métier", "modèle d'analyse" et "modèle technique"). Pour poursuivre l'analogie amorcée avec l'urbanisme, on peut comparer la modélisation d'un processus aux plans que doit dessiner un architecte pour préparer la construction d'un immeuble.

Urbanisme

Le plan d'urbanisme part de l'entreprise considérée dans son ensemble, la découpe en domaines de production de valeur qui reproduisent souvent, mais pas toujours, le découpage de l'organigramme en grandes directions ; puis il identifie les divers processus de production : la plupart de ces processus sont intérieurs chacun à un domaine, mais certains parcourent divers domaines (on les appelle "processus transverses", et ce sont ceux dont la modélisation est la plus difficile en raison du partage de responsabilité qu'ils impliquent) ; enfin, le plan d'urbanisme décrit sommairement les activités (étapes du processus, exécutées chacune par un acteur bien défini) qui se succèdent à l'intérieur de chaque processus. Il identifie enfin les principaux échanges de données entre les divers processus, ainsi que les liens logiques qui relient chaque processus au référentiel de l'entreprise. 

Modélisation d'un processus

La modélisation d'un processus (ou "spécification") reprend et détaille la description des activités esquissée dans le plan d'urbanisme. A chaque activité est associée la liste des dossiers que l'acteur doit utiliser (dossier "client", "commande", "produit", etc.) ; dans le langage UML ("Unified Modeling Language", qui permet de construire les spécifications d'une programmation en objets), on dit que chaque dossier est un "composant" en désignant ainsi soit une "classe" du modèle objet, soit un ensemble de classes autour d'une classe maître.

Chaque composant est caractérisé par un format spécifique ; celui-ci comporte d'abord un identifiant, puis une liste de variables observées sur l'être réel que le composant représente ("attributs"),  enfin des traitements à réaliser sur ces attributs ("méthodes") : ces traitements concrétisent par exemple l'application des règles de vérification lors de la saisie, ou bien l'élaboration d'attributs obtenus par calcul (cumuls, agrégats, âge calculé par différence entre la date de naissance et la date du jour, etc.)

Enfin les données qui représentent les valeurs prises par les divers attributs sont stockées dans des bases de données, selon des architectures et des formats que le modèle devra préciser. 

La modélisation du processus procède selon plusieurs étapes qu'il faut distinguer (voir "Modélisation du processus").