FR 2945142 A1 20101105 FR 0952962 A 20090504 1 Le domaine de l'invention est celui de la mise à jour par une banque émettrice de données d'une application de paiement sans contact, telle qu'une application de paiement sans contact embarquée au sein d'un terminal de téléphonie mobile. L'invention concerne plus précisément l'administration d'un compteur d'une application de paiement embarquée au sein d'un appareil apte à la fois à établir une liaison radio avec un réseau de communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, le compteur étant susceptible de dépasser un seuil prédéterminé alors que l'application de paiement est utilisée pour réaliser une transaction sans contact hors-ligne avec le lecteur externe. Par transaction hors-ligne, on entend dans ce qui suit la réalisation d'une transaction de paiement sans que celle-ci n'ait été approuvée par la banque émettrice de l'application de paiement. Un ou plusieurs compteurs cumulatifs hors-ligne sont typiquement associés à une application de paiement. Il s'agit par exemple d'un compteur cumulant les montants de transactions successives hors ligne, ou encore d'un compteur cumulant le nombre de transactions successives hors ligne. Ce compteur étant incrémenté à chaque transaction hors-ligne, il est amené à dépasser un seuil défini par la banque émettrice de l'application de paiement selon une politique de gestion de risque. En cas de dépassement du seuil, une autorisation de la banque émettrice doit en effet être obtenue afin de finaliser en ligne une transaction initialisée hors ligne. En d'autres termes, le terminal de paiement électronique avec lequel l'application de paiement dialogue doit aller en ligne pour obtenir l'autorisation d'approuver la transaction. Une fois qu'une réponse positive de la banque émettrice à l'autorisation de paiement est authentifiée par l'application de paiement, cette dernière réinitialise ce compteur en le remettant à zéro. Une application de paiement est typiquement intégrée dans une carte de paiement sous forme d'une carte plastique équipée d'une bande magnétique et/ou carte à puce. La carte de paiement interagissant par contact avec le terminal de paiement électronique (TPE), la réinitialisation des compteurs ne pose pas de problème particulier dans la mesure où la carte est physiquement présente au contact du TPE lorsque celui-ci reçoit l'autorisation de la banque émettrice. De nombreux travaux sont cependant menés aujourd'hui pour élaborer des solutions de paiement mobile sans contact ayant pour objectif de simplifier les paiements de proximité en mettant à disposition des utilisateurs un moyen rapide, simple et sûr pour effectuer leurs transactions de la vie 1 o quotidienne avec leurs téléphones mobiles. Ces solutions s'appuient sur une application de paiement répondant aux règles de fonctionnement de type carte bancaire, installée dans la carte SIM du téléphone mobile d'un utilisateur et sur la technologie sans contact NFC (� Near Field Communication � désignant une communication en 15 champ proche). Afin de réaliser la réinitialisation des compteurs, il est nécessaire pour ces solutions de paiement mobile sans contact que le téléphone mobile reste dans le champ NFC du TPE pendant que celui-ci sollicite en ligne l'autorisation de la banque émettrice, traite la réponse de la Banque 20 émettrice et transmet la réponse à l'application de paiement dans la carte SIM. Cela s'avère contraignant pour l'utilisateur qui doit maintenir son téléphone dans le champ du TPE sans contact pendant tout le processus d'autorisation en ligne et de réinitialisation des compteurs. Par ailleurs, ce 25 processus n'est alors plus transparent pour l'utilisateur. Afin de rendre le paiement sans contact moins contraignant pour l'utilisateur, il a été envisagé que celui-ci n'ait pas à maintenir son téléphone dans le champ du TPE sans contact pendant tout le processus d'autorisation en ligne mais qu'il soit invité à représenter son téléphone dans le champ du 30 TPE pour obtenir la réponse la banque émettrice. Cette solution n'est toutefois pas totalement satisfaisante dans la mesure où elle reste 3 contraignante pour l'utilisateur qui doit représenter sont téléphone dans le champ du TPE et où le processus d'autorisation en ligne reste non transparent pour l'utilisateur. L'invention a pour objectif de répondre à ces inconvénients, et propose à cet effet selon un premier aspect un procédé d'administration d'un compteur d'une application bancaire embarquée au sein d'un appareil apte à la fois à établir une liaison radio avec un réseau de communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, le procédé étant caractérisé par les étapes suivantes mises en 1 o oeuvre après dépassement d'un seuil par le compteur alors que l'application de paiement est utilisée pour réaliser une transaction sans contact hors-ligne avec le lecteur externe : - l'application de paiement simule une transaction de paiement, laquelle transaction nécessite une autorisation en ligne auprès d'un serveur bancaire 15 du fait du dépassement de seuil du compteur ; - un processus d'authentification mutuelle de l'application de paiement et du serveur bancaire est mis en oeuvre par l'intermédiaire de la liaison radio pour autoriser en ligne la transaction simulée ; - le compteur est réinitialisé en cas d'authentification mutuelle réussie. 20 Selon d'autres aspects, l'invention propose un module de gestion d'un groupe d'une ou plusieurs applications de paiement, une carte à puce dans laquelle sont stockées une application bancaire et le module de gestion associé, ainsi qu'à un système de réalisation de transaction de paiement mobile sans contact mettant en oeuvre le procédé selon le premier aspect. 25 D'autres aspects, buts et avantages de la présente invention apparaîtront mieux à la lecture de la description détaillée suivante de formes de réalisation préférées de celle-ci, donnée à titre d'exemple non limitatif, et faite en référence aux dessins annexés sur lesquels : - la figure 1 est un schéma illustrant le stockage de différentes 30 applications de paiement dans une carte à puce destinée à être insérée dans un terminal de téléphonie mobile pour offrir différentes solutions de paiement mobile sans contact ; - la figure 2 est un schéma illustrant les échanges de données lors d'une réinitialisation des compteurs conforme à un mode de réalisation possible de l'invention. Dans le cadre de l'invention, on considère une application de paiement embarquée au sein d'un appareil apte à la fois à établir une liaison radio avec un réseau de communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe (typiquement un terminal de paiement électronique sans contact). L'application de paiement dispose d'au moins un compteur qui est typiquement incrémenté à chaque transaction sans contact hors ligne en cumulant les montants des transactions ou le nombre de transactions. Dans un tel cas de figure, la réinitialisation du compteur consiste typiquement à le remettre à zéro. L'invention n'est toutefois pas limitée à l'incrémentation de compteurs, mais concerne également la décrémentation de compteurs pouvant être amenés à passer sous un seuil. La réinitialisation consiste ici à remettre le compteur à sa valeur initiale non nulle. Dans ce qui suit, on parlera de dépassement d'un seuil pour qualifier aussi bien le cas où un compteur est incrémenté de telle manière à venir passer au dessus d'un seuil que le cas où un compteur est décrémenté de telle manière à passer sous un seuil. L'appareil est typiquement un terminal de téléphonie mobile 1 disposant d'un contrôleur NFC et dans lequel peut être logée une carte UICC 2. On comprendra cependant que l'invention n'est pas limitée par le type de dispositif pouvant être utilisé ni par le type de technologie sans contact. En référence à la figure 1, on a ainsi représenté un terminal de téléphonie mobile 1 dans lequel une carte à puce 2 de type carte UICC (Universal Integrated Circuit Gard), par exemple une carte SIM ou une carte USIM, stockant les informations spécifiques à l'abonné d'un réseau mobile peut être insérée pour gérer l'authentification de l'abonné dans le réseau. Dans le cadre de l'invention, le terminal de téléphonie mobile peut être doté de plusieurs solutions de paiement. Comme cela est représenté à titre d'exemple sur la figure 1, le terminal 1 peut utiliser une première solution de paiement proposée par une Banque 1 et une seconde solution de paiement 5 proposée par une Banque 2. Chaque solution de paiement est composée : - d'une carte de paiement virtuelle stockée dans la carte à puce 2 ; - d'une interface homme machine (IHM) (10 pour la banque 1 et 20 pour la banque 2) dédiée à sa propre solution de paiement (respectivement 12 et 21) stockée dans le terminal 1. L'IHM offre différents outils de gestion de la carte de paiement virtuelle à laquelle elle est associée. Elle permet en particulier à l'utilisateur d'activer ou désactiver la ou les applications de la carte de paiement virtuelle, de réaliser un paiement, de modifier un code personnel, de visualiser les paiements réalisés, etc. Une carte de paiement virtuelle peut comprendre un groupe d'une ou plusieurs applications de paiement et un module de gestion du groupe Comme représenté à titre d'exemple sur la figure 1, la solution de paiement de la Banque 1 comprend une application de paiement locale 12a et une application de paiement internationale 12b, et un module de gestion 11 de ces applications 12a, 12b. L'application de paiement locale est typiquement utilisée pour réaliser des transactions sur le marché domestique de la Banque 1, tandis que l'application de paiement internationale est typiquement utilisée lorsque l'utilisateur se trouve à l'étranger. La solution de paiement de la Banque 2 ne comprend quant à elle qu'une seule application 22 et un module de gestion 21 de cette application 22. On relèvera que le stockage et l'exécution des applications dans la carte 2 peuvent être réalisés d'une manière connue en soi sur la base du SIM Application Toolkit (USIM Application Toolkit dans le cas de l'UMTS) et d'un environnement applicatif Java Gard. De manière connue en soi, la carte 2 contient plusieurs domaines de sécurité (Security Domains), à savoir un domaine de sécurité de l'émetteur de la carte (Issuer Security Domain - ISD) et un ou plusieurs domaines de sécurité supplémentaires (Supplementary Security Domains - SSD) tels que définis dans la norme � GlobalPlatform Gard Specifications v.2.2 �. Chaque fournisseur d'applications dispose ainsi de la possibilité de stocker et de gérer ses propres applications dans un environnement sécurisé dont il est le seul responsable. En particulier, un domaine de sécurité supplémentaire peut être dédié à une solution de paiement d'une banque. On relèvera qu'un module de gestion d'un groupe d'applications a pour objectif de remplir des fonctions spécifiques à une solution de paiement mobile sans contact dans la mesure où ces fonctions ne sont pas couvertes par les applications de paiement. L'invention n'est toutefois pas limitée à un module de gestion de groupe indépendant d'une application de paiement, et s'étend également au cas où une application de paiement peut elle-même réaliser les fonctions spécifiques au paiement mobile sans contact, le module de gestion de groupe y étant de la sorte intégré. Dans le cadre de l'invention, et comme cela sera détaillé plus en avant par la suite, le module de gestion de chaque groupe comprend un � émulateur de transaction de paiement � configuré pour, après dépassement d'un seuil par le compteur d'une application de paiement du groupe, lorsque l'application bancaire est utilisée pour réaliser une transaction sans contact hors-ligne avec le lecteur externe : - simuler une transaction de paiement, laquelle transaction nécessite une autorisation en ligne auprès d'un serveur bancaire du fait du dépassement de seuil du compteur ; - mettre en oeuvre un processus d'authentification mutuelle de l'application bancaire et du serveur bancaire par l'intermédiaire de la liaison radio pour autoriser en ligne la transaction simulée ; - réinitialiser le compteur en cas d'authentification mutuelle réussie. On a représenté de manière schématique sur la figure 2 les échanges de données lors d'une transaction de réinitialisation des compteurs conforme à un mode de réalisation possible de l'invention, entre une application de paiement 3, un module de gestion 4 de l'application de paiement, un terminal de paiement sans contact 5 et un serveur d'autorisation de la banque émettrice 6. Ces échanges comprennent trois phases : - une première phase � NFC � de transaction de paiement au cours de laquelle l'application 3 dialogue via l'interface sans contact avec le terminal 1 o de paiement 5 ; - une seconde phase � OTA � (selon la terminologie anglo-saxonne Over The Air) au cours de laquelle l'application et le serveur bancaire 6 dialoguent via l'interface radio afin d'initier la procédure de réinitialisation du compteur. - une troisième phase de réinitialisation du compteur. 15 On relèvera que la figure 2 et la description qui suit présentent dans un souci de clarté ces différents échanges de manière simplifiée. Sur cette figure 2, une transaction sans contact hors ligne, illustrée par les flèches 31 et 32, entre l'application 3 et le terminal de paiement 5 entraîne le dépassement du seuil d'un compteur cumulatif de l'application de 20 paiement (événement A sur la figure 2). Du fait du dépassement du seuil, l'application de paiement 3 requiert une autorisation en ligne auprès du serveur bancaire pour finaliser la transaction. L'application 3 génère alors de manière classiquement connue 25 (événement B) un cryptogramme de requête d'autorisation (ARQC ù Autorisation ReQuest Cryptogram), noté ARQC 1 dans ce qui suit, qui est transmis à la banque émettrice dans une requête d'autorisation émise par le terminal de paiement 5. Sur la figure 2, les flèches 33 et 34 illustrent la fourniture du cryptogramme ARQC 1 au terminal 5 par l'intermédiaire de la 30 liaison sans contact. La flèche 35 illustre quant à elle la requête d'autorisation transmise par le terminal de paiement 5 au serveur bancaire 6 dont un attribut est le cryptogramme ARQC 1 généré par l'application bancaire lors de la transaction sans contact hors ligne. Le serveur bancaire 6 procède alors à la vérification du cryptogramme ARQC 1 (événement C) et retourne (flèche 36) un code de réponse d'autorisation (ARC 1: Authorisation Response Code) au terminal de paiement 5 sans données d'identification de l'émetteur (Issuer Authentication Data), et par conséquent sans cryptogramme de réponse d'autorisation (ARPC : Autorisation ResPonse Cryptogram). Le terminal de paiement approuve alors la transaction (événement D) 1 o sans qu'une authentification de la banque émettrice ne soit réalisée. Via l'événement E, le serveur bancaire 6 élabore une requête d'activation de l'émulateur de transaction de paiement du module de gestion associé à l'application de paiement. Cette requête est transmise directement (flèche 37) à l'appareil par l'intermédiaire de la liaison radio (canal OTA : 15 Over The Air). L'émulateur de transaction du module de gestion 4 simule alors une transaction de paiement, typiquement une transaction de montant nul. L'émulateur lance ainsi (flèche 38) une transaction de paiement avec l'application de paiement associée 3 et demande la génération d'un 20 cryptogramme de requête d'autorisation en ligne. L'application de paiement 3 génère (événement F) à nouveau un cryptogramme de requête d'autorisation, dit cryptogramme de requête d'autorisation en ligne et noté ARQC 2. Le cryptogramme ARQC 2 généré par l'application de paiement 3 est fourni à l'émulateur (flèche 39), lequel transmet (flèche 40) une requête 25 d'autorisation au serveur bancaire 6 dont un attribut est le cryptogramme ARQC 2 généré par l'application de paiement lors de la demande d'autorisation en ligne de la transaction simulée. Le serveur bancaire procède alors (événement G) à la vérification du cryptogramme ARQC 2 de manière à authentifier l'application de paiement 3 30 et au calcul du cryptogramme de réponse d'autorisation ARPC 2 correspondant. Le serveur bancaire élabore ensuite une requête de réinitialisation des compteurs comprenant des données d'authentification de la banque émettrice (incluant l'ARPC 2) ainsi qu'un code de réponse d'autorisation ARC 2 et envoie l'ensemble (flèche 41), via l'interface radio OTA, au module de gestion 4. L'émulateur de transaction de paiement transmet alors à l'application concernée dans la même session (flèche 42) les données d'authentification de la banque émettrice (incluant l'ARPC 2) en utilisant la commande d'authentification dédiée, ainsi que l'ARC 2. 1 o L'application de paiement (3) procède alors (événement H) à la vérification du cryptogramme de réponse d'autorisation ARPC 2 en utilisant le cryptogramme de requête d'autorisation ARQC 2 qu'elle a généré et le code de réponse d'autorisation ARC 2 retourné par la banque émettrice avec les données d'authentification de la banque émettrice. 15 Si la vérification est positive, la transaction de paiement simulée peut alors être autorisée et le compteur peut être réinitialisé. La flèche 43 illustre ainsi la réponse à l'authentification de la banque émettrice fournie par l'application de paiement à l'émulateur de transaction. Ainsi, dans le cadre de l'invention, l'application bancaire simule une 20 transaction de paiement, laquelle transaction nécessite une autorisation en ligne auprès d'un serveur bancaire. Un processus d'authentification mutuelle de l'application bancaire et du serveur bancaire est alors mis en oeuvre par l'intermédiaire de la liaison radio pour autoriser en ligne la transaction simulée et réinitialiser le compteur en cas d'authentification mutuelle réussie. 25 Selon un mode de réalisation possible de l'invention, la réinitialisation du compteur d'une application de paiement impose la vérification d'un code personnel lors de la prochaine transaction de paiement sans contact réalisée avec l'application de paiement. Un indicateur stocké dans le module de gestion de l'application peut à ce titre être levé de manière à forcer la saisie 30 d'un code personnel (via l'IHM correspondante) quelque soient les préférences de l'utilisateur. On notera que dans la mesure où la 2945142 le réinitialisation des compteurs s'opère dans le cadre de l'invention de manière transparente pour l'utilisateur, l'obligation de saisir le code personnel lui apparaîtra comme une mesure de sécurité mise en oeuvre de manière aléatoire. 5 On retiendra par ailleurs que l'invention présente l'avantage de peu impacter l'architecture du serveur bancaire (type SAE : SAE û Serveur d'Autorisation Emetteur), notamment par rapport à une solution ne mettant pas en oeuvre de simulation de transaction et selon laquelle une authentification mutuelle de l'application et du serveur bancaire serait réalisée sur la base du cryptogramme de requête d'autorisation ARQC 1 généré par l'application bancaire lors de la demande d'autorisation de transaction sans contact hors ligne (le serveur bancaire devant alors mettre en oeuvre le calcul d'un cryptogramme de requête d'autorisation ARPC correspondant au cryptogramme ARQC 1 reçu via le canal NFC et le transmettre dans la foulée via OTA à l'application de paiement). L'invention n'est en outre pas limitée à un procédé selon son premier aspect, mais s'étend également à une carte à puce dans laquelle sont stockées une application bancaire et le module de gestion (intégrant l'émulateur) associé, au module de gestion ainsi qu'à un système de réalisation de transaction de paiement mobile sans contact mettant en oeuvre le procédé selon le premier aspect. L'invention concerne également un procédé dans lequel : - lors de la simulation de transaction, l'application de paiement génère un cryptogramme de requête d'autorisation en ligne ARQC 2 ; l'appareil transmet le cryptogramme de requête d'autorisation par l'intermédiaire de la liaison radio au serveur bancaire le serveur bancaire authentifie l'application de paiement à partir du cryptogramme de requête d'autorisation et génère un cryptogramme de réponse d'autorisation ARPC 2 ; - le serveur bancaire transmet une requête de réinitialisation du compteur à l'application de paiement par l'intermédiaire de la liaison radio, ladite requête comprenant le cryptogramme de réponse d'autorisation ; - l'application de paiement vérifie l'authenticité du serveur bancaire en utilisant le cryptogramme de requête d'autorisation (ARQC 2) qu'elle a généré lors de la demande d'autorisation en ligne de la transaction simulée et le cryptogramme de réponse (ARPC 2) qu'elle a reçu, et procède en cas de vérification positive à la réinitialisation du compteur. L'invention concerne également un procédé dans lequel la transaction sans contact hors ligne est finalisée par la mise en oeuvre des étapes suivantes préalablement à la simulation de la transaction de paiement : un cryptogramme de requête d'autorisation ARQC 1 généré par l'application de paiement lors de la demande d'autorisation de la transaction sans contact hors ligne est transmis par l'appareil au lecteur externe via la liaison sans contact, puis du lecteur externe au serveur bancaire ; - le serveur bancaire authentifie l'application de paiement à partir dudit cryptogramme de requête d'autorisation, génère un code de réponse d'autorisation ARC 1 et transmet le code de réponse d'autorisation au lecteur externe ; le lecteur externe approuve la transaction. L'invention concerne également un procédé dans lequel la simulation de la transaction de paiement est mise en oeuvre après réception via la liaison radio par un émulateur de transaction de paiement associé à l'application de paiement d'une requête d'activation issue du serveur bancaire. L'invention concerne également un procédé dans lequel le serveur bancaire génère ladite requête d'activation suite à la réception d'une requête d'autorisation pour la finalisation de la transaction sans contact hors ligne. L'invention concerne également un procédé dans lequel la transaction simulée est une transaction de montant nul. L'invention concerne également un procédé dans lequel la réinitialisation du compteur impose la vérification d'un code personnel lors de la prochaine transaction de paiement sans contact réalisée avec l'application de paiement. L'invention concerne également un module de gestion destiné à être associé à un groupe d'une ou plusieurs applications de paiement embarqué dans un appareil apte à la fois à établir une liaison radio avec un réseau de communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, chaque application de paiement pouvant être utilisée pour réaliser une transaction sans contact entre le lecteur externe et l'appareil et disposant d'un compteur, caractérisé en ce qu'il comporte un émulateur de transaction de paiement configuré pour, après dépassement d'un seuil par le compteur d'une application de paiement du groupe lorsque l'application de paiement est utilisée pour réaliser une transaction sans contact hors-ligne avec le lecteur externe, simuler une transaction de paiement, laquelle transaction nécessite une autorisation en ligne auprès d'un serveur bancaire du fait du dépassement de seuil du compteur ; mettre en oeuvre un processus d'authentification mutuelle de l'application de paiement et du serveur bancaire par l'intermédiaire de la liaison radio pour autoriser en ligne la transaction simulée ; réinitialiser le compteur en cas d'authentification mutuelle réussie. L'invention concerne également une carte à puce destinée à être utilisée dans un appareil apte à la fois à établir une liaison radio avec un réseau de communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, comprenant au moins un groupe d'une ou plusieurs applications de paiement pouvant être sélectionné pour que l'une des applications du groupe puisse être utilisée pour réaliser une transaction sans contact entre l'appareil et le lecteur externe, un compteur étant associé à chaque application caractérisée en ce qu'elle comporte un module de gestion conforme à l'aspect précédemment évoqué de l'invention associé à chaque groupe. L'invention concerne également un appareil apte à la fois à établir une liaison radio avec un réseau de communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, embarquant une carte à puce conforme à un aspect de l'invention.10 REVENDICATIONS1. Procédé d'administration d'un compteur d'une application bancaire embarquée au sein d'un appareil apte à la fois à établir une liaison radio avec un réseau de communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, le procédé étant caractérisé par les étapes suivantes mises en oeuvre après dépassement d'un seuil par le compteur alors que l'application de paiement est utilisée pour réaliser une transaction sans contact hors-ligne avec le lecteur externe : - l'application de paiement simule une transaction de paiement, laquelle transaction nécessite une autorisation en ligne auprès d'un serveur bancaire du fait du dépassement de seuil du compteur ; - un processus d'authentification mutuelle de l'application de paiement et du serveur bancaire est mis en oeuvre par l'intermédiaire de la liaison radio pour autoriser en ligne la transaction simulée ; - le compteur est réinitialisé en cas d'authentification mutuelle réussie. 2. Procédé selon la revendication 1, dans lequel : - lors de la simulation de transaction, l'application de paiement génère un cryptogramme de requête d'autorisation en ligne (ARQC 2) ; - l'appareil transmet le cryptogramme de requête d'autorisation par l'intermédiaire de la liaison radio au serveur bancaire ; - le serveur bancaire authentifie l'application de paiement à partir du 25 cryptogramme de requête d'autorisation et génère un cryptogramme de réponse d'autorisation (ARPC 2) ; - le serveur bancaire transmet une requête de réinitialisation du compteur à l'application de paiement par l'intermédiaire de la liaison radio, ladite requête comprenant le cryptogramme de réponse d'autorisation ; 30 - l'application de paiement vérifie l'authenticité du serveur bancaire en utilisant le cryptogramme de requête d'autorisation (ARQC 2) qu'elle a généré lors de la demande d'autorisation en ligne de la transaction simulée et le cryptogramme de réponse (ARPC 2) qu'elle a reçu, et procède en cas de vérification positive à la réinitialisation du compteur. 3. Procédé selon l'une des revendications précédentes, dans lequel la transaction sans contact hors ligne est finalisée par la mise en oeuvre des étapes suivantes préalablement à la simulation de la transaction de paiement : un cryptogramme de requête d'autorisation (ARQC 1) généré par l'application de paiement lors de la demande d'autorisation de la transaction sans contact hors ligne est transmis par l'appareil au lecteur externe via la liaison sans contact, puis du lecteur externe au serveur bancaire ; - le serveur bancaire authentifie l'application de paiement à partir dudit cryptogramme de requête d'autorisation, génère un code de réponse d'autorisation (ARC 1) et transmet le code de réponse d'autorisation au lecteur externe ; le lecteur externe approuve la transaction. 4. Procédé selon l'une des revendications précédentes, dans lequel la simulation de la transaction de paiement est mise en oeuvre après réception via la liaison radio par un émulateur de transaction de paiement associé à l'application de paiement d'une requête d'activation issue du serveur bancaire. 5. Procédé selon la revendication précédente, dans lequel le serveur bancaire génère ladite requête d'activation suite à la réception d'une requête d'autorisation pour la finalisation de la transaction sans contact hors ligne. 6. Procédé selon l'une des revendications précédentes, dans lequel la transaction simulée est une transaction de montant nul. 7. Procédé selon l'une des revendications précédentes, dans lequel la réinitialisation du compteur impose la vérification d'un code personnel lors de la prochaine transaction de paiement sans contact réalisée avec l'application de paiement. 8. Module de gestion destiné à être associé à un groupe d'une ou plusieurs applications de paiement embarqué dans un appareil apte à la fois à établir une liaison radio avec un réseau de communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, chaque application de paiement pouvant être utilisée pour réaliser une transaction sans contact entre le lecteur externe et l'appareil et disposant d'un compteur, caractérisé en ce qu'il comporte un émulateur de transaction de paiement configuré pour, après dépassement d'un seuil par le compteur d'une application de paiement du groupe lorsque l'application de paiement est utilisée pour réaliser une transaction sans contact hors-ligne avec le lecteur externe, - simuler une transaction de paiement, laquelle transaction nécessite une autorisation en ligne auprès d'un serveur bancaire du fait du dépassement de seuil du compteur ; - mettre en oeuvre un processus d'authentification mutuelle de l'application de paiement et du serveur bancaire par l'intermédiaire de la liaison radio pour autoriser en ligne la transaction simulée ; - réinitialiser le compteur en cas d'authentification mutuelle réussie. 9. Carte à puce destinée à être utilisée dans un appareil apte à la fois à établir une liaison radio avec un réseau de communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, comprenant au moins un groupe d'une ou plusieurs applications de paiement pouvant être sélectionné pour que l'une des applications du groupe puisse être utilisée pour réaliser une transaction sans contact entre l'appareil et le lecteur externe, un compteur étant associé à chaque application caractérisée en ce qu'elle comporte un module de gestion (12, 22) conforme à la revendication précédente associé à chaque groupe. 2945142 1/ 10. Appareil apte à la fois à établir une liaison radio avec un réseau de communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, embarquant une carte à puce selon la revendication précédente. 5 11. Système de réalisation de transaction de paiement mobile sans contact, comprenant : - un lecteur externe ; - un appareil apte à la fois à établir une liaison radio avec un réseau de 10 communication mobile et à communiquer par l'intermédiaire d'une liaison sans contact avec le lecteur externe ; - un serveur bancaire relié au lecteur externe et également apte à dialoguer avec l'appareil par l'intermédiaire de la liaison radio ; - au moins une application de paiement disposant d'un compteur embarquée 15 au sein de l'appareil et pouvant être utilisée par l'appareil pour réaliser une transaction de paiement sans contact hors-ligne avec le lecteur externe, caractérisé en ce qu'un émulateur de transaction de paiement associé à l'application de paiement est configuré pour, après dépassement de seuil du compteur au cours d'une transaction sans contact hors-ligne, simuler une 20 transaction de paiement, laquelle transaction nécessite une autorisation en ligne auprès du serveur bancaire du fait du dépassement de seuil du compteur, en ce que l'émulateur et le serveur bancaire sont configurés pour mettre en oeuvre un processus d'authentification mutuelle par l'intermédiaire de la liaison radio pour autoriser en ligne la transaction simulée, et en ce que l'émulateur est en outre 25 configuré pour réinitialiser le compteur en cas d'authentification mutuelle réussie.