FR 3053814 A1 20180112 FR 1656622 A 20160711 1 Arrière-plan de l'invention La présente invention se situe dans le domaine général des dispositifs électroniques et concerne plus particulièrement un dispositif électronique, tel qu'une carte à puce ou un terminal mobile par exemple, configuré pour coopérer avec un terminal externe pour réaliser une transaction, dans le domaine bancaire par exemple. L'invention s'applique plus particulièrement, mais de manière non exclusive, aux cartes à puce (ou cartes à microcircuit), conformes par exemple à la norme 1507816. L'invention s'applique également aux terminaux, notamment les terminaux mobiles tels que les téléphones portables par exemple, configurés pour coopérer avec un terminal (ou lecteur) externe pour traiter une transaction. L'invention vise notamment la sécurisation d'un tel dispositif électronique dans le traitement d'une transaction selon protocole EMV (pour « Europay Mastercard Visa »). 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. Ces cartes permettent d'effectuer divers types de transactions, telles que par exemple des transactions de paiement, de prélèvement ou encore d'authentification du porteur. 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 distributeurs automatiques de billets (DAB) pour réaliser divers opérations financières. Des solutions alternatives à la carte à puce ont également été développées comme notamment des solutions logicielles mises en oeuvre sur des terminaux pour permettre à un utilisateur d'effectuer une transaction avec un terminal externe. Une solution mobile consiste par exemple à installer une application sur un terminal mobile (un téléphone portable par exemple) pour traiter une transaction de façon similaire à une carte à puce. EMV est le protocole standardisé utilisé aujourd'hui majoritairement dans le monde pour sécuriser notamment les transactions de paiement effectuées par des cartes à puce ou solutions mobiles. Le protocole EMV 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 à 3053814 2 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. 5 Suivant le type de carte utilisé, la situation, ou encore le montant considéré, une carte EMV peut fonctionner en ligne ou hors ligne. En mode en ligne, la carte EMV peut communiquer, via le lecteur, avec l'entité émettrice correspondante (la banque à l'origine de la carte, par exemple) afin de vérifier en particulier que la transaction en cours est légitime. En revanche, si la carte EMV fonctionne en mode hors ligne, celle-ci applique des 10 critères de vérification préenregistrés pour décider si la transaction doit être autorisée ou refusée. De nombreux mécanismes de sécurité ont récemment été développés afin de sécuriser autant que possible l'usage croissant des cartes à puce, de type EMV notamment. 15 Cependant, certains terminaux de paiement peuvent présenter des faiblesses d'implémentation (nombre imprédictible non aléatoire, signature non supportée...) susceptibles d'être exploitées à mauvais escient par un tiers ou entité malveillant pour réaliser une transaction frauduleuse. Ces terminaux sont cependant fonctionnels et constituent donc un risque sécuritaire élevé pour une carte à puce, ou plus généralement 20 pour un dispositif électronique destiné à traiter une transaction comme indiqué ci-avant. Ces terminaux sensibles au sens sécuritaire, sont généralement connus des banques. Il n'existe toutefois pas aujourd'hui de solution satisfaisante pour sécuriser les transactions réalisées entre un dispositif électronique, tel qu'une carte à puce ou un terminal mobile par exemple, et un terminal sensible comme décrit ci-dessus. 25 Un besoin existe en particulier pour sécuriser le traitement d'une transaction hors ligne entre un dispositif électronique et un terminal à risque, dans la mesure où la banque n'est pas en mesure de faire de contrôles spécifiques pour s'assurer de la validité de la transaction. 30 Objet et résumé de l'invention / Résumé A cet effet, la présente invention concerne un procédé de contrôle d'un dispositif électronique, ledit procédé comprenant, lors d'une transaction en cours de traitement en coopération avec un terminal, les étapes suivantes : 3053814 3 réception, en provenance du terminal, d'un identifiant dudit terminal ; consultation d'une première liste d'au moins un identifiant de terminal pour déterminer si l'identifiant dudit terminal est inclus dans ladite première liste ; et traitement de la transaction en fonction du résultat de ladite consultation. 5 L'invention permet avantageusement à un dispositif électronique de déterminer si le terminal avec lequel il coopère lors d'une transaction présente un risque sécuritaire particulier et, dans l'affirmative, d'adapter le traitement de la transaction en conséquence afin, par exemple, de sécuriser d'avantage la transaction. Selon un mode de réalisation particulier, le procédé comprend, préalablement à ladite 10 étape de consultation, l'enregistrement de la première liste d'au moins un identifiant de terminal dans une mémoire du dispositif électronique. Le dispositif électronique dispose ainsi d'une liste lui permettant d'identifier le ou les terminaux à risque avec lesquels il est susceptible de coopérer lors d'une transaction. Selon un mode de réalisation particulier, ledit procédé comprend, préalablement à 15 ladite étape de consultation : envoi, à un serveur distant, d'une donnée permettant au serveur distant de déterminer la localisation du dispositif électronique ; et réception, en réponse audit envoi, de la première liste d'au moins un identifiant de terminal, ladite première liste étant fonction de ladite localisation du dispositif 20 électronique. L'invention permet ainsi avantageusement au dispositif électronique de recevoir une liste de terminaux présentant un risque sécuritaire particulier, cette liste étant adaptée à la localisation dudit dispositif électronique. De façon avantageuse, il est ainsi possible d'envoyer au dispositif électronique une liste de taille limitée adaptée à la zone 25 géographique dans laquelle se trouve le dispositif électronique, ce qui permet un gain en termes d'espace mémoire et de ressources utilisés au niveau du dispositif électronique. En outre, l'invention permet de s'assurer que le dispositif électronique est capable de déterminer si les terminaux susceptibles d'être situés à proximité présentent un risque particulier ou non. 30 Selon un mode de réalisation particulier, ladite donnée est une donnée de localisation représentative de la localisation du dispositif électronique. Selon un mode de réalisation particulier, le procédé comprend, préalablement à son envoi, la détermination de ladite donnée de localisation à partir d'au moins l'un parmi : 3053814 4 - des coordonnées GPS représentatives de la localisation géographique du dispositif électronique ; et - des données de réseau représentatives de la localisation du dispositif électronique dans un réseau de communication. 5 Selon un mode de réalisation particulier, s'il est déterminé lors de ladite consultation que l'identifiant dudit terminal est inclus dans la liste d'au moins un identifiant de terminal, l'étape de traitement de la transaction comprend le déclenchement d'au moins une opération prédéfinie de sécurisation de la transaction. Selon un mode de réalisation particulier, dans lequel ladite au moins une opération 10 prédéfinie de sécurisation comprend au moins l'un quelconque parmi : envoi d'une requête demandant le traitement en ligne de la transaction en cours ; enregistrement, dans un fichier d'historisation, d'une donnée d'historisation prédéfinie ; et 15 configuration d'au moins un paramètre de fonctionnement du dispositif électronique. Selon un mode de réalisation particulier, la transaction en cours est de type EMV. L'identifiant du terminal est par exemple reçu dans un message de transaction EMV de type GAC. 20 Selon un mode de réalisation particulier, le procédé comprend les étapes suivantes : - réception, lors de la transaction en cours, d'une commande spécifiant une deuxième liste d'au moins un identifiant de terminal ; et en réponse à ladite commande, enregistrement de ladite deuxième liste dans une mémoire du dispositif électronique en remplacement de ladite première liste. 25 L'invention permet ainsi avantageusement de mettre à jour la liste détenue par le dispositif électronique. Dans un mode particulier de réalisation, les différentes étapes du procédé de contrôle sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support 30 d'informations, ce programme étant susceptible d'être mis en oeuvre dans un dispositif électronique tel qu'un terminal mobile, 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 contrôle tel que défini ci-dessus. 3053814 5 L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. L'invention concerne aussi un procédé d'envoi mis en oeuvre par un serveur, 5 comprenant les étapes suivantes : réception d'une donnée en provenance d'un dispositif électronique configuré pour coopérer avec un terminal pour mettre en oeuvre une transaction ; - détermination de la localisation du dispositif électronique à partir de ladite donnée ; 10 - sélection, à partir de la localisation du dispositif électronique, d'une liste d'au moins un identifiant de terminal ; et envoi de ladite liste à destination du dispositif électronique de sorte à configurer le traitement, par le dispositif électronique, d'une transaction. Selon un mode de réalisation particulier, la donnée reçue est l'une parmi : 15 une donnée de localisation représentative de la localisation du dispositif électronique ; et - un identifiant d'un terminal avec lequel le dispositif électronique coopère pour traiter une transaction en cours. Selon un mode de réalisation particulier, le serveur envoie la liste d'au moins un 20 identifiant de terminal au dispositif électronique dans un message de transaction EMV. Dans un mode particulier de réalisation, les différentes étapes du procédé d'envoi sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un serveur, ou 25 plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé d'envoi tel que défini ci-dessus. L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 30 L'invention concerne également un dispositif électronique comprenant, lors d'une transaction en cours avec un terminal, les étapes suivantes : - un module de réception configuré pour recevoir, lors d'une transaction en cours avec un terminal, un identifiant dudit terminal ; 3053814 6 un module de détermination configuré pour consulter une première liste d'au moins un identifiant de terminal pour déterminer si l'identifiant dudit terminal est inclus dans ladite première liste ; et un module de traitement configuré pour traiter la transaction en fonction du 5 résultat de la consultation de la première liste par le module de consultation. Le dispositif électronique est par exemple un terminal mobile tel qu'un téléphone mobile intelligent configuré pour coopérer avec un terminal externe pour réaliser une transaction (de type EMV par exemple). Le dispositif électronique peut également être une carte à puce, de type EMV par exemple. 10 L'invention concerne en outre un serveur comprenant : un module de réception configuré pour recevoir une donnée en provenance d'un dispositif électronique, ledit dispositif étant configuré pour coopérer avec un terminal pour mettre en oeuvre une transaction ; un module de détermination configuré pour déterminer la localisation du 15 dispositif électronique à partir de ladite donnée ; un module de sélection configuré pour sélectionner, à partir de la localisation du dispositif électronique, une liste d'au moins un identifiant de terminal ; et un module d'envoi configuré pour envoyer ladite liste à destination du dispositif électronique de sorte à configurer le traitement, par le dispositif électronique, 20 d'une transaction. A noter que les différents modes de réalisation définis ci-avant en relation avec le procédé de contrôle, d'une part, et avec le procédé d'envoi, d'autre part, ainsi que les avantages associés à ces procédés, s'appliquent par analogie au dispositif électronique et au serveur définis ci-avant. 25 Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description 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: 30 la figure 1 représente schématiquement un terminal mobile apte à coopérer avec un serveur distant SV1 et avec un terminal externe T2, selon un mode de réalisation particulier de l'invention ; 3053814 7 la figure 2 représente schématiquement des modules mis en oeuvre dans le terminal mobile T1 et dans le serveur distant SV1 représentés en figure 1, selon un mode de réalisation particulier de l'invention ; la figure 3 représente schématiquement des procédés de contrôle mis en oeuvre 5 respectivement par le terminal mobile T1 et par le serveur distant SV1 représentés en figures 1 et 2, selon un mode de réalisation particulier de l'invention ; la figure 4a représente schématiquement un exemple d'une table TB contenant des listes LT d'au moins un identifiant de terminal, en association avec une zone 10 géographique ; la figure 4b représente schématiquement un exemple d'une liste LT2 contenue dans la table TB représentée en figure 4a ; la figure 5 représente, sous forme d'un diagramme, les principales étapes de procédés de contrôle mis en oeuvre respectivement par le terminal mobile T1 et 15 par le serveur distant SV1 représentés en figures 1 et 2, selon un mode de réalisation particulier de l'invention ; - la figure 6 représente schématiquement une carte à puce apte à coopérer avec un serveur distant SV3 par l'intermédiaire d'un terminal externe T3, selon à un mode de réalisation particulier de l'invention ; 20 - les figures 7a et 7b représentent schématiquement des modules mis en oeuvre dans la carte à puce CD et dans le serveur distant SV3 représentés en figure 6, selon un mode de réalisation particulier de l'invention ; et - la figure 8 représente, sous forme d'un diagramme, les principales étapes de procédés de contrôle mis en oeuvre respectivement par la carte à puce CD et 25 par le serveur distant SV3 représentés en figure 6, selon un mode de réalisation particulier de l'invention. Description détaillée de plusieurs modes de réalisation Comme précédemment indiqué, la présente invention concerne les dispositifs 30 électroniques, tels que les cartes à puce ou terminaux mobiles par exemple, configurés pour coopérer avec un terminal externe pour réaliser une transaction, dans le domaine bancaire par exemple. 3053814 8 L'invention vise en particulier à sécuriser les transactions réalisées entre un dispositif électronique, tel qu'une carte à puce ou un terminal mobile par exemple, et un terminal externe présentant un risque sécuritaire élevé. Dans le présent exposé, des exemples de mises en oeuvre de l'invention sont décrits 5 de façon non limitative en relation avec une transaction conforme au protocole EMV. On comprendra que l'invention s'applique plus généralement à tout dispositif électronique configuré pour mettre en oeuvre une transaction, y compris selon un standard de transaction autre que le standard EMV. A noter également que la notion de transaction est ici entendue au sens large et 10 comprend par exemple, dans le domaine bancaire, aussi bien une transaction de paiement ou de transfert que d'une consultation d'un compte bancaire sur un terminal bancaire. Les divers modes de réalisation de l'invention sont ici décrits de façon non limitative dans le cadre d'une transaction de paiement dans le domaine bancaire, d'autres types de transaction étant possibles dans le cadre de l'invention. 15 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é. La figure 1 représente, selon un mode de réalisation particulier, un terminal (ou 20 dispositif électronique) T1 configuré pour coopérer avec un serveur distant SV1 et un terminal externe (ou lecteur) T2. Le terminal T2 est configuré pour faire l'interface entre le terminal T1 et un serveur distant SV2. Dans un exemple particulier, les serveurs SV1 et SV2 forment un seul et même serveur. On suppose ici que le terminal T1 est un terminal mobile, par exemple un téléphone 25 portable, configuré pour traiter des transactions EMV en coopération avec le terminal T2, d'autres exemples de terminaux (mobiles ou fixes) étant toutefois possibles dans le cadre de l'invention. Le terminal T1 constitue dans cet exemple un terminal de paiement électronique. On comprendra que certains éléments généralement présents dans un téléphone 30 portable ou dans un serveur ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la présente invention. A noter également que le terminal mobile T1 et le serveur distant SV1 représentés en figure 1 ne constituent que des exemples de réalisation, d'autres mises en oeuvre étant possibles dans le cadre de l'invention. L'homme 3053814 9 du métier comprendra en particulier que certains éléments du terminal mobile Ti et du serveur SV1 ne sont décrits ici que pour faciliter la compréhension de l'invention, ces éléments n'étant pas indispensables pour mettre en oeuvre l'invention. Plus précisément, le terminal mobile Ti comprend dans cet exemple un processeur 2, 5 une mémoire volatile 4 (de type RAM), une mémoire non volatile réinscriptible 6, une première interface de communication 8a et une deuxième interface de communication 8b. La mémoire non volatile réinscriptible 6 constitue ici un support d'enregistrement conforme à un mode de réalisation particulier, lisible par le terminal Ti, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier. 10 Ce programme d'ordinateur PG1 comporte des instructions pour l'exécution des étapes d'un procédé de contrôle selon un mode de réalisation particulier. La mémoire 6 est par ailleurs configurée pour contenir une liste LT d'au moins un identifiant de terminal. Comme expliqué plus en détail par la suite, cette liste permet au terminal mobile Ti d'identifier des terminaux présentant un risque sécuritaire particulier. 15 A partir de cette liste LT, le terminal Ti peut ainsi déterminer si le terminal T2, avec lequel il communique pour traiter une transaction EMV, est un terminal à risque ou non. Les interfaces 8a, 8b permettent au terminal mobile T1 de communiquer respectivement avec le serveur distant SV1 et avec le terminal externe T2, comme expliqué ci-après. 20 Par ailleurs, le serveur SV1 comprend dans cet exemple un processeur 20, une mémoire non volatile réinscriptible 22 et interface de communication 24. La mémoire non volatile réinscriptible 22 constitue ici un support d'enregistrement conforme à un mode de réalisation particulier, lisible par le serveur SV1, et sur lequel est enregistré un programme d'ordinateur PG2 conforme à un mode de réalisation particulier. 25 Ce programme d'ordinateur PG2 comporte des instructions pour l'exécution des étapes d'un procédé de contrôle selon un mode de réalisation particulier. La mémoire 22 est en outre configurée pour contenir une table TB contenant au moins une liste LT en association avec une zone géographique donnée, chaque liste LT contenant au moins un identifiant de terminal, comme expliqué ultérieurement dans un 30 exemple particulier en référence aux figures 4a et 4b. Selon une variante, la table TB est enregistrée dans une mémoire (par exemple une base de données) située hors du serveur SV1 et consultable par ce dernier. 3053814 10 Comme expliqué ci-après en référence à la figure 2, le terminal T1 est configuré pour coopérer avec le terminal externe T2 pour mettre en oeuvre une transaction EMV. Lorsque le traitement de cette transaction EMV se fait en ligne, le terminal T2 est configuré pour coopérer avec le serveur distant SV2 pour permettre à ce dernier de 5 vérifier et valider la transaction EMV en cours. Dans l'exemple considéré ici, les serveurs SV1 et SV2 sont des serveurs contrôlés par l'émetteur (par exemple une banque) d'une application bancaire AP2 installée dans le terminal T1, comme illustré ci-après en figure 2. Comme représenté en figures 1 et 2, le processeur 2 du terminal mobile T1 piloté 10 par le programme d'ordinateur PG1 met ici en oeuvre un certain nombre de modules, à savoir : un premier module de détermination MD2, un module d'envoi MD4, un premier module de réception MD6, un deuxième module de réception MD8, un deuxième module de détermination MD10 et un module de traitement MD12. Dans cet exemple, le module d'envoi MD4 et le module de réception MD6 sont mis en 15 oeuvre par une première application AP1 installée dans le terminal T1 et exécutable par le processeur 2. De même, le module de réception MD8, le module de détermination MD10 et le module de traitement MD12 sont mis en oeuvre par une autre application AP2 installée dans le terminal T1 et exécutable par le processeur 2. Dans cet exemple, les applications AP1 et AP2 sont des applications bancaires. 20 Plus précisément, le module de détermination MD2 est configuré pour déterminer une donnée de localisation DN représentative de la localisation du terminal mobile T1 à un instant donné. Dans l'exemple considéré ici, le module de détermination MD2 est configuré pour obtenir des coordonnées géographiques (par exemple des coordonnées GPS) indiquant la position géographique du terminal mobile Tl, d'autres exemples de 25 mise en oeuvre étant toutefois envisageables. Selon une variante, le module de détermination MD2 est apte à déterminer des données de réseau représentatives de la localisation du terminal mobile T2 dans un réseau de communication, tel qu'un réseau de téléphonie mobile par exemple. Selon cette variante, le module MD2 identifie par exemple au moins deux points d'accès (des 30 antennes relais par exemple) au réseau de communication, ces points d'accès se situant à proximité du terminal mobile T1. A partir des points d'accès ainsi identifiés, le module de détermination MD2 est configuré pour déterminer la donnée de localisation DN, par exemple en utilisant une technique de repérage bien connue de triangularisation. 3053814 11 Le module d'envoi MD4 est configuré pour envoyer la donnée de localisation DN au serveur SV1. Le module de réception MD6 est configuré pour recevoir, en réponse à la donnée DN envoyée par le module d'envoi MD4, une liste LT d'au moins un identifiant de terminal. 5 Le module de réception MD8 est configuré pour recevoir, lors d'une transaction EMV en cours avec le terminal externe T2, un identifiant IDX2 dudit terminal T2. Le deuxième module de détermination MD10 est configuré pour consulter la liste LT reçue par le premier module de réception MD6 pour déterminer si l'identifiant IDX2 reçu par le deuxième module de réception MD8 est inclus dans ladite liste LT. Dans un 10 exemple particulier, le module de réception MD6 est en outre configuré pour enregistrer la liste LT dans une mémoire du terminal mobile T1 (dans la mémoire 6 dans cet exemple). Le module de traitement MD12 est configuré pour traiter la transaction EMV en cours en fonction du résultat de la consultation de la liste LT par le deuxième module de 15 détermination MD10. Dans un exemple particulier, si le module de détermination MD10 détermine que l'identifiant IDX2 du terminal T2 est inclus dans la liste LT, le module de traitement MD12 est configuré pour déclencher au moins une opération prédéfinie de sécurisation de la transaction EMV en cours. Le module de traitement MD12 est par exemple configuré pour déclencher, en tant qu'opération de sécurisation, l'envoi d'un 20 message RGAC requérant la poursuite de la transaction en mode en ligne, de façon à ce que le serveur distant SV2 de la banque puisse procéder aux vérifications nécessaires. Par ailleurs, comme représenté en figures 1 et 2, le processeur 20 du serveur SV1 piloté par le programme d'ordinateur PG2 met ici en oeuvre un certain nombre de modules, à savoir : un module de réception MD20, un module de détermination MD22, un 25 module de sélection MD24 et un module d'envoi MD26. Plus précisément, le module de réception MD20 est configuré pour recevoir la donnée de localisation DN émis par le module d'envoi MD4 du terminal mobile T1. Le module de détermination MD22 est configuré pour déterminer la localisation, notée LOC, du terminal mobile T1 à partir de la donnée de localisation DN reçue. La 30 donnée de localisation DN peut se présenter sous tout format approprié pouvant être interprété par le module de détermination MD22 du serveur SV1. Le module de sélection MD24 est configuré pour sélectionner, en fonction de la localisation LOC du terminal mobile T1, une liste LT correspondante, c'est-à-dire une liste 3053814 12 LT d'au moins un identifiant de terminal, cette liste étant ainsi adaptée à la position géographique du terminal mobile Ti. Comme expliqué par la suite, l'invention permet avantageusement au terminal T1 de déterminer si le ou les terminaux externes T2 avec lequel il est susceptible de coopérer présentent un risque sécuritaire particulier et, dans 5 l'affirmative, d'adapter le traitement d'une transaction en conséquence. Le module d'envoi MD26 du serveur SV1 est configuré pour envoyer la liste LT, sélectionnée par le module de sélection MD24, à destination du terminal mobile T1. De cette manière, il est possible de configurer la manière dont le terminal mobile T1 traite une ou des transactions EMV ultérieures. 10 Le fonctionnement des modules MD2-MD12 du terminal mobile Tl et des modules MD20-MD26 du serveur distant SV1 apparaîtra plus précisément dans les exemples de réalisation décrits ci-après en référence aux figures 3, 4a, 4b et 5. On comprendra que les modules MD2-MD26 tels que représentés en figure 2 ne représentent qu'un exemple de mise en oeuvre non limitatif de l'invention. 15 Des modes de réalisation particuliers sont à présent décrit sen référence aux figures 3-5. Plus précisément, le terminal mobile T1 et le serveur distant SV1 représentés en figures 1 et 2 mettent chacun en oeuvre un procédé de contrôle en exécutant respectivement les programmes d'ordinateur PG1 et PG2. Comme représentées en figures 1 et 4a, trois listes LT (notées LT1, LT2 et LT3) 20 sont ici enregistrées dans la mémoire 22 du serveur SV1 en association avec une zone géographique RG respective (notées RG1, RG2 er RG3). Cet enregistrement se présente ici sous la forme d'une table TB bien que d'autres représentations ou arrangements soient possibles. Chaque zone géographique peut correspondre à un territoire, à une région ou encore 25 à un site approprié. Dans un exemple particulier, une zone géographique correspond à un pays, à une ville ou encore à une zone de périmètre quelconque. La banque émettrice peut par exemple définir la taille et les emplacements des zones géographiques en fonction de critères de son choix (adresse postale du domicile du porteur du terminal mobile Tl etc.). 30 Plus précisément, dans l'exemple considéré ici, la table TB contient les listes LT1, LT2 et LT3 en association avec des identifiants respectifs IDR1, IDR2, IDR3 (notés collectivement IDR) correspondant aux zones géographiques RG1, RG2, RG3. Chaque 3053814 13 identifiant de zone IDR1-IDR3 identifie une zone géographique RG correspondante, en association avec une liste LT. La figure 4b représente schématiquement la liste LT2 contenant par exemple ici les identifiants IDT notés IDT1 à IDT4, chaque identifiant IDT correspondant à un terminal 5 externe (ou lecteur) respectif susceptible de coopérer avec le terminal mobile Tl pour traiter une transaction EMV. Comme représenté en figure 3, le terminal mobile Ti détermine, au cours d'une étape A2, une donnée de localisation DN représentative de la localisation LOC du terminal mobile Ti. Dans l'exemple décrit ici, cette donnée DN est déterminée à partir de 10 coordonnées GPS obtenues par le module de détermination MD2, ces coordonnées GPS étant représentatives de la position géographique du terminal mobile 2. Comme déjà expliqué, d'autres techniques sont possibles pour déterminer la donnée de localisation DN. Le format de la donnée de localisation DN peut varier selon le cas. Dans un exemple particulier, la donnée de localisation DN comprend des coordonnées physiques (par 15 exemple les coordonnées GPS) du terminal mobile Tl. En A4, le terminal mobile Ti envoie la donnée de localisation DN au serveur SV1 qui la reçoit en B6. Le serveur SV1 détermine (B8) ensuite, à partir de la donnée de localisation DN reçue, la localisation LOC du terminal mobile T1. 20 En B10, le serveur SV1 consulte sa table TB et sélectionne, à partir de la localisation LOC (ou directement à partir des données de localisation DN), la liste LT correspondante. Pour ce faire, le serveur SV1 détermine par exemple dans quelle région RG spécifiée dans la table TB se trouve le terminal mobile T1 et en déduit la liste LT associée. On suppose dans cet exemple que le serveur SV1 détermine, à partir de la localisation LOC du 25 terminal mobile T1, que ledit terminal T1 se trouve dans la zone géographique RG2 et, par conséquent, sélectionne (B10) la liste LT2 associée, illustrée en figure 4b. En B12, le serveur SV1 envoie alors au terminal mobile Ti la liste LT2 sélectionnée en B10. Le terminal mobile Tl reçoit cette liste LT2 en Al2. Dans un exemple particulier, le serveur SV1 envoie en B12 la liste LT2 sous forme chiffrée (ou cryptée). Le terminal 30 mobile Ti est alors capable de déchiffrer la liste LT2 à partir d'une clé cryptographique dont il dispose. En A14, le terminal mobile Ti enregistre la liste LT2 dans sa mémoire 6. 3053814 14 A l'issue des procédés de contrôle représentés en figure 3, le terminal mobile T1 dispose ainsi dans sa mémoire d'une liste d'au moins un terminal (ou lecteur) présentant un risque sécuritaire particulier, cette liste étant adaptée à la localisation du terminal mobile T1. De façon avantageuse, il est ainsi possible d'envoyer au terminal mobile Ti 5 une liste de taille limitée adaptée à la zone géographique dans laquelle se trouve ledit terminal T1, ce qui permet un gain en termes d'espace mémoire et de ressources utilisés au niveau du terminal mobile T1. En outre, l'invention permet de s'assurer que le terminal mobile T1 est capable de déterminer si les terminaux externes T2 situés à proximité présentent un risque particulier ou non. 10 L'invention permet également de mettre à jour si nécessaire une liste LT déjà contenue en mémoire dans le terminal mobile T1. Différents modes de réalisation sont envisageables pour mettre à jour cette liste LT. Selon un exemple particulier, préalablement à l'étape A2 représentée en figure 3, le terminal mobile T1 contient déjà en mémoire une liste LT, par exemple la liste LT1. En 15 A14, le terminal mobile T1 est alors configuré pour effacer la liste LT1 existante et pour enregistrer, en tant que nouvelle liste, la liste LT2 reçue en Al2. De cette façon, il est possible de limiter l'espace mémoire nécessaire dans le terminal mobile T1 pour stocker les identifiants IDT de terminaux à risque. Le terminal mobile T1 dispose ainsi des identifiants des terminaux externes qu'il est susceptible de rencontrer dans son voisinage. 20 Selon un mode de réalisation particulier, le serveur SV1 envoie également, en B12 (figure 3), au terminal mobile T1, des données DRG2 représentatives de la zone géographique RG2 associée à la liste LT2 sélectionnée (B12) par le serveur SV1. Ces données DRG2 définissent les limites de la zone géographique DRG2. En A14, le terminal mobile T1 enregistre les données DRG2 en association avec la liste LT2. Le terminal 25 mobile T1 compare ensuite périodiquement, et/ou sur réception d'une commande, la position courante du terminal mobile T1 avec les limites de la zone géographique RG2 définies par les données DRG2. Le terminal mobile T1 envoie au serveur SV1 une demande de mise à jour de sa liste LT2 contenue dans sa mémoire s'il détecte que sa position courante est hors de la zone géographiques associée RG2. Cette demande de 30 mise à jour comprend par exemple une donnée de localisation DN représentative de la nouvelle positon du terminal mobile T1. La mise à jour de la liste LT2 peut s'effectuer de la même manière que les procédés de contrôle illustrés en figure 3 pour récupérer et stocker la liste LT2 dans la mémoire du terminal mobile T1. Ce mode de réalisation 3053814 15 permet avantageusement de limiter les ressources du réseau et du serveur SV1 nécessaires pour la mise à jour de la liste LT dans la mesure où les zones géographiques sont préétablies et le terminal mobile T1 envoie une requête de mise à jour seulement s'il détecte qu'il est positionné hors de la zone géographique associée à sa liste LT. 5 Selon une autre variante du procédé de contrôle représenté en figure 3, le terminal mobile T1 définit, en tant que position de référence PRef, la position dudit terminal mobile T1 correspondant à la donnée de localisation DN envoyée en A4. Après la réception Al2 de la liste LT1, le terminal mobile T1 est alors configuré pour évaluer périodiquement, et/ou en réponse à une commande reçue, la distance entre la position courante du 10 terminal mobile T1 et la position de référence PRef. Le terminal mobile T1 envoie au serveur SV1 une demande de mise à jour de sa liste LT s'il détecte que sa position courante se situe à une distance D supérieure ou égale à une distance limite prédéfinie Dlim vis-à-vis de la position de référence PRef. La mise à jour de la liste LT2 peut s'effectuer de la même manière que les procédés de contrôle illustrés en figure 3 pour 15 récupérer et stocker la liste LT2 dans la mémoire du terminal mobile T1. Ce mode de réalisation permet de limiter les ressources nécessaires au niveau du terminal mobile T1 dans la mesure où il n'est pas nécessaire que le terminal mobile T1 détermine les limites de la zone géographique associée à sa liste LT actuelle, ou qu'il compare ces limites avec sa position courante pour déterminer si une mise à jour de sa liste LT est nécessaire. 20 Selon un exemple de réalisation particulier, on suppose qu'après l'étape A14 d'enregistrement de la liste LT2 comme illustrée en figure 3, le terminal mobile T1 débute le traitement d'une transaction EMV notée TR1, comme illustré en figure 5. Pour ce faire, le terminal mobile T1 coopère avec le terminal externe T2 de façon connue selon le protocole EMV. Le terminal mobile T1 et le terminal externe T2 s'échangent divers 25 messages normalisés de transaction EMV tels que, par exemple, les messages RST (« Reset »), ATR (« Answer to Reset »), SELECT FILE ou encore SELECT APPLICATION bien connus de l'homme du métier. Comme illustré en figure 5, le terminal T2 envoie (C20) au terminal mobile T1 un identifiant IDX2 du terminal T2. Dans l'exemple considéré ici, l'identifiant IDX2 est envoyé 30 en C20 dans un message de transaction MSG1 de type « GENERATE AC » (GAC) bien connu de l'homme du métier. La commande GAC contient des informations telles que, par exemple, le montant de la transaction en cours, la devise utilisée et/ou le type de transaction, etc. 3053814 16 Le terminal mobile T1 reçoit l'identifiant IDX2 du terminal externe T2 en A20 puis consulte en A22 la liste LT2, précédemment reçue en Al2 (figure 3), pour déterminer si l'identifiant IDX2 est inclus dans ladite liste LT2. Le terminal mobile T1 traite (A24) ensuite la transaction TR1 en fonction du résultat 5 de la consultation A22. Dans l'exemple considéré ici, s'il est détecté en A22 que l'identifiant IDX2 est contenu dans la liste LT2 présente dans la mémoire 6, le terminal mobile T1 en déduit que le terminal externe T2 présente un risque sécuritaire élevé et adapte son traitement A24 de la transaction TR1 en conséquence afin de sécuriser la transaction TR1. 10 Selon un exemple particulier, s'il est déterminé lors de ladite consultation A22 que l'identifiant IDX2 du terminal T2 est inclus dans la liste LT2, le traitement A24 de la transaction par le terminal mobile T1 comprend le déclenchement d'au moins une opération prédéfinie de sécurisation de la transaction TR1. Le terminal mobile T1 réalise par exemple au moins l'une des opérations de sécurisation A26, A28 et A30 telles que 15 décrites ci-après. En A26, le terminal mobile T1 envoie une requête MSG2 au terminal T2 demandant le traitement en mode en ligne de la transaction TR1 en cours. Dans cet exemple particulier, la requête MSG2 est une requête de type ARQC (pour « Autorisation Request Cryptogram ») selon le protocole EMV, bien connue de l'homme du métier. Le terminal T2 20 reçoit la requête MSG2 en C26, puis transmet celle-ci au serveur distant SV2 en C28. Une fois la requête MSG2 reçue (B28), le serveur distant SV2 peut alors authentifier la transaction TR1 et effectuer les contrôles de sécurité appropriés. En A28, le terminal mobile T1 enregistre, dans un fichier d'historisation (non représenté), une donnée d'historisation prédéfinie notée ici DNH. Cette donnée DNH est 25 par exemple stockée dans une mémoire du terminal mobile T1. Dans un exemple particulier, cette donnée d'historisation DNH indique qu'une transaction TR1 a été traitée en coopération avec le terminal externe T2 présentant un risque sécuritaire élevé. Il est ainsi possible de garder un historique, dans le terminal mobile T1, des transactions à risque traiter avec un terminal externe sensible. Cette donnée d'historisation DNH pourra 30 si besoin être consultée ultérieurement par la banque. En A30, le terminal mobile T1 configure au moins un paramètre de fonctionnement PR du terminal mobile T1. Chaque paramètre de fonctionnement définit la manière dont le 3053814 17 terminal mobile T1 traite une transaction EMV. Ainsi, le terminal mobile T1 modifie par un compteur ou le seuil limite de ce dernier. La présente invention permet avantageusement à un dispositif électronique (ici le terminal mobile T1) de déterminer si un terminal externe, avec lequel il coopère pour 5 traiter une transaction en cours, présente un risque sécuritaire particulier. De manière avantageuse, le dispositif électronique peut vérifier si ce terminal externe est un terminal à risque lors d'une transaction hors ligne, c'est-à-dire sans l'intervention du serveur distant SV2 de l'émetteur. En fonction de si le terminal externe en question est identifié comme étant à risque ou non, le dispositif électronique est alors en mesure d'adapter son 10 traitement de la transaction en cours. Si besoin, le dispositif électronique peut requérir la poursuite de la transaction en ligne avec l'aide du serveur distant SV2. Dans un exemple particulier, la liste LT d'au moins un identifiant de terminal dont dispose le dispositif électronique est adaptée à la position dudit dispositif électronique (comme décrit ci-avant en référence à la figure 3). Cela permet avantageusement de 15 s'assurer que le dispositif électronique est capable de déterminer si les terminaux externes T2 avec lesquels il est susceptible de coopérer présentent un risque sécuritaire particulier ou non. En outre, l'identité de terminaux de paiement, par exemple, présentant une faiblesse de sécurité peut constituer une information sensible que les banques souhaitent protéger. 20 L'invention permet avantageusement de limiter le nombre des terminaux sensibles qui sont identifiés dans de la liste transmise au dispositif électronique de l'invention, de sorte à réduire au maximum les risques en cas d'interception par un tiers ou une entité malveillante. A noter que, dans ce mode de réalisation, le terminal mobile T1 reçoit la liste LT 25 appropriée hors du cadre d'une transaction, de type EMV par exemple, avec un terminal externe. Il est ainsi possible de mettre à jour la liste LT d'identifiants de terminal du terminal mobile sans allonger la durée de traitement d'une transaction EMV ou autre. Comme déjà indiqué, la mise en oeuvre de l'invention n'est pas limitée à un terminal mobile et peut s'appliquer à divers dispositifs électroniques configurés pour traiter une 30 transaction, de type EMV par exemple, avec un terminal externe (ou lecteur). La figure 6 représente, selon un autre mode de réalisation, une carte à puce EMV notée CD, cette carte CD étant configurée pour coopérer avec un terminal externe T3 pour traiter une transaction EMV. Le terminal T3 est configuré pour faire l'interface entre 3053814 18 la carte à puce CD et un serveur distant SV3, en particulier lorsqu'une transaction EMV est traitée en ligne. Dans l'exemple considéré ici, le serveur SV3 est contrôlé par l'émetteur (la banque par exemple) de la carte à puce CD. On comprendra ici aussi que certains éléments généralement présents dans une carte 5 à puce ou dans un serveur bancaire ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la présente invention. A noter également que la carte à puce CD et le serveur distant SV3 représentés en figure 6 ne constituent que des exemples de réalisation, d'autres mises en oeuvre étant possibles dans le cadre de l'invention. L'homme du métier comprendra en particulier que certains éléments de la 10 carte CD et du serveur SV3 ne sont décrits ici que pour faciliter la compréhension de l'invention, ces éléments n'étant pas indispensables pour mettre en oeuvre l'invention. Plus précisément, la carte à puce CD comprend dans cet exemple un processeur 30, des contacts externes 32 configurés pour coopérer avec le lecteur T3 et une mémoire non volatile réinscriptible 34. 15 La mémoire 34 constitue dans un cet exemple un support d'enregistrement conforme à un mode de réalisation particulier, lisible par la carte à puce CD, et sur lequel est enregistré un programme d'ordinateur PG3 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG3 comporte des instructions pour l'exécution des étapes d'un procédé de contrôle selon un mode de réalisation particulier, comme décrit ci-après. 20 Dans un exemple particulier, la carte à puce CD est conforme à la norme ISO 7816. Dans ce cas, les contacts externes 32 présentent des caractéristiques conformes à cette norme. On comprendra toutefois que d'autres modes de réalisation sont possibles. La carte à puce CD peut par exemple coopérer avec le lecteur T3 en mode sans contact via une antenne RF intégrée dans la carte CD. 25 Toujours dans l'exemple considéré ici, la mémoire 34 est configurée pour contenir une liste LT d'au moins un identifiant de terminal, de la même manière que la mémoire 6 représentée en figure 1. Toujours en référence à la figure 6, le serveur SV3 présente dans cet exemple une structure similaire à celle du serveur SV1 illustrée en figure 1. Plus particulièrement, le 30 serveur SV2 comprend dans cet exemple un processeur 40, une mémoire non volatile réinscriptible 42 et interface de communication 44. La mémoire 42 constitue ici un support d'enregistrement conforme à un mode de réalisation particulier, lisible par le serveur SV3, et sur lequel est enregistré un programme 3053814 19 d'ordinateur PG4 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG4 comporte des instructions pour l'exécution des étapes d'un procédé de contrôle selon un mode de réalisation particulier. La mémoire 42 est en outre configurée pour contenir une table TB identique à celle 5 décrite ci-avant en référence aux figures 4a, 4b. Dans l'exemple considéré ici, la table TB contient ainsi les listes LT1 à LT3 en association avec les zones géographiques respectives RG1 à RG3 (ou plus particulièrement, en association avec les identifiants de zones IDR1 à IDR3). Selon une variante, la table TB est enregistrée dans une mémoire (par exemple une base de données) hors du serveur SV3 et consultable par ce dernier. 10 L'interface 44 permet au serveur SV3 de communiquer avec le terminal externe T3. Par ailleurs, le processeur 30 de la carte CD, piloté par le programme d'ordinateur PG3, met ici en oeuvre un certain nombre de modules représentés en figure 7a, à savoir : un premier module de réception MD40, un module de détermination MD42, un module de traitement MD44, un module d'envoi MD46 et un deuxième module de 15 réception MD48. Le premier module de réception MD40 est configuré pour recevoir un identifiant IDX3 du terminal externe T3, par exemple dans un message de transaction EMV. Dans un exemple particulier, le module de réception MD40 est en outre configuré pour enregistrer l'identifiant IDX3 reçue dans la mémoire 34 de la carte à puce CD. 20 Le module de détermination MD42 est configuré pour consulter la liste LT, présente dans la mémoire 34, pour déterminer si l'identifiant IDX3 reçu par le premier module de réception MD40 est inclus dans ladite liste LT. Le module de traitement MD44 est configuré pour traiter une transaction EMV en cours en fonction du résultat de la consultation de la liste LT par le module de 25 détermination MD42. Dans un exemple particulier, si le module de détermination MD42 détermine que l'identifiant IDX3 du terminal T3 est inclus dans la liste LT, le module de traitement MD12 est configuré pour déclencher au moins une opération prédéfinie de sécurisation de la transaction EMV en cours. Le module de traitement MD44 est par exemple configuré pour déclencher une opération de sécurisation prédéfinie de façon 30 identique au module de traitement MD12 illustré en figure 1. Le module d'envoi MD46 est configuré pour envoyer, par exemple dans un message de transaction EMV, l'identifiant IDX3 du terminal T3 au serveur SV3. 3053814 20 Le module de réception MD48 est configuré pour recevoir, en réponse à l'identifiant IDX3 envoyé par le module d'envoi MD46, une nouvelle liste LT d'au moins un identifiant de terminal. Cette nouvelle liste LT est par exemple reçue dans une commande, dite commande de script, provenant du serveur SV3. 5 Par ailleurs, le processeur 40 du serveur SV3, piloté par le programme d'ordinateur PG4, met ici en oeuvre un certain nombre de modules représentés en figure 7b, à savoir : un module de réception MD60, un module de détermination MD62, un module de sélection MD64 et un module d'envoi MD66. Les modules MD60 à MD66 du serveur SV3 fonctionnent respectivement de façon analogue aux modules MD20 à MD26 du serveur 10 SV1, tel que représentés en figure 2. Plus précisément, le module de réception MD60 est configuré pour recevoir l'identifiant IDX3, du terminal T3, en provenance de la carte à puce CD. Le module de détermination MD62 est configuré pour déterminer la localisation, notée LOC, de la carte à puce CD à partir de l'identifiant IDX3 reçue. Sachant quel 15 terminal T3 coopère avec la carte CD, le serveur SV3 est en effet capable d'en déduire la position de la carte CD. Le module de sélection MD64 est configuré pour sélectionner, à partir de la localisation LOC de la carte à puce CD, une liste LT correspondante, c'est-à-dire une liste LT d'au moins un identifiant IDT de terminal, cette liste étant adaptée à la position 20 géographique de la carte à puce CD. Comme indiqué par la suite, cette liste permet ensuite à la carte à puce CD d'identifier le ou les terminaux externes T3 se trouvant dans son voisinage, et présentant un risque sécuritaire particulier. Le module d'envoi MD66 du serveur SV3 est configuré pour envoyer la liste LT, sélectionnée par le module de sélection MD64, à destination de la carte à puce CD. Il est 25 ainsi possible de configurer la manière dont la carte à puce CD traite une ou des transactions EMV ultérieures. Le fonctionnement des modules MD40-MD48 de la carte à puce CD et des modules MD60-MD66 du serveur distant SV3 apparaîtra plus précisément dans les exemples de réalisation décrits ci-après en référence à la figure 8. 30 On comprendra que les modules MD40-MD48 de la carte à puce CD et les modules MD60-MD66 du serveur distant SV3, tels que représentés dans les figures 7a et 7b, ne constituent qu'un exemple de mise en oeuvre non limitatif de l'invention. 3053814 21 Un mode de réalisation particulier est à présent décrit en référence à la figure 8. Plus précisément, la carte à puce CD et le serveur distant SV3 représentés en figure 6 mettent chacun en oeuvre un procédé de contrôle en exécutant respectivement les programmes d'ordinateur PG3 et PG4. 5 Dans un état initial, on suppose que la liste LT2 telle que représentée en figure 4b est enregistrée dans la mémoire 34 de la carte à puce CD. Cette liste LT2 est par exemple enregistrée lors d'une phase de personnalisation de la carte à puce CD ou lors d'une mise à jour ultérieure de la carte à puce CD. Comme déjà indiqué, la table TB du serveur SV3 contient les listes LT1, LT2 et LT3 10 (notées collectivement LT) en association avec respectivement les zones géographiques RG1, RG2 er RG3 (notées collectivement RG). Comme illustré en figure 8, on suppose que la carte à puce CD a initié le traitement d'une transaction EMV notée TR2 avec le terminal externe T3. Pour ce faire, la carte à puce CD coopère avec le terminal externe T3 de façon connue selon le protocole EMV, La 15 carte à puce CD et le terminal externe T3 s'échangent en particulier des messages normalisés de transaction EMV bien connus de l'homme du métier, tels que RST, ATR SELECT FILE etc. comme déjà expliqué en référence à la transaction TR1 en figure 5. Au cours d'une étape d'envoi C40, le terminal externe T3 envoie l'identifiant IDX3 dudit terminal T3 à la carte à puce CD. Le message MSG4, dans lequel est envoyé 20 l'identifiant IDX3 en C40, est dans cet exemple un message GAC conforme au standard EMV. La carte à puce CD reçoit l'identifiant IDX3 du terminal externe T3 en A40 puis consulte en A42 la liste LT2, de façon analogue à la consultation A22 représentée en figure 5, pour déterminer si l'identifiant IDX3 est inclus dans ladite liste LT2. 25 La carte à puce CD traite (A43) ensuite la transaction TR2 en cours en fonction du résultat de la consultation A42. Dans l'exemple considéré ici, s'il est détecté en A42 que l'identifiant IDX3 est contenu dans la liste LT2 présente dans la mémoire 34, la carte à puce CD en déduit que le terminal externe T3 présente un risque sécuritaire élevé et adapte son traitement de la transaction TR2 en conséquence afin de sécuriser la 30 transaction TR2, de façon analogue à l'étape A24 représentée en figure 5. Selon un exemple particulier, s'il est déterminé lors de ladite consultation A42 que l'identifiant IDX3 du terminal T3 est inclus dans la liste LT2, le traitement (A43) de la transaction par la carte à puce CD comprend le déclenchement d'au moins une opération prédéfinie de 3053814 22 sécurisation de la transaction TR2, comme par exemple au moins l'une des opérations A26, A28 et A30 représentées en figure 5. L'invention permet ici à la carte à puce CD de déterminer, sans l'aide du serveur distant SV3 de l'émetteur (hors ligne), si le terminal externe T3 est sensible en termes de 5 sécurité et ainsi d'adapter le traitement de la transaction EMV comme déjà expliqué ci- avant. Dans un exemple particulier, on suppose à présent que la carte à puce CD a déterminé, lors de la consultation A42, que l'identifiant IDX3 du terminal T3 n'est pas présent dans la liste LT2. Au cours d'une étape A44 d'envoi, la carte à puce CD envoie 10 l'identifiant IDX3 à destination du serveur distant SV3. Le message MSG5, dans lequel se trouve l'identifiant IDX3 du terminal T3, est dans cet exemple un message de transaction EMV de type ARPC (pour « authorization response cryptogram ») indiquant la décision de la banque. On notera que la carte à puce CD ne dispose pas ici de moyens lui permettant de 15 déterminer sa localisation. Aussi, elle n'est pas en mesure de fournir une donnée de localisation DN comme cela été décrit ci-avant dans les étapes A2-A4 représentées en figure 3. Comme indiqué par la suite, c'est ici l'identifiant IDX3 du terminal T3 fourni par la carte à puce CD qui permet au serveur SV3 de déterminer une liste LT adaptée à la position de la carte à puce CD. 20 Le terminal T3, faisant ici l'interface entre la carte à puce CD et le serveur SV3, reçoit l'identifiant IDX3 en C44 et transmet celui-ci au serveur SV3 en C46. Le serveur SV1 évalue (B48) ensuite, à partir de l'identifiant IDX3 du terminal T3 reçu, la localisation LOC de la carte à puce CD. Pour ce faire, le serveur SV3 utilise par exemple une table (non représentée) indiquant la zone géographique RG associé au 25 terminal externe T3. Dans le présent exemple, on suppose que la banque émettrice de la carte à puce CD est capable de déterminer, à partir de l'identifiant IDX3, la position géographique du terminal T3, et donc de la carte à puce CD se trouvant à proximité. En B50, le serveur SV3 consulte ensuite sa table TB illustrée en figure 4a et sélectionne, à partir de la localisation LOC de la carte à puce CD, la liste LT 30 correspondante. Pour ce faire, le serveur SV3 détermine par exemple dans quelle zone géographique RG spécifiée dans la table TB se trouve le terminal T3 (et donc la carte à puce CD) et en déduit la liste LT associée. On suppose dans cet exemple que le serveur SV3 détermine, à partir de la localisation LOC de la carte à puce CD, que la carte à puce 3053814 23 CD se trouve à présent dans la zone géographique RG3 et, par conséquent, sélectionne (B50) la liste LT3 associée. En B52, le serveur SV3 envoie alors à la carte à puce CD la liste LT3 sélectionnée en B50. Dans cet exemple, le message MSG6 dans lequel est envoyée la liste LT3 en B52, est 5 une commande de script conforme au standard EMV, cette commande requérant la mise à jour de la carte à puce CD à partir de la liste LT3. La carte à puce CD reçoit en A54 la commande MSG6 contenant la nouvelle liste LT3 d'au moins un identifiant de terminal. En A56, la carte à puce CD enregistre la nouvelle liste LT3 dans sa mémoire 34. Dans 10 cet exemple, la carte à puce CD supprime (A56) en outre l'ancienne liste LT2 qui était jusqu'ici stockée dans la mémoire 34. A l'issue des procédés de contrôle représentés en figure 8, la carte à puce CD dispose ainsi dans sa mémoire d'une liste d'au moins un terminal (ou lecteur) présentant un risque sécuritaire particulier, cette liste étant adaptée à la localisation de ladite carte 15 CD. De façon avantageuse, il est ainsi possible d'envoyer à la carte à puce CD une liste de taille limitée adaptée à la zone géographique dans laquelle se trouve la carte à puce CD, ce qui permet un gain en termes d'espace mémoire et de ressources utilisés au niveau de la carte à puce CD. En outre, l'invention permet de s'assurer que la carte à puce CD est capable de déterminer si les terminaux externes T2 situés à proximité présentent un 20 risque particulier ou non. Dans les modes de réalisation et variantes décrits dans cet exposé, la liste LT fourni au dispositif électronique par le serveur distant est une liste « noire » dans le sens où elle identifie le ou les terminaux externes présentant un risque sécuritaire particulier. En variante, on peut envisager d'autres mises en oeuvre dans lesquelles la liste LT est une 25 liste « blanche » dans le sens où elle identifie le ou les terminaux externes ne présentant pas de risque sécuritaire particulier. Selon d'autres variantes, la liste LT identifie à la fois des terminaux en tant que terminaux à risque, et d'autres terminaux en tant que terminaux de confiance. Selon un mode de réalisation particulier, outre la première liste LT variant en fonction 30 de la position du dispositif électronique, ce dernier peut contenir en mémoire une deuxième liste LT d'au moins un identifiant de terminal qui ne varie pas en fonction de la position du dispositif électronique. Cette deuxième liste LT est par exemple associée à une zone géographique où le porteur du dispositif électronique est susceptible de se trouver 3053814 24 fréquemment (à proximité de son domicile, d'un lieu privilégié de son choix etc.). Le dispositif électronique est alors configuré pour consulter les première et deuxième listes LT lors des étapes A22 et A42 précédemment décrites. A noter par ailleurs que, dans les modes de réalisation et variantes décrites ci-avant, 5 chaque identifiant IDT de terminal correspond à un unique terminal externe susceptible d'interagir avec le dispositif électronique de l'invention. En variante, un identifiant IDT contenu dans une liste LT peut correspondre à un groupe d'au moins deux terminaux (IDT identifie par exemple un type ou modèle de terminal). Un identifiant IDT peut par exemple correspondre au nom du marchant impliqué dans une transaction de paiement. 10 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 de mise en oeuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier. 15 REVENDICATIONS1. Procédé de contrôle d'un dispositif électronique (T1 ; CD), ledit procédé comprenant, lors d'une transaction (TR1 ; TR2) en cours de traitement en coopération avec un terminal (T2 ; T3), les étapes suivantes : réception (A20 ; A40), en provenance du terminal, d'un identifiant (IDX2 ; IDX3) dudit terminal ; consultation (A22 ; A42) d'une première liste (LT) d'au moins un identifiant (ID) de terminal pour déterminer si l'identifiant dudit terminal (T2 ; T3) est inclus dans ladite première liste ; et traitement (A24 ; A43) de la transaction en fonction du résultat de ladite consultation. 2. Procédé de contrôle selon la revendication 1, comprenant, préalablement à ladite étape (A22 ; A42) de consultation, l'enregistrement de la première liste d'au moins un identifiant de terminal dans une mémoire du dispositif électronique. 3. Procédé de contrôle selon la revendication 1 ou 2, ledit procédé comprenant, préalablement à ladite étape (A22 ; A42) de consultation : envoi (A4 ; A44), à un serveur distant (SV1 ; SV3), d'une donnée (DN ; IDX3) permettant au serveur distant de déterminer la localisation (LOC) du dispositif électronique ; et réception (Al2 ; A54), en réponse audit envoi, de la première liste (LT2 ; LT3) d'au moins un identifiant (IDT) de terminal, ladite première liste étant fonction de ladite localisation du dispositif électronique. 4. Procédé de contrôle selon la revendication 3, dans lequel ladite donnée est une donnée de localisation (DN) représentative de la localisation du dispositif électronique. 30 5. Procédé de contrôle selon la revendication 4, ledit procédé comprenant, préalablement à son envoi (A4), la détermination de ladite donnée de localisation (DN) à partir d'au moins l'un parmi : - des coordonnées GPS représentatives de la localisation géographique du 35 dispositif électronique ; et 3053814 26 - des données de réseau représentatives de la localisation du dispositif électronique dans un réseau de communication. 6. Procédé de contrôle selon l'une quelconque des revendications 1 à 5, dans 5 lequel, s'il est déterminé lors de ladite consultation (A22 ; A42) que l'identifiant dudit terminal est inclus dans la liste (LT2 ; LT3) d'au moins un identifiant de terminal, l'étape de traitement (A24 ; A43) de la transaction comprend le déclenchement d'au moins une opération prédéfinie de sécurisation de la transaction. 10 7. Procédé de contrôle selon la revendication 6, dans lequel ladite au moins une opération prédéfinie de sécurisation comprend au moins l'un quelconque parmi : envoi (A26) d'une requête demandant le traitement en ligne de la transaction en Cours enregistrement (A38), dans un fichier d'historisation, d'une donnée d'historisation 15 prédéfinie ; et configuration (A30) d'au moins un paramètre de fonctionnement du dispositif électronique. 8. Procédé de contrôle selon l'une quelconque des revendications 1 à 7, dans lequel 20 la transaction (TR1 ; TR2) en cours est de type EMV et l'identifiant (IDX2 ; IDX3) du terminal (T2 ; T3) est reçu dans un message de transaction EMV de type GAC. 9. Procédé de contrôle selon la revendication 8, comprenant : réception (Al2 ; A54), lors de la transaction en cours, d'une commande 25 spécifiant une deuxième liste (LT) d'au moins un identifiant de terminal ; et en réponse à ladite commande, enregistrement (A14 ; A56) de ladite deuxième liste dans une mémoire du dispositif électronique en remplacement de ladite première liste. 10. Procédé d'envoi mis en oeuvre par un serveur (SV1 ; SV3), comprenant les étapes suivantes : réception (B6 ; B46) d'une donnée (DN ; IDX3) en provenance d'un dispositif électronique (T1 ; CD) configuré pour coopérer avec un terminal (T2 ; T3) pour mettre en oeuvre une transaction ; détermination (B8 ; B48) de la localisation du dispositif électronique à partir de ladite donnée ; 3053814 27 - sélection (B10 ; B50), à partir de la localisation du dispositif électronique, d'une liste (LT) d'au moins un identifiant (IDT) de terminal ; et - envoi (B12 ; B52) de ladite liste à destination du dispositif électronique de sorte à configurer le traitement, par le dispositif électronique, d'une transaction. 5 11. Procédé d'envoi selon la revendication 10, dans lequel la donnée reçue est l'une parmi : une donnée de localisation (DN) représentative de la localisation du dispositif électronique ; et 10 un identifiant (IDX3) d'un terminal avec lequel le dispositif électronique coopère pour traiter une transaction en cours. 12. Procédé d'envoi selon la revendication 10 ou 11, dans lequel le serveur envoie la liste (LT) d'au moins un identifiant de terminal au dispositif électronique dans un message 15 de transaction EMV. 13. Programme d'ordinateur (PG1 ; PG2) comportant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 12 lorsque ledit programme est exécuté par un ordinateur. 20 14. Dispositif électronique (T1 ; CD) comprenant, lors d'une transaction en cours avec un terminal, les étapes suivantes : un module de réception (MD8) configuré pour recevoir, lors d'une transaction en cours avec un terminal, un identifiant dudit terminal ; 25 un module de détermination (MD10) configuré pour consulter une première liste d'au moins un identifiant de terminal pour déterminer si l'identifiant dudit terminal est inclus dans ladite première liste ; et un module de traitement (MD12) configuré pour traiter la transaction en fonction du résultat de la consultation de la première liste par le module de consultation. 30 15. Serveur (SV3) comprenant : - un module de réception (MD60) configuré pour recevoir une donnée en provenance d'un dispositif électronique, ledit dispositif étant configuré pour coopérer avec un terminal pour mettre en oeuvre une transaction ; 35 - un module de détermination (MD62) configuré pour déterminer la localisation du dispositif électronique à partir de ladite donnée ; 3053814 28 - un module de sélection (MD64) configuré pour sélectionner, à partir de la localisation du dispositif électronique, une liste d'au moins un identifiant de terminal ; et un module d'envoi (MD66) configuré pour envoyer ladite liste à destination du dispositif électronique de sorte à configurer le traitement, par le dispositif électronique, d'une transaction.