Ue Msi

DSGC
UE 215 MANAGEMENT DES

SYSTÈMES D’INFORMATION
Année 2016-2017
Ce fascicule comprend :
La présentation de l’UE
La série 1
Le devoir 1 à envoyer à la correction
DE LA DÉFINITION À LA CONCEPTION DES SYSTÈMES

D’INFORMATION
L’URBANISATION DU SI
En collaboration avec le
Rémy FÉVRIER
Dominique GATINAUT
Z2151-F1/4
Document de travail réservé aux élèves de l'INTEC. Toute reproduction sans autorisation écrite est interdite.
Pierre-Antoine AKE (2ifecbf@gmail.com)
Management des systèmes d’information • Série 1
Les auteurs
Rémy FÉVRIER : Maître de conférences au Cnam, responsable de l’UE 215.
Dominique GATINAUT : Expert en systèmes d’information, consultant, chargé d’ED réseau infor-
matiques au Cnam de Paris, enseignant à l’Intec et chargé de cours à l’université Paris-X.
� • • • www.cnamintec.fr • • • �
Document de travail réservé aux élèves de l’Intec – Toute reproduction sans autorisation est interdite
L’ensemble des contenus (textes, images, données, dessins, graphiques,

etc.) de ce fascicule est la propriété exclusive du Cnam-Intec.
En vertu de l’art. L. 122‑4 du Code de la propriété intellectuelle, la repro-
duction ou représentation intégrale ou partielle de ces contenus, sans au-
torisation expresse et préalable du Cnam-Intec, est illicite. Le Code de la
propriété intellectuelle n’autorise que « les copies ou reproductions stricte-
ment réservées à l’usage privé du copiste et non destinées à une utilisation
collective » (art. L. 122‑5).
2
UE 215 • Management des systèmes d’information
Table des matières
PRÉSENTATION DE L’UE 5
PLAN ANNUEL DU COURS 9
OBJECTIFS DE LA SÉRIE 1 11
Partie 1. DE LA DÉFINITION À LA CONCEPTION

DES SYSTÈMES D’INFORMATION 13
I. Qu’est-ce qu’un système d’information ?............................................13

A. Les notions........................................................................................13
B. Le processeur d’information..............................................................16
C. Les actions programmées et les décisions.......................................16
D. Les niveaux d’abstraction d’un SI.....................................................17
E. Le fichier et la base de données........................................................17
II. Les bases de données relationnelles...................................................22
A. La place du serveur SQL...................................................................22
B. Les principes directeurs de création d’une base de données...........24
III. De la conception à la modélisation d’un SI.........................................28

A. Les différentes approches.................................................................30
B. La méthode Merise............................................................................30
C. L’UML (Unified Modeling Language).................................................43
D. Exercices...........................................................................................64
IV. Le BPMN.................................................................................................67
A. La présentation de BPMN.................................................................67
B. Les connecteurs................................................................................68
C. Les cas d’utilisation...........................................................................69
D. Le récapitulatif des principaux symboles graphiques utilisés
dans BPMN.......................................................................................70
E. Les diagrammes BPMN.....................................................................71
F. Exercices...........................................................................................76
V. La place du SI.........................................................................................77
A. L’usage des technologies de l’information........................................77
B. La place des SI dans une organisation..............................................79
C. Comment les SI transforment-ils les entreprises ?...........................79
202151TDPA0116 3
D. L’émergence de l’entreprise numérique............................................80

E. Les objectifs stratégiques des SI......................................................81
F. Les raisons de l’existence des SI informatisés..................................81
G. Les limites de l’importance de la technologie de l’information.........82
H. Les SI dans la perspective managériale............................................82
I. Les dimensions des SI.......................................................................83
J. Les actifs complémentaires et le capital organisationnel..................83
K. Les nouvelles possibilités..................................................................84
VI. Corrigé des exercices de la partie 1.....................................................85
Partie 2. L’URBANISATION DU SI 95
I. L’informatique spaghetti........................................................................96
II. Pourquoi urbaniser ?.............................................................................97

A. Architecture à base de composants..................................................97
B. Urbanisation autour des processus d’entreprise..............................98
C. Normalisation des échanges.............................................................98
D. Architecture ouverte..........................................................................98
III. Le métamodèle et les concepts............................................................98
IV. La démarche d’urbanisation...............................................................100

A. Vocabulaire et processus................................................................100
B. Concepts et règles..........................................................................102
ANNEXES 105
BIBLIOGRAPHIE ET WEBOGRAPHIE 119
DEVOIR 1 121
4
Présentation de l’UE
I. PROGRAMME DE L’UE 215 :

MANAGEMENT DES SYSTÈMES D’INFORMATION EN DSGC
Le cours du DSGC de l’Intec est conforme au programme de l’UE 5 du DSCG, tel que défini dans
le bulletin officiel n° 14 du 3 avril 2014 et reproduit ci-après.
Pour des raisons historiques, l’ordre de présentation a été quelque peu modifié par rapport au
bulletin officiel. Cependant, bien sûr, toutes les notions sont intégralement présentées au travers
des quatre séries qui composent l’ensemble de ce cours.
Il s’agit d’un cours de niveau master. Le programme est de 140 heures et il correspond à
15 crédits ECTS.
Sens et portée de l’étude Notions et contenus

1. Gouvernance des systèmes d’information (30 heures)
Comprendre la nécessité d’associer au système
d’information de l’organisation des structures de prise
de décision.
1.1 Position de la fonction informatique au sein de l’organisation
Analyser les relations entre la direction générale, La direction des systèmes d’information : mission,
la direction des systèmes d’information et les directions organigramme, tableau de bord
« métiers ». La fonction informatique dans les petites organisations
1.2 La stratégie informatique
Connaître le contenu et la démarche d’élaboration Alignement de la stratégie informatique sur la stratégie
de la stratégie informatique. « métier »
Comprendre ses liens avec la stratégie globale et définir Schéma directeur informatique : définition, évolution,
la chaîne d’alignement stratégique. communication sur le schéma directeur
Plan informatique
Démarche de planification informatique
1.3 Urbanisation (évolution) des systèmes d’information
Prendre en compte la diversité des applications Cartographie du système d’information
informatiques dans l’organisation.
2. La gestion de projet des systèmes d’information (30 heures)
2.1 Les enjeux d’un projet
Analyser les conditions de lancement d’un projet. Place du projet dans la stratégie
Périmètre de son application
Organisation du projet
2.2 La mise en œuvre d’un projet
Connaître la démarche et les outils pour mettre en œuvre Cahier des charges
un projet. Cycle de vie d’un projet : prévision, planification,
ordonnancement
Plan d’assurance qualité : normes ISO sur la qualité du
logiciel ; méthode de conduite de projets ; méthode
d’amélioration des processus (CMMI)
Suivi et contrôle des coûts et des délais : analyse des
écarts (de planning, budgétaires)
Test : jeux d’essai, site pilote, test en situation réelle,
qualification, recette
Déploiement d’une solution et formation des utilisateurs
202151TDPA0116 5

2.3 Maintenance
Connaître les différents types de maintenance Maintenance corrective
et comprendre leur adaptation au projet. Maintenance évolutive
Contrat de maintenance
Tierce maintenance applicative
2.4 Gestion des risques du projet
Identifier les conditions qui peuvent conduire à l’échec Analyse et gestion des risques
et les mesures préventives et correctives utilisables. Intégration des risques dans les contrats
2.5 Les meilleures pratiques – Les facteurs clés de succès
Découvrir l’importance d’une capitalisation des savoirs et Gestion des connaissances
savoir-faire au sein de l’organisation. Outils collaboratifs
3. Les progiciels de gestion intégrés (25 heures)
3.1 La place des progiciels de gestion intégrés (PGI)
Comprendre la segmentation du marché des PGI Le progiciel de gestion intégré :
en fonction des besoins des clients. définition
Analyser les fonctionnalités des logiciels. diffusion dans les entreprises et les administrations
couverture fonctionnelle
évolutions technologiques
3.2 Le cycle de vie d’un progiciel de gestion intégré
Illustrer les concepts de la gestion de projet. Expression des besoins
Choix de la solution
Mise en place et déploiement de la solution
Exploitation de la solution
Évaluation des systèmes de gestion intégrés
4. Gestion de la performance informatique (25 heures)
4.1 Définition d’indicateurs
Indicateurs de performances
Indicateurs de qualité
4.2 Le contrat de service
Rechercher les niveaux de service à atteindre. Objectifs et contraintes du contrat de service
Repérer les enjeux des contrats en fonction du contexte Élaboration du contrat
organisationnel (infogérance, prestataire, facturation en Mise en œuvre du contrat
interne).
Négocier avec les parties prenantes.
4.3 Les coûts
Appliquer les concepts de la comptabilité de gestion Analyse des coûts
aux spécificités de la fonction informatique. Budget de fonctionnement de la fonction informatique
4.4 Les budgets
Agréger les dépenses informatiques décentralisées. Budget de la fonction informatique
Comprendre l’intérêt de la facturation pour responsabiliser Facturation en interne de l’utilisation des ressources
les utilisateurs. informatiques
4.5 Évaluation des projets informatiques
Établir des critères de choix des investissements dans Évaluation des coûts/avantages des projets
le domaine informatique. informatiques
Critères de sélection des projets
5. Architecture et sécurité des systèmes informatiques (15 heures)
5.1 Architecture technique
Être capable d’identifier les principales architectures Client-serveur
techniques. Médiateur (middleware)
Transactionnel
Intégration
Portail
5.2 Mise en place d’une architecture de confiance
Comprendre le fonctionnement d’une infrastructure à clé Infrastructure à clé publique
publique. Certificat numérique
Signature électronique
6

5.3 Surveillance et prévention
Prendre les dispositions pour garantir la continuité Surveillance des processus
de l’activité. Protection juridique
Assurances et garanties (légales et contractuelles)
6. L’audit et la gouvernance (15 heures)
6.1 Audit du système d’information
Comprendre le sens d’une mission d’audit de la fonction Audit interne, audit externe et audit stratégique de la
informatique. fonction informatique
6.2 Gouvernance d’entreprise et environnement spécifique pour l’auditeur
Appréhender les enjeux de l’audit dans une organisation Contrôle des comptes des entités informatisées
informatisée. Risques d’audit
Prendre connaissance des obligations légales et des Normes professionnelles nationales et internationales
normes professionnelles. Obligations légales et réglementaires
6.3 L’audit assisté par ordinateur
Identifier les ressources informatiques nécessaires pour Les étapes de l’audit assisté par ordinateur
réaliser une mission d’audit. Les progiciels d’aide à la révision
INDICATIONS COMPLÉMENTAIRES
2.1 Dans la partie stratégique, il est important de distinguer la maîtrise d’ouvrage et la maîtrise d’œuvre et d’étudier
l’opportunité de faire ou de faire-faire. La partie organisationnelle doit aborder les points suivants : contrat régie et
forfait ; relation client-fournisseur en interne ; relations contractuelles avec les fournisseurs et les prestataires ;
l’animation des équipes.
4.3 L’analyse des coûts fera référence aux éléments suivants : centre d’analyse, unité d’œuvre, inducteur de coûts ;
coût de fonctionnement, coût de développement, coût de possession (TCO, Total Cost of Ownership). On étudiera les
enjeux et les modalités de la réduction des coûts de l’informatique : externalisation de certaines fonctions,
infogérance, recours à des progiciels, licences libres, délocalisations.
II. DÉROULEMENT DU TRAVAIL EN COURS À DISTANCE

L’ordre de présentation du cours dans les quatre séries a été quelque peu modifié par rapport à
celui du bulletin officiel n° 14 du 3 avril 2014.
Outre les quatre séries, vous trouverez également, en fin de chaque série, un devoir à envoyer
à la correction. Ces devoirs vous entraînent au sujet d’examen. Un 5e devoir sera mis en
ligne en milieu d’année universitaire selon le planning précisé dans le guide de l’élève sur le site
www.cnamintec.fr.
Il est particulièrement important de faire ces devoirs. Leur apport formateur n’est plus à prouver.
Outre une possibilité de bonification à l’examen, vous bénéficiez de la richesse des commen-
taires fournis par le correcteur, vous permettant ainsi de progresser et de corriger vos éven-
tuelles erreurs.
Conçu pour se suffire à lui-même, ce cours vous permet d’aborder l’ensemble des connais-
sances nécessaires à une bonne maîtrise des concepts généraux mais également leur applica-
tion à des cas réels. L’ensemble des connaissances y figurant est donc suffisant pour, le jour de
l’examen, résoudre sans difficulté particulière le sujet présenté. Mais, il s’agit là d’une approche
quelque peu théorique malgré tout. Le jour de l’examen, vous aurez à faire preuve d’un minimum
de capacités d’analyse, de réflexion et de synthèse. Seul un travail régulier peut vous y conduire.
Une réelle implication ainsi qu’un travail personnel sont donc attendus.
Les annales des années précédentes sont riches d’enseignement et disponibles sur le site
Internet de l’Intec : www.cnamintec.fr. Nous vous conseillons fortement de vous y reporter.
Enfin, au-delà de l’objectif de l’examen, il se peut que certaines et certains souhaitent accroître
leur champ de connaissance sur tel ou tel sujet ou dans le cadre général de la profession
d’expert-comptable. À ce titre, vous trouverez en fin de série une bibliographie accompagnée
d’une webographie vous permettant d’enrichir vos connaissances.
202151TDPA0116 7
III. DÉROULEMENT DE L’ÉPREUVE DU DSGC

Le bulletin officiel stipule à ce sujet : « Il s’agit d’une épreuve écrite, portant sur l’étude d’un cas
ou de situations pratiques pouvant être accompagnées de commentaire d’un ou plusieurs docu-
ments et/ou d’une ou plusieurs questions. » Sa durée est de trois heures et le coefficient est de 1.
La candidate ou le candidat devra faire preuve d’un minimum d’esprit d’analyse, de réflexion et
de synthèse. Aussi, sera évaluée la capacité à rédiger. La qualité de la copie, dans son contenu
et dans son style rédactionnel, sera un élément occupant une place importante lors de l’évalua-
tion du travail fourni.
Afin de pouvoir réussir cette épreuve, il est indispensable de posséder comme prérequis l’inté-
gralité du programme de l’UE 118 « Systèmes d’information de gestion » (UE 8 de l’État).
A. LE JOUR DE L’ÉPREUVE
Le jour de l’épreuve, accordez-vous, avant de commencer à rédiger, le temps nécessaire pour une
lecture précise de l’intégralité du sujet proposé. Prévoyez à cet effet environ quinze minutes. Il ne s’agit
en rien de temps perdu car vous pourrez vous imprégner de l’esprit du sujet proposé. Vous aurez ainsi
une idée sur les questions dont vous maîtrisez le thème et celles qui risquent de vous demander plus
de réflexion. Enfin, vous aurez également une vue exacte sur le nombre de points accordé à chaque
question. Il sera de votre intérêt de commencer à traiter les questions dont vous maîtrisez le mieux les
thèmes afin de consacrer le reste de votre temps à celles qui vous demande plus de réflexion. Mieux
vaut rendre une copie dans laquelle vous aurez traité cinq questions à deux points chacune que
d’avoir passé votre temps à traiter à moitié une question à dix points, si cela existe.
Les questions étant généralement indépendantes les unes des autres, à partir du moment où
vous les repérez correctement dans votre copie, rien ne vous oblige à les traiter dans l’ordre
selon lequel elles vous sont posées.
N’allez pas remplir des pages et des pages de réponses hors sujets. Il est inutile de retranscrire le
cours si cela n’apporte rien à la question posée. La quantité d’écrits n’est pas déterminante dans
l’obtention d’une note élevée. Seule la qualité et la justesse de vos réponses seront considérées.
Apportez autant que possible le maximum de soin à votre copie. Évitez les écritures « pattes de
mouche », souvent illisibles. En cas d’erreur, pensez à rayer à l’aide d’une règle la ou les parties
que vous souhaitez ne pas voir prise en compte. Évitez les ratures parfois ambigües. Attention
aux fautes d’orthographe. Rendez un travail soigné, structuré, propre, facile et agréable à corriger.
B. COMMENT SE PRÉPARER ?
Il n’y a ni secret ni miracle. Seul un travail régulier, tout au long de l’année, peut vous conduire à
la réussite. Vous mettre à travailler quelques semaines avant la date de l’épreuve ne donnera
jamais le résultat escompté mais vous conduira inévitablement à une grande déception.
La lecture et l’assimilation des concepts présentés dans les séries constituent une étape initiale
et incontournable avant toute tentative de résolution d’exercices. Ne négligez pas ces lectures.
Au contraire, si un concept vous semble un peu flou, si vous désirez approfondir un sujet ou
aborder un thème sous un autre angle que celui exposé dans la série, n’hésitez pas à consulter
d’autres ouvrages ou des sites Web de qualité. À ce sujet, attention, gardez votre sens critique.
Croisez plusieurs sources afin de ne pas faire vôtre tout ce que vous pouvez lire ci et là.
N’hésitez surtout pas à vous connecter sur le site Internet de l’Intec www.cnamintec.fr. Dans la
rubrique « Ressources pédagogiques complémentaires », vous trouverez bon nombre de res-
sources pédagogiques telles que des exercices corrigés.
La maîtrise des concepts abordés dans ce cours nécessite de prendre un certain recul. Dans cet
effet, il est important dès à présent de commencer un travail de synthèse pour chacun de vos
cours. Le mieux, pour cela, est de mettre par écrit les notions principales. Ce travail constituera
vos fiches de synthèse. Elles vous seront d’une aide précieuse en période de révision. Elles
seront plus opérationnelles, plus efficaces que des fiches acquises par ailleurs. Non seulement
leur structure vous correspondra mais, de plus, en les relisant, des connaissances, des souve-
nirs, vous reviendront en mémoire.
8
Plan annuel du cours
SÉRIE 1
PARTIE 1. DE LA DÉFINITION À LA CONCEPTION DES SYSTÈMES

D’INFORMATION
I. Qu’est-ce qu’un système d’information ?
II. Les bases de données relationnelles
III. De la conception à la modélisation d’un SI
IV. Le BPMN
V. La place du SI
VI. Corrigé des exercices de la partie 1
PARTIE 2. L’URBANISATION DU SI
I. L’informatique spaghetti
II. Pourquoi urbaniser ?
III. Le métamodèle et les concepts
IV. La démarche d’urbanisation
SÉRIE 2
PARTIE 3. LE SYSTÈME D’INFORMATION ET SON DÉCOUPAGE EN DOMAINES

FONCTIONNELS ET PROCESSUS TRANSVERSAUX
I. Identifier et structurer les informations de gestion
II. Les domaines fonctionnels courants
III. La réorientation vers les processus transversaux
PARTIE 4. LES LOGICIELS MÉTIERS POUR LES GESTIONNAIRES

(COMPTABILITÉ, CONTRÔLE, AUDIT, CONSEIL)
I. L’informatique structurelle
II. Les logiciels et les progiciels
III. Les logiciels de comptabilité
IV. Du logiciel de comptabilité au progiciel de gestion
V. Les critères de choix d’un progiciel comptable
VI. Les progiciels de gestion intégrée
202151TDPA0116 9
SÉRIE 3
PARTIE 5. LA GESTION DE PROJETS SYSTÈMES D’INFORMATION

ET LA MESURE DE LA PERFORMANCE INFORMATIQUE
I. Rappel sur la théorie des graphes
II. Les outils informatiques pour gérer les projets (et construire les graphes)
III. Les acteurs des projets, les rôles et prérogatives
IV. Le cycle de vie d’un projet
V. De la gestion d’un projet à la gestion des projets
VI. La gouvernance et la mesure de la performance informatique
VII. Les coûts de développement, de production et de maintenance
VIII. L’économie d’un projet « système d’information »
IX. Étude de cas : la banque G2N
SÉRIE 4
PARTIE 6. LES INFRASTRUCTURES TECHNOLOGIQUES DE L’INFORMATION

I. Architectures informatiques
II. Technologies de base et des architectures de machines
III. Architecture de systèmes
IV. Architecture de réseaux
V. Évolution des architectures de données
VI. Évolution des architectures de traitement
VII. Évolution des architectures globales
VIII. Architectures techniques d’aujourd’hui
PARTIE 7. LA SÉCURITÉ DES SYSTÈMES D’INFORMATION

I. La protection des actifs
II. L’évaluation des risques
III. L’identification des menaces
IV. La mise en place d’une politique SSI (PSSI)
V. Sécurité opérationnelle
VI. Informatique et libertés
PARTIE 8. LES NORMES ET LES RÉFÉRENTIELS DES AUDITS DES SYSTÈMES

D’INFORMATION
I. Définitions et vocabulaire
II. Les contextes internationaux et les enjeux
III. Les sources des normes et référentiels
IV. Le contrôle fiscal des comptabilités informatisées
10
Objectifs de la série 1
Cette première série a pour objectifs de :

• définir les fondamentaux indispensables à la bonne compréhension du cours ;
• présenter les deux principales méthodes de modélisation, Merise et UML, utili-
sables dans la conception d’un système d’information ;
• présenter une méthode de modélisation de processus, BPMN, nécessaire dans la
communication entre entités impliquées ;
• présenter la place du SI dans une organisation ;
• présenter l’urbanisation d’un système d’information, méthode pour l’évolution
d’un système d’information.
La série 1 est la plus abstraite et la plus technique des quatre séries composant ce
cours.
Les annexes contiennent des informations pertinentes mais qui n’ont pas à être
abordées lors d’une première lecture. Cependant, nous vous conseillons d’y porter
toute votre attention une fois maîtrisé le contenu de cette série.
Par ailleurs, à plusieurs reprises vous trouverez des exercices en fin de partie. Les
corrigés des exercices se trouvent en fin de partie. Nous vous conseillons égale-
ment de chercher à résoudre chacun d’eux sans consulter avant la solution. Ne

vous inquiétez pas de vos échecs, ils sont formateurs.
Cette série, comme les trois autres, ne doit pas être lue de façon linéaire. Il ne s’agit
pas de lire un roman, c’est-à-dire de commencer à la première ligne pour terminer
à la dernière. Cette série, comme d’ailleurs tout document de ce type, doit tout
d’abord être parcourue en diagonale, juste pour en percevoir sa structure et les
grands thèmes abordés. Ce travail initial fait, la série doit être lue de nouveau mais
avec plus d’attention. Le recours à des marqueurs de couleurs peut s’avérer être
un bon moyen pour identifier les différentes parties : définitions, points importants,
points secondaires… À ce stade, il n’est pas inutile de compléter votre lecture par
d’autres sources si vous souhaitez approfondir un sujet. Un second éclairage peut
s’avérer parfois efficace pour une meilleure compréhension d’un sujet.
Votre investissement ne peut s’avérer que fructueux. Bon courage.
202151TDPA0116 11
1
PARTIE
De la définition à la conception
des systèmes d’information
Vous trouverez ci-après les principaux sigles utilisés dans cette série :
BPMN Business Process Model and Notation

CIM Contrainte d’intégrité multiple
DF Dépendance fonctionnelle
HTTP HyperText Transfer Protocol
MCC Modèle conceptuel de communication
MCD Modèle de conception de données
MDF Matrice des dépendances fonctionnelles
MLD Modèle logique des données
MOA Maîtrise d’ouvrage
MOD Modèle organisationnel des données
MOE Maîtrise d’œuvre
SGBD Système de gestion de base de données
SGBDR Système de gestion de base de données relationnelle
SI Système d’information
SQL Structured Query Language
UML Unified Modeling Language
URL Uniform Resource Locator
I. QU’EST-CE QU’UN SYSTÈME D’INFORMATION ?

Avant d’aborder la question « Qu’est-ce qu’un système d’information ? », commençons par défi-
nir ces deux notions : système et information.
A. LES NOTIONS
Le dictionnaire Larousse en ligne1 nous donne, pour chacun des deux termes, plusieurs définitions.
1. Système
Nous retiendrons deux définitions du terme système :
• « ensemble d’éléments considérés dans leurs relations à l’intérieur d’un tout fonctionnant de
manière unitaire » ;
• « ensemble de procédés, de pratiques organisées, destinés à assurer une fonction définie ».
Plusieurs notions essentielles s’en dégagent. La première définition met en exergue le fait que si
un système est composé de divers éléments, aucun n’est considéré individuellement pour
autant. Au contraire, ils sont « considérés dans leurs relations à l’intérieur d’un tout ». La seconde
définition précise que l’on trouve également dans un système « des procédés, des pratiques
organisées, destinées à assurer une fonction définie ».
1. http://www.larousse.fr.
202151TDPA0116 13
Il en résulte donc qu’un système est constitué d’un ensemble d’éléments matériels et non maté-
riels (méthodes, règles, etc.) directement ou non en interactions les uns avec les autres transfor-
mant par un ou plusieurs processus des éléments fournis par ses entrées en d’autres éléments
restitués par ses sorties. Ce système est dit « système de puissance ou système opérant ». Par
exemple, un radiateur électrique reçoit en entrée un courant électrique qu’il transforme en cha-
leur et qu’il restitue en sortie par sa surface de contact avec l’air ambiant.
Il se peut qu’un système soit lui-même contrôlé par un second système appelé système de
commande ou de pilotage. Comme son nom l’indique, il pilote le système opérant en agissant
sur le comportement de celui-ci en fonction des objectifs fixés. Par exemple, on obtiendra plus
ou moins de chaleur en agissant sur le thermostat du radiateur électrique. Nous avons donc
deux systèmes qui coopèrent ensemble : un système de gestion ou de pilotage et un système
de puissance ou opérant qui ensemble forment un tout. L’ensemble peut se schématiser ainsi :
Figure 1 – Système opérant et son système de pilotage2
Système de pilotage Objectifs
Entrées Système opérant Sorties
2. Information
Pour « information », consultons de nouveau le dictionnaire Larousse en ligne et retenons deux
définitions parmi celle proposées :
• « indication, renseignement, précision que l’on donne ou que l’on obtient sur quelqu’un ou
quelque chose » ;
• « élément de connaissance susceptible d’être représenté à l’aide de conventions pour être
conservé, traité ou communiqué ».
De nouveau, des notions essentielles en ressortent. La première définition met en exergue que
les informations sont obtenues mais également fournies. Et, celles-ci sont relatives à « quelqu’un
ou quelque chose ». Une information est donc liée à un contexte défini. La seconde définition
précise que ces informations sont susceptibles d’être : « représentées à l’aide de conventions
pour être conservées, traitées ou communiquées ». Si cette précision ne fait référence à aucune
technologie en particulier, on recourt essentiellement aujourd’hui, pour ne pas dire exclusive-
ment, à l’informatique.
Avant de définir un système d’information, précisons la différence entre une donnée et une infor-
mation. Pris isolément, les données « 28 », « Paris » et « 2016 » n’ont aucune signification parti-
culière. Il s’agit simplement de données. C’est en plaçant celles-ci dans un contexte qu’elles
prennent un sens et deviennent une information. Pour résumé, nous pouvons dire que l’on peut
percevoir des données mais que l’on interprète des informations. La donnée devient donc une
information dès lors qu’elle est transmise à une entité, humaine ou non, en mesure de l’interpré-
ter. Une même donnée peut donc avoir plusieurs interprétations et donc correspondre à diverses
informations, en fonction de son interprétation. Par exemple, la donnée 28 peut, selon le contexte,
être interprétée comme l’âge d’une personne ou l’effectif d’une association. La valeur 28 ne
constitue donc pas en elle-même la moindre information. Seule l’interprétation de cette donnée
en fait une information.
3. Système d’information
Muni de ces éléments d’informations, nous pouvons à présent proposer notre définition d’un
système d’information.
2. Les figures sont librement inspirées de l’ouvrage Comprendre Merise – Outils conceptuels et organisa-
tionnels, Jean-Patrick Matheron, éditions Eyrolles, 1994.
14
Définition
Un système d’information est un ensemble de ressources matérielles, logicielles et humaines.
Les ressources matérielles sont de nos jours principalement, voire exclusivement, de nature
informatique (serveurs, réseaux, logiciels, etc.) interconnectées selon différentes architectures,
en relation directement ou non l’une avec l’autre, formant un tout, pouvant recevoir, stocker,
traiter et restituer des données qui seront interprétées comme des informations par les utilisa-
teurs.
Attention à ne pas confondre « système d’information » avec « système informatique ». Il serait
faux d’assimiler l’un à l’autre, malgré l’omniprésence de l’informatique dans les systèmes d’in-
formation. Ce n’est en rien l’infrastructure informatique qui fait un système d’information. Ce qui
le constitue ce sont les interconnexions entre les éléments informatiques, les flux de données,
ces données elles-mêmes, leur traitement, leur stockage et leur restitution qui, une fois interpré-
tées, fournissent de l’information.
Dans la suite de cette série, ainsi que dans les trois autres, chaque fois que l’abréviation « SI »
sera utilisée elle fera référence à un « système d’information » et en aucun cas à un « système
informatique ».
Le périmètre d’un SI n’est pas obligatoirement circonscris géographiquement uniquement au
sein de l’organisation détentrice. Il peut sans aucun problème sortir du cadre géographique et
s’étendre sur plusieurs continents si besoin est mais tout en restant clos comme, par exemple,
avec un intranet.
Toute organisation (un tant soit peu évoluée et structurée) doit obligatoirement, de nos jours, se
doter d’un SI venant s’interfacer entre le système de pilotage et le système opérant. L’ensemble
peut se schématiser ainsi :
Figure 2 – Place d’un SI dans l’ensemble
Système de pilotage Objectifs
Informations de décisions
Informations sur le système opérant
Système d’information
Informations d’interaction
Liaisons de couplage
Entrées Système opérant Sorties
Le SI, chargé de stocker, traiter et restituer des informations relatives au système opérant
comme, par exemple, les variations des ventes, les investissements, etc., met ces informations
à disposition du système de pilotage. Par ailleurs, le SI peut également recevoir des commandes
en provenance des décisions, en vue de son propre pilotage. Enfin, il peut également émettre à
destination du système opérant des informations d’interaction. Par exemple, le système opérant
pourra accepter la réservation d’une place de spectacle que si le SI lui confirme que les réserva-
tions sont ouvertes et qu’il reste des places disponibles.
Un SI constitue la mémoire d’une organisation. À ce titre, il comporte deux aspects : un statique
et un dynamique.
• L’aspect statique concerne la sauvegarde des événements survenus ainsi que la mémorisa-
tion des structures de données, des règles et des contraintes.
• L’aspect dynamique concerne la réactualisation des données sauvegardées dans la base
d’information et, pour les systèmes adaptables, de modifier les structures, les règles et les
contraintes du modèle de données suite à des changements dans l’organisation ou dans les
objectifs. On appelle cette partie dynamique le processeur d’information, c’est-à-dire, la
partie qui traite les informations.
202151TDPA0116 15
B. LE PROCESSEUR D’INFORMATION
Chaque événement survenant peut être assimilé par le processeur d’information comme un
message contenant des informations. En se basant sur les règles présentes dans le modèle, le
processeur d’information va interpréter ce message et procéder à d’éventuels ajustements de
la base d’information et/ou du modèle lui-même, si besoin est. Il retournera également un nou-
veau message faisant état des modifications apportées. Le processeur d’information, constitué
d’hommes et de machines, se schématise ainsi :
Figure 3 – Processeur d’information

Événements
Modèle
Processeur
d’information Base d’information
Retour d’information
sur la base d’information
et/ou le modèle
C. LES ACTIONS PROGRAMMÉES ET LES DÉCISIONS

Dans un SI, on trouve des actions dites « programmées ». Il s’agit d’informations qui déter-
minent de façon unique les sorties du système à partir de ses entrées. Aucune décision n’est à
prendre. Par exemple, le nombre d’inscrits à une formation détermine de façon unique l’effectif
de celle-ci. Autrement dit, la sortie constituée par l’effectif est déterminée de façon unique par la
connaissance du nombre d’inscrits qui constitue l’entrée. Dans cette situation, on dit que le
système est déterminé. On peut écrire l’égalité : S = f(E).
Figure 4 – Actions programmées

Entrée (E) Sortie (S)
Système sans décision
E = f(S)
Cependant, dans un système, la connaissance d’informations en entrée peut ne pas permettre
pour autant de déterminer de façon unique une sortie. On est alors en situation d’information
incomplète. Dans un tel cas, une même situation en entrée peut conduire à plusieurs sorties
différentes S1, S2, …, Sn. Le choix de la situation sera fonction de la décision qui sera prise. Par
exemple, le nombre d’inscrits à une formation ne permet pas pour autant d’être certain que tous
les inscrits se sont acquittés des frais d’inscription et que le volume d’argent théorique est dis-
ponible pour financer un achat de matériel pédagogique. Il va falloir prendre une décision. Lors
de la prise de décision, des éléments non formalisables, tels que l’expérience professionnelle,
les habitudes, l’intuition, etc., peuvent intervenir et influencer le choix et donc la sortie.
Figure 5 – Information incomplète nécessitant une décision

Sortie 1
Entrée (E) Sortie 2

Système avec décision
Sortie N
Décision
16
Les deux types de situations ne sont pas exclusives l’une de l’autre. Au sein d’un SI, un proces-
sus qui transforme des entrées en sorties peut comporter simultanément des actions program-
mées et des informations incomplètes nécessitant de faire des choix.
D. LES NIVEAUX D’ABSTRACTION D’UN SI

Trois niveaux d’études sont à aborder lors de la conception d’un SI :
• le niveau conceptuel ;
• le niveau organisationnel ;
• le niveau opérationnel.
Le niveau conceptuel permet d’envisager le SI sans devoir prendre en considération la moindre
organisation, tant pour les données que pour les traitements. Seules les données disponibles
sont à considérer mais ni leur structure ni leur organisation. À ce stade, deux questions doivent
être posées : Quoi faire ? et Avec quelles données ?
Le niveau organisationnel permet d’insérer dans l’analyse des critères liés à l’organisation
donc des notions de lieux, de temps, d’acteurs, de poste de travail, etc. On se pose ici les ques-
tions Qui ?, Où ?, Quand ? Par ailleurs, on réfléchit également à la répartition des tâches entre
l’homme et la machine.
Le niveau opérationnel permet d’apporter des réponses techniques aux problèmes afin de
finaliser l’étude et permettre la mise en œuvre effective du SI.
E. LE FICHIER ET LA BASE DE DONNÉES

Toute l’activité d’une organisation, quelle que soit sa nature, s’appuie donc sur des données,
diverses et variées, qui sont stockées, traitées, manipulées, transformées, restituées quotidien-
nement pour fournir les informations nécessaires au bon fonctionnement de cette organisation.
Il est donc légitime de se poser quelques questions. Où sont stockées ces données ? Sont-elles
stockées dans des fichiers ? Par quoi et comment sont-elles traitées, manipulées et restituées ?
Non, les données ne sont pas stockées dans un fichier. Pourquoi ? Un fichier est une collection
d’informations numériques, binaires, au sein d’une même structure, enregistrée sur un support
tel qu’un disque dur, une clé USB, etc. Si les données sont des caractères, les informations
binaires sont regroupées en octets.
L’essence même d’un fichier réside dans les informations contenues. Mais, dans un fichier, celles-
ci ne sont pas structurées. Ainsi, par exemple, à la lecture de « Alain Pierre », il est impossible de
savoir si Alain est le prénom et Pierre le nom ou l’inverse. De plus, le format d’un fichier est sou-
vent propriétaire. Cela nécessite donc d’utiliser quasiment une application par type de fichier pour
accéder à son contenu. Par exemple, il est impossible d’ouvrir un fichier PDF avec une applica-
tion non dédiée à cet effet. Nous reviendrons ultérieurement sur la problématique des fichiers.
Si les données ne sont pas enregistrées dans un fichier, dans quoi le sont-elles ? La réponse est
simple. Les données sont stockées dans une base de données. Elles sont traitées, manipulées et
restituées par un système de gestion de base de données, généralement désignés par « SGBD ».
Ce concept de base de données a connu plusieurs évolutions au fil du temps. Si, de nos jours,
le modèle relationnel s’est imposé de façon hégémonique, deux autres principaux modèles ont
vu le jour précédemment : le modèle dit « réseau » et le modèle dit « hiérarchique ».
1. Base de données de type réseau

Elle a été proposée en 1971 par le groupe DBTG d’un comité appelé CODASYL3. Une améliora-
tion a été apportée en 1978. Les données modélisées dans ce type de base de données le sont
à l’aide de trois concepts : atome, groupe et article.
3. Conference on Data Systems Languages, soit en français « Conférence sur les langages de systèmes
de traitement de données ».
202151TDPA0116 17
Un atome est assimilable au champ d’un article de fichier. Il est typé, ce qui définit ses valeurs pos-
sibles ainsi que les opérations qui lui sont applicables. Un atome est instancié par une unique valeur
dans la base de données. Par exemple, « Prénom », « Nom », « Civilité » pourraient être des atomes
dans une base de données de clients. Il est possible de grouper consécutivement ensemble plu-
sieurs atomes. Cela constitue un groupe de données. Atomes et groupes constituent des articles.
2. Base de données de type hiérarchique

Les bases de données étant destinées à « modéliser » les informations du monde réel et celui-ci
nous apparaissant le plus souvent au travers de hiérarchie, il est naturel qu’un modèle de type
hiérarchique ait vu le jour. Ce modèle peut être vu comme un cas particulier du modèle précédent.
Les données sont modélisées à l’aide de champs, segments, clés et arbres de segments. Un
champ est équivalent à un atome du modèle hiérarchique. Les segments sont assimilables aux
groupes du modèle réseau mais sur lesquels des restrictions sont appliquées. Un segment est à
même de comporter un champ discriminant appelé clef. Une valeur de celle-ci permet d’identi-
fier une occurrence unique dans un segment. Les segments sont reliés entre eux par des liens
de 1 vers N. Pour résumer, une base de données hiérarchique peut être illustrée par un ensemble
d’arbres dont chacun des nœuds est un segment.
3. Base de données de type relationnel

Le modèle relationnel gère un objet central : la relation. Une relation est un ensemble d’élé-
ments, appelés attributs, qui caractérisent une entité. Exemple : l’entité « élève » peut contenir
les attributs « prénom, nom, civilité, année_études » qui la caractérisent.
Des règles s’appliquent à une relation afin de respecter des contraintes liées à l’analyse. Citons,
à titre d’exemple, quelques-unes de ces règles :
• cohérence : un attribut ne peut avoir qu’une valeur appartenant au domaine sur lequel il est
défini ;
• unicité : au sein d’une relation, il ne peut pas y avoir deux éléments identiques ;
• identifiant : c’est un attribut ou un ensemble d’attributs permettant de caractériser de
façon unique chacun des éléments de la relation ;
• clé primaire : elle est constituée de l’identifiant minimum d’une relation ;
• clés secondaires : elles sont constituées des autres identifiants de la relation ;
• intégrité référentielle : il s’agit d’une règle imposant qu’un attribut, ou un groupe d’attri-
buts, d’une relation figure en tant que clé primaire dans une autre relation ;
• clé étrangère : un attribut, ou un ensemble d’attributs, qui vérifie la règle d’intégrité réfé-
rentielle ;
• valeur nulle : la notion de nullité est admise dans le modèle relationnel. Il s’agit d’une valeur
qui représente une information inconnue ou inapplicable dans une colonne d’une table. Elle est
représentée par une valeur particulière : NULL ;
• contrainte d’intégrité : aucune valeur participant à une clé primaire ne peut avoir cette valeur
NULL.
Dans ce modèle, le concept sous-jacent est donc la relation issue de la théorie des ensembles.
Plus rigoureusement, une relation est un sous-ensemble du produit cartésien entre domaines.
Un domaine correspond à un ensemble fini ou non de valeurs possible. Par exemple, nous
pouvons citer le domaine des nombres entiers, celui des noms des membres d’une association,
celui des pays membres de la CEE…
Rappelons que le produit cartésien d’ensembles D1, D2, …, Dn, noté de façon multiplicative D1 ×
D2 × … × Dn constitue l’ensemble des n-uplets (ou tuples) {V1, V2, … Vn} avec Vi ∈ Di. Par
exemple, le produit cartésien des deux domaines D1 et D2, définis respectivement par D1 = {Alain,
Louis, Bernard} et D2 = {Patricia, Clarisse} est, si on le représente sous la forme d’une table :
Alain Patricia
Alain Clarisse
Louis Patricia
Louis Clarisse
Bernard Patricia
Bernard Clarisse
18
Dans ce modèle, les données sont structurées sous forme de tables. Il s’agit d’un modèle facile
à comprendre. Reposant sur l’algèbre relationnel4, ses fondements profitent donc d’une approche
mathématique ce qui lui confère de facto une très grande rigueur.
Une table relationnelle est parfois appelée simplement table ou relation. Un nom lui est affecté,
permettant ainsi une identification sans ambiguïté. Par ailleurs, afin de ne pas être contraint par
l’ordre des colonnes dans une table ou devoir se restreindre uniquement à des tables mono-
colonnes, chaque colonne est affectée d’un nom permettant également une identification aisée.
Bien sûr, cela interdit de facto qu’au sein d’une même table deux colonnes portent le même
nom.
Chaque colonne d’une table constitue un attribut de la relation représentée par la table.
En mathématique, il est possible de définir un ensemble de deux façons différentes : en inten-
sion ou en extension. Dans le premier cas, on exprime une propriété que doit vérifier chaque
élément de l’ensemble comme, par exemple, « L’ensemble des nombres paires » alors que le
second cas consiste à exprimer exhaustivement la totalité des éléments appartenant à l’en-
semble. Lorsque l’on travaille avec une base de données, seul le recours à la définition en exten-
sion est permis. Il faut donc toujours lister un à un l’ensemble des tuples de la relation.
On appelle schéma d’une table l’ensemble des attributs y figurant donc l’ensemble des
colonnes de cette table. Par extension, on désigne également schéma d’une base de données
l’ensemble des tables contenues dans une base de données.
À l’aide de l’ensemble de ces éléments, nous pouvons donner une définition d’une base de don-
nées relationnelle.
Définition
Une base de données est dite « relationnelle » lorsque son schéma est constitué d’un
ensemble de tables relationnelles, chacune correspondant à une relation, et dont les occur-
rences sont les tuples de celles-ci.
EXEMPLE
Soit le schéma suivant d’une base de données :
Élèves(Matricule_el, Prénom, Nom)

Enseignants(Matricule_en, Prénom, Nom, Matière)
Notes(Matricule_el, Matricule_en, Mathématiques, Physique, Informatique)
Il se traduira par5 :
Élèves Matricule_el Prénom Nom
Enseignants Matricule_en Prénom Nom Matière
Notes Matricule_el Matricule-en Mathématiques Physique Informatique
Parallèlement, d’autres types de bases de données existent également. Leur utilisation est mar-
ginale en regard de celle des bases de données relationnelles. À titre d’exemple, citons les bases
de données orientées objets et les bases de données déductives.
4. Le lecteur souhaitant approfondir ses connaissances sur ce sujet pourra se reporter en annexe.
5. Seules deux lignes, à titre d’exemple, ont été insérées dans chaque table. Mais, bien sûr une table peut
en contenir bien plus, autant qu’il y a d’enregistrement à insérer.
202151TDPA0116 19
4. Base de données de type « orienté objets »

Les bases de données relationnelles sont parfaitement adaptées aux applications de gestion.
Elles gèrent essentiellement des données. Cependant, il existe des besoins non négligeables de
gérer des objets complexes. Parmi ceux-ci, nous pouvons distinguer les objets statiques tels
que, par exemple, des textes, des graphiques, des cartes, des images, etc., ainsi que des objets
dynamiques tels que, par exemple, des programmes informatiques, des simulations, etc.
Les SGBD gérant des bases de données relationnelles sont inadaptés à ce genre de gestion
d’où un besoin en SGBD spécialisés. Cependant, il est possible d’étendre des SGBD relation-
nels afin de leur offrir des capacités à gérer de tels objets.
5. Bases de données déductives

Dans le but de faciliter le développement d’applications informatiques, d’éviter de dupliquer des
programmes à fonctionnalités voisines et de supporter des facilités de raisonnements symbo-
liques rapides il apparaît nécessaire d’intégrer une définition des connaissances générales
autour de la base de données.
Les faits stockés dans les relations constituent la base de données extensionnelle. Les règles
expriment les connaissances, sous forme de prédicats dérivés, encore appelés relations déri-
vées. Elles constituent la base de données intentionnelle.
L’objectif est d’intégrer le maximum de connaissances dans la base intentionnelle afin de réduire
de façon significative le volume des programmes spécifiques à la mise en œuvre de chaque
application et de faciliter le partage relationnel des connaissances.
6. Bases de données réparties

Depuis la genèse de l’informatique, la centralisation a été dominante voire omniprésente dans
la gestion des données. Les données sont stockées et gérées par un unique calculateur contrôlé
par un service informatique très présent, lui-même généralement centralisé.
Jusqu’au début des années 1980, compte tenu du coût élevé des matériels et des très faibles
capacités des réseaux, seule l’approche centralisée avait raison d’être. Ce contexte a d’ailleurs
été bénéfique au développement même de la notion de base de données qui, par définition, tend
à centraliser les données et leur administration.
Ensuite, le développement fulgurant de la microinformatique associé à celui des réseaux infor-
matiques a permis l’émergence du concept de base de données répartie offrant ainsi une alter-
native à l’unique centralisation.
Intuitivement, une base de données répartie est constituée d’une collection de données corré-
lées logiquement mais réparties physiquement en plusieurs points interconnectés via un réseau
informatique.
Le programme d’application en charge d’administrer l’ensemble des données, qui repose sur un
système spécifique pour la gestion de données réparties, peut alors de façon transparente accé-
der aux données localisées en divers points sans même savoir où telle donnée se situe physi-
quement.
Il serait réducteur, et de surcroît faux, de confondre le concept de base de données distantes
avec celui de base de données réparties. Dans le premier cas, même si les données sont stoc-
kées sur un serveur distant de celui qui héberge les programmes d’application, les données sont
centralisées. Pour accéder à des données, l’utilisateur doit connaître la localisation de la base de
données et la mentionner explicitement. Dans le second cas, aucune localisation géographique
n’est à connaître pour accéder à une donnée. L’utilisateur perçoit les données réparties de façon
identique que les données soient réparties ou non. La répartition lui est inconnue, elle lui est
transparente.
L’avantage de cette transparence est qu’en cas de restructuration, de réorganisation physique
de la base de données, il se peut que la répartition sur les divers serveurs concernés soit
20
impactée. Mais, quoi qu’il en soit, cela n’aura pas le moindre impact sur les programmes d’appli-
cation qui accèdent aux données. La transparence les préserve de ces modifications physiques.
Par ailleurs, pour des raisons de fiabilité des données, l’unique solution est d’avoir de la redon-
dance des données sous certaines formes. L’unité de duplication est, en général, le segment. Un
segment est dupliqué quand il réside simultanément au minimum sur deux serveurs différents.
Si l’un des sites hébergeant un segment devient non opérationnel pour une raison quelconque,
le segment est toujours accessible via l’une de ses copies. Le fonctionnement d’un site local
n’est donc en rien affecté par le dysfonctionnement d’un autre site.
Si cette duplication présente des avantages, elle est également source d’une certaine com-
plexité. En effet, la problématique de mise à jour d’un segment doit se faire automatiquement et
simultanément sur toutes les copies ce qui impose obligatoirement une automatisation de cette
tâche. Malgré tout, une autre problématique persiste. Si l’un ou plusieurs des sites hébergeant
un segment est en panne lors d’une mise à jour d’un segment. Lorsqu’il redémarrera, il ne sera
pas modifié et ne sera donc pas conforme aux autres segments qui eux auront subit la modifi-
cation. Des mécanismes pour pallier ce problème doivent impérativement être mis en place.
Les données étant réparties en divers lieux, chaque site peut manipuler, gérer, contrôler ses
données locales, indépendamment des autres sites. De ce fait, l’administration de la base de
données répartie peut être totalement décentralisée. Chaque base de données locale peut être
gérée par son propre administrateur. Cependant, la coopération entre les divers sites doit être
assurée et rester cohérente. Cette coopération peut être assurée par les administrateurs locaux
par l’existence de commandes spécifiques fournies par le SGBD réparti.
Un autre avantage des bases de données réparties est son pouvoir à s’agrandir dynamiquement
en fonction des besoins. On nomme cette propriété l’extensibilité. Celle-ci peut se faire de
façon incrémentale par l’ajout progressif de nouveaux sites dans le réseau avec un impact
minime sur les autres bases de données locales et les programmes d’applications existants.
7. Bases de données locales

De nos jours les moyens d’accéder à de l’information sont très répandus et totalement décen-
tralisés. À l’aide d’un Smartphone, par exemple, il est possible d’avoir accès à un volume consi-
dérable d’applications et d’informations. Or, bon nombre de ces applications recourent à une
base de données et celle-ci doit être accessible très rapidement. Pour minimiser le nombre de
requêtes via les connexions téléphoniques, les données sont directement stockées sur le péri-
phérique. Des bases de données pouvant fonctionner en environnement dégradé ont donc vu le
jour. À titre d’exemple, intéressons-nous quelques instants à SQLite6.
SQLite est une base de données particulièrement appréciée car non seulement elle offre une
interface SQL (Structured Query Language) conviviale et relativement simple d’emploi mais éga-
lement ne nécessite que peu de mémoire tout en offrant une rapidité de traitement satisfaisante.
SQLite appartient au domaine public et il peut donc être utilisé librement. De grandes entreprises
telles qu’Adobe, Apple, Google, etc., ainsi que plusieurs projets open-sources tels que Mozilla,
PHP, Python, etc., offrent désormais des solutions intégrant SQLite. Comme de plus, SQLite est
intégrée maintenant dans le moteur d’exécution d’Android, n’importe quelle application amenée
à s’exécuter dans cet environnement est à même de recourir à SQLite.
La plus grande différence de SQLite avec les autres SGBD relationnel porte sur le typage des
données. Cette remarque mise à part, on dispose là d’un SGBD relationnel complet offrant, entre
autre, les triggers, les transactions, etc. L’ensemble des instructions de base des instructions
SQL comme, par exemple, select, create, delete, etc., fonctionne exactement tel qu’on est en
droit de l’attendre.
Des personnes habituées à travailler régulièrement avec un SGBD tel qu’Oracle, par exemple,
peuvent être amenées à considérer SQLite comme un gadget. Mais, il ne faut pas perdre de vue
6. Téléchargeable gratuitement à l’adresse suivante : www.sqlite.org.
202151TDPA0116 21
que les deux systèmes ont été conçus pour apporter une réponse à des problématiques bien
différentes : on ne peut pas installer complètement Oracle sur un Smartphone alors que SQLite
le permet déjà.
Compte tenu de leur importance ainsi que pour des raisons pédagogiques, focalisons notre
attention davantage sur les bases de données relationnelles, modèle qui est aujourd’hui omni-
présent. De plus, les notions que nous allons abordées faciliteront la compréhension de concepts
abordés ultérieurement.
II. LES BASES DE DONNÉES RELATIONNELLES

Toute organisation souhaite posséder un SI performant, évolutif et fiable. Pour ce faire, la réali-
sation d’un bon système informatique est fondamentale. Celui-ci constitue l’architecture maté-
rielle et logicielle sur lesquelles un SI s’appuie. Un système informatique constitue la charpente
du SI.
Tout système informatique se décompose selon deux axes :
• le matériel7, regroupant les postes serveurs, les postes clients, la connectique, les réseaux et
leurs équipements d’interconnexion et de routage, etc. ;
• le logiciel8, regroupant les systèmes d’exploitation, les programmes spécifiques, les progi-
ciels, les gestionnaires de fichiers, les SGBD, etc.
Nous n’entrerons pas ici dans un descriptif de l’ensemble de ces divers éléments. Ceux-ci seront
détaillés dans la série 2, pour les progiciels en général et plus spécifiquement pour les ERP et
dans la série quatre pour les infrastructures matérielles et logicielles. Nous nous contenterons de
nous focaliser sur le concept de « Base de données relationnelle ». Après avoir abordé la place
des serveurs de bases de données dans le processus de développement, nous focaliserons
notre attention plus particulièrement sur la conception et la mise en œuvre d’une base de don-
nées relationnelle.
A. LA PLACE DU SERVEUR SQL

De nos jours, généralement, l’utilisation du SI se fait dans un contexte d’Intranet. À partir d’un
navigateur, on accède, selon ses droits, à tout ou partie des applications et des informations
résidentes sur le ou les serveurs de l’organisation.
Cette situation peut se schématiser ainsi :
Figure 6 – Architecture d’un intranet
Poste client, Intranet Logiciel serveur Web : Scripts : Serveur SQL :

muni d’un Apache, Tomcat, IIS… PHP, Java, Asp… MySQL, Oracle,
navigateur MS SQL…
Cette architecture est identique qu’il s’agisse d’un site Web, de commerce électronique ou non,
sur Internet, d’un intranet ou encore d’un extranet. À titre informatif, rappelons les différences
entre ces trois termes. Une application mise à disposition sur Internet est accessible à tous, en
tout point du globe terrestre, à partir du moment où l’on est en mesure de se connecter. Une
application mise à disposition sur un intranet peut être accessible de tout point de la terre à
partir du moment où l’on est membre de l’organisme propriétaire de l’intranet. Derrière ce
concept, il n’y a nullement une notion de périmètre géographique comme parfois des personnes
7. Ou hardware.
8. Ou software.
22
sont amenées à le penser. Seule l’appartenance à l’organisme qui a mis en place l’intranet est
obligatoire. Enfin, un extranet est un intranet sur lequel on a ouvert à des personnes non membre
de l’organisme propriétaire des accès à tout ou partie des données et applications hébergées.
Par exemple, il peut s’agir d’une entreprise qui offre certains accès à des fournisseurs ou à des
sous-traitants. Tout comme un intranet, un extranet est également accessible en tout point de la
surface terrestre.
1. Ce que le serveur SQL peut faire

Un serveur SQL a deux principales fonctions : enregistrer efficacement les données et les resti-
tuer rapidement. Il est le lieu où elles vivent. Il est possible d’en insérer de nouvelles, d’en sup-
primer ou d’en modifier et ce de différentes façons.
De plus, un serveur SQL est en mesure de fournir des statistiques sur les données stockées. Par
exemple, imaginons que l’on ait enregistré les noms et adresses d’élèves sur notre serveur SQL.
Si nous souhaitons savoir à un moment combien d’entre eux résident dans Paris intra-muros,
notre serveur SQL sera en mesure de nous fournir cette information rapidement et aisément.
Pour cela, il invoquera son moteur d’inférence en mesure d’interpréter la requête SQL qui lui sera
adressée à cet effet.
2. Ce que le serveur SQL ne peut pas faire

La figure 6 ci-avant fait ressortir qu’un serveur SQL n’est pas en interaction directement avec
le navigateur installé sur le poste du client, l’utilisateur. Dans les applications pour le Web, deux
parties logicielles complètent le serveur SQL. Il s’agit du serveur Web et du middleware, consti-
tué des logiciels intermédiaires.
Le travail du serveur Web est relativement simple. Il est connecté en permanence à l’Internet
tout comme à l’intranet, selon le cas, et est en attente de requêtes http9, qui est le mode de
communication de tout navigateur Web, en provenance d’adresses IP ou de noms de domaines
spécifiques. Lorsqu’un utilisateur entre dans son navigateur une adresse Web ou URL10 ou
encore clique sur une ancre dans une page Web affichée, une requête http est adressée auto-
matiquement au serveur Web destinataire. Celui-ci la réceptionne et l’interprète puis retourne la
réponse correspondante. Un serveur SQL n’est pas en mesure lui d’interpréter et encore moins
de répondre directement à une requête http, même si celle-ci a pour vocation d’interroger une
base de données.
Dans des applications professionnelles bien des serveurs Web et SQL sont issus du monde du
logiciel libre. Parmi ceux-ci, nous pouvons citer, pour les serveurs Web, Apache, Tomcat, JBoss,
GlassFish et, pour les serveurs SQL, MySQL et PostgreSQL. Naturellement, des solutions com-
merciales, soumises à licence sont également utilisées, comme par exemple, pour le serveur
Web, Internet Information Services (IIS) et, pour le serveur SQL, Microsoft SQL Server. Ces deux
solutions sont des produits de Microsoft. Nous pouvons, bien sûr, citer également des solutions
tels que DB2 d’IBM ou encore Oracle de la société du même nom.
L’aspect dynamique de la consultation d’une base de données impose à l’ensemble de réagir en
fonction de la requête et non de façon systématique. Ainsi, par exemple, si l’on consulte la liste
des clients afin de savoir ceux qui ont commandé pour plus de 10 000 € de marchandise et
habitant Paris. Seules les réponses correspondant à ces deux critères doivent être retournées
sous la forme d’une page Web idoine. C’est ici que le middleware joue pleinement son rôle.
9. HyperTexte Transfert Protocol : le protocole de transfert de documents basés sur l’hypertexte, fonde-
ment du Web.
10. Uniform Resource Locator : adresse d’un site Web du type http://www.xxxxxx.yyy. La présence des
trois w n’est pas obligatoire.
202151TDPA0116 23
B. LES PRINCIPES DIRECTEURS DE CRÉATION D’UNE BASE DE DONNÉES

Pourquoi les bases de données relationnelles sont-elles si utiles ? Pourquoi ne recourons-nous
pas directement au système de fichier pour le stockage de données ?
Bien des solutions de stocker des données existent. Les langages de programmation ont eux-
mêmes leurs propres structures de données internes : tableaux, objets, scalaires, etc., utiles
pour diverses tâches. Indépendamment du système d’exploitation utilisé, il est toujours possible
de stocker des informations dans un fichier puis d’accéder à son contenu chaque fois que
besoin est dans une application.
Selon le type d’application que l’on écrit, le stockage de données dans des fichiers peut conve-
nir. Sous Windows, bien des applications recourent à un fichier d’extension « .ini » qui définit des
paramètres spécifiques et sert à l’initialisation du programme lorsqu’il est exécuté la première
fois. Sous Unix, la plupart des applications ont une sorte de fichier « .conf » qui assure la même
fonctionnalité d’initialisation.
Mais un système de fichiers, quel que soit le système d’exploitation, n’est pas conçu pour traiter
efficacement des modifications rapides et fréquentes. Que ce soit sous Windows ou sous Unix,
des fichiers d’initialisation sont peu accédés que ce soit en lecture ou en écriture. Aussi, vu la
faible fréquence d’accès à ces fichiers, le fait d’y recourir ne pose pas de problème.
Or, dans une application où de nombreux utilisateurs peuvent accéder simultanément à des
données, comme dans le cadre du Web, de nombreux problèmes se poseraient en utilisant des
fichiers, notamment la gestion des conflits d’accès. En effet, chaque fois qu’un utilisateur tente
d’ajouter, supprimer ou modifier une ou plusieurs informations dans un fichier, il est indispen-
sable de s’assurer qu’il n’est déjà pas accédé par un autre utilisateur. Des mécanismes de ver-
rouillage sophistiqués doivent exister garantissant ainsi que les données sont maintenues dans
un état cohérent.
Un système de gestion de base de données relationnelle ou SGBDR assure en grande partie ces
mécanismes de verrouillage assurant de facto la sécurisation des accès aux données. Il faut
cependant rester vigilant dans le cas de transactions, d’autant plus si elles sont distribuées.
Nous n’entrerons pas dans cette problématique qui dépasse largement le cadre de ce cours.
1. Utiliser des tables
L’intégralité des SGBDR stockent les données dans des tables. Conceptuellement, celles-ci ne
diffèrent en rien des tableaux que l’on est amené parfois à créer lors de l’utilisation d’un traite-
ment de texte ou d’un tableur. Ces tables sont automatiquement protégées par le SGBDR contre
les problèmes que l’on peut connaître avec des fichiers et évoqués récemment. Aussi, plusieurs
applications peuvent interagir simultanément sur des données avec l’assurance que les inser-
tions, mises à jour et suppressions dans les tables ne s’effectueront pas de façon inappropriée.
Ceci dit, il serait faux de penser que recourir simplement à des tables suffit à résoudre bien des
problèmes. Imaginons que le système recourt à des tables protégées par des mécanismes de
verrouillage mais sans autres particularités. Chaque fois qu’un élève s’inscrit à un cours, ses
noms, prénoms et adresse sont inscrits dans la table. Que va-t-il se passer si l’élève vient à
déménager en cours d’année ? Il sera nécessaire de modifier l’adresse autant de fois qu’elle
apparaîtra. On peut estimer que cette situation n’est pas particulièrement problématique puisque
le nombre d’élèves déménageant en cours d’année est rarement conséquent. Mais imaginons,
par exemple, un site de commerce en ligne dont des tables contiennent des milliers de lignes.
Une problématique de modification est évidente.
L’un des buts des tables relationnelles est d’assurer que la mise à jour d’une seule ligne ne
risque pas de corrompre des données dans d’autres lignes. Si l’adresse d’un élève à une ligne
est modifiée alors que l’adresse du même élève est différente dans une autre ligne de la même
table, nous aurons des informations contradictoires puisque différentes. Si une telle situation
peut se présenter, si la modification d’une donnée peut conduire à des données en conflit, alors
on est en présence de ce que l’on nomme une anomalie de mise à jour.
24
Quelle réponse apporter à cette problématique ? En créant une autre table qui ne contiendra que
les coordonnées des élèves. Celle-ci ne contiendra qu’une ligne unique par élève. Ainsi, si un
élève déménage en cours d’année universitaire, une unique modification devra être effectuée,
éliminant de facto la problématique d’anomalie de mise à jour.
Afin de relier les tables entre elles, il sera nécessaire d’avoir une colonne identique dans chacune
d’elles. Nous voyons donc pourquoi la désignation base de données relationnelle est utilisée et
qu’il s’agit d’une appellation appropriée.
Sans entrer dans les détails, signalons que certaines configurations peuvent entraîner que la
suppression d’une ligne de données dans une table puisse conduire à la suppression de don-
nées que l’on a l’intention de conserver. Si la structure d’une table peut conduire à cette situa-
tion, alors la table contient une anomalie de suppression.
Signalons qu’il est également possible d’être confronté à une anomalie d’insertion.
2. Normaliser les relations

Dans la phase de conception d’une base de données, le processus permettant d’éliminer les
anomalies citées ci-avant se nomme normalisation. Avant de pouvoir normaliser les données, il
faut dresser l’inventaire exhaustif de celles que l’on souhaite conserver en prenant en compte
toutes les données dont on a besoin maintenant ainsi que celles dont on pourrait avoir besoin
dans le futur.
On prendra quelques échantillons des données retenues et on les insérera dans des tables. Bien
sûr, ces tables comporteront inévitablement beaucoup d’anomalies, mais il faut bien commen-
cer par quelque chose. Ces tables imparfaites seront corrigées au fur et à mesure du processus
de normalisation.
Durant ce processus de normalisation, les données seront mises en forme normalisée.
Certains critères devront impérativement être respectés avant que les données puissent être
considérées comme étant en forme normalisée.
Il existe cinq formes normalisées. Elles s’enchaînent chronologiquement. La première étape
sera donc de mettre les données en 1re forme normale. Cette étape finalisée, les données pour-
ront alors être mise en 2e forme normale et ainsi de suite. Arrivé au stade de la 3e forme normale,
à peu près toutes les anomalies seront éliminées.

Nous n’entrerons pas ici dans la mise en œuvre de ces formes normalisées, ce sujet débordant
le cadre de ce cours. Nous laissons le lecteur intéressé par ce sujet se reporter en annexe ainsi
qu’à des sources d’informations spécialisées. Fort de ces connaissances, revenons maintenant
à l’étude du déroulement de la réalisation d’une base de données qui comporte quatre étapes :
• recueil des besoins ;
• modélisation ;
• conception ;
• réalisation.
Examinons chacune de celles-ci.
3. Étude et recueil de l’expression des besoins utilisateurs

La toute première étape dans la réalisation d’une base de données, relationnelle ou non, consiste
naturellement à recueillir les besoins des futurs utilisateurs.
La conception d’une base de données, qui doit correspondre aux attentes des futurs utilisateurs,
n’est pas envisageable sans une écoute et une compréhension préliminaire des besoins qu’ex-
primeront ceux-ci. Ces attentes s’exprimeront en termes de fonctionnalités et de traitements des
informations que gérera le futur SI. Le recueil des besoins concernera des aspects fonctionnels,
organisationnels, économiques et sécuritaires.
202151TDPA0116 25
Cette phase s’appuie essentiellement sur des audits d’utilisateurs. L’étude débute par l’existant
afin d’acquérir, autant soit peu, la connaissance exhaustive du sujet et ainsi être en mesure de
recenser les informations concernées, leurs flux, les acteurs qui interviennent, les traitements
automatisés et ceux qui ne le sont pas, leur chronologie, etc. Les informations retenues seront
de toute nature et pourront être conservées sur divers supports : fichiers, courriels, fax, etc.
4. Maîtrise d’œuvre et maîtrise d’ouvrage

Deux entités interviennent à ce stade : la Maîtrise d’OuvrAge (MOA) et la Maîtrise d’Œuvre (MOE).
Au premier incombe la responsabilité d’exprimer clairement et de façon exhaustive les besoins.
La MOA est toujours à l’origine d’un projet. C’est le client, le demandeur. La MOE, elle, doit avoir
une bonne compréhension de ce que lui spécifie la MOA. Cette dualité, cette complémentarité
entre les deux entités constitue ici l’une des clés de la réussite de tout projet informatique.
En effet, seule une bonne compréhension par la MOE des besoins exprimés par la MOA lui per-
mettra de circonscrire précisément les domaines concernés ainsi que les informations qui tran-
siteront dans le futur SI et qui devront être traitées. À partir de cette connaissance, il sera alors
possible à la MOE de structurer efficacement ces données.
Cette étape de structuration donnera lieu à la recherche des liens pouvant exister entre des don-
nées. Ces liens sont dénommés dépendances fonctionnelles. Pour faciliter leur recherche, on
aura recours à ce que l’on dénomme une matrice des dépendances fonctionnelles (MDF).
5. Dépendance fonctionnelle (DF)

Avant d’aborder l’élaboration de cette matrice, arrêtons-nous un instant sur cette notion de
dépendance fonctionnelle. Le dictionnaire des données rassemble les données retenues.
Chacune d’elles est liée à une entité du monde réel. Il peut exister des relations entre des don-
nées d’une même entité. Ce sont ces relations qui sont qualifiées de DF. Cette notion illustre la
dépendance entre informations. Par exemple, la majorité dépend de l’âge, la civilité dépend du
sexe, etc.
Définition
On dit que deux données X et Y sont en dépendance fonctionnelle si et seulement si chaque
valeur de X détermine automatiquement une unique valeur de Y. Ceci doit être vérifié pour
chacune des valeurs de X.
Les valeurs de X sont appelées « données sources » alors que celle de Y sont dites « données
cibles ».
6. Dictionnaire des données

La constitution d’un dictionnaire des données est une étape intermédiaire incontournable, d’au-
tant plus si plusieurs personnes doivent travailler simultanément sur une même base de données
et si le volume des données est conséquent.
Il s’agit d’un document regroupant l’intégralité des données qui devront être conservées dans la
base de données et qui figureront donc dans le modèle de conception de données (MCD). Il
correspond à la description de toutes les entités du modèle.
Pour chaque donnée, le dictionnaire des données mentionne :
• son code mnémonique : il s’agit d’un libellé désignant de façon unique et non ambigüe une
donnée comme, par exemple, « titre_DVD » pour le titre d’un DVD ;
• une désignation : il s’agit d’une courte mention décrivant la finalité de la donnée, par exemple
« titre d’un DVD » ;
• le type de donnée : chaque type est codifié par un repère unique :
–– A ou Alphabétique quand la donnée est uniquement composée de caractères alphabé-
tiques (de ‘A’ à ‘Z’ et de ‘a’ à ‘z’),
–– N ou Numérique si la donnée est composée uniquement de nombres entiers ou réels,
26
–– AN ou Alphanumérique quand la donnée peut être composée à la fois de caractères alpha-

bétiques et numériques,
–– Date quand la donnée est une date au format AAAA-MM-JJ,
–– Booléen : vrai ou faux ;
• la taille qui s’exprime en nombre de caractères ou de chiffres. Dans le cas d’une date au for-
mat AAAA-JJ-MM tout comme JJ-MM-AAAA, on compte également le nombre de caractères,
soit 10. Les deux signes tirets de séparation sont comptabilisés, ils font partie intégrante de la
date. Pour ce qui est du type booléen, nul besoin de préciser la taille (ceci dépend de l’implé-
mentation du SGBDR) ;
• une remarque complémentaire, par exemple, si une donnée est > 0.
Les données qui figurent dans le MCD, et donc dans le dictionnaire des données, doivent en
général être élémentaires :
• elles ne doivent donc pas être calculées. Les données calculées donc obtenues par calcul à
partir de données élémentaires qui, elles, sont conservées en base. Cependant, il existe
quelques cas où il s’avère pertinent de conserver, pour des raisons d’optimisation, une donnée
calculée, le montant d’une commande par exemple. On ne conservera cependant pas les don-
nées calculées intermédiaires sauf en cas d’obligation légale comme, par exemple, un mon-
tant HT où les composantes peuvent d’ailleurs avoir un prix variable dans le temps. En effet,
cela évite de refaire les calculs plusieurs fois pour un résultat qui restera fixe ;
• elles ne doivent pas être également composées. Les données composées doivent être obte-
nues par la concaténation de données élémentaires conservées en base. Par exemple, une
adresse est obtenue à partir d’une rue, d’une ville et d’un code postal : ce sont ces trois der-
nières données qui sont conservées et qui figureront dans le MCD et donc dans le dictionnaire
des données.
Lorsqu’une donnée est numérique mais sans pour autant résulter d’un calcul comme, par
exemple, un numéro de téléphone, celle-ci doit être de type AN.
7. Matrice des dépendances fonctionnelles

Revenons sur l’élaboration de la matrice des dépendances fonctionnelles. Celle-ci s’élabore en
suivant trois étapes :
Étape 1 : étudier individuellement chacune des données présentes dans le dictionnaire des don-
nées et, pour chacune d’elles, rechercher s’il existe des dépendances fonctionnelles sources ou
cibles. Regrouper ensuite toutes les dépendances fonctionnelles identifiées au sein de la matrice
des dépendances fonctionnelles dans laquelle les en-têtes des colonnes représentent les
sources et les en-têtes de lignes correspondent aux cibles.
Étape 2 : passer en revue l’ensemble des données sources et pour chacune s’interroger si pour
une valeur précise de celle-ci il est possible d’identifier une unique valeur d’une ou de plusieurs
données cibles. Pour chaque donnée répondant positivement à l’interrogation, placer « df » à
l’intersection de la ligne et de la colonne correspondante.
Étape 3 : une fois l’analyse de l’ensemble des données à même d’être une donnée source, on
doit simplifier la matrice des dépendances fonctionnelles. Pour ce faire, on ne conserve que les
colonnes dont l’intitulé, l’en-tête, est effectivement une donnée source.
Les attentes des utilisateurs seront regroupées au sein d’un document dénommé « cahier des
charges ». Il s’agit, en quelque sorte, de l’expression du « Quoi ? » : que devra être en mesure
d’assurer le prochain SI ? Le cahier des charges est un document contractuel. Dès lors où la
MOE, interne ou externe11, accepte le cahier des charges, elle s’engage à répondre aux besoins
qu’il exprime. Dans le cas d’une sous-traitance, le cahier des charges constitue directement une
annexe au contrat.
11. Dans le cas d’une sous-traitance, par exemple.
202151TDPA0116 27
Bien que finalement les informations gérées seront structurées puis implémentées dans une
base de données et que des applications informatiques réaliseront les traitements idoines pour
obtenir les informations souhaitées, à ce stade du travail encore aucune information n’est don-
née ni même connue sur le « Comment » du futur SI. Nous sommes encore loin des solutions tant
techniques qu’organisationnelles permettant d’apporter une solution aux attentes exprimées.
La MOE se limitera à ce stade à dresser la liste des informations recensées dans le but de créer
un recueil des données pertinentes ainsi qu’à envisager une structure dédiée à leur futur
usage. À cette fin, les données redondantes, directement ou non, seront éliminées. Il faudra être
vigilant sur le fait que des données peuvent avoir des dénominations différentes dans le monde
réel mais cependant avoir le même sens dans le SI et donc être redondantes même si cela n’est
pas percutant à première vue. Dans ce cas, la MOE devra ne retenir que les données les plus
pertinentes donc les données les plus stables, les moins enclines à être modifiées, celles qui
apparaissent le plus fréquemment dans les traitements applicatifs, etc.
À l’inverse, il faudra également être vigilant au fait que peuvent exister des données homonymes.
Bien qu’ayant la même dénomination, elles peuvent avoir un sens différent dans le SI. Il faudra
alors les renommer afin de leur redonner leur sémantique originelle et assurer leur existence
dans le futur SI.
La MOE devra veiller à ce que chaque information soit liée à un objet du « monde réel » dénommé
entité dont chaque occurrence puisse être déterminée de façon unique. Par ailleurs, chaque
identifiant associé ne prendra qu’une unique valeur assurant ainsi l’exclusivité pour chaque
occurrence. Par exemple, Nom de l’élève, Prénom de l’élève, Adresse de l’élève représentent
bien les caractéristiques d’un élève. Mais elles sont nettement insuffisantes pour distinguer sans
ambiguïté un élève parmi les autres. En effet, rien n’interdit que deux élèves, voire plus, portent
le même nom ou le même prénom dans l’établissement. De même, si deux frères sont scolarisés
dans le même établissement, ils partageront a priori la même adresse. Il sera donc indispensable
d’introduire une donnée supplémentaire, prenant une valeur unique pour chaque élève. Ce sera
généralement un matricule.
Rappelons qu’une fois ce travail terminé, l’ensemble des données retenues constituera ce que l’on
nomme le dictionnaire des données du SI cible. Celui-ci se présente sous la forme d’un tableau
où chaque ligne illustrera une donnée et chaque colonne une caractéristique de celle-ci.
Nous focaliserons volontairement notre attention plutôt sur les données que sur les traitements.
En effet, ces derniers relèvent du domaine de la programmation, ce qui sort du cadre de ce
cours, et n’interviennent en rien dans l’élaboration d’une base de données.
Mais, bien sûr, il faudra toujours avoir à l’esprit dans le développement d’un SI que les deux sont
indissociables. Données et traitements sont étroitement liés. Toute modification sur l’un des
deux peut se répercuter significativement sur l’autre. Ce principe de liens étroits est d’ailleurs
omniprésent dans toutes les méthodes de développement de projet, qu’elles soient orientées
objet comme avec UML (Unified Modeling Language) ou non comme avec Merise.
III. DE LA CONCEPTION À LA MODÉLISATION D’UN SI

Rappelons qu’une base de données dite « relationnelle » est une collection de données qui sont
en relations dans des tables ; une table étant composée d’un ensemble de lignes et de colonnes.
Chaque colonne correspond à un attribut de la relation et chaque ligne correspond à une
occurrence de cette relation, aussi appelée enregistrement.
La qualité des informations est directement fonction de deux paramètres : la mémorisation et le
traitement des données. Si le premier paramètre est du ressort de la base de données, le second
est du ressort du SGBDR.
En effet, un SGBDR ne se cantonne pas seulement à la base de données en elle-même. Il intègre
également divers éléments logiques (les données) et physiques (leur mémorisation) permettant :
• l’administration et le maintien dans un état cohérent de la base de données ;
28
• d’assurer :
–– une indépendance physique de sorte que, d’une part, la structure physique de stockage soit
totalement transparente pour les utilisateurs et, d’autre part, qu’elle n’impacte en rien la
façon d’accéder aux données,
–– une indépendance logique afin que chaque application accède uniquement aux données qui
lui sont nécessaires,
–– un « langage de manipulation de données (LMD) » offrant un accès aux données à des per-
sonnes non informaticiennes. Celui-ci est suffisamment riche pour permettre une sélection
précise des données cherchées,
–– une centralisation de l’administration des données pour l’administrateur de la base de don-
nées via des outils d’administration inclus de facto dans le SGBDR,
–– une non-redondance de données grâce à une centralisation physique des données évitant
ainsi la mémorisation de données déjà existantes,
–– un partage sécurisé des données, via le concept de « verrouillage logique des données »,
–– la sécurisation des données avec, entre autre, la confidentialité de celles-ci, leur récupéra-
tion en cas d’incident, etc.
Le succès des SGBDR est dû essentiellement au fait que l’utilisateur n’a à se charger que de la
gestion du niveau logique ce qui lui donne une grande simplicité de la gestion de ses données,
même sans être un informaticien.
Il apparaît clairement que le SGBDR constitue un élément central d’un SI en répondant pleine-
ment aux attentes des utilisateurs. Par ailleurs, une base de données constitue une clé de voute
d’un SI de qualité.
Ceci dit, même avec les outils les plus puissants à sa disposition, la qualité du SI repose avant
tout sur une modélisation correcte de la base de données. Par analogie, nous pouvons dire que
quels que soient les matériaux utilisés et les techniques de construction, si les plans sont mau-
vais, le résultat le sera également.
De plus, une connaissance minimale des bases de l’algèbre relationnelle, à l’origine du modèle
relationnel, constitue un plus pour l’élaboration de requêtes optimales, tant pour la modification
que pour la consultation d’une base de données.
Il est donc fondamental de consacrer du temps initialement à cette modélisation et de maîtriser,
ne serait-ce qu’à minima, des méthodes de modélisation telles que Merise ou UML. C’est ce à
quoi nous allons nous attacher à présent.
Avant d’aborder un problème, il est toujours nécessaire de réfléchir profondément aux tenants
et aux aboutissants de ce que l’on va entreprendre avant de commencer.
Une phase de conception nécessite souvent d’effectuer de nombreux choix qui, parfois,
peuvent avoir des répercussions importantes ultérieurement. La conception d’une base de don-
nées relationnelle n’échappe pas à la règle.
Des spécialistes de la théorie de l’information ont proposés diverses méthodes destinées à
structurer un projet et de représenter de façon abstraite le travail envisagé. Ces méthodes sont
à l’origine d’une nouvelle discipline, l’analyse, et d’un nouveau métier, l’analyste. Cette disci-
pline étudie et présente de façon abstraite un travail à effectuer.
Une phase d’analyse est primordiale puisqu’elle sera présentée aux futurs utilisateurs qui auront
à la valider avant que ne débute la mise en œuvre du système étudié. Aussi, un soin particulier
doit lui être apporté.
Les façons d’étudier, d’analyser, les SI ont pour objectif de décrire ces systèmes par des modèles
puis de mettre en œuvre les SI qui en découlent. On distingue essentiellement deux grandes
approches : l’approche analytique et l’approche systémique.
202151TDPA0116 29
A. LES DIFFÉRENTES APPROCHES

1. L’approche analytique
Elle repose sur un découpage du domaine à étudier en sous-domaines plus réduits. Chacun de
ceux-ci, plus simple que le système initial, est étudié séparément. Ensuite, chacun des sous-
domaines est réintégré à l’ensemble afin de reconstituer le tout initial.
Cette approche privilégie avant tout les traitements. Aussi, il peut en résulter une complexité
inhérente au principe même en fournissant des sous-ensembles difficiles à interconnecter et
dont l’ensemble est à même de conduire à une solution peu cohérente. L’intégration de ces dif-
férents sous-ensembles pouvant s’avérer peu conforme avec la réalité que l’on est censé décrire.
2. L’approche systémique
Elle passe par une modélisation du système à étudier dans le but de le comprendre. Ce modèle,
obligatoirement réducteur par rapport à la réalité, est lui-même décomposé. On étudie ensuite,
en relation avec l’ensemble, chaque partie obtenue. La cohérence du tout est assurée par le
modèle représentatif de la réalité. Merise, une méthode de modélisation et de conception de SI
appartient à ce type d’approche. C’est donc une méthode systémique.
De nombreuses méthodes, plus ou moins spécialisées ont vu le jour. À titre d’exemple, citons
Axial, OMT, HOOD, H++, SADT, SART, etc. La méthode le plus utilisée en France pour la concep-
tion d’une base de données est la méthode Merise.
Avant d’aborder l’étude de la méthode Merise, demandons-nous ce qu’est une méthode et
quels peuvent être ses rapports dans la conception d’un SI. Le dictionnaire Larousse nous donne
la définition suivante :
« Ensemble ordonné de manière logique de principes, de règles et d’étapes permettant de
parvenir à un résultat. »
Le recours à une méthode va donc fournir au concepteur :

• une ligne de réflexion lui permettant de suivre une succession progressive d’étapes enrichis-
sant l’analyse au fur et à mesure ;
• la manière d’aborder les problèmes ;
• des représentations de la réalité, spécifiques à chaque étape, lui permettant d’assurer effica-
cement la communication entre MOA et MOE.
B. LA MÉTHODE MERISE
Il s’agit d’une méthode française développée dans les années 1980. En 1977, après le grand
succès des traitements automatisés, le ministère de l’Industrie a souhaité rationnaliser la concep-
tion des SI. Le contexte de la mise en place de la méthode était créé.
Plusieurs sociétés de service en ingénierie informatique (SSII) ont participé à cette étude en col-
laboration avec le centre d’études techniques de l’équipement (CETE) du ministère de l’Indus-
trie. Ainsi naquit la méthode Merise.
Il s’agit d’un ensemble structuré et intelligent de concepts et de règles de construction qui
s’intègre aisément à la structure d’une organisation pour gérer son SI de façon fiable et pérenne.
Cette méthode, bien que relativement âgée, est toujours d’actualité. Elle a su évoluer et s’adap-
ter à diverses innovations informatiques telles que Merise 2 pour les architectures dites « Client/
Serveur » ou encore MOO pour les conceptions dites « orientée objets ».
Merise est l’une des méthodes de conception les plus utilisées dans les administrations fran-
çaises, les banques, compagnies d’assurance, etc., car elle est particulièrement en adéquation
avec l’informatique de gestion.
30
Merise est donc une méthode systémique. Elle sépare les données des traitements. Si cela
l’alourdit quelque peu, cela permet de faciliter la maintenance des applications : une évolution
des traitements n’impacte pas systématiquement les données et réciproquement, allégeant ainsi
les mises à niveau.
Mais, bien sûr, dans le déroulement de la méthode, des étapes de vérification de la cohérence
entre traitements et données sont omniprésents.
1. Les trois dimensions de la méthode

Par analogie géométrique, la méthode peut être définie selon trois axes :
• la démarche ou cycle de vie ;
• le raisonnement ou cycle d’abstraction ;
• la maîtrise ou cycle de décision.
a. La démarche ou cycle de vie

Parmi les objectifs d’une méthode l’un est de guider l’informaticien lors de son processus d’in-
formatisation. C’est ce qui est appelé démarche ou cycle de vie dans Merise. On s’appuie pour
cela sur une succession de phases qui enrichissent progressivement l’étude en comportant des
activités bien définies. Ces activités peuvent être spécifiques à une phase mais également conti-
nues tout au long de la démarche. Par exemple, l’activité de création du dictionnaire des don-
nées est réalisé en début de projet et donc spécifique à cette phase alors que la création de
documentation est continue tout au long du projet. Le passage d’une phase à une autre résulte
de la validation par la MOA de la phase précédente.
Le nombre de phases est fonction de plusieurs critères : taille de l’entreprise, amplitude du pro-
jet, etc. Il n’est donc pas constant. Mais, quel que soit le cas, les phases couvrent systématique-
ment les tâches suivantes :
• l’analyse des besoins qui permettra de mettre en exergue les objectifs, les fonctionnalités
ainsi que les contraintes du futur SI ;
• la conception qui permettra d’affiner et de définir plus précisément les niveaux physiques et
conceptuels de la future solution ;
• les tests unitaires seront réalisés par les analystes-programmeurs afin de contrôler la prise en
compte des traitements requis ainsi que la qualité de la programmation ;

• les tests fonctionnels, appelés également parfois recette utilisateur, seront effectués par la
MOA. Ils servent à s’assurer que les fonctionnalités développées dans l’ensemble des divers
modules répondent intégralement et exactement à l’expression initiale des besoins ;
• la mise en œuvre inclut la préparation de l’intégration de l’ensemble du futur SI qui vient d’être
développé dans l’environnement de production, dans le SI déjà existant ;
• la maintenance consiste à prendre en compte les corrections d’éventuelles anomalies appa-
raissant à l’utilisation réelle mais également à apporter des réponses aux évolutions tant fonc-
tionnelles que techniques.
Les modèles Merise couvrent l’intégralité de l’ensemble de ces phases. Mais, les modèles les
plus structurants sont ceux couvrant les phases précédant celles de réalisation et de tests uni-
taires.
b. Le raisonnement ou cycle d’abstraction

Au fur et à mesure que la conception d’un SI avance, différentes problématiques risquent d’ap-
paraître. À titre d’exemple, nous pouvons citer :
• un manque de précision dans la définition des règles de gestion du futur SI ;
• une mauvaise définition des informations que devra gérer le futur SI ;
• un manque de précision dans la répartition des tâches entre l’homme et la machine ;
• une mauvaise répartition dans les traitements : en temps réel ou temps différé ;
• un manque de précision dans la chronologie des traitements ;
• etc.
202151TDPA0116 31
Les réponses à ces problématiques conduisent à devoir faire des choix de différentes natures :
gestion, organisation, technique, matérielle, etc. De plus, ces questions suivent une progression
allant du plus général au plus précis. Merise définit cela en termes de niveaux d’abstraction et
en propose quatre :
• le niveau conceptuel qui est le plus abstrait. Il sert à exprimer les grandes activités, les pro-
cessus inclus, les choix fondamentaux de gestion, les différents éléments structurels du futur
SI mais sans se soucier des moyens à mettre en œuvre, de leurs contraintes et de leur organi-
sation. Il permet de répondre à la question Quoi ?
• le niveau organisationnel sert à exprimer les choix d’organisation des ressources humaines
et matérielles, la localisation des données, leur visibilité, leurs modalités de mise à jour. Il per-
met d’apporter des réponses aux questions Comment ?, Où ?, Qui ?, Quand ?
• le niveau logique sert à exprimer les choix des moyens et ressources informatiques, indépen-
damment de leurs caractéristiques techniques. Il apporte une réponse à la question Avec
quels moyens ?
• le niveau physique permet la mise en œuvre des solutions informatiques en tenant compte
des caractéristiques techniques et de leurs spécificités et de leurs contraintes. Dans ce niveau,
la description de la ou des bases de données se fera avec le vocabulaire, la syntaxe du futur
SGBD choisi et les outils proposés par celui-ci. C’est le niveau le plus concret. Il correspond à
l’étape de construction avec le matériel et les outils.
Pour illustrer nos propos, considérons l’analogie de l’arrivée d’un PC au domicile :
• le niveau conceptuel peut être assimilé à la réponse à la question : « Où intégrer le PC dans le
domicile ? » Souhaitons-nous l’installer sur un meuble spécialement dédié à son usage avec
d’éventuelles options comme, par exemple, un emplacement pour l’imprimante ? etc. ;
• le niveau organisationnel va permettre de préciser qui sera en mesure d’utiliser le PC (parents
et/ou enfants). Quand pourra-t-il être utilisé (la journée, le soir, à des moments bien définis, à
tout moment) ? ;
• le niveau logique va préciser quels seront les moyens qui vont permettre de répondre à ce
besoin : la construction par un menuisier d’un meuble spécifique, l’achat d’un meuble déjà
monté, l’achat d’un meuble en kit à monter soi-même, etc. ;
• le niveau physique correspond à sortir les éléments du kit réceptionné : matériels, plan de
montage, outils, etc.
c. La maîtrise du projet ou cycle de décision
Chaque niveau d’abstraction présente des problèmes qui se manifestent inévitablement dans la
conception d’un SI. Il y a donc obligation à trouver des réponses et à devoir faire des choix :
quelle(s) solution(s), quels moyens, etc. ?
Ces choix, dans l’optique de la maîtrise d’un projet, induisent souvent des arbitrages relatifs aux
coûts, aux délais, au niveau de la sécurité mise en place, au niveau de la qualité du produit final,
etc. Or, ces différentes composantes sont antagonistes entre elles. On est conduit à en privilé-
gier une aux détriments d’au moins une autre voire plus. Particulièrement, si l’on réduit les bud-
gets, la qualité finale peut en être impactée : matériel moins performant, suppression de certains
tests, etc.
Ces décisions d’arbitrage sont donc stratégiques. Ce ne sont ni les utilisateurs qui expriment
leurs besoins ni l’équipe informatique qui apporte des réponses à ces besoins qui sont à même
de prendre de telles décisions. Aussi, un troisième type d’acteur apparaît : les décideurs,
membres de la direction.
Chacun des acteurs, à un moment ou à un autre, sera conduit à prendre au moins une décision
lors du déroulement du projet. Chacune des décisions sera prise dans l’intérêt du projet, pour
répondre aux critères de coûts, délais, qualité, etc. ; mais leur criticité sera variable en fonction
de la décision prise et de l’acteur qui la prendra.
C’est pour cela que la démarche de maîtrise de projet consiste à définir :
• les rôles précis et les responsabilités de chaque acteur ;
• les groupes d’acteurs : comité de suivi, comité de pilotage, etc. ;
32
• les décisions à prendre en cours de projet : solution privilégiée, plan de charge, etc. ;
• les documents à livrer, les livrables : cahier des charges, dossier de choix de solutions et de
sécurité, etc.
Pour un développement optimal d’un projet, les trois axes de Merise doivent être développés de
façon harmonieuse et homogène. Il ne faut surtout pas accentuer un cycle plus qu’un autre.
Sinon, cela impacterait l’ensemble.
2. Les modèles de Merise

Comme déjà mentionné, tout SI englobe des données et des traitements. Les données sont à la
source des informations pouvant être tirées du SI et les traitements agissent sur les données
pour les combiner ou les maintenir à jour, permettant ainsi de facto l’évolution d’informations.
a. Modèle conceptuel de communication (MCC)

Si des informations évoluent, c’est naturellement sous l’influence d’événements et de flux d’in-
formations en provenance d’autres systèmes en relation avec le SI. Il faut donc, dans un premier
temps, définir les frontières du SI :
• quels sont les domaines d’activité du SI : processus et acteurs internes ?
• quels sont les éléments externes au SI : acteurs externes ?
C’est la raison pour laquelle Merise intègre un modèle conceptuel de communication (MCC).
Il permet d’apporter une réponse aux questions précédentes.
Un MCC est composé de deux diagrammes :
• le modèle de contexte : en premier lieu, il faudra définir les frontières du SI et les acteurs
externes ainsi que les flux entrants et sortants qui existent entre un SI. Ceci ne sera réalisable
qu’avec une bonne compréhension des besoins des utilisateurs afin de définir précisément le
domaine d’étude. Bien sûr, on ne modélise pas l’intégralité du SI à chaque fois. Parler de
modélisation peut ne concerner qu’une partie du SI, un nouveau service, de nouvelles fonc-
tionnalités à mettre en place. En second lieu, il sera possible de spécifier les domaines d’acti-
vité que l’on souhaite incorporer dans le SI : activités commerciales, de production, de gestion
des ressources humaines… Arrêtons-nous un instant sur ce qu’est une activité.
Une activité appartient à un domaine et est constituée d’une ou plusieurs opérations élémen-
taires, chacune d’elles étant constituée d’une suite chronologique de tâches qui s’exécutent
sans interruption. Une opération élémentaire forme donc un tout cohérent. Elle se déclenche
sur la réception d’un évènement et retourne un résultat. Dans le cas où un SI comporte plu-
sieurs domaines d’activité échangeant des informations, chacun de ceux-ci représentera un
acteur interne. Ce dernier peut être un secrétariat, un atelier, un magasin, etc. Il est clair que
les acteurs internes reflètent la répartition organisationnelle des activités au sein du domaine.
Les autres entités qui ne sont pas circoncis par les frontières du SI sont des acteurs externes.
Ceux-ci ont une importance capitale puisqu’ils sont à la base de l’activité d’un domaine. En
effet, ce sont eux qui émettent des flux qui déclencheront puis entretiendront les activités d’un
domaine. Comme acteur externe, à titre d’exemple, nous pouvons citer un partenaire extérieur
comme un client ou un fournisseur mais également un autre domaine d’activité de l’organisa-
tion comme la direction des ressources humaines ou le service des achats ou encore une autre
unité élémentaire mais extérieure au SI étudié.
Un acteur, interne ou externe est actif. À la réception d’un flux, il réagira : traitement(s)
d’information(s), émission d’un nouveau flux, etc. Les flux sont donc le moyen par lequel le SI
va communiquer avec les acteurs externes mais également celui par lequel les acteurs internes
communiquent entre eux. La connaissance de l’ensemble de ces flux, permet de connaître le
fonctionnement global du SI étudié.
Un flux est caractérisé par :
–– la connaissance des acteurs, internes et externes, qui l’émettent et le reçoivent,
–– la catégorie de ces flux : matière, finance, etc. Concernant l’informatique de gestion, seuls
les flux d’information qui englobent les futures données retiennent notre intérêt ;
• le modèle de flux conceptuel entre un peu plus en profondeur dans un SI et va permettre de
mettre en exergue les grands domaines d’activités du SI, les acteurs externes ainsi que les flux
202151TDPA0116 33
échangés. En premier lieu, nous examinerons l’intérieur du SI et préciserons les activités qui y
sont incluses. Nous dresserons donc la liste exhaustive des acteurs internes. Ensuite, nous
identifierons les flux échangés entre ces acteurs. Cette étape est à même de distinguer plu-
sieurs niveaux d’études d’où plusieurs modèles de plus en plus approfondis. En effet, le but de
ces modèles est de représenter de plus en plus finement les flux échangés entre les activités,
le niveau de détail le plus fin étant celui d’une opération élémentaire dans une activité.
À ce stade, les grandes fonctionnalités ainsi que tous les flux d’informations sont identifiés et
modélisés. À partir de là, la méthode Merise propose de spécialiser l’analyse et la modélisation
en distinguant les données des traitements. Nous n’aborderons pas ici la modélisation des trai-
tements, ce sujet sortant largement du cadre de ce cours.
Notre préoccupation est donc maintenant de pouvoir bâtir une base de données à partir des
modèles de données de Merise. Parmi ces modèles, un se détache des autres plus particulière-
ment dans la conception d’une base de données et retiendra par conséquent toute notre atten-
tion. Il s’agit du modèle conceptuel des données (MCD).
b. Modèle conceptuel de données (MCD)

Le MCD est un modèle abstrait offrant une représentation graphique des informations ce qui
en permet une représentation efficace et facilement compréhensible. Il permet en outre une des-
cription statique d’un SI à l’aide d’entités et d’associations. Il repose sur le concept du schéma
entités-associations appelé également schéma entités-relations. Le travail de création à pro-
prement parlé d’une base de données débute juste après la création du MCD par les analystes.
Mais, avant d’aborder ce sujet, commençons par définir quelques notions propres au MCD.
• Propriété : il s’agit d’une donnée élémentaire, non décomposable, du SI. Par exemple, l’effec-
tif de personnes travaillant sur un projet, la couleur d’un revêtement mural, la note d’un étu-
diant, etc.
• Entité : constitue la représentation dans le SI d’un objet matériel, d’un tout cohérent, qui a une
existence propre, appartenant au domaine étudié et en adéquation avec les choix de gestion
faits. Une entité est parfaitement définie par sa ou ses propriétés et un identifiant. Chaque
représentation de l’entité est appelé occurrence. Par exemple, l’entité élève pourrait être défi-
nie par les propriétés : matricule, prénom, nom, date de naissance et adresse postale.
Figure 7 – Représentation générale d’une entité
Nom de l’entité
.
.
Liste des propriétés
.
.
.
Figure 8 – Une entité et l’une de ses occurences

Élève Élève
Matricule 007
Prénom James
Nom Bond
Date_de_naissance 1 février 1996
Adresse_postale 10 rue d’issy 75001 Paris
• Association : elle informe sur le fait que dans le SI un lien existe entre deux ou plusieurs enti-
tés. Selon le nombre d’entités impliquées, on distingue quatre types d’associations :
–– réflexive : l’association porte sur une même entité ;
–– binaire : l’association porte sur deux entités ;
–– ternaire : l’association porte sur trois entités ;
–– n-aire : l’association porte sur n entités.
34
Une association possède obligatoirement un nom. Les noms des associations sont générale-
ment des verbes d’action car le lien qui relie une ou des entités représente toujours une action :
appartenir, payer, commander, voyager, etc. Par ailleurs, une ou des propriétés peuvent venir
enrichir une association mais ce n’est pas une obligation.
Figure 9 – Représentation d’une association binaire
Nom de l’entité 1 Nom de l’entité 2
. .
Nom de
. .
l’association
Liste des propriétés Liste des propriétés
de l’entité 1 Propriété(s) de de l’entité 2
. l’association .
. .
• Cardinalités : elles permettent d’enrichir le lien entre une entité et une association. Une cardi-
nalité comporte deux valeurs : une borne minimale et une borne maximale.
–– La borne minimale correspond au nombre minimal de fois qu’une occurrence de l’entité
concernée participe aux occurrences de l’association. Généralement, cette borne a la valeur
0 ou 1. La valeur 0 exprime le fait qu’il peut y avoir au moins une occurrence parmi toutes
celles existantes qui n’a jamais participé à l’association. Les cardinalités minimales sont
nécessaires pour exprimer certaines contraintes d’intégrité mais ne modifient en rien la
structure de la base de données qui sera mise en place. Elles ne servent qu’à spécifier si les
colonnes de la table concernée sont autorisées à prendre la valeur particulière NULL ou pas.
–– La borne maximale correspond au nombre maximal de fois qu’une occurrence de l’entité
concernée participe aux occurrences de l’association. Généralement, cette borne a la valeur
1 ou N. Les cardinalités maximales sont intéressantes dans la création d’une base de don-
nées. Elles permettent de déterminer le nombre de tables nécessaires dans la base de don-
nées relationnelle qui sera mise en place.
Figure 10 – Cardinalités sur une association
Étudiant Cours
. .
. Inscription .
Liste des propriétés 1,N 0,30 Liste des propriétés
d’un étudiant Propriété(s) de d’un cours

. l’association .
. .
Un étudiant s’inscrit au moins à un cours et peut s’inscrire à autant de cours qu’il le souhaite,
d’où la borne maximale indiquée. Par ailleurs, si l’on suppose que dans les règles de gestion des
enseignements définies par l’établissement, l’effectif maximal d’élèves par cours est de trente,
un cours peut n’avoir aucun élève inscrit ou au plus trente, d’où les cardinalités indiquées12.
• Identifiant : dans une entité, l’identifiant de celle-ci est constituée d’une ou plusieurs proprié-
tés de l’entité de sorte qu’à chaque valeur de l’identifiant une unique occurrence de l’entité
peut être associée. Il figure en souligné dans la représentation d’une entité. Il constitue par la
suite la clé d’une table relationnelle.
Figure 11 – Entité réflexive avec un identifiant
Matériel
0,N
Numéro
.
. Composé de
.
0,N
.
12. Rappelons que les cardinalités sont fonctions des règles de gestion définies. Une même modélisation
peut donc se voir affecter de différentes cardinalités, selon le contexte de la modélisation.
202151TDPA0116 35
Dans la figure 11, l’entité « Matériel », dont l’identifiant est « Numéro », illustre qu’un matériel
peut éventuellement être lui-même constitué d’un ou plusieurs autres matériels.
• Contraintes d’intégrité multiples : les associations dont toutes les entités participantes ont
des cardinalités maximum à N sont appelées contraintes d’intégrité multiples (CIM).
L’identifiant unique d’une CIM est la concaténation des identifiants participant à celle-ci. Ces
associations sont généralement porteuses de données et se schématisent de la sorte :
Figure 12 – Schématisation d’une CIM

Relation CIM
Entité 1 Entité 3
Code1 Code1 – Code2 – Code3 Code3
Propriétés
Entité 2
Code2
Passer de la matrice des dépendances fonctionnelles aux entités-associations

Nous venons de définir les entités et les associations. Posons-nous maintenant la question :
Comment allons-nous élaborer le schéma entités-associations en s’appuyant sur les règles de
gestion définies par la MOA et sur la matrice des dépendances fonctionnelles ou MDF ?
La MDF induira l’ensemble des entités et des CIM. Les règles de gestion aideront à compléter
les associations du schéma. Avant d’aborder les règles de passage, rappelons que deux don-
nées X et Y sont en dépendance fonctionnelle si la connaissance de la valeur de X permet
d’identifier une et une seule source de B. Par ailleurs, les lignes de la MDF recensent de façon
exhaustive les données du SI. De base, toute donnée en ligne est une donnée cible de dépen-
dance fonctionnelle. Après étude, si cette donnée est une donnée source de dépendance fonc-
tionnelle, elle est également entrée en colonne. Le passage s’effectue en trois étapes.
Étape 1 : commencer par considérer les données sources élémentaires. L’ensemble constitué
d’une donnée source élémentaire et de ses données cibles représente une entité. La donnée source
est l’identifiant de celle-ci. Les autres données cibles constituent les propriétés de cette entité.
Étape 2 : examiner ensuite les données sources issues de rapprochement de données sources
élémentaires, appelées données sources complexes. Un ensemble constitué d’une donnée
source complexe et des données cibles représente une association et plus particulièrement une
contrainte d’intégrité multiple ou CIM. La donnée source complexe constitue l’identifiant de
cette association. Les autres données cibles constituent les propriétés de cette association.
Étape 3 : revenir aux règles de gestion définies par la MOA pour compléter le schéma avec les
associations simples et toutes les cardinalités.
c. Modèle organisationnel des données (MOD)

Un MCD vise à représenter la signification des informations utilisées dans un SI. Il ne tient pas
compte des contraintes organisationnelles, économiques ni techniques. Les modèles suivants
vont donc les étudier et y apporter des réponses.
En effet, l’architecture technique des SI a fortement évoluée au fil des ans. D’une structure initiale
de type monolithique avec une totale concentration, après plusieurs évolutions, nous sommes
arrivés à une architecture poussée de type client-serveur et recourant massivement à des bases
de données relationnelles. Nous sommes donc passés d’une totale concentration des données
et des traitements à une totale répartition de ceux-ci entre des clients et plusieurs serveurs. Il est
donc devenu indispensable de devoir modéliser très tôt la répartition organisationnelle des don-
nées en prenant en compte leur volume, leur durée de vie, leur disponibilité ainsi que leur façon
d’y accéder qui peuvent se différencier significativement suivant l’organisation fonctionnelle.
Le MOD apporte des réponses à ces questions. Il s’exprime avec un formalisme identique à celui
du MCD. À ce stade, il est possible d’avoir plusieurs schémas entités-associations, à raison d’un
36
pour chaque division organisationnelle : siège social, annexes, etc., suivant que tout ou partie
des données leur soit accessible en mise à jour et/ou en consultation. Ainsi, suivant la répartition
organisationnelle, on obtiendra un MOD principal ainsi que zéro ou plusieurs MOD locaux.
Chacun de ceux-ci sera complété d’un texte décrivant les règles organisationnelles à prendre en
compte, accompagné d’un tableau recensant les catégories d’utilisateurs et leurs restrictions
d’accès aux données.
d. Modèle logique des données (MLD)

Sa construction s’appuie sur les MCD et MOD en intégrant de plus l’orientation technique rete-
nue pour la construction du SI. De nos jours, l’orientation technique la plus utilisée dans l’infor-
matique de gestion est l’orientation base de données relationnelle. Il n’est pas impossible qu’à
l’avenir les choses évoluent avec la prise en compte du Big Data qui impose de nouveaux
modèles de base de données et de ne plus pouvoir se contenter uniquement que du langage
SQL d’où le concept de NoSQL signifiant Not Only SQL et non Not SQL comme on pourrait être
amené à le penser de prime abord.
Nous avons vu qu’un MCD s’appuie sur le concept de schéma entités-associations avec des
éléments tels que : entités, associations, identifiants uniques et cardinalités. La transformation
d’un MCD en MLD passe donc inévitablement par la transformation de ces éléments. Qu’en est-
il du MOD ? Il ne faut pas perdre de vue qu’un MOD est constitué d’un MCD, complété par des
règles organisationnelles, de données volumétriques, etc. Donc, finalement, le plus important
dans cette phase est bien le passage d’un MCD en un MLD. Ce travail incombe au concepteur
de base de données et cette transition repose sur quatre règles bien précises :
• Règle 1 : toute entité est traduite en, au plus, une table relationnelle dont :
–– le nom de la table est celui de l’entité ;
–– chaque propriété de l’entité ou de la relation devient une colonne dans la table ;
–– chaque occurrence de l’entité devient une ligne de la table ;
–– la clé primaire de la table est l’identifiant de l’entité ;
–– les autres attributs de l’entité forment les autres colonnes de la table.
• Règle 2 : toute relation binaire ou n-aire dont les cardinalités de chacune des entités partici-
pantes est de la forme (0,N) ou (1,N) est traduite en une table relationnelle dont :
–– le nom de la table est le nom de la relation ;
–– la clé de la table est formée de la concaténation des identifiants de chacune des entités
participant à la relation ;
–– les attributs de la relation forment les autres colonnes de la table.
• Règle 3 : toute relation binaire dont la cardinalité de l’une des entités sont de la forme (0,1) ou
(1,1) et les cardinalités de l’autre entité participante est de la forme (0,N) ou (1,N) est générale-
ment traduite par un report de clé selon la règle suivante :
–– l’identifiant de l’entité ayant les cardinalités de la forme (0,N) ou (1,N) est ajouté comme
colonne supplémentaire à la table représentant l’autre entité. Cette nouvelle colonne est
appelée clé étrangère ;
–– une relation de cardinalité (0,N) – (0,1) (il s’agit d’un lien hiérarchique) provoque la migration
d’une clé étrangère. L’identifiant côté 0,N migre vers la table de l’identifiant côté 0,1. S’il
existe des propriétés sur l’association, elles migrent côté 0,1 ;
Figure 13 – MLD correspondant à un MCD avec un lien hiérarchique
Entité 1 0,1 Relation 0,N Entité 2

A E C
B D
Table 1 Table 2
A C
B D
C
E
202151TDPA0116 37
–– une relation de cardinalité (0,N) – (0,N) (il s’agit d’un lien maillé) donnera naissance à une
table supplémentaire. Les identifiants des entités auxquelles l’association est liée migreront
dans cette nouvelle table et la clé primaire de celle-ci sera constituée de la réunion de ces
identifiants. Si l’association contient des propriétés, elles migreront également dans la nou-
velle table.
Figure 14 – MLD correspondant à un MCD avec un lien maillé
Entité 1 0,N Relation 0,N Entité 2

A E C
B D
Table 1 Table 3 Table 2

A A C
B C D
E
Une association n-aire est gérée selon le même processus avec génération d’une table
supplémentaire.
• Règle 4 : toute relation binaire dont les cardinalités de l’une des entités sont de la forme (0,1)
ou (1,1) et les cardinalités de l’autre entité participante de la forme (0,1) ou (1,1) est générale-
ment traduite selon les deux règles suivantes :
–– on fusionne les tables des entités que la relation binaire relie pour n’en faire plus qu’une.
Cette nouvelle table contiendra les attributs de façon exhaustive et sans redondance ;
–– la clé de la table résultante sera choisie parmi les deux tables participantes. Les clés pour-
ront être soulignées afin de les distinguer des autres colonnes de la table et seront listées en
premier.
Les diagrammes d’un MLD contiennent généralement des flèches. Celles-ci n’ont pas d’autre
but que d’illustrer les reports de clés, appelées clés étrangères. Ces flèches sont uniquement là
à titre informatif. En aucun cas elles ne correspondent à un quelconque pointeur physique, les
tables relationnelles ne sont pas liées, elles sont toutes physiquement indépendantes.
e. Modèle physique de données (MPD)
Enfin, une fois le MLD finalisé, il est temps de passer à l’étape du modèle physique de données
en implémentant concrètement la base de données dans le SGBD sélectionné. Cette mise en
œuvre, cette concrétisation de la base de données, se fera selon le mode de fonctionnement du
SGBD retenu, avec les outils et l’environnement, graphique ou non, proposés par celui-ci.
Rappelons les principales règles de passage d’un schéma conceptuel entité-relation en un
schéma relationnel. Plusieurs cas sont à distinguer :
• toute entité est traduite en une table relationnelle dont les caractéristiques sont :
–– le nom de la table est le nom de l’entité,
–– la clé de la table est l’identifiant de l’entité,
–– les autres attributs de la table forment les autres colonnes de la table ;
• toute relation binaire plusieurs à plusieurs est traduite en une table relationnelle dont les
caractéristiques sont :
–– le nom de la table est le nom de la relation,
–– la clé de la table est formée par la concaténation des identifiants des entités participant à la
relation,
–– les attributs spécifiques de la relation forment les autres colonnes de la table.
Une contrainte d’intégrité référentielle est générée entre chaque colonne clé de la nouvelle
table et la table d’origine de cette clé ;
38
Figure 15 – Passage d’un MCD « plusieurs à plusieurs » à sa réalisation réelle13
Client 1,N Achète 0,N Produit

Numclient Désignation
Nom Symbole
Adresse Quantité
Client Produit
Nom Symbole
Adresse Quantité
Achat
Par De
Client
Produit
Client Produit
Numclient Nom Adresse Désignation Symbole Quantité
Achat
• toute relation binaire un à un est traduite, au choix, par l’une des trois solutions suivantes :
–– fusion des tables des entités qu’elle relie (choix 1),
–– report de clé d’une table dans l’autre (choix 2),
–– création d’une table spécifique reliant les clés des deux entités (choix 3).
Les attributs spécifiques de cette relation sont ajoutés à la table résultant de la fusion (choix 1),
reportés avec la clé (choix 2) ou insérés dans la table spécifique (choix 3) ;
• toute relation binaire un à plusieurs est traduite selon un des deux cas suivants :
–– soit par un report de clé : l’identifiant de l’entité participant à la relation côté N est ajouté
comme colonne supplémentaire à la table représentant l’autre entité. Cette colonne est par-
fois appelée clé étrangère. Le cas échéant, les attributs spécifiques à la relation sont eux
aussi ajoutés à la même table,
–– soit par une table spécifique dont les caractéristiques sont :
– le nom de la table est le nom de la relation,
– la clé de la table est l’identifiant de l’entité participent à la relation côté 1,
– les attributs spécifiques de la relation forment les autres colonnes de la table.
Figure 16 – Passage d’un MCD « un à plusieurs » à sa réalisation réelle
Service Employé
Nom 0,N Emploie 0,N Matricule
Localisation Nom
Fonction
Service Employé
Nom Localisation Matricule Nom Fonction NomSce
13. Le diagramme intermédiaire ne correspond pas à une norme. Il a été uniquement introduit à des fins
pédagogiques dans le but de faciliter la compréhension avec l’introduction des hexagones de part de
d’autre.
202151TDPA0116 39
À titre d’exemple, illustrons cela avec le SGBDR MySQL. Supposons qu’à l’issue d’une modéli-
sation Merise on doit construire la base de données UE215, dans laquelle nous aurons la table
Inscrits contenant les champs, donc les colonnes, Matricule, Prénom, Nom, Sexe et Anniversaire.
Afin d’illustrer les possibilités offertes ainsi que les divers modes de fonctionnement, nous détail-
lerons l’élaboration de cette base de données et de cette table avec l’environnement graphique
offert par MySQL ainsi que via la ligne de commandes dans la console d’administration de
MySQL.
Travailler avec la console graphique de MySQL
Figure 17 – Console graphique d’administration de MySQL

Liste des bases de données déjà Liste d’onglets permettant
existantes et sous la tutelle du SGBDR diverses commandes
En sélectionnant l’onglet Databases, à gauche de la barre d’onglets, il est possible de créer une
nouvelle base de données qui apparaît alors dans la liste des bases sous la tutelle de MySQL.
Figure 18 – Création de la nouvelle base de données, appelée UE

Liste des bases de données Liste des bases de données
existantes avant et Création de la base existantes après et
sous la tutelle de MySQL de données UE215 sous la tutelle de MySQL
La base de données
UE215 a bien été créée
Figure 19 – Création d’une table dans la nouvelle base de données

Création d’une première table et spécification
de son nom ainsi que de son nombre de colonnes
40
Figure 20 – Renseignement sur les colonnes de la table Inscrits, nouvellement créée

D’autres informations doivent être fournies comme, par exemple,
Nom de la table la longueur des champs, s’ils peuvent ou non être à Null…
Nom des colonnes Type des informations

donc des attributs de chaque colonne
de l’entité Inscrits
dans le MCD
Figure 21 – La table Inscrits est bien insérée dans la base de données UE215
La nouvelle table inscrits a bien été insérée

dans la base de données ue215
Figure 22 – Insertion d’informations dans les colonnes de la table

Figure 23 – La requête SQL est automatiquement générée et exécutée par MYSQL
MySQL a automatiquement généré et exécute la requête SQL idoine

permettant l’insertion dans la base de données des données fournies
202151TDPA0116 41
Figure 24 – Interrogation du contenu de la table inscrits
Requête SQL d’interrogation

du contenu de la table inscrits
Toutes les données entrées

sont présentes dans la table
Travailler en ligne de commande avec la console d’administration de MySQL

Figure 25 – Console d’administration de MYSQL
Création d’une nouvelle

base de données
Utilisation de cette
nouvelle base de données
Création d’une nouvelle

table dans la base
de données
Affichage de la
nouvelle table
Insertion de données
dans la table
Affichage des données

nouvellement insérées
REMARQUE
La conception d’un MCD avec bon nombre d’entités peut s’avérer particulièrement ardue.
Cela nécessite un savoir-faire que seuls des analystes professionnels chevronnés ont acquis
par l’expérience au fil du temps. De plus, certaines entités peuvent présenter des particularités
comme, par exemple, les dates qui offrent un niveau de complexité supérieur. Dès qu’une date
doit figurer dans une clé, on est très souvent dans l’obligation de créer une entité spécifique
« Date » bien qu’ultérieurement on ne traduira jamais cette entité par une table dans la base de
données relationnelle qui sera créée.
3. La notion de clé
C’est un concept fondamental. Dans une relation R, une clé candidate est un groupe d’attributs G
tel que R est déterminé par G avec la condition : ∀G’ ⊂ G, G’ ne détermine pas R. Une clé est donc
un groupe minimal d’attributs permettant de déterminer tous les autres. Chaque clé possible d’une
relation doit impérativement être clairement identifiée avant toute démarche de normalisation14.
Il doit être possible d’identifier sans ambiguïté chaque ligne de données d’une table relationnelle.
Aussi, chaque ligne doit contenir un identifiant unique appelé clé primaire. Lors de l’implémen-
tation, le terme clé primaire se rapporte à la clé candidate privilégiée. Cette notion n’intervient
en aucune façon dans l’identification de redondances.
Concernant les tables, une clé primaire est une colonne dans une table qui assure que chaque
enregistrement, donc chaque ligne, soit unique. Une clé primaire doit respecter certaines règles :
• la colonne dans une table qui sera clé primaire doit être désignée comme telle à la création
de la table ;
14. Voir en annexe la normalisation d’une relation.
42
• on utilise la clé primaire pour identifier de façon unique chaque enregistrement ; aussi, de
facto, les données contenues dans la colonne assurant le rôle de clé primaire ne peuvent en
aucun cas être répétées ;
• une clé primaire ne peut jamais avoir la valeur particulière NULL. Si ce n’était pas le cas,
comme d’autres enregistrements sont à même de contenir la valeur NULL, la clé primaire ne
serait pas unique ;
• une clé primaire doit obligatoirement recevoir une valeur quand un enregistrement est inséré.
Sans le respect de cette règle, on prend le risque de finir avec une clé primaire sans valeur
particulière et qui, par conséquent, sera mise à NULL et de dupliquer des lignes dans la table
ce qui enfreindrait la 1re forme normale. Cette dernière notion sera abordée ultérieurement,
lorsque nous aborderons la normalisation d’une relation ;
• une clé primaire doit être compacte. Elle ne doit contenir que des informations nécessaires
pour garantir son unicité et rien d’autre ;
• les valeurs d’une clé primaire ne sont pas modifiables. Si tel n’était pas le cas, le risque de
définir accidentellement une valeur déjà utilisée serait présent.
Figure 26 – Unicité de la clé primaire
Numéro de Année de Numéro de
Prénom Nom
Sécurité sociale naissance téléphone
Les valeurs de cette colonne sont Il est possible de trouver dans la table des lignes différentes
forcément uniques. Elle peut être avec des valeurs identiques. Donc, aucune de ces colonnes
retenue comme clé primaire. ne peut être retenue comme clé primaire
On distingue également d’autres types de clés :

• clé étrangère : une colonne dans une table qui référence la clé primaire d’une autre table ;
• clé étrangère auto-référencée : il s’agit d’une clé primaire dans la même table mais utilisée
par ailleurs également dans un autre but ;
• clé composite : une clé primaire composée de plusieurs colonnes créant ainsi une valeur de
clé unique.
4. Le modèle conceptuel de traitements (MCT)

Il est très souvent, pour ne pas dire systématiquement, difficile de dissocier données et traite-
ments effectués sur celles-ci. Un MCD est donc généralement associé à un modèle conceptuel
de traitements (MCT). Ce sujet dépassant le sujet de ce cours, nous laissons le lecteur désirant
explorer ce sujet se reporter aux ouvrages et sites Web spécialisés sur ce sujet.
5. Les outils
Il n’est pas réaliste de vouloir réaliser des diagrammes Merise à l’aide d’un logiciel de dessin
comme ceux que l’on utilise pour la réalisation de diapositives en vue de faire un exposé alors
qu’il existe des éditeurs dédiés. À titre informatif, nous pouvons citer : JFreeSoft qui met à dis-
position plusieurs outils spécialisés tels que : JFlux pour les diagrammes de flux, JMerise pour
les modèles conceptuels de données, JMct pour les modèles de traitement et JMot pour les
modèles organisationnels de traitements.
C. L’UML (UNIFIED MODELING LANGUAGE)

L’UML est un formalisme.
Comme son nom l’indique, l’UML est un langage. Il s’agit d’un ensemble de notations gra-
phiques en vue de créer des modèles orientés objets pour l’analyse et la modélisation de
logiciels dits « orientés objets ».
L’UML, à l’inverse de Merise, n’est donc pas une méthode. Il ne stipule en aucun cas une
démarche à suivre. Comme tout langage, il n’est qu’un moyen de décrire quelque chose. Il s’agit
d’un langage graphique de modélisation des données et des traitements.
202151TDPA0116 43
Né en 1995 de la fusion des trois principales méthodes de modélisation objet de l’époque à

savoir OMT, Booch et OOSE, l’UML n’a cessé de connaître un succès grandissant depuis sa
première publication et a connu plusieurs évolutions. Il a été standardisé en 1997 par un orga-
nisme appelé Object Management Group (OMG). Il est aujourd’hui un standard reconnu et très
largement utilisé comme notation orientée objets. Il est d’ailleurs souvent utilisé comme syno-
nyme d’orientation objet.
Aussi, commençons par aborder ce concept d’orienté objet.
1. Le paradigme objet
L’intérêt suscité par l’approche objet vient de sa capacité à décrire les entités du monde réel et
à les gérer sous une forme naturelle dans laquelle les données et les méthodes les manipulant
sont regroupées dans une même entité sémantique : la classe.
L’approche objet résulte de différentes tentatives de conciliation de deux courants de program-
mation existant : la programmation structurée dont le langage Pascal en fut un bon ambassa-
deur et la programmation dirigée par les données.
Les débuts de la programmation orientée objet datent de 1966 et se trouvent dans le langage
Simula. Dans ce langage, apparaissait déjà la notion de classe donc de structures regroupant
des données et les procédures permettant d’y accéder et de les manipuler.
Les concepts objets sont nombreux et leurs définitions ne conduisent pas toujours à un consen-
sus. On trouve quatre grandes approches selon que l’on cherche à décrire l’aspect structurel ou
comportemental des objets, que l’on cherche à décrire les associations entre objets ou les fon-
dements théoriques de l’approche objet.
Nous nous rallierons cependant à une définition qui malgré tout fait l’unanimité. Nous appelle-
rons objet tout entité du monde réel, qu’il soit concret, on peut le voir et le toucher comme, par
exemple, un ordinateur ou abstrait comme, par exemple, une structure juridique.
Un objet est caractérisé par sa structure, constituée par ses attributs ou champs, et par son
comportement, défini par ses méthodes.
Les deux concepts de classe et d’objet sont interdépendants. Tout objet est l’instance d’une
classe et toute classe permet la création d’objets de même structure et de même comportement.
Par exemple, un ordinateur qui est un objet concret peut avoir comme propriété de structure :
• la taille de son écran ;
• la puissance de son processeur ;
• sa quantité de mémoire de travail ;
• la capacité de son disque dur.
Et comme comportement :
• démarrer ;
• travailler ;
• se mettre en veille ;
• s’éteindre.
De même, une structure juridique commerciale qui est un objet abstrait peut avoir comme pro-
priété de structure :
• son statut ;
• ses dirigeants ;
• son chiffre d’affaires.
Et comme comportement :
• s’approvisionner ;
• vendre ;
• croître.
44
a. Les types d’objets

On distingue deux types d’objets :
• les objets de type atomique ou primitif sont des objets dont tous les attributs sont exclusive-
ment atomiques : entier, réel, caractère, chaîne de caractères, etc. ;
• les objets de type complexe font eux-mêmes référence à d’autres objets. Dans ce cas, l’ob-
jet est un n-uplet formé des identifiants des objets référencés. La récursivité n’est pas exclue.
L’un des objets référence peut également faire référence à un ou plusieurs autres objets.
La terminologie fait un usage intensif du terme objet mais, ce qui est élaboré en premier lieu ce
sont des classes, les objets étant des instances de celles-ci. Il faut voir une classe comme un
moule. Imaginons que nous ayons un moule dans lequel nous pouvons couler du plâtre et obte-
nir des petits personnages. Tous les personnages moulés auront la même forme. Ils seront iden-
tiques les uns des autres. Ce qui va les différencier, ce sera la façon dont on les personnalisera.
L’on peindra en bleu le pantalon de l’un alors que ce sera en rouge pour un second puis en vert
pour un troisième, etc.
Il en est de même avec les classes et les objets. Illustrons cela par un exemple.
EXEMPLE
Soit la classe élève possédant les trois attributs, prénom, nom et matricule, et ayant les quatre
méthodes, s’inscrire, passer_examen, passer_en_année_supérieure, être_diplômé. Chaque
fois que nous allons instancier cette classe, nous créerons un nouvel objet. Ainsi, par exemple,
nous pourrons, si nous le souhaitons, instancier trois fois notre classe et donc obtenir les trois
objets suivants : élève1, élève2 et élève3. Chacun d’eux aura sa propre valeur pour chacun de
ses attributs. Par exemple, pour élève1 nous aurons les attributs Pierre, Machin, 007. Mais,
tous les objets, donc toutes les instances d’une même classe, gardent en commun les
méthodes définies dans leur classe.
À ce stade de nos connaissances, il peut paraître logique de se poser la question : « Mais quel
est finalement le réel intérêt de l’approche objet ? » En effet, outre le fait d’avoir des classes que
l’on instancie pour obtenir des objets, quel est le réel intérêt ? Pour répondre à cette question,
sans entrer dans le moindre code, examinons la structure d’un programme informatique.
Un programme informatique n’est rien d’autre que la transcription dans un langage donné d’un
cheminement séquentiel d’actions, l’ensemble constituant un algorithme.
Un programme informatique commence par un début, suit une séquence d’actions et termine
par une fin. Il s’agit d’un déroulement linéaire. Dès la conception, l’ensemble de la problématique
doit être pris en charge dans sa totalité. In fine, nous obtenons une liste plus ou moins longue
d’instructions. Chaque fois qu’une modification doit être apportée à la logique implémentée, il
faut plonger dans cette liste d’instructions, porter la ou les modifications exclusivement aux
bons endroits et, bien sûr, tester que tout est conforme aux attentes. Ce type d’approche s’est
très souvent avéré problématique. Intervenir dans la liste d’instructions peut parfois se révéler
catastrophique pour le fonctionnement. Une modification portée à un certain endroit peut se
répercuter directement ou pas sur d’autres parties de la suite d’instruction, créant ainsi des dys-
fonctionnements.
b. Les classes
L’approche objet permet d’apporter une solution à cette problématique. Il n’est plus nécessaire
de prendre en charge directement la totalité de la problématique à traiter. L’approche objet per-
met une approche modulaire et descendante. Nous allons partir du général pour nous focaliser
au fur et à mesure sur le particulier.
Imaginons, par exemple, que nous ayons à traiter la gestion d’un stock d’articles divers : pro-
duits informatiques, électroménager, vaisselle, textiles, etc. Nous allons commencer à nous inté-
resser à ce qui est commun à tous les articles, indépendamment de leur nature. Quel que soit
son type, un article peut être caractérisé par : une référence, un nom, un prix unitaire hors taxe
202151TDPA0116 45
et une quantité en stock. Ensuite, nous allons nous intéresser à la catégorie des appareils élec-
triques. Que ce soit un ordinateur ou une machine à laver, il est caractérisé par : une tension, un
ampérage et une fréquence d’alimentation ainsi que par sa puissance et sa catégorie de consom-
mation d’énergie. Dans les appareils électriques, intéressons-nous à la sous-catégorie de ceux
qui ont un écran comme, par exemple, un ordinateur portable, une tablette, un Smartphone ou
encore un téléviseur. Toujours dans les appareils électriques, intéressons-nous à la sous-catégo-
rie de ceux qui ont un moteur comme, par exemple une machine à laver, une centrifugeuse ou
encore un moulin à café.
Il apparaît clairement, qu’ainsi nous isolons les problématiques les unes des autres. Nous par-
tons du général pour aller vers le particulier. Nous commençons par identifier de grands domaines
dans lesquels nous identifions des sous-domaines au sein desquels nous identifions également
des sous-domaines, etc. Nous procéderons ainsi jusqu’à converger vers des articles spéci-
fiques : l’ordinateur modèle yyy de chez xxx, la machine à laver zzz du constructeur vvv, etc.
Chaque sous-catégorie va correspondre à une classe. Mais, comment les relier entre elles ?
c. L’héritage
C’est ici qu’intervient un nouveau concept fondamental de l’approche objet : l’héritage. Par ce
mécanisme, il est possible de créer des liens entre différentes classes, créant ainsi une hié-
rarchie de classes. Une classe plus spécifique qu’une autre à laquelle elle est liée est dite
« sous-classe » de celle qui lui est plus générale. La plus générale est dite « classe mère » de
celle qui hérite d’elle. Ainsi, si nous revenons à notre exemple précédent d’articles, la classe
commune à tous les articles sera classe mère de la classe concernant les appareils électriques
ainsi que de celle concernant les textiles, etc. La classe concernant les appareils électriques est
classe mère de la classe des appareils électriques avec écran qui, par conséquent, est sous-
classe de sa classe mère, etc.
Deux types d’héritage existent : le simple et le multiple. Dans le premier, une classe hérite au
plus d’une autre classe. La figure 27 illustre un héritage simple. Dans le cas de l’héritage mul-
tiple, une classe peut hériter d’une mais également de plusieurs classes. La figure 28 illustre un
héritage multiple.
Figure 27 – Un graphe d’héritage simple
La classe A est classe mère des classes B et E.
Ces deux classes sont des sous-classes
de la classe A.
Classe A
Il en est de même pour B avec C et D Lien d’héritage
ainsi que C avec F…
Classe B
Classe C Classe D Classe E
Classe F Classe G Classe H Classe I
Figure 28 – Un graphe d’héritage multiple
Humain Bipède
Homme Pingouin
Un homme est à la fois un humain et un bipède. Aussi, la classe Homme

hérite simultanément de la classe Humain et de la classe Bipède.
46
En héritant d’une classe, on hérite de tous les attributs et de toutes les méthodes des classes en
amont dans le graphe d’héritage. Ainsi, par exemple, la classe F hérite de la totalité des attributs
et des méthodes de la classe C qui elle-même hérite de la classe B qui hérite elle-même de la
classe A. Finalement, une instance de la classe F peut accéder à tous les attributs contenus
dans les classes A, B et C et il en est de même pour les méthodes.
d. Les classes et les méthodes abstraites

Des classes peuvent jouer un rôle de réserve de données et de méthodes mais ne doivent pas
être instanciée. Si nous revenons à notre exemple d’articles, il s’agirait d’un non-sens d’instan-
cier la classe commune à tous les articles. Pour éviter qu’une classe puisse être instanciée, pour
éviter qu’un objet puisse en être créé, on déclare cette classe abstraite. Seules les classes qui
ne sont pas déclarées abstraites peuvent être instanciées.
Outre les classes, il est également possible de rendre des méthodes abstraites. Dans ce cas, le
corps de la méthode n’existe pas, seule son interface est définie. Ainsi une méthode abstraite
n’a qu’un nom, suivi d’une paire de parenthèses. Entre celles-ci peut se trouver une liste com-
posée de zéro, un ou plusieurs paramètres avec le type de chacun. Une méthode, abstraite ou
non, peut retourner zéro ou un résultat. Si un résultat est retourné, le type est mentionné. Une
classe est abstraite dès qu’elle contient au moins une méthode abstraite. Une classe qui
contient uniquement que des méthodes abstraites est appelée une interface.
Il est légitime de se demander quel est l’intérêt de ces méthodes et classes abstraites. Imaginons
que l’on développe une classe appelée « Calcul », offrant une méthode abstraite nommée
« Périmètre » et destinée, comme on s’en doute, au calcul d’un périmètre. Qu’il s’agisse d’un
rectangle, d’un cercle, d’un triangle, d’un pentagone, etc., chaque périmètre se calcule différem-
ment. Il va falloir implémenter une classe pour chacune des figures géométriques dont on va
avoir besoin. Rien n’interdirait d’avoir dans chacune de celles-ci une méthode effectuant le
calcul du périmètre mais sans aucune obligation de se nommer Périmètre. Rien n’interdirait de
recourir à des appellations telles que contour, longueur du tour, etc. En créant un lien d’héritage
entre les différentes classes que l’on va créer et la classe Calcul qui est abstraite, chaque sous-
classe devra obligatoirement surcharger la méthode Périmètre c’est-à-dire lui donner un corps
donc implémenter une méthode de calcul. Ainsi, nous aurons la garantie que chaque sous-
classe sera en mesure de recourir à une méthode Périmètre, mais dont chacune aura sa propre
méthode de calcul.
e. L’encapsulation
Un objet ne peut être manipulé uniquement que via les méthodes qui lui sont associées lors de
sa création. Les connaissances sur sa structure, ses attributs et sur son comportement, ses
méthodes, constituent la visibilité de l’objet. Il n’est possible d’accéder à l’une comme à l’autre
que via l’interface de l’objet. Un objet a la possibilité de rendre accessible aux autres objets tout
ou partie de ses attributs et de ses méthodes. Il dispose donc de différents niveaux de visibilité.
Faisons une analogie qui permettra d’illustrer ce concept de visibilité et des niveaux qui lui sont
associés. Imaginons un magasin. La zone de vente est accessible à tout le monde. La réserve
est d’un accès plus restreint. Seuls le commerçant, les livreurs et les fournisseurs peuvent y avoir
accès. Le bureau est d’un accès encore plus restreint. Seul le commerçant y a accès. Il en va de
même en ce qui concerne les niveaux de visibilité des attributs et des méthodes d’un objet.
Avant de pouvoir illustrer ces niveaux de visibilité, nous devons introduire un concept supplé-
mentaire, celui de paquetage.
f. Les paquetages et la visibilité

Il est possible dans les langages à objets, de regrouper des classes par thèmes. Par exemple, il
est possible de faire un paquetage regroupant bon nombre de classes permettant de dessiner
sur un écran tout comme de faire un paquetage de classes spécialisées dans la gestion des
connexions réseaux, etc.
202151TDPA0116 47
Figure 29 – Extrait de la liste des paquetages15 du langage Java
Trois niveaux explicites de visibilité peuvent être exprimés. Imaginons deux paquetages dis-
tincts. Dans le premier, le paquetage 1, nous avons les trois classes A, B et C. Dans le second,
le paquetage 2, nous avons les deux classes D et E. Par ailleurs, il existe des liens d’héritages
entre certaines de ces classes. Les classes B et E héritent de la classe A.
Les attributs et les méthodes de la classe A, qui ne devront pas être accédés par une autre
classe, que celle-ci hérite ou non de la classe A, devront être déclarés privés.
Les attributs et les méthodes de la classe A qui ne pourront être accessibles qu’aux classes qui
sont dans le même paquetage qu’elle ou qui en héritent, indépendamment du paquetage dans
lequel elles se situent, devront être déclarés protégés.
Les attributs et les méthodes de la classe A qui pourront être accédés par n’importe quelle autre
classe devront être déclarés publics.
15. Le langage en compte plus de deux cents.
48
Figure 30 – Illustrations des trois cas : privé, protégé et public
Classe A
Classe D
Classe B
Classe E
Classe C
Paquetage 1 Paquetage 2
Classe A
Classe D
Classe B
Classe E
Classe C
Classe A
Classe D
Classe B
Classe E
Classe C
Imaginons, par exemple, qu’une classe intervenant dans le calcul de facturation contienne l’attri-
but TVA avec la valeur en cours de cette taxe. Il est évident qu’il n’est pas envisageable qu’une
autre classe y accédant puisse modifier cette valeur. Aussi, la classe contenant cet attribut TVA
pourra avoir une méthode qui calcule le prix TTC et à laquelle on communiquera en paramètre le
prix hors taxe. L’attribut TVA sera déclaré privé alors que la méthode de calcul sera publique. Ainsi,
la méthode de calcul étant dans la classe contenant l’attribut TVA, elle seule pourra y accéder et
cet attribut sera sécurisé puisqu’il n’y a aucun risque qu’il soit modifié à partir d’une autre classe.
2. La notation UML
L’UML offre treize diagrammes normalisés différents. Il en existe également trois autres mais non
officiels. Tous sont réalisés en partant du besoin des utilisateurs. Ils peuvent être regroupés selon
deux aspects :
• les aspects fonctionnels qui permettent d’apporter des réponses aux questions Qui utilisera
le logiciel et pour quoi faire ? Comment les actions devront-elles se dérouler ? Quelles infor-
mations seront utilisées pour cela ? etc. ;
• les aspects liés à l’architecture qui permettent d’apporter des réponses aux questions Quels
seront les composants logiciels à utiliser (base de données, librairies, interfaces, etc.) ? Sur
quel matériel chacun des composants sera installé ? etc.
Ces seize diagrammes sont les diagrammes de : classe, de séquence, de cas d’utilisation,
d’état, de collaboration, d’activités, de déploiement, de relations entre entités, de communica-
tion, d’états-transitions, d’objets, de composants, d’interaction, de paquetage, de structure
composite et de temps.
202151TDPA0116 49
Seuls neuf sont importants et utilisés fréquemment. Tous ces diagrammes sont classables en
quatre grandes catégories de diagrammes : statiques, dynamiques, d’architecture et d’utilisation.
Loin de nous l’idée de tous les aborder. Nous focaliserons notre attention sur cinq : les dia-
grammes de cas d’utilisation, de classes, d’interaction, d’états-transitions et d’activités.
a. Les diagrammes de cas d’utilisation

Avant de voir les deux représentations graphiques concernant les cas d’utilisation que propose
UML, commençons par définir ce qu’est un cas d’utilisation.
Définition
On nomme cas d’utilisation une façon spécifique d’utiliser un système. Les acteurs, situés à
l’extérieur du système modélisent tout ce qui est à même d’interagir avec le système. Un cas
d’utilisation réalise un service de son commencement jusqu’à son achèvement. Pour un acteur
le déclenchant, il y a donc la séquence suivante : début, traitement et fin.
Voyons maintenant les représentations graphiques proposées par UML.
Représentation et spécification : le système à modéliser doit figurer dans un cadre dont le
nom apparaît dans la partie haute. Cette représentation permet d’isoler le système du monde
extérieur.
Figure 31 – Exemple de représentation d’un système
Distributeur automatique
Les utilisateurs ou acteurs sont représentés à l’extérieur du cadre sous la forme d’un petit bon-
homme dont le nom est inscrit dessous ou d’un rectangle contenant le stéréotype acteur et dont
le nom de l’acteur figure sous le stéréotype.
Figure 32 – Représentation d’un acteur sous les deux formes et un exemple
Rôle de l’acteur Directeur

« acteur » « acteur »
Nom Client ou Nom de l’acteur M. Machin
de l’acteur
Les cas d’utilisation peuvent se représenter de deux façons :

• par une ellipse : l’identifiant du cas, qui est un verbe d’action à l’infinitif, se situe soit dans
l’ellipse soit au-dessus. Il est possible d’ajouter éventuellement un stéréotype au-dessus de
l’identifiant, permettant ainsi d’apporter une précision supplémentaire, ainsi qu’une suite de
propriétés au-dessous du nom ;
Figure 33 – Représentation elliptique d’un cas d’utilisation et un exemple
« stéréotype »
Nom du cas
Liste de propriétés, S’inscrire
éventuellement vide
50
• par un rectangle : celui-ci comporte alors deux parties. Celle du haut contient le nom du cas
accompagné d’une petite ellipse. La partie du bas, qui est optionnelle, sert à contenir une liste
de propriétés.
Figure 34 – Représentation rectangulaire d’un cas d’utilisation et un exemple
Nom du cas
S’inscrire
Liste des propriétés
Regroupons tous ces éléments au sein d’un diagramme minimaliste d’un cas d’utilisation.
Prenons le cas d’un élève qui s’inscrit à un cours. Il doit remplir le formulaire d’inscription, payer
celle-ci, travailler et passer les examens associés. Nous obtiendrons le diagramme de cas d’uti-
lisation suivant :
Figure 35 – Diagramme minimaliste du cas d’utilisation

Cours dispensés
S’inscrire
Payer
Élève Travailler
Composer
L’ordre des cas d’utilisation dans le système n’a aucune importance. Lorsque plusieurs acteurs
figurent, la règle gérant les positionnements est d’éviter au maximum les croisements des liens
entre les acteurs et les cas d’utilisation.

Des multiplicités peuvent figurer à l’extrémité d’un cas. Le symbole * signifie plusieurs, sans
autre précision. Plusieurs autres possibilités sont possibles. Exactement la valeur n s’écrit sim-
plement n. En spécifiant une forme telle que m..n, on signifie « entre m et n ». Le minimum est
« m » et « n » le maximum.
Figure 36 – Diagramme de cas d’utilisation avec une multiplicité

Cours dispensés
S’inscrire
*
Payer
Élève Travailler
Composer
202151TDPA0116 51
➠➠Relations entre cas d’utilisation

Afin de clarifier un diagramme de cas d’utilisation, UML permet d’établir des relations entre des
cas d’utilisation. On distingue deux types de relation : dépendance stéréotypée et généralisa-
tion/spécialisation.
Dans le premier type, le nom du stéréotype indique la portée de la relation. Les deux principaux
stéréotypes utilisés sont :
• l’inclusion : un cas X est inclus dans un cas Y si le comportement décrit par le cas X est inclus
dans le comportement du cas Y. Cette dépendance se symbolise par le stéréotype include au-
dessus d’une flèche en pointillée. Par exemple, conduire un véhicule inclut que l’on ait son
permis et donc que l’on soit majeur. Les inclusions offrent également la possibilité de décom-
poser en sous-cas plus simple un cas complexe ;
• l’extension : si le comportement de X peut être étendu par le comportement de Y, on dit que
A étend B. Une extension est souvent soumise à condition. Graphiquement, une extension se
matérialise sous forme d’une note.
Figure 37 – Relations d’inclusion entre cas d’utilisations

Conduire un véhicule
Obtenir son permis « inclut »

Être majeur
S’installer au volant
Démarrer
Conducteur
Manœuvrer
S’arrêter
Figure 38 – Relation entre cas : décomposition complexe
Retrait d’une commande
Vérifier la livraison
« inclut »
Retirer sa commande
« inclut »
Client
Vérifier l’identité
➠➠Relations entre acteurs

Plusieurs acteurs peuvent figurer dans un même cas d’utilisation et, parfois, il se peut qu’il y ait
des relations entre eux. Mais, la seule relation possible entre deux acteurs est la généralisation.
On dit qu’un acteur X est une généralisation d’un acteur Y si l’acteur X peut être remplacé par
l’acteur Y.
52
Figure 39 – Relation entre acteurs
Suivre une formation
S’inscrire
« inclut »
Participer
Employé
« inclut »
Formation
ouverte
« inclut »
Autoriser
Supérieur
hiérarchique
La figure 39 illustre que le supérieur hiérarchique est un employé à même de suivre une forma-
tion mais avec un pouvoir supplémentaire, celui d’autoriser. L’employé ne le peut pas.
➠➠Regroupement des cas en paquetages

UML permet de regrouper plusieurs cas d’utilisation dans une même entité appelé paquetage.
Ce regroupement peut se faire de deux façons : par acteur ou par domaine fonctionnel.
Un diagramme de cas d’utilisation peut contenir un ou plusieurs paquetages. Un paquetage
peut lui-même contenir un ou plusieurs autres paquetages.
Figure 40 – Regroupement de cas d’utilisation en paquetages
Élève
Cours
Enseignant
Les flèches en pointillé dans la figure 40 matérialisent les dépendances entre paquetages qui
reflètent l’inclusion des cas d’utilisation.
b. Les diagrammes de classes

Ce type de diagramme est considéré comme le plus important dans la modélisation orientée
objet. Alors qu’un diagramme de cas d’utilisation présente un système du point de vue des
acteurs externes, un diagramme de classes illustre la structure interne d’un système. Il est
essentiellement constitué de classes.
Rappelons qu’une classe contient une partie statique constituée des attributs et une partie
dynamique constituée des méthodes.
202151TDPA0116 53
Un diagramme des classes ne renseigne en rien sur l’utilisation des méthodes. Il se borne à une
description purement statique d’un système. C’est le diagramme d’interactions qui informe sur
l’aspect dynamique.
Un diagramme de classes décrit les classes et leurs relations. Il peut également décrire des
regroupements de classes en paquetage, les interfaces et les objets, les classes qui réalisent à
un cas d’utilisation, etc.
Pour la création d’un diagramme de classes, il faut commencer par définir les classes et leurs
responsabilités, les paquetages et les relations (association, héritage…) possibles entre ces élé-
ments. D’autres éléments peuvent également y figurer comme les objets et les interfaces.
Nous nous limiterons volontairement qu’à l’étude des éléments indispensables pour réussir cor-
rectement une modélisation d’un diagramme de classes.
➠➠Représentation graphique d’une classe

La représentation graphique d’une classe se présente sous la forme d’un rectangle scindé en
trois parties. En partant du haut, la première zone contient le nom de la classe qui doit être signi-
ficatif et débute par une majuscule. Suit ensuite la liste des attributs de la classe. Chacun d’eux
se présente par son nom, suivi du caractère deux points « : », lui-même suivi du type de l’attri-
but. Enfin, la troisième zone contient les méthodes de la classe. Chacune se manifeste par son
nom, suivi d’une paire de parenthèses, du caractère deux points « : » et du type de donnée
retournée.
Figure 41 – Représentation d’une classe et un exemple
Élève
matricule : Integer
Nom de la classe civilite : {'F','M'}
date_nai : Date
Liste des attributs
adresse : String
Liste des méthodes
s'inscrire () : Boolean
calcul_moyenne () : Real
nb_presence () : Integer
➠➠Représentation graphique des modificateurs d’accès
Nous avons vu qu’une classe comme des méthodes peuvent être déclarées privées, protégées
ou publiques. Cette information est appelée modérateur de visibilité. Ils se représentent graphi-
quement respectivement par :
Figure 42 – Symboles graphiques des modérateurs de visibilité

Désignation Symbole graphique
Privé (private) +
Protégé (protected) #
Public (public) –
Chaque modérateur se place à la gauche du nom de la classe concernée et/ou de même, à la

gauche de chaque méthode concernée.
54
Figure 43 – Diagramme d’une classe avec des modérateurs
+ Élève
matricule : Integer
civilite : {'F','M'}
date_nai : Date
adresse : String
– s'inscrire () : Boolean
+ calcul_moyenne () : Real
+ nb_presence () : Integer
➠➠Diagramme de paquetages
Nous avons vu que plusieurs classes se rapportant à un même thème, par exemple les classes
gérant des connexions réseaux, permettant de dessiner en deux dimensions, … peuvent être
regroupées au sein d’un paquetage. Naturellement, UML offre une symbolisation graphique pour
les faire figurer dans une modélisation.
Figure 44 – Exemple d’un paquetage avec les classes contenues
Paquetage 1
Classe 1 Classe 2
+ attribut1 : Integer attribut1 : String
+ attribut2 : char – attribut2 : Boolean
– attribut3 : Real – attribut3 : Integer
# attribut4 : String # attribut4 : String
– méthode1 () : Boolean + méthode1 () : Boolean
– méthode2 () : Real – méthode2 () : Real
methode3 () : Integer methode3 () : Integer
➠➠Diagramme de classes abstraites

Nous avons vu qu’une classe peut contenir une ou plusieurs méthodes qui n’ont pas de corps
et où seul leur interface existe. UML offre une représentation graphique pour modéliser une
classe abstraite.
Figure 45 – Une classe abstraite et une classe l’implémentant
Géométrie {abstract}
Cercle
Trait : ligne
dessiner()
dessiner() {abstract}
La figure 45 modélise la classe abstraite Géométrie. Sa méthode « dessiner() » est déclarée abs-
tract, elle a donc une interface mais pas de corps. La classe Cercle, implémente cette classe
abstraite. Elle surcharge la méthode abstraite en lui donnant un corps, c’est-à-dire en définissant
le travail qu’elle doit effectuer.
➠➠Modélisation d’une interface

Rappelons qu’une interface est une classe qui ne contient que des méthodes abstraites. UML
définit deux représentations graphiques d’une interface.
202151TDPA0116 55
Figure 46 – Deux modes de modélisation d’une interface et de son implémentation

« interface »
NomInterface
ou NomClasse
NomInterface
NomClasse
➠➠Relations entre classes

Modéliser une application qui nécessite plusieurs classes, il est naturel qu’il existe des relations
entre plusieurs d’entre elles. Ces relations expriment des liens sémantiques ou structurels. Les
relations les plus fréquentes sont l’association, l’agrégation, la composition, la dépendance et
l’héritage. La quasi-totalité de ces relations sont binaires, elles relient uniquement deux classes.
Cependant, même une relation binaire entre deux classes peut faire intervenir d’autres classes.
Multiplicité : elle permet de contrôler le nombre de classes intervenant dans ce cas. Elle appa-
raît à chaque extrémité d’une relation, indiquant le nombre d’objets de la classe apparaissant à
cette extrémité pouvant s’associer à un seul et unique objet de la classe apparaissant à l’autre
extrémité.
Supposons qu’une formation est limitée à un effectif maximal de vingt personnes. La multiplicité
sera l’intervalle allant de 1 à 20.
Figure 47 – Relation d’une multiplicité allant de 1 à 20

1..20
Formation Inscrits
Agrégation : il s’agit d’une forme spécifique d’association. Elle illustre une relation d’inclusion
structurelle ou comportementale d’un élément dans un ensemble. Contrairement à d’autres
associations celle-ci est transitive.
Soit un centre de formation. Il a une à plusieurs salles de cours. Chacune de celles-ci contient
plusieurs tables. Par ailleurs, chaque salle de cours est équipée d’un vidéo projecteur. Cette
situation se modélise ainsi :
Figure 48 – Relation d’agrégation

1 1..* * *
Centre de formation Salle de cours Tables
1
Vidéo projecteur
Dépendance : il s’agit d’une relation unidirectionnelle qui exprime une dépendance sémantique
entre des éléments du modèle. Elle indique que toute modification de la cible implique de facto
la modification de la source.
Figure 49 – Relation d’indépendance
EmploisDuTemps Inscrits
Héritage : il s’agit d’une relation à la base même de la conception et de la programmation orien-

tée objets. Elle permet une approche descendante, en partant du plus général pour arriver au
plus spécifique.
56
Figure 50 – Relation d’héritage
Êtres vivants
Humains Animaux
Femmes Hommes
➠➠Modélisation d’objets
UML modélise les objets de façon identique à une classe mais qu’avec deux compartiments,
celui de son nom et celui de ses attributs. Le compartiment des méthodes est inexistant. En
effet, il n’a pas lieu d’être. Les méthodes étant identiques à toutes les instances d’une même
classe, il est inutile de les faire figurer dans chaque objet d’autant plus que dans la réalité, dans
les langages à objets, les méthodes restent dans les classes. Un objet communique avec sa
classe ainsi qu’avec d’autres objets par un envoi de message. Un objet demande à sa classe
d’exécuter telle ou telle méthode avec les valeurs des paramètres qui lui conviennent, si
paramètre(s) il y a.
Par ailleurs, contrairement au nom d’une classe, le nom d’un objet est souligné et peut être
ajouté devant le nom de la classe qu’il instancie. Chaque attribut reçoit une valeur. Quand un ou
plusieurs attributs dans un objet n’ont pas de valeur, l’objet est dit partiellement défini.
UML offre huit types différents de modélisation d’objets. On trouve les objets totalement définis,
les partiellement définis, les objets nommés, les objets anonymes avec indication de paquetage,
les objets multiples, les objets orphelins et les objets stéréotypés.
Figure 51 – Objet totalement défini et objet partiellement défini
:Ingénieur :Élève
Prénom = "Pierre" Prénom = "Pierre"

Nom = "Machin" Nom = "Machin"
Matricule = 700 Matricule = "inconnue"
c. Les diagrammes d’interaction

Un diagramme de cas d’utilisation offre une vision fonctionnelle et externe d’un système en
montrant les acteurs qui interagissent avec les grandes fonctionnalités dudit système. Un dia-
gramme de classe décrit le cœur d’un système en modélisant les classes et leurs associations.
Dans les deux cas, il s’agit d’une vision statique et structurelle d’un système.
Un diagramme d’interaction établit un lien entre l’approche des cas d’utilisation et celle des dia-
grammes de classes. Il modélise la façon dont des instances au cœur d’un système commu-
niquent afin de réaliser certaines fonctionnalités.
Les interactions sont diverses et variées. Il faut donc un langage riche pour les exprimer. Aussi,
UML propose plusieurs diagrammes dans cet objectif. Il propose les diagrammes : de séquence,
de communication et de timing. Ces trois éléments permettent une modélisation de la dyna-
mique d’un système.
➠➠Interactions
Un diagramme de cas d’utilisation illustre des interactions entre des acteurs externes avec les
grandes fonctions d’un système. Mais, les interactions ne se limitent pas qu’aux acteurs. Dans
un système, des objets interagissent également entre eux quand ils s’échangent des messages.
Les participants à une interaction sont nommés ligne de vie.
202151TDPA0116 57
Les deux principaux diagrammes offerts par UML pour la modélisation d’interactions sont le
diagramme de séquences et celui de communication. Une même interaction peut être indiffé-
remment modélisée par l’un ou par l’autre.
Un diagramme de timing est réservé à la modélisation d’un système qui s’exécute sous de
fortes contraintes temporelles. Le temps y joue une place prépondérante. On parle, dans ce cas,
de système temps réel. C’est le cas, par exemple, d’un lecteur de badge d’entrée. L’ouverture
d’une porte doit être quasi instantanée dès la présentation du badge devant le lecteur idoine.
L’un comme l’autre, ces deux diagrammes modélisent des interactions entre des lignes de vie.
Un diagramme de séquence offre une vision plus temporelle et plus spécifiquement le séquen-
cement temporel des messages échangés entre lignes de vie alors qu’un diagramme de com-
munication modélise les choses sous l’angle d’une représentation spatiale des lignes de vie.
Un diagramme d’interaction, qu’il soit de séquence ou de communication, se représente par un
rectangle contenant dans son coin supérieur gauche un pentagone accompagné du mot réservé
sd dans le cas d’un diagramme de séquence ou de com dans le cas d’un diagramme de com-
munication. Dans un cas comme dans l’autre, le mot réservé est suivi du nom de l’interaction
modélisée.
La liste des lignes de vie figurant dans l’interaction modélisée peut éventuellement suivre le nom
de l’interaction. D’autre part, des attributs peuvent être mentionnés à proximité du sommet du
rectangle contenant le diagramme. Dans ce cas, la syntaxe de ces attributs est identique à celle
des attributs dans une classe.
Les lignes de vie se représentent par un rectangle en partie haute auquel est accrochée, en par-
tie basse, une ligne verticale en pointillé. Le rectangle en partie haute contient un identifiant.
Un diagramme d’interaction se parcourt du haut vers le bas. Une ligne de temps, verticale et
implicite, part du haut du diagramme et se déroule jusqu’en bas de celui-ci.
➠ Diagramme de séquence de travail
Figure 52 – Diagramme de séquence d’un retrait d’argent à un distributeur de billets

Attribut de l’interaction Contrainte sur la valeur de l’attribut
sd Retrait argent LignesDeVie :Client :Distributeur :Banque
code : entier {lirevaleur 1000 < code < 9999}
Client :Distributeur :Banque Ligne de vie

introduire Carte
affichageEcranSaisieCode
saisirCode(code) Événement de début
saisirCode(code) d’exécution
Temps
banqueOK
Exécution d’une tâche
délivrerBillets()
prendreArgent() Message de réponse

retirerCarte()
UML, en dehors d’un message de réponse symbolisé comme dans la figure juste ci-avant, dis-
tingue deux autres types de messages : synchrone et les asynchrone. Le premier correspond au
cas où l’émetteur est bloqué tant qu’il n’a pas la réponse mais pas le second cas.
58
Un message synchrone et un message asynchrone se représentent de la même façon, à la dif-

férence de la flèche terminale, qui est fermée pour un message synchrone et ouverte pour un
message asynchrone.
Figure 53 – Message synchrone et asynchrone
Une interruption inattendue, anormale, se symbolise par une croix à une extrémité.
Figure 54 – Interruption inattendue
➠➠Diagramme de communication
Si un diagramme de séquences illustre un séquencement temporel des messages, le temps
s’écoulant de haut en bas, il ne laisse pas apparaître l’organisation spatiale des participants à
l’interaction modélisée.
Un diagramme de communication rend compte des relations entre les lignes de vie qui commu-
niquent entre elles. Il représente des interactions sous l’angle spatial. Ce type de diagramme est
le plus fréquemment utilisé dans l’illustration d’un cas d’utilisation ou dans la description d’une
opération particulière.
Figure 55 – Diagramme de communication d’une conduite automatique
Com Conduire
démarrer
unPilote : PiloteAutomatique uneVoiture : Voiture
allumer
leMoteur : Moteur
d. Les diagrammes états-transitions

Ces diagrammes décrivent le comportement interne d’un objet via un automate à états finis. On
y fait figurer les séquences possibles d’états et d’actions qu’une instance de classe peut traiter
au cours de son cycle de vie en réaction à des événements telle que l’invocation de méthodes.
Ils sont particulièrement bien adaptés à la description d’objets ayant un comportement d’auto-
mate. Mais, la vision globale d’un système est moins apparente, ils ne s’intéressent qu’à un
unique élément indépendamment de son environnement.
Enfin, ils permettent de lier entre elles des parties d’un système.
➠➠Automate à états finis

Un automate dit à états finis16 est un dispositif dont l’état des sorties n’est pas uniquement fonc-
tion de l’état de ses entrées. L’état de ses sorties tient compte de l’historique des sollicitations
précédentes. Cet historique est caractérisé par un état. Ainsi, l’effet d’une action sur un objet est
fonction de son état, qui est susceptible de varier au cours du temps.
Par exemple, considérons un dispositif muni de deux boutons poussoirs, l’un repéré « marche »
et l’autre « arrêt ». Supposons que le dispositif soit à l’arrêt. En pressant le bouton poussoir
repéré marche, le dispositif deviendra actif alors qu’en pressant celui repéré arrêt ce sera l’in-
verse. Mais, une seconde pression sur le bouton poussoir repéré marche ne produit plus aucun
effet une fois le dispositif actif. La réaction du dispositif à cet évènement est fonction de son état
interne.
16. Il existe d’autres types d’automates que ceux à états finis et plusieurs catégories parmi ceux à états finis
202151TDPA0116 59
Figure 56 – Diagramme états-transitions très simple
actif marche
marche arrêt
inactif arrêt
➠➠Points de jonction
Il est possible de faire figurer dans un diagramme états-transitions des alternatives pour le fran-
chissement d’une transition. À cet effet, deux pseudo-états particuliers peuvent être utilisés : les
points de jonction, représentés par un petit disque et les points de choix, représentés par un
petit losange vide.
Dans les deux cas, il s’agit d’artefacts graphiques permettant de partager des segments de
transition. Plusieurs transitions peuvent converger vers un même point de jonction tout comme
le quitter. Tous les chemins envisageables au travers d’un point de jonction sont valides et donc
pouvant tous potentiellement s’exécuter.
On trouve là une simplification des diagrammes en leur permettant une représentation plus com-
pacte. Sans leur présence, il est nécessaire de représenter un comportement équivalent en
créant une transition pour chaque paire de segment avant et après le point de jonction ce qui
complexifie et alourdit la lecture d’un diagramme états-transitions comme l’illustrent les deux
figures suivantes.
Figure 57 – Une modélisation sans point de jonction

état1 C1[a>0 et b<0]
C1[a état3
C1 >0 et
[a> b=0]
0e
t b>
0]
état4
<0] t b=0
]
0 et b C2[a>0 e
[a >
C2 C2[a>0 et b>0] état5
état2
Figure 58 – La même modélisation mais en recourant à un point de jonction

état1 [b>0]
C1[a>0] état3
[b=0]
état4
[b<0]
C2[a>0] état5
état2
➠➠Point de jonction dynamique

Le point de jonction en forme de losange est dit dynamique. À l’inverse d’un point de jonction
circulaire, il permet de baser un choix en fonction des résultats en franchissant le segment en
amont du point de jonction. Si une fois le point de jonction atteint aucun segment en aval n’est
franchissable, c’est que le modèle est incorrect. À l’inverse, si plusieurs segments sont franchis-
sables simultanément, l’une d’entre elles est sélectionnée aléatoirement.
La figure 59 illustre une utilisation de ce point de jonction. Après avoir renseigné un formulaire, il
doit être validé. Si les informations saisies sont correctes, une confirmation est demandée. Sinon,
le formulaire est rejeté et une nouvelle saisie doit être effectuée. Un tel fonctionnement ne peut
pas être modélisé par un simple point de jonction, un point de jonction sous forme de disque.
60
Figure 59 – Utilisation d’un point de jonction dynamique
Valider Valider saisie Saisie validée Faire

formulaire confirmer
Saisie rejetée
Informer
du rejet
➠➠Point de jonction comme alternative

Les simples points de jonction servent également à figurer une alternative. Si l’on recourt à ce
symbole pour illustrer le branchement d’une clause conditionnelle, il est conseillé d’y recourir
également pour illustrer la fin du branchement afin de rester homogène. La figure 60 illustre un
tel cas.
Figure 60 – Utilisation de deux points de jonction comme alternative

Afficher
Recherche Élève identifié information Élève
élève inscrit
Inscrire élève
Élève inexistant
Attention de ne pas assimiler le tout premier disque noir à un point de jonction. Bien que le sym-
bole soit identique, sa sémantique est tout autre. Il illustre le départ de la modélisation et non un
point de jonction.
➠➠État composite
Par opposition à un état dit simple, un état composite est graphiquement composé d’une suite
de sous-états. Tout état comme tout sous-état peut être décomposé en sous-états enchaînés
les uns aux autres. Il n’existe pas de limite dans la profondeur d’une telle décomposition.
Un tel état se représente graphiquement par les deux compartiments de nom et d’action internes
et par un compartiment contenant le sous-diagramme.
Figure 61 – État composite

Crypter un message
Début Crypter
soumettreMessage() Texte crypté
Parcourir
Préparer message
le message
Crypter
e. Les diagrammes d’activités

Ils permettent de modéliser des traitements a priori séquentiels. Leur pouvoir d’expression est
assez proche de celui des langages de programmation objet. S’ils s’avèrent bien adaptés à la
spécification détaillée de traitements en phase de réalisation, ils trouvent également toute leur
utilité dans une utilisation informelle de description d’enchaînements d’actions de haut niveau et
notamment pour la description détaillée de cas d’utilisation.
Les modèles servent en premier lieu à exprimer le fonctionnement d’un système en permettant
une vision abstraite de ses comportements. Cependant, UML 2 ne se limite pas qu’à une simple
description informelle. Il a pour vocation de permettre, à terme, d’offrir la possibilité de décrire
un système à un niveau de détails tel qu’il en permette son exécution. Ceci s’inscrit directement
202151TDPA0116 61
dans le cadre du Model Driven Architecture ou MDA, mis au point par l’Object Management
Group (OMG) qui a, entre autre, comme objectif de centrer le développement des systèmes au
niveau de leur modèle.
À terme, l’objectif est d’arriver à fournir un langage de spécification suffisamment détaillé pour
permettre de se détacher des langages de programmation. Demain, les développeurs pourront
n’utiliser qu’UML pour développer leurs systèmes sans jamais devoir descendre jusqu’au niveau
d’un langage de programmation.
Si les modèles d’activités permettent de modéliser bon nombre d’éléments proches de la pro-
grammation tels que des appels de procédures ou des traitements, ils permettent également de
modéliser des flots de contrôle. C’est uniquement sous cet aspect que nous allons aborder les
modèles d’activité.
➠ Flot de contrôle
Au sein d’un diagramme d’activité centré sur des flots de contrôle, on trouve deux éléments
fondamentaux :
• les activités, représentées par un rectangle aux coins arrondis, décrivent un traitement. Dans
ce rectangle, figure la description textuelle des actions de base réalisées par l’activité concer-
née ou uniquement son nom si le niveau de spécification n’est pas suffisamment précis pour
détailler les actions. Un flot de contrôle reste dans l’activité jusqu’à ce que les traitements
soient finis. Il est possible d’associer des variables locales à une activité ainsi que de manipu-
ler la totalité des variables, locales ou non, accessibles depuis le contexte d’une activité. Des
activités peuvent s’imbriquer hiérarchiquement les unes dans les autres. On parle dans ce cas
d’activités composites ;
• les transitions, représentées par des flèches pleines, connectent les activités entre elles. Une
activité est déclenchée dès que l’activité source est terminée et les transitions déterminent la
prochaine activité à déclencher. Contrairement aux activités, les transitions sont franchies de
façon atomique, sans durée perceptible.
Figure 62 – Extrait d’un diagramme d’activités, centré sur les flots de contrôle
Client Comptabilité Magasin
État initial
Établir devis Ligne d’eau
Passer commande Vérifier disponibilité

Sous-activité
Calculer prix Activité composite
[modifier]
Transition
Devis
Garde
[valider] Préparer commande

Valider
[annuler]
Établir facture Activité
Fork
État final
62
➠➠Structure de contrôle conditionnelle

Une façon naturelle d’exprimer des conditions est de recourir à des transitions munies d’une
garde. De telles transitions se réalisent que si la garde associée est évaluée à « vrai ». Une garde
peut être vue comme un test pouvant faire intervenir les variables accessibles depuis le contexte
de l’activité.
Il est possible d’ajouter une garde à toute transition d’un diagramme d’activité. Elle se note entre
crochets. Si plusieurs transitions sont simultanément franchissables, le choix de la transition
sélectionnée est indéterministe. Aussi, il est préférable de s’assurer qu’une seule transition à la
fois est franchissable. Enfin, il est également possible d’utiliser une clause [else] dans une garde.
Elle ne sera validée uniquement que si et seulement si toutes les autres gardes des transitions
ayant la même source sont fausses.
Il est possible de faire porter les gardes sur des transitions dont la source est une activité.
Cependant, afin de mieux mettre en valeur un branchement conditionnel, on peut recourir à un
point de jonction symbolisé par un losange. Un tel point de jonction exprime un aiguillage du flot
de contrôle. Ils peuvent posséder plusieurs transitions en entrée comme en sortie. Il s’agit d’états
dits « de contrôle » dans lequel le flot de contrôle ne s’attarde pas. Le franchissement d’une
transition entre deux activités est atomique, même lorsque l’on traverse des points de jonction.
Figure 63 – Extrait d’un diagramme d’activité avec flot de contrôle
Entrer code
[Code faux & Tentative < 4]

Vérifier code
[else]
Déconnecter
[Code correct]
➠➠Outils
Ce serait un non-sens que d’entreprendre la réalisation de diagrammes UML à la main, en s’ap-
puyant sur un logiciel de dessin comme ceux utilisés dans la réalisation de diapositives pour une
présentation alors qu’il existe bon nombre d’outils logiciels spécialisés à cet effet. Si certains
sont soumis à licence, d’autres sont issus du monde de l’open source et gratuits.
À titre indicatif, nous pouvons citer, par ordre alphabétique : ArgoUML, Astah Community, Bouml,
CodeDesigner Rad, Edge Diagrammer, Enterprise Architect, GenMyModel, Modelio, Objecteering/
UML, Open Modelsphere, Papyrus UML, Poseidon, PyUT, SAP Sybase PowerAMC 16.5 SP03,
StarUML, Visustin et Win’Design
202151TDPA0116 63
D. EXERCICES
Exercice 1 : Merise
Énoncé
TRAVAIL À FAIRE
1. Quelle interprétation donnez-vous au MCD suivant (la polygamie sera exclue) ?
0,1 0,1
Homme/Femme Est marié à Homme/Femme
2. Même question pour le MCD ci-après :
1,n 0,n
Client Commande Produit
3. Même question pour le MCD ci-après :
1,1 0,n
Homme Est fils de Femme
4. Construisez le MCD correspondant à la situation suivante, sans oublier d’indiquer les car-
dinalités :
Un professeur assure au moins un enseignement et il peut en assurer plusieurs. Une matière
peut ne pas être enseignée. Si elle l’est, elle peut l’être plusieurs fois. Chaque classe a au moins
un enseignant et peut en avoir plusieurs.
5. Même question mais avec les nouvelles règles de gestion suivante :
Tout professeur enseigne en principe au moins une matière mais certains peuvent être dispensés
d’enseignement en raison de leurs travaux de recherche. Toute matière est enseignée dans au
moins une classe. Toute classe a au moins trois enseignants.
6. Quelle interprétation donnez-vous au MCD ci-après ? De quel type de relation s’agit-il ?
Personne Est marié à
7. Quelle interprétation donnez-vous au MCD ci-après ? De quel type de relation s’agit-il ?

Citez un exemple correspondant.
Personne À vendu à Produit
8. Soit le cas suivant :

L’établissement scolaire dans lequel vous étudiez envisage de s’équiper d’un nouvel équipe-
ment informatique dans le but d’automatiser sa gestion. Sachant que :
• chaque classe a un professeur principal ;
• un même professeur peut être principal dans plusieurs classes la même année ;
• une matière dans une classe n’est enseignée que par un unique professeur ;
• chaque classe a deux délégués.
64
a. Dressez le dictionnaire des données qui vous semble convenir. Vous vous limiterez à la liste
du nom des données.
b. Dressez le MCD impliquant les entités : Élève, Professeur et Classe.
c. Dressez le MCD pour les relations : « Est élève de », « Est principal » et « Enseigner ».
⇒ Le corrigé des exercices se trouve en fin de partie.
Exercice 2 : UML17
Énoncé
UML n° 1
TRAVAIL À FAIRE
1. Soit le système informatique qui gère une station-service de distribution d’essence. Nous
nous intéressons à la modélisation de la prise d’essence par un client.
Le client se sert de l’essence selon la chronologie suivante : il prend un pistolet accroché à une
pompe et appuie sur la gâchette pour prendre de l’essence.
a. L’acteur du système est-il le client, le pistolet ou la gâchette ?
Le pompiste peut se servir de l’essence pour sa voiture.
b. Est-il un nouvel acteur ?
La station a un gérant qui utilise le système informatique pour des opérations de gestion.
c. Est-il un nouvel acteur ?
La station-service a un petit atelier d’entretien de véhicule dont s’occupe un mécanicien. Le
gérant est remplacé par un chef d’atelier qui, en plus d’assurer la gestion, est aussi mécanicien.
d. Établissez le diagramme des cas d’utilisation correspondant.
e. Que pensez-vous du diagramme de cas d’utilisation ci-après ?
Décrocher le pistolet Appuyer sur la gâchette Reposer le pistolet Payer

Client
UML n° 2
2. Modélisez à l’aide d’un diagramme de cas d’utilisation dont le fonctionnement est stipulé
ci-après. On utilisera une relation d’inclusion entre cas d’utilisation.
Une personne souhaitant utiliser le distributeur doit avoir une carte magnétique spéciale. Le prix
de la location est de 2 € de l’heure. Le retrait d’une vidéo se déroule de la façon suivante :
• le client introduit une carte magnétique spéciale ;
• il recherche la vidéo désirée ;
• Il sélectionne la vidéo désirée puis part avec.
Pour restituer une vidéo, il lui suffit d’introduire la vidéo empruntée dans le distributeur.
17. Librement adapté de UML2 – Pratique de modélisation, Benoît Charroux, Aomar Osmani, Yann Thierry-
Mieg, éditions Pearson.
202151TDPA0116 65
UML n° 3
3. Donnez une modélisation de la situation suivante :
Une personne est caractérisée par son prénom, son nom, son sexe et son âge. Les responsabi-
lités de la classe sont le calcul de l’âge, du revenu et le paiement des charges. Les attributs de
la classe sont privés alors que les méthodes sont publiques.
UML n° 4
Le chien comme le chat sont des animaux. S’ils diffèrent significativement l’un de l’autre ils pos-
sèdent cependant des propriétés communes.
4. Proposez une modélisation en faisant apparaître le partage de ces propriétés communes.
UML n° 5
Une bibliothèque propose à ses adhérents des œuvres littéraires dans plusieurs catégories.
5. Donnez le diagramme de séquence d’emprunt d’un ouvrage.
UML n° 6
Un site de vente en ligne propose des produits que le client peut placer dans son panier virtuel
au fur et à mesure de ses achats, tandis qu’il navigue. Pour valider ses achats, il lui suffit de cli-
quer sur un bouton repéré « Valider ». Il lui est alors proposé de se connecter à son compte s’il
existe ou d’en créer un dans le cas contraire.
Pour créer un nouveau compte, l’utilisateur doit fournir une adresse de messagerie qui lui servira
également de login ensuite, son adresse postale, son nom et ses coordonnées bancaires. Il
pourra indiquer une adresse de livraison si celle-ci diffère de l’adresse de facturation mentionné
précédemment. Le cas où l’adresse de messagerie indiquée serait déjà associée à un compte
existant est pris en compte. Si toutes les informations fournies sont validées, l’utilisateur se voit
proposer de se connecter à son nouveau compte. Il confirme alors ses achats.
6. Modélisez cette procédure à l’aide d’un diagramme d’activité.
UML n° 7
Un centre équestre commercialise des juments. Un acquéreur potentiel peut, à tout moment,
formuler auprès du directeur du centre une demande pour obtenir la liste des juments mises en
vente. Le directeur retourne cette liste régulièrement actualisée. Lorsque le directeur reçoit de la
part d’un client une demande d’information sur l’une d’elles, il se connecte à une base de don-
nées dans laquelle figurent les pédigrées, le carnet de vaccination, etc. Le directeur retourne
alors ces informations à l’acquéreur potentiel.
7. Donnez le diagramme de séquence correspondant à cette procédure.
UML n° 8
Soit une lampe de chevet que son utilisateur peut à foison allumer ou éteindre comme bon lui
semble.
8. a. Représentez le diagramme de séquence incluant l’allumage et l’extinction en faisant
intervenir la lampe et son utilisateur.
b. Faites intervenir comme nouveaux objets l’interrupteur et le réseau électrique et fournissez
le diagramme de séquence correspondant.
66
IV. LE BPMN
Bien que le Business Process Model and Notation (BPMN) fasse partie intégrante de la modéli-
sation, nous lui avons volontairement consacré un paragraphe. Les finalités des modélisations
BPMN se distinguent nettement des modélisations vues dans le paragraphe précédent. En effet,
il ne s’agit plus de modélisations techniques comme peuvent l’être les modélisations faites avec
la méthode Merise ou avec le langage UML. Il s’agit ici de modélisations faites dans un but de
communiquer efficacement entre différentes entités. Aussi, il nous a paru préférable de traiter
séparément le BPMN des modélisations Merise et UML.
A. LA PRÉSENTATION DE BPMN
À l’inverse de Merise et d’UML qui offrent respectivement une méthode et un langage de modé-
lisation d’un système sous un angle disons technique, BPMN propose de modéliser graphique-
ment des processus métiers dans un flux d’information au sein d’un SI. Il s’agit donc d’une
approche non plus sous un angle technique, en vue d’une réalisation ultérieure, mais d’une
modélisation des processus métiers en vue d’une communication.
L’objectif du BPMN est donc de faciliter la communication entre acteurs engagés dans le déve-
loppement et la maintenance d’un SI en favorisant l’utilisation d’un langage commun de modé-
lisation. Il permet une représentation standardisée du déroulement des processus que ce soit
pour les analystes qui produisent les premières ébauches ou pour le personnel technique chargé
de la mise en œuvre concrète. BPMN est prévu pour servir comme langage permettant de com-
bler un éventuel déficit de communication à même de survenir entre le design des processus
métier et leur implémentation.
BPMN supporte uniquement ces concepts de modélisation applicables aux processus métiers.
De ce fait, les autres types de modélisation sont en dehors de la portée de BPMN. Par exemple,
la modélisation de structures organisationnelles comme celle des répartitions fonctionnelles ou
encore des modèles de données ne font pas partie de BPMN.
Cependant, BPMN permet également de représenter des sémantiques complexes de processus.
La spécification BPMN fournit aussi une relation entre les graphiques de la notation et les concepts
sous-jacents des langages d’exécution Business Process Execution Language ou BPEL.
C’est le Business Process Management Initiative ou BPMI, qui depuis a fusionné avec l’Object
Management Group ou OMG, qui est à l’origine de BPMN. La version actuelle est BPMN 2.0. De
nombreux outils la supportent.
Ce langage bien que très proche graphiquement d’UML et plus particulièrement de ses dia-
grammes d’activité, en est éloigné sémantiquement.
Examinons un premier exemple.
EXEMPLE
Soit un site de commerce en ligne. Les commandes sont passées via un portail Web. Nous
allons modéliser l’enchaînement des actions entre le moment où une commande est récep-
tionnée et la marchandise expédiée. La chronologie des opérations est la suivante :
• à la réception de la commande, le responsable du dépôt vérifie si les articles sont dispo-
nibles ;
• si c’est le cas, la commande est validée. Sinon, si au moins un des articles commandés est
en rupture de stock, la commande est annulée et le processus se termine ;
• si une commande est validée, un magasinier prépare alors la commande. Simultanément, un
autre employé prépare en collaboration avec une compagnie d’expédition l’envoi de la com-
mande ;
• une dernière vérification est effectuée avant l’expédition afin de s’assurer que tout est cor-
recte.
202151TDPA0116 67
Figure 64 – Modélisation BPMN de l’exemple
Préparer la
Rupture commande
Traiter une commande
de stock ?
Non Vérification
Client
Réceptionner Vérifier
commande disponibilité X + Préparation + Vérifier
Démarrer Fin
Oui
Préparer
l'expédition
Fin
Nous voyons apparaître plusieurs symboles graphiques dans ce petit diagramme. BPMN en
contient de nombreux dont notamment les connecteurs logiques ET, OU sous sa forme inclusive
et exclusive ainsi que le NON c’est-à-dire la négation. Pour éviter toute ambiguïté dans leur uti-
lisation, rappelons les rôles respectifs de chacun de ces connecteurs.
B. LES CONNECTEURS
Soit l’équation logique Y = A ET B, dans laquelle les variables Y, A et B ne peuvent avoir que
deux valeurs : Faux ou Vrai. Nous allons étudier les valeurs de Y en fonction de celles de A et de
B. Pour cela, nous allons dresser ce qui est appelé table de vérité. Il en existe une pour chacun
des quatre connecteurs logiques.
Une table de vérité n’est rien d’autre qu’un tableau. À l’intersection d’une ligne et d’une colonne,
on trouve la valeur de la variable Y en fonction des valeurs des deux autres variables, celle cor-
respondant à la ligne et celle correspondant à la colonne.
1. Table de vérité du connecteur logique ET

Pour introduire le principe de fonctionnement d’un connecteur, détaillons un exemple pour le
connecteur ET. Soient les quatre propositions suivantes :
• je suis extraterrestre ET né sur Mars  Comme les deux termes qui composent la proposition
sont faux, il en est de même pour cette dernière ;
• je suis un humain ET né sur Mars  Bien que le premier terme soit vrai, comme le second ne
l’est pas, la proposition est donc fausse ;
• je suis extraterrestre ET né sur la terre  Le premier terme étant faux, bien que le second soit
vrai, la proposition de l’est pas ;
• je suis humain et né sur la terre  Les deux termes étant vraies, la proposition l’est.
Bien sûr, l’utilisation du connecteur logique ET ne se limite pas qu’à unir deux termes entre eux.
Il n’y a pas de limite au nombre de termes pouvant figurer dans une proposition.
Règle : Dans une proposition logique pouvant contenir un nombre quelconque de termes, si seul
le connecteur logique ET relie la totalité des termes entre eux, il suffit qu’un seul de ces termes
soit faux pour que la proposition le soit.
La table de vérité du connecteur ET est donc :
Figure 65 – Table de vérité du connecteur logique ET

Valeurs de la variable A
A Faux Vrai
B
Faux Faux Faux
Valeurs de la
variable B Vrai Faux Vrai
Les quatres valeurs de la vaiable Y
68
2. Table de vérité du connecteur logique OU inclusif

La forme générale avec deux variables se note : Y = A + B
Règle : Dans une proposition logique pouvant contenir un nombre quelconque de termes, si seul
le connecteur logique OU inclusif relie la totalité des termes entre eux, il suffit qu’un seul de ces
termes soit vrai pour que la proposition le soit.
Figure 66 – Table de vérité du connecteur logique OU inclusif

A Faux Vrai
B
Faux Faux Vrai
Vrai Vrai Vrai
3. Table de vérité du connecteur logique OU exclusif

La forme générale avec deux variables se note : Y = A ⊕ B
Règle : Dans une proposition logique contenant deux termes reliés entre eux par le connecteur
logique OU exclusif, la proposition est vraie uniquement si l’un des deux termes est vrai et l’autre
faux. Dans les deux autres cas, les deux termes faux et les deux termes vrais, la proposition est
fausse.
Les deux termes s’excluent mutuellement. Ils ne peuvent donc pas être « vrai » simultanément.
Par exemple, des propositions comme : Je suis présent ou absent, Je suis mort ou vivant, etc.,
en sont des exemples. Aucun des deux termes ne peut être « vrai » simultanément.
Figure 67 – Table de vérité du connecteur logique OU exclusif

A Faux Vrai
B
Faux Faux Vrai
Vrai Vrai Faux

4. Table de vérité du connecteur logique NON

La forme générale avec une variable se note : Y = NON(A) ou Y = ¬A
Règle : Dans une proposition logique contenant la négation d’un terme, si celui-ci est faux alors
la proposition est vraie et si le terme est vrai, alors la proposition est fausse. Dit autrement, la
négation du faux c’est le vrai et réciproquement.
Exemple : La négation de la condition « le client est solvable » est « le client n’est pas solvable ».
C. LES CAS D’UTILISATION

Voyons quand utiliser tel ou tel connecteur logique dans l’élaboration d’un diagramme BPMN.
Le ET : si plusieurs conditions doivent être réunies simultanément, c’est le connecteur ET que
l’on utilisera. Par exemple, pour acheter en ligne, il faut être titulaire d’une carte de crédit et être
solvable. Le connecteur logique ET se représente ainsi dans un diagramme BPMN :
Figure 68 – Représentation graphique du connecteur ET
202151TDPA0116 69
On attendra que tous les flux entrants soient actifs, donc que les conditions soient remplies,
avant de déclencher le flux sortant.
Le OU inclusif : si plusieurs conditions peuvent être réalisées mais sans obligation de simulta-
néité, c’est le connecteur OU inclusif, que l’on utilisera. Par exemple, il est possible d’acheter
tant sur le site Web d’une certaine enseigne que dans un de ses points de vente mais sans devoir
obligatoirement faire les deux. Le connecteur logique OU inclusif se représente ainsi dans un
diagramme BPMN :
Figure 69 – Représentation graphique du connecteur OU inclusif
Le OU exclusif : si plusieurs conditions peuvent être vérifiées mais pas simultanément, si elles
s’excluent mutuellement, c’est le connecteur OU exclusif que l’on utilisera. Par exemple, quand
deux modes de paiement sont proposés sur un site d’achat en ligne : à la commande et contre
remboursement, ils s’excluent de facto mutuellement. Le client est libre de choisir le mode de
paiement qui lui convient mais en aucun cas choisir les deux.
Figure 70 – Représentation graphique du connecteur OU exclusif
Le OU exclusif se dit également XOR. Il est donc logique de voir figurer la lettre X sur son sym-
bole graphique.
D. LE RÉCAPITULATIF DES PRINCIPAUX SYMBOLES

GRAPHIQUES UTILISÉS DANS BPMN
Tableau 1 – Principaux symboles graphiques
Représentation graphique Signification
Activité : On désigne ainsi tout travail à accomplir au sein d’un
processus. Une activité est consommatrice de temps, d’une ou
plusieurs ressources, nécessite un ou plusieurs objets en entrée
et en produit, un ou plusieurs en sortie. Toute activité est à même
d’être décomposée en tâche. Une tâche constitue l’unité de
décomposition la plus précise d’une action. Les activités peuvent
représenter plusieurs niveaux de détails. Quand des activités
sont combinées ensemble, elles forment un sous-processus. Le
symbole graphique est un rectangle aux coins arrondis. Dans une
modélisation les activités d’un processus ne sont généralement
pas connectées les unes aux autres.
Sous-processus : On désigne ainsi une partie d’un processus. Y
recourir dans une modélisation graphique peut permettre d’allé-
ger un diagramme mais peut, éventuellement, augmenter poten-
tiellement la complexité de la compréhension d’un système.
+ Représenté par le symbole d’une activité à l’intérieur duquel on
ajoute en partie inférieure un petit carré contenant un signe +.
Celui-ci signale que l’on peut cliquer dessus et accéder à un
niveau de détail plus important.
Tâche : C’est la plus petite unité de décomposition hiérarchique
d’une activité. C’est aussi le niveau de détail le plus bas repré-
senté dans les diagrammes. Habituellement, une personne ou
une application va réaliser la tâche.
70
Représentation graphique Signification

Passerelle : On l’utilise pour contrôler des divergences et des
convergences présentes dans des flux séquentiels d’activités ou
de tâches. Le terme de passerelle signifie l’existence d’un méca-
nisme qui autorise ou non le passage à ce niveau-là.
Il en existe de différents types comme ceux illustrés ci-avant,
dans la partie consacrée aux connecteurs logiques.
Flux séquentiel : Symbolise la chronologie selon laquelle les
activités et les tâches doivent se réaliser au sein d’un processus.
Flux de messages : Symbolise les échanges de messages, tant
en émission qu’en réception, entre deux participants.
Association : Utilisée pour illustrer des relations entre des élé-
ments graphiques tels que, par exemple, les annotations, les
données, les messages et les objets du flux.
Bassin : Symbolise un participant dans un diagramme de colla-
boration. S’il contient des détails alors il représente un proces-
Formation
sus. Sinon, il agit comme une simple « boîte noire ».
Couloir : Symbolise la division d’un processus en sous-

ensembles d’activités ou de tâches.
Formateur
Formation
Participant
Regroupement : Permet le regroupement d’éléments graphiques

appartenant à une même catégorie. Il n’a pas de conséquence
sur les flux séquentiels.
Texte descriptif : Offre le moyen d’ajouter des informations sup-
plémentaires à un modèle.
Début : Symbolise le début d’une activité ou d’une tâche. Chaque
diagramme doit obligatoirement en posséder au moins un.
Événement de départ : Il en existe plusieurs types. Chacun

d’eux symbolise un évènement susceptible de déclencher une
activité ou une tâche comme, par exemple, la réception d’un
message, une date précise ou un début de signal.
Fin : Symbolise la fin d’une activité ou d’une tâche. Chaque dia-
gramme doit obligatoirement en posséder au moins un.
Il existe un récapitulatif complet et explicatif, rédigé en français, sur ce site Web : http://
www.bpmb.de/images/BPMN2_0_Poster_FR.pdf. Nous vous conseillons de vous y
reporter.
E. LES DIAGRAMMES BPMN

BPMN, dans le but de pouvoir schématiser un processus sous différentes vues, offre quatre
types de diagrammes :
• les diagrammes d’orchestration, sous deux déclinaisons : processus privé et public ;
• les diagrammes de collaboration ;
• le diagramme de chorégraphie ;
• le diagramme de conversation.
202151TDPA0116 71
1. Les diagrammes d’orchestration
a. Processus privé
Il s’agit d’un type de modélisation permettant de schématiser un processus spécifique à une
organisation. Il permet de préciser divers éléments tels que : les sous-processus, les activités,
les tâches, les passerelles, les événements, les objets échangés, etc.
Un processus privé se modélise en adéquation avec une perspective spécifique à une organisa-
tion. Il présente la façon dont les activités comme les tâches sont réalisées en adoptant le point
de vue de celui qui va les réaliser. Aussi, il est nécessaire que les tâches modélisées le soient de
façon détaillée. On précisera chaque acteur qui réalise des tâches ou activités en les isolants
dans un bassin propre à chacun d’eux.
Les flux séquentiels des activités ou des tâches d’un processus restent systématiquement
contenus dans les limites de son bassin. Il ne sont en aucun cas autorisé à le traverser. À l’in-
verse des précédents, les flux de messages peuvent traverser les limites d’un bassin afin d’illus-
trer les interactions existantes entre des processus privés séparés.
Une illustration d’un processus privé est donnée à la figure 71.
Figure 71 – Processus privé relatif à un point de vente

Point de vente
Étudier les Recueillir Analyser les

Accueillir Venir livrer
possibilités de la satisfaction réponses
les clients le client
livraison du client du client
Début Fin
b. Processus public
Un processus public est un processus privé accompagné des interactions existants avec un ou des
participants et en définissant leurs flux de messages, leurs séquences, leurs ordres, etc. Dans le
processus public, seules figurent les activités de communication avec l’autre (ou les autres) partici-
pant. Toute autre tâche ou activité interne du processus privé sont exclues dans la représentation.
Un processus public est donc une représentation d’interactions entre un processus privé et un par-
ticipant externe : un individu, un département ou un autre processus. Un processus public ne com-
prend donc que les activités d’échange d’information et de communication avec l’autre participant.
Si un processus privé met précisément le projecteur sur les tâches effectuées dans une organi-
sation, le processus public présente précisément les interactions entre le processus privé et un
participant externe.
Figure 72 – Processus public de livraison d’une Smart TV

Point de vente
Étudier les Recueillir la Analyser les

possibilités satisfaction réponses
de livraison du client du client
Début Fin
Je serai On me demande
Je veux une Nos
sur le lieu si j’ai été satisfait Je donne
smartTV disponibilités
de la livraison de la livraison mon avis
ultra HD et 4k sont xxx
le jour J et de l’installation
Client
72
Dans cet exemple, on représente les échanges d’information entre un point de vente qui consti-
tue le participant externe et un client qui constitue le processus privé.
Le flux séquentiel de ce processus peut se décrire comme suit :
1. le client se rend dans un point de vente spécialisé pour acheter une Smart TV ;
2. le client et le point de vente fixent ensemble la date et l’heure de la livraison ;
3. le client attend le livreur et installateur le jour prévu, là où doit se faire la livraison ;
4. le client reçoit un questionnaire de satisfaction sur la prestation réalisée ;
5. le client renseigne et retourne le questionnaire qu’il a reçu.
2. Les diagrammes de collaboration

On dénomme ainsi tout type de diagramme permettant de représenter les échanges et les inte-
ractions qui existent entre deux ou plusieurs unités représentées par des bassins. Les bassins
constituent les participants de cette collaboration. Les messages qu’ils s’échangent sont pré-
sentés à l’aide du symbole flux de message. Ce symbole permet de connecter les bassins entre
eux ainsi que les objets que l’on retrouve à l’intérieur de ces bassins.
Les bassins peuvent demeurer vides, c’est-à-dire à l’état de « boîte noire » ou encore représen-
ter des processus publics. Dans ce dernier cas, les activités ou les tâches, qui relient les partici-
pants entre eux, sont considérées comme des points de contact. Les processus représentés
comme processus publics peuvent avoir plus de sous-processus, d’activités ou de tâches que
ce qui est représenté dans le processus public.
Nous avons donc les règles suivantes :
• un bassin peut être vide ;
• le flux de message relie les deux tâches ou activités lors d’une communication ;
• les échanges ou communications peuvent être tout type d’objet physique ou d’information ;
• on inscrit le nom de l’objet échangé à la racine du flux de message.
Figure 73 – Diagramme de collaboration du processus d’achat d’une Smart TV
Aller à un point
Recevoir Recevoir un Retourner le
Client
de vente Fixer un jour

le livreur questionnaire questionnaire

acheter de livraison
et installateur de satisfaction de satisfaction
Début une smartTV Fin
Point de vente
Étudier les Recueillir la Analyser

possibilités satisfaction les réponses
de livraison du client du client
Début Fin
Le diagramme de collaboration ci-avant se compose de deux processus publics : la séquence

d’activités du client et celle du point de vente. Chaque action est reliée avec l’action correspon-
dante de l’autre participant. Il s’agit de la même séquence que l’on retrouve dans le processus
public, sauf que les actions des deux participants sont coordonnées.
3. Le diagramme de chorégraphie
On appelle chorégraphie la modélisation d’un comportement prévu entre participants qui intera-
gissent les uns avec les autres et voulant coordonner leurs activités à l’aide de messages. Dans
ce type de modélisation, on ne se focalise pas sur la manière dont est accompli le travail selon
le point de vue des participants, mais sur les échanges de messages entre participants. L’élément
central de la chorégraphie est le message.
202151TDPA0116 73
Si un processus public ou privé est représenté à l’intérieur d’un bassin, une chorégraphie l’est
entre bassins. Une chorégraphie ressemble à un processus privé dans la mesure où elle se pré-
sente sous la forme d’un réseau d’activités, d’événements et de passerelles. Mais, elle en diffère
car les activités en interactions représentent des échanges de messages impliquant deux ou
plusieurs participants.
Le diagramme d’une chorégraphie illustre une description d’un comportement normal en fonc-
tion de procédures établies entre les intervenants dans un processus. Ce diagramme indique les
interactions coordonnées entre deux ou plusieurs participants. Une activité de chorégraphie
n’est jamais positionnée dans un bassin ou un couloir. Une chorégraphie peut se situer entre
deux bassins si elle coupe les flux de messages entre les bassins. Elle est alors présentée au
centre, entre les bassins et les flux de messages.
La chorégraphie illustre les communications entre deux ou plusieurs participants prenant part à une
collaboration et un message représente le contenu d’une communication entre deux participants.
Donc, une communication entre deux entités est illustrée par un flux de message les unissant.
Figure 74 – Communication entre deux entités
Client
Réservation Confirmation
Voyagiste
Au sein d’une chorégraphie, les tâches sont définies en fonction d’une communication entre
deux participants distincts. Le nom des participants est inscrit dans les symboles d’activité.
L’enveloppe blanche signifie un envoi de message et la noire signifie la réception d’un message.
L’initiateur d’une activité de chorégraphie doit être un participant de l’activité précédente. Cette
règle permet de conserver une certaine logique dans la séquence de chorégraphie.
4. Le diagramme de conversation
Ce type de diagramme schématise des échanges de messages présentés sous la forme d’un
regroupement de flux de messages, logiquement reliés entre les participants, et qui concernent
un objet d’affaires : un ordre, une livraison, une facture, etc. Il représente un ensemble de flux de
messages regroupés ensemble. Une conversation peut impliquer un nombre quelconque de
participants.
Les messages échangés sont reliés les uns aux autres et présentent différents scénarii pos-
sibles. Par exemple, dans le cas de la logistique, les messages sont reliés au réapprovisionne-
ment des stocks, à la création d’un ordre d’achat d’une entreprise de livraison, etc. Les
conversations sont symbolisées par un hexagone entre les participants.
Les bassins qui servent à la représentation d’un diagramme de conversation, ne contiennent
habituellement pas de processus et sont donc présentés vides. Aucun diagramme de chorégra-
phie ne peut être placé entre les bassins du diagramme de conversation.
Un participant, que ce soit une organisation, une unité d’affaires, un fournisseur, un client ou un
département mais rarement un simple individu est symbolisé par un rectangle. Les conversa-
tions le sont par des losanges. Il n’y a pas lieu de recourir à d’autres symboles de la notation.
Figure 75 – Symbole d’une communication

Objet de la
communication
Voyagiste Client
74
EXEMPLE
Achat de nouvelle fourniture
Une entreprise de location de matériel audiovisuel doit régulièrement se procurer de nouveaux
produits soit pour combler la demande des clients, soit pour s’assurer d’offrir de l’équipement à la
fine pointe de la technologie. Les communications de l’entreprise pourront être modélisées ainsi.
5. La démarche de construction d’une modélisation BPMN

L’élaboration d’un diagramme BPMN se déroule en plusieurs étapes selon cette chronologie :
• identifier les acteurs : chaque entité participante est un acteur ;
• définir les frontières du processus : elles sont uniquement fonction de la problématique à
modéliser. Il est donc important de se reporter avec attention au cahier des charges ;
• identifier les tâches : au sein d’un processus privé, les opérations effectuées doivent être
détaillées. Il faut donc définir les tâches des participants. Pour chaque participant, il faut iden-
tifier ses principales activités. Si une action simple est effectuée par le participant, elle peut être
représentée avec une simple tâche. Dans la première phase, il est possible d’identifier les
tâches ou activités sans aucun marqueur spécifique. Au contraire, si l’action est plus complexe,
il est préférable de la représenter comme un sous-processus. Il est important d’analyser la
nature des tâches des participants. Pendant la deuxième phase, il sera possible de substituer
les sous-processus avec des tâches et vice-versa. Cependant, il est préférable, le plus sou-
vent, d’inscrire toutes les actions en tâche et de les définir plus spécifiquement lors de la deu-
xième étape. Il est toujours plus aisé de regrouper des tâches pour en faire un sous-processus
que de définir un sous-processus puis d’en extraire ensuite les tâches qui le composent ;
• identifier et représenter les événements à l’aide des symboles appropriés : par la suite, il faut
ajouter les événements du processus. Un événement est quelque chose qui survient en cours de
processus et qui affecte la séquence d’exécution. Un événement peut se retrouver au début, à la
fin ou dans la séquence du processus. L’événement d’initialisation est souvent un besoin émis.
La réception d’une facture est un événement intermédiaire. Le processus peut se terminer pour
plusieurs raisons. Il n’est donc pas impossible que figurent plusieurs symboles de fin ;
• identifier et représenter les passerelles et les flux à l’aide des symboles appropriés : on
va établir la séquence. Pour cela, on va relier les activités et créer les points de branchements
avec les passerelles en fonction des différentes possibilités. Il est possible de répertorier les
passerelles chaque fois qu’une séquence se décompose en plusieurs chemins. Elles sont
souvent introduites à l’aide d’une expression conditionnelle comme si alors et avec des phrases
contenant des verbes tels que : peut, doit… Certaines de ces constructions indiquent implici-
tement la nature de la décision. Un terme comme pendant, suggèrent des décisions parallèles.
Il peut s’avérer utile parfois de diviser une séquence du processus en plusieurs séquences
parallèles, de choisir la voie à suivre selon le résultat d’une condition ou d’effectuer une gestion
des exceptions si des conditions particulières surviennent. Ensuite, il est possible de joindre
les éléments graphiques avec le flux normal. Cela nous donne un processus privé. On retrouve,
au sein du processus public, uniquement les tâches du processus privé qui nécessitent une
communication, une réception ou un envoi d’information ou d’un produit physique. Il est
important de s’assurer que la séquence du processus public est ordonnée, c’est-à-dire qu’elle
suit l’ordre d’exécution des tâches ;
• établir le diagramme de chorégraphie : ce diagramme illustre la façon dont les participants
échangent des informations lors de l’exécution du processus. La chorégraphie regroupe toutes
les activités de communication et d’échange entre tous les participants du processus ;
• établir le diagramme de conversation : cela nécessite que l’on modélise tous les interve-
nants comme des entités et qu’on les joigne à l’aide du symbole de la conversation que l’on
nomme en désignant le sujet principal des interactions entre ces entités. Le symbole de la
conversation représente généralement un ensemble de communications entre les deux entités.
6. Les outils
Il est inenvisageable de construire un diagramme BPMN à la main, en utilisant un logiciel de
dessin comme un de ceux qui sont utilisés pour la réalisation de diapositives lors de la
202151TDPA0116 75
préparation d’une présentation alors qu’il existe plusieurs éditeurs plus ou moins spécialisés.
Certains sont soumis à licence et d’autres gratuits, appartenant à la famille des logiciels open
source.
Dans l’ensemble des outils logiciels disponibles, nous pouvons citer : Aris Express, Bonitasoft,
BizAgi Process Modeler, Questetra BPM Suite, Tibco Business Studio, Open ModelSphere,
Process Maker.
F. EXERCICES
Exercice 3 : BPMN
Énoncé
BPMN n° 1
La société Net-Tours, spécialisée dans les voyages et circuits touristiques sur tous les conti-
nents ne possède aucun point de vente. La totalité de son offre est uniquement disponible sur le
Web. Il en est de même pour les réservations et les paiements. Du coup, sans pour autant rogner
sa marge bénéficiaire, la société, ayant des frais moindres, est en mesure d’offrir des tarifs par-
ticulièrement concurrentiels.
L’informatique en général et son SI en particulier occupent une place prépondérante chez Net-
Tours.
Régulièrement, la société Net-Tours communique avec une cellule spécialisée du ministère des
Affaires étrangères ainsi qu’avec les ambassades, ou consulats, des pays pour lesquels elle a
une offre dans le but d’être informée en quasiment en temps réel sur d’éventuels risques tant
sanitaires que d’insécurité pour offrir les meilleures conditions de sécurité à ses clients. Seules
les destinations actualisées depuis une semaine tout au plus sont accessibles, les autres sont
mises en attente d’actualisation.
TRAVAIL À FAIRE
1. Fournissez le diagramme BPMN de la mise en ligne d’une offre par la société Net-Tours.
BPMN n° 2
La société FroidChaud, spécialisée dans la distribution de boissons, possède un réseau de dis-
tributeurs automatiques de boissons de toute dernière génération, tant dans des lieux publics
comme par exemple des gares, que dans des lieux privés comme par exemple des entreprises.
Chaque distributeur est relié au site central de la société FroidChaud, soit par une liaison filaire
soit par une liaison WiFi.
Ainsi, les remontées d’alarmes en temps réel suivantes sont possibles à tout moment :
• manque d’un élément : boisson, sucre, gobelet ou cuillère ;
• manque de monnaie dans le monnayeur ;
• caisse contenant plus de X18 euros ;
• bouteille ou canette de boisson coincée.
Par ailleurs, avant d’introduire des pièces dans le monnayeur, il est possible de savoir si la bois-
son désirée est disponible. Pour cela, il suffit simplement de composer sur le clavier prévu à cet
effet, le code associé à la boisson désirée. Le message « disponible » ou « indisponible » appa-
raît alors sur un afficheur. Chaque client utilise systématiquement cette fonctionnalité avant de
sélectionner une boisson.
18. Le montant est variable selon le distributeur : d’où la valeur X.
76
Concernant la maintenance, des tournées de ravitaillement et des contrôles techniques ont lieu
régulièrement. Chaque tournée ne concerne qu’un certain nombre de distributeurs. Cependant,
un technicien peut toujours intervenir sur un distributeur situé hors de sa tournée à condition
qu’il soit proche. Ainsi, la société FroidChaud offre une qualité de service la meilleure possible.
Chaque fois qu’une boisson est consommée, son effectif dans le distributeur est décrémenté
d’une unité. Selon le type de boisson, d’autres ressources peuvent également être décrémen-
tées comme, par exemple, un gobelet, une cuillère et du sucre pour un café. Lorsqu’une quantité
passe sous un certain seuil, une alarme est automatiquement remontée au siège de la société
FroidChaud.
Ces remontées d’alarmes sur les manques de produits sont enregistrées et cumulées dans une
base de données, au fur et à mesure de leurs arrivées. Ainsi, dès qu’un seuil, fixé par la société
FroidChaud, est dépassé pour un produit19, une commande est automatiquement déclenchée
auprès du fournisseur concerné afin d’éviter une rupture de stock.
Par ailleurs, chaque dépositaire d’un distributeur de boisson reçoit une fois par an, de la société
FroidChaud, un pourcentage sur la marge bénéficiaire annuelle du distributeur hébergé. Ce
pourcentage est défini à chaque renouvellement du contrat de dépôt.
Aussi, afin d’éviter une éventuelle contestation ultérieure, au moment de la rétribution annuelle,
chaque achat d’une boisson donne lieu à un enregistrement du montant à reverser tant dans le
SI du dépositaire que dans celui de la société FroidChaud.
Ainsi, chaque dépositaire est en mesure de connaître à l’avance le montant de la rémunération
qui devra lui être attribuée et de comparer avec celle réellement perçue. En cas de contestation,
les enregistrements, qui doivent être identiques, feront foi.
Enfin, dans un souci constant d’amélioration de son niveau de qualité, de satisfaction de ses
clients et d’optimisation de ses process, l’entreprise FroidChaud a décidé de faire réaliser un
audit par le cabinet spécialisé dans lequel vous exercez votre profession.
2.  Fournissez la modélisation BPMN de l’achat d’une boisson.
V. LA PLACE DU SI
Tout manager, tout responsable d’un SI, se doit de réfléchir à comment ce système peut augmen-
ter la compétitivité, l’efficacité et la rentabilité de son entreprise. Aussi, nous allons nous intéres-
ser ici aux aspects comportementaux, aux changements que les SI apportent aux organisations
dans leurs pratiques. Nous commencerons par le rôle des SI, puis nous verrons les SI dans la
perspective managériale et les approches contemporaines de ces SI. Pour cela, nous nous
appuierons sur l’ouvrage UML2 – Pratique de modélisation (cf. Bibliographie en fin d’ouvrage).
A. L’USAGE DES TECHNOLOGIES DE L’INFORMATION

Les entreprises font un usage intensif dans de nombreux domaines d’activité des technologies
de l’information et de la communication. Les dépenses élevées ne cessent de croître régulière-
ment. Parmi toutes les utilisations certaines technologies de l’information et de la communica-
tion se détachent.
1. Le commerce électronique
Selon Médiamétrie, en janvier 2012, la France comptait 40,24 millions d’internautes soit une
hausse de près de 5 % par rapport à la même époque un an avant. Ce sont donc quasiment
72 % des Français qui sont raccordés au réseau. Cette même année, aux États-Unis, les ventes
19. Par exemple, quand il vient à manquer de café.
202151TDPA0116 77
sur Internet ont représentées 289 milliards de dollars contre 256 milliards un an avant. Une étude
du cabinet eMarketeer, publiée début 2012, prévoyait que le chiffre d’affaires global du com-
merce électronique aux États-Unis dépasserait 362 milliards de dollars en 2016.
La France n’est pas en reste. En 2014, le chiffre d’affaires du commerce en ligne atteignait
17 milliards d’euros avec un nombre d’acheteurs de 31 millions. Selon le cabinet d’études
Forester, qui a réalisé une étude du comportement des internautes dans les différents euro-
péens, la France fait partie du peloton de tête. Les internautes français se fient de plus en plus
aux achats en ligne. Si en 2005 ils n’étaient que 18 % à déclarer avoir confiance dans la sécurité
de ce type d’achat, ce chiffre est passé à plus de 25 % neuf ans après. D’après l’Observatoire
des Usages Internet, les achats de ce type dans l’Hexagone vont connaître en moyenne un taux
de croissance annuel de 6,5 % donc une augmentation plus soutenue que la moyenne de 5,5 %
en Europe de l’Ouest.
Le commerce électronique ainsi que la publicité en ligne ne cessent de croître. Le revenu des
annonces en ligne sur Google a dépassé les 20 milliards de dollars sur les six premiers mois de
2012. Malgré la crise économique déclenchée en 2008 par les subprimes, la croissance de ce
secteur est restée à deux chiffres.
2. Les communications mobiles

Depuis 2008, le nombre de nouveaux abonnés à la téléphonie mobile n’a cessé de dépasser
celui du nombre d’ouvertures de lignes fixes. De nos jours, les Smartphones, les tablettes, les
courriels et les vidéoconférences sont des outils incontournables pour les organisations.
Selon des chiffres publiés en mars 2013 par Ericsson, l’équipementier suédois en équipements
de télécommunication, au troisième trimestre 2012 le volume de données échangées par télé-
phonie mobile et sur Internet a dépassé les 900 pétaoctets20 soit plus du double par rapport au
troisième trimestre 2011 et 16 % de plus qu’au deuxième trimestre 2012. Toujours selon Ericsson,
avec la croissance du nombre d’utilisateurs et la consommation de chacun d’eux, le volume des
données transportées par les réseaux mobiles devrait continuer à doubler chaque année pen-
dant les six années à venir.
Si les ordinateurs et les tablettes dominent encore le trafic actuellement, les Smartphones
devraient, à eux seuls, représenter plus de la moitié du trafic échangé en 2018. Le taux mondial
de pénétration de la téléphonie mobile a atteint 91 % au troisième trimestre 2011. On estime
qu’il devrait y avoir 9,3 milliards d’abonnements en 2018. Les appareils mobiles et l’extension
des réseaux poussent les utilisateurs à être présents sur les réseaux sociaux sur Internet quasi-
ment en permanence. Par exemple, les utilisateurs n’arrêtent pas d’utiliser Facebook ou Twitter
parce qu’ils se mettent devant leur téléviseur. Les deux activités sont menées conjointement.
3. Les communications à destination du grand public

Alors que le nombre de lecteurs de la presse écrite ne cesse de décroître un peu partout dans le
monde, celui du nombre de lecteurs de blogs ne cesse de croître. Environ 71 millions d’Euro-
péens en lisaient un en 2009 et 21 millions en tenaient un. D’après une étude de NM Incite, le
nombre de blogs dans le monde en octobre 2001 était de 173 millions, soit 25 millions de plus
que l’année précédente à la même époque mais surtout près de cinq fois plus que cinq ans
auparavant. L’apparition et surtout l’explosion du nombre de ces nouveaux lecteurs et rédac-
teurs ont été brutales. En 2012, Facebook a attiré 900 millions de visiteurs dans le monde et
Tweeter a fêté son septième anniversaire et voit transiter plus de 400 millions de tweets chaque
jour avec plus de 500 millions d’utilisateurs enregistrés.
20. Soit 900 millions de milliards d’octets.
78
B. LA PLACE DES SI DANS UNE ORGANISATION

En 2012, à l’échelle mondiale, les entreprises ont consacré environ 1 450 milliards de dollars aux
SI en général : matériel, logiciel, etc., ces coûts ne se limitent pas qu’aux achats de composants
et de systèmes technologiques. Les mettre en place, s’y préparer, les intégrer aux systèmes
existants nécessite des compétences pointues et des budgets conséquents. Ces technologies
de l’information et de la communication impactent fortement les organisations, tous secteurs
confondus et quelle que soit leur taille. Elles doivent se réorganiser voire se restructurer pour être
en mesure de tirer profit au mieux de ces nouvelles technologies.
Les managers comme les directeurs des SI ont dû s’adapter. Ils doivent travailler dans et pour
des organisations qui utilisent de plus en plus ces technologies et y investissent également de
manière intensive. Bien sûr, chacun s’interroge sur la façon d’investir le plus efficacement pos-
sible, se demande s’il effectue les bons choix et si les résultats seront à la hauteur des investis-
sements.
Déjà les entreprises ont modifié leurs règles de fonctionnement. Elles ont cherché à anticiper les
changements dans les demandes et comportements de leurs clients. Les stocks ont été réduits
au maximum et l’efficacité des opérations logistiques renforcée autant que peu sans parler de
l’augmentation des cadences des chaînes de production et d’approvisionnement. Les entre-
prises misent aujourd’hui sur une fluidité et une synchronisation des flux pour réduire leurs coûts
de fonctionnement tout en sachant se positionner au bon moment sur chaque marché.
Avec plus ou moins de succès, les entreprises apprennent à exploiter de mieux en mieux les
nouveaux moyens de communication. Elles utilisent désormais quotidiennement les nouveaux
canaux de communications qui s’offrent à elles – Facebook, Tweeter, syndication de contenus,
flux RSS, etc. – pour communiquer et mettre en relation leurs managers, leurs clients et leurs
employés dans le monde entier.
De nouveaux métiers ont fait leur apparition dans les organisations : Webmaster, e-Community
manager, etc. Par ailleurs, l’usage des réseaux sociaux en entreprise devient de plus en plus
mature. Avec un taux d’adoption en très forte croissance, les entreprises tentent de saisir tout le
potentiel de ces nouveaux outils pour faire du Web 2.0 un élément à part entière de leur stratégie
de promotion et de communication. Les SI sont de plus en plus centraux et même vitaux pour
les organisations.
Plusieurs pays ont promulgué de nouvelles lois relatives à la sécurité et à la transparence des
actes et des comptes. Elles visent notamment l’obligation d’archiver durant un an au minimum,
mais bien souvent plus, leurs courriels, leurs sauvegardes, etc.
C. COMMENT LES SI TRANSFORMENT-ILS LES ENTREPRISES ?

L’évolution constante des technologies, leur acquisition et leur gestion ainsi que leur impact sur
les entreprises font du management des SI un des sujets les plus toniques mais également les
plus complexes de nos jours. Le recul manque parfois pour évaluer correctement, dans la durée,
l’ampleur et la nature des impacts que ces bouleversements auront sur les relations, sur les
clients, les fournisseurs, les prestataires, etc., ainsi et surtout, sur le résultat de l’entreprise.
Pour comprendre les nombreux changements apportés par ces nouvelles technologies, il ne faut
pas seulement dépasser le cadre de l’étude de chacune d’elles de façon isolée mais il faut tenter
de les mettre en relation et d’en comprendre les effets combinés, ceux-ci pouvant autant se
révéler positifs que négatifs, tant pour les organisations que pour ceux qui y travaillent.
C’est souvent une mise en synergie originale qui provoque les effets les plus intéressants. On
identifie trois grands axes :
• la consolidation des plateformes numériques mobiles : les derniers nés des ordinateurs, à
la fois tablettes et Notebook avec le clavier détachable, ces produits multifonctions, ont ten-
dances de plus en plus à se substituer aux produits mono-dédiés déjà en place et permettent
de fusionner images, sons, textes, géolocalisation et services à valeur ajoutée ;
202151TDPA0116 79
• l’émergence du Big Data : la croissance exceptionnelle du volume de données de tout type

(texte, son et vidéo) échangées sur Internet met à disposition des entreprises une manne mas-
sive d’informations. La croissance annuelle de ce volume est estimée à 5 exabites soit 5 mil-
liards de gigabits. L’exploitation de cette source de données en informations utiles devient
réaliste et donne lieu à ce qui est nommé Big Data ;
• la croissance du Cloud computing : la mutualisation coopérative de puissances de calcul se
confirme et offre des opportunités intéressantes aux organisations. De plus en plus cette utili-
sation se banalise d’autant que bon nombres des logiciels commerciaux accessibles peuvent
s’exécuter simplement via un simple accès à Internet transformant ainsi les usages et les stra-
tégies informatiques.
Grâce aux technologies dites « Web 2.0 », telles que les réseaux sociaux et les outils collabora-
tifs comme les wikis, les managers espèrent une prise de décision plus rapide et plus pertinente.
Ces plateformes mobiles les assistent dans la coordination des forces de vente et dans la ges-
tion de la satisfaction des clients. Pour bon nombre de dirigeants, il est inenvisageable de passer
une journée sans téléphone mobile ou sans connexion à Internet.
De plus en plus d’organisations non seulement adoptent directement ces dispositifs mais intègrent
leur utilisation par leurs collaborateurs dans leur stratégie informatique. Par exemple, le BYOD21
devient chose courante. Le comportement des managers change ainsi que l’organisation, la coor-
dination et la façon dont le travail est réalisé et mesuré. Les employés échangent régulièrement dans
les espaces virtuels de collaboration, même quand plusieurs fuseaux horaires les séparent. Il s’agit
d’un facteur favorisant différentes formes de déconcentrations et, parfois, de décentralisations.
Tous ces changements peuvent contribuer à créer une nouvelle mondialisation des activités et
du pilotage des entreprises. Mais ces potentialités technologiques ne sont en elles-mêmes ni
vertueuses ni toxiques. Leur utilisation massive ne doit surtout pas faire oublier les nécessaires
débats avant et pendant ces usages, débats pouvant porter, par exemple, sur la frontière entre
la vie personnelle et la vie professionnelle des collaborateurs.
D. L’ÉMERGENCE DE L’ENTREPRISE NUMÉRIQUE

Tous les changements qui viennent d’être abordés, associés à une redéfinition considérables
des modes opératoires dans les entreprises, ont créé les conditions propices à l’émergence
d’une entreprise numérique.
Les processus dits « métiers » font référence à l’ensemble des tâches et des comportements
structurés développés par les entreprises au fil du temps, afin de produire des résultats spéci-
fiques et une méthode originale et difficilement imitable à l’aide de laquelle les activités seront
organisées et coordonnées. Développer un nouveau produit, générer et répondre à une com-
mande, élaborer une stratégie commerciale et recruter des employés sont quelques exemples
de processus métier.
Dans une entreprise où les actifs clés sont massivement gérés via le numérique, appelée « entre-
prise numérique », toutes les informations clés utiles à la prise de décision sont disponibles en
tout lieu et en tout temps. Aussi, ces entreprises ont la faculté de comprendre et de répondre à
leur environnement plus rapidement que les entreprises traditionnelles. De plus, dans les entre-
prises numériques, le décalage dans le temps et dans l’espace est devenu la norme. Le
décalage dans le temps fait référence aux entreprises actives en continu, 24h/24 et 7j/7,
contrairement à la journée de travail habituelle. Le décalage dans l’espace signifie que le travail
se déroule sur un site inséré dans une logique mondialisée au-delà des frontières nationales.
Si toutes les entreprises ne sont pas aussi avancées, elles évoluent cependant vers une intégra-
tion significative du numérique dans les relations avec leurs fournisseurs, leurs clients et leurs
employés. Un grand nombre d’entre elles privilégient les réunions virtuelles à l’aide de la vidéo-
conférence, au détriment des traditionnelles réunions en face à face.
21. Bring Your Own Machine.
80
E. LES OBJECTIFS STRATÉGIQUES DES SI

Les SI sont, de nos jours, indispensables dans la gestion quotidienne des organisations. Ils se
révèlent tout aussi essentiel pour la réalisation des objectifs stratégiques des entreprises. Il faut
donc combiner les contributions opérationnelles et stratégiques.
Des pans entiers de nos économies, comme, par exemple, les entreprises bâties autour des
potentialités du commerce en ligne, seraient aujourd’hui inconcevables s’ils ne bénéficiaient pas
d’investissements significatifs dans les SI. Aujourd’hui, les industries du secteur tertiaire (finance,
assurance, service à la personne, etc.) comme celles spécialisées dans la vente au détail et dans
la production ont besoin des SI pour survivre et prospérer. Tout comme les bureaux, le télé-
phone, les placards à archives, les locaux spacieux et fonctionnels constituaient la partie visible
des entreprises du xxe siècle, les systèmes et technologies de l’information sont un des éléments
fondamentaux et structurants de l’entreprise du xxie siècle.
L’interdépendance est de plus en plus forte entre la capacité d’une entreprise à utiliser les tech-
nologies de l’information et celle à mettre en œuvre des stratégies et à atteindre ses objectifs.
Par exemple, ce qu’une entreprise envisagera de réaliser dans cinq ans dépendra fortement de
ce que ses systèmes seront capables de supporter et permettront de faire. Augmenter sa part
de marché, devenir un producteur haut de gamme, développer de nouveaux produits, etc. ; voilà
autant d’éléments qui dépendront de plus en plus de la performance du SI dont disposera l’en-
treprise et de la qualité des usages qu’elle en fera. Plus un manager comprendra cette relation
et plus efficient il sera.
Plus spécifiquement, les entreprises investissent en masse dans les SI dans le but d’atteindre
principalement sept objectifs stratégiques : excellence opérationnelle, raccourcissement des
délais de mise sur le marché de nouveautés, développement de services innovants, création de
rapports privilégiés et très réactifs avec le client et les fournisseurs, amélioration de la rapidité de
la prise de décision, création de nouveaux avantages compétitifs, amélioration de la robustesse
et des capacités de survie.
De nos jours, l’interdépendance est de plus en plus marquée entre le SI d’une organisation et ses
capacités commerciales et logistiques. Les changements de stratégie, les règles et les proces-
sus métier nécessitent de plus en plus souvent des évolutions adaptatives voire intégrales des
infrastructures matérielles et logicielles, des bases de données, des réseaux informatiques…
F. LES RAISONS DE L’EXISTENCE DES SI INFORMATISÉS

De nos jours, la culture managériale est pleinement axée sur Internet et ses répercussions sur le
monde des affaires sont considérables. Les managers utilisent Internet autant pour communi-
quer via le courrier électronique que pour accéder aux informations en temps réel. Par ailleurs,
les outils toujours plus nombreux, plus mobiles et plus performants rendent le travail des salariés
mobiles très réactifs.
Les technologies de l’information sont les composantes de nature technique que les entreprises
achètent ou développent et qu’elles combinent pour constituer une infrastructure technologique
qui enrichira leur SI et lui permettra de fonctionner de façon optimale. Sur le plan de l’étude de
l’informatisation des organisations, la notion de SI englobe donc celle des technologies de l’in-
formation. Aussi, habituellement, on ne parle de technologie de l’information que lorsqu’il doit
être fait référence à l’unique dimension technologique de l’infrastructure d’un SI.
Les SI jouent un rôle primordial qui ne cessera de croître pour trois raisons principalement :
• fonctionnement et existence : le développement de nombreuses entreprises, voire leur exis-
tence même, est inconcevable sans un recours massif aux SI. Des entreprises comme Google
ou Amazon, par exemple, n’existeraient même pas. Aujourd’hui, le secteur des services ne
peut fonctionner sans SI et ce n’est pas l’unique secteur dans cette situation ;
• productivité : un investissement dans le domaine des SI participe de façon tangible à l’aug-
mentation de la productivité des entreprises ;
202151TDPA0116 81
• possibilités et avantages stratégiques : pour profiter des opportunités du marché et y

répondre par de nouveaux produits et services, des investissements substantiels dans les SI
peuvent s’imposer. Combinés à des changements dans les exigences et les pratiques mana-
gériales, ces SI contribuent à fournir un avantage stratégique concurrentiel.
G. LES LIMITES DE L’IMPORTANCE DE LA TECHNOLOGIE DE L’INFORMATION

Puisque toutes les organisations ont accès aux SI et aux mêmes technologies, elles peuvent
aisément acheter les mêmes dispositifs, se copier entre elles et librement utiliser ces produits qui
se fondent sur des normes communes telles qu’Internet, par exemple. Aussi, les SI ne consti-
tuent plus un véritable facteur différenciateur dans les performances.
Aujourd’hui, une entreprise ne peut recourir aux SI pour en tirer un avantage stratégique par
rapport à ses concurrents, tout comme elle ne peut le faire avec l’électricité ou le téléphone. Les
entreprises doivent donc être plus sélectives et minimiser leurs dépenses relatives aux SI, suivre
les tendances plutôt que d’innover, réduire les risques en se préparant aux pannes informatiques
et aux problèmes de sécurité et éviter de déployer inutilement de nouvelles technologies du seul
fait de leur caractère innovant.
Cette analyse fait débat au sein de la communauté des spécialistes en SI. Des recherches sou-
lignent de grandes disparités dans l’utilisation efficace des SI par les entreprises. Des sociétés
arrivent à obtenir durablement d’excellents résultats de leur investissement dans les SI mais il
est impossible de généraliser.
À puissance et capacité constantes, les prix du matériel informatique et des logiciels baissent et
les nouvelles normes dans le domaine de l’informatique et des télécommunications facilitent
l’utilisation des ordinateurs et leurs interconnexions. Pour autant, cela ne signifie pas la fin des
différenciations stratégiques positives accessibles via une mobilisation intelligente et originale
des SI. Au contraire, la banalisation génère souvent un regain de créations, de nouveaux mar-
chés et produits.
Ce qui est certain, c’est que ce ne sont pas les investissements en SI qui donnent en eux-mêmes
des résultats ou qui ont une valeur stratégique. Certains sont simplement nécessaires pour se
maintenir sur un marché, satisfaire aux exigences réglementaires et légales ou encore répondre
aux besoins des clients et des fournisseurs.
Pour obtenir un certain succès, les investissements dans les SI doivent s’accompagner de chan-
gements significatifs dans les opérations et les processus, de même que dans la philosophie, les
attitudes et les comportements managériaux, sous peine de n’être qu’un gaspillage de res-
sources financières, humaines et techniques.
H. LES SI DANS LA PERSPECTIVE MANAGÉRIALE

Les entreprises qui investissent dans les systèmes et la technologie de l’information en attendent
une valeur économique réelle. La mise en place ou l’amélioration d’un SI suppose que les résul-
tats obtenus seront conformes aux attentes. Cette efficience de rendement pourra se traduire
par une augmentation significative de la productivité, des revenus ou encore par un meilleur
positionnement stratégique à long terme.
Il arrive également que des organisations investissent dans des SI pour se mettre en conformité aux
obligations légales ou aux impératifs environnementaux. Par exemple, une entreprise devant
répondre aux exigences des lois encadrant les opérations des sociétés cotées en Bourse peut éla-
borer un système de gestion électronique des documents qui suit les flux des documents utilisés.
Dans certains cas, les organisations doivent investir dans les SI pour survivre. Par exemple, les
banques sont obligées d’investir dans des réseaux de guichets automatiques et offrir des ser-
vices bancaires complexes accessibles en ligne ce qui nécessite des investissements technolo-
giques substantiels uniquement pour ne pas perdre leur clients d’autant plus si leur principaux
concurrents le font.
Un SI peut donc constituer un instrument clé de production de valeur s’il permet à une organi-
sation d’augmenter de façon substantielle ses revenus et/ou de diminuer ses coûts tout en
82
fournissant des informations permettant aux managers de prendre les meilleures décisions aux
meilleurs moments.
Chaque organisation est dotée d’une chaîne de valeur de l’information dans laquelle les données
brutes y sont collectées et stockées puis, ensuite, transformées lors de diverses étapes de trai-
tements qui leur donnent du sens, donc de la valeur. Un SI constitue donc une solution d’orga-
nisation et de gestion à un défi que se pose une organisation et/ou à un problème posé par
l’environnement. Cette solution se construit sur les technologies de l’information.
Pour bien comprendre les SI, un manager doit saisir l’ensemble de leurs dimensions qui se rap-
portent à l’organisation, à la gestion et à la technologie de l’information, ainsi que la façon dont
ils fournissent des solutions aux problèmes posés par l’environnement de l’entreprise. Il n’est
pas exceptionnel de désigner par « culture des systèmes d’information » cette compréhension
globale des SI qui correspond à la connaissance des aspects de gestion et d’organisation des
systèmes, ainsi que de leurs dimensions techniques. Il s’agit d’une approche à la fois compor-
tementale, sociétale et technique par opposition à la « culture informatique » qui ne met l’accent
que sur les connaissances relatives aux technologies de l’information.
I. LES DIMENSIONS DES SI

Portons notre attention sur les dimensions organisationnelles et managériales des SI :
• les organisations : le personnel, la structure, les processus opérationnels et la culture sont les
éléments clés de toute organisation. Les SI font partie intégrante de l’organisation ainsi que de
la structure.
Outre les managers, dans une entreprise, on trouve différentes catégories de collaborateurs.
Les spécialistes de la connaissance tels que des ingénieurs et/ou des chercheurs, conçoivent
des produits ou des services. Les employés administratifs, tels que les secrétaires, comp-
tables, etc., travaillent à partir de données et de documents et en génèrent d’autres. Les
employés de production et des services logistiques fabriquent les produits et/ou délivrent les
services proposés par l’entreprise.
Chaque organisation a une culture d’entreprise, c’est-à-dire un ensemble fondamental de pos-
tulats, de règles, de valeurs et de savoir-faire que les membres de son personnel acceptent.
Certaines parties de cette culture peuvent se trouver dans le SI comme, par exemple, des
démarches qualité sur les services aux clients ;

• le management : à partir des défis concurrentiels et des objectifs fixés aux managers par les
instances décisionnaires, les dirigeants élaborent une stratégie puis affectent les compétences
et ressources humaines, financières et techniques pour la mettre en œuvre jusque dans l’orga-
nisation et la coordination opérationnelles. Outre la gestion courante de l’entreprise, les mana-
gers doivent créer de nouveaux produits et services ainsi que repenser régulièrement
l’organisation de l’organisme. Les SI jouent un rôle essentiel dans la mise en œuvre d’une
« reconception » de l’organisation.
Les responsables tiennent des rôles différents et prennent des décisions qui varient selon leur
niveau hiérarchique. Les cadres dirigeants prennent les décisions stratégiques à long terme au
sujet des produits et services que l’entreprise propose et devra proposer sur le marché. Les
cadres intermédiaires exécutent les programmes et les plans élaborés par les cadres diri-
geants. Les cadres opérationnels sont responsables du fonctionnement des activités opéra-
tionnelles de l’entreprise. Les besoins d’information sont spécifiques à chaque niveau de
gestion, lequel exprime diverses exigences en matière de SI. Cette segmentation hiérarchique
des rôles est un cadre général classique d’analyse mais, selon la taille de l’entreprise ou les
visions opérationnelles des dirigeants, elle peut être plus ou moins remise en question.
J. LES ACTIFS COMPLÉMENTAIRES ET LE CAPITAL ORGANISATIONNEL

Les dimensions organisationnelles et managériales des SI aident à comprendre pourquoi les SI
de certaines organisations donnent de meilleurs résultats que d’autres. Certaines organisations
investissent beaucoup et obtiennent d’excellents résultats tandis que d’autres investissent tout
autant mais pour peu de résultat. D’autres, encore, investissent peu et ont d’excellents résultats
202151TDPA0116 83
ou investissent peu mais n’obtiennent que peu. L’investissement dans les SI n’est donc pas
obligatoirement une garantie de bons résultats. Il est légitime de se demander pourquoi.
Les organisations comme les managers doivent être soutenus au sein de l’organisation par des
valeurs et des structures favorables ainsi que par des modèles de comportement et d’autres
actifs complémentaires. Les investissements limités aux SI ne suffisent pas à eux seuls à rendre
les organisations plus efficaces. La réponse à la question « Pourquoi ? » posée précédemment,
se trouve donc en partie dans le concept d’actifs complémentaires.
Les actifs complémentaires sont les actifs nécessaires pour tirer de la valeur d’un investissement
primaire. Par exemple, pour tirer de la valeur des Smartphones, il a fallu réaliser des investisse-
ments complémentaires considérables dans les réseaux téléphoniques, dans un couverture
internationale avec la mise en place de satellites de télécommunication, dans des points de
ventes, dans des formules d’abonnement, dans le développement, la commercialisation et la
distribution d’applications à installer sur ces Smartphones… Il ne suffit donc pas simplement
d’investir massivement dans un SI ou dans une nouvelle technologie pour obligatoirement récol-
ter de bons résultats.
K. LES NOUVELLES POSSIBILITÉS

Les SI offrent de nombreuses possibilités intéressantes aux entreprises mais sont également
source de problèmes, questions et défis.
Alors que les technologies de l’information évoluent rapidement, l’installation et l’utilisation des
SI ne sont ni simples ni mécaniques. Les gestionnaires doivent relever six grands défis :
• défi de l’investissement : « Comment les organisations peuvent-elles générer de la valeur à
partir de leur SI ? » Comme nous l’avons vu, il est essentiel de considérer les SI comme des
investissements potentiellement créateurs de valeurs pour une organisation. Cependant,
toutes les entreprises n’obtiennent pas obligatoirement de bons rendements de leurs investis-
sements dans ces SI ;
• défi de l’évaluation : « Comment peut-on évaluer les investissements dans les SI, qui par
nature sont immatériels, comme les dirigeants le font pour leurs autres investissements ? »,
« Le capital investi dans le SI, produit-il le retour escompté ? » Trop d’organisation ne sont pas
en mesure de répondre à de telles questions. Bien trop souvent, elles ne disposent pas de
procédures de décision clairement définies pour être à même de décider de leurs investisse-
ments dans les technologies de la communication et en évaluer les retours réels obtenus ;
• défi stratégique : « Quels sont les actifs complémentaires dont les entreprises ont besoin
pour utiliser efficacement leur SI ? » La puissance ainsi que les possibilités offertes tant par le
matériel que par les logiciels ont augmenté bien plus rapidement que les capacités des orga-
nisations à les adopter, à les intégrer et à en tirer pleinement profit. L’ensemble du personnel
doit modifier ses comportements ainsi que ses méthodes de travail. Il faut éliminer les proces-
sus et les structures organisationnelles quand ils sont inefficaces et/ou dépassés et en élabo-
rer de nouveau en lieu et place ;
• défi de la mondialisation : « Comment les organisations peuvent-elles intégrer et combiner
les exigences concurrentielles et les potentialités des SI dans une économie mondiale ? » La
croissance rapide du commerce international et la naissance d’une économie mondialisée
requiert des SI capables de soutenir la production et la vente de biens et services dans diffé-
rents pays. Jadis, les bureaux régionaux des multinationales se concentraient sur leurs propres
problèmes d’information. Cette situation était souvent à l’origine d’incohérences et de pro-
blèmes au niveau du management global vu les différentes langues, cultures et politiques entre
pays. Pour élaborer et mettre en place des SI multinationaux, les organisations doivent établir
des normes internationales techniques, ce qui conduit à une homogénéisation des moyens,
organisationnelles et fonctionnelles, en décidant de processus et de structures de données
internationaux cohérents ;
• défi de l’infrastructure : « Compte tenu des évolutions rapides des contextes et des conjonc-
tures économiques comme des technologies ; comment les organisations peuvent-elles éla-
borer et mettre en place une infrastructure de technologie de l’information qui soutienne et
favorise de façon durable et robuste la poursuite de leurs objectifs ? »
84
Bon nombre d’organisations se trouvent face à des infrastructures techniques coûteuses et

lourdes, inadaptées aux innovations et aux changements. Leur SI est parfois si complexe et si
fragile qu’il nuit à l’accomplissement de leur stratégie et à leurs opérations quotidiennes.
Pour relever de nouveaux défis sur les plans de la gestion et de la technologie, il peut s’avérer
nécessaire de disposer d’une infrastructure de SI totalement nouvelle. Créer l’infrastructure
idoine d’une organisation hautement informatisée constitue un important défi technique, finan-
cier, logistique et humain.
Bon nombre d’organisations sont handicapées par leur SI constitué de matériels informatique,
de logiciels et de réseaux de télécommunications incomplets, obsolètes et incompatibles
entre eux, ce qui nuit, voire interdit, une circulation fluide de l’information entre différentes par-
ties de l’organisation ;
• défi de la responsabilité : « Comment les organisations peuvent-elles s’assurer que leur SI
est utilisé de façon éthique et responsable ? » Les SI ont permis des résultats positifs et tan-
gibles, mais ils sont également la source de nouveaux problèmes et défis tant d’ordre éthique
que social tels que, par exemple, la menace au droit du respect de la vie privée ou encore de
la propriété intellectuelle. Il est nécessaire de concevoir des SI que les utilisateurs peuvent
comprendre et contrôler.
Les managers doivent sans cesse intervenir pour maintenir la sécurité et le contrôle. Les menaces
d’intrusion et/ou de perturbation du SI sont de plus en plus réelles, de plus en plus importantes,
de plus en plus prégnantes. Les SI sont devenus tellement essentiels aux organisations qu’il est
indispensable de prendre des mesures spéciales pour assurer leur protection, le maintien de leur
efficacité, leur exactitude et leur fiabilité. Une organisation dont le SI est à même d’être envahi et
corrompu par des pirates informatiques ou encore ne pas être en mesure de fournir des données
sous une forme correctement exploitable cour simplement à sa perte.
VI. CORRIGÉ DES EXERCICES DE LA PARTIE 1
Exercice 1
Corrigé
1. Quelle interprétation donnez-vous au MCD suivant (la polygamie sera exclue) ?
0,1 0,1
Homme/Femme Est marié à Homme/Femme
Un homme peut ne pas être marié, l’être à une femme ou à un autre homme et réciproquement
pour une femme, d’où la cardinalité minimale « 0 » de part et d’autre de la relation « Est marié
à ». Mais, s’ils sont mariés, ils ne le sont qu’au plus à une personne, la polygamie étant exclue,
d’où la cardinalité maximale « 1 » de part et d’autre de la relation.
2. Même question pour le MCD ci-après :
1,n 0,n
Client Commande Produit
Un client commande au moins un produit sinon il n’est pas client, d’où la cardinalité minimale
« 1 » du côté de l’entité « Client ». Mais, il peut également en commander plusieurs, autant qu’il
le désire, d’où la cardinalité maximale « n » du côté de l’entité « Client ». Pour un produit, rien
n’oblige à ce que quelqu’un le commande, il peut ne jamais être commandé, d’où la cardinalité
minimale « 0 » du côté de l’entité « Produit ». À l’inverse, rien n’interdit que le produit connaisse
un succès et qu’il soit commandé plusieurs fois, d’où la cardinalité maximale « n » du côté de
l’entité « Produit ».
202151TDPA0116 85
3. Même question pour le MCD ci-après :
1,1 0,n
Homme Est fils de Femme
Un homme est au moins le fils d’une femme, d’où la cardinalité minimale « 1 » du côté de l’entité
« Homme » mais il ne l’est également au plus que d’une femme. Aucun homme ne peut avoir
plus d’une génitrice. D’où la cardinalité maximale « 1 » toujours du côté de l’entité « Homme ».
Concernant l’entité « Femme », une femme peut ne pas avoir d’enfant, d’où la cardinalité mini-
male 0 mais rien ne lui interdit d’en avoir plusieurs d’où la cardinalité maximale de n.
4. Construisez le MCD correspondant à la situation suivante, sans oublier d’indiquer

les cardinalités : un professeur assure au moins un enseignement et il peut en assu-
rer plusieurs. Une matière peut ne pas être enseignée. Si elle l’est, elle peut l’être
plusieurs fois. Chaque classe a au moins un enseignant et peut en avoir plusieurs.
0,n
Matière
1,n
Professeur Enseigne
Classe
1,n
Comme les règles de gestion stipulent qu’un professeur doit assurer au moins un enseignement,
nous avons donc la cardinalité minimale « 1 » et comme il peut également en assurer plusieurs,
nous avons donc la cardinalité maximale « n » du côté de l’entité « Professeur ». De même, les
règles de gestion stipulent qu’une matière peut ne pas être enseignée, d’où la cardinalité mini-
male « 0 » et qu’elle peut également être enseignée plusieurs fois, d’où la cardinalité « n » du
côté de l’entité « Matière ». Enfin, les règles de gestion stipulent que chaque classe a au moins
un professeur, d’où la cardinalité minimale « 1 » et qu’elle peut également en avoir plusieurs,
d’où la cardinalité maximale « n » du côté de l’entité « Classe ».
5. Même question mais avec les nouvelles règles de gestion suivante : tout profes-
seur enseigne en principe au moins une matière mais certains peuvent être dispen-
sés d’enseignement en raison de leurs travaux de recherche. Toute matière est ensei-
gnée dans au moins une classe. Toute classe a au moins trois enseignants
1,n
Matière
0,n
Professeur Enseigne
Classe
3,n
Rappelons que les cardinalités dans un MCD sont uniquement fonction des règles de gestion.
La situation est identique à la précédente. Nous avons donc une modélisation identique à la
précédente. Mais, nous avons de nouvelles règles de gestion par conséquent, les cardinalités
sont modifiées. Ainsi, les nouvelles règles de gestion stipulent qu’un enseignant peut ne pas
devoir faire cours alors que précédemment il y était dans l’obligation d’enseigner. Du côté de
l’entité « Enseignant », la cardinalité minimale est donc « 0 » maintenant. De même, les nouvelles
règles de gestion stipulent que, par rapport à la situation précédente dans laquelle une matière
pouvait ne pas être enseignée, toute matière est enseignée au moins une fois, d’où la cardinalité
minimale « 1 ». Enfin, les nouvelles règles de gestion stipulent qu’une classe a au moins trois
enseignants contre un seul précédemment. Donc, la cardinalité minimale passe de « 1 » à « 3 »
du côté de l’entité « Classe ».
6. Quelle interprétation donnez-vous au MCD ci-après ? De quel type de relation

s’agit-il ?
Personne Est marié à
86
Il faut deux occurrences de l’entité « Personne » pour que la relation « Est marié à » soit vérifiée.
En d’autres termes, il faut être deux pour se marier.
Deux entités sont concernées, donc il s’agit d’une relation binaire.
7. Quelle interprétation donnez-vous au MCD ci-après ? De quel type de relation

s’agit-il ? Citez un exemple correspondant.
Personne À vendu à Produit
Une personne a vendu un produit à une autre personne.

Trois entités sont concernées, aussi il s’agit d’une relation ternaire.
Un exemple pourrait être : « Pierre a vendu un livre à Clémentine. »
8. Soit le cas suivant :

L’établissement scolaire dans lequel vous étudiez envisage de s’équiper d’un nouvel équipe-
ment informatique dans le but d’automatiser sa gestion. Sachant que :
• chaque classe a un professeur principal ;
• un même professeur peut être principal dans plusieurs classes la même année ;
• une matière dans une classe n’est enseignée que par un unique professeur ;
• chaque classe a deux délégués.
a. Dressez le dictionnaire des données qui vous semble convenir. Vous vous limiterez à la
liste du nom des données.
Rappelons qu’un dictionnaire des données résulte d’une phase initiale : le recueil des besoins.
Ce dictionnaire recense, en un seul exemplaire, l’ensemble des données devant figurer dans la
base de données qui sera mise en place. Ces données figurent dans le MCD qui conduira juste-
ment à la construction de la base de données. Ce dictionnaire est un outil important car il consti-
tue la référence de toutes les études effectuées ensuite. Aussi, par exemple, nous pourrions
avoir dans le dictionnaire des données les éléments suivants :
N° de classe Nom élève Prénoms élève

Nom professeur Prénoms professeur Adresse professeur
Adresse élève Date d’entrée d’un professeur Note
Date de la note Nom matière Professeur principal
Nom délégué N° élève Délégué
Les attributs « Prénoms » seront décomposés en : Prénom1 et Prénom2
b. Dressez le MCD impliquant les entités : Élève, Professeur et Classe

Élève
N° élève
Nom élève Professeur
Prénom1 élève
Prénom2 élève Nom professeur
Adresse élève Prénom1 professeur
Délégué Adresse professeur
1,1 0,n
1,n Classe 1,1

est élève de est principal
N° de classe
202151TDPA0116 87
c. Dressez le MCD pour les relations : « Est élève de », « Est principal » et « Enseigner ».
Élève
N° élève Professeur
Nom élève 0,n Nom professeur
Prénom1 élève
Prénom1 professeur
Prénom2 élève
Adresse professeur
Adresse élève
Délégué 1,n
1,1
est principal enseigner
1,1
1,n
1,n Classe Matière
est élève de 1,n
N° de classe Nom matière
Exercice 2 : UML
Corrigé
UML n° 1
1. Soit le système informatique qui gère une station-service de distribution d’essence.

Nous nous intéressons à la modélisation de la prise d’essence par un client.
a. Le client se sert de l’essence selon la chronologie suivante : il prend un pistolet accroché
à une pompe et appuie sur la gâchette pour prendre de l’essence. L’acteur du système est-
il le client, le pistolet ou la gâchette ?
Pour le système informatique qui pilote la station-service, le pistolet et la gâchette sont des péri-
phériques matériels. De ce point de vue, ce sont des acteurs. Il est néanmoins nécessaire de
consigner dans le système informatique l’état de ces périphériques : dès qu’un client prend le
pistolet, le système doit informer le pompiste et lui indiquer le type de carburant choisi. Pistolet
et gâchette doivent donc faire partie du système à modéliser.
Le client qui est en dehors du système devient l’acteur principal. Il est possible d’englober le
pistolet et la gâchette dans une modélisation qui englobe la prise du pistolet et l’appui sur la
gâchette comme l’illustre le cas d’utilisation ci-après.
Station-service
Se servir
Client
b. Le pompiste peut se servir de l’essence pour sa voiture. Est-il un nouvel acteur ?
Un acteur est caractérisé par le rôle qu’il tient vis-à-vis d’un système. Le pompiste est une per-
sonne qui a des fonctions différentes d’un simple client. Cependant, quand il se sert du carbu-
rant, il ne se différencie plus d’un autre client. Aussi, il n’y a pas lieu de créer un nouvel acteur
pour le cas « Se servir ».
88
c. La station a un gérant qui utilise le système informatique pour des opérations de gestion.
Est-il un nouvel acteur ?
La gestion de la station-service définit une nouvelle fonctionnalité. Elle doit donc être modélisée.
Le gérant y tient le rôle principal. Un nouvel acteur doit donc être créé. Le cas d’utilisation
devient donc :
Station-service
Se servir
Client
Gérer
la station
Gérant
d. La station-service a un petit atelier d’entretien de véhicule dont s’occupe un mécanicien.

Le gérant est remplacé par un chef d’atelier qui, en plus d’assurer la gestion, est aussi
mécanicien. Établissez le diagramme des cas d’utilisation correspondant.
La station offre maintenant un service supplémentaire : l’entretien de véhicules. Le système
informatique doit donc prendre en charge cette nouvelle fonctionnalité. Un nouvel acteur fait son
apparition : le mécanicien. Par ailleurs, le gérant est à présent un chef d’atelier qui est également
un mécanicien mais qui en plus a la capacité de gérer la station-service. Il y a donc une relation
de généralisation entre les deux acteurs Mécanicien et Chef d’atelier, signifiant que le chef d’ate-
lier peut, en plus d’assurer la gestion, entretenir également des véhicules. Nous obtenons donc
le nouveau diagramme de cas d’utilisation suivant :
Station-service
Se servir
Client
Entretenir
des
véhicules
Gérant
Gérer
la station
Chef
d’atelier
e. Que pensez-vous du diagramme de cas d’utilisation ci-après ?
Décrocher le pistolet Appuyer sur la gâchette Reposer le pistolet Payer

Client
Ce diagramme de cas d’utilisation est incorrect. En effet, on ne doit jamais introduire de séquen-
cement temporel dans un diagramme de cas d’utilisation. Cette notion apparaît lors de la des-
cription des cas. De plus, il est doublement incorrect puisque l’on ne doit jamais recourir à un
trait plein pour relier deux cas entre eux. Cette notation est réservée aux associations entre les
acteurs et les cas d’utilisation.
202151TDPA0116 89
UML n° 2
2. Modélisez à l’aide d’un diagramme de cas d’utilisation le fonctionnement d’un distribu-

teur de vidéo, tel que stipulé dans l’énoncé. On utilisera une relation d’inclusion entre cas
d’utilisation.
Une information telle que le coût de la location n’intervient en rien dans le cas d’utilisation. Le fait
de devoir introduire une carte magnétique peut être ou ne pas être pris en compte, selon la gra-
nularité désirée. S’il n’est pas nécessaire de détailler explicitement cette étape, elle peut être
englobée dans une action appelée « Emprunter une vidéo ». En retenant ce cas, le diagramme
de cas d’utilisation avec une relation d’inclusion est :
Distributeur automatique de vidéos
Emprunter
une vidéo « inclut »
Rechercher
une vidéo
Client
Restituer
une vidéo
UML n° 3
3. Donnez le diagramme de classes de la situation suivante : une personne est caractéri-

sée par son prénom, son nom, son sexe et son âge. Les responsabilités de la classe sont
le calcul de l’âge, du revenu et le paiement des charges. Les attributs de la classe sont
privés alors que les méthodes sont publiques.
Personne
- nom : String
- prénom : String
- sexe : {'F','M'}
- dateNaissance : Date
+ calculAge() : Integer
+ calculRevenu () : Real
+ calculCharges () : Real
UML n° 4
Un chien comme un chat sont des animaux. S’ils diffèrent significativement l’un de l’autre ils
possèdent cependant des propriétés communes comme, par exemple, le nombre de pattes,
d’être mammifère ou encore d’être des animaux domestiques.
4. Proposez un diagramme de classes faisant apparaître le partage de ces propriétés com-

munes qui seront publiques.
Une des caractéristiques de la conception objets est de pouvoir procéder selon une démarche
descendante : du général vers le particulier. Cette approche permet de regrouper dans des classes
des propriétés communes. Les autres classes qui partagent ces propriétés, peuvent y accéder par
la mise en place d’une relation d’héritage. Le diagramme de classes correspondant est donc :
Animal
+ nbPattes : Integer
+ mamifere : Boolean
+ AnimalDomest : Boolean
Chien Chat
90
UML n° 5
Une bibliothèque propose à ses adhérents des œuvres littéraires dans plusieurs catégories.
Après avoir vérifié si le demandeur est en droit d’emprunter et s’il reste au moins un ouvrage
disponible, l’ouvrage désiré est remis au demandeur.
5. Donnez le diagramme de séquence d’emprunt d’un ouvrage.

Pour établir un scénario d’utilisation, il faut considérer le système comme une boîte noire et ne
pas chercher à montrer des objets au cœur de ce système. Aussi, le système est illustré par une
seule ligne de vie nommée Bibliothèque. Le diagramme de séquence est donc :
sd gestion des emprunts
Bibliothécaire : Bibliothèque
Rechercher un adhérent
Adhérent trouvé
Vérifier si l’adhérent peut emprunter
L’adhérent peut emprunter
Rechercher une œuvre
Œuvre trouvée
Vérifier s’il y a un exemplaire disponible pour cette œuvre
Il y a au moins un exemplaire disponible
Décrémenter le nombre d’exemplaires dans la bibliothèque
Attribuer l’exemplaire à l’adhérent

UML n° 6
Un site de vente en ligne propose des produits que le client peut placer dans son panier virtuel
au fur et à mesure de ses achats, tandis qu’il navigue. Pour valider ses achats, il lui suffit de cli-
quer sur un bouton repéré « Valider ». Il lui est alors proposé de se connecter à son compte, s’il
existe ou d’en créer un sinon.
Pour créer un nouveau compte, l’utilisateur doit fournir une adresse de messagerie qui lui servira
également de login ensuite, son adresse postale, son nom et ses coordonnées bancaires. Il
pourra indiquer une adresse de livraison si celle-ci diffère de l’adresse de facturation mentionné
précédemment. Le cas où l’adresse de messagerie indiquée serait déjà associée à un compte
existant est pris en compte. Si toutes les informations fournies sont validées, l’utilisateur se voit
proposer de se connecter à son nouveau compte. Il confirme alors ses achats.
6. Modélisez cette procédure à l’aide d’un diagramme d’activité.

Ici l’énoncé est suffisamment vague pour donner lieu à de nombreuses interprétations. Cette
situation est fréquente et typique d’une spécification textuelle des besoins, telle qu’on en trouve
dans un cahier des charges. La solution proposée fixe donc de façon un peu arbitraire un certain
nombre de choix d’organisation de la procédure. On se concentre ici principalement sur la
modélisation de l’utilisateur et la création d’un compte le cas échéant.
202151TDPA0116 91
Remplir panier Confirmer les achats
loguer utilisateur [else]

[compte invalide]
Compte [oui] Saisir login et

existant ? mot de passe
Créer le
[non][adresse compte
Réception d’un nouveau
Saisie adresse connue] mot de passe temporaire
de courriel
Mot de passe Refus de l’adresse

[else] X
perdu ? de courriel
Saisir les
Saisie nom
références
et adresse
bancaires
[adresse différente]
Modifier
l’adresse de
livraison
UML n° 7
Un centre équestre commercialise des juments. Un acquéreur potentiel peut, à tout moment,
formuler auprès du directeur du centre une demande pour obtenir la liste des juments mises en
vente. Le directeur retourne cette liste régulièrement actualisée. Lorsque le directeur reçoit de la
part d’un client une demande d’information sur l’une d’elles, il se connecte à une base de don-
nées dans laquelle figurent les pédigrées, le carnet de vaccination, etc. Le directeur retourne
alors ces informations à l’acquéreur potentiel.
7. Donnez le diagramme de séquence correspondant à cette procédure.
: Acheteur : Directeur : BaseDeDonnées
1: demandeListeJuments
2: listeJuments
3: choisirJument
4: demandePapiers(jument)
4.1: cherchePapiersCheval(jument)
4.2: papiersjument
4.3: papiersjument
92
UML n° 8
Soit une lampe de chevet que son utilisateur peut à foison allumer ou éteindre comme bon lui
semble.
8.a. Représentez le diagramme de séquence incluant l’allumage et l’extinction en faisant

intervenir la lampe et son utilisateur.
: Utilisateur : Lampe
1: allumer
2: éteindre
b. Faites intervenir comme nouveaux objets l’interrupteur et le réseau électrique et four-

nissez le diagramme de séquence correspondant.
: Utilisateur : Interrupteur : Réseau électrique : Lampe
1: appuyer
2: circuler
3: allumer
4: appuyer
5: couper
6: éteindre
202151TDPA0116 93
Exercice 3 : BPMN
Corrigé
BPMN n° 1
1. Fournissez le diagramme BPMN de la mise en ligne d’une offre par la société Net-Tours.
Ambassades/Consulats
Affaires étrangères/
Réception de Traiter Envoyer

la demande la demande la réponse
Commercialisation d’une offre
Problème
Demande X
d’information Oui Non
Mise
Portail Web
en attente
10 jours
Proposer 00:00:00 Mise
une offre
+ en ligne
Début 10 jours
00:00:00
BPMN n° 2
2. Fournissez la modélisation BPMN de l’achat d’une boisson.
Interroger Sélection de Boisson Récupérer

Client
le distributeur la boisson récupérée la monnaie

Début1
Non
Oui
Non Boisson Rendre
délivrée X la monnaie
Oui
Boisson Monnaie à rendre
Interrogation X Décrémentation
Distributeur
sélectionnée
Boisson
disponible
Achat d’une boisson
Oui Boisson
X préparée
Quantité restante < Seuil
Dépositaire
Enregistrement
du montant à
verser
FroidChaud
Enregistrement
Manque du montant à
enregistré verser
94
2
PARTIE
L’urbanisation du SI
Les organisations sont en pleine mutation : fusions-acquisitions, changements internes, mise en

place de processus collaboratifs, etc., et, bien sûr, le patrimoine des SI n’est pas préparé à une
telle flexibilité. Ces SI datent des grandes applications, héritées de l’époque des sites centraux
(mainframe) ou du mode client/serveur de première génération ainsi que des vastes domaines
confiés à des ERP22. Il est très fréquent de trouver dans ces SI une multitude de petites applica-
tions, plus ou moins connectées entre elles, fonctionnant presque miraculeusement avec une
multitude d’interfaces bricolées. Les redondances de données de référence sont monnaie cou-
rante ainsi que la multiplicité d’objets informatiques. Tout cela rend impossible les rénovations
progressives et génère des surcoûts de la production informatique ainsi que des charges crois-
santes des évolutions et des maintenances.
En effet, les organisations ont un existant, elles ne partent pas de zéro. Le recours à l’informa-
tique ne date pas d’hier. Les SI existant ont été mis en place progressivement, au fil du temps,
sans une réelle structuration sans une véritable documentation23, mélangeant diverses techno-
logies, divers langages de programmation, diverses architectures sans compter le départ des
informaticiens de l’époque…
De plus, le patrimoine représenté par l’ensemble des applications est souvent mal connu, ce qui
rend difficile l’insertion d’un nouveau projet, ou la prédiction des conséquences d’une évolution
incontournable. Enfin, les incohérences, la mauvaise communication et l’hétérogénéité de cer-
tains sous-systèmes, résultant d’une longue histoire complique encore plus la situation.
Par ailleurs, les SI sont de plus en plus complexes et nécessitent davantage d’être intégrés. De
même, les budgets connaissent des restrictions drastiques et les retours sur investissements
doivent être justifiés. Il est bien fini le temps où la DSI pouvait envisager les dépenses à marche
forcée. De nos jours, le besoin d’assurer une vision transverse se fait sentir de plus en plus.
Dans le même temps, les cycles de vie des technologies, des organisations et des stratégies
évoluent de plus en plus vite, engendrant un besoin urgent d’évolution permanente des SI asso-
ciés. Les systèmes vieillissent prématurément.
Donc, comme nous l’avons vu notamment dans le paragraphe précédent, Défi de l’infrastruc-
ture, bon nombre d’organisations se trouvent face à des infrastructures techniques coûteuses et
lourdes, inadaptées aux innovations et aux changements. Nous avons vu que leur SI est parfois
si complexe et si fragile qu’il nuit à l’accomplissement de leur stratégie et à leurs opérations
quotidiennes. Nous avons vu également que bon nombre d’organisations sont handicapées par
leur SI constitué de matériels informatique, de logiciels et de réseaux de télécommunications
incomplets, obsolètes et incompatibles entre eux, ce qui nuit, voire interdit une circulation fluide
de l’information entre différentes parties de l’organisation.
Aussi, nombre d’anciens SI doivent être progressivement remplacés par d’autres technologique-
ment bien plus puissants. Comme nous l’avons vu également, afin de garantir sa pérennité,
toute organisation doit apprendre à maîtriser les investissements et les usages de ces nouvelles
technologies. Mais, bien sûr, il est inenvisageable de penser faire table rase du passé, de tout
arrêter, de tout mettre « à la casse » et de repartir de zéro.
22. Enterprise Resource Planning.

23. Si toutefois il en existe au moins une, même à l’état embryonnaire !
202151TDPA0116 95
L’urbanisation est souvent perçue comme une démarche stratégique. Pourtant, dans la conduite
des SI, il est aisé de perdre de vue ses principes fondateurs. Pour répondre à des objectifs clas-
siques tels que la flexibilité, la mutualisation, la maintenabilité, la scalabilité (capacité à s’adap-
ter), la résilience, etc., l’urbanisation est en premier lieu une démarche technique qui recoure à
trois principes simples : décomposition, découplage et intermédiation.
L’urbanisation est une démarche de re-ingéniérie qui, par conséquent, est indiquée pour l’inté-
gration et la prise en compte des progiciels, des logiciels historiques et des composants hétéro-
gènes. D’un point de vue pratique, la démarche d’urbanisation est une réponse à une situation
insupportable, souvent appelée « informatique spaghetti ». C’est une démarche d’architecture
des SI et non pas d’architecture logicielle même si elle s’accompagne de conséquences sur les
composants logiciels. C’est une démarche pragmatique qu’il est aisé à comprendre.
L’urbanisation est apparue conjointement au besoin d’intégrer des applications dans un environ-
nement hétérogène. L’informatique a commencée avec des applications indépendantes, puis
des applications intégrées au sein d’un environnement commun : le mainframe. Elle a ensuite
évoluée vers une informatique distribuée sur des serveurs dédiés avec des applications indé-
pendantes ou très faiblement couplées au travers d’une base de données commune par exemple.
Quand le besoin de couplage s’est renforcé parce que, par exemple, il fallait partager les mêmes
informations sur les clients entre les applications de logistique, de facturation, etc., la probléma-
tique de l’intégration d’application (ou EAI en anglais, Entreprise Application Integration) est née.
Au début, avec deux ou trois applications, il a d’abord été question d’une problématique tech-
nique, de faisabilité. Quand le nombre d’applications a augmenté, nous sommes passés à un
problème plus complexe de cohérence, de contrôle et de capacité à faire évoluer. La phase
technique de l’intégration d’application a débuté à la fin des années 1980, avec l’apparition des
bus de composants dans le monde de l’informatique d’entreprise. La notion d’urbanisation qui
correspond à une vision systémique est apparue dans la fin des années 1990.
L’urbanisation est l’évolution naturelle des méthodologies de construction de parcs applicatifs.
On y retrouve des idées et des concepts développés depuis plus de trente ans dans le monde
informatique : analyse fonctionnelle, processus, formalisation des interfaces, définition des rôles,
analyse des flots de données, etc.
Il ne s’agit donc pas d’une révolution conceptuelle mais au contraire d’une maturation progres-
sive des concepts, qui permet de les utiliser de façon unifiée. En revanche, cette maturation s’est
accompagnée d’un développement technologique rapide qui a rendu possible, à la fin des
années 1990, de faire ce dont les architectes SI parlaient depuis longtemps, en particulier depuis
l’introduction de Corba. Comme dans d’autres domaines informatiques, le facteur déclenchant
a été la conjonction :
• d’un niveau de performance offert par la progression de la puissance des machines permettant
d’absorber la charge induite par une architecture ouverte ;
• de la maturité des concepts permettant aux éditeurs d’introduire le concept d’offre EAI, définis
par la combinaison d’un bus logiciel pour le transport, de techniques de transformation de
données pour l’intégration et de mécanismes de contrôle ;
• d’une offre suffisante en termes de nombre et de maturité des éditeurs.
En conséquence, on a vu à partir de 1998 des démarches d’urbanisation fleurir dans la plupart
des grandes entreprises françaises.
Pour comprendre cette démarche, pourquoi elle est pertinente et commet juger de son effica-
cité, il faut comprendre les qualités attendues d’un SI : flexibilité, maintenabilité, mutualisation,
scalabilité et résilience. Le SI désigne ici l’ensemble des applications considérées comme un
tout et dans sa capacité à supporter et exécuter les processus de l’entreprise.
I. L’INFORMATIQUE SPAGHETTI
La notion d’informatique spaghetti ou encore de plat de nouilles est apparue spontanément il y
a quelques années quand des DSI ont demandé qu’on leur fasse une macrocartographie appli-
cative, c’est-à-dire un plan des systèmes et des flux. Dans la plupart des organisations de grande
96
taille, ces cartes présentent plusieurs similitudes : un grand nombre d’applications symbolisées
par un rectangle et un nombre encore plus grand de liens entre celles-ci et qui vont dans tous
les sens. Quelle que soit l’ingéniosité de la représentation, tous ces liens se croisent et se
recroisent à foison et vont d’un bout à l’autre de la carte créant ainsi l’effet visuel d’un plat de
spaghetti flagrant.
À l’instar de la représentation d’un plat de spaghettis aux olives – il est impossible de savoir quel
spaghetti relie deux olives –, il est impossible d’identifier précisément les liens entre deux appli-
cations.
Le problème ne se situe pas dans le nombre de boîtes, d’une part, parce que celui-ci est arbi-
traire en fonction de la finesse de l’analyse et, d’autre part, parce que l’informatique d’une grande
organisation comporte nécessairement de très nombreuses fonctions. Le problème vient d’une
part du nombre de liens et du fait qu’ils vont dans tous les sens, par opposition au fait de former
des îlots de sous-système fortement connectés. Par la suite, lorsque nous regardons de plus
près, nous réalisons que la plupart de ces liens sont ad hoc, correspondant à un ensemble hété-
rogène de technologies, allant de batchs de transfert de fichiers jusqu’à des liens synchrones
assurant des connexions de type requête/réponse. Ces liens ne sont pas indépendants, ils for-
ment des enchaînements correspondant à une logique métier, mais sans aucun contrôle central.
Cette situation n’est pas sans conséquence. Au contraire, elle est source de bien des problèmes :
• reprise sur incident : la complexité des flux de transfert de données rend la reprise sur inci-
dent difficile. Cette difficulté est renforcée lorsque la logique correspondant à des enchaîne-
ments de liens n’est pas représentée, en dehors du planning d’exploitation ;
• coût d’évolution : d’une façon générale, dans le cas de liens ad hoc, les impacts liés à un
changement applicatif se propagent sur les liens. Plus un système est connecté, plus il va
falloir de modifications sur ses interfaces avec l’extérieur ;
• gestion de la complexité : indépendamment des coûts, la complexité des liens et de leur
nature devient rapidement un facteur bloquant pour l’évolution. La réponse est le plus souvent
l’apparition de nouveaux systèmes ou de nouveaux liens ;
• risque de ralentissement voire de blocages : une partie des liens crée des couplages forts,
en particulier les liens synchrones. Ces couplages rendent délicate la gestion des perfor-
mances puisqu’il faut prendre en compte un grand nombre de systèmes pour régler le bon
fonctionnement des flux.
II. POURQUOI URBANISER ?

Avant d’aborder la démarche d’urbanisation, examinons la cible que nous cherchons à atteindre.
Un SI urbanisé possède quatre caractéristiques :
• il est organisé autour des processus métier de l’entreprise ;
• il repose sur une décomposition hiérarchique en sous-systèmes et composants ;
• ses échanges entre sous-systèmes et composants sont normalisés autour d’un modèle
métier ;
• il est construit sur une architecture ouverte pour faciliter l’évolution.
Il est facile de voir que ces quatre caractéristiques sont des réponses aux objectifs formulés
précédemment. Détaillons chacune de ces quatre caractéristiques.
A. ARCHITECTURE À BASE DE COMPOSANTS

Le principe de décomposition hiérarchique et de définition de composants n’est pas nouveau.
Déjà Descartes, dans son discours de la méthode écrivait : « De diviser chacune des difficultés
que j’examinerais en autant de parcelles qu’il se pourrait, et qui serait requis pour mieux les
résoudre. » Toutes les démarches d’analyse insistent sur la décomposition hiérarchique en sous-
systèmes de telle sorte que les interactions entre composants soient limitées au profit de celles
à l’intérieur du composant. L’objectif est d’obtenir la modularité de la décomposition, propriété
qui caractérise la capacité à faire évoluer chaque composant de façon la plus indépendante et
202151TDPA0116 97
autonome possible. Une telle décomposition peut se faire de haut en bas24 en partant de l’ana-
lyse du métier pour dériver les composants fonctionnels avec une approche récursive pour com-
mencer par les macrofonctions et terminer par les fonctions détaillées. Elle peut également se
faire de bas en haut25, une fois établie la liste des activités ou fonctions élémentaires, en partant
du graphe d’interaction et en identifiant les îlots de forte connectivité.
B. URBANISATION AUTOUR DES PROCESSUS D’ENTREPRISE

La notion de processus est une notion fondamentale en informatique et qui a émergé progressi-
vement comme outil de modélisation pour l’informatique d’entreprise. Un processus est un
modèle d’enchaînement d’activités usuellement représenté par un graphe dont les nœuds sont
les activités et les liens représentent les transitions. Dans une modélisation métier, le processus
permet de décrire la logique d’enchaînement des activités entre plusieurs acteurs.
C. NORMALISATION DES ÉCHANGES

La normalisation des échanges est une activité essentielle de l’urbanisation dans le cadre d’une
cité qu’il s’agisse de réseaux de transports, d’alimentation en eau ou en électricité, etc. Il en est de
même pour l’urbanisation des SI. La normalisation des échanges et des interfaces est également
fondamental. De la même façon qu’il faut normaliser le contenant et le contenu dans une interface
physique, par exemple : un tuyau de diamètre 25 mm avec un filetage de 10 mm pour de l’eau
potable, il faut normaliser la technologie des échanges et les formats qui peuvent être échangés.
D. ARCHITECTURE OUVERTE
Une architecture ouverte dispose de mécanismes permettant de réaliser de façon simple des
modifications ou des extensions. Ces mécanismes sont le plus souvent inspirés du monde de
l’intégration et des méthodes développées pour créer des logiciels ouverts. Le premier para-
digme qui permet une modélisation simple est précisément celui de l’interface standardisée et
normalisée. Il reste à gérer le branchement/débranchement qui peut néanmoins s’avérer com-
plexe. Pour aller plus loin en termes d’extensibilité, et de souplesse de modification, le méca-
nisme d’intermédiation est utilisé. Il consiste à introduire un intermédiaire technique entre un
couple client/serveur. Cet intermédiaire va permette de faire et défaire des branchements de
façon dynamique, sans avoir à modifier physiquement les composants client et serveur.
L’intermédiation est un concept classique de l’informatique. Il prend par exemple souvent le nom
de proxy. L’utilisation d’un bus de communication est une forme d’intermédiation. Il permet de
découpler les composants à travers les adaptateurs. Il permet également de modifier les branche-
ments par simple paramétrage, voire de supporter des branchements dynamiques si le modèle de
connexion supporte la notion de prise vide. Une prise vide est un emplacement sur lequel il est
possible de brancher un composant, plus tard, avec une sémantique d’interaction prédéfinie.
III. LE MÉTAMODÈLE ET LES CONCEPTS

L’une des activités fondamentales des projets d’urbanisation consiste à représenter les diffé-
rentes visions du SI sous des formes permettant de les exploiter comme, par exemple une base
de données ou un référentiel d’outil de génie logiciel. Pour cela, il existe un modèle générique
des concepts, qui peut bien évidemment être adapté au contexte de chaque projet.
Les modèles doivent permettre de représenter aussi bien le SI actuel que le SI cible.
Le modèle décrit les concepts utilisés dans la démarche méthodologique proposée, ainsi que les
liens qui les unissent.
24. Ou top-down.
25. Ou bottom-up.
98
Une définition de chaque concept du modèle est proposée avec quelques-unes des propriétés
principales.
Les concepts figurant dans le métamodèle sont :
• acteur : il est entendu selon la définition UML. Il représente ce qui existe en dehors du système
et agit avec lui. Un acteur peut être humain ou être un automate. Il opère des transactions avec
le système et chaque séquence de transaction peut être définie dans un cas d’utilisation. Un
acteur est différent d’un utilisateur. Un utilisateur utilise réellement le système alors qu’un
acteur est un agent externe qui représente quelque chose pour le système ;
• activité : une activité est l’unité de décomposition fonctionnelle du processus. Elle correspond à
un module fonctionnel indépendant des fonctions en amont ou en aval et est éventuellement
réutilisable comme, par exemple, un contrôle de disponibilité ou encore une demande d’acompte  ;
• bloc : il s’agit d’un terme générique qui désigne l’un des trois niveaux de découpage de l’archi-
tecture fonctionnelle ou de l’architecture applicative : zone, quartier ou îlot. Il s’agit d’une unité
atomique et autonome disjointe à l’exécution. Un bloc est décrit par un texte de description
générale, les services qu’il assure et ses principes de base ;
• bloc applicatif : il s’agit d’un module logiciel exécutable et ayant une prise bien définie. À
l’image du bloc qui désigne pour l’architecture fonctionnelle une zone, un quartier ou un îlot, le
bloc applicatif peut être une zone applicative, un quartier applicatif ou un îlot applicatif selon
qu’il correspond en termes de granularité à une zone, un quartier ou un îlot. Un bloc applicatif
est décrit par un texte de description générale, un texte décrivant ses objectifs, les fonctions
qu’il assure et ses principes de base ;
• classe métier : il s’agit, à l’image de la programmation orientée objets d’un ensemble d’objets
métier qui possèdent des caractéristiques identiques ;
• événement : il s’agit d’un signal qui peut être reconnu par un acteur donné et qui indique
qu’un fait auquel des données sont attachées a eu lieu. Il a les caractéristiques suivantes : il
arrive à un moment donné, il n’a pas de durée, il peut précéder ou suivre un autre évènement,
il peut être pris en compte par plusieurs blocs simultanément, il donne lieu à un flux de don-
nées ou de matière, les flux de données étant transmis par des messages d’un bloc à un autre ;
• flux : il s’agit d’un échange de données entre blocs. Il peut être continu ou déclenché à certains
moments de la journée. Un flux peut être interne au système étudié, provenir « de » ou encore
être destiné à un système externe. On distingue les flux de matière et les flux de données ;
• îlot : il s’agit d’une entité remplaçable du SI susceptible d’être développé ou acheté séparé-
ment. Un îlot correspond à une finalité fonctionnelle et comprend des traitements et des accès
à des données pour cette finalité. Un îlot émet des résultats normalisés exploitables par
d’autres îlots. Un îlot va typiquement correspondre à une application ou une grande fonction
applicative ou encore à un progiciel ou à un autre module d’un progiciel. Exemples : accepta-
tion des paiements échelonnés, facturation, gestion des paiements échelonnés… ;
• message : il s’agit du mode de propagation entre blocs d’un flux de données associé à un
évènement de gestion. Il peut être transmis de manière synchrone ou asynchrone. Un mes-
sage peut être interne au système étudié ou provenir de ou être destiné à un système externe ;
• objectif : la stratégie de l’organisation est appréhendée sous la forme de ses objectifs et sous-
objectifs. Dans un but de traçabilité, on peut enregistrer dans la cartographie métier la descrip-
tion des objectifs et sous-objectifs. On s’assurera que chaque objectif est couvert par un
processus, chaque activité de processus par un ou plusieurs blocs. On conservera ainsi la
trace des besoins couverts par chaque élément de la cartographie applicative ;
• opération : il s’agit d’une étape d’une procédure correspondant à l’intervention d’un acteur de
l’organisation dans le cadre des activités de l’organisation. Une fois démarrée, l’opération peut
être exécutée sans attendre d’autre évènement que son événement déclencheur. L’opération
ne peut pas être interrompue ;
• poste de travail : il s’agit d’un ordinateur ou terminal connecté au réseau interne de l’organi-
sation et permettant à un acteur d’accéder à des logiciels métier ou à des logiciels de base
comme, par exemple, une messagerie, un fax, Internet, des outils de bureautique… ;
• procédure : il s’agit d’un processus organisé, c’est-à-dire que la dimension organisation (qui fait
quoi ?) est introduite par rapport au processus. Une procédure se décompose en opérations ;
• processus : un processus est constitué d’un réseau d’activités ayant pour finalité le traitement
d’un évènement de gestion initiateur. Il a pour objectif la production de flux de résultats définis
202151TDPA0116 99
dans des conditions de délai et de qualité fixées pour répondre aux besoins tiers internes ou
externes. Il est indépendant de l’organisation. Exemples : une réservation, un paiement, une
facturation, etc. ;
• quartier : il regroupe des îlots homogènes quant à la nature de l’information traitée. Un quar-
tier va typiquement correspondre à ce que l’on appelle communément un sous-système.
Exemples : gestion de paiements, gestion de tarifs, gestion de voyages… ;
• réseau : il s’agit d’un groupe d’ordinateurs raccordés entre eux pouvant échanger des infor-
mations et partager des équipements tels qu’une imprimante, un scanner… ;
• serveur : il s’agit d’un élément technique composé d’une partie matérielle et d’une partie logi-
cielle d’infrastructure ou encore logiciel de base, nécessaires à son fonctionnement. Un ser-
veur est localisé sur un site et peut héberger des logiciels métier ;
• site : il s’agit d’un lieu géographique considéré du point de vue d’une ou plusieurs activités.
Exemple : l’agence de Bordeaux, le siège de Paris… ;
• système d’information : il s’agit d’un aspect d’une organisation qui fournit, utilise et distribue
l’information. Il s’agit donc d’un aspect d’un système humain, contenant éventuellement des
systèmes informatiques ;
• système informatique : il s’agit d’un ou plusieurs ordinateurs, matériels périphériques et logi-
ciels qui effectuent un traitement de données. C’est la partie automatisée des SI. Il est com-
posé de l’ensemble des moyens matériels et logiciels assurant le traitement, le stockage et le
transport des informations ;
• zone : elle correspond au premier niveau de découpage du SI. La liste des zones d’un SI est
donnée par les règles de bonnes pratiques. Exemples : zone d’échange, zone opération…
IV. LA DÉMARCHE D’URBANISATION
A. VOCABULAIRE ET PROCESSUS
L’urbanisation est une démarche difficile qui doit être abordée avec modestie. Cette difficulté se
manifeste de deux façons. Dans la phase d’analyse la définition des objets et des processus
métiers est une démarche itérative, qui demande quelques itérations avant d’aboutir au bon
résultat. Dans la phase de déploiement, de nombreuses difficultés techniques surgissent, même
si la cible est clairement identifiée, en termes de performance et de validation des échanges.
La première étape est de définir une cible métier en termes d’objets métier et de processus. Le
modèle métier va structurer tous les échanges, c’est la langue commune du SI. Ceci est vrai au
niveau informatique, mais encore plus vrai pour les hommes. La définition d’un modèle métier
pour l’entreprise est l’occasion de se mettre d’accord sur le sens des mots, ce qui est déjà un
premier bénéfice, indépendamment de toute informatisation. Le modèle métier doit avoir plu-
sieurs caractéristiques :
• il se prête naturellement à la description des activités et des processus de l’entreprise ;
• il est complet quant à la couverture des cas complexes ou difficile. Un modèle métier doit
décrire 100 % du métier ;
• il est construit pour accompagner l’évolution du métier de l’entreprise. En recourant aux
apports classiques de la modélisation par objets comme, par exemple, la hiérarchie des
classes, le modèle peut s’enrichir facilement de nouveaux concepts.
La seconde étape d’une démarche d’urbanisation est la réalisation d’une cartographie.
L’importance de celle-ci est un point consensuel de l’ensemble des livres, rapports, thèses, etc.,
traitant de l’urbanisation. L’analogie avec l’urbanisation des cités est d’ailleurs à la mise en avant
de la cartographie, qui joue simultanément le rôle de définition de la cible, de mode d’emploi et
d’outil de communication. Puisque l’urbanisation est une démarche progressive, la cartographie
permet de décrire l’existant, l’objectif final et les différentes étapes de transition.
Il est d’usage de distinguer quatre niveaux dans la cartographie des SI :
• la cartographie métier, qui est également le niveau stratégique. Selon les approches, elle
contient différents types d’information, comme les modèles d’objet métiers, les processus, les
enjeux stratégiques, etc. Il s’agit donc de la structuration du SI par les activités métier de
100
l’entreprise ou de l’organisme vis-à-vis de ses processus. La description de ces activités peut

se faire à partir des processus métier, si leur description est disponible, ou au moyen des
concepts utilisés par les utilisateurs concernés. Le plus souvent, la description des activités se
fait dans une hiérarchie qui va d’un domaine assez large comme, par exemple, la gestion des
clients, jusqu’au niveau le plus atomique comme, par exemple « créer un client » en passant
par un nombre variable de niveaux intermédiaires ;
• la cartographie fonctionnelle, qui contient la définition des fonctions de l’organisation, sous
forme hiérarchique. Les grandes fonctions sont représentées par des blocs, les fonctions plus
détaillées qui implémentent chacune des macrofonctions sont représentées par des sous-
blocs. La cartographie fonctionnelle peut être enrichie par des flux d’échange, dont leur com-
plexité constitue une métrique de la qualité de la cartographie. Il s’agit donc de la structuration
du SI en blocs fonctionnels communicants. Les concepts des architectures fonctionnelles et
métier sont liés. Il est important lors de la cartographie fonctionnelle de faire apparaître les liens
entre les zones quartiers, îlots et les activités métier qu’ils assurent ou assureront dans le cas
de la conception du futur SI. Ces informations permettront de mesurer les impacts des modi-
fications fonctionnelles et de repérer les parties d’applications éventuellement réutilisables ;
• la cartographie applicative, qui contient les éléments logiciels qui vont remplir ces fonctions,
ainsi que les éléments d’infrastructure qui supportent les flux d’échange de données et de
contrôle. Il s’agit de la structuration du SI en blocs applicatifs communicants. Il s’agit de la des-
cription et de l’organisation des applications informatiques (données et traitements) ainsi que des
messages échangés par ces applications. L’architecture applicative est décrite par les zones,
quartiers et îlots applicatifs ainsi que par les messages échangés entre ces différents éléments ;
• la cartographie physique, qui contient la cartographie des machines qui hébergent les appli-
cations, les outils de stockage et ceux de communication. Il s’agit de la structuration des
moyens d’infrastructure technique à mettre en œuvre pour informatiser l’activité de l’organisa-
tion. Il s’agit donc de l’organisation des différents moyens matériels tels que les serveurs,
postes clients, etc., et des logiciels comme les systèmes d’exploitation, les SGBD, ainsi que
des moyens de communication entre elles comme les réseaux.
Figure 76 – Les quatre cartographies d’un système d’information

Stratégie de l'entreprise
Clients
Clients
ts
en
Fournisseurs Partenaires e m sus
én es
év roc
p
Métier on
m ati
r
fo n
’in atio
(règles d'urbanisation, standards et
d
e n i s
normes, règles de gestion…)
tèm ga
sys or
Fonctionnel ue
tiq atifs
Référentiels
a
orm lic
e inf app
m nts
stè sa
sy mpo
co
Application e
qu e
m ati niqu
r h
nfo ec
Internet m e i ure t
è t
st c
sy astru
ni fr
Technique
Évolutions technologiques
202151TDPA0116 101
B. CONCEPTS ET RÈGLES
Urbaniser permet de :
• fédérer les briques d’un SI existantes autour d’une architecture d’ensemble et de principes qui
lui permettront d’acquérir la souplesse et la réactivité nécessaire pour s’adapter aux contraintes
du marché ou de l’environnement ;
• gérer la prise en compte rapide et efficiente par le SI ainsi urbanisé des demandes d’évolution
critiques, par une approche rationnalisée ;
• faire porter les efforts de développement sur les nouvelles fonctionnalités à forte valeur ajoutée
et de réutiliser en majeure partie le système existant.
Une fois cette intervention menée à bien, le SI a la capacité d’accueillir toute nouvelle structure
qui répond aux règles d’urbanisme établies. Les modifications apportées à des parties du SI
auront un impact à la fois prédictible et maîtrisé.
Le but d’un projet d’urbanisation de SI est d’organiser la prise en compte des besoins majeurs
d’évolution, nécessitant une refonte totale ou partielle, sur un SI, en minimisant les risques
encourus et en maximisant la sauvegarde du patrimoine informationnel.
La démarche d’urbanisation propose de passer d’un SI existant à un SI cible, par paliers succes-
sifs correspondants à des états stables.
L’approche d’urbanisation privilégie la maîtrise des risques en introduisant des paliers maîtri-
sables dans des contextes particulièrement complexes, où le niveau de complexité engendre un
risque élevé.
Pour mener à bien cette opération, la démarche se base sur un cadre de référence distinguant
quatre visions du SI : les quatre cartographies présentées précédemment.
L’opération d’urbanisation va consister à réorganiser un système informatique où les frontières
entre les blocs ne sont pas effectives, pour rendre ce système informatique modulaire et capable
d’évolutions.
Si une démarche d’urbanisation peut déboucher sur un succès, elle peut également déboucher
sur un échec. Dans un cas comme dans l’autre, plusieurs facteurs interviennent. Les facteurs
clés du succès sont :
• adhésion des acteurs ;
• méthodologie comprise et partagée par tous ;
• mode de communication et supports adaptés aux différentes typologies d’acteurs ;
• structure projet la plus pérenne possible impliquant toutes les compétences nécessaires
(représentants de tous métiers) ;
• présence d’un PAQ26 définissant précisément le volet management du projet d’urbanisation
(qui fait quoi et quand?) ainsi que son volet de production (comment et avec quoi faire ?).
À l’inverse, les facteurs d’échec sont :
• mauvaise compréhension du périmètre de l’étude ;
• objectifs métiers contradictoires ou irréalistes ;
• équipe projet sous dimensionnée ;
• manque de disponibilité des métiers ;
• absence de décisionnaires ;
• absence d’un sponsor ;
• informations collectées inexploitables ;
• document sur l’existant très pauvre ;
• résistance au changement ;
• structure de pilotage SI absente, cible irréaliste au regard de l’existant.
26. Plan d’assurance qualité. Ce concept sera traité dans une autre série.
102
Exercice 4 : Urbanisation
Énoncé
TRAVAIL À FAIRE
1. Quel lien faites-vous entre l’action de cartographier un SI et son urbanisation ?
2. Quel est le but de la cartographie des processus ?
3. Quels est le but de la cartographie applicative ?
4. Selon-vous, est-il préférable de procéder par une analyse descendante en partant des
métiers pour arriver aux applications ou, au contraire, de procéder de façon ascendante ?
Corrigé
1. Quel lien faites-vous entre l’action de cartographier un SI et son urbanisation ?

Cartographier un SI consiste à se doter d’un outil qui va présenter le SI existant sous différentes
vues. Elle est donc indispensable dans une démarche d’urbanisation, qui consiste à faire évoluer
un SI existant système vers un SI cible, plus à même d’anticiper les changements dans l’envi-
ronnement d’une entreprise.
2. Quel est le but de la cartographie des processus ?

La cartographie des processus décrit les entrées et les sorties des processus et leurs activités
critiques. Elles doivent être par conséquent arborescentes : macroprocessus, processus, sous-
processus, activités. Elle se décompose en quatre déclinaisons : processus stratégiques, pro-
cessus métiers, fonctions support et processus de pilotage.
3. Quels est le but de la cartographie applicative ?

La cartographie applicative est destinée à mettre en exergue la capacité d’évolution d’un SI dans
sa capacité à répondre aux évolutions stratégiques de l’organisation détentrice. Elle complète la
cartographie des processus en faisant correspondre les fonctions informatiques avec les fonc-
tions des processus. Dans une optique d’urbanisation d’un SI, la cartographie applicative
conjointement à la cartographie des processus feront apparaître d’éventuels doublons ainsi
qu’une mauvaise couverture de certains champs tout comme les blocs applicatifs communs à
plusieurs processus et, enfin, les applications vieillissantes.
4. Selon-vous, est-il préférable de procéder par une analyse descendante en partant

des métiers pour arriver aux applications ou, au contraire, de procéder de façon
ascendante ?
Ni l’un ni l’autre, il faut procéder simultanément des deux façons. En reliant les processus aux
fonctions et les fonctions aux applications, on vérifie la couverture des domaines soit par une
matrice processus/application, soit par empilement des diagrammes en couches. Ne travailler
qu’avec la cartographie applicative risque de conduire à restreindre l’activité des processus à ce
que peuvent faire les applications. Réciproquement, ne regarder que la cartographie des proces-
sus risque de déboucher sur des choix qui ne pourront pas être supportés par le SI ou devant
nécessiter de gros investissements.
202151TDPA0116 103
Annexes
Annexe 1 Algèbre relationnelle

Introduite en 1970 par Codd afin de formaliser des opérations sur les ensembles. Ce formalisme
en s’appuyant sur la rigueur mathématique offre la possibilité de démontrer l’équivalence entre
requêtes et opérations ensemblistes.
Ces connaissances s’avèrent indispensables à toute personne désirant comprendre le méca-
nisme des requêtes sur une base de données. À l’inverse, bien sûr, ces connaissances ne sont
en rien nécessaires et sont même totalement masquées à toute personne souhaitant utiliser une
base de données.
Loin de nous l’idée d’aborder l’étude détaillée de ces concepts. Aussi, à titre d’exemple, nous
nous limiterons aux principaux concepts sous-jacents.
On peut classer en deux catégories les opérations réalisables : les ensemblistes et les unaires.
Dans le but d’illustrer ces deux catégories d’opérations, recourons aux deux relations
suivantes :
X R S T Y R S T
a b C b g a
d a f d a f
c b d
Opération de base
On trouve les opérations suivantes :
L’union de deux relations X et Y, de même schéma, est une troisième relation Z, également de
même schéma, contenant l’ensemble des tuples de X ou de Y ou des deux. On note Z=(X  ∪
Y). En termes de tables, l’union entre deux tables en donne une troisième, la table résultante, de
même structure que les deux autres et contenant l’ensemble des éléments présents dans cha-
cune des deux tables initiales ou dans les deux tables simultanément.
La différence entre deux relations X et Y, de même schéma, est une troisième relation Z, égale-
ment de même schéma, contenant l’ensemble des tuples appartenant à X mais n’appartenant
pas à Y. On note Z=X-Y. En termes de tables, la différence entre deux tables en donne donc une
troisième, la table résultante, de même structure que les deux autres et contenant l’ensemble
des éléments présents dans la première table mais ne figurant pas dans la seconde.
L’intersection entre deux relations X et Y, de même schéma, est une troisième relation Z, égale-
ment de même schéma, contenant les éléments contenus simultanément dans chacune des
deux relations initiales. En termes de tables, l’intersection entre deux tables en donne donc une
troisième, la table résultante, de même structure que les deux autres et contenant l’ensemble
des éléments communs aux deux autres tables.
La restriction sur une relation, selon une condition, donne comme résultat une relation de même
schéma que la relation concernée ne contenant que les éléments de la relation vérifiant la condi-
tion. Par exemple, la restriction avec la condition « strictement supérieur à 9 » appliquée sur une
relation contenant des valeurs décimales donnera en résultat une table ne contenant que les
valeurs initiales supérieures ou égales à 10.
La projection d’une relation sur un groupe d’attributs donne une relation ayant comme schéma
uniquement que ces attributs et contenant les tuples distincts composés par les valeurs asso-
ciées de ces attributs. Par exemple, la projection sur la relation Élève{matricule_el, prénom, nom,
202151TDPA0116 105
année_naissance, civilité} avec les attributs (prénom, nom, civilité) donne en résultat une table ne
contenant que les trois attributs (les trois colonnes) prénom, nom, civilité et contenant les infor-
mations correspondantes contenues dans la table initiale.
Le produit cartésien entre deux relations  se reporter à la page 18 pour consulter la définition
déjà présentée.
La jointure entre deux relations selon une condition résulte d’une restriction sur le produit carté-
sien suivant cette condition. On distingue quatre types de jointures :
• la Θ-jointure de deux relations R et S selon une condition C fournit l’ensemble des tuples du
produit cartésien R x S vérifiant C. Dans l’expression de la condition C, il est possible de recou-
rir à des constantes ainsi qu’aux opérateurs arithmétiques <, ≤, =, >, ≥ ainsi que les opérateurs
logiques OU, ET et NON. Essentielle dans les opérations relationnelles, cette jointure permet
une utilisation raisonnable du produit cartésien ;
• l’équijointure, qui est une Θ-jointure dans laquelle la condition porte sur l’égalité entre deux
colonnes ;
• l’autojointure qui est une Θ-jointure d’une table avec elle-même. Tout se passe comme si l’on
disposait de deux copies différentes de la même table ;
• la jointure naturelle qui correspond à une jointure des deux relations R et S sur l’ensemble
des attributs de même nom, dans R et dans S, suivie de la projection qui permet d’éliminer les
éventuels doublons donc les attributs répétés. Il s’agit du type de jointure le plus fréquemment
utilisé dans la pratique.
On notera qu’une jointure sans condition n’est rien d’autre qu’un produit cartésien.
Annexe 2 Langages SQL et QBE

Loin de nous l’idée de traiter ici en détails le langage SQL. La raison d’être de cette annexe est
uniquement pour donner un aperçu de la façon dont on interagit avec une base de données.
1. Le langage SQL
Crée par IBM en 1970, puis commercialisé en 1979 par ORACLE, le langage SQL (Structured
Query Language) est un langage de requête utilisé pour la définition et la manipulation des bases
de données relationnelles.
Lorsqu’en 1970, E. F. Cood élabora le modèle relationnel, plusieurs langages permettant de tra-
vailler avec une base de données relationnels virent le jour. Parmi ceux-ci, figurait le langage
Sequel développé par IBM. Il évolua vers Sequel/2. Ce dernier donna naissance au langage
SQL.
C’est en 1981 que le premier SGBD relationnel implémentant le langage SQL fut commercialisé.
Son nom, inconnu à l’époque est devenu depuis une référence internationale dans l’univers des
SGBD relationnel : Oracle.
L’intérêt du langage réside dans les caractéristiques suivantes :
• normalisation : le langage qui implémente le modèle relationnel est soutenu par les principaux
organismes de normalisation :
–– l’ANSI (American National Standards Institute) dans les documents ANSI 9075-1 : 1999,
ANSI 9075-2 :1999 et ANSI 9075-5 :1999,
–– l’ISO (International Organisation for Standardization) dans les documents ISO/IEC 9075-1 :
1999, ISO/IEC 9075-2 : 1999 et ISO/IEC 9075-5 : 1999 ;
• standard : du fait de cette normalisation, les grands éditeurs de SGBDR intègrent le langage
SQL à leurs produits : Informix, DB2, MySQL, PostgrSQL, ORACLE, SYBASE, etc. Par consé-
quent, il existe une grande portabilité entre différents SGBD des requêtes et des applications ;
• non procédural : du fait que le SQL soit un langage de requête et non un langage procédural,
il permet à un utilisateur d’obtenir un résultat sans se préoccuper des moyens techniques
sous-jacents mis en œuvre pour l’obtenir. L’optimisateur, qui est un des composants du moteur
de recherche d’un SGBD se charge de cette tâche.
106
Le langage SQL manipule aussi bien un unique enregistrement que des ensembles d’enregis-
trements. Il permet d’utiliser dans une commande le résultat d’une requête. Il est donc inutile
de recourir à des structures de contrôle comme dans bon nombre de langages de
programmation ;
• universel : le langage est utilisable à tous les niveaux de la gestion d’une base de données :
administration système, administration d’une base de données, développement, application, etc.
Tous les utilisateurs d’une base de donnés partagent donc un langage commun qui permet
d’effectuer toutes sortes d’opérations :
• interrogation de données ;
• ajout, suppression, modification de données ;
• gestion de structures ;
• gestion de la sécurisation des accès aux données ;
• etc.
En 1986, le SQL fut normalisé avec SQL/86. De légères modifications furent apportées en 1989.
En revanche, en 1992 de nombreuses améliorations eurent lieu. Celles-ci débouchèrent sur
SQL/92, plus communément nommé SQL2.
Au sein de SQL se trouve plusieurs autres langages.
• En premier, il s’agit d’un langage de définition de données, appelé DDL (Data Definition
Language). Celui-ci permet de créer, modifier et supprimer des tables dans une base de don-
nées via respectivement les ordres : CREATE27, DROP et ALTER
• En deuxième, il s’agit d’un langage de manipulation de données, appelé DML (Data
Manipulation Language). Celui-ci offre la possibilité de sélectionner, insérer, modifier ou sup-
primer des données via respectivement les ordres : SELECT, INSERT, UPDATE et DELETE.
• Enfin, en troisième et dernière position, il s’agit d’un langage de contrôle de données, appelé
DCL (Data Control Language). Celui-ci permet d’accorder ou de supprimer des droits à un
utilisateur via, respectivement, les ordres : GRANT et REVOKE.
Il est possible de recourir à une requête SQL soit directement, de façon interactive soit en
incluant les requêtes dans un programme informatique comme, par exemple, dans un script écrit
en Java ou en Php et placé côté serveur. Un large choix de langages informatiques supportant
l’inclusion de requêtes SQL existe.
Figure 77 – Intégration d’une requête SQL dans du code PHP
Requête SQL
27. Il est coutume d’écrire les ordres SQL intégralement en majuscule. Il ne s’agit en aucun cas d’une obli-
gation technique. Une requête SQL écrite en minuscules fonctionnera à l’identique avec une requête
écrite en majuscules.
202151TDPA0116 107
À titre d’exemple, illustrons quelques requêtes SQL réalisées à partir d’ordres du DDL :
EXEMPLE 1 : LIRE TOUS LES ÉLÉMENTS D’UNE TABLE

Le seul ordre nécessaire à la lecture de données dans une table est SELECT. Sa syntaxe géné-
rale est :
SELECT nom des colonnes à lire FROM Nom de la table ou des tables WHERE condition ;
Exemple : SELECT nom FROM inscrits; Cette requête retournera tous les noms contenus dans
la colonne nom de la table inscrits.
Il est possible de recourir à certains caractères dits « jokers ». L’un d’eux est fréquemment
utilisé. Il s’agit du caractère *. Il remplace toute chaîne de caractères.
Exemple : SELECT * FROM inscrits; Cette requête retournera la totalité des données conte-
nues dans la table inscrits.
Mais, avec cette requête, si des doublons existent, ils subsisteront. Pour les éliminer, il suffit
de le spécifier : SELECT DISTINCT nom FROM inscrits;
Il est également possible d’utiliser les opérateurs arithmétiques >, >=, <=, <, = et <> ainsi que
les trois opérateurs logiques AND, OR et NOT.
Exemple : SELECT nom FROM inscrits WHERE age > 18 AND age <= 25;
Cette requête sélectionne les noms présents dans la table inscrits si et seulement si leur âge
est strictement supérieur à 18 ans et inférieur ou égal à 25 ans.
Exemple : SELECT nom FROM inscrits WHERE ville IN (‘Paris’,’Bordeaux’);
Cette requête sélectionne les noms présents dans la table inscrits si et seulement si la valeur
de leur attribut ville est Paris ou Bordeaux.
Deux autres caractères jokers sont également disponibles. Le caractère de soulignement _
appelé underscore et le signe %. Le premier remplace n’importe quel caractère alors que le
second se substitue à n’importe quelle séquence de caractères ne pouvant pas être nul.
Exemple : SELECT nom FROM inscrits WHERE ville IN ‘P%’;
Cette requête sélectionne les noms présents dans la table inscrits si et seulement si la valeur
de leur attribut ville débute par la lettre P. Donc, des villes comme Paris, Paux, Périgueux28
conviennent.
Expression d’une jointure
Pour exprimer une jointure en langage SQL, on spécifie le nom des tables sur lesquelles la join-
ture porte et on exprime la condition à l’aide de la clause WHERE.
Exemple : Obtenir tous les éléments du produit cartésien étudiant x matière s’exprimera par la
requête : SELECT * FROM étudiants, matière;
Des possibilités de tris ascendants et descendants sont également offertes via la clause ORDER
BY à laquelle on spécifie le sens du tri désiré à l’aide des ordres ASC ou DESC.
Ces tris s’appliquent autant sur des valeurs numériques que littérale. Dans ce dernier cas, l’ordre
s’effectue sur la base de l’ordre alphabétique.
EXEMPLE 2 : CRÉER UNE NOUVELLE TABLE DANS UNE BASE DE DONNÉES
La syntaxe générale pour créer une table est la suivante :
CREATE TABLE nom_de_la_table (colonne1 type_donnee, colonne2 type_donnee, colonne3
type_donnee…);
Cette requête définit des colonnes en spécifiant pour chacune la nature de l’information qui
pourra y être insérée. Le mot-clé type_donnee sera donc à remplacer par un mot-clé comme,
par exemple INT, DATE, TEXT… Pour chaque colonne, il est également possible de spécifier
des options supplémentaires.
Bien d’autres possibilités sont encore offertes par le langage SQL. Cependant, nous arrêterons
là notre étude de ce langage. Nous invitons le lecteur désirant approfondir le sujet à se reporter
28. Nous arrêtons là l’énumération des noms de villes débutant par la lettre P, la France en compte 1 700 !
108
à des sites Web ou à des ouvrages spécialisés sur le sujet. Plusieurs sont cités dans la biblio-
graphie et dans la webographie en fin de série.
Cependant, avant de clore ce sujet, nous nous devons de dire également quelques mots sur
une alternative au langage SQL : QBE (Querry By Example)
2. Langage QBE
Dans l’objectif de simplifier l’élaboration de requêtes, IBM développa en 1978 un langage plus
graphique, plus visuel que la simple rédaction de requêtes relationnelles sous forme textuelle.
En travaillant avec QBE, l’utilisateur opère en simulant une réponse envisageable à sa requête.
Pour cela, il va opérer en deux temps :
• d’abord, le schéma de la table ou des tables concernées lui sera affiché sur son écran ;
• puis, une fois l’affichage disponible, l’utilisateur n’a plus qu’à cliquer dans les colonnes concer-
nées. Des options lui sont également offertes, mais toujours sous forme graphique qu’il n’a
qu’à sélectionner généralement par simple clics à l’aide de sa souris.
À l’image de SQL, les opérateurs de comparaison arithmétiques >, >=, <=, <, = et <> ainsi que
les trois opérateurs logiques AND, OR et NOT sont disponibles.
Mais, à l’inverse de SQL, QBE élimine automatiquement tous les doublons dans les réponses à
une requête dès qu’il en détecte. Alors que dans SQL il est nécessaire d’indiquer explicitement
que l’on souhaite éliminer les doublons, dans QBE, il est nécessaire de mentionner que l’on
souhaite les conserver. Cela se fait à l’aide de la commande ALL.
Par ailleurs, toujours à l’inverse de SQL, le langage QBE n’est pas normalisé. Aussi, chaque
constructeur de SGBD qui y recourt est à même de proposer sa propre implémentation. Il n’est
donc pas impossible de trouver des disparités d’une version à une autre.
De même, l’usage du langage QBE est quelque peu limité. S’il est aisé d’effectuer des requêtes
courantes, il en est tout autre dès que l’on augmente un tant soit peu la complexité des requêtes
devant être effectuées. En effet, le langage QBE ne se substitue qu’à l’unique commande
SELECT. Pour toutes les autres, il est obligatoire de recourir de nouveau au langage SQL.
Enfin, il est impossible de travailler avec le langage QBE autrement que de façon interactive
donc en direct, face à son écran. Aussi, de facto, toute volonté d’utilisation via un programme
applicatif comme, par exemple, dans une application de commerce électronique disponible sur
le Web est impossible.
Annexe 3 Normalisation des relations

Durant la phase de conception, la personne en charge de la création d’une base de données
relationnelle, se pose naturellement la question : « Parmi l’ensemble des relations envisageables
pour modéliser mon schéma conceptuel quelles sont celles à même d’éviter des problèmes
d’incohérence suite à des mises à jour ? »
Soit, par exemple, une université dont les cours, peuvent avoir lieu sur différents sites et qui sont
matérialisés par l’unique relation : Enseignement(repère, matière, enseignant, lieu, programme,
etc.). Rien n’interdira donc d’avoir plusieurs occurrences du même couple (matière, programme)
si les cours ont lieu sur différents sites.
Or, il est évident que cette relation devra respecter la contrainte d’intégrité « Dans une année
universitaire, une même matière doit avoir le même programme. » Mais, ces redondances sont
source de problèmes lors de mises à jour. Par exemple, il n’est pas impossible d’oublier de
modifier certaines occurrences.
Trois types d’anomalies peuvent se rencontrer :
• anomalie à l’insertion : telle qu’elle, cette relation interdit la mémorisation d’un programme
pour un cours qui n’existe pas encore ;
• anomalie à la suppression : quand un enseignement qui est l’unique représentant de son
type disparaît, par exemple par faute d’étudiants inscrits à l’UE, le programme associé dispa-
raît également ;
202151TDPA0116 109
• anomalie de modification : toute modification du programme d’enseignement doit absolument

être intégralement répercutée sur tous les tuples correspondant à cet enseignement. Le temps
de mise à jour est donc de ce fait allongé et, de plus, les risques d’incohérences augmentés.
Heureusement, des solutions existent. La théorie de la normalisation apporte des réponses à ces
problématiques. Cette théorie repose sur l’analyse des dépendances entre les attributs et l’ori-
gine des redondances. Elle propose une démarche rigoureuse et systématique qui permet la
décomposition de relations concernées. Il est toujours envisageable un retour à la relation origi-
nelle via l’opération de jointure de l’algèbre relationnelle.
Cette méthode conduit à des résultats qualifiés de « normaux ». Ce terme, à même d’être mal
interprété, nécessite une précision. Il ne s’agit pas d’un terme en opposition à « résultats anor-
maux ». Le terme « normaux » signifie que les résultats obtenus sont en conformité avec ceux
qui auraient été obtenus de façon empirique si l’on avait eu une bonne perception de la problé-
matique causée par des redondances.
Généralement, le concepteur d’une base de données élabore directement des relations norma-
lisées. Cependant, certains Ateliers de Génie Logiciel (ou AGL) produisent directement des
tables normalisées en partant du MCD. Cependant, bien que la normalisation des relations soit
un plus incontestable, certaines situations conduisent pour des raisons d’efficacité à devoir
« dénormaliser » des relations.
On distingue cinq formes normales dont trois principales qui, dans la plupart des cas, suffisent.
Mais, par souci d’exactitude, nous aborderons l’ensemble des cinq règles.
Avant de commencer, faisons quelques rappels.
Clé : elle définit un sous-ensemble minimal des colonnes dans une table tel que celle-ci ne
puisse contenir deux lignes ayant mêmes valeurs pour ces colonnes.
On distingue trois types de clés :
• la clé primaire : il s’agit d’un ensemble minimum d’attributs qui permet de distinguer chaque
n-uplet de la table par rapport à tous les autres. Chaque table doit avoir une clé primaire ;
• la clé candidate : il s’agit d’un ensemble minimum d’attributs susceptibles de jouer le rôle de
la clé primaire ;
• la clé étrangère : cela fait référence à la clé primaire d’une autre table.
Par ailleurs, une contrainte d’intégrité référentielle ou d’inclusion lie deux colonnes ou deux
ensembles de colonnes de deux tables différentes.
A – Première forme normale
On dit qu’une relation est en 1re forme normale, ce que l’on note « 1NF » lorsque tous ses attri-
buts sont atomiques. Cela signifie qu’aucun attribut ne peut être décomposé à la vue du contexte
dans lequel est abordée cette relation. En d’autres termes, une relation est 1NF si aucun de ses
attributs n’est lui-même une relation entre des « sous-attributs ».
Nom Notes
Dupond 12 19
Durand 18 14
Exemple : La relation définie par la table n’est pas 1NF.

Pour la rendre 1NF, on doit soit avoir un attribut29 pour chaque note à mémoriser soit avoir autant
de tuples que de couples (nom, note).
La première solution impose que le nombre maximal de notes soit préalablement connu et que
pour chaque élève son nombre de notes ne dépasse jamais ce maximum. Par exemple :
Nom Mathématiques Informatique
Dupond 12 19
Durand 18 14
29. Donc une colonne.
110
La seconde solution augmente d’autant le nombre de lignes qu’il y a de tuples c’est-à-dire de

couples (nom, note). Par exemple :
Nom Note
Dupond 12
Dupond 19
Durand 18
Durand 14
B – Deuxième forme normale

Une relation est dite être en deuxième forme normale, ce que l’on note 2NF, si la relation est en
1NF et si un attribut qui n’appartient à aucune clé soit en dépendance élémentaire avec toutes
les clés. Il n’y a donc aucune dépendance partielle.
En d’autres termes, à partir du moment où un attribut qui n’appartient pas à une clé dépend
d’une partie d’une clé, la relation n’est pas en 2NF. Par conséquent, des redondances d’informa-
tions peuvent exister. Par exemple, soit la relation définie par :
Inscrit_A_UE(matricule, NomEleve, PrenomEleve, DateNaissance, NomUe, Professeur, Lieu,
Programme, Annee_Inscription)
Plusieurs dépendances fonctionnelles existent entre attributs :
• Matricule  NomEleve
• NomUe  Professeur, Lieu, Programme
• Matricule, NomUe  Annee_Inscription
Par application des propriétés des dépendances fonctionnelles on obtient :
Matricule, NomUe  NomEleve, Professeur, Lieu, Programme, Annee_Inscription
L’unique clé de cette relation est Matricule, NomUe. Or, NomEleve, Prenom, DateNaissance et
Annee_Inscription ne dépendent que de Matricule. De même, Professeur, Lieu et Programme ne
dépendent que de NomUe.
Cette relation n’est donc pas en 2NF. En effet, dès qu’un élève s’inscrit à plusieurs UE la même
année, ce qui est généralement le cas, son nom et son année d’inscription sont initialement
reproduits dans la base. De même, le nom de l’UE est répété pour chaque inscription.
Il faut donc appliquer le théorème de décomposition sur les dépendances fonctionnelles fau-
tives. Cela conduit à éclater la relation et débouche sur :

• Eleve(Matricule, NomEleve, PrenomEleve, DateNaissance)
• UE(NomUe, Professeur, Lieu, Programme)
• Inscription(Matricule, NomUe, Annee)
C – Troisième forme normale

Une relation est dite en troisième forme normale, ce que l’on note 3NF, dès lors qu’elle est en
2NF mais que de plus, quand aucun de ses attributs qui n’appartient pas à une clé ne dépend
pas d’un attribut non clé.
En d’autres termes, une relation n’est pas en 3NF dès que dans celle-ci il existe une dépendance
fonctionnelle entre deux attributs qui n’appartiennent pas à une clé.
Dès qu’une relation n’est pas en 3NF, des redondances d’informations sont possibles. Exemple,
soit la relation :
Professeur(Nom, Local, Matière, Bureau, Lieu) et les deux contraintes :
• un local ne regroupe exclusivement que des enseignants d’une même matière ;
• dans un local, chaque bureau ne contient qu’un unique poste téléphonique.
Il est évident que l’attribut Nom est la clé de cette relation puisque c’est à partir d’un nom que
l’on peut établir les liens avec les autres informations. Par ailleurs, les règles de gestion, c’est-à-
dire les contraintes se traduisent par les dépendances fonctionnelles suivantes :
• Bâtiment  Matière(Département)
• Bâtiment, Bureau  Téléphone
• Téléphone  Bureau, Bâtiment
202151TDPA0116 111
La dépendance Bâtiment  Discipline ne concernant pas la clé, la relation Enseignant n’est

donc pas en 3NF.
En exploitant le théorème de décomposition de façon à isoler les dépendances fonctionnelles,
on obtient alors les relations :
• Siège(Nom, Bureau, Bâtiment)
• Annuaire(Bureau, Bâtiment, Téléphone)
• Affectation(Bâtiment, Discipline)
Théorème : Toute relation admet une décomposition en 3NF à jonction conservatrice, donc sans
perte, et avec préservation des dépendances fonctionnelles.
Le processus de conception de schéma relationnel, de la qualité duquel va dépendre la perti-
nence et l’efficacité de la base de données, devra prendre en compte ces critères : normalité,
préservation des contenus, préservation des dépendances fonctionnelles.
Or, à partir du recueil des dépendances fonctionnelles, il est possible de construire un « bon »
schéma relationnel en exploitant des manipulations algorithmiques de dépendances telles que
la recherche de clés, et des algorithmes de conception de schéma relationnel en 3NF tels que
l’algorithme de synthèse ou l’algorithme de décomposition.
L’algorithme de conception de schéma relationnel en 3NF, appelé algorithme de synthèse, peut
se décomposer en quatre étapes.
Celui-ci, sortant amplement du cadre du cours, il ne sera pas abordé ici. Nous laissons le lecteur
intéressé se reporter à des ouvrages spécialisés au sein desquels il trouvera bon nombre de
détails et d’exemples illustrés.
D – Troisième forme normale dite « de Boyce-Codd »

Les schémas en 3NF, bien qu’épurés des situations les plus courantes d’anomalies, n’en sont
pas pour autant toujours exemptes. Il convient donc parfois de pousser plus loin l’analyse. Mais,
il s’agit de cas peu fréquents.
En effet, il est encore possible que des dépendances existent entre un attribut non clé vers un
attribut clé. Ce schéma génère alors de nouveaux problèmes de redondance. La forme normale
de Boyce-Codd tente de prendre en compte ce critère supplémentaire pour assurer un schéma
valide.
On dit qu’une relation est en 3NF de Boyce-Codd, que l’on note BCNF, si elle est déjà en 3NF et
que de plus, les seules dépendances fonctionnelles élémentaires sont celles dans lesquelles une
clé candidate détermine un attribut.
Contrairement à la 3NF, il ne doit plus y avoir de dépendances d’attribut vers une clé. Exemple :
Soit la relation Cours(Matière, Classe, Professeur) et les règles de gestion dont les contraintes
sont :
• un professeur n’enseigne qu’une seule matière ;
• une classe n’a qu’un seul enseignant par matière.
Nous en déduisons donc les dépendances fonctionnelles :
• Matière, Classe  Professeur
• Professeur  Matière
Cette relation est en 3NF, néanmoins il est impossible d’enregistrer un professeur sans classe
affectée et la suppression d’une classe entraîne la disparition du professeur associé. Clairement,
cela résulte du fait qu’une dépendance fonctionnelle n’a pas comme origine une clé de la
relation.
Pour sortir de ce piège, nous utiliserons de nouveau le théorème de décomposition. Nous obte-
nons alors deux nouvelles relations : Compétence(Professeur, Matière) et Affectation(Professeur,
Classe).
Il faut noter que la dépendance fonctionnelle Matière, Classe Professeur est éclatée. Cela peut
avoir comme conséquence, si l’on n’y prend pas garde, de venir en contradiction avec la règle
de gestion dont la dépendance fonctionnelle perdue est l’expression.
112
Une décomposition en BCNF est préférable à une simple décomposition en 3NF mais unique-
ment si elle conserve les dépendances fonctionnelles initiales. Sinon, il est préférable de rester
en 3NF.
Avant d’aborder la quatrième forme normale, nous devons examiner les dépendances
multivaluées.
E – Dépendances multivaluées
Les redondances et anomalies de mise à jour n’ont pas exclusivement pour cause une dépen-
dance fonctionnelle, c’est-à-dire un groupe d’attribut fonction d’un autre, bien que résultant
d’une forme de dépendance interattributs : la dépendance multivaluée.
Exemple :
Soit la relation Renseignements(Diplôme, NomEnfant). Comme une personne est à même d’avoir
plusieurs diplômes et plusieurs enfants et qu’un enfant a généralement deux parents, on ne peut
mettre à jour ici aucune dépendance fonctionnelle ; la clé de cette relation est constituée de
l’ensemble de ses attributs et, de plus, elle est en BCNF.
Or, dès qu’une même personne a plus d’un diplôme et plus d’un enfant, des redondances appa-
raîtront au sein de la relation. Ainsi, pour rendre compte, par exemple, de la relation Ma Dalton a
quatre fils, Joe, Jack, William et Awerell, ainsi qu’un master de pédagogie et un master de droit
pénal, il faut exhiber huit tuples :
Pédagogie Ma Dalton Joe
Pénal Ma Dalton Joe
Pédagogie Ma Dalton Jack
Pénal Ma Dalton Jack
Pédagogie Ma Dalton William
Pénal Ma Dalton William
Pédagogie Ma Dalton Awerell
Pénal Ma Dalton Awerell
Il est inutile d’insister sur les pénalisations induites par ces nombreuses redondances lors des
opérations de mise à jour. Pour toute obtention, radiation ou modification d’un diplôme, l’opéra-
tion devra être répétée autant de fois qu’il y a d’enfants.
Intuitivement, on perçoit que ce n’est plus le diplôme mais un ensemble de diplômes qui dépend
du nom des enfants et réciproquement. C’est d’une situation semblable à celle-ci que vient
l’extension de la notion de dépendance fonctionnelle à la notion de dépendances multivaluées.
F – Quatrième forme normale

On dit qu’une relation est en quatrième forme normale, que l’on note 4NF, quand toutes les
dépendances multivaluées, y compris les dépendances fonctionnelles, non triviales ont comme
déterminant une clé de la relation ou un groupe d’attributs contenant une clé. Cette définition
implique que toute relation en 4NF est de facto en BCNF.
Exemple :
Supposons que soit effectué le recensement d’équipes lors de rencontres sportives au travers
de la relation : Composition(IdentificationMatch, MembreEquipeA, MembreEquipeB).
La clé de cette relation est : IdentificationMatch, MembreEquipeA, MembreEquipeB.
On ne peut mettre en évidence aucune dépendance fonctionnelle : pour un match donné, les
équipes A et B sont composées de plusieurs membres ; les joueurs ont également participés à
plusieurs matchs.
En revanche, pour un match, la composition des équipes est unique et il n’y a aucun lien formel
entre les deux.
Nous avons donc Identification  MembreEquipeA ainsi que Identification  MembreEquipeB.
Donc, la relation Composition n’est pas en 4NF bien qu’elle soit en BCNF.
202151TDPA0116 113
De nouveau, l’algorithme sur la décomposition des relations peut s’appliquer pour obtenir un
schéma relationnel en 4NF. Nous arrivons de ce fait aux deux nouvelles relations :
• CompositionA(Identification, MembreEquipeA) ;
• CompositionB(Identification, MembreEquipeB).
De nouveau, abordons deux autres notions avant d’examiner la cinquième et dernière forme
normale.
G – Dépendances hiérarchiques
Soit la relation RencontresParEquipe(IdentificationMatch, MembreEquipeA, MembreEquipeB,
Résultat) pour laquelle on suppose qu’il s’agit de rencontres de judo par équipes et au cours
desquelles, tout membre d’une équipe rencontre chaque membre de l’équipe adverse. Ce sont
les résultats de ses combats individuels qui sont représentés par l’attribut Résultat.
On observe ici une dépendance fonctionnelle relative à la signification de l’attribut Résultat telle
que l’on vient de le préciser : IdentificationMatch, MembreEquipeA, MembreEquipeB  Résultat.
Comme précédemment, pour un match donné, les équipes A et B ont toujours une composition
unique mais on ne peut pas parler ici de dépendance fonctionnelle.
En effet, pour un match donné, on ne peut pas séparer les couples de combattants puisque les
résultats des combats y sont liés. Donc, les ensembles d’attributs IdentificationMatch,
MembreEquipeA, MembreEquipeB, Résultat ne sont pas indépendants.
Nous sommes en présence d’un nouveau type de contrainte d’intégrité qui possède la propriété
d’être multivaluée sur une projection de la relation. On nomme ce type de contrainte d’intégrité
une dépendance hiérarchique.
H – Dépendance produit
Soit un groupe de magasins franchisés disposant d’une certaine autonomie mais devant malgré
tout respecter certaines obligations imposées par le groupe. Supposons que celui-ci négocie
auprès d’un certain nombre de marques l’accord suivant : Si un franchisé propose un certain
type d’article mais que ce type d’article figure au catalogue d’une des marques déjà présente en
magasin alors il ne devra proposer à la vente que ceux de la marque déjà présente en magasin.
Les franchisés ne travaillent qu’avec les marques ayant passé un tel accord auprès du groupe.
Par exemple, si un franchisé commercialise des polos Laboste et des parfums Yves S’Implorant,
le franchisé est dans l’obligation de vendre également des parfums Laboste.
Soit donc la relation : Produit(IdentifiantFranchisé, TypeProduit, MarqueProduit) stipulant qu’un
franchisé F commercialise le produit de type T de la marque M.
Analysons les dépendances interattributs. Il n’y a pas de dépendances fonctionnelles non tri-
viales. La clé de la relation est IdentifiantFranchisé, TypeProduit, MarqueProduit.
En effet, si l’on a : IdentifiantFranchisé  TypeProduit et, par conséquent, également
IdentifiantFranchisé  MarqueProduit, il n’y aura plus de lien entre les types de produit et les
marques alors qu’un magasin distribuant un type de produit T et diffusant également la marque
M ne doit distribuer que des articles de type T de la marque M.
De même, si l’on a : TypeProduit  IdentifiantFranchisé et par conséquent également TypeProduit
 MarqueProduit cela signifie qu’un franchisé commercialisant un type de produit T est obligé
de travailler avec toutes les marques disposant de ce type de produit, ce qui ne figure pas dans
les termes du contrat.
Enfin, si l’on a : MarqueProduit  IdentifiantFranchisé et par conséquent MarqueProduit 
TypeProduit cela signifie qu’un franchisé diffusant une marque est obligé de commercialiser tous
les produits de cette marque. Cela ne figure également pas dans les termes du contrat.
Ces différentes situations conduisent à la cinquième forme normale.
114
I – Cinquième forme normale

Une relation est en cinquième forme normal, que l’on note 5NF, à la condition qu’elle soit en 4NF
et que toute dépendance produit soit induite par une clé candidate.
J – Conclusion sur la normalisation des relations

La théorie de la normalisation permet de définir formellement la qualité des tables au regard du
problème posé par la redondance des données. La théorie de la normalisation s’appuie sur la
dépendance fonctionnelle. Cod a défini un ensemble de formes normales caractérisant les tables
relationnelles.
L’étude des différentes formes de dépendances interattributs et les degrés de normalisation
d’une relation n’a pas pour ambition de substituer une approche purement formelle à une
approche plus intuitive en phase avec l’interprétation naturelle des attributs manipulés.
Sa principale vocation est d’identifier clairement les causes, les effets directs et secondaires
ainsi que les remèdes aux différentes formes de redondances d’informations, sources inévi-
tables d’erreurs.
Les trois premières formes normales qui couvrent la quasi-totalité des cas, se résument en :
• première forme normale (1NF) : quand elle ne contient que des attributs atomiques ;
• deuxième forme normale (2NF) : si elle est 1NF et si, de plus, il n’existe aucune dépendance
fonctionnelle entre la partie d’une clé et une colonne non clé de la table ;
• troisième forme normale : si elle est 2NF et si, de plus, il n’existe aucune dépendance fonc-
tionnelle entre les colonnes non clé.
Plus une table est normalisée et moins elle comporte de redondances et donc de risques d’inco-
hérence et pose de problèmes.
Annexe 4 Gestion des transactions
A – Tolérance aux pannes

Un système informatique, comme tout autre équipement, est sujet à des pannes. L’une des plus
fréquentes est sans doute la coupure soudaine d’alimentation électrique.
Dans une telle circonstance, la perte de données peut s’avérer être catastrophique. Aussi, un
SGBD doit être en mesure de proposer un mécanisme permettant de reprendre sans consé-
quences néfastes un traitement subitement interrompu.
Bien sûr, il n’est pas concevable, par exemple, dans le cas d’une mise à jour interrompue suite
à une panne de devoir de nouveau relancer le traitement qui était en cours d’exécution, les infor-
mations déjà modifiées avant la panne le seraient de nouveau. De même, il n’est pas envisa-
geable de devoir abandonner définitivement la mise à jour, seule une partie des informations
auraient été mises à jour. Dans un cas comme dans l’autre, la base de données serait dans un
état d’incohérence.
L’exemple classique concerne une application bancaire dans laquelle un transfert d’une somme
S doit avoir lieu entre le compte A et le compte B. L’une des contraintes du SI consiste à toujours
s’assurer que la somme des soldes des comptes A et B est constante avant et après la réalisa-
tion du transfert. Autrement, si l’interruption se produit après que le compte A soit débité mais
avant que le compte B ne soit crédité de la somme débitée, l’argent se serait volatilisé à jamais.
La règle à suivre est simple : la base doit toujours être dans un état cohérent. Il est donc néces-
saire de pouvoir définir des suites d’opérations considérées par le système comme atomique,
c’est-à-dire indivisibles, au sens où soit toutes les actions de cette suite sont exécutées et vali-
dées soit aucune ne l’est. De cette façon, la base de données peut rester dans un état
cohérent.
202151TDPA0116 115
Par ailleurs, durant l’exécution de ces actions, un autre utilisateur ne doit pas pouvoir accéder à
des données en cours de modification mais uniquement qu’à la fin du traitement comme, par
exemple, lors d’une mise à jour. Ceci définit l’isolation du code.
Ces différents points conduisent à la notion de transaction qui a pour but essentiel de préserver
la cohérence d’une base de données.
Définition : une transaction est une unité de traitement séquentiel constituée d’une suite d’ins-
tructions à réaliser sur une base de données et qui appliquée à une base cohérente, restitue une
base cohérente.
Une transaction doit impérativement respecter des principes que l’on résume sous l’appellation
ACID :
• atomicité : soit toute est exécuté soit rien ne l’est ;
• cohérence : toutes les contraintes doivent être respectées. Une base de données cohérente
avant doit également l’être après ;
• isolation : rien n’est visible de l’extérieur tant que tout n’est pas terminé ;
• durabilité : les actions effectuées par une transaction une fois terminée persistent.
C’est un programme particulier, nommé moniteur transactionnel, qui a la charge du respect de
ces propriétés durant l’exécution des transactions. Le programmeur n’a pas à s’en soucier.
Du point de vue du programmeur, une transaction n’est ni plus ni moins qu’un programme qui
accède à une base de données et qui peut être constitué d’une simple requête avec les ordres
du langage de manipulation de données30 ou être élaboré à partir du langage hôte.
Il n’existe aucune différence entre une transaction et un programme applicatif quelconque. Une
transaction n’est rien d’autre qu’un programme classique géré par un moniteur transactionnel.
Une transaction peut connaître quatre étapes :
• active : il s’agit de l’état initial conservé tant qu’aucune anomalie ne se produit ;
• partiellement validée : c’est l’état dans lequel se trouve la transaction quand la dernière ins-
truction de la transaction a été atteinte ;
• échouée : il s’agit de l’état à la suite d’une anomalie logique ou physique ;
• validée : c’est l’état dans lequel se trouve la transaction après une exécution totalement
terminée.
L’action de validation d’une transaction est effectuée par l’ordre Commit. Cet ordre peut être
explicite dans une transaction où, comme c’est la plupart du temps le cas, implicite et exécuté
à la fin de la transaction par le SGBD. Une fois l’ordre commit exécuté, les modifications réali-
sées sont irrémédiables et la transaction est validée.
Si la transaction échoue, le SGBD doit naturellement revenir à l’état précédant le début de la
transaction puisque c’est le dernier point de garantie de cohérence. Cela est fait automatique-
ment par le SGBD via la commande Rollback.
L’administrateur a alors la possibilité soit de relancer la transaction si le problème était physique
et qu’il n’existe plus, soit de mettre fin définitivement à cette transaction si le problème était
logique comme, par exemple, une mauvaise conception de la transaction. Pour assurer la reprise
sur panne, le SGBD utilise la notion de journal.
Définition : un journal est un fichier texte dans lequel la SGBD inscrit dans l’ordre toutes les
actions de mise à jour qu’il a effectué. Il s’agit de l’historique, de la mémoire des actions effec-
tuées préalablement.
Il existe plusieurs méthodes de gestion d’atomicité d’une transaction à l’aide d’un journal. L’une
des plus utilisée est l’utilisation d’un journal incrémental avec mise à jour immédiate.
B – Accès concurrent aux données

Jusqu’à présent nous avons étudié l’ensemble des primitives d’accès à une base de données
sans tenir compte du fait qu’en général plusieurs utilisateurs y accèdent simultanément.
30. Ou DML pour Data Manipulation Language.
116
Les transactions décrites précédemment étaient considérées comme séquentielles. L’accès aux
données par plusieurs transactions simultanées est un point essentiel pour l’efficacité d’une
base de données. L’accès concurrent permet de partager les ressources machine et d’optimiser
ainsi le temps CPU.
Le problème principal de l’accès concurrent réside dans les opérations de mise à jour. Que se
passe-t-il quand plusieurs utilisateurs tentent de modifier la même donnée au même moment ?
Si le système ne prend pas de précaution des incohérences sont susceptibles d’apparaître dans
la base de données.
On dit que deux transactions sont concurrentes si elles accèdent simultanément aux mêmes
données. L’exécution d’un ensemble de transactions concurrentes est représentée par un inter-
classement de diverses actions de chaque transaction. On considère bien sûr qu’une exécution
doit préserver l’ordre d’opposition des instructions de chacune des transactions.
C – Caractériser les exécutions correctes

Le contrôleur de concurrence est la partie du SGBD qui contrôle l’exécution simultanément de
transactions de façon à produire les mêmes résultats qu’une exécution séquentielle. Cette pro-
priété essentielle des systèmes distribués est nommée sérialisabilité.
Définition : une exécution d’un ensemble de transactions est dite « sérialisable » si elle donne
pour chaque transaction participante le même résultat que l’exécution en série de ces mêmes
transactions.
Une condition suffisante pour assurer l’absence de conflit consiste à s’assurer que le méca-
nisme de contrôle de concurrence ne peut générer que des exécutions sérialisables. Le rôle du
contrôle de concurrence consiste donc à n’autoriser lors de l’exécution de transactions concur-
rentes que des exécutions sérialisables.
D – Le système de verrouillage
Afin d’assurer que seules des exécutions sérialisables seront exécutées, plusieurs mécanismes
existent. L’outil le plus répandu pour mener à bien cette tâche est basé sur l’utilisation de
verrous.
On impose que l’accès aux données se fasse de façon mutuellement exclusive. Un verrou est
posé sur chaque donnée sujette à une transaction afin d’empêcher les autres transactions d’y
accéder.
On considère qu’un verrou est placé sur une donnée avant une lecture ou une écriture sur celle-
ci. Si une transaction tente de verrouiller une donnée déjà verrouillée, elle est mise en attente et
obligée d’attendre que l’autre transaction débloque cette donnée.
La taille de la donnée verrouillée est nommée granularité. C’est au gestionnaire de verrous
qu’incombe la tâche de gérer l’accès aux données. Une forte granularité implique un faible paral-
lélisme alors qu’une faible granularité implique la gestion d’une table de verrous importante.
Les systèmes actuels parviennent généralement à travailler de façon idéale en ne bloquant que
les lignes des données concernées par la transaction et non une table entière.
Dans la majorité des systèmes, il existe trois types de verrous :
• les verrous posés en cas de lecture : si une transaction lit une donnée, aucune autre tran-
saction ne doit pouvoir la modifier tant que cette transaction n’est pas terminée. C’est le mode
partage ;
• les verrous posés en cas de sélection pour mise à jour : d’autres transactions peuvent lire
les données, à condition qu’elles n’aient pas l’intention de les modifier. C’est le mode
protégé ;
• les verrous posés en cas d’écriture : si une transaction vient d’écrire une donnée, aucune
autre ne doit pouvoir la lire tant que cette transaction n’est pas terminée. C’est le mode
exclusif.
202151TDPA0116 117
E – Le protocole à deux phases

S’il est aisé de savoir quand poser les verrous, leur suppression est beaucoup plus complexe.
En effet, de nouvelles précautions sont à prendre. Si on tente d’augmenter le rendement du trai-
tement simultané des transactions en déverrouillant les données dès que possible, la base peut
se trouver en état inconsistant. À l’inverse, si on ne déverrouille pas un article avant d’en verrouil-
ler un autre, on crée des interblocages. Il faut donc imposer aux transactions un protocole de
verrouillage à deux phases, qui garantit la sérialisabilité lors de leur exécution.
Ce protocole implique que chacune des transactions émette ses demandes de verrouillage et de
déverrouillage en deux phases distinctes :
• verrouillage croissant : la transaction peut obtenir de nouveaux verrouillage mais pas de nou-
veaux déverrouillages.
• verrouillage décroissant : la transaction peut obtenir des déverrouillages mais pas de nou-
veaux verrouillages.
Initialement, une transaction est en phase de verrouillage croissant. Lorsqu’elle libère un verrou,
elle entre en phase de décroissance et aucun verrouillage ne peut plus être demandé.
118
Bibliographie et webographie
Bibliographie
Références bibliographiques
• Comprendre Merise – Outils conceptuels et organisationnels
De : Jean-Patrick Matheron, éditions Eyrolles, 1994 ISBN : 2-212-07502-2
• UML2 – Pratique de la modélisation
De : Benoît Charroux, Aomar Osmani et Yann Thierry-Mieg, éditions Pearson
ISBN : 2-7440-7287-1
Ouvrages spécifiques au DSCG 5
• Management des systèmes d’information – Manuel, Applications & Corrigés
De : Annelise Couleau-Dupont et Régis Tombarel, éditions Nathan, 2011
ISBN : 978-2-09-160683-5
• Management des systèmes d’information – Manuel et applications
De : Michelle et Patrick Gillet, éditions Dunod, 2010, ISBN : 978-2-10-054912-2
• Réussir le DSCG 5
De : Virginie Billet, Valérie Guerrin et Miguel Liottier, éditions Eyrolles, 2012
ISBN : 978-2-212-55506-6
Ouvrages spécifiques à la méthode Merise
• Se former à Merise : La modélisation conceptuelle
De : Gérald Louvet, Les éditions d’organisation, 1990, ISBN : 2-7081-1146-9
• Exercices et cas pour comprendre Merise
De : Jean-Patrick Matheron, éditions Eyrolles, 1994, ISBN : 2-212-07501-4
Ouvrages spécifiques au langage UML
• Introduction à UML
De : Sinan Si Albir, traduction d’Alexandre Gachet, éditions O’Reilly, 2003
ISBN : 2-84177-279-9
• Le tout en poche UML
De : Martin Fowler avec la collaboration de Kendall Scott, éditions CampusPresse, 2003,
ISBN : 2-7440-1482-6
• UML2 – Initiation, exemples et exercices corrigés
De : Laurent Debrauwer et Fien Van der Heyde, éditions ENI, 2005
ISBN : 2-7460-1455-6
• UML2 – Entraînez-vous à la modélisation
De : Laurent Debrauwer et Naouel Karam, éditions ENI, 2006
ISBN : 2-7460-3360-7
Ouvrages spécifiques au BPMN
• Architecture logicielle - Concevoir des applications simples, sûres et adaptables
De : Jacques Printz, éditions Dunod, 2012, ISBN : 2-10-057865-0
• BPM, Business Process Management : pilotage métier de l’entreprise
De : Bernard Debauche et Patrick Mégard, éditions Lavoisier, 2004
Ouvrages spécifiques à l’urbanisation
• Le projet d’urbanisation du SI – Cas concret d’architecture d’entreprise
De Christophe Longépé, éditions Dunod, 2009, ISBN : 978-2-10-052883-7
• Urbanisme des SI et gouvernance – Retour d’expérience et bonnes pratiques
De : Club Urba-EA31, éditions Dunod, 2006, ISBN : 2-10-0496678-6
31. Ouvrage collectif.
202151TDPA0116 119
• Urbanisation et BPM – Le point de vue d’un DSI

De : Yves Caseau, éditions Dunod, 2005, ISBN : 2-10-048724-8
Webographie
• http://sql.sh/cours/select
• http://www.commentcamarche.net/contents/1062-le-langage-sql
• https://openclassrooms.com/ (de nombreux supports de cours y sont disponibles gratuitement)
• http://www.developpez.com/ (de nombreux supports de cours y sont disponibles gratuitement
et il existe un forum dans lequel il est possible de poser des questions)
120
UE 215
Devoir 1
Management des systèmes d’information
Année 2016-2017
À envoyer à la correction
Auteur : Dominique GATINAUT
EXERCICE : SOCIÉTÉ JOUERETAPPRENDRE (20 POINTS)
Faisons connaissance avec la société JouerEtApprendre. Elle commercialise, exclusivement via le Web,
des jeux à vocation pédagogique pour enfants de 6 à 12 ans.
Chaque parent intéressé se connecte sur le site puis crée son compte en fournissant certaine informa-
tions via un formulaire en ligne. Après validation, muni de son couple « identifiant/mot de passe », il peut
alors acheter le nombre de crédits qu’il désire. Plusieurs offres commerciales sont proposées.
Ensuite, pour chaque utilisation, après avoir été correctement identifié par le site, il suffit de sélectionner
le jeu désiré. Selon le choix effectué, le nombre de crédits consommés varie. Lorsque le solde de crédits
disponible avoisine la valeur la plus faible associée à un jeu, un message d’alerte, proposant d’acquérir
de nouveaux crédits, est affiché.
Si le nombre de crédits disponible est insuffisant pour accéder au jeu désiré, un message d’information
est affiché sur l’écran de l’utilisateur et l’invitant également à renouveler ses crédits. Après la troisième
tentative infructueuse, une déconnection automatique du site est effectuée.
Le site Web est donc au cœur de la stratégie de JouerEtApprendre puisqu’il lui permet non seulement de
diffuser ses jeux éducatifs, de faire entrer de la trésorerie via les achats de crédits mais également d’ac-
quérir de nouveaux clients.
Lors de son inscription, alors qu’il renseigne le formulaire en ligne, un client est amené à fournir les infor-
mations suivantes : Civilité (à choisir entre Mme et M.), Prénom, Nom, Adresse postale, Nombre d’en-
fants à inscrire (limité à trois), Âge de chaque enfant inscrit, Adresse de courriel, Langue à privilégier pour
l’affichage (à choisir entre Français, Allemand, Anglais et Espagnol), Type du périphérique généralement
utilisé (à choisir entre PC, Tablette et Smartphone) et Domaine privilégié (à choisir entre Grammaire/
Orthographe, Mathématiques, Histoire, Géographie, Langues).
TRAVAIL À FAIRE
1. Dressez la liste des données relatives à un client qui devront figurer dans le dictionnaire des don-
nées. (2 points)
2. Si à partir du dictionnaire des données, tel que réalisé à la question précédente, on établit une table
pour l’entité « Client » dans la base de données du site Web, les relations incluant « Client » seront-
elles en première forme normale (1NF) ? Pourquoi ? Seront-elles en seconde forme normale (2NF) ?
Pourquoi ? (3 points)
3. Pourrait-on sélectionner une clé primaire ? Pourquoi ? (2 points)
4. Quelle pourrait-être une clé primaire intuitive pour la table « Client » de la base de données ?
(2 points)
5. Établissez le MCD de la relation « Acheter des crédits » en prenant en compte la solution proposée
à la question précédente. (2 points)
6. Établissez le MLD associé au MCD précédent. Donnez pour l’entité « Client » une structure de table
ne contenant que des attributs de type atomique. (3 points)
7. Établissez le diagramme UML de séquences correspondant à l’utilisation d’un jeu éducatif en ligne.
(2 points)
8. Donnez le diagramme BPMN modélisant l’interaction d’un utilisateur avec le site. (2 points)
202151TDPA0116 121
✄
Management des systèmes d’information • Devoir 1
Pour la construction du site Web, on a utilisé au logiciel serveur Web Tomcat, au langage Java pour les
scripts et au SGBD MySQL. Une machine serveur héberge le serveur Tomcat ainsi que les scripts Java
alors que MySQL est hébergé sur une seconde machine serveur. Il s’agit là du premier système d’infor-
mation de l’entreprise.
9. Pensez-vous qu’il soit justifié de procéder à une urbanisation de ce système d’information ?
Pourquoi ? (2 points)
122
✄
Powered by TCPDF (www.tcpdf.org)

Ue Msi

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ue Msi

Загружено:

Авторское право:

Доступные форматы

DSGC

UE 215  MANAGEMENT DES

DE LA DÉFINITION À LA CONCEPTION DES SYSTÈMES

L’ensemble des contenus (textes, images, données, dessins, graphiques,

Table des matières

PLAN ANNUEL DU COURS 9

Partie 1. DE LA DÉFINITION À LA CONCEPTION

I. Qu’est-ce qu’un système d’information ?............................................13

III. De la conception à la modélisation d’un SI.........................................28

D. L’émergence de l’entreprise numérique............................................80

II. Pourquoi urbaniser ?.............................................................................97

IV. La démarche d’urbanisation...............................................................100

I. PROGRAMME DE L’UE 215 :

Sens et portée de l’étude Notions et contenus

Sens et portée de l’étude Notions et contenus

Sens et portée de l’étude Notions et contenus

II. DÉROULEMENT DU TRAVAIL EN COURS À DISTANCE

III. DÉROULEMENT DE L’ÉPREUVE DU DSGC

Plan annuel du cours

PARTIE 1. DE LA DÉFINITION À LA CONCEPTION DES SYSTÈMES

PARTIE 3. LE SYSTÈME D’INFORMATION ET SON DÉCOUPAGE EN DOMAINES

PARTIE 4. LES LOGICIELS MÉTIERS POUR LES GESTIONNAIRES

PARTIE 5. LA GESTION DE PROJETS SYSTÈMES D’INFORMATION

PARTIE 6. LES INFRASTRUCTURES TECHNOLOGIQUES DE L’INFORMATION

PARTIE 7. LA SÉCURITÉ DES SYSTÈMES D’INFORMATION

PARTIE 8. LES NORMES ET LES RÉFÉRENTIELS DES AUDITS DES SYSTÈMES

Cette première série a pour objectifs de :

ment de chercher à résoudre chacun d’eux sans consulter avant la solution. Ne

BPMN Business Process Model and Notation

I. QU’EST-CE QU’UN SYSTÈME D’INFORMATION ?

Figure 1 – Système opérant et son système de pilotage2

Système de pilotage Objectifs

Entrées Système opérant Sorties

Figure 2 – Place d’un SI dans l’ensemble

Système de pilotage Objectifs

Entrées Système opérant Sorties

Figure 3 – Processeur d’information

C. LES ACTIONS PROGRAMMÉES ET LES DÉCISIONS

Figure 4 – Actions programmées

Figure 5 – Information incomplète nécessitant une décision

Entrée (E) Sortie 2

D. LES NIVEAUX D’ABSTRACTION D’UN SI

E. LE FICHIER ET LA BASE DE DONNÉES

1. Base de données de type réseau

2. Base de données de type hiérarchique

3. Base de données de type relationnel

Élèves(Matricule_el, Prénom, Nom)

Élèves Matricule_el Prénom Nom

Enseignants Matricule_en Prénom Nom Matière

Notes Matricule_el Matricule-en Mathématiques Physique Informatique

4. Base de données de type « orienté objets »

5. Bases de données déductives

6. Bases de données réparties

7. Bases de données locales

6. Téléchargeable gratuitement à l’adresse suivante : www.sqlite.org.

II. LES BASES DE DONNÉES RELATIONNELLES

A. LA PLACE DU SERVEUR SQL

Figure 6 – Architecture d’un intranet

Poste client, Intranet Logiciel serveur Web : Scripts : Serveur SQL :

1. Ce que le serveur SQL peut faire

2. Ce que le serveur SQL ne peut pas faire

B. LES PRINCIPES DIRECTEURS DE CRÉATION D’UNE BASE DE DONNÉES

2. Normaliser les relations

UE 215 MANAGEMENT DES

I. Qu’est-ce qu’un système d’information ?............................................13

II. Pourquoi urbaniser ?.............................................................................97

I. PROGRAMME DE L’UE 215 :

Cette première série a pour objectifs de :

I. QU’EST-CE QU’UN SYSTÈME D’INFORMATION ?

Figure 1 – Système opérant et son système de pilotage2

Figure 5 – Information incomplète nécessitant une décision

4. Base de données de type « orienté objets »

6. Téléchargeable gratuitement à l’adresse suivante : www.sqlite.org.

Le recours à une méthode va donc fournir au concepteur :

compte des traitements requis ainsi que la qualité de la programmation ;

On distingue également d’autres types de clés :

Figure 27 – Un graphe d’héritage simple

Figure 28 – Un graphe d’héritage multiple

Figure 29 – Extrait de la liste des paquetages15 du langage Java

Les cas d’utilisation peuvent se représenter de deux façons :