modélisation des systèmes d ˇinformationtheses.univ-oran1.dz/document/th4020.pdf · 2...
TRANSCRIPT
DEPARTEMENT D'INFORMATIQUE
MEMOIRE
Présenté par
FRENDI Moha mmed
Pour l’obtention du diplôme de :
MAGISTER
Spécialité Informatique
Option : Système d’information
Intitulé : Soutenu le : 19/03/2013 à la salle de conférences de la Faculté des Sciences
Devant les membres du jury :
Président du jury KHELFI Mohamed Fayçal : Professeur - Université d’Oran.
Examinateur SEKHRI Larbi : Maître de Conférences A- Université d’Oran.
Examinateur ABDI Mustapha Kamel : Maître de Conférences A- Université d’Oran.
Encadreur RAHMOUNI Mustapha Kamel : Professeur – Université d’Oran.
Co-Encadreur ADLA Abdelkader : Maître de Conférences A- Université d’Oran.
Modélisation des Systèmes d’Information
1
Dédicaces:
A mes parents.
Vous récoltez dans ce travail le fruit de vos efforts. Aucune dédicace ne saurait exprimer mon profond amour et ma reconnaissance.
Que DIEU vous accorde longue vie, santé, bonheur et prospérité.
A ma femme.
Ta bonté et ta sincérité font de toi une femme aimée de tous et adoré par moi. C’est à tes cotés que le mot « dévouement » a pris sa véritable connotation.
Je te remercie de m’aimer et souhaite ne jamais te décevoir.
A mes enfants.
Mes merveilleux amours, chaque jour où je peux lire de la fierté dans vos yeux, je serais heureux et soulagé d’avoir réussi.
Aucun mot ne peut exprimer ma joie de vous avoir dans ma vie.
A mon équipe et amis.
Vous avez tant partagé avec moi, en vous j’ai trouvé deuxième une famille dont les liens ne pourront se briser. Je vous dédie mon travail en témoignage de mon sincère attachement. Je prie DIEU pour vous donner santé, bonheur, prospérité et beaucoup
de réussite.
2
Remerciements :
A mon président de jury Monsieur le professeur KHELFI MOHAMED FAYÇAL
Je suis très honorés de vous avoir comme président du jury de ma thèse.
Veuillez, monsieur le professeur, trouver dans ce travail l’expression de ma sincère considération et de mon profond respect.
A mon premier examinateur
Monsieur le Maitre de Conférence SEKHRI LARBI Je tiens à vous déclarer mes remerciements les plus sincères pour avoir accepté
d’examiner ce travail ainsi que pour votre patience et disponibilité. Soyez assuré de ma vive reconnaissance et ma profonde gratitude.
A mon second examinateur
Monsieur le Maitre de Conférence ABDI MUSTAPHA KAMEL
Vous me faites l’honneur d’être présent pour juger ce travail. Veuillez trouver en ce travail l’expression de mon profond respect.
A mon maître encadreur Monsieur le professeur RAHMOUNI MUSTAPHA KAMEL
Vous m’avez fait honneur de me confier ce travail, vos conseils m’ont été précieux.
Je vous remercie pour votre disponibilité, votre patience et votre encadrement. Veuillez, monsieur le professeur, trouver dans ce travail le témoignage de ma
profonde gratitude et de mon plus grand respect.
A mon Co-encadreur Monsieur le Maitre de Conférence ADLA ABDELKADER
C’est un grand honneur de nous avoir confié la responsabilité de ce travail.
Nous vous remercions d’avoir veillé à la réalisation de cette thèse. Nous espérons avoir mérité votre confiance.
3
Sommaire I INTRODUCTION GENERALE .......................................................................................................................... 7 II PARTIE I : ETAT DE L’ART ........................................................................................................................ 14 II.1 Chapitre 1 : Systèmes d’Information ........................................................................... 15
II.1.1 INTRODUCTION .............................................................................................................................16 II.1.2 APPROCHE SYSTEMIQUE .............................................................................................................17 II.1.3 REFERENTIEL DE COMPLEXITES CROISSANTES .....................................................................18 II.1.4 MODELISATION SYSTEMIQUE DE L’ENTREPRISE ...................................................................20 II.1.5 Fonctions du Système d’Information ..................................................................................................21 II.1.6 Conclusion .........................................................................................................................................22
II.2 Chapitre 2 : LES systèmes multi-agents ...................................................................... 24 II.2.1 Introduction .......................................................................................................................................25 II.2.2 Agents ...............................................................................................................................................27 II.2.3 Choix du type d’agents .......................................................................................................................29 II.2.4 Les systèmes Multi-Agents ................................................................................................................30 II.2.5 Conclusion .........................................................................................................................................39
II.3 Chapitre 3 : Les Systèmes d'Information Coopératifs .................................................. 40 II.3.1 Introduction .......................................................................................................................................41 II.3.2 Caractéristiques et propriétés des SIC .................................................................................................43 II.3.3 Taxonomie des Systèmes d’Information Coopératifs ...........................................................................46 II.3.4 Conclusion .........................................................................................................................................61
II.4 Chapitre4 : Ingénierie des systèmes d’information coopératifs .................................... 62 II.4.1 Introduction .......................................................................................................................................63 II.4.2 Travail collaboratif.............................................................................................................................64 II.4.3 La GED .............................................................................................................................................65 II.4.4 Workflow ..........................................................................................................................................66 II.4.5 Sécurité des Systèmes d’Information ..................................................................................................76 II.4.6 Conclusion .........................................................................................................................................78 III PARTIE II : PROBLEMATIQUE ET SOLUTION PROPOSEE ......................................................... 79
III.1 Chaine logistique ........................................................................................................ 80 III.1.1 Introduction .......................................................................................................................................81 III.1.2 Définitions issues de la littérature scientifique ....................................................................................82 III.1.3 Gestion de la chaîne logistique (GCL) ................................................................................................86 III.1.4 Le système décisionnel.......................................................................................................................88 III.1.5 Les performances ...............................................................................................................................90 III.1.6 Modélisation de la gestion de la chaîne logistique ...............................................................................92 III.1.7 description du système d’information projeté ......................................................................................95
III.2 Méthodologies de développement ............................................................................... 99 III.2.1 Introduction ..................................................................................................................................... 100 III.2.2 L’approche en cascade ..................................................................................................................... 100 III.2.3 L’approche itérative incrémentale ..................................................................................................... 100 III.2.4 UML (Unified Modeling Language ) ................................................................................................ 101 III.2.5 Choix de l’architecture .................................................................................................................... 102
4
III.2.6 Architecture globale du système ....................................................................................................... 106
III.3 Chapitre3: Choix et présentation des technologies utilisées ....................................... 107 III.3.1 Plate-forme J2EE ............................................................................................................................. 108 III.3.2 Les services de J2EE : ...................................................................................................................... 111 III.3.3 CLIENTS ........................................................................................................................................ 112 III.3.4 Les Design Pattern ........................................................................................................................... 113 III.3.5 Réplication et répartition avec Oracle streams ................................................................................... 115 III.3.6 Oracle Transparent Gateways ........................................................................................................... 121
III.4 Chapitre 4 : DEVELOPPEMENT du Système « SICLOG » ...................................... 123 III.4.1 Phase : Inception .............................................................................................................................. 124 III.4.2 Phase : Elaboration .......................................................................................................................... 129 III.4.3 Phase : construction ......................................................................................................................... 138 IV CONCLUSION GENERALE ....................................................................................................................... 142 V BIBLIOGRAPHIE .......................................................................................................................................... 144
5
LISTE DES FIGURES
Figure 1-le paradigme systémique ........................................................................................ 17
Figure 2-Les niveaux 2 et 3 de complexité. .......................................................................... 18
Figure 3-Les niveaux 4 et 5 de complexité. .......................................................................... 19
Figure 4-Niveau 6 de la complexité ...................................................................................... 19
Figure 5-Niveau7 de la complexité ....................................................................................... 20
Figure 6-espace SMA........................................................................................................... 32
Figure 7-les cinq niveaux de l’approche fédérée ................................................................... 47
Figure 8- architecture basée sur un système de médiation ..................................................... 51
Figure 9-description de procédure ........................................................................................ 70
Figure 10-Activités en entreprises de la Chaîne .................................................................... 85
Figure 11-Architecture client/serveur ................................................................................. 103
Figure 12-Architecture à trois niveaux ............................................................................... 104
Figure 13-Architecture multi niveaux ................................................................................. 105
Figure 14-Architecture du system (SICLOG) ..................................................................... 106
Figure 15-Architecture J2EE .............................................................................................. 109
Figure 16-Principe de la réplication de données ................................................................. 115
Figure 17-Préparation de la réplication dans Oracle............................................................ 116
Figure 18-Concept du groupe de réplication dans Oracle .................................................... 117
Figure 19-Les processus d’Oracle Streams ......................................................................... 118
Figure 20-Processus de capture .......................................................................................... 119
Figure 21-Processus de propagation ................................................................................... 120
Figure 22-Propagations autorisées et non autorisées entre files d’attente ............................ 120
Figure 23- Processus d’application ..................................................................................... 121
Figure 24-oracle transparent gateway ................................................................................. 121
Figure 25-Diagramme de Contexte Dynamique SICLOG ................................................... 127
Figure 26-Diagramme de Contexte Statique SICLOG ....................................................... 128
Figure 27-paquetage Maintenance 1 ................................................................................... 130
Figure 28-paquetage Maintenance 2 ................................................................................... 131
Figure 29-paquetage gestion de stock ................................................................................. 132
Figure 30-reversement ....................................................................................................... 135
Figure 31-établissement de marché .................................................................................... 136
Figure 32-distribution matériel ........................................................................................... 136
Figure 33-maintenance ....................................................................................................... 137
Figure 34-Diagramme de déploiement ............................................................................... 139
6
INTRODUCTION GENERALE
7
I INTRODUCTION GENERALE Ayant une expérience de plus de 25 ans d'activité professionnelle, notamment dans les
domaines de gestion et de formation, à partir desquelles j'ai pu observer tout ce qui se passait
dans les bureaux, services, départements; en d'autres termes, à différents niveaux de
l'organisation dans laquelle j’exerce mon métier d’informaticien, j'ai pu constater combien
l'information est une affaire complexe encore mal exploitée et moins explorée. Faisant partie
de notre environnement quotidien, nous manipulons, recherchons et produisons celle-ci à tout
instant, ce qui la rend parmi les gestes instinctifs qu'il semble inopportun de s'interroger sur
eux. Chacun se meut dans une masse d'information et met en œuvre de nombreuses
procédures, de façon quasi automatique et routinière. Devant cet état de fait, Il est indéniable
d'investiguer ces opérations et les démarches mobilisées par cette activité toute personnelle.
Il est important de souligner que les gestionnaires d'entreprise, qui considèrent l'information
comme l'une des ressources entrant dans la production d'un bien ou d'un service, sont
préoccupés par cette activité qui en fait constitue le résultat d'expérimentation individuelle.
Actuellement, l'information est gérer comme un capital et non comme un moyen de
renseignement, de communication ou de décision. Elle constitue la matière première du
métier "spécialiste de l'information". Ce terme évoque tous ceux qui, à des titres divers, ont en
charge de collecter, organiser et mettre à disposition des fonds ou/et des flux d'information
inhérents aux activités de leur organisme.
L'avènement des technologies et leur capacité de traitement, de stockage et de
diffusion ont complexifié les procédures de travail. A partir du moment où, tout agent,
individu ou entité faisant partie d'une organisation, peut ou pourra, sans se déplacer, accéder à
tous types d'informations. Qu'adviendra-t-il, donc, des métiers "d'intermédiation", dont le rôle
consiste à faciliter l'accès à des ressources lointaines ou inconnues.
Brigitte Guyot, dans son ouvrage "Dynamiques informationnelles dans les organisations" a
rendu compte des composantes de l'activité de l'information sur au moins deux plans,
individuel et collectif, en couplant le point de vue du gestionnaire avec celui de l'individu au
travail, en faisant abstraction à l'approche documentaire centrée sur les études des besoins, sur
les objets et leurs traitements.
Cependant, il faudrait dépasser l'idée courante que les technologies de l'information résolvent
presque tous les problèmes d'information. Si dans la plupart des cas cela est vérifié, certains
problèmes n'ont pas été résolus et ont été même amplifiés.
Nécessitant des connaissances supplémentaires, de nombreuses personnes sont
impuissantes à résoudre les problèmes engendrés par l'utilisation de ces technologies.
8
La situation actuelle est transitoire: les outils sont suffisamment disponibles pour que leur
usage paraisse largement acquis. Mais en même temps, ils subissent l'épreuve de la réalité,
lorsque chacun les façonne, à sa manière, pour les utiliser à la manière voulue.
Le principe même d'une organisation est de se structurer autour d'un objectif (but), en
rassemblant autour d'elle un ensemble de moyens humains matériels et immatériels. Il faut
donc la considérer dans des dimensions sociales (des hommes travaillant ensemble),
organisationnelle (un ensemble de règles encadrant son fonctionnement), sans faire
abstraction à la dimension cognitive, dans la mesure où ses activités produisent une
représentation d'elle-même, pour elle et pour ses partenaires ou concurrents.
L'information joue un rôle fondamental dans cette construction car elle contribue à
structurer, à organiser, à socialiser et à construire du sens. Cela laisse entrevoir une première
approche de l'information: elle est liée à une activité qu'elle traduit en la représentant; elle est
inscrite sur des supports qui permettent de faire circuler des instructions, des ordres, des
règlements, signalant ainsi des intentions multiples. C’est un support de management.
Une entreprise qui prend place dans un marché (environnement), propose un certain
nombre de produits, de biens ou d'équipement, ou de services. Pour cela, elle est dans
l'obligation de recourir à des fournisseurs, de construire des relations avec ses clients ou des
usagers, tout en s'informant sur les activités des ses concurrents.
Elle peut contrôler en interne l'ensemble du processus allant de la mise au point de son produit
à sa commercialisation et son suivi. Mais elle peut aussi recourir à des corps de métier
spécialisés qui vont lui assurer une partie de son travail.
De nos jours, il y a lieu de constater qu'une partie de l'avantage concurrentiel d'une
entreprise est liée à la manière dont elle surveille son marché, et surtout à la façon dont elle
gère ses propres informations, celles qui sont liées à son métier. On parle alors de
management stratégique de l'information et d'information stratégique pour faire ressortir
qu'une information acquise au bon moment fera la différence dans son positionnement, ou de
capital de connaissances, pour souligner l'importance d'une exploitation des savoir-faire
acquis par la pratique. Dans les deux cas, l'information est considérée comme un potentiel
possédant une valeur stratégique.
La stratégie pourrait se définir comme la capacité à anticiper et à donner du sens à son
action. Elle se fonde alors en grande partie sur une connaissance fine de sa propre position sur
l'environnement, dans lequel elle opère, afin de prendre les mesures nécessaires à sa survie et
son développement. L'information est donc intégrée dans le processus de décision en lui
fournissant les éléments à analyser et à synthétiser au préalable.
9
Au début des années 80, et selon les théories de la décision, l'information stratégique
signifie l'importance du processus de transformation de données hétérogènes en informations
par une analyse permettant la prise de décision. Les technologies de l'information sont
fortement impliquées par leur capacité à produire des tableaux de bord d'activités, simulation
et scénarios. L'intelligence artificielle développe, quant à elle, les outils d'aide à la décision
pour les organes directoires.
La théorie générale des systèmes est le nom donné par L. Von Bertalanffy après la seconde
guerre mondiale ; il la définit comme « la formulation et la dérivation des principes valables
pour les systèmes en général »
Le mot système a été l’objet de plusieurs définitions. AD. Hall et RC. Fagen
définissent un système comme étant « un ensemble d’objets et les relations entre ces objets et
entre leurs attributs ». Les objets sont les composants du système, les attributs sont les
propriétés des objets et les relations peuvent être comprises comme « ce qui fait tenir
ensemble le système ».
J. Rosnay propose la définition suivante : « Un système est un ensemble d’éléments en
interaction dynamique, organisés en fonction d’un but.»
J.L. Le Moigne propose de définir le système comme :
• Quelque chose (n’importe quoi, identifiable),
• Qui fait quelque chose (activité, fonction),
• Et qui est dotée d’une structure,
• Evolue dans le temps,
• Dans quelque chose (environnement),
• Pour quelque chose (finalité, but, objectif).
La théorie des systèmes distingue le système fermé et le système ouvert.
Le système fermé est défini comme étant totalement isolé des influences externes et donc
uniquement soumis à des modifications internes. Aussi, un système fermé peut être défini
comme un automate qui ne peut se trouver que dans un certain nombre d’états définis ; la
connaissance de ces états est suffisante pour définir le système.
Paradoxalement, le système ouvert est en relation permanente avec son environnement. Il
subit des perturbations externes qui sont, a priori, imprévisibles et inanalysables. Ces
perturbations (événements), qui se produisent dans l’environnement, provoquent des
adaptations du système qui le ramènent à un état stationnaire.
Trois propriétés formelles s’appliquent aux systèmes ouverts :
10
• Totalité : un système ne se comporte pas comme un simple agrégat d’éléments indépendants, il
constitue un tout cohérent et indivisible. Une autre façon d’exprimer cette propriété est de définir
un système complexe. Ce dernier est constitué par une grande variété de composants organisés.
• Rétroaction : Le fonctionnement de base des systèmes repose sur le jeu combiné des interactions
entre les composants du système. Dans tout système où s’effectuent des transformations, on peut
identifier des entrées qui reflètent l’action de l’environnement sur le système et des sorties qui
représentent l’action du système sur l’environnement. L’identification de boucle de rétroaction
permet de comprendre des fonctionnements complexes des systèmes. La mise en œuvre de ces
boucles va conduire à une circularité du système ; en effet, autant pour une chaîne causale
linéaire, on peut parler d’un commencement et d’une fin, autant pour les systèmes à rétroaction,
ces termes n’ont pas de sens.
• Equifinalité : Le principe d’équifinalité signifie que les mêmes conséquences peuvent avoir des
origines différentes et donc par opposition au système fermé qui est complètement déterminé par
ses conditions initiales, un système ouvert a un comportement à la limite indépendant des
conditions initiales.
P. Watzlawitck voit la famille comme étant un système ouvert. La propriété de totalité signifie
que le comportement de chacun des membres est lié au comportement de tous les autres
membres et en dépend. La famille ne peut se réduire à chacun de ses membres.
Les boucles de rétroactions se traduisent par le fait que les réactions de la famille en réponse à
des perturbations venant de l’environnement vont à leur tour modifier le « système famille ».
Il donne l’exemple de certaines familles pour lesquelles le fait d’essuyer un gros revers est
une occasion de resserrer les liens familiaux, alors que pour d’autres la crise la plus banale est
une occasion d’éclatement.
Le principe d’équifinalité stipule que dans l’analyse de la famille comme un système,
on devra moins s’intéresser aux conditions initiales de la perturbation qu’au mécanisme de
rétroaction et qu’un éclatement ou un resserrement peuvent être causés par des entrées forts
diverses. Le terme d’homéostasie rend compte de l’existence des mécanismes de rétroaction
qui servent à atténuer les répercussions d’un changement et à ramener le système à son état
d’équilibre.
L’approche systémique s’oppose à l’approche analytique et la complète. Dans cette
dernière, on essaie de réduire le système à des éléments constitutifs simples pour les étudier
isolément et analyser leur interaction avec le système. Cette approche est pertinente dans le
cas des systèmes homogènes comportant des éléments semblables ayant entre eux des
11
interactions faibles. Dans les autres cas, on doit considérer le système dans sa totalité, en
tenant compte de sa complexité et de sa dynamique.
Le recours à l'approche systémique paraît incontournable pour avoir une vision générale de
l'entreprise, de ces flux et des relations entre les entités qui la composent. Cette science les
définit comme des regroupements d'éléments en interaction dynamique, agencés et organisés
en fonction d'un but. Chacun, de ces éléments, est doté d'attributs, propriétés qui tiennent
ensemble par des relations réciproques.
Un système a donc une délimitation (espace interne circonscrit par des frontières), un mode
d'organisation propre et il entretient des relations avec ses environnements proches ou
lointains. Il trouve en lui-même, ou va chercher ailleurs, les ressources nécessaires pour
évoluer, survivre et se développer.
L'information joue un rôle essentiel dès qu'on s'intéresse aux interactions qui
structurent et transforment un système. Ceci découle de la cybernétique, ou science du
pilotage des machines. Ces systèmes techniques sont bouclés autour de relations simples
cause-conséquence, et commandés par des réponses-réflexes et de rééquilibrages permanents
(la rétroaction) pour maintenir leur équilibre.
Sur le plan méthodologique, la systémique conceptualise par modélisation. L'observateur
choisit un point de vue pour étudier un objet puis, par une série de traductions et de
schématisations, il élabore une représentation signifiante des lignes de forces. Ce modèle
explicatif offre une grille de lecture réutilisable dans d'autres situations jugées semblables.
Ainsi, un modèle hiérarchique sera représenté sous forme d'arborescence, un processus par un
découpage en séquences.
Lorsqu'on applique les principes systémiques à une organisation, elle devient un système
contraint car structuré par les buts assignés, et construit par des interactions qui forgent son
identité. Ce système "global" se subdivise en autant de sous-systèmes qu'il a de fonctions
spécialisées.
Chaque partie, composant ce système, tout en étant autonome et situé selon la place qu'elle
occupe dans l'ensemble, y joue un rôle particulier. Cette globalité se décompose en unités
locales, tant géographiques que fonctionnelles. Il s'établit une différenciation par niveaux, du
plus élémentaire (l'individu) au plus global ; la macro correspondant à l'entreprise toute
entière. Ils sont reliés entre eux par des relations transversales, entre unités locales ou entre
niveau local et le niveau général. L'organisation est traversée, en interne, par des relations
hiérarchiques, contractuelles ou interpersonnelles, tout en entretenant des rapports
concurrentiels ou coopératifs vis-à-vis de son environnement extérieur, au plan régional ou
12
même mondial. N'importe quelle modification entraîne un réagencement de la totalité qui se
mue, en transformant sa configuration.
L'information est définie par les cybernéticiens comme un signal qui transforme un état
à un moment T1 vers un autre état à un moment T2. Elle est considérée comme des instances
faisant bouger le système technique, la régulation en conditionnant sa réactivité et enfin la
contribution à la lutte contre l'entropie (dégradation du système).
Conformément à l'approche systémique, l'information est posée comme un vecteur de
transmission d'ordres (dans une verticalité descendante) et de signalement vers le système de
décision et de contrôle des activités (verticale remontante).
En même temps, en venant transformer les représentations antérieures, l'information
agit comme un facteur d'organisation symbolique: l'entreprise, dès sa création, produit des
informations, aussi, bien pour s'organiser et fonctionner que pour se doter d'un système de
représentations partagées par l'ensemble de ses membres. Certains considèrent l'information
comme un vaste système de traitement de symboles. Une organisation désigne les objets
(matériels et immatériels) sur lesquels elle s'active et produit des représentations sur ses
propres activités. Cette mémoire organisationnelle engrange toutes ces productions
symboliques et crée de l'intelligence, en donnant du sens aux actions futures.
Le mémoire est organisé en deux parties, dont la première présente un état de l’art du
domaine et la deuxième concerne principale notre contribution.
La première partie comporte quatre chapitres, dont le premier introduit la notion de système
d’information et de l’approche systémique. Aussi, un référentiel de complexités croissantes
des systèmes a été évoqué permettant de situer la modélisation systémique. S’en suivi, une
présentation des fonctions que peut assurer un système d’information. Enfin, des remarques et
des suggestions ont été énumérées dans une conclusion à ce chapitre. Le deuxième chapitre
donne des définitions sur les agents, les systèmes multi-agents et leur environnement. En
outre, les concepts de communication, d’interactions, de coopérations et d’organisation ont
été évoqués. Les systèmes d’information coopératifs ont été cernés dans le chapitre trois.
Dans ce dernier, on retrouve les caractéristiques et la taxonomie des systèmes d’information
coopératifs. Enfin, dans le quatrième chapitre nous nous sommes intéressés à l’ingénierie des
systèmes. Les notions de travail collaboratif, de GED et de workflow ont été données, non
sans omettre l’aspect sécuritaire des systèmes d’information qui précède une conclusion à ce
chapitre.
La deuxième partie, quant à elle, comporte aussi quatre chapitres, dont le premier
introduit les problèmes d’organisation et de gestion des activités auxquels sont confrontées les
13
entreprises. Les notions de « chaîne logistique » et de « gestion de la chaîne logistique » sont
définies. Une analyse des performances et des critères de performance ont été énumérés ainsi
que l’aspect modélisation de la gestion de la chaine logistique. A la fin de ce chapitre, nous
avons présenté notre système (SICLOG) « Système d’Information de la Chaîne Logistique ».
Au chapitre deux, les méthodologies de développement ont été présentés. En effet, dans ce
chapitre, nous avons donné une description des différentes architectures existantes et avons
présenté l’architecture globale de notre système. Au chapitre trois, ont été évoqués les choix
des technologies utilisées ainsi que telles que : Java, Oracle, UML …,. Enfin, au quatrième
chapitre nous avons présenté le processus de conception. Notre choix s’est porté sur le
processus unifié qui comporte quatre phases, à savoir : la phase Inception, dans laquelle, nous
essayons de comprendre le contexte du système, de déterminer les principaux cas
d’utilisation, les besoins fonctionnels et non fonctionnels. La deuxième phase intitulée
Elaboration dans laquelle nous avons tenté d’approfondir la compréhension du système par un
processus continue de collecte d’information et d’arriver à obtenir les spécifications dudit
système. Une analyse et une conception détaillées des cas d’utilisation ont été présentées. Il
est utile de signaler que cette phase est très importante vu qu’on doit passer d’une architecture
candidate construite lors de la phase précédente, vers une architecture stable dans celle-ci. La
construction étant la troisième phase, permet de savoir si le système informatisé a satisfait les
exigences des utilisateurs. Enfin, la dernière phase, qui consiste au déploiement et à la mise en
place dudit système. Cette phase est appelée Transition.
Nous clôturons ce mémoire par une conclusion générale, dans laquelle nous évoquons
les perspectives.
14
II PARTIE I : ETAT DE L’ART
PARTIE I :
ETAT DE L’ART
Chapitre 1 : Systèmes d’Information
Chapitre 2 : Les Systèmes Multi-Agents
Chapitre 3 : Les Systèmes d'Information Coopératifs
Chapitre 4 : Ingénierie des Systèmes d’Information Coopératifs
15
II.1 CHAPITRE 1 : SYSTEMES D’INFORMATION
Chapitre 1 :
Systèmes d’Information
16
II.1.1 INTRODUCTION
Un système dévolu à l'information peut être défini comme un assemblage de moyens,
matériels et humains, pour gérer, mettre en ordre et organiser l'exploitation d'information.
Cette notion de système d'information est ambiguë, du fait qu’elle est réduite au seul
traitement informatique. Il est vrai que l'informatique engrange des données, les trie et les
formalise pour les rendre compatibles avec les traitements attendus, comme l'indiquent les
termes de computation ou de traitement de l'information.
Les sciences de gestion ont défini le système d'information comme l'ensemble des outils
informatiques dévolus au pilotage des activités, à la gestion stratégique et au contrôle.
[FAV99, ROW 02]
De nos jours, le système d’information, et sa composante informatisée (de plus en plus
consistante), impacte et implique une organisation dans son ensemble. Ce n’est pas par hasard
si certains progiciels de gestion imposent, pour le meilleur et pour le pire, un modèle
d’organisation.
De manière lapidaire, une organisation (entreprise, organisme, administration, …) est
structurée autour d’un objectif (de vente, de production de service public …), auquel sont
consacrés des ressources, définissant ainsi un intérieur (les agents de l’organisation) et un
extérieur (partenaires, clients, administrés …), et manipulant, pour satisfaire cet objectif, de
l’information, en mettant en œuvre des supports divers : un Système d’Information.
A l’heure où l’information n’est plus seulement considérée comme ressource opérationnelle
mais aussi comme une ressource stratégique pour l’entreprise, son système d’information
devient un facteur de différenciation par rapport à ses concurrents. C’est par sa culture, ses
croyances et son système d’information performant que celle-ci pourra s’adapter à son
environnement concurrentiel. C’est dire toute l’importance des méthodes de conception et de
développement de systèmes d’information mises en œuvre dans l’entreprise.
Mais, au fait, qu’est ce qu’une méthode ? L’étymologie du mot est incertaine, mais
elle tient pour plausible l’association de deux racines, celle qui dit le raisonnement rusé ou les
ruses de l’intelligence ; la « Métis », et celle qui dit le chemin, la voie à suivre, « Hodos ».
« Chercher une méthode, disait P.Valéry (dans variétés), c’est chercher un système
d’opérations extériorisables qui fasse mieux que le travail de l’esprit.
Dans le petit robert, on trouve la définition suivante : Une méthode peut être « une marche, un
ensemble de démarches que suit l’esprit pour découvrir et démontrer la vérité (dans les
sciences). Cela peut être aussi, « un ensemble de démarches raisonnées, suivies pour parvenir
17
à un but ». On peut, également, définir une méthode comme « un ensemble de règles, des
principes normatifs sur lesquels reposent l’enseignement, la pratique d’un art »
La nature spécifique du système d’information, à la fois objet « naturel » et objet
« artificiel », nous conduit à définir une méthode pour leur conception comme avant tout un
schéma de réflexion fournissant au concepteur un guide continu indiquant la manière
d’aborder les problèmes. C’est ce qui appelé communément les principes généraux de la
méthode.
La façon de mettre en œuvre ces principes généraux au cours du processus de conception se
concrétise par une démarche, proposant une succession progressive d’étapes. Cette démarche
est fréquemment appuyée sur des raisonnements qui permettent de mettre en œuvre plus
aisément celle-ci. Ces raisonnements sont soit l’émanation directe des principes généraux et
constituent ainsi l’originalité de la démarche, soit plus généraux et adaptés aux principes de la
méthode.
Pour conduire ces raisonnements, et pour assurer la communication entre les intervenants
dans le processus de conception, la méthode doit proposer des modèles. Les modèles seront
exprimés et validés en utilisant des formalismes ; langages permettant d’identifier et de
décrire tous les concepts nécessaires à la spécification des systèmes étudiés.
II.1.2 APPROCHE SYSTEMIQUE
Le paradigme systémique repose sur les trois hypothèses fondamentales suivantes :
• Hypothèse téléologique où l’objet à modéliser est supposé doté d’au moins un projet identifiable.
Le fonctionnement et l’évolution de cet objet peuvent être interprétés par des projets qui eux-
mêmes détermineront des structures possibles ;
• Hypothèse d’ouverture sur l’environnement où l’objet à modéliser est ouvert sur l‘environnement
que l’on doit présenter, même s’il n’est pas descriptible de manière exhaustive ;
• Hypothèse structuraliste où l’objet à modéliser doit être décrit dans sa totalité, fonctionnant et
évoluant.
Figure 1-le paradigme systémique
18
Appliqué à l’entreprise, ce paradigme met l’accent sur les interrelations entre sa structure, son
activité, son évolution et ses finalités, cela dans un environnement changeant.
II.1.3 REFERENTIEL DE COMPLEXITES CROISSANTES
J.L Le Moigne [Le Moigne 77] a proposé une classification des systèmes fondée sur
leur complexité croissante. Cette classification se décompose en neuf (09) niveaux artificiels
permettant à l’observateur de situer sa modélisation, en fonction de la complexité de l’objet
réel et surtout en fonction des objectifs du modèle représentant l’objet.
Cette classification en complexité croissante nous permet d’illustrer l’émergence de la notion
de système d’information, de nous doter d’une définition du système d’information et
d’appréhender les limites de l’informatisation de ces systèmes.
• Niveau 1 : l’objet est passif et sans activité (une table, une armoire).
• Niveau 2 : l’objet est actif et transforme des flux (structure active, mouvement prédéterminé :
pressoir, ampoule électrique, machines).
• Niveau 3 : l’objet actif est régulé. Il présente quelques régularités de comportement, et l’on
observe des refus d’autres comportements possibles. On peut le modéliser comme doté d’un autre
processeur chargé d’assumer sa régulation.
Figure 2-Les niveaux 2 et 3 de complexité.
• Niveau 4 : l’objet s’informe. Au lieu d’un couplage physique entre les deux processeurs, le
processeur de régulation s’informe sur l’activité du processeur actif (freinage ABS, injection
électronique …). La modélisation de l’objet régulé grâce à un flux d’information constitue le
schéma de base de la cybernétique.
• Niveau 5 : l’objet décide de son activité. Il passe d’un comportement théoriquement prévisible
(ou programmé) à un comportement « libre » et apparaît doté d’un projet (objectif). C’est
l’émergence d’un processeur décisionnel autonome.
19
Figure 3-Les niveaux 4 et 5 de complexité.
• Niveau 6 : l’objet a une mémoire. Pour prendre des décisions, le processeur décisionnel fait appel
à des informations-représentations non seulement du comportement actuel, mais aussi des
comportements passés. Ce niveau est caractérisé par l’émergence de processus de mémorisation.
L’objet possède une mémoire.
Figure 4-Niveau 6 de la complexité
• Niveau 7 : l’objet se coordonne. Le processeur actif devient une fédération de processus actifs,
nécessitant une coordination ; il est alors appelé système opérant (SO). La même évolution
s’applique au processeur décisionnel qui devient système de pilotage (SP), ainsi que la mémoire
qui devient système d’information (SI).
20
Figure 5-Niveau7 de la complexité
• Niveau 8 : l’objet imagine et s’auto-organise. L’objet est capable, afin d’atteindre ses objectifs,
d’imaginer l’organisation la mieux adapter de ses sous-systèmes. Le système de pilotage dispose
de capacités d’imagination, de conception qu’il mettra à profit pour élaborer des plans d’action et
conduire l’adaptation des autres sous-systèmes.
• Niveau 9 : l’objet s’auto-finalise. Ultime stade de l’évolution (pour l’auteur), l’objet est
désormais capable de définir son projet, voir ses objectifs. C’est l’émergence de la conscience. Le
système de pilotage dispose de capacités de finalisation (système de finalisation), lui permettant
de changer ses objectifs. Pour les atteindre, il fera évoluer en conséquence ses sous-systèmes
opérants, de pilotage et d’information.
II.1.4 MODELISATION SYSTEMIQUE DE L’ENTREPRISE
En nous proposant une modélisation progressive des objets, la systémique facilite la
compréhension de l’entreprise, objet complexe actif et organisé. Il est utile de rappeler que
tout corps social organisé, en particulier les entreprises et les administrations, pourra être
modélisé comme un système dont la complexité se situera au niveau 9 précédemment défini.
A travers l’étude des niveaux de complexité apparaît le rôle du sous-système
d’information (émergence de processus de mémorisation). Ainsi, nous pouvons situer le rôle
et les fonctions du système d’information de l’entreprise et ses relations avec les autres
systèmes ; le système de pilotage et le système opérant.
Nous allons, à présent, décrire succinctement, le rôle de chacun de ces systèmes composant
l’entreprise-système.
21
• Le système opérant est le siège de l’activité productive de l’entreprise. Il est constitué des toutes
les catégories de personnels réels ou artificiels transformant des flux de matières, des flux
financiers, des flux d’actifs ou d’informations … etc.
• Le système de pilotage est le siège de l’activité décisionnelle de l’entreprise. Cette activité
décisionnelle est très large et est assurer par tous les acteurs de l’entreprise, à des niveaux divers,
depuis les acteurs agissant plutôt dans l’activité productrice de l’entreprise, à ceux dirigeant cette
dernière. Elle permet la régulation, le pilotage amis aussi l’adaptation de l’entreprise à son
environnement.
• Le système d’information qui est considéré, pour l’instant, comme un système de mémorisation
dont le rôle est de permettre au système de pilotage d’assumer ses fonctions, notamment en
assurant son couplage avec le système opérant.
II.1.5 FONCTIONS DU SYSTEME D’INFORMATION
L’analyse systémique nous a permis de faire émerger la notion de système
d’information comme une représentation de l’activité du système opérant et/ou du système de
pilotage, et des échanges avec l’environnement, conçue à l’initiative du système de pilotage
en fonction des objectifs à atteindre et de l’organisation choisie.
Ce système d’information est destiné :
• Au système de pilotage pour pouvoir connaître et maîtriser le fonctionnement du système opérant,
• Au système opérant lorsque les flux transformés sont de nature « information ».
Le système d’information (SI) assure, au sein de l’entreprise, les fonctions primaires
suivantes :
• La génération des informations.
Le système de pilotage, organe de conception du système d’information, doit faire preuve
d’imagination dans la définition de l’information nécessaire à l’émergence du SI et de ses fonctions.
Cette génération de l’information est un préalable nécessaire à toute mémorisation de l’information ;
elle permettra toute saisie future et elle est propre à chaque organisation. Cette génération de
l’information consiste à définir un vocabulaire spécifique de l’entreprise, à travers l’attribution à toute
information d’un nom et d’une définition, reconnus et partagés au sein de l’entreprise. Elle concerne
également la définition des événements déclarés « d’intérêt pour l’organisation », conduisant aussi à
définir les réactions que l’organisation devra développer en réponse à ces événements.
• La mémorisation des informations (transfert des informations dans le temps).
22
La fonction de mémorisation (collective) des informations a un rôle central dans le référentiel
des complexités croissantes de K.E. Boulding : dans mémoire, pas d’apprentissage, pas d’intelligence.
La nature et la signification des informations à mémoriser seront des éléments essentiels de la
conception d’un système d’information.
• La communication et la diffusion des informations (transfert des informations dans l’espace).
Le système d’information assure les échanges (acquisition et restitution) d’informations
avec/entre le système opérant et le système de pilotage.
L’organisation de l’acquisition et de la restitution des informations constituera un autre élément
important de la conception des SIs.
• L’exécution des traitements (transfert des informations dans la forme).
Par référence à l’approche systémique, les traitements sont soit des activités de transformation
d’information-matière première (relevant donc du système opérant), soit des activités de décisions,
élémentaires ou complexes (relevant du système de pilotage). Le SI accueille, pour le compte du SP
ou du SO, les traitements suffisamment formalisés et répétitifs. Ce qui était une décision-réflexion au
niveau du SP devient un réflexe au niveau du SI.
Ainsi, le système d’information ne fait aucune hypothèse sur les moyens le supportant ; le
système d’information existe indépendamment des techniques informatiques. Toutefois, ces
techniques vont permettre d’amplifier les fonctions de mémorisation, de communication et de
traitement des informations.
L’informatisation du système d’information comporte ainsi deux préoccupation
majeures ; d’une part la compréhension et l’explication du système d’information (activité,
information, organisation), et d’autre part la construction de logiciels, support du système
d’information.
II.1.6 CONCLUSION
Ce qu’il faudrait retenir ici, c’est que l’auteur n’a pas pris en considération les aspects
règlementation, d’existence ou de survie, priorisation des objectifs et la conception de
méthodes. En outre, l’aspect sécuritaire n’a pas été du tout pris en compte, puisque l’objet
se trouve dans un environnement instable (variant) et peut se retrouver dans d’autres
environnements inconnus.
L’objet peut être sujet d’anomalies de fonctionnement. Dans ce contexte, comment
peut-il le savoir et quelles sont les actions (prioritaires) qu’il doit entreprendre pour
retrouver sa stabilité ou son fonctionnement jugé normal.
23
La question qui se pose, c’est que l’objet peut-il changer une règlementation
prédéfinie, au sein de l’environnement dans lequel il opère, ou au sein même de son entité.
Peut-on le doter d’un pouvoir décisionnel sans limites lorsqu’il opère dans des
environnements inconnus ou lorsque son environnement est perturbé voir instable ?
Ces questions nous amènent à étudier la possibilité de doter l’objet de ces pouvoirs
(propriétés) afin qu’il puisse « survivre » à toute forme de déstabilisation, d’anomalies de
fonctionnement ou de changement d’environnement tout en restant dans un cadre
réglementaire général.
24
II.2 CHAPITRE 2 : LES SYSTEMES MULTI-AGENTS
Chapitre 2 :
Les systèmes multi-agents
25
II.2.1 INTRODUCTION
Depuis l’avènement de l’outil informatique, les chercheurs ont toujours essayé de
comparer le cerveau humain à la machine la plus perfectionnée. Mais c’est pendant les années
1960 que l’homme a abordé un des plus important axes de recherches qui consiste à créer des
comportements intelligents à partir d’ordinateurs. C’était le début de l’intelligence artificielle.
Depuis, l’intelligence artificielle s’intéresse à la modélisation des comportements
humains suffisamment complexes pour être dits intelligents. La machine de Turing étant
présentée comme un test consistant à déterminer son intelligence par rapport à celle de l’être
humain lors d’une conversation. Néanmoins, la notion d’intelligence de groupe ou
d’intelligence collective était totalement ignorée dans ce test, car la machine ne pouvait
représentée plusieurs personnes à la fois.
Au début des années 80, la notion d’agent et de systèmes multi-agents a pris un
ascendant considérable. Ce domaine est né de l’idée de distribuer les connaissances et le
contrôle dans des systèmes d’Intelligence Artificielle. Il constitue, de nos jours, une
alternative très intéressante pour la conception, la mise en œuvre ou la simulation et la
compréhension de systèmes coopératifs, distribués ou ouverts.
Dans une société humaine, un problème complexe ne peut être résolu par une personne
isolé mais en contre parti ce même problème, aussi complexe soit-il, est très souvent résolu
par un groupe d’individus compétents évoluant dans une organisation dont l’attitude évolue
dynamiquement et de manière autonome au cours de l’élaboration de la solution.
L’Intelligence Artificielle Distribuée (IAD) se distingue de l’Intelligence Artificielle
(IA) classique, d’une part, par le concept de distribution de l’intelligence, et d’autre part par la
différence de paradigme. La connaissance n’est plus concentrée dans une seule entité, cas de
l’IA, mais répartie entre plusieurs, qui, par leur interactions, parviennent à résoudre une tâche
collective ou à ordonner leurs actions.
Les systèmes Multi-Agents (SMA) ont été définis par Ferber [Ferber,1995], comme
étant « des activités simples ou complexes, telles que la résolution de problèmes,
l’établissement d’un diagnostic, la coordination d’action ou la construction de systèmes sont
le fruit d’entités relativement autonomes et indépendantes, appelées agents, qui travaillent au
sein de communautés selon des modes, parfois complexes, de coopération, de conflit et de
concurrence, pour survivre et se perpétuer. De ces interactions émergent des structures
organisées qui, en retour, contraignent et modifient les comportements de ces agents ».
Les systèmes multi-agents sont composés d’un agrégat de logiciels autonomes appelés
« Agents » et sont caractérisés par :
26
• Un environnement dynamique dans lequel évoluent les agents, dont l’activité peut être remise en
cause durant la vie du système ;
• Des agents ayant une perception partielle de leur environnement. La pertinence de leur action est
alors uniquement locale ;
• Des agents ayant des capacités cognitives restreintes. Ils ne peuvent, par conséquent, pas tout
traiter individuellement et doivent s’associer pour réaliser l’activité globale ;
Selon Jacques Ferber, les recherches dans le domaine poursuivent deux objectifs
majeurs :
• Le premier concerne l’analyse théorique et expérimentale des mécanismes d’auto-organisation
qui ont lieu lorsque plusieurs entités autonomes interagissent ;
• Le second s’intéresse à la réalisation d’artefacts distribués capables d’accomplir des tâches
complexes par coopération et interaction.
Toutes les recherches actuelles se focalisant sur le domaine multi-agent s’intéressent
principalement aux systèmes formés par un nombre important d’agents et ayant une très
forte dynamique. Chaque agent, évoluant de manière autonome dans un système, ne
possède qu’une vue partielle de ce système, et par voie de conséquence, il lui est
impossible d’y avoir une vue globale. D’autre part, vu que la dynamique est très
importante, il est quasiment impossible de prévoir, dès la conception, toutes les situations
pouvant survenir durant le fonctionnement du système. Ces systèmes doivent
impérativement s’adapter à cette dynamique au cours de leur fonctionnement.
En effet, Les systèmes sont plongés dans des environnements qui changent
dynamiquement et de manière imprévue. Face à ces environnements en perpétuel mutation,
les systèmes doivent pouvoir réagir, s’adapter ou se muer. Cette faculté d’adaptation
devient, par conséquent, de plus en plus importante et nécessaire afin de survivre dans des
environnements dynamiques et stochastiques inconnus ou indescriptibles à l’avance. Les
systèmes multi-agents adaptatifs apportent, des solutions très intéressantes et prometteuses
et constituent actuellement un domaine à part entière en intelligence distribuée.
Un système multi-agent n’est pas monolithique (cohérent), mais est constitué d’un
grand nombre d’agents interagissant les uns avec les autres. Chaque agent agit sur
l’environnement, sur autrui et sur l’organisation en fonction de ses interactions.
La résolution d’un problème s’effectue généralement selon une méthode « up-down »
descendante. Ceci dit, pour la résolution d’un problème complexe, la méthode utilisée
consiste en la décomposition de ce problème en sous problèmes qui à leur tour s’ils
27
présentent une certaine complexité, sont divisés en sous-problèmes jusqu’à obtenir des
problèmes simples à résoudre par des agents d’une manière individuelle, tout en prenant en
charge le séquencement des opérations afin d’obtenir la solution recherchée. Cette
approche présuppose de pouvoir maitriser, dès la conception, les interactions potentielles
du système avec l’environnement dans lequel il est plongé. Lorsque la spécification du
problème est incomplète où lorsque l’environnement est évolutif, cette démarche devient
difficilement applicable.
Les systèmes multi-agents permettent de construire des systèmes artificiels pour
lesquels l’activité collective observée n’est décrite dans aucun des agents qui les
composent. Cette approche devient impérative lorsqu’il s’agit de construire des systèmes
complexes qui n’ont pas de solution algorithmique connue a priori : la solution doit se
construire dynamiquement. Ceci est très utile dans les applications où :
• La coopération d’une multitude de tâches élémentaires est indispensable pour la réalisation d’une
activité collective précise mais difficilement formalisables ;
• Le système est fortement évolutif : la création, la modification ou la suppression de tâches
élémentaires sont permanentes et imprévisibles ;
• L’environnement exerce des contraintes fortes et dynamiques sur le système.
II.2.2 AGENTS
Il existe une multitude de définitions du terme « Agent » du fait de son utilisation
versatile. Nous allons essayer de donner quelques définitions les plus utilisées :
Définition de Ferber :
On appelle agent une entité physique ou virtuelle possédant les caractéristiques suivantes :
• La possibilité d’agir dans un environnement,
• La faculté de communiquer directement avec d’autres agents,
• L’opportunité de muer grâce un ensemble de tendances (sous la forme d’objectifs individuels ou
d’une fonction de satisfaction, voire de survie, qu’elle cherche à optimiser),
• La possession de ressources propres,
• La capacité de percevoir son environnement (mais d’une manière limitée),
• La disposition d’une représentation partielle de cet environnement (et éventuellement aucune),
• La possession de compétences et la possibilité d’offrir des services,
• La possibilité de reproduction.
On distingue trois types d’agents :
28
Agents réactifs II.2.2.1
Ce type d’agents possède une représentation très simplifiée de l’environnement dans lequel ils
évoluent. Ils sont souvent qualifiés de peu intelligents. Leurs capacités consistent à réagir
uniquement en mode stimulus/Action. Un système Multi-Agents constitué d’Agents réactifs
possède généralement un assez grand nombre d’agents et le succès, dans ce type de systèmes,
porte sur l’émergence d’un comportement collectif intelligent. Nous pouvons citer l’exemple
d’un système multi-agent reproduisant le comportement des fourmis pour trouver le chemin le
plus rapide entre deux points d’un réseau dont le nombre de nœuds et d’arrêtes est inconnu
fait émerger une intelligence collective dans son comportement.
Agents cognitifs II.2.2.2
Sont supérieurs au agent réactifs d’un point de vue pouvoir. Ils possèdent une représentation
de leur environnement ; même si elle partielle, cette représentation est sophistiqué. En plus,
ils ont des buts explicites et sont même en mesure de planifier leur comportement, de
mémoriser leurs actions passées, de communiquer par envoi de messages ou par
l’intermédiaire de langages d’interaction élaborés, de négocier, … etc. A l’inverse d’un SMA
constitué d’agents réactifs, celui composé d’agents cognitifs ne possède qu’un nombre
restreint d’agents. Ces agents peuvent être intentionnels, c’est-à-dire dotés d’attitudes
intentionnelles telles que la croyance, les désirs et les intentions « BDI », rationnels qui
agissent selon la rationalité donnée, normés dans le cas où les agents évoluent dans un
système doté de normes sociales, … etc.
Parmi les architectures cognitives les plus connues, nous citerons celle de Belief,
Desire et Intention (BDI) qui est basée sur les notions d’attitudes mentales que sont la
croyance, le désir et l’intention :
• Les croyances correspondent aux informations dont dispose l’agent sur son environnement ;
• Les désirs correspondent aux états de l’environnement que l’agent souhaiterait voir réalisés ;
• Les intentions correspondent aux projets de l’agent pour satisfaire ses désirs.
Agents hybrides II.2.2.3
D’autres types d’agents qualifiés d’hybrides, qui sont en réalité une mixture des deux types
précédents, sont ensuite apparus. Ces agents intègrent l’aspect cognitif et réactif. Dans une
telle architecture un agent est composé de modules qui gèrent indépendamment la partie
réactive et la partie cognitive. Le problème principal reste de trouver le mécanisme idéal
assurant cette combinaison.
29
Il est très important de souligner que ni les architectures réactives, ni les architectures
cognitives n’offrent de solution unique, mais certaines architectures sont plus adaptées que
d’autres en fonction du contexte.
II.2.3 CHOIX DU TYPE D’AGENTS
Le choix du ou des types d’agents à utiliser dépend en fait du système multi-agents le
plus pertinent pour le problème à résoudre. Ainsi, certains SMA n’utilisent qu’un seul type
d’agents regroupés par objectif, d’autres plusieurs types correspondant à des rôles précis
nécessaires à la résolution.
Selon l’utilisation II.2.3.1
• Agents collaboratifs : Ces agents ont des capacités de coopération. Un regroupement de ces
agents permet, entre autres, de réduire un problème complexe en sous-problèmes moins
complexes.
• Agents d’interface : Ces agents collaborent avec l’utilisateur pour effectuer certaines tâches
telles que les activités de bureautique, les systèmes tuteurs intelligents.
• Agents pour la recherche d’information : Ces agents effectuent, en premier lieu, une
recherche d’informations parmi une collection de données et, en second lieu, procèdent à une
analyse des informations utiles trouvées afin de découvrir de nouvelles connaissances.
• Agents pour le commerce électronique : La montée en puissance de l’Internet a créée de
nouvelles exigences. Les agents issus de cette tendance permettent la promotion, la vente ainsi
que l’achat de produits et de services par l’entremise des réseaux informatiques.
• Agents conversationnels animés : Ce sont des interfaces de dialogue entre des utilisateurs et
des systèmes d’information. Ils se déploient sur des sites Internet, notamment des sites
marchands. Ils sont pourvus de bases de dialogues correspondant aux contextes d’interaction
dans lesquels ils agissent.
• Agents guide ou assistants : Ce type d’agents essayent de suggérer des sites susceptibles
d’intéresser l’utilisateur, en observant son comportement sur Internet. Généralement, quand des
usagers visitent des sites sur Internet, ils laissent une traçabilité (adresse), qui permet à ces agents
de déterminer leurs besoins ou leurs désirs.
Selon la technologie employée II.2.3.2
• Agents stationnaires : Allusion faite aux satellites stationnaires, Il s’agit du cas où l’agent
s’exécute toujours sur la même machine.
• Agents mobiles : A l’inverse des agents stationnaires, les agents mobiles s’exécutent sur
différentes machines en se propageant d’un hôte à l’autre. Typiquement, ils suivent un itinéraire.
30
II.2.4 LES SYSTEMES MULTI-AGENTS
Un système multi-agents peut être considéré comme un ensemble d’agents partageant un
même environnement. Cet environnement peut être décomposé en deux parties,
l’environnement social qui est composé des agents du système et l’environnement physique
au sein duquel ils évoluent.
Propriétés des environnements II.2.4.1
La nature de l’environnement ainsi que ses propriétés influent de manière considérable les
actions des agents. Parmi les propriétés les plus connues, nous pouvons citer :
• Entièrement observable par opposition à partiellement observable : si l’agent a accès à la
totalité de l’environnement en tout temps, cet agent est dit entièrement observable ; celui-ci peut
obtenir une information complète, exacte et à jour sur l’état de l’environnement. Dans un
environnement partiellement observable ou inaccessible, l’agent ne peut avoir qu’une information
partielle.
• Déterministe par opposition à non déterministe ou stochastique : si l’état suivant de
l’environnement est complètement déterminé par l’état courant et par l’action qu’exécute l’agent,
on dit que l’environnement est déterministe ; sinon, il est stochastique. Dans un environnement
non déterministe, une action n’a pas un effet unique garanti. Cependant, si l’environnement est
partiellement observable, il pourra paraître stochastique.
• Dynamique par opposition à statique : si l’environnement peut changer alors qu’un agent est
entrain de prendre une décision (délibérer), on dit que cet environnement est dynamique. L’état
de l’environnement dynamique dépend non seulement des actions du système qui s’y trouve,
mais aussi des actions d’autres processus. Ainsi, les changements ne peuvent pas être prédits par
le système. A l’inverse, un environnement statique ne change pas si le système n’agit pas.
• Continu par opposition à discret : Le nombre d’actions et de perceptions possibles dans un
environnement continu est infini et indénombrable. Dans le cas discret, l’environnement est défini
par un nombre d’états.
• Mono-Agent par opposition multi-Agents : La distinction entre environnements mono-agents
et multi-agents peut sembler relativement simple. Un agent qui résout un problème tout seul ne
doit pas considérer les événements et actions exercés par les autres agents.
Propriétés des Systèmes Multi-Agents II.2.4.2
Les propriétés en termes de rationalité et d’autonomie doivent être précisées dans un système
contenant plusieurs entités.
• Rationalité
31
Le terme rationalité peut être exprimé de différentes manières selon les types de systèmes
multi-agents :
o Pour certains systèmes, chaque agent dispose d’une rationalité propre et peut mesurer
individuellement sa performance. C’est un challenge pour l’agent dans la mesure où il
cherche à maximiser ses gains (critères de performance) éventuellement au détriment des
autres agents du système.
o D’autres systèmes s’intéressent à une mesure de performance globale : Le système, en
question, est caractérisé par une fonction globale de performance ; éventuellement
calculée à partir d’une combinaison de mesures de performances locales. La rationalité est
forcément limitée puisque l’agent ne connaît pas l’environnement ni surtout le
comportement des autres agents. L’absence de capacité sociale ne permet pas aux agents
d’estimer le comportement des autres et par voie de conséquence ne peuvent pas agir
correctement par la suite. Les systèmes de cette catégorie sont intelligents, collectifs et
coopératifs du fait qu’une mesure de performance globale caractérise les performances du
système.
• Autonomie
Plusieurs définitions peuvent être attribuées, en fonction du système, à la notion
d’autonomie d’un agent.
Russel et Norvig [Russel & AL., 2006] ont défini cette notion comme étant la capacité de
l’agent de s’adapter à partir des expériences passée ; l’agent a une mémoire. Dans un système
multi-agent, cette capacité inclut la capacité à s’adapter à l’environnement global du système ;
il a la faculté de se modifier, de changer et de muer. Aussi, il doit s’adapter aux autres agents
présents dont le comportement est inconnu et peut évoluer au cours du temps.
Jennings [Jennings, 2000] définit, quant à lui l’autonomie d’un agent comme étant la faculté
de décider d’une manière autonome de son action sans intervention extérieure. Ceci signifie
que toute action émise dans le système est uniquement à l’initiative d’un agent.
Par conséquent, nous pouvons dire que l’autonomie dans un système multi-agents coopératif
doit permettre à l’ensemble du système d’évoluer.
Typologie des systèmes multi-agents II.2.4.3
On distingue deux grandes classes de systèmes à savoir les systèmes multi-agents
cognitifs et les systèmes multi-agents réactifs en fonction du type des agents qui les
composent.
32
o Les systèmes multi-agents cognitifs
Ces systèmes sont composés d’agents cognitifs souvent en nombre très réduit. La construction
de systèmes multi-agents intelligents peut se faire à partir d’agents dont les capacités de
représentation sont complexes et pouvant disposer de processus de communication élaborés.
o Les systèmes multi-agents réactifs
Ces systèmes sont constitués d’agents réactifs généralement en grand nombre. De tels
systèmes se basent sut l’hypothèse qu’il est possible de produire des comportements collectifs
intelligents complexes malgré la simplicité des comportements individuels. Dans un système
multi-agent, un comportement global complexe peut apparaître comme le résultat des
interactions entre des composants simples en grand nombre. De nombreux phénomènes
peuvent s’expliquer de la sorte (par exemple, les systèmes inspirés des colonies de fourmis).
o Les systèmes multi-agents homogènes
Ces systèmes sont constitués d’agents de même type et donc de même architecture interne.
o Les systèmes multi-agents hétérogènes
Les systèmes de ce type sont composés d’agents dont l’architecture interne est différente. Il y
a lieu à signaler que les systèmes actuels sont généralement hétérogènes.
Espace Système Multi-Agents II.2.4.4
Les systèmes Multi-Agents constituent un espace s’articulant autour de trois axes principaux
et nécessaires pour la conception et la mise en œuvre de systèmes complexes :
Aptitudes cognitives individuelles et collectives ;
apprentissage ; raisonnement ; décision
Concurrence
Langage d’interaction, protocoles
de communication
ESPACE
SMA
Interaction
Distribution des traitements et des
connaissances : Modèles, architectures
Cognition
Figure 6-espace SMA
33
L’axe cognition fait référence aux aptitudes cognitives d’un agent telles que l’apprentissage,
le raisonnement, la prise de décision, la planification autonome, … etc. Ces aptitudes
permettent aux agents de s’adapter aux changements de leur environnement. Cependant, les
agents étant dans un environnement multi-agents, leurs capacités doivent être considérées
dans un contexte collectif
Domaines d’application des SMA II.2.4.5
Les applications des systèmes multi-agents couvrent des domaines tels les systèmes
d’information coopératifs, la simulation sociologique, les outils documentaires adaptés au
Web, les robots autonomes coopératifs, jeux vidéo (plusieurs joueurs), l’aéronautique, la
résolution distribuée de problèmes, … etc. Cependant, les systèmes multi-agents développés
actuellement peuvent être classés en trois catégories [Ferber 2006] :
• Les simulations dont l’objectif est la modélisation de phénomènes du monde réel, afin d’observer,
de comprendre et d’expliquer leur comportement et leur évolution. Ne trouvant pas de
formalisme mathématique adapté, les systèmes multi-agents ont été utilisés dans le domaine de la
modélisation des systèmes complexes. Aussi, ces systèmes ont montré qu’il était possible de
modéliser, dans le domaine des sciences du vivant, les comportements d’entités élémentaires, au
niveau micro, et d’étudier le résultat global de l’interaction de ces entités au niveau macro. En
effet, la simulation multi-agent offre la possibilité de tester rapidement les modifications de
certaines hypothèses ; elle permet, en outre, d’intégrer de nouveaux agents et d’éditer, sur un plan
pratique, les résultats pour comparer les expérimentations les unes aux autres. De plus, elle
permet de préserver l’hétérogénéité du système à simuler.
• Les applications dans lesquelles les agents prennent le rôle d’êtres humains. En effet, la notion
d’agents facilite la conception de ces systèmes et conduit à de nouvelles problématiques centrées
utilisateur telles que la sécurité, la communication, … etc. Les systèmes de ventes aux enchères,
par exemple, où les agents jouent les rôles de commissaire-priseur et d’acheteurs, représentent
une classe d’application de cette catégorie.
• La résolution de problèmes : l’objectif est de mettre en œuvre un ensemble de techniques pour
que des agents participent de manière efficace et cohérente à la résolution du problème global,
sachant que ces agents sont dédiés pour la résolution d’une partie ou l’ensemble du problème.
34
Communication dans les systèmes multi-agents II.2.4.6
Définition
« La communication est l’échange intentionnel d’informations occasionné par la
production et la perception de signes issus d’un système partagé de signes conventionnels. »
[Russel 2006]
Les communications dans les SMA sont inspirées de celles des humains. Ils sont à la
base des interactions et de l’organisation sociale. Si l’agent ne peut pas communiquer, il
devient alors isolé. Par le biais de la communication, les agents arrivent à coopérer et
coordonner leurs actions et exécuter efficacement des tâches en commun.
Pour pouvoir communiquer, les SMA utilisent des langages d’interactions (ACLs, Agent
Communication Languages), tels que KQML, KIF et FIPA ACL.
Interactions dans les SMA II.2.4.7
La notion d’interaction constitue l’essence d’un système multi-agents à partir de
laquelle les agents vont posséder la faculté de produire des comportements collectifs
complexes et dépendants les uns des autres. En effet, la fonction interactionnelle d’un agent
porte sur l’ensemble des mécanismes lui permettant de faire le lien avec son environnement
ainsi que l’ensemble des autres agents. L’interaction peut être considérée comme une mise
en relation dynamique de deux ou plusieurs agents par le biais d’un ensemble d’actions
réciproques [Thomas 2005]. Elle représente de plus un élément nécessaire à la constitution
des organisations.
Définition [Ferber 1995]
« On appelle situation d’interaction un ensemble de comportements résultant du
regroupement d’agents qui doivent agir pour satisfaire leurs objectifs en tenant compte des
contraintes provenant des ressources plus ou moins limitées dont ils disposent et de leurs
compétences individuelles ».
A partir de cette définition, nous pouvons faire une classification des situations
d’interaction selon les critères suivants :
• La présence d’objectifs communs ou compatibles,
• L’accès à des ressources communes
• La répartition des compétences au sein des agents.
35
La notion de situation d’interaction peut s’exprimer, comme les attitudes adoptées par
les agents vis-à-vis des autres agents, en fonction de ces critères et de l’objectif du
système. Jacques Ferber distingua trois grandes catégories d’interactions :
• L’antagonisme entre agents : les agents ont des objectifs conflictuels, ils sont en
compétition, ou ont besoin de ressources communes d’où l’existence d’un conflit sur
ces dernières.
• L’indifférence entre agents : les agents accomplissent leurs tâches individuellement et
atteignent leurs objectifs sans gêne.
• La coopération entre agents : pour atteindre leurs objectifs, les agents doivent
s’entraider. Ces objectifs peuvent être communs aux agents.
En effet, un des aspects importants de la dynamique d’un SMA est la nature des
interactions entre ses entités, étant donné qu’elles constituent un support effectif de la
coopération. Les agents interagissent en vue de coopérer et de coordonner leurs actions
afin d’atteindre des buts locaux (individuel) ou globaux (collectifs). L’interaction est
réalisée à travers un langage compréhensible et commun à tous les agents et peut être :
• Sélective sur un nombre restreint d’agents ; en fonction de l’accointance, par exemple.
• Ou étendue à l’ensemble des agents c’est-à-dire par diffusion.
En outre, dans les systèmes multi-agents, les interactions permettent la combinaison des
fonctionnalités des agents pour faire émerger le comportement global du système.
D’une part, une interaction peut être dans l’une des trois catégories suivantes selon le gain
perçu :
• Incidence nulle ;
• Incidence positive : l’agent perçoit l’interaction comme une aide ;
• Incidence négative : l’agent perçoit l’interaction comme une gêne.
Organisations dans les SMA II.2.4.8
Dans un système multi-agents, les agents sont organisés de manière à connaitre leurs
partenaires et les rôles qu’ils doivent assumer afin d’atteindre un objectif donné.
L’organisation qui est une structure du système permet donc une mise en ordre des agents
et conditionne le comportement de ces agents à travers les contraintes environnementales.
Nous pouvons utiliser la définition de l’organisation dans le domaine des systèmes multi-
agents donnée par Ferber [Ferber, 1995] :
« L’organisation est un agencement de relations entre composants ou individus qui produit
une unité ou un système, dotée de qualités inconnues au niveau des composants ou
36
individus. L’organisation lie de façon interrelationnelle des éléments ou évènements ou
individus divers qui dès lors deviennent les composants d’un tout. Elle assure solidarité et
solidité relative, donc assure une certaine possibilité de durée en dépit de perturbations
aléatoires ».
Dans le même contexte, la définition de [Moujahed 2007] est comme suit :
« Une organisation est un ensemble d’individus regroupés au sein d’une structure régulée,
ayant un système de communication pour faciliter la circulation de l’information, dont le
but est de répondre à des besoins et d’atteindre des objectifs déterminés ».
Dans un système multi-agents, l’organisation est le facteur structurant qui permet aux
agents de connaître leurs rôles et éventuellement leurs partenaires en vue d’atteindre leur
objectif. La dualité existante entre l’aspect statique et l’aspect dynamique de l’organisation
détermine à la fois le processus d’élaboration d’une structure et le résultat même de ce
processus. Ferber distingue alors l’organisation comme étant le processus même de la
structure organisationnelle qui en est le résultat.
Nous pouvons considérer l’organisation comme processus de mise en ordre résultant des
interactions d’agents, et la structure organisationnelle comme étant le regroupement de ces
agents.
On distingue plusieurs types d’organisation :
• Groupe : plusieurs types de groupe existent :
o Groupe simple : un groupe d’individus pouvant coordonner et coopérer afin d’atteindre
un objectif commun et partagé.
o Equipe : est une collection d’individus rassemblés pour effectuer un travail ensemble.
Au sein d’une équipe, la communication entre les individus est impérative puisqu’ils
existent et évoluent dans un environnement.
o Groupe d’intérêts : chaque membre a les mêmes intérêts que les autres. Ces membres
partagent les informations et coopèrent pour réaliser un but commun.
o Communauté de pratique : se constitue lorsque les professionnels se regroupent et
s’organisent pour partager des informations et des expériences à leurs activités.
• Hiérarchie où l’on distingue : o Hiérarchie simple : est basée sur une relation maître /esclave.
o Hiérarchie multi niveaux : les liens d’autorité forment un arbre. Le contrôle de ce type
d’organisation est très complexe.
• Organisation décentralisée : c’est une hiérarchie multi divisions où chaque sommet d’une
branche est une organisation à part entière. La difficulté principale dans ce type d’organisations
est l’intégration des différents résultats provenant des différentes divisions.
37
• Marché : ce type d’organisation se base sur la relation existante entre deux cocontractants qui
doit obligatoirement être régit par des lois (articles). Une instance spéciale du marché est le
Contrat Net Protocol qui est un protocole permettant l’élaboration et l’exécution d’un contrat
entre un agent manager et un agent contractant. Il fait intervenir des agents interagissant entre
les deux cocontractants pendant l’élaboration et l’exécution du contrat au moyen de
performatifs.
• Coalitions : Une coalition est une organisation à court terme basée sur des engagements
spécifiques et contextuels permettant aux agents de bénéficier de leurs compétences respectives
de façon opportuniste.
La coopération entre agents II.2.4.9
Les études dans le domaine de la sociologie ont montré que pour atteindre leurs
objectifs (buts) d’une manière efficace et rapide, les humains doivent coopérer et
coordonner leurs actions puisque leurs capacités sont limitées.
La coopération étant la forme générale d’interaction la plus étudiée dans les SMA,
représente l’attitude sociale qui permet l’augmentation des performances de groupe. De
plus, la coopération se fonde à la fois sur la complémentarité d’intérêt et la confiance.
Définition 1 : [Glizes 2004]
Les caractéristiques de la coopération idéale sont aussi celles d’une coopération totale
où la moindre activité est bénéfique pour autrui :
• Compréhension : un signal perçu doit être interprétable par un système coopératif. La
compréhension mutuelle n’a pas à être postulée mais doit émerger de l’ajustement mutuel entre
le système et son environnement.
• Raisonnement : toute information (un signal interprété) doit avoir des conséquences logiques
dans le système. Autrement dit, toute information doit apporter de la nouveauté, à la différence
des informations déjà stockées.
• Action : les conclusions du processus de raisonnement doivent être utiles à l’environnement du
système.
Définition 2 :
On dira que plusieurs agents coopèrent ou encore qu’ils sont dans une situation de
coopération si l’une des conditions suivantes est vérifiée :
− L’ajout d’un nouvel agent permet d’accroître différentiellement les performances du
groupe ;
− L’action des agents sert à éviter ou à résoudre des conflits potentiels ou actuels.
38
[Ferber 1995] proposa un certain nombre de méthodes permettant de mettre en œuvre
cette attitude coopérative entre agents comme :
• La communication pour échanger des informations ;
• Le regroupement physique des agents ;
• La spécialisation pour rendre certains agents plus adaptés à leur tâche ;
• La répartition des tâches, des informations et des ressources ;
• La coordination d’actions qui correspond à l’exécution des tâches supplémentaires
permettant d’exécuter d’autres actions critiques dans les meilleures conditions.
De plus, certains chercheurs distinguent la coopération indirecte, due aux actions
individuelles émises par les agents faisant évoluer l’environnement, et la coopération
directe résultante des signaux directs émis par les agents.
A partir de ces définitions, nous pouvons déduire qu’un système coopératif doit avoir
les caractéristiques suivantes :
• C’est un système composé d’agents coopératifs. Ces mêmes agents s’entraident, se complètent et se comprennent ;
• Les agents doivent accomplir la tâche pour laquelle ils ont été conçus dans un milieu coopératif ;
Le maintien d’un haut degré de coopération assure la survie et le bon fonctionnement du
système.
La coopération est une caractéristique essentielle dans l’apprentissage en univers multi-agent.
En effet, chaque agent ne possède qu’une vue partielle du système auquel il appartient et il a la
possibilité, grâce à la coopération, de réaliser plus de tâches que s’il avait à travailler seul de manière
individualiste.
Les anciens travaux relatifs à la coopération l’utilisent comme processus de résolution de
problèmes. Les chercheurs se sont ensuite plus particulièrement intéressés à la définition et à la
formalisation de ce concept [Woolridge, 1995]. Dès qu’un système se trouve dans une situation
coopérative, le concept de coopération prend une signification plus large. Il signifie toujours
coopération pour la résolution du problème auquel est confronté le système, mais aussi coopération
entre les entités du système, en l’occurrence les agents, pour que le système ait un fonctionnement
optimal.
L’intérêt des systèmes multi-agents ne porte pas sur la manière dont un agent résout un
problème donné mais sur la manière dont un groupe d’agents arrive à résoudre ce problème. En
effet, une société ne doit pas être vue comme une agrégation d’agents interconnectés, directement ou
indirectement par le biais de l’environnement, ayant des compétences particulières homogènes ou
hétérogènes. Une société repose sur une réelle coopération d’agents et non sur une simple
39
cohabitation. L’aspect collectif lors de la résolution d’un problème et plus exactement la coopération
des agents sont donc des points importants dans ce domaine.
La coopération permet en particulier à des agents de résoudre des tâches qu’ils n’auraient pas
pu résoudre seuls, d’améliorer la productivité de chacun, d’optimiser l’utilisation des ressources,
d’augmenter le nombre de tâches réalisées lors d’un délai imparti… [Freber, 1994].
II.2.5 CONCLUSION
Les SMA proposent aujourd’hui une nouvelle technologie effective de mise en œuvre de
systèmes complexes dès lors que ceux-ci requièrent distribution, ouverture, coopération et
autonomie ajustable. Ces systèmes froment une communauté de recherche issue de plusieurs
influences, dont les principales sont :
• L’intelligence artificielle distribuée ;
• La vie artificielle ou les systèmes inspirés d’organismes vivants ;
• Les sciences sociales et les sciences cognitives.
Dans le chapitre SMA, nous avons présenté un état de l’art sur les agents et systèmes multi-
agents, tout en mettant l’accent sur les concepts d’environnement, de coopération et d’interaction.
L’interaction étant nécessaire pour la coopération, elle nous permet d’observer de manière objective le
système.
40
II.3 CHAPITRE 3 : LES SYSTEMES D'INFORMATION
COOPERATIFS
Chapitre 3 :
Les Systèmes d'Information
Coopératifs
41
II.3.1 INTRODUCTION
Au sein des organisations, l’informatisation a permis de développer une multitude de
systèmes d’information chargés de stocker, d'organiser, d'interroger et de restituer des
données utiles. Pour assurer une parfaite coopération à différents niveaux d’une organisation,
ces systèmes doivent collaborer. Cette collaboration se matérialise par une coopération des
informations issues des SI nouveaux ou existants, une coopération entre les acteurs de
l'organisation ou une coopération avec les autres organisations dans des divers
environnements. La notion de système d’information coopératif constitue la clé de voute aux
exigences citées précédemment. Les SIC ont pour objectif de permettre la coopération de
systèmes d'information à différents niveaux.
Définition
D'après LAROUSSE, la définition littéraire du terme coopérer est agir conjointement
avec quelqu'un. La coopération en informatique est une instanciation de cette définition en
utilisant des moyens logiciels et matériels. Elle désigne une activité informatique menée
par un groupe d'utilisateurs dans un espace informatique commun.
Au début des années 90, les Systèmes d’Information Coopératifs firent leur apparition
grâce à [Boulanger 1991] [Papazoglou& Al., 1992]. Cet axe de recherche est issu
principalement de l’Intelligence Artificielle Distribuée (IAD) et les Bases de Données.
La notion de Système d’Information Coopératif a été introduite au cours de la
conférence CoopIS' 1994 : "Le paradigme pour la nouvelle génération de systèmes
d'information implique un grand nombre de systèmes d'information distribués sur des
vastes et complexes réseaux de communication. De tels systèmes d'information géreront et
accèderont à de nombreuses sources d'information et services. Ils supporteront le travail
humain individuel et collaboratif. Les traitements seront réalisés de façon concurrente sur
le réseau par des systèmes logiciels allant d'applications conventionnelles à des systèmes
applicatifs avancés tels les systèmes experts et les systèmes multi-agents. L'information et
les services seront disponibles sous de nombreuses formes à travers les applications
existantes ou nouvelles. La communication entre les systèmes se fera de façon centralisée
ou distribuée en utilisant des protocoles de communication conventionnels ou issus de
l'Intelligence Artificielle Distribuée. Nous appellerons cette génération de systèmes, les
systèmes d'information coopératifs …".
Selon cette description, les systèmes d'information coopératifs mettent l'accent sur les
défis technologiques à relever et reposent sur des avancées en termes de
télécommunication, de matériels, de logiciels…
42
Dans l'approche des bases de données, un Système d’Information Coopératif est un
système intégrant des sources d'informations distribuées, des bases de données et/ou
systèmes à bases de connaissances, pouvant utiliser des représentations de connaissances et
de données hétérogènes" [BRODIE & CERI, 1992]. Selon la communauté de l'intelligence
Artificielle Distribuée, un SIC est définit comme "un ensemble d'agents (programmes) qui
partagent continuellement des objectifs avec d'autres systèmes d'information, des agents
humains aussi bien qu'avec l'organisation au sein de leur environnement opérationnel"
[HERIN & AL., 2001]. Boulanger & Dubois [BOULANGER & DUBOIS, 1997]
proposent une définition plus fédératrice dans laquelle un SIC est perçue comme "un
ensemble de composants plus ou moins autonomes, souvent préexistants qui travaillent de
manière synergique en échangeant information, expertise et en coordonnant leurs
activités". Ces définitions font apparaître trois aspects des SIC [DEMICHELIS & AL.,
1997] [AGOSTINI & AL., 1998] :
• L’aspect "systèmes distribués". Cet aspect inclut des types variés d'information, d'applications
et de systèmes logiciels ou matériels existants, développés à l'aide de technologies
conventionnelles telles que les langages de programmation, les systèmes de gestion de bases
de données (SGBD), … Les problèmes d’hétérogénéité et d’incompatibilité entre les systèmes
doivent être pris en charge par la coopération. Cette dernière doit ainsi permettre à tous les
systèmes d'une organisation, ou de plusieurs organisations, d'échanger des données et d'utiliser
des fonctionnalités d'autres systèmes. Ainsi, la coopération est située au niveau des données
des applications et doit résoudre les problèmes d’hétérogénéité des sources d’information tels
que le format de stockage des données, la sémantique des données,… Cet aspect a trait aux
recherches sur la coopération de sources de données et l'intégration de l'information.
• l’aspect "travail collaboratif" (workflow, processus métiers, CSCW Computer Supported
Cooperative Work, …), concerne la manière dont des individus travaillant sur un processus
métier ou un projet commun peuvent coordonner leurs activités, prendre en compte les
contingences et changer leurs pratiques à travers les discussions et l'apprentissage. Le
problème de coopération posé est que la collaboration de groupes requiert un haut niveau de
flexibilité des systèmes qui supportent le travail collaboratif. Cet aspect a donné naissance aux
recherches liées à la coopération de tâches et de processus, au groupware, à l'informatique
organisationnelle,…
• l’aspect organisationnel (processus métiers, objectifs stratégiques, …). Il s'intéresse à la
gestion du travail d'un point de vue organisationnel, en faisant abstraction des acteurs ou de la
technologie. Cet aspect concerne les modèles organisationnels globaux, incluant les objectifs
43
métiers et organisationnels, les politiques,… Dans ce cadre, les "outils" de coopération ont
trait aux modèles de processus organisationnels, aux modèles de règles métier et aux modèles
d'objectifs et d'interdépendances entre les agents organisationnels,…
Les principaux objectifs de tels systèmes sont :
• résoudre les différents types d'hétérogénéité ou les conflits inhérents à la coopération de
Systèmes d’information ;
• traiter les requêtes soumises au SIC en respectant ses caractéristiques ou propriétés définis
comme suit :
II.3.2 CARACTERISTIQUES ET PROPRIETES DES SIC
Un système d’information coopératif repose sur des principes tels que l’autonomie, la
distribution et l’hétérogénéité des systèmes composants. Les propriétés telles que la
transparence, l’évolutivité et la scalabilité, permettent d’évaluer la qualité du SIC.
Autonomie II.3.2.1
Cette propriété est dite d’un système possédant la faculté d’action, de modification de
communication sans altération du fonctionnement de l’environnement dans lequel il évolue. Il
y a lieu de citer les principaux types d’autonomie au sein des SIC, à savoir :
• L’autonomie de conception : elle interdit tout changement dans la conception et
l’implémentation des composants du SIC ; c’est des boites noires. Ce principe garantit la
pérennité des applications héritées (legacy systems).
• L’autonomie d’exécution : celle-ci assure la liberté du traitement des requêtes externes
provenant de la coopération. Ainsi, le système peut choisir l’ordre des requêtes ou refuser
certaines d’entre elles, jugées incompatibles avec les contraintes déjà définies : telles que la
sécurité, les droits d’accès, les permissions, …etc.
• L’autonomie de communication : c’est la faculté attribuée à un composant pour pouvoir
communiquer ou non avec d’autres composants et de choisir les modalités (protocoles) de
communication.
• Enfin, l’autonomie d’association : qui est la faculté donné à un composant de pouvoir partager
ou non ses fonctionnalités ou ressources avec d’autres composants.
Hétérogénéité II.3.2.2
Le développement autonome des systèmes, notamment lorsqu’il y a des différences au niveau
de la structure et du type des systèmes composants, produit généralement l’hétérogénéité.
L’hétérogénéité a été classée en trois niveaux, à savoir :
44
• Technique : se réfère sur l’hétérogénéité des plates-formes (Systèmes d’exploitation, architectures
matérielles SISC ou RISC …etc).
• Structurelle : s’appuie sur les différences en matière de :
o Modèles de données (classique, relationnel, orienté objet),
o Langage des requêtes (Langage de manipulation des données, SQL ou OQL),
o Représentation des informations entre composants coopérants, à savoir :
§ Les conflits schématiques : utilisation de concepts différents lors de la représentation de
l’information (la même information peut être une table dans un composant et un attribut dans
un autre composant),
§ Les conflits généralisation/spécialisation : utilisation de plusieurs concepts pour représenter
une information ou d’un concept unique plus général (Une université pourra définir plusieurs
entités pour représenter ses types d’employés alors qu’une autre utilisera une seule entité pour
gérer tous ses employés, i.e. Enseignant, étudiant, administrateurs, …etc).
§ Les conflits d’agrégation : expriment la différence des niveaux de granularité entre les
systèmes. La valeur d’un attribut d’un système composant peut être équivalente à
l’agrégation des valeurs de plusieurs attributs dans un autre système. L’attribut « adresse »
constitue un bon exemple.
§ Les conflits de types : constituent la différence des types de données entre attributs porteurs de
la même information. L’attribut « Date » peut être déclaré chaîne de caractères, dans un
système composant, et par un type date dans un autre système.
• Hétérogénéité sémantique : Représente les différences dans l’interprétation ou la signification
d’une même donnée. Aussi, cette hétérogénéité sémantique symbolise les conflits de domaine de
définition. Elle englobe, plus exactement, les conflits suivants :
o Les conflits de noms : Ces conflits concernent la synonymie (des termes différents expriment la
même information), l’homonymie (des informations différentes possèdent le même nom),
l’hyperonymie et l’hyponymie (un terme peut être plus général ou plus spécifique qu’un ou
plusieurs autres termes). Les conflits de noms relèvent de l’autonomie des systèmes à nommer
les informations.
o Les conflits de valeurs : sont dus à la différence dans la codification des mêmes informations
dans des systèmes différents. Parmi les conflits de valeurs nous distinguons :
§ Les conflits de représentation de données résultant de l’utilisation de valeurs différentes pour
représenter la même information. Par exemple, les valeurs d’attribut « permis de conduire »
pourront être {« oui » ou « non »} dans un système alors que dans un autre, elles seront {0
ou 1}.
45
§ Les conflits de précision de données surviennent quand une même information possède un
degré de précision différent dans des systèmes composants (par exemple, une note sera
représentée par une valeur de {0 à 20} dans un système alors qu’elle sera représentée par une
lettre {A, B, C, D, E} dans un autre).
§ Enfin les conflits d’échelle relèvent de la présentation d’une même information en utilisant
des unités ou mesures différentes (par exemple, une altitude peut être représentée en pieds et
en mètres dans des systèmes différents).
La distribution II.3.2.3
En plus deux problèmes exposés précédemment, le problème de la distribution
physique des sources d’information se pose. La distribution physique des données signifie
que les informations sont réparties entre des sites géographiquement éloignés mais peuvent,
aussi, être localisées sur un même site. Dans le premier cas, c’est-à-dire des sites distants, la
communication est réalisée à travers des réseaux interconnectés et sécurisés. Le problème de
distribution des données est résolu par des techniques nombreuses et disparates telles Hyper
Text Transfer Protocol (HTTPs) ou Common Object Request Broker Architecture (CORBA)/
Internet Inter-ORB Protocol (IIOP). CORBA permet, par exemple, à des composants d’être
utilisés tout en ignorant leur localisation physique.
La transparence II.3.2.4
La transparence concerne l’intégration : un système d’information parfaitement intégré
doit être vu comme un Système centralisé. Pour les utilisateurs, toutes leurs interactions se
font sur un Système locale. Toutefois, ce système intégré doit être fonctionnel, homogène et
cohérent. Nous distinguons trois types de transparence, à savoir :
• La transparence de localisation permet à l’utilisateur d’ignorer la localisation physique de
l’information.
• La transparence au niveau de la modélisation des données où les utilisateurs ne se soucient
aucunement des noms des entités ou attributs des sources d’information.
• La transparence de langage permet aux utilisateurs où l’apprentissage d’un langage de requête
d’extraction des données n’est pas obligatoire pour les utilisateurs. La transparence implique la
présence d’un niveau d’abstraction entre l’utilisateur et les sources d’information.
L’évolutivité II.3.2.5
L’évolutivité est définie comme étant la faculté de prendre en charge les changements
qui peuvent apparaître au sein d’une architecture coopérative. Ces changements interviennent
à deux niveaux :
46
• Au niveau du SIC (ajout / retrait d’un composant participant), • Au niveau des systèmes composants (modification d’un schéma, de l’implémentation ou de la
sémantique d’un composant,…).
La scalabilité II.3.2.6
La scalabilité consiste en la capacité d’un SIC à gérer un nombre important de
systèmes composants. La scalabilité garantit un bon niveau de performance dans l’exécution
d’une requête lorsque le nombre de sources d’information est assez élevé.
II.3.3 TAXONOMIE DES SYSTEMES D’INFORMATION COOPERATIFS
Pour résoudre les différents types d’hétérogénéité, de nombreuses solutions ont été proposées.
Ces solutions doivent assurer ainsi la coopération de sources d’information. Elles permettent toutes,
au moins, de résoudre certains problèmes liés à l’hétérogénéité structurelle – notamment les
différences entre les modèles de données des systèmes composants – et garantissent l’autonomie des
sources d’information locales.
Approches II.3.3.1
A travers les différents travaux sur les SIC, deux approches ont été suivies, à savoir
l’approche fédérée et les approches à base de médiation.
• L’approche fédérée
Selon la définition de SHETH & LARSON, un système fédéré contrôle et coordonne la
manipulation d’une collection de systèmes de gestion de bases de données autonomes.
Chacun des systèmes de base de données participant à une fédération continue à être utilisé
par un ensemble d’applications, de manière locale. L’approche fédérée est orientée vers
l’intégration partielle des structures de données. Les deux auteurs distinguent deux types
d’intégration : l’intégration sous forme de schéma fédéré (couplage fort) et l’intégration sous
forme de vues fédérant plusieurs SI (couplage faible).
o Principes de l’approche L’approche fédérée est basée sur la présence de cinq niveaux de schémas [SHETH &
LARSON, 1990] (figure 6) :
§ Le schéma local représente le schéma base de la fédération dans son modèle local.
§ Le schéma composant est le produit de la traduction d’un schéma local en un schéma
exprimé à l’aide d’un modèle de données commun, appelé modèle canonique ou pivot. Cette
transformation permet de résoudre les problèmes d’hétérogénéité des modèles de données.
§ Le schéma exporté est une vue d’un schéma composant spécifiant les données qui seront
mises à disposition de la fédération.
47
§ Le schéma fédéré peut consister à intégrer statiquement des schémas d’export ou peut être
une vue dynamique sur plusieurs schémas d’export. Il peut y avoir plusieurs schémas fédérés
répartis en fonction des applications clientes ou des utilisateurs. Un schéma fédéré
correspond à domaine d’application.
§ Le schéma externe consiste en une vue d’un schéma fédéré adaptée à une application cliente
ou une catégorie d’utilisateurs. Les schémas externes permettent ainsi de limiter l’étendu et
la complexité des schémas fédérés.
Figure 7-les cinq niveaux de l’approche fédérée
Les quatre premiers niveaux de schémas utilisent un modèle canonique permettant
d’homogénéiser les schémas locaux représentés dans différents modèles de données
(relationnel, objet, hiérarchique, …). Ce modèle canonique est en général un modèle
orienté objet, en raison de ses capacités d’abstraction et de représentation. Le modèle
canonique assure ainsi la résolution de certains problèmes d’hétérogénéité structurelle,
définie précédemment. Cependant, les problèmes d’hétérogénéité sémantique restent
implicites et doivent être pris en compte (en général, manuellement) lors de l’intégration
des schémas.
Cette approche nécessite la présence d’un dictionnaire de données (répertoire de
méta-données des schémas, …), appelé dictionnaire de la fédération, afin de pouvoir
réaliser l’intégration.
48
o Les systèmes fédérés fortement intégrés Les systèmes fortement intégrés permettent aux applications ou utilisateurs de formuler leurs
requêtes sur le schéma fédéré « global » unifié. Les schémas exportés par les différentes sources
de données sont ainsi intégrés en un schéma fédéré unique. La définition du schéma fédéré
global demande, d’une part, l’analyse et la comparaison des différents schémas et, d’autre part,
la résolution des conflits éventuels [KIM & AL., 1994]. Définir un schéma global est une tâche
difficile, limitant les capacités du système à évoluer et à intégrer de nouvelles sources.
Les caractéristiques de tels systèmes sont :
§ L’administration de la fédération a un contrôle total sur la création et la maintenance des
schémas fédérés et des schémas exportés,
§ La transparence de la localisation des données et la distribution des données,
§ Les schémas fédérés sont statiques et donc rarement modifiés,
§ L’autonomie des sources locales n’est pas pleinement respectée.
Les problèmes liés à l’hétérogénéité structurelle sont résolus par le processus
d’intégration. Ce dernier résout également implicitement les problèmes liés à
l’hétérogénéité sémantique du fait que le schéma fédéré global représente l’organisation
des informations pour un domaine d’application particulier. La transparence est assurée,
il suffit de poser une requête sur le schéma fédéré. Néanmoins, l’extensibilité et la
scalabilité sont les critères qui s’adaptent très mal à l’intégration. La fédération est une
approche à préférer dans le cadre d’une coopération peu évolutive de quelques SI.
o Les systèmes fédérés faiblement intégrés
Les systèmes fédérés faiblement intégrés (couplés) n’exigent pas la définition d’un schéma
global et l’intégration des informations des différents systèmes composants est réalisée en
fonction des besoins des utilisateurs. Ces systèmes permettent d’intégrer simplement de
nouvelles sources de données.
Les caractéristiques de tels systèmes sont :
§ L’utilisateur de la fédération est responsable de la création et de la maintenance de la
fédération,
§ L’utilisateur doit être bien informé sur la structure et l’information contenue dans les
schémas exportés,
§ Les schémas fédérés peuvent être créés ou supprimés selon les besoins,
§ Les composants locaux sont autonomes mais uniquement disponibles en lecture seule,
49
§ L’évolutivité des composants locaux.
De tels systèmes n’utilisent pas de schéma partiel ou global prédéfini mais reposent
sur l’utilisation d’un langage de manipulation multi-bases (en général, SQL étendu ou
OQL) et éventuellement, d’un langage de définition de données. Le langage de
manipulation multi-bases comprend un langage de manipulation étendu et enrichi
permettant d’exprimer les opérations des données au niveau multi-bases (capacités
d’adressage des sources d’information, de préfixation des données manipulées par le
nom de la base, de définition de vues multi-bases,…). Un langage de définition des
données peut lui être adjoint et permet l’expression des structures de données et la
définition des dépendances, i.e. contraintes d’intégrité, entre les bases composantes.
L’approche multi-bases est évolutive mais n’offre pas de transparence à la localisation
des données pour les utilisateurs ni une scalabilité importante. Les conflits schématiques
et sémantiques, n’étant pas traités, restent à la charge des utilisateurs.
• Les approches à base de médiation
o Principes
Les approches de type médiation proposent une organisation modulaire des systèmes
d’information de manière à tirer parti de l’accès à de nombreuses sources de données connectées
par des réseaux. La médiation repose sur un composant central, appelé médiateur, qui simplifie,
abstrait, réduit, combine et décrit les données [WIEDERHOLD, 1992 WIEDERHOLD &
GENESERETH 1995] et est chargé des traitements permettant à l’application cliente d’obtenir les
données extraites des sources de données locales. Pour cela, le médiateur encode les connaissances
nécessaires aux transformations sur les données des sources. Un médiateur peut être spécialisé pour
un ensemble de sources ou un domaine d’application. Plusieurs médiateurs peuvent être composés
en une hiérarchie de modules entre l’application et un grand nombre de sources de données.
L’infrastructure de médiation a pour but de rassembler les connaissances permettant
l’intégration des données dans des composants utilisables par plusieurs applications. D’autre part,
l’infrastructure se doit d’être modulaire ; cette modularité permet à l’infrastructure de médiation
d’évoluer facilement et notamment d’intégrer de nouvelles sources.
Une telle infrastructure de médiation reprend et généralise un certain nombre d’idées relatives
aux systèmes de bases de données fédérés. Wiederhold [1992] étend cependant les concepts de ces
derniers, en décrivant notamment des techniques qui, selon lui, doivent être prises en compte pour
la définition des médiateurs. Il cite notamment le domaine de l’intelligence artificielle qui apporte
la notion de déclarativité, les capacités d’explication et l’utilisation d’heuristiques pour explorer de
grands espaces de recherche. Il cite le domaine de la logique appliquée aux bases de données qui
50
permet une approche formelle des problèmes d’intégration. Il cite enfin les techniques qui
permettent un accès efficace aux sources de données, notamment les vues matérialisées et
l’optimisation sémantique.
Les idées et concepts présentés par Wiederhold ont été repris par la plupart des projets de
médiation. Ainsi, les projets issus de ce domaine ont adopté une même architecture pour leur SIC.
La figure suivante décrit cette architecture basée sur trois niveaux : le premier niveau concerne les
SI locaux, le deuxième niveau englobe les différents outils pour traiter les requêtes et résoudre les
conflits et le troisième niveau est dédié aux applications et utilisateurs.
Médiateurs et adaptateurs sont les composants du deuxième niveau du système de médiation.
A chaque source de données est associé un adaptateur. Chaque adaptateur fournit la même
interface d’accès vers les sources de données et masque ainsi l’hétérogénéité de la source associée.
Le médiateur fournit un point d’entrée unique et une vue uniforme sur un ensemble de sources de
données (il résout les problèmes d’hétérogénéité liés aux différences de modèles de données et de
langages de requêtes en présentant les données dans le modèle de médiation ; un modèle de
médiation est généralement défini comme un modèle canonique étendu à la représentation de la
sémantique des informations. Il s’agit d’un modèle de représentation des méta-données des
sources d’information locales, ainsi que des concepts sémantiques entre méta-données).
L’application soumet des requêtes déclaratives au médiateur de manière à obtenir les données
demandées par l’utilisateur.
Pour intégrer une nouvelle source de données, un adaptateur doit être développé. Cet adaptateur
est ensuite enregistré auprès du médiateur. Lorsque l’application soumet une requête, celle-ci est
optimisée par le médiateur, elle est ensuite exécutée. Le moteur d’exécution du médiateur envoie
des sous-requêtes aux sources de données par l’intermédiaire des adaptateurs : chaque sous-requête
envoyée par le médiateur est transformée par un adaptateur en une requête locale au format du
médiateur. Dans une dernière étape, le médiateur rassemble les résultats fournis par toutes les
sources de données impliquées dans la requêtes, les combine et compose la réponse qu’il renvoie à
l’application. Lors de cette étape, le médiateur résout certains conflits structurels et sémantiques.
L’intégration de nouvelles sources de données requiert le développement d’adaptateurs dont
l’interface et les fonctionnalités sont précisément définies. Un système de médiation doit ainsi
fournir les outils pour le développement rapide d’adaptateurs.
Notons enfin que médiateurs et adaptateurs sont souvent conçus et implantés sous formes
d’agents intelligents en raison de leurs fonctionnalités de distribution des connaissances et de
l’exécution des tâches. [CHAWATHE & AL., 1994][GENESERETH, 1997].
51
Figure 8- architecture basée sur un système de médiation
Deux types de médiation peuvent être distingués en fonction de la manière de gérer les requêtes
et d’utiliser la sémantique dans le processus de médiation [JOUANOT, 2000 et 2001] : la
médiation de schémas et la médiation de contextes.
o La médiation de schémas
La médiation de schémas construit au préalable une base d’information prenant en compte les
SI participants. Elle associe au médiateur un ensemble de connaissances qui localisent et intègrent a
priori les informations pertinentes à un contexte d’utilisation. La résolution d’une requête et l’accès
aux données distribuées suivent un plan d’exécution établi par des règles qui définissent où se
trouvent les données pertinentes, comment elles sont transformées et combinées pour fournir un
résultat exploitable. La notion de contexte est ici implicite : le schéma de médiation travaille au
niveau de la structure des données et des outils simplifient la résolution à l’avance des nombreux
conflits. Le schéma de médiation est formé d’interfaces qui peuvent être soit :
§ Des interfaces objet définies sous la forme d’un ensemble de classes virtuelles. Le modèle
choisi pour représenter ces interfaces est en général le modèle ODMG’93 [CATTEL & AL.,
1993] étendu ou non. Les instances des classes virtuelles ne sont pas des objets stockés et
gérés localement mais sont des instances d’objets distants attachés à un SI. Une base de
connaissances met en correspondance ces classes virtuelles avec les éléments des schémas
52
locaux. Les solutions mettant en œuvre des interfaces objet sont, par exemple, DIOM ou
DISCO [TOMASIC 1995] qui utilisent un modèle objet basé sur ODMG’93 ou le projet
ACSIS [BOULANGER & DUBOIS 1997] qui repose sur l’application d’un modèle objet
spécifique.
§ Des interfaces logiques basées sur l’utilisation d’un modèle logique (logique terminologique
ou logique déductive). Les solutions mettant en œuvre des interfaces logiques sont, par
exemple, TSIMMIS [GARCIA-MOLINA & AL., 1997] ou YAT [SIMEON, 1999].
§ Des interfaces objet XML. Le langage XML est utilisé comme modèle commun pour définir
les interfaces de coopération et remplace petit à petit le modèle objet classique. MIX
[LUDASCHER & AL., 1999] est un exemple de projet mettant en œuvre des interfaces
XML : les wrappers fournissent un schéma d’export XML des sources d’information et
permettant l’accès aussi bien à des sites web qu’à des SGBD ; le médiateur correspond à une
vue sur les schémas XML.
Le modèle canonique choisi a un impact très important sur les capacités du SIC à
pouvoir faire coopérer des systèmes intégrant des données structurées, semi-structurées
ou non structurées.
La médiation de schémas est une extension directe de l’approche fédérée avec une
meilleure évolutivité et souvent une meilleure scalabilité, notamment souvent permise
par l’utilisation d’agents intelligents et systèmes multi-agents.
o La médiation de contextes La médiation de contextes est basée sur une représentation explicite de la sémantique des
données à travers la notion de contexte ; ce contexte peut être décrit à l’aide d’outils de types méta-
donnés (sont définies comme des données sur des données, i.e. des informations sur le stockage et
la gestion des données. Elles décrivent le contenu de l’information des systèmes composants.)
[LIBOUREL & AL., 2003] ou ontologies (une ontologie est une description des concepts d’un
domaine et des relations entre ces concepts. Les termes d’un vocabulaire liés par des relations
sémantiques (synonymie, homonymie,…) forment une ontologie. Un contexte spécifie un
ensemble de connaissances sur la structure, les valeurs ou les fonctionnalités d’un objet qui permet
d’en saisir la sémantique.
La médiation de contextes repose sur l’intégration dynamique des informations en fonction du
contexte de l’application ou de l’utilisateur. Chaque source d’information décrit le contexte de ses
informations et doit se définir par rapport à un modèle de référence. Chaque système composant
doit donc spécifier un contexte d’utilisation du modèle de référence ; à la charge du médiateur de
réconcilier les différents contextes des composants. Dans la plupart des approches, le médiateur est
53
associé à un contexte d’application qui utilise les concepts et le vocabulaire d’une ontologie, l’accès
à un médiateur particulier définit alors le contexte d’une application. Deux types de médiation de
contextes peuvent être distingués :
§ L’approche mono-domaine repose sur un ensemble unique de connaissances (domaine
unique) pour décrire la sémantique des informations. Un médiateur est alors associé à une
ontologie unique représentant la connaissance du domaine d’application. La scalabilité est
représentée mais reste limitée en raison du fait que chaque système composant doit définir le
contexte de ses données par rapport à chaque domaine auquel il souhaite être rattaché. Les
SIC basés sur la médiation de contextes et mettant en œuvre une approche mono-domaine
sont, par exemple, SIMS [ARENS & AL., 1993] et COIN [GOH, 1997].
§ L’approche multi-domaines repose sur la distribution des informations sur des domaines de
connaissances différents, domaines en relation les uns avec les autres. Un médiateur prend
ainsi en charge les ontologies liées aux différents domaines de connaissances et devra
disposer d’outils spécifiques pour comparer et réconcilier des domaines distincts. Ces
différents outils devront permettre de définir :
Ø Des relations de synonymie, d’homonymie ou d’antonymie entre les termes désignant les
concepts d’un domaine (termes d’ontologie),
Ø Des relations inter-ontologies explicitant les règles de mise en correspondance entre les
concepts de domaines différents.
Les solutions de médiation de contextes multi-domaines sont, par exemple,
OBSERVER [MENA, 1999] et INFOSLEUTH [BAYARDO & AL., 1997]. Ces
solutions utilisent différents moyens pour représenter et lier des domaines
sémantiquement différents tels les treillis d’ontologie, les hiérarchies d’ontologies ou les
agents intelligents et systèmes multi-agents.
La médiation de contextes assure une résolution dynamique des conflits et ne requiert
pas la connaissance a priori des SI participants (pas de schéma de médiation).
Comparaison des approches II.3.3.2
L’objectif est de comparer les différentes approches coopératives présentées, d’étudier
l’évolution de la coopération mais aussi de montrer la pluralité des concepts et techniques utilisés au
sein des SIC inhérents à chaque approche. Chaque approche est évaluée en fonction des points
suivants :
• Modèle canonique utilisé,
• Représentation de la sémantique du domaine d’application,
• Respect des propriétés pour la coopération,
54
• Types d’hétérogénéité prise en compte,
• Type de proposition (projet de recherche, projet fournissant un prototype ou une
application opérationnelle),
• Modèle d’architecture.
Les différents points de comparaison cités ci-dessus ne se veulent pas exhaustifs, mais
permettent d’illustrer les différences ou points communs entre les approches coopératives ou
entre les SIC (techniques et architectures sous-jacentes,…) à l’intérieur de chaque approche
(tableau 1). Les approches, ou plus exactement les SIC, peuvent être comparés sur de
nombreux autres points, comme par exemple, les techniques d’optimisation ou de traitement
des requêtes [OUZZANI & BOUGUETTAYA], etc.
• Modèle de représentation des données (modèle canonique)
Un modèle canonique est un modèle commun de représentation des données assurant
l’homogénéisation des modèles locaux. Les schémas des sources de données locales (ou schémas
locaux) sont traduits en schémas composants à l’aide de ce modèle. Ce modèle peut être :
o Relationnel,
o Orienté-objet (modèles objet issus des standards object data langage ODL de l’ODGM, OGM,
…),
o Logique (modèles basés sur la logique terminologique tels KL-ONE, LOOM ou KIF ou
modèles basés sur la logique déductive tels LDL, F-Logic ou Prolog),
o Objet XML,
o Propriétaire (extension d’un modèle objet ou logique avec des concepts spécifiques adaptés à la
représentation de données particulières : par exemple, FDS pour les données spatiales,…).
Remarquons que certains SIC, relatifs principalement aux approches à base de médiation de
contextes, n’utilisent pas de modèles canoniques.
• Langage d’interrogation de la coopération
Un langage d’interrogation de la coopération (ou langage global) est étroitement lié au
modèle utilisé pour représenter les données (modèle canonique). Il permet l’accès uniforme aux
informations distribuées (données et connaissances) et peut être :
o Un langage de programmation (C, C++, Java,…), associé à un modèle relationnel ou orienté-
objet. Le langage de programmation est souvent utilisé en combinaison avec un langage
déclaratif.
o Un langage déclaratif (langage dérivé de SQL ou OQL), associé à un modèle relationnel,
orienté-objet voire logique (logique terminologique ou logique déductive).
55
o Un langage déductif, dérivé, par exemple, de Prolog pour un modèle déductif ou de KL-ONE,
LOOM ou KIF pour un modèle terminologique,… Ce langage est également associé à un
modèle relationnel dans certains projets.
Remarquons que certains SIC peuvent combiner plusieurs types de langages, et parfois ils
n’utilisent pas de langages d’interrogation de la coopération.
• Représentation de la sémantique du domaine d’application
La représentation de la sémantique des informations concerne notamment le domaine
d’application, i.e. le domaine général dans lequel les données trouvent une signification. Nous
présentons, dans ce qui suit, quatre types de représentation du domaine d’application possibles :
o Le Schéma : décrit comment sont structurées les informations d’un domaine. De nombreux
projets utilisent un schéma de données pour exprimer le domaine d’application ; le modèle de
données utilisé pour décrire ce schéma est généralement le même que le modèle commun de
représentation des données.
o L’interface objet : elle décrit la sémantique du domaine d’application et nécessite l’utilisation
d’un langage spécifique. Cette interface sert de point d’accès au système pour l’interroger.
o L’annuaire : Un annuaire regroupe une description résumée des différents systèmes d’un
environnement de coopération. Il permet de localiser un SI en fonction d’une thématique
particulière.
o L’ontologie : Elle explicite les concepts d’un domaine d’application. Cette ontologie peut soit
être limitée à un vocabulaire de référence, soit utiliser un schéma terminologique ou logique.
Celle-ci peut être, aussi, hiérarchisée ou non (hiérarchie d’ontologies) ou être une ontologie
universelle prédéfinie. Chaque projet, basé sur l’usage d’ontologies, utilise un langage de
règles pour formaliser les concepts et relations entre ces concepts : F-Logic, KIF,
ONTOLINGUA,…
• Respect des propriétés pour la coopération
Les différents projets respectent à des degrés différents, les propriétés requises pour la
coopération, à savoir, l’autonomie, la distribution, l’hétérogénéité, la transparence, l’évolutivité
et la scalabilité :
o Les propriétés de distribution et d’hétérogénéité sont bien respectées par la plupart des projets et
notamment par les projets de type médiation. L’autonomie est également respectée par la
plupart des solutions, et notamment, l’autonomie de conception en raison de l’utilisation de
schémas d’export ou d’adaptateurs. L’autonomie d’association est assurée principalement dans
les approches de type médiation de contextes.
56
o La transparence doit permettre à l’utilisateur de la coopération de formuler une requête globale
sans se soucier de la modélisation et du langage d’interrogation des données, ni de la
localisation des informations pertinentes. Le schéma global, utilisé dans les approches fédérées
à couplage fort, résout les problèmes de localisation et de modélisation des données et permet
l’utilisation d’un unique langage d’interrogation. La gestion de la transparence, dans ce cas, est à
la charge de l’administrateur de la fédération. Dans le cas des approches fédérées à couplage
faible, la gestion de la transparence est gérée par l’utilisateur et est donc moins bien respectée.
Les solutions de type médiation de schémas fournissent généralement des outils nombreux et
variés permettant d’assurer la transparence à la localisation et de respecter l’indépendance du
modèle local de représentation des données. Les approches de type médiation de contextes
assurent toutes un niveau de transparence à la localisation, à la modélisation et à l’interrogation
de données (les requêtes sont spécifiées selon les termes définis dans l’ontologie).
o L’évolutivité est permise par une intégration dynamique des informations en fonction de la
sémantique de la requête ou de la source d’information. L’évolution est ainsi une caractéristique
de base des systèmes de médiation de contextes. Les autres approches demandent une
modification des connaissances globales ; l’évolutivité sera ainsi respectée en fonction de la
présence ou non d’outils pour simplifier la gestion de ces modifications. De manière générale,
l’évolutivité dans les approches fédérées à couplage faible nécessite des mises à jour
importantes au niveau local si les sources sont nombreuses ; dans les approches fédérées à
couplage fort, l’administrateur de la fédération devra procéder à une mise à jour manuelle de la
coopération qui pourra être facilitée par la présence d’outils.
o La scalabilité est conditionnée par les caractéristiques de résolution dynamique des requêtes, et,
notamment, par l’utilisation d’une ou plusieurs ontologies. La scalabilité est donc une propriété
de bases des systèmes à base de médiation de contextes. La scalabilité est, en outre, encore
mieux gérée avec un petit nombre de relations terminologiques (utilisation de plusieurs
ontologies) plutôt qu’avec une multitude de relations contenues dans une ontologie globale. Les
approches fédérées faiblement couplées assurent également un degré de scalabilité correct du
fait que l’ajout de nouvelles sources reste relativement aisé en raison de la simplicité de leur
modèle de données. Par contre, les approches à base de médiation de schémas nécessitent lors
de l’ajout de systèmes composant, la mise à jour d’un ou plusieurs médiateurs, opération rendue
difficile par la complexité des modèles. L’implantation des médiateurs sous forme de
hiérarchies ou la présence d’outils spécifiques permet cependant d’accroître la scalabilité de
telles architectures.
57
• Types d’hétérogénéité pris en compte
Les projets relevant de l’approche fédérée assurent principalement la résolution des conflits
de modèle de données et de langages d’interrogation. Les systèmes d’information coopératifs de
type médiation de schémas ou médiation de contexte traitent la plupart des conflits structurels et
certains conflits sémantiques. La résolution de ce dernier type de conflit varie cependant selon
les SIC. Ainsi, les systèmes coopératifs de type médiation de contextes résolvent généralement
des conflits sémantiques plus complexes que ceux relevant de l’approche à base de médiation
de schémas.
• Type de proposition
o Recherche : le projet propose des concepts, une méthode de résolution des conflits et une
architecture coopérative permettant la coopération de systèmes d’information, mais ni prototype
ni application opérationnelle.
o Prototype : type de proposition « Recherche » et fourniture d’un prototype.
o Application : type de proposition « Recherche » et fourniture d’une application opérationnelle.
• Modèles d’architecture
Les architectures proposées ont généralement suivi l’évolution des techniques informatiques.
Plusieurs types d’architectures peuvent être rencontrés.
o L’architecture 3-tiers L’application cliente manipule un module applicatif qui est le seul à accéder aux sources
d’information. Ce module intermédiaire traite la requête globale.
o Les objets distribués Les objets distribués sont une évolution des applications 3-tiers, où les fonctions du module
applicatif sont réparties sur plusieurs plates-formes (utilisation d’un middleware CORBA, en général,
pour assurer la communication entre les différents objets).
o Les wrappers Dans les systèmes à base de wrapper, l’application cliente accède directement aux sources
d’information locales via une interface représentée dans un modèle commun. Ce type d’architecture
n’est pas adapté à la résolution des problèmes d’hétérogénéité sémantique.
o Les médiateurs
Le médiateur fournit un accès transparent aux différentes sources de données. Les architectures
peuvent éventuellement être composées de plusieurs médiateurs regroupés par domaine d’application.
o Les agents artificiels
Les agents artificiels sont de plus en plus fréquemment utilisés dans les projets de systèmes
d’information coopératifs. [BRIOT& DEMAZEAU, 2001], ont défini un agent artificiel comme étant,
58
« une entité logicielle ou physique à qui est attribuée une certaine mission qu’elle est capable
d’accomplir de manière autonome et en coopération avec d’autres agents ».
Parmi les dix points de vue proposés par Briot & Demazeau, nous présentons les quatre suivants :
Ø Les agents logiciels : Les premiers agents logiciels utilisés et les plus simples sont les
daemon sous Unix (processus informatique autonomes capables de se réveiller à certaines
heures ou en fonction de certaines conditions). Les virus informatiques en sont des
versions déjà plus sophistiquées (notamment douées de la capacité de reproduction) et
malfaisantes.
Ø Les agents mobiles : l’idée des agents mobiles est de donner la capacité à un agent
logiciel de se déplacer d’une machine à une autre en fonction des données et informations
à traiter ainsi localement. Les motivations sont généralement la minimisation des
communications distantes (il est en général moins coûteux de migrer le code de
traitement que les données à traiter, qui peuvent être beaucoup plus volumineuses) et le
cas de l’informatique nomade (l’agent mobile peut continuer ses traitements sur des
serveurs pendant la déconnexion de la machine cliente).
Ø Les agents cognitifs ou intelligents : Un agent cognitif est un agent de forte granularité
capable de résoudre certains problèmes par lui-même [FERBER, 1995]. Chaque agent
dispose d’une base de connaissances comprenant l’ensemble des règles et des procédures
nécessaires à la réalisation d’objectifs visés et à la gestion des interactions avec les autres
agents :
ü Pour satisfaire un objectif, ils ont des comportements de négociation.
ü Ils sont proches du modèle humain et agissent selon un mode
Perception/Décision/Action. Chaque agent agit en fonction de sa connaissance, de ses
objectifs et de la perception qu’il a de son environnement.
ü Ils disposent de possibilités de communication, i.e. capacités à communiquer avec les
utilisateurs et les autres agents du système, voulant se rapprocher du langage humain.
o Les agents réactifs
Cette approche est basée sur l’émergence des comportements collectifs à partir de
comportements individuels relativement simples (réagissant à des stimuli, d’où leur nom d’agents
réactifs) et n’ayant pas ou très peu de capacités de représentation et de raisonnement [FERBER,
1995]. Chaque agent réactif est de faible granularité, de plus bas niveau qu’un agent cognitif, n’est
pas individuellement intelligent mais participe à l’intelligence du système. Il ne dispose pas d’une
représentation symbolique et explicite de son environnent à partir de laquelle il peut raisonner. Il est
régi par ses capacités sensori-motrices et a ainsi un comportement « réflexe » [FERBER, 1995].
59
Dans la plupart des cas, plusieurs agents autonomes se regroupent et communiquent
ensemble pour la résolution d’un problème donné, car l’approche consistant à le résoudre, en
utilisant un seul agent suscite de nombreuses difficultés [NWANA, 1996]. Ils forment ainsi
un système mutli-agents. Un système multi-agents, dont l’acronyme est SMA ou MAS
pour « multi-agent system » en anglais, est défini comme un ensemble organisé d’agents.
Dans un SMA, il existe une ou plusieurs organisations structurant les règles de cohabitation et
de travail collectif entre agents, à travers la définition des rôles, les partages de ressources, les
dépendances entre tâches, les protocoles de négociation, les résolutions de conflits, …).
Pour la modélisation des SIC, on utilise les paradigmes agents et SMA. L’intérêt porté
sur l’agent pour les systèmes d’information coopératifs réside dans ses capacités
collaboratives, une distribution forte des tâches et des connaissances et permet de construire
des architectures ouvertes et évolutives. Ferber considère que l’utilisation des agents assure
une reconfiguration simple, flexible et dynamique de l’ensemble des composants d’un
système d’information coopératif et confère à ce dernier un niveau de décentralisation assez
élevé.
Ces dernières années, l’intégration des concepts agents dans les SIC s’est faite d’une
manière disparate. Les entités qui étaient spécifiées auparavant à l’aide du paradigme orienté
objet ou par d’autres paradigmes, ont été encapsulées en agents. Ces agents peuvent être des
agents logiciels, des agents mobiles, des agents réactifs et des agents cognitifs. Les systèmes
d’information coopératifs à base de systèmes multi-agents peuvent spécifier plusieurs types
d’agents. Ces agents disposent de dénominations, tâches et rôles variés dans le cadre du
traitement des requêtes globales et de la résolution des problèmes d’hétérogénéité. La
diversité des dénominations et des tâches allouées aux agents est illustrée comme suit :
Ø Le projet coopératif DOK [TARI & AL., 1996][TARI & STOKES, 1997] a évoqué les Agents wrappers, les agents de tâches et les agents de coordination :
« Les agents de coordination, après l’envoi d’une requête globale, sont chargés de
décomposer celle-ci en sous-requêtes et de les transmettre aux agents de tâches
chargés de l’optimisation des requêtes locales, de la gestion des transactions et de
l’accès à l’information souhaitée par le biais des agents wrappers. Les agents
wrappers disposent de fonctions de traduction entre langages de requêtes, de
fonctions de réingénierie permettant la modélisation de la sémantique des sources
d’information locales dans le modèle de représentation commun et de fonctions de
sécurité et de réplication des données ».
Ø Genesereth & AL, ont utilisés des agents facilitateurs et des agents wrappers dans le projet InfoMaster :
60
« Le composant principal d’InfoMasterest un agent facilitateur qui détermine
dynamiquement la manière la plus efficace de répondre à une requête globale soumise
par un utilisateur, i.e. en n’utilisant que les ressources nécessaires et en résolvant les
problèmes d’hétérogénéité entre ces sources. Les agents wrappers permettent l’accès
aux bases de données ou sources web ».
Ø [Bayardo & AL, 1997] [Fowler & AL., 1999] pour le projet Infosleuth, les agents d’ontologie, agents de courtage, agents utilisateurs, agents ressources, agents moniteurs, agents d’exécution de tâches, agents d’analyse de données ont été définis :
« Les agents d’ontologie gèrent les ontologies de domaine, i.e. la création, la mise
à jour et l’interrogation de chaque ontologie. Les agents de courtage répertorient les
services et la localisation de chaque agent du système et ont pour rôle d’assurer la
mise en relation des agents fournisseurs et des agents clients, lesquels varient selon le
processus de traitement des requêtes.
L’agent utilisateur aide l’utilisateur à construire sa requête globale, puis récupère
et affiche les résultats obtenus. Les agents d’exécution de tâches gèrent les requêtes
exprimées sur l’ontologie en les décomposant et les transmettant aux agents
ressources appropriés. Ces derniers identifient les informations d’une source de
données par rapport à une ontologie, traduisent la requête globale dans le format
local de la ressource et retournent les résultats dans le modèle de l’ontologie après
exécution. Un agent fournisseur ne pourra communiquer avec un agent client que s’il
connaît son emplacement. Cette information lui est fournie par l’agent de courtage.
Les agents moniteurs sont utilisés pour guider les interactions entre les autres agents
et pour enregistrer les traces des plans d’exécution des requêtes. Enfin, les agents
d’analyse des données sont des agents ressources spécialisés dans les méthodes
d’analyse et de fouille de données ».
Ø Les agents wrappers, agents de coopération, agent d’ontologie et agent d’interface ont été
utilisés pour le projet DECA [BENSLIMANE & AL., 1998 + 2000] :
« Les agents de coopération assurent le rôle de médiateur et sont chargés de
décomposer la requête globale soumise en sous-requête. L’agent d’ontologie
commune composée de concepts et de relations entre les concepts du domaine ainsi
que d’informations sur la localisation des agents de coopération qui ont agréé tout ou
partie de ces concepts. Un agent d’interface constitue l’interface entre un utilisateur
et un agent de coopération gestionnaire chargé du traitement de la requête globale.
Cet agent de coopération sollicite l’agent d’ontologie pour connaître les agents de
61
coopération susceptibles d’intervenir dans le traitement de cette requête. Chaque
agent de coopération traduit la requête dans son propre vocabulaire et détecte s’il
peut participer à son traitement. Si tel est le cas, cette requête sera transmise dans le
langage de requête commun (OQL) aux agents wrappers chargés de la traduction de
la requête dans le langage d’interrogation local et de la demande d’exécution. Les
résultats envoyés par les différents agents sont rassemblés par l’agent de coopération
gestionnaire de la requête et transmis à l’agent d’interface pour affichage ».
II.3.4 CONCLUSION
Au cours de ces dernières années, de nombreux SIC ont été conçus, voire même
implémentés. Ces SIC sont issus d’approches de coopération dissemblables. Cependant,
même à l’intérieur des approches, les SIC diffèrent également sur de très nombreux
points tels que l’hétérogénéité des concepts, les architectures sous-jacentes, les
technologies utilisées et les types de conflits résolus ainsi que la variabilité du respect
des propriétés des SIC,…). En plus, leur processus de conception ou de développement
varie également. De ce fait, comme tout système d’information, les systèmes
d’information coopératifs nécessitent un processus d’ingénierie.
62
II.4 CHAPITRE4 : INGENIERIE DES SYSTEMES D’INFORMATION
COOPERATIFS
Chapitre 4 :
Ingénierie des Systèmes
d’Information Coopératifs
63
II.4.1 INTRODUCTION
L’ingénierie des SIC est définie par Conrad & AL., comme étant « un domaine de
recherche inhérent au développement systématique de solutions interopérables pour les
systèmes hétérogènes et autonomes comprenant aussi bien des bases de données que d’autres
types de sources d’information (…) provenant de domaines d’application variés ».
L’ingénierie des SIC a pour objectif de construire des solutions réutilisables dédiées à la
coopération des sources d’information. Tout comme celle relative aux systèmes
d’information, l’ingénierie des SIC utilisent des concepts provenant du génie logiciel et des
techniques issues de l’intelligence artificielle distribuée telles que les ontologies, les agents ou
systèmes multi-agents.
Dans le même contexte du travail collaboratif, Boughzala définissait l’ingénierie de la
coopération, lors du développement d’un SIC, comme étant « l’étude des concepts, des
méthodes et des techniques permettant d’acquérir, de modéliser et de formaliser la
connaissance afin de la mobiliser ».
Ces deux définitions complémentaires de l’ingénierie des SIC mettent l’accent sur le
développement de solutions d’interopérabilité et sur la nécessité de modéliser et de formaliser
les connaissances portant sur ce développement.
De nombreuses solutions très hétérogènes ont été proposées, portant à la fois sur la définition
de concepts et d’architectures réutilisables. Ces architectures conceptuelles et logicielles
permettent la construction de processus coopératifs entre sources d’information et la
résolution des conflits inhérents. Néanmoins, les SIC existants (et leurs concepts et
architectures sous-jacents) souffrent de trois anomalies rendant leur réutilisation fastidieuse :
• Ils sont très complexes et donc difficilement réutilisables,
• Dans la plupart des cas, leur ingénierie ne s’appuie pas sur les techniques de réutilisation qui
ont fait leurs preuves telles que framework et pattern, …
• Leur documentation est souvent éclatée entre de nombreux articles de recherche et/ou thèses.
Face à ce constat, les recherches du domaine se focalisent sur deux axes, à savoir :
• Augmenter la réutilisabilité des SIC existants avec notamment des techniques de réutilisation
ayant fait leurs preuves dans le monde objet : pattern, framework, composant logiciel,…
• Promouvoir les recherches sur l’aide à l’ingénierie de nouveaux systèmes d’information
coopératifs ; en particulier sur les aspects conceptuels et architecturaux liés à cette ingénierie.
64
II.4.2 TRAVAIL COLLABORATIF
Nous allons essayer de retracer succinctement les grandes étapes de l’évolution de la
notion de travail Collaboratif. Cette notion assez ancienne, autrement appelé, le travail de
groupe assisté par ordinateur fut son apparition durant les années 60, au Research Institute de
Stanford aux Etats-Unis sous la direction d’ENGELBART, considéré aujourd’hui comme le
père fondateur du travail collaboratif. Il développa un système nommé « Augment » qui
recouvre en quasi-totalité toutes les caractéristiques d’un outil de groupware d’aujourd’hui
avec les dimensions technologiques mais aussi humaines et organisationnelles.
Dans les années 70, en milieu universitaire aux Etats-Unis d’Amériques, d’autres
applications de type « travail collaboratif » ont été développées, notamment l’EIES
(Electronic Information Exchange System), qui est réellement un système de téléconférence
développé au New Jersey Institute of Technology sous la direction de TURROF. Son objectif
était de concevoir « un laboratoire de communication électronique utilisable par des
communautés de chercheurs géographiquement dispersées ».
Empruntant le pas aux évolutions et développement des technologies informatiques, aussi
hardware que software, au cours des années 80, les outils de travail collaboratif connurent une
forte expansion. Le terme « groupware » est d’ailleurs cité pour la première fois à destination
du grand public dans un article provenant du magazine anglo-saxon « Fortune » et daté de
1987. Il est présenté comme une « nouvelle manière révolutionnaire» de travailler.
Mais c’est dans les années 90, que le groupware prend son plein essor grâce à l’expansion
de la gestion et de l’économie de l’information et de la communication. C’est le
développement de la bureautique individuelle qui a fait connaître au grand public le célèbre
logiciel « Lotus Notes ».
Le groupware, connu sous le nom de « collecticiel » en France, fait véritablement son
apparition en 1994.
Plusieurs ouvrages utilisant le terme de « groupware » firent leur apparition, plus tard, ce
qui correspond à l’approche orientée « outil » au lancement de cette notion. Le terme «travail
collaboratif» est utilisé par les ouvrages les plus récents. Ceux sont les professionnels qui ont
vu la nécessité de prendre en compte le travail collaboratif afin d’améliorer la communication
aux seins des entreprises.
Les années 2000 voient apparaître de nouveaux types d’outils de travail collaboratif
comme les logiciels libres et le collaboratif web. Le web 2.0, avec les blogs et les sites de type
wiki, facilite l’utilisation du web pour les « novices » et offre des interfaces plus
ergonomiques spécialement pensées pour les utilisateurs.
65
Le groupware est un néologisme inventé, en 1980, par deux éminents chercheurs, à savoir
Peter et Trudy Johnson-Lenz. Ce terme qui est constitué par la concaténation de deux termes,
le groupe « group » d’une part représentant la notion de travail, et d’autre part l’aspect
technologique du logiciel avec le mot « ware » de software. Cependant, le travail collaboratif
ne constitue pas un simple outil permettant une meilleure communication entre plusieurs
individus. A travers la définition suivante, nous pouvons montrer les différentes nuances que
recouvrent cette notion : « une combinaison de technologies, de personnes et d’organisation
qui facilite la communication et la coordination nécessaire à un groupe pour réaliser son
travail de manière collective et efficace, atteindre un but partagé et assurer un gain pour
chacun de ses membres ».
Aux Etats-Unis, un champ disciplinaire appelé CSCW (Computer Supported Cooperative
Work) a vu le jour à partir de ce nouveau concept. Le CSCW étudie le comportement des
individus travaillant en groupe afin de fournir des solutions logicielles adaptées à leurs
besoins. Ce qui signifie que le CSCW a été élaboré en vue de prendre en charge l’aspect
comportemental de l’être humain et les interactions homme/homme et homme/machine.
Le groupware est souvent comparé à d’autres systèmes d’information pour l’entreprise
comme le Gestion Electronique de Documents (GED) ou encore le Workflow.
Le travail collaboratif, la GED et le Workflow sont trois systèmes d’information qui
facilitent le travail de groupe au sein d’une entreprise :
• Le Workflow sert à modéliser les tâches de chacun des acteurs pour la réalisation d’un projet ;
• La GED est un outil « permanent » qui met à disposition les documents de travail utiles pour
l’ensemble des acteurs (référentiels etc.)
• Le travail collaboratif, quant à lui correspond à l’organisation globale d’une structure qui
permet le travail par projet. Le groupware se base sur des technologies de GED, de workflow,
de communication, il facilite ainsi la communication interne et stimule «l’intelligence
collective ».
II.4.3 LA GED
Les solutions de Gestion Electronique de Documents (GED) se sont répondues dans les
entreprises à partir des années 90. Elles sont désignées en anglais par l’expression
« Electronic Document Management (EDM) ». Le qualificatif « Electronique » rend compte
de l’évolution des systèmes de gestion, désormais capables de reproduire le document sous
forme numérique et de proposer un accès direct à celle-ci. A l’instar des solutions
informatiques, ces solutions n’ont pu voir le jour qu’en raison des évolutions technologiques :
les technologies de numérisation et les systèmes de reconnaissance de caractères « Optical
66
Character Recognition (OCR) » ont rendu possible l’acquisition de documents sous forme
numérique, les plates-formes offrent des espaces de stockage plus importants et l’architecture
réseau favorise l’accès aux documents à distance.
Définition
Dans le Dictionnaire Encyclopédique de l’Information et de la Documentation,
Jacques Chaumier définit la GED comme un « ensemble de logiciels concourant à
réaliser les diverses étapes de la chaîne de traitement d’un document : acquisition,
restitution et diffusion ». Un système GED est donc un logiciel qui vise à gérer et
organiser l’ensemble de la documentation produite par l’entreprise.
La mise en place d’une GED, au sein d’une entreprise, présente les avantages
suivants :
• Accès rapide et à distance aux documents par le biais de réseau (l’intranet le plus souvent),
• Pérennité dans l’accès aux documents, • Utilisation d’une base unique pour l’ensemble des documents de l’entreprise, • Conservation des documents.
II.4.4 WORKFLOW
Les systèmes d’informations coopératifs mettent en œuvre des techniques de workflow et
plus généralement de logiciels de groupe. Il est nécessaire de mettre en évidence les
spécificités de ces systèmes en vue d’en tenir compte le plutôt possible dans leur conception
[NUR95]. Il s’agit, en fait, de définir d’une part une méthode d’analyse et de conception
associant le workflow et les autres situations du travail coopératif, et d’autre part des modèles
sous-jacents permettant de représenter les interactions entre coopérants qu’il s’agisse
d’interactions synchrones ou asynchrones, formelles ou informelles. A terme, il serait
intéressant de construire des outils implémentant les méthodes et les modèles ainsi définis.
Les applications workflow automatisent la gestion du flux d’information suivant les
spécifications d’un processus donné. Les tâches de traitement de l’information passent d’une
personne à une autre selon un circuit conditionnel bien défini. Chaque acteur du circuit réalise
se tâche sans avoir besoin de se préoccuper de ce qui a été fait avant, et de ce qui devrait être
fait après. L’application présente à l’utilisateur les informations nécessaires pour effectuer sa
tâche, avant que le processus ne suive son cours vers l’étape suivante. Il n’existe pas
actuellement de définition unique, faisant référence, sur le Workflow. D’après S.
Soubbaramayer [SOU 94] il s’agit d’un « ensemble de logiciels proactifs qui permettent de
gérer les procédures de travail, de coordonner les charges et les ressources et de superviser
le déroulement des tâches ». Le terme « proactif » caractérise parfaitement les logiciels de
67
workflow, en effet d’après la petit Larousse, ce terme se dit d’une chose qui a un effet sur une
autre qui vient après. Ceci signifie, que c’est le logiciel qui invoque l’utilisateur et non
l’inverse.
Le Workflow peut être décrit comme étant le traitement séquentiel d’un document ou un
dossier par des agents successifs qui lui appliquent des actions définies à l’avance AFC 94].
Le workflow correspond avant tout à une activité de séquencement et de coordination du
travail entre les différents acteurs impliqués. La définition donnée par N. Naffah [NAF 94] est
la plus proche de ce concept : « Travail coopératif impliquant un nombre limité de personnes
devant accomplir, en un temps limité, des tâches articulées autour d’une procédure définie et
ayant un objectif global ». Dans le cas du workflow, le terme travail coopératif signifie que
plusieurs personnes sont impliquées pour atteindre l’objectif global, mais à des étapes
différentes du déroulement du travail et cela individuellement à partir du moment où la
personne « prend » la tâche.
Origines du workflow II.4.4.1
Les origines du workflow remontent à la Gestion Electronique des Documents (GED).
Initialement, la GED ne prenait en compte que l’aspect statique de la vie d’un document.
Mais un document n’est pas une entité qui est simplement traitée puis classée. Il circule entre
les agents d’une organisation, cette circulation étant le plus souvent soumise à une procédure
bien définie et donc « programmable ». Le workflow devient donc le complément naturel de
la GED en prenant en compte l’aspect dynamique de la vie du document.
Possibilités offertes par le workflow II.4.4.2
• Un guidage rigoureux des procédures : le guidage de l’enchaînement des tâches garantit
l’exécution d’une affaire conformément au plan de travail et facilite ainsi la mise en place de
normes ISO.
• Un contrôle du flux de travail : les logiciels de workflow permettent de suivre l’état d’avancement
d’un travail étape par étape et de détecter rapidement d’éventuels goulets d’étranglement
correspondant à l’accumulation de tâches en attente sur un poste.
• Un maximum d’automatisation : les pertes de temps dues à rechercher, photocopier, distribuer et
classer les documents sont considérablement diminuées. Les logiciels de workflow offrent aussi la
possibilité d’automatiser toutes les opérations pour lesquelles une intervention humaine n’apporte
pas de réelle valeur ajoutée.
Ces nouvelles possibilités ont des conséquences positives sur la productivité, une
réactivité plus grande aux aléas du marché, une diminution des délais de productions et une
amélioration de la qualité des produits et services rendus.
68
Avantages du workflow II.4.4.3
Les groupes permettent d’accomplir des tâches irréalisables par une seule personne. C’est
la base de toute organisation. L’efficacité d’une organisation dépend de l’efficacité de ses
groupes de travail. On peut les définir comme des regroupements de personnes partageant le
même but et engagées dans une communication continue. Les performances et l’efficacité du
groupe résultent de la coopération mise en œuvre et des décisions prises par ses membres.
L’objectif des logiciels de groupe est de les aider à travailler ensemble.
Réorganisation et approche qualité
Un outil de workflow doit donner à l’entreprise les avantages concurrentiels
nécessaires pour maintenir ou améliorer sa position sur le marché en répondant mieux et plus
vite aux clients. Mais bien automatiser un mauvais processus ne peut pas permettre à
l’entreprise d’atteindre ses objectifs à long terme. C’est donc l’organisation elle-même des
entreprises qu’il faut revoir en premier lieu.
Le principe du « management scientifique » fondé par F.W. Taylor en (1911) vise l’utilisation
d’une main d’œuvre peu qualifiée grâce à une parcellisation des tâches. L’organisation
résultante aboutit à une division verticale du travail basée sur des structures fonctionnelles à
l’intérieur d’un réseau hiérarchique parfois complexe.
Par opposition, l’organisation horizontale correspond à un tassement de la structure
hiérarchique. Elle privilégie la communication et la capacité à réagir immédiatement devant
les changements permanents du marché. Elle est basée sur le processus correspondant à des
« équipes de projets » à l’opposé de l’entreprise verticale basée sur les fonctions. Un
processus est un ensemble d’activités qui, à partir d’une ou plusieurs entrées, produit un
résultat représentant une valeur pour un client interne ou externe [HAM 93]. La démarche qui
consiste en un remodelage complet de l’organisation autour de ses processus est appelée
« Business Process Reengineering » (BPR) par M. HAMMER et J.CHAMPY.
Les outils de workflow se présentent comme une réponse technologique idéale pour répondre
aux objectifs fixés par une activité de reengineering. Ce qui signifie qu’on associe souvent le
développement d’une application workflow à la reconfiguration d’un processus complet.
Les outils de workflow peuvent aussi contribuer à atteindre les standards de qualité prédéfinis
dans la norme ISO 9000. Le contrôle de conformité à cette norme, que l’on peut expliquer par
« écrire ce que l’ont fait, faire ce que l’ont écrit et prouver ce que l’on a fait », passe par une
gestion rigoureuse des documents constituant le manuel de qualité et par l’amélioration du
système grâce à un contrôle de l’enchaînement des procédures. En favorisant les étapes de
contrôle, les suivis et en augmentant le niveau de sécurité des procédures établies, les outils
69
de workflow rejoignent les préoccupations d’un nombre croissant d’entreprises sur la qualité
de leurs services
Le travail de groupe impose parfois quelques adaptations, mais la plupart du temps des
changements radicaux des habitudes et des processus sont impératifs. L’intégration d’une
nouvelle technologie dans une entreprise engendre des interrogations sur l’organisation la
plus adaptée à l’activité, au style de l’entreprise et à la culture du personnel. Le progrès
technique et l’innovation sociale sont étroitement liés.
Catégories d’applications workflow II.4.4.4
Nous distinguons deux grandes catégories d’applications workflow. La première
catégorie concerne les procédures dites « ad-hoc ». Elles ont la caractéristique d’être
occasionnelles et peu structurées. La préoccupation la plus importante de ce genre
d’application se situe au niveau du partage de l’information et du savoir entre les membres
d’un groupe, beaucoup plus que sur la coordination de leurs tâches. Les besoins seront donc
plus axés sur les produits dédiés à la communication. Les logiciels de groupe (autre que le
workflow) sont parfaitement adaptés à ce genre de situation. Lotus Notes est le produit le plus
représentatif de cette catégorie.
Par contre, la deuxième catégorie est constituée d’outils de workflow trouvant
parfaitement leur efficacité pour des procédures très structurées, répétitives, dont les besoins
en coordination et en automatisation sont importants. Ceci est le cas pour les tâches
administratives dans lesquelles les manipulations de dossiers (encore sur papier), circulant
d’une personne à une autre, occupent une part importante de l’activité.
La plupart des groupes au sein d’une entreprise se font et se défont suivant des besoins
ponctuels. Ces groupes constituent par exemple pour des réunions de décision, pour la
rédaction d’un document en commun. Ces activités, souvent imprévisibles, n’entrent pas
forcément dans une procédure formelle de l’entreprise.
Ces activités correspondent à un besoin dont l’origine se trouve dans l’une de ces
procédures. Le type d’activité est décisif pour le choix de collecticiels adéquats. Il y a lieu de
citer, par exemple, la conception coopérative, la décision de groupe, la gestion de projets, …
La taille du groupe est aussi un élément déterminant. On peut considérer que l’intégration de
collecticiels et plus particulièrement de collecticiels synchrones dans une application
workflow consiste à intégrer des groupes de petites tailles effectuant des tâches collectives
dans un groupe de grande taille responsable de la procédure. Une application workflow
comporte souvent un nombre important d’acteurs exécutant des tâches. A l’inverse,
l’organisation d’une réunion concernera la plupart du temps un groupe réduit de personnes
70
dont la décision permettra de poursuivre la procédure en attente de cette décision. Il s’agit
d’un cas d’intégration.
L’outil de workflow servira de fil conducteur pour l’ensemble de logiciels mixtes,
aussi bien logiciels individuels que des logiciels de groupe. Le but de l’intégration est de
rendre transparentes les transitions entre les différents logiciels qui nous intéressent.
Méthodes existantes pour le développement d’une application workflow : II.4.4.5
Le développement d’un système d’information coopératif commence par la
modélisation des processus à automatiser. Pour chaque étape du travail à effectuer, il faudra
déterminer qui fait quoi, à quel moment, après quoi et avant quoi et comment il doit. Mais
aussi définir les détenteurs de l’information, les types de documents traités, les points
éventuels de blocage,…
Dans un premier temps, nous allons définir quels sont les besoins en terme de
modélisation de processus. Nous tracerons ensuite un panorama des méthodes d’analyse et de
conception de systèmes d’information afin de déterminer celle(s) qui convient(nent) le mieux
au développement d’une application workflow.
II.4.4.5.1 Modélisation d’une procédure
On appelle procédure un ensemble prédéfini de tâches partiellement ordonnées, qui ne sont
pas nécessairement exécutées séquentiellement ; boucles et parallélismes sont possibles. Pour
décrire l’enchainement des tâches, il est nécessaire de disposer d’opérateurs logiques disjonctifs
« ou », conjonctifs « et » (unificateurs) et de pouvoir combiner les deux.
Figure 9-description de procédure
71
Chaque tâche se voit attribué un rôle correspondant à un groupe d’acteurs parmi lesquels sera
choisi celui qui l’exécutera. La création des liens qui existent entre un rôle et les acteurs associés
se fait indépendamment de la procédure par l’administrateur de l’outil de workflow. Il est
cependant évident que tous les rôles nécessaires à une procédure doivent être correctement créés
par l’administrateur. En définitive, pour modéliser une procédure en vue d’en automatiser le
déroulement à l’aide de l’outil de workflow, il est nécessaire de représenter (voir figure) le ou les
événements qui la déclenchent, les tâches qui la composent et leurs relations de précédence. Ces
relations définissent des enchainements séquentiels (en série), parallèles (avec leurs points de
rendez-vous) et conditionnels (avec leurs points de retour). Finalement, pour chaque tâche on doit
représenter les événements qui déclenchent son exécution, les moyens nécessaires à sa réalisation
(données et outils) et le rôle associé.
Modèles existants
Pour représenter graphiquement une procédure chaque outil de workflow propose son
propre modèle. Même si les modèles sont très nombreux, par contre les études théoriques qui sont
à leur base le sont beaucoup moins. Nous pouvons distinguer deux catégories de modèles : les
modèles issus des réseaux de Petri et les modèles issus de la théorie des actes du langage (Speech
ActTheory). Les modèles Information Control Net (ICN) et le modèle Action sont les modèles
majeurs résultant de ces deux courants.
Le modèle ICN a été développé par le Palo Alto Research Center (PARC) durant les années
70 [ELL 79]. Dans ce modèle, une procédure est un ensemble d’activités reliées par des
relations de précédence. Une activité peut être élémentaire ou composée. Dans le cas où
l’activité est composée, elle peut être considérée comme une procédure, à son tour, et développé
en tant que telle. Le modèle permet ainsi de choisir le niveau de détail dans la présentation et de
construire une procédure complexe par raffinements successifs. Les activités sont représentées
par des nœuds et les enchainements d’activités par des transitions. Les structures d’alternative,
de parallélisme et de boucle sont utilisées pour décrire les procédures.
Le modèle Action [MED 92] issu des recherches de T. Winograd et F. Flores et visant à
orienter le travail de groupe par rapport à leurs activités de dialogue, de négociation et de prises
de décision. Certains résultats de recherches développées dans le domaine de la linguistique
(Speech ActTheory), ont été utilisés. Le modèle repose sur une structure assez simple : il s’agir
de considérer une tâche comme une relation de communication entre deux participants, un
client et un fournisseur par exemple. La construction du modèle de la procédure se fait par
72
raffinements successifs. La boucle principale représente la procédure dans sa globalité. Les
différentes phases de cette boucle sont ensuite décomposées en d’autres boucles qui peuvent à
leur tour être aussi décomposées,…
Bien qu’ils soient différents, les modèles ICN et Action comportent un certain nombre de
caractéristiques. Ils utilisent une approche de haut en bas « top-down » qui permet de choisir le
niveau de détail dans la représentation et de modéliser une procédure complexe par raffinements
successifs. Ils ont aussi la même finalité : diviser un processus en un nombre fini d’étapes et en
décrire l’enchainement.
La difficulté principale dans l’analyse d’un processus consiste à déterminer l’ensemble des
tâches qui le composent, autrement dit à trouver la bonne granularité des tâches. Une tâche est
définie comme étant un ensemble d’actions réalisées par une seule personne qui remplit ainsi un
certain rôle dans le processus global. Il s’agit donc de bien définir les rôles au préalable. Il est
obligatoire de trouver les personnes qui interviennent dans le processus, en premier lieu, les
rôles qu’elles y remplissent et connaitre comment elles communiquent entre elles pour pouvoir
coordonner leurs différentes activités et ceci dans le but d’atteindre l’objectif global.
Le modèle Action, quant à lui, propose une approche client-fournisseur qui donne au modèle
une dimension inexistante dans le modèle ICN. Dans une procédure modélisée avec Action, on
se rend compte de l’organisation qui justifie la façon dont le processus a été divisé en tâches.
Les responsabilités et les relations entre les intervenants sont clairement identifiées. Cette
dimension est très importante dans « Business Process reengineering BPR ».
L’objectif d’une analyse workflow est de trouver le bon découpage d’un processus en étapes
afin d’en automatiser l’enchainement. Si les modèles ICN et Action sont des modèles adaptés à
la modélisation des procédures, il est important de signaler qu’ils leur manque toute la démarche
d’analyse qui permettrait d’arriver à la solution. En effet, un modèle, aussi parfait soit-il, ne
permet que la représentation de la solution choisie. Sans l’utilisation d’une méthode appropriée,
il est quasiment impossible de construire une solution. Donc, une méthode complète devrait :
• Permettre de déterminer si un outil de workflow est adapté pour automatiser le déroulement du
processus étudié et s’il est avantageux de le faire. Elle doit être suffisamment générale pour
permettre de modéliser n’importe quel processus (même s’il comporte des étapes qui ne
peuvent pas être mises en œuvre par un workflow).
• Prendre en charge l’analyse depuis l’identification des processus jusqu’à la modélisation des
procédures dont on veut automatiser l’exécution.
• Etre en concordance avec les principes de BPR énoncés précédemment ; il faut raisonner sur les
objectifs à atteindre et non sur les fonctions réalisées par les différents services d’un organisme.
73
• Permettre d’aborder des organisations complexes dont les processus ne sont pas clairement
définis. Une approche systémique est requise dans ce cas.
II.4.4.5.2 Méthodes usuelles
Les méthodes de conception de systèmes d’information telles que Merise, SADT,
SART, OMT, OOM, UP et RUP sont toutes orientées vers la structuration des données
et des traitements automatisés. Les aspects organisationnels y sont discernés de façon
parcellaire.
Dans le cas de Merise [Tardieu 83], le modèle organisationnel des traitements repose
sur un formalisme approprié pour décrire l’enchainement des tâches dans une
procédure. Or le problème qui se pose réside dans le choix de la granularité des tâches.
Le modèle organisationnel des traitements de Merise a pour objectif d’arriver à un
découpage qui mette en évidence les traitements par lots et conversationnels nécessaires
au développement d’une application. Ces traitements feront l’objet d’une description
détaillée débouchant sur la programmation des divers modules. Cependant, pour une
application de workflow n’a pas pour but de déterminer une liste de programmes à
développer, mais de trouver comment les agents coordonnent leurs efforts pour
atteindre les résultats escomptés. Il faut trouver la meilleure organisation du travail. Il
s’agit, donc, de fournir à chaque acteur les moyens technologiques qui assistent ou
automatisent son travail individuel tout en lui offrant la possibilité d communiquer avec
les autres acteurs afin de coordonner les différentes activités et atteindre ainsi l’objectif
global.
La méthode OSSAD (Office Support System Analysis and Design) [DUM 90], qui
est une méthode orientée vers l’organisation du travail des hommes, à l’inverse des
méthodes usuelles qui sont orientées vers l’organisation des données et l’automatisation
des traitements, a été conçue dans le cadre d’un projet ESPRIT, qui avait pour objectif
de rechercher des méthodes appropriées au développement de systèmes bureautiques. Il
s’agit d’une approche systémique qui aide à comprendre comment les gens travaillent
au bureau, en incluant les personnes dans le système à concevoir. OSSAD est une
méthode qui permet d’analyser comment différents agents coordonnent leurs tâches en
vue de fournir un résultat global. Son but est d’accompagner le changement en milieu
administratif en profitant des opportunités de réorganisation qu’offrent les nouvelles
technologies informatiques. OSSAD propose deux niveaux de réflexion : l’abstrait et le
descriptif.
74
• Le niveau abstrait vise à représenter l’organisme du point de vue de ses missions et de ses
objectifs, en faisant abstraction des moyens utilisés.
• Le niveau descriptif vise à représenter les conditions de réalisation actuelles ou envisagées
conformément aux objectifs formulés au niveau abstrait. Il prend en compte les moyens
organisationnels (choix d’organisation, partage des responsabilités, flux des informations et
des documents), humains (répartition des collaborateurs dans les différentes unités ou
services) et techniques (outils de type bureautique ou informatique).
a) Le modèle abstrait
Le modèle abstrait s’intéresse aux objectifs en cherchant à représenter ce qui doit être fait
et pourquoi. Il répond aux questions : « Quels objectifs satisfaire ?» et « Que faut-il faire
pour cela ? », en faisant abstraction de la solution pratique employée. Il fixe les
caractéristiques stables et durables du système étudié que tout choix d’organisation devra
respecter. Il sert de cadre à la construction des modèles descriptifs.
Le modèle abstrait se base sur un découpage de l’organisme en Fonctions, c’est-à-dire
en sous-systèmes aux objectifs cohérents. Chaque fonction peut être décomposée en Sous-
fonctions décomposables à leur tour. Au niveau le plus détaillé de l’analyse, les fonctions
non décomposées sont dénommées Activités. Une activité n’a qu’un seul objectif. Ces sous-
systèmes communiquent entre eux et avec l’environnement par échange de Paquets
d’information (abstraction faite de leur support physique).
b) La matrice Activité/Rôle
Le passage entre le niveau abstrait et le niveau descriptif est assuré par la matrice
Activité/Rôle. Les lignes correspondent à des activités (concept abstrait) et les colonnes à des
rôles (concept descriptif). On indique pour chaque activité d’une fonction tous les rôles qui y
interviennent en réalisant une tâche (une croix dans la matrice correspond à une tâche).
A chaque activité du niveau abstrait correspond une Procédure au niveau descriptif.
Le niveau descriptif est constitué de différents modèles destinés à décrire une procédure sous
divers aspects.
c) Les modèles descriptifs
Les modèles descriptifs s’intéressent aux moyens organisationnels, humains et
techniques mis en œuvre pour atteindre les objectifs de l’organisme. Ils représentent la
manière pratique dont le travail est réalisé actuellement ou sera réalisé dans le futur. Ils
répondent à la question : « qui fait quoi ? ». Le niveau de représentation est celui de la
procédure.
75
Il existe trois types de modèles descriptifs : le modèle descriptif des rôles, le modèle
descriptif de procédures et celui d’opérations. Les deux premiers élaborent une
représentation statique du fonctionnement de l’organisme ; aucun élément chronologique
n’est prévu. Le troisième type de modèle constitue le niveau le plus détaillé de la description
et explicite la dynamique de l’organisation.
• Le modèle descriptif de rôles Ce modèle permet de représenter la structure organisationnelle de l’organisme, ou
celle qui lui est proposée, pour accomplir ses activités. Il utilise les concepts de Rôles,
d’Unités et de Ressources. Une unité représente un ensemble de rôles regroupés pour la
commodité de modélisation. Ce qui pourrait correspondre à une unité administrative de
l’organisme étudié. Les informations échangées entre rôles, rôles externes et/ou unités sont
considérées comme ressources.
• Le modèle descriptif de procédures Ce modèle permet de représenter le fonctionnement de l’organisme, c’est-à-dire
l’organisation du travail actuelle ou souhaitée. Il fait appel aux concepts de procédure et de
ressource. Il donne une vue d’ensemble des relations entre procédures.
• Le modèle descriptif d’opérations Il fournit le détail d’une procédure correspondant à une ligne de la matrice
Activité/Rôle. Il y est indiquer qui fait quoi et dans quel ordre. On fait apparaitre ainsi la
répartition du travail entre les divers rôles. On attribue une colonne différente à chacun des
rôles concernés et on y place les Opérations qu’ils effectuent. Le concept d’opération utilisé
correspond au concept de tâches défini précédemment. Les opérations situées dans la même
colonne constituent la tâche effectuée par le rôle concerné dans cette procédure. Ce modèle
utilise un formalisme proche des réseaux de Petri. En plus des simples actions de
précédence, ce formalisme permet de représenter trois possibilités d’enchaînement des
opérations : parallélisme, alternative et boucle.
Certaines opérations d’une procédure peuvent être regroupées en Macro-opérations.
Ceci permet d’obtenir une vue d’ensemble plus simplifiée. Par la suite, chaque macro-
opération peut être détaillée à son tour en un autre diagramme. Le modèle descriptif
d’opérations d’une procédure peut donc se construire par raffinements successifs.
Sur ce type de diagramme peuvent être indiqués les ressources en informatiques et les
outils nécessaires à la réalisation d’une opération. Pour modéliser en détail les moyens que
mobilise une opération, la méthode fournit le diagramme de détail d’une opération qui peut
aussi être utilisée comme une macro-opération (ressources et outils, conditions de
déclenchement, les règles de gestion appliquées à l’opération).
76
OSSAD se propose comme une méthodologie dans laquelle chacun « pioche » pour
construire la méthode adaptée à ses besoins. Nous pouvons considérer cette méthodologie
comme étant un générateur de méthode qui à travers un paramétrage adéquat fournit au
concepteur le modèle qui répond le mieux à ses aspirations.
II.4.5 SECURITE DES SYSTEMES D’INFORMATION
Les évolutions récentes et rapides de l’informatique ont contribué à l’accélération des
échanges d’informations. Les entreprises se trouvent désormais confrontées au contrôle
efficace de la confidentialité, de l’intégrité et de la disponibilité de ces informations.
Véritable point névralgique, le système d’information est souvent la proie de multiples
attaques qui menacent l’activité économique des entreprises et requièrent la mise en place
d’une politique interne de sécurité.
D’une manière générale le système d’information concerne l’ensemble des moyens
(organisation, acteurs, procédures et systèmes informatiques) nécessaires à l’élaboration, au
traitement, au stockage, à l’acheminement et à l’exploitation des informations.
Dans les faits, de nos jours, l’essentiel du système d’information est porté par le
système informatique et la notion de sécurité informatique recouvre pour l’essentiel la notion
de sécurité des systèmes d’information (SSI).
Le concept de SSI recouvre donc un ensemble de méthodes, techniques et outils chargés de
protéger les ressources d’un système informatique afin d’assurer la disponibilité des services,
la confidentialité et l’intégrité des informations.
Les échanges au travers notamment d’Internet ont rendu également nécessaire le
développement de propriétés nouvelles comme l’authentification, la paternité et la traçabilité
de l’information.
La sécurité fait donc appel à différentes techniques complémentaires dont :
• le chiffrement de l’information (cryptologie)
• la protection contre les signaux parasites compromettants (sécurité électronique)
• la protection contre les intrusions dans les logiciels, mémoires ou banques de
données (sécurité informatique).
• la protection contre les accidents naturels et les actes malveillants (sécurité
physique)
Les menaces
Bien que souvent invisibles, du moins tant qu’elles n’ont pas eu de conséquences directes, les
menaces sont cependant bien réelles :
77
• Les menaces physiques Actes de délinquance (vols, détérioration) et accidents naturels sont des menaces physiques
qui visent directement le matériel. Souvent ignorés, les évènements naturels, accidentels ou
malveillants, représentent pourtant jusqu’à 8% des sinistres déclarés (source : étude 2003 du
CLUSIF sur la sinistralité).
Quelle entreprise peut se prétendre totalement à l’abri d’une inondation, d’une tempête ou
d’un incendie d’autant que, si le matériel peut être, le plus souvent, aisément remplacé il n’en
va pas de même des données qu’il contenait ?
• Les menaces informatiques Bien plus connues et envisagées, dès lors qu’on parle de sécurité des systèmes d’informations,
les menaces informatiques (virus, chevaux de Troie, spams...) n’en sont pas moins de réels
dangers. En 2003 environ 18% des entreprises ayant répondu à l’enquête du CLUSIF (étude
sur la sinistralité) ont déclaré avoir été infectées par un ou plusieurs virus et l’impact financier
en a été jugé élevé dans 11% des cas.
Heureusement la plupart des entreprises ont désormais saisi l’importance et l’intérêt des outils
destinés à se prémunir de ces attaques (antivirus, firewall) et ces dernières voient leur
efficacité reculer d’années en années.
• Les menaces internes Bien moins identifiées, les menaces internes sont plus souvent liées à la négligence et à
l’ignorance du personnel de l’entreprise ; il s’agit plus d’inconscience que d’une réelle
volonté de nuire.
En général ces menaces correspondent à un usage personnel du matériel informatique de
l’entreprise avec d’une part le risque d’infection par virus (surtout dans le cas des ordinateurs
portables confiés aux employés) et d’autre part un risque pénal par le téléchargement de
programmes ou de fichiers pirates (films, musiques) qui sont incompatibles avec les
applications professionnelles ou utilisés en dehors du cadre légal (licences d’exploitation).
Les cas d’espionnage industriel sont plus rares mais restent néanmoins un danger bien réel qui
pèse sur les entreprises œuvrant sur des marchés stratégiques. La sécurité des systèmes
d’information passe aussi par la mise en place d’une politique efficace de protection visant à
empêcher toute possibilité d’action malveillante par du personnel temporairement affecté à
l’entreprise (stagiaires...)
78
Les risques sont tout aussi multiples et doivent être pris au sérieux. Nombre de personnes ne
jugent ces risques que sous l’angle de l’entreprise agressée et peu savent ou même imaginent
que leur propre responsabilité est engagée.
II.4.6 CONCLUSION
Les outils de travail coopératif constituent une aide à la mise en place des organisations
de demain, basées sur des structures horizontales plus responsabilisantes. Leur impact sur
l’organisation du travail est important. Néanmoins, la plupart des méthodes de conception de
systèmes d’information sont trop orientées vers l’organisation des données et l’automatisation
des traitements et non vers l’organisation du travail des hommes.
Il serait très intéressant de construire une méthode inhérente à l’analyse du travail du
groupe et plus particulièrement à l’analyse et à la conception d’applications Workflow.
Une application Workflow sert de fil conducteur pour un ensemble d’activités qui
peuvent être individuelles ou coopératives.
Le développement d’une application Workflow étant souvent précédé par la
reconfiguration des processus de travail (Business Process reengineering), la définition d’une
démarche pour cette étape souvent incontournable est aussi nécessaire.
79
III PARTIE II : PROBLEMATIQUE ET SOLUTION PROPOSEE
PARTIE II :
PROBLEMATIQUE ET SOLUTION PROPOSEE
Chapitre 1 : chaine logistique
Chapitre 2 : Méthodologies de développement
Chapitre 3 : Choix et présentation des technologies utilisées
Chapitre 4 : Développement du Système « SICLOG »
80
III.1 CHAINE LOGISTIQUE
Chapitre 1 :
Chaine logistique
81
III.1.1 INTRODUCTION
Quelles sont les évolutions qui ont mené au concept actuel de Supply Chain
Management (SCM – Gestion de la chaîne logistique) ?
Durant les années 50 à 70, les entreprises produisaient principalement sur stock. Cette
production de masse avait pour objet de minimiser les coûts de production et les délais de
livraison. Néanmoins, ce procédé présentait des inconvénients majeurs, à savoir : une
lenteur pour le développement et l’industrialisation de nouveaux produits et le sur-stockage
induisant des immobilisations financières. Ce qui a conduit, vers les années 70 à 80, à un
nouvel essor d’une économie basée sur la demande où aucune production n’est déclenchée
sans avoir au préalable reçu de commande.
A partir des années 80, l’avènement de la mondialisation et de la concurrence, les
exigences de performance financière et l’intégration des technologies de l’information et
des communications ont poussé les consortiums à proposer des produits de bonne qualité,
selon les normes ISO, et à bas prix. Pour ce faire, et afin d’améliorer les temps de cycles de
production par rapport à la concurrence, de nouvelles méthodes de management ont vu le
jour. Parmi ces méthodes nous distinguons la méthode appelée « Just in time » qui a est
utilisée par les gestionnaires dans le but de limiter des stocks de matières premières
« intrants » en organisant et ordonnançant plus précisément l’approvisionnement avec les
fournisseurs. C’est dans ce contexte que les différentes entreprises ont pris connaissance de
l’importance de la relation stratégique Client-Fournisseur, qui constitue les prémisses du
Supply Chain Management, qui au début été orienté « approvisionnement » avec les
fournisseurs directs. Parallèlement à ce concept, des experts en gestion de la logistique ont
disséminé les concepts de materials management et de Distribution Resource Planning
(DRP), une étape supplémentaire pour définir les fonctions transport et distribution
physique de ladite chaîne. L’intégration de la fonction distribution à la partie
approvisionnement forma ainsi la « logistique intégrée », connu aussi sous le nom de
gestion de la chaîne logistique ou Supply Chain Management (SCM).
Actuellement, le SCM s’étend à tous les fournisseurs et à toutes les entités de la
distribution. Le but d’une logistique intégrée est de répandre les bonnes pratiques « best
practices » de gestion à tous les maillons de la chaîne afin d’améliorer globalement la
performance de la chaîne.
D’après la littérature scientifique, l’origine du Supply Chain Management provient du
materials management et du physical distribution après la seconde guerre mondiale, ainsi
que du domaine du functional logistics (différents managers pour toutes les fonctions) et de
82
l’integrated logistics (un seul manager pour toutes les fonctions). Forrester a commencé à
étudier les logistiques fonctionnelles, en 1958, en utilisant une approche systémique. Il
décrivît l’amplification de la demande lorsqu’elle remonte la chaîne vers les fournisseurs.
Ce phénomène porte d’ailleurs son nom « effet Forrester » ou encore « bullwhip effect »,
c’est-à-dire, l’effet boule de neige. Plus tard, en 1969, Bowersox étudia l’évolution de la
logistique intégrée et évoqua ce qui deviendra, par la suite, la chaîne logistique, en
considérant que les entreprises soient reliées entre elles par le flux physique.
La recherche opérationnelle, la dynamique des systèmes, les sciences du management,
le marketing, l’économie, …etc., ont tous contribués pleinement aux concepts du SCM. La
gestion et le contrôle des stocks ont eux aussi participé à ces concepts, à travers le
réapprovisionnement des stocks, ainsi que l’allocation d’ordres de production, la
planification des activités de production et de distribution.
Puis vint le problème d’optimisation de cette chaîne, à travers la maîtrise des coûts et de
l’efficacité interne des entreprises. Ceci mena les scientifiques à fixer un cadre au SCM,
selon deux grands axes, à avoir : la partie achat et approvisionnement et celle du transport
et de la logistique. En effet, ’intégration de ces deux parties dans un même modèle ne
semble pas être chose aisée. Les chercheurs ont élargi leur domaine d’étude en parcourant
toute la chaîne de l’atelier à la chaine en passant par l’usine en vue d’une optimisation plus
globale des systèmes de production, grâce notamment aux avancées dans les technologies
de l’information, les modèles mathématiques et autres outils d’optimisation.
III.1.2 DEFINITIONS ISSUES DE LA LITTERATURE SCIENTIFIQUE
La logistique III.1.2.1
Le mot « logistique » apparut au 18ième siècle, en France, lorsque les problèmes de
soutien à la stratégie militaire furent pris en compte. En effet, le réapprovisionnement en
armement, munitions, vivres, carburants et énergies, effets d’habillement, soins
médicaux, … etc., constituent un soutien multiforme aux armés.
Ce terme pris ensuite une autre dimension, dans le milieu industriel notamment, pour
évoquer particulièrement la manutention et le transport des marchandises.
Jusqu’aux années 70, la logistique ne constituait pas un intérêt majeur dans la gestion
des entreprises, puisqu’elle était considérée comme une fonction secondaire. Elle était
limitée aux tâches d’exécution dans les entrepôts et sur les quais d’expédition.
Au milieu des années 90, la logistique devient une fonction globalisée voire même
mondialisée de gestion du flux physique dans une vision complète de la chaîne
Clients/Fournisseurs, et constitua véritablement une nouvelle discipline du management
83
des entreprises. Cette logistique globale représente l’ensemble des activités internes ou
externes à l’entreprise qui apportent de la valeur ajoutée aux produits et des services aux
clients.
L’évolution vers la logistique globale met en avant un certain nombre de points clés
pour la mise en œuvre des partenariats d’entreprise :
• Partager une vision globale de la problématique logistique avec des partenaires potentiels ;
• Définir le périmètre de la coopération : quelles informations doivent être échangées ?
• Déterminer une vision cible ;
• Informer et former les divers opérateurs pour établir une culture logistique interne et externe ;
• Aligner les processus internes et externes ;
• Utiliser les meilleurs pratiques et s’auto-évaluer ;
• Choisir les outils adaptés pour la mise en œuvre opérationnelle d’une logistique performante.
Supply Chain III.1.2.2
Le terme supply chain signifie littérairement chaine d’approvisionnement. Parmi les
multiples définitions, nous allons citer les suivantes :
• Selon Christopher [Christopher, 1992], la chaîne logistique peut être considérer comme le
réseau d’entreprises qui participent, en amont et en aval, aux différents processus et activités
qui créent de la valeur sous forme de produits et de services apportés au consommateur final.
• Lee et Billington, quant à eux, définissent la chaîne logistique comme étant un réseau
d’installation qui assure les fonctions d’approvisionnement en matières premières, de
transformation de ces matières en composants puis en produits finis, et de distribution de ces
produits vers le client.
• La définition donnée par La Londe et Masters n’est guère différente de la précédente. Une
chaîne logistique est un ensemble d’entreprises qui se transmettent des matières. En règle
générale, plusieurs acteurs indépendants participent à la fabrication d’un produit et à son
acheminement jusqu’à l’utilisateur final – Les producteurs de matières premières et de
composants, les assembleurs, les grossistes, les distributeurs et les transporteurs constituent
l’ensemble des membres de la chaîne.
• Ganeshan et Al., 95 la définissent comme suit : « Une chaîne logistique est un réseau d’entités
de production et de sites de distribution qui réalise les fonctions d’approvisionnement de
matières, de transformation de ces matières en produits intermédiaires et finis, et de distribution
de ces produits finis jusqu’aux clients. Les chaînes logistiques existent aussi bien dans les
84
organisations de service que de production, bien que la complexité de la chaîne varie d’une
industrie à une autre et d’une entreprise à une autre aussi.
• Pour Tayur et al, 99., Une chaine logistique est un système de sous-traitants, de producteurs, de
distributeurs, de détaillants et de clients entre lesquels s’échangent les flux matériels dans le
sens des fournisseurs vers les clients et des flux d’information vers les deux sens.
• Stadlter et Kilger, 00, définissent cette chaine comme étant constituée de deux ou plusieurs
organisations indépendantes, liées par des flux physique, informationnel et financier. Ces
organisations peuvent être des entreprises produisant des composants, des produits
intermédiaires et des produits finis, des prestataires de service logistique et même le client final
lui-même.
• Génin, 03, considère qu’une chaîne logistique est un réseau d’organisations ou de fonctions
géographiquement dispersées sur plusieurs sites qui coopèrent, pour réduire les coûts et
augmenter la vitesse des processus et activités entre les fournisseurs et les clients. Si l’objectif
de satisfaction du client est le même, la complexité varie d’une chaîne à une autre.
• Enfin, Lummus et Vokurka, 04, considèrent que toutes les activités impliquées dans la livraison
d’un produit depuis le stade de matière première jusqu’au client en incluant
l’approvisionnement en matières premières et produits semi-finis, la fabrication et l’assemblage,
l’entreposage et le suivi des stocks, la saisie et la gestion des ordres de fabrication, la distribution
sur tous les canaux, la livraison au client et le système d’information permettant le suivi de
toutes ces activités.
D’autres termes proches ou semblables de « chaîne logistique » sont aussi plus ou
moins utilisés : entreprise étendue, entreprise virtuelle, entreprise réseau, réseau
d’entreprises, entreprise fédérale, entreprise en trèfle en grappe, fractale, organisation triple
I, joint-venture, consortium d’entreprises, constellations d’entreprises,…
Cependant, ces définitions peuvent être classifiées en catégories suivant leur orientation
principale. La chaîne logistique peut ainsi se définir en tant que :
• Succession d’activités Client/Fournisseur,
• Succession d’activités de création de valeur,
• Fonctions ou processus d’approvisionnement, de transformation et/ou de distribution.
85
Pour notre part, nous considérons que :
1. Une chaîne logistique peut se rapporter au processus de soutiens multiformes en vue de
réaliser des objectifs communs ;
2. Cette chaîne fait intervenir plusieurs entités, structures ou organismes ;
3. Ces entités sont liées entre elles par trois flux :
a. Le flux d’information,
b. Le flux physique,
c. Le flux financier.
4. A chacune de ces entités est dédiée une fonction bien déterminée, l’approvisionnement, la
distribution, l’activité spécifique, l’utilisation opérationnelle ;
5. Pour être cohérente et efficiente, la chaîne logistique doit être réglementée, à travers
l’instauration de lois et instructions régissant les activités de ces entités.
Structure physique de la chaîne III.1.2.3
La structure topologique d’une chaîne logistique peut prendre différentes formes, en
particulier trois topologies élémentaires de réseaux (Huang et al., 2003, Croom et al., 2000,
Lambert, 2000, Min et al., 2002) :
1. Structure convergente ;
2. Structure divergente ;
3. Structure hiérarchique ;
4. Et enfin, une structure hybride (combinée convergente, divergente et hiérarchique).
Recyclage
Ressources
naturelles
Clients
finaux
Transformation
matières
premières
Fabrication
composants
Fabrication
produits
Distributeurs
(grossistes)
Distributeurs
(Détaillants)
Distribution et
entreposage
Figure 10-Activités en entreprises de la Chaîne
86
III.1.3 GESTION DE LA CHAINE LOGISTIQUE (GCL)
Définition III.1.3.1
Nous pouvons dire qu’une chaîne logistique existe dès lors qu’au moins deux entités
travaillent sur la réalisation d’un produit ou service donné. Dans ce cas, si cette association est
pilotée convenablement pour maximiser les performances, on pourra parler de gestion de la
chaîne logistique « Supply Chain Management (SCM) ». Plusieurs définitions de la gestion
de la chaine logistique ont été formulées, parmi lesquelles nous distinguons :
• [Jones et Riley, 1985], ont proposé la définition suivante : La gestion de la chaîne logistique
est une approche intégrative pour s’accorder sur la planification et le contrôle du flux
physique depuis les fournisseurs jusqu’aux utilisateurs finaux.
• [Berry et al., 1994], ont défini la GCL comme étant un concept qui vise à construire une
confiance, à échanger des informations sur les besoins des marchés, à développer de
nouveaux produits et à réduire la base de fournisseurs d’une entreprise afin de libérer des
ressources de gestion pour le développement de relations significatives sur le long terme.
• [Simshi-Levi et al., 2000], considèrent que la GCL (SCM) est un ensemble d’approches
utilisées pour intégrer efficacement les fournisseurs, les producteurs, les distributeurs, de
manière à ce que la marchandise soit produite et distribuée au bon endroit, au bon moment
avec une meilleure qualité dans le but de minimiser les coûts et d’assurer le niveau de service
requis par les demandeurs.
• [Geunes et Chang, 2001], quant à eux, ont défini la GCL comme étant la coordination et
l’intégration des activités de la chaîne logistique avec l’objectif d’atteindre un avantage
compétitif viable. La GCL comprend donc un large panel de problématiques stratégiques,
financières et opérationnelles.
• [Rota-Franz et al,. 2001] ont considéré que faire du Supply Chain Management signifie que
l’on cherche à intégrer l’ensemble des moyens internes et externes pour répondre à la
demande des clients. L’objectif est d’optimiser de manière simultanée et non plus
séquentielle l’ensemble des processus logistiques.
• Enfin, [Dominguez et Lashkari, 2004] ont vu que l’intérêt du SCM est de faciliter les ventes
en positionnant correctement les produits en bonne qualité, au bon endroit, et au bon moment
où il y en a besoin et enfin à un coût le plus petit possible. Le principal objectif du SCM est
d’allouer efficacement les ressources de production, distribution, transport et d’information,
en présence d’objectifs conflictuels, dans le but d’atteindre le niveau de service demandé par
les clients au plus bas prix.
87
De ces définitions, nous montrons qu’il s’agit en fait de chaîne logistique intra ou inter-
entreprises. Cette chaîne intra-entreprise constitue un réseau de sites de production
géographiquement dispersés, appartenant à une seule entreprise mère. Ce type de réseau est
appelé « réseau multi-sites ». A l’inverse, une chaîne inter-entreprises est un réseau
d’entreprises économiquement et juridiquement indépendantes. Dans ce cas, lu dualité
existante entre la confidentialité des données et recherche d’une performance globale
s’avère être un problème assez conséquent.
De ce qui précède, nous pouvons conclure que la notion chaîne logistique est présente à
travers les termes « réseaux d’entreprises » ou « réseaux d’entités » qui constitue un fait
organisationnel structurel ayant des activités transverses, à contrario, l’aspect gestion existe
dès lors qu’il s’agit de la façon d’intégrer et de faire interagir toutes ces entités. Donc, cet
aspect peut être considéré comme étant une approche intégrative et ainsi concerne
essentiellement les fonctionnalités qui permettent à un système d’être très performant.
Donc le principal objectif d’un SCM est d’améliorer la compétitivité industrielle en
minimisant les coûts, en assurant le niveau de service requis par les demandeurs (clients),
en allouant efficacement les activités sur les acteurs de production (prestations),
distribution, transport et d’information, en veillant à ce que les acteurs ne développent pas
de comportements locaux antagonistes venant obstruer la performance globale.
Les flux de la chaîne logistique III.1.3.2
Les flux traversant une chaîne logistique sont principalement : les flux d’information,
les flux physiques et financiers. Ces trois flux peuvent avoir lieu soit à travers des règles
stipulées dans les contrats de partenariat, soit conformément à une réglementation qui régit le
fonctionnement de cette association d’entités.
Le flux d’information III.1.3.3
Le flux d’information représente l’ensemble des transferts ou échanges de données entre
les différents acteurs de la chaîne logistique. Ce flux est devenu, de nos jours, de plus en plus
rapide grâce à l’introduction des nouvelles technologies de l’information et de la
communication. Cependant, le développement des flux d’information présente certaines
insuffisances, d’une part, en matière de confidentialité (aspect sécuritaire) entre acteurs, et
d’autre part, du problème de la qualité des données véhiculées qui constitue un risque réel
pouvant affecter les décisions prises sur la base de données erronées ou simplement falsifiées
voire même périmées.
88
Le flux physique III.1.3.4
Le flux physique est constitué par le mouvement des marchandises transportées et
transformées depuis les matières premières jusqu’aux produits finis en passant les divers
stades de produits semi-finis. L’écoulement du flux physique résulte de la mise en œuvre des
diverses activités de manutention et de transformation des produits quel que soit leur état. Ce
flux est considéré comme étant le plus lent des trois flux.
Le flux financier III.1.3.5
Le flux financier concerne toute la gestion monétaire des entreprises : ventes des
produits, achats de matières premières, mais aussi de moyens de production, de location
d’entrepôts, … et bien d’autres charges. Le flux financier correspond, sur le long terme, aux
investissements lourds tels que la construction de nouveaux édifices et de lignes de
fabrication.
III.1.4 LE SYSTEME DECISIONNEL
Le Supply chain management requiert un système décisionnel s’appuyant sur un
système d’information cohérent. Ce dernier constitue le support et la mémoire des
transactions des informations. La transaction de l’information est afférente à l’acquisition, le
transfert, le stockage et l’affichage des données, à travers des tableaux de bord constituant des
moyens d’aide à la décision. Tandis que, l’analyse de l’information est un élément de
l’activité de prise de décision. Au-delà du système d’information, le système décisionnel est
l’organisation par laquelle la chaîne logistique est pilotée, définissant les décideurs à tous les
niveaux hiérarchiques et ce sur le court, moyen et long terme. Le système décisionnel peut
être centralisé ou distribué selon l’organisation adoptée, à savoir : Une chaine logistique
dirigée comme une seule entité par un seul responsable dominant, ou bien, une chaine pilotée
par un groupe de partenaires locaux des entreprises constituant le consortium.
Si, dans le passé, la modélisation de l’environnement d’un décideur se limitait aux
frontières de l’entreprise, avec la notion de la chaine logistique, l’environnement du décideur
s’étend sur tout ou partie de la chaîne. De ce fait, et afin d’optimiser leur décisions et
améliorer les performances de leurs activités, les responsables (système de pilotage) doivent
prendre en compte un plus grand nombre de paramètres, utilisés des outils d’aide à la
décision, basés sur des modèles ou de simulation.
Extension de la notion de niveau décisionnel au réseau d’entreprises
Certaines notions issues principalement de l’entreprise, avec l’approche globale de la
gestion de la chaîne logistique, s’étendent désormais à la chaîne elle-même. Ainsi, la
notion de niveau décisionnel a été appliquée à un réseau d’entreprises.
89
• Au niveau stratégique, on distingue quatre parties :
o La partie « Objectifs stratégiques » : il s’agit de déterminer les objectifs pour l’ensemble des
parties prenantes ;
o La partie « Design, conception ou configuration » : Il s’agit de déterminer la structure de la
chaîne dans sa topologie et dans la sélection des parties prenants ;
o La partie « Développement d’avantages compétitifs » : il s’agit d’analyser comment la gestion
de la chaîne logistique peut développer ou améliorer la compétitivité des entreprises
partenaires ;
o La partie « Evolution historique » : qui se focalise sur l’évolution des stratégies des entreprises.
• Au niveau tactique, on distingue aussi quatre parties :
o La partie « Développement des relations inter-entreprises » : Les relations développées
peuvent être bilatérales ou multilatérales, horizontales ou verticales ;
o La partie « Gestion des opérations intégrées » : c’est la gestion des activités des entreprises
pour garantir l’efficience globale de la chaîne logistique ;
o La partie « Gestion des systèmes collectifs de transport et de distribution » : c’est la gestion
des activités d’acheminement et de ventilation des produits ;
o La partie « Développement de systèmes d’information » : qui cherche à améliorer et fluidifier
l’échange d’informations dans le cadre des objectifs stratégiques.
• Enfin, au niveau opérationnel :
o La partie « Contrôle et gestion des stocks et des flux physiques » : il s’agit des activités de
gestion des stocks au niveau des différents aires de stockage et des mouvements des articles
stockés. Cependant, le contrôle est plus qu’obligatoire dans la mesure où ses articles doivent
faire l’objet d’une surveillance en matière de périssabilité, de conservation et de
conditionnement ;
o La partie « Coordination de la planification de la production » : il s’agit des activités liées à la
régulation, l’ordonnancement et l’assignation des opérations du cycle de production ;
o La partie « Spécification du partage des informations opérationnelles » : il s’agit de définir les
moyens et procédures et de la nature d’échanges d’information pour permettre l’adhésion de
toutes les parties prenantes et assurer un parfaite coopération et coordination. C’est, en
quelques sortes, une base informationnelle de communication ;
o La partie « Développement d’outils de pilotage opérationnel » : il s’agit de la conception et de
la reconfiguration d’outils et de moyens de contrôle des activités afin d’en améliorer les
performances.
90
III.1.5 LES PERFORMANCES
Afin d’améliorer le système global de production, la gestion de la chaîne logistique a mis en
place un certain nombre d’indicateurs de performance, dès fois difficile à quantifier, comme
la satisfaction des clients (disponibilité, délais de réponse, efficacité du service après-vente,
réception du produit avec les bonnes spécifications), l’amélioration de la productivité, de
l’adaptabilité ou de la flexibilité de la chaîne, un meilleur partage de l’information, la gestion
et le partage des risques, la diversification des produits, l’amélioration de la traçabilité, de la
compétitivité … Ces indicateurs sont conçus à partir du suivi de production (niveau des
stocks, nombre de ruptures, …). Ces indicateurs permettent aux décideurs de se fixer les
objectifs à atteindre au bout d’un certain délai.
Comment améliorer la performance
Pour améliorer sa propre performance, l’entreprise doit parfaire la performance globale
de la chaîne, ceci suppose d’elle doit coordonner efficacement avec ses partenaires. En plus
de l’idée de coordination, vient de se greffer la justification stratégique des chaînes
logistiques, qui consiste en l’établissement entre elles d’un rapport gagnant-gagnant aux
entreprises partenaires au détriment des maillons défavorisés. Ce dernier acte nécessite une
confiance entre les acteurs de la chaîne.
Pour améliorer une chaîne logistique, généralement le système de production, il faudrait
être en possession de la performance effective et pouvoir déterminer une cible ou un objectif à
atteindre. La première de cette démarche consiste à mesurer la performance, selon certains
critères. Ensuite, il faudrait prendre des décisions de réingénierie et pouvoir agir sur le
système à travers des facteurs de décision en vue de se projeter vers la cible choisie.
En finalité, la mise en place d’un système performant induit implicitement une ambition
de contrôle et d’amélioration des performances.
Comment mesurer la performance ?
L’évaluation de la performance par un système d’indicateurs de performance est une
problématique largement étudiée dans la littérature récente sur la chaîne logistique. Le
principal objectif étant d’améliorer la performance de l’ensemble de la chaîne, il est
nécessaire de mettre en place des « mesures de performance » à même d’évaluer
l’efficience d’une politique de gestion de chaîne logistique.
[Beamon, 1998] a classé ces mesures de performance en deux catégories : les
mesures de performance quantitatives (retards de livraison, temps de réponse,…) et les
mesures de performance qualitatives (satisfaction du client, intégration du flux physique et
d’information, gestion du risque financier,…).
91
Parmi les modèles qualitatifs, nous distinguons le modèle qualitatif « Supply Chain
Operations Reference model (SCOR) » qui est basé sur un benchmarking des
modélisations de la chaîne logistique. Ce modèle de référence, qui a été créé en 1966 par
un groupement de 69 industriels, est composé de quatre niveaux et donne la description des
processus clés présents dans chaque entreprise de la chaîne logistique. Ce modèle propose
un certain nombre d’indicateurs de performance relatifs à chacun des processus, décrit les
meilleures pratiques associées à chacun des éléments des processus et identifie les
progiciels commerciaux pour les appliquer.
Les principaux indicateurs de performance préconisés par SCOR sont indiqués dans le
tableau suivant :
Activité/processus Niveau stratégique Niveau tactique Niveau opérationnel
Planification Niveau de perception de la
valeur du produit par le
client, variances par rapport
au budget, temps de
commande, coût de
traitement de l’information,
profit net contre ration de la
productivité, temps de cycle
total, temps total de cash
flow, temps de cycle
développement du produit
Temps de requête du
client, temps de cycle de
développement, fiabilité
des techniques de
prévisions, temps de
cycle du processus de
planification, méthodes
de réception des
commandes, productivité
des ressources humaines
Méthodes de réception
des commandes,
productivités des
ressources humaines
Approvisionnement Performance de livraison
des fournisseurs, temps
de réponse des
fournisseurs par rapport
aux normes industrielles,
prix des fournisseurs par
rapport aux prix du
marché, efficience du
temps de cycle des ordres
d’achat, efficience de la
méthode de cash flow
Efficience du temps de
cycle des ordres d’achat,
prix des fournisseurs par
rapport aux prix du
marché
Production Portefeuille de :
produits/services
Pourcentage de rebut,
coût par heure de travail,
utilisation de la capacité,
utilisation des quantités
Pourcentage de rebut,
coût par heure de travail,
indice de productivité des
92
économiques ressources humaines
Livraison Flexibilité du système de
service pour répondre aux
besoins du client, efficience
du plan de distribution de
l’entreprise
Flexibilité du système de
service pour répondre aux
besoins du client,
efficience du plan de
distribution de
l’entreprise, efficacité des
méthodes de facturation,
pourcentage des produits
finis dans le réseau,
fiabilité des performances
de livraison
Qualité des produits finis
livrés, pourcentages des
produits livrés à temps,
efficacité des méthodes
de facturation, nombre de
factures sans fautes,
pourcentages des
livraisons urgentes,
richesse des informations
nécessaires pour
effectuer les livraisons,
fiabilité des
performances de
livraison
Morana et Paché (2000) ont proposé de regrouper ces indicateurs sous forme d’un
tableau de bord prospectif afin d’aider les décideurs, au niveau stratégique, à prendre les
meilleurs décisions, grâce à une meilleure vision sur le système de pilotage.
Notons au passage que c’est Robert Kaplan et David Norton qui ont développé le
concept de tableau de bord prospectif (Balanced Score Card). Leur approche consistait à
retranscrire la stratégie de l’entreprise sous la forme d’indicateurs de performances (KPI –
Ket Performances Indicators), reliant ainsi la stratégie long-terme avec les performances à
court terme. Cet assemblage d’indicateurs financiers et non financiers constitue le tableau
de bord prospectif.
III.1.6 MODELISATION DE LA GESTION DE LA CHAINE LOGISTIQUE
Afin de permettre aux décideurs du Supply Chain Management de prendre des décisions
aisément, plusieurs outils ont été développés par la recherche et transférés par l’offre
logicielle. Il s’agit, d’une part, de la modélisation d’entreprise pour comprendre le
positionnement des activités dans les processus d’entreprise et, d’autre part, des modèles
mathématiques et de résolution optimale, supports en particulier à la planification.
Modélisation d’entreprise III.1.6.1
L’objectif de la modélisation d’entreprise est de représenter l’entreprise pour
comprendre son fonctionnement, pour analyser son comportement et ses performances, pour
93
détecter ses dysfonctionnements, en vue d’améliorer éventuellement ses performances, ou de
valider une nouvelle organisation.
Selon [Ganeshan et al., 1999], la modélisation d’entreprise regroupe la part « concepts
et modèles non quantitatifs » de la littérature scientifique. [Croom et al., 2000] classent la
modélisation d’entreprise dans les modèles descriptifs et non normatifs, [Min et Zhou 2002]
quant à eux, l’ont classée dans les modèles qualitatifs.
La modélisation d’entreprise utilise plusieurs formalismes de modélisation générique.
Cette multitude est parfois une problématique pour définir d’une manière unifiée le
fonctionnement d’une entreprise. [Roque, 2005] proposa un méta-modèle permettant
d’intégrer différentes modélisations par décomposition puis recomposition de composants
élémentaires présents dans ces modélisations. Ce méta-modèle a comme faculté, la facilitation
dans les échanges d’informations entre les modèles ; c’est une forme d’interopérabilité entre
les différentes modélisations d’entreprises.
En général, ces modèles sont centrés ou focalisés sur une entreprise, plutôt que les
chaînes logistiques.
Les modèles analytiques III.1.6.2
Les modèles analytiques permettent la description d’un système par un ensemble
d’équations régissant son fonctionnement. Ces modèles peuvent être déterministes ou
stochastiques, et sont généralement associés à un problème d’optimisation mono ou
multicritères. Des logiciels spécifiques ou génériques ont été élaborés pour la résolution de
ces modèles. Parmi les grandes familles de modèles, nous distinguons les modèles
stochastiques (modélisation par file d’attente, par exemple), les modèles analytiques
(programmation linéaire, par exemple), et les simulations.
Les modèles analytiques ont été classés par [Thomas & Griffin 1996] suivant deux niveaux
hiérarchiques : opérationnel et stratégique. Les problèmes évoqués dans ces modèles au
niveau opérationnel sont la gestion d’une ressource avec file d’attente, la gestion du transport,
l’utilisation ou non de la sous-traitance, la gestion de la production locale ou au contraire
globale, la détermination de la taille des lots pour la production et la distribution, le choix du
type de transport, … Au niveau stratégique, les décisions à prendre sont l’ouverture ou la
délocalisation d’une entreprise eu d’un centre de distribution, l’allocation d’équipements pour
les entreprises, le choix de sites pour l’implantation de nouvelles entreprises pour un nouveau
produit ou pour le changement du flux physique d’un produit à travers la chaîne, le choix de
fournisseurs… Il y a lieu à signaler que la plupart des recherches récentes se focalisent sur les
modèles stochastiques.
94
Les modèles de simulation III.1.6.3
Un modèle de simulation est généralement utilisé dans le cas où il est difficile de
trouver une relation entre les différentes variables et ne pouvant pas se mettre sous la
forme d’un modèle analytique.
[Maria 1997] a procédé à un classement des modèles selon le critère du temps. Ce
classement permettait de faire ressortir deux types de modèles : les modèles statiques dans
lesquels le temps n’est pas pris en compte, et les modèles dynamiques. Les modèles de
simulation sont à la fois stochastiques et dynamiques.
Enfin, [Kleijnen, 2005] a procédé à l’identification de quatre types de simulations. La
simulation de type Tableur, la Dynamique des systèmes, la Simulation évènementielle (à
évènements discrets), et les Jeux d’entreprises. Il mena une étude comparative pour mettre
en évidence l’intérêt de vérifier et valider les modèles, à travers des méthodes statistiques,
pour analyser la sensibilité des facteurs, optimiser les modèles, et étudier leur robustesse.
Offre logicielle III.1.6.4
Durant les années 80, le Computer Integrated Manufacturing (CIM) a rendu possible la
première intégration des activités de production. La généralisation du concept d’intégration
de systèmes informatiques et des processus « métier » dans tous les domaines de
l’entreprise a donné naissance aux Entreprise Resource Planning (ERP), extension du
terme Manufacturing Resource Planning (MRP). Un ERP, basé sur un système
d’information cohérent, intègre et homogène, fournit à l’ensemble des acteurs de
l’entreprise une image unifiée de l’ensemble des informations dont ils ont besoin.
Néanmoins, les ERP visent à une centralisation de l’information et demandent d’être
complétés par des systèmes d’aide à la décision dans un but d’optimisation dépassant les
frontières de l’entreprise.
Sont venus, s’ajouter aux fonctionnalités des ERP, les Advanced Planning Systems
(APS) qui peuvent prendre en compte la capacité finie des ressources lors de la
planification ou de la simulation de plusieurs scénarii de planification et de la gestion
simultanée de plusieurs sites.
D’autres logiciels gravitant autour des ERP sont venus complétés cette panoplie, il
s’agit des Supplier Relationship Management (SRM), des Customer Relationship
Management (CRM), des MAnufacturing Execution System (MES), des Supply Chain
System (SCS), des Warehouse Management System (WMS), des Transport Management
System (TMS) et de l’Advanced Order Management (AOM).
95
Des logiciels relatifs à la conception et au cycle de vie des produits s’ajoutent encore à
cette panoplie de progiciels, il s’agit du Product Lifecycle Management (PLM). Et enfin,
les Echanges de Données Informatisées « Electronic Data Interchange » qui constituent des
logiciels dédiés assurant la communication entre ces logiciels. En effet, un EDI permet de
partager des informations entre les éléments de la chaîne logistique.
Face à ce foisonnement de progiciels et d’éditeurs, généralement les décideurs sont
perdus quant au choix le plus approprié. De plus, l’implantation et la configuration de ces
logiciels sont souvent très lourdes et les résultats escomptés ne sont pas toujours atteints.
Il est à noter que les ERP ainsi que tous les outils accompagnateurs n’ont pas donné
satisfaction car d’une part, les entreprises doivent procéder à une réorganisation de leur
structure pour qu’elles puissent s’adapter aux fonctionnalités, procédures et schéma du flux
informationnel offert par les ERP, et d’autre part, procéder à la modification, à travers une
implantation et reconfiguration draconienne, qui souvent donne des résultats non
satisfaisant.
En effet, l’Economist Intelligence Unit a avancé, en 2007, un taux d’échec de 56%.
Plusieurs milliards de dollars ont été investis dans l’achat, la personnalisation, le
déploiement et le maintien d’ERP, CRM,SCM, ainsi que les autres solutions d’affaires
intégrées, par contre peu d’entreprises peuvent y trouver les avantages promis. La
technologie doit faire plus que simplement automatiser les tâches, elle doit effectivement
refléter les pratiques ad-hoc que les gens réalisent.
C’est face à ces insuffisances que nous avons décidé de prendre en charge l’étude, la
conception et la réalisation système d’information intégré, au profit de notre organisme, où
la chaîne logistique constitue le noyau autour duquel gravitent tous les autres systèmes,
faisant partie du système global.
III.1.7 DESCRIPTION DU SYSTEME D’INFORMATION PROJETE
Il est indéniable que l’acquisition d’outils comme les ERPs ne suffit pas à créer les
conditions d’une bonne gestion. Armé d’une certaine expérience, nous avons essayé de
pénétrer en profondeur dans le fonctionnement de notre organisation pour analyser et
concevoir de nouveaux dispositifs, en mettant notamment en valeur, l’apport de nouvelles
pratiques de mise en réseaux des compétences qui contribuent directement au développement
du capital immatériel. Nous avons adopté une démarche pragmatique permettant de mieux
installer un nouveau système robuste, cohérent et permettant une bonne gestion du capital
immatériel.
96
Une refonte, une rénovation, une création ou une intégration de système d’information
informatisé poursuivent en général les objectifs majeurs suivants :
• Gagner en souplesse et réactivité,
• Réussir l’ouverture du SI à des multiples et parfois nouveaux acteurs,
• Assurer la capitalisation et la valorisation des acquis et de l’expertise métier,
• Enfin, adapter le SI à son temps et le moderniser. C’est l’enjeu majeur de l’urbanisation des
systèmes d’information que d’assurer le succès de telles évolutions, condition sine qua non
d’une modernisation continue.
A une époque où les changements étaient certes importants mais relativement peu
fréquents, il était raisonnable d’envisager la construction d’un nouveau système
d’information. Aujourd’hui, les entreprises sont dans une situation où :
• Le changement est devenu la règle. Les entreprises doivent pouvoir réagir rapidement aux
mouvements des marchés, à la versatilité des besoins des clients, aux évolutions des métiers des
utilisateurs, à l’évolution des technologies … ;
• La prévisibilité des changements extérieurs se réduit, dans un monde concurrentiel soumis
notamment aux effets des modes, les stratégies de communication des différents acteurs
rapprochent de plus en plus l’horizon des changements envisageables ;
• L’horizon temporel des évolutions de l’entreprise est lui aussi raccourci : il dorénavant difficile
de faire des prévisions et de les maintenir telles quelles sur du long terme.
Les décisions stratégiques fréquemment observées dans les entreprises concernent :
• L’intégration (horizontale/verticale) des activités nouvelles pour optimiser les ressources
disponibles, ou au contraire l’externalisation des activités existantes pour se concentrer sur les
maillons à forte valeur ajoutée de la chaîne de valeur ;
• Le recentrage des activités vers le cœur métier pour optimiser la performance, ou au contraire la
diversification pour atténuer les aléas sectoriels. Les entreprises alternent ces deux types
d’action dans le temps en fonction de nombreux paramètres plus ou moins rationnels ;
• La globalisation pour conquérir de nouveaux marchés, pour profiter de l’effet d’échelle, et pour
atténuer les aléas géographiques, ou au contraire l’exploitation de marchés de niches,
l’excellence sur un domaine restreint ou la banalisation.
Les évolutions stratégiques ne se limitent évidemment pas au seul secteur concurrentiel.
En effet, les décisions stratégiques caractérisant sans doute durablement les administrations
aujourd’hui sont les suivantes, qu’il s’agisse des services centraux de l’état ou des services
97
déconcentrés, ou encore des collectivités territoriales ou des établissements publics ou
parapublics en général :
• La mise en place de services aux entreprises et aux citoyens ;
• Le développement de réseaux mettant en œuvre des coopérations nouvelles, ou des
éléments de mutualisation ;
• La dématérialisation des échanges, c’est-à-dire, une administration zéro papier.
L’adéquation du système d’information aux orientations stratégiques de l’organisation
consiste à vérifier la coïncidence entre l’état et le plan d’évolution du système d’information
et la stratégie de l’entreprise. Cet alignement du système d’information à la stratégie de
l’organisation est une garantie de l’efficacité des projets de développement et de la pérennité
des investissements. L’alignement stratégique ne peut être obtenu sans une réflexion amont
nécessitant un investissement à différents niveaux hiérarchiques de la chaîne de direction.
L’alignement stratégique est matérialisé dans un plan pluriannuel d’évolution du système
d’information ; schéma directeur du système d’information.
L’effort d’alignement des stratégies n’est pas une opération ponctuelle, il faut l’inscrire
dans la durée, mettre en œuvre une démarche de suivi de la réalisation des plans d’action, et
leur actualisation en fonction des infléchissements inévitables de la stratégie de l’organisation,
qui est en réalité en mutation constante. Les plans d’actions doivent ainsi se comprendre en
glissement (planification avec glissement).
L’adéquation du système d’information n’est pas une notion statique, mais plutôt un projet
permanent. Cette adéquation est un équilibre dynamique qu’il faut absolument chercher en
permanence. Si ce besoin d’adéquation est majeur, alors il implique la capacité du système
d’information à évoluer.
L’expérience vécue, durant les années 80 à 90, à travers les acquisitions des systèmes
d’informations spécifiques, nous a permis de consolider notre choix, celui de compter sur soi-
même. Dans la majorité des projets, il s’agissait d'adapter son propre système d’information
aux exigences du système acheté. De nos jours, les solutions proposées tels que les ERP
"open source", présentent des difficultés incommensurables en matière de modifications ou
d’adaptation à notre système.
Mais ce qu’il faudrait retenir dans cette phase de développement, c'est que d’une part, a-t-on
fait l’étude de notre système pour pouvoir se muer avec l'organisation proposée par l'ERP? et
d’autre part, peut-on procéder aux modifications, qui prennent beaucoup de temps, à cause de
la non maîtrise du Système d’information, au moment où le développement technologique est
en croissance continue.
98
Ce constat nous a poussés à développer notre propre système, qui éventuellement est
décomposé, vu sa complexité, en plusieurs sous-systèmes. Le système d'information global de
notre organisme intègrera les différents systèmes d’information relatifs aux fonctionnalités
suivantes :
• La fonction opérationnelle ;
• La fonction soutien technique ;
• La fonction soutien opérationnel ;
• La fonction logistique
• La fonction soutien commun ;
• La fonction administration et finances ;
• La fonction Formation ;
• La fonction Protection.
Aussi, nous avons entamé, en se basant sur l'architecture n-tiers, le développement des
tableaux de bord permettant de visualiser tous les indicateurs de performance comme
systèmes d'aide à la décision, non sans oublier l'intégration des outils de travail collaboratifs
tels que la GED et le workflow.
Système d’Information
"SICLOG"
Fonction Opérationnelle
Fonction Soutien
Opérationnel
Fonction de Protection
Fonction de Formation
Fonction Administrative
Fonction Soutien
Commun
Fonction Soutien
Technique
99
III.2 METHODOLOGIES DE DEVELOPPEMENT
Chapitre 2 :
Méthodologies de développement
100
III.2.1 INTRODUCTION
L’évolution des langages de programmation a abouti à des environnements de développement
graphique moins complexes, qui nécessitent peut de codage, du fait qu’on assiste à une
production plus élevée d’applications répondant certes à un besoin simple et immédiat mais
avec un taux d’échec plus élevé. Ceci est due à un codage en méthode dite « bulldozer » et à
l’utilisation d’approches qui engendre des résultats médiocres.
Pour l’approche séquentielle, une étude a montré que « 45% des fonctionnalités développés
ne sont jamais utilisées, et des taux qui atteignent 40 % de dépassement en matière de délais
et de coût par rapport aux premières estimations ». [LARMAN et BASIL, 2003]
III.2.2 L’APPROCHE EN CASCADE
« Dans un cycle de vie en cascade (séquentiel), on essaie de définir la plus grande partie des
spécifications, voire toutes, avant de programmer. Souvent, on entreprend également de créer
une conception complète ou un ensemble de modèles préliminaire au codage. De même, on
tente de définir dès le début un plan ou un calendrier fiable sans être assuré qu’il sera
respecté ». [LARMAN, 2005]
La rupture entre L’utilisateur ou l’expert métier et le développeur lors des phases de
conception et de codage, résulte d’une omission des changements et du scepticisme des
utilisateurs fassent à une solution pour laquelle on peut ou pas participer du tout.
III.2.3 L’APPROCHE ITERATIVE INCREMENTALE
Le principe de l’approche itérative et incrémentale repose sur la croissance et
l’affinement successif du système, le feed-back et l’adaptation cyclique qui constitue une
garantie pour aboutir à un système satisfaisant.
Les avantages qu’offre le développement itératif sont :
• La diminution des échecs et l’amélioration de la productivité et de la
qualité ;
• gestion précoce des risques. ;
• feed-back et implication des utilisateurs ;
• gestion de la complexité ;
• exploitation méthodique des enseignements tirés d’une itération.
Le Processus Unifié III.2.3.1
Le processus unifié est une méthode de travail qui s’est imposé comme processus de
développement itératif pour la construction de systèmes orientés objet. Sa forme la plus
101
élaborée est connue sous le nom de RUP (Rational Unified Process). RUP est une méthode
souple et ouverte, qui incite à inclure des pratiques judicieuses issues d’autres méthodes
itératives modernes tels que XP ou SCRUM, des techniques comme le développement piloté
par les tests, le refactoring, l’intégration continue, le war-room ou les réunions quotidiennes
de SCRUM.
Les caractéristiques essentielles du processus unifié sont :
• Le processus unifié est à base de composants,
• Le processus unifié utilise le langage UML (ensemble d’outils et de diagrammes),
• Le processus unifié est piloté par les cas d’utilisation,
• Centré sur l’architecture,
• Itératif et incrémental.
L’utilisation d’UML comme langage de modélisation accroît la compréhension des concepts
métier et la communication entre l’ensemble des concepteurs, développeurs et l’expert métier.
Les phases du Processus Unifié III.2.3.2
Le Processus unifié organise les activités de développement en quatre phases [LARMAN,
2005] :
o Inception : Elle consiste en une vision approximative de la finalité du projet, une étude
d’opportunité, une définition du périmètre et des estimations globales.
o Elaboration : elle débouche sur une vue plus élaborée, avec l’implémentation itérative de
l’architecture du noyau, la résolution des risques élevés, l’identification de la plupart des besoins
et du périmètre réel ainsi que sur des estimations plus réalistes.
o Construction : il s’agit de l’implémentation itérative des éléments qui présentent des risques, une
complexité moindre, et une préparation du déploiement.
o Transition : c’est la phase des bêta-test et du déploiement.
III.2.4 UML (UNIFIED MODELING LANGUAGE )
Les méthodes d’analyse orientées objet sont initialement issues des milieux
industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c’est-à-dire les
principes et techniques permettant d’augmenter la rigueur et la qualité quand on construit une
application informatique. Initialement, UML est le résultat de la fusion de trois méthodes
orientées objet. La méthode OOD, Obejct Oriented Design, de G. Booch a été conçue à la
demande du ministère de la défense des Etats-Unis. La méthode OMT, Object Modeling
Technic, a été mise au point par Général Electric. Et enfin, la méthode OOSE, Object
102
Oriented Software Engineering, est d’origine universitaire (informatique temps réel) et
industrielle (Ericsson). UML est un langage visuel dédié à la spécification, la construction et
la documentation des artefacts d’un system. L’UML peut être appliqué de trois manières
différentes, à savoir :
• UML en mode esquisse : Diagrammes informels et incomplets, souvent tracés à la main, utilisés
pour décrire une problématique ou des solutions en exploitant la puissance des langages
graphique.
• UML en mode plan : Diagrammes de conception relativement détaillés utile pour la pro-
ingénierie ou la retro- ingénierie.
• UML comme langage de programmation : Permet de générer un code exécutable directement à
partir langage UML.
Une classification courante distingue les diagrammes qui traduisent la structure et les
diagrammes qui présentent le comportement du système étudié, à savoir :
• Diagrammes de structure : o Diagrammes de classes,
o Diagrammes d’objets,
o Diagrammes de paquetage,
o Diagrammes de structure composite,
o Diagrammes de composants,
o Diagrammes de déploiement.
• Diagrammes de comportement : o Diagrammes d’activités.
o Diagrammes d’états transitions,
o Diagrammes de communication,
o Diagrammes de séquence,
o Diagrammes d’ensemble des interactions,
o Diagrammes des cas d’utilisation,
o Diagrammes de timing.
III.2.5 CHOIX DE L’ARCHITECTURE
La solution préconisée serait de concevoir un système réparti, c’est-à-dire un système
dont les ressources ne sont pas centralisées. Le but étant de permettre à des utilisateurs de
manipuler, leurs données sans contraintes sur les localisations respectives des éléments. Par
ailleurs, ce type de système permet au concepteur de diviser les problématiques.
103
Dans ce qui suit, nous présentons les différentes architectures existantes, et positionnons notre
choix quant à l’architecture qui sied à notre organisme.
Architecture à 2 niveaux : III.2.5.1
Figure 11-Architecture client/serveur
Les systèmes client/serveur se basent sur une architecture à 2 niveaux, dont le principe est de
séparer la partie des données de la partie de présentation/logique comme indiqué dans la
Figure I.8. [MARTY, 2000]
Dans une architecture à 2 niveaux, la charge du traitement est attribuée au poste client, tandis
que la charge du contrôle du trafic entre l’application et la base de données est attribuée au
serveur.
Pour simplifier, on peut dire que, dans ce type d'architecture, les traitements sont sur le poste
client et la base de données est sur le serveur. Survient alors un problème de taille c’est celui
de la maintenance. La moindre modification nous obligera à mettre à niveau chaque poste
client. De plus les performances de l'application sont pour beaucoup en fonction des
ressources des clients.
En effet, les performances de l’application sont en fonction de l’infrastructure matérielle mis
en place. Souvent, des problèmes de lenteur, lourdeur et de fluidité du trafic peuvent surgir,
qui n’est pas chose aisée à résoudre. Devant cet état de fait, et afin de pallier aux différents
problèmes suscités, l’architecture trois niveaux (trois tiers) a vu le jour.
base de donnée
CLIENT 2réseauréseau_
serveur d'appl ication
CLIENT 1
104
Architecture à 3 niveaux : III.2.5.2
La Figure suivante montre ainsi qu’une application est divisée en trois niveaux logiques :
Figure 12-Architecture à trois niveaux
• Niveau présentation : Constitué d’une interface utilisateur graphique (GUI).
• Niveau intermédiaire (logique applicative) : C’est le code appelé par l’utilisateur
afin d’extraire les données nécessaires.
• Niveau données : Contient les données utiles à l’application (serveur de base de
données, documents XML, serveur LDAP...).
Le niveau métier contient le code appelé (via le niveau présentation) par l'utilisateur pour
extraire et traiter les données de la troisième couche. Cette séparation en couches améliore la
souplesse de l'application. Il devient facile de déployer de nombreuses interfaces utilisateur
sans devoir modifier la logique applicative. [MARTY, 2000]
Architecture multi niveaux III.2.5.3
La subdivision d’une application peut nous amener à une architecture multi niveaux qui se
définit comme suit :
clientServeur d'application Serveur de donnée
logique appl icative
105
Figure 13-Architecture multi niveaux
• Interface utilisateur : Chargée de gérer les interactions entre l’utilisateur et
l’application ; il peut s’agir d’un navigateur Web s’exécutant à travers un pare-feu,
d’une application de bureau plus puissante ou encore d’un mobile WAP.
• Logique de présentation : Permettant de définir ce que doit afficher l’interface
utilisateur et la manière dont les requêtes de l’utilisateur seront traitées ;
• Logique métier : Qui modélise les règles métier de l’application, souvent via
l’interaction avec les données de l’application ;
• Services d’infrastructure : Qui fournissent des fonctionnalités supplémentaires
nécessaires aux composants de l’application, tels qu’un service de messagerie, de
support transactionnel, … etc ;
• Niveau données : Hébergeant les données de l’entreprise.
clientServeur d'application Serveur de donnée
logique applicative
logique metier Services
106
III.2.6 ARCHITECTURE GLOBALE DU SYSTEME
L’architecture du système d’information intégré permet une transparence dans l’accès
aux bases de données, c’est à dire que l’utilisateur peut interroger plusieurs bases de données
hétérogènes, à travers les SGBDs (Oracle, SQLServer), sans gêne. Ces bases de données sont
réparties dans un réseau à architecture n-tiers. La figure suivante illustre l’architecture
globale du système.
Figure 14-Architecture du system (SICLOG)
107
III.3 CHAPITRE3: CHOIX ET PRESENTATION DES TECHNOLOGIES
UTILISEES
Chapitre 3 :
Choix et présentation des
technologies utilisées
108
III.3.1 PLATE-FORME J2EE
Introduction III.3.1.1
Avant l’arrivée de J2EE, l’informatique distribuée recouvrait principalement la
programmation client/serveur. Le chemin était tout tracé ; il y avait d’abord l’écriture d’une
application serveur mettant en œuvre une interface, une application cliente se connectant au
serveur et puis le démarrage à la fois du serveur et du client. Cette méthode semble fort
simple, mais elle dissimule en réalité de nombreux obstacles, selon la technologie mise en
œuvre.
Considérons maintenant que les serveurs et clients demandent l’accès à des services
tels que les transactions distribuées, la messagerie, etc. pour pouvoir utiliser ces services, il
faudrait ajouter une quantité importante de code aux applications, et peut-être également à
mettre en œuvre et à configurer différentes solutions middleware ou encore à effectuer des
appels aux API spécifiques d’un vendeur afin de pouvoir accéder à ces services. Mis à part les
services concernant l’accès à des bases de données, la plupart d’entre eux sont propriétaires
ou non standard. En conséquence, ces applications deviendront plus complexe plus lentes et
plus coûteuses en termes de développement, de gestion et de maintenance.
Ces exigences côté serveur se retrouvant dans de nombreuses applications, il est
opportun de considérer une plate-forme dotée de solutions intégrées. Ceci permet de faire
nettement la distinction entre ces aspects d’infrastructure et la préoccupation plus immédiate
de transformer les exigences applicatives en un logiciel qui fonctionne. L’environnement
d’exécution J2EE résout ces difficultés. C’est le vendeur du serveur J2EE qui se charge de
mettre en œuvre ces fonctionnalités pour l’utilisateur dans le respect des standards.
C’est quoi J2EE ? III.3.1.2
J2EE signifie Java Entreprise Edition et repose donc sur Java, langage objet conçu pour être
"portable". Une caractéristique qui passe notamment par l'utilisation d'un module client
(baptisé machine virtuelle) pour assurer l'exécution des programmes sur n'importe quel type
de serveurs et de systèmes d'exploitation... pour peu que ces derniers supportent l'outil en
question. D'où le slogan lancé par la firme de Palo Alt : "Write Once, Run Anywhere"
(développez une fois, exécutez partout).
Nous distinguons, dans ce qui suit, les principaux atouts de ce langage :
• Il ne dépend d'aucune plate-forme ;
• Il est sécurisé ;
• Il s'agit d'un langage 100 % orienté objet ;
109
• Il est évolutif ;
• ll est relativement simple à assimiler (comparé au C++).
Description technique de J2EE : III.3.1.3
La spécification J2EE définit la notion de conteneur, qui est un environnement
d'exécution chargé de gérer des composants applicatifs et leur donner accès aux API
(application programming interface) J2EE.
Figure 15-Architecture J2EE
Deux types de conteneurs sont visibles dans cette architecture :
III.3.1.3.1 Conteneur web
Le conteneur web est utilisé pour héberger les services Java et les pages JSP, et dispose de :
• Servlets
La spécification Servlet définit un modèle de composants côté serveur qui peut être
implémenté par les fournisseurs de serveurs web. Les servlets offrent une API simple mais
puissante pour générer dynamiquement des pages web. Même si les servlets peuvent être
utilisées avec différents protocoles de type demande-réponse, elles servent principalement à
traiter des requêtes HTTP.
110
• Java Server Pages
Les Java Server Pages (JSP) sont une extension du modèle de composants des servlets qui
simplifient la génération dynamique de code HTML. Les JSP permettent principalement
d’inclure directement du Java dans une page HTML. Dans J2EE, le code Java d’une page JSP
peut accéder à l’Environment Naming Context de JNDI (Java Naming and Directory
Interface), tout comme le code Java d’une servlet. En fait, les pages JSP (des documents
texte) sont converties et compilées en des servlets Java, puis sont ensuite exécutés sur un
serveur web comme n’importe quelle autre servlet. Les JSP peuvent aussi servir à générer
dynamiquement des documents XML (eXchange Markup Language).
JSP ressemble beaucoup à ASP.NET de Microsoft. Il offre un système d'assemblage de
pages puissant et dynamique, qui exploite les nombreux avantages de la plate-forme Java.
La technologie Java Server Pages (JSP) permet d’embarquer des composants dans une
page et de laisser ces derniers générer la page qui sera finalement renvoyée au client. Une
page JSP peut contenir du code HTML, du code Java et des composants JavaBean. Lorsque la
servlet a été compilée à partir de la page JSP, le serveur Web se contente de renvoyer la
servlet sans avoir à repasser systématiquement par l’étape de compilation.
La séparation devient alors plus claire entre les logiques applicatives et de présentation.
Ainsi, les développeurs d’application peuvent se concentrer sur les aspects métier et les
concepteurs Web, sur la présentation.
III.3.1.3.2 CONTENEUR EJB
Il est utilisé pour héberger les composants Entreprise JavaBean, et comprend :
• Composants EJB (Entreprise JavaBeans)
L’architecture EJB est un modèle de composants distribués permettant de développer
des composants sûrs, évolutifs, transactionnels et multi utilisateurs. En clair, il s’agit d’unités
logicielles réutilisables contenant une logique métier. À instar de JSP qui permet de séparer la
logique applicative de la logique de présentation, les EJB permettant de séparer la logique
applicative des services de niveau système, ce qui laisse au programmeur le loisir de se
connecter d’avantage sur les aspects métier que sur la programmation système.
Il existe deux sortes d’objets métier EJB: les beans entité et les beans de session.
111
o Beans de session
Il existe deux formes de beans de session, ceux qui possèdent un état (standard)
et ceux qui n’en possèdent pas. Un beans session qui possède un état est un objet
transitoire permettant de représenter l’interaction d’un client avec le système : le
beans de session exécute les requêtes clientes au sein de l’application, en accédant à
la base de données, etc.., et, lorsque les opérations clientes sont effectuées, il est
détruit (c’est-à-dire que sa durée de vie est celle de la session cliente). Un bon
exemple de cette procédure est un panier d’achats en ligne. A l’inverse, un beans de
session sans état ne conserve pas d’état entre les requêtes clientes. En général, ce
type de beans de session permet de mettre en œuvre un service spécifique ne
nécessitant pas d’état client, par exemple, une simple mise à jour d’une base de
données.
o Beans entité
Un beans entité, à l’inverse, est un persistant qui modélise les données à
l’intérieur de l’entrepôt de données, c’est-à-dire qu’il encapsule les données dans un
objet. Par rapport aux beans de session qui peuvent être utilisés par n’importe quel
client, les beans entité peuvent être employés en même temps par plusieurs clients,
mais ils doivent conserver une identité unique via une clé primaire. En réalité, avec
l’architecture de conteneurs J2EE, vous pouvez choisir soit de laisser le conteneur
gérer l’état persistant du beans entité pour vous, soit de mettre en œuvre vous-même
cet état à l’intérieur du beans. [MONSON-HAEFEL, 2000]
III.3.2 LES SERVICES DE J2EE :
La spécification de la plateforme J2EE prévoit un ensemble Java standard :
• Authentification : J2EE fournit des services d'authentification en se basant sur les
concepts d'utilisateur, de domaines et de groupes.
• JDBC : Java Database Connectivity est une API qui permet aux programmes Java
d’interagir avec les bases de données Oracle 10 g ou autre.
• JMS : Java Messaging Service est à la fois une ossature et une API permettant aux
développeurs de construire des applications professionnelles qui se servent de
messages pour transmettre des données.
• Le protocole standard Remote Method Invocation over the Internet Inter-ORB
(RMI-IIOP ou RMI sur IOP) 1.0 : ce protocole permet la mise en œuvre de l’API
112
RMI Java classique sur IIOP. En outre, il permet aux applications RMI et COBRA
de se rejoindre ;
• JavaMAil : Cette API fournit un cadre indépendant des plates-formes et des
protocoles dans le but de concevoir des applications de courrier électronique basées
sur Java.
III.3.3 CLIENTS
Etant donné qu’il y a deux types de conteneurs on peut leur attribuer deux types de
clients :
Clients Légers III.3.3.1
S’exécutent normalement au sein des navigateurs web. Pour ces clients, l’interface
utilisateur est générée côté serveur, par exemple en HTML ou en XML, elle est ensuite
téléchargée, puis restituée par les navigateurs. Ces clients utilisent HTTP pour communiquer
avec les conteneurs web et ceci en envoyant des requêtes. Les composants applicatifs (servlets
et JSP) mettent en œuvre les fonctionnalités requises pour les clients web afin de générer des
réponses .
Clients lourds III.3.3.2
Les clients lourds sont des applications ayant accès aux composants EJB au sein des
conteneurs EJB. Il existe deux types possibles de clients EJB :
• La première catégorie recouvre les applications clientes. Il s’agit d’applications
autonomes ayant accès aux composants EJB au moyen du protocole RMI-IIOP.
• La seconde catégorie inclut les composants se trouvant à l’intérieur du conteneur web.
Donc, les servlets Java et les pages JSP peuvent accéder aux composants EJB via le
protocole RMI-IIOP, à l’instar des applications clientes.
Pour résumer, on peut dire que les clients peuvent accéder aux composants applicatifs
via le conteneur respectif. Les clients web ont accès aux pages JSP et au servlets Java via le
conteneur web, et les clients EJB accèdent aux composants EJB via le conteneur EJB.
113
III.3.4 LES DESIGN PATTERN
Définition III.3.4.1
Plusieurs définitions nous aideront à comprendre ce concept :
« En génie informatique, un motif de conception (Design pattern en anglais) est un
concept issu de la programmation orientée objet, destiné à résoudre les problèmes récurrents »
« Solution récurrente décrivant et résolvant un problème général dans un contexte
particulier ».
« Une solution de conception commune à un problème | récurrent dans un contexte
donné ».
«…, un Design Pattern décrit un problème récurrent dans un environnement donné
puis décrit une solution à ce problème de telle manière que cette solution soit réutilisable à
chaque fois qu'on rencontre le problème sans cependant qu'elle soit deux fois exactement la
même. »
Le principal intérêt des patterns est de permettre la manipulation d'artefacts plus
élaborés que les objets et les classes. Ils accroissent la force d'expression des langages de
modélisation. Le concepteur d'un pattern propose une solution générique pour un problème,
plutôt de détail, qui est souvent rencontré dans divers développements. Cette solution est
présentée sous une forme indépendante d'un langage de programmation particulier »
L'usage des design patterns apporte donc évolutivité, lisibilité et efficacité aux
développements. C'est pourquoi leur emploi améliore sensiblement le respect des
prescriptions d'architecture [Bushmann 96]. Par ailleurs, ils offrent un transfert de compétence
rapide en conception orientée objet, dans la mesure où ils représentent pour les débutants un
catalogue des meilleures pratiques à adopter.
Un design pattern est généralement formé de quatre parties essentielles, à savoir :
• Le nom du pattern, point d'accroché qui permettra de facilement retrouver le problème et
sa solution. Ce nom doit donc être choisi avec soin.
• Le problème lui-même, qui décrit le plus synthétiquement possible le contexte dans
lequel s'applique ce design pattern.
• La solution, qui décrit l'ensemble des éléments en jeu, leurs relations et leurs
responsabilités. La solution est exprimée d'une façon générique et ne repose sur aucun cas
concret pour être facilement transposable. La solution doit être abstraite pour mieux être
concrétisée, un peu comme une classe abstraite permet de créer par héritages des classes
concrètes.
114
• Les conséquences qu'entraîné l'application de la solution. En matière de développement,
cela peut concerner la mémoire utilisée, le temps de calcul, les contraintes particulières
que le langage choisi, pour mettre en œuvre la solution, doit pouvoir respecter.
Les deux points centraux (description du problème traité et solution apportée)
justifient en général l'utilisation d’UML pour illustrer le propos et le rendre plus universel.
Les diagrammes les plus souvent utilisés en la matière sont les cas d'utilisation, les
diagrammes de classes, les diagrammes de séquences et de collaboration ainsi que les
diagrammes d'états de transitions.
Les design patterns sont l'antithèse de la réinvention de la roue. Et comme finalement
le monde est partout le même, et que les problèmes proviennent souvent de causes similaires,
de situations « classiques », il est raisonnable de vouloir réutiliser les solutions qui ont fait
leurs preuves face à des problèmes finalement identiques ou proches dans leur nature.
C'est ce que permet de faire les design patterns, lorsqu'elles sont appliquées au
développement. Elles permettent à la fois de gagner du temps et de s'assurer qu'on utilise une
« bonne » solution qui ne causera pas ultérieurement plus de problèmes qu'elle n'en réglait.
La Programmation Orientée Objet a introduit la notion de réutilisation du code en
créant des acteurs autonomes que sont les objets, les design patterns inventent la réutilisation
des idées. Après avoir résolu un problème original on peut généraliser cette solution en créant
un design pattern.
Exemple de design Patterns : III.3.4.2
• Le design pattern « singleton »
Le « singleton» est l'une des techniques les plus utilisées en conception orientée
objet. Il permet de référencer l'instance d'une classe devant être unique par construction.
Certains objets techniques prennent en effet une responsabilité particulière dans la gestion
logique d'une application. C'est par exemple le cas d'objets comme le « contrôleur des
objets chargés en mémoire » ou le « superviseur des vues », qui sont les seuls et uniques
représentants de leur classe. Ces objets sont le plus souvent publiquement accessibles. De
tels cas de figure sont fréquents en conception, le singleton est requis pour les concevoir.
« Le singleton permet de s'assurer qu'une seule instance d'une classe sera
instanciée pendant toute la durée d’exécution d’une application ».
115
III.3.5 REPLICATION ET REPARTITION AVEC ORACLE STREAMS
Introduction III.3.5.1
Dès la version Oracle 9i, Oracle a totalement réécrit sa réplication en donnant ainsi
naissance à « Oracle Streams », constituant ainsi une nouvelle méthode de partage de
données, qui prend en considération les modifications de type DDL (Data Definition
Language) et DML (Data Manupaltion Language) apportées aux tables des bases concernées.
Par le passé, les systèmes de réplication qu’offrait Oracle n'ont jamais fait l’unanimité.
Basés sur des Snapshots de tables, peu performants. Ils ont souvent été ignorés au profit
d'autres systèmes de réplication hétérogènes d'autres éditeurs, et c’est de cette manière
qu’Oracle a décidé de palier à cette défection.
Réplication avec Oracle III.3.5.2
Apparu dès la version Oracle 9i, la répartition (réplication) d’informations dans
plusieurs bases de données ne va pas sans poser des problèmes techniques. Pour les résoudre
et assurer une cohérence entre des données synchronisées, la réplication intègre l’ensemble
des techniques à mettre en œuvre.
Oracle 9i ainsi qu’Oracle10g sous Windows permet une synchronisation aisée des
données entre plusieurs bases situées sous Windows ou sous d’autres systèmes d’exploitation.
Utiliser ces versions d’Oracle apporte la garantie de ne pas rester « isolé » et de disposer d’un
système d’informations ouvert et communicant.
Figure 16-Principe de la réplication de données
116
Une réplication réussie consiste à configurer correctement l'ensemble des étapes
nécessaires, des objets répliqués et des processus de propagation et de purge des transactions.
Figure 17-Préparation de la réplication dans Oracle
• L’administrateur de réplication
L'administrateur de réplication, appelé plus communément administrateur de flux de
données, est un utilisateur créé sur chaque base de données participant à la réplication. Il a
pour rôle de gérer l'environnement de réplication. Pour cela, il doit disposer des privilèges
nécessaires. [MEYLAN, 2003]
• Groupe de réplication
Dans un environnement de réplication, Oracle gère les objets répliqués en utilisant les
groupes de réplication. Un groupe est une collection d'objets répliqués logiquement reliés
entre eux. En organisant des objets de la base de données apparentés dans un groupe, il
devient plus facile d'administrer simultanément une multitude d'objets.
Un groupe ne correspond pas forcément à un schéma. Un groupe peut contenir des
objets provenant de plusieurs schémas et les objets d’un schéma peuvent appartenir à
plusieurs groupes de réplication. La seule restriction réside dans le fait qu'un objet ne peut
appartenir qu'à un et un seul groupe de réplication.
117
La réplication dans Oracle est un processus très puissant. Oracle permet la réplication
des objets suivants :
• Tables
• Indexe
• Vues
• Packages et corps de Package
• Procédures et Fonctions
• Types définis par l'utilisateur et corps de types
• Déclencheurs
• Synonymes.
Définition Oracle streams III.3.5.3
Oracle Streams est un outil chargé de capturer les changements de la base source (la base sur
laquelle les changements ont été effectués), les propager et les appliquer aux bases
destinations. C’est une nouvelle méthode de partage de données, qui prend en considération
les modifications de type DDL et DML apportées aux tables des bases concernées.
Lors de l’utilisation des Streams, les changements DDL et DML incluent précisément trois étapes :
• Le processus de capture
• Le processus de propagation
Figure 18-Concept du groupe de réplication dans Oracle
118
• Le processus d’application
Ces derniers se succèdent à travers un cheminement partant de la base de données
source vers la base de données destination. Oracle Streams commence par capturer les
changements (données, tables, schémas…etc.) effectués dans une base de données, qui seront
enregistrés dans les fichiers « redo log » de la base de données. Ensuite, il les extrait des
fichiers « redo log » et formate chaque changement en un LCR (Logical Change Record). Les
LCR sont alors stockés dans une file d'attente Après, Streams propage les LCRs d'une file
d'attente (la file d'attente de la base source) à une autre (la file d'attente de la base destination)
et peuvent alors appliquer les LCRs à la base de données destination à partir de sa file
d'attente.
En plus de la réplication de données, les Streams peuvent être employés pour
l’accomplissement des tâches suivantes :
• Extraction et chargement d'entrepôt de données
• Avis d'évènement
• Migration de plateforme de base de données
• Évolution de base de données et d'application
En utilisant Oracle Streams, les entreprises peuvent saisir, propager et appliquer
l’information comme suit :
• Dans une base de données Oracle
• Entre deux bases de données Oracle
• Parmi de multiples bases de données Oracle
• Entre une base de données Oracle et une autre non Oracle
Figure 19-Les processus d’Oracle Streams
119
III.3.5.3.1 Processus de capture
Un processus de capture est un processus d'arrière-plan Oracle qui analyse le fichier de
journalisation de la base de données pour capturer les modifications de type DML et DDL
apportées aux objets de base de données. Il formate ces modifications dans des évènements
appelés enregistrements logiques de modification (LCR) et les met en file d'attente
Figure 20-Processus de capture
120
III.3.5.3.2 Processus de propagation
Un processus de propagation envoie les évènements d'une file d'attente source vers une
file d’attente destination, ces files se trouvent dans la même base de données ou dans deux
bases différentes.
Une seule file d'attente source peut propager des évènements à plusieurs files d'attente
destination, et une file d'attente destination peut recevoir des évènements de plusieurs files
d'attentes sources. Cependant, une seule propagation peut avoir lieu entre une file d'attente
source et une file d'attente destination.
Figure 22-Propagations autorisées et non autorisées entre files d’attente
Figure 21-Processus de propagation
121
III.3.5.3.3 Processus d’application
Un processus d'application des transactions est un processus d'arrière-plan Oracle qui
retire des évènements d'une file d'attente et applique directement chaque évènement à un objet
de base de données destination.
Figure 23- Processus d’application
III.3.6 ORACLE TRANSPARENT GATEWAYS
Oracle transparent Gateway permettent d’accéder aux données transparentes résidant
dans un system non-oracle à partir d’un environnement Oracle. Cette transparence élimine le
besoin pour les développeurs d’application de personnaliser leurs applications pour accéder à
des données provenant de différents systèmes, ce qui réduit les efforts de développement et
d’amélioration de la mobilité de la demande Oracle. Cette technologie est constituée de deux
composants :
• Services hétérogènes (Heterogeneous Services) : permet de :
Traduction SQL Oracle vers SQL non Oracle
Traduction de dictionnaire de données
Exécution de procédures stockées
Base Base Heterogeneous
Services
Tansparent
Gateway
Figure 24-oracle transparent gateway
122
• Transparent Gateway
Fournit aux services hétérogènes les informations nécessaires à la traduction :
ü Traduction des types de données
ü Assure la connexion à des systèmes non-Oracle
123
III.4 CHAPITRE 4 : DEVELOPPEMENT DU SYSTEME « SICLOG »
Chapitre 4 :
Développement du Système
« SICLOG »
124
III.4.1 PHASE : INCEPTION
Dans le cadre d’une approche itérative et incrémentale à travers la méthode UP nous allons
poursuivre la réalisation de notre système à travers les quatre phases du processus unifié.
Déroulement de la phase III.4.1.1
Lors de la phase inception, un atelier d’expression des besoins est organisé, regroupant le
client, l’architecte système, l’utilisateur final, l’analyste et le développeur. Le groupe est
animé par l’analyste qui est responsable de la définition des besoins.
Cet atelier nous permet de cerner les besoins et les attentes des clients. À travers ce projet,
ainsi tous les cas d’utilisations, les différentes fonctionnalités et les principaux besoins non
fonctionnels doivent être identifiées.
Vision et étude de faisabilité III.4.1.2
Le but est de décrire les objectifs et les contraintes de haut niveau ainsi qu’une étude
d’opportunité.
• Description des objectifs et des contraintes de haut niveau :
Le but de notre travail est de réaliser un système d’information global, au profit de notre
organisme. Ce système, décomposé en sous-systèmes selon leur fonctionnalité, doit prendre
en charge l’ensemble des fonctions relatives aux structures suivantes :
• La Fonction Emmagasinage;
• La Fonction Approvisionnement et réapprovisionnement ;
• La Fonction Transport (routier et fret,…) ;
• La Fonction Maintenance technique;
• La Fonction opérationnelle ;
• La Fonction Ressources humaine ;
• La fonction Administrative.
Conception et développement du SI
Le système gestion des stocks devra permettre à la chaîne technique un soutien continu et
indéfectible pour le maintien en condition des équipements en exploitation. Le système en
question doit donc répondre aux exigences de la chaîne technique en pourvoyant les magasins
sectoriels mais aussi les magasins unités en pièces et matériels de rechanges.
Le système gestion des stocks comprend six modules :
• Catalogue et gestion des contrats fournisseurs ;
125
• Réception et contrôle : planification de mission d’acheminement des nouvelles acquisitions,
détermination des moyens et itinéraires de transport, exécution des procédures administratives
y afférentes;
• Entrées/contrôle : nouvelles acquisitions, entrée pour réparation, retour de distribution, retour
de prêt ;
• Sorties/contrôle : équipements neufs, sortie pour réparation, sortie pour prêt ;
• Prévisions et statistiques ;
• Un tableau de bord est mis à la disposition de la Direction pour une meilleure prise de décision
et afin d’évaluer les performances de cette entreprise.
Le système Technique permet la remise en état et le maintien en condition des équipements
servant à l’activité de l’organisation. Chaque équipement, possédant un dossier administratif
constitué d’un journal d’évènements, d’une carte technologique et d’une pièce d’identité, se
voit subir un contrôle drastique en matière de maintenance calendaire et/ou systématique. La
disponibilité de la pièce de rechange est nécessaire à l’activité de cette structure, d’où
l’existence d’un magasin sur site, relié par réseau au magasin central. Ce système
d’information informatisé comprend les modules suivants :
1. Planification et contrôle ;
2. Approvisionnements ;
3. Maintenance et rénovation ;
4. Energie et moyens de servitudes nécessaires à l’activité ;
5. Prévisions et statistiques.
6. Tableau de bord servant le directeur pour analyser les performances de la chaîne technique.
Ces deux systèmes cohabitant dans une même plate-forme, utilisent un même catalogue, situé
au niveau central, pour garantir la communication, la fiabilité et la cohérence des informations
échangées. Le flux informationnel est dématérialisé grâce à un système de Gestion
Electronique de Documents « GED », conçu conformément à la réglementation régissant
l’organisation et disposant de toutes les fonctionnalités des GED du marché. Ce système GED
comprend aussi une ouverture sur le système de travail collaboratif Lotus Notes, à travers
lequel, les utilisateurs peuvent s’échanger des courriers. Il a été conçu selon l’architecture
Client/Serveur, où chaque station se voit attribuer une licence d’exploitation, afin d’éviter la
fraude, et comprend un module de cryptage des documents stockés sur une base de données
Oracle 10g.
126
Il est important de signaler, qu’un système workflow sera développé pour la chaîne technique
permettant à tous les acteurs, de cette structure, d’intervenir sur ce plan en créant ou en
modifiant des informations selon un ordre chronologique tout en respectant le niveau de
responsabilité de tout un chacun et selon la hiérarchie imposée.
Aussi, dans le cas de rupture impromptue de pièces de rechange, l’utilisation d’un système
multi-agents à médiation est plus que nécessaire. En effet, il s’agira de lancer une requête de
demande d’information sur la satisfaction de la demande à tous les agents, positionnés aux
niveaux des sites sectoriels. Ces agents vont interroger leurs bases de données respectives et
transmettront leurs réponses au médiateur qui se trouve au niveau central. Dans le cas où les
réponses sont négatives, le médiateur propose les fournisseurs susceptibles de fournir les
pièces demandées, en prenant en considération le degré de satisfaction des fournisseurs en se
rapportant sur l’historique Fournisseurs. Dans le cas contraire, c’est-à-dire, au moins une
réponse est favorable, un processus déterminant les moyens les plus appropriés pour
l’acheminement de cette pièce de rechange est établi. L’ordre de mouvement est élaboré
automatiquement et les mises à jour des bases de données concernées sont faites
instantanément. L’utilisation de la signature électronique permettra à ces systèmes de
fonctionner plus efficacement.
Enfin, dans nos perspectives une fois que la masse informationnelle sera assez consistante et
volumineuse, nous souhaiterions réaliser des entrepôts de données « data-warehouse » au
niveau sectoriel et utiliserions le concept de datamining pour la recherche des connaissances.
III.4.1.2.1 Délimitation du périmètre d’étude
Le projet sera réalisé pour les structures organiques. Il doit prendre en charge la gestion de la
logistique ; le stockage, l’approvisionnement, la maintenance, la production et la gestion des
ressources humaines.
• Identification des Acteur et de leurs besoins
Cette étape permet d’identifier les utilisateurs du futur système, et les principales
fonctionnalités attendues.
Le diagramme de contexte dynamique permet l’identification des différents acteurs, et leurs
interactions avec le système. Ce dernier est représenté sous forme de boite noire entourée
d’acteurs qui émettent des messages qui peuvent être interprété comme des buts ou des
fonctionnalités souhaitées par les utilisateurs du système. Elles sont recensées par la suite
dans la liste des fonctionnalités.
127
Figure 25-Diagramme de Contexte Dynamique SICLOG
III.4.1.2.2 Liste de fonctionnalités
Une liste des fonctionnalités est établie en vue de recenser les besoins des utilisateus.
III.4.1.2.3 Spécifications supplémentaires
Les besoins techniques ou non fonctionnels font parties des spécifications supplémentaires, le
diagramme de contexte statique permet la quantification des occurrences ainsi des choix
techniques peuvent être décidé.
Chef Service Planification Chef Service Chef Service Appro
administrateur système Admistrateur strems
Chef Service Mécanicien Utilisateur
SICLO
128
Figure 26-Diagramme de Contexte Statique SICLOG
III.4.1.2.4 Contrainte et sécurité
La prospection et l’utilisation des nouvelles technologies et fortement recommandé
notamment en matière d’acquisition et de traitement des données, afin d’apporter un
maximum de performances, de facilités d’utilisation aux utilisateurs d’une part et d’autre part
l’utilisation de nouvelles méthodes en matière de conception d’implémentation et de
développement.
• La solution doit prendre en considération la possibilité d’évolution vers d’autres
métiers.
• La qualité est de rigueur, l’aspect temps d’accès performances et tolérance de panne
doit être prise en charge.
• L’intégration avec d’autres applications externes est fortement recommandée dans la
mesure du possible, sinon des schémas intermédiaires devraient être réalisés dans
l’attente d’une intégration totale.
La sécurité est un aspect essentiel et doit être pris en considération, pendant tout le
processus de développement et de déploiement de la solution. Du coté serveur, les ports
réseaux non utilisés doivent impérativement être bloqués. Du coté client l’application doit être
Chef Service Matériels
Mécanicien Utilisateur
Chef Service Planification
Chef Service Maintenance
Chef Service Appro
administrateur système Admistrateur strems SICLOG
1..1
1..1 1..1
1..N
1..N 1..N
1..4
1..1
129
en mesure d’éviter un certain nombre d’attaque telles que l’attaque par débordement de
mémoire tampon ou par injection SQL.
Lors de l’exploitation, l’administrateur sera chargé de la gestion des utilisateurs des privilèges
qui leurs sont associés et doit analyser les journaux et prendre les mesures nécessaires pour le
bon fonctionnement de système.
III.4.2 PHASE : ELABORATION
Introduction III.4.2.1
Dans cette phase nous allons analyser en détail les différents métiers qui se réfèrent au
système.
Nous commencerons par des diagrammes de cas d’utilisation qui permettent de capter les
besoins des utilisateurs, par la suite l’esquisse de diagrammes de séquences ou de
collaboration « renommé en diagramme de communication dans UML2 » pour analyser
l’aspect dynamique du système, pour aboutir à une identification des objets et classe
candidates qui serviront à réaliser un diagramme de classe pour chaque sous métier de
système. Enfin, la fusion des solutions obtenues aboutira à un schéma complet et intégré qui
va être la base pour la construction du système future.
Cas d’utilisation III.4.2.2
Les diagrammes de cas d’utilisation représentent les cas d’utilisation, les acteurs et les
relations entre les cas d’utilisation et les acteurs. Un cas d’utilisation est une manière d’écrire
comment utiliser le système. C’est l’image d’une fonctionnalité du système, déclenchée par
un acteur.
130
III.4.2.2.1 Paquetage Maintenance 1
Figure 27-paquetage Maintenance 1
systeme de gestion de la maintenance
<<include>>
<<include>>
<<extend>>
<<include>>
<<extend>>
pannes de 4 éme échelon
Gestion de Lubrifiant
Gestion de carburant
service carburant et lubrifiant
service des équipements spécique
Gestion des équipements
spécifiques
service du matériel roulantGérer le matériel roulant
suivi
maintenance
Fournisseurfournir produit
établissement de réparation
Réparer matériel roulant
direction générale
établir ordre d'attribution matériel
intervenir
suite à une demande de la direction générale
131
III.4.2.2.2 Paquetage Maintenance2 :
Figure 28-paquetage Maintenance 2
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
systeme de gestion de la maintenance
service de planification
programmer Maintenance
contrôler
plannifier
Consulte documentation ou BDD
service d'approvisionement Gestion des stocks
Entrées
Sorties
Réparation et reversement
Exécution Maintenance
service de maintenance
zone d'activi té
établi r DM
établ issement de stockage
Fournir Materiel
recevoir materiel
Demande Materiel
Mise à jour documentation
132
III.4.2.2.3 Paquetage gestion de stock :
Figure 29-paquetage gestion de stock
service contrat
Système de gestion des stocks
avec un bon de reversement
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<extend>>
<<extend>>
<<extend>>
fournisseur
établissement de stockage
Marché accuisition
Marché réparation
Fournir produi ts
Sortie matériel
Réparation
établi r ordre d'attribution matériel
structures
reversement matériel
instance reforme
pour réparation
pour erreur distributionstocker
recevoir materiel
apres contrôle
Réaliser Marché
133
III.4.2.2.4 Description des cas d’utilisations :
Demande matériel
Description sommaire Titre Demande Matériel
But Décrit la demande des pièces de rechange utilisé pour la
Acteurs Service de maintenance
Description des enchainements
Pré-condition La maintenance est déjà planifiée
Enchainements 1. La maintenance de l’équipement est planifiée. 2. Le service de maintenance demande le matériel requis
pour la maintenance auprès du service d’approvisionnement.
Postes-conditions Les travaux de maintenance seront exécutés lorsque le service de planification établit le programme final de révision.
Contrôle des équipements :
Description sommaire
Titre Contrôle et suivi des équipements
But Permet le suivi de l’état de l’équipement et de
Acteurs Service de planification
Description des enchainements
Pré-condition La zone d’activité établie DM
Enchainements 1. Contrôle et mise à jour des documents à travers la DM 2. Mise à jour des documents spécifiques des équipements.
Postes-conditions • Butée atteinte : 1. Déclanchement du DM et du document spécifique de
l’équipement pour le service de maintenance. 2. Matériel indisponible
• Butée non atteinte : Classification de la documentation.
134
Processus des travaux :
Description sommaire
Titre Exécution de la maintenance
But Description de la manière avec laquelle s’effectuent les travaux
Acteurs Service de maintenance
Description des enchainements
Pré-condition Réception du DT et documents spécifiques des équipements
Enchainements 1. Préparation des travaux. 2. Distribution des taches aux ateliers. 3. Sortie du matériel. 4. Exécution des travaux.
Postes-conditions Réponse au service de planification dans les CE
Sortie matériel
Description sommaire
Titre Sortie matériel
But Description du processus de sortie du matériel destiné à
Acteurs Etablissement de stockage
Description des enchainements
Pré-condition Réception du bon de commande (BC) ou un ordre de d’attribution matériel(OA).
Enchainements 1. Réception et enregistrement d’OA ou BC. 2. Mise à jour des documents.
Postes-conditions Sortie matériel.
Diagrammes de séquence III.4.2.3
Les diagrammes de séquence nous permettent de montrer les interactions entre objets, ils nous
permettent de bien schématiser les scénarios des cas d’utilisation. La représentation se
concentre sur la séquence des interactions selon un point de vue temporel. Ils sont en général,
135
plus aptes à modéliser les aspects dynamiques des systèmes temps réel et des scénarios
complexes mettant en œuvre peu d’objets. [44]
Une interaction modélise un comportement dynamique entre objets. Elle se traduit par l’envoi
de message entre objets. Un diagramme de séquence représente une interaction entre objet, en
insistant sur la chronologie des envois de message. [44]
III.4.2.3.1 Reversement
Figure 30-reversement
reversement
avis de réparation : fin de réparation
avis de fin de reception : erreur de distribution
vérifier catégorie [reforme| réparation | erreur distribution]
reversement matériel
établissement de stockage
structures
avis de réparation : fin de réparation
avis de fin de reception : erreur de distribution
vérifier catégorie [reforme| réparation | erreur distribution]
reversement matériel
136
III.4.2.3.2 Etablissement du marche
Figure 31-établissement de marché
III.4.2.3.3 2-3-3- Distribution matériel
Figure 32-distribution matériel
établissement marché
aprés délai de livraison
fournir les produits
réalisation du marché
service contrat fournisseur
fournir les produits
réalisation du marché
distribution materiel
avis de distribution
ordre d'attribution du matériel
notification de fin de reception
stockage
Notification du nouveau matériel arrivé
établ issement de stockage
service contrat
refétabl issement marché()
avis de distribution
ordre d'attribution du matériel
notification de fin de reception
stockage
Notification du nouveau matériel arrivé
137
III.4.2.3.4 Maintenance
Figure 33-maintenance
maintenace
CE :Après exécution des travaux
effectue la maintenance
fournir matériel : si i l existe
demande piéces de rechange
planning de la maintenance
programme la maintenance
DT : cas de panne
DT : travaux periodiques
MAJ documentation et contrôle
DM
Service de planification
service de maintenance
zone d'activité établ issement de stockage
CE :Après exécution des travaux
effectue la maintenance
fournir matériel : si i l existe
demande piéces de rechange
planning de la maintenance
programme la maintenance
DT : cas de panne
DT : travaux periodiques
MAJ documentation et contrôle
DM
138
Diagramme de classe III.4.2.4
Le diagramme de classe représente le diagramme cœur d’UML, après les cas d’utilisations, il
est le seul diagramme obligatoire dans une approche objet. La classification est Un moyen
efficace pour aboutir à un model représentatif de ce que sera le futur system car il joint entre
organisation des données et traitement relatif à celle-ci.
Le diagramme de classe fournit une représentation abstraite des objets du système qui vont
interagir ensemble pour réaliser les cas d’utilisation.
III.4.3 PHASE : CONSTRUCTION
Introduction III.4.3.1
A ce stade les principales spécifications sont stabilisées, Cette phase vise à développer le
logiciel, à métamorphoser l’architecture en un Système complet en concevant, en
implémentant et en testant l’ensemble des éléments, ici les choix techniques se concrétisent
car il va falloir choisir un environnement de développement et un serveur d’application SGBD
et le middleware qui jouera le rôle d’intermédiaire entre l’applicatif et les données
persistantes.
Déploiement de la solution III.4.3.2
La réussite d’un système dépend essentiellement de la satisfaction des utilisateurs finaux,
après l’analyse la conception et la construction du système le déploiement de la solution doit
être étudiée afin de décrire l’environnement optimal pour une bonne exploitation du système.
Diagrammes de déploiement
Ce diagramme décrit la disposition physique des matériels qui composent le système
et la répartition des composants sur ces matériels, ainsi :
• Les ressources matérielles sont représentées sous forme de nœuds.
• Les nouds sont connectés entre eux, à l'aide d'un support de communication.
• La nature des lignes de communication et leurs caractéristiques peuvent être
précisées.
• Les diagrammes de déploiement peuvent montrer des instances de nœuds (un
matériel précis), ou des classes de nœuds.
139
Figure 34-Diagramme de déploiement
• Description du diagramme de déploiement du système
Le diagramme décrit les choix technique retenus
• Serveurs donnés Oracle 10 g
Oracle est un leader mondial des bases de données, connu par ces performances et ces
fonctionnalités qu’il offre aux administrateurs des bases de données, il permet ainsi une bonne
gestion de ces dernières en assurant :
o La définition et la manipulation des données
o La cohérence des données
o La confidentialité des données
o L’intégrité des données
o La sauvegarde et la restauration des données
o La gestion des accès concurrents
• Serveur Tomcat
TCP-IP/SQL
U nité d e p rod uctio n
Windows XP
Serveur d'application
WEB SERVER EJB CONTAINER
Windows XP
Serveur de données
ORACLE
Windows XP
ORACLE 10
Windows. XP
ORACLE 10
Windows. XP
GATEWAYORACLE. 10 SQL SERVEUR 2005
Client leger
Navigateur
Client lourd
Application
TCP-IP/SQL
TCP-IP/SQL
JDBC
RMI
HTTP
HTTP
ACTIVE DIRECTORY
serveur de domaine
140
Le serveur Tomcat est un serveur Open Source qui agit comme un conteneur de servlet
J2EE.Il fait partie du projet Jakarta, au sein de la fondation Apache. Tomcat implémente les
spécifications des servlets et des JSP de Sun Microsystems. Comme Tomcat inclut un serveur
HTTP interne, il est aussi considéré comme un serveur HTTP.
Tomcat est un serveur web qui supporte servlet et JSP. C'est le compilateur jasper qui compile
les pages JSP pour en faire des servlet. Le moteur de servlet Tomcat agit souvent en
combinaison avec un serveur web Apache ou d'autres serveurs web.
Tomcat a été écrit en langage Java, il peut donc s'exécuter via la JVM (machine virtuelle java)
sur n'importe quel système d'exploitation.
• Eclipse
Eclipse est un environnement de développement intégré (le terme Eclipse désigne également
le projet correspondant, lancé par IBM) extensible, universel et polyvalent, permettant
potentiellement de créer des projets de développement mettant en œuvre n'importe quel
langage de programmation. L'application est écrite en Java (à l'aide de la bibliothèque
graphique SWT, d'IBM), et ce langage, grâce à des bibliothèques spécifiques, est également
utilisé pour écrire des extensions.
141
CONCLUSION
GENERALE
142
IV Conclusion générale L’informatique centrée sur les réseaux utilise un modèle d’architecture où les applications
ont entre elles des relations d’échange de données et/ou d’invocation de services. Ces
applications sont distantes, diverses, disparates, pourtant elles coopèrent, ou sont censées le
faire : la gestion de ces relations est prise en charge par ce que l’on nomme « middleware »,
c’est-à-dire une couche logicielle jouant le rôle d’intégration et assurant la communication
entre des composants applicatifs, leur « interopérabilité ».
On distingue deux modes de communication entre applications :
• Asynchrone : chaque échange entre applications est monodirectionnel et n’a pas
connaissance d’autre contexte que le sien. Les deux applications ne sont pas
nécessairement actives en même temps. On parle aussi de couplage faible entre les
applications ;
• Synchrone : une session d’échanges bidirectionnels est maintenue entre les applications.
Les deux applications sont nécessairement actives en même temps et en permanence
durant toute la durée du dialogue. C’est le cas de couplage fort entre les applications.
Il existe une grande diversité de solutions d’interopérabilité, parmi lesquelles nous citons :
• Accès aux bases de données ;
• Appel de procédures et invocation d’objets à distances ;
• File d’attente de messages (middleware orienté message découple les applications
communicantes ;
• Contrôle de transactions.
Tous ces types de solution servent à la fois d’intermédiaires entre les applications
diverses et de tampon entre elles ainsi qu’avec l’architecture du réseau qu’ils essaient de
rendre transparente.
Leur mise en œuvre aboutit à des gains de modularité, d’évolutivité technique, de
minimisation de l’adhérence et du couplage entre sous-systèmes, à leur isolation.
Bien sûr, ces différentes technologies ne répondent pas de la même manière aux besoins de
flexibilité et d’évolutivité du système d’information centré sur le réseau. Il est donc
impératif de prendre en compte les nouvelles solutions émergentes qui, en termes de
potentiel technique, peuvent constituer un puissant instrument d’urbanisation.
143
1. La notion de service logiciel, indissociable de celle de composant ou module, n’est pas liée
à une technologie ou à un outil en particulier, mais plutôt à un modèle de définition des
applications ?
2. L’adoption d’une architecture service : construire une architecture de services est une
stratégie qui consiste à structurer le système d’information comme un ensemble
d’applications ayant la capacité d’exposer leur interface fonctionnelle.
3. L’approche Entreprise Service Bus : les solutions d’intégration marient l’Entreprise
Application Integration (EAI) et Web services. Elles combinent interopérabilité interne
(entre les applications d’un même SI) et externe (entre les systèmes de différents
établissements ou partenaires et les applications transverses).
C’est une solution permettant de constituer un véritable bus de Services fédérant des
systèmes d’information multiples. Le modèle architecture orienté services qu’elles ciblent
ne remet pas en cause l’existant et n’impose aucun langage ou technologie d’implantation
des composants applicatifs. Quant à la mise en œuvre de ce modèle, elle est facilitée car
chaque entité concernée n’est pas obligée de remettre en question certains de ses choix
(langage de développement, protocole de transport, modèle de communication, sécurité,
administration, exploitation, …
Ainsi, urbaniser son système d’information correspond adéquatement à une solution
architecturale qui mérite d’être définie comme l’une des cibles actuelles de la
modernisation des systèmes d’information informatisés.
144
V Bibliographie [AFCET, 1994] AFCET – Enquête sur la pratique de la collectique (groupeware) en France.
Rapport d’étude, Septembre, 1994, 83p.
[AGOSTINI & AL., 1997] AGOSTINI A., DE MICHELIS G., JARKE M., MATTHES F.,
MYLOPOULOS J., POHL K., SCHMIDT J., WOO C., YU E., - A three-Faceted
View of information System : The Challenge of Change, Communications of the
ACM, p. 64-71, December (1998).
[AMRANI-ZOUGGAR & AL., 2007] AMRANI-ZOUGGAR A., FRANCOIS J.,
DESCHAMPS J.C., BOURRIERES J.P. – Multi-echelon production planning
process with no time coordination, 4th IFAC Conference on Management and
Control of Production and Logistics, 27-30 Septembre 2007, Sibiu, Roumanie.
[ARENS & AL., 1993] ARENS Y., CHEE C.Y., HSU C., KNOBLOCK C.A. – Retrieving
and Integrating data from multiple information sources, International Journal of
Intelligent and Cooperative Information Systems, Vol. 2, N°2,p. 127-157, (1993).
[BAYARDO & AL., 1997] BAYARDO R., BOHRER W., BRICE R., CICHOKI A.,
FOWLER G., HELAL A., KASHYAP V., KSIEZYK T., MARTIN G., NODINE
M., RASHID M., RUSINKIEWICZ M., SHEA R., UNNIKRISHNAN C.,
UNRUH A., WOELK D., - InfoSleuth : Agent-Based Semantic Integration of
Information in Open and Dynamic Environments, Proceedings of ACM SIGMOD
Internationel Conference on Management of Data, Tucson, Arozona, USA, p.
195-206, May (1997).
[BEAMON, 1998] BEAMON B. M. – Supply Chain design and analysis : Models and
methods. International Journal of Production Economics, 55 (1998) p. 281-294.
[BENSLIMANE & AL., 1998] BENSLIMANE D. YETONGNON K. CHRAIBI S.
ABDELWAHED H. – DECA / une architecture multi-agents pour
l’interopérabilité des bases de données, Conférence Internationale CARI’98,
DAKAR, Sénégal 1998.
[BENSLIMANE & AL., 2000] BENSLIMANE D. YETONGNON K. CHRAIBI S.,
LECLERCQ E., ABDELWAHED E. - Les systèmes d’information coopératifs :
le projet DECA, Technique et Science de l’Informatique (TSI) Edition Hermès,
Vol 19, N°7/2000, p. 1009-1043, (2000).
145
[BOUGHZALA, 2002] BOUGHZALA I. – Methodology for designing interentreprise
cooperative information system, 6th World Mutli Conference on Systemics,
Cybernetics and Informatics SCI’2002, Orlando, USA, July 14-18 (2002).
[BOULANGER, 1991] BOULANGER D. – Coopération de Systèmes d’Information, Dossier
scientifique pour l’habilitation à diriger des recherches, Université Jean Moulin,
Lyon, 13 Mars (1991).
[BRIOT & DEMAZEAU, 2001] BRIOT J-P., DEMAZEAU Y. – Introduction aux agents, In
principes et architectures des systèmes multi-agents, Jean-Pierre Briot et Yves
Demazeau éditions, Collection IC2, Hermès Science Publications, Paris, France,
décembre (2001).
[BRODIE & CERI, 1992] BRODIE M., CERI S. – On intelligent and cooperative
information systems, International Journal of Intelligent and Cooperative
Information Systems, 1(2), p. 1-35, September (1992).
[CATTEL & AL., 1993] CATTEL R., BARRY D., BARTELS D., EDS – The Object
Database Standard : ODMG 2.0, Morgan Kaufmann, (1993).
[CHRISTOPHER, 1992] CHRISTOPHER M.L. – Logistics and Supply Chain Management,
Pitman Publishing, London, 1992.
[CONRAD & AL., 2002] CONRAD S., HASSELBRING W., JAMES A.E., KAMBUR D.,
KUTSCHE R., THIRAN PH. – Report on the EFIS 2001 Workshop, Computer
Journal, 45(2), p. 249-251, (2002).
[CONRAD & AL., 2002] CONRAD S., HASSELBRING W., JAMES A.E., KAMBUR
D., KUTSHE R., THIRAN PH. – Report on the EFIS 2001 Workshop, Computer
Journal, 45(2), p. 249-251, (2002).
[CROOM & AL., 2000] CROOM S., ROMANO P., GIANNAKIS M. – Supply Chain
Management : an analytical framework for critical literature review. European
Journal of Purchasing and Supply Management 6, (2000), p. 67-83.
[DE MICHELIS & AL., 1997] DE MICHELIS G., DUBOIS E., JARKE M., MATTHES F.,
MYLOPOULOS J., PAPAZOGLOU M., POHL K., SCHMIDT J., WOO C., YU
E., - Cooperative information systems : A manifesto, Cooperative Information
System : Trends and Directions, (1997).
[DOMINGUEZ & LASHKHARI, 2004] DOMINGUEZ H., LASHKHARI R. S. – Model for
Integrating the Supply Chain of an appliance company : A value of information
approach. International Journal of Production Research, 01 June 2004, Vol. 42,
N° 11, p. 2113-2140.
146
[DUMAS & CHARBONNEL, 1990] DUMAS P., CHARBONNEL G. – La méthode OSSAD
– pour maitriser les technologies de l’Information. Tome 1 et 2, les éditions
d’Organisation, 1990.
[ELLIS, 1979] ELLIS C. – Information Control Nets, A mathematical Model of Office
Information Flow, Proceedings of the ACM conf. on Simulation, Measurement
and Modeling of Computer Systems, 1979, p. 225-240.
[FAVIER & COAT, 1999] FAVIER M., COAT F. – Le futur des Systèmes d’Information,
revue française de gestion, Septembre-Octobre 1999.
[FERBER, 1994] FERBER J. – Coopération réactive et émergence. Intellectica, (1994).
[FERBER, 1995] FERBER J. – Les systèmes multi-agents, vers une intelligence collective.
Edition Intereditions, (1995).
[FERBER, 2006] FERBER J. – Concepts et méthodologies multi-agents. Dans modélisation
et simulation multi-agents, applications pour les sciences de l’homme et de la
société. Edition Lavoisier (2006).
[GANESHAN & AL., 1998] GANESHAN R., JACK E., MAGAZINE M.J., STEPHENS P. –
A taxonomic Review of Supply Chain Management Research, in Quantitative
Models for Supply Chain Management, Kluwer Academic Publishers, Boston,
1998, p. 841-880.
[GARCIA-MOLINA & AL., 1997] GARCIA-MOLINA H., PAPAKONSTANTINOU Y.,
QUASS D., RAJARAMAN A., SAGIV Y., ULLMAN J., VASSALOV V.,
WIDOM J. – The TSIMMIS approach to mediation: Data models and languages,
In Journal of Intelligent Information Systems,Vol.8, p. 117-132, (1997).
[GENESERETH & AL., 1997] GENESERETH M.R., KELLER A.M., DUSCHKA O.M., -
Infomaster : an information integration system, In Proceedings of the ACM
SIGMOD Conference, p. 539-542, May (1997).
[GENIN, 2003] GENIN P. – Planification tactique robuste avec usage d’un A.P.S –
Proposition d’un mode de gestion par plan de référence. Thèse de doctorat de
l’Ecole des Mines de Paris, (2003).
[GEUNES & CHANG, 2001] GEUNES J., CHANG B. – Operations research models for
supply chain management and design, in Encyclopedia of Optimization, C.A.
Floudas and P.M. Pardalos Eds, Kluwer Academic Publishers, (2001), p. 133-145.
[GOH, 1997] GOH C. – Representing and Reasoning about Semantic Conflicts in
Heterogeneous Information Systems, PhD thesis, MIT Sloan School of
Management, USA, (1997).
147
[GUYOT, 2006] GUYOT B. – Dynamiques informationnelles dans les organisations, éditions
Hermès science, Février 2006, ISBN 2-7462-1294-3.
[HAMMER, 1993] HAMMER M., CHAMPY J. – le reengineering, Dunod, Paris, 1993, 256
p.
[HERIN & AL., 2001] HERIN D., ESPINASSE B., ANDONOFF E., HANNACHI C. – Des
Systèmes d’information coopératifs aux agents informationnels, Chapitre 8 du
livre « Ingénierie des Systèmes d’Information », Hermès, (2001).
[HUANG & AL., 2003] GEORGE Q. HUANG, JASON S. K. LAU, K. L. MAK. – The
impacts of sharing production information on supply chain dynamics: a review of
the literature. International Journal of Production Research, (2003), Vol. 41,
N°7, p. 1483-1517.
[JENNINGS, 2000] JENNINGS N.R. – On Agent-Based Software Engineering, Artificial
Intelligence Journal 117 (2), p. 277-296, (2000).
[JOUANOT, 2000] JOUANOT F. – Un modèle sémantique pour l’interopérabilité de
systèmes d’information, In INFORSID 2000, Lyon, p. 347-364, 16-19 Mai (2000).
[JOUANOT, 2001] JOUANOT F. – DILEMMA : vers une coopération de systèmes
d’information basée sur la médiation sémantique et la fusion d’objets, Thèse de
doctorat, Université de Bourgogne, France, Novembre (2001).
[KLEIJNEN, 2005] KLEIJNEN J.P.C. – Supply Chain Simulation Tools and Techniques: A
Survey. International Journal of Simulation and Proces Modelling, Vol. 1, N° ½,
(2005), p. 82-89.
[LA LONDE & MASTERS, 1994] LA LONDE B.J., MASTERS J.M. – Emerging Logistics
Strategies : Blue-print for the next century, International Journal of Physical
Distribution and Logistics Management, Vol 24, N° 7, p. 35-47, (1994).
[LARMAN ET BASIL, 2003] – Iterative and incremental Development: a brief history IEEE
Computer, June (2003).
[LARMAN, 2005] – UML2 et les design patterns, 3ème édition (2005).
[LAROUSSE, 2004] LE PETIT LAROUSSE 2004 – Dictionnaire de la langue française, Ed.
Larousse, Paris, (2004).
[LEE & BILLINGTON, 1993] LEE H.L., BILLINGTON C. – Material Management in
Decentralized Supply Chain. Operation Research, Vol 41, N° 5, (1993).
[Le MOIGNE, 1977] Le MOIGNE J.L. – La théorie du système général, Théorie de la
modélisation, Paris, Coll., Systèmes-Décisions, Presses Universitaires de France.
(1977) et (1983).
148
[LUMMUS & VOKURKA, 2004] LUMMUS R.R., VOKURKA R.J. – Defining Supply
Chain Management: a historical perspective and practical guideline. Industrial
Management 1 Data Systems, (1999), p. 11-17.
[MARIA, 1997] MARIA A. – Introduction to modeling and simulation. Proceedings of the
1997 Winter Simulation Conference.
[MARTY, 2000] – Servlets and Java-server pages: a Sun Microsystems Press,
Book:0-13-089340-4 (the end 2000).
[MEDINA-MORA & AL., 1992] MEDINA-MORA R., WINOGRAD T., FLORES R.,
FLORES F. – The Action Workflow Approach to Workflow Management
Technology, Proceedings of CSCW’92, ACM, Toronto, Canada, 31 October – 4
November 1992, p. 281-288.
[MENA, 1999] MENA E. – OBSERVER: An Approach for Query Processing in Global
Information Systems based on Interoperation across Pre-existing Ontologies, PhD
Thesis, University of Zaragoza, Spain, February (1999).
[MEYLAN, 2003] – « Bases de données répliquées » source :
http://libd.isnetne.ch/cours/distributionReplication/02-replication/index.html,
Novembre (2003).
[MIN & ZHOU, 2002] MIN H., ZHOU G. – Supply Chain Modeling : Past, present and
future. Computers & Industrial Engineering 43, (2002), p. 231-249.
[MONSON-HAEFEL, 2000] – Enterprise JavaBeans, Book: 2-84177-124-5 (2000).
[MORANA & PACHE, 2000] MORANA J., PACHE G. – Supply Chain Management et
Tableau de Bord Prospectif : à la recherche de synergies. Logistique et
Management, Vol. 8, N° 1, (2000), p. 77-88.
[NAFFAH, 1994] NAFFAH N. – Workflow : Etat de l’art et évolution, Actes de Conférences
IT FORUM’94, Télécom Paris, Paris, 8-11 Février 1994.
[NURCAN, 1995] NURCAN S., TROLLIET J.Y. – Une méthode d’analyse et de conception
pour les applications Workflow, Actes du XIIIème Congrès d’INFORSID, 31 mai -
2 juin 1995, Grenoble, p. 453-472.
[NURCAN, 1995] NURCAN S., CHIRAC J.L. – Quels modèles choisir pour les applications
coopératives mettant en œuvre les technologies de Workflow et groupeware,
Actes du Congrès AFCET’95, 25-27 Octobre 1995, Toulouse, p. 593-602.
[NWANA, 1996] NWANA H.S. – Software Agents: An Overview, Knowledge Engineering
Review, Vol.11, N°3, p. 205-244, (1996).
149
[OUZZANI & BOUGUETTAYA, 2004] OUZZANI M., BOUGUETTAYA B. – Query
Processing and Optimization on the Web, Distributed and Parallel Databases
Journal, 15(3), Kluwer Academic Publishers, p. 187-218, May (2004).
[PAPAZOGLOU & AL., 1992] PAPAZOGLOU M.P., LAUFMANN S., SELLIS T.K. – An
organizational framework for cooperating intelligent information systems,
International Journal of Cooperative Information Systems, Vol. 1, N°1, March
(1992).
[ROWE, 2002] ROWE F. – Faire de la Recherche en Systèmes d’Information,
Vuibert/FNEGE, Paris 2002.
[ROQUE, 2005] ROQUE M. – Contribution à la définition d’un langage générique de
modélisation d’entreprise. Thèse de doctorat de l’université Bordeaux 1, (2005).
[ROTA-FRANZ & AL., 2001] ROTA-FRANZ K., THIERRY C., BEL G. – gestion des Flux
dans les chaînes logistiques. In Performances industrielles et Gestion des flux.
(Burlat P., Campagne J.P.) Hermès Traité IC2, (2001) , p. 153-186.
[RUSSEL & NORVIG, 2006] RUSSEL S., NORVIG P. – Intelligence Artificielle, Pearson
Education 2ème édition, (2006).
[SHETH & LARSON, 1990] SHETH A., LARSON J. – So far (Schematically) Yet so Near
(Semantically), in proceeding of the IFIP DS-5, Conference on Semantics of
Interoperable Database Systems, Lorne, Australia, November (1992).
[SOUBBARAMAYER, 1994] SOUBBARAMAYER S. – les enjeux du Workflow, Actes de
Conférences IT FORUM’94, Télécom Paris, Paris, 8-11 Février 1994.
[STADTLER & KILGER, 2000] STADTLER H., KILGER C. – Supply Chain Management
and Advanced Planning: concepts, models, software and case studies, Editions
Springer Verlag,( 2000).
[TARI & AL., 1996] TARI Z., CHENG W., YETONGNON K., SAVNICK I. – Toward
Cooperative Database : The Distributed Object Kernel (DOK) Approach,
Proceedings of Conference on Parallel and Distributed Computing Systems
(PDCS’96), DIJON, France, p. 595-600, (1996).
[TARI & STOKES, 1996] TARI Z., STOKES J. – Designing a Reengineering Service for the
DOK Federated Database System, Int. Conf. on Data Engineering (ICDE’97),
Birmingham, p. 465-475, (1997).
[TAYUR & AL., 1999] TAYUR S., GANESHAN R., MAGAZINE M. – Quantitative models
for supply chain management. Kluwer Academic Publisher, (2000).
150
[THOMAS & GRIFFIN, 1996] THOMAS D.J., GRIFFIN P.M. – Coordinating Supply Chain
Management. European Journal of Operation Research. 94, (1996), p. 1-15.
[TOMASIC & AL., 1995] TOMASIC A., RASCHID L., VALDURIEZ P. – Scaling
heterogeneous databases and the design of Disco, Technical report, number 2704,
INRIA, Rocquencourt, France, (1995).
[VON BERTALANFFY, 1973] VON BERTALANFFY L. – Théorie générale des systèmes,
trad. J-B. Chabol, Dunod, (1973).
[WIEDERHOLD, 1992] WIEDERHOLD G. – Mediators in the Architecture of Future
Information Systems, IEEE Computer, Vol. 25, N°3, p. 38-49, March (1992).
[WIEDERHOLD & GENESERETH, 1995] WIEDERHOLD G., GENESERETH M. – The
basis for mediation, Proceedings of the third International Conference on
Cooperative Information Systems, p. 140-157, May (1995).
Résumé :
Il est indéniable que l’acquisition d’outils comme les ERPs ne suffit pas à créer les
conditions d’une bonne gestion. Armé d’une certaine expérience, nous avons essayé de
pénétrer en profondeur dans le fonctionnement de notre organisation pour analyser et
concevoir de nouveaux dispositifs, en mettant notamment en valeur, l’apport de nouvelles
pratiques de mise en réseaux des compétences qui contribuent directement au développement
du capital immatériel. Nous avons adopté une démarche pragmatique permettant de mieux
installer un nouveau système robuste, cohérent et permettant une bonne gestion du capital
immatériel.
Une refonte, une rénovation, une création ou une intégration de système d’information
informatisé poursuivent en général les objectifs majeurs suivants :
Gagner en souplesse et réactivité,
Réussir l’ouverture du SI à des multiples et parfois nouveaux acteurs,
Assurer la capitalisation et la valorisation des acquis et de l’expertise métier,
Enfin, adapter le SI à son temps et le moderniser. C’est l’enjeu majeur de l’urbanisation des
systèmes d’information que d’assurer le succès de telles évolutions, condition sine qua non
d’une modernisation continue.
Vu sa complexité, le développement du système d’information global, de notre organisme,
qui en réalité intègre plusieurs systèmes d’information, a été réalisé selon une architecture
n-tiers. Ce système, étant un système d’aide à la décision, dispose de tableaux de bord
permettant la visualisation de tous les indicateurs de performance et est outillé de GED et
deWorkflow.
Mots clés :
Système D’information; Système Multi-Agents; Système D’information Coopératifs;
Ingénierie Des Systèmes D’information; Travail Collaboratif; Workflow; GED; Chaine
Logistique; Supplychain Management; Bases De Données Réparties.