Ingénieur

STIC 1
Analyse et Conception des
Systèmes d’Information
Juin 2022

KPO Louagbeu Loua

Enseignant-Chercheur au DMI
Loua.kpo@inphb.ci 07 07 77 43 84
I- Introduction à Merise
Introduction
 Difficulté de Conception des SI
Nécessité d’une méthode de modélisation et de conception.

 Objectif : réalisation des projets informatique à partir d’une

méthode de conception et de développement

 MERISE : Méthode d’Etudes et Réalisation Informatique pour

les Systèmes de l’Entreprises

3
Introduction
 Système d’information au sein d’une Entreprise
Les ressources de l’entreprise
◼ Les ressources productives
◼ Les ressources commerciales
◼ Les ressources financières
◼ Les ressources humaines
◼ …..Système d’information au sein d’une Entreprise

L’information
◼ L’acquisition
◼ Traitement
◼ Transport
◼ Stockage

4
Introduction
 Problème de constitution d’un SI sans méthode
Vision parcellaire des besoins
◼ Redondance de données
◼ Synonyme (plusieurs termes ont le même sens)
◼ Polysémie (terme à plusieurs sens différents)

Difficulté d’une maintenance efficace

◼ Moyens techniques limités
◼ Manque de dossiers d’analyse

Utilisateur non intégré dans la conception du SI

Difficulté de planification et de suivi du travail
Apparition des méthode de conduite de projet

5
1.1-Historique
En 1977/1978, demande du Ministère de l’Industrie (France)
choix de société de conseil en Informatique pour la constitution
d’une méthode de conception des systèmes d’information
➢ Equipe de Lemoigne( Univ. d’Aix/Marselle)
➢ CTI (Centre Technique d’Information)
➢ CETE (Centre d’Etude Technique de l’équipement)
➢ Méthode Merise (1979)
➢ Conception du SI par étapes validées

➢ Séparation des données et des traitements

➢ Vérifier la concordance entre données et traitements

➢ Vérifier qu’il n’y a pas de donnée superflues

➢ Méthode MERISE 2ième génération en 1992

6
1.2-Notion de système
❑ Un système est un ensemble d’éléments matériels ou
immatériels (hommes, machines, méthodes, règles, etc.) en
interaction transformant par un processus des éléments (les
entrées) en d’autres éléments (les sorties)

❑ Exemple: une chaudière transforme par combustion du

charbon en chaleur.

❑ Un système peut être contrôlé par un autre système dit

système de pilotage.

7
1.2-Notion de système
❑ On obtiendra plus ou moins de chaleur selon les réglages
qu’on effectuera sur la chaudière. L’opérateur qui effectue
les réglages et contrôle le flux de charbon en entrée constitue
un système de pilotage qui par ses commandes au système
physique (à la chaudière) cherche à satisfaire un objectif (un
tel niveau de chaleur).

8
1.3-Le système d’Informations
❑ Nous n’envisageons ici que des systèmes constitués par des
organisations (entreprise, administration, collectivité, tout
groupe social organisé exerçant une activité) et fonctionnant
en vue de la réalisation de certains objectifs.

❑ Un système physique ou (opérant) transforme un flux

physique d’entrées (matières premières, flux financiers …) en
un flux physique de sorties (produit finis, flux financiers …).

❑ Un système de gestion ou (pilotage) procède au pilotage (à la

régulation et au contrôle ) du système opérant en décidant du
comportement de celui-ci en fonction des objectifs
fixés.

9
1.4-Les systèmes
❑ Système d’information est défini comme le cœur de l’entreprise, il se
trouve interface entre le système opérant et le système de pilotage et fournit
les réponses aux deux systèmes.

❑ Système opérant :
❑ Chargé de la production
❑ répond à la finalité de l'entreprise

❑ Système de pilotage :
❑ Dirige l’entreprise
❑ cible les objectifs a une fonction d'arbitrage, d'allocations de
ressources, de suivi de leurs utilisations, d'adaptation du
fonctionnement de l'entreprise à son environnement

10
 1.4-Les systèmes
❑ Système d'information :
❑ lien entre les deux systèmes
❑ informe le Système de Pilotage des performances du Système Opérant
❑ transmet au Système Opérant les instructions du Système de Pilotage

11
Le système d’Informations

12
Rôle du système d’information
 Collecter des informations provenant :
◼ d ’autres éléments du système
◼ de l’environnement

 Mémoriser des données :

◼ base de données
◼ Fichiers
◼ Historique, Archivage

 Traiter les données stockées :

◼ traitements automatisables
◼ aide à la prise de décision

 Communiquer
13
Rôle du système d’information
❑ L’information est la base de toute décision d’entreprise :
Ex. : embaucher un comptable, sur la base de données perçues non
formalisées dans le SI (les protestations dans le service par ex.) ou celles
formalisées dans le SI (ex : indicateur nombre d’écritures comptables / jour
/ employé)
❑ L’information est l’outil de coordination de toute organisation :
Ex. : sur la base du budget des ventes, le responsable commercial oriente
l’action des vendeurs en termes de volume de ventes, de marge et de cible
commerciale. Ce même budget est la référence des vendeurs, du Service
marketing...

❑ L’information n’est pas statique, elle se transforme et passe

dans des flux
Information = énergie (rien ne se crée, tout se transforme).
Ex : une écriture comptable de vente sert à mettre à jour un compte
client, la situation du budget des ventes et aussi sera décomposée en
lignes de commande client pour la production et la comptabilité analytique.
On parle de chaîne de traitement de l’information.

14
1.5-Vision systémique de
l’entreprise et formalise de Merise

15
1.5-Vision systémique de
l’entreprise et formalise de Merise
❑ Seul le système de Pilotage n’est pas directement décrit par Merise
Le Système de Pilotage ne peut être modélisé à partir de processus, sauf
ceux
relatifs à des processus de décision à partir de représentations totalement
différentes (non abordées ici)

❑ Les entités du SI d’informations sont décrites par des données

