Après COLDCARD, Trezor et SafePal : la thèse de CLAVI en faveur de la minimisation des données

Clôture de la recherche : 19 août 2026. Les totaux déclarés par les fournisseurs sont signalés comme tels. Cet article est fourni à titre pédagogique et ne constitue ni un avis juridique ni un conseil en réponse aux incidents.

La réponse directe : moins de données conservées signifie moins d’exposition du côté de l’opérateur

La minimisation des données est un contrôle de sécurité, car un opérateur ne peut pas perdre un enregistrement qu’il n’a jamais collecté. À défaut, il faut ne recueillir que ce qu’exige une finalité définie, l’isoler des autres systèmes et le supprimer selon un calendrier vérifié. Mais la promesse « zéro donnée » n’est pas crédible pour une société en activité. L’expédition, les factures, le support, la prévention de la fraude et les services réglementés peuvent imposer des besoins ciblés de tenue de dossiers. L’objectif défendable est zéro accès de l’opérateur aux secrets du coffre et la conservation du minimum nécessaire partout ailleurs.

Cette distinction est importante, car durant le cycle d’actualité d’août 2026, trois événements de sécurité ont souvent été regroupés sous un même titre alarmiste sur des « piratages de portefeuilles matériels ». Il ne s’agissait pas d’un problème unique.

• L’incident COLDCARD concernait la génération des secrets de portefeuille.
• L’incident Trezor concernait un accès non autorisé chez un prestataire d’expédition.
• La divulgation de SafePal concernait une faille d’autorisation dans un composant de suivi des commandes.

Que s’est-il passé en juillet et août 2026 ?

Incident	Publication ou mise à jour publique	Couche de sécurité	Présentation publiable	Niveau de confiance
Incident COLDCARD lié à un RNG prévisible	Avis publié le 30 juillet ; consignes mises à jour le 14 août 2026	Génération des secrets	Coinkite et Block ont indépendamment attribué le problème à une erreur d’intégration du firmware qui permettait à un générateur de secours déterministe de fournir l’aléa utilisé pour générer les seeds.	Cause première confirmée ; certains détails relatifs aux versions et à l’impact restent contestés ou estimés.
Exposition Trezor/ShipMonk	Avis publié le 13 août 2026	Données logistiques et d’identité	Trezor affirme que ShipMonk l’a informé d’un accès non autorisé touchant environ 13 689 dossiers clients. Trezor indique que ses appareils, ses clés et ses sauvegardes n’ont pas été touchés.	Périmètre déclaré par le fournisseur, divulgation corroborée par une couverture indépendante ; ensemble de données non audité indépendamment.
Exposition du suivi des commandes SafePal	Divulgation publiée le 16 août 2026	Données logistiques et d’achat	SafePal affirme qu’une faille d’autorisation a exposé les informations de commande d’environ 39 798 clients. L’entreprise indique que les identifiants de portefeuille et les données de cartes de paiement n’étaient pas concernés.	Déclaration du fournisseur, situation encore en évolution.

COLDCARD : l’air-gap ne peut pas compenser une faible entropie

La vulnérabilité COLDCARD était une défaillance dans la création des secrets, et non une compromission d’une base de données clients. Le compte rendu technique de Coinkite et l’analyse indépendante du code par Block ont tous deux constaté qu’une erreur de compilation ou d’édition de liens permettait l’utilisation d’un générateur de secours déterministe de MicroPython à la place de l’aléa matériel prévu.

Une seed de portefeuille doit être imprévisible. Si l’espace des seeds possibles devient suffisamment petit pour être exploré, un attaquant peut reconstruire des clés candidates hors de l’appareil. Le portefeuille peut être éteint, placé dans un coffre et n’avoir jamais été connecté à Internet : ces protections ne rétablissent pas l’aléa qui manquait au moment de la création du secret.

