FR 3006526 A1 20141205 FR 1354888 A 20130529 068715 Chargement dynamique de composants applicatifs Domaine technique La présente invention concerne généralement les dispositifs électroniques et en particulier un procédé et un système de supervision de composants applicatifs pour de tels dispositifs. Art antérieur et problème technique Les récentes avancées technologiques de ces dernières années ont mis l'accent sur la démocratisation des réseaux sans-fil et sur la miniaturisation des appareils de communication. Actuellement, il existe sur le marché une multitude de dispositifs électroniques personnels de plus en plus légers, compacts, mobiles et dotés de divers moyens de communication sans-fil, tels que les téléphones portables, les téléphones mobiles intelligents (« smartphones » en langue anglo- saxonne), les tablettes, les ordinateurs portables ou encore les capteurs. Ces dispositif concentrent des fonctionnalités complexes et très diversifiées : téléphonie, messagerie instantanée, navigation Internet, système de localisation (GPS acronyme pour « Global Positioning System »), lecteur audio, etc. Ces dispositifs font l'objet d'une demande grandissante pour des services de plus en plus riches et personnalisés. Le défi est de pouvoir proposer des applications pour ces dispositifs qui s'adaptent tant aux souhaits des utilisateurs qu'à l'environnement physique dans lequel ils opèrent. Les dispositifs électroniques mobiles ont la capacité de pouvoir rendre compte non seulement de leur environnement matériel et logiciel mais aussi, avec l'arrivée de périphériques tels que les capteurs sans fils ou les capteurs intégrés aux téléphones portables, de pouvoir mesurer des grandeurs physiques liées à l'environnement du dispositif ou au dispositif lui-même, telles que la température, la pression ou encore la vitesse de déplacement. L'intégration des données issues de tels dispositifs dans les applications peut permettre de proposer aux utilisateurs des services mieux adaptés à leur situation courante. Cependant, ces dispositifs possèdent des caractéristiques (autonomie énergétique, mobilité, ressources limitées) qui nécessitent l'adaptation des applications ainsi que des services rendus par celles-ci pour assurer un fonctionnement correct pendant une durée suffisante, et une continuité de service en cas d'indisponibilité d'un périphérique du dispositif électronique, par exemple lorsqu'un périphérique du dispositif électronique ne possède plus suffisamment de batterie. En l'absence de continuité de service, tous les services offerts par le périphérique cessent alors de fonctionner impliquant une rupture de service. Il peut en résulter un confort d'utilisation limité pour l'utilisateur, notamment dans le cas où des applications sont en cours d'exécution. On connaît des systèmes de supervision sensibles au contexte qui réagissent aux changements de contexte pour fournir à l'utilisateur des services adaptés à la situation. De tels systèmes 068715 peuvent reposer sur différents types d'adaptations : adaptation de contenu, adaptation de présentation, adaptation de comportement, adaptation structurelle, adaptation de déploiement. Ainsi, des systèmes de supervision existent pour adapter le contenu des applications qui s'exécutent sur les dispositifs électroniques en fonction du contexte, comme par exemple la solution décrite dans Christoph Dom, Richard N. Taylor - Co-adapting human collaborations and software architectures - ICSE 2012 Proceedings of the 2012 International Conference on Software Engineering - pp. 1277-1280. En fonction de la situation, les données peuvent être modifiées pour ne présenter à l'utilisateur que celles qui sont pertinentes à sa situation. D'autres systèmes connus sont configurés pour adapter la présentation dans le domaine des IHM (acronyme pour Interface Homme Machine). En fonction du statut hiérarchique de l'utilisateur, l'interface de l'application présentera ou non une information et proposera ou non une fonctionnalité, comme par exemple la solution décrite dans l'article de Y. Gabillon, G. Calvary, H. Fiorino, intulé « Composition d'Interfaces Homme-Machine en contexte : approche par planification automatique >>, Revue TSI. Vol. 30,2011. Dans d'autres systèmes encore, il est prévu une adaptation de comportement qui repose sur l'adaptation des fonctionnalités fournies par un composant ou un service en fonction du contexte, comme par exemple la solution décrite dans l'article de Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor, intitulé « Runtime Software Adaptation: Framework, Approaches, and Styles >>, ICSE Companion '08 Companion of the 30th international conference on Software engineering, pp. 899-910. Dans d'autres approches encore, les systèmes de supervision réalisent une adaptation structurelle qui vise à modifier la composition de l'application et/ou les connexions entre les différents composants dans le but d'obtenir une application dont le comportement reste inchangé. Ce type d'adaptation est le plus couramment utilisé dans le domaine des applications distribuées basées composants. On connaît également des systèmes de supervision qui adaptent le déploiement en fonction du contexte, comme proposé par exemple dans l'article de Ning Gui, Vincenzo De Florio, Hong Sun, Chris Blondia intitulé « Toward architecture-based context-aware deployment and adaptation >>, The Journal of Systems and Software 84 (2011) 185-197 - Elsevier, 2011. De tels systèmes mettent en oeuvre des déploiements qui prennent en compte les propriétés des périphériques supportant l'application. Ce type d'adaptation est souvent utilisé pour faire face aux problèmes engendrés par les limitations matérielles des dispositifs mobiles et contraints, massivement utilisés de nos jours. Les solutions existantes reposant sur l'adaptation de contenu, l'adaptation de présentation et l'adaptation de fonctionnalité sont essentiellement tournés vers l'utilisateur. Le contenu et les fonctionnalités sont adaptés en fonction de ses préférences et la présentation est adaptée en fonction de son statut par exemple. Les adaptations de structure et de déploiement conviennent 068715 particulièrement aux contraintes matérielles et aux contraintes réseaux. Toutefois, les fonctionnalités restent inchangées malgré les changements de contexte. Les solutions reposant sur l'adaptation structurelle et l'adaptation de déploiement permettent d'adapter les fonctionnalités en fonction du contexte. Une application est alors représentée par un assemblage de composants qu'il est possible de modifier par des opérations élémentaires telles que l'ajout, la suppression de composants ainsi que de connexions entre ces composants. Ces opérations élémentaires agissent sur la structure de l'application. Parmi les solutions basées sur une adaptation structurelle en fonction du contexte, l'article de O. Riva, T. Nadeem,C. Borcea, L. Iftode, Context-Aware Migratory Services, in Ad Hoc Networks IEEE Transactions on Mobile Computing, Vol. 6, No. 12, December 2007, propose un modèle de service permettant aux réseaux adhoc de fournir des services capables de s'adapter au contexte afin d'offrir une continuité de service au client. Un service de migration supervise les services et réagit en déclenchant des migrations de services chaque fois qu'un noeud n'est plus capable de supporter l'exécution du service, provoquant la poursuite du service sur un autre noeud. L'aspect migration est rendu invisible aux applications cliente par l'utilisation d'un unique terminal virtuel. On connaît également une approche basée sur des composants légers pour concevoir des services web composites, qui est décrite dans l'article de V. Maurin, N. Dalmasso, B. Copigneaux, S. Lavirotte, G. Rey, J. Y. Tigli, Simply engine-wcomp : plate-forme de prototypage rapide pour l'informatique ambiante basée sur une approche orientée services pour dispositifs réels/virtuels, David Menga and Florence Sedes, editors, UbiMob, volume 394 of ACM International Conference Proceeding Series, pages 83-86. ACM, 2009. Cette solution permet de construire des applications sous forme de graphes de services web basés sur le concept de conteneur. D'autre part, elle fournit un intergiciel basé sur le concept d'Aspects d'Assemblage permettant d'adapter les services web. Une telle solution permet la réutilisation des services et par suite une extensibilité et une communication basée sur les événements, ce qui garantit une forte réactivité du système. Un autre avantage de cette solution est qu'elle permet la mobilité des applications (paradigme de services web) et apporte une flexibilité au niveau de la structure qu'il est possible d'adapter (paradigme composant). Le projet MUSIC (R. Rouvoy, P. Barone, Y. Ding, F. Eliassen, S. Hallsteinsen, J. Lorenzo, A.Mamelli, and U. Scholz. MUSIC: Middleware Support for Self-Adaptation in Ubiquitous and Service-Oriented Environments - Book on Software Engineering for Self-Adaptive Systems (SEfSAS). LNCS 5525 -2009) fournit un intergiciel permettant la reconfiguration d'applications mobiles et sensibles au contexte. Le processus d'adaptation défini dans MUSIC repose sur les principes de l'adaptation par planification (« planning based adaptation » en langue anglo- saxonne). L'adaptation par planification fait référence à la capacité de reconfiguration d'une application en réponse aux changements de contexte en exploitant les connaissances de sa composition et des métadonnées de Qualité de Service associées à chacun des services la constituant. 068715 Dans l'article de D. Ayed, C. Taconet, G. Bernard, and Y. Berbers. Cadecomp, Context-aware deployment of component-based applications", J. Network and Computer Applications, 31(3) 2008, un intergiciel est proposé pour le déploiement sensible au contexte des applications basées composants. Cet intergiciel étend les services de déploiement existants en y intégrant les capacités d'adaptation nécessaires au domaine des applications mobiles et des périphériques contraints. Il propose un déploiement automatique à la volée et sensible au contexte : une application est installée au moment de son accès et désinstallée juste après la fin de son utilisation. Les applications sont considérées comme une collection de composants distribués sur le réseau et reliés entre eux via des ports. Le déploiement est défini selon cinq paramètres : l'architecture de l'application, le placement des instances des composants, le choix de leur implémentation, les propriétés des composants et leurs dépendances. Cet intergiciel repose sur un modèle de données permettant de décrire le contexte qui agit sur le déploiement et de définir des contrats de déploiement qui associent à chaque situation de contexte toutes les variations possibles des paramètres de déploiement. Le contexte modélise essentiellement les caractéristiques des instances des composants. Ces informations sont collectées lors de la spécification et du développement par le producteur du composant. Elles permettent de spécifier des contraintes sur le placement des composants ainsi que sur les connexions, obligatoires ou optionnelles. La plateforme à service OSGi (acronyme pour « Open Services Gateway initiative ») implémente un modèle de composant (désignée par le terme anglo-saxon « Bundle » signifiant « groupement »). Ces derniers possèdent un cycle de vie leur permettant d'être arrêtés, démarrés, mis à jour et désinstallés à chaud. Le service appelé « registry » (terme anglo-saxon signifiant « registre ») permet d'enregistrer des composants (bundle) en tant que services et d'en détecter l'apparition ou la suppression. OSGi est basé sur la découverte de services. Toutefois, la plateforme OSGi ne supporte pas la migration des composants entre périphériques et est basée sur la découverte de services. Les solutions existantes proposent ainsi différentes approches d'adaptation structurelle des applications (canevas logiciel, intergiciel, plateforme d'exécution). Toutefois, aucune des approches proposées ne permet une supervision décentralisée, entièrement dynamique et transparente des composants applicatifs sur un ensemble de dispositifs mobiles, pouvant être de nature différente et connectés par tous types de réseaux, en fonction du contexte. Par ailleurs, aucune des solutions existantes ne propose un tel système de supervision capable de charger dynamiquement le code des composants applicatifs lors de la création ou de la migration d'un composant applicatif sur un dispositif électronique. Définition générale de l'invention L'invention améliore la situation en proposant un système de supervision d'applications s'exécutant sur un ensemble de dispositifs électroniques reliés entre eux par un ou plusieurs réseaux. Chaque dispositif comprend une entité de supervision locale, les entités de supervision coopérant entre 068715 elles pour contrôler les applications s'exécutant sur les dispositifs électroniques, et chaque application comprend un ensemble de composants applicatifs. Avantageusement, l'entité de supervision d'un dispositif donné est apte à exécuter les étapes suivantes, en réponse à une commande d'accueil d'un composant applicatif sur ledit dispositif, dit dispositif d'accueil, ledit composant ayant un état de départ donné: - communiquer avec un ensemble d'entités de supervision pour rechercher un fichier de code comprenant le code exécutable associé au composant applicatif, - charger le fichier de code exécutable associé au composant sur ledit dispositif d'accueil, en réponse à la disponibilité du fichier de code sur le dispositif d'accueil, - démarrer le composant dans ledit état de départ à partir du code chargé, en l'encapsulant dans un conteneur contrôlable par l'entité de supervision. La commande d'accueil peut être une commande de création du composant sur le dispositif, l' état de départ étant alors un état initial. La commande d'accueil peut être une commande de migration du composant sur le dispositif d'accueil depuis un dispositif source, l'état de départ étant alors l'état du composant dans le dispositif source. Selon une caractéristique de l'invention, la recherche de fichier de code peut comprendre l'envoi d'un message de demande de code par l'entité de supervision du dispositif d'accueil aux entités de supervision dudit ensemble d'entités de supervision, ledit message comprenant des informations relatives au composant et au dispositif d'accueil. Le message de demande de code peut être relayé par chaque entité de supervision réceptrice le message vers un autre ensemble d'entités de supervision, si le dispositif hébergeant l'entité de supervision réceptrice ne détient pas le fichier de code associé au composant. En particulier, l'étape consistant à relayer le message de demande de code vers un autre ensemble d'entités de supervision peut comprendre la désignation de l'entité de supervision réceptrice comme relai pour l'envoi d'une réponse comprenant le fichier de code depuis une autre entité de supervision vers le dispositif d'accueil dans le message relayé. Selon une autre caractéristique de l'invention, chaque entité de supervision réceptrice du message de demande de code est apte à rechercher si le dispositif hébergeant l'entité de supervision détient un fichier de code associé au composant à partir du nom de la classe du composant. Chaque entité de supervision réceptrice du message de demande de code peut déterminer si le dispositif hébergeant l'entité de supervision réceptrice détient un fichier de code associé au composant en effectuant une recherche dans un dépôt de code de composants, à partir des informations relatives au composant et au dispositif d'accueil, si le dispositif hébergeant l'entité de 068715 supervision réceptrice gère un dépôt de code de composants stockant des fichiers de code à des composants. Selon une forme de réalisation de l'invention, l'entité de supervision du dispositif d'accueil est apte à envoyer le message de demande de code par diffusion du message, si le dispositif a une capacité d'envoi par diffusion, l'ensemble d'entités de supervision comprenant alors les entités de supervision des dispositifs voisins recevant ledit message envoyé par diffusion. Selon une autre forme de réalisation de l'invention, l'entité de supervision du dispositif d'accueil peut maintenir des informations relatives aux entités de supervision avec lesquelles elle communique dans une structure de données tandis que l'entité de supervision du dispositif d'accueil est apte à envoyer ledit message de demande de code à des entités de supervision déterminées à partir de ladite structure de données. En variante, l'entité de supervision du dispositif d'accueil peut envoyer le message de demande de code à un proxy prédéfini apte à relayer ledit message par diffusion, l'ensemble d'entités de supervision comprenant les entités de supervision des dispositifs voisins recevant ledit message envoyé par diffusion par le proxy. Le proxy peut être une entité de supervision sur un dispositif ayant une adresse publique sur Internet. Selon un aspect de l'invention, chaque entité de supervision peut comprendre un émetteur configuré pour transmettre les demandes de code associé à un composant vers un client d'envoi par diffusion, le client d'envoi par diffusion étant configuré pour envoyer les messages de demandes de code associé à un composant à l'ensemble d'entités de supervision. Selon un autre aspect de l'invention, l'émetteur peut être configuré pour transmettre les demandes de code associées à un composant vers un client lié au proxy. La connexion avec le proxy peut être maintenue ouverte pour permettre la réception des réponses relayées par le proxy en réponse à une demande de code. La connexion peut être maintenue ouverte en utilisant l'envoi de messages de type PING. Chaque entité de supervision peut comprendre en outre un émetteur de réponse pour envoyer la réponse de l'entité de supervision à un message de demande de code vers l'entité de supervision du dispositif qui lui a relayé le message de demande de code provenant du dispositif d'accueil, l'émetteur étant configuré pour transmettre la réponse à l'entité de supervision via au moins un client d'envoi spécifique selon le réseau disponible. 068715 Chaque composant peut être associé à une classe de composant donnée, et en ce que les informations relatives au composant comprennent le nom de la classe du composant. Les informations relatives au composant peuvent comprendre le type de dispositif. L'entité de supervision locale du dispositif d'accueil peut charger le fichier de code en utilisant un chargeur de code associé au fichier de code. Le chargeur de code associé au fichier de code sur le dispositif est crée lors de la première création du composant sur le dispositif d'accueil. Le lien entre le composant et son chargeur de code est mémorisé dans le conteneur du composant. L'invention propose en outre un procédé de supervision d'applications s'exécutant sur un ensemble de dispositifs électroniques reliés entre eux par un ou plusieurs réseaux, chaque dispositif comprenant une entité de supervision locale. Les entités de supervision coopérant entre elles pour contrôler les applications s'exécutant sur les dispositifs électroniques. Chaque application comprend un ensemble de composants applicatifs. Avantageusement, le procédé comprend les étapes suivantes, en réponse à une commande d'accueil d'un composant applicatif sur un dispositif, dit dispositif d'accueil, ledit composant ayant un état de départ donné: - rechercher un fichier de code comprenant le code exécutable associé au composant applicatif sur un ensemble de dispositifs ; - charger le fichier de code associé au composant sur ledit dispositif d'accueil, en réponse à la disponibilité du fichier de code sur le dispositif d'accueil, - démarrer le composant dans ledit état de départ à partir du code chargé, en l'encapsulant dans un conteneur contrôlable localement. Le système de supervision selon l'invention permet ainsi de ne charger le code associé à un composant applicatif sur un dispositif donné que lorsque le dispositif accueille le composant (création ou migration d'un composant sur le dispositif. Un composant peut ainsi être migré dynamiquement de dispositif en dispositif, quel que soit le type de dispositif électronique (téléphone intelligent sous Android, ordinateur personnel, etc.), en redémarrant dans l'état où il se trouvait sur le dispositif d'accueil. Le chargement dynamique de code se fait en un temps très limité, et est donc transparent pour l'utilisateur. Le procédé de chargement dynamique selon les formes de réalisation de l'invention permet ainsi à n'importe quel dispositif qui accueille un nouveau composant d'obtenir un composant à jour. Ce mécanisme permet de limiter la surcharge des dispositifs et notamment la surcharge des dispositifs contraints (par exemple téléphones), en ne prévoyant de dépôts de code de composants que sur certains dispositifs ayant des ressources suffisantes pour maintenir un tel dépôt et répondre aux demandes de code provenant d'autres entités de supervision. 068715 Par ailleurs, le système de supervision selon l'invention est adapté pour ne déployer que les composants nécessaires tout en supprimant les composants qui sont devenus inutiles. En effet, en contrôlant chaque composant qui s'exécute sur le dispositif indépendamment des autres composants (notamment au moyen des connecteurs de composants créés par l'entité de supervision), chaque entité de supervision sur un dispositif donné peut avoir à tout moment une connaissance de l'état des composants hébergés sur le dispositif. Brève description des dessins D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit et des figures des dessins annexés dans lesquels: - La figure 1 représente un exemple d'architecture du système de supervision, selon une forme de réalisation de l'invention ; - La figure 2 représente un exemple de dispositifs hébergeant des composants contrôlés par le système de supervision, selon des modes de réalisation de l'invention ; - La figure 3 montre la structure des applications ; - La figure 4 est un schéma montrant la structure d'un modèle de composant, selon certaines formes de réalisation de l'invention; -La figure 5 illustre le cycle de vie d'un Composant; -La figure 6 représente schématiquement la structure d'un dépôt de composant, selon certaines formes de réalisation de l'invention ; - La figure 7 est un organigramme représentant les étapes mises en oeuvre pour charger le code associé à un composant depuis d'autres entités de supervision ; - La figure 8 est un organigramme illustrant le chargement d'un fichier de code associé à un composant sur un dispositif; - La figure 9 est un organigramme représentant les étapes mises en oeuvre pour charger le code associé à un composant depuis d'autres entités de supervision, en fonction des capacités de diffusion disponibles ; - La figure 10 est un schéma structurel d'une entité de supervision locale illustrant la communication avec les autres entités de supervision pour le chargement dynamique de code, selon certaines formes de réalisation de l'invention ; et 068715 - La figure 11 est un exemple de schéma de l'architecture du noyau de chaque entité de supervision. Description détaillée La figure 1 représente un système de supervision d'applications 10 mettant en oeuvre le procédé de chargement dynamique selon les formes de réalisation de l'invention. Le système de supervision 10 représenté est un système dynamique et décentralisé pour contrôler les applications d'un ensemble de dispositifs électroniques 5 connectés entre eux par des réseaux de communication 7, par exemple de type WIFI, ou satellite (GSM, 3G, 4G etc.). Les dispositifs électroniques (encore désignés par les expressions « dispositif hôtes » ou « hôtes » ou « machines » dans la suite de la description) peuvent comprendre tout type de dispositif électronique, notamment des dispositifs électroniques mobiles, comme des ordinateurs personnels tels que PC1 et P02), des téléphones mobiles intelligents (appelé « Smartphone » en langue anglo-saxonne) tels que Ti et T2, des tablettes informatiques telles que TI1, etc. Les réseaux de communication supportés par les dispositifs électroniques 5 peuvent comprendre plusieurs types de réseaux 7. Selon cette approche décentralisée, le système de supervision 10 comprend un ensemble d'entités de supervision 6 (encore appelée « entités de supervision locales »), chacune hébergée sur un dispositif électronique respectif 5. Les entités de supervision coopèrent entre elles pour superviser de manière dynamique les composants applicatifs qui s'exécutent sur l'ensemble des dispositifs 5 en fonction du contexte et des ressources. Ces entités de supervision contrôlent dynamiquement le cycle de vie des composants qui peut comprendre la création d'un composant sur un dispositif, la suppression d'un composant d'un dispositif 5 ou la migration d'un composant applicatif entre un dispositif source et un dispositif cible, notamment pour tenir compte du contexte d'exécution et des ressources matérielles. Les entités locales de supervision 6 peuvent en outre être configurées pour collecter des informations sur l'utilisation des ressources matérielles des dispositifs électroniques, telle que la batterie, la mémoire ou le CPU (acronyme pour l'expression anglo-saxonne « Central Processing Unit »), et/ou le contexte d'exécution, représenté par exemple par le réseau, les besoins des utilisateurs, ou les règles d'usage de l'application, etc. Les entités de supervision locales 6 peuvent alors déclencher dynamiquement des actions de reconfiguration des composants applicatifs qui s'exécutent sur les dispositifs électroniques 5 de manière transparente pour l'utilisateur selon une approche décentralisée (aucun serveur central n'est requis). Une telle reconfiguration permet le déploiement et le redéploiement dynamique d'applications et peut notamment impliquer la création, la suppression ou la migration de composants. Les composants peuvent ainsi être migrés de dispositif en dispositif, de manière indépendante, quel que soit le type du dispositif source et du dispositif d'accueil en fonction du contexte d'exécution et/ou des ressources matérielles, tout en poursuivant leur exécution sur chaque dispositif qui les accueille (redémarrage à chaud). 068715 Le système de supervision 10 selon l'invention permet notamment d'assurer une continuité de service en cas d'indisponibilité d'un dispositif électronique 5. En particulier, en cas de dysfonctionnement d'un dispositif, les entités de supervision 6 peuvent fournir à l'application tout ce qu'elle attend tout en pérennisant au maximum son exécution et en anticipant des situations critiques qui peuvent être liées par exemple à la durée de vie d'une batterie ou le dépassement de la bande passante disponible. Le système de supervision 10 permet notamment de répartir la charge de l'application sur des dispositifs électroniques 5 voisins, et d'optimiser la répartition des composants de l'application sur les dispositifs électroniques voisins, lorsque le dispositif 5 sur lequel s'exécute l'application est confronté à des problèmes de ressources, comme des déconnexions dues au déchargement de la batterie. Selon un aspect de l'invention, la partie applicative (comprenant notamment le code des classes des composants et des objets échangés) n'est pas résidente sur chacun des dispositifs électroniques 5 supervisés afin de limiter la surcharge des dispositifs. Pour cela, l'entité de supervision locale 6 sur chaque dispositif comprend une fonction de chargement dynamique de code 100 pour charger dynamiquement le code associé à un composant applicatif sur un dispositif 5 en réponse à une commande de création ou de migration de ce composant sur ce dispositif. La fonction de chargement dynamique de code peut être en outre configurée pour supprimer le code associé à un composant, lorsque le composant n'est plus utilisé sur le dispositif 5. Le chargement de code dynamique selon l'invention repose en particulier sur des échanges entre un ensemble d'entités de supervision réparties sur des dispositifs électroniques 5 pouvant être de types différents, et sur des échanges internes entre l'entité de supervision du dispositif qui accueille un composant et le composant, au moyen d'un conteneur de composant créé par l'entité de supervision. Pour mettre en oeuvre la fonction de chargement dynamique de code 100, chaque entité de supervision locale 6, hébergée sur un dispositif donné, peut comprendre une unité de recherche de code 11 pour rechercher le code exécutable associé à un nouveau composant accueilli sur le dispositif électronique (création d'un composant ou migration d'un composant sur le dispositif). L'entité de supervision locale 6 utilise en outre un chargeur de code 12 pour charger le code associé au composant lorsqu'il a été trouvé (pouvant comprendre notamment la classe et les ressources logicielles du composant, ainsi que les données échangées par le composant). Le chargeur de code 12 utilisé pour charger le code associé à un composant peut être spécifique au composant ou à la classe du composant, et au dispositif. Par exemple, lorsqu'un composant Cl est migré du dispositif PC1 vers le téléphone intelligent de type 1, l'entité de supervision sur le dispositif Ti envoie un message de demande de code vers les entités de supervision des autres dispositifs P03, P02, T2, TI1 pour obtenir le code exécutable associé au composant Cl (qui peut être le code associé à la classe du composant). Lorsque le fichier de code est trouvé par l'une des entités, ici T2, il est acheminé vers Ti qui le charge dynamiquement. L'homme du métier comprendra que la représentation de la figure 1 est schématique et ne montre pas la structure 068715 détaillée des entités de supervision 6 et de leurs éléments de communication qui seront décrits plus en détail ci-après. La figure 2 montre des exemples de dispositifs 5, de types différents, exécutant des applications contrôlés par le système de supervision selon l'invention (non représenté sur la figure). Une application peut être composée de un ou de plusieurs services et chaque service peut être réalisé par un ou plusieurs assemblages de composants (représentés par les carrés grisés) reliés par des connecteurs (représentés par les lignes fléchées). L'état d'une application est ainsi constitué par l'ensemble des états des composants, des dispositifs, des connecteurs entre les composants et de l'environnement. Les entités de supervision sont configurées pour recueillir de telles données afin de les traiter et de déclencher les actions de reconfiguration qui conviennent. En réponse à ces commandes de reconfigurations, les entités de supervision peuvent coopérer entre elles pour modifier l'architecture générale de l'application (pouvant impliquer une modification de la répartition des composants sur l'ensemble des dispositifs impliqués dans l'application), en migrant certains composants (carrés grisés) d'un dispositif 5 à un autre selon un mécanisme de migration, et/ou en remplaçant un ou plusieurs composants par d'autres. La figure 3 représente la structure générale des applications 3 contrôlées par le système de supervision 10. Des applications modulaires 3 à base de composants logiciels distribués peuvent être exécutées sur les dispositifs 5. La modularité qui en résulte permet de proposer des solutions ad hoc, reconfigurables à chaud, qui garantissent la continuité des applications et leur pérennité dans le temps. Chaque application 3 selon l'invention comprend un ensemble de fonctionnalités 30 interconnectées. Chaque fonctionnalité est elle-même constituée d'un ensemble de composants logiciels 302 reliés par des connecteurs 303. Ces fonctionnalités 30 peuvent être réalisées de différentes manières à partir d'assemblages de composants 302 différents. Le système de supervision 10 dispose donc de plusieurs décompositions fonctionnelles correspondant aux diverses configurations de l'architecture. Pour pouvoir s'adapter dynamiquement, chaque application 3 a une capacité de réflexivité qui lui permet d'avoir une connaissance d'elle-même. Cette capacité de réflexivité peut lui permettre de remplacer un service défectueux ou inadapté au contexte courant par un autre service. A cet effet, le système de supervision 10 est configuré pour acquérir la connaissance de l'application en cours ainsi que le contexte de l'application de manière dynamique et transparente. Le système de supervision 10 peut être utilisé par exemple pour superviser une application de prise de notes à destination des jardiniers d'un parc botanique équipé chacun de dispositifs 5, afin de leur permettre de réaliser un suivi des plantes et de leurs évolutions (prises de photos, prises de notes, localisation, etc.). L'application peut être hébergée sur des téléphones intelligents 5 (smartphones) permettant aux jardiniers de prendre des notes géolocalisées, écrites ou orales. 068715 Chaque plante est accompagnée d'un panneau identificateur par code barre de type code OR (acronyme pour l'expression anglo-saxonne « Quick Response >>, signifiant littéralement « réponse rapide »), la lecture de ces codes OR facilitant la désignation des plantes dans les notes. Pour des raisons pratiques (position du preneur de notes par rapport au panneau), la lecture des codes OR peut être déléguée à un autre jardinier. Il est également possible de permettre à un autre jardinier de compléter une prise de notes. Lorsqu'un jardinier arrive dans le parc et dispose d'un téléphone intelligent hébergeant une entité de supervision locale 6 en cours d'exécution, un composant d'IHM (Interface Homme Machine) peut lui être déployé, offrant 3 boutons : Edition/Sélection d'une note, enregistrement d'une note vocale, activation de la géolocalisation. S'il sélectionne le premier bouton, un composant Cl de choix de note écrite ou orale est déployé lui permettant de sélectionner une note déjà présente tandis qu'un composant C2 d'accès à la base de données des notes est déployé sur le serveur central du parc. Ces deux composants Cl et C2 sont reliés entre eux par des connecteurs. Si le jardinier choisit une note écrite, un composant d'édition C3 est déployé. Lorsqu'il souhaite introduire une lecture (scan) de code OR dans sa note, la liste des dispositifs des autres jardiniers présents dans le parc lui est proposée. Il peut alors choisir de scanner lui-même la note ou de déléguer cette tâche à l'un de ses collègues. Dans ce dernier cas, un composant d'alerte (vibreur et message) C4 est déployé sur le terminal de ce collègue afin de l'avertir de la demande. Si le collègue accepte, ce composant d'alerte C4 est remplacé par un composant C5 de lecture de code OR qui est relié par connecteur au composant de prise de notes C6 du premier jardinier. Dès que la lecture du code a été faite et le résultat inséré dans la note, le composant de lecture (scan) et le connecteur sont automatiquement supprimés. Si le jardinier a mis en marche la géolocalisation, lorsqu'il sauvegarde sa note sur le serveur du parc, elle pourra être automatiquement géolocalisée. Lors d'une consultation ultérieure de cette note, cette géolocalisation ainsi que la date seront accessibles. La figure 4 illustre les interactions entre les composants 302 et des connecteurs 303 selon l'invention. Le système de supervision 10 forme une plateforme de supervision qui est distribuée sur les dispositifs 5 de manière à avoir connaissance des composants 302 et des connecteurs 303 déployés. Elle est en outre configurée pour récupérer les informations de contexte que ceux-ci peuvent lui transmettre. En fonction de ces informations, le système de supervision 10 détermine si des reconfigurations doivent être mises en oeuvre, impliquant le déploiement et le redéploiement dynamique de composant. Les entités de supervision 6 utilise des conteneurs 305 pour surveiller le fonctionnement des composants 302 et la circulation des flux de données entre les composants 302 connectés par les connecteurs 303, sur le dispositif associé. Les conteneurs 305 sont configurés pour recueillir les 068715 informations entre les entités 302 et 303. Ils permettent en outre de gérer l'hétérogénéité matérielle et logicielle des dispositifs 5 ainsi que la mobilité des dispositifs. La figure 4 montre plus précisément un modèle de conteneur 305 de composant 302 de type Composant Métier. Dans la suite de la description, les termes « composants métier », « composants applicatifs « composants logiciels » ou simplement « composants » pourront être utilisés de manière similaire pour désigner un composant. Selon ce modèle de conteneur 305, la logique métier contenue dans un composant métier est séparée de la supervision gérée par un conteneur. Le Composant 302 peut recevoir plusieurs flux de données en entrée et produire plusieurs flux de données en sortie. Par ailleurs, chaque flux de sortie peut être dupliqué. Le conteneur 305 représenté encapsule un seul composant 302 et peut implémenter un ensemble de propriétés non-fonctionnelles, telles que la gestion du cycle de vie, la récupération des informations de qualité de service et la gestion des communications. Le conteneur 305 associé à un composant sur un dispositif est créé par l'entité de supervision 6 qui accueille le composant, tandis que le code du composant est chargé dynamiquement. Le conteneur 305 possède trois types unités : Une ou plusieurs unités d'entrée (UE) désignées par la référence 41 pour recevoir les flux de donnée en entrée, Une ou plusieurs unités de sortie (US) désignées par la référence 42 pour recevoir les flux de donnée en sortie, et Une Unité de contrôle (UC) désignées par la référence 40. Les unités UE d'entrée 41 et les unités US de sortie 42 peuvent être reliées à un ou à plusieurs connecteurs 303. Ces unités 41 et 42 permettent au Composant 302 de lire et d'écrire des données provenant d'autres composants 302 ou à destination d'autres composants 302. Le composant 302 peut ainsi lire des données via les unités d'entrée 41, effectuer son traitement et écrire les résultats dans les unités de sortie 42. L'entité de supervision 6 du dispositif hébergeant le composant peut utiliser l'unité de contrôle 40 (UC) pour superviser le conteneur 305.Pour cela, chaque conteneur 305 de composant peut enregistrer son unité de contrôle 40 comme un service permettant à l'entité locale de supervision de contrôler les différentes phases du cycle de vie d'un composant 302. L'unité de contrôle 40 contrôle les éléments du conteneur 305 de composant. Par exemple, le comportement du composant peut être contrôlé par l'unité de contrôle 40 au moyen d'une méthode d'initialisation de composant (appelée init()), d'une méthode de suppression de composant (appelée « destroy ») ou encore d'une méthode d'activation de composant (appelée « Run BC »). Les unités d'entrée et de sortie 40 et 41 contrôlent la circulation des données dans le conteneur 305 et donnent au composant des accès à ses flux d'entrée et de sortie. 068715 La fonctionnalité principale d'un connecteur 303 est de relier deux composants 302 entre eux et de faire circuler l'information entre eux. De la même manière qu'un composant 302, un connecteur 303 constitue un élément de première classe (élément pouvant être créé ou détruit dynamiquement). Les connecteurs 303 ne sont pas limités à la mise en oeuvre d'un ou de plusieurs modes de communication spécifiques (par exemple de type Client/Serveur, Pipe & Filter, etc.). Par ailleurs, un connecteur 303 peut agir sur l'information échangée entre deux composants de manière à adapter (techniquement ou sémantiquement) les données. Pour cela, chaque connecteur 303 peut comprendre lui-même un composant. Par ailleurs, les connecteurs 303 peuvent être eux même encapsulés dans des conteneurs. Dans une forme de réalisation préférée de l'invention, chaque composant comprend plusieurs classes (classe du composant, classes des données échangées) et peut inclure des ressources et des bibliothèques qui sont chargées dynamiquement lors de la création de la première instance du composant sur le dispositif. La figure 5 illustre le cycle de vie d'un composant 302. Les composants associés à une application donnée sont initialement écrits par le concepteur de l'application. L'entité de supervision 6 du dispositif accueillant un composant encapsule le composant 302 dans un conteneur 305 qui en contrôlera le cycle de vie. Le cycle de vie d'un composant peut correspondre à l'appel de méthodes surchargées. Ce cycle de vie d'un composant est généralement similaire à celui d'une « applet » (terme désignant un logiciel qui s'exécute dans la fenêtre d'un navigateur web), d'un MIDIet (acronyme pour « Mobile Information Device applet » et désignant un programme installé dans un dispositif d'information mobile) ou d'une activité du système d'exploitation Android. Le cycle de vie d'un composant 302 correspond aux trois types d'actions mises en oeuvre par les entités de supervision 6: la création d'un composant sur une machine hôte, la suppression d'un composant sur une machine hôte et la migration d'un composant entre deux machines hôtes reliées en réseau. La création d'un composant 302 comprend l'instanciation d'un objet de la classe associée (comprenant le chargement de code exécutable associé au composant), l'encapsulation de cet objet dans un conteneur 305 puis la connexion de ses flux d'entrée et de sortie. La suppression d'un composant 302 comprend l'arrêt du composant encapsulé puis la suppression de son conteneur 305 sur le dispositif. Le fichier de code associé au composant peut alors être supprimé si le dispositif ne contient plus aucun composant de la même classe que le composant. Ses flux d'entrée/sortie peuvent rester en attente d'un nouveau composant ou d'être à leur tour supprimés. La migration d'un composant est mise en oeuvre lorsqu'un composant 302 s'exécutant sur un hôte A doit être migré vers un hôte B. L'entité de supervision 6 hébergée sur l'hôte A arrête alors le composant au niveau de l'hôte A comme lors d'une suppression, puis envoie le composant à 068715 l'entité de supervision sur l'hôte B en utilisant un mécanisme de sérialisation des propriétés du composant, si le dispositif B ne dispose pas du code associé au composant. L'entité de supervision 6 détourne ensuite l'ensemble des connecteurs 303 reliés à ce composant 302 vers leurs nouvelles destinations constituées par l'hôte B. Le composant 502 reçu en B est encapsulé dans un conteneur 305 puis l'entité de supervision 6 reconnecte les flux d'entrée et de sortie du composant. Lorsqu'un composant 302 est créé, il passe de l'état « non-présent », désigné par la référence 60, à l'état « Initialisé », désigné par la référence 61, où il exécute une méthode d'initialisation appelée « mit ». Il passe ensuite dans l'état « Actif », désigné par la référence 62, où il exécute une méthode d'exécution appelée « run BC ». Un composant peut également passer directement de l'état « non-présent » (60) à l'état « actif » (61) lorsqu'il est reçu sur le dispositif électroniques suite à une migration. Dans ce cas le composant est démarré à chaud dans le même état que celui où il se trouvait précédemment sur le dispositif source depuis lequel il a été migré, de sorte qu'aucune phase d'initialisation n'est requise. Lors d'appels de fonctions de l'interface de programmation API (acronyme pour l'expression anglo-saxonne « Application Programming Interface »), comprenant par exemple des fonctions de type lecture, écriture, services du système de supervision, le composant peut être mis dans un état « Bloqué », désigné par la référence 63. Depuis l'état Actif 62 et l'état Bloqué 63, le composant 302 peut être arrêté et mis dans l'état « Détruit » (état 64) où il exécute une méthode appelée « Destroy ». Un composant 302 peut passer de l'état actif 62 à l'état détruit 64 s'il est en fin d'activité ou a été migré vers un autre dispositif. Un composant peut notamment passer de l'état « bloqué » 63 à l'état « détruit » 64 sur un dispositif donné 5, lors d'une migration vers un autre dispositif électronique 5. Les transitions entre les états 50 à 54 sont provoquées par des exceptions. Une exception désigne une interruption de l'exécution d'un programme en réponse à un évènement spécifique pouvant entraîner un changement d'état. Selon une caractéristique de l'invention, deux classes d'exception peuvent être utilisées : Une première classe appelée « StopBCException » qui représente une exception qui peut être utilisée pour provoquer des changements d'état lors de tentatives de lecture ou d'écriture ou lors d'accès aux services du système de supervision (passage de l'état actif 62 à l'état bloqué 63). Une deuxième classe appelée « InterruptedException » qui peut être utilisée pour provoquer des changements d'état lorsqu'un composant 302 est dans l'état bloqué 63 sur un sémaphore ou est suspendu. Après l'exécution de la méthode « Destroy » (dans l'état « détruit » 64) ou après un laps de temps prédéfini, si l'exécution de la méthode « Destroy » ne se termine pas, le composant 302 peut être détruit ou migré. Lors d'une migration du composant 302, ses propriétés sont sérialisées et, sur le nouveau dispositif électronique d'accueil 5, il est directement mis dans l'état Actif 52. 068715 Selon une caractéristique de l'invention, les classes d'un composant 302 sont chargées dynamiquement lors de la création de la première instance du composant 302 sur un dispositif ou de la réception de la première instance du composant migré sur un dispositif et peuvent être dynamiquement supprimées lors de la suppression de la dernière instance du composant sur ce dispositif (transitions 50-51 et 50-52). Plus précisément, le code des composants 302 est chargé dynamiquement en réponse à la création ou à la migration d'un composant sur un dispositif s'il ne détient pas le code associé au composant. L'entité de supervision 6 sur le dispositif qui accueille le nouveau composant (dispositif demandeur ou dispositif d'accueil) est configurée pour coopérer avec un ensemble d'entités de supervision 6 sur d'autres dispositifs 5, pouvant être de types différents de celui du dispositif demandeur, afin de rechercher le code associé au composant et de le relayer au dispositif demandeur, lorsque le code exécutable du composant n'est pas résident sur ce dispositif. En particulier, un dispositif peut détenir le code associé à un composant, soit parce qu'il héberge un composant de la classe du composant recherchée, soit parce qu'il gère un dépôt de composant, ce qui peut être le cas de certains hôtes non contraints (les dispositifs contraints ont des ressources plus limitées, comme par exemple les téléphones mobile). L'entité de supervision 6 sur le dispositif demandeur peut être configurée pour attendre une réponse au message de demande de code pendant un délai paramétrable, au terme duquel le code demandé peut être considéré comme n'existant pas. Dans les formes de réalisation préférées de l'invention, le code de composant échangé entre les dispositifs 5 pour le chargement de code de ce composant sur un dispositif peut se présenter sous la forme d'un fichier de code. En particulier, pour les dispositifs 5 ayant un système d'exploitation de type JAVA, le fichier de code de composant est un fichier de code binaire Java appelé fichier JAR (fichier interprétable par le système d'exploitation). La suite de la description sera faite en référence à un fichier de code de type JAR. La figure 6 représente un exemple de dépôt de composants 60 placé sur un dispositif non contraint (par exemple, ordinateurs personnels PCs). Un dépôt de code 60 peut stocker, pour chaque type de dispositif, les fichiers de code associés aux composants. Le dépôt de code peut être partiel, en ce sens qu'il ne contient pas tous les codes de composants utilisés par les dispositifs, mais seulement le code de certains composants (par exemple, les composants les plus utilisés). Par ailleurs, pour optimiser les performances de certains dispositifs ayant des capacités de traitement plus faibles, dits dispositifs contraints, (par exemple, dispositif contraint de type téléphone), seuls certains dispositifs non-contraints 5 peuvent être associés à un dépôt de code complet ou partiel. Cela permet de limiter la surcharge de certains dispositifs (notamment les dispositifs non contraints), liée au maintien du dépôt de code et à l'envoi de code en réponse aux demandes des entités de supervision. 068715 Selon un autre aspect de l'invention, les dépôts de code peuvent être modifiés par le concepteur des composants. Le concepteur de composant peut ainsi ajouter, à tout moment, de nouveaux composants sur un ou plusieurs dépôts. La gestion des dépôts de code peut être contrôlée de différentes manières. Par exemple, une entreprise développant des composants peut héberger des dépôts de code sur ses propres machines, le cas échéant en limitant l'accès à ces dépôts (par exemple par un système d'abonnement), ou les déposer sur des machines librement accessibles. Lorsqu'un dispositif 5 gère un dépôt de code, le dépôt de code 60 peut être stocké sur une zone mémoire du dispositif, par exemple sur un disque ou sur carte mémoire amovible de stockage SD (acronyme pour « Secure Digital ») pour les dispositifs de type tablettes informatiques ou téléphones. Un dépôt de code 60 peut être structuré en sous-dépôts 61 correspondant aux différents types d'hôtes existants Ti, T2, Ti, etc. (par exemple PC, Android, etc.). Certains types de dispositif peuvent utiliser un tel dépôt de composants 60, comme par exemple les dispositifs de type PC tandis que d'autres ne sont pas configurés pour gérer un tel dépôt. Dans le dépôt de composant 61, chaque composant est représenté par son fichier de code Cil, Ci2, Cin, etc. Selon un aspect de l'invention, chaque fichier de code associé à un composant Cil, Ci2, Cin, etc. peut comprendre les informations suivantes : - Le code binaire 602 (« byte code » en langue anglo-saxonne) de chaque classe nécessaire au fonctionnement de ce composant 302 (incluant des bibliothèques) et des classes des objets échangés entre composants; - Les ressources 604 utilisées par le composant (par exemple, images, fichiers, etc.); - Le nom de la classe du composant 606 qui peut être inclus par exemple dans un fichier de type « manifest ». Le nom de la classe 606 peut être utilisé par l'entité de supervision locale 6 du dispositif maintenant le dépôt de code 60 pour retrouver un fichier de code associé à un composant (si le dispositif est le dispositif d'accueil ou s'il en reçoit la demande depuis l'entité de supervision d'un autre dispositif). Ainsi, lorsque l'entité de supervision locale 6 d'un dispositif vérifie si elle détient le code d'un composant, soit parce que le composant vient d'être créé ou migré sur ce dispositif, soit parce qu'elle en a reçu la demande depuis l'entité de supervision d'un autre dispositif demandeur, elle peut utiliser le nom de classe du composant (si le composant est accueilli localement par le dispositif) ou le nom de la classe et le type de dispositif demandeur, si la demande vient d'un autre dispositif demandeur (ces informations seront alors incluses dans le message). 068715 La figure 7 est un organigramme représentant les étapes principales mises en oeuvre pour la recherche de code associé à un composant créé ou migré sur un dispositif A, lorsque le fichier de code n'est pas résident sur le dispositif, selon les formes de réalisation de l'invention. La création d'un composant sur le dispositif électronique A peut être déclenchée dynamiquement en fonction du contexte et/ou de l'état des ressources. Dans ce cas, le composant 302 sera démarré sur le dispositif d'accueil depuis un état initial. Dans le cas où le composant 302 est migré vers le dispositif électronique A depuis un autre dispositif source, le composant 302 est sérialisé et encapsulé dans une classe du système de supervision par l'entité locale 6 sur le dispositif source avant la migration. La sérialisation comprend le codage de l'état des propriétés du composant pour permettre son redémarrage à chaud sur le dispositif A. Les propriétés sérialisées sont ensuite encapsulées dans un conteneur de l'entité de supervision 6 du dispositif source. La lecture des propriétés par l'entité de supervision sur le dispositif A ne peut se faire que si le dispositif A dispose du code des classes de ces propriétés pour pouvoir désencapsuler les propriétés du composants et les affecter au composant. Ainsi, lorsque le dispositif A reçoit le composant 302, ses propriétés ont été sérialisées. Toutefois, le dispositif A qui reçoit un composant doit également disposer de la classe du composant 302 (code binaire en JAVA) pour pouvoir démarrer le composant dans le même état (redémarrage à chaud). En réponse à une commande de création d'un nouveau composant ou de migration d'un composant (700) sur un dispositif A (composant migré depuis un dispositif source), l'entité de supervision sur le dispositif A détermine si le fichier de code associé au composant (correspondant à la classe du composant) est disponible sur le dispositif (701). S'il est disponible, l'entité de supervision sur le dispositif A charge les classes du composant (709). Sinon, l'entité locale de supervision 6 placée sur l'hôte A où le composant est créé (création ab initio ou suite à une migration) envoie un message de demande de code à un ensemble d'entités de supervision sur d'autres dispositifs à l'étape 703. Le message comprend des informations relatives au composant et peut comprendre notamment le nom de la classe de composant 302 recherché ainsi que le type du dispositif électronique A (par exemple dispositif sous Android, ordinateur personnel PC). Les dispositifs vers lesquels est envoyé le message de demande de code peut être de tout type, et en particulier peut être différent du type du dispositif demandeur. La diffusion du message vers l'ensemble d'entité de supervision à l'étape 703 peut être réalisée de différentes manières, directement ou indirectement, selon les possibilités associées aux réseaux dont dépend le dispositif A, par exemple par diffusion (« broadcast » en langue anglo-saxonne), multi-diffusion (« multicast » en langue anglo-saxonne) ou diffusion point à point. 068715 Si l'entité locale 6 d'un dispositif S qui reçoit un tel message de demande de recherche de code (704) dispose de la classe de composant recherchée (704), elle envoie à l'entité locale 6 du dispositif source A le fichier de code contenant cette classe de composant (par exemple, fichier JAR en JAVA), à l'étape 706. Une telle situation peut se produire notamment lorsque l'entité locale 6 du dispositif S gère un dépôt de composants 60 ou en variante lorsque le dispositif S est du même type que le dispositif A accueille un composant 302 de la même classe que la classe recherchée. Le nom de la classe 606 contenu dans les fichiers de code 61 et le type de dispositif spécifié dans le message de demande de code permette à l'entité locale de supervision 6 de déterminer s'ils contiennent la classe demandée. Sinon, si l'entité locale 6 du dispositif S ne possède pas le fichier de code associé à la classe du composant recherché, elle rediffuse de la même manière que le dispositif A (étape 703) le message de demande de code à un ensemble d'entités de supervision en fonction des types de réseaux auxquels elle peut accéder, à l'étape 708, directement ou indirectement selon les capacités de diffusion (broadcast ou multicast ou autre). Dans certaines formes de réalisation de l'invention, l'entité de supervision 6 du dispositif S peut également indiqué dans le message relayé que leurs réponses doivent repasser par le dispositif S qui les transmettra au dispositif A (en se désignant comme relai possible). Les dispositifs qui reçoivent le message relayé à l'étape 708 et qui possèdent la classe recherchée, par exemple parce qu'ils gèrent un dépôt de classes de composants 60 ou encore parce qu'ils possèdent une instance de la classe du composant, répondront alors au dispositif S qui pourra donc jouer le rôle de relai pour l'envoi du fichier de code vers le dispositif demandeur. Sinon, elles diffusent le message de la même manière (étape 708) vers les entités de supervision qui leurs sont accessibles. Dans une forme de réalisation de l'invention, les messages ne sont relayés qu'une fois, de sorte que la réponse revient au dispositif demandeur A soit directement, soit au travers d'un seul relai. En réponse à la réception du fichier de code correspondant à la classe de composant recherché (fichier « .jar >>) depuis l'une des entités de supervision qui a reçu le message de demande de code, l'entité de supervision du dispositif demandeur charge le fichier de code de composant sur le dispositif demandeur pour permettre l'initialisation du composant, s'il s'agit d'une création directe, ou le redémarrage à chaud du composant, si le composant a été migré depuis un dispositif source. Dans le cas où le composant a été migré depuis un dispositif source sur le dispositif A, le dispositif demandeur A qui reçoit le fichier associé à la classe du composant crée une instance du composant par désencapsulation et dé-sérialisation de ses propriétés et le démarre à chaud. L'entité de supervision locale du dispositif demandeur peut alors envoyer des commandes vers les entités de supervision 6 hébergées sur d'autres dispositifs 5 pour assurer la redirection des connecteurs 303 liés au composant 302 migré. Pour charger le fichier de code reçu depuis une autre entité de supervision, l'entité de supervision locale 6 du dispositif A peut créer un chargeur de code 11 (encore appelé chargeur de classe) associé au fichier de code à l'étape 707, puis utiliser le chargeur de code pour charger les classes 068715 du composants et des données échangées par le composant à partir du fichier de code à l'étape 709. Pour optimiser l'occupation en mémoire, le fichier de code correspondant à la classe recherché (fichier jar) pourra être supprimé sur le dispositif A, dès que la dernière instance du composant 302 qui l'utilise sera supprimée. La figure 8 est un organigramme illustrant le chargement dynamique des classes de composant (étape 709 de la figure 7) sur le dispositif électronique A, selon différents cas. L'entité de supervision résidente sur chaque dispositif peut posséder un certain nombre de classes utilisables par tous les composants 302 (classes résidentes). Ainsi, si la classe du composant est résidente sur le dispositif (800), comme par exemple une classe standard Java ou une classe incluse dans l'entité locale de supervision 6, à l'étape 801 l'appel est transmis au chargeur de classes standard de java. Le chargeur standard de la machine virtuelle JAVA permet le chargement dynamique de code par le biais de spécialisations de la classe du chargeur. Si la classe du composant n'était pas connue (802)et a été chargée à l'étape 707 de la figure 7 par le procédé de chargement dynamique de code, un chargeur de code (encore appelé chargeur de classe) associé au fichier est créé par l'entité locale de supervision 6 et enregistré (étapes 707 de la figure 7) à l'étape 803. Il est ensuite utilisé pour charger le code (804). Le chargeur de classe associé à chaque fichier est stocké sur le dispositif A où il est créé. Le rôle de ce fichier de classe est de charger dans la mémoire de la machine le code correspondant à une classe demandée (en recherchant dans le fichier auquel il est associé la partie de code correspondant à la classe demandée). A chaque composant 302 hébergé sur un dispositif est ainsi associé le chargeur de classes qui a servi à le créer sur ce dispositif de telle sorte que les créations futures d'objets issus de ce composant (par exemple lorsque le composant créé un objet qu'il veut envoyer par un connecteur de sortie) peuvent se faire ensuite au travers de ce même chargeur de classes. Dans les dispositifs dépendants du système d'exploitation JAVA, la création du chargeur de classe peut comprendre la définition d'une classe spécifique (appelée Classloader) pour charger du code dans la machine virtuelle java et l'instanciation d'un objet ensuite associé au composant CM. Dans le cas particulier où le dispositif électronique A utilise un système d'exploitation de type Android, le chargeur de classe peut en outre hériter d'un autre type de classe de chargement de code appelé « DexClassLoader » car le code binaire et la façon de charger le code sur les dispositifs de type Android sont différents. Selon une caractéristique de l'invention, le lien entre le composant 302 et son chargeur de classes peut être mémorisé dans le conteneur 305 du composant 302 (sous la forme d'un objet qui peut être ajouté aux propriétés du conteneur). Cette association entre un composant 302 et un chargeur de classes permet l'accès par un composant 302 aux ressources incluses dans le fichier de code associé au composant (fichier Jar) au moyen de méthodes d'accès aux ressources appelées 068715 «getResourceAsStream » (pour recevoir les données sous forme de flux) et « getResourceAsByteArray » (pour recevoir les données sous forme de données binaires). Ces méthodes appartiennent à la classe du modèle de composant dont il hérite, appelée BCModel. Le chargeur de classes pour un dispositif de type ordinateur personnel (PC) diffère de celui utilisé pour un dispositif utilisant le système d'exploitation Android en raison du mode différent de chargement de classes entre ces deux types de dispositifs. Si la classe du composant 302 est comprise dans un fichier disponible localement (805), l'entité de supervision locale 6 transmet l'appel au chargeur de classes 11 associé à ce fichier à l'étape 806 (cas où la condition 701 est vérifiée). Une telle situation se produit par exemple, si le dispositif A gère un dépôt de code ou possède un composant de la même classe que le nouveau composant. Un tel chargeur de classes a été créé lors de la réception initiale du fichier de code associé au composant par le dispositif (conformément aux étapes 802 et 803) pour la création de la première instance du composant. Le chargeur de classes 11 associé au fichier de code est alors utilisé pour charger la classe du composant ainsi que les classes des objets en entrée et sortie du composant. Le chargement dynamique de code de composant mis en oeuvre par le système de supervision permet ainsi d'ajouter dynamiquement des fonctionnalités sans relancer l'application et de remplacer certains composants par d'autres contextuellement mieux adaptés afin de fournir une qualité de service optimale. Par ailleurs, les composants déployés pour les besoins d'une application peuvent être supprimés de manière transparente dès lors qu'ils ne sont plus utilisés, afin de limiter la surcharge des dispositifs. En contrôlant le cycle de vie des composants, chaque entité de supervision a, à chaque instant, une connaissance de l'état des composants, ce qui lui permet de détecter si un composant n'est plus utilisé sur son dispositif, et de supprimer le code associé au composant. Un message de demande de code peut être envoyé de différentes manières vers un ensemble d'entités de supervision sur d'autres dispositifs (étape 704 de la figure 7), selon les capacités associées aux réseaux de communication dont dépend le dispositif demandeur A. La figure 9 est un organigramme illustrant l'envoi d'un message de demande de code de composant depuis l'entité de supervision d'un dispositif demandeur, en réponse à la création ou à la migration d'un composant, selon les capacités de diffusion disponibles. Si le dispositif demandeur A appartient à un réseau de communication permettant la diffusion simple (« broadcast » en langue anglo-saxonne) ou la multi-diffusion (« multicast » en langue anglo-saxonne), l'entité de supervision envoie sa demande par diffusion (« broadcast » ou « multicast »). Le message de demande de code est alors reçu par les entités de supervision des dispositifs couramment connectés sur ce réseau (dispositifs voisins), qui continuent à le relayer de la même façon, si elle ne dispose pas du fichier de code recherché. Chaque entité de supervision 068715 qui relaie ainsi le message à d'autres entités de supervision peut se désigner comme relai possible pour le retour de la réponse vers l'entité de supervision du dispositif demandeur A. L'entité de supervision sur le dispositif demandeur A procède ainsi conformément aux étapes suivantes, si la diffusion des messages (broadcast ou multicast) entre les dispositifs mobiles est possible (900) : - Un message de demande du fichier de code associé à d'un composant est envoyé en broadcast/multicast aux dispositifs voisins sur tous les réseaux accessibles, le message indiquant le type du dispositif A et le nom de la classe 606 recherchée (901). - Les entités de supervision locales 6 des dispositifs voisins 5 qui reçoivent le message de recherche de classe traitent le message comme expliqué en relation avec la figure 7: Si le dispositif voisin qui reçoit le message possède cette classe, par exemple parce qu'il gère un dépôt de classes, ou parce qu'il possède une instance de cette classe, son entité de supervision 6 envoie le message vers le dispositif demandeur A qui reçoit alors le fichier de code depuis cette entité (902); sinon il relaie à son tour le message de demande de code vers les dispositifs qui lui sont accessibles, de la même manière que le dispositif demandeur, en se désignant comme relai possible pour transmettre la réponse au dispositif demandeur qui pourra alors recevoir la réponse via l'entité de supervision 6 de ce dispositif voisin. Si le dispositif demandeur A ne permet pas l'envoi de message par diffusion et dépend d'un autre réseau de communication (par exemple GSM, 3G ou 4G), l'entité de supervision 6 sur le dispositif demandeur A peut envoyer le message de demande du code du composant à un dispositif servant de proxy 14. Le proxy 14, associé à l'entité de supervision du dispositif demandeur 10, peut être un dispositif comprenant une entité de supervision 6, disposant d'une adresse publique sur Internet, et doté d'une capacité d'envoi en broadcast/multicast. Le dispositif associé au proxy peut être d'un autre type que le dispositif demandeur qui utilise le proxy. Par exemple, un dispositif de type PC peut être le proxy d'un dispositif de type Android. Il peut être préalablement associé à l'entité de supervision du dispositif demandeur par l'utilisateur au moyen d'une interface homme machine. L'envoi de messages en broadcast/multicast est alors remplacé par un envoi en direct sur le proxy associé au dispositif demandeur A qui relaiera alors les messages vers les dispositifs qui lui sont accessibles, conformément aux étapes suivantes : - le message de demande de code associé au composant est envoyé au proxy 14 (904) défini pour le dispositif A, le message indiquant le type du dispositif A et le nom de la classe 606 recherchée. - le proxy 14 reçoit le message de demande de code associé au composant (905): S'il possède la classe recherchée (906), l'entité de supervision du proxy envoie le fichier au dispositif demandeur (907) ; Sinon, le proxy 14 renvoie en broadcast/multicast le message de demande de code associé au composant sur tous les réseaux qui lui sont accessibles en se désignant comme relai pour l'hôte recherché (908). 068715 - les dispositifs qui reçoivent un message de demande de code associé au composant, relayé à l'étape, et qui possèdent les classes associés au composant (par exemple, parce qu'ils gèrent un dépôt de classes ou parce qu'ils possèdent une instance de cette classe) répondent au proxy 14 qui pourra alors jouer le rôle de relai. Le fichier de code trouvé pourra alors être relayé au dispositif demandeur par le proxy (909) ; sinon, ces dispositifs relaient le message vers les dispositifs qui leurs sont accessibles, de la même manière que le dispositif demandeur, notamment soit par diffusion broadcast ou multicast, s'ils en ont la capacité, soit via un proxy respectif 14 qui leur est associé. Cette approche est similaire à l'approche de recherche de classe par diffusion de type broadcast ou multicast, à la différence que seuls les dispositifs pouvant être atteints par le proxy 14 sont utilisables comme fournisseurs de classes, de tels dispositifs ne pouvant dialoguer que par le biais de cet hôte de référence. Dans certaines formes de réalisation de l'invention, l'entité de supervision locale 6 sur chaque dispositif électronique est configurable par le biais d'une interface pour spécifier si elle peut ou non utiliser une diffusion de type broadcast/multicast et, le cas échéant, quel proxy 14 elle utilise. Par ailleurs, la gestion du proxy à utiliser pour la recherche de classes de composant, lorsque le dispositif électronique n'est pas doté de capacité de diffusion broadcast ou multicast, peut être directement intégrée à l'entité locale de supervision 6. Pour les dispositifs 5 ayant par nature une capacité de diffusion broadcast/multicast, l'envoi de message par diffusion de type broadcast/multicast peut être utilisé par défaut pour la recherche de classe. Dans certaines formes de réalisations de l'invention, il peut être possible de paramétrer une entité de supervision pour forcer l'envoi des messages de demande de code par un proxy, par exemple lorsque le réseau utilisé ne permet pas la diffusion (broadcast/multicast). En variante, si le dispositif demandeur A n'est associé à aucun proxy et ne dispose pas de capacité d'envoi par diffusion, l'entité de supervision du dispositif demandeur peut envoyer le message de demande de code à tous les dispositifs qu'elle connaît comme étant ses voisins. Pour cela, l'entité de supervision peut maintenir les informations relatives aux entités de supervision avec lesquelles elle a communiqué dans une structure de données DNS (acronyme pour « Domain Name Service » signifiant littéralement Service de Nom de Domaine), stocké localement. Le DNS peut comprendre les noms et adresses de tous les dispositifs avec lesquels l'entité de supervision a communiqué. Lorsqu'une entité de supervision démarre, elle peut envoyer un message de démarrage (par exemple "Hello" signifiant « Bonjour ») aux entités de supervision qui sont connectées sur le même réseau, de sorte que toute nouvelle entité de supervision qui entre sur un réseau est connue et génère une entrée sur les DNS de toutes les entités de supervision couramment connectées sur ce réseau. 068715 La figure 10 illustre la communication entre les entités de supervision pour le chargement dynamique de code, selon certaines formes de réalisation de l'invention. L'entité de supervision locale 6 de chaque dispositif 5 peut communiquer avec les entités de supervision sur les autres dispositifs 5 non seulement pour lancer la recherche de code pour la création ou la migration d'un composant sur le dispositif 5 associé à l'entité de supervision (si le code n'est pas disponible localement, l'entité de supervision ayant alors un rôle client pour l'envoi de messages de demande de code de composant vers les dispositifs voisins), mais aussi pour effectuer une recherche de code pour un composant crée ou migré sur un autre dispositif, à la demande de l'entité de supervision de ce dispositif (rôle serveur). Elle peut également communiquer avec les entités de supervision sur d'autres dispositifs en tant que simple relai pour relayer un fichier de code à acheminer vers un dispositif demandeur. Dès que du code non résident est nécessaire, suite à la création d'un composant sur un dispositif ou à la migration d'un composant sur le dispositif, l'entité de supervision 6 lance une recherche de code auprès de l'unité de recherche de code 11 (également appelée «classfinder») en lui indiquant le code recherché. Le code recherché peut être identifié par le nom de la classe du composant 302. L'unité de recherche de code lance la recherche de code en émettant un message de demande de code. Chaque entité de supervision 6 peut comprendre au moins une file d'attente 101 pour stocker les messages de demande de code qui doivent être envoyés vers d'autres dispositifs. Cette file d'attente 101 permet à l'entité de recherche de code d'utiliser le réseau en concurrence avec d'autres services de l'entité de supervision ou les connecteurs 303. Lors de l'envoi d'un message par une entité de supervision locale 6, le message peut ainsi être mis en attente dans une file d'attente jusqu'à ce que le réseau soit disponible et/ou jusqu'à ce que le message puisse être réellement envoyé. Du point de vue de l'unité de recherche de code 11, l'envoi est considéré comme fait, mais dans les faits l'envoi peut être différé. Chaque entité de supervision 6 peut comprendre en outre au moins un émetteur 102 (appelé sur la figure « classFinderBroadcastSender >>) pour transmettre les messages de demande de code placés dans la file d'attente 101 à un client d'envoi 103 correspondant au réseau approprié en fonction du destinataire du message. Dans la forme de réalisation préférée de l'invention, lorsque l'envoi par diffusion (broadcast ou multicast) est possible, l'entité de supervision locale 6 utilise un client d'envoi par diffusion de message (broadcast ou multicast) 102, appelé, ce qui permet d'envoyer le message simultanément vers plusieurs dispositifs voisins. L'émetteur 102 peut envoyer les demandes de codes de la file d'attente 101 vers les entités de supervision 6 des dispositifs 5 voisins par diffusion via le client d'envoi 103 par diffusion (broadcast ou multicast), appelé « IPBroadcastServer >>. Le client d'envoi par diffusion 103 peut en outre recevoir les demandes de codes reçues en diffusion broadcast/multicast depuis les entités de supervision 6 d'autres dispositifs 5 et les transmettre à l'unité de recherche de classe 11. En réponse à de telles 068715 demandes, l'unité de recherche de classe 11 détermine si le code de composants réside sur le dispositif 5, à partir d'un dépôt de code de composants si le dispositif associé gère un tel dépôt ou parmi les fichiers de code de composants qu'elle a reçu pour les composants qu'elle héberge. Si elle trouve le code de composants, elle renvoie le code recherché vers un émetteur 104 destiné à renvoyer la réponse au dispositif relai indiqué dans le message de demande pour le réacheminer vers le dispositif demandeur. Sinon, si le code n'est pas trouvé localement (le dispositif ne détient pas de composant de la même classe que le composant qui a été créé sur le dispositif distant), elle envoie un message à l'émetteur 102 (via la file d'attente 101) pour que le message de demande de code qu'elle a reçu soit rediffusé vers les dispositifs voisins. Si le client d'envoi par diffusion 103 ne peut pas atteindre le destinataire identifié dans un message, il peut le notifier à l'émetteur 102 qui peut faire appel à une unité de routage 15. L'unité de routage 15 est configurée pour déterminer si un autre dispositif 5 peut servir de relai. Lorsque l'unité de routage 15 identifie un tel dispositif relai, le message est transmis à ce dispositif relai qui le transmettra au destinataire. Chaque entité de supervision 6 fonctionnant sur un dispositif électronique 5 qui dispose d'une adresse publique peut lancer un serveur supplémentaire de proxy 14. Sur un dispositif 5 configuré pour accéder à un réseau par satellite, l'adresse de l'un de ces proxys peut être spécifiée au préalable à l'entité de supervision du dispositif via une interface. Le dispositif 5 pourra alors établir une connexion avec ce proxy qu'il conservera ouverte afin de pouvoir recevoir des messages et des données. Le dispositif 5 peut lancer également un client 105 lié à ce proxy 14 qui sera alors choisi par son émetteur de messages 102 pour tous les messages envoyés par son entité de supervision locale 6, si une diffusion de type broadcast/multicast n'est pas possible, par exemple lorsque les dispositifs électroniques sont de type 3G. L'entité de supervision locale 6 peut utiliser le client d'envoi lié au proxy 105 pour envoyer les messages de recherche de code vers le proxy 14 directement joignable qui lui a été associé au préalable pour l'envoi de demandes de recherche de code émises par l'unité de recherche de classe 12. Le proxy 14 défini pour un dispositif donné peut être un autre dispositif 5 supporté par le système de supervision, joignable par le dispositif 5 par exemple en liaison GSM, et qui est doté d'une capacité d'envoi en broadcast/multicast. L'envoi de messages en broadcast/multicast est alors remplacé par un envoi en direct sur le proxy 14 associé au dispositif A qui relaiera alors les messages vers les autres dispositifs mobiles. Ainsi, pour une recherche de code de composant (rechercher de classe du composant), si la diffusion broadcast/multicast n'est pas possible, l'émetteur 102 envoie les demandes de codes de la file d'attente 101 vers le client de proxy 14 qui les transmet directement au proxy 14 via le réseau de communication supporté. Dès que le proxy 14 dispose du fichier de code de composant recherché, soit parce qu'il le possède, soit parce qu'il lui a été relayé par l'un des dispositifs auquel il a envoyé le message de demande de code par diffusion broadcast, il le renvoie au client 105 de proxy qui le transmettra à l'unité de recherche de code 11. 068715 En complément, pour éviter les déconnexions qui peuvent être provoquées par les fournisseurs d'accès, lors de l'établissement d'une connexion avec le proxy 14, le client d'envoi 105 peut envoyer, à intervalles réguliers un message de test appelé « PING » (également désigné par l'acronyme « Packet InterNet Groper ») destiné à maintenir la connexion ouverte avec le proxy. Cet échange de messages de test permet également au dispositif 5 et au proxy 14, de détecter les pertes de connexion (dues par exemple à la mobilité). En outre, des écouteurs peuvent être utilisés (tel que par exemple l'écouteur de diffusion appelé « BroadcastReceiver » pour les dispositifs de type Android) pour permettre aux dispositifs mobiles 5 de basculer automatiquement d'un mode de fonctionnement par proxy 14 au mode de fonctionnement normal sans proxy, lors d'un changement de type de connexion. Chaque entité de supervision locale peut en outre comprendre un sémaphore d'exclusion mutuelle 109, par exemple un mutex, pour gérer la concurrence entre les messages envoyés vers l'unité de recherche de code 11. En effet, le client d'envoi par diffusion 103 et le client de Proxy 105 ont un rôle similaire et peuvent donc déposer tous deux une requête auprès de l'unité de recherche 12. Le mutex 109 permet d'éviter que ces requêtes n'entrent en concurrence en traitant les requêtes les unes après les autres. Pour échanger avec les autres entités de supervision des messages de réponse à des demandes préalablement reçues ou envoyées, l'entité de supervision locale 6 utilise l'émetteur 104, appelé « classFinderReplySender ». L'émetteur 104 gère notamment l'envoi de réponses aux demandes de code émises par d'autres entités de supervision. Le rôle de l'émetteur 104 est ainsi d'envoyer les réponses de l'entité de supervision locale 6 via des clients d'envoi 107, selon les différents types de réseaux accessibles, vers des entités de supervision sur d'autres dispositifs. L'unité de recherche 12 place les réponses dans une file d'attente 106 pour qu'elles soient traitées les unes après les autres par les clients d'envoi 107. Par exemple, lorsque le dispositif 5 a une capacité WIFI, il peut passer par le client d'envoi 107 de type WIFI, appelé « IPReplyServer », représenté sur la figure 10. En variante, si le dispositif dispose d'autres moyens de communication, par exemple Bluetooth, les messages de la file d'attente 106 peuvent être traités par un autre client d'envoi 107 adapté (par exemple, client d'envoi Bluetooth). Sur la figure 10, un seul client d'envoi est représenté à titre d'illustration. Toutefois, l'homme du métier comprendra que l'invention n'est pas limitée à ce type de client d'envoi de réponse et que l'entité de supervision peut inclure d'autres types de clients d'envoi en fonction des réseaux disponibles. Le client d'envoi 107 peut recevoir en outre des fichiers de code transmis par des entités de supervision 6 sur d'autres dispositifs 5, en réponse à une demande émise par un dispositif demandeur. Dans ce cas, l'entité de supervision 6 sert simplement de relai pour transmettre les fichiers de code reçus vers d'autres dispositifs à destination du dispositif demandeur (rôle de relai pour le renvoi de fichier de code), le client d'envoi 107 renvoie les fichiers de code vers le destinataire final du message en utilisant les moyens de communication dont il dispose (WIFI dans 068715 l'exemple). Sinon, si le dispositif est destinataire du fichier de code, le client d'envoi 107 dépose le fichier de code dans une boîte à lettres 108. Le client d'envoi 107 est également configuré pour envoyer des fichiers de code trouvé localement par l'unité de recherche 12 à un autre dispositif 5, identifié comme relai, qui le fera suivre de la même manière jusqu'à l'entité de supervision du dispositif demandeur A, en réponse à une demande de code de composant (par exemple en WIFI dans le mode de réalisation de la figure 10). Une telle situation peut notamment se produire lorsque le dispositif 5 associé au client d'envoi 105 héberge un composant 302 de la même classe que celle qui est demandée, ou gère un dépôt 60 de code de composants. La boite aux lettres 108 est utilisée pour stocker les réponses de l'unité de recherche 12. Il est à noter que l'entité de supervision 6 peut exécuter en parallèle des commandes de reconfiguration de sorte que plusieurs demandes de code peuvent être envoyées en même temps. Les réponses peuvent ne pas revenir dans l'ordre des demandes. Aussi la boîte aux lettres 108 permet de les mettre en attente pour être traitées. Les files d'attentes 101 et 106 permettent à d'autres services de l'entité de supervision et aux connecteurs 303 d'utiliser le réseau en concurrence. De ce fait, lors de l'envoi d'un message, le message est mis en attente dans une file d'attente jusqu'à ce que le réseau soit disponible et qu'il puisse être envoyé. Du point de vue du service de l'entité de supervision ou du connecteur, l'envoi est considéré comme fait, mais il peut être différé. Dans les files d'attente 101 et 106, les demandes peuvent être associées à des règles de priorité qui seront prises en compte pour l'ordre d'envoi des demandes. L'unité de recherche de routes 15 permet au système de supervision 10 de supporter tout type de réseau de communication entre les dispositifs mobiles 5. En particulier, elle permet de relayer les messages de recherche de classe lorsque deux dispositifs 5 dépendant de réseaux de communication différents ne peuvent pas établir de communication directe entre eux. Cela permet notamment d'établir à tout moment une connexion entre deux entités de supervision locales 6. L'unité de recherche de routes 15 est interrogée par l'émetteur 102 de l'entité de supervision 6 pour déterminer un relai pour une communication avec l'entité de supervision hébergée sur un autre dispositif, lorsque cela est nécessaire. Elle peut être également interrogée pour déterminer le dispositif qui doit accueillir un connecteur relai lorsque deux composants doivent être reliés alors qu'ils ne disposent pas de possibilité de lien direct. Dans une forme de réalisation de l'invention, l'unité de recherche de routes 15 utilise un mécanisme de type « PING » et des messages en broadcast, en multicast, ou en point à point vers les hôtes voisins. Ainsi si un dispositif A cherche une route pour atteindre un dispositif B, le mécanisme est le suivant : le dispositif A tente tout d'abord d'atteindre directement le dispositif B par envoi d'un message de type PING. Si le dispositif B répond au message PING, la liaison est 068715 directe et la recherche de route est terminée. Dans le cas contraire, le dispositif A envoie à tous ses voisins (atteints par envoi par diffusion broadcast/multicast) un message de recherche du dispositif B. Chacun de ses voisins tente alors de joindre le dispositif B par un message de PING. Les dispositifs qui parviennent à joindre le dispositif B indiquent au dispositif A qu'ils peuvent servir de relai pour le dispositif B. Ceux qui n'y parviennent pas diffusent à leur tour cette demande à leurs propres voisins. Le dispositif A peut recevoir plusieurs réponses. Dans ce cas, il peut choisir comme route celle qui correspond à la première réponse reçue et qui représente la route la plus rapide. La figure 11 montre un exemple d'architecture de noyau pour chaque entité locale de supervision 6 pour le contrôle de la communication entre composant. Chaque entité locale de supervision 6 peut comprendre : - Un enregistreur de services 2 qui permet à l'entité locale de supervision 6 d'accéder à un ensemble de services offerts par le système de supervision 10 ; - une couche de communication indépendante du réseau 24 et une couche de communication dépendante du réseau 25 : ces couches permettent aux entités locales de supervision 6 hébergées sur des dispositifs mobiles respectifs de communiquer entre elles et servent de support aux connecteurs entre composants ; la couche de communication indépendante du réseau 24 fournit des mécanismes (files d'attentes, sémaphores, etc) qui peuvent être utilisés par l'entité de supervision et les connecteurs pour envoyer et recevoir des objets et la couche de communication dépendante du réseau 25 fournit notamment des mécanismes pour implémenter les communications de réseau pour l'entité de supervision et pour les connecteurs. L'entité de supervision locale 6 peut comprendre en outre les éléments 22 suivant utilisés pour la supervision des applications : - Un module de supervision 223 (encore appelé « superviseur >>) pour exécuter les commande de déploiement ou de reconfiguration en créant, supprimant, migrant des composants et/ou en créant, supprimant, dupliquant, redirigeant des connecteurs exécuter les commandes de création/suppression/migration/connexion/déconnexion de composants ; - un gestionnaire de contexte 222 pour contrôler le contexte des applications, notamment à partir de capteurs du dispositif 23 ; il reçoit notamment des informations sur l'état de l'application en cours d'exécution, en particulier des informations relatives aux composants, aux connecteurs liant les composants et aux dispositifs hôtes 5 ; - des conteneurs 224 de connecteurs 303 ; 068715 - un gestionnaire de classes de composant 226 pour gérer dynamiquement les classes chargées ; il crée en outre des chargeurs de classes 12 pour chaque fichier de code téléchargé pour un nouveau composant accueilli sur l'hôte. - les conteneurs 305 de composants 302 ; et - un gestionnaire de modules 227 qui peuvent être des modules d'extension (ou plugin) pour contrôler un ensemble modules 21. Le gestionnaire de modules 227 est adapté pour lancer ou arrêter des modules 21 de l'entité de supervision. Il peut utiliser un fichier de description qui indique les plugins qui sont automatiquement exécutés lorsque l'entité de supervision s'arrête. Des modules 21 peuvent être ajoutés ou supprimés en cours d'exécution. Les modules 21 peuvent en outre comprendre : - un module pour applications (encore appelée « plugins pour application ») 221 qui permet aux composants d'accéder à des ressources gérées par l'entité de supervision 6. Ces ressources peuvent comprendre des ressources classiques (par exemple, textes, images, etc.) ou encore des ressources spécifiques au matériel (telles que des capteurs 222, un système GPS (acronyme pour « Global Positioning System »), ou encore un système SMS (acronyme pour Short Messaging System », etc.)) ; cette unité permet notamment aux composants d'envoyer des commandes aux entités de supervision locales ou distantes et de recevoir des réponses. - La fonction de chargement de code 100 pour charger le code associé à un composant accueilli sur le dispositif hôte 5 ; elle interagit notamment avec le gestionnaire de classe 226. - L'unité de routage 15 pour le calcul de routes (encore appelée service de routage) ; et - un DNS local 224 (DNS est l'acronyme pour « Domain Name System » signifiant System de Nom de Domaine). L'enregistreur de services 2 peut fonctionner de manière similaire à l'application JAVA appelée Les entités de supervision locales 6 peuvent en outre exécuter des méthodes pouvant être surchargées, notamment : - La méthode d'initialisation appelée « init() », pour initialiser un composant 302. Les initialisations des propriétés d'un composant 302 peuvent être faites dans la méthode « mit » ou au début de la méthode « run BC » (avant la boucle). La méthode d'initialisation « mit » est exécutée lors du premier lancement du composant métier 302. Toutefois, elle n'est pas redémarrée après une migration. Les initialisations faites dans la méthode « mit » concernent par conséquent les propriétés qui seront sérialisées lors d'une migration. Ainsi, la création d'une interface, l'accès à des dispositifs locaux ou la mise en place d'écouteurs d'événements sur certains flux d'entrée peuvent être faites au début de la méthode « run BC » pour être prises en compte lors d'une migration. - La méthode de destruction appelée « destroy()» qui est exécutée lors de l'arrêt définitif du composant et également avant une migration. Les méthodes suivantes sont héritées de la classe des modèles de composants, appelée «BCModel», et peuvent être utilisables par chaque composant 302. Elles comprennent des méthodes relatives à l'état du composant 302 incluant : - une méthode d'arrêt de composant appelée « idle() » qui arrête le composant mais ne le supprime pas ; 068715 - une méthode qui indique si le composant 302 peut continuer à s'exécuter, appelée « isRunning() » et de type booléen. Dans le cas où le composant doit être arrêté, cette méthode peut lever l'exception de classe appelée « StopBCException ». - une méthode indiquant l'état de migration du composant 302, de type booléen. Cette méthode peut par exemple renvoyer la valeur « VRAI » si le composant 302 a été migré. Les méthodes « idle()» et «isRunning()» sont de préférence bloquantes : si elles sont appelées par un autre fil d'exécution (thread en langue anglo saxonne), elles ne s'exécutent pas et affichent une erreur. Les méthodes héritées de la classe des modèles de composants « BCModel » et utilisables par chaque composant 302 peuvent comprendre également des méthodes relatives à l'environnement du composant telles que: - Une méthode qui renvoie le nom du composant ; - Une méthode qui renvoie le nombre d'entrées du composant 302; - Une méthode qui renvoie le nombre d'entrées actuellement connectées du Composant 302; - Une méthode d'indication de connexion d'entrée pour indiquer si l'entrée désignée par le paramètre est actuellement connectée à un connecteur ; - Une méthode qui renvoie le nombre de sorties du composant 302 ; - Une méthode qui renvoie le nombre de sorties actuellement connectées du composant 302 ; - Une méthode d'indication de connexion de sortie pour indiquer si la sortie désignée par le paramètre est actuellement connectée à au moins un connecteur. Les méthodes héritées de la classe des modèles de composants « BCModel » et utilisables par chaque composant 302 peuvent comprendre aussi des Méthodes relatives aux entrées telles que : - Une méthode pour créer un filtre de données d'une classe spécifiée, sur une entrée du composant 302; - Une méthode pour supprimer le filtre de données sur une entrée du composant 302 qui reçoit en paramètre un numéro d'entrée; - Une méthode de lecture des données sur une entrée du composant; - Une méthode de lecture des données d'une classe sur une entrée du composant; 068715 - Une méthode de lecture des premières données disponibles sur les entrées du composant 302 ; - Une méthode qui indique la disponibilité de données sur une entrée du composant 302; - Une méthode pour ajouter un écouteur en entrée d'un composant 302; - Une méthode de suppression d'écouteurs. D'autres méthodes utilisables par les composants peuvent être relatives aux sorties des composants 302 et comprendre une méthode pour écrire sur une sortie du composant 302. D'autres méthodes pouvant être appelées par les composants peuvent être relatives aux événements (interfaces ou écouteurs d'entrée), comme une méthode d'attente d'un événement de composant ou une méthode d'envoi d'un événement au composant. Les composants 302 peuvent également appeler des méthodes relatives aux ressources contenues dans le fichier de code associé au composant (fichier jar). Les ressources peuvent être placées dans un sous-répertoire du répertoire contenant le composant. Le composant 302 peut y accéder en utilisant des méthodes appelées « getResourceAsByteArray » (récupération de la ressource sous forme binaire) ou « getResourceAsStream » (récupération d'un flux de lecture de la ressource). Selon une autre caractéristique de l'invention, chaque entité locale de supervision 6 peut maintenir des informations relatives à toutes les entités locales de supervision 6 avec lesquelles elle est entrée en communication. En particulier, ces informations peuvent être enregistrées dans le DNS local 224. Pour chaque autre entité locale de supervision 6 identifiée par le DNS 224, le DNS 224224 peut stocker les informations suivantes : - un identifiant unique associé à l'entité locale de supervision 6 ; - La liste des adresses connues de cette entité locale de supervision 6 sur chacun des réseaux auxquels elle accède ; - Le Décalage d'horloge avec cette entité locale de supervision 6 et l'erreur maximale de mesure de ce décalage. Lors de chaque réception de message (par exemple, message de recherche de classe) par l'entité locale de supervision locale 6 en provenance d'une entité locale de supervision 6 hébergée sur un autre dispositif, le DNS 224 enregistre l'entité de supervision 6 émettrice et son adresse. Lors d'échanges de messages de type PING ou de recherche de routes, à la réception de la réponse, le DNS 224 calcule le décalage d'horloges (ces messages contiennent l'heure d'émission extraite de 068715 l'horloge locale de l'entité de supervision 6 émettrice). Le temps d'échange de ces messages permet en outre de déterminer une borne maximale d'erreur de la mesure de ce décalage. Chaque route indirecte trouvée provoque l'ajout de l'entité de supervision 6 servant de relai et de celle à laquelle aboutit la route. Par ailleurs, à intervalles réguliers, les entités de supervision 6 peuvent échanger les contenus de leurs DNS 224. Les informations ainsi reçues peuvent être utilisées pour mettre à jour chaque DNS local, notamment pour ajouter des entités de supervision 6 qui n'y étaient pas enregistrées, ou pour compléter les listes d'adresses des entités de supervision 6. Les décalages d'horloges reçus permettent de calculer de nouvelles valeurs, par exemple : - Décalage entre hôte A et hôte B = décalage entre A et C + décalage entre C et B, et - Erreur sur le décalage entre hôte A et hôte B = Erreur sur le décalage entre A et C + Erreur sur le décalage entre C et B. Ces valeurs peuvent ainsi compléter le DNS local 224 ou remplacer les valeurs locales lorsque l'erreur calculée est inférieure à celle couramment connue localement. Les décalages d'horloges du DNS peuvent être utilisés pour la gestion des connexions, notamment pour dater les objets échangés en heure locale. En effet, les données envoyées sont automatiquement datées à leur création et cette date est ajustée par les connecteurs 303 à la réception. Lorsque le décalage d'horloge avec l'hôte émetteur n'est pas connu, le connecteur 303 date la donnée par l'heure locale de sa réception. Pour tenir compte de la mobilité des dispositifs 5, les enregistrements du DNS 224 ont de préférence une durée de vie limitée et sont supprimés à leur terme. Une valeur maximale peut être affectée à cette durée de vie lors de chaque communication réussie, puis réajustée à partir des durées de vie des DNS reçus des autres entités de supervision 6 (la valeur maximale peut alors être conservée). Ainsi une entité de supervision 6 qui disparaît ou perd toute connexion pourra être supprimée de tous les DNS. De même, une entité de supervision 6 qui ne communique avec aucune autre entité de supervision (par exemple, aucun message n'a été échangé avec d'autres entités de supervision) pourra être supprimée de tous les DNS, et réapparaître dans les DNS dès que l'entité de supervision correspondante communiquera à nouveau avec d'autres entités de supervision. Les inventeurs ont effectué un certain nombre de mesures relatives au système de supervision 10, en particulier sur la complexité, le temps d'exécution des commandes, les temps de transfert d'informations dans les connecteurs et le temps de déploiement d'une application. 068715 La plupart des exécutions de commandes supportées par le système de supervision induisent des temps d'attente faibles (réponse par réseau d'une autre entité de supervision, recherche de route ...). Une reconfiguration est, généralement constituée de plusieurs commandes (ajout/suppression de composants et/ou de connecteurs par exemple). Ces temps d'attente sont optimisés par le système de supervision 10 en permettant l'exécution parallèle de ces commandes. Aussi, le temps d'exécution d'une reconfiguration est inférieur à la somme des temps d'exécution de chacune des commandes prises indépendamment. D'après les mesures effectuées, les temps de reconfiguration sont suffisamment faibles pour permettre au système de supervision d'adapter rapidement une application à un changement de contexte. Le passage à l'échelle (nombre plus important de dispositifs impliqués dans la reconfiguration) ne modifie pas la situation significativement puisque chaque entité de supervision sur un dispositif peut exécuter ses commandes en parallèle des autres. Le système de supervision 10 selon l'invention permet ainsi d'exécuter des applications (i.e. des composants formant tout ou partie d'une application) sur différents dispositifs 5 pouvant être mobiles et d'agir à chaud sur l'architecture de l'application lorsque nécessaire. L'invention n'est pas limitée aux modes de réalisation décrits ci-avant à titre d'exemple non limitatif. Elle englobe toutes les variantes de réalisation qui pourront être envisagées par l'homme du métier. En particulier, l'invention n'est pas limitée à l'architecture des entités de supervision représentée sur la figure 11. Elle n'est pas non plus limitée à la structure particulière de dépôt de code de la figure 6, ou à une structure particulière de fichier de code. Par exemple, les fichiers de code peuvent être cryptés pour plus de sécurité. Par ailleurs, les entités de supervision peuvent être paramétrées de différentes manières, par l'utilisateur. Ainsi, les entités de supervision peuvent utiliser une liste identifiant des composants refusés par l'utilisateur. Une telle liste peut être paramétrée par l'utilisateur à travers une interface de configuration de l'entité de supervision, pour désigner des composants qui ne doivent pas être installés sur le dispositif (par exemple un composant devant utiliser un système de localisation GPS ne sera pas installé par l'entité de supervision si l'utilisateur a spécifié qu'il refusait d'être localisé). Les entités de supervision peuvent en outre être configurées pour gérer l'achat de composants. L'homme du métier comprendra que les entités de supervision 6 selon les formes de réalisation de l'invention peuvent être mises en oeuvre de diverses façons par matériel (« hardware »), logiciel, ou une combinaison de matériel et de logiciels. En particulier, les éléments de chaque entité de supervision peuvent être combinés ou séparés en sous-éléments pour mettre en oeuvre l'invention. En outre, ils peuvent être mis en oeuvre sous la forme de programmes d'ordinateur exécutés par un processeur. Un programme d'ordinateur est un ensemble d'instructions qui peuvent être utilisées, directement ou indirectement, par un ordinateur. 068715 Un programme d'ordinateur peut être écrit dans n'importe quel langage de programmation, y compris les langages compilés ou interprétés, et il peut être déployé sous n'importe quelle forme dans l'environnement informatique choisi.5 REVENDICATIONS1. Système de supervision d'applications s'exécutant sur un ensemble de dispositifs électroniques (5) reliés entre eux par un ou plusieurs réseaux, caractérisé en ce que chaque dispositif (5) comprend une entité de supervision locale (6), les entités de supervision coopérant entre elles pour contrôler les applications s'exécutant sur les dispositifs électroniques (5), chaque application comprenant un ensemble de composants applicatifs, et en ce que l'entité de supervision d'un dispositif donné est apte à exécuter les étapes suivantes, en réponse à une commande d'accueil d'un composant applicatif sur ledit dispositif, dit dispositif d'accueil (5), ledit composant ayant un état de départ donné : - communiquer avec un ensemble d'entités de supervision pour rechercher un fichier de code comprenant le code exécutable associé au composant applicatif, - charger le fichier de code exécutable associé au composant sur ledit dispositif d'accueil, en réponse à la disponibilité du fichier de code sur le dispositif d'accueil, - démarrer le composant dans ledit état de départ à partir du code chargé, en l'encapsulant dans un conteneur (305) contrôlable par l'entité de supervision. 2. Système de supervision selon la revendication 1, caractérisé en ce que ladite commande d'accueil est une commande de création du composant sur le dispositif, et en ce que ledit état de départ est un état initial. 3. Système de supervision selon la revendication 1, caractérisé en ce que ladite commande d'accueil est une commande de migration du composant sur le dispositif d'accueil depuis un dispositif source, et en ce que ledit état de départ est l'état du composant dans ledit dispositif source. 4.Système de supervision selon l'une des revendications précédentes, caractérisé en ce que la recherche de fichier de code comprend l'envoi d'un message de demande de code par l'entité de supervision du dispositif d'accueil aux entités de supervision (6) dudit ensemble d'entités de supervision, ledit message comprenant des informations relatives au composant et au dispositif d'accueil. 5. Système de supervision selon la revendication 4, caractérisé en ce que ledit message de demande de code est relayé par chaque entité de supervision réceptrice le message vers un autre ensemble d'entités de supervision, si le dispositif hébergeant l'entité de supervision réceptrice ne détient pas le fichier de code associé au composant. 6. Système de supervision selon la revendication 5, caractérisé en ce que l'étape consistant à relayer le message de demande de code vers un autre ensemble d'entités de supervision068715 comprend la désignation de l'entité de supervision réceptrice comme relai pour l'envoi d'une réponse comprenant le fichier de code depuis une autre entité de supervision vers le dispositif d'accueil dans le message relayé. 7. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que chaque entité de supervision (6) réceptrice du message de demande de code est apte à rechercher si le dispositif hébergeant l'entité de supervision détient un fichier de code associé au composant à partir du nom de la classe du composant. 8. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que chaque entité de supervision (6) réceptrice du message de demande de code est apte à déterminer si le dispositif hébergeant l'entité de supervision réceptrice détient un fichier de code associé au composant en effectuant une recherche dans un dépôt de code de composants, à partir des informations relatives au composant et au dispositif d'accueil, si le dispositif hébergeant l'entité de supervision réceptrice gère un dépôt de code de composants (60) stockant des fichiers de code à des composants. 9. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que l'entité de supervision du dispositif d'accueil (5) est apte à envoyer ledit message de demande de code par diffusion du message, si le dispositif a une capacité d'envoi par diffusion, ledit ensemble d'entités de supervision comprenant les entités de supervision (6) des dispositifs voisins recevant ledit message envoyé par diffusion. 10. Système de supervision selon l'une des revendications 1 à 8, caractérisé en ce que l'entité de supervision du dispositif d'accueil (5) maintient des informations relatives aux entités de supervision avec lesquelles elle communique dans une structure de données et en ce que l'entité de supervision du dispositif d'accueil (5) est apte à envoyer ledit message de demande de code à des entités de supervision déterminées à partir de ladite structure de données (224). 11. Système de supervision selon l'une des revendications 1 à 8, caractérisé en ce que l'entité de supervision du dispositif d'accueil (5) est apte à envoyer ledit message de demande de code à un proxy prédéfini (14) apte à relayer ledit message par diffusion, ledit ensemble d'entités de supervision comprenant entités de supervision (6) des dispositifs voisins recevant ledit message envoyé par diffusion par le proxy (14). 12. Système de supervision selon la revendication 11, caractérisé en ce que le proxy (14) est une entité de supervision sur un dispositif ayant une adresse publique sur Internet. 13. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que chaque entité de supervision comprend un émetteur (102) configuré pour transmettre les demandes de code associé à un composant vers un client d'envoi par diffusion (103), ledit client068715 d'envoi par diffusion (103) étant configuré pour envoyer les messages de demandes de code associé à un composant à l'ensemble d'entités de supervision. 14. Système de supervision selon les revendications 12 et 13, caractérisé en ce que l'émetteur (102) est configuré pour transmettre les demandes de code associées à un composant vers un client (105) lié au proxy (14). 15. Système de supervision selon la revendication 14, caractérisé en ce que la connexion avec le proxy (14) est maintenue ouverte pour permettre la réception des réponses relayées par le proxy (14) en réponse à la demande de code. 16. Système de supervision selon la revendication 15, caractérisé en ce que la connexion est maintenue ouverte en utilisant l'envoi de messages de type PING. 17. Système de supervision, selon l'une des revendications précédentes, caractérisé en ce que chaque entité de supervision comprend un émetteur de réponse (104) pour envoyer la réponse de l'entité de supervision (6) à un message de demande de code vers l'entité de supervision du dispositif qui lui a relayé le message de demande de code provenant du dispositif d'accueil, l'émetteur (104) étant configuré pour transmettre la réponse à ladite entité de supervision via au moins un client d'envoi spécifique ( 107) selon le réseau disponible. 18. Système de supervision selon l'une des revendications 3 à 17, caractérisé en ce que chaque composant (302) est associé à une classe de composant donnée, et en ce que les informations relatives au composant comprennent le nom de la classe du composant. 19. Système de supervision selon l'une des revendications 3 à 17, caractérisé en ce que les informations relatives au composant comprennent le type de dispositif. 20. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que l'entité de supervision locale (6) du dispositif d'accueil est apte à charger le fichier de code en utilisant un chargeur de code associé au fichier de code. 21. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que le chargeur de code (12) associé au fichier de code sur le dispositif est crée lors de la première création du composant sur le dispositif d'accueil. 22. Système de supervision selon la revendication 21, caractérisé en ce que le lien entre le composant (302) et son chargeur de code est mémorisé dans le conteneur (305) du composant (302). 23. Procédé de supervision d'applications s'exécutant sur un ensemble de dispositifs électroniques (5) reliés entre eux par un ou plusieurs réseaux, chaque application comprenant un ensemble de068715 composants applicatifs, caractérisé en ce que ledit procédé comprend les étapes suivantes, en réponse à une commande d'accueil d'un composant applicatif sur un dispositif, dit dispositif d'accueil (5), ledit composant ayant un état de départ donné: - rechercher un fichier de code comprenant le code exécutable associé au composant applicatif sur un ensemble de dispositifs ; - charger le fichier de code associé au composant sur ledit dispositif d'accueil, en réponse à la disponibilité du fichier de code sur le dispositif d'accueil, - démarrer le composant dans ledit état de départ à partir du code chargé, en l'encapsulant dans un conteneur (305) contrôlable localement.10