brutes en majorité
Le système opérant manipule des données brutes en majorité (ex : un
montant HT, un nombre d’articles…), parfois calculées (ex. total TTC). Ces
données « de base » sont représentatives du système d’informations induites
par les opérations des acteurs du système (par ex. pour rédiger une
commande, il faut connaître la référence de l’article et son tarif)

❑ Le système de pilotage manipule de son côté des données

agrégées portant sur les données brutes mémorisées dans le SI.
La méthode Merise ne s’y intéresse pas.

16
 La notion du système
d’information
Un projet informatique a pour objectif de construire une
application informatique (logiciel et base de données), support
d'un système d'information informatisé, inclus dans un système
d'information organisationnel.

17
 1.6-La notion de modèle
un modèle est une représentation simplifiée d’une réalité sur
laquelle on veut être renseigné (Ex: Un schéma électrique, le
plan d’une maison…)
Un modèle s’exprime avec un ensemble de concepts dotés de
règles d’utilisation et de représentations.

Rôle: un modèle sert à :

➢ Communiquer : vérifier que l’analyste a bien compris les
utilisateurs (phase de l’analyse)
➢ Préparer la réalisation: grâce à un modèle de la solution
(phase de conception)
➢

18
Exemple de modèle

19
 1.7-Analyse et Conception
Au sens informatique, l’analyse consiste d’une part à
comprendre et modéliser le fonctionnement d’un domaine de
gestion d’une organisation, et d’autre part à concevoir la
solution informatique adéquate.

Analyse Conception
 On s’intéresse en général à un On définit une solution informatique:
domaine d’activité de l’entreprise  Structuration des données
◼ Vente  Organisation des traitements
◼ Production  Définition des postes de travail
◼ Logistique  Choix techniques matériels,
◼ Finance langage de programmation, le
◼ RH SGBD…. (bien justifié)
 On prend en compte les besoins
des utilisateurs
 On définit le problème à résoudre
(fonctionnalités et qualités
attendues)
20
1.7-Analyse et Conception

Démarche globale

Conception
Analyse du Réalisation
de la
problème du système
solution

21
1.8-Principes de base de la
méthode Merise
❑ Expression des besoins
• Définir les attentes du SI a automatisé
• Faire l’inventaire des éléments nécessaires au SI
• Délimiter le système en s’informant auprès des futures
utilisateurs

22
1.9-Approche par niveaux et
approche par étapes
 Démarche par niveaux: formalise le système futur
◼ En contribuant à la stratégie de l’entreprise
◼ Mettant en œuvre les règles de gestion
◼ En tenant compte des aspects organisationnels et techniques

 Démarche par étapes: hiérarchise les décisions au cours du

projet
◼ Conception
◼ Développement
◼ Mise en œuvre
◼ Généralisation de l’emploi du SI futur
◼ Évolution du SI futur

 Intérêt de cette double approche

◼ Maitrise des risques (coût, délais, personnel…)
◼ Favorise l’introduction de nouvelles technologies
◼ Favorise l’évolution des SI 23
 1.10-Trois (3) niveaux de
modélisation
 Invariance décroissante: formalise le système futur
◼ Plus le niveau est élevé (ou conceptuel) plus il est stable

 Possibilité de détecter plus rapidement les problèmes

1. Niveau conceptuel
◼ Répondre à la question quoi ? (ce que fait l’entreprise)
◼ Que faire ? Avec quelles données ?
◼ Modèle conceptuel des données (MCD)
◼ Modèle conceptuel des traitements (MCT)

2. Niveau organisationnel
◼ Répondre aux questions qui, quand, où ? (les différents postes de ceux
qui le font)
◼ Modèle logique des données (MLD)
◼ Modèle organisationnel de traitement (MOT)

24
 Trois (3) niveaux de modélisation
3. Niveau technique
◼ Répondre à la question comment ? (quels sont les moyens de le faire?)
◼ Intégration des moyens techniques, matériels et logiciels
◼ Modèle physique des données (MPD)
◼ Modèle opérationnel des traitement (MOpT)

25
1.11-Merise
 Points forts
◼ La méthode s'appuie sur une approche systémique : C’est
donc une approche globale.
◼ Les concepts sont peu nombreux et simples.
◼ Elle est assez indépendante vis à vis de la technologie.
◼ Elle est la plus utilisée en France dans les domaines de gestion (2010).
◼ Elle sert de référence aux enseignements sur les méthodes.
 Critiques
◼ Elle ne s'occupe pas de l'interface utilisateur.
◼ Elle ne permet pas réellement une validation rapide de la part des
utilisateurs.
◼ Il est très difficile de valider les traitements par rapport aux données et
cela au niveau conceptuel ou organisationnel.
 La validation en cours de l’étude par des personnes concernées permet
d’assurer que le système en train de construction conforme aux objectifs. Si on
ne respecte pas les étapes de validation on risque de produire des applications
loin de la demande initiale ce qu’on nomme « l’effet tunnel ». Sans oublier que
les applications développées sont destinées aux utilisateurs et non
au plaisir des informaticiens.
26
II-Les principes de bases de
Merise
Introduction
De l’abstraction à la réalisation d’un Système d’information, on va devoir
observer sous plusieurs angles de vues l’organisation que l’on étudie.
Ces angles de vues sont appelés cycles. MERISE présente dans sa démarche
d’analyse trois cycles fondamentaux :
• le cycle d’abstraction,
• le cycle de vie (de développement),
• le cycle de décision

28
2-1. Démarche ou cycle de vie à
trois dimensions

 La démarche : le niveau du cycle de vie

 Le raisonnement : le niveau d’abstraction
 La maitrise : le niveau de décision

29
2-2. Cycle d’abstraction
 Niveau conceptuel
◼ Ce qu’il faut faire
◼ Quoi faire

 Niveau organisationnel
◼ La manière de faire
◼ Pour les traitements
◼ QUI, QUAND, OU ?

 Niveau logique
◼ Choix des moyens de ressources
◼ Pour les données

 Niveau physique
◼ Les moyens de le faire
◼ Comment le faire
30
Introduction

31
 2-3. Cycle de vie