Il s’agit d’une correction importante aux descriptions simplistes d’un « air-gap ». L’isolation physique et réseau peut fortement réduire les voies d’attaque à distance, mais elle ne prouve pas que chaque composant à l’intérieur de la frontière isolée fonctionne correctement. La génération d’entropie, l’intégration du firmware, les builds reproductibles, les procédures de mise à jour et l’examen indépendant restent des éléments du modèle de sécurité.

La frontière exacte entre les versions Mk2/Mk3 concernées offre elle-même une leçon utile sur le traitement des preuves. L’analyse de Block fait remonter le chemin affecté à la version 4.0.0. L’avis actuel de Coinkite commence à la version 4.0.1. Plutôt que de choisir silencieusement l’une des deux, utilisateurs et éditeurs devraient reconnaître cette divergence et traiter avec prudence toute seed créée sous l’une ou l’autre limite.

Coinkite précise également que l’installation du firmware corrigé ne renforce pas une seed déjà créée avec un firmware affecté. La mise à jour protège les générations futures ; une seed concernée nécessite encore une migration prudente vers un portefeuille nouvellement généré, sous réserve des précisions du fournisseur concernant les dés et la passphrase. Cette distinction devrait figurer dans tout résumé des mesures correctives.

Dans son analyse on-chain du 3 août, Galaxy Research a attribué 1 596 BTC à trois vagues à haute confiance et à 14 incidents plus modestes. Ce chiffre ne doit être utilisé qu’avec cette attribution. Il ne constitue pas un total de pertes vérifié par Coinkite, et cet article ne reprend pas les estimations plus élevées concernant une quatrième vague ou leur valeur en dollars, restées non confirmées.

Les éléments publics n’identifient pas l’attaquant et ne montrent pas que l’intelligence artificielle a découvert la faille. Une campagne d’hameçonnage distincte a exploité l’inquiétude autour de COLDCARD, mais aucune source examinée n’établit qu’elle ait utilisé une liste de clients Coinkite divulguée.

Trezor : la minimisation semble avoir réduit l’exposition, sans l’éliminer

L’avis de Trezor du 13 août concernait des données logistiques détenues par ShipMonk, et non un matériel de portefeuille compromis. Trezor affirme que ShipMonk l’a informé le 10 août. Il s’agit de la date de notification, pas nécessairement de la date de l’intrusion.

L’avis de Trezor ne nommait pas l’exploit. BleepingComputer a ensuite rapporté que les courriels de notification de ShipMonk qu’il avait examinés reliaient l’accès à une vulnérabilité Metabase. L’avis primaire de Metabase identifie CVE-2026-72898 comme une faille critique d’injection SQL non authentifiée activement exploitée. Aucun post-mortem public de ShipMonk ni rapport forensique indépendant n’avait été trouvé à la date de clôture.

Trezor a signalé deux groupes concernés :

• 11 742 clients dont les noms, adresses e-mail, numéros de téléphone et adresses de livraison ont été exposés.
• 1 947 clients dont les noms, villes et adresses e-mail ont été exposés sans les adresses de livraison complètes.

Le total déclaré est donc d’environ 13 689, et non « exactement 14 000 ». Trezor indique que la plupart des dossiers concernés portaient sur des clients ayant reçu des commandes aux États-Unis, au Royaume-Uni, en Suède, en Colombie, au Brésil, en Italie ou au Portugal entre le 10 mai et le 8 août 2026. L’entreprise a précisé séparément que les dossiers partiels pouvaient inclure des commandes plus anciennes et que la période exacte était encore en cours de vérification avec ShipMonk.

Selon Trezor, ses propres systèmes, ses portefeuilles matériels, ses clés privées et ses sauvegardes de portefeuilles n’ont pas été touchés. Trezor affirme aussi que le contenu des colis n’a pas été exposé. Ces limites sont importantes, mais elles ne rendent pas inoffensifs les noms et les adresses personnelles. Les informations d’identité et de livraison peuvent rendre un faux message de support plus convaincant et accroître le risque de ciblage. L’avis n’établit pas qu’une attaque physique a eu lieu ; le risque ne doit donc pas être présenté comme une conséquence confirmée.

