C4

Technologie multiagent

Jacques Ferber Jacques Ferber, MSc Edimbourg, docteur ès sciences, professeur à l’Université Pierre et Marie Curie (Paris VI) est chercheur au laboratoire Laforia du CNRS où il dirige l’équipe Miriad spécialisée dans les systèmes multiagents. Il est aussi président du groupe Afcet sur les systèmes multiagents.

Technologie multiagent

Origines Les systèmes multiagents (SMA) mettent en œuvre un ensemble de concepts et de techniques permettant à des logiciels hétérogènes, ou à des parties de logiciels, appelées “agents” de coopérer suivant des modes complexes d’interaction. La technologie des SMA s’est développée ces dernières années sous une quadruple pression.

Alors que l’idée du “Web” est d’ouvrir un espace de navigation électronique, le concept d’agent et de système multiagent consiste à remplacer l’“outil” informatique par un “collaborateur” autonome, mobile et relativement “intelligent”.

La première est due aux limites de l’intelligence artificielle classique sur le plan de la structuration et de l’organisation des connaissances. La difficulté qu’il y a à traduire un ensemble d’expertises sous une forme unifiée a amené les chercheurs à développer ce que l’on a d’abord appelé des systèmes multiexperts, c’est-à-dire des systèmes mettant en jeu plusieurs bases de connaissances plus ou moins coordonnées. Ce faisant, on a pu constater que le problème de la coopération entre plusieurs bases de connaissances se révélait un enjeu crucial qui dépassait de loin le problème de la multiexpertise. La deuxième trouve son origine dans la nécessité de trouver des techniques de modélisation et de simulation performantes dans le domaine des sciences du vivant au sens large du terme. L’évolution des écosystèmes habités, notamment, montrent qu’il est difficile de rendre compte de leur évolution par un ensemble d’équations différentielles. Une approche dans laquelle les individus sont directement représentés sous forme d’entités informatiques semble une voie prometteuse et a contribué à l’essor du domaine. La troisième provient de la robotique. Le développement de la miniaturisation en électronique permet de concevoir des robots qui disposent d’une certaine autonomie quant à la gestion de leur énergie et à leur capacité de décision. On a pu alors montrer qu’un ensemble de petits robots ne disposant que de capacités élémentaires de décision et d’intelligence pouvait facilement rivaliser avec les performances d’un seul robot “intelligent”, nécessairement plus lourd et plus difficile à gérer. Le problème alors

revient, ici encore, à faire coopérer ces entités de manière à ce qu’elles assurent les fonctions désirées. Enfin, la quatrième est issue du développement de l’informatique et des systèmes distribués en particulier. Avec la généralisation des réseaux et des ordinateurs parallèles, il devient de plus en plus important de pouvoir faire coopérer plusieurs composants logiciels au sein d’environnements hétérogènes et distribués. Le problème ne réside plus dans le contenu des programmes, qui peuvent avoir des fonctionnalités diverses, mais dans leur capacité à collaborer avec d’autres programmes à la réalisation d’un objectif commun. C’est surtout cet aspect que nous retiendrons dans la suite de cet exposé.

De l’outil au collaborateur Le concept de système multiagent est suffisamment novateur pour bouleverser notre approche du travail en général et des techniques d’applications distribuées en particulier. Ces systèmes introduisent une rupture épistémologique dans les relations que nous entretenons avec les systèmes informatiques. Pendant longtemps, et dans le monde informatique notamment, on a vécu dans la métaphore de l’outil. Un outil augmente la puissance d’action de celui qui le manie mais en restant directement lié à ses gestes et à ses commandes. Le mécanisme de contrôle se situe encore dans l’être humain. Les actions à entreprendre ne sont que des extensions de nos diverses capacités : un tableur, par exemple, n’est qu’un grand tableau de nombres qui possède la faculté de faire des opérations. Il ne possède ni désirs, ni intentions, ne sait pas communiquer avec un être humain au même niveau que lui et ne fonctionne pas en dehors des commandes qui lui sont envoyées. La coordination des actions reste donc l’apanage de l’être humain. Un “macrolangage” ne change rien à cette situation. Il ne fait que répéter des suites d’actions stéréotypées.

Le “Minitel”, malgré son intérêt et l’impact qu’il a eu dans la société, demeure dans le cadre conceptuel classique de l’outil. Un utilisateur se connecte à un serveur d’applications informatiques à partir duquel il peut réserver un billet d’avion, commander des articles, obtenir des informations, etc. A chaque fois l’utilisateur est en communication avec une application qui lui fournit un ensemble de fonctionnalités à partir duquel il peut obtenir ce qu’il désire. Ici encore, la machine est passive, attendant les ordres élémentaires que l’utilisateur veut bien lui envoyer. La rupture commence avec Internet, et plus particulièrement avec ce que l’on appelle communément le “Web”. Ce dernier n’offre pas, comme on le pense souvent, un ensemble de services mais un espace de navigation. Malgré son extrême dénuement en termes de fonctionnalités offertes, ce qui commence d’ailleurs à évoluer avec un ensemble de logiciels comme Java, il propose une implémentation effective de ce que Mario Tokoro appelle un “espace électronique” (computational field) [Tokoro 90]. Un espace électronique est simplement une gigantesque zone informatique dans laquelle des processus informatiques interagissent avec d’autres processus de sources hétérogènes. Si, pour l’instant, le Web est essentiellement un système hypertexte, par l’ensemble des capacités qu’il offre, il fournit le support idéal pour l’élaboration de cette “société artificielle” que les écrivains de science-fiction avaient appelé le “cyberspace ”. Mais la rupture devient consommée avec les systèmes multiagents, car ils n’interagissent pas sur le mode de l’outil, mais sur celui du collaborateur. Les agents sont des entités autonomes qui sont mues par des désirs et qui poursuivent leurs propres buts. Ils peuvent communiquer avec d’autres agents (ou avec un utilisateur) dans un langage de haut niveau qui laisse place à l’élaboration d’interactions complexes qui s’apparentent à des négociations commerciales et juridiques.

Vers un “marché électronique” Il faut penser l’univers informatique du futur comme un gigantesque “marché électronique” de services dans lequel des agents vivent (et meurent), interagissent, négocient, se reproduisent en suivant leur propre comportement. Cette façon de penser va remettre en cause notre manière de travailler, en constituant une véritable zone d’activité de travail électronique, qui doublera et aidera la zone d’activité humaine. La rapidité de connexion et de mise en relation des agents leur permettra de réagir à n’importe quelle modification de l’état de l’offre et de la demande en temps réel, beaucoup plus rapidement que ne pourrait le faire un opérateur humain. Il est donc très important de penser dès maintenant à des services favorisant la mise en relation des agents les uns avec les autres si l’on ne veut pas rapidement produire des services obsolètes dans une telle situation. En effet, les réseaux du futur seront très ouverts, tant d’un point de vue technique (connexion facile entre agents hétérogènes, fonctionnement peu sensible aux pannes) qu’économique (proposition et négociation rapide de services, bourses d’échanges de services, contrats avec options de désengagement, etc.). Il ne faut pas penser, par exemple, qu’un agent A ayant négocié un service avec un agent B continuera indéfiniment de travailler avec ce dernier. S’il trouve un autre agent C moins cher qui lui offre les mêmes services que B, il rompra son contrat avec B (si les clauses de ruptures ne sont pas trop coûteuses) pour en établir un autre avec C. Et ce scénario s’effectuera à n’importe quel niveau de service. Avant de présenter les différentes catégories d’applications envisageables avec les SMA, nous devons d’abord nous arrêter sur la notion d’agent et de système multiagent.

La notion d’agent et de système multiagent Agent et système multiagent La notion d’agent, comme tous les concepts fondamentaux, est relativement vague. On peut distinguer plusieurs manières de concevoir et de comprendre la notion d’agent. Chacune de ces notions renvoie à un courant de recherche particulier dans le domaine de ce qui touche à la nébuleuse “agent”.

L’agent comme objet distribué La première, que j’appellerais faible, est surtout tournée vers une conception très “informaticienne” de l’agent, et se situe en contact étroit avec l’implémentation. Dans ce sens, un agent peut être défini comme un objet informatique (au sens des langages objets) dont le comportement peut être décrit par un “script”, qui dispose de ses propres moyens de calcul (un agent est alors associé à un processus léger), et qui peut se déplacer de places en places (une place pouvant être un site informatique distant du site originel de l’agent) pour communiquer avec d’autres agents. C’est cette conception de l’agent qui a été retenue par la société General Magic pour concevoir le logiciel Téléscript. Issu des modèles à objets concurrents en général et des langages d’acteurs en particulier, ce modèle présente l’avantage d’être facilement opérationnalisable. Nous renvoyons à l’article de Jean-Yves Léonnec (dans ce volume) pour la présentation de Téléscript dans le cadre du projet Pyramide de France Télécom. Néanmoins, malgré son intérêt pratique immédiat, ce modèle reste à un niveau trop élémentaire, le concept initial de l’agent, qui repose sur son autonomie de décision et son caractère intentionnel, ayant été quelque peu limité à des critères d’implémentation immédiate. Néanmoins, comme nous le verrons plus loin des langages fondés sur cette approche peuvent être utilisés

pour implémenter des modèles de systèmes multiagents plus complexes.

