Résumé : L'évolution de l'informatique nous fait considérer qu'il sera de plus en plus difficile - sinon impossible - de contrôler correctement l'activité des logiciels de complexité croissante et situés dans des environnements de plus en plus en plus dynamiques. Pour faire face à ces difficultés, la voie que nous explorons ici consiste à laisser plus d'autonomie aux logiciels afin qu'ils s'adaptent au mieux aux imprévus. Nous souhaitons ainsi montrer ce que peut apporter le domaine des Systèmes Multi-Agents à l'exécution du code et, plus particulièrement, au code mobile. Nous soulignons tout d'abord que ces termes ne peuvent pas être confondus puis nous proposons d'utiliser les caractéristiques de l'intelligence artificielle pour mettre en place de réels agents mobiles i.e. "agentifier " le code.

La première partie présente et compare les manières dont le traitement du code et l'intelligence artificielle ont évolué vers des systèmes ouverts dont l'évolution dynamique n'est pas toujours prévisible par les concepteurs de systèmes informatiques. D'où, l'évolution vers des systèmes auto-adaptatifs dont les propriétés, présentées dans la partie 2, permettent de proposer, dans la partie suivante, les lignes directrices de l'agentification du code. La partie 4 précise la manière dont les agents-code interagissent dans certaines circonstances, afin de toujours tendre vers une organisation coopérative. Avant de conclure, la partie 5 analyse quelques conséquences découlant de l'agentification des codes.

Mots-clés : Code mobile, système multi-agent, agent, autonomie, adaptation, auto-organisation.
 
 

1. L'évolution du code et des agents

Le code mobile, capable de s'exécuter de manière autonome là où il le souhaite, est souvent nommé agent mobile [Chess 94]. Or, ce terme d'"agent " est aussi utilisé en intelligence artificielle où il possède une signification particulière. Ainsi, en Intelligence Artificielle Distribuée et Systèmes Multi-Agents, un agent est défini comme "une entité physique ou logique capable d'agir sur elle-même et sur son environnement, qui dispose d'une représentation partielle de cet environnement et qui, dans un univers multi-agent, peut communiquer avec d'autres agents et dont le comportement est la conséquence de ses observations, de sa connaissance et des interactions avec les autres agents " [Ferber 95].

Le but de cette partie est d'établir un parallèle entre l'évolution de deux domaines de l'informatique : l'exécution du code et l'intelligence artificielle.

Les progrès technologiques ont permis, ces dernières années, une baisse des prix du matériel informatique et le développement rapide des réseaux. La taille de ces derniers augmente, les liaisons se font sans fils et ces réseaux sont capables d'évoluer dynamiquement (une machine peut se connecter/déconnecter de manière dynamique).

De plus, la démocratisation des ordinateurs et le développement d'Internet ont fait naître un nouveau profil utilisateur. Celui-ci est de plus en plus exigeant en matière de performance et de fiabilité et de moins en moins spécialiste en informatique.

Afin de s'adapter à ces tendances, les deux domaines qui nous intéressent ont dû évoluer dans le but de diminuer :

• le temps de réponse des applications pour les rendre plus performantes ;
• le contrôle externe pour alléger la tâche de l'utilisateur et celle du gestionnaire.

Pour rendre les outils informatiques de plus en plus performants, l'exécution d'applications logicielles a subi une évolution parallèle à celle du matériel.

S'exécutant tout d'abord séquentiellement, sur une machine, les applications sont devenues pseudo-parallèles. Une application est logiquement décomposée en activités et chaque activité (ou processus ou tâche) essaie de profiter des temps de blocage des autres activités pour s'exécuter sur la même machine. L'apparition de multiprocesseurs a permis de passer au stade suivant de l'évolution, celui du parallélisme réel. Les activités s'exécutent sur les différents processeurs d'une machine. Puis, l'évolution des réseaux a donné naissance aux systèmes répartis. Une application acquiert la faculté de percevoir un système réparti comme un supercalculateur; chaque activité s'exécute alors sur une des machines constituant ce réseau.

Dans un premier temps, la distribution d'une application a été rendue possible grâce à un placement statique des différentes composantes de l'application sur les différentes machines du réseau. Ces activités y sont placées lors de leur création et s'y exécutent jusqu'à leur terminaison [André 88]. Afin de profiter au mieux des instants d'inactivité ou de sous-activité des machines d'un réseau, le placement a évolué vers un placement dynamique dans lequel, à chaque création d'une activité, on se pose la question de savoir sur quel site du réseau on va la créer afin qu'elle s'y exécute [Talbi 97, Chatonnay 98]. Or, cette activité pourrait, si sa durée de vie est assez importante, s'exécuter plus efficacement sur un des autres sites du réseau par la suite. C'est pourquoi, des outils de migration de processus ou d'objets [Nutall 96] ont vu le jour. La plupart du temps, on souhaite équilibrer la charge de travail globale sur tous les sites d'un réseau. Une activité qui se déplace, de site en site, pour s'exécuter plus efficacement, ne le fait pas de sa propre autonomie. Il existe, en général, une composante du système sous-jacent qui décide quand, pourquoi et où faire migrer cette activité [Folliot 92, Litzkow 88].

