Les données de carte sont une responsabilité connue des entreprises. Le coût moyen mondial d'une violation de données s'élevait à 4,44 millions de dollars en 2025. Chaque serveur, fichier de logs et sauvegarde dans lequel est sauvegardé un numéro de compte principal (PAN) fait partie de ce que la norme Payment Card Industry Data Security Standard (PCI DSS) appelle l'environnement des données des titulaires de cartes (CDE), et chaque aspect de cet environnement est soumis aux exigences de conformité.

La tokenisation modifie ce qui se trouve réellement dans cet environnement en remplaçant le PAN par une valeur de substitution qui n'a aucune valeur exploitable en soi. Si vous mettez en œuvre la tokenisation correctement, vous pouvez réduire vos obligations de conformité à une fraction de ce qu'elles seraient autrement. Ci-dessous, nous expliquons comment fonctionne la tokenisation pour la conformité PCI, les limites de ses protections, les endroits où d'autres contrôles de sécurité doivent être mis en œuvre, et ce que le PCI Security Standards Council exige d'un système de tokenisation conforme.

Points clés

• La tokenisation peut soustraire des systèmes entiers du champ d'application de la conformité de la norme Payment Card Industry Data Security Standard (PCI DSS), mais uniquement lorsque les contrôles de génération de tokens, de sécurité des coffres-forts et de détokenisation répondent à des normes techniques spécifiques.

• Le chiffrement et la tokenisation protègent les données de carte différemment dans le cadre de la norme PCI DSS, et de nombreuses architectures conformes s'appuient sur les deux plutôt que de choisir l'un par rapport à l'autre.

• L'admissibilité au questionnaire d'auto-évaluation de conformité PCI le plus simple dépend de la façon dont les données de carte circulent dans une intégration plutôt que simplement de la présence ou non de la tokenisation quelque part dans le système.

Qu'est-ce que la conformité à la norme PCI DSS ?

La conformité PCI DSS signifie répondre aux exigences de sécurité établies par le PCI Security Standards Council pour toute entreprise qui sauvegarde, traite ou transmet des données de titulaires de cartes. La norme couvre 12 exigences fondamentales concernant la sécurité du réseau, le contrôle d'accès, le chiffrement et la surveillance. Elle s'applique que vous exploitiez un seul terminal de paiement ou traitiez des millions de transactions par an.

Ce que dit la norme PCI DSS sur la tokenisation

Les lignes directrices de la norme PCI DSS pour la tokenisation conseillent que si un token n'a aucune valeur en dehors du système qui l'a créé, et si ce système est correctement isolé et sécurisé, les environnements où le token réside n'ont pas besoin d'être évalués comme s'ils contenaient de vraies données de carte. Chaque PAN existe toujours quelque part, généralement à l'intérieur d'un coffre-fort chiffré, mais la tokenisation signifie qu'il n'existe qu'à cet endroit unique, et non réparti sur plusieurs systèmes.

Comment la tokenisation réduit le champ d'application de la conformité PCI

La tokenisation réduit le champ d'application de la conformité PCI en limitant le nombre d'endroits où les données de carte lisibles sont sauvegardées ou transmises. Cela est vrai tant que les tokens ne peuvent pas être reconvertis en numéro de compte principal (PAN) d'origine par quiconque en dehors du système de tokenisation. Si quelqu'un peut calculer le PAN à partir du token en utilisant une logique connue, le token ne réduit pas le champ d'application.

Lignes directrices sur la tokenisation de la norme PCI DSS et exigences pour la réduction du champ d'application

Les lignes directrices du PCI Security Standards Council comprennent des attentes techniques spécifiques pour tout système revendiquant une réduction du champ d'application. Celles-ci se répartissent en deux catégories principales : la génération de tokens et les coffres-forts de tokens.

Génération de tokens

La génération de tokens doit résister à l'ingénierie inverse. Les tokens préservant le format qui imitent la longueur et la structure d'un numéro de carte donné sont sûrs tant que la substitution elle-même est imprévisible plutôt que dérivée d'une formule réversible.