L’agent comme entité intentionnelle Au contraire, dans la seconde définition, que l’on pourrait qualifier de forte, le concept d’agent prend toute son importance. Dans ce cas, on appelle agent une entité informatique qui [Ferber 95] : n se trouve dans un système informatique ouvert comprenant un ensemble d’applications, de réseaux, et de systèmes hétérogènes, n peut communiquer avec d’autres agents, n est mue par un ensemble d’objectifs propres (c’est en ce sens que l’on peut parler d’agent intentionnel), n possède des ressources propres, n ne dispose que d’une représentation partielle des autres agents, n possède des compétences (services) qu’elle peut offrir aux autres agents, n a un comportement tendant à satisfaire ses objectifs, en tenant compte d’une part des ressources et des compétences dont elle dispose, et d’autre part de ses propres représentations et des communications qu’elle reçoit. Cette définition met l’accent sur l’autonomie de décision qui résulte de l’indépendance avec laquelle un agent tente de satisfaire des objectifs qu’il s’est assigné, en utilisant au mieux les ressources et les compétences dont il dispose.

L’agent en interaction Certains en restent là et considèrent alors que tout est dit. Le problème repose alors sur la caractérisation précise de cette définition et à sa mise en œuvre formelle et pratique. C’est ainsi que tout un courant de chercheurs qui se réclament de l’approche “agent” travaille dans ce sens. Citons Shoham, Georgeff et Rao, Levesque, Cohen et Lesperance, Jennings et Wooldridge, etc., tous étant convaincus que la solution passe directement, et uniquement, par la réalisation formelle d’un modèle d’agent et par son implémentation.

Au contraire, d’autres chercheurs, qui se reconnaissent dans la notion de “système multiagent” (et qui insistent sur le “multi”) considèrent qu’il faut d’abord penser l’interaction et ensuite en déduire la structure intentionnelle des agents et non l’inverse. L’intérêt des systèmes multiagents réside en effet dans la notion d’action collective et dans sa capacité à articuler l’individuel au collectif, par l’intermédiaire de la structure cognitive des agents. Sans remettre en cause l’idée d’agent intentionnel, cette conception “collective” met l’accent sur les structures d’interactions (coopération, négociations, coordination d’actions, conflits, ...) et sur les organisations qui en découlent (rôles, hiérarchies d’autorité, ...).

L’agent comme collaborateur Enfin, la troisième approche est celle de l’agent comme système collaborateur d’un être humain. L’idée sous-jacente est de dire, comme nous l’avions signalé dans l’introduction, que l’interaction entre l’utilisateur et la machine va passer d’une conception des systèmes informatiques comme “outils” à celle de “collaborateur” ou “assistant”. Dans ce cas, l’utilisateur se trouve en face d’un “être” informatique qui dispose de son autonomie en termes d’action, qui interagit “intelligemment” avec lui, qui accomplit un certain nombre de tâches répétitives (telles que la gestion de courrier électronique par exemple) ou qui agit comme un mandataire pour aller “fureter” des informations sur le réseau ou négocier des transactions commerciales. Bien que sa position conceptuelle soit très proche de celle de l’agent comme entité intentionnelle, l’agent collaborateur met l’accent sur le dialogue homme/machine et sur la compréhension, par la machine, des désirs et volontés de l’utilisateur. Par exemple, un agent collaborateur digne de ce nom, doit pouvoir “lire par-dessus l’épaule” de l’utilisateur afin d’apprendre sa façon de travailler, connaître ses préférences et en déduire des règles d’action.

Relation avec la notion d’objet On pose souvent la question de savoir ce qui distingue la notion d’agent de celle d’objet ou d’acteur. La réponse est simple : dans le domaine informatique, les termes “objet” et “acteur” désignent des entités informatiques caractérisées par leur structure et leurs mécanismes d’exécution. La notion d’objet est définie par trois concepts : la relation classe/instance, qui décrit la classe comme un modèle structural et comportemental et l’instance comme un représentant d’un modèle ; l’héritage, qui permet de dériver une classe d’une autre et de faire bénéficier la première des caractéristiques de la seconde ; enfin l’envoi de message, qui permet de définir des procédures polymorphes, c’est-à-dire des procédures dont le code diffère en fonction du receveur du message. Si le concept d’agent comme objet distribué est très proche de celui de l’objet (La notion d’agent Téléscript ajoute, par rapport à celle d’objet, les notions de place et de migration de l’agent, et distingue les communications locales des communications globales, qui ne sont d’ailleurs pas possibles dans la première version de ce langage), il n’en est pas de même de l’agent comme entité intentionnelle. En effet les objets n’ont ni but ni recherche de satisfaction et le mécanisme d’envoi de message se résume à un simple appel de procédure. Il n’y a pas de langage de communication à proprement parler. Les mécanismes d’interaction (comme pour les agents Téléscript d’ailleurs) sont donc à la charge du programmeur. La différence essentielle qui existe entre les objets et les agents (purement communicants) est illustrée figure 1. Un objet est défini par un certain nombre de services (ses méthodes) qu’il ne peut refuser d’exécuter si un autre objet le lui demande et les messages sont donc nécessairement des invocations de méthodes. Le développeur d’un logiciel “objet” doit donc vérifier que tous les

L’individu et sa relation au monde

Figure 1 - Un objet répond directement à des requêtes correspondant à ses méthodes, alors qu’un agent “encapsule” ses compétences (ou services) par des mécanismes supplémentaires qui “filtrent” les communications externes et gèrent les dialogues. De plus, les agents sont mus par des objectifs (ou tendances) personnels.

objets recevront bien des ordres sensés qu’ils seront effectivement capables d’exécuter. Par rapport aux objets, les agents peuvent recevoir des messages qui ne sont pas uniquement des demandes d’exécution mais aussi des informations ou des demandes d’informations sur leurs capacités, etc. De ce fait, les services que peut rendre un objet, sont donc filtrés par une couche logicielle qui découple les demandes et le fonctionnement interne de l’agent. Enfin, comme nous l’avons dit, les agents tentent de satisfaire des objectifs, ce qui leur procure une autonomie supplémentaire par rapport aux objets. En effet, l’agent, à l’encontre de l’objet, peut refuser d’accepter d’effectuer un certain travail, ce refus pouvant s’expliquer par son manque de compétence (il ne possède pas le savoir-faire nécessaire) ou par sa trop grande occupation à une autre tâche ou par toute autre raison. Un agent “encapsule” les méthodes qu’un objet peut offrir sous la forme d’un ensemble de services qui ne sont accessibles que par un langage particulier connu de l’ensemble des agents et qui utilise généralement la théorie des actes de langages. Mais le lien qui existe entre objets et agents ne doit pas non plus être sousestimé. Si un agent purement communicant, peut être considéré comme une sorte d’objet amélioré, inversement, un objet peut passer pour un agent dégénéré, c’est-à-dire un agent dont le langage d’expression se résume à l’emploi des

mots clés correspondant à ses méthodes. Enfin, et c’est d’ailleurs ce qui augmente encore la confusion possible, on implémente souvent, pour des raisons pratiques, les agents sous la forme d’objets ou d’acteurs. Ceci n’est pourtant qu’une des implémentations possibles. On peut de la même manière implémenter des agents en Fortran, C ou Lisp, qui ne sont pas naturellement des langages à objets, sans que cela modifie en quoi que ce soit leur caractère d’agent.

Thèmes de recherches Concevoir un système multiagent, c’est avant tout analyser et résoudre un très grand nombre de problèmes. La conception d’un réseau intégrateur de services par exemple soulève un grand nombre de questions qui recouvrent des domaines très divers. Comment les agents se représentent-ils leur environnement et les autres agents ? Comment coopèrent-ils ? Peuvent-ils assurer leur viabilité ? Sont-ils capables d’adapter leur comportement à des modifications du milieu dans lequel ils évoluent ? Sont-ils pris dans des rapports hiérarchiques ou d’autorités entre eux ? Ces différentes questions peuvent être classées en cinq catégories principales : la problématique de l’action, l’agent et sa relation au monde, l’interaction, l’adaptation, la réalisation et l’implémentation de SMA.

Les différents thèmes relatifs à l’individu portent d’une part sur son architecture et son organisation interne et, d’autre part, sur l’ensemble des moyens qu’il met en œuvre pour assurer sa viabilité et satisfaire ses objectifs. Il s’agit évidemment de thèmes essentiels car la réalisation d’un système multiagent passe nécessairement par la description de l’architecture des agents et des fonctionnalités dont ils disposent pour accomplir leurs tâches. C’est à ce niveau que l’on s’intéresse aux éléments cognitifs dont l’organisation permet la constitution d’un comportement adapté. Sauf pour des agents réactifs simples, un agent se trouve à un certain moment dans un certain “état mental” qui résulte de sa propre histoire, de sa perception du monde et des interactions avec le monde et les autres agents. Ces états mentaux sont souvent très complexes et font intervenir un grand nombre d’éléments dont la combinaison explique le comportement d’un agent “de l’intérieur”. Ces éléments cognitifs sont aux états mentaux des agents ce que les corpuscules élémentaires sont aux corps physiques : des composants de base dont la combinaison permet d’exprimer l’état mental d’un agent et dont les lois d’interaction servent à décrire l’évolution future du comportement d’un agent et de ses états mentaux ultérieurs. Ces éléments cognitifs, régissent l’ensemble des aspects de l’activité intérieure d’un agent : perception et exécution d’action, croyances, désirs et tendances, intentions, méthodes et plans, etc. Par exemple, la notion d’intention est définie formellement ainsi : On dit qu’un agent x a l’intention de faire une action a, ce que l’on note (intention x a) si x a comme but qu’une proposition p portant sur le monde soit vraie (noté (but x p)) et que les conditions suivantes soient satisfaites : n x croit que p appartient aux conséquences de a, n x croit que p n’est pas vrai actuellement,

