Amrane Maz

Conception et réalisation d’un workflow à base
d’un système multi-agents pour la gestion des

examens radiologiques
AMRANE Hacene
MAZ Karim
2007/2008
Ministère de l’enseignement supérieur et de la recherche
scientifique
Institut National de formation en Informatique (I.N.I)
Oued-Smar, Alger
Mémoire de fin d’études

Pour l’obtention du diplôme d’ingénieur
d’Etat en informatique
Option : Systèmes d’information
Thème
Conception et réalisation d’un workflow à base d’un
système multi-agents pour la gestion des examens
radiologiques
Réalise par Encadré par

- AMRANE HACENE - Mme B.Hadjazi Dellal
- MAZ KARIM
Promotion : 2007/2008
INSTITUT NATIONAL DE FORMATION EN INFORMATIQUE
Conception et réalisation d’un workflow à base d’un système

multi-agents pour la gestion des examens radiologiques
AMRANE Hacene
MAZ Karim
MEMOIRE PRÉSENTÉ EN VUE DE L'OBTENTION

DU DIPLÔME D’INGENIEUR D’ETAT EN INFORMATIQUE
(SYSTEMES D’INFORMATION)
JUIN 2008
©AMRANE Hacene, MAZ Karim, 2008.

Remerciements
Nous tenons en premier lieu à remercier Dieux pour l’aide qu’il nous a
accordé pour arriver au terme de nôtre projet et de notre cursus.
Nous devons une reconnaissance particulière à nôtre promotrice Mme

Hadjazi Dellal pour la confiance qu’elle nous a accordé en nous
proposant ce projet, mais aussi pour sa disponibilité, sa gentillesse et
surtout sa générosité.
Nous remerciant aussi le personnel du service de radiologie de l’hôpital

Maillot pour l’accueil qu’il nous accordent tout au long de notre stage,
mais surtout leurs coopération et leurs gentillesse.
Nous adressons nos profonds remerciement aux membres de notre

commission de suivi, plus particulièrement Mr Medjaoui et Mr
Chergou pour leurs précieuses remarques,
Nos remerciements vont aussi à chacun des membres du jury pour avoir
fait l’insigne honneur d’examiner notre travail, sans oublier nos
respects à tous nos professeurs.
Pour n’oublier aucun, nous remerciant tous ceux qui ont contribué de
prés ou de loin à l’achèvement de ce travail.
Hacene & Karim
Dédicaces
Je remercie Dieu le tout puissant pour l’aide, le courage et la patience
qu’il m’a accordés tout au long de mon cursus.
Je dédie ce mémoire aux êtres qui me sont les plus chers au monde, mes
parents, à qui je ne saurai exprimer ma profonde reconnaissance et
gratitude… mais je sais bien que ma réussite est le plus beau et le plus
cher cadeaux à vous offrir.
A toi ma mère, pour ton amour, ta patience et ta présence à mes cotés

dans les moments les plus difficiles que j’ai vécus.
A toi mon père pour ton amour, ta patience et surtouts les sacrifices
que tu as fait pour nous.
A vous mes chers frères Mouhdh, Djamilla, Aomar, Zohra pour vôtre
amour, votre patience et surtout vos encouragements qui me donnaient
toujours les forces nécessaires pour continuer, tout au long de mon
cursus. A toi aussi notre joli petit prince, bienvenue chez nous. A toi
aussi ma très chère petite rose, sachez que…
Je dédie aussi ce mémoire à mon binôme Karim tout en reconnaissant

sa gentillesse et sa patience tout au long d’une année de travail
ensemble.
Pour n’oublier aucun, à tous mes amis, qui de prés ou de loin m’ont
encouragé tout au long de mon cursus.
Hacene
Dédicaces
A ma chère mère qui m’a ouvert les yeux sur le monde et qui a été
toujours à mes cotés, rien au monde ne pourra suffire pour te remercier.
A la mémoire de mon père, qui m’a inculqué tant de principes et de

valeurs et qui a toujours su trouver les gestes et les mots qu’il fallait
pour m’aider.
A mes frères et sœurs pour leur amour et leur soutien
inconditionnel.
A toi surtout mon frère Noureddine pour tes encouragements et
surtout ta présence à mes cotés dans les moments les plus difficiles.
A mes oncles, à mes tantes et à toute ma famille.
A Farid et Bilal, Ghanem, Snoussi, Badar, Dai, Belaid, Salim,

Kamel … et à tout mes amis.
A mes amis de Tazmalt.
A mes amis de L’INI.
A mon binôme Hacene
Karim
SOMMAIRE PAGE
Résumé du mémoire ....................................................................................................................I
Problématique...........................................................................................................................VI
Objectifs attendus du projet................................................................................................... VIII
Présentation de l'organisme d'accueil .......................................................................................IX
Première partie : Etat de l’art
Introduction ............................................................................................................................... 1
Chapitre I : Comprendre le workflow.................................................................................... 3
Introduction ............................................................................................................................... 3
I.1. Le Groupware....................................................................................................................... 4
I.1.1. Définition .................................................................................................................... 4
I.1.2. Typologie des applications de Groupware ................................................................. 4
I.1.2.1. Les applications orientées «Mémoire» ......................................................... 4
I.1.2.2. Les applications orientées «Routage» ........................................................... 5
I.1.2.3. Les applications orientées «Echange» .......................................................... 5
I.1.3. Workflow et Groupware.............................................................................................. 6
I.2. Le workflow ......................................................................................................................... 7
I.2.1. La workflow management coalition (WFMC)............................................................ 7
I.2.1.1. Présentation de la WFMC ............................................................................. 7
I.2.1.2. Terminologie de la WFMC............................................................................. 7
I.2.1.3. Le modèle de référence de la WFMC ............................................................ 9
I.2.2. Le workflow et la gestion électronique des documents (GED) ................................ 11
I.2.3. Concepts de base du workflow.................................................................................. 11
I.2.2.1. Des rôles pour accomplir les activités ......................................................... 11
I.2.2.2. Des règles pour formaliser la coordination ................................................ 11
I.2.2.3. Des routes pour organiser la dynamique des processus.............................. 12
I.2.4. Rôles et impacts du Workflow .................................................................................. 13
I.2.5. Domaines d’application du Workflow .................................................................... 13
I.3. Typologie fonctionnelle des applications workflow .......................................................... 13
I.3.1. Le workflow dit «de production............................................................................... 14
I.3.2. Le workflow dit « coopératif» ................................................................................. 14
I.3.3. Le workflow administratif ....................................................................................... 14
I.3.4. Le workflow dit «ad hoc» ....................................................................................... 15
I.4. Workflow et processus d’entreprise................................................................................... 15
I.4.1. Identification des processus dans une organisation................................................... 15
I.4.2. Typologie des processus ........................................................................................... 15
I.4.3. Les processus candidats au Workflow ...................................................................... 16
I.4.4. Les états d’un processus ........................................................................................... 16
I.5. Conduite d’un projet de workflow ..................................................................................... 17
I.5.1. Etapes de développement d’un projet Workflow...................................................... 17
I.5.2. Modélisation d’un processus workflow .................................................................... 19
I.5.3. Implémentation d’un processus workflow ................................................................ 20
I.6. Accès aux informations dans un Workflow ....................................................................... 21
I.7. Quelques produits workflow .............................................................................................. 21
I.8. Workflow flexible .............................................................................................................. 22
I.8.1. Avantages et limites des workflows classiques......................................................... 22
I.8.2. besoins de flexibilité pour un workflow coopératif .................................................. 22
I.8.2.1. besoin de flexibilité du flot de contrôle ........................................................ 22
I.8.2.2. Besoin de flexibilité du flot de données........................................................ 22
I.8.2.3. Besoin d'augmenter le parallélisme entre processus ................................... 23
I.8.2.4. Besoin de support pour l'évolution du modèle ............................................. 23
Conclusion ............................................................................................................................... 24
Chapitre II : Les systèmes multi-agents ............................................................................... 25
Introduction ............................................................................................................................. 25
II.1. Intelligence artificielle distribuée (IAD)........................................................................... 26
II.1.1. Définitions .............................................................................................................. 26
II.1.2. Historique de l’intelligence artificielle distribuée .................................................. 26
II.1.3. De l’IAD aux systèmes multi-agents ...................................................................... 26
II.2. Notion d’agents ................................................................................................................ 27
II.2.1. Définition ................................................................................................................ 27
II.2.2. Caractéristiques d’un agent..................................................................................... 27
II.2.3. Typologie des agents............................................................................................... 29
II.2.3.1. Les agents réactifs .................................................................................... 29
II.2.3.2. Les agents cognitifs................................................................................... 30
II.2.4. Etats d’un agent ...................................................................................................... 31
II.3. Les systèmes multi-agents ................................................................................................ 32
II.3.1. Définition ................................................................................................................ 32
II.3.2. Caractéristiques des SMA...................................................................................... 33
II.3.3. Apports des SMA.................................................................................................... 33
II.3.4. Typologies d’applications SMA ............................................................................. 34
II.4. Les interactions et les langages de communication dans les SMA ................................. 35
II.4.1. Les interactions dans les SMA .............................................................................. 35
II.4.1.1. La coordination........................................................................................ 36
II.4.1.2. La coopération ......................................................................................... 36
II.4.1.3. La communication.................................................................................... 36
II.4.2. Les langages de communication dans les SMA..................................................... 37
II.4.2.1. Knowledge query and manipulation language (KQML........................... 38
II.4.2.2. Foundation for Intelligent Physical Agents (FIPA-ACL ......................... 38
II.4.2.3. Autres protocoles ..................................................................................... 39
II.5. Les méthodologies de conception des SMA.................................................................... 39
II.5.1. Méthodologies centrées sur les agents................................................................... 39
II.5.2. Méthodologies issues des méthodologies orientées objet...................................... 41
II.5.3. Méthodologies issues de l’ingénierie des connaissances....................................... 42
II.6. Les plates formes multi-agents ......................................................................................... 43
II.6.1. La plate forme Jade (Java Agent Developement framework) ............................... 43
II.6.2. La plate forme Jack ............................................................................................... 43
II.7. Architecture des plates-formes multi-agents .................................................................... 44
II.8. Critères de choix de plates-formes multi-agents............................................................... 44
II.8.1. Critères généraux ................................................................................................... 44
II.8.2. Critères spécifiques................................................................................................ 44
Conclusion ............................................................................................................................... 45
Chapitre III : La radiologie médicale ................................................................................... 46
Introduction ............................................................................................................................. 46
III.1. L’imagerie médicale ........................................................................................................ 47
III.1.1. Définition............................................................................................................. 47
III.1.2. Concepts fondamentaux de l’imagerie digitalisée............................................... 47
III.1.3. Application de l’informatique en imagerie médicale .......................................... 48
III.2. Les systèmes d’information hospitaliers (SIH................................................................. 48
III.2.1. Définition............................................................................................................. 48
III.2.2. Objectifs principaux des SIH............................................................................... 49
III.2.3. Le dossier patient................................................................................................. 49
III.3. Les systèmes d’information radiologiques (SIR) ............................................................ 49
III.3.1. Définition............................................................................................................. 49
III.3.2. Fonctions d’un SIR.............................................................................................. 50
III.4. Le système d’archivage et de communication PACS...................................................... 50
III.4.1. Définition............................................................................................................. 51
III.4.2. Architecture d’un PACS...................................................................................... 51
III.4.3. Apports d’un PACS au SIR ................................................................................. 53
III.5. Intégration des PACS et des SIR aux SIH....................................................................... 54
III.6. Les standards DICOM et HL7......................................................................................... 54
III.7. Télémédecine et Téléradiologie ...................................................................................... 55
III.8. L’aide à la décision médicale ......................................................................................... 56
III.8.1. Typologie des systèmes d’aide à la décision médicale........................................ 56
III.8.1.1. Les systèmes d’aide indirecte à la prise de décision ............................. 56
III.8.1.2. Les systèmes de rappels automatiques .................................................. 56
III.8.1.3. Les systèmes consultants ...................................................................... 56
III.8.2. Techniques d’aide à la décision........................................................................... 57
Conclusion ................................................................................................................................ 58
Deuxième partie : Analyse-Conception
Introduction ............................................................................................................................. 59
IV.1. Analyse............................................................................................................................ 60
IV.1.1. Présentation du service........................................................................................ 60
IV.1.2. Analyse des facteurs humains ............................................................................ 61
IV.1.3. Analyse des facteurs technologiques .................................................................. 63
IV.1.4. Description du fonctionnement actuel du processus .......................................... 64
IV.1.5. Diagnostic et recommandations .......................................................................... 66
IV.2. Conception ...................................................................................................................... 68
IV.2.1. Conception du Workflow .................................................................................... 69
IV.2.1.1. Choix de l’approche de conception ...................................................... 69
IV.2.1.2. Conception des diagrammes de cas d’utilisation ................................. 71
IV.2.1.3. Conception des diagrammes d’activités ............................................... 83
IV.2.1.4. Conception du diagramme des classes ................................................. 90
IV.2.2. Conception du SMA............................................................................................ 96
IV.2.2.1 Choix de la méthodologie de conception .............................................. 96
IV.2.2.2 Analyse du SMA ................................................................................... 97
IV.2.2.3 conception du SMA............................................................................... 99
IV.2.3. Composantes du Workflow ............................................................................... 107
IV.2.3.1 Les ‘3R’ du Workflow ........................................................................ 107
IV.2.3.2 Les formulaires et les documents ........................................................ 108
Conclusion .............................................................................................................................. 109
Troisième partie : Réalisations
Introduction ........................................................................................................................... 110
V.1. Architecture réseau du système ...................................................................................... 111
V.2. Environnement de développement ................................................................................. 112
V.2.1. Langage de programmation ................................................................................. 112
V.2.2. Choix du SGBD................................................................................................... 113
V.2.3. Choix de la plate-forme workflow....................................................................... 113
V.2.4. Choix de la plate-forme multi-agents .................................................................. 113
V.3. Description des fonctionnalités du système.................................................................... 114
V.4. Les droits d’accès ........................................................................................................... 119
V.5. Sécurité du système ........................................................................................................ 119
Conclusion .............................................................................................................................. 120
Conclusions et perspectives.................................................................................................... 121
Annexes .................................................................................................................................. 122
Glossaire ................................................................................................................................. 138
Bibliographie .......................................................................................................................... 141
Liste des figures
Figure I-1 Typologie des applications de Groupware .............................................................. 04
Figure I-2 Modèle de référence du Workflow........................................................................ .09
Figure 1-3 Les principaux routages utilisés dans les applications Workflow. ......................... 12
Figure 1-4 Typologie fonctionnelle des applications de Workflow. ....................................... 14
Figure I-5 Les différents états d'un processus…. ..................................................................... 16
Figure 1.6 Etapes d’un projet de développement d’une application de Workflow .................. 17
Figure 1.7 Démarche générale de modélisation de processus …. ............................................ 19
Figure II-1 Architecture d’un agent réactif.............................................................................. .29
Figure II-2 Architecture BDI d’un agent ................................................................................. 30
Figure II-3 Les différents états d’un agent. .............................................................................. 32
Figure II-4 Organisation d’un système multi-agents............................................................... 32
Figure II-5 Classification des types d’applications de SMA. ................................................. .34
Figure II-6 Les méthodologies orientées Agents...................................................................... 39
Figure III-1 Le système d’information d radiologie................................................................. 51
Figure III.2 Architecture d’un système PACS. ........................................................................ 52
Figure III.3 Intégration SIH-SIR-PACS (Echange de données)............................................... 54
Figure IV.1 Cas d’utilisation global. ....................................................................................... 72
Figure IV.2 Cas d’utilisation : Fixation de rendez-vous .......................................................... 73
Figure IV.3 Cas d’utilisation : Anesthésie................................................................................ 75
Figure IV.4 Cas d’utilisation : Réalisation d’un examen radiologique. ................................... 76
Figure IV.5 Cas d’utilisation : Interprétation d’un examen complexe ..................................... 79
Figure IV.6 Cas d’utilisation : Edition et remise d’un résultat d’un examen complexe ........ 81
Figure IV.7 Diagramme d’activités global. .............................................................................. 84
Figure IV.8 Diagramme d’activités (Fixation d’un RDV) ...................................................... 85
Figure IV.9 Diagramme d’activités (Anesthésie).................................................................... 86
Figure IV.10 Diagramme d’activités (Réalisation d’un examen) ........................................... 87
Figure IV.11 Diagramme d’activités (Interprétation d’un examen complexe) ........................ 88
Figure IV.12 Diagramme d’activités (Edition des résultats d’un examen complexe) ............. 89
Figure IV.13 Diagramme de classes........................................................................................ 91
Figure IV.14 Schéma global de conception Voyelles ............................................................. 97
Figure IV.15 Structure de l’organisation.................................................................................. 99
Figure IV.16 Architecture interne de l’agent interface (AgtInt) ........................................... 100
Figure IV.17 Architecture interne de l’agent expert (AgtExp) ............................................. 101
Figure IV.18 Classification des méthodes d’apprentissage.................................................... 101
Figure IV.19 Agent conçu autours d’un système de classifier ............................................... 102
Figure IV.20 Diagramme de classe pour le traitement par classifier system ......................... 103
Figure IV.21 Architecture interne de l’agent DF (AgtDf) ..................................................... 104
Figure IV.22 Diagramme d’interaction : Ajout d’une connaissance..................................... 105
Figure IV.23 Diagramme d’interaction : Aide à la décision, Cas oû la connaissance existe . 105
FigureIV.25 Diagramme d’interaction : Aide à la décision, traitement par classifier system 106
Figure IV.26 Diagramme de protocoles de demande d’inscription auprès de AgtDf ........... 106
Figure IV.27 Diagramme de protocoles de demande de dés-inscription auprès de AgtDf ... 107
Figure IV.28 Diagramme de protocoles de demande de dés-inscription auprès de AgtDf ... 107
Figure V.1 Architecture générale du système ........................................................................ 111
FigureV.2 Interface authentification....................................................................................... 113
FigureV.3 Interface administrateur ........................................................................................ 114
FigureV.4 Interface création d’un utilisateur ......................................................................... 114
FigureV.5 Interface fixation rendez-vous............................................................................... 115
FigureV.6 Fiche de rendez-vous............................................................................................ 115
FigureV.7 Interface réalisation anesthésie............................................................................. 116
FigureV.8 Interface réalisation d’un examen ....................................................................... 117
FigureV.9 Envoi d’un message ............................................................................................. 117
FigureV.10 Interface de la secrétaire médicale ..................................................................... 118
FigureV.11 Fiche compte rendu d’examen ............................................................................ 118
Liste des tableaux

Tableau VI.1 Analyse des facteurs technologiques du service ................................................ 63
Tableau VI.2 Le formalisme du diagramme de cas d’utilisation ............................................ .71
Tableau IV.3 Le formalisme du diagramme d’activités ........................................................... 83
Tableau IV.4 Le formalisme du diagramme de cas d’utilisation. ............................................ 90
Tableau IV.5 Liste des rôles ................................................................................................... 108
Tableau IV.6 Liste des formulaires. ....................................................................................... 109
Liste des abréviations
ACL
Agent Communication Langage : Langage de communication qui combine habilement
KQML et KIF. KQML est pris pour la partie administrative et KIF pour la représentation des
données et/ou expressions à évaluer.
API
Application Programming Interface : Bibliothèques d'objets (dans le cas de langages objets) qui
permettent au programmeur d'utiliser directement des objets. L'API réseau du Java permet
d'ouvrir des sockets, mais aussi de gérer les adresses IP ainsi que les URL.
CORBA
Common Object Request Brocker Architecture : Une architecture définie par l'OMG qui permet
l'implémentation d'objets distribués. Ces objets sont accessibles par l'intermédiaire de nombreux
langages grâce à la définition d'IDL.
Framework
Ensemble d'outils (de conception, d'exécution, de dégage) qui permettent de faire quelque chose,
par exemple de mettre en oeuvre d'autres programmes. Ces outils peuvent êtres des programmes,
des méthodes de travail, des librairies, etc.
IDL
Interface Definition Language : Un langage qui permet de définir les objets CORBA. Une
Interface IDL déclare les opération, exceptions et attributs. IDL ne permet pas d'implémenter les
objets, comme son nom l'indique, il ne fait que définir les interfaces des objets.
Java / JDK
Java, langage créé en 1995 par Sun, ce langage est orienté objet et présente le gros avantage
d'être portable. JDK (Java Développement Kit) est le kit de développement Java fournis par Sun
pour le développement de programmes Java.
KIF
Knowledge Interchange Format : Langage qui permet de coder des expressions, algorithmes ou
données dans le plus pur style Lisp : 3+5 deviens (+ 3 5).
KQML
Knowledge Query Modeling Langage, ce langage est le standard de fait pour l'échange
d'information entre les agents. (Pour s'en persuader, il suffit de regarder la liste des produits déjà
existants).
MOM
Message Oriented Middleware : Middleware orienté message, c'est un middleware qui
contrairement à CORBA ou RMI ne permet pas l'appel de méthodes à distances, mais seulement
l'échange de messages. Un MOM peut aussi contenir des services.
ORB
Object Request Broquer : Les librairies, processus et autres infrastructures qui permettent, dans
un environnement distribué CORBA, aux objets de communiquer entre eux. L'ORB permet aux
objets qui demandent des services d'entrer en contact avec les objets qui fournissent ces services.
OSI
Open System Interconnection : Le modèle OSI est composé de 7 niveaux. Ces niveaux sont
organisés de manière hiérarchiques. Les niveaux sont définis de telle sorte qu'une modification
dans un niveau ne nécessite pas de modification dans les autres niveaux.
Proxy
Objet et/ou programme qui permet d'accéder à des ressources qui ne sont pas accessibles
directement, c'est donc un intermédiaire. L'utilisation d'un proxy est en général de protéger la
ressource à laquelle on veut accéder.
RMI
Remote Method Invocation est une technique qui permet à des objets Java de se servir d'objets
Java distants comme s'il s'agissait d'objet local. L'équivalent en C/C++ est RPC (Remote
Procedure Call). CORBA fournis les mêmes fonctionnalité, mais présente l'avantage de ne pas
être réduit à un seul langage.
Socket
Objet qui permet de communiquer sur un réseau de type TCP/IP. La création d'une socket
nécessite un serveur sur lequel on se connecte et un client qui se connecte à se serveur. Les deux
peuvent ensuite communiquer, c'est à dire, envoyer et recevoir des suites d'octets. La définition
d'un protocole de communication est donc indispensable.
Thread
Programme qui s'exécute à l'intérieur d'un autre programme : ceci permet à un programme de
faire plusieurs choses en même temps. Un thread est parfois appelé tâche.
UDP
User Datagram Protocol : Protocole en dessous de TCP/IP sur le modèle OSI. Ce protocole ne
garantie pas l'arrivée des données (datagrams), ni leur ordre d'arrivée.
FIPA
Est une organisation à but non lucratif produisant des normes pour l'inter opérabilité des agents
hétérogènes de logiciel.
Résumé du mémoire
Actuellement les entreprises marquent un passage du découpage fonctionnel et

hiérarchique à une organisation par processus bénéfices et clientèle. Ceci implique un
engagement collectif des acteurs et des ressources, ainsi qu’une forte intégration des données
et des informations. Cette tendance met l’accent sur trois aspects importants : la gestion des
processus de l’entreprise, la communication et la coordination entre les acteurs impliqués dans
le processus et le partage des informations et des connaissances individuelles et collectives.
Cette importance croissante de la notion de processus et du travail de groupe, ainsi que

les changements dans la conception du travail et de son organisation impliquent
nécessairement des évolutions. Cette évolution est induite par la naissance de nouvelles
technologies répondant à ces orientations comme le groupware et le Workflow.
Nous nous focalisons sur la technologie workflow, comprise comme étant une
application groupware qui se base sur l’automatisation des processus de travail au niveau des
entreprises afin de gagner en temps et en coûts. Cette technologie est en train de gagner du
terrain sur le marché mondial en permettant aux entreprises d’évoluer vers une nouvelle
restructuration de leurs méthodes de travail. L’objectif étant la décentralisation d’exécution
des processus à travers la construction d’un système intelligent dans lequel les acteurs
évoluent vers un but en coopérant et en adaptant leurs comportements à l’évolution de leur
environnement
Le caractère innovant de l’introduction de la technologie workflow est le fait

d’aborder l’analyse, l’optimisation et l’automatisation des processus en faisant intervenir
l’ensemble des interactions et les relations de coopération entre les différents intervenants
dans le déroulement du processus.
L’inconvénient majeur des systèmes workflow traditionnels est leurs rigidité : dans les
applications administratives et de production, il s’agit de la difficulté à gérer les cas
particuliers et d’exception. Dans les applications créatives, il s’agit de l’inadaptation des
modèles et des systèmes traditionnels à supporter les interactions coopératives.
I
Lorsque le processus de travail est complexe, on assiste à une interaction coopérative
entre les acteurs, d’oû la nécessité de la recherche de moyens rendant le workflow coopératif
flexible. L’introduction de technologies permettant de donner plus de flexibilité aux systèmes
traditionnels est devenue inévitable. Les systèmes multi-agents (SMA) ont prouvé leurs
capacités à résoudre les problèmes liés à l’interaction dans un système complexe
d’utilisateurs.
Les SMA est une technologie mise au point dans un but méthodologique dans le
domaine de l’intelligence artificielle, elle a ensuite évolué pour devenir à la fois une méthode
de gestion et une technologie de l’ingénierie logicielle dont le but est de procurer des
solutions à des problèmes de la vie réelle.
Le principe qui fait la force des SMA est de partager les tâches à réaliser entre
plusieurs entités appelées agents qui travaillent en collaboration pour atteindre un objectif
commun. La solution globale est la coordination et le regroupement des solutions partielles
des agents, un principe qui s’applique parfaitement aux différents processus existants au
milieu de plusieurs organisations.
Le service de radiologie de l’hôpital Maillot est une structure complexe, il constitue le

centre d’intérêt de toutes les autres unités de soins de cet hôpital, pratiquement toutes les
unités lui font appel pour assurer leurs fonctionnalités, il utilise plusieurs techniques faisant
appel aux moyens informatiques : échographie, scanner, imagerie par résonance
magnétique…etc. De plus les tâches sont distribuées entre plusieurs acteurs, le partage et
l’échange des documents et des information est fréquent, très important et exigeant plus de
flexibilité du système. Ce service ne peut correctement fonctionner que s’il existe une
communication et une coopération entre les différents acteurs afin de traiter au mieux les
patients. Les moyens informatiques interviennent pour faciliter les tâches liées à l’exercice de
l’activité radiologique.
Dans ce contexte, Le travail qui nous a été proposé au niveau de la division systèmes
d’information du centre de recherche sur l’information scientifique et technique (CERIST),
consiste à concevoir et réaliser un workflow basé sur un système multi-agents pour la gestion
des examens radiologiques de l’hôpital Maillot. Ce projet est donc à cheval entre deux
domaines informatiques très intéressants qui sont le Workflow et les systèmes multi-agents.
II
Ce mémoire est divisé en trois parties : Etat de l’art, Analyse-Conception et
Réalisation. Après avoir présenter la problématique, les objectifs de notre projet ainsi que
l’organisme d’accueil, on entame l’étude de ces différentes parties en détail.
La première partie (Etat de l’art) introduit le cadre théorique dans lequel s’inscrit notre
projet, on présentera donc une synthèse des concepts liés aux domaines concernés par notre
étude. Le premier chapitre de cette partie donne une vue d’ensemble sur la technologie
workflow : ses concepts et définitions, rôles, domaines d’application, limites des workflow
classiques et le besoins de flexibilité pour un workflow coopératif. Le deuxième chapitre est
consacré à l’études de l’approche multi-agents : concepts, protocoles de communication,
méthodologies de conception des SMA, architecture et critères de choix des plates formes de
développement systèmes multi-agents. Le troisième chapitre traite de la radiologie médicale,
il sera question en premier lieu de présenter cette discipline tout en précisant son rôle,
devenue primordial pour une meilleure prise en charge et un meilleur traitement des patients,
et les techniques informatiques introduites dans son fonctionnement.
La deuxième partie de ce mémoire (Analyse-Conception) est consacrée à l’étude du

système de fonctionnement du processus de gestion des examens radiologiques du service
radiologie de l’hôpital Maillot, de recenser les anomalies enregistrées et de proposer quelques
recommandations pour remédier à ces anomalies. La partie conception est divisée en deux
phases : La première est consacrée à la conception du système workflow et la deuxième à la
conception du SMA qui constituera le système d’aide à la décision diagnostique. Il sera
question en fin de cette partie de définir les ‘3R’ du workflow conçu : rôles, règles et routes.
Quant à la troisième partie (Réalisation), elle marque les étapes d’implémentation des
solutions proposée, il sera question de présenter l’architecture du système, les outils de
développement et enfin la description des fonctionnalités du système ainsi que les mesures de
sécurité à mettre en place pour assurer la confidentialité et le sécurité des données du système.
Ce mémoire se termine par une conclusion générale qui synthétise les différents aspects
évoqués tout au long de notre projet, ainsi que la présentation de quelques perspectives
d’extension, d’enrichissement et de développement du projet.
Mots clés: Groupeware, Workflow, wfmc, Lotus Notes, IAD, Agents, SMA, KQML, FIPA-
ACL, JADE, SIH, SIR, Telemedicine, Teleradiologie, PACS, Aide à la décision medicale.
III
Problématique
Le service d’imagerie de l’hôpital Maillot est doté d’un matériel très sophistiqué (deux
scanners, deux IRM, trois échographes,…), et propose des prix largement raisonnables
comparés au secteur privé. Ces deux paramètres ont conduit à un flux de demande nationale
qui ne cesse d’augmenter (86998 patients traités en 2004 contre 109761 patients traités en
2005, soit 22763 examens traités en plus). Le service possède aussi un matériel très coûteux et
très efficace pour l’archivage des images médicales (PACS : Picture Archiving and
Communication System) qui n’est pas du tout exploité, ni pour utiliser au mieux les images
pour permettre d’optimiser la décision diagnostique et la stratégie thérapeutique retenue, ni
pour aider l’enseignement et la recherche scientifique.
Ce service se retrouve submergé dans un bain de difficultés fonctionnelles et

organisationnelles engendrées par l’absence de système d’information et des nouvelles
technologies de restructuration des méthodes de travail : nombre très important de demandes,
mauvais rendement des médecins (la planification des examens leur est confiée), des délais
d’attente devenus intolérables pour l’obtention d’un rendez-vous (48 heure) et la récupération
des résultats d’examens (15 jours pour certain examen de scanner).
Le processus de gestion des examens radiologiques au service d’imagerie de l’hôpital

Maillot est un processus complexe qui assure entre autres les fonctions liées à la fixation de
rendez-vous aux malades, à la réalisation et l’interprétation des examens, et à l’édition et la
remise de ces résultats aux patients. On assiste au quotidien à des problèmes liés à la
planification des examens, à la coopération et à la communication entre les différents acteurs
intervenant dans le processus (chef de service, secrétaires, réceptionnistes, médecins...),
notamment pour la réalisation et l’interprétation des examens qui nécessitent l’implication de
plusieurs médecins pour donner leurs avis :
- Les médecins n’ont aucune information sur le patient, ils ne connaissent ni ses
antécédents, ni les résultats de ses examens antérieurs, et ceci en l’absence d’un dossier
médical radiologique ; l’interprétation n’est donc pas assistée (Les images de radios et les
comptes rendus ne sont pas archivés d’une façon électronique).
VI
- Une communication défaillante entre les différents acteurs du système : si un radiologue
veut transmettre un compte rendu à un radiologue expert pour avis et que ce dernier est
absent, cela entraînera un retard dans la transmission et donc l’interprétation des examens.
- Perte du temps due à la durée nécessaire au transfert de documents d’un acteur à un autre :
le compte rendu passe par plusieurs intervenants avant sa remise au patient (médecin
radiologue médecin expert médecin radiologue réceptionniste Secrétaire
médecin radiologue réceptionniste.
- Consommation considérable de papier : pour chaque examen on a besoin de délivrer un
jeton, une fiche de RDV, une décharge, un bon de paiement, une fiche d’enregistrement,
un bon de retour, et plusieurs clichés de radio.
- Perte de documents due au nombre important de dossiers qui circulent entre les différents
acteurs (médecins, secrétaires, …), cette perte entraîne un mauvais suivi du malade.
- Compte tenu du nombre important de malades qui passent par l’hôpital quotidiennement,
la recherche de documents est fastidieuse surtout lorsqu’il s’agit d’une urgence (Les
dossiers sont archivés dans des classeurs).
- Les médecins ne possèdent pas un système d’aide à la décision pour s’en servir dans des
cas d’examens compliqués, dans ces cas l’appel aux autres collègues devient nécessaire.
C’est pour répondre à cette problématique que nous travaillons sur ce projet qui nous a
été proposé par le CERIST (Centre d’Etude et de Recherche sur l’Information Scientifique et
Technique) au sein du service d’imagerie de l’hôpital Maillot dont l’objectif est de concevoir
et de réaliser un système workflow à base de l’approche multi-agents pour la gestion des
examens radiologiques de ce service.
Nous nous intéressons dans ce projet à concevoir et réaliser une solution workflow qui
permettra d’évoluer vers une nouvelle restructuration des méthodes de travail au sein de ce
service, cette solution permettra de garantir une coopération efficace entre les acteurs afin de
rendre le meilleur service possible aux patients et assurer une gestion optimale du service. On
introduira à notre solution le mécanisme multi-agent qui rendra le système intelligent et
flexible à tel point que les acteurs évoluent en coopérant et en adaptant leurs comportements à
l’évolution de leur environnement. Ce système doit gérer la prescription de l’examen, la
gestion des rendez-vous, la réalisation de l’examen, la gestion du résultat, l’interprétation et la
consultation du dossier médical radiologique.
VII
Objectifs attendus du projet
Il s’agit de réaliser un outil qui permettra l’automatisation des tâches liées à la gestion
des examens radiologiques, et à la coopération entre les acteurs intervenant dans ce processus
au sein du service de radiologie de l’hôpital Maillot, donc de proposer une nouvelle
organisation des méthodes travail au sein de ce service. Les objectifs à atteindre sont :
Diminuer le temps d’attente pour la prise de rendez-vous et la récupération des résultats
(On passe de 48H à 5 minutes maximum pour la prise de rendez-vous).
Réaliser des gains en temps en supprimant les délais de traitement superflus : le transfert
et la recherche de documents se fait donc de manière automatique via le dossier patient
informatisé.
Assurer le suivi des patients et la continuité des soins et mettant en place un dossier
patient informatisé, l’archivage des documents se fera donc de manière électronique, ainsi
des gains en coûts sont réalisés en diminuant l’utilisation du papier.
Faciliter la gestion du service en automatisant les procédures de travail, donc assurer de
meilleures conditions de travail au personnel et une meilleure qualité de service aux
patients.
Faciliter les communications intergroupes en mettant au point des mécanismes de
communication performants (messagerie électronique).
Aider les médecins dans leurs interprétations et leurs diagnostics en mettant à leur
disposition des mécanismes d’aide à la décision, ainsi diminuer les risques d’erreurs.
Mettre à la disposition des médecins résidents des mécanismes d’apprentissage, en leurs
assurant un accès à certains cas jugés utiles à des fins pédagogiques.
Assurer une sécurité accrue du système : les tâches de chaque participant dans le
processus lui sont affectées par le système.
VIII
Présentation de l'organisme d'accueil
Le centre hospitalo-universitaire Maillot de Bab El Oued se situe au pied de la Casbah,
au coeur d’Alger, Il est intégré dans une structure hospitalière de 840 lits, et dessert un bassin
de population de prés de 1,5 millions d'habitants. Il est constitué de plusieurs unités de soins
dont l’unité d’imagerie médicale.
Le service d’imagerie de l’hôpital Maillot est structuré en plusieurs départements :

IRM, TDM, radiologie vasculaire, radiologie ostéoarticulaire, radio-urologie, radiologie
génitale, radio-pédiatrie, neuroradiologie, radiologie digestive, radiologie thoracique et
radiologie interventionelle. L'exercice est organisé en système vacataire pour un partage
efficace et optimal des moyens. A cet effet le service dispose de plusieurs consoles de
traitement d'images et d'une station d'archivage. De plus ce service dispose d'un ensemble de
stations de visualisation d'images ainsi que d'une station d'archivage. Une ligne spécialisée
dédiée de 2 Méga bytes assure les connexions internes et externes.
Le service dispose de tous les moyens pédagogiques requis (secrétariat scientifique,

archives centralisées, moyens audio-visuels, documents pédagogiques, filmothèque,
diapothèque, bibliothèque spécialisée). Un projet de téléconférence réalisé en collaboration
avec le service de radiologie de l'hôpital la Timone est en cours de développement via
l'agence nationale de documentation scientifique
En plus de ses activités d'imagerie médicale, le service a une vocation nationale fixée
par arrêté ministériel. Les conditions d'exercice et la disponibilité des moyens permettent
d'offrir une prise en charge pédagogique, paramédicale et médicale (formation de graduation
et de post graduation, formation continue).
Le service assure actuellement la formation de médecins résidents (formation de post-

graduation). Cette dernière est pratique et théorique (cours magistraux, activités en salle,
colloques, présentation de dossiers ...). Qualifié comme terrain de stage, le service participe à
l'application du programme national d'enseignement de la radiologie réparti sur 4 années. Le
staff médical participe régulièrement à l'enseignement des étudiants en médecine (formation
de graduation).
IX
Dans le cadre du jumelage entre le CHU de Bab El Oued et l'Assistance publique des
hôpitaux de Marseille, le service d'imagerie médicale a développé un partenariat avec le
service de radiologie de l'hôpital la Timone. De plus le jumelage du CHU Maillot avec
l'hôpital de Tamanrasset, ville située à l'extrême sud algérien, permet le désenclavement et la
mise à disposition des moyens du nord pour le sud, le service d'imagerie y contribue
particulièrement.
Parmi les objectifs recherchés, le désenclavement des régions, le partage des

