Tout vendeur en ligne qui accepte des paiements par carte est soumis à PCI DSS. Cette règle s'applique qu'il s'agisse d'une petite boutique Shopify ou d'une plateforme e-commerce générant des millions d'euros de transactions. Le niveau d'exigence et le type de questionnaire d'auto-évaluation (SAQ) dépendent de votre architecture d'intégration — et le bon choix peut réduire votre charge de conformité de façon dramatique.
Pourquoi tous les e-commerçants sont dans le scope PCI DSS
PCI DSS s'applique à toute entité qui stocke, traite ou transmet des données de compte de paiement. En e-commerce, dès que vous affichez une page de paiement par carte — même si vous utilisez un prestataire de paiement tiers — vous êtes potentiellement dans le scope. La question n'est pas de savoir si vous êtes concerné, mais de déterminer quelle est l'étendue de votre périmètre et quel SAQ vous devez remplir.
Il existe une distinction fondamentale entre les e-commerçants selon leur architecture de paiement. Si vos clients saisissent leurs données de carte directement sur votre serveur (intégration directe via formulaire HTML sur votre domaine), vous traitez des données de carte et votre périmètre PCI est maximal. Si vous utilisez une page de paiement hébergée (hosted payment page) ou des champs de paiement intégrés (hosted payment fields) fournis par votre PSP ou par PCI Proxy EU, les données de carte ne passent jamais par vos serveurs, et votre périmètre se réduit considérablement.
Quel SAQ s'applique à votre boutique en ligne ?
Le SAQ A est le plus avantageux pour les e-commerçants. Il s'applique si vous ne traitez pas, ne stockez pas et ne transmettez pas de données de compte — si tout le traitement des cartes est externalisé à un prestataire certifié PCI DSS Level 1, et si votre page de paiement ne contient aucun code JavaScript ou iframe provenant de sources non vérifiées. Ce SAQ ne comprend que 22 exigences. La grande majorité des boutiques en ligne utilisant des hosted payment fields ou une redirection vers une page de paiement hébergée peuvent prétendre au SAQ A.
Le SAQ A-EP s'applique aux e-commerçants qui utilisent des formulaires de paiement sur leur propre domaine avec des scripts tiers (JavaScript embarqué d'un PSP). Ce SAQ comprend 191 exigences et exige notamment un inventaire des scripts exécutés sur votre page de paiement — une obligation introduite par PCI DSS v4.0 qui complexifie significativement la conformité pour ce type d'intégration. Le SAQ D, avec ses 329 exigences, s'applique si vous stockez des données de carte ou si votre intégration fait transiter les données par vos serveurs.
Les risques spécifiques à l'e-commerce : Magecart et skimming
Les attaques de type Magecart — injection de code JavaScript malveillant sur les pages de paiement pour capturer les données de carte en temps réel — sont l'une des menaces les plus actives en e-commerce. Ces attaques ciblent spécifiquement les boutiques en ligne dont la page de paiement charge des scripts tiers depuis des CDN, des plugins ou des bibliothèques JavaScript. PCI DSS v4.0 répond directement à cette menace avec les nouvelles exigences 6.4.3 et 11.6.1, qui imposent un inventaire complet des scripts et un mécanisme de détection des modifications non autorisées.
La solution la plus efficace contre le skimming est d'éliminer les données de carte de votre page de paiement. Avec des hosted payment fields, les champs où le client saisit son numéro de carte et son CVV sont des iframes hébergés chez le prestataire PCI — votre JavaScript ne peut pas accéder à leur contenu, et un attaquant qui injecte du code sur votre page ne peut pas non plus lire les données saisies dans ces champs. Le risque Magecart est neutralisé à la racine.
Comment PCI Proxy EU élimine le scope PCI de votre boutique
L'intégration de PCI Proxy EU dans votre boutique en ligne repose sur des hosted payment fields : des composants JavaScript sécurisés que vous intégrez à votre page de paiement. En apparence, le formulaire de paiement fait partie de votre design. En réalité, les champs PAN et CVV sont des iframes hébergés chez PCI Proxy EU, sur des serveurs certifiés PCI DSS Level 1 hébergés en Europe. Les données de carte ne touchent jamais vos serveurs.
Lorsque votre client clique sur "Payer", PCI Proxy EU tokenise le PAN et vous retourne un token. Votre serveur reçoit ce token, déclenche la transaction auprès de votre PSP (en transmettant le token, non le PAN), et le vault PCI Proxy EU détokenise à la volée pour le réseau de cartes. Vous pouvez conserver le token dans votre base de données pour les commandes récurrentes sans jamais stocker de données de carte. Votre boutique passe du SAQ D ou SAQ A-EP au SAQ A — une réduction de charge de conformité de plus de 90 %.
Plateformes e-commerce et PCI DSS : Shopify, WooCommerce, Magento
Les plateformes e-commerce populaires ont des approches très différentes en matière de PCI DSS. Shopify héberge lui-même le formulaire de paiement et est certifié PCI DSS Level 1 — si vous utilisez Shopify Payments ou une intégration standard, votre périmètre est minimal. WooCommerce (WordPress) est une plateforme auto-hébergée : la conformité PCI dépend entièrement de la façon dont vous configurez votre plugin de paiement. Avec WooCommerce Stripe ou WooCommerce Mollie, si les données transitent via vos serveurs, vous avez un périmètre PCI actif.
Magento (Adobe Commerce) est la plateforme qui génère le plus de risques PCI, précisément parce qu'elle offre le plus de flexibilité dans l'intégration des paiements. De nombreux développeurs Magento configurent des intégrations qui font transiter les données de carte par le serveur Magento avant de les envoyer au PSP — ce qui crée immédiatement un périmètre PCI D. PCI Proxy EU propose une intégration native avec Magento via hosted payment fields qui élimine ce problème.
Questions fréquentes
Si j'utilise Stripe ou Mollie, suis-je exempté de PCI DSS ?
Non — mais votre périmètre est considérablement réduit si vous utilisez correctement les hosted payment fields de ces prestataires. Si les données de carte ne passent jamais par vos serveurs, vous pouvez prétendre au SAQ A. En revanche, si vous utilisez leur API directement depuis votre backend (server-side payment intent avec transmission du PAN), vos serveurs traitent des données de carte et vous avez un périmètre PCI actif.
La nouvelle exigence PCI DSS v4 sur les scripts JavaScript m'affecte-t-elle ?
Les exigences 6.4.3 et 11.6.1 de PCI DSS v4.0 s'appliquent à toute page de paiement qui charge des scripts JavaScript, y compris les pages utilisant des intégrations de type SAQ A-EP. Si vous utilisez des hosted payment fields en iframes (SAQ A), ces exigences ne s'appliquent pas à votre page de paiement. C'est l'un des avantages les plus concrets du SAQ A pour les e-commerçants en 2025.
Combien de temps prend l'intégration de PCI Proxy EU dans une boutique WooCommerce ou Magento ?
L'intégration standard via hosted payment fields dans WooCommerce ou Magento prend typiquement 3 à 7 jours de développement. PCI Proxy EU fournit une documentation technique complète, des exemples de code et un environnement sandbox pour tester l'intégration avant la mise en production. Une fois en production, votre boutique passe du SAQ D ou A-EP au SAQ A.
Vous souhaitez éliminer le scope PCI DSS de votre boutique en ligne avec une intégration simple ? Découvrez PCI Proxy EU.