Conformité PCI DSS pour le commerce électronique : Guide de sécurité des paiements

Chaque transaction de commerce électronique impliquant une carte de paiement crée une obligation de conformité selon la norme PCI DSS – la norme de sécurité des données de l'industrie des cartes de paiement. La non-conformité ne constitue pas un risque théorique : les marques de cartes (Visa, Mastercard, Amex) peuvent imposer des amendes de 5 000 à 100 000 dollars par mois aux banques acquéreuses, qui répercutent la responsabilité directement sur les commerçants via leurs accords de traitement des paiements. À la suite d'une violation, les commerçants non conformes s'exposent à des amendes allant de 50 à 90 dollars par carte compromise, à des frais d'enquête médico-légale sur la marque de la carte et, dans les cas les plus graves, à la résiliation de leur compte marchand.

La norme PCI DSS v4.0, publiée en mars 2022 et devenue obligatoire à partir de mars 2025, a introduit des changements importants dans les exigences cryptographiques, les normes d'authentification et la gestion des scripts sur les pages de paiement. Ce guide donne aux équipes de commerce électronique une feuille de route complète de mise en œuvre.

Points clés à retenir

• PCI DSS v4.0 est obligatoire à compter du 31 mars 2025 — tous les commerçants en ligne doivent être conformes à la nouvelle version
• Le cadrage est la première étape la plus critique : réduisez autant que possible votre environnement de données de titulaire de carte (CDE)
• L'utilisation de la page de paiement hébergée par un processeur de paiement (Stripe, Braintree, Adyen) réduit considérablement la portée
• SAQ A s'applique à la plupart des commerçants proposant des pages de paiement hébergées, mais uniquement si aucune donnée de titulaire de carte ne touche vos serveurs.
• Les nouvelles exigences v4.0 incluent MFA pour tous les accès CDE, des contrôles d'intégrité des scripts sur les pages de paiement et une analyse des risques ciblée.
• L'écrémage Web (attaques Magecart) est abordé par la nouvelle exigence 6.4.3 sur l'inventaire des scripts de page de paiement
• Les tests d'intrusion annuels et les scans de vulnérabilités trimestriels restent obligatoires
• Des pénalités de non-conformité sont imposées par les marques de cartes → banques acquéreuses → commerçants

---

Fondamentaux du cadre PCI DSS

PCI DSS est géré par le Payment Card Industry Security Standards Council (PCI SSC), un organisme fondé par American Express, Discover, JCB, Mastercard et Visa. La norme actuelle est PCI DSS v4.0.

La norme est organisée en 12 exigences réparties sur 6 objectifs :

La conformité s'applique à toute entité qui stocke, traite ou transmet des données de titulaire de carte – ou pourrait affecter la sécurité des données de titulaire de carte. Cela inclut les commerçants, les processeurs de paiement, les acquéreurs, les émetteurs et les prestataires de services.

---

Étape 1 — Définissez et réduisez votre portée

L'environnement de données de titulaire de carte (CDE) est tout système qui stocke, traite ou transmet des données de titulaire de carte (CHD) ou des données d'authentification sensibles (SAD). Réduire la portée est l’étape la plus efficace que vous puissiez prendre.

Données du titulaire de carte et données d'authentification sensibles :

Stratégies de réduction de la portée du commerce électronique :

1. Utilisez une page de paiement hébergée : redirigez les clients vers la page de paiement hébergée de votre processeur de paiement (Stripe Checkout, Braintree Hosted Fields, Adyen Drop-in). Aucune donnée du titulaire de carte ne touche vos serveurs et vous êtes admissible au SAQ A, le questionnaire d'auto-évaluation le plus simple.

2. Tokenisation : remplacez les numéros de carte par des jetons générés par le processeur immédiatement après l'autorisation. Stockez uniquement le jeton, qui est inutile pour les attaquants sans accès au coffre-fort de tokenisation du processeur.

3. Formulaires de paiement basés sur iFrame : intégrez le formulaire rendu en JavaScript par le processeur de paiement dans votre page de paiement. Les données de la carte sont saisies directement dans un formulaire hébergé sur le domaine du processeur, pas le vôtre.

