II.8.

Modélisation du niveau conceptuel

L'objectif est de représenter l'activité de l'entreprise et de formaliser son SI indépendamment de son
organisation.

• Le modèle de communication formalise les échanges d'informations entre les différents

acteurs.

• Le modèle de traitement formalise les traitements effectués par les acteurs, comment un
acteur réagit à une réception d'informations, ou quand, spontanément, elle décide d'émettre
des informations.

• Le modèle de données décrit la manière dont l’entreprise mémorise son activité. Il formalise
toutes les informations mémorisées. Ces informations sont structurées, regroupées en
ensembles appelés individus et relations entre les individus.

II.8.1. Modèle conceptuel de communication

a) Délimitation du système
La première étape de ce modèle est d'arriver à isoler le système en le délimitant. Le système
pourrait être l’entreprise elle-même ou un service quelconque de l’entreprise. Il s'agit donc de
définir le système et les éléments externes avec lesquels il échange des flux d'information. Ces
éléments extérieurs sont appelés acteurs externes ou partenaires (voir illustration 6).

b) Acteurs
La seconde étape consiste à découper l'organisation en entités appelées acteurs internes (voir
illustration 5).

Caisse Caisse

Illustration 5: Illustration 6:
Représentation Représentation
graphique d'un acteur graphique d'un acteur
interne externe
Un acteur représente une unité active intervenant dans le fonctionnement du système opérant.
Stimulé par des flux, il les transforme, les renvoie. Un acteur “ fait quelque chose ”, il est actif.

Dans la pratique, un acteur peut représenter :

28
 • un partenaire extérieur à l’entreprise (client, fournisseur, etc.),

• un domaine d’activité de l’entreprise précédemment identifié (la comptabilité, la gestion du

personnel, etc.),

• un ensemble d’activités ou processus (liquidation, contrôle, etc.),

• un élément structurel de l’entreprise (service, unité géographique, unité fonctionnelle, etc.).

c) Flux ou message
La troisième étape est l'analyse des flux d'information.

Le flux représente un échange entre deux acteurs. Les flux peuvent être classés en cinq catégories :

• Matière (qui est transformée ou consommée)

• Finance

• Personnel

• Actif (matériel ou savoir-faire nécessaire pour exercer l’activité)

• Information

Un flux est émis par un acteur à destination d’un autre acteur.

Illustration 7:
Représentation
graphique d'un
flux
Deux types de flux sont distingués, les flux enclencheurs ou stimulants et les messages informants.

d) Modèle de communication
C’est une représentation graphique des acteurs entre internes de l'entreprise et les acteurs externes et
des flux échangés. Les acteurs sont représentés par des ellipses ou des rectangles.

Le flux est représenté par une flèche orientée ; le nom du flux étant porté par ce lien.

L’aspect visuel et la simplicité du symbolisme font du MCC un support efficace pour le dialogue
avec l’utilisateur, en particulier lors des premiers entretiens.

• Exemple de MCC

29
 Illustration 8: MCC simplifié d'une entreprise commeriale
Dans l’exemple, nous avons perçu les acteurs suivants : Client, Fournisseur, Comptabilité, Achat,
Comptoir, Caisse, Stock, Secrétariat.

II.8.2. Modèle conceptuel de traitement

L’approche de Merise est une approche du général au particulier. Ainsi le Modèle Conceptuel de
Traitement et le Modèle Conceptuel de Données seront produits à partir du MCC en analysant les
réponses de chaque acteur face à différents stimulis.

a) Décomposition des acteurs

Dans le modèle de communication, sont représentés les messages échangés entre acteurs. Dans les
modèles de traitement, nous décrivons ce qui se passe dans chaque acteur quand ce dernier reçoit
des messages (flux) venant d’un autre acteur. Le MCT est en quelque sorte un agrandissement
(Zoom) du MCC ; l’idée est de découper chaque acteur en plusieurs opérations.

Il faut comprendre à ce niveau de la modélisation que :

30
 • Quand un acteur (intervenant) reçoit un flux (message entrant), ce dernier réagit en
effectuant un ensemble de tâches appelé “ opération ” ou “ traitement ”. A chaque flèche qui
entre va correspondre un ou plusieurs rectangles représentant les traitements.

Les figures suivantes illustrent les passage d’un acteur à un ensemble de traitements.

