Systèmes d’Information I

Manuel & Applications

DUT I

INSTITUT UNIVERSITAIRE DE TECHNOLOGIE

Département Génie Informatique
Dr Amougou Ngoumou, Ph.D.,
P.0. Box 8698 Douala - Cameroun Chargé de Cours
 Descriptif du cours

Code EC GI161
Intitulé EC Système d’Information I
Parcours DUT
Niveau 1
Semestre 2
Nombre d’heures 60
• Maîtrise satisfaisante du raisonnement logique ;
Pré requis du cours • Bonne familiarité avec le principe d’abstraction.

Le cours étudie les notions d’information et de système

d’information ; l’analyse et la modélisation des processus sont
Description du cours introduites. En s’appuyant sur la méthode MERISE, le cours insiste sur
les modèles conceptuels des données en se servant d’exemples tirés des
domaines métiers.
A la fin du cours, l’étudiant doit être capable :
• De comprendre la place et le rôle du système d’information
dans une organisation ;
Objectifs du cours • De mettre en œuvre la démarche d’informatisation ;
• D’aborder l’analyse et la modélisation des processus ;
• D’élaborer des dictionnaires de données ;
• De produire des modèles conceptuels des données.
Le cours est articulé autour des notions suivantes :
• L’information et le système d’information de l’organisation ;
Contenu du cours • Introduction à l’analyse et à la modélisation des processus ;
• Présentation générale de MERISE ;
• Le modèle conceptuel des données.
• 1 heure 30 minutes de cours magistral par semaine ;
Format du cours
• 1 heure 30 minutes de travaux dirigés par semaine.
• Annelise Couleau-Dupont, "Systèmes d’information de gestion :
manuel et applications", Nathan, Paris, France, 2008.
• Annelise Couleau-Dupont, "Systèmes d’information de gestion :
Corrigés des applications", Nathan, Paris, France, 2007.
• Pierre-Alain GOUPILLE, Jean-Marc ROUSSE, "Analyse
Informatique pour les I.U.T. et B.T.S.", MASSON, 1993 ;
• Des fiches de travaux dirigés sont éventuellement délivrées aux
étudiants.

Livres à la bibliothèque de l’IUT de Douala

Ressources pédagogiques

• Robert Rise, "Système d'information et management des

organisations", 4e édition ;
• Solginger Jackson - Simon Villeneum, "Analyse et conception
des systèmes d'information" ;
• Yves Frederic LIVIAN, "Introduction à l'Analyse des
organisations" ;
• Nacer BOUDJLIDA, "Bases De Données et Systèmes
d'Information - Le Modèle Relationnel".

2
 Chapitre 1. L’INFORMATION ET LE SYSTEME D’INFORMATION

Ce chapitre a pour objectif de faire découvrir, dans un premier temps, la notion

d’organisation à travers l’approche systémique ; dans un deuxième temps, le système
d’information est décrit à travers différents axes : fonctions, rôle, composants, critères de
classification. Toutefois, un système d’information n’a de raison d’être que s’il dispose de la
matière première : l’information. Ce thème sera étudié dans un troisième temps, avec la
mise en évidence de ses caractéristiques et de ses qualités.

1. La théorie systémique des organisations

Un système est un ensemble d’organes, de procédures et d’idées, organisé en vue de la réalisation
d’un objectif commun et distinct de son environnement (L. von Bertalanffy, 1951).
Une organisation est un système ouvert, finalisé, régulé, et composé d’un ensemble de sous-
systèmes en interaction pour assurer l’exercice de ses activités.
Exemple : une entreprise (ou organisation marchande), une association, une administration, un
laboratoire de recherche, etc.

1.1 L’organisation et ses composants

L’organisation est un système. Comme tout système, elle se caractérise par différents composants.

1.1.1 La structure
La structure d’une organisation est composée d’éléments matériels (locaux), incorporels (fonds de
commerce) et humains (personnel).

1.1.2 Le réseau de flux

Le réseau de flux d’une organisation comporte :
- Des flux physique (achat ou vente de biens ou de services) ;
- Des flux financiers (règlements des opérations d’achat et de vente) ;
- Des flux d’information (informations contenues dans les documents commerciaux, les notes de
service) reliant les différents éléments et réalisant l’unité de l’organisation.

1.2 L’organisation comme système ouvert

L’organisation est un système ouvert, en relation avec son environnement, qu’il soit économique,
technique, institutionnel, culturel, etc.

1.3 L’organisation comme système finalisé

L’organisation est un système finalisé, ayant des buts précis et des objectifs propres (maximisation
du profit, croissance, satisfaction des usagers) distincts de ceux des membres (personnel, dirigeants).

1.4 L’organisation comme système régulé

3
 L’organisation est un système régulé, s’adaptant en permanence pour atteindre les objectifs fixés,
que se soit par autorégulation ou grâce à l’existence d’organes de commande (direction).

1.5 L’organisation et ses sous-systèmes

L’organisation est composée de sous-système en interaction (figure 1.1). Toutefois, chaque
organisation crée ses propres sous-systèmes (il n’existe pas de liste exhaustive des sous-systèmes),
distingués ci-après.

1.5.1 Le système opérant

Le système opérant (ou opératoire) assure le fonctionnement du système en réalisant la production

physique des biens et des services. Il est relié à l’environnement par des flux externes et aux autres
sous-systèmes par des flux d’information. Son activité est contrôlée par le système de décision.

1.5.2 Le système de décision

Le système de décision (ou de pilotage ou de management) finalise l’organisation en lui fixant ses
objectifs. Il est relié aux autres sous-systèmes par les flux internes d’information. Il analyse
l’environnement et le fonctionnement interne de l’organisation. Il contrôle l’exécution des tâches du
système opérant et assure la régulation du système.

1.5.3 Le système d’information

Le système d’information fournit aux membres de l’organisation une représentation de l’état et du

fonctionnement de celle-ci face à son environnement. Pour cela, il collecte, mémorise, traite et
communique les informations aux autres sous-systèmes.
L’analyse systémique est une analyse en termes de flux mettant en évidence les interactions entre
les différents sous-systèmes et entre l’organisation et son environnement (figure 1.1).

Environnement
Organisation

Système de décision

Système d’information

Système opérant

Flux d’information :

Figure 1.1 - Flux d’information et sous-systèmes

4
 2. Le système d’information

Le concept de système d’information (SI) a émergé aux États-Unis dans les années soixante en
prenant le nom de Management Information System (MIS).

2.1 Définition
Un SI est un ensemble organisé de ressources : matériel, logiciel, personnel, données, procédures
permettant d’acquérir, de traiter, de stocker, de communiquer des informations (sous forme de données,
de textes, d’images, de sons, etc.) dans les organisations.

2.2 Les fonctions du système d’information

Généralement, on attribut quatre fonctions au système d’information : acquisition de l’information,
mémorisation de l’information, traitement de l’information et diffusion de l’information.
2.2.1 L’acquisition de l’information
L’acquisition de l’information est réalisée par collecte et saisie. Cette étape peut être réalisée
manuellement ou être automatisée.
2.2.2 La mémorisation (ou le stockage) de l’information
La mémorisation de l’information correspond à l’enregistrement de cette dernière sous la forme de
fichiers et de bases de données. En effet, une fois saisie, l’information doit être stockée de manière
durable et stable.
2.2.3 Le traitement de l’information
Le traitement de l’information correspond à la transformation du contenu ou de la forme de
l’information par des programmes informatiques ou des interventions manuelles. L’information est
traitée en vue de répondre aux objectifs de l’organisation.
2.2.4 La diffusion (ou la communication) de l’information
Une fois traitée, l’information doit être diffusée aux différents acteurs ou aux différentes fonctions de
l’organisation.

2.3 Le rôle du système d’information

Le système d’information contribue au pilotage de l’organisation ou de ses activités en fournissant de
l’information pour le management. Il aide ainsi à la prise de décision. Il permet de contrôler l’évolution
de l’organisation par la détection des dysfonctionnements et des anomalies internes. Il a également pour
finalité de coordonner l’activité des différentes composantes de l’organisation (système opérant et
système de décision).

2.4 Le système d’information et ses composants

Un système d’information est constitué de différentes ressources : les personnes, le matériel, les
logiciels, les procédures et les données.
Le système d’information n’est pas assimilable au système informatique, qui n’en n’est qu’une partie.
Le système informatique est un support du système d’information ; il prend en charge l’information
numérisée et les traitements automatisés.
2.4.1 Les moyens humains
Les moyens humains sont composés de l’ensemble des personnes intervenant au niveau du système
d’information.
Exemple : Les utilisateurs, qui, pour l’exécution de leurs tâches, « consomment » l’information
produite par le système d’information, contribuent à l’acquisition, au stockage, au

5
 traitement et à la communication d’informations. Les spécialistes des systèmes
d’information, dont la fonction exclusive consiste à concevoir, implanter, faire fonctionner
le système d’information.

2.4.2 Les moyens matériels

Les moyens matériels sont constitués des dispositifs physiques de degré de technicité plus ou moins
poussé permettant de recevoir, manipuler, émettre l’information. Ils comprennent également les
différents supports de l’information.
Exemple : dispositifs physiques : les ordinateurs, les moyens de communication, les photocopieurs.
Supports : papiers, magnétiques, optiques.
2.4.3 Les logiciels et procédures
Les logiciels correspondent à l’ensemble des programmes d’application et de service nécessaires au
fonctionnement du système d’information (s’il est informatisé). Les procédures décrivent, quant à elles,
l’articulation entre les traitements manuels et automatisé.
Exemple : procédure de traitement des achats.
2.4.4 Les données
Les données existent sous des formes variées (mots, nombres, images, sons, etc.).
2.5 La typologie des systèmes d’information
Un système d’information peut se décomposer selon quatre critères : le degré de formalisation des
moyens, le degré d’automatisation, le nombre d’utilisateurs, et le niveau de décision. Le tableau 1.1 ci-
après présente les caractéristiques du système d’information pour chaque critère.

6
Critères Composantes Caractéristiques

Degré de SI formel Information structurée sous forme écrite.

formalisation
Exemple : SI comptable (écritures comptables)
des moyens
(procédures,
documents, etc.) SI informel Absence de règles précises de présentation de l’information.
Exemple : les discussions téléphoniques.

Degré SI manuel Opérations sur les informations réalisées par l’homme sans
d’automatisation recours aux machines.
des traitements
SI mécanisé Certaines opérations sur les informations sont réalisées avec
des machines non programmables. Exemple : réalisation de
devis avec une machine à écrire et une machine à calculer.

SI automatisé Opérations sur les informations réalisées par l’ordinateur.

Nombre SI individuel Satisfait les besoins d’un individu à son poste de travail.
d’utilisateurs
SI collectif Permet à un ensemble d’individus de l’entreprise de
travailler à des tâches communes.

SI Permet l’échange d’informations entre individus

interorganisationnel appartenant à des organisations différentes.

Niveau de SI de direction Aide à la planification stratégique.

décision
Destiné au personnel de direction de l’entreprise.
L’information, très synthétique vise le moyen et le long
termes.

Système d’aide à la Aide à la planification et au contrôle tactique.

