Brevet FR3076026A1 — publié le 20190628

Arrière-plan de l'invention La présente invention se sftue dans le domaine général des dispositifs électroniques 10 et concerne plus particulièrement un dispositif électronique, tel qu'une carte à puce par exemple, configurée pour coopérer avec un terminal externe pour réaliser une transaction, dans le domaine bancaire par exemple. L'invention s'applique plus particulièrement, mais de manière non exclusive, aux cartes à puce (ou cartes à microcircuit), conformes par exemple à la norme 1507816. 15 L'invention vise notamment la sécurisation d'une carte à puce fonctionnant selon le protocole EMV (pour « Europay Mastercard Visa »).. De manière générale, une carte à puce est conçue pour communiquer avec un dispositif externe à cette carte, autrement appelé terminal ou lecteur. Ces cartes permettent d'effectuer divers types de transactions, telles que par exemple des 20 transactions de paiement, de prélèvement ou encore d'authentification du porteur. Les cartes à puce pour applications bancaires (carte de crédit, carte de débit etc.), par exemple, sont aptes à coopérer avec des terminaux de paiement ou des distributeurs automatiques de billets (DAB) pour réaliser divers opérations financières. EMV est le protocole standardisé utilisé aujourd'hui majoritairement dans le monde 25 pour sécuriser notamment les transactions de paiement effectuées par des cartes à puce. 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 30 éventuellement la saisie d'un code secret (appelé communément code PIN) par le porteur de la carte. Au cours d'une transaction, une carte bancaire obtient un certain nombre de données représentatives de cette transaction, comme par exemple la date de la transaction, la monnaie utilisée, le montant de la transaction ou encore les contrôles sécuritaires 35 effectués par la carte ainsi que es résultats obtenus. De façon connue, des données, dites données d'historisation, représentatives d'une. transaction peuvent être enregistrées dans une mémoire de la carte bancaire afin de conserver un historique des transactions réalisées. Les types de données d'historisation qu'une carte bancaire garde en mémoire à 2 chaque transaction sont définis par centaines normes (VISA ou MASTERCARD par exemple). Cependant, un problème se pose en- ce que les ressources en mémoire des dispositifs électroniques tels que les cartes à puce sont limitées. Aussi, lorsque la mémoire de l'historique est pleine, la carte bancaire écrase généralement le.s données d'historisation de la transaction la plus ancienne avec les nouvelles données d'historisation de la transaction courante. Il s'ag t d'un système d'enregistrement cyclique. Ce système permet d'utiliser la mémoire en conservant le plus longtemps possible les données d'historisation d'une transaction donnée. 10 Or, l'enregistrement cyclique présente l'inconvénient en ce que les données qui sont écrasées sont parfois toujours pertinentes : elles peuvent etre utiles pour la carte bancaire ou l'émetteur de la carte par exemple. Si des données d'histo;isation sont supprimées dans !a mémoire avant que la carte ait pu !es transmettre, lors d'une_ transaction par exemple, l'émetteur de la carte ne pourra pas les récupérer. Les données 15 d'historisation sont cependant très utiles notamment pour le suivi des transactions, la_ détection de fraudes, le suivi comportemental des utilisateurs etc. Dans certains cas, ces données d'historisation sont nécessaires à la carte bancaire pour réaliser de' contrôles sécuritaires internes, lors du traitement d'une transaction par exemple. Il existe donc aujourd'hui un besoin pour une solution permettant une meilleure 20 gestion de l'enregistrement de l'historique de transactions dans une carte à puce (carte bancaire, carte de paiement...), et plus généralement dans un dispositif électronique destiné à coopérer avec un terminal externe pour réaliser une quelconque transaction. Objet et résumé de l'invention 25 A cet effet, la présente invention concerne un procédé de traitement mis en oeuvre par un dispositif électronique apte à traiter des transactions, ledit procédé comprenant : réception de données de transaction en provenance d'un terminal avec lequel le dispositif électronique coopère pour traiter une transaction courante ; obtention' à partir des données de transaction reçues, de nouvelles données 30d'historisation représentatives de la transaction courante ; et enregistrement des nouvelles données d'historisation selon un premier format.dedonnées en tant que nouvelle entrée dans un premier fichier d'historisation ; dans lequel, préalablement audit enregistrement, le procédé comprend vérification que ledit enregistrement remplit au moins une condition prédéterminée indiquant que ledit enregistrement est critique vis-à-vis d'anciennes données d'historisation stockées en tant que précédente entrée dans le premier fichier d'historisation ; et 3 - dans l'affirmative, transfert des anciennes données d'historisation dans un deuxième fichier d'historisation selon un deuxième format de données, réduit en taille par rapport au premier frormal de données. La présente invention permet d'optimiser l'usage de la mémoire du dispositif électronique pour stocker des données d'historique propres à des transactions traitées par ledit dispositif. Comme déjà indiqué, les ressources en mémoire d'une carte à puce sont limitées. :Le dispositif électronique selon l'invention est capable de transférer si besoin certaines données d'historique jugées pertinentes, depuis un premier fichier d'historisation vers un deuxième fichier d'historisation, de sorte à réaliser une sauvegarde sous forme 10 compressée de données d'historisation. Selon un mode de réalisation particulier, le deuxième format de données est réduit en ce qu'il autorise l'enregistrement d'une quantité inférieure de données par rapport au premier format de données. Selon un mode de réalisation particulier, le premier format de données définit une 15 pluralité de types de données à enregistrer tandis que le deuxième format de données définit une sélection parmi ladite pluralité de types -de données excluant au moins l'un parm ladite pluralité de types de données. Selon un mode de réalisation particulier, ladite vérification comprend : - détermination que l'enregistrement des nouvelles données d'historisation selon le 20 premier format de données dans e premier fichier d'historisation conduit à un écrasement d'une précédente entrée, représentative d'une précédente transaction, déjà enregistrée dans le premier fichier d'historisation selon le premier format de données ; et détection que l'enregistrement est critique Si la précédente transaction, définie 25 par la précédente entrée clans le premier fichier d'historisation, remplit une première condition temporelle. Selon un mode de réalisation particulier, la première condition temporelle est remplie si un instant antérieur au cours duquel a été réalisée le précédente transaction selon ladite précédente entrée se trouve dans une période de temps, d'une durée prédéfinie, 30 terminant à un instant courant au cours duquel est réalisé ou a été réalisé la transaction courante. Selon un mode de réalisation particulier, ladite vérification comprend : - détermination, à partir des données de transaction reçues, de l'instant courant caractérisant la transaction courante ; et 35 - calcul d'un deuxième instant antérieur correspondant au début de la période de temps, à partir de l'instant courant et de la durée prédéfinie attribuée à ladite ériocie de temps, 4 le premier instant antérieur se trouvant dans la période de temps s'il est postérieur au deuxième instant antérieur. Selon un mode de réalisation particulier, le procédé de traitement comprend, préalablement audit enregistrement des nouvelles données d'historisation selon le premier format de données dans le deuxième fichier d'historisation - sélection, parmi des types de données d'historisation définis par le premier format de données, d'un sous-ensemble de types de: données d'historisation conformément à au moins une règle de sélection prédéfinle ; et - conversion des anciennes données d'historisation selon e deuxième format: de 10 données en vue (tète transférées dans le deuxième fichier d'historisation, dans laquelle seulement le ou les types de données d'historisation sélectionnés sont conservés dans les anciennes données d'historisation lors de ladite conversion. Selon un mode de réalisation particulier, préalablement à ladite sélection, le second fichier d'historisation comprend déjà au moins une entrée sauvegardée selon le deuxième format de données, ladite entrée sauvegardée étant représentative d'une précédente transaction antérieure à la transaction] courante. Lors de ladite sélection, le dispositif électronique sélectionne un premier type de données d'historisation prédéfini seulement si la plus récente entrée sauvegardée dans le second fichier d'historisation comportant le premier type de donnée d'historisation spécifie, pour ledit premier type de données 20 d'listorisation, une valeur différente de celle définie par ladite précédente entrée Selon un mode de réalisation particulier, lors de ladite vérification, le dispositif électronique détecte systématiquement que l'enregistrement n'est pas critique si ia transaction courante est une transaction sans contact. Selon un mode de réalisation particulier, si la transaction courante est une transaction 25 par contact avec le terminal, te dispositif électronique détecte systématiquement lors ladite vérification que l'enregistrement est critique si la condition suivante est remplie : détection que ledit enregistrement des nouvelles données d'historisation selon premier format de données dans le premier fichier d'historisation conduit le premier fichier d'historisation à contenir un nombre, supérieur ou égal à une valeur seuil prédéterminée, 30 d'entrées de transactions satisfaisant une deuxième condition temporelle. Selon un exemple particulier, la deuxième condition temporelle est identique à la première condition temporelle définie ci avant, Selon un mode de réalisation particulier, s'il est détecté lors de ladite vérification que ledit enregistrement n'est pas critique, le dispositif électronique ne transfert pas es 35 anciennes données d'historisation dans le deuxième fichier d'historisation selon le deuxième format de données préalablement audit enregistrement. Selon un mode de réalisation particulier, le dispositif électronique détecte lors de ladite vérification que ledit enregistrement est critique uniquement sur détection que la transaction courante est passée avec succès. Selon un mode de réalisation particulier, le procédé de traitement comprend, après 5 ledit transfert des anciennes données d'historisation selon le deuxième format de données. dans deuxième fichier d'historisation conversion des anciennes données d'historisation depuis le deuxième format de données dans un format modifié à partir du contenu d'une précédente entréa dans le deuxième fichier d'historisation ; et transmission des anciennes donnée d'historisation dans le format modifié de. données à un terminal. Dans un mode particulier de réalisation, les différentes étapes du procédé 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. .en oeuvre dans un dispositif électronique ou dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de traitement tel que défini dans ce document, Ce programme peut utiliser n'importe duel 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 (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é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 a-re 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. 6 L'invention concerne également un dispositif électronique configure pour mettre en oeuvre le procédé de traitement de l'invention tel .que défini ci-avant. Plus particulièrement, l'invention vise un dispositif électronique apte à traiter des transactions, comprenant : un module de réception configure pour recevoir des données de transaction en provenance d'un terminal avec lequel le dispositif électronique coopère pour traiter une transaction courante ; un module d'obtention configure pour obtenir, -à partir des données de transaction reçues, de nouvelles données d'historisation à enregistrer en tant que 10 nouvelle entrée dans le dispositif électronique, lesdites nouvelles données d'historisation étant représentatives de la transaction courante ; et un module d'enregistrement configure pour enregistrer les nouvelles données d'historisation selon un premier format de données dans un premier fichier d'historisation ; 15 le dispositif comprenant en outre : un module de vérification configure pour vérifier, préalablement à l'enregistrement par le module d'enregistrement des nouvelles données d'historisation selon le premier format de données dans le premier fichier d'historisation, que ledit enregistrement rempiit au moins une condition 20 prédéterminée indiquant que ledit enregistrement est critique vis-à-vis d'anciennes données d'historisation stockées en tant que précédente entrée dans le premier fichier d'historisation ; et un module de sauvegarde configure, si l'enregistrement est détecté comme étant critique par le module de vérification, pour transférer les anciennes données 25 d'historisation dans un deuxième fichier d'historisation selon un deuxième format de données, réduit en taille par rapport au premier format de données. Selon un exemple particulier, le dispositif électronique est une carte à puce, par exemp e de type EMV (carte de paiement au autre). On .notera quo .es différents modes de réalisation mentionnés ci-avant en relation 30 avec le procédé de traitement de l'invention ainsi que les avantages associés s'appliquent de façon analogue au d sposilif électronique de l'invention. Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant 35 matériel ou à un ensemble de composants matériels et logiciels, Un composant logiciei correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programme d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de 7 fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel peut être exécuté par un processeur de données d'une entité physique (terminal, carte à puce etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires; supports d'enregistement, bus de .communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). 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 ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de 10 logiciel, par exemple un circuit intégré. Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des 15 exemples de réalisation dépourvus de tout caractère, limitatif. Sur les figures: - la figure 1 représente schématiquement un environnement comprenant un dispositif électronique apte à coopérer avec un terminal, .selon un mode de réalisation particulier de l'invention ; les figures 2A et 213 représentent schématiquement des données d'historisation 20 conformes respectivement à un premier format de données et à un deuxième format de données, selon un mode de réalisation particulier de l'invention ; la figure 3 représente schématiquement des modules fonctionnels mis en oeuvre par un dispositif électronique, selon un mode de réalisation particulier de l'invention 25 les figures 4A et 43 représentent schématiquement des données d'historisation enregistrées respectivement dans un premier fichier d'historisation et dans un deuxième fichier d'historisation, 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é de 30 traitement, selon un mode de réalisation particulier de l'invention ; - la figure 6 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 ; - les figures 7A et 76 représentent schéreetiquement le traitement dans le temps de transactions par un dispositif électronique, selon un mode de réalisation 35 particulier de l'invention ; la figure 8 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 ; et 8 la figure 9 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. 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 terminal externe pour réaliser une transaction, dans le domaine bancaire par exemple. L'invention propose un procédé de traitement permettant la gestion du stockage d'un historique de transactions dans une carte à puce (de type EMV par exemple), et p US 10 généralement dans un dispositif électronique, afin d'optimiser l'utilisation des ressources en mémoire du dispositif électronique et de sorte à limiter ires risques que des données d'historique pertinentes soient perdues. A cette fin, l'invention prévoit l'enregistrement par un dispositif électronique de nouvelles données d'historisation (ou données d'historique), représentatives d'une. transaction courante, selon un premier format de données dans un 15 premier fichier d'historisation. En outre, si cet enregistrement risque de causer la perte d'anciennes données crhistorisation déjà présentes dans ce premier fichier d'historisation, l'invention prévoit le transfert de ces anciennes données d'historisation dans un second fichier d'nistorisation selon un deuxième format de données, réduit en taille par rapport au premier .forman afin de sauvegarder une version compressée de ces anciennes 20 données dans la mémoire du dispositif électronique. Divers conditions prédéfinies peuvent s'appliquer pour déterminer si un tel mécanisme de sauvegarde doit être déclenché par le dispositif électronique. En paniculier, selon différents mode de réalisation, le procédé de traitement de l'invention, mis en oeuvre par un dispositif électronique tel qu'une carte à puce par 25 exemple, comprend : réception de données de transaction en provenance d'un terminal ; obtention; à partir des données de transaction reçues, de nouvelles données d'historisation représentatives d'une transaction courante ; et enregistrement des nouvelles données d'historisation selon un premier format de données dans un premier fichier d'historisation. En outre, préalablement audit enregistrement, le procédé 30 comprend : vérification que ledit enregistrement remplit au moins une condition prédéterminée indiquant que ledit enregistrement est critique vis-à-vis d'anciennes données d'historisation déjà stockées dans le premier fichier d'historisation ; et, dans l'affirmative, transfert (ou sauvegarde) des anciennes données d'historisation dans un deuxième fichier d'historisation selon un deuxième format de données, compressé ou 35 réduit en tail e par rapport au premier format de données. L'invention porte également sur un dispositif électronique configuré pour mettre en oeuvre un procédé de traitement comme défini ci-dessus. 9 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 comprendra que l'invention ne se limite par exclusivement aux cartes à puce EMV mais s'applique plus généralement à tous dispositifs électroniques configurés pour mettre en oeuvre une transaction, y compris des 5 dispositifs autre que des caltes à puce et qui utilisent le standard EMV, et des dispositifs électroniques qui utilisent d'autres standards de transaction. On peut également 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 qu'une transaction de consultation. d'un compte bancaire sur un 10 terminal bancaire. Les divers modes de réalisation de l'invention sont ici décrits dans le cadre d'une carte de paiement destinée à réaliser des transactions bancaires. On comprend que d'autres types de transactions ou opérations sont envisageables dans le cadre de l'invention. L'invention peut s'appliquer par exemple au stockage de données d'historisation représentatives de transactions d'authentification. 15- Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mémes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ou analogues ne sont généralement pas à nouveau décrits par souci -de simplicité. La figure 1 représente schématiquement un environnement comportant un dlspositif 20i électronique 2 d'un utilisateur U13,1 et un terminal (ou lecteur) T d'un utilisateur UR2, Le dispositif éiectronique 2 est configuree pour coopérer avec le terminal T pour traiter une transaction TRI, dite transaction courante. Comme déjà indiqué, on suppose ici que le dispositif électronique 2 est une carte à puce EMV, telle qu'une carte de paiement par exemple. La carte bancaire 2 est par 25 exemple conforme à la norme 150 7816. Dans un exemple particulier, le porteur UR1 utilise sa carte bancaire pour réaliser un. paiement à l'aide du terminal T d'un point de vente (ou marchand) noté UR2. Le terminal T permet le cas échéant de faire l'interface entre la carte bancaire 2 et un serveur distant SV d'une entité tierce IS (par exemple un organisme bancaire émetteur -de 30 la carte à puce 2). Ce serveur distant SV intervient éventuellement pour réaliser des contrôles sécuritaires supplémentaires lors d'un traitement en ligne de la transaction courante TRI.. Il convient de noter que certains éléments généralement présents dans une carte à puce EMV ont été volontairement omis car ils ne surit pas nécessaires à la compréhension 35 de ta présente invention. A noter également que la carte à puce 2 représentée en figure 1 ne constitue qu'un exemple de réalisation, d'autres mises en oeuvre f:tant possibles dans le cadre de l'invention. L'homme du métier comprend en particulier que certains éléments de la carte à puce 2 ne sont décrits dans ce document que pour faciliter la 10 compréhension de l'invention, ces éléments n'étant pas nécessaires pour mettre en oeuvre l'invention. Plus précisément, la carte à puce 2 comprend dans cet exemple des contacts externes 1 configurés pour coopérer avec le lecteur T, on processeur 6, une mémoire volatile relnscriptible (de type RAM) 8 et une mémoire non volatile réinscriptible 10 de type Flash par exemple). La mémoire non-volatile 10 constitue dans cet exemple un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisib e par la carte à puce 2, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à 10 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 étapes de ce procédé sont décrites ultérieurement, dans des modes de réalisation particuliers de l'invention. Dans un exemple particulier, la carte à puce 20 est conforme à la norme 150 7816. 15 Dans ce cas, les contacts externes 4 présentent des caractéristiques conformes à cette norme. On comprend toutefois que d'autres modes de réalisation sont possibles sans l'utilisation de tels contacts externes. La carte à puce 2 peut par exemple être configurée pour coopérer avec le lecteur T en mode sans contact via une antenne RF (non représentée) intégrée dans la carte 2. 20 Toujours dans l'exemple considéré ici, la mémoire non volatile réinscriptible 10 est configurée pour stocker des données d'historisation (ou données d'historique) DH représentatives de transactions traitées par la carte à puce 2 au fil du temps. Pour ce faire, la mémoire 10 comprend deux fichiers d'historisation' à savoir un premier fichier d'historisation (ou fichier primaire d'historisation) LG1 configure pour enregistrer des 25 données d'historisation DH selon un premier format de données FT' et un deuxième fichier d'historisation (ou fichier secondaire d'historisation) L02 configure pour enregistrer des données d'historisation OH selon un deuxième format de données F12, distinct du premier format FT1. Comme expliqué par la suite, le deuxième format de données FT2 est réduit en taille (compressé) par rapport au premier format de données 1. Ainsi, le 30 deuxième format FT2 ne permet de stocker que certaines des données d'historisation définies par le premier format de données Selon un exemple de réalisation, les premier et deuxième fichiers d'historisation LG1, LG2 sont (ou correspondent à) des zones mémoires distinctes. Ces fichlers d'historisation LG1 et LG2 (appelés aussi « transaction Log file » en 35 anglais) sont décrits plus en détail ci-après en référence notamment aux figures 4A-4B. Les données d'historisation DH sont enregistrées sous formes d'entrées successives dans les premier et deuxième fichiers d'historisation LG1 et LG2, chaque entrée -étant représentative d'une transaction traitée par la carte à puce 2. Les données d'historisation DH sont stockées dans ces fichiers LG1 et LG2 seYin respectivement des formats de données dlfférents 1-11 et FT2 de sorte à pouvoir être ultérieurement consultées par la calte à puce 2 ou transmises vers un terminal externe, tel que le terminal T par exemple. Comme expliqué ci-après, le deuxième fichier d'historisation LG2 sert de fichier de sauvegarde pour des données d'historisation DH transférées, le cas échéant, depuis le premler fichier d'historisation LG1. Ce transfert de sauvegarde est déclenché par la carte à puce 2 lorsqu'elle détecte qu'un enregistrement imminent de nouvelles données d'historisation OH représentatives d'une transaction courante est critique, c'est-à-dire que cet enregistrement risque de causer ,a perte d'anciennes données d'historisation dans le 10 prerner fichier d'historisation LG1. Ce transfert constitue un mécanisme de sauvegarde au sens de l'invention. Comme représenté en figure 1, la mémoire non volatile 10 peut également stocker au moins une condition prédéfinie CD définissant si l'enregistrement de données d'historisation DH d'une transaction courante TR1 dans le premier fichier d'historisation 15 LG1 selon le premier format FT1 est critique ou non. La mémoire non volatile 10 peut aussi stocker au moins une règle précléfinie RL définissant le ou les types de données d'historisation qui doivent être sauvegardés dans le deuxième fichier d'historisation L G2 conformément au deuxième format FT2 lorsque d'anciennes données d'historisation sont. transférées depuis le premier fichier 20 d'historisation LG1. Comme décrit par la suite, la carte à puce 2 détermine, à partir de la OU des règles prédéfinies RL, les données d'historisation DH qui doivent être trensféré.es conformément au deuxième format F12 dans le deuxième fichier d'historisation LG2 et celles qui doivent être exclues de ce transfert de sauvegarde. La nature des conditions CD et des règles RL ainsi que leur utilisation sont décrites 25 plus en détail ultérieurement. Comme déjà indiqué, la carte à puce 2 est configurée pour mémoriser des données d'historisation Di-1 selon un premier format FT1 de .données dans le premier fichier d'historisation LG1 et pour sauvegarder si besoin des données -d'historisation DH dans le deuxième fichier d'historisation LG2 selon un deuxième format F12 de données, ce format 30 ru étant compressé (ou réduit en taille) par rapport au format Fil. Des exemples de mise en oeuvre de ces formats FT1 et F17 sont décrits ci-après. Les figures 2A et 2B représentent schématiquement des données d'historisation DH conformes respectivement au premier format FT1 de données et au deuxième format F12 de données. 35 Comme illustré, les données d'historisation DH selon le premier format FT1 (figure 2A) comportent différents types de données notés D1-11 à DH6 caractérisant une même transaction traitée par la carte à puce 2. Chaque type de donnée correspond à une caractéristique de la transaction concernée et présente une valeur particulière. Ces types 12 de données DH1 à DI-16 peuvent comprendre par exemple au moins l'un parmi les types de données suivants : point dans le temps (i.e. dateet/ou heure) au cours duquel la transaction a été traitée ; la monnaie de la transaction ; montant de ia transaction ; au moins un cryptogramme. pré:défini ; contrôles sécuritaires réalisés par la carte à puce ; les résultats des contrôles sécuritaires ; et 10 le résultat (ou statut) de la transaction (acceptée, refusée.. Selon un exemple particulier, les types de données prévus par le premier format FT1 de données sont définis par la norme applicable VISA ou MASTERCARD. Selon un exemple particulier, le premier format FT1 de données ou « Log format» en anglais) est conforme à la norme suivante pour produit CPA (pour « Common Payment 15 Application »): « EllIV Integrated Circuit Card, Specifications for Payment Systems, Common Paymont Application Specification», Version 1.0 décembre 2005. L'homme du métier peut toutefois adapter notamment le nombre et la nature des types de données inclus dans le format Fil selon le cas d'espèce. Conformément à l'invention, le deuxième format FT2 de données est réduit en taille 20 par rapport au premier format ET1 de données. Autrement dit, le deuxième format F12 est un format compressé par rapport au premier format Fil. Le deuxième format F12 de données est réduit (ou compressé) en ce qu'il autorise l'enregistrement d'une quantité inférieure de données par rapport au premier format F11 de données. Le type de compression utilisé pour passer du premier format Fil au deuxième format F12 peut être 25 adapté par l'homme du métier selon chaque cas d'espèce. Comme illustré en figure 2B, dans les exemples décrits ici, les données d'historisation DH selon le deuxième format F12 comportent seulement certains parmi les types de données notés Dl-11 à Di-16 caractérisant une même transaction traftée par la carte à puce 2. Chaque type de donnée correspond à une caractéristique de la transaction 30 concernée et présente une valeur particulière. Dans cet exemple, les données d'historisation DI-1 selon le deuxième format FT2 comportent les types de données D1-11, Di-12 et DH6 mais ne contiennent pas les bffles de données DH3, DHil et DH5 prévus par le premier format FT1. Dans cet exemple, tous les types de données DH1, DH2 et DH6 inclus dans le second 35 format F12 sont également présents dans le premier format FT1, bien que des variantes soient possibles. De manière générale, le premier format I.-71 de données définit par exemple une pluralité de types de données (DH1-DH6 par exemple) tandis que l(?: deuxième format FT2 de données définit une sélection (DH1, DI-12, PH6 per exemple) 13 parmi ladite pluralité de types de données excluant au moins l'un parmi ladite pluralité de types de données. D'autres modes de réalisation sont toutefois possibles. Le processeur 6 piloté par le programme d'ordinateur PG1, met ici en oeuvre un certain nombre de modules représentés en figure 3, à savoir : un module de réception MD2, un module d'obtention MD4, un module d'enregistrement MD6, un module de vérification MD8, un module de sauvegarde MD10, et éventuellement aussi un module de conversion MD12 et un module de traitement MD14. Comme illustré en figures 1-3, le module de réception MD2 est configuré dans cet exemple pour recevoir des données de transaction DTR en provenance du terminal T avec 10 lequel la carte à puce 2 coopère pour traiter une transaction TR1 courante. Ces données de transaction DTR peuvent comprendre divers types de données (point courant dans le temps, montant de la transaction, monnaie...) représentatives de la transaction courante TR1. Le module d'obtention MD4 est configuré- pour obtenir, à partir des données de 15. transaction DTR reçues, de nouvelles données d'historisation DH représentatives de la transaction courante TRI.. Ces donnée d'historisation DH peuvent comprendre des données supplémentaires par rapport aux données DTR fournies par le terminal T, telles que le typo des contrôles sécuritaires effectués par la carte à puce 20 pour vérifier la validité de la transaction courante TR1 ou encore les résultats de ces contrôles 20 sécuritaires ou le résultat final de la transaction (acceptée ou rejetée). Dans un exemple particulier, les données de transaction DTR reçues par le module de réception MD2 et les données d'historisation DH obtenues par le module d'obtention MD4 sont identiques. Le module d'enregistrement MD6 est configuré pour enregistrer [es nouvelles données d'historisation DH selon le premier format FT1 de -données dans le premier fichier 25 d'historisation LG1. Le module de vérification MD8 est configuré pour vérifier, préalablement à l'enregistrement par le module d'enregistrement MD6 des nouvelles données d'historisation DH selon le premier format FT1 de données dans le premier fichier d'historisation LG1, que ledit enregistrement remplit au moins une condition 30 prédéterminée indiquant que ledit .enregistrement est critique vis-à-vis d'anciennes données d'historisation DH stockées en tant que précédente entrée dans le premier fichier d'historisation LG1. Le module de sauvegarde MD10 est configuré, si l'enregistrement est détecté comme étant critique par le module de vérification MD8, pour transférer (ou sauvegarder) les 35 anciennes données d'historisation dans le deuxième fichier d'historisation LG2 selon le deuxième format FT2 de données, réduit en taille par rapport au premier format FT1 de données. Pour ce faire, le module de sauvegarde MD10 compresse ces anciennes données d'historisation selon au moins une règle de sélection RL prédéfinie. 14 Par ailleurs, le module de conversion MD12 est configuré pour interpréter si besoin des données d'historisation DH sauvegardées selon le deuxième format FT2 de données dans le deuxième fichier d'historisation LG2. Pour ce faire, le module de conversion MD12 peut convertir des données d'histoi isation DH sauvegardées selon le deuxième format 1-12 5 dans le deuxième fichier d'historisation LG2 sous une forme modifiée plus facilement exploitable par une entité tierce tel que le terminal T ou le serveur distant SV. Cette conversion peut être réalisée à partir de ladite au moins une règle de sélection RL prédéfinie utilisée préalablement par le module de sauvegarde MD10. Le module de transmission MD14 peut être configuré pour transmettre des données 10 d'historisation DH à un terminal externe tel que le terminai T par exemple. En particulier, le module de transmission MD12 peut transmettre des données d'historfsation DH conformes au format FT2 ou éventuellement de telles données préalablement converties sous une forme modifiée par le module de conversion MD12. La configuration et le fonctionnement des modules MD2-7,1D1,1 de la carte à puce 2 15 apparaîtront plus précisément dans les exemples de réalisation décrits ci-après en référence notamment aux figures 4A-4B, 5-6, 7A-7B et 8-9. On comprendra toutefois que les modules MD2-MD14 tels que représentés en figure 3 ne représentent qu'un exemple de mise en oeuvre non limitatif de l'invention. La coopération entre une carte à puce et un lecteur externe approprié pour réaliser 20 une transaction de type EMV est connue en soi et ne sera donc pas développée en détail dans le présent exposé par souci de simplicité. On suppose dans les modes de réalisation décrits ci-dessous que le mode d'enregistrement des entrées dans le premier fichier d'historisation LG1 (figure 1) est cyclique. Autrement dit, si le premier fichier d'historisation LG1 est rempli (contient le 25 nombre maximum d'entrées enregistrables dans LG1), alors chaque nouvelle entrée représentative d'une transaction courante est enregistrée dans le fichier LG1 à la place de l'entrée la plus ancienne dans le fichier LG1, c'est-à-dire par écrasement de l'entrée correspondant à la transaction la plus ancienne. Comme déjà indiqué, cet écrasement peut avoir un caractère critique si les données d'historisation ainsi supprimées sont 30 considérées comme étant toujours pertinentes. La figure 4A représente le contenu du premier fichier d'historisation LG1 selon un exemple particulier. Conformément à ['invention, les données d'historisation DH enregistrées dans le premier fichier d'historisation LG1 sont conformes au premier format FT1 de données. Dans cet exemple, le premier fichier d'historisation LG1 peut comporter 35 des données d'historisation DH sous la forme d'entrées RC distinctes (appelées aussi entrées d'historique), chacune d'elles étant représentative d'une transaction respective traitée par la carte à puce 2. 15 Dans l'exemple considéré ici, le premier fichier d'historisation LG1 comporte les entrées d'historique RC1-RC10 représentatives de transactions antérieurs à la transaction courante TR1, traitées par la carte à puce 2. Conformément au premier format FT1, les entrées RO. à RC10 comprennent chacune les types de données DI-11 à DH6, comme déjà décrit ci-avant. On suppose ici que le premier fichier d'historisation LG1 peut contenir un nombre maximum n1 de. 1.0 entrées RC de données d'historisation correspondant à- 10 transactions respectives, bien que des variantes soient bien entendu possibles. Selon un exemple particulier, le premier fichier d'historisation .LG1 est conforme à la norme ISO/IEC 7816-4 (cf. « EMV 4.3 Book 3 », section 4). L'entrée RC1 est l'entrée la 10 plus récente, l'entrée RC2 est la deuxième transaction la plus récente, etc. La figure 4B représente le contenu du deuxième fichier d'historisation LG2 selon un exemple particulier. Conformément à l'invention, les données d'historisation DH .sauvegardées dans le deuxième fichier d'historisation LG2 sont conformes au deuxième format FT2 de données. Dans cet exemple, le deuxième fichier d'historisation LG2 peut 15 comporter des données d'historisation DI-1 sous la forme d'entrées RD distinctes - notées ici RD1-RD20 chacune d'elles étant représentative d'une transaction respective traitée par la carte à puce 2. Chaque entrée RD (appelée aussi entrée de sauvegarde) présente dans le fichier LG2 correspond ici à une ancienne entrée RC qui a été précédemment transférée par mesure de sauvegarde depuis le premier fichier d'historisation LG1., 20 conformément à l'invention. On suppose ici que le deuxième fichier d'historisation LG2 peut contenir un nombre maximum n2 de 20 entrées RD de données d'historisation correspondant à 20 transactions respectives, bien que des variantes soient bien entendu possibles. Conformément au deuxième fOrmat FT2, chaque entrée RD sauvegardée dans le 25 deuxième fichier d'historisation LG2 comprend une sélection (ou sous-ensemble) parmi les types de données DH1 à DH6 de sorte que l'un au moins parmi les types DH1 à .DH6 est exclu. A titre d'exemple, les entrées .RD1 et RD2 comportent des données d'historisation DH de type DH1, DH2 et DH6, tandis que l'entrée RD3 comporte uniquement des données d'historisation DH de type DH2 et DH6 (figure 4B). 30 Les données .d'historisation DH dans le deuxième format FT2 constituent donc une version compressée ou allégée par rapport aux données d'historisation DH dans le premier format FT1. Dans cet exemple, la compression réalisée pour passer du format FT1 au format FT2 implique une perte de données, c'est-à-dire l'exclusion d'au moins un type de données lors de la sauvegarde dans le .deuxième fichier d'historisation LG2. 35 D'autres types de compression sont toutefois possibles. La figure 5 représentent les étapes réalisées par la carte à puce 2 illustrée en. figures 1-3 et 4A-4B lors d'un procédé de traitement conforme à un mode de réalisation particulier de l'invention. Plus précisément, la carte à puce .2 met en oeuvre le procédé de 16 traitement en exécutant le programme PG1, selon un mode de réalisation particulier de l'invention. On suppose que le traitement d'une transaction TRI, dite transaction courante, est initié (S2) par la carte à puce 2 en coopération avec le terminai T. Comme déjà indiqué, on suppose ici que cette transaction est de type EMV (une transaction de paiement .par exemple). Au cours du traitement de cette transaction TR1, la carte à puce. 2 reçoit (S4) diverses données de transaction DTR représentatives de la transaction courante TR1, conformément au protocole ENIV (date, monnaie, montant de la transaction...). 10 Au cours d'une étape 56 d'obtention, la carte à puce 2 obtient, à partir des données de transaction DTR reçues, de nouvelles données d'historisation (ou données d'historique) DH à enregistrer en tant que nouvelle entrée dans sa mémoire 10, ces nouvelles données d'historisation DH étant représentatives de la transaction courante TR1. Comme déjà expliqué, ces nouvelles données d'historisation peuvent comprendre tout ou parties des 15 données de transaction DTR reçues en 54 et éventuellement des données supplémentaires déterminées par la carte à puce 2 en réalisant un quelconque traitement approprié à partir des données de transaction TR1. Dans un exemple particulier, les données de transaction DTR reçues en 54 et les nouvelles données d'historisation DH obtenues en 56 sont identiques. 20 On suppose ici que la carte à puce 2 obtient en 56 tous les types de données DH1 à DH6 tels que décrits précédemment en référence notamment à la figure 2A. Ces nouvelles données d'historisation DH comprennent notamment le type des contrôles sécuritaire.s réalisés par la carte à puce 2 lors du traitement de la transaction courante TR1 ou encore le statut (accepté, refusé) de cette transaction TR1. 25 Comme indiqué par la suite, la carte à puce 2 est sur le point d'enregistrer (étape 512 à venir) les nouvelles données d'historisation DH obtenues en 56 dans le premier fichier d'historisation LG1 selon le premier format Fil de données. Cet enregistrement 512 imminent peut cependant être critique s'il cause la perte d'anciennes de données d'historisation DH déjà présentes dans le premier fichier d'historisation LG1 au moment de 30 l'enregistrement S12. Aussi, préalablement à l'étape 512 d'enregistrement dans le premier fichier d'historisation LG1, la carte -à puce réalise l'étape 58 de vérification, et éventuellement aussi l'étape S10 de transfert, comme décrit ci-après. Au cours de l'étape 58 de vérification, la carte à puce 2 vérifie que l'enregistrement 512 à venir des nouvelles données d'historisation DH dans le premier fichier d'historisation 35 LG1 selon le premier format Fil remplit au moins une condition prédéterminée CD indiquant que ledit enregistrement 512 est critique vis-à-vis d'anciennes données d'historisation DH stockées en tant que précédente entrée RC (représentative d'une transaction antérieure à la transaction courante TRI) dans le premier fichier 17 d'historisation LG1. Comme indiqué par la suite, l'homme du métier peut adapter la ou les conditions CD à prendre en compte -en 58 pour déterminer si l'enregistrement 58 à réaliser est critique ou non. Selon un exemple particulier, l'enregistrement 58 des nouvelles données d'historisation DH est jugé critique si cet enregistrement dans le premier fichier d'historisation LG1 cause la suppression (ou perte) d'une quelconque ancienne entrée RC déjà présente dans ce fichier LG1 avant l'enregistrement 512. La définition des conditions CD permet d'adapter dans quels cas d'anciennes données d'historisation DH doivent être sauvegardées selon le deuxième format FT2 de données dans le deuxième fichier d'historisation LG2. L'enregistrement 512 à venir est en 10 particulier considéré comme étant critique s'il y a un risque suffisant qu'il cause la perte immédiate, ou éventuelle prochaine, d'anciennes données d'historisation DH pertinentes stockées dans le premier fichier d'historisation LG1 selon le premier format FT1 de données. Une condition CD appliquée en 58 peut notamment comprendre une condition 15 temporelle comme décrit ultérieurement. Si l'enregistrement 512 à venir n'est pas détecté comme étant critique en 58, la carte à puce 2 procède à cette étape S12 d'enregistrement qui est décrite ultérieurement. Dans ce cas, la carte à puce 2 ne transfert pas d'anciennes données d'historisation DH depuis le premier fichier d'historisation LG1 dans. le deuxième fichier d'historisation LG2. Autrement 20 dit, le mécanisme de sauvegarde de l'invention n'est alors pas activé par la carte à puce. 2. Si, en revanche, l'enregistrement 512 à venir est détecté en 58 comme étant critique vis-à-vis d'anciennes données d'historisation DI-1 stockées en tant que précédente entrée RC dans le premier fichier d'historisation LG1, la cafte à puce 2 réalise une étape S10 de 25 transfert au cours de laquelle elle transfert (ou sauvegarde) lesdites anciennes données d'historisation DI-1 dans le deuxième fichier d'historisation LG2 selon le deuxième format FT2 de données. Ces anciennes données d'historisation DH sont enregistrées en tant que nouvelle entrée de sauvegarde RD dans un emplacement libre du deuxième fichier d'historisation LG2 ou, à défaut, à la place de la plus ancienne entrée de sauvegarde RD 30 présente dans le deuxième fichier d'historisation LG2 (enregistrement cyclique). Comme déjà indiqué, le deuxième format FT2 est réduit en taille (compressé) par rapport au premier format FT1 de données. Ce transfert S10 est réalisé préalablement à l'enregistrement 512 des nouvelles données d'historisation DH dans le premier fichier d'historisation LG1 afin d'éviter tout risque de perdre d'anciennes données d'historisation 35 DH pertinentes. Comme décrit plus en détail par la suite, l'étape S10 de transfert (ou étape de sauvegarde) nécessite la conversion préalable des données d'historisation DH dans le deuxième format FT2 de sorte que l'un au moins des types de données définis par le 18 premier format FT1 soit exclu des données d'historisation DH sauvegardées dans le deuxième fichier d'historisation Fr2. La conversion dans le format FT2 est ici réalisée en exécutant au moins une règle de sélection prédéfinie RL, cette règle indiquant le ou- les types de données sélectionnés en vue d'être sauvegardés dans le deuxième fichier d'historisation LG2. Comme illustré en figure 4B, on suppose par exemple ici que, lors de à l'étape 510 de transfert, d'anciennes données d'historlsation Mi du fichier LG1 sont sauvegardées -selon le deuxième format FT2 en tant que nouvelle entrée RD2 dans le deuxième fichier d'historisation LG2, cette nouvelle entrée RD2 comprenant les types de données 10 DH2 et DH6. Autrement dit, le transfert 510 conduit dans cet exemple à l'exclusion des -types de données DH3, et DH5 des anciennes données d'historisation DH sauvegardées (510) avant l'enregistrement 512 des nouvelles données d'historisation dans le premier fichier d'historisation LG1. Comme représenté en figure 5, au cours de l'étape 512 d'enregistrement, la carte à 15 puce 2 enregistre ensuite les nouvelles données d'historisation DH (obtenues en 56) selon le premier format FT1 de données dans le premier fichier d'historisation LG1. Ces nouvelles données d'historisation DI-1 sont enregistrées en tant que nouvelle entrée RC dans un emplacement libre du premier fichier d'historisation LG1 ou, à défaut, à la .place de ia phis ancienne -entrée RC présente dans ic premier fichier d'historisation LG1 20 (enregistrement cyclique). Dans le cas où l'enregistrement 512 a été détecté comme étant critique en 58, il est susceptible de causer la perte immédiate ou ultérieure d'une -précédente entrée RC correspondant à une transaction antérieure à la transaction courante La présente invention permet d'optimiser l'usage de mémoire de la carte à puce 25 .pour stocker des données d'historique propres aux transactions traitées par la carte. Comme déjà indiqué, les ressources en mémoire d'une carte à puce sont limitées. La carte à puce selon l'invention est capable de réaliser un tri intelligent pour transférer si besoin certaines données d'historique depuis un premier fichier d'historisation vers un deuxième fichier d'historisation, de sorte à réaliser une sauvegarde sous forme compressée de 30 données d'historisation. Ce mécanisme de transfert permet de limiter les risques que d'ancienne données d'historique, considérées comme toujours pertinentes, soient perdues suite l'enregistrement de nouvelles données d'historique dans la mémoire de la carte à puce et ce, tout en garantissant qu'un minimum d'informations utiies soient sauvegardé afin 35 d'économiser de l'espace mémoire. La sauvegarde peut être mise en oeuvre dans un second fichier d'historique dédié. de la carte à puce sans qu'il soit nécessaire d'exécuter un algorithme de compression complexe, facilitant ainsi la sécurisation des données d'historisation. 19 En prticufler, l'invention permet de déterminer si d'anciennes données d'historisation doivent Litre transférées depuis le premier fichier d'historisation vers un deuxième fichier d'historisation, en fonction du caractère critique ou non d'un enregistrement à venir de nouvelles données d'historisation dans le premier fichier d'historisation: Si un tel enregistrement à venir est critique, la carte à puce détecte que d'anciennes données d'historisation stockées dans le premier fichier d'historisation risque d'être perdues et transfert par conséquent celles-ci dans le deuxième fichier- d'historisation dans un format compressé. Bien que certaines données dinistorisation ne soient pas conservées lors de ce transfert de sauvegarde en raison de 'usage du second format, cela permet de garantir 10 que la carte à puce garde en mémoire au moins certains types de données jugés importants pour une exploitation ultérieure par la carte à puce ou une entité tierce. La carte à puce 2 peut ainsi accéder ultérieurement aux données d'historisation DH enregistrées aussi bien dans le premier fichier d'historisation LG1 dans le format FT1 que dans le deuxième fichier d'historisation LG2 dans le format f- 2. 15 En particulier, au cours d'une étape 514 de lecture (figure 5), la carte à puce 2 peut ultérieurement lire les données d'historisation stockées dans le deuxième fichier d'historisation LG2- selon le format FT2 et utiliser ces données de façon appropriée. La carte à puce 2 peut notamment utiliser ces données DH pour réaliser un contrôle sécuritaire, notamment lors du traitement d'une transaction ultérieure à !ü: transaction 20 TRI, ou peut encore transmettre ces données à un terminal externe, par exemple lors du traitement d'une transaction d'ultérieure. La carte à puce 2 peut ainsi avantageusement utiliser toutes les données d'historisation DH sauvegardées dans le deuxième fichier d'historisation pour sécuriser le traitement de transactions. L'émetteur 15 de la carte à puce 2 peut également recevoir 25 ces données, lors du traitement en liane d'une transaction par exemple, pour réaliser tous types de traitement appropriés : contrôles sécuritaires à distance de 1a transaction en cours, analyse comportemental du porteur de :a carte... Comme déjà indiqué, les conditions prédéfinies CD appliquées à l'étape 58 pour déterminer si Venregistrement S12 à venir est critique ou non peuvent être adaptées selon 30 le cas. Dans un exemple de réalisation particulier, la carte à puce 2 détecte systématiquement en S8 que l'enregistrement S12 à venir des nouvelles données d'historisation DH de la transaction courante TR1 n'est pas critique si cette transaction courante TR1 est une transaction sans contact. Autrement dit, la carte à puce 2 bloque 35 systématiquement le mécanisme de sauvegarde de !Invention dans le cas où la transaction courante TRi est traitée en sans contact par la carte à puce 2. Pour ce faire, ia carte à puce 2 détecte au préalabie si la transaction courante T R1 est une transaction sans contact ou non. Lorsqu'une transaction est réalisée en sans contact, il est important 20 que le carte à puce 2 traite la transaction rapidement, en raison notamment des contrantes de temps imposées par cette opération ou par une norme applicable. Il est .donc avantageux d'éviter de mettre en oeuvre e mécanisme de sauvegarde de l'invention afin de garantir un traitement rapide des transactions sans contact. Dans un exemple de réalisation particulier, la carte à puce 2 détecte en 58 que l'enregistrement 512 à venir des nouvelles données d'historisation D1-1 de la transaction courante 'TRI est critique seulement si la transaction courante TRI, est passé avec succès. Pour ce faire, la carte à puce 2 détecte au préalable si un cryptogramme TC (pour « Transaction Cereicate»), indiquant que la transaction a été approuvée, a été obtenu 10 .pour la transaction courante TRI. La carte à puce. 2 consulte par exemple les données d'historisation DI-1 obtenues en S6 et détermine si celles-d contiennent le cryptogramme TC conforme à la norme EMIL Cette variante permet de limiter l'espace mémoire utilisé dans la carte à puce en ne transférant dans le fichier d'historisation secondaire que les données d'historisation considérées comme étant les plus pertinentes, à savoft celles concernant des transactions approuvées par la carte à puce 2. La figure G représentent les étapes réalisées par la carte à puce 2 illustrées en ifigures 1-3 et 4A-4B lors d'un procédé de traitement conforme à un mode de réalisation particulier de l'invention. Plus précisément, la carte à puce 2 met en oeuvre le procédé de traitement en exécutant ie. programme PGI, selon un mode de réalisation particulier de 20 l'invention. On suppose que la carte à puce 2 réalise les étapes 52,54 et 56 de façon identique à ce qui est décrit précédemment en référence à la figure 5, et que- la carte à puce 2 est -sur le point de d'enregistrer (étape S12 à venir) les nouvelles données d'historisation DH obtenues en 56 dans le premier fichier d'historisation LG1 selon le premier format FT1 de 25 données, comme déjà décrit en référence à la figure 5. La carte à puce 2 réalise ensuite l'étape 58 de vérification, comme déjà décrit en référence à la figure 5, pour vérifier si l'enregistrement 512 à venir des nouvelles données d'historisation Di-1 dans le premier fichier d'historisation LG1 est critique vis-à-vis d'anciennes données d'historisation D1-1 stockées en tant que précédente entrée RC dans 30 le premier fichier d'historisation LG1. Pour ce faire, au cours de l'étape S8 de vérification, la carte â puce 2 réalise dans cet exemple une étape 520 de détermination pour déterminer si l'enregistrement 512 à venir des données d'historisation DFi selon le premier format FT1 de données dans le premier fichier d'historisation LG1 conduit (une fois réalisé) à un écrasement ou suppression d'une 35 précédente entrée RC, représentative d'une précédente transaction, déjà enregistrée dans le premier fichier d'historisation LG1 selon le premier format FT1 de données. Un risque d'écrasement est par exemple détecté s'il n'existe plus d'emplacement ou de zone -mémoire libre (non occupée) dans le premier fichier d'historisation LG1 ou encore si ce 21 fichier LG1 comporte déjà un nombre maximal prédéfini n1 d'entrées correspondant à des transactions antérieures à la transaction- courante TRI.. Si l'étape 520 de détermination délivre un résultat négatif (pas de risque d'écrasement d'une ancienne entrée dans LG1), alors la carte à puce 2 procède à l'étape 512 d'enregistrement, de façon identique à ce qui est décrit précédemment à la figure 5, de sorte à enregistrer les nouvelles données d'historisation DH obtenues en 56 dans le premier fichier d'historisation LG1 selon le premier format FT1.de données. Dans ce cas, carte à puce 2 ne transfert pas client:enfles données d'historisation DH depuis le premier fichier d'historisation LG1 dans le deuxième fichier d'historisation LG2. Autrement 10 dit, le mécanisme de sauvegarde de l'invention n'est pas activé par la carte à puce 2. Si, en revanche, l'étape 520 de détermination délivre un résultat positif indiquant un risque d'écrasement d'une précédente entrée RC dans le premier fichier d'historisation LG1, alors ia carte à puce 2 poursuit l'étape de vérification 58 en réalisant une détection S22. 15 A titre d'exemple, on suppose par la suite que, lors de l'étape 520 de détermination, la carte à puce 2 détermine que l'enregistrement 512 à venir des données d'historisation DH selon le premier format FT1 de données dans le premier fichier d'historisation LG1 conduit à l'écrasement de la précédente entrée RC2, représentative d'une précédente transaction TR2, déjà enregistrée dans le premier fichier d'historisation LG1 selon le 20 prernier format. Fri de données (figure 4A). Ceci s'explique ici par le fait que la précédente entrée RC2 constitue dans cet exemple la plus ancienne entrée enregistrée dans le fichier LG1 au moment de l'exécution de l'étape 520 de détermination. Au cours de l'étape 522 de détection, la carte à puce 2 détecte que l'enregistrement 58 à venir des données d'historisation DH de la transaction courante TR1 est critique si la 25 précédente transaction TR2, définie par ladite précédente entrée DH2 risquant d'être écrasée, remplit une première condition temporelle CD1. Diverses conditions temporelles sont possibles pour définir en S22 si un enregistrement par écrasement dans le premier fichier d'historisation LG1 constitue un enregistrement critique ou non au sens de l'invention. Une combinaison de conditions 30 temporelles et non-temporelles est également possible. Dans l'exemple considéré ri, la vérification de la première condition temporelle est illustree en référence aux figures 7A et 7B. On suppose que la transaction courante TR1 est traitée ou a été traitée au cours d'un instant courant PC qui est représenté sur une ligne de temps dans les figures 7A et 35 .7B. Le terme « instant » désigne dans ce document une date et/ou une heure oc, plus généralement, une quelconque indication d'une position dans le temps (indication temporelle). On suppose que chaque transaction considérée dans ce document est 22 caractérisée par un instant donné qui est défini dans les données d'historique correspondantes. Dans ce document, un instant peut être caractérisé .par une date et/ou une heure par exemple. L'instant courant PC caractérise l'instant au cours duquel est réalisé le procédé de l'invention, la manière dont cet instant courant est déterminé par le terminal T étant laissé au libre choix de l'homme du métier. Dans un exemple particulier, la carte à puce 2 récupère une indication de l'instant courant PC depuis le terminal T ('étape 54 dans leS données de transaction DTR. Selon l'exemple considéré ici, PC désigne donc l'instant courant au cours duquel est 10 réalisé ou a été réalisé la transaction courante TR1 par la carte à puce 2. On note par ailleurs PA1 un premier instant, antérieur dans le temps à 'instant courant PC, au cours duquel a été réalisée la précédente transaction TR2 comme définie par la précédente entrée RC2 La première condition ternpore le CD1 est détectée en 522 comme étant remplie si ce premier instant antérieur 'PA1, au cours duouel a été réalisée la précédente 15 transaction TR2 selon la précédente entrée RC2, se trouve dans une période de temps PD, d'une durée prédéfinie., terminant à l'instant courant PC. Cette période de temps PD est lci une période de temps glissante qui présente une durée prédéfinie et s'achève à l'instant courant PC de la transaction courante TR1 traitée par la carte à puce 2. La durée prédéfinie de la période PD est par exemple fixée à 1 mois, cette valeur pouvant être 20 adaptée selon le cas. La figure 7A représente un premier cas où, selon l'entrée RC2 stockée dans le fichier d'historisation LG1, la précédente transaction TR2 est associée à un instant antérieur PA1 se trouvant clans la période de temps PD. Dans ce cas, la première condition temporelle CD1 est donc remplie. 25 La figure 7B représente un deuxième cas où, selon l'entrée RC2 stockée dans le fichier d'historisation LG1., la précédente transaction TR2 est associée à un instant antérieur PA1 qui est antérieur à la période de temps PD. Dans ce cas, la première condition temporelle CD1 n'est donc pas remplie. La vérification réalisée par la carte à puce 2 pour déterminer en 522 si la première 30 condition temporelle CD1 est rempile est décrite plus en détail ci-après dans un exemple particulier représenté en figure 9. Toujours en référence à la figure 6, si la première condition temporelle CD1 est détectée en 522 comme n'étant pas remplie cas de la figure 76), alors la carte à puce 2 procède à l'étape S12 d'enregistrement, de façon identique à ce qui est décrit 35 précédemment à la figure 5, de sorte à enregistrer les nouvelles données d'historisation DH obtenues en 56 dans le premier fichier d'historisation LG1 selon le premier format FT de données. Dans ce cas, la carte à puce 2 ne transfert pas d'anciennes données d'historisation DH depuis le premier fichier d'historisation LG.1 dans le deuxième fichier 23 d'historisation LG2. Autrement dit, le mécanisme de sauvegarde de l'invention n'est pas activé par la carte à puce 2. Dans ce cas particulier., l'enregistrement 512 des nouvelles données d'historisation DH représentatives de la transaction courante TR1 entraîne par conséquent la suppression, dans le premier fichier -d'historisation LG1, de l'entrée RC2 correspondant à la précédente transaction TR2. Cet écrasement de données en 512 se justifie ici par le fait que l'on estime que la précédente entrée RC2 n'est plus pertinente du fait qu'elle correspond à une transaction suffisamment ancienne car antérieure à la fenêtre temporelle PD terminant au point courant PC. La carte à puce 2 juge donc ici qu'il n'est pas utile de sauvegarder une 10 version compressée de cette précédente entrée RC2 dans le deuxième fichier cithistorisaton LG2, ce qui permet d'éviter l'utilisation superflue de ressources de la calte à puce 2. Si, au contraire, la première condition temporelle CD1 est détectée en 522 comme étant remplie (cas de la figure 7A), alors l'enregistrement 512 à venir est détecté comme 15 critique (58) et la carte à puce 2 réalise une sauvegarde de l'entrée RC2 dans le deuxième fichier d'historisation LG2 conformément a l'invention (figure 6). On suppose dans cet exemple que la carte à puce 2 réalise la sauvegarde de l'ancienne entrée RC2 représentative de l'ancienne transaction TR2, en transférant les données d'historisation DH correspondantes dans le deuxième fichier d'historisation LG2 20 selon le deuxième format FT2 de données. Pour ce faire, la carte à puce 2 procède dans cet exemple aux étapes 524, 526 et 510, comme deuit ci-après, préalablement à l'étape 512 d'enregistrement. Plus particulièrement, au cours d'une étape 524 de sélection, la carte à puce 2 sélectionne parmi les types de données d'historisation DH1-DH6 définis par le premier 25 format Fil de données, un sous-ensemble de de types de données d'historisation conformément à au moins une règle de sélection RL prédéfinie. La- carte à puce 2 peut sélectionner par exemple en 524 les types de données DH1, DH2 et DH6 parmi les types de données .DH1-DH6, comme illustré en figures 2A-26. Ces types de données sont par exemple tels que : 30 - DH1 définit un instant (date et/ou heure) caractérisant la transaction courante TR1 ; - DI-12 définit le montant de la transaction courante TRI ; et DH3 définit la monnaie utilisée dans la transaction courante TRI_ &noter que les règles prédéfinies RI_ appliquées à l'étape 524 pour déterminer quels 35 types de données doivent être sélectionnés peuvent être adaptées selon le cas. Selon trl exemple particulier, les règles prédéfinies RL définissent toujours les mêmes type- de données à sauvegarder en tant que nouvelle entrée dans le deuxième fichier d'historisation LG2. Les règles RL prévoient par exemple la sélection systématique des 24 types de données DH1, DH2 et DH6 lors de Vétap S24 de sélection, causant ainsi l'exclusion des types de données DH3-DH5. Selon un autre exemple, la carte à puce 2 peut également adapter les types de données d'historisation D1-1 sélectionnés en 524 en fonction des précédentes entrées de sauvegarde RD déjà stockées dans le deuxième fichier d'histor sation LG2 au moment d'initier l'étape S24 de sélection: En faisant varier les types de données sélectionnés en 524, il est possible de llmiter encore d'avantage l'espace mémoire nécessaire pour stocker les données d'historisation Dl-l. Plus particulièrement, au moment d'initier l'étape 521 de sélection, le second fichier 10 d'historisation LG2 comprend par exemple déjà au moins une ancienne entrée RD sauvegardée selon le format FT. Cette ancienne entrée RD est représentative d'une précédente transaction antérieure à la transaction TR2 faisant l'objet du mécanisme de sauvegarde. On suppose ici par exemple que le deuxième fichier d'historisation LG2 ne comporte, au moment d'initier l'étape 524 de sélection, que les anciennes entrées 15 sauvegardées RD1 et RD2 correspondant à des transactions respectives TR3 et TR4 antérieures à la transaction 1R2 (figure 4B). Dans ce cas, la carte à puce 2 sélectionne en 524, conformément à une règle de sélection RL prédéfinie, le premier type DH1 de données d'h;storisation seulement si la plus récente entrée RD sauvegardée dans le .second iclier d'histor1sation LG2 comportant ledit premier type DH1 de donnée 20 d'historisation spécifie, pour ledit premier type DH1 de données d'historisation, une valeur différente de celle définie par l'entrée RC2 pour la transaction TR2. Autrement dit, en supposant par exemple que D1-1i correspond à l'instant (la date par exemple) d'une transaction, ia carte à puce 2 ne sélectionne le type DH1 en 521 que si la précédente entrée RD2 comportant le premier typo DH1 dans le fichier LG2 spécifie, pour ce type 25 .D1-11, une date différente de celle définie par l'entrée RC2 dans le fichier LG1 pour la -transaction TR2. Dans l'hypothèse où l'entrée RD2 ne comporterait pas le type DH1., la carte à puce 2 se réfère à la précédente entrée de sauvegarde RD1 qui comporte le type Dlii de sorte que le type DH1 est sélectionné en 524 que si la précédente entrée RD1 dans le fichier LG2 spécifie, pour ce t.,,/po DH1, une date différente de celle définie par 30 l'entrée RC2 dans le fichier LG1 pour la transaction TR2. De cette manière, il est possible par exemple d'adapter ic contenu de chaque nouvelle entrée RD sauvegardée dans le deuxième format sorte que l'une au moins des conditions suivantes soient satisfaites : - le montant de la transaction TR2 à sauvegarder dans LG2 est toujours 35 sélectionné en S24; la date de ia transaction TR2 à sauvegarder est sélectionnée .en 574 seulement si elle est différente de la date de la transaction la plus récente déjà sauvegardée dans le deuxième fichier d'historisation LG7 ; 25 la monnaie de la transaction TR2 à sauvegarder est sélectionnée en 524 seulement si elle est différente de la monnaie de la transaction la plus récente déjà sauvegardée dans le deuxième fichier d'historisation LG2. Autrement dit, au moins une entrée RD sauvegardée dans le deuxième fichier d'historisation LG2 peut être codée à partir du contenu de l'entrée RD immédiatement précédente dans le deuxième fichier -d'historisation LG2 ou à partir du contenu d'une autre précédente entrée RD dans le deuxième fichier d'historisation LG2. Si la carte à puce enregistre un type de types de donnée dans le deuxième fichier d'historisation LG2 lors de la sauvegarde d'une ancienne transaction, uniquement lorsque 10 la valeur correspondante diffère par rapport à une autre transaction précédemment sauvegardée dans le deuxième fichier d'historisation LG2, il est possible de gagner encore plus d'espace mémoire sans perdre d'informations utiles. Comme plusieurs transactions successives présentent souvent des caractéristiques communes (même date, même monnaie...), on évite de stocker des informations redondantes dans le fichier 15 d'historisation secondaire LG2 de la carte à puce 2. Une entrée de sauvegarde RD stockée .dans le second fichier d'historisation LG2 peut s'interpréter à partir de l'entrée -immédiatement précédente, ou à partir d'une autre entrée précédente, dans ce fichier .LG2. En particulier lorsque les types des données d'historisation dans le deuxième fichier 20 d'historisation LG2 sont susceptibles de varier, il est avantageux d'inclure dans chaque entrée RD un champ (non représenté sur les figures) indiquant les types de données -indus (par exemple dans un entête de l'entrée). Ce champ permet notamment -d'interpréter plus .facilement les données d'historisation incluses dans une entrée RD, lors -par exemple d'une étape d'interprétation S28 décrite ci-après. 25 Dans la suite de cet exemple représenté en figure 6, on suppose que seuls les types .de DH2 et DH6 sont sélectionnés lors de l'étape 524 de sélection dans le cadre de la .sauvegarde de l'entrée RC2 du fichier LG1 correspondant à l'ancienne transaction TR2. Une fois l'étape 524 de sélection réalisée, la carte à puce 2 convertit (étape S26) les les -données d'historisation DH de l'entrée RC2 depuis le premier format FT1 dans le 30 deuxième format FT2 de sorte à former une nouvelle entrée de sauvegarde RD3 dans laquelle seuls le ou les types de données d'historisation sélectionnés en S24 sont conservés. Autrement -dit, dans l'exemple considéré ici, la nouvelle entrée de sauvegarde .RD3 comprend les données DI-12 et DH6 de l'ancienne entrée RC2. En revanche, les données. DH1, DH3, IDH4 et DH5.de. l'ancienne entrée RC2 sont exclues de la sauvegarde. 35 Au cours d'une étape 510 de transfert, la carte à puce 2 transfert (ou sauvegarde) la nouvelle entrée de sauvegarde RD3 dans le deuxième fichier d'historisation LG2 selon le deuxième format FT2 de données, comme déjà décrit en référence à la figure 5. Plus 26 particulièrement, dans l'exemple considéré ici, la nouvelle entrée RD3 est enregistrée dans le deuxième fichier cibistorisation LG2 à la suite de la précédente entrée RD2. Suite à cette étape S10 de transfert, la carte à puce 2 réalise l'étape 512 d'enregistrement au cours de laquelle elle enregistre les nouvelles données d'historisation DH, correspondant à la transaction en cours TRI, dans le premier fichier d'historisation LGI selon le premier format FT1. Dans le cas où l'enregistrement 512 a été détecté àVavance en S8 comme étant critique, il peut causer la perte immédiate ou ultérieure d'une précédente. entrée RC correspondant à une transaction antérieure à la transaction courante TR1, telle que par exemple Ventrée RC2 de la précédente transaction TR2. 10 La carte à puce 2 peut ultérieurement consulter les données d'historisation D1-1. enregistrées dans le format FT2 dans le deuxième fichier d'historisation LG2. Comme représenté en figure 6, la carte à puce 2 peut ultérieurement (étape 528)- interpréter si besoin l'entrée de sauvegarde RD2 stocker dans le deuxième fichier d'historisation LG2 à partir de Ventrée de sauvegarde RD immédiatement précédente, ou 15 à partir d'une autre entrée de sauvegarde RD précédente. La carte à puce 2 peut le cas échéant se reporter au champ de l'entrée RD2 pour déterminer les types de données inclus dans cette entrée. Dans l'exemple considéré ici (figure 4B), la carte à puce 2. convertit l'entrée de sauvegarde RD3 dans un format modifié, plus facilement exploitable par une entité tierce, en y incluant la données d'historisation Dl-11 représentative de 20 l'ancienne transaction TR2. La carte à puce 2 retrouve la donnée Dl-Il de la transaction TR2 à partir de la donnée DHÏ de la précédente entrée RD2 dans le deuxième fichier d'historisation LG2. La carte à puce 2 peut ensuite transmettre 530) l'entrée RD3 dans ce format modifié (ou dans son format FIl2 (l'origine) à une entité tierce te: que ta banque 15 par 25 l'intermédiaire d'un terminai de lecture, ce qui permet à l'émetteur 15 de la carte à puce 2 de récolter les informations d'historique pertinentes. L'interprétation S28 effectuée éventuellement par la carte à puce 2 permet de rendre transparente pour l'émetteur _1S la manière dont a été codée une entrée de sauvegarde RD dans le deuxième fichier .d'historisation LG2 à partir d'une précédente entrée de sauvegarde RD. 30 Par ailleurs, comme déjà indiqué, les conditions prédéfnles CD appliquée à l'étape. SS (figures 4-5) pour déterminer si un enregistrement 52 à réaliser est crib Je ou non_ peuvent être adaptées selon le cas. Dans un exemple de réalisation particulier, la carte a puce 2 détecte systématiquement en 522 (figure 6) que l'enregistrement des données d'historisation DH 35 de la transaction courante TRI n'est pas critique si la transaction courante TRI est une transaction sans contact. Pour ce faire, la carte à puce 2 détecte au préalable si la transaction courante TR1 est une transaction sans contact ou non. 27 Lorsqu'une transaction est réalisée en sans contact, il est important que la carte à puce 2 traite la transaction rapidement, en raison notamment des contraintes. de tern imposées par cette opération ou par une norme applicable. Il est donc avantageux d'éviter de mettre en oeuvre le mécanisme de stockage sous forme compressée dans le fichier d'historisation secondaire afin de garantir un traitement rapide des transactions sans contact. En outre, toujours dans le but de faciliter le traitement des transactions sans contact, il peut être avantageux de déclencher le mécanisme de sauvegarde de l'invention en transférant d'anciennes données d'historisation DEI dans le deuxième fichier d'historisation 10 LG2 selon le deuxième format FT2 lorsque la transaction courante TR1 est traitée par la carte à puce 2 par contact et ce, même s'il n'y a pas un risque immédiat de supprimer de précédentes données d'historisation DH dans le premier fichier d'historisation LG1 (figure 1). On peut par exemple configurer la carte à puce 2 pour qu'elle détecte en S8 15 (figures 4 et 5) que l'enregistrement 512 à venir des données de transaction DH de la transaction courante TR1 dans le premier fichier LG1 est critique dès lors qu'il existe un nombre insuffisant d'espaces vacants dans le premier fichier d'historisation LG1 pour que .des données d'historisation de prochaines transactions en sans contact puissent y être stockées rapidement dans le premier fichier d'historisation LG1 sans nécessiter la 20 sauvegarde 510 d'anciennes données d'historisation DH dans le deuxième fichier d'historisation LG2. Ainsi, selon un exemple particulier représenté en figure 8, la carte à puce 2 réalise les étapes 52 à 56 comme déjà décrit précédemment. Au cours de l'étape 58 de vérification, la carte à puce 2 détermine en S50 si [a transaction courante TR1 est réalisée 25 par contact. Dans la négative (réalisation sans contact), la carte à puce 2 détecte (58) que l'enregistrement 512 à venir des nouvelles données d'historisation DH dans le premier fichier d'historisation LG1 n'est pas critique et procède par conséquent directement à l'étape 512 d'enregistrement de façon identique à ce qui est décrit précédemment en référence aux figures 4 et 5. 30 Si, en revanche, la carte à puce 2 détermine en S50 que la transaction courante TR1 est réalisée par contact avec le terminal T, alors la carte à puce 2 procède à l'étape 552 de détermination au- cours de laquelle elle détecte systématiquement que l'enregistrement S12 à venir est critique si la condition suivante est remplie détection que ledit enregistrement 512 des nouvelles données d'historisation DH 35 selon le premier format FT1 dans le premier fichier d'historisation LG1 conduit ledit fichier LG1 à contenir un nombre, supérieur ou égal à une valeur seuil k prédéterminée, d'entrées RC de transactions satisfaisant une deuxième condition temporelle CD2. Si cette dernière condition CD2 est remplie, cela signifie qu'il existe un nombre trop important 28 k) d'entrées pertinentes dans le premier fichier d'historisation LG1 et qu'il y a donc un risque qu'il ne soit plus possible pour les nouvelles données d'historisation transaction ultérieure réalisée en sans contact d'être stockées dans le premier fichier d'historisation LG1 sans déclencher le mécanisme de sauvegarde (510) tout en évitant la 5 perte d'anciennes données d'historisation pertinentes. Autrement dit, le blocage systématique du -mécanisme de sauvegarde 510 dans le cas des transactions par contact risque alors de causer la suppression d'anciennes données d'historisation pertinentes dans le premier fichier d'historisation LG1. Dans un exemple particulier, la deuxième condition temporelle CD2 est identique à la 10 première condition temporelle CD1 telle que précédemment décrite. Si l'enregistrement 512 à venir est détecté comme étant critique en 552 (figure 8), la carte à puce 2 réalise l'étape 510 de transfert d'anciennes données d'historisation depuis le premier fichier LG1 dans le deuxième fichier LG2 selon le format FT2, puis réalise l'étape S12 d'enregistrement des- nouvelles données d'historisation DH -de la 15 transaction courante TR1 dans le premier fichier LG1, de façon identique à ce qui est décrit précédemment en référence aux figures 4 et 5. Pour ce faire, la carte à puce 2 réalise par exemple les étapes S24 et 526 comme déjà décrites en référence à la figure 5. Si, .en revanche, l'enregistrement 512 à venir est détecté comme n'étant pas critique 20 en 552 (condition temporelle CD2 par remplie), alors la carte à puce 2 procède directement à l'étape 512 d'enregistrement de façon identique à -ce qui est décrit précédemment en référence aux figures 4 et 5. Par ailleurs, -comme indiqué précédemment, la figure 9 représente la vérification réalisée par la carte à puce 2 pour déterminer en 522 (figure 6 et 7A-713) si la première 25 condition temporelle CD1 est remplie, selon un exemple de réalisation particulier. Au cours d'une étape 540 de détermination, la carte à puce 2 détermine, partir des données de transaction IDTR reçues en S4, l'instant courant PC caractérisant la transaction courante TR1. La carte à puce 2 calcule (542) ensuite un deuxième instant PA2 antérieur à l'instant 30 courant PC, ce deuxième instant PA2 :correspondant au début de la période de temps PD prédéfinie. Ce calcul S-4-12 est réalisé à partir de l'instant courant PC et de la -durée prédéfinie attribuée à ladite période de temps PD prédéfinie (PA2 - PC - PD). La carte à -puce 2 détecte (544) que le premier instant PAl. caractérisant la transaction TR2 se trouve dans la période de temps PD s'il est postérieur au deuxième 35 instant PA2 marquant le début de la période PD. 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 REVENDICATIONS1. Procédé de traitement mis en oeuvre par un dispositif électronique (2) apte à traiter des transactions, ledit procédé comprenant : - réception de données de transaction (DN) en provenance d'un terminal (T) avec lequel le dispositif électronique coopère pour traiter une transaction (TR1) courante ; obtention, à partir des données de transaction reçues, de nouvelles données 10 d'historisation représentatives de la transaction courante ; et - enregistrement des nouvelles données d'historisation selon un premier format (FT1) de données en tant que nouvelle entrée (RC) dans un premier fichier d'historisation (LG1) ; dans lequel, préalablement audit enregistrement, le procédé comprend : 15 vérification que ledit enregistrement remplit au moins une condition prédéterminée indiquant que ledit enregistrement est critique vis-à-vis d'anciennes données d'historisation stockées en tant que précédente entrée (RC) dans le premier fichier d'historisation (LG1) ; et - dans l'affirmative, transfert des anciennes données d'historisation dans un 20 deuxième fichier d'historisation (LG2) selon un deuxième format (FT2) de données, réduit en taille par rapport au premier format (FT1) de données. 2. Procédé selon la revendication 1, dans lequel le deuxième format de données est réduit en ce qu'il autorise l'enregistrement d'une quantité inférieure de données par 25 rapport au premier format de données. 3. Procédé selon la revendication 2, dans lequel le premier format de données définit une pluralité de types de données à enregistrer tandis que le deuxième format de données définit une sélection parmi ladite pluralité de types de données excluant au 30 moins l'un parmi ladite pluralité de types de données. 4. Procédé selon l'une quelconque d. s revendications 1 à 3, dans lequel kulite vérification comprend : détermination que l'enregistrement des nouvelles données d'historisation selon le 35 premier format de données dans le premier fichier d'historisation conduit à un écrasement d'une précédente entrée (RC), représentative d'une précédente transaction, déjà enregistrée dans le premier fichier d'historisation (LG1) selon le premier format (FT1) de données ; et 31 détection que l'enregistrement est critique si la précédente transaction, définie par la précédente entrée dans le premier fichier d'historisation (LG1), remplit une première condition temporelle (CD). 5. Procédé selon la revendication 4, dans lequel la première condition temporelle est remplie si un instant antérieur (PA1) au cours duquel a été réalisée la précédente transaction (TR2) selon ladite précédente entrée se trouve dans une période de temps (PD)' d'une durée prédéfinie, terminant à un instant courant au cours duquel est réalisé ou a été réalisé la transaction courante (TR1). 10 6. Procédé selon la revendication 5, dans lequel ladite vérification comprend : détermination, à partir des données de transaction (DH) reçues, de l'instant courant (PC) caractérisant la transaction courante (TR1) ; et calcul d'un deuxième instant antérieur (PA2) correspondant au début de la 15 période de temps (PD), à partir de l'instant courant (PC) et de la durée prédéfinie attribuée à ladite période de temps, le premier instant antérieur (PA1) se trouvant dans la période de temps (PD) s'il est postérieur au deuxième instant antérieur (PA2). 20 7. Procédé selon L'une quelconque des revendications 1 à 6, comprenant, préalablement audit enregistrement des nouvelles données d'historisation selon le premier format de données dans le deuxième fichier d'historisation : sélection, parmi des types de données d'historisation (DH1-DH6) définis par le premier format (FT1) de données, d'un sous-ensemble (DH1, DH2, DH6) de 25 types de données d'historisation conformément à au moins une règle de sélection (RL) prédéfinie ; et conversion des anciennes données d'historisation (DH) selon le deuxième format (FT2) de données en vue d'être transférées dans le deuxième fichier d'historisation (LG2), dans laquelle seulement le ou les types de données 30 .d'historisation sélectionnés sont conservés dans les anciennes données d'historisation lors de ladite conversion. 8. Procédé selon la revendication 7, dans lequel, préalablement à ladite sélection, le second fichier d'historisation (LG2) comprend déjà au moins une entrée (RD) sauvegardée 35 selon le deuxième format (FT2) de données, ladite entrée sauvegardée étant représentative d'une précédente transaction antérieure à la transaction courante (TR1), et dans lequel, lors de ladite sélection, le dispositif électronique (2) sélectionne un premier type de données d'historisation prédéfini seulement si la plus récente entrée 32 sauvegardée dans le second fichier d'historisation comportant le premier type de donnée d'historisation spécifie, pour ledit premier type de données d'historisation, une valeur différente de celle définie par ladite précédente entrée (RC). 9. Procédé selon l'une quelconque des revendications 1 à 8, dans lequel, lors de ladite vérification, le dispositif électronique détecte systématiquement que l'enregistrement n'est pas critique si la transaction courante est une transaction sans contact. 10. Procédé selon la revendication 9, dans lequel, si la transaction courante est une transaction par contact .avec le terminal, le dispositif électronique détecte systématiquement lors ladite vérification que l'enregistrement est critique si la condition suivante est remplie : détection que ledit enregistrement des nouvelles données d'historisation selon le premier format (FT1) de données dans le premier fichier d'historisation (LG1) conduit le premier fichier d'historisation (LG1) à contenir un nombre, supérieur ou égal à une valeur seuil prédéterminée, d'entrées de transactions satisfaisant une deuxième condition temporelle. 11. Procédé selon l'une quelconque des revendications t à 10, dans lequel s'il est détecté lors de ladite vérification que ledit enregistrement n'est pas critique, le dispositif électronique ne transfert pas les anciennes données d'historisation dans le deuxième fichier d'historisation (LG2) selon le deuxième format (FT2) de données préalablement audit enregistrement. 12. Procédé selon l'une quelconque des revendications 1 à 11, le dispositif électronique détecte lors de ladite vérification que ledit enregistrement est critique uniquement sur détection que la transaction courante (TRI) est passée avec succès. 13. Procédé selon l'une quelconque des revendications 1 à 12, comprenant, après ledit transfert des anciennes données d'historisation selon le deuxième format (FT2) de données dans le deuxième fichier d'historisation (LG2) : conversion des anciennes données d'historisation depuis le deuxième format de données dans un format modifié à partir du contenu d'une précédente entrée dans le deuxième fichier d'historisation (LG2) ; et transmission des anciennes données d'historisation dans le format modifié de données à un terminal. 33 14. Programme d'ordinateur (PG1) comportant des instructions pour l'exécution des étapes d'un procédé de traitement selon l'une quelconque des revendications 1 à 13 lorsque ledit programme est exécuté par un ordinateur. Dispositif électronique apte à traiter des transactions, comprenant : un module de réception (MD2) configurés pour recevoir des données de transaction (DN) en provenance d'un terminal (T) avec lequel le dispositif électronique coopère pour traiter une transaction (TR1) courante ; un module d'obtention configuré pour obtenir, à partir des données de 10 transaction reçues, de nouvelles données d'historisation à enregistrer en tant que nouvelle entrée (RC) dans le dispositif électronique, lesdites nouvelles données d'historisation étant représentatives de la transaction courante ; et un module d'enregistrement configuré pour enregistrer les nouvelles données d'historisation selon un premier format (FT1) de données dans un premier fichier 15 d'historisation (LG1) ; le dispositif comprenant en outre : un module de vérification configuré pour vérifier, préalablement à l'enregistrement par le module d'enregistrement des nouvelles données d'historisation selon le premier format (FT1) de données dans le premier fichier 20 d'historisation (LG1), que ledit enregistrement remplit au moins une condition prédéterminée indiquant que ledit enregistrement est critique vis-à-vis d'anciennes données d'historisation stockées en tant que précédente entrée (RC) dans le premier fichier d'historisation (LG1) ; et un module de sauvegarde configuré, si l'enregistrement est détecté comme étant 25 critique par le module de vérification, pour transférer les anciennes données d'historisation dans un deuxième fichier d'historisation (LG2) selon un deuxième format .(FT2) de données, réduit en taille par rapport au premier format (F1) de données.