En bref : qu'est-ce que PCI DSS
- Douze exigences de sécurité du PCI Security Standards Council pour quiconque stocke, traite ou transmet des données de porteur de carte.
- La version actuelle est 4.0.1. Les exigences 6.4.3 (inventaire de scripts) et 11.6.1 (détection d'altération de page de paiement) appliquées depuis le 31 mars 2025.
- La non-conformité signifie amendes, perte possible d'acceptation des marques de cartes, et responsabilité totale pour les coûts de brèche.
Ce qu'est le PCI DSS et qui le gère
La norme est publiée par le PCI Security Standards Council, une entité fondée en 2006 par American Express, Discover, JCB, Mastercard et Visa pour uniformiser la sécurité des données de cartes dans l'ensemble de l'écosystème de paiement. Avant ce conseil, chaque réseau de cartes disposait de son propre programme de sécurité. Les regrouper au sein du PCI DSS a permis aux commerçants et aux prestataires de services de viser un seul cadre au lieu de cinq.
Le PCI DSS n'est pas une loi, mais il est contractuellement exigé par chaque réseau de cartes et chaque acquéreur qui vous permet d'accepter les cartes. Le non-respect peut entraîner des amendes, des taux de traitement plus élevés, des coûts d'enquête forensique après une violation, et la perte pure et simple de la capacité à traiter les paiements par carte.
Qui doit se conformer
Toute entreprise qui accepte, stocke, traite ou transmet des données de cartes de paiement. L'obligation s'applique à différents niveaux selon le volume de transactions :
| Niveau de commerçant | Volume de transactions | Validation |
|---|---|---|
| 1 | Plus de 6M/an (Visa/Mastercard) | RoC annuel signé par un QSA |
| 2 | 1M-6M/an | SAQ annuel (généralement SAQ D) + scans ASV |
| 3 | 20K-1M e-commerce/an | SAQ annuel + scans ASV |
| 4 | Moins de 20K e-commerce ou 1M au total | SAQ annuel, scans ASV si requis |
| Prestataire de services | Toute entité traitant des données de cartes pour autrui | RoC annuel signé par un QSA |
La variante précise de SAQ dépend de votre manière de traiter les données de cartes. Pour connaître les différences, consultez notre guide du SAQ D et notre guide du rapport de conformité PCI DSS.
Les 12 exigences
Le PCI DSS 4.0.1 organise ses contrôles autour de six objectifs englobant 12 exigences :
Objectif 1 : 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
- Exigence 2 : Appliquer des configurations sécurisées à tous les composants du système
Objectif 2 : Protéger les données de compte
- Exigence 3 : Protéger les données de compte stockées
- Exigence 4 : Protéger les données de titulaires de cartes par une cryptographie forte lors de leur transmission
Objectif 3 : Maintenir un programme de gestion des vulnérabilités
- Exigence 5 : Protéger tous les systèmes et réseaux contre les logiciels malveillants
- Exigence 6 : Développer et maintenir des systèmes et des logiciels sécurisés
Objectif 4 : Mettre en œuvre des mesures de contrôle d'accès strictes
- Exigence 7 : Restreindre l'accès selon le besoin d'en connaître
- Exigence 8 : Identifier les utilisateurs et authentifier les accès
- Exigence 9 : Restreindre l'accès physique aux données de titulaires de cartes
Objectif 5 : Surveiller et tester régulièrement les réseaux
- Exigence 10 : Journaliser et surveiller tous les accès
- Exigence 11 : Tester régulièrement la sécurité des systèmes et des réseaux
Objectif 6 : Maintenir une politique de sécurité de l'information
- Exigence 12 : Soutenir la sécurité de l'information par des politiques et des programmes organisationnels
Chaque exigence comporte plusieurs sous-exigences. La norme complète s'étend sur des centaines de pages.
Ce qui a changé dans le PCI DSS 4.0.1
La version 4.0.1 a remplacé le PCI DSS 3.2.1 comme norme obligatoire le 31 mars 2025. Les principaux ajouts par rapport à la 3.2.1 concernent la sécurité côté client :
- Exigence 6.4.3 : tenir un inventaire des scripts sur les pages de paiement, documenter la justification métier, vérifier l'intégrité, détecter les modifications non autorisées
- Exigence 11.6.1 : surveiller les en-têtes HTTP sur les pages de paiement, détecter les modifications non autorisées et déclencher des alertes
- Exigence 8.3.6 : renforcement de la complexité des mots de passe
- Exigence 8.4.2 : MFA obligatoire pour tout accès administratif hors console à l'environnement des données de titulaires de cartes
- Exigence 12.3.3 : inventaire des algorithmes de chiffrement et des protocoles cryptographiques
- Exigence 10.7.2/3 : journalisation et surveillance étendues
Les ajouts côté client sont les plus importants car ils comblent une lacune que les outils de sécurité traditionnels ne couvrent pas. Des attaques comme le skimming de scripts de type Magecart se déroulent entièrement dans le navigateur et, jusqu'à la 4.0.1, aucune exigence PCI DSS explicite n'imposait de les détecter.
Pour un cheminement plus détaillé, consultez notre guide complet du PCI DSS 4.0 et le résumé du webinaire de mise en œuvre de la 4.0.1.
Erreurs de conformité PCI DSS courantes
En accompagnant des commerçants lors de leur première évaluation 4.0.1, les mêmes lacunes reviennent sans cesse :
- Aucun inventaire des scripts sur les pages de paiement : exigé par la 6.4.3, absent de la plupart des environnements avant 2025
- Aucune surveillance des en-têtes HTTP : exigée par la 11.6.1
- Sous-estimer le périmètre : supposer que le SAQ A s'applique alors que le SAQ A-EP ou le SAQ D est en réalité requis
- Collecte manuelle des preuves : les QSA ont besoin de preuves continues, pas de captures d'écran prises pendant l'évaluation
- Contrôles compensatoires sans documentation formelle : les QSA n'acceptent pas de contrôles compensatoires non documentés
- Prendre les certifications d'un fournisseur pour votre propre conformité : le fait que votre processeur de paiement soit conforme PCI ne vous rend pas conforme PCI
Où cside intervient
Les exigences 6.4.3 et 11.6.1 sont les deux domaines les moins bien préparés dans la plupart des évaluations PCI DSS. cside produit un inventaire continu des scripts, une surveillance de l'intégrité, une surveillance des en-têtes HTTP et un historique des alertes de modification, c'est-à-dire exactement les preuves dont un QSA a besoin pour valider ces exigences.
Pour le guide de mise en œuvre pratique, consultez comment se conformer à la PCI 6.4.3 et le guide QSA pour la 6.4.3 et la 11.6.1.
Pour commencer
Si vous débutez avec le PCI DSS, la démarche ressemble à ceci :
- Déterminez votre niveau de commerçant et le SAQ (ou RoC) applicable
- Réalisez un schéma de périmètre couvrant chaque système qui stocke, traite ou transmet des données de cartes
- Effectuez une évaluation des écarts au regard des exigences applicables
- Corrigez les écarts en priorisant tout ce qui bloque le traitement des transactions
- Complétez le SAQ ou faites appel à un QSA pour le RoC
- Maintenez des preuves continues pour le cycle annuel suivant
La conformité est un programme continu, pas un projet ponctuel. Les commerçants qui la traitent comme un processus continu finissent par consacrer moins de temps et d'argent par cycle que ceux qui reconstituent leurs preuves chaque année.
