En bref : la conformité au RGPD dépend de votre rôle dans le traitement des données, pas du modèle de conservation des fonds
Un modèle non dépositaire ne vous dispense pas de respecter le RGPD. Celui-ci porte sur les données à caractère personnel, les finalités du traitement et le rôle de chaque partie. Si une passerelle ou un commerçant traite des noms, des adresses e-mail, des traces de portefeuille, des messages d’assistance ou même une empreinte numérique de l’appareil, le RGPD peut s’appliquer.
La question « une passerelle de paiement crypto non dépositaire est-elle conforme au RGPD ? » semble appeler une réponse par oui ou par non, mais la réalité juridique est plus complexe. Une passerelle peut ne pas détenir les fonds de ses clients et néanmoins traiter des données à caractère personnel en permanence lorsqu’elle gère le paiement, les journaux, les contrôles antifraude ou l’assistance client. Le modèle de conservation des fonds compte pour la conception de la sécurité ; à lui seul, il ne détermine pas la conformité au RGPD. Il est donc utile de se demander : « une passerelle crypto non dépositaire est-elle soumise au RGPD » ? La réponse dépend des données traitées et des rôles de chaque partie.
Prenons un paiement simple. Un client paie en USDC et le système enregistre un numéro de commande, une adresse de portefeuille, un horodatage et une adresse IP. Cela suffit déjà à justifier un examen au regard du RGPD si le paiement peut être associé à une personne identifiable — ce qui est souvent possible grâce aux factures, aux données de compte ou aux échanges avec l’assistance.
Pour les commerçants, la vraie question est plus précise : qui décide pourquoi les données sont collectées et qui en détermine les moyens ? La réponse permet de savoir si le commerçant est responsable du traitement, si la passerelle est sous-traitante ou si les deux parties partagent la responsabilité. En pratique, il faut notamment déterminer « qui est responsable du traitement des données d’un paiement crypto ». Une seule étiquette ne convient que rarement à tous les processus.
Quelles parties sont généralement responsables du traitement, sous-traitantes ou responsables conjointes ?
Dans un parcours de paiement crypto classique, le commerçant est généralement responsable du traitement des données client liées à la vente. C’est lui qui décide des produits vendus, des données conservées et de la durée de conservation de l’historique d’achat dans le système de commandes. Son activité relève donc clairement du RGPD.
Un fournisseur de passerelle peut agir en qualité de sous-traitant s’il traite les données uniquement sur les instructions du commerçant. C’est souvent le cas lorsqu’il affiche la page de paiement, crée les instructions de paiement et transmet les mises à jour de statut. Si le fournisseur décide également de réutiliser les données à des fins d’analyse produit, d’évaluation des risques ou pour alimenter sa propre base de clients, son rôle peut changer. Il peut alors devenir responsable du traitement pour ces finalités distinctes.
Les infrastructures de portefeuille, les outils d’indexation de blockchain, les fournisseurs d’analytique et les hébergeurs interviennent généralement en arrière-plan comme sous-traitants ou sous-traitants ultérieurs, mais tout dépend des faits. Un opérateur de nœud qui fournit uniquement une infrastructure technique peut être peu exposé. En revanche, un service qui rapproche les transactions de plusieurs commerçants peut relever de la responsabilité du traitement, voire de la responsabilité conjointe.
La responsabilité conjointe n’a rien d’exceptionnel. Elle peut exister lorsque le commerçant et la passerelle déterminent ensemble certains aspects d’une même opération de traitement, par exemple des règles communes de détection de fraude ou un parcours de paiement co-marqué. Dans ce cas, les deux parties doivent conclure un accord écrit précisant qui gère les avis d’information, les demandes d’accès et les incidents de sécurité. Trois mots sont essentiels : qui fait quoi.
Les équipes commerciales oublient souvent le rôle des outils d’assistance. Un centre d’assistance qui conserve des captures d’écran envoyées par les clients, des e-mails concernant des remboursements et des captures de portefeuille ne fait pas « que de l’assistance ». Il traite des données à caractère personnel, et son contrat avec le fournisseur doit le préciser. Il en va de même pour les systèmes de gestion des tickets et les outils CRM.
Quelles données à caractère personnel une passerelle non dépositaire peut-elle encore traiter ?
Non dépositaire ne signifie pas sans données. Pour déterminer « quelles données personnelles traite une passerelle de paiement crypto », il faut notamment examiner les adresses IP, les adresses e-mail, les adresses de portefeuille, les données sur l’appareil, les identifiants de transaction, la langue du navigateur, les références de facture et les notes de remboursement. Chacun de ces éléments peut devenir une donnée à caractère personnel dès lors qu’il peut être associé, directement ou indirectement, à une personne.
Les adresses de portefeuille méritent une attention particulière. À première vue, elles peuvent ressembler à de simples suites de caractères aléatoires. En pratique, une adresse peut être reliée à un client par l’intermédiaire d’un compte, d’une facture, d’un échange avec l’assistance, d’une étiquette d’expédition ou d’un dossier KYC. Un seul identifiant peut révéler bien plus qu’il n’y paraît.
Les journaux constituent un autre piège. Un journal serveur conservé pendant 90 jours peut contenir des adresses IP, des en-têtes de requête, des schémas d’horodatage et des messages d’erreur. Si ces journaux peuvent être recherchés par adresse e-mail ou numéro de commande, le système devient une cartographie de l’activité des clients. Cela suffit à soulever des questions au regard du RGPD, même si les fonds ne transitent jamais par le bilan de la passerelle.
Les demandes d’assistance peuvent contenir des données plus sensibles que celles du paiement. Un client peut joindre une capture de son portefeuille, le hash d’une transaction échouée ou une adresse personnelle liée à un problème de livraison. Ce petit ensemble d’informations peut révéler des habitudes d’achat, une localisation et la titularité d’un compte. Le RGPD ne fait pas de distinction selon que les données ont été communiquées dans le cadre d’une « simple question ».
Les factures et les reçus comptent aussi. Ils peuvent contenir des noms, des adresses de facturation, des numéros de TVA, des identifiants fiscaux ou des détails de commande. Si le commerçant utilise la même référence de facture sur la blockchain et dans son système interne, le lien devient plus évident. Une transaction sur une blockchain peut être pseudonyme tout en restant liée à un client identifiable.
Les bases juridiques du RGPD les plus pertinentes pour le paiement crypto
Pour la plupart des commerçants, l’exécution du contrat est la première base juridique à examiner. Si le client paie des biens ou des services, la passerelle a besoin de certaines données pour traiter la commande et confirmer le paiement. Ce traitement est souvent nécessaire à l’exécution du contrat.
L’obligation légale vient ensuite. Les règles fiscales et comptables, les contrôles antifraude et les obligations de conservation peuvent imposer de conserver certaines données pendant une durée déterminée. La durée exacte dépend du pays et du type de document ; un avocat ou un délégué à la protection des données devra parfois confirmer la règle applicable.
L’intérêt légitime peut également justifier certains traitements, notamment la prévention de la fraude, l’intégrité du service, la détection des abus et certaines analyses limitées. Cette base ne s’applique pas automatiquement. Une mise en balance doit vérifier si le client peut raisonnablement s’attendre à ce traitement, si les données sont limitées au nécessaire et si le commerçant peut atteindre le même objectif de manière moins intrusive.
Le consentement est souvent une mauvaise option par défaut pour le traitement essentiel au paiement. Si le paiement ne peut fonctionner sans certaines données, demander le consentement risque de créer un faux choix. Le consentement peut rester utile pour le marketing facultatif, des analyses supplémentaires ou le suivi par cookies, mais pas pour le simple fait d’accepter un paiement. Cette distinction est importante.
Une règle pratique peut aider : lorsque c’est possible, rattachez les données de paiement à l’exécution du contrat ou à une obligation légale et réservez le consentement aux fonctionnalités réellement facultatives. Cette approche réduit les frictions et rend le parcours de paiement plus transparent. Elle évite aussi les bandeaux de consentement surchargés qui prétendent tout couvrir.
Si vous cartographiez le parcours de paiement côté commerçant, le guide sur les passerelles de paiement crypto pour le commerce en ligne peut vous aider à comprendre les détails de mise en œuvre qui ont un effet sur le traitement des données, comme les mises à jour du statut des commandes et l’emplacement du module de paiement.
Minimisation des données et protection de la vie privée dès la conception des parcours de paiement
La minimisation des données est le point de départ le plus simple. Ne collectez que ce dont le parcours de paiement a réellement besoin. Si la commande peut être finalisée sans date de naissance, ne la demandez pas. Si une adresse e-mail de facturation suffit, n’ajoutez pas un autre identifiant. De petits choix réduisent rapidement les risques.
Les journaux doivent être limités de façon réfléchie. Ne conservez que les champs nécessaires au dépannage, à la sécurité et au traitement des litiges. Il est rarement justifiable de garder pendant 12 mois un historique complet des portefeuilles, des traces IP détaillées et chaque en-tête de requête sans raison claire. Une durée de conservation plus courte est souvent préférable.
Dans la mesure du possible, séparez les données de facturation des données de la blockchain. Le commerçant peut conserver le profil client dans un système et la référence de transaction sur la chaîne dans un autre, en les reliant au moyen d’un jeton interne ou d’un numéro de commande. Cette séparation n’efface pas les obligations liées au RGPD, mais elle limite les dégâts en cas de compromission d’un système.
La protection de la vie privée dès la conception n’est pas qu’un slogan. Elle signifie que, par défaut, le parcours de paiement évite les champs superflus, les notes de transaction publiques et l’affichage inutile de métadonnées sensibles. Un client ne devrait pas avoir à chercher un réglage caché pour obtenir une facture simple. La conception doit protéger la vie privée dès le départ.
Les limites de conservation doivent être définies avant le lancement, et non après la première réclamation. Un e-mail d’assistance vieux de six mois peut encore se trouver dans la boîte de réception si personne n’a fixé de règle. Il en va de même pour les exports d’analytique, les rapports de paiements échoués et les archives de webhooks. Supprimer les anciennes données demande un effort, mais c’est plus simple que de justifier pourquoi elles ont été conservées indéfiniment.
Pour obtenir une liste pratique de vérifications à effectuer avant de traiter du trafic réel, consultez comment tester un paiement crypto. Un environnement de test est le meilleur endroit pour repérer les mauvais réglages par défaut.
Transferts internationaux de données et considérations liées à l’hébergement
Une infrastructure répartie sur plusieurs pays peut vite compliquer la conformité au RGPD. Si des nœuds, serveurs, centres d’assistance ou systèmes d’analytique se trouvent hors de l’EEE, le commerçant doit examiner les règles de transfert. Un parcours de paiement peut être non dépositaire tout en transférant des données à caractère personnel vers les États-Unis, le Royaume-Uni ou une autre région.
Les transferts ne sont pas interdits, mais ils nécessitent un mécanisme juridique et une évaluation du fournisseur. Les clauses contractuelles types peuvent être pertinentes, tout comme une décision d’adéquation lorsqu’il en existe une. Ce n’est qu’un début. Le commerçant doit également vérifier ce que le fournisseur fait réellement avec les données, et pas seulement où se trouve le serveur.
Les détails de l’hébergement comptent, car les systèmes de sauvegarde peuvent se trouver dans un autre pays que l’application principale. Il en va de même pour les outils de surveillance, les outils de suivi des erreurs et les plateformes d’assistance client. Héberger une page de paiement dans l’EEE ne suffit pas si les journaux sont copiés chaque heure vers un service d’analytique externe.
L’évaluation des fournisseurs doit répondre à trois questions : où les données sont-elles stockées, qui peut y accéder et quels sous-traitants ultérieurs interviennent ? Les réponses doivent être fournies par écrit. Une promesse commerciale ne suffit pas.
Le commerçant doit aussi vérifier si l’infrastructure blockchain est interrogée par l’intermédiaire d’un indexeur tiers, car celui-ci peut recueillir des métadonnées de transaction et des journaux d’adresses IP. Ce point est souvent négligé parce que la blockchain elle-même semble décentralisée. Le véritable enjeu de transfert se situe généralement dans les services qui l’entourent.
Politique de confidentialité, registres et contrats de sous-traitance à prévoir
L’avis de confidentialité est le premier point de contact. Il doit expliquer quelles données sont collectées, pourquoi elles le sont, à qui elles sont communiquées, combien de temps elles sont conservées et quels droits le client peut exercer. Si le paiement fait intervenir des adresses de portefeuille, des identifiants de facture et des coordonnées communiquées à l’assistance, il faut les désigner clairement.
Le registre des activités de traitement (RAT, ou RoPA en anglais) reste important, même pour les petites équipes, dès que leurs traitements ne sont pas anodins. Il doit répertorier les catégories de données, les finalités, les destinataires, les durées de conservation et les destinations des transferts. Oui, c’est de la paperasse. C’est aussi la preuve que quelqu’un a réfléchi au parcours de bout en bout.
Les contrats de sous-traitance sont indispensables lorsqu’un fournisseur agit sur les instructions du commerçant. Un accord de traitement des données doit couvrir les mesures de sécurité, les délais de notification en cas de violation, la sous-traitance ultérieure, l’effacement des données à la fin du contrat et l’assistance en cas d’audit. Si la passerelle recourt à des fournisseurs externes pour l’hébergement, l’analytique ou l’envoi d’e-mails, ceux-ci doivent également être répertoriés.
Les règles de conservation doivent être explicites. Le commerçant doit savoir combien de temps les données de facturation et les journaux sont conservés, et quand les paiements échoués sont supprimés. Une règle sans échéance n’est qu’un vœu pieux. Cela ne suffit pas au regard du RGPD.
Les procédures en cas de violation doivent figurer dans le même dossier. Si une adresse de portefeuille, une adresse e-mail ou une base de données de factures est exposée, le commerçant doit disposer d’un processus de triage, d’un responsable interne et d’un calendrier de signalement. Lorsque plusieurs fournisseurs sont impliqués, les retards peuvent rapidement coûter cher.
Liste de vérification pratique pour évaluer une passerelle
Commencez par cartographier les rôles. Indiquez qui est responsable du traitement, qui est sous-traitant et dans quels cas une responsabilité conjointe peut s’appliquer. Si les rôles varient selon les fonctionnalités, précisez-le aussi. Un même parcours de paiement peut impliquer trois rôles juridiques différents selon les données traitées.
Demandez ensuite une cartographie des données. Quels champs sont stockés ? Lesquels sont consignés dans les journaux ? Lesquels sont envoyés aux systèmes d’analytique, d’assistance ou d’hébergement ? Si un fournisseur ne peut pas répondre lors d’un seul entretien, c’est un signal d’alerte. Un système bien défini laisse des traces claires.
Vérifiez ensuite les durées de conservation et les procédures d’effacement. Demandez la durée par défaut de conservation des journaux, celle des factures et la procédure d’effacement des commandes annulées et des demandes d’assistance. Si le fournisseur répond « nous conservons les données aussi longtemps que nécessaire », demandez des durées précises. Sans chiffres, il n’y a pas de contrôle.
Examinez la base juridique de chaque finalité de traitement. La confirmation du paiement peut relever de l’exécution du contrat, les documents fiscaux d’une obligation légale et certaines opérations de surveillance de l’intérêt légitime. Le marketing doit être séparé du parcours de paiement essentiel. Une finalité par ligne vaut mieux qu’un paragraphe vague.
Vérifiez les garanties encadrant les transferts. Si les données d’assistance, de télémétrie ou d’analytique quittent l’EEE, demandez quel mécanisme de transfert est utilisé et quels pays sont concernés. Ne supposez pas que la réponse est la même pour tous les services. Un commerçant qui stocke ses journaux en Allemagne peut tout de même envoyer les données de ses tickets vers une autre région.
Avant le lancement, demandez le contrat de sous-traitance, la liste des sous-traitants ultérieurs, la procédure en cas de violation et un projet d’avis de confidentialité. Si ces documents n’existent pas, le commerçant n’est pas prêt. Si la passerelle doit gérer des demandes d’assistance portant sur des transactions sensibles ou de grands volumes de données client, consultez un avocat ou un délégué à la protection des données avant de signer.
Pour les commerçants qui prévoient des factures récurrentes ou la facturation de clients, l’article sur les passerelles de paiement crypto pour les travailleurs indépendants est utile : les données de facturation, l’identité du client et les historiques de paiement se recoupent souvent et influencent les décisions liées au RGPD. Le chevauchement semble limité, puis il prend soudain beaucoup d’ampleur.
Si la passerelle doit se connecter à des outils d’automatisation, examinez chaque application en aval. Un webhook qui transmet les détails d’une commande à un CRM peut rapidement diffuser des données à caractère personnel. Pour découvrir un exemple pratique d’intégration, consultez comment connecter Payora à Zapier. Une étape supplémentaire peut ajouter trois nouveaux sous-traitants.
Dernière vérification : demandez au fournisseur d’expliquer clairement pourquoi chaque champ existe. S’il répond « parce que nous l’avons toujours collecté », arrêtez-vous là. Une passerelle de paiement crypto non dépositaire peut tout à fait être compatible avec le RGPD, à condition que le commerçant maîtrise ses pratiques en matière de données avec autant de soin que le parcours de paiement lui-même.
Comments