ressources, la mise en commun des moyens et la fluidité de l'information. le jumelage du
CHU Bab el oued avec l'hôpital de Tamanrasset, par le biais de la télématique sanitaire
s'inscrit dans la démarche arrêtée.
L'installation d'un réseau PACS et le développement de la télémédecine sont des

tâches inclues dans le cahier de charge du service et de ces partenariats : la maîtrise de la
distance, la suppression des frontières pour un partage et une mise en commun des moyens
fait partie des objectifs de ce service.
En collaboration avec l'agence nationale de documentation de la Santé (Ministère de la

santé, de la population et de la réforme hospitalière) et en partenariat avec l'assistance
publique des hôpitaux de Marseille, un projet incluant autant l'intranet que la télémédecine est
en cours de développement.
X
Introduction
Les entreprises opèrent aujourd’hui dans des marchés en constante évolution
caractérisés par des cycles de vie de plus en plus courts et un accroissement des exigences de
flexibilité. Ainsi l’environnement économique actuel impose aux organisations de réduire au
maximum les coûts inutiles.
Le développement de démarches de réorganisation de processus est une réponse

adaptée à la recherche d’optimisation des processus. Elle peut se traduire par l’utilisation
d’une solution logicielle appropriée, comme le Workflow. Ce dernier permet d’être un
support à une nouvelle organisation, il se caractérise par une analyse fine de l’organisation
cible qui permet de définir les tâches, les rôles et les règles de routage des documents gérés.
Le transport physique de documents et l’ordonnancement de tâches bien connues

peuvent être confiées à un système d’information qui gère de façon centralisée la répartition
du travail de tout un chacun. C’est dans ce cadre que des solutions informatiques de type
workflow ont été mises en place, dans les années 90. L’objectif est essentiellement
organisationnel afin de générer des gains financiers, de temps et de qualité de service.
Lorsque le processus du travail est complexe, on assiste à une interaction coopérative

entre les acteurs, d’oû la nécessité de la recherche de moyens rendant le workflow coopératif
et flexible. Les systèmes multi-agents ont prouvé leurs capacités à résoudre les problèmes liés
à l’interaction dans un système complexe d’acteurs. Cette technique a été mise au point dans
un but méthodologique dans le domaine de l’intelligence artificielle, elle a ensuite évoluée
pour devenir à la fois une méthode de gestion et une technique d’ingénierie logicielle.
L’un des domaines oû les taches sont distribuées entres plusieurs acteurs, et le partage
et l’échange des documents et des information est très important et exigeant une flexibilité du
système est le domaine médicale, plus particulièrement les services de radiologie.
Tout au long de cette première partie, il sera question d’introduire le cadre théorique
dans lequel s’inscrit notre projet, on présentera donc une synthèse des concepts liés aux
domaines concernés par notre étude.
1
Le premier chapitre de cette partie donne une vue d’ensemble sur la technologie
workflow : ses concepts et définitions, ses rôles et ses domaines d’application, on évoquera
vers la fin de ce chapitre les limites des workflow classiques et le besoins de flexibilité pour
un workflow coopératif.
Le deuxième chapitre est consacré à l’études de l’approche systèmes multi-agents :

concepts, protocoles de communication, méthodologies de conception et plates formes de
développement de systèmes multi-agents tout en présentant leurs différentes architectures
ainsi que les critères de choix de plates-formes multi-agents.
Le troisième chapitre traite les concepts liés au cas pratique que nous avons choisi : La
radiologie médicale, il sera question en premier lieu de présenter cette discipline tout en
précisant son rôle, devenue primordial pour une meilleure prise en charge et un meilleur
traitement des patients, on mettra par la suite le point sur les techniques informatiques
introduites dans son activité : système d’information hospitalier (SIH), système d’information
radiologique (SIR) et système d’archivage et de communication d’images (PACS) tout en
passant par la présentation du dossier patient informatisé, et enfin on parlera de l’intégration
des PACS et des SIR aux SIH ainsi que des concepts de télémédecine et de téléradiologie
dont le workflow constitue leur outil préféré.
2
Chapitre I Comprendre le workflow
Introduction
Cela fait maintenant plusieurs années que les organisations vivent des transformations
majeures sur les plans humain, organisationnel et technologique, qui font de leur capacité à
maîtriser le changement une condition de survie. Il est en effet de plus en plus nécessaire
d’offrir des outils permettant à différentes personnes éloignées physiquement et qui doivent
travailler collectivement sur un même projet de communiquer, de s’échanger des documents
et de présenter leurs informations à l’ensemble de l’équipe.
Le groupware est une technologie qui aide le travail coopératif, basé sur la
communication, la collaboration et la coordination, ce qui est essentiel au développement
durable de toute entreprise. C’est un concept qui porte avant tout sur les processus de
communication et de travail en groupe, et sur la façon dont ces processus peuvent être
soutenus par des outils logiciels basés sur une architecture réseaux. Le workflow est une
application de groupware, elle s’intéresse aux communications formelles entre les membres
d’une organisation. Conceptuellement, le workflow relève de l'automatisation de processus,
donc de flux informationnels dans lesquels les documents et les tâches associés sont
acheminés d'un participant à un autre selon des règles plus ou moins détaillées et prédéfinies.
C’est une technologie qui offre une infrastructure pour l’automatisation et l’amélioration des
flux de travail et de l’enchaînement des tâches des processus d’entreprises afin de gagner en
temps et en coûts, elle est en train de gagner du terrain sur le marché mondiale en permettant
aux entreprises d’évoluer vers une nouvelle restructurations des méthodes de travail.
L’objet de ce chapitre est donc de présenter les différents concepts liés au workflow, il
s’agit en premier lieu de présenter la technologie groupware : sa définition et ses différentes
typologies, on verra que le workflow n’est rien d’autre qu’une application de groupware. On
passera par la suite à détailler le concept de workflow, on présentera en premier lieu
l’organisme mondial de standardisation dans le domaine du workflow (WFMC), on évoquera
par la suite la gestion électronique des documents (GED), qui est la première application de
workflow. Après une présentation des concepts de base du workflow, on passera à citer les
principaux rôles et impacts du workflow, ses typologies ainsi que ses domaines d’application.
Enfin, on traitera les différentes étapes de conduite d’un projet workflow, en passant par
l’identification des processus candidats au workflow, puis on mettra le point sur les limites
des workflow classiques et le besoin de flexibilité pour un workflow coopératif.
3
I.1. Le Groupware
I.1.1. Définition
« On désigne par le terme Groupware, les méthodes et les outils logiciels (appelés
collecticiels ou synergiciels) permettant à des utilisateurs géographiquement éloignés de
travailler en équipe à travers les réseaux. Le travail en équipe peut se concrétiser par le
partage d’information ou bien la gestion et l’échange de données informatisées. Il s’agit dans
la plupart du temps : d’outils de messagerie, espace de documents partagés, conférences
électroniques (Vidéoconférence, Chat,…) et d’outils de workflow » [CCM, 07].
I.1.2. Typologie des applications de Groupware

On peut classer les application Groupware en trois familles représentées sur une
matrice dont l’axe des abscisses permet de classer les applications qui reposent sur des
interactions plus ou moins fortes entre les individus, et l’axe des ordonnées les applications
qui apportent des services d’information et de communication dans un environnement plus ou
moins structuré [LEV, 00]. La figure I-1 illustre cette typologie.
Plus structuré
Mémoire Routage Echange
Bibliothèque Workflow Suivi

Moins structuré
Kiosque Messagerie Conférence
Moins interactif Plus interactif
Figure I-1 : Typologie des applications de Groupware [LEV, 00]
I.1.2.1. Les applications orientées «Mémoire»

Ces applications ont pour but principal de mettre en commun des informations, voir
des connaissances capitalisées par et pour les activités de différents groupes et individus.
4
Cette mise en commun constitue une mémoire collective, partagée qui regroupe des
documents multimédia (textes, images et sons).
Cette famille d’applications prend tout son intérêt dés qu’il s’agit d’organiser le travail au sein
d’une équipe dont les membres opèrent de façon dispersée, tant sur le plan géographique que
temporel.
I.1.2.2. Les applications orientées «Routage»

Ces applications ont pour but principal d’organiser dans le temps et l’espace des flux
d’information, suivant des schémas de circulation généralement prédéfinis entre les acteurs.
Chaque application de routage assure un transport en temps réel ou différé, l’objet
électronique (formulaire ou mémo) d’un individus à un autre, d’un individus à une application
ou d’une application à une autre, utiles pour l’accomplissement des tâches et des activités
quotidiennes des individus et des groupes [LEV, 00].
Cette classe d’applications va permettre à chaque individu, et au groupe dans son ensemble,
de développer des modes particulièrement efficaces de communication et de coordination.
L’émetteur décide de transmettre l’information (le formulaire électronique d’une activité de
workflow ou le courrier électronique de sa messagerie) à un ou à plusieurs destinataires.
La messagerie est la première et la plus simple des applications workflow, elle permet
d’envoyer un formulaire simple comprenant : nom de l’émetteur et du destinataire, copie,
date, heure, objet, etc.
I.1.2.3. Les applications orientées «Echange»

Ces applications permettent d’assister de façon totalement asynchrone, les interactions
entre plusieurs acteurs impliqués dans des actions communes et ce, quels que soient l’heure et
le lieu de l’échange.
Dans les environnements complexes oû la division du travail fait largement appel aux
mécanismes de coordination basé sur l’ajustement mutuel, les besoins de communication et
d’échange entre individus ou entre groupes sont fondamentaux. Ces échanges peuvent être
plus ou moins structuré selon que les besoins de coordination et de coopération dominent.
On distingue deux sous-classes d’application [LEV, 00]:
Applications de suivi : L’agenda et le planning de groupe sont des exemples de ces
applications, elles permettent l’optimisation de la gestion du temps individuel et collectif
5
d’une ou de plusieurs équipes, de gérer les tâches quotidiennes, personnelles ou déléguées et

les étapes d’un projet.
Application de conférence : elles peuvent se présenter sous la forme de conférence
électronique (forum de discussion), d’autres exemples sont les chats rooms et les outils de
vidéoconférence.
I.1.3. Dimension humaine du Groupware

Un des apports du groupware est qu’il aide les équipes à mieux communiquer. Cet
aspect du groupware semble souvent si implicite qu’il reste ignoré, car il traite des rapports
humains et de la manière dont les individus interagissent.
Le groupware accroît le niveau de communication entre les différents membres d’une équipe,
de plus il met à leur disposition des bases d’information et de connaissance de toute
l’entreprise mais si le groupware est mal utilisé, il peut produire un impact négatif sur
l’entreprise si la hiérarchie n’est pas respectée. C’est pourquoi, avant d’introduire le
groupware, toute entreprise doit être prête à adopter ce type d’infrastructure sociale et d’être
consciente des implications du groupware sur l’organisation et le management [KHO, 98].
I.1.4. workflow et Groupware

La typologie des applications de groupware montre que le workflow est bien une pièce d'un
puzzle technologique servant globalement des usages de communications variés inhérents aux
situations de travail coopératif [KHO, 98].
S'il est vrai que les applications de workflow ont pour vocation de traiter les
interactions formelles du travail, elles exigent dans la réalité l'accompagnement d'autres
applications de groupware. Ainsi, les applications de groupware, favorisant l'émergence d'une
mémoire organisationnelle riche et accessible, sont des instruments privilégiés qu'il convient
d'intégrer aux applications de workflow, au titre des applications appelées. Il en va de même
pour la classe d'application de groupware orientée échange [LEV, 00]. L'intérêt d'intégrer ce
type d'application (ex. conférences électroniques) au workflow est grand. En effet, le travail
réellement accompli par les participants d'un workflow ne repose jamais sur la seule
communication formelle et procédurale. Celle-ci est, pour tout ou partie, prise en charge par
l'application de workflow proprement dite. Mais les échanges informels sont toujours présents
et s'imposent, surtout lorsque la complexité des tâches et des activités sollicite l'intelligence
collective plus que la seule compétence individuelle [KHO, 98].
6
I.2. Le workflow
I.2.1. La workflow management coalition (WFMC)
Pour définir le workflow et les concepts de base sur lesquels il repose, Nous devons
présenter tout d'abord l'organisme international de standardisation de workflow.
I.2.1.1. Présentation de la WFMC

Fondée en août 1993, la WFMC est une organisation internationale à but non lucratif
qui regroupe des éditeurs, des utilisateurs et des experts dans le domaine du workflow. Sa
mission est de promouvoir l’utilisation du workflow grâce à la définition de standards portant
sur la terminologie workflow, l’interopérabilité et la connectivité entre les produits workflow
[LEV, 00].
La WFMC s’impose aujourd’hui comme le principal organisme de standardisation et
de référence pour le marché workflow. Elle est organisée en deux grands comités : le comité
technique et le comité de pilotage. Ces comités sont composés de groupes de travail
thématiques : terminologie workflow, interopérabilité, connectivité et communication avec le
reste du monde. Ces comités se réunissent alternativement aux USA et en europe. En fait la
participation à la coalition est ouverte à toutes les parties impliquées dans la création,
l’analyse et le déploiement de solutions workflow [LEV, 00].
I.2.1.2. Terminologie de la WFMC [WMC, 07]

