PCI DSSLa norme de sécurité incontournable pour la protection des données de paiement
La norme de sécurité imposée par les réseaux de cartes à toute organisation qui accepte, traite, stocke ou transmet des données de cartes bancaires, en version 4.0.1 obligatoire depuis le 31 mars 2025.

Qu’est-ce que PCI DSS ?
Toute organisation qui accepte, traite, stocke ou transmet des données de cartes bancaires est soumise à la norme PCI DSS. Qu’il s’agisse d’un commerçant en ligne, d’un prestataire de services de paiement, d’un hébergeur ou d’un éditeur de logiciels intégrant des fonctionnalités de paiement, la conformité PCI DSS est une exigence contractuelle imposée par les réseaux de cartes (Visa, Mastercard, American Express, Discover) à l’ensemble de leur écosystème.
La version 4.0.1 du standard, pleinement obligatoire depuis le 31 mars 2025, représente la mise à jour la plus importante depuis plus de dix ans. Elle introduit une approche personnalisée permettant des contrôles alternatifs, renforce les exigences d’authentification multifacteurs et de chiffrement, et ajoute de nouvelles obligations sur la sécurité côté client, notamment la protection des pages de paiement contre les attaques de type Magecart. Avec 64 nouvelles exigences, dont les 51 à effet différé devenues obligatoires en mars 2025, la conformité PCI DSS v4 nécessite une démarche structurée et anticipée.
Cette page vous présente les 12 exigences clés du standard, les niveaux de conformité applicables, les sanctions encourues et les étapes concrètes pour engager votre mise en conformité.
Le Payment Card Industry Data Security Standard (PCI DSS) est la norme de sécurité publiée et maintenue par le PCI Security Standards Council (PCI SSC), fondé en 2006 par Visa, Mastercard, American Express, Discover et JCB. Son objectif est de protéger les données des titulaires de cartes bancaires tout au long de leur cycle de vie, de la collecte à la suppression.
Contrairement au RGPD ou à NIS 2, PCI DSS n’est pas une réglementation étatique : c’est une exigence contractuelle. Sa non-conformité n’expose pas à des sanctions prononcées par une autorité publique, mais à des pénalités imposées par les réseaux de cartes via les banques acquéreuses, qui peuvent aller jusqu’à l’exclusion du droit d’accepter des paiements par carte.
Qui est concerné par PCI DSS ?
La conformité PCI DSS s’applique à toute organisation qui stocke, traite ou transmet des données de titulaires de cartes ou des données d’authentification sensibles. Cela inclut :
- Les commerçants qui acceptent des paiements par carte, en ligne ou en point de vente
- Les prestataires de services qui traitent, stockent ou transmettent des données de cartes pour le compte de commerçants
- Les éditeurs de logiciels dont les applications intègrent des fonctionnalités de paiement
- Les hébergeurs d’environnements traitant des données de cartes
Les quatre niveaux de conformité
Les commerçants sont classés en quatre niveaux selon leur volume annuel de transactions, chaque niveau imposant des exigences de validation différentes. Les prestataires de services sont classés en deux niveaux, avec des exigences de validation plus strictes pour les prestataires de niveau 1 (plus de 300 000 transactions par an).
-
Niveau 1
Plus de 6 millions de transactions par an. Audit annuel obligatoire par un Qualified Security Assessor (QSA) et scans trimestriels par un Approved Scanning Vendor (ASV).
-
Niveau 2
Entre 1 et 6 millions de transactions. Questionnaire d’auto-évaluation (SAQ) annuel et scans ASV trimestriels.
-
Niveau 3
Entre 20 000 et 1 million de transactions e-commerce. SAQ annuel et scans ASV trimestriels.
-
Niveau 4
Moins de 20 000 transactions e-commerce ou jusqu’à 1 million de transactions au total. SAQ annuel recommandé.
L’environnement des données de cartes (CDE)
L’environnement des données de cartes (Cardholder Data Environment, CDE) est le périmètre central de la conformité PCI DSS. Il comprend tous les systèmes qui stockent, traitent ou transmettent des données de titulaires de cartes ou des données d’authentification sensibles, ainsi que tout système pouvant affecter la sécurité de ces systèmes. La définition précise du CDE est la première étape de toute démarche de conformité PCI DSS.
Les 12 exigences de PCI DSS v4
Les 12 exigences de PCI DSS v4 sont organisées en six objectifs de contrôle, couvrant l’ensemble des dimensions de la sécurité des données de paiement.
-
Construire et maintenir un réseau et des systèmes sécurisés
Exigence 1 : Installer et maintenir des contrôles de sécurité réseau
Les organisations doivent mettre en place des pare-feux et des mécanismes de segmentation réseau pour protéger le CDE des réseaux non fiables. La segmentation réseau n’est pas obligatoire au sens strict, mais elle est fortement recommandée car elle réduit significativement le périmètre du CDE et donc l’effort de conformité. Elle doit être validée par des tests de pénétration au moins une fois par an.
Exigence 2 : Appliquer des configurations sécurisées à tous les composants système
Tous les composants système du CDE doivent être configurés de façon sécurisée : suppression des comptes et mots de passe par défaut, désactivation des services non nécessaires, application des principes de configuration minimale. PCI DSS v4 impose des mots de passe d’au moins 12 caractères pour les comptes utilisateurs et 15 caractères pour les comptes de service.
-
Protéger les données des titulaires de cartes
Exigence 3 : Protéger les données stockées des titulaires de cartes
Les données de titulaires de cartes ne doivent être stockées que si cela est strictement nécessaire. Les données d’authentification sensibles (CVV2, PIN…) ne doivent jamais être stockées après autorisation. Les données stockées doivent être protégées par chiffrement (AES-256 recommandé), troncature ou tokenisation.
Exigence 4 : Protéger les données en transit par chiffrement
Toutes les transmissions de données de titulaires de cartes sur des réseaux ouverts et publics doivent être chiffrées avec TLS 1.2 minimum, TLS 1.3 recommandé. Les protocoles obsolètes (SSL, TLS 1.0, TLS 1.1) sont interdits.
-
Maintenir un programme de gestion des vulnérabilités
Exigence 5 : Protéger tous les systèmes contre les logiciels malveillants
Une solution anti-malware doit être déployée sur tous les composants système exposés aux malwares. Les définitions doivent être maintenues à jour et les analyses périodiques documentées.
Exigence 6 : Développer et maintenir des systèmes et applications sécurisés
Les applications traitant des données de cartes doivent être développées selon des pratiques de développement sécurisé conformes aux standards reconnus (OWASP). PCI DSS v4 introduit deux nouvelles exigences critiques devenues obligatoires en mars 2025 : l’exigence 6.4.3 impose un inventaire et un contrôle de tous les scripts JavaScript chargés sur les pages de paiement, et l’exigence 11.6.1 impose des mécanismes de détection des modifications non autorisées de ces scripts, pour prévenir les attaques de type Magecart.
-
Mettre en œuvre des mesures de contrôle d’accès strictes
Exigence 7 : Restreindre l’accès aux données par besoin d’en connaître
L’accès aux données de titulaires de cartes doit être limité aux seules personnes dont les fonctions l’exigent. Les droits d’accès doivent être documentés et revus régulièrement.
Exigence 8 : Identifier les utilisateurs et authentifier l’accès
Chaque utilisateur doit disposer d’un identifiant unique. L’authentification multifacteurs (MFA) est désormais obligatoire pour tous les accès au CDE, pas uniquement pour les accès administratifs. Les comptes doivent être verrouillés après 10 tentatives de connexion échouées.
Exigence 9 : Restreindre l’accès physique aux données
L’accès physique aux équipements et aux supports contenant des données de cartes doit être contrôlé et journalisé. Les terminaux de paiement doivent faire l’objet d’inspections régulières pour détecter toute tentative de manipulation.
-
Surveiller et tester régulièrement les réseaux
Exigence 10 : Journaliser tous les accès aux ressources réseau et données cartes
Tous les accès aux composants du CDE et aux données de titulaires de cartes doivent être journalisés. Les journaux doivent être conservés pendant au moins 12 mois, avec les trois derniers mois immédiatement disponibles.
Exigence 11 : Tester régulièrement la sécurité
Les organisations doivent réaliser des scans de vulnérabilités trimestriels par un ASV approuvé, et des tests d’intrusion annuels par un prestataire qualifié, couvrant à la fois le périmètre externe et interne du CDE. Les tests de segmentation réseau doivent être réalisés au moins une fois par an pour la plupart des organisations, et tous les six mois pour les prestataires de services.
-
Maintenir une politique de sécurité de l’information
Exigence 12 : Maintenir une politique de sécurité de l’information
Une politique de sécurité de l’information documentée, couvrant l’ensemble du personnel, doit être maintenue et révisée annuellement. Elle doit inclure un programme de sensibilisation à la sécurité, une gestion des risques formalisée, et un plan de réponse aux incidents.
L’approche personnalisée : la nouveauté structurante de PCI DSS v4
PCI DSS v4 introduit une approche personnalisée (Customized Approach) qui permet aux organisations de concevoir leurs propres contrôles de sécurité pour atteindre les objectifs de la norme, à condition de démontrer que ces contrôles offrent un niveau de sécurité équivalent aux contrôles prescrits. Cette approche nécessite obligatoirement la validation d’un QSA.
Cette flexibilité est particulièrement utile pour les organisations disposant d’architectures innovantes ou de contrôles de sécurité avancés qui ne correspondent pas exactement aux contrôles définis par le standard.
PCI DSS face aux exigences transverses
Correspondance avec les 12 exigences communes aux référentiels cyber : chaque carte renvoie au comparatif détaillé de l’exigence.
9 obligations explicites et 3 exigences partielles sur les 12 familles d’exigences communes.
-
Organisationnel
Gouvernance & Politique SSI
Politique de sécurité documentée, approuvée par la direction, rôles et responsabilités définis. Pilier de toute démarche de conformité. Comparer avec les autres référentiels -
Organisationnel
Gestion des incidents
Processus complet de détection, classification, réponse et notification des incidents. Délais réglementaires à respecter. Comparer avec les autres référentiels -
Technologique
Contrôle d’accès & Authentification
Gestion des identités, droits d'accès, authentification forte. Mesure fondamentale contre les intrusions. Comparer avec les autres référentiels -
Technologique
Cryptographie & Protection des données
Protection cryptographique des données sensibles au repos et en transit. Gestion des clés cryptographiques. Comparer avec les autres référentiels -
Organisationnel
Sécurité de la chaîne d’approvisionnement
Évaluation, contractualisation et suivi de la sécurité des prestataires et sous-traitants. Exigence renforcée de NIS 2 et DORA. Comparer avec les autres référentiels -
Technologique
Gestion des vulnérabilités
Identification, évaluation et correction des vulnérabilités. Patch management, scans réguliers, processus de divulgation coordonnée. Comparer avec les autres référentiels -
Humain
Sensibilisation & Formation
Formation et sensibilisation des collaborateurs à la cybersécurité. Programme continu adapté aux profils. Culture cyber mesurée. Comparer avec les autres référentiels -
Physique
Sécurité physique
Protection physique des locaux hébergeant les SI et les données. Contrôle d'accès physique, surveillance, sécurisation des équipements. Comparer avec les autres référentiels -
Technologique
Journalisation & Détection
Collecte, centralisation et analyse des journaux d'événements. Capacité de détection des incidents et activités malveillantes. Comparer avec les autres référentiels -
Organisationnel
Analyse & Gestion des risques
Analyse formelle des risques cyber, identification des actifs, évaluation des menaces et vulnérabilités, plan de traitement. Comparer avec les autres référentiels -
Organisationnel
Continuité & Reprise d’activité
Plans de continuité et de reprise d'activité, stratégie de sauvegardes, tests réguliers. Défense essentielle contre les ransomwares. Comparer avec les autres référentiels -
Organisationnel
Privé : Protection des données personnelles
Respect des droits des personnes, minimisation, finalités, bases légales. Obligations spécifiques au RGPD et textes sectoriels. Comparer avec les autres référentiels
Calendrier d’application de PCI DSS v4
-
Passé
Publication de PCI DSS v4.0
Le PCI Security Standards Council publie la version 4.0 du standard, représentant la mise à jour la plus importante depuis plus de dix ans.
-
Passé
PCI DSS v3.2.1 caduque
La version 3.2.1 devient caduque le 31 mars 2024. PCI DSS v4.0 devient la seule version valide pour les évaluations de conformité.
-
Passé
Publication de PCI DSS v4.0.1
Le PCI SSC publie la version 4.0.1, une mise à jour de clarification qui corrige des ambiguïtés de la version 4.0 sans introduire de nouvelles exigences substantielles.
-
Passé
Toutes les exigences v4.0.1 obligatoires
Les 51 exigences à effet différé de PCI DSS v4.0.1 deviennent obligatoires le 31 mars 2025, incluant notamment les exigences 6.4.3 et 11.6.1 sur la sécurité des scripts de pages de paiement, et les nouvelles exigences de MFA et de gestion des mots de passe.
Sanctions et risques en cas de non-conformité
Amendes mensuelles des réseaux de paiement
La non-conformité PCI DSS expose à des amendes mensuelles imposées par les réseaux de paiement via les banques acquéreuses, pouvant aller de 5 000 à 100 000 euros par mois selon le niveau du commerçant et la durée de la non-conformité. Les commerçants de niveau 1 s’exposent aux amendes les plus élevées.
En cas de violation de données
Une violation de données de cartes déclenche automatiquement le passage au niveau de conformité 1, nécessitant une évaluation complète par un QSA. Les coûts associés incluent les frais d’investigation forensique (200 à 500 euros par enregistrement compromis), les frais de remplacement de cartes (3 à 5 euros par carte), les amendes majorées des réseaux de paiement, et les frais juridiques.
Exclusion des réseaux de paiement
La sanction ultime est la résiliation du compte commerçant par la banque acquéreuse, entraînant l’impossibilité d’accepter des paiements par carte. Cette sanction, combinée à l’augmentation des frais de transaction et à la responsabilité financière pour les fraudes, peut avoir des conséquences commerciales dévastatrices.
Les étapes de mise en conformité PCI DSS v4
-
Définir l’environnement CDE
La première action consiste à cartographier précisément l’environnement des données de cartes : identifier tous les systèmes qui stockent, traitent ou transmettent des données de titulaires de cartes, documenter les flux de données de bout en bout, et définir les limites du CDE. Les erreurs de périmètre sont la défaillance la plus courante lors des évaluations PCI.
-
Réduire la portée
Minimiser le périmètre CDE est la stratégie la plus efficace pour réduire l’effort de conformité. Les deux techniques principales sont la tokenisation, qui remplace les données de carte par des tokens sans valeur pour les attaquants, et la segmentation réseau, qui isole le CDE du reste de l’infrastructure. Ces deux techniques combinées peuvent réduire le périmètre de conformité de 80 à 90 %.
-
Évaluation des écarts
Une analyse d’écart (GAP analysis) permet d’identifier les non-conformités par rapport aux 12 exigences PCI DSS v4.0.1 sur le périmètre CDE défini. Cette évaluation doit couvrir l’ensemble des 300+ exigences du standard et prioriser les écarts selon leur criticité.
-
Remédiation
Les écarts identifiés doivent être traités par ordre de priorité, en commençant par les exigences les plus critiques : MFA, chiffrement TLS, gestion des vulnérabilités, et sécurité des scripts de pages de paiement. Un plan de remédiation documenté, avec des responsables et des échéances, est indispensable.
-
Tests de pénétration
Un test d’intrusion annuel doit être réalisé par un prestataire qualifié, couvrant le périmètre externe et interne du CDE. Les tests de segmentation réseau doivent également être réalisés pour valider l’isolation du CDE. Le coût d’un test d’intrusion PCI DSS varie généralement entre 2 000 et 15 000 euros selon le périmètre.
-
Rapport de conformité
Selon le niveau de conformité applicable, la validation prend la forme d’un questionnaire d’auto-évaluation (SAQ) pour les niveaux 2 à 4, ou d’un Report on Compliance (ROC) établi par un QSA certifié pour les commerçants de niveau 1 et les prestataires de services de niveau 1. Le modèle de ROC de PCI DSS v4 a été élargi de 192 à 354 pages pour refléter la complexité accrue des exigences.
PCI DSS en 4 questions
Mon site e-commerce est-il concerné par PCI DSS si j’utilise un prestataire de paiement ?
Cela dépend de la façon dont le paiement est intégré. Si vous utilisez une page de paiement hébergée par votre prestataire (redirect ou iframe), votre périmètre CDE est très réduit et un SAQ A suffit généralement. Si vous collectez les données de carte directement sur votre site, votre périmètre est plus large et les exigences plus nombreuses. Depuis mars 2025, même les intégrations en redirect sont soumises aux nouvelles exigences sur les scripts JavaScript (6.4.3 et 11.6.1).
Qu’est-ce qu’un QSA et quand est-il obligatoire ?
Un Qualified Security Assessor (QSA) est un auditeur certifié par le PCI SSC pour réaliser des évaluations PCI DSS. Il est obligatoire pour les commerçants de niveau 1 et les prestataires de services de niveau 1, qui doivent faire établir un Report on Compliance (ROC) annuel. Pour les autres niveaux, le QSA peut valider l’approche personnalisée ou être sollicité de façon optionnelle pour accompagner la démarche.
Quelle est la différence entre tokenisation et chiffrement dans le contexte PCI DSS ?
Le chiffrement transforme les données de carte en données illisibles, mais les données originales restent présentes et peuvent être déchiffrées avec la clé. La tokenisation remplace les données de carte par un token sans relation cryptographique avec les données originales : les systèmes qui ne voient que le token sont hors périmètre PCI DSS, à condition qu’ils n’aient pas accès au coffre de tokenisation. La tokenisation est donc la technique la plus efficace pour réduire le périmètre CDE.
Qu’est-ce que l’approche personnalisée introduite par PCI DSS v4 ?
L’approche personnalisée permet aux organisations de concevoir leurs propres contrôles de sécurité pour atteindre les objectifs de la norme, plutôt que d’appliquer les contrôles prescrits. Elle offre de la flexibilité pour les organisations disposant d’architectures innovantes, mais nécessite obligatoirement la validation d’un QSA et une documentation rigoureuse démontrant que les contrôles alternatifs atteignent le même niveau de sécurité.
Votre conformité PCI DSS avec Fidens
Définition du périmètre CDE, analyse d’écarts, tests d’intrusion, préparation du SAQ ou du ROC : nos consultants vous accompagnent vers la conformité PCI DSS v4 et vous aident à mutualiser vos efforts avec ISO 27001.

