{
    "id": 338,
    "type": "post",
    "title": "MERISE : modéliser la communication avant les données",
    "slug": "merise-modele-conceptuel-de-la-communication",
    "url": "https://www.dico-micro.com/merise-modele-conceptuel-de-la-communication/",
    "description": "Le modèle conceptuel de communication, étape de la méthode MERISE, cartographie qui échange quelle information avec qui avant de concevoir la base de données.",
    "chapo": "Le modèle conceptuel de communication, étape de la méthode MERISE, cartographie qui échange quelle information avec qui avant de concevoir la base de données.",
    "date_published": "2023-07-01T13:58:56+02:00",
    "date_modified": "2026-09-26T16:32:35+02:00",
    "language": "fr-FR",
    "translations": null,
    "categories": [
        {
            "name": "Actus high-tech",
            "url": "https://www.dico-micro.com/sujet/actus-high-tech/"
        }
    ],
    "tags": [],
    "word_count": 897,
    "reading_time_min": 5,
    "image": "https://www.dico-micro.com/wp-content/uploads/2026/09/merise-modele-conceptuel-de-la-communication.jpg",
    "image_alt": "MERISE : modéliser la communication avant les données",
    "author": {
        "name": "Dico Micro",
        "url": "https://www.dico-micro.com/author/dico-micro/",
        "bio": "La rédaction de Dico Micro : matériel, logiciels et culture geek, expliqués sans jargon.",
        "avatar": "https://www.dico-micro.com/uploads/auteurs/dico-micro-robot.webp"
    },
    "content_markdown": "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.\n\nPrenez 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.\n\n## Isoler le système avant de le découper\n\nLa 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.\n\n![Schéma MERISE plaçant le système au centre et les acteurs externes autour, reliés par des flèches de flux](https://www.dico-micro.com/images/acteurs.gif)\n\nUne 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é.\n\n![Découpage d’une organisation en domaines internes distincts comme ventes, production et comptabilité](https://www.dico-micro.com/images/domaines.gif)\n\n  **Un flux, c’est de l’information, pas un document**\n\nLe MCC ne représente ni la facture papier ni le mail envoyé, mais l’information qui circule. Un même flux peut plus tard se matérialiser sous plusieurs formes : ça n’a pas d’importance à ce stade.\n\n## Le diagramme de contexte, ou qui parle à l’organisation\n\nLe 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.\n\n![Diagramme de contexte MERISE avec l’organisation en rectangle et les acteurs externes en ellipses pointillées](https://www.dico-micro.com/images/contexte.gif)\n\nÀ 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.\n\n## Le diagramme conceptuel de flux, pour ouvrir la boîte\n\nLe 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.\n\n![Diagramme conceptuel de flux MERISE reliant acteurs internes et externes par des flèches de communication](https://www.dico-micro.com/images/diagconc.gif)\n\nReprenons 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.\n\n  **Nommez chaque flux avec un verbe d’action**\n\n« Commande » ne dit rien sur le sens de circulation. « Transmettre la commande » ou « confirmer la livraison » lève l’ambiguïté et évite les allers-retours en réunion de validation.\n\n## Pourquoi ne pas sauter directement au modèle de données\n\nOn 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](https://www.dico-micro.com/systeme-de-gestion-de-base-de-donnees/). 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.\n\nC’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](https://www.dico-micro.com/glossaire/b/#base-de-donnees) relationnelle.\n\n  **Un MCC se dessine en une ou deux séances**\n\nContrairement au modèle conceptuel des données, qui peut prendre des semaines sur un système complexe, le MCC reste volontairement grossier. S’il traîne trop longtemps sur la table, c’est le signe qu’on essaie d’y mettre trop de détails.\n\n## Les pièges classiques du débutant\n\nLe 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.\n\nUne 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.",
    "content_html": "<p>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.</p>\n\n<p>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.</p>\n\n<h2>Isoler le système avant de le découper</h2>\n\n<p>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.</p>\n\n<p align=\"center\"><img src=\"/images/acteurs.gif\" alt=\"Schéma MERISE plaçant le système au centre et les acteurs externes autour, reliés par des flèches de flux\"></p>\n\n<p>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é.</p>\n\n<p align=\"center\"><img src=\"/images/domaines.gif\" alt=\"Découpage d’une organisation en domaines internes distincts comme ventes, production et comptabilité\"></p>\n\n<aside class=\"bluf bluf-bleu\">\n<strong>Un flux, c’est de l’information, pas un document</strong>\n<p>Le MCC ne représente ni la facture papier ni le mail envoyé, mais l’information qui circule. Un même flux peut plus tard se matérialiser sous plusieurs formes : ça n’a pas d’importance à ce stade.</p>\n</aside>\n\n<h2>Le diagramme de contexte, ou qui parle à l’organisation</h2>\n\n<p>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.</p>\n\n<p align=\"center\"><img src=\"/images/contexte.gif\" alt=\"Diagramme de contexte MERISE avec l’organisation en rectangle et les acteurs externes en ellipses pointillées\"></p>\n\n<p>À 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.</p>\n\n<h2>Le diagramme conceptuel de flux, pour ouvrir la boîte</h2>\n\n<p>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.</p>\n\n<p align=\"center\"><img src=\"/images/diagconc.gif\" alt=\"Diagramme conceptuel de flux MERISE reliant acteurs internes et externes par des flèches de communication\"></p>\n\n<p>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.</p>\n\n<aside class=\"bluf bluf-rose\">\n<strong>Nommez chaque flux avec un verbe d’action</strong>\n<p>« Commande » ne dit rien sur le sens de circulation. « Transmettre la commande » ou « confirmer la livraison » lève l’ambiguïté et évite les allers-retours en réunion de validation.</p>\n</aside>\n\n<h2>Pourquoi ne pas sauter directement au modèle de données</h2>\n\n<p>On pourrait être tenté de passer directement à la conception des tables : après tout, c’est ce qui finira dans le <a href=\"/systeme-de-gestion-de-base-de-donnees/\">système de gestion de base de données</a>. 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.</p>\n\n<p>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 <a href=\"/glossaire/b/#base-de-donnees\">base de données</a> relationnelle.</p>\n\n<aside class=\"bluf bluf-violet\">\n<strong>Un MCC se dessine en une ou deux séances</strong>\n<p>Contrairement au modèle conceptuel des données, qui peut prendre des semaines sur un système complexe, le MCC reste volontairement grossier. S’il traîne trop longtemps sur la table, c’est le signe qu’on essaie d’y mettre trop de détails.</p>\n</aside>\n\n<h2>Les pièges classiques du débutant</h2>\n\n<p>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.</p>\n\n<p>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.</p>",
    "alternates": {
        "html": "https://www.dico-micro.com/merise-modele-conceptuel-de-la-communication/",
        "markdown": "https://www.dico-micro.com/merise-modele-conceptuel-de-la-communication.md",
        "json": "https://www.dico-micro.com/api/post/merise-modele-conceptuel-de-la-communication.json"
    },
    "site": {
        "name": "Dico Micro",
        "url": "https://www.dico-micro.com/"
    },
    "license": "Reproduction autorisée avec lien vers la source."
}