Illustration 9: Un acteur dans un MCC

Illustration 10: Le même acteur avec les différents traitements

• Chaque opération déclenchera de nouveaux flux à destination d’autres opérations ou

d’autres acteurs (message sortant).

La modélisation conceptuelle des traitements a pour objectif de représenter formellement les

activités exercées par le domaine, activités dont la connaissance est la base du S.

Pour décrire le niveau conceptuel de traitement, le formalisme comporte les concepts suivants :

31
 • L’événement/résultat-message,

• L’état,

• L’opération,

• La synchronisation,

• Les conditions d’émission.

b) Evénement/résultat-message
Un événement est la formalisation d’un stimulus par lequel le domaine, puis son SI, prend
connaissance de comportements de son environnement (interne ou externe à l’entreprise). Un
événement est donc émis par un acteur à destination du domaine.

Un résultat est la formalisation d’une réaction du domaine et de son système d’information. Un

résultat est donc émis par une activité du domaine à destination d’un acteur.

A un événement ou résultat est éventuellement associé un ensemble d’informations appelé message.

Un message est un ensemble structuré d’informations décrivant un événement/résultat type.

Exemple

32
 Illustration 11: Exemple d’évenement (flèches du haut) et de résultat (flèche du bas)
c) Etat
L'état peut s'exprimer par :

• une valeur prise par une information (statut dossier = en cours),

• le fait qu'une activité a été réalisée (calcul des pénalités effectué),

• une règle de traitement (délai de règlement dépassé de 15 jours.)

Pour la description d'un état d'un objet de données, on précisera:

• le nom de l'objet,

• le nom de l'information décrivant le type d'état,

• la valeur de l'état,

• éventuellement la règle permettant de déterminer l'état.

L'état est formalisé graphiquement de la façon suivante :

33
 Illustration 12:
Représentation
graphique d'un
état
Exemple

Illustration 13: Exemple d'un

état
d) Opération
L’opération est la description du comportement du domaine et de son système d’information par
rapport aux événements types. Elle est déclenchée par la survenance d’un (ou plusieurs)
événement(s) et/ou d'un (ou plusieurs) états synchronisés. L’opération comprend l’ensemble des
activités que le domaine peut effectuer à partir des informations fournies par l’événement, et de
celles déjà connues dans la mémoire du SI.

Illustration 14: Formalisme

graphique d'une opération
Exemple

34
 Illustration 15: Exemple d'une opération VENTE
e) Synchronisation
La synchronisation représente une condition de présence d’évènements et/ou d’états préalables au
démarrage de l’opération.

Elle se traduit par une expression logique s’appliquant sur la présence (ou l’absence) des
occurrences des événements et/ou des états. L’expression logique de la synchronisation utilise les
opérateurs classiques ET, OU, NON, ou toute combinaison admise par la logique.

Illustration 16: Place de la

synchronisation (expression)
dans une opération
Si la condition est vérifiée, l’opération peut démarrer et les occurrences déclencheuses (ainsi que les
messages associés) sont considérées comme consommées par l’opération. Si la condition n’est pas

35
vérifiée, la synchronisation et les occurrences d’événements présents restent en attente jusqu’à ce
qu’elle soit vérifiée.

f) Conditions d’émission
L’opération produit des résultats et/ou des états. L’émission de ces résultats et/ou états est soumise à
des conditions traduites par des expressions logiques.

Illustration 17: Place de la

condition dans une opération
Bien que représentée graphiquement dans la partie inférieure de l’opération, une condition peut être
vérifiée à partir de toute fonction de l’opération.

Exemple détaillé d’un MCT

Illustration 18: MCT d’une entreprise

36
 Illustration 19: Suite MCT d'une entreprise
g) Conseil pour la construction d’un modèle conceptuel des traitements
On retrouvera des principes généraux de construction suivants :

• Recenser les acteurs et les flux échangés. L’analyse des flux et sa représentation par le MCC
permet de mettre en évidence le domaine, les acteurs et les flux échangés. Un effort
d’abstraction sera fait pour identifier ces échanges par des événements/résultats.

• Identifier les principaux processus, au sein du domaine, liés aux flux précédents.

• Découper chaque processus en opérations, c’est-à-dire en une succession d’événements et de

résultats.

II.8.3. Modèle conceptuel de données