Les tokens créés par un processus unidirectionnel, de sorte qu'il n'y a pas de fonction inverse mathématique, sont plus admissibles à la réduction du champ d'application que les tokens générés par chiffrement avec une clé récupérable. Les valeurs chiffrées sont toujours considérées comme des données de titulaires de cartes selon les définitions de la norme PCI DSS, même lorsqu'elles sont formatées pour ressembler à des tokens. La façon dont les tokens sont générés détermine la façon dont un évaluateur classe votre système. Les lignes directrices de la norme PCI DSS abordent également la résistance aux attaques par force brute. Si l'algorithme de tokenisation peut être deviné ou inversé par des tentatives répétées, le token n'est pas admissible à la réduction du champ d'application, quelle que soit la façon dont il est généré.

Coffres-forts de tokens

Le système de stockage des tokens est appelé un coffre-fort. Le coffre-fort de tokens doit se situer dans une zone réseau segmentée, appliquer un contrôle d'accès strict basé sur les rôles aux données qui mappent les tokens avec le PAN d'origine, et consigner chaque événement de détokenisation de manière suffisamment détaillée pour permettre un examen médico-légal. Les évaluateurs de la norme PCI DSS s'en tiennent généralement à la norme selon laquelle la détokenisation doit être rare, délibérée et auditable. Les lignes directrices exigent également que le fournisseur de tokenisation, qu'il s'agisse d'une équipe interne ou d'un tiers, se soumette à sa propre évaluation PCI DSS. Un coffre-fort compromis annule l'objectif de la tokenisation.

La documentation doit prouver la revendication de réduction du champ d'application aux évaluateurs et doit inclure un diagramme de flux de données qui montre exactement où les PAN existent en texte clair (c'est-à-dire des données lisibles qui ne sont pas chiffrées), où la tokenisation a lieu et où les tokens prennent le relais dans vos systèmes. Le diagramme doit être mis à jour chaque fois qu'un nouveau système entre dans le parcours de paiement ; sinon, la revendication de réduction du champ d'application cesse de correspondre à la réalité même si rien d'autre n'a changé.

Comparaison de la tokenisation avec le chiffrement dans le cadre de la norme PCI DSS

La tokenisation et le chiffrement protègent tous deux les mêmes données sous-jacentes, mais la norme PCI DSS les traite très différemment en matière de champ d'application. Un PAN chiffré reste généralement dans le champ d'application, à moins que le système de stockage n'ait pas accès aux clés de déchiffrement nécessaires pour lire le texte chiffré (le format chiffré). Le système contenant le texte chiffré doit répondre aux mêmes exigences en matière de contrôle d'accès, de consignation des activités et de gestion des vulnérabilités qu'un système dans lequel est sauvegardé le PAN en texte clair, même si le risque pratique est plus faible.

Avec la tokenisation, il n'y a pas de clé à protéger. Lorsqu'un token est généré par un processus unidirectionnel correctement mis en œuvre, il ne peut pas être inversé mathématiquement, ce qui signifie que les systèmes qui le contiennent existent en dehors du CDE.

En pratique, de nombreuses architectures conformes à la norme PCI utilisent à la fois le chiffrement et la tokenisation, car chacun ajoute des protections différentes. Le chiffrement protège le PAN à l'intérieur du coffre-fort pour l'autorisation et le règlement, tandis que la tokenisation protège le PAN partout ailleurs, comme dans les systèmes qui ont besoin de référencer une transaction, d'émettre un remboursement ou de montrer à un client les quatre derniers chiffres, sans jamais avoir besoin du numéro réel. En fin de compte, le chiffrement protège les données utilisables, et la tokenisation les supprime entièrement d'un système.

Qui est responsable du maintien de la conformité de la tokenisation après sa mise en œuvre ?

La conformité PCI DSS nécessite une validation continue, et la tokenisation ajoute sa propre maintenance en plus du cycle habituel d'application de correctifs (c'est-à-dire l'application de mises à jour de sécurité) et de surveillance de la norme. Si vous utilisez un fournisseur de tokenisation tiers, vous êtes toujours responsable de vérifier que le fournisseur maintient sa propre validation PCI DSS et d'examiner son Attestation de conformité chaque année. Une certification expirée du côté du fournisseur met en péril votre propre revendication de réduction du champ d'application, même si rien n'a changé de votre côté.