Mais, l'apparition de l'informatique nomade (mobile) et le besoin de personnaliser le service selon l'usager ont fait apparaître la notion de code mobile [Bernard 99]. La différence avec la migration d'activités "classiques " est que c'est l'activité elle-même (i.e. le code) qui décide quand, pourquoi et où se déplacer. Elle devient autonome, elle part, avec ses données, s'exécuter ailleurs quand elle le désire.

1.2. L'évolution des agents

Parallèlement, le domaine de l'intelligence artificielle s'est posé un peu les mêmes problèmes et a évolué de manière similaire.

L'intelligence artificielle distribuée (IAD) et les systèmes multi-agents (SMA) étudient des techniques de résolution collective de problèmes par des entités appelées agents et situées au sein d'un même système. Ces logiciels sont employés pour simuler le comportement d'une collectivité naturelle (cellules, insectes, ...) ou pour créer des systèmes artificiels réalisant une fonction globale dans lesquels les connaissances, les traitements et le contrôle sont distribués. Cette problématique a été prise en compte au milieu des années 1970 lorsque les potentialités des systèmes à base de connaissances étaient beaucoup freinées par la centralisation des connaissances. Ainsi, cette limitation des systèmes à base de connaissances a été un des points de départ de l'IAD. Cette distribution du traitement permettait aussi d'aller vers des applications logiquement pseudo-parallèles.

Au sein de ces systèmes, la compétence est répartie chez des agents autonomes et interactifs qui décident quand intervenir dans la résolution.. Ils peuvent déléguer des tâches (Réseau contractuel de Davis&Smith) [Smith 80] ou s'échanger des résultats. Grâce à la distribution du contrôle, chaque composante de l'application devient autonome et évolue indépendamment des autres, bien qu'elle en ait encore besoin pour évoluer. Les interactions se font sous la forme de communications directes, par envoi de messages, ou indirectes, par le biais de leur environnement commun, qu'ils sont aptes à percevoir et transformer. Actuellement, des concepts comme l'autonomie, l'émergence, l'interopérabilité, l'hétérogénéité, sont de plus en plus pris en compte pour la définition et la conception des SMA.

Les travaux se focalisent moins aujourd'hui sur l'agent comme entité et plus sur la notion d'interaction. Ce n'est plus l'activité d'un agent qui est contrôlée, mais c'est l'agent qui tente d'agir sur son extérieur (l'environnement et les autres agents) pour le transformer selon ses besoins spécifiques. La manière dont le comportement d'un agent est guidé par ses interactions avec l'environnement est plus particulièrement vue dans le principe de l'éco-résolution de Ferber [Ferber 95]. La notion d'accointances ou de croyances sur les autres et sur soi se retrouve dans beaucoup de systèmes (Archon-Grate [Jennings 90], Synergic [Gleizes 91] ...), les notions de dépendance et de pouvoir entre les agents sont implémentées (DepNet de Sichman). Le contenu des informations échangées concerne non seulement le domaine d'application mais aussi guide la résolution. C'est en ce sens que le contrôle est dans l'interaction, il apparaît au travers d'un métalangage de communication. Les travaux sont orientés vers la définition de ces métalangages ou langages d'interaction [FIPA 97].

Avec le recul, nous savons aujourd'hui caractériser plus nettement -mais non formellement- les logiciels informatiques multi-agents :

• l'environnement dans lequel sont plongés les agents est dynamique, ne serait-ce que par la présence d'autres agents. Leur activité peut ainsi être remise en cause durant la vie du système : les agents ont une rationalité limitée temporellement ;
• les agents n'ont qu'une perception partielle de leur environnement. Ils ne peuvent garantir globalement la pertinence de leur action : ils ont aussi une rationalité limitée spatialement ;
• les agents ont des compétences restreintes : ils ont une rationalité limitée cognitivement. En conséquence, ils ne peuvent pas tout traiter individuellement et doivent s'associer pour réaliser l'activité globale.

Nous pouvons résumer l'évolution des deux domaines par le tableau suivant :
 

C'est grâce au besoin d'autonomie au sein des applications, que les deux domaines que sont l'IAD et les systèmes répartis voient leur évolution se rejoindre.

Nous avons vu que la notion d'autonomie existe dans le code mobile puisque ce dernier décide où s'exécuter.

Dans les SMA, la caractéristique principale des agents est leur autonomie. Grâce à ses capacités cognitives et relationnelles, un agent prend des décisions, effectue des actions en fonction de sa perception locale de l'environnement dans lequel il est plongé. Dans les systèmes adaptatifs, ces agents ont, de plus, la capacité d'"apprendre " ; cette propriété fait l'objet de la deuxième partie.

Dans la plupart des articles consacrés au code mobile [Chess 94, Green 97], le terme "agent " est utilisé pour désigner du code capable de partir s'exécuter, de manière autonome, ailleurs; on parle ainsi d'"agents mobiles ". Or, cette dénomination est souvent ambiguë, comme le souligne [Fuggeta 98]. Bien entendu, le terme agent rappelle la notion connue en IAD par la capacité que possède un agent mobile à décider de son propre devenir. Mais, ces deux termes doivent être distingués, les agents mobiles ne possédant pas les mêmes propriétés que les agents de l'IAD [Franklin 96]. Ainsi, quand les auteurs veulent être plus précis, ils parlent alors d'"agents mobiles " et d'"agents intelligents " [Thomsen 97, Vellino 97].

