Une entreprise qui encaisse par carte manipule des données que les attaquants monétisent immédiatement. La norme PCI DSS, publiée par le PCI Security Standards Council, encadre cette manipulation depuis 2004. Sa version 4 a profondément changé la donne : elle introduit 64 exigences nouvelles, réécrit la logique de validation et déplace le curseur vers la sécurité côté client des pages de paiement. À jour au 13 août 2026, la seule version active de la norme est PCI DSS v4.0.1, et l’ensemble de ses exigences est pleinement opposable lors d’un audit.
Ce guide traite les questions qu’un RSSI, un DSI ou un responsable e-commerce doit trancher : qui est réellement concerné, comment définir la portée sans faire exploser le coût de l’audit, ce que les exigences différées ont changé depuis mars 2025, comment choisir entre approche définie et approche personnalisée, et comment articuler PCI DSS avec le RGPD et NIS2 sans payer deux fois le même contrôle.
Qu’est-ce que PCI DSS et qui doit s’y conformer ?
PCI DSS est un référentiel de sécurité applicable à toute entité qui stocke, traite ou transmet des données de compte de carte de paiement, ainsi qu’à toute entité dont les systèmes peuvent influer sur la sécurité de cet environnement. Il ne s’agit pas d’une loi mais d’une obligation contractuelle imposée par les réseaux de cartes et relayée par les banques acquéreuses.
Une norme contractuelle, pas une réglementation
La distinction est structurante pour la gouvernance interne. Aucun texte français ou européen n’impose PCI DSS. Le régulateur qui sanctionne n’est ni la CNIL ni l’ANSSI, mais la banque acquéreuse ou le prestataire de services de paiement, sur le fondement du contrat d’acceptation. Les leviers dont ils disposent sont concrets : pénalités mensuelles, reclassement dans un niveau de validation plus contraignant, prise en charge des frais d’investigation post-incident, et en dernier ressort résiliation du contrat.
La conséquence pratique est qu’un projet PCI DSS ne se pilote pas comme un projet de conformité réglementaire classique. L’interlocuteur de référence est l’acquéreur, et c’est lui qui valide en dernier ressort le niveau de validation applicable et le questionnaire retenu. Toute interprétation de portée doit être écrite et confirmée par lui.
Les données concernées
La norme distingue deux familles. Les données de titulaire de carte regroupent le numéro de compte primaire (PAN), le nom du porteur, la date d’expiration et le code de service. Les données d’authentification sensibles couvrent le contenu de la piste magnétique ou de la puce, le cryptogramme visuel (CVV2, CVC2, CID) et le code PIN ou son bloc chiffré.
La règle la plus simple de la norme est aussi la plus violée : les données d’authentification sensibles ne doivent jamais être conservées après autorisation, même chiffrées. Le PAN, lui, peut être stocké s’il est rendu illisible, par troncature, hachage avec sel, tokenisation ou chiffrement fort avec gestion de clés conforme. Les modalités de cette gestion de clés sont traitées dans notre guide dédié au chiffrement des données en entreprise.
Les entités concernées
Deux catégories coexistent. Les commerçants acceptent les cartes en paiement de biens ou de services. Les prestataires de services sont les entités qui traitent, stockent ou transmettent des données de compte pour le compte d’un tiers, ou qui fournissent un service pouvant affecter la sécurité de ces données : hébergeurs, éditeurs de solutions d’encaissement, centres de contact, intégrateurs, prestataires de sauvegarde. Cette seconde catégorie est régulièrement sous-estimée par des entreprises qui se croient hors périmètre alors qu’elles administrent des systèmes du périmètre de leurs clients.
PCI DSS v4.0.1 : où en est la norme en août 2026
PCI DSS v4.0.1 est la seule version active de la norme depuis le 1er janvier 2025, et l’intégralité de ses exigences, y compris celles publiées avec effet différé, est évaluée lors de tout audit conduit en 2026.
Le calendrier des versions
PCI DSS v4.0 a été publiée en mars 2022. La version v3.2.1 a été retirée le 31 mars 2024, ce qui a rendu v4.x incontournable. En juin 2024, le Council a publié PCI DSS v4.0.1, une révision limitée qui corrige des erreurs de rédaction et de mise en forme, clarifie certaines formulations et aligne le texte sur les FAQ publiées entre-temps. Aucune exigence n’a été ajoutée et aucune date d’application n’a bougé. La version v4.0 a été retirée le 31 décembre 2024.
Les exigences différées, obligatoires depuis mars 2025
C’est le point de bascule que beaucoup d’organisations ont sous-évalué. Selon le PCI Security Standards Council, sur les 64 exigences nouvelles introduites par PCI DSS v4.x, 51 étaient différées et sont devenues applicables le 31 mars 2025. Publiées dès 2022 avec le statut de bonne pratique, elles ont laissé trois ans de préparation. Depuis 2025, elles sont opposables sans transition.
Une organisation qui a validé sa conformité en 2024 sur la base d’un périmètre v4.0 sans ces exigences se retrouve donc mécaniquement en écart lors du cycle suivant, sans qu’aucune alerte formelle ne le lui signale. Le contrôle à faire est simple : reprendre le dernier rapport et vérifier le statut des exigences 6.4.2, 6.4.3, 8.4.2, 10.4.1.1, 11.6.1 et 12.3.1.
Ce qui se prépare pour la suite
Le Council a ouvert du 3 juin au 20 juillet 2026 une période de consultation publique sur v4.0.1, destinée à préparer l’itération suivante de la norme, avec une attention explicite portée aux évolutions technologiques et à l’intelligence artificielle. Aucune version successeur n’est publiée à ce jour. Les organisations qui construisent leur feuille de route 2027 ont donc intérêt à privilégier des contrôles structurels, indépendants du texte, plutôt que des réponses ponctuelles à une exigence donnée.
Les 12 exigences regroupées en 6 objectifs
PCI DSS s’organise en 12 exigences réparties dans 6 objectifs de contrôle, structure inchangée depuis les premières versions et conservée en v4.0.1. Le détail normatif est disponible dans la bibliothèque documentaire du PCI SSC.
Construire et maintenir un réseau et des systèmes sécurisés
- Installer et maintenir des contrôles de sécurité réseau. La version 4 abandonne le terme de pare-feu au profit de la notion plus large de contrôle de sécurité réseau (NSC), qui englobe pare-feu, groupes de sécurité cloud, routeurs filtrants et politiques de micro-segmentation.
- Appliquer des configurations sécurisées à tous les composants du système, ce qui interdit les comptes et paramètres par défaut des éditeurs.
Protéger les données de compte 3. Protéger les données de compte stockées, avec interdiction absolue de conserver les données d’authentification sensibles après autorisation. 4. Protéger les données de titulaire de carte lors de leur transmission sur des réseaux publics ouverts, par cryptographie forte. L’exigence 4.2.1.1 impose désormais un inventaire tenu à jour des certificats de confiance.
Maintenir un programme de gestion des vulnérabilités 5. Protéger tous les systèmes contre les logiciels malveillants, avec extension aux supports amovibles et ajout de mécanismes de détection et de protection contre l’hameçonnage. 6. Développer et maintenir des systèmes et des logiciels sécurisés. La sélection des vulnérabilités à corriger en priorité relève de la même logique que celle décrite dans notre article sur la gestion des vulnérabilités par CVE et CVSS.
Mettre en place des mesures de contrôle d’accès strictes 7. Restreindre l’accès aux composants du système et aux données de compte selon le besoin d’en connaître. 8. Identifier les utilisateurs et authentifier l’accès aux composants du système. 9. Restreindre l’accès physique aux données de titulaire de carte, y compris aux terminaux de point de vente, dont la protection contre l’altération matérielle est explicitement traitée.
Surveiller et tester régulièrement les réseaux 10. Journaliser et surveiller tous les accès aux composants du système et aux données de compte. 11. Tester régulièrement la sécurité des systèmes et des réseaux.
Maintenir une politique de sécurité de l’information 12. Soutenir la sécurité de l’information par des politiques et des programmes organisationnels, incluant la gestion des risques liés aux prestataires et la réponse à incident.
Définir la portée : le CDE et la segmentation réseau
La portée détermine à elle seule le coût, la durée et le risque d’un projet PCI DSS. L’environnement de données de carte (CDE) regroupe les composants qui stockent, traitent ou transmettent des données de compte, auxquels s’ajoutent tous les systèmes connectés à ce périmètre ou susceptibles d’en affecter la sécurité.
Les trois cercles à cartographier
Le premier cercle est le CDE au sens strict : serveurs applicatifs de paiement, bases de données, terminaux, passerelles. Le deuxième regroupe les systèmes connectés au CDE, qui peuvent communiquer avec lui : annuaire d’identité, serveurs de sauvegarde, outils de supervision, serveurs de rebond. Le troisième couvre les systèmes affectant la sécurité, qui n’accèdent pas aux données mais conditionnent les protections : serveurs d’autorité de certification, solutions de journalisation, consoles d’administration, serveurs de mise à jour.
Ce troisième cercle est celui que les organisations oublient le plus souvent. Un contrôleur de domaine qui authentifie les administrateurs du CDE est dans la portée, même s’il ne voit jamais un numéro de carte. Les principes de durcissement associés sont traités dans notre article sur la sécurité et le durcissement d’Active Directory.
La segmentation n’est pas obligatoire, elle est rentable
La norme ne rend pas la segmentation obligatoire. Un réseau plat peut être conforme, mais il est alors intégralement dans la portée : chaque poste de travail devient un composant à durcir, à journaliser, à scanner et à documenter. Le calcul est vite fait pour une entreprise de quelques centaines de postes.
Une segmentation efficace suppose de mettre en oeuvre des contrôles techniques qui empêchent réellement la communication entre le CDE et le reste du réseau, et pas seulement une séparation logique de confort. Le rattachement des équipements au bon segment relève des mécanismes décrits dans notre guide du contrôle d’accès réseau et de 802.1X, et la logique générale de réduction de la confiance implicite rejoint celle du Zero Trust, formalisée par le NIST dans la publication SP 800-207.
Tester la segmentation, pas seulement la déclarer
L’exigence 11.4.5 impose de tester la segmentation au moins tous les douze mois pour un commerçant, et l’exigence 11.4.6 tous les six mois pour un prestataire de services. Le test doit être conduit par une ressource qualifiée, interne ou externe, avec une indépendance organisationnelle vis-à-vis de l’équipe qui a mis en place les contrôles. Il consiste à vérifier depuis chaque segment hors portée que le CDE reste inaccessible, protocole par protocole. Un schéma d’architecture ne remplace pas ce test, et l’écart le plus fréquent relevé en audit est une règle de pare-feu temporaire jamais retirée.
Les nouveautés v4.x qui coûtent le plus cher
Quatre exigences différées concentrent l’essentiel de l’effort de mise en conformité observé depuis mars 2025, parce qu’elles touchent l’architecture plutôt que la documentation.
MFA généralisée sur tous les accès au CDE
L’exigence 8.4.2 impose l’authentification multifacteur pour tous les accès à l’environnement de données de carte, et non plus seulement pour les accès administratifs ou distants. L’exigence 8.5.1 précise les propriétés attendues du mécanisme : résistance au rejeu, impossibilité de contournement, indépendance des facteurs, application à tous les utilisateurs. Le sujet du choix des facteurs et de leur résistance à l’hameçonnage est développé dans notre article sur l’authentification forte en entreprise.
Le point dur pratique concerne les comptes de service et les comptes applicatifs, traités par les exigences 8.6.1 à 8.6.3 : rotation des mots de passe, interdiction d’usage interactif, contrôle documenté. Sur un système ancien, cela suppose souvent une refonte des mécanismes d’intégration.
Sécurité côté client des pages de paiement
Les exigences 6.4.3 et 11.6.1 répondent directement aux attaques par injection de scripts sur les pages de paiement, qui interceptent les saisies dans le navigateur de l’acheteur sans jamais toucher au serveur marchand. La première impose de gérer les scripts chargés dans la page de paiement : inventaire, justification, autorisation, vérification d’intégrité. La seconde impose un mécanisme de détection des modifications non autorisées des en-têtes HTTP et du contenu de la page, avec évaluation au moins tous les sept jours.
Ces deux exigences ont produit un effet de bord notable sur la validation des commerçants e-commerce. Le Council a retiré les exigences 6.4.3, 11.6.1 et 12.3.1 du questionnaire SAQ A tout en ajoutant un critère d’éligibilité : le commerçant doit confirmer que sa page n’est pas exposée aux attaques par scripts susceptibles d’affecter son système de commerce électronique. La contrainte technique n’a pas disparu, elle a changé de forme.
L’analyse de risque ciblée
L’exigence 12.3.1 impose une analyse de risque ciblée et documentée pour toute exigence dont la fréquence d’exécution est laissée à l’appréciation de l’entité. Chaque analyse doit identifier l’actif protégé, la menace, les facteurs contributifs, la fréquence retenue et sa justification, avec une révision au moins annuelle. Une organisation qui exploite largement cette souplesse peut se retrouver avec plusieurs dizaines d’analyses à produire et à maintenir, ce qui constitue une charge documentaire durable et non un chantier ponctuel.
Journalisation automatisée et détection
L’exigence 10.4.1.1 impose des mécanismes automatisés pour la revue des journaux, ce qui exclut de fait la revue manuelle sur une organisation de taille moyenne. Les exigences 10.7.2 et 10.7.3 imposent la détection, l’alerte et la réponse rapide en cas de défaillance d’un système critique de sécurité, y compris les contrôles de segmentation. Cette combinaison pousse mécaniquement vers une plateforme de collecte et de corrélation, dont les principes de dimensionnement sont détaillés dans notre article sur le SIEM et la journalisation.
Approche définie ou approche personnalisée
PCI DSS v4 offre deux voies de validation pour chaque exigence, et le choix engage durablement l’organisation.
L’approche définie est la voie classique : l’entité applique la procédure de test décrite dans la norme, et l’évaluateur vérifie sa mise en oeuvre. L’approche personnalisée permet d’atteindre l’objectif de sécurité de l’exigence par un contrôle différent, adapté au contexte technique. Elle suppose de documenter l’objectif visé, de décrire le contrôle retenu, de produire une analyse de risque ciblée et de définir les procédures de test que l’évaluateur devra suivre. Cette voie exige obligatoirement l’intervention d’un évaluateur qualifié (QSA) et n’est pas disponible dans les questionnaires d’auto-évaluation.
L’approche personnalisée est pertinente pour une organisation dont l’architecture s’écarte des hypothèses de la norme, par exemple un environnement conteneurisé éphémère où la notion de correctif appliqué à un système persistant n’a pas de sens. Elle est déconseillée à une organisation qui cherche simplement à éviter un contrôle jugé coûteux, car la charge de preuve est plus lourde que la mise en oeuvre du contrôle standard.
Se valider : SAQ, ROC et scans ASV
Le mode de validation dépend du niveau attribué par les réseaux de cartes, lui-même fonction du volume annuel de transactions et de l’historique d’incidents.
Niveaux et livrables
Les seuils sont fixés par chaque réseau et non par le PCI SSC. En pratique, un commerçant de niveau 1, généralement au-delà de six millions de transactions annuelles pour un réseau donné, doit produire un rapport de conformité (ROC) établi par un QSA ou un évaluateur interne certifié, accompagné d’une attestation de conformité. Les niveaux inférieurs peuvent recourir à un questionnaire d’auto-évaluation (SAQ). Un commerçant ayant subi une compromission avérée est fréquemment reclassé au niveau 1 par son acquéreur, indépendamment de son volume.
Choisir le bon questionnaire
Le SAQ A couvre les commerçants qui externalisent intégralement le traitement des données de carte, par redirection complète ou par iframe entièrement servi par le prestataire. Le SAQ A-EP s’applique aux commerçants qui conservent la maîtrise de la page de paiement tout en déléguant la saisie, situation courante avec des champs hébergés injectés par un script. Le SAQ D, le plus complet, s’applique aux commerçants qui stockent ou traitent eux-mêmes les données, et dans une version distincte à tous les prestataires de services éligibles à l’auto-évaluation. Les SAQ B, B-IP, C, C-VT et P2PE couvrent des configurations de point de vente physique.
Le sur-classement volontaire est une erreur fréquente : choisir un questionnaire plus lourd que nécessaire multiplie l’effort sans réduire le risque. Le sous-classement est plus grave encore, car il invalide l’attestation en cas d’incident. L’éligibilité doit être tranchée avec l’acquéreur avant le lancement du projet.
Scans externes et tests d’intrusion
L’exigence 11.3.2 impose des analyses de vulnérabilité externes au moins tous les trois mois, réalisées par un prestataire agréé par le PCI SSC (ASV) figurant sur la liste officielle des Approved Scanning Vendors, avec obligation de remédier puis de relancer le scan jusqu’à obtention d’un résultat conforme. L’exigence 11.3.1 impose des analyses internes trimestrielles. Les exigences 11.4.2 et 11.4.3 imposent des tests d’intrusion internes et externes au moins annuels, et après tout changement significatif d’infrastructure. Le cadrage de ces tests est traité dans notre guide du test d’intrusion en entreprise.
PCI DSS, RGPD et NIS2 : trois régimes distincts
Une attestation PCI DSS ne vaut ni conformité au RGPD ni conformité à NIS2. Les trois textes partagent une partie de leurs contrôles techniques mais poursuivent des finalités différentes et sont contrôlés par des autorités différentes.
PCI DSS protège les données de compte de carte, sous contrôle contractuel des réseaux et des acquéreurs. Le RGPD protège les personnes physiques et impose des obligations que PCI DSS ignore complètement. La CNIL rappelle dans sa doctrine sur le paiement en ligne que les données strictement nécessaires à une transaction ne doivent pas être conservées au-delà de celle-ci, et que la conservation du numéro de carte pour faciliter des achats ultérieurs suppose un consentement spécifique, matérialisé par une case à cocher non pré-cochée, l’acceptation des conditions générales étant insuffisante. Un environnement parfaitement conforme PCI DSS peut donc être en infraction au RGPD. Les obligations de notification associées sont détaillées dans notre article sur la notification de violation de données à la CNIL en 72 heures.
NIS2, de son côté, vise la résilience d’entités essentielles et importantes désignées par secteur, sans considération du moyen de paiement. Une enseigne de distribution peut relever simultanément de NIS2 pour sa gouvernance cyber et de PCI DSS pour son encaissement, avec deux interlocuteurs et deux calendriers distincts. Le périmètre exact est traité dans notre guide NIS2 pour les entreprises.
Le contexte de menace justifie de traiter ces régimes ensemble plutôt qu’en silos. L’ANSSI indique dans son Panorama de la cybermenace 2025 avoir traité 3 586 événements de sécurité en 2025, en baisse de 18 % sur un an, dont 2 209 signalements et 1 366 incidents, et souligne le recul relatif du rançongiciel au profit de l’exfiltration de données seule. Côté paiement, la Banque de France relève dans le rapport 2024 de l’Observatoire de la sécurité des moyens de paiement que le taux de fraude sur la carte s’est stabilisé à son plus bas niveau historique pour la troisième année consécutive, à 53 euros de fraude pour 100 000 euros de paiements, soit 0,053 %, le montant annuel de fraude sur l’ensemble des moyens de paiement restant juste sous le seuil de 1,2 milliard d’euros. La fraude à la carte est donc maîtrisée en France, ce qui déplace l’enjeu vers le vol de données en masse plutôt que vers la fraude transactionnelle unitaire.
Plan de mise en conformité en six chantiers
Pour une organisation qui aborde ou reprend le sujet en 2026, six chantiers structurent un plan réaliste sur douze mois.
Chantier 1, cartographier les flux. Identifier chaque point où une donnée de carte entre, transite, se pose ou sort, y compris les canaux non applicatifs : centre d’appels, enregistrements téléphoniques, courriels reçus, exports comptables, tickets de support, sauvegardes, environnements de test alimentés par des données de production.
Chantier 2, réduire la portée. Externaliser ou tokeniser ce qui peut l’être, puis segmenter ce qui reste. Chaque système sorti du périmètre est un système qu’il ne faudra ni durcir, ni journaliser, ni scanner, ni documenter pendant les années à venir.
Chantier 3, arbitrer le mode de validation. Déterminer le niveau applicable avec l’acquéreur, choisir le questionnaire ou engager un QSA, et trancher l’usage éventuel de l’approche personnalisée avant de démarrer les travaux techniques.
Chantier 4, traiter les exigences différées. Reprendre une à une les exigences applicables depuis mars 2025, en commençant par la MFA sur le CDE, la sécurité des scripts de page de paiement, la solution automatisée de protection des applications web exposées et la revue automatisée des journaux.
Chantier 5, industrialiser la preuve. PCI DSS se prouve par des artefacts datés et répétés : scans trimestriels, revues d’accès, analyses de risque ciblées, tests de segmentation, revues de portée. Automatiser leur production évite la course à la documentation dans les six semaines précédant l’audit.
Chantier 6, brancher la conformité sur la détection. Les exigences 10.7.2 et 10.7.3 imposent de détecter et de traiter rapidement la défaillance des contrôles critiques. C’est le point de jonction avec le dispositif de supervision décrit dans notre observatoire de la cybersécurité en entreprise.
Sources et références
[1] PCI Security Standards Council, bibliothèque documentaire PCI DSS, version v4.0.1. [2] PCI Security Standards Council, publication de PCI DSS v4.0.1, juin 2024. [3] PCI Security Standards Council, exigences différées de PCI DSS v4.x applicables au 31 mars 2025. [4] PCI Security Standards Council, mise à jour des critères d’éligibilité du questionnaire SAQ A. [5] PCI Security Standards Council, consultation publique sur PCI DSS v4.0.1, 3 juin au 20 juillet 2026. [6] ANSSI, Panorama de la cybermenace 2025, publié en mars 2026. [7] Banque de France, rapport 2024 de l’Observatoire de la sécurité des moyens de paiement, publié en septembre 2025. [8] CNIL, doctrine sur le paiement en ligne et recommandation relative aux données de carte de paiement. [9] NIST, Special Publication 800-207, Zero Trust Architecture.