Manière de conduire le projet: succession de phases
contrôlables par l’organisation (planning, échéances, moyens
humain…)

1. Analyse et Conception
Le schéma directeur
L’étude préalable
L’étude détaillée

2. La réalisation
L’étude technique
Production logiciel
Mise en service (déploiement)
3. La Maintenance

32
2-3. Cycle de vie

 Le processus de développement est découpé en étapes :

◼ Schéma directeur
◼ l’étude préalable : elle aboutit à une prise de décision
d’informatisation, en cas de décision positive, elle est suivie par
◼ l’étude détaillée : elle aboutit à un cahier de réalisation avec
affectation des tâches
◼ Réalisation : écriture des programmes et implantation des bases
◼ Mise en œuvre et maintenance

33
2-3. Cycle de vie

34
2-4. Schéma directeur
 Etude globale du SI: Découpage en domaines
 Buts:
◼ Définir les grandes orientations politiques et stratégiques de l’entreprise
◼ Définir les besoins en SI en fonction de la stratégie de l’entreprise
◼ Fixer les cadres budgétaires, la stratégie des besoins en personnel et les
contraintes
diverses liées à l’environnement
◼ Fixer les lignes directrices des développements informatiques
◼ Définir les projets nécessaires à l’élaboration ou l’évolution du SI
 Documents produits:
◼ Le schéma directeur
◼ Le plan de développement informatique

35
2-4. Etude préalable
Comporte
 Une analyse critique du système existant (physique,
organisationnel, conceptuel)
 Les objectifs du nouveau système (Conceptuel,
organisationnel)
 Les différents scénarios de solutions informatique
 Une évaluation des coûts et moyens nécessaires
 Un planning de réalisation
Se traduit par :
 Un dossier d’étude préalable ou dossier de choix
Aboutit
 Au choix d’une solution par la direction

36
 2-5. Etude détaillée
Permet
 De se décider de l’organisation détaillée de la solution retenue
 De définir logiquement les données et les traitements
informatique de la solution
 De définir les interfaces écrans, états de sortie,
 De construire le planning de réalisation
Se traduit par :
 Un cahier des charges de l’application (contrat vis-à-vis des
utilisateurs)
 Un dossier d’étude détaillée pour les analystes-programmeurs
 Un cahier des charges matériel/ logiciel pour appel d’offre


37
2-6. La réalisation
La réalisation qui consiste à produire le logiciel et à le mettre
en place , comporte trois étapes:

 Etude technique : spécification technique complète

 Production logiciel : écriture des programmes et tests

 Mise en service: installation de l’application informatique

38
2-7. Etude Technique
Effectue
 La spécification technique (niveau physique)
◼ Structure physique de données
◼ Dossiers d’écrans et des états de sortie
 La production des programmes
Fournit
 Une documentation technique (maintenance des programmes)
 Une documentation utilisateur (manuel d’utilisation de
l’application)
 Manuel d’exploitation (pour le service exploitation sur gros
sites informatiques)

39
 2-8. La maintenance
Adaptation à l’évolution de l’environnement( correction des
anomalies, amélioration, évolutions)

 C'est la prise en compte des évolutions apparaissant après le

lancement opérationnel.

Elle comprend :
 L'étude de l'impact des modifications
 La spécification des modifications
 La réalisation
 La mise en service
Elle peut parfois aboutir à une remise en cause de la solution
précédemment mise en place.
40
 2-9. Cycle de décision
Durant le cycle de vie, des décisions sont à prendre aus
différentes étapes (possibilité de conflits).

41
2-9. Cycle de décision

42
2-10. Résumé (principe de base)

43
III-Les flux d’information dans
l’organisation
3-1. Découpage en domaine
❑ Pour réduire la complexité de modélisation de l’entreprise en
un seul tenant, on découpe l’entreprise en domaines d’activité
(Vente, Stock, Achat, Comptabilité, Gestion du personnel)
52
Un domaine d’activité de l’organisation est un sous-ensemble
relativement indépendant composé d’informations, règles et
de procédures de gestion

❑ Chaque domaine peut être considéré comme un système

autonome (ayant un SP, Si et un SO)

45
3-1. Découpage en domaine

❑ Les domaines de l’entreprise échangent des flux entre eux,

certaines informations peuvent figurer dans plusieurs
systèmes d’information.

❑ Le SI de l’entreprise peut être considéré comme la réunion

non disjointe des SI de chaque domaine.

46
3-2. Comment découper une
organisation en domaine ?
 la technique employée se base sur les ensembles
d’informations échangés, dits aussi flux d’information. Ces
flux peuvent être classés comme suit :
1. Flux en provenance de l’environnement extérieur
2. Flux à destination de l’environnement extérieur
3. Flux interne échangé (entre les domaines)

47
 3-3. Analyse des flux
 L’analyse des flux permet de représenter le fonctionnement
global de l’entreprise

Acteurs et flux
 Un acteur représente une entité active intervenant
dans le fonctionnement de l’entreprise :
◼ Client, Fournisseurs, (acteur externe)
◼ Un domaine de l’entreprise (Gestion Personnel, Comptabilité)
◼ ….

 Un flux de données est la représentation d’un échange

d’informations entre deux acteurs

48
3-4. Graphe des flux
Le graphe des flux est une représentation graphique
des acteurs et des flux.

49
3-4. Graphe des flux
Exemple : Gestion des sinistres dans une société
d’assurance
A l'arrivée d'une déclaration de sinistre, on l'examine. Si la
déclaration est recevable, on demande l'avis d'un expert, sinon
on notifie le refus à l'assuré. Au retour de l'expertise et après
réception de la facture du garage, on calcule le montant du
remboursement et on envoie le chèque au client

Liste des acteurs Liste des flux

SOCIETE D’ASSURANCE (int), DECLARATION,
CLIENT (ext), DEMANDE AVIS,
EXPERT (ext), FACTURE,
GARAGE (ext) REFUS,
AVIS EXPERT,
CHEQUE
50
3-4. Graphe des flux