n x croit qu’il est capable de faire a, n x croit que a sera possible et donc que

p pourra être satisfait.

C’est à ce niveau aussi que sont décrits les engagements. En s’engageant à accomplir une action auprès d’un tiers, l’agent contraint l’ensemble des actions qu’il peut réaliser et donne la possibilité au tiers de planifier son propre comportement en diminuant son incertitude sur l’ensemble des états futurs. La formalisation de cette notion passe par des logiques modales temporelles. Les travaux portant sur la rationalité des agents rationnels, dont nous avons parlé plus haut, s’inscrivent dans ce thème. Les tenants principaux de ces recherches sont essentiellement des Américains (Cohen et Levesque [Cohen & Levesque 1990a ; Cohen & Levesque 1990b], Shoham [Shoham 1993]) des Australiens (Georgeff [Rao & Georgeff 1992]) et des Britanniques (Jennings et Wooldridge [Wooldridge & Jennings 1994]). Il s’agit ici de formaliser l’ensemble des états mentaux d’un agent (essentiellement ses croyances, ses désirs, ses intentions et ses engagements) à partir d’un formalisme logique comprenant des aspects temporels et des modalités. Des modèles d’architecture sont issus de ces travaux. L’école des agents rationnels, malgré l’intérêt des recherches et l’importance des résultats, tend néanmoins à masquer ce qui fait l’originalité des systèmes multiagents, à savoir l’interaction et la coopération. De ce fait, les travaux portant sur les agents rationnels donnent souvent l’impression que les agents sont isolés les uns des autres, les phénomènes de coopération n’étant généralement pris en compte que de façon marginale. Cette école a très peu fait d’émule en France.

L’interaction Pour un agent, interagir avec un autre constitue à la fois la source de sa puissance et l’origine de ses problèmes. C’est en effet parce qu’ils coopèrent que des agents peuvent accomplir plus que la somme de leurs actions des agents, mais c’est aussi à cause de leur multitude qu’ils doivent coordonner leurs actions et résoudre des conflits. Pour un agent, l’autre est à la fois le pire et la meilleure des choses. Communiquer Traiter le problème de l’interaction c’est se donner les moyens non seulement de décrire les mécanismes élémentaires permettant aux agents d’interagir, mais aussi d’analyser et de concevoir les différentes formes d’interaction que des agents peuvent pratiquer pour accomplir leurs tâches et satisfaire leurs buts. Tout d’abord, les agents doivent être capables, par le biais de la communication, de transmettre des informations, mais surtout d’induire chez l’autre un comportement spécifique. Communiquer est donc une forme d’action particulière qui, au lieu de s’appliquer à la transformation de l’environnement, tend à une modification de l’état mental du destinataire. Par exemple, demander à un autre d’exécuter une tâche, tend à provoquer chez l’autre une intention d’accomplir cette tâche et constitue donc une manière de satisfaire un objectif sans réaliser la tâche soi-même. Il existe deux formes de communications : n les communications intentionnelles mettent en contact des agents cognitifs par le biais d’envois de messages. Cette forme de communication est surtout utilisée par des agents organisés en réseaux ; n les communications réactives qui prennent la forme de signaux transmis entre agents réactifs. On rencontre ces formes de communication surtout dans la robotique collective mobile et la simulation de sociétés animales, beaucoup moins dans les réseaux.

Les communications intentionnelles sont surtout étudiées sous l’angle d’actes de langage. Issue initialement des travaux d’Austin [Austin 1962], Searle [Searle 1969 ; Searle 1979] et Vanderveken [Vanderveken 1988] en philosophie du langage, la théorie des actes de langage décrit l’aspect pragmatique des communications en termes d’états mentaux de l’émetteur et du destinataire de l’acte (voir l’encadré de l’article de David Sadek dans ce volume). Ces théories ont été reprises et formalisées par Cohen et Levesque [Cohen & Levesque 1990b]. Elles sont à la base de nombreux protocoles de communications entre agents communicants. Dans ce cadre, une communication individuelle peut être notée ainsi : e : d << F(a) où e et d sont les agents émetteur et destinataire du message, et où F, que l’on appelle le performatif, décrit le type de message et où a représente le contenu du message. Chaque type de message (locutoire) est transformé en une force “illocutoire”, elle-même formalisée dans un langage modal en termes des états mentaux du destinataire et du receveur. Par exemple, un message de type DemanderFaire, qui consiste pour un agent e à demander à un autre agent d d’accomplir l’action a, peut se formaliser ainsi (d’après [Cohen & Levesque 1995]) : (demanderFaire e d a) = (croyanceMutuelle e d (but e [(capable d a) ⇒ (intention d a)])) et qui peut se paraphraser ainsi : envoyer une demande d’action revient à ce que les deux agents émetteurs et destinataires aient comme croyance que l’émetteur ait comme but que le destinataire ait un jour l’intention d’accomplir l’action demandée s’il en a la capacité. Aux Etats-Unis, un projet de recherche initialement fondé par la Darpa a pour but de développer un standard de communication de haut niveau, appelé KQML pour “Knowledge Query and Manipulation Language”, fondé sur les actes de langages et permettant à des agents cognitifs de coopérer.

Ce projet a un grand retentissement dans toute la communauté et de nombreux chercheurs tentent à la fois de s’intégrer et de dépasser les nombreuses limites de ce projet [Cohen & Levesque 1995]. En France, un comité d’étude est en cours de mise en place pour étudier et concevoir des protocoles entre agents coopérants. Une critique que l’on peut faire à cette approche est de ne pas rendre compte des aspects exécutoire. Il s’agit en fait d’une spécification de haut niveau qui indique quelles sont les conditions que doit remplir une réalisation effective. Au contraire, un formalisme de type réseau de Petri permet de décrire la réalisation d’une telle communication tout en conservant des capacités de validation et de vérification [Ferber 95]. Dans ce cas, une action de type DemanderFaire peut être décrite par le réseau suivant (figure 2) : Figure 3 - La répartition de tâches par médiation.

organisées dans le temps et l’espace de manière à réaliser les objectifs. Enfin, lorsque des conflits apparaissent, il est important de pouvoir en limiter leurs effet. Les techniques de négociation servent ainsi à satisfaire les parties impliquées en établissant des compromis ou en dépassant la nature du conflit.

Figure 2 - Un acte de langage représenté sous la forme d’un réseau de Petri.

Collaboration et coordination d’actions Les différentes formes d’interaction sont la collaboration et la coordination d’actions. La première s’intéresse à la manière de répartir le travail entre plusieurs agents, qu’il s’agisse de techniques centralisées ou distribuées, et la seconde analyse la manière dont les actions des différents agents doivent être

