MERISE : modéliser la communication avant les données

Avant d’écrire la moindre table dans une base de données, la méthode MERISE demande de répondre à une question plus simple qu’il n’y paraît : qui échange quoi avec qui, dans l’organisation qu’on s’apprête à informatiser ? Cette étape s’appelle le modèle conceptuel de la communication, ou MCC. Elle sert à cartographier les flux d’information avant de penser écrans, tables ou champs.

Prenez une boutique en ligne. Le client passe une commande, le service comptabilité émet une facture, le transporteur reçoit un bon de livraison. Le MCC ne s’intéresse à aucun de ces documents en détail : il note juste qu’un flux d’information part d’ici et arrive là. Le détail viendra plus tard, avec le modèle conceptuel des données.

Isoler le système avant de le découper

La première tâche consiste à tracer une frontière autour du système étudié. Tout ce qui est à l’extérieur de cette frontière, mais qui échange des informations avec le système, porte un nom précis : les acteurs externes, aussi appelés partenaires. Un fournisseur, un client, une banque, une administration : chacun de ces interlocuteurs envoie ou reçoit des flux d’information sans faire partie du système qu’on modélise.

Une fois cette frontière posée, on découpe l’intérieur du système en entités appelées acteurs internes, ou domaines. Dans une entreprise de taille moyenne, ça peut donner : ventes, production, comptabilité, ressources humaines. Quand un domaine reste trop large pour être compris d’un coup d’œil, rien n’empêche de le redécouper en sous-domaines, par exemple en séparant la paie du recrutement dans un domaine ressources humaines trop chargé.

Le diagramme de contexte, ou qui parle à l’organisation

Le diagramme de contexte pose la première photo des échanges. La convention est stricte, et c’est elle qui rend le schéma lisible par n’importe quel membre de l’équipe projet : l’organisation entière est représentée par un rectangle, les acteurs externes par des ellipses en pointillés, et les flux par des flèches dont le sens indique qui envoie et qui reçoit.

À ce niveau, on ne voit encore aucun détail interne. C’est voulu : le diagramme de contexte répond à une seule question, celle des frontières du système, avant de s’attaquer à ce qui se passe à l’intérieur.

Le diagramme conceptuel de flux, pour ouvrir la boîte

Le diagramme conceptuel de flux, qu’on appelle aussi modèle conceptuel de la communication, prend le relais. Il garde les acteurs externes du diagramme de contexte, mais ajoute les acteurs internes identifiés à l’étape précédente. Chaque acteur interne devient à son tour une ellipse, et les flèches représentent maintenant aussi bien les échanges avec l’extérieur que les messages qui circulent entre les domaines de l’organisation.

Reprenons l’exemple de la boutique en ligne. Le domaine ventes reçoit la commande du client (acteur externe), transmet l’information à la logistique (domaine interne) pour l’expédition, et prévient la comptabilité (autre domaine interne) pour la facturation. Trois flèches, trois flux, aucun champ de base de données encore défini : c’est exactement le niveau d’abstraction que vise le MCC.

Pourquoi ne pas sauter directement au modèle de données

On pourrait être tenté de passer directement à la conception des tables : après tout, c’est ce qui finira dans le système de gestion de base de données. Le problème, c’est qu’une base de données pensée sans avoir clarifié qui échange quoi produit presque toujours des champs orphelins ou des tables qui ne collent pas aux usages réels. Le MCC oblige à valider la logique métier avec les personnes concernées avant d’installer quoi que ce soit en dur.

C’est aussi un excellent outil de dialogue avec des interlocuteurs non techniques. Un rectangle, des ellipses et des flèches se comprennent sans formation en informatique, ce qui n’est pas le cas d’un schéma de base de données relationnelle.

Les pièges classiques du débutant

Le premier piège consiste à confondre acteur et service physique : la « boîte aux lettres » n’est pas un acteur, le client qui envoie le courrier en est un. Le deuxième piège, plus fréquent, revient à dessiner un flux pour chaque document existant plutôt que pour chaque information réellement utile : deux documents différents peuvent très bien porter le même flux d’information. Enfin, mélanger acteurs internes et externes dans le diagramme de contexte fait perdre tout l’intérêt de la première étape, qui est justement de fixer la frontière du système avant d’aller plus loin.

Une fois le MCC stabilisé et validé par les acteurs métier, la suite logique de la méthode MERISE consiste à transformer chaque flux d’information en données précises : c’est le rôle du modèle conceptuel des données, puis du modèle logique qui aboutira à la structure réelle de la base.