Une question revient régulièrement en début de projet e-commerce : « Faut-il être certifié PCI DSS pour vendre en ligne ? ». La réponse rassure généralement le client : oui, la norme s’applique à toute boutique qui traite des paiements par carte, mais l’immense majorité des boutiques WooCommerce peuvent rester dans la catégorie de conformité la plus légère, à condition de respecter une règle simple dès la conception technique — ne jamais laisser les données de carte transiter par le serveur WordPress lui-même.
PCI DSS (Payment Card Industry Data Security Standard) est un ensemble d’exigences de sécurité imposé par les réseaux de cartes bancaires à tout commerçant qui traite, stocke ou transmet des données de carte. Sa mise en œuvre concrète, pour un site WordPress, dépend presque entièrement de l’intégration technique de la passerelle de paiement.
Comprendre les niveaux de questionnaire d’auto-évaluation
La majorité des e-commerçants ne sont pas audités directement, mais remplissent un questionnaire d’auto-évaluation (SAQ, Self-Assessment Questionnaire), dont le niveau d’exigence dépend de la façon dont les données de carte sont collectées :
- SAQ A : le commerçant ne voit ni ne manipule jamais les données de carte, entièrement déléguées à un prestataire tiers via une redirection complète ou un iframe hébergé par ce prestataire (c’est le cas de Stripe Elements ou Stripe Checkout, ou d’une redirection PayPal classique) ;
- SAQ A-EP : le commerçant héberge la page de paiement mais délègue la saisie elle-même à un iframe tiers, un niveau intermédiaire plus exigeant que SAQ A ;
- SAQ D : le commerçant traite ou stocke lui-même des données de carte, ce qui impose l’ensemble le plus complet des exigences PCI DSS, avec audit renforcé.
Pour une boutique WooCommerce standard utilisant une passerelle reconnue avec Stripe Elements ou une redirection vers un environnement de paiement hébergé, rester en SAQ A est presque toujours atteignable, et c’est l’objectif à viser systématiquement dès la conception du tunnel de commande.
Le piège du formulaire de carte « personnalisé »
La demande client la plus fréquente qui menace ce niveau de conformité léger est esthétique : « Le formulaire de carte de la passerelle ne ressemble pas au design du site, peut-on le refaire à notre charte graphique ? ». Techniquement, Stripe Elements permet effectivement de styliser en profondeur l’apparence du champ de carte tout en conservant sa nature d’iframe isolé, ce qui préserve le niveau SAQ A. La ligne rouge à ne jamais franchir est de recréer un formulaire HTML natif qui capte directement le numéro de carte dans un champ contrôlé par le code du site, même pour le transmettre ensuite à la passerelle par API : cela fait immédiatement basculer la boutique en dehors de SAQ A, car le serveur WordPress a alors « vu » passer une donnée de carte, même sans la stocker.
Ce qu’un développeur doit vérifier concrètement
// Signal d'alerte à rechercher dans le code d'une extension de paiement personnalisée :
// un champ de formulaire natif qui capture directement le numéro de carte
<input type="text" name="numero_carte" pattern="[0-9]{16}" />
// Pratique conforme SAQ A : le champ de carte est entièrement rendu
// et géré par un iframe fourni par la passerelle, jamais par un champ natif du site
Au-delà du formulaire lui-même, plusieurs vérifications techniques restent de la responsabilité directe du développeur, même en restant en SAQ A :
- Le certificat TLS doit être valide et à jour sur l’intégralité du tunnel de commande, pas seulement sur la page d’accueil ;
- Les journaux d’erreurs applicatifs ne doivent jamais enregistrer accidentellement une charge utile de requête contenant un numéro de carte, en cas d’erreur mal gérée dans l’intégration de la passerelle ;
- Aucune extension tierce ne doit avoir accès au flux de paiement pour des raisons qui n’ont rien à voir avec le traitement de la commande (un plugin d’analytics trop intrusif, par exemple, chargé sur la page de paiement elle-même).
La question des enregistrements de carte pour les paiements récurrents
Pour un abonnement WooCommerce Subscriptions ou un système de carte enregistrée en un clic, la tokenisation proposée par les passerelles conformes (Stripe, notamment) permet de stocker un jeton de réutilisation côté prestataire, sans que WordPress ne conserve jamais le numéro de carte réel. C’est cette délégation complète du stockage qui permet à ces fonctionnalités de coexister avec un niveau de conformité SAQ A, à condition que l’intégration passe strictement par les mécanismes de tokenisation officiels de la passerelle plutôt que par un stockage maison, qui serait une faute de sécurité grave en plus d’une non-conformité réglementaire.
Documenter la conformité pour le client
Un développeur n’est jamais seul responsable de la conformité PCI DSS globale de l’entreprise cliente, mais il est le mieux placé pour documenter l’architecture technique retenue : quelle passerelle, quel mécanisme de collecte des données de carte, quel niveau de questionnaire visé. Cette documentation facilite grandement la démarche du client ou de son expert-comptable au moment de remplir effectivement le questionnaire annuel auprès de sa banque acquéreuse.
La meilleure protection contre une non-conformité PCI DSS reste architecturale : ne jamais construire un système qui pourrait techniquement voir passer un numéro de carte. Ce qui n’existe pas dans le code ne peut pas fuiter.
En résumé
Pour la grande majorité des boutiques WooCommerce, rester conforme PCI DSS au niveau SAQ A le plus simple est parfaitement atteignable, à condition de déléguer intégralement la saisie et le stockage des données de carte à la passerelle de paiement, sans jamais recréer un formulaire natif qui les ferait transiter par le serveur. C’est une contrainte architecturale à poser dès le cadrage du projet, bien avant la moindre ligne de code de personnalisation esthétique.