La coopération est la forme générale d’interaction la plus étudiée dans les systèmes multiagents. De manière simplifiée, le problème de la coopération peut se ramener à déterminer qui fait quoi, quand, où, avec quels moyens, de quelle manière et avec qui, c’est-à-dire en fait à résoudre les différents sousproblèmes que constituent la collaboration par répartition de tâches, la coordination d’actions et la résolution de conflits. La réalisation de systèmes de répartition de services et de coordinations, tels que la médiation (usage de médiateurs ou courtiers pour la répartition des services en fonction des offres et des demandes (figure 3) ou le réseau contractuel, fondé sur la notion de marché [Smith 79]

passent par l’établissement de protocoles de conversations, qui peuvent faire l’objet d’une représentation et d’une validation par réseaux de Petri.

Architecture d’un système multiagent Les systèmes multiagents sont évidemment complexes, et leur architecture intègrent un ensemble de concepts dévéloppés aussi bien dans les systèmes distribués qu’au sein de l’intelligence artificielle.

Une architecture en couche Un système multiagent conçu autour d’agents communicants possède une architecture caractéristique qui est illustrée figure 4. Le niveau 0 correspond à l’ensemble des ressources disponibles telles que les mécanismes de communication de bas niveau (sockets Unix, protocoles TCP/IP ou http, etc.) ainsi que les mécanismes d’exécution parallèles tels que les “threads”. C’est au-dessus de cette couche, qui est utilisée comme un existant, que viennent s’intégrer un système multiagent proprement dit.

Figure 4 - L’architecture en couche d’un système multiagent.

Le niveau 1 décrit les couches de bas niveau d’un système multiagent : les primitives de communication entre agents distants (primitives de type KQML), les serveurs de noms permettant à des agents d’entrer et de sortir du système (procédures de check-in check-out), ainsi que les moteurs qui implémentent le cycle de base de fonctionnement d’un agent. Ce cycle est lié à un processus en boucle de type perception/délibération/action : la perception représente la reconnaissance des objets de l’environnement ainsi que l’interprétation des messages reçus ; l’action décrit les opérations qu’un agent exécute ainsi que les communications dont il est l’émetteur ; enfin, la délibération exprime l’ensemble des moyens mis en œuvre pour qu’un agent accomplisse son action.

Le niveau 2 correspond à l’ensemble des mécanismes génériques qui sont mis en œuvre dans un système multiagent. Il s’agit du niveau fondamental sur lequel porte la plupart des recherches décrites dans la section précédente : définition de protocoles génériques de coopération, description d’agents administratifs et de liaison tels que les “courtiers” (ou brokers) qui mettent en rapport les agents qui demandent et ceux qui offrent des services, description de langage de contenu généraux, comportements génériques d’agents, etc. Le niveau 3 enfin traite des applications spécifiques et des domaines particuliers auxquels on dédie un système multiagent particulier. Nous verrons plus loin comment cette architecture peut être mise en œuvre dans le cas d’une application de type “commerce électronique”.

L’architecture des agents

Figure 5 Le cycle de base de fonctionnement d’un agent.

L’architecture des agents relève encore de la recherche. Nous avons développé dans [Ferber 95] une architecture suffisamment générale pour qu’elle puisse s’adapter à un grand nombre de situations. Cette architecture est fondée sur 6 fonctions : n la fonction “conative” qui représente l’élaboration de buts et la prise de décision, n la fonction organisationnelle qui gère le suivi des tâches et la satisfaction des buts, n la fonction représentationnelle qui porte sur l’ensemble des données et représentations qu’un agent peut avoir sur le monde, sur les autres et sur lui-même, n la fonction productive qui représente les services offerts par un agent pour lui permettre d’accomplir sa fonction, n la fonction végétative représente l’ensemble des processus qui gère les coûts, les temps d’exécution et la gestion des ressources d’une manière générale, n la fonction interactionnelle s’occupe de l’interface et des entrées-sorties : perception et action, réception et envoi de message notamment.

Ce type d’architecture peut être mise en œuvre de différentes façons. L’une des plus connues repose sur celle de tableau noir.

Les architectures d’agents à base de tableaux noirs L’architecture de tableau noir est l’une des plus utilisée dans les systèmes multiagents cognitifs symboliques et elle a donné lieu à une abondante littérature. Originellement développée dans le cadre de l’intelligence artificielle traditionnelle (c’est-à-dire, du point de vue de l’IAD, pour réaliser des systèmes monoagents), pour la reconnaissance de la parole avec le système Hearsay II [Erman et al. 1980], l’architecture de tableau noir s’est rapidement imposée en IAD comme une architecture suffisamment souple et puissante pour pouvoir implémenter les mécanismes de raisonnement et de calculs intervenant à l’intérieur des agents, notamment avec le système DVMT [Lesser & Corkill 1983]. Le modèle de tableau noir est fondé sur un découpage en modules indépendants qui ne communiquent directement aucune informations, mais qui interagissent indirectement en partageant des informations. Ces modules, appelés sources de connaissance ou KS (pour Knowledge Sources), travaillent sur un espace qui comprend tous les éléments nécessaires à la résolution d’un problème. L’architecture d’un système à base de tableau noir comprend trois soussystèmes (figure 6) : n les sources de connaissance ; n la base partagée (le “tableau” proprement dit) qui comprend les états partiels d’un problème en cours de résolution, les hypothèses et les résultats intermédiaires et d’une manière générale toutes les informations que s’échangent les KS. Ces bases sont décomposées en hiérarchies (conceptuelles, partitives, causales, etc.) qui structurent la modélisation du domaine d’application comme l’espace des hypothèses/solutions ; n un dispositif de contrôle qui gère les conflits d’accès entre les KS, ces derniers

intervenant de manière “opportuniste” c’est-à-dire sans être déclenchés effectivement par un système centralisé de contrôle. C’est cette partie qui a connu le plus de modifications au cours de l’évolution de ces architectures.

Figure 6 Une architecture de système à base de tableau noir.

Le contrôle dans les tableaux noirs Si le modèle de tableau noir est très général, puisqu’il ne dit rien sur la manière dont sont organisés ces sous-systèmes, de nombreuses réalisations ont vu le jour, chacune présentant une vision différente du contrôle, la partie en fait la plus ardue d’un tableau noir. Le problème du contrôle dans un tableau noir revient à essayer de savoir ce qu’il convient de faire ensuite, c’est-à-dire en fait de déterminer quelle source de connaissance doit être déclenchée. Au début, avec les premières implémentations de Hearsay II, le contrôle était “câblé” au sein d’une procédure, puis très rapidement il fut donné sous la forme d’un ensemble de règles. Mais ce n’est qu’avec le système BB1 de B. Hayes-Roth que l’organisation du contrôle dans les tableaux noirs acquit ses lettres de noblesses, en considérant le contrôle comme un problème suffisamment important pour qu’il dispose de son propre tableau [Hayes-Roth 1985]. L’architecture de BB1 comprend donc deux tableaux : le premier est destiné au traitement du problème du domaine et le second à la gestion du contrôle. De ce fait, il est possible de traiter l’activation des sources de connaissance comme s’il s’agissait d’un problème indépendant du domaine d’application.

Pour pallier certains des problèmes d’efficacité des approches à base de tableau de contrôle à la BB1, et considérant que la plupart des systèmes de contrôle étaient en fait hiérarchiques, J.-P. Haton, H. Laasri et B. Maitre du Crin à Nancy ont cherché une architecture présentant un bon compromis entre l’expressivité et l’efficacité. Ils voulaient pouvoir décrire le contrôle sous forme de KS sans perdre en efficacité par rapport à un contrôle procédural pur. De cette réflexion, est né le système Atome [Lâasri et al. 1987] qui a été depuis utilisé dans un grand nombre d’applications. Citons notamment un système d’aide à la décision pour la gestion des réfections de la voirie de Nancy et un outil de gestion temps réel des contre-mesures pour un pilote d’avion de chasse. On trouvera une bonne explication de la notion de tableau noir comme système indépendant, de ses mécanismes et des différentes versions dans [Engelmore & Morgan 1988]. Tableaux noirs et systèmes multiagents Si dans un premier temps, les systèmes à base de tableau noirs furent considérés comme des systèmes d’IAD, chaque KS pouvant être perçu comme un agent qui interagit avec les autres KS, il n’en est plus de même aujourd’hui. Du fait de leur mécanisme de contrôle très centralisé et de leur manque de mémoire locale et donc de localité des informations, ces systèmes sont maintenant envisagés comme des architectures pratiques pour la réalisation de systèmes “intelligents” et, en particulier, pour implémenter la structure interne d’agents cognitifs symboliques. Nombre de systèmes multiagents ont été implémentés de cette manière aux Etats-Unis [Lesser & Corkill 1983] [Hayes-Roth et al. 1988] et en France [Chevrier 1993][Cambier 1994].

L’architecture de tableau noir présente de nombreux avantages dont, en tout premier lieu, une remarquable souplesse pour décrire des modules et articuler leur fonctionnement. Son intérêt réside dans ce qu’elle est à la fois opportuniste et centralisée, les liaisons entre les modules (entre les KS donc) étant mutables. Elle est opportuniste au sens où les KS se déclenchent lorsque des configurations du tableau les intéressent, suite à des modifications provoquées par d’autres KS. Elle est centralisée par l’intermédiaire d’un module de contrôle qui ordonne l’ordre dans lequel les KS seront effectivement activés, en essayant de déterminer quelle est la meilleure action à effectuer compte tenu de l’état du système. Son principal inconvénient provient de sa relative inefficacité, due à la très grande expressivité de son contrôle. De ce fait, ce type d’architecture s’avère particulièrement utile lors de la phase de prototypage de la réalisation de systèmes ou lorsque les temps de réponses ne sont pas trop contraints. Néanmoins, des versions de BB1 ont montré que même dans des cas où il était nécessaire d’avoir des temps de réponses en temps réel, la gestion fine du contrôle pouvait accélérer de manière drastique son comportement en prenant les bonnes décisions et en choisissant les tâches importantes et urgentes au bon moment [Hayes-Roth & Collinot 1993]. En tout état de cause, les avantages de ce type d’architecture sont indéniables : du fait de sa très grande plasticité, il est possible d’implémenter n’importe quelle structure d’agent en termes d’éléments de tableaux et de KS. En particulier, toutes les autres architectures peuvent être modélisées en termes de tableaux noirs au prix parfois d’une certaine lenteur dans l’exécution. Le tableau noir se présente donc comme une sorte de “méta-architecture”, c’est-à-dire une architecture pour implémenter des architectures.

Architectures multiagents et acteurs On appelle architecture multiagent d’un agent l’application de la notion de système multiagent à la définition de l’architecture des agents eux-mêmes, un agent étant alors considéré comme un système multiagent à part entière. Le premier à avoir considéré le psychisme d’un être (humain ou artificiel) comme le résultat d’interactions entre petits agents individuels est M. Minsky dans son livre “La société de l’esprit” [Minsky 1988]. Il y décrit, de manière assez décousue, un ensemble de mécanismes résultant de conflits et de coopérations entre petites entités calculatoires qu’il appelle agents. Chacun est responsable d’une activité, d’un souvenir, d’une propriété reconnue d’un objet, sans qu’il y ait de véritable système centralisateur coordonnant l’ensemble. De ce fait, Minsky considère que le fonctionnement de l’appareil psychique n’est pas le résultat d’un ensemble d’inférences portant sur des symboles, mais plutôt le fruit de confrontations auto-organisatrices entre processus autonomes. Bien que très peu de systèmes aient été conçus à partir des travaux de Minsky (et on peut d’ailleurs se demander si elles sont réellement implémentables dans leur totalité), ses idées ont certainement influencé tout un courant de pensée qui considère que le comportement d’un agent résulte d’un ensemble d’activités internes que l’on peut associer au fonctionnement d’un système multiagent. En particulier tous les travaux portant sur les langages d’acteurs et sur leur utilisation dans des systèmes multiagents peuvent dans une certaine mesure se rapporter à ce courant. Initialement, la notion d’acteur est apparue avec les travaux de Hewitt dès 1973. Ils ont véritablement été rendus publics vers 1976 avec l’article initiateur “Viewing Control Structures as Patterns of Passing Messages” [Hewitt 1977], qui développait une certaine conception des programmes conçus comme des sociétés de spécialistes résolvant

un problème en communiquant par envois de messages. A cet effet, Hewitt montrait que son modèle d’exécution permettait de considérer les structures de contrôle des langages traditionnels comme des schémas (patterns) de communications entre entités autonomes appelées acteurs. Depuis, les langages d’acteurs, en particulier sous l’influence de Agha [Agha 1986] de Tokoro [Tokoro 92] et de Yonezawa [Yonezawa 90] ont surtout été étudiés comme des modèles d’exécution pour la programmation par objets concurrents. Mais quelques travaux ont voulu rester dans les idées initiales que prônaient Hewitt et qu’il confirma avec ses notions de “sémantique des systèmes ouverts” [Hewitt 1991] [Hewitt 1985]. P. Carle [Carle 1992], S. Giroux [Giroux & Senteni 1992] et J. Ferber [Ferber & Carle 1991], tout en estimant que les langages d’acteurs sont effectivement de très bons outils pour l’implémentation de calculs parallèles, considèrent néanmoins qu’ils présentent des caractéristiques tellement originales qu’ils modifient par leur présence la notion même d’architecture multiagents en envisageant les agents et les systèmes multiagents comme des extensions naturelles de la notion d’acteur. Mais qu’est ce qu’un acteur ? Un acteur est une entité informatique qui se compose de deux parties : une structure qui comprend l’adresse de tous les acteurs qu’il connaît et à qui il peut envoyer des messages et une partie active, le script, qui décrit son comportement lors de la réception d’un message. Le comportement de chaque acteur, qui s’exécute indépendamment et en parallèle avec les autres, se résume à un ensemble d’actions extrêmement réduit : envoyer des messages, créer des acteurs et modifier son état (ou déterminer un nouveau comportement pour le message suivant). C’est tout ! Et c’est suffisant pour pouvoir exprimer n’importe quel calcul parallèle comme une combinaison de ces actions primitives.

La communication entre acteurs s’effectue par envois de messages asynchrones, c’est-à-dire que l’émetteur n’a pas besoin que le récepteur soit prêt pour recevoir un message. Mais l’originalité la plus importante des langages d’acteurs est certainement l’usage de la continuation locale du calcul. Lorsqu’un acteur A a besoin d’une réponse à un message qu’il envoie à un acteur B, il n’attend pas la réponse : il passe en argument un nouvel acteur C, appelé “customer” chez Hewitt, qui se charge de traiter la réponse et la suite du calcul. Cet acteur C agit donc comme la continuation locale du calcul initié par l’envoi de message de A vers B. L’usage des continuations locales donnent une très grande fluidité aux calculs exprimés en langages d’acteurs puisque les acteurs n’ont aucunement besoin d’attendre les réponses. De nombreux langages d’acteurs ont été proposés. Les plus célèbres et actuellement opérationnels sont ABCL [Yonezawa 1990], Mering IV [Ferber & Carle 1991] et Actalk [Briot 1989], ce dernier étant conçu comme une extension de Smalltalk. En étendant la notion d’acteur vers celle d’agent grâce à l’utilisation de la réflexivité organisationnelle, S. Giroux [Giroux 1993] propose de considérer un agent comme un écosystème, c’est-à-dire comme un ensemble d’agents en interactions, et un écosystème comme un agent. Son système, ReActalk, fondé sur une extension d’Actalk, fournit aux agents la possibilité d’adapter leur comportement en fonction du type de message qu’ils reçoivent et ainsi de pouvoir dialoguer aussi en mode synchrone si cela s’avère nécessaire. Néanmoins, ces agents ne disposent pas véritablement de comportements autonomes (ils n’ont pas de systèmes motivationnels) ni de représentations de leur environnement, l’idée d’écosystème étant plutôt prise comme une métaphore. Néanmoins ces travaux montrent qu’il existe un lien de continuité entre la notion d’acteur et celle d’agents.

Enfin, il faut signaler d’une part que L. Gasser dans son système Mace [Gasser et al. 1987] a été fortement inspiré par les idées de Hewitt concernant les acteurs et, d’autre part, que le langage Actalk est à la base d’un grand nombre de plates-formes multiagents, le premier en date ayant été Mages III [Bouron et al. 1990]. Le rapport entre acteurs et agents est ainsi des plus féconds et nul doute que l’avenir verra d’autres travaux tendant à montrer les liens très étroits qui unissent ces deux concepts.

Environnement de développement De nombreux environnements de développements de SMA ont été proposés par des équipes universitaires. Citons en particulier Mice par Ed Durfee de l’université du Michigan [Durfee & Montgomery 1989], Mages [Bouron et al. 1990], Ratman [Bürckert & Müller 1991] et plus récemment Desire [Brazier et al. 96]. Mais ces environnements ne peuvent combler les contraintes industrielles, voire même pré-industrielles. C’est pour cela qu’un projet Esprit, Imagine, avait démarré en 1990, avec comme partenaire Siemens, Plessey, Intrasoft, et Steria pour la France. Il s’agissait d’offrir aux concepteurs et réalisateurs un environnement de développement pour systèmes multiagents à granularité variable. Dans ce contexte, un agent peut être un système à base de connaissance, un capteur, un programme de supervision, voire même l’assistant informatisé d’un être humain. Deux applications avaient été envisagées. L’une concerne le trafic aérien, l’autre un système de gestion de réseau de télécommunication. Si des “maquettes” du système ont bien été réalisées en Parlog* avec souvent de très bonnes idées, le projet global n’a pas abouti.

Plusieurs systèmes industriels se présentent maintenant comme une alternative à ces premiers projets universitaires. En particulier, AgentBuilder réalisé par IBM, environnement de réalisation d’agents “intelligents” à partir d’un ensemble de composants connectables (puggable). Chaque agent se compose d’un moteur d’inférence (dont les faits et règles sont écrits en format KIF), et d’un système de réaction à des événements http. Dans le domaine des télécoms, la société General Magic, en collaboration avec de nombreuses sociétés de télécommunications, et en particulier France Télécom, a développé un système de développement de systèmes multiagent fonctionnant sur réseau, Téléscript**. Bien que dans ce système les notions d’agents soient particulièrement frustes (les agents ne sont ici que de simples processus) il intègre néanmoins un certain nombre de caractéristiques qui permettent d’ores et déjà d’écrire des (petites) applications distribuées disposant d’un minimum de capacités multiagents. Gageons que les systèmes du futur s’inspireront des facilités de développement et de la technologie – très orientée objet – mise en œuvre dans ce produit. Enfin, le langage Java de Sun commence à prendre un essor considérable et certains le voient comme un challenger particulièrement prometteur de Téléscript. Bien qu’il dispose de moins de richesses quant à la migration d’objets et à la sécurité de fonctionnement, plusieurs projets commencent à promouvoir Java comme langage de développement d’agents communicants sur Internet. S’il n’existe pas d’ouvrage ni d’article décrivant en détail les problèmes et les techniques d’implémentation des systèmes multiagents, on retrouve disséminé ici et là, et surtout dans les travaux de thèse,

* Parlog est un Prolog concurrent qui peut s’exécuter sur des architectures paralléles. ** On pourra trouver de l’information concernant Téléscript à l’adresse internet : www.genmagic.com

un certain nombre d’informations quant à la réalisation effective d’un système multiagent, qu’il s’agisse de systèmes complets ou plus simplement de platesformes de développement. Par exemple [Bouron 92] décrit une architecture de SMA cognitif en Smalltalk. On trouvera aussi dans [Jennings 94] une bonne description des problèmes d’implémentation de systèmes multiagents industriels, dans [Ferber 95] une présentation de différentes architectures d’agent et de SMA et dans [O’Hare & Jennings 96] un état de l’art d’un certain nombre de platesformes de développement de SMA.

Applications des SMA aux télécommunications Les applications des SMA pour les télécoms sont nombreuses, mais on peut les regrouper en quatre classes principales : les agents assistants, l’intégration de services et le commerce électronique, l’administration et la régulation de réseaux, et enfin la simulation de réseaux et de comportements.

Les agents assistants L’application tournée vers la notion d’agents assistants correspond directement à une mise en pratique de la conception de l’agent comme collaborateur. Les applications déjà envisagées dans ce cadre concerne des agents trieurs et administrateurs de courrier électroniques, des agents “fureteurs” qui récupèrent et filtrent l’information disponible sur le réseau en fonction des préférences de l’utilisateur, des agents gestionnaires de rendez-vous, et d’une manière générale des agents qui automatisent des tâches quotidiennes.

Le problème général des agents assistants porte sur la compétence et la confiance que l’utilisateur peut avoir en eux. La confiance se définit dans le temps au cours d’un échange permanent entre l’utilisateur et l’agent. Un utilisateur devient confiant dans son agent si : n il arrive à anticiper des demandes de l’utilisateur et accomplit des tâches que l’utilisateur n’avait pas demandées mais qui se révèlent exactement ce qui l’intéresse, n il pose des questions pertinentes à l’utilisateur lorsqu’il se trouve dans une situation difficile qui demande un arbitrage de l’utilisateur, n il ne commet pas d’erreur importante dans ses décisions personnelles. Cette mise en confiance peut être développée lors d’une période d’apprentissage où d’un côté l’agent apprend les désirs de l’agent, son style, ses préférences et sa façon de se comporter, et de l’autre côté l’utilisateur surveille le comportement de l’agent.

Simulation La simulation est une branche très active de l’informatique qui consiste à analyser les propriétés de modèles théoriques du monde environnant. Généralement, ces modèles sont donnés sous la forme de relations mathématiques entre des variables représentant des grandeurs physiques mesurables dans la réalité. Les modèles les plus utilisés sont les équations différentielles, les matrices de transitions, la théorie des files d’attente, etc. Elles reposent dans tous les cas sur la définition d’une relation de cause à effet entre des variables d’entrées et des variables de sorties. Par rapport à ces techniques classiques, les systèmes multiagents apportent une solution nouvelle au concept même de modèle et de simulation en offrant la possibilité de représenter directement les individus, leurs comportements et leurs interactions. La simulation multiagent est fondée sur l’idée qu’il est possible de représenter sous forme informatique

le comportement des entités qui agissent dans le monde et qu’il est ainsi possible de représenter un phénomène comme le fruit des interactions d’un ensemble d’agents disposant de leur propre autonomie opératoire. Par exemple, dans un modèle multiagent de population, on représentera directement les individus sous la forme d’agents, et la quantité d’individus d’une espèce donnée sera le résultat des confrontations (coopération, lutte, reproduction) des comportements de tous les individus représentés dans le système (pour avoir un panorama plus étendu sur la simulation multiagent on pourra se reporter à [Ferber 95]). De ce fait, l’utilisateur d’un tel simulateur a un rôle actif. Il emploie un système multiagent comme s’il s’agissait d’un laboratoire miniature, déplaçant des individus, changeant leur comportement, et modifiant les conditions environnementales. Chaque agent est évidemment “marqué” comme pourrait l’être un être naturel, mais ce marquage est évidemment plus facile, puisque l’individu peut être suivi à tout moment dans son évolution et avec le degré de finesse désiré. On exploite alors les capacités des ordinateurs pour traiter les données obtenues, les agréger et les exploiter à l’aide de techniques statistiques afin de vérifier les hypothèses émises. Ainsi, à la différence des approches classiques, la simulation multiagent ne se réduit pas à l’implémentation d’un modèle puis à l’analyse de la réponse de ce modèle en fonction des paramètres d’entrées, mais participe au processus de recherche de modèles. Les principales qualités des modélisations multiagents sont leur capacité d’intégration et leur flexibilité. En effet, il est possible d’intégrer dans la même modélisation des variables quantitatives, des équations différentielles, et des comportements fondés sur des règles symboliques. Il est aussi très facile d’intégrer des modifications, chaque enrichissement du modèle étant réalisé par l’adjonction de règles comportementales qui agissent au niveau de l’individu. De plus, les individus étant toujours distingués les uns

des autres, il est possible d’ajouter de nouveaux types d’agents disposant de leur propre modèle de comportement, qui viennent interagir avec les agents déjà définis. Par exemple, dans une modélisation forestière, on peut introduire de nouvelles espèces animales ou végétales et analyser leurs interactions avec celles déjà modélisées. Enfin, les systèmes multiagents permettent la modélisation de situations complexes dont les structures globales émergent des interactions entre individus, c’est-à-dire de faire surgir des structures du niveau macro à partir de modélisations du niveau micro, brisant ainsi la barrière des niveaux, si criante dans les modélisations classiques. Nous présentons ici deux systèmes caractéristiques de simulation multiagent qui sont le résultat de collaboration entre informaticiens et chercheurs écologues. Il existe bien évidemment un grand nombre d’autres applications de simulation comportementale, mais ceux-ci donnent un aperçu des domaines variés dans lesquels les SMA peuvent être employés. Dans le domaine des télécommunications, la simulation multiagent peut être utilisée avec efficacité pour modéliser le fonctionnement de réseaux à grande vitesse (par exemple la gestion des flux de réseaux ATM) ou pour modéliser l’interaction entre plusieurs services afin de mieux comprendre la quantité et le type de flux d’informations qu’ils échangent.

Intégration de services et marché électronique La plus grande gamme d’applications intéressantes pour les systèmes multiagents dans le cadre de réseaux de télécommunications me semble être celle de l’intégration de services et le développement du marché électronique. L’idée générale de ce type d’application est de mettre en commun des clients et des fournisseurs de services dans une architecture totalement ouverte, clients et fournisseurs étant des agents électroniques

qui négocient entre eux des échanges de services. Le système multiagent constitue alors une sorte de “place de marché électronique”, dans lequel les clients émettent des demandes et les fournisseurs envoient des propositions de services. Finalement des contrats sont établis entre clients et fournisseurs, et tout cela de manière automatique, ou en tous cas, avec une intervention humaine réduite. Les mots clés sont ici négociations entre agents, contrats, gestion de contraintes, services et intégration de services, etc. Un exemple simple, mais néanmoins révélateur, en est donné par le scénario de l’agence de voyage. Dans cet exemple, un service intermédiaire, l’agence de voyage, combine différents services (réservations de trains, d’avions et de chambres d’hôtel) et les propose à des clients électroniques eux aussi (le client peut être un agent assistant mandaté par l’utilisateur par exemple). Lorsqu’un client établit une transaction commerciale avec l’utilisateur, un contrat est établit qui détermine les engagements de chacun. Par exemple, si l’horaire d’un avion est modifié, ou si les prix viennent à changer, l’agence de voyage peut gérer ces modifications en tenant compte de conditions établies par le client : dates du voyage, prix maximum, etc. De plus, l’agence de voyage doit tenir compte de contraintes dépendant des services qu’elle propose (s’il y a deux vols au cours d’un trajet, il faut vérifier que le second n’a lieu qu’après le premier).

Types d’agents Dans une application de type agence de voyage, de nombreux types d’agents doivent collaborer. Voici un éventail (non exhaustif, mais assez détaillé pourtant) de ces différents types d’agents : n les agents “assistants” servent d’interface avec l’utilisateur. Ils gèrent les interactions avec les autres agents assistants (prise de rendez-vous, organisation de réunions, etc.) et avec les autres types d’agents (recherche d’information, de service, négociation de contrats, etc.) ;

n les agents “applicatifs” qui sont de deux ordres : - les “services terminaux” qui sont liés à une application de type base de données, ou de type serveur télématique, ils correspondent à la réalisation d’un service “terminal”. Ces applications sont encapsulées dans des agents pour interagir avec l’ensemble de la communauté ; - les “services intermédiaires” qui servent à établir des fonctionnalités à valeurs ajoutées en regroupant des services terminaux. Typiquement, il correspondent à l’exemple de “l’agence de voyage” qui intègre des services “réservation d’hôtel ” “réservation de billets d’avion” et “réservation de billets de trains” en disposant d’une expertise portant sur le voyage ; n les agents “marketing” sont de plusieurs types : - les “commerciaux” qui servent à faire connaître leurs services aux utilisateurs potentiels (courtiers, services intermédiaires et assistants) ; - les “acheteurs”, qui négocient le prix des services ; - les “fureteurs” qui se déplacent dans le réseau à la recherche de bonnes affaires ou d’informations utiles à l’utilisateur. Pour l’instant, ce type d’agent a surtout été utilisé ; - les agents “filtreurs” qui, devant la grande quantité d’informations disponible, sélectionnent ce qu’ils jugent utile à leur mandant, lequel peut être aussi bien un utilisateur (éventuellement au travers d’un agent assistant) qu’un service ; n les agents de liaison, appelés généralement “courtiers” (brokers) qui se chargent de la mise en rapport de demandeurs et d’offreurs de services ; n les agents “intégrateurs et juridiques” se chargent de l’élaboration et du suivi des contrats, de leur vérification, ainsi que de la mise à jour des contraintes lorsque des conditions sont modifiées ; n les agents administratifs enfin, qui s’occupent de la vérification, de la sécurité et de l’acheminement des informations au lieu où se trouve l’utilisateur, et qui comprennent les “agents messagers” caractéristiques de l’approche Téléscript.

Exemples de projets existants

Les problèmes rencontrés

Dans ce cadre, un certain nombre de projets ont été réalisés en collaboration avec France Télécom dans le cadre de contrats CNET avec des Universités. Elles consistent à analyser la notion de système multiagent dans le cadre de réseaux de télécommunications. En particulier le problème de l’engagement des agents lors de l’établissement de services et celui des outils et des méthodes à mettre en pratique pour l’élaboration de systèmes multiagents dans des réseaux.

Ce scénario, qui est à la base d’un champ d’applications énorme dans le domaine des télécoms pose un certain nombre de problèmes : n langage de communication et d’interaction normalisé. Pour que différents services hétérogènes puissent travailler ensemble, il est nécessaire qu’ils parlent un langage commun. A l’heure actuelle, certaines propositions autour de KQML, un langage développé à Stanford, semble être mis en avant par nombre de chercheurs. Néanmoins, il souffre de nombreux maux, dont le premier est de ne pas avoir une sémantique claire, indépendante de la structure des agents. D’autre part, il ne peut être utilisé que pour des communications isolées, alors que la mise en place d’interactions complexes nécessite l’établissement de protocoles élaborés ; n langage de description des services et des contraintes souple et évolué. Les agents doivent être à même de communiquer à d’autres agents sur des sujets divers. Il est donc nécessaire qu’ils puissent se mettre d’accord sur le sens des mots. En effet, il faut faire en sorte qu’un agent qui désire aller de Paris à Toulouse puisse être compris s’il désire : “Je veux aller de Paris à Toulouse” ou “Je veux acheter un billet pour aller de Paris à Toulouse”, et cela dans plusieurs langues. Ce problème est d’ailleurs bien connu des chercheurs en linguistique computationnelle qui ont développé des interfaces de base de données en langage naturel. C’est pour résoudre cet épineux problème qu’il est nécessaire de développer des thesaurus conceptuels (que les anglo-saxons ont baptisé “ontologies”) qui soient communes sinon à tous, tout du moins à un ensemble d’agents travaillant dans le même domaine. A cet égard, les langages de type IDL (Interface Description Language) tels qu’on les trouve dans des architectures objet de type Corba (ou ODP) ne sont pas suffisants, car ils sont purement syntaxiques et ne prennent pas en compte le sens des requêtes et des descriptions. Ce problème peut être assez facilement résolu par des techniques de type analyse de langage naturel, adapté aux interactions entre agents ;

Outre ces projets, on peut parler de celui de CommerceNet, développé à Stanford en collaboration avec un ensemble d’industriels importants de la région. CommerceNet est une infrastructure ouverte pour le développement du marché électronique. Ce projet a pour objectif affiché de “révolutionner les contacts entre clients, fournisseurs et développeurs en rendant leurs interactions aussi efficaces que s’il s’agissait d’interactions entre membres d’un même département”. Tout en étant sensiblement différent, le projet Bayou de Xerox Parc se situe dans cette mouvance. Leur objectif est de développer une plate-forme de développement et d’exécution d’applications permettant à des outils de communications mobiles (ordinateurs portables, PDA (Personal Digital Assistant) de type Newton, etc.), qui sont rarement “en ligne”, d’avoir accès à des informations collectives relativement cohérentes. Ce type de projet montre bien que la métaphore de l’espace électronique est féconde et que des organismes de recherche majeurs s’intéressent à cette question.

n validation des comportements et

des protocoles d’interaction. Comment assurer que les agents vont bien accomplir ce qu’ils sont censés faire. Ce problème est celui de la validation des protocoles d’interactions ainsi que du comportement des agents intermédiaires nécessaires à l’établissement des négociations commerciales et à leur équité (courtiers, agents juridiques, etc.). Ces problèmes se situent à deux niveaux. Au niveau technique, il s’agit de vérifier que le comportement des agents ne conduit pas à des situations incohérentes ou de blocages. Pour cela on peut utiliser des techniques classiques, telles que les réseaux de Petri. Mais il existe un second problème qui se situe à un niveau juridique. A partir du moment où des agents peuvent établir des contrats et accomplir des actes commerciaux de manière autonome, ils peuvent être amenés à accomplir des actions qui ne soient pas totalement en accord avec les demandes de leur utilisateur. De ce fait, il faut réfléchir au statut juridique de ces agents et aux problèmes de responsabilités associés ; n plate-forme de développement d’applications et d’exécution de tels logiciels. Il s’agit ici d’un problème à la fois technique et économique. Il pose de nombreux problèmes concernant la manière d’aborder le problème. De ce fait, vu son importance stratégique, la section suivante lui est entièrement consacrée.

Quelques scénarios dans le cas du commerce électronique Comment gérer le développement de ce type d’application ? Trois scénarios me semblent imaginables dans le futur. En voici trois qui paraissent viables sur le plan technique : les réseaux multiagents propriétaires, les “zones à péage” et les outils standardisés d’interactions. Les réseaux propriétaires Le premier de ces scénarios concerne la réalisation d’un réseau grand public propriétaire. Ce réseau offrirait toute l’architecture et toute l’infrastructure nécessaire à l’implémentation d’un ensemble d’agents en interaction : agents administratifs, intégrateurs et juridiques, ainsi qu’un ensemble de base d’agents services, marketing et assistants. Le fournisseur du réseau offrirait de même un kit de développement pour la réalisation de services. Ce scénario suppose l’existence d’un regroupement important entre plusieurs opérateurs de réseaux, de manière à pouvoir lutter contre le développement d’Internet. Bien que cette stratégie puisse être celle de France Télécom, je la crois difficilement viable à terme pour des raisons purement économique. Cette stratégie ne peut s’appliquer que dans des situations de marché captif, qui vont à l’encontre de la tendance actuelle plutôt tournée vers l’ouverture. A cet effet, l’importance du développement d’Internet, ses faibles coûts de communication, le standard de fait qu’il procure avec les outils Web, l’échec de Microsoft Network, montre, s’il en était besoin, que le vent ne souffle pas dans cette direction. Les “zones à péage” Un deuxième scénario repose sur la notion de ce que l’on pourrait appeler une “zone à péage” (terme forgé par mes soins). Il consiste à développer un sous réseau d’Internet dans lequel les communications sont gérées par un opérateur unique qui fournit un ensemble de services supplémentaires (agents courtiers, administratifs, juridiques, etc.). Un site Web ne constituant pas a priori un agent,

il est nécessaire d’établir, au sein de ce gigantesque espace, des zones dans lesquelles le marché électronique pourra prendre effet. Pour offrir un service dans cette zone, ou tout simplement pour pouvoir y accéder, il faudrait s’abonner à cette zone pour une somme forfaitaire donnant droit à l’utilisation à l’ensemble des fonctionnalités de ce sous réseau. Ce scénario me semble relativement viable, mais comme tous les systèmes relativement fermés, il dépend uniquement du nombre d’abonnés tentés par cette opération. Cela dépend donc de la puissance économique des opérateurs et de l’ensemble des services qu’il peuvent apporter. Les outils standardisés d’interactions Le troisième scénario qui me paraît le plus vraisemblable, repose sur le développement de standards de communications de haut niveau et de thesaurus conceptuels (ontologies) ainsi que le développement d’un ensemble d’outils bon marché permettant l’intégration de techniques agents à des logiciels de navigation existant. Cette stratégie est très proche de celle choisie par Netscape et Sun avec Java. Bien que Java ne soit pas pour l’instant un logiciel d’intégration de systèmes multiagents, il est relativement facile de l’étendre pour qu’il joue ce rôle, comme nous l’avons dit plus haut. Ensuite, toute entreprise, tout utilisateur, peut développer ses propres agents à partir d’une telle base. Des entreprises spécialisées dans le juridique pourraient alors développer des agents intégrateurs et juridiques qui offriraient la meilleure sécurité de transaction. De ce fait, lors de l’établissement d’un contrat, les agents contractants décideraient de régler leur différend par les services intégrateurs et juridiques de telle ou telle compagnie. De ce fait, toutes les fonctionnalités nécessaires à la réalisation d’un système de marché électronique, hormis le langage de communication et le langage de description des ontologies, seraient disponibles sous la forme d’agents fournis par une entreprise tierce.

D’autres compagnies pourraient développer d’autres types d’agents : services, marketing, assistants, etc. à partir d’un kit de développement s’appuyant sur les fonctionnalités offertes par les outils standards d’interaction. C’est le scénario qui me paraît le plus probable, car c’est celui qui suppose le moins d’alliances économiques initiales. Il repose simplement sur l’existence d’un standard de communication de haut niveau fourni à bas prix et qui assure les fonctionnalités minimum de sécurité nécessaires à la réalisation d’échanges économiques sur le réseau.

Bibliographie

Van de Velde W, Perram J. (Eds.) (1996) Agents Breaking Away, pp. 42-55, LNAI 1038.

Ouvrages de référence*

Werner E. et Demazeau Y. (Eds.) (1992) Decentralized A.I. 3. Amsterdam, Elsevier/North-Holland.

Avouris N. et Gasser L. (Eds.) (1992) Distributed Artificial Intelligence: Theory and Praxis. Kluwer Academic Publishers. Bond A. et Gasser L. (Eds.) (1988) Readings in Distributed Artificial Intelligence. San Mateo, California, Morgan Kaufman. Ferber J. (1995) Les Systèmes multiagents. Vers une intelligence collective, InterEditions, 1995. Jennings N. (1994) Cooperation in Industrial Multi-Agent Systems. Vol. 43, World Scientific Press. O’Hare G., Jennings N. (1996) Foundations of Distributed Artificial Intelligence, Wiley.

Actes de congrès publiés Castelfranchi C. et Werner E. (Eds.) (1994) Artificial Social Systems, Proc. of Maamaw’92. Springer-Verlag. Demazeau Y. et Müller J.-P. (Eds.) (1990) Decentralized Artificial Intelligence. Elsevier North-Holland. Demazeau Y. et Müller J.-P. (Eds.) (1991) Decentralized AI 2. Amsterdam, Elsevier North-Holland.} Gasser L. et Huhns M. (Eds.) (1989) Distributed Artificial Intelligence}. Vol. II, Londres, Pitman/Morgan Kaufman. Huhns M. N. (Eds.) (1987) Distributed Artificial Intelligence. Londres, Pitman/Morgan Kaufman.

