Notes de Cours de Mai I G2-Ig

REPUBLIQUE DEMOCRATIQUE DU CONGO
ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
INSTITUT SUPERIEUR DE COMMERCE

« ISC-KIS »
B.P. 1010
KISANGANI
NOTES DU COURS DE METHODOLOGIE

D’ANALYSE INFORMATIQUE I (M.A.I)
DESTINEES AUX ETUDIANTS DE DEUXIEME
GRADUAT INFORMATIQUE DE GESTION
SECTIONS : JOUR & SOIR
Dispensé par
Ass2.Ir.KUTUMBAKANA ATUHELUSA Philémon

Ph:D Student in Strategic Management
Appartenant à
………………………………………..
ANNEE ACADEMIQUE 2021 - 2022

KUTUMBAKANA Philemon 1
Méthodologie d’Analyse Informatique
Ph.D Student in Strategic Management
Objectifs
- Expliquer le rôle joué par l'analyste des systèmes dans le développement des
systèmes d'information.
- Décrire le cycle de vie fondamental du développement des systèmes et ses quatre
phases.
- Expliquer comment les organisations identifient les projets de développement de
Système d’Information.
- Expliquer l'importance de lier le système d'information aux besoins de
l'entreprise.
- Décrire l'évaluation de la faisabilité technique, économique et organisationnelle.
- Être capable d'effectuer une analyse de faisabilité.
- Être capable de créer un système d’Information utilisant MERISE.
PARTIE I : NOTIONS GENERALES DE SYSTÈMES D’ENTREPRISE
CHAPITRE UN : PRESENTATION DU SYSTÈMES D’ENTREPRISE
1.1. Introduction
Dans le monde des affaires, l'analyse et la conception de systèmes d’Information

font référence au processus d'examen d'une situation d'entreprise dans le but
de l'améliorer par de meilleures procédures et méthodes.
L'analyse et la conception de systèmes d’Information ont trait à la mise en forme

des organisations, à l'amélioration des performances et atteindre des objectifs
de rentabilité et de croissance. L'accent est mis sur les systèmes en action, les
relations entre les sous-systèmes et leur contribution à la réalisation d'un
objectif commun. L'examen d'un système et la détermination de son
fonctionnement adéquat, des changements à apporter et de la qualité des
résultats font partie de l'analyse du système.
Les organisations sont des systèmes complexes composés de sous-systèmes

interdépendants et imbriqués. Les changements dans une partie du système ont
des conséquences prévues et imprévues dans d'autres parties du système.
L'approbation des systèmes est une façon de penser à l'analyse et la conception
d'applications informatiques. Il fournit un cadre pour visualiser les facteurs
organisationnels et environnementaux qui agissent sur un système.
Lorsqu'un ordinateur est utilisé dans une organisation, diverses fonctions et

dysfonctionnements agissent sur l'utilisateur ainsi que sur l'organisation. Parmi
les conséquences positives, citons l'amélioration des performances et un
sentiment de réussite grâce à des informations de qualité. Parmi les
conséquences imprévues, on peut citer une menace éventuelle pour l'emploi
des employés, une baisse du moral du personnel en raison d'un manque
d'implication et d'un sentiment d'intimidation de la part des utilisateurs en
raison de l'analphabétisme informatique. Le rôle de l'analyste est d'éliminer ces
craintes et de faire en sorte que le système soit un succès.
L'analyse et la conception de systèmes d’Information sont axées sur les

systèmes, les processus et la technologie.
I.2. Etude des Concepts
- Méthodologie :
La méthodologie est une étude des méthodes (utilisées dans les sciences et les
techniques). La méthodologie peut être aussi définie comme un ensemble des
procédés et des techniques propres à un domaine spécifique. Une
méthodologie d'analyse propose au concepteur des modèles, des méthodes et
des outils.
Un modèle, au sens d'une théorie de la modélisation, est un ensemble de
concepts et de lois (de complétude, de cohérence, de transformation ...) unissant
ces concepts. Concepts et lois qui permettent de décrire "intelligemment" une
réalité. A titre subsidiaire, un modèle comporte des formalismes, qu'il ne faut
pas croire limités aux seuls schémas graphiques ou diagrammes dont, à l'instar
de tout concepteur.
- Méthode :
Une méthode définit un processus d’informatisation, possède un champ

d’étude et décrit une démarche à suivre. Une méthode propose des démarches
et des règles de bon usage. Idéalement, elle se fonde sur des modèles éprouvés
et vise à en exploiter les potentialités en vue de fabriquer des objets répondant
à certains critères de qualité. Une méthode :
- S’appuie sur des concepts théoriques
- Aide à la mise en place d’un langage commun au sein de l’organisation
- Doit permettre une meilleure communication entre tous les partenaires
- Utilité d’une Méthode
Une méthode est nécessaire :

- pour maîtriser la complexité du problème informationnel à résoudre ;
- pour sortir la construction des systèmes d'information de l'empirisme
individuel et la fonder sur une coopération efficace entre informaticiens et
gestionnaires ;
- pour permettre la communication entre individus de l'équipe de conception ;
- pour construire des systèmes pertinents, fiables, flexibles et adaptatifs ;
- pour permettre d'évaluer le système à tout moment de son cycle, tant sur le
plan de son efficacité technique que sur celui de sa pertinence par rapport
aux besoins des gestionnaires;
- pour améliorer les coûts, les délais et la productivité des activités de
développement.
Composants d’une méthode
- Modèles : ensemble de concepts et de règles destinés à expliquer et

construire la représentation de phénomènes organisationnels
- Langages : destinés à la spécification et à simplifier la communication
- Démarche : processus à suivre pour effectuer les travaux demandés,
découpée en étapes
- Outils et techniques : aide à mise en œuvre des modèles, langages,
démarche.
I.3. Objectifs de la méthode
- Réduire la complexité des informations

- Rendre cohérentes les solutions conçues et assurer leur bonne intégration
dans une stratégie globale
- Maitriser les budgets
- Accroitre la productivité des services informatiques
- Améliorer les communications entre intervenants dans une organisation
(gestionnaires, informaticiens, etc.)
I.4. Les cinq niveaux de maturité des processus de développement.
1. initial : le développement n'est pas formalisé, l'équipe réagit au jour le jour

et choisit des solutions au cas par cas, de sorte que le succès dépend
fortement des personnes impliquées dans le projet ;
2. reproductible : l'organisation est capable d'établir des plans raisonnables en
termes de budget et de vérifier l'état d'avancement du projet par rapport à
ces plans ;
3. défini : le processus de développement est bien défini, connu et compris par
tous les intervenants du projet ;
4. encadré : les performances du processus de développement sont mesurables
objectivement ;
5. optimisant : les données de contrôle des performances du processus

permettent l'amélioration du processus.
Les équipes de développement ont besoin d’une méthode de travail contrôlée,

d’un processus intégrant les diverses facettes du développement et d’une
approche commune, c’est-à-dire d’un processus capable :
- de dicter l’organisation des activités de l’équipe ;
- de diriger les tâches de chaque individu et de l’ensemble de l’équipe ;
- de spécifier les artefacts à produire ;
- de proposer des critères pour le contrôle et l’évaluation des produits et
des activités du projet.
I :5.Quelques Méthodes
- MERISE : Méthode d’Etude et de Réalisation Informatique pour les

Systèmes d’Entreprise
- AXIAL : Analyse et Conception des Systèmes d’Information Assistés par
Logiciels
- SSADM: Structured Systems Analysis and Design Method
- SADT: Structured Analysis and Design Techniques
- OOA: Object-Oriented Analysis
- OMT: Object Modeling Technique
- UML: Unified Modeling Language
1.2. VUE D'ENSEMBLE DE L'ANALYSE ET DE LA CONCEPTION DES SYSTÈMES
Qu'est-ce que l'analyse et la conception de systèmes ?
On peut généralement considérer que le développement de systèmes

d’information comporte deux grandes composantes : l'analyse des systèmes et
la conception des systèmes.
- l'analyse des systèmes : L'analyse du système est donc le processus de

collecte et d'interprétation des faits ou information, de diagnostic des
problèmes, et l'utilisation de ces informations pour recommander des
améliorations au système.
- la conception des systèmes : La conception de systèmes est le processus qui

consiste à la planification d'un nouveau système d’information d'entreprise ou
d'un système destiné à remplacer ou à compléter un système existant. Mais
avant que cette planification puisse être faite, nous devons comprendre en
profondeur l'ancien système et déterminer comment les ordinateurs peuvent
être utilisés au mieux pour rendre son fonctionnement plus efficace.
C'est le travail de l'analyste des systèmes.
- Prenons, par exemple, le fonctionnement de la gestion de stock d'un magasin

de vêtements. Pour mieux contrôler son inventaire et avoir accès à des
informations plus récentes sur les niveaux de stock et le réapprovisionnement,
le magasinier demande à un analyste de système d'informatiser ses opérations
de stockage. Avant de pouvoir concevoir un système pour saisir les données,
mettre à jour les fichiers et produire des rapports, il faut en savoir plus sur les
opérations de stock du magasin : quelles sont utilisées pour stocker
l'information, comme les demandes d'achat, les bons de commande et les
factures, ainsi que les rapports qui sont produits et comment ils sont utilisés.
Pour commencer, vous recherchez les informations sur les fiches de demande
d'achat, les bons de commande en cours, les registres des stocks disponibles
et d'autres rapports. Vous devez également trouver l'origine de ces
informations, que ce soit dans le service des achats, l'entrepôt ou le service
comptable. En d'autres termes, vous devez comprendre comment le système
existant fonctionne et, plus précisément, à quoi ressemble le flux
d'informations dans le système.
Vous devez également savoir pourquoi le magasin souhaite modifier ses
opérations actuelles. L'entreprise a-t-elle des problèmes pour suivre ou
retracer les commandes, la marchandise ou l'argent ? Semble-t-elle prendre du
retard dans le traitement des fiches d'inventaire ?
A-t-elle besoin d'un système plus efficace avant de pouvoir étendre ses activités
?
Ce n'est qu'après avoir recueilli tous ces détails que vous pourrez déterminer
comment et où un système d'information peut bénéficier à tous les utilisateurs
du système. Cette accumulation d'informations, appelée étude des systèmes,
doit précéder toutes les autres activités d'analyse.
Les analystes de systèmes font plus que résoudre les problèmes actuels. Ils sont
souvent appelés pour aider à gérer l'expansion prévue d'une entreprise. Dans
le cas du magasin de vêtements, l'étude des systèmes est orientée vers l'avenir,
car aucun système n'existe actuellement.
Les analystes évaluent aussi soigneusement que possible quels seront les
besoins futurs de l'entreprise et quels changements doivent être
envisagés pour répondre à ces besoins.
Dans ce cas et dans la plupart des autres, les analystes peuvent
recommander des alternatives pour améliorer la situation. Généralement,
plus d'une stratégie est possible.
Travaillant en collaboration avec les gestionnaires et les employés de
l'organisation, les analystes de systèmes recommandent la solution à
adopter, en se fondant sur des considérations telles que l'adéquation de
la solution à l'organisation et au contexte particuliers, ainsi que le soutien
que les employés sont susceptibles d'apporter à la solution. Parfois, le
temps nécessaire pour développer une alternative, par rapport aux autres,
est le point le plus critique.
Les coûts et les avantages sont également déterminants. En fin de compte,

c'est la direction, qui paiera et utilisera le résultat, qui décide de
l'alternative à accepter ou à adopter.
Une fois cette décision prise, un plan est élaboré pour mettre en œuvre la
recommandation. Le plan comprend toutes les caractéristiques de la
conception des systèmes, comme les nouveaux besoins en matière de
saisie de données, les spécifications des fichiers, les procédures
d'exploitation, les besoins en équipement et en personnel.
Dans l'analyse de système, nous discutons de la façon dont divers systèmes sont
conçus et comment ils fonctionnent pour répondre aux exigences de l'utilisateur.
L'analyse et la conception d'un système d’Information consistent donc à

étudier en détail les différentes étapes de son cycle de vie.
1.3 Concepts de systèmes d'entreprise
Le mot système est largement utilisé. Il est devenu à la mode d'ajouter le mot
système pour ajouter une touche contemporaine lorsqu'on se réfère à des
choses ou à des processus. On parle de système d'exercice, de système
d'investissement, de système de livraison, de système d'information, de
système éducatif, de système informatique, etc.
Un système peut désigner tout ensemble de composants qui fonctionnent

de manière interdépendante pour une cause ou un objectif commun.
1.3.1. Définition :
Le terme système est dérivé du mot grec systema, qui signifie une relation
organisée entre des unités ou des composants fonctionnels (qui
fonctionnent). Un système existe parce qu’il est conçu pour atteindre un ou
plusieurs objectifs.
Nous sommes arrivés en contact quotidien avec le système de transport, le

système téléphonique, le système comptable, le système de production et,
depuis plus de deux décennies, le système informatique.
De même, nous parlons du système d'entreprise et de l'organisation comme

d'un système composé de départements interdépendants (sous-systèmes) tels
que la production, les ventes, le personnel et un système d'information.
Aucun de ces sous-systèmes n'est d'une grande utilité en tant qu'unité unique
et indépendante. Toutefois, lorsqu'ils sont correctement coordonnés,
l'entreprise peut fonctionner de manière efficace et rentable.
Il existe plus d'une centaine de définitions du mot "système", mais la plupart

semblent avoir un fil conducteur qui suggère qu'un système est un
regroupement ordonné de composants interdépendants liés entre eux selon
un plan pour atteindre un objectif spécifique.
Le mot composant peut faire référence à des parties physiques (moteurs, ailes
d'avion, voiture), à des étapes de gestion (planification, organisation et contrôle)
ou à un système dans une structure à plusieurs niveaux.
Le composant peut être simple ou complexe, basique ou avancé. Il peut s'agir

d’un ordinateur unique doté d'un clavier, d'une mémoire et d'une imprimante
ou une série de terminaux intelligents reliés à un ordinateur central.
Dans un cas comme dans l'autre, chaque composant fait partie du système total
et doit faire sa part de travail pour que le système atteigne l'objectif visé.
N.B : L'étude des concepts de systèmes a donc trois implications fondamentales
1. Un système doit être conçu pour atteindre un objectif prédéterminé.
2. Des interrelations et une interdépendance doivent exister entre les

composants.
3. Les objectifs de l'organisation dans son ensemble sont plus prioritaires que
les objectifs de ses sous-systèmes. Par exemple, l'informatisation des
applications du personnel doit se conformer à la politique de l'organisation en
matière de confidentialité et de sécurité, confidentialité et de sécurité de
l'organisation, ainsi que la mise à disposition de certaines données (par exemple
la paie) disponibles à la division de la comptabilité sur demande.
1.4 Caractéristiques d'un système
Notre définition d'un système suggère quelques caractéristiques qui sont

présentes dans tous les systèmes : organisation (ordre), interaction,
interdépendance, intégration et un objectif central.
1.4.1 Organisation
L'organisation implique une structure et un ordre. C'est l'agencement des

éléments qui permet d'atteindre les objectifs. Dans la conception d'un système
d'entreprise, par exemple, les relations hiérarchiques allant du président au
sommet jusqu'aux cols bleus représentent la structure organisationnelle. Un tel
arrangement dépeint une relation système - sous-système, définit la structure
d'autorité, spécifie le flux formel de communication et formalise la chaîne de
commandement. De la même manière, un système informatique est conçu
autour d'un dispositif d'entrée, d'une unité centrale de traitement, d'un dispositif
de sortie et d'une ou plusieurs unités de stockage. Lorsqu'ils sont reliés entre
KUTUMBAKANA Philemon
Méthodologie d’Analyse Informatique 10
eux, ils fonctionnent comme un système complet pour produire des

informations.
1.4.2 Interaction
L'interaction fait référence à la manière dont chaque composant fonctionne avec

les autres composants du système. Dans une organisation, par exemple, les
achats doivent interagir avec la production, la publicité avec les ventes et la paie
avec le personnel. Dans un système informatique, l'unité centrale de traitement
doit interagir avec le dispositif d'entrée pour résoudre un problème. La mémoire
principale, quant à elle, contient les programmes et les données que l'unité
arithmétique utilise pour le calcul. L'interrelation entre ces composants permet
à l'ordinateur de fonctionner.
1.4.3 Interdépendance
L'interdépendance signifie que des parties de l'organisation ou du système

informatique dépendent les unes des autres. Ils sont coordonnés et reliés entre
eux selon un plan. Le bon fonctionnement d'un sous-système dépend de l'entrée
d'un autre sous-système, c'est-à-dire que la sortie d'un sous-système est l'entrée
nécessaire à un autre sous-système. Cette interdépendance est cruciale dans le
travail sur les systèmes.
Un système d'information intégré est conçu pour répondre aux besoins des
utilisateurs autorisés (chefs de service, gestionnaires, etc.) pour un accès et une
récupération rapide via des terminaux à distance. L'interdépendance entre le sous-
système personnel et les utilisateurs de l'organisation est évidente.
En résumé, aucun sous-système ne peut fonctionner isolément car il dépend données

(entrées) qu'il reçoit des autres sous-systèmes pour accomplir les tâches qui lui
incombent. L'interdépendance est également illustrée par les activités et le soutien des
analystes de systèmes, des programmeurs et du personnel d'exploitation d'un centre
informatique.
La décision d'informatiser une application est initiée par l'utilisateur, analysée et

conçue par l'analyste, programmée et testée par le programmeur, et exécutée par
l'opérateur informatique.
Aucune de ces personnes ne peut opérer sans l'apport requis des autres personnes du
centre informatique sous-système.
1.4.4 Intégration
L'intégration fait référence à l'holisme des systèmes. La synthèse suit l'analyse

pour atteindre l'objectif central de l'organisation. L'intégration s'intéresse à la
manière dont un système est lié. C'est plus que le partage d'une partie ou d'un
emplacement physique. Cela signifie que les parties du système fonctionnent
ensemble au sein du système même si chaque partie remplit une fonction
unique. Une intégration réussie produira généralement un effet synergique et
un impact total plus important que si chaque composant travaille séparément.
1.4.5 Objectif central
La dernière caractéristique d'un système est son objectif central. Les objectifs
peuvent être réels ou déclarés. Bien qu'un objectif déclaré puisse être l'objectif
réel, il n'est pas rare qu'une organisation déclare un objectif et agisse pour en
atteindre un autre. Le point important est que les utilisateurs doivent connaître
l'objectif central d'une application informatique dès le début de l'analyse pour
que la conception et la conversion soient réussies. Les considérations d'ordre
politique et organisationnel masquent souvent le véritable objectif. Cela signifie
que l'analyste doit contourner ces obstacles pour identifier l'objectif réel du
changement proposé.
1.5 Éléments d'un système
Dans la plupart des cas, les analystes de systèmes travaillent dans un

environnement dynamique où le changement est un mode de vie. Cet
environnement peut être une entreprise, une application commerciale ou un
système informatique. Pour reconstruire un système, les éléments clés suivants
doivent être considérés :
1. Les entrées et les sorties.
2. Le(s) processus (traitements).
3. Contrôle.
4. Retour d'information(feedback).
5. L'environnement.
6. Frontières (limites) et interface.
1.5.1 Entrées et sorties
L'un des principaux objectifs d'un système est de produire un résultat qui a
de la valeur pour son utilisateur. Quelle que soit la nature de la production
(biens, services ou informations), elle doit être conforme aux attentes de
l'utilisateur concerné. Les entrées sont les éléments (matériel, ressources
humaines et informations) qui entrent dans le système pour être traités. La sortie
est le résultat du traitement. Un système se nourrit d'entrées pour produire des
sorties, de la même manière qu'une entreprise apporte des ressources
humaines, financières et matérielles pour produire des biens et des services. Il
est important de souligner ici que la détermination de la sortie est une première
étape dans la spécification de la nature, de la quantité et de la régularité de
l'entrée nécessaire au fonctionnement d'un système.
Par exemple, dans l'analyse des systèmes, la première préoccupation est

de déterminer les exigences de l'utilisateur d'un système informatique
proposé - c'est-à-dire la spécification de la sortie que l'ordinateur est censé
fournir pour répondre aux exigences de l'utilisateur.
1.5.2 Processus(s)
Le processus est l'élément d'un système qui implique la transformation réelle de

l'entrée en sortie. Il s'agit du composant opérationnel d'un système. Les
processus peuvent modifier totalement ou partiellement l'entrée, en fonction
des spécifications de la sortie. Cela signifie que le traitement évolue au fur et à
mesure que les spécifications de sortie changent. Dans certains cas, les données
d'entrée sont également modifiées pour permettre au processus de gérer la
transformation.
1.5.3 Contrôle
L'élément de contrôle guide le système. Il s'agit du sous-système de prise de

décision qui contrôle le schéma des activités qui régissent les entrées, le
traitement et les sorties. Dans un contexte organisationnel, la direction, en
tant qu'organe décisionnel, contrôle les entrées, les manipulations et les sorties
d'activités qui affectent le bien-être de l'entreprise.
Dans un système informatique, le système d'exploitation et les logiciels qui

l'accompagnent influencent le comportement du système. Les spécifications de
sortie déterminent le type et la quantité d'entrées nécessaires pour maintenir le
système en équilibre.
Dans l'analyse des systèmes, connaître l'attitude de la personne qui contrôle le

secteur pour lequel un ordinateur est envisagé peut faire la différence entre le
succès et l'échec de l'installation. Le soutien de la direction est nécessaire pour
assurer le contrôle et soutenir l'objectif du changement proposé.
1.5.4 Retour d'information (feedback)
Le contrôle d'un système dynamique s'effectue par rétroaction. La rétroaction

mesure la sortie par rapport à une norme dans une certaine forme de procédure
cybernétique qui inclut la communication et le contrôle.
Les informations de sortie sont renvoyées à l'entrée et / ou à la direction

(contrôleur) pour délibération. Après avoir comparé les résultats aux normes de
performance, des changements peuvent être apportés à l'entrée ou au
traitement et, par conséquent, aux résultats.
Les commentaires peuvent être positifs ou négatifs, de routage ou

d'information. Un feedback positif renforce les performances du système. Il est
de nature routinière. Le feedback négatif fournit généralement au contrôleur des
informations pour agir. Dans l'analyse des systèmes, le feedback est important
de différentes manières.
Au cours de l'analyse, on peut dire à l'utilisateur que les problèmes d'une

application donnée confirment les préoccupations initiales et justifient la
nécessité d'un changement. Une autre forme de feedback intervient après la
mise en œuvre du système. L'utilisateur informe l'analyste des performances de
la nouvelle installation. Ce feedback entraîne souvent des améliorations pour
répondre aux besoins de l'utilisateur.
1.5.5 Environnement
L'environnement est le "supra système" au sein duquel opère une organisation.

Il est la source des éléments externes qui influent sur le système. En fait, il
détermine souvent comment un système doit fonctionner.
Par exemple, l'environnement de l'organisation, composé de fournisseurs, de

concurrents et autres, peut fournir des contraintes et, par conséquent, influencer
les performances réelles de l'entreprise.
1.5.6 Limites et interface
Un système doit être défini par ses frontières - les limites qui identifient ses
composants, ses processus et ses interrelations lorsqu'il s'interface avec un autre
système. Par exemple, le système de guichet d'une banque commerciale est
limité aux dépôts, aux retraits et aux activités connexes des comptes chèques et
d'épargne des clients. Il peut exclure les saisies d'hypothèques, les activités de
fiducie, etc.
Chaque système a des limites qui déterminent sa sphère d'influence et de

contrôle.
Par exemple, dans le cadre de la conception d'un système informatique intégré

de type bancaire, un client qui qui a un prêt hypothécaire et un compte chèque
dans la même banque peut faire un chèque par l'intermédiaire du "système de
guichet" pour payer la prime qui est ensuite traitée par le "système de prêt
hypothécaire". Récemment, la conception du système a permis le transfert

automatique de fonds d'un compte bancaire pour payer des factures et d'autres
obligations envers des créanciers, indépendamment de la distance ou de
l'emplacement.
Cela signifie que dans l'analyse des systèmes, la connaissance des limites
d'un système donné est cruciale pour déterminer la nature de son interface
avec d'autres systèmes en vue d'une conception réussie.
1.6. La représentation schématique des systèmes de l’entreprise

Si nous reprenons l’analogie anatomique, et si nous comparons l’entreprise à un
corps humain, nous pouvons réduire l’entreprise à un cerveau qui pilote, un
muscle qui opère et des nerfs qui font transiter les informations. Voici un schéma
simplifié qui en découle :
1.6.1. Le système de pilotage
Le système de pilotage (appelé également système de décision) définit les