Le tableau de conservation publié par Trezor indique que les données principales relatives aux commandes et livraisons de la boutique en ligne, une fois les commandes terminées ou annulées, sont généralement supprimées après 90 jours, sous réserve d’exceptions pour les commandes en cours. Cette politique semble avoir limité le nombre d’adresses de livraison complètes disponibles. Elle n’a pas éliminé l’incident, et la réserve concernant les anciens dossiers partiels empêche de présenter sa mise en œuvre comme parfaite.

Le même tableau montre aussi pourquoi l’affirmation « Trezor supprime les données clients après 90 jours » est fausse. Il prévoit des durées différentes selon les finalités : dix ans pour les données de facturation dans un environnement séparé, jusqu’à sept ans pour les données de paiement fiat détenues par des tiers, cinq ans après la fin de la relation pour certains dossiers de paiements en crypto-actifs et anonymisation des tickets de support clos après 120 jours. Les données de marketing et de parrainage suivent encore d’autres règles.

Voici à quoi ressemble une véritable minimisation : non pas un slogan ou un délai unique, mais une cartographie des catégories de données. La question critique est de savoir si cette cartographie est appliquée chez le commerçant, l’entrepôt, le transporteur, la plateforme de support, le prestataire de paiement, dans les répliques et dans les sauvegardes.

SafePal : un portefeuille peut rester intact tandis que ses acheteurs deviennent visibles

La divulgation de SafePal décrit une autre défaillance touchant des données commerciales, et non une compromission déclarée de secrets de portefeuille. SafePal affirme qu’une faille d’autorisation dans un plug-in de suivi des commandes a exposé des informations concernant environ 39 798 clients ayant passé commande entre le 2 mars 2025 et le 11 avril 2026.

Selon SafePal, les champs exposés comprenaient les noms, adresses e-mail, adresses de livraison, numéros de téléphone et détails d’achat. L’entreprise indique que l’incident ne concernait ni les phrases de récupération, ni les clés privées, ni les mots de passe de portefeuille, ni d’autres identifiants de portefeuille, ni les informations de compte bancaire, ni les numéros de carte de paiement, ni les numéros d’identification officiels.

Ces déclarations restent celles du fournisseur. La conclusion prudente est plus étroite : savoir qu’une personne identifiée a acheté un produit de sécurité peut avoir de la valeur, même lorsque les secrets du produit restent protégés.

Pour un fournisseur de matériel, la pile de paiement et de suivi n’est pas un « commerce électronique ordinaire » situé hors du périmètre de sécurité. Elle peut relier une identité réelle, une adresse de livraison, des canaux de contact et un achat sensible sur le plan de la sécurité. Chaque plug-in et partenaire logistique traitant cette combinaison entre dans le modèle de menace du client.

« Zéro donnée » ne désigne pas une seule réalité

« Ne collecter aucune donnée » est un défi de conception utile, mais une politique opérationnelle incomplète. Un Personal Vault et la société qui le fabrique ou l’assiste traitent des catégories d’informations différentes.

L’objectif le plus exigeant s’applique à la couche des secrets du coffre : le fournisseur ne devrait recevoir ni clés privées, ni matériel de récupération, ni prompts locaux de l’IA propriétaire de CLAVI, ni aucun autre contenu protégé. La documentation publique de CLAVI décrit cet objectif comme celui de son Personal Vault. Il s’agit d’une affirmation sur l’architecture du produit et l’accès de l’opérateur aux secrets de l’utilisateur, et non de l’affirmation que CLAVI Switzerland AG ne détient aucun dossier commercial.

Les dossiers commerciaux et d’entreprise exigent une autre discipline :

