La protection des données des titulaires de carte est au cœur des exigences PCI DSS. Comprendre précisément quelles données sont concernées, comment elles doivent être protégées et comment la tokenisation élimine la nécessité de les stocker est essentiel pour tout marchand ou prestataire de services traitant des paiements par carte en Europe.
Quelles données sont classées comme données de titulaires de carte ?
PCI DSS distingue deux catégories de données sensibles liées aux paiements par carte. Les données de titulaires de carte (CHD) incluent : le PAN (numéro de carte complet), le nom du titulaire, la date d'expiration de la carte, et le code de service (les trois chiffres sur la bande magnétique qui définissent les conditions d'utilisation de la carte). Ces données peuvent être stockées sous conditions strictes.
Les données d'authentification sensibles (SAD) incluent : les données complètes de la piste magnétique (track data), le code CAV2/CVC2/CVV2/CID (le code à 3 ou 4 chiffres imprimé sur la carte), et les données de bloc PIN. Ces données ne peuvent jamais être stockées après autorisation de la transaction, même sous forme chiffrée — c'est une interdiction absolue de PCI DSS.
Il est important de comprendre que la simple transmission de ces données suffit à faire entrer un système dans le périmètre CDE, même si ces données ne sont pas stockées. Un serveur proxy qui relaie des données de carte sans les stocker est néanmoins dans le périmètre PCI DSS et doit respecter l'ensemble des exigences applicables.
Les obligations de stockage selon PCI DSS v4.0
PCI DSS version 4.0 (entrée en vigueur en mars 2024) maintient et renforce les exigences de protection du stockage. L'exigence 3.3 est catégorique : les SAD ne doivent jamais être stockées après autorisation. L'exigence 3.4 impose que le PAN soit rendu illisible partout où il est stocké — par troncature (afficher uniquement les 6 premiers et 4 derniers chiffres), hachage unidirectionnel, chiffrement fort (AES-256 minimum), ou tokenisation.
L'exigence 3.5 interdit de stocker des numéros de compte complets dans les journaux applicatifs, les fichiers de log, les données de debug ou tout autre fichier susceptible d'être accessible en dehors du périmètre sécurisé. Cette exigence est fréquemment violée involontairement : des développeurs ajoutent des logs de débogage qui capturent les paramètres de requête, incluant par inadvertance des PAN.
PCI DSS v4.0 introduit également des exigences renforcées sur la gestion des clés cryptographiques (exigence 3.7) : les clés utilisées pour chiffrer les données de carte doivent être stockées dans des HSM ou des systèmes équivalents, avec des procédures formelles de génération, distribution, stockage, rotation et révocation des clés documentées et suivies.
Risques et conséquences d'une protection insuffisante
Une protection insuffisante des données de carte expose les entreprises à des conséquences financières et réputationnelles sévères. En cas de compromission, les réseaux de paiement (Visa, Mastercard) peuvent infliger des amendes allant de 5 000 à 100 000 euros par mois jusqu'à résolution du problème, plus des pénalités additionnelles basées sur le nombre de cartes compromises.
L'acquéreur peut également suspendre la capacité du marchand à accepter des paiements par carte — une sanction catastrophique pour tout commerce en ligne. Les coûts d'investigation forensique post-incident (obligatoires pour les marchands de niveau 1 et souvent exigés pour les autres niveaux) atteignent typiquement 50 000 à 200 000 euros. Sans compter les coûts de notification aux porteurs de carte (obligatoires dans l'UE sous le RGPD) et les éventuelles actions en justice.
Au-delà des sanctions financières, l'atteinte réputationnelle peut être durable. Des études montrent que 30 à 40 % des clients victimes d'une fuite de données abandonnent leur relation avec l'entreprise concernée. Pour les marchands en ligne, la perte de confiance des consommateurs est souvent la conséquence la plus coûteuse à long terme.
Intersections avec le RGPD : une double conformité
Les données de carte sont également des données personnelles au sens du RGPD. Un PAN associé à un titulaire de carte identifié constitue une donnée personnelle et bénéficie de toutes les protections du règlement européen. Les marchands doivent donc gérer simultanément les obligations PCI DSS (sécurité des données de paiement) et RGPD (protection des données personnelles).
Heureusement, les deux réglementations s'alignent sur les principes fondamentaux : minimisation des données (ne stocker que ce qui est nécessaire), protection par conception (security by design), et documentation des traitements. Une approche de conformité PCI DSS bien conçue contribue directement à la conformité RGPD pour les données de paiement.
Le droit à l'effacement RGPD (article 17) pose un défi spécifique pour les marchands qui stockent des PAN : comment garantir l'effacement complet et définitif de données chiffrées sur des systèmes distribués avec sauvegardes ? La tokenisation simplifie ce problème : supprimer le token dans votre base de données et demander la suppression du PAN dans le vault PCI Proxy EU suffit à satisfaire l'obligation d'effacement.
Comment la tokenisation élimine le problème à la racine
La tokenisation adopte une approche radicalement différente : plutôt que de sécuriser le stockage des PAN, elle élimine le besoin de stocker des PAN dans vos systèmes. Les données de carte ne transitent jamais par vos serveurs — elles vont directement du navigateur du client vers le vault sécurisé de PCI Proxy EU via une iFrame ou un SDK JavaScript isolé.
Vos systèmes ne reçoivent et ne stockent que des tokens — des chaînes de caractères sans valeur intrinsèque. Si votre base de données est compromise, l'attaquant ne récupère que des tokens inutilisables sans accès au vault PCI Proxy EU, lui-même protégé par une infrastructure de sécurité de niveau bancaire incluant des HSM, une surveillance 24/7, et des audits de sécurité réguliers.
Cette approche réduit également votre surface d'attaque globale : il n'y a pas de clés cryptographiques à gérer dans vos systèmes (risque principal dans les solutions de chiffrement), pas de procédures de rotation de clés à documenter, et pas de risque de fuite de clé compromettre rétrospectivement toutes les données chiffrées stockées. Le vault PCI Proxy EU assume l'entière responsabilité de la sécurité des PAN.
Bonnes pratiques de protection complémentaires
Même avec la tokenisation, certaines bonnes pratiques restent importantes pour la protection globale de vos paiements. Assurez-vous que vos pages de paiement utilisent exclusivement l'iFrame PCI Proxy EU pour la saisie des données de carte — aucun champ de formulaire natif HTML ne doit capturer des données de carte sur vos serveurs. Auditez régulièrement votre code JavaScript côté client pour détecter toute injection de scripts malveillants (skimming).
Mettez en place une politique de conservation des données claire : définissez combien de temps les tokens sont conservés dans vos systèmes et automatisez leur suppression lorsqu'ils ne sont plus nécessaires. Formez vos équipes de service client à ne jamais demander les données de carte complètes par email, chat ou téléphone sans passer par un système de tokenisation sécurisé.
Protégez vos données de carte à la source avec la tokenisation : découvrir PCI Proxy EU.