décision
Destiné au personnel de l’encadrement.
Informations à court terme (1 à 12 mois)

SI pour la gestion Aide à la gestion courante, au contrôle opérationnel.

opératoire
Destiné au personnel exécutant.
Informations très précises et à très court terme.

2.6 La classification des systèmes d’information

Les systèmes d’information peuvent être classifiés en grandes catégories : les systèmes de traitement
des transactions, les systèmes d’information de gestion, les tableaux de bord de gestion, et les systèmes
d’information d’aide à la décision.

2.6.1 Les système de traitement des transactions

Les systèmes de traitement des transactions traitent les données qui proviennent des transactions
que l’organisation effectue avec ses clients, ses fournisseurs, ses créanciers et ses employés. Ils
produisent aussi les documents et pièces qui témoignent de ces opérations. Ils sont responsables de
l’emmagasinage de toutes les données qui permettent le suivi des activités de l’organisation.
Exemple : système de paye, système de prise de commande, système de facturation, etc.

2.6.2 Les système d’information de gestion

7
 Les systèmes d’information de gestion ont pour but de soutenir les activités des gestionnaires de
l’organisation, qu’elles se situent au niveau du contrôle des opérations, du contrôle de gestion ou de la
planification stratégique. Ils reposent souvent sur les bases de données créées par les systèmes de
traitement des transactions, bien qu’ils aient aussi des sources de données externes à l’organisation. Ils
consistent généralement en des rapports remis à des gestionnaires, de façon périodique ou sur
demande, qui résument la situation d’un aspect particulier de l’organisation. Ces rapports sont souvent
comparatifs ; ils opposent une situation présente à une situation qui avait été prévue, des données
présentes à des données historiques, et des données concernant des entreprises du même secteur
économique.
Puisque ces systèmes reposent en grande partie sur les données produites par les systèmes de
traitement des transactions, la qualité de l’information qu’ils produisent est largement tributaire du
bon fonctionnement de ces derniers.

2.6.3 Les tableaux de bord de gestion

Les tableaux de bord de gestion sont des systèmes conçus pour fournir de l’information de façon
sommaire et ciblée. Ils sont constitués d’un certain nombre d’indicateurs essentiels et pertinents. Ils
mettent en évidence les résultats significatifs, les exceptions, les écarts et les tendances.
Le tableau de bord de gestion partage le même objectif que le système d’information de gestion.
Cependant, dans le cas de ce dernier type de système d’information, l’accent est mis sur le repérage et la
localisation des problèmes.

2.6.4 Les système d’information d’aide à la décision (SIAD)

Les systèmes d’information d’aide à la décision (SIAD) sont des systèmes conçus dans l’objectif
explicite de soutenir les activités de prise de décision. Le processus de prise de décision est composé de
grandes phases :
- l’identification du problème ;
- l’élaboration et l’évaluation de scénarios de solution ;
- le choix d’une solution.
En principe, un SIAD doit fournir l’information permettant aux décisionnaires d’identifier une
situation impliquant une prise de décision. De plus, il doit être pourvu de capacités de modélisation
pour permettre la génération et l’évaluation de scénarios de solution. Ce sont en général des systèmes
interactifs, qui ont accès à une ou plusieurs bases de données et qui utilisent un ou plusieurs modèles
pour représenter et évaluer une situation.

2.6.5 Les systèmes experts

Les systèmes experts (ou systèmes de base de connaissances) trouvent leur origine dans la recherche
en intelligence artificielle. Ils résultent d’un effort qui vise à représenter par des moyens informatiques
les connaissances d’un expert dans un domaine donné.

3. L’information
Dans l’usage courant, les termes « données » et « information » sont souvent considérés comme
synonymes. Cependant, si on est précis, il apparaît que la donnée ne devient une information que
lorsqu’elle est reçue par un être humain qui l’interprète.

8
 3.1 Définition
Une information est une donnée observée par un acteur. L’observation implique la comparaison à
d’autres données pour qu’il y ait interprétation. Passer du rang de données à celui d’information
suppose que la connaissance de la donnée contribue à l’action de celui qui l’observe. Les données (mots,
nombres, images, sons, etc.) constituent la matière première de l’information par un processus
d’interprétation qui leur attribue de la signification, du sens.
L’information est un élément de connaissance susceptible d’être représenté à l’aide de conventions
pour être conservé, traité ou communiqué.

3.2 Les caractéristiques

L’information a des caractéristiques de forme, de contenu, de coût et de valeur.

3.2.1 Les caractéristiques de forme

Tableau 1.1 - Les caractéristiques de forme de l’information

Caractéristique Exemple

Ecrite/picturale Le plan d’un bâtiment est une information picturale, écrite.

Orale/visuelle/ - L’annonce radio d’un message est une information orale.

olfactive/tactile/gustative - Une photographie est une information visuelle.
- Une odeur est une information olfactive.
- L’inscription en braille sur l’emballage d’un médicament est
une information tactile.
- Grâce à la dégustation d’un produit, on obtient une information
gustative.

Structurée/non structurée - La balance comptable est une information structurée.

- Une information notée comme « pense-bête » sur un document
vierge est non structurée.

Quantitative/numérique/ - L’âge est une information quantitative (une valeur mesurable)

contrairement à la date de naissance.
alphanumérique/alphabétique
- Une date, un poids sont des informations numériques
(exprimées uniquement par des chiffres).
- Un numéro minéralogique 200 ADC 06 est une information
alphanumérique (composée de lettres associées à des chiffres).
- Le nom d’une personne est une information alphabétique
(constituée uniquement de lettres).

3.2.2 Les caractéristiques de coût et de valeur

L’information est souvent appréhendée en termes de coût ou de valeur. Le coût de l’information

correspond au coût de collecte, de traitement, de stockage et de destruction, alors que la valeur de

9
l’information est appréciée au travers de sa capacité à réduire l’incertitude, à améliorer la décision et la
productivité.
Le coût n’est justifié que s’il est inférieur à la valeur de l’information.

3.3 La qualité de l’information

La qualité d’un information est appréciée au travers de son exactitude, de sa disponibilité et de sa

pertinence.
Pour être pertinente, elle doit être fiable, actuelle, licite, non redondante et en rapport avec le
problème traité.
Une information est disponible quand elle parvient au bon moment, au bon endroit et sous une forme
directement exploitable. La disponibilité d’une information est indissociable de son accessibilité : il ne
suffit pas qu’elle soit disponible, elle doit être utilisable avec des temps de réponse acceptables.
Une information est fiable quand elle donne une bonne représentation de la réalité. Elle est actuelle
quand elle correspond à une réalité du moment présent, et licite quand son usage est permis par le
droit. Une information est redondante lorsqu’elle existe en plusieurs exemplaires ou lorsqu’elle peut-
être obtenue à partir d’autres informations.
Exemple : L’âge d’un individu est une information redondante par rapport à la date de naissance : on
peut obtenir l’âge en réalisant un calcul entre une date donnée et la date de naissance.

4. Exercices
4.1 Les flux d’information
Dans une entreprise commerciale, on peut mettre en évidence les flux d’information suivants :
- 1. commande client ;
- 2. tarifs ;
- 3. préparation de la livraison ;
- 4. sortie de stock ;
- 5. facture client ;
- 6. statistiques des ventes ;
Représenter les flux d’information.

4.2 Informations, traitements et résultats des traitements

M. Mveng Amougou, comptable de la société Ekang, doit expédier une facture aux établissements
Tchuente. Ceux-ci ont commandé 10 m2 de sable Sanaga à 30000 FCFA HT le m3 et 50 sacs de ciment
blanc à 6000 FCFA HT le sac. Le taux de TVA applicable à ces produits est le taux normal.
1. Quelles sont les informations nécessaires à M. Mveng Amougou pour établir la facture ?
2. Quels sont les traitements auxquels seront soumises ces informations ?
3. quels sont les résultats de ces traitements ?

4.3 Repérer des informations pertinentes

Vous réaliser un stage d’études au sein de la SARL Du Mfoundi et on vous confie la tâche d’analyser
des documents internes existants. La fiche « salarié » (document 1) vous est soumise pour examen.

10
 Signaler dans le tableau d’analyse (document 2) les informations qui ne sont pas
pertinentes dans le gestion des salariés.

DOCUMENT 1 FICHE « SALARIE »

SARL DU MFOUNDI
Fiche « salarié »

Nom : Date de naissance :

Prénom : Âge :

N° de téléphone

Adresse personnelle :

Rue :

Code postal : Ville :

Situation familiale (1) :

Célibataire Marié(e) Divorcé(e) Veuf(ve) Concubin(e)

Nombre d’enfants :

Religion

Combien de téléviseurs possédez-vous ?

Date d’entrée dans l’entreprise : / /

Qualification actuelle : Poste occupé :

Vous plaisez-vous dans l’entreprise (1) ? : oui non

Pensez-vous que votre supérieur hiérarchique est compétent (1) ? : oui

non
(1) Cochez la case correspondant à votre situation ou à votre réponse.

DOCUMENT 2 ANALYSE DE LA FICHE « SALARIE »

Information Pertinence (oui/non) Motif de la non-pertinence

Nom

Prénom

Date de naissance

Âge

Numéro de téléphone

Adresse personnelle

Situation familiale

Nombre d’enfant(s)

Religion

Nombre de téléviseurs possédés

Date d’entrée dans l’entreprise

Qualification actuelle

Poste occupé

Vous plaisez-vous dans l’entreprise ?

Compétence du supérieur hiérarchique

11
 Chapitre 2. INTRODUCTION A L’ANALYSE ET A LA
MODELISATION DES PROCESSUS

L’analyse d’un SI doit permettre de concevoir, à partir d’une situation donnée, un état souhaitable
du SI et de préparer sa mise en place. L’analyse dispose de nombreuses méthodes. En informatique,
la modélisation des données était jusqu’à présent au centre de toutes les méthodes de conception.
Aujourd’hui, la modélisation s’étend aux « processus ».
• L’analyse est la définition du problème à résoudre en termes de fonctionnalités et de qualités
attendues en prenant en compte les besoins des utilisateurs dans un domaine d’activité de
l’organisation qui peut être les ventes, la production, la logistique, les finances, les ressources
humaines, etc.
• La conception est la définition d’une solution informatique à travers la structuration des données,
l’organisation des traitements, la définition des postes de travail, les choix techniques en termes de
matériels, langages de programmation, logiciels de gestion de données (SGBD), etc.

1 Les composantes d’une méthode d’analyse

La conception d’un système d’information nécessite de réfléchir à l’ensemble de l’organisation à
mettre en place et oblige à recourir à des méthodes permettant de réaliser un modèle sur lequel on
va s’appuyer. Une méthode d’analyse se caractérise par quatre composantes principales : des
modèles, des langages de modélisation, une démarche, et des documents : le cahier des charges.

1.1 Les modèles

La modélisation est l’opération par laquelle on définit comment une partie du monde réel est
représentée.
Un modèle est une représentation simplifiée d’une réalité sur laquelle on veut être renseigné. Il
s’exprime avec un ensemble de concepts dotés de règles d’utilisation et de notation (souvent graphique).
En ACSI, les modèles servent à :
- communiquer : vérifier que l’analyste a bien compris les utilisateurs grâce à des modèles du
problème (modèles d’analyse) ;
- préparer la réalisation : grâce à des modèles de la solution (modèles de conception).

