Architecture d’aide a la décision distribuée et de

Université Lumière Lyon 2Université Sidi Mohamed Ben Abdallah de Fès

École Doctorale IIS : Informatique et Information pour la SociétéLaboratoire LIESP (Laboratoire d’Informatique pour l’Entreprise et les Systèmes de Production)

Groupe de Recherche GRMS2I (Groupe de Rechercheen Modélisation et Ingénierie des Systèmes d’Information)

Architecture d’aide a la décision distribuéeet de simulation proactive dans les chaîneslogistiques : une approche multi agent

Par El Habib NFAOUIThèse de doctorat en informatique

Sous la direction de Omar EL BEQQALI et Abdelaziz BOURASPrésentée et soutenue publiquement le 20 septembre 2008

Membres du jury : Abdelaziz. BOURAS, Professeur des universités, Université Lumière Lyon 2Omar EL BEQQALI, Professeur d’université, Université Sidi Mohamed Ben Abdallah Maroc BernardGRABOT ; Professeur des universités, Ecole Nationale d'Ingénieurs de Tarbes Mostafa BELLAFKIH,Professeur d’université, Institut National des Postes et Télécommunications, Rabat, Maroc YacineOUZROUT, Maître de conférences, Université Lumière Lyon 2 Driss ABOUTAJDINE, Professeurd’université, Université Mohamed V, Rabat, Maroc Rachid EL KOUCH, Professeur d’université,Institut National des Postes et Télécommunications, Rabat, Maroc Mohamed MEKNASSI, Professeurd’université, Université Sidi Mohamed Ben Abdallah Maroc

Table des matièresContrat de diffusion . . 6Remerciements . . 7Liste des Abreviations . . 8Introduction générale . . 9

Contexte . . 9Objectifs de la thèse . . 10Plan de la thèse . . 11

Chapitre 1 : Chaîne Logistique : Problématique de l’Aide à la Décision Distribuée etUtilisation des Systèmes Multi-Agent . . 13

1.1. Introduction . . 131.2. Chaîne logistique . . 131.3. Problèmes liés à la gestion des flux circulant dans la chaîne logistique . . 15

1.3.1. Flux d’informations . . 161.3.2. Flux physique . . 191.3.3. Flux financier . . 20

1.4. Gestion de la chaîne logistique (Supply Chain Management) . . 201.4.1. SCM et solutions informatiques associées . . 211.4.2. Pratiques collaboratives . . 25

1.5. Les systèmes multi-agent dans la chaîne logistique . . 281.6. Conclusion . . 32

Chapitre 2 : Systèmes Multi-Agent : une Approche pour les Architectures Distribuées deSimulation et d’Aide à la Décision . . 33

2.1. Introduction . . 332.2. Notion d’agent . . 33

Définition de Ferber : . . 33Définition de Wooldridge : . . 34

2.3. Notion de système multi-agent . . 352.3.1. Définition . . 352.3.2. Interactions . . 362.3.3. Langages de communication entre agents . . 36

2.4. Axes de recherche dans le domaine des agents . . 372.5. Méthodologies de développement de SMA . . 382.6. Plates-formes de développement de SMA . . 43

a. Caractéristiques d’ordre technique liées à notre problème : . . 45b. Caractéristiques d’ordre général [Chmiel et al., 2004] [JADE, 2008]: . . 45

2.7. Modélisation et simulation : approche multi-agent . . 452.7.1. Simulation Orientée Agent . . 462.7.2. Branches de la simulation orientée agent . . 46

2.8. Conclusion . . 47Chapitre 3 : Architecture Distribuée à base d’Agents pour la Simulation Proactive et l’Aideà la Décision dans la Chaîne Logistique . . 48

3.1. Introduction . . 483.2. Cas d’utilisation de l’architecture proposée . . 483.3. Approche méthodologique . . 49

Le produit : . . 50Fournisseurs : . . 50Clients : . . 51Modèle à base de système multi-agent : . . 51

3.4. Architecture du système . . 533.4.1. Identification des agents et leurs rôles . . 533.4.2. Structure statique du système . . 56

3.5. Modèles pour l’aide à la décision . . 613.5.1. Processus décisionnels des agents . . 613.5.2. Protocoles de négociation . . 62

3.6. Modélisation des comportements des agents . . 693.6.1. Introduction . . 693.6.2. Rappel sur les statecharts . . 703.6.3. Comportement des agents . . 71

3.7. Conclusion . . 79Chapitre 4 : Implémentation . . 81

4.1. Introduction . . 814.2. Norme FIPA pour les systèmes multi-agent . . 814.3. Modèle d’agents JADE et notion de comportement . . 83

4.3.1. Modèle d'agents . . 834.3.2. Critères de choix . . 86

4.4. Des diagrammes d’états-transitions vers l’implémentation des agents :l’ingénierie vers l’aval . . 874.5. Architecture fonctionnelle de JADE et cycle de vie d’un agent . . 94

4.5.1. Architecture de la plate-forme JADE . . 954.5.2. Cycle de vie d’un agent . . 97

4.6. Conclusion . . 98Chapitre 5 : Validation . . 99

5.1. Introduction . . 995.2. Etude de cas industriel : Gestion des commandes urgentes non prévues . . 99

5.2.1. Contexte économique . . 995.2.2. Description de la chaîne logistique étudiée . . 1005.2.3. Problématique industrielle . . 1005.2.4. Formulation du problème et solution apportée . . 1015.2.5. Mise en œuvre industrielle . . 109

5.3. Expérimentation : Simulation du processus CPFR . . 115Analyse des résultats : . . 116

5.4. Conclusion . . 117Conclusion générale et perspectives . . 118

Bibliographie . . 120A . . 120B . . 120C . . 121D . . 123E . . 124F . . 125G . . 125H . . 126I . . 127J . . 128K . . 128L . . 129M . . 130N . . 131O . . 132P . . 132R . . 133S . . 134T . . 135V . . 136W . . 136Z . . 137

Annexes . . 138Annexe A . . 138

GPA et CPFR . . 138Avantages du CPFR . . 141

Annexe B . . 142Les différentes actions de communication de FIPA-ACL . . 142

Annexe C . . 143Systèmes de gestion de stock . . 144

Résumé . . 148Abstract . . 149

Architecture d’aide a la décision distribuée et de simulation proactive dans les chaîneslogistiques : une approche multi agent

6

Sous contrat Creative Commons : Paternité-Pas d'Utilisation Commerciale-

Pas de Modification 2.0 France (http://creativecommons.org/

licenses/by-nc-nd/2.0/fr/) - NFAOUI El HabibUniversité Lyon 2 - 2008

Contrat de diffusionCe document est diffusé sous le contrat Creative Commons « Paternité – pas d’utilisationcommerciale - pas de modification » : vous êtes libre de le reproduire, de le distribuer et de lecommuniquer au public à condition d’en mentionner le nom de l’auteur et de ne pas le modifier,le transformer, l’adapter ni l’utiliser à des fins commerciales.

http://creativecommons.org/licenses/by-nc-nd/2.0/fr/legalcode

http://creativecommons.org/licenses/by-nc-nd/2.0/fr/legalcode

Remerciements

7




RemerciementsJe remercie M. Taoufik OUAZZANI CHAHDI le président de l’Université Sidi Mohamed BenAbdallah de Fès (Maroc) et M. Claude JOURNES le président de l’Université Lumière Lyon II(France) de m’avoir accepté de préparer ma thèse cotutelle entre les deux universités. Je remercieégalement les responsables du programme MIRA (Mobilité Internationale Rhône-Alpes) en mepermettant de bénéficier d’une bourse de mobilité.

Je remercie les professeurs Omar EL BEQQALI et Abdelaziz BOURAS de m’avoir acceptéet dirigé ma thèse en cotutelle entre l’Université Sidi Mohamed Ben Abdallah de Fès (au sein duGroupe de Recherche en Modélisation et Ingénierie des Systèmes d’Information – GRMS2I - )et l’Université Lumière Lyon II (au sein du Laboratoire d’Informatique pour l’Entreprise et lesSystèmes de Production – LIESP - ). J’aimerais également leur exprimer toute ma reconnaissancepour la pleine confiance qu’ils m’ont accordée. Je leur exprime toute ma gratitude pour leursprécieux conseils, leurs suivis et leurs soutiens.

J’adresse mes vifs remerciements à mon co-encadrant M. Yacine OUZROUT qui a sum’encadrer chaleureusement et de façon très constructive. Ses connaissances, ses orientations,ses conseils, ses observations et ses critiques m’ont été très bénéfiques.

J’exprime toute ma gratitude au responsable de l’UFR doctorale Informatique Avancée(Faculté des Sciences Dhar Al Mahraz de Fès) le professeur Mohammed MEKNASSI pour sesprécieux conseils et son soutien. Je suis honoré de sa participation dans mon jury et d’examinerma thèse.

Je suis grandement honoré de la participation dans mon jury de thèse de M. MostafaBELLAFKIH (Professeur, Institut National des Postes et Télécommunications (INPT), Rabat) et M.Bernard GRABOT (Professeur, Ecole Nationale d'Ingénieurs de Tarbes (ENIT), Tarbes, France)qui ont accepté d’en être les rapporteurs. Je remercie bien vivement M. Driss ABOUTAJDINE(Professeur à l’Université Mohamed V de Rabat et membre de l’Académie Hassan II desSciences et Techniques) et M. Rachid EL KOUCH (Professeur, Institut National des Postes etTélécommunications (INPT), Rabat) d’avoir accepté d’être dans le jury et d’examiner ma thèse.

Je remercie l’équipe de recherche à la faculté des sciences Dhar Al Mehraz de Fès et enparticulier les membres du groupe de recherche GRMS2I. Je remercie tous les membres du centrede calcul (ceux qui y sont et ceux qui sont déjà partis), pour tous les moments de partage deconnaissances et de compagnie.

Je remercie l’équipe de recherche à Lyon 2 et en particulier les membres du laboratoireLIESP. Je remercie tous les membres du centre CERRAL de l’IUT Lumière Lyon II.

Je remercie chaleureusement l’ensemble du personnel de l’IUT Lumière Lyon II. Merciinfiniment à son directeur M. Michel LeNir qui m’a accueilli au sein de son institut.

Enfin, un grand merci à toute ma famille pour son soutien qui m’ont accompagné dans lesmoments heureux et difficiles. Toute ma gratitude va à mes parents pour la présence et la confianceconstante qu’ils m’ont apportées. Merci, merci.


8




Liste des Abreviations

ACL Agent Communication LanguageAGR Agent-Groupe-RôleAOM Advanced Order ManagementAPS Advanced Planning SystemsAUML Agent Unified Modeling LanguageBDI Belief, Desire and IntentionCL Chaîne Logistique globaleCPFR Collaborative Planning, Forecasting and ReplenishmentCRP Continuous Replenishment ProgramEAI Enterprise Application IntegrationECR Efficient Consumer ResponseEDI Echanges de Données InformatiquesERP Enterprise Ressource PlanningFIPA Foundation for Intelligent Physical AgentsGPA Gestion Partagée des ApprovisionnementsGPAO Gestion de Production Assistée par OrdinateurIAD Intelligence Artificielle DistribuéeJADE Java Agent Development FrameworkJAT Juste à TempsKIF 19F19 Knowledge Interchange FormatKQML Knowledge Query and Manipulation LanguageMES Manufacturing Execution SystemNTIC Nouvelles Technologies de l’Information et de la CommunicationOMG Object Management GroupSCE Supply Chain ExecutionSCM Supply Chain ManagementSCOR Supply-Chain Operations Reference-modelSMA Système Multi-AgentTM Transport ManagementVMI Vendor Managed InventoryWMS Warehouse Management System

Introduction générale

9





ContexteDans la compétition mondiale actuelle, la chaîne logistique globale1 (CL) constitue un enjeuimportant pour contribuer à l'efficacité opérationnelle des entreprises. Fonctionnant sur labase de l’entreprise élargie, elle couvre l’ensemble des flux physiques, informationnels etfinanciers, depuis les clients des clients jusqu’aux fournisseurs des fournisseurs. Elle permetainsi, à la société, d’avoir une vision globale de son activité, de se focaliser sur la satisfactiondu client en recherchant l’optimisation de l’ensemble de cette chaîne.

Au cours des dernières années, les industriels furent les principaux instigateurs del’évolution de la CL dans le but d’optimiser fabrication et distribution. Aujourd’hui, le niveaude qualité de fabrication – facteur d’avantage compétitif à long terme – s’est peu à peuuniformisé. La nouvelle source d’avantage compétitif devient donc la capacité à satisfaireau mieux les demandes des clients en termes de livraison [Hakanson2 et Wondergem3,1999]. F. Doche confirme dans [Doche et al., 1999] que l’acquisition d’un nouveau clientpeut coûter jusqu’à vingt fois plus cher que la fidélisation d’un client existant. Une réductiondes défections de 5% génère une hausse des bénéfices de 25% à 85%. Il ne sert donc à riende dépenser des fortunes pour recruter de nouveaux clients si l’on n’est pas capable, avanttout, de fidéliser sa propre clientèle. Aujourd'hui, le comportement client a évolué, les clientssont de plus en plus exigeants et les industriels doivent répondre au mieux à leurs besoinsen matière de personnalisation, de rapidité de traitement des commandes et de livraison.

La réponse à ces besoins n’est pas facile à atteindre dans le contexte de la CLqui est définie comme « un réseau d’organisations – qui supporte des flux physiques,informationnels et financiers – impliquées par des relations en amont et en aval, dansdifférents processus et activités, qui fournissent un produit ou un service, dans le but desatisfaire le client » [Christopher, 1992] (d’autres définitions sont données par plusieursauteurs dans la littérature, comme [Muckstadt et al., 2001] [Stadtler et Kilger, 2000][Swaminathan et al., 1998] [Eymery, 1997] [Lee et al., 1997]). Cette définition soulignela complexité plus ou moins grande des réseaux ainsi constitués. Ils peuvent en effetfaire intervenir plusieurs dizaines, voire centaines, d’installations réparties sur toute laplanète. La complexité de l’architecture de la CL entraîne une difficulté de gestion des fluxphysiques et d’informations depuis les approvisionnements en matières premières jusqu’àla mise à disposition des produits finis aux clients sur le lieu d’achat ou de consommation,puisque dans un contexte industriel, les données concernant ces deux flux sont parfoisimprécises (comme par exemple les temps de production ou les temps de transports),souvent incertaines (comme par exemple les décisions prises par les concurrents) etcertaines évolueront durant le cycle de vie de la chaîne (comme par exemple la demande

1 Ang. Supply Chain2 B. Hakanson: Directeur Exécutif du Supply-Chain Council. 1150 Freeport Road Pittsburgh Pennsylvania USA 15238. http://

www.supply-chain.org/ . E-mail: mailto:[email protected] J. Wondergem: Managing Director-Europe Office: Korte Brinkweg 323761 EE Soest, NETHERLANDS.

[email protected]

http://www.supply-chain.org/

http://www.supply-chain.org/

mailto:[email protected]

mailto:[email protected]


10




client). En conséquence, les très bonnes performances obtenues par une solution dansdes conditions données pourront être détériorées de façon drastique si ces conditionsvarient. C’est pourquoi les notions de robustesse et de solutions robustes sont devenuesdes concepts clés depuis quelques années dans le management industriel et logistique.

La problématique de la fidélisation et la satisfaction des clients en matière de rapiditéde traitement des commandes et de livraison a suscité les intérêts d’un nombre importantde chercheurs et supply chain managers. Plusieurs techniques et méthodes ainsi que desoutils informatiques d’aide à la décision sont développées et mises en œuvre entre lesacteurs d’une CL – dans le cadre du supply chain management – en vue de coordonnerleurs décisions et répondre ainsi à ce besoin. C’est dans le cadre de ces travaux que s’inscritla principale contribution présentée dans ce mémoire. Nous visons à proposer des solutionsliées aux systèmes d’information des chaînes logistiques au moyen des agents d’interface4 intelligents qui soient capables d’aider à la prise de décision collaborative [Chehbi, 2007].Ceci, en vue de permettre aux différentes entreprises d’avoir la capacité à satisfaire aumieux les demandes des clients en termes de livraison, plus particulièrement, lors de laprésence :

∙ des commandes incertaines : une commande incertaine est une commande dontl’occurrence n’est pas assurée,

∙ des commandes imprécises : une commande imprécise est une commande dont laquantité commandée n’est pas connue avec exactitude,

∙ des exceptions (problème de production, problème de transport, erreur sur prévisions,retard de livraison, etc.) pouvant altérer le bon déroulement d’un processus defabrication, d’approvisionnement ou de livraison.

Objectifs de la thèseLe but pricipal de notre travail est de développer une architecture distribuée à base desystème multi-agent (SMA) pour l’aide à la prise de décision collaborative dans le contextede la chaîne logistique. L’architecture ainsi développée doit permettre, entre autres, de :

∙ Synchroniser les décisions prises par les différents acteurs d’une CL afin de pallieraux problèmes liés au flux d’information et flux de produits ; en particulier, lorsde la présence des commandes incertaines, des commandes imprécises ou desexceptions (problème de production, problème de transport, erreur sur prévisions,retard de livraison, etc.). Notre idée principale est de développer des agentsd’interface intelligents qui soient capables de (i) s’alimenter en informations auprèsdes systèmes d’information des différents acteurs (ii) interagir et négocier afin deproposer des solutions aux managers pour leur aider à prendre une décision. Cesagents d’interfaces doivent garantir l’autonomie et la confidentialité des donnéesstratégiques dans le cas des acteurs indépendants ou concurrents.

∙ Aider par la simulation proactive les managers à connaître les états futurs des acteursde la CL lors de la présence d’une exception. En effet, le contexte de compétitivitédans lequel évoluent aujourd’hui les entreprises, impose d'accélérer les prises dedécision par une augmentation de la vitesse de circulation de l'information. L'objectifest de pouvoir propager l'impact d'une nouvelle donnée sur l'ensemble de la chaîne

4 Appelés ainsi parce qu’ils enrichissent la fonctionnalité dont dispose un usager lors de son interaction avec le système.


11




logistique. Il ne s'agit donc plus uniquement de planifier, mais de replanifier lorsqu'unaléa survient.

Pour atteindre ces objectifs, nous proposons :

∙ Une approche de modélisation d’une CL fondée sur les concepts d’agents etd’interactions [Nfaoui et al., 2006]. Plusieurs travaux liés à la modélisation d’une CLsont réalisés ces dernières années, mais chaque modèle est lié au problème traitédans la CL.

∙ La structuration du développement des agents de manière que l’on dispose d’unearchitecture et de composants réutilisables, en évitant de devoir recommencer defuturs développements à partir de rien. Dans ce sens, on considère égalementimportant d’organiser la manière de spécifier le comportement d’agents.

∙ L’implantation d’une architecture distribuée et sa validation dans deux scénariosdifférents. Le premier scénario est une étude de cas industriel concret d’une chaînelogistique de distribution des produits sanitaires [Nfaoui et al., 2008a]. Le deuxièmescénario consiste à évaluer l’importance de la mise en œuvre du processus CPFR(Collaborative Planning, Forecasting and Replenishment) [VICS Association, 2006]entre des acteurs travaillant dans le secteur du textile et d’habillement [Nfaoui et al.,2008b].

Le comportement global de la CL résulte des comportements individuels des acteurs quila composent et des interactions entre eux. Ces acteurs sont relativement autonomes etinteragissent entre eux et avec leur environnement. En plus, chaque acteur de la CL poursuitses buts individuels tandis qu’il satisfait à ses contraintes locales et externes. Cette visionnaturellement distribuée d’une CL se prête bien à une démarche d’analyse orientée agents.

Afin de donner un cadre méthodologique au processus de modélisation, nous avonsadopté le langage AUML (Agent Unified Modeling Language). Nous donnons une grandeimportance aux diagrammes de séquence et d’états-transitions. Le diagramme de séquence[Huget et Odell, 2004] servira pour modéliser quelques protocoles de négociation etd’échanges que nous avons proposés pour des agents spécifiques au pilotage de la chaînelogistique dans les situations d’urgences. Le diagramme d’états-transitions (statechartdiagram) [Huget, 2002a] sera utilisé pour modéliser les comportements des agents. Ainsi,Nous montrons que le langage AUML peut être appliqué à des applications réelles.

Vu la diversité des plates-formes utilisées par les acteurs industriels et la naturedistribuée de la chaîne logistique, nous avons choisi la plateforme de développement JADE(Java Agent Development Framework) [Bellifemine et al., 1999] pour implémenter notrearchitecture. Elle est gratuite et est basée sur le langage JAVA.

Plan de la thèseAprès la présentation des principaux objectifs de notre travail, la suite du présent mémoireest organisée comme suit :

∙ Le chapitre 1 dresse globalement un état de l’art sur la chaîne logistique. Nousdéfinissons tout d’abord la CL et nous montrons les problèmes liés aux fluxd’informations et de produits. Nous citons ensuite les principaux outils et approchesutilisés dans le cadre de la gestion de la chaîne logistique5 afin de pallier aux


12




problèmes ayant une influence directe ou indirecte sur la satisfaction des clients enterme de rapidité de traitement et de livraison des commandes. Parmi ces outils, onmet l’accent sur l’utilisation des SMA, tout en précisant une liste de projets et thèsesrécemment soutenues dans ce cadre. Puis nous montrons les points forts et faiblesde l’utilisation de l’approche multi-agent dans le domaine de la chaîne logistique.Enfin, nous concluons.

∙ Nous introduisons dans le chapitre 2 les définitions de base concernant le conceptd’agent et de système multi-agent. Nous présentons ensuite quelques axes derecherche dans le domaine des agents et nous donnons une synthèse sur lesméthodologies d’analyse et conception ainsi que les plates-formes de développementdes systèmes multi-agent. Puis nous montrons les grandes lignes et critères qui ontguidé nos choix concernant le langage de modélisation et la plate-forme utilisés pourle développement de notre architecture. Enfin, nous présentons la modélisation et lasimulation orientée agent. Nous terminons ce chapitre par une conclusion.

∙ En s’appuyant sur le langage AUML, le chapitre 3 présente la modélisation d’unechaîne logistique à base de SMA. Nous identifions les agents nécessaires etnous proposons un ensemble de protocoles de négociation. Les comportementsdes agents et leurs interactions seront aussi modélisés à l’aide des diagrammesd’états-transistions d’AUML. Dans ce contexte, un statechart sera associé à chaqueagent afin de décrire les différents états qu’il peut prendre en fonction des actionsse produisant dans l’environnement ou en fonction des messages reçus. Enfin,nous terminons ce chapitre par une conclusion récapitulant l’originalité de notrecontribution.

∙ Le chapitre 4 est consacré à la phase d’implémentation de l’architecture proposéesous l’environnement JADE. Après une présentation du modèle d’agent JADE, nousproposons des règles de transformation permettant l’obtention de squelette d’uneclasse d’agent dans JADE à partir de son modèle de comportement (statechart),en particulier, l’établissement d’une correspondance entre les diagrammes d’états-transistions AUML et les comportements de JADE.

∙ Le chapitre 5 est consacré à la validation des notre approche par des études de casindustriels concrets. Nous décrivons quelques processus (méthodes de collaboration)et algorithmes permettant de gérer les commandes non prévues au sein d’une CLde distribution de produits sanitaires. Puis nous discutons les résultats obtenus etl’apport que peut apporter notre système dans la résolution de quelques problèmesliés aux flux d’informations et de produits. Enfin, nous simulons le processus CPFRet nous tirons quelques conclusions sur sa mise en œuvre dans le cas d’une chaînelogistique travaillant dans le secteur du textile et d’habillement.

Finalement, nous présenterons une synthèse de la démarche et des résultats obtenus,puis nous dresserons, les conclusions de ces travaux de recherche et nous proposeronsquelques-unes des perspectives qui nous paraissent intéressantes à court et moyen termes.

Chapitre 1 : Chaîne Logistique : Problématique de l’Aide à la Décision Distribuée et Utilisation desSystèmes Multi-Agent

13




Chapitre 1 : Chaîne Logistique :Problématique de l’Aide à la DécisionDistribuée et Utilisation des SystèmesMulti-Agent

1.1. IntroductionLa compétition globale et les changements rapides des besoins des clients conduisent àdes mutations majeures dans les styles de production ainsi que dans la configuration desentreprises. Ainsi, les flux d’informations et de produits circulant dans la chaîne logistiquedoivent être bien maîtrisés et gérés. La problématique de l’incertitude des informations dansle flux d’informations présente un challenge important à surmonter, car c’est l’un des facteurspouvant causer des ruptures de stock. Ce qui se traduira par un mauvais niveau de servicedans l’optique de la fidélisation du client final en matière de rapidité de traitement et delivraison des commandes, problématique à laquelle nous portons un grand intérêt dans cemémoire.

Ce chapitre commence par des généralités sur la CL. Ensuite nous citons les problèmesliés à la gestion des flux circulant dans la CL. Puis on présente un état de l’art sur les outils,méthodes et pratiques utilisés par les industriels dans le cadre du SCM afin de faire faceà ces problèmes. On se focalise après sur l’utilisation des SMA dans le domaine de la CL.Enfin, nous concluons en mettant en exergue la problématique traitée dans le cadre de nostravaux de recherche.

1.2. Chaîne logistiqueLe concept de chaîne logistique est couramment perçu comme un réseau d’installationsqui assure les fonctions d’approvisionnements en matières premières ou en articles semi-finis, le transport et la transformation de ces matières en composants, en articles semi-finispuis en articles finis, et enfin le stockage et la distribution des articles finis vers les clients[Lee et Billington, 1992]. Le terme « installation » s’entend comme une unité de stockage,une unité de production, une usine, un fournisseur, un centre de distribution, un entrepôtou un client. En clair, la chaîne logistique d'un produit est l'ensemble d'entreprises qui ontsuccessivement participé à l'élaboration et au transport jusqu'au client de ce produit.

Comme l’illustre la figure 1.1 [Swaminathan et al., 1998], la chaîne logistique est unréseau d’interrelation dynamiques d’une incroyable complexité entre des dizaines, descentaines voire des milliers de fournisseurs, de clients et de partenaires. Elle recouvre unemultitude de fonctions interdépendantes et une myriade de critères associés à chacune de


14




ces fonctions. Elle appelle des qualités récemment redéfinies par l’e-business [Probert6 etO’Regan7, 2002] :

∙ La collaboration : communication sur des informations opportunes entre les analystes,gestionnaires, fournisseurs et clients de la chaîne logistique.

∙ La flexibilité : informations et ressources permettant de résoudre les problèmes et desaisir les opportunités.

∙ La réactivité : capacité à réagir promptement aux changements des conditions demarché.

∙ La visibilité : accès immédiat aux informations qui déterminent les opérations et lesperformances de la chaîne logistique.

Fig. 1.1 - Exemple de chaîne logistiqueUne acceptionplus récente de la notion de chaînes logistiques considère cette dernière

comme un ensemble de relations clients/fournisseurs successives intégrant, pour chaqueentité, les activités d’approvisionnement, de production et de distribution [Tayur et al., 1999][Stadtler et Kilger, 2000]. Cette proposition complète donc les précédentes définitions enfocalisant la chaîne logistique sur les relations entre les acteurs qui la composent (figure1.2 [Supply Chain Council, 2000]).

6 Directeur des alliances stratégiques, Business Objects : leader mondial des fournisseurs de solutions de business intelligence(BI). http://www.France.businessobjects.com

7 Senior hmanager, Accenture: leader mondial du conseil en management et technologies de l’information. http://www.accenture.com/fr

http://www.France.businessobjects.com/

http://www.accenture.com/fr

http://www.accenture.com/fr


15




Fig. 1.2 - Relations clients / fournisseurs d’une chaîne logistique et fonctions présentesDans [Poirier et Reiter, 2001], les auteurs résument cette notion en indiquant

simplement qu’une chaîne logistique est le système grâce auquel les entreprises amènentleurs produits et leurs services jusqu’à leurs clients. La chaîne logistique est ici clairementassociée à l’entreprise (ou réseau d’entreprises) et donc aux processus et ressources quil’animent. Le modèle récent qui intègre cette représentation de la notion de chaîne logistiqueest le modèle SCOR (Supply-Chain Operations Reference-model) de la figure 1.3 développéet soutenu par le Supply Chain Council8 [Supply Chain Council, 2006].

Fig. 1.3 - Modèle SCOR niveau 1Après avoir présenté le concept de la CL, nous traitons dans la section suivante les

différents problèmes liés à la gestion des flux y circulant.

1.3. Problèmes liés à la gestion des flux circulant dansla chaîne logistique

Les entreprises appartenant à une même chaîne logistique sont liées par des flux deproduits, des flux d’informations et des flux financiers (figure 1.4 [Gratacap et Médan, 2001]).

8 Le Supply Chain Council est un organisme indépendant, mondial et à but non lucratif dont l’adhésion est ouverte à toutesles entreprises et les organisations intéressées à l’application et à l’amélioration de l’état de l’art sur les systèmes et les pratiquesde gestion d’une chaîne logistique.


16




Pour optimiser le fonctionnement de la CL, les entreprises impliquées doivent se coordonneren tentant de satisfaire d’une part leurs objectifs locaux, et d’autre part les objectifs globauxde la CL. La gestion d’une CL pose ainsi un problème de décision distribuée où les contexteset les objectifs propres aux différents acteurs de la chaîne diffèrent, malgré les intérêtscommuns qu’ils partagent du fait qu’ils participent tous à la production d’un même produit.Pour résoudre ce problème de décision et parvenir à un compromis satisfaisant les acteursdoivent coopérer.

Fig. 1.4 - Les différents flux parcourant la chaîne logistique

1.3.1. Flux d’informationsLes informations remontent la CL puisque ce flux part des clients et, de proche en proche,traverse l’ensemble de la chaîne jusqu’au dernier des fournisseurs. Le flux d’informationse compose au minimum des commandes émises par les clients à leurs fournisseurs. Ondistingue, en général, deux types d’informations :

∙ celles concernant les commandes fermes, c'est-à-dire, les commandes réelles,confirmées qui considèrent une quantité de produit à livrer à une date et dans un lieudonnés,

∙ celles concernant les commandes prévisionnelles. Elles correspondent à desprévisions sur les demandes futures à partir des historiques des ventes et desprévisions sur l’évolution des marchés.

Les commandes prévisionnelles sont analogues à des commandes fermes sauf qu’elles nesont pas définitives et peuvent être modifiées.

Il peut y avoir d’autres types d’informations qui circulent dans le but d’aider les acteursde la relation client/fournisseur dans leur prise de décision. Ce flux peut être bidirectionnel,le fournisseur pouvant informer son client sur les retards à la livraison, les quantités à livrer,etc.


17




Problèmes liés à la gestion des flux d’informationLes performances de nombreux systèmes sont réduites par les imperfections des flux quiles parcourent. En tant que systèmes distribués composés d’entreprises et traversées pardivers flux, les CL font également face à ce problème. Nous nous limitons à citer deuxproblèmes liés à la gestion de ce type de flux et qui ont des conséquences directes sur laproblématique à laquelle nous intervenons dans ce mémoire.

a. Problème de l’incertitude des informationsLe problème de l’incertitude des informations au sein de la CL, concerne en particulierle traitement des commandes incertaines et imprécises. Nous appellerons ‘commandeincertaine’ une commande dont l’occurrence n’est pas assurée et ‘commande imprécise’une commande dont la quantité commandée n’est pas connue avec exactitude.

Le traitement des commandes incertaines, ou commandes imprécises, a été envisagédans plusieurs travaux de recherche [Fargier et al., 2002], [Hapke et al., 2000], [Genesteet al., 2000] et [Letouzey et al., 2001]. Mais le travail qui a englobé la majorité des étudeset a analysé simultanément l’imprécision et l’incertitude des informations a été proposépar [Reynoso, 2004]. Après avoir balayé l’apport des autres travaux, l’auteur propose unedémarche similaire à MRP9 avec une approche basée sur la logique floue10: ‘MRP flou’.Giannoccaro [Giannoccaro et al., 2003] a aussi utilisé la logique floue pour proposer uneméthode de gestion de stock dans la chaîne logistique. Il a modélisé l’incertitude de lademande et les coûts du stock (coût de possession et coût des commandes en retard).

Une des causes de la complexité des prises de décision est l’incertitude qui apparaîtdans les fonctions d’approvisionnement, de production et de distribution. Différentesincertitudes, propres à chacune de ces fonctions, sont donc présentes dans la chaîne. Selonles travaux qui exposent cette problématique, la source la plus problématique concernel’incertitude au niveau de la demande [Davis, 1993], [Lee et Billington, 1993] et [Arnold,1996]. Elle s’exprime en terme de quantité, de répartition entre produits, entre fournisseurs,en dates de besoin, etc. Si l’on considère des acteurs producteurs dans une CL, l’incertitudeau niveau du processus de production est relative aux taux de pannes, de rebus, aux tempsde répartition, etc. L’incertitude au niveau de la distribution se traduit par des retards à lalivraison, des quantités supplémentaires livrés en cas de mauvais transports, etc. La figure1.5 résume les sources d’incertitudes dans la CL [Rota, 1998].

9 Application de gestion des approvisionnements qui succède au MRP en lui ajoutant des fonctions des gestions des capacitéset de calcul de coûts.

10 Ang. fuzzylogic


18




Fig. 1.5 - Sources d’incertitudes dans la CLToutes ces sources d’incertitude donnent naissance à plusieurs problèmes. Tout

d’abord leurs effets se cumulent au niveau de chaque acteur et différentes fonctionsde la chaîne : en fonction de la demande prévue, les approvisionnements sont lancés,ils conditionnent les quantités pouvant être produites qui elles mêmes influent sur lesdécisions lors de la distribution. Ensuite, ces incertitudes se propagent le long de lachaîne à partir des prévisions de vente faites sur chaque niveau de la chaîne. Desdemandes d’approvisionnement vers les niveaux supérieurs sont effectuées, ces demandesd’approvisionnement sont à leur tour exploitées par les niveaux supérieurs pour donner lieuà de nouvelles demandes d’approvisionnement, et ainsi de suite.

b. Problème de la fluctuation de l’informationLes informations concernées par ce problème consistent essentiellement aux demandesémises par les clients à leurs fournisseurs tout au long de la chaîne (figure 1.6).


19




Fig. 1.6 - Illustration du problème de fluctuation de la demande (cas de trois acteurs)La fluctuation du flux d’information, appelée aussi ‘amplification de la demande’ ou ‘effet

coup de fouet 11 ’ ou encore ‘effet de Forrester’ [Moyaux, 2002] reflète la déformation del’information lorsque cette information remonte la CL du point de vente vers les fournisseursde matières premières. Concrètement, elle se propage de la façon suivante : le point devente émet des commandes qui sont imprévisibles (pas forcément avec de fortes variations).Les conséquences négatives de ce phénomène sont l’accroissement des inventaires, laréduction du service aux clients due à des ruptures de stock, l’inefficacité des transports,l’échec des plans de production, etc.

La dynamique des flux d’information est difficile à cerner. Les entreprises sontautonomes et il n’y a pas de coordonnateur qui joue le rôle du centre de contrôle. Aussi,ces entreprises n’ont pas à transmettre l’intégralité de leurs informations.

L’effet coup de fouet est également la cause d’autres problèmes tels que les difficultés àordonnancer, à gérer la main d’oeuvre, à contrôler les stocks et les besoins en entrepôts quien résultent, le service au client est faible (en particulier, en termes de retards des livraisons,de différences entre les quantités commandées et livrées et d’erreurs de facturation) ainsique les efforts administratifs qui sont excessifs [Taylor, 2001], [Carlsson et Fullér, 2001].

1.3.2. Flux physiqueLe flux de produit traverse la CL dans le sens orienté des fournisseurs aux clients. Ilcorrespond aux flux de matières premières, composants de produits, produits semi-finis etproduits finis entre les entreprises. Les équipements d’usinage (ex. machines, convoyeurs),de transport (ex. véhicules de transport de marchandises) et le matériel d’investissement(ex. outillage) ne font pas partis de ce type de flux.

Le transfert de produit peut être bidirectionnel : il circule évidemment du fournisseurvers les clients, mais il peut aussi, dans le cas d’une relation de sous-traitance, circuler dudonneur d’ordre vers le sous-traitant [Despontin, 2004]. Par exemple, l’entreprise fournit àson sous–traitant la matière première et récupère le produit par la suite.

Problèmes liés aux flux de produitsLa complexité croissante des systèmes industriels, ainsi que les exigences des clients dansun marché très concurrentiel, placent la gestion des flux au coeur des problématiquesindustrielles actuelles [Campagne et Burlat, 2001]. Selon ces auteurs, le service du flux deproduit doit être considéré selon trois points:

∙ Qualité : Depuis de nombreuses années, les exigences imposées en terme de qualitétotale doivent assurer le zéro défaut pour les produits livrés. Les flux ont évolué, enparticulier avec les livraisons directes des produits dans les unités de production et lasuppression des contrôles à réception, aboutissant à la réduction des stocks et desdélais de mise à disposition des produits.

∙ Délai : La généralisation du JAT (Juste à Temps) a entraîné une réduction drastiquedes délais clients, allant parfois jusqu’à l’exigence de livraison synchrone desproduits, les appels de livraison se faisant alors dans un ordre déterminé lors de lamise en ligne des produits sur les chaînes. Si la garantie de délais courts ne pose pasde problèmes particuliers pour la livraison de produits standard peu diversifiés, elle

11 Ang. Bullwhip effect


20




conduit en revanche à une remise en cause complète de l’organisation du systèmelogistique et des méthodes de gestion dans une économie de variété.

∙ Coût : Dans de nombreux secteurs d’activité, la plupart des fournisseurs répondentaux exigences imposées par leurs clients en termes de qualité et de délai, de sorteque le facteur concurrentiel redevienne le prix de vente. Les gisements traditionnelsde réduction des coûts ne suffisent plus pour répondre à ces exigences. Lestentatives de réduction des coûts et d’amélioration des services ne peuvent alorsreposer sur une seule amélioration des performances internes de l’entreprise.

1.3.3. Flux financierCe type de flux concerne les paiements des fournisseurs de produits et/ou des services etles arrangements financiers entre clients et fournisseurs (crédits, paiement cash, payementsmensuels, etc.).

1.4. Gestion de la chaîne logistique (Supply ChainManagement)

Beaucoup d’efforts ont été consentis ces dernières années pour mettre en place un pilotageglobal de la chaîne logistique. En raison de son large périmètre, la gestion de la chaînelogistique doit utiliser des liens complexes en créant une « entreprise étendue » qui vabien au-delà des murs de l’entreprise. Ainsi, Le Supply Chain Management (SCM) estdéfini comme la coordination systématique et stratégique des fonctions traditionnellesde l’entreprise dans un réseau interentreprises avec, pour objectif, d’améliorer lesperformances à long terme à la fois de l’entreprise concernée et de la chaîne logistiquedans son ensemble [Samii, 2004]. Le SCM cherche à optimiser l’ensemble de la chaînelogistique, depuis la prévision de vente jusqu’à la distribution, en prenant en compte laplanification de production et des approvisionnements. T.C. Jones et D. W. Riley (1987)définissent les conditions d’une gestion efficace de la CL. Selon cette optique, le SCMsuppose de planifier et de contrôler les stocks et les activités comme une entité unique etintégrée des fournisseurs jusqu’aux utilisateurs finaux. Trois éléments doivent alors être prisen considération :

∙ Le niveau de service souhaité par le client final,∙ Le niveau des stocks sur différents lieux de positionnement préalablement définis tout

au long de la chaîne,∙ Les procédures de gestion de la CL en tant qu’entité unique.

Les acteurs principaux dans la gestion de la chaîne logistique sont tout d’abordles fournisseurs de matériel ou de services, les partenaires commerciaux (grossistes,distributeurs, détaillants), mais aussi les clients eux-mêmes, les consultants en gestion dela chaîne logistique, ou encore les fournisseurs et développeurs de logiciels [Hakanson etWondergem, 1999].

Différents niveaux de collaboration, coopération, coordination, communication et departenariat entre les entreprises ont été mis en place dans l’industrie ces derniers tempsafin de résoudre les différentes problématiques de gestion de la chaîne logistique. Cesproblématiques couvrent les trois niveaux de planification dans la chaîne logistique (figure


21




1.7 [Lamouri, 2006]) ainsi que les différents horizons de la prise de décision (long, moyenet court termes).

Fig. 1.7 - Les trois niveaux de planification dans la chaîne logistiqueParmi les offres concernant la collaboration entre acteurs de la CL, on peut en

identifier deux types : les outils informatiques pour coordonner les décisions et lesbonnes pratiques qui sont définies par des associations d’industriels. Puisque notre travailtraite particulièrement les situations d’urgences dues aux problèmes de l’incertitude desinformations (section 1.3.1) dans le flux d’informations ou les problèmes liés aux flux deproduits (section 1.3.2), nous nous limitons à présenter les outils, les processus et lespratiques industrielles les plus connus qui contribuent de manière directe ou indirecte à cecontexte.

1.4.1. SCM et solutions informatiques associéesPour simplifier, nous dirons que le marché des logiciels de supply chain management sedivise en trois catégories : les ERP (Enterprise Ressource Planning), les APS (AdvancedPlanning Systems) et les SCE (Supply Chain Execution).

1.4.1.1. ERP et APSLes ERP sont des outils transactionnels qui assurent la capture des données et leurstockage (commandes, gestion des stocks, gestion des achats, etc.). Les logiciels de typeAPS sont des outils spécialisés structurant la décision pour la planification de la demande,de la production et de la distribution. Ils optimisent la planification et synchronisent les fluxde la chaîne logistique en tenant compte simultanément d’un grand nombre de contraintes(ressources, capacités, délais, coûts, profits, etc.) [CXP, 2001].

Les ERP se placent au niveau opérationnel en gérant les transactions. Les grandséditeurs d’ERP ont crée des progiciels qui couvrent littéralement toutes les fonctions del’entreprise : gestion commerciale, gestion de production, achats, stocks, maintenance,qualité, comptabilités (générale, clients, fournisseurs), trésorerie, consolidation, gestion desressources humaines, etc. Une étude récente sur les nouvelles recherches concernant les


22




ERP est présentée dans [Botta-Genoulaz et al., 2005]. À titre d’exemple, nous présentonsci-dessous (figure 1.8 [Baglin et al., 2001a]) la structure générale de l’ERP le plus diffusédans le monde : SAP R/3.

Fig. 1.8 - Modules SAP R/3Au-delà de toutes les fonctions de gestion interne de l’entreprise, les ERP offrent, grâce

à une ouverture sur le monde extérieur au moyen des technologies de l’information, lapossibilité de gérer efficacement l’ensemble de la chaîne logistique dans laquelle évoluel’entreprise. Ci-dessous une liste non exhaustive de fonctions :

∙ La planification inter-entreprise (Collaborative Planning) : permet de communiquerles plannings de fabrication et de livraison entre les partenaires (fournisseurs,clients, sous-traitants) pour aboutir à des solutions réalistes. Cela suppose desconnexions entre les ERP des partenaires et donc d’avoir mis en place des accordsde partenariat.

∙ La planification du réseau logistique (Supply Network Planning) : permet de fairecorrespondre la demande avec les processus d’achats, de fabrication et de transport,pour équilibrer et optimiser l’ensemble du réseau de logistique.

∙ Le pilotage du réseau logistique (Supply Chain Cockpit) : offre aux utilisateurs unevue générale de la chaîne logistique à l’aide d’une interface utilisateur graphiquepersonnalisable.

∙ Le disponible à la vente globale (Global Available-to-Promise) : fait coïncider l’offre etla demande à une échelle vraiment internationale.

∙ Le e-procurement : permet de soumettre des appels d’offres via Internet sur desplaces de marché.

Un ERP permet normalement de réduire les ruptures de stock, d’abaisser le niveau moyendes stocks par une rotation plus élevée, d’améliorer le respect des délais de livraison promis


23




aux clients et d’abaisser le coût de revient de la production par une meilleure régularité dansle fonctionnement des ateliers.

Les données modélisées et traitées par l’APS sont issues de la base de donnéesrelationnelle de l’ERP. En effet, les APS ne disposent pas de leur propre base de donnéeset doivent donc être « connectés » aux ERP ou au système d’information de l’entreprise.Les APS interviennent pour la synchronisation de la chaîne logistique (figure 1.9 [Lamouri,2006]). Les transactions liées aux déclarations de production, à la saisie d’une commande,etc. seront exécutées dans l’ERP. Ces informations sont mises en forme dans l’APSpour que le gestionnaire puisse établir le plan. Les décisions de production, de transport,d’approvisionnement sont ensuite transmises à l’ERP sous forme d’ordres pour y êtrelancés.

Fig. 1.9 - Le positionnement relatif des ERP et des APSToutes les activités ayant un impact fort sur la qualité du service au client sont intégrées

dans les APS : planification, remise de délai, gestion des stocks, expéditions, etc.La cohabitation réussie entre l’APS et l’ERP s’avère essentielle. L’APS doit pouvoir

déterminer les meilleures décisions en tenant compte des informations les plus récentespossibles contenues dans l’ERP, mais également assurer le suivi des plans pour contrôlerque la situation ne dévie pas significativement. L’ERP doit recevoir les décisions de l’APSpour en tenir compte.

Les APS donnent une visibilité sur toute la chaîne et offrent des fonctionnalitésd’interconnexion avec les systèmes d’information des clients et fournisseurs en s’appuyantsur le développement des technologies intranet et internet. Le gestionnaire de la chaînelogistique dispose donc aujourd’hui de l’architecture informatique qui lui permet de s’appuyersur des données mises à jour à travers l’ERP pour prendre des décisions de planificationavec le support de l’APS.

1.4.1.2. SCE et EAILes SCE ont pour objectif d’optimiser le cycle de traitement des commandes. Ils regroupentgénéralement trois fonctions :


24




∙ La gestion de l’entreposage (Warehouse Management System - WMS),∙ La gestion des transports (Transport Management - TM),∙ La gestion des commandes (Advanced Order Management - AOM).

Ils offrent des solutions adaptées aux modes de circulation des flux au sein de la chaînelogistique et sont par exemple conçus pour traiter des livraisons en GPA - Gestion Partagéedes Approvisionnements – (cf. section 1.4.2). Ils peuvent disposer de la radiofréquence enentrepôt, recourir à des transmissions par satellites pour le suivi des marchandises, ou faireappel à Internet pour le suivi des commandes en temps réel.

L’inconvénient des progiciels SCE réside dans le fait qu’ils assurent une intégrationaval (logistique de distribution) mais pas une intégration amont ; en effet, ils ne permettentgénéralement pas de retrouver les ordres de fabrication initiaux et les fournisseurs descomposants. Le suivi en amont est effectivement assuré par les logiciels de GPAO (Gestionde Production Assistée par Ordinateur) ou par les logiciels appelés MES (ManufacturingExecution System). Ces derniers, grâce à l’utilisation des gammes et des nomenclatures,permettent d’associer les fournisseurs des composants, les produits, les ordres defabrication et les commandes.

Face à cette offre fragmentée, quelques éditeurs de progiciels proposent à leursclients la possibilité de disposer d’un véritable système d’information intégré avec les EAI(Enterprise Application Integration), traduit par intégration des applications d’entreprises12.Il s’agit de logiciels capables d’instaurer des échanges entre des applications qui n’ontpas été conçues pour communiquer. Un EAI doit être capable d’une part d’aller chercherdes informations d’origines et de formats divers et d’autre part de rendre ces informationshomogènes et accessibles.

La figure 1.10 [Gratacap et Médan, 2001] permettra d’avoir une vision globale simplifiéede l’offre logicielle qui existe en vue de gérer efficacement la CL. Dans [Gratacap et Médan,2001], les auteurs affirment que la tendance n’est pas à la fragmentation de l’offre ; lesmultiples alliances dans le domaine des logiciels de gestion intégrée s’expliquent par le faitque les entreprises souhaitent de plus en plus homogénéiser leurs solutions informatiques,afin d’être véritablement intégrées.

12 Pour plus de clarté sur une terminologie instable, nous préciserons que : les logiciels interapplicatifs à l’intérieur de l’entreprisesont aussi appelés logiciels A-to-A (Application to Application) ; lorsque le périmètre de ces échanges interapplicatifs est étenduaux partenaires de l’entreprise (clients, fournisseurs), on parle alors de logiciels B-to-B (Business to Business) ou indifféremment delogiciels IAI (Internet Application Integration).


25




Fig. 1.10 - Les logiciels de SCM selon le niveau de la SCM

1.4.2. Pratiques collaborativesLe besoin de collaboration/coopération a donné naissance à un ensemble de « bonnespratiques » et « techniques » permettant d’améliorer la collaboration entre les clients et lesfournisseurs. On peut notamment citer :

a. ECRL’Efficient Consumer Response (en français, réponse optimale au consommateur) a pourobjectif d’assurer un flux de marchandises sans rupture ainsi que de fiabiliser et fluidifierles flux d’information correspondant [Baglin et al., 2001b]. Parmi les principaux outilsau service d’une stratégie d’ECR orientée logistique, on trouve notamment le CPFR(Collaborative Planning and Forecasting Replenishment) et le GPA (Gestion Partagée desApprovisionnements).

b. GPA et CRP

La Gestion Partagée des Approvisionnements (GPA13) et le programme deréapprovisionnement en continu14 sont deux systèmes très similaires mais mis en placedans deux industries différentes. Ils utilisent une centralisation de l’information pour quele fournisseur puisse contrôler le réapprovisionnement de son client. C’est à dire que lefournisseur connaît en temps réel le niveau des stocks de son client, ce qui lui permet

13 Ang. VMI pour Vendor Managed Inventory.14 Ang. CRP pour Continuous Replenishment Program.


26




de réapprovisionner son client quand il le juge nécessaire, et ce sans que le client nepasse de commande. Le fournisseur est seul responsable du réapprovisionnement deson client. Ainsi, ces deux pratiques logistiques permettent de passer d’un flux poussé(usine-magasin) dans la chaîne d’approvisionnement, à un flux tiré (magasin-usine) par lademande consommateur. L’annexe A.1 présente les phases de déroulement de la GPA.

Il faut par ailleurs préciser que la GPA n’est pas utilisée de façon uniforme pour tousles produits. En effet, pour des produits à forte rotation ou à forte période de saisonnalité,qui ont une fréquence de réapprovisionnement supérieure à une fois par semaine, on seservira de la GPA, alors que pour des produits qui ont une faible rotation, on privilégiera desachats en masse permettant de réaliser des économies d’échelle importantes.

La principale contrainte de la GPA est supportée par les producteurs, en effet, la miseen place de la GPA nécessite une réorganisation de leurs services et de leurs modes defonctionnement. De plus, c’est également un investissement très important pour eux enterme de coûts mais aussi en terme de masse de travail puisqu’ils doivent gérer dès lorseux-mêmes leurs références et leurs réapprovisionnements.

Le problème dans le système GPA c’est la prévision. Il existe un manque d’intégrationet d’exploitation de l’information stockée dans les datawarehouses. En plus, la GPA nepermet pas de reconnaître la gestion des exceptions, c’est-à-dire les évènements quine peuvent pas être prévus dans le processus logistique (par exemple la rupture dueà une augmentation trop forte de la demande). Cela dégrade le taux de service car lacommande ne peut pas être assurée dans les temps. Il faut donc isoler les phénomènes etles comprendre pour essayer de les anticiper ensemble.

c. CPFRLe CPFR (Collaborative Planning and Forecasting Replenishment) est la planification et laprévision collaboratives. Il s’agit d’un standard basé sur le Web qui améliore le VMI et leCRP en incorporant la prévision commune de la demande. Avec le CPFR, les entreprisess’échangent électroniquement une série de commentaires écrits et de données incluant latendance des ventes passées, les promotions planifiées et les prévisions [Moyaux, 2004a].Cela permet aux participants de coordonner ensemble leurs prévisions en se concentrantsur les différences qu’il y a entre leur prévision respective : les entreprises cherchent lacause de ces différences et en déduisent une vision commune et améliorée de la situation[Simchi-Levi et al., 2000].

La particularité du CPFR, et ce qui en fait son attrait, c’est le fait que cette méthodeprend aussi bien en compte la gestion de l’offre que la gestion de la demande. Il fautdonc, pour que ce processus puisse être exploité de la meilleure façon qu’il soit, queproducteurs et distributeurs partagent et communiquent les informations qu’ils détiennentdans un environnement de transparence et dans la perspective d’un partenariat « gagnant-gagnant». L’annexe A.2 présente les étapes de la mise en place du CPFR.

Le CPFR montre de nombreux avantages pour pouvoir réduire le nombre de ruptureslinéaires. Le seul frein à l’établissement d’une telle méthode est le partage d’information, carce sont des informations stratégiques et propres à la politique de l’entreprise. En effet, si undistributeur X communique toutes ses informations à son fournisseur, ce dernier étant aussile fournisseur d’autres distributeurs, qui sont les concurrents directs du distributeur X, celui-ci craindra alors une diffusion de ses informations stratégiques. Jusqu’où va la confianceentre le distributeur et le fournisseur dans le partage des données?


27




d. Stock échelonLe stock échelon comprend la somme du stock local et du stock de tous les centres dedistribution de niveau inférieur. La notion de stock échelon est plus cohérente avec lesdécisions centralisées et requiert un haut degré de partage d’informations entre les différentsacteurs de la CL, alors que dans le schéma décentralisé, chaque entité gère son proprestock et passe les commandes à ses prédécesseurs en optimisant son propre objectif.

Toutes les pratiques collaboratives citées ci-dessus utilisent l’Echanges de DonnéesInformatiques (EDI) et les Nouvelles Technologies de l’Information et de la Communication(NTIC). Ces nouvelles technologies permettent d’avoir accès à plus d'informations en tempsréel. Elles permettent donc de partager des informations entre les acteurs de la chaînelogistique. Par contre, elles ne permettent pas de savoir quelles sont les informations qu’ilest judicieux d’échanger et comment elles doivent être exploitées par les différents acteursde la chaîne logistique [Telle et al., 2003].

La littérature montre que chacun des outils et pratiques présentés précédemment ases propres fonctionnalités et objectifs. Mais, ils participent tous à atteindre l’objectif global :éviter le sur-stockage, réduire les ruptures de stock, diminuer les stocks de sécurité. Enoutre, Selon Compagne [Campagne et Sénéchal, 2002], les entreprises, qui optent pour unmode de fonctionnement coopératif et par conséquent utilisent des outils de coopérationet de collaboration, attendent en retour une minimisation des risques et une réduction del’incertitude, ainsi qu’un accroissement de la performance industrielle. Néanmoins, nousrelevons quelques points de faiblesse de ces outils:

∙ La planification avancée (APS) permet aujourd’hui de recalculer rapidement unplan tactique sur la base d’une recherche d’optimum. Si cela garantit la faisabilitédu plan, il n’en assure pas la robustesse [Lamouri, 2006]. Le terme robustesse estgénéralement associé à celui de risque et de prise de décision [Kleijnen et Gaury,2003]. Un système est dit robuste s’il permet d’obtenir une faible dispersion desperformances cibles malgré les variations du niveau des variables de décision noncontrôlables [Lamouri, 2006]. En outre, l’inconvénient des APS est qu’ils peuventdifficilement fonctionner sans s’alimenter en informations auprès des bases dedonnées des ERP, bases de données de très bas niveau [Telle et al., 2003]. Or, lapratique des relations industrielles montre que les industriels impliqués dans desrelations Donneur d’ordres / Fournisseur sont très réticents en ce qui concernel’échange de ce type de données.

∙ la GPA est en général mise en place entre le point de vente et son fournisseur. leCPFR est en général utilisé entre le distributeur et le producteur. Que peut-on diredes CL de dimensions importantes ?

∙ la majorité des pratiques exigent un partage d’informations, ce qui n’est pas possibledans le cas d’une CL formée d’acteurs indépendants ou parfois concurrents. Parexemple, des distributeurs concurrents qui s’approvisionnent en produits finis chez lemême producteur.

∙ La notion du stock échelon est plus cohérente avec les décisions centralisées,∙ Ces techniques ne donnent pas de solutions pour résoudre les situations d’urgences

(présence des commandes non prévues ou des exceptions) au moment de leurprésence, et surtout pendant un intervalle de temps acceptable.

Après avoir passé en revue les différentes pratiques et outils ainsi que leurs faiblesses,nous montrons l’originalité de notre travail. En fait, notre contribution s’inscrit principalementdans les solutions permettant de pallier aux faiblesses citées ci-dessus, nous proposons


28




des fonctionnalités liées aux systèmes d’information des chaînes logistiques au moyen desagents d’interface 15 intelligents qui soient capables d’apporter des solutions instantanéeset automatisées aux situations d’urgences. Ces solutions complètent les outils et processuscités ci-dessus lors de la présence de ce genre de situations. Dès qu’un événement survientdans la chaîne, c’est-à-dire lorsque l’état de la chaîne logistique dévie de l’état planifié,les alertes sont générées conduisant les gestionnaires à re-planifier, tout en se basantsur les propositions automatisées des agents d’interface reliés au système d’informationde chaque entité. Des contre-mesures sont lancées rapidement pour corriger et sauverla situation, synchronisant à nouveau l’ensemble des maillons de la chaîne avec lesnouvelles conditions. Notre système prend en compte tous les acteurs potentiels de la CL sinécessaire, en commençant du fournisseur le plus en aval jusqu’au client le plus en amont.Notre angle de vue se résume comme le suivant: Une situation d’urgence est survenuemême si on a pris toutes les précautions et les mesures, alors que peut-on faire pour sauverla situation ? Sachant que les acteurs peuvent être indépendants.

Pour répondre à cette question, nous adoptons une approche distribuée de la décisiondans la CL (Distributed Decision Making) [Schneeweiss, 2003]. Cette approche reconnaîtune certaine autonomie de décision à chaque acteur de la CL, chacun des acteurspouvant éventuellement remettre en cause des décisions prises par ses partenaires. Selon[Despontin, 2004], l’approche distribuée de la décision est adaptée à un contexte réeld’application, où les entreprises ne coopèrent que pour certaines activités et peuvent êtreen concurrence sur d’autres, et où le pouvoir de décision est réparti de façon homogène.Plusieurs travaux préconisent une approche pour l’aide à la décision et à la coopérationbasée sur le concept de réseau de centres de décision [Chehbi, 2007] [Despontin, 2004][Monteiro, 2001] [Camalot, 2000] [Huguet, 1994]. Nous rejoignons ces auteurs car cetteapproche nous semble la mieux adaptée au développement d’une aide à la décision dansle contexte de notre étude, surtout dans les situations d’urgence où une cohérence globaledes différents scénarios et choix apparaît nécessaire.

1.5. Les systèmes multi-agent dans la chaînelogistique

Les systèmes multi-agent sont devenus populaires pour la modélisation des systèmescomplexes comme la chaîne logistique. En effet, plusieurs projets concernant l’utilisationdes systèmes multi-agent dans la chaîne logistique ont été réalisés. Ces projets seconfrontent à des problèmes différents de la chaîne logistique dont la conception et lagestion sont deux grandes catégories de problématiques.Clautier [Cloutier et al., 2001],Maturana [Maturana et al., 1999] et Parunak [Parunak, 1996] ont montré l’intérêt d’utilisercette approche dans le domaine des chaînes logistiques.En particulier, Cloutier précise quele paradigme des agents est une métaphore naturelle avec les organisations en réseaudepuis que les unités de production distribuées possèdent les mêmes caractéristiques queles agents (basé sur la définition d’un agent de [Wooldridge et Jennings, 1995] qui seraprésentée dans le chapitre 2) :

∙ autonomie : une entreprise exécute des tâches d’elle-même sans interventionextérieure ;

15 Appelés ainsi parce qu’ils enrichissent la fonctionnalité dont dispose un usager lors de son interaction avec le système.


29




∙ capacités sociales : un acteur de la chaîne logistique peut communiquer avecun autre acteur pour, par exemple, lui passer une commande de produits ou deservices ;

∙ réactivité : une firme modifie son comportement si le marché ou la concurrenceévolue ;

∙ pro-activité : une entreprise peut initier d’elle-même de nouvelles activités, comme parexemple décider de lancer un nouveau produit sur le marché ;

La littérature montre que les projets utilisant les SMA dans la CL se confrontentessentiellement à trois problèmes principaux : La modélisation, la conception et la gestion(pilotage). De plus, la manière de résoudre ces problèmes diffèrent aussi en fonction desprojets : par exemple, le nombre et le rôle des agents varient considérablement. Nousprésentons ci-dessous une liste non exhaustive de projets utilisant les SMA dans la CL :

1. MASCF (Multi-Agent Supply Chain Framework) [Govindu et Chinnam, 2007]: MASCFest un outil qui offre une méthodologie générique conçue pour faciliter et simplifierles phases d'analyse et de conception des applications basées sur les SMA dansles CL. MASCF adopte le modèle standard ‘SCOR’ pour la description de la CL etla méthodologie ‘Gaia’ (cf. chapitre 2. section 2.5) pour le développement des SMA.Puisque le modèle SCOR et la méthodologie Gaia sont les éléments principauxde MASCF, ce dernier est alors considéré comme un outil générique largementapplicable pour modéliser des CL par des systèmes multi-agent. MASCF ne spécifieaucune plateforme de développement des SMA, par conséquent, le développeurchoisit la plate-forme appropriée.

2. MASC (Multi Agent Supply Chain) [Chehbi, 2007] [Chehbi et al., 2003]: MASC est unearchitecture à base d’agents dédiée à la modélisation et la simulation des processusde collaboration dans les chaînes logistiques. Les auteurs ont défini un modèle basésur des agents distribués de type BDI (Belief, Desire and Intention) qui décrivent lesobjectifs, les intentions et les croyances des acteurs dans une organisation de typeAGR (Agent-Groupe-Rôle) et réifiant quatre principaux rôles: Client, Fournisseur,Négociateur et Producteur. Ces agents appelés ‘agents-acteurs’ représentent lescentres de décision de la chaîne. Trois types de décisions: stratégiques, tactiqueset opérationnelles peuvent être abordées selon deux visions différentes. Une vision‘court et moyen termes’ qui ne considère que les facteurs et les critères opérationnelstel que le coût, la qualité, le prix et le niveau de stock. Une vision ‘long terme’ quis’intéresse quant à elle aux facteurs et critères qui déterminent la viabilité à longterme de l’entreprise sur un marché concurrentiel. Des propositions on été faites afinde rapprocher ces deux visions dans une démarche globale d’aide à la décision.

3. Dans [Jiao et al., 2006], les auteurs proposent un système multi-agent utilisant unenégociation multi contractuelle pour coordonner la fabrication dans une chaînelogistique. Le système est développé à l’aide de la plate-forme JADE et est utilisédans une compagnie de fabrication de téléphones mobiles.

4. Dans [Liang et Huang, 2005], les auteurs ont utilisé la technologie des agents poursimuler une CL et les méthodes de gestion du stock de chaque entité qui y appartient.Les agents emploient des algorithmes génétiques pour calculer la quantité optimaleà commander pour chaque échelon. Chaque agent communique et partage lesinformations de la demande avec les autres afin de minimiser le coût global. Lessupply chain managers des différentes entités partagent les informations avecconfiance. En outre, les agents explorent et stockent les connaissances des supply


30




chain managers sous forme de règles et les réutilisent plus tard en cas de problèmessemblables. Avec cette approche, les auteurs ont montré que le coût total est réduitau minimum.

5. OCEAN (Organisation and Control Emergence with an Agent Network) est unsystème de pilotage à architecture ouverte, décentralisée et basée sur descontraintes (distribution des ressources de production, distribution des donnéestechniques, adaptabilité pour répondre à la dynamique de l’environnement). Le but dece système est de montrer que des coopérations au niveau global peuvent apparaîtreà partir des compétitions au niveau individuel [Bournez et Gutknecht, 2001]. Ce travaila été réalisé à l’INSA de Lyon (France) et à l’université Montpellier 2 (France).

6. Le simulateur du jeu du Bois Québécois [Moyaux et al., 2004b] (jeu dérivé du jeu dela bièreJeu de la bière (en anglais, Beer Game) : c’est un jeu qui a été proposé parSterman en 1989 pour faire prendre conscience aux étudiants et aux industriels de ladynamique d’une chaîne logistique.) est un simulateur à base de système multi-agentservant à modéliser et simuler la chaîne logistique de l’industrie forestière du Québec.L’auteur a implémenté ce simulateur afin de valider deux principes qu’il a proposépour diminuer l’effet coup de fouet. Ce jeu permet d’enseigner ce qu’est l’effet coupde fouet ainsi que la complexité de la dynamique d’une chaîne logistique.

7. Le projet développé par Telle [Telle et al., 2003] est dédié aux relations entre Airbuset ses fournisseurs. La méthodologie et l’outil de simulation associés qui sontproposés dans ce projet sont destinés au diagnostic puis à l’aide à l’amélioration desperformances des relations Donneurs d’ordres / Fournisseur (DO/F) au sein d’unechaîne logistique. L’outil proposé utilise des techniques relevant de l’évaluation desperformances et de l’aide à la décision dans le domaine de la coopération industrielle.La démarche d’aide à la coopération proposée s’appuie sur la chronologie type desétapes utilisant des approches évaluatives. Sa spécificité tient au fait qu’elle estconçue pour être utilisée par un couple d’utilisateurs, acteurs d’une réelle relation DO/F. Dans ce projet, le fournisseur est modélisé par 4 sous-agents. Un sous-agent pourla fonction approvisionnement, un sous-agent pour la fonction production, un sous-agent pour la fonction distribution et un sous-agent système de conduite.

8. DragonChain [Kimbrough et al., 2001] a été implémenté pour automatiser lagestion de la chaîne logistique, et plus particulièrement pour réduire l’effet coupde fouet. Pour cela, ils se sont basés sur le modèle du jeu de la bière (à savoirles variantes Beer Game et Columbia Beer Game) et ont utilisé des agentsutilisant des algorithmes génétiques pour déterminer la meilleure politique deréapprovisionnement. Dans ce projet, chaque entreprise a été modélisée par unagent.

9. L’Agent Building Shell de l’université de Toronto (Ontario, Canada) est unebibliothèque logicielle de classes supportant des outils d’implémentation d’agents.L’architecture de ces agents est réalisée selon quatre couches : (i) la couche degestion de la connaissance, (ii) la couche d’ontologie, (iii) la couche de la coopérationet des conflits et (iv) la couche de communication et de coordination (cette quatrièmecouche est supportée par le langage COOL (pour COOrdination language). Plusieurschercheurs ont travaillé sur ce projet, en particulier Fox et Barbuceanu [Barbuceanuet Fox, 1996, Barbuceanu and Fox, 1995, Teigen and Barbuceanu, 1996, Beck andFox, 1994]. Dans ce projet, chaque entreprise a été modélisée par un agent.

10. MASCOT (Multi-Agent Supply Chain cOordination Tool) est une architecturereconfigurable, à niveau et basée sur les agents pour la planification et la coordination


31




qui vise à améliorer l’agilité d’un réseau logistique. Précisément, ce systèmecoordonne la production à travers les multiples installations (internes et externes)de l’entreprise, et évalue les décisions de conception de nouveaux produits/sous-composants et les décisions d’affaires stratégiques [Sadeh et al, 1999]. Ce travaila été réalisé à l’université Carnegie Mellon (Pittsburgh, PA, USA). Dans ce projet,chaque entreprise a été modélisée par un agent.

11. DASCh (Dynamic Analysis of Supply Chain) a été développé dans ERIM (Ann Arbor,MI, USA) par l’équipe de Parunak [Parunak et VanderBok, 1998, Baumgaertel etal., 2001] pour explorer les techniques de modélisation des réseaux de fournisseurset des fournisseurs de leurs fournisseurs. En particulier, les flux de produits etd’informations sont agentifiés afin de modéliser le fait qu’ils ne soient pas parfaits(Prise en compte des délais et incertitudes sur les flux par des agents). Chaqueentreprise a été modélisée par 2 agents et un agent pour les flux.

Ce bref état de l’art montre bien que les SMA sont devenus populaires pour la modélisationet le pilotage des chaînes logistiques. Néanmoins, nous relevons quelques lacunes:

∙ Le développement des applications pour la chaîne logistique à base de SMAreste assez compliqué et prend beaucoup de temps. Actuellement, le processusde modélisation prend beaucoup de temps puisqu’il n'existe pas de méthodesgénériques pour la modélisation des CL en utilisant les systèmes multi-agent àl’exception de méthodologies telle que celle proposée dans [Govindu et Chinnam,2007] qui sont encore en cours de développement. Un nombre limité d’auteurs(comme [Fox et al., 2000], [Swaminathan et al., 1998]) ont discuté l’importance dedévelopper des composants génériques et réutilisables, la plupart des applicationsutilisent des modèles particuliers liés à une problématique industrielle ou logistiquespécifique.

∙ La littérature ne considère pas explicitement les phases d’analyse et de conceptionde l’application à base de SMA (qui sont des phases importantes dans le cycle dedéveloppement des applications industrielles) mais s’attaque directement à la phased’implémentation à partir des besoins.

∙ Dans la littérature, il apparaît que la plupart des applications sont orientéesrecherche. En effet, un nombre important de chercheurs ont utilisé les SMA pourmodéliser et simuler la chaîne logistique en vue de tester et d’évaluer des pratiqueset des techniques de collaboration basées en général sur le partage d’informations.Pour plus de détail, le lecteur pourra se référer à l’étude effectuée par S. Terzi et S.Cavalieri [Terzi et Cavalieri, 2003] concernant l’utilisation de la simulation dans la CL.Au contraire il existe un nombre réduit de prototypes qui ont utilisé des langages deprogrammation (comme Java), logiciels commerciaux (comme ADE, G2), ou logicielsgratuits (freeware)/outils libres (open-source toolkits) (comme Swarm, JATLite, JADE)pour développer des applications réelles à base de SMA.

La recherche que nous menons contribue à l’utilisation des agents pour le développementdes applications réelles qui aident à la prise de décision collaborative dans la CL. L’intérêtde notre travail réside au niveau des agents d’interface intelligents liés aux systèmesd’informations des différents acteurs pour exécuter une simulation proactive distribuéerenseignant les décideurs et les supply chain managers sur les scénarios possibles etacceptables en cas de situations d’urgences.

Comme on a montré ci-dessus, puisqu’il n’existe pas un modèle générique pour lachaîne logistique (ils sont en cours de développement), nous avons développé notre propre


32




modèle (cf. chapitre 3) pour traiter notre problématique. Il est quasi-générique et convient àun grand nombre de chaînes logistiques ou groupements d’entreprises.

1.6. ConclusionDans ce chapitre, nous avons présenté quelques problématiques liées au niveau de laplanification tactique dans les chaînes logistiques afin de délimiter notre champ d’étude.Plusieurs travaux, outils et méthodes développées dans le cadre du SCM sont mis enplace afin de palier de manière directe ou indirecte à ces problématiques. Cependant, lamajorité de ces méthodes possèdent des faiblesses au niveau de la problématique quenous traitions.

L’utilisation des SMA dans les chaînes logistiques est en pleine évolution. Elle concernela simulation et le développement de nouveaux outils remplaçant ou bien complétant ceuxqui existent auparavant.

Notre contribution dans le cadre de ce mémoire, consiste à utiliser le paradigme desSMA pour développer une architecture distribuée de simulation et d’aide à la décisionpermettant d’automatiser et synchroniser les décisions des supply chain managers lors dela présence des commandes non prévues, des commandes imprécises ou des exceptions(problème de production, problème de transport, erreur sur prévisions, retard de livraison,etc.). Notre objectif est de combler les lacunes des principaux outils utilisés dans laplanification tactique. D’un autre point de vue, nous visons à rendre la CL plus stable devantles aléas et les perturbations.

Chapitre 2 : Systèmes Multi-Agent : une Approche pour les Architectures Distribuées deSimulation et d’Aide à la Décision

33




Chapitre 2 : Systèmes Multi-Agent :une Approche pour les ArchitecturesDistribuées de Simulation et d’Aide à laDécision

2.1. IntroductionLes systèmes multi-agent se situent dans le prolongement de l’Intelligence ArtificielleDistribuée (IAD) qui se définit comme l’étude et la conception d’organisations d’agentsartificiels pour obtenir des systèmes intelligents [Demazeau et Müller, 1991]. Les systèmesmulti-agent se veulent de portée plus générale que l’IAD, puisqu’ils concernent la résolutionde problèmes au sens large, la robotique distribuée, la simulation et la conception demondes hypothétiques [Ferber, 1995].

De la notion de système multi-agent (SMA) se dégage immédiatement l’idée d’unsystème qui est fait de plusieurs agents. Le concept d’agent reste donc le pivot de cedomaine et l’interprétation qu’on a de ce terme doit être le premier pas dans l’explorationdes univers multi-agent. La façon dont les agents interagissent entre eux permettra ensuitede cerner comment les systèmes multi-agent sont construits.

Après avoir montré dans le premier chapitre que le paradigme des agents convientmieux pour traiter la problématique présentée dans ce mémoire. Nous passons en revuedans ce chapitre plusieurs concepts liés au domaine des agents. Nous présentonsprincipalement les arguments qui guideront et renforceront notre choix de la méthodologiede conception et d’analyse ainsi que la plate-forme multi-agent à utiliser pour implémenternotre architecture distribuée.

2.2. Notion d’agentLe concept d’agent a été introduit an tant qu’idée centrale de l’intelligence artificielledistribuée. Nous donnons deux définitions couramment admises, celle de Ferber [Ferber,1995] et celle de Wooldrige [Wooldridge et Jennings, 1995].

Définition de Ferber :On appelle agent une entité physique ou virtuelle :

∙ qui est capable d’agir dans un environnement,∙ qui peut communiquer directement avec d’autres agents,


34




∙ qui est mue par un ensemble de tendances (sous la forme d’objectifs individuels oud’une fonction de satisfaction, voire de survie, qu’elle cherche à optimiser),

∙ qui possède des ressources propres,∙ qui est capable de percevoir (mais de manière limitée) son environnement,∙ qui ne dispose que d’une représentation partielle de cet environnement (et

éventuellement aucune),∙ qui possède des compétences et offre des services,∙ qui peut éventuellement se reproduire,∙ dont le comportement tend à satisfaire ses objectifs, en tenant compte des

ressources et des compétences dont elle dispose, et en fonction de sa perception, deses représentations et des communications qu’elle reçoit.

Cette définition met l’accent sur l’insertion d’un agent dans un environnement et eninteraction avec les autres agents. Elle met aussi l’accent sur la capacité d’agir et surl’autonomie puisqu’il dispose de tendances et d’objectifs.

Définition de Wooldridge :Le terme agent caractérise un système informatique matériel ou (plus souvent) logiciel quicomporte les caractéristiques suivantes :

∙ Autonomie : l’agent agit sans l’intervention d’humains ou d’autres intervenants, et aun certain contrôle sur ses actions et ses états internes.

∙ Capacités sociales : l’agent interagit avec d’autres agents (pouvant être des êtreshumains) à l’aide d’un langage de communication d’agent.

∙ Réactivité :l’agent perçoit son environnement (qui peut être un monde physique,un utilisateur via une interface graphique, un ensemble d’autres agents, Internet,ou encore tous ces éléments combinés), et répond de manière opportuniste auxchangements qui y surviennent.

∙ Pro-activité : l’agent n’agit pas simplement aux stimuli de son environnement, il estaussi capable de démontrer des comportements dirigés par des buts en prenant desinitiatives.

Nous retrouvons dans les deux définitions, les notions de réactivité, de pro-activité et unedimension sociale même si Ferber n’utilise pas ces termes-là.

En plus des propriétés citées ci-dessus, nous pouvons en identifier d’autres issues desdéfinitions qui apparaissent dans la littérature, comme par exemple [Briot et Demazeau,2001] [Hunhns et Singh, 1999] [Sycara, 1998] [Franklin et Graesser, 1996] [Wooldridge etJennings, 1995] :

∙ Raisonnement : Un agent peut décider quel but poursuivre ou à quel événementréagir, comment agir pour accomplir un but, ou suspendre ou abandonner un but pourse dédier à un autre.

∙ Apprentissage : L’agent peut s’adapter progressivement à des changements dans desenvironnements dynamiques grâce à des techniques d’apprentissage.

∙ Mobilité: Dans des applications déterminées il peut être intéressant de permettre auxagents de migrer d’un noeud à un autre dans un réseau tout en préservant leur étatlors de sauts entre noeuds.

Il existe deux grandes classes d’agents obtenues en fonction de leurs capacités deraisonnement : les agents réactifs et les agents cognitifs. Les agents réactifs opèrent


35




selon un cycle Perception/Action. Leur comportement est fondé sur un ensemble destimuli-réponses, i.e. à une perception donnée, il existe une action qui est programmée.La communication entre agents et les interactions avec l’environnement sont trèsrudimentaires. Les agents réactifs présentent certaines caractéristiques intéressantes[Drogoul, 1993] : la simplicité de la description d’un comportement local et l’émergencedes comportements globaux complexes, malgré la simplicité des agents. La fourmilière duprojet MANTA est un exemple de société d’agents réactifs [Drogoul, 1993]. Les agentscognitifs se calquent sur le modèle humain. Chaque agent dispose d’une représentationpartielle de l’environnement et des autres agents. Ils agissent selon un cycle Perception/Décision/Action. Chaque agent a donc la possibilité de raisonner en fonction de ses propresbuts, des connaissances qu’il a des autres agents. Les agents ont, de plus, la capacité decommuniquer avec les autres agents selon un mode de communication proche de celuiprésent dans les conversations humaines.

A l’intérieur de chacune de ces deux classes, différentes architectures d’agents peuventêtre choisies. Ce choix dépend du domaine d’application mais aussi des fonctionnalités del’agent souhaitées par le concepteur.

2.3. Notion de système multi-agent

2.3.1. DéfinitionFerber [Ferber, 1995] définit un système multi-agent comme suit :

On appelle système multi-agent un système composé des éléments suivants :a. Un environnement E, c’est-à-dire un espace disposant généralement d’une métrique.b. Un ensemble d’objets O. Ces objets sont situés, c’est-à-dire que, pour tout objet, il

est possible, à un moment donné, d’associer une position dans E. Ces objets sont passifs,c’est-à-dire qu’ils peuvent être perçus, créés, détruits et modifiés par les agents.

c. Un ensemble A d’agents, qui sont des objets particuliers (A inclut dans O), lesquelsreprésentent les entités actives du système.

d. Un ensemble de relations R qui unissent des objets (et donc des agents) entre eux.e. Un ensemble d’opérations Op permettant aux agents de A de percevoir, produire,

consommer, transformer et manipuler des objets de O.f. Des opérateurs chargés de représenter l’application de ces opérations et la réaction

du monde à cette tentative de modification, que l’on appellera les lois de l’univers.Il faut noter que tous les systèmes n’auront pas nécessairement besoin d’être décrits

avec tous ces éléments. Il arrive par exemple que les ensembles E ou O – A soient videsdans des situations où il n’est pas nécessaire de prendre en compte un environnement pourles agents, ou qu’il n’existe pas dans le système des objets inertes. On parlera d’ailleurslorsque E est vide d’un système multi-agent purement communicant.

Les systèmes multi-agent ont des applications diverses : la chaîne logistique, le pilotagede la production, la gestion des réseaux informatiques, le commerce électronique, lestélécommunications, la planification, la robotique, etc. Nous référons le lecteur à [Jennings,2000a] pour une présentation d’exemples significatifs.


36




2.3.2. InteractionsUne interaction est une mise en relation dynamique de deux ou plusieurs agents par lebiais d’un ensemble d’actions réciproques [Ferber, 1995]. Les interactions s’expriment àpartir d’une série d’actions dont les conséquences exercent, en retour, une influence surle comportement futur des agents. Les interactions sont des éléments indispensables auxagents. En effet, l’interaction est une condition nécessaire à la coopération. La notiond’interaction suppose :

∙ Un ensemble d’agents capables d’agir et/ou de communiquer,∙ Des situations susceptibles de servir de point de rencontre entre agents

(collaboration, utilisation des ressources limitées),∙ Des éléments dynamiques permettant des relations locales et temporaires entre

agents,∙ Une certaine flexibilité dans les relations entre agents, en leur permettant à la fois de

créer, de maintenir ou de briser les relations.

La communication est une forme particulière d’interaction, qui tend à modifier l’étatmental de l’agent destinataire et éventuellement de l’agent émetteur. Les situationsd’interactions entre agents sont nombreuses et diverses : coopération, coordination,échange d’informations, résolution de conflits, etc.

La coopération consiste à répartir le travail entre plusieurs agents pour la mise en œuvrecommune. Alors que la coordination s’intéresse à la manière dont les actions des agentssont organisées dans le temps et dans l’espace pour accomplir les buts. On distingue quatreformes de coordination d’actions [Ferber, 1995] :

∙ La coordination par synchronisation : il s’agit de la forme la plus basique pour laquelleles actions sont décrites précisément au niveau de leur enchaînement.

∙ La coordination par planification : cette technique repose sur un découpage del’action en deux phases. La première consiste à créer un ensemble de plans d’actionsqui décrivent précisément les actions à effectuer pour atteindre un but. La secondeest l’exécution de l’un de ces plans.

∙ La coordination réactive : cette technique considère qu’il est plus facile de mettreen œuvre des mécanismes de coordination fondés sur des agents réactifs que deplanifier l’ensemble des actions.

∙ La coordination par réglementation consiste à ordonner les règles de comportementqui visent à éliminer les conflits potentiels entre agents.

2.3.3. Langages de communication entre agentsGrâce à la coordination, un système multi-agent peut réaliser ses tâches avec plusd'efficacité qu'un seul agent. Mais pour coordonner l'activité d'un ensemble hétérogèned'agents autonomes, il faut que les agents communiquent dans un langage compréhensiblepar tous les autres.

L'utilisation d'un langage de communication16 commun implique que tous les agentscomprennent son vocabulaire sous tous ses aspects concernant:

∙ la syntaxe, qui précise le mode de structuration des symboles;∙ la pragmatique pour pouvoir interpréter les symboles;

16 Ang. Agent Communication Language


37




∙ l'ontologie pour pouvoir utiliser les mêmes mots d'un vocabulaire commun.

KQML17 (Knowledge Query and Manipulation Language) et FIPA18-ACL(Foundation forIntelligent Physical Agents – Agent Communication Language) [FIPA, 2002a] sont deuxprincipaux langages de communication entre agents. Ils sont presque identiques ence qui concerne leurs concepts de base et les principes qu’ils observent. Ils diffèrentprincipalement dans les détails de leurs cadres sémantiques. Dans un sens, cette différenceest substantielle :

∙ il n'est pas possible de proposer une traduction systématique entre les performativesde KQML et celles complètement équivalentes de FIPA, ou vice-versa ;

∙ les différences inéluctables pourraient avoir peu d'importance pour les programmeursd'agents intelligents, si leurs agents ne sont pas de véritables agents BDI (Belief –Desire – Intention), en Français "Croyance – Désir – Intention".

Chaque message KQML ou FIPA-ACL comprend plusieurs éléments. Voici quelques uns :Performative : Type de l’acte communicatif (passage d’information, réquisition

d’information...). L’annexe B présente quelques actes du langage FIPA-ACL.Sender : L’émetteur du message.Receiver : Le destinataire du message.Content : Le contenu du message (l’information transportée par la performative).Les deux langages n’impliquent aucun engagement de base vis-à-vis d’un langage pour

le contenu. Plusieurs langages peuvent être utilisés pour coder le contenu, comme :

∙ Le langage KIF19 (KnowledgeInterchange Format).∙ SQL, PROLOG, STEP.

2.4. Axes de recherche dans le domaine des agentsSelon Pavan [Pavón, 2006], il y’a trois axes de recherche dans l’aire des agents commecela est montré dans la figure 2.1 [Wooldridge et Jennings, 1995], selon que l’on donneplus ou moins d’importance aux aspects cognitifs (raisonnement, apprentissage), sociaux(communication et coopération), ou de mobilité (agents mobiles).

17 http://www.cs.umbc.edu/kqml18 FIPA : Foundation for Intelligent Physical Agents, organisme de normalisation privé (Genève, Suisse). http://www.fipa.org/

http://www.cs.umbc.edu/kqml


38




Fig. 2.1 - Caractérisation des agentsEn général, les travaux sur les agents mobiles laissent de côté les caractéristiques

sociales et cognitives et se centrent sur le fondement de modèles de migration et denavigation des agents dans un réseau, et d’autres problèmes associés comme celui de lasécurité. Les aspects cognitifs déterminent à quel point le comportement de l’agent peutêtre complexe. Par ailleurs, les aspects sociaux sont l’élément différenciateur des systèmesbasés sur les agents par rapport à d’autres paradigmes du domaine de l’intelligenceartificielle, comme les systèmes experts.

En plus de ces trois axes décrits ci-dessus, il s’ajoute l’axe de l’ingénierie dessystèmes multi-agent. Elle comprend les méthodologies agents et les plates-formes dedéveloppement. Nous parlerons de cet axe dans les prochaines sections.

2.5. Méthodologies de développement de SMAActuellement, il existe un nombre important de méthodologies et d’outils de conception deSMA [Bauer et Müller, 2004]. Chacune d’entre elles se fonde sur une base conceptuellepropre et recouvre un certain nombre d’aspects dont la prise en compte est considéréeessentielle. La plupart de ces propositions méthodologiques sont inspirées des résultatsdu domaine du génie logiciel orienté objets. Dans cette section nous présentons un certainnombre d’exemples de ces méthodologies et nous terminons par quelques arguments quirenforcent notre choix de la méthodologie à utiliser pour notre application SMA dans ledomaine de la chaîne logistique.

AUML [Odell et al, 2001] a pour but d’étendre UML avec des facilités permettant dedécrire des agents. Ce formalisme a comme but de recommander une technologie pourl'adoption d'une sémantique, d’un méta-modèle et d’une syntaxe abstraite communes pourl'analyse et la conception des méthodologies basées sur les agents. Cette technologiedevra permettre de couvrir le cycle de vie des produits et des outils de travail AUML et


39




être en accord avec les spécifications existantes de FIPA et l’OMG (Object ManagementGroup). Actuellement, les versions 2.0 et 2.1 d’UML ont intégré plusieurs concepts d’AgentUML, comme ceci est montré sur le site20 officiel d’AUML. Ainsi avec UML 2.0 et versionsultérieures, on pourra modéliser une application orientée agent. Pour plus de détails sur cepoint, le lecteur pourra se référer à l’article de B. Bauer et J. Odell [Bauer et Odell, 2005].

M-UML a été proposée par K. Saleh et C. El-Morr [Saleh et El-Morr, 2004] pourmodéliser les agents mobiles.

GAIA [Wooldridge et al., 2000] est une méthodologie où le système multi-agent estvu comme une organisation composée de rôles interagissant entre eux. La méthodologieprend comme point de départ une description de la structure organisationnelle du système,composée de rôles et d’interactions entre eux. Deux phases sont distinguées (figure 2.2) : laphase d’analyse qui permet de constituer le modèle des rôles et le modèle des interactions,et la phase de conception durant laquelle sont créés les modèles d’agents, de services etd’accointances.

Cette méthodologie aborde la conception d’un SMA sans un modèle d’architectured’agent préétabli. Son utilisation conduit à un ensemble de spécifications qui peuvent seconsidérer au niveau d’analyse. Mais la conception est très faible, puisque aucun modèlecomputationnel n’est envisagé. Il n’y a pas non plus de guides méthodologiques, parexemple, pour assigner les rôles aux agents [Pavón, 2006]. Et bien que dans sa version laplus récente sont envisagés des aspects organisationnels [Zambonelli et al., 2003], aucunpatron d’organisation n’est proposé, ni comment déterminer le type de rôles qui devraitexister dans une organisation. Par conséquent l’utilité de Gaia pour la réalisation de SMAest assez limitée, mis à part les apports qui peuvent être obtenus quant à l’étude qu’il faitsur la définition de rôles et d’interactions, bien que ces dernières se spécifient de manièreassez simple et sans considérer les aspects de concurrence [Pavón, 2006].

Fig. 2.2 - Les relations entre les modèles de la méthodologie GAIAMaSE [DeLoach et al., 2001] (Multi-agent System Engineering) est une méthodologie

générique qui considère comme point de départ le contexte initial du système, supposécontenir un ensemble bien défini d’exigences fonctionnelles, et permettre d’en extraire unensemble de buts hiérarchisés. Elle est centrée sur les aspects pratiques de constructionde SMA. Cette méthodologie est composée de deux phases (figure 2.3). La phased’analyse se déroule en trois étapes : capture des buts, application des cas d’utilisationet raffinement des rôles. La phase de conception comporte quatre étapes: création desclasses d’agents, construction des conversations, assemblage des classes d’agents et

20 www.auml.org


40




conception du système. La méthodologie MaSE utilise des notations similaires à UML etpropose un cycle de développement interactif et incrémental avec des activités d’analyseet de conception, qui sont assistées par l’outil AgentTool [DeLoach et Wood, 2000].

MaSE propose de commencer avec une analyse des buts car elle considère que lesbuts sont plus stables dans l’analyse et la conception que les fonctions, les processus etles structures d’information. Cette analyse des buts et leur distinction claire par rapport àune analyse fonctionnelle classique sont les apports les plus intéressants de MaSE. Ellepropose aussi un mécanisme pour l’identification des rôles et leur assignation aux agents.Pour arriver finalement à un modèle computationnel des agents, il réalise, cependant, unecertaine simplification quand on considère que chaque type d’agent correspond à une classed’objets. D’autre part, certaines considérations, comme celle d’assumer que l’on disposed’un ensemble de besoins fonctionnels initial ou la détermination d’un ensemble établi deconversations, font que leur applicabilité se limite à résoudre des problèmes similaires àceux traités avec une méthodologie orientée objets classique [Pavón, 2006]. C’est ainsi quele résultat est un ensemble de classes dont le comportement est défini par des automatesmais il n’est pas clair comment on pourrait aborder la construction des agents délibératifs,comme c’est le cas des agents BDI, puisque on ne définit plus, par exemple, comment géreret contrôler la satisfaction ou l’échec des buts.


41




Fig. 2.3 - La méthodologie MaSEAALAADIN [Ferber et Gutknecht, 1998] est un méta-modèle reposant sur les concepts

organisationnels que sont les agents, groupes et rôles (AGR), pris ici comme conceptsprimitifs, et issus d’une analyse préalable du système envisagé. L’organisation est définiecomme un cadre d'activité et d'interaction, mis en place par la définition de groupes, rôleset de leurs relations, et considérée comme l’ensemble des relations structurelles dansun ensemble d'agents. Un SMA est vu par l’approche AALAADIN, comme un ensemblede groupes d’agents interconnectés par l’intermédiaire d’agents appartenant à plusieursgroupes (figure 2.4). Aucune contrainte ou pré-requis n’est imposée sur l’architecture internedes agents et aucun formalisme où modèle particulier n’est supposé pour en décrireleur comportement. Chaque agent est simplement décrit comme une entité autonomecommunicante qui joue des rôles au sein des différents groupes. La méthode AALAADIN adonné lieu au développement de la plate-forme MadKit, développée par O. Gutknecht et J.Ferber [Gutknecht et Ferber, 2001], sur laquelle nous reviendrons.


42




Fig. 2.4 - Les trois concepts centraux d’AALAADINLa liste présentée ci-dessus n’est pas limitative. Dans la littérature on trouve d’autres

méthodologies partant des résultats du domaine du génie logiciel orienté objets (ADELFE[Picard et al., 2002], AAII/BDI [Rao et Georgeff, 1991], Kendall [Kendall, 1995], MASB[Moulin et Brassard, 1996], ODAC [Gervais, 2003], MESSAGE [Caire et al., 2001]) ouappliquent des techniques de construction de systèmes experts (CoMoMAS [Glaser, 1996],MAS-CommonKADS [Iglesias, 1998]). D’autres donnent plus d’importance aux relationsentre les divers aspects du SMA, comme dans VOYELLES [Demazeau, 1995], INGENIAS[Pavón et Gómez-Sanz, 2003] ou MASSIVE [Lind, 2001].

Ci-dessous, nous montrons quelques arguments guidant et renforçant notre choix dela méthodologie à utiliser pour la phase de modélisation de notre architecture :

∙ Il existe un nombre important de méthodologies et d’outils de conception de SMA etla communauté travaillant dans le domaine des agents se trouve en face du problèmed’identification d’un vocabulaire commun pour les supporter [Bauer et Müller, 2004].Cependant, il n’existe pas encore une méthodologie standard suffisamment maturequi aborde tous les aspects nécessaires pour définir un SMA, ni tout le cycle dedéveloppement de ce type de logiciel.

∙ J. Pavón, l’un des auteurs de la méthodologie INGENIAS [Pavón et Gómez-Sanz,2003] affirme dans [Pavón, 2006] que malgré l’existence de beaucoup d’applicationsbasées sur les agents, il manque encore l’expérience pour la conception et laconstruction de SMA à un niveau industriel (une révision plus récente de l’état del’art et des applications de la technologie des agents se trouve dans [Luck, 2004]).La grande majorité des applications basées sur les agents est construite sans utiliserdes composants agents réutilisables et ne sont pas généralisables. C’est pourcela que la recherche sur les méthodes, les outils et les plates-formes d’agents abeaucoup d’importance pour l’implantation de la technologie d’agents en dehors dudomaine purement académique. Dans la situation actuelle, peu de méthodologiesont amené des cas réels significatifs à la pratique et sont assistées par des outils.En plus, les méthodologies existantes ne considèrent que certains aspects du cyclede vie, généralement l’analyse et la conception. Pour l’implémentation, la plupartdes méthodologies sont conditionnées par l’utilisation d’une architecture d’agentsdéterminée.

∙ Le paradigme d’agent peut s’étendre à celui d’objet. En conséquence, uneméthodologie de développement de SMA devrait profiter de l’expérience del’approche objet. Les méthodologies orientées objets ont acquis un haut niveaude maturité et leurs avantages sont largement reconnus. Une grande partie desdéveloppeurs de logiciel sont familiarisés avec elles et utilisent la large gammed’outils disponibles [Pavón, 2006].


43




Afin de donner un cadre méthodologique au processus de modélisation, nous allons parla suite appliquer le formalisme AUML et par conséquent UML 2.1 qui contient un grandnombre de concepts liés aux agents. En fait, UML est un standard largement connu,accepté et a fait ses preuves pour la modélisation des applications orientées objet. Le faitque le paradigme des agents est considéré comme une extension du paradigme objet aconduit plusieurs auteurs pour étendre UML afin de tenir compte des concepts agents. Unediscussion sur ce sujet a été présentée dans [Bauer et al., 2001]. En choisissant AUML,nos modèles proposés dans ce manuscrit seront largement diffusés et compris. D’autresarguments plus techniques liés à la problématique que nous traitions et qui renforcent notrechoix seront présentés dans les prochains chapitres.

2.6. Plates-formes de développement de SMALes environnements de développement ou les plates-formes multi-agent sont nécessairespour renforcer le succès de la technologie multi-agent. Les plates-formes multi-agentpermettent aux développeurs de concevoir et réaliser leurs applications sans perdre detemps à réaliser des fonctions de base pour la création et l'interaction entre agents etéliminent, dans la plupart des cas, la nécessité d'être familier avec les différents conceptsthéoriques des systèmes multi-agent.

Dans cette section nous allons présenter sommairement quelques plates-formes dedéveloppement de SMA. Nous la concluons par les critères guidant notre choix de la plate-forme à utiliser pour la phase d’implémentation de notre outil SMA.

Il existe un nombre important d'environnements de développement des applicationsorientées agents : il y a aussi bien des produits commerciaux que des logiciels dansle domaine public. Une liste assez complète de ces plates-formes se trouve à l'adresse« 170H170H191H170H170Hhttp://www.agentlink.org/ ». Parmi les plates-formes fourniescomme logiciels libres, il y a quelques unes plus connues pour avoir été utilisées dans ledéveloppement de plusieurs applications : JADE, MACE, ZEUS, et MADKIT pour les agentscognitifs, et SWORM pour les agents réactifs. Il faut noter que cette liste n'est pas unique,et qu'il y a aussi d'autres plates-formes qui ont été utilisées avec beaucoup de succès pourbâtir diverses applications.

JADE (Java Agent Development Framework) [Bellifemine et al., 1999] est une plate-forme multi-agent développée en Java par CSELT (Groupe de recherche de GruppoTelecom, Italie) qui a comme but la construction des systèmes multi-agent et la réalisationd'applications conformes à la norme FIPA [FIPA, 1997]. JADE comprend deux composantesde base : une plate-forme agents compatible FIPA et un paquet logiciel pour ledéveloppement des agents Java. La plate-forme multi-agent JADE sera présentée dans lechapitre 4, car c’est cette plate-forme qu’on a utilisée pour développer notre architecture.Les autres mentionnées ci- dessous vont être présentées d'une manière synthétique danscette section même.

MACE [Gasser et al., 1987] est le premier environnement de conception etd'expérimentation de différentes architectures d'agents dans divers domaines d'application.Dans MACE, un agent est un objet actif qui communique par envoi de messages. Lesagents existent dans un environnement qui regroupe tous les autres agents et toutes lesautres entités du système. Un agent peut effectuer trois types d'actions : changer sonétat interne, envoyer des messages aux autres agents et envoyer des requêtes au noyau


44




MACE pour contrôler les événements internes. Chaque agent est doté d'un moteur quireprésente la partie active de l'agent. Ce moteur détermine l'activité de l'agent et la façondont les messages sont interprétés. MACE a été utilisé pour développer des simulationsd'applications distribuées.

ZEUS [Nwama et al., 1999] est une plate-forme multi-agent conçue et réalisée parBritish Telecom (Agent Research Programme of BT Intelligent Research Laboratory) pourdévelopper des applications collaboratives. ZEUS est écrit dans le langage Java et il estfondé sur les travaux de la FIPA. L'architecture des agents ZEUS est similaire à la majoritédes agents collaboratifs. Elle regroupe principalement les composantes suivantes :

∙ une boîte aux lettres et un gestionnaire de messages qui analyse les messages de laboîte aux lettres et les transmet aux composantes appropriées ;

∙ un moteur de coordination ;∙ un planificateur qui planifie les tâches de l'agent en fonction des décisions du moteur

de coordination, des ressources disponibles et des spécifications des tâches ;∙ plusieurs bases de données représentant les plans connus par l'agent, les ressources

et l'ontologie utilisée ;∙ un contrôleur d'exécution qui gère l'horloge locale de l'agent et les tâches actives.

L'environnement comporte trois bibliothèques : une avec des agents utilitaires, une avecdes outils pour la construction des agents, et une avec des composants agents.

ZEUS met un fort accent sur la méthodologie de développement, fondée sur la notionde rôle. ZEUS a été utilisé pour développer plusieurs applications réelles comme lesventes aux enchères et la simulation de la fabrication des ordinateurs. Les caractéristiquesdes domaines d'applications de ZEUS ont été définies par les concepteurs ; parmi cescaractéristiques, on peut mentionner :

∙ chaque agent crée un plan qui nécessite un raisonnement explicite pour atteindre sonbut ;

∙ la résolution de problèmes nécessite une coopération entre agents ;∙ le rôle de chaque agent consiste à contrôler un système externe qui réalise une

tâche du domaine d'application, la résolution de problème est ainsi effectuée par cesystème externe et contrôlée par les agents.

MADKIT [Gutknecht et Ferber, 2001] est une plate-forme développée par le Laboratoired'Informatique, de Robotique et de Microélectronique de Montpellier (LIRMM) de l'UniversitéMontpellier II. MADKIT est libre pour l'utilisation dans l'éducation. MADKIT est écrit en Javaet est fondé sur le modèle organisationnel ALAADIN (cf. section 2.5). Il utilise un moteurd'exécution où chaque agent est construit en partant d'un micro-noyau. Chaque agent a unrôle et peut appartenir à un groupe. Il y a un environnement de développement graphiquequi permet facilement la construction des applications.

SWARM [Minar et al., 1996] est une plate-forme multi-agent avec agents réactifs.L'inspiration du modèle d'agent utilisé vient de la vie artificielle. SWARM est l'outil privilégiéde la communauté américaine et des chercheurs en vie artificielle. L'environnement offre unensemble de bibliothèques qui permettent l'implémentation des systèmes multi-agent avecun grand nombre d'agents simples qui interagissent dans le même environnement.

Après cette présentation sommaire de quelques environnements de développement deSMA, nous donnons maintenant les arguments et les caractéristiques qui nous ont conduità choisir la plateforme JADE pour implémenter notre architecture distribuée (cf. chapitre


45




4). Nous avons classé ces caractéristiques en deux types, caractéristiques techniques etcaractéristiques d’ordre général:

a. Caractéristiques d’ordre technique liées à notre problème :Par rapport à notre problème, JADE utilise l'abstraction Comportement (Behavior)pour modéliser les tâches qu'un agent peut exécuter et les agents instancient leurscomportements selon leurs besoins et leurs capacités. En conséquence, nous pouvonsrapidement générer le squelette de code d’un agent JADE à partir du diagramme d’états-transistions (statechart) AUML (qu’on a choisi pour la phase de modélisation) modélisantson comportement. Ceci à une grande importance dans la phase d’implémentation. D’autresarguments plus techniques tels que ceux concernant l’implémentation des protocolesd’interaction seront exposés dans le chapitre 4.

b. Caractéristiques d’ordre général [Chmiel et al., 2004] [JADE, 2008]:∙ Plate-forme agent satisfaisant aux spécifications de la FIPA (organisme de

normalisation de spécifications concernant les agents),∙ Fournit plusieurs API pour les développeurs des agents en Java,∙ JADE se trouve actuellement en plein développement et possède toutes les

possibilités d’être extensible dans le futur,∙ JADE s’exécute sur plusieurs systèmes d’exploitation, en particulier Windows et

Linux.∙ Projet Open Source, LGPL Licence, cette licence assure le droit de :

– faire des copies de JADE et de les distribuer– accéder au code source– réaliser des améliorations au logiciel– utiliser JADE à partir de logiciels commerciaux propriétaires

∙ Outil support pour plusieurs projets en état de transfert technologique ou enexploitation commerciale,

∙ Plus de 10 grosses institutions (universités, entreprises) contribuent audéveloppement,

2.7. Modélisation et simulation : approche multi-agentLa simulation est la démarche scientifique qui consiste à réaliser une reproduction artificielle,appelée modèle, d’un phénomène réel que l’on désire étudier, à observer le comportementde cette reproduction lorsqu’on en fait varier expérimentalement certains paramètres, et àen induire ce qui se passerait dans la réalité sous l’influence de variations analogues. Leprocessus de simulation passe donc par l’élaboration d’un modèle.

La modélisation d’un phénomène dans une perspective multi-agent se traduit par[Drogoul, 1993] :

∙ une décomposition du phénomène en un ensemble d’éléments discrets et autonomesdont les interactions reproduisent le phénomène ;


46




∙ la modélisation de chacun de ces éléments par un agent, en précisant éventuellementses connaissances, ses capacités fonctionnelles, ses comportements et les modesd’interaction qu’il adoptera à l’encontre des autres agents ;

∙ la définition de l’environnement des agents, espace topologique et / ou temporel danslequel les agents évoluent, ainsi que des lois qui le gouvernent et de ses réactionsaux actions des agents.

2.7.1. Simulation Orientée AgentLa simulation orientée agent21 est de plus en plus utilisée dans différents domaines. Lestechniques de simulation orientée objets [Troitzsch, 1997] et centrées sur l’individu [Harding,1999], sont en train de céder leur place à cette nouvelle technique. Dans [Drogoul et al.,2002], les auteurs justifient le fait que la simulation orientée agent est devenue le support dechoix pour la simulation de systèmes complexes par les deux principales raisons suivantes :

1. La capacité de la simulation orientée agent à s’adapter à des modèles très différentsdes entités à simuler. Elle utiliserait ainsi des agents réactifs [Drogoul, 1995] pour simulerdes entités simples et déploierait des agents cognitifs [Jennings, 2000b] pour simuler desentités plus complexes.

2. La simulation orientée agent offre au concepteur la possibilité de manipuler différentsniveaux de représentations (ex. ‘individu’, ‘groupe’ et ‘cluster’), contrairement à uneapproche basée sur les automates cellulaires [Vanbergue et al., 2000].

2.7.2. Branches de la simulation orientée agentSelon Ören et al. [Ören et al., 2000], les agents peuvent être combinés de trois façonspossibles à la simulation, ce qui a donné naissance aux trois sous branches suivantes :simulation agent, simulation basée sur les agents et simulation supportée par les agents.

Simulation Agent : la simulation agent22 est la simulation d’entités qui peuvent êtrereprésentées pas des agents [Ören et al., 2000]. Elle est la façon naturelle de modéliseret de simuler des entités intelligentes. Ces entités peuvent être des humains ou encoredes entités artificielles telles que les plateformes intelligentes, les équipements, etc. Dansle domaine militaire par exemple, la simulation agent serait donc de modéliser des entitésintelligentes et quasi autonomes. Les agents pourraient représenter des individus amis ouennemis, des troupes, des plateformes, des armes ou tout autre équipement. Quant à notrearchitecture, elle supporte ce type de simulation. En fait, comme nous allons le montrer dansle chapitre 3, chaque acteur de la CL sera représenté par un ensemble d’agents.

Simulation basée sur les agents : la simulation basée sur les agents23 est le fait d’utiliserdes agents dans la simulation afin de générer un modèle de comportement [Ören et al.,2000]. Elle offre également des possibilités additionnelles pour la simulation numérique, toutcomme dans la simulation des systèmes experts ou les systèmes de simulation qualitative.A titre indicatif, dans le domaine militaire, la simulation basée sur les agents est utilisée pourmodéliser le comportement humain lors d’un conflit, d’une évacuation dans le cas d’unesituation de crise.

21 Ang. Agent-Directed Simulation (ADS)22 Ang. Agent simulation (AS)23 Agent-based simulation (ABS)


47




Simulation supportée par les agents : la simulation supportée par les agents24 est lefait d’utiliser des agents dans la simulation des opérations de soutien qui peuvent être desopérations d’interface front-end ou back-end [Ören et al., 2000]. Ce type de simulationest très utilisé par les militaires pour décrire des scénarios, représenter ou analyser desmenaces, représenter le champ de bataille ou de façon plus générale l’environnement,évaluer les capacités à comprendre, visualiser l’influence de l’information sur les décisionsen situation de combat, etc.

Bien que la simulation orientée agent couvre maintenant plusieurs domaines etsemble, du moins théoriquement, être d’une grande utilité pour la simulation des systèmescomplexes, il est toujours légitime de se demander si en pratique les projets qui utilisent lasimulation orientée agent bénéficient vraiment des avantages de cette technique.

2.8. ConclusionCe chapitre nous a permis de mettre le point sur les systèmes multi-agent. Nous avonsprésenté les grands concepts qui définissent le domaine, les méthodologies et les plates-formes de développement de SMA ainsi que la simulation multi-agent. Deux choiximportants ont été défendus dans ce chapitre et constituent les briques de base deschapitres suivants. Le premier choix concerne le langage AUML qui sera utilisé pour laphase de modélisation (cf. chapitre 3). Le deuxième choix concerne la plate-forme JADEqui sera utilisée dans la phase d’implémentation (cf. chapitre 4).

24 Agent-supported simulation (ASS)


48




Chapitre 3 : Architecture Distribuéeà base d’Agents pour la SimulationProactive et l’Aide à la Décision dans laChaîne Logistique

3.1. IntroductionDans le chapitre 1, on a présenté plusieurs travaux liés à la modélisation des chaîneslogistiques par des SMA. On a montré aussi que chaque modèle traite un problème précis.De notre part, dans ce chapitre nous allons proposer notre modèle quasi-générique quiconvient à un grand nombre de chaînes logistiques ou groupements d’entreprises. Cemodèle à base d’agents pourra être configuré selon la chaîne logistique étudiée et letype de collaboration à mettre en place. La spécificité de notre modèle est qu’il traiteles situations d’urgences. Par exemple, une situation de planification opérationnelle (courtterme: commande urgente [Lopez et al., 2001] [Pinedo et Chao, 1999], commande nonprévue, etc.) ou bien une exception (problème de production, problème de transport, erreursur prévision, etc.) conduisant à une négociation pour modifier la quantité commandée, ladate de livraison, etc.

Tout d’abord, on présente notre approche méthodologique à suivre afin de délimiterla structure et le périmètre de la CL à modéliser, ceci nous mène à identifier les agentsnécessaires et représenter une vue statique de notre système. Ensuite nous proposonset nous modélisons avec AUML quelques protocoles de négociation et d’échanges utiliséspar les agents de notre architecture. Puis nous modélisons le comportement de chaqueagent par un diagramme d’états-transitions AUML. Enfin, nous concluons en présentantnotre contribution à la modélisation d’une CL et aux protocoles de négociation entre agents.

3.2. Cas d’utilisation de l’architecture proposéeRappelons que le but principal de cette thèse est de développer une architecture distribuéeà base de système multi-agent pour l’aide à la prise de décision collaborative dans lecontexte de la chaîne logistique. Nous avons identifié deux principaux cas d’utilisationdes agents composant cette architecture. Le premier cas d’utilisation consiste à demanderaux agents d’effectuer une initialisation avec les données réelles auprès des systèmesd’informations des acteurs et de lancer une simulation afin de connaître les tendancesdes états futurs des acteurs de la CL lors de la présence d’une exception. L'objectifmajeur est de pouvoir propager l'impact d'une nouvelle donnée sur l'ensemble de la chaînelogistique lorsqu'un aléa survient. Ceci nécessite d’avoir un modèle performant qui reproduitle fonctionnement des différents processus (approvisionnement, production, achat, gestionde stock, etc.) de chaque entité. Or, réellement, chaque processus est géré par des êtres

Chapitre 3 : Architecture Distribuée à base d’Agents pour la Simulation Proactive et l’Aide à laDécision dans la Chaîne Logistique

49




humains en se servant d’outils informatiques. Par conséquent, notre modèle à base d’agentsdoit être capable de représenter les différentes actions effectuées par les managers etles outils informatiques utilisés. A titre d’exemple, le manager choisit le jour pour passerune commande d’approvisionnent et en se basant sur les prévisions fournies par un outilinformatique, il pourra établir un plan de production.

Le deuxième cas d’utilisation consiste à demander aux agents d’interface de chercherles informations nécessaires auprès des systèmes d’information des différents acteurs, puisfaire des négociations automatisées (tout en garantissant l’autonomie et la confidentialitédes données stratégiques dans le cas où il s’agit d’acteurs indépendants ou concurrents)pour le compte des décideurs afin de proposer des solutions aidant à prendre une décisionadéquate. Ceci est utile lors de la présence d’une commande incertaine, d’une commandeimprécise ou d’une exception (problème de production, problème de transport, erreur surprévisions, retard de livraison, etc.). Pour ce cas d’utilisation, les agents doivent implémenterdes protocoles de négociation et reproduire les techniques utilisées par les managers. Donc,dans ce cas, il s’agit de modéliser sous forme de règles, les connaissances des décideurset des mangers.

3.3. Approche méthodologiqueDeux données sont importantes dans le processus de modélisation d’une chaîne logistique,le périmètre et la structure. Le premier délimite la chaîne en nombre d’acteurs et le deuxièmedéfinit les relations clients/fournisseurs. En l’absence de ces deux paramètres, il est difficilede délimiter les frontières de la modélisation (en terme de niveaux). En effet, une chaînelogistique peut faire intervenir plusieurs dizaines, voire centaines d’installations (entreprise,usine, entrepôt, fournisseur de logistique, client, marché, etc.) réparties sur toute la planète(figure 3.1 [Colin, 2003]). Alors, est-il vraiment nécessaire de prendre en considération tousles acteurs (installations) ? En outre, une installation peut faire partie de plusieurs chaîneslogistiques, alors, quels sont les niveaux de clients et de fournisseurs que doit couvrir lemodèle proposé ?


50




Fig. 3.1 - Chaînes logistiques inter-reliéesPour répondre à ces deux questions, il est nécessaire d’identifier le produit pour lequel

est défini la CL. En effet, on définit une CL pour un produit ou une famille de produitdonné. Elle représente l’ensemble des entreprises, fournisseurs, clients, distributeurs quiinterviennent dans le processus de fabrication, de distribution et de vente de ce produit[Rota, 1998]. Connaissant le produit, nous précisons clairement l’entreprise centrale dela CL, c’est-à-dire celle qui assemble le produit final. Suite à cela, nous déterminons sesclients, ses fournisseurs, les clients de ses clients, les fournisseurs de ses fournisseurs,et ainsi de suite jusqu’aux clients les plus en aval et les fournisseurs les plus en amont.Ci-dessous, nous proposons une approche méthodologique de 11 étapes [Nfaoui et al.,2006] permettant de délimiter les frontières de modélisation et définir les relations clients/fournisseurs :

Le produit :1. Identifier le produit fini pour lequel est définie la CL. Ceci définit automatiquement

l’entreprise centrale « EC » de la CL.2. Identifier la nomenclature du produit fini.3. Exclure de cette nomenclature les matières premières ne nécessitant pas un

partenariat ou une collaboration.

Fournisseurs :1. Identifier ensuite les fournisseurs (distributeurs ou usines possédant l’activité de

production) des matières premières restantes. La même matière première peut être


51




achetée chez un ou plusieurs fournisseurs différents. Dans ce dernier cas, déterminerle pourcentage des commandes à passer à chacun d’eux.

2. Pour chaque fournisseur, refaire les étapes 2, 3 et 4 en considérant cette fois, lamatière première comme un produit fini, et ainsi de suite jusqu’au fournisseur le plusen amont.

3. Déterminer le type des demandes (stationnaire, aléatoire, etc.) des clients autres quel’entreprise centrale « EC » des différents fournisseurs identifiés dans l’étape 4.

4. Refaire l’étape 6 pour les fournisseurs des fournisseurs à l’exception des derniersfournisseurs (fournisseurs les plus en amont).

Clients :1. Identifier la liste des clients de l’entreprise centrale « EC ».2. Dans cette liste, identifier les clients potentiels agissant sur la CL du produit (clients

nécessitant une collaboration ou un partenariat) et ceux qui ne l’ont pas. Déterminerensuite le type des demandes de ces derniers (aléatoire, stationnaire, etc.) ainsique le pourcentage des commandes que passe chaque client potentiel à l’entreprisecentrale « EC ».

3. Pour chaque client potentiel de l’entreprise centrale « EC », refaire les étapes 8 et 9 àl’exception des clients finaux (par exemple, les consommateurs).

Modèle à base de système multi-agent :1. Attribuer un modèle à base d’agents (cf. sections ci-dessous) à tous les acteurs

identifiés (entreprise centrale, clients et fournisseurs).

Afin d’illustrer cette approche, nous étudions un exemple. La figure 3.2 illustre une entreprisecentrale « EC » (représentée par une ellipse), ses clients (représentés par des cercles) etses fournisseurs (représentés par des carrés) sur plusieurs niveaux (deux niveaux de clientsimpliquent un client direct et ses clients).

Fig. 3.2 - Structure de la chaîne logistique à modéliser


52




Fig. 3.3 - Nomenclature du produit fini PFSupposons que l’entreprise centrale « EC » fabrique le produit fini « PF » possédant

la nomenclature arborescente de la figure 3.3. Une unité du produit fini « PF » nécessitela quantité qs1 du composant intermédiaire « S1 » (constitué respectivement des quantitésq1 et q2 des matières premières « MP1 » et « MP2 »), et les quantités q3, q4 et q5 desmatières premières « MP3 », « MP4 » et « MP5 ». Ces matières premières sont à acheterrespectivement chez les fournisseurs F1, F2, F3, F4 et F5 (la même matière premièrepeut être achetée chez un ou plusieurs fournisseurs différents). Dans ce manuscrit, le mot« matière première » désigne toute matière achetée à l’extérieur de l’entreprise, elle peutêtre une matière première, un composant ou un produit semi-fini.

Certaines matières premières (comme « MP5 » dans notre exemple) ne nécessitentpas une collaboration interentreprises. Elles seront donc exclues du modèle. C’est le caspar exemple des matières premières dont la consommation est très régulière et qui peuventêtre approvisionnées dans des délais courts. Ainsi, à titre d’exemple, dans le cas descomposants de montage d’un téléviseur, les flux des tubes cathodiques et des écrans sontsynchronisés avec précision en fonction du plan de montage quotidien et nécessitent unecollaboration interentreprises. En revanche, les vis de fixation ou les emballages en cartonne le nécessitent pas.

Ce qui vient d’être dit pour le produit fini « PF » fabriqué par l’entreprise centrale « EC »,reste valable pour les matières premières « MP1 », « MP2 », « MP3 » et « MP 4» qui sont enfait des produits fabriqués ou distribués respectivement par les entreprises « F1 », « F2 »,« F3 » et « F4 ». Nous suivons la même logique de raisonnement pour les fournisseurs desfournisseurs jusqu’au dernier niveau. Dans le cas d’un distributeur (entreprise ne possédantpas l’activité de production), le produit fini distribué représente la matière première achetée.

L’entreprise centrale « EC » fournit le produit fini « PF » à ses clients « C1 », « C2 »,« C3 » et « C4 ». Parmi eux, nous trouvons des clients (comme C4 représenté par un cercleen pointillé) qui viennent s’approvisionner de temps en temps comme les détaillants et lesgrossistes situés dans la même région que l’entreprise centrale « EC » et qui ne sont pasimpliqués réellement dans une collaboration ou un partenariat. En conséquence, seulesleurs demandes sont prises en compte (par exemple, demandes stationnaires, demandesaléatoires, etc.). Ceci reste valable aussi pour quelques clients des clients, comme c’est lecas pour le client « CC14 » du client « C1 ».

Les clients (représentés par des cercles en pointillé pour F1) n’interviennent pasdirectement dans la SC du produit fini « PF », de ce fait, seules leurs demandes serontprises en compte. De même pour les fournisseurs des clients (comme FC11 et FC12 pourC1) qui ne seront pas modélisés.


53




3.4. Architecture du systèmeDans cette section, nous allons décrire la vue statique de notre système.

3.4.1. Identification des agents et leurs rôlesLes degrés d’autonomie, de capacité à coopérer et d’apprentissage diffèrent d’un agent àun autre, selon le domaine d’application. Ces différences font dévoiler plusieurs typologiesd’agents dédiés aux applications qui tournent autour de la CL [Chehbi, 2007]. Selon le mêmeauteur, nous distinguons donc :

∙ Des agents d’interface, autonomes et capable d’apprendre comme dans [Maes,1995].

∙ Des agents collaboratifs, autonomes et capable de coopérer [Slimani, 2006].∙ Des agents collaboratifs apprenants, capables de coopérer et d’apprendre tels que

les agents de [Sandip, 2002].∙ Des agents intelligents intégrant les caractéristiques de tous les autres types. Ils

sont autonomes, aptes à coopérer et à apprendre à partir de leur environnement, lesagents SATELIT-Agent dans [Akoulchina et Ganascia, 1998].

R. Charton [Charton, 2003] a classé les typologies d’agents d’applications comme montréesà la figure 3.4.

Fig. 3.4 - Typologies des agents selonQuand à notre architecture, nous comptons programmer des agents d’interface

intelligents afin qu’ils aident les décideurs à prendre une décision. Pour identifier le nombre


54




des agents et leurs rôles, nous nous basons sur le niveau 1 du modèle ‘SCOR’ (SupplyChain Operations Reference model) que nous avons présenté au chapitre 1 (cf. section 1.2).Le niveau 1 permet, sur la base des fonctions élémentaires (approvisionner, faire, délivrer,planifier et retourner), de modéliser le périmètre de la chaîne logistique que l’on souhaiteétudier. Le travail s’effectue ici avec une vision très macroscopique. Nous rejoignons donc R.Govindu et R.B. Chinnam, dans leur proposition intitulée MASCF (Multi-Agent Supply ChainFramework) [Govindu et Chinnam, 2007]. MASCF est un outil qui offre une méthodologiegénérique conçue pour faciliter et simplifier les phases d'analyse et de conception desapplications basées sur les SMA dans les CL. Il adopte le modèle standard ‘SCOR’ pourla description de la CL.

Nous avons choisi d’attribuer 4 agents pour chaque acteur identifié de la CL (cf. section3.3). Le tableau 3.1 présente les noms et les rôles de ces agents.

Tab. 3.1 : Agents du système

Nom de l’agent RôlesApp Agent interface intelligent lié au processus approvisionnement

et achat. Cet agent se connecte au module ERP gérant lesinformations concernant le stock de fabrication (stock de matièrespremières, de composants et de produits semi finis).

Fab Agent interface intelligent lié au processus de fabrication(production).

Liv Agent interface intelligent lié au processus de livraison et auprocessus relatifs aux clients. Cet agent se connecte au ModuleERP qui gère les informations concernant les commandes desclients et le stock de distribution (stock de produits fins).

AgentSCM Agent interface intelligent lié aux pratiques et techniques misesen œuvre par les acteurs pour piloter et gérer leur CL. Elles sontconnues sous le terme "Supply Chain Management ".

Remarque : Dans le cas d’un acteur de type distributeur, l’activité de productionn’existe pas. Par conséquent, cet acteur sera représenté et modélisé seulement par lestrois agents : App, Liv et AgentSCM.

Chacun de ces agents, cherche à coopérer avec les autres pour augmenter le nombrede scénarios possibles devant une situation d’urgence. Nos agents seront aussi capablesde s’adapter et d’apprendre de leur environnement, en particulier, ils collectent les stratégieschez les managers et les décideurs, cherchent les données nécessaires et précises et visentà construire une base de règles afin de bien coordonner les décisions. En conséquence,nos agents sont donc ‘intelligents’.

En ce qui concerne la réactivité et la cognition, nos agents auront des stimuli réactifs(transfert de messages, calcul de coût suite à la réception d’un message) ainsi que desstratégies de décisions.

Les comportements des agents sont encapsulés directement dans les agents sansles encapsuler dans les rôles. Nous montrerons dans le chapitre 4 que la plate-forme dedéveloppement JADE est très adaptée à ce choix, et simplifie ainsi l’implémentation.


55




Fig. 3.5 (a) - Agents interface intelligents d’un acteur

Fig. 3.5 (b) - Architecture distribuée de simulation et d’aide à la décision


56




3.4.2. Structure statique du systèmeHuget [Huget, 2002a] a proposé une extension des diagrammes de classes UML afin deprendre en compte les caractéristiques des agents. AUML permet de représenter plusieursniveaux d’abstraction lors de la conception des diagrammes de classes. Deux niveauxd’abstraction sont couramment utilisés : Le niveau conceptuel et le niveau implémentation.Le niveau conceptuel est une vue assez haute du système multi-agent éliminant toutes lesinformations qui sont superficielles pour comprendre la structure du système : les attributs,les opérations, les rôles, etc. Le niveau implémentation donne en détail le contenu desagents. Nous présentons ci-dessous le diagramme de classe niveau implémentation dechaque agent.

Dans notre architecture, chacun des agents présentés dans le tableau 3.1 possède lesattributs suivants:

∙ Id : une identification∙ Nom∙ Loc : localisation

Ces attributs sont appelés ‘des contraintes systèmes’ comme spécifié dans la modélisationAUML.

3.4.2.1. Agent « App » Comme c’est montré sur le tableau 3.1 (cf. section 3.4.1), l’agent « App » est lié au processusd’approvisionnement en matières premières. En conséquence, parmi ses opérations, ontrouve :

∙ mettre_A_Jour_Plan_Appro() : cette opération permet de mettre à jour le pland’approvisionnement en cas de modification.

∙ mettre_A_Jour_Stock_Appro() : cette opération permet de mettre à jour le stockd’approvisionnement lors de la réception des matières premières.

∙ passer_commande() : cette méthode permet de passer une commande caractériséepar une quantité et un délai de livraison à l’agent « Liv » d’un autre acteur.

L’agent « App » utilise des protocoles de négociation afin de négocier les commandespassées, les scénarios possibles en cas d’aléa, etc. Dans ce cadre, on a proposé plusieursprotocoles de négociation afin d’augmenter le nombre de scénarios possibles. On trouveparmi ces protocoles :

∙ Négociation_Heuristique,


57




∙ Négociation_Heuristique_Ferme,∙ Négociation_Heuristique_Recursive.

Ces protocoles seront présentés et étudiés en détail dans la section 3.5 du même chapitre.La figure 3.6 montre le diagramme de classe niveau implémentation de l’agent « App ».

Ce diagramme sera complété par d’autres informations dans le chapitre 4.

Fig. 3.6 - Le niveau implémentation pour l’agent « App »L’agent « App » passe d’un état donné à un autre en fonction des actions se produisant

dans l’environnement ou en fonction des messages reçus. Son comportement est modélisépar le diagramme d’états-transitions (App_Behavior) de la figure 3.18 (section 3.6.3) dumême chapitre.

L’agent « App » gère entre autres, plusieurs données relatives aux matières premièresconstituant le produit fini fabriqué par l’entreprise. En effet, la fabrication du produit fininécessite plusieurs matières premières ou produits semi fini. Le stock de chaque matièrepremière (appelé aussi stock de fabrication) peut être géré par une méthode de gestionde stock. Le management industriel et logistique connaît plusieurs systèmes et politiquesde gestion de stock. Elles dépendent de la durée de vie des articles (pouvant être longueou courte) et du type du processus de la demande. Cette dernière peut être globalementconstante (on parle dans ce cas de demande stationnaire) ou au contraire présenter desévolutions importantes au cours du temps, on parlera alors de demande non-stationnaire.De plus, il est possible qu’une part de la demande présente un caractère aléatoire, qui larend difficile à quantifier à l’avance. On parle alors de demande aléatoire. Les principes desdeux systèmes de gestion de stock les plus fréquents sont :


58




∙ si la commande survient lorsqu’un stock minimum est atteint, on approvisionnetoujours la même quantité, il s’agit alors d’un système à quantité fixe et à périodicitévariable ;

∙ si la passation de commande a lieu à périodicité fixe, on approvisionne des quantitésdifférentes d’une commande à la suivante (typiquement on approvisionne à chaquefois ce qui a été consommé depuis la dernière commande passée, pour ramener leniveau du stock vers un niveau cible). On a là un système à périodicité fixe et quantitévariable.

Il existe des variantes de ces deux systèmes de base. On distingue entre autres, le systèmeà point de commande périodique, le système à re-complètement périodique avec seuil et lessystèmes mixtes. L’annexe C présente plus de détails sur les systèmes de gestion de stock.

Le tableau 3.2 montre quelques données gérées par l’agent « App ».

Tab. 3.2 : Partie des données gérées par l’agent « App ».

Donnée DescriptionnumMatPrem Numéro de la matière première qui entre dans la constitution

du produit fini. On a déjà précisé dans la section 3.3 qu’onprend en compte juste les matières premières potentiellesnécessitant une collaboration ou un partenariat.

nomMatPrem Nom de la matière première.qmp Quantité de la matière première nécessaire à la fabrication

d’une unité du produit fini.qf Quantité fixe à commander.pc Point de commande.nr Niveau de recomplètement.pr Période de révision.nomSGS Nom de la méthode utilisée pour gérer le stock d’une

matière première. Par exemple : système à point decommande, système à re-complètement périodique, etc.

pg Pourcentage des commandes à passer au fournisseur.ca Cycle d’approvisionnement.nomAgentLiv Nom de l’agent « Liv » du fournisseur qui livre la matière

première.

3.4.2.2. Agent « Fab » L’agent « Fab » est lié au macro-processus ‘Fabrication’ de l’entreprise. Dans le cas d’undistributeur, cet agent n’existe pas. En plus des attributs id, nom et loc, cet agent gère desdonnées techniques relatives à la fabrication d’un produit fini comme par exemple le cyclede production d’une unité de produit fini et la capacité de production. Parmi ses opérations,on trouve notamment :

∙ mettre_A_Jour_Prog_Pro ( ) : cette méthode permet la mise à jour du programme deproduction en cas de modification.

∙ annuler_Demande_Pro ( ) : elle permet d’annuler une demande de production encours d’étude ou déjà commencée.

L’agent « Fab » passe d’un état donné à un autre en fonction des actions se produisant dansl’environnement (par exemple : une perturbation) ou en fonction des messages provenant


59




des agents « App » et « Liv » du même acteur. Son comportement est modélisé par lediagramme d’états-transitions (Fab_Behavior) de la figure 3.17 (section 3.6.3).

La figure 3.7 montre le diagramme de classe niveau implémentation de l’agent « Fab ».

Fig. 3.7 - Le niveau implémentation pour l’agent « Fab »

3.4.2.3. Agent « Liv » L’agent « Liv » est l’agent interface lié au processus de livraison et au processus relatifsaux clients. En particulier, il est lié à la gestion des commandes des clients et le stock dedistribution (stock de produits fins). En ce qui concerne le stock des produits finis (appeléaussi stock de distribution), l’agent gère entre autres les informations suivantes pour chaqueproduit fini fabriqué par l’entreprise :

∙ cp : capacité de stock∙ sgs : système (ou méthode) de gestion du stock de livraison.∙ qf : quantité fixe à commander.∙ pc : point de commande,∙ nr : niveau de re-complètement,∙ pr : période de révision.∙ une fiche de stock composé des données suivantes : en : entrée, so : sortie, sp :

stock physique, com : quantité commandée, sd : stock disponible.

L’agent « Liv » reçoit des commandes envoyées par les agents « App » des autres acteurs.Chaque commande possède deux principaux paramètres :

∙ quantité commandée,∙ délai de livraison.


60




Chacun de ces deux paramètres peut être modifiable ou non (possibilité d’avoir unenégociation). Cela correspond à la possibilité de modifier ou non la valeur de l’attribut dansune contre-proposition. Par exemple, la quantité commandée peut être livrée intégralementou par partie. Ceci influe sur la décision à prendre par l’agent.

La figure 3.8 montre le diagramme de classe de l’agent « Liv ». Il utilise des protocolesde négociation afin de négocier les commandes passées, les scénarios possibles en casd’aléa, etc. Ces protocoles seront présentés en détail dans la section 3.5.2 du mêmechapitre. L’agent « Liv » passe d’un état donné à un autre en fonction des actions seproduisant dans l’environnement ou en fonction des messages reçus. Son comportementest modélisé par le diagramme d’états-transitions (Liv_Behavior) de la figure 3.16 (section3.6.3).

Fig. 3.8 - Le niveau implémentation pour l’agent « Liv »

3.4.2.4. Agent « AgentSCM »La figure 3.9 présente le niveau implémentation de l’agent « AgentSCM ». Cet agentencapsule toutes les pratiques et techniques mises en œuvre par les acteurs pour piloteret gérer leur CL. Elles sont connues sous le terme ‘Supply Chain Management’. Ontrouve par exemple le processus collaboratif CPFR qu’on a présenté dans le chapitre 1(cf. section 1.4.2 (c)). L’agent « AgentSCM » utilise plusieurs protocoles pour négocieravec ses partenaires d’autres acteurs. Certains de ces protocoles seront traités dansla section 3.5.2 du même chapitre et d’autres seront présentés dans le chapitre 5. Lecomportement de l’agent « AgentSCM » est modélisé par le diagramme d’états-transistions(AgentSCM_Behavior) de la figure 3.19 (section 3.6.3).


61




Fig. 3.9 - Le niveau implémentation pour l’agent « AgentSCM »

3.5. Modèles pour l’aide à la décision

3.5.1. Processus décisionnels des agentsLa décision est souvent vue comme le fait d’un individu isolé (le décideur) exerçant un choixentre plusieurs possibilités d’actions à un moment donné. Comme le définit Roy dans [Roy,2000] ‘Aider à décider, c’est tout d’abord aider à clarifier la formulation, la transformationet l’argumentation des préférences. A ce niveau, le concept clé est celui du critère’. En sebasant sur cette définition et d’autres, nous déduisons que ‘préférences’ et ‘critères’ sont lesdeux mots clés essentiels dans la conception du processus décisionnel. Nous avons doncétudié la décision des agents de la CL selon les critères pris en compte et les préférencesde leurs choix. Nous nous sommes basés sur le fait que les agents de notre architecturesont coopératifs de sorte qu’ils cherchent un but global : trouver un scénario acceptable pourrésoudre une situation d’urgence. Voici quelques types de décision utilisés par les agentsde notre architecture :


62




∙ Décision par stratégie : l’agent interface de chaque processus agit selon une stratégiechoisie dans sa base de règles. Cette base est configurée au préalable par lesmanagers de ce processus et mise à jour par les stratégies apprises par l’agentà partir de l’historique des décisions validées et prises par les décideurs pendantles situations d’urgence. Ainsi les agents sont capables de proposer des décisionsde type tactique (planifier la production, planifier les prévisions de vente, etc.) etopérationnel (approvisionner, livrer, choisir sa stratégie de stockage, etc.).

∙ Décision par calcul des coûts : la décision de l’agent est fondée sur une rationalitécomplète, il doit chercher les informations (coûts), prendre en considération lesdifférentes contraintes (capacités de stockage, distances géographiques, capacité deproduction, commandes des clients, etc.) pour minimiser le coût global de la chaîne.

∙ Décision par négociation : la négociation est considérée comme cas particulierdes approches non fondées sur la rationalité complète. L’agent constitue et déduitdynamiquement la décision à partir des propositions des autres agents. Notrearchitecture supporte ce type de décision. Nous détaillons les protocoles denégociation dans la section suivante.

Les trois types de décision précédents sont utilisés et exploités dans les deux cas d’étudetraités dans le chapitre 5.

3.5.2. Protocoles de négociation La négociation est le mécanisme par lequel les agents peuvent arriver à un accord commun.Dans le cas des agents intelligents et des SMA, La négociation est une composante debase de l’interaction et cela parce que les agents sont autonomes [Jennings, 2001] ; il n’ya pas de solution imposée à l’avance et les agents doivent arriver à trouver des solutionsdynamiquement, pendant qu’ils résolvent les problèmes. Pour modéliser la négociationentre les agents composant notre système, nous avons pris en compte les aspects suivants :

∙ L’objet de négociation : un objet abstrait qui comprend les attributs que les agentsveulent négocier. Dans notre architecture, plusieurs objets sont sujets à négocierselon la situation. Nous trouvons entre autres, le scénario acceptable en cas d’aléas,la commande avec ses attributs quantité et date de livraison, les prévisions avec leursattributs quantité, date et exception.

∙ Le processus de décision : le modèle que l'agent utilise pour prendre des décisionspendant la négociation. La partie la plus importante de la prise des décisions dansce cas est la stratégie de négociation qui permet de déterminer quelle primitive denégociation l'agent doit choisir à un certain moment.

∙ Le langage de communication : le langage utilisé par les agents pour échangerdes informations pendant la négociation. Dans notre architecture, les agentscommuniquent à l’aide du langage FIPA-ACL [FIPA, 2002a], il s’agit du langagestandard utilisé par l’environnement JADE [Bellifemine et al., 1999] que nous avonsutilisé pour développer notre architecture (cf. chapitre 4).

∙ Le protocole de négociation définissant l'ensemble des règles qui régit lanégociation : Les participants possibles à la négociation, les propositions légalesque les participants peuvent faire, les états de la négociation et enfin une règle pourdéterminer quand on est arrivé à un accord ou quand il faut s'arrêter parce qu'aucunaccord n'a pas pu être trouvé.


63




Dans le contexte du supply chain management, les agents sont coopératifs, ayant le mêmebut (agrégation des objectifs locaux), partagent et résolvent ensemble des problèmes. Pourcette raison, ils doivent fournir des réactions plus utiles aux propositions qu’ils reçoivent. Cesréactions peuvent prendre la forme d’une critique ou d’une contre-proposition (propositionrefusée ou modifiée). Une critique est un commentaire sur la partie de la propositionque l’agent accepte ou refuse. Une contre-proposition est une proposition alternativeengendrée en réponse à une proposition. A partir de telles réactions, l’agent doit êtrecapable d’engendrer une proposition qui est probablement plus apte à mener à un accord.En conséquence, les agents de notre système doivent utiliser des protocoles respectant lescritères qui viennent d’être énoncés et dépendant essentiellement de trois paramètres :

∙ Le secteur d’activité de la CL (industrie de textile et habillement, industrie des biensde consommation, etc.).

∙ Méthodes et approches SCM utilisées pour la coopération et la coordination.∙ Objet à négocier : commande urgente, commande incertaine, commande normale,

prévisions de ventes, prévisions de commandes, plan de livraison en cas d’aléas, etc.

Nous proposons un ensemble de protocoles de négociation entre agents propres à lachaîne logistique [Nfaoui et al., 2008b] : Le protocole de négociation heuristique, le protocolede négociation heuristique ferme, le protocole de négociation heuristique récursive et lesprotocoles correspondant aux différentes méthodes et pratiques SCM (comme : le CPFR-Collaborative Planning, Forecasting and Replenishment-, le Transshipment, etc.). Nousmodéliserons chacun d’eux à l’aide d’un diagramme de séquence AUML [Huget et Odell,2004].

3.5.2.1. Diagramme de séquenceUn diagramme n’est pas un modèle mais une représentation graphique de quelqueséléments du modèle. Les diagrammes constituent l’expression visuelle et graphique. Ilexiste plusieurs types de diagrammes dynamiques dans AUML : les diagrammes dedéploiement, de collaboration, de séquences, de cas d’utilisation, d’états-transitions etd’activités. Un diagramme ne montre pas toutes les informations, plusieurs diagrammessont nécessaires pour illustrer le modèle complet. C’est pourquoi plusieurs diagrammessont nécessaires pour donner une description dynamique complète de l’agent. Nous avonsretenus le diagramme de séquence pour modéliser les interactions entre les différentsagents, en particulier, les protocoles de négociation. Plusieurs protocoles standard denégociation ont été modélisés par le diagramme de séquence comme FIPA RequestProtocol, FIPA Contract Net Protocol, FIPA English Auction Protocol [FIPA, 2003].

Un diagramme de séquence est en deux dimensions : l’axe vertical correspond autemps tandis que l’axe horizontal recense les agents participants aux interactions. Pourreprésenter la création ou la destruction d’un agent sur un diagramme de séquence, il fautdémarrer ou arrêter sa ligne de vie aux points appropriés, dans les autres cas de figure,la ligne de vie est représentée de haut en bas du diagramme. Ils doivent être clairs pourfaciliter la communication. Les détails non pertinents doivent être évités. Un diagramme deséquence montre les interactions entre agents (ou rôles) sous la forme de séquences dansle temps. En particulier, il montre les agents participants à l’interaction par leur ‘ligne de vie’et les messages qu’ils échangent ordonnancés dans le temps.

3.5.2.2. Négociation heuristique


64




La négociation heuristique est montrée dans la figure 3.10 [Florea, 2002]. Dans ce protocole,plusieurs propositions et contre-propositions peuvent être échangées dans les différentesétapes afin d’arriver à un accord. L'agent A, avec la proposition pA, est l'initiateur de lanégociation, alors que l'agent B (participant) peut répondre avec les réponses p1B, p2B, p3B(to Modify Request). Le nombre des contre-propositions est limité. Une fois que cette limiteest atteinte, les agents arrivent à un rejet. Nous proposons de récapituler le fonctionnementdu protocole de négociation heuristique à l’aide d’un digramme de séquence AUML (figure3.11).

Fig. 3.10 - Négociation heuristique


65




Fig. 3.11 - Négociation heuristique

3.5.2.3. Proposition d’une négociation heuristique fermeDans certaines situations de négociation, les agents coopératifs sont obligés d’arriver àun accord. C’est le cas par exemple de deux agents « AgentSCM » d’acteurs différentscollaborant sur les prévisions de ventes. Pour cela, la négociation heuristique étudiée dansla section précédente (cf. figure 3.11) doit comporter seulement les primitives ACCEPT-PROPOSAL ou PROPOSE sans inclure la performative REFUSE. Ainsi, nous proposonsle protocole de négociation heuristique ferme qui est un cas particulier de la négociationheuristique. Le nom « ferme » qualifie ce protocole puisqu’il mène toujours à un accord.Lafigure 3.12 montre le diagramme de séquence AUML décrivant ce protocole.


66




Fig. 3.12 - Négociation heuristique ferme

3.5.2.4. Proposition d’une négociation heuristique récursiveLe protocole de négociation heuristique récursive que l’on propose se déroule au moinsentre trois agents, l’agent initiateur de la négociation, l’agent destinataire qui pourra êtrel’initiateur d’une nouvelle négociation heuristique avec le troisième agent. D’où le nom« récursive » qualifiant cette heuristique. La figure 3.13 montre le diagramme de séquenceAUML correspondant.

Dans notre architecture de simulation, les agents utilisent le protocole de négociationheuristique récursive afin de négocier une commande urgente, une commande incertaineou le scénario à adopter en cas d’aléas. Ce protocole peut aussi être utilisé à l’intérieur d’unprotocole correspondant à une pratique ou une démarche SCM. Dans le cas général, il sedéroule de la manière suivante :

∙ L’agent initiateur de la négociation envoie des messages (pas nécessairementidentiques) de performative « PROPOSE » à tous les agents directs (amont et/ouaval) qu’il croit candidats à une négociation. Ainsi, il lance plusieurs négociationsindépendantes. Il n’attend pas toutes les réponses pour prendre une décision. Deplus, selon la situation et l’intervalle de temps dont il dispose, il peut chercher lameilleure solution en créant de nouvelles propositions déduites des réponses reçues ;

∙ Puisque les agents de notre architecture sont coopératifs, chacun d’eux recevant unmessage peut à son tour initier une négociation si nécessaire entre les agents setrouvant en amont et en aval afin de trouver une solution, d’où le nom « récursive »qualifiant cette heuristique.


67




Fig. 3.13 - Négociation heuristique récursive

3.5.2.5. Protocole de négociation CPFRLe CPFR (Collaborative Planning, Forecasting and Replenishment) présenté dans lechapitre 1 (cf. section 1.4.2 (c)) est un processus collaboratif mis en place entre lesentreprises qui prend en compte toute la chaîne logistique. Il s’agit d’une méthode degestion globale de l’offre et de la demande qui améliore le VMI (Vendor Managed Inventory)et le CRP (Continuous Replenishment Program) [Simchi-Levi et al., 2000]. Le protocolede négociation CPFR entre un fournisseur et un distributeur se déroule selon les étapessuivantes :

∙ La négociation débute entre les deux agents « AgentSCM » du distributeur et sonfournisseur dès que l’un d’eux crée des prévisions de ventes et en informe l’autre.

∙ L’agent destinataire consulte et analyse ces prévisions, ensuite il envoi un messagede confirmation à l’émetteur ou bien initie une négociation heuristique ferme avec luis’il n’est pas d’accord afin de modifier ces prévisions. Dans tout les cas, l’émetteur


68




et le destinataire doivent se mettre d’accord sur des prévisions de ventes puis lespartager.

∙ Chacun des deux peut être l’auteur d’une négociation heuristique qui résout uneexception (changements et mises à jour) sur les prévisions de ventes créées. Cettenégociation heuristique entre les deux agents est sujette à devenir récursive pourimpliquer d’autres agents pouvant aider à la résolution. La négociation se terminelorsque toutes les exceptions sont résolues ou le délai fixé dynamiquement est expiré.

∙ L’agent « AgentSCM » du distributeur envoi un message de performative« INFORM » à l’agent « AgentSCM » de son fournisseur contenant des informationssur le niveau de ses stocks (quantités en commandes, en stock...).

∙ L’agent « AgentSCM » du fournisseur répond aussi par un message de type« INFORM » indiquant sa capacité de production, l’historique de sa production, deses lead times…

∙ A ce stade, la négociation concernant les prévisions de ventes est terminée. Unenouvelle négociation débute entre les deux agents dès que l’un d’eux crée desprévisions de commandes et en informe l’autre.

∙ Chacun des deux peut être l’auteur d’une négociation heuristique qui résout uneexception sur les prévisions de commandes créées. Cette négociation heuristiqueest sujette à devenir récursive pour impliquer d’autres agents pouvant aider à larésolution. La négociation se termine lorsque toutes les exceptions sont résolues oule délai fixé dynamiquement est expiré.

∙ Enfin, selon la situation, l’un d’eux transforme la prévision d’une commande en unengagement d’une commande ferme, puis en informe immédiatement l’autre.

La figure 3.14 illustre le diagramme de séquence AUML correspondant lorsque lefournisseur s’occupe de la création des prévisions de ventes et les commandes certaines.


69




Fig. 3.14 - Protocole de négociation CPFRAprès avoir traité le modèle décisionnel des agents et les protocoles de négociation,

nous passons à l’étude de leurs comportements que nous modéliserons à l’aide desdiagrammes d’états-transistions AUML.

3.6. Modélisation des comportements des agents

3.6.1. IntroductionLes sections précédentes ont conduit à l’énumération des agents constituant le systèmeet la modélisation de quelques protocoles de négociation. Dans cette section, nousmodélisons le comportement de chaque agent par un diagramme d’états-transitions AUML.Les agents passent d’un état donné à un autre en fonction des actions se produisant dans


70




l’environnement ou en fonction des messages reçus. Les diagrammes d’états (statechartdiagram) AUML semblent être une solution efficace pour décrire leurs comportements[Huget, 2002b]. Premièrement, nous rappelons quelques caractéristiques des statechartsque nous utilisons dans cette section et ultérieurement dans le chapitre 4 pour proposerquelques règles informelles facilitant le travail d’implémentation d’un agent à partir de soncomportement sous la forme d’un statechart. Ensuite nous modélisons et décrivons lecomportement de tous les agents identifiés dans la section 3.4.1 de ce même chapitre.

3.6.2. Rappel sur les statechartsLe langage des statecharts appartient à la famille des formalismes inspirés du paradigme‘automate d’état fini’, qu’ils enrichissent par l’introduction d’un ensemble d’états hiérarchisés[Harel, 1987]. Un état d’un statechart peut se décomposer en des sous-états. Si un état Sest actif, certains sous-états de S, s’il en possède, seront actifs, dépendant du type de S.

Un état S peut être de type :

∙ Basique s’il ne comporte pas de sous-états,∙ OU et alors, lorsque S est actif, un et un seul état de ses sous-états est actif,∙ ET et alors, lorsque S est actif, tous ses sous-états sont actifs.

Un état de type ET exprime donc une décomposition concurrente et un état de type OU unedécomposition séquentielle. Un sous-état peut à son tour se décomposer en sous-états. Lastructure hiérarchique des états d’un statechart permet de dire par exemple qu’un état S1est un descendant de l’état S2, ou inversement, que S2 est un ancêtre de S1.

Une autre caractéristique des statechart est la communication par diffusiond’événements, qui se produit lors des changements d’état. Ces derniers sont décrits parles transitions. Une transition τ = (S0, λ, Sd) est définie par son état origine S0, sonétat destination Sd et son étiquette λ. Cette dernière est constituée d’une expressiond’événement ev, d’une expression conditionnelle cond et d’une expression d’action act,suivant la syntaxe ev [cond] / act.

Pour qu’une transition τ puisse se déclencher, il faut :

∙ que l’état S 0 soit actif,

∙ que l’expression d’événement ev s’évalue à vrai,∙ que la condition cond s’évalue à vrai,

Dans ce cas l’état S0 devient inactif, l’état Sd devient actif et les actions décrites par actsont exécutées.

A l’intérieur d’un état du statechart, l’action différer (defer en anglais) est utilisée pourdéfinir des événements différés, c’est-à-dire des événements qui, s’ils ne déclenchent pasde transition lors de leur occurrence, ne sont pas perdus mais mémorisés dans une filed’attente jusqu’à ce qu’ils soient acceptés ou que le statechart soit dans un état où ils nesont plus différés (dans ce dernier cas, les événements sont alors perdus).

Le langage des statecharts inclut de nombreuses primitives et constructions dontcertaines sont illustrées par l’exemple qui suit.

Considérons le statechart de la figure 3.15. Les états T1 et P1 peuvent être actifs enmême temps car ils sont les descendants de l’état S qui est de type ET. Si l’événement estalors présent, la transition (T1, (A [X > 0] / B), T2) sera déclenchée, à condition que la valeur


71




de la variable X soit supérieure à zéro. Dans ce cas, l’état T1 devient inactif, l’état T2 devientactif, l’événement A disparaît et l’événement B est provoqué et diffusé. Au pas suivant,l’occurrence de B déclenche la transition sortant de P1. Par l’intermédiaire du connecteurc. La valeur de la variable Y déterminera alors si l’état destination est P2 ou P3. Au cas oùY = 0, P3 sera activé. L’identificateur de l’état P2 est décoré du symbole > pour signifierqu’une action statique lui est associée. A l’instant d’activation de P2 (déclencheur entering),les instructions indiquées dans la figure 3.15, à l’intérieur de cet état sont exécutées.

Fig. 3.15 - Exemple simple d’un modèle statechart

3.6.3. Comportement des agentsLes facteurs essentiels qu’on a pris en considération lors de l’élaboration des diagrammesd’états-transitions sont :

∙ L’aspect parallèle (concurrentiel) des activités d’un acteur. Par exemple, l’agent« Liv » peut traiter plusieurs commandes en même temps.

∙ L’environnement de la CL est riche en négociation entre les agents,∙ Ces négociations se font à base de la communication par messages asynchrones.

Un message asynchrone n’interrompt pas l’exécution de l’expéditeur. L’expéditeurenvoie le message sans savoir quand, ni même si le message sera traité par lesdestinataires.

3.6.3.1. Comportement de l’agent « Liv ».Le comportement de l’agent « Liv » dépend du type de l’acteur, qui peut être une usinefabriquant un produit, un distributeur (acteur ne possédant pas l’activité de production) ouun détaillant. La figure 3.16 illustre son comportement de base pour une usine. Dans lecas d’un distributeur, l’événement « Message_AgentFab » provoqué par la réception d’unmessage provenant de l’agent « Fab » sera remplacé par un événement qu’on appellera


72




« Message_AgentApp » et qui sera provoqué cette fois-ci par tout message provenant del’agent « App » du même acteur.

Fig. 3.16 - Diagramme d’états-transitionsde l’agent « Liv » d’un acteur de type « usine »

Le tableau 3.3 donne la description des états de l’agent « Liv » d’un acteur de type« Usine ».

Tab. 3.3 : Etats de l’agent « Liv » pour une usine.


73




Etat DescriptionGestion_Stock_CommandesLorsque l’agent est dans cet état, il gère le stock de produits

finis (stock de distribution) en utilisant une méthode de gestionde stock. Par exemple, le système à point de commande, lesystème à re-complètement périodique, etc. Il maintient aussiun plan de livraison des commandes confirmées. Selon laméthode utilisée pour la gestion du stock, des événementsinternes peuvent être déclenchés. Par exemple la périodede révision est atteinte (dans le cas d’un système à re-complètement périodique). L’action devant être exécutée suiteau déclenchement de ce type d’événement est l’envoi d’unmessage de performative égale à « REQUEST » à l’agent« Fab » dans le cas d’une usine ou à l’agent « App » dans lecas d’un distributeur. Au même temps, il attend l’arrivée d’unecommande provenant de l’agent « Appi » d’un autre acteur.L’événement « Message_AgentAppi » montre que l’agentpeut traiter plusieurs commandes en même temps provenantd’acteurs différents. Il attend aussi des réponses provenant del’agent « Fab ».

Etudier_Commande Dans cet état, l’agent « Liv » étudie la possibilité de livraisonde la commande qui peut être nouvelle ou en cours d’étude.Pour ce faire, il consulte le stock et le programme de livraison,puis communique avec l’agent « Fab » si nécessaire. Il peutrépondre à ce moment à l’agent « Appi » ou ultérieurementquand il reçoit la réponse de l’agent « Fab ».

Mettre_à_jour_Plan_LivraisonDans cet état, l’agent « Liv » met à jour le plan de livraisonpour tenir compte de la commande confirmée par l’agent« Appi ». Eventuellement, il peut envoyer un message deconfirmation à l’agent « Fab ».

Annuler_Commande Dans cet état, l’agent « Liv » doit annuler la commandeconfirmée ou se trouvant en cours d’étude.

Envoyer_Confirmation Deux cas de figures sont possibles dans cet état : L’agent« Liv » envoie un message de réponse à l’agent « Appi »en lui indiquant que la livraison de la commande passée estpossible et attendra sa confirmation. L’agent « Liv » envoie unmessage de confirmation à l’agent « Fab » pour commencerla production (par exemple, dans le cas de la mise à jour dustock dans un système à point de commande).

Envoyer_Nouvelle_Proposition_à_AgentAppiDans cet état, l’agent identifie les raisons pour lesquellesl’agent « Fab » n’a pas accepté la demande d’effectuer l’actionde production, il cherche ensuite une nouvelle proposition etl’envoie à l’agent « Appi ».

Mettre_à_jour_Stock Dans cet état, l’agent « Liv » met à jour le stock après la fin dela production.

Livraison Dans cet état, l’agent livre la commande programmée dans leplan de livraison.

Calcul_Prévisions Dans cet état, l’agent calcule les prévisions et met à jour lesplans nécessaires.

3.6.3.2. Comportement de l’agent « Fab ».


74




La figure 3.17 illustre le comportement de l’agent « Fab » et le tableau 3.4 décrit sesdifférents états.

Fig. 3.17 - Diagramme d’états-transitions de l’agent « Fab »

Tab. 3.4 : Etats de l’agent « Fab ».


75




Etat DescriptionGestion_Production Lorsque l’agent est dans cet état, il gère

un programme de production. En mêmetemps, il attend l’arrivée d’un messageprovenant de l’agent « Liv » ou l’agent« App ». Ce message peut contenir unenouvelle demande de production ou bien uneréponse concernant une commande en coursd’étude.

Etudier_Demande_Pro Dans cet état, l’agent analyse la demandede production puis communique avec l’agent« App » si nécessaire. Il peut répondre à cemoment à l’agent « Liv » ou ultérieurementquand il reçoit la réponse de l’agent « App ».

Mettre_à_jour_Prog_Pro Dans cet état, l’agent met à jour leprogramme de production pour tenir comptede la commande confirmée. Eventuellement,il peut envoyer un message de confirmationà l’agent « App ».

Annuler_Demmande Dans cet état, l’agent annule la productionconcernant une commande confirmée ou encours d’étude.

Confirmer_à_AgentLiv Dans cet état, l’agent confirme à l’agent« Liv » que la production est possibleet attend juste sa confirmation pourcommencer.

Envoyer_Nouvelle_Proposition_à_AgentLiv Dans cet état, l’agent identifie les raisonspour lesquelles l’agent « App » a refusé,ensuite il envoie une nouvelle proposition àl’agent « Liv ».

Tenir_compte_Perturbation L’agent identifie le degré de la perturbationpuis demande la mise à jour des plansnécessaires.

Confirmer_Production_Terminée Dans cet état, l’agent envoie un message àl’agent « Liv » pour mettre à jour le stock, carla production de la quantité demandée deproduits est terminée.

3.6.3.3. Comportement de l’agent « App » La figure 3.18 illustre le comportement de l’agent « App ». Le tableau 3.5 décrit ses différentsétats.


76




Fig. 3.18 - Diagramme d’états-transitions de l’agent « App »

Tab. 3.5 : Etats de l’agent « App ».


77




Etat DescriptionGestion_Approvisionnement L’agent gère le stock d’approvisionnement

de chaque matière première.Etudier_Commande Dans cet état, l’agent vérifie si les quantités

demandées des matières premières sontdisponibles ou pourrait l’être.

Mettre_à_jour_Plan_App L’agent met à jour le pland’approvisionnement pour tenir compte de lacommande confirmée.

Annuler_Commande Dans cet état, l’agent doit annuler lacommande confirmée ou se trouvant encours d’étude.

Envoyer_Confirmation Deux cas de figures sont possibles dans cetétat : L’agent « App » envoie un messagede réponse à l’agent « Fab » en lui indiquantque les quantités demandées des matièrespremières sont disponibles ou elles le seront. L’agent envoie un message de confirmationd’une commande d’approvisionnement àl’agent « Livi » d’un autre acteur.

Envoyer_Nouvelle_Proposition_à_AgentFab L’agent envoie une nouvelle proposition àl’agent « Fab ».

Mettre_à_jour_Stock_App L’agent reçoit les matières premières, il metà jour le stock d’approvisionnement. Cecidépend bien sûr des méthodes utiliséespour la gestion du stock de chaque matièrepremière.

3.6.3.4. Comportement de l’agent « AgentSCM ».Le comportement de l’agent « AgentSCM » dépend du type du processus de collaboration,coopération ou partenariat mise en œuvre entre l’acteur en question et ses clients ou sesfournisseurs. La figure 3.19 illustre le comportement d’un agent « AgentSCM » dans le casdu CPFR. Le tableau 3.6 décrit ses différents états.


78




Fig. 3.19 - Diagramme d’états-transitions de l’agent « AgentSCM » pour le CPFR

Tab. 3.6 : Etats de l’agent « AgentSCM » pour le processus CPFR.


79




Etat DescriptionInit_AgentSCM Phase d’initialisation de l’agent « AgentSCM ».Calcul_Prévisions_Ventes L’agent crée les prévisions de ventes quand la

date correspondante est atteinte.Supply_Chain_Management Dans cet état, l’agent consulte en continu les

informations partagées et les met à jour.Collaborer_Exceptions_Prévisions_Ventes L’agent collabore avec l’agent « AgentSCM »

du fournisseur pour résoudre les exceptionsdes prévisions de ventes (par exemple, leschangements et les mises à jour de chacun desacteurs, le changement du produit, etc.)

Créer_Prévisions_Commandes Quand les exceptions concernant les prévisionsde ventes sont résolues, l’agent crée desprévisions de commandes.

Collaborer_Exceptions_Prévisions_CommandesL’agent collabore avec l’agent « AgentSCM » du fournisseur pour résoudre les exceptions desprévisions de commandes.

Créer_Commandes Les prévisions sont validées et se transformenten commandes réelles.

Mettre_à_jour_Plans_Concernés Les plans d’approvisionnement, de production etde distribution doivent être mis à jour pour tenircompte des commandes confirmées.

Analyser_Prévisions_Ventes_Client L’agent analyse les prévisions de ventes créespar le client et lui envoie ses propositions.

Collaborer_Exceptions_Prévisions_Ventes_ClientsL’agent collabore avec l’agent « AgentSCM » du client pour résoudre les exceptions desprévisions de ventes.

Analyser_Prévisions_Commandes Quand les exceptions concernant les prévisionsde ventes sont résolues, l’agent analyse lesprévisions de commandes et envoie sespropositions au client.

Collaborer_Exceptions_Commandes_Client L’agent collabore avec l’agent « AgentSCM » du client pour résoudre les exceptions desprévisions de commandes.

Mettre_à_jour_Plans_Nécessaires Les plans d’approvisionnement, de production etde distribution doivent être mis à jour pour tenircompte des commandes confirmées.

3.7. ConclusionCe chapitre est le cœur de notre contribution. Dans un premier temps, nous avons présentéun cadre méthodologique pour délimiter les frontières de la modélisation de la chaînelogistique en terme de niveaux. En se basant sur la notion de macro-processus d’un acteuret le modèle SCOR, nous avons attribué un modèle à base de quatre agents (« App »,« Fab », « Liv » et « AgentSCM ») à chaque acteur identifié. Dans un deuxième temps, nousavons discuté les différents processus décisionnels de ces agents : décision par stratégie,décision par calcul des coûts et décision par négociation. Ceci nous a amené à développer et


80




proposer des protocoles de négociation (protocole de négociation heuristique, protocole denégociation heuristique ferme, négociation heuristique récursive, protocole de négociationCPFR, etc.) entre agents dans le contexte des chaînes logistiques. Ces protocoles donnentune grande souplesse à notre architecture pour répondre aux problèmes évoqués dans leschapitres précédents. Enfin, nous avons utilisé le diagramme d’états-transitions pour décrirele comportement dynamique de chaque agent, ceci facilitera la phase d’implémentationprésentée dans le chapitre 4.

Dans la suite de la thèse, nous verrons comment l’approche proposée a été mise enœuvre, ainsi que les outils que nous avons employés pour la réaliser. Nous allons aussiprésenter quelques algorithmes que nous avons proposés et validés dans le cadre dequelques études de cas industriels concrets.

Chapitre 4 : Implémentation

81





4.1. IntroductionCe chapitre est destiné à présenter les aspects techniques de l’architecture développée.Cette architecture distribuée est mise en œuvre en utilisant la plateforme multi-agent JADE(Java Agent Development Framework). Nous présentons tout d’abord les spécificationsde la norme FIPA pour les systèmes multi-agent. Ensuite, nous décrivons en détail lemodèle d’agent JADE et les étapes d’exécution d’un thread d’agent qui nous amènent àmontrer des caractéristiques techniques renforçant notre choix de cette plateforme. Puis,nous proposons quelques règles permettant d’obtenir l’essentiel de la structure de la classeJava correspondante à chaque type d’agent à partir de son modèle de comportement vudans le chapitre 3. Enfin, nous donnons une description résumée de la plateforme JADEen présentant son architecture fonctionnelle et le cycle de vie d’un agent. Nous achevonsce chapitre par une conclusion.

4.2. Norme FIPA pour les systèmes multi-agentLes premiers documents de spécification de la norme FIPA [FIPA, 1997], appelésspécifications FIPA97, établissent les règles normatives qui permettent à une sociétéd'agents d'inter-opérer. Tout d'abord, les documents FIPA décrivent le modèle de référenced'une plate-forme multi-agents (figure 4.1) où ils identifient les rôles de quelques agentsclés nécessaires pour la gestion de la plate-forme, et spécifient le contenu du langage degestion des agents et l'ontologie du langage.


82




Fig. 4.1 - Le modèle de référence pour une plate-forme multi-agent FIPA

∙ Le Système de Gestion d'Agents (Agent Management System ‘AMS’) est l'agentqui 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ôled'enregistrements.

∙ Le Canal de Communication entre Agents (Agent Communication Channel ‘ACC’,appelé aussi ‘Message Transport System’) est l'agent qui fournit la route pour lesinteractions de base entre les agents dans et hors de la plate-forme ; c'est la méthodede communication implicite qui offre un service fiable et précis pour le routage desmessages ; il doit aussi être compatible avec le protocole IIOP (Internet Inter-OrbProtocol) pour l'interopérabilité entre les différentes plates-formes multi-agent.

∙ Le Facilitateur d'Annuaire (Directory Facilitator ‘DF’) est l'agent qui fournit un servicede pages jaunes à la plate-forme multi-agent. Il faut remarquer qu'il n'y a aucunerestriction sur la technologie utilisée pour l'implémentation de la plate-forme : e-mail,basé sur CORBA, applications multi-threads Java, etc.

Le standard spécifie aussi le Langage de Communication d'Agents (Agent CommunicationLanguage ‘ACL’). La communication des agents est basée sur l'envoi de messages.Le langage FIPA-ACL est le langage standard des messages et impose le codage, lasémantique et la pragmatique des messages. La norme n’impose pas de mécanismespécifique pour le transport interne des messages. Plutôt, puisque les agents différentspourraient s'exécuter sur des plates-formes différentes et utiliser des technologiesdifférentes d'interconnexion, FIPA spécifie que les messages transportés entre les plates-formes devraient être codés sous forme textuelle. On suppose que l'agent est en mesurede transmettre cette forme textuelle. La norme FIPA préconise des formes communes pourles conversations entre agents par la spécification de protocoles d'interaction, qui incluentdes protocoles simples de type requête-réponse, mais aussi des protocoles spécifiques auxagents.


83




4.3. Modèle d’agents JADE et notion decomportement

JADE est une plateforme multi-agent développée en Java par CSELT (Groupe derecherche de Gruppo Telecom, Italie) qui a comme but la construction des systèmes multi-agent et la réalisation d'applications conformes à la norme FIPA. JADE comprend deuxcomposantes de base : une plateforme agents compatible FIPA et un paquet logiciel pourle développement des agents Java.

Dans cette section, nous présentons en détail le modèle d’agents dans la plateformeJADE afin de montrer quelques unes de ses performances et ses caractéristiques. Sesdernières sont qualifiées comme importantes dans le choix de cette plateforme pour laphase d’implémentation de notre architecture distribuée.

4.3.1. Modèle d'agentsOn a vu qu'une propriété importante d'un agent est son autonomie : un agent ne doit pas selimiter à réagir aux événements externes, mais il doit être aussi capable de prendre l'initiativede nouveaux actes communicatifs d'une façon autonome. Ceci exige que chaque agentait un thread interne de contrôle ; cependant, un agent peut engager des conversationssimultanées multiples, tout en poursuivant d'autres activités qui n'impliquent pas d'échangesde messages.

JADE utilise l'abstraction Comportement (Behaviour) pour modéliser les tâches qu'unagent peut exécuter. Les agents instancient leurs comportements selon leurs besoinset leurs capacités. Du point de vue de la programmation concurrente, un agent estun objet actif, ayant un thread de contrôle. JADE utilise un modèle de programmationconcurrente "un thread-par-agent" au lieu d'un modèle "un thread-par-comportement" pouréviter une augmentation du nombre de threads d'exécution exigés sur la plateformed'agents. Ceci signifie que, pendant que les agents différents s'exécutent dans unenvironnement multi-thread de préemption, deux comportements d'un même agent sontplanifiés coopérativement.

En dehors de la préemption, les comportements travaillent tous comme des threadsd'exécution coopératifs, mais il n'y a pas de pile qui ait besoin d'être sauvée. Un planificateur(scheduler), exécuté par la classe de base Agent et caché au programmeur, exécute unepolitique de « round-robin » de non-préemption entre tous les comportements disponiblesdans la file des processus prêts. Ainsi, il permet l'exécution d'une classe dérivée de la classeComportement jusqu'à ce qu'elle abandonne le contrôle d'exécution par elle-même. Si latâche qui a le contrôle n'est pas encore finie, elle sera re-planifiée pendant le prochaintour du « round-robin » à moins qu'elle ne soit pas bloquée ; en fait, un comportementpeut se bloquer lui-même, par exemple pendant qu'il attend des messages, pour éviterle gaspillage de temps de CPU, réalisant ainsi un comportement d'attente occupée. Lafigure 4.2 résume les étapes d’exécution d’un thread d’agent. Donc, le développeur d'agentsdoit étendre la classe Agent et implémenter les tâches spécifiques de l'agent par uneou plusieurs classes Comportement, les instancier et les ajouter à l'agent en utilisant laméthode addBehaviour(). JADE inclut quelques comportements prêts à être utilisés pour lestâches les plus communes dans la programmation des agents, tels que l'envoi et la réceptiondes messages et la décomposition des tâches complexes en des agrégations de tâches plussimples. La figure 4.3 montre la hiérarchie de quelques classes de comportement JADE. Par


84




exemple, la classe OneShotBehaviour permet d’instancier un comportement qui se terminejuste après sa première exécution. Ainsi, sa méthode action() qui représente la tâche àeffectuer est exécutée une seule fois. La méthode done() de cette classe est déclarée finale(i.e. ne pouvant pas être redéfinie) et retourne toujours vrai (true). La classe CyclicBehaviourpermet d’instancier un comportement qui ne se termine pas. Par conséquent, sa méthodeaction() exécute les mêmes opérations chaque fois où est appelée jusqu’à ce que le threadinterne de l’agent exécutant ledit comportement se termine. La méthode done() de cetteclasse est déclarée finale et retourne toujours false.

La classe Agent représente une super-classe commune pour tous les agents définispar l'utilisateur. Du point de vue du programmeur, la conséquence est qu'un agent JADEest une classe Java qui étend la classe de base Agent. Cela permet à l'agent d'hériterun comportement fondamental caché (qui traite toutes les tâches liées à la plate-forme,telles que l'enregistrement, la configuration, la gestion à distance, etc.), et un ensemblede méthodes qui peuvent être appelées pour implémenter les tâches spécifiques àl'agent, par exemple envoi des messages, utilisation des protocoles d'interaction standard,enregistrement sur plusieurs domaines, etc. Entre autres, JADE offre aussi une classeJessBehaviour qui permet l'intégration avec le système expert JESS (Java Expert SystemShell), où JADE fournit le noyau de l'agent et garantit (autant que possible) la conformitéavec les normes FIPA, alors que JESS est le moteur d'inférence de l'agent qui exécute leraisonnement nécessaire pour la résolution du problème.


85




Fig. 4.2 - Etapes d’exécution d’un thread d’agent


86




Fig. 4.3 - Hiérarchie de quelques classes Behaviour de la plateforme JADE

4.3.2. Critères de choixAprès avoir présenté le modèle d’agent JADE et la notion de comportement, nousrépondons dans cette section à la question : pourquoi nous avons choisi la plateformeJADE ?

Nous avons déjà présenté dans le chapitre 2 (cf. section 2.6) quelques caractéristiquesda la plateforme JADE qui nous ont conduits à la choisir pour la phase d’implémentation.Par rapport à notre problème, JADE possède des caractéristiques d’ordre technique qui ontrenforcé notre choix. L’une des caractéristiques principales est l’abstraction Comportement(Behaviour) présentée dans la section précédente. Elle permet d’implémenter les tâchesqu'un agent peut exécuter. La notion de Comportement se révèle très importante au moinspour deux raisons :


87




1. Elle permet d’implémenter de manière efficace les protocoles d’interaction entreles agents. Ceci est très important dans notre cas pour implémenter les différentsprotocoles de négociation modélisés par AUML dans le chapitre 3 (cf. section 3.5).A titre d’exemple, les classes prédéfinies ProposeInitiator et ProposeResponder deJADE permettent d’instancier des objets behaviours qui implémentent le protocoled’interaction FIPA-Propose modélisé par le diagramme de séquence AUML de lafigure 4.4. JADE fournit d’autres classes de comportements prêts pour implémenterles protocoles d’interactions FIPA comme FIPA Propose Protocol, FIPA RequestProtocol, FIPA Contract Net Protocol, FIPA English Auction Protocol [FIPA, 2003].Ces classes se trouvent dans le package jade.proto.

Fig. 4.4 - Protocole d’interaction FIPA ProposeLa notion de comportement nous permet de générer rapidement le squelette de code

d’un agent JADE à partir du diagramme d’états-transitions qui modélise son comportement(cf. chapitre 3, section 3.6). Comme nous montrerons dans la section suivante dece chapitre, nous avons élaboré quelques règles informelles qui facilitent le travaild’implémentation d’un agent (héritant de la classe Agent de la plateforme JADE) à partir deson comportement sous la forme d’un statechart. Il s’agit donc de faciliter le passage de laspécification à l’implémentation.

4.4. Des diagrammes d’états-transitions versl’implémentation des agents : l’ingénierie vers l’aval


88




L’ingénierie vers l’aval est le processus de transformation d’un modèle en code grâce à unmapping dans un langage d’implémentation donné. Dans cette section, nous proposonsquelques règles informelles qui facilitent le travail d’implémentation d’un agent (héritant dela classe Agent de la plateforme JADE) à partir de son comportement sous la forme d’unstatechart, mis au point dans la phase précédente (cf. chapitre 3, section 3.6), considéréecomme une étape de spécification. Il s’agit donc de faciliter le passage de la spécification àl’implémentation. Ce passage se présente sous la forme d’un ensemble de transformationsentre un diagramme d’états-transistions, modèle de comportement d’un agent et une classed’agent, conformément à la structure proposée par JADE pour une telle classe.

Nous commençons d’abord par la présentation des étapes détaillées d’exécution d’unthread d’agent JADE. Ensuite, nous proposons des règles informelles de transformationentre le modèle de comportement d’un agent et sa classe correspondante en JADE. Puis, àtitre d’exemple, nous appliquons ces règles sur le statechart de l’agent « Liv » (cf. chapitre3, section 3.6.3.1, fig 3.16) afin de déterminer partiellement son code. En général ce codedevra être complété par des instructions spécifiques à la gestion de l’activité d’un agentdans l’environnement d’exécution de JADE.

La figure 4.5 présente les étapes détaillées d’exécution d’un thread d’agent JADE.En fait, nous avons enrichi la figure 4.2 par d’autres étapes (marquées par un fondgris) que nous avons déduites au cours de l’utilisation de la plateforme JADE. Commele montre cette figure, chaque agent JADE possède une méthode setup(). Elle estdestinée à contenir les ordres d’initialisations de l’agent et d’ajout de comportements. Il estindispensable d'ajouter au moins un objet comportement (Behaviour) à l'agent, pour qu'ilsoit capable de faire quoi que ce soit. L’ajout d’un nouveau comportement se fait par laméthode addBehaviour(Behaviour b). La méthode takeDown() est exécutée juste avant laterminaison définitive de l’agent.

Chaque objet comportement (behaviour) possède entre autres les méthodes onStart(),onEnd() et action(). La méthode onStart() est exécutée une seule fois avant de commencerl'exécution du comportement, c’est-à-dire avant l’exécution de la méthode action() quireprésente l’activité à exécuter par le comportement. La méthode onEnd() est exécutée uneseule fois après la fin d’exécution du comportement.

Un objet comportement d’un agent peut être bloqué (méthode block()) en attendantl’arrivée d’un message provenant d’un autre agent. Quand un message est posté dans laboîte privée des messages de l’agent, le planificateur25 (exécuté par la classe de base Agentet caché au programmeur) exécute le comportement.

La boîte privée des messages de chaque agent est partagée entre tous ses objetscomportement. De ce fait, on peut bloquer un objet comportement et ne l’exécuter quelorsqu’un message vérifiant des conditions précises soit posté. La classe MessageTemplatefournie avec la plateforme JADE permet de créer ces conditions et par suite sélectionnerle message correspondant.

25 Ang. Scheduler


89




Fig. 4.5 - Etapes détaillées d’exécution d’un thread d’agent JADE*: If the method is called from within action() method, behaviour suspension occurs as

soon as action() returns.Après avoir présenté en détail les étapes d’exécution d’un thread d’agent, nous passons

maintenant aux règles de transformation.Nous avons déjà vu dans le chapitre 3 (section 3.6.2) qu’une transition τ = (S0, λ, Sd)

est définie par son état origine S0, son état destination Sd et son étiquette λ. Cette dernièreest constituée d’une expression d’événement ev, d’une expression conditionnelle cond etd’une expression d’action act, suivant la syntaxe ev [cond] / act. Alors, le premier élémentde transformation peut être formulé comme suit :

A chaque couple « étiquette λ, état destination S d » on associe un objet comportement(Behaviour). Le type de cet objet (cf. figure 4.3) dépend de deux critères concernantl’événement ev constituant la transition. Le premier critère est lié au type de l’événementqui pourra être un message provenant d’un autre agent ou non (par exemple : événementtemporel causé par l’expiration d’une temporisation). Nous avons déjà dit dans le rappel


90




sur les statecharts (cf. chapitre 3, section 3.6.2) qu’un événement pourra être différé envue d’un traitement ultérieur dans un état ne différant pas cet événement. Ce caractèredifféré caractérisant un événement constitue le second critère conduisant au choix du typede l’objet comportement. Nous nous intéressons ici seulement aux événements de typemessages provenant d’autres agents. Nous dégageons donc deux règles :

1. Si l’événement constituant la transition est non différé dans aucun des étatsde l’agent, alors le type de l’objet comportement sera OneShotBehaviour(). Il ne doit êtreajouté que lorsque l’agent termine l’exécution de l’état origine de cette transition. L’objetOneShotBehaviour() ajouté doit être bloquée jusqu’à l’arrivée du message correspondant.

2. Si l’événement est différé , alors le type de l’objet comportement seraCyclicBehaviour(). Il pourra être ajouté dans la partie initialisation de l’agent, en particulierdans la méthode setup(). L’objet CyclicBehaviour() ajouté doit être bloquée jusqu’à l’arrivéedu message correspondant. La classe MessageTemplate de la plateforme JADE permet decréer des templates complexes pour sélectionner les messages reçus.

La troisième règle de transformation concerne les actions d’entrée et de sortie dechaque état (représenté par un comportement). Elle peut être formulée comme suit :

3. Dans certaines situations, on souhaite exécuter les mêmes instructions chaquefois que l’on entre dans un état quelle que soit la transition par laquelle on est arrivé. Cesinstructions peuvent être placées dans la méthode onStart() du comportement associé. Demême, à la sortie d’un état (fin d’exécution du comportement associé), on peut avoir envied’exécuter les mêmes instructions, quelle que soit la transition par laquelle on repart. Cesinstructions peuvent être placées dans la méthode onEnd() du comportement.

Dans la suite de cette section, nous montrons comment appliquer ces règles sur unexemple d’agents de notre système. Pour cela, nous nous référons au diagramme d’états-transitions de l’agent « Liv » (cf. chapitre 3, section 3.6.3.1, fig 3.16). Nous le reprenonssur la figure 4.6. La classe Java de l’agent « Liv » est obtenue à partir de son modèle decomportement, sa structure partielle est présentée dans le tableau 4.1.

Remarque :Dans certains cas, après une application mécanique des transformations, on peut

percevoir des possibilités de simplification.


91




Fig. 4.6 - Statechart de l’agent « Liv »


92




Tab. 4.1 : Transformation partielle du modèle decomportement de l’agent « Liv » vers le code Java


93





94




4.5. Architecture fonctionnelle de JADE et cycle de vied’un agent

Dans cette section, nous allons présenter l’architecture fonctionnelle de JADE et le cyclede vie d’un agent JADE.


95




4.5.1. Architecture de la plate-forme JADEL'architecture du logiciel est basée sur la coexistence de plusieurs Machines Virtuelles (VM)Java et la communication se fait par la méthode RMI (Remote Method Invocation) de Javaentre machines virtuelles (VMs) différentes. Chaque VM est un réceptacle d'agents quifournit un environnement d'exécution complet pour l'exécution des agents et permet d'avoirplusieurs agents qui s'exécutent simultanément sur un même hôte. Chaque réceptacled'agents est un environnement multi-thread d'exécution composé d'un thread d'exécutionpour chaque agent et en plus, des threads créés à l'exécution par le système RMI pourenvoyer des messages. Un récipient (container) spécial joue le rôle du frontal de la plate-forme (main-container); il contient les agents de gestion et représente la plate-forme touteentière pour le monde extérieur.

Une plate-forme multi-agent JADE est alors composée de plusieurs réceptaclesd'agents selon la figure 4.7. La distribution de ces réceptacles à travers un réseaud'ordinateurs est permise, à condition que la communication RMI entre leurs hôtes soitconservée. Chaque réceptacle d'agents est un objet serveur RMI qui gère localement unensemble d'agents. Il règle le cycle de vie des agents (voir section 4.5.2) en les créant,les suspendant, les reprenant et les détruisant. En plus, il traite tous les aspects de lacommunication : répartition des messages ACL reçus, routage des messages selon lechamp de destination (: receiver) et dépôt des messages dans les files de messages privéesdes agents (figure 4.8). Pour les messages vers l'extérieur, le réceptacle d'agents maintientassez d'information pour chercher l'emplacement de l'agent récepteur et pour choisir uneméthode de transport convenable pour expédier le message ACL.


96




Fig. 4.7 - Plateforme et récipients (container)


97




Fig. 4.8 - Gestion des messages envoyés et reçus par les agents JADE

4.5.2. Cycle de vie d’un agentUn agent JADE peut être dans l’une des différents états de son cycle de vie définis parles spécifications FIPA (figure 4.9). Ces états sont représentés par des constantes dans laclasse Agent qui figure dans les packages fournis avec la plateforme JADE :

∙ AP_INITIATED :l’objet Agent est construit, mais il n’est pas encore enregistré avecl’AMS. Il ne possède ni un identificateur ni une adresse et ne peut pas communiqueravec d’autres agents.

∙ AP_ACTIVE :l’objet Agent est enregistré avec l’AMS, il possède un nom correct etpeut accéder à toutes les caractéristiques du JADE.

∙ AP_SUSPENDED :l’objet Agent est actuellement stoppé. Son thread interne estsuspendu et aucun comportement (behaviour) ne peut s’exécuter.

∙ AP_WAITING :l’objet Agent est bloqué. Son thread interne est en sommeil. Il peut seréveiller quand une condition est vérifiée (typiquement quand un message arrive).

∙ AP_DELETED : l’exécution du thread interne de l’agent est terminée. L’agent n’estplus enregistré avec l’AMS.

∙ AP_TRANSIT :un agent mobile entre dans cet état quand il migre à un nouvelemplacement. Le système continue à mémoriser les messages afin de les lui envoyerau nouvel emplacement.

∙ AP_COPY : cet état est utilisé intérieurement par le JADE pour cloner un agent.∙ AP_GONE : cet état est utilisé intérieurement par le JADE quand un agent mobile a

migré vers un nouvel emplacement et a pris un état stable.

La classe Agent fournit avec le JADE possède des méthodes publiques qui permettent dechanger l’état d’un objet Agent. Par exemple, la méthode doWait () permet de passer unagent de l’état AP_ACTIVE à l’état AP_WAITING.


98




Fig. 4.9 - Le cycle de vie d’un agent défini par FIPA

4.6. ConclusionCe chapitre a été consacré à la phase d’implémentation de l’architecture proposée sousl’environnement JADE. Nous avons présenté en détail la notion de comportement et lemodèle d’agent JADE. Ensuite nous avons montré que ces deux caractéristiques techniquesont renforcé beaucoup notre choix de la plateforme JADE. Puis nous avons proposédes règles informelles de transformation permettant l’obtention de squelette d’une classed’agent dans JADE à partir de son modèle de comportement (statechart). On a aussi montrécomment appliquer ces règles sur l’un des agents de notre système. Ainsi, à titre d’exemple,on a pu généré la structure partielle de l’agent « Liv » à partir de son diagramme d’états-transitions. Enfin, nous avons présenté brièvement l’architecture de JADE ainsi que le cyclede vie d’un agent JADE.

Chapitre 5 : Validation

99





5.1. IntroductionCe chapitre a pour but principal de présenter les cas d’étude traités et sur lesquels nousnous sommes basés pour valider nos propositions. Nous décrivons quelques processus(méthodes de collaboration) et algorithmes permettant de gérer les commandes urgentesnon prévues au sein d’une CL de distribution de produits sanitaires. Ensuite, Nousdiscuterons les résultats obtenus et l’apport que pourra apporter notre système dans larésolution de quelques problèmes liés aux flux d’informations et de produits. Puis, noussimulerons le processus CPFR (Collaborative Planning, Forecasting and Replenishment) etnous tirons quelques conclusions sur sa mise en œuvre dans le cas d’une chaîne logistiquetravaillant dans le secteur du textile et d’habillement. Enfin, nous achevons ce chapitre parune conclusion.

5.2. Etude de cas industriel : Gestion des commandesurgentes non prévues

Dans le but de valider l’approche et l’architecture proposées dans ce mémoire, nous avonstravaillé en collaboration avec une entreprise située au Maroc et travaillant dans le secteursanitaire. Nous présentons dans cette section la problématique industrielle traitée et l’apportde notre architecture.

5.2.1. Contexte économique Après avoir étudié les secteurs se trouvant en plein développement sur le marché marocain,nous avons choisi un grand distributeur travaillant dans les secteurs du Sanitaire (lavabos,water-closets, etc.), la Robinetterie, le Carrelage (carreaux sol et murs, Zellige), la Plomberieet les Meubles. Ces secteurs sont directement liés au marché de l’immobilier. Ce dernierconnaît actuellement une mutation profonde et une véritable révolution se traduisant par "laprofessionnalisation, l'internationalisation et la financiarisation progressive de ce secteur",a affirmé en novembre 2007, le directeur régional du groupe CB Richard Ellis-Maroc(CBRE26), leader mondial du conseil en immobilier.

26 CB Richard Ellis est le premier cabinet-conseil international en immobilier à s'implanter au Maroc et en Afrique du Nord. La société-mère, dont le siège se trouve à Los Angeles, est cotée à la bourse de New York et compte plus de 24.000 collaborateurs répartisdans plus de 300 bureaux et 58 pays. Son chiffre d'affaires pour l'année 2006 s'élève à 4 milliards de dollars. En 2007, la filialemarocaine du groupe CBRE a expertisé plus de 1,4 milliard d'Euros de biens immobiliers au Maroc. Elle compte 18 consultants denationalités différentes. D’après : http://www.emarrakech.info/Le-marche-immobilier-marocain-en-plein-essor,-selon-le-groupe-CB-Richard-Ellis_a13083.html .

http://www.emarrakech.info/Le-marche-immobilier-marocain-en-plein-essor,-selon-le-groupe-CB-Richard-Ellis_a13083.html

http://www.emarrakech.info/Le-marche-immobilier-marocain-en-plein-essor,-selon-le-groupe-CB-Richard-Ellis_a13083.html


100




D’après l’article27 publié le 30 Mai 2006 par Isabelle Rey-Lefebvre sous le titre « AuMaroc, le marché de l'immobilier est en ébullition », Le marché immobilier marocain doitrelever un triple défi : construire 1,2 million de logements pour les habitants, répondre à lademande grandissante des « MRE » (Marocains résidant à l'étranger) qui veulent un toit aupays natal, et gérer l'afflux d'étrangers, touristes et retraités. « Nous avons décidé de faireappel au privé, dans le cadre de partenariats avec le public, pour construire les logementsqui manquent au pays, qu'il s'agisse d'appartements économiques, en accession sociale,ou d'habitats de standing », explique Ahmed Taoufik Hjira, ministre marocain de l'habitatet de l'urbanisme.

Les statistiques2 présentées sur le tableau 5.1 montrent que le marché marocain del’immobilier est en plein essor.

Tab. 5.1 : Estimation des unités construites pendant 2004 et 2005

Type Année Estimée à2004 40 000 unitésParcelles de terrain ou de

logements 2005 112 300 unitésHabitats de standing 2005 80 000 unités

5.2.2. Description de la chaîne logistique étudiée Il s’agit d’une grande entreprise située au Maroc qui distribue des produits finis (environ800 articles) dans les secteurs du Sanitaire (lavabos, water-closets, etc.), la Robinetterie, leCarrelage (carreaux sol et murs, Zellige), la Plomberie et les Meubles. Elle possède quatrefournisseurs principaux, deux sont nationaux (Maroc) et deux sont étrangers (l’Espagneet la Turquie). Elle distribue les produits finis à des dizaines de grossistes implantésdans différentes régions du pays. Les produits distribués sont des produits de gammeéconomique et de haute gamme. Quelques produits sont gérés sur stock (système à point decommande et système à re-complètement périodique), d’autres à la commande et d’autresutilisent les deux. La période de révision du stock des produits de haute gamme de laplomberie est égale à 6 mois, celle des autres références est égale à 1 mois. Les quantitéscommandées sont calculées à partir des stocks, des prévisions, et de l’expérience desresponsables de rayon.

5.2.3. Problématique industrielleLe distributeur a remarqué qu’au total, de 6 à 10 commandes urgentes non prévues etfermes sont passées chaque mois (pour des références différentes). Pour les supply chainmanagers, il s’agit d’un grand défi à surmonter puisque ces commandes ne concernent pastoujours le même produit. En valeur moyenne, 60% de ces commandes s’annulent, 20%sont commandées chez d’autres distributeurs et pour les 20% restants, la durée de livraisonest modifiée suite à des négociations avec les clients.

La politique de l’entreprise vise à bien gérer ce type de situation qualifiée de situationd’urgence. Les objectifs de la livraison de ce type de commandes dépendent du profil duclient :

27 www.lemonde.fr , article publié par Isabelle Rey-Lefebvre sous le titre « Au Maroc, le marché de l'immobilier est enébullition », Mai 2006.

http://www.lemonde.fr/


101




∙ Le distributeur ne cherche pas à gagner, mais seulement fidéliser le client : c’est lecas d’un grossiste client.

∙ Accroître le nombre de clients : le fait de livrer des commandes non prévues eturgentes permet aux nouveaux clients d’apprécier le service offert.

∙ Aider un grossiste client de se débarrasser d’un surstock.

5.2.4. Formulation du problème et solution apportéeSupposons qu’un client ait passé une commande urgente non prévue et ferme caractériséepar :

∙ une quantité commandée OQ (Ordered Quantity) ne pouvant pas être livréetotalement ou partiellement à partir du stock disponible,

∙ une date de livraison DT (Delivery Time) qui fixe directement la durée dont dispose ledistributeur pour livrer la commande.

Deux cas sont alors possibles :

1. Le distributeur ne dispose d’aucune partie de la quantité commandée OQ,2. Il dispose d’une partie et doit compléter le reste.

Dans les deux cas, on note :OQ = DisQ + RQAvec DisQ : quantité dont dispose le distributeur, qui peut être nulle (cas 1) ou inférieur

à OQ (cas 2).RQ (required quantity): quantité recherchée.Le problème se résume alors comme suit :Trouver la quantité RQ pour livrer la commande urgente tout en respectant la durée DT

et en minimisant le maximum possible les coûts de transport.L’une des pratiques utilisées par les distributeurs et en particulier celui faisant objet

de notre cas d’étude consiste à chercher la quantité RQ chez un autre grossiste ouun autre distributeur. Du point de vue du distributeur, cette pratique présente quelquesinconvénients :

∙ La négociation se déroule généralement par téléphone, ceci augmente la durée derecherche surtout pour une commande urgente,

∙ La solution trouvée n’est pas toujours la meilleure puisque le distributeur se limite àquelques acteurs plus proches faisant partie du même groupe.

Dans le cadre du SCM, notre architecture étend et automatise cette pratique enimpliquant plusieurs grossistes, distributeurs de mêmes produits et distributeurs de produitséquivalents dans une collaboration interentreprises. Ainsi, le distributeur pourra trouver laquantité RQ chez quatre types d’acteurs différents :

1 er type (les grossistes clients du distributeur)

∙ Grossistes de la même région que le client passant la commande,∙ Grossistes de régions différentes que le client passant la commande,∙ Les deux en même temps.


102




2 ème type (distributeurs de mêmes produits)

∙ Distributeurs de même produits et/ou leurs grossistes.

3 ème type (distributeurs de produits équivalents)

∙ Distributeurs de produits équivalents et/ou leurs grossistes.

4 ème type

∙ Solution hybride faisant intervenir plus de deux types.

Pour mettre en pratique ce processus de collaboration entre les acteurs, satisfaire leursexigences et répondre à leurs attentes, trois conditions doivent être vérifiées :

∙ La recherche de la solution doit être automatisée. De ce fait, le manager contacte lesautres, juste pour confirmer la solution. Cette condition est bien vérifiée puisque larecherche de la quantité RQ et la négociation se font par les agents pour le comptedes managers.

∙ L’autonomie et la confidentialité des données de chaque participant doivent êtregaranties, puisqu’ils peuvent être indépendants. Comme c’est montré dans ledeuxième chapitre, les SMA sont très adaptés à ce type de problème.

∙ Minimiser le maximum possible les coûts de transport qui seront ajoutés au coûtd’achat déjà élevé puisque la commande ne sera pas livrée directement par ledistributeur. L’algorithme exécuté par les agents (tableau 5.2) montre clairement quecette condition est aussi vérifiée.

La figure 5.1 montre les interactions entre les agents collaboratifs. En fait, les agents qui vontnégocier la commande sont les agents AgentSCM des différents acteurs. A titre de lisibilité,nous attribuons respectivement les noms AgentSCM_Who et AgentSCM_Dis auxagentsAgentSCM des grossistes (wholesalers) et distributeurs (distributors). Ces noms sont plussignificatifs surtout que les rôles joués par les agents AgentSCM dans ce cas dépendentdu type de l’acteur (grossiste ou distributeur).


103




Fig. 5.1 - Interactions entre les agents collaboratifsLes différents agents sont autonomes, puisqu’ils permettent à chaque SC manager

de modifier les stratégies de décision. En plus, les agents contrôlent et choisissent lesdonnées à échanger entre eux. Dans le cas où les acteurs collaboratifs sont indépendantsou concurrents, les informations sensibles (comme le niveau du stock) peuvent ne pasêtre échangées. Chaque agent AgentSCM_Dis i peut interagir avec d’autres agents{AgentSCM_Disk / k � [1, nd], k ≠ i} et {( AgentSCM_Who i ) j / j � [1, nw i ],nw i est le nombre total des grossistes collaboratifs du distributeur (i) } (ses grossistesclients), par contre un agent ( AgentSCM_Who i ) j ne peut interagir qu’avec l’agentAgentSCM_Dis i représentant son distributeur. Cette limitation est dûe au fait que lesacteurs travaillent dans le même secteur d’activités. Par conséquent, il est simple de monterune collaboration entre un distributeur et ses grossistes. Tandis qu’il reste difficile voireimpossible à la monter entre un distributeur et les grossistes clients d’un autre distributeur.En fait, chaque distributeur cherche à accroître le nombre de ses grossistes et tente lemaximum possible de les fidéliser.


104




Quand une commande urgente non prévue et ferme (caractérisée par: OQ et DT) estpassée par un client au distributeur (i) (i � [1, nd] et nd est le nombre total des distributeurscollaboratifs ), le SC manager demande à l’agent AgentSCM_Dis i de chercher la meilleuresolution. A ce moment, l’agent exécute l’algorithme search_OQ (tableau 5.2 ci-dessous)[Nfaoui et al., 2008a] pour résoudre le problème pouvant être résumé comme suit :

∙ Chercher la quantité de produit RQ : elle peut être livrée totalement par un seulacteur ou rassemblée par partie chez plusieurs acteurs.

∙ Classer une série de parcours possibles par ordre croissant du coût de transport (quidépend étroitement de la distance) pour transporter la quantité de produits OQ tout enrespectant la durée DT.

∙ Proposer la quantité Q j à prendre chez chaque participant faisant partie d’unparcours.

Tab. 5.2 : Algorithme de recherche de la quantité OQ (Algorithm search_OQ)


105





106





107




La figure 5.2 montre le diagramme de séquence AUML qui modélise les messageséchangés entre l’agent AgentSCM_Dis i (distributeur)et les agents {( AgentSCM_Who i )

j / j � [1, nw i ], nw i est le nombre total des grossistes collaboratifs du distributeur

(i) } (ses grossistes clients).


108




Fig. 5.2 - Protocole d’interaction Distributeur / GrossistesSi aucune solution n’est trouvée, ou si la valeur inacceptable de N (nombre maximal des

grossistes impliqués dans un parcours pour rassembler la quantité RQ. N � [1, nw i ]) estatteinte ou bien dans le cas où le SC manager n’est pas satisfait par les solutions proposéespar le système, l’agent interagira avec les agents { AgentSCM_Dis k / k � [1, nd], k ≠ i} desautres distributeurs en leur envoyant un message de performative QUERY-REF. Chaqueagent applique son processus de décision afin de livrer la quantité RQ. Ils peuvent interagiravec les agents de leurs grossistes clients. La figure 5.3 montre le diagramme de séquenceAUML modélisant les messages échangés entre les agents de différents distributeurs.


109




Fig. 5.3 - Protocole d’interaction Distributeur / Distributeurs

5.2.5. Mise en œuvre industrielle

5.2.5.1. Exemple d’une situation d’urgence Au début de la saison basse des ventes chez le distributeur, le stock d’un produit dehaute gamme et de marque précise était à une valeur très basse. La quantité de re-complètement était retardée à cause d’un problème chez l’un des fournisseurs étrangers.En même temps, un entrepreneur ayant déjà utilisé une quantité de ce produit dans sonchantier de construction d’immeubles (situé à la ville de Fès) avait besoin d’une autrequantité. Il était obligé de passer une commande à l’unique distributeur de ce produit (quiest concerné par notre étude). Il devait utiliser la même gamme du produit manquant pourrecevoir le permis d’habiter et éviter tout problème avec les autorités de contrôle. En plus,l’entrepreneur disposait d’un délai très limité (environ une semaine) pour clore son chantier.Il était difficile de penser à une prolongation de ce délai car il avait déjà distribué les clésdes appartements aux nouveaux habitants. Cette situation était qualifiée par le distributeur


110




comme une situation d’urgence. La commande passée par l’entrepreneur était considéréecomme non prévue, urgente (délai de livraison égale à 9 heures) et ferme (elle ne peut pasêtre retardé ni annulée).

5.2.5.2. Solution adoptée par le distributeurDevant cette situation d’urgence, le distributeur était obligé de remplacer le produitcommandé par leur équivalent (gamme, marque, couleur...) chez un autre distributeurconcurrent situé à la ville de Casa (située environ à 289Km de la ville de Fès). Mêmesi le coût était élevé, le distributeur s’est intéressé à la fidélisation de son client potentiel(l’entrepreneur).

5.2.5.3. Solution fournie par notre systèmeDans le but de montrer l’efficacité de l’outil proposé, nous avons simulé une collaborationentre le distributeur et 37 grossistes parmi ceux qu’il approvisionne en produits finis. Cesgrossistes sont situés dans des régions différentes du pays et sont identifiés par scm1, scm2… scm37 (tableau 5.3).

Tab. 5.3 : Villes où sont localisées les différents grossistesNous avons pris toutes les données nécessaires (historique des stocks, plans de

livraison, stratégies de décision, etc). Nous avons aussi pris en compte que les différentsgrossistes ne partagent pas les informations startégiques (comme le niveau du stock) avecleur distributeur. Cependant, quand il les sollicite pour résoudre une situation d’urgence,chacun d’eux peut le renseigner sur la quantité maximale qu’il peut fournir.


111




a. Liste des parcoursLa figure 5.4 montre seulement les trois premiers parcours parmi 13 solutions proposéespar le système. La figure 5.6 montre les 13 solutions proposées (parcours et quantités) enrelation avec le nombre des grossistes formant chaque parcours. Ce nombre est choisi parle manager (figure 5.5). Dans la figure 5.6, Q min représente la quantité minimale duproduit qu’on peut transporter dans un segment connectant un acteur et l’acteur suivantdans le même parcours.

Fig. 5.4 - Les trois premiers parcours


112




Fig. 5.5 - Interface de saisie des données nécessairespour trouver la quantité recherchée (Required Quantity)


113




Fig. 5.6 - Solutions proposées par le système


114




b. Coûts des transports relatifs aux parcoursLes coûts des transports dépendent de la quantité prise chez les acteurs appartenant à unparcours et de la distance entre eux. Le distributeur a besoin d’un véhicule de 8T - 14T /

35m3 pour transporter la quantité commandée. Cette dernière pèse environ 12 Tonnes.Le tableau 5.4 montre les coûts des transports relatifs aux 4 premiers parcours incluant 3acteurs. La figure 5.7 illustre graphiquement ces coûts.

Tab. 5.4 : Coûts des transports relatifs aux 4 premiers parcours incluant 3 acteurs


115




Fig. 5.7 - Coûts des transports relatifs aux 4 premiers parcours

c. Interprétation des résultats∙ Nous remarquons que même si la quantité recherchée ne peut pas être trouvée chez

un seul grossiste, on peut la rassembler chez les deux grossistes scm26 (Ourzazate)et scm23 (Marrakech). C’est la seule solution qui correspond à un parcours de deuxgrossistes (figure 5.6). Cette solution n’est pas satisfaisante puisque la distance duparcours est égale à 687km. En effet, les coûts de transport seront élevés.

∙ Pour les parcours incluant trois grossistes, on a 12 choix. Les distances (323km ;343km) des deux premiers parcours (Tetouan→Chefchaouen→Meknes→Fès;Tanger→Tetouan→Chefchaouen→Fès) sont proches de 289km (distance entrele distributeur concurrent et le demandeur). Nous remarquons aussi que les coûtsdes transports des 4 premiers parcours sont proches. Pour choisir un parcours, Ledistributeur peut recourir aux céfficients de proximité collaborative ou bien privilégierle parcours incluant des villes liées par des autoroutes. Certainement, Ces quatresolutions sont plus avantageuses que celle adoptée par le distributeur, car si lescoûts de transport sont proches, les prix d’achat chez les grossistes collaboratifset appartenant à la même CL seront inférieurs à ceux offerts par le distributeurconcurrent.

Ainsi, on démontre bien que le distributeur avait quatre solutions meilleures que celleadoptée. On peut conclure que plus le nombre d’acteurs constituant un parcours et laquantité recherché sont grands, plus le nombre de choix est important. Ce scénariomontre un cas d’utilisation réelle. Sur le terrain, plusieurs situations d’urgences existent etdépendent principalement du secteur d’activité.

5.3. Expérimentation : Simulation du processus CPFRLe processus CPFR (Collaborative Planning, Forecasting and Replenishment) est déjàprésenté dans le chapitre 1 (cf. 1.4.2(c)). L’annexe A.2 montre les étapes détaillées de sa


116




mise en place. Dans cette section, nous allons présenté les résultats de simulation de ceprocessus dans l’architecture proposée afin d’évaluer l’importance de sa mise en œuvre.

Nous avons considéré un cas particulier de supply chain des industries du textile et del’habillement comprenant une entreprise centrale (maison-mère) et deux filiales F1 et F2situées en trois pays différents. Les fonctions d’approvisionnement en matières premières,de fabrication et de distribution vers les stocks sont réalisées par l’entreprise centrale. Lesfonctions de vente et de distribution aux grossistes sont à la charge des filiales. La filialeF1 distribue les produits à deux grossistes concurrents, tandis que la filiale F2 distribueles produits à deux grossistes non concurrents situés dans deux zones géographiquesdifférentes. Chacun de ces deux derniers utilise le protocole CPFR pour collaborer avecson distributeur (filiale F2), alors que les deux grossistes concurrents ne collaborent pasavec leur distributeur (même filiale F1) puisqu’ils craignent la diffusion de leurs informationsstratégiques.

Nous avons représenté les clients finaux par un agent qui passe aux grossistes deuxtypes de commandes :

∙ Commandes pseudo-cycliques concernant un produit P1.∙ Commandes aléatoires uniformes liées au stade de commercialisation d’un nouveau

produit de mode noté P2.

Au cours de la simulation, nous avons calculé l’indicateur de performance : nombre descommandes livrées en retard par les deux filiales, qui traduit une rupture en linéaire chezles grossistes. Le tableau 5.5 montre les résultats obtenus pendant la durée de simulation.

Tab. 5.5 : Indicateurs de performance

Analyse des résultats :∙ Pour le produit P2, nous remarquons que la filiale F2 a livré seulement 4 commandes

en retard devant 11 livrées par F1. La différence entre les deux nombres estrelativement importante. Ceci montre très bien que la filiale F2 et ses grossistes ontbénéficié de prévisions de ventes et de commandes plus précises puisqu’ils mettenten œuvre le processus CPFR, surtout que la nature des commandes du produit P2est aléatoire uniforme. Ce type de commandes est relativement difficile à maîtriser,car les acteurs (maison-mère, filiales et grossistes) n’ont pas l’idée du comportementdu produit sur le marché. C’est le cas de plusieurs produits de mode dans le domainedu textile et d’habillement.

∙ Pour le produit P1, la filiale F2 a livré une seule commande en retard devant 4 livréespar F1. La différence n’est pas relativement grande, car les commandes concernant


117




le produit P1 et passées par le client final sont pseudo-cycliques. C’est-à-dire qu’auniveau des acteurs, les variations de ces commandes sont connues. C’est le cas deplusieurs produits de textile et d’habillement dont la demande varie selon les saisonsde l’année (tee-shirt pour la saison d’été, Manteau pour la saison d’hiver, etc).

Nous déduisons donc que le processus CPFR mis en place entre la filiale F2 et sesgrossistes a réduit considérablement le nombre des commandes livrées en retard. Enconséquence, le nombre de rupture en linéaire chez les grossistes sera réduit, ceci setraduira par un bon niveau de service dans l’optique de la fidélisation du client final.

Cette étude de cas qui a pour objectif d’expérimenter les protocoles proposés, nousmontre que lorsque le niveau de collaboration augmente, le nombre des commandes livréesen retard diminue. Le niveau de collaboration peut augmenter en choisissant des pratiqueset méthodes de collaboration reposant sur le partage des données (comme le CPFR) et enintégrant plusieurs acteurs dans la prise de décision.

5.4. ConclusionDans ce chapitre, nous avons présenté le contexte applicatif de notre architecture. Nousavons effectué un cas d’étude concret (gestion des commandes urgentes non prévues)au sein d’une chaîne logistique opérant dans le secteur du sanitaire. Ce cadre industrielnous a donné une idée claire et assez réaliste des limites des différents points des modèlesétablis et de l’architecture proposée dans les chapitres précédents. Les tests réalisés etles résultats obtenus sont très prometteurs et montrent l’intérêt de l’utilisation du modèleproposé pour aider à la prise de décision collaborative dans les chaînes logistiques. Ilparaît qu’en connectant les agents de notre architecture aux systèmes d’informations desacteurs (ERP à titre d’exemple) d’une chaîne logistique, notre architecture apportera uneaide importante dans la prise de décision collaborative en cas de situations d’urgence. Ledeuxième cas d’étude a concerné la simulation du processus CPFR. Nous avons évaluél’importance de sa mise en œuvre. Ceci constitue ainsi en quelque sorte une deuxièmevalidation expérimentale de notre approche.


118




Conclusion générale et perspectives

Les travaux et résultats présentés dans ce mémoire traitent la problématique de la prise dedécision collaborative dans l’environnement des chaînes logistiques. En particulier, lors dela présence des commandes incertaines, des commandes imprécises ou des exceptions(problème de production, problème de transport, erreur sur prévisions, retard de livraison,etc.).

Nous avons ainsi proposé une architecture distribuée basée sur un système multi-agent. Un agent logiciel est vu comme un nouveau paradigme de développementd'applications. Les agents ne définissent pas une nouvelle discipline mais plutôt unenouvelle façon d'envisager l'utilisation des technologies existantes comme outils pourconstruire des applications qui interagissent dynamiquement et communiquent avec leurenvironnement immédiat (utilisateur, ressources locales et système informatique) et d'unemanière (semi-) autonome. Les agents sont connus par leur capacité à aborder lesproblèmes dynamiques et complexes comme le cas d’une chaîne logistique.

Pour répondre à la problématique dégagée dans l’introduction générale et le chapitre1, nous avons commencé par définir explicitement les concepts clés de gestion des chaîneslogistiques et leurs composantes coopératives. Nous avons présenté une synthèse sur lesoutils et les pratiques collaboratives permettant d’améliorer la collaboration entre les acteursd’une chaîne logistique. Nous avons ainsi pu témoigner la présence de quelques faiblessesdans ces derniers, surtout au niveau de la robustesse et la gestion des situations d’urgencescausées par les exceptions pouvant altérer le fonctionnement normal de la chaîne et dévierainsi son état planifié. Ensuite, nous avons montré différents projets concernant l’utilisationdes systèmes multi-agent dans la chaîne logistique. Nous avons relevé le manque deméthodologies et de modèles génériques pour les chaînes logistiques en utilisant lessystèmes multi-agent. Nous avons ainsi témoigné du faible nombre de travaux relatifs àces sujets.

De là, nous avons proposé un modèle quasi-générique qui convient à un grand nombrede chaînes logistiques ou groupements d’entreprises. Ce modèle est fondé sur les conceptsd’agents et d’interactions, il pourra être configuré selon la chaîne logistique étudiée et le typede collaboration à mettre en place. La spécificité de ce modèle est qu’il traite les situationsd’urgences. Nous avons aussi proposé une approche méthodologique à suivre afin dedélimiter la structure et le périmètre de la chaîne logistique à modéliser. Ceci a conduità l’identification de 4 agents (App, Fab, Liv et AgentSCM) nécessaires pour modéliserchaque acteur. Chacun de ces agents, cherche à coopérer avec les autres pour augmenterle nombre de scénarios possibles devant une situation d’urgence. Nos agents sont aussicapables de s’adapter et d’apprendre de leur environnement, en particulier, ils collectentles stratégies chez les managers et les décideurs, cherchent les données nécessaires etprécises pour construire une base de règles permettant de bien coordonner les décisions.Puis, nous avons proposé et modélisé quelques protocoles de négociation et d’échangesutilisés par ces agents.

Nous avons présenté le contexte applicatif et validé l’architecture proposée par le biaisde simulations basées sur des données réelles d’une chaîne logistique. Une autre simulationa concerné l’évaluation de l’importance du processus CPFR. Les différents cas étudiés ont

Conclusion générale et perspectives

119




montré l’apport des agents dans la collaboration entre acteurs de la chaîne et l’intérêt qu’ilsapportent au niveau de l’aide à la décision distribuée. Les agents de notre architecturefacilitent et automatisent les négociations entre clients/fournisseurs. Ceci contribue à lapropagation de l'impact d'une nouvelle donnée sur l'ensemble de la chaîne logistique et deprocéder rapidement à une replanification lorsqu'un aléa survient.

Aux termes de ce travail, nous envisageons deux catégories d’extension:

∙ la finalisation de la mise en œuvre de notre architecture au cas des chaîneslogistiques travaillant dans le secteur du sanitaire et le maintien de celle-ci dans letemps ;

∙ l’application du modèle proposé à une chaîne logistique plus étendue incluant desusines de fabrication, des distributeurs et des grossistes. Cela nous permettrade prendre en compte des coûts supplémentaires engendrés par une dimensioninternationale de la chaîne et par des stratégies de commande et de gestion destocks non homogènes.

Concernant la continuité du déploiement de l’architecture proposée, nous identifionsplusieurs thèmes :

∙ développer une bibliothèque de classes pour assurer la connexion des agentsavec un grand nombre de systèmes d’informations utilisés par les industriels. Nousenvisageons pour cela de travailler parallèlement avec des éditeurs de systèmesd’informations et des entreprises pour lesquelles la problématique de la gestiondes commandes imprécises, des commandes incertaines et des exceptions estimportante ;

∙ poursuivre le travail sur l’adaptation et l’apprentissage des agents.


120




Bibliographie

A

[Akoulchina et Ganascia, 1998] Akoulchina, I., Ganascia, J. G. SAGE Agent for theSATELIT Web Based System. Dans les actes deWebSim'98, San-Diego, Californie, Etats-Unis, 1998

[Arnold, 1996] Arnold, J. Production Planning and control within SupplyChains. IT and Manufacturing Partnerships, pp: 139-148,1996

B

Bibliographie

121




[Baglin et al., 2001a] Baglin, G., Bruel, O., Garreau, A., Greif, M. et Delft, C.Management Industriel et Logistique. Collection Gestion,Série: Productique et techniques quantitatives appliquéesà la gestion, Economica, pp: 323-340, 2001

[Baglin et al., 2001b] Baglin, G., Bruel, O., Garreau, A., Greif, M. et Delft, C.Management Industriel et Logistique. Collection Gestion,Série: Productique et techniques quantitatives appliquéesà la gestion, Economica, pp: 493-497, 2001

[Barbuceanu et Fox, 1995] Barbuceanu, M., Fox, M. Cool: A language for describingcoordination in multi-agents systems. In Proceedings ofthe first International Conference on Multi-agent Systems,1995

[Barbuceanu et Fox, 1996] Barbuceanu, M., Fox, M. Coordinating multiple agents inthe supply chain. In Proceedings of the Fifth Workshops onEnabling Technology for Collaborative Entreprises, WETICE’96, IEEE Computer Society Press, pp: 134-141, 1996

[Bauer et al., 2001] Bauer, B., Bergenti, F., Massonet, Ph. et Odell, J. Agentsand the UML: a unified notation for agents and multi-agent systems. In Proceeding of the AOSE 2001, Springer,Montreal, 2001

[Bauer et Müller, 2004] Bauer, B., Müller, J.P. Methodologies and modelinglanguages. In: Luck, M., Ashri, R., D’Inverno, M. (Eds.),Agent-Based Software Development. Artech HousePublishers, Boston, London, 2004

[Bauer et Odell, 2005] Bauer, B., Odell, J. UML 2.0 and agents: how to buildagent-based systems with the new UML standard.Engineering Applications of Artificial Intelligence, vol. 18,pp: 141-157, 2005

[Baumgaertel et al., 2001] Baumgaertel, H., Brueckner, S., Parunak, V., Vanderbok,R., et Wilke, J. Agent Models of Supply NetworkDynamics. The Practice of Supply Chain Management,2001

[Beck et Fox, 1994] Beck, J., Fox, M. Supply chain coordination via mediatedconstraint relaxation. In Proceedings of the First CanadianWorkshop on Distributed Artificial Intelligence, Banff,Canada, pp: 61-72, 1994

[Bellifemine et al., 1999] Bellifemine, F., Poggi, A., Rimassa, G. JADE - A FIPA-compliant agent framework. CSELT internal technicalreport, et dans Actes de PAAM'99, London, pp: 97-108,Avril 1999

[Botta-Genoulaz et al., 2005] Botta-Genoulaz, V., Millet, P. A., et Grabot, B. A survey onthe recent research literature on ERP systems. Computersin Industry, vol. 56, issue : 6, pp: 510–522, 2005

[Boulanger et al., 1995] Boulanger, D., Colloc, J., Dubois, C., et Wintergerst,C. Objets-agents : Continuum ou différences. Actesdes troisièmes journées francophones sur l’IAD et lessystèmes multi-agents, 1995

[Bournez et Gutknecht, 2001] Bournez, C., Gutknecht, O. Modèle de contrôle parémergence de coordination dans un réseau de contratsmultiagents. In Journées Francophones de l’IntelligenceArtificielle Distribuée et des Systèmes MultiAgents,Montréal, Québec, Canada. 2001

[Briot et Demazeau, 2001] Briot, J.P., Demazeau, Y. Systèmes Multi-Agents.Principes et architectures. Collection IC2. Hermes SciencePublications, 2001

C


122




Bibliographie

123




[Caire et al., 2001] Caire, G., Leal, F., Chainho, P., Evans, R., Garijo, F.,Gomez-Sanz, J. J., Pavon, J., Kerney, P., Stark, J., &Massonet, P. Agent Oriented Analysis using MESSAGE/UML. Second International Workshop, AOSE 2001,Montreal, Canada, May 29, 2001. Revised Papers andInvited Contributions. LNCS 2222. Springer-Verlag, pp:119-135, 2001

[Camalot, 2000] Camalot, J.P. Aide à la décision et à la coopération engestion du temps et des ressources. Thèse de Doctorat,Institut National des Sciences Appliquées de Toulouse,Toulouse, France, 2000

[Campagne et Burlat, 2001] Campagne, J.P., Burlat, P. Maîtise et organisation des fluxindustriels. Ed. Lavoisier, ISBN : 2-7462-0296-4, 2001

[Campagne et Sénéchal, 2002] Campagne, J.P., Sénéchal, O. Les nouvelles exigencesde la coopération, Coopération et connaissance dans lessystèmes industriels sous la direction de R. Soënen et J.Perrin. Lavoisier, Hermes Science, pp: 51-67, 2002

[Carlsson et Fullér, 2001] Carlsson, C., Fullér, R. Reducing the bullwhip effect bymeans of intelligent, soft computing methods. Dans lesactes de 34th Hawaii international conference on systemsciences, 2001

[Charton, 2003] Charton, R. Des agents intelligents dans un environnementde communication multimédia : vers la conception deservices adaptatifs. Thèse de doctorat, Université HenriPoincaré Nancy 1, 2003

[Chehbi, 2007]. Chehbi, S. Modélisation et Simulation des ProcessusCollaboratifs dans les Chaînes Logistiques: Une ApprocheMulti Agents. Thèse de doctorat, Université LUMIERE-LYON II, 2007

[Chehbi et al., 2003] Chehbi S., Derrouiche R., Ouzrout Y. et Bouras A. Multi-Agent Supply Chain Architecture to Optimize Distributed

Decision Making. Proceedings of the 7th World Multi-conference on Systemics, Cybernetics and informatics,SCI, 16, Orlando, USA, 2003

[Chmiel et al., 2004] Chmiel, K., Tomiak, D., Gawinecki, M., Karczmarek, P.,Szymczak, M. et Paprzycki, M. Testing the efficiencyof JADE agent platform. In Proceedings of the 3rdinternational symposium on parallel and distributedcomputing, Cork, Ireland, pp: 49–57. Los Alamitos, CA:IEEE Computer Society Press, 2004

[Christopher, 1992] Christopher, M. Logistics and Supply Chain Management.Pitman Publishing, London, 1992

[Cloutier et al., 2001] Cloutier, L., Frayret, J-M., D’Amours, S., Espinasse, B.et Montreuil, B. A commitment-oriented framework fornetworked manufacturing coordination. Internationaljournal of computer integrated manufacturing, 14(6), pp:522-534, 2001

[Colin, 2003] Colin, R. Formation à la gestion des chaînes logistiques.Supports de formation, 2003

[CXP, 2001] www.cxp.fr

D

http://www.cxp.fr/


124




[Davis, 1993] Davis, T. Effective supply chain management. SloanManagement Review, vol. 34(4), pp: 35-46, 1993

[DeLoach et Wood, 2000] DeLoach, S., Wood, M. Developing Multiagent Systemswith agentTool. en Y. Lesperance & C. Castelfranchi,editores, Intelligent Agents VII - Proceedings of the 7thInternational Workshop on Agent Theories, Architectures,and Languages (ATAL’2000), 2000

[Deloach et al., 2001] Deloach, S., Wood, M. et Sparkman, C. MultiagentSystems Engineering – MaSE. The International Journalof Software Engineering and Knowledge Engineering, vol.11(3), 2001

[Demazeau, 1995] Demazeau, Y. From Interactions To Collective BehaviourIn Agent-Based Systems. Proceedings of the FirstEuropean Conference on Cognitive Science, Saint Malo,France,pp:117-132, Avril 1995

[Demazeau et Müller, 1991] Demazeau, Y et Müller, J.-P. From Reactive to IntentionalAgents. Dans Decentralized A.I. 2, Y.Demazeau & J.P.Müller Eds, Elsevier 1991

[Despontin, 2004] Despontin-Monsarrat, E. Aide A La Décision PourUne Coopération Inter-Entreprises Dans Le Cadre DeLa Production A La Commande. Thèse de doctorat,Univérsité de Toulouse 3 Paul Sabatier, Toulouse France,décembre 2004

[Drogoul, 1993] Drogoul, A. De la simulation multi-agents à la résolutioncollective de problèmes. Une étude de l’émergence destructures d’organisations dans les systèmes multi-agents.PhD thesis, Université Paris VI. 1993

[Drogoul, 1995] Drogoul, A. When Ants Play Chess (Can StrategiesEmerge from Tactical Behaviors?, dans le livre ‘Fromreaction to cognition’, C. Castelfranchi et J. P. Müller, Ed.Springer-Verlag, Berlin Allemagne, ISBN 3-540- 58698-9,1995

[Drogoul et al., 2002] Drogoul, A., Vanbergue, D. et Meurisse, T. Multi-AgentBased Simulation: Where are the Agents? dans lesactes de 3rd International Multi-Agent Based Simulation(MABS'02), Bologne, Italy, pp : 1-15, 15-16 Juillet 2002

[Doche et al., 1999] Doche, F., Djorno, Y. et Douilly, N. L’art de l’entreprisemondiale, Module 8 : Fidéliser le client mondial. FinancialTimes Limited et Editions Village Mondial, Paris, pp :207-234, 1999

E

Bibliographie

125




[Eymery, 1997] Eymery, P. La logistique de l’entreprise-Supply chainmanagement. Ed. Hermés, Paris France, ISBN :2-86601-589-4, 1997

F

[Fargier et al., 2002] Fargier, H., Thierry, C. The use of possibilistic decisiontheory in manufacturing planning and control; RecentResults in Fuzzy Master Production Scheduling. Dans lelivre de ‘Scheduling under fuzziness’, R. Slowinski and M.Hapke, Ed. Springer-Verlag, pp. 45-59, 2002

[Ferber et Gutknecht, 1998] Ferber, J., Gutknecht, O. A Meta-Model for the Analysisand Design of Organizations in Multi-Agent Systems.Proceedings of the Third International Conference onMulti- Agent Systems (ICMAS98), IEEE CS Press, pp:128-135, 1998

[Ferber, 1995] Ferber, J. Les systèmes multi-agents. Vers une intelligencecollective. InterEditions, Paris, 1995

[FIPA, 1997] FIPA. Foundation for Intelligent Physical Agents.Specifications, 1997. http://www.fipa.org/

[FIPA, 2003] FIPA. Foundation for Intelligent Physical Agents.http://www.fipa.org/repository/ips.php3

[FIPA, 2002a] Foundation for Intelligent Physical Agents. FIPA ACLMessage Structure Specification. (On http://www.fipa.org/specs/fipa00061/SC00061G.html ), 2002

[FIPA, 2002b] Foundation for Intelligent Physical Agents. FIPACommunicative Act Library Specification. (On http://www.fipa.org/specs/fipa00037/SC00037J.html ), 2002

[Florea, 2002] Florea, A. Using Utility Values in Argument-basedNegotiation. In Proceedings of IC-AI'02, the 2002International Conference on Artificial Intelligence, LasVegas, Nevada, USA, pp: 1021-1026, 2002

[Franklin et Graesser, 1996] Franklin, S., Graesser, A. Is it an Agent, or just aProgram? A Taxonomy for Autonomous Agents.Proceedings of the Third International Workshop on AgentTheories,Architectures, and Languages. Springer-Verlag,1996

[Fox et al., 2000] Fox, M. S., Barbuceanu, M., et Teigen, R. Agent-orientedsupply chain management. The International Journal ofFlexible Manufacturing Systems, vol. 12, pp: 165–188,2000

G

http://www.fipa.org/

http://www.fipa.org/specs/fipa00061/SC00061G.html

http://www.fipa.org/specs/fipa00061/SC00061G.html

http://www.fipa.org/specs/fipa00037/SC00037J.html

http://www.fipa.org/specs/fipa00037/SC00037J.html


126




[Gasser et al., 1987] Gasser, L., Braganza, C. et Herman, N. MACE: A flexibletestbed for distributed AI, Pitman, 1987

[Geneste et al., 2000] Geneste, L., Grabot, B. et Moutarlier, P. Scheduling ofheterogeneous data using fuzzy logic in a customer-subcontractor context, Scheduling under fuzziness. Dansle livre ‘Studies in Fuzziness and Soft Computing serie’,Ed. R. Slowinski et M. Hapke, ISBN 1434-9922, Springer-Verlag, 2000

[Gervais, 2003] Gervais, M. ODAC: An Agent Oriented MethodologyBased on ODP. Autonomous Agents and Multi-AgentSystems, vol. 7(3), pp: 199-228, 2003

[Giannoccaro et al., 2003] Giannoccaro, I., Pontrandolfo, P., et Scozzi, B. A fuzzyechelon approach for inventory management in supplychains, European Journal of Operational Research, vol.149(1), pp: 185-196, 2003

[Glaser, 1996] Glaser, N. Contribution to Knowledge Modelling in a Multi-Agent Framework (the CoMoMAS Approach). Thèse del’Université Henri Poincaré, Nancy I, 1996

[Govindu et Chinnam, 2007] Govindu, R., Chinnam, R.B. A generic process-centeredmethodological framework for analysis and design ofmulti-agent supply chain systems. Computers & IndustrialEngineering, vol 53, issue 4, ISSN:0360-8352, pp:584-609, 2007

[Gratacap et Médan, 2001] Gratacap et Médan. Management de la production:Concepts, Méthodes, Cas. Dunod. ISBN 2 10 005229 2,pp 301, 2001

[Gutknecht et Ferber, 2001] Gutknecht, O., Ferber, J. The MADKIT Agent PlatformArchitecture. Infrastructure for Agents, Multi-AgentSystems, and Scalable Multi-Agent Systems: Int.Workshop on Infrastructure for Scalable Multi-AgentSystems, 2000 Revised Papers. LNCS 1887, SpringerVerlag, pp: 48-55, 2001

H

Bibliographie

127




[Hakanson et Wondergem, 1999] Hakanson., B, Wondergem., J. ajouter le titre. http://www.supplychain.org/Chapters/Europe/French/10.htm.

[Hapke et al., 2000] Hapke, M., Slowinski, R. Fuzzy set approach to multi-objective and multi-mode project scheduling underuncertainty. Scheduling under fuzziness, Studies inFuzziness and Soft Computing serie, Ed. R.Slowinski andM. Hapke, Springer-Verlag, pp: 197-221, 2000

[Harding, 1999] Harding, A. Modeling techniques for examining the impactof population ageing on social expenditure. Conferenceon the Policy implications of the Ageing of Australia'sPopulation, Melbourne, 19 Mars 1999

[Harel, 1987] Harel, D. Statecharts: A virtual formalism for complexsystem. Science of Computer Programming, vol. 8, pp:231-274, 1987

[Huget, 2002a] Huget, M.-P. An Application of Agent UML to SupplyChain Management. In Proceedings of Agent OrientedInformation System (AOIS-02), Paolo Giorgini and YvesLespérance and Gerd Wagner and Eric Yu (eds.), Bologne,Italie, 2002

[Huget, 2002b] Huget, M-P. Agent UML Class Diagrams Revisited.In Proceedings of Agent Technology and SoftwareEngineering (AgeS). Bernhard Bauer, Klaus Fischer, JoergMueller and Bernhard Rumpe (eds), Erfurt, Germany, 2002

[Huget et Odell, 2004] Huget, M.-P., Odell, J. Representing Agent InteractionProtocols with Agent UML.Proceedings of the FifthInternational Workshop on Agent-Oriented SoftwareEngineering (AOSE), New York, USA, pp: 15-30, 2004

[Huguet, 1994] Huguet, M.J. Approche par contrainte pour l'aide à ladécision et à la coopération en gestion de production.Thèse de Doctorat, Institut National des SciencesAppliquées de Toulouse, Toulouse France,Décembre 1994

[Hunhns et Singh, 1999] Hunhns, M., Singh, M.P. A Multiagent Treatmentof Agenthood. en Applied Artificial Intelligence: AnInternational Journal, vol. 13(1-2), pp: 3-10, January-March1999

I


128




[Iglesias et al., 1998] Iglesias, C., Garijo, M., Gonzalez J. et Velasco J.Analysis and design of multiagent systems using MAS-CommonKADS. In: M. P. Singh, A. Rao, and M. J.Wooldridge (ed.), Intelligent Agents IV, LNAI 1365,Springer Verlag, pp: 313-326, 1998

J

[JADE, 2008] Java Agent Development framework. http://jade.tilab.com/(last access, Février 2007)

[Jennings, 2000a] Jennings, N. R. On agent-based software engineering.Artificial intelligence, vol. 117(2), pp: 277-296, 2000

[Jennings, 2000b] Jennings, N. R. Agent methodology for softwareengineering. Communication of ACM.

[Jennings, 2001] Jennings, N. R. Automated negotiation: Prospects, methods and challenges. Group Decision and NegotiationJournal, vol. 10(2), pp: 199-215, 2001

[Jiao et al., 2006] Jiao, J., You, X. et Kumar, A. An agent-based frameworkfor collaborative negotiation in the global manufacturingsupply chain network. Robotics and Computer-IntegratedManufacturing, vol. 22(3), pp : 239–255, 2006

[Jouenne et al., 2000] Jouenne, T., Renon, E. et Danquigny, J-F. CPFR,Concepts, carte routière et premiers pilotes internationaux.Edition française, Editions Jouwen, 2000

K

http://jade.tilab.com/

Bibliographie

129




[Kendall, 1995] Kendall, E. A Methodology for Developing Agent BasedSystems for Enterprise Integration, IFIP WorkingConference of TC5 SIG on Architectures for EnterpriseIntegration, Queensland, Australia, November 1995

[Kimbrough et al., 2001] Kimbrough, S.O., Wu, D.J. et Zhong, F. Computers playthe beer game: can artificial agents manage supplychains? Decision Support Systems, vol. 33, issue 3, pp:323-333, 2002

[Kleijnen et Gaury, 2003] Kleijnen, J.P.C., Gaury E. Short-term robustness ofproduction management systems: A case study. EuropeanJournal of Operational Research, vol. 148, pp: 452-465,2003

L


130




[Labidi et Lejouad, 1993] Labidi, S., Lejouad, W. De l’intelligence artificielledistribuée aux systèmes multi-agents. Technical Report,INRIA, 2004

[Letouzey et al., 2001] Letouzey, A., Geneste, L. et Grabot, B. Productionplanning forecasting under uncertainty using possibilitytheory. CASYS 2001, 5th International Conference onComputing Anticipatory Systems, LiegeBelgique, pp:13-18, Aout 2001

[Lamouri, 2006] Lamouri, S. Synchronisation des prises de décisions dansune chaîne logistique: robustesse et stabilité. Mémoired’Habilitation à Diriger des Recherches. École Doctoraled’Informatique et Électronique de Paris. Institut Supérieurde Mécanique de Paris (Supméca Paris), 2006

[Lee et Billington, 1992] Lee, H.L., Billington, C. Managing Supply Chain inventory:pitfalls and opportunities, Slon Management Review, Vol.33(3), pp: 65-73, 1992

[Lee et Billington, 1993] Lee, H.L., Billington, C. Material management indecentralized supply chain, Operations Research, vol.41(5), pp: 835-847, 1993

[Lee et al., 1997] Lee, H.L., V. Padmanabhan et Whang, S. Informationdistortion in a supply chain: The bullwhip effect.Management Science, vol. 43(4), pp: 546-558, 1997

[Liang et Huang, 2005] Liang, W.Y, Huang, C.C. Agent-based demand forecast inmulti-echelon supply chain. Decision Support Systems, vol.42, issue 1, pp: 390-407, 2006

[Lind, 2001] Lind, J. Iterative Software Engineering for MultiagentSystems: The MASSIVE Method. Springer 2001

[Lopez et al., 2001] Lopez, P. et Roubellat, F. Ordonnancement de laproduction. Série productique, Editions Hermès, Traité IC2Informatique –Commande – Communication, 2001

[Luck, 2004] Luck, M., McBurney, P. et Preist, C. A Manifesto for AgentTechnology: Towards Next Generation Computing. Journalof Autonomous Agents and Multi-Agent Systems, vol. 9(3),pp: 203-252, 2001

M

Bibliographie

131




[Maes, 1995] Maes, P. Artificial Intelligence meets Entertainment: LifelikeAutonomous Agents. Communications of the ACM, vol.38(11), pp: 108-114, 1995

[Maturana et al., 1999] Maturana, F., Shen, W. et Norrie, DH. MetaMorph:an adaptive agent-based architecture for intelligentmanufacturing. International Journal of ProductionResearch, vol. 37(10), pp: 2159-2174, 1999

[Minar et al., 1996] Minar, N. e.a. The swarm simulation system: a toolkit forbuilding multi-agent simulations. http://www.santafe.edu/project/swarm

[Monteiro, 2001] Monteiro, T. Conduite distribuée d'une coopération entreentreprises : le cas de la relation donneurs d'ordres– fournisseurs. Thèse de Doctorat, Institut NationalPolytechnique de Grenoble, Grenoble, France, Octobre2001

[Moyaux, 2002] Moyaux, T. Techniques Multi Agents pour la Réductionde l’Amplification de la Demande dans une ChaîneLogistique : Application à l’Industrie Forrestière. Résuméde Thèse, Juillet 2002, Univérsité de Laval, Laval Canada,2002

[Moyaux, 2004a] Moyaux, T. Conception, simulation et analyse de stratégiescollaboratives dans des systèmes multi-agents: le cas dela gestion de chaînes logistiques – Thèse de doctorat,2004

[Moyaux et al., 2004b] Moyaux, T., Chaib-draa, B., et D’Amours, S. An agentsimulation model for the québec forest supply chain’,

Proceedings of the 8th International Workshop onCooperative Information Agents (CIA), 3191, pp: 226-241,Erfurt, Germany, 2004

[Moulin et Brassard, 1996] Moulin, B., Brassard, M. A scenario-based design methodand environment for the development of multiagentsystems, En Proceedings of the 1st Australian WorkshoponDistributed Artificial Intelligence, LNAI 1087 - SpringerVerlag, pp: 216-231, 1996

[Muckstadt et al., 2001] Muckstadt, J., Murray, D., Rappold, J., et Collins, D.Guidelines for collaborative supply chain system designand operation. Information systems Frontiers, vol. 3(4), pp:427-435, 2001

N

http://www.santafe.edu/project/swarm

http://www.santafe.edu/project/swarm


132




[Newell, 1982] Newell A. The knowledge level . Artificial Intelligence, vol.18, pp: 87-127, 1982

[Nfaoui et al., 2006] Nfaoui, E.H., Ouzrout, Y., El Beqqali, O. et Bouras, A. AnApproach of Agent-based Distributed Simulation for SupplyChains: Negotiation Protocols between CollaborativeAgents. Proceedings of the The 20th annual EuropeanSimulation and Modelling Conference, Toulouse, France.EUROSIS Publication ISBN: 90-77381-30-9, pp: 290-295,2006

[Nfaoui et al., 2008a] Nfaoui, E.H, El Beqqali, O., Ouzrout, Y., et Bouras,A. An Approach of Decision-Making Support basedon Collaborative Agents for Unexpected Rush OrdersManagement. International Journal of Information Systemsand Supply Chain Management (IJISSCM), Specialissue (Volume 2, Issue 2) on Collaborative Supply ChainManagement, accepté (à paraître en Janvier 2009).

[Nfaoui et al., 2008b] Nfaoui, E.H., Ouzrout, Y., El Beqqali, O. et Bouras, A.Architecture Distribuée à base d’Agents pour la SimulationProactive et l’Aide à la Décision dans la Chaîne Logistique.7ème Conférence Internationale de MOdélisation etSIMulation (MOSIM’08). Editions Tec&Doc – LavoisierISBN : 978-2-7430-1057-7. Paris, France, vol. 2, pp:1476-1484, du 31 mars au 2 avril 2008

[Nwama et al., 1999] Nwama, H., et al. Zeus: A toolkit for building distributedmulti-agent systems. Applied Artificial Intelligence Journal,vol. 13(1), pp: 129-186, 1999

O

[Ören et al., 2000] Ören, T.I., Numrich, S.K., Uhrmacher, A.M., Wilson, L.F.et Gelenbe, E. Agent-Directed Simulation - Challenges toMeet Defense and Civilian Requirements. Proceedings ofthe Winter Simulation conference, vol. 2, pp: 1757- 1762,2000

[Odell et al., 2001] Odell, J., Van Dyke Parunak, H. et Bauer, B. Representingagent interaction protocols in UML. En P. Ciancariniand M. Wooldridge (eds.), Agent-Oriented SoftwareEngineering - Proceedings of the First InternationalWorkshop (AOSE-2000). Springer- Verlag, 2001

P

Bibliographie

133




[Parunak, 1996] Parunak, H. V. D. Applications of distributed artificial intelligence in industry. In O’Hare, G. M. P. And Jennings,N. R., editors, Foundations of Distributed ArtificialIntelligence, John Wiley et Sons, pp: 71-76, 1996

[Parunak et VanderBok, 1998] Parunak, H. V. D., VanderBok, R. Modeling the extndedsupply network. In ISA-Tech’98 (Houston), IndustrialTechnology Institute, 1998

[Pavón et Gómez-Sanz, 2003] Pavón, J., Gómez-Sanz, J. Agent Oriented SoftwareEngineering with INGENIAS. In: Proc. 3rd InternationalCentral and Eastern European Conference on Multi-Agent Systems (CEEMAS 2003), V. Marik, J. Müller, M.Pechoucek (Eds.), Multi-Agent Systems and ApplicationsII, LNAI 2691, Springer-Verlag, pp: 394-403, 2003

[Pavón, 2006] Pavón, J. INGENIAS : Développement Dirigé par Modèlesdes Systèmes Multi-Agents. Dossier d’Habilitation à Dirigerdes Recherches de l’Université Pierre et Marie CurieSpécialité: Informatique, 2006

[Picard et al, 2002] Picard, G., Bernon, C., Gleizes, M., et Peyruqueou, S.ADELFE: a methodology for adaptive multi-agent systemsengineering. In Petta, P., Tolksdorf, R., and Zambonelli,F., editors, Engineering Societies in the Agents World III:Third International Workshop (ESAW 2002), LNCS 2577,Springer Verlag, pp: 156–169, 2002

[Pinedo et Chao, 1999] Pinedo, M., Chao, X. Operations Scheduling withapplications in manufacturing and services. Editions Mc.Graw-Hill, 1999

[Poirier et Reiter, 2001] Poirier, C.C., Reiter, S.E. Revoir le partenariat d’entreprise,La Supply Chain. Editeurs : C.C. Poirier, S.E. Reiter,Dunod, pp: 285, 2001

[Probert et O’Regan, 2002 ] Probert, A., O’Regan, D. Supply Chain Intelligence. LivreBlanc 2002. Imprimé en France et aux Etats-Unis- PT #WP2031, 2002

R


134




[Rao et Georgeff, 1991] Rao, A. et Georgeff, M. Modeling Rational Agents withina BDI Architecture. Proceedings of the 2nd internationalconference on Principles of Knowledge Representationand Reasoning, pp: 473-484, 1991

[Reynoso, 2004] Reynoso, C. Prise En Compte De Commandes IncertainesEt Imprecises Dans Une Logique MRP2. Dans les actesdes Rencontres Francophones sur la Logique Floue etses Applications (LFA’02),Montpellier – France, pp : 21-22Octobre 2002

[Rota, 1998] Rota, K. Coordination Temporelle de Centres Gérantde Façon Autonomes des Ressources: Application auxChaînes Logistiques Intégrées en Aéronautique. Thèse dedoctorat. Université de Toulouse, France, 1998

[Roy, 2000] Roy, B. Réflexions sur le thème: quête de l’optimum etaide à la décision. Cahier du Lamsade n° 167, UniversitéParis-Dauphine, 2000

S

Bibliographie

135




[Sadeh et al, 1999] Sadeh, N., Hildum, DW., Kjenstad, D. et Tseng, A.MASCOT: an agent-based architecture for dynamic supplychain creation and coordination in the internet economy.Prod Plan Control, vol. 12(3), pp: 212–223, 1999

[Saleh et El-Morr, 2004] Saleh, K., El-Morr, C. M-UML: an extension to UML forthe modeling of mobile agent-based software systems.Information and Software Technology, vol. 46, pp: 219–227, 2004

[Samii, 2004] Samii, A-K. Stratégie Logistique, Supply Chain

Management. Editions DUNOD. 3e edition, pp: 14-15,2004

[Sandip, 2002] Sandip, S. Believing Others: Pros and Cons.ArtificialIntelligence, vol. 142(2), pp: 179-203, 2002

[Schneeweiss, 2003] Schneeweiss, C. Distributed decision making in supplychain management. Int. J. Production Economics, vol. 84,pp: 71–83, 2003

[Simchi-Levi et al., 2000] Simchi-Levi, D., Kaminsky, P. et Simchi-Levi, E. Designingand managing the supply chain: Concepts, Strategies andCase Studies. Editions. McGraw Hill, 2000

[Slimani, 2006] Slimani, A. Zeus: Open Source, Visual Development,Visualisation, Intelligent Agents. Cours de Masterrecherche en Informatique, Univérsité Paris 6 Orsay, ParisFrance, 2006

[Stadtler et Kilger, 2000] Stadtler, H. et Kilger, C. Supply Chain Management andAdvanced Planning. Edition Springer- Verlag, pp: 371,2000

[Supply Chain Council, 2000] Supply Chain Council, Supply Chain Operations Referencemodels, SCOR version 4.0, Edition Supply Chain Council,pp: 214, 2000

[Supply Chain Council, 2006] Supply Chain Council. Overview of SCOR version 7.0.Available on Http://www.supplychain.org

[Swaminathan et al., 1998] Swaminathan J.M., Smith S.F. et Sadeh N.M. ModelingSupply Chain Dynamics: A Multiagent Approach. DecisionSciences, vol. 29(3), pp. 607-632, 1998

[Sycara, 1998] Sycara, K. Multi-Agent Systems. AI Magazine. pp: 85-92,Summer 1998

T


136




[Taylor, 2001] Taylor, D. An Approach to the identification and eliminationof demand amplification across the supply chain. In D.Taylor, D. Brunt, editors, ‘Manufacturing operations andsupply chain management’, ISBN: 1861526040,ThomsonLearning Press, pp. 155-174, 2001

[Tayur et al., 1999] Tayur, S., Ganeshan, R. et Magazine, M. QuantitativeModels for Supply Chain Management. Kluwer AcademicPublishers, 1999

[Teigen et Barbuceanu, 1996] Teigen, R. et Barbuceanu, M. The supply chaindemonstrator. Rapport technique et guide de l’utilisateur,1996

[Telle et al., 2003] Telle, O., Thierry, C. et et Bel, G. Simulation d’une relationclient/fournisseur au sein d’une chaîne logistique intégrée:Mise en œuvre industrielle. 2003

[Terzi et Cavalieri, 2003] Terzi, S., Cavalieri, S. Simulation in the supply chaincontext: a survey. Computers in Industry, Vol. 53(1), pp:3-16, 2003

[Troitzsch, 1997] Troitzsch, K.G. Social science simulation - origins,prospects, purposes. Simulating Social Phenomena. vol.456, pp: 41-54, 1997

V

[Vanbergue et al., 2000] Vanbergue, D., Treuil, J-P. Drogoul, A. Modelling urbanphenomena with cellular automata’, In Applications ofSimulation to Social Science. G. Ballot et G. Weisbuch,eds. Hermes, Paris, France, ISBN 1- 903398-04-5, 2000

[VICS Association, 2006] VICS Association. Web site (last access: April 15, 2006).

W

Bibliographie

137




[Wooldridge et Jennings, 1995] Wooldridge, M., Jennings, N. R. Intelligent agents: Theoryand practice. The Knowledge Engineering review, vol.10(2), pp: 115-152, 1995

[Wooldrige, 1999] Wooldrige, M. Intelligent agents. In Wei, G., editeur,MultiAgent Systems – A Modern Approach to DistributedArtificial Intelligence, The MIT Press, pp: 27-78, 1999

[Wooldridge et al., 2000] Wooldridge, M., Jennings, N. et Kinny, D. The GaiaMethodology for Agent-Oriented Analysis and Design.Journal of Autonomous Agents and Multi-Agent System,vol. 3(3), pp: 285-312, 2000

Z

[Zambonelli et al., 2003] Zambonelli, F., Jennings, N. et Wooldridge, M. DevelopingMultiagent Systems: The Gaia Methodology. ACM Trans.Software Engineering and Methodology, vol. 12(3),pp:317-370, 2003


138




Annexes

Annexe A

GPA et CPFR

A.1 Les phases du déroulement de la GPALa GPA se déroule en cinq phases :

Phase 1 : la plate-forme du distributeur livre ses magasins,Phase 2: la plate-forme envoie, chaque jour, au fabricant, les informations concernant

ses produits (cumul des quantités livrées pour chaque référence),Phase 3: le fabricant, connaissant le stock de la plate-forme ainsi que ses sorties,

peut déterminer un réapprovisionnement optimal. Avant d’effectuer celui-ci, il demandeconfirmation à son client en lui adressant une « proposition de livraison»,

Phase 4 : la plupart du temps celui-ci confirme,Phase 5 : le fabricant livre les quantités proposées.

A.2 Etapes de la mise en place du processus CPFRLe CPFR formalise le processus entre deux partenaires (fournisseurs et distributeurs) parl’utilisation commune d’un plan de prévision, et de réapprovisionnement permettant dereconnaître, répondre et gérer la moindre exception.

Les partenaires ont différentes compétences basées sur leurs stratégies etinvestissements. Ils ont aussi chacun leur propre source d’information et des visionsdifférentes du marché. Le CPFR permet de structurer la vision et la façon de travailler desdeux partenaires.

Le CPFR a pour objectifs principaux :

∙ l’intégration des stratégies commerciales des entreprises partenaires (plancommercial joint) ;

∙ la prise en considération des contraintes opérationnelles de part et d’autre ;∙ l’automatisation des processus d’approvisionnement ;∙ les échanges de données en temps réel ;∙ la résolution des questions liées à la prévision des ventes et des promotions.

Afin de mettre en place un CPFR entre deux partenaires, il est nécessaire de suivre 9 points(figure A.1) [Jouenne et al., 2000] :

Annexes

139




Fig. A.1 - Processus global de mise en œuvre du processus CPFR1. Etablir une relation collaborativeIl s’agit de développer les documents qui seront partagés par les deux partenaires.

Les documents définissent le processus, la façon dont les performances sont mesurées etidentifient le rôle de chaque partenaire.

Les objectifs et buts d’une telle collaboration sont déterminés, ainsi que les ressources(financières, économiques, humaines...) des deux parties, leur système d’information et leurcapacité à contribuer au processus. Le bon résultat d’un CPFR passe par la définition desopportunités, la compréhension de l’impact sur chacune des parties...

Il faut déterminer l’information nécessaire qui doit être partagée, la fréquence de sa miseà jour, les méthodes de prévision, base de données, prendre en compte les éléments de lacollaboration précédente et définir les paramètres des divers engagements du processus.L’établissement des règles pour résoudre les différents et désaccords doit être précisé, ainsique les périodes d’évaluation afin de benchmarker le succès de la relation collaborative


140




et la modifier si nécessaire. La collaboration implique un échange des connaissances, unpartage des avantages mais aussi du risque.

2. Créer un business planLe fournisseur et le distributeur doivent échanger un certain nombre d’information sur

leur stratégie afin de collaborer en développant un Business Plan commun. Les partenairesdoivent appliquer les principes du Category Management pour créer une stratégie departenariat et ensuite définir les objectifs. Ils doivent aussi définir des indicateurs deperformance (taux de rupture, taux de satisfaction client...). Le développement de ceBusiness Plan améliore la qualité de prévision et facilite la communication et coordinationde la CL. Une fois le business plan construit, il doit être approuvé par les deux parties.

3. Créer des prévisions de ventesA ce stade, la base de données des consommations est utilisée pour la prévision des

ventes. Cette base de données est différente suivant les produits. Il est aussi important detenir compte et d’y incorporer la saisonnalité et les évènements qui entraînent une évolutionde la demande (vacances, périodes de promotion...). La prévision des ventes est créée parune des deux parties, puis vérifiée et validée par l’autre. Les résultats sont rassemblés etpartagés entre les deux partenaires.

4. Identifier les exceptions pour la prévision des ventesLes critères d’exception de prévision de vente sont établis dans le plan de collaboration

et définis comme des facteurs qui contrôlent la prévision du processus. Il faut alors identifierles changements et les mises à jour du fournisseur et du distributeur. Il faut regarder chaqueproduit et être à l’écoute du moindre changement. C’est en prenant en compte les exceptionsdans la prévision qu’il y a le moins de possibilité de rupture linéaire.

5. Résoudre/collaborer sur les exceptionsCe cinquième point implique la résolution des exceptions dans la prévision des ventes

en utilisant au maximum les informations de la base de donnée partagée, les emails, letéléphone, les réunions... et en soumettant le moindre changement aux prévisionnistes desventes.

La bonne prévision des ventes et l’échange d’information à ce stade du processusdu CPFR commencent à réduire les risques (de rupture en linéaire) entre fournisseurs etdistributeurs. Chaque partenaire permet à l’autre de regarder à ses ventes, ses actionsmarketing et à différentes activités de la CL. La clef de la réussite est que la prévision soitgérée d’une façon flexible et en réponse à l’environnement dans lequel une évaluation del’impact sur le partenaire peut être mesurée.

6. Créer une prévision de commandesDans le court terme, la prévision est utilisée pour la création d’une commande tandis

que dans le long terme, elle est utilisée pour la planification.La prévision des commandes permet à l’industriel d’approvisionner sa capacité de

production tout en minimisant ses stocks. Cela donne aussi au distributeur une meilleureconfiance que sa commande sera correctement livrée (dans les quantités et temps prévus).

Tout d’abord, ensemble, fournisseur et distributeur fournissent une prévision de vente.Ensuite, le distributeur donne au fournisseur des informations sur le niveau de ses stocks(quantités en commandes, en stock...) et l’industriel informe le distributeur de sa capacitéde production, l’historique de sa production, de ses lead times...Puis ils regroupent toutesces informations et en extraient tous les éléments leur permettant de constituer au mieux

Annexes

141




des prévisions de commande. De plus, la collaboration en temps réel réduit l’incertitudeentre les partenaires. Il en résulte une baisse des stocks et une augmentation du taux deservice client.

7. Identifier les exceptions pour la prévision des commandesLes fournisseurs et les distributeurs doivent identifier tout changement et mises à

jour pouvant impacter le processus. Ensuite ils extraient de ces informations les critèresd’exception. Les critères d’exception pour la prévision de commandes sont établis et définisdès la mise en place de la collaboration entre les partenaires. Ensemble, ils comparentchaque élément afin de pouvoir corriger ou prévenir une exception.

8. Résoudre et collaborer sur les éléments d’exceptionLes résultats de ce huitième point sont les conclusions des négociations entre

fournisseur et distributeur. Les éléments des exceptions sont extraits des bases de donnéesde l’industriel et du distributeur. Ils sont ensuite analysés conjointement par les deuxpartenaires. Si la recherche change la prévision et/ou résout les exceptions, alors lesrésultats seront soumis à la prévision des commandes.

9. Générer une commandeCe dernier point est la dernière étape : il marque la transformation d’une prévision de

commande à l’engagement d’une commande certaine. En effet, les prévisions sont validéeset se transforment en réelles commandes.

La commande est créée puis transmise. Si le fournisseur crée la commande, ledistributeur en a connaissance immédiatement et inversement. A ce stade tout le travail aété fait en amont pour éviter toute exception pouvant causer une rupture en linéaire.

Avantages du CPFR∙ Pour les distributeurs

En premier lieu, la mise en place du CPFR engendrera pour les distributeurs une baissedes stocks et donc une réduction significative des coûts. En effet, le réapprovisionnementautomatique implique des livraisons plus fréquentes et donc des niveaux de stocks plusfaibles.

L’avantage majeur pour les distributeurs qui les incite à mettre en place ce processusest la réduction des ruptures en linéaire grâce au réapprovisionnement automatique et àla fiabilité des prévisions. Celles-ci proviennent d’un travail collaboratif entre producteurs etdistributeurs, effectué en amont et sur l’ensemble de la chaîne logistique.

On pourra également noter le fait que disposer d’un outil de planification etde réapprovisionnement performant leur permettra de développer le processus dedifférenciation retardée et donc d’atteindre un niveau de service optimal dans l’optique dela fidélisation client.

∙ Pour les fournisseurs

La mise en place du CPFR leur permet de bénéficier de prévisions de ventes plus précisespour leurs produits. Ainsi, ils pourront mieux planifier leur production et donc réduireleurs stocks, ce qui engendrera une baisse significative des coûts. Tout comme pour lesdistributeurs, le CPFR diminuera les différents coûts administratifs. Cela leur permettra


142




également de pouvoir mieux faire face aux demandes imprévues et de réduire les rupturesde stock.

Annexe B

Les différentes actions de communication de FIPA-ACLLes agents communiquent entre eux en échangeant ce qui peut représenter des actes delangage. Le tableau B.1 ci-dessous présente quelques actes du langage de communicationFIPA-ACL.

Tab. B.1 : Actes du langage de communication FIPA-ACL

Annexes

143




Actions Syntaxe DéfinitionAccept Proposal accept-proposal Communication de l'accord de l'expéditeur

d'effectuer une action qui lui a été préalablementsoumise.

Agree agree Communication de l'accord de l'expéditeur poureffectuer une action, sans doute dans le futur.

Cancel cancel Communication de l'annulation de l'accord donnéepréalablement par l'expéditeur pour effectuer uneaction.

Call for Proposal cfp Communication par l'expéditeur d'une demanded'effectuer une certaine action.

Confirm confirm Communication par l'expéditeur de la confirmationde la validité (selon les règles de l'agent) de laproposition préalablement reçue.

Disconfirm disconfirm Communication par l'expéditeur de la confirmationde la non validité (selon les règles de l'agent) de laproposition préalablement reçue.

Failure failure Communication par l'expéditeur de l'échec d'uneaction essayée.

Inform inform Communication par l'expéditeur d'une proposition,pensée vrai par celui-ci.

Inform If inform-if Communication par l'expéditeur d'une proposition(pensée vrai par celui-ci), et demande audestinataire une confirmation ou une non-confirmation. Macro-action impliquant l'usage de« request ».

Inform Ref inform-ref Communication par l'expéditeur d'une demande del’objet qui correspond à une description envoyée. Macro-action impliquant l'usage de « request ».

Not Understood not-understood Communication par l'expéditeur d'une noncompréhension d'une action effectuée par ledestinataire.

Propagate propagate Communication par l'expéditeur d'un messageà propager à des agents dont la descriptionest fournie. Le destinataire du message traitele sous-message à propager comme s'il luiétait directement destiné et envoie le message« propagate » à l’agent qu'il a identifié.

Propose propose Communication par l'expéditeur d'une propositiond'action conditionnée à certaines préconditionsdonnées.

Proxy proxy Communication par l'expéditeur d'une demanded'une transmission d'un message à des agentsdont la description est donnée.

Query Ref query-ref Communication par l'expéditeur d'une demandepar l'expéditeur de l'objet référencé par uneexpression.

Refuse refuse Communication par l'expéditeur de son refusd'effectuer une action donnée, et en donne lesraisons.

Reject Proposal reject-proposal Communication, pendant une négociation, parl'expéditeur de son refus d'effectuer des actions.

Request request Communication par l'expéditeur d'une demande audestinataire d'effectuer une action.

Request When request-when Communication par l'expéditeur d'une demande,au destinataire, d'effectuer une action quand uneproposition donnée devient vraie.

Request Whenever request-whenever Communication par l'expéditeur d'une demande,au destinataire, d'effectuer une action dès qu'uneproposition donnée devient vraie, et à chaque foisque celle-ci redevient vrai.

Subscribe subscribe Communication par l'expéditeur d'une demanded'un objet donné par une référence envoyé parl'expéditeur, et de renotifier l'agent ayant souscritdès que l'objet en question change.

Annexe C


144




Systèmes de gestion de stockLes règles de gestion de stock consistent à définir des politiques de réapprovisionnement :déterminer à quel moment on passe des commandes et quelle quantité on commande.Les deux systèmes de gestion de stock les plus fréquents sont : Le système à point decommande et le système à recomplètement périodique. Il existe des variantes de ces deuxsystèmes de base comme le système à point de commande périodique et le système àrecomplètement périodique avec seuil.

C.1 Système à point de commandeLe système à point de commande consiste à commander une quantité fixe Q à chaque foisque le stock disponible descend à un niveau déterminé, dit point de commande (figure C.1).Cette commande est réceptionnée à l’issue d’un délai d’obtention, d 0 . La date de passationde commande est donc variable : si la demande est plus forte, le point de commande seraatteint plus tôt ; si la demande est ralentit, le point de commande sera atteint plus tard.

Fig. C.1 - Système à point de commande

C.2 Système à recomplètement périodiqueLe principe du second système de base (figure C.2) est le suivant. A périodicité fixe,appelée période de révision et notée Pr, on constate le niveau de stock disponible. On leramène alors, par une commande de réapprovisionnement, à un niveau fixe dit niveau derecomplètement, noté Nr. Cette commande est réceptionnée après un délai d’obtention, d0 . La quantité commandée à la fin de chaque période fixe est donc égale à la différenceentre le stock disponible et le niveau de recomplètement. Sauf exception, cette commandeest habituellement égale à la demande de la période précédente.

Annexes

145




Fig. C.2 - Système à recomplètement périodique

C.3 Système à point de commande périodiqueLe principe de ce système est le suivant : une commande ne peut être passée qu’à unedouble condition,

∙ comme dans un système à point de commande, le stock doit être descendu au-dessous du point de commande,

∙ comme dans un système à recomplètement périodique, les commandes sont passéesà dates fixes.


146




Fig. C.3 - Système à point de commande périodique

C.4 Système à recomplètement périodique avec seuillLe principe de ce système est le suivant : à la fin de chaque période de révision, on examinele niveau du stock. On ne passe une commande que si ce niveau est inférieur à un seuilprédéterminé. Cela évite de passer des commandes de trop petites tailles si la demandependant la période a été très faible.

La figure C.4 illustre le comportement d’un tel système : à la date t1, le seuil est franchiet on passe une commande alors qu’à la date t2, le seuil n’étant pas franchi, on ne passepas de commande et on attend la période t3.

Annexes

147




Fig. C.4 - Système à recomplètement périodique avec seuil


148




Résumé

Dans cette thèse, nous abordons le problème de la prise de décision collaborative dansl’environnement des chaînes logistiques. En particulier, lors de la présence des commandesincertaines, des commandes imprécises ou des exceptions (problème de production,problème de transport, erreur sur prévisions, retard de livraison, etc.). Le comportementglobal de la chaîne logistique résulte des comportements individuels des acteurs qui lacomposent et des interactions entre eux. Ces acteurs sont relativement autonomes etinteragissent entre eux et avec leur environnement. En plus, chaque acteur de la chaînelogistique poursuit ses buts individuels tandis qu’il satisfait à ses contraintes locales etexternes. Cette vision naturellement distribuée d’une chaîne logistique se prête bien à unedémarche d’analyse orientée agents.

Après une étude bibliographique détaillée sur la chaîne logistique et les systèmes multi-agent, nous proposons un modèle quasi-générique qui convient à un grand nombre dechaînes logistiques ou groupements d’entreprises. Ce modèle est fondé sur les conceptsd’agents et d’interactions. Quatre agents (App, Fab, Liv et AgentSCM) ont été identifiés pourmodéliser chaque acteur. Chacun de ces agents, cherche à coopérer avec les autres pouraugmenter le nombre de scénarios possibles devant une situation d’urgence. Ces agentssont aussi capables de s’adapter et d’apprendre de leur environnement, en particulier,ils collectent les stratégies chez les managers et les décideurs, cherchent les donnéesnécessaires et précises pour construire une base de règles permettant de bien coordonnerles décisions.

Nous avons présenté le contexte applicatif et validé l’architecture proposée par le biaisde simulations basées sur des données réelles d’une chaîne logistique. Une autre simulationa concerné l’évaluation de l’importance du processus CPFR.

Mots clés : Systèmes Multi-Agent, Protocoles de Négociation, Gestion de la ChaîneLogistique, Incertitude des Informations, Simulation Proactive, Agent UML.

Abstract

149




Abstract

This thesis is related to distributed decision making and collaboration within a supplychain context. Mainly, we focus on unexpected swings in demand and on unexpectedexceptions (problem of production, problem of transportation, etc.), which are importantcoordination and communication issues in supply chain management. Supply chain is adistributed environment. Therefore, we apply an agent-based distributed architecture inorder to guarantee the autonomy and the strategic data confidentiality of all participants.Agent technology provides to the distributed environment a great promise of effectivecommunication. An agent is a program that performs a specific task intelligently without anyhuman supervision and can communicate with other agents cooperatively.

After a critical review on supply chain activities and their management and multi-agent systems, we propose a model based on agents and interactions. This model aimsat modeling many supply chains structures. To represent the three main functions of thecompany (source, make and deliver) and consider the control processes in the supplychain and its environment, each actor is modeled by the fourth agents (App, Fab, Liv andAgentSCM). These collaborative agents communicate between them and negotiate usingprotocols. They collect strategies from managers; seek the accurate data and aim at buildinga rule-base for better coordination and better decision-making process.

The usefulness of the model and the distributed architecture has been validated on anindustrial case study (distribution company). The aforementioned company operates in thesectors of toilets and showers (washbasin, baths, etc.), taps, tiling, plumbing and pieces offurniture. Also, a simulation concerns CPFR process is performed in order to evaluate itsbenefit.

Keywords: Multi-agent systems, Negotiation Protocols, Supply Chain Management,Demand uncertainty, Distributed and Proactive Simulation, Agent UML, Rush unexpectedorder.

Documents

Architecture d’aide a la décision distribuée et de