Nous présentons ici quelques définitions de base présentées par la WFMC:
workflow
« Automatisation de tout ou partie d'un processus d'entreprise au cours duquel
l'information circule d'une activité à l'autre, c'est à dire d'un participant (ou d'un groupe de
participants) à l'autre, pour action en fonction d'un ensemble de règles de gestion ».
Système de gestion de workflow
« Système qui définit, implémente et gère l'exécution d'un ou de plusieurs workflow à
l'aide d'un environnement logiciel fonctionnant avec un ou plusieurs moteurs de workflow et
capable d'interpréter la définition d'un processus, de gérer la coordination des participants et
d'appeler des applications externes ».
Tâche
« Une tâche est un ensemble d’actions exécutées par une seule personne, de durée
réduite dans le temps, et ayant un objectif de réalisation à court terme ».
7
Activité
« Une activité est une description d’un travail représentant une étape logique d’un
processus. Une activité peut être manuelle ou automatisée. Une activité workflow
(automatisée) fait appel à des ressources humaines ou matérielles pour son accomplissement.
Lorsqu’une ressource humaine est requise, l’activité est affectée à un participant (rôle) »
Procédure
« Une procédure est un ensemble coordonné d’actions ou d’opérations qui sont
reliées, en série ou en parallèle, dans le but d’atteindre un objectif commun ».
Exemples : procédure de remboursement de notes de frais, procédure de déclaration de
sinistre, procédure de commande.
Processus d'entreprise
« Ensemble de plusieurs activités reliées les unes aux autres pour réaliser un objectif,
dans un contexte généralement organisationnel qui définit des rôles et des relations ».
Processus
« Représentation informatique d'un processus qui définit à la fois les processus
manuels et workflow. Cette définition peut être utilisée pour la modélisation et la simulation
d'un processus, comme elle peut être exécutée par un système de gestion de workflow. Une
définition de processus est un réseau d'activités intégrant des critères de lancement et de
terminaison ainsi que des informations relatives aux activités (participants, applications
appelées, données spécifiques, etc.) ».
Sous-processus
« Processus déclenché à partir d'un autre processus (ou Sous-processus) et qui fait
partie intégrante du processus dans son ensemble. Un workflow peut comprendre plusieurs
niveaux de Sous-processus ».
Instance de processus
« Représentation d’un cas unique d’exécution de processus. Chaque instance
représente une application unique d’un modèle de processus qui est géré spécifiquement.
L’instance de processus gère sa propre métamorphose et enregistre ses événements
spécifiques »
Acteur du workflow
« Un acteur du workflow est une ressource (soit un programme informatique, soit un
individu utilisant ou non un programme doté d'une interface utilisateur) qui exécute une
activité. Par extension, toute ressource qui exécute partiellement ou totalement le travail
dévolu à une instance d'activité ».
8
Bon de travail (Work Item)

« Représentation du travail à effectuer par un acteur du workflow dans le cadre d'une
instance d'activité dans une instance de processus ».
Corbeille (Work List)
« Liste des bons de travail qui attendent d'être réalisés par un acteur du workflow.
Une corbeille peut être partagée par un groupe d'acteurs. Elle est une composante importante
de l'application cliente gérant les interactions entre le moteur de workflow et le gestionnaire
de corbeille ».
I.2.1.3. Le modèle de référence de la WFMC

La WFMC a établit un schéma de référence pour définir les principales composantes
d’un système de gestion de workflow : cinq composantes faisant elles même l’objet de
standards, et cinq interfaces représentées sur la figure I-2. Tout le travail de la coalition est
basé sur l’hypothèse : « Tout les systèmes de gestion de workflow reposent sur les mêmes
composantes génériques qui interagissent selon diverses modalités » [WMC, 07].
Outils de définition de
processus
Interface 1
API Workflow (WAP) et

I I
n formats d’échange n
t t
e Dispositif de services e Autre(s)
Outils r r dispositif(s) de
f
workflow f
d’administration et Moteur(s) de workflow services workflow
a a
de pilotage c c
e e Moteur(s) de
workflow
5 4
Interface 2 Interface 3
Application Application
cliente Workflow appelée
Figure I-2 : Modèle de référence du workflow [WMC, 07]
9
Le moteur de services de workflow est un environnement run-time capable d’exécuter un

ou plusieurs workflow. Il est distinct des applications et des outils orientés utilisateur mis en
œuvre pour l’accomplissement des tâches. Son rôle consiste à consulter les routes du
workflow pour designer la prochaine activité à consulter. La coalition a définit cinq
composantes faisant elles-mêmes l’objet de standards, et cinq interfaces [WMC, 07] :
L’outil de définition de processus
Cette interface permet l’échange des modèles entre les moteurs de workflow et les
différents outils de modélisation de processus, elle est désignée sous le terme d’interface
d’import/export de définition de processus. Ces modèles peuvent être les informations
suivantes : - Conditions de déclenchement et de terminaison de processus.
- Identification d’activités dans le processus incluant les applications externes
associées et les données d’ordonnancement de processus.
- Identification des types de données et des chemins d’accès.
- Définition des conditions de transition et des règles de routage.
- Informations relatives aux décisions d’allocation de ressources.
L’application cliente Workflow
Cette application est un module logiciel qui peut appeler les applications et les
outils logiciels nécessaires à l’accomplissement des tâches, le moteur de services workflow
poursuit alors le déroulement du processus. L’interface 2 permet à des applications clientes de
communiquer avec le moteur de workflow.
L’application appelée par le workflow
Or les systèmes de gestion de workflow doivent communiquer avec toutes les
applications externes nécessaires à l’accomplissement des tâches, la WFMC attache beaucoup
d’importance au développement de standards relatifs à l’appel de telles applications.
Les autres moteurs de services workflow
L’interface 4 permet l’interopérabilité entre moteurs de workflow. La WFMC
voudrai définir des standards permettant à des systèmes de gestion de workflow, conçus et
produits par différents éditeurs, de travailler ensemble sur les mêmes tâches.
L’outil d’administration et de pilotage du système workflow
Cette interface permet l’interaction entre les applications d’administration et le
moteur de workflow, cela permettra :
- Obtenir une vision complète de l’état d’un workflow cheminant à travers une
organisation, indépendamment du système workflow mis en oeuvre.
- Choisir le meilleur outil d’administration et de pilotage en fonction des besoins et objectifs.
10
I.2.2. Le workflow et la gestion électronique des documents (GED)

« La GED est un ensemble de techniques permettant d'organiser, de gérer et de
distribuer des informations sous forme électronique; mais également de structurer des
documents pour favoriser l’utilisation, la circulation, les échanges et l’archivage» [JCH, 05].
La GED est devenue une composante des systèmes d'information dans lesquels elle
introduit des fonctions de gestion et de traitement des documents. Elle pilote les flux entre
producteurs et consommateurs. La GED permet la réduction des coûts opérationnels, un accès
facile et sécurisé aux informations, elle met également en place des dispositifs permettant
d'échanger et de partager les connaissances en permanence. En effet la mise en commun des
documents dans un groupe est la première étape d’une évolution vers des applications de
groupware et de workflow.
I.2.3. Concepts de base du workflow

Nous allons voir que les concepts de rôles, de règles et de routes sont à la base de la
gestion des mécanismes de coordination pour une application de workflow.
I.2.2.1. Des rôles pour accomplir les activités

Le workflow est avant tout un outil de communication et de coordination, cela suppose
que les personnes travaillent dans un contexte de coopération minimale et qu’elles assument
des rôles bien définis et formellement impliqués dans l’accomplissement des processus. Dans
un workflow, le système et les participants doivent jouer leurs rôles respectifs dans
l’accomplissement des tâches. En effet les tâches ne sont pas systématiquement réalisées par
des personnes [LEV, 00].
Le rôle est un concept très puissant dans la conception d’un workflow par ce qu’il
permet d’introduire une grande souplesse organisationnelle. Lors de l’exécution du processus,
le moteur du workflow procédera à la recherche des participants pouvant assurer tel ou tel
rôle, puis il lui envoie un ordre de travail.
I.2.2.2. Des règles pour formaliser la coordination

Gérer la coordination au sein d’une organisation, c’est gérer un réseau plus ou moins
complexe d’interdépendances entre les activités réalisées par des acteurs assumant des rôles
dont les responsabilités sont définies par rapport à des objectifs. Cette coordination
s’implémente dans un workflow à travers l’usage des règles.
11
Les principales causes de l’interdépendance sont [LEV, 00].

- Les ressources partagées : Hommes, informations, outils.
- Les contraintes à priori : Dans un workflow, le déclenchement de certaines activités dépend
de la terminaison d’autres activités.
- Les contraintes simultanées : Dans un workflow, le déclenchement de certaines activités
doit être simultanée lorsqu’elles doivent être accomplies en parallèle.
I.2.2.3. Des routes pour organiser la dynamique des processus
Les routes d’un workflow désignent les chemins que prennent les différents résultats
d’une activité à l’autre, d’un rôle à un autre, et donc, d’un participant à l’autre. La figure I-3
représente les principaux routages utilisés dans les applications workflow.
Activité 2
Résultat 1 Résultat 1
Activité 1 Activité 2
Activité 1
Résultat 2 Activité 3
Activité 2 Activité 1 Résultat 1

Résultat 1
Résultat 2 Activité 3 Activité 2 Résultat 2

Résultat 1
Résultat 1
Figure 1-3 : les principaux routages utilisés dans les applications workflow [LEV, 00]
On distingue le routage séquentiel pour l’exécution d’une suite de tâches, le routage

parallèle pour l’exécution de tâches dans une même unité de temps, le routage à rétroaction
pour la ré-exécution de tâches, et le routage circulaire pour le retour de l’information à
l’expéditeur en fin du processus.
I.2.4. Rôles et impacts du workflow

Les applications workflow contribuent essentiellement à l’amélioration de la
productivité des entreprises, qu’elles produisent des biens, des services ou des informations.
Cette amélioration se réalise par [LEV, 00]:
12
- Réduction des coûts opérationnels : La duplication, la diffusion, le stockage et la mise à

jour des documents est électronique, des économies de papiers sont ainsi réalisées.
- Suppression des délais de traitement superflus : Le transfert et la recherche de documents
se fait de manière automatique, ainsi un gain de temps est réalisé.
- Amélioration du service à la clientèle : Un système de workflow permet un traitement
rapide des demandes en respectant les priorités, donc une réponse rapide et efficace est
remise aux clients.
- Augmentation des performances des équipes fonctionnelles : Les tâches routinières sont
automatisées.
- L’amélioration du contrôle et du planning : Des méthodes statistiques et d’analyse
d’information sont utilisées pour des applications workflow afin de rassembler de
précieuses donnés de gestion dans le but de mieux comprendre la situation et prendre les
meilleures décisions.
- Sécurité accrue : Dans une application workflow, les tâches sont affectées aux participants
par le système, ainsi, un participant n’effectue que les tâches qui lui sont affectées pour
des rôles qu’il peut accomplir.
I.2.5. Domaines d’application du workflow

Les applications workflow sont introduites dans plusieurs domaines (systèmes) :
- Systèmes bancaires : Délivrance de prêts, approbation de crédits.
- Système des assurances : Traitement des demandes de règlement, remboursement.
- Applications intersectorielles : Demandes de congés, remboursement des frais de mission,
- Système médical : Suivi des dossiers médicaux, planification des opérations chirurgicales.
I.3. Typologie fonctionnelle des applications workflow

Les applications workflow sont conçues pour faciliter la coordination des actions et
des acteurs nécessaires à l’accomplissement des processus. Les éditeurs des applications GED
étaient les premiers à intégrer des fonctions de workflow dans leurs systèmes [Lev, 00]. On
distingue quatre types d’applications workflow, illustrés par la figure 1-4.
13
Workflow centré sur le Workflow centré sur le

document groupe
Workflow de production Processus répétitifs et Processus spécifiques
structuré par les et structuré par les
documents intervenants
Workflow Workflow
Workflow appliqués
aux processus de production Coopératif Bases de données
principaux (Forte Ex : Demande de prêt Ex : Développement et moteurs du
valeur ajoutée) bancaire de nouveaux produits Workflow
Workflow appliqués
Workflow Workflow Messagerie et
Workflow ad hoc
aux processus de Administratif ad-hoc formulaire

support (Faible valeur Ex : remboursement Ex : Rédaction / électronique
ajoutée) de notes de frais révision d’un
document
Processus Processus
‘Modes routine’ ‘Modes projet’
Figure 1-4 : Typologie fonctionnelle des applications de workflow [LEV, 00]
I.3.1. Le workflow dit « de production»

Il correspond à la gestion des processus opérationnels, répétitifs et critiques pour la
performance globale de l’entreprise, ou de l’unité organisationnelle qu’en est responsable. Les
traitements des réclamations déposées par des clients d’une compagnie d’assurance, les
instructions de demande de prêts bancaires, les traitements de demandes et de facturation des
sociétés de vente par correspondance, sont des exemples de workflow de production.
I.3.2. Le workflow dit « coopératif»
L’utilisation de ce type de workflow facilite la communication intergroupe, ces
groupes peuvent être un petit comité avec une organisation orientée projet ou un grand groupe
repartit à travers le monde et travaillant sur un objectif commun. Par conséquent, le workflow
coopératif fait appel aux moyens de communication qui permettent l’ajustement mutuel des
individus impliqués. Le lancement d’un nouveau produit, la rédaction collective d’un rapport
d’expertise sont des exemples de workflow coopératif.
I.3.3. Le workflow administratif
Le workflow administratif traite un volume d’information moins important que le
workflow de production. Il a pour objectif de décharger les ressources d’une entreprise des
tâches administratives. En effet ces procédures sont répétitives (Approbation de dépenses,
Demande de titres de congés), fortement prédictibles et les règles d’enchaînement des tâches
14
sont très simples et clairement définies ; ces procédures sont aisément automatisables évitant
ainsi un travail fastidieux oû peuvent naître des erreurs souvent humaines. Les systèmes
workflow administratifs permettent de lier à une tâche administrative, les documents et les
informations nécessaires à la réalisation de cette tâche par un acteur humain, ces systèmes
gèrent également le routage des documents et le remplissage des formulaires.
I.3.4. Le workflow dit «ad hoc»
IL automatise les procédures d’exception, occasionnelles, voir uniques, ils sont le plus
souvent liés à des routines administratives. Les exemples les plus courants sont : la gestion de
correspondances institutionnelles exigeant parfois des révisions et des approbations
intermédiaires, recrutement d’une compétence particulière. Les applications workflow ad hoc
font appel aux moyens de communication qui permettent l’ajustement mutuel des individus
impliqués.
I.4. Workflow et processus d’entreprise

I.4.1. Identification des processus dans une organisation
Etablir un découpage de l’organisation en processus, c’est sélectionner des liaisons
entre activités et, par la suite, les besoins de communication, de coopération et de
coordination, essentiels à la performance. Pour identifier et décrire un processus, il faut
disposer de deux types d’informations [KHO, 98]:
- Informations permettant de délimiter le périmètre et décrivant l’environnement interne du
processus (frontières du système).
- Informations liées à l’environnement externe du processus.
I.4.2. Typologie des processus

Les processus primaires et les processus secondaires [LEV, 00]
« Un processus primaire est représenté par certaines activités contribuant directement
à fournir des produits matériels ou immatériels porteurs de fonctionnalités pour les clients de
l’entreprise ». Le processus de vente, le processus de production, certains processus de flux
financiers sont des processus primaires de l’entreprise.
« Les processus secondaires servent uniquement de soutient aux processus primaires et ne se
traduisent par aucune prestation extérieure directe ». C’est généralement le cas des processus
de conception et d’entretien des ressources ou de soutien méthodologique.
15
Les processus récurrents et les processus de projets [LEV, 00]

« Les processus récurrents (répétitifs) réalisent des produits plutôt standardisés et
routiniers. C’est le cas des processus courants de production de série, de facturation et de
recouvrement, les processus de projet (spécifiques), à l’opposé, présentent des résultats
fortement personnalisés. Chaque produit pris individuellement a une importance significative
pour l’entreprise, et sa durée de réalisation est généralement plus importante par rapport aux
cycles de gestion normaux ».
I.4.3. Les processus candidats au workflow

Parmi tous les types de processus dans l'entreprise, ce sont les processus métier qui
sont les premiers candidats au workflow. Un processus métier à pour objet la création de
valeur pour le client. Cette valeur s'exprime par la satisfaction du client qui "achète" le produit
matériel ou immatériel offert par l'entreprise. Un processus métier se décrit par des activités,
des rôles et des interactions traduisant différentes formes de communication, de coopération et
de coordination [KHO, 98].
Généralement, les processus candidats à être optimisés grâce aux technologies du
workflow sont ceux, nécessitant une grande coordination, une collaboration intense et dont les
acteurs sont répartis aussi bien géographiquement que temporellement. De plus, si une
multitude d'acteurs est susceptible d'intervenir dans le déroulement d'un processus pour jouer
les mêmes rôles, le système de workflow permet d'optimiser l'emploi du temps de ceux-ci.
I.4.4. Les états d’un processus

La figure I-5 présente les états de base par lesquels passe un processus.
Arrêter
Suspendu Terminé
Redémarrer Terminer Itérations sur les

Suspendre Reprendre
activités en cours
Initialiser Démarrer
Initialisé Exécution Activé
Redémarrer
(Une ou plusieurs
instances d’activités)
Complété
Figure I-5 : Les différents états d'un processus [WDS, 05]
16
Depuis son initialisation jusqu’à sa terminaison, un processus passe par les états de
base suivants :
- Initialisé : L’instance du processus a été créé, mais n'a pas commencé.
- En cours d'exécution (running) : L’instance du processus est en exécution.
- Suspendu : L'exécution de l’instance du Processus est suspendue temporairement.
- Complété : L’exécution du processus a été finie et complétée normalement.
- Activé : Une ou plusieurs instances du processus en attente d’exécution
- Terminé : L’instance du processus a été terminée.
I.5. Conduite d’un projet workflow

I.5.1. Etapes de développement d’un projet workflow
La figure 1.6 illustre les six étapes caractérisant tout projet workflow :
Etape 1 Définir le projet de Workflow
Etape 2 Analyser le processus et les situations de travail
Etape 3 Concevoir les solutions
Etape 4 Réaliser la solution de Workflow choisie
Etape 5 Mettre en place l’application de Workflow
Etape 6 Piloter et optimiser l’application de Workflow
Figure 1.6 : Etapes d’un projet de développement d’une application workflow [LEV, 00]
• Etape 1 : Définir le projet workflow :
- La première étape consiste à spécifier l’objectif du projet de workflow. Il va falloir
prendre contact avec les principaux acteurs opérationnels, comprendre la situation et les
besoins particuliers tant organisationnels que technologiques, définir les conditions de
succès du projet, et enfin, sensibiliser les acteurs opérationnels impliqués dans le futur
17
système de gestion de workflow. Il s’agit, en fait, de bien exprimer les besoins, c’est-à-
dire, à poser les questions qui relèvent spécifiquement d’un projet workflow [LEV, 00] :
- Comment le processus est-t-il définit ?
- Quelle est la nature des flux d’information ?
- Comment le travail est-t-il affecté et pris en charge ?
- Oû travaillent les différents participants ?
- Quelle est la durée de vie de chaque activité ?
• Etape 2 : Analyser le processus et les situations de travail :
L’objectif de cette étape, c’est de conduire un diagnostic. C'est-à-dire,
d’étudier le contexte et de modéliser le processus existant en mettant au point les méthodes,
techniques et les outils du projet, de recueillir les données du processus, de modéliser le
processus existant (modèle descriptif) et enfin, établir un diagnostic avec les personnes
impliquées.
• Etape 3 : Concevoir des solutions :
Le projet workflow oblige à concevoir plusieurs solutions, car, dans le domaine de
l’organisation, il n’existe pas de solution unique et optimale, il n’y a que des solutions plus
ou moins satisfaisantes qu’il convient de concevoir, de modéliser et d’évaluer. C’est l’objet de
cette étape. Il s’agit donc, d’adapter la méthode et les techniques d’implémentation de
workflow en fonction de l’outil de workflow retenu.
• Etape 4 : Réaliser la solution workflow choisie :
La réalisation de la solution workflow consiste à implémenter le modèle cible dans le
système de gestion de workflow et de tester la cohérence et le fonctionnement à priori de
l’application workflow. Les différentes tâches à réaliser dans cette étape sont [LEV, 00]:
- Planifier la réorganisation liée à la mise en œuvre du processus cible.
- Définir le processus cible dans le système de gestion de workflow.
- Réaliser les formulaires électroniques associés aux activités.
- Réaliser les interfaces avec les applications appelées.
- Tester la cohérence et le fonctionnement de l’application workflow.
• Etape 5 : Mettre en place l’application de workflow
L’objectif de cette étape est de réaliser le processus de changement sur les plans
humain, organisationnel et technologique. Appliquer la réorganisation, informer et
communiquer, installer le matériel et les logiciels, former les utilisateurs et les
administrateurs, mettre en route le système de gestion de workflow.
18
• Etape 6 : Piloter l’exploitation de l’application de workflow :

Cette étape a pour objectif de contrôler et d’évaluer la pertinence de l’application
workflow, de plus, elle fournit des recommandations pour l’optimisation du workflow en
mettant au point les règles de supervision et de pilotage de l’application workflow.
Il faut souligner que le système de gestion de workflow dispose d’un environnement de
supervision des processus qui permet, en temps réel, de connaître leur état d’avancement et
les activités en cours de réalisation sur toutes les instances du processus en cours. Cet
environnement permet également d’obtenir des informations sur le temps passé, les problèmes
posés et les solutions apportées [LEV, 00].
La base de donnée d’un système de gestion de workflow qui utilise cette technologie, permet
également d’effectuer des traitements statistiques qui facilitent les évaluations de
performance, la mesure des progrès accomplis et de ceux qui restent à accomplir.
I.5.2. Modélisation d’un processus workflow

La modélisation consiste à représenter graphiquement le fonctionnement d’un
système. La figure 1.7 montre les trois grandes étapes de modélisation de processus :
Objectifs du
projet Workflow
Modéliser le processus existant Modèle descriptif du

processus existant
Analyser et simuler des Dossier d’analyse

scenarios d’amélioration et de simulation
Modéliser le processus cible Modèle normatif

du processus cible
Validation cible / objectifs
Figure 1.7 : Démarche générale de modélisation de processus [KHO, 98]
La modélisation d’un processus inclut la modélisation des actions accomplies et des

règles qui régissent leur coordination. Les éléments de base de la modélisation sont :
- L’activité qui symbolise une étape du processus.
- Le rôle qui accomplit l’activité.
19
- La route (le chemin) qui représente les transitions entre les activités.
- L’objet qui transite par les activités et chemins et qui subit des transformations.
Toute modélisation d’un processus passe par trois étapes [KHO, 98] :
- La première étape de l’activité de modélisation consiste à réaliser un modèle descriptif du
processus considéré. Cette modélisation ne doit pas uniquement décrire les activités et leur
circuit, mais également prendre en compte les relations entre les acteurs.
- La deuxième étape consiste à réaliser des simulations successives qui serviront de bases
de réflexion et d’actions à l’étape suivante. Le résultat de la simulation est de prendre des
décisions concernant l’optimisation des coûts et délais, et l’amélioration de la qualité du
processus et en suite, la qualité des produits.
- La troisième étape de la modélisation consiste à identifier et analyser les
dysfonctionnements actuels du processus et de rechercher des solutions permettant
d’atteindre les objectifs fixés. La modélisation de processus peut s’élaborer selon deux
approches :
- L’approche fonctionnelle : Elle est centrée sur les activités et qui a pour objectif
d’améliorer la performance du processus au niveau de la qualité du produit, des délais
et des coûts.
- L’approche relationnelle : Centrée sur les rôles, et qui a pour objectif de créer une
dynamique de groupe.
I.5.3. Implémentation d’un processus workflow

L’implémentation du workflow représente un ensemble de tâches spécifiques d’un
projet de workflow, ces tâches correspondent à la réalisation proprement dite de l’application.
« L’implémentation du workflow peut être définie comme étant la traduction
informatique d’un réseau d’activités et d’interactions entre rôles, intégrant des critères de
lancement et de terminaison ainsi que des informations relatives à chaque activité et à chaque
rôle : liste des participants et des applications appelées, données spécifiques des activités et
de leurs règles de gestion ainsi que des routages des flux d’information » [KHO, 98].
En d’autres termes un système de gestion de workflow doit être capable d’implémenter la
logique qui permet de déterminer dynamiquement les itinéraires d’un processus préalablement
modélisé au moment de l’exécution de chacune de ses activités, tout en tenant compte des
exceptions aux règles.
20
D’une manière générale, quels que soient les produits de workflow utilisés, l’implémentation
de workflow (définition de processus) consiste à définir trois variables [LEV, 00] :
- Les rôles, qui doivent être définis indépendamment des personnes réellement impliquées dans
l’organisation.
- Les règles relatives aux conditions d’exécution des activités, en intégrant des applications
extérieures au workflow.
- Les routes qui assurent la liaison entre les activités et leurs règles, et entre les acteurs.
En résumé, l’implémentation de workflow avec ces outils s’effectue en trois étapes :
- Définition du carnet d’adresse des participants (utilisateurs connectés au réseau).
- Création d’un modèle de processus (plan).
- Création des formulaires associés aux activités du processus.
I.6. Quelques produits workflow

Plusieurs compagnies de logiciels de dimension mondiales développent leurs propres
solutions workflow, Ci-dessous quelques exemples.
TIBCO IProcess 10.6
TIBCO est un leader mondial du logiciel, il a intégré le BPMS en 2004 avec
l’acquisition de Staffware, depuis, cette compagnie a intégré son BPM, appelé TIBCO
Iprocess avec sa plate-forme SOA (BusinessWorks & ActiveMatrix). En 2007, TIBCO s’est
engagé dans le développement d’un design BPM unifié et consistant et éventuellement créer
un IDE unifié pour la plate-forme TIBCO basé sur Eclipse, indépendant d’une plate-forme
d’exécution ou d’un langage de programmation. Le premier produit TIBCO est le TIBCO
Business Studio 2.0 [BIO, 08].
IBM WebSphere
IBM est un leader mondial des solutions groupware, Elle a développé IBM Business
Process Management, en le dotant du composant IBM WebSphere Business Modeler, ce
dernier offre des outils pour analyser, modéliser et simuler des processus, d’intégrer de
nouveaux workflow ou des workflow révisés. Il permet aussi de définir et de documenter les
ressources et les organisations. Il offre de plus des fonctionnalités de publication et de
collaboration sur le web [IBM, 08].
On peut citer encore: FlowMind 4.1.7, I-Flow, Webflow, Vdoc Process et W4 3.0.
21
I.7. workflow flexible

I.7.1. Avantages et limites des workflow classiques [WDS, 05]
Le concept de workflow a été introduit pour modéliser et exécuter des procédés
administratifs et de production des entreprises. Toutefois, la rigidité présente l'inconvénient
majeur de ce modèle de workflow :
- Difficulté à gérer les cas particuliers et les exceptions dans les applications administratives
et de production.
- Inadaptation des modèles et systèmes traditionnels à supporter les interactions coopératives
dans les applications créatives.
I.7.2. besoins de flexibilité pour un workflow coopératif

I.7.2.1. besoin de flexibilité du flot de contrôle
Les modèles de workflow actuels imposent des dépendances entre activités du type
fin-démarrage, c'est à dire qu'une activité ne peut pas démarrer tant que l'activité précédente
n'est pas terminée [WDS, 05].
I.7.2.2. Besoin de flexibilité du flot de données

Dans les modèles de workflow traditionnels, l'échange des données entre deux
activités n’est possible que si les deux activités sont connectées par un flot de contrôle. Il est
nécessaire de trouver un nouveau modèle de gestion de flot de données aussi simple à utiliser
et aussi sûr qu'un modèle de transactions traditionnel. Il doit en particulier [WDS, 05]:
- Permettre aux activités de s'échanger des données en cours d'exécution.
- Permettre à des activités situées dans des branches parallèles de modifier les mêmes
données.
- Ne pas imposer que tous les flots de données soient complètement définis à l'avance.
I.7.2.3. Besoin d'augmenter le parallélisme entre processus

Pour augmenter le parallélisme entre un processus et ses sous-processus, les données
résultantes par les activités du sous-processus devraient être mises à la disposition du
processus principal dès qu'elles sont produites [WDS, 05].
22
I.7.2.4. Besoin de support pour l'évolution du modèle

Le passage de l’exécution d’un procédé sans utiliser un support informatique pour la
coordination, à l’exécution contrôlée par un système de workflow est une étape trop grande
pour être effectuée en une seule fois. Son intégration doit être mise en œuvre de façon
graduelle. Un système de workflow peut aider les utilisateurs à faire cette transition de deux
façons [WDS, 05]: - Définition incomplète et modifications dynamiques.
- Analyse et amélioration du procédé.
23
Conclusion
Le caractère innovant de l’introduction de la technologie workflow est le fait
d’aborder l’analyse, l’optimisation et l’automatisation des processus en faisant intervenir
l’ensemble des interactions et les relations de coopération entre les différents intervenants
dans le déroulement du processus.
Le principal intérêt de l’approche workflow est de séparer la modélisation de la

logique de l’entreprise, cela permet en particulier un découpage entre le modèle de procédés
et le modèle organisationnel, ce qui simplifie et améliore la gestion des ressources :
lorsqu’une activité est exécutable, elle est automatiquement rajoutée, avec les ressources, à la
liste des tâches à exécuter des participants dans le processus, qualifier aptes à l’exécuter.
Lorsqu’une tâche est exécutée par un participant, elle est automatiquement retirée des listes
des autres participants
L’inconvénient majeur de ce modèle est sa rigidité, dans les applications

administratives et de production, il s’agit de la difficulté à gérer les cas particuliers et
d’exception. Dans les applications créatives, il s’agit de l’inadaptation des modèles et des
systèmes traditionnels à supporter les interactions coopératives.
L’introduction de technologies permettant de donner plus de flexibilité aux systèmes
traditionnels est devenue inévitable. Les systèmes multi-agents on montré leur efficacité pour
gérer ces aspects. Nous présenterons dans le chapitre suivant la technologie multi-agents.
24
Chapitre II Les Systèmes Multi-Agents (SMA)
Introduction :
Les systèmes multi-agents (SMA) constituent une discipline très récente et très
ouverte, qui n’est pas formalisée de façon consensuelle et exhaustive. Elle est mise au point
dans un but méthodologique dans le domaine de l’intelligence artificielle, elle a ensuite
évolué pour devenir à la fois une méthode de gestion et une technologie de l’ingénierie
logicielle dont le but est de procurer des solutions à des problèmes de la vie réelle
Les SMA s’intéressent aux comportements collectifs produits par les interactions de plusieurs
entités autonomes appelées agents. Cette technique est introduite dans plusieurs domaines à
savoir : l’économie, la médecine, l’ingénierie… Les SMA sont aptes à résoudre des
problèmes très complexes par des procédés relativement simples à mettre en œuvre et de
simuler le fonctionnement des organisations les plus complexes.
Les SMA semblent particulièrement bien adaptés pour la modélisation de la

dynamique de l’organisation des entreprises et pour l’étude des changements organisationnels
qui s’y produisent : l’automatisation et l’amélioration des processus de prise de décision, la
représentation des connaissances d’une manière distribuée, la simulation du fonctionnement
des organisations sont, entre autres, les apports les plus importants des SMA aux
organisations.
Ce chapitre traite les SMA. Après une brève présentation de l’intelligence artificielle
distribuée (IAD), on donnera une vue d’ensemble de la notion d’agent en présentant ses
définitions, ses caractéristiques et ses différentes typologies et architectures, puis nous
exposerons les différents aspects des SMA : leurs définitions, leurs caractéristiques, leurs
typologies, leurs apports et leurs types d’application. Il sera question par la suite d’évoquer les
aspects liés aux interactions et aux protocoles assurant leurs communications. Enfin on
présentera quelques méthodologies de conception des SMA, et quelques plates-formes
d’implémentation de ces systèmes, leurs architectures et les critères à prendre en compte lors
du choix des plates-formes à utiliser pour implémenter les SMA.
25
II.1. Intelligence artificielle distribuée (IAD)

II.1.1. Définitions
« L’intelligence artificielle distribuée (IAD) consiste à distribuer l’expertise au sein
d’une société d’entités appelées ‘Agents’, dont le contrôle et les données sont distribués.
Chaque agent a ses propres compétences mais il a besoins d’interagir avec les autres pour
résoudre des problèmes qui dépendent de son domaine d’expertise, pour éviter les conflits,
etc. l’objectif de l’IAD est donc de trouver une solution à des problèmes globaux grâce à un
ensemble d’entités distribuées, travaillant en collaboration, le comportement de ces entités
peuvent être très simples » [DAM, 96].
II.1.2. Historique de l’intelligence artificielle distribuée

Les premiers travaux qui ont marqué les débuts de l’IAD ont apparus au début des
années 70 avec le système HEARSAY-II, un système de reconnaissance de la parole continue.
Ce dernier est considéré comme le pionnier dans ce domaine, il introduit le concept de tableau
noir (BlackBoard). Un système de tableau noir est constitué d’un ensemble d’entités appelées
sources de connaissances, qui utilisent une zone de données commune le tableau noir.
Les différentes sources de connaissances coopèrent en partageant un tableau noir oû elles
lisent et écrivent des hypothèses. Chaque source de connaissance est spécialisée dans un
domaine donné, et peut modifier ou supprimer des hypothèses [DAM, 96].
La notion d’acteur apparaît peu après avec les travaux de C.Hewitt au MIT dés 1973, un
acteur est une entité informatique qui se compose de deux parties : Une structure qui
comprend l’adresse de tous les acteurs qu’il connaît et à qui il peut envoyer des messages, une
parti active, le script qui décrit son comportement lors de la réception d’un message.
Un acteur est donc une entité autonome, possédant un comportement propre, et
communiquant avec les autres acteurs de son environnement. La solution est le fruit des
interactions entre ces différents acteurs [DAM, 96].
II.1.3. De l’IAD aux systèmes multi-agents

L’intelligence artificielle distribuée conduit à la réalisation de systèmes dits multi-
agents qui permettent de modéliser le comportement d’un ensemble d’entités plus ou moins
expertes, plus ou moins organisées selon des lois de type social [DAM, 96]. Ces entités, ou
agents, disposent d’une certaine autonomie et sont émergés dans un environnement dans
26
lequel, et avec lequel elles interagissent. D’oû leurs structures autour de trois fonctions
principales : celles de percevoir, de décider et d’agir.
Les systèmes multi-agents constituent l’une des branches les plus prometteuses de
l’intelligence artificielle distribuée. Ils peuvent être différenciés suivant plusieurs critères tels
que : le degrés de granularité des agents, leurs nombres et les mécanismes de communication
utilisés, etc. [DAM, 96].
Avant d’aborder les SMA, il est utile d’évoquer quelques notions de base sur les agents, c’est
l’objet des sections suivantes.
II.2. Notion d’agents

II.2.1. Définition
Selon Ferber, « Un agent est une entité autonome, réelle ou abstraite, capable d’agir
sur elle même et sur son environnement, qui dans un univers multi-agent peut communiquer
avec d’autres agents, et dont le comportement est la conséquence de ses observations, de ses
connaissances et des interactions avec les autres agents ». [TOU, 05].
II.2.2. Caractéristiques d’un agent

Tout agent possède quelques unes des caractéristiques suivantes [STR, 02] :
Interaction
L’interaction d’un agent est réalisée avec :
• Le matériel : Des dispositifs spéciaux sont mis en place pour assurer le contrôle des
caractéristiques physiques du matériel. L’information est ainsi reçue via les capteurs, ou
l’émission d’informations à travers les actionnaires.
• Le logiciel : La collaboration des agents avec d’autres applications du service permet
d’automatiser certaines tâches.
• L’être humain : Cette interaction a pour objectif l’authentification, l’échange
d’information, la consultation, la modélisation et la configuration.
• D’autres agents : Cette interaction permet de résoudre des problèmes complexes et
distribués utilisant des ressources communes, et d’améliorer la modularité et la flexibilité.
L’apprentissage
Les agents doivent évoluer et améliorer leurs connaissances, ainsi, adapter ou changer
leurs comportements face à des situations similaires et cela en fonction de leurs expériences
passées. Cette caractéristique est principalement réservée aux agents qualifiés d’intelligents.
27
Raisonnement
Les agents disposent des capacités de raisonnement leurs permettant de suivre
l’évolution des procédures adaptées à leur environnement dynamique, et de calculer des plans
pour prendre en compte les dysfonctionnements et les situations imprévues. Dans son
raisonnement, un agent intègre les éléments suivants :
- La base de faits : Ce sont les nouveaux faits produits par l’analyse des événements ou
l’acquisition d’informations et les faits déduits qui sont des résultats intermédiaires du
processus d’inférence. Cette base de faits peut être vue comme la perception en temps
réel, par l’agent, du monde à un instant T.
- La base de règles : C’est la connaissance de travail fournie à l’agent par son concepteur ou
par l’utilisateur. Pour un agent adaptatif, la base de règles peut être modifiée soit par
l’agent lui-même, soit par des processus externes.
- La structure de contrôle : C’est une structure procédurale du moteur de raisonnement qui
détermine, entre autres, quand réévaluer une règle donnée.
- Les interfaces événements/action : Ce sont des interfaces de programmation par lesquelles
l’agent reçoit des événements et effectue des actions.
Le système de raisonnement fournit un moyen d’appliquer un raisonnement à base de règles
lors de l’apparition de nouveaux faits dans le monde de l’agent et permet d’appliquer cette
capacité de raisonnement pour décider de ce que l’agent doit réaliser par la suite.
Intelligence
Un agent intelligent est celui qui possède des capacités de raisonnement et
d’apprentissage, ou des capacités de représentation symbolique des fonctions cognitives. Il
doit adopter des buts qu’il croit réalisables et abandonner ceux qu’il croit irréalisables. Il a la
faculté de raisonner, d’apprendre et d’accepter les demandes de l’utilisateur. L’agent devrait
comprendre ce que l’utilisateur veut, et planifier les moyens à mettre en œuvre pour atteindre
ce but. L’agent doit non seulement planifier ses propres actions, mais aussi tenir compte de
celles des autres agents.
L’autonomie
D’après Demazeam et J-P.Muller, un agent autonome est un agent dont l’existence ne
se justifie pas par l’existence des autres agents et de l’opérateur humain. Il possède certains
états inaccessibles aux autres agents.
Pour être autonome, un agent doit avoir ses propres buts et être capable de prendre des
décisions, et ainsi résoudre des conflits internes.
28
La réactivité
L’agent doit pouvoir réagir aux modifications de l’environnement, dans le temps
requis, que ce soit la modification des objectifs ou des ressources disponibles.
Planification
C’est le processus qui permet la construction d’un plan d’actions à réaliser pour
atteindre un certain but, le plan est constitué d’intentions, d’engagement et de croyances su
l’environnement qui entour l’agent.
Prise de décision
C’est le choix auquel est confronté l’agent pour sélectionner le but à satisfaire en
premier, et pour chaque but, l’action qui permet de l’atteindre.
II.2.3. Typologie des agents

Il existe deux grandes tendances de typologie des agents qui sont [TOU, 05] :
II.2.3.1. Les agents réactifs
L’école réactive considère qu’il n’est pas nécessaire que les agents soient intelligents
individuellement pour que le système ait un comportement global intelligent. Elle suppose
que les agents sont très simples et que l’intelligence émerge de l’interaction entre ces agents.
Un agent réactif est donc un agent très simple et ne possédant pas de représentation explicite
de son environnement, ni de capacité de raisonnement, et dont le comportement est primitif et
ne consiste en général qu’à répondre à la loi stimulus/action, c'est-à-dire qu’il réagit en
fonction des événements qui lui arrivent. Les agents sont fortement couplés et disposent d’un
protocole de communication réduit. La figure II-1 représente l’architecture d’un agent réactif.
Module compétence (2)

Exploration de
l’environnement
Nœud de suppression Nœud d’inhibition

Composante Composante
Perception Module compétence (1) Exécution
Entrée Déplacement dans
Sortie
l’environnement
Module compétence (0)

Eviter les obstacles
Figure II-1 : Architecture d’un agent réactif [TOU, 05]
29
Cette figure montre qu’un agent réactif comporte plusieurs modules, chaque module
étant responsable de la réalisation d’une tâche simple. Ces modules correspondent à des
comportements spécifiques pour accomplir une tâche particulière, et s’appellent modules de
compétence.
II.2.3.2. Les agents cognitifs

Ils sont plus ‘intelligents’ et plus complexes. Ils peuvent se construire une
représentation de l’environnement. Ils possèdent une base de connaissance et ils sont capables
de raisonner, ils peuvent tenir compte de leur passé et ainsi anticiper sur l’avenir pour
planifier leurs actions. Ils peuvent aussi connaître les états des autres agents.
L’agent doit élaborer un plan d’actions en fonction des connaissances et des croyances dont il
dispose, et des buts qu’il se fixe suite à une perception ou à une interaction avec le monde
extérieur (l’environnement ou les autres agents). Pour cela, il doit décider du but à retenir et à
satisfaire en premier, planifier en fonction de ce but et passer à l’exécution. BDI est
l’architecture la plus connue des agents cognitifs (Voir figure II-2).
B = Revc (B, P)
Croyances Révision des
croyances
Analyseur
opportunité
Procès de décision
Perceptions
I = Options (D, I)
Raisonnement Intentions Désirs
modulaire
D = Des (B, D, I)
Filtre
I = Filtre (B, D, I)
Lib P Intentions structurées

dans plans partiels
PE = Plan (B, I)
Plans Exécution Actions
Figure II-2 : Architecture BDI d’un agent [TOU, 05]
30
B : Belief (Croyances) : Ce sont les informations que l’agent possède sur l’environnement et
sur les autres agents qui existent dans le même environnement. Les croyances peuvent être
incorrectes, incomplètes ou incertaines, elles sont différentes des connaissances de l’agent,
qui sont des informations toujours vraies. Les croyances peuvent être changées au fur et à
mesure que l’agent, par sa capacité de perception, ou par l’interaction avec d’autres agents,
recueille plus d’information.
D : Desire (Désirs) : Ce sont les états de l’environnement, et parfois de lui-même, que l’agent
aimerai voir réalisés. Un agent peut avoir des désirs contradictoires, dans ce cas il doit choisir
parmi ses désirs, un sous-ensemble qui soit consistant. Ce sous-ensemble consistant de ces
désirs est parfois identifié avec les buts de l’agent.
I : Intention (Intention) : Ce sont les désirs que l’agent a décidé d’accomplir ou les actions
qu’il a décidé de faire pour accomplir ses désirs. Même si tous les désirs d’un agent sont
consistant, l’agent peut ne pas être capable d’accomplir tous ses désirs à la fois.
Remarques
Des architectures hybrides existent, elles combinent les caractéristiques des architectures
cognitives et des architectures réactives.
Un agent mobile est autonome et capable de se déplacer entre les différents
environnements d’exécution des machines hôtes d’un réseau, à condition de prévoir des
mécanismes d’accueil pour l’agent sur l’hôte qui le reçoit. Telescript de General Magic
est connu pour être la première implémentation commerciale des agents mobiles. Le plus
connu des projets du monde Java, pour les agents mobiles nous vient de chez IBM Japon,
il s’agit d’Aglets (Agent Applets) [AMB, 99]
II.2.4. Etats d’un agent

A chaque moment, l’agent dispose d’un état qui nous permet de déterminer sa position
qui nous permet de déterminer sa position dans son cycle de vie [SGW, 05].
A l’état initial, l’agent se trouve à l’état dormant, il transite à l’état actif à la suite d’un
message reçu d’un autre agent qui possède son modèle. A la fin du traitement, l’agent passe à
l’état attente d’un message ou d’une requête d’un autre agent. Si au bout d’un certain temps,
l’agent ne reçoit pas de messages, il repasse à l’état dormant. La figure II-3 présente les
différents états par lesquels passe un agent.
31
Requête ou arrivée d’un message
Fin d’exécution d’une requête Attente

Actif
Délai
Réception d’un message Attente d’une requête ou

d’un message
Dormant
Figure II-3 : Les différents états d’un agent [SGW, 05]
II.3. Les systèmes multi-agents

II.3.1. Définition
« Les systèmes multi-agents consistent à gérer une société d’entités autonomes
appelées agents, qui peuvent s’organiser de façon à résoudre des problèmes, réaliser des
tâches, et de manière générale, produire des phénomènes globaux qu’aucun agent ne peut
réaliser ou pas avec la même efficacité individuellement. Les SMA utilisent la métaphore
sociale que ce soit celle des insectes dits sociaux quand les agents sont réactifs (SMA réactifs)
ou des organisations humaines quand les agents sont cognitifs » [MUL, 02].
Moi
Objectifs Lui
Environnement
Communication
Agent Agent
Perception
Ressources Action
Objets de l’environnement
Figure II-4 : Organisation d’un système multi-agents [FER, 95]
32
La figure II-4 montre que trois paramètres régissent l’organisation et le

fonctionnement des sociétés d’agents : la distribution des tâches et des contrôles, les modes et
les protocoles de communication, les modes d’organisation et de coopération.
II.3.2. Caractéristiques des SMA

Les systèmes multi-agents sont, généralement caractérisés par [AMB, 99] :
- Les agents agissent et travaillent indépendamment les uns des autres.
- Chaque agent est une partie intégrante du système.
- Chaque agent travaille dans le but d’accomplir ses tâches.
- Chaque agent est capable de communiquer et d’interagir avec d’autres agents.
- Un agent coopère avec les autres agents lorsque c’est nécessaire.
- Un agent est capable de coordonner ses activités avec les autres agents pour accéder à des
ressources et à des services dont il a besoins pour réaliser ses tâches.
- Les agents peuvent avoir des buts communs, chaque agent a une vue partielle du système.
II.3.3. Apports des SMA

Les apports les plus importants des systèmes multi-agents sont résumés comme
suit [AMB, 99]:
- L'automatisation et l'amélioration des processus de prise de décisions.
- La décentralisation d’un système en sous-systèmes coopératifs.
- La réutilisation par la création de nouveaux systèmes en interoperant avec ceux déjà
existants.
- La représentation des connaissances d’une manière distribuée.
- La simulation des fonctionnements des organisations, comme ils sont utilisés pour simuler
de nombreux mécanismes afin de vérifier les hypothèses des nombreuses recherches.
33
II.3.4. Typologies d’applications SMA

Les SMA connaissent une grande expansion, et ont concerné de nombreux domaines,
Jacques Ferber se propose de classer les types d’applications de SMA ainsi :
Résolution
distribuée de
problèmes
Résolution de Résolution
problèmes distribuée de
problèmes
Simulation distribués
Multi-agents
Résolution par
coordination
Système Construction de
Multi-agents mondes
synthétiques
Robotique
distribuée
Conception
kenetique de
programmes
Figure II-5 : Classification des types d’applications de SMA [FER, 95]
On s’intéresse dans cette section à la typologies d’application de résolution de problèmes,

ça concerne en fait toutes les situations dans lesquelles des agents logiciels accomplissent des
tâches utiles aux êtres humains. Elle englobe trois types d’applications [FER, 95] :
Résolution distribuée de problèmes
L’expertise globale est distribuée parmi l’ensemble des agents, chacun n’ayant qu’une
compétence restreinte par rapport à l’ensemble du problème à résoudre. Ces agents disposent
d’une compétence complémentaire et coopèrent entre eux pour résoudre un problème général
tel qu’un diagnostic médical, la conception d’un produit industriel, l’acquisition de
connaissances…
Résolution distribuée de problèmes distribués
Le problème est distribué et les agents peuvent avoir des compétences semblables. Il
s’agit essentiellement d’applications telles que l’analyse, l’identification, le diagnostic et la
commande de systèmes physiquement repartis, pour lesquels il est difficile d’avoir une vision
totalement centralisée.
34
La surveillance de réseaux de télécommunication dans lesquels la supervision est repartie sur

chacun des nœuds constitue un bon exemple de résolution distribuée de problèmes distribués.
Résolution par coordination
Dans ce cas, le domaine n’est pas distribué et l’expertise ne l’est pas non plus. Les
agents peuvent servir d’une manière beaucoup plus élémentaire à résoudre des problèmes au
sens classique du terme, c’est-à-dire, à tenter de trouver une solution à quelque chose dont
l’énoncé est bien posé et dont l’ensemble des informations est entièrement disponible.
II.4. Les interactions et les protocoles de communication dans les SMA

II.4.1. Les interactions dans les SMA
D’après Ferber : « Une situation d’interaction est un ensemble de comportements
résultants 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 » [THO, 05].
La notion d’interaction constitue l’essence d’un système Multi-Agents puisque c’est
grâce à elle que les agents vont pouvoir produire des comportements collectifs complexes et
dépendants les uns des autres. Ces interaction entre agents sont motivées par
l’interdépendance des agents selon ces trois dimensions [WDS, 05] :
- Leurs buts peuvent être compatibles ou non.
- Les agents peuvent désirer des ressources que les autres possèdent.
- Un agent X peut disposer d’une capacité nécessaire à un agent Y pour l’accomplissement
d’un des plans d’actions de Y.
En général les interactions sont mises en œuvre par un transfert d’informations entre
agents ou entre l’environnement et les agents, soit par perception, soit par communication.
L’interaction peut être décomposée en trois phases non nécessairement séquentielles [THO,
05]: - La réception d’information ou la perception d’un changement.
- Le raisonnement sur les autres agents à partir des informations acquises.
- Une émission de messages ou plusieurs actions modifiant l’environnement.
Ferber a proposé une classification des situations d’interaction selon plusieurs critères
en distinguant trois situations : 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
II.4.1.1. La coordination
La coordination permet aux agents, d’une part, de s’inspirer de certains résultats des
autres agents, et d’autre part, d’éviter de refaire un travail qui a été déjà fait par un autre agent
[FER, 95].
II.4.1.2. La coopération
La coopération est une attitude adoptée par les agents qui décident de travailler
ensemble. Elle permet à un agent de [FER, 95] :
- Mettre à jour les connaissances globales du système.
- Intégrer des informations venant d’autres agents.
- Interrompre son plan d’exécution pour aider les autres agents.
- Déléguer la tâche qu’il ne sait pas résoudre à un autre agent dont il connaît les
compétences.
II.4.1.3. La communication
La communication est un point fondamental des systèmes multi-agents, elle n’est pas
réduite à un système d’échange de données, mais il s’agit d’un acte intentionnel qui se traduit
par une modification de la connaissance des agents. Il faut donc savoir quoi, quand et avec qui
communiquer [FER, 95]. Il existe deux modèles de communication [MTC, 03] :
Communication par partage d’information (Tableau noir)

Les agents ne sont pas en liaison directe et n’ont pas une vue globale du problème, ni
de l’état global de la solution, ils réagissent uniquement aux informations auxquelles ils ont
accès et ne peuvent pas raisonner sur leurs coopérations avec les autres agents. Ils
communiquent via une structure de données partagée considérée comme une mémoire
globale, et donc accessible à tous les agents ces derniers y accèdent pour y déposer des
informations et / ou y prendre celles qui leurs sont destinées. Des mécanismes de contrôle
sont mis en place pour gérer les accès au tableau noir.
L’agent, appelé source de connaissance, est constitué de deux parties :
- La partie condition : Indique les conditions qui doivent figurer dans le tableau noir
pour être activé.
- La partie action : Spécifie les actions à effectuer une fois l’agent est activé.
36
La zone commune, divisée en niveaux d’abstraction, est appelée le tableau noir. Ce

dernier contient une description de l’état de la solution sous forme d’entités appelées faits,
hypothèses ou nœuds. Il sert à partager les données entre les agents.
Le mécanisme de contrôle : Ce mécanisme supervise les changements qui surviennent
dans le tableau noir et décide des actions à effectuer à la prochaine étape. Il gère les
conflits d’accès aux ressources du tableau noir entre les agents.
Remarque : Les systèmes multi-agents basés sur ce mode de communication entre les agents
sont appelés ‘SMA à contrôle centralisé’.
Communication par envoi de messages

Les échanges entre les agents se font par envoi de messages suivant un protocole bien
défini, les connaissances et les contrôles se retrouvent ainsi distribués. Deux modes de
transmission sont possibles :
- Transmission point à point : L’agent émetteur connait et précise l’adresse de (ou des)
agent (s) destinataire (s).
- Transmission par diffusion : Le message est envoyé à tous les agents du système.
Dans ce mode de communication, tout agent contient les adresses des agents à qui il
peut envoyer des messages, et un script (Ensemble de méthodes), qui définit son
comportement lors de l’arrivée de messages venant de l’extérieur : l’agent filtre ces messages
reçus et active les méthodes appropriées.
Remarque : Les systèmes multi-agents basés sur ce mode de communication entre les agents
sont appelés ‘SMA à contrôle distribué’.
II.4.2. Les langages de communication dans les SMA

Dans un SMA cognitif, les agents doivent disposer d’un langage commun pour
pouvoir échanger les informations et coopérer leurs actions pour la résolution d’un problème.
Ce langage est un ensemble de primitives connues par chaque agent, il permet donc de
structurer et d’uniformiser les interactions inter-agents. Les primitives de base d’un langage
de communication peuvent être résumées en ces points [MTC, 03] :
- Etablissement d’une connexion entre deux entités.
- Identification du nœud destinataire.
- Envoi de données.
- Réception des données.
- Définition d’un type de communication (Synchrone, Asynchrone).
37
Il existe plusieurs types de protocoles de communication, les plus connus sont :

II.4.2.1. Knowledge query and manipulation language (KQML)
Initialement prévu comme moyen d’échange d’informations entre programmes à base
de connaissance, sa structure orientée message et la généricité de ses primitives lui permettent
d’être utilisé comme ACL (Agent Communication Language). Ses performatifs (actes
communicatifs) sont divisés en trois catégories [KIF, 07]:
- Sept (7) performatifs de régulation de conversation : Traitent quelques cas particuliers
(Sorry, Error…), et permettent quelques variantes de la conversation (Standby, Ready, Next,
Rest, Discard,…).
- Dix Sept (17) performatifs de discours : Permettent l’échange d’information et des
connaissances (Ask-If, Tell, Deny, Stream-All,…).
- Onze (11) performatifs d’assistance et de réseau pour étendre la conversation à plus de
deux agents (Forward, Broker-All,…).
II.4.2.2. Foundation for Intelligent Physical Agents (FIPA-ACL)

C’est un langage de communication indépendant de la syntaxe et de la sémantique
(ontologie) du contenu. Il est aussi indépendant du mécanisme de transport des messages
(TCP/IP, SMTP, IIOP, HTTP), des protocoles de haut niveau utilisés pour la communication
(REQUEST, QUERY) et la negociation (CONTRACT-NET) [MTC, 03].
Les spécifications de FIPA-ACL se composent d’un ensemble de types de messages et de la
description normative d’un ensemble de protocoles d’interaction de haut niveau, y compris la
demande d’action, l’établissement de contrats et plusieurs mécanismes d’enchère.
FIPA-ACL possède 22 actes communicatifs, exprimés par des performatifs. Les actes
communicatifs peuvent être primitifs, c'est-à-dire qu’ils ne sont pas définis à partir d’autres
actes, ou composé d’un ensemble d’actes. Ces performatifs sont divisés en cinq catégories
[WDS, 05] :
- Cinq (5) performatifs de passage d’information : Inform, Inform-if, Inform-ref, Confirm,
Disconfirm.
- Trois (3) performatifs de requisition d’information : Query-if, Query-ref, Subscribe.
- Quatre (4) performatifs de negociation : Accept-proposal, Cfp, Propose, Reject-proposal.
- Huit (8) performatifs de distribution ou d’execution d’une action : Request, Request-
when, Request-whenever, Agree, Cancel, Refuse, Propagate, Proxy.
- Deux (2) performatifs de manipulation des erreures : Failure, Not-understood.
38
II.4.2.3. Autres langages

Il existe une multitude d’autres langages comme : ARCOL (ARtimis Communication
Language), ICL (InterAgent Communication Language), AOP (Agent Oriented
Programming) et MAC (Mobil Agent Communication).
II.5. Les méthodologies de conception des SMA

Plusieurs méthodologies ont été proposées pour guider les concepteurs dans leur tâche
d’analyse et de conception. Pour cela, les notions de rôle, d’interaction et d’organisation sont
souvent mises en avant, pour faciliter la décomposition et la description de systèmes
complexes distribués. La figure II-6 illustre les méthodologies les plus connues :
Méthodologies orientées agents
Méthodologies centrées Méthodologies issues des Méthodologies issues de

sur les agents méthodologies orientées l’ingénierie des connaissances
objet
Prometheus ODAC MAS-CommonKADS

Tropos MaSE CoMoMas
SODA MASSIVE
Gaia DESIR
Voyelles AOEM
Figure II-6 : Les méthodologies orientées Agents [LAB, 06]
II.5.1. Méthodologies centrées sur les agents [LAB, 06]

Ces méthodes sont caractérisées par la prise en compte des concepts du paradigme
agent dés la phase d’analyse du système. Parmi ces méthodes on peut citer :
• La méthode Gaia
Elle contient cinq modèles répartis en deux phases :
La phase d’analyse : Elle produit deux modèles :
- Le modèle de rôle : identifie les principaux rôles du système.
- Le modèle d’interaction : C’est un ensemble de définitions de protocoles
d’interaction.
La phase de conception : Le processus de conception se base sur les trois modèles
suivants :
39
- Le modèle d’agent : Identifie les agents du système en les associant aux différents
rôles.
- Le modèle de services : Identifie les principaux services nécessaires pour
accomplir les rôles des agents.
- Le modèle d’accointance : Définit les liens de communication entre les agents.
• La méthodologie Voyelles
Pour un problème à résoudre (ou un système à simuler) dans un domaine donné,
l’utilisateur choisit le modèle d’agent, le modèle d’environnement, le modèle d’interaction et
le modèle d’organisation. Cette méthodologie est composée de trois phases [PIC, 04]:
La phase d’analyse : permet d’identifier et de décomposer le problème en quatre
composantes fondamentales, pour dégager l’architecture générale du système.
- Les agents (A) : Définir les éléments nécessaires à la construction des agents à
savoir leur modèle, leur architecture, leur implémentation...
- L’environnement (E) : Dans un système multi-agents, on appelle environnement
l’espace commun aux agents du système. Ça consiste donc à trouver les éléments
nécessaires à la réalisation des interactions extérieures au système comme par
exemple la perception de cet environnement, les actions que l’on peut y faire.
- Les interactions (I) : Les interactions proviennent de la mise en relation dynamique
de plusieurs agents par le biais d’un ensemble d’actions réciproques. Il existe
plusieurs types d’interactions, qui dépendent de trois paramètres que sont les buts,
les ressources et les compétences.
- L’organisation (O) : C’est une structure décrivant les interactions et autres
relations qui existent. L’organisation peut donc apparaître comme une structure de
coordination et de communication.
La phase de conception : Elle permet de choisir les modèles opérationnels des
composantes pour aboutir à la spécification du fonctionnement global du système
exprimé sous forme de diagramme de comportements.
La phase d’implémentation : Elle consiste en l’instanciation des modèles, en utilisant
des plates-formes et des langages choisis. Le système implémente peut alors être
exécuté, évalué (test et validation) et repensé en cas d’inadéquation avec les besoins
exprimés par le type de problèmes et de domaine d’application.
40
II.5.2. Méthodologies issues des méthodologies orientées objet [LAB, 06]

• La méthode AOEM (Agent Oriented Methodology for enterprise Modelling)
Le processus de modélisation est constitué de quatre étapes successives qui sont:
- Identification et description des fonctions du système par la conception de
diagrammes IDEFO (Décomposition hiérarchique et fonctionnelle), ainsi elle identifie
les agents du système.
- Transformation des diagrammes IDEFO en utilisant la notation des cas d’utilisation.
- Description des interactions entre les cas d’utilisation et entre les acteurs et les cas
d’utilisation.
- Conception du système multi-agents.
• La Méthode MaSE (Multi-Agent Systems Engineering)
Les étapes associées à cette méthodologie sont les suivantes:
- Identification des buts du système afin de les structurer et de les représenter sous
forme d’une hiérarchie.
- Identification des rôles et leurs interactions en utilisant le diagramme des cas
d’utilisation pour définir le comportement général du système, ses fonctionnalités, son
environnement (utilisateurs et acteurs) et les rôles du système, et le diagramme de
séquences pour représenter les messages échangés entre rôles.
- Identifier la décomposition fonctionnelle du système en utilisant les rôles et les tâches
concurrentes. Chaque rôle correspond au moins à un but auquel s’ajoute un ensemble
de tâches correspondantes. Lors de la création des modèles de rôles, les interactions
entre les rôles sont définies en connectant les tâches entre elles. Le model de tâches
concurrentes permet de représenter, à l’aide d’automates à états finis, les tâches
réalisées par les rôles pour l’accomplissement de leurs buts respectifs.
- Identifier le système multi-agents par la description des architectures d’agents et de
leurs liens conversationnels. Une classe d’agent précise leurs rôles assignés.
- Définir les protocoles de coordination entre deux agents en expliquant les
comportements des agents durant la conversation.
- Spécifier l’architecture interne des agents.
- Conception du système en spécifiant la distribution des agents selon l’architecture
physique du système.
41
II.5.3. Méthodologies issues de l’ingénierie des connaissances [LAB, 06]

• La Méthode MAS-CommonKADS
Elle commence par la conceptualisation, oû l’utilisateur spécifie les besoins et les
caractéristiques du système, ensuite viennent les deux phases d’analyse et de conception
du SMA qui produisent les modèles suivants :
- Le modèle d’agent: Décrit les capacités et les caractéristiques des agents
(Raisonnement, connaissances, buts, services,…).
- Le modèle de tâches : Décrit les tâches de chaque agent (Ses buts), ainsi que la
composition des tâches et les méthodes de résolution de problèmes.
- Le modèle d’expertise : Décrit les connaissances des agents pour la réalisation des
tâches. La modélisation des connaissances est basée sur l’utilisation de KADS.
- Le modèle de coordination : Décrit les interactions entre agents et les capacités
conversationnelles en utilisant un langage de communication agent.
- Le modèle d’organisation : Décrit l’organisation du système Multi-Agent.
- Le modèle de communication : Décrit l’interaction entre les utilisateurs et les agents
pour le développement d’interfaces adaptées.
- Le modèle de conception : Décrit le système Multi-Agent sur la base des modèles
précédents et se décompose en trois étapes: Conception du réseau d’agent, choix de
l’architecture d’agent et la sélection de la plate forme de développement d’agents.
• La methode CoMoMAS
Elle utilise la syntaxe de CML (Conceptual Modelling Language) pour décrire ses
différents modèles qui sont :
- Le modèle d’agent : Décrit l’architecture et la structure des connaissances des agents.
C’est le principal modèle.
- Le modèle d’expertise : Décrit les compétences cognitives et réactives des agents.
- Le modèle de coopération : Décrit la coopération entre agent, en utilisant les méthodes
de résolution des conflits.
- Le modèle de tâches : Décrit la décomposition des tâches du système et indique si ces
tâches sont exécutées par un humain ou un agent informatique.
- Le modèle du système : Définit les aspects organisationnels de la société des agents et
leurs aspects architecturaux.
- Le modèle de conception : Intègre les modèles précédents dans un système global. Il
décrit les différentes exigences pour la conception.
42
II.6. Les plates-formes multi-agents

Le meilleur moyen pour construire un SMA est d’utiliser une plate-forme multi-
agents. Une plate forme multi-agents est un ensemble d’outils nécessaires à la construction et
à la mise en service d’agents au sein d’un environnement spécifique. Ces outils peuvent
également servir à l’analyse et au test de SMA ainsi créé [MTC, 03]. Ces outils peuvent être
sous la forme d’environnements de programmation (API) et d’applications permettant d’aider
le développeur, les bibliothèques servent en fait à l’implémentation des comportements
d’agents. Il existe actuellement de nombreuses plates-formes multi-agents [MTC, 03]. On
s’intéresse dans cette section à deux plates-formes qui sont largement utilisées :
II.6.1. La plate forme Jade (Java Agent Developement framework) [MTC, 03]
C’est une plate-forme multi-agents créée en 1999 au laboratoire TILAB (Telecom
Italia Laboratory). Elle permet le développement de systèmes multi-agents et d’applications
conformes aux normes FIPA. Jade est implémentée en JAVA et fourni des classes qui
implémentent ‘Jess’ (Java Expert System Shell). Pour la définition du comportement des
agents, Jade possède trois modules principaux nécessaires aux normes FIPA. Ils sont lancés à
chaque démarrage de la plate-forme :
• DF « Directory Facilitator » fournit un service de « pages jaunes » à la plate-forme.
• ACC « Agent Communication Channel » gère la communication entre les agents.
• AMS « Agent Management System » supervise l'enregistrement des agents, leur
authentification, leur accès et l'utilisation du système.
L’interface est implémentée comme un agent appelé RMA (Remote Monitoring Agent), Jade
utilise le protocole IIOP pour connecter d’autres plates-formes.
Jade utilise Behavior pour modéliser les taches qu’un agent peut exécuter, et les agents
instancient leurs comportements selon leurs besoins et leurs capacités. Les messages internes
sont transférés, codés comme des objets java et non comme des chaînes de caractères.
II.6.2. La plate forme Jack [MTC, 03]

Jack est décrite comme étant un environnement pour construire, exécuter et intégrer
des systèmes multi-agents commerciaux, écrite en Java et utilisant une approche orientée
composants. Elle est développée par la société australienne Agent Oriented Software Pty. Ltd.
Les agents sont basés sur le modèle BDI (Belief, Desire, Intention) développés à l’Australian
Artificial Intelligence Institute (AAII). Les outils logiciels sont le JDE (Jack Development
43
Environment), un environnement de programmation graphique, le compilateur du Jack Agent

Language (JAL), qui traduit les programmes écrits en JAL en Java pur, et la librairie de
classes permettant l’exécution des agents, appelée Jack Agent Kernel.
La particularité de Jack est sa forte orientation vers la programmation agent, ce qui mène à
une grande mobilité, étant surtout focalisée sur l’aspect BDI, Jack n’utilise pas de langage de
communication entre agents.
II.7. Architecture des plates-formes multi-agents

L’architecture est basée sur la coexistence de plusieurs machines virtuelles java
(JVM), et la communication se fait par la méthode RMI (Remote Method Invocation) de java
entre machines virtuelles différentes. Chaque machine virtuelle est un réceptacle d’agents qui
fournit un environnement d’exécution complet pour l’exécution des agents et permet d’avoir
plusieurs agents qui s’exécutent simultanément sur un même hôte [WDS, 05].
Chaque réceptacle d’agents est un environnement multi-threads d’exécution composé d’un
thread d’exécution pour chaque agent et, en plus, des thread créés à l’exécution pour le
système RMI pour envoyer des messages. Un réceptacle spécial joue le rôle de frontal de la
plate-forme, il contient les agents de gestion et représente la plate-forme toute entière pour le
monde extérieur [WDS, 05].
II.8. Critères de choix de plates-formes multi-agents

Le choix d’une plate-forme multi-agents pour implémenter un système multi-agents
peut être basé sur deux critères [MTC, 03]:
II.8.1. Critères généraux
- Facilité d’apprentissage de l’outil et disponibilité de la documentation.
- Simplicité de l’implémentation.
- Génération automatique de code.
II.8.2. Critères spécifiques

- Standardisation et gestion de l’interaction (la communication satisfait-t- elle la norme
mise en place par la FIPA ?).
- Des agents prédéfinis du niveaux méta (Ex : Agents d’annuaire déjà implémentés sous
forme de services).
44
Conclusion
Le principe qui fait la force des SMA est de partager les tâches à réaliser entre
plusieurs entités appelées ‘agents’ qui travaillent en collaboration pour atteindre un objectif
commun. La solution globale est la coordination et le regroupement des solutions partielles
des agents, un principe qui s’applique parfaitement aux différents processus existants au
milieu de plusieurs organisations.
Les SMA considèrent que l’action et l’interaction sont les éléments moteurs de la
structuration d’un système dans son ensemble. Le système est alors fiable : la panne d’un
sous-système n’entrave pas le fonctionnement de l’ensemble, de plus le système est
extensible : l’adjonction d’un nouveau sous-système se fait de façon naturelle.
Le processus de développement des systèmes multi-agents n'est pas encore

complètement opérationnel : c’est un domaine qui fait l’objet de plusieurs recherches afin
d’étendre son utilisation à plusieurs disciplines, mais on peut commencer à développer des
applications multi-agents avec les premières versions de ces environnements.
45
Chapitre III La radiologie médicale
Introduction
L’hôpital a pour mission première de donner des soins à des patients, composé de
plusieurs types d’unités avec des fonctions distinctes : unités de soins, services administratifs,
services medico-techniques, pharmacie, services logistiques.
Le service de radiologie constitue le centre d’intérêt des unités de soins, pratiquement

toutes les unités lui font appel pour assurer leurs fonctionnalités. C’est une structure complexe
qui ne peut correctement fonctionner que s’il existe une communication et une coopération
entre les différents acteurs afin de traiter au mieux les patients. Ce service utilise plusieurs
techniques faisant appel aux moyens informatiques : échographie, scanner, imagerie par
résonance magnétique…etc. Ces derniers interviennent pour faciliter les activités
administratives et médicales du service.
Dans ce chapitre, il s’agit de présenter la radiologie médicale et les techniques

informatiques introduites dans son activité : système d’information hospitalier (SIH), système
d’information radiologique (SIR) et système d’archivage et de communication d’images
(PACS) tout en passant par la présentation du dossier patient informatisé, par la suite on
parlera de l’ntégration des PACS et des SIR aux SIH, on évoquera par la suite deux
technologies très récentes dans la pratique médicale : télémédecine et téléradiologie, et enfin
on procédera à la présentation du système d’aide à la décision médicale ainsi que son impacte
sur l’amélioration de la pratique médicale.
46
III.1. L’imagerie médicale

III.1. Définition
« L’imagerie médicale regroupe l’ensemble des techniques utilisées par la médecine
pour le diagnostic, mais aussi le traitement d’un grand nombre de pathologies. Elle a
révolutionné la médecine en donnant un accès immédiat et fiable à des informations
jusqu’alors ‘invisibles’ au diagnostic clinique, comme par exemple aux caractéristiques
anatomiques des organes » [RAT, 90].
III.1.2. Concepts fondamentaux de l’imagerie digitalisée

Le développement des techniques d’imagerie médicale, en particulier, d’imagerie
digitale, a profondément modifié la pratique médicale de ces dernières années. La
scintigraphie, la tomodensitométrie axiale (Scanner), et l’imagerie par résonance magnétique
(IRM), sont les exemples parmi les plus significatifs. Mais de multiples techniques peuvent
maintenant bénéficier de procédures d’acquisition digitales comme l’échographie et plus
récemment la radiologie conventionnelle.
Les films traditionnels peuvent être remplacés par des supports magnétiques ou des disques
optiques numériques (DON) ou optomagnétiques et les négatoscopes par des écrans vidéo
haute résolution. Finalement les images digitales se prêtent bien à des méthodes de traitement
et d’analyse automatiques permettant d’en améliorer la qualité et éventuellement d’aider le
clinicien à leur interprétation [TIM, 91].
Dans le cas du scanner comme celui de l’IRM, les capacités de calcul de l’ordinateur
sont déterminantes dans le processus de formation des images. Contrairement aux techniques
d’imagerie conventionnelle, c’est en effet l’ordinateur qui construit l’image selon un
traitement mathématique bien définit. Les images peuvent être calculées plutôt que mesurées,
et l’on peut stocker et transmettre sur des réseaux de communication n’importe qu’elle image
numérisée. Quelques paramètres permettent de caractériser la qualité des images obtenues :
- La résolution spatiale : mesure la capacité à distinguer les points d’un objet. Elle
correspond au nombre de pixels par unité de surface de l’image.
- La résolution de contraste : mesure l’aptitude à distinguer de petites différences
d’intensité. Elle correspond au nombre de bits par pixel.
- La résolution temporelle : mesure le temps nécessaire pour créer une image. Une
application temps réel exige une génération de 30 images par seconde [TIM, 91].
47
III.1.3. Application de l’informatique en imagerie médicale

Les fonctions associées aux techniques de gestion informatique des images peuvent
être regroupées en plusieurs catégories qui comprennent l’acquisition des données de base, le
traitement des données, y compris la reconstruction d’images, l’affichage, la transmission et le
stockage de l’image. Bien que certains traitements soient communs, les deux premières
fonctions sont plus spécifiques du mode d’imagerie concerné [TIM, 91].
Après la mémorisation des données, l’ordinateur affiche l’image reconstruite. Les

procédures de reconstruction varient d’une technique à l’autre, mais mettent toujours en jeu
une manipulation très importante de l’information disponible. La qualité finale de l’image
dépend de la taille des pixels, du codage des niveaux de gris et de la nature et de la
sophistication de l’algorithme de reconstruction. L’informatique fournit des aides à l’analyse
des images qui facilitent le repérage et l’extraction de régions d’intérêt.
La digitalisation des images présente deux ordres d’avantages qui méritent d’être
soulignés : La pérennité de l’information est assurée. Les supports informatiques assurent une
meilleure qualité de conservation que le support traditionnel, l’archivage ne se dégrade pas au
cours du temps. Les images sont accessibles sur n’importe quel terminal approprié, sur place
ou en un autre lieu, sans dégradation. Ces fonctionnalités sont assurées par les systèmes
d’archivage et de communication d’images : PACS (voir section III.4) [TIM, 91].
III.2. Les systèmes d’information hospitaliers (SIH)

III.2.1. Définition
« On entend habituellement par système d’information hospitalière (SIH), un système
informatique destiné à faciliter la gestion de l’ensemble des informations médicales et
administratives d’un hôpital » [TIM, 91].
Un SIH permet d’améliorer la qualité des soins tout en permettant une gestion plus rationnelle
de l’activité médicale. Les autorités de tutelle peuvent espérer d’un SIH une meilleure
connaissance de l’activité hospitalière et des besoins de santé de la population ainsi qu’un
moyen de parvenir à une maîtrise plus rationnelle des coûts.
48
III.2.2.Objectifs principaux du SIH [BEN, 02]

Parmi les nombreux objectifs des systèmes d’information hospitaliers on peut citer :
- Amélioration de la qualité de service aux patients.
- Permettre la gestion rationnelle et l’évaluation de l’activité médicale.
- Porter à la connaissance des autorités de la tutelle une meilleur connaissance de l’activité
hospitalière et des besoins de santé de la population.
- Faciliter la communication entre les hospitaliers et leur environnement extérieur.
- Réduire les délais d’attente avec une disponibilité de l’information.
- Parvenir à maîtriser les coûts.
- Partage de l’information et aide à la décision.
III.2.3. Le dossier patient informatisé

« Le dossier du malade est la mémoire dans laquelle sont consignées toutes les
information nécessaires à la prise en charge et à la surveillance d’un patient. Il ne se résume
pas à l’observation écrite du médecin ou une note de l’infirmière. Il englobe tout ce qui peut
être mémorisé chez un malade, des enregistrements démographiques electro-physiologiques
aux images les plus sophistiqué. Compte tenu de ce rôle, le dossier du malade est et restera
longtemps l’outil principal de coordination de l’activité médicale » [TIM, 91].
Les dossiers informatisés facilitent le partage des données, la coordination et la

communication entre les différents partenaires du système de soins (édition automatique de
comptes rendus, accès par réseau à des données cliniques ou biologiques, transfert
électronique d’informations médicales ou administratives…).
Cette informatisation a pour objectifs de [DAY, 90], [FRM, 07] :
- Conserver et rendre disponibles les informations du patient, et ses données personnelles
pertinentes en rapport avec la santé, et ainsi garantir la continuité des soins.
- Surveillance des facteurs de risque et prévention.
- Instrument pour l’aide à la décision.
- Assurer la protection et la confidentialité des données des patients.
49
III.3. Les systèmes d’information radiologiques (SIR)

« Le SIR est conçu pour stocker, manipuler et rechercher les informations pour la
planification, l’organisation, la direction et le contrôle des activités administratives et
cliniques liées à la fourniture et à l’utilisation des services et des équipement de
radiologie »[IGS, 89].
III.3.2. Fonctions d’un SIR

Un service de radiologie utilise deux types de systèmes informatiques : le système
d’information radiologique (SIR), et le système d’archivage et de communication d’images
(PACS). Le SIR doit regrouper toutes les fonctionnalités utiles à l’ensemble du personnel du
service radiologie (paramédicaux, médecins, encadrement, secrétaires). Il doit assurer le lien
entre les différents composants du système : Il est connecté au SIH pour récupérer
l’identification des patients et pour envoyer les données d’activité. Il doit également être
connecté au système d’acquisition et de gestion des images (PACS), pour la transmission de
l’identification des patients, et pour l’organisation de la production des examens. La gestion
de la production des actes (rendez-vous, accueil, cotation et codification, réalisation de l’acte,
comptes rendus,…) constituent l’essentiel de l’information saisie au quotidien. Ainsi le
système doit être architecturé autours du patient plutôt qu’autour de l’acte qui n’est qu’un des
éléments du dossier. Le SIR assure les fonctions suivantes [IGS, 89] :
- la prescription de l’examen et la planification de rendez-vous.
- Vérification des identifications du patient et du demandeur.
- La réalisation de l’examen.
- L’interprétation des clichés et l’établissement des comptes rendus.
- L’archivage des comptes rendus et des radios pour une réutilisation ultérieure.
- Evaluation du service par l’intermédiaire de tableaux de bord d’activités et de données sur
le fonctionnement des différents secteurs du service (durée d’attente, durée des actes,
durée de rendez-vous).
III.4 Le système d’archivage et de communication PACS

Le problème majeur des images est la taille considérable qu'elles occupent lorsqu'elles
sont manipulées sous forme numérique (une image d’examen IRM peut occuper 2
MégaBytes, celle de radiographie de thorax 4 MégaBytes et celle de tomodensitométrie axiale
50
10 MégaBytes). D'autre part le problème est aussi celui du grand nombre d'images générées
par examen (Un seul examen de tomodensitométrie axiale peut générer entre 20 et
90 images) [AIM, 91].
On dispose aujourd'hui de nouvelles technologies de stockage numérique telles que
celle des disques optiques ou plus récemment des disques optornagnétiques réinscriptibles.
Ces nouvelles technologies permettent de stocker plus de 6 Gygabytes par disque. Par
ailleurs, des systèmes mécaniques de Juke-Box permettent de gérer jusqu'à 150 disques à la
fois sans intervention manuelle ce qui offre une capacité de stockage proche du TeraByte.
La distribution des images à distance à grande échelle reste cependant limitée par la
performance des réseaux de transmission des données numériques. Des réseaux rapides
actuellement disponibles tels que les réseaux Ethernet (1 MBit/s) restent insuffisants quand il
s'agit de distribuer un grand nombre d'images à un grand nombre de stations de travail. Les
réseaux à très haute vitesse, tels que les réseaux FDDI (100 MBit/s), font cependant leur
apparition et permettent déjà d'envisager des communications d'images à des vitesses
acceptables dans un milieu hospitalier [AIM, 91].
« Un PACS peut être définit comme étant une capacité d’archivage élevée connectée à
un réseau rapide de communication d’images servant différents types de stations de
consultation. Le but d’un PACS est de collecter et de stocker des images, à partir
d’équipements divers, dans une banque d’images accessible de n’importe quel point de
l’hôpital. Un PACS apparaît comme le sous-ensemble du système d’information hospitalier
(Voir figure III.1) consterné par le stockage et la transmission des images et repose sur le
standard DICOM de communication et de description des images» [TIM, 91].
Système d’Information Hospitalier (SIH)
Système
Figure d’Information
III.1 de
: Système d’Information PACS
de Radiologie (SIR)
Radiologie (SIR)
Figure III-1 : Le système d’information de radiologie [TIM, 91]
51
III.4.2. Architecture d’un PACS

L'architecture générale du PACS peut être schématiquement divisée en deux types de
serveurs : les serveurs d'archives et les serveurs d'affichage. Les images sont stockées sur des
disques optiques au niveau des serveurs d'archives et une distribution de ces images est
effectuée de façon préprogrammée à des serveurs d'affichage qui sont reliés aux stations de
travail. La figure III.2 représente cette architecture.
Figure III.2 : Architecture d’un système PACS [AIM, 91]

Le serveur d’archives
Un serveur d’archives est une unité constituée d'un ordinateur (le serveur) connecté à
une unité de disques optiques multiples (Juke Box).
Le serveur est relié à différentes sources d'acquisition des images soit par l'intermédiaire d'un
réseau local ou directement au travers d'interfaces de transmission de données à grande
vitesse (Radiographies Numérisées (CR), Digitaliseurs de films, etc.). Ces images seront
stockées sur des disques optiques en maintenant une banque de données des images en
commun avec le reste des informations des patients [AIM, 91].
Le serveur d’archives est également relié à deux réseaux Ethernet : l'un relié au SIH de
l’hôpital par lequel les informations concernant les patients, la programmation des examens et
la facturation sont échangées, l'autre (appelé réseau PACS) où seules les images sont
véhiculées entre le serveur d'archives et les différents serveurs d'affichage.
52
Un Juke Box est une unité permettant de stocker et de lire automatiquement plusieurs
disques optiques à large capacité. Les systèmes actuellement disponibles sur le marché,
pouvant correspondre aux besoins d'archivages des images radiologiques, contiennent
habituellement un minimum de deux unités de lecture/écriture des disques servis par un robot
mécanique capable de changer les disques à partir d'un stock d'environ 60 à 100 disques.
L’accès en lecture et écriture sur disques optiques est relativement lent. Pour pouvoir assurer
une performance suffisante on a mis en place un système de disques magnétiques (ou
optornagnétiques réinscriptibles) [AIM, 91].
Le serveur d'affichage
Un serveur d'affichage a une configuration semblable à celle du serveur d'archives sauf
qu'il n'est pas relié à un système de stockage à disques optiques mais plutôt à des disques
magnétiques (ou optornagnétiques réinscriptibles) à large capacité pour un stockage des
images pour une durée limitée.
La fonction du serveur d'affichage consiste en la distribution des images à différentes
stations de travail et de visualisation des images. Le Serveur d'affichage n'est pas directement
relié à des sources d'acquisition des images radiologiques, mais il obtient les images qui lui
sont destinées à partir du serveur d'archives. Les images sont stockées sur disques
magnétiques avant d'être redistribuées aux différentes stations de visualisation. Lorsqu'une
image ou un examen demandé n'est pas disponible sur le serveur d'affichage local, une
requête est alors "envoyée" au serveur d'archives pour transférer cet examen des archives au
disque local du serveur d'affichage [AIM, 91].
III.4.3. Apports d’un PACS au SIR [DFB, 05]

L’utilité d’un système cohérent prend en compte l’acquisition et la distribution des
images peut se justifier ainsi :
- Assurer la conservation des images digitales sans risques de pertes ou de détérioration de
leurs contenus.
- Rendre l’accès rapide et facile à toutes les images pour chacune des personnes autorisées.
- Permettre l’accès simultané aux mêmes images à partir de n’importe quelle station de
lecture.
- Permettre la manipulation et le traitement local des images.
- Réaliser des économies en coût de personnel et de matériel.
53
- Faciliter l’alimentation permanente de la recherche par la pratique clinique quotidienne, ce

qui implique que l’on dispose d’outils permettant une sélection rapide des images
pertinentes.
Remarque : Plus de 102 sociétés revendiquent la commercialisation de systèmes

PACS, les plus importantes étant : KODAK, FUJIFILM, AGFA, PHILIPS… [RCA, 91].
III.5. Intégration du PACS aux SIH

De nombreuses difficultés techniques et financières ont, à ce jour, limité le
développement des PACS et leurs intégration dans les systèmes d’information hospitaliers. En
effet cette intégration est nécessaire pour permettre la prise en compte de toutes les données
pertinentes du malade, les images et les données alphanumériques, et d’apporter au technicien
utilisateur une réelle aide à l’action médicale. Une connexion efficace entre la base de
données alphanumérique hospitalière du SIH et la base d’images du PACS est nécessaire.
Notons que la taille d’une base de données d’un SIH classique varie entre 10 et 100 GO, alors
que celle d’un PACS varie entre 1000 et 10000 GO [AIM, 91].
Figure III.3 : Intégration SIH-SIR-PACS (Echange de données)
Pour assurer la transmission de larges séquences d’images, il est impératif d’utiliser

des réseaux haut débit tels que les réseaux FDDI. Le standard DICOM a permis aux PACS de
se développer, en faisant communiquer entre eux tous les appareils de radiologie produits ces
dernières années. Le standard HL7 (Health Level 7) a permis d’interfacer les PACS aux
systèmes d’information hospitaliers.
54
III.6. Les standards DICOM et HL7 [INT, 08]

L’un des problèmes rencontrés lors du développement des systèmes PACS est celui
des formats différents utilisés par les constructeurs pour le stockage numérique des images.
Le standard DICOM (Digital Imaging and communication in Medicine) est une gamme
complète de standards pour la manipulation et la transmission des données et des informations
des images, ce standard comprend une définition du format de fichiers et un protocole de
communication en réseaux. Il a été développé à NEMA (National Electrical Manufacturers
Associates) afin de rendre possible l’intégration des scanners, serveurs, postes de travail,
imprimantes, l’équipement réseaux provenant de multiples manufacturiers pour en faire un
système d’entreposage et de communication d’images.
Le standard HL7 (Health Level 7) est un standard pour l’échange d’information entre les
systèmes de santé : systèmes d’information hospitalier (SIH), systèmes d’information
radiologique (SIR) et le système d’archivage et de communication d’images (PACS).
III.7. Télémédecine et Téléradiologie

La télémédecine est un concept général qui couvre différentes applications en rapport
avec la santé, elle doit être un complément aux soins reçus personnellement, on a recourir à la
télémédecine pour obtenir des renseignements supplémentaires nécessaires ou prendre un avis
spécialisé et immédiatement nécessaire qui n’est possible qu’à distance : Les médecins auront
accès au dossier complet du patient n’importe où et n’importe quand, et donc à son
historique, ainsi qu’aux informations concernant sa sensibilité et ses allergies à différents
médicaments, Un principe de base est le transfert d’informations à l’endroit où une décision
ou une action doit être prise (on déplace donc l’information et non pas le patient) [WST, 02].
La téléradiologie est une application de télémédecine, c’est un acte médical qui

recouvre deux types de situations: le télédiagnostic et la téléexpertise, son emploi se justifie
par l’état de santé du patient, la continuité ou la permanence des soins ou plus généralement
par des circonstances particulières de temps et de lieu. Elle permet au médecin (praticien de
proximité) au contact direct avec le patient de disposer de l’avis d’un médecin radiologue
situé à distance du lieu de réalisation de l’examen radiologique (téléradiologue) : guider la
conduite de l’examen le plus adapté à la situation clinique, effectuer une seconde lecture des
images, et affiner et/ou confirmer son diagnostic et le cas échéant, guider la conduite à tenir
pour le patient. Outre ce bénéfice immédiat pour le patient, la téléradiologie présente l’autre
55
avantage de favoriser les échanges de connaissances et de savoir-faire entre les médecins

radiologues qui l’utilisent (Téléexpertise) [CPR, 07].
Comme la télémédecine, Le recours à la téléradiologie doit s’exercer dans le respect

d’un certain nombre de principes de déontologie pour garantir son bon usage. Elle est
formalisée par des protocoles rédigés et mis en oeuvre dans le cadre de contrats ou de
conventions signées personnellement par les médecins qui s’y engagent et s'il y a lieu les
établissements où ils exercent [CPR, 07].
III.8. L’aide à la décision médicale

Les systèmes d’aide à la décision médicale ont fait l’objet de multiples réalisations, les
systèmes experts faisant appel aux méthodes de l’intelligence artificielle se multiplient en
médecine comme dans d’autres domaines des sciences et des techniques, ces méthodes
permettent des raisonnements qui s’appuient sur de grandes quantités de connaissances. [TIM,
91], Il est devenu possible de développer des systèmes centrés sur l’action médicale
permettant aux cliniciens de bénéficier des possibilités offertes par l’informatique et les
méthodes avancées du traitement de l’information pour améliorer leurs connaissances, leurs
décisions et maîtriser leurs activités.
III.9. Typologie des systèmes d’aide à la décision médicale [TIM, 91]

III.9.1. Les systèmes d’aide indirecte à la prise de décision
Ces systèmes permettent de stocker l’information et le savoir médical et mettent en
œuvre des procédures d’accès aux informations stéréotypées : l’accès aux résultats de
laboratoires, ou la consultation des éléments importants du dossier médicale du patient
constituent des aides indirectes à la décision, cette aide intervient pour faciliter l’appréciation
d’une situation par le médecin. L’accès aux informations concernant les médicaments et leurs
interactions sont d’autres exemples pouvant intervenir dans la décision médicale.
III.9.2. Les systèmes de rappels automatiques

Ces systèmes permettent de rappeler le médecin des erreurs à ne pas commettre ou des
éléments importants à prendre en compte pour la prise de décision, ils constituent un aide-
mémoire fournissant une information pertinente dans une situation donnée : Le rappel des
valeurs normales des examens biologiques, et l’émission d’un message de mise en garde
56
devant une association de médicaments déconseillée sont des aides simples mais très utiles.
Ces systèmes restent en état de veille et se déclenchent à chaque fois qu’une situation
particulière est identifiée.
III.9.3. Les systèmes consultants

Les systèmes consultants cherchent à donner un avis de spécialiste devant une
situation médicale définie, qu’elle soit de nature diagnostique, thérapeutique ou pronostique.
Les systèmes experts médicaux peuvent être classés dans cette catégorie : Ce sont des
systèmes qu’il faut interroger pour obtenir un conseil sur un problème médical particulier, ils
disposent de bases de connaissances qu’un expert ou un groupe d’experts fait évoluer
incrémentalement. La possibilité d’ajouter et de modifier des règles est une des
caractéristiques essentielles de ces systèmes.
III.10. Techniques d’aide à la décision

Un des buts poursuivis est de faire en sorte qu’une machine puisse dériver de
nouvelles conclusions en utilisant de manière formelle les description du monde (et de ses
états) auquel on s’intéresse. Il existe deux approches d’aide à la décision : l’approche dite
numérique et l’approche logico-symbolique. La première se base sur des algorithmes
numériques comme l’analyse discriminante, le théorème de Bayes, les réseaux de neurones,
etc. la deuxième approche s’appuie sur des algorithmes de logiques formelles (propositions,
logique de 1er ordre), d’algorithmes de représentation des connaissances et des méthodologies
de recueil de l’expertise médicale [TIM, 91].
57
Conclusion
Les systèmes d’information hospitaliers (SIH), plus particulièrement les systèmes
d’information radiologiques (SIR), ne peuvent correctement fonctionner sans la participation
active de l’ensemble des personnels concernés. La participation doit être initiée dés la phase
d’analyse sous peine de rejet ultérieur.
L’introduction d’une solution RIS- PACS est le moment idéal pour réviser la manière
de travailler dans le service de radiologie. En effet, on ne peut augmenter l’efficacité et la
productivité de ces services que si une réflexion sur les processus de travail et le workflow est
menée. Un travail de communication auprès de tous les acteurs médicaux est important, car la
numérisation de la radiologie a des impacts sur la plupart des services hospitaliers.
Par le passé, le développement des applications médicales s’est focalisé su le dossier

informatisé du patient, vu les progrès qu’a connu la médecine et les masses d’informations
disponibles, des systèmes d’aide à la décision médicale ont été mis en place et ont prouvé
leurs capacité à fournir des outils précieux pour l’amélioration de la qualité des soins fournie
aux patients, de plus il jouent un rôle dans la formation (initiale et continue) des
professionnels de santé.
58
Synthèse
Il s’agissait dans cette première partie d’introduire le cadre théorique dans lequel
s’inscrit notre projet, on a présenté une synthèse des concepts liés aux domaines concernés par
notre étude.
On a vue au premier chapitre que le workflow est une application de groupware, qui
s’intéresse aux communications formelles produites ou imposées dans le cadre d’exercice
d’un ensemble d’utilisateurs qui peuvent ne pas se retrouver dans un même lieu, ni au même
moment, et qui doivent travailler en commun dans le but de réaliser un même objectif.
Au deuxième chapitre il s’agissait d’évoquer les systèmes multi-agents, conçus

préalablement dans un but méthodologique dans le domaine de l’intelligence artificielle, et
qui ont ensuite évolués pour devenir à la fois une méthode de gestion et une technologie de
l’ingénierie logicielle dont le but est de procurer des solutions à des problèmes de la vie réelle.
On a vu que le principe qui fait la force des SMA est le partage des tâches à réaliser
entre plusieurs entités appelées ‘agents’ qui travaillent en collaboration pour atteindre un
objectif commun. La solution globale est la coordination et le regroupement des solutions
partielles des agents. Ces systèmes peuvent donc constituer un remède aux limites des
workflow classiques en les rendants plus adaptatifs aux exigences de flexibilité imposées par
les environnements instables dans lesquels opèrent les organisations d’aujourd’hui.
Au troisième chapitre, on a découvert comment la pratique de l’exercice médical, en

particulier, l’exercice radiologique est révolutionné par l’introduction de nouvelles
technologies numériques, à savoir l’informatisation du dossier médicale du patient, ainsi que
l’archivage et la communication des images radiologiques, à travers l’utilisation de systèmes
conçus spécialement à cet effet, à savoir les systèmes PACS.
On a vu aussi que le service radiologie est une structure complexe qui ne peut
correctement fonctionner que s’il existe des infrastructures assurant et une coopération entre
les différents acteurs afin de traiter au mieux les patients, la télémédecine et la téléradiologie,
on a montré à la fin de la partie que les systèmes d’aide à la décision médicale sont de plus en
plus introduits pour améliorer l’activité médicale.
Introduction
L’implémentation du workflow doit avant tout être précédée par une modélisation et
une amélioration du processus candidat au workflow. La phase de modélisation sert à la
représentation du processus à l’aide d’un langage graphique, l’intérêt est de mieux voir les
étapes du processus, les acteurs y faisant partie et la circulation des données au cours
d’exécution du processus.
Cette partie est divisée en deux phases : la première phase consiste à modéliser le
processus workflow en question, il s’agit en premier lieu de décrire le fonctionnement actuel
du processus de gestion des examens radiologiques au sein du service de radiologie de
l’hôpital Maillot. Cette description doit permettre d’avoir une vision globale du processus. Au
terme de cette étape on doit identifier les dysfonctionnements enregistrés, et de proposer des
recommandations permettant d’améliorer et d’optimiser son fonctionnement.
Ces recommandations constitueront le point de départ de la deuxième étape de

modélisation dans laquelle on représentera par un langage graphique les solutions jugées être
un remède aux dysfonctionnements enregistrés au cours de l’étape d’analyse. Cette étape doit
permettre, entre autres, d’aboutir à la construction de la base de données du système, de
donner une vision globale des activités qui composent le processus étudié, de définir les liens
entre ces activités et les rôles qui les assurent.
La deuxième partie traite l’aspect flexible du processus workflow étudié, qui est
l’interprétation des examens radiologiques, ça consiste à définir un ensemble d’agents
logiciels intervenant dans l’interprétation des examens, cet ensemble d’agents constitue un
SMA pour l’aide à la décision (interprétation des examens radiologiques).
59
Chapitre IV Analyse-Conception
IV.1. Analyse
Cette partie a pour but d’étudier la réalité des tâches et activités quotidiennes afin de
bien comprendre le fonctionnement actuel du processus de gestion des examens radiologiques
du service de radiologie de l’hôpital Maillot. On devra particulièrement s’attacher à :
- Présenter brièvement ce service.
- Analyser les facteurs humains tels que les rôles tenus par des individus ou des groupes.
- Analyser les facteurs technologiques tels que les modalités et le potentiel des
infrastructures de communication existantes (Réseaux, Ordinateurs, Téléphones,...).
- Décrire le fonctionnement actuel du processus de la gestion des examens radiologiques de
ce service en précisant les tâches effectuées depuis la réception d’une demande d’examen
radiologique par un patient jusqu’à la remise des résultats de cet examen.
- Elaborer une synthèse et des recommandations sur la reconfiguration du processus
candidat, présentant des dysfonctionnements.
IV.1.1. Présentation du service

Le service d'imagerie médicale est implanté dans l'enceinte du centre hospitalo-
universitaire de Bab El Oued. Ce dernier est situé au pied de la Casbah, au coeur d’Alger, Il
est intégré dans une structure hospitalière de 840 lits, et dessert un bassin de population de
prés de 1,5 millions d'habitants.
En plus de ses activités d'imagerie médicale, le service a une vocation nationale fixée
par arrêté ministériel. Les conditions d'exercice et la disponibilité des moyens permettent
d'offrir une prise en charge pédagogique paramédicale et médicale (formation de graduation et
de post graduation, formation continue).
Le service est structuré en plusieurs départements : IRM, TDM, radiologie vasculaire,