Le modèle conceptuel de données (MCD) est la représentation de l’ensemble des données du
domaine, sans tenir compte des aspects techniques et économiques de mémorisation et d’accès, sans
se référer aux conditions d’utilisation par tel ou tel traitement.

Dans un système d’information en fonctionnement, données et traitements apparaissent intimement

liés (surtout du point de vue de l’utilisateur).

37
Dans cet univers, on fait référence à des objets concrets ou abstraits (le client, la commande) et à
des associations entre ces objets (le client effectue des commandes). L’objectif du modèle
conceptuel de données est d’identifier, de décrire par des informations et de modéliser ces objets et
associations.

a) Démarche
Dans la démarche de construction d’un modèle conceptuel de données, on distingue deux attitudes,
correspondant en fait à la connaissance de l’organisation par le concepteur :

• Une démarche déductive qui s’appuie sur l’existence préalable d’une liste d’informations à
structurer ;

• Une démarche inductive qui cherche à mettre rapidement en évidence les différents concepts
évoqués, puis à les décrire par des informations.

Ces deux approches coexistent alternativement dans la pratique.

En résumé :

• Si le concepteur opte pour une démarche déductive, il doit d’abord constituer une liste
d’informations.

• Si le concepteur choisit la démarche inductive, il peut directement, à l’aide du formalisme,

construire le modèle conceptuel de données.

b) Constitution d’une liste d’informations

Cette liste d’informations est le résultat d’un recueil d’informations circulant dans le domaine. Elle
se présente sans aucune structure de regroupement (la section suivante traitera le regroupement des
informations) a priori, tout au plus un classement alphabétique.

Pour constituer cette liste, le concepteur peut procéder de deux façons :

• Ratisser, au gré des entretiens, les informations présentes sur quelques documents.

• Exprimer les messages associés aux événements et résultats, et spécifiés dans le modèle
conceptuel de traitements

Pour chaque information que le concepteur recueille dans son environnement, avant de l’ajouter à la
liste déjà établie, il doit répondre aux questions suivantes :

38
 • La nouvelle information n’a-t-elle pas déjà été répertoriée ? Il est, par exemple, fort probable
que l’information n° police apparaisse dans de nombreux messages et documents. Dans ce
cas, on considère la “ nouvelle ” information comme déjà connue.

• La nouvelle information a été déjà répertoriée mais sous une appellation différente. Le
concepteur est en présence d’un synonyme. Par exemple, référence contrat et n° police.
Après s’être assuré de cette synonymie, le concepteur peut soit prendre en compte les deux
informations en notant cette synonymie, soit ne retenir qu’une appellation.

• Une appellation identique existe déjà pour la nouvelle information mais associée à une
signification différente. Le concepteur est en présence d’un homonyme. Par exemple, date
de livraison (demandée) et date de livraison (effective). Il doit impérativement lever
l’ambiguïté en modifiant les appellations des informations.

A la fin de ce travail, le concepteur dispose d’une liste d’informations sans redondance, sans
synonyme et sans homonyme. Il prend soin, par ailleurs, d’associer à chaque information une
description sous la forme d’un texte libre et éventuellement de mots clés, afin de constituer un
catalogue (ou dictionnaire) d’informations.

c) Regroupement des informations

L’idée force du modèle conceptuel de données est de représenter, par un schéma standardisé, les
différents éléments constitutifs du SI, appelés attributs (exemple : nom, âge, ...), et les relations qui
les unissent, appelées associations après avoir regroupé de manière structurée et classifié toutes les
informations listées (on regroupe dans une même entité les données qui ont un point commun).

Une manière simple de modéliser est de décrire la réalité par une phrase : Le sujet et le
complément représentent des entités, et le verbe l’association.

Exemple : un utilisateur (entité) poste (association) une news (entité).

d) Modèle de données
Ce formalisme comporte quatre concepts types de base : l’entité, la relation, la propriété, la
cardinalité. Ce formalisme possède une représentation graphique présentée à la figure suivante :

39
 Illustration 20: Les concepts du formalisme entité - relation
e) Entité
Dans un MCD, une entité est représentée par un rectangle à cartouche. Le nom de l’entité est placé
dans le cartouche : il est recommandé de choisir un nom commun décrivant l’entité
(exemple : CLIENT, ACHAT, FOURNISSEUR). Le nom de l’entité est écrit en majuscules dans le
cartouche. Les attributs (propriétés) prendront place dans la partie basse.