4. Segmentation du réseau : isolez les systèmes CDE (serveurs de traitement des paiements, bases de données) des systèmes hors de portée à l'aide de pare-feu. Des réseaux correctement segmentés réduisent considérablement la portée de l’audit.

---

Étape 2 — Identifiez votre type de SAQ

Le questionnaire d'auto-évaluation (SAQ) est un outil de validation destiné aux commerçants et aux prestataires de services qui ne nécessitent pas d'évaluation sur site d'un évaluateur de sécurité qualifié (QSA). Le type de SAQ est déterminé par la manière dont vous acceptez les paiements :

SAQ A — Applicable aux commerçants sans carte (commerce électronique) qui sous-traitent entièrement le traitement des paiements à un tiers conforme à la norme PCI DSS. Aucune donnée électronique du titulaire de la carte n’est stockée, traitée ou transmise sur vos systèmes ou locaux. Votre page de paiement est entièrement fournie par votre processeur de paiement. Environ 22 exigences.

SAQ A-EP — Pour les commerçants en ligne qui externalisent partiellement le traitement des paiements mais qui disposent toujours d'une page de paiement hébergée sur leur propre serveur, qui intègre une iframe de paiement tierce. Votre serveur Web affecte indirectement la sécurité du traitement des paiements. Plus d'exigences que SAQ A. Gravement affecté par la nouvelle exigence v4.0 6.4.3.

SAQ D — Pour les commerçants qui ne répondent aux critères d'aucun autre type de SAQ ou qui stockent les données des titulaires de carte. Couvre les 12 exigences. Obligatoire pour les commerçants exploitant leur propre infrastructure de traitement des paiements. Généralement environ 300+ sous-exigences.

Niveaux de niveau (norme Mastercard/Visa) :

---

Étape 3 — Modifications clés de la norme PCI DSS v4.0 pour le commerce électronique

PCI DSS v4.0 a introduit plusieurs exigences qui affectent spécifiquement les commerçants de commerce électronique. Tous étaient obligatoires à partir du 31 mars 2025.

Exigence 6.4.3 — Gestion des scripts de la page de paiement

Cette exigence cible directement les attaques Magecart/Web Skimming, dans lesquelles les attaquants injectent du JavaScript malveillant dans les pages de paiement du commerce électronique pour voler les données des titulaires de carte en temps réel. En vertu de l'article 6.4.3, les commerçants utilisant SAQ A-EP ou supérieur doivent :

• Maintenir un inventaire de tous les scripts autorisés à s'exécuter sur les pages de paiement
• Justifier la nécessité business ou technique de chaque script
• Implémenter une méthode pour confirmer l'intégrité de chaque script (hachages d'intégrité des sous-ressources pour les scripts tiers ou directives de politique de sécurité du contenu)

Pour les commerçants SAQ A disposant d'une page de paiement entièrement externalisée, cette exigence s'applique aux pages de votre processeur de paiement — ils doivent démontrer leur conformité en votre nom.

Exigence 11.6.1 — Détection de modification et de falsification des pages de paiement

Les commerçants doivent déployer un mécanisme (par exemple, une politique de sécurité du contenu, un service de surveillance des scripts) pour détecter les modifications non autorisées des en-têtes HTTP et du contenu des scripts sur les pages de paiement. Les alertes doivent être générées dans les 7 jours suivant toute modification non approuvée.

Exigence 8.4.2 — MFA pour tous les accès au CDE

L'authentification multifacteur est désormais requise pour tous les comptes d'utilisateurs ayant accès au CDE, et pas seulement pour l'accès à distance. Cela inclut les utilisateurs internes accédant aux systèmes de paiement de production depuis le réseau de l'entreprise.

Exigence 3.3.1.1 — Le DAS ne peut être conservé après autorisation

Interdit explicitement le stockage des données d'authentification sensibles (données de trace complète, CVV, PIN) après autorisation. Cela a toujours été interdit, mais est désormais formulé plus précisément pour combler les failles dans la façon dont certains systèmes enregistraient SAD dans les sorties de débogage/diagnostic.

Analyse des risques ciblés (TRA)

La version 4.0 introduit le concept d'analyse des risques ciblée : les commerçants peuvent démontrer des approches alternatives à certaines exigences s'ils effectuent une analyse des risques documentée montrant une protection équivalente. Cela offre une flexibilité pour des environnements plus grands et plus complexes.