Figure 3.1 – Elaboration d’un modèle

ANALYSE

Application
Réalité Modèle du modèle
observable

Implantation des bases de

données, mise en œuvre des
traitements, etc.

12
 1.2 Les langages de modélisation
Un langage de modélisation est un ensemble de concepts et de règles permettant de construire des
modèles décrivant les systèmes d’information. L’utilisation d’un langage partagé par une communauté
d’acteurs facilite la communication, épargne les efforts d’explication des termes méthodologiques
employés et guide le modélisateur dans la sélection d’éléments clés à faire figurer.

1.3 Une démarche

C’est un processus opératoire par lequel s’effectue le travail de modélisation, de description et de
réalisation du système d’information.
Une démarche comporte en général les sept étapes suivantes :
- le schéma directeur ;
- l’étude préalable ;
- l’étude détaillée ;
- l’étude technique ;
- le développement ;
- l’implantation ;
- la maintenance.

1.3.1 Le schéma directeur

L’informatisation d’un système d’information se fait suivant un schéma directeur qui est un plan
stratégique destiné à piloter le développement de l’informatique dans l’entreprise. La durée de vie du
schéma directeur est comprise généralement entre deux et six ans.
L’objectif de cette étape est d’établir un pont entre la stratégie de l’entreprise et ses besoins en termes de
système d’information.
1.3.2 L’étude préalable
L’étude préalable permet d’élaborer différentes solutions pour le domaine étudié et d’en évaluer les
conséquences. Pour chacune des solutions sont précisés :
- le processus de fonctionnement du domaine ;
- le degré et le type d’automatisation ;
- le coût des moyens à mettre en œuvre ;
- les étapes et les délais ;
- les avantages et les contraintes de la solution ;
- la situation par rapport au schéma directeur.
Sur le plan de la démarche, il est important de noter qu’un bilan du système existant est réalisé au cours
de l’étude préalable avant de démarrer l’élaboration de solutions. Ainsi, avant le dossier de choix, un dossier
d’expression des besoins est produit au début de cette étape. Ses objectifs sont de :
• décrire les besoins réels des acteurs de la gestion en s’appuyant sur leur expérience,
• tenir compte de l’existant en termes de système d’information,
• faciliter la compréhension des besoins par l’équipe chargée de mener l’étude détaillée.

1.3.3 L’étude détaillée

13
 A cette étape, le futur système d’information est spécifié en tenant compte des choix réalisés dans l’étude
préalable.
Les différents modèles sont complétés et validés. Chacune des tâches à automatiser fait l’objet d’une
description complète en termes de support (écrans, impressions, etc.), d’algorithmes (règles de gestion, de
calcul, de contrôle, etc.), d’actions sur les données (mise à jour, consultation, etc.).
On procède à un ajustement des évaluations de moyens et de coûts estimés dans l’étude préalable.
Lors de cette étape, un dossier d’étude détaillée est produit.
1.3.4 L’étude technique
L’étude technique consiste en la traduction informatique des spécifications résultant de l’étude détaillée.
La structure informatique de la base de données, l’architecture des programmes, la structure de chaque
programme et les accès aux données sont définis.
La structure du dossier d’étude technique étant fortement dépendante de l’environnement, un plan type
pour ce document n’est pas proposé.
1.3.5 Le développement
Le développement consiste à définir quels seront les outils informatiques de haut niveau (langage de
développement, logiciels, progiciels) devant être mis en œuvre pour concrétiser la proposition de l’analyste.
1.3.6 L’implémentation
L’implémentation s’appuie sur une architecture matérielle qui met le système d’information à la
disposition des différents types d’utilisateurs. Elle consiste à traduire dans un langage de programmation
des fonctionnalités définies lors de la phase de conception.
1.3.7 La maintenance
La maintenance consiste à faire évoluer les applications en fonction des besoins des utilisateurs, de
l’environnement, des progrès technologiques.

1.4 Le cahier des charges

Le cahier des charges est un outil de communication, de structuration et de description des besoins
pour un projet déterminé. Il est rédigé en conformité avec le schéma directeur qui concerne l’ensemble
des projets à informatiser et leur planification.
1.4.1 Définition et objectifs
Un cahier des charges est un document visant à définir exhaustivement les spécifications de base
d’un produit ou d’un service à réaliser. Il décrit également les modalités d’exécution, les objectifs à
atteindre et vise à cadrer une mission.
En interne, le cahier des charges sert à formaliser les besoins et à les expliquer aux différents
acteurs pour s’assurer que tout le monde est d’accord. Il sert ensuite à sélectionner les fournisseurs
(concepteurs de logiciel, distributeurs de matériel, etc.) et à organiser la relation tout au long du projet.
Il est considéré comme un référentiel contractuel partagé par le prestataire et l’équipe interne. C’est
l’outil fondamental de communication du chef de projet.
1.4.2 Composition du cahier des charges
Le cahier des charges comporte un certain nombre de rubriques qui peuvent être adapté au type de
produit ou de service décrit par ce document.
Les principales rubriques sont :
- contribution du produit ou du service dans l’organisation : ces éléments sont définis dans le schéma
directeur (ex. : performances attendues du produit ou du service) ;
- personnels visé par le produit ou le service (ex. : personnel du service des ressources humaines) ;

14
 - objectifs généraux du produit ou du service et options possibles : il s’agit des finalités du produit ou
du service (ex. : outil devant permettre la télétransmission des bulletins de notes) ;
- apports du produit ou du service pour l’organisation et pour les utilisateurs (gains en termes
techniques, financiers, organisationnels, etc.) ;
- contraintes à respecter : contraintes liées à l’environnement d’utilisation (ex. : installation
d’ordinateurs dans des lieux ou la température atmosphérique peut être très élevée), contraintes
liées aux modalités d’utilisation (ex. : solution nomades pour les commerciaux), contraintes liées au
personnel (ex. : compétences) ;
- descriptif du produit ou du service (pour du matériel informatique, par exemple : performances,
types de matériel, possibilités d’évolution, etc.) ;
- matériel nécessaire pour utiliser le produit ou le service ;
- délais ;
- documentation (ex. : support papier, en ligne) ;
- maintenance ;
- formation ;
- coût du produit ou du service : coût devant inclure la formation, le contrat de maintenance et les
mises à jour pour les logiciels.

2. L’approche orientée processus

On assiste à un glissement d’une situation traditionnelle où le système d’information se construisait

autour des applications informatiques, à une situation où le système d’information s’organise autour
des processus de l’entreprise. Ce passage suppose un changement pour le système d’information, mais
aussi pour l’organisation de l’entreprise.
La responsabilité du système d’information passe de l’informatique aux métiers qui définissent son
contenu fonctionnel et maîtrisent sa modélisation.
L’informatique cesse d’être un centre de coût et devient un centre d’investissement au service des
métiers.
Dans l’approche « processus », la définition des applications qui reposait sur une interprétation du
travail à faire par les utilisateurs part de la question : « Comment travaille-t-on ? »
Tableau 3.1 – Comparaison des approches orientées « application » et orientées
« processus »

Organisation Approche orientée Approche orientée

« application » « processus »
Responsabilité du SI Informatique Métiers
Economie de l’informatique Centre de coût Centre d’investissement
Priorités de l’informatique Développement Soutien aux utilisateurs
Exploitation
Eléments du SI Applications Processus
Objets
Définition des applications « Expression des besoins » « Comment travaille-t-on ? »
Interprétation du travail à
faire

Ce n’est pas en analysant la structure de l’organisation, mais plutôt ce qui s’y passe, c’est-à-dire les
processus qui y sont effectués, qu’il est possible d’examiner le rôle de l’information et des systèmes
d’information qui soutiennent les processus.

15
 2.1 Définition et caractéristique des processus
Par processus, on entend un ensemble d’activités qui utilisent un ou plusieurs inputs, les
transforment pour obtenir un ou plusieurs outputs ayant un ou plusieurs destinataires. Un processus
est un ensemble d’activités entreprises dans un objectif déterminé. Une activité est un ensemble de
travaux devant être exécutés par des machines et/ou des êtres humains. Ces activités peuvent être des
activités de production, de communication ou de contrôle. L’objectif d’un processus est l’expression de sa
finalité.
Exemple : Les missions d’une société de services en informatique peuvent être traduites en
processus.
Cartographie des processus d’une SSII

Gestion du personnel

Gestion Gestion Gestion

Suivi
des des comptable et Gestion
des
prestations formations financière commerciale
résultats

Processus d’une SSII

Processus Objectif

Gestion des prestations Vendre une compétence

Gestion des formations Vendre une connaissance

Gestion commerciale Développer l’activité de l’entreprise

Gestion comptable et financière Fournir les documents légaux et maîtriser les finances

Gestion du personnel Maîtriser le facteur humain

Suivi des résultats Conduire la trajectoire de l’entreprise

Les processus sont conçus pour apporter une valeur ajoutée et réaliser les orientations de
l’organisation.
La responsabilité d’exécution de tout ou partie des activités par un acteur correspond à un rôle.
L’acteur est une personne physique, une entité organisationnelle ou une machine qui prend une part
aux activités du processus. L’acteur peut être interne ou externe à l’organisation.
Le déroulement du processus utilise des ressources et peut être conditionné par des événements
d’origine interne ou externe. L’agencement des activités correspond à la structure du processus.
Une ressource est un moyen, information ou outil, utilisé par une activité.
Un événement est un fait qui survient et qui provoque le déclenchement d’une activité.

Exemple : Une activité peut être déclenchée par une décision externe qui met fin à un projet.
Description de l’activité « Instruction de clôture ». Acteur : chef de projet. Evénement :
décision de clôture. Résultat : demande état des lieux émise.

2.2 Typologie des processus

16
 L’ensemble des processus par lesquels l’organisation produit et livre les biens et les services qu’elle
vend à ses clients constitue ce que l’on appelle « la chaîne de valeur ». La chaîne de valeur est composée
de deux types de processus :
- les processus de production, qui sont directement responsables de la production du bien ou de la
prestation de services à la clientèle (fabrication d’ordinateurs, par exemple) ;
- les processus d’affaires, qui jouent un rôle de soutien aux processus de production (la prise de
commande, la paye, le contrôle de la qualité, par exemple).
On peut procéder à une autre décomposition des processus :
- les processus opérationnels sont les processus de réalisation du produit ou les processus métier ;
- les processus fonctionnels sont les processus de pilotage et de support, et plus concrètement, les
processus de management des ressources et les processus de mesure, d’analyse et d’amélioration.
2.3 Lien entre processus et système d’information
Il existe un lien étroit entre processus et système d’information. En effet, le processus ne peut être
exécuté sans la présence du système d’information, et le système d’information n’a pas de raison d’être
sans la présence d’un processus (tableau 3.2 et 3.3).

Tableau 3.2 – Analyse comparative : processus et système d’information du traitement de

commandes

Elément de comparaison Processus Système d’information

Objectifs Préparer, emballer et expédier Assurer l’exactitude de la