radiologie ostéoarticulaire, radio-urologie, radiologie génitale, radio-pédiatrie,
neuroradiologie, radiologie digestive, radiologie thoracique, radiologie interventionelle.
L'installation d'un réseau PACS et le développement de la télémédecine sont des tâches
inclues dans le cahier de charge du service et de ses partenaires.
L'exercice est organisé en système vacataire pour un partage efficace et optimal des
moyens. A cet effet le service dispose d'un ensemble de stations de visualisation et de
60
traitement d'images ainsi que d'une station d'archivage. Une ligne spécialisée dédiée de 2
Méga bytes assure les connexions internes et externes.
Le service a traité 86998 patients en 2004 et 109761 patients en 2005. il reste ouvert
et fonctionne 24 heures sur 24 et 7 Jours sur 7.
L’équipe de jour travaille selon les horaires suivants :
- De 8 H à 14 H pour les médecins et les techniciens manipulateurs.
- De 8 H à 16 H pour les agents de service (Réceptionnistes, agents de sécurité, agents
d’entretient et médecins qui s’occupent de l’échographie (non exposés aux rayons)).
- De 8 H à 15 H pour les agents de service qui travaillent le jeudi de 8 H à 12 H.
L’équipe de soir travaille selon les horaires suivants :
- De 14 heures à 8 heures du matin, et n’assure que les urgences, cette équipe est
composée de deux techniciens qui s’occupent des examens standards (radio os), d’un
assistant et d’un résident pour le scanner et l’échographie
- Les médecins de garde travaillent un jour sur trois, il y a donc trois équipes de garde.
Le service assure actuellement la formation de médecins résidents (formation de post-

graduation). Cette dernière est pratique et théorique (cours magistraux, activités en salle,
colloques, présentation de dossiers ...).
IV.1.2. Analyse des facteurs humains