missions et les objectifs, organise l’emploi des moyens, contrôle l’exécution des
travaux. Le système de pilotage exploite les informations qui circulent, organise
le fonctionnement du système, décide des actions à conduire sur le système
opérant et raisonne en fonction des objectifs et des politiques de l’entreprise.
Il assigne des objectifs à l’organisation, analyse l’environnement et le
fonctionnement interne à l’organisation, contrôle le système opérant. Il est relié
aux autres systèmes par des flux d’informations internes.
1.6.2. Le système opérant
Le système opérant est l’ensemble des moyens humains, matériels,

organisationnels qui exécutent les ordres du système de pilotage. Il assure le
fonctionnement du système global, son activité est contrôlée par le système de
pilotage. Le Système opérant reçoit les informations émises par le système de
pilotage, il se charge de réaliser les tâches qui lui sont confiées, génère à son
tour des informations en direction du système de pilotage (qui peut ainsi
contrôler les écarts et agir en conséquence). Le système opérant englobe toutes
les fonctions liées à l’activité propre de l’entreprise : facturer les clients, régler
les salariés, gérer les stocks.
1.6.3. Système d’Information
1.6.3.1. Qu'est-ce qu'une information ?
Idéalement, l'information réduit l'incertitude concernant un état ou un

événement. Par exemple, l'information selon laquelle il y a du vent réduit
l'incertitude sur le fait que la promenade en bateau sera agréable. Un système
d'information est la base de l'interaction entre l'utilisateur et l'analyste. Il fournit
des instructions, des commandes et un retour d'information. Il détermine la
nature des relations entre les décideurs.
- ‘’Un ensemble de dispositifs, de procédures et de systèmes d'exploitation

conçus autour de critères basés sur l'utilisateur pour traiter l'information et la
communiquer à l'utilisateur pour la planification, le contrôle et la performance.
Dans l'analyse du système, il est important de garder à l'esprit qu'envisager un

système alternatif signifie améliorer un ou plusieurs de ces critères."
Le système d’information est l’ensemble des ressources humaines,

techniques et financières qui fournissent, utilisent, compilent, traitent et
distribuent l’information de l’organisation. Il alimente l’organisation en
informations d’origines diverses (internes ou externes).
Les systèmes d’information sont censés aider les utilisateurs dans leurs
activités : stocker et restaurer l’information, faire des calculs, permettre
une communication efficace, ordonnancer et contrôler des tâches, etc.
1.6.4. LES ACTIVITÉS DU SYSTÈME D’INFORMATION
- Recueil ou collecte de l’information

Pour fonctionner, le système doit être alimenté : Enregistrer une information
(support papier, informatique…) avant son traitement. Les informations
proviennent de différentes sources, internes ou externes.
Les sources externes proviennent de l’environnement du système. Il s’agit
généralement de flux en provenance des partenaires du système (clients,
fournisseurs, administrations…). De plus en plus, l’entreprise doit être à l’écoute
de son environnement pour anticiper les changements et adapter son
fonctionnement. Le développement des moyens de communication (internet en
particulier) permet de trouver plus facilement de l’information mais son
exploitation reste délicate (qualité et fiabilité des informations).
En interne, le système d’information doit être alimenté par les flux générés par
les différents acteurs du système. Ces flux résultent de l’activité du système :
approvisionnements, production, gestion des salariés, comptabilité, ventes…
La plupart de ces flux sont parfaitement formalisés (existence de procédures
bien définies) mais il existe également des flux d’information informelle (climat
social, savoir-faire non formalisés…) qui sont par définition très difficiles à
recueillir et à exploiter mais qui ont parfois beaucoup d’importance.
Les informations jugées pertinentes pour l’organisation doivent être saisies.
Cette opération est généralement onéreuse car elle nécessite souvent une
intervention humaine. Beaucoup d’efforts ont été déployés pour tenter
d’automatiser le recueil d’informations (système en temps réel, lecture optique,
numérisation, robots d’analyse de contenus…). L’information est précieuse, vitale
même pour les entreprises mais elle a aussi un coût.
- Mémorisation de l’information (conserver, archiver, ….)

Une fois l’information saisie, il faut en assurer la pérennité, c’est à dire garantir
un stockage durable et fiable. Aujourd’hui, le support privilégié de l’information
est constitué par les moyens mis à disposition par les disques des ordinateurs
(magnétiques ou optiques : disques durs, Cédéroms, DVD, bandes et cassettes…)
; cependant, le papier reste un support très utilisé en entreprise (conservation
des archives papiers). Les informations stockées dans les ordinateurs le sont sous
forme de fichier ou organisés afin d’être plus facilement exploitables sous la
forme d’une base de données. Le système de gestion de bases de données
(SGBD) est donc une composante fondamentale d’un système d’information.
Pour être exploitées dans une base de données, les informations doivent subir
une transformation car l’ordinateur ne sait stocker que des données. A l’inverse,
on doit être capable de reconstituer de l’information à partir des données
stockées dans la base. Le stockage de l’information nécessite de mettre en
œuvre des moyens importants et coûteux : ordinateurs, logiciels spécialisés,
supports numériques, personnels, dispositifs de sécurité…
- Traitement de l’information
Pour être exploitable, l’information subit des traitements : effectuer des opérations
(calcul, tri, classement, résumé, …) Là encore, les traitements peuvent être
manuels (c’est de moins en moins souvent le cas) ou automatiques (réalisés par
des ordinateurs). Les principaux types de traitement consistent à rechercher et
à extraire de l’information, consolider, comparer des informations entre elles,
modifier, supprimer des informations ou en produire de nouvelles par
application de calculs.
- Diffusion de l’information
Pour être exploitée, l’information doit parvenir dans les meilleurs délais à son
destinataire : transmettre à la bonne personne (éditer, imprimer, afficher, … une
information après traitement). Les moyens de diffusion de l’information sont
multiples : support papier, forme orale et de plus en plus souvent, utilisation de
supports numériques qui garantissent une vitesse de transmission optimale et
la possibilité de toucher un maximum d’interlocuteurs. Ceci est d'autant plus vrai
à l'heure d'Internet et de l'interconnexion des systèmes d'information.
1.6.5. Composants du Système d’Information
Les composants d'un système peuvent être classés en fonction de son modèle
IPO (Input, Process, Output). Nous présentons maintenant les composantes du
modèle IPO pour un système d'information. Les données sont le composant
d'entrée et l'information est le composant de sortie. Le processus qui
transforme les données en informations peut lui-même consister en des
composants et être lié à des composants tels que. Les composants du système
d’Information sont énumérés ci-dessous :
a. Utilisateurs finaux.
L'ordinateur est important mais les personnes qui utilisent et travaillent avec le
système d'information sont l'aspect le plus vital du système. Les systèmes
d'information sont destinés aux utilisateurs finaux. L'analyste doit reconnaître
que les utilisateurs finaux font partie intégrante du système d’information.
b. Système d’Information
Il s'agit de l'agencement de composants indépendants qui interagissent pour

soutenir les opérations, la gestion et les besoins d'information d'une entreprise
en matière d'opérations, de gestion et de prise de décision. Un système
d'information est le sous-système du système d'entreprise. L'objectif d'un
système d'information est de répondre aux besoins d'information de ses
utilisateurs finaux. Un système d'information crée, collecte, stocke des
données et traite ces données pour en faire des informations utiles.
c. Méthodes et procédures
Méthodes : désignent les méthodes employées dans les systèmes d'information

informatisés. Les systèmes d'information informatisés transforment les données
en informations par l'une des méthodes suivantes :
(i) Traitement par lots.
Il s'agit de collecter les données, de les stocker par lots et de les traiter une ou
deux fois par jour.
(ii) Traitement en ligne.

Dans cette méthode, les données sont traitées au fur et à mesure qu'elles se
présentent ou qu'elles sont disponibles.
(iii) Traitement en temps réel
Dans le traitement en temps réel, les données sont traitées en temps réel (ce qui
exige une réponse très rapide).
Procédures : Les procédures décrivent comment les utilisateurs finaux

effectuent leur travail et prennent des décisions. Les procédures ne font pas
référence aux programmes informatiques.
d. Le matériel informatique.
L'information peut inclure une variété de composants matériels, y compris des

machines à dupliquer, des calculatrices et un système informatique. Les
composants informatiques comprennent le scanner, l'imprimante, l’ordinateur,
les terminaux à tube cathodique et les lecteurs de disques magnétiques.
e. Logiciels informatiques
La programmation informatique est la responsabilité des programmeurs

informatiques. Il existe de nombreux programmes d'application qui soutiennent
les fonctions de l'entreprise. Il existe également des programmes qui font
fonctionner l'ordinateur lui-même et allouent les ressources aux utilisateurs de
l'ordinateur. Les programmeurs sont responsables des programmes et les
analystes système sont responsables des spécifications des programmes.
Progiciels : Les progiciels sont des programmes informatiques qui sont achetés
plutôt que construits.
f. Stockages des données.
Les données internes du système d'information sont stockées dans des fichiers
et des bases de données. Ces entrepôts de données peuvent être soit manuels
(armoire à dossiers) ou automatisés (disque d'ordinateur).
g. Procédures internes
La rétroaction et le contrôle sont un concept et une caractéristique du système

qui doivent être ajoutés à tout système pour en assurer le bon fonctionnement.
Il se compose d'utilisateurs finaux, de méthodes et de procédures, de stockage

de données, et éventuellement de logiciels et de matériel. Il réagit aux
informations générées par le système d'information. Le contrôle interne met
directement en œuvre les modifications du système d'information ou notifie aux
utilisateurs finaux que le système ne fonctionne pas correctement. C'est le sous-
système du système d'information.
Exemple de Systèmes d’Information

- Gestion des réparations dans un garage automobile,
- Gestion de la scolarité dans une école,
- Gestion des vols dans une compagnie aérienne
- Gestion des inscriptions dans une école, université,
- Gestion des Stocks dans un magasin, boutique
- La gestion d’une bibliothèque (la gestion des abonnés, la gestion des achats
de livres, La gestion de la restauration de livres de valeur etc.)
CHAPITRE II : ANALYSTE DE SYSTÈMES
L'analyste de système est une personne qui mène une étude méthodique et
une évaluation d'une activité telle que l'entreprise pour identifier les objectifs
souhaités afin de déterminer la procédure par laquelle ces objectifs peuvent être
atteints.
L’analyste de systèmes est un spécialiste qui étudie les problèmes et les besoins
d'une organisation afin de déterminer comment les personnes, les données, les
processus et les technologies de l'information peuvent améliorer l'activité de
l'entreprise.
Cet analyste de système joue un rôle majeur dans le développement du système

candidat (futur) et dans la définition de ses avantages. L'analyste est une
personne dotée d'une compétence unique. Le travail de l'analyste de système
ne se limite pas au traitement des données, car il fait largement appel aux
personnes, aux procédures et à la technologie.
Le bon sens et une approche disciplinée de la résolution des problèmes font

donc partie de l'analyse.
De nombreuses personnes dans le monde des affaires peuvent acquérir les

compétences requises par un analyste.
II.1. Compétences en matière d'analyse des systèmes
Compétences interpersonnelles. Compétences techniques
Compétences en Compétences
Créativité Résolution de
communication Pédagogiques
problèmes
Compétences de Vendre ses Gestion de Attitude des

compréhension Compétences projet questions
1. Compétences interpersonnelles.
La première compétence interpersonnelle concerne la relation et l'interface de

l'analyste avec les personnes dans l'entreprise (système) ; elle est utile pour
établir la confiance, visualiser les conflits et communiquer des informations.
Parmi les compétences interpersonnelles, nous pouvons citer :
i) Compétences en communication :
La première compétence indispensable à l'analyste de système est la capacité

de communication. Cela signifie que l'analyste doit être capable de
communiquer ou de transmettre ses idées à l'utilisateur de manière fiable et
efficace. La communication, ce n'est pas seulement des rapports, le téléphone,
c'est des gens qui parlent, qui s'écoutent, qui s'échangent des expériences. Il
faut donc ouvrir des canaux de communication et, pour une meilleure
communication, l'analyste doit pouvoir parler la langue de l'utilisateur.
ii) Capacité de compréhension :
Cela signifie que l'analyste doit identifier le problème et accéder à son résultat
ou à ses impacts. Il doit comprendre les objectifs de l'entreprise et être sensible
à l'impact du système sur les personnes au travail.
iii) Compétences pédagogiques
L'analyste doit avoir des compétences en matière d'enseignement car il doit

former les gens à l'utilisation du système et apporter son soutien à l'utilisateur
en cas de besoin particulier lorsque le système est utilisé.
iv) Attitude de ventre ses compétences
Vendre des idées et promouvoir l'invocation est la résolution de problèmes à

l'aide d'un ordinateur.
2) Compétences techniques :
Les compétences techniques, quant à elles, se concentrent sur les procédures et

les techniques d'analyse des opérations, des systèmes et de l'informatique. Elles
sont nécessaires pour rendre un système techniquement solide et fiable.
i)Créativité :
L'analyste doit avoir un esprit créatif car il doit aider l'utilisateur à modeler ses
idées en plans concrets et à développer le système candidat pour répondre aux
exigences des utilisateurs.
ii)Résolution de problèmes :
Cela signifie que l'on réduit le problème à son niveau élémentaire pour l'analyser
et développer la solution alternative à un problème donné et comprendre les
avantages et les inconvénients du système candidat.
iii) Gestion de projet :
L'analyste de systèmes doit avoir les compétences nécessaires pour gérer un

projet (système) de manière fiable. La gestion de projet implique l'établissement
d'un calendrier, le respect des délais (donner du temps), la coordination des
efforts de l'équipe et la gestion des coûts et des dépenses.
iv) Attitude interrogative :
Savoir quoi, quand, où, qui et comment fonctionne un système. Connaissance

des bases de l'ordinateur et des fonctions ou des opérations du système
d’entreprise.
Conclusion :
Au cours de l'analyse et du développement du système, l'analyste de systèmes

a besoin de compétences personnelles et techniques, bien que le besoin de ces
deux compétences dépende de la phase de développement du système. Par
exemple, au cours de l'analyse et de la mise en œuvre, les compétences
interpersonnelles sont plus nécessaires, tandis que dans la phase de conception,
les compétences techniques sont largement requises. Cela peut être présenté
dans un tableau.
II.2. RÔLE COMPLET / POLYVALENT DE L'ANALYSTE DE SYSTÈMES
Un analyste de systèmes joue un rôle très important dans le développement du

système qui est très complet et polyvalent. Ainsi, un Analyste de systèmes peut
être par exemple :
1. Agent de changement
2. Enquêteur et contrôleur
3. Architecte
4. Psychologue
5. Vendeur
6. Motivateur
7. Politicien
1. Agent de changement
Le premier rôle de l'analyste de systèmes dans le développement du système

est celui d'un agent de changement, car l'analyste est la personne qui introduit
le changement et la réorientation en développant le système candidat. Mais il
est aussi très important que le changement soit accepté par l'utilisateur et l'un
des moyens d'assurer l'acceptation par l'utilisateur est de le faire participer à la
conception et à la mise en œuvre.
Styles pour introduire le changement :
Dans la règle de l'agent de changement, l'analyste peut choisir différents styles

pour introduire le changement. Le style persuasif ou imposant sont adaptés.
Lorsque l'utilisateur semble avoir une certaine tolérance au changement, le style

persuasif ou catalyseur est approprié. En revanche, lorsque des changements
radicaux sont nécessaires, il faut adopter le style imposant ou confrontant.
Quel que soit le style utilisé, l'objectif est cependant le même : obtenir
l'acceptation du système candidat avec un minimum de résistance.
2. Investigateur et contrôleur :
Dans le développement du système candidat, l'analyste du système joue

également un rôle d'enquêteur. Il/elle définit un problème : il/elle rassemble les
informations recueillies pour déterminer comment le système actuel ne

fonctionne pas bien et quels changements pourraient corriger le problème.
À cet égard, ce travail est similaire à celui d'un enquêteur, car l'analyste doit
également extraire le problème réel du système existant.
Contrôleur : Le rôle de contrôleur est lié à celui d'enquêteur. L'analyste doit

surveiller les programmeurs par rapport au temps, au coût et à la qualité.
L'analyste doit surveiller le projet pour qu'il soit mené à bien et qu'il soit
efficace.
3.Architecte :
La fonction principale d'un architecte est de faire le lien entre les exigences
abstraites du client en matière de conception et le plan de construction détaillé
du constructeur. Il peut être comparé au rôle de l'analyste en tant que lien entre
les exigences logiques de conception de l'utilisateur et les détails.
En tant qu'architecte, l'analyste crée également une conception physique

détaillée du système candidat.
4. Psychologue :
Dans le développement de systèmes, les systèmes sont construits autour d'une

personne, ce qui est peut-être un peu difficile, mais l'analyste joue le rôle d'un
psychologue dans la mesure où il/elle atteint les gens, interprète leurs pensées,
accède à leur comportement et tire des conclusions de ces interactions.
L'analyste doit donc comprendre les relations interfonctionnelles. Il est très

important que l'analyste soit conscient des sentiments et de la perception des
gens et qu'il soit prêt à contourner les choses de manière gracieuse.
5.Vendeur des idées :
L'analyste joue également un rôle de vendeur car il/elle doit vendre ses idées et
obtenir l'acceptation des utilisateurs. La vente du changement peut donc être
aussi cruciale que l'initialisation du changement : la présentation orale de la
proposition de système a pour objectif de convaincre l'utilisateur du système et
se déroule en fait à chaque étape du cycle de vie du système. Les compétences
et la conviction de tous sont donc très importantes pour le succès du système.
6. Motivateur :
Le système candidat doit être conçu et acceptable pour l'utilisateur ;

l'acceptation du système est obtenue par la participation de l'utilisateur, la
formation de l'utilisateur et une motivation adéquate pour l'utilisation du
système.
Le niveau de l'analyste du système en tant que facteur de motivation devient

très important au cours des premières semaines après la mise en œuvre et
pendant la période où les nouvelles personnes sont formées pour travailler avec
le nouveau système.
7. Politicien :
Le rôle du politicien est lié à celui du motivateur. Sur un système candidat,

l'analyste doit satisfaire toutes les parties impliquées dans la démocratie et dans
les relations avec les gens, il peut faire accepter le système. Comme un
politicien doit avoir le soutien de ses partisans, le but de l'analyste est le
même : avoir le soutien du personnel utilisateur, il représente leur pensée
et essaie d'atteindre leurs objectifs.
CHAPITRE III : CYCLE DE VIE DU DÉVELOPPEMENT DU SYSTÈME

D’INFORMATION
III.1 Introduction
L'analyste de système donne un sens et une direction à un projet de

développement de système. Un système candidat est abordé après que
l'analyste a bien compris les besoins et les problèmes des utilisateurs.
Une solution viable est élaborée, puis communiquée.
Les systèmes candidats dépassent souvent les frontières des utilisateurs de

l'organisation. Par exemple, un système de facturation peut impliquer des
utilisateurs du service des commandes, du service du crédit, de l'entrepôt et du
service comptable.
Pour s'assurer que les besoins de tous les utilisateurs sont satisfaits, un groupe
de projet qui représente chaque utilisateur travaille avec l'analyse pour réaliser
un projet de développement du système d’information.
Le SYSTÈME CANDIDAT :
"Le système qui va être développé peut-être un système entièrement nouveau

ou révisé". Le cycle de vie du développement du système d’information se
concentre donc sur les procédures de développement ou de construction d'un
système informatique pour aider l'utilisateur à gérer une entreprise ou à prendre
des décisions de manière efficace.
III.2 Les étapes du cycle de vie du développement du système

d’information
La méthode du cycle de vie du développement du système est classiquement
considérée comme l'ensemble des activités que les analystes, les concepteurs et
les utilisateurs réalisent pour développer et mettre en œuvre un système
d'information. Les différentes étapes de l'activité sont étroitement liées les unes
aux autres, même l'ordre des étapes de ces activités est difficile à déterminer
(spécification des besoins de l’utilisateur, étude de faisabilité, analyse,
conception, implémentation ou mise en œuvre, formation des utilisateurs
et maintenance).
III.2.1. Spécification des besoins de l’utilisateur
La première étape du développement d'un système est la spécification de besoin

des utilisateurs, car il faut savoir quel est le problème avant de pouvoir le
résoudre. Il s'agit des bases d'un système candidat pour améliorer le système
d'information ou une procédure. Par exemple, si un directeur d'entreprise reçoit
des plaintes concernant un problème spécifique de l'entreprise, la première
tâche qu'il doit accomplir est de mener une enquête ou une investigation initiale
pour déterminer le problème et si un système alternatif peut le résoudre. Si le
problème est suffisamment grave, la direction peut demander à un analyste de
l'examiner. Une telle mission implique un engagement, surtout lorsque
l'analyste est recruté à l'extérieur.
La première tâche de l'analyste est de préparer un énoncé de problème qui

spécifie la portée et l'objectif du problème, puis de le revoir avec l'utilisateur
pour en vérifier l'exactitude.
III.2.1.1. Stratégies pour déterminer les besoins des utilisateurs
Il existe trois stratégies principales ou approches générales pour obtenir des

informations concernant les besoins de l'utilisateur : (1) poser des questions, (2)
obtenir des informations du système d'information existant et le prototypage.
1. Poser des questions : cette stratégie permet d'obtenir des informations des
utilisateurs en les interrogeant simplement sur les exigences. Elle suppose un
système stable dans lequel les utilisateurs sont bien informés et capables de
surmonter les préjugés dans la définition de leurs problèmes. Il existe trois
principales méthodes d'interrogation.
- Les questions peuvent être ouvertes ou fermées. Une question ouverte permet
à la personne interrogée de formuler une réponse. Elle est utilisée lorsque les
sentiments ou les opinions sont importants.
Par exemple, "Comment évaluez-vous le dernier ajout à votre matériel ?"
En revanche, une question fermée demande une réponse parmi un ensemble

spécifique de réponses. Elle est utilisée lorsque les réponses factuelles sont
connues.
Par exemple, "Depuis combien de temps êtes-vous responsable du centre

informatique ?"
- Le brainstorming est une technique utilisée pour générer de nouvelles idées

et obtenir des informations générales nécessaires. Cette méthode est une
approche du brainstorming qui demande à chaque participant de définir
des solutions idéales, puis de sélectionner la meilleure solution réalisable.
Elle fonctionne bien pour les utilisateurs qui ont une connaissance du système
mais qui ont du mal à accepter de nouvelles idées.
- Le consensus de groupe demande aux participants leurs attentes concernant

des variables spécifiques. Dans une enquête Delphi, par exemple, chaque
participant remplit un questionnaire. Les résultats sont résumés et remis aux
participants avec un questionnaire de suivi.
Les participants sont invités à modifier leurs réponses. Les résultats sont à
nouveau résumés et renvoyés aux participants. Ce débat par questionnaire se
poursuit jusqu'à ce que les réponses des participants soient suffisamment
convergentes. Cette méthode présente un avantage par rapport au
brainstorming dans la mesure où les participants ne sont pas soumis à la
pression psychologique d'autres personnes ayant une autorité ou une
influence.
2. Obtenir des informations à partir du système d'information existant.
La détermination des informations à partir d'une application existante est

appelée l'approche de l'analyse des données. Elle demande simplement à
l'utilisateur quelles informations sont actuellement reçues et quelles autres
informations sont nécessaires. Elle s'appuie largement sur l'utilisateur pour
formuler ses besoins en information.
L'analyste examine tous les rapports, discute avec l'utilisateur de chaque

élément d'information examiné et détermine les besoins d'information non
satisfaits en interrogeant l'utilisateur.
3. Prototypage :
La troisième stratégie pour déterminer les besoins en information de l'utilisateur

est utilisée lorsque l'utilisateur ne peut pas établir avec précision ses besoins en
information avant la construction du système d'information. La raison peut en
être l'absence d'un modèle existant sur lequel fonder les exigences ou une
difficulté à visualiser les systèmes candidats. Dans ce cas, l'utilisateur doit