51
3-4. Graphe des flux
Lorsque le graphe comporte plusieurs acteurs internes on
regroupes parfois tous ces acteurs en une même entité
(correspondant au SI à étudier) et on ne garde que les flux
en entrée et en sortie. C’est le ‘graphe des flux
contextuel’

52
3-5. Exercice d’application (1)
(GESTION DES CARTES BLEUES)
Le demandeur désirant obtenir une carte bleue doit en faire
la demande auprès de son agence.
La carte bleue n'est pas accordée si le demandeur n'est pas
un client de l'agence.
Chaque jour, l'agence transmet au centre de gestion des
cartes bleues les demandes de ses clients.
Dès que l'agence a reçu la carte bleue en provenance du
centre (en général 4 jours après la demande), elle adresse
au client un avis de mise à disposition et un avis de
prélèvement de la cotisation annuelle. Le client vient alors
retirer sa carte.
Si au bout de 2 mois la carte n'a pas été retirée, elle est
détruite.
1. Etablir le graphe des flux

53
3-5. Exercice - Solution

54
IV- Le modèle conceptuel des
traitements (MCT)
 Le modèle Conceptuel de
traitement
❑ L’objectif du MCT est de répondre à la question QUOI faire par
rapport à un événement.
▪ Tenir compte de la chronologie des évènements
▪ le MCT est une représentation de la succession des règles de
gestion dont l’entreprise veut se doter pour répondre aux
événements auxquels elle doit faire face, du fait de son
activité et de son environnement.

❑ il décrit le fonctionnement du SI d’une organisation au niveau

conceptuel : on ne décrit que les règles fondamentales de
gestion (les invariants, ‘le métier’ de l’organisation).
Description la plus stable.

56
Le modèle Conceptuel de
traitement
Exemple introductif
Les demandes des crédits bancaire doivent suivre les règles de
gestion suivantes :

Règle 1 : Toute demande d‘un crédit bancaire doit faire l'objet

d'un examen préalable.

Règle 2 : L'accord définitif du crédit bancaire ne peut être donné

qu'après avis de la Banque du Maroc.

Travail à faire : Proposer un MCT

57
Le modèle Conceptuel de
traitement

58
Le modèle Conceptuel de
traitement
Le fonctionnement du SI est décrit par :
❑ l’enchaînement d’opérations, déclenchées selon certaines
conditions de synchronisation (et, ou, …), par des
événements contributifs (internes ou externes), et
produisant d’autres événements résultats (internes ou
externes).

59
Schéma
d’une
opération
conceptuelle

60
4-1. MCT - Evènement
Les Types d’événement
1. Evénements externes : proviennent de l’univers extérieur, sont traités par
une opération conceptuelle (ex: arrivée d’un flux d’entrée, date de
déclenchement),
• C’est un stimulus pour le SI qui provoque une réaction. Il doit
être détectable par le SI.
• C’est un message c’est à dire un ensemble de données qui sont
associés au fait nouveau.

2. Evénements internes : générés par une opération conceptuelle, contribuent

au déclenchement d’une autre opération (état intermédiaire du SI ou état
d’attente),

3. Evénements résultats : générés par une opération conceptuelle et destinés à

l’univers extérieur (résultats externes) ou à d’autres opérations (résultats
internes)

61
4-2. MCT - Opérations
▪ Séquence continue d’actions non interruptible.
▪ Déclenchée par un ou plusieurs événements internes ou
externes.
• Produit des événements résultats internes ou externes,
conditionnés par des règles d’émission.

Les actions sont constituées :

• des traitements appliqués aux données en entrée selon
certaines règles,
• des tâches de consultation et de mise à jour d’une
base d’informations (base de données)
implicitement accessible.

62
4-3. MCT – Synchronisation
❑ Condition exprimée sur les événements, qui détermine
le déclenchement d’une opération.

❑ S’exprime sous la forme d’une proposition logique

utilisant des et et des ou (on évitera au maximum le
non, les non-événements n’étant pas toujours
détectables par le SI)
Exemple : a ou (b et c)

63
4-4. MCT – Règles d’émission
Elles caractérisent les résultats possibles de l’opération
❑ les conditions d’émission des résultats d’une opération ne
sont pas nécessairement exclusives (un résultat peut
être émis par deux règles d’émission distinctes)
❑ les conditions d’émission portent souvent sur des cas
d’anomalies (ex : une rupture de stock).

❑ Les résultats d'une opération peuvent être conditionnés

par des règles d'émission. L'absence de règles d'émission
signifie que le résultat est « TOUJOURS » produit ;
❑ On ne retient que les règles d'action, on ne retient pas les
règles de calcul.

64
4-5. MCT – difficultés

65
4-6. Construction du MCT

66
5-6. Construction du MCT
Démarche
Étape 1 A partir du graphe des flux, on construit la liste de tous
les événements en entrée et en sortie du SI.
Étape 2 Passage au MCT
tout événement en entrée se retrouve en entrée d'une
opération,
il existe d’autres événements en entrée (ex: des dates conceptuelles),
tout événement en sortie est produit par une opération,
une opération peut avoir plusieurs événements contributifs vérifiant
une règle de synchronisation,
une opération peut avoir plusieurs événements résultats émis selon
certaines règles d'émission,
une opération peut ne construire aucun événement résultat mais
uniquement des événements internes,
tout événement résultat est destiné soit à un acteur externe, soit à une
autre opération,
le découpage en opérations est guidé par les règles de gestion.

67
4-6. Construction du MCT
Règles de validation
Une opération ne peut pas être interrompue par l’attente d’un événement
externe. Si tel est le cas, il faut décrire une seconde opération déclenchée
par cet événement en attente.

TAF : Réaliser le MCT de la gestion des sinistre

68
4-6. Construction du MCT

69
4-6. Exercices
Domaine d'étude : Gestion des ventes

Quand un client s'adresse à un vendeur et lui dit qu'il souhaite

