Brevet FR3105853A1 — publié le 20210702

Système embarqué La présente description concerne un procédé de lecture et/ou d'écriture de données ou de commandes d’au moins une application (12, 13, 14) dans une mémoire non volatile (15) d'un système embarqué (10), dans lequel les données ou commandes transitent par une zone mémoire (16) et sont interprétées par un programme distinct d’un système d’exploitation du système embarqué. Figure pour l'abrégé : Fig. 6 Système embarqué La présente description concerne de façon générale les systèmes électroniques, et, en particulier, les systèmes électroniques embarqués. La présente description concerne plus précisément les systèmes électroniques embarqués adaptés à mettre en oeuvre au moins une application. Les systèmes électroniques embarqués, ou systèmes embarqués, sont des systèmes électroniques autonomes généralement spécialisés dans une ou plusieurs tâches précises. Un système embarqué est généralement mis en oeuvre par un système d'exploitation (operating system, OS). De plus en plus de systèmes embarqués sont adaptés à mettre en oeuvre plusieurs tâches précises. Pour cela, leur système d'exploitation est adapté à mettre en oeuvre plusieurs applications. Il serait souhaitable de pouvoir améliorer, au moins en partie, certains aspects des systèmes embarqués connus dont le système d'exploitation est adapté à mettre en oeuvre une ou plusieurs applications. Il existe un besoin pour des systèmes embarqués plus fiables. Il existe un besoin pour des systèmes embarqués plus fiables dont le système d'exploitation est adapté à mettre en oeuvre une ou plusieurs applications. Il existe un besoin pour des systèmes embarqués dont les données (commandes et données) des différentes applications sont stockées plus efficacement dans une mémoire. Un mode de réalisation pallie tout ou partie des inconvénients des systèmes embarqués connus. Un mode de réalisation prévoit une solution plus particulièrement adaptée à un système dont le système d'exploitation est adapté à mettre en oeuvre plusieurs applications. Un mode de réalisation prévoit un procédé de démarrage d'un système embarqué, dans lequel des premières commandes, distinctes de commandes d’un système d’exploitation du système embarqué, sont exécutées pour provoquer le stockage d’au moins une application dans une mémoire non volatile. Selon un mode de réalisation, les premières commandes sont stockées dans une zone de mémoire non volatile. Selon un mode de réalisation, des deuxièmes commandes de plusieurs applications sont stockées dans ladite zone. Selon un mode de réalisation, lesdites premières commandes sont ou exécutent des commandes de personnalisation et/ou de configuration de la ou des applications. Selon un mode de réalisation, la ou les applications sont adaptées à générer les adresses auxquelles des données sont stockées dans ladite mémoire. Un mode de réalisation prévoit un système embarqué, comportant une zone de stockage de premières commandes, distinctes de commandes d’un système d’exploitation, dans laquelle sont stockées des deuxièmes commandes d’au moins une application, les premières commandes étant destinées à provoquer le stockage de ladite au moins une application dans une mémoire non volatile au démarrage du système embarqué. Selon un mode de réalisation, au moins deux applications sont mises en oeuvre par le système d'exploitation. Selon un mode de réalisation, lesdites premières commandes sont ou exécutent des commandes de personnalisation et/ou de configuration de la ou des applications. Selon un mode de réalisation, les applications sont adaptées à générer les adresses auxquelles elles stockent des données dans ladite mémoire. Selon un mode de réalisation, au moins une application est une application de paiement bancaire ou de transport. Un mode de réalisation prévoit une carte à puce adaptée à mettre en œuvre le procédé décrit. Un mode de réalisation prévoit une carte à puce comportant un système tel que décrit. Un mode de réalisation prévoit un procédé de lecture et/ou d'écriture de données ou de commandes d’au moins une application dans une mémoire non volatile d'un système embarqué, dans lequel les données ou commandes transitent par une zone mémoire et sont interprétées par un programme distinct d’un système d’exploitation du système embarqué. Selon un mode de réalisation, ladite zone est une zone de mémoire volatile. Selon un mode de réalisation, ladite zone est une zone de mémoire non volatile. Selon un mode de réalisation, ladite au moins une application est mise en oeuvre par le système d'exploitation. Selon un mode de réalisation, des commandes sont transférés d'une application à une autre via ladite zone. Selon un mode de réalisation, la ou les applications sont adaptées à stocker des données dans la mémoire. Selon un mode de réalisation, la ou les applications sont adaptées à générer les adresses auxquelles elles stockent des données dans ladite mémoire. Un mode de réalisation prévoit un système embarqué, adapté à mettre en oeuvre au moins une application stockée en mémoire non volatile, comprenant une zone mémoire et un programme, distinct d’un système d’exploitation, des données ou commandes de ladite au moins une application transitant par ladite zone pour être stockées dans ladite mémoire. Selon un mode de réalisation, ladite zone est une zone de mémoire volatile. Selon un mode de réalisation, ladite zone est une zone de mémoire non volatile. Selon un mode de réalisation, le système met en œuvre au moins deux applications. Selon un mode de réalisation, des données transitent d’une application à une autre via ladite zone mémoire. Selon un mode de réalisation, les applications sont adaptées à générer les adresses auxquelles elles stockent des données dans ladite mémoire. Selon un mode de réalisation, au moins une application est une application de paiement bancaire ou de transport. Un mode de réalisation prévoit une carte à puce adaptée à mettre en œuvre le procédé décrit. Un mode de réalisation prévoit une carte à puce comportant un système tel que décrit. Ces caractéristiques et avantages, ainsi que d'autres, seront exposés en détail dans la description suivante de modes de réalisation et de mise en oeuvre particuliers faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : la figure 1 représente, de façon très schématique et sous forme de blocs, un mode de réalisation d’un circuit électronique du type auquel s’appliquent les modes de réalisation et de mise en oeuvre décrits ; la figure 2 représente, de façon très schématique et sous forme de blocs, un autre mode de réalisation d’un circuit électronique du type auquel s’appliquent les modes de réalisation décrits ; la figure 3 représente, de façon très schématique et sous forme de blocs, un mode de mise en œuvre d’un procédé de gestion d’un circuit mémoire tel qu’illustré par la figure 2 ; la figure 4 illustre, schématiquement et sous forme de blocs fonctionnels, le mode de mise en œuvre du procédé de la figure 3 ; la figure 5 représente, de façon très schématique et sous forme de blocs, un mode de mise en œuvre d’un procédé de gestion d’un circuit mémoire tel qu’illustré par la figure 2 ; et la figure 6 illustre, schématiquement et sous forme de blocs fonctionnels, le mode de mise en œuvre du procédé de la figure 5. De mêmes éléments ont été désignés par de mêmes références dans les différentes figures. En particulier, les éléments structurels et/ou fonctionnels communs aux différents modes de réalisation peuvent présenter les mêmes références et peuvent disposer de propriétés structurelles, dimensionnelles et matérielles identiques. Par souci de clarté, seuls les étapes et éléments utiles à la compréhension des modes de réalisation décrits ont été représentés et sont détaillés. Sauf précision contraire, lorsque l'on fait référence à deux éléments connectés entre eux, cela signifie directement connectés sans éléments intermédiaires autres que des conducteurs, et lorsque l'on fait référence à deux éléments reliés (en anglais "coupled") entre eux, cela signifie que ces deux éléments peuvent être connectés ou être reliés par l'intermédiaire d'un ou plusieurs autres éléments. Dans la description qui suit, lorsque l'on fait référence à des qualificatifs de position absolue, tels que les termes "avant", "arrière", "haut", "bas", "gauche", "droite", etc., ou relative, tels que les termes "dessus", "dessous", "supérieur", "inférieur", etc., ou à des qualificatifs d'orientation, tels que les termes "horizontal", "vertical", etc., il est fait référence sauf précision contraire à l'orientation des figures. Sauf précision contraire, les expressions "environ", "approximativement", "sensiblement", et "de l'ordre de" signifient à 10 % près, de préférence à 5 % près. On désigne par "système d'exploitation" un ensemble de programmes ou logiciels permettant de faire fonctionner un système embarqué. Il s’agit du niveau le plus haut des programmes et logiciels que met en oeuvre le système embarqué. On désigne par "application" un programme ou logiciel adapté à être mis en oeuvre par un système d'exploitation. Il s’agit d’un programme ou logiciel de niveau inférieur au niveau du système d'exploitation. La figure 1 représente, de façon très schématique et sous forme de blocs, un mode de réalisation d’un circuit ou système électronique 100 du type auquel s’appliquent les modes de réalisation décrits. Le circuit électronique 100 comporte : - une ou plusieurs unité 110 de traitement numérique (PU), parmi lesquelles au moins un microprocesseur ; - une ou plusieurs mémoires de stockage volatil (RAM) 112 et non volatil (NVM) 115 de données et programmes ; - un ou plusieurs bus 114 de données, d'adresses et/ou de commandes entre les différents éléments internes au circuit 100 ; - une ou plusieurs interfaces 117 d'entrée-sortie (I/O) de communication avec ou sans fil avec l'extérieur du circuit 100 ; et - divers autres circuits en fonction de l'application, symbolisés en figure 1 par des blocs 116 (FCT). Le fonctionnement du microprocesseur 110 est régi par un système d’exploitation qui exploite, entre autres, des zones de mémoire non-volatile 115. Le circuit 100 est, par exemple intégré dans une carte à microcircuit (IC card) ou carte à puce (smartcard) avec ou sans contact. La figure 2 représente, de façon très schématique et sous forme de blocs, un autre mode de réalisation d’un circuit électronique du type auquel s’appliquent les modes de réalisation décrits. Le circuit de la figure 2 représente, de façon très schématique un exemple d’architecture d’une mémoire non volatile 15 (NVM). La mémoire 15 comporte, au moins fonctionnellement : - une ou plusieurs zones 152 de stockage de commandes (programmes) ou données d’applications devant être mise en œuvre par un système d’exploitation exécuté par le microprocesseur ou unité de traitement auquel la mémoire est associée ; - une zone 16 (SB) de stockage de commandes particulières correspondant à des commandes à exécuter au démarrage ou initialisation du circuit ou pour basculer d’une application à une autre ; et - un contrôleur mémoire 154 (CTRL) réalisant l’interface entre l’intérieur et l’extérieur de la mémoire 15. La zone 16 est destinée à contenir au moins un programme (script) 18 d’interprétation ou de conversion de commandes et/ou de données d'installation ou de configuration d'applications. Ces commandes et/ou données peuvent être stockées dans cette zone 16 ou, en variante, être stockées en mémoire volatile 112 ou en mémoire non volatile 15. La zone 16 est, par exemple, une zone dédiée du plan mémoire de mémoire non volatile dans lequel sont prévues la ou les zones 152, ou structurellement une région distincte de la mémoire 15, par exemple un registre. De préférence, fonctionnellement, la zone 16 contient à la fois des données d’application et un programme d’interprétation de ces données pour leur transfert en mémoire 15. La ou les zones 152 sont destinées à stocker des applications du système, c’est-à-dire des commandes et des données associées à des applications à mettre en œuvre. Il s’agit, par exemple, dans le cadre d’une carte à puce, d’applications de paiement (applications bancaires) ou de transport. La mémoire 15 est, de préférence, intégrée dans (est dans une puce commune avec) un circuit contenant également au moins une unité de traitement. La mémoire fait alors, par exemple, partie du circuit 100 (figure 1) et constitue une mémoire non volatile embarquée (embedded). La mémoire 15 peut, en variante, être un circuit électronique indépendant, destiné à être monté sur une carte électronique afin d’être exploitée par un microprocesseur distinct. Selon les modes de réalisation décrits, on prévoit, au niveau du système intégrant la mémoire 15 (ou 115, figure 1) et au moins une unité de traitement, un mécanisme ou programme 18 embarqué dans la mémoire, plus particulièrement stocké dans la zone 16. Cela se traduit par le stockage, dans la zone 16, de commandes d’interprétation exécutables 18, distinctes du système d’exploitation et des applications exécutées par le circuit. Selon un mode de réalisation, la zone ou bloc 16 contient des commandes 17 liées aux applications ainsi qu'un programme 18 interpréteur de ces commandes. Cet interpréteur est destiné à être exécuté par le système d'exploitation pour interpréter les commandes. Selon un autre mode de réalisation, la zone 16 contient uniquement un programme (script) 18 interpréteur de commandes 17 contenues en mémoire volatile, par exemple chargées depuis l'extérieur du système ou stocké en mémoire non volatile. Selon un autre mode de réalisation, le bloc 16 constitue un interpréteur 18 de commandes, adapté à exécuter des commandes 17 de configuration d'applications contenues dans la zone mémoire stockant l'interpréteur. L’exécution de ces commandes est alors déclenchée par le système d’exploitation. La figure 3 représente, de façon très schématique et sous forme de blocs, un mode de mise en œuvre d’un procédé de gestion d’un circuit mémoire tel qu’illustré par la figure 2. Selon ce mode de réalisation, l’interpréteur de commandes 18 est programmé à la fabrication du circuit, ou plus précisément, en fin de fabrication, dans une phase dite de pré-personnalisation. Cette programmation revient à stocker (bloc 31, STORE CONFIG/PERSO IN SB), dans la zone 16 et en fin de fabrication (FAB), des commandes 17 de configuration ou de personnalisation d’applications auxquelles est destiné le système embarqué ainsi qu’un interpréteur 18. Une fois le circuit fabriqué et pré-personnalisé en fonction du client auquel il est destiné, c’est-à-dire dont le zone 16 contient un programme (script) 18 de configuration et/ou de personnalisation des applications, celui-ci est fourni au client. Il ne s’agit pas de l’utilisateur final, mais de l’entité exploitant les applications, par exemple, l’application bancaire ou de transport. Lors du premier démarrage (START) du produit, le système d’exploitation provoque l’exécution (bloc 33, EXEC CONFIG/PERSO), par le programme interpréteur 18 contenu dans la zone 16, des commandes 17 de configuration ou de personnalisation contenues, par exemple, dans cette zone. Cela se traduit par un stockage (bloc 35, STORE IN NVM), dans la zone 152 (figure 2) de la mémoire non volatile 15, des commandes et données de la ou des applications en vue de leur exploitation par le système d’exploitation. Le système est alors prêt à fonctionner avec les applications stockées en mémoire non volatile 15. La figure 4 illustre, schématiquement et sous forme de blocs fonctionnels, le mode de mise en œuvre du procédé de la figure 3. On suppose que la zone 16 (SCRIPTBOX) contient les commandes et données de plusieurs applications, par exemple trois applications qui y ont été stockées en fin de fabrication. Toutefois le processus illustré par les figures 3 et 4 peut être mis en œuvre pour des système de mettant en œuvre qu’une seule application. La figure 4 illustre les trois éléments ou fonctions du système embarqué 10 qui interviennent pour la configuration ou personnalisation d’application(s) par la mise en oeuvre du procédé de la figure 3. On retrouve la mémoire non volatile 15 et, plus particulièrement, sa zone (152, figure 2) destinée à stocker les applications (les commandes et tout ou partie des données). On retrouve également, l’interpréteur 18 de commandes 17 et le système d’exploitation 11 (OS). On suppose que la mise en œuvre du procédé de la figure 3 conduit à stocker en mémoire non volatile trois applications 12 (App1), 13 (App2) et 14 (App3) dont tout ou partie des données de configuration ont été stockées, lors de la pré-personnalisation, dans la zone ou registre de commandes 16. A titre d'exemple, ces données sont des données 17 de configuration des applications. Selon un mode de réalisation, les applications stockent des données dans la même mémoire non volatile, par exemple toutes leurs données sont stockées dans la même mémoire non volatile. Les applications sont adaptées à générer les adresses auxquelles leurs données doivent être lues et/ou écrites dans la mémoire 15. Chaque application est, plus particulièrement, adaptée à générer des adresses dans lesquelles stocker ses propres données et commandes dans la mémoire 15 sans empiéter sur les adresses utilisées par les autres applications. En particulier, les adresses de stockage de données secrètes comme, par exemple, des clés de chiffrement, ne sont pas contenues dans, ni commues par, la zone 16. Au premier démarrage et/ou configuration (FIRST BOOT) du système embarqué 10, les commandes (c’est-à-dire le programme) stockées dans la zone 16 sont exécutées. Cette exécution conduit à configurer les applications 12, 13 et 14 dans la mémoire 15. Cette phase est mise en œuvre par le système d’exploitation 11 qui reçoit et exécute les commandes de la zone 16. Les commandes de configuration ou de personnalisation des applications ne contiennent de préférence pas l’ensemble des commandes des applications, mais des commandes permettant le stockage, en mémoire non volatile, de données secrètes comme des identifiants et des mots de passe, etc. En variante, la zone 16 stocke toutes les commandes destinées aux applications, puis les distribue auxdites applications pour qu'elles les exécutent. Un avantage de ce mode de réalisation est que, comme les adresses sont générées par les applications elles-mêmes, les commandes chargées dans la zone ou le registre 16 en fin de fabrication (étape 31) n’ont pas besoin de contenir d’adresses explicites. Cela évite de devoir prévoir, au niveau du système d’exploitation, des commandes sécurisées pour la personnalisation afin de garantir que les applications ne soient pas stockées aux mêmes adresses pour tous les circuits ou pour la personnalisation de clés. Cela simplifie la pré-personnalisation effectuée en fin de fabrication du système. En effet, les commandes et données des applications stockées dans la zone 16 peuvent désormais être les mêmes pour tous les circuits fabriqués. En d’autres termes, le stockage de la ou des applications dans la mémoire non volatile de chaque circuit fabriqué est organisé par des commandes contenues dans la zone dédiée 16 et ces commandes sont communes à tous les circuits fabriqués. Un fois le premier démarrage effectué, la zone de commandes 16 n’est plus utilisé pour la configuration des applications qui sont désormais en mémoire 15. Il peut, soit servir à mettre en œuvre le procédé de reconfiguration d’applications qui est décrit par la suite, soit ne plus être utilisé. Dans un mode de réalisation où l'interpréteur de commandes 18 n'est utilisé que dans la phase de personnalisation, la zone 16 en mémoire non volatile contient de préférence à la fois l'interpréteur 18 et les données ou commandes 17 à interpréter. On peut alors considérer que ces commandes 17 et les commandes 18 de l’interpréteur sont un même jeu de commandes. Cela permet, une fois la personnalisation effectuée, de libérer la zone 16 pour le stockage d'autres données d'applications. La figure 5 représente, de façon très schématique et sous forme de blocs, un mode de mise en œuvre d’un procédé de gestion d’un circuit mémoire tel qu’illustré par la figure 2. Ce procédé utilise le programme 18 d’interprétation des données, contenu dans la zone de commandes 16, pour exécuter une mise à jour d’une ou plusieurs applications dans la mémoire non volatile 15. Typiquement, lorsqu’une application stockée dans la mémoire 15 doit être mise à jour (bloc 51, MAJ/RD REQ), le système d’exploitation OS reçoit une commande de mise à jour de l’extérieur. A réception de cette commande, le système d’exploitation provoque l’écriture dans la zone 16 (bloc 53, WRITE SB) de l’application devant être mise à jour (des commandes et/ou données 17 de cette application). Puis, l’exécution (bloc 55, EXEC) du programme 18 contenu dans la zone 16 (SB) provoque la configuration ou mise à jour de l’application correspondante dans la mémoire 15. Une fois cette exécution terminée, l’application est à jour. Le même processus que décrit ci-dessus peut être mis en œuvre pour l’extraction (la lecture) de données de l’application dans la mémoire 15. La figure 6 illustre, schématiquement et sous forme de blocs fonctionnels, le mode de mise en œuvre du procédé de la figure 5. La figure 6 illustre, comme en figure 4, les trois éléments ou fonctions du système embarqué 10 qui interviennent pour la mise à jour d’application(s) par la mise en oeuvre du procédé de la figure 5. On retrouve la mémoire non volatile 15 et, plus particulièrement, sa zone (152, figure 2) destinée à stocker les applications (les commandes et tout ou partie des données). On retrouve également, l’interpréteur 18 de commandes 17 et le système d’exploitation 11 (OS). On suppose que trois applications 12 (App1), 13 (App2) et 14 (App3) sont présentes en mémoire non volatile 15. A réception d’un programme de mise à jour (MAJ), le système d’exploitation transfère (WRITE SB) les commandes correspondantes 17 dans la zone ou registre 16. Le programme d’interprétation 18 contenu dans cette zone 16 exécute EXEC les commandes 17, ce qui conduit à reconfigurer ou mettre à jour le ou les applications concernées 12, 13 et 14 dans la mémoire 15. Cette phase est mise en œuvre par le système d’exploitation 11 qui reçoit et exécute les commandes de la zone ou registre 16. Comme pour le mode de mise en oeuvre des figures 3 et 4, les commandes de configuration et/ou de personnalisation des applications ne contiennent pas nécessairement l’ensemble des commandes des applications, mais des commandes permettant le stockage, en mémoire non volatile, entre autres de données secrètes comme des identifiants et des mots de passe, etc. Plus particulièrement, en supposant que l'interpréteur 18 est utilisé à la fois pour la configuration initiale et pour un partage de données entre plusieurs applications, les données contenues dans la zone 16 et partagées entre les applications peuvent être différentes des données de configuration utilisées initialement pour la configuration des applications. Comme pour le mode de mise en œuvre des figures 3 et 4, les applications stockent des données dans la même mémoire non volatile, par exemple toutes leurs données sont stockées dans la même mémoire non volatile. Les applications sont adaptées à générer les adresses auxquelles leurs données doivent être lues et/ou écrites dans la mémoire 15. Chaque application est, plus particulièrement, adaptée à générer des adresses sans empiéter sur les adresses générées par les autres applications. De plus, deux systèmes embarqués 10 identiques verront les données de leurs applications stockées à des adresses différentes. La solution décrite en relation avec les figures 5 et 6 peut également être utilisée pour la lecture ou l’écriture de données d’une application par une autre application. Par exemple, on suppose que l’application du bloc 13 (App2) demande la lecture et/ou la réécriture de données dans l'application (App1) du bloc 12. Pour cela, l'application du bloc 13 envoie une commande représentative de cette demande à la zone de commandes 16. Cette zone distribue alors ladite commande à l'application du bloc 12 pour qu'elle l'exécute. En effet, seule l'application 12 est capable de lire ou modifier les données qu'elle a stockées dans la mémoire 15. La zone ou registre de commandes 16 permet donc de faire le lien entre les différentes applications sans qu’il soit nécessaire que le système d’exploitation sécurise la lecture ou l’écriture. En variante, les données et/ou commandes 17 ne sont pas stockées dans la zone 16 mais transitent en mémoire volatile, la zone 16 étant utilisée pour stocker le programme 18 d'interprétation de commandes utilisées pour le transfert des données et/ou commandes. Un avantage de ce mode de réalisation est qu'il permet la lecture et/ou la réécriture de données d'une application par une autre, sans que les applications ne se partagent les adresses auxquelles sont stockées lesdites données. Divers modes de réalisation et variantes ont été décrits. La personne du métier comprendra que certaines caractéristiques de ces divers modes de réalisation et variantes pourraient être combinées, et d’autres variantes apparaitront à la personne du métier. En particulier, les modes de réalisation des figures 1 et 2 sont compatibles, le registre ou zone de commandes pouvant cumuler les deux utilisations décrites en figure 1 et en figure 2. Enfin, la mise en oeuvre pratique des modes de réalisation et variantes décrits est à la portée de la personne du métier à partir des indications fonctionnelles données ci-dessus. Procédé de lecture et/ou d'écriture de données ou de commandes d’au moins une application (12, 13, 14) dans une mémoire non volatile (15) d'un système embarqué (10), dans lequel les données ou commandes (17) transitent par une zone mémoire (16) et sont interprétées par un programme (18) distinct d’un système d’exploitation du système embarqué. Procédé selon la revendication 1, dans lequel ladite zone (16) est une zone de mémoire volatile. Procédé selon la revendication 1, dans lequel ladite zone est une zone de mémoire non volatile (16). Procédé selon l'une quelconque des revendications 1 à 3, dans lequel ladite au moins une application (12, 13, 14) est mise en oeuvre par le système d'exploitation (11). Procédé selon la revendication 4, dans lequel des commandes (17) sont transférés d'une application (12, 13, 14) à une autre via ladite zone (16). Procédé selon l'une quelconque des revendications 1 à 5, dans lequel la ou les applications (12, 13, 14) sont adaptées à stocker des données dans la mémoire (15). Procédé selon la revendication 6, dans lequel la ou les applications (12, 13, 14) sont adaptées à générer les adresses auxquelles elles stockent des données dans ladite mémoire (15). Système embarqué (20), adapté à mettre en oeuvre au moins une application (12, 13, 14) stockée en mémoire non volatile (15), comprenant une zone mémoire (16) et un programme (18), distinct d’un système d’exploitation, des données ou commandes (17) de ladite au moins une application transitant par ladite zone pour être stockées dans ladite mémoire. Système selon la revendication 8, dans lequel ladite zone (16) est une zone de mémoire volatile. Système selon la revendication 8, dans lequel ladite zone (16) est une zone de mémoire non volatile. Système selon l'une quelconque des revendication 8 à 10, mettant en œuvre au moins deux applications (12, 13, 14). Système selon la revendication 11, dans lequel des données ou commandes transitent d’une application à une autre via ladite zone mémoire (16). Système selon la revendication 11 ou 12, dans lequel les applications (12, 13, 14) sont adaptées à générer les adresses auxquelles elles stockent des données dans ladite mémoire (15). Système selon l’une quelconque des revendications 8 à 13, dans lequel au moins une application est une application de paiement bancaire ou de transport. Carte à puce adaptée à mettre en œuvre le procédé selon l'une quelconque des revendications 1 à 7. Carte à puce comportant un système selon l'une quelconque des revendications 8 à 14.