Catégorie de données	Objectif défendable	Pourquoi « ne rien conserver » peut être incomplet
Secrets du coffre et contenu local protégé	Les rendre inaccessibles à l’opérateur par l’architecture ; ne jamais les demander par l’intermédiaire du support.	C’est pour ces éléments que l’absence de collecte supprime le plus directement l’exposition du côté de l’opérateur.
Données de commande et de livraison	Recueillir le minimum de champs exigés par le transporteur choisi ; les isoler ; les supprimer après la livraison et à l’expiration des délais de retour et de contestation.	Un produit physique ne peut parvenir au client sans un mécanisme de livraison, sauf à utiliser une option de retrait préservant la vie privée.
Factures et justificatifs comptables	Ne conserver que les informations nécessaires pour constituer et justifier les documents comptables requis, dans un système distinct.	Les règles comptables suisses peuvent imposer la conservation pendant dix ans des livres et pièces comptables, ainsi que du rapport de gestion et du rapport de révision ; elles n’autorisent pas la conservation d’un profil CRM complet.
Dossiers de support	Interdire les secrets, minimiser les pièces jointes, séparer les adresses de réexpédition et supprimer ou anonymiser les dossiers clos.	Une garantie, un remplacement ou un litige en cours peut nécessiter un dossier limité.
Données marketing	Rendre la participation facultative et séparer les preuves de consentement des données logistiques.	Une commande ne devrait pas devenir tacitement une autorisation de profilage sans limite de durée.
Éléments de sécurité et mesures de conservation légale	Conserver un ensemble documenté et étroitement délimité lorsqu’un incident ou une obligation légale valide l’exige ; réexaminer l’exception.	Une suppression habituelle peut être légalement suspendue pour une enquête précise ou une obligation de conservation, mais l’exception ne devrait pas devenir la règle permanente.

Le principe n’est pas de « tout supprimer quelles qu’en soient les conséquences ». Il consiste à « exiger de chaque champ conservé qu’il justifie son existence ».

Que requièrent réellement le RGPD, le droit suisse et les règles sur les crypto-actifs ?

Le paysage juridique soutient la minimisation, mais ne prescrit pas un calendrier universel de conservation. L’applicabilité dépend de l’entreprise, du client, de la finalité du traitement, du service et de la juridiction. Le tableau suivant est une cartographie du périmètre, et non un avis juridique.

Cadre	Ce qui peut être affirmé avec prudence	Ce que cela ne signifie pas
RGPD	L’article 5 exige que les données personnelles soient adéquates, pertinentes et limitées à ce qui est nécessaire, et qu’elles ne soient pas conservées plus longtemps que nécessaire. L’article 25 impose la protection des données dès la conception et par défaut.	Le RGPD n’impose pas à chaque entreprise de ne collecter aucune donnée et ne prescrit pas une architecture unique entièrement locale.
Notification des violations au titre du RGPD	Un responsable du traitement notifie l’autorité de contrôle sans retard injustifié et, lorsque cela est possible, dans les 72 heures après en avoir pris connaissance, à moins que la violation ne soit pas susceptible d’engendrer un risque pour les droits et libertés des personnes physiques. Les personnes sont informées sans retard injustifié lorsqu’un risque élevé est probable, sous réserve d’exceptions.	Tout incident ne doit pas être annoncé à tout le monde dans les 72 heures.
LPD suisse	L’article 7 impose la protection des données dès la conception et par défaut, notamment des paramètres par défaut limités au traitement nécessaire à la finalité. L’article 24 emploie la norme « dans les meilleurs délais » lorsqu’une violation est susceptible d’entraîner un risque élevé.	Le droit suisse ne reprend pas la formulation fixe de 72 heures du RGPD.
Droit comptable suisse	L’article 958f du Code des obligations exige que les livres et pièces comptables, ainsi que le rapport de gestion et le rapport de révision, soient conservés pendant dix ans à compter de la fin de l’exercice.	Il n’impose pas de conserver pendant dix ans la télémétrie sans rapport, les profils marketing, les dossiers de support ou les données de portefeuille.
MiCA	Un prestataire de services sur crypto-actifs entrant dans le champ d’application conserve certains enregistrements relatifs aux services, activités, ordres et transactions pendant cinq ans, voire sept après une demande formulée à temps par une autorité. La qualité de PSCA dépend du point de savoir si le prestataire fournit à titre professionnel à des clients un ou plusieurs services énumérés par MiCA. La conservation ou le contrôle des crypto-actifs des clients ou de leurs moyens d’accès concerne spécifiquement la garde ; le transfert, l’exécution, l’échange, le conseil et les autres services énumérés répondent à des critères distincts.	Tout vendeur de matériel n’est pas automatiquement un PSCA, et MiCA n’exige pas la conservation de chaque champ relatif au client.
Règlement de l’UE sur les transferts de fonds	Les obligations d’information s’appliquent à tous les transferts entrant dans le champ d’application qui impliquent un PSCA de l’UE. Les transferts dépassant 1 000 € vers ou depuis une adresse auto-hébergée du client déclenchent une évaluation supplémentaire visant à déterminer si le client possède ou contrôle cette adresse. Les informations prescrites sont conservées pendant cinq ans ; un État membre ne peut autoriser ou imposer jusqu’à cinq années supplémentaires qu’après avoir évalué la nécessité et la proportionnalité à des fins de LBC/FT.	1 000 € n’est pas un seuil général de la Travel Rule. Les transferts purement de personne à personne sans PSCA sont exclus.
Mise en œuvre suisse du CARF	Le SIF suisse indique que le cadre ne peut pas être mis en œuvre avant le 1er janvier 2027 et que sa base juridique ne s’applique pas en 2026. Le CARF de l’OCDE couvre l’identité des utilisateurs déclarables et les transactions pertinentes agrégées pour les prestataires de services entrant dans son champ.	La Suisse n’a pas mis en œuvre le CARF le 1er janvier 2026, et le CARF n’est pas une base de données universelle recensant les avoirs de chaque acheteur de portefeuille matériel.