acheter une chaîne Hi-fi (par exemple), celui-ci vérifie sur
ordinateur si l'article est disponible. Si ce n'est pas le cas, le
vendeur informe le client de l'indisponibilité du matériel
souhaité ; sinon le vendeur remplit un bon avec les références
de l'article et le prix à payer. Le client doit alors se présenter à
la caisse, muni de ce bon. Une fois le montant à payer réglé, la
caissière lui remet une facture et un bon de sortie de stock. Un
double de bon de sortie est envoyé à l'entrepôt afin que soit
apporté au magasin (au rayon "retrait des articles") l'article Hi-
fi. Le client se présente alors au rayon "retrait des articles",
juste à côté de la caisse et présente son bon de sortie de stock.
Dès que l'article est arrivé, un employé tamponne le bon de
sortie : "article livré" et remet l'article acheté au client.
70
4-6. Exercices
Domaine d'étude : Gestion des ventes

TAF:

1) Identifier les acteurs internes, externes et les domaines connexes.

2) Réaliser le diagramme de contexte.
3) Réaliser le MCT

71
4-6. Exercices
Domaine d'étude : Gestion des ventes

Acteurs externes : Clients

Domaines connexes : Entrepôt / Retrait des articles
Acteurs internes: Vendeurs / Caisses

➢ Les flèches en pointillés bleus sont facultatives puisqu'elles ne

concernent pas directement le système d'information de la Gestion
des ventes.
➢ A droite, on retrouve les domaines connexes qui font partie de
l'entreprise, mais pas du système de gestion des ventes. Les
domaines connexes sont représentés avec des rectangles.
➢ A gauche, les client représentent un acteur externe dans le système
d'information et ils sont donc représentés par une ellipse.

72
4-6. Exercices

73
4-6. Exercices

74
 4-7. Exercices
Le demandeur désirant obtenir une carte bleue doit en faire la
demande auprès de son agence. La carte bleue n'est pas
accordée si le demandeur n'est pas un client de l'agence.
Chaque jour, l'agence transmet au centre de gestion des
cartes bleues les demandes de ses clients.
Dès que l'agence a reçu la carte bleue en provenance du
centre (en général 4 jours après la demande), elle adresse au
client un avis de mise à disposition et un avis de prélèvement
de la cotisation annuelle. Le client vient alors retirer sa carte.
Si au bout de 2 mois la carte n'a pas été retirée, elle est
détruite.
1. Etablir le graphe des flux
2. Etablir le MCT

75
4-8. Modèle Organisationnel des
traitements
Le modèle organisationnel des traitements s'attache à décrire
les propriétés des traitements non traitées par le modèle
conceptuel des données, c'est-à-dire :

➢ le temps
➢ les ressources
➢ le lieu

Le modèle organisationnel des traitements consiste donc à

représenter le modèle conceptuel des traitements dans un
tableau dont les colonnes sont la durée, le lieu, les
responsables et ressources nécessaires à une action.

76
 4-9. MOT – Tableau des
procédure fonctionnelles
❑ La première étape du modèle organisationnel des
traitements consiste à découper les opérations en
procédures fonctionnelles, une succession de traitements
déclenchée par un événement.

Il s'agit donc d'associer dans un tableau :

▪ les procédures fonctionnelles
▪ l'heure de début et de fin
▪ le lieu du poste de travail
▪ le responsable du poste de travail
▪ les ressources du poste de travail

MOT = MCT + lieu (qui exécute l’opération) + moment

(quand exécute-t-on l’opération) + nature (manuelle ou
automatique)

77
78
4-9. MOT – Gestion de cartes
bancaire

61
4-9. MOT – Gestion de cartes
bancaire

80
V- Le modèle conceptuel de
données (MCD)
V. MCD
Objectif du MCD

❑ Le modèle conceptuel des données est une représentation

statique du système d’information de l’entreprise qui met
en évidence sa sémantique.

❑ Il a pour but d'écrire de façon formelle les données qui

seront utilisées par le système d'information.

❑ Il s'agit donc d'une représentation des données, facilement

compréhensible. Le formalisme adopté par la méthode
Merise pour réaliser cette description est basé sur les
concepts « entité- association ».

82
5-1. MCD- Dictionnaire de
données
❑ Inventaire exhaustif des données du domaine étudié.
❑ On utilise habituellement : une fiche "descriptif de
document" (une par document),

❑ Unicité sémantique : à une donnée correspond une

mnémonique ,il faut parvenir à ce que chacun de ces
mnémoniques ait une signification unique au sein de
l’organisation. Il faut pour cela éviter :
➢ Les redondances : existence d’une donnée en double
➢ Les synonymes : existence de deux mnémoniques
décrivant le même objet (difficile à détecter)
Libelle Article
Nom Produit
Il faut trancher en choisissant un des mnémonique
➢ Les polysèmes : mnémonique unique pouvant décrire
plusieurs objets différents
83
5-1. MCD- Dictionnaire de
données
❑ Contraintes d’Intégrité : (CI) une contrainte d’intégrité
est une règle à observer pour que chacune des valeurs que
revêt une donnée soit correcte.

❑ Les données calculées doivent être examinées avec soin.

La règle est la suivante : Si une donnée calculée peut être
obtenue par l’application d’un traitement à partir de
données élémentaires valides, on peut la supprimer du
dictionnaire.

84
5-2. MCD- Recueil des données
Contexte
Le but du recueil des informations est de constituer un
référentiel sur lequel s’appuiera l’étude. Ce référentiel est
consigné dans un document appelé dictionnaire des données.
Le dictionnaire peut être géré à l’aide d’outils spécialisés.
Cette phase de recueil est effectuée en plusieurs étapes :

❑ Techniques et outils
La localisation des informations: Le premier problème à
résoudre est de trouver l’information. On recherchera dans les
documents, les règlements, les lois, les normes, les
procédures, les bases de données, les fichiers.

85
5-2. MCD- Recueil des données
Les techniques de recueil
Pour recenser les informations, on utilise essentiellement l’étude
de documents et les entrevues.
➢ Les documents
L’essentiel des données peut être retrouvé sur les documents en
circulation. On s’efforcera :
▪ De rassembler un maximum de documents,
▪ De s’assurer que les documents sont encore valides,
▪ D’utiliser des documents remplis (pas seulement des
modèles) et repérer les informations réellement utilisées,
▪ D’attacher une attention particulière aux documents non
formalisés (ils traduisent souvent l’existence d’une
évolution non prise en compte des procédures ou d’une
inadéquation de la procédure en cours),
▪ De décoder les codes et abréviations utilisés