---

Étape 4 — Architecture de sécurité réseau

Pour les commerçants dont la portée des systèmes dépasse celle du SAQ A, la sécurité du réseau est un domaine de conformité essentiel.

Exigence 1 – Installer et maintenir les contrôles de sécurité du réseau :

• Implémenter un pare-feu entre les réseaux non fiables (internet) et le CDE
• Implémenter un pare-feu entre CDE et les autres réseaux internes (segmentation)
• Documenter toutes les règles de pare-feu avec justification commerciale
• Réviser les règles de pare-feu au moins tous les 6 mois
• Refuser tout le trafic non explicitement requis (posture de refus par défaut)
• Pour le eCommerce : implémenter le WAF (Web Application Firewall) devant les serveurs web

Tests de segmentation du réseau :

Une idée fausse courante est que la segmentation du réseau réduit automatiquement la portée. PCI SSC vous oblige à tester que la segmentation est efficace : les tests d'intrusion doivent inclure les tentatives de franchissement des limites de segmentation. Si un testeur d'intrusion peut accéder aux systèmes CDE à partir de réseaux hors de portée, la segmentation n'est pas efficace et l'environnement plus large entre en jeu.

Architecture DMZ pour le commerce électronique :

Internet → WAF/Load Balancer → DMZ (Web Servers) → Internal Firewall → CDE (Payment Servers, DB) → Internal Network

Les serveurs Web de la DMZ servent votre vitrine. Seul le trafic spécifique et documenté (HTTPS vers API de paiement, SQL sur un port spécifique vers une base de données spécifique) passe de la DMZ au CDE. Tout autre trafic est bloqué.

---

Étape 5 — Exigences de sécurité des applications

Exigence 6 — Développer et maintenir des systèmes et des logiciels sécurisés :

• Maintenir un inventaire de tous les logiciels personnalisés et tiers concernés
• Traiter les vulnérabilités dans le cadre d'un processus formel de gestion des vulnérabilités
• Protéger les applications Web contre les attaques connues (OWASP Top 10)
• Effectuer des revues de code de sécurité ou des tests de pénétration des applications avant le déploiement en production de changements importants
• Utilisez uniquement des logiciels provenant de fournisseurs réputés avec des processus de correctifs de sécurité engagés

Pare-feu d'application Web (WAF) — Exigences 6.3.2 et 6.4.2 :

WAF est obligatoire pour toutes les applications Web publiques, configuré pour bloquer les attaques ou générer des alertes et un examen dans un délai d'une heure. Pour le commerce électronique, WAF doit couvrir :

• Prévention des injections SQL
• Protection contre les scripts intersites (XSS)
• Protection contre la falsification de requêtes intersites (CSRF)
• Détection de robots malveillants
• Limitation du débit pour la prévention de la force brute

Gestion des dépendances et des logiciels tiers :

Les plateformes de commerce électronique (personnalisations WooCommerce, Magento, Shopify) s'appuient fortement sur des plugins et des extensions. Chaque plugin concerné doit être évalué pour sa sécurité. Maintenez un inventaire et appliquez les correctifs dans le cadre de votre SLA de correctifs (critique : 7 jours à compter de la publication du correctif par le fournisseur).

---

Étape 6 — Contrôle d'accès et authentification

Exigence 7 – Restreindre l'accès aux composants du système et aux données des titulaires de carte :

• Implémenter un contrôle d'accès basé sur les rôles basé sur le moindre privilège
• Par défaut, tous les accès sont "tout refuser" avec des autorisations explicites documentées
• Réviser les droits d'accès des utilisateurs au moins tous les 6 mois

Exigence 8 – Identifier les utilisateurs et authentifier l'accès :

• Attribuer un identifiant unique à chaque personne ayant accès au CDE
• Mots de passe d'au moins 12 caractères (v4.0 augmenté de 7 dans la v3.2.1), exigences de complexité
• Verrouiller les comptes après un maximum de 10 tentatives invalides (v4.0 par défaut ou par TRA)
• Délai d'expiration de la session après un maximum de 15 minutes d'inactivité pour les sessions CDE
• MFA requis pour tous les accès CDE (extension v4.0 à distance uniquement)
• Les comptes de service et les comptes système doivent être gérés séparément des comptes d'utilisateurs

