Réification des interactions : le modèle MIC* {Mouvement Interaction Calcul}*

6.2.4.1 Présentation

Dans la continuité de ce travail, [Gouaïch & Guiraud, 2002], [Gouaïch, 2003] proposent un modèle algébrique formel où les notions d'autonomie et d'interaction sont placées au centre de la problématique.

Pour garantir l'autonomie d'un agent, [Gouaïch, 2003] propose de considérer l'intégrité interne comme critère objectif. L'intégrité interne est une contrainte de programmation qui conçoit un agent autonome comme un système dont les dynamiques internes et la structure ne sont ni observables, ni contrôlables directement par une autre entité. Les processus de décision de l'agent doivent être entièrement et seulement déterminés par ses perceptions et ses comportements. Pour Gouaïch, l'intégrité interne est la condition sine qua none de l'autonomie.

If the external observer of an entity has enough knowledge and means to control its behaviors, this entity is not autonomous for this observer. By contrast, if the external observer lacks knowledge and means to control the behaviors of the entity, the later is autonomous since its outputs may change in response to the same stimulus. So, no matter if the behaviors of the software entity are actually changing over time; it is the lack of knowledge and control means that makes the software entity behaving as autonomous [Gouaïch, 2005].

Mais la définition d'une frontière entre l'agent et l'extérieur avec lequel il doit interagir, est un problème délicat. Car l'agent doit modifier les perceptions des autres. La difficulté réside alors dans la possibilité d'interaction entre les agents sans interférer sur leur intégrité. Ce paradoxe force les auteurs à identifier une entité non-agent chargée de gérer ces interactions. C'est l'environnement de déploiement des agents appelé MIC*, pour Mouvement Interaction Calcul

150

(l'astérisque signifie la répétition de ce processus sur N agents; le mouvement est une interaction particulière de l'agent avec son environnement et il est utilisé de façon récurrente dans les SMA). Sans rentrer dans les détails du modèle, on peut néanmoins noter que la notion d'interaction est centrale. En cela, MIC* s'inscrit parfaitement dans la définition proposée par [Singh, 1996] d'une approche orientée interactions :

"We introduce interaction-oriented programming (IOP) as an approach to orchestrate the interactions among agents. IOP is more tractable and practical than general agent programming, especially in settings such as open information environments, where the internal details of autonomously developed agents are not available".

Dans MIC*, les interactions sont réifiées sous la forme "d'objets d'interaction" qui constituent le seul moyen par lequel les agents agissent dans l'environnement.

L'agent (processus de calcul) est organisé en trois composants : sa structure interne, sa boîte de réception (inbox) et sa boîte d’émission (outbox). Les boîtes inbox et outbox recouvrent les notions de senseurs et d’effecteurs. Symétriquement, elles constituent la seule partie observable d’un agent.

De plus, ces boîtes d'échanges ne peuvent contenir que des objets d’interaction. Un agent est ainsi une entité qui ne perçoit le monde qu'à travers des objets d’interaction depuis son inbox. Il effectue un calcul pour produire de nouveaux objets d’interaction dans son outbox. Celle-ci personnifie la présence de l’agent dans un "espace d’interaction". En effet, à l'instar de la notion de rôle qui incarne l'agent dans AGR, un agent MIC* existe uniquement dans un espace d’interaction à travers ses boîtes d'échange.

MIC* repose également sur la mise en œuvre du principe "Influences-Réaction". En effet, les objets d’interaction peuvent jouer le rôle des influences produites par les agents. La réaction de l’environnement à ces influences correspond alors à l’application de règles chargées d'organiser les différents objets d’interaction pour calculer une réaction.

6.2.4.2 Applications

MIC* est un modèle formel dont une implémentation a été réalisée par Michel sur la plate-forme Madkit. Le Jeu de la vie, imaginé par John Horton Conway en 1970 et Sugarscape [Epstein & Axtell, 1996] ont servi pour illustrer des utilisations de MIC* dont on trouve une description détaillée dans [Michel, 2004]. Mais revenons sur quelques points concernant l'implémentation de Sugarscape.

Trois espaces d'interaction sont définis : World, Move (espace des influences de mouvement) et