MiCA, la Travel Rule, DORA, la LBA suisse et le CARF ne peuvent pas être appliqués à CLAVI à partir de simples étiquettes telles que « matériel », « auto-garde » ou « non dépositaire ». L’analyse peut changer selon l’accès aux clés, les capacités de signature ou d’intervention, les services de transfert et d’échange, le contrôle des smart contracts, les rôles contractuels et les relations continues avec les clients. Les fonctionnalités de production doivent faire l’objet d’un examen juridique qualifié avant toute exclusion déclarée publiquement.

Les lignes directrices finales 02/2025 v2.0 du Comité européen de la protection des données, adoptées le 7 juillet 2026, ajoutent une autre frontière. Les adresses de portefeuille et les clés publiques peuvent constituer des données personnelles lorsqu’elles peuvent raisonnablement être reliées à une personne physique. Le chiffrement peut protéger des données personnelles sans les rendre anonymes. Les lignes directrices déconseillent généralement d’inscrire des données personnelles on-chain, car le stockage immuable complique leur suppression, mais elles n’édictent pas une interdiction juridique catégorique de tout traitement de ce type.

Un modèle de frontière des données pour le Personal Vault de CLAVI

CLAVI devrait décrire la vie privée comme une frontière inspectable, et non comme un adjectif absolu. La définition canonique de CLAVI présente le produit comme un Personal Vault pour les actifs numériques, les données privées et les communications privées. La suite utile consiste à expliquer, catégorie par catégorie, ce à quoi l’opérateur peut accéder et ce que la société exploitante doit encore traiter.

Le modèle public devrait répondre à sept questions pour chaque catégorie de données :

1. Finalité : pourquoi ce champ existe-t-il ?
2. Champs minimaux : quels attributs sont strictement nécessaires ?
3. Système : où l’enregistrement est-il conservé, et est-il séparé des autres finalités ?
4. Accès : quels rôles et sous-traitants peuvent le consulter ?
5. Déclencheur d’expiration : le délai commence-t-il à la collecte, à la livraison, à la clôture du ticket, à la fin de la relation ou à la fin de l’exercice ?
6. Preuve de suppression : comment les copies de production, les répliques, les systèmes des sous-traitants et les sauvegardes sont-ils couverts ?
7. Exception : qu’est-ce qui peut suspendre la suppression, qui l’approuve et quand cette décision est-elle réexaminée ?