rapidement et sans erreur les commande et de la facture.
commandes des clients Facturer rapidement

inputs Commande du client Commande du client

outputs Facture Facture

Bon d’expédition Bon d’expédition
Produits à expédier

Activités Enregistrer, autoriser, Enregistrer, autoriser,

compléter, emballer, expédier, compléter, emballer, expédier,
facturer facturer

Tableau 3.3 – Synthèse de l’analyse comparative

Elément de comparaison Processus Système d’information

Inputs et outputs Données, information, Données et information

produits

Activités Activités de traitement Activités de traitement de

d’information et activités l’information
impliquant d’autres
manipulations (ramassage de
produits dans un entrepôt,
chargement et déchargement
d’un camion de livraison etc.)

17
Composantes dont tiennent Inputs, outputs, activités, Inputs, outputs, traitements
compte les modèles ressources humaines et et dépôts de données
matérielles, lieux, temps

Objectifs Subordonnés aux objectifs de Subordonnés aux objectifs du

l’organisation processus

De fait, le système d’information est un sous-ensemble du processus : bien qu’étant une entité en lui-
même, il fait partie du processus. Processus et système d’information ont en commun un input (la
commande d’un client, par exemple) et un output (la facture, par exemple). Cependant, le processus a
un autre output que n’a pas le système d’information : les produits expédiés au client.
Processus et système d’information ont en commun un grand nombre d’activités, de tâches (saisir le
détail de la commande, vérifier le crédit, la disponibilité des stocks, facturer le client, etc.).
Cependant, le processus comporte des activités qui ne sont pas du ressort du système d’information
(ramasser les produits dans l’entrepôt, emballer la commande, par exemple).
Dans le cas d’un processus dont toutes les activités traitent de l’information, comme le processus de
paiement des factures aux fournisseurs, le sous-ensemble « système d’information » devient très
semblable à l’ensemble « processus ». Dans le cas où ce processus est entièrement informatisé, il n’existe
plus de différence entre le système d’information et le processus (commerce électronique, par exemple).
Ainsi, le projet d’amélioration d’un processus doit tenir compte du système d’information qui en est
le sous-ensemble. De même, le projet de développement d’un système d’information doit se préoccuper
du processus dont le système fait partie.
Le système d’information vise à assister l’utilisateur dans la réalisation des tâches liées aux
processus.
Modéliser un processus, c’est décrire la succession des tâches qui concourent à une production de
valeur ajoutée : ce que fait chaque acteur, les données qu’il manipule, les traitements qu’il ordonne, les
délais dans lesquels son travail doit être exécuté, etc.
La représentation des processus est motivée par le besoin de comprendre ce qui se passe au sein d’un
processus. Mais ce qui se passe est généralement complexe et ne faire une description complète est
impossible. Une solution partielle consiste à développer des modèles simplifiés des processus.

3. La modélisation des processus

La modélisation des processus permet de faire apparaître les éléments constitutifs d’un processus. Il
existe différents formalismes de modélisation, qui possèdent chacun leur propre vocabulaire. Toutefois,
il existe un ensemble de concepts liés à l’entité « processus » et à l’entité « activité » qui sont
indépendants des langages de modélisation qu’il convient de définir.

3.1 Les concepts liés à l’entité « processus »

3.1.1 Le concept de processus
Lors de la modélisation, le concept de processus retenu est celui d’un système dynamique orienté
vers la réalisation d’un objectif et d’un ensemble d’éléments en interrelation : activité, rôle, acteur,
résultat, ressources, etc.
3.1.2 Le processus global et le processus détaillé
Un processus global est un processus dont on ne veut représenter que l’objectif et, éventuellement,
une décomposition en processus.

18
 Un processus détaillé est un processus dont on a représenté la dynamique, en particulier les
activités.
Exemple :
Le processus global « Gestion des formations » peut être décomposé s’il est considéré comme un axe
stratégique de développement et peut donner lieu à quatre processus plus fins
Décomposition du processus global « Gestion des formations »

Processus Objectif

Gestion du catalogue Communiquer

Gestion des inscriptions Organiser

Gestion des sessions Réaliser

Suivi des participants Suivre

Le processus « Gestion du catalogue » peut être décomposé à son tour en quatre processus
Décomposition du processus « Gestion du catalogue »

Processus Objectif

Gestion du contenu Déterminer le contenu du catalogue

Gestion de la mise en forme Déterminer le format du catalogue

Fabrication Assurer la reproduction du

catalogue

Distribution Distribuer le catalogue

Les objectifs sont ainsi décomposés en objectifs plus précis. Lorsqu’on atteint un niveau suffisant
dans l’affinement des objectifs, on peut passer à une représentation détaillée. Ainsi, si le processus
« Gestion des sessions » ne peut pas être décomposé, on peut passer à la représentation de ses activités.
Par contre, le processus « Gestion du catalogue » pouvant être décomposé en quatre processus, ce sont
ces quatre processus qui seront analysés sous l’angle des activités.
3.1.3 Processus principal, secondaire, de pilotage
Les processus sont classifiés en processus principaux, secondaires et de pilotage. Un processus
principal est un processus dont l’objectif traduit la finalité du système du plus haut niveau auquel il
appartient.
L’objectif d’un processus principal correspond à une raison d’être de l’organisation ou du domaine
étudié.
Figure 3.2 – Cartographie des processus d’une SSII et classification des processus de
premier niveau

Gestion du personnel
(processus secondaire)

Suivi Gestion Gestion Gestion

des résultats des prestations des formations comptable et Gestion
(processus (processus (processus financière commerciale
de pilotage) principal) principal) (processus (processus
secondaire) secondaire)
19
 Un processus secondaire est un processus dont la contribution n’est pas considérée comme
stratégique. Il est indispensable, mais il ne correspond pas directement à une mission de l’organisation.
Il rend possible l’existence et/ou l’exécution de processus principaux.
Un processus de pilotage est un processus dont l’objectif est le contrôle d’autres processus. Il a pour
objectif de veiller à la bonne marche de tout ou partie d’une organisation.

3.2 Les concepts liés à l’entité activité

3.2.1 Le concept d’activité

Une activité est un ensemble de travaux correspondant à une unité d’évolution du système.
Exemple : Le processus « Gestion des sessions » peut être décomposé en trois activités : « Accueil des
participants » ; « Présentation » ; « Evaluation ».

3.2.2 Le concept d’acteur et de rôle

Le concept d’acteur a déjà été défini précédemment comme étant une personne physique, une entité
organisationnelle ou une machine qui prend part aux activités du processus. L’acteur peut être interne
ou externe à l’organisation. Au niveau de la modélisation, l’acteur sera considéré comme un élément
actif chargé d’une ou plusieurs activités dans le processus. Par ailleurs, le concept de rôle retenu est
celui d’un regroupement d’activités confiées à un acteur unique.
Exemple
Le processus « Gestion des inscriptions » comprend trois activités : « Saisie de la demande
d’inscription » ; « Validation de l’inscription » ; « Paiement de la session de formation ».
Trois rôles ont été identifiés et peuvent être tenus par des acteurs différents.

Rôles et acteurs du processus « Gestion des inscriptions »

Activités Rôles Acteurs

Client

Saisie de la demande d’inscription Opérateur de saisie

Agent commercial

Validation de l’inscription Contrôleur

Responsable commercial

Validation de la session de formation Payeur

Responsable comptable

3.2.3 La transition

Une transition est un lien orienté entre deux activités. Elle exprime une contrainte d’enchaînement
entre deux activités.

3.2.4 La tâche

Une tâche est le plus petit élément de décomposition d’une activité.

20
 3.2.5 L’événement

Un événement est un stimulus qui provoque une réaction dans une activité. Il peut être de plusieurs
types.

Tableau 3.4 – Typologie des événements

Type d’événement Description

Evénement spécialisé selon son origine
Evénement interne Il correspond à un stimulus généré à l’intérieur des frontières.
Celles-ci peuvent être les frontières du processus, les frontières du
domaine dans lequel s’inscrit le processus ou les frontières de
l’organisation.
Evénement externe C’est un stimulus sur lequel on n’a pas de prise : il est lié à un
acteur ou à un système extérieur.
Evénement temporel Il correspond à une échéance unique ou périodique, à laquelle on
associe une réaction de l’organisation.
Evénement spécialisé selon son effet
Evénement déclencheur Il provoque l’exécution de la première tâche de l’activité.
Evénement interrupteur Il conduit à terminer l’activité, même si toutes les tâches n’ont pas
été effectuées, ainsi que le processus.
Evénement modificateur Il fait changer le cours du processus.

3.2.6 Le résultat

Un résultat est un produit issu de l’exécution d’une activité. Un résultat peut devenir une ressource,
une entrée ou un événement interne pour une autre activité du processus.

3.2.7 L’entrée

Une entrée est un élément qui va subir une transformation lors de l’exécution de l’activité à laquelle
il est associé.

3.2.8 La ressource

Une ressource est un élément utilisé pour l’exécution d’une activité.

3.2.9 La condition
Une condition exprime une restriction dans l’exécution d’une tâche, le déclenchement d’une
transition ou l’effet d’un événement.

3.3 Les méthodes de modélisation.

3.3.1 Les années 60 (la préhistoire)
Cette époque se caractérise par l’automatisation d’un processus administratif ponctuel :
édition des factures, édition des bulletins de paie… Sur le plan de la technologie informatique,
on note les programmes en temps différé sur des lots de données (traitement 'batch') ; et les lots de
données sur bandes magnétiques (accès séquentiel uniquement). Au niveau de l’ACSI, Les résultats
proviennent des données et d’un enchainement de phases avec fichiers intermédiaires.

21
 Figure 3.3 : Traitement batch de la facturation

3.3.2 Les années 70 (le moyen âge)

Cette période se caractérise par l’intégration partielle des chaînes de traitement par partage
de fichiers (ex : facturation + comptabilité, facturation + stocks). Au niveau de la technologie
informatique, on note l’apparition des disques magnétiques (possibilité d’accès direct) et des gros
systèmes (multiprogrammation). L’ACSI est marquée par les méthodes fonctionnelles (SADT) avec
la décomposition des fonctions, jusqu’à des fonctions élémentaires facilement programmables ; les
fonctions et flots de données (diagramme de flots de données) ; et la programmation : COBOL + fichiers
séquentiels et directs.

Figure 3.4 : Décomposition fonctionnelle

3.3.3 Les années 80-90 (l’époque classique)

Cet intervalle d’années se caractérise par l’intégration complète des applications autour d’une
base de données, les traitements interactifs, et les applications d’aide à la décision. Au niveau
de la technologie informatique, on note les terminaux écran dans les services utilisateurs, les OS
multiutilisateurs et multitâches, et les SGBD. L’ACSI est marquée par les méthodes systémiques
(MERISE : Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise,
SSADM : Structured Systems Analysis & Design Method) avec la modélisation données et
traitement d’un SI ; l’utilisation des SGBDR (relationnel) et des L4G ; les ateliers de génie logiciel ; et les
gros projets.

22
 Figure 3.5 : Modélisation données et traitements d’un SI

3.3.4 Les années 2000 (l’époque moderne)