---

Étape 7 — Gestion et tests des vulnérabilités

Exigence 11 — Tester la sécurité des systèmes et des réseaux :

Analyses de vulnérabilités internes trimestrielles : analysez tous les systèmes concernés. Corrigez toutes les vulnérabilités de haute gravité et critiques avant la prochaine analyse. Les analyses peuvent être effectuées par le personnel interne à l'aide d'outils approuvés (Nessus, Qualys, OpenVAS).

Analyses de vulnérabilités externes trimestrielles par un fournisseur d'analyses agréé (ASV) : les analyses externes de tous les systèmes accessibles de l'extérieur doivent être effectuées par un ASV approuvé par PCI SSC. L’analyse doit réussir (pas de vulnérabilités ouvertes élevées/critiques) avant que vous puissiez attester de la conformité.

Tests d'intrusion annuels : effectués par une ressource interne qualifiée ou une entreprise externe réputée. Doit couvrir :

• Tous les systèmes et réseaux concernés
• Contrôles de segmentation (vérifier que le CDE est correctement isolé)
• OWASP Top 10 pour les applications Web
• Ingénierie sociale (pour les environnements à plus haut risque)

Corrigez tous les résultats des tests d’intrusion et effectuez des tests de vérification pour confirmer la correction.

Surveillance de l'intégrité des fichiers (FIM) : déployez FIM sur tous les fichiers système critiques, les fichiers de configuration et les fichiers de contenu. Alerte dans l'heure (v4.0) de toute modification non autorisée.

---

Liste de contrôle de conformité PCI DSS pour le commerce électronique

• Portée du traitement des paiements définie et réduite (page de paiement hébergée ou tokenisation utilisée lorsque cela est possible)
• Type de SAQ identifié en fonction du mode d'acceptation du paiement
• Segmentation du réseau mise en œuvre et documentée
• Inventaire des données du titulaire de la carte terminé – aucun SAD stocké nulle part
• Tous les stockages de données des titulaires de cartes sont cryptés (AES-256 ou équivalent)
• TLS 1.2+ appliqué pour toutes les transmissions de données de paiement
• Inventaire des scripts de la page de paiement documenté (Exigence 6.4.3)
• Détection de modification/falsification déployée sur les pages de paiement (Exigence 11.6.1)
• WAF déployé devant toutes les applications Web publiques
• MFA appliqué pour tous les accès CDE (Exigence 8.4.2)
• ID utilisateur uniques, mots de passe forts, verrouillage du compte configuré
• Analyses de vulnérabilités trimestrielles (internes + ASV externes) terminées
• Test d'intrusion annuel terminé, résultats corrigés
• Surveillance de l'intégrité des fichiers déployée sur les systèmes CDE
• Règles de pare-feu révisées au cours des 6 derniers mois
• Formation de sensibilisation à la sécurité achevée pour tout le personnel en contact avec le CDE
• Le plan de réponse aux incidents couvre les scénarios de violation de carte de paiement
• Conformité du fournisseur/prestataire de services PCI DSS vérifiée

---

Questions fréquemment posées

Nous utilisons Shopify pour notre boutique : avons-nous toujours besoin de la conformité PCI DSS ?

Shopify est un fournisseur de services certifié PCI DSS niveau 1. Si vous utilisez le traitement des paiements standard de Shopify (Shopify Payments ou paiement hébergé par Shopify), votre portée de conformité est considérablement réduite. Vous avez toujours des obligations – principalement SAQ A – concernant votre utilisation des services de Shopify. Si vous ajoutez du JavaScript personnalisé à votre paiement Shopify ou utilisez des applications de paiement tierces qui traitent les données de carte en dehors de l'environnement de Shopify, la portée s'étend.

Quelle est la différence entre la conformité PCI DSS et la certification PCI DSS ?

Il n’existe pas de « certification PCI DSS » formelle pour les commerçants. Les commerçants attestent de leur conformité via des questionnaires d'auto-évaluation ou (commerçants de niveau 1) via un rapport de conformité (RoC) réalisé par un QSA. Les prestataires de services peuvent être répertoriés dans le registre mondial des prestataires de services de Visa. Les termes « certifié » et « conforme » sont souvent utilisés de manière interchangeable dans les communications commerciales, mais techniquement, les commerçants attestent eux-mêmes ou font attester leur conformité par la QSA.