s'ancrer sur des systèmes réels à partir desquels des ajustements peuvent être
effectués. Par conséquent, l'approche de découverte itérative capture un
ensemble initial d'exigences d'information et construit un système pour
répondre à ces exigences, ce qui peut être dû à l'absence d'un modèle existant
sur lequel baser les exigences ou à une difficulté à visualiser les systèmes
candidats. Au fur et à mesure que l'utilisateur acquiert de l'expérience dans son
utilisation, il demande des exigences supplémentaires ou des modifications
(itérations), dans le système ; en substance, les exigences en matière
d'information sont découvertes en utilisant le système.
Le prototypage convient aux environnements où il est difficile de formuler un

modèle concret pour définir les besoins en information et où les besoins
d'information de l'utilisateur évoluent, comme c'est le cas dans les systèmes de
gestion des données.
III.2.1.2. Conduire une investigation
Les données que les analystes recueillent au cours des enquêtes préliminaires
sont collectées par deux méthodes principales : l'étude ou examiner des
documents et les entretiens avec le personnel de l'entreprise sélectionné.
1. Etudes des documents de l'organisation
Les analystes qui mènent l'enquête commencent par se renseigner sur

l'organisation impliquée dans, ou affectée par, le projet. Par exemple, pour
examiner une proposition de systèmes d'inventaire, il faut d'abord savoir
comment fonctionne le service des stocks et qui sont les responsables et les
superviseurs. Les analystes peuvent généralement obtenir ces détails en
examinant les organigrammes et en étudiant les procédures opérationnelles
écrites.
Les procédures décrivent comment le processus d'inventaire doit fonctionner et

identifient les étapes les plus importantes de la réception, de la gestion et de la
distribution du stock.
2. Conduire des entretiens ou des interviews
Les documents écrits expliquent aux analystes comment les systèmes devraient
fonctionner, mais ils ne sont pas toujours suffisamment détaillés pour permettre
de prendre une décision sur les mérites d'une proposition de système et ils ne
présentent pas non plus les points de vue des utilisateurs sur les opérations
actuelles. Pour obtenir ces détails, les analystes ont recours à des entretiens.
Les entretiens permettent aux analystes d'en apprendre davantage sur la nature
de la demande de projet et la raison pour laquelle elle a été soumise. Pour
atteindre l'objectif des entretiens, les analystes doivent s'assurer de mettre
l'accent sur la demande et le problème auquel elle répond.
En d'autres termes, les entretiens doivent fournir des détails qui expliquent
davantage le projet et montrent si l'aide est méritée sur le plan économique,
opérationnel et technique. L'élaboration d'une solution à la situation vient plus
tard, au cours de l'enquête détaillée.
Habituellement, les entretiens d'enquête préliminaire ne concernent que le

personnel de direction et personnel de supervision.
III.2.2. ÉTUDE DE FAISABILITÉ
De nombreuses études de faisabilité sont désillusionnantes, tant pour les

utilisateurs que pour les analystes. Tout d'abord, l'étude présuppose souvent
qu'au moment de la préparation du document de faisabilité, l'analyste est en
mesure d'évaluer les solutions. Deuxièmement, la plupart des études tendent à
négliger la confusion inhérente au développement de systèmes - les contraintes
et les attitudes supposées.
Si l'étude de faisabilité doit servir de document de décision, elle doit répondre

à trois questions clés :
1. Existe-t-il une nouvelle et meilleure façon de faire le travail qui profitera à

l'utilisateur ?
2. Quels sont les coûts et les économies de l'alternative (s) ?
3. Qu'est-ce qui est recommandé ?
Les projets les plus réussis ne sont pas nécessairement les plus grands ou les plus
visibles dans une entreprise, mais plutôt ceux qui répondent réellement aux
attentes des utilisateurs. Il y a plus de projets qui échouent à cause d'attentes
exagérées que pour toute autre raison.
III.2.2.1. CONSIDÉRATIONS DE FAISABILITÉ
Trois considérations clés sont impliquées dans l'analyse de faisabilité :

économique, technique et comportementale. Examinons brièvement chacune
de ces considérations et la façon dont elles sont liées à l'effort en matière de
systèmes.
1. Faisabilité économique
L'analyse économique est la méthode la plus fréquemment utilisée pour évaluer

l'efficacité d'un système candidat. Plus communément appelée analyse
coûts/avantages, la procédure consiste à déterminer les avantages et les
économies attendus d'un système candidat et à les comparer aux coûts.
Si les avantages l'emportent sur les coûts, la décision est prise de concevoir et
de mettre en œuvre le système. Dans le cas contraire, il faudra justifier ou
modifier le système proposé pour qu'il ait une chance d'être approuvé.
2. Faisabilité technique
La faisabilité technique concerne le système informatique existant (matériel,

logiciel, etc.) et dans quelle mesure il peut supporter l'ajout proposé. Par
exemple, si l'ordinateur actuel fonctionne à 80 % de sa capacité - un plafond
arbitraire - l'exécution d'une autre application pourrait surcharger le système ou
nécessiter du matériel supplémentaire.
Cela implique des considérations financières pour permettre des améliorations

techniques. Si le budget est une contrainte sérieuse, le projet est jugé non
réalisable.
3. Faisabilité comportementale
Les gens sont par nature résistants au changement, et les ordinateurs sont
connus pour faciliter le changement, faciliter le changement. Il convient
d'estimer la réaction que le personnel utilisateur est susceptible d'avoir à l'égard
du développement d'un système informatisé. Il est de notoriété publique que
les installations informatiques ont un rapport avec la rotation, les transferts, le
recyclage et les changements de statut professionnel des employés.
Il est donc compréhensible que l'introduction d'un système candidat exige un

effort particulier pour éduquer, vendre et former le personnel à de nouvelles
méthodes de travail.
III.2.2.2. Étapes de l'analyse de faisabilité
L'analyse de faisabilité comporte huit étapes à savoir :
1. Constituer une équipe de projet et nommer un chef de projet.
2. Préparer les organigrammes du système.
3. Énumérer les systèmes candidats potentiels.
4. Décrire et identifier les caractéristiques des systèmes candidats.
5. Déterminer et évaluer la performance et la rentabilité de chaque système

candidat.
6. Pondérer les données sur les performances et les coûts des systèmes.
7. Sélectionner le meilleur système candidat.
8. Préparer et présenter la directive finale du projet à la direction.
1. Former une équipe de projet et nommer un chef de projet
Le concept d'une équipe de projet est que les futurs utilisateurs du système
doivent être impliqués dans sa conception et sa mise en œuvre dans sa
conception et sa mise en œuvre. Leurs connaissances et leur expérience dans le
domaine des opérations sont essentielles à la réussite du système.
Pour les petits projets, l'analyste et un assistant suffisent généralement ;

cependant, les études plus complexes nécessitent une équipe de projet. L'équipe
est composée d'analystes et de personnel utilisateur - une expertise collective
suffisante pour concevoir une solution au problème. Dans de nombreux cas, un
consultant extérieur et un spécialiste de l'information se joignent à l'équipe
jusqu'à ce que le travail soit terminé.
Les projets sont planifiés pour occuper une période de temps spécifique, allant
de plusieurs semaines à plusieurs mois. L'analyste senior de système est
généralement désigné comme chef de projet. Il s'agit généralement de l'analyste
le plus expérimenté de l'équipe. La nomination est temporaire et dure aussi
longtemps que le projet. Il faut organiser des réunions régulièrement pour
maintenir l'élan et accomplir la mission - la sélection du meilleur système
candidat. Un compte rendu de l'avancement des travaux est établi à chaque
réunion.
2. Préparer les organigrammes du système
L'étape suivante de l'étude de faisabilité consiste à préparer des organigrammes

généralisés pour le système. Les tableaux qui orientent l’information et les
diagrammes de flux de données préparés lors de l'enquête initiale sont
également examinés à ce stade. Les diagrammes font ressortir l'importance des
entrées, des sorties et du flux de données entre les points clés du système
existant. Tous les autres organigrammes nécessaires à l'évaluation détaillée sont
complétés à ce stade.
3. Énumération des systèmes candidats potentiels
Cette étape identifie les systèmes candidats qui sont capables de produire les
sorties incluses dans les organigrammes généralisés. Cela nécessite une
transformation des modèles de systèmes logiques en modèles de systèmes
physiques. Un autre aspect de cette étape est la prise en compte du matériel qui
peut gérer l'ensemble des exigences du système.
Dans cette conception, le traitement réel est géré par le micro-ordinateur, tandis
que les informations telles que les paiements et les crédits sont transmises aux
fichiers de l'ordinateur principal pour un ajustement approprié sur le compte
chèque du client. La question qui se pose ici est la suivante : quel micro-
ordinateur (IBM, Apple, Digital, etc.) doit-on choisir ? Cette question est abordée
à l'étape 6 de l'étude.
Un aspect important du matériel c’est le traitement et la mémoire principale. Il

existe un grand nombre d'ordinateurs dont la taille de traitement, les capacités
de mémoire principale et le support logiciel diffèrent. L'équipe de projet peut
contacter les fournisseurs pour obtenir des informations sur les capacités de
traitement du système disponible.
4. Décrire et identifier les caractéristiques du système candidat
À partir de systèmes candidat envisagé, l'équipe commence une évaluation

préliminaire afin d'essayer de le réduire à un nombre raisonnable. Les
connaissances techniques et l'expertise dans le domaine du matériel et des
logiciels sont essentielles pour déterminer ce que chaque système candidat peut
et ne peut pas faire.
5. Déterminer et évaluer la performance et le rapport coût-efficacité de

chaque système candidat.
Les performances de chaque système candidat sont évaluées par rapport aux
exigences de performance du système définies avant l'étude de faisabilité. Quels
que soient les critères, il doit y avoir une correspondance aussi étroite que
possible, bien que des compromis soient souvent nécessaires pour sélectionner
le meilleur système.
Le coût englobe la conception et l'installation du système. Il comprend la

formation des utilisateurs, la mise à jour des installations physiques et la
documentation. Les critères de performance du système sont évalués par
rapport au coût de chaque système afin de déterminer quel système est
susceptible d'être le plus rentable et de répondre aux exigences de performance.
L'analyste peut tracer les critères de performance et les coûts de chaque

système pour déterminer comment chacun se comporte.
Les coûts sont plus faciles à déterminer lorsque les avantages du système sont
tangibles et mesurables. Un autre facteur à prendre en compte est le coût de la
conception et du développement de l'étude.
6. Pondérer les données sur les performances et les coûts du système
Dans certains cas, les données sur les performances et les coûts de chaque
système candidat indiquent quel système est le meilleur choix ? Ce résultat met
fin à l'étude de faisabilité.
La matrice d'évaluation des performances/coûts ne permet pas toujours

d'identifier clairement le meilleur système. L'étape suivante consiste donc à
pondérer l'importance de chaque critère en appliquant un chiffre de notation.
Ensuite, le système candidat ayant obtenu le score total le plus élevé est
sélectionné.
La procédure pour la pondération des systèmes candidats est simple : - 1.
1. Attribuer un facteur de pondération à chaque critère d'évaluation en fonction

de l'effet du critère sur le succès du système.
. Par exemple, si le critère de convivialité est deux fois plus important que le
facteur de précision, la convivialité se voit attribuer un poids de 4 et la précision
un poids de 2.
2. Attribuez une note quantitative à la note qualitative de chaque critère. Par

exemple, (mauvais, passable, bon, très bon, excellent) peuvent se voir
attribuer des valeurs respectives (1,2,3,4,5).
3. Multipliez le poids attribué à chaque catégorie par la note relative pour

déterminer le pour déterminer le score.
4. Additionnez la colonne des scores pour chaque système candidat.
Ainsi, la matrice d'évaluation pondérée des candidats est préparée en suivant

ces étapes, qui, en soi, aide à l'étape suivante.
7. Sélectionner le meilleur système candidat
Le système ayant obtenu le score total le plus élevé est considéré comme le
meilleur système. Cela suppose que les facteurs de pondération sont justes et
que la notation de chaque critère d'évaluation est exacte. Le critère du potentiel
de croissance a généralement le poids le plus élevé, et donc le plus grand effet
sur le score total. En outre, le développement du système et la formation des
utilisateurs sont également des pondérations élevées. En tout état de cause, la
direction ne doit pas effectuer la sélection sans avoir l'expérience nécessaire
pour le faire. La coopération et les commentaires de la direction sont toutefois
encouragés.
8. Rapport de faisabilité
L'aboutissement de l'étude de faisabilité est un rapport de faisabilité destiné à

la direction. Il évalue l'impact des changements proposés sur la ou les zones en
question. Le rapport est un document formel à l'usage de la direction,
suffisamment bref et non technique pour être compréhensible, mais
suffisamment détaillé pour servir de base à la conception du système candidat.
Il n'existe pas de format standard pour la préparation des rapports de faisabilité.

En général, les analystes choisissent généralement un format qui convient à
l'utilisateur et au système en question. Toutefois, la plupart des rapports
commencent par un résumé des conclusions et des recommandations, suivi des
détails du document.
Le fait de commencer par un résumé met en évidence l'essence du rapport, ce

qui donne à la direction la possibilité d'examiner les détails plus tard.
Le rapport contient les sections suivantes sections suivantes :
1. La lettre d'accompagnement présente formellement le rapport et indique

brièvement à la direction la nature, les conclusions générales et les
recommandations à prendre en compte.
2. La table des matières précise l'emplacement des différentes parties du
rapport. La direction se réfère rapidement aux sections qui la concernent.
3. L'aperçu est une explication narrative de l'objectif et de la portée du
projet, de la raison pour laquelle l'étude de faisabilité a été entreprise et
du ou des départements impliqués ou affectés de l'étude de faisabilité et
le(s) service(s) concerné(s) par le système candidat.
On y trouve également le nom des personnes qui ont mené l'étude, la
date de son début et d'autres informations qui expliquent les
circonstances entourant l'étude.
4. Des conclusions détaillées décrivent les méthodes utilisées dans le
système actuel. L'efficacité et l'efficience du système ainsi que les coûts
d'exploitation sont soulignés. La section fournit également une
description des objectifs et des procédures générales du système
candidat.
Une discussion sur les rapports de sortie, les coûts et les avantages permet
à la direction de se faire une idée des avantages et des inconvénients du
système candidat.
5. La justification économique détaille les comparaisons de coûts point par
point et les estimations de coûts préliminaires pour le développement et
l'exploitation du système candidat. L’analyse du retour sur investissement
(ROI) du projet est également incluse.
6. Les recommandations et les conclusions suggèrent à la direction le
système le plus avantageux et le plus rentable. Elles sont rédigées
uniquement à titre de recommandation, et non de commandement. Après
les recommandations, toute conclusion de l'étude peut être incluse.
7. Les annexes documentent toutes les notes et les données compilées au
cours de l'enquête. Elles sont placées à la fin du rapport pour référence.
Remarque : Il est rare que le rapport de faisabilité soit désapprouvé s'il a été
mené correctement. Lorsqu'une équipe de faisabilité a entretenu de bons
rapports avec l'utilisateur et son personnel, les recommandations sont plus
faciles à approuver.
Techniquement, le rapport n'est qu'une recommandation, mais il fait autorité. La

direction a le dernier mot. Son approbation est nécessaire avant de commencer
la conception du système.
Présentation orale
Le rapport de faisabilité est une bonne présentation écrite qui documente les
activités impliquant le système candidat. L'étape cruciale, cependant, consiste à
vendre le changement proposé. Invariablement, le chef de projet ou l'analyste
doit faire une présentation orale à l'utilisateur final. Bien qu'elle ne soit pas aussi
soignée que le rapport écrit, la présentation orale a plusieurs objectifs
importants. Les exigences les plus importantes pour l'analyste qui donne la
présentation orale sont les suivantes : (1) des compétences en communication
et des connaissances sur le système candidat qui peuvent être traduites dans un
langage compréhensible pour l'utilisateur et (2) la capacité de répondre aux
questions, de clarifier les problèmes, de maintenir la crédibilité et de reprendre
toute nouvelle idée ou suggestions.
DEUXIEME PARTIE : LA METHODE MERISE
Il faut ouvrir des cadenas différents avec des clés différentes (Proverbe chinois)
CHAPITRE I. PRESENTATION GENERALE DE MERISE
I.2. Introduction
MERISE (Méthode d’Étude et de Réalisation Informatique pour les

Systèmes d’Entreprise) est certainement le langage de spécification le plus
répandu dans la communauté de l’informatique des systèmes d’information, et
plus particulièrement dans le domaine des bases de données. Une
représentation Merise permet de valider des choix par rapport aux objectifs, de
quantifier les solutions retenues, de mettre en œuvre des techniques
d’optimisation et enfin de guider jusqu’à l’implémentation. Reconnu comme
standard, Merise devient un outil de communication. En effet, Merise réussit le
compromis difficile entre le souci d’une modélisation précise et formelle, et la
capacité d’offrir un outil et un moyen de communication accessible aux non-
informaticiens.
I.2. Historique de la méthode Merise

Merise est un acronyme signifiant Méthode d’Étude et de Réalisation
Informatique par les Sous Ensembles ou pour les Systèmes d’Entreprise.
La méthode Merise a comme objectif d’aider, de guider les
Informaticiens, dans leurs phases d’analyses, de conception et le
développement de l’applicatif.
Nous devons la création, l’étude et la mise en place de cette méthode à une
équipe de chercheurs et d’ingénieurs aixois (JeanLouis le Moigne, Hubert
Tardieu, Dominique Nancy, Henry Heckenroth, Daniel Pasco, Bernard Espinasse)
qui en posèrent les bases dans le milieu des années 1970.
Le ministère de l’Industrie vit en cette méthode un excellent moyen pour

standardiser et rationaliser les rapports existants entre les administrations et
leurs sous traitants. C’est pourquoi il finança quelque temps les recherches sur
la méthode Merise. Le challenge était de pouvoir proposer des outils ou des
méthodologies permettant aux donneurs d’ordres et aux développeurs de se
comprendre et ainsi de mieux appréhender chacun de leur côté, avec leur propre
culture professionnelle, l’ensemble du système d’information. La méthode

Merise présente comme avantage indéniable de permettre une définition claire
et précise de l’ensemble du Système d’Information et d’en définir correctement
le périmètre.
Cette méthode est actuellement enseignée aux étudiants se dirigeant vers des
études informatiques, mais aussi aux étudiants voulant suivre des études
comptables. Nous retrouvons là le besoin qui avait poussé le ministère de
l’Industrie à investir dans cette méthode. En effet, dans les petites et moyennes
entreprises qui n’ont souvent pas de service informatique c’est le comptable qui
est l’interlocuteur privilégié entre l’entreprise et le prestataire de services
informatiques.
Dominique Nancy, Henry Heckenroth rejoignirent Bernard Cohen créateur
de la société Cecima distributrice du logiciel Win’Design qui permet de
concevoir les différentes phases d’un projet piloté par la méthode Merise.
L’année 1981 a connu l’apparition de Merise version 1 qui s’est enrichie des
premières années d’expérience.
En 1991, la version 2 de Merise a vu le jour, elle est une extension de la

méthode Merise version 1, elle intègre les flux et les données aux principes
de traitement. La puissance de cette approche réside dans le fait qu’elle
permet de schématiser les niveaux d’abstraction et offre un niveau de
granularité adaptable à tous les besoins. Elle utilise :
– un modèle fonctionnel basé sur les diagrammes de flux ;
– un modèle statique basé sur l’Entité-Association enrichi de méthodes de
traitement ;
– un modèle dynamique des objets explicitant le contrôle et les interactions
des objets.
Merise sépare les données et traitements et définit trois niveaux d’abstraction
qui permettent de décomposer les préoccupations du concepteur.
– Le niveau conceptuel s’appuie sur les invariants, il répond à la question “quoi
– Le niveau organisation et logique précise les aspects pratiques (qui fait quoi
?) et la vision informatique de la solution (comment ?).
– Le niveau physique décrit l’outil informatique (avec quoi ?).
I.3. Principes de la Méthode

Cette méthode s’articule sur les points suivants :
■ Approche globale : aboutissant à une architecture d’ensemble, elle garantit
un bon niveau d’intégrité du système construit.
■ Conception descendante : partant des finalités de chaque activité de
l’entreprise et prenant évidement en compte les besoins des utilisateurs qui
valident le système proposé.
■ Etudes indépendantes des données et des traitements/ce n’est qu’après en
avoir établi des modèles séparés que les incidences réciproques seront prises
en compte pour assurer la cohérence du système.
■ Recherche des éléments invariants de l’organisation et analyse de chaque
niveau (conceptuel, logique et opérationnel) pour stabiliser le système sur
l’activité essentielle de l’entreprise.
■ Utilisation d’un formalisme apportant concision, précision, rigueur et facilitant
le dialogue entre les parties présentes du système.
I.4. Caractéristiques de MERISE

La méthode Merise se c aractérise par :
• une approche systémique en ayant une vue de l'entreprise en
termes de systèmes ;
• une séparation des données (le côté statique ) et des traitements
(le côté dynamique )
• une approche par niveaux .
Le but de cette méthode est d'arriver à concevoir un système d'information.
Un des concepts clés de la méthode Merise est la séparation des données

et des traitements.
La méthode MERISE est basée sur la séparation des données et des traitements à
effectuer en plusieurs modèles conceptuels et physiques. La séparation des
données et des traitements assure une longévité au modèle. En effet, l'agencement
des données n'a pas à être souvent remanié, tandis que les traitements le sont plus
fréquemment.
Cette méthode est donc parfaitement adaptée à la modélisation des problèmes

abordés d’un point de vue fonctionnel. Les données représentent la statique du
système d’information et les traitements sa dynamique. L’expression
conceptuelle des données conduit à une modélisation des données en entités
et en associations. Dans ce cours, nous écartons volontairement la modélisation

des traitements puisque nous ne nous intéressons à la méthode Merise que dans
la perspective de la modélisation de bases de données.
I.4.1. La séparation des données et des traitements.

1. Les données (ou informations)
L’information est l’émission ou la réception de signaux oraux ou écrits,
sonores, visuels ou multimédias dont le but est de déclencher les processus
alimentant l’échange, base naturelle et indispensable de l’animation de
l’organisation. Les informations se recueillent à l’intérieur du domaine à
étudier. La liste d’informations est constituée de plusieurs façons : l’interview,
l’étude des documents internes e t l ’étude des documents externes.
a. L’interview
Une des phases du recueil d’information est un entretien avec les différents
acteurs de l’organisation. Cet entretien permet de définir le périmètre de
l’applicatif futur. Les informations orales sont classées et regroupées en
parties distinctes. Ainsi, les informations concernant l’enregistrement des
données de l’organisation seront regroupées.
b. L’étude des documents internes

Les documents internes (factures, bons de livraison, ordres de fabrication)
recèlent des informations qui sont souvent omises lors des entretiens. Ces
oublis sont dus au caractère automatique et récurrent de ces informations.
Les personnes qui les manipulent au quotidien oublient souvent de les citer
tant elles leur paraissent évidentes.
c. L’étude des documents externes

L’étude des documents externes (factures des fournisseurs, bons de livraison
fournisseurs...) tout comme l’étude des documents internes permet de
découvrir des informations oubliées lors des interviews et de découvrir aussi
quelques règles de gestion. Pour ce recueil d’informations, il est nécessaire
de respecter certaines règles pour éviter des erreurs futures. Avant d’ajouter
une information, il est impératif de s’assurer qu’elle n’est pas déjà présente.
Par exemple, un numéro client peut apparaître sur un bon de livraison et sur
une facture. Ce n’est pas la peine de le répertorier deux fois.
De même, une information peut être synonyme d’une autre. Par exemple sur
le bon de livraison il apparaît « Code client » et sur la facture « Numéro
Client ». Il est impératif de ne garder qu’une seule des deux informations.
I.4.2. Une approche par niveaux

Pour la conception d’un SI, il est nécessaire de considérer quatre niveaux
d’étude :
● Le niveau conceptuel.
● Le niveau organisationnel.
● Le niveau logique.
● Le niveau physique.
1. Le niveau Conceptuel
Le niveau conceptuel c o n s is t e à concevoir le SI en faisant abstraction d e
toutes les contraintes t e c h n i q u e s o u organisationnelles et cela tant au
niveau des données que des traitements. Le niveau conceptuel répond à la
question Quoi ? (le quoi faire, avec quelles données).
Le niveau conceptuel :
- Exprime les choix fondamentaux de gestion, les objectifs de l’organisation
- Décrit les invariants de l’organisation, le métier de l’organisation
- Définit des activités, des choix de gestion, des informations, indépendamment
des aspects organisationnels, des aspects techniques de mise en œuvre du point
de vue :
- Des traitements : objectif, résultat, règle de gestion, enchaınement
- Des données : signification, structure, liens
Le formalisme Merise employé sera :