Cette période se caractérise par la répartition des traitements et des données sur des
machines en réseau. Au niveau de la technologie informatique, on note la généralisation des
terminaux graphiques/souris ; les réseaux locaux, étendus, mondial (Internet) ; les architectures
client/serveur, technologies du Web (intranets)… L’ACSI est marquée par les méthodes orientées
objets (UML) avec l’unification données-traitements, le développement incrémental et la réutilisation.

4. Exercices.
Les exercices de ce chapitre visent à permettre à l’étudiant de bien cerner les concepts de d’analyse
et de conception.

4.1 Processus opérationnels et processus fonctionnels

Déterminer les processus opérationnels et les processus fonctionnels correspondant à la cartographie

générale des processus présentée ci-après.

P1 P2 P3 P4 P5 P6 P7

Marketing

Service commercial

Bureau d’études

Approvisionnement

Production

Logistique

Ressources humaines

Comptabilité

P1 : processus de conception et de développement.

P2 : processus commercial.

23
 P3 : processus d’approvisionnement.
P4 : processus de production.
P5 : processus de stockage et de livraison.
P6 : processus de facturation.
P7 : processus de ressources humaines (recrutement, formation…).

4.2 Processus principaux, secondaires, de pilotage

La société PlusLogiciel édite, intègre et vend des solutions logicielles. La vente des logiciels se fait
soit en direct par un portail Internet, soit par des démarches téléphoniques et visites. La société est
organisée en six départements :
• le département commercial regroupe la force de vente, constituée de quinze commerciaux et
du responsable marketing. Ce département est placé sous la responsabilité du directeur
commercial ;
• le département après vente ;
• le département recherche et développement ;
• le département stock ;
• le département administratif.
La gestion de la relation client (GRC) et de la chaine de vente (CDV) de la société PlusLogiciel est
composée de quatre grands processus :

Processus Objectif

Gestion commerciale Organiser et réaliser la vente des produits et des prestations

de la société

Gestion des appels Assurer une assistance aux clients

Gestion des actions marketing Réaliser des actions concourant ad développement des ventes

Gestion des référentiels Gérer les informations relatives à l’offre de PlusLogiciel

(produits, tarifs et fournisseurs)

1. Déterminer les processus principaux et les processus secondaires de la gestion de la relation

client (GRC) et de la chaîne de vente (CDV).

La décomposition des processus a permis d’affiner les objectifs. Le processus « Gestion commerciale »
a été décomposé en trois nouveaux processus :

Processus Objectif

Prospection Générer des opportunités commerciales

Vente Réaliser des ventes

Suivi des ventes Surveiller le déroulement de la gestion

commerciale

24
 Le processus « Suivi des ventes » a été décomposé en trois activités :
• au niveau des commerciaux : collecte des informations et élaboration du tableau de bord ;
• au niveau de la direction générale : analyse des tableaux de bord ;
• au niveau du directeur commercial : définition d’actions.
2. Caractériser les trois nouveaux processus résultant de la décomposition du processus « Gestion
commerciale » en processus principal, secondaire ou de pilotage.
3. Déterminer les acteurs participant au processus « Suivi des ventes ».
4. Indiquer le rôle de la direction générale dans le processus détaillé « Suivi des ventes ».

4.3 Le management par les processus

1. Définir les termes « processus » et « processus métier ».

2. Définir ce que représente le concept de « management par les processus ».
3. Indiquer les différentes étapes d’une démarche de management par les processus.

4.4 L’analyse des besoins logiciels est sans aucun doute l’étape avec le plus de communication
intensive dans le processus logiciel. Pourquoi le cours de la communication échoue fréquemment ?
4.5 Il ya fréquemment des répercussions politiques quand l’analyse des besoins logiciels (et/ou
l’analyse du système) commence. Par exemple, les travailleurs peuvent penser que la sécurité de
l’emploi est menacée par le nouveau système automatisé. Qu’est-ce qui causent de tels problèmes ? Est-
ce que la tâche de l’analyste peut être conduite tel que les politiques soient minimisées ?
4.6 Discuter vos perceptions de la formation idéale et du background pour un analyste système.
4.7 Décrivez le "client" pour les développeurs d’applications, les constructeurs de produits
informatique et les constructeurs de systèmes. Soyez prudent ici, il peut exister plus dans ce problème
que vous pouvez imaginer en premier.
4.8 Est-ce vous concevez le logiciel quand vous "écrivez" un programme ? Qu’est-ce qui rend la
conception du logiciel différent du codage ?
4.9 Listez dix principes de conception logicielle.

25
Chapitre 3. LA MODELISATION DES DONNEES : METHODE MERISE

Une donnée peut être représentée de façon plus ou moins formalisée. L’objet de ce chapitre n’est
pas de décrire l’intégralité de la méthode mais de se consacrer a la modélisation des données en
étudiant le modèle conceptuel des données.

1. La méthode Merise
La méthode Merise (Méthode d’étude et de réalisation informatique par les sous-ensembles ou pour
les systèmes d’entreprise) est une méthode de conception, de développement et de réalisation de projets
informatiques. Elle repose sur des concepts de base qui donnent lieu à différents modèles qui seront
utilisés successivement afin d’aboutir à un système d’information fonctionnel reflétant une réalité
physique.
La méthode merise s’appuie sur deux principes majeurs : la séparation des données et des
traitements, et l’approche par niveaux d’abstraction.
1.1 La separation des données et des traitements
La méthode Merise d’analyse et de conception respecte la distinction des données et des
traitements et procède à une description sous forme de trois découpages par :
- les flux : les échanges ou la communication sont des flux entre systemes, notamment des flux
d’informations ;
- les traitements : les traitements des flux d’information décrivent les tâches à effectuer à la
réception ou pour l’émission d’un flux d’informations. Les traitements représentent l’aspect
dynamique du système d’information, c’est-à-dire ce qui est fait ;
- les données : la structure de mémorisation des informations est représentée sous une forme
qui permet un passage aisé vers les enregistrements informatiques. Les données
représentent l’aspect statique du système d’information : ce qui est.

La séparation des données et des traitements est un artifice utilisé par la méthode. Il est évident
que les données n’ont de sens qu’à travers les traitements et que les traitements ne fonctionnent pas
sans données.

1.2 Les niveaux d’abstraction

Le cycle d’abstraction est nécessaire pour isoler les éléments significatifs contribuant à la
description d’un système cohérent.

La méthode Merise repose sur une hiérarchie qui comprend trois niveaux d’abstraction, dont les
dénominations sont adaptées au contexte des données et traitements :
- premier niveau : le niveau conceptuel ;
- deuxième niveau : le niveau organisationnel pour les traitements et le niveau logique pour les
données ;
- troisième niveau : le niveau physique.

1.2.1 Le niveau conceptuel

Le niveau conceptuel correspond à la finalité de l’entreprise en explicitant sa raison d’être. Il

définit les fonction réalisées dans l’organisation. Il répond à la question : que fait l’organisation ? Il est
déterminé par son activité.
A ce niveau se détermine :
- pour les traitements : la succession des actions ;
- pour les données : la signification de chacune des données les unes par rapport aux autres.
1.2.2 Le niveau organisationnel et le niveau logique

26
 Le niveau organisationnel met en évidence les choix d’organisation en termes de choix
d’automatisation, de poste de travail (utilisateurs) et de chronologie des opérations. Il répond à la
question : qui fait quoi ? Les modèles organisationnels de traitement définissent ce que fait chaque
poste de travail.
Le niveau conceptuel et le niveau organisationnel représentent toute l’organisation.
Le niveau logique répond à la question : avec quoi ? L’objectif du niveau logique est la définition des
moyens informatiques à disposition des postes de travail afin d’effectuer les opérations organisées.
A ce niveau on décide :
- pour les traitements : de la répartition du travail entre l’homme et la machine ;
- pour les données : des structures d’implantation logique.

1.2.3 Le niveau physique

Le niveau physique traduit les choix techniques et la prise en compte des spécifiés. Il répond à la
question : comment faire ?

A ce niveau sont décrits :

- pour les traitements automatisés : un découpage en programme ;
- pour les traitements manuels : une définition précise du poste de travail et des notes
d’instruction ;
- pour les données : l’organisation technique.

A chaque niveau, le système d’information est représenté par un modèle. Chaque modèle respecte un
formalisme et des concepts adaptés (tableau 3.1)

Tableau 3.1- Les modèles suivant la méthode Merise

Niveau Flux Traitement Données

Conceptuel MCF (Modèle MCT (Modèle MCD (Modèle
Correspond à la conceptuel des flux) : conceptuel des conceptuel des
finalité de l’entreprise représente les traitements) : données)
en explicitant sa échanges représente les actions
raison d’être : c’est le « d’informations entre indépendamment de
quoi » les acteurs leur organisation et
conceptuels de la technique
employée
Organisationnel MOF (Modèle MOT (Modèle Schéma relationnel ou
Logique organisationnel des organisationnel des MKD (Modèle logique
Ce sont les choix flux) : représente les traitements) : prend des données)
d’organisation : les échanges en compte le niveau
postes de travail, les d’informations entre d’informatisation,
choix d’organisation, tous les types l’acteur concerné et le
et l’aspect temporel : « d’acteurs temps pour les actions
qui fait quoi, quand et décrites dans le MCT
où ? »
Physique : MPT (Modèle MPD (Modèle
« comment ? » physique des physique des
traitements) : données) : description
architecture des bases de données
technique des
programmes

L’enchainement des modèles se fait suivant un ordre précis (figure 3.1).

En premier lieu, le modèle conceptuel des flux est réalisé afin de schématiser les échanges
d’informations (flux) entre les acteurs conceptuels.
Ensuite, en parallèle de la réalisation du modèle conceptuel des données brut (avant modification
et validation), le modèle conceptuel des traitements et le modèle organisationnel des traitements sont
réalisés.

27
 Lorsque le modèle organisationnel des traitements est finalisé, il est rapproché du modèle
conceptuel des données brut afin de vérifier la cohérence des modèles et le modifier si nécessaire.

Ainsi, au terme de cette phase de rapprochement, le modèle conceptuel des données est valide et il
est alors possible, d’une part, de réaliser le modèle opérationnel des traitements, et d’autre part, de
générer le modèle logique des données brut. Ce dernier sera optimisé afin de passer au modèle physique
des données.

Diagramme des flux

Modèle conceptuel des traitements Modèle conceptuel des données brut

Modèle organisationnel des traitements

Modèle conceptuel des données validé

Modèle logique des données brut

Modèle logique des données optimisé

Modèle opérationnel des traitements Modèle physique des données

Description des processus Description des données

Figure 3.1- L’organisation des différents modèles

Dans la pratique, les modèles de la méthode Merise les plus utilisés sont le modèle conceptuel des
traitements (MCT) et le modèle conceptuel des données (MCD). Leur formalisme répond bien à l’attente
des concepteurs dans le domaine des systèmes d’information de gestion.

Dans ce chapitre, nous nous attachons à présenter le modèle de niveau conceptuel contribuant à la
description des données. La génération du modèle logique des données et les modèles contribuant à la
description des traitements c’est-à-dire des processus seront étudiés dans le cours de systèmes
d’information II.

2. Le Modèle conceptuel des données