2. Les Systèmes Multi-Agents adaptatifs

• il n'existe pas de solution algorithmique permettant de passer du but final du système global à des sous-buts qui seront assignés à des parties du système. Il est pratiquement impossible d'optimiser toutes ces activités souvent concurrentielles ou contradictoires en satisfaisant au mieux tous les objectifs individuels.
• l'environnement dans lequel le système sera plongé est hautement dynamique et il est donc impossible de spécifier totalement toutes les situations auxquelles le système aura à faire face.
• le système développé est tellement complexe qu'il est pratiquement impossible de prouver qu'il réalise exactement la fonction souhaitée.

2.1. Auto-organisation par coopération dans des environnements dynamiques.

Il n'existe pas de bonne organisation d'un système dans l'absolu, mais elle est toujours contextuelle [Ashby 62]. Apprendre pour un système S consiste à transformer sa fonction actuelle f_S de manière autonome afin de s'adapter à l'environnement, considéré comme une contrainte qui lui est donnée. Chaque partie p_i du système S réalise une fonction partielle fp_i. L'environnement d'une partie p_i est constitué des autres parties du système ainsi que de l'environnement de S. La fonction globale de S notée f_S est le résultat de la composition de ces fp_i. La composition est déterminée par les relations - c'est-à-dire l'organisation - qui relie les parties. Ainsi, sans changer les parties, transformer l'organisation interne du système conduit à un changement de la composition des fonctions partielles et donc à une transformation de la fonction globale f_S.

Un système complexe adaptatif - parmi lesquels nous retrouvons beaucoup de systèmes biologiques - produit des phénomènes induits par des interactions entre de nombreuses entités individuelles, dont l'auto-organisation au niveau du système produit des propriétés d'adaptation émergentes, car non exhibées au niveau des individus. D'une manière générale, les échanges système-environnement entraînent des influences réciproques conduisant à un ajustement mutuel dû à leur couplage structurel. Ce processus a été observé depuis longtemps et modélisé avec des systèmes artificiels par exemple dans la boucle de rétroaction en cybernétique [VonFoerster 62]. L'imprévu étant inhérent à la vie de ces systèmes, l'auto-organisation, qui correspond à un changement décidé de manière autonome, devient un moyen pour parvenir à surmonter les perturbations éventuelles de l'environnement [Marcia 96].

2.2. Résultats théoriques de l'adéquation fonctionnelle.

Théorème : Pour tout système fonctionnellement adéquat, il existe un système à milieu intérieur coopératif qui réalise une fonction équivalente dans le même environnement.

La théorie que nous étudions et employons [Camps 98, Gleizes 99] affirme simplement le fait que si l'on souhaite réaliser un système fonctionnellement adéquat, alors un système dont les éléments (ou agents) sont en interactions coopératives convient sans que l'on connaisse cette fonction globale souhaitée. C'est un observateur hypothétique omniscient qui peut affirmer que les changements du comportement d'un système correspondent à un processus d'adaptation (i.e. l'adéquation fonctionnelle).

Cette théorie permet ainsi de guider un système pour s'adapter à un environnement dynamique (il n'est donc actuellement pas fonctionnellement adéquat), même si ce système ignore la fonction qu'il doit réaliser. Cette méthode d'adaptation possède plusieurs propriétés :