86
5-2. MCD- Recueil des données
➢ Les entrevues
▪ Avec la direction, il s’agit d’obtenir des informations générales
: organisation des services, objectifs stratégiques, procédures
et règles de gestion globales…
▪ Avec les utilisateurs, on s’efforcera :
o D’obtenir une description précise et détaillée des
procédures.
o De mettre en évidence des dysfonctionnements.
o D’obtenir des propositions, des critiques, des suggestions.
o De rechercher des procédés non officiels.

87
5-2. MCD- Recueil des données
❑ Classification des données
On peut distinguer :
✓ Les données élémentaires : l’information se confond avec la valeur
prise par la donnée. Par exemple, un nom, une date… Ces données
doivent être recensées de manière exhaustive.
✓ Les données calculées ou déduites : elles sont obtenues par
l’application d’un traitement mathématique ou logique. Ces données
sont associées à des règles de calcul (règles de gestion). Il faut penser
à bien identifier et conserver la règle de gestion qui permet d’arriver
au résultat.
✓ Les données composées : certaines données sont regroupées en une
même entité sémantique (par exemple une adresse). Ces informations
doivent être décomposées en données élémentaires. Toutefois, s’il est
montré qu’une donnée composée n’est jamais décomposée dans la
chaîne de traitement de l’information, on peut envisager de la
conserver telle quelle.
88
5-2. MCD- Recueil des données
❑ Typologie des données
Notion de domaine
Certaines données ont des valeurs prises dans le même
ensemble. Par exemple, langue parlée, langue lue et langue
maternelle prennent leur valeur dans un ensemble sémantique
« Langues ».
On appelle domaine l’ensemble des valeurs prises par une
donnée, indépendamment du contexte de son utilisation.

89
5-2. MCD- Recueil des données
❑ Typologie des données
Notion de domaine
L’identification d’un domaine est une opération importante lors
du recueil des données. Il s’agit de déterminer précisément
l’ensemble des valeurs possibles s’il s’agit d’un domaine
exhaustif ou les règles de représentation (codification, types,
bornes…) dans les autres cas.

90
5-2. MCD- Recueil des données
❑ Typologie des données
Types de données
Les types de données ont un sens plus restrictif que le domaine.
Alors que le domaine s’applique à la sémantique d’une donnée
(plus proche de la notion d’information), le type est une
contrainte physique liée à la manière dont sera stockée la
donnée dans le système d’information.
Les principaux types à retenir sont :
✓ Alphabétique (A)
✓ Alphanumérique (AN)
✓ Numérique (on peut préciser s’il s’agit d’un entier ou d’un
réel)
✓ Date (D)
✓ Logique ou booléen (L ou B)
✓

91
5-3. MCD-DD Formalisme

92
5-4. MCD- Graphe de
dépendances fonctionnelles
Notion de dépendance fonctionnelle (df)

Soient A et B les ensembles de valeurs prises par deux

données. Il y a dépendance fonctionnelle entre A et B
lorsque, connaissant une valeur de A, quelque soit cette
valeur, on détermine une et une seule valeur de B.
On symbolise la dépendance fonctionnelle par A → B où A
est appelé source de la df (on dit aussi déterminant ou
partie gauche) et B la cible (on dit aussi but, déterminé
ou partie droite) de la df.

Par exemple no_client → nom_client

Cela signifie qu’à un numéro de client ne correspond

qu’un et un seul nom. En revanche, il n’est pas impossible
qu’à un nom, correspondent plusieurs clients.
93
5-4. MCD- Graphe de
dépendances fonctionnelles
Typologie
❑ Dépendance fonctionnelle forte et faible
La définition de la dépendance fonctionnelle peut être affinée :
Définition stricte
• la df associe à chaque valeur de A une et une seule de B : il y
a unicité au départ
• la df est vérifiée pour toutes les valeurs de A : il y a totalité
au départ (toutes les valeurs de A ont une image dans
l’ensemble d’arrivée B).
Dans ce cas, on parle de df forte.
Par exemple, la dépendance fonctionnelle
no_commande → no_client est une df forte car il n’y a pas
de commande sans client.

94
5-4. MCD- Graphe de
dépendances fonctionnelles
Typologie
❑ Dépendance fonctionnelle forte et faible
Définition large
Il y a dépendance fonctionnelle entre A et B lorsque, connaissant
une valeur de A, quelque soit cette valeur, on détermine au plus
une valeur de B. Cette définition supprime la contrainte de
totalité au départ. On parle de df faible.
Par exemple, la dépendance fonctionnelle
no_insee →nom_jeune_fille est une df faible car certaines
valeurs de NoInsee n’ont pas de correspondance dans
l’ensemble d’arrivée.

95
5-4. MCD- Graphe de
dépendances fonctionnelles
Typologie

❑ Dépendance fonctionnelle à partie gauche composée

Une df peut comporter dans sa partie gauche plusieurs attributs.
On parle dans ce cas de dépendance fonctionnelle à partie
gauche composée. Pour connaître une valeur de l’ensemble
d’arrivée C, il faut connaître un couple (ou plus) de valeurs
provenant de A et de B.
Ce type de df est noté : (d1, d2) → d3

(no_facture, code_produit) →qte_facturee

(no_eleve, matiere, date) →note

96
5-4. MCD- Graphe de
dépendances fonctionnelles
Typologie

❑ Dépendance fonctionnelle élémentaire

Une df est élémentaire s’il n’existe aucune donnée ou sous-
ensemble de données de la partie gauche assurant une
dépendance fonctionnelle vers le même but. Par définition les
dépendances fonctionnelles à deux rubriques sont toujours
élémentaires.

code_produit →nom_produit est élémentaire (deux rubriques).