La modélisation conceptuelle des données du système d’information d’une organisation se fait à

l’aide de concepts dont la mise en œuvre permet d’obtenir une représentation appelée « Modèle
conceptuel des données » (MCD) ou « Modèle entité-association » (MEA).
Elle ne tient pas compte des aspects organisationnels et techniques liés à leur mise en œuvre. C’est
une représentation statique de l’ensemble des données manipulées par l’entreprise ainsi que des
relations entre ces données.
Le MCD sera confronté à la vision dynamique proposée par les modèles des traitements.

2.1 Les concepts de base

Le MCD sera réalisé lors des trois premières étapes de la démarche proposée dans la méthode
Merise (schéma directeur, étude préalable et étude détaillée) en mobilisant des concepts spécifiques.

2.1.1 Les entités

Une entité constitue un élément de gestion utile à l’organisation étudiée, que l’on souhaite décrire
par ensemble d’informations.
L’entité est un individu ou un objet défini au sein d’un système d’information. Elle est caractérisée
par un certain nombre de propriétés qui lui sont specifiques.

28
 D’un point de vue graphique, une entité (ou ensemble homogène) est représentée sous forme d’un
rectangle barré à l’intérieur duquel est inscrit son nom ou libellé.

Exemple :

La SA Recentresud commercialise des articles en matière plastique (1600 références) qu’elle se

procure auprès d’une cinquantaine de fournisseurs. Les données suivantes sont communiquées.
Certaines s’appliquent aux fournisseurs d’autres concernent les articles.

Données Fournisseurs Articles

Nom du fournisseur x
Nom de l’article x
Adresse du fournisseur x
Nom du représentant x
Prix d’achat de l’article x
Prix de vente de l’article x

Les entités coexistant dans cet exemple sont :

- L’entité FOURNISSEURS
- L’entité ARTICLES.
Les fournisseurs et les articles sont symbolisés par des rectangles qui représentent les entités :

FOURNISSEURS ARTICLES Nom de l’entité

2.1.2 Les propriétés

Une propriété est une information élémentaire qui caractérise une entité. Chaque entité
représente un ensemble homogène de propriétés.

Seules les propriétés élémentaires (ex : nom fournisseur, adresse fournisseur) et calculées
datées (ex. : CA annuel HT) figurent dans une entité. Ainsi, les données calculées datées seront
obtenues sans avoir à reprendre l’ensemble des calculs. Les propriétés calculées ne sont pas retenues
(ex. : solde d’un compte, total d’une ligne de facture, montant brut, montant TVA, montant TTC).

On entend par propriété élémentaire une propriété qui ne peut pas être décomposée en
plusieurs autres propriétés (ex. : une adresse est une propriété complexe décomposable en propriétés
élémentaires : rue, code postal, ville).

Afin d’alléger le représentation d’une entité, il est recommandé de coder les noms des propriétés
( « Nom_frs », « Adr_frs », « Nom_rep », etc.).

Exemple :

FOURNISSEURS ARTICLES
Propriétés de Nom_frs Nom_art Propriétés de
l’entité Adr_frs Prix_achat l’entité
FOURNISSEURS Nom_rep Prix_vente ARTICLES

29
 La propriété « Nom_frs » contient la raison sociale de chaque fournisseur.
La propriété « Adr_frs » contient l’adresse de chaque fournisseur.
La propriété « Nom_rep » contient le nom du représentant de chaque fournisseur.

2.1.3 Les occurrences

L’occurrence d’une entité correspond aux valeurs prises par les propriétés.

Exemple 1 :

Il y a 1600 occurrences de l’entité ARTICLES et 50 occurrences de l’entité FOURNISSEURS.

Ainsi, 1600 articles et 50 fournisseurs différents sont référencés.

Exemple 2 :

Représentation de 3 occurrences de l’entité FOURNISSEURS :

FOURNISSEURS FOURNISSEURS FOURNISSEURS

AMADOU FOKOU ABEGA
Bassa Bonabéri Bali
Moustapha Pete Zanga

Exemple 3 :

Représentation de 3 occurrences de l’entité ARTICLES

ARTICLES ARTICLES ARTICLES

Fer de 8 Sac de ciment Tôle
2000 FCFA 4500 FCFA 3000 FCFA
2500 FCFA 5500 FCFA 4000 FCFA

L’occurrence d’une propriété correspond aux valeurs prises par cette propriété.

Exemple 2 :

En reprenant l’exemple 2 :
- « ABEGA » est une occurrence de la propriété « Nom_frs » ;
- « Bali » est une occurrence de la propriété « Adr_frs » ;
- « Zanga » est une occurrence de la propriété « Nom_rep ».

2.1.4 L’identifiant

L’identifiant est une propriété particulière qui permet de distinguer de façon certaine et unique les
différentes occurrences d’une entité, C’est une propriété dont le domaine des valeurs ne contient
jamais deux valeurs identiques : c’est la règle d’énumération.

La connaissance de l’identifiant donne la connaissance des autres propriétés de l’entité. C’est la

règle de dépendance directe. Dans ce cas, l’identifiant est nommé identifiant absolu.

D’un point de vue graphique, un identifiant est différencié par son soulignement.

30
 Exemple :

Deux fournisseurs peuvent porter le même nom : par exemple, ABEGA. Si on attribue au premier
le code ABE01 et au second le code ABE02, on pourra ainsi les distinguer. L’identifiant sera le code
fournisseur.

FOURNISSEURS ARTICLES

Identifiant Code_frs Code_art Identifiant

Nom_frs Nom_art
Propriétés de Propriétés de
Adr_frs Prix_achat
l’entité l’entité
Nom_rep Prix_vente
FOURNISSEURS ARTICLES

« Code_frs » est l’identifiant de l’entité FOURNISSEURS.

« Code_art » est l’identifiant de l’entité ARTICLES.

2.1.5 Les associations et les entités

Une association relie deux entités ou plus pour produire une nouvelle information.
Une association est une relation existant entre plusieurs entités en fonction du problème à traiter.
Elle assure le lien entre des entités. Elle est généralement caractérisée par un verbe ou un substantif.
D’un point de vue graphique, une association est représentée sous forme d’une ellipse à l’intérieur
de laquelle est inscrit son libellé. Une patte (ou un trait) est dessiné entre la relation et chacune des
entités qu’elle relie.
Dans certains cas, une association peut être porteuse de propriétés.

Exemple :

Il y a une relation entre l’entité FOURNISSEURS et l’entité ARTICLES. Puisque les fournisseurs
vendent leurs articles à la SA Recentresud. Cette association entre les fournisseurs et les articles est
signalée par un verbe qui figurera dans une ellipse reliée aux entités concernées. Le verbe FOURNIR
peut être choisi.

On appelle dimension d’une association le nombre d’entités qu’elle relie. Lorsqu’elle vaut 1,
l’association (ou la relation) est dite réflexive. Lorsqu’elle vaut 2, elle est dite de dimension 2 ou «
association binaire ». Lorsqu’elle vaut 3, elle est dite de dimension 3 ou « association ternaire ». Au-delà,
on parle d’association n-aire.

Dana la pratique, il est souhaitable de limiter autant que possible la dimension d’une association à
deux.

Exemple :

L’association « Fournir » est une association de dimension 2 ou binaire qui etablit le lien entre les
fournisseurs et leurs articles.

FOURNISSEURS
ARTICLES
Fournir
Code_frs
Code_art
Nom_frs
Nom_art
Adr_frs
Prix_achat
Nom_rep
Prix_vente

31
Association représentée par un verbe
 L’association « Approvisionner » est une association de dimension 3 ou ternaire qui établit le
lien entre les fournisseurs, leurs articles et les entrepôts.

Association porteuse de
propriétés

FOURNISSEURS Approvisionner ARTICLES

Prix_Unitaire
Code_frs
Code_art
Nom_frs
Nom_art
Adr_frs
Prix_achat
Nom_rep
Prix_vente

ENTREPOTS

Code_entrepôt
Nom_entrepôt
Adr_entrepôt

2.1.6 Les cardinalités

Les cardinalités précisent les nombres minimal et maximal d’occurrences d’une entité en
relation avec une autre entité. Elles mesurent le degré de participation de l’entité à
l’association.

Les cardinalités ont au moins deux attributs :

− La cardinalité minimale, qui donne le nombre minimal de participations de chacune
des occurrences de l’entité à la relation ;
− La cardinalité maximale, qui donne le nombre maximal de participations de chacune
des occurrences de l’entité à la relation.
Pour chaque entité, on doit préciser la cardinalité minimale et la cardinalité maximale par
rapport à l’association.

On trouve les quatre combinaisons suivantes :

− 0, 1 : au moins zéro, au plus un ;
− 0, n : au moins zéro, au plus n ;
− 1, 1 : au moins un, au plus un ;
− 1, n : au moins un, au plus n.

Remarque 1
Dans le cas de relations binaires, deux cas de cardinalités amènent à se poser des questions :
- les cas 0,1 – 0,1 ou 0,1 – 1,1 : dans ces cas, il faut se poser des questions sur la relation et se
demander si ‘une des entités n’est pas en fait une propriété de l’autre ;
- le cas 1.1 – 1.1 : ce jeu de cardinalités traduit souvent une erreur de conception. Il convient
dans ce cas de vérifier si l’une des entités participant à la relation ne comporte pas des
propriétés de l’autre entité.

Remarque 2
Dans le cas d’une association ternaire (dimension 3), les valeurs maximales des cardinalités sont
toujours égales à n.

D’un point de vue graphique, les cardinalités sont marquées à côté de la patte reliant l’entité à
l’association.

32
Exemple 1

Tout fournisseur ne fournit qu’un seul article. Tout article n’est fourni que par un seul fournisseur.

Cardinalité minimale Cardinalité maximale

FOURNISSEURS
1, 1 ARTICLES
1, 1
Fournir
Code_frs
Code_art
Nom_frs
Nom_art
Adr_frs
Prix_achat
Nom_rep
Prix_vente

Interprétation des cardinalités

Entité Association Cardinalité Commentaire

FOURNISSEURS FOURNIR 1,1 Un fournisseur fournit un seul article
ARTICLES FOURNIR 1,1 Un article est fourni par un seul fournisseur

Remarque : dans ce cas, Il convient de vérifier si les propriétés de l’entité « ARTICLES » ne sont
pas des propriétés de l’entité « FOURNISSEURS ».

Exemple 2

Certains articles sont fabriques par l’entreprise et ne font pas l’objet d’approvisionnement.
Tout fournisseur ne fournit qu’un seul produit.

FOURNISSEURS
1, 1 ARTICLES
0, 1
Fournir
Code_frs
Code_art
Nom_frs
Nom_art
Adr_frs
Prix_achat
Nom_rep
Prix_vente

Interprétation des cardinalités

Entité Association Cardinalité Commentaire

FOURNISSEURS FOURNIR 1,1 Un fournisseur fournit un seul article
ARTICLES FOURNIR 0,1 Un article est fourni par aucun ou par un
seul fournisseur

Remarque : dans ce cas, Il convient de vérifier si les propriétés de l’entité « ARTICLES » ne sont
pas des propriétés de l’entité « FOURNISSEURS ».