Lu avec Pourquoi CLAVI n’est pas en concurrence avec Ledger, le propos n’est pas qu’un mécanisme de sécurité permette de vaincre toutes les attaques. Un Personal Vault combine plusieurs couches : génération des secrets, autorité de signature, traitement local, contrôle physique, données d’entreprise soigneusement délimitées et environnement juridique. Chaque couche possède son propre mode de défaillance.

Neuf contrôles pour traduire la minimisation dans les opérations

Une politique ne réduit le risque que lorsque les systèmes et les sous-traitants l’appliquent. Pour les fournisseurs de matériel et de Personal Vaults, l’ensemble pratique de contrôles est simple à énoncer, même si sa mise en œuvre est difficile.

1. Tenir un registre des finalités au niveau de chaque champ. « Données de commande » est trop vague. Le nom, l’adresse postale, le numéro de téléphone, l’adresse e-mail, le SKU et l’identifiant de suivi ont chacun besoin d’une finalité et d’un responsable documentés.
2. Séparer les données par finalité. La logistique, la comptabilité, le support, le marketing et les éléments de sécurité ne devraient pas devenir un profil client unique interrogeable.
3. Rendre les champs facultatifs réellement facultatifs. Une exigence locale d’un transporteur ne devrait pas devenir une exigence universelle à la commande.
4. Adopter des durées opérationnelles courtes. Faire partir l’expiration d’un événement défini et documenter les prolongations liées aux retours, garanties ou litiges en cours.
5. Vérifier la suppression chez les sous-traitants. Les clauses contractuelles devraient être appuyées par des tâches de suppression, des rapports, des échantillonnages ou des droits d’audit couvrant les entrepôts, les transporteurs et les sous-traitants ultérieurs.
6. Concevoir les sauvegardes en fonction de l’expiration. Un enregistrement n’est pas véritablement supprimé s’il reste couramment restaurable et interrogeable depuis des sauvegardes à longue durée de vie. Lorsqu’un retrait immédiat est impraticable, limiter les restaurations et réappliquer la suppression avant que les données restaurées ne redeviennent actives.
7. Tenir les secrets hors du support. Le personnel, les formulaires et les outils automatisés ne devraient jamais demander de phrases de récupération, de clés privées ou de contenu du coffre. Les pièces jointes sensibles nécessitent des règles explicites de traitement et d’expiration.
8. Réduire ce que révèle un colis. Un emballage neutre, des coordonnées d’expéditeur génériques et des options légales de casier ou de retrait peuvent réduire l’association, mais aucune ne devrait être présentée comme garantissant l’anonymat.
9. Prévoir les exceptions sans les normaliser. Les éléments relatifs à un incident et les mesures de conservation légale nécessitent un périmètre consigné, une approbation, une date de réexamen et une procédure de levée.

Aucun contrôle ne rend le paysage statique. Les attaquants changent de tactiques, les dépendances logicielles évoluent, les chaînes logistiques se transforment et la réglementation change. La bonne réponse n’est pas une collecte sans limite « au cas où ». C’est une cartographie vivante des données, dont les finalités, les sous-traitants et les preuves de suppression sont réexaminés à mesure que le monde évolue.

Questions fréquentes

Le matériel Trezor a-t-il été piraté en août 2026 ?

Trezor affirme que non. Son avis du 13 août concernait un accès non autorisé chez ShipMonk et l’exposition de données logistiques. Trezor a déclaré que ses systèmes, portefeuilles matériels, clés privées et sauvegardes n’avaient pas été touchés. L’avis de Trezor ne nommait pas l’exploit ; BleepingComputer a ensuite rapporté que des courriels de ShipMonk reliaient l’accès à une vulnérabilité Metabase, que Metabase a identifiée comme CVE-2026-72898.

L’incident COLDCARD était-il une fuite de données clients ?

Aucune compromission d’une base de données clients n’a été établie en lien avec la vulnérabilité COLDCARD. Le problème confirmé concernait la génération des seeds : une erreur d’intégration du firmware permettait à un générateur de secours déterministe de fournir l’aléa. Une campagne d’hameçonnage distincte a ensuite exploité l’inquiétude publique liée à l’incident, mais les éléments publics ne montrent pas qu’elle ait utilisé une liste de clients Coinkite divulguée.