● Le Modèle Conceptuel de Communication (MCC).
● Le Modèle Conceptuel des Données (MCD).
● Le Modèle Conceptuel des Traitements (MCT).
2. Le niveau Organisationnel
Le niveau organisationnel a comme mission d’intégrer dans l’analyse les
critères liés à l’organisation étudiée. Le niveau organisationnel f e r a
préciser les notions de temporalité, d e chronologie d e s opérations,
d ’ u n i t é de lieu, définira les postes de travail, l’accès aux bases de données…
Les questions posées, au niveau des traitements, sont : Qui ? Où ? Quand

?
Le niveau organisationnel :
– Exprime les choix organisationnels de ressources humaines et matérielles
– Définit : la répartition géographique et fonctionnelle des sites de travail (du
point de vue des données et des traitements), le mode de fonctionnement :
temps réel ou temps différé, la répartition du travail homme/machine (degré et
type d’automatisation), les postes de travail et leur affectation, la volumétrie des
données, la sécurité des données, indépendamment des moyens de traitement
et de stockage de données actuels ou futurs.
– Les opérations conceptuelles vont être décomposées au niveau
organisationnel en une ou plusieurs opérations organisationnelles.
Le formalisme Merise employé sera :

●Le Modèle Organisationnel de Communication (MOC).
● Le Modèle Organisationnel des Données (MOD).
● Le Modèle Organisationnel des Traitements (MOT).
3. Le niveau Logique
Le niveau logique est indépendant du matériel informatique, des langages
de programmation ou de gestion des données. C’est la réponse à la
question Avec quoi ?
Le niveau Logique
– Exprime la forme que doit prendre l’outil informatique pour être adapté à
l’utilisateur, à son poste de travail, indépendamment de l’informatique
spécifique, des langages de programmation ou de gestion des données.
– Introduit la notion d’outils en tant que fonction réutilisable
– Décrit : le schéma de la base de données (relationnel, hiérarchique ou réseau),
c’est-à-dire les caractéristiques du mode de gestion des données, la répartition
des données sur les différentes unités de stockage, les volumes par unité de
stockage, ’optimisation des couts induits par le mode de gestion.
Le formalisme sera :
- Le Modèle Logique de Communication (MLC)
- Le Modèle Logique des Données (MLD).
- Le Modèle Logique des Traitements (MLT).
4. Le niveau Physique
Le niveau physique permet de définir l’organisation réelle (physique) des
données. Il apporte les solutions techniques, par exemple sur les méthodes
de stockage et d’accès à l’information. C’est la réponse au Comment ?
Le niveau Physique
– Traduit les choix techniques et la prise en compte de leurs spécificités
– Répond aux besoins des utilisateurs sur les aspects logiciels et matériels.
– Définit complètement : les fichiers, les programmes, l’implantation physique
des données et des traitements, les ressources à utiliser, les modalités de
fonctionnement.
Le formalisme employé sera :

- Le Modèle Physique de Communication (MPC).
- Le Modèle Physique des Données (MPD).
- Le Modèle Opérationnel et physique des Traitements (MOPT).
5. Tableau récapitulatif
LE CYCLE D’ABSTRACTION
Niveaux Données Traitements
CONCEPTUEL MCD MCT
Modèle conceptuel des données Modèle conceptuel des
Signification des informations sans traitements
QUOI ? contraintes techniques, organisationnelle Activité du domaine sans préciser
ou économique. Modèle entité – les ressources et leur
association organisation
ORGANISATIONNEL MOD MOT
Modèle organisationnel des données Modèle organisationnel des
QUI, OU, QUAND ? Signification des informations avec traitements
contraintes organisationnelles et Fonctionnement du domaine
économiques. (Répartition et avec les ressources utilisées et
quantification des données ; droit des leur organisation (répartition des
utilisateurs) traitements sur les postes de
travail)
MLD MLT
LOGIQUE Modèle logique des données Modèle logique des traitements
Description des données tenant compte
de leurs conditions d’utilisation Fonctionnement du domaine
COMMENT ? (contraintes d’intégrité, historique, avec les
techniques de ressources et leur organisation
mémorisation). Modèle relationnel informatique.
MPD MPT
PHYSIQUE Modèle physique des données Modèle physique des
Description de la (ou des) base(s) de traitements
COMMENT ? données dans la syntaxe du Système de Architecture technique des
Gestion des données (SG. Fichiers ou SG programmes
Base de Données)
Optimisation des traitements (indexation,
dénormalisation, triggers).
C O L P
SENS DE L'ETUDE
Une validation des modèles entre eux est "à cheval" sur plusieurs niveaux.
La fin de l'étude préalable, date importante dans la vie d'un projet, décide de la
réalisation du reste de l'étude. Ce choix s'effectue à partir de la liste des outils
informatiques. La validation entre données et traitement est effectuée entre
chaque outil retenu du niveau logique et les modèles organisationnels de
données. Cette validation vérifie l'exhaustivité de la liste des outils informatiques
à développer.
Etude Etude Liste des outils Etude Etude

conceptuelle organisationnelle et validation MOD logique Physique
ETUDE PREALABLE
L'étude préalable va jusqu'à la définition des outils

I.5. Processus de développement
Modèles successifs produits
I.6. Les apports de Merise

La force de la méthode Merise est d e structurer les besoins des décideurs
de façon simple et compréhensible . Merise améliore la communication
entre les différents acteurs du processus de développement. Cette

méthode, grâce à ses modèles, encadre le projet et de ce fait p r otè g e
les intervenants d’un possible développement hors sujet . Suivre ce
cheminement intellectuel peut aussi a i d e r l'entreprise à mieux se
connaître , mieux se comprendre et ainsi mieux communiquer.
Le projet Merise s'articule autour d’un schéma directeur qui
détermine et planifie le projet et ses enchaînements.
MODELES CONCEPTUELS
CHAPTITRE II. LE MODELE CONCEPTUEL DE COMMUNICATION (MCC)
II.1. Introduction
Approche systémique. Une entreprise est un système. L'entreprise échange avec
l'extérieur, avec d'autres systèmes. Tout système interne ou externe est appelé
INTERVENANT. Tout système se décompose en sous-systèmes fonctionnels ou
Intervenants. Pour une entreprise de livraison on pourra distinguer les
intervenants : LIVRER, FACTURER, ENCAISSER
II.2. Définitions des concepts

- Diagrammes des flux
Le Modèle conceptuel de communication (MCC), appelé aussi diagramme des
flux, donne une vue d’ensemble (ou cartographie) ou permet une description
des flux d’information (la circulation des informations) échangés entre acteurs
internes ou externes qui participent à un domaine d’étude.
Le Diagramme de flux est une représentation graphique des acteurs et des
flux échangés
La première étape de ce modèle est d'arriver à isoler le système en le

délimitant. Il s'agit donc de définir le système et les éléments externes avec
lesquels il échange des flux d'information. Ces éléments extérieurs sont
appelés acteurs externes (ou partenaires).
La seconde étape consiste à découper l'organisation en entités appelées

acteurs internes (ou domaines). Lorsque les domaines d'une organisation
sont trop importants, ils peuvent être décomposés eux-mêmes en sous-
domaines. La dernière étape est l'analyse des flux d'information, c'est-à-dire
la définition des processus.
- Diagramme de contexte
Le diagramme de contexte a pour but de représenter les flux
d'informations entre l'organisation et les acteurs externes selon une
représentation standard dans laquelle chaque objet porte un nom :
- L’organisation est représentée par un rectangle
- Les acteurs externes sont représentés par des ellipses en pointillés
 Les flux d'information sont représentés par des flèches dont l'orientation
désigne le sens du flux d'information
Exemple de Diagramme de Contexte
- Diagramme Conceptuel de Flux

Ce diagramme (appelé aussi modèle conceptuel de la communication)
permet de compléter le diagramme de contexte en décomposant
l'organisation en une série d'acteurs internes. Dans ce diagramme la
représentation standard est la suivante :
 Les acteurs internes sont représentés par des ellipses,
 Les messages internes sont représentés par des flèches
Exemple de Diagramme Conceptuel de Flux (MCC)
- Un domaine fonctionnel est un découpage de l’organisation. Il correspond

à une finalité majeure de l’organisation.
- Domaine d’étude
Un domaine d’étude délimite le périmètre précis d’une ou de plusieurs
activités au sein d’une organisation spécifique. Un domaine d’étude est un
sous-ensemble de l’organisation dont on étudie séparément le SI.
- Le découpage en domaines fonctionnels est un quasi-invariant de
l’organisation : il correspond aux grandes fonctions ou activités de
l’organisation
- Ce découpage est fixé en entrée d’une étude MERISE et n’est pas de la
responsabilité du concepteur
- Les différents domaines d’étude sont supposés indépendants les uns des
autres
- interactions limitées et un partage minimum des données
Un Domaine est un système ou sous système qui a une mémoire et un SI. Un
domaine est fonctionnel, il joue un rôle. Un domaine peut se décomposer en
sous domaines.
Exemple : une entreprise (qui est un domaine) se compose des domaines
Vendre, Produire, Gérer le personnel ; ses partenaires sont Client, Etat, …
Le domaine Produire peut se décomposer en sous domaines Maintenir (la
production), Approvisionner (les usines), … Les domaines (ou sous domaines)
sont identifiés soit : Comme les fonctions de base répondant à la question
POURQUOI ? Par énumération de toutes les fonctions connues et réunion de
Brain storming avec les groupes d'utilisateurs. La question posée aux
participants étant toujours : Pourquoi ... Une fois les intervenants (ou domaines)
définis (en accord avec les utilisateurs), il faut déterminer les échanges entre
ceux-ci et plus particulièrement les Messages.
On distingue :
 Le message enclencheur; qui attend une réponse ou une réaction du
récepteur
 Le message informant ; qui informe le récepteur sans attendre de réponse
ou de réaction de ce dernier.
Entre sous domaines d'un même domaine, les messages informant sont sans
objet puisque la mémoire du domaine est commune aux sous domaines. Le type
Domaine est représenté par un grand ovale (ou patatoïde) regroupant le cas
échéant des sous domaines (plus petits ovales). Dans chaque ovale on indique
le nom du domaine. Le type Message est représenté par une flèche entre deux
domaines et/ou intervenants avec le nom du message écrit au-dessus de la
flèche.
Découpage du domaine et analyse des flux
Découper l’entreprise en domaines d’activité (pour maîtriser la complexité)

•Chaque domaine doit être « quasi autonome »
•Appréhender l’entreprise comme un ensemble d’unités d’activités échangeant
des flux
- Activité
Une activité est un ensemble homogène de traitements qui transforme ou
manipule des données. Une activité est le concept sur lequel s’appuie la
décomposition.
Exemples : - instruction d’un prêt, déblocage des fonds, remise de chéquier
Règle de décomposition du domaine d’étude en activités :

Le critère d’arrêt de la décomposition en activités est l’ininterruptabilité par un
flux entrant
Distinction entre la cause de l’activité et activité elle-même
Activité : L’activité, c’est le travail effectué à l’intérieur de l’entreprise.
Cause de l’activité : l’événement déclencheur

Les activités sont déclenchées par des événements. Avant l’événement

déclencheur, le système est au repos.
Résultats de l’activité
Les activités produisent des résultats. A la fin de l’activité, le système retrouve
la situation de repos.
- Les flux
Le flux symbolise un échange entre deux acteurs du système d’information
étudié. Il est représenté par une flèche, porte un nom et peut, pour soucis de
lisibilité chronologique, être numéroté.
Le flux décrit un échange entre deux acteurs. Le flux est émis par un acteur à
destination d’un autre acteur.
Les flux décrivent les causes et les résultats de l’activité, et non pas l’activité
elle-même.
On ne s’intéresse pas aux flux entre les acteurs externes : on ne s’intéresse
qu’aux flux qui mettent en jeu au moins un acteur interne.
Ex : documents, appels téléphoniques, données informatiques
Représentation graphique des Flux
- Flux externe
Un flux externe est un flux qui soit est émis par un acteur externe, soit est à
destination d’un acteur externe. Autrement dit, un flux externe est un flux qui
met en jeu au moins un acteur externe.
- Flux interne
Un flux interne est un flux qui est émis par un acteur interne à destination d’un
acteur interne.
Autrement dit, un flux externe est un flux qui ne met en jeu que des acteurs
internes.
- Acteur
L’acteur (interne ou externe au domaine d’étude) est un système actif
intervenant dans le domaine d’étude au moyen des flux. L’acteur représente
une unité active intervenant dans le fonctionnement d’un système opérant. Il
peut être stimulé par des flux d’information, l’acteur peut transformer et émettre
des flux d’information. L’acteur est une unité active : il fait « fait quelque chose
», il est actif. Les acteurs peuvent être :
 des personnes : le client, le comptable, etc.
 des services : le secrétariat, le service comptable, la banque, etc.
 des machines : un lecteur de badge qui fait office de contrôle d’entrée, un
site internet de vente en ligne dans une entreprise de VPC et de vente en
magasin.
On distingue les acteurs internes et externes.

- Acteurs externes
Un acteur externe ou Partenaire est un intervenant extérieur à l’entreprise
échangeant des flux d’information.
Exemples de partenaires Fonctionnels : CLIENT qui paye, FOURNISSEUR qui
approvisionne, …
Un partenaire est Physique s'il est vu fonctionnellement sous plusieurs facettes.
- Acteurs internes
Un Acteur interne fait partie du système d’information étudié
– Ex : guichet, service informatique...
– Si le système est complexe, on peut considérer un acteur interne comme un
sous-domaine et détailler ce sous-domaine dans un nouveau MCC.
Distinction entre le flux et l’activité
L’activité : L’activité concerne un acteur et un seul. Elle ne décrit pas un échange
entre plusieurs acteurs.
Le flux : Le flux décrit un échange entre deux acteurs. Il est émis par un acteur
à destination d’un autre acteur.

II.3. Remarques et règles d’usages

a. Un flux ne doit pas être bidirectionnel
Il ne doit pas exister entre deux acteurs (internes, externes ou identiques) de

liens bidirectionnels. Il convient de noter deux flux distincts.
b. Le flux ne doit pas être réflexif

Un flux ne doit pas partir et revenir sur le même acteur (interne ou externe). Si
cela est nécessaire, nous devons segmenter l’acteur.
c. Pas de flux entre des acteurs externes
Les flux entre les acteurs externes ne sont d’aucun intérêt dans l’étude du
système.
II.4. Les étapes à suivre pour concevoir le MCC

Première étape d’une étude de l’existant, pour modéliser les habitudes de
travail dans l’organisation concernée :
– Délimiter le domaine étudié
– Réduire la complexité en identifiant des sous problèmes traités
individuellement
– Identifier les acteurs externes et internes
– Modéliser les échanges d’informations entre les différents acteurs
Exemple : Gestion de ventes de Fournitures de bureau
Fonctionnement (Description textuelle)
La rupture de stock de fourniture occasionne l’approvisionnement. Le gérant

demande la liste des fournitures à approvisionner au service vente qui joue le
rôle de magasinier. Ensuite le gérant fait le rapport de la situation de stock au
Directeur qui lui donne l’instruction d’approvisionner les fournitures en stock et
le gérant lance une demande auprès de leur fournisseur (bon de commande) et
le fournisseur lui livre les fournitures en respectant l’engagement (payement,
frais de transport…).
A l’arrivée du client pour la première fois à la papeterie, il s’adresse au service

vente (magasinier) en passant sa commande, si la demande est possible après
vérification du stock, la facture est éditée, remise au client et ce dernier paie
directement à la caisse. Après paiement, le service vente (magasinier) prépare
les fournitures et les met à la disposition du client.
Après livraison des fournitures, la réclamation se fait sur place pour obtenir le
remplacement des fournitures le cas échéant. Toute réclamation après le départ
du client n’est plus possible. A la fin de la journée, le service vente prépare le
rapport de la situation du stock et le service de caisse sa situation financière qu’il
soumet au Comptable et celui transmet le rapport au Gérant. Le Directeur recoit
le rapport mensuel auprès du Gérant.
Travail à faire:
- Etablir le tableau des acteurs et leurs flux
- Concevoir le Diagramme de Flux (MCC) en respectant les contraintes de
l’énoncé.
1. Recensement des acteurs
N° ACTEUR TYPE INTERPRETATION
C’est la personne qui vient pour acheter les

produits directement ou discuter le prix ou
01 CLIENT EXTERNE encore prendre du crédit.
C’est un acteur qui gère, assure la direction ou

02 GERANT INTERNE administration de cette papeterie.
C’est la personne qui garde l’argent pendant
03 CAISSIER INTERNE la journée et dresse la facture.
Acteur chargé de la vente et livraison de
04 VENDEUR INTERNE tous les fournitures de la papeterie.
Est celui qui fait la vérification des factures
05 COMPTABLE INTERNE et de l’argent.
Acteur chargé de fournir habituellement les

articles commandé à ses clients partenaires.
06 FOURNISSEUR EXTERNE
ce le représentant légal de la papeterie.
07 DIRECTEUR INTERNE
Gestion de vente des fournitures scolaires et des

bureaux 5
3
Direction Gérance 6 Fournisseur 8
4
9
19 1 2
Service 18 10
comptabilité 19 Service
1 2 11
et finance Vente
17 7
15
12
Service
17
Encaissement 16
13 Client
/caisse
14
Légende
1. Le gérant demande la liste des fournitures non approvisionnées auprès

de Service Vente.
2. Service Vente fournie la liste des fournitures non approvisionnées auprès
du gérant.
3. Le gérant envoi le rapport au directeur
4. Le directeur donne l’instruction au gérant d’approvisionner les fournitures
5. Le gérant envoi le bon de commande des fournitures non
approvisionnées auprès des leurs fournisseurs
6. Réception de bon de commande par les fournisseurs et demande les
payements et frais des transports auprès du gérant.
7. Le gérant donne l’instruction au service caisse de payer tous les frais
demandés auprès du fournisseur pour la livraison des fournitures
8. Le service caisse paye tous les frais auprès du fournisseur
9. Le fournisseur livre les fournitures auprès du gérant
10. Service vente reçoit des fournitures approvisionnées auprès du gérant
11. Client présent demande les fournitures auprès de service vente
12. Le service vente informe au client la disponibilité des fournitures
13. Client paye directement à la caisse

14. Service caisse remet la facture au client
15. Le client devant le service vente présente la facture
16. Service vente livres les fournitures au client
17. Le service caisse transmet les bordereaux de versement reçu et livré
auprès du comptable
18. Le service comptabilité passe l’écriture comptable auprès de gérant
19. Le gérant envoi le rapport de situation de la caisse auprès de Directeur.
CHAPITRE III. LE MODELE CONCEPTUEL DES TRAITEMENTS (MCT)
III.1. OBJECTIFS DU MODELE CONCEPTUEL DES TRAITEMENTS
INTRODUCTION
Le Modèle Conceptuel des Traitements met en lumière les traitements