(no_facture, code_produit) →qte_facturee est élémentaire (ni le
code produit seul, ni le numéro de facture seul permettent de
déterminer la quantité).
(no_facture, code_produit) →nom_article n’est pas élémentaire
puisque le code du produit seul suffit à déterminer le nom du
produit.
97
5-4. MCD- Graphe de
dépendances fonctionnelles
Typologie

❑ Dépendance fonctionnelle directe

Une df d1 → d3 est directe s’il n’existe aucune donnée d2 qui
engendrerait une dépendance fonctionnelle transitive telle que
d1 → d2 → d3
Soient les dépendances fonctionnelles :
no_facture → no_representant ;
no_representant → nom_representant
no_facture →nom_representant
n’est pas une dépendance fonctionnelle directe puisque obtenue
par transitivité.

98
5-4. MCD- Graphe de
dépendances fonctionnelles
Construction du GDF

Ce graphe des DF est une représentation graphique des DFs

entre les données.

99
100
 5-4. MCD
Modèle Entité/Association
Les concepts de base du modèle E/A

Entité :
Une entité est un objet abstrait ou concret de l’univers du
discours.
Une entité peut être :
• Une personne (CLIENT)
• Un lieu (DEPOT, BUREAU, ATELIER, …)
• Un objet documentaire ( LIVRE, OUVRAGE, DOSSIER,…)

Identifiant :
▪ C’est une propriété particulière de l’entité; représentation de
l’une des occurrences de l’entité ou de l’association.
▪ Le meilleur moyen pour ne pas risquer d’avoir des synonymes
consiste à prendre des numéro de références comme
identifiant.
101
5-4. MCD
Modèle Entité/Association
Les concepts de base du modèle E/A

Identifiant :
• Un identifiant peut être simple c.à.d. constitué d’une seule
propriété élémentaire (d’ordre 1) : NUM_ELEV.
• Un identifiant peut être constitué de plusieurs propriétés
élémentaires: d’ordre 2, 3 ou 4

Les occurrences d’une entité:

• Une occurrence ou tuple est une réalisation particulière de
l’entité ou un exemplaire de l’entité.
• L’ensemble des occurrences forme l’entité désignée.

102
5-4. MCD
Modèle Entité/Association
Les concepts de base du modèle E/A

les associations :
• Une association est un lien sémantique entre plusieurs entités
indépendamment de tous traitements.
• Une association est souvent nommé par un verbe qui exprime
le sens du lien entre les entités.
• Les liens logiques existant entre deux entités sont appelés
Associations.

Par exemple, on peut considérer qu’il existe une association

Enseigner entre l’entité instituteur et élève dans le cas d’une
école.

103
5-4. MCD
Modèle Entité/Association
Les concepts de base du modèle E/A

Attributs d’associations
Une association peut être caractérisée par des attributs.
ex. date de la commande et quantité de produits commandés

Cardinalités d’associations
Cardinalité d’une assoc. : nombres minimum et maximum de
participations de chaque occurrence d’entité à l’association.

ex. un client doit commander au moins un produit ; un produit

peut être commandé par zéro ou un nombre quelconque de
clients
En fonction des cardinalités maximales, une association binaire
(degré = 2) peut être de type 1-1, 1-N ou N-M
104
5-4. MCD
Modèle Entité/Association
Les concepts de base du modèle E/A

Cardinalités d’associations Typologie des associations binaires

105
5-4. MCD
Modèle Entité/Association
Les concepts de base du modèle E/A

Les cardinalités sont élément essentiel pour définir la sémantique des

données, pas une « décoration » accessoire. Derrière cette notion on trouvera
des contrôles (par le SGBD ou les programmes)

Pour une situation donnée, il n’existe pas une «solution» unique.

Un modèle exprime un point de vue et reflète des besoins en information.
Le bon modèle est celui qui est accepté par les personnes concernées
par le projet.

106
 5-5. MCD -Règle sur les entités
1) Règle de l’identifiant: Toutes les entités ont un identifiant.
2) Règle de vérification des entités: Pour une occurrence d’une
entité, chaque propriété ne prend qu’une seule valeur (cf. la
1FN du modèle relationnel); MONO-VALUEE

On décompose l'entité Employé en deux entités : Employé, et Enfant

107
5-5. MCD -Règle sur les entités
3) Règles de normalisation des entités
Les dépendances fonctionnelles (DF) entre les propriétés d’une
entité doivent vérifier la règle suivante : toutes les propriétés
de l’entité dépendent fonctionnellement de l’identifiant et
uniquement de l’identifiant.

Rappel :  une DF X→Y si à une valeur de X correspond une et une seule

valeur de Y (réciproque pas vraie).

La DF: N°insee → Nom, Adresse contredit la règle.

108
5-5. MCD -Règle sur les entités
3) Règles de normalisation des entités
Une partie de l’identifiant ne peut pas déterminer certaines
propriétés. .

La DF n°-comm → date-comm, n°-client contredit la règle. On décompose

l’entité Commande en deux entités. Ces règles correspondent aux 2FN et
3FN du modèle Relationnel (dépendance pleine et directe des clés).
109
5-6. MCD -Règle sur les
associations
Règle de vérification des associations
Pour une occurrence d’association, chaque propriété ne prend
qu’une seule valeur.

Règle de normalisation sur les propriétés des associations

Toutes les propriétés de l’association doivent dépendre
fonctionnellement de tous les identifiants des entités portant
l’association, et uniquement d’eux.

N°-insee → Date-permis pose problème (donc déplacer Date-

permis vers Personne)

110
 5-6. MCD -Règle sur les
associations
Une éventuelle DF N°prof → N°mat donne la décomposition :

C’est le cas, quand une patte a une cardinalité 1,1.

Par exemple à 1 contrat est associé un client et un local :

111
5-6. MCD -Règle sur les
associations
La décomposition des associations n-aires
Il faut garder un minimum d’associations d’arité > 2. Si on
observe une DF entre un sous-ensemble des entités d’une
association, on peut la décomposer en deux associations (on
parle aussi de ‘contrainte d’intégrité fonctionnelle’ ou CIF).

