Chapitre 1. Les données de paiement sont des données personnelles.
Le RGPD (règlement (UE) 2016/679, applicable depuis le 25 mai 2018) protège toute information se rapportant à une personne physique identifiée ou identifiable. Un IBAN, un numéro de carte (PAN), un identifiant de wallet ou un historique de transactions entrent pleinement dans cette définition, puisqu'ils identifient une personne. Surtout, ils racontent sa vie. Qui paie quoi, où, quand et combien révèle les déplacements, les habitudes, parfois la santé (pharmacie), les convictions (dons) ou la situation familiale.
Un contresens fréquent mérite d'être écarté. Les données financières ne sont pas des « données sensibles » au sens de l'article 9 du RGPD (qui vise santé, opinions, biométrie…). Mais le comité européen (EDPB) les classe parmi les données à caractère hautement personnel, qualification qui pèse dans l'analyse de risque : exigences de sécurité relevées, analyse d'impact (AIPD) souvent nécessaire, tolérance quasi nulle des autorités en cas de manquement.
Chapitre 2. Bases légales : quel fondement pour quel traitement ?
Tout traitement doit reposer sur l'une des six bases légales de l'article 6 du RGPD. Dans le paiement, quatre dominent : l'exécution du contrat, l'obligation légale, l'intérêt légitime et le consentement. L'erreur classique consiste à tout fonder sur le consentement, démarche inutile parce que le paiement d'une commande exécute le contrat sans exiger aucun consentement, et dangereuse parce qu'un consentement se retire à tout moment.
| Traitement | Base légale | Pourquoi |
|---|---|---|
| Encaisser le paiement d'une commande | Exécution du contrat | Sans traitement des données de carte, pas de vente : le traitement est nécessaire au contrat |
| Prélever les échéances d'un abonnement | Exécution du contrat | La conservation de la carte est nécessaire à l'exécution du contrat souscrit |
| Conserver la carte pour de futurs achats (paiement en 1 clic) | Consentement | Facilité offerte au client, non nécessaire au contrat : case à cocher, jamais pré-cochée, retirable à tout moment |
| Conserver la transaction à titre de preuve (13/15 mois) | Intérêt légitime / obligation légale | Se défendre en cas de contestation d'une opération non autorisée (art. L. 133-24 CMF) |
| Lutte contre la fraude (scoring, règles) | Intérêt légitime | Intérêt reconnu par la CNIL et le considérant 47 du RGPD, sous réserve de proportionnalité |
| KYC, screening, déclarations TRACFIN | Obligation légale | Le Code monétaire et financier impose ces traitements aux assujettis |
| Prospection commerciale à partir des données de paiement | Consentement | Finalité étrangère au paiement : elle exige un choix libre, spécifique et éclairé |
La doctrine de la CNIL sur la conservation de la carte est fixée par sa recommandation sur les données de carte de paiement (délibération n° 2018-303 du 6 septembre 2018). Le marchand ou son PSP peut conserver le numéro et la date d'expiration pour un abonnement, sur la base du contrat. La conservation destinée à faciliter des achats ultérieurs d'un client ponctuel exige, elle, son consentement explicite. Il se matérialise par un acte positif, une case à cocher dédiée, distincte des conditions générales.
Un dernier piège, plus subtil, tient à l'article 94, paragraphe 2, de la DSP2, qui exige le « consentement explicite » du client pour que son PSP traite ses données personnelles. L'EDPB l'a clarifié dans ses lignes directrices 06/2020 sur l'articulation DSP2/RGPD. Ce « consentement » est de nature contractuelle, une clause acceptée en connaissance de cause. Il ne constitue pas la base légale « consentement » du RGPD, les deux textes se superposant sans se confondre.
Chapitre 3. Minimisation et durées : 13/15 mois, CVV, LCB-FT.
Le principe de minimisation (article 5 du RGPD) impose de ne collecter que les données adéquates, pertinentes et limitées à la finalité. Un paiement de 30 € n'exige ni date de naissance, ni pièce d'identité, ni numéro de sécurité sociale. Son corollaire est la limitation de conservation. Chaque donnée a une durée de vie définie à l'avance, au terme de laquelle elle est supprimée ou anonymisée. Dans le paiement, ces durées sont largement fixées par la doctrine CNIL et par la loi.
| Donnée / finalité | Durée | Fondement |
|---|---|---|
| Données de carte pour réaliser la transaction | Jusqu'au paiement effectif complet (livraison comprise le cas échéant) | Exécution du contrat |
| Transaction conservée à titre de preuve | 13 mois après la date de débit, en archivage intermédiaire | Délai de contestation d'une opération non autorisée, art. L. 133-24 CMF |
| Idem, carte à débit différé | 15 mois (13 mois + décalage du débit) | Recommandation CNIL carte de paiement |
| Cryptogramme visuel (CVV) | Jamais conservé après l'autorisation de la première transaction | Doctrine CNIL constante + PCI DSS (donnée d'authentification sensible) |
| Carte enregistrée pour achats futurs (1 clic) | Jusqu'au retrait du consentement ou à l'expiration de la carte | Consentement, sans jamais inclure le CVV |
| Dossiers KYC et pièces LCB-FT | 5 ans après la fin de la relation d'affaires | Art. L. 561-12 CMF |
| Pièces comptables (factures, écritures) | 10 ans | Art. L. 123-22 du Code de commerce |
La CNIL distingue la base active (données accessibles aux équipes pour l'exploitation courante) de l'archivage intermédiaire (accès restreint à des personnes habilitées, pour un besoin défini : contentieux, contrôle). Les 13/15 mois de conservation à titre de preuve relèvent de l'archivage intermédiaire, où le service marketing n'a rien à faire. La purge doit être outillée et prouvable. Un engagement de conservation sans mécanisme de suppression automatique ne résiste pas à un contrôle.
retention_policy:
cvv:
stockage: interdit
commentaire: "purge memoire immediatement apres autorisation"
transaction_preuve:
zone: archivage_intermediaire
duree_mois: 13
duree_mois_debit_differe: 15
depart: date_de_debit
acces: ["conformite", "contentieux"]
carte_one_click:
base_legale: consentement
duree: "retrait du consentement ou expiration de la carte"
donnees: ["pan_tokenise", "date_expiration"]
dossier_kyc:
duree_annees: 5
depart: fin_de_relation_affaires
purge:
job: "quotidien 03:00 UTC"
preuve: "journal de purge horodate, conserve 3 ans"Chapitre 4. PSP : sous-traitant ou responsable de traitement ?
Toute la répartition des obligations RGPD découle de l'identification de celui qui détermine les finalités et les moyens du traitement. Celui-là est responsable de traitement. Celui qui traite pour le compte et sur instruction d'un autre est sous-traitant (article 28). Dans la chaîne de paiement, la réponse varie traitement par traitement, car un même PSP est souvent les deux à la fois.
| Acteur | Traitement | Qualification usuelle |
|---|---|---|
| Marchand | Gestion des commandes et encaissement de ses clients | Responsable de traitement |
| PSP / gateway | Traitement technique des paiements pour le marchand | Sous-traitant du marchand (contrat art. 28) |
| PSP / acquéreur | Obligations propres : KYC/KYB, LCB-FT, reporting réglementaire | Responsable de traitement distinct |
| PSP | Lutte contre la fraude mutualisée entre tous ses marchands | Responsable de traitement (finalités et moyens définis par lui) |
| Banque émettrice | Tenue du compte, autorisations, 3-D Secure côté porteur | Responsable de traitement |
| Wallet (Apple Pay, PayPal…) | Gestion du portefeuille et tokenisation côté utilisateur | Responsable de traitement |
Cette lecture « par finalité » est celle des lignes directrices 07/2020 de l'EDPB sur les notions de responsable et de sous-traitant. Elle explique la dualité assumée des grands PSP dans leurs contrats de protection des données (DPA). Ils sont sous-traitants pour les services rendus au marchand (encaissement, reporting), responsables pour leurs obligations réglementaires et leurs dispositifs anti-fraude mutualisés. En négociation de contrat, la vigilance porte sur un point précis, la frontière entre les deux rôles devant être décrite et pas seulement proclamée.
Le contrat de sous-traitance de l'article 28 n'est pas une formalité. Il fixe l'objet, la durée, la nature et la finalité du traitement, les catégories de données, les instructions documentées du responsable, la confidentialité et la sécurité. Il fixe aussi le régime des sous-traitants ultérieurs (autorisation préalable, obligations en cascade), l'assistance (droits des personnes, violations, AIPD), le sort des données en fin de contrat et le droit d'audit. Pour un marchand, auditer son PSP passe en pratique par les certifications (PCI DSS, ISO 27001) et les rapports de contrôle mis à disposition.
Chapitre 5. Transferts hors UE et violations de données.
La chaîne de paiement est mondiale par construction, entre réseaux internationaux, PSP américains, hébergeurs cloud et outils anti-fraude. Or le chapitre V du RGPD interdit de transférer des données personnelles hors de l'Espace économique européen sans garanties appropriées. Trois voies : la décision d'adéquation de la Commission, les clauses contractuelles types (CCT, version de juin 2021) complétées d'une analyse d'impact du transfert, ou les règles d'entreprise contraignantes (BCR).
En pratique, un marchand ou un PSP européen commence par cartographier les flux, en recensant les destinations des données de paiement, les entités du groupe concernées et les sous-traitants ultérieurs. Il vérifie ensuite pour chaque destinataire américain sa certification DPF active, puis couvre le reste du monde par CCT avec analyse des lois locales. Les données de paiement étant hautement personnelles, les autorités attendent un dossier de transfert particulièrement soigné.
Deuxième volet, celui des violations de données régies par les articles 33 et 34. Toute violation (confidentialité, intégrité ou disponibilité) doit être documentée dans un registre interne. Elle est notifiée à la CNIL dans les 72 heures de sa constatation dès lors qu'elle présente un risque pour les personnes, et communiquée aux personnes concernées sans délai indu si le risque est élevé. Dans le paiement, une fuite de PAN ou d'IBAN franchit presque toujours ces seuils, parce qu'elle ouvre la voie à la fraude directe.
Chapitre 6. PCI DSS, tokenisation et RGPD : l'articulation.
Reste à savoir comment le RGPD s'articule avec PCI DSS, le standard de sécurité des données de carte, ce qui suppose d'abord une clarification. PCI DSS n'est pas une loi, mais un référentiel édicté par le PCI Security Standards Council (fondé par les réseaux Visa, Mastercard, Amex, Discover, JCB) et imposé par contrat le long de la chaîne d'acceptation. La version 4.0 est obligatoire depuis le 31 mars 2024, ses exigences « futures » étant exigibles depuis le 31 mars 2025 (version 4.0.1).
| RGPD | PCI DSS v4.x | |
|---|---|---|
| Nature | Règlement européen, force de loi | Standard privé, imposé par contrat |
| Données couvertes | Toutes les données personnelles | Données de carte (PAN, pistes, CVV, PIN) |
| Objectif | Protéger les droits et libertés des personnes | Prévenir la compromission des données de carte |
| Qui contrôle | CNIL et autorités européennes | QSA (auditeurs certifiés), acquéreurs, réseaux |
| Sanctions | Jusqu'à 20 M€ ou 4 % du CA mondial | Pénalités contractuelles, hausse des frais, exclusion des réseaux |
| Zone de recouvrement | Sécurité des traitements (art. 32) | Les 12 exigences de sécurité techniques et organisationnelles |
Être conforme PCI DSS aide puissamment à satisfaire l'article 32 du RGPD (sécurité du traitement) pour le périmètre carte (chiffrement, segmentation, contrôle d'accès, journalisation, tests). Mais conformité PCI ≠ conformité RGPD. PCI DSS laisse de côté les bases légales, l'information des personnes, les durées de conservation hors CVV, les droits et les transferts. Inversement, le RGPD couvre l'IBAN, les données 3-D Secure ou les scores de fraude, hors du périmètre PCI.
La tokenisation remplace le PAN par un jeton inutilisable hors de son contexte. Elle sert les deux mondes, puisqu'elle réduit drastiquement le périmètre PCI DSS du marchand (le PAN ne touche plus ses systèmes) et constitue une pseudonymisation exemplaire au sens du RGPD. Pseudonymisation n'est pourtant pas anonymisation. Tant que le détokeniseur rend le porteur identifiable, le jeton reste une donnée personnelle et le RGPD continue de s'appliquer intégralement.
Vient enfin l'analyse d'impact (AIPD) de l'article 35, exigée quand un traitement est susceptible d'engendrer un risque élevé. La liste adoptée par la CNIL en 2018 vise notamment les traitements mutualisés de manquements contractuels (listes noires de fraudeurs partagées) et les profilages s'appuyant sur des sources externes. Le scoring anti-fraude à grande échelle d'un PSP coche presque toujours ces cases. L'AIPD documente le risque et les mesures retenues, et elle fait la différence lors d'un contrôle.