En interne, quelqu'un doit s'occuper du diagramme de flux de données et le mettre à jour chaque fois qu'un nouveau système entre dans le parcours de paiement. La réduction du champ d'application peut s'éroder silencieusement lorsque, par exemple, un nouvel outil d'analyse est connecté, ou qu'une équipe de service de support exporte des données de transaction dans une feuille de calcul pour un dépannage et trouve un PAN en texte clair dont personne n'avait tenu compte lors de la dernière évaluation. Les logs d'accès au coffre-fort doivent également faire l'objet d'un examen périodique pour détecter les demandes de détokenisation qui ne correspondent pas aux processus commerciaux prévus.

Dans de nombreuses entreprises de taille moyenne, c'est la responsabilité de la personne qui gère l'infrastructure de paiement (souvent quelqu'un de la finance ou de l'ingénierie), qui travaille avec un évaluateur de sécurité qualifié (QSA) au cours du cycle d'évaluation annuel. Les petites entreprises utilisant un fournisseur de paiement qui gère la tokenisation de bout en bout ont moins de travail, mais elles doivent tout de même vérifier qu'elles n'ont pas réintroduit de PAN dans leurs propres systèmes via des exportations, des captures d'écran ou des flux de travail de service client qui ne relevaient pas de la réduction de la portée initiale.

La tokenisation suffit-elle à garantir la conformité PCI DSS à elle seule ?

La tokenisation réduit le champ d'application, mais elle n'élimine pas les obligations de conformité pour les systèmes qui restent dans le champ d'application. Le coffre-fort doit toujours être entièrement conforme : la logique de génération, les données de mappage des tokens aux PAN et les contrôles de détokenisation doivent tous répondre aux normes PCI DSS complètes.

Les points de contact préalables à la tokenisation doivent également rester dans le champ d'application. Tout système qui gère un PAN avant qu'il ne soit tokenisé, comme une page de paiement ou un terminal POS, nécessite un chiffrement en transit, une segmentation du réseau et une analyse des vulnérabilités.

L'écart d'admissibilité au questionnaire d'auto-évaluation (SAQ)

De nombreuses entreprises supposent que toute solution de tokenisation les qualifie pour utiliser le Questionnaire d'auto-évaluation A (SAQ A), le questionnaire d'auto-évaluation le plus simple. Mais cela n'est vrai que si le système de tokenisation empêche l'entreprise de manipuler, de transmettre ou de sauvegarder des PAN, généralement via une page de paiement hébergée ou un composant intégré où les données de carte vont directement du navigateur du client au fournisseur de paiement. Une approche de tokenisation où les données brutes de carte passent toujours par le propre serveur de l'entreprise, même brièvement, avant d'être tokenisées, maintient ce serveur dans un champ d'application plus large, quelle que soit la force de la tokenisation à partir de ce moment.

Comment Stripe Payments peut vous aider

Stripe Payments propose une solution de paiement unifiée à l’échelle internationale. Elle permet à toutes les entreprises (des startups aux entreprises internationales) d’accepter des paiements en ligne, en personne et dans le monde entier.

Stripe Payments peut vous aider à :

• Optimiser votre expérience de paiement : créez une expérience client fluide et économisez des milliers d’heures d’ingénierie grâce à des interfaces de paiement préconfigurées, à l’accès à plus de 125 moyens de paiement et à Link, un wallet conçu par Stripe.

• Accéder plus rapidement à de nouveaux marchés : atteignez des clients dans le monde entier et réduisez la complexité et le coût de la gestion multidevise grâce aux options de paiement transfrontalier, disponibles dans 195 pays et plus de 135 devises.

• Unifier les paiements en ligne et en personne : créez une expérience commerciale unifiée, en ligne et en personne, pour personnaliser les interactions, récompenser la fidélité client et booster vos revenus.

• Améliorer vos performances en matière de paiement : augmentez vos revenus grâce à une gamme d’outils de paiement personnalisables et faciles à configurer, y compris une protection contre la fraude no-code et des fonctionnalités avancées pour améliorer les taux d’autorisation.

• Gagner en efficacité grâce à une plateforme de croissance flexible et fiable : développez-vous sur une plateforme conçue pour évoluer avec vous, avec un temps de disponibilité de 99,999 % et une fiabilité inégalée dans le secteur.

Découvrez comment Stripe Payments peut vous aider à optimiser vos paiements en ligne et en personne, ou démarrez dès aujourd’hui.