FR 2945141 A1 20101105 FR 0952960 A 20090504 Le domaine de l'invention est celui des solutions de paiement sans contact dans lesquelles des transactions de paiement sont effectuées entre un appareil mobile et un lecteur externe. L'invention concerne des applications de paiement sans contact activées pour qu'un appareil, tel qu'un appareil de téléphonie mobile, dans lequel les applications sont stockées puisse réaliser des transactions de paiement sans contact avec un lecteur externe de type terminal de paiement électronique. Plus particulièrement encore, l'invention concerne un processus de gestion d'une application de paiement sans contact activée nécessitant la vérification d'un code personnel pour la finalisation de la transaction. De nombreux travaux sont aujourd'hui menés pour élaborer des solutions de paiement mobiles 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 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 champ proche). On connaît du document WO 2008/086421 Al, un procédé de gestion d'une application de paiement sans contact au sein d'un appareil mobile, lequel procédé comprend les étapes suivantes : - entrée d'une limite de temps prédéterminée dans le téléphone mobile, - activation d'une application de paiement mobile associée avec le téléphone mobile, - désactivation de ladite application, une fois la limite de temps prédéterminée dépassée. On relèvera en premier lieu que ce document est relativement silencieux quant à l'implémentation pratique de ce procédé de gestion de l'application. Et on relèvera surtout que le procédé proposé par ce document n'est applicable que pour des scénarios dans lesquels l'application n'est activée que pour une seule transaction. Ce document ne traite effectivement pas du cas d'un mode d'exécution dans lequel l'application est en permanence active (mode d'exécution appelé � always on � selon lequel l'application de paiement peut directement être mise en oeuvre dans le cadre d'une session de paiement, ladite session étant par exemple initiée lorsque le terminal mobile est placé à proximité d'un terminal de paiement sans contact ou lorsque l'utilisateur du terminal mobile sélectionne manuellement une fonction de paiement pour la réalisation de la session avec l'application active). Or les solutions de paiement mobile sans contact aujourd'hui envisagées préconisent de pouvoir utiliser les applications de paiement dans n'importe quelle situation sans avoir forcément à les activer manuellement au préalable à chaque transaction. On notera par ailleurs que la solution préconisée par le document précité n'est pas entièrement satisfaisante en ce que, dans le cas d'un dépassement de la limite de temps, elle nécessite une réactivation manuelle de l'application pour toute nouvelle transaction envisagée. L'invention a donc pour objectif de résoudre ces inconvénients afin de proposer un procédé de gestion d'un groupe d'une ou plusieurs applications de paiement permettant de maintenir la ou les applications du groupe actives sans pour autant réduire le niveau de sécurité attendu quant à l'utilisation d'une application du groupe D'une manière plus générale, l'invention a pour objectif d'offrir à un groupe d'applications de paiement différents services nécessaires à la mise en oeuvre d'une solution de paiement mobile sans contact, en particulier un service de vérification d'un code personnel. A cet effet, l'invention propose selon un premier aspect un procédé pour la gestion d'une application de paiement sans contact active embarquée au sein d'un appareil apte à établir une communication sans contact avec un terminal de paiement sans contact, comprenant les étapes suivantes : - suite à l'initialisation d'une session de paiement mettant en oeuvre l'application de paiement sans contact, saisie d'un code personnel via une interface; ù vérification du code personnel saisi par un module de gestion associé à un groupe d'une ou plusieurs applications comprenant l'application mise en oeuvre dans la session de paiement, et en cas de vérification positive, renseignement par le module de gestion d'un indicateur de vérification du code personnel ; ù lecture de l'indicateur par l'application et finalisation de la session de paiement si l'indicateur est renseigné ; ù réinitialisation de l'indicateur une fois la session finalisée. Avantageusement mais facultativement, l'invention comprend au moins l'une des caractéristiques suivantes : - le procédé comprend les étapes suivantes mises en oeuvre en cas de vérification positive du code personnel : ^ démarrage d'un compteur de temps; ^ dans le cas où la session de paiement n'est pas finalisée une fois une limite de temps prédéterminée atteinte par le compteur, fermeture de la session de paiement tandis que l'application reste active de manière à pouvoir directement être mise en oeuvre pour une nouvelle session de paiement. - l'initialisation de la session de paiement fait suite à une étape de communication sans contact entre l'appareil et un terminal de paiement ; - l'initialisation de la session de paiement met en oeuvre une sélection de l'application de paiement par le terminal de paiement parmi la ou les applications de paiement actives ; - l'initialisation de la session de paiement fait suite à la sélection, via l'interface, par un utilisateur de l'appareil, de l'application de paiement parmi la ou les applications de paiement actives. - la fermeture de la session de paiement entraîne la fermeture de l'interface ; 30 - le procédé comprend en outre les étapes suivantes : une fois le code saisi, envoi par l'interface, à destination d'un module de gestion associé à un groupe d'une ou plusieurs applications de paiement sans contact comprenant l'application destinée à être mise en oeuvre dans la session de paiement, d'une commande de vérification du code saisi ; vérification du code saisi par le module de gestion : en cas de succès de la vérification, envoi par le module de gestion à l'interface d'une commande de démarrage du compteur de temps. - en cas de vérification positive du code saisi par le module de gestion, le module de gestion renseigne un indicateur de vérification du code personnel ; - suite à la fermeture ou à la finalisation de la session de paiement, le module de gestion réinitialise l'indicateur de vérification du code personnel ; Selon d'autres aspects, l'invention s'étend à un module de gestion d'un groupe d'applications ainsi qu'à une carte à puce stockant un tel module et à un appareil hébergeant une telle carte à puce. 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 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 représentant de manière plus détaillée une solution de paiement mobile sans contact mettant en oeuvre un appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un terminal de paiement sans contact ; - la figure 3 représente un premier mode de réalisation possible du procédé selon le premier aspect de l'invention - la figure 4 représente un second mode de réalisation possible du procédé selon le premier aspect de l'invention - la figure 5 illustre les communications conformes à un mode de réalisation possible de l'invention entre une interface utilisateur et un module de gestion associé à l'application de paiement sans contact. En référence à la figure 1, on a représenté un terminal de téléphonie mobile 1 dans lequel une carte à puce 2 de type carte UICC (Universal Integrated Circuit Card), 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 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 A et, facultativement, une seconde solution de paiement proposée par une Banque B. Chaque solution de paiement est composée d'une carte de paiement virtuelle stockée dans la carte 2 et d'une interface homme machine (IHM) dédiée à la solution de paiement qui est stockée dans le terminal 1 ou la carte 2. 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 une ou plusieurs applications de paiement. Comme représenté à titre d'exemple sur la figure 1, la solution de paiement de la Banque A comprend une application de paiement locale et une application de paiement internationale. 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 Card. La figure 2 représente de manière plus détaillée une solution de paiement mobile sans contact mettant en oeuvre un dispositif apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe. Le dispositif est typiquement un terminal de téléphonique mobile 1 disposant d'un contrôleur NFC 3 et dans lequel peut être logée une carte UICC 2. On comprendra cependant que l'invention n'est pas limité par le type de dispositif pouvant être utilisé ni par le type de technologie sans contact. 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 a ainsi représenté sur la figure 2, le domaine ISD 4 et deux domaines supplémentaires 11, 21 chacun dédié à une solution de paiement. Le domaine ISD contient de manière classiquement connue en soi l'application SIM ou USIM permettant de gérer l'authentification de l'abonné auprès du réseau. Chaque domaine de sécurité supplémentaire alloué à une banque 11, 21 contient un groupe d'une ou plusieurs applications 13a, 13b ; 23 et un module de gestion 12, 22 du groupe. En conservant l'exemple de la figure 1, le domaine de sécurité supplémentaire 11 est par exemple alloué à la Banque A. Il contient un groupe d'applications comprenant une application de paiement locale 13a et une application de paiement internationale 13b, ainsi qu'un module de gestion du groupe 12. Le domaine de sécurité supplémentaire 21 est quant à lui alloué à la Banque B et contient un groupe comprenant une seule application de paiement 23, ainsi qu'un module de gestion du groupe 22. On relèvera qu'un module de gestion de groupe 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é. Différentes interfaces homme-machine (typiquement des applets Java) sont par ailleurs chargées dans le terminal 1 ou la carte 2. / Comme déjà décrit précédemment, une interface sous la responsabilité d'une banque est dédiée à chacune des solutions de paiement embarquées dans la carte. Cette interface est ainsi reliée de manière sécurisée à un unique domaine de sécurité supplémentaire dans la carte et offre différents outils de gestion à l'utilisateur, en particulier la possibilité d'activer ou désactiver la carte de paiement virtuelle, de réaliser un paiement, de modifier un code personnel, de visualiser les paiements réalisés, etc. On a représenté sur la figure 2, deux interfaces 10, 20 de ce type (dénommées IHM Banque dans ce qui suit) reliées respectivement à un domaine de sécurité supplémentaire 11, 21. / Une interface 9 (dénommée IHM Opérateur dans ce qui suit) sous la responsabilité de l'opérateur permettant à l'utilisateur de visualiser tous les services NFC stockés dans la carte et de lancer, suite à une sélection réalisée par l'utilisateur, l'IHM Banque correspondante. L'interface 9 est apte à dialoguer avec un module 6 de listage des applications, hébergé dans la carte UICC, par exemple dans le domaine ISD. On a également représenté sur la figure 2 le système d'exploitation 30 de la carte 2 lequel met notamment en oeuvre une interface de contrôleur NFC et un environnement répondant aux spécifications � GlobalPlatform �. Dans le cadre de l'invention un module de gestion comprend : un espace mémoire stockant un code de référence commun aux applications de paiement du groupe et un indicateur de vérification du code personnel ; des moyens pour confronter le code de référence avec un code personnel saisi via l'interface IHM Banque correspondante; des moyens configurés pour renseigner l'indicateur en cas de confrontation positive et pour réinitialiser l'indicateur suite à la fermeture ou à la finalisation d'une session de paiement mise en oeuvre avec une application du groupe ; des moyens formant interface commune permettant de rendre accessible l'indicateur aux applications du groupe. Le module de gestion offre ainsi aux différentes applications du groupe un service de vérification du code personnel. Selon un mode de réalisation possible, le module de gestion peut en outre être configuré pour offrir aux différentes applications du groupe un service d'agrégation et de mise à disposition de l'utilisateur (typiquement via l'IHM Banque correspondante) des transactions de paiement archivées au niveau de chaque application de paiement. Le module de gestion peut en particulier être configuré de manière à ajouter à l'enregistrement d'une transaction l'identifiant de l'application de paiement concernée de manière à permettre à l'IHM Banque d'identifier les paiements (par exemple paiements locaux, paiements internationaux, etc.). Typiquement l'utilisateur consulte via l'IHM Opérateur 9 une liste des différentes solutions de paiement susceptibles d'être utilisées pour réaliser une transaction de paiement sans contact entre le terminal mobile 1 et un lecteur externe, tel qu'un terminal de paiement électronique doté de moyens pour établir une liaison sans contact. La sélection par l'utilisateur d'une solution de paiement dans la liste va alors entraîner le lancement de l'interface Banque 10, 20 correspondant à la solution de paiement sélectionnée. A titre d'exemple, la sélection via l'IHM Opérateur 9 de la solution de paiement offerte par la Banque A va entraîner le lancement de l'IHM Banque 10, tandis que la sélection de la solution de paiement offerte par la Banque B va entraîner le lancement de l'IHM Banque 20. L'utilisateur visualise alors un menu dans lequel différents outils d'administration de la solution de paiement sont proposés : activation/désactivation de la solution, saisie de code personnel, changement de code personnel, consultation d'un historique de transaction, etc. L'utilisateur choisit ainsi via l'IHM Banque d'activer la solution de paiement correspondante. On prendra dans ce qui suit l'exemple de l'activation via l'IHM Banque 20 de la solution de paiement de la Banque B. En référence à la figure 3, et selon une réalisation possible de la présente invention, une fois l'application de paiement activée, cette dernière reste en attente d'une communication sans contact avec un terminal de paiement sans contact (étape 300). Ainsi, lorsque l'utilisateur U veut réaliser une transaction (également dénommée session de paiement dans ce qui suit) par exemple pour régler ses achats, il initialise une session de paiement en établissant une communication entre son appareil mobile 1 et un terminal de paiement sans contact en mettant son appareil mobile à proximité du terminal de paiement. Le module NFC de l'appareil mobile 3 rentrant dans la zone de communication du terminal de paiement sans contact, une communication est établie entre le terminal de paiement et l'application de paiement de l'appareil mobile, permettant à ladite application de récupérer les informations nécessaires à la transaction. Dans le cadre de ce mode de réalisation, l'initialisation de la session de paiement peut mettre en oeuvre une sélection de l'application de paiement par le terminal de paiement parmi la ou les applications de paiement actives. C'est notamment le cas lorsqu'un groupe d'applications est actif, par exemple lorsque le groupe est formé d'une application de paiement locale et d'une application de paiement internationale. Le terminal de paiement est alors avisé des identifiants des applications actives, et choisit selon des règles connues en soi, l'application active avec laquelle la transaction doit être réalisée (par exemple l'application internationale lorsque l'utilisateur se trouve à l'étranger). Afin de s'assurer de l'identité de l'utilisateur U, un code personnel d'identification (PIN) est demandé à ce dernier. Une fois le code d'identification saisi et vérifié (étape 302), un compteur de temps 303 est lancé avec en paramètre une limite de temps 307 prédéterminée. Selon un mode de réalisation possible, l'application de paiement devant être utilisée pour la réalisation de la session de paiement transmet, par exemple après détermination qu'une vérification d'un code personnel est nécessaire, au module de gestion à laquelle elle est associée un événement permettant de réveiller l'IHM Banque avec un paramètre correspondant à une requête de vérification de code personnel. En référence à la figure 5, l'exécution du compteur de temps est initiée par le module de gestion 22. Pour ce faire, ce dernier envoie à l'IHM Banque 20 les informations nécessaires à l'activation du compteur de temps via une communication 50. Par exemple, il peut être prévu que le module de gestion 22 envoie à l'IHM Banque les informations relatives à la limite de temps liée au compteur de temps. Ainsi, l'IHM Banque 20 exécute le compteur de temps et la surveillance de la limite de temps sous ordre du module de gestion 22. L'IHM Banque invite alors l'utilisateur à rentrer son code personnel (par exemple à travers un message affiché sur un moyen d'affichage 201 de l'appareil mobile, tel qu'un écran LCD). Une fois le code rentré par l'utilisateur à l'aide par exemple d'un clavier alphanumérique 202 de l'appareil mobile 1, l'IHM Banque 20 envoie au module de gestion 22 une commande de vérification 54 du code rentré par l'utilisateur. En cas de succès de la vérification opérée par le module de gestion (le code saisi par l'utilisateur étant confronté à un code stocké dans le module de gestion 22), le module de gestion 22 enregistre le résultat de cette vérification par exemple en renseignant un indicateur de vérification du code personnel 222 indiquant l'état de vérification du code personnel (par exemple, la valeur de cet indicateur, par défaut à 0, est alors fixée à 1, signifiant alors que le code rentré par l'utilisateur a bien été vérifié et qu'une transaction peut être finalisée). Une fois le code vérifié avec succès, le module de gestion 22 signale à l'IHM Banque 20 le succès de cette vérification via une communication 58, afin qu'avantageusement l'IHM Banque 20 puisse le notifier à l'utilisateur via le moyen d'affichage 201. Durant l'activité du compteur de temps et avant que la limite de temps ne soit dépassée, l'utilisateur doit en principe ré-effectuer une communication entre l'appareil mobile et le terminal de paiement afin de finaliser la transaction, en approchant l'appareil mobile 1 du terminal de paiement. Dans le cas où une telle communication n'est pas effectuée (étape 305), l'IHM Banque 20 signale au module de gestion le dépassement de la limite de temps via une communication 56. En conséquence de cette communication, le module de gestion 22 fixe la valeur de l'indicateur de vérification du code personnel 222 à 0, signifiant que le code n'est plus considéré comme vérifié et qu'en conséquence la transaction en cours est annulée (étape 306 : fermeture de la session de paiement avec réinitialisation de son contexte, en particulier l'indicateur 222) tandis que l'application reste active (retour à l'étape 300) de manière à pouvoir être directement réutilisée pour une transaction ultérieure. Si au contraire une telle communication entre l'appareil mobile 1 et le terminal de paiement est effectuée (étape 304) avant le dépassement de la limite de temps, la transaction en cours est finalisée avec le terminal de paiement (l'application de paiement vient pour cela lire la valeur de l'indicateur 222 ; si ce dernier est renseigné - par exemple à la valeur 1 û la vérification du code personnel a été réalisée avec succès et la session de paiement peut alors se finaliser). L'indicateur de vérification du code personnel 222 est ensuite réinitialisé (sa valeur est par exemple fixée à 0), signifiant que le code personnel n'est plus considéré comme vérifié, et l'application de paiement se réinitialise (retour à l'étape 300) en attente d'une communication ultérieure avec un lecteur extérieur. On comprend ainsi que d'une part la communication avec l'extérieur de l'appareil mobile est sécurisée par la saisie et la vérification du code personnel et par un compteur de temps, garant d'une limite de validité du code personnel et d'autre part, le fait que l'application reste activée même lorsque la limite de temps est dépassée permettant de démarrer toute nouvelle transaction sans nécessité une activation manuelle de l'application. Ainsi un tel procédé permet d'offrir une sécurisation de l'application de paiement dans le cas où cette dernière reste activée en permanence (mode � always on �). Une telle sécurisation est rendue possible notamment par le fait que le démarrage du compteur de temps n'est pas assujetti à l'activation de l'application de paiement. Il peut être également prévu que la valeur de l'indicateur 222 soit fixée à 0 lorsque l'utilisateur annule la transaction en cours (par exemple en désactivant l'application de paiement). Afin de garantir un meilleur niveau de sécurité, il est prévu des moyens de contrôle permettant de vérifier les commandes 54 et 56 (permettant respectivement de faire vérifier le code rentré par l'utilisateur et de signaler le dépassement de la limite de temps au module de gestion 22) soient bien envoyées par l'IHM Banque, seule entité autorisée à envoyer de telles communications. Par ailleurs, une méthode de chiffrement peut être mise en oeuvre afin d'assurer la confidentialité des communications entre une application de paiement et le module de gestion auquel elle est associée. En référence à la figure 4, et selon une autre réalisation possible de la présente invention, une fois l'application de paiement activée, cette dernière reste en attente d'une invitation par l'utilisateur U à démarrer une transaction (étape 400). Dans le cadre de ce mode de réalisation, l'initialisation de la session de paiement fait suite à la sélection, via l'interface 20, par un utilisateur de l'appareil, de l'application de paiement parmi la ou les applications actives. Ainsi, lorsque l'utilisateur U veut réaliser une transaction par exemple pour régler ses achats, il indique à l'IHM Banque 20 (par exemple via le clavier alphanumérique 202) de son appareil mobile 1 son intention d'effectuer une transaction et, après une invitation de ladite interface, rentre son code personnel (PIN). Une fois le code d'identification entré et vérifié de la manière décrite précédemment (étape 401), un compteur de temps 403 est lancé avec en paramètre une limite de temps 404 prédéterminée. Ainsi l'utilisateur U, voulant finaliser la transaction, dispose de cette limite de temps pour établir une communication sans contact entre son appareil mobile 1 et un terminal de paiement en mettant son appareil mobile à proximité du terminal de paiement. L'exécution du compteur de temps est similaire à celui décrit précédemment et est initiée par le module de gestion 22. Si une communication n'est pas effectuée avant le dépassement de la limite de temps (étape 405), la transaction en cours est annulée (étape 406) au sein de l'application de paiement, la valeur de l'indicateur 222 est fixée à 0, et l'application est réinitialisée tout en restant toujours active (retour à l'étape 400). Si au contraire une telle communication est effectuée (étape 407) avant le dépassement de la limite de temps, la transaction en cours est finalisée avec le terminal de paiement 3, la valeur de l'indicateur 222 est fixée à 0, et l'application de paiement se réinitialise (retour à l'étape 400) en attente d'une communication sans contact avec un lecteur extérieur. De la même manière que précédemment, durant cette communication, le module NFC du téléphone 3 rentrant dans la zone de communication du terminal de paiement (POS), une communication est établie entre le terminal de paiement et l'application de paiement, permettant à ce dernier de récupérer les informations nécessaires à la transaction. D'autres modes de réalisation et modifications peuvent être ajoutées à la présente invention sans toutefois sortir de son cadre. Notamment, selon une réalisation possible de la présente invention, il est prévu que le dépassement de la limite de temps implique la fermeture de l'IHM Banque (tant en conservant l'application de paiement active de manière à pouvoir être réutilisée pour une transaction ultérieure). A titre d'exemple illustratif, la limite de temps est fixée à 1 minute.30 L'invention concerne un module de gestion destiné à être associé à un groupe d'une ou plusieurs applications de paiement embarquées dans un appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, chaque application de paiement pouvant être mise en oeuvre dans le cadre d'une session de paiement sans contact entre le lecteur externe et l'appareil, caractérisé en ce qu'il comporte • un espace mémoire stockant un code de référence commun aux applications de paiement du groupe et un indicateur de vérification du code personnel ; • des moyens pour confronter un code personnel saisi via une interface utilisateur au code de référence ; • des moyens configurés pour renseigner l'indicateur en cas de confrontation positive et pour réinitialiser l'indicateur suite à la fermeture ou à la finalisation d'une session de paiement mise en 15 oeuvre avec une application du groupe ; • des moyens formant interface commune permettant de rendre accessible l'indicateur aux applications du groupe. L'invention concerne également une carte à puce destinée à être utilisée dans un 20 appareil à 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 mettre en oeuvre une session de paiement entre. l'appareil et le lecteur externe, caractérisée en ce qu'elle comporte un module de gestion 25 conforme à l'invention associé à chaque groupe. L'invention concerne également un appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, embarquant une carte à puce selon l'invention. REVENDICATIONS1. Procédé pour la gestion d'une application de paiement sans contact active embarquée au sein d'un appareil apte à établir une communication sans contact avec un terminal de paiement sans contact, comprenant les étapes suivantes : ù suite à l'initialisation (300, 400) d'une session de paiement mettant en oeuvre l'application de paiement sans contact, saisie d'un code personnel (302, 401) via une interface (20) ; ù vérification du code personnel saisi par un module de gestion associé à un groupe d'une ou plusieurs applications comprenant l'application mise en oeuvre dans la session de paiement, et en cas de vérification positive, renseignement par le module de gestion d'un indicateur de vérification du code personnel (222) ; ù lecture de l'indicateur par l'application et finalisation de la session de paiement si l'indicateur est renseigné ù réinitialisation de l'indicateur une fois la session finalisée. 2. Procédé selon la revendication précédente, comprenant les étapes suivantes mises en oeuvre en cas de vérification positive du code personnel : ù démarrage d'un compteur de temps (302, 401) ; ù dans le cas où la session de paiement n'est pas finalisée une fois une limite de temps prédéterminée (307, 404) atteinte par le compteur, fermeture de la session de paiement tandis que l'application reste active de manière à pouvoir directement être mise en oeuvre pour une nouvelle session de paiement. 3. Procédé selon l'une des revendications 1 à 2, dans lequel l'initialisation de la session de paiement fait suite à une étape (301) de communication sans contact entre l'appareil et un terminal de paiement (POS). 4. Procédé selon la revendication 3, dans lequel l'initialisation de la session de paiement met en oeuvre une sélection de l'application de paiement par le terminal de paiement parmi la ou les applications de paiement actives. 5. Procédé selon l'une des revendications 1 à 4, dans lequel l'initialisation de la session de paiement fait suite à la sélection, via l'interface (20), par un utilisateur de l'appareil, de l'application de paiement parmi la ou les applications de paiement actives. 6. Procédé selon l'une des revendications précédentes, comprenant en outre les étapes suivantes : une fois le code saisi, envoi par l'interface (20), à destination du module de gestion (22) associé au groupe d'une ou plusieurs applications de paiement sans contact comprenant l'application destinée à être mise en oeuvre dans la session de paiement, d'une commande de vérification (54) du code saisi ; vérification du code saisi par le module de gestion (22) ; en cas de succès de la vérification, envoi par le module de gestion (22) à l'interface (20) d'une commande de démarrage de compteur de temps. 7. Procédé selon la revendication 6, dans lequel le module de gestion réinitialise l'indicateur de vérification du code personnel (222) suite à la fermeture ou à la finalisation de la session de paiement. 8. Module de gestion destiné à être associé à un groupe d'une ou plusieurs applications de paiement embarquées dans un appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, chaque application de paiement pouvant être mise en oeuvre dans le cadre d'une session de paiement sans contact entre le lecteur externe et l'appareil, caractérisé en ce qu'il comporte • un espace mémoire stockant un code de référence commun aux applications de paiement du groupe et un indicateur de vérification du code personnel ; • des moyens pour confronter un code personnel saisi via une interface utilisateur au code de référence ; • des moyens configurés pour renseigner l'indicateur en cas de confrontation positive et pour réinitialiser l'indicateur suite à la fermeture ou à la finalisation d'une session de paiement mise en oeuvre avec une application du groupe ; • des moyens formant interface commune permettant de rendre accessible l'indicateur aux applications du groupe. 9. Carte à puce destinée à être utilisée dans un appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, comprenant au moins un groupe d'une ou plusieurs 20 applications de paiement pouvant être sélectionné pour que l'une des applications du groupe puisse être utilisée pour mettre en oeuvre une session de paiement entre l'appareil et le lecteur externe, caractérisée en ce qu'elle comporte un module de gestion conforme à la revendication précédente associé à chaque groupe. 25 10. Appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, embarquant une carte à puce selon la revendication précédente. 10 15