FR 2877115 A1 20060428 FR 0411309 A 20041022 Dispositif et procédé d'interprétation sémantique d'évènements, mis en oeuvre dans un agent logiciel 1. Domaine de l'invention La présente invention concerne l'interprétation sémantique d'évènements 5 traités dans un agent logiciel. En particulier, l'invention a trait aux programmes d'ordinateur dits ouverts, c'est-à-dire des programmes dotés d'une capacité d'interprétation du sens des événements qu'ils perçoivent ou des messages qu'ils reçoivent, indépendamment de la forme de ces derniers et de tout protocole de communication utilisé. De façon plus précise, l'invention concerne le domaine des programmes qualifiés d'agents logiciels dont la capacité de compréhension du sens des messages échangés avec d'autres programmes logiciels, du même type ou non, est associée à un comportement rationnel , c'est-à-dire prévisible et en parfaite cohérence avec le sens du message reçu. On rappelle ici les définitions communément retenues pour les notions d'agent logiciel et par extension, d'agent logiciel intelligent. Un agent logiciel est défini comme une entité physique ou virtuelle: capable d'agir dans un environnement donné, - capable de communiquer directement avec d'autres agents logiciels, 20 qui est mue par un ensemble de tendances et/ou de règles, - qui possède des ressources qui lui sont propres, - qui est capable de percevoir de manière plus ou moins limitée son environnement, et qui ne dispose que d'une représentation partielle de cet environnement, - qui possède des compétences, - qui offre des services, - qui peut éventuellement se reproduire. Par extension, un agent logiciel intelligent est défini comme une entité logicielle visant notamment, et de façon non limitative, à simplifier et/ou à faciliter la recherche et la gestion d'information dans un environnement local ou distribué, du type système d'information local et/ou distribué, systèmes de bases de données locaux ou distribués, Internet, etc. Un tel agent possède des attributs qui lui sont propres et agit dans le but d'accomplir un certain nombre de tâches pour lui-même, pour un autre agent logiciel ou pour un humain. Ainsi, parmi les attributs qui servent le plus souvent à caractériser les agents logiciels intelligents, on trouvera de façon non exhaustive et donc non limitative: - l'autonomie: un agent logiciel est capable de prendre des initiatives de manière autonome et d'exercer un contrôle sur ses actions; - la collaboration: un agent est capable d'interagir et/ou de collaborer avec d'autres 10 agents logiciels, ou encore, avec des êtres humains dans le but d'accomplir ses actions; - l'apprentissage: un agent est capable de s'adapter aux besoins de son utilisateur et/ou de son environnement en analysant les actions passées; - la réactivité : un agent répond dans le temps aux changements dans son 15 environnement; - la proactivité : un agent peut accepter des requêtes humaines précises mais décide de quelle manière les satisfaire, et n'agit pas seulement suite à un changement détecté dans son environnement; de plus, un agent travaille de manière continue; - la flexibilité : les actions d'un agent ne sont pas entièrement prédéfinies; l'agent est capable de choisir ce qu'il va faire et dans quel ordre il va le faire; - la liberté d'action: contrairement à un logiciel ordinaire, un agent peut décider de lui-même la date de déclenchement d'une action; - la mobilité : un agent est éventuellement capable de se déplacer d'une machine à une autre au travers de plateformes matérielles et d'architectures logicielles différentes, voire même au travers de réseaux de communication publics ou privés. 2. État de la technique Le champ d'utilisation des techniques de développement à base d'agents logiciels s'est considérablement étendu ces dernières années. Initialement plutôt destinées à permettre la distribution de traitements complexes et gourmands en ressources matérielles et/ou logicielles sur un grand nombre de petites entités spécialisées, ces techniques sont de plus en plus souvent mises en oeuvre à l'échelle de réseaux hétérogènes. Ce type d'approche permet notamment de pouvoir réaliser une mise en relation d'entités logicielles indépendantes réalisant de manière autonome, pour le compte d'applications variées, des fonctions plus complexes. Dans ce contexte, l'autonomie des agents logiciels dans un environnement donné, ainsi que leur interopérabilité dans cet environnement, sont devenues des caractéristiques essentielles. Aujourd'hui, seul le consortium FIPA (pour Foundation for Intelligent Physical Agents en anglais ou Fondation pour des agents physiques Intelligents en français) fondé en 1996, se préoccupe de définir et de publier des spécifications visant à rendre possible l'interopérabilité entre des agents logiciels hétérogènes. Notamment, le langage de communication inter-agent FIPA-ACL (pour Agent Communication Language en anglais ou Langage de Communication d'Agent en français) propose un formalisme, fondé sur la théorie (philosophique) des actes de langage, qui: permet une représentation précise et non ambiguë d'un message envoyé par un agent à d'autres agents, - spécifie formellement la signification de tels messages en termes de préconditions et d'effets sur les états mentaux des agents, c'est-à- dire leurs états internes de croyances et d'intentions relativement à d'autres agents, et de principes de rationalité que doivent observer les agents pour interpréter ces préconditions et/ou ces effets. Cependant, si les travaux conduits par le consortium FIPA visent effectivement à permettre à terme une interopérabilité au niveau des échanges de messages entre agents logiciels hétérogènes, la sémantique formelle des messages spécifiée en annexe du standard FIPA n'est aujourd'hui implémentée dans aucune plateforme. Seules les spécifications relatives aux protocoles de communication du standard FIPA le sont. En conséquence, le développeur d'agents logiciels est aujourd'hui contraint de coder et/ou de décoder la sémantique des messages devant être échangés entre les agents logiciels, ce décodage se faisant aussi parfois en contradiction avec les exigences des spécifications du standard FIPA, avec pour conséquence l'impossibilité de faire communiquer et interopérer les agents logiciels entre eux. A ce jour, il existe à notre connaissance très peu de techniques à même de résoudre de façon satisfaisante le problème de l'interopérabilité entre des agents logiciels, et plus précisément, entre agents logiciels hétérogènes n'ayant pas été mis en oeuvre par un même développeur, ou par des développeurs travaillant conjointement ou en collaboration sur les types de messages échangés par les agents logiciels qu'ils développent. La plupart des techniques connues à ce jour s'appuient sur la mise en oeuvre d'agents dans l'objectif de résoudre un problème de façon distribuée, ou de distribuer le traitement d'une tâche auprès d'agents logiciels éventuellement spécialisés et distribués sur différentes machines distantes. Dans ce sens, on citera à titre d'exemple illustratif le document de brevet américain n US6144989 intitulé Adaptive agent-oriented software architecture (pour Architecture logicielle adaptative orientée agent en français) qui décrit une méthode et une architecture multiagent autorisant la distribution d'un traitement associé à une requête d'un utilisateur sur un ensemble d'agents organisés hiérarchiquement. Plus précisément, dans le document précité, chaque agent logiciel traite simplement une partie de la requête initiale en fonction de ses compétences. Ceci suppose donc la propagation de la requête initiale sur les différents agents logiciels, en fonction de leurs compétences respectives et/ou éventuellement de la puissance de traitement délivrée par la machine exécutant ledit agent. En outre, pour autoriser les agents logiciels impliqués dans la résolution du traitement de la requête initiale à coopérer, la technique décrite dans ce document prévoit un formatage prédéterminé de chaque type de message pouvant être potentiellement échangé entre les agents logiciels considérés. De plus, la technique décrite n'autorise en aucun cas le traitement de messages autres que ceux provenant directement d'un utilisateur, en particulier de messages qui pourraient provenir d'agents ou d'applications logiciels externes au système multiagent considéré. Enfin, dans la technique décrite dans le document de brevet précité, la modification de l'état courant d'un agent est effectuée uniquement sur la base d'une requête d'un utilisateur, sans aucune possibilité d'inculquer audit agent un comportement proactif nécessaire pour le rendre autonome. Par ailleurs, un second document de brevet américain n US 2004/0059698 intitulé Method and system for a software agent control architecture (ou Méthode et système pour une architecture de contrôle basée agent logiciel en français), propose une méthode et un système de mise en oeuvre associé permettant de concevoir et de développer des agents logiciels à partir de briques de base réutilisables, baptisées règles . Ces règles s'exécutent sur une infrastructure baptisée moteur de règles dont le rôle consiste à permettre une interopérabilité entre les agents logiciels développés à partir du même ensemble de règles initiales. Cependant, la technique décrite dans ce second document propose un traitement par les règles basé sur la forme du message échangé entre les agents, mais en aucun cas basé sur le sens contenu dans ces derniers. En outre, dans cette technique, l'agent est contraint d'agir uniquement à la suite d'une requête de l'utilisateur, sans aucune possibilité donc, d'inculquer un comportement proactif à l'agent, ce qui limite de nouveau son autonomie. Enfin, l'application des règles est entièrement dirigée par les buts de l'agent, et non pas par la compréhension du message reçu, de sorte que l'agent résultant ne dispose d'aucune capacité d'interopérabilité avec d'autres agents logiciels, notamment dans un environnement hétérogène. Parmi les techniques connues, on pourra citer enfin le document de brevet français n FR 2 787 902 du même déposant. La technique décrite dans ce document s'appuie sur un système de dialogue intelligent mis en oeuvre par au moins un agent logiciel dont le comportement rationnel, c'est-à- dire le comportement recherché, respecte les mêmes principes que ceux du modèle formel sous-jacent au langage de communication FIPA-ACL (pour Foundation for Intelligent Physical Agent Agent Communication Language en anglais ou en français: Langage de communication entre agents du standard FIPA). Plus précisément, la technique décrite dans ce document de l'art antérieur met 5 en oeuvre un mécanisme de compréhension du sens des messages reçus en provenance de l'utilisateur ou d'autres agents. Cependant, un tel mécanisme impose la mise en oeuvre d'un moteur d'inférence syntaxique pour la logique multimodale du premier ordre sousjacente au modèle formel considéré. Or un tel moteur d'inférence n'existe pas encore sur le marché public. Cet état de fait constitue l'une des raisons principales expliquant pourquoi aucune plate-forme conforme à certains standards n'offre aujourd'hui les éléments, même de base, qui permettraient une mise en oeuvre de la sémantique d'un langage comme FIPAACL par exemple, au niveau des messages échangés entres des agents logiciels, et permettrait ainsi l'interopérabilité entre ces derniers, telle que spécifiée par exemple dans le standard FIPA. En outre, l'architecture revendiquée dans le document précité, ne permet en aucun cas à un agent rationnel ainsi construit de générer un comportement proactif, c'est-à-dire qui ne soit pas nécessairement consécutif à un message reçu en provenance de l'utilisateur ou d'un autre agent. 3. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces divers inconvénients de l'état de la technique. Plus précisément, un objectif de l'invention est de fournir un dispositif et un procédé autorisant un développeur à ne plus prendre à sa charge la mise en oeuvre de l'interprétation du sens des messages échangés entre les agents logiciels qu'il développe. Notamment, un objectif de l'invention est de fournir un dispositif et un procédé qui soient universels d'une part en termes d'échange de messages entre agents logiciels, et d'autre part, en termes de compréhension et d'interprétation sémantiques des messages échangés par ces agents logiciels. Un objectif supplémentaire de l'invention est de fournir un dispositif et un procédé qui favorisent l'interopérabilité entre agents logiciels hétérogènes, c'est-à-dire entre agents logiciels n'ayant pas été développés par une même équipe de développeurs, ou évoluant dans des environnements applicatifs différents depuis lesquels ils doivent pouvoir interopérer. Un autre objectif de l'invention est de conférer aux agents logiciels mis en oeuvre, un comportement proactif et non plus uniquement réactif à des événement externes, ainsi qu'une plus grande autonomie. Un objectif complémentaire de l'invention est de fournir un dispositif et un procédé qui favorisent la mise en oeuvre de principes formels définissant la sémantique d'un langage de communication entre agents logiciels hétérogènes. Enfin, un autre objectif de l'invention est de fournir une technique qui soit simple de mise en oeuvre et d'exploitation, favorisant ainsi une diminution des temps et donc des coûts de développement logiciel. 4. Résumé de l'invention Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un dispositif d'interprétation sémantique mis en oeuvre dans au moins un premier agent logiciel, qui comprend avantageusement: des moyens de capture d'évènements survenant au niveau du premier 20 agent logiciel; des moyens de traduction de chacun des évènements en une représentation sémantique initiale interprétable; des moyens d'identification par au moins une itération d'au moins un modèle d'interprétation sémantique conforme à la représentation 25 sémantique initiale, le modèle appartenant à une liste ordonnée de modèles d'interprétation sémantique prédéfinis; des moyens d'interprétation du sens de chacun des évènements par l'application d'au moins un modèle d'interprétation sémantique identifié à la représentation sémantique initiale; des moyens d'exécution et/ou de génération d'au moins une opération par le premier agent logiciel en réaction auxdits évènements dont la sémantique a été interprétée. Il s'agit notamment de proposer un mécanisme permettant de mettre en oeuvre les principes formels définissant la sémantique d'un langage de communication, par exemple tel que FIPA-ACL, dans un agent logiciel qui pourra alors réagir de façon naturelle et cohérente relativement au sens des messages qu'il reçoit, défini conformément au modèle formel d'interprétation sémantique sous-jacent, et non plus relativement à la forme syntaxique des messages ou à un protocole pré-établi, comme c'est le cas dans les techniques de l'art antérieur. De façon avantageuse, les évènements survenant au niveau de l'agent logiciel sont soit des événements internes générés de façon autonome par l'agent lui-même dans l'exécution de ses opérations, soit des messages provenant d'autres agents logiciels avec lesquels l'agent doit interopérer. Un intérêt particulier d'une gestion identique au niveau de l'agent aussi bien des messages reçus d'autres agents logiciels que des évènements générés par l'agent lui-même en interne, concerne d'une part la généricité de l'approche, et d'autre part, la possibilité de pouvoir conférer un comportement proactif à l'agent logiciel, celui-ci étant à même de faire évoluer son comportement en fonction de ses propres actions qu'il aura pu générer. Une telle solution technique est un enrichissement considérable en termes d'amélioration de l'autonomie et de l'adaptabilité des agents logiciels, notamment lorsque ces derniers doivent interopérer et/ou coopérer avec d'autres agents logiciels évoluant dans des environnements applicatifs le plus souvent hétérogènes. Préférentiellement, les opérations, encore appelée activités dans le domaine des agents logiciels, exécutées et/ou générées par l'agent logiciel sont à considérer comme des suites d'actions unitaires coordonnées et dont l'effet recherché au niveau de l'agent logiciel est dirigé par le sens d'au moins un des événements ayant été interprété, de façon à faire évoluer le comportement dudit agent. De façon avantageuse, les actions unitaires précitées sont des actions sémantiques dont l'exécution est contrainte par la vérification d'au moins une précondition de faisabilité, de manière à obtenir un effet rationnel dans le comportement de l'agent logiciel concerné. Un tel mécanisme d'interprétation sémantique des évènements perçus par un agent logiciel repose donc principalement sur le calcul d'une représentation sémantique pour chaque message reçu ou chaque événement interne généré par un agent (par exemple, et de façon non limitative, dans le même formalisme que celui utilisé pour spécifier la sémantique formelle de FIPA-ACL, à savoir le langage logique FIPA-SL pour FIPA- Semantic Language en anglais ou Langage Sémantique FIPA en français) et sur un algorithme d'application de modèles d'interprétation sémantique. Une telle représentation sémantique et un tel algorithme mettent notamment en oeuvre chacun, tout ou partie d'un principe formel sous- jacent à la définition de FIPA-ACL, à savoir par exemple, le calcul d'une précondition de faisabilité, la recherche d'un effet rationnel dans le comportement de l'agent, l'application d'un schéma d'axiome logique, etc. Ils peuvent également permettre de modifier la représentation sémantique précitée pour un agent logiciel et/ou de lancer une opération particulière de l'agent (laquelle peut alors envoyer d'autres messages vers d'autres agents ou accomplir des tâches spécifiques au domaine d'application). Outre cette capacité d'interopérabilité ouverte, l'architecture préconisée, qui repose entre autres sur les concepts d'activité de l'agent et d'événement interne, permet également de doter les agents d'une qualité d'autonomie. En particulier, elle autorise explicitement la mise en oeuvre d'actions de l'agent qui ne soient pas nécessairement consécutives à la réception d'un message, que l'on qualifie généralement d'actions proactives par opposition à des actions réactives. Avantageusement et de façon non limitative, les actions unitaires sont du type appartenant au groupe comprenant au moins: l'interrogation d'une base de connaissances contenant les états internes possibles de l'agent logiciel et/ou les transitions possibles entres les états internes possibles de l'agent logiciel; la mise à jour des informations contenues dans la base de connaissances; - l'interrogation d'un gestionnaire de plans définissant les opérations permettant audit agent logiciel d'atteindre un objectif déterminé; la génération d'évènements internes à l'agent logiciel, à exécution instantanée; la génération d'évènements internes à l'agent logiciel, à exécution 10 différée; la génération d'évènements internes à l'agent logiciel, à exécution conditionnée par l'évolution d'au moins une donnée interne et/ou externe déterminée; l'émission de messages vers au moins un autre agent logiciel; - la génération d'une nouvelle activité associée à l'agent logiciel; l'ajout, la suppression d'un modèle d'interprétation sémantique à la liste de modèles d'interprétation sémantique; la modification de l'ordre des modèles d'interprétation sémantique de la liste de modèles d'interprétation sémantique, afin de modifier le comportement de l'agent logiciel en réaction aux évènements externes et/ou internes. En général, les activités de l'agent s'appuient sur une base de connaissances pour gérer l'état interne de l'agent. Cette base est manipulée (ajout, retrait ou mise à jour de connaissances) au cours du déroulement des opérations (encore appelées 25 activités) de l'agent. En outre, les opérations de l'agent peuvent également utiliser un gestionnaire de plans pour calculer une opération permettant d'atteindre un but (par exemple pour répondre à une intention exprimée par un autre agent). Cette opération pourra alors être ajoutée à l'agent au fur et à mesure de l'évolution du comportement des agents. Préférentiellement, les moyens d'interprétation sont des moyens d'application d'au moins un premier modèle d'interprétation sémantique de la liste ordonnée des modèles d'interprétation sémantique, à la représentation sémantique initiale, de façon à générer au moins une nouvelle représentation sémantique à partir de la représentation sémantique initiale. De façon préférentielle, la nouvelle représentation sémantique est soumise, de façon récursive, à l'application d'au moins un deuxième modèle d'interprétation sémantique d'indice supérieur dans la liste ordonnée des modèles d'interprétation sémantique. Plus précisément, un modèle d'interprétation sémantique peut être très général, ou au contraire très spécifique à une application particulière mise en oeuvre à l'aide de l'agent. Une activité peut à tout instant ajouter ou supprimer des modèles d'interprétation sémantique, ce qui a pour conséquence de modifier dynamiquement le comportement de l'agent. Il est important de souligner que lorsqu'un modèle est ajouté (pendant le déroulement d'une opération), son rang dans la liste des modèles d'interprétation sémantique de l'agent doit être indiqué, car l'ordre d'application des modèles par l'interpréteur sémantique est significatif. Avantageusement, les moyens de traduction des évènements comprennent au 20 moins: un analyseur syntaxique d'au moins un langage indéterminé définissant le contenu initial des évènements survenus au niveau de l'agent logiciel; un générateur de contenu logiquement équivalent au contenu initial des évènements, le contenu logiquement équivalent étant traduit dans un langage formel déterminé, interprétable sémantiquement. Cette nouvelle technique basée sur l'utilisation d'un analyseur syntaxique et d'un générateur de contenu logiquement équivalent trouve son sens de façon pertinente plus précisément dans un contexte d'interopérabilité entre agents logiciels hétérogènes, c'est-à-dire évoluant dans des environnements applicatifs différents et/ou dont les structures et/ou la sémantiques des messages échangés ne sont pas équivalentes. Cette approche peut bien évidemment s'appliquer directement à la traduction d'évènements internes d'un agent logiciel, notamment pour des agents logiciels intelligents dotés d'une capacité d'apprentissage en donc d'enrichissement de leur comportement en fonction des contraintes liées à l'environnement dans lequel ils évoluent. Préférentiellement, le dispositif selon l'invention comprend en outre un simplificateur des formules du langage formel déterminé, de façon à permettre une simplification des expressions des événements perçus et/ou desdites opérations générées par l'agent logiciel. Ce module est utilisé en particulier par le traducteur de représentation sémantique pour le calcul de la représentation sémantique initiale d'un message (qui peut être une formule FIPA-SL), et par les différents modèles d'interprétation sémantique pour calculer la transformation de la représentation sémantique qu'ils reçoivent (en entrée) en une ou plusieurs nouvelles représentations sémantiques qu'ils renvoient (en sortie). Préférentiellement, le langage formel déterminé est conforme au moins aux spécifications du langage FIPA-SL (pour Foundation Intelligent Physical Agent- Semantic Language en anglais, ou Fondation pour des agents physiques intelligents - Langage sémantique en français). De façon avantageuse, l'un au moins des premier et deuxième agents logiciels sont des agents du type appartenant au groupe comprenant au moins: les agents rationnels; les agents dialoguants; - les agents coopérants; - les agents mobiles. L'invention concerne également de façon avantageuse un procédé d'interprétation sémantique du contenu d'au moins un événement survenu au niveau 30 d'un premier agent logiciel comprenant au moins les étapes suivantes: - étape 1: capture d'au moins un évènement survenant au niveau d'un premier agent logiciel; étape 2: traduction de chacun des évènements capturés en une représentation sémantique initiale interprétable; étape 3: identification d'au moins un premier modèle d'interprétation sémantique conforme à la représentation sémantique initiale, dans une liste ordonnée de modèles d'interprétation sémantique prédéfinis; étape 4: si au moins un modèle d'interprétation sémantique est identifié : étape 4.1: application du modèle d'interprétation sémantique identifié de manière à interpréter le sens de chacun des évènements capturés à l'étape 2, puis; étape 4.2: si le sens des événements capturés peut être associé à au moins une opération contenue dans une liste d'opérations du premier agent logiciel, passer à l'étape 4.4, sinon, passer à l'étape 4.5; étape 4.4: exécution et/ou génération par le premier agent logiciel d'au moins une action représentative d'au moins une opération contenue dans une liste d'opérations de façon à faire évoluer l'état courant du premier agent logiciel; étape 4.5: génération d'au moins une nouvelle représentation sémantique à partir de la représentation sémantique initiale; - étape 5: si au moins un second modèle d'interprétation sémantique est identifié, application récursive des étapes 3 à 5 sur la base de la nouvelle représentation sémantique. Lorsque le modèle d'interprétation sémantique ne renvoie aucune représentation sémantique, c'est-à-dire que l'ensemble des représentations renvoyé est vide, on dit qu'il absorbe la représentation sémantique reçue en entrée. Une activité peut à tout instant' ajouter ou supprimer des modèles d'interprétation sémantique, ce qui a pour conséquence de modifier dynamiquement le comportement de l'agent. De façon avantageuse, lorsque les actions représentatives d'au moins une opération de l'agent sont des actions sémantiques devant provoquer un effet rationnel au niveau de l'agent logiciel lui-même, le procédé selon l'invention met en oeuvre au moins une étape supplémentaire 4.3 de vérification d'au moins une précondition de faisabilité associée à l'exécution des actions sémantiques, de façon que si la précondition est vérifiée, on exécute l'étape 4.4 précitée. Préférentiellement, l'opération exécutée et/ou générée au niveau d'un agent concerné par le procédé selon l'invention est une suite d'actions unitaires du type appartenant au groupe comprenant au moins: l'interrogation d'une base de connaissances contenant les états internes possibles de l'agent logiciel et/ou les transitions possibles entres les états internes possibles de l'agent logiciel; la mise à jour des informations contenues dans la base de connaissances; l'interrogation d'un gestionnaire de plans définissant les opérations 15 permettant à l'agent d'atteindre un objectif déterminé; la génération d'évènements internes à l'agent logiciel, à exécution instantanée; la génération d'évènementsinternes à l'agent logiciel, à exécution différée; la génération d'évènements internes à l'agent logiciel, à exécution conditionnée par l'évolution d'au moins une donnée interne et/ou externe déterminée, ce qui confere à l'agent un comportement proactif et une autonomie plus grande en termes d'interopérabilité; l'émission de messages vers au moins un autre agent logiciel; la génération d'une nouvelle opération archivée ou non dans la liste des opérations; l'ajout, la suppression d'un modèle d'interprétation sémantique à la liste de modèles d'interprétation sémantique; la transformation d'une première représentation sémantique en un ensemble de plusieurs autres représentations sémantiques distinctes interprétables; la modification de l'ordre des modèles d'interprétation sémantique contenus dans la liste de modèles d'interprétation sémantique, afin de modifier le comportement de l'agent logiciel en réaction aux différents évènements internes et/ou externes. En outre, l'étape 2 de traduction de chacun des évènements en une représentation sémantique initiale interprétable met en de oeuvre façon avantageuse 10 les étapes: d'analyse syntaxique d'au moins un langage indéterminé définissant le contenu initial des évènements capturés; de génération d'un contenu logiquement équivalent au contenu initial traduit dans un langage formel déterminé, interprétable sémantiquement. Préférentiellement, le procédé d'interprétation sémantique selon l'invention met en oeuvre également une étape de simplification des formules exprimées dans le langage formel déterminé, de façon à permettre la simplification des expressions des événements perçus et/ou des opérations exécutées et/ou générées par l'agent logiciel. Tout comme pour le dispositif précité selon l'invention, le langage formel déterminé pour la définition du contenu sémantique des évènements considérés est conforme au moins aux spécifications du langage FIPA-SL. L'invention concerne également de façon avantageuse une interpréteur sémantique du contenu d'au moins un événement survenu au niveau d'un premier agent logiciel, lequel met en oeuvre un procédé d'interprétation sémantique tel que 25 défini ci-dessus. L'invention concerne également un système multiagent comportant au moins deux agents logiciels, l'un au moins des agents logiciels considérés mettant en oeuvre au moins un dispositif d'interprétation sémantique comprenant: des moyens de capture d'évènements survenant au niveau des agents 30 logiciels; des moyens de traduction de chacun des évènements en une représentation sémantique initiale interprétable; - des moyens d'identification par au moins une itération d'au moins un modèle d'interprétation sémantique conforme à la représentation sémantique initiale, le modèle appartenant à une liste ordonnée de modèles d'interprétation sémantique prédéfinis; des moyens d'interprétation du sens de chacun des évènements par l'application d'au moins un modèle d'interprétation sémantique identifié à la représentation sémantique initiale; des moyens d'exécution et/ou de génération d'au moins une activité par chacun des agents; des moyens d'échange de messages entre les agents logiciels. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple illustratif et non limitatif, faite en référence aux dessins annexés parmi lesquels: - la figure 1 illustre l'organisation des principaux éléments constitutifs de l'invention au sein d'un agent logiciel; la figure 2 décrit les principaux éléments mis en oeuvre par un modèle d'interprétation sémantique selon l'invention; la figure 3 est un organigramme définissant les grandes étapes du procédé (ou de l'algorithme) d'interprétation sémantique selon l'invention; - les figures 4.a, 4.b et 4.c donnent trois exemples de modèles d'interprétation sémantique applicables dans le contexte de l'invention; et la figure 5 illustre un exemple de mise en oeuvre du dispositif et du procédé selon l'invention. 6. Description d'un mode de réalisation préféré de l'invention La présente invention concerne un dispositif et un procédé qui permettent de mettre en oeuvre les principes formels définissant la sémantique d'un langage de communication tel que FIPA-ACL, par exemple. Un agent logiciel qui intègre un mécanisme d'interprétation sémantique selon l'invention, réagit alors naturellement, et de façon cohérente relativement au sens des messages qu'il reçoit d'autres agents logiciels, par application d'un modèle formel sous-jacent, et non plus comme dans les systèmes de l'art antérieur, en fonction de la forme syntaxique des messages reçus, ou encore, relativement à un protocole d'échange et/ou de communication inter-agent qui serait pré-établi. Comme mentionné précédemment, le mécanisme d'interprétation sémantique selon l'invention repose d'une part, sur le calcul d'une ou plusieurs représentations sémantiques pour chaque message reçu par un agent, (dans le même formalisme que celui utilisé pour spécifier la sémantique formelle de FIPA-ACL, à savoir le langage logique FIPA-SL) et, d'autre part, sur un algorithme d'application de modèles d'interprétation sémantique. Ces modèles mettent en oeuvre chacun tout ou partie d'un principe formel conforme à la définition de FIPA-ACL (par exemple, le calcul d'une précondition de faisabilité, d'un effet rationnel, l'application d'un schéma d'axiome logique, ...), pour lancer une activité particulière de l'agent (envoi d'autres messages vers d'autres agents ou accomplissement de tâches spécifiques au domaine d'application, par exemple). Outre cette capacité d'interopérabilité ouverte, l'architecture préconisée, qui repose entre autres sur les concepts d'activité de l'agent et d'évènements internes perçus par celui-ci, permet également de doter les agents d'une qualité d'autonomie. De plus, elle autorise explicitement l'exécution d'actions par l'agent qui ne sont pas nécessairement consécutives à la réception d'un message, mais qui caractérisent un comportement proactif de l'agent. De telles actions sont qualifiées généralement d'actions proactives par opposition aux actions réactives exécutées par les systèmes de l'art antérieur. Relativement aux figures 1 à 5, on décrit ci-après un mode de réalisation préféré de l'invention. Comme illustré sur la figure 1, les principaux éléments constitutifs de l'invention s'organisent sous la forme d'une architecture spécifique intégrée à l'agent logiciel (100), de façon que ce dernier puisse comprendre et interpréter le sens des messages (101) et/ou des événements reçus et/ou perçus (102), et adapter ensuite son comportement en fonction du résultat de cette compréhension et/ou interprétation. De façon plus détaillée, l'architecture du dispositif selon l'invention met en oeuvre au moins les éléments suivants. > Agent logiciel (100) : L'agent logiciel (100) est l'entité logicielle perceptible par d'autres programmes (100) du même type et dans laquelle le dispositif et/ou le procédé d'interprétation sémantique selon l'invention est mis en oeuvre. Un agent réceptionne des messages (101) provenant d'autres agents, ainsi que des événements internes (102), qu'il génère pendant le déroulement de ses activités (103), que l'on appellera aussi opérations. Un agent (100) envoie également des messages (104) à d'autres agents pendant le déroulement de ses activités (103) ou réagit de façon proactive à ses propres événements internes (102) perçus et/ou générés en sortie. Des agent logiciels de ce type, conformes au standard FIPA pour l'envoi, la réception et le format des messages, peuvent par exemple être mis en oeuvre au moyen de la plate-forme JADE (pour Java Agent DEvelopment Framework en anglais ou Environnement de développement d'agents en technologie JAVA ). Le comportement d'un tel agent (100) résulte ainsi de l'ensemble des activités (103) ou opérations qu'il réalise à un instant donné, soit instantanément en réaction à un événement interne (102) et/ou externe (101) (message reçu d'un autre agent par exemple), soit de façon différée ou proactive sur détection d'une modification d'un paramètre ou de la survenue d'un événement interne et/ou externe attendu ou surveillé. Activité ou opération (103) : Dans le contexte de la présente invention, par activité ou opération (103) on entend une suite d'actions coordonnées de l'agent (100) en vue d'atteindre un objectif qui peut être rationnel. Cette suite peut être arbitrairement complexe mais conduit dans tous les cas à une évolution du comportement de l'agent (100) de façon autonome, ou bien relativement à l'environnement applicatif dans lequel il évolue. Elle peut mettre en oeuvre des éléments extérieurs comme une base de connaissances (105) ou un gestionnaire de plans (106), émettre des messages (104) vers d'autres agents, produire des événements internes (102) (qui sont alors traités par l'agent), ou encore générer de nouvelles activités (103). Une activité ou opération (103) peut également modifier, c'est-à-dire ajouter, supprimer, réordonner la liste (107) des modèles d'interprétation sémantique (108) de l'agent (100), afin d'en modifier le comportement. Une activité (103) démarre à sa création et se termine une fois la suite d'actions qui la définit réalisée. Une activité (103) peut aussi être récurrente, ce qui signifie qu'elle est répétée un certain nombre de fois, jusqu'à ce qu'une condition soit vérifiée, voire répétée indéfiniment, c'est-à-dire durant toute la vie de l'agent. Interpréteur sémantique (109) : Ce composant (109), objet de l'invention, réalise successivement les étapes 20 suivantes: - la réception d'un message (101) (en provenance d'un autre agent) ou d'un événement interne (102) (généré par une activité de l'agent); - l'extraction (110) de la représentation sémantique initiale associée au message ou à l'événement reçu; la mise en oeuvre des modèles d'interprétation sémantique (108) conformes à la représentation sémantique initiale. La représentation sémantique initiale, générée à l'étape d'extraction de la représentation sémantique initiale associée au message ou à l'événement reçu, est transmise au premier modèle (108) applicable. Puis, chaque modèle (108) appliqué renvoie une ou plusieurs représentations sémantiques, qui sont alors transmises au modèle applicable suivant. L'ordre dans lequel les modèles d'interprétation sémantique sont définis dans la liste (107) des modèles d'interprétation sémantique (108) influence le comportement de l'agent (100). L'algorithme d'application des modèles d'interprétation sémantique est détaillé ci-après au regard de l'organigramme de la figure 3. Extracteur de représentation sémantique (110) : Traducteur de contenu (1111 20 Ce composant (110) a pour fonction d'extraire la représentation sémantique initiale d'un message (101) (en provenance d'un autre agent). La représentation sémantique d'un message est une structure caractérisant la signification du message de façon non ambiguë. La représentation sémantique calculée par ce composant (110) est qualifiée d'initiale car elle est destinée à être modifiée par les modèles d'interprétation sémantique (108) à qui elle sera appliquée dans la suite du processus. Dans le cadre de la présente invention, les messages (101, 104) échangés entre les agents (100) sont exprimés dans le langage FIPA-ACL (pour Agent Communication Language en anglais ou Langage de Communication entre Agents en français). La représentation sémantique initiale d'un message m reçu par un agent r possède la forme suivante: (B r (done m true)) Cette formule logique exprimée dans le langage FIPA-SL (pour Semantic Language en anglais ou Langage Sémantique en français) signifie par exemple que l'agent récepteur r pense que l'action m (que l'on peut traduire comme l'envoi du message m vers l'agent noté r) vient d'être réalisée. Le langage choisi dans le cadre de la présente invention pour exprimer la représentation sémantique des messages est le FIPA-SL (voir ci-dessus) en tant que langage définissant la sémantique formelle du langage de communication FIPA-ACL utilisé pour échanger les messages (101, 104) entre les agents logiciels (100). Or le contenu propositionnel des messages FIPA-ACL peut être a priori exprimé avec n'importe quel langage de contenu, et donc pas forcément avec FIPASL, ce qui pourrait aboutir à des représentations sémantiques non homogènes, dont une partie ne serait pas exprimée en langage FIPA-SL. Le traducteur de contenu (111) a donc pour rôle de traduire le contenu d'un message (101), exprimé dans un langage quelconque, en un contenu logiquement équivalent exprimé en langage FIPA-SL. Pour ce faire, l'agent (100) dispose d'autant de traducteurs de contenu (111) qu'il y a de langages de contenu qu'il est susceptible de comprendre. Les éléments constitutifs d'un traducteur de contenu (111) sont un analyseur syntaxique pour le langage de contenu associé, et un générateur produisant un contenu logiquement équivalent en langage FIPASL. Si le contenu du message est déjà exprimé en FIPASL, alors le traducteur de contenu (111) correspondant se réduit à un analyseur syntaxique pour ce langage. Lorsque le contenu d'un message (101) ne peut être traduit ou s'il est incorrect, le traducteur de contenu (111) l'indique à l'extracteur (110). Ce dernier produit alors une représentation sémantique particulière qui conduit, le cas échéant, à la mise en oeuvre d'un modèle d'interprétation sémantique (108) amenant l'agent (100) à signaler l'erreur (en général par l'émission d'un message FIPA-ACL de type NOT-UNDERSTOOD qui signifie en français que le message n'a pas pu être compris et/ou interprété par l'agent logiciel). Simplificateur de formules (112) : Ce module (112) permet de calculer une forme normale d'une formule FIPASL, laquelle est à considérer en tant que formule logiquement équivalente, dont la 25 structure est simplifiée autant que possible. Ainsi, à titre d'exemple illustratif et non limitatif, la formule: (B i (B i p)) se simplifie en (B i p). Ce module (112) de simplification de formule est utilisé en particulier par l'extracteur de représentation sémantique (110) pour le calcul de la représentation sémantique initiale d'un message (qui est une formule FIPASL), ainsi que par les différents modèles d'interprétation sémantique (108) dédiés au calcul de la transformation permettant de traduire la représentation sémantique qu'ils reçoivent en entrée en une ou plusieurs nouvelles représentations sémantiques qu'ils renvoient en sortie. Modèle d'interprétation sémantique (108) : Un agent (100) selon la présente invention comporte ainsi nécessairement 10 plusieurs modèles d'interprétation sémantique (108), chaque modèle consistant à : 1. Reconnaître les représentations sémantiques auxquelles il s'applique; 2. S'il est applicable à une représentation sémantique entrante, à : a) ajouter éventuellement une activité (103) à l'agent (100). Cette activité (103) correspond aux actions que l'agent (100) doit réaliser pour 15 réagir à la représentation sémantique reconnue; b) transformer éventuellement la représentation sémantique reconnue en un ensemble de représentations sémantiques (qui peut être vide). Ces représentations renvoyées en sortie à l'interpréteur sémantique seront les nouvelles représentations sémantiques transmises par ce dernier aux modèles d'interprétation sémantique applicables suivants (la représentation sémantique reconnue en entrée est alors perdue). Si le modèle d'interprétation sémantique ne procède pas à cette opération de transformation, alors la même représentation sémantique que celle reconnue en entrée est renvoyée en retour à l'interpréteur sémantique (et sera donc propagée sur les modèles d'interprétation suivants). Ainsi, un modèle d'interprétation sémantique (108), lorsqu'il est applicable, peut opérer soit les étapes a) ou b), soit les deux à la fois. Un modèle n'opérant que l'étape a) consiste par exemple à déclencher une réaction de l'agent (100) relativement à une représentation sémantique donnée et à propager cette même représentation sémantique sur les modèles (108) d'interprétation suivants. De façon similaire, un modèle n'opérant que l'étape b) consiste uniquement à modifier la forme d'une représentation sémantique pour qu'elle puisse être reconnue par d'autres modèles d'interprétation. Une telle transformation revient à appliquer un modèle comportemental de l'agent (100) sous forme d'une règle. Lorsque le modèle d'interprétation sémantique (108) ne renvoie aucune représentation sémantique (i.e. l'ensemble des représentations renvoyé est vide), on dit qu'il absorbe la représentation sémantique reçue en entrée. Un modèle d'interprétation sémantique (108) peut être très général, ou au contraire très spécifique à une application particulière mise en oeuvre à l'aide de l'agent. Une activité (103) peut à tout instant ajouter ou supprimer des modèles d'interprétation sémantique (108), ce qui a pour conséquence de modifier dynamiquement le comportement de l'agent (100). Lorsqu'un modèle (108) est ajouté (pendant le déroulement d'une activité), son rang dans la liste (107) des modèles d'interprétation sémantique (108) de l'agent (100) doit être indiqué, car l'ordre d'application des modèles par l'interpréteur sémantique est significatif (voir organigramme de la figure 3). Base de connaissances (105) : En général, les activités de l'agent s'appuient sur une base de connaissances (105) pour gérer l'état interne de l'agent. Cette base est manipulée (ajout, retrait ou mise à jour de connaissances) au cours du déroulement des opérations de l'agent (100). Cette base de connaissances (105) permet ainsi à l'agent de capitaliser sur les opérations qu'il a déjà exécutées en réaction à un événement. Gestionnaire de plans (106) : Les activités ou opérations (103) de l'agent peuvent également utiliser un gestionnaire de plans (106) pour calculer une activité permettant d'atteindre un but (par exemple pour répondre à une intention exprimée par un autre agent). Cette activité pourra alors être ajoutée à l'agent. Relativement à la figure 2, on décrit ci-après les principaux éléments à mettre en oeuvre dans un modèle d'interprétation sémantique (108) selon l'invention. Table des actions (action, activité. précondition, effet rationnel) (201) : Le concept d'action mis en oeuvre par la présente invention est défini conformément à la spécification des actes communicatifs de FIPA-ACL. On fait correspondre à toute action, d'une part une précondition (203) de faisabilité (notée FP), et d'autre par un effet rationnel (204) (noté RE). L'un comme l'autre sont exprimés par des formules en langage FIPA-SL. Pour information concernant les spécifications FIPA, le lecteur pourra se référer à l'ouvrage: FIPA Communicative Act Library , FIPA-00037, lequel précise qu'une formule de précondition doit impérativement être vérifiée avant de réaliser l'action correspondante. Une formule d'effet rationnel exprime l'effet recherché par la mise en oeuvre de l'action correspondante, et non l'effet systématiquement produit par cette action. En outre, dans la présente invention, on associe à toute action l'activité (103) qui consiste à réaliser cette action. La table des actions (201) d'un agent (100) comporte à un instant donné toutes les actions susceptibles d'être mises en oeuvre par cet agent. En particulier, tous les actes communicatifs définis par le standard FIPA. Représentation sémantique (202) : Une représentation sémantique (202), au sens de l'invention, est une formule exprimée en langage FIPA-SL représentant le sens formel d'un message FIPA-ACL reçu par l'agent ou d'un événement interne. Cette formule est complétée par une référence au message (101) ou à l'événement interne (102) correspondant. Modèle d'interprétation sémantique (108) : Un modèle d' interprétation sémantique (108), mis en oeuvre par un agent, peut utiliser la table des actions (201) de l'agent (100) pour rechercher une action particulière. Il a alors accès à sa précondition de faisabilité (203), à son effet rationnel (204), ainsi qu'à une activité (103) permettant de la réaliser. On décrit ci-après et relativement à l'organigramme de la figure 3 les étapes essentielles du procédé d'interprétation sémantique selon l'invention. Cet algorithme est mis en oeuvre par l'interpréteur sémantique (109) pour appliquer les modèles d'interprétation sémantique (108) à la représentation sémantique initiale (202) extraite du message FIPA-ACL reçu (101) ou de l'événement interne (102) généré. Dans le cadre de cet algorithme, les représentations sémantiques (202) manipulées sont en fait des structures qui regroupent au moins trois informations: la formule logique en FIPA-SL associée à cette représentation sémantique (notée. formule sur la figure), l'indice (noté . indiceMlS), dans la table des modèles d'interprétation de l'agent (LIST MIS), du prochain modèle d'interprétation à appliquer à cette représentation sémantique (202), et une référence au message (101) reçu ou à l'événement interne (102) à l'origine de cette représentation sémantique (non utilisé sur la figure) qui sera transmise aux activités (103) ajoutées par les modèles d'interprétation sémantique (108) le cas échéant. L'algorithme commence par initialiser la représentation sémantique initiale (RSI) avec la formule logique FIPA-SL (.formule) issue de l'extracteur de représentation sémantique (110), et l'indice du prochain modèle à appliquer (.indiceMlS) égal à (301) : - la valeur 1 si la RSI est issue d'un message reçu (101) par l'agent (100), ou si 25 elle est issue d'un événement interne qui ne précise pas de valeur pour cet indice; la valeur déjà indiquée par la RSI lorsqu'elle est issue d'un événement interne (102) précisant cette valeur. La liste des représentations sémantiques (202) à traiter (LIST RS) est ensuite initialisée (302) avec cette représentation sémantique initiale. Dans le même temps, il affecte (303) le modèle d'interprétation sémantique (108) courant (MIS courant) au premier modèle de la liste ordonnée (107) des 5 modèles d'interprétation sémantique (108) de l'agent (LIST MIS). Tant que le modèle d'interprétation sémantique courant (MIS courant) existe (304), c'est-à-dire tant que tous les modèles d'interprétation sémantique (108) n'ont pas été pris en compte, on réalise les étapes suivantes: 1) Initialiser (306) une nouvelle liste de représentations sémantiques (NEW LIST RS) avec une liste vide. Cette liste représente la liste des représentations sémantiques qui devront être traitées après la prise en compte du MIS courant préalablement chargé (305) dans la variable notée M. 2) Tant que la liste des représentations sémantiques à traiter (LIST RS) n'est 15 pas vide (307), on réalise les étapes suivantes: a) Retirer (308) la première représentation sémantique (RS) de LIST RS; b) Soit l'indice associé à la RS (.indiceMlS) égale l'indice du MIS courant (dans la table LIST MIS), auquel cas on passe (309) à l'étape c) (310) ; sinon on passe à l'étape d) (311); c) (310) Soit le MIS courant est applicable à RS, auquel cas on l'applique à RS (312). Ceci peut conduire, le cas échéant, à ajouter une activité (103) à l'agent (100). Puis on passe à l'étape e) (314); soit le MIS courant n'est pas applicable à RS, auquel cas on incrémente (313) d'une unité l'indice associé à RS (.indiceMlS) et on passe à l'étape d) (311). d) (311) On rajoute RS à NEW LIST RS (la représentation sémantique sera éventuellement prise en compte par les prochains modèles à appliquer). Puis on reboucle sur l'étape 2 (307). e) (314) On récupère ensuite l'ensemble (possiblement vide) des représentations sémantiques renvoyées par l'application du MIS courant à RS et on les rajoute à NEW_LIST_RS. Puis on reboucle sur l'étape 2 (307). 3) La nouvelle liste (107) de représentations sémantiques (NEW LIST RS) devient (315) la liste des représentations sémantiques (202) à traiter (LIST RS). 4) Le modèle d'interprétation sémantique courant (MIS courant) devient le modèle dont l'indice dans la liste des modèles d'interprétation sémantique de l'agent (LIST MIS) est le plus petit indice parmi ceux associés aux représentations sémantiques de LIST RS. Le plus souvent, lorsqu'ils sont appliqués, les modèles d'interprétation sémantique (108) calculent les indices des représentations sémantiques (202) renvoyées, selon trois modes: - l'indice de la représentation sémantique (202) renvoyée est l'indice du modèle d'interprétation sémantique (108) correspondant dans la table de l'agent incrémenté de 1. Cela correspond à transmettre cette représentation au modèle suivant. l'indice de la représentation sémantique renvoyée est fixé à 1. Cela correspond 20 à forcer le traitement de cette représentation par l'ensemble des modèles de l'agent. l'indice de la représentation sémantique renvoyée est fixé par le modèle à une valeur particulière. Relativement aux figures 4.a, 4.b et 4.c, on présente maintenant sous une 25 forme graphique trois exemples de modèles d'interprétation sémantique (108). Ils sont donnés à titre de simples exemples illustratifs et non limitatifs. Formalisme de représentation graphique utilisé Une boite (400) comportant trois parties (401, 402, 403) peut servir de formalisme de représentation pour un modèle d'interprétation sémantique (108) : la partie supérieure (401) indique la forme de représentation sémantique reconnue par le modèle (108). Cette forme est exprimée dans une syntaxe FIPA-SL dans laquelle les formes notées ??X désignent des termes ou des formules FIPA- SL à reconnaître; la partie centrale (402) indique le nom du modèle (108) ; la partie inférieure (403) indique la liste des représentations sémantiques (202) renvoyées par le modèle (108) lorsqu'il est appliqué. Lorsqu'il y en a plusieurs, chaque représentation (202) est séparée par une ligne pointillée (404). Lorsqu'il n'y en a aucune, la partie inférieure (403) est barrée d'une croix (405). Dans ces représentations (202), les formes notées ??X désignent les termes ou formules FIPA-SL qui ont été reconnues. L'opération (406) mentionnée à gauche de la partie inférieure (403) représente le mode de calcul des indices associés aux représentations sémantiques (202) renvoyées par le modèle; l'indice n représente l'indice du modèle dans la table (107) des modèles d'interprétation sémantique (108) de l'agent (100). Ces indices sont utilisés par l'algorithme d'application des modèles d'interprétation sémantique (Cf. organigramme de la figure 3). - Une ellipse (407) représente une activité (103) possiblement générée et ajoutée à l'agent (100) par le modèle (108) lorsqu'il est appliqué. Un texte entre crochets (408) représente une condition à la génération de cette activité (103). Modèle d'interprétation sémantique pour l'interprétation d'un message FIPAACL (figure 4.a) Ce modèle s'applique aux représentations sémantiques (202) issues de la réception d'un message FIPA-ACL par l'agent (100). Ilproduit deux représentations sémantiques correspondant à : l'interprétation de l'effet rationnel de l'acte reconnu (désigné par ??ACT). Elle correspond à l'effet intentionnel tel que défini par la spécification FIPA, et se calcule à partir de l'effet rationnel de l'acte (désigné par ??RE) que le modèle lit dans la table des actions (201) de l'agent (Cf. figure 2); l'interprétation de la précondition de faisabilité (désignée par ??FP) de l'acte reconnu. Elle correspond à la nécessité pour l'agent (100) qui reçoit le message (101) de croire que cette précondition est vraie. Comme pour l'effet rationnel, la précondition de faisabilité de l'acte est lue dans la table des actions (201) de l'agent. L'indice associé aux représentations sémantiques produites est simplement égal à l'indice du modèle d'interprétation suivant dans la table des modèles de l'agent. Si l'effet rationnel et/ou la précondition de faisabilité correspondant au message FIPA-ACL reçu par l'agent, ne peuvent être trouvés dans la table des actions de l'agent, alors cela signifie que l'agent n'est pas en mesure d'interpréter correctement ce message. Le modèle génère alors une activité (407) consistant à répondre à l'agent émetteur du message par un message de type NOT-UNDERSTOOD. Dans ce cas, aucune représentation sémantique n'est renvoyée par le modèle d'interprétation sémantique (108). Modèle d'interprétation sémantique pour la réalisation d'une action (figure 4.b) Ce modèle s'applique aux représentations sémantiques (202) signifiant que figure, dans l'état mental d'un agent extérieur (désigné par ??AGENT), une intention portant sur le fait que l'agent (100) réalise une action (désignée par ??ACTION). Dans ce cas, si une activité (103) est trouvée pour cette action dans la table des actions (201) de l'agent (100), ce modèle génère et rajoute à l'agent cette activité (qui va donc conduire l'agent à réaliser l'action demandée). Ce modèle ne renvoie en sortie aucune représentation sémantique (108). Modèle d'interprétation sémantique pour l'acquisition de connaissance (figure 4.c) Ce modèle s'applique aux représentations sémantiques (202) indiquant des croyances (désignées par ??PHI) attribuées à l'agent (100). Le modèle (108) génère systématiquement une activité (103) consistant à ajouter cette croyance dans la base de connaissance (105) de l'agent, et renvoie en sortie une représentation sémantique (202) dont la formule est identique à celle de la représentation reconnue en entrée, et dont l'indice égale l'indice du modèle d'interprétation (108) suivant dans la table (107) des modèles de l'agent. Relativement à la figure 5, on présente un exemple de mise en oeuvre d'un agent logiciel (100) désigné par le terme récepteur (501). Dans cet exemple, un message FIPA-ACL de type QUERY-REF (502) est émis par un agent extérieur que l'on désigne ici sous le terme émetteur (503). Plus précisément, ce message signifie que l'agent émetteur (503) souhaite que l'agent récepteur (501) lui indique un objet (504) (désigné par la variable ?x) vérifiant une propriété désignée par le prédicat p. On suppose alors que l'agent récepteur (501) dispose des trois modèles d'interprétation sémantique de la figure 4, dans l'ordre où ils sont présentés. L'extracteur de représentation sémantique (505), encore appelé traducteur de représentation sémantique, fabrique d'abord la représentation sémantique initiale (506) (désignée par RSI) de ce message (101), à savoir une formule (507) exprimée en FIPA-SL et dont le contenu signifie que l'agent récepteur (501) "pense" que l'action correspondant à l'envoi du message FIPA-ACL par l'agent émetteur (503) vient de se produire. Puis l'interpréteur sémantique met en oeuvre l'algorithme dont les étapes sont 25 décrites en liaison avec l'organigramme de la figure 3. Au départ l'indice associé à la représentation sémantique initiale (RSI) (506) est 1, puis, étant donnée la définition choisie pour les modèles d'interprétation sémantique de l'agent, cet indice sera systématiquement incrémenté d'une unité à chaque application d'un modèle, de sorte que les modèles de l'agent sont appliqués les uns après les autres dans l'ordre d'apparition dans la table des modèles de l'agent. Dans un premier temps, l'interpréteur sémantique teste si la RSI (506) est applicable au premier modèle d'interprétation sémantique (508). C'est effectivement le cas car ce modèle reconnaît la formule correspondante. Il ne génère aucune activité pour l'agent récepteur, mais renvoie deux représentations sémantiques (désignées par RSI (509) et RS2 (51 0)). La première (509) correspond à l'interprétation de l'effet rationnel du message FIPA-ACL reçu, à savoir au fait que figure dans l'état mental de l'agent émetteur (503) une intention portant sur le fait que l'agent récepteur (501) lui indique un objet ?x vérifiant p. La seconde (510) correspond à la précondition de faisabilité du message FIPA-ACL reçu, à savoir au fait que l'agent émetteur (503) ne connaît pas d'objet ?x vérifiant p. Dans un second temps, l'interpréteur confronte RS 1 (509) au deuxième modèle d'interprétation sémantique qui la reconnaît également. Ce dernier interroge alors la table des actions de l'agent pour obtenir l'activité correspondant à l'action INFORMREF demandée par l'agent émetteur (503), puis l'ajoute à l'agent. Cette activité consiste à interroger la base de connaissances (511) de l'agent pour connaître un objet ?x vérifiant p, puis, si un tel objet est trouvé, à créer une autre activité consistant, elle, à envoyer à l'agent émetteur (503) un message FIPA-ACL de type INFORM contenant l'objet trouvé. Cette seconde activité pourra elle aussi être obtenue par la table des actions de l'agent. Le deuxième modèle renvoie en sortie une liste vide de représentations sémantiques. Dans une troisième étape, l'interpréteur confronte RS2 (510) au deuxième 25 modèle d'interprétation sémantique, mais ce dernier ne la reconnaît pas. Dans une quatrième étape et avant de passer au troisième modèle d'interprétation sémantique, l'interpréteur dispose d'une liste de représentations sémantiques à traiter égale à la réunion des représentations sémantiques renvoyées par les applications précédentes du deuxième modèle d'interprétation sémantique. Cette liste se réduit ici à RS2. L'interpréteur confronte alors, dans une cinquième étape, RS2 au troisième modèle d'interprétation sémantique qui la reconnaît. Ce dernier crée alors une activité consistant à ajouter à la base de connaissances de l'agent, la croyance selon laquelle l'agent émetteur ne connaît aucun objet vérifiant la propriété p. REVENDICATIONS 1. Dispositif d'interprétation sémantique mis en oeuvre dans au moins un premier agent logiciel (100), caractérisé en ce qu'il comprend: des moyens de capture d'évènements (101, 102) survenant au niveau dudit premier agent logiciel (100); des moyens (110) de traduction de chacun desdits évènements (101, 102) en une représentation sémantique initiale interprétable; des moyens d'identification par au moins une itération d'au moins un modèle (108) d'interprétation sémantique conforme à ladite représentation sémantique initiale (202), ledit modèle appartenant à une liste (107) ordonnée de modèles (108) d'interprétation sémantique prédéfinis; des moyens (109) d'interprétation du sens de chacun desdits évènements 15 par l'application d'au moins un modèle (108) d'interprétation sémantique identifié à ladite représentation sémantique initiale; des moyens d'exécution et/ou de génération d'au moins une opération (103) par ledit premier agent logiciel (100) en réaction auxdits évènements dont la sémantique a été interprétée. 2. Dispositif d'interprétation sémantique selon la revendication 1, caractérisé en ce que lesdits évènements sont des messages reçus par ledit premier agent logiciel et qui ont été générés par au moins un deuxième agent logiciel. 3. Dispositif d'interprétation sémantique selon la revendication 1, caractérisé en ce que lesdits évènements sont des événements internes générés de façon autonome par ledit premier agent logiciel dans l'exécution de ses opérations. 4. Dispositif d'interprétation sémantique selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdites opérations dudit agent logiciel sont des suites d'actions unitaires coordonnées dont l'effet recherché au niveau dudit agent logiciel est dirigé par le sens d'au moins un desdits événements ayant été interprétés, de façon à définir son comportement. 5. Dispositif d'interprétation sémantique selon les revendications 1 et 4, caractérisé en ce que lesdites actions unitaires sont des actions sémantiques dont l'exécution est contrainte par la vérification d'au moins une précondition de faisabilité, de manière à obtenir un effet rationnel dans le comportement dudit agent logiciel. 6. Dispositif d'interprétation sémantique selon les revendications l et 4, caractérisé en ce que lesdites actions unitaires sont du type appartenant au groupe comprenant au moins: l'interrogation d'une base de connaissances contenant les états internes possibles dudit agent logiciel et/ou les transitions possibles entres lesdits états internes possibles dudit agent logiciel; - la mise à jour des informations contenues dans ladite base de connaissances; l'interrogation d'un gestionnaire de plans définissant les activités permettant audit agent logiciel d'atteindre un objectif déterminé; la génération d'évènements internes audit agent logiciel, à exécution instantanée; la génération d'évènements internes audit agent logiciel, à exécution différée; la génération d'évènements internes audit agent logiciel, à exécution conditionnée par l'évolution d'au moins une donnée interne et/ou externe déterminée; l'émission de messages vers au moins un autre agent logiciel; la génération d'une nouvelle activité associée audit agent logiciel; l'ajout, la suppression d'un modèle d'interprétation sémantique à ladite liste de modèles d'interprétation sémantique; la modification de l'ordre desdits modèles d'interprétation sémantique de ladite liste de modèles d'interprétation sémantique, afin de modifier le comportement dudit agent logiciel en réaction auxdits évènements. 7. Dispositif d'interprétation sémantique selon l'une quelconque des revendications 1 à 5 caractérisé en ce que lesdits moyens d'interprétation sont des moyens d'application d'au moins un premier modèle d'interprétation sémantique de ladite liste ordonnée des modèles d'interprétation sémantique, à ladite représentation sémantique initiale, de façon à générer au moins une nouvelle représentation sémantique à partir de ladite représentation sémantique initiale. 8. Dispositif d'interprétation sémantique selon la revendication 7, caractérisé en ce que ladite nouvelle représentation sémantique est soumise, de façon récursive, à l'application d'au moins un deuxième modèle d'interprétation sémantique d'indice supérieur dans ladite liste ordonnée des modèles d'interprétation sémantique. 9. Dispositif d'interprétation sémantique selon l'une quelconque des revendications 1 à 6 caractérisé en ce que lesdits moyens de traduction desdits évènements comprennent au moins: un analyseur syntaxique d'au moins un langage indéterminé définissant le contenu initial desdits évènements survenus au niveau dudit agent logiciel; un générateur de contenu logiquement équivalent audit contenu initial desdits évènements, ledit contenu logiquement équivalent étant traduit dans un langage formel déterminé, interprétable sémantiquement. 10. Dispositif d'interprétation sémantique selon l'une quelconque des revendications 1 à 9 caractérisé en ce qu'il comprend en outre un simplificateur de formule permettant de simplifier les expressions desdits événements perçus et/ou desdites opérations générées par ledit agent logiciel. 11. Dispositif d'interprétation sémantique selon les revendications 9 et 10 caractérisé en ce que ledit langage formel déterminé est conforme au moins aux spécifications du langage FIPA-SL. 12. Dispositif d'interprétation sémantique selon l'une quelconque des revendications 2 à 11, caractérisé en ce que l'un au moins desdits premier et deuxième agents logiciels sont des agents du type appartenant au groupe comprenant au moins: les agents rationnels; les agents dialoguants; les agents coopérants; les agents mobiles. 13. Procédé d'interprétation sémantique du contenu d'au moins un événement survenu au niveau d'un premier agent logiciel (100), caractérisé en ce qu'il comprend les étapes suivantes: étape 1: capture d'au moins un évènement (101, 102) survenant au niveau dudit premier agent logiciel (100); étape 2: traduction (110) de chacun desdits évènements (101, 102) capturés en une représentation sémantique initiale (202) interprétable; étape 3: identification d'au moins un premier modèle (108) d'interprétation sémantique conforme à ladite représentation sémantique initiale (202), dans une liste (107) ordonnée de modèles (108) d'interprétation sémantique prédéfinis; étape 4: si au moins un modèle d'interprétation sémantique est identifié : étape 4.1: application dudit modèle (108) d'interprétation sémantique identifié de manière à interpréter le sens de chacun desdits évènements capturés à l'étape 2, puis; étape 4.2: si ledit sens desdits événements capturés peut être associé à au moins une opération contenue dans une liste (201) d'opérations dudit premier agent logiciel (100), passer à l'étape 4.4, sinon, passer à l'étape 4.5; étape 4.4: exécution et/ou génération par ledit premier agent logiciel d'au moins une action représentative d'au moins une opération (103) contenue dans une liste d'opérations de façon à faire évoluer l'état courant dudit premier agent logiciel (100); étape 4.5: génération d'au moins une nouvelle représentation sémantique (202) à partir de ladite représentation sémantique initiale; étape 5: si au moins un second modèle d'interprétation sémantique est identifié, application récursive desdites étapes 3 à 5 sur la base de ladite nouvelle représentation sémantique. 14. Procédé d'interprétation sémantique selon la revendication 13, caractérisé en ce que lorsque lesdites actions représentatives d'au moins une opération dudit agent sont des actions sémantiques devant provoquer un effet rationnel au niveau dudit agent logiciel, il met en oeuvre au moins l'étape supplémentaire 4.3 de vérification d'au moins une précondition de faisabilité associée à l'exécution desdites actions sémantiques, de façon que si ladite précondition est vérifiée, on exécute ladite étape 4.4. 15. Procédé d'interprétation sémantique selon les revendications 13 et 14, caractérisé en ce que ladite au moins une opération est une suite d'actions unitaires du type appartenant au groupe comprenant au moins: 16. l'interrogation d'une base de connaissances contenant les états internes possibles dudit agent logiciel et/ou les transitions possibles entres lesdits états internes possibles dudit agent logiciel; la mise à jour des informations contenues dans ladite base de connaissances; l'interrogation d'un gestionnaire de plans définissant les activités permettant audit agent d'atteindre un objectif déterminé; la génération d'évènements internes audit agent logiciel, à exécution instantanée; la génération d'évènements internes audit agent logiciel, à exécution différée; la génération d'évènements internes audit agent logiciel, à exécution conditionnée par l'évolution d'au moins une donnée interne et/ou externe déterminée; l'émission de messages vers au moins un autre agent logiciel; la génération d'une nouvelle activité; l'ajout, la suppression d'un modèle d'interprétation sémantique à ladite liste de modèles d'interprétation sémantique; la transformation d'une première représentation sémantique en un ensemble de plusieurs autres représentations sémantiques distinctes interprétables; la modification de l'ordre desdits modèles d'interprétation sémantique contenus dans ladite liste de modèles d'interprétation sémantique, afin de modifier le comportement dudit agent logiciel en réaction auxdits évènements. 17. Procédé d'interprétation sémantique selon les revendications 13 et 14, caractérisé en ce que ladite étape 2 de traduction de chacun desdits évènements en une représentation sémantique initiale interprétable met en oeuvre les étapes: d'analyse syntaxique d'au moins un langage indéterminé définissant le contenu initial desdits évènements capturés; de génération d'un contenu logiquement équivalent audit contenu initial traduit dans un langage formel déterminé, interprétable sémantiquement. 18. Procédé d'interprétation sémantique selon l'une quelconque des revendications 13 à 16, caractérisé en ce qu'il comprend en outre une étape de simplification de formule permettant de simplifier les expressions desdits événements perçus et/ou desdites opérations générées par ledit agent logiciel. 19. Procédé d'interprétation sémantique selon l'une quelconque des revendications 16 et 17, caractérisé en ce que ledit langage formel déterminé est conforme au moins aux spécifications du langage FIPA-SL. 20. Procédé d'interprétation sémantique selon l'une quelconque des revendications 13 à 18, caractérisé en ce que l'un au moins desdits premier et deuxième agents logiciels sont du type appartenant au groupe comprenant au moins: les agents rationnels; - les agents dialoguants; les agents coopérants; - les agents mobiles. 21. Interpréteur sémantique du contenu d'au moins un événement (101, 102) survenu au niveau d'un premier agent logiciel (100), caractérisé en ce qu'il met en oeuvre un procédé d'interprétation sémantique selon l'une quelconque des revendications 13 à 19. 22. Système multiagent comportant au moins deux agents logiciels (100), caractérisé en ce qu'au moins un desdits agents logiciels (100) met en oeuvre au moins un dispositif d'interprétation sémantique comprenant: des moyens de capture d'évènements (101, 102) survenant au niveau desdits agents logiciels (100); - des moyens (110) de traduction de chacun desdits évènements en une représentation sémantique initiale interprétable; - des moyens d'identification par au moins une itération d'au moins un modèle (108) d'interprétation sémantique conforme à ladite représentation sémantique initiale (202), ledit modèle appartenant à une liste ordonnée de modèles (108) d'interprétation sémantique prédéfinis; - des moyens (109) d'interprétation du sens de chacun desdits évènements par l'application d'au moins un modèle (108) d'interprétation sémantique identifié à ladite représentation sémantique initiale (202); - des moyens d'exécution et/ou de génération d'au moins une opération (103) par chacun desdits agents (100); - des moyens d'échange de messages (101, 104) entre lesdits agents logiciels (100). 23. Système multiagent selon la revendication 21, caractérisé en ce qu'au moins un desdits agents logiciels est du type appartenant au groupe comprenant au moins: les agents rationnels; les agents dialoguants; les agents coopérants; les agents mobiles.