Le service d’imagerie de l’hôpital Maillot emploi un personnel très qualifié composé
de trois catégories :
Staff médical
- Chef de service.
- Département neuro-radiologie : Un professeur, un maître assistant.
- Département radiologie vasculaire: un maître assistant, un médecin spécialiste.
- Département radiologie interventionelle : un maître assistant.
- Département radiologie digestive : un maître assistant.
- Département radiologie osteo-articulaire : un maître assistant.
- Département radiologie ORL : un maître assistant.
- Département radiologie thoracique : un médecin spécialiste.
- Département radiologie urologie : un médecin spécialiste.
- Département radiologie pédiatre : un médecin spécialiste.
61
- Département radiologie gynécologique : un médecin spécialiste.

- Département mammographie : deux médecins spécialistes.
- Département échographie : un médecin spécialiste.
- Neuf médecins résidents.
Staff paramédical
- Un surveillant médical.
- Un ingénieur et un correspondant technique.
- Un technicien anesthésiste.
- Quatorze techniciens supérieurs de la santé
Secrétariat
- Un responsable secrétariat et archives.
- Une secrétaire médicale.
- Trois secrétaires principales.
- Deux secrétaires d’accueil.
Notre étude nous a permis d’identifier quatre postes de travail : Chef de service,
Secrétariats, Réceptions, et l’ensemble des médecins. Chacun des postes est chargé d’assurer
un certain nombre de rôles. Dans ce qui suit une description des rôles de chaque poste :
• Chef de service
- Gestion du service de radiologie.
- Edition des emplois du temps des médecins.
• Secrétariats
- Edition des comptes rendus électroniques.
- Mise à jour du registre des patients traités.
- Prise en charge des réclamations des patients.
- Répondre au téléphone (Standard et chef de service).
• Réceptions
- Réception des demandes d’examens.
- Tris des demandes d’examens.
- Remise des rendez-vous aux patients.
- Réception des rendez-vous des patients.
- Edition des bons d’enregistrement.
- Constitution du dossier patient.
- Tris des dossiers patients.
- Remise des résultats aux patients.
62
• Médecins
- Fixation des rendez-vous aux patients.
- Mise à jour du registre des rendez-vous.
- Réalisation des examens.
- Edition des comptes rendus des examens.
- Mise à jour du registre patient.
- Validation des comptes rendus électroniques.
IV.1.3. Analyse des facteurs technologiques

Le service de radiologie de l’hôpital Maillot utilise un matériel très sophistiqué. Le
tableau suivant pressente les appareils d’acquisition d’images du service.
Appareil Type et marque Numérique Examens réalisés
Echographe Logic500 de General Oui Tous + interventionelle
elctric
Echographe HDI de Philips Oui Tous + interventionelle
Echographe Sienna de Siemens Oui Tous + interventionelle
IRM 0.2 de Siemens Oui Tous
IRM 1.5 de Siemens Oui Tous
TDM (CT) Spiral de Siemens Oui Tous
TDM (CT) 16 Barettes de Siemens Oui Tous
Radio Philips Oui Angiographie
Panoramique Finlandais de General Non Panoramique dentaire,
mammographie elctric sinus, mammographies
Urographie Enie Non Tous
intraveineuse
Osteodensitometre Chalenger Non Tous
Radio Philips Oui Articulaire UCR, TG
Radio Philips Oui Digestifs
3 radios fixes Non Osseux
3 radios mobiles
Radio standard à RX
Tableaux VI.1. Analyse des facteurs technologiques du service
63
Le service possède aussi :

- Neuf écrans de visualisation d’images utilisés dans les examens d’IRM et de scanner.
- Six cameras laser de marque (Drystar 3000). Trois reliées aux scanners, IRM et leurs
stations de travail. Trois reliées aux salles d’examens spécialisés : omni-diagnostic,
duo-diagnostic et multi-diagnostic.
- Trois appareils de radiographie mobiles, placés dans les salles de réanimation, de
chirurgie et d’orthopedie-neurochirurgie.
- Il existe une salle de radiologie dans le service de pédiatrie
- Il y a un doppler utilisé dans les cas critiques.
- Il existe un réseau constitué de sept micro-ordinateurs.
- PACS pour l’archivage et la communication d’images.
- Pour les activités pédagogiques : filmothèque, diapothèque et une bibliothécaire
spécialisée.
IV.1.4. Description du fonctionnement actuel du processus

Dans ce qui suit, on procédera à la description du fonctionnement actuel du processus
de la gestion des examens radiologiques au niveau du service de radiologie de l’hôpital
Maillot, tout en mettant au point les effectifs impliqués et les moyens utilisés dans le
déroulement de ce processus :
1. Lorsqu’un patient se présente à la réception 1 (IRM ou TDM), ou à la réception 2

(Examens standards ou spécialisés), muni d’une ordonnance oû est inscrit son nom, son
prénom, son âge, son cas clinique, le type de l’examen demandé, le nom du service et du
médecin demandeur de l’examen ; le réceptionniste reçoit la demande, constitue un
dossier contenant la demande d’examen, une fiche de rendez-vous vierge, et si nécessaire,
une note d’information (décharge) à remettre au médecin traitant pour approbation, remet
ensuite au patient un jeton oû est inscrit le numéro du dossier et la date de retour pour
prise du rendez-vous.
Remarques :
- Le médecin est soit externe, soit appartenant à un autre service de l’hôpital.
- Le malade est soit interne à l’hôpital, soit externe hospitalisé dans un autre hôpital.
Les autres cas ne sont pas acceptés.
64
2. Le réceptionniste remplit les fiches de rendez-vous des dossiers, puis les trie selon les
différents types d’examens demandés et les remet aux médecins pour programmation.
3. Pour chaque journée, chaque spécialité a un médecin responsable, ce dernier traite les
dossiers un par un : il note les informations des patients sur le registre des rendez-vous,
complète la fiche de rendez-vous, inscrit entre autres le nom de l’examen à réaliser, la date
du rendez-vous, les conditions à satisfaire pour effectuer l’examen, les bilans biologiques
et radiologiques nécessaires.
4. En fin de journée, le réceptionniste récupère les dossiers des patients.
5. Lorsque le patient revient muni de son jeton ; le réceptionniste lui remet son dossier (La
fiche de rendez-vous, la décharge et la demande d’examen) et lui demande de remplir la
décharge par son médecin traitant.
6. Le patient revient le jour du rendez-vous muni de son dossiers, paie son examen
(l’examen IRM est gratuit), le réceptionniste lui remet un bon de paiement et un bon
d’enregistrement oû est inscrit son nom et son prénom, sa date et l’heure d’arrivée, ainsi
que la salle d’examen.
7. Le patient se présente à la salle d’anesthésie pour qu’on lui injecte un produit de contraste.
8. Le médecin possède les dossiers du jour, commence à les traiter un par un, il appelle
l’agent de sécurité par téléphone, lui donne le nom du patient à appeler.
9. Après traitement de l’examen, le médecin met à jour son registre des patients traités. Deux
cas se présentent en fin d’examen :
- Si c’est un examen simple (Echographie, Télétorax…), le médecin remet directement
le cliché de la radio et le compte rendu au patient (Cas d’urgence ou cas normal).
- Si c’est un examen complexe (TDM, IRM…),
- Dans le cas normal, le patient doit revenir dans quelques jours pour récupérer les
résultats de son examen.
- Dans le cas d’urgence, le médecin imprime le cliché de la radio et édite un compte
rendu qu’il remet au patient. Une autre lecture de l’examen est souvent nécessaire.
10. Chaque médecin a un paquet d’examens à interpréter, il est assisté par un ou deux
résidents (Etudiants en spécialité), la première lecture des clichés est réalisée par les
résidents, ils portent leurs remarques et éditent un compte rendu d’examen. Le médecin
(assistant ou maître assistant) vérifie ensuite ces comptes rendus et porte des correctifs et
des compléments au compte rendu, il édite donc un compte rendu final de l'examen. Si le
médecin estime que c’est un cas compliqué, il le pressente à des médecins plus spécialisés
ou le propose au colloque pour être mieux interprété.
65
11. L’agent de la réception 3 récupère les examens IRM et TDM interprétés, auprès des
médecins, les inscrits dans son registre des examens à remettre. Il vérifie à chaque fois si
le compte rendu est bien édité (pas de ratures), auquel cas il marque l’examen comme
étant prêt à être libéré, sinon il remet le compte rendu manuscrit au secrétariat pour être
saisit et imprimé. La secrétaire tape puis imprime le compte rendu et le remet au médecin
pour être validé. Après validation du médecin, la secrétaire met à jour son registre des
dossiers traités, et remet les résultats à la réception 3. L’agent de la réception 3 remet le
compte rendu au dossier correspondant.
12. Lorsque le patient vient muni de son bon d’enregistrement à la réception 3, l’agent vérifie
selon la date qui figure sur sa fiche d’enregistrement, si les résultats de l’examen
correspondant sont prêts à être remis, auquel cas, il remet les résultats au patient et marque
l’examen comme étant libéré. Deux cas se présentent :
- Si c’est le médecin traitant du patient (hospitalisé dans un des services de l’hôpital)
qui vient retirer les résultats de l’examen, l’agent de la réception 3 enregistre les
coordonnées de ce médecin.
- Si c’est le patient qui vient retirer les résultats, il récupère la fiche d’enregistrement et
marque l’examen comme étant remis.
IV.1.5. Diagnostic et recommandations

Tout au long de notre étude du fonctionnement actuel du processus de gestion des
examens radiologiques dans ce service, on a identifié quelques anomalies qui influencent le
bon fonctionnement du processus à savoir :
- La durée pour avoir un rendez-vous est énorme, elle est de 48 heures.
- La fixation des rendez-vous se fait par les médecins ce qui provoque une charge
supplémentaire sur les médecins d’oû la baisse de leurs productivité.
- Risque de programmer des examens à des patients qui peuvent ne pas respecter leurs date
de rendez-vous ; le paiement des examens se fait le jour oû le patient se présente pour
effectuer son examen.
- Perte de temps dans la validation des comptes rendus d’examens lorsque ceux-ci
contiennent des ratures : l’agent de la réception 3 remet le compte rendu manuscrit à la
secrétaire pour être saisit puis remis au médecin pour validation.
- Absence d’identifiants pour la recherche des résultats, le réceptionniste effectue la
recherche à l’aide du nom et prénom, donc risque d’erreurs et perte de temps.
66
- Problème organisationnel flagrant : un même agent de réception s’occupe de recevoir les

demandes d’examens et de remettre les dossiers (avec fiche de rendez-vous) aux patients.
- La date de retour est absente ou inexacte pour la récupération des résultats des examens
complexes, la durée d’attente est entre 5 et 15 jours.
- Inexistence du dossier médical radiologique des patients.
- Pas d’archivage des comptes rendus et des radios, le PACS n’est pas utilisé.
En se basant sur l’ensemble des anomalies identifiées précédemment, on présente dans
ce qui suit quelques recommandation à prendre en compte pour améliorer le fonctionnement
du processus de gestion des examens radiologiques de ce service :
- La fixation des rendez-vous doit être immédiate au niveau de la réception (on garde une
seule réception), ainsi dégager les médecins d’une tâche qui n’est pas la leurs.
- Le paiement doit se faire au moment de la fixation du rendez-vous.
- Mettre en place des dossiers patients informatisés, donc les observations de l’anesthésiste
suite à l’injection du produit de contraste, les antécédents du patient, les interprétations
des examens sont rajoutés au dossier électronique du patient.
- La recherche et le transfert des documents doivent se faire de manière électronique.
- Mettre à la disposition des médecins des mécanismes de coopération leurs permettant de
se communiquer et de se partager les connaissances individuelles et collectives.
- Mettre à la disposition des médecins des mécanismes d’aide à la décision afin de mieux
interpréter les examens, et d’établir de bons diagnostics.
- Utiliser le PACS pour bénéficier des avantages qu’il offre (Archivage et communication
des images de radios).
- Le bon de retour pour récupérer les résultats d’examens complexes doit porter la date de
retour.
- L’impression des examens se fera au moment de la demande de récupération des
examens par le patient au niveau du secrétariat.
-
67
IV.2. Conception
Notre étude du système nous a permis d’identifier cinq activités principales qui
constituent le processus de gestion des examens radiologiques du service, à savoir : la fixation
des rendez-vous aux patients, l’anesthésie, la réalisation, l’interprétation et la restitution des
résultats des examens radiologiques.
On se propose dans nôtre solution de raccourcir le cycle complet de l’examen
radiologique, depuis la demande d’un examen par un patient jusqu’à la remise des résultats :
- La fixation des rendez-vous devient plus rapide : le réceptionniste aura à sa disposition
une interface lui permettant, à partir d’un planning pré-programmé et en fonction de
l’examen demandé, d’attribuer un RDV au patient.
- En fonction de l’examen à réaliser, l’anesthésiste aura accès au dossier patient informatisé
pour ajouter d’éventuels compléments d’information à l’examen, notamment ses
observations de la réaction du patient suite à l’injection du produit de contraste.
- Les médecins radiologues auront accès au dossier patient informatisé pour consulter
éventuellement les antécédents du patient et compléter les informations de l’examen à
réaliser. Les modalités sont connectées au PACS, après avoir traiter les images, celles-ci
sont automatiquement poussées pour archivage dans le serveur d’archivage du PACS. Les
médecins peuvent proposer certains examens (pour des fins pédagogiques) à des médecins
résidents pour interprétation.
- Les médecins radiologues auront accès au dossier patient informatisé pour interpréter les
examens effectués (Editer un compte rendu de l’examen) : ils peuvent éventuellement
consulter des examens antérieurs, faire appel à un système d’aide à la décision ou
demander l’avis d’un radiologue expert en utilisant la messagerie du système. Les
médecins radiologues peuvent éventuellement prescrire d’autres examens
complémentaires aux patients lorsque la situation l’exige.
- Les médecins résidents ont la possibilité d’accéder à certains examens jugés utiles pour
des fins pédagogiques, et envoyer leurs comptes rendus à leurs médecins encadreurs en
utilisant la messagerie du système.
- La recherche et la remise des résultats des examens se fait d’une manière simple et
efficace, les secrétaires médicales ont accès aux examens pour impression des résultats.
Notre conception est en effet divisée en deux phases : dans la première phase, il s’agit
de modéliser le processus workflow, la deuxième phase est consacrée à la conception du
système multi-agents qui constituera le système d’aide à la décision médicale mis en place.
68
IV.2.1. Conception du Workflow

La conception du processus candidat au workflow sert à la représentation du processus
à l’aide d’un langage graphique. L’intérêt est de mieux voir les différentes étapes du
processus, les acteurs intervenant dans son déroulement, la circulation des données et des
échanges de messages au cours d’exécution du processus.
On a divisé le processus de gestion des examens radiologiques du service de

radiologie de l’hôpital Maillot en cinq sous-processus à savoir : fixation des rendez-vous aux
patients, anesthésie, réalisation, interprétation, restitution des résultats des examens
radiologiques.
IV.2.1.1. Choix de l’approche de conception