Exemple 3

Tout fournisseur peut fournir un ou plusieurs articles. Tout produit n’est fourni que par un seul
fournisseur.

FOURNISSEURS
1, n ARTICLES
1, 1
Fournir
Code_frs
Code_art
Nom_frs
Nom_art
Adr_frs
Prix_achat 33
Nom_rep
Prix_vente
 Interprétation des cardinalités

Entité Association Cardinalité Commentaire

FOURNISSEURS FOURNIR 1,n Un fournisseur fournit un ou plusieurs
articles
ARTICLES FOURNIR 1,1 Un article est fourni par un seul fournisseur

Exemple 4

Certains articles sont fabriques par l’entreprise et ne font pas l’objet d’approvisionnement.
Tout fournisseur peut fournir un ou plusieurs produits.

FOURNISSEURS
1, n ARTICLES
0, 1
Fournir
Code_frs
Code_art
Nom_frs
Nom_art
Adr_frs
Prix_achat
Nom_rep
Prix_vente

Interprétation des cardinalités

Entité Association Cardinalité Commentaire

FOURNISSEURS FOURNIR 1,n Un fournisseur fournit un ou plusieurs
articles
ARTICLES FOURNIR 0,1 Un article est fourni par aucun ou par un
seul fournisseur

Exemple 5

Tout fournisseur peut fournir un ou plusieurs produits. Tout produit est fourni par un ou plusieurs
fournisseurs.

FOURNISSEURS
1, n 1, n ARTICLES
Fournir
Code_frs
Code_art
Nom_frs
Nom_art
Adr_frs
Prix_achat
Nom_rep
Prix_vente

Interprétation des cardinalités

Entité Association Cardinalité Commentaire

FOURNISSEURS FOURNIR 1,n Un fournisseur fournit un ou plusieurs
articles
ARTICLES FOURNIR 1,n Un article est fourni par un ou plusieurs
fournisseurs.

34
 Exemple 6

Cas d’une association ternaire

FOURNISSEURS 1, n
Approvisionner 1, n ARTICLES
Prix_Unitaire
Code_frs
Code_art
Nom_frs
Nom_art
Adr_frs
Prix_achat
Nom_rep
1, n Prix_vente

ENTREPOTS

Code_entrepôt
Nom_entrepôt
Adr_entrepôt

Interprétation des cardinalités

Entité Association Cardinalité Commentaire

FOURNISSEURS APPROVISIONNER 1,n Un fournisseur approvisionne un ou
plusieurs dépôts en un ou plusieurs
produits
ARTICLES APPROVISIONNER 1,n Un article est approvisionné auprès d’un
ou plusieurs fournisseurs pour un ou
plusieurs entrepôts.
ENTREPOTS APPROVISIONNER 1,n Un entrepôts est approvisionné par un
ou plusieurs produits provenant d’un ou
plusieurs fournisseurs.

Interprétation de l’association « Approvisionner » : le prix unitaire d’un produit est fonction du

fournisseur et de l’entrepôt.

2.1.7 La contrainte d’intégrité fonctionnelle (CIF)

Dans le cas d’une CIF, nomme également « association hiérarchique », des entités sont mises en jeu
et il existe une dépendance fonctionnelle directe entre les identifiants de ces entités.

Ainsi, une entité est totalement identifiée par la connaissance des autres.

Les entités liées par une CIF constituent une structure de type « Père-Fils », pour la bonne raison
qu’un père peut avoir plusieurs fils, alors qu’un fils n’a qu’un père.

Exemple :

Un article (Fils) est fourni par un et un seul fournisseur (Père). Autrement dit, la connaissance
d’un article rend possible sans aucune ambigüité la connaissance de son fournisseur. Il existe donc une
dépendance fonctionnelle directe entre les identifiants des entités « ARTICLES » et « FOURNISSEURS
».

FOURNISSEURS
1, n ARTICLES
1, 1
Fournir
Code_frs
Code_art
Nom_frs
Nom_art
Adr_frs
Prix_achat
Nom_rep 35
Prix_vente
 Remarque 1 : ces associations ne sont jamais porteuses de propriétés (ex. : l’association « Fournir »
ne porte aucune propriété).

Remarque 2 : leur particularité est d’avoir une cardinalité 0,1 ou 1,1.

2.1.8 La contrainte d’intégrité multiple (CIM)

Une CIM est également nommée « association non hiérarchique ». Les associations peut être
porteuses de données.

Contrairement à une CIF, une CIM comporte un identifiant qui résulte de la concaténation des
identifiants des entités participant à l’association. La concaténation consiste à mettre bout à bout
les identifiants des entités participant à l’association de manière à donner l’identifiant de la CIM.
Par convention, il n’est pas note dans l’association.

Exemple :

Les élèves sont évalués dans différentes matières et obtiennent des notes pour chacune des
matières. Il convient donc de créer deux entités : l’entité « ELEVES » et l’entité « MATIERES » et
l’association « Evaluer ». La connaissance d’un N° élève et d’un N° matière permet de connaitre une
note, mais on ne peut pas connaitre une note à partir du seul N° élève ou du seul N° matière. C’est
pourquoi la propriété Note ne peut pas être une propriété de l’entité « ELEVES » ou de l’entité «
MATIERES ». Note est donc une propriété de l’association « Evaluer ».

0,n
MATIERES
ELEVES 0,n
Evaluer
N°_mat
Note Nom_mat
N°_eleve
Nom_el
Prenom_el
Adr_el
BP_el
Propriété étant une donnée
portée (Note)

Représentation de 4 occurrences de l’association « Evaluer » :

N°°_eleve N°°_mat Note

1 1 8
1 2 12
2 1 14
2 2 6

L’identifiant de l’association « Evaluer » résulte de la concaténation des identifiants des entités «

ELEVES » et « MATIERES ».

36
 2.2 La démarche d’élaboration du modèle conceptuel des données

La construction du MCD demande de respecter une démarche d’élaboration qui nécessite

d’inventorier les règles de gestion, d’élaborer le dictionnaire des données, de représenter les
dépendances fonctionnelles, de construire le MCD et de le contrôler.

2.2.1 Les règles de gestion

Les règles de gestion doivent être inventoriées. On entend par règle de gestion un élément de
description globale du fonctionnement de l’organisation. Une règle de gestion peut porter sur les
données manipulées par l’organisation ou sur les traitements exécutés au sein de celle-ci.

Exemple 1 :

Règles de gestion (RG) relatives à l’organisation d’un examen :

- RG1 : chaque épreuve comporte un libellé, un numéro sur 4 positions et un coefficient sur
une seule position ;
- RG 2 : les candidats sont identifiés par un numéro sur 4 positions et décrits par un nom et un
prénom ;
- RG 3 : les établissements scolaires sont référencés par un code sur 6 positions. Ils sont
ensuite décrits par leur nom et leur ville d’implantation ;
- RG4 : à chaque épreuve, les candidats obtiennent une note sur 20. A l’issue de la correction
des copies, un nombre total de points est calculé à partir des notes obtenues et des
coefficients. Si le total des points est d’au moins 210, le candidat est déclaré admis ; sinon, il
est ajourné.

2.2.2 Le dictionnaire des données

C’est à partir du dictionnaire des données du système actuellement manipulé par l’entreprise que
le MCD brut est construit. On entend par dictionnaire des données un tableau qui recense et décrit
l’ensemble des propriétés qui seront utilisées pour élaborer le MCD. Les propriétés sont décrites grâce
aux règles de gestion.

La structure des rubriques du dictionnaire des données doit permettre de respecter les qualités
d’une bonne codification :

- concision ;
- fiabilité ;
- fixité ;
- extensibilité ;
- simplicité ;
- adaptabilité.

Exemple 1 (suite)

Dictionnaire des données

rubrique Type Commentaire

(E : élémentaire ; (règles d’intégrité pour vérifier la pertinence
C : calculé ; de l’information, règles de calcul)
CD : calculée datée ;
Conc. : concaténé)
Num_Epreuve E 9999 (Signification : numérique sur 4 positions)
Lib_Epreuve E
Coef_epreuve E 9 (Signification : numérique sur 1 position)
Num_Cand E 9999 (Signification : numérique sur 4 positions)

37
Nom_Cand E
Prenom_Cand E
Code_Ets E 999999 (Signification : numérique sur 6 positions)
Nom_Ets E
Ville_Ets E
Note E [0, 20]
Total C ∑ (Note x Coef.)
Decision C Si total ≥ 210 alors décision : « Admis ». Sinon,
décision « Ajourné ».

Une fois élaboré, le dictionnaire des données doit être contrôlé on doit veiller à :
1. supprimer les polysèmes (rubriques désignant plusieurs notions) ;

Exemple 1 :

La rubrique « Nom » peut désigner à la fois le nom d’un candidat et le nom d’un établissement
scolaire. La résolution de ce polysème consistera à créer deux rubriques distinctes : « Nom_Cand »
et « Nom_Ets ».

2. supprimer les synonymes (rubrique designant la meme notion) ;

Exemple 1 :

Si les rubriques « Code_Ets » et « N°_Ets » désignent la même information, il faudra ne retenir

qu’une seule rubrique.

3. Supprimer les rubriques génériques (rubriques regroupant plusieurs rubriques élémentaires) ;

Exemples 1 :

La rubrique « Adresse » doit être décomposée en plusieurs rubriques élémentaires : « Rue », «

Boite_postal » et « Ville ».

4. supprimer les rubriques paramètres (propriétés constantes).

Exemple 1 : le taux de TVA unique, la durée de travail.

5. supprimer les rubriques calculées (rubriques pouvant être obtenues à partir d’autres données en
appliquant une règle de calcul).

Exemple 1 : « Total » et « Décision ».

Le dictionnaire des données final ne doit donc contenir que les données de base. Cependant,
certaines rubriques font exception :
- les rubriques calculées d’utilisation fréquente ;
- les rubriques calculées de type situation ou historique : rubrique calculées datées (ex. :
montant mensuel HT) ;
- les paramètres utilisés comme identifiants (ex. : l’identifiant Tx TVA de l’entité TVA).

2.2.3 Les dépendances fonctionnelles (DF)

Les dépendances fonctionnelles entre propriétés doivent être mises en évidence.

Les propriétés concernant un même concept vont être regroupées pour constituer les entités et les
associations du MCD.
Pour réaliser cette étape, un outil peut être utilisé : la matrice des dépendances fonctionnelles. Elle
permet de déterminer à partir du dictionnaire des données les identifiants et les relations bâties autour
d’eux.

38
 La matrice des dépendances fonctionnelles est un tableau à deux dimensions où les colonnes
contiennent les sources de dépendance fonctionnelle et où les buts sont portés en lignes. Les sources et
les buts correspondent aux rubriques répertoriées dans le dictionnaire des données.
La première étape consiste à rechercher les propriétés en DF avec les identifiants existant.
Les identifiants sont les propriétés comportant au moins un 1 dans la colonne.
La deuxième étape se traduit par la concaténation des identifiants existants pour créer une DF
élémentaire vers les propriétés isolées.

Exemple 1 (suite) :

Matrice des dépendances fonctionnelles

Source 1 2 3 4 5 6 7 8 9 10