À quelles sanctions les commerçants s'exposent-ils en cas de non-conformité ?

Les pénalités ne proviennent pas directement du PCI SSC : elles proviennent des marques de cartes via les banques acquéreuses. Les amendes mensuelles varient généralement de 5 000 $ à 100 000 $ selon le niveau du commerçant et la durée de la non-conformité. À la suite d'une violation, les marques de cartes peuvent imposer des amendes par carte (50 à 90 dollars par carte Visa, similaire pour Mastercard), des frais d'enquête médico-légale (20 000 à 200 000 dollars et plus) et des frais de réémission obligatoires de la carte. Dans les cas graves, les commerçants perdent entièrement la capacité d’accepter les paiements par carte. Les récidivistes ou les commerçants ayant des conséquences importantes en matière de violation s'exposent aux sanctions les plus élevées.

Qu'est-ce qu'une attaque Magecart et comment la norme PCI DSS v4.0 y répond-elle ?

Magecart fait référence à des attaques dans lesquelles du JavaScript malveillant est injecté dans les pages de paiement du commerce électronique pour intercepter les données des titulaires de carte en temps réel au fur et à mesure que les clients les saisissent. Ces attaques exploitent des scripts tiers (analyses, widgets de chat, gestionnaires de balises) que les commerçants incluent sur les pages de paiement. Les exigences PCI DSS v4.0 6.4.3 et 11.6.1 répondent directement à ce problème : les commerçants doivent inventorier et vérifier l'intégrité de tous les scripts sur les pages de paiement, et déployer une surveillance pour détecter les modifications non autorisées du code de la page de paiement.

Comment gérer la norme PCI DSS pour une architecture de commerce électronique sans tête ?

Le commerce électronique sans tête sépare la couche de présentation front-end du moteur de commerce back-end. Aux fins de la norme PCI DSS, ce qui compte, c'est l'endroit où circulent les données des titulaires de carte. Si votre interface sans tête utilise Stripe Elements ou une solution similaire basée sur iFrame, les données de carte passent directement du navigateur au processeur de paiement sans toucher à vos serveurs frontaux - c'est le territoire de la SAQ A. Si votre architecture sans tête implique un traitement des paiements personnalisé côté serveur, la portée s'étend considérablement et vous devez faire appel à un QSA pour obtenir des conseils sur la portée.

Avons-nous besoin d'un QSA pour notre évaluation PCI DSS ?

Seuls les commerçants de niveau 1 (plus de 6 millions de transactions/an pour Visa/Mastercard) sont tenus d'engager un QSA pour un rapport annuel de conformité (RoC). Les commerçants de niveau 2 à 4 peuvent s'auto-certifier via la SAQ. Cependant, de nombreux commerçants font volontairement appel à une QSA ou à une société d'évaluation de sécurité qualifiée (QSAC) pour obtenir des conseils, même lorsque cela n'est pas nécessaire, en particulier lorsqu'ils ne sont pas sûrs de leur portée ou disposent d'une infrastructure complexe.

---

Prochaines étapes

La conformité PCI DSS protège les données de paiement de vos clients, limite votre exposition à la responsabilité et constitue une condition préalable au maintien de l'acceptation des cartes. Pour les entreprises de commerce électronique sur Shopify ou sur des plateformes personnalisées, la première étape est toujours de réduire la portée : accéder au SAQ A grâce à une utilisation appropriée des pages de paiement hébergées est le chemin le plus rapide et le plus rentable.

L'équipe de mise en œuvre du commerce électronique d'ECOSIRE possède une vaste expérience dans la création de magasins Shopify et de plateformes de commerce personnalisées conformes à la norme PCI DSS, avec une architecture de paiement conçue dès le départ pour minimiser la portée du CDE.

Commencez : ECOSIRE Shopify Services

Avertissement : ce guide est fourni à titre informatif uniquement et ne constitue pas un conseil juridique ou de conformité. Les exigences PCI DSS peuvent changer et varier selon la marque de la carte et l'acquéreur. Faites appel à un QSA pour obtenir des conseils de conformité définitifs spécifiques à votre environnement.