Repro (espace des influences de reproduction). Deux types de processus de calcul sont présentés :

un processus par agent (modélisation du cerveau) et un processus pour les dynamiques de l'environnement (évolution endogène et réactions aux influences). Deux modes de gestion du temps sont proposés : une gestion classique par horloge et une gestion événementielle telle que préconisée par [Lawson & Park, 2000].

Les simulations à "pas de temps" constants gèrent les activités des agents. En accord avec la description de [Lawson & Park, 2000], les agents effectuent deux comportements par "pas de temps". Les déplacements sont activés en premier dans un ordre aléatoire. Dans un deuxième temps, le comportement de reproduction des agents est activé puis la réaction à ces influences est calculée. Michel remarque lui-même "qu'il peut bien sûr exister une différence suivant l’ordre dans lequel les différentes étapes de la réaction sont considérées". Dans le cas d'une gestion par horloge, MIC* ne supprime donc pas le problème lié à l'ordre d'activation des agents.

inbox ^Structure Interne ^outbox senseur effecteur inbox ^Structure Interne ^outbox senseur effecteur

151

En ce qui concerne la gestion événementielle, l'échéancier calcule la date de la prochaine activation d'un agent selon une loi de Poisson. Si statistiquement, les agents agissent tous uniformément, un agent donné peut aussi être activé plus souvent qu'un autre. D'autre part, une optimisation du simulateur était indispensable car sinon, les temps de calcul devenaient ingérables. Pour ce type de gestion, Michel souligne que "l'implémentation du mode événementiel recèle de nombreux pièges" et il admet que malgré l'attention portée à l'implémentation, il n'exclut pas de possibles erreurs.

La gestion des influences de mouvements consiste à recueillir les différentes influences moves(t)

émises par les agents puis, après calcul, à modifier leur position. Si un conflit survient, c'est-à-dire si plusieurs agents souhaitent se déplacer sur une même cellule, "le traitement des influences de mouvement consiste à considérer les influences dans un ordre aléatoire". MIC* ne supprime donc pas les problèmes de conflit entre les agents. La solution proposée peut sembler proche d'une gestion classique par horloge avec mélange aléatoire des agents. Mais ici, la résolution de conflit entraîne une nouvelle règle : "dans le cas où un agent souhaite se déplacer sur une cellule qui se trouve occupée, l’environnement calcule la cellule non occupée la plus proche de l’objectif initial et y place l’agent. Dans le cas où cette cellule n’existerait pas, le mouvement de l’agent est annulé" [ibid.]. Une gestion synchrone de type automate cellulaire pourrait également proposer un module de gestion de conflit basée sur le même principe.

Pour conclure sur l'utilisation de MIC* dans le cadre des simulations multi-agents, Michel reconnaît les difficultés rencontrées pour mettre au point un simulateur de type Sugarscape:

le modèle que nous avons proposé est assez complexe du fait de l’application du principe Influence/Réaction, du modèle MIC* et des différentes contraintes liées à la cohérence paradigmatique (distinction esprit/corps, intégrité environnementale, etc.). C’est pourquoi il conviendra de clarifier le plus possible les différents concepts qui sont manipulés lors d’une modélisation basée sur ces outils formels. La formalisation d’une loi d’interaction, d’une loi de computation et des différents objets d’interaction n’est pas forcément une tâche triviale en l’état.[ibid.]

6.3 CONCLUSION DU CHAPITRE

Ce chapitre propose un tour d'horizon sur les concepts d'autonomie rencontrés dans les systèmes multi-agents. Après avoir décrit les niveaux conceptuels traitant de cette notion, deux voies se dégagent. L'une aborde l'autonomie réelle des êtres vivants (autonomie faible) que les agents devraient émuler. On constate d'ailleurs que les êtres vivants sont moins autonomes qu'il n'y paraît. Leurs décisions dépendent fortement de leur milieu, de leurs besoins physiologiques et du couplage social dans lequel ils sont engagés. L'autre voie s'attache à décrire l'autonomie informatique en cherchant à protéger l'intégrité même des entités (autonomie forte).