Wooldridge M., Jennings N. (Eds.) (1995) Intelligent Agents, LNAI 890, Springer Verlag. Wooldridge M., Müller J. P., M. Tambe (Eds.) (1996), Intelligent Agents II, LNAI 1037, Springer Verlag.

Autres références Agha G. Actors: A Model of Concurrent Computation for Distributed Systems. MIT Press, 1986. Austin J. L. How to Do Things With Words. Traduction française Quand dire c’est faire, Le Seuil, 1970. (Ed.), Clarendon Press, 1962. Bouron T. Structures de communication et d’organisation pour la coopération dans un univers multiagents. Thèse d’université, Université Paris 6, 1992. Bouron T., Ferber J. et Samuel F. Mages: a Multi-Agent Testbed for Heterogeneous Agents. In Decentralized Artificial Intelligence (Vol II), Demazeau Y. et Muller J.-P. (Ed.), North-Holland, 1990. Brazier F., Dunin-Keplicz B., Jennings N., Treur J. Desire : modelling multiagent systems in a compositional formal framework, International Journal of Cooperative Information Systems, M. Huhns, M. Singh (Eds.), special issue on Formal Methods in Cooperative Information Systems, 1996. A paraître.

Lesser V. (Ed.) (1995) Proceedings of the First International Conference on MultiAgent Systems (ICMAS’95), MIT Press.

