FR 3090947 A1 20200626 FR 1873537 A 20181220 Description Titre de l'invention : Dispositif à multiples interfaces de communication et procédé correspondant Domaine technique [0001] L'invention se situe dans le domaine des dispositifs électroniques et porte plus parti- culièrement sur la gestion dans un dispositif électronique, tel qu'une carte à puce, d'une pluralité d'interfaces de communication pour communiquer avec l'extérieur selon différents protocoles de communication. Technique antérieure [0002] L'utilisation des cartes à puce (ou cartes à microcircuit) est aujourd'hui largement répandue dans la vie quotidienne. Les cartes à puce peuvent être conçues pour réaliser divers types de fonctions, notamment pour effectuer des transactions, telles que des transactions bancaires (transaction de paiement, de transfert...), des transactions d'authentification, etc. Ces cartes peuvent par exemple être utilisées comme cartes bancaires, cartes de fidélité, cartes d'accès etc., et peuvent prendre divers formats selon leurs utilisations respectives. [0003] De manière générale, une carte à puce est conçue pour communiquer avec un dispositif externe à cette carte, autrement appelé terminal ou lecteur, pour mettre en oeuvre au moins une fonction. Les cartes à puce pour applications bancaires (carte de crédit, carte de débit etc.), par exemple, sont aptes à coopérer avec des terminaux de paiement ou des dishibuteurs automatiques de billets (DAB) pour réaliser divers opérations financières. [0004] De façon connue, une carte à puce comprend un corps de carte qui est équipé d'une puce électronique configurée pour traiter des signaux et réaliser diverses fonctions selon l'utilisation souhaitée de la carte. Pour ce faire, une carte à puce est également munie de moyens de communication lui permettant d'interagir avec des terminaux externes. [0005] Plus particulièrement, une carte à puce est traditionnellement conçue pour coopérer avec un terminal externe au moyen de contacts externes accessibles à la surface de la carte. Un terminal externe peut ainsi positionner des broches de contact appropriées sur les contacts externes de la carte afin d'établir une communication par contact. Plus récemment, les cartes à puce sans contact ont connu un essor important en raison du gain en rapidité et en simplicité liées aux transactions sans contact. Pour ce faire, les cartes sans contact embarquent une antenne radiofréquence (RF) permettant la transmission et la réception de signaux RF avec un terminal externe. [0006] En général, les cartes à puce comportent un élément sécurisé configuré pour traiter 2 les transactions, par exemple selon le standard EMV qui est majoritairement utilisé aujourd'hui pour sécuriser les transactions de paiement. Cet élément sécurisé n'interagit pas directement avec les terminaux externes. Les cartes à puce comportent en outre une unité de traitement, dit parfois « Frontend », qui prend la forme d'une puce électronique conçue pour faire l'interface entre l'élément sécurisé et l'extérieur de la carte. [0007] Pour communiquer avec l'extérieur, une carte à puce respecte un protocole de com- munication approprié. Ainsi, le protocole ISO 7816 est le protocole de communication utilisé majoritairement par les cartes à puce pour coopérer par contact avec des terminaux externes, par exemple avec des terminaux de paiement lors de transactions de paiement par contact. [0008] Comme illustré en figure 1, il est également connu de doter une carte à puce de deux interfaces de communication distinctes afin de permettre à cette carte de communiquer avec l'extérieur selon deux protocoles de communication différents, à savoir le protocole ISO 7816 et le protocole 14443. Le protocole de communication ISO 14443 est conçu pour les transactions sans contact. [0009] A titre d'exemple, la figure 1 représente une carte à puce 100 conventionnelle comportant une premier puce électronique 102, correspondant au « Frontend », et une deuxième puce électronique 108 constituant un élément sécurisé de type EMV pour traiter des transactions EMV. L'élément sécurisé 108 est destiné à contenir des informations confidentielles sensibles, telles que le code PIN de la carte par exemple, et bénéficie donc d'un niveau de sécurité accru par rapport au processeur 102. Ace titre, des mécanismes de sécurité avancés sont généralement mis en oeuvre dans cet élément sécurisé. Une certification est généralement nécessaire pour pouvoir mettre sur le marché et exploiter chaque version d'un tel élément sécurisé. [0010] De façon connue, l'élément sécurisé 108 de cette carte à puce 100 comporte un processeur 109 et deux interfaces de communication 104 et 106 qui permettent au processeur 109 de communiquer avec l'extérieur, au travers de la puce électronique 102, selon deux protocoles de communication distincts, à savoir ISO 7816 et ISO 14443. Ces interfaces de communications 104, 106 sont des périphériques matériels qui sont intégrés dans les couches semi-conductrices (en silicium généralement) de l'élément sécurisé 108. [0011] Le processeur 109 de l'élément sécurisé est apte à exécuter deux modules logiciels (ou applets) 110 et 112 afin de traiter des transactions avec l'extérieur selon respectivement les protocoles de communication ISO 7816 (transactions par contact) et ISO 14443 (transactions sans contact). Ainsi, la carte à puce 100 est multi-application. Lorsque la carte à puce 100 interagit avec un terminal sans contact, ce dernier sélectionne l'applet 112 de l'élément sécurisé 108 pour mettre en oeuvre une transaction 3 sans contact. Inversement, si la carte à puce 100 interagit avec un terminal par contact, ce dernier sélectionne l'applet 110 de l'élément sécurisé 108 pour mettre en oeuvre une transaction par contact. Dans tous les cas, la puce électronique « Frontend » 102 fait l'interface entre l'extérieur de la carte à puce 100 et l'élément sécurisé 108. Chaque commande CMD reçue selon le protocole de communication ISO 7816 (respectivement 150 14443) est transmise par la puce 102 à l'élément sécurisé 108 selon ce même protocole 1SO 7816 (respectivement ISO 14443). Cette commande CMD est reçue par l'interface de communication 104, 106 correspondante de l'élément sécurisé 108, puis traitée par le processeur 109 qui exécute l'applet 110, 112 correspondante pour mettre en oeuvre la transaction EMV. [0012] De façon connue, au cours d'une transaction EMV, le terminal externe envoie à la carte à puce 100 une commande normalisée SELECT APPLICATION qui comporte un identifiant noté AID (pour « Application Identifier ») indiquant l'application souhaitée (traitement par contact ou sans contact). Ainsi, l'élément sécurisé 108 détermine laquelle parmi les applets 110 et 112 il doit exécuter, et ce à partir du protocole de communication utilisé (ISO 7816 ou ISO 14443) et de l'identifiant AID présent dans la commande SELECT APPLICATION reçue. [0013] Comme indiqué ci-dessus, le caractère sensible de l'élément sécurisé 108 requiert que celui-ci soit certifié avant exploitation. L'obtention de cette certification est un processus coûteux. Cette nécessité de certifier les éléments sécurisés, notamment de type EMV, dans les cartes à puce est d'autant plus critique qu'une telle certification est nécessaire pour chaque interface de communication (ici 104 et 106) de l'élément sécurisé 108. [0014] Un besoin existe donc aujourd'hui pour une solution permettant à une carte à puce, ou plus généralement un dispositif électronique, de traiter efficacement des transactions (par exemple de type EMV) selon de multiples protocoles de communication. Or, les mécanismes de sécurité avancés mis en oeuvre dans les éléments sécurisés EMV actuels (pour chaque interface de communication) ainsi que les contraintes liées aux certifications rendent problématique la gestion de multiples protocoles de communication dans de tels éléments sécurisés. Les modifications structurelles qu'il faut apporter à un élément sécurisé afin de permettre la gestion de nouveaux protocoles de communication avec l'extérieur de la carte à puce pose des défis techniques en termes de sécurité notamment, et engendre des coûts indésirables. Exposé de l'invention [0015] A cet effet, la présente invention vise un procédé de routage (ou procédé de traitement) mis en oeuvre dans une carte à puce coopérant avec un terminal pour traiter une transaction, la carte à puce comprenant : une unité de gestion pour traiter la transaction selon des commandes émises par le terminal ; et une unité de traitement configure° pour faire l'interface entre l'unité de gestion et l'extérieur de la carte à puce, en communiquant avec l'unité de gestion selon un unique protocole de communication interne et en communiquant avec l'extérieur selon l'un parmi une pluralité de protocoles de communication externes supportés par l'unité de traitement ; dans lequel l'unité de gestion comprend une pluralité de modules d'exécution, chacun d'eux étant configure pour traiter la transaction selon un protocole de communication externe respectif, le procédé comprenant : réception, par l'unité de traitement, d'une première commande émise par le terminal selon un premier protocole de communication externe ; extraction, par l'unité de traitement, depuis la première commande, d'un premier identifiant d'une application spécifiée pour traiter la transaction ; détermination, à partir du premier identifiant et à partir du premier protocole de communication externe, d'un deuxième identifiant désignant un premier module d'exécution de l'unité de gestion ; génération, à partir de la première commande, d'une deuxième commande comportant le deuxième identifiant ; transmission à l'unité de gestion, par l'unité de traitement, de la deuxième commande selon l'unique protocole de communication interne ; identification, par l'unité de gestion, du premier module d'exécution à partir du deuxième identifiant ; et routage, par l'unité de gestion, de la deuxième commande vers le premier module d'exécution pour traiter ladite deuxième commande. [0016] Selon un mode de réalisation particulier, l'unique protocole de communication interne est le protocole ISO 7816. [0017] Selon un mode de réalisation particulier, la pluralité de protocoles de communication externes supportés par l'unité de traitement comprend les protocoles suivants : BLE (ou Bluetooth) ; Wifi ; NFC ; et ISO 7816. [0018] Selon un mode de réalisation particulier, l'unique protocole de communication interne est différent du premier protocole de communication externe. [0019] Selon un mode de réalisation particulier, le premier identifiant est un identifiant AID conforme à la norme ISO 7816-4. [0020] Selon un mode de réalisation particulier, lors de ladite détermination, l'unité de traitement détermine le deuxième identifiant à partir d'une base de données indiquant, pour une pluralité de couples associant un dit premier identifiant avec un protocole de communication externe, un deuxième identifiant désignant un module d'exécution correspondant de l'unité de gestion. [0021] Selon un mode de réalisation particulier, lors de ladite génération, l'unité de traitement : remplace dans la première commande le premier identifiant par le deuxième identifiant pour générer ladite deuxième commande ; ou génère une nouvelle commande, en tant que deuxième commande, à partir du contenu de la première commande, et en insérant dans la deuxième commande ledit deuxième identifiant. [0022] Selon un mode de réalisation particulier, le procédé comprend un traitement par le premier module d'exécution de la deuxième commande selon ladite application spécifiée dans la première commande et conformément au premier protocole de communication externe. [0023] Selon un mode de réalisation particulier, chaque module d'exécution est un module logiciel configure pour mettre en oeuvre une application selon un protocole distinct parmi ladite pluralité des protocoles de communication externes pour traiter une transaction. [0024] Dans un mode particulier de réalisation, les différentes étapes du procédé de routage sont déterminées par des instructions de programmes d'ordinateurs. [0025] En conséquence, l'invention vise aussi au moins 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 plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de routage tel que défini dans ce document. [0026] 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é dans ce document. [0027] A noter que les programmes d'ordinateur mentionnés dans le présent exposé 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. [0028] De plus, les supports d'enregistrement mentionnés dans ce document 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. [0029] 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 6 électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. [0030] 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 utilise dans l'exécution du procédé en question. [0031] L'invention vise également une carte à puce configuré pour mettre en oeuvre le procédé de routage défini dans le présent document. Plus particulièrement, l'invention vise une carte à puce configuree pour coopérer avec un terminal pour traiter une transaction, la carte à puce comprenant : une unité de gestion pour traiter la transaction selon des commandes émises par le terminal ; et une unité de traitement configurée pour faire l'interface entre l'unité de gestion et l'extérieur de la carte à puce, en communiquant avec l'unité de gestion selon un unique protocole de communication interne et en communiquant avec l'extérieur selon l'un parmi une pluralité de protocoles de communication externes supportés par l'unité de traitement ; dans laquelle l'unité de gestion comprend une pluralité de modules d'exécution, chacun d'eux étant configuré pour traiter la transaction en fonction d'un protocole de communication externe respectif ; dans laquelle l'unité de traitement comprend : un module de réception configuré pour recevoir une première commande émise par le terminal selon un premier protocole de communication externe ; un module d'extraction configuré pour extraire depuis la première commande un premier identifiant d'une application spécifiée pour traiter la transaction ; un module de détermination configuré pour déterminer, à partir du premier identifiant et à partir du premier protocole de communication externe, un deuxième identifiant désignant un premier module d'exécution de l'unité de gestion ; un module de génération configuré pour générer, à partir de la première commande, une deuxième commande comportant le deuxième identifiant ; un module de transmission configuré pour transmettre à l'unité de gestion la deuxième commande selon l'unique protocole de communication interne ; dans laquelle l'unité de gestion comprend en outre : un module d'identification configuré pour identifier le premier module d'exécution à partir du deuxième identifiant ; et un module de routage configuré pour router la deuxième commande vers le premier module d'exécution pour traiter ladite deuxième commande. [0032] A noter que les différents modes de réalisation mentionnés clans ce document en 7 relation avec le procédé de routage de l'invention ainsi que les avantages associés s'appliquent de façon analogue à la carte à puce de l'invention. [0033] Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, sauf indication contraire, le terme « module » peut correspondre dans cc document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. [0034] 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é. [0035] 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 dans ce document pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, etc. [0036] De manière générale, la carte à puce selon l'invention peut comprendre un module configuré pour réaliser chaque opération ou étape décrite dans ce document en relation avec le procédé de routage de l'invention. Brève description des dessins [0037] 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: [0038] [fig.1[ La figure 1 représente schématiquement la structure d'une carte à puce conventionnel de type EMV. [0039] [fig.2[ La figure 2 représente schématiquement la structure d'une carte à puce selon un mode de réalisation particulier de l'invention. [0040] [fig.3[ La figure 3 représente schématiquement des modules fonctionnels mis en oeuvre par une carte à puce selon un mode de réalisation particulier de l'invention. [0041] [fig.4] La figure 4 représente schématiquement une table mises en oeuvre dans une carte à puce selon un mode de réalisation particulier de l'invention. [0042] [fig.5] La figure 5 représente schématiquement une table mises en oeuvre dans une carte à 8 puce selon un mode de réalisation particulier de l'invention. [0043] [fig.6] La figure 6 représente schématiquement, sous la forme d'un diagramme, les étapes d'un procédé de routage selon un mode de réalisation particulier de l'invention. Description des modes de réalisation [0044] La présente invention se propose de permettre une gestion efficace et adaptative de multiples protocoles de communication dans un dispositif électronique, tel qu'une carte à puce, afin de traiter des transactions avec un ou des terminaux externes. [0045] Pour ce faire, l'invention propose notamment un procédé de routage (ou procédé de traitement) mis en oeuvre dans une carte à puce coopérant avec un terminal pour traiter une transaction, la carte à puce comprenant : - une unité de gestion pour traiter la transaction selon des commandes émises par le terminal ; et - une unité de traitement configurée pour faire l'interface entre l'unité de gestion de transaction et l'extérieur de la carte à puce, en communiquant avec l'unité de gestion selon un unique protocole de communication interne et en communiquant avec l'extérieur avec l'un parmi une pluralité de protocoles de communication externes supportés par l'unité de traitement ; dans lequel l'unité de gestion comprend une pluralité de modules d'exécution, chacun d'eux étant configure pour traiter la transaction en fonction d'un protocole de communication externe respectif, le procédé comprenant : - réception, par l'unité de traitement, d'une première commande émise par le terminal selon un premier protocole de communication externe ; - extraction, par l'unité de traitement, depuis la première commande, d'un premier identifiant d'une application spécifiée pour traiter la transaction ; - détermination, à partir du premier identifiant et à partir du premier protocole de communication externe, d'un deuxième identifiant désignant un premier module d'exécution de l'unité de gestion ; - génération, à partir de la première commande, d'une deuxième commande comportant le deuxième identifiant ; - transmission à l'unité de gestion, par l'unité de traitement, de la deuxième commande selon l'unique protocole de communication interne ; - identification, par l'unité de gestion, du premier module d'exécution à partir du deuxième identifiant ; et - routage, par l'unité de gestion, de la deuxième commande vers le premier module d'exécution pour traiter ladite deuxième commande. 9 [0046] L'invention vise également la carte à puce correspondante, ainsi que le ou les programmes d'ordinateurs mis en oeuvre pour réaliser les étapes du procédé. [0047] 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. [0048] Dans le présent exposé, des exemples de mise en oeuvre de l'invention sont décrits dans le cadre d'une carte à puce de type EMV, configurée pour traiter des transactions EMV. A noter que d'autres modes de réalisation sont toutefois possibles. En particulier, l'invention ne s'applique pas exclusivement aux cartes à puce mais peut s'appliquer plus généralement à des dispositifs électroniques quelconques configurés pour traiter des transactions selon de multiples protocoles de communication en coopérant avec un ou des terminaux externes. [0049] De même, des modes de réalisation sont possibles avec un fonctionnement autre que le standard EMV. [0050] On peut également noter que la notion de transaction est entendue dans ce document au sens large et comprend par exemple, dans le domaine bancaire, aussi bien une transaction de paiement ou une transaction de transfert, qu'une consultation d'un compte bancaire sur un terminal bancaire par exemple. Dans les modes de réalisation décrits ci-après, la carte à puce de l'invention traite des transactions de paiement, bien que d'autres types de transaction soient possibles. [0051] 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é. [0052] La figure 2 représente, de manière schématique, la structure d'une carte à puce CD1 selon un mode de réalisation particulier de l'invention. Cette carte à puce CD1 est configurée pour coopérer avec un terminal externe Tl pour traiter une transaction de paiement TRI selon le standard EMV. [0053] Le protocole EMV, bien connu de l'homme du métier, a été conçu pour diminuer les risques de fraudes lors d'une transaction de paiement en permettant notamment l'authentification à la fois de la carte à puce et de son porteur. Ce processus d'authentification fait appel à une combinaison de cryptogrammes (ou clés cryptées) et de signatures numériques et nécessite éventuellement la saisie d'un code secret (appelé communément code PIN) par le porteur de la carte. [0054] Comme représenté en figure 2, la carte à puce CD1 comprend une unité de traitement UI et une unité de gestion de transaction U2 (dite aussi unité de gestion), ces unités étant configurées pour communiquer ensemble au sein de la carte à puce CD1 en utilisant un unique protocole de communication interne noté PI, et ce quelles que soient les données échangées. On suppose par la suite que cet unique protocole de communication interne est le protocole ISO 7816, bien que d'autres protocoles soient possibles. Cela signifie que l'unité de gestion U2 ne communique avec l'unité de traitement Ul qu'au travers de ce seul protocole de communication PI qui est interne à la carte à puce CD1. [0055] Dans l'exemple envisagé ici, l'unité de gestion U2 constitue un élément sécurisé qui est intégré ou inclus dans la carte à puce CD1. Cet élément sécurisé U2 est configure pour traiter des transactions selon la norme EMV. [0056] L'unité de traitement Ul et l'unité de gestion U2 peuvent être implémentées sur deux puces électroniques distinctes, connectées l'une à l'autre, bien que d'autres modes de réalisation soient possibles. [0057] 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 plateforme 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 « Universel' Integrated Circuit Card »), un élément sécurisé embarqué (ou « einbedded SE » ou encore « eSIM ») ou encore une carte microSD. 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é. [0058] Toujours dans l'exemple de réalisation représenté en figure 2, l'unité de traitement Ul est implémentée dans une puce électronique dite « Frontend ». L'unité de traitement Ul est configurée pour faire l'interface entre l'unité de gestion U2 et l'extérieur de la carte à puce CD1. Pour ce faire, l'unité de traitement Ul communique avec l'unité de gestion U2 selon l'unique protocole de communication interne PI (comme déjà décrit ci-avant) et communique avec l'extérieur de la carte à puce CD1 (et plus particulièrement avec le terminal Tl dans cet exemple) en utilisant l'un parmi une pluralité de protocoles de communication externes PE supportés par l'unité de traitement Ul. Autrement dit, l'unité de traitement Ul est configurée pour coopérer avec le terminal externe Tl via l'un parmi de multiples protocoles de communication externes PE prédéfinis. [0059] Comme représenté en figures 2, on suppose que l'unité de traitement Ul supporte les protocoles de communication externes PE1, PE2, PE3 et PE4 (notés collectivement PE). Autrement dit, l'unité de traitement Ul a la capacité de sélectionner et exécuter chacun des protocoles PE selon le cas pour communiquer avec une entité externe. A titre d'exemple, on considère par la suite que les protocoles de communication 11 externes PE pris en charge par l'unité de traitement UI sont définis comme suit : PEI : protocole BLE pour « Bluetooth Law Energy » ; PE2 : protocole Wifi ; PE3 : protocole NFC pour « Near Field Communication » ; et PE4 : protocole ISO 7816. [0060] A noter qu'il ne s'agit que d'un exemple non limitatif, le nombre et la nature des protocoles de communication externes PE pouvant varier selon les besoins. [0061] Comme représenté en figure 2, l'unité de traitement Ul comprend un processeur 2 ainsi que 4 interfaces de communication INT1-INT4 pour permettre au processeur 2 de communiquer avec l'extérieur de la carte à puce CD1 (et en particulier avec le terminal Ti) selon les protocoles de communication externes respectifs PEI-PE4. Il s'agit ici d'interfaces de communication externes dans le sens où les protocoles PE permettent de communiquer avec des entités externes à la carte à puce CD1. Dans cet exemple, ces interfaces de communication PE prennent la forme de périphériques matériels qui sont intégrés dans les couches semi-conductrices de la puce électronique comportant l'unité de traitement Ul . [0062] Dans cet exemple, la carte à puce CD1 comprend en outre des antennes AT1, AT2 et AT3 qui sont utilisées respectivement par les interfaces de communication INTI-TNT3 pour communiquer avec un terminal externe selon les protocoles de communication externes PE1, PE2 et PE3, respectivement. De même, la carte à puce CD1 comprend dans cet exemple des contacts externes CT conforme au standard ISO 7816, pour permettre à l'interface de communication externe INT4 de communiquer par contact avec un terminal externe selon le protocole de communication externe PE4 (i.e. ISO 7816). [0063] A noter qu'il est possible de n'implémenter dans la carte à puce CD1 que certaines parmi les interfaces de communication INT1-INT4. Par exemple, il est possible de n'implémenter que les interfaces INT I-INT3 et d'exclure ainsi l'interface INT4. Dans ce cas, il n'est pas nécessaire que la carte à puce CD1 embarque les contacts externes CT. En variante, une quelconque sous-combinaison parmi les interfaces de communication INTI-INT4 peut être mise en oeuvre dans la carte à puce CDI. [0064] Dans l'exemple considéré ici, chaque antenne ATI-AT3 est adaptée pour permettre une communication selon le protocole de communication externe correspondant PE1-PE3. Les moyens mis en oeuvre dans la carte à puce CDI pour permettre les communications avec l'extérieur peuvent être adaptés par l'homme du métier selon chaque cas d'usage. Selon un exemple particulier, au moins deux parmi les antennes ATI-AT3 peuvent former une seule et même antenne. [0065] Comme représenté en figure 2, l'unité de traitement UI comprend également une mémoire MR1 ainsi qu'une interface de communication interne INT5. 12 [0066] La mémoire MR1 est une mémoire non volatile (Flash ou EEPROM par exemple), cette mémoire constituant un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par l'unité de traitement Ul, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier. Cc programme d'ordinateur PG1 comporte des instructions pour l'exécution de certaines des étapes d'un procédé de routage selon un mode de réalisation particulier qui sera décrit ultérieurement. [0067] Comme décrit plus en détail par la suite, la mémoire MR1 est apte à stocker également des données sous la forme d'une table TB1. Des structures de données autres qu'une table sont toutefois possibles. La structure TBI peut prendre la forme d'une base de données par exemple. Cette table TBI (représentée en figure 4) permet à l'unité de traitement Ul de déterminer comment router des commandes entrantes vers l'unité de gestion U2 et comment transmettre des commandes sortantes vers l'extérieur de la carte à puce CD1. Comme décrit plus en détail ultérieurement, cette table TB1 stocke en particulier des triplets associant un premier identifiant ID1, un deuxième identifiant ID2 et un protocole de communication externe PE correspondant. [0068] L'unité de traitement UI peut en outre comprend une mémoire volatile RAM (non représentée). [0069] L'unité de traitement UI utilise en outre son interface de communication interne INT5 pour communiquer selon l'unique protocole de communication interne PI avec l'unité de gestion U2. [0070] Par ailleurs, comme déjà indiqué, l'unité de gestion U2 est configurée pour traiter des transactions EMV en coopération avec des terminaux externes tels que Tl par exemple. Pour ce faire, l'unité de gestion U2 comprend un processeur 10, une interface de communication interne INT6, une mémoire MR2 et des modules d'exécution MX1-MX4, notés collectivement MX. [0071] Le processeur 10 utilise l'interface de communication INT6 pour communiquer selon l'unique protocole de communication interne PI avec l'unité de traitement Ul. L'unité de gestion U2 coopère ainsi avec le terminal Ti au travers de l'unité de traitement Ul qui fait office d'interface. Comme déjà indiqué, on suppose ici que le protocole PI est ISO 7816 bien que d'autres exemples soient possibles. [0072] La mémoire MR2 est une mémoire non volatile (Flash ou EEPROM par exemple), cette mémoire constituant un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par l'unité de gestion U2, et sur lequel est enregistré un programme d'ordinateur PG2 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG2 comporte des instructions pour l'exécution de certaines des étapes d'un procédé de routage selon un mode de réalisation particulier qui sera décrit ultérieurement. 13 [0073] Comme décrit plus en détail par la suite, la mémoire MR2 est apte à stocker également des données sous la forme d'une deuxième table TB2. Des structures de données autres qu'une tahle sont toutefois possibles. La structure TB2 peut prendre la forme d'une hase de données. Cette tahle TB2 (représentée en figure 5) permet à l'unité de gestion U2 de déterminer vers lequel parmi les modules d'exécution MX doivent être routées des commandes entrantes et comment transmettre des commandes sortantes vers l'unité de traitement Ul . Comme décrit plus en détail ultérieurement, cette table TB2 stocke en particulier des couples associant un deuxième identifiant 1D2 et un module d'exécution MX correspondant. [0074] L'unité de gestion U2 peut en outre comprend une mémoire volatile RAM (non re- présentée). [0075] Comme déjà indiqué, l'unité de gestion U2 comprend dans cet exemple 4 modules d'exécution MX distincts, bien que d'autres implémentations soient possibles. Chaque module d'exécution MX est configure pour traiter une transaction en exécutant une application selon un protocole de communication externe distinct parmi PEI, PE2, PE3 et PE4. Ainsi, chacun de ces modules d'exécution MX constitue un module logiciel (ou applet) exécutable par le processeur 10 pour mettre en oeuvre une application selon un protocole distinct parmi la pluralité des protocoles de communication externes PE supportés par l'unité de traitement U1. Ces modules d'exécution MX permettent ainsi de traiter une transaction selon différents protocoles de communication externes. [0076] On suppose par la suite que tous les modules d'exécution MX sont configurés pour exécuter une même application APPI, telle que par exemple une application de paiement VISATM, pour traiter une transaction EMV. La manière dont chaque module d'exécution MX exécute cette même application de paiement APP1 (notamment au niveau des commandes qui sont échangées) varie néanmoins de sorte à être adaptée au protocole de communication externe PE utilisé entre le terminal externe et le module de traitement Ul. [0077] On comprend toutefois que le nombre et la nature des modules d'exécution MX peuvent varier en fonction des protocoles de communication externes PE implémentés par l'unité de traitement Ul. De même, les modules d'exécution MX peuvent éventuellement être configurés pour exécuter au moins deux applications différentes (par exemple de type VISATM et MASTERCARDTM). La nature des applications exécutées par les modules d'exécution MX pour traiter des transactions peut également être adaptée selon les besoins. [0078] De manière générale, lorsqu'une transaction TRI de type EMV est initiée entre la carte à puce CD1 et le terminal Tl (comme représentée en figure 2), ceux-ci peuvent coopérer ensemble selon l'un quelconque parmi les protocoles de communication externes PE supportés par l'unité de traitement Ul, par exemple celui choisi par le 14 terminal Ti. Ainsi, toutes les commandes ou messages échangés dans la transaction TR1 entre le terminal Tl et la carte à puce CD1 respectent le protocole de communication externe PE choisi. L'unité de traitement Ul est ainsi capable de faire l'interface entre le terminal Ti et l'unité de gestion U2 en communiquant avec l'unité de gestion U2 selon l'unique protocole de communication interne PI et en communiquant avec le terminal Ti avec l'un parmi la pluralité de protocoles de communication externes PE. Une contrainte réside en ce qu'un seul protocole de communication interne IP, qui peut être différent du protocole de communication PE est utilisé pour les communications internes entre l'unité de traitement Ul et l'unité de gestion U2. Pour permettre le dialogue entre l'unité de gestion U2 et l'extérieur, les commandes entrantes doivent donc être routées vers le module d'exécution MX approprié d'une part et, d'autre part, les commandes sortantes doivent être transmises à l'unité de traitement Ul de sorte que cette dernière puisse elle-même transmettre ces commandes au terminal Tl selon le protocole de communication externe PE approprié. La manière dont ces commandes sont routées dans les sens entrant et sortant est décrite ci-après dans un exemple particulier. [0079] A noter que certains éléments généralement présents dans une carte à puce ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la présente invention. L'homme du métier comprend en outre que certains éléments de la carte à puce CD1 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. [0080] Par ailleurs, conformément à un mode de réalisation particulier, le processeur 2 piloté par le programme d'ordinateur PG1 met ici en oeuvre un certain nombre de modules représentés en figure 3, à savoir : un module de réception MD2, un module d'extraction MD4, un module de détermination MD6, un module de génération MD8 et un module de transmission MD10. [0081] De même, conformément à un mode de réalisation particulier, le processeur 10 piloté par le programme d'ordinateur PG2 met ici en oeuvre un certain nombre de modules représentés en figure 3, à savoir : les modules d'exécution MX déjà mentionnés ci-avant, un module d'identification MD20 et un module de routage MD22. [0082] Plus précisément, le module de réception MD2 est configuré pour recevoir, lors d'une transaction TRI, une première commande CMD1 émise par le terminal Tl selon un premier protocole de communication externe, à savoir PE1 par exemple. Cette commande est par exemple une commande SELECT APPLICATION conforme à la norme EMV. [0083] Le module d'extraction MD4 est configuré pour extraire depuis la première commande CMD1 un premier identifiant ID1 d'une application spécifiée pour traiter la transaction TRI, à savoir l'identifiant ID1 de l'application APP1 dans cet exemple. Ce premier identifiant est par exemple de type AID (pour « Application Identifier ») conforme à la norme ISO 7816-4. [0084] Le module de détermination MD6 est configuré pour déterminer, à partir du premier identifiant ID] extrait par le module d'extraction MD4 et à partir du premier protocole de communication externe utilisé (à savoir PE1 par exemple), un deuxième identifiant 1D2 désignant un premier module d'exécution MX de l'unité de gestion U2 (à savoir le module d'exécution MX1 par exemple). Le module d'exécution MX ainsi désigné correspond à celui parmi MX1-MX4 qui est configuré pour prendre en charge les communications selon le protocole de communication externe PE utilisé lors de la transaction TRI. [0085] Le module de génération MD8 est configuré pour générer, à partir de la première commande CMD1, une deuxième commande CMD2 comportant le deuxième identifiant ID2. [0086] Le module de transmission MD10 est configuré pour transmettre à l'unité de gestion U2 la deuxième commande CMD2 selon l'unique protocole de communication interne PI. [0087] Le module d'identification MD20 est configuré pour identifier le premier module d'exécution MX (à savoir, MX1 par exemple) à partir du deuxième identifiant 1D2 présent dans la deuxième commande CMD2 reçue. [0088] Le module de routage MD22 est configuré pour router la deuxième commande CMD2 vers le module d'exécution ainsi identifié (MX1 par exemple) pour traiter cette deuxième commande. [0089] L'unité de traitement Ul et l'unité de gestion U2 sont ainsi configurées pour dé- terminer, à partir du protocole de communication externe PE utilisé et de l'identifiant ID1 désignant une application spécifique, comment router chaque commande entrante vers le module d'exécution MX approprié dans le cadre de la transaction TRI. Une fois que le module d'exécution MX approprié est déterminé, toutes les commandes entrantes reçues lors de la transaction TRI peuvent être transmises au même module d'exécution MX. [0090] Inversement, l'unité de traitement UI et l'unité de gestion U2 sont configurées pour déterminer, à partir du module d'exécution MX qui est exécuté, comment transmettre chaque commande sortante depuis l'unité de gestion U2 vers le terminal Ti en respectant le protocole de communication externe PE appliqué. [0091] La configuration et le fonctionnement des modules MD2-MDIO de l'unité de traitement Ul, d'une part, et des modules MX et MD20-MD22 de l'unité de gestion U2, d'autre part, apparaîtront plus précisément dans les exemples de réalisation décrits ci-après. On comprendra que ces modules ne représentent qu'un exemple de mise en oeuvre non limitatif de l'invention. 16 [0092] De manière générale, l'unité de traitement Ul et l'unité de gestion U2 mettent en oeuvre un module respectif pour réaliser chaque opération ou étape du procédé de routage de l'invention. [0093] Un mode de réalisation particulier de l'invention est à présent décrit en référence aux figures 4-6. Plus précisément, la carte à puce CD1 représenté en figures 1-2 met en oeuvre un procédé de routage (ou procédé de traitement) de l'invention en exécutant les instructions des programmes d'ordinateur PG1 et PG2, formant collectivement un programme d'ordinateur. Autrement dit, l'unité de traitement Ul et l'unité de gestion U2 exécutent respectivement les programmes d'ordinateur PG1 et PG2 pour mettre en oeuvre collectivement les étapes du procédé de routage. [0094] On suppose qu'une transaction EMV notée TR1 est initiée entre le terminal externe Ti et la carte à puce CD1. Cette transaction TR1 fait appel à une coopération entre terminal Ti et la carte à puce CD1 qui échangent ensemble des commandes (ou messages) conformes au standard EMV. On suppose ici que la transaction TR1 est une transaction de paiement EMV. [0095] Lors de cette transaction TR1, la carte à puce CD1 et le terminal Ti communiquent ensemble selon l'un quelconque parmi les protocoles de communication externes PE, par exemple celui imposé par le terminal Tl. Ainsi, toutes les commandes ou messages échangés dans la transaction TR1 entre le terminal Ti et la carte à puce CD1 respectent le protocole de communication externe PE appliqué par le terminal T1. On suppose dans cet exemple que le terminal TI applique le protocole de communication externe PE1 correspondant au protocole BLE, d'autres exemples étant toutefois possibles. [0096] Dans une phase préliminaire de la transaction TRI, le terminal Tl transmet (A2) ainsi à la carte à puce CDI, selon le protocole de communication externe PEI, une commande CMD1 de type SELECT APPLICATION afin de sélectionner une application, à savoir l'application de paiement APP1 dans cet exemple. Pour ce faire, la commande CMD1 comprend un premier identifiant ID I de type AID conforme à la norme ISO 7816-4, qui identifie l'application que le terminal TI souhaite sélectionner dans la carte à puce CDI. La commande CMD1 est reçue (B2) par l'unité de traitement Ul au travers de son interface de communication externe INTI qui applique le protocole de communication externe PE utilisé par le terminal Tl. [0097] Le format de la trame de la commande CMD1 reçue en B2 est conforme au protocole de communication externe PE1. Il s'agit d'une commande APDU dont l'encapsulation est réalisée selon le protocole PEI. Le processeur 2 de l'unité de gestion U2 reconnaît ainsi que c'est le protocole de communication externe PEI qui est appliqué à partir du format de la commande CMD1 reçue, ou plus généralement à partir de l'interface de communication externe par laquelle a été reçue la commande CMDI (à savoir, via l'interface INTI dans cet exemple). Dans le cas présent, la commande CMD1 est reçue 17 par l'unité de traitement Ul via l'antenne AT1 sur son interface de communication externe INT1, ce qui signifie que c'est le protocole dc communication externe PE1 qui est appliqué. [0098] Au cours d'une étape B4 d'extraction, le processeur 2 extrait ensuite le premier identifiant ID] de la commande CMDI reçue. On suppose dans cet exemple que cet identifiant correspond à l'application APPI que le terminal Ti souhaite sélectionner dans la carte à puce CD1 pour traiter la transaction TRI . [0099] Au cours d'une étape B6 de détermination, le processeur 2 consulte alors la table TB1 dans la mémoire MR1 (figures 2 et 4) et détermine, à partir du protocole dc communication externe PE1 utilisé et du premier identifiant ID1, un deuxième identifiant 1D2 correspondant au module d'exécution MX qui est destiné à traiter cette commande et plus généralement la transaction TR1. [0100] Plus précisément, la table TB1 envisagée dans cet exemple est représentée en figure 4. Comme déjà indiqué, cette table TB1 stocke des triplets associant un premier identifiant ID] et un deuxième identifiant ID2 à chaque protocole dc communication externe PE supporté par l'unité de traitement Ul. Autrement dit, la table TB1 indique, pour une pluralité de couples associant un premier identifiant ID1 avec un protocole de communication externe PE, un deuxième identifiant ID2 désignant un module d'exécution MX correspondant de l'unité de gestion U2. Ainsi, dans cet exemple, la table TB1 spécifie : l'identifiant ID21 en association avec l'identifiant IDI et le protocole de communication externe PEl ; l'identifiant ID22 en association avec l'identifiant IDI et le protocole de communication externe PE2 ; l'identifiant ID23 en association avec l'identifiant IDI et le protocole de communication externe PE3 ; et l'identifiant ID24 en association avec l'identifiant IDI et le protocole de communication externe PE4. [0101] Comme déjà indiqué, on suppose dans ce mode de réalisation que seule l'application de paiement APPI est exécutée par tous les modules d'exécution MX. Aussi, tous les triplets stockés dans la table TB1 comprennent ici le même premier identifiant IDI correspondant à la même application APPI (une application de paiement VISATM par exemple). Comme déjà indiqué, d'autres modes de réalisation sont toutefois possibles dans lesquels plusieurs applications différentes sont mises en oeuvre par les modules d'exécution MX de l'unité de gestion U2. Dans un tel cas, le premier identifiant IDI varie dans les triplets de la table TBI. [0102] Les deuxièmes identifiants ID21-1D24 (notés collectivement ID2) désignent chacun un module d'exécution MX respectif de l'unité de gestion U2 parmi MXI-MX4. 18 [0103] Dans l'exemple considéré ici, à partir du premier identifiant ID1 extrait en B4 de la commande CMDI et à partir de PE1 reconnu comme le protocole de communication externe utilisé par le terminal T1, le processeur 2 détermine (B6) le deuxième identifiant ID21 correspondant au module d'exécution MX1. Dans cet exemple, le module d'exécution MX1 est destiné à traiter des transactions EMV selon le protocole de communication externe BLE en exécutant l'application de paiement APPl. [0104] A noter qu'un identifiant AID selon la norme ISO 7816-4 désigne une application (une application de paiement VISATM dans cet exemple) et cc, quel que soit le protocole de communication qui est utilisé pour les communications externes entre carte à puce CD1 et terminal externe Tl. Autrement dit, un identifiant AM ne renseigne pas nécessairement sur le protocole de communication externe PE utilisé. Cela signifie que le protocole de communication externe PE utilisé a un impact sur la trame APDU de la commande SELECT APPLICATION, mais pas sur l'identifiant AID présent dans cette commande. Comme expliqué par la suite, le premier identifiant ID1 présent dans la commande CMD1 ne suffirait donc pas à l'unité de gestion U2 pour déterminer quel module d'exécution MX doit traiter une commande entrante, et de manière générale, la transaction TR1 en cours. C'est à partir de ce premier identifiant ID] et du protocole de communication externe PE applicable que l'unité de traitement Ul en déduit, en consultant sa table TB1, quel module d'exécution MX doit traiter la transaction en cours. Dans l'exemple considéré ici, le deuxième identifiant ID2 déterminé en B6 ne désigne pas simplement l'application de paiement VISATM mais plus précisément l'unité de gestion MX1 qui est configurée pour traiter l'application de paiement VISATM selon le protocole de communication externe PE1 (c'est-à-dire BLE dans cet exemple). [0105] Selon un exemple particulier, l'unité de traitement UI enregistre le deuxième identifiant ID2 déterminé en B6 (à savoir, l'identifiant ID21 dans cet exemple) dans sa mémoire volatile RAM (non représentée). Comme expliqué ultérieurement, cette information peut être utilisée par la suite par l'unité de traitement Ul pour router d'autres commandes entrantes depuis l'extérieur vers l'unité de gestion U2. [0106] Selon un exemple particulier, l'unité de traitement UI enregistre dans sa mémoire volatile RAM le premier identifiant ID1 extrait en B4 en association avec PE1 reconnu comme le protocole de communication externe utilisé par le terminal Tl. Comme expliqué ultérieurement, cette information peut être utilisée par la suite par l'unité de traitement UI pour transmettre des commandes sortantes depuis l'unité de gestion U2 vers l'extérieur. [0107] Puis, au cours d'une étape B8 de génération, le processeur 2 génère, à partir de la première commande CMD1, une deuxième commande CMD2 comportant le deuxième identifiant M21 déterminé en B6. 19 [0108] Pour ce faire, au cours de l'étape B8 de génération, le processeur 2 génère une nouvelle commande, en tant que deuxième commande CMD2, à partir du contenu de la première commande CMD1, et en insérant dans cette deuxième commande le deuxième identifiant 1D21 déterminé en B6. En variante, au cours de l'étape B8 de génération, le processeur 2 remplace dans la première commande CMD1 le premier identifiant ID] par le deuxième identifiant 1D21 de sorte à générer la deuxième commande CMD2. [0109] Au cours d'une étape B10 de transmission, le processeur 2 déclenche ensuite la transmission, selon l'unique protocole de communication interne PI (à savoir ISO 7816 dans cet exemple), de la deuxième commande CMD2 à l'unité de gestion U2. Cette transmission est réalisée en utilisant l'interface de communication interne INTS qui communique avec l'interface de communication INT6 de l'unité de gestion U2. Il s'ensuit que cette deuxième commande CMD2 présente un format ou une encapsulation qui est conforme à l'unique protocole de communication interne PI. [0110] Au cours d'une étape C10 de réception, l'unité de gestion U2 reçoit la commande CMD2 selon l'unique protocole de communication interne PI. [0111] Au cours d'une étape C12 d'identification, le processeur 10 de l'unité de gestion U2 identifie le module d'exécution MX destinataire de la commande CMD2 reçue en C10. Pour cc faire, le processeur 10 consulte par exemple la table TB2 (figure 2) qui est représenté plus précisément en figure 5 dans cet exemple particulier. Le processeur 10 détermine ainsi dans cet exemple, à partir de l'identifiant 1D21 compris dans la commande CMD2, que c'est le module d'exécution MX1 qui est destinataire de ladite commande CMD2. [0112] Au cours d'une étape C14 de routage, le processeur 10 route alors la commande CMD2 vers le module d'exécution MX concerné, à savoir le module MX1 dans cet exemple, pour traiter la commande CMD2, et plus généralement la transaction TRI. [0113] Au cours d'une étape CI6 de traitement, le module d'exécution MX1 destinataire réalise un traitement de la deuxième commande CMD2 selon l'application APP1 spécifiée par l'identifiant ID1 de la première commande CMD1. Ce traitement est réalisé conformément au protocole de communication externe PEl qui est utilisé par le terminal TI et l'unité de traitement UI pour communiquer ensemble. Ce traitement peut comprendre un échange de commandes entre l'unité de gestion U2 et le terminal Tl au travers de l'unité de traitement UI en respectant le principe présenté ci-dessus. [0114] L'unité de traitement Ul et l'unité de gestion U2 peuvent ensuite coopérer ensemble pour router chaque commande entrante vers le module d'exécution MX approprié, à savoir le module MX1 dans cet exemple. Ainsi, selon un exemple particulier, suite à l'étape C12 d'identification, l'unité de gestion U2 détermine que c'est le module d'exécution MX1 qui doit traiter toutes les commandes échangées avec le terminal T 1 au travers de l'unité de traitement Ul lors de la transaction TRI en cours. Aussi, tant que la transaction TRI est en cours, toutes les commandes reçues depuis l'unité de traitement Ul sont routées par le processeur 10 vers le module d'exécution MX1. [0115] De même, selon un exemple particulier, suite à l'étape B6 de détermination, l'unité de traitement Ul détermine que c'est le deuxième identifiant ID21 qui doit être inséré dans chaque commande à transmettre à l'unité de gestion U2 (de façon identique à l'étape B8). Pour ce faire, l'unité de traitement Ul peut consulter sa mémoire volatile RAM (non représentée) dans laquelle est stocké le deuxième identifiant ID21, comme déjà décrit précédemment. Ainsi, pour chaque commande entrante, l'unité de traitement Ul sait comment router la commande sans qu'il soit nécessaire de consulter à nouveau la table TB1 (figure 2). Il n'est donc pas nécessaire que l'unité de traitement Ul consulte de manière répétée sa table TB1 (figure 2), ce qui permet d'accélérer le traitement et d'économiser des ressources. Si, en revanche, l'identifiant 1D21 n'est plus présent dans sa mémoire volatile RAM, alors l'unité de traitement Ul peut exécuter à nouveau les étapes B4 et B6 comme déjà décrit afin de déterminer le deuxième identifiant ID2 applicable. [0116] Dans ce qui précède, il a été décrit la manière dont une ou des commandes entrantes dans la carte à puce CDI depuis le terminal T1 sont routées vers le module d'exécution adéquat de l'unité de gestion U2. Une ou des commandes sortantes peuvent également être transmises par l'unité de gestion U2 et l'unité de traitement Ul, bien que cela ne soit pas obligatoire. A noter par exemple que, dans le cas particulier où la commande entrante CMD1 précédemment mentionnée est une commande SELECT OPTION, aucune réponse n'est générée par le module d'exécution MX1 conformément au standard EMV. Des échanges de commandes se poursuivent néanmoins selon le standard EMV entre le terminal Ti et la carte à puce CDI au cours de la transaction TRI. [0117] Selon un exemple particulier, l'unité de traitement UI et l'unité de gestion U2 peuvent ainsi coopérer ensemble pour transmettre chaque commande sortante depuis l'unité de gestion U2 vers le terminal Tl par l'intermédiaire de l'unité de traitement Ul. [0118] Ainsi, comme représenté en figure 6, suite à la réception de la commande CMD2, le module d'exécution MX1 peut générer une nouvelle commande CMD3 qui comprend l'identifiant ID2I correspondant audit module d'exécution MXI. Cette nouvelle commande peut être par exemple une commande GET PROCESSING OPTIONS ou tout autre commande conforme au standard EMV. [0119] Le processeur 10 de l'unité de gestion U2 transmet (C20) alors cette commande CMD3 à l'unité de traitement UI selon l'unique protocole de communication interne PI. L'unité de traitement Ul reçoit cette commande CMD3 en B20. 21 [0120] Au cours d'une étape B24 de détermination, le processeur 2 consulte sa mémoire volatile et détermine que c'est le premier identifiant ID1 et le protocole de commu- nication externe PE1 qui sont applicables pour transmettre une commande vers l'extérieur. [0121] Au cours d'une étape B26 de génération, le processeur 2 génère alors une nouvelle commande, en tant que quatrième commande CMD4, à partir du contenu de la troisième commande CMD3, et en insérant dans cette quatrième commande CMD4 le premier identifiant Dl déterminé en B24. En variante, au cours de l'étape B26 de génération, le processeur 2 remplace dans la troisième commande CMD3 le deuxième identifiant ID21 par le premier identifiant ID1 de sorte à générer la quatrième commande CMD4. [0122] Selon une variante, si la mémoire volatile RAM de l'unité de traitement Ul ne contient plus l'information selon laquelle ce sont le premier identifiant ID1 et le protocole de communication externe PEI qui sont applicables pour transmettre une commande vers l'extérieur, alors le processeur 2 peut fonctionner selon le même principe que déjà décrit en référence aux étapes B4 à B8, mais de façon inversée. Ainsi, le processeur 2 peut extraire (B22) le deuxième identifiant ID21 de la commande CMD3 reçue. Le processeur 2 consulte alors sa table TB1 (figure 4) et détermine à l'étape B24, à partir du deuxième identifiant ID21, que c'est l'application APPI correspond à l'identifiant IDI (de type AID) qui est mise en oeuvre et que c'est le protocole de communication externe PEI qui est appliqué dans le cas présent. Le processeur 2 peut ensuite procéder à l'étape B26 de génération comme décrit ci-avant. [0123] Au cours d'une étape B28 de transmission, le processeur 2 déclenche ensuite la transmission, selon le protocole de communication externe PEI (à savoir BLE dans cet exemple), de la quatrième commande CMD4 au terminal Tl. Cette transmission est réalisée en utilisant l'interface de communication externe INT I qui communique avec le terminal Tl selon le protocole PEI en utilisant l'antenne ATI. Il s'ensuit que cette quatrième commande CMD4 présente un format ou une encapsulation qui est conforme au protocole de communication externe PEI. [0124] Le terminal Tl reçoit (A30) la commande CMD4 et peut poursuivre le traitement de la transaction TRI avec la carte à puce CDI tant que nécessaire, conformément au principe de routage présenté ci-avant. [0125] Ainsi, pour chaque commande sortante, l'unité de traitement Ul peut consulter sa mémoire volatile RAM pour déterminer comment transmettre la commande depuis l'unité de gestion U2 vers l'extérieur. Il n'est donc pas nécessaire que l'unité de traitement Ul consulte de manière répétée sa table TBI (figure 2), ce qui permet d'accélérer le traitement et d'économiser des ressources. En revanche, si l'information désignant l'identifiant IDI et le protocole de communication externe PEI comme étant applicables n'est plus présente dans sa mémoire volatile RAM, alors l'unité de traitement Ul peut consulter sa table TB1 comme déjà décrit. [0126] Dans l'exemple de réalisation décrit ci-dessus, le protocole de communication externe PE appliqué dans les communications entre le terminal Tl et la carte à puce CD1 est le protocole PE1 correspondant au BLE. D'autres exemples sont bien entendu possibles. Selon un exemple particulier, le protocole de communication externe PE1 appliqué est différent de l'unique protocole de communication interne PI utilisés par l'unité de traitement Ul et l'unité de gestion U2 pour communiquer ensemble en interne. [0127] La présente invention permet une gestion efficace et adaptative de multiples protocoles de communication dans une carte à puce, ou plus généralement dans un dispositif électronique, afin de traiter des transactions avec des terminaux externes tout en garantissant un bon niveau de sécurité. [0128] L'invention offre en particulier une souplesse de fonctionnement dans la mesure où la carte à puce peut sélectionner le protocole de communication externe adéquat en fonction du type de terminal avec lequel elle coopère. [0129] Selon le principe de l'invention, l'unité de gestion utilise un unique protocole de communication interne, de sorte que celui-ci ne varie pas même s'il l'on varie les protocoles de communication externes utilisés dans les communications entre la carte à puce et l'extérieur. L'usage de cet unique protocole de communication interne a pour conséquence que l'unité de gestion n'est pas capable de déduire directement du format des commandes reçues le protocole de communication externe utilisé par l'unité de traitement pour communiquer avec le terminal externe. Selon le principe de l'invention, l'unité de traitement fournit donc à l'unité de gestion une nouvelle information, à savoir un deuxième identifiant ID2, permettant à l'unité de gestion de router intelligemment les commandes reçues vers le module d'exécution adéquat. [0130] Il est ainsi possible d'adapter aisément la configuration de la carte à puce de sorte à ce qu'elle supporte les protocoles de communication externes souhaités, et ce sans altérer la structure matérielle ou l'architecture de l'unité de gestion. [0131] L'architecture de l'unité de gestion, ou plus précisément de l'élément sécurisé, est simplifiée du fait qu'un seul protocole de communication interne est supporté ce qui permet d'augmenter la sécurité de l'unité de gestion, tout en garantissant que des transactions puissent être traitées selon de multiples protocoles de communication externes. Le fait qu'un unique protocole de communication interne soit supporté par l'unité de gestion permet de mettre en oeuvre, dans cette unité de gestion, des mécanismes de sécurité avancés (logiciels et/ou matériels) qui sont adaptés à cet unique protocole. En concentrant les mécanismes de sécurité sur cette unique interface de communication interne, la sécurité des transactions peut être améliorée. 23 [0132] De façon avantageuse, il est par exemple possible d' implémenter ISO 7816 en tant que protocole de communication interne PI. Les éléments sécurisés proposés aujourd'hui par les fondeurs supportent généralement le protocole ISO 7816. Ce cas particulier est également avantageux en ce que les éléments sécurisés communiquant selon ISO 7816 présentent une architecture générale connue dont on maîtrise bien aujourd'hui les aspects sécuritaires. Il est plus aisé de protéger efficacement un élément sécurisé communiquant selon 1SO 7816 car les mécanismes de sécurité associés à cc protocole sont fiables du fait de la longévité de ce type d'architecture. En évitant l'implémentation de protocole de communication plus récents tels que BLE ou NFC par exemple, la sécurité de l'élément sécurisé est renforcé tout en permettant à la carte à puce de fonctionner selon de multiples protocoles de communication externes. [0133] En outre, l'invention permet de d'adapter aisément les protocoles de communication externes supportés de la carte à puce sans qu'il soit nécessaire d'obtenir une nouvelle certification de l'unité de gestion puisque seules les interfaces de communication externes de l'unité de traitement sont impactécs. [0134] Un homme du métier comprendra que les modes de réalisation et variantes décrits ci- avant ne constituent que des exemples non limitatifs dc mise en oeuvre dc 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 dc répondre à un besoin bien particulier. 24 [Revendication I] [Revendication 2]