FR 3076027 A1 20190628 FR 1762826 A 20171221 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 par 10 exemple, apte à coopérer avec un terminai 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 vise notamment la sécurisation d'une carte à puce fonctionnant selon le 15 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. Les cartes à puce 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 20 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. 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. 25 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 à 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 30 de la carte. Selon 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 un serveur distant (un serveur de la banque émettrice de s carte, par exemple) afin de vérifier la validité de la transaction en cours. En 35 revanche,si la carte EMV fonctionne en mode hors ligne, celle-cl applique des critères de vérification préenregistrés pour décider si la transaction doit être autorisée ou refusée. Un problème réside en ce que, pour certaines transactions EMV, aucune traitement en ligne de la transaction n'est réalisé bien que cela soit demandé par le carte EMV.. L'absence de traitement en ligne d'une transaction EMV peut résulter, par exemple, d'une incapacité temporaire ou permanente du terminal de iectum à communiquer avec le serveur distant de la banque (à bord d'un avion ou d'un navire par exemple, ou lorsque le terminai n'est pas équipé à cet effet) L'absence de traitement en ligne d'une transaction EMV pose un risque sécuritaire majeur dans la mesure où aucune vérification de contrôle ne peut être réalisée à distance par la banque au moment où la transaction est réalisée. Des fraudes sont susceptibles 10 d'être commises lors d'une transaction sans que cela soit détecté en interne par la carte EMV, d'où la nécessité dans certains cas de vérifier la validité d'une :transaction EMV en ligne. L'invention vise à pallier les promes et inconvénients mentionnés ci-dessus et vise plus généralement à sécuriser le traitement d'une transaction, telle qu'une transaction de 15 paiement (de type EMV par exemple), par un dispositif électronique, tel qu'une carte à- puce de type EMV par exemple). Objet et. résumé de l'invention A cet effet, la présente invention concerne un procédé de traitement mis en oeuvre 20 par un dispositif électronique, ledit procédé comprenant les étapes suivantes : réception, en provenance d'un terminal avec lequel le dispositif électronique coopère pour traiter une transaction en cours, d'un identifiant du terminal ou: d'un identifiant d'une entité tierce utilisant ledit terminal pour réaliser la transaction en cours ; 25 détermination, à partir de l'identifiant du terminal ou de l'identifiant de l'entité tierce, de si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal ; si un refus suspect d'un traitement en ligne de la transaction en cours n'est pas susceptible d'être reçu' en provenance du terminal, envoi d'une première. 30 commande au terminal ; et si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal, exécution d'une étape de sécurisation comprenant : envoi au terminal d'une deuxième commande, distincte Oz, la première 35 commande,. pour forcer un traitement en ligne de la transaction en cours par le terminal ; ou o blocage de la transaction en cours pour interdire une validation par le terminal de la transaction en cours sans un traitement en ligne préalable. L'invention permet ainsi d'adapter le traitement, par le dispositif électronique (une carte à puce par exemple), d'une transaction en cours en fonction de Si Ie terminal avec lequel le dispositif électronique coopère présente un risque suffisant d'émettre un refus suspect de traiter en ligne la transaction en cours. Lorsqu'il y a un risque suffisant que le termina- décline de façon suspecte (ou non autorisée) une demande de traitement en ligne, le carte à puce modifie son comportement en envoyant une commande spécifique, dite deaxième commande, reconnaissable par le terminal de sorte à forcer un traitement 10 en ligne de la transaction en cours ou à bloquer la transaction afin d'empêcher que le terminal valide la transaction sans un traitement en ligne préalable, ce qui permet de sécuriser le traitement de la transaction en cours. il n'est alors pas possible pour le terminal de valider la transaction en cours à l'insu du dispositif électronique lorsque la demande de traitement en ligne de ce dernier ne peut être satisfaite. 15 Dans un mode de réalisation particulier, la transaction en cours est une transaction de paiement conforme à la norme EMV. Dans un mode de réalisation particulier, le première commande est un. message (ou cryptogramme) ARQC conforme à la norme EMV pour demander un traitement en ligne de la transaction en cours. 20 Dans un mode de réalisation particulier, la deuxième commande est un message (ou. cryptogramme) AAR conforme à la norme EMV. Dans un mode de réalisation particulier, la deuxième commande est un message APDLJ comprenant un champ indiquant le type de cryptogramme dudit message, ledit champ comprenant une valeur prédéterminée spécifiant que la deuxième commande 25 interdit iu terminal de valider la transaction sans un traitement en ligne avec un serveur distant avant achèvement de la transaction. Dans un mode de réalisation particulier, la première commande est un message (ou cryptogramme) AAC conforme à la norme El« pour refuser la transaction en cours. Dans un mode de réalisation particulier, le blocage de la transaction est réalisé en 30 envoyant au terminal, en réponse à un message de type ARC conforme à la norme EMV indiquant qu'un traitement en ligne n'est pas possible, un message d'erreur bloquant la transaction en cours. Dans un mode de réalisation particulier, le blocage de la transaction en cours est réalisé per non réponse au terminal suite à la réception d'un message de type ARC 35 conforme à la norme EMV indiquant qu'un traitement en ligne n'est pas possible. Dans un mode de réalisation particulier, le procédé comprend, préaiablement l'étape de détermination, une étape d'obtention d'une liste d'au moins un identifiant., 4 l'étape de détermination comprenant une vérification de si l'identifiant du terminal ou l'identifiant de l'entité tierce est inclus dans ladite liste, le dispositif électronique déterminant si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal à partir d'un résultat délivré lors de ladite vérification. Dans un mode de réalisation particulier, l'étape d'obtention de la liste comprend, pour au moins une précédente transaction t,aitée par le dispositif électronique avec un 'précédent terminal préalablement à la transaction en cours, une mise à jour de la liste au cours de laquelle : 10 sur réception d'un message de refus du précédent terminal de traiter en ligne la transaction, le dispositif électronique inclut dans la liste au moins l'un parmi un identifiant du précédent terminal et un identifiant d'une entité tierce associée audit précédent terminal. Dans un mode de réalisation particulier, le procédé comprend une étape de mise à 15 jour de compteur au cours de laquelle : pour chaque précédente transaction pendant laquelle un message de refus de traiter en ligne ladite précédente transaction est reçu d'un précédent terminal, le dispositif électronique incrémente un compteur associé audit précédent terminal ou à une entité tierce associée audit précédent terminal ; et 20 pour chaque précédente transaction pendant laquelle aucun message de refus de traiter en ligne la transaction n'est reçu d'un précédent terminal, le dispositif électronique décrémente un compteur associé audit précédent terminal ou à une entité tierce associée audit précédent terminal ; ladite étape de détermination étant réalisée à partir de l'état du compteur associé au 25 terminai ou à l'entité tierce utilisant ledit terminal pour réaliser la transaction en cours. Dans un mode particulier de réalisation, les différentes étapes du procédé de traitement 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 (ou support d'enregistrement), ce programme étant susceptible d'être mis 30 en oeuvre dans un dispositif électronique 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 de traitement tel que défini ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code 35 objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations ou support d'enregistrement) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de. stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectroniqu encore un moyen d'enregistrement magnétique, par exemple une disquette floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un 10 signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, te circuit étant adapté pour exécuter ou pour être utilisé dons 15 l'exécution du procédé en question. L'invention vise également un dispositif électronique configure pour mettre en oeuvre le procédé de traitement de l'invention. Plus particulièrement, l'invention concerne aussi un dispositif électronique comprenant : un module de réception, en provenance d'un terminal avec lequel le dispositif 20 électronique coopère pour traiter une transaction en cours, d'un identifiant du terminal ou d'un identifiant d'une entité tierce utilisant ledit terminal pour réaliser la transaction en cours ; un module de détermination, à partir de l'identifiant du terminal ou de l'identifiant de l'entité tierce, de si un refus suspect d'un traitement en ligne de la 25 transaction est susceptible d'être reçu en provenance du terminal ; un module de traitement configure : o si un refus suspect d'un traitement en ligne de la transaction n'est pas susceptible d'être reçu en provenance du terminal, pour envoyer une première commande au terminal ; et .30 0 si un refus suspect d'un traitement en ligne de la transaction est susceptible d'être reçu en provenance du terminal, pour exécuter une étape de sécurisation, le module de traitement étant configure, au cours de l'étape de sécurisation, pour envoyer au terminal une deuxième commande, distincte de la p.-emii-,Te commande, de 35 sorte à forcer un traitement en ligne de la transaction par le terminai ou pour bloquer la transaction de sorte à interdire une validation par le terminal ou la transaction sans un traitement en ligne préalable. 6 On notera que ,es différents modes ce réalisation mentionnés ci-avant en relation avec le procédé de traitement de l'invention ainsi que les avantages associés s'appliquent de façon analogue au dispositif électronique de l'invention. Dans un mode de réalisation particulier, in procédé comprend en outre une mémoire configurée pour contenir une liste d'au moins un identifiant, ledit module de détermination étant configure pour comparer l'identifiant du terminal ou l'identifiant de l'entité tierce audit au moins un identifiant de la liste pour déterminer si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal. 10 Dans un mode de réalisation particulier, le dispositif électronique est une carte à puce. Dans un mode de réalisation particulier, la transaction en cours est une transaction de paiement de type EMV. Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de 15 composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'a un composant matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou. plusieurs sous-programmes d'un programme, ou de manière plus- générale à tout élément 20 d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit clans ce document pour le module concerné. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel. (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble: de fonctions, selon ce qui est décrit dans ce .document pour le module concerné. Il peut 25 s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, etc. reve description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la 30 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: - la figure 1 représente, sous forme d'un diagramme, les étapes d'un procédé de traitement d'une transaction EMV, selon un exemple particulier ; - :e figure 2 représente, SOUS forme d'un diagramme, les étapes d'un procédé de 35 rraiternent d'une transaction EMV, scion un exemple particulier ; 7 - .1a figure 3 représente schématiquement un environnement comprenant un dispositif électronique conforme à un mode de réalisation particulier de l'invention ; - la figure 4 représente schématiquement la configuration d'un dispositif électronique selon un mode de réalisation particulier de l'invention ; la figure 5 représente, sous forme d'un diagramme, les étapes d'un procédé dé traitement selon un mode de réalisation particulier de l'invention ; la figure 6 représente schématiquement la structure d'une commande conforme à un mode de réalisation -particulier de l'invention ; 10 la figure 7 représente, sous forme d'un diagramme, les étapes d'un procédé de traitement selon un mode de réalisation particulier de l'invention ; la figure 8 représente, sous forme d'un diagramme, ;es étapes d'un procédé de traitement selon un mode de réalisation particulier de l'invention ; et la figure 9 représente, sous forme d'un diagramme, les étapes d'un procédé de 15 traitement selon un mode de réalisation particulier de l'invention. Description détaillée de plusieurs modes de réalisation Comme indiqué précédemment, la présente invention concerne les dispositifs électroniques, tels que les cartes à puce par exemple, configurés pour coopérer avec un 20 terminal externe pour réaliser une transaction, dans le domaine bancaire par exemple. Dans .ce document, les expressions « cryptogramme » et « certificat cryptographique » peuvent être utilisées de façon interchangeable. La figure 1 représente un exemple d'une transaction de, paiement conforme au protocole EMV, réalisée par une carte à puce 2 en coopération avec un terminal de lecture 25 4. Dans cet exemple, la carte à puce 2 est une carte EMV. Lors de la mise en oeuvre d'une transaction, le protocole EMV S'articule généralement en trois phases, des variantes étant toutefois possibles. On comprendra que certains moyens et opérations généralement mis en oeuvre lors d'une transaction EMV ont été volontairement omis car- ils ne sont pas nécessaires à la compréhension de la présente 30 invention. Lors d'une première phase destinée à authentifier la carte à puce 2 utilisée, le terminal 4 et la carte 2 s'échangent un message RESET (RST) en 52 puis une réponse ATR en S4. En 56, le- porteur de la tarte .sélectionne via le terminal 4 le mode de transaction 35 souhaité, déclenchant ainsi l'envoi d'une commande SELECT à la carte 2 afin d'initier le début de là transaction EMV. Une fois la phase d'authentification de carte achevée, le protocole EMV procède à une phase d'authentification (non représentée) du porteur de la carte 2. Le terminal 4 détermine le procédé d'authentification du porteur à appliquer et détermine en particulier si la transaction -est effectuée en mode avec vérification de code ou en mode sans vérification de code. Si le mode avec vérification de code est sélectionné, la carte à puce 2 vérifie la validité du code PIN entré par le porteur sur le terminal 4. Si en revanche le mode sans vérification de code est sélectionné, aucune vérification de code PIN n'est réalisée. Ce cas se produit par exemple lorsque le terminal est dans l'Incapacité de prendre en charge !a vérification d'un code PIN. Dans ce cas, la signature manuscrite du 10 porteur peut éventuellement être requise pour authentifier ce dernier. Une fois la phase d'authentification du porteur achevée, le protocole EMV initie la phase de vérification de la transaction. Pour ce faire, le terminal envoie (58) à la carte à. puce 2 une première commande APDU dite GENERATE AC ou G.AC, notée ici GAC1. Cette commande, bien connue de l'homme du métier, comprend des informations sur la 15 transaction en cours telles que le montant de la transaction, la devise utilisée, le type de transaction, etc. La carte EMV réalise alors, à partir des données reçues dans la .commande GAC1, un premier contrôle de sécurité au cours duquel la carte 2 vérifie (59) la transaction selon des critères de vérification prédéfinis. La carte 2 envoie (S10) ensuite, en réponse, un 20 cryptogramme (ou certificat cryptographique) comprenant un code d'authentification- de message (ou MAC pour Message Authentification ('ode» en anglais). Ce code d'authentification MAC est par exemple crypte à partir d'une clé cryptographique mémorisée dans la carte 2. Plus précisément, dans l'exemple considéré en figure .1 la carte à puce 2 envoie en 25 iS10 un message de type ARQC (« Authorization Re.quest Cryptogram») indiquant que la carte souhaite poursuivre la transaction en ligne avec, par exemple, un serveur distant de l'émetteur 6 de la carte 2 utilisée (mode en ligne). Le terminal 4 transmet (312) alors le cryptogramme ARQC à l'émetteur 6 qui réalise (513) à distance un certain nombre de vérifications afin de s'assurer que la transaction est valide. Le terminal 4 reçoit (514) 30 ensuite, en réponse, un message crypté ARC (« Authorization Response -Code .») comprenant un cryptogramme ARPC (« Authorisation Response Cryptogram ») et qui indique la décision de l'émetteur 6. Le terminal 4 transmet (516) alors la réponse ARC (positive ou négative) de l'émetteur 6 à la carte 2. Le terminal 4 envoie ensuite en -520, à la carte à puce 2, une 35 deuxième commande APDU bien connue de type GENERATE AC ou GAC, notée ici GAC2. La carte 2 détermine, lors d'une étape 522 de contrôle de sécurité, la suite à donner à la transaction en cours. Si la carte 2 accepte la transaction, celle-ci envoie (S24), en réponse 9 à la commande GAC2, un cryptogramme de type TC (transaction acceptée) au terminal Ti. Dans le cas contraire, la carte 2 envoie un cryptogramme de. type AAC (pour « Application Authentication Cryptogram») au terminal 4 signifiant le refus de la tra nsaction. Toutefois, comme indiqué ci-dessus, un traitement en ligne d'une transaction EMV n'est pas toujours possible quand bien même cela est demandé par la carte EMV au cours du traitement de la transaction. Dans certains cas, la transaction EMV est validée par le terminal de lecture malgré le refus de ce dernier de poursuivre en ligne le traitement de la transaction, comme expliqué ci-après. 10 La figure 2 représente un autre exemple d'une transaction de paiement EMV réalisée également par la carte à puce 2 en coopération avec le terminal 4. Dans cet exemple, la demande de traitement en ligne de la transaction par la carte EMV 2 n'est pas satisfaite. Plus précisément, la carte 2 et le terminal /1 réalisent les étapes 52 à 510 comme déjà décrit précédemment en référence à la figure 1. Cet exemple diffère en ce 15 qu'en réponse à la demande ARQC (510) de la carte EMV 2 de poursuivre la transaction en ligne, le terminal 4 envoie (530) un message ARC (pour « Authorization Response Code») conforme à la norme EMV indiquant un refus de traiter la transaction en ligne (figure 2). En réponse, la carte EMV 2 envoie (532) au terminai 4 un cryptogramme AAC signifiant le refus de la transaction. 20 Toutefois, malgré le refus (S32) de la transaction par la carte 2, le terminal 4 peut dans certains cas poursuivre (534) le traitement de la transaction EMV. Dans ce cas, le terminal 4 peut ainsi valider la transaction EMV alors même que, du point de vue de la carte 2, la transaction a été refusée. Dans certains cas, le terminal 4 peut être configuré pour procéder de manière différée à la vérification en ligne de la transaction EMV, c'est-à- 25 dire après achèvement de la transaction en question. Ce mécanisme, appelé ici « traitement en ligne différé » ou « autorisation en ligne différée », peut être mis en oeuvre pour diverses raisons. Certains points de vente (commerces...) qui sont particulièrement sollicités peuvent par exemple mettre volontairement en oeuvre ce mécanisme d'autorisation en ligne différé pour accélérer et fluidifier le traitement de 30 transactions de paiement. Un commerce utilisant ce mécanisme peut alors vérifier en ligne une transaction dans un délai donné (par exemple, dans les 24 heures suivant la date/heurc., de la transaction). Dans un exemple particulier, le terminal de lecture enregistre les requêtes ARQC collectées lors des transactions traitées dans une période donnée (dans une même journée par exemple) puis envoie en différé l'ensemble de ces 35 requêtes ARQC de façon groupée au(x) serveur(s) distant(s) concerné(s). Ce mécanisme de traitement en ligne différé permet ainsi de réaliser des transactions EMV en mode hors en ligne avec des vérifications de contrôle moins contraignantes. Ce 10 mécanisme présente cependant un risque sécuritaire majeur dans la mesure où il n'est pas possible pour la banque de réaliser en temps réel certaines vérifications de contrôle lorsqu'une transaction EMV est en cours de traitement. Un traitement en ligne n'est possible qu'après achèvement de la transaction, ce qui ne permet pas notamment de bloquer la transaction si besoin, augmentant ainsi sensiblement les risques de fraude. Ce problème sécuritaire est accru par le fait que la validation de la transaction se fait à l'insu de la carte EMV. L'invention propose un procédé de traitement visant à adapter le comportement d'une carte EMV, et plus généralement d'un dispositif électronique, afin de pallier les 10 problèmes et inconvénients mentionnés précédemment. Selon différents modes de réalisation, l'invention prévoit notamment un procédé, mis en oeuvre par un dispositif électronique tel qu'une carte à puce par exemple, comprenant : la réception, en provenance d'un terminal avec lequel le dispositif électronique coopère pour traiter une transaction en cours, d'un identifiant du terminal ou d'un identifiant d'une entité tierce 15 utilisant ledit terminal pour réaliser la transaction en cours ; la détermination, à partir de. l'identifiant du terminal ou de l'identifiant de l'entité tierce, de si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal ; si un refus suspect d'un traitement en ligne de la transaction en cours n'est pas susceptible d'être reçu en provenance du terminal, l'envoi d'une première commande 20 au terminal ; et si au contraire un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal, l'exécution d'une étape de sécurisation comprenant : l'envoi au terminal d'une deuxième commande, distincte de la première commande, à la place de la première commande, pour forcer un traitement en 25 ligne de la transaction en cours par le terminal ; ou le blocage de la transaction en cours pour interdire une validation par le terminal de la transaction en cours sans un traitement en ligne préalable. L'invention porte également sur un dispositif électronique configuré pour mettre en oeuvre un procédé de contrôle comme défini ci-dessus. 30 D'autres aspects et avantages de la présente invention ressortiront .des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. Dans le présent exposé, des exemples de mises en oeuvre de l'invention sont décrits en relation avec une carte à puce de type EMV. On comprend que l'invention ne se limite par exclusivement aux cartes à puce EMV mais s'applique plus généralement à tout 35 dispositif électronique configure pour mettre en oeuvre une transaction, y compris des dispositifs autre que des cartes à puce et qui utilisent le standard EMV, et à des dispositifs électroniques qui utilisent d'autres standards de transaction. 11 Il convient également de noter que la notion de transaction est ici entendue au sens large et 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 ic: décrits dans le cadre d'une carte de paiement destinée. à réaliser une transaction bancaire. A noter que d'autres types de transactions ou opérations sont envisageables dans le cadre de l'invention. 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 10 décrits par souci de simplicité. La figure 3 représente, de manière schématique, un environnement comprenant une .carte à puce 20 de type EMV, conforme à un mode de réalisation particulier. Cette carte .EMV 2 peut coopérer avec un terminal (ou lecteur) Ti pour traiter une transaction EMV. Le terminal Ti fait l'interface entre la carte à puce 2 et un serveur distant SV1, ce dernier 15 étant dans cet exemple un serveur de l'émetteur 14 (un organisme bancaire par exemple) de la carte à puce 2. Comme indiqué par la suite, le serveur SV1 intervient en particulier pour traiter en ligne une transaction EMV, sur requête de la carte à puce 20. Dans l'exemple considéré ici, la transaction EMV est une transaction de paiement et le terminal Ti est un terminal de paiement. On suppose par exemple qu'un utilisateur 10 20 utilise sa carte à puce 2 pour réaliser un .paiement à l'aide du terminal de paiement d'une entité tierce 12 (un marchand ou un commerce par exemple). On comprendra que certains éléments généralement présents dans une carte à puce EMV 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 20 représentée en figure 3 ne 25 constitue qu'un exemple de réalisation, d'autres mises en oeuvre étant possibles dans le cadre de l'invention. L'homme du métier comprend en particulier que certains éléments .de la carte à puce 20 ne sont décrits ici que pour faciliter la compréhension de l'invention, ces éléments n'étant pas nécessaires pour mettre en oeuvre l'invention. Dans cet exemple, la carte à puce 20 est configurée pour communiquer, via le 30 terminal Tl, avec le serveur distant SV1 afin de mettre en oeuvre, selon le protocole EMV, une transaction dite « en ligne », c'est-à-dire impliquant un échange avec une entité de contrôle tierce (c'est-à-dire l'émetteur 14 de la carte à puce 20, dans cet exemple). Plus précisément, la carte à puce 20 comprend dans cet exemple des contacts externes 22 configurés pour coopérer avec le terminal Ti, un processeur 21, une 35 mémoire volatile réinscriptible. (de type RAM) 26 et une mémoire non volatile réinscriptible 28 (de type Flash par exemple). 12 La mémoire 28 constitue dans cet exemple un support d'enregistrement u support d'informations) conforme à un mode do réalisation particulier, lisible par la carte à puce 20, et sur lequei est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG1 comporte des instructions pour l'exécution des étapes d'un procédé de traitement selon un mode de réalisation particulier. Les principales étapes de ce procédé sont décrites ultérieurement, selon des modes de réalisation particuliers de l'invention. Dans un exemple particulier, la carte à puce 20 est conforme à la norme 150 7816. Dans ce cas, les contacts externes 22 présentent des caractéristiques conformes à cette norme. On comprend toutefois que d'autres modes de réalisation sont possibles sens l'utilisation de tels contacts externes. La carte à puce 20 peut par exemple être configurée pour coopérer avec le terminal 1-1 en moce sans contact à l'aide d'une antenne radiofréquence (non représentée) intégrée dans la carte 20. Toujours dans l'exemple considéré ici, la mémoire non volatile réinscriptible 28 est en outre configuree pour stocker une liste (ou base de données) LT pouvant comprendre au moins un identifiant IDT d'un terminal et/ou au moins un identifiant IDE d'une entité tierce (un commerce ou un marchand par exemple). Comme représenté en figure 3, on suppose dans cet exemple que la liste LT comporte des identifiants de terminal IDT1, IDT2 et. IDT3 ainsi que des identifiants d'entités tierces respectives IDE1, IDE2 .et IDE3. A noter qu'une même entité tierce (ou marchand) peut disposer d'une pluralité de terminaux distincts dans un ou plusieurs points de vente. Le cas échéant, la mémoire 28 peut également stocker au moins un compteur Ci, à savoir les compteurs CT1 et CT2 dans cet exemple, dont l'usage sera décrit ultérieurement. Le processeur 6 piloté par le programme d'ordinateur PG1, met ici en oeuvre un certain nombre de modules représentés en figure 4, à savoir un module de réception MD2, un module de détermination MD4, un module de traitement MD5 et éventuellement un module d'obtention MD8. Comme illustré en figure 3, le module de réception MD2 est configuré dans cet exemple pour recevoir, en provenance du terminal Tl avec lequel la carte à puce 20 coopère pour traiter une transaction en cours, un identifiant du terminal Ti ou un identifiant d'une entité tierce utilisant le terminal T pour réaliser la transaction en cours. Le module de détermination MD4 est configure pour déterminer, à partir de l'identifiant reçu par le module de réception MD2 (i.e. l'identifiant du terminal ou l'identifiant de l'entité tierce), si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal. Autrement dit, le module de détermination MD4 détermine s'il y a un risque suffisant que le terminal Ti. 13 refuse de façon non autorisée une demande de traitement en ligne de la transaction en cours. Le module de traitement MD6 est configure pour agir de la manière suivante : a) si un refus suspect d'un traitement en ligne de la transaction en cours n'est pas susceptible d'être reçu en provenance du terminal Ti' le module de traitement MD6 envoie une première commande au terminal Tl, par exempte pour demander un traitement en ligne de la unsaeaon en cours ou pour refuser la transaction en cours ; et b un refus suspect d'un traitement en ligne de la transaction en cours est 10 susceptible d'être reçu en provenance du terminal Ti, le module de traitement MD6 exécute une étape de sécurisation au cours de laquelle le module de traitement MD6, au lieu d'envoyer la première commande : envoie au terminal Ti une deuxième commande, distincte de la première commande, de sorte à forcer un traitement en liqne de la transaction en cours par le terminal Tl ou bloque la 15 transaction en cours de sorte à interdire une validation par le terminai Ti de la transaction en cours sans un traitement en ligne préalable. Un tel blocage peut être réalisé par la carte à puce en interrompant la transaction, comme expliqué ultérieurement. Comme expliqué par la suite, un principe de l'inventon réside dans l'adaptation du 20 traitement de la transaction en cours par la carte à puce en fonction de si e terminal présente un risque suffisant d'émettre .un refus suspect de traiter en ligne la transaction en cours. Le module d'obtention MD8 est configure pour obtenir la liste LT d'au moins un identifiant. Pour ce faire, le module d'obtention MD8 peut. par exemple recevoir ou 25 générer cette liste LT. Dans ce cas, le module de détermination MD4 peut être configure pour vérifier si l'identifiant du terminal avec lequel il coopère ou l'identifiant de l'entité tierce correspondante est inclus dans ladite liste LT, et pour détermine- si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal Ti à partir du résultat de cette vérification. 30 La configuration et le fonctionnement des modules MD2-M.08 de la carte à puce 20 apparaîtront plus précisément dans les exemples de réalisation décrits ci-après en référence aux figures 5-9. On comprend toutefois que les modules MD2-MD8 tels que représentés en figure 4 ne représentent qu'un exemple de mise en oeuvre non iimitatif de l'invention. 35 La figure 5 représente les étapes d'un procédé de traitement n-Ës> en oeuvre par la carte à puce 20 illustrée en figues 3 et 4, selon un mode de réalisation particulier. Pour ce faire, la .carte à puce 20 exécute le programme d'ordinateur PG1. 14 On suppose ici que la carte à puce 20 coopère avec le terminal Ti pour traiter une transaction TR1 en cours, à savoir Une transaction EMV de paiement dans cet exemple. Au cours d'une étape de réception 540, la carte à puce 20 reçoit, en provenance du terminal Ti avec lequel ia carte coopère pour traiter la transaction TR1 en cours, au 5 moins l'un parmi un identifiant IDTI du terminal Ti et un identifiant IDE1 de l'entité tierce 12 utilisant le terminal Ti pour réaliser la transaction TR1 en cours. Dans cet exemple, l'entité tierce 12 en question est une entité marchande (un marchand par exemple) utilisant le -terminal Ti à un point de vente particulier pour réaliser .une transaction de paiement. 10 Les identifiants IDTI et/ou IDE1 peuvent être transmis par le terminal Tl à la carte à puce 20 dans un message EMV approprié, par exemple dans un message de type GENERATE AC ou GAC, correspondant à le commande GAC1 décrite précédemment en référence à l'étape 58 représente en figure 1. Au cours d'une étape de détermination 542, la carte à puce 20 détermine, à partir de 15 l'identifiant IDT1 du terminal Tl ou de l'identifiant IDE1 de l'entité tierce, si un refus suspect d'un traitement en ligne de la transaction en cours TRI est susceptible d'être (risque d'être) reçu en provenance du terminal Ti. Autrement dit, la carte à puce 20 détecte s'il y a un risque suffisamment grand que le terminal T1 refuse de façon non autorisée une demande de traitement en ligne de la transaction TRi émise par la carte à 20 puce 20. Un tel refus suspect de la part du terminal Ti peut survenir en particulier lorsqu'un mécanisme d'autorisation en ligne différée tel que décrit ci-avant est mis en oeuvre par le terminal Ti à l'insu de la carte à puce 20. Dans l'exemple décrit ici, lors de l'étape 542, la carte à puce 20 consulte la liste LT et compare l'identifiant IDTI ou IDE1 reçu en 540 avec cette liste LT afin de déterminer si 25 un refus suspect d'un traitement en ligne de ila transaction TR1 en cours est susceptible d'être reçu en provenance du terminal Ti. Dans cet exemple, la liste LT sert de liste noire (ou « black list ») : la carte à puce 20 détermine qu'un refus suspect d'un traitement en ligne de la transaction TR en cours est susceptible d'être reçu en provenance du terminal Ti uniquement si l'identifiant IDTI du terminal Ti ou si l'identifiant IDEl de l'entité tierce 30 est inclus dans la liste LT. Il est toutefois possible, selon une variante de réalisation, d'utiliser à l'inverse la liste .LT en tant que liste blanche (ou « white list ») de sorte à ce qu'elle spécifie uniquement les terminaux et/Ou entités tierces pour lequel il n'y pas de risque que la carte à puce 20 se voit refuser une demande de i.raitement en ligne de la transaction TR1 en cours. 35 L'étape de détermination 542 peut être réalisée par la carte à puce 20 au cours par exemple d'une étape d'analyse telle que décrite précédemment en référence à l'étape S9 des figures 1 et 2. 15 Dans le cas où le résultat de la détermination en S42 est négatif (i.e. un refus suspect d'un traitement en ligne de la transaction TR1 en cours n'est pas susceptible d'être reçu en provenance du terminal Ti), la carte à puce 20 envoie (544) au terminal Ti une commande .CMD1, en tant que première commande au sens de l'invention, pour demander un traitement en ligne de la transaction TR1 en cours. Dans cet exemple, la première commande CMD1 est un cryptogramme ARQC conforme à la norme EMV. Le traitement de la transaction TRi se poursuit ensuite normalement. En particulier, le terminal Ti transmet la première commande CMD1 au serveur distant SV1 de sorte qu'un traitement en ligne (S48) de la transaction TR1 soit réalisé par la carte à puce 20 en 10 coopération avec le terminal Ti et le serveur SV1. Dans le cas contraire où le résultat de la détermination en S42 est positif (i.e. un refus suspect d'un traitement en ligne de la transaction TR.1 en cours est susceptible d'être reçu en provenance du terminal Ti), la carte à puce 20, au lieu d'envoyer la première commande CM1, exécute une étape 546 de sécurisation. Dans ce mode de 15 réalisation, cette étape 546 de sécurisation comprend un envoi au terminal Ti d'une commande CMD2, en tant que deuxième commande au sens de l'invention, cette commande CMD2 étant distincte de la première commande CMD1, pour forcer un traitement en ligne de la transaction TR1 en cours par le terminal Ti. Au !ieu d'envoyer la première commande CMD1 de type ARQC (comme en 544), la 20 carte à puce 20 adapte donc son comportement en 546 afin de contraindre le terminal. Ti a vraiment poursuivre la transaction TR en mode en ligne, quand bien même le terminal Ti serait configuré pour mettre en oeuvre le mécanisme d'autorisation en ligne différée mentionné ci-avant. Sur réception (S16) de la deuxième commande CMD2 le terminal Ti procède au 25 traitement en ligne de la transaction TRI Selon un exemple particulier, la commande CMD2 envoyée en 546 est un cryptogramme AAR (pour « Application Authorisation Referral») conforme à la norme EMV. L'envoi d'un cryptogramme AAR permet de déclencher des vérifications supplémentaires de la transaction TRI. par l'émetteur 14. 30 Selon un exemple particulier représenté en figure 6' la deuxième commande CMD2 envoyée en S16 est une commande ARDU comprenant un champ indiquant le type de cryptogramme de ladite commande, ce champ comprenant une valeur prédéterminée spécifiant que cette commande CMD2 interdit au terminal T1 de valider la transaction TR1 sans un traitement en ligne préalable avec l'émetteur 1,4 avant achèvement de la 35 transaction TR1. Dans cet exemple, le champ en question est un champ CID (pour « Cryptogra.m Information Data») conforme à la norme EMV. Une valeur V1 prédéterminée peut ainsi être attribuée au champ CID afin de forcer le terminal Ti à 16 réaliser un traitement en ligne si nécessaire. La carte à puce 20 peut, par exemple, fixer un bit particulier dans le champ CID à la valeur '1' afin de commander au terminal T1 de poursuivre la transaction en mode en ligne. Pour ce faire, on peut utiliser un. bit RFU (pour « Reserved for Future Use») prédéterminé dans le champ CID, conformément à la norme EMV. L'invention permet ainsi d'adapter le traitement, par la carte à puce, d'une transaction en cours en fonction de si le terminal avec lequel la carte à puce coopère présente un risque suffisant d'émettre un refus suspect de traiter en ligne la transaction en cours. Lorsqu'ii y a un risque suffisant que le terminal Ti décline de façon suspecte (ou non 10 autorisée) une demande conventionnelle ARQC de traitement en ligne, il est alors possible de forcer un traitement en ligne de la transaction TR1 en cours, à l'aide ici d'une deuxième commande CMD2 prévue à cet effet. et reconnaissable par le terminal Ti.. La figure 7 représente les étapes d'un procédé de traitement mis en oeuvre par la carte à puce 20 illustrée en figues 3 et 4, selon un mode de réalisation particulier. Pour 15 ce faire, la carte à puce 20 exécute le programme d'ordinateur PG1. On suppose dans cet exemple que le carte à puce- 20 coopère avec le terminal Ti pour traiter une transaction TR1 en cours, à savoir une transaction EMV de paiement dans cet exemple. Au cours d'une étape de réception 510 comme déjà décrite en référence à la figure 20 5, la .carte à puce 20 reçoit, en provenance du terminal Ti avec lequel la carte coopère pour traiter la transaction TR1 en cours, au moins l'un parmi un identifiant IDT1 du terminal T1 et un identifiant IDE". de l'entité tierce 12 utilisant le terminal Ti pour réaliser la transaction TR1 en cours. Dans cet exemple, l'entité tierce 12 en question est une entité marchande (un marchand, par exemple) utilisant le terminal T1 à un point de 25 vente particulier pour réaliser une transaction de paiement. Les identifiants IDT1 et/ou IDE1 peuvent être transmis par le terminal T1 à ta carte à puce 20 dans un message EMV, par exemple dans un message de type GENERATE AC ou GAC, correspondant à la commande GAC1 décrite précédemment en référence à l'étape 58 représentée en figure 1. 30 Au cours d'une étape .d'envoi 550, la carte à puce 20 envoie au terminal Ti un message MSG2 conforme à la norme EMV, à savoir une commande AROC dans cet exemple, afin de demander un traitement en ligne de la transaction TR1 en cours. A ce stade, la carte à puce 20 ne sais pas si le terminal T1 va accepter ou refuser de poursuivre en ligne la transaction. 35 En réponse, on suppose ici que le terminal Ti envoie (552) à la carte 20 un message MSG3 conforme à la norme EMV, à savoir un message ARC dans cet exemple, indiquant que la demande de transaction en ligne est refusée. Un te i refus intervient par exemple 17 lorsque le terminal Ti met en oeuvre un mécanisme d'autorisation en ligne différée tel que déjà décrit ci-avant. A noter qu'un tel refus de la part du terminal Ti n'est pas nécessairement suspect ou frauduleux et peut également résulter d'une incapacité légitime du terminal TI à communiquer avec l'émetteur 14 de la carte à puce 20 (en raison, par exemple, d'une incapacité à établir une connexion avec le serveur SVI). En outre, le terminal Tl peut être configure pour mettre en oeuvre le mécanisme d'autorisation en ligne différée pour une paille seulement des transactions, de sorte qu'un refus de sa part à traiter en ligne une transaction en cours peut résulter, par exemple, aussi bien d'une raison légitime que de la mise en oeuvre d'un. mécanisme d'autorisation 10 en ligne différé. Sur réception (552) du message MSG3 de refus de traiter en ligne la transaction, la carte à puce 20 réalise une .étape 554 de détermination analogue à l'étape 542 de détermination telle que représentée en figure 6. Plus précisément, lors de l'étape 554 (figure 7), la carte à puce 20 détermine, à partir de l'identifiant IDT1 du terminal Ti ou 15 de l'identifiant IDE1 de l'entité tierce 12, si un refus suspect d'un traitement en ligne de la transaction TR1 en cours est susceptible d'être (risque d'être) reçu en provenance du terminal Ti. Autrement dit, la carte à puce 20 détecte s'il y a un risque suffisamment grand que le terminal Ti refuse de façon non autorisée une demande de traitement en ligne de la transaction TR1 émise par la carte à puce 20. A noter que dans l'exemple 20 particulier considéré ici, la carte à puce 20 a déjà reçu le message de refus M.SG2 et doit donc déterminer en 554 si ce refus de traitement en ligne est suspect ou non. Selon une variante, cette étape de détermination 554 est réalisée avant réception 552 du message MSG3. Dans l'exemple décrit ici, lors de l'étape 554 de détermination, la carte à puce 20 25 consulte la liste LT et compare l'identifiant IDT1 ou IDE1 reçu en S40 avec- cette liste LT afin de déterminer si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal Ti. Dans cet exemple, la liste LT sert de liste noire (ou « lis-t») : la carte à puce 20 détermine que le refus reçu en S52 au travers du message ARC est suspect uniquement si l'identifiant IDT1 du terminal 30 Ti ou si l'identifiant IDE1 de l'entité tierce est indus dans la liste LT. Ii. est toutefois possible, selon une variante de réalisation, d'utiliser à l'Inverse la liste LT en tant que liste blanche (ou « white list ») de sorte à ce qu'elle spécifie uniquement les terminaux et/ou entités tierces pour lesquels la carte à puce 20 autorise le refus du terminal à poursuivre la transaction en ligne. 35 Pans le cas où le résultat de la détermination en 554 est négatif (i.e. pas de refus suspect de la part du terminal Ti à traiter en ligne la transaction TR1 en cours), la carte à puce 20 envoie (556) au terminal Ti une commande CMD3, en tant que première 18 commande au sens de l'invention, pour mettre fin à la transaction TR1 en cours. Dans cet exemple, la première commande CMD3 est un cryptogramme AAC conforme à la norme EMV, signifiant que la carte à puce 20 refuse la transaction. Grâce à l'étape 554 de détermination, il est détecté ici qu'il n'y a pas de risque significatif que le terminal Ti valide la transaction TR1 à l'insu de la carte à puce 20, et ce malgré- le refus de cette dernière en S56, comme cela peut être le cas par exemple lorsqu'un mécanisme d'autorisation en ligne différée est mis en oeuvre. En réponse à la première commande CMD3, le terminal Ti réagit donc normalement en Mettant fin à la transaction TR1. Dans le cas contraire où le résultat de la détermination en S54 est positif (i.e. cas 10 d'un refus suspect de la part du terminal Ti à traiter en ligne la transaction TR1 en cours), la carte à puce 20, au lieu d'envoyer la première commande CMD3, exécute une étape 558 de blocage pour interdire une validation par le terminal T de la transaction TR1 en cours sans un traitement en ligne préalable de cette transaction TR1. Cette étape 558 de blocage constitue ici une étape de sécurisation au sens de l'invention. 15 Selon un premier exemple de réalisation, "ors de l'étape 558 blocage, la carte à puce 20 envoie (558a) au terminal Ti un message d'erreur CMD4, en tant que deuxième conimande au sens de l'invention, cette commande CMD4 étant distincte de la première commande CMD3. Cette commande CMD4 correspond ici à une commande APDU de statut d'erreur qui a pour effet de bloquer (ou suspendre) la transaction TR1 en cours de 20 sorte à ce que le terminal 11 soit dans l'obligation de refuser ;a transaction TRI. La commande d'erreur CMD4 est par exemple un statut d'erreur (appelé aussi « Status 1/1/ord ») conforme à la norme VISO 7816-4. Un tel statut d'erreur peut également être tel que défini dans la norme « EMV book 3». Ce statut d'erreur indique au terminal Ti l'état du traitement d'une commande, c'est-à-dire si une commande (C1D3 par 25 exemple) a été correctement exécutée. Les deux normes précitées définissent deux types principaux de statut d'erreur : commande exécutée (« process completed ») et commande non exécutée (« process aborted»). Au lieu d'envoyer la première commande CMD3 de type AAC (comme en 556), la carte à puce. 20 adapte donc son comportement en 558 afin de forcer le blocage de la 30 transaction TR1 en cours, de sorte qu'il ne soit pas possible pour le terminal Ti de valider la transaction TR1 malgré le refus de la carte à puce 20. L'envoi (558a) d'un message de statut d'erreur entraîne la suspension (560) de la transaction TR1 en cours, ce qui empêche le terminal Ti de valider la transaction. Selon un deuxième exemple de réalisation, lors de l'étape 558 de blocage, ia carte à 35 puce 20 bloque la transaction TR en cours par non réponse (S58b) au message NISG3 de type ARC indiquant le refus du -terminal Ti à traiter en ligne la transaction TRI en cours. Autrement dit, au lieu d'envoyer la commande CMD3 de type AAC (comme en 556), la 19 carte à puce 20 décide d'omettre (S58b) de répondre au message ARC précédemment reçu en provenance du terminal Ti en 552. L'absence de réponse de la part de la carte à puce 20 au message MSG3 (ARC) a pour effet de bloquer la transaction TR1 en cours de sorte qu'il n'est pas possible pour le terminai Ti de la valider. La carte à puce 20 adapte donc ici aussi son comportement en 558 afin de forcer le blocage de la transaction TRI en cours, de sorte qu'il ne soit pas possible pour le terminai il de valider la transaction TR1 ma;gre le refus de la .carte puce 20. L'absence de réponse entraîne la suspension (560) de la transaction TR1 en cours, ce qui empêche le terminal Ti de valider la transaction. 10 Au cours de l'étape 558 de sécurisation, sur détection du message d'erreur CMD4 ou sur détection qu'aucune réponse n'a été reçue (par exemple dans un temps prédéterminé) à compter de l'envoi S52 de son message M5G3, le terminal T3 met donc fin a la transaction TR1 (560). Dans les modes de réalisation représentés en figures 5 et 7, la carte puce 20 15 utilise une liste LT pour déterminer s'il y a un risque de refus suspect de la part du terminal 1-1 à traiter en ligne la transaction TRi en cours. La carte à puce 20 peut obtenir cette liste U selon une quelconque méthode appropriée, par exemple en générant cette liste ou en recevant celle-ci de l'extérieur. La figure 8 représente schématiquement un exemple de réalisation selon lequel la 20 carte à puce 20 obtient en 570 la liste LT préalablement à l'étape de détermination (542 ou S5,4) et à l'étape de sécurisation (546 ou 558) décrites précédemment. Cette liste LT peut être créée par la carte à puce 20 elle-même ou fournie par un terminal lors d'une transaction en cours' par exemple. On suppose ici que cette étape 570 d'obtention de la liste LT comprend au moins une 25 étape de mise à jour réalisée par la carte à puce 20 lors d'une ou de précédentes transactions TR2 traitées au fil du temps avec des terminaux. Autrement dit, dans un exemple particulier représenté en figure 8, la carte à puce 20 réalise pour au moins une précédente transaction TR2 traitée avec un précédent terminai préalablement à la transaction 1 R1, une mise à jour de la liste au cours de laquelle : sur réception d'un 30 message de refus du précédent terminal de traiter en ligne ladite précédente transaction, le dispositif électronique inc.iut (572) dans la liste Li- au moins l'un parmi un identifiant IDT Ou précédent terminal et un identifiant IDE d'une entité tierce associée audit précédent terminal. Chaque précédent terminal avec lequel coopère la carte à puce 20 lors d'une précédente transaction peut être le terminal Ti ou un quelconque autre terminal. La carte à puce 20 >eut ainsi mettre à jour son historique représenté par la liste LT afin d'être capable d'identifier les terminaux et ou les entités tierces associées qui 20 présentent un risque sécuritaire de refuser un traitement en ligne d'une transaction. Grâce à lu liste LT mise à jour, la carte à puce 20 peut adapter son comportement selon le terminal et/ou l'entité tierce mis en jeu. Par ailleurs, la carte à puce 20 peut prendre en compte au moins un critère prédéfini supplémentaire lors des étapes de détermination 542 (figure 5) et 554 (figure 7). En particulier, la carte à puce 20 peut utiliser au moins un compteur CT comme représenté en figure 3 pour déterminer si un refus suspect d'un traitement en ligne d'une transaction en cours est susceptible d'être reçu en provenance du terminai. La figure 9 représente schématiquement un exemple de réalisation selon lequel la 10 carte à puce 20 maintient é jour (étape 580) au moins un compteur (CT) de la façon suivante : pour chaque précédente transaction TR2, traitée par la carte à puce 20, pendant laquelle un message de refus (message ARC) de traiter en ligne ladite précédente transaction est reçu d'un terminal, dit « précédent terminal », la 15 carte à puce 20 incrémente un compteur Cil associé audit précédent terminal (par exemple Ti.) ou un compteur CT2 associé à une entité tierce (par exemple l'entité 12) utilisant ledit précédent terminai ; pour chaque précédente transaction TR2, traitée par la carte à puce 20, pendant laquelle aucun message de refus (messade ARC) de traiter en ligne la 20 transaction n'est reçu .d'un terminal (dit « précédent terminal ») avec lequel Fa carte à puce 20 coopère, la carte à puce 20 décrémente un compteur CT1 associé audit précédent terminal (par exemple Tl) ou décrémente un compteur CT2 associe à une entité tierce (par exemple l'entité 12) utilisant ledit précédent terminai. 25 Ainsi, à chaque fois que la carte -à puce 20 détecte, lors du traitement d'une transaction avec le terminal Ti, un refus de la part du terminal de poursuivre en ligne la transaction, ladite carte incrémente le compteur CT1 associé au terminal Ti = CT1 +1) ou incrémente le compteur CT2 de l'entité tierce 12 associée (L12 - C.12 e 1). Inversement, à chaque fois que la carte à puce 20 ne détecte, lors du traitement d'une 30 transaction avec le terminal Ti, aucun refus de la part du terminal à poursuivre en ligne la transaction, ladite carte décrémente le compteur el 1 associé au terminal Ti (CT1 CT1 - 1) ou décrémente le compteur CT2 associé à l'entité tierce 12 correspondante (CT2 CT2 - 1). Dans un exemple particulier, la decrémentation se fait uniquement si une demande. ARQC de traitement en ligne a été envoyée par- la carte à puce 20 lors de la 35 transaction en cours. 21 En outre, la carte à puce 20 peut prendre en compte l'état du compteur en associé au terminal Ti ou l'état du compteur CT2 associé à l'entité tierce 12 utilisant le terminal Ti pour réaliser l'étape de détermination en 542 (figure 5) ou en 554 (figure 7), Selon un exemple particulier représenté en figure 9, la carte à puce 20 peut 5 déterminer en 512 (figure 5) ou en 554 (figure 7) si le compteur cri. ou C-1-2 atteint une valeur seuil prédéterminée CTmax correspondante et prendre en compte le résultat de cette comparaison pour déterminer s'il y a un risque de refus suspect de traiter en ligne la transaction TR1 en cours. Dans un exemple particulier, la carte à puce 20 détermine qu'un tel risque existe (542, 554) uniquement si l'identifiant IDT1 ou IDE1 10 précédemment reçu (540) est indus dans la liste contenue dans sa mémoire 28. Selon un exemple particulier, lors des étapes 542 ou 551 de détermination, la carte à puce prend en compte le compteur CT2 associé à l'entité tierce 12 mais pas le compteur CT1 associé au terminal Tl, dans la mesure où l'identifiant d'une entité tierce telle qu'un marchand par exemple est moins susceptble de varier due l'identifiant (fun terminal 15 d'une telle entité tierce. En outre, une même entité tierce peut disposer d'une pluralité de. terminaux pour réaliser des transactions. L'invention permet ainsi avantageusement de limiter les risques d'erreur de la parte de la carte 20 de sorte que seules les transactions réellement à risque déclenchent un comportement sécuritaire particulier de la carte à puce 20, afin selon le cas de forcer une 20 poursuite en ligne de la transaction en cours ou de bloquer la transaction en cours. 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 C;l1 REVENDICATIONS1. Procédé de traitement mis en oeuvre par un dispositif électronique (20), ledit procédé comprenant les étapes suivantes réception (540), en provenance d'un terminal (Ti) avec lequel le dispositif e.lectronique coopère pour traiter une transaction (TR1) en cours, d'un identifiant (IDT) du terminal ou d'un identifiant (IDE) d'une entité tierce (1.2) utilisant ledit terminal pour réaliser la transaction en cours ; détermination (S12 ; 554), à partir de l'identifiant du terminal ou de l'identifiant 10 de l'entité tierce, de si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal (Ti) ; si un refus suspect d'un traitement en Ugne de la transaction en cours n'est pas susceptible d'être reçu en provenance du terminal, envoi (544 ; 556) d'une première commande (CMD1 ; CMD3) nu terminal ; et si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal, exécution d'une étape (546 ; 558) de sécurisation comprenant : o envoi (546) au terminal d'une deuxième commande (CMD2)' distincte de la. première commande (CMD1), pour forcer un traitement en ligne de la 20 transaction en cours par le terminal ; ou blocage (558) de la transaction en cours pour interdire une validation par le terminal de la transaction en cours sans un traitement en ligne préalable. 25 2. Procédé selon la revendication 1, dans lequel la transaction en cours est une transaction de paiement conforme à la norme EMV. 1 Procédé selon la revendication 2, dans lequel la première commande (CMD1) est un message ARQC conforme à la norme ElIV pour demander un traitement en ligne de la 30 transaction en cours. 4. Procédé selon la revendication 3, dans lequel la deuxième commande (CMD2) est un message AAR conforme à la norme EMV.. 35 5. Procédé selon la revendication 3, dans lequel la deuxième commande CMD2) est un message APDU comprenant un champ indiquant ie type de cryptogramme dudit message, ledit champ comprenant une valeur prédéterminée spécifiant: que la deuxième 23 commande interdit au terminal de valider la transaction en cours sans un traitement en ligne avec un serveur distant avant achèvement de ladite transaction en cours. 6. Procédé selon la revendication 2, dans lequel la première commande (CMD3) est un message AAC conforme à la norme EMV pour refuser la transaction en cours. 7. Procédé seHon la revendication 6, dans lequel ledit blocage de la transaction en cours est réalisé en envoyant (S56a) au terminal, en réponse à un message de type ARC conforme à la norme EMV indiquant qu'un traitement en ligne n'est pas possible, un 10 message d'erreur (CMD4) bloquant la transaction. 8. Procédé se on la revendication 6, dans lequel ledit blocage de la transaction est réalisé par non réponse (556b) au terminal suite à la réception (552.) d'un message de type ARC conforme à la norme EMV àdiquant qu'un traitement en ligne n'est pas 15 possible. Y. Procédé selon l'une quelconque des revendications 1 à 8, dans lequel le procédé comprend, préalablement à l'étape (542 ; 554) de détermination, une étape (570) d'obtention d'une liste (LT) Ci ,:71 LI moins un identifiant (IDT ; IDE), 20 l'étape de détermination comprenant une vérification de si l'identifiant (IDT) du terminal ou l'identifiant (IDE) de l'entité tierce est inclus dans ladite liste, le dispositif électronique déterminant si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal à partir d'un résultat délivré lors de ladite vérification. 25 10. Procédé selon la revendication 9, dans lequel l'étape d'obtention (570) de la liste comprend, pour au moins une précédente transaction (TR2) traitée par le dispositif électronique avec un précédent terminal préalablement à la transaction (TR) en cours; une mise à jour 572) de la liste au cours de laquelle : 30 sur réception d'un message de refus du précédent terminal de traiter en ligne la transaction, le dispositif électronique inclut dans la liste au moins l'un parmi un identifiant (MT) du précédent terminai et un identifiant (IDE) d'une entité tierce associée audit précédent terminal. 35 11. Procédé selon la revendication 10, comprenant une étape (580) de mise à jour de compteur au cours de laquelle : 24 - pour chaque précédente transaction (TR2) pendant laquelle un message de refus de traiter en ligne ladite précédente transaction est reçu d'un précédent terminal, le dispositif électronique incrémente un compteur (CT1 ; L I 2) associé audit précédent terminal ou à une entité tierce associée audit précédent terminai ; et - pour chaque précédente transaction pendant laquelle aucun message de refus de traiter en ligne la transaction n'est reçu d'un précédent terminal, le dispositif -Ltronique décrémente un compteur (Cri ; CT2) associé audit précédent leuninal Ou à une entité tierce associée audit précédent terminal ; ladite étape de détermination étant réalisée à partir de l'état du compteur associé au 10 terminal ou à l'entité tierce utilisant ledit terminal pour réaliser la transaction en cours. 12. Programme d'ordinateur (PG1) comportant des instruction, pour l'exécution des étapes d'un procédé de traitement selon l'une quelconque des revendications 1 à 11 15 lorsque ledit programme est exécuté par un ordinateur. 13. Dispositif électronique (20) comprenant : un module de réception (MD2), en provenance d'un terminal avec lequel le dispositif électronique coopère pour traiter une transaction en cours, d'un 20 identifiant du terminal ou d'un identifiant d'une entité tierce utilisant ledit terminal pour réaliser la transaction en cours ; un module de détermination (MD1), à partir de l'identifiant du terminal ou de l'identifiant de l'entité tierce, de si un refus suspect d'un traitement en ligne de la. transaction est susceptible d'être reçu en provenance du terminal ; 25 un module de traitement (MD6) configure : 0 si un relus suspect d'un traitement en ligne de la transaction n'est pas susceptible d'être reçu en provenance du terminal, pour envoyer une première commande au terminal ; et 0 si un refus suspect d'un traitement en ligne de la transaction est 30 susceptibie d'être reçu en provenance du terminal, pour exécuter une étape de sécurisation, le module de traitement étant configure, au cours de l'étape de sécurisation, pour envoyer au terminal une deuxième commande' distincte de la première commande, de sorte à forcer un traitement en ligne de la transacton par le 35 terminai ou pour bloquer la transaction de sorte à interdire une validation par le terminal de la transaction sans un traitement en ligne préalable. 25 14. Dispositif selon la revendication 13, comprenant en outre une mémoire configurée pour contenir une liste (LT) d'au moins un identifiant, ledit module de détermination étant configuré pour comparer l'identifiant du terminal ou l'identifiant de l'entité tierce audit au moins un identifiant de la liste pour déterminer si un refus suspect d'un traitement en ligne de la transaction en cours est susceptible d'être reçu en provenance du terminal. 15. Dispositif selon la revendication 13 ou 14, dans lequel le dispositif électronique est une cartc à puce. 10