FR 2958770 A1 20111014 FR 1052808 A 20100413 Arrière-plan de l'invention La présente invention se situe dans le domaine général des dispositifs aptes à effectuer une transaction en mode avec ou sans code, tels que les cartes à microcircuit autrement connues sous le nom de cartes à puce (notamment les cartes à microcircuits conformes à la norme ISO7816). L'invention s'applique plus particulièrement, mais de manière non exclusive, aux cartes à microcircuit fonctionnant conformément au protocole EMV (« Europay Mastercard Visa »), aussi connu sous l'expression « Chip and PIN » en anglais. De manière générale, une carte à microcircuit 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 des transactions de paiement ou d'authentification du porteur, par exemple. Les cartes à microcircuit pour applications bancaires (carte de crédit, carte de débit etc.), par exemple, sont aptes à communiquer avec des terminaux de paiement. L'EMV est le protocole standardisé utilisé majoritairement dans le monde pour sécuriser notamment les transactions de paiement effectuées par des cartes à microcircuit. Le protocole EMV a été conçu pour diminuer les risques de fraudes lors d'une transaction de paiement en permettant l'authentification de la carte 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 (appelé communément code PIN ou code personnel) par le porteur de la carte. 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 un terminal, avec l'entité émettrice correspondante (la banque à l'origine de la carte, par exemple) afin de vérifier que la transaction en cours est légitime. En revanche, si la carte EMV fonctionne en mode hors ligne, celle-ci applique des critères de vérification préenregistrés pour décider si la transaction doit être autorisée ou refusée. 1 La figure 1 représente un exemple d'une transaction de paiement conforme au protocole EMV, à l'aide d'une carte à puce susceptible de fonctionner en mode avec ou sans vérification de code. Une carte à puce EMV de paiement contient généralement différentes applications bancaires permettant par exemple de fonctionner en mode « carte de crédit » ou « carte de débit » dans un point de vente ou encore d'interagir avec un guichet automatique bancaire. On suppose ici que le porteur de la carte insert la carte de paiement dans un terminal de paiement compatible. Le protocole EMV s'articule alors généralement en trois phases. La première phase ([100) du protocole EMV consiste à authentifier la carte à puce utilisée. Pour se faire, le terminal envoie à la carte de paiement une commande « SELECT APPLICATION » avec en paramètre l'identifiant d'application (AID pour « Application Identifier » en anglais) « 1PAY.SYS.DDF01 » (E101). Cette commande permet de demander à la carte les applications que cette dernière est capable de mettre en oeuvre. En réponse, la carte envoie une liste des différentes applications qu'elle peut mettre en oeuvre (E102). Le porteur peut alors sélectionner via le terminal de paiement le mode de transaction souhaité, déclenchant ainsi l'envoi vers la carte d'une commande « SELECT APPLICATION » avec en paramètre l'identifiant AID de l'application sélectionnée (E104). Le terminal envoie en outre une commande « GET PROCESSING OPTIONS » à la carte afin d'initier le début de la transaction (E104). Le terminal reçoit ensuite de la carte de paiement un ensemble de données appelées parfois « records » (E106), ceux-ci comprenant notamment des informations propres à la carte (numéro de compte, date d'expiration de la carte...), une signature numérique pour authentifier la carte, des paramètres de contrôle à utiliser pour réaliser la transaction et des listes d'objets dites listes CDOL (pour « Card Data Object List », celles-ci étant décrites plus en détails ultérieurement). Une fois la phase d'authentification de carte achevée, le protocole EMV procède à la phase d'authentification du porteur de la carte (E107). Le terminal détermine le procédé d'authentification du porteur à appliquer en fonction des informations précédemment reçues dans les paramètres de contrôle. Cette phase permet en particulier au terminal de paiement de déterminer si la transaction est effectuée en mode avec vérification de code ou en mode sans vérification de code. Si, comme dans la majorité des cas, le mode avec vérification de code est sélectionné, le porteur est invité à saisir son code PIN à l'aide du clavier dont est généralement munit le terminal de paiement. Le terminal envoie ensuite à la carte de paiement une requête dite « VERIFY » de vérification du code saisi par le porteur (E108). La carte de paiement compare alors le code PIN saisi par le porteur avec le code PIN authentique inclus dans sa mémoire. Si le code PIN saisi est considéré comme valide, la carte de paiement envoie un message « OK » de type 0x9000 au terminal (E110). Dans le cas contraire, la carte envoie un message de refus de type Ox63Cx au terminal (E110), dans lequel x est le nombre de tentatives de code PIN restantes avant que la carte bloque la transaction en cours (et les transactions à venir). On ne s'intéresse ici qu'au cas d'une vérification de code PIN hors ligne, c'est-à-dire sans que le terminal fasse appel à l'émetteur de la carte dans le processus de vérification du code PIN. 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 la vérification d'un code PIN. Dans ce cas, la signature manuscrite du porteur peut éventuellement être requise pour authentifier ce dernier. Une fois la phase d'authentification du porteur achevée, le protocole initie la phase de vérification de la transaction (E113). Pour se faire, le terminal envoie à la carte EMV une commande dite APDU GENERATE AC ou GAC (E112). Cette commande comprend une description de la transaction en cours et est obtenue à partir de la concaténation de données spécifiées dans une liste CDOL précédemment transmise par la carte. Typiquement, la commande GAC contient des informations telles que le montant de la transaction en cours, la devise utilisée, le type de transaction, etc. La carte EMV réalise alors une étape d'analyse (E114) comprenant un certains nombre de vérifications de critères. Le nombre et la nature de ces vérifications ne sont pas normalisés par le protocole EMV. Toutefois, certaines vérifications particulières sont imposées pour les dispositifs EMV mettant en oeuvre l'option CCD (pour « Common Core Definitions » en anglais) du protocole EMV. A l'issue de cette étape d'analyse, la carte EMV envoie en réponse au terminal un cryptogramme (ou certificat cryptographique) comprenant un code d'authentification de message (ou MAC pour « Message Authentification Code » en anglais), ce dernier étant typiquement crypté à partir d'une clé cryptographique mémorisée dans la carte (E116). La réponse de la carte dépend notamment du paramétrage de la carte effectué par l'entité émettrice de ladite carte (appelée « émetteur » dans la suite de ce document). Dans l'exemple de la figure 1, la carte envoie un cryptogramme de type ARQC (« Autorisation Request Cryptogram ») indiquant que la carte souhaite poursuivre la transaction en ligne avec, par exemple, le serveur de l'émetteur de la carte EMV utilisée (mode en ligne). Le terminal transmet alors le cryptogramme ARQC à l'émetteur (E118) qui réalise à distance un certain nombre de vérifications afin de s'assurer que la transaction est valide ([120). Le terminal reçoit notamment en réponse un message crypté de type ARPC indiquant la décision de l'émetteur (E122). Le terminal transmet alors ce message à la carte EMV (E124). Si la carte accepte la transaction, celle-ci envoie en réponse un cryptogramme de type TC (transaction acceptée) au terminal (E126). Dans le cas contraire, la carte EMV envoie un cryptogramme de type AAC au terminal (refus de la transaction). On notera cependant qu'une poursuite de transaction en ligne n'est pas toujours nécessaire, ni même possible. Si, par exemple, la carte détecte qu'une poursuite de la transaction en ligne n'est pas nécessaire, elle envoie un cryptogramme de type TC ou AAC en réponse à la commande GAC du terminal. A noter également que, lorsque la carte EMV applique l'option CCD du protocole EMV, celle-ci ajoute un message de type CVR (« Card Verification Results ») dans sa réponse à la commande GAC lors de l'étape E116). Le message CVR permet notamment d'indiquer les raisons associées à la décision de la carte EMV suite à la commande GAC. Ce message peut en particulier être transmis par le terminal à l'émetteur de la carte EMV pour un usage interne. En définitive, les dispositifs permettant d'effectuer des transactions en mode avec ou sans vérification de code, tels que les cartes à microcircuit de type EMV par exemple, sont généralement sécurisés de manière à résister efficacement aux fraudes les plus classiques. Cependant, de nouveaux types d'attaques frauduleuses ont été récemment identifiés, ces attaques remettant en cause la fiabilité des transactions réalisées à l'aide de ce type de dispositif. Le document intitulé « Chip and PIN is Broken » de Ross Anderson et al. présente notamment l'émergence d'une nouvelle attaque de type MITM (pour « Man-In-The-Middle » en anglais) à l'encontre des protocoles de communication tels que le protocole EMV, par exemple. Ce type d'attaque consiste à placer un composant MITM entre le terminal et la carte EMV afin d'intercepter et de modifier les données échangées entre ces deux entités lors d'une transaction. Plus précisément, lorsque le terminal envoie une requête VERIFY au cours de l'étape E108, par exemple, cette requête peut être interceptée par un composant MITM qui envoie en réponse un message « OK » de type 0x9000 au terminal, et ce quelque soit le code entré par l'utilisateur. En conséquence, le terminal considère que la vérification du code PIN entré par le porteur est positive et initie alors la phase E113 de vérification de la transaction en envoyant une commande GAC à la carte EMV. La carte EMV, quant à elle, ne reçoit pas de requête VERIFY de la part du terminal lors de la phase E107. Ainsi, à la réception de la commande GAC provenant du terminal ([112), la carte EMV en déduit que le terminal ne prend pas en charge les vérifications de code PIN (ce qui est une issue plausible à la phase d'authentification du porteur) et considère donc que la transaction en cours s'effectue en mode sans vérification de code. Le protocole EMV ne permet ni au terminal ni à la carte EMV de détecter cette incohérence dans la suite de la transaction, ce qui constitue donc une brèche dans le protocole. Il existe donc aujourd'hui un besoin pour sécuriser les transactions en mode sans vérification de code, afin notamment d'empêcher des attaques de type MITM comme décrites ci-dessus. Objet et résumé de l'invention A cet effet, l'invention propose un procédé de contrôle d'un dispositif apte à fonctionner en mode avec ou sans vérification de code pour effectuer une transaction, le procédé comprenant : une étape d'authentification du dispositif, une étape optionnelle de vérification d'un code, et - une phase de poursuite de la transaction, le procédé étant caractérisé en ce qu'il comprend en outre une première étape de vérification pour vérifier si le dispositif fonctionne en mode sans vérification de code, et en ce que, dans l'affirmative, la phase de poursuite de la transaction comprend une étape de sécurisation comprenant : une sous-étape de détermination d'un historique des transactions précédentes du dispositif en mode sans vérification de code, une sous-étape étape de traitement sécurisé de la transaction en fonction au moins de l'historique, et - une sous-étape de mise à jour de l'historique. L'invention permet avantageusement de limiter les risques de fraudes associés aux transactions en mode sans vérification de code. Comme expliqué précédemment, ce type de transaction comporte certains risques, résultant notamment de l'émergence des attaques de type MITM. L'invention est par ailleurs avantageuse en ce qu'elle n'affecte que le fonctionnement du dispositif lui-même. Ceci permet d'éviter de modifier les dispositifs externes susceptibles de communiquer avec ledit dispositif pour effectuer la transaction. Les terminaux de type EMV notamment sont très répandus aujourd'hui et leur remplacement (ou modification) à grande échelle engendrerait des coûts très importants. Dans un mode de réalisation particulier, l'étape de détermination est réalisée après une étape de réception, lors de la phase de poursuite de la transaction, d'une demande d'un cryptogramme. Lorsque le dispositif fonctionne selon le protocole EMV, par exemple, le dispositif peut être configuré de telle manière qu'il réalise l'étape de détermination après réception d'une commande de type GAC. Par ailleurs, les transactions peuvent être des transactions de paiement, l'historique comprenant au moins un des paramètres suivants : - le nombre d'utilisations du dispositif en mode sans vérification de code, et - le montant cumulé de toutes les transactions sans vérification de code. Dans une variante, l'historique ne comprend qu'un seul de ces paramètres. D'autre part, lorsque les transactions considérées sont des transactions de paiement, la sous-étape de traitement sécurisé de la transaction peut également prendre en compte le montant individuel de la transaction en cours. Dans un mode de réalisation particulier, la sous-étape de traitement sécurisé comprend au moins une des actions suivantes : - l'envoi d'une requête de poursuite de la transaction en ligne, - l'envoi d'un message d'avertissement, et - le rejet de la transaction. Par ailleurs, lorsque les transactions sont des transactions de paiement, la sous-étape de traitement sécurisé peut en outre comprendre une sous-étape de vérification pour vérifier si le nombre d'utilisations du dispositif en mode sans vérification de code dépasse un nombre minimum prédéterminé et si le montant cumulé de toutes les transactions sans vérification de code dépasse un montant minimum prédéterminé, et dans l'affirmative, l'envoi d'une requête de poursuite de ladite transaction en ligne. Ce mode de réalisation offre un certain degré de souplesse dans la sécurisation des transactions en mode sans vérification de code. En effet, lorsque la transaction en cours est considérée comme risquée, celle-ci n'est pas nécessairement bloquée. L'émetteur du dispositif, par exemple, peut effectuer des vérifications complémentaires à distance afin de s'assurer que la transaction en cours est légitime. Dans un autre mode de réalisation, une commande est reçue en réponse à la requête de poursuite de la transaction en ligne, et la sous-étape de traitement sécurisé comprend le rejet de la transaction : - si la commande reçue comprend un paramètre indiquant le refus de la requête de poursuite de la transaction en ligne, - si le nombre d'utilisations du dispositif en mode sans vérification de code dépasse un nombre maximum prédéterminé, et - si le montant cumulé de toutes les transactions sans vérification de code dépasse un montant maximum prédéterminé. Ce mode de réalisation est avantageux car le porteur d'une carte de paiement, par exemple, peut être amené à effectuer plusieurs transactions de paiement de suite hors ligne, et ce dans le cadre d'un usage normal de la carte. Dans une variante de ce mode de réalisation, on détermine si la requête de poursuite en ligne a été acceptée en fonction de l'état du paramètre dans la commande reçue, le procédé comprenant en outre une étape préliminaire d'envoi d'une requête d'insertion dudit paramètre dans la commande à envoyer en réponse à la requête de poursuite en ligne. De plus, lorsque le résultat de la première étape de vérification est négatif, l'historique peut être réinitialisé. Selon une variante de réalisation, le dispositif est apte à effectuer une transaction en mode de communication avec contact ou en mode de communication sans contact, le mécanisme de sécurisation étant déterminé en fonction du mode de communication utilisé par le dispositif. Dans un mode particulier de réalisation, les différentes étapes du procédé de contrôle de l'invention 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 par un microprocesseur, 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écrit 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 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 lisible par un microprocesseur, ou plus généralement par un ordinateur, ce support d'informations 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électronique, ou 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 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é, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Corrélativement, l'invention vise un dispositif apte à fonctionner en mode avec ou sans vérification de code pour effectuer une transaction, le dispositif comportant : des moyens d'authentification dudit dispositif, des moyens de vérification d'un code, et - des moyens de poursuite de la transaction, le dispositif étant caractérisé en ce qu'il comprend des moyens de vérification aptes à vérifier si le dispositif fonctionne en mode sans vérification de code, et dans ce cas, à déclencher des moyens de sécurisation comprenant : des moyens de détermination d'un historique des transactions précédentes du dispositif en mode sans vérification de code, des moyens de traitement sécurisé de la transaction en fonction au moins de l'historique, et des moyens de mise à jour de l'historique. On notera que les différents modes de réalisation du procédé de contrôle de l'invention décrits ci-avant ainsi que les avantages résultant de chacun de ces modes s'appliquent de la même manière au dispositif de l'invention. 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 un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la figure 1 représente, sous forme d'organigramme, les principales étapes d'un protocole de communication connu de type EMV entre un terminal et une carte EMV ; la figure 2 représente une carte à microcircuit conforme à un mode particulier de réalisation de l'invention ; la figure 3 représente un exemple de dispositif externe apte à communiquer avec le dispositif de la figure 2 ; la figure 4 représente, sous forme d'organigramme, les principales étapes du procédé de contrôle de l'invention selon un mode particulier de réalisation ; la figure 5 représente, sous forme d'organigramme, les principales étapes du procédé de contrôle de l'invention selon une variante du mode de réalisation de la figure 4 ; et - la figure 6 représente une carte à microcircuit conforme à une variante du mode de réalisation de la figure 2. Description détaillée d'un mode de réalisation L'invention concerne un procédé de contrôle d'un dispositif apte à fonctionner avec ou sans vérification de code pour effectuer une transaction. L'invention s'applique tout particulièrement aux cartes (notamment les cartes à puce) fonctionnant conformément au standard EMV pour mettre en oeuvre une transaction. L'invention ne se limite cependant pas aux cartes mais concerne plus généralement tout dispositif apte à fonctionner en mode avec ou sans vérification de code pour effectuer une transaction. La figure 1 représente une carte à microcircuit 201 conforme à un mode de réalisation de l'invention. 10 Cette carte à microcircuit 201 comporte un microprocesseur 202, apte à accéder d'une part à une mémoire vive 204 au moyen d'un bus 206, et d'autre part à une mémoire non volatile 208 (par exemple du type EEPROM) au moyen d'un bus 210. La carte à microcircuit 201, ou plus précisément le microprocesseur 202, peut échanger des données avec un dispositif externe dit terminal 301 représenté en figure 3 au moyen d'une interface de communication 212 constituée de contacts. Deux lignes de contact particulières 214 sont représentées en figure 1, celles-ci permettant les échanges de données entre le terminal 301 et le microprocesseur 202. La mémoire non volatile 208 de la carte à microcircuit 201 constitue un support d'informations conforme à l'invention. Elle comporte un programme d'ordinateur PG1 conforme à l'invention, ce programme comportant des instructions aptes à mettre en oeuvre un procédé de contrôle conforme à l'invention dont les principales étapes [402 à E428 sont représentées sous forme d'organigramme à la figure 4. En référence à la figure 3, le terminal 301 présente, dans cet exemple, l'architecture matérielle d'un ordinateur. Il comporte notamment un processeur 302, une mémoire vive de type RAM 304, une mémoire morte de type ROM 306, et un connecteur 308 compatible avec les contacts 212 de la carte à microcircuit 201. Le terminal 301 comporte en outre, dans cet exemple, des moyens d'interaction homme/machine 310 (tels qu'un clavier et un écran d'affichage, par exemple). Nous supposerons, dans l'exemple décrit ici, que la carte 201 et le terminal 301 fonctionnent conformément au protocole EMV. On comprendra cependant que l'invention ne se limite en aucun cas au protocole EMV et peut en fait s'appliquer à un protocole quelconque. Un mode particulier de mise en oeuvre de l'invention est à présent décrit en référence aux figures 2, 3 et 4. Nous supposerons dans cet exemple que la carte 201 est une carte de paiement qui est insérée dans le terminal 301 afin d'effectuer une transaction de paiement. Comme indiqué plus en détails ultérieurement, l'invention ne se limite cependant pas aux transactions de paiement. La carte 201 et le terminal 301 sont alors capables de communiquer ensemble via l'interface de contact 212 de la carte et le connecteur 308 du terminal. On supposera en outre que les étapes d'authentification de la carte 201 et d'authentification du porteur de cette dernière ont été exécutées conformément aux étapes E101 et E107 représentées en figure 1. Lors d'une étape E402, la carte 201 reçoit une première commande GAC, notée GAC1, provenant du terminal 301. La réception de cette commande permet d'initier une phase de poursuite de la transaction, cette phase correspondant à une étape de vérification de la transaction. Conformément au protocole EMV, la commande GAC1 générée par le terminal 301 comprend un ensemble de données descriptives de la transaction en cours. Plus précisément, cette commande résulte de la concaténation de données sélectionnées en fonction d'une liste d'objet CDOL envoyée par la carte 201 au terminal 301 lors de l'étape préalable d'authentification de la carte. Selon le protocole EMV, l'envoi de la commande GAC1 permet au terminal 301 de recevoir en retour un cryptogramme indiquant la réponse de la carte 201 quant à la suite à donner à la transaction. Une fois la commande GAC1 reçue (étape E402), la carte 201 procède à une première étape de vérification pour vérifier si le terminal fonctionne en mode sans vérification de code (étape E404). Pour cela, le microprocesseur 202 détermine si une commande VERIFY de vérification d'un code saisi par le porteur de la carte 201 a été reçue lors de la précédente étape d'authentification du porteur. Si au moins une commande de ce type provenant du terminal 301 a été reçue par la carte 201, cela signifie que le porteur a saisi au moins un code PIN lors de l'étape d'authentification du porteur à l'aide des moyens d'interaction homme/machine 310. En conséquence, la carte 201 en déduit que le terminal (et donc la carte 201) est en mode avec vérification de code. Dans ce cas, la transaction peut se poursuivre de manière conventionnelle. En effet, la transaction en cours n'est pas concernée par les risques de fraudes associés aux transactions en mode sans vérification de code. On supposera donc ici que la carte 201 détermine au cours de l'étape E404 qu'aucune commande VERIFY en provenance du terminal 301 n'a été reçue au préalable au cours de la transaction. En conséquence, la carte 201 considère que le terminal 301 (et donc la carte elle-même) fonctionne en mode sans vérification de code. Dans ce cas, la carte 201 initie une étape E405 dite de sécurisation de la transaction. Dans cet exemple, le microprocesseur 202 consulte la mémoire non-volatile 208 afin de déterminer l'historique (H1) des transactions précédentes de la carte 201 en mode sans vérification de code (E406). Dans le cas décrit ici, l'historique Hi inclus dans la mémoire non-volatile 208 comprend un compteur CT indiquant le nombre de transactions en mode sans vérification de code que la carte 201 a précédemment effectuées. L'historique H1 comprend également dans cet exemple un compteur CM indiquant le montant cumulé des transactions en mode sans vérification de code que la carte 201 a précédemment effectuées. Une fois les valeurs des compteurs CT et CM déterminées, le microprocesseur 202 réalise une sous-étape de mise à jour de l'historique H1 consistant à incrémenter le compteur CT de 1 et à incrémenter le compteur CM du montant de la transaction en cours (ce montant étant précédemment communiqué par le terminal 301 dans sa commande GAC1) (étape E406). La carte 201 initie alors une sous-étape de traitement sécurisé de la transaction en cours en fonction au moins de l'historique H1 inclus dans la mémoire non-volatile 208. Plus précisément, le microprocesseur 202 réalise une sous-étape de vérification (E408) pour vérifier si la condition suivante (notée A) est satisfaite : - CT > CTmin et - CM > CMmin où CTmin correspond à un premier nombre limite prédéterminé de transactions en mode sans vérification de code et CMmin correspond à un premier montant total limite prédéterminé de transactions en mode sans vérification de code. CTmin et CMmin sont par exemple définis au préalable par l'émetteur de la carte 201 et stockés dans la mémoire non volatile 208. Aussi, pour effectuer la sous-étape de vérification E408, le processeur 202 consulte la mémoire non volatile 208 afin de déterminer les valeurs de CTmin et CMmin. Si la condition A n'est pas respectée, on considère que les risques associés à la transaction en cours sont acceptables. C'est pourquoi, la carte 201 génère puis envoie un cryptogramme de type TC afin d'indiquer au terminal 301 qu'elle accepte la transaction (étape E410). Dans ce cas, le terminal transmet le cryptogramme TC à l'émetteur de la carte, celui-ci correspondant typiquement à un serveur distant de la banque émettrice de la carte 201. Si en revanche la carte 201 détermine que la condition A est satisfaite, la carte 201 génère puis envoie un cryptogramme de type ARCQ au terminal 301 (étape E412). La carte 201 reçoit ensuite une deuxième commande GAC notée GAC2 provenant du terminal 301 (étape E414), cette commande indiquant si la poursuite en ligne de la transaction en cours est possible. Comme indiqué précédemment, le terminal n'est pas nécessairement en mesure de communiquer avec l'émetteur de la carte 201 afin de poursuivre la transaction en ligne. Une transaction en ligne est par exemple impossible lorsque le terminal 301 n'est pas en mesure de se connecter au serveur de l'émetteur. La carte 201 interprète alors la commande GAC2 afin de déterminer si la transaction peut se poursuivre en ligne (étape E416). Si la commande GAC2 reçue par la carte 201 indique que la requête de poursuite de transaction en ligne est acceptée, la carte 201 envoie un cryptogramme TC au terminal 301 afin d'indiquer au terminal qu'elle accepte la transaction (étape E418). Si, en revanche, la commande GAC2 indique à la carte 201 que la requête de poursuite de la transaction en ligne est refusée, la carte 201 poursuit le traitement sécurisé de la transaction en cours. Dans cet exemple, la carte 201 vérifie alors si la condition suivante (notée B) est satisfaite : - CT > CTmax, et - CM > CMmax où CTmax correspond à un deuxième nombre limite prédéterminé de transactions en mode sans vérification de code et CMmax correspond à un deuxième montant total limite prédéterminé de transactions en mode sans vérification de code. De plus, CTmax et CMmax sont tels que : - CTmin Aussi, pour effectuer la sous-étape E416, le processeur 202 consulte la mémoire non volatile 208 afin de déterminer les valeurs de CTmax et CMmax. Si la carte 201 détermine que la condition B n'est pas respectée, on considère que les risques associés à la transaction en cours sont acceptables. En conséquence, la carte 201 envoie un cryptogramme TC au terminal 301 afin d'indiquer au terminal qu'elle accepte la transaction (étape 422). Si en revanche la carte 201 détermine que la condition B est satisfaite, elle envoie un cryptogramme AAC au terminal 301 (étape E424). Ce cryptogramme indique au terminal 301 que la carte 201 refuse la transaction en cours. On considère en effet que les risques associés à la transaction sont trop importants. Comme la transaction est refusée, la carte 201 remet également à jour le compteur CM mémorisé dans l'historique H1 de la mémoire non- volatile 208. Plus précisément, la carte 201 soustrait au compteur CM le montant de la transaction en cours (étape E426) afin de ne pas prendre en compte le montant de cette transaction lors des transactions futures. La carte 201 peut également être configurée pour mettre à jour le compteur CT lors de l'étape E426 afin de ne pas prendre non plus en compte le fait qu'une tentative de transaction en mode sans vérification de code ait eu lieu. Dans ce cas, la carte 201 décrémente également de 1 le compteur CT à l'étape E426. L'invention permet avantageusement de limiter les risques de fraudes lorsque la carte considère que la transaction en cours s'effectue en mode sans vérification de code. Comme expliqué précédemment, ce type de transaction comporte certains risques, résultant notamment de l'émergence des attaques de type MITM. Le mode de réalisation ci-dessus permet d'offrir un certain degré de souplesse dans la sécurisation des transactions en mode sans vérification de code. En effet, lorsque la condition A est satisfaite, la carte 201 ne refuse pas nécessairement la transaction. La décision de la carte 201 dépend de la possibilité (ou non) de poursuivre la transaction en ligne avec l'émetteur de la carte, ou éventuellement du résultat de l'étape E416. Ce mode est avantageux car le porteur d'une carte de paiement peut être amené à effectuer plusieurs transactions de paiement de suite hors ligne dans le cadre d'un usage normal de la carte 201. La poursuite de la transaction en ligne (suite à l'étape E418) permet, par exemple, à l'émetteur de la carte d'effectuer des vérifications supplémentaires. L'émetteur peut par exemple effectuer des vérifications financières ou anti-fraude (vérifier si la carte est enregistrée comme volée, si les fonds du porteur sont suffisants au vu du montant de la transaction...). L'invention est par ailleurs avantageuse en ce qu'elle permet de sécuriser les transactions en mode sans vérification de code, et ce sans modifier le fonctionnement normal du terminal 301. En effet, l'invention propose de ne modifier que le comportement de la carte 201 en y intégrant un programme conforme à l'invention. Ceci permet avantageusement de ne pas modifier les terminaux de paiement de type EMV, ceux-ci étant très répandus aujourd'hui. Le remplacement du parc des terminaux EMV engendrerait en effet des coûts très importants. L'exemple de la figure 4 ne représente cependant qu'une mode de réalisation possible de l'invention. On comprendra en effet que l'invention peut couvrir divers variantes de réalisation. L'émetteur de la carte 201, par exemple, peut avantageusement pré-paramétrer la carte 201, et plus précisément le programme PG1 inclus dans la mémoire non-volatile 208, afin de mettre en oeuvre une gestion des risques de fraudes adaptée aux circonstances de la transaction considérée. Il est par exemple possible d'adapter la valeur de CTmin, CTmax, CMmin et/ou CMmax en fonction notamment de la date et/ou du lieu de la transaction ou encore en fonction d'un profile de risque préétablit par l'émetteur concernant le porteur de la carte. Dans une variante, la carte 201 peut être configurée pour que, dès que la condition A est satisfaite, la carte envoie au terminal 301 un cryptogramme AAC de refus de la transaction. Cette variante offre moins de souplesse que le mode de réalisation de la figure 4 mais permet en revanche d'augmenter le niveau de sécurisation des transactions que la carte effectue en mode sans vérification de code. Dans une autre variante de réalisation, lorsque la carte 201 a déterminé à l'étape E404 que le terminal fonctionne en mode avec vérification de code, la carte 201 procède à une étape de réinitialisation des compteurs CT et CM (étape 428). En d'autres termes, la carte 201 remet les compteurs CT et CM à zéro. Cette réinitialisation permet avantageusement à la carte 201 de compter toutes les transactions effectuées avec succès en mode sans vérification de code, que celles-ci se déroulent en ligne ou hors ligne. De manière alternative, la carte 201 peut réaliser cette étape de réinitialisation des compteurs dès qu'une commande VERIFY est reçu lors de la phase d'authentification du porteur. Par ailleurs, le programme PG1 peut configurer la carte 201 afin que cette dernière vérifie des conditions A et/ou B différentes de celles décrites précédemment. Par exemple, la condition A peut se limiter à CT > CTmin ou encore se limiter à CM > CMmin. De même, la condition B peut se limiter à CT > CTmax ou à CM > à CMmax. Dans une autre variante, la carte 201 peut être configurée pour que, lors de l'étape E408, celle-ci prenne en compte des éléments supplémentaires (en plus de l'historique H1). La condition A peut, par exemple, inclure : M > Mmin où M correspond au montant individuel de la transaction en cours et Mmin correspond à un premier montant limite pour une transaction en mode sans vérification de code. De plus, la condition B peut inclure : - M>Mmax où M correspond au montant individuel de la transaction en cours et Mmax correspond à un deuxième montant limite pour une transaction en mode sans vérification de code. Si Mmin et Mmax sont pris en compte respectivement dans les conditions A et B, alors : Mmin Aussi, pour vérifier si M est supérieur à Mmin et/ou si M est supérieur à Mmax, le processeur 202 consulte la mémoire non volatile 208 afin de déterminer Mmin et/ou Mmax. Dans une autre variante, la carte 201 peut vérifier lors de l'étape E406, par exemple, si les conditions A et B sont satisfaites. Dans ce cas, le résultat obtenu concernant la condition B peut être utilisé le cas échéant par la carte 201 lors de l'étape E416. De plus, lorsque la carte 201 met en oeuvre l'option CCD du protocole EMV, la carte peut avantageusement insérer un message CVR dans ses réponses cryptées aux commandes GAC1 et/ou GAC2. L'insertion des messages CVR permet de fournir au terminal 301 et/ou à l'émetteur de la carte 201 les raisons associées aux décisions de la carte 201 en réponse aux commandes GAC reçues. Un message CVR peut, par exemple, être transmis à la banque émettrice de la carte 201 afin d'être conserver comme informations d'audit. Plus précisément, lorsqu'une carte EMV met en oeuvre l'option CCD, on peut par exemple utiliser l'un quelconque des bits numérotés 1 à 4 dans l'octet N°3 du CVR afin d'indiquer un dépassement. Ces 4 bits du CVR sont en effet réservés pour l'usage personnel de l'émetteur. Le bit utilisé à cet effet peut, par exemple, être fixé à 1 lorsque la carte 201 souhaite indiquer un dépassement d'une ou de plusieurs valeurs limites prédéterminées, et fixé à zéro dans le cas contraire. Ainsi, la carte 201 peut avantageusement envoyer au terminal 301 un message d'avertissement de type CVR dans sa réponse TC lors de l'étape E418 afin d'indiquer à l'émetteur de la carte que seule la condition A est satisfaite. De cette manière, l'émetteur peut être avertit que les seuils prédéterminés CTmin et/ou CMmin sont dépassés, et éventuellement que CTmax et CMmax ne sont pas dépassés. De la même manière, la carte 201 peut insérer un message d'avertissement de type CVR dans son cryptogramme ARCQ envoyé à l'étape E412 au terminal, ce message indiquant que la condition A est satisfaite (autrement dit, que CT > CTmin et CM > CMmin dans cet exemple). De même, la carte 201 peut insérer un message d'avertissement de type CVR dans sa réponse cryptée AAC envoyée lors de l'étape E424 au terminal 301, ce message indiquant que les seuils prédéterminés CTmax et CMmax ont été dépassés (condition B satisfaite). Il est toutefois envisageable d'insérer des messages d'avertissement dans les réponses de la carte 201 aux commandes de type GAC, même lorsque la carte ne met pas en oeuvre l'option CCD. Par ailleurs, lorsque la carte 201 met en oeuvre l'option CCD du protocole EMV, la carte peut être configurée pour inclure deux listes d'objets (notées CDOL1 et CDOL2) dans les « records » qu'elle envoie au terminal 301 lors de la phase préalable d'authentification de la carte (étape E106). Les listes d'objets CDOL1 et CDOL2 correspondent aux données que le terminal 301 doit inclure dans les commandes GAC1 et GAC2, respectivement. La liste d'objet CDOL2, en particulier, peut contenir un objet indiquant que le terminal 301 doit inclure un message de type ARC (pour « Autorisation Response Code » en anglais) dans la commande GAC2 à envoyer à la carte 201. Ce message ARC est ainsi reçu par la carte 201 lors de l'étape 414 (si celle-ci se produit). La carte est alors capable, à partir du message ARC reçu, de déterminer lors de l'étape E416 si une poursuite de transaction en ligne est possible (ou non). D'autre part, dans les divers variantes de réalisation décrites en référence à la figure 4, c'est le microprocesseur 202 qui réalise les étapes du procédé de contrôle de l'invention, et ce en faisant appel notamment à la mémoire non-volatile 208 et à l'interface de communication 212. La figure 6 représente une carte à microcircuit 601 selon une variante de réalisation de la carte 201 représentée en figure 2. La carte à microcircuit 601 comporte un microprocesseur 602, une mémoire vive 604, une mémoire non-volatile 608, des bus 606 et 610 et une interface de communication 612 identiques à ceux inclus dans la carte 201 de la figure 2. L'architecture matérielle de la carte 601 diffère uniquement de celle de la carte 201 en ce que la carte 601 comprend en outre une antenne de communication en champ proche 618 reliée au microprocesseur 602. Le microprocesseur 602 et l'antenne de communication en champ proche 618 forment ainsi un circuit de communication en champ proche permettant l'établissement d'une communication sans contact avec un dispositif externe tel que le terminal 301, par exemple. Il est ainsi possible d'échanger des données entre la carte 601 et un dispositif externe conformément à la norme ISO 14 443, par exemple. L'antenne 618 est formée, par exemple, par une pluralité de spires électriquement conductrices, cette antenne délimitant une surface utile de réception d'un champ magnétique. Par surface utile, on entend la surface de l'antenne qui, traversée par un champ magnétique, produit un courant induit circulant dans l'antenne 618. La carte 601 est ainsi capable d'effectuer une transaction en établissant une communication avec un dispositif externe au moyen de l'interface de communication 612 (mode de communication avec contact), ou alternativement, au moyen de l'antenne de communication en champ proche 618 (mode de communication sans contact). Les transactions effectuées en mode de communication sans contact sont avantageuses en ce qu'elles permettent un gain de temps et de simplicité vis-à-vis des transactions en mode de communication avec contact. C'est pourquoi, on supposera ici que les transactions en mode de communication sans contact ne nécessitent pas la vérification d'un code lors de l'étape d'authentification du porteur. D'autre part, la mémoire non volatile 608 de la carte à microcircuit 601 constitue un support d'informations conforme à l'invention. Elle comporte un programme d'ordinateur PG2 conforme à l'invention, ce programme comportant des instructions apte à mettre en oeuvre un procédé de contrôle conforme à l'invention dont les principales étapes E502 à E516 sont représentées sous forme d'organigramme à la figure 5. Un deuxième mode de mise en oeuvre de l'invention est à présent décrit en référence aux figures 3, 5 et 6. Nous supposerons dans cet exemple que le terminal 301 est capable de communiquer avec la carte 601 aussi bien en mode de communication sans contact qu'en mode de communication avec contact. Nous supposerons en outre que les étapes d'authentification de la carte 601 et d'authentification du porteur de cette dernière ont été exécutées conformément aux étapes E101 et E107 représentées en figure 1. Au cours d'une étape E502, la carte 601 reçoit une commande de type GAC (notée GAC1) provenant du terminal 301. Comme dans l'étape E402, cette commande GAC1 invite la carte 601 à répondre par une réponse cryptée indiquant la manière dont la transaction doit se poursuivre. La carte 601 détermine alors si la transaction en cours s'effectue en mode de communication avec contact ou sans contact (E504). Si la transaction s'effectue en mode de communication avec contact, la carte 601 peut procéder à l'étape E404 précédemment décrite et poursuivre la transaction comme décrit en référence à la figure 4. Si, en revanche, la carte 601 détecte que la transaction s'effectue en mode de communication sans contact, celle-ci en déduit que la transaction est en mode sans vérification de code et initie alors une étape E505 de sécurisation de la transaction. Plus précisément, le microprocesseur 602 consulte la mémoire non-volatile 608 afin de déterminer l'historique (H2) des transactions précédentes de la carte 601 en mode sans vérification de code (E506). Dans le cas décrit ici, l'historique H2 inclus dans la mémoire non-volatile 608 comprend un compteur CT indiquant le nombre de transactions en mode sans vérification de code que la carte 601 a précédemment effectuées. L'historique H2 comprend également dans cet exemple un compteur CM indiquant le montant cumulé des transactions en mode sans vérification de code que la carte 601 a précédemment effectuées. Une fois les valeurs des compteurs CT et CM déterminées, le microprocesseur 602 réalise une sous-étape de mise à jour de l'historique H2 (sous-étape E506) consistant à incrémenter le compteur CT de 1 et à incrémenter le compteur CM du montant de la transaction en cours (ce montant étant précédemment communiqué par le terminal 301 dans sa commande GAC1). La carte 601 initie alors une sous-étape de traitement sécurisé de la transaction en cours en fonction au moins de l'historique H2 inclus dans la mémoire non-volatile 608. Plus précisément, le microprocesseur 602 vérifie si la condition suivante (notée B') est satisfaite (sous-étape E508) : - CT > CTmax' et - CM > CMmax' où CTmax' correspond à un nombre limite prédéterminé de 35 transactions en mode sans vérification de code et CMmax' correspond à un montant total limite prédéterminé de transactions en mode sans vérification de code. CTmax' et CMmax' sont par exemple définis au préalable par l'émetteur de la carte 201 et stockés dans la mémoire non volatile 208. Aussi, pour effectuer la sous-étape E508, le processeur 602 consulte la mémoire non volatile 608 afin de déterminer les valeurs de CTmax' et CMmax'. Dans un mode de réalisation particulier, CTmax=CTmax' et CMmax=CMmax'. Dans une variante, CTmax*CTmax' et/ou 10 CMmax*CMmax'. Si la condition B' n'est pas respectée, on considère que les risques associés à la transaction en cours sont acceptables. C'est pourquoi, la carte 601 génère puis envoie un cryptogramme de type TC afin d'indiquer au terminal 301 qu'elle accepte la transaction (sous-étape 15 E510). Dans ce cas, le terminal 301 transmet le cryptogramme TC à l'émetteur de la carte. Si, en revanche, la carte 601 détermine que la condition B' est satisfaite, la carte génère puis envoie un cryptogramme de type AAC au terminal 301 (sous-étape E512). Ce cryptogramme indique au terminal 20 301 que la carte 601 refuse la transaction en cours. En outre, la carte 601 remet à jour le compteur CM en lui soustrayant le montant de la transaction en cours (sous-étape E514). De même que pour l'étape E426, cette opération permet de ne pas prendre en compte dans le compteur CM le montant d'une transaction refusée 25 par la carte 601. La carte 601 peut en outre remettre à jour le compteur CT en décrémentant celui-ci de 1 afin de ne pas prendre en compte la transaction en cours qui a échoué. Le mode de réalisation de la figure 5 permet d'adapter le niveau 30 de sécurisation d'une transaction en fonction du mode de communication utilisé. En effet, les terminaux de paiement fonctionnant en mode de communication sans contact n'acceptent généralement pas les transactions en ligne. C'est pourquoi, dans ce mode de réalisation, la carte 601 ne génère pas de requête de poursuite de transaction en ligne. La 35 carte 601 est configurée pour refuser systématiquement une transaction lorsque la condition B' est satisfaite. On comprendra que les variantes décrites en référence au mode de réalisation de la figure 4, s'appliquent de la même manière au mode de la figure 5. En particulier, l'émetteur de la carte 601 pourra adapter la condition B' de la même manière que la condition B précédemment décrite. De plus, si la carte 601 met en oeuvre l'option CCD du protocole EMV, un message de type CVR pourra être inséré dans la réponse de la carte 601 à la commande GAC1 du terminal 301. De plus, les avantages énoncés concernant les variantes décrites en référence à la figure 4 s'appliquent de la même manière au mode de réalisation de la figure 5 (et à ses variantes). L'invention s'applique également à une carte à microcircuit comprenant une antenne de communication en champ proche mais dépourvue de contacts tels que ceux constituant l'interface de connexion 612, par exemple. Dans ce cas, le procédé de contrôle peut, par exemple, passer directement de l'étape E502 à l'étape E506. Par ailleurs, dans les divers variantes de réalisation décrites en référence à la figure 5, c'est le microprocesseur 602 qui réalise les étapes du procédé de contrôle de l'invention, et ce en faisant appel notamment à la mémoire non-volatile 608, à l'interface de communication 612 et à l'antenne de communication en champ proche 618. Les modes de réalisation décrits ci-avant s'appliquent aux cartes de paiement de type EMV. Toutefois, l'invention ne se limite pas au protocole EMV mais couvre également des dispositifs fonctionnant suivant d'autres protocoles. L'invention s'applique notamment aux cartes à microcircuit conformes à la norme ISO7816. L'invention couvre également des dispositifs de type EMV ne mettant pas en oeuvre l'option CCD. De manière plus générale, l'invention ne se limite pas aux transactions de paiement. L'invention s'applique de la même manière à d'autres types de transactions faisant intervenir un dispositif apte à fonctionner en mode avec ou sans vérification de code pour effectuer la transaction. L'invention s'applique, par exemple, à un dispositif apte à fonctionner en mode avec ou sans mode de vérification afin de mettre en oeuvre une transaction d'authentification du porteur. Dans ce cas, aucun montant de transaction n'est mis en jeu dans le procédé de contrôle de l'invention. Lorsqu'il est déterminé que le dispositif fonctionne en mode sans vérification de code, l'étape de sécurisation de la transaction peut par exemple consister : à déterminer le nombre de transactions d'authentification précédentes du dispositif en mode sans vérification de code, à réaliser un traitement sécurisé de la transaction en fonction au moins du nombre de transactions d'authentification ainsi déterminé, et à mettre à jour le nombre de transactions d'authentification ainsi déterminé, en l'incrémentant de 1 par exemple. D'autre part, l'invention ne s'applique pas exclusivement aux cartes à microcircuit. Le dispositif selon l'invention peut prendre la forme d'une clé USB, par exemple. Selon un mode de réalisation particulier, le dispositif de l'invention est un dispositif portatif (ou dispositif « de poche »). Par ailleurs, l'invention s'applique également au cas où le code optionnel lors de la phase d'authentification du porteur prend la forme d'une empreinte digitale. Par exemple, dans le mode de réalisation décrit en référence à la figure 4, la saisie optionnelle d'un code confidentiel par le porteur de la carte 201 peut être remplacée par la capture optionnelle de l'empreinte digitale du porteur. Dans ce cas, la carte 201 est apte à fonctionner en mode avec vérification de code ou en mode sans vérification de code, le code prenant ici la forme d'une empreinte digitale. Dans ce cas, le terminal 301 comprend des moyens de capture d'une empreinte digitale. De plus, la carte 201 est capable de vérifier l'authenticité du porteur en comparant une empreinte digitale capturée par le terminal 301 avec une empreinte préenregistrée dans sa mémoire non volatile 208. L'invention trouve par exemple des applications dans le domaine des transports ou des accès sécurisés. L'invention peut en effet permettre avantageusement l'authentification à intervalles réguliers d'un utilisateur, et ce de manière sécurisée. L'invention peut également s'appliquer à un porte-monnaie électronique non EMV qui nécessiterait la vérification sécurisée du porteur de la carte à intervalles réguliers.35 REVENDICATIONS1. Procédé de contrôle d'un dispositif (201) apte à fonctionner en mode avec ou sans vérification de code pour effectuer une transaction, ledit procédé comprenant : une étape d'authentification du dispositif, - une étape optionnelle de vérification d'un code, et une phase de poursuite de la transaction, le procédé étant caractérisé en ce qu'il comprend en outre une première étape de vérification pour vérifier si le dispositif fonctionne en mode sans vérification de code, et en ce que, dans l'affirmative, ladite phase de poursuite de la transaction comprend une étape de sécurisation comprenant : une sous-étape de détermination d'un historique (H1) des transactions précédentes du dispositif en mode sans vérification de code, une sous-étape étape de traitement sécurisé de ladite transaction en fonction au moins dudit historique, et une sous-étape de mise à jour de l'historique. 2. Procédé de contrôle selon la revendication 1, dans lequel l'étape de détermination est réalisée après une étape de réception, lors de ladite phase de poursuite de la transaction, d'une demande (GAC1) d'un cryptogramme. 3. Procédé de contrôle selon la revendication 1 ou 2, dans lequel lesdites transactions sont des transactions de paiement, ledit historique comprenant au moins un des paramètres suivants : - le nombre (CT) d'utilisations du dispositif en mode sans vérification de code, et - le montant cumulé (CM) de toutes les transactions sans vérification de code. 4. Procédé de contrôle selon l'une quelconque des revendications 1 à 3, dans lequel la sous-étape de traitement sécurisé comprend au moins une des actions suivantes : - l'envoi d'une requête de poursuite de ladite transaction en ligne, - l'envoi d'un message d'avertissement, et - le rejet de la transaction. 5. Procédé de contrôle selon la revendication 3, dans lequel la 10 sous-étape de traitement sécurisé comprend : - une sous-étape de vérification pour vérifier si le nombre d'utilisations du dispositif en mode sans vérification de code dépasse un nombre minimum prédéterminé (CTmin) et si le montant cumulé de toutes les transactions sans vérification de code dépasse un montant minimum 15 prédéterminé (CMmin), et dans l'affirmative, l'envoi d'une requête de poursuite de ladite transaction en ligne. 6. Procédé de contrôle selon la revendication 5, dans lequel une 20 commande est reçue en réponse à ladite requête de poursuite de la transaction en ligne, et dans lequel la sous-étape de traitement sécurisé comprend le rejet de la transaction : - si ladite commande reçue comprend un paramètre indiquant le refus de ladite requête de poursuite de la transaction en ligne, 25 - si le nombre d'utilisations du dispositif en mode sans vérification de code dépasse un nombre maximum prédéterminé (CTmax), et - si le montant cumulé de toutes les transactions sans vérification de code dépasse un montant maximum prédéterminé 30 (CMmax). 7. Procédé de contrôle selon l'une quelconque des revendications 1 à 6, dans lequel lorsque le résultat de la première étape de vérification est négatif, ledit historique est réinitialisé. 35 8. Procédé de contrôle selon l'une quelconque des revendications 1 à 7, dans lequel ledit dispositif est apte à effectuer une transaction en mode de communication avec contact ou en mode de communication sans contact, ledit mécanisme de sécurisation étant déterminé en fonction du mode de communication utilisé par le dispositif. 9. Procédé de contrôle selon la revendication 6, dans lequel on détermine si ladite requête de poursuite en ligne a été acceptée en fonction de l'état dudit paramètre dans ladite commande reçue, le procédé comprenant en outre une étape préliminaire d'envoi d'une requête d'insertion dudit paramètre dans ladite commande à envoyer en réponse à ladite requête de poursuite en ligne. 10. Programme d'ordinateur (PG1) comportant des instructions pour l'exécution des étapes du procédé de contrôle selon l'une quelconque des revendications 1 à 9 lorsque ledit programme est exécuté par un microprocesseur (202). 11. Support d'enregistrement (208) lisible par un microprocesseur (202) sur lequel est enregistré un programme d'ordinateur (PG1) comprenant des instructions pour l'exécution des étapes du procédé de contrôle selon l'une quelconque des revendications 1à9. 12. Dispositif (201) apte à fonctionner en mode avec ou sans vérification de code pour effectuer une transaction, ledit dispositif comportant : - des moyens (202) d'authentification dudit dispositif, - des moyens (202) de vérification d'un code, et - des moyens (202) de poursuite de la transaction, le dispositif étant caractérisé en ce qu'il comprend des moyens (202) de vérification aptes à vérifier si le dispositif fonctionne en mode sans vérification de code, et dans ce cas, à déclencher des moyens (202) de sécurisation comprenant : 5des moyens (202) de détermination d'un historique (H1) des transactions précédentes dudit dispositif en mode sans vérification de code, des moyens (202) de traitement sécurisé de ladite transaction en fonction au moins dudit historique, et des moyens (202) de mise à jour de l'historique.