Brevet FR3095054A1 — publié le 20201016

Description Titre de l'invention : Gestion d'une mémoire dans un dispositif élec- tronique Domaine technique [0001] L'invention se rapporte au domaine de la gestion de la mémoire dans des dispositifs électroniques et vise plus particulièrement à optimiser l'utilisation de l'espace mémoire dans une mémoire volatile d'un dispositif électronique. [0002] De façon connue, lorsqu'un élément sécurisé (ES) est intégré ou embarqué dans un dispositif électronique hôte, tel qu'un SOC (pour « System on Chip ») par exemple, il est nécessaire de charger des applications dans l'élément sécurisé pour les exécuter. Pour ce faire, l'élément sécurisé comporte généralement une mémoire volatile (RAM) interne apte à charger le code exécutable et les données d'une application à exécuter. [0003] Un tel élément sécurisé peut être, par exemple, un modem ou une carte mère, ou plus généralement, une unité de traitement indépendante configurée pour coopérer de façon sécurisée avec un dispositif électronique hôte, dans lequel est intégré ou embarqué l'élément sécurisé. [0004] La mémoire volatile de l'élément sécurisé est généralement de taille relativement réduite, ce qui limite la taille et le nombre des applications que l'on peut exécuter dans l'élément sécurisé. 100051 Le dispositif électronique hôte peut également comporter une mémoire non volatile (MNV), tel qu'une mémoire non volatile réinscriptible par exemple. Cette mémoire non volatile permet de conserver en mémoire des applications susceptibles d'être invoquées si besoin par l'élément sécurisé, c'est-à-dire le code exécutable et les données de ces applications. 100061 L'élément sécurisé doit alors accéder à certaines données présentes dans la mémoire non volatile du dispositif hôte afin que ces données puissent être récupérées et chargées dans la mémoire volatile de l'élément sécurisé. L'accès à de telles données dans la mémoire non volatile du dispositif hôte est toutefois coûteux en temps et en ressources, ce qui limite les performances générales du système, en particulier lorsque de nombreux accès en lecture ou écriture sont nécessaires dans la mémoire non volatile du dispositif hôte. 100071 De tels problèmes de gestion d'une mémoire volatile se posent notamment dans les systèmes dits bytecode-compilés, c'est-à-dire dans lesquels le code source des applications est compilé ou traduit dans une représentation intermédiaire, à savoir un code interprétable orienté objet que l'on appelle couramment le « bytecode ». 100081 L'invocation de codes exécutables de type bytecode depuis une mémoire non volatile 2 vers une mémoire volatile, notamment vers la RAM d'un élément sécurisé embarqué dans un dispositif hôte comme indiqué ci-dessus, pose des problèmes de performance en raison du temps et des ressources nécessaires pour l'accès dans la mémoire non volatile et l'enregistrement dans la RAM. [0009] Un besoin existe par conséquent pour une solution permettant un accès plus efficace à des codes interprétables orientés objet et à des données dans un système comportant une mémoire volatile de taille limitée et une mémoire non volatile capable de stocker des applications. En particulier, des accès en lecture et écriture plus rapides et moins coûteux en ressources sont souhaitables, pour un dispositif électronique (tel qu'un élément sécurisé par exemple) accédant à une mémoire non volatile située hors de ce dispositif électronique. Ce besoin existe notamment pour les systèmes exécutant des applications en langage interprété orienté objet (de type bytecodc), tel que le bytecode Java ou Java Card par exemple. [0010] De manière générale, il est souhaitable d'améliorer l'utilisation de l'espace mémoire dans une mémoire volatile et de faciliter les accès à du code interprétable orienté objet qui est stocké dans une mémoire non volatile, dont l'accès en lecture et écriture est couteux en ressources. Objet et résumé de l'invention [0011] A cet effet, la présente invention concerne un procédé (dit aussi procédé de traitement), mis en oeuvre par un premier système comportant un premier dispositif électronique comportant une première mémoire, ledit premier dispositif électronique coopérant avec un deuxième dispositif électronique comportant une deuxième mémoire, le procédé comprenant : une étape de chargement initial (B8) comprenant : acquisition (B10) d'une application (APP1) comportant du code interprétable orienté objet, définissant une pluralité de méthodes (MT) exécutables ; génération (B12) dans la première mémoire, pour chaque méthode du code interprétable, d'un objet distinct (OBM) dit objet-méthode ; une étape d'envoi (B15) de chaque objet-méthode (OBM) au deuxième dispositif électronique (DV2) pour enregistrement dans la deuxième mémoire (MR2) ; une étape d'interprétation (B18) comprenant : interprétation (B19) du code interprétable de l'application (APPI) ; identification (B20), à partir de ladite interprétation, d'au moins un objet-méthode (OBMI) invoqué dans le code interprétable ; et une étape d'allocation (B26) dans la première mémoire, pour chaque objet-méthode (OBM) invoqué qui n'est pas stockée dans la première mémoire (MRI), comprenant : 3 récupération (B28), depuis la deuxième mémoire (MR2), dudit objet-méthode ; et enregistrement (B30), dans la première mémoire (MR1), dudit objet-méthode récupéré depuis la deuxième mémoire, pour en permettre un accès par le premier dispositif électronique. [0012] L'invention offre ainsi une gestion avantageuse de l'espace mémoire de la première mémoire, par exemple de type volatile, dans la mesure où le code exécutable peut être récupéré sous forme d'objet-méthode depuis la deuxième mémoire (par exemple de type non volatile) et chargé quand cela est nécessaire dans la première mémoire (par exemple de type volatile). Le code interprétable orienté objet d'une application peut ainsi être chargé dans la première mémoire même lorsque celle-ci présente une taille réduite ne permettant pas d'y charger toute l'application en même temps ou même tout une classe. [0013] L'accès au code interprétable orienté objet est facilité car le premier dispositif DV1 peut accéder aux objets-méthodes directement dans sa mémoire volatile s'ils sont disponibles ou, à défaut, peut récupérer ceux-ci depuis la mémoire du deuxième dispositif DV2. [0014] L'invention permet en particulier de limiter le pic de consommation en mémoire volatile dans le premier dispositif DV1 lorsque l'application APP1 est chargée dans la mémoire MR1. On peut rapatrier les objets-méthodes un par un dans la mémoire MR1 lorsque ceux-ci sont invoqués à l'exécution de l'application APPL On évite notamment le rapatriement d'un ensemble de méthodes dans la mémoire volatile, comme par exemple le chargement de toutes les méthodes d'une classe (class loading), comme cela peut être nécessaire dans les solutions conventionnelles. [0015] L'invention permet de faciliter l'exécution d'une application en langage interprété orienté objet. Si la mémoire volatile ne contient pas l'objet souhaité, le premier dispositif le copie depuis sa version disponible dans la deuxième mémoire du deuxième dispositif. Les accès subséquents sont ensuite réalisés depuis la version de l'objet conservée dans la première mémoire du premier dispositif. [0016] Selon un mode de réalisation particulier, lors de l'étape de chargement initial, le premier système reçoit une application qui est chargée dans la deuxième mémoire du deuxième dispositif électronique ou dans une mémoire volatile du deuxième dispositif électronique. [0017] Selon un mode de réalisation particulier, l'étape de chargement initial comprend, pour chaque méthode du code interprétable : chargement dans la première mémoire de ladite méthode du code interprétable ; et génération dans la première mémoire d'un objet-méthode correspondant, sous la forme d'une structure de données prédéterminée comprenant un entête et un corps d'objet ; dans lequel le corps d'objet comprend du code interprétable orienté objet définissant l'objet-méthode. [0018] Selon un mode de réalisation particulier, l'étape de chargement initial est réalisée à partir d'une première partie et d'un deuxième partie qui sont compris dans l'application chargée dans le deuxième dispositif électronique lors de ladite étape de chargement initial, la première partie comportant une concaténation de la pluralité de méthodes de et la deuxième partie comportant des indications de position indiquant une position respective de chaque méthode dans la première partie. [0019] Selon un mode de réalisation particulier, le procédé comprend, lors de l'étape d'interprétation : vérification, pour chaque objet-méthode invoqué, de si ledit objet-méthode est stocké dans la première mémoire, le premier dispositif électronique procédant à ladite allocation pour l'objet-méthode invoqué seulement si ledit objet-méthode n'est pas stocké dans la mémoire volatile. [0020] Selon un mode de réalisation particulier, lors de l'étape d'interprétation, le premier dispositif électronique détermine, pour chaque objet-méthode invoqué, que ledit objet-méthode est stocké dans la première mémoire s'il détecte des données de localisation, enregistrées dans la première mémoire, comprenant une première référence d'objet indiquant où l'objet-méthode est enregistré dans la première mémoire et une deuxième référence d'objet indiquant où l'objet-méthode est enregistré dans la deuxième mémoire dans le deuxième dispositif électronique. [0021] Selon un mode de réalisation particulier, lors de l'étape d'interprétation, le premier dispositif électronique détermine, pour chaque objet-méthode invoqué, que ledit objet-méthode n'est pas stocké dans la mémoire volatile s'il ne détecte pas de dites données de localisation dans la mémoire volatile. [0022] Selon un mode de réalisation particulier, pour chaque objet-méthode récupéré et en- registré dans la mémoire volatile lors de ladite étape d'allocation, le premier dispositif enregistre, dans la mémoire volatile, des dites données de localisation comprenant une première référence d'objet indiquant où l'objet-méthode est enregistré dans la mémoire volatile et une deuxième référence d'objet indiquant où l'objet-méthode est enregistré en mémoire dans le deuxième dispositif électronique. [0023] Selon un mode de réalisation particulier, les données de localisation de chaque objet- méthode stocké dans la mémoire volatile sont enregistrées, dans la mémoire volatile, en tant qu'objet de données, dit objet de localisation, propre audit objet-méthode. [0024] Selon un mode de réalisation particulier, chaque objet-méthode et chaque objet de lo- calisation sont enregistrés ensemble dans un même conteneur mémoire dans la mémoire volatile. [0025] Selon un mode de réalisation particulier, sur détection lors de ladite étape d'allocation que la mémoire volatile ne dispose pas d'un espace mémoire suffisant pour enregistrer chaque objet-méthode invoqué, le premier dispositif électronique réalise un mécanisme d'éviction au cours duquel il supprime au moins un autre objet déjà stocké dans la première mémoire pour libérer un espace mémoire suffisant pour enregistrer chaque objet-méthode invoqué, dans lequel pour chaque objet-méthode supprimé de la mémoire volatile par le mécanisme d'éviction, le premier dispositif électronique supprime les données de localisation dudit objet-méthode. [0026] Selon un mode de réalisation particulier, ledit procédé comprend une opération d'écriture comprenant : modification d'un objet-méthode stocké dans la première mémoire ; détermination de la position où est enregistré l'objet-méthode dans la deuxième mémoire ; et envoi d'une commande d'écriture spécifiant ladite modification dudit objet-méthode pour modifier ledit objet-méthode stockée à ladite localisation dans la mémoire non volatile. [0027] Selon un mode de réalisation particulier, lors de ladite récupération, le premier dispositif électronique envoie au deuxième dispositif électronique au moins une commande de lecture spécifiant : ledit objet-méthode, dit objet-méthode récupéré, qui est invoqué et qui n'est pas stocké dans la mémoire volatile; et une adresse de destination respective à laquelle ledit objet-méthode récupéré doit être enregistré dans une mémoire intermédiaire à laquelle le premier dispositif électronique a accès. [0028] Selon un mode de réalisation particulier, le procédé comprend en outre une exécution dudit au moins un objet-méthode invoqué, stocké dans la mémoire volatile. [0029] Selon un mode de réalisation particulier, le procédé comprend, suite à ladite exécution, une détection ultérieure que ledit au moins un objet-méthode invoqué est à nouveau invoqué en association avec ladite application, et une opération de lecture de la mémoire volatile pour exécuter ledit au moins un objet-méthode invoqué, stocké dans la mémoire volatile. [0030] Selon un mode de réalisation particulier, le premier dispositif électronique comprend une machine virtuelle apte à interpréter le code interprétable de l'application à partir d'une pile (l'exécution, le procédé comprenant : 6 sur détection d'une référence d'un objet-méthode sur la pile d'exécution, exécution d'une action sécuritaire pour bloquer son accès à une application. dans lequel le premier dispositif électronique détecte que l'objet référencé dans la pile d'exécution est un objet-méthode à partir de la donnée de type contenue dans les métadonnées de l'objet-méthode. [0031] Selon un mode de réalisation particulier, le premier dispositif électronique et le deuxième dispositif électronique forment un seul et même dispositif électronique ou sont deux dispositifs électroniques distincts. [0032] Dans un mode particulier de réalisation, les différentes étapes du procédé sont dé- terminées par des instructions de programmes d'ordinateurs. [0033] En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un dispositif électronique tel qu'une carte à puce ou un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé tel que défini dans ce document. [0034] L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. [0035] A noter que les programmes d'ordinateur mentionnés dans le présent document peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. [0036] De plus, les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. [0037] D'autre part, les supports d'enregistrement peuvent correspondre à un support trans- missible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou pai- d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. [0038] Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé clans l'exécution du procédé en question. [0039] L'invention vise également le premier dispositif électronique en tant que tel. [0040] En particulier, l'invention vise un système, dit premier système, comprenant un premier dispositif électronique comportant une première mémoire, et configuré pour 7 coopérer avec un deuxième dispositif électronique comportant une deuxième mémoire, le premier système comprenant, pour réaliser un chargement initial: un module d'acquisition configure pour acquérir une application comportant du code interprétable orienté objet, définissant une pluralité de méthodes exécutables ; un module de génération configure pour générer dans la première mémoire, pour chaque méthode du code interprétable, un objet distinct dit objet-méthode ; un module d'envoi configure pour envoyer chaque objet-méthode au deuxième dispositif pour enregistrement dans la mémoire non volatile ; le premier dispositif électronique comprenant en outre, pour réaliser une interprétation : un module d'interprétation configure pour interpréter le code interprétable de l'application ; un module d'identification configure pour identifier, à partir d'une interprétation du code interprétable réalisée par le module d'interprétation, au moins un objet-méthode invoqué dans le code interprétable ; un module de traitement configure pour réaliser une allocation dans la première mémoire, pour chaque objet-méthode invoqué qui n'est pas stocké dans la mémoire volatile, de sorte à: récupérer, depuis la deuxième mémoire, ledit objet-méthode; et enregistrer, dans la première mémoire, ledit objet-méthode récupéré depuis la deuxième mémoire, pour en permettre un accès par le premier dispositif électronique. [0041] Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. [0042] Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. [0043] A noter que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé de traitement de l'invention ainsi que les avantages associés s'appliquent de façon analogue au premier dispositif électronique de l'invention. [0044] Pour chaque étape du procédé de l'invention décrit dans ce document, le dispositif électronique de l'invention peut comprendre un module correspondant configure pour réaliser ladite étape. 8 100451 L'invention concerne également un système, dit deuxième système, comprenant un premier système comme déjà défini ci-avant ; et ledit deuxième dispositif électronique, comportant une deuxième mémoire, étant configuré pour coopérer avec le premier système. Brève description des dessins [0046] D'autres caractéristiques et avantages de la présente invention ressortiront de la des- cription faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures: [0047] [fie.11 la figure 1 représente schématiquement un système comprenant un premier dispositif électronique et un deuxième dispositif électronique selon un mode de réalisation particulier de l'invention ; [0048] [fig.2] la figure 2 représente schématiquement des modules fonctionnels mis en oeuvre par le premier dispositif électronique selon un mode de réalisation particulier de l' invention ; [0049] [fig.3] la figure 3 représentent, sous forme d'un diagramme, les étapes d'un procédé de traitement conforme à un mode de réalisation particulier de l'invention ; [0050] [fig.4] la figure 4 représente, sous forme d'un diagramme, les étapes d'un procédé de traitement conforme à un mode de réalisation particulier de l'invention ; [0051] [fig.5] la figure 5 représente schématiquement les données de localisation générées par le premier dispositif électronique, selon un mode de réalisation particulier de l' invention ; [0052] [fig.6] la figure 6 représente schématiquement la structure d'un objet-méthode, selon un mode de réalisation particulier de l'invention ; [0053] [fig.7] la figure 7 représente schématiquement sous forme d'un diagramme un mode de réalisation particulier ; [0054] [Fig. 8-9] les figures 8 et 9 représentent, sous forme de diagrammes, les étapes de mécanisme d'éviction selon des modes de réalisation particuliers de l'invention ; [0055] [fig.10] la figure 10 représente, sous forme d'un diagramme, les étapes d'une opération d'écriture selon un mode de réalisation particulier de l'invention ; et [0056] la figure 11 représente, sous forme d'un diagramme, un mécanisme de sécurisation selon un mode de réalisation particulier de l'invention. Description détaillée de plusieurs modes de réalisation [0057] Comme indiqué précédemment, l'invention vise à améliorer l'utilisation de l'espace mémoire dans une mémoire volatile d'un dispositif électronique. L'invention vise notamment à faciliter l'accès à du code interprétable orienté objet qui est stocké dans une mémoire, telle qu'une mémoire non volatile dont les accès en lecture et écriture sont couteux en ressources. 9 [0058] Les problèmes de gestion d'une mémoire volatile tels que décrits précédemment se posent plus particulièrement dans les systèmes dits bytecode-compilés, c'est-à-dire dans lesquels le code source des applications est compilé ou traduit en code interprétable orienté objet que l'on appelle couramment du « bytecodc ». [0059] Un code interprétable (ou exécutable) orienté objet est généralement conçu ini- tialement en code source puis converti par compilation en bytecode. De façon bien connue pour l'homme du métier, le bytecode est une représentation intermédiaire qui n'est pas directement exécutable par un processeur et doit donc être interprétée ou compilée par un logiciel spécifique, appelé « machine virtuelle », pour permettre l'exécution de l'application par un processeur. Cette forme de code exécutable présente notamment l'avantage d'être portable entre différentes architectures. [0060] Comme bien connu de l'homme du métier, un objet dans le contexte d'un langage in- terprété orienté objet constitue une instance d'une classe et une classe est un descripteur programmatique regroupant un ensemble d'attributs et de méthodes. En outre, une méthode dans un langage interprété orienté objet est une routine membre d'une classe. Il peut s'agir aussi bien de méthodes d'instance que de méthodes statiques. Ces éléments étant bien connus de l'homme du métier, ils ne sont pas décrits plus en détail dans ce document. [0061] Aujourd'hui, divers types de langages interprétés orientés objet peuvent être compilés en bytecode avant d'être exécutés par un interpréteur (ou compilé par un compilateur). Ainsi, une application Java ou Java Card est habituellement transmise sous forme de bytecode à un dispositif cible tel qu'un élément sécurisé comme évoqué ci-avant. Cet élément sécurisé réalise une compilation ou interprétation, éventuellement à la volée, pour traduire le bytecode en code machine avant exécution. Pour ce faire, l'élément sécurisé met en oeuvre un logiciel spécifique appelé « machine virtuelle », bien connu de l'homme du métier. [0062] Comme déjà indiqué, le chargement de codes interprétables de type bytecode depuis une mémoire non volatile dans une mémoire volatile, notamment dans la RAM d'un élément sécurisé embarqué dans un dispositif hôte, pose des problèmes de performance en raison du temps et des ressources nécessaires pour l'accès dans la mémoire non volatile et le chargement dans la RAM. [0063] A cet effet, l'invention, selon différents modes de réalisation, vise un procédé de traitement mis en oeuvre par un premier système comprenant un premier dispositif électronique comportant une première mémoire (une mémoire volatile par exemple), ce premier système coopérant avec un deuxième dispositif électronique comportant une deuxième mémoire (une mémoire non volatile par exemple). Pour permettre l'accès par le premier dispositif électronique à un code interprétable orienté objet, le procédé prévoit en particulier la génération, pour chaque méthode exécutable défini dans le code interprétable orienté objet, d'un objet distinct dit « objet-méthode » qui est stocké en mémoire dans le deuxième dispositif. Ces objets-méthodes sont accessibles si besoin par le premier dispositif et peuvent être chargés dans la première mémoire de ce dernier. Lorsque le premier dispositif électronique interprète le code interprétable orienté objet et identifie des objets-méthodes invoqués dans ce code, il peut accéder directement à ces objets-méthodes s'ils sont stockés dans sa mémoire volatile ou, à défaut, il peut charger ces objets-méthodes depuis la deuxième mémoire du deuxième dispositif (ou éventuellement depuis une autre mémoire de ce dernier) dans sa première mémoire. [0064] L'invention offre ainsi une gestion avantageuse de l'espace mémoire de la première mémoire, par exemple de type volatile, dans la mesure où le code exécutable peut être récupéré sous forme d'objet-méthode depuis la deuxième mémoire (par exemple de type non volatile) et chargé quand cela est nécessaire dans la première mémoire (par exemple de type volatile). Le code interprétable orienté objet d'une application peut ainsi être chargé dans la première mémoire même lorsque celle-ci présente une taille réduite ne permettant pas d'y charger toute l'application en même temps ou même tout une classe. [0065] Le procédé, selon des modes de réalisation particuliers, comprend une étape de chargement initial au cours de laquelle le premier dispositif électronique : fait l'acquisition d'une application comportant du code interprétable orienté objet, définissant une pluralité de méthodes exécutables ; génère dans la première mémoire, pour chaque méthode du code interprétable, un objet distinct dit objet-méthode. Le procédé comprend en outre une étape d'envoi au cours de laquelle le premier dispositif électronique envoie chaque objet-méthode au deuxième dispositif électronique pour enregistrement dans la deuxième mémoire ; puis une étape d'interprétation ultérieure. Au cours de cette étape d'interprétation, le premier dispositif électronique : interprète du code interprétable de l'application ; et identifie, à partir de ladite interprétation, au moins un objet-méthode invoqué dans le code interprétable. Le procédé comprend en outre, suite à l'étape d'interprétation, une étape d'allocation réalisée par le premier dispositif électronique pour chaque objet-méthode invoqué qui n'est pas stocké dans la première mémoire, comprenant : une récupération depuis la deuxième mémoire dudit objet-méthode ; et un enregistrement dans la première mémoire dudit objet-méthode récupéré depuis la deuxième mémoire, pour en permettre un accès par le premier dispositif électronique. [0066] L'invention vise également le premier dispositif électronique, un système comprenant les premiers et deuxièmes dispositifs électroniques, ainsi qu'un programme d'ordinateur pour l'exécution du procédé de l'invention et un support d'enregistrement comportant un tel programme d'ordinateur. 11 [0067] D'autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. [0068] Dans ce document, des exemples de mise en oeuvre de l'invention sont décrits dans le cadre d'un élément sécurisé (ES) coopérant avec un dispositif électronique hôte, tel qu'un SOC (pour « System on Chip ») par exemple, dans lequel l'élément sécurisé est embarqué ou intégré. Des mises en oeuvre de l'invention sont toutefois possibles dans d'autres environnements. [0069] Comme défini par l'organisme de standardisation « GlobalPlatform » bien connu de l'homme du métier, un élément sécurisé (pour « secure dûment ») est une plateforrne matérielle et logicielle configurée pour héberger de façon sécurisée des applications et leurs données sensibles associées (clés cryptographiques, algorithmes...), en conformité avec des règles fixées par une autorité tierce de confiance. Un élément sécurisé fournit un environnement d'exécution sécurisé à des applications. Il peut prendre diverses formes, telles qu'un module UICC (pour « Univcrsal Integrated Circuit Card »), un élément sécurisé embarqué (ou « embedded SE» ou encore « eSIM ») en tant qu'élément discret ou intégré, ou encore une carte rnicroSD. Un module UICC et une carte microSD sont généralement amovibles. Chaque forme d'élément sécurisé est destinée à être utilisée dans des applications bien particulières et doit répondre à des exigences propres au marché concerné. [0070] Un élément sécurisé peut par exemple être utilisé en téléphonie mobile pour au- thentifier l'utilisateur d'un terminal de communication auprès d'un réseau mobile auquel il est abonné, ou encore pour mettre en oeuvre une application de paiement dans le domaine bancaire. [0071] Toutefois, l'invention ne s'applique pas de manière exclusive aux architectures SE/ SOC mais vise de manière plus générale la gestion de l'espace mémoire dans une première mémoire - par exemple une mémoire volatile - d'un premier dispositif électronique afin de permettre à celui-ci un accès rapide et efficace à du code exécutable, et plus particulièrement à du code interprétable orienté objet, qui est stocké et accessible dans une deuxième mémoire, par exemple une mémoire non volatile. [0072] L'invention peut s'appliquer dans divers architectures ou systèmes dans lesquels du code interprétable orienté objet doit être chargé dans une première mémoire pour exécuter une application. En particulier, l'invention peut être mise en oeuvre dans une carte à puce, dans un terminal de communication ou dans tout autre système approprié comportant une mémoire volatile et une mémoire non volatile. [0073] Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. 12 [0074] La figure 1 représente un système SY, dit premier système, comportant un premier dispositif électronique DV1 et un deuxième dispositif électronique DV2, selon un mode de réalisation particulier. Les premiers et deuxièmes dispositifs électroniques DV1 et DV2 sont configurés pour coopérer ensemble pour permettre notamment la gestion d'un code exécutable comme décrit ci-après. [0075] Comme représenté en figure 1, le premier système SY peut en outre comprendre un troisième dispositif électronique DV3 configure pour coopérer avec le deuxième dispositif DV2. Dans ce cas, le premier dispositif DV1 et le troisième dispositif DV3 forment ensemble un deuxième système noté SZ. Comme indiqué par la suite, des mises en oeuvre de l'invention sans ce troisième disposition DV3 sont toutefois possibles. [0076] Dans l'exemple de réalisation considéré ici, le premier dispositif DV1 est un élément sécurisé (SE) comme déjà décrit précédemment, ce dernier étant intégré ou embarqué dans le deuxième dispositif électronique (un SOC par exemple) servant de dispositif hôte. Un tel élément sécurisé peut être, par exemple, embarqué, ou intégré sous forme de brique matérielle, dans un modem ou une puce. Plus généralement, l'élément sécurisé peut être une unité de traitement indépendante, configurée pour coopérer dc façon sécurisée avec le dispositif électronique hôte, dans lequel est intégré ou embarqué l'élément sécurisé. [0077] Selon l'exemple représenté en figure 1, le premier dispositif électronique DV1 et le deuxième dispositif électronique DV2 sont donc deux dispositifs électroniques distincts coopérant ensemble. En variante, le premier dispositif électronique DV1 et le deuxième dispositif électronique DV2 forment un seul et même dispositif électronique. [0078] Le premier dispositif électronique DV1 comprend dans cet exemple un processeur 2, une mémoire volatile MR1 (RAM) et une interface de communication 4 pour communiquer avec le deuxième dispositif électronique DV2. [0079] La mémoire volatile MR1 constitue une « première mémoire » au sens de l'invention. Cette mémoire est apte à stocker notamment des objets, et plus particulièrement des objets-méthodes OBM et des objets-données OBDT, ainsi que des données de position DP (notées ici DPI à DP5) et des données de localisation DL (notées ici DLI à DL5). Ces différents éléments seront décrits plus en détails ultérieurement. [0080] Dans ce document, on désigne par « objet-méthode » un objet (au sens d'un langage orienté objet) con-espondant à une méthode du code interprétable considéré incluant éventuellement son gestionnaire d'exception, à savoir dans cet exemple, le code interprétable orienté objet défini dans une application APP1. De même, un « objet-donnée » est un objet correspondant à des données de l'application considérée, à savoir APP1 dans cet exemple. 13 [0081] La mémoire volatile MR1 constitue un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le premier dispositif électronique DV1, et sur lequel peut être enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier. En variante, ce programme P01 est stocké dans une mémoire non volatile (non représenté) du premier dispositif DV1. Cc programme d'ordinateur PG1 comporte des instructions pour l'exécution des étapes d'un procédé de traitement qui est décrit ultérieurement selon des modes de réalisation particuliers. [0082] Selon une variante, la mémoire MR1 est une mémoire non volatile (par exemple une mémoire non volatile réinscriptible). Dans ce cas, le premier dispositif DV1 peut en outre comporter une mémoire volatile (non représentée) qui peut servir de mémoire intermédiaire dans le cadre de l'invention. [0083] Le deuxième dispositif électronique DV2 comprend dans cet exemple un processeur 12, une mémoire non volatile MR2, une interface de communication 14 pour communiquer avec le premier dispositif électronique DV1, et éventuellement une mémoire volatile MR3. [0084] La mémoire MR2 constitue une « deuxième mémoire » au sens de l'invention. Cette mémoire est par exemple une mémoire non volatile réinscriptible, par exemple de type Flash. EEPROM ou autre. Cette mémoire permet de stocker une application susceptible d'être exécutée si besoin par le premier dispositif DV1, une telle application comprenant le code exécutable (ou code interprétable orienté objet) et les données associées. Selon une variante, la mémoire MR2 est une mémoire volatile. [0085] On considère ici que la mémoire MR2 est en particulier apte à stocker une ap- plication APPI et des objets associés à cette application, à savoir des objets-méthodes OBMI à OBM5 notés collectivement OBM et des objets-données OBDTI à OBDT6 notés collectivement OBDT, dans l'exemple de la figure 1. [0086] Comme illustré aussi en figure 1, on suppose par la suite que l'application APPI comporte du code interprétable orienté objet, définissant une pluralité de méthodes exécutables MT1 à MT5, notées collectivement MT. Ces méthodes MT se présentent sous la forme de bytecode qui est interprétable par le premier dispositif DVI en mettant en oeuvre un logiciel spécifique, à savoir une machine virtuelle. [0087] Le code interprétable orienté objet est par exemple codé dans le langage Java ou Java Card, d'autres langages étant toutefois possibles. [0088] Dans cet exemple, l'application APPI comporte en outre des données DT1 à DT6, notées collectivement DT. [0089] La mémoire non volatile MR2 constitue un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le deuxième dispositif électronique DV2, et sur lequel peut être enregistré un programme 14 d'ordinateur P02 conforme à un mode de réalisation particulier. Ce programme d'ordinateur P02 est exécuté par le deuxième dispositif DV2 pour coopérer avec le premier dispositif DV1. [0090] De façon optionnelle, la mémoire volatile (RAM) MR3 peut être utilisée comme mémoire intermédiaire pour charger l'application APP1 ou encore pour permettre l'accès par le premier dispositif DV1 à certains objets (objets-méthodes et/ou objets-données). [0091] De manière générale, l'application APP1, une fois stockée en mémoire dans le deuxième dispositif DV2 (dans la mémoire non volatile MR2 ou éventuellement dans la mémoire volatile MR3), doit être chargée dans la mémoire volatile MR1 du premier dispositif DV1 pour pouvoir être exécutée. Pour ce faire, les méthodes MT doivent être chargées dans la mémoire volatile MR1 comme décrit ultérieurement. [0092] A noter que certains éléments généralement présents dans un élément sécurisé et dans un SOC destiné à coopérer avec un tel élément sécurisé, ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la présente invention. [0093] Le système SY représenté en figure 1 ne constitue qu'un exemple de réalisation, d'autres mises en oeuvre étant possibles dans le cadre de l'invention. L'homme du métier comprendra en particulier que certains éléments du système SY ne sont décrits ici que pour faciliter la compréhension de l'invention, ces éléments n'étant pas nécessaires pour mettre en oeuvre l'invention. [0094] Par ailleurs, la figure 2 représente selon un mode de réalisation particulier des modules mis en oeuvre par le processeur 2 piloté par le programme d'ordinateur P01, à savoir : un module d'acquisition MD2, un module de génération MD4, un module d'envoi MD6, un module d'interprétation MD8, un module d'identification MD10 et un module de traitement MD12. [0095] Le module d'acquisition MD2 et le module de génération MD4 sont configurés pour réaliser ensemble un chargement initial de l'application APP1. [0096] Dans l'exemple considéré ici, ces modules MD2, MD4 et MD6 sont mis en oeuvre dans le premier dispositif DV1 (dans ce cas, le troisième dispositif DV3 n'est donc pas nécessaire). Selon une variante, ces modules MD2, MD4 et MD6 sont mis en oeuvre à l'extérieur du premier dispositif DVI, par exemple dans le troisième dispositif DV3 représenté en figure 1. Dans une telle variante, le troisième dispositif DV3 utilise donc un processeur et une troisième mémoire volatile (et/ou une mémoire non volatile) qui lui sont propres pour réaliser les fonctions associées aux modules MD2, MD4 et MD6 comme décrits ci-après. [0097] Plus spécifiquement, le module d'acquisition MD2 est configuré pour acquérir (recevoir ou obtenir) une application APP1. Dans cet exemple, cette application APPI a par exemple été chargée au préalable en mémoire dans le deuxième dispositif élec- tronique DV2 (dans la mémoire non volatile MR2 ou dans la mémoire volatile MR3), bien que d'autres exemples soient possibles. [0098] Le module de génération MD4 est configuré pour générer dans la mémoire volatile MR1, pour chaque méthode MT du code interprétable de l'application APP1, un objet distinct OBM dit objet-méthode. Lors de cette génération, le premier dispositif DV1 génère ou crée ainsi des objets-méthodes OBM correspondant respectivement à chacune des méthodes MT définies dans le code interprétable de l'application APPl. La nature de ces objets-méthodes et la manière dont ceux-ci sont générés sont décrites plus en détail ultérieurement dans des exemples particuliers. [0099] Le module d'envoi MD6 est configuré pour envoyer chaque objet-méthode généré par le module de génération MD4 au deuxième dispositif DV2 pour enregistrement dans la mémoire non volatile MR2. [0100] Comme décrit par la suite, le module de génération MD4 peut en outre générer et en- registrer dans la mémoire volatile MR1 des données de position DP associées aux objets-méthodes ainsi alloués, ces données étant représentatives de la position respective à laquelle ces objets-méthodes sont stockés dans la mémoire non volatile MR2. A partir de ces données de position DP, le premier dispositif DV1 peut ainsi récupérer depuis la mémoire non volatile MR2 des objets-méthodes souhaités. [0101] Dans le cas où les objets-méthodes OBM sont non seulement générés mais également alloués dans la mémoire volatile MR1 lors du chargement initial de l'application APPI, le module de génération MD4 peut également enregistrer dans la mémoire volatile MR1 des données de localisation DLI-DL5 (appelées collectivement DL) associées respectivement aux objets-méthodes OBM1-0BM5, bien que cela ne soit pas obligatoire comme expliqué ultérieurement. [0102] Par ailleurs, le module d'interprétation MD8 et le module d'identification MDIO sont configurés pour réaliser ensemble une interprétation du code interprétable de l'application APP1, une fois que le chargement initial mentionné ci-dessus a été effectué. Dans l'exemple de réalisation considéré ici, les modules MD8-MD10, ainsi que le module MD12, sont mis en oeuvre dans le premier dispositif DV1. [0103] Plus spécifiquement, le module d'interprétation MD8 est configuré pour interpréter le code interprétable de l'application APP1. Pour ce faire, le module d'interprétation met en oeuvre une machine virtuelle adaptée à l'application APP1 considérée. [0104] Le module d'identification MDIO est configuré pour identifier, à partir de l'interprétation du code interprétable réalisée par le module d'interprétation MD8, au moins un objet-méthode OBM (par exemple OBM1) invoqué dans le code interprétable de l'application APP1. [0105] Le module de traitement MD12 est configuré pour réaliser une allocation dans la mémoire volatile MRI, pour chaque objet-méthode OBM invoqué qui n'est pas déjà 16 stocké dans la mémoire volatile MR1, de sorte à : récupérer, depuis la mémoire non volatile MR2, ledit objet-méthode OBM ; et enregistrer, dans la mémoire volatile MR1, ledit objet-méthode OBM récupéré depuis la mémoire non volatile MR2, pour en permettre un accès par le premier dispositif électronique DVI. [0106] La configuration et le fonctionnement des modules MD2-MD12 définis ci-avant ap- paraîtront plus précisément dans les exemples de réalisation décrits ci-après. A noter que les modules MD2-MD12 tels que représentés en figure 2 ne représentent qu'un exemple de mise en oeuvre non limitatif de l'invention. [0107] Comme déjà indiqué, on suppose par la suite que les modules MD2 à MD12 sont mis en oeuvre dans le premier dispositif DV1, bien que des variantes soient possibles dans lesquelles les modules MD2-MD6 sont mis en oeuvre dans le troisième dispositif DV3. [0108] Un mode de réalisation particulier de l'invention est à présent décrit en référence aux figures 3,5 et 6. Plus précisément, le premier dispositif électronique DVI (figures 1-2 ), coopérant avec le deuxième dispositif électronique DV2, met en oeuvre le procédé de traitement de l'invention en exécutant le programme d'ordinateur P01. [0109] La figure 3 représente les étapes mis en oeuvre par les premiers et deuxièmes dis- positifs électroniques DVI, DV2 dans ce mode de réalisation particulier. [0110] Au cours d'une étape A2 de chargement, l'application APP1 déjà décrite ci-avant est chargée en mémoire dans le deuxième dispositif électronique DV2. Dans cet exemple, l'application APP1 est chargée dans la mémoire non volatile MR2. Selon une variante, l'application APPI est chargée dans la mémoire volatile MR3. [0111] Comme déjà décrit, l'application APP1 comporte du code interprétable orienté objet (c'est-à-dire du code exécutable de type bytecode), définissant une pluralité de méthodes MT exécutables, à savoir les méthodes MTI-MT5 dans cet exemple (figures 1-2). L'application APPI comprend en outre des données DT associées, à savoir les données DT1-DT6. [0112] Au cours d'une étape A8 d'envoi, le deuxième dispositif DV2 envoie au premier dispositif DVI l'application APP1, y compris les méthodes MT1-MT5. Cette transmission A8 se fait progressivement, par paquets de données comprenant notamment les méthodes MT1-MT5. Ces paquets de données peuvent également comprendre par exemple les données DTI-DT6 comme expliqué ultérieurement. [0113] Le premier dispositif DVI réalise alors une étape B8 de chargement initial au cours de laquelle il fait l'acquisition (B10) de l'application APP1 sous forme de paquets de données puis génère (B12), ou alloue, dans la mémoire volatile MR1, pour chaque méthode MTI-MT5 du code interprétable de l'application APPI, un objet distinct OBM - dit objet-méthode -, noté respectivement OMB1-OBM5. Autrement dit, le premier dispositif DVI génère ou créée (étape B12) dans la mémoire volatile MR1 un objet-méthode respectif OBM pour chaque méthode MT défini dans le code exécutable 17 de l'application APP1. Cette étape B8 de chargement initial vise ainsi à prédécouper chacune des méthodes MT présentes dans le bytecode de l'application APP1 en un objet-méthode OBM respectif qui pourra par la suite être appelé séparément et exécuté par le premier dispositif DV1. [0114] Plus spécifiquement, lors de l'étape B8 de chargement initial, le premier dispositif DV1 reçoit en B10 des paquets de données comportant les méthodes MT1-MT5. Pour chaque méthode MT1-MT5 reçue, le premier dispositif DV1 génère (B12) (et éventuellement alloue) un objet-méthode respectif OBM1-0BM5 qui est enregistré dans la mémoire volatile MR1. [0115] Typiquement, la taille de la mémoire volatile MR1 ne permet pas de charger en même temps toutes les méthodes MT1-MT5 dans la mémoire MR1 ou encore de stocker en même temps tous les objets-méthodes OBM1-0BM5 correspondants dans la mémoire MR1. Un mécanisme d'éviction peut alors être mis en oeuvre par le premier dispositif DV1 pour libérer progressivement de l'espace mémoire dans la mémoire MR1, comme expliqué par la suite. [0116] Les objets-méthodes OBM générés en B12 sont de type « bytccode » dans le sens où ils contiennent chacun du bytecode de l'application APP1 correspondant à une méthode MT donnée. [0117] Comme représenté en figure 5, chaque objet-méthode OBM est généré à l'étape B12 (figure 3) par exemple sous la forme d'une structure de données prédéterminée comprenant un entête Pl et un corps (l'objet P2. L'entête Pl comporte des métadonnées pouvant spécifier au moins Fun parmi : une donnée de type (ou donnée de classification), notée DN1, indiquant que l'objet OBM considéré est un objet-méthode définissant une méthode de l'application APP1 ; une donnée de taille, notée DN2, représentative de la taille de l'objet méthode considéré ;et toutes autres informations appropriées. [0118] La donnée de taille DN2 permet en particulier à l'interpréteur du premier dispositif DV1, à l'exécution de l'application APP1, de savoir comment lire l'objet considéré et comment le rapatrier si besoin depuis le deuxième dispositif DV2 vers sa mémoire MR1. En l'absence de la donnée DN2, la récupération d'un objet-méthode OBM depuis la mémoire MR2 vers la mémoire MR1 peut être affectée dans la mesure où trop ou pas assez de données sont récupérées, limitant ainsi les performances du système. [0119] En outre, le corps P2 de l'objet-méthode OBM comprend des données DN3 associées à la méthode MT correspondante. Autrement dit, ces données DN3 comprennent l'ensemble du bytecode (du code interprétable orienté objet) de la méthode MT correspondante, y compris les opérandes et éventuellement ses blocs de traitement d'erreur 18 (ou « handlers ») configurés pour traiter des conditions exceptionnelles (erreurs, exceptions...) pendant l'exécution de la méthode MT. Comme le comprend l'homme du métier, lorsqu'une condition d'erreur est détectée lors de l'exécution de la méthode MT, un bloc de traitement (handlcr) approprié est exécuté. [0120] Toujours au cours de l'étape B8 de chargement initial (figure 3), le premier dispositif DV1 peut enregistrer (B13) des données de position DP qui sont représentatives de la position où chaque objet-méthode respectif OBM1-0BM5 ainsi créé est censé être stocké dans la mémoire non volatile MR2 ou éventuellement dans la mémoire volatile MR3 (cf. enregistrement A16 ci-après). [0121] Dans l'exemple considéré ici, ces données de position DP sont dites persistantes dans le sens où elles sont conservées dans la mémoire volatile MR1 même si les objets-méthodes OBM correspondants, après leur génération en B12, sont éventuellement supprimés de la mémoire volatile MR1 (par exemple en mettant en oeuvre un mécanisme d'éviction pour libérer de l'espace mémoire dans MR1). Le premier dispositif DV1 peut ainsi récupérer depuis la mémoire MR2 (ou MR3) du deuxième dispositif DV2, à partir de ces données de positionnement DP, des objets-méthodes OBM désirés lorsque ceux-ci ne sont plus présents dans sa mémoire volatile MR1. Comme décrit par la suite (en référence notamment à la figure 4), d'autres modes de réalisation sont toutefois possibles dans lesquels les données de position DP n'ont pas besoin d'être conservées de façon persistante dans la mémoire MR1. [0122] Selon un exemple particulier, les données de localisation DL de chaque objet- méthode OBM sont stockées dans la mémoire volatile MRI en tant qu'objet de données (dit « objet-données ») OBDT. Ces objets constituent ainsi l'instance d'une classe définie dans le langage, orienté objet, qui est utilisé par l'application APPI, comme le comprend l'homme du métier. [0123] Toujours au cours de l'étape B8 de chargement initial, le premier dispositif DVI peut enregistrer (B 14) dans la mémoire MR1 des données de localisation DL, notées ici DL1-DL5, associés respectivement à chaque objet-méthode OBM1-OBM5 généré en B12. Comme expliqué par la suite, d'autres modes de réalisation sont possibles dans lesquels l'enregistrement de telles données de localisation DL n'est pas nécessaire à ce stade du procédé. [0124] Plus précisément, comme représenté en figure 6, les données de localisation DL comprennent une première référence d'objet AD1 indiquant où l'objet-méthode respectif OBM est enregistré dans la mémoire volatile MRI et une deuxième référence d'objet AD2 indiquant où l'objet-méthode respectif OBM est enregistré en mémoire (en MR2 ou éventuellement en MR3) dans le deuxième dispositif électronique DV2. Ces données de localisation DL sont dites temporaires dans le sens où, lorsqu'un objet-méthode OBM est supprimé de la mémoire volatile MR1, les données de localisation 19 DL associées sont supprimées également de la mémoire volatile MR1. [0125] La référence d'objet AD1 (respectivement AD2) peut être une adresse dans la mémoire MR1 (respectivement MR2 ou MR3), ou encore un identifiant d'objet, par exemple pour chercher les objets-méthodes dans une liste d'objets. Ces données de localisation peuvent se présenter sous diverses formes telles qu'une table ou des objets comme décrit ci-après. La deuxième référence d'objet AD2 indique où l'objet-méthode est enregistré dans le deuxième dispositif DV2, c'est-à-dire dans la mémoire non volatile MR2 ou éventuellement dans la mémoire volatile MR3 (si MR3 est utilisée ultérieurement pour l'interprétation du code interprétable de l'application APP1). [0126] Dans l'exemple de réalisation considéré ici (figure 3), pour chaque objet-méthode OBM généré (B12) dans la mémoire volatile MR1, le premier dispositif DV1 conserve donc dans sa mémoire volatile MR1 les données de localisation DL correspondantes. en plus de générer chaque objet-méthode OBM1-0BM5 en B12, le premier dispositif DV1 alloue (B12-B13) ces objets-méthodes à une localisation donnée dans sa mémoire MR1. [0127] Selon un exemple particulier, les données de localisation DL de chaque objet- méthode OBM stocké dans la mémoire volatile MR1 sont enregistrées, dans la mémoire volatile MR1, en tant qu'objet de données, dit objet de localisation, propre à l'objet-méthode OBM concerné. Ces objets de localisation DL constituent ainsi l'instance d'une classe définie dans le langage orienté objet utilisé par l'application APP1, comme le comprend l'homme du métier. Cet exemple particulier permet d'allouer dynamiquement un espace mémoire de taille adéquate aux données de localisation DL dans la mémoire volatile MR1, optimisant ainsi l'utilisation de l'espace dans la mémoire volatile MR1. L'affectation statique d'un espace mémoire pour ces données de localisation DL bloquerait l'usage d'un espace mémoire plus ou moins important dans la mémoire volatile MR1. Il en résulterait une difficulté pour fixer la taille de cet espace mémoire, qui risquerait d'être soit trop faible pour accueillir toutes les données de localisation DL, soit trop grande ce qui serait couteux en ressources et limiterait l'usage de la mémoire MR1 à d'autres fins Cet exemple particulier permet d'affecter dynamiquement un espace mémoire adapté dans la mémoire volatile MR1 pour stocker les données de localisation DL, dont le volume est susceptible de varier. [0128] Ces objets de localisation DL peuvent présenter une structure analogue à celle des objets-méthodes OBM décrits en référence à la figure 5. En particulier, ces objets de localisation peuvent se présenter sous la forme d'une structure de données prédéterminée comprenant un entête P1 et un corps d'objet P2. L'entête P1 comporte des métadonnées pouvant spécifier au moins l'un parmi : [0129] une donnée de type (ou donnée de classification), notée DN1, indiquant que l'objet OBM considéré est un objet de localisation indiquant la localisation en mémoire d'un objet ; une donnée de taille, notée DN2 représentative de la taille de l'objet méthode considéré ; et toutes autres informations appropriées. [0130] En outre, le corps P2 de l'objet de localisation DL comprend des données DN3 dé- finissant les données de localisation DL, et comprenant en particulier la première référence d'objet AD1 et la deuxième référence d'objet AD2 telles que définies ci-avant. [0131] Selon un autre exemple de réalisation, le premier dispositif DV1 ne réalise pas l'enregistrement B14 des données de localisation DL lors de l'étape B8 de chargement initial. Les objets-méthodes OBM générés en B12 sont transmis au deuxième dispositif DV2 (lors de l'étape B15 comme décrit ci-après) sans avoir été alloué en tant que tel dans la mémoire MR1 et donc sans enregistrer les données d'allocation DL correspondantes. Cette variante permet de libérer un maximum d'espace mémoire dans la mémoire volatile MR1 pendant l'étape B8 de chargement initial, et d'économiser les ressources nécessaires lors de cette étape. Dans cette variante, les données de position DP permettent par la suite au premier dispositif DV1 de récupérer si besoin depuis la mémoire MR2 des objets-méthodes OBM invoqués, comme expliqué ci-après. [0132] Toujours en référence à la figure 3, au cours d'une étape B15 d'envoi, le premier dispositif DV1 envoie chaque objet-méthode OBM généré en B12 au deuxième dispositif DV2 pour enregistrement dans sa mémoire non volatile MR2 (ou éventuellement dans sa mémoire volatile MR3). Ces objets-méthodes OBM sont reçus et chargés en mémoire (i.e. dans MR2 ou MR3) par le deuxième dispositif DV2 au cours d'une étape A15. Dans l'exemple considéré ici, on suppose que tous les objets-méthodes OBM sont reçus et chargés dans la mémoire MR2. [0133] Les objets-méthodes OBM générés en B12 peuvent être transmis (B15) progres- sivement, l'un après l'autre ou par paquets, au deuxième dispositif DV2. Dans l'exemple considéré (figure 3), chaque objet-méthode OBM est transmis (B15) au deuxième dispositif DV2 dans une commande CMDI, accompagné d'une référence d'objet AD2 indiquant où l'objet-méthode OBM doit être enregistré en mémoire dans le deuxième dispositif DV2. Comme déjà indiqué, cette référence d'objet AD2 peut être une adresse mémoire, un identifiant ou toute autre information permettant au deuxième dispositif DV2 de déterminer où l'objet-méthode OBM doit être enregistré dans sa mémoire MR2 ou MR3. [0134] Comme illustré en figure 1, dans un cas particulier où l'application APP1 est codée en langage interprété Java Card, l'étape B8 de chargement initial précédemment décrite peut être réalisée à partir d'une première partie CP1 et d'une deuxième partie CP2 qui sont toutes deux comprises dans l'application APP1 chargée dans le deuxième 21 dispositif électronique DV2. La première partie CP1 (dit composant « METHOD ») comporte alors une concaténation des méthodes MT de l'application APP1 tandis que le deuxième composant CP2 (dit « DESCRIPTOR ») comporte des indications de position DN5 indiquant une position respective de chaque méthode MT dans la première partie CP1. Ces indications de position DN5 peuvent représenter par exemple l'emplacement de début de chaque méthode dans le composant CP1 (informations relatives dites « d'offset »). Le cas échéant, la deuxième partie CP2 peut également indiquer la taille de chaque méthode MT et/ou le nombre de méthodes MT. [0135] Le premier dispositif DV1 peut en outre récupérer les données DT contenues dans une troisième partie CP3 de l'application APPl. Ces parties CP1, CP2 et CP3 sont par exemple conformes à la norme « Java Card 3 Plateform Virtual Machine Specification » (chapitre 6 : « The CAP file format »). [0136] A l'issue des étapes A2-A15 et B8-B15, l'application APP1 a donc été chargée pro- gressivement dans la mémoire volatile MR1 du premier dispositif DV1 et des objets-méthodes respectifs OBM définissant chaque méthode MT du code interprétable de l'application APP1 ont été alloués et stockés dans la mémoire MR2 du deuxième dispositif DV2. Comme décrit ci-après, ces objets-méthodes sont accessibles à la demande par le premier dispositif DV1. [0137] De façon analogue aux méthodes MT, le premier dispositif DV1 peut également recevoir en B10 (figure 3) les données DT de l'application APP1, et générer en B12 un objet-données OBDT, noté respectivement OBDT1-0BDT6, pour chacune des données DT1-DT6 de l'application APPI (figure 1). Ces objets-données OBDT sont également transmis en B15 (figure 3) par le premier dispositif DVI au deuxième dispositif DV2 pour enregistrement dans la mémoire non volatile MR2 ou dans la mémoire volatile MR3. Des données de position DP et des données de localisation DL peuvent également être générées par le premier dispositif DVI en association à chacun des objets-données OBDT, de façon identique à ce qui est décrit ci-avant en référence aux étapes B13 et B14. [0138] Toujours à l'issue des étapes A2-A15 et B8-B15, une partie des objets-méthodes OBM générés en B8 peut être conservée dans la mémoire volatile MR1. Dans ce cas, les données de localisation DL des objets-méthodes OBM sont également conservées dans la mémoire volatile MR1. Comme déjà indiqué, la mémoire volatile MR1 est typiquement de taille insuffisante pour conserver en même temps tous les objets-méthodes OBM, bien que cela soit possible dans certains cas. Aussi, le premier dispositif DV1 peut être configuré pour supprimer au moins l'un des objets-méthodes précédemment créés afin de libérer de l'espace dans la mémoire MR1 en vue de créer d'autres objets-méthodes OBM. Un exemple d'implémentation d'un mécanisme d'éviction est décrit ultérieurement. [0139] Toujours en référence à la figure 3, le premier dispositif DVI réalise ensuite une étape B18 d'interprétation au cours de laquelle il lit et interprète le code interprétable orienté objet de l'application APPl. Pour ce faire, le premier dispositif DV1 met en oeuvre un interpréteur appelé « machine virtuelle » (de type Java par exemple) qui interprète le code interprétable à partir d'une pile d'exécution, de façon bien connue de l'homme du métier. Cette interprétation permet de convertir le code interprétable de l'application APP1 en code machine avant exécution. [0140] Lors de cette interprétation, le premier dispositif DVI identifie (B20, figure 3) un ou des objets-méthodes OBM qui sont invoqués dans le code interprétable. [0141] Pour chaque objet-méthode OBM invoqué, le premier dispositif DVI vérifie (B22) si l'objet-méthode OBM en question est déjà stocké dans la mémoire volatile MR1. Dans l'affirmative, le procédé se poursuit à l'étape B24 de lecture, sinon le procédé se poursuit à l'étape B26 d'allocation. [0142] Plus spécifiquement, le premier dispositif DV1 procède à une étape B26 d'allocation pour chaque objet-méthode OBM invoqué qui n'est pas couramment stocké dans la mémoire volatile MR1. Pour ce faire, le premier dispositif DVI détermine en B22, qu'un objet-méthode OBM invoqué n'est pas stocké dans la mémoire volatile MR1 s'il ne détecte pas de données de localisation DL associées dans la mémoire volatile MR1. [0143] A titre d'exemple, on suppose dans la suite que le premier dispositif DVI détecte en B20 (figure 3) que l'objet-méthode OBMI est invoqué. Le premier dispositif DVI vérifie (B22) alors si l'objet-méthode OBMI est déjà stocké dans la mémoire volatile MR1. Pour ce faire, le premier dispositif DVI détermine en B22 si des données de localisation DL1 associées à l'objet-méthode OBMI sont stockées dans la mémoire volatile MR1. [0144] Si de telles données de localisation DL1 sont déjà stockées dans la mémoire volatile MR1, cela signifie que l'objet-méthode OBM1 est également présent dans la mémoire volatile MR1 (OBMI alloué dans la mémoire MR1). Dans ce cas, le premier dispositif DVI procède à l'étape B24 de lecture au cours de laquelle il accède à l'objet-méthode OBMI directement dans sa mémoire volatile MR1 en utilisant les données de localisation DLI, puis procède à l'étape B34 d'exécution (figure 3). Pour rappel, dans cet exemple, les données de localisation DLI comprennent une première référence d'objet ADI indiquant où l'objet-méthode OBM1 est enregistré dans la mémoire volatile MR1 et une deuxième référence d'objet AD2 indiquant où l'objet-méthode OBMI est enregistré en mémoire (MR2 ou MR3) dans le deuxième dispositif DV2 (figure 6). Le premier dispositif DVI retrouve ainsi en B24 (figure 3) l'objet-méthode OBMI dans la mémoire volatile MR1 à partir de la première référence d'objet ADI. [0145] Si, en revanche, aucune donnée de localisation DL1 n'est stockée dans la mémoire volatile MR1 en association avec l'objet-méthode OBMI, cela signifie que cet objet- 23 méthode n'est pas présent dans la mémoire volatile MR1. Dans ce cas, le premier dispositif DV1 procède alors à l'étape B26 d'allocation afin de récupérer l'objet-méthode OBM1 depuis la mémoire MR2 (ou éventuellement MR3) du deuxième dispositif DV2. [0146] De manière générale, lors de l'étape B22 (figure 3) de détermination, l'objet-méthode OBM1 qui est recherché par le premier dispositif DV1 peut être ou non présent dans la mémoire volatile MR1 selon le cas. Comme déjà décrit, cet objet-méthode OBM1 a été précédemment généré lors de l'étape B8 de chargement initial niais le premier dispositif DV1 n'a pas nécessairement conserver en mémoire MR1 cet objet-méthode OBM1 par la suite. Ce dernier peut avoir été supprimé, c'est-à-dire évincé de la mémoire volatile MR1 pour libérer de l'espace mémoire. Comme déjà décrit, les données de localisation DL sont dites temporaires de sorte que, si l'objet-méthode OBM a été préalablement évincé de la mémoire volatile MR1, alors il en va de même concernant les données de localisation DL1 associées. [0147] Au cours de l'étape B26 d'allocation (figure 3), le premier dispositif DV1 récupère (B28) l'objet-méthode OBM1 manquant depuis le deuxième dispositif DV2. Pour ce faire, le premier dispositif DV1 envoie (B28) au deuxième dispositif DV2 une commande de lecture CMD2 reçue par le deuxième dispositif DV2 en A28 pour récupérer l'objet-méthode OBM1. Cette commande de lecture CMD2 comprend les données de position DP1 associées à l'objet-méthode OBM1, ces données de position DP1 ayant été préalablement récupérées dans la mémoire volatile MR1 par le premier dispositif DV1. En réponse, le premier dispositif DV1 reçoit en provenance du deuxième dispositif DV2 l'objet-méthode OBM1 qui est présent dans la mémoire MR2 ou MR3 (A30; B28). [0148] Le premier dispositif DV1 spécifie ainsi au deuxième dispositif DV2 le ou les objets- méthodes OBM qu'il souhaite récupérer depuis la mémoire MR2 (ou MR3) du deuxième dispositif DV2. Dans l'exemple considéré ici, le processeur 12 du deuxième dispositif DV2 n'a pas un accès direct à la mémoire volatile MR1 du premier dispositif DV1 notamment pour des raisons de sécurité. Les objets-méthodes OBM demandés par le premier dispositif DV1 sont partagés par le deuxième dispositif DV2 via une mémoire intermédiaire (non représentée) accessible par le premier dispositif DV1 et par le deuxième dispositif DV2. Le processeur 2 du premier dispositif DV1 recopie ensuite les objets-méthodes OBM demandés dans sa mémoire volatile MR1 à la position souhaitée. Cette mémoire intermédiaire peut se trouver par exemple dans le premier dispositif DV1 ou dans le deuxième dispositif DV2. Il peut s'agir par exemple de la mémoire MR3. [0149] Selon un exemple particulier, lors de la récupération B28, le premier dispositif DVI envoie ainsi au moins une commande de lecture CMD2 au deuxième dispositif DV2 24 pour récupérer chaque objet-méthode OBM désiré qui n'est pas disponible dans la mémoire volatile MR1. Cette commande de lecture CMD2 peut par exemple spécifier : l'objet-méthode souhaité, appelé ici « objet-méthode récupéré », ainsi qu'une adresse de destination respective à laquelle chaque objet-méthode récupéré doit être enregistré dans une mémoire intermédiaire (à laquelle le premier dispositif électronique DV1 a accès). [0150] Toujours au cours de l'étape B26 d'allocation, pour chaque objet-méthode OBM récupéré en B28, le premier dispositif DV1 enregistre (B30) cet objet-méthode dans sa mémoire volatile MR1 à la position souhaitée (figure 3). Le premier dispositif DV1 génère (B32) en outre des données de localisation DL (comme déjà décrites) en association à chaque objet-méthode récupéré, ces données de localisation DL comprenant une première référence d'objet AD1 indiquant où l'objet-méthode OBM est enregistré dans la mémoire volatile MR1 et une deuxième référence d'objet AD2 indiquant où l'objet-méthode OBM est enregistré en mémoire dans le deuxième dispositif électronique DV2, i.e. dans la mémoire non volatile MR2 ou éventuellement dans la mémoire volatile MR3 (si MR3 est utilisée pour l'interprétation). Le premier dispositif DV1 enregistre (B32) ainsi ces données de localisation DL dans la mémoire volatile MR1 en association à chaque objet-méthode OBM récupéré en B28. [0151] L'étape B32 de génération et d'enregistrement peut être réalisée lors de l'étape B28 de récupération. [0152] On suppose donc dans cet exemple que le premier dispositif DV1 enregistre (B30, B32) dans sa mémoire volatile MR1 l'objet-méthode OBM1 en association avec les données de localisation DLl. [0153] Les aspects décrits ci-avant en référence aux données de localisation DL susceptibles d'être générées à l'étape B14 (figures 3 et 6) s'appliquent de la même manière aux données de localisation DL générées en B32 lors de l'interprétation du code interprétable de l'application APP1. [0154] En particulier, ces données de localisation DL sont temporaires dans le sens où, si un objet-méthode OBM est par la suite supprimé de la mémoire volatile MR1, les données de localisation DL associées sont supprimées également de la mémoire volatile MR1. Comme déjà indiqué, pour chaque objet-méthode OBM présent dans sa mémoire volatile MR1 à un instant donné, le premier dispositif DVI peut conserver dans sa mémoire volatile MR1 les données de localisation DL correspondantes. Par ailleurs, la nature des références d'objet AD1 et AD2 peut être adaptée selon le cas (adresse, identifiant...). La forme de ces données de localisation DL peut également varier selon le cas (table, liste d'objets...). [0155] Comme déjà décrit précédemment, selon un exemple particulier, les données de loca- lisation DL de chaque objet-méthode OBM stocké dans la mémoire volatile MR1 sont enregistrées, dans la mémoire volatile MR1, en tant qu'objet de données, dit objet de localisation, propre à l'objet-méthode OBM considéré. Ces objets de localisation constituent ainsi l'instance d'une classe définie dans le langage, orienté objet, qui est utilisé par l'application APP1, comme le comprend l'homme du métier. [0156] Une fois l'étape B26 d'allocation effectuée, le premier dispositif DV1 procède à l'étape B34 au cours de laquelle il exécute chaque objet-méthode OBM identifié précédemment en B20 (figure 3) - à savoir l'objet-méthode OBM1 dans cet exemple - depuis la mémoire volatile MR1 du premier dispositif DVI. Pour ce faire, la machine virtuelle mise en oeuvre par le premier dispositif DVI change le pointeur d'instruction pour aller exécuter chaque objet-méthode OBM invoqué. [0157] L'accès aux objets-données OBDT souhaités peut être réalisé par le premier dispositif DVI de la même manière que pour les objets-méthodes OBM, comme décrit ci-avant en référence aux étapes B19-B34. [0158] A noter par ailleurs que les étapes B19 à B34 peuvent être réalisées une pluralité de fois lors d'itérations successives. [0159] Suite à l'exécution en B34 (figures 3-4) de chaque objet-méthode OBM invoqué, si le premier dispositif DVI détecte (B20) que l'un au moins de ces objets-méthodes est à nouveau invoqué en association avec l'application APP1 (au cours d'une itération ultérieure), il réalise une opération de lecture (B24) dans sa mémoire volatile MR1 pour exécuter chaque objet-méthode OBM souhaité, stocké dans la mémoire volatile MR1. Il en va de même pour l'accès aux objets-données OBDT de l'application APP1. [0160] Autrement dit, à partir de la deuxième exécution d'un objet-méthode OBM invoqué, l'accès à cet objet-méthode se fait directement dans la mémoire volatile MR1, sauf cas particulier où cet objet-méthode a entretemps été évincé comme expliqué ultérieurement. [0161] Ainsi, dans l'exemple considéré ici, l'objet-méthode OBMI est conservé dans la mémoire volatile MR1 après achèvement de l'exécution B34 de la méthode MT I. II est ainsi possible pour le processeur 2 du premier dispositif DVI d'accéder rapidement à la méthode MTI sans dépenser de ressources en chargeant à nouveau l'objet-méthode OBMI depuis la mémoire du deuxième dispositif DV2. Il en va de même pour l'accès aux données DT de l'application APP1. [0162] L'ordre dans lequel les étapes B8-B34 sont exécutées n'est proposé ici qu'à titre illustratif, d'autres ordres d'exécution étant possibles. Par exemple, l'ordre dans lequel les étapes B12, B13 et B14 sont exécutés lors de l'étape B8 de chargement initial peut varier selon le cas. [0163] L'invention permet avantageusement d'améliorer l'utilisation de l'espace mémoire dans la mémoire volatile MR1 du premier dispositif DVI. Plus particulièrement, l'accès à du code interprétable orienté objet est facilité car le premier dispositif DVI 26 peut accéder aux objets-méthodes directement dans sa mémoire volatile s'ils sont disponibles ou, à défaut, peut récupérer ceux-ci depuis la mémoire du deuxième dispositif DV2. [0164] De même, le premier dispositif DV1 peut accéder facilement aux objets-donnés di- rectement dans sa mémoire volatile s'ils sont disponibles ou, à défaut, peut récupérer ceux-ci depuis la mémoire du deuxième dispositif DV2. [0165] L'invention permet en particulier de limiter le pic de consommation en mémoire volatile dans le premier dispositif DV1 lorsque l'application APP1 est chargée dans la mémoire MR1. On peut rapatrier les objets-méthodes un par un dans la mémoire MR1 lorsque ceux-ci sont invoqués à l'exécution de l'application APPL On évite notamment le rapatriement d'un ensemble de méthodes dans la mémoire volatile, comme par exemple le chargement de toutes les méthodes d'une classe (class loading), comme cela peut être nécessaire dans les solutions conventionnelles. [0166] Lors de l'exécution de l'application, le premier dispositif DV1 détecte si chaque objet-méthode invoqué est présent en mémoire volatile interne ou pas. La détection éventuelle de la présence en mémoire volatile interne profite donc des accès sur les objets comme le prévoit le code interprétable orienté objet, et non selon des accès sur les pages de la mémoire externe du deuxième dispositif DV2 ou selon des accès sur des adresses directement. [0167] Selon l'invention, les objets peuvent contenir le bytecode d'une méthode, ou des données. La granularité de l'accès repose donc ici sur les objets, ce qui facilite l'exécution d'une application en langage interprété orienté objet. Si la mémoire volatile ne contient pas l'objet souhaité, le premier dispositif le copie depuis sa version disponible dans la mémoire non volatile du deuxième dispositif (ou éventuellement dans la mémoire volatile de ce dernier). Les accès subséquents sont ensuite réalisés depuis la version de l'objet conservée dans la mémoire volatile du premier dispositif. Si cette mémoire volatile est pleine, le premier dispositif peut évincer de manière sélective un ou plusieurs objets afin de libérer de l'espace mémoire, par exemple pour enregistrer d'autres objets. [0168] Un deuxième mode de réalisation particulier de l'invention est à présent décrit en référence à la figure 4. Plus précisément, le premier dispositif électronique DV1 ( figures 1-2), coopérant avec le deuxième dispositif électronique DV2, met en oeuvre le procédé de traitement de l'invention en exécutant le programme d'ordinateur P01. [0169] Ce deuxième mode de réalisation diffère du premier mode de réalisation représenté en figure 3 dans la manière dont les données de position DP sont traitées. Plus précisément, lors de l'étape B8 de chargement initial, le premier dispositif DV1 génère (B12) un objet-méthode OBM respectif pour chaque méthode MT de l'application APPI, et peut éventuellement enregistrer (B14) également des données de localisation 27 DL dans la mémoire MR1, de façon identique à ce qui a déjà été décrit en référence à la figure 3. [0170] Toujours au cours de l'étape B8 de chargement initial, le premier dispositif DV1 peut enregistrer (B13) également des données de position DP qui sont représentatives de la position où chaque objet-méthode respectif OBM1-0BM5 ainsi créé est censé être stocké dans la mémoire non volatile MR2 (ou éventuellement dans la mémoire volatile MR3) lors de l'étape AIS d'enregistrement, comme déjà décrit en référence à la figure 3. Ces données de position DP sont ainsi enregistrées dans une structure de données appropriée. [0171] Dans le premier mode de réalisation représenté en figure 3, ces données de position DP sont conservées dans la mémoire volatile MR1 pour pouvoir être utilisées ultérieurement par le premier dispositif DV1 en B28 pour récupérer les objets-méthodes OBM invoqués qui ne sont plus présents dans la mémoire MR1. Or, selon ce deuxième mode de réalisation représenté en figure 4, les données de position DP sont utilisées d'une manière différente. [0172] Plus précisément, comme représenté en figure 4, une fois que tous les objets- méthodes OBM1-0BM5 générés en B12 ont été chargés lors de l'étape AIS dans la mémoire MR2, le premier dispositif DVI reçoit en provenance du deuxième dispositif DV2 et charge (B36) à nouveau tous ces objets-méthodes OBM1-0BM5 dans sa mémoire MR1 afin d'y insérer (B37) les données de position DP adéquates. Pour cc faire, le deuxième dispositif DV2 envoie au premier dispositif DVI les objets-méthodes OBM1-OBM5 précédemment créés en B12. Cette transmission A50 peut se faire progressivement, par paquets de données comprenant chaque objet-méthode OBM1-0BM5 et éventuellement aussi les objets-données OBDT1-0BDT6 précédemment créés. Le premier dispositif DVI réalise alors une étape B36 de chargement (ultérieure au chargement initial B8) au cours de laquelle il reçoit dans sa mémoire MR1 les objets transmis par le deuxième dispositif DV2. [0173] Au cours d'une étape B37 d'insertion, le premier dispositif DVI insère dans au moins l'un des objets-méthodes OBM1-0BM5 les données de position DP appropriées. Ces données de position DP peuvent être insérées dans le bytecode de chaque objet-méthode OBM en remplacement des opérandes du bytecode qui, de façon connue, encodent par exemple un index dans une structure de données appelée « constant pool » (application Java). Les données de position DP ainsi insérées (B37) peuvent indiquer la localisation d'un autre objet-méthode qui est appelé par l'objet-méthode OBM en question. A l'exécution, l'interpréteur du premier dispositif DVI interprète ainsi l'opérande de l'objet-méthode OBM comme étant les données de position DP précédemment insérées dans cet objet-méthode. [0174] Pour ce faire, il est nécessaire que le premier dispositif DVI détermine, avant 28 l'exécution de l'application APP1, quel objet-méthode (dit « objet-méthode appelé ») est appelé par un objet-méthode OBM donné (dit « objet-méthode appelant »). Il s'agit d'une étape de pré-résolution (statique) effectuée avant l'étape B37 d'insertion. Le premier dispositif DV1 peut ainsi insérer, dans chaque objet-méthode OBM appelant, les données de position DP correspondant à au moins un autre objet-méthode OBM appelé par l'objet-méthode appelant. [0175] Au cours d'une étape B38 d'envoi (figure 4), le premier dispositif DV1 renvoie les objets-méthodes OBM comportant les données de position DP au deuxième dispositif DV2. Pour ce faire, le premier dispositif DV1 peut transmettre (B38) ces objets-méthodes OBM progressivement, l'un après l'autre ou par paquets, au deuxième dispositif DV2. Dans l'exemple considéré, chaque objet-méthode OBM est transmis (B38) au deuxième dispositif DV2 dans une commande CMD3, accompagné de la référence d'objet AD2 (déjà mentionnée ci-avant) indiquant où l'objet-méthode OBM doit être enregistré en mémoire dans le deuxième dispositif DV2. [0176] Le deuxième dispositif DV2 charge (A54) dans sa mémoire MR2 les objets- méthodes OBM transmis en B38 par le premier dispositif DV1. [0177] En outre, le premier dispositif DV1 supprime (B39) les données de position DP de sa mémoire MR1 une fois que ces données de position DP ont été transmises (B38), au sein des objets-méthodes, dans la mémoire MR2. Dans cc cas, les données de position DP ne sont donc pas conservées de façon persistante dans la première mémoire MR1 comme cela est le cas dans le premier mode de réalisation représenté en figure 3. [0178] A l'issue de l'étape A38 d'envoi, la mémoire MR2 contient ainsi les objets-méthodes OBM générés en B12, dans lesquels ont été insérés des données de position DP respectives permettant de retrouver à partir d'un objet-méthode appelant au moins un objet-méthode appelé dans le flux d'exécution des objets-méthodes. [0179] Des données de position DP peuvent également être insérées dans les objets-données OBDT de façon analogue à ce qui est décrit ci-dessus en référence aux objets-méthodes OBM. [0180] Toujours dans ce deuxième mode de réalisation représenté en figure 4, les étapes A28-A30 et les étapes B18-B34 sont ensuite réalisées lors de l'exécution de l'application APP1 de façon identique à ce qui est décrit précédemment en référence à la figure 3. [0181] Dans ce deuxième mode de réalisation représenté en figure 4, on ne garde donc pas les données de position DP dans une structure additionnelle dans la mémoire MR1 du premier dispositif DVI. Lors de l'exécution, le premier dispositif DV1 détermine à partir des données de position DP présentes dans le bytecode d'un objet-méthode appelant le ou les objets-méthodes appelés dans le flux d'exécution. Le premier dispositif DV1 peut ainsi être plus rapide à l'exécution de l'application APP1 dans la 29 mesure où r i ntcrpréteur n'a pas besoin de consulter une structure additionnelle (de type « constant pool » par exemple) pour retrouver les objets-méthodes à exécuter. De plus, cette solution permet d'économiser l'espace mémoire qui serait sinon nécessaire dans la mémoire MR1 pour stocker une telle structure additionnelle comportant les données de position DP. [0182] A noter que l'insertion (B37) des données de position DP n'est réalisée que dans les objets-méthodes OBM correspondant à des méthodes statiques, c'est-à-dire dans les objets-méthodes dont il est possible, avant exécution de l'application, de déterminer le ou les objets-méthodes qui sont appelés (pré-résolution statique). [0183] Dans le cas où le premier dispositif DVI ne peut pas déterminer avant exécution de l'application APP1 quel objet-méthode est appelé par un objet-méthode OBM donné, cela signifie qu'une pré-résolution statique n'est pas possible. Un tel objet-méthode correspond alors à une méthode MT dite « virtuelle ». C'est le cas par exemple en langage Java Card ou Java pour le bytecode « invokevinual ». Dans le cas d'une méthode MT virtuelle, le premier dispositif DVI n'insère pas de données de position DP dans l'objet-méthode OBM concerné comme précédemment décrit. [0184] Selon une variante représentée schématiquement en figure 7, on améliore aussi la lo- calisation pour les méthodes non statiques. Le bytecode d'un appel à une méthode virtuelle prend sur la pile d'exécution 30 une référence d'objet, depuis laquelle le premier dispositif DVI récupère une information de classe. La classe correspondante contient une table des méthodes. Selon cette variante, le premier dispositif DVI insère, lors de l'étape d'insertion B37 (figure 4) de l'application APP1, les données de position DP de l'objet méthode OBM dans la table des méthodes de cette classe. Dans le cas par exemple du langage Java Card, le premier dispositif DV1 remplace notamment l'entrée 32 dans la table « public_vinual_methad_tablen » présente par exemple dans une partie de l'application APP1 propre aux classes (class component). [0185] Cette variante permet également d'économiser l'espace mémoire volatile MR1 utilisé car l'interpréteur n'a pas besoin d'une structure additionnelle pour retrouver les objets-méthodes à exécuter. Elle permet également de ne pas augmenter davantage le temps d'exécution car elle ne nécessite pas d'indirection supplémentaire pour atteindre la référence d'un objet méthode OBM. [0186] Par ailleurs, on notera que dans les modes de réalisation décrits ci-avant, c'est le premier dispositif DVI qui réalise les étapes B8-B34 (figures 3 et 4) et éventuellement B36-B39 (figure 4), de sorte que l'usage du troisième dispositif DV3 (ligure 1) n'est pas nécessaire. Selon une variante, les étapes B8 à B15 (figure 3), voire B8 à B39 ( figure 4) sont réalisées par le troisième dispositif DV3. Autrement dit, les objets-méthodes OBM sont créés puis transmis au deuxième dispositif DV2 par le troisième dispositif DV3. Les étapes B19 à B34 à l'exécution de l'application APP1 sont toujours réalisées par le premier dispositif DVI. Dans ce cas, c'est donc le premier système SZ, comportant les dispositifs DVI et DV3, qui réalisent le procédé de l' invention. [0187] Un exemple de mécanisme d'éviction est à présent décrit en référence aux figures 8 et 9. [0188] Typiquement, comme déjà indiqué, la taille de la mémoire volatile MR1 (figure 1) ne permet pas de charger en même temps toutes les méthodes MT1-MT5 dans la mémoire MR1 (étape B10, figures 3-4) ou encore d'allouer en même temps tous les objets-méthodes OBM1-0BM5 dans la mémoire MR1 (B12, figures 3-4). Un mécanisme d'éviction peut donc être mis en oeuvre par le premier dispositif DV1 pour libérer progressivement de l'espace mémoire dans la mémoire MR1. [0189] Un tel mécanisme d'éviction est illustré en figure 8, selon un mode de réalisation particulier. Dans cet exemple, lors de l'étape B8 de chargement initial, pour chaque méthode MT qu'il est nécessaire de charger en B10, le premier dispositif DVI détermine (B40) au préalable s'il dispose d'un espace suffisant dans sa mémoire volatile MR1 pour enregistrer la méthode MT, ainsi que les autres éléments associés qu'il est nécessaire de générer, à savoir : l'objet-méthode OBM, les données de position DP et éventuellement les données de localisation DL (si celles-ci sont générées lors de l'étape B8 de chargement initial). [0190] Selon un exemple particulier, le premier dispositif DV1 réalise la détermination B40 collectivement pour une pluralité de méthodes MT à charger. [0191] Le premier dispositif DVI peut par exemple déterminer en B40 (figure 8) qu'il dispose d'un espace insuffisant si l'espace libre est inférieur à une valeur seuil prédéterminée, ou éventuellement en fonction de la taille du ou des méthodes MT à charger. Diverses implémentations sont possibles. [0192] Si le premier dispositif DVI détermine en B42 (figure 8) qu'il dispose d'un espace suffisant, alors il procède à l'étape B8 de chargement initial et aux étapes suivantes comme déjà décrit ci-avant en référence aux figures 3-4. Dans le cas contraire (espace insuffisant), le premier dispositif DVI réalise une étape B44 d'éviction au cours de laquelle il met en oeuvre un mécanisme (ou algorithme) d'éviction pour supprimer (évincer) un ou des éléments (des objets par exemple) de sa mémoire volatile MR1 afin de libérer l'espace mémoire nécessaire. [0193] Selon un exemple particulier, lors de ce mécanisme d'éviction B44, le premier dispositif DVI supprime au moins un objet déjà stocké dans la mémoire volatile MR1 pour libérer un espace mémoire suffisant pour charger une ou d'autres méthodes MT, ainsi que les données associées (les objets-méthodes OBM, leurs données de position DP et éventuellement leurs données de localisation DL). [0194] Plus précisément, le premier dispositif détermine (B46) le ou les éléments à 31 supprimer conformément à des règles de priorité prédéterminées, ces règles définissant des niveaux de priorité associés à différents types d'éléments susceptibles d'être stockés dans la mémoire volatile MR1. Si un espace suffisant ne peut être libéré, le processeur 2 du premier dispositif DVI émet un message d'erreur (exception mémoire). Dans le cas contraire, le premier dispositif DV1 évince (B48) de la mémoire volatile MR1 les éléments identifiés en B46. [0195] Les éléments ainsi évincés peuvent être au moins l'un parmi des objets-méthodes OBM ou des objets-données OBDT précédemment alloués, ou encore les objets de localisation DL associées. Lorsqu'un objet-méthode est par exemple évincé en B48 ( figure 8), le premier dispositif supprime (B50) également les données de localisation DL associées. En revanche, comme déjà décrit, le premier dispositif DVI conserve dans sa mémoire volatile MR1 les données de position DP associées à chaque objet-méthode OBM précédemment généré lors de l'étape B12 de génération (figures 3-4), afin de pouvoir récupérer si besoin des objets-méthodes depuis la mémoire MR2 (ou MR3) du deuxième dispositif DV2. [0196] Une fois le mécanisme d'éviction B44 exécuté, le premier dispositif DVI réalise l'étape B8 de chargement initial (figures 3-4) comme déjà décrit précédemment. [0197] Si l'on se place dans la variante incluant un troisième dispositif DV3, ce dernier sera alors en charge du prédécoupagc des méthodes MT en objets-méthodes OBM (étape B8), le premier dispositif DVI mettant en oeuvre le mécanisme d'éviction déjà décrit. [0198] Par ailleurs, comme illustré en figure 9, un mécanisme d'éviction analogue à celui représenté en figure 8 peut être mis en oeuvre par le premier dispositif DVI lors de l'étape B26 d'allocation (figures 3-4). [0199] Plus précisément, lors de l'étape B26 d'allocation, pour chaque objet-méthode OBM qu'il est nécessaire de charger, le premier dispositif DVI détermine (B60) au préalable s'il dispose d'un espace suffisant dans sa mémoire volatile MR1 pour enregistrer l'objet-méthode OBM désiré et ses données de localisation DL. [0200] Selon un exemple particulier, le premier dispositif DV1 réalise la détermination B60 collectivement pour une pluralité d'objet-méthodes OBM à charger. [0201] Le premier dispositif DVI peut par exemple déterminer en B62 (figure 9) qu'il dispose d'un espace insuffisant si l'espace libre est inférieur à une valeur seuil prédéterminée, ou éventuellement en fonction de la taille du ou des objets-méthodes OBM à charger (en tenant compte éventuellement aussi de la taille estimée des données de localisation DL). Diverses implémentations sont possibles. [0202] Si le premier dispositif DVI détermine en B62 (figure 9) qu'il dispose d'un espace suffisant, alors il procède à l'étape B28 d'allocation et aux étapes suivantes comme déjà décrit ci-avant en référence aux figures 3-4. Dans le cas contraire, le premier dispositif DVI met en oeuvre un mécanisme (ou algorithme) B64 d'éviction au cours 32 duquel il supprime (B68) au moins un autre objet déjà stocké dans la mémoire volatile MR1 pour libérer un espace mémoire suffisant pour enregistrer chaque objet-méthode OBM remonté depuis la mémoire du deuxième dispositif DV2. [0203] Selon un exemple particulier, lors de cc mécanisme d'éviction, le premier dispositif DVI supprime au moins un autre objet déjà stocké dans la mémoire volatile MR1 pour libérer un espace mémoire suffisant pour enregistrer le ou les objets-méthodes OBM à charger, ainsi que les données de localisation DL associées. [0204] Plus précisément, le premier dispositif détermine (identifie) en B66 le ou les objets à supprimer conformément à des règles de priorité prédéterminées, ces règles définissant des niveaux de priorité associés à différents types d'éléments susceptible d'être stockés dans la mémoire volatile MR1. Si un espace suffisant ne peut être libéré, le processeur 2 du premier dispositif DVI émet un message d'erreur (exception mémoire). Dans le cas contraire, le premier dispositif DV1 évince (B68) de la mémoire volatile MR1 les éléments identifiés en B66. [0205] Les éléments (ou objets) ainsi évincés peuvent être au moins l'un parmi des objets- méthodes OBM ou des objets-données OBDT précédemment alloués, ou encore les données de localisation DL associées. Pour chaque objet-méthode OBM supprimé (B68) de la mémoire volatile MR1 par le mécanisme d'éviction, le premier dispositif DVI supprime (B70) les données de localisation DL de l'objet-méthode considéré. En revanche, comme déjà décrit, le premier dispositif DV1 conserve dans sa mémoire volatile MR1 les données de position DP associées à chaque objet-méthode OBM précédemment alloué lors de l'étape B8 de chargement initial (figures 3 et 4). [0206] Une fois le mécanisme d'éviction B64 exécuté, le premier dispositif DVI réalise l'étape B26 d'allocation (figures 3-4) comme déjà décht précédemment. [0207] Par ailleurs, lors de l'exécution B34 (figures 3-4) d'un objet-méthode OBM invoqué dans le code interprétable orienté objet de l'application APP1, le premier dispositif DVI peut être amené à réaliser des opérations d'écriture sur l'objet-méthode OBM correspondant (et/ou sur des objets autres tels que des objets-données), c'est-à-dire réaliser des modifications de l'objet-méthode OBM considéré. Ces modifications sont réalisées directement sur la version dite « clone » de l'objet-méthode OBM présente dans la mémoire volatile MRI du premier dispositif DVI. Le premier dispositif DV1 est en outre configuré pour modifier de façon identique la version de ce même objet-méthode OBM présente dans la mémoire non volatile MR2 du deuxième dispositif DV2 (ou éventuellement dans sa mémoire volatile MR3). [0208] Plus précisément, comme illustré en figure 10, on suppose que le premier dispositif DVI réalise une opération d'écriture (B80) au cours de laquelle il modifie (B81), dans la mémoire volatile MR1, l'objet-méthode OBMI en objet-méthode modifié OBMia. Autrement dit, le premier dispositif DVI réalise une opération d'écriture sur cet objet- 33 méthode OBM1 pour produire l'objet-méthode modifié OBM1a. La modification, notée MF, subie par l'objet-méthode OBMI lors de cette opération d'écriture peut être quelconque. [0209] Le premier dispositif DVI détermine (B83) alors la position où est enregistré l'objet-méthode OBM1 dans la mémoire non volatile MR2 (ou éventuellement dans la mémoire volatile MR3) du deuxième dispositif DV2. Pour ce faire, le premier dispositif DVI récupère la localisation de l'objet-méthode OBM1 à partir des données de position DP présentes dans l'objet-méthode OBM1 (précédemment insérées à l'étape B37), ou éventuellement dans un objet donné qui contient la table des méthodes. [0210] Au cours d'une étape B84 d'envoi, le premier dispositif DVI envoie au deuxième dispositif DV2 une commande d'écriture CMD4 spécifiant la modification MF qui a été réalisée pour modifier l'objet-méthode OBM1 en OBM1a. Cette commande CMD4 peut comprendre la référence objet AD2 contenue dans les données de localisation DL1 associées à l'objet-méthode OBMI , ainsi que l'objet-méthode modifiée OBM1a (ou toute autre information représentative de la modification MF réalisée en B81). [0211] Le deuxième dispositif DV2 reçoit la commande CMD4 en A84 (figure 10) et, en réponse à cette commande, enregistre (A86) la version modifiée OBM1a dans sa mémoire MR2 (ou éventuellement dans la mémoire volatile MR3) en remplacement de l'objet-méthode OBM1. [0212] Un procédé identique peut être réalisé lorsque le premier dispositif DVI apporte des modifications à des objets-données dans sa mémoire volatile MRI. [0213] 11 est ainsi possible d'assurer la cohérence entre les objets stockés dans la mémoire volatiles MR1 et ceux stockés en mémoire MR2 dans le deuxième dispositif DV2. Chaque modification apportée aux objets stockés dans la mémoire volatile MR1 du premier dispositif DVI est répercutée dans la mémoire non volatile MR2 (ou dans la mémoire volatile MR3) du deuxième dispositif DV2. Ainsi, si un objet est par la suite évincé de la mémoire volatile MR1 du premier dispositif DVI, il est possible de récupérer ultérieurement la bonne version de l'objet depuis la mémoire du deuxième dispositif DV2. [0214] Par ailleurs, comme déjà indiqué, la manière dont le premier dispositif DVI met en oeuvre une machine virtuelle pour interpréter le code exécutable de l'application APP1 (B19, figures 3-4) à partir d'une pile d'exécution est bien connue de l'homme du métier. En particulier, la machine virtuelle détecte des objets en lisant le code interprétable et place (empile) les références d'objet dans une pile d'exécution. [0215] Un mode particulier de réalisation est à présent décrit en référence à la figure 11. Au cours de l'interprétation B19 (figures 3-4) du code interprétable orienté objet, le premier dispositif DVI réalise une lecture de la pile d'exécution au cours d'une 34 première étape B90. Lors de cette étape de lecture (B90), lorsque le premier dispositif DVI détecte (B92) une référence d'un objet sur la pile d'exécution, il exécute (B94) une action sécuritaire pour bloquer l'accès dc cet objet-méthode OBM à une application. Il peut s'agir d'une référence à un objet-méthode OBM ou, le cas échéant, à un objet de localisation comme décrit précédemment. [0216] Le premier dispositif DVI détecte par exemple en B92 que l'objet référencé dans la pile d'exécution est un objet-méthode OBM à partir de la donnée de type DN1 contenue dans les métadonnées de l'objet-méthode OBM, comme précédemment décrit en référence notamment à la figure 5. [0217] Le premier dispositif peut détecter que l'objet référencé est un objet de localisation de façon analogue, à partir d'une donnée de type contenue dans les métadonnées de l'objet de localisation, comme précédemment décrit. [0218] En effet, les objets-méthodes et, le cas échéant les objets de localisation, sont des objets particuliers qui sont créés par le système du premier dispositif DV1 mais auxquelles aucune application ne devrait jamais accéder par elle-même pour des raisons de sécurité. Un logiciel malveillant pourrait par exemple récupérer la référence d'un objet-méthode OBM depuis la pile d'exécution et modifier le contenu de cet objet (bytecode) pour endommager l'application APPl. De même, un risque existe qu'un tel logiciel récupère dans la pile d'exécution la référence d'un objet dc relocalisation afin de fausser l'adresse de l'objet correspondant dans la mémoire non volatile MR2 du deuxième dispositif DV2, en vue par exemple de réaliser des opérations illicites en écriture et/ou en lecture. [0219] Il est ainsi possible de sécuriser l'accès aux objets-méthodes OBM et aux objets de localisation par de quelconques applications susceptibles d'être exécutées dans le premier dispositif DVI. Pour ce faire, le premier dispositif DVI peut réaliser une action sécuritaire pour empêcher l'accès par une application à la référence d'un objet-méthode ou à un objet de localisation dans la pile d'exécution. Pour renforcer la sécurité de ces objets, le premier dispositif DV1 peut ainsi être configuré pour interdire d'empiler des références à de tels objets sur la pile d'exécution. De la même façon, le premier dispositif DVI peut être configuré pour interdire de déréférencer (lors du dépilement) de tels objets. Les objets-méthodes dont on souhaite protéger l'accès peuvent être dans la mémoire volatile MR1 du premier dispositif DVI ou dans la mémoire non volatile MR2 (ou éventuellement la mémoire volatile MR3) du deuxième dispositif DV2. [0220] Par ailleurs, comme déjà décrit, des données de localisation DL peuvent être enre- gistrées sous forme d'un objet de localisation dans la mémoire volatile MR1 pour chaque objet-méthode OBM alloué par le premier dispositif DV1. Selon un exemple particulier, chaque objet-méthode OBM et chaque objet de localisation DL générés par le premier dispositif DV1 sont enregistrés ensemble dans un même conteneur mémoire dans la mémoire volatile MR1. [0221] Dans le présent document, un conteneur mémoire est une abstraction logiciel d'un espace mémoire physique, généralement borné en taille (exemple: le tas d'objet est un conteneur d'objet). Le système d'exploitation (OS) du premier dispositif DV1 est typiquement en charge de fournir des routines d'allocation et de libération pour utiliser ce conteneur. [0222] Plus généralement, le premier dispositif DV1 peut stocker dans sa mémoire volatile MR1 divers types d'objet, à savoir des objets-méthodes, des objets de localisation, d'autres objets contenant des données récupérées dans la mémoire non volatile MR2, et/ou des objets transitoires comportant des données générées ponctuellement par le premier dispositif DV1 pour exécuter l'application APP1 et qui sont effacées par la suite. Le premier dispositif DV1 peut être configure pour stocker tous ces objets dans un même conteneur de sa mémoire volatile MR1. [0223] En faisant cohabiter tous ces objets dans un même conteneur mémoire dans la mémoire volatile MR1, on permet une utilisation maximale de la mémoire volatile MR1 par rapport à une solution basée sur de la segmentation mémoire. En effet, une segmentation suppose de créer statiquement plusieurs conteneurs, à savoir au moins : un conteneur pour les données de localisation DL, un conteneur pour les objets-méthodes, et un conteneur pour les objets transitoires. Il est cependant difficile d'estimer à l'avance les tailles optimales pour chacun de ces conteneurs. Le nombre d'objets qui sont chargés dans la mémoire volatile MR1 dépend notamment des commandes exécutées lors de l'exécution de l'application. Une exécution est donc plus performante en consommation mémoire si l'on fait cohabiter les objets précités dans un même conteneur mémoire. [0224] Un homme du métier comprendra que les modes de réalisation et variantes décrits cl- avant ne constituent que des exemples non limitatifs de mise en oeuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier. 36 [Revendication 1] REVENDICATIONSProcédé, mis en oeuvre par un premier système comportant un premier dispositif électronique (DV1) comportant une première mémoire (MR1), ledit premier dispositif électronique coopérant avec un deuxième dispositif électronique (DV2) comportant une deuxième mémoire (MR2), le procédé comprenant : une étape de chargement initial (B8) comprenant : acquisition (B10) d'une application (APP1) comportant du code interprétable orienté objet, définissant une pluralité de méthodes (MT) exécutables ; génération (B12) dans la première mémoire, pour chaque méthode du code interprétable, d'un objet distinct (OBM) dit objet-méthode ; une étape d'envoi (B15) de chaque objet-méthode (OBM) au deuxième dispositif électronique (DV2) pour enregistrement dans la deuxième mémoire (MR2) ; une étape d'interprétation (B18) comprenant : interprétation (B19) du code interprétable de l'application (APP1) ; identification (B20), à partir de ladite interprétation, d'au moins un objet-méthode (OBM1) invoqué dans le code interprétable ; et une étape d'allocation (B26) dans la première mémoire, pour chaque objet-méthode (OBM) invoqué qui n'est pas stockée dans la première mémoire (MR1), comprenant : récupération (B28), depuis la deuxième mémoire (MR2), dudit objet-méthode ; et enregistrement (B30), dans la première mémoire (MR1), dudit objet-méthode récupéré depuis la deuxième mémoire, pour en permettre un accès par le premier dispositif électronique. [Revendication 2] Procédé selon la revendication 1, dans lequel, lors de l'étape dc chargement initial, le premier système (DV1) reçoit une application 37 [Revendication 3] [Revendication 4] [Revendication 5] (APP1) qui est chargée dans la deuxième mémoire (MR2) du deuxième dispositif électronique (DV2) ou dans une mémoire volatile (MR3) du deuxième dispositif électronique (DV2). Procédé selon la revendication 1 ou 2, dans lequel ladite étape de chargement initial (B8) comprend, pour chaque méthode du code interprétable: chargement dans la première mémoire (MR1) de ladite méthode du code interprétable ; et génération dans la première mémoire d'un objet-méthode correspondant, sous la forme d'une structure de données prédéterminée comprenant un entête et un corps d'objet ; dans lequel le corps d'objet comprend du code interprétable orienté objet (DN3) définissant l'objet-méthode. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel ladite étape de chargement initial est réalisée à partir d'une première partie (CP1) et d'un deuxième partie (CP2) qui sont compris dans l'application (APP1) chargée dans le deuxième dispositif électronique (DV2) lors de ladite étape de chargement initial, la première partie (CP1) comportant une concaténation de la pluralité de méthodes (MT) de l'application, et la deuxième partie (CP2) comportant des indications de position (DN5) indiquant une position respective de chaque méthode dans la première partie (CP1). Procédé selon l'une quelconque des revendications 1 à 4, dans lequel le procédé comprend, lors de l'étape d'interprétation : vérification (B22), pour chaque objet-méthode invoqué, de si ledit objet-méthode (OBM) est stocké dans la première mémoire (MR1), [Revendication 6] le premier dispositif électronique procédant à ladite allocation pour l'objet-méthode invoqué seulement si ledit objet-méthode n'est pas stocké dans la mémoire volatile (MR1). Procédé selon la revendication 5, dans lequel, lors de l'étape d'interprétation, le premier dispositif électronique (DV1) détermine, pour chaque objet-méthode invoqué, que ledit objet-méthode (OBM) est stocké dans la première mémoire (MR1) s'il détecte des données de localisation (DL), enregistrées (B13) dans la première mémoire (MR1). 38 [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11] comprenant une première référence d'objet (AD1) indiquant où l'objet-méthode est enregistré dans la première mémoire (MR1) et une deuxième référence d'objet (AD2) indiquant où l'objet-méthode est enregistré dans la deuxième mémoire (MR2) dans le deuxième dispositif électronique (DV2). Procédé selon la revendication 6, dans lequel, lors de l'étape d' interprétation, le premier dispositif électronique (DV1) détermine, pour chaque objet-méthode invoqué, que ledit objet-méthode (OBM) n'est pas stocké dans la mémoire volatile (MR1) s'il ne détecte pas de dites données de localisation (DL) dans la mémoire volatile (MR1). Procédé selon la revendication 6 ou 7, dans lequel pour chaque objet-méthode (OBM) récupéré et enregistré dans la mémoire volatile (MR1) lors de ladite étape d'allocation, le premier dispositif enregistre (B32), dans la mémoire volatile (MR1), des dites données de localisation (DL) comprenant une première référence d'objet (AD1) indiquant où l'objet-méthode est enregistré dans la mémoire volatile (MR1) et une deuxième référence d'objet (AD2) indiquant où l'objet-méthode est enregistré en mémoire (MR2) dans le deuxième dispositif électronique (DV2). Procédé selon la revendication 8, dans lequel les données de localisation (DL) de chaque objet-méthode (OBM) stocké dans la mémoire volatile (MR1) sont enregistrées, dans la mémoire volatile (MR1), en tant qu'objet de données, dit objet de localisation, propre audit objet-méthode. Procédé selon la revendication 9, dans lequel chaque objet-méthode (OBM) et chaque objet de localisation (DL) sont enregistrés ensemble dans un même conteneur mémoire dans la mémoire volatile. Procédé selon l'une quelconque des revendications 6 à 10, dans lequel, sur détection (B62) lors de ladite étape d'allocation que la mémoire volatile (MR1) ne dispose pas d'un espace mémoire suffisant pour enregistrer chaque objet-méthode invoqué, le premier dispositif électronique (DV1) réalise un mécanisme d'éviction (B64) au cours duquel il supprime (B68) au moins un autre objet déjà stocké dans la première mémoire (MR1) pour libérer un espace mémoire suffisant pour enregistrer chaque objet-méthode invoqué, dans lequel pour chaque objet-méthode supprimé de la mémoire volatile (MR1) par le mécanisme d'éviction, le premier dispositif électronique (DV1) supprime (B50 ; B70) les données de localisation (DL) dudit 39 [Revendication 12] [Revendication 13] objet-méthode. Procédé selon l'une quelconque des revendications 6 à 11, dans lequel ledit procédé comprend une opération d'écriture (B80) comprenant : modification (B81) d'un objet-méthode (0BM1) stocké dans la première mémoire (MR1) ; détermination (B83) de la position où est enregistré l'objet-méthode dans la deuxième mémoire (MR2) ; et envoi (B84) d'une commande d'écriture (CMD4) spécifiant ladite modification dudit objet-méthode pour modifier ledit objet-méthode stockée à ladite localisation dans la mémoire non volatile (MR2). Procédé selon l'une quelconque des revendications 1 à 12, dans lequel lors de ladite récupération (B28), le premier dispositif électronique (DV1) envoie (B28) au deuxième dispositif électronique (DV2) au moins une commande de lecture (CMD2) spécifiant : ledit objet-méthode, dit objet-méthode récupéré, qui est invoqué et qui n'est pas stocké dans la mémoire volatile (MR1); ct [Revendication 14] [Revendication 15] [Revendication 16] une adresse de destination respective à laquelle ledit objet-méthode récupéré doit être enregistré dans une mémoire intermédiaire à laquelle le premier dispositif électronique (DV1) a accès. Procédé selon l'une quelconque des revendications 1 à 13, comprenant en outre une exécution (B34) dudit au moins un objet-méthode (OBM) invoqué, stocké dans la mémoire volatile (MR1). Procédé selon la revendication 14, dans lequel le procédé comprend, suite à ladite exécution (B34), une détection ultérieure que ledit au moins un objet-méthode invoqué est à nouveau invoqué en association avec ladite application (APP1), et une opération de lecture (B24) de la mémoire volatile (MR1) pour exécuter ledit au moins un objet-méthode invoqué, stocké dans la mémoire volatile (MR1). Procédé selon l'une quelconque des revendications 1 à 15, dans lequel le premier dispositif électronique (DV1) comprend une machine virtuelle apte à interpréter le code interprétable de l'application (APP1) à partir d'une pile d'exécution, le procédé comprenant : 40 [Revendication 17] [Revendication 18] [Revendication 19] [Revendication 20] sur détection (B92) d'une référence d'un objet-méthode sur la pile d'exécution, exécution (B94) d'une action sécuritaire pour bloquer son accès à une application. dans lequel le premier dispositif électronique (DV1) détecte que l'objet référencé dans la pile d'exécution est un objet-méthode à partir de la donnée de type (DN1) contenue dans les métadonnécs de l'objet-méthode. Procédé selon l'une quelconque des revendications 1 à 16, dans lequel le premier dispositif électronique et le deuxième dispositif électronique forment un seul et même dispositif électronique ou sont deux dispositifs électroniques distincts. Programme d'ordinateur (PG1) comportant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 17 lorsque ledit programme est exécuté par un ordinateur. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (P01) comprenant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 17. Système (DV1, DV3), dit premier système, comprenant un premier dispositif électronique (DV1) comportant une première mémoire (MR1), et configuré pour coopérer avec un deuxième dispositif électronique (DV2) comportant une deuxième mémoire (MR2), le premier système comprenant, pour réaliser un chargement initial : un module d'acquisition (MD2) configuré pour acquérir une application (APP1) comportant du code interprétable orienté objet, définissant une pluralité de méthodes (MT) exécutables ; un module de génération (MD4) configuré pour générer dans la première mémoire, pour chaque méthode du code interprétable, un objet distinct (OBM) dit objet-méthode ; un module d'envoi (MD6) configuré pour envoyer chaque objet-méthode au deuxième dispositif pour enregistrement dans la mémoire non volatile (MR2) ; le premier dispositif électronique (DVI) comprenant en outre, pour réaliser une interprétation : un module d'interprétation (MD8) configuré pour interpréter le code interprétable de l'application (APP1) ; 41 un module d'identification (MD10) configure pour identifier, à partir d'une interprétation du code interprétable réalisée par le module d'interprétation, au moins un objet-méthode (0BM1) invoqué dans le code interprétable ; un module de traitement (MD12) configure pour réaliser une allocation dans la première mémoire, pour chaque objet-méthode (0BM) invoqué qui n'est pas stocké dans la mémoire volatile (MR1), de sorte à : - récupérer, depuis la deuxième mémoire (MR2), ledit objet-méthode ; et - enregistrer, dans la première mémoire (MR1), ledit objet-méthode récupéré depuis la deuxième mémoire, pour en pet-mettre un accès par le premier dispositif électronique. [Revendication 21] Système (SY), dit deuxième système, comprenant : un premier système (SZ) selon la revendication 20; et ledit deuxième dispositif électronique (DV2), comportant une deuxième mémoire (MR2), étant configuré pour coopérer avec le premier système (SZ).