Briot J.-P. Actalk: a Testbed for Classifying and Designing Actor Languages in the Smalltalk-80 Environment. Proc. of ECOOP’89, 109-129, Nottingham, UK, 1989.

Müller J.-P., Quinqueton J. (Eds.) (1996). IA distribuée et systèmes multiagents, JFIADSMA’96, Hermès.

Brooks R. A. Elephants Don’t Play Chess. Robotics and Autonomous Systems 6, pp. 3-15, 1990.

Rosenschein J. et Zlotkin G. Rules of Encounters: Designing Conventions for Automated Negotiation among Computers. Cambridge, Massachusetts, MIT Press, 1994.

Bürckert H.-J. et Müller J. Ratman: Rational Agents Testbed for Multi-Agent Networks. In Decentralized AI 2, Demazeau Y. et Müller J.-P. (Ed.), Amsterdam, Elsevier North-Holland, 1991.

Burg B. et Arlabosse F. Archon : une plate-forme industrielle pour l’intelligence artificielle distribuée. Deuxièmes journées francophones sur l’intelligence artificielle distribuée et les systèmes multiagents (JFIADSMA’94), Demazeau Y. et Pesty S. (Ed.), IMAG, Voiron, 1994. Cambier C. Simdelta : un système multiagent pour simuler la pêche sur le Delta Central du Niger. Thèse d’université, Paris 6, 1994. Cammarata S., McArthur D. et Steeb R. Strategies of Cooperation in Distributed Problem Solving. Proc. of the 1983 IJCAI Conference, 1983. Carle P. Un Langage d’acteur pour l’intelligence artificielle distribuée intégrant objets et agents par réflexivité compilatoire. Thèse d’université, Paris 6, 1992. Carle P., Collinot A. et Zeghal K. Cassiopeia: a Method for Designing Computational Organizations. DIMAS’95, International Workshop on Decentralized Intelligent and Multi-Agent Systems, Krakovie, Pologne, 1995. Cohen P. R. et Levesque H. J. Intention is Choice with Commitment. Artificial Intelligence 42, pp. 213-261, 1990a. Cohen P. R. et Levesque H. J. Rational Interaction as the Basis for Communication. In Intentions in Communications, Cohen P. R., Morgan J. et Pollack M. E. (Ed.), 508. MIT Press, 1990b. Cohen P. R. et Levesque H. J. Communicative Actions for Artificial Intelligence. First International Conference on MultiAgent Systems (ICMAS’95), Lesser V. (Ed.), MIT Press, San Francisco, 1995. Chevrier V. Etude et mise en œuvre du paradigme multiagent: de Atome à Gtmas. Thèse d’Université, Nancy I, 1993. Demazeau Y., Boissier O. et Koning J.-L. Using Interaction Protocols to Control Vision Systems. IEEE International Conference on Systems, Man and Cybernetics, San Antonio, 1994. Dieng R., Corby O. et Labidi S. AgentBased Knowledge Acquisition. European Conference on Knowledge Acquisition, EKAW’94, 1994.