Une éventuelle DF N°prof → N°mat donne la décomposition :

112
 5-6. MCD -Règle sur les
associations
La suppression des associations transitives
Toute association pouvant être obtenue par transitivité de n
autres associations peut être supprimée.

On supprime l'association associée_a, car elle peut être obtenue

par transitivité sur les associations concerne et obtenue_par
113
5-6. MCD -Règle sur les
associations
❑ Règle 1
Deux entités qui doivent être reliées entre elles le seront
par le biais d’une relation

114
5-6. MCD -Règle sur les
associations
❑ Règle 2
Deux relations ne peuvent jamais être directement reliées
entre elles

115
5-6. MCD -Règle sur les
associations
❑ Règle 3
Le nom de la relation doit représenter d’une manière
concrète et significative l’information que l’on veut obtenir

116
5-6. MCD -Règle sur les
associations
❑ Règle 4
Un attribut est unique à une entité ou à une relation

117
5-6. MCD -Règle sur les
associations
❑ Règle 5
Les entités et les relations ne doivent contenir que des
données élémentaires, donc ne pas contenir des résultat de
calcul/traitement

118
5-6. MCD -Règle sur les
associations
❑ Règle 6
Pour une occurrence donnée, une seule valeur doit être attribuée
à chaque attribut de l’entité ou de la relation

119
5-6. MCD -Règle sur les
associations
❑ Règle 7
Pour une occurrence donnée, une seule valeur doit être attribuée
à chaque attribut de l’entité ou de la relation

120
5-6. MCD -Règle sur les
associations
❑ Règle 8
Chaque fois qu’un attribut est un code ou un type, on forme
une nouvelle entité avec ce code/type et sa description

121
5-6. MCD -Règle sur les
associations
❑ Règle 9
Lorsqu’une relation peut être déduite des autres relations,
elle n’est pas représentée à moins qu’on veuille extraire une
information spécifique à cette relation

122
5-6. MCD -Règle sur les
associations

123
5-6. MCD -Règle sur les
associations
❑ Règle 10
Seule une association de type plusieurs à plusieurs (N:M)
peut avoir des attributs
▪ Si vous avez des attributs sur une relation 1:N, il y a un
problème !
▪ L’attribut doit être placée sur une entité
▪ L’attribut doit être éliminé (ex. valeur calculée)
▪ Note : Une relation N:M n’a pas obligatoirement des attributs

124
5-6. MCD -Règle sur les
associations

12
 5-6. MCD – démarche
Une démarche de construction ?

Certains auteurs suggèrent la démarche suivante :

1 Analyser l'existant et constituer le dictionnaire des données
2 Épurer les données (éliminer synonymes et polysèmes)
3 Dégager les ‘entités naturelles’ grâce aux identifiants existants déjà dans
l’organisation
4 Rattacher les propriétés aux entités
5 Recenser les associations entre entités et leur rattacher leurs éventuelles
propriétés
6 Déterminer les cardinalités
7 Décomposer si possible les associations n-aires (cf. règles)
8 S'assurer de la conformité du modèle aux règles de construction (cf. règles)
9 Normaliser le modèle : s'assurer qu'il est en 3FN
126
 5-6. MCD – démarche
Une démarche de construction ?
Malheureusement, dans le monde réel, il n’y a pas d’énoncé !
L’existant n’est pas complètement connu au départ, ni toutes les
données. Imaginer avoir un dictionnaire exhaustif au départ
n’est pas réaliste dans les cas complexes.

Il n’y a donc pas une suite linéaire d’étapes mais plutôt un ensemble
d’itérations :
- ébaucher un modèle avec les entités et associations qui semblent
essentielles,
- évaluer si ce qui est modélisé est correct et correspond à ce que
les utilisateurs comprennent,
- itérer en complétant progressivement jusqu’à ce que le modèle
semble raisonnablement complet
-
127
 5-7. MCD – Exercice
Exercice 1
Une banque désire posséder un SGBD pour suivre ses clients. Elle
désire ainsi stocker les coordonnées de chaque client (nom,
prénom adresse), et les comptes dont elle dispose ainsi que leur
solde (sachant par ailleurs que certains compte ont plusieurs
bénéficiaires). On stockera également les opérations relatives à
ces comptes (retrait et dépôt, avec leur date et le montant).

127
5-7. MCD – Exercice
1:n 1:n 0:n
bénéficie Comptes
Clients
NoClient Code

Nom
Solde
Prénom
Adresse Concerne

Opérations
Id_op 1:1

Type

Date

montant

127
VI- Le modèle Logique de
données (MLD)
6-1. MLD
❑ Plus proche du modèle physique.
❑ Ne contient que des tables qui possèdent des propriétés et
une ou plusieurs clés primaires.
❑ Toutes les tables ont un nom unique.

Pour les entités. Toute entité devient une table et conserve

ses propriétés et sa clé.
Pour les associations. Dépend des cardinalités. Deux grand cas
possibles :
Relation (1,1) à (?,?)
la relation est matérialisée par l’ajout d’une clé étrangère
Relation (?,n) à (?,n)
la relation donne lieu à la création d’une table

131
 6-1. MLD
❑ Une relation ternaire devient une table si les cardinalités
sont 1:n sur toutes les branches, sinon on place les références
dans la table reliée à une cardinalité 1:1
❑ Si plusieurs relations existent entre deux entités, on les traite
séparément
❑ Les cardinalités k:k sont à traiter comme k relations 1:1
❑ Si deux entités sont reliés par une relation de type
1:1 1:1

❑ il faut probablement les fusionner en une table.

❑ Supprimer les tables inutiles ! (tables à un seul champ)

132
6-2. MLD - Exercice
1:n 1:n
Œuvres écrit Auteurs
NoOeuvre NoAuteur
1:n
Titre Nom
Prénom
édition
1:n
Editions 1:n Editeurs
1:1
ISBN édite NoEditeur

Titre Nom

0:n
Exemplaires
1:1
Stocks Ref_livre
Etat

Question : Trouvez le MLD équivalent… 133

6-2. MLD - Exercice