Les partisans de l'autonomie forte déplorent que la notion d'autonomie reste seulement théorique. Ils refusent de considérer l'action comme une modification directe de l'état de l'environnement et des autres agents. Alors ils distinguent le geste de sa conséquence.

Ce rejet conduit à une nouvelle forme de gestion des actions basée sur le principe "Influences-Réaction". Pour assurer davantage l'intégrité informatique, une architecture telle que AGR, qui place l'organisation comme élément fondamental d'un SMA, interdit toute référence directe à un agent. Celui-ci n'est visible que par ses interfaces qui le matérialisent dans des espaces sociaux et physiques. De plus, afin de renforcer encore l'autonomie forte, l'agent est divisé en deux parties : son cerveau en charge de la cognition et son corps. Cette division est d'ailleurs accentuée puisque le corps devient un élément de l'environnement parmi d'autres auquel personne n'a directement accès, pas même son propre cerveau. Pour Michel, cette division corps/cerveau permet de respecter les "contraintes d’intégrité environnementale" :

152

Un agent n’est pas une entité en mesure de calculer les conséquences de ses actes. A ce titre, il est important qu’un agent ne soit pas en mesure de modifier directement les variables d’état de l’environnement. Autrement dit, les variables environnementales ne doivent pas être modifiées par les agents. C’est ce que nous avons appelé la contrainte d’intégrité environnementale.[Michel, 2004]

Finalement, ces concepts sont formalisés dans MIC* qui place l'interaction au cœur des modèles. Après la conception objet, après la pensée agent, MIC* peut être vu comme un nouveau paradigme de modélisation multi-interactionnelle, encore appelé IOP (interaction-oriented programming). Toutes ces propositions pour protéger l'autonomie des agents obligent souvent à diviser artificiellement ces derniers en deux parties indépendantes. Elles conduisent à considérer le corps de l'agent comme une entité étrangère répondant à des influences du cerveau. Et au final, c'est l'environnement qui détermine l'action effectivement réalisée.

Pour autant, est-il nécessaire de passer par de tels artifices pour concevoir tout type de SMA ? A-t-on réellement besoin d'une autA-t-onomie forte pour spécifier un modèle multi-agent pour aider à la gestion des ressources renouvelables ? Certes, lorsque l'on cherche à transposer l'autonomie d'un être vivant sur un agent, il est nécessaire de prendre des précautions afin d'éviter certains artéfacts. Des exemples présentés dans cette deuxième partie montrent que la modification directe de l'état d'un agent conduit parfois à des aberrations en termes de comportement avec des conséquences sur les résultats de la simulation.

Néanmoins, il ne me paraît pas nécessaire de passer systématiquement par des architectures compliquées pour émuler cette autonomie. D'ailleurs celles qui sont proposées ne résolvent pas les conflits liés aux actions simultanées interdépendantes et aux interactions. Je ne suis donc pas partisan de ces solutions qui me semblent trop compliquées et contraignantes pour le modélisateur. En fonction de ses objectifs, celui-ci peut émuler l'autonomie de ses agents par une approche classique (c'est-à-dire simplement objet). Il est par contre indispensable qu'il ait conscience des biais que peuvent entraîner des modifications directes des variables, qu'il les anticipe et propose des solutions adéquates en fonction de la situation. Par exemple, dans le cas des deux robots poussant une porte, il peut traiter le conflit par une solution standard de type automate cellulaire (variable tampon et mise à jour différée). Dans l'exemple de l'achat de poisson dans Mopa (chapitre précédent), il faut simplement que l'agent passif de la transaction (le pêcheur) mette à jour son état et fasse lui aussi le bilan de cette vente afin de rectifier le fonctionnement asymétrique de la transaction. Après un traitement standard de ce type, il est nécessaire d'en tester la robustesse en vérifiant les conséquences sur le comportement des agents et sur les simulations. Dans le cadre de la modélisation des ressources renouvelables, il ne me paraît donc pas opportun d'abandonner les approches maintenant classiques des SMA pour adopter des outils sophistiqués et contraignants pour protéger l'intégrité informatique des agents. Il est par contre nécessaire d'aborder la modélisation des interactions avec attention. Ces questions font l'objet du prochain chapitre.