• un système coopératif dans l'environnement est fonctionnellement adéquat, ce qui lui évite de connaître la fonction globale qu'il doit réaliser pour s'adapter.
• cette théorie n'impose pas non plus de but au système, pour que celui-ci puisse agir dans son milieu. En fonction de ses perceptions de l'environnement, il agira pour que son comportement soit coopératif compte tenu de sa compétence et des croyances (s'il en dispose) sur celle des autres.
• la notion de rétroaction (feed-back), n'est pas contraignante dans cette théorie car le système doit seulement juger si les changements s'opérant dans le milieu sont coopératifs de son point de vue sans savoir si ces changements sont dépendants de ses propres actions passées.

2.3. Méthode de conception de systèmes multi-agents à fonctionnalité émergente

Ceci nous amène à un procédé de construction de système qui consiste à créer les agents du système et à leur attribuer ensuite un comportement pour qu'ils maintiennent des interactions coopératives de leur point de vue. Un système n'est pas monolithique, mais constitué de parties en interactions. Seules les parties sont spécifiées lors du développement ; et c'est le processus permanent d'auto-organisation qui déterminera sur le terrain la "bonne" organisation à chaque instant. Tant que nous ne pouvons pas garantir qu'une méthode de spécification classique est applicable pour une partie, nous la décomposons en sous-parties plus élémentaires qui s'auto-organiseront. Pour être cohérent avec la théorie, chacune des parties doit être constituée comme suit :

• de compétences qui lui permettent de réaliser la fonction partielle qui lui est assignée. Aucune contrainte technique n'est imposée pour le développement (système de production, méthode objet,...). Par exemple, un footballeur à des capacités de base comme dribbler, shooter, se déplacer,...
• de croyances qui lui permettent de raisonner sur son environnement et notamment d'autres parties du même système. Ces croyances peuvent être dynamiques, incomplètes ou erronées ; auquel cas il faudra le doter d'un apprentissage. Pour les footballeurs, chaque joueur de l'équipe a des croyances justes sur tous les autres partenaires.
• d'une attitude sociale qui est la coopération. Chaque agent est "câblé coopératif " pour garantir que le système converge bien vers l'adéquation fonctionnelle. Chaque action sera décidée de manière à gêner le moins possible les autres parties du système et même son environnement.

Le comportement de chacun des agents est ensuite spécifié de manière à ce qu'il essaye d'atteindre son objectif local tout en gardant des interactions coopératives avec les autres. Avant chaque action, l'agent analyse localement s'il est ou non en interactions coopératives c'est-à-dire il recherche s'il existe des situations non coopératives et tente de les éliminer pour revenir à un état coopératif. Ceci, car la coopération est l'attitude sociale qui guide son comportement.

Un agent a donc deux rôles essentiels : le premier est de réaliser la fonction pour laquelle il a été spécifié et le second est d'agir sur l'organisation interne du système s'il rencontre des situations non coopératives.

La détection de situations non coopératives n'est pas un moyen de gommer les problèmes comme les conflits ou la concurrence à l'intérieur du système ; c'est une alarme qui indique que l'état actuel du système est inadéquat avec les potentialités de certaines de ses parties. Le "bruit " local devient un moyen d'améliorer le fonctionnement global dont on postule qu'il n'est jamais parfait du fait de la connaissance incomplète que le système possède sur son environnement dynamique. Tous les comportements des agents que nous avons spécifiés sont conformes à cette méthode pour garantir l'adéquation fonctionnelle.

3. L'agentification du code

En introduction de la partie précédente, nous avons vu que certaines causes obligeaient à spécifier des systèmes artificiels en termes de systèmes complexes adaptatifs. Nous pouvons instancier ces causes avec des situations auxquelles le concepteur d'un système informatique se trouve habituellement confronté mais qu'il ne peut maîtriser :

• les besoins des usagers en termes d'environnement de développement et d'exécution changent régulièrement et sont donc difficilement prévisibles.
• les ordinateurs ont des caractéristiques techniques (mémoire, vitesse de traitement, périphériques, ...) qui dépendent d'une évolution technologique permanente. De plus, l'ère des portables et les facilités de connexion induisent des structures de réseaux de machines très évolutives.
• les logiciels supportés par ces machines subissent eux aussi des changements constants (systèmes d'exploitation, compilateurs, versions de langages, ...) qu'il est pratiquement impossible de prévoir au-delà de quelques années.

L'objectif de cette partie est donc de déterminer comment encapsuler un code utilisateur afin de le transformer en une entité répondant à la définition donnée dans la partie précédente. Pour faciliter la présentation, nous dirons que les agents-code sont nommés Ai, tandis que les sites qui constituent leur environnement local présent sont nommés Si. Tout Ai est constitué de compétences, de croyances, de capacités d'interaction et d'une attitude sociale coopérative. Nous présentons, dans la partie suivante, la manière dont l'attitude sociale d'un agent induit son comportement, tandis que cette partie décrit ses compétences et ses croyances.

3.1. Les objectifs d'un agent-code

On peut dire que l'objectif principal d'un code utilisateur se réduit à s'exécuter au mieux, que ce code soit fixe sur un site d'un réseau ou possède la possibilité de se déplacer au sein de ce réseau. Pour s'exécuter au mieux, il peut chercher à :

• optimiser le temps de réponse (par exemple, en s'exécutant sur un site le moins chargé possible) ;
• utiliser au mieux les différentes ressources d'un réseau (il ne peut pas s'exécuter localement car il lui manque une ressource, pourrait-il la trouver sur un autre site ?) ;
• répondre aux attentes de l'utilisateur (par exemple, en s'exécutant sans l'aide de ce dernier, de manière déconnectée et asynchrone).

3.2. Les compétences d'un agent-code

D'une manière générale, un code utilisateur a besoin d'une infrastructure lui permettant [Berbers 96]  :

• de s'exécuter sur un site avec gestion éventuelle des erreurs. Pour cela, un compilateur ou un interprète adéquat doit lui être fourni ;
• de communiquer avec l'utilisateur qui l'a créé (pour lui fournir un résultat, par exemple) ; mais aussi, avec d'autres entités, les différents codes s'exécutant sur un même site pouvant former un système faiblement couplé (ils peuvent partager des données, échanger des résultats, ...) ;
• d'assurer sa sécurité. Il doit être sûr que personne n'essaiera de corrompre son code. L'environnement a le même problème, il doit assurer sa propre intégrité en empêchant l'exécution de tout code mobile qu'il juge peu fiable ou malintentionné [Dale 97].

• agent-code utilisateur : c'est ce qui encapsule le code utilisateur ainsi que tout ce qui lui sert à redémarrer son exécution éventuellement ailleurs. Le but de cet agent est de s'exécuter au mieux, de profiter des ressources du système (de l'environnement) ;
• agent-code ressource : correspond aux différents types de ressources qu'un agent-code utilisateur désire acquérir. Ce dernier pourrait négocier leur utilisation. Il est donc utile de définir un langage commun  (ontologie).

En dotant le code utilisateur de cette faculté à être mobile, l'infrastructure, parfois nommée "agence ", doit lui permettre aussi de s'exécuter sur tout autre site que son site d'origine. Elle doit donc étendre les opérations d'exécution et de communication à un environnement réparti et assurer le transfert du code, de son contexte d'exécution (état, attributs, ...) et des ressources transférables qu'il utilise entre son site de départ et son site d'arrivée.

Si l'on suppose que seuls les agents-code utilisateurs peuvent se déplacer et que les agents-code ressource sont fixés sur leurs sites (ces derniers n'ont pour but que de satisfaire au mieux leurs clients), cela peut amener à définir deux agents-code ressources particuliers :

• agent-code réseau : il sait comment transférer le "c?ur " d'un agent-code d'un site à un autre ; il sait si cela sera bénéfique à l'agent-code. Représentant du réseau sous-jacent, il doit savoir estimer si le déplacement d'un agent-code lui est profitable en fonction des informations qu'il connaît sur cet agent (taille du code, état des communications, ...) et sur le réseau.
• agent-code sécurité : correspond à l'accueil sur le site et à l'aspect sécurité. Représentant du site, il est capable d'analyser l'agent-code lors de son arrivée sur son site. Il le laisse s'installer ou non localement, en fonction de ce qu'il connaît sur l'origine, le passé de l'agent-code (comme par exemple, l'utilisation CPU, la place mémoire occupée, les ressources demandées, l'identité du propriétaire, ...)

Le seul moyen d'interagir de manière pertinente avec d'autres agents est de disposer de croyances justes sur les compétences d'autrui (les informations nécessaires à leur activité ainsi que les résultats qu'ils produisent).

Sachant que nous situons, par définition, les agents-code dans un environnement dynamique, il doivent être dotés de capacités d'apprentissage de croyance. Ils pourront ainsi améliorer leur représentation sur l'environnement au fur et à mesure de leurs échanges. C'est ainsi que les interactions individuelles tendront en permanence vers des échanges coopératifs pour aboutir à une société d'agents-code qui est fonctionnellement adéquate (i.e. tous les objectifs individuels seront satisfaits au mieux des ressources disponibles).

Au cours de ses interactions, A1 a acquis de nouvelles croyances sur les compétences d'autrui (soit A2). Ces croyances (positives ou négatives) sont certainement ignorées de S1, sinon il les lui aurait communiquées pour avoir des échanges plus pertinents. A1 possède donc une représentation de l'environnement pouvant être profitable à d'autres agents qui auront des besoins similaires. Il va les communiquer à S1 ce qui améliorera l'organisation du système.

4. Les comportements coopératifs d'un agent-code

Un code est plongé dans un milieu constitué :

• de l'environnement dans lequel il peut se déplacer, agir (exécuter des commandes).

• des agents-code avec lesquels il a des activités complémentaires / coopératives : il bénéficie de l'activité d'autrui et son activité peut bénéficier à d'autres.
• d'autres agents-code avec lesquels il pourra être en concurrence, conflit, compétition pour accéder à des ressources partageables ou non. Ces situations non coopératives sont liées à une connaissance imparfaite de l'environnement ou à un manque de ressource.

4.1. Les situations d'incompréhension et d'ambiguïté

L'intercompréhension survient lorsque des agents interagissent sans aucune interprétation réciproque erronée : elle ne peut se juger que durant une période relativement longue d'échanges. Pour des agents autonomes, nous ne pouvons considérer qu'une compréhension instantanée locale à un agent : le cadre de ses compétences lui permet d'interpréter d'une manière unilatérale les signaux reçus. L'incompréhension correspond à l'impossibilité pour un agent d'interpréter un message reçu, tandis que l'ambiguïté autorise plusieurs interprétation contradictoires. Nous analysons ici les situations d'incompréhension les plus fréquentes d'un agent-code.

Exemple d'incompréhension de requête. A1 demande à A2 l'exécution d'une commande qu'il ne connaît pas. Dans les croyances dont il dispose, A2 peut vérifier si les paramètres évoqués sont pertinents pour d'autres agents. Le cas échéant, il relaxera la requête vers ceux-ci. Ainsi, les représentations réciproques des compétences seront améliorées, conduisant à une plus grande efficacité.

Exemple d'ambiguïté. A1 demande une réservation d'espace de 100. A2 ignore si l'unité demandée correspond à des bits, des Koctets dans la mémoire vive ou bien le disque. Plutôt que de rejeter la requête, A2 tente de lever l'ambiguïté en demandant les précisions nécessaires à A1. Après ajustement de croyances, il saura ultérieurement le type de données à préciser.

4.2. Les situations d'incompétence

A2 reçoit une demande de A1 qu'il ne peut satisfaire. Il peut en informer A1, mais surtout il va vérifier s'il connaît d'autres agents susceptibles de la satisfaire (ici A3). Si c'est le cas, non seulement A1 aura les résultats demandés mais surtout il connaîtra désormais un nouvel agent (A3) avec qui il n'aurait peut-être jamais pu interagir. L'organisation du système est ainsi améliorée.

Exemple de la compilation. A1 encapsule du code C et demande à A2 (compilateur C) de se faire compiler mais la version de ce compilateur n'est pas la bonne. A2 ne sait donc pas satisfaire A1 et cherche dans son entourage (sur un autre site) qui le pourrait, plutôt que de retourner un échec.

Avec les croyances dont il dispose A1 estime qu'il s'exécute mal sur son site courant S1. N'ayant aucun recours, il interroge S1 qui connaît un site S2 sur lequel il dispose de croyances pertinentes pour le problème. S1 fournit à A1 les moyens de migrer vers S2 pour aller s'y exécuter ou de créer un clone qui réalisera la tâche souhaitée. à l'encapsulation, le clone disposera d'un corpus de croyances lui permettant d'interagir de manière autonome dans ce nouvel environnement local. À la fin du traitement, S1 aura une représentation plus récente des compétences de S2, soit elle sera confirmée ou bien infirmée (dans le cas d'un échec d'exécution) car des croyances transiteront par retour entre les deux sites.

Exemple de l'équilibrage de charge entre sites. À un instant donné, un agent A1 estime que son site S1 est trop chargé (ou S1 estime qu'il est trop chargé et que A1 n'aurait pas dû venir ou ne devrait pas rester), il demande donc son avis à S1 qui lui indique sur quel site continuer son exécution dans de meilleures conditions.

S2 reçoit de S1 un agent qui doit réaliser une certaine activité (S1 croit S2 pertinent). Si le site S2 ne connaît pas d'agent compétent pour celle-ci, il va tenter de relaxer cet agent vers un site voisin S3 dont il croit qu'il dispose de compétences. À la fin du traitement, les croyances respectives des sites S1, S2 et S3 seront plus pertinentes.

Exemple de gestion d'un périphérique. Une imprimante sur S2 tombe en panne et ne peut plus rendre le service correspondant. S2 va envoyer le "fichier d'impression" vers un autre périphérique équivalent. Lorsque l'imprimante S2 redeviendra disponible, elle communiquera spontanément une offre de service à son voisinage. À mesure de l'évolution des demandes de la part des agents-code, le réseau global s'adaptera dynamiquement à l'apparition/disparition de ressources.

4.3. Les situations de conflit et de concurrence

Deux agents sont en conflit lorsqu'ils veulent accéder dans l'environnement à une ressource exclusive, qui ne sera plus jamais disponible pour le second lorsque le premier y aura accédé. La concurrence survient lorsque deux agents veulent réaliser la même activité.

Exemple de gestion d'espace disque. Deux logiciels ont simultanément besoin de beaucoup de mémoire pour stocker des données, de telle manière que la réservation pour A1 empêche définitivement la réservation pour A2. Cette information n'était préalablement pas connue par le site S1. Compte-tenu de ses contraintes, A1 peut accepter de migrer sur S2 ce qui ne pourrait pas être le cas de A2. La négociation a pu résoudre ce conflit à la satisfaction de tous les codes.

Exemple de compilation concurrente. Deux agents-compilateurs A1 et A2 peuvent être présents sur S1 et être aptes à compiler un agent-code utilisateur A3. Par le fait de croyances antérieures, A3 sollicite directement A1 qui lui connaît un agent A2 qui dispose des mêmes compétences mais est une version plus récente. Il peut lui communiquer la requête et à la fin du traitement les croyances seront plus pertinentes.

5. Discussion

5.1. L'émergence d'un réseau fonctionnellement adéquat

Les situations non coopératives présentées dans la partie précédente avaient pour objectif de montrer comment l'activité individuelle locale peut apporter une amélioration au fonctionnement global du réseau, alors que la perception et l'action des agents sont strictement locaux. Un observateur externe au réseau et qui connaîtrait par avance tous les besoins des agents-code et des ressources disponibles trouverait que l'activité globale est proche de l'optimal. Cela signifie que s'il existe une solution répondant aux contraintes d'activité d'un code, alors le réseau la trouvera.

Cette propriété découle directement du théorème énoncé, à condition que l'ensemble des situations non coopératives d'un agent-code soit correctement spécifié. Pour garantir des comportements coopératifs adéquats, il est indispensable qu'ils soient spécifiés et contrôlés exclusivement par les fournisseurs des sites. Tous les codes sont ainsi exclusivement automatiquement encapsulés par ces agents génériques certifiés.

Même si les exemples présentés ne sont pas exhaustifs, le nombre de situations d'un agent est relativement limité et les échanges nécessaires pour rétablir une activité coopérative peuvent être supportés par un nombre réduit d'actes de langage. Par exemple, la gamme des actes formalisés dans les ACL de Fipa [Glize 99] sont très largement suffisants.

5.2. La typologie des agents-code

Dans la partie précédente, nous avons présenté un panorama des activités correctrices qu'un agent-code pouvait tenter dans le but d'aboutir à l'adéquation fonctionnelle de l'ensemble des systèmes informatiques interconnectés. L'identification des agents que nous avons fait dans la partie 3.2 n'est pas absolue, car il est possible de considérer que des parties d'un système opératoire puissent être agentifiées. Par exemple, un compilateur ou un interpréteur pourraient devenir des agents-code. Quelle en serait l'utilité ?

Nous pourrions avoir une configuration dans laquelle S1 posséderait un compilateur adéquat pour compiler un agent-code utilisateur donné mais avec des ressources insuffisantes. Par contre, S2 possédant un environnement système similaire disposerait de ces ressources, mais pas de compilateur. Si le compilateur n'est pas un agent coopératif, la seule manière est de réaliser l'installation manuelle du compilateur sur S2 ... ou d'échouer à la compilation. Un agent-compilateur pourrait, après demande de traitement de l'agent-code utilisateur, migrer vers S2, s'installer pour exécuter l'agent-code utilisateur puis disparaître. Aucun plan global préalablement spécifié n'est nécessaire : c'est seulement l'activité locale d'agents coopératifs qui aboutit à la solution (si elle existe). Mais, elle n'est possible que si des éléments du système opératoire sont agentifiés. De plus, si plusieurs agents-code demandent ce compilateur, cela pourrait conduire à le déplacer sur S2. Cela constitue une ouverture vers la mise à jour automatique de logiciels.

Il en découle une question sur la typologie des agents-code. Si les agents-code utilisateurs ont des comportements coopératifs similaires, il faudra vérifier par un classement typologique exhaustif que des agents-code de nature différente n'aient pas d'autres comportements à implanter. Dans ce cas, l'encapsulation dépendra d'un type identifiant chaque agent-code ; en sachant toutefois que cette typologie sera, par nature, très limitée.

5.3. Agentification, hétérogénité et sécurité

Parmi les présupposés de cette approche, les sites sont considérés hétérogènes (machines, systèmes opératoires, ..) ce qui rend illusoire la possibilité de réaliser le même codage pour les agents. Actuellement, les seuls codes pratiquement mobiles sont ceux qui sont écrits dans un langage interprétable sur le site d'accueil comme Java. Cette contrainte n'est pas admissible si les agents sont aussi des codes " ressources " tels les compilateurs précédemment cités. Nous aurons donc autant de versions différentes d'agents génériques (qui encapsulent les codes) que de types de sites, bien qu'ils aient des comportements identiques.

Une conséquence évidente est que l'accueil d'un code mobile sera effectué en l'encapsulant dans un clone d'agent générique du site. Il sera toujours coopératif selon les critères définis et recevra en outre des croyances sur d'autres agents ou éléments de l'environnement du site récepteur avec lequel il sera potentiellement amené à interagir de manière autonome. Ainsi, ce n'est pas l'agent qui migre au sens strict mais seulement le noyau (qui correspond à sa compétence) : il constitue le corps d'un message transitant entre le site émetteur et le site récepteur.

La méthode d'encapsulation du code utilisateur dans un agent peut aussi induire des conséquences sur la sécurité. Comme ce sont des messages signés qui circulent entre sites, le résultat d'un traitement retournera nécessairement au site expéditeur d'origine : même s'il s'agissait d'une contrefaçon, le contrefacteur n'aura jamais de retour. Ainsi, un code agentifié peut être aussi sécurisé que toute technique usuelle de communication à distance : l'exécution du code n'apportera ni plus ni moins de conséquences sur l'intégrité du site.

6. Conclusion

L'adéquation fonctionnelle d'un système (les réseaux d'ordinateurs et les logiciels qu'ils supportent dans notre propos) ne peut s'obtenir que s'il possède une représentation parfaite, préalablement à toute activité. Cette situation survient uniquement dans un monde clos, ce qui permet d'employer des méthodes de spécification globale descendante classique des systèmes artificiels. Mais cela ne peut être le cas dans des systèmes ouverts qui possèdent de nouveaux composants (processus) et qui sont situés dans des environnements dynamiques (nouvelles ressources). Dans ces situations, seule une approche adaptative est pertinente pour tendre vers l'adéquation fonctionnelle, sans jamais l'atteindre. La difficulté est de permettre à un système d'apprendre sans pouvoir spécifier parfaitement la fonction globale et en évitant l'écueil d'attracteurs locaux qui rendraient le système sous-optimal. C'est ce à quoi la théorie de l'auto-organisation coopérative peut aboutir ; et nous avons tenté de montrer comment elle peut s'appliquer pour spécifier des agents-code.

Mais si l'agentification du code peut améliorer l'activité des systèmes informatiques, une volonté forte est aussi indispensable pour se lancer dans cette direction. Faut-il pour cela faire table rase du passé et stopper brutalement toutes les machines pour les doter désormais (et uniquement) de systèmes à agents ? Il faut heureusement répondre par la négative, car ce passage peut se réaliser incrémentalement. Un agent-code peut en effet être doté de capacités à interagir avec d'autres agents, mais aussi d'interagir de manière plus traditionnelle avec les non-agents.

Mais, nous sommes encore aujourd'hui relativement éloignés de cette optique "tout-agent" de gestion des systèmes informatiques. Tous les outils nécessaires existent cependant : les supports à la mobilité du code ainsi que les techniques d'adaptation par auto-organisation. Par habitude et sécurité, nous préférons néanmoins apporter des réponses traditionnelles à un problème qui ne peut pas les accepter. Le pas à franchir est donc principalement intellectuel pour disposer de supports informatiques qui seraient beaucoup plus faciles d'emploi et plus performants collectivement, à l'heure où la très grande majorité des machines s'interconnectent dans un réseau mondial.

7. Références bibliographiques

[André 88] F. André et J.L. Pazat
" Le placement de tâches sur des architectures parallèles " - T.S.I., 7, n° 4, 1988, p. 385-401.

[Ashby 62] W. R. Ashby
" Principles of the self-organizing system - Principles of self-organization "
H.Von Foerster, G.W.Zopf Editors - Pergamon Press, 1962.

[Berbers 96] Y. Berbers, B. De Decker et W. Joosen
" Infrastructure for mobile agents "
Proc. Of the 7^th ACM SIGOPS European Workshop : System support for worlwide applications,
pp173-180, 1996.

[Bernard 99] G. Bernard
" Technologie du code mobile : Ètat de l'art et perspectives "
Actes du Colloque Francophone sur l'Ingénierie des Protocoles, Nancy, France, April 26-29, 1999.

[Camps 98] V. Camps, M-P. Gleizes et P. Glize
" Une théorie des phénomènes globaux fondée sur des interactions locales "
Journées francophones sur l'IAD & les SMA - Éditions Hermès, 1998.

[Chatonnay 98] P. Chatonnay
" Gestion de l'allocation des ressources aux objets dans les systèmes répartis,
une approche multicritère intégrant les communications "
Thèse de l'université de Franche-Comté, Janvier 1998.

[Chess 94] D. Chess, C. Harrison, A. Kershenbaum et T. Watson
" Mobile Agents: Are they a good idea ? " - IBM Research Report - 1994

[Ferber 95] J. Ferber
" Les sytèmes multi-agents. Vers une intelligence collective "
Editions InterEditions 1995

[FIPA 97] "FIPA'97 Specification Foundation for Intelligent Physical Agents"
Part2, Agent Communication Language - drogo.cselt.stet.it.fipa - 0ctober 1997

[Folliot 92] B. Folliot
" Méthodes et outils de partage de charge pour la conception et la mise en ?uvre
d'applications dans les systèmes répartis hétérogènes "
Thèse de l'université Pierre et Marie Curie, Paris VI, Décembre 1992.

[Franklin 96] S. Franklin et A. Graesser
" Is it an agent or just a program ? : A Taxonomy for autonomous agents "
Proc. of the 3rd Int. Work. on Agent Theories, Architectures and Languages, Springer-Verlag, 1996.

[Fuggetta 98] A. Fuggetta, G.P. Picco et G. Vigna
" Understanding code mobility "
IEEE Transactions on Software Engineering, Vol 24, No 5, pp 342-361, 1998.

[Gleizes 91] M-P. Gleizes et S. Trouilhet
" Conception d'un système multi-agent: étude de la coopération dans SYNERGIC "
8 ième Congrès Reconnaissance des Formes et Intelligence Artificielle - Villeurbanne, 1991

[Gleizes 99] M-P. Gleizes, V. Camps et P. Glize
" A theory of emergent computation based on cooperative self-organization for adaptive
artificial systems " - Fourth European Congress of Systems Science - Valencia, 1999

[Glize 99] P. Glize, M-P. Gleizes et A. Léger
" Brokerage communication in a cooperative multi-agent based mediation service :
one example in Abrose " - Foundation for Intelligent Physical Agent CFP6_016, 1999.

[Green 97] S. Green, L. Hurst, B. Nangle, P. Cunningham, F. Somers et R. Evans
" Software agents : a review " - Report 27 May 1997

[Jennings 90] Jennings N.R. et Wittig T.
" ARCHON: Theory and practice " - In DAI: Theory and Praxis, Avouris & Gasser (p179-195)

[Litzkow 88] M.J. Litzkow, M. Livny et M.W. Mutka
" Condor : A Hunter of Idle Workstations "
Proc. of the 8th Int. Conf. on Dist. Comp. Syst. - San Jose, Ca - pp104-111 - Juin 1988.

[Marcia 96] MARCIA
" Auto-organisation : émergence de structures "
Journées du PRC GDR IA : les systèmes multi-agents, 1996.

[Nutall 96] M. Nutall
" Survey of systems providing process or object migration "
Imperial College Research Report DoC 94/10 - November 1996.

[Smith 80] R. G. Smith
" The contract net protocol: high-level communication and control in a distributed problem solver " IEEE transactions on Computers, C-29 N°12 pp 1104-1113, December 1980

[Talbi 97] E. G. Talbi
"Une taxonomie des algorithmes d'allocation dynamique de processus
dans les systemes parallèles et distribués " - ISYPAR'97, Toulouse, France, pp 137-164, Mars1997

[Thomsen 97] L. Thomsen et B. Thomsen
" Mobile Agents - The New Paradigm in Computing "
ICL Systems Journal - Vol 12, n1, May 1997.

[Vaari 94] J. Vaari
" Modeling Adaptive Self-organization "
Artificial Life IV edited by Brooks and Maes MIT Press 1994

[Vellino 97] A. Vellino
" What are mobile agents good for anyway ? "
http://ai.iit.nrc.ca/~andre/publications/whataremobileagentsgoodfor.html

[Von Foerster 62] H. Von Foerster et G. W. Zopf, Editors
" Principles of self-organization "
Pergamon Press, 1962.