Pour modéliser les différents diagrammes de ces sous-processus, on a opté pour le
langage UML, nôtre choix est motivé par le fait que : UML est devenu un standard en matière
de développement de logiciels. De plus UML convient parfaitement à la modélisation de
systèmes coopératifs, distribués et de workflow, ceci revient à sa richesse : neuf diagrammes
représentant des aspects différents du système.
UML est un langage de notation orienté objet qui a été développé et standardisé par
Rational Software et Object Management Group en 1997 et adopté par les méthodes d'analyse
et de conception orientées objet existantes (OMT, Booch, OOSE. UML est devenu un
standard pour le développement de projets informatiques : La modélisation objet consiste à
créer une représentation informatique des éléments du monde réel auquel on s’intéresse, sans
se préoccuper de l’implémentation ce qui signifie indépendamment d’un langage de
programmation. Il s’agit donc de déterminer les objets présents et d’isoler leurs données et les
fonctions qui les utilisent.
Un objet est caractérisé par plusieurs notions.

Les attributs : propriété caractérisant l’objet.
Les méthodes : Caractérisent les comportements (les opérations à réaliser) de l’objet.
L’identité : L’objet possède une identité qui permet de le distinguer des autres objets.
69
UML offre neuf diagrammes :

- Le diagramme de cas d’utilisation : Décrit les interactions d’un système avec son
environnement, en particulier avec les acteurs qui l’utilise, qu’ils soient des êtres humains ou
des machines. Il représente les comportements d’un système du point de vue de l’utilisateur
- Le diagramme de classes : Représente l’aspect statique d’un système sous la forme de
classes et de relations et ne contient pas d’informations temporelles. Une classe est une
représentation abstraite d’un ensemble d’éléments similaires.
- Le diagramme d’objets : Représente les objets et leurs relations, un objet étant un élément
particulier d’une classe.
- Le diagramme de séquence : S’intéresse à l’aspect dynamique du système et s’attache
principalement à montrer la circulation et l’ordre chronologique des messages, autrement
dit, il décrit la circulation de l’information.
- Le diagramme de collaboration : Représente les objets, leurs liens et leurs Interactions
de manière structurée.
- Le diagramme de transition d’états: Exprime le comportement dynamique d’un objet en
termes d’états, d’activités, de transitions et d’événements.
- Le diagramme d’activité : Montre le flux de contrôle et le flux d’information qui circule
au sein d’un système. Il permet de représenter le séquencement exact des activités et de
définir des conditions d’exécution.
- Le diagramme de composants : Montre l’implémentation physique d’un système, en
terme de composants logiciels.
- Le diagramme de déploiement : Décrit la configuration des éléments de traitement à

l’exécution et les composants qui leurs sont rattachés.
70
IV.2.1.2. Diagrammes de cas d’utilisation

« Un cas d’utilisation représente un ensemble de séquences d’actions (scénarios),
réalisées par le système et produisant un résultat observable intéressant pour un acteur
particulier et exprime les interactions acteur-système et apporte une valeur métier ‘notable’ à
l’acteur concerné. Il modélise un comportement attendu du système, sans imposer le mode de
réalisation de ce comportement. L’ensemble des cas d’utilisation doit décrire exhaustivement
les exigences fonctionnelles d’un système» [UEA, 03].
Le formalisme utilisé dans les diagrammes de cas d’utilisation se présente comme suit :
Symbole Désignation
Un Acteur représente un ensemble cohérent de rôles qui
interagit avec un cas d’utilisation. Il peut s’agir d’un être
humain, d’un système informatique ou d’un matériel spécialisé.
Un cas d’utilisation décrit ce qu’un système fait mais ne

spécifie pas comment il le fait.
Un Acteur peut être connecté avec un cas d’utilisation

uniquement par une relation d’Association qui se dessine par
un trait plein.
Un cas d’utilisation peut inclure un autre cas d’utilisation,
L’inclusion s’utilise notamment pour éviter de modéliser
plusieurs fois des événements identiques qui ont lieu dans
plusieurs cas d’utilisation
Un cas d’utilisation peut étendre un autre cas d’utilisation,
L’extension sert notamment à modéliser un ensemble optionnel
d’événements d’un cas d’utilisation
Une Note permet de stocker du texte libre dans la description
graphique d'un modèle
Tableau VI.2. le formalisme du diagramme de cas d’utilisation
Pour décrire la dynamique d’un cas d’utilisation, le plus naturel consiste à recenser
toutes les interactions de façon textuelle ; La fiche de description d’un cas d’utilisation n’est
pas normalisée par UML. Nous préconisons pour notre part la structuration suivante :
71
• Description sommaire
- Nom du cas d’utilisation
- But
- Résumé
- Acteurs
• Description des enchaînements
- Pré-conditions
- Scénarios
- Exceptions
- Post-conditions
• Besoin d’IHM
Nous avons identifié cinq cas d’utilisation: Fixation de rendez-vous, Anesthésie,
Traitement d’un examen, Interprétation d’un examen, Remise des résultats.
Diagramme des cas d’utilisation global
Avant d’aborder les diagrammes de cas d’utilisation en détail, nous avons jugé utile de les
représenter dans un même diagramme pour donner un aperçu global du fonctionnement du
système. La figure suivante rassemble les cinq cas d’utilisation dentifiés.
Interne ou Externe
Fixation rendez vous (Urgent)
Receptionniste
Remise résultats des examens
Secretaire Patient
Anesthésie
Anesthésiste Réalisation examen
C'est le seul
responsable du CR Editer un avis sur l examen
final
<<include>>
Radiologue expert
Accés à l examen à interpréter
Radiologue réalisateur de l examen

<<extend>> <<extend>> <<extend>>
Editer CR final de l examen Faire appel à un medecin expert Consulter le système d aide a la décision
Figure IV.1. Diagramme de cas d’utilisation global
72
Diagramme de cas d’utilisation : Fixation de rendez-vous

Diagramme
Interne ou Externe
(Urgent)
Receptionniste Patient
Fixation rendez vous
<<include>>
Authentification
Figure IV.2. Diagramme de cas d’utilisation : Fixation de rendez-vous

Description
- Nom du cas d’utilisation : fixation de rendez-vous.
- But : Pour un patient demandeur d’examen radiologique, lui fixer un rendez-vous
(Date, Heure, Salle d’examen,…).
- Résumé : lorsqu’un patient se présente pour obtenir un rendez-vous pour effectuer un
examen radiologique, le réceptionniste cherche, en fonction de l’examen demandé,
une séance disponible (planning pré-établi), il reçoit le paiement (cas d’un examen
ordinaire), enregistre le rendez-vous puis remet une fiche de RDV au patient.
- Acteurs : Réceptionniste (Principal), Patient.
- Pré-conditions
1. Le réceptionniste se connecte, s’identifie et s’authentifie auprès du système.
2. Le planning (mensuel) des séances par type d’examen est préétablit.
3. Le patient se présente muni d’une ordonnance pour obtenir un rendez-vous pour
effectuer un examen radiologique.
- Scénarios
1. Le cas d’utilisation commence lorsqu’un patient (muni d’une demande d’examen)
se présente pour obtenir un rendez-vous, le réceptionniste choisit l’option ’Fixer
un rendez-vous’.
2. Si le nom de l’établissement n’existe pas dans le système, le réceptionniste choisit
l’option ‘Rajouter un établissement’.
73
3. Si le nom du médecin prescripteur n’existe pas dans le système, le réceptionniste

choisit l’option ‘Rajouter un médecin’.
4. Le réceptionniste lance une recherche du patient (par numéro ou par non), si le
nom du patient n’existe pas, le réceptionniste choisit l’option ‘Rajouter un
patient’. Il saisit les informations du patient et valide l’inscription, ainsi un dossier
patient est créé.
5. Si c’est un cas d’urgence
5.1. Si toutes les conditions de l’examen sont satisfaites, la séance la plus proche
du jour est affectée au patient.
5.2. Sinon la séance la plus proche du lendemain est affectée au patient.
Dans les deux cas :
- Si l’ordonnance porte la mention ‘Complémentaire’, il saisit le numéro de
l’examen qu’il réfère (Ce numéro est portée sur l’ordonnance). il valide la séance,
imprime le RDV, le signe puis le remet au patient. (la fiche de RDV contenant la
mention ‘Urgent’), le patient devra passer à la salle d’anesthésie pour prendre un
produit de contraste le jour de son RDV.
- Sinon il valide la séance, imprime le RDV, le signe puis le remet au patient. (la
fiche de RDV contenant la mention ‘Urgent’), le patient devra passer à la salle
d’anesthésie pour prendre un produit de contraste le jour de son RDV.
6. Si ce n’est pas un cas d’urgence (cas ordinaire) :
6.1.1. La séance la plus proche est affectée au patient, puis reçoit le paiement.
- Si l’ordonnance porte la mention ‘Complémentaire’, le réceptionniste saisit le
numéro de l’examen qu’il réfère (Ce numéro est porté sur l’ordonnance). Il
valide la séance, imprime le RDV, le signe puis le remet au patient, ce dernier
devra passer à la salle d’anesthésie pour prendre un produit de contraste le jour
de son RDV.
- Sinon le réceptionniste valide la séance, imprime le RDV, le signe puis le remet
au patient, ce dernier devra passer à la salle d’anesthésie pour prendre un produit
de contraste le jour de son RDV.
- Exceptions
1. Cas d’échec de connexion du réceptionniste au système (consulter
l’administrateur).
2. Si des informations obligatoires ne figurent pas dans la demande de l’examen, ou
qu’un examen n’est pas dispensé au service, celle-ci est rejetée.
74
- Post-conditions
1. Fiche de RDV imprimée, signée et remise au patient.
2. Liste des séances libres mise à jour.
• Besoin d’IHM
1. Liste des types d’examens triée par ordre alphabétique.
Diagramme de cas d’utilisation : Anesthésie

Diagramme
Anesthésiste Anesthésie Patient
<<include>>
Authentification
Figure IV.3. Diagramme de cas d’utilisation : Anesthésie

Description
- Nom du cas d’utilisation : Anesthésie.
- But : Renseigner des informations sur l’injection d’un produit de contraste pour un
patient.
- Résumé : Lorsqu’un patient se présente à la salle d’anesthésie, muni de sa fiche de
rendez-vous, pour prendre une injection d’un produit de contraste,
l’anesthésiste renseigne les informations concernant cette opération.
- Acteurs : Anesthésiste (Principal), Patient.
- Pré-conditions
1. L’anesthésiste se connecte au système, s’identifie et s’authentifie.
2. Le patient se présente muni de sa fiche de RDV (Programmé pour la journée).
- Scénarios:
1. Le cas d’utilisation commence lorsqu’un patient se présente muni de sa fiche de
RDV, l’anesthésiste vérifie si le cas est programmé pour cette journée et que toutes
les conditions de l’examen sont satisfaites.
2. Si oui, elle choisit l’option ‘Réaliser anesthésie’. Une fiche contenant la liste des
renseignements à saisir sur l’injection s’affiche.
75
2.1. elle saisit le numéro de l’examen, les informations de l’examen s’affichent

alors, elle choisit le produit de contraste à injecter. Effectue l’injection et porte
ses remarques dans la zone ‘observations’ puis valide
3. Sinon, elle le réoriente à la réception pour renouvellement de rendez-vous.
- Exception
1. Problèmes de connexion au système (contacter l’administrateur).
2. Si le patient n’est pas programmé pour cette journée ou que les conditions de
l’examen ne sont pas satisfaites, l’anesthésie n’est pas effectuée.
- Post-conditions
1. Lorsque le patient ne satisfait pas les conditions de l’examen, celui-ci est
reprogrammé.
2. Les observations de l’anesthésie réalisée sont rajoutées à l’examen.
• Besoin d’IHM
1. Liste des produits de contraste triée par nom.
Diagramme de cas d’utilisation : Réalisation d’un examen
Diagramme
Medecin Radiologue Réalisation examen Patient
<<include>>
Authentification
Figure IV.4. Diagramme de cas d’utilisation : Réalisation d’un examen radiologique

Description
- Nom du cas d’utilisation : Réalisation d’un examen radiologique.
- But : Réalisation d’un examen programmé (ou un cas d’urgence) pour un patient.
- Résumé : Lorsqu’un patient se présente pour effectuer un examen (cas ordinaire ou
cas d’urgence), le médecin vérifie que c’est bien le patient à examiner pour cette
séance, auquel cas il réalise l’examen, de plus il édite un compte rendu instantané dans
le cas d’un examen simple, ou d’un examen complexe (cas d’urgence.).
- Acteurs : Médecin Radiologue (Principal), Patient.
76
- Pré-conditions
1. Le médecin se connecte, s’identifie et s’authentifie auprès du système.
2. Le patient se présente muni de sa fiche de RDV (Programmé pour la journée).
3. Les observations de l’anesthésie sont disponibles dans le dossier du patient.
- Scénarios
1. Le cas d’utilisation commence lorsque le médecin se connecte au système en
fournissant son login et son mot de passe.
2. Lorsque le tour d’un patient arrive, il se présente chez le médecin, ce dernier
choisit l’option ‘Réaliser un examen’, la fiche correspondant s’affiche sur écran, il
saisit le code de l’examen puis vérifie que c’est bien le patient à examiner.
3. Auquel cas, le médecin consulte les observations de l’anesthésiste, et les
antécédents du patient.
4. Scénario 1. Si l’examen à effectuer présente un risque sur le patient (le médecin se
réfère aux observations de l’anesthésiste), Le médecin choisit l’option ‘Prescrire
un examen’, puis réoriente le patient à la réception.
5. Scénario 2. Si l’examen à effectuer ne présente aucun risque sur le patient :
5.1. Le médecin réalise l’examen à l’aide de l’appareil (La modalité). L’image de
la radio est récupérée, traitée et archivée dans le PACS.
5.2. Si c’est le cas d’un examen simple, le médecin choisit l’option ‘Visualiser
radio’, puis ‘Editer un compte rendu’, interprète l’examen puis édite un
compte rendu, le valide ensuite, compte rendu final, (le compte rendu et une
référence à l’image de la radio dans le PACS sont rajoutés au dossier
patient). Il imprime ensuite le cliché de la radio et le compte rendu, et remet
le tous au patient.
5.3. Si c’est un cas complexe :
5.3.1. Si c’est un cas d’urgence, le médecin choisit l’option ‘Visualiser
radio’, puis ‘Editer un compte rendu’, interprète l’examen puis édite un
compte rendu, (Il peut solliciter, si le cas est compliqué, le système
d’aide à la décision ou un collègue via la messagerie du système), le
valide, compte rendu provisoire (le compte rendu, considéré comme
étant provisoire, et une référence à l’image de la radio dans le PACS
sont rajoutés au dossier patient). Il imprime ensuite le compte rendu
provisoire et le cliché de la radio, et remet le tous au patient.
77
5.3.2. Si ce n’est pas un cas d’urgence (cas ordinaire), le médecin valide

l’examen (une référence à l’image de la radio dans le PACS est
rajoutée au dossier du patient). Cet examen est donc rajouté à la liste
des examens à interpréter par ce médecin. Il imprime ensuite un bon de
retour, contenant la date de retour, puis le remet au patient.
5.4. Dans tous les cas, et pour des raisons pédagogiques, le médecin choisit de
proposer des examens qu’il juge intéressants pour les médecins radiologues
résidents qu’il suit, pour interprétation.
5.5. Dans tous les cas, si le médecin juge la nécessité d’un examen
complémentaire, il choisit l’option ‘Prescrire un examen’, puis le prescrit au
patient (Le numéro de l’examen qui a généré cet examen complémentaire est
mentionné dans l’ordonnance), auquel cas ce dernier se présentera à la
réception pour fixer la date du rendez-vous.
- Exceptions
1. Cas d’échec de connexion du médecin radiologue au système.
2. Si l’examen à effectuer présente un risque sur la santé du patient (réaction
anormale du patient vis-à-vis du produit injecté), ou que ses antécédents ne lui
permettent pas de réaliser un tel examen, le médecin annule l’examen.
3. Si l’examen n’est pas programmé ou que le patient n’a pas effectué l’anesthésie,
l’examen est annulé.
- Post-conditions
1. Au cas oû un examen présente un risque au malade, ou que le médecin juge la
nécessité d’un examen complémentaire, un autre examen est prescrit au patient.
2. Si un examen est annulé (conditions de l’examen ne sont pas satisfaites), celui-ci
peut être reprogrammé.
3. Un compte rendu et le cliché de la radio sont remis à tout patient effectuant un
examen simple.
4. Un compte rendu ‘provisoire’ et le cliché de la radio sont remis à tout patient se
présentant dans un cas d’urgence pour effectuer un examen complexe.
5. Tout examen complexe (cas ordinaire) est rajouté à la liste des examens à
interpréter, avec remise d’un bon retour au patient.
6. Le dossier patient est mis à jour.
78
• Besoin d’IHM
1. Liste des RDV de la journée triée par heure et affichée ainsi : (Heure_examen /
Nom_patient / Prénom_ patient / Type_examen / Cas_Clinique_Patient)
Diagramme de cas d’utilisation : Interprétation d’un examen complexe

Diagramme
C'est le seul
responsable du CR Editer un avis sur l examen
final
Radiologue expert
<<include>>
Accés à l examen à interpréter
Radiologue réalisateur de l examen

<<extend>>
<<extend>> <<include>> <<extend>>
Faire appel à un medecin expert

Editer CR final de l examen Authentification
Consulter le système d aide a la décision
Figure IV.5. Diagramme de cas d’utilisation : Interprétation d’un examen complexe

Description
- Nom du cas d’utilisation : Interprétation d’un examen complexe.
- But : Permettre au médecin d’interpréter un examen de sa liste des examens en
instance d’interprétation.
- Résumé : À partir de sa liste des examens en instance d’interprétation, le médecin
procède à l’interprétation des examens un par un. Il se sert du PACS pour récupérer
les radios, des informations se trouvant dans le dossier du patient, et éventuellement
du système d’aide à la décision. A la fin de l’interprétation de l’examen, s’il juge que
c’est un cas compliqué, il sollicite un collègue plus expérimenté (Plus spécialisé), par
la messagerie du système, ou au cas extrême, il propose ce cas au colloque du service
pour que l’interprétation soit le plus fiable possible.
- Acteurs : Radiologue réalisateur de l’examen (Principal), Radiologue expert.
- Pré-conditions
1. Le médecin réalisateur de l’examen se connecte, s’identifie et s’authentifie.
2. Arrivée d’un avis d’un radiologue expert.
79
- Scénarios
1. Le cas d’utilisation commence lorsque le médecin se connecte au système en
fournissant son login et son mot de passe et choisit l’option ‘Examens à interpréter’.
Une fiche contenant la liste des examens à interpréter s’affiche, elle est triée par date
de réalisation.
2. Il choisit un examen, les informations de l’examen s’affichent (Date de réalisation,
identité du patient).
3. Si l’examen est affecté à des résidents, il peut consulter leurs comptes rendus en
choisissant l’option ‘Consulter comptes rendus des résidents’. Il porte ses correctifs
et les renvoient par E-Mail.
4. Si le médecin a besoin de visualiser un examen antérieur, il le récupère en
choisissant l’option ‘Examens antérieurs’, au cas de besoins de complément
d’informations sur le patient il peut consulter les antécédents (Maladies antérieures)
du patient en choisissant l’option ‘Consulter antécédents’.
5. S’il juge que l’examen est un cas compliqué, et nécessite la consultation d’un expert,
il édite un compte rendu provisoire (l’examen est mis en instance de validation), il
choisit ensuite l’option ‘Proposer le cas à un expert’, de plus s’il juge que c’est un
cas à proposer au colloque, il choisit l’option ‘Proposer le cas au colloque’. Sinon il
fait son interprétation et édite un compte rendu de l’examen et valide.
6. Lorsque l’interprétation du radiologue expert, ou du colloque lui arrivent, il consulte
une autre fois en choisissant l’option ’ Examens en instance’. Il porte un
complément d’interprétation à l’examen, puis valide. L’examen est alors rajouté à la
liste des examens à remettre.
7. Dans tous les cas, si le médecin juge la nécessité d’un examen complémentaire, il
contacte le patient pour venir récupérer son ordonnance. Le médecin choisit donc
l’option ‘Prescrire un examen complémentaire’, puis le prescrit au patient (Le
numéro de l’examen qui a généré cet examen complémentaire est mentionné dans
l’ordonnance), auquel cas le patient se présentera à la réception pour fixer la date du
rendez-vous.
- Exception
1. problèmes de connexion au système ou au PACS.
2. Au cas oû le médecin réalisateur de l’examen juge la nécessite de consulter des
médecins experts, il demande leurs avis.
80
3. Au cas oû le médecin réalisateur de l’examen juge la nécessite de présenter le cas

au colloque du service, il émet une demande au chef de service
- Post-conditions
1. Compte rendu de l’examen est rajouté au dossier du patient.
2. L’examen interprété est rajouté à la liste des examens à remettre.
3. Une demande d’avis est éventuellement émise à des radiologues experts.
4. Une demande d’organisation de colloque est éventuellement émise au chef de
service.
• Besoin d’IHM
1. Liste des examens à interpréter, ou en instance d’interprétation (Attente du compte
rendu d’un expert) est triée par ordre de priorité et de la date d’échéance.
Diagramme de cas d’utilisation : Edition et remise d’un examen complexe

Diagramme
Sécrétaire médicale Remise résultat des examens

Patient
<<include>>
Authentification
Figure IV.6. Diagramme de cas d’utilisation : Edition et remise d’un résultat d’un examen
complexe
Description
• Discrétion sommaire
- Nom du cas d’utilisation : Edition et remise des résultats d’un examen complexe.
- But : Edition et remise des résultats (cliché de radio et compte rendu final) d’un
examen au patient.
- Résumé : Edition d’un résultat d’examen à partir du dossier patient puis remise du
cliché et du compte rendu final.
- Acteurs : Secrétaire médicale (Principal), Patient.
81

- Pré-conditions
1. Connexion, identification et authentification de la secrétaire médicale.
2. Le patient se présente muni d’un bon de retour (Programmé pour la journée)
- Scénarios
1. Le cas d’utilisation commence lorsque la secrétaire médicale se connecte au
système en fournissant son login et son mot de passe.
2. Lorsque le patient se présente muni de son bon de retour pour récupérer les
résultats de son examen, la secrétaire vérifie la date de retour mentionnée sur le
bon et saisit le numéro de l’examen.
3. Si l’examen n’est pas prêt à être remis (l’examen est en instance d’interprétation,
attente de l’avis du médecin expert, ou du colloque), le patient sera appelé dés que
les résultats de son examen seront prêts, l’examen est automatiquement rajouté à la
liste des examens en instance de remise. Sinon la secrétaire médicale lance
l’impression du compte rendu final et du cliché de la radio de l’examen.
4. Elle récupère la radio et le compte rendu qu’elle signe, puis elle met le tous
dans une chemise qu’elle remet au patient.
- Exception
1. Echec de connexion au système.
2. Résultats non disponibles : le patient sera appelé dés que les résultats de son
examen seront disponibles.
- Post-conditions :
1. Résultats de l’examen du patient remis.
2. L’examen (Dont le CR n’est pas disponible) est mis en instance de remise.
• Besoin d’IHM :
1. Liste des examens en instance de remise est triée par date d’échéance.
82
IV.2.1.3. Diagrammes d’activités

« Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils sont
donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de
flots de données. Ils permettent ainsi de représenter graphiquement le comportement d’une
méthode ou le déroulement (la description textuelle) d’un cas d’utilisation » [AUD, 07].
Le formalisme utilisé dans les diagrammes d’activités se présente comme suit :
L’Etat initial marque le début d’un diagramme d’activités,
c’est-à-dire le point de départ par défaut d’un flux de contrôle
d’activités.
L’Etat final marque la fin d’un diagramme d’activités, c’est-à-
dire le point où un flux de contrôle d’activités a été
complètement exécuté.
Une Activité représente l’exécution d’actions atomiques ou
d’opérations et elle cause un changement de l’Etat du système.
Un objet peut être nécessaire à la réalisation d’une activité et il

peut circuler dans un diagramme d’activité. Il est de plus
possible d’écrire l’Etat de l’objet entre crochets en dessous de
son nom. Une relation de dépendance est utilisée pour lier un
objet à une ou des activités.
Une relation de transition montre le chemin d’exécution d’un
flux de contrôle d’activités.
Une relation de dépendance est utilisée pour montrer la
participation d’un objet au déroulement d’une activité.
Le symbole de ramification montre qu’il existe plusieurs
transitions ou chemins d’exécution possibles conditionnés par
une expression booléenne. Une ramification a une transition en
entrée et au minimum deux transitions en sortie.
Un point de divergence montre qu’un flux d’exécution se
découpe en plusieurs chemins parallèles. Il peut avoir deux ou
plusieurs transitions en sortie. La barre noire qui symbolise un
point de divergence peut aussi être représentée verticalement.
Un Point de convergence permet de regrouper des chemins
d’exécution parallèles. Il peut avoir plusieurs transitions en
entrée, mais leur nombre doit correspondre au nombre de
transitions qui suivent le point de divergence qui lui
correspond. Un point de convergence n’a qu’une seule
transition en sortie. La barre noire qui symbolise un point de
convergence peut aussi être représentée verticalement.
Tableau IV.3. le formalisme du diagramme d’activités
83
Ci-après le diagramme d’activités global
Figure IV.7. Diagramme d’activités global
84
Diagramme d’activités (Fixation d’un RDV)
Figure IV.8. Diagramme d’activités (Fixation d’un RDV)
85
Diagramme d’activités (Anesthésie)
Figure IV.9. Diagramme d’activités (Anesthésie)
86
Diagramme d’activités (Réalisation d’un examen)
Figure IV.10. Diagramme d’activités (Réalisation d’un examen)
87
Diagramme d’activités (Interprétation d’un examen complexe)
Figure IV.11. Diagramme d’activités (Interprétation d’un examen complexe)
88
Diagramme d’activités (Edition et remise des résultats d’un examen complexe)
Figure IV.12. Diagramme d’activités (Edition et remise des résultats d’un examen complexe)
89
IV.2.1.4. Diagramme des classes

« Le diagramme de classes est considéré comme le plus important de la modélisation
orientée objet, il permet de modéliser les classes du système et leurs relations
indépendamment d’un langage de programmation particulier. Il s’agit d’une vue statique car
on ne tient pas compte du facteur temporel dans le comportement du système. Alors que le
diagramme de cas d’utilisation montre un système du point de vue des acteurs, le diagramme
de classes en montre la structure interne. Il permet de fournir une représentation abstraite
des objets du système qui vont interagir ensemble pour réaliser les cas d’utilisation. Il est
important de noter qu’un même objet peut très bien intervenir dans la réalisation de plusieurs
cas d’utilisation» [AUD, 07].
Le formalisme utilisé dans les diagrammes de classes se présente comme suit :
Une classe permet de mettre en évidence un objet du système

modélisé.
Une association binaire met en relation deux classes
Une association N- aire met en relation N classes.
Une relation d’héritage permet à une classe ‘fille’ d’hériter des

propriétés d’une classe ‘mère’
Une Note permet de stocker du texte libre dans la description

graphique d'un modèle
TableauIV.4. le formalisme du diagramme de cas d’utilisation
90
Diagramme de classes
Figure IV.13. Diagramme de classes
91
Description des classes

Légende : A : Alphabétique, N : Numérique, AN : Alphanumérique.
Classe Attributs / Méthodes Désignation Type

Examen Attributs
Num_Exam Numéro de l’examen N
Date_Exam Date de l’examen Date
Heure_Exam Heure de l’examen Heure
Etat_Exam Etat de l’examen A
Etat_Pat Etat patient A
Type_Pat Type Patient A
Cas_Clinique_Pat Cas clinique du patient AN
(Urgent /Ordinaire)
Cr_Exam Compte rendu de l’examen AN
Etat_Cr Etat du compte rendu A
Date_Ret Date de Retour Date
Heure_ Ret Heure de Retour Heure
Observations_Anesth Observations Anesthésiste A
Méthodes
FixerRdvExamen()
ModifierRdvExamen()
RéaliserExamen()
InterpreterExamen()
Anesthesie()
Editer_Examen()
Consulter_Examen()
Patient Attributs
Num_Pat Numéro du patient N
Nom_Pat Nom du patient A
Pren_Pat Prénom du patient A
Adr_Pat Adresse du patient AN
Wilaya Wilaya A
DN_Pat Date de naissance du patient Date
Sexe Sexe A
Tel_Pat Téléphone du patient N
Num_Sec_Pat Numéro sécurité sociale patient N
Méthodes
CreerPatient()
ModifierPatient()
Rech_Pat()
Personnel Attributs
Num_Pers Numero personnel N
Nom_Pers Nom personnel A
Pren_Pers Prenom personnel A
Adr_Pers Adresse du personnel AN
Tel_Pers Telephone du personnel N
Fax_Pers Fax du personnel N
Identif_Pers Identif du personnel AN
Password_Pers Password du personnel AN
Fonction_Pers Fonction du personnel A
92
Méthodes
CreerPersonnel ()
ModifierPersonnel ()
SupprimerPersonnel ()
Médecin Attributs
Spe_Med Spécialité du médecin AN
Service
Méthodes
CreerMedecin ()
ModifierMedecin ()
Rechercher_Med()
MédecinQualifie Attributs
Service Service auquel appartient le med AN
Grade Grade du médecin AN
MédecinResident Attributs
Service Service auquel appartient le med AN
Année_Etudes Année d’études du résident AN
TypeExamen Attributs
Num_Typ_Exam Numéro du type examen N
Lib_Typ_Exam Libellé du type examen AN
Cout_Typr_Exam Coût du type d’examen AN
Etat_Pat Etat du patient A
Spe_Type_Exam Spécialité du type d’examen AN
Méthodes (ORL…)
AjouterTypeExamen ()
ModifierTypeExamen ()
Machine Attributs
Num_ Mach Numéro de la machine N
Design_ Mach Désignation de la machine AN
Etat_Mach Etat de la machine A
Nom_Salle Nom de salle A
Nbr_Exam_Jour Nombre d’examens par jour N
Méthodes
AjoutererTypeMachine ()
ModifierTypeMachine ()
SupprimerTypeMachine ()
Antécédent Attributs
Num_Ant Numéro antecedent N
Desig_Ant Designation antecedent AN
Description_Ant Description antecedent AN
Méthodes
AjouterAntecedant ()
ModifierAntecedant ()
ProduitContraste Attributs
Ref_Prod_Contraste Référence Produit de Contraste
Lib_Prod_Contraste Libellé Produit de Contraste
Méthodes
RajouterProdContraste()
93
Etablissement Attributs
Num_Etab Numéro établissement N
Nom_Etab Nom de l’établissement AN
Adr_Etab Adresse de l’établissement AN
Tel_Etab Téléphone de l’établissement N
Fax_Etab Fax de l’établissement N
Méthodes
CreerEtablissement ()
ModifierEtablissement ()
Rechercher_etabliss()
Image Attributs Référence de l’image AN
Ref_Image
Description des associations
Association Classes Associée Cardinalités Attribut

Se fait TypeExamen 1..* Durée_Exam
Machine 1..* (Date de l’examen)
Utilise TypeExamen 1..* Date_tr (Date de travail du médecin
Médecin 1..* sur une machine précise)
Concerné Patient 0..*
Antecedant 0..*
Exige Num_Type_Exam 0..*
Num_Type_Exam 0..*
Génère Num_Exam 1..*
Num_Exam 1
Interpréter Examen 1..*
Médecin 0..*
Necessite Examen 1..*
Produit 1..*
94
Passage au modèle relationnel

Examen (Num_Exam, Date_Exam, Heure_Exam, Etat_Exam, Etat_Pat, Cas_Clinique_Pat,
Cr_Exam, Etat_Cr, Date_Ret, Heure_Ret, Observations_Anesthésiste ,Num_Pat, Num_Pers,
Num_Typ_Exam, Num_ Mach)
TypeExamen(Num_Typ_Exam, Lib_Typ_Exam, Cout_Typr_Exam, Etat_Pat,
Spe_Type_Exam ,Prod_Admi,)
Doc_Type_Exam (Num_Doc_Type_Exam, Age_Patient, Sexe_Patient)
Image (Ref_Image, Num_Exam)
Patient (Num_Pat, Nom_Pat, Pren_Pat, Adr_Pat, Wilaya, DN_Pat, Sexe, Tel_Pat,
Num_Sec_Pat)
Personnel (Num_Pers, Nom_Pers, Pren_Pers, Adr_Pers, Tel_Pers, Fax_Pers, Identif_Pers,
Password_Pers, Fonction_Pers, Num_Etab)
Médecin (Num_Pers, Spe_Med)
MédecinInterne (Num_ Pers, Service, GradeMI)
MédecinExterne (Num_ Pers, Num_Etab, GradeME)
MédecinRésident (Num_ Pers, Service, Année_Etudes)
Machine (Num_ Mach, Design_Mach, Etat_Mach, Nom_Salle, Nbr_Exam_Jour)
Antecedant (Num_Ant, Desig_Ant, Type_Ant)
Produit (Ref_Prod_Contraste, Lib_Prod_Contraste)
Etablissement (Num_Etab, Nom_Etab, Adr_Etab, Tel_Etab, Fax_Etab)
Se fait (Num_Typ_Exam, Num_ Mach, Durée_Exam)
Utilise (Num_Typ_Exam, Num_Pers, Date_tr)
Concerné (Num_Pat, Num_Ant)
Exige (Num_Typ_Exam, Num_Typ_Exam)
Genere(Num_Exam, Num_Exam)
Interpréter (Num_Pers, Num_Exam)
Necessite (Num_Exam, Ref_Prod_Contraste)
95
IV.2.2. Conception du SMA

Après une étude du fonctionnement du système de gestion des examens radiologiques
au sein du service de radiologie de l’hôpital Maillot, nous avons compris que la phase
d’interprétation est une phase critique : En effet, les médecins ne disposent pas d’outils d’aide
pour cerner les différents aspects liés aux cas à traiter, ce qui les obligent (souvent les moins
expérimentés) à consulter leurs collègues expérimentés (souvent occupés ou non disponibles)
pour les aider à interpréter des examens ‘compliqués’.
Nous proposons dans ce qui suit une conception d’un système d’aide à la décision basé
sur un système multi-agents dont les agents sont dotés d’un mécanisme d’apprentissage par
renforcement, implémenté par la technique de classifier system. Cette technique permet de
générer de nouvelles règles en appliquant des raisonnements ‘logiques’ sur des règles
existantes. Les ‘meilleures’ règles générée servent à enrichir la base de connaissances du
système, préalablement initialisée par des connaissances validées, introduites par des
médecins experts.
Pour ce faire, on a choisit l’approche ‘Voyelles’ pour concevoir ce système, notre
conception est divisée en deux phases : la phase d’analyse qui nous permet d’identifier et de
décomposer le problème afin de dégager l’architecture générale du système, la phase de
conception permet la spécification du fonctionnement global du système exprimée sous forme
de diagrammes de comportements. La troisième phase de l’approche ‘Voyelles’ étant relative
à l’implémentation du système multi-agents (Elle sera traitée dans la partie réalisation).
IV.2.2.1. Choix de l’approche de conception

Parmi les méthodologies citées dans l’état de l’art et qui couvre le mieux l’ensemble
des phases de développement d’un système multi-agents, nous avons choisit l’approche
’Voyelles’. Ce choix se justifie par le fait que ‘Voyelles’ repose sur des principes purement
multi-agents : Elle est fondée sur la décomposition de la vue d’un système multi-agents en
quatre dimensions : Agents, Environnement, Interaction et Organisation, (récemment une
cinquième dimension a été ajoutée : Utilisateur).
‘Voyelles’ n’impose pas un formalisme pour la modélisation des composantes du
SMA, elle comprend un ensemble de modèles qui devront être combinés pour aboutir à la
réalisation du SMA. Le schéma global de conception et de développement consiste dans un
premier lieu à ‘agentifier’ le problème grâce à la phase d’analyse, puis à l’aide des différents
96
outils, la phase de conception permet de spécifier le fonctionnement global du SMA. La

figure IV.14 représente le schéma global de conception ‘Voyelles’.
Récursion-Emergence
Principes Mécanismes
Modèles Outils
AIOE AIOE
Choix Instanciation
Problème SMA
Problème Analyse Conception
agentifié opérationnel
Figure IV.14. Schéma global de conception Voyelles [WDS, 05]
IV.2.2.2. Analyse du SMA (Identification des composantes)

L’objet de cette phase consiste à identifier et à décomposer le problème en cinq
composantes fondamentales (agents, environnement, interaction, organisation, utilisateurs)
afin de dégager l’architecture générale du système.
Agents
Nous avons identifié trois types d’agents :
• Agent Interface (AgtInt)
Sert d’intermédiaire entre les utilisateurs et les agents du SMA : il permet de traduire
les requêtes des utilisateurs et les transmets aux agents concernés, lorsque ces derniers lui
renvoient les résultats de leurs traitements, il les affichent au médecin.
• Agent Expert (AgtExp)

Servent d’interlocuteurs avec les médecins, en effet lorsqu’un médecin sollicite l’aide
du système, l’exécution des instances cet agent est lancée : l’agent récupère la requête du
médecin auprès de l’agent interface et fait le traitement correspondant à cette requête, puis
revoie le résultat au médecin par l’intermédiaire de l’agent interface.
97
Environnement
Constitué par ce qui est fixe durant l’activation du système : l’ensemble des agents
modélisés et des objets qu’ils manipulent pour réaliser leurs objectifs. Les agents agissent sur
cet environnement en fonction des entrées qu’ils reçoivent de lui, ces entrées sont les
informations sur les examens (symptômes et interpretations).
Interactions
Les interactions sont au cœur de la problématique des systèmes multi-agents, elles
permettent aux agents de participer à la satisfaction d’un but global, les interactions sont
représentées sous forme de diagrammes de comportement d’AUML (extension du langage
UML) qui montrent les interactions existantes entre les différents agents. On distingue les
interactions utilisateur-agent et les interactions agent-agent :
• Interaction Utilisateur-Agent
Elles correspondent soit à l’action du médecin sur l’interface intelligente (interaction
utilisateur-agent), soit à la représentation des résultats dans une interface graphique
(interaction agent-utilisateur). En effet lors de l’interprétation d’un examen, le médecin
sollicite éventuellement le système d’aide à la décision : il soumet sa requête à l’agent
interface, ce dernier reformule la requête (message FIPA-ACL) et la transmet à l’agent expert
correspondant. Lorsque l’agent interface reçoit les résultats de ses requêtes depuis l’agent
expert, il les reformule et affiche les résultats dans l’interface correspondant au médecin
demandeur.
• Interaction Agent-Agent
Lorsqu’un agent soumet une requête (message FIP-ACL) à un autre agent, ce dernier :
. Refuse la requête en répondant par un message (Refuse) en donnant les raisons du refus.
. Accepte la requête en répondant par un message (Agree) : soit il n’aboutit pas à un résultat,
auquel cas, il répond par un message (Failure), soit il aboutit à un résultat, et répond par un
message (Inform-result) qui contient le résultat de la requête.
Organisation
Une structure organisationnelle est définie par un ensemble de classes d’agents
caractérisées par les rôles qui leurs sont affectés, et l’ensemble de relations abstraites
existantes entre ces rôles. L’organisation structurelle de notre système est donnée dans la
figure IV.15.
98
SMA
Monde
Médecin1 IHM AgtInt1 AgtExp1
AgtDf
Liste des BDD
AgtInt et AgtExp
Médecin2 IHM AgtInt2 AgtExp2
Figure IV.15. Structure de l’organisation
Les interfaces homme-machine «IHM» permettent à l’utilisateur de communiquer

avec son agent interface, ce dernier communique avec les autres agents (DF et AgtExp). Les
agents AgtInt et AgtExp ont accès à la base de donnée.
Utilisateurs
Nous avons identifié deux types d’utilisateurs :
- L’administrateur du système qui a la charge de la maintenance de la base de données et du
système.
- Les médecins qui demandent de l’aide au système pour l’interprétation des examens
radiologiques, et ajoutent à travers eux de nouvelles connaissances à la base de
connaissance du système (cas des médecins expérimentés).
IV.2.2.3. conception du SMA (Choix des modèles fonctionnels)

L’objet de cette phase consiste à choisir les modèles fonctionnels des composantes pour
aboutir à la spécification du fonctionnement global du système exprimée sous forme de
diagramme de comportements.
Architecture des agents
Le choix d’un modèle d’agents se fait essentiellement en fonction des besoins exprimés au
cours de la phase d’analyse, tous les agents disposent d’un module de communication (boites
oû les agents reçoivent leurs messages). L’architecture de nos agents est décrite ci-dessous :
99
• L’agent interface (AgtInt)

C’est un agent réactif, il sert d’intermédiaire entre l’utilisateur et les agents experts pour
transmettre leurs messages, son architecture est représentée par la figure IV.16 :
Module de communication .
avec l’utilisateur
Module de Base de
traitements connaissances
De l’agent DF
Module de communication
inter-agents
Figure IV.16. Architecture interne de l’agent interface (AgtInt)
L’agent interface reçoit la requête du médecin à travers le module de comminations avec

l’utilisateur, traduit la requête en langage FIPA-ACL dans l’unité de traitement, puis la
transmet à l’agent expert via le module de communications inter-agents, sa base de
connaissances contient ses propres données. Il reçoit les résultats de traitement de l’agent
expert dans sa boite aux lettres, fait un traitement sur ces résultats et les remet au médecin.
• L’agent expert (AgtExp)

C’est un agent cognitif doté de capacités d’apprentissage et de raisonnement, cet
apprentissage est implémenté par la technique de classifier system afin d’assurer l’évolutivité
du système par la génération de nouvelles connaissances en appliquant des raisonnements
logiques sur les connaissances existantes, et ainsi enrichir la base de connaissances du
système. L’agent expert communique avec l’agent interface afin de traiter les requêtes du
médecin, son architecture est représentée par la figure IV.17 :
100
Module de communication
inter-agents
Faits
Module de traitements Résultats du raisonnement
(Classifier system)
Données
Règles
Module
Mise à jour
d’apprentissage
Base de (Apprentissage par
connaissances renforcement)
Figure IV.17. Architecture interne de l’agent expert (AgtExp)
Principe de fonctionnement de classifier system

L’apprentissage est une faculté nécessaire à tout système intelligent, il a pour but
d’améliorer son fonctionnement en lui permettant d’évoluer. De nombreux modèles
d’apprentissage commencent à être définis, la figure IV.18 représente ces méthodes :
Réseaux de Par
neurones A partir
renforcement
d’exemples
Symbolique Supervisé
Apprentissage
automatique
Perspectives Non supervisé A partir

génétiques d’explications
Figure IV.18. Classification des méthodes d’apprentissage [DMI, 08]
L’apprentissage par renforcement peut être implémenté par la technique de classifier

system. Les systèmes à base de classifier sont des cas particuliers de systèmes à règles de
production, originellement introduits par Holland depuis 1968 pour concevoir des systèmes
autonomes et évolutifs dont le but est de générer un ensemble de règles ‘SI condition Alors
Action’, permettant d’atteindre un objectif, par l’intermédiaire d’un processus
d’apprentissage. Ces systèmes sont dans la plupart du temps utilisés pour créer des formes de
vie artificielles. Le principe de cette technique est représenté dans la figure IV.19 :
101
Figure IV.19. Agent conçu autours d’un système de classifier [FER, 95]
Un système à base de classifier se présente donc comme une variation d’un système
à base de règles de production dont lequel les faits (messages) sont des chaînes de caractères
(généralement pris dans un alphabet binaire 0,1) de taille fixe et les règles (appelées classifier)
sont des couples de chaînes de caractères dont les éléments sont pris dans l’alphabet précédent
auquel on a ajouté un caractère joker (#) qui peut s’associer à n’importe quel élément. Les
règles comportent un poids correspondant à leurs probabilités de déclenchement. Les
informations provenant de l’environnement sont codées par le système de perception
(Capteurs) sous la forme d’un ensemble de faits. Les règles s’appliquent sur ces faits et
produisent d’autres faits qui peuvent à leurs tours déclencher d’autres classifiers, ou bien
produire des actions dans l’environnement via le système d’exécution (Effecteurs) [FER, 95].
Le rôle du système de Classifieurs est de manipuler les Classifieurs de manière à faire

émerger les meilleures règles possibles. Ceci est réalisé par l’intermédiaire d’un mécanisme
de sélection naturelle consistant à préserver les plus utiles d’entre elles et à remplacer les plus
mauvaises. Pour cela, une force est attribuée à chaque classifieur. Elle représente l’adéquation
du déclenchement d’action lorsque condition est observée. Les règles les plus faibles auront
tendance à mourir pour laisser place aux “descendants” des classifieurs les plus forts via
l’utilisation d’opérateurs génétiques tels que la sélection et la mutation [OSC, 07].
102
Notre système manipule trois tables dans la base de données, la table Symptômes
rassemble tous les symptômes (signes) qui peuvent être observés lors de l’interprétation d’un
examen radiologique, à chaque symptôme est associé son numéro de bit dans la partie
condition du classifieur. La table Interprétations rassemble toutes les interpretations qui
peuvent correspondre à l’apparition d’un certain nombre de symptômes, à chaque
interprétation est associé son numéro de bit dans la partie action du classifieur. La table
Connaissances rassemble toutes les connaissances du système, il s’agit de règles (condition,
action, note) introduites par les médecins experts, ou des règles déduites par les agents experts
grâce à leurs mécanismes d’apprentissage par classifier system.
Figure IV.20. Diagramme de classe pour le traitement par classifier system
Notre système répond donc à deux fonctionnalités complémentaires à savoir :

- Ajout d’une connaissance par un médecin expert : Lorsqu’un médecin expert veut rajouter
une connaissance, sa requête est prise en charge par l’agent interface, ce dernier accède aux
tables Symptômes et Interprétations pour former les parties conditions et actions, une fois la
connaissance est constituée, l’agent interface accède à la table Connaissances, s’il ne trouve
pas la connaissance dans cette table il le rajoute. Sinon si la note de la règle est inférieure à 1,
il met à jour cette connaissance (Note = 1).
- Aide à la décision : Lorsqu’un médecin sollicite l’aide du système, il introduit les
symptômes (signes) qu’il a observé lors de l’interprétation d’un examen radiologique et les
spécialité qu’il souhaite en avoir faire recours, sa requête est prise en charge par l’agent
103
interface, ce dernier accède à la table Symptômes pour former la partie condition du

classifieur, il la transmet à l’agent expert correspondant à la spécialité demandée sous forme
d’un message FIPA-ACL, lorsque ce dernier reçoit ce message, il accède à la table
Connaissances pour vérifier s’il existe dans cette table une connaissance dont la note est 1 et
qui contient cette partie conditions, auquel cas il la transmet sous forme d’un message FIPA-
ACL à l’agent interface, s’il n’existe pas une connaissance qui contient la partie condition
reçue ou que sa note est inférieure à 1, l’agent lance l’algorithme de classifier system, de
nouvelles règles sont alors générées avec les notes correspondant, il enregistre alors ces
nouvelles connaissances dans la table Connaissances, et met à jour éventuellement les
classifiers existants.
Par la suite l’agent expert transmet le résultat de son traitement (partie action du
classifieur déduit et la note correspondant) à l’agent interface sous forme d’un message FIPA-
ACL, lorsque ce dernier reçoit ce message, il accède à la table Interprétations pour former le
résultat à afficher au médecin.
• L’agent DF (AgtDf)
AgtExp1 : - Service y
- Service z
Enregistrer AgtExp2 : - Service y

Rechercher les
les services - Service z
services offerts par les
offerts autres agents
AgtExp i
DF
AgtInt i
(Service pages jaunes)
Figure IV.21. Architecture interne de l’agent DF (AgtDf)
L’agent AgtDf est un service de pages jaunes, il permet aux agents fournisseurs de
services (AgtExp) de s’inscrire, d’enregistrer les services qu’ils offrent, il permet de plus aux
agents (AgtInt) de s’inscrire et de rechercher les services qu’offrent les agents AgtExp.
104
Les diagrammes d’interaction

• Les diagrammes d’interaction utilisateur-agents
- Ajout d’une connaissance
AgtInt BDD
Medecin
Dde ajout connaissance
Ajout connaissance
Confirmation ajout connaissance
Confirmation
Figure IV.22. Diagramme d’interaction : Ajout d’une connaissance

- Aide à la décision
Deux cas se présentent lorsqu’un médecin sollicite l’aide du système : soit la
connaissance à afficher existe dans la table connaissances, auquel cas elle lui sera
affichée, sinon le système déclenche l’exécution du classifier system, de nouvelles règles
sont alors générées, on aura donc deux diagrammes :
- Cas oû la connaissance existe
AgtInt AgtExp BDD
Medecin Demande aide
Traduire requette
Message FIPA
Rechercher diagnostic
Resultat recherche
Message FIPA
Traduire resultats
Resultat final
Figure IV.23. Diagramme d’interaction : Aide à la décision, Cas oû la connaissance existe
105
- Cas de traitement par classifier system
AgtInt AgtExp BDD
Medecin Demande aide
Traduire requete
Message FIPA
Rechercher diagnostic
Resultat recherche
Traitement Classifier System
Ajout classifier
Confirmation ajout classifier

Message FIPA
Traduire resultat
Resultat final
FigureIV.24. Diagramme d’interaction : Aide à la décision, traitement par classifier system

• Les diagrammes d’interaction agents- agents
Figure IV.25. Diagramme de protocoles de demande d’inscription auprès de AgtDf
106
Figure IV.26. Diagramme de protocoles de demande d’inscription auprès de AgtDf
Figure IV.27. Diagramme de protocoles de demande de dés-inscription auprès de AgtDf
107
IV.2.3. Composantes du Workflow

IV.2.3.1. Les ‘3R’ du Workflow
La modélisation effectuée nous a permis de déduire les 3R de notre Workflow qui
sont : les rôles, les règles et les routes.
Des rôles pour accomplir les activités

Un rôle est responsable d’un ou de plusieurs résultats du processus
Participant Rôle
Réceptionniste - Ajout d’un nouvel établissement, d’un nouveau médecin et d’un
nouveau patient.
- Fixation et modification d’un RDV pour un patient
Médecin - Réalisation d’un examen radiologique
- Edition, enregistrement et remise des comptes rendus.
- Edition des bons de retour.
- Interprétation des examens (Edition et enregistrement des
comptes rendus).
- Validation des examens (Edition et enregistrement d’un compte
rendu final).
Secrétaire - Edition des résultats d’examens complexes.
- Signature des résultats auprès des médecins
- Remise des résultas aux patients
Administrateur - Lancer et superviser le système
- Création et suppression des utilisateurs
- Affectation des privilèges (profils) aux utilisateurs
TableauIV.5. Liste des rôles
Des règles pour formaliser la coordination

Les mécanismes de coordination entre sous-systèmes sont traduits dans le Workflow
par des règles de routage :
• Règles implicites : La validation d’un document par un rôle termine l’activité en
cours, change le statut du document et donne ainsi l’autorisation au rôle suivant (ou
bien le même rôle) de commencer son activité.
108
• Règles sur les dates :

- La réalisation d’un examen n’est déclenchée que si la date d’examen est arrivée.
- L’interprétation et la validation d’un examen doivent être réalisées avant
l’échéance.
- La remise des résultats (Compte rendus et cliché de radio) d’un examen (simple ou
complexe urgent) doit être instantané.
• Autres règles
- Le résultat d’un examen est constitué du compte rendu final et du cliché de la radio
(plus éventuellement un bon de retour dans le cas complexe urgent).
- Tous les comptes rendus d’examens doivent être signés avant leur remise.
- Le paiement d’un examen (Cas ordinaire) se fait au moment de la fixation du
RDV.
- Les cas d‘urgence sont pris en charge en priorité et ne sont pas payés.
Des routes pour organiser la dynamique des processus
Dans notre cas, ce n’est pas le document qui circule, mais un participant (autorisé) obtient
le document via un lien vers ce document.
IV.2.3.2. Les formulaires et les documents

Désignation Description
- Formulaire Fiche - Contient des champs pour planifier ou modifier un examen.
RDV
- Formulaire - Contient des champs pour éditer des observations concernant une
observations anesthésie..
anesthésie
- Formulaire compte - Contient des champs pour éditer un compte rendu d’un examen.
rendu
- Formulaire bon de - Contient des champs pour éditer un bon de retour pour récupération
retour des résultats d’un examen pour un patient.
- Formulaire - Contient des champs pour prescrire un nouvel examen pour un
prescription d’un patient.
examen
TableauIV.6. Liste des formulaires
109
Conclusion
Dans cette partie, nous avons effectué l’étude conceptuelle de nôtre système
workflow, Cette étape nous a permis, entre autres, d’aboutir à la construction de la base de
données du système, d’avoir une vision globale des activités qui composent le processus
étudié, les liens entre ces activités et les rôles qui les assurent.
Nous avons aussi introduit une nouvelle approche de résolution de problèmes

complexes dans le domaine d’aide à la décision médicale par la conception d’un système
multi-agents, nous avons utilisé la méthodologie voyelles et le langage UML pour modéliser
ce système. Le rôle de ce système se justifie par l’aide à l’interprétation des examens
radiologiques, par exemple, suite à l’introduction de certains paramètres, le système peut
suggérer un diagnostic approché au cas étudié, ou même proposer des examens
complémentaires ou rappeler le médecin d’un traitement préalable ou future particulier.
Une fois la conception achevée, reste à implémenter les solutions proposées, il s’agit
en premier lieu de définir l’architecture réseaux du système, de choisir l’environnement de
développement approprié et de présenter le fonctionnalités globales du système ainsi que les
mesures de sécurité à prendre en considération, c’est l’objet de la partie suivante.
110
Introduction
Après la modélisation du processus et son optimisation, il convient de réaliser
l’application workflow. Le choix de la technologie sous laquelle sera basée l’application
dépend du processus à automatiser. Cependant la messagerie semble convenir dans le cas des
processus administratifs tel que le processus de la gestion des examens radiologiques.
L’intégration d’une application workflow dans une entreprise nécessite une plate-
forme capable de supporter les mécanismes de coopération, de coordination et de
communication. Le marché du logiciel propose plusieurs plates-formes pour ces applications
particulières : Lotus Notes, MS Exchange, Netscape Messenger, Novell Groupewise, etc.
Le meilleur moyen pour construire un SMA est d’utiliser une plate-forme multi-
agents. Une plate forme multi-agents est un ensemble d’outils nécessaires à la construction et
à la mise en service d’agents au sein d’un environnement spécifique. Essentiellement des
produits résultants des travaux de recherche, et dont le choix dépend du domaine
d’application, il existe plusieurs plate-forme multi-agents : Jade, Jack, MadKit,…
Dans cette partie nous allons présenter la mise en œuvre des différents composants de
notre application. Il s’agit de en premier lieu de définir l’architecture réseau du système,
ensuite de présenter l’environnement de développement et de justifier les outils choisis :
système de gestion de bases de données, plates-formes d’implémentation du workflow et du
système multi-agents, ainsi que la présentation de quelques fonctionnalités du système et des
mesures de sécurité à prendre en considération pour assurer la sécurité du système et la
confidentialité des données et des informations.
110
Chapitre V Réalisation
V.1. Architecture réseau du système

L’architecture de notre système est 3 tiers, c’est l’architecture même de, pratiquement
toutes les applications de bases de documents de Lotus Notes. Les principaux avantages d’une
telle architecture sont : la facilité de déploiement (donc réduction des coûts), l’application en
elle-même n’est déployée que sur le site serveur, le client ne nécessite qu’une configuration
minimale et accède à l’application à travers son navigateur web (Lotus Notes), une évolution
régulière du système peut être envisagée, en effet cette évolution ne nécessite que la mise à
jour de l’application sur le site serveur.
Utilisateur1 Utilisateur2
Navigateur Navigateur
Lotus Notes Lotus Notes
Requête http Requête http
Serveur
Base Notes
NSF
Module workflow
Pilote JDBC Plate forme JADE
BDD Oracle 10j
FigureV.1 : Architecture générale du système
111
V.2. Environnement de développement

V.2.1. Langage de programmation
Le langage répondant au mieux à la mise en œuvre de notre conception en termes de
programmation orientée objets, de réutilisation et d’accès aux bases de données, est le langage
Java, Lotus Notes et Jade sont développés en Java, et proposent donc l’exploration de
librairies Java ce qui facilite l’interopérabilité entre ces deux plates-formes.
Java est développé par Sun microsystem en 1995, et a connu rapidement un énorme succès. Le
développement d’un système avec Java présente beaucoup d’avantages à savoir :
- « write once, run everywhere » constitue la force de Java, ceci est réalisé par une
bibliothèque d'exécution qui se veut indépendante de la plateforme : il est possible
d'utiliser le même code pour Windows 95/98/NT, UNIX, Macintosh, etc.
- Il est possible de développer des modules (objets) séparément, qui vont s’échanger des
messages, et cela répond parfaitement à notre besoin de développement d’agents.
- Java nous permet un accès simplifié aux bases de données, soit à travers la passerelle
JDBC-ODBC ou à travers un pilote JDBC spécifique au SGBD.
V.2.2. Choix du SGBD

Nous avons choisit Oracle 10J pour implémenter notre base de données, c’est un
SGBD développé par Oracle Corporation, leader mondial des SGBDR. Ce choix est motivé
par le fait que Oracle 10J est un SGBD relationnel supportant le langage SQL pour
l’interrogation des bases de données, c’est aussi un SGBD qui donne un importance
particulière à la sécurité et à la confidentialité des données, ce qui est fortement recommandé
dans les applications dédiées au domaine médical. De plus il gère de manière fiable une
grande quantité de données dans un environnement multi-utilisateurs et fournit des solutions
efficaces pour la récupération des données après incident.
V.2.3. Choix de la plate-forme workflow

Notre choix s’est orienté à Lotus Notes, car Lotus Notes est à la fois un système de
messagerie, un outil de stockage, de partage et de diffusion de l’information. C’est aussi une
plate-forme puissante de développement d’applications dédiées au travail coopératif et une
porte d’accès à internet. Lotus Notes est le leader mondial des logiciels de groupeware, il
offre à travers son interface, les fonctionnalités les plus évoluées en matière de courrier
électronique : carnet d’adresses, agendas, navigation web, etc.
112
Lotus Notes est un logiciel multi plate-forme, développé par IBM, et répond aux
besoins des entreprises en matière de messagerie et de travail coopératif en offrant une
infrastructure fiable et puissante de développement d’applications groupeware grâce à des
outils intégrés conçu spécialement pour ça, à savoir Lotus Domino Server et Lotus Domino
Designer.
V.2.4. Choix de la plate-forme multi-agents

On a choisit la plate-forme Jade pour implémenter notre système multi-agents, ce
choix est motivé par le fait que Jade est écrite entièrement en java, elle bénéficie donc des
avantages de ce langage en terme de portabilité et de souplesse. C’est aussi un produit open
source (gratuite) et repend aux normes FIPA-ACL. De plus cette plate-forme n’exige pas une
méthodologie de conception du système multi-agents, elle laisse le concepteur libre choix de
la méthode la plus adaptée pour son système. Jade offre un ensemble d’outils graphiques qui
permettent le débogage et l’administration du SMA, de plus, des agents dont les
fonctionnalités sont très utiles, sont implémentés et son chargés à son lancement.
V.3. Description des fonctionnalités du système

La page authentification permet à un utilisateur de se connecter au système pour
assurer ses fonctions, une interface personnalisée lui est affichée selon son
profil.
FigureV.2 : Interface authentification
113
L’administrateur du système a à sa charge de veiller sur le lancement du serveur

Domino ainsi que le serveur de la plate-forme Jade, il assure de plus d’autres fonctionnalités à
savoir : la création et la modification des profiles des utilisateurs du système, la création de
nouveaux types d’examens,…
FigureV.3 : Interface administrateur
FigureV.4 : Création d’un utilisateur
114
Le réceptionniste assure la planification et la modification des rendez-vous des

examens, à partir de son interface il peut ajouter un nouvel établissement, un nouveau
médecin et un nouveau patient, la recherche d’un patient se fera par numéro ou par nom.
FigureV.5 : Interfacee fixation rendez-vous

Une fois le réceptionniste termine de renseigner les informations de l’examen, il édite
une fiche de rendez-vous qu’il remet au patient après avoir reçu le payement de l’examen.
FigureV.6 : Fiche de rendez-vous
115
L’anesthésiste à a sa charge d’injecter le produit de contraste nécessaire à l’examen

demandé par le patient. L’anesthésiste sélectionne ce produit et mentionne ses observations
sur la réaction du patient vis-à-vis du produit injecté.
FigureV.7 : Réalisation anesthésie
116
Le médecin a à sa charge de réaliser l’examen, de l’interpréter. Il a la possibilité de

consulter des examens antérieurs du patient, de consulter ses antécédents.
FigureV.8 : Interface réalisation d’un examen

Pour la partie aide à la décision, le médecin peut rajouter des connaissances au système,
consulter d’autres collègues via le système de messagerie…
FigureV.9 : envoi d’un message
117
La secrétaire médicale assure les fonctions liées à la remise des résultats des examens,
elle recherche les résultats d’examens à éditer par l’intermédiaire de son interface.
FigureV.10 : Interface de la secrétaire médicale
FigureV.11 : Fiche compte rendu d’examen
118
V.4. Les droits d’accès

Rôle Niveau d’accès Privilège
Administrateur Gestionnaire - Créer et supprimer des utilisateurs
- Affecter et modifier des profils des utilisateurs
- Consulter les dossiers patients.
Réceptionniste Auteur - Créer et modifier des fiches RDV.
- Ajouter et modifier des informations d’un
établissement, un médecin ou un patient.
Médecin Auteur - Consulter les dossiers patients (Informations
personnelles, antécédents, examens antérieurs,…)
- Editer des bons de retour et des comptes rendus
finaux.
- Ajouter de connaissances au système.
- Consulter le système d’aide à la décision.
Secrétaire Lecteur - Consulter les examens à éditer (à rendre)
V.5. Sécurité du système

La sécurité des systèmes informatiques est un volet très important qu’il faut prendre en
considération durant la phase de développement et de déploiement des applications conçues.
Les informations médicales sont d’une extrême importance, la confidentialité des données des
malades doit être respectée. En effet des mesures de sécurité doivent être mises en place :
L’accès aux fonctionnalités de l’application est géré par mot de passe, en effet chaque
utilisateur qu’il soit réceptionniste, paramédical, médecin, secrétaire, possède un login et
un mot de passe avec lesquels ils se connectent au système, ces login et un mot de passe
sont enregistrés dans la base de données que seul l’administrateur aura accès.
Une interface personnalisée est affichée à chaque utilisateur, le réceptionniste ne peut
accéder aux fonctionnalités d’un médecin et vice versa, donc le système ‘responsabilise’
ses utilisateurs.
Un journal des transactions est généré par le service d’annuaire de Lotus Notes.
Des copies de la base de donnée doivent être effectuées périodiquement.
119
Conclusion
Tout au long de cette partie, nous avons procédé à la présentation des étapes
d’implémentation des solutions qu’on a proposé dans la partie conception, nous avons
présenté en premier lieu l’architecture réseaux de notre système et l’environnement de
développement, nous avons ensuite donné une illustration de quelques fonctionnalités du
système ainsi que les mesures de sécurité à mettre en place.
Notre système gère les principaux aspects liés à la gestion des examens radiologiques
du service de radiologie de l’hôpital Maillot à savoir : la prescription des examens, la fixation
des rendez-vous, la réalisation des examens, la consultation du dossier patient, l’interprétation
des images et la restitution des résultats des examens aux patients.
On a aussi introduit un mécanisme pour doter le système de plus de flexibilité en

mettant en place un système multi-agents pour être un support d’aide à la décision médicale.
Ce système est à la fois évolutif et adaptatif, ce qui signifie que l’on pourra améliorer le
processus en ajoutant des fonctionnalités nouvelles et en introduisant d’autres agents pour
effectuer d’autres tâches, et cela sans affecter le fonctionnement du système.
119
Conclusions et perspectives
Le système de santé algérien est en pleine restructuration afin de rattraper les années
de retard engendrées par différentes causes, les nouvelles technologies peuvent donner une
impulsion et aider nos institutions hospitalières à développer des pratiques modernes dans
l’exercice de l’activité médicale.
Le service de radiologie est une structure complexe qui ne peut correctement

fonctionner que s’il existe une communication et une coopération entre les différents acteurs
afin de traiter au mieux les patients. Ces exigences ne peuvent être satisfaites que par le
développement de systèmes supportant le travail collaboratif tel que le workflow, et la mise
en place de systèmes d’aide à la décision assistés par un système multi-agents.
Ce projet qui nous a été proposé au CERIST au sein du service de radiologie de

l’hôpital Maillot, nous a été très bénéfique dans la mesure oû il nous a permis d’étudier deux
technologies qui font l’actualité du marché du logiciel à savoir le workflow et les systèmes
multi-agents, et de découvrir leurs puissants apports dans le domaine de développement
d’applications d’entreprises.
On espère avoir réalisé les objectifs qui nous ont été assignés avant d’entamer ce
projet, mais on est conscients que la mise en place d’un workflow radiologique doté d’un
système d’aide à la décision n’est pas une mince affaire, et ne peut être achevé dans le cadre
d’un projet de fin d’études, on espère inscrire ce projet dans la continuité, et d’envisager des
développement d’avenir, à savoir :
Mise en place d’un système d’information hospitalier coopératif, en lui intégrant le
workflow radiologique et le système PACS, ainsi la prescription et la consultation
d’examens radiologiques soient possibles via le réseau de l’hôpital.
Intégration de la téléradiologie dans les activités du service en permettant l’accès par
télécommunication à l’examen en cours mais également au dossier du patient pour le
travail quotidien à l’hôpital et pour la consultation d’experts.
Mise en place d’un réseau de santé intégrant de petits hôpitaux et cliniques privées, ainsi,
le dossier radiologique sera toujours disponible et puisse suivre le patient où qu’il soit et
assurer la continuité des soins.
Améliorer le système d’aide à la décision par la conception d’une ontologie médicale.
120
Bibliographie
[AIT, 04] « conception et réalisation d’un environnement de support à la pédagogie de

projet à base de système multi-agent », AIT HAMMOUDA Abdelkrim &
ARBAOUI ELHADJ Abdelmalek, Université : INI Année : 2004.
[AIM, 91] « Les réseaux de communication et d'archivage des images médicales » Osman
Ratib, Denis Hochstrasser, Jean-Raoul Scherrer, Unité d’Imagerie numérique,
Centre d'Informatique Hospitalière Hôpital Cantonal Universitaire de Genève
Année : 1991
[AMB, 99] « Les agents mobiles – Une introduction » Nicolas Esposito DASSAULT
SYST`EMES – Recherche et nouvelles technologies Année : 1999.
[AUD, 07] « UML 2.0 » Laurent AUDIBERT Institut Universitaire de Technologie de

Villetaneuse – Département Informatique Année : 2007.
[BEN, 02] « Le système d’information hospitalier comme outil d’aide à l’analyse et à la

décision dans le cadre de la réforme hospitalière », thème de la communication
R. Benamirouche Année 2002.
[CLB, 02] « Création d’une librairie de Balises pour l’insertion d’agents JADE dans des
pages JSP », Olivier Fourdrinoy Faculté Jean Perrin, Université d’Artois, Lens.
Année : 2002.
[CPR, 07] « Organisation de la téléradiologie : Guide pour le bon usage professionnel et

déontologique de la téléradiologie », élaboré par le Conseil Professionnel de la
Radiologie (G4) et par le Conseil national de l’Ordre des médecins Année : 2007
[DAM, 96] « Intelligence artificielle distribuée et développement de systèmes

d’information : une approche multi-agents pour le développement de systèmes
d’information » Dalila AMZAL Université : INI Année : 1996.
[DAV, 98] « Working Knowledge : How organisations manage what they know »,
Davenport.T & Prusak.L, Harvard Business School Press Année: 98
[DAY, 90] « Examination of architecture to allow integration of image data with hospital
information systems». Dayhoff RE, Maloney DL, Kusmak PM Amsterdam.
IEEE Année 1990.
[DFB, 05] « Conception et réalisation d’un système d’information radiologique » Djaffer

Faycel Benali & Naziha Mahrouche INI Année : 2006
[DIL, 96] « Une approche multi-agents des systèmes de bureautique communicante »

DILLENSEGER Bruno Année : 1996.
[FER, 95] « Les systèmes Multi-Agents – vers une intelligence collective »
Jacques FERBER Edition : InterEdition Année : 1995.
[IGS, 89] « Informatique et gestion des unités de soins » P. DEGLOUET, J-C. STEPHANE,
A. VENOT et P. J. YVON Paris Année : 1989.
[KHO, 98] «Groupware & Workflow » Setrag KHOSHAFIAN & Marek
BUCKEIWCZ Edition: Masson Année : 1998.
[KIF, 07] « Application d’une approche multi-agent pour la conception d’une mémoire
d’entreprise dédiée au risques sismiques », Ammar KIFOUCHE & Mourad
HAROUN Université : INI Année : 2007.
[LAB, 06] « Modélisation et simulation orientée agent de chaines logistiques dans un

contexte de personnalisation de masse », Olivier LABARTHE Université : Paul
CEZANNE Année : 2006.
[LEB, 03] « Un simulateur multi-agents pour l’aide à la décision d’un collectif : application
à la gestion d’une ressource limitée agro-environnemental », M. LE BARS
Université Paris Dauphine Année : 2003.
[LEV, 00] « Le propjet workflow » Serge K.LEVAN Edition: Eyrolls, 2000.
[LUC, 07] « TÉLÉMÉDECINE : Considérations éthiques déontologiques et de responsabilité

médicale » Docteur Jacques LUCAS Conseil national de l’Ordre national des
Médecins (France) Année : 2007.
[MUL, 02] « Des systèmes autonomes aux SMA interaction, Emergence et systèmes
complexes », Jean-Pierre MÜLLER, Université de Montpellier II Année : 2002.
[MTC, 03] « Un environnement de conception multi-agents pour le pilotage des systèmes de

production », Mohammed TCHICOU, Université PAU et des pays de l’Adour ,
Année : 2003
[OGC, 02] « Comparaison de trois techniques de modélisation de processus: ADONIS,

OSSAD et UML » Olivier GLASSEY Jean-Loup CHAPPLET Working paper
de l'IDHEAP 14 Année 2002
[OSC, 07] « Optimisation de l’Algorithme de Dead Reckoning par Systèmes de

Classifieurs », TORKI Samir Institut de Recherche en Informatique de
Toulouse : Équipe VORTEX Année : 2007.
[PCW, 06] « Automatisation de processus collaboratif workflow », HAMDAOUI bdennour

LAGA Nassim, Université : INI Année : 2006
[PIC, 04] «Méthodologie de développement de systèmes multi-agents adaptatifs et

conception de logiciels à fonctionnalités émergentes», G.PICARD Université Paul
Sabatier d Toulouse 3 Année : 2004.
[POM, 01] « Programmation Orientée Multi-Agents : Développement et Déploiement de

Systèmes Multi-Agents Voyelles », Pierre-Michel Ricordel laboratoire LEIBNIZ
Année : 2001.
[PMR, 01] « Programmation Orientée Multi-agents : Développement et Déploiement de
Systèmes Multi-agents Voyelles », Pierre-Michel Ricordel Université : INPG
Année : 2001.
[RAT, 90] «Multimodality image file format for PACS and teléradiomogy», Ratib O, Appel
R, Cherrer JR Radiology, Année 1990.
[RCA, 91] « Les réseaux de communication et d'archivage des images médicales », H.

Ducrot, E. Martin et J. -R. Scherrer Unité d’Imagerie Numérique, Centre
d'Informatique Hospitalière (Hôpital Cantonal Universitaire de Genève),
Année : 1991.
[SGW, 05] « Réalisation d’un système de gestion de workflow à base de la technologie

multi-agents pour le domaine hospitalier », FERHI Amar & IGUERBE Adlane ,
INI Année : 2005
[STR, 02] « Système d’agents normatifs, conception et outils logiques », STRATULAT

Tiberiu Université de Caen Année : 2002.
[THO, 05] « Proposition d’un formalisme pour la construction automatique d’interactions

dans les systèmes multi-agents réactifs », Vincent THOMAS, Université de
Nancy I Année : 2005
[TIM, 91] « Traitement de l’information médicale : méthodes et applications hospitalières »

P. DEGOULET, M FIESCHI, Préface de F GREMY Edition Masson Année :
1991.
[TOU, 05] « Diagnostic logique des systèmes complexes dynamiques dans un contexte
multi-agent » TOUAF Samir Université Joseph Fourier Année : 2005
[UEA, 03] « UML en action : de l’analyse des besoins à la conception en Java », Pascale
ROCQUES & Franck VALLÉE Editions : Eyrolls Année : 2003.
[VAN, 02] « Un système de Workflow flexible pour la formation ouverte et à distance »
Tomas VANTROYS Yvan PETER Université de Lille Année : 2002.
[WDS, 05] « Workflow de décision coopérative à base de système multi-agents : cas de

processus de décision spatiale », Hedjazi Dellal Badiâa INI : Thèse magistère
Année 2005/2006.
[WFE, 06] «La découverte de workfow Transactionnel pour la Fiabilisation des exécutions »,
Walid Gaaloul Université Henri Poincaré Année : 2006
[WGI, 06] «Conception et réalisation d’un système workflow pour la gestion d’identité du
personnel de NAFTAL Spa », METAI Oahiba TARBINT Fethi Université : INI
Année : 2006.
[WPA, 03] «conception et réalisation d’une application workflow pour processus

administratif », BOUAFIA Lamin CHAROUATI Mohammed Université : INI
Année : 2003.
[WST, 02] « Télémédecine » Dr Werner Stauffacher & Willi Roos Académie suisse des
sciences techniques Année : 2002.
Webographie
[BIO, 08] www.BPMInstitute.org
[CCM, 07] http://www.commentcamarche.net
[COT, 08] http://www.coto.org
[DMI, 08] http://www.dmi.usherb.ca
FRM, 07] http://www.frm.org/informer/
[IBM, 08] www.ibm.com
[INT, 08] www.intelerad.com
[KSI, 07] http://ksi.cpsc.ucalgary.ca
[LIM, 05] http://www.limsi.fr
[OOP, 02] http://www.oopartners.com
[WMC, 07] http://www.wfmc.org

[IGM, 08] http://www-igm.univ-mlv.fr
Annexes
Annexe I : Lotus Notes
I.1. Présentation [IGM, 08]

Lotus Notes est le leader mondial des logiciels multi plates-formes de groupeware
développé par IBM, il s'articule autour de trois activités : communiquer, organiser et
partager. On va donc avoir un certains nombre d'outils qui vont aider à la réalisation de ces
actions. Des applications Notes comme la base Mail ou les forums vont permettre le partage
et la gestion des documents et la communication entre les personnes.
Lotus Notes est donc un outil de création, d'organisation et de partage de documents
d'où la notion de GroupWare. Ces documents peuvent contenir du texte, des graphiques, des
images, des vidéos et sont stockés sous forme de bases en un lieu unique (Serveur) pour que
tout le monde puisse partager les données les plus récentes.
Une base de documents Notes est un ensemble de documents qui ont un rapport les
uns avec les autres, que l'on peut organiser pour en faciliter l'accès et la gestion. Ainsi,
l'utilisation d'une boîte mail passe par une base de documents traitée par Notes (Chaque Email
correspond à un document et est régi par certaines règles).
Messagerie
Communiquer
Workflow Espaces de discussions
Organiser Partager
Gestion documentaire Partage de ressources
Figure 1 : activités de Lotus Notes
122
Annexes
I.2. Composition d’une base notes

Une base Notes se décompose en deux parties :
• Les éléments de structure de la base
Forment le squelette de la base. C'est la façon dont va être organisée la base et
comment vont être affichées et manipulées les données. C'est la partie fonctionnelle d'une
base. Le rôle d'un développeur Lotus Notes va donc être de construire cette partie
fonctionnelle de la base.
• Les documents de la base
Contiennent les données sous forme de champs, ce sont ces mêmes champs qui sont
manipulés par les éléments de structure organisant et faisant vivre ainsi la base Notes.
Les utilisateurs ne voient que les documents et ils utilisent l'application à travers ceux -ci.
Figure 2 : structure d’uns base de documents [IGM, 08]
I.3. L'environnement Lotus Notes

Notes est utilisé par des groupes d'individus à travers un réseau. Un réseau est un
groupe d'ordinateurs connectés pour partager des informations.
Les bases de documents sont donc stockées sur des serveurs Notes avec lequel on échange des
informations par le client Notes (Voir Les clients Notes).
Il est aussi possible de créer une base en local (sur son propre poste) et de la répliquer
123
Annexes
ensuite avec les serveurs Notes : on peut ainsi travailler à distance avec une réplique de la
base.
Figure 3 : environnement lotus notes[IGM, 08]
L'utilisateur itinérant dispose aussi avec Lotus Notes d'un moyen, efficace de consulter
son courrier hors connexion avec le serveur de messagerie, d'interroger des bases
d'informations enregistrées sur le disque dur de son portable. Le courrier et les bases
d'informations sont mis à jour périodiquement par connexion avec les services de l'entreprise.
I.4. Le serveur Domino

Le serveur Domino est une évolution de la version 4.0 : c'est en fait un serveur Http
qui est inclut au produit Lotus Notes.
Plus précisément, le serveur Domino (serveur fonctionnant sous n'importe quelle plate-forme,
notamment Windows ou UNIX) fournit aux utilisateurs du client Notes et aux autres serveurs
Domino des services, tel que l'acheminement du courrier Notes.
Le service HTTP est une tâche du serveur Domino qui ajoute les fonctionnalités d'un serveur
Web au serveur Notes. Ci-dessous, un schéma de l'architecture Notes/Domino :
124
Annexes
Figure 4 : l'architecture Notes/Domino[IGM, 08]
Ce service étend l'accès des utilisateurs Web aux bases de documents Notes, aussi bien
en lecture qu'en écriture. La partie HTTP du serveur demande au serveur Notes les
documents, qui seront alors convertis au format HTML puis délivrés au client Web sous
forme de fichier Html. Si un client Web soumet un nouveau document, le même processus a
lieu dans l'autre sens et le document est stocké dans la base Notes.
Ainsi, les documents sont traités directement sur la base Notes et s'adaptent sans conversion
sous un client Notes. Et pour qu'ils puissent être assimilés par un navigateur, le serveur
Domino opère une conversion pour l'adaptation en client Web. On peut donc considérer deux
modes de développement selon que l'application est destinée à être utilisée dans un navigateur
(Client Web) ou dans le client Notes : les langages utilisés et la programmation ne sont pas les
mêmes en fonction du type de page voulu.
125
Annexes
Les deux modes d ’accès aux bases Notes

Si l'on veut remettre dans le contexte les différents clients de Notes, Voilà comment on
peut schématiser l'ensemble des accès aux applications Lotus Notes.
Figure 5 : accès aux applications Lotus Notes[IGM, 08]
Les clients Notes

Le client Administrateur : client de paramétrage du serveur Notes.
Le client Utilisateur (client Notes) : client accessible par tous permettant l’accès aux bases de
travail (mail, forum, forum technique, autres applications…).
Le client Designer : client du développeur et interface de développement Notes.
Le client Web
Le client Web correspond aux navigateurs Web (Internet explorer, Netscape...). On
peut, grâce au serveur Domino atteindre les applications sur le serveur Notes en mode Web.
I.5. Les clients du logiciel Lotus Notes
On appelle "client" toute interface graphique avec laquelle on accède à une base à
partir du poste local. C'est le programme avec lequel va se connecter un utilisateur au serveur
Lotus Notes.
Les clients Notes
L'environnement Notes est décomposé en trois clients :
• Le client Administrateur : c'est le client de paramétrage du serveur Notes ; seuls les
administrateurs y ont accès.
126
Annexes
• Le client Utilisateur (client Notes) : c'est le client accessible pour tous, offrant les bases de
travail classiques (mail, forum, forum technique…).
• Le client Designer : c'est le client du développeur que nous verrons en détail plus loin.
Le client Web
En plus de la partie Notes, les bases Lotus Notes sont désormais accessibles par un client
Web grâce au serveur Domino :
Le client Web correspond à l'accès que les utilisateurs utilisent pour accéder aux applications
en passant par un navigateur (Internet explorer ou Netscape par exemple). Une application est
accessible par ce client pour tous les utilisateurs ayant un accès à la base et offre ainsi la partie
Web de l'application.
Les utilisateurs Notes
On peut distinguer trois types d'utilisateurs :
• Les administrateurs gèrent les réseaux, les bases Notes et assurent aux utilisateurs l'accès
aux bases qui leur sont destinées. Ils passent par le client Administrateur.
• Les utilisateurs créent, consultent, modifient et impriment des documents stockés dans les
bases de documents Notes par le client Notes.
• Les développeurs créent et organisent les bases pour un partage et une gestion des
informations entre les utilisateurs. Ils passent par le Client Designer pour créer les
applications.
Chaque développeur possède un client Designer et un client Notes, le premier pour créer et le
second pour tester et utiliser les applications.
I.6. Le client Designer
Un outil de développement convivial
Le client Designer permet de développer des applications Web/Notes pour Intranet,
Extranet et Internet. Une application correspond à une ou plusieurs bases qui vont contenir les
éléments de structure de l'application. Une fois ces éléments mis en place, la base va s'enrichir
avec les documents créés par les utilisateurs au moyen de la structure mise en place.
Le client designer se présente de la façon suivante :
127
Annexes
Figure 6 : Le client designer

A gauche, on peut voir une liste des bases en cours. Pour chaque base s'ouvre un sous menu
proposant tous les éléments de structure possible pour l'élaboration d'une base. Ces éléments
sont détaillés dans le tutoriel.
A droite se trouve l'élément de structure à construire avec différents objets à l'intérieur de
celui-ci. Ces objets sont des champs avec des propriétés diverses ce qui permet de générer des
formulaires de données. Ces éléments sont présentés en détail dans la partie "Introduction à
l’outil de conception Notes".
128
Annexes
Annexe II : La plate-forme Jade

Depuis quelques années, une évolution de la programmation orientée objet se dessine
à l’horizon : la programmation orientée agent (proposée pour la première fois par Yoov
Schoham). En effet la programmation orientée objet n’est pas toujours adaptée aux besoins
des applications d’aujourd’hui. Les systèmes sont souvent distribués et décentralisés. Ils
interagissent et communiquent entre eux et doivent s’exécuter indépendamment les uns des
autres.
II.1. Présentation de JADE

JADE (Java Agent DEvelopment Framework) est une plate-forme multi-agents crée
par Bellifemine, Poggy et Rimassa en 1999, elle permet le développement et l’exécution de
systèmes multi-agents conformes aux normes FIPA 1997. La plate-forme est implémentée en
Java et fourni deux composantes de base : Une plate-forme agents compatible FIPA et un
paquet logiciel pour le développement des agents Java inclut[LIM, 05] :
- Un environnement d’exécution (runtime environnement) où les agents JADE vivent.
- Une bibliothèque de classes que les programmeurs peuvent utiliser (directement ou en les
spécialisant) pour développer leurs agents.
- Une suite d’outils graphiques qui permet d’administrer et de surveiller l’activité courante
des agents.
II.1.1. Conteneurs et Plate-formes
Chaque instance de l'environnement d'exécution de JADE est appelée « conteneur »
(container) car elle peut contenir plusieurs agents. L'ensemble des conteneurs actifs est appelé
« plateforme ». Dans chaque plateforme, un conteneur spécial appelé conteneur principal
(main container) doit toujours être en activité, les autres conteneurs s'enregistrent auprès de
celui-ci à leur démarrage.
La figure 1 illustre, à travers un exemple, les notions définies ci-dessus. Cet exemple montre
deux plateformes JADE composées respectivement d’un et de trois conteneurs. Les agents
JADE sont identifiés par un nom unique. Grâce à la connaissance de leurs noms respectifs, les
agents peuvent communiquer de façon transparente, sans avoir à prendre en considération la
localisation de chacun : même conteneur (exemple des agents A2 et A3), conteneurs
différents au sein de la même plateforme (exemple des agents A1 et A2) ou plateformes
différentes (exemple des agents A4 et A5).
129
Annexes
Figure 7 : Conteneurs et Plate-formes[LIM, 05]
La distribution de ces conteneurs à travers un réseau d'ordinateurs est permise à

condition que la communication RMIentre leurs hôtes soient conservées. Chaque conteneur
d'agents est un objet serveur RMI qui gère localement un ensemble d'agents. Il règle le cycle
de vie des agents (création, suspension, attente et destruction). Il assure en plus, le traitement
de tous les aspects de la communication : répartition des messages ACL reçus, routage des
messages selon l’agent destinataire (receiver) et dépôt des messages dans les files de
messages privées des agents. Pour les messages vers l'extérieur, le conteneur d'agents
maintient assez d'information pour chercher l'emplacement de l'agent récepteur et pour choisir
une méthode de transport convenable pour expédier le message ACL.
La plate-forme offre une interface graphique utilisateur (GUI) pour la gestion à
distance qui permet de contrôler et surveiller le statut des agents, par exemple arrêter et
remettre en marche un agent. L'interface graphique permet aussi de créer et de commencer
l'exécution d'un agent sur un hôte éloigné, à condition qu'un conteneur d'agents s'exécute déjà
130
Annexes
sur cet hôte. L'interface elle-même a été implémentée comme un agent, appelé RMA (Remote
Monitoring Agent).
Toute la communication entre les agents et l'interface (GUI) et toute la
communication entre cette interface et l'AMS est faite par ACL via une extension ad hoc de
l'ontologie des agents de gestion FIPA.
JADE supporte la gestion des comportements coopératifs. Le runtime inclut quelques
fonctions complexes prêtes à l'emploi pour les tâches les plus communes dans la
programmation agent, comme des protocoles d'interaction de FIPA. JADE offre entre autres
un certain JessBehaviour qui permet la pleine intégration dans JESS, où JADE fournit le GUI
de l'agent et garantit la conformité de FIPA, alors que JESS est le moteur qui exécute tout le
raisonnement nécessaire. On a donc la possibilité de créer des agents intelligents en délégant
le raisonnement à d'autres outils.
II.1.2. La bibliothèque du JADE

La plate-forme JADE est composée des principaux packages suivants :
- Jade.core implante le noyau du système. Il possède la classe Agent qui doit être étendue
par les applications des programmeurs. Une classe behaviour (comportement) est
contenue dans jade.core.behaviours, qui est une sous classe de jade.core. Les
comportements implémentent les tâches ou intentions des agents.
- Jade.lang qui contient un sous package pour chaque langage de communication utilisé par
JADE en particulier jade.lang.acl.
- Jade.content contient un ensemble de classes qui permettent de définir des ontologies.
- Jade.domain contient toutes les classes Java qui représentent les entités Agent
Management définies par FIPA en particulier AMS et DF.
- Jade.gui contient un ensemble générique de classes utiles pour la création de GUI pour
l’affichage, l’édition des messages ACL, et de la description des agents.
- Jade.mtp contient une interface Java que chaque MTP (Message Transport Protocol) doit
implémenter.
- Jade.proto contient des classes qui modélisent les protocoles standard d’interaction. Les
classes permettent aussi aux programmeurs d’ajouter d’autres protocoles.
- jade.tools contient les outils qui facilitent l’administration de la plate forme et le
développement d’applications.
131
Annexes
II.1.3. Les Agents de base

Remote Management Agent « RMA »
Le RMA permet de contrôler le cycle de vie de la plate-forme et tous les agents la
composant. L'architecture répartie de JADE permet le contrôle à distance d'une autre plate-
forme. Plusieurs RMA peuvent être lancés sur la même plate-forme du moment qu'ils ont des
noms distincts.
Figure 8 : Interface graphique d’un RMA
Agent Management System « AMS »

Le Système de Gestion d'Agents (AMS) est l'agent qui exerce le contrôle de
supervision sur l'accès à et l'usage de la plate-forme ; il est responsable de l'authentification
des agents résidents et du contrôle d'enregistrements.
Agent Communication Canal « ACC »
Le Canal de Communication entre Agents (ACC) est l'agent qui fournit la route pour
les interactions de base entre les agents dans et hors de la plate-forme ; c'est la méthode de
communication implicite qui offre un service fiable et précis pour le routage des messages ; il
doit aussi être compatible avec le protocole IIOP pour l'interopérabilité entre les différentes
plates-formes multi-agents.
Directory Facilitor « DF »
132
Annexes
L'interface du DF peut être lancée à partir du menu du RMA .Cette action est en fait
implantée par l'envoi d'un message ACL au DF lui demandant de charger son interface
graphique. L'interface peut être juste vue sur l'hôte où la plate-forme est exécutée. En utilisant
cette interface, l'utilisateur peut interagir avec le DF.
Figure : Interface du Directory Facilitator
Dummy Agent « DA »
L’agent ‘DummyAgent’ permet aux utilisateurs d'interagir avec les agents JADE d'une
façon particulière. L'interface permet la composition et l'envoi de messages ACL et maintient
une liste de messages ACL envoyés et reçus. Cette liste peut être examinée par l'utilisateur et
chaque message peut être vu en détail ou même édité. Plus encore, le message peut être
sauvegardé sur le disque et renvoyé plus tard.
133
Annexes
Figure : Interface graphique d’un Dummy Agent

Sniffer Agent « SA »
Quand un utilisateur décide d'épier un agent ou un groupe d'agents, il utilise un agent
sniffer. Chaque message partant ou allant vers ce groupe est capté et affiché sur l'interface du
sniffer. L'utilisateur peut voir et enregistrer tous les messages, pour éventuellement les
analyser plus tard. L'agent peut être lancé du menu du RMA ou de la ligne de commande
suivante : Java jade.Boot sniffer:jade.tools.sniffer.sniffer.
Figure : Interface du Sniffer Agent
134
Annexes
Introspector Agent
Cet agent permet de gérer et de contrôler le cycle de vie d'un agent s'exécutant et la
file de ses messages envoyés et reçus.
Figure : Interface de l’Introspector
II.2. Les Behaviours (Comportements)

Un Behaviour (comportement) représente une tâche qu’un agent doit effectuer.
Chaque Behaviour possède deux méthodes : la méthode action() qui définit les opérations à
exécuter par l’agent, et la méthode done() qui renvoie un booléen spécifiant si le Behaviour a
terminé et doit être supprimé de la file des Behaviours à exécuter par l’agent.
Nous distinguons principalement trois types de Behaviours [LIM, 05] :
1. Behaviours mono-coup « OneShot behaviours » qui se terminent immédiatement et dont
la méthode action() est exécutée seulement une fois. La méthode done() retourne «Vrai».
2. Behaviours cycliques « Cyclic behaviours » qui ne sont jamais terminés et dont la
méthode action() exécute les mêmes opérations chaque fois qu’elle est appelée. La
méthode done() retourne «Faux».
3. Behaviours génériques « Generic behaviours » qui exécutent différentes opérations
dépendamment d’un état ; Ils se terminent quand une certaine condition est vérifiée.
II. 3. Communication entre agents

Un des dispositifs les plus importants que les agents JADE fournissent est la capacité
de communiquer. Le paradigme de communication adopté est le mode asynchrone. Chaque
135
Annexes
agent a une sorte de boîte aux lettres (la file d'attente de messages de l’agent). A chaque fois
qu’un message arrive, il est ajouté à la queue de la file et l’agent commence par traiter le
premier message arrivé.
Figure : traitement asynchrone de messages[LIM, 05]

Les messages échangés par les agents JADE obéissent au format spécifié par
le langage ACL lequel a été défini par la norme FIPA pour l'interopérabilité des agents.
II. 3. 1 Envoi de messages

L'envoi d’un message consiste à créer un objet ACL-Message et appeler la méthode send() de
classe « Agent ».
Exemple : Le code suivant correspond à l’envoi d’un message à l’agent « Bibito »
dans le but de l’informer qu’ « il fait beau aujourd’hui».
ACLMessage msg = new ACLMessage (ACLMessage.INFORM);

msg.addReceiver (new AID ("Bibito", AID.ISLOCALNAME));
msg.setLanguage ("Français");
msg.setOntology ("Prévision-météo");
msg.setContent ("Aujourd’hui il fait beau");
send (msg);
II. 3. 2 Réception de messages

La lecture des messages de la file d'attente de message est accomplie par la méthode
receive() de la classe d'agent. Cette méthode renvoie le premier message dans la file d'attente
(en le retirant de la file) ou NULL si la file d'attente est vide.
136
Annexes
L’exemple suivant défini la méthode action() d’un Behaviour ; dans cette méthode
on impose à l’agent de bloquer ce Behaviour par la méthode block() si aucun message n’est
reçu pour ne pas occuper le CPU, sinon on traite le message.
Public void action() {

ACLMessage msg = myAgent.receive();
if (msg != null) {
// Message reçu : Traitement du message;
}
else {
block() ;
}
}
JADE reste en perpétuelle évolution. En effet, des améliorations, perfectionnements et

réalisations ont déjà été projetées, la plupart d'entre eux en collaboration avec les utilisateurs
intéressés de la communauté JADE.
137
Annexes
Annexe III : L’imagerie médicale

V.1. L'angioradiologie
En angioradiologie (artériographie, phlébographie), le médecin radiologiste utilise des
substances de contraste à base d'iode qu'il injecte à l'aide de petits tubes (cathéters) introduits
à l'intérieur des artères ou des veines pour faire l'étude des vaisseaux sanguins et parfois
même pour procéder à des traitements spécifiques.
V.2. La mammographie
La mammographie (examen radiologique du sein) est un moyen diagnostique
important qui permet parfois de découvrir un cancer avant qu'il ne soit perceptible par d'autres
méthodes. Faite au bon moment, elle peut permettre le diagnostic précoce et la guérison
complète d'une maladie trop fréquente, le cancer du sein.
Les bienfaits qu'une femme peut retirer de cet examen quand il est indiqué, compensent
largement pour les risques minimes qu'elle peut encourir à cause de l'usage de rayons X.
Des études scientifiques démontrent les bienfaits indéniables de soumettre les femmes à des
examens de dépistage selon une grille d'âge et des facteurs de risque bien établis. Votre
médecin traitant peut vous renseigner à ce sujet.
V.3. La tomodensitométrie
La tomodensitométrie est une méthode révolutionnaire d'examen qui associe les
qualités techniques des rayons X à celles de l'ordinateur. Elle permet d'obtenir des images en
coupes ou en tranches à divers niveaux du corps humain. Grâce à cette méthode, on a
considérablement augmenté la capacité d'explorer et de visualiser l'intérieur du corps humain,
ce qui permet de dépister plus précocement diverses maladies et de mieux évaluer leur
réponse aux traitements. II faut injecter des produits de contraste iodés dans bon nombre de
ces examens afin d'en augmenter la sensibilité et la fiabilité.
V.4. L'échographie
L'échographie est une méthode d'imagerie constituant une application médicale des
ultrasons et de la technologie du Sonar. II ne s'agit donc pas de rayons X. Les images que I'on
obtient de certaines régions ou parties du corps se font sans rayonnement ionisant, sans
douleur et sans danger.
L'échographie est une méthode relativement économique et en constant développement qui
permet d'obtenir des informations importantes sur votre état de santé. L'abdomen, le fœtus, le
cœur, le cou, les extrémités, l'œil, les organes génitaux, se prêtent particulièrement bien à
138
Annexes
cette technique. Les vaisseaux sanguins (artères et veines) peuvent être étudiés par
l'ultrasonographie Doppler.
V.5. La résonance magnétique
La résonance magnétique est une méthode nouvelle qui permet d'obtenir des images
du corps humain sans radiation, en se servant d'un instrument qui ressemble à un
tomodensitomètre. Elle consiste à utiliser un champ magnétique très puissant qui, par
interaction avec des ondes de radio, produit des signaux qui sont transformés en images grâce
a l'informatique. Avec les instruments et la technique actuels, aucun effet biologique nocif n'a
été démontré. Comme vous pouvez vous en rendre compte, il existe des moyens nombreux et
divers d'obtenir des images de l'intérieur de votre corps. Votre médecin et le médecin
radiologiste vous recommanderont le genre d’examen qui convient le mieux pour préciser le
diagnostic de votre état et établir un traitement approprié, le cas échéant.
V.6. La radiologie d'intervention
Comme autre nouveauté de la dernière décennie, mentionnons que le médecin
radiologiste peut, grâce à différentes techniques de guidage visuel par rayons X ou par
ultrasons, avoir accès à des abcès pour les drainer ou à des vaisseaux pour arrêter des
hémorragies internes. II peut aussi faire une biopsie des tumeurs avec des aiguilles fines,
prélever des ovules sur des ovaires pour fins de fertilisation in vitro dans des cas d'infertilité.
Un médecin radiologiste qui a développé une expertise en angiologie (science des artères et
des veines) peut aussi dilater des artères obstruées afin d'améliorer la circulation du sang dans
les membres. Toutes ces techniques, et bien d’autres, regroupées sous le vocable « radiologie
d'intervention », peuvent être une alternative à des approches plus douloureuses, plus
dangereuses ou plus coûteuses qui exigeraient une anesthésie générale, une chirurgie, une
hospitalisation et une convalescence plus ou moins longue.
139

Amrane Maz

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Amrane Maz

Hochgeladen von

Copyright:

Verfügbare Formate

Conception et réalisation d’un workflow à base

d’un système multi-agents pour la gestion des

Mémoire de fin d’études

Réalise par Encadré par

Conception et réalisation d’un workflow à base d’un système

MEMOIRE PRÉSENTÉ EN VUE DE L'OBTENTION

©AMRANE Hacene, MAZ Karim, 2008.

Nous devons une reconnaissance particulière à nôtre promotrice Mme

Nous remerciant aussi le personnel du service de radiologie de l’hôpital

Nous adressons nos profonds remerciement aux membres de notre

A toi ma mère, pour ton amour, ta patience et ta présence à mes cotés

Je dédie aussi ce mémoire à mon binôme Karim tout en reconnaissant

A la mémoire de mon père, qui m’a inculqué tant de principes et de

A mes oncles, à mes tantes et à toute ma famille.

A Farid et Bilal, Ghanem, Snoussi, Badar, Dai, Belaid, Salim,

Liste des tableaux

Actuellement les entreprises marquent un passage du découpage fonctionnel et

Cette importance croissante de la notion de processus et du travail de groupe, ainsi que

Le caractère innovant de l’introduction de la technologie workflow est le fait

Le service de radiologie de l’hôpital Maillot est une structure complexe, il constitue le

La deuxième partie de ce mémoire (Analyse-Conception) est consacrée à l’étude du

Ce service se retrouve submergé dans un bain de difficultés fonctionnelles et

Le processus de gestion des examens radiologiques au service d’imagerie de l’hôpital

au sein du service de radiologie de l’hôpital Maillot, donc de proposer une nouvelle

Diminuer le temps d’attente pour la prise de rendez-vous et la récupération des résultats

(On passe de 48H à 5 minutes maximum pour la prise de rendez-vous).

et la recherche de documents se fait donc de manière automatique via le dossier patient

des gains en coûts sont réalisés en diminuant l’utilisation du papier.

Faciliter la gestion du service en automatisant les procédures de travail, donc assurer de

meilleures conditions de travail au personnel et une meilleure qualité de service aux

Faciliter les communications intergroupes en mettant au point des mécanismes de

communication performants (messagerie électronique).

Mettre à la disposition des médecins résidents des mécanismes d’apprentissage, en leurs

assurant un accès à certains cas jugés utiles à des fins pédagogiques.

processus lui sont affectées par le système.

Le service d’imagerie de l’hôpital Maillot est structuré en plusieurs départements :

Le service dispose de tous les moyens pédagogiques requis (secrétariat scientifique,

Le service assure actuellement la formation de médecins résidents (formation de post-

Parmi les objectifs recherchés, le désenclavement des régions, le partage des

L'installation d'un réseau PACS et le développement de la télémédecine sont des

En collaboration avec l'agence nationale de documentation de la Santé (Ministère de la

Le développement de démarches de réorganisation de processus est une réponse

Le transport physique de documents et l’ordonnancement de tâches bien connues

Lorsque le processus du travail est complexe, on assiste à une interaction coopérative

Le deuxième chapitre est consacré à l’études de l’approche systèmes multi-agents :

I.1.2. Typologie des applications de Groupware

Mémoire Routage Echange

Bibliothèque Workflow Suivi

Kiosque Messagerie Conférence

Moins interactif Plus interactif

Figure I-1 : Typologie des applications de Groupware [LEV, 00]

I.1.2.1. Les applications orientées «Mémoire»

I.1.2.2. Les applications orientées «Routage»

I.1.2.3. Les applications orientées «Echange»

d’une ou de plusieurs équipes, de gérer les tâches quotidiennes, personnelles ou déléguées et

I.1.3. Dimension humaine du Groupware

I.1.4. workflow et Groupware

I.2.1.1. Présentation de la WFMC

I.2.1.2. Terminologie de la WFMC [WMC, 07]

Bon de travail (Work Item)

I.2.1.3. Le modèle de référence de la WFMC

API Workflow (WAP) et

Figure I-2 : Modèle de référence du workflow [WMC, 07]