Buts
1 Num_Epreuve
2 Lib_Epreuve 1
3 Coef 1
4 Num_cand
5 Nom_Cand 1
6 Prenom_Cand 1
7 Code_Ets 1
8 Nom_Ets 1
9 Ville_Ets 1
10 Note

a) Première étape

A ce stade, seules 10 propriétés sont portées dans la matrice des DF.

• Lecture de la matrice en colonne

Pour remplir la matrice, on va se poser la question suivante : pour une valeur de la donnée en
colonne, existe-t-il au maximum une seule valeur de la donnée située en ligne ? Si la réponse
est oui, on inscrit un 1 à l’intersection pour indiquer l’existence d’une DF.

Exemple 1 :

« Num_Epreuve » est en DF avec « Lib_Epreuve » et « Coef ».

« Num_Cand » est en DF avec « Nom_Cand », « Prenom_Cand » et « Code_Ets ».
« Code_Ets » est en DF avec « Nom_Ets » et « Ville_Ets ».
« Num_Epreuve », « Num_Cand » et « Code_Ets » sont des identifiants.

• Lecture de la matrice en ligne

Il convient de ne trouver qu’un seul 1 sur une meme ligne. Lorsqu’il y a deux 1 sur une meme
ligne, il y a un risque important de presence de DF transitive entrainant une redondance
d’information.
Une DF (A→B) est dite transitive s’il existe une donnee C telle que : A → C et C → B.

Exemple 2 :

A chaque transaction avec un client, une facture est établie. Cette dernière comporte les
données citées ci-après :

Matrice des dépendances fonctionnelles (extrait)

39
 Source 1 2 3 4 5 6 7

Buts
1 Num_Fact
2 Date_Fact 1
3 Num_Clt 1
4 Nom_Clt 1 1
5 Adr_Rue_Clt 1 1
6 BP_Clt 1 1
7 Ville_Clt 1 1

Les identifiants sont soulignés

Exemple 1 (suite) : Organisation d’un examen :

Num_Epreuve, Num_Cand et Code_Ets

Exemple 2 (suite) : Facturation client

Num_Fact et Num_Clt

La matrice peut être simplifiée en éliminant les colonnes vides.

Exemple 1 (suite)

Matrice des dépendances fonctionnelles simplifiée

Source 1 4 7

Buts
1 Num_Epreuve
2 Lib_Epreuve 1
3 Coef 1
4 Num_cand
5 Nom_Cand 1
6 Prenom_Cand 1
7 Code_Ets 1
8 Nom_Ets 1
9 Ville_Ets 1
10 Note

b) Deuxième étape

Certaines données ne sont pas reliées aux autres par un 1 en colonne ou en ligne. Il s’agit de
propriétés isolées qui ne sont pas en DF avec un identifiant.
Exemple 1 : Note n’est pas reliée aux autres par un 1 en colonne ou en ligne.

40
 IL faut donc voir à présent, en prenant les identifiants deux à deux ou trois par trois, si on peut
obtenir la propriété non reliée aux autres par un 1.
Exemple 1 (suite)
On peut obtenir « Note » à partir de « Num_Epreuve » et de « Num_Cand ».
La concaténation des identifiant « Num_Epreuve » et « Num_Cand » permet de créer une DF
elementaire vers la propriété isolée « Note ».
Num_Epreuve, Num_Cand → Note

2.2.4 L’élaboration du modèle conceptuel des données

A partir de la matrice des dépendances fonctionnelles, le MCD est élaboré.

Exemple 1 (suite)

EPREUVE CANDIDAT
Noter
Num_Epreuve 1, n Num_Cand
1, n Note
Lib_Epreuve Nom_Cand
Coef Prenom_Cand
CIM

ETABLISSEMENT
1, 1
Code_Ets
Nom_Ets
Ville_Ets Appartenir
1, n

CIF
Modèle conceptuel des données

2.2.5 La vérification du modèle conceptuel des données

Lorsque le MCD est terminé, on doit procéder à quelques vérifications avant validation par les
utilisateurs.

Règle 1 : une propriété, pour une occurrence de la relation qui la porte, ne peut pas être répétitive.
Si c’est le cas, il faut l’isoler sous la forme d’une entité distincte.

Exemple

ASSURE
N°_SS
Nom
Prenom
Noms_enfants

« Nom des enfants » est une propriété répétitive qu’il faut extraire de l’entité « ASSURE » afin de
créer une nouvelle entite « ENFANT ».

ASSURE
0, n ENFANT
1, 1
Avoir
N°_SS
N°_Enfant
Nom
Nom
Prenom
41
 Règle 2 : les propriétés portées par une entité ou une association doivent dépendre
exclusivement de l’identifiant de l’entité ou de l’association.

Exemple :

« Nom » et « Prenom » de l’entité « ASSURE » dépendent uniquement de l’identifiant de cette entité

« N°SS ».
« Nom_Cand » et « Prenom_Cand » dépendent exclusivement de l’identifiant « Num_Cand ».

Règle 3 : Si une propriété dépend de l’identifiant de l’entité mais aussi d’une autres propriété de
cette entité, cela signifie qu’il y a une entité imbriquée dans l’entité de base.

Exemple :

VEHICULE
N°_Immatriculation
Numéro de série
Type
Puissance

La « Puissance » pouvant être déterminée à partir du type de véhicule, il faut donc extraire de
l’entité « VEHICULE » les propriétés Type et Puissance afin de créer une nouvelle entité « TYPE ».

VEHICULE
1,1 TYPE
1,n
Avoir
N°_Immatriculation Type
Numéro de série
Puissance

Règle 4 : à l’exception des associations réflexives, il ne doit exister qu’une et une seule occurrence
de chaque entité participant à la relation.

Exemple :

VEHICULE
1,1 TYPE
1,n
Avoir
N°_Immatriculation Type
Numéro de série
Puissance

Pour une occurrence de l’entité « VEHICULE », il n’existe qu’une seule occurrence de l’entité «
TYPE ».

42
 Règle 5 : une CIF (1,1 ou 0,1 sur une patte de l’association binaire considérée) n’est jamais
porteuse de propriétés.

3. Applications
3.1 Questions de cours : La méthode MERISE
1. Définir la modélisation
2. Expliquer pourquoi la méthode Merise s’appuie sur la séparation des données et des traitements.
3. Expliquer les raisons poussant à rapprocher le modèle organisationnel des traitements du modèle
conceptuel des données.
4. Préciser les objectifs du cycle d’abstraction pour la conception des systèmes d’information et citer les
différentes étapes.
3.2 Modèle conceptuel des données
Proposer un modèle conceptuel des données qui représente le domaine d’application suivant :
Les patients de l’hôpital sont réparties dans les services (caractérisés chacun par un nom identifiant, sa localisation, sa
spécialité) de ce dernier. Chaque médecin appartient à un service. Il est caractérisé par un matricule identifiant, son nom
et son prénom. Un patient passe des visites. Chaque visite est effectuée chez un médecin à une date déterminée. Un
patient ne peut passer plus d’une visite par jour. Lors d’une visite, une ou plusieurs prescriptions peuvent être rédigées.
Chaque prescription mentionne le nom d’un médicament et la posologie à respecter par le patient (posologie = simple
ligne de texte). Il est évident que le médecin ne prescrit pas deux fois le même médicament lors d’une même visite ! Un
patient possède un numéro d’inscription (identifiant), un nom, un prénom et une adresse.

3.3 Modèle conceptuel des données

La Direction du Centre des Œuvres Universitaires (DCOU) gère des logements pour les étudiants. Deux
types de logements sont gérés par des services différents : les logements en cité universitaire et les logements
en ville. Nous nous intéressons ici au second. Le service des logements en ville dispose de renseignements
concernant des propriétaires de villas, appartements, garages, …
- nom, prénom et adresse des propriétaires ;
- nature et adresse du bien possédé par un propriétaire.
a) Modéliser cette réalité à l’aide d’un MCD (3 pts) ;
b) Nous voulons maintenant pouvoir représenter le fait qu’un propriétaire peut vouloir louer ses biens.
Nous ne souhaitons toutefois pas d’auto-location (de location dans lesquelles propriétaire et
locataire sont une seule et même personne). La location se fait à partir d’une date donnée, pour une
période donnée et moyennant un loyer mensuel précis. Modéliser cette réalité à l’aide d’un MCD (6
pts);
c) La DCOU envisage de percevoir sur les loyer un pourcentage, variable selon la nature du bien. Cela
pourrait servir à alimenter un fond social d’aide aux étudiants en difficulté. Modifier le modèle
précédent pour permettre la mémorisation de ce pourcentage (3 pts).

3.4 Modèle conceptuel des données

43
 Nous voulons modéliser une gestion de prêts de livres dans une médiathèque. Une première tentative a
conduit au MCD suivant :

EMPRUNTEUR OUVRAGE
EMPRUNTE

Nom N° Référence

0, n 0, n

Modifier le schéma pour que nous puissions prendre en compte l’historique des emprunts (Mr
OWONO pouvant emprunter plusieurs fois le même livre). Proposer deux solutions.

3.5 Modèle conceptuel des données

Un site internet vend des produits à des clients. Un produit a un nom, un type et un prix. Le client a un
nom, une adresse, une adresse mail et un mot de passe. Une adresse mail correspond à un client et un seul.
Les clients peuvent changer d’adresse mail. Les clients font des achats. Pour cela, ils remplissent un panier
avec leurs produits. Leurs achats donnent lieu à une facture avec un numéro de facture, le détail des achats,
le total des achats et le nombre de produits achetés.

Travail demandé : Réaliser le MCD.

3.6 INVENTAIRE DES ŒUVRES D’ART

Les conservateurs des musées d’art veulent constituer une base de données commune des œuvres d’art
qu’ils possèdent. Actuellement le conservateur de chaque musée garde, pour chaque œuvre, les informations
suivantes : type (peinture, collage, sculpture, lithographie…), titre, année, nom du ou des artiste(s), matière,
dimensions, le courant artistique auquel il appartient (impressionnisme, cubisme…). Attention, il peut dans
certains cas ne pas être défini car certaines œuvres sont inclassables.
En plus certains conservateurs se sont constitués des fiches techniques décrivant :
• les principaux courants artistiques : nom du courant, période (année de début, année de fin), texte
descriptif ;
• les artistes : nom, prénom, les courants auxquels il a participé par ses œuvres, texte descriptif.
Ils veulent aussi mettre ces fiches en commun dans la base de données. Cette base de données devra
permettre de répondre à des questions du type :
• Dans quel musée se trouve telle œuvre de tel artiste ?
• Quelles sont les œuvres créées par tel artiste ?
• A quels courants a participé tel artiste ?
• Dans quels musées trouve-t-on des œuvres de tel courant ?
• Quels sont les œuvres et les noms des artistes de tel musée ?
• Quels sont les musées de telle ville ?

44
Travail demandé
1. Quelles sont les entités qui entrent en jeu ? Donner l’identifiant et la liste des propriétés de chacune
de ces entités.
2. Mettre en évidence les associations existantes entre ces entités.
3. Créer le MCD.
4. Justifier par une phrase chacune des cardinalités.

45