Quelles informations Trezor et SafePal ont-ils déclaré comme exposées ?

Trezor a signalé les noms, adresses e-mail, numéros de téléphone et adresses de livraison de 11 742 clients, ainsi que les noms, villes et adresses e-mail de 1 947 autres. SafePal a signalé les noms, adresses e-mail, numéros de téléphone, adresses de livraison et détails d’achat d’environ 39 798 clients. Il s’agit de chiffres déclarés par les entreprises, et non de totaux audités indépendamment ; aucune des deux entreprises n’a signalé l’exposition de secrets de portefeuille dans ces avis.

Le RGPD impose-t-il à une entreprise de portefeuilles matériels de ne collecter aucune donnée ?

Non. Lorsqu’il s’applique, le RGPD exige que les données personnelles soient adéquates, pertinentes et limitées à ce qui est nécessaire pour une finalité définie, et qu’elles ne soient pas conservées plus longtemps que nécessaire. Il impose aussi la protection des données dès la conception et par défaut. Cela soutient la minimisation, la séparation et les calendriers de suppression, mais ne crée pas une règle universelle de collecte nulle.

L’auto-garde exempte-t-elle automatiquement un fournisseur de la réglementation financière ?

Non. Le statut réglementaire dépend de ce que fait réellement un fournisseur, notamment du contrôle des clés, des pouvoirs de signature ou d’intervention, des services de transfert ou d’échange, des rôles liés aux smart contracts et des relations continues avec les clients. La seule vente de matériel ne suffit pas à trancher l’analyse. Les fonctionnalités de production et le rôle contractuel de CLAVI exigent donc un examen juridique propre à chaque juridiction avant d’affirmer toute exclusion de MiCA, de la Travel Rule, de l’AMLA, de DORA ou du CARF.

Que devrait signifier zero knowledge pour un Personal Vault ?

Pour un Personal Vault, zero knowledge devrait décrire une frontière technique précise : l’opérateur ne devrait ni recevoir les secrets du coffre de l’utilisateur ni pouvoir les récupérer. Cette expression ne devrait pas suggérer qu’une société en activité ne possède aucun dossier de commande, de facturation, de support ou de conformité. Ces dossiers commerciaux nécessitent des finalités, des contrôles d’accès et des calendriers de conservation distincts.

Pourquoi la suppression doit-elle être vérifiée auprès des prestataires logistiques et des autres sous-traitants ?

La politique de suppression d’un responsable du traitement ne peut réduire l’exposition si des copies restent actives chez un entrepôt, un transporteur, un prestataire de paiement, une plateforme de support, un fournisseur de sauvegarde ou un service marketing. Les contrats sont nécessaires, mais le contrôle le plus solide est une suppression vérifiable dans les systèmes de production, les répliques et les sauvegardes, assortie d’exceptions documentées pour les commandes non résolues ou une conservation légalement requise.

La position durable : aucun secret du coffre, moins de données commerciales, davantage de preuves

Le dossier client le plus sûr est celui qui n’entre jamais dans les systèmes de l’opérateur. Ce principe devrait s’appliquer avec le plus de rigueur aux clés privées, au matériel de récupération et au contenu protégé du coffre. Pour les informations plus limitées qu’une société en activité doit traiter, l’exigence est différente mais reste élevée : collecter moins, séparer les finalités, faire expirer les dossiers, vérifier la suppression en aval et documenter l’exception.

COLDCARD montre pourquoi la protection de la vie privée ne peut pas remplacer une mise en œuvre cryptographique solide. Trezor et SafePal montrent comment les systèmes commerciaux peuvent exposer des personnes alors que le matériel de portefeuille reste hors de l’incident signalé. Une définition plus honnête de la sécurité d’un Personal Vault doit protéger le secret, protéger la personne et identifier les données qui existent entre les deux.