FR 2824929 A1 20021122 FR 0106606 A 20010518 terminal. - 1 DEPLOIEMENT D'APPLICATION DEPUIS UNE CARTE A PUCE La présente invention concerne le déploiement d'une application depuis un premier moyen de traitement de données, tel qu'une carte à puce, dite également carte à microcontrôleur ou carte à circuit intégré, sur un deuxième moyen de traitement de données, tel qu'un terminal d'accueil de la carte à puce, dans un contexte étendu et hétérogène. Dans ce contexte, l' app lication est compos ée de compos ants logiciels dispers és dans un réscau de télécommunication et doit pouvoir être exécutée à partir de terminaux hétérogènes ayant des caractéristiques matérielles et logicielles différentes, tels qu'un terminal radiotéléphone mobile, un assistant électronique personnel et un ordinateur personnel. Les terminaux hétérogènes diffèrent par exemple par leurs systèmes d'exploitation et leurs caractéristiques de codage de données et de communication. Actuellement, des utilisateurs accèdent à diverses applications à travers des réscaux de télécommunication, notamment le réseau Internet, quasiment à l'aide de n'importe quel terminal parmi divers terminaux hétérogènes, depuis leurs bureaux, leurs domiciles, ou des bornes d'accès publiques. Malheureusement, les applications ne sont pas capables de se configurer automatiquement en fonction de caractéristiques personnelles à l'utilisateur et il est nécessaire de reconfigurer le terminal de l'utilisateur en fonction de l'application choisie. Pour exécuter correctement les applications, le terminal doit disposer de données de service relatives à l'application à exécuter et aux serveurs distants offrant ces applications, et de données individuelles confdentielles, propres à chaque utilisateur et personnalisant l'accès à une ou plusieurs applications. Lorsque les utilisateurs sont sédentaires ces informations sont généralement statiques sur leurs terminaux. En revanche, lorsque les utilisateurs sont itinérants, la carte à puce offre un support autonome, sûr et portable pour fournir ces données aux terminaux que l'utilisateur est susceptible d'avoir besoin. Par ailleurs, les fournisseurs d'applications ont intérêt à ce que leurs applications soient utilisables depuis un très grand nombre de types de terminaux. Une application doit donc être capable de s'adapter au terminal dans lequel el le est exécutée. Par exemp le. une application donnée présente une interface graphique complexe à base de fenêtres - 2 dans un ordinateur personnel, et de simples menus textuels dans un radiotéléphone mobile, ou établit une communication audio ou vidéo en fonction du débit offert par le réseau et le terminal. L'adaptabilité des applications distribuées à leur contexte s d'exécution et aux besoi-ns de l'utilisateur devient ainsi une nécessité (cf. article intitulé "Adaptabilité des applications pour des utilisateurs mobiles", Michel RIVEILL et al., OCM'2000, Objets Composants Modèles, 8 Mai 2000). I1 est donc nécessaire de déployer des applications de service en fonction du type du terminal et d'une personnalisation de configuration pour l'utilisateur. Cette souplesse requise est obtenue par une architecture modulaire de chaque application. Chaque application est conçue comme un graphe de composants interconnectés par des connexions. Le déploiement de l'application sur un terminal crée dans celui-ci des instances de ces composants en fonction du contexte d'exécution et de caractéristiques personnelles. Comme montré aux figures 1 et 2, il est connu de définir une application dans une carte à puce CP, ou tout autre objet électronique portable présentant une capacité de mémoire relativement faible, par un descripteur DAP d'une application AP identifiant des éléments essentiels de l'application, tels que les composants logiciels CA de l'application et des connexions CX entre ces composants deux à deux. En général, une application comprend au moins trois composants CA1, CA2 et CA3 et au moins deux connexions CX1 et CX2 interconnectant deux à deux les composants CA1 à CA3. Un composant CA est une unité de traitement logiciel encapsulant des fonctionnalités, assez petite pour que l' on puisse la créer et la maintenir, et ass ez grande p our que l ' on puiss e l' installer et en assurer l e support. Le composant est doté d'interfaces de communication pour qu'il puisse coopérer avec d'autres composants et ainsi présenter son comportement à ces autres composants. En pratique, un composant logiciel peut être implanté sur n'importe quel site d'un réseau de transmission RT. Une connexion définit les relations entre les interfaces de communication de deux composants. Des paramètres des connexions de l'application sont également adaptés au contexte de la plate-forme d'exécution. Au niveau de la carte à puce CP, un descripteur d'application DAP ne contient pas l'élément lui-même (composant logiciel CA ou connexion CX), mais un descripteur DCA, DCX de l'élément CA, CX contenant des propriétés et des paramètres de l'élément le définissant et permettant de le retrouver parmi une multitude d'éléments. Les propriétés du descripteur d'un élément sont fxées une fois pour toutes par le fournisseur de l'application qui spécialise l'élément, compos ant ou connexion, afin de s atis faire les besoins de l' app l ication et de l'utilisateur selon des caractéristiques d'abonnement par exemple. Elles indiquent les caractéristiques de la plate-forme sur laquelle l'élément peut être exécuté, ainsi que les besoins systèmes nécessaires à son exécution. Une propriété peut consister en un type ou une adresse d'élément, qui est associé à chaque élément et utilisé pour la recherche du code ou de l'implantation de l'élément, ou est intimement liée à l'application ou à un type d'application. Par exemple, la propriété "numéro de compte" est associée à un composant gestionnaire de compte bancaire. Ces propriétés sont, selon la technique antérieure, figées lors de la souscription au service correspondant à l'application par l'utilisateur de la carte à puce, et ne sont accessibles qu'en lecture seule. D'aukes propriétés, dites paramètres, sont de préférence personnalisées par l'utilisateur et peuvent être modifiées à tout instant. Par exemple, un paramètre définit la monnaie d'affichage d'un montant, ou bien une panoplie de couleurs pour l'affichage de pages sur un écran, ou bien encore la valeur du débit ou d'une caractéristique de transmission dans une connexion. Chaque descripteur d'application est représenté sous la forme d'un graphe d'objet en langage orienté objet, par exemple le langage JAVA (marque déposée) ou le langage XML (Extensible Markup Langage). Les descripteurs d'application DAP1, DAP2, DAP3 dans une carte à puce multi-applications sont associés au pilote de déploiement PI (en anglais bootstrap) qui constitue au sein de la carte à puce CP une application permettant de sélectionner une application, la configurer et la déployer en fonction de son descripteur, après introduction de la carte CP dans le terminal d'accueil TE. En groupant les descripteurs d'application et le pilote de déploiement dans la carte, la confidentialité des descripteurs est assurée, si bien que la lecture des descripteurs par le pilote de déploiement ne nécessite pas d'authentification. En revanche, le pilote de déploiement authentifie chaque client qui l'interroge avant de - 4 mettre à sa disposition l'ensemble des descripteurs d'application mémorisés dans la carte. Le pilote PI peut ainsi traiter un ou plusieurs déploiements d' application. Comme déjà dit, un élément d'application, composant ou connexion, est configuré en fonction du contexte de l' application, c'est-à- dire des propriétés matériel l es et l ogicielles de la plate- forme o sera exécutée l'application, et de paramèkes choisis par l'utilisateur et personnalisant l'application. Toutes ces informations sont regroupées dans le descripteur de l'élément d' application afin que le pilote de déploiement PI filtre les informations contenues dans le descripteur de l ' él ément en foncti on du contexte de l'applicati on et des paramètres de personnalisation de l'utilisateur. Le pilote de déploiement PI localisé dans la carte à puce CP transmet des commandes de déploiement à un portail de déploiement PO qui est un élément applicatif implémenté dans le terminal d'accueil TE. Le portail a pour principal rôle de recevoir les commandes de déploiement et de les ré-émettre vers la plate-forme d'exécution afin d'installer l' application sélectionnée. Ainsi le portail de déploiement a principal ement une foncti on d'information de la carte à puce sur l'environnement dans lequel l' installation et l' exécution de l'app licati on sélectionnée doivent êke faites, et une fonction de communication avec la carte afin de recevoir diverses commandes de déploiement de l'application sélectionnée. Selon la technique antérieure, le déploiement d'une application est synchrone, c'est-à-dire les commandes élaborées par le pilote de déploiement PI sont transmises séquentiellement, les unes après les autres, respectivement pour l'installation des éléments de l'application, pui s p our le paramètrage des éléments de l' app l icati on, chaque commande devant être acquittée par le portail de déploiement PO sur le terminal avant que la commande suivante soit émise par le pilote PI. Finalement, lorsque tous les composants et les connexions de l'application sélectionnée AP sont installés et paramétrés, l'application ainsi déployée se trouve adaptée au terminal TE et peut alors être exécutée. Le démarrage de l'application est effectué par une commande d' exécution (RUN) qui contient le nom du comp os ant de l 'app l icati on sélectionnée déterminant le point d' enhée de l'applicati on, généralement un composant d'interface d'utilisateur. I1 s'avère qu'un tel déploiement synchrone présente l'inconvénient de rendre l'installation d'une application longue, à cause de la succession de commandes qui doivent être acquittées selon un ordonnancement prédéterminé. Cette installation est d'autant plus longue que le nombre de composants à installerest élevé et que l'installation de ces derniers nécessite de faire appel aux ressources du réseau de transmission RT. Ce temps pendant lequel l'utilisateur attend peut étre un facteur de rejet d'une application lorsqu'il est trop important. Pour tenter de remédier à cet inconvénient, on a proposé d'effectuer le déploiement d'une application de manière asynchrone, c'est à-dire que le pilote PI demande l' install ation en p arallèle de tous les composants de l'application, indépendants d'autres composants, sans attendre un acquittement du portail PO, puis commande en parallèle, l'installation d'éléments dépendants en réponse respectivement à l' acquittement de l' installation des él éments dont ils dépendent. Le paramétrage des éléments peut également être effectué de manière asynchrone. Dans le cas d'un système mono processeur, l'exécution en parallèle de plusieurs traitements signif e simplement que plusieurs traitements peuvent étre en cours d'exécution simultanément, les ressources du processeur étant, bien entendu, attribuées à un seul traitement à un instant donné. Cette solution permet d'optimiser l'utilisation de la puissance de traitement et le débit de transmission, offerts par le terminal et le réseau de transmission. Toutefois, en particulier lorsque l'application à installer comprend de nombreux composants et que le terminal de déploiement présente une faible capacité de kaitement, le déploiement asynchrone ne permet pas de réduire de manière signifcative le temps d'attente de l'utilisateur, avant que l'application soit lancée. Dans les deux cas précédents, tous les composants de l'application sont installés, même ceux que l'utilisateur utilise rarement ou jamais, ce qui augmente inutilement le temps d'installation de l'application et surcharge inutilement les ressources du terminal. La présente invention a pour objectif de remédier aux inconvénients précités du déploiement des applications à éléments répartis selon la technique antérieure, et à réduire encore le délai d'installation. - 6 Cet objectif est atteint par la prévision d'un procédé pour déployer une application composée de plusieurs éléments distants répartis, depuis un premier moyen de traitement de donnces contenant des descripteurs desdits éléments, sur un. second moyen de traitement de données relié à des moyens d'implantation des éléments, pour exécuter l'application une fois déployée, caractérisé en ce qu'il comporte au moins les étapes consistant à: - sélectionner au moins un élément de l' app l icati on en tant qu' élément prioritaire, - déployer sur le second moyen de traitement le ou les éléments prioritaires, et - exécuter l'application par le second moyen de traitement dès que le ou les éléments prioritaires ont été déployés. Grâce à ces dispositions, le temps d'attente de l'utilisateur se trouve considérablement diminué, puisque le déploiement effectué avant le lancement de l' application concerne un nombre réduit de composants. En outre, si seuls les composants utilisés sont installés, la carte ne présente pas au terminal les descripteurs des éléments non installés, et les ressources du terminal ne sont pas surchargées par des éléments inutiles. Avantageus ement, l'étap e de s él ection d' au moins un élément de l' application en tant qu'élément prioritaire consiste à examiner au moins un indicateur de priorité contenu dans le descripteur de la dite application. Selon une particularité de l'invention, si au cours de l'exécution de l'application par le second moyen de traitement de données, un élément non déployé est appelé, le procédé comprend en outre une étape de déploiement de l'élément appelé, puis une étape de poursuite de l'exécution de l'application. Selon une autre particularité de l'invention, les éléments de l' appl icati on non sélecti onnés en tant qu'éléments prioritaires s ont déployés sur le second moyen de traitement de données en parallèle de l'exécution de l'application. Selon encore une autre particularité de l'invention, le procédé comprend en outre une étape de transmission du contexte d'exécution de l' application depuis le second moyen de traitement de données vers le premier moyen de traitement de données, le déploiement en parallèle de l'exécution de l'application, des éléments de l'application non sélectionnés en tant qu'éléments prioritaires, étant réalisé en fonction du contexte d'exécution transmis. De préLérence, les éléments de l' application non s électionnés en tant qu'éléments prioritaires, sont déployés sur le second moyen de traitement en parallèle de l'exécution de l'application, d'une manière synchrone. Alternativement, les éléments de l'application non sélectionnés en tant qu'éléments prioritaires, sont déployés sur le second moyen de traitement en parallèle de l'exécution de l'application, d'une manière asynchrone. Selon encore une autre particularité de l'invention, le procédé comprend en outre une étape de sélection d'au moins un élément de l' application en tant qu'élément non prioritaire, les él éments non prioritaires de l'application étant déployés sur le second moyen de kaitement uniquement s'ils sont appelés au cours de l'exécution de l'application. Avantageusement, en fin d'exécution de l'application, le procédé selon l'invention comprend en outre une étape de mise à jour des indicateurs de priorité respectifs des éléments de l'application en fonction des éléments qui ont été utilisés durant l'exécution de l'application. L'invention concerne également un objet électronique comprenant un moyen de description pour décrire une application composée de plusieurs éléments distants répartis, et un moyen de traitement pour déployer l'application en vue de son exécution à l' extérieur de l' obj et électronique, en fonction du moyen de description de l'application, caractérisé en ce que le moyen de description comporte au moins un indicateur de priorité pour sélectionner au moins un élement en tant qu'élément prioritaire de l' application, et en ce que le moyen pour déployer l'application ne déploie que les éléments prioritaires avant d' autori s er l' exécution de l' appl icati on. Cet objet est par exemple de type carte à microcontrôleur. L'invention concerne aussi un système de déploiement d'application comprenant un objet électronique portable du type carte à microcontrôleur, un terminal connecté à un réseau de transmission de données et comportant un moyen pour communiquer avec l'objet - 8 électronique portable, I'objet électronique portable comprenant un moyen de description pour décrire une application composée de plusieurs éléments distants répartis accessibles au terminal par le réseau de transmission de données, et un moyen de traitement pour déployer l'application sur le terminal en vue de son exécution par le terminal, en foncti on du moyen de description de l' application, caractérisé en ce que le moyen de description comporte au moins un indicateur de priorité pour sélectionner au moins un élement en tant qu'élément prioritaire de l'application, et en ce que le moyen pour déployer l'application ne déploie que les éléments prioritaires avant de déclencher l'exécution de l'application déployée sur le terminal. D'autres caractéristiques et avantages de la présente invention appara^tront plus clairement à la lecture de la description suivante de plusieurs réalisations prétérées de l'invention en référence aux dessins annexés correspondants dans lesquels: - la figure 1 représente schématiquement une application modulaire comprenant six composants; - la figure 2 est un bloc-diagramme schématique des moyens mis en oeuvre dans un réseau de télécommunication pour le déploiement d'une application constituée d'éléments distants répartis; - la figure 3 est un algorithme de déploiement et d'exécution d'une application, selon l'invention; et les figures 4 et sont des algorithmes montrant plus en détail certaines étapes de l'algorithme représenté sur la figure 3. La figure 1 représente une application de services bancaires accessibles par un réseau de transmission de données tel quel le réseau Internet. Cette application comprend un composant principal CA1 dans lequel sont rassemblées toutes les fonctions d'interface UI avec l'utilisateur, ce composant permet d'accéder à un service générique de gestion de comptes bancaires intégré dans un composant CA2 et à un service générique de demande de crédit CA3. A cet effet, le composant CA1 est relié aux composants CA2 et CA3 par les connexions respectives CX1 et CX2. Dans l'application particulière mise à la disposition de l'utilisateur, représentée sur la figure 1, le composant CA2 de gestion de comptes bancaires est relié par les connexions CX3 et CX4 respectivement aux serveurs de deux organismes bancaires B1 et B2 intégrés dans les composants CA4 et CA5, ce qui signife que l'utilisateur peut accéder à des comptes bancaires gérés uniquement par les organismes bancaires B1 et B2. D'une manière analogue, le composant CA3 est relié par les connexions CX5 et CX6 respectivement aux serveurs de deux organismes bancaires B 1 et B3. Tous les éléments d'une telle application ne doivent pas nécessairement êke installés sur le terminal d' exécution de l ' appli cati on. Ainsi dans l'exemple présenté, les services offerts par les serveurs d'organismes bancaires, en-cours d'exécution sur des sites distants, sont interrogés à la demande par le terminal d'exécution de l'application. A cet effet, le lien entre les composants CA2 et CA3, d'une part et les composants CA4 à CA6 d'autre part est réalisé par les connecteurs CX3 à CX6 qui utilisent le réseau en implémentant un protocole de communication adéquat. Une telle application peut étre décrite par un descripteur d'application ayant la forme suivante, exprimée dans le langage XML: 25... .. 10 5... 35... - 11 .. s Cette syntase représente à l'aide de balises de début et de fin de champ " " et " " une structure hiérarchique d'éléments imbriqués les uns dans les autres. Elle donne en particulier la liste des descripteurs d'éléments (composants logiciels et connexions) faisant partie de l'application, chaque descripteur d'élément comprenant notamment une liste de propriétés. Comrne décrit ci-avant, un tel descripteur d'application est stocké dans un premier moyen de traitement tel qu'une carte à puce CP, laquelle peut stocker plusieurs descripteurs d'application DAP1, DAP2, DAP3, s'il s'agit d'une carte multi-applications. Une telle carte est destinée à être lue par un lecteur de carte couplé à un second moyen de traitement tel qu'un terminal TE dans lequel on souhaite déployer une application. Le déploiement d'une application à partir d'une telle carte est géré par le pilote de déploiement PI intégré dans la carte à puce CP, qui lorsque la carte est lue par le lecteur d'un terminal TE, communique avec un logiciel appelé portail de déploiement PO prévu sur le terrninal. Le déploiement est donc réalisé par le pilote PI de déploiement à partir du descripteur DAP de l'application sélectionnée, en établissant un dialogue avec le portail de déploiement PO dans le terminal d'accuoil TE. Le portail peut contenir un moteur de recherche d'éléments, ou être en liaison avec un ou plusieurs moteurs de recherche d'éléments MR, comme montré à la figure 2. Chaque moteur de recherche MR a accès à des bibliothèques d'éléments d'application BI1, BI2, BI3, à travers le réseau de transmission RT. Chaque élément dans une bibliothèque est mémorisé avec son descripteur et géré par le concepteur de l'élément. Le réseau de transmission RT peut être un réscau public ou privé, de type téléphonique câblé ou cellulaire, ou encore de type réseau d'ordinateurs tel que le réseau Internet. Tel que représenté sur les figures 3 et 4, le déploiement proprement dit d'une application sélectionnée, est précédé d'une phase d'initialisation 1 au cours de laquelle l'utilisateur introduit la carte à puce CP dans la fente de lecteur du terminal d'accueil TE. Après l'introduction de la carte à puce, celle-ci dialogue 11 avec le terminal d'accueil pour - 12 authentifier 12 l'utilisateur, conna^tre 13 le contexte de la plate-forme d' exécuti on de l' application constituée es sentiellement p ar le terminal TE, et l'application sélectionnée 14. L'authentification cons iste par exemp le à véri fier l' i dentité de l'utilisateur au moyen d'un code confidentiel PIN saisi par le terminal. Le contexte extérieur à l'environnement matériel de la carte à puce est défini par des propriétés de la plate- forme d' exécution qui s ont transmises par le terminal TE à la carte à puce CP. Les propriétés du contexte d'exécution fournies par le terminal sont par exemple le type du terminal d'accueil utilisé TE, le nom du terminal, un certificat ou clé d' identification du terminal, et la localisation géographique du terminal dans le réseau de télécommunication. Ces propriétés permettent au pilote de déploiement PI de limiter la quantité de données qu'il transmet au portail de déploiement PO et ainsi de minimiser la durée du déploiement. Lors d'un déploiement ultérieur, ces rétérences aux propriétés contextuelles sont remplacées par les valeurs fournies par un autre terminal d'accueil TE. L'utilisateur sélectionne une application AP, classiquement par exemple dans un menu de présentation de diverses applications dont les déploiements peuvent étre commandés par la carte à puce CP. Après la sélection de l'application AP, le terminal TE, selon le contexte, et de prétérence l'utilisateur paramèkent 15 l'application, c'est-à-dire paramètrent certains des ou éventuellement tous les descripteurs DCA et DCX des composants et des connexions de l'application sélectionnée qui sont susceptibles d'être paramétrés. Le paramétrage par l'utilisateur est cl as s i que à l ' aide de menus arborescents demandant des val eurs de paramètre. A la suite de ces étapes d'initialisation 1, le déploiement de l'application sélectionnée AP est exécuté en fonction des descripteurs de composant CAi et des descripteurs de connexion CXi dans le descripteur paramétré DAP de l'application sélectionnée AP. Selon l'invention, seuls certains éléments de l'application sont définis comme étant prioritaires et doivent être chargés avant le démarrage de l'application, les autres éléments pouvant être déployés après le démarrage de l'application. Dans l'exemple de la figure 1, ces éléments sont constitués par le composant d'interface utilisateur CA1. Dans le descripteur d'application exprimé en langage XML, présenté ci- avant, la définition de la priorité de déploiement d'un élément est définie - 13 sous la forme d'une propriété associée à l'élément, appelée "deploymentUrgency" et ayant une valeur située entre O et 100. Par convention, on peut choisir que la valeur 100 est attribuée aux éléments prioritaires, c'est-à-dire devant étre déployés avant le démarrage de l'application. Les éléments définis comme prioritaires sont donc sélectionnés 2 comme étant des éléments à déployer, puis déployés 3. Après le dép loiement des éléments prioritaires, l' application est lancée 4 et exécutée 5. Dans l'exemple de la figure 1, seul le composant CA1 qui gère le dialogue avec l'utilisateur est déployé et activé. I1 en résulte qu'après le déploiement d'un unique composant, l'utilisateur peut percevoir sur le terminal TE que l'application est activée et lui propose de choisir entre un accès aux gestionnaires de comptes bancaires et un accès à des offres de crédit. Le déploiement des éléments prioritaires peut se dérouler de manière synchrone ou asynchrone. Toutefois, en général une application possède un unique point d'entrée contenu dans un seul composant. Par conséquent, si l'on souhaite que l'application soit activée le plus rapidement possible, seul le composant contenant le point d'entrée de l'application doit étre configuré comme prioritaire pour étre déployé seul avant le démarrage de l'application. Selon un premier mode de réalisation de l'invention, les déploiements des éléments d'application non prioritaires ne sont effectués que s'ils sont demandés par l'utilisateur. 2s Selon un second mode de réalisation de l' invention alternatif, on définit une catégorie d'éléments de priorité moyenne qui sont déployés en tâche de fond dès que l' application est démarrée et une catégorie d'éléments non prioritaires ou de priorité basse qui ne sont déployés que s'ils sont requis par l'exécution de l'application en cours. Dans le descripteur d'application donné ci-avant, on a choisi comme convention qu'un niveau de priorité égal à 100 est attribué aux éléments prioritaires, un niveau de priorité supérieur à 10 et inférieur à 100 est attribué aux éléments de priorité moyenne, et un niveau de priorité inférieur à 10 est attribué aux éléments de priorité basse, c'est-à-dire aux éléments qui sont rarement exécutés. Avantageusement, chaque fois qu'un élément d'une application est appelé au cours de l'exécution de l'application, un message est transmis à la carte à puce, pour l'en avertir. De son côté la carte à puce, à la - 14 réception d'un tel message, met à j our le champ valeur du niveau de priorité dans le descripteur de l'élément concerné dans le descripteur d'application. De cette manière, l'ordre dans lequel les éléments d'une application sont déployés peut être adapté aux besoins et habitudes de chaque utilisateur concernant l'exécution d'une application. Lorsque l'utilisateur s électionne une option de l' appl icati on en cours d'exécution, par exemple dans un menu, soit le composant réalisant la fonction choisie est déjà déployé et dans ce cas, il peut être exécuté immédiatement, soit il ne l'est pas. Dans ce dernier cas, l'environnement d'exécution de l'application du terminal TE détecte que le composant n' est pas dép loyé et fait une demande de dép loiement du comp os ant auprès de la carte à puce CP (étape 6) en lui fournissant par exemple le nom de l'élément à déployer. Cette demande déclenche le déploiement de l'élément (étape 7). Ici encore, le déploiement d'élément peut être synchrone ou asynchrone, c'est-à-dire que le pilote de déploiement PI attend ou non la fin du déploiement avant de retourner à l'étape 6 pour lancer un éventuel autre déploiement d'élément si d'autres éléments sont requls. S'il existe des éléments de priorité moyenne à déployer, ceux-ci sont déployés en tâche de fond, également d'une manière synchrone ou asynchrone (étape 9). On peut prévoir que ce déploiement d'éléments de priorité moyenne soit effectué uniquement si les performances ou les capacités du terminal sont suffisantes (étape 8), ou que ces éléments soient déployés par ordre de priorité jusqu'à ce que les ressources disponibles (par exemple en terme de capacité mémoire) du terminal atteignent un seuil minimum prédéfni, ou encore, dans le cas d'un déploiement asynchrone, que le nombre de déploiement déclenchés en parallèle soit limité en fonction des ressources disponibles du terminal, de manière à ne pas ralentir d'une manière notable pour l'utilisateur l'exécution de l'application en cours. La figure 5 illustre la manière dont le déploiement 7 d'un élément Ei est effectué. Au cours d'un tel déploiement quatre types de commandes sont émis par le pilote de déploiement PI à destination du portail de déploiement PO. Par une première commande d'installation [INSTALLER Ei] contenant les propriétés du descripteur de l'élément, le pilote PI ordonne 61 au portail PO l'installation du composant Ei de l'application sélectionnée. En réponse à la commande d'installation, le portail PO - 15 commande une recherche de l'élément désigné Ei s'il s'agit d'un composant, à travers au moins un moteur de recherche MR dans une bibliothèque BI de composants, de manière à récupérer une instance du composant dans le terminal TE, ou une référence distante de ce comp osant. Après comp l ète exécution de la commande d' install ati on, l'installation de l'élément est confirmée 62 par un message d'acquittement [ACK (INSTALLER Ei)] transmis par le portail PO au pilote PI. Le pilote PI émet 63 ensuite au portail PO une seconde commande [PARAMETRER Ei], contenant les paramètres de configuration de l'élément Ei, pour paraméker l'élément installé. Le paramétrage de l'élément Ei est effectué en fonction de certains paramètres contenus dans le descripteur de l'élément et dépend du contexte d'exécution de l' app lication et éventuel lement de s élections de l'utilisateur, dé finis durant le déploiement. Une fois le paramétrage de l'élément effectué par le portail PO, ce dernier transmet 64 au pilote PI un message d'acquittement [ACK(PARAMETRER Ei)]. Si aux étapes 62 et 64, le portail PO n'a pas répondu par un acquittement avant la fin d'une temporisation prédéterminée, un message d'erreur est transmis 65 par le pilote PI au terminal TE pour signaler que le déploiement de l'élément n'a pas pu être effectué. Dans le cas o plusieurs éléments sont déployés de manière asynchrone, ils doivent bien entendu être indépendants les uns des autres, sachant qu'un élément dépendant d'autres éléments ne peut pas être déployé tant que les éléments dont il dépend ne sont pas déployés sur le terminal. Dans l'exemple de la fgure 1 et selon le descripteur d'application correspondant donné ci-avant, seul le composant d'interface utilisateur CA1 est prioritaire (priorité égale à 100) et est déployé avant l'exécution de l'application sur le terminal. Ensuite, en tâche de fond ou parce que l'utilisateur l'a demandé, le composant d'agent bancaire CA2 qui a la priorité moyenne la plus élevée (70) est installé, ainsi que le composant CA4 qui a la même priorité. Le déploiement de ces deux composants peut être effectué de manière asynchrone, c' est- à- dire sensiblement en parallèle, ces deux éléments étant indépendants l'un de l'autre et ne dépendant pas d'autres éléments. Le déploiement du composant CA5 peut également être lancé puisqu'il est indépendant des autres éléments de l'application, même s'il possède un niveau de priorité de 50 inférieure à celui d'autres éléments non encore déployés comme les connexions CX1 - 16 et CX3. Toutefois, ce déploiement peut ne pas être effectué si par exemple il est conditionné par les performances du terminal. Ensuite, une fois que les composants CA2 et CA4 sont déployés, les connexions CX1 entre l'interface utilisateur CA1 et l'agent CA2, et CX3 entre l'agent et le s serveur bancaire B1, lesquels ont la priorité moyenne la plus élevée suivante 69, peuvent étre déployés en parallèle. La connexion CX4 entre les composants CA2 et CA5 peut être installée à la suite du composant CA5. Les autres éléments, c'est-à-dire CA3, CA6 et CX6 ayant une priorité inférieure à 10 ne sont installés que si l'utilisateur les demande. Selon une variante prétérée de l'invention, les éléments utilisés durant l'exécution de l' application sont marqués et à la fin d'exécution de l' application, le terminal TE transmet à la carte à puce la référence des éléments ainsi marqués. A la suite de cette transmission, la carte à puce met à jour les indicateurs de priorité de tous les éléments de l'application en fonction des éléments qui ont ainsi été utilisés. Les indicateurs de priorité des éléments de l'application peuvent ainsi être modifiés dans certaines limites. Par exemple, les indicateurs de priorité des éléments utilisés sont augmentés, tandis que les éléments non utilisés sont diminués. - 17 REVENDICATIONS 1. Procédé pour déployer une application composée de plusieurs éléments distants répartis (CA, CX), depuis un premier moyen de traitement de données (CP, PI) contenant des descripteurs desdits éléments, sur un second moyen de traitement de données (TE) relié à des moyens d'implantation (MR, BI) des éléments, et exécuter l'application une fois déployée, caractérisé en ce qu'il comporte au moins les étapes consistant à: - sélectionner (2) au moins un élément (CA1) de l'application en tant qu'élément prioritaire, - déployer (3) sur le second moyen de traitement (TE) le ou les éléments prioritaires (CA1), et - exécuter (5) l'application par le second moyen de traitement (TE) dès que le ou les éléments prioritaires ont été déployés. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape de sélection (2) d'au moins un élément (CA1) de l'application en tant qu'élément prioritaire consiste à examiner au moins un indicateur de priorité contenu dans le descripteur (DAP) de ladite application. 3. Procédé selon la revendication 1 ou 2, caractéri sé en ce que si au cours de l' exécution de l 'applicati on par le 2s second moyen de traitement de données (TE), un élément (CA2, CA3) non déployé est appelé, il comprend une étape (7) de déploiement de l'élément appelé, puis une étape (5) de poursuite de l'exécution de l'application. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que les éléments (CA2, CA4) de 1'application non sélectionnés en tant qu'éléments prioritaires sont déployés (9) sur le second moyen de traitement de données (TE) en parallèle de l'exécution (5) de l'application. 5. Procédé selon la revendication 4, caractérisé en ce qu'il comprend en outre une étape (13) de transmission du contexte d'exécution de l'application depuis le second moyen de - 18 traitement (TE) de données vers le premier moyen de traitement de données (CP), et en ce que le déploiement (9) en parallèle de l'exécution de l' application, des éléments (CA2, CA4) de l'application non sélectionnés en tant qu'éléments prioritaires, est réalisé en fonction du contexte d'exécution transmis. 6. Procédé selon l'une quelcouque des revendications 1 à 5, caractéris é en ce que les éléments (CA2, CA4) de l' app li cation non sélectionnés en tant qu'éléments prioritaires, sont déployés (9) sur le second moyen de traitement (TE) en parallèle de l'exécution (5) de l'application, d'une manière synchrone. 7. Procédé selon l'une quelcouque des revendications 1 à 5, caractérisé en ce que les éléments (CA2, CA4) de l'application non sélectionnés en tant qu'éléments prioritaires, sont déployés (9) sur le second moyen de traitement (TE) en parallèle de l'exécution (5) de l'application, d'une manière asynchrone. 8. Procédé selon l'une quelconque des revendications 1 à 7, 2 0 caractéri s é en ce qu' i l comprend en outre une étap e de s élection d' au moins un élément (CA3, CA6) de l'application en tant qu'élément non pri oritaire, les éléments non prioritaires de l' app licati on étant dép l oyés (7) sur le second moyen de traitement (TE) uniquement s'ils sont appelés au cours de l'exécution (5) de l'application. 9. Procédé selon l'une quelconque des revendications 2 à 8, caractérisé en ce qu'en fin d'exécution (5) de l'application, il comprend en outre une étape de mise à jour des indicateurs de priorité respectifs des éléments (CA) de l'application en fonction des éléments (CA) qui ont été utilisés durant l'exécution de l'application. 10. Objet électronique (CP) comprenant un moyen de description (DAP) pour décrire une application (AP) composée de plusieurs éléments distants répartis (CA, CX), et un moyen de traitement (PI) pour déployer l'application en vue de son exécution à l'extérieur (TE) de l ' obj et électronique, en fonction du moyen de description de l'application, caractérisé en ce que le moyen de description (DAP) comporte au moins - 19 un indicateur de priorité pour sélectionner au moins un élement (CA1) en tant qu'élément prioritaire de l' application, et en ce que le moyen pour déployer l'application ne déploie que les éléments prioritaires avant d' autoris er l' exécution de l' app lication. 11. Objet électronique selon la revendication 10, caractérisé en ce qu'il est de type carte à microcontrôleur. 12. Système de déploiement d'application comprenant un objet électronique portable (CP) du type carte à microcontrôleur, un terminal (TE) connecté à un réseau de transmission de données (RT) et comportant un moyen pour communiquer avec l'objet électronique portable (CP), l'objet électronique portable comprenant un moyen de description (DAP) pour décrire une application (AP) composée de plusieurs éléments distants répartis (CA, CX) accessibles au terminal par le réseau de kansmission de données (RT), et un moyen de traitement (PI) pour déployer l'application sur le terminal (TE) en vue de son exécution par le terminal, en fonction du moyen de description de l'application, caractérisé en ce que le moyen de description (DAP) comporte au moins un indicateur de priorité pour sélectionner au moins un élement en tant qu'élément prioritaire de l' application, et en ce que le moyen pour déployer l'application ne déploie que les éléments prioritaires avant de déclencher l'exécution de l'application déployée sur le terminal (TE).