Drogoul A., Ferber J., Corbara B. et Fresneau D. A Behavioral Simulation Model for the Study of Emergent Social Structures. Towards a Practice of Autonomous Systems, Bourgine P. et Varela F. (Ed.), MIT Press, pp. 161-170, Paris, 1992. Durfee E. et Montgomery T. Mice: A Flexible Testbed for Intelligent Coordination Experiments. Proc. of Ninth Workshop on Distributed AI, Benda M. (Ed.), Boing Computer Services, Orcas Islands, Seattle, 1989. Engelmore R. et Morgan T. Blackboard Systems. Addison-Wesley, 1988. Ferber J. et Carle P. Actors and Agents as Reflective Concurrent Objects: a Mering IV Perspective. IEEE Trans on Systems, Man and Cybernetics 21 (6), 1991. Finin T., Fritzson R., McKay D. et McEntire R. KQML as an Agent Communication Language. 3rd International Conference on Information and Knowledge Management (CIKM’94), ACM Press, 1994. Gasser L. Social Conceptions of Knowledge and Action: DAI Foundations and Open Systems Semantics. Artificial Intelligence 47 (1-3), 107-138, 1991. Gasser L., Braganza C. et Herman N. Mace: a Flexible Testbed for Distributed AI Research. In Distributed Artificial Intelligence, Huhns M. N. (Ed.), 119-152. Londres, Pitman, 1987. Giroux S. Agents et systèmes, une nécessaire unité. Thèse de Doctorat, Université de Montréal, 1993. Hayes-Roth B. A Blackboard Architecture for Control. Artificial Intelligence 26 (3), 251-321, 1985. Hayes-Roth B. et Collinot A. A Satisficing Cycle for Real-Time Reasoning in Intelligent Agents. Expert Systems with Applications 7, 31-42, 1993. Hewitt C. Viewing Control Structures as Patterns of Message Passing. Artificial Intelligence 8 (3), 323-374, 1977. Hewitt C. The Challenge of Open Systems. Byte, pp 223-242, 1985.