effectués sur les données. Indépendamment de toute contrainte liée à
l’organisation, le Modèle Conceptuel des Traitements répond à la question
« Quoi ? ». Le Modèle Conceptuel des Traitements ne répond ni au comment,
ni au quand, ni au qui, mais à Que souhaite ton obtenir ?
 Le MCT représente formellement les activités exercées par le domaine (`à la
base de la connaissance du SI)
 Le MCT repose sur la prise en compte des échanges (flux) du domaine avec
son environnement
 Le MCT s’effectue en faisant abstraction de l’organisation et des choix
technologiques
 La définition des interactions du domaine avec son environnement prime sur
la manière dont on assurera ces activités
Le MCT vise à définir le quoi, quels sont les traitements dans l’organisation. Le
MCT ne définit pas qui, ni ou, ni comment sont effectués les traitements (rôle du
MOT). Le MCT prend en compte des événements, décrit les opérations qu’ils
déclenchent et les résultats obtenus. Il décrit aussi quels ordres s’enchaînent les
traitements.
Différence entre MCC et MCT

– Le MCT est un « zoom » sur le MCC
– Dans les MCC, on représente les messages échangés entre acteurs
– Dans les MCT, on représente comment un acteur de l’organisation réagit
quand il reçoit ce message et quelle opération il effectue.
III.2. ETUDES DES CONCEPTS

LES EVENEMENTS
Le MCT est aussi appelé Modèle événement résultat. L’arrivée d’un ou

plusieurs évène me nt s v a générer une opération qui va elle-même fournir
un résultat. Selon leur origine on distingue les évènements externes (exemple
: la commande d’un client) et les évènements internes générés par le
système d’information (exemple : l’émission d’une facture). Un événement est
le fait que quelque chose survient et que l’on perçoit que quelque chose
survient. Un certain temps peut s’écouler entre la perception du fait et la prise
en compte de cette perception par le SI. Un évènement est représenté de la
façon suivante :
TYPES D’EVENEMENTS
Nous distinguons :
- Les événements contributifs externes issus de l’UE et devant provoquer une

réaction du SI. Ils peuvent être porteurs des mouvements.
- Les événements contributifs internes issus du SI lui-même et pouvant :
Soit provoquer une nouvelle réaction du SI. Dans cette éventualité, ils
peuvent également être porteurs des mouvements à faire prendre en charge par
le SI ;
Soit constituer des résultats à l’intention de l’UE (événements résultats). Dans
ce cas, ils sont porteurs des messages du SI à l’UE ou des résultats.
- Evénement déclencheur : Fait réel dont l’apparition déclenche l’exécution
d’une opération.
- Evénement Résultat : Un produit de l’exécution d’une opération. L’événement

résultat est généré par une opération conceptuelle et destiné à l’univers
extérieur (résultats externes) ou à d’autres opérations (résultats internes).
PROCESSUS (TRAITEMENT)
C’est un ensemble organisé d’activités, déclenché par un événement ou orienté

vers la production d’un résultat clairement identifié. Ensemble organisé
d’activités, d’événements et des résultats qui concourent à un même but.
En bref, le Processus ou traitement est un ensemble organisé d’activités (ou

actions) déclenché par un événement extérieur qui concourent à un même but
clairement identifié.
LE RESULTAT
Un résultat peut-être un document, un message externe, un nouvel état du SI
(nouvelle situation, nouvelles données), créé par une opération, qui peut lui-
même jouer le rôle d’événement. Un résultat externe représente une information
envoyée à l’extérieur du SI (ex : facture). Un résultat interne est un nouvel état
du système d’information (ex : ordre de préparation)
LES OPERATIONS
Une opération est une suite d’actions interruptibles. Pour trouver les
opérations, on se sert du diagramme de flux conceptuel de niveau le plus bas
et on décompose les activités en un ensemble d’opérations élémentaires.
LA SYNCHRONISATION D’UNE OPERATION

C’est une condition booléenne (ET / OU) traduisant les règles de gestion que
doivent respecter les événements pour déclencher une opération. Dans le cas
ET, elle marque qu'un événement déjà là doit en attendre un ou plusieurs autres.
La synchronisation d’une opération : marque le rendez-vous des événements
contributifs qui doivent arrivés avant le déclanchement de l’opération selon une
proposition logique traduisant les règles de gestion d’activité.
Remarque : Pour qu'il soit question de synchronisation, il faut la présence de
plusieurs événements déclencheurs ; aussi, le symbole de synchronisation est
laissé à blanc dans le cas d'un événement unique. Si tous les événements
entrants sont liés par le même opérateur, on peut seulement faire figurer
l'opérateur dans le symbole de synchronisation sinon il faut numéroter les
événements (a, b ,c …) et constituer l'expression à l'aide des événements et des

opérateurs. (ex : (a ET b) OU c).
REGLE D'EMISSION
Condition, traduisant les règles de gestion, qui permet d'exprimer des
conditions de sortie des résultats.
Remarques : L'expression d'une règle d'émission peut être composée de
plusieurs conditions élémentaires reliées par les opérateurs ET, OU. On peut
également utiliser l'opérateur NON pour exprimer la négation d'une condition.
ROLE DES REGLES DE GESTION

Recensées lors de l'étude de l'existant ou définies pour le futur SI, elles décrivent
les enchaînements d'opérations. Elles rendent possible le regroupement des
actions au sein d'une seule opération non interruptible au niveau conceptuel.
Représentation schématique d’un Modèle Conceptuel des Traitements
Evénement 2 Evénement n
Evènements Evénement 1 Evénement 3

déclencheur
s
Synchronisation
Opération Libellée de l’opération

Déscruption de l’Opération
Règle d’émission Régle
Opération Règle d’émission
1
Règle
d’émission 2 n d’émission 3
Résultat 1 Résultat 2
Résultat Résultat n Résultat 3
LES ETAPES DE LA CONSTRUCTION DU MCT
Etape 1 : A partir du graphe ordonnancé des flux, on construit la liste de tous

les événements en entrée et en sortie du SI.
Etape 2 : Passage au MCT

- Tout événement en entrée se trouve 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.
METHODE DE CONSTRUCTION DU MCT

1. Enchaînement des différentes opérations
2. Utiliser la représentation normalisée
3. Ajouter les conditions d’émission
4. Mettre en place les événements
5. Ajouter les fonctions de synchronisation
Conception d’un Modèle Conceptuel des Traitements pas à pas
Exemple 1 : Une administration qui gère des demandes de promotions selon

les règles de gestion suivantes :
RG1 : Toute demande de promotion doit subir un examen préalable (vérification
de l’ancienneté, vérification des états de service et autres critères) permettant
de déterminer si elle est recevable ou non.
RG2 : L’examen du dossier d’une demande recevable ne peut se faire qu’après
rapport du supérieur hiérarchique.
RG3 : Après examen du dossier par l’autorité compétente, la promotion sera
accordée ou refusée (lecture rapport du supérieur hiérarchique, discussions,
vote).
Solution :
Demande de promotion
No1 Examen préalable

- Vérification ancienneté
- Vérification états de service
Non
Recevable Recevable
Rapport supérieur
Rejet du dossier Ouverture dossier
ET
No2 Examen Dossier

- Lecture rapport
- Discussions
Avis Avis
Défavorable Favorable
Promotion refusée Promotion accordée
ETUDE DE CAS : GESTION DE VENTES DES FOURNITURES SCOLAIRES ET

DE BUREAUX
Construction du MCT par processus
a. Processus d’approvisionnement
D.C.R A C.D.A.F
Présen t Dispo
et
N°5 Décaissement de montant à payer
- Vérification de caisse
- Annexer la factu re
- Passas sions des écriture de décaissement
OK Non OK
Décaissement Décaissement
effectué Annulé
C.D.A.F Fournisseur
Présen t Dispo
et
N°6 Paiement facture
- Transfère d’argent
- Remise de bordereau de trans fère
Tou jours
C.P.A Paiement effectué Fournisseur

Présen t Présen t
et
N°7 Réception des intrants agricoles livrés
- Contrôle à la réception
Toujours
C.P.A Réception C.G.S.M

Présen t effectuée Dispo
et
N°8 Contrôle des intrants réceptionnés
- Vérification des produits
Bon éta t M auvais état
Produit accepté Produit retourné
C.P.A C.G.S.M
Présen t Dispo
et
N°9 Mise en jour de stock
- Enregistrement d es intra nts reçu s
Tou jours
MAJ effectuee
b. Processus de commande client

c. Processus de facturation
CHAPITRE IV. MODELISATION DES DONNEES
IV.1. La représentation de Modèle Conceptuel de Données (MCD).

Un modèle : est-ce qui sert ou doit servir d’objet d’imitation pour faire ou
reproduire quelque chose.
Le Modèle Conceptuel des Données (MCD) introduit la notion d’Entités, de

Relation-Association, Cardinalités, Identifiant et de Propriétés ou Attributs. Nous
allons commencer par voir certains aspects « théoriques » avant de plonger
dans la pratique.
Le Modèle Conceptuel des Données a pour but d'écrire de façon formelle

les données utilisées par le système d'information. Il s'agit donc d'une
représentation des données, facilement compréhensible, permettant de décrire
le système d'information à l'aide d'entités. La représentation graphique,
simple et accessible, permet à un non informaticien de participer à son
élaboration.
En se basant sur un document d'analyse, le modèle conceptuel des données

(MCD) fait référence à tous les objets du système d'information et à des
relations entre ces objets. Le formalisme utilisé dans ce modèle est encore
connu sous le nom de "Schéma Entité-Relation". Ce formalisme se base
autour de 3 concepts principaux, les entités, les relations et les propriétés.
L’objectif de MCD est de proposer une représentation schématique de la

partie statique de l’entreprise (données et liens) en utilisant le formalisme
d’entité/association qui soit abordable par tout utilisateur permettant un
dialogue clair avec les concepteurs. Le MCD obtenu ne doit inclure que des
données nécessaires au fonctionnement de l’entreprise et les liens existants
entre ces données.
Le Modèle Conceptuel de Donnée : est l’ensemble des modèles qui intègrent

les contraintes conceptuelles définies par Merise. Le MCD est donc une
abstraction (un modèle abstrait).
Un modèle conceptuel de données (MCD) : est la formalisation de la
structure et de la signification des informations décrivant des objets et des
associations perçus d’intérêt dans le domaine étudié, en faisant abstraction
des solutions et contraintes techniques informatiques d’implantation en
base de données. Le but du MCD est de modéliser (formaliser) les données
mémorisées du S.I On ne tient pas compte des aspects techniques,

économiques, ni de problèmes de stockage de l'information, ni des problèmes
d'accès aux informations et ni des conditions d'utilisation. On a deux démarches
pour explorer le S.I :
- La démarche déductive (ascendante). Cette démarche s'appuie sur une

liste d'informations.
- La démarche inductive (descendante). Elle met en évidence les entités de
gestion en les décrivant
 La démarche déductive
Elle nécessite un recensement exhaustif de toutes les informations brassées par
le S.I (on appelle ça la déstructuration). Cette phase fournit un dictionnaire des
toutes les informations (dictionnaire des données). C'est le point de départ d'une
recomposition du S.I, d'une structuration de ses informations en objets et
relations.
 La démarche
- Constitution d'une liste de données (recueil des données à travers des
entretiens et des documents)
- L'information est-elle vraiment nouvelle ?
- Est-ce que l'information a déjà été répertoriée sous un nom différent ou sous
un même nom mais avec un sens différent ?
- Constitution d'un dictionnaire des données où chaque donnée figurera avec
sa description (mot clef, longueur, texte libre, règle de calcul, ...)
- Constitution des objets et des relations entre les objets en agrégeant les
propriétés pour décrire des entités de gestion (gérer en entreprise)
Le Modèle Conceptuel des Données introduit la notion d’entités, de relations et

des propriétés. Nous allons commencer par voir certains aspects « théoriques »
avant de plonger dans la pratique. Il décrit de façon formelle les données
utilisées par le système d'information. La représentation graphique, simple et
accessible, permet à un non-informaticien de participer à son élaboration.
III.2. Etude des concepts de base

Les éléments de base constituant un modèle conceptuel des données
sont :
 Les entités;
 Les relations ;
 Les propriétés ;
 Les cardinalités ;
 L’Identifiant.
III.2.1. Une Entité

Une Entité est la représentation d'un élément matériel ou immatériel ayant un
rôle dans le système que l'on désire décrire. Une entité est une population
d’individus homogènes. Par exemple, les produits ou les articles vendus par
entreprise peuvent être regroupés dans une même entité articles (figure 1), car
d’un article à l’autre, les informatiques ne changent pas de nature (à chaque fois,
il s’agit de la désignation, du prix unitaire, etc.).
Par contre, les articles et les clients ne peuvent pas être regroupés : les
informations ne sont pas homogènes (un article ne possède pas d’adresse et un
client ne possède pas de prix unitaire). Il faut donc leur réserver deux entités
distinctes : l’entité articles et l’entité clients.
Classification des Entités
Entités permanentes : Les entités permanentes sont des entités que l’on
conserve en permanence dans la base d’informations mais qu’on peut mettre à
jour à tout moment. Elles correspondent à la structure mais ne représentent
pas des faits.
Exemple : client est une entité permanente car, on conserve les propriétés d’un
client en permanence tout en ayant la possibilité de le modifier à tout moment.
Les propriétés d’une activité permanente peuvent changer mais l’entité est
stable.
Entités de type Mouvement : Il s’agit des mouvements mémorisés. Ces entités
sont des images des événements qui ont porté sur ces mouvements. Elles sont
liées à la conjoncture (elles représentent des faits conjoncturels). Une entité de
type mouvement est le souvenir d’un événement, dans le SI.
Exemple : l’entité commande (N° de commande, date) mémorisée dans le

système est issue de l’événement passation de commandes.
Il existe un moment où on ne peut plus mettre à jour une entité mouvement (on
ne peut plus modifier une commande une fois qu’elle est passée)
III.2.2. Relation ou Association.

Une relation (appelée aussi parfois association) : représente les liens
sémantiques qui peuvent exister entre plusieurs entités.
Une association est une liaison qui a une signification précise entre plusieurs
entités. Dans notre exemples, l’association commander est une liaison
évidente entre les entités articles et clients, tandis que l’association livrer établit
le lien sémantique entre les entités articles et fournisseurs.
Remarquons que dans ce schéma, les entités clients et fournisseurs ne sont pas
liées directement, mais indirectement, via l’entité articles, ce qui est naturel.
Classement des relations
Relations permanentes : Ce sont des relations entre les entités permanentes

qu’on conserve en permanence et dont on peut modifier des propriétés à tout
moment. Ce sont des relations structurelles.
Relation de type Mouvements : Ce sont des relations entre entités

permanentes ou de mouvements qui représentent le souvenir d’un événement
(relation conjoncturelle).
Classification des mouvements
Qu’ils soient mémorisés (sous forme d’entité conjoncturelle) ou non, les
mouvements (propriétés portées par les événements) peuvent se classer en :
- Mouvements de maintenance des propriétés signalétiques ou des entités ou
relations permanentes.
- Mouvements d’opérations courantes
Les mouvements de maintenance des propriétés signalétiques correspondent

à la MAJ (ajout, modification ou annulation) des propriétés signalétiques des
entités ou relations permanentes. Ils correspondent à l’entretient de ces
dernières (l’intendance).
Exemple : à propos de l’entité permanente Client (code, nom, adresse, CA), tous
les mouvements visant à changer le nom ou l’adresse (propriétés signalétiques)
du client constituent de tels mouvements de maintenance. Il en va de même de
l’ajout ou de l’annulation du client.
Les mouvements d’opérations courantes correspondent aux événements
quotidiens qui sont traités par le système et qui visent à mettre à jour la situation
des entités ou relations permanentes.
Exemple : les commandes des clients sont des événements courants traités par
le SI commercial et visent à mettre à jour les CA des clients (situations des entités
permanentes) de type CLIENTS et le CA des produits.
Les écritures servent à mettre à jour la situation des comptes ; des entrées-
sorties en magasin servent à mettre à jour le niveau de stock du produit. On
peut classer les mouvements des opérations courantes par rapport une période
de traitement de référence en :
- Mouvements nouveaux : mouvements qui n’ont pas encore participé au
traitement de la période (dans le cas des traitements quotidiens des
commandes, les commandes de la journée qu’on vient d’enregistrer en vue

de livrer le client) ;
- Mouvements en cours : mouvements nouveaux des périodes précédentes
dont le traitement n’est pas encore terminé (ex : commandes des jours
précédents qui n’ont pu être honorées faute de stocks insuffisants)
- Mouvements historiques : mouvements des périodes précédentes dont le
traitement est terminé (ex : commandes des jours passés ayant donné lieu à
la livraison).
Par rapport à la période de référence d’un autre traitement, les mouvements

historiques peuvent redevenir des mouvements nouveaux. Ex : à la fin du mois,
l’historique des commandes livrées servira des mouvements nouveaux pour
l’établissement des statistiques mensuelles des ventes. Les mouvements
nouveaux ne sont pas obligatoirement mémorisés. Les mouvements historiques
ou en cours le sont nécessairement. Les mouvements d’opérations courantes
permettent soit de MAJ directement les situations en permettant les calculs de
nouvelles valeurs des propriétés de situation ; soit des MAJ indirectement par la
MAJ des mouvements mémorisés qui permettront (à l’ordinateur) de calculer à
tout moment la nouvelle situation à partir de l’ancienne et à partir de ce
mouvement.
III.2.3. Attributs ou Propriétés.

Un attribut est une propriété d’une entité ou d’une association. Les propriétés
sont les informations de base du système d’information. Un client possède
un numéro de client, un nom, un prénom, habite à une adresse précise, etc. Ces
informations élémentaires essentielles sont des propriétés.
Les propriétés disposent d’un type. Elles peuvent être numériques, représenter
une date, leur longueur peut être aussi définie. Par exemple : le nom est une
propriété de type alphabétique et de longueur 50, c’est-à-dire que la valeur
saisie ne comportera aucun chiffre et ne dépassera pas cinquante caractères.
Une propriété peut être élémentaire, ou concaténée, elle peut être mémorisée
ou calculée. Les types ne sont pas décrits au niveau conceptuel, ca r ce
niveau est trop proche de la définition du système physique.
Toujours dans notre exemple (figure 3), le prix unitaire est attribut de l’entité
articles, le nom de famille est un attribut de l’entité clients, la quantité
commandée est un attribut de l’association commandé et la date de livraison
est un attribut de l’association livrer.
Une entité et ses attributs ne doivent traiter que d’un seul sujet afin d’assurer
une certaine cohérence au modèle. Dans notre exemple, il est donc de ne pas
mettre les informations relatives aux fournisseurs dans l’entité des articles mais
plutôt dans une entité fournisseurs séparées (et liée à l’entité articles via
l’association livrer).
Les propriétés d’une activité permanente peuvent être de deux types :

 Les propriétés signalétiques
 Les propriétés de situation
Les propriétés signalétiques correspondent à la « fiche d’Etat civil » de l’entité

à sa description.
Exemples : Nom, rue, ville,…sont des propriétés signalétiques de l’entité
Client.
Désignation, prix,…. sont des propriétés signalétiques de l’entité Produit.
Intitulé est une propriété signalétique de Compte.
Les propriétés de situation expriment dans quelle situation se trouve l’entité
permanente à un instant donné, situation qui représente en générale un cumul
ou une position.
On pourra distinguer la situation actuelle d’une entité, représentée par des

propriétés de situation à l’instant présent, et les situations en historique,
représentées par des propriétés des situations de l’entité à des instants passés.
Exemple : pour l’entité Produit, la propriété CAM (Chiffre d’affaires au mois

actuel M) représente la situation actuelle si on fait la mise à jour du CA tous les
mois. Les propriétés CAM-1, CAM-2,…, représentent l’historique des situations
du produit. La situation à une date T peut être mémorisée ou calculée à partir
d’une situation antérieure et des mouvements concernant cette entité depuis
cette situation antérieure.
Exemple : le solde d’un compte au 04 mars peut se calculer à partir du dernier

solde mémorisé (par exemple au 28 février ; date de dernière MAJ des comptes)
et des écritures (mouvements) enregistrées depuis cette dernière MAJ (depuis
le 28 février).
On a donc deux méthodes pour déterminer la situation d’une entité à l’instant
T : Calculer une fois pour toutes cette situation et la mémoriser. Rechercher à
chaque fois cette situation à partir de la dernière situation mémorisée et des
mouvements enregistrés depuis. Cette méthode n’est envisageable qu’avec un
ordinateur ayant assez de mémoire externe pour conserver tous les
mouvements au calcul.
Nous venons de voir que le concept propriété correspond à la notion de

rubrique, attribut d’une entité ou d’une relation. Il peut aussi correspondre à la
notion de données (rubriques) portées par un événement.
Exemple : l’événement « entrées en stock » est porteur des propriétés :
référence des produits entrés en stock, quantité entrés en stock,…
Une propriété peut être concaténée si elle est décomposable en d’autres
propriétés.
Exemple : Adresse peut-être une rubrique concaténée décomposable en rue,
code postal et ville.
ADRESSE=RUE+CODE POSTAL+VILLE (concaténation)

Une propriété est dite élémentaire si elle ne peut pas se décomposer.
Exemple : rue, code postal.
Une propriété peut être élémentaire ou concaténée.
Une propriété peut être mémorisée dans la base d’information du SI, c’est-à-
dire, stockée sur un support destiné à la conserver. Exemple : le nom du client
peut être mémorisé sur une fiche en carton.
Certaines propriétés peuvent ne pas être mémorisées mais se déduire de
propriété mémorisée pour l’obtention d’un résultat.
Exemple : le solde d’un compte peut se calculer à partir de données
mémorisées : cumul débit et cumul crédit par la différence entre ces deux
données. Exemple : PT = Qté * PU
Enfin, une propriété peut être portée par un événement sans être mémorisée
par le système.
Exemple : l’événement "demande de consultation de stock" porte la référence
du produit à consulter. Cette propriété peut ne pas être mémorisée si l’on ne
désire pas conserver le souvenir de consultations effectuées.
Bien entendu rien n’empêche de mémoriser les propriétés liées à des
événements si l’on souhaite conserver la trace de ces événements (on peut très
bien vouloir noter toutes les demandes de consultation du stock).
Une propriété peut être mémorisée ou calculée (déductible de propriétés
mémorisées).
Elle peut aussi être portée par un événement sans être nécessairement
mémorisée.
On distingue trois sortes de propriétés : LES CODES, LES LIBELLES, LES

MONTANTS
Les CODES sont des informations synthétiques représentatives d’objets

matériels, immatériels de l’UE, selon une loi de correspondance rigoureuse(le
système de codification) qui à tout objet existant associe une valeur et une seule
du code et telle qu’à deux objets différents correspondent deux valeurs
distinctes de ce code.
Exemple : tel client se verra attribué le code A01 et aucun autre code. Aucun
autre client ne pourra avoir le CODE A01.
Un code pourra servir d’identifiant d’une entité, c’est-à-dire la propriété
caractéristique de cette entité (ou clé d’identification si l’entité en question
représente l’objet correspondant au code.
Exemple: le numéro de BC est un code qui représente l’objet commande de

l’UE. Il pourra servir d’identifiant (de clé) à l’entité Bon de commande.
Les LIBELLES sont des données alpha-numériques, quantitatives, des simples
chaînes de caractères qui pourront simplement être restituées par le système ou
sur lesquelles on pourra faire des tris ou comparaisons mais qui ne pourront
participer à aucun calcul. Ex : Nom du client
Exemple : Nom du client
Les MONTANTS sont des données numériques, quantitatives, qui pourront

participer à des calculs Ex : prix, poids, taille, date,…
III.2.4. Identifiant
Identifiant : modélisation des propriétés contribuant à la détermination unique
d’une occurrence d’une entité. Propriété qui permet de distinguer de l’entité –
type les occurrences d’une manière unique.
L’identifiant permet de connaître de façon sûre et unique l’ensemble des
propriétés qui participent à l’entité. Par exemple, l e fait de connaître l a
ville d’u n c l i e n t p e r m e t -il d e connaître s o n nom ? La réponse e s t
non. La connaissance d u nom du client permet-elle d e connaître s a ville
? La réponse e s t toujours n o n , car en cas d’homonymie la confusion entre
un Durand Max et un Durand Raymond est totale.
Il faut donc trouver, ou inventer, une propriété qui lorsque sa valeur est
connue permet la connaissance de l’ensemble des valeurs qui s’y rattachent
de façon formelle. Chaque individu d’une entité doit être indentifiable de la
manière unique. C’est pourquoi toutes les entités doivent posséder un attribut
sans doublon (c’est- à - dire ne prenant pas deux fois la même valeur). Il s’agit
de l’identifiant que l’on souligne sur le schéma, par convention. Le numéro de
client consiste un identifiant classique pour l’entité clients (figure 4). Ainsi,
lorsque le numéro du client est connu, son nom, son prénom et toutes les
valeurs des autres propriétés qui s’y rattachent sont connues de façon sûre
et unique.
Remarque :
- Une entité possède au moins un attribut (son identifiant)
- Au contraire, une association peut être dépourvue d’attribut.
III.2.5. Cardinalités
Une cardinalité : modélisation des participations minimales et maximales
d’une entité à une relation ; c’est le nombre de fois qu’une entité participe à une
relation. La cardinalité d’un lien entre une entité et une association précise le
minimum et le maximum de fois qu’un individu de l’entité peut être concerné
par l’association.
Exemple : un client a au moins commande un article et peut commander n

articles (n étant indéterminé), tandis qu’un article peut avoir été commandé
entre 0 et n fois (même si ce n’est pas le même n que précédemment). On
obtient alors le schéma entités –associations complet (figure 5)
La seule difficulté pour établir correctement les cardinalité c’est poser les
questions dans le bon sens. Autour de l’association commander, par exemple :
- Cote clients, la question est « un client peut commander combien

d’article ? » et la réponse est « entre 1 et plusieurs » ;
- Cote article, la question est « un article peut être commandé par
combien de clients ? » et cette fois-ci la réponse est « entre 0 et
plusieurs ».
Types de Cardinalités
La notion de cardinalité minimum/ maximum permet d’exprimer la
fonctionnalité et la totalité/ partialité d’une relation. C’est grâce à la cardinalité
que l’on exprime le MCD.
Cardinalité minimum : La cardinalité minimum d’une relation est le nombre

minimum des fois où chaque occurrence d’une entité–type participe à la relation.
La cardinalité minimum 0 correspond à une relation PARTIELLE.
La cardinalité minimum 1 signifie qu’une occurrence d’entité–type ne peut
exister sans participer à une occurrence de la relation.
La cardinalité minimum n implique que toute occurrence d’entité–type participe

obligatoirement à n occurrences de la relation. Les cardinalités minimums non
nulles correspondent à des relations TOTALES.
Cardinalité maximum :
La cardinalité maximum d’une relation est le nombre maximum des fois où
chaque occurrence d’entité –type peut participer à une occurrence de la relation.
La cardinalité maximum 1 signifie que toute occurrence de l’entité –type ne peut
participer qu’à une occurrence de relation au plus.
La cardinalité maximum n signifie qu’une occurrence de l’entité –type peut être

impliquée dans un maximum de n occurrences de la relation.
III.2.5. Les relations porteuses
Définition : Une relation est dite porteuse lorsqu’elle contient des propriétés.
Imaginons que l’on veuille connaître la quantité d’articles commandés par
clients, nous nous rendons compte qu’il faut utiliser une nouvelle propriété
Quantité. Cette nouvelle propriété dépend de clients, d’articles ou des deux ?
La bonne réponse est que Quantité dépend des deux entités. Voici le
modèle conceptuel correspondant :
Nous pouvons interpréter ce schéma de la façon suivante : Le client X a

commandé la quantité Y d’articles Z. Si nous désirons connaître la date
d’achat, il nous suffit de créer une entité Date à la relation Commander. Une
relation faisant intervenir deux entités est dite binaire, trois entités, Tertiaires.
Règles d’usages
●Toute entité doit comporter un identifiant.
●Toutes les propriétés de l’entité dépendent fonctionnellement de l’identifiant.
C’estàdire que connaissant la valeur de l’identifiant, nous connaissons de
façon sûre et unique la valeur des propriétés associées. Si nous recherchons
le client numéro 5, nous devons récupérer le nom et le prénom du client
numéro 5 et pas ceux d’une autre personne.
● Le nom d’une propriété ne doit apparaître qu’une seule fois dans le modèle
conceptuel des données. Si nous établissons une entité Clients et une
nommée Prospects, nous ne devons pas retrouver la propriété Nom dans les
deux entités. Il faut préférer la dénomination suivante Nom_client et
Nom_prospect.
● Les propriétés résultantes d’un calcul ne doivent pas apparaître dans le
modèle conceptuel des données.
III.2.6. Type et Occurrence

Un type est un ensemble d’éléments ayant les mêmes caractéristiques. Ex : les
Étudiants de l’ISC-KIS faisant l’informatique à partir de la deuxième année. Une
occurrence d’un type est un élément particulier d’un type appartenant à cet
ensemble.
Exemple : un Etudient est l’occurrence de l’ensemble des Etudiants de l’ISC-KIS
faisant l’informatique.
Entité –type : un type d’entité ou entité type est une classe d’entités
particulières ayant des propriétés analogues.
Occurrence d’entité -type : une occurrence d’entité type est une entité
particulière appartenant à ce type.
Exemple : - client est une entité type
- client DURAND et client DUPOND sont des occurrences de cette

entité –type
Une propriété particulière d’une entité l’identifiant (ou clé d’identification)
permet de distinguer cette entité particulière de toute autre entité du même
type. L’identification est une propriété qui caractérise chaque occurrence de
l’entité –type
III.2.7. REGLES DE GESTION

Les règles de gestion du MCD précisent les contraintes qui doivent être
respectées par le modèle.
Exemple : Modélisons le fait qu’une mère élève des enfants. Nous avons deux
entités Mères et Enfants :
Une relation ou association E l ev e r :
Règles de Gestion (RG)

RG1 : Une mère peut élever un ou plusieurs enfants.
RG2 : Un enfant peut être élevé par une et une seule mère.
Bien sûr, tout est question d’interprétation. Au sein d’une équipe de

développement, il peut y avoir des divergences de point de vue. Pour les
cardinalités, il faut être le plus logique possible, se référer aux règles de gestion
édictées par le commanditaire de l’application et se rappeler la maxime suivante
: "Qui peut le plus peut le moins".
III.2.7. Notion de Contrainte d’Intégrité Fonctionnelle (CIF)

Définition
Une contrainte d ’ i n t é g r i t é f o n c t i o n n e l l e ( ou CIF) est définie par le
fait qu’une d es entités d e l’association e s t complètement déterminée
par la connaissance d’une ou de plusieurs entités participant à cette même
association.
Par exemple :
Nous pouvons lire qu’une salle peut contenir zéro ou plusieurs ordinateurs
et qu’un ordinateur existe dans une et une seule salle. Dans le cas d’une
association binaire comme celle-ci, une contrainte d’intégrité fonctionnelle
existe à partir du moment où une cardinalité de type 1,1 existe. Certains
auteurs proposent une écriture de ce type :
Notre conseil est de nommer votre relation de façon claire et compréhensible

pour donner tout son sens à la lecture de votre modèle conceptuel.
III.3. DICTIONNAIRE DES DONNEES
Définition : Le dictionnaire des données est un document qui permet de

recenser, de classer et de trier toutes les informations (les données)
collectées lors des entretiens ou de l’étude des documents. Le dictionnaire
peut être plus ou moins élaboré selon le niveau de granularité souhaité.
En voici un exemple :
Nom de la Format Longueur Type Règle de Règle de Document

donnée calcul gestion
Élémentaire Calculé
Nom de la donnée : Cette cellule recevra une donnée par exemple : Nom
client.
Format : Ici sera indiqué le format de la donnée, par exemple : alphabétique.
Longueur : La longueur approximative ou exacte de la donnée sera
indiquée, par exemple : 30.
Type : Une croix sera inscrite dans la colonne pour indiquer si la donnée est
élémentaire ou calculée.
Règle de calcul : Ici sera indiquée de manière claire la formule ou le calcul
nécessaire à appliquer pour obtenir la donnée.
Règle de gestion : Dans cette zone sera indiquée, si nécessaire, la règle de
gestion inhérente à la donnée.
Document : La rubrique document permet de saisir le document dans lequel
a été trouvée la donnée.
Voici ce que pourrait être le dictionnaire :
Nom de Format Longue Type Règle Règle Document

la ur de de
donnée calcul gestion
E C
Nom client Alphabétique 30 X Facture
Le nom est au format alphabétique, d’une longueur de 30 caractères, de

type élémentaire, il n’y a aucune règle de gestion et le document dans
lequel l’information a été trouvée est la facture.
La longueur du champ nom a été définie aléatoirement à 30 caractères.
Il faut toujours avoir à l’esprit que dans le doute il vaut mieux sur
dimensionner les tailles. Le proverbe qui s’adapte à la situation est « Qui
peut le plus peut le moins ».
Exemple : Suite à une demande d’un membre de notre famille, président

d’une association, nous devons établir le dictionnaire des données de la
gestion des adhérents. Voici une représentation d’une fiche d’adhérent :
À la lecture de la fiche, nous pouvons déterminer la présence de neuf

informations différentes :
● Le numéro de l’adhérent.
● Le nom.
● Le prénom.
● L’adresse.
● Le code postal.
● La ville.
● Le téléphone.
● Le mail.
● La date d’adhésion.
Voici le dictionnaire des données :
Nom Format Longueur Type Règle de Règle de Document

calcul gestion
E C
Numéro Numérique X Fiche
Nom Alphabétique 30 X //
Prénom Alphabétique 30 X //
Adresse Alphabétique 50 X //
Code Postal Alphanumérique 10 X //
Ville Alphabétique 50 X //
Téléphone Alphanumérique 15 X //
Mail Alphanumérique 50 X //
Date d’adhésion Date X //
Le code postal est alphanumérique et de taille 10. Certaines personnes

peuvent considérer qu’il serait plus judicieux de placer le format en
numérique. Or qu’est ce qui prouve que dans certains pays la règle d’écriture
des codes p os ta ux est identique à la règle française des 5 chiffres ? En
effet, certains pays mélangent des chiffres et des lettres. Le format
alphanumérique est le plus approprié dans ce caslà. De manière générale,
il est souhaitable de ne formater en numérique que les champs sur lesquels
il va y avoir des calculs. Le raisonnement appliqué est le même pour le
champ téléphone.
III.4. REGLES DE NORMALISATION

Un bon schéma entités-associations doit répondre à 9 règles de normalisation,
que le concepteur doit connaitre par cœur.
Les bonnes manières dans un schéma entités-associations

Normalisation des entités (importante) : toutes les entités qui sont remplaçables
par une association doivent être remplacées (comme sur la figure 8).
Normalisation des noms : le nom d’une entité, d’une association ou d’un attribut
doit être unique.
Conseils : Pour les entités, utiliser un mon commun au pluriel (par exemple :
clients) ;
- Pour les associations, utiliser un verbe à l’infinitif (par exemple : effectuer,

concerner) éventuellement à la forme passive (être commandé) et
accompagné d’un adverbe (avoir lieu dans, pendant, a) ;
- Pour les attributs, utiliser un nom commun singulier (par exemple : nom,
numéro, libelle, description) textuellement accompagne du nom de
l’entité ou de l’association dans laquelle il se trouve (par exemple : nom,
de client, numéro d’article).
Remarque : lorsqu’il reste plusieurs fois le même nom, c’est parfait

symptomatique d’une modélisation qui n’est pas terminée (figure 11(a)) ou
signe d’une redondance (figure 11 (b))
(b) Si deux attributs contiennent les mêmes informations, alors la redondance

induit non seulement un gaspillage d’espace mais également un grand risque
d’incohérence : ici ; les adresses risquent de ne pas être les mêmes et dans ces
conditions, ou faut-il le livrer ?
Normalisation des identifiants : chaque entité doit posséder un identifiant.
Conseils :
- Eviter les identifiants composent de plusieurs attribut (comme par

exemple un identifiant forme par les attributs nom et prénom), car d’une
part c’est mauvais pour les performances et d’autre part, l’unicité suppose
par une telle démarche finit tôt ou tard par être démenti ;
- Préférer un identifiant court pour rendre la recherche la plus rapide possible
(éviter notamment les chaines de caractères comme un numéro de plaque
d’immatriculation, un numéro de sécurité sociale ou un code postal);
- Eviter également les identifiants susceptibles de changer au cours du temps
(comme les plaques d’immatriculation ou les numéros de sécurité sociale
provisoires.)
Conclusion : l’identifiant sur un schéma entités-associations (et donc la future
clé primaire dans le schéma relationnel) doit être sur un entier, de préférence
incrémente automatiquement.
Normalisation des attributs (importante) : remplacer les attributs en plusieurs

exemplaires en une association supplémentaire de cardinalités maximales n et
ne pas ajouter d’attribut calculable à partir d’autre attributs.
En effet, d’une part, les attributs en plusieurs exemplaires posent des problèmes
d’évolutivité du modelé (sur la figure 12 (a) à gauche, comment faire si un
employé a deux adresses secondaires ?) et
(a) Attributs en plusieurs exemplaires remplacés par une association

supplémentaire.
d’autre part, les attributs calculables induisent un risqué d’incohérence entre les
valeur des attributs de base et celles des attributs calculés, comme sur la figure
12(b).
D’autres d’attributs calculables classique sont à éviter, comme l’âge (qui est
calculable à partir de la date de naissance) ou encore le département (calculable
à partir d’une sous-chaine du code postal).
Normalisation des attributs des associations (importante) ; les attributs d’une

association doivent dépendre directement des identifiants de toutes les entités
en association.
Par exemple, sur la figure 5 quantité commandée dépend à la fois du numéro

de client et du numéro d’article, par contre la date de commande non. Il faut
donc faire une entité commande à part, idem pour les livraisons (figure 13).
L’inconvénient de cette règle de normalisation est qu’elle est difficile à appliquer

pour les associations qui ne possèdent pas d’attribut. Pour vérifier malgré tout
qu’une association sans attribut imaginaire (mais pertinent) qui permet de
vérifier la règle.
Par exemple, entre les entités livres et auteurs de la figure 16, l’association écrite
ne possède pas d’attribut. Imaginons que nous ajoutons un attribut pourcentage
qui contient le pourcentage du livre écrit par chaque auteur (du même livre).
Comme cet attribut pourcentage dépendra la fois du numéro de livre et du
numéro d’auteur, l’association écrire est bien normalisée. Autre conséquence de
la normalisation des attributs des associations : une entité avec une cardinalité
de 1,1 ou 0,1 aspire les attributs de l’association (figure 14).
Normalisation des associations (importante) : il fout éliminer les associations

fantômes (figure 15(a)), redondantes (figure 15 (b)) ou en plusieurs exemplaires
(figure 15 (c)).
En ce qui concerne les associations redondantes, cela signifie que s’il existe deux
chemins pour se rende d’une entité a une autre, alors ils doivent avoir deux
significations ou deux durées de vie différentes. Si non, il faut supprimer le
chemin le plus court, car il est déductible à partir de l’autre chemin. Dans notre
règlement en passant par la facture qui corresponde.
Remarque : une autre solution pour le problème de figure 15(b) consiste à

retirer l’entité règlements et d’ajouter une association régler avec les mêmes
attributs (sauf l’identifiant) entre les entités clients et factures.
Normalisation des cardinalités : une cardinalité minimale est toujours 0 ou 1

(et pas 2, 3 ou n) et une cardinalité maximale est toujours 1 ou n (et pas 2, 3,……).
Cela signifie que si une cardinalité maximale est connue et vaut 2,3 ou plus
(comme sur la figure 15(c) à droite, ou pour un nombre limité d’emprunts dans
une bibliothèque), alors nous considérons quand même qu’elle est
indéterminée et vaut n. cela se justifie par le fait que même si nous connaissons
n au moment de la conception, il se peut que cette valeur avouée au cours du
temps. Il vaut donc mieux considérer n comme une inconnue dès le départ.
Cela signifie également qu’on ne modélise pas les cardinalités minimales qui
valent plus de 1 car ce genre de valeur est aussi amené à évoluer. Par ailleurs,
avec une cardinalité maximale de 0, l’association n’aurait aucune signification.
Dans un SGBD relationnel, nous pourrions les cardinalités valant 2,3 ou plus, via
l’utilisation de déclencheurs. Mais cette notion n’est pas abordée dans ce
document qui se contente, au contraire, de décrier ce qu’il est possible de faire
sans utiliser de déclencheur.
Les Formes Normales

A ces 6 règles de normalisation, il convient d’ajouter les 3 premières formes
normales traditionnellement énoncées pour les schémas relationnels, mais qui
trouvent tout aussi bien leur place en ce qui concerne les schémas entités-
associations.
Première forme normale : à un instant donne dans une entité, pour un individu,
un attribut ne peut prendre qu’une valeur et non pas, un ensemble ou une liste
de valeur.
Si un attribut prend plusieurs valeurs, alors ces valeurs doivent faire l’objet d’une
entité supplémentaire, en association avec la première (figure 16).
Deuxième forme normale : l’identifiant peut être composé de plusieurs

attributs mais les autres attributs de l’entité doivent dépendre de l’identifiant en
entier (et non pas une partie de cet identifiant).
Cette deuxième forme normale peut être oubliée si suit le conseil de n’utiliser
que identifiants non composes et de type entier. En vérité, elle a été vidée de sa
substance par la règle de normalisation des attributs des associations.
Considérons malgré tout le contre-exemple suivant : dans une entité clients

dont l’identifiant est composé des attributs nom et prénom, la date de fête d’un
client ne dépend pas de son identifiant en entier mais seulement de prénom.
Elle ne doit pas figurer dans l’entité clients, il faut donc faire une entité calendrier
a part, en association avec l’entité clients :
Troisième forme normale de Boyce-Codd (importante): tous les attributs

d’une entité doivent dépendre directement de son identifiant et d’aucun autre
attribut.
Si ce n’est pas le cas, il faut placer l’attribut pathologique dans une entité
séparée, mais en association avec la première.
Par exemple, l‘entité avons (figure 17 à gauche) dont les valeurs sont données
dans le tableau 1, n’est en troisième forme normale de Boyce-Codd, car la
capacité et le constructeur d’un avion ne dépendent pas du numéro d’avion mais
de son modèle. La solution normalisée est donnée figure 17 à droite.
III.5. DEPENDANCE FONCTIONNELLE.
Le rôle de l’établissement des dépendances fonctionnelles est de

nous aider à comprendre les liens existants entre chaque donnée.
Cette démarche de recherche des dépendances fonctionnelles est la
pierre angulaire de toute l’analyse des données. En effet, cette activité
étant la première dans l’élaboration de l’analyse, si elle est négligée
c’est tout l’ensemble qui en subira les conséquences.
Pour établir efficacement un modèle entités-associations bien normalisé, on
peut étudier au préalable les dépendances fonctionnelles entre les attributs puis,
les organiser en graphe de couverture minimale. Cette technique est
traditionnellement employée pour normaliser des schémas relationnels, mais
elle s’applique très bien en amont, au niveau des modèles conceptuels.
Définition et propriétés
Une donnée B dépend fonctionnellement (ou est en dépendance
fonctionnelle) d’une donnée A lorsque la connaissance de la valeur de la
donnée A nous permet la connaissance d’une et au maximum une seule
valeur de la donnée B.
Un attribut Y dépend fonctionnellement d’un attribut X si et seulement si une

valeur de X induit une unique valeur de Y. On note une dépendance
fonctionnelle par une flèche simple: X Y.
Par exemple, si X est le numéro de client et Y le non de client, alors on a bien

X Y. Par contre, on n’a pas Y X, car plusieurs clients de numéros
différents peuvent porter le même nom.
Transitivité : si X Y et Y Z alors X Z.
Par exemple, on a numéro de commande numéro de client non client,

donc on a aussi numéro de commande nom de client. Mais la dépendance
fonctionnelle numéro de commande nom de client est dite transitive, car
il faut par le numéro de client pour l’obtenir. Au contraire, la dépendance
fonctionnelle numéro de client nom client est directe. Seules les
dépendances fonctionnelles directes nous intéressent. D’autres exemples sont
donnés dans le tableau 2.
Un attribut Y peut avoir une dépendance fonctionnelle qui repose sur la

conjonction de plusieurs attributs, auquel cas la dépendance est dite non
élémentaire. Les dépendances fonctionnelles non élémentaires sont notées par
une flèche unique mais comportant plusieurs points d’entrée (regroupes autour
d’un cercle). Par exemple, la quantité commandée (d’un article dans une
commande) dépend de deux attributs : le numéro de commande et le numéro
d’article (figure 18). Notons que cette dépendance numéro de commande +
numéro d’article quantité est à la fois non élémentaire et direct.
Graphe de couverture minimale

En représentant tous les attributs et toutes les dépendances fonctionnelles
directes entre eux, nous obtenons un réseau appelé graphe est donne sur la
figure 19.
La technique de traduction en un schéma entité-associations
A partir du graphe de couverture minimale (figue 19), le schéma entités-

associations normalisé correspondant apparait naturellement (figure20), en
suivant quelques étapes simples.
Etape 1 : il faut repérer et souligner les identifiants.

Etape 2 : puis tous les attributs non identifiants qui dépend directement d’un
identifiant et d’un seul, forment une entité (avec l’identifiant, bien sûr).
Etape 3 : ensuite, les dépendances élémentaires entre les identifiants forment
des associations binaires dont les cardinalités maximales sont 1 au départ de la
dépendance fonctionnelle et n à l’arrivée.
Etape 4 : sauf si entre deux identifiants se trouvent deux dépendances

élémentaires réflexives, auquel cas l’association binaire a deux cardinalités
maximales valant 1.
Etape 5 : enfin, les attributs (on identifiants) qui dépendent de plusieurs
identifiants sont attributs d’une association supplémentaire dont les cardinalités
maximales sont toutes n.
La traduction du graphe de couverture minimale de la figure 20 en un schéma
entités-associations normalisé est donnée sur la figure 21.
Dans ce genre de traduction, il faut donner un nom aux entités et aux

associations, car ce n’est pas le cas sur le graphe de couverture minimale et il
reste les cardinalités minimales à établir.
Remarquons également qu’en réalité, il faut déjà connaitre les entités en

présence pour établir correctement le graphe de couverture minimale, ne serait-
ce que pour y faire figurer leurs identifiants. Donc, finalement, cette technique
n’est une aide pour établir les associations entre les entités et pour normaliser
les entités et leurs associations (jusqu’à troisième forme normale de Boyce-
Codd).
Graphe des dépendances fonctionnelles
Le graphe des dépendances fonctionnelles est une étape intéressante car il

épure le dictionnaire en ne retenant que les données non déduites et
élémentaires et il permet une représentation spatiale de ce que sera le futur
modèle conceptuel des données.
III.7. ETUDES DE DOCUMENTS UTILISES
Les informations se recueillent à l’intérieur du domaine à étudier.

La liste d’informations est constituée de plusieurs façons : l’interview, l’étude
des documents internes e t l ’étude des documents externes.
a. L’interview
Une des phases du recueil d’information est un entretien avec les différents
acteurs de l’organisation. Cet entretien permet de définir le périmètre de
l’applicatif futur. Les informations orales sont classées et regroupées en
parties distinctes. Ainsi, les informations concernant l’enregistrement des
données de l’organisation seront regroupées.
b. L’étude des documents internes

Les documents internes (factures, bons de livraison, ordres de fabrication)
recèlent des informations qui sont souvent omises lors des entretiens. Ces
oublis sont dus au caractère automatique et récurrent de ces informations.
Les personnes qui les manipulent au quotidien oublient souvent de les citer
tant elles leur paraissent évidentes.
c. L’étude des documents externes

L’étude des documents externes (factures des fournisseurs, bons de livraison
fournisseurs...) tout comme l’étude des documents internes permet de
découvrir des informations oubliées lors des interviews et de découvrir aussi
quelques règles de gestion. Pour ce recueil d’informations, il est nécessaire
de respecter certaines règles pour éviter des erreurs futures.
Avant d’ajouter une information, i l est impératif de s’assurer qu’elle n’est
pas déjà présente. Par exemple, un numéro client peut apparaître sur un
bon de livraison et sur une facture. Ce n’est pas la peine de le répertorier

deux fois. De même, une information peut être synonyme d’une autre. Par
exemple sur le bon de livraison il apparaît « Code client » et sur la facture «
Numéro Client ». Il est impératif de ne garder qu’une seule des deux
informations.
III.8. LES ETAPES POUR LA CONSTRUCTION D'UN MCD
Ici, 2 démarches non antagonistes :

– Déductive : exploite le maximum de données récupérées, les trie, les organise,
et on crée le MCD
– Inductive : on crée le MCD tout de suite, en s’appuyant sur les concepts et en
les décrivant par des informations.
Démarche déductive
Il faut retrouver les informations utilisées au travers des entretiens et des

documents utilisés
 Pour chaque nouvelle information, il faut se demander si :
– elle n’est pas déjà répertoriée (sous le même nom ou sous un autre nom)
– une appellation identique n’existe pas déjà pour une autre information
différente
 On crée un dictionnaire des données
Démarche inductive
On identifie les concepts utilisés (d’après les entretiens ou les documents)

 On modélise ces concepts par un MCD
 On décrit ensuite chaque concept par des propriétés
 Cette démarche est la plus simple à mettre en œuvre, moins lourde que
celle déductive
 Elle est également plus « créatrice »
 Les deux démarches se complète ou s’émulent
L'étude de l'existant
 Interview de la direction (Système de Pilotage).
 Objectifs principaux.
 Liste des postes de travail.

 Délimiter le champ de l’étude.
 Interview des postes de travail (Système Opérant).
 Recenser et décrire les tâches exécutées.
 Observer la circulation des informations.
 Apprendre le langage de l’entreprise.
 Etablissement d’une liste des règles de gestion.
 Construction d’un dictionnaire de données (DD).
 Construction du GDF (Graphe des Dépendances Fonctionnelles).
 Extraire du DD la liste des attributs qui ne sont ni concaténés, ni

calculés.
 Ne pas considérer les DF transitives pour obtenir un GDF avec une

couverture minimale (répondant à la 3FN).
 Transformation du GDF en MCD.
 Mise au propre du MCD.
ETUDE DE CAS : GESTION DE VENTE DES INTRATS AGRICOLES, INERA

YANGAMBI
Graphe des dépendances fonctionnelles

Construction de MCD
Règles de gestion
 RG 1. Un client peut commander un ou plusieurs intrants agricoles ;

 RG 2. Un client peut effectuer un ou plusieurs paiements ;
 RG 3. Un intrant peut être concerné par un ou plusieurs stocks ;
 RG 4. Une catégorie peut Avoir un ou plusieurs intrants
 RG 5. Un fournisseur peut fournir un ou plusieurs stocks des intrants
LE NIVEAU ORGANISATIONNEL
Après avoir défini les fonctions principales de l'entreprise et ses domaines

d'information, les concepts et la transformation des messages, le cadre de
l'application est stabilisé. Le propos de ce chapitre est la définition de
l'organisation, des postes de travail, des sites de traitement et de données. La
définition des outils de gestion informatiques viendra à l'étape suivante, au
niveau logique.
CHAP I. LE MODELE ORGANISATIONNEL DE TRAITEMENTS (MOT)
I.1. Introduction
Les modèles organisationnels de traitement (MOT) définissent ce que fait chaque
poste de travail. Le Modèle Organisationnel de Traitement (MOT) répond à la
question « QUI FAIT QUOI »? Préalablement à ces modèles, l'organisation des
postes de travail, QUI, est définie.
Le modèle organisationnel des traitements (MOT) définit ce que fait chaque poste
de travail, répond à la question « qui fait quoi ? » Préalablement à ce modèle,
l’organisation de travail qui est définie. Les fonctions de l’entreprise sont
« projetées » sur les postes de travail. Toute opération conceptuelle devra être
exécutée de manière organisée par un poste de travail.
Les modèles organisationnels de données (MOD) ajoutent la géographie des

données aux concepts. Chaque modèle organisationnel est un sous-ensemble
du modèle conceptuel adapté à un site de données. Le lien entre MCD et MOD
est donc fort. Un MCD correspond à un domaine. L'étude des MOD se conduit
par domaine afin de faire ressortir les cohérences et les consolidations entre site.
Les MOD s'enrichissent, par rapport au MCD, de nouveaux individus liés à
l'organisation tels que "autorisation", "document", "historique".
Les modèles organisationnels de communication (MOC) représentent les
communications entre sites de traitement, attachés à un poste de travail, et un
site de données. L'ordre des trois modèles du niveau organisationnel
(traitements, données et communications) est différent de celui du niveau
conceptuel.
I.2. Problématique du MOT

Le MCT s’est occupé du QUOI : quelle est l’activité de l’entreprise, sans
s’intéresser aux ressources mises en œuvre. Le MOT va s’intéresser, du point de
vue fonctionnel, à la question : COMMENT est organisée l’activité ?
Attention, le « COMMENT » du MOT ne répond pas à la question : comment est
réalisé le traitement ? Cette question relève de l’analyse organique et des
niveaux logique et physique.
Pour répondre à la question « Comment est organisée l’activité », on va répondre

aux questions :
QUI fait l’activité ?
OU est faite l’activité ?
QUAND est faite l’activité ?
Le MOT part du MCT et du diagramme conceptuel des flux et précise

particulièrement :
Quelles sont les RESSOURCES ? (humaines et matérielles).
Le MOT fait intervenir essentiellement une nouvelle notion : Le POSTE de
TRAVAIL
Pour finir, le MOT va préciser :

- Les relations entre ressources humaines et postes de travail.
- Les tâches à réaliser sur chaque poste de travail, avec leur ordre et
éventuellement la durée.
- La circulation des informations entre les postes de travail.
I.3. Poste de travail et Organigramme.
I.3.1.Poste de travail.
Le découpage organisationnel de l'entreprise définit les postes de travail ou les
unités d'organisation. "QUI", poste de travail est défini avant de déterminer "QUI
FAIT QUOI ?"
Un poste de travail est une responsabilité au sein de l'entreprise : P. D. G.,
directeur commercial, secrétaire... Il est aussi "casquette" : acheteur, vendeur...
Une même personne peut avoir plusieurs casquettes. Tout dépend de ses
capacités et de sa charge de travail. Certaines personnes auront toujours la
même casquette : Andy Capp, le héros de bande dessinée, par exemple. D'autre
part, plusieurs personnes peuvent porter la même "casquette" comme une
caissière dans un supermarché. A l'étape suivante, il sera nécessaire d'affecter
des personnes à chaque poste. Les écrans informatiques seront validés par les
personnes affectées à un poste, les utilisateurs finals.
Une organisation est une adaptation des fonctions de l'entreprise à

l'environnement en les projetant sur les postes de travail.
Un poste de travail est défini par les moyens mis à disposition (personnes,
ressources matérielles et logicielles) et le travail à effectuer (les opérations
organisées).
La définition des postes de travail reflète les intervenants définis au niveau
conceptuel.
Un poste de travail est caractérisé par :

- une fonction à assurer (exemple : gestion des stocks, ….)
- une implantation géographique (lieu) ;
- un ensemble de moyens ou ressources (personnel, matériel).
Ceci équivaut aux acteurs du modèle acteurs/flux.
ORGANISATION
Poste 1 Poste 2 Poste 3
FONCTION
Intervenant 1
Interne
Intervenant 2
Interne
Intervenant 3
Interne
L'organisation est SPECIALISEE...
Si chaque poste de travail traite une fonction, l'entreprise est organisée de

manière spécialisée.
A la Poste, à un guichet (poste de travail 1, 2, ou 3) correspond une fonction :
distribuer les timbres-poste, affranchir les lettres et les paquets, payer les
mandats... les intervenants internes.
ORGANISATION
Poste 1 Poste 2 Poste 3
FONCTION
Intervenant 1
Interne
Intervenant 2
Interne
Intervenant 3
Interne
...ou POLYVALENTE
Par contre, aux Etats-Unis, chaque poste de travail exerce les différentes
fonctions. Les clients attendent sur une file commune et vont au premier guichet
libéré. Cette organisation est non spécialisée ou polyvalente. On peut aussi dire
qu’il n’existe qu’un seul poste de travail.
Les raisons de s'organiser de telle ou telle manière sont des raisons de bon sens
telles qu'un partenaire (le client par exemple) doit toujours avoir un même poste
de travail (interlocuteur client) comme correspondant pour le fidéliser ou des
raisons de pouvoir ou d'historique non formalisable. L'utilisateur exerce son
choix.
I.3.2. Organigramme.
L'organigramme est un dessin représentant la structure d'organisation des
postes de travail de l'entreprise.
Pour être défini sans ambiguïté, un poste de travail ne doit dépendre que d'un
seul poste de travail amont (qui est responsable ?) et doit avoir ses
responsabilités clairement énoncées (que fait-il ou que doit-il faire ?). Cela
évitera d'embaucher un salarié pour faire A, lui faire faire B, le juger sur C et lui
octroyer la médaille du travail pour D.
Poste de
P. D. G.
Travail
D. G. Service de livraison
L'architecture des postes de travail est représentée par un organigramme...
Le niveau de détail de la définition des postes de travail dépend de l'objectif

poursuivi par sa construction. S'il s'agit de définir l'organisation générale
d'une grande entreprise, l'organigramme est général. S'il s'agit de définir ou
valider des écrans informatiques, l'organigramme doit être détaillé. Le travail

de la secrétaire est différent de celui du livreur.
P. D. G.
D. G. Service de livraison
Livreur Secrétariat de livraison
Au niveau conceptuel des traitements, sont définies les actions à effectuer par
les acteurs de l’organisme en même temps qu’on identifie les acteurs externes
qui agissent sur le système.
S'organiser consiste aussi à prévoir les réactions ou les réflexes à acquérir face à
des événements extérieurs. Ces réflexes normalisés au sein de l'entreprise sont
décrits sous formes de procédures, les MOT.
Un MOT analyse les réactions des postes de travail à un message
externe.
ENTREPRISE ORGANISEE
Partenaire Poste 1 Poste 2 Poste 3 Partenaire
Message "externe"
enclenchant
Une procédure peut commencer par une opération sans message événement
comme la décision de passer des contrats financiers. L'éclatement d'une
opération conceptuelle en N opérations organisées permet un partage des
responsabilités et doit définir le contrôle en découlant. Le regroupement
d'opérations conceptuelles en une opération organisée ou sur un poste de
travail permet une synchronisation, donc une accélération des traitements
organisés et la création de postes de travail "correspondant" de partenaires - le
client a un interlocuteur unique pour la commande, la livraison, le service après-
vente, le contentieux...
Les questions relatives aux conditions de déroulement de ces actions et les

échanges intra-entreprise qu’elles impliquent révèlent du Modèle
Organisationnel des Traitements (MOT).
Celui-ci devra répondre aux questions suivantes :
 Qui sont les intervenants au sein de l’entreprise ?

 Où se trouvent-ils géographiquement ?
 De quelles ressources dispose-t-on pour réaliser les actions ?
 Selon quelle périodicité se déroulent les traitements ?
 Quelle est la durée d’exécution des traitements ?
Par rapport à une opération conceptuelle, une opération organisationnelle
comportera en plus :
 Les moyens matériels qui autorisent le déploiement de l’opération

 Les ressources humaines en termes de qualifications des agents chargés
d’exécuter les traitements et
 Les conditions temporelles qualifiées de la réalisation des opérations.
I.4. La tache (Procédure Fonctionnelle (PF))
I.4.1. Présentation : Tâche, phase et opération

Le concept de tâche rejoint les concepts d’opération et de phase.
Une opération peut être constituée de plusieurs phases (en fonction des acteurs
internes qui interviennent dans la réalisation de l’opération).
Une phase peut être constituée de plusieurs tâches (en fonction du caractère
manuel, interactif ou automatique des activités de la phase). Enfin, la tâche peut
être constituée de plusieurs activités.
Une Procédure Fonctionnelle (PF)) : d’une manière générale, une opération

du niveau conceptuel est transformée en au moins une Procédure
fonctionnelle (PF) au niveau organisationnel.
Une Procédure Fonctionnelle est un ensemble logique structuré d’actions

élémentaires dont l’activation est provoquée par l’application d’un ou plusieurs
événements. Elle est réalisée par un même acteur et son déroulement ne
nécessite pas l’intervention d’autres événements ou acteurs.
Une procédure quant à elle est un ensemble logique de procédures

fonctionnelles qui s’enchainent et qui concourent à la même finalité et qui se
déroulent selon la même périodicité. C’est l’équivalent du processus du

niveau conceptuel.
Synchronisation
Pour chaque tâche, on précise la synchronisation des événements
déclencheurs (flux IN).
Conditions de sorties
Pour chaque tâche, on précise les conditions de sortie des résultats (flux OUT).
Activités (ou règles de gestion ou fonction)

Pour chaque tâche, on donne la liste de ses activités. Les activités sont aussi
appelées : règles de gestions. Il arrive souvent que la tâche ne contienne plus
qu’une seule activité.
Dans le cas des tâches interactives (tâches réalisées avec un logiciel), on peut
préciser les paramètres en entrées et en sortie de la tâche (en-tête de la tâche),
ainsi que l’algorithme d’enchaînement de ces activités.
On peut aussi préciser les paramètres en entrées et en sortie de chaque activité
(en-tête de l’activité), ainsi que l’algorithme de l’activité. Pour chaque activité de
la tâche, on peut aussi décrire la fonction d’interface avec la base de données.
I.4.2. Propriétés spécifiques des tâches

Les tâches ont des propriétés spécifiques qu’on ne trouve pas au niveau des
phases et des opérations. On peut distinguer particulièrement 3 propriétés
principales et 2 propriétés secondaires.
Les 3 propriétés principales des tâches et des activités
Tâches et activités sont caractérisées par trois propriétés principales :

Le degré d’automatisation
- Une tâche (ou une activité) peut être : Manuelle (M), Interactive (I) ou
Automatique (A).
Une tâche (ou une activité) manuelle (M) est une tâche qui ne mobilise que des
ressources manuelles. Par exemple : la vérification du dossier de commande.
- Une tâche (ou une activité) interactive (I) est une tâche qui mobilise des
ressources manuelles et informatiques. On parle aussi de tâche
conversationnelle (C).
- Une tâche (ou une activité) automatique (A) est une tâche qui ne mobilise,
une fois lancée et jusqu’à la production des résultats, que des ressources
informatiques.
I.4.3. Le mode de traitement

Une tâche (ou une activité) peut être : à traitement unitaire (U) ou à
traitement par lots (L).
- Une tâche (ou une activité) à traitement unitaire (U) traite les
occurrences d’événements déclencheurs une par une.
- Une tâche (ou une activité) à traitement par lot (L) traite ces occurrences
par paquets dont la taille est à définir.
I.4.4. Le délai de réponse

Une tâche (ou une activité) peut être : Immédiate (I) ou Différée (D).
- La réponse est immédiate (I) quand le déclenchement de la tâche n’est
lié qu’à la survenance d’un événement.
- La réponse est différée (D) quand le déclenchement est conditionné par
un délai.
I.4.5. Principe de division de la phase en tâches

Les propriétés principales d’une tâche peuvent se reporter sur ses activités. Dans
une tâche, on met des activités qui ont les mêmes propriétés principales. La
subdivision de la phase en tâches vient donc de la distinction des propriétés des
activités.
Exemple
La phase de secrétariat dans la gestion de la vente par correspondance
contient deux activités : la vérification et la saisie. La vérification est une activité
manuelle. La saisie est une activité interactive.
La phase va donc se diviser en deux tâches :
- Une tâche manuelle, immédiate et unitaire qui va consister à vérifier que

le dossier est complet. S’il n’est pas complet, on renvoie un courrier sans
rien enregistrer de plus.
- Une tâche interactive, immédiate et unitaire qui va consister à saisir les
données de la commande.
Les 2 propriétés secondaires des tâches et des activités
- La périodicité : On peut préciser la périodicité (ou fréquence) s’il y a

lieu.
- La durée : On peut préciser la durée s’il y a lieu.
I.4.6. Enchaînement des tâches : synchrone et asynchrone

L’enchaînement des tâches peut être synchrone ou asynchrone.
- Enchaînement synchrone
Deux tâches sont enchaînées de façon synchrone quand elles se suivent sans
interruption temporelle.
- Enchaînement asynchrone
Deux tâches sont enchaînées de façon asynchrone quand elles se suivent avec
une interruption temporelle.
Cela signifie que la cause du déclenchement de la seconde tâche n’est pas
seulement la terminaison de la première, mais aussi un autre événement, le plus
souvent une échéance.
I.4.7. Synchronisation et délai de réponse des tâches

Les tâches à traitement différé suivent toujours celles qui les précèdent de façon
asynchrone.
Les tâches à traitement immédiat suivent toujours celles qui les précèdent de
façon synchrone.
- La phase
La phase est une succession de tâches exécutées consécutivement au sein
d’un même poste.
Graphiquement, on présentera ensemble les tâches d’une même phase.
L’enchaînement des tâches dans une même phase se modélise par un simple
lien qui exprime la continuité des tâches dans la phase : non-interruptibilité.
I.4.7 MOT et MCT

Le MCT est construit à partir du diagramme de contexte (diagramme conceptuel
des flux). Le MOT est construit à partir du diagramme des flux (diagramme
organisationnel des flux) : il fait apparaître les acteurs internes, c’est-à-dire
l’organisation de l’entreprise.
I.4.8. Règles de passage du MCT au MOT
En pratique, on réalise le MOT à partir du tableau des phases en décomposant

les phases en tâches.
Le Modèle Organisationnel des traitements consiste à 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. L’unité de
traitement dans le MOT est la procédure fonctionnelle (PF) ;
Règle1 : Toute opération conceptuelle doit-être découpée en Procédure
Fonctionnelle, en analysant les petites tâches de traitement qui se passe au sein
de l’opération conceptuelle ;
Règle2 : Si le traitement change les résultats à mettre et ces résultats doivent
changer la nature ou n’intervient plus comme évènement contributeur ou
déclencheur dans la Procédure Fonctionnelle suivante ou on parle d’arrêt de
processus ;
Règle3 : Toutes les procédures fonctionnelles doivent être décrites dans un
tableau qui peut être divisé en Processus selon le besoin de l’analyse ;
Règle4 : Chaque procédure fonctionnelle doit être écrite de la manière
suivante :
Numéro de la procédure ; Action de la procédure ; Nature du traitement ; le
temps du traitement ; et le poste de travail (Lieu, Responsable, Ressource) ;
Règle5 : le Diagramme d’enchainement des Procédures fonctionnelles doit être
l’aboutissement du Modèle Organisationnel de Traitement (MOT).
I.4.9. Représentation graphique du MOT

Le MOT décrit graphiquement chaque phase du tableau des phases en les
décomposant en tâches.
Enchaînement chronologique des tâches

Dans un même schéma, on représente une phase avec l’enchaînement
chronologique de toutes les tâches de la phase (axe du temps vertical). On peut
aussi présenter plusieurs phases dans un même schéma.
Formalisme
Le formalisme reprend celui du MCT. Toutefois, on précisera les propriétés, les
ressources matérielles (postes informatiques surtout), et les modifications de
données du MCD. Les deux principaux schémas utilisés pour modéliser le MOT
sont :
- Le diagramme d’enchainement des procédures fonctionnelles et
- Le graphe de circulation des informations
Le Diagramme d’Enchainement des Procédures Fonctionnelles (DEPF).
Dans transformation des opérations en procédures fonctionnelles dotées des

aspects organisationnels suivants : le temps (périodicité, temps début, durée
d’exécution), la nature, le poste de travail avec les ressources qui sont affectées.
Dans le futur système, les procédures fonctionnelles apparaitront en effet
comme des réactions concrètes d’Operations conceptuelles qui se situent à un
niveau dénué de contraintes organisationnelles. La forme générale du
diagramme d’enchainement des procédures fonctionnelles est : le diagramme
d’enchainement des procédures fonctionnelles, nous trouvons également le
Tableau des Procédures Fonctionnelles.
Le Graphe de Circulation des Informations (GCI) met en évidence les

échanges entre les différents postes de travail. C’est une repensassions qui
fournit une bonne perception de la transformation progressive des informations.
Elle permet également de déceler les procédures fonctionnelles, chacune de
celle-ci étant affectées de sa périodicité et éventuellement de sa durée
d’exécution. Les symboles ci-après servent à la représentation schématique de
la circulation de l’information au sein du système d’information. C’est l’une
des méthodes utilisées pour présenter ou analyser les flux d’informations entre
service. Donc c’est une étude qui analyse comment les informations circulent
d’un poste à l’autre, d’un traitement à l’autre.
Procédure automatisée
Conversationnelle
(Ressources : homme + machine)

Support papier
Disque magnétique
Support parcouru par information
Chemin parcouru par information
Procédure manuelle
I.4.9. Règles d’obtention des Procédures Fonctionnelles

Pour transformer les opérations du MCT en Procédures Fonctionnelles (taches)
du MOT, il faut regrouper les règles de gestion du niveau conceptuel selon des
critères organisationnels. D’où la nécessité de prendre en compte
respectivement :
- Les aspects du niveau conceptuel de traitement

- Les aspects propres au niveau organisationnel
- L’origine des règles de gestion ainsi que l’organisation et leur validité dans
le temps.
Point de départ :
1. On considère les règles de gestion définies dans le nouveau Modèle
Conceptuel de Traitements
2. On définit les nouvelles règles d’organisation :
- Quel poste de travail assure le traitement ?
- Le traitement est manuel ou automatisé ?
- Quelles contraintes de temps dues à l’organisation ?
Procédure : Ici, chaque opération conceptuelle est décomposée en un

ensemble de phases.
Phase : C’est un ensemble de taches dont l’enchainement est non interruptible

compte tenu de l’organisation mise en place. Toutes les taches d’une phase se
déroulent :
- sur un même poste de travail (unité de temps)
- à un moment déterminé (unité de temps)
- avec des moyens homogènes – manuel ou automatique – (unité d’action)
Exemple : Chaque jour à 16h le Secrétariat exécute la phase ‘Saisie du Dossier’
sur micro ;
Liste des tache liées à cette phase : Saisie des données, Mise à Jour du fichier
informatique ‘Dossier’, Classement du dossier papier.
ETUDE DE CAS : GESTION DE VENTE INTRATS AGRICOLES

Les règles d’organisation (RO)
RO1 : L’INERA Yangambi travail de Lundi au Samedi de 8h30 jusqu’à 16h30
RO2 : Client doit adresser sa commande auprès de Directeur de centre de
recherche
RO3 : Le Directeur de centre de recherche conduit la commande de client à la
coordination des activités de recherche pour assurer de la disponibilité de stock.
RO4 : La facture est élaborée au service de la comptabilité après la vérification
de stock.
RO5 : Le client paie sa facture à la caisse après la vérification de l’authenticité de
facture au service de budget contrôle.
RO 6 : Le caissier doit faire rapport de paiement de facture de client auprès de
la cellule de gestion de stock et magasin pour la passassions des écritures.
RO7 : La livraison est intervenue après la passassions des écritures et le contrôle
de paiement.
Tableau des procédures fonctionnelles
PROCEDURE D′APPROVISIONNEMENT
Poste de travail
Nature
PF Déroulement Action Responsabl
Lieu Ressource
e
C.P.A et
Elaboration de
8h30’<t<16h00 Chef de Chef de
PF1 rapport de l’état AC C.G.S.M
’ cellule cellule,
de stock
Ordinateur
8h30’<t<16h00 Transmission de
PF2 M D.C.R Directeur Directeur
’ rapport de stock
Analyse de
8h30’<t<16h00
PF3 rapport de l’état M D.C.R Directeur Directeur
’
de stock
C.D,
8h30’<t<16h00 Décaissement de Chef de
PF4 M D.A.F Comptable,
’ fonds division
Ordinateur
8h30’<t<16h00 Elaboration de
PF5 AC D.C.R Directeur Directeur
’ B.C
8h30’<t<16h00 Directeur,
PF6 Envoi de B.C M D.C.R Directeur
’ Fournisseur
8h30’<t<16h00 Confirmation de Directeur,
PF7 M D.C.R Directeur
’ commande Fournisseur
C.D,
8h30’<t<16h00 Paiement de Chef de
’ facture division
Ordinateur
C.P.A et
8h30’<t<16h00 Livraison des Chef de
PF9 M C.G.S.M Chef de
’ intrants agricoles cellule
cellule
C.D,
8h30’<t<16h00 Contrôle des Chef de
’ intrants division
Ordinateur
C.P.A et
8h30’<t<16h00 Mise en jour de Chef de Chef de
PF11 AC C.G.S.M
’ stock cellule cellule,
Ordinateur
PROCEDURE DE COMMANDE CLIENT
Poste de travail
Nature
Lieu Ressource
e
8h30’<t<16h00 Passassions Directeur,

’ commande Client
C.P.A et
Vérification de
8h30’<t<16h00 Chef de Chef de
PF13 quantité AB C.G.S.M
’ cellule cellule,
disponible
Ordinateur
8h30’<t<16h00 Confirmation de Directeur,

’ commande C.A.R
Directeur,
8h30’<t<16h00 Enregistrement de
PF15 AC D.C.R Directeur Client,
’ commandes
Ordinateur
PROCEDURE DE FACTURATION
Poste de travail
Nature

Lieu Ressource
e
Chef de
8h30’<t<16h00 Etablissement Chef de division,
PF16 AC D.A.F
’ facture division Comptable,
Ordinateur
Contrôle de Chef de
8h30’<t<16h00 Budget Chef de
PF17 l’authenticité de M service,
’ contrôle service
facture Scanneur
8h30’<t<16h00 Directeur,
PF18 Remise facture M D.C.R Directeur
’ Client
8h30’<t<16h00 Caissier,
PF19 Paiement facture M Caisse Caissier
’ Client
8h30’<t<16h00 Enregistre de Caissier,
PF20 AC Caisse Caissier
’ paiement Ordinateur
CONSTRUCTION DU DIAGRAMME D’ENCHAINEMENT DES PROCEDURES

Graphe de circulation des informations

CHAPITRE II. LE MODELE ORGANISATIONNEL DES DONNEES (MOD)
La modélisation organisationnelle des données va permettre de prendre en

compte des éléments relevant de l’utilisation des ressources de mémorisation :
- Le choix des informations à mémoriser informatiquement.
- La quantification (ou volume) et la durée de vie des informations à mémoriser.
- La répartition des données informatisées entre unités organisationnelles.
- L’accès aux données informatisées pour chaque unité organisationnelle.
Le Modèle Organisationnel des Données (MOD) est la représentation de

l’organisation, des circuits, des postes de travail et de la répartition des
traitements entre l’homme et la machine, par poste de travail. Le modèle
organisationnel des données (MOD) consiste à l’organisation des données en
fonction des logiciels retenus (Base des données, fichier).
Le modèle organisationnel des données apparaît donc comme une

représentation, exprimée avec le formalisme entité-relation, des informations
qui seront mémorisées informatiquement compte tenu des volumes, de la
répartition et de l’accessibilité, sans encore tenir compte des conditions de
structuration, de stockage et de performance liées à la technologie de
mémorisation qui sera utilisée.
Le développement du Client/serveur nécessite une répartition des données

et des traitements entre les clients et un ou plusieurs serveurs. Le MOD se
caractérise par des préoccupations spécifiques.
Détermination des données retenues au niveau organisationnel

- Détermination des droits d'accès aux données.
- La visibilité des données par site organisationnel (S.I organisé en plusieurs
sites).
- La volumétrie des données actives (MAJ) et passives (Archivage).
- Pour chaque donnée ou ensemble de données
- Les droits d'accès en consultation, Mise à Jour, doivent être définis pour chaque
utilisateur
- Le formalisme du MOD est identique à celui du MCD.
2.1.1 Choix des données à mémoriser informatiquement

Il s’agit de choisir, à partir des données formalisées sur le modèle conceptuel

des données, celles qui devront être effectivement mémorisées
informatiquement dans le système d’information informatisé. Notons au
passage que d’autres informations pourront être mémorisées manuellement sur
support papier ou sur autres supports non informatique. Ces informations feront
toujours partie des informations constituant la mémoire du système
d’information organisationnel.
Le modèle organisationnel des données ainsi obtenu et ne prend pas en compte
les choix d’utilisation reparties.
2.1.2. REGLES DE PASSAGE DU MCD AU MOD
Les règles de passage du modèle conceptuel des données au modèle

organisationnel des données sont les suivantes :
1. Supprimer des éléments (entités, relations, propriétés) qui ne seront pas
mémorisés informatiquement pour trois raisons :
- Si l’objet ne pressente pas d’intérêt particulier pour l’application ;
- Lorsque l’objet ou la relation est techniquement impossible d’être
informatisés ;
- Si l’objet ne contient qu’une seule occurrence.
2. Modifier certains éléments (entités, relations, propriétés, cardinalités, …)
compte tenu du choix de mémorisation informatisé.
3. Ajouter de nouvelles informations pour permettre de faire le lien entre les
données mémorisées et les données restées manuelles ; par exemple la
référence des fiches, des dossiers, etc.
N.B : Si le modèle conceptuel contient des informations qui sont toutes

mémorisables informatiquement, alors ce modèle devient le modèle
organisationnel de données global.
2.1.3. IDENTIFICATION DES TYPES DE SITES ET DES TYPES D'ACTEURS :
a. Type d'acteurs : Ensemble d'occurrence d'acteurs travaillant sur un même type

d’activité (ex : le service comptable)
b. Type de site : Ensemble de type d'acteurs regroupé s sur un critère
organisationnel et/ou fonctionnel (ex. Agence régional)
2.1.4. DETERMINATION DES DROITS D'ACCES
Les droits d'accès doivent être définis par type d'acteur et/ou par type de site.
• Droit d'accès à la consultation largement autorisé sauf dans les cas spécifiques
de données sensibles (salaires, donné es stratégiques,)
• Les droits d'accès en M à J représentent un enjeu fondamental dans la
construction du SI s'assurer de l’unicité de la responsabilité de la M à J
• Dé finir des droits du M à J par ensemble homogène et cohérent de données
et par type d'acteur responsable.
2.1.5. LA REPARTITION DES DONNEES INFORMATISEES EN UNITES

ORGANISATIONNELLES ET LA PRISE EN COMPTE DE LEUR SECURITE
Répartition des données informatisées en unités organisationnelles

Nous ferons cette répartition en fonction de notre processus. Nous rappelons
les entités et relations les constituants sur l’ébauche du MOD global suivant :
- La connaissance de la répartition organisationnelle des données présente un
intérêt certain pour orienter ultérieurement la répartition informatique des
données, en particulier dans des environnements clients/serveurs.
- L’unité organisationnelle recouvre généralement un ensemble de postes
représentant par exemple un service ou un site géographique. Les utilisateurs
d’une unité organisationnelle ont une vue commune et partagée d’un ensemble
de données : le MOD local. Le MOD local et l’unité organisationnelle sont donc
un moyen d’exprimer, du point de vue de l’utilisateur, les données accessibles
par un ensemble de postes.
Le MOD local est un sous-ensemble du MOD global en termes :

• D’entités types, de relation types et de propriétés,
• D’occurrence d’entités ou de relation. Par exemple, une agence (unité
organisationnelle) ne gère que les contrats de son secteur.
2.1.6. LA PRISE EN COMPTE DE L’ACCESSIBILITE AUX DONNEESET DE LA

SECURITE
L’accessibilité des données d’un MOD local s’exprime par les actions
élémentaires que peuvent effectuer sur ce sous-ensemble de données les
traitements réalisés dans le site organisationnel. Ces différents types d’accès, en
lecture (L), en modification (M), en création (C) et en suppression (S), sont

précisés sur le MOD.
La sécurité des données définit des restrictions d’accès aux données mémorisées
pour certaines catégories d’utilisateurs.
Ces restrictions peuvent avoir un type limité d’actions (L, M, C, S) soit aux entités,
relations ou propriétés du MOD global ou local, soit à une sous-population des
occurrences d’entités ou des relations. La sécurité d’accès comprend la limitation
d’actions à certaines personnes et intègre aussi les aspects de confidentialité.
Ces droits peuvent être :

- Lecture : L
- Modification : M
- Création : C
- Suppression : S
Chacun de ces droits s’appliquant aux entités, aux attributs, aux associations et
à leurs occurrences. La sécurité d’accès passe par la définition de catégories ou
de profils d’utilisateurs. Pour chaque profil, on précise les éventuelles restrictions
d’accès envisagées. L’application de la répartition des informations
informatisées en unités organisationnelles ainsi que leurs accessibilités et
sécurités à notre cas d’étude se trouve présentée sur le schéma suivant :
Exemple de construction du MOD : Gestion de vente des intrants

Agricoles
Dérivation des MOD locaux au MOD Global

 Poste de travail
 Directeur centre de recherche
 Coordination des activités de recherche
 Cellule de gestion de stock et magasin
 Chef de Programme agricole
 Chef de Division Admin et Finance
 Caissier
a. Directeur centre de recherche
Légende :
A : Ajouter
M : Modifier
C : Consulter
S : Supprimer
b. Coordination des activités de recherche
Légende :
A : Ajouter
M : Modifier
C : Consulter
S : Supprimer
c. Cellule de gestion de stock et magasin
Légende :
A : Ajouter
M : Modifier
C : Consulter
S : Supprimer
d. Chef de Programme agricole
Légende :
A : Ajouter
M : Modifier
C : Consulter
Quantification des données
La quantification est une opération qui consiste à déterminer le volume des
données à mémoriser en spécifiant :
 La taille et la nature des propriétés ;

 Le nombre d’occurrences des objets et relations ;
 La cardinalité moyenne ;
 Le volume de la base de données.
NOMBRE
ENTITES IDENTIFIANT PROPRIETES LONG
D’OCCURENCE
Design
QteDispo
Intrant agricol CodeInt 85 8500
Categ
PU
NomCli
RefCli PrenomCli
Client 125 12500
AdressCli
TelCli
DateEnt
Stock RefStoc QteEntr 50 5000

QteInt
Catégorie CodeCat DesignCat 50 5000
DatePaie
Paiement NumPaie MotifPaie 90 9000
MontPaie
NomFour
Fournisseur RefFour PrenomFour 175 17500

AdressFour
TelCli
EmailFour
- Taille d’un enregistrement : 8500 + 12500 + 5000 + 9000 + 9000 +
17500 = 61500
- Taille total de la Base de données : (85*8500) + (125*12500) +
(50*5000) + (90*9000) + (90*9000) + (175*17500) = 7217500 Octet = 6,88
Mo
- Taille des données manipulées par jour : 6,88 Mo * 6,88 Mo = 47,3 Mo
LE NIVEAU LOGIQUE
CHAPITRE III. LE MODELE LOGIQUE DES DONNEES (MLD)
Maintenant que le MLD est établi, on peut le traduire en différents systèmes

logique et notamment les bases de données relationnelles qui proposent une
version plus concrète pour modéliser la situation.
Le Modèle Logique des Données (MLD) est la suite normale du processus

Merise. Son but est de nous rapprocher au plus près du modèle physique. Pour
cela, nous partons du Modèle Organisationnel des Données et nous lui enlevons
les relations, mais pas n'importe comment, il faut en effet respecter certaines
règles. Voici la procédure à suivre.
Pour l’obtention des tables présentant le plus de cohérence possible (éviter les
redondances et les valeurs nulles) dans leurs exploitations, il existe deux grands
procédés préconisés par la structure relationnelle de stockage de données :
Le processus de normalisation qui est une décomposition d’une table universelle
de départ en plusieurs tables par des projections définies judicieusement en
fonction des dépendances fonctionnelles entre attributs. Ce processus et
totalement réversible et possède cinq formes normales dont les trois premières
suffisent pour obtenir des tables canoniques.
L’application des règles de transformation du formalisme entité-relation en
formalisme relationnel sur le MOD pour en dériver un MLD. Cette transformation
est entièrement algorithmique mais n’est pas totalement réversible. Le modèle
ainsi obtenu est obligatoirement en deuxième forme normale du premier

procédé mais pas nécessairement en sa troisième forme. Bien que ce procédé
soit privilégié par la méthode MERISE, il conviendra, en toute rigueur, de vérifier
si les tables issues des entités sont en troisième forme normale.
Puisque nous utilisons la méthode MERISE, nous appliquons en ce point le
second procédé dont l’algorithme se présente comme suit :
III.1. SYSTEMES LOGIQUES
Avant l’apparition des systèmes de gestion de base de données (SGBD ou DBMS

pour Data Base Management System), les données étaient stockées dans des
fichiers et gérées par des programmes exécutables (développés en Basic, Cobol,
Dbase, par exemple). [Gabay] propose à ce sujet une traduction d’un MPD vers
MLD fiche. Mais la maintenance des programmes (en cas modification de la
structure des données, notamment) était très problématique.
Sont alors apparus les SGBD hiérarchiques dans lesquels les données sont
organisés en arbre (IMS-DLL d’IBM ; par exemple), puis les SGBD réseaux dans
lesquels les données sont organisées selon un graphe plus général (IDS2 de Bull,
par exemple). [Matheron, Nanci et al.. Gabay] décrivent la traduction d’un MPD
vers un MLD Codasy1 (base de données réseaux). Ces deux types de SGBD son
dit naviagtionnels car on peut retrouver l’information à condition d’en connaitre
le chemin d’accès.
Aujourd’hui, ils sont largement remplaces par les SGBD relationnels (SGBDR)
avec lesquels l’information peut être obtenue par un réseau formulé dans in
langage quasiment naturel (le langage SQL pour Structured Query Langage).
Parmi les SGBD les plus répandus nous trouvons Oracle, SQL Serveur et DB2.
Nous nous contentons ici d’exposer le modèle logique de données relationnel
(MLDR).
Plus récemment, sont apparus le modèle logique oriente objet et même des
SGBD orientes objets. Pourtant, les SGBD relationnels restent extrêmement
majoritaires tandis que l’approche orient objet est parfaitement adaptée au
développement d’application clients dynamiques et liées aux données du
system d’information.
III.2. MODELE LOGIQUE RELATIONNEL

Concentrons –nous désormais sur le MLDR.
Tables, ligne est colonnes
Lorsque des données ont la même structure (comme par exemple, les
renseignements relatifs aux clients), on peut les organiser en table dans laquelle
les colonnes décrivent les champs en commun et les lignes contiennent les
valeurs de ces champs pour enregistrement (tableau 3).
Clés Primaires et Clés Etrangères

Les lignes d’une table doivent être uniques, cela signifie qu’une colonne (au
moins) doit servir à les identifier. Il s’agit de la clé primaire de la table.
L’absence de valeur dans une clé primaire ne doit pas être autorisée. Autrement
dit, la valeur vide (NULL) est interdite dans une colonne, dont certaines peuvent
ne pas être renseignées à toutes les lignes.
De plus, la valeur de la clé primaire d’une ligne ne devrait pas, en principe,
changer au cours du temps.
Par ailleurs, il se peut qu’une colonne Colonne1 d’une table ne doive contenir
que des valeurs prises par la colonne Colonne2 d’une autre table (par exemple,
le numéro du client sur une commande doit par correspondre à un vrai numéro
de client). La colonne2 doit être sans doublons (bien souvent il s’agit d’une clé
primaire). On dit alors que la colonne1 est clé étrangère et qu’elle référence la
colonne2.
Par convention, on souligne les clés primaires et on fait précéder les clés
étrangères d’un dièse # dans la description des colonnes d’une table:
Clients (numéro client, nom client, prénom, adresse clients)

Commandes (numéro commande, date de commande, #numéro client (non
vide))
Remarque :
- Une même table peut avoir plusieurs clés étrangères mais une seule clé
primaire (éventuellement composée de plusieurs colonnes) ;
- Une colonne clé étrangère peut aussi être primaire (dans la même table) ;
- Une clé étrangère peut être composée (c’est le cas si la clé primaire
référencée est composée);
- Implicitement, chaque colonne qui compose une clé primaire ne peut pas
recevoir la valeur vide (NULL interdit) ;
- Par contre, si une colonne clé étrangère ne doit pas recevoir la valeur vide,
alors il faut le préciser dans la description des colonnes.
Les SGBDR vérifient au coup par coup que chaque clé étrangère ne prend pas
de valeurs en dehors de celles déjà prises par la ou les colonne (s) qu’elle
référence. Ce mécanisme qui agit lors de l’insertion, de la suppression ou de la
mise à jour de lignes dans les tables, grandit ce que l’on appelle l’intégrité
référentielle des données.
Schéma Relationnel
On peut représenter les tables d’une base de données relationnelle par un
schéma relationnel dans lequel les tables sont appelées relations et les liens
entre les clés étrangère et leur clé primaire est symbolisé par un connecteur
(figure 26).
Certains éditeurs inscrivent sur le connecteur un symbole 1 coté clé primaire et

un symbole ∞ coté clé étrangère (à condition que celle-ci ne soit pas déjà clé
primaire).
III.3. REGLES DE PASSAGE D’UN MCD EN UN MLDR
Pour traduire un MCD en un MLDR, il suffit d’appliquer cinq (5) règles.
Notations : on dit qu’une association binaire (entre deux entités) est de type :
- 1 : 1 (un à un) si aucune des deux cardinalités maximales n’est N ;

- 1 : N (un à plusieurs) si une des deux cardinalités maximales est N ;
- N : M (plusieurs à plusieurs) si les deux cardinalités maximales sont N.
En fait, un schéma relationnel ne peut faire la différence entre 0, N et 1, N. par

contre, il peut la faire entre 0, 1 et 1, 1 (règles 2 et 4).
Règle 1 : toute entité devient une table dans laquelle les attributs deviennent
les colonnes. L’identifiant de l’entité constitue alors la clé primaire.
Par exemple, l’entité articles de la figure 13 devient la table :
Articles (numéro_artcle, désignation, prix unitaire de vente).
Règle 2 : une association binaire de type 1 : N disparait au profit d’une clé

étrangère dans la table coté 0, 1 ou 1, 1 qui référence la clé primaire
de l’autre table. Cette clé étrangère ne peut pas recevoir la valeur vide
si la cardinalité est 1, 1.
Par exemple, l’association livrer de la figure 13 est traduite par :
Fournisseur (numéro_fournisseur, nom contact, no téléphone)

Livraisons (numéro_livraison, date de livraison, nom livreur,
#numéro_fournisseur (non vide)).
Il ne devrait pas y avoir d’attribut dans une association de type 1 : N, mais s’il
en reste, alors ils glissent vers la table coté 1.
Règle 3 : une association binaire de type N : M devient une table

supplémentaire (parfois appelée table de jonction, table de jointure
ou table d’association) dont la clé primaire est composée de deux clés
étrangères (qui référencent les deux clés primaires des deux tables en
association). Les attributs de l’association deviennent des colonnes de
cette nouvelle table.
Par exemple, l’association concerner (1) de la figure 13 est traduite par une
table supplémentaire ligne de commande :
Ligne de commande (#numéro_commande, #numéro_article, quantité

commandée)
Règle 4 : une association binaire de type 1 : 1 est traduite comme une

association binaire de type 1 : N sauf que la clé étrangère se voit
imposer une contrainte d’unicité en plus d’une éventuelle contrainte
de non vacuité (cette contrainte d’unicité impose à la colonne
correspondante de ne prendre que des valeurs distinctes).
Si les associations fantômes ont été éliminées, il devrait y avoir au moins un côté
de cardinalité 0, 1. C’est alors que dans la table du côté opposé que doit aller la
clé étrangère. Si les deux cotés sont de cardinalité 0, 1 alors la clé étrangère peut
être placée indifféremment dans l’une de deux tables.
Par exemple, l’association diriger de la figure 29 est traduite par :
Services (no_service, nom service, #numéro employé (non vide, unique))

Employés (no_employé, nom)
En réalité, la règle 4 proposée ici considère qu’une association binaire de type

1 : 1 correspond à une association binaire de type 1 : N particulière. Une
alternative consiste à voir une association binaire de type 1 : 1 comme une
association binaire de type N : M particulière. Il suffit pour cela d’ajouter une
contrainte d’unicité sur chacune des clés étrangères de la table d jonction
supplémentaire :
Services (no_service, nom service)

Direction (#no_service (unique), #numéro employé (unique))
Employés (no_employé, nom)
Mais rien ne garantit, dans cette traduction alternative (figure 30), qu’un service
possède un dirigeant, alors que c’est obligatoire. La première traduction (figure
29) est donc possible.
Remarque : d’autres techniques sont parfois proposées pour cette règle 4

(fusionner les tables, utiliser une clé primaire identique, utiliser deux clés
étrangères réflexives) mais elles ne sont pas exploitables dans le cas général.
Règle 5 : une association non binaire est traduite par une table supplémentaire
dont la clé primaire est composée d’autant de clés étrangères que
d’entités en association. Les attributs de l’association deviennent des
colonnes de cette nouvelle table.
Par exemple, l’association projeter devient une table :
Projections (#no_film, #no_salle, #no_crenau, tarif)

Exemple : Construction de Modèle Logique de Données

Elaboration de MLDR
Schémas relationnels associés au MLD valide

 T-INTRAN AGRICOLE (CodeIntr, Design, QteDispo, Categ, PU, #CodeCat)
 T-STOCKS (RefStoc, DateEnt, QteEntr, QteIni, #CodeIntr)
 T-CLIENTS (RefCli, NomCli, PrenomCli, TypeCli, AdressCli, TelCli)
 T-COMMANDE (NumComm, DateComm, QteComm, #RefCli, #CodeIntr)
 T-PAIEMENT (NumPaie, DatePaie, Montant, MotiifPaie, #RefCli)
 T-CATEGORIE (CodeCat, DesignCat)
 T-FOURNISSEUR (RefFour, NomFour, PrenomFour, AdressCli, TelCli, Email)
 TFOURNIR (#RefStoc, #RefFour, DateFour)

CHAPITRE IV. LE MODELE PHYSIQUE DES DONNEES (MPD)
Un modèle physique de données est l’implémentation particulière du modèle

logique de données par un logiciel.
IV.1. Distinction entre MLD et MPD

La traduction d’un MLD conduit à un MPD qui précise notamment le stockage
de chaque donnée à travers son type et sa taille (en octets ou en bits). Cette
traduction est également l’occasion d’un certain nombre de libertés prises par
rapport aux règles de normalisation afin d’optimiser les performances du
système d’information.
La traduction d’un MLD relationnel en un modèle en un modèle physique est la

création (par des requîtes SQL de type CREATE TABLE et ADD CONSTRAINT)
d’une base de données hébergée par un SBGD relationnel particulier. Il peut
s’agir d’une base Oracle, d’une base SQL Server, d’une base Access ou d’une
base DB2 ; PQR exemple. Le fait que tous les SGBDR reposent sur le même
modèle logique (le schéma relationnel) permet à la fois la communication entre
des hétérogènes et la conversion d’une base de données d’une SGBDR à l’autre.
IV.2. Optimisations
L’optimisation des performances en temps de calcul se fait toujours au
détriment de l’espace mémoire consomme. Dans le pire des cas, réduire les
temps de réponse consiste à de normaliser volontairement le système
d’information, avec tous les risques d’incohérence et les problèmes de gestion
que cela comporte.
Pour les c=blases de données relationnelles, l’optimisation qui vise à accélérer

les requetés peut passer par :
- L’ajout d’index aux table (au minimum sur les colonnes clés primaires et clés
étrangères); ces index consomment calculées au de d=certaine redondances
pour éviter des jointures couteuses (auquel cas la base est de normalisée) ; il
faut alors veiller à ce que la cohérence entre les colonnes soit respectée, soit
par l’utilisation de déclencheurs, soit dans l’application clients du système
d’information;
- Les suppressions contraintes d’unicité, de non vacuité ou encore de clé
étrangère (auquel cas l’intégrité des données doit être assure par le code client
du système d’information).
Par exemple, la table commandes de la figure 28 peut être supprimée et la date
de commande est alors ajoutée à la table ligne se commandes. On renonce donc
à la troisième forme normale (figure 32) puisque la date de commande est

répétée autant de fois qu’il y a de lignes dans la commande, mais on évite ainsi
une jointure couteuse en temps de calcul lors des requetés SQL.
Le conseil le plus précieux, en matière d’optimisation, est de ne jamais optimiser

a priori, mais toujours a posteriori, c’est-à-dire en réponse à une lenteur que le
SGBDR n’est pas capable de résoudre tout seul. Il faut alors mesurer le gain de
toute optimisation manuelle en effectuant des tests (chronométrages
avant/après) sur un volume de données significatif et de préférence en
exploitation.
Exemple du Modèle Physique des Données (MPD)

Bibliographie
1. System Analysis and Design, 5th Edition, DENNIS, WIXOM, ROTH.

2. MERISE/2, Guide Pratique (Nouvelle Edition), Jean- Luc BAPTISTE, ENI
Editions
3. Robert Reix (1934-2006), Systèmes d'information et management des
organisations, Éditions Vuibert, First edition in 1995, 367 pages.
4. La méthode MERISE, Principes et outils : H. TARDIEU, A. ROCHFELD, R.
COLLETTI. Les éditions d’organisation, 1979.
5. Ingénierie des systèmes d'information MERISE deuxième génération
(4eme édition), D.NANCI, B. ESPINASSE, éditions Vuibert. 2001
6. Conception des bases de données relationnelles : Concepts, méthodes et
cas corrigés. 2001J. AKOKA, I. Comyn-Wattiau
7. - H. TARDIEU, A. ROCHFELD, R. COLLETTI : La méthode Merise. Tome 1
principes et Outils. Les Editions d'organisation. 1983.
8. Y. TABOURIER : De l'autre côté de Merise. Les Editions d'organisation.
1986.
9. Y. TABOURIER : Du modèle entité/relation vers un véritable réseau
sémantique. MBD n°9 1988.
10. C. JAULT : Les bases de données relationnelles ou le libre accès aux
informations. Les Editions d'organisation. 1986
11. D. DURAND : La systémique. Collection Que sais-je ? PUF. 1979.
12. J. J. SEMPE, R. GOSCINNY : Le petit Nicolas. Denoël. 1960.
13. M. AYME : Les contes rouges du chat perché. Gallimard. 1963.
14. H. LABORIT : La colombe assassinée. Grasset. 1983.
15. C. PEROCHON : Comptabilité générale. Editions Foucher. 1981.
16. E.F. CODD : An evaluation scheme for database management systems
that are claimed to be relational. Computerworld. 1985.
17. H. TARDIEU, A. ROCHFELD, R. COLLETTI : La méthode Merise. Tome 2
démarche et pratiques. Les Editions d'organisation. 1985.

Notes de Cours de Mai I G2-Ig

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Notes de Cours de Mai I G2-Ig

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DEMOCRATIQUE DU CONGO

ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

INSTITUT SUPERIEUR DE COMMERCE

NOTES DU COURS DE METHODOLOGIE

Ass2.Ir.KUTUMBAKANA ATUHELUSA Philémon

ANNEE ACADEMIQUE 2021 - 2022

PARTIE I : NOTIONS GENERALES DE SYSTÈMES D’ENTREPRISE

CHAPITRE UN : PRESENTATION DU SYSTÈMES D’ENTREPRISE

Dans le monde des affaires, l'analyse et la conception de systèmes d’Information

L'analyse et la conception de systèmes d’Information ont trait à la mise en forme

Les organisations sont des systèmes complexes composés de sous-systèmes

Lorsqu'un ordinateur est utilisé dans une organisation, diverses fonctions et

L'analyse et la conception de systèmes d’Information sont axées sur les

I.2. Etude des Concepts

Une méthode définit un processus d’informatisation, possède un champ

- Utilité d’une Méthode

Une méthode est nécessaire :

Composants d’une méthode

- Modèles : ensemble de concepts et de règles destinés à expliquer et

I.3. Objectifs de la méthode

- Réduire la complexité des informations

I.4. Les cinq niveaux de maturité des processus de développement.

1. initial : le développement n'est pas formalisé, l'équipe réagit au jour le jour

5. optimisant : les données de contrôle des performances du processus

Les équipes de développement ont besoin d’une méthode de travail contrôlée,

- MERISE : Méthode d’Etude et de Réalisation Informatique pour les

1.2. VUE D'ENSEMBLE DE L'ANALYSE ET DE LA CONCEPTION DES SYSTÈMES

Qu'est-ce que l'analyse et la conception de systèmes ?

On peut généralement considérer que le développement de systèmes

- l'analyse des systèmes : L'analyse du système est donc le processus de

- la conception des systèmes : La conception de systèmes est le processus qui

C'est le travail de l'analyste des systèmes.

- Prenons, par exemple, le fonctionnement de la gestion de stock d'un magasin

Les coûts et les avantages sont également déterminants. En fin de compte,

L'analyse et la conception d'un système d’Information consistent donc à

1.3 Concepts de systèmes d'entreprise

Un système peut désigner tout ensemble de composants qui fonctionnent

Nous sommes arrivés en contact quotidien avec le système de transport, le

De même, nous parlons du système d'entreprise et de l'organisation comme

Il existe plus d'une centaine de définitions du mot "système", mais la plupart

Le composant peut être simple ou complexe, basique ou avancé. Il peut s'agir

N.B : L'étude des concepts de systèmes a donc trois implications fondamentales

1. Un système doit être conçu pour atteindre un objectif prédéterminé.

2. Des interrelations et une interdépendance doivent exister entre les

1.4 Caractéristiques d'un système

Notre définition d'un système suggère quelques caractéristiques qui sont

L'organisation implique une structure et un ordre. C'est l'agencement des

eux, ils fonctionnent comme un système complet pour produire des

L'interaction fait référence à la manière dont chaque composant fonctionne avec

L'interdépendance signifie que des parties de l'organisation ou du système

En résumé, aucun sous-système ne peut fonctionner isolément car il dépend données

La décision d'informatiser une application est initiée par l'utilisateur, analysée et

L'intégration fait référence à l'holisme des systèmes. La synthèse suit l'analyse

1.4.5 Objectif central

1.5 Éléments d'un système

Dans la plupart des cas, les analystes de systèmes travaillent dans un

1. Les entrées et les sorties.

2. Le(s) processus (traitements).

6. Frontières (limites) et interface.

1.5.1 Entrées et sorties

Par exemple, dans l'analyse des systèmes, la première préoccupation est

Le processus est l'élément d'un système qui implique la transformation réelle de

L'élément de contrôle guide le système. Il s'agit du sous-système de prise de