Qu’est-ce qu’une demande d’accès aux données dans ce contexte ?
Une demande d’accès aux données, ou DSAR (de l’anglais « data subject access request »), est une demande légale par laquelle une personne cherche à savoir si ses données personnelles sont traitées et à en obtenir une copie, ainsi que certaines précisions sur leur utilisation. En termes simples, elle peut demander : « Quelles données détenez-vous à mon sujet ? » Une demande d’accès aux données personnelles paiement crypto peut concerner des informations recueillies lors d’un paiement en cryptomonnaie. Ce type de demande n’a rien de rare. Elle peut concerner une infrastructure de paiement crypto auto-hébergée si celle-ci traite des données sur une personne réelle, et pas seulement des mouvements de cryptomonnaies.
Cet article pose une question plus précise : si un commerçant exploite la passerelle sur son propre serveur, une passerelle de paiement crypto auto-hébergée est-elle soumise aux demandes d’accès aux données en vertu du droit de la protection des données ? La réponse courte est souvent oui, mais uniquement pour les données qui constituent des données personnelles et lorsque l’opérateur est effectivement en mesure de répondre. Un système de paiement par blockchain n’échappe pas à ces règles sous prétexte qu’il est auto-hébergé.
Une DSAR n’est pas une demande de remboursement, ni un ticket d’assistance. La personne à l’origine de la demande peut vouloir consulter des échanges par e-mail, son historique de paiement ou des journaux d’adresses IP. L’opérateur doit alors examiner sa demande au regard des données qu’il détient réellement.
Qui est considéré comme responsable du traitement pour une passerelle de paiement crypto auto-hébergée ?
En pratique, tout est une question de contrôle. Si le commerçant décide quelles données client sont recueillies au moment du paiement, pourquoi elles sont recueillies et combien de temps elles sont conservées, il peut être le responsable du traitement pour ces opérations. C’est important, car c’est généralement au responsable du traitement que la DSAR est adressée et qui doit y répondre.
Un commerçant qui héberge sa propre infrastructure de paiement prend souvent ces décisions directement. Il définit les champs du formulaire de paiement et décide s’il faut demander une adresse e-mail, un nom de facturation ou une note de livraison. Il peut également choisir de consigner des métadonnées de portefeuille pour détecter les fraudes ou assurer l’assistance.
Toutes les parties de la chaîne ne sont pas responsables du traitement. Un hébergeur peut n’agir qu’en qualité de sous-traitant. Un développeur peut simplement assurer la maintenance du code. Le commerçant peut tout de même être celui qui porte la responsabilité juridique, même si le serveur se trouve dans un centre de données et que le portefeuille est sur la blockchain.
Un test simple peut aider : demandez-vous qui a décidé qu’il fallait « collecter ces données » et « les conserver ». Si c’est le commerçant, il est probablement responsable du traitement pour cette partie de la passerelle de paiement crypto auto-hébergée.
Quelles parties d’un parcours de paiement crypto sont généralement concernées par une DSAR ?
Le périmètre d’une DSAR est généralement moins vaste qu’on ne le craint, mais il n’est pas négligeable. Pour savoir quelles données fournir lors d’une demande d’accès RGPD, commencez par examiner les données d’identité saisies au paiement, les adresses e-mail, les adresses IP, les journaux de transaction associés à une personne, les tickets d’assistance et les notes internes permettant d’identifier quelqu’un. Ces éléments peuvent se trouver dans différents systèmes, ce qui complique les recherches par rapport à une simple requête dans une base de données.
Prenons l’exemple d’un paiement où un client saisit son adresse e-mail, choisit une cryptomonnaie et ajoute un message du type « commande pour mon entreprise ». Ce message peut désigner une personne nommément. L’adresse e-mail est, de toute évidence, une donnée personnelle. L’adresse IP peut l’être aussi si le commerçant est en mesure de la rattacher à un utilisateur.
Les tickets d’assistance sont faciles à oublier. Ils contiennent souvent des informations très franches, et un même ticket peut réunir une adresse de portefeuille, une discussion sur un remboursement et un problème de livraison. Les notes internes peuvent également être concernées lorsqu’elles identifient une personne ou expliquent une décision prise à la suite d’un examen manuel.
Les journaux demandent une attention particulière. Une ligne indiquant simplement « facture payée » peut être moins sensible qu’une ligne reliant une facture au nom d’un client. C’est ce lien qui change la donne : il fait passer les données de simples informations de paiement à des données personnelles.
Pour savoir par où commencer avec les données de paiement, le guide sur les passerelles de paiement crypto pour le commerce en ligne présente les champs que les commerçants ont tendance à recueillir. C’est important ici, car chaque champ ajouté au formulaire de paiement peut élargir le périmètre des recherches à effectuer en cas de DSAR.
L’utilisation d’adresses de portefeuille ou de données de blockchain change-t-elle le traitement d’une DSAR ?
Oui, mais pas de la manière simple à laquelle beaucoup d’équipes s’attendent. Une adresse de portefeuille ne constitue pas toujours, à elle seule, une donnée personnelle. Elle a beaucoup plus de chances d’en être une si la passerelle peut la relier à un client au moyen de ses commandes, de tickets d’assistance, de données de compte ou de l’historique des adresses IP. Les données de la blockchain ne sont pas isolées des systèmes internes du commerçant.
La blockchain n’est généralement pas le seul sujet à prendre en compte. Une empreinte de transaction publique peut rester inscrite sur la chaîne pour toujours, mais la question de la DSAR dépend souvent du lien hors chaîne. Si le commerçant sait que le portefeuille X appartient à Alice, les informations relatives à ce portefeuille peuvent alors faire partie des données personnelles d’Alice.
Il en résulte une situation délicate. Les données sur la chaîne peuvent être immuables, contrairement à la base de données, aux journaux et aux notes du commerçant. Celui-ci ne peut pas effacer la blockchain à sa guise, mais il peut tout de même devoir expliquer les données qu’il détient, les raisons de leur conservation et l’endroit où se trouve le lien avec la personne concernée.
Une bonne habitude consiste à considérer les adresses de portefeuille comme potentiellement identifiantes dès lors que la passerelle peut les associer, même indirectement, à une personne. Cette approche prudente fait gagner du temps lorsqu’une DSAR arrive et qu’on vous demande « tous les dossiers liés à mes paiements ».
Pour les commerçants qui comparent les différentes options d’intégration, le guide d’intégration de l’API Payora pour les paiements crypto est pertinent, car la conception de l’API détermine souvent les informations consignées dans les journaux, les tableaux de bord et les exports. Quelques champs supplémentaires dans une requête API peuvent alourdir le traitement d’une DSAR par la suite.
Dans quels cas l’opérateur d’une passerelle auto-hébergée peut-il refuser ou limiter une DSAR ?
Il existe des limites. L’opérateur d’une passerelle auto-hébergée peut généralement refuser une DSAR ou en restreindre le périmètre s’il ne peut pas identifier le demandeur, si la demande est manifestement infondée ou excessive, ou si une autre obligation légale empêche une communication complète. Ces exceptions existent bel et bien, mais elles ne constituent pas un passe-droit.
Il faut d’abord vérifier l’identité. Si la personne ne peut pas être associée aux dossiers, l’opérateur risque de ne pas pouvoir répondre de façon utile. C’est différent d’un refus motivé par le fait que la recherche est fastidieuse. Une demande valable émanant d’un utilisateur identifiable exige tout de même un travail de recherche.
Les obligations légales de conservation peuvent également limiter la communication des données. Un commerçant peut être tenu de conserver certains éléments pour des raisons fiscales, comptables, de lutte contre la fraude ou de sécurité. Dans ce cas, l’opérateur ne prétend pas que les données n’existent pas : il explique pourquoi leur suppression ou leur communication intégrale peut être limitée.
Les données de sécurité peuvent elles aussi être sensibles. Si un journal contient des indicateurs de menace internes ou des schémas d’abus, l’opérateur devra peut-être mettre en balance le droit d’accès et le risque de révéler ses mesures de protection. Cet arbitrage doit être documenté, et non improvisé.
Les demandes excessives posent un autre problème. Une demande portant sur « tout depuis 2021 », sans nom, adresse e-mail ni détail de transaction, peut nécessiter des précisions avant de lancer un export. Deux questions de suivi peuvent faire gagner une semaine.
Que doit faire en premier l’opérateur d’une passerelle après avoir reçu une DSAR ?
Commencez par vérifier l’identité du demandeur. Confirmez ensuite le périmètre de la demande. Ces deux étapes doivent précéder tout export, car communiquer des données à la mauvaise personne peut en soi créer un problème.
Repérez ensuite les systèmes susceptibles de contenir des données personnelles. Une passerelle de paiement crypto auto-hébergée peut en stocker dans la base de données du paiement, les journaux de l’application, les relevés de paiement, les outils d’assistance par e-mail et les notes d’administration. Une seule demande peut concerner ces cinq sources.
Distinguez ensuite les données personnelles des simples données de paiement. Une empreinte de transaction seule peut ne pas suffire. En revanche, un identifiant de commande associé à un nom change la donne. C’est à ce stade que l’opérateur doit déterminer quels éléments inclure dans sa réponse et lesquels en exclure.
Il faut identifier rapidement les sous-traitants. Si un fournisseur de service d’assistance, de messagerie ou de surveillance détient des données pertinentes, le commerçant devra peut-être lui demander d’effectuer une recherche ou un export. Il est difficile de traiter correctement une DSAR si une partie des données se trouve hors des serveurs de l’opérateur.
La marche à suivre est simple : vérifier, préciser, rechercher, classer, répondre. Cinq étapes, sans complication. Cet ordre évite que la réponse ne se transforme en une pile de captures d’écran et de journaux examinés à la hâte.
Comment traiter les réponses aux DSAR lorsque la passerelle fonctionne sur une infrastructure auto-hébergée ?
Une DSAR et passerelle de paiement crypto auto-hébergée impliquent les mêmes obligations que les autres traitements, mais les modalités changent : les données se trouvent là où le commerçant les a stockées. L’opérateur doit donc disposer d’un inventaire clair des serveurs, bases de données, espaces de stockage d’objets, fichiers journaux et sauvegardes. Sans cet inventaire, toute réponse relève de l’improvisation.
La personne en mesure d’exporter les données compte autant que l’endroit où elles sont stockées. Si un seul ingénieur connaît le mot de passe administrateur, le processus de traitement des DSAR est fragile. Si le commerçant ne peut effectuer des recherches que manuellement dans la base de données, il risque de passer à côté de journaux ou de discussions d’assistance. Il faut documenter une procédure d’export de base avant de recevoir la première demande.
Les recherches doivent couvrir les données actuelles ainsi que les données récentes. Un client peut avoir utilisé une adresse e-mail lors de son inscription et une autre dans ses échanges avec l’assistance. Les notes internes peuvent mentionner un pseudonyme. C’est pourquoi une recherche portant sur un seul champ ne suffit souvent pas.
L’opérateur doit également consigner les motifs de ses décisions. Si certaines données sont exclues parce qu’elles ne sont pas personnelles ou qu’elles relèvent d’une autre restriction légale, la justification doit figurer dans le dossier. Ainsi, la demande suivante ne sera pas traitée uniquement de mémoire.
Si l’équipe de la passerelle affine encore ses parcours de paiement, l’article expliquant comment tester un paiement crypto peut être utile avant le lancement. C’est également pendant les tests que les équipes découvrent quels journaux sont créés — et c’est souvent une surprise.
Petite parenthèse : nombre d’opérateurs ne découvrent l’existence d’un ancien journal de débogage qu’à l’occasion d’une DSAR. Quelqu’un finit alors par dire : « On avait oublié que ce fichier existait. » Cette phrase ne devrait jamais être le premier rempart.
Que doit prévoir une politique de traitement des DSAR pour les passerelles de paiement crypto auto-hébergées ?
Une politique prête à traiter les DSAR doit indiquer par quels canaux les demandes peuvent être présentées. Si elles peuvent arriver par e-mail, via un formulaire web ou un ticket d’assistance, précisez-le. Si elles doivent être accusées réception dans un délai donné, indiquez ce délai. Le silence n’est pas une bonne politique.
Les contrôles d’identité doivent également être définis par écrit. Précisez les justificatifs demandés, la personne chargée de les vérifier et la marche à suivre si la demande est présentée depuis un compte qui n’existe plus. Cette étape permet d’éviter les différences de traitement entre les clients.
La politique doit aussi prévoir les règles de masquage. Tous les dossiers ne peuvent pas être communiqués intégralement. Une demande peut contenir le nom d’une autre personne, une note d’un membre du personnel ou un indicateur de fraude. La politique doit préciser comment ces éléments seront supprimés ou résumés.
La politique doit recenser les systèmes susceptibles de contenir des données client. Une courte liste suffit : base de données des paiements, journaux, service d’assistance, sauvegardes, outils d’analyse et notes d’administration. Un inventaire vaut mieux qu’un exercice de mémoire.
Il est utile de préciser les étapes de transmission. Si un sous-traitant détient des données, indiquez qui le contacte et dans quel délai. Si l’intervention d’un développeur est nécessaire pour lancer un export, précisez qui autorise cet accès. Une politique de traitement des DSAR qui repose sur des échanges informels ne mérite pas vraiment son nom.
Pour les équipes qui souhaitent comparer les fonctionnalités avant de choisir une infrastructure, l’article sur les évolutions des passerelles de paiement crypto apporte un éclairage utile sur leur fonctionnement actuel. Ces évolutions comptent, car davantage d’automatisation peut entraîner le stockage d’une plus grande quantité de données, et plus il y a de données, plus il y a d’éléments à rechercher lorsqu’une demande arrive.
Dernier point pratique : si l’opérateur de la passerelle travaille aussi avec des indépendants, l’article sur les passerelles de paiement crypto pour les indépendants montre que les données de facturation et les coordonnées des clients se recoupent souvent. Ce chevauchement peut compliquer une DSAR, car une même facture peut contenir à la fois une preuve de paiement et des coordonnées personnelles.
Une politique qui se contente d’indiquer « nous traitons les DSAR au cas par cas » est trop vague. Une procédure en sept étapes, qui nomme les systèmes concernés et désigne une personne responsable de la réponse, fournit à l’opérateur un véritable outil dès le premier jour, et pas seulement une promesse à ressortir en période d’audit.
Comments