Illustration 21:
Modèle d'une entité
et ses propriétés
La définition de l’entité est un choix du concepteur en fonction de l’intérêt qu’elle présente. A partir
d’objets concrets ou abstraits du monde réel, le concepteur peut, à son gré, composer diverses
modélisations en termes d’entité.

40
 Illustration 22: Différentes modélisations possibles.
f) Règle d’identification
L’on doit pouvoir faire référence distinctement à chaque occurrence de l’entité. Pour cela l’entité
type doit être dotée d’un identifiant. Cet identifiant est une propriété telle que, à une valeur de
l’identifiant, corresponde une seule occurrence de l’entité type.

Le choix d’un identifiant est un problème délicat. On peut opter pour :

• une propriété “ naturelle ”, par exemple le nom d’un pays pour l’entité pays,

• une propriété “ artificielle ”, inventée par le concepteur pour identifier l’entité qu’il vient de
concevoir (tous les numéros, références, codes, etc., en sont l’illustration),

• une propriété composée en s’assurant que la règle de composition ne générera pas de

doublons; on parle alors d’identifiant composé ; par exemple nom + prénom + date et lieu de
naissance,

• un identifiant relatif, par exemple n° allocataire + n° ordre.

41
 g) Association ou Relation
La relation modélise un ensemble d’associations de même nature entre deux ou plusieurs
occurrences d’entités (de types différents ou du même type).

La représentation graphique de la relation est illustrée sur la figure suivante.

Illustration 23:
Exemple d'une
association
Exemple

Illustration 24: Association entre ASSURE et VOITURE

Quelques règles régissent la modélisation en termes de relation type :

• Une relation type n’a pas d’identifiant propre,

• La relation type peut être dotée de propriétés. Il s’agit d’informations qui ne peuvent prendre
de sens qu’avec la présence de l'ensemble des entités constituant cette relation type,

Illustration 25: Propriétés d'une association

h) Cardinalités
Le terme cardinalité, dans le formalisme entité-relation, traduit la participation des occurrences
d’une entité type aux occurrences d’une relation type. Cette participation s’analyse par rapport à
une occurrence quelconque de l’entité type, et s’exprime par deux valeurs : la cardinalité minimum
et la cardinalité maximum.

Certaines valeurs typiques caractérisent les situations les plus courantes :

42
 • Cardinalité mini = 0 : certaines occurrences de l’entité type ne participent pas à la relation;
participation optionnelle.

• Cardinalité mini = 1 : toute occurrence de l’entité type participe au moins une fois aux
occurrences de la relation ; participation obligatoire.

• Cardinalité maxi = 1 : quand une occurrence de l’entité type participe à la relation, elle n’y
participe au plus qu’une fois ; unicité de participation.

• Cardinalité maxi = n : quand une occurrence de l’entité type participe à la relation, elle peut
y participer plusieurs fois ; multiplicité de participation.

Ainsi, les cardinalités fréquemment utilisées sont :

Table 2: Cardinalités fréquentes

Participation Optionnelle Obligatoire

Unique 0,1 1,1

Multiple 0,n 1,n

Remarque importantes

• L'ordre des cardinalités est minimum, maximum.

• Les cardinalités se lisent dans les deux directions : gauche vers la droite et droite vers la
gauche.

Illustration 26: Cardinalités dans une association

Exemple

Dans l’illustration 26, on lit : un CLIENT passe plusieurs COMMANDE ; une

COMMANDE est passée par un et un seul CLIENT

43
 i) Exemple détaillé d’un MCD

Illustration 27: MCD correspondant au MCT des illustrations 18, 19

j) Conseil pour la construction d’un modèle conceptuel de données
On retrouvera ces principes généraux de construction :

• Chercher d’abord à modéliser les entités types qui apparaissent le plus naturellement, puis
s’intéresser aux relations.

• Dès que l’on modélise une entité type, chercher à lui affecter un identifiant, ou du moins
l’illustrer par des exemples d’occurrences.

• Éviter absolument de réfléchir en termes de fonctionnement (ou traitement); s’astreindre à

exprimer des “ faits ”.

• S’assurer que toutes les entités participent au moins à une relation.

• Préciser les cardinalités mini et maxi de chaque entité dans chaque relation.

44