Brevet FR3078187A1 — publié le 20190823

Arrière-pian de l'invention L'invention se rapporte au domaine des systèmes de paiement utilisant une monnaie cryptographique (ou eryptomonnaie), c'est-à-dire une monnaie virtuelle utilisable sur un réseau informatique décentralisé (de pair à pair) et faisant appel à des mécanismes 10 cryptographiques. L'invention concerne plus particulièrement la gestion d'un porte-monnaie virtuel permettant la réalisation de transactions dans une monnaie cryptographique. Une monnaie virtuelle de type cryptographique bien connue à ce jour est le « bitcoin » qui s'appuie sur un système de paiement pair-à-pair dénommé Bitcoin. Le 15 système Bitcoin permet de faire des transactions de compte à compte, grâce à des logiciels appelés porte-monnaie virtuel (ou « wallet » en anglais) mis en oeuvre dans des dispositifs de traitement appropriés (smartphones, ordinateurs...). La validité de chaque transaction est vérifiée par des terminaux (ou logiciels) de vérification appelés « mineurs », les transactions une fois validées étant inscrites dans un registre public 20 appelé chaîne de blocs (ou « blockchain » en anglais) en raison de sa structure constituée d'une série de blocs. Chaque bloc définit des transactions validées par les mineurs et fait référence à des transactions antérieures. Un porte-monnaie virtuel permet en particulier de créer un compte et de réaliser des transactions en bitcoin avec un compte tiers. Lors d'une transaction de paiement par 25 exemple, le compte du porte-monnaie virtuel est débité d'un certain montant en bitcoin .pour en créditer le compte tiers. Un porte-monnaie virtuel peut stocker des données (ou entrées) correspondant à d'anciennes transactions dont le porte-monnaie virtuel a été le bénéficiaire (le destinataire). Ces données, appelées « entrées » ou « entrées de transaction », 30 constituent de la valeur disponible en bitcoin dont l'utilisateur du porte-monnaie est propriétaire. A partir de ses entrées de transaction, le porte-monnaie virtuel peut générer des « sorties » ou « sorties de transaction » définissant des montants en bitcoin transférés lors de transactions de paiement depuis le compte de l'utilisateur vers des 2 comptes de tiers destinataires. Chaque sorte de transaction définit un montant de la transaction et la clé publique du compte tiers qui est crédité. En outre, chaque compte est associé à une paire de clés cryptographiques comprenant une clé publique et une clé privé. Pour réaliser des transferts, un porte- monnaie virtuel doit signer ses transactions à l'aide d'au moins une clé privée. Les transactions ainsi effectuées sont diffusées à des terminaux de vérification (mineurs) qui valident les transactions qu'ils reçoivent et les regroupent progressivement avant de les enregistrer sous formes de blocs dans la chaîne de blocs. Le réseau de mineurs vérifie en particulier la validité de la signature de chaque transaction à partir de la clé publique correspondant au compte débiteur, en s'appuyant sur un mécanisme de cryptographie asymétrique. Lors de cette opération de vérification les mineurs assemblent les transactions en bloc en y adjoignant un en-tête comportant des indications particulières (date, heure, somme de contrôle ou « hash »...).. L'inscription dans a chaîne de blocs d'une nouvelle -transaction (sortie de transaction) a pour effet d'interdire toute utilisation ultérieure des entrées de transaction à partir desquelles la nouvelle transaction a été réalisée, ce qui revient à débiter les comptes des payeurs et de créditer les comptes des destinataires. Les vérifications réalisées par les terminaux de vérification !ors des opérations de minage pour valider chaque transaction nécessitent du temps de traitement et des ressources particulières. Lors d'une transaction, le tiers destinataire doit donc attendre un temps minimal de traitement (de 10 minutes à 1 heure, par exemple) à compter du moment de la transaction pour s'assurer que la transaction est bien validée. Si le tiers 'attend pas que la transaction soit confirmée pour délivrer sa contrepartie (portant par exemple sur un bien ou service), il prend le risque de ne pas être payé. Ce temps d'attente présente un problème dans certaines transactions, notamment celles réalisées dans la vie courante. En outre, le délai d'attente nécessaire à la réalisation de ce processus de validation et d'inscription présente un risque dans la mesure où ce délai peut être exploité pour réaliser une attaque dite de « double paiement ». Cette attaque, pouvant être réalisée par un tiers malveillant, consiste à dépenser plusieurs fois de la même monnaie (ou argent) cryptographique avant que la validation d'une première transaction ait eu lieu, afin par exemple d'obtenir plusieurs biens ou services- auprès de marchands différents. Dans ce cas de figure, un seul parmi les destinataires potentiels est finalement payé(celui pour lequel le processus de validation et d'inscription est achevé le plus vite). Ces risques de non-paiement contraignent les tiers destinataires à attendre le délai de traitement nécessaire pour obtenir confirmation que la transaction est bien validée. Ce temps d'attente présente un inconvénient pour les utilisateurs. Les risques liés aux problèmes de double-paiement diminuent en outre la confiance des utilisateurs envers le système Bitcoin. Par ailleurs, lorsqu'une transaction de paiement est réalisée par un porte-monnaie virtuel, un problème peut se poser lorsqu'une panne ou une difficulté technique survient au niveau notamment du terminal du tiers destinataire avant que la transaction ait été validée et inscrite dans la chaîne de blocs. Dans une telle situation, les entrées de 10 transaction utilisées pour la transaction sont bloquées et ne peuvent plus servir bien que le paiement n'ait pas réellement eu lieu. Il n'existe pas aujourd'hui de système satisfaisant permettant de palier les problèmes et inconvénients exposés ci-dessus. En particulier, il existe un besoin pour une solution permettant de sécuriser les transactions réalisées dans une monnaie cryptographique telle 15 que le bitcoin ou autre, et notamment pour éviter le phénomène du double-paiement et permettre des transactions plus rapides entre les parties. Un besoin existe en outre pour gérer une situation dans laquelle une difficulté technique survient lors d'une transaction, empêchant celle-ci d'aboutir. 20 Objet et résumé de l'invention A cet effet, la présente invention concerne un procédé de contrôle d'un porte-monnaie virtuel, mis en oeuvre dans un dispositif de traitement apte à réaliser des transactions dans une monnaie cryptographique, le dispositif de traitement stockant dans une mémoire au moins une entrée de transaction définissant une transaction dont le 25 porte-monnaie virtuel a été le bénéficiaire, le procédé comprenant traitement d'une transaction en cours, comportant une génération, à partir d'au moins une entrée de transaction, d'une sortie de transaction définissant la transaction en cours entre le dispositif de traitement et un terminal tiers ; 30 le procédé comprenant en outre : conservation en mémoire d'au moins un paramètre représentatif d'un statut d'une entrée de transaction associée stockée dans ladite mémoire, le paramètre étant fixé initialement à une première valeur tant que ladite entrée de transaction 4 associée n'est pas utilisée par le porte-monnaie virtuel lors du traitement d'une transaction pour générer une sortie de transaction ; sur détection que ladite entrée de transaction associée est utilisée par le porte-monnaie pour générer une sortie de transaction, modification du statut de ladite entrée de transaction associée en affectant audit paramètre une deuxième valeur différente de la première valeur pour indiquer que iadite entrée de transaction associée est dépensée ; dans lequel, ledit traitement de la transaction en cours comprend une vérification du paramètre d'une entrée de transaction associée, cette dernière étant utilisée 10 dans la génération de la sortie de transaction seulement si ledit paramètre est fixé à la première valeur indiquant que ladite entrée de transaction associée n'est pas dépensée. L'invention permet avantageusement à un dispositif de traitement, telle qu'une carte à puce par exemple, de contrôler le statut des entrées de transaction stockées dans sa 15 mémoire de sorte à déterminer les entrées de transaction qui ont été dépensées et celles qui sont toujours disponibles pour réaliser une transaction de paiement. En affectant une première valeur ou une deuxième valeur aux paramètres de statut de chaque entrée de transaction, le dispositif de traitement peut distinguer les entrées de transaction dépensées de celles qui ne le sont pas. 20 L'invention permet en outre au dispositif de traitement de bloquer toutes les entrées de transaction qui ont été dépensées lors d'une transaction mais qui sont toujours présentes dans la mémoire. De cette manière, le dispositif de traitement ne peut dépenser plusieurs fois de l'argent correspondant à une même entrée de transaction, en particulier dans la période nécessaire à la réalisation du processus de validation et 25 d'inscription par le réseau de mineurs. Une fois une transaction inscrite dans la chaîne de blocs, une synchronisation du dispositif de traitement avec un serveur peut causer la suppression, dans la mémoire, de la ou des entrées de transaction dépensées. L'invention permet ainsi de lutter contre le phénomène de double-paiement déjà décrit précédemment et ainsi sécuriser les transactions de paiement. 30 Selon un mode de réalisation particulier, le procédé comprend : - première synchronisation avec un serveur distant, comprenant une réception d'un premier indicateur temporel représentatif d'un premier instant associée à la première synchronisation ; et - affectation, au paramètre d'au moins une première entrée de transaction indiquée comme dépensée, d'une troisième valeur représentative du premier instant et différente des première et deuxième valeurs. Selon un mode de réalisation particulier, le procédé comprend : 5 - deuxième synchronisation, postérieure à la première synchronisation, avec un serveur distant, comprenant une réception d'un deuxième indicateur temporel représentatif d'un deuxième instant associé à la deuxième synchronisation ; sur détection que le paramètre de la première entrée de transaction a une troisième valeur différente des première et deuxième valeurs, détermination à 10 partir de la troisième valeur et du deuxième indicateur temporel, de si l'intervalle de temps entre le premier instant et le deuxième instant atteint une durée limite prédéterminée ; et dans l'affirmative, modification du statut de ladite première entrée de transaction en affectant au paramètre associé ladite première valeur indiquant que ladite 15 première entrée de transaction n'est pas dépensée. Selon un mode de réalisation particulier, la durée limite prédéterminée est déterminée à partir d'un paramètre compris dans la première entrée de transaction ou dans une sortie de transaction générée à partir de ladite première entrée de transaction. Selon un mode de réalisation particulier, le procédé comprend : 20 une synchronisation avec un serveur distant, comprenant une réception de données de mise à jour ; et - sur détection, à partir des données de mise à jour, qu'une entrée de transaction n'est plus valide, le dispositif de traitement supprime ladite entrée de transaction non valide de la mémoire. 25 Selon un mode de réalisation particulier, le procédé comprend : lors de la deuxième synchronisation, une réception de données de mise à jour ; et - sur détection, à partir des données de mise à jour, que ladite première entrée de transaction n'est plus valide, le dispositif de traitement supprime ladite première entrée de transaction de la mémoire. 30 Selon un mode de réalisation particulier, dans lequel la monnaie cryptographique est le bitcoin. Selon un mode de réalisation particulier, au cours du traitement de la transaction en cours, le dispositif de traitement s'authentifie auprès du terminal tiers en envoyant une 6 réponse déterminée à partir d'une donnée de défi préalablement reçue dudit terminal tiers. Selon un mode de réalisation particulier, la réponse comprend une signature d'un message comportant la donnée de défi. Dans un mode particulier de réalisation es différentes étapes du procédé de contrôle sont déterminées. par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programn-ie d'ordinateur sur un support d'informations .(ou support d'enregistrement), ce programme étant susceptible d'être mis en oeuvre dans un dispositif de: traitement ou plus généralement dans un ordinateur, ce 10 programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un. procédé de contrôle tel que défini ci-dessus. 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 15 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 20 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 25 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 30 l'exécution du procédé en question. L'invention concerne également un dispositif de traitement configuré pour contrôler un porte-monnaie virtuel destiné à réaliser des transactions dans une monnaie cryptographique, comprenant 7 un module de stockage configuré pour stocker au moins une entrée de transaction définissant une transaction dont le porte-monnaie virtuel a été le bénéficiaire ; un module de traitement d'une transaction en cours, configuré pour générer, à partir d'au moins une entrée de transaction, une sortie de transaction définissant la transaction en cours entre le dispositif de traitement et un terminal tiers ; le dispositif de traitement comprenant en outre : un module de gestion configuré pour conserver en mémoire au moins un paramètre représentatif d'un statut d'une entrée de transaction associée, le paramètre étant fixé initialement à une première valeur tant que ladite entrée de 10 transaction associée n'est pas utilisée par le module de traitement lors du traitement d'une transaction pour générer une sortie de transaction, le module de gestion étant configuré, sur détection que ladite entrée de transaction associée est utilisée par le porte-monnaie pour générer une sortie de transaction, pour modifier le statut de ladite entrée de transaction associée en 15 affectant audit paramètre une deuxième valeur différente de la première valeur pour indiquer que ladite entrée de transaction associée est dépensée ; dans lequel, ledit module de traitement est configuré pour vérifier le paramètre d'une entrée de transaction associée et pour utiliser cette dernière dans la génération de la sortie de transaction seulement si ledit paramètre est fixé à la première valeur indiquant 20 que ladite entrée de transaction associée n'est pas dépensée. On notera que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé de contrôle de l'invention ainsi que les avantages associés s'appliquent de façon analogue au dispositif de traitement de l'invention. Selon un mode de réalisation particulier, le dispositif de traitement comprend un 25 module de synchronisation configuré pour réaliser une première synchronisation avec un serveur distant, au cours de laquelle le dispositif de traitement reçoit un premier indicateur temporel représentatif d'un premier instant associée à la première synchronisation ; le module de gestion étant configuré pour affecter, au paramètre d'au moins une 30 première entrée de transaction indiquée comme dépensée, une troisième valeur représentative du premier instant et différente des première et deuxième valeurs. Selon un mode de réalisation particulier, le module de synchronisation est configuré pour réaliser, postérieurement à la première synchronisation, une deuxième synchronisation avec un serveur distant, au cours de laquelle le dispositif de traitement reçoit un deuxième indicateur temporel représentatif d'un deuxième instant associé à deuxième synchronisation le module de gestion étant configuré pour sur détection que le paramètre de la première entrée de transaction a une troisième valeur différente des première et deuxième valeurs, déterminer à partir de la troisième valeur et du deuxième indicateur temporel, si l'intervalle de temps entre le premier instant et le deuxième instant atteint une durée limite prédéterminée ; et dans l'affirmative, modifier le statut de ladite première entrée de transaction en 10 affectant au paramètre associé ladite première valeur indiquant que ladite première entrée de transaction n'est pas dépensée, Selon un mode de réalisation particulier, le module de synchronisation détermine la durée limite prédéterminée à partir d'un paramètre compris dans la première entrée de transaction ou dans une sortie de transaction générée à partir de ladite première entrée 15 de transaction. Selon un mode de réalisation particulier, le dispositif de traitement comprend un module de synchronisation configuré pour réaliser une synchronisation avec un serveur distant, au cours de laquelle le dispositif de traitement reçoit des données de mise à jour ; dans lequel le module de gestion est configuré pour détecter, à partir des données 20 de mise à jour, qu'une entrée de transaction n'est plus valide ; et dans lequel le module de stockage est configuré pour supprimer ladite entrée de transaction non valide dc la mémoire. Selon un mode de réalisation particulier, le module de synchronisation -est configure,. lors de la deuxième.synchronisation, pour recevoir des données de mise à jour ; et 25 sur détection, à partir des données de mise à jour, que ladite première entrée de transaction n'est plus valide; le module de stockage est configuré pour supprimer ladite première entrée de transaction de la mémoire. 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 30 correspondre dans ce document aussi bien à un composant logiciel, qu'a un composant matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit 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 logiciel, par exemple un circuit intégré, une carte à puce, etc. Brève description des dessins 10 D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures: - la figure 1 représente schématiquement un environnement comprenant un dispositif de traitement selon un mode de réalisation particulier de l'invention ; 15 - la figure 2 représente schématiquement la structure d'un dispositif de traitement selon un mode de réalisation particulier de l'invention ; - la figure 3 représente, sous forme d'un organigramme, les étapes d'un procédé de traitement selon un mode de réalisation particulier de l'invention ; - la figure 4 représente, sous forme d'un organigramme, les étapes d'un procédé 20 de traitement selon un mode de réalisation particulier de l'invention ; - la figure 5 représente, sous forme d'un organigramme, les étapes d'un procédé de traitement selon un mode de réalisation particulier de l'invention ; et - la figure 6 représente, sous forme d'un organigramme, les étapes d'un procédé de traitement selon un mode de réalisation particulier de l'invention. 25 Description détaillée de plusieurs modes de réalisation Comme indiqué précédemment, l'invention se rapporte aux systèmes de paiement utilisant une monnaie cryptographique (ou cryptomonnaie). De façon bien connue, une monnaie virtuelle est utilisable sur un réseau informatique décentralisé (de pair à pair) 30 pour réaliser des transactions de compte à compte à l'aide de clés cryptographiques associées aux comptes des utilisateurs. L'invention concerne plus particulièrement la gestion d'un porte-monnaie virtuel permettant la réalisation de transactions dans une monnaie cryptographique. Dans ce document, des modes de réalisation de l'invention sont décrits dans le cadre du système 10 Bitcoin bien connu de l'homme du métier et dont certaines caractéristiques ont été rappelées ci-avant. On comprend toutefois que l'invention ne s'applique pas exclusivement aux porte-monnaie virtuels utilisant la monnaie bitcoin et peut s'appliquer plus généralement à tous types de porte-monnaie virtuel utilisant une quelconque 5 monnaie cryptographique. L'invention propose notamment un procédé de control (ou procédé de gestion) d'un porte-monnaie virtuel dans un dispositif de traitement apte à réaliser des transactions, et vise en particulier la gestion des entrées de transaction stockées dans le dispositif de traitement et susceptibles d'être utilisées par le porte-monnaie virtuel pour réaliser une 10 transaction avec un tiers. Pour ce faire, l'invention propose, selon différents modes de réalisation, de conserver en mémoire un paramètre respectif représentant un statut de chaque entrée de transaction stockée dans le dispositif de traitement, ce paramètre étant fixé à une première valeur tant que l'entrée de transaction associée n'est pas utilisée (Le. pas dépensée) pour réaliser une transaction et fixé à une deuxième valeur lorsque ladite 15 entrée de transaction est utilisée (i.e. dépensée) lors d'une transaction. Ainsi, chaque entrée de transaction stockée dans le dispositif de traitement dont le paramètre associé est fixé à la deuxième valeur est bloquée de sorte qu'elle ne puisse pas être utilisé,- par le porte-monnaie virtuel pour réaliser une nouvelle transaction. L'invention vise également un dispositif de traitement correspondant, ainsi qu'un 20 programme d'ordinateur correspondant. D'autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. 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 25 analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. La figure 1 représente, de manière schématique, un environnement E comprenant un dispositif de traitement DV1, un terminal DV2, un serveur distant SV et un réseau 20, conformément à un mode de réalisation particulier de l'invention. 30 Dans cet exemple, le dispositif de traitement DV1 est une carte à puce bien que d'autres types de dispositif de traitement soient possibles. En variante, le dispositif de traitement DV1 peut être un quelconque dispositif apte à réaliser le procédé de traitement décrit ci-après, tel que par exemple un mobile multifonction (ou « smartphone »), un ordinateur, une tablette etc. 11 Dans un exemple particulier, la carte à puce DV1 est une carte EMV, telle qu'une carte de paiement par exemple. Dans l'exemple de réalisation décrit ici, un utilisateur Ul utilise sa carte à puce DV1 pour réaliser des transactions avec des tiers dans la monnaie cryptographique bitcoin bien connue de l'homme du métier. On suppose ici que l'utilisateur U1 réalise par exemple une transaction avec un utilisateur tiers U2, représentant par exemple un marchand. Pour ce faire, la carte à puce DV1 coopère avec le terminal (ou lecteur) DV2 de l'utilisateur U2 afin d'échanger des données nécessaires à l'exécution de la transaction. Plus précisément, la carte à puce DV1 comprend dans cet exemple des contacts 10 externes 1 configurés pour coopérer avec le terminal DV2, un processeur 2, un porte- monnaie-virtuel 4 mis en oeuvre par le processeur 2, une mémoire volatile réinscriptible RAM) 6 et une mémoire non volatile réinscriptible M1 (de type Flash par exemple). La mémoire non-volatile M1 constitue dans cet exemple un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par la 15 carte à puce DV1, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG1 comporte des instructions pour l'exécution des étapes d'un procédé de contrôle 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. 20 Comme décrit par la suite, le processeur 2 est piloté par le programme PG1 pour mettre en oeuvre le porte-monnaie virtuel 4 destiné à réaliser un procédé de traitement conforme à l'invention. Ce porte-monnaie virtuel 4 peut permettre en particulier de créer un compte de l'utilisateur Ul et de réaliser des transactions en monnaie cryptographique bitcoin avec un compte de l'utilisateur tiers U2. Lors d'une transaction de paiement par 25 exemple, le compte du porte-monnaie virtuel 4 est débité d'un certain montant en bitcoin pour en créditer le compte du tiers U2. On suppose ici que l'environnement E est un environnement conforme ou compatible au système Bitcoin, bien que d'autres exemples soient possibles. Dans un exemple particulier, la carte à puce DV1 est conforme à la norme ISO 7816. 30 Dans ce cas, les contacts externes 1 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 DV1 peut par exemple être configurée pour coopérer avec le terminal DV2 en mode sans contact via une antenne RF (non représentée) intégrée dans la carte DV1. 12 Dans l'exemple considéré ici, la mémoire non volatile réinscriptible M1 est configurée pour stocker une paire de clés cryptographiques associées au compte de l'utilisateur Ul, cette paire comprenant une clé publique PK1 et une clé privée SK1 complémentaire. Le porte-monnaie virtuel 4 peut utiliser la clé privé SK1 du compte de l'utilisateur U1 pour signer des données de transaction avant envoi au tiers destinataire U2. Dans un mode d'implémentation, la paire de clé PK1 /SK1 n'est pas stockée dans la mémoire MI. mais calculée à la volée par le porte-monnaie virtuel 4, à partir d'une donnée (appelée « graine », ou « seed » en anglais) qui est stockée dans la mémoire Ml. A noter que le porte-monnaie virtuel 4 peut comporter plusieurs comptes d'utilisateur. 10 Dans ce cas, les données de transaction générées pour chaque transaction sont signées en utilisant la clé privée de chaque compte utilisé. Comme indiqué ci-avant, chaque paire de clés peut être stockée à l'avance dans la mémoire M1 ou calculée à la volée à partir d'une graine stockée dans la mémoire Ml. La mémoire M1 est également configurée pour stocker une ou des entrées de 15 transaction (ou entrées), chacune d'elles correspondant à une ancienne transaction dont le porte-monnaie virtuel 4 a été le bénéficiaire (le destinataire) dans le passé. Ces entrées de transaction TI constituent de la valeur disponible en bitcoin dont l'utilisateur U1 est propriétaire. Ces entrées de transaction TI peuvent être reçues par le porte-monnaie virtuelle 4 en provenance d'une entité tierce, le serveur SV par exemple, pouvant 20 correspondre à un organisme émetteur de la carte DV1, à un fournisseur de services ou autre. A partir des entrées de transaction TI stockées dans la mémoire M1, le porte-monnaie virtuel 4 peut générer des sorties de transaction TO définissant des transactions de transfert en bitcoin depuis le compte de l'utilisateur U1 du porte-monnaie 4 vers au 25 moins un compte du tiers destinataire U2 et son terminal DV2. Ces sorties de transaction TO peuvent être transmises par la carte à puce DV1 au terminal DV2 lors d'une transaction de paiement. Comme représenté en figure 1, on suppose ici que la carte à puce DV1 stocke dans sa mémoire M1 des entrées de transaction Tli, TU et TI3 (notées collectivement -n). 30 Chaque entrée de transaction -"n est constituée d'un groupe de données caractérisant une ancienne transaction dont l'utilisateur U1 a été bénéficiaire. Dans cet exemple, les entrées de transaction TI comprennent un identifiant d'une transaction passée dont l'utilisateur U1 a été le bénéficiaire, une adresse du compte de l'utilisateur Ul (égale ou comprenant la clé publique PK1) et un montant en bitcoin de la transaction. 13 Chaque sortie de transaction TO générée par la carte à puce DV1, et plus précisément par le porte-monnaie virtuel 4 comporte par exemple un montant de la transaction et la clé publique du compte de l'utilisateur tiers qui est le bénéficiaire de la transaction. Le porte-monnaie 4 est configuré pour générer des données de transaction pouvant comprendre une ou plusieurs sorties de transaction TO et éventuellement d'autres données associées (par exemple, des informations relatives à une ou plusieurs entrées de transaction TI utilisés dont au moins un TI est associé à la clé publique PK1, un identifiant de transaction...). Ces données de transaction peuvent être signées par le porte-monnaie virtuel 4 à partir de la clé privée SK1 associée au compte de l'utilisateur Ul 10 qui est utilisé pour réaliser les transactions. Dans un exemple particulier, une transaction peut être réalisée à partir d'entrée de transaction 11 associés à des comptes d'utilisateur différents. Dans ce cas, les données de transaction sont signées avec chacune des clés privées associées à ces comptes. Dans l'exemple décrit ici, la mémoire M1 est également configurée pour stocker au 15 moins un paramètre SP, dit paramètre de statut, chaque paramètre SP étant représentatif d'un statut d'une entrée de transaction Ti associée stockée dans la mémoire Ml. Dans cet exemple, la mémoire M1 comporte un paramètre respectif SP1-SP3 pour chacune des entrées de transactions T11-T13. Comme expliqué par la suite, les paramètres SP sont initialement fixés à une 20 première valeur V1 tant que les entrées de transaction TI associées ne sont pas utilisées par le porte-monnaie virtuel 4 lors du traitement d'une transaction pour générer une sortie de transaction TO. Les paramètres de statut SP permettent au porte-monnaie virtuel 4 de suivre et contrôler le statut de chaque entrée de transaction TI, afin de déterminer en particulier si 25 celles-ci ont déjà été dépensées lors d'une transaction avec un tiers ou, au contraire, si elles sont toujours disponibles (non dépensées) pour être utilisées dans une transaction. Comme représenté en figure 1., le carte à puce DV1 est configurée pour communiquer avec le serveur distant SV afin notamment de faire des mises à jour régulières, comme décrit ultérieurement. Dans le cas présent où le dispositif de traitement 30 DV1 est une carte à puce, il peut communiquer avec le serveur SV via tout équipement approprié, tel que le terminal DV2 (lors du traitement d'une transaction, par exemple). En variante, le dispositif de traitement DV1 comprend des moyens de communication pour communiquer directement avec le serveur SV. 14 Le serveur SV, exécutant un programme d'ordinateur PG2, peut en particulier transmettre à la carte à puce DV1 au moins l'un parmi des données de mise à jour DM et un indicateur temporel TS associé. Les données de mise à jour DM renseignent la carte à puce DV1 sur les entrées de transaction TI dont l'utilisateur Ul, c'est-à-dire le compte de l'utilisateur U1, est propriétaire, à un instant donné qui est représenté par l'indicateur temporel TS. Par ailleurs, le terminal DV2 comprend en mémoire un programme d'ordinateur PG3 qu'il peut exécuter pour réaliser une transaction en bitcoin. Comme déjà expliqué, chaque transaction de paiement réalisée depuis l'utilisateur U1 10 en faveur de l'utilisateur U2 nécessite la validation préalable par des terminaux de vérification, appelés mineurs, disposés ici dans un réseau de mineurs 20. Le terminal DV2 est configuré pour transmettre au réseau 20 chaque sortie de transaction TO reçue de la carte à puce DV1 afin que les mineurs vérifient la validité de la transaction. Les mineurs (terminaux de vérification) valident les sorties de transaction TO qu'ils reçoivent et 15 regroupent progressivement les transactions avant de les enregistrer sous formes de blocs dans la chaîne de blocs du système Bitcoin. Ce processus est appelé dans ce document processus de validation et d'inscription. Lors de ce processus, le réseau de mineurs 20 vérifie en particulier la validité de la signature associée à chaque entrée de transaction TI utilisée pour générer la sortie de 20 transaction TO reçue, à partir de la clé publique PK1 de l'utilisateur U1. Comme indiqué par la suite, on suppose dans les exemples de réalisation qui suivent que toutes les entrées de transaction -rn à TI3 sont associées au même compte de l'utilisateur L11 (bien que d'autres exemples soient possibles dans lesquels ces entrées TI1-T13 sont associées à au moins deux comptes respectifs), et qu'au moins une sortie de transaction TO peut être 25 générée à partir de ces entrées 1I1 à 1I3. De façon connue, l'inscription par le réseau de mineurs 20 dans la chaîne de blocs d'une nouvelle sortie de transaction TO a pour effet d'interdire toute utilisation ultérieure de la ou des entrées de transaction TI à partir desquelles la nouvelle transaction a été réalisée, ce qui revient à débiter l'utilisateur Ul et créditer l'utilisateur U2 du montant défini dans la sortie de transaction TO. 30 Comme déjà expliqué, les vérifications réalisées par les terminaux de vérification dans le réseau 20 pour valider les transactions (c'est-à-dire les données de transaction représentant chaque transaction) nécessitent un temps de traitement qui peut être relativement long et qui peut poser problème notamment pour les utilisateurs Ul et U2. En outre, un risque existe pour le bénéficiaire U2 que l'utilisateur Ul tente d'utiliser les 15 mêmes entrées de transaction TI, dans un intervalle de temps restreint, pour réaliser plusieurs transactions distinctes, par exemple avec d'autres utilisateurs tiers (double paiement). A noter que l'environnement E, et plus particulièrement le dispositif de traitement DV1, représenté en figure 1 ne constitue qu'un exemple de réalisation, d'autres mises en oeuvre étant possibles dans le cadre de l'invention. L'homme du métier comprend en particuler que certains éléments du dispositif de traitement DV1 représenté en figure 1 ne sont décrits ici que pour faciliter la compréhension de l'invention, ces éléments n'étant pas nécessaires pour mettre en oeuvre l'invention. 10 Par ailleurs, dans l'exemple envisagé ici, le processeur 2 piloté par !e. programme d'ordinateur PG1 met en oeuvre un certain nombre de modules représentés en figure 2, à savoir : un module de stockage MD2, un module de traitement MD4, un module de gestion MD6 et, éventuellement, un module de synchronisation MD8. Le module de stockage MD2 est configure pour stocker dans la mémoire M1 au moins 15 une entrée de transaction TI définissant une transaction dont le porte-monnaie virtuel 4 est le bénéficiaire. Comme indiqué, on suppose ici que le module de stockage MD2 a stocké initialement les entrées de transaction 711, T2 et TI3 dans la mémoire Ml. Le 'nodule de traitement MD4 est configure pour traiter des transactions. Plus particulièrement, le module de traitement MD4 est configure pour traiter une transaction 20 en cours en générant, à partir d'au moins l'une des entrées de transaction TI1-T13, une sortie de transaction TO définissant la transaction en cours entre la carte à puce DV1 et le terminal tiers DV2. Le module de gestion MD6 est configure pour conserver en mémoire au moins un paramètre SP représentatif d'un statut d'une entrée de transaction II associée, ce 25 paramètre SP étant fixé initialement à une première valeur V1 tant que ladite entrée de transaction II associée n'est pas utilisée par le module de traitement MD4 ;ors du traitement d'une transaction pour générer une sortie de transaction TO. Le module de gestion MD6 est en outre configure, sur détection que ladite: entrée de transaction associée est utilisée par le porte-monnaie 4 pour générer une sortie de transaction TO, 30. pour modifier le statut de ladite entrée de transaction 11 associée en affectant audit paramètre SP une deuxième valeur V2 différente de la première valeur V1 pour indiquer que ladite entrée de transaction II associée est dépensée (c'est-à-dire « consommée » ou «utilisé » 16 Le module de traitement MD4 est en outre configuré pour utiliser une entrée de transaction TI dans la génération d'une sortie de transaction TO seulement si ledit paramètre SP associé est fixé à la première valeur V1 indiquant que ladite entrée de transaction TI associée n'est pas dépensée (c'est-à-dire « non consommé » ou « pas utilisée »). Pour ce faire, le module de traitement MD4 est configuré pour vérifier le paramètre SP d'au moins une entrée de transaction pour déterminer si celle-ci peut être utilisée pour générer une sortie de transaction TO. Par ailleurs, le module de synchronisation MD8 est configuré pour synchroniser si besoin le porte-monnaie virtuel 4 du dispositif DV1 avec un serveur distant, tel que le 10 serveur SV représenté en figure 1. par exemple. Au cours d'une synchronisation avec le serveur SV, le module de synchronisation MD8 est configuré pour recevoir des données de mise à jour DM et éventuellement un indicateur temporel TS, comme expliqué ultérieurement. Selon un exemple particulier, le module de synchronisation MD8 est configuré pour recevoir des données de mise à jour DM du serveur DV afin de déterminer 15 si ses entrées de transaction TI1-T13 sont toujours valides. Selon un exemp e particulier, le module de synchronisation MD8 est configuré pour réaliser une synchronisation avec un serveur distant tel que le serveur SV. Au cours d'une telle synchronisation, le dispositif de traitement (et plus particulièrement le module de synchronisation MD8) reçoit des données de mise à jour MD. Le module de gestion MD6 20 peut être configuré pour détecter, à partir des données de mise à jour DM reçues, qu'une entrée de transaction TI un par exemple) n'est plus valide. Le module de stockage MD2 peut en outre être configuré pour supprimer de la mémoire Ml la ou les entrées de transaction TI détectées comme non valides par le module de gestion MD6. Le fonctionnement et la configuration des modules MD2-MD8 du dispositif de 25 traitement DV1 apparaîtront plus précisément dans les exemples de réalisation décrits ci- après. A noter également que les modules MD2-MD8 tels que représentés en figure 2 ne constituent qu'un exemple de mise en oeuvre de l'invention. Un mode de réalisation particulier de l'invention est à présent décrit en référence à la figure 3. Plus précisément, le dispositif de traitement DV1 représenté en figures 1-2 30 exécute le programme d'ordinateur PG1 pour mettre en oeuvre un procédé de contrôle du porte-monnaie virtuel 4, selon un mode de réalisation particulier. On suppose que la carte à puce DV1 se synchronise régulièrement avec le serveur distant SV pour mettre à jour les entrées de transaction TI dont l'utilisateur U1, c'est-à-dire le compte de l'utilisateur U1, est le propriétaire à un instant courant selon la chaîne 17 de blocs. Dans cet exemple, la carte à puce DV1 reçoit lors d'une telle synchronisation les entrées de transaction T-I1-TI3 qu'elle enregistre (étape 52) dans sa mémoire Mi. A noter que d'autres manières sont possibles pour permettre à la carte à puce DV1 d'obtenir les entrées de transaction 111-113. Les entrées de transaction TI comprennent par exemple un identifiant d'une transaction passée dont l'utilisateur U1 a été le bénéficiaire, une adresse de l'utilisateur -U.1 (égale ou comprenant la clé publique PK1) et un montant en bitcoin de cette ancienne transaction en faveur de l'utilisateur Ul. Au cours d'une étape d'initialisation S4, la carte à puce DV1 génère et enregistre dans 10 la mémoire Ml, en association avec chaque entrée de transaction TI1-T13, un paramètre de statut SP respectif. La carie à puce DV1 initialise (54) chacun de ces paramètres SP en leur affecta-nt une première valeur V1. prédéhnie (V1 = 0 par exemple). Un paramètre SP fixé à la valeur V1 indique que l'entrée de transaction TI associée n'a pas été dépensée, c'est-à-dire qu'elle n'a pas encore été utilisée par la carte à puce DV1 pour générer une 15 sortie de transaction TO. La carte à puce DV1 conserve ainsi en mémoire les paramètres SP, ces paramètres étant fixés à la première valeur VI tant que l'entrée de transaction associée n'est pas utilisée par le porte-monnaie virtuel 4 lors du traitement d'une transaction pour générer une sortie de transaction TO. 20 Dans cet exemple, la carte à puce DV1 réalise ensuite un traitement 56 d'une transaction, notée TR1' avec un terminal tiers, à savoir le terminal DV2 dans ce cas. On suppose ici qu'il s'agit -d'une transaction de paiement d'un montant donné en bitcoin réalisée par l'utilisateur .U1 en tant que débiteur (ou payeur), à destination de l'utilisateur U2 en tant que créditeur (ou destinataire), Au cours de ce traitement 56, la carte à puce 25 DV1 réalise les étapes 58, 510 et 512 comme décrit ci-après. Au cours d'une étape de vérification S8, la carte à puce DV1 identifie au moins une entrée de transaction TI stockée dans la mémoire M1, qui est indiquée comme non utilisée, c'est-à-dire dont le paramètre de statut SP est fixé à la valeur initiale VI.. Dans l'exemple considéré ici, les entrées de transaction TI1, TU et 1I3 sont détectées comme 30 non dépensées et donc disponibles (SP = V1) pour réaliser un paiement. Au cours d'une étape de génération 510, la carte à puce DV1 génère, à partir d'au moins l'une des entrées de transaction TI non dépensées identifiées en S8, une sortie de transaction TO définissant la transaction en cours entre la carte à puce DV1 et le terminal 18 DV2. Cette sortie de transaction TO comporte par exemple un montant de la transaction en cours et la clé publique de l'utilisateur tiers qui est le bénéficiaire de cette transaction. Ainsi, les entrées de transaction TI stockées dans la mémoire M1 sont utilisées dans la génération (510) d'une sortie de transaction TO seulement si le paramètre SP 5 correspondant est fixé à la première valeur V1 indiquant que ladite entrée de transaction associée n'est pas dépensée. Au cours d'une étape de modification 512, sur détection qu'une entrée de transaction TI est utilisée en S10 pour générer une sortie de transaction TO, la carte à puce DV1 modifie le statut de cette entrée de transaction TI en affectant à son paramètre SP 10 associé une deuxième valeur prédéfinie V2 (V2 = -1 par exemple), différente de la première valeur V1, pour indiquer que l'entrée de transaction est dépensée et n'est donc plus disponible pour réaliser une nouvelle transaction. Autrement dit, la carte à puce DV1 bloque l'usage des entrées de transaction Ti qui ont été dépensées afin qu'elles ne puissent faire l'objet d'un double paiement. 15 Le processus de validation et d'inscription de la transaction TR1 en cours est ensuite réalisé par le réseau de mineurs 20 de façon conventionnelle comme déjà évoqué précédemment et n'est donc pas décrit en détail dans ce document par souci de simplicité. Une fois la transaction TR1 en cours validée, celle-ci est enregistrée par le réseau 20 dans la chaîne de blocs (registre) de sorte à être consultable notamment par le 20 serveur SV. Si la carte à puce DV1 détecte (514) qu'une nouvelle transaction de paiement est initiée, le procédé réalise une nouvelle itération du traitement 56, comprenant les étapes S8-510, comme déjà décrit ci-avant. Au cours de cette nouvelle itération de S6, la carte à puce DV1 détecte en particulier en S8 que la ou les entrées de transaction TI dont le 25 paramètre SP est à présent fixé à la valeur V2 sont bloquées et ne peuvent donc être utilisées en 510 pour générer une nouvelle sortie de transaction TO. L'invention permet avantageusement à un dispositif de traitement, telle que la carte à puce DV1, de contrôler le statut des entrées de transaction stockées dans sa mémoire de sorte à déterminer les entrées de transaction qui ont été dépensées et celles qui sont 30 toujours disponibles pour réaliser une transaction de paiement. En affectant des valeurs V1 ou V2 aux paramètres de statut de chaque entrée de transaction, le dispositif de traitement DV1 peut distinguer les entrées de transaction 11 dépensées de celles qui ne le sont pas. 1.9 L'invention permet en outre au dispositif de traitement DV1 de bloquer toutes les entrées de transaction Tl qui ont été dépensées lors d'une transaction mais qui sont toujours présentes dans la mémoire Ml. De cette manière, le dispositif de traitement DV1 ne peut dépenser plusieurs fois de l'argent correspondant à une même entrée de transaction TI, en particulier dans la période nécessaire à la réalisation du processus de validation et d'inscription par le réseau de mineurs. Une fois une transaction inscrite dans la chaîne de blocs, une synchronisation du dispositif de traitement DV1 avec le serveur SV peut causer !a suppression de la ou des entrées de transaction TI dépensées dans la mémoire Ml. 10 L'invention permet ainsi de lutter contre le phénomène de double-paiement déjà décrit précédemment et ainsi sécuriser les transactions de paiement. A noter cependant, comme indiqué précédemment, que si des difficultés techniques surviennent lors du processus de validation et d'inscription d'une transaction en cours, au niveau notamment du terminal DV2 ou du réseau de mineurs 20 (figure 1), il y a un 15 risque que l'inscription de la sortie de transaction TO soit retardée, voire même qu'elle n'ait jamais lieu. Dans ce cas, un problème peut survenir en ce qu'une entrée de transaction Ti peut être considérée comme dépensée du point de vue du dispositif de traitement DV1 alors qu'elle n'a jamais été inscrite, en tant que transaction dépensée (ou validée), dans la chaîne de blocs. Cette incohérence a pour conséquence que, bien que le 20 paiement n'ait pas eu lieu, l'entrée de transaction TI concernée ne peut plus être utilisée par le dispositif de traitement DV1. L'invention propose de résoudre ces problèmes supplémentaires comme décrit ci-après. Un mode de réalisation particulier de l'invention est à présent décrit en référence à la figure 4. Plus précisément, le dispositif de traitement DV1 représenté en figures 1-2 25 exécute le programme d'ordinateur PG1 pour mettre en oeuvre un procédé de contrôle du porte-monnaie virtuel 4, selon un mode de réalisation particulier. Comme indiqué précédemment, la carte à puce DV1 peut se synchroniser régulièrement avec le serveur distant SV pour mettre à jour les entrées de transaction Tl dont l'utilisateur U1, c'est-à-dire le compte de l'utilisateur Ul, est le propriétaire selon la 30 chaîne de blocs. Ainsi, lors d'une telle synchronisation, la carte à puce DV1 reçoit (étape S20) des données de mise à jour DM et un indicateur temporel TS. Ces données de mise à jour DM spécifient les entrées de transaction TI valides, c'est-à-dire à la disposition de du compte de l'utilisateur Ul, à un instant particulier tl représenté par l'indicateur temporel TS. Ces données de mise à jour DM sont par exemple représentatives de l'état 20 de la chaîne de blocs à l'instant t1, et reflètent donc les entrées de transaction TI qui sont valides à cet instant. L'indicateur temporel TS comprend par exemple la date et/ou l'heure de l'instant tl. La synchronisation 520 peut être réalisée de façon sécurisée, par exemple en utilisant un canal sécurisé entre le serveur SV et la carte à puce DV1, suite à un protocole d'authentification mutuelle. Dans un mode d'implémentation, l'indicateur temporel TS est certifié, par exemple par signature cryptographique dudit indicateur à l'aide d'une clé privé associée à une clé publique connue du dispositif de traitement DV1. Dans l'exemple considéré ici, le traitement selon les étapes S22-534 décrites ci-après est réalisé pour chacune des entrées de transaction TI1-TI3 présentes dans la mémoire 10 M1 de la carte à puce DV1. On suppose ici que la carte à puce DV1 traite l'entrée de transaction TU lors d'une première itération des étapes 522-S34. Au cours d'une étape de vérification 522, la carte à puce DV1 vérifie, à partir des données de mise à jour DM reçues, que l'entrée de transaction TI1 stockée dans sa mémoire M1 est valide. Les données de mise à jour DM permettent en particulier à la 15 carte à puce DV1 de déterminer si une transaction de paiement préalablement réalisée a été validée et enregistrée dans la chaîne de bloc. Si l'entrée de transaction TU est déterminée (522) comme invalide, la carte à puce DV1 supprime (524) l'entrée de transaction TI1 de sa mémoire M1. Une entrée de transaction TI est en particulier désignée comme invalide par les données de mises à jour 20 DM si cette entrée a été précédemment utilisée par l'utilisateur Ul pour effectuer un paiement qui a été validé et inscrit dans la chaîne de blocs du système Bitcoin. Selon un mode d'implémentation particulier, la carte à puce DV1 supprime également l'indicateur Spi associé à l'entrée de transaction 111 supprimée. Une fois l'étape 524 de suppression réalisée, le procédé peut prendre fin ou se 25 poursuivre en réalisant une nouvelle itération des étapes 522-534, par exemple pour traiter les autres entrées de transaction 112 et 113. En revanche, si l'entrée de transaction TU est détectée en 522 comme valide, le procédé se poursuit à l'étape de détection 526. Lors de l'étape de détection 526, la carte à puce DV1 détermine si le paramètre SP1 30 correspondant à l'entrée de transaction TI1 détectée comme valide du point de vue du serveur SV a une valeur différente des valeurs V1 et V2 prédéfinies déjà mentionnées ci-avant. Pour rappel, un paramètre de statut SP fixé à la valeur prédéfinie V1 ou V2 indique que, du point de vue de la carte à puce DV1, l'entrée de transaction 11 associée est 21 respectivement disponible (non dépensée) ou utilisée (dépensée). L'entrée de transaction TH est considéré comme dépensée, et donc bloquée, du point de vue de la carte à puce DV1 si cette dernière a préalablement utilisé cette entrée de transaction T11 lors d'une transaction pour générer une transaction de sortie TO. Ces valeurs V1 et V2 sont connues 5 de la carte à puce DV1. Dans un exemple particulier, V1 = 0 et V2 = -1, d'autres affectations de valeurs étant possibles. Si le paramètre Spi de l'entrée de transaction T11 est fixé à une valeur différente de V1 et V2 (étape S26), le procédé se poursuit à l'étape 532, sinon le procédé se poursuit à l'étape S30. 10 En 530, si le paramètre SP1 est détecté comme ayant la valeur V2, la carte à puce DV1 détecte que l'entrée de transaction TI1 associée a été précédemment utilisée pour générer une sortie de transaction TO et, en conséquence, modifie le statut de l'entrée de transaction -rn en affectant au paramètre SPI correspondant une troisième valeur V3, différente des valeurs V1 et V2, cette valeur V3 étant représentative de l'instant 'd défini 15 par l'indicateur temporel TS reçu en S20. A noter que, dans ce cas, la carte à puce DV1 considère que l'entrée de transaction T11 en question est dépensée alors que, selon les données de mises à jour DM, cette entrée de transaction T11 est toujours valide (car sa dépense n'est pas inscrite dans la chaîne de blocs). Cette situation se produit en particulier lorsqu'une transaction récemment réalisée par la carte à puce DV1 n'a pas 20 encore été validée par le réseau 20 et inscrite dans la chaîne de blocs. Dans un exemple particulier, la valeur V3 est égale à L'indicateur temporel TS ou déterminé à partir de l'indicateur temporel TS. Une fois l'étape 530 réalisée, le procédé peut prendre fin ou se poursuivre en réalisant une nouvelle itération des étapes 522-534, par exemple pour traiter les autres entrées de transaction TI2 et T13. 25 Toujours à l'étape 530, si le paramètre de l'entrée de transaction TEl est détecté comme ayant la valeur V1, aucune action particulière n'est réalisée et le procédé peut initier une nouvelle itération des étapes 522-S34, par exemple pour traiter les autres entrées de transaction 112 et 113. Le fait qu'une entrée de transaction TI considérée comme valide du point de vue de la chaîne de blocs ait son paramètre SP à la valeur V1 30 est cohérent et n'appelle à aucune action particulière. Par ailleurs, sur détection en 526 que le paramètre SP1 de l'entrée de transaction TH (qui est valide) a une valeur V4 différente des valeurs prédéfinies V1 et V2, la carte à puce CDV1 en déduit que cette valeur V4 est représentative d'un instant t2, antérieur à tl, correspondant à une précédente mise à jour. Cette valeur V4 a été affectée par la carte à 22 puce DV1 au paramètre SP1 en question lors d'une précédente itération de l'étape S30 (synchronisation antérieure). La carte à puce DV1 calcule (532) alors l'intervalle de temps INT qui s'est écoulé entre l'instant t2 et l'instant tl, à partir de l'indicateur temporel TS représentatif de 5 l'instant t1 et de la valeur V4 représentatif de l'instant antérieur t2. S'il est détecté en S32 que cet intervalle de temps (t1 - t2) atteint une durée limite prédéterminée DL, alors le procédé se poursuit à l'étape 534. Sinon, le procédé peut prendre fin ou reprend éventuellement par une nouvelle itération des étapes 522-534, par exemple pour traiter les autres entrées de transaction 1I2 et 113. 10 Dans un exemple particulier, la carte à puce DV1 détermine en S32 la durée limitée prédéterminée DL à partir d'un paramètre, dit paramètre de durée, compris dans l'entrée de transaction TEl ou dans la sortie de transaction TO qui a été générée à partir de cette entrée de transaction 111. A l'étape de modification 534, la carte à puce DV1 modifie le statut de l'entrée de 15 transaction m en affectant au paramètre SP1 associé la valeur initiale V1 indiquant que l'entrée de transaction en question n'est pas dépensée. De cette manière, l'entrée de transaction 111 dont le paramètre SP1 a été réinitialisé à la valeur V1 est débloquée et peut donc à nouveau être utilisée par la carte à puce DV1 lors d'une transaction ultérieure pour générer (étape S10, figure 3) une sortie de 20 transaction. Comme représenté en figure 4, le procédé peut prendre fin ou se poursuivre en réalisant une nouvelle itération des étapes S22-534, par exemple pour traiter les autres entrées de transaction 1I2 et 113. Un exemple de réalisation est à présent décrit en référence à la figure 5. Dans cet 25 exemple, on suppose que la carte à puce DV1, représentée en figures 1-2, comprend dans sa mémoire Miles entrées de transaction TI1-T13 définissant des transactions dont l'utilisateur Ul a été le bénéficiaire, en association avec les paramètres de statut SP1-SP3 indiquant si ces entrées de transaction respectives 111-113 ont été dépensées par l'utilisateur U1 ou non. Dans cet exemple, on suppose que l'entrée de transaction TI1 a 30 déjà été dépensée par la carte à puce DV1 lors d'une transaction de paiement passée, notée TRI (figure 3), avec le terminal DV2 et que les entrées de transaction TI2 et 113 n'ont pas encore été dépensées par la carte à puce DV1. On considère donc dans cet exemple que la mémoire Nîl est dans l'état suivant : - SPI. = V2 = -1 indiquant que Ventrée 111 est dépensée et donc bloquée ; 23 - SP2 = V1 = 0 et 5P3 = V1 = 0 indiquant que les entrées respectives TI2 et TI3 n'ont pas encore été dépensées et peuvent être utilisées par la carte à puce DV1. Au cours d'une première synchronisation 520e, la carte à puce DV1 reçoit en provenance du serveur SV des premières données de mise à jour DM1 et un premier indicateur temporel TS1. Ces données de mise à jour DM1 spécifient les entrées de transaction TI de l'utilisateur 1.11 qui sont valides selon la chaîne de blocs du système Bitcoin à un instant particulier t3 représenté par l'indicateur temporel TS1. L'indicateur temporel TS1 10 comprend par exemple la date et/ou l'heure correspondant à l'instant t3. On suppose qu'il s'agit de la première synchronisation avec le serveur distant SV depuis l'utilisation par la carte à puce DV1 de l'entrée de transaction TI1 (étape 510, figure 3) lors de la transaction passée TR1 pour générer une sortie d'entrée TO. Dans cet exemple, les données de mise à jour DM1 indiquent que l'entrée de transaction T11 est 15 toujours valide à l'instant t3 car sa dépense n'est pas encore inscrite dans la chaîne de blocs, Comme déjà expliqué, un temps de traitement plus ou moins long est nécessaire entre le moment de la transaction TR1 et l'inscription de cette transaction dans la chaîne de blocs. Cette inscription de la transaction TR1 peut en particulier tarder, voire même ne jamais se produire, si des difficultés techniques surviennent au niveau du terminal DV2 ou 20 du réseau de mineurs 2 lors du processus de vérification et d'inscription dans la chaîne de blocs. Au cours d'une étape 530a (identique à l'étape 530 de la figure 4), la carte à puce DV1 affecte, au paramètre SP1 de la première entrée de transaction TU indiquée comme dépensée (SP1=V2), une troisième valeur V3 prédéfinie représentative du premier instant 25 t3, cette valeur V3 étant différente des valeurs V1 = 0 et V2 = -1 précédemment mentionnées. Dans cet exemple, la valeur V3 est égale à l'indicateur temporel TS1 reçu en S20a lors de la première synchronisation. En affectant cette valeur V3 au paramètre de statut SPI., il est possible de spécifier dans la mémoire M1 de la carte à puce DV1 un instant t3 à partir duquel l'entrée de 30 transaction TI1 a le statut « dépensé » et, comme expliqué ci-après, de vérifier ultérieurement si le temps nécessaire pour que cette entrée de transaction 1I1 soit inscrite dans la chaîne de blocs est normal ou anormalement long. On suppose que la carte à puce DV1 réalise par la suite une deuxième synchronisation 520b avec le serveur SV. Au cours de cette deuxième synchronisation 24 S20b, la carte à puce DV1 reçoit en provenance du serveur SV des deuxièmes données de mise à jour DM2 et un deuxième indicateur temporel TS2. Ces données de mise à jour DM2 spécifient les entrées de transaction TI de l'utilisateur Ul qui sont valides selon la chaîne de blocs du système Bitcoin à un instant 5 particulier t4 représenté par l'indicateur temporel TS2. Dans cet exemple, l'instant t4 est postérieur à l'instant t3. L'indicateur temporel TS2 comprend par exemple la date et/ou l'heure correspondant à l'instant t4. Au cours d'une étape de détermination 522b, la carte à puce DV1 détermine pour chaque entrée de transaction T11-T13 stockée dans la mémoire Ml, si celle-ci est valide 10 du point de vue de la chaîne de blocs, de façon identique à l'étape S22 représentée en figure 4. Dans la négative (entrée invalide), la carte à puce DV1 supprime l'entrée de transaction TI concernée de sa mémoire M1 à l'étape S30b de façon identique à l'étape S24 représentée figure 4. A titre d'exemple, on s'intéresse par la suite au traitement de l'entrée TU qui a été 15 précédemment dépensée par l'utilisateur Ul lors de la transaction TR1. On suppose dans cet exemple qu'un problème technique quelconque affectant le terminal DV2 ou le réseau de mineurs 20 a perturbé le processus de validation et d'inscription de la transaction TR1 précédemment réalisée par la carte à puce DV1 avec le terminal DV2. Aussi, à l'instant t4, la sortie de transaction TO générée à partir de l'entrée de 20 transaction TH n'a toujours pas été inscrite dans la chaîne de blocs. Par conséquent, à l'étape S22b, la carte à puce DV1 détecte que l'entrée 1I1 est toujours valide et le procédé procède à l'étape S26b. Au cours de l'étape S26b, la carte à puce DV1 détecte que le paramètre de statut SP1 de l'entrée de transaction TI1 a une valeur V3 distincte des valeurs prédéfinies V1 et V2, 25 comme déjà décrit en référence à l'étape S26 représentée en figure 4. La carte à puce DV1 en déduit que la valeur V3 constitue une indication temporelle correspondant à une précédente synchronisation et le procédé procède à une étape S32b identique à l'étape 532 représentée en figure 4. Sur détection (S22b, S26b) que l'entrée de transaction TI1 est toujours valide et que 30 le paramètre SP1 a une troisième valeur V3 différente des valeurs prédéfinies V1 et V2, la carte à puce DV1 détermine (étape 532b) alors, à partir de la troisième valeur V3 et du deuxième indicateur temporel TS2, si l'intervalle de temps INT entre le premier instant t3 et le deuxième instant t4 atteint une durée limite prédéterminée DL. Dans la négative, le 25 procédé prend tin (étape 540). Dans le cas contraire (t4 - t3 2 DL)'. le procédé se poursuit à l'étape 534b. Dans un exemple particulier, la carte à puce DV1 détermine en S32b la durée limitée prédéterminée DL à partir d'un paramètre, dit paramètre de durée, compris dans l'entrée 5 de transaction TU_ ou dans la sortie de transaction TO qui a été précédemment générée à partir de cette entrée de transaction T11. Au cours de l'étape. 534b (identique à l'étape 534 représentée en figure 4), la carte à puce DV1 modifie le statut de l'entrée de transaction T11 en affectant au paramètre SP1 associé la valeur initiale V1 indiquant que cette entrée de transaction TU n'est pas 10 dépensée. A noter que l'ordre dans lequel sont exécutées les étapes du procédé de l'invention, notamment dans les figures 3, 4 et 5, n'est présenté ici qu'à titre d'exemple et est susceptible d'adaptations dans le cadre de l'invention. En figure 5, par exemple l'étape S22b peut éventuellement être réalisée après l'étape 526b. 15 Comme indiqué précédemment, si des difficultés techniques viennent perturber le processus de validation et d'inscription d'une transaction en cours, au niveau notamment du terminal DV2 ou du réseau de mineurs 20 (figure 1), il y a un risque que l'inscription d'une sortie de transaction TO soit retardée, voire même qu'elle n'ait jamais lieu, ce qui pose problème dans la mesure où une ou des entrées de transaction TI peuvent être 20 bloquées dans la carte à puce DV1 bien que le paiement n'ait pas eu lieu. L'invention permet avantageusement à la carte à puce DV1 de vérifier si le processus de validation et d'inscription dans la chaîne de blocs d'une sortie de transaction. TO prend trop de temps ou non et, dans le cas d'un traitement anormalement long, de considérer que le paiement n'a pas eu lieu et par conséquent de débloquer dans la carte à puce DV1 25 le ou !es entrées de transaction Ti qui ont été utilisées pour générer la sortie de transaction TO considérée. Une fois réactivées, les entrées de transaction Tl peuvent être utilisées à nouveau par le porte-monnaie virtuel lors d'une nouvelle transaction de paiement. L'invention permet ainsi d'éviter que des entrées de transaction 11 soient bloquées 30 indéfiniment dans le cas où un problème particulier vient perturber le processus de validation et d'inscription dans la chaîne de blocs. A noter que, dans les exemples représentés en figures 4 et 5, la carte à puce- DV1 réalise des synchronisations avec un serveur distant SV afin de mettre à jour ses entrées .de transaction TL Pour ce faire, la carte à puce DV1 reçoit en provenance du serveur SV 26 des données de mise à jour DM et un indicateur temporel TS, comme déjà expliqué précédemment. A noter toutefois que la carte à buco DV1 peut, de manière générale, réaliser une synchronisation avec un serveur distant (tel que le serveur SV) de sorte à recevoir des données de mise à jour DM sans indicateur temporel TS ou, inversement, pour recevoir un indicateur temporel TS sans données de mise à jour DM. Selon un exemple particulier, la carte à puce DV1 reçoit des données de mise à jour DM du serveur SV afin de déterminer si ses entrées de transaction TI1-T13 sont toujours valides. Pour ce faire, la carte à puce DV1 réalise par exemple une synchronisation avec le serveur SV. Au cours d'une telle synchronisation, la carte à puce DV1 reçoit des données 10 de mise à jour MD. La carte à puce DV1 détecte, à partir des données de mise à jour Divi reçues, qu'au moins une entrée de transaction TI CM par exemple) stockée dans sa mémoire M1 n'est plus valide et supprime de sa mémoire M1 chaque entrée de transaction 11 détectée comme non valide. Par ailleurs, pour sécuriser une transaction de paiement, Ir est préférable que le 15 terminal DV2 (figure 1) authentifie la carte à puce DV1 pour déterminer que celle-ci est un tiers de confiance. Sur détection que l'utilisateur Ul est un tiers de confiance et ne peut donc pas réaliser de double-paiement, le terminal DV2 accepte une transaction en cours. Selon un exemple particulier, au cours du traitement d'une transaction en cours, la 20 carte à puce DV1 s'authentifie auprès du terminal DV2 en envoyant une réponse déterminée à partir d'une donnée de défi préalablement reçue du terminal DV2. Cette réponse comprend par .exemple une signature d'un message comportant la donnée de défi. Un exemple de réalisation particulier est décrit en référence à la figure 6. Dans cet 25 exemple, lors d'une transaction.TR2 en Cours de traitement, le terminal DV2 génère (554) un donnée de défi CH1. Cette donnée de défi- CI-11 se présent par exemple sous la forme d'une série de symboles, de type alphanumériques ou autres. Cette donnée de défi CH1 est par exemple générée aléatoirement par le terminal DV2. Le terminal DV2 envoie (556) cette donnée de défi CH1 à la carte à puce DV1. Une 30 fois la donnée de défi CH1 reçue (556), la carte à puce DV1 calcule (558) un résultat HI-11 d'une fonction de hachage F, à partir de données de transaction représentatives de la transaction TR2- en cours. Ces données de transaction peuvent être une sortie de transaction TO générée par la carte à puce DV1 comme décrit précédemment (510, figure 3 27 La carte à puce DV.1 détermine ,560 ensuite la signature Si d'un message comprenant le résultat HH1 et la donnée de défi Chil, avec éventuellement d'autres informations. Cette signatum est réalisée à l'aide de la clé secrète SKi de l'utilisateur Ul. La carte à puce DV1 envoie la signature Si et le résultat HH1 au terminal DV2 lors d'une ape S62. Selon un autre mode de réalisation, la signature Si est déterminée en 560 à l'aide d'une clé secrète autre que la clé secrète SK1 associée au con-ipte crypto monnaie de l'utUisateur Ul. (e.g. on utilise la clé secrète associée à une application de paiement EMV). Le terminal DV2 reçoit (S62) puis vérifie (564) la signature Si à partir de la clé 10 publique PK1 de l'utilisateur Ul. Si cette vérification 564 est passée avec succès, le terminal DV2 enregistre (S66) le résultat 1-11-11 dans sa mémoire et le procédé se poursuit. Une phase de vérification 568 d'un code personnel (PIN) de l'utilisateur U1 est éventuellement réalisée entre la carte à puce DV1 et le terminal DV2. La carte à puce DV1 envoie (570) alors les données de transaction représentatives de 15 la transaction TR2 en cours au terminal DV2, éventuellement sur requête du terminal 0V2. Ces données de transaction comprennent la sortie de transaction TO correspondant à la transaction TR2 et, éventuellement d'autres données associées comme déjà expliqué. A partir de ces données de transaction, le terminal DV2 calcule (S72) son propre résultat HH2 de la fonction de hachage F puis compare les résultats HH1 et HH2 de sorte que 20 l'authentification de la carte à puce DV1 et de la transaction TR2 est passée avec succès seulement si HH1 = H1-12. Un homme du métier comprendra que les modes de réalisation et variante_ décrits ci-avant ne constituent que des exemples non limitatifs de mise en oeuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou 25 combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier. On notera par exemple que dans les modes de réalisation décrits ci-avant, il y a une paire de clés PK1 SKi associée à un .compte de l'utilisateur L11.. Néanmoins, l'invention s'applique aussi à des porte-monnaie virtuels comportant plusieurs paires de clés 30 associées à plusieurs comptes d'utilisateur. Dans ce cas, le porte-monnaie virtuel peut signer ses transactions à l'aide REVENDICATIONS1. Procédé de contrôle d'un porte-monnaie virtuel (4), mis en oeuvre dans un dispositif de traitement (DV1) apte à réaliser des transactions dans une monnaie cryptographique, le dispositif de traitement stockant dans une mémoire (M1) au moins une entrée de transaction (ri) définissant une transaction dont le porte-monnaie virtuel a été le bénéficiaire, le procédé comprenant : - traitement d'une transaction en cours (TR1), comportant une génération (S10), à partir d'au moins une entrée de transaction (n), d'une sortie de transaction (TO) définissant la transaction en cours entre le dispositif de traitement et un terminal (DV2) tiers ; le procédé étant caractérisé en ce qu'il comprend : conservation (S4) en mémoire d'au moins un paramètre (SP) représentatif d'un statut d'une entrée de transaction associée stockée dans ladite mémoire, le paramètre étant fixé initialement à une première valeur (V1) tant que ladite entrée de transaction associée n'est pas utilisée par le porte-monnaie virtuel lors du traitement d'une transaction pour générer une sortie de transaction (TO) ; sur détection que ladite entrée de transaction associée est utilisée par le porte- monnaie pour générer une sortie de transaction (TO), modification (S12) du statut de ladite entrée de transaction Cm associée en affectant audit paramètre une deuxième valeur (V2) différente de la première valeur pour indiquer que ladite entrée de transaction associée est dépensée ; dans lequel, ledit traitement de la transaction en cours comprend une vérification (S8) du paramètre d'une entrée de transaction associée, cette dernière étant utilisée dans la génération de la sortie de transaction seulement si ledit paramètre est fixé à la première valeur indiquant que ladite entrée de transaction associée n'est pas dépensée. 2. Procédé selon la revendication 1, comprenant : première synchronisation (S20a) avec un serveur distant (SV), comprenant une réception d'un premier indicateur temporel (TS1) représentatif d'un premier instant (t3) associée à la première synchronisation ; et 29 affectation (S30a), au paramètre (SPI) d'au moins une première entrée de transaction (T11) indiquée comme dépensée, d'une troisième valeur (V3) représentative du premier instant et différente des première et deuxième valeurs. 5 3. Procédé selon la revendication 2, comprenant : - deuxième synchronisation (S20b), postérieure à la première synchronisation, avec un serveur distant (SV), comprenant une réception d'un deuxième indicateur temporel (TS2) représentatif d'un deuxième instant (t4) associé à la deuxième synchronisation ; 10 sur détection (S26b) que le paramètre (SP1) de la première entrée de transaction (111) a une troisième valeur (V3) différente des première et deuxième valeurs (V1, V2), détermination (S32b) à partir de la troisième valeur et du deuxième indicateur temporel, de si l'intervalle de temps (INT) entre le premier instant (t3) et le deuxième instant (t4) atteint une durée limite prédéterminée (DL) ; et 15 dans l'affirmative, modification (S34b) du statut de ladite première entrée de transaction en affectant au paramètre (SPI.) associé ladite première valeur (V1) indiquant que ladite première entrée de transaction (111) n'est pas dépensée, 4. Procédé selon la revendication 3, dans lequel la durée limite prédéterminée (DL) 20 est déterminée à partir d'un paramètre compris dans la première entrée de transaction ou dans une sortie de transaction générée à partir de ladite première entrée de transaction. 5. Procédé selon l'une quelconque des revendications 1 à 4, comprenant : une synchronisation avec un serveur distant, comprenant une réception de 25 données de mise à jour ; et sur détection, à partir des données de mise à jour, qu'une entrée de transaction n'est plus valide, le dispositif de traitement supprime ladite entrée de transaction non valide de la mémoire. 30 6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel la monnaie cryptographique est le bitcoin. 7. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel, au cours du traitement de la transaction en cours, le dispositif de traitement s'authentifie auprès du 30 terminal tiers en envoyant (560) une réponse déterminée à partir d'une donnée de défi (CI-11) préalablement reçue (556) dudit terminal tiers. 8. Procédé selon la revendication 7, dans lequel la réponse comprend une signature 5 (Si) d'un message comportant la donnée de défi (CI-Il). 9. 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 à 8 lorsque ledit programme est exécuté par un ordinateur. 10 10. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG1) comprenant des instructions pour l'exécution des étapes d'un procédé de traitement selon l'une quelconque des revendications 1 à 8. 15 11. Dispositif de traitement (DV1) configuré pour contrôler un porte-monnaie virtuel (4) destiné à réaliser des transactions dans une monnaie cryptographique, comprenant : un module de stockage (MD2) configuré pour stocker au moins une entrée de transaction (11) définissant une transaction dont le porte-monnaie virtuel a été le bénéficiaire ; 20 un module de traitement (MD4) d'une transaction en cours (TRI.), configuré pour générer, à partir d'au moins une entrée de transaction, une sortie de transaction (TO) définissant la transaction en cours entre le dispositif de traitement et un terminal tiers ; le dispositif de traitement étant caractérisé en ce qu'il comprend 25 un module de gestion (MD6) configuré pour conserver en mémoire au moins un paramètre (SP) représentatif d'un statut d'une entrée de transaction (Tl) associée, le paramètre étant fixé initialement à une première valeur (V1) tant que ladite entrée de transaction associée n'est pas utilisée par le module de traitement lors du traitement d'une transaction pour générer une sottie de transaction, 30 le module de gestion (MD6) étant configuré, sur détection que ladite entrée de transaction associée est utilisée par le porte-monnaie pour générer une sortie de transaction, pour modifier le statut de ladite entrée de transaction associée en affectant audit paramètre (SP) une deuxième valeur (V2) différente de la première valeur (V1) pour indiquer que ladite entrée de transaction associée est dépensée ; 31 dans lequel, ledit module de traitement (MD4) est configuré pour vérifier le paramètre (SP) d'une entrée de transaction associée et pour utiliser cette dernière dans la génération de la sortie de transaction seulement si ledit paramètre est fixé à la première valeur (V1) indiquant que ladite entrée de transaction associée n'est 5 pas dépensée. 12. Dispositif selon la revendication 11, comprenant un module de synchronisation (MD8) configuré pour réaliser une première synchronisation avec un serveur distant, au cours de laquelle le dispositif de traitement reçoit un premier indicateur temporel 10 représentatif d'un premier instant associée à la première synchronisation ; le module de gestion (MD6) étant configuré pour affecter, au paramètre d'au moins une première entrée de transaction indiquée comme dépensée, une troisième valeur représentative du premier instant et différente des première et deuxième valeurs. 15 13. Dispositif selon la revendication 12, dans lequel le module de synchronisation (MD8) est configuré pour réaliser, postérieurement à la première synchronisation, une deuxième synchronisation avec un serveur distant (SV), au cours de laquelle le dispositif de traitement reçoit un deuxième indicateur temporel représentatif d'un deuxième instant associé à la deuxième synchronisation ; 20 le module de gestion (MD6) étant configuré pour : sur détection que le paramètre de la première entrée de transaction a une troisième valeur différente des première et deuxième valeurs, déterminer à partir de la troisième valeur et du deuxième indicateur temporel, si l'intervalle de temps entre le premier instant et le deuxième instant atteint une durée limite 25 prédéterminée ; et dans l'affirmative, modifier le statut de ladite première entrée de transaction en affectant au paramètre associé ladite première valeur indiquant que ladite première entrée de transaction n'est pas dépensée. 30 14. Dispositif selon la revendication 13, dans lequel le module de synchronisation (MD8) détermine la durée limite prédéterminée à partir d'un paramètre compris dans la première entrée de transaction ou dans une sortie de transaction générée à partir de ladite première entrée de transaction. 32 15. Dispositif selon l'une quelconque des revendications 11 à 14, comprenant un module de synchronisation configuré pour réaliser une synchronisation avec un serveur distant, au cours de laquelle le dispositif de traitement reçoit des données de mise à jour ; dans lequel le module de gestion est configuré pour détecter, à partir des données 5 de mise à jour, qu'une entrée de transaction n'est plus valide ; et dans lequel le module de stockage est configuré pour supprimer ladite entrée de transaction non valide de la mémoire.