Hewitt C. Open Information Systems Semantics for Distributed Artificial Intelligence. Artificial Intelligence (special issue on foundations of AI) 47 (1-3), 79-106, 1991.

Smith R. G. A Framework for Distributed Problem Solving. Proceedings of IJCAI’79, 1979. Sycara K. Multiagent Compromise via Negotiation. In Distributed Artificial Intelligence, Gasser L. et Huhns M. (Ed.), London, Pitman, 1989.

Jennings N., Corera J. M. et Laresgoiti I. Developing Industrial MultiAgent Systems. First International Conference on Multi-Agent Systems, Lesser V. (Ed.), MIT Press, San Francisco, 1995.

Tokoro M. The Society of Objects. Proc. of the OOPSLA’93 Conference, 1993.

Lâasri H., Maître B. et Haton J.-P. Atome: outil d’aide au développement de systèmes multi-experts. Actes 6e journées sur la reconnaissance des formes et l’intelligence artificielle (RFIA’87), 749-759, Antibes, 1987.

Vernadat F. et Azemat P. Prototypage de systèmes d’agents communicants. Premières journées francophones sur l’intelligence artificielle distribuée et les systèmes multiagents, Toulouse, 1993.

Vanderveken D. Les actes de discours. Liège, Pierre Mardaga, 1988.

Lalanda P., Charpillet F. et Haton J.-P. A Real Time Blackboard Based Architecture. 10th European Conference on Artificial Intelligence, Vienne, Autriche, 1992.

Weihmayer R. et Brandau R. A Distributed AI Architecture for Customer Network Control. Globecom’90, San Diego, 1990.

Lesser V. R. et Corkill D. D. The Distributed Vehicle Monitoring Testbed: A Tool for Investigating Distributed Problem Solving Networks. AI Magazine 4 (3), pp. 15-33, 1983.

for Multi-Agent Systems. Chichester, Ellis Horwood, 1992.

Minsky M. La Société de l’Esprit. Paris, InterEditions, 1988. Parunak H. V. D. Industrial Applications of MultiAgent Systems. Industrial Technology Institute, Rapport de recherche 1993. Rao A. et Georgeff M. Social Plans: Preliminary Report. In Decentralized AI 3. Proc. of MAAMAW’91, Werner E. et Castelfranchi C. (Ed.), 127-146. Elsevier/North Holland, 1992.

Wittig T., ed. Archon: An Architecture

Wooldridge M. et Jennings N. Towards a Theory of Cooperative Problem Solving. Maamaw’94, Demazeau Y., Muller J.-P. et Perram J. (Ed.), Odense, Danemark, 1994. Yonezawa A., ed. ABCL: An ObjectOriented Concurrent System. Computer Systems Series. Cambridge, MA, MIT Press, 1990.

Sabah G. Caramel: A Computational Model of Natural Language Understanding using Parallel Implementation. Proc. of the Ninth European Conference on Artificial Intelligence (ECAI 90), Stockholm, 1990. Searle J. R. Speechs Acts. Cambridge, Cambridge University Press, 1969. Searle J. R. Expression and Meaning. Cambridge, Cambridge University Press, 1979. Shoham Y. Agent Oriented Programming. Artificial Intelligence 60 (1), 51-92, 1993.

* Les ouvrages marqués (Eds.) sont des recueils d’articles.