PCI DSS et protection des données pour une boutique en ligne — ce qu’il faut respecter avant d’accepter les cartes

Le PCI DSS, la protection des données suisse et l’obligation suisse de signaler les cyberattaques contre les infrastructures critiques sont trois obligations distinctes qu’on confond facilement en un vague problème de « sécurité » — et leur périmètre est très différent. Le PCI DSS ne s’applique qu’aux boutiques qui acceptent le paiement par carte, et son périmètre réel dépend de la manière dont le paiement par carte est intégré : une redirection vers la page du prestataire de paiement donne le périmètre le plus restreint, un iframe intégré en exige davantage. Le droit suisse de la protection des données s’applique à toute boutique qui traite des données de clients, quel que soit le mode de paiement. L’obligation suisse de signaler les cyberattaques contre les infrastructures critiques, malgré l’attention que reçoit son pendant européen NIS2, ne concerne généralement pas une boutique en ligne qui vend ses propres produits. Cet article passe en revue les trois, en indiquant clairement ce qui est confirmé à la source et ce qui ne l’est pas.

Le PCI DSS — qu’est-ce que c’est, qui vérifie la conformité

Le PCI DSS (Payment Card Industry Data Security Standard) est une norme de sécurité des données de cartes de paiement, élaborée par les marques de paiement et administrée par le PCI Security Standards Council (PCI SSC). La version actuelle de la norme est PCI DSS v4.0.1 — elle figure sous ce titre dans la bibliothèque de documents du PCI SSC, avec le document « PCI DSS Summary of Changes v4.0 to v4.0.1 » (pcisecuritystandards.org/document_library, consulté le 2026-10-01). Le PCI SSC a publié la v4.0.1 en juin 2024 comme révision limitée de la v4.0 — avec des corrections rédactionnelles et des clarifications, mais « There are no additional or deleted requirements in this revision » (blog du PCI SSC, 11 juin 2024, consulté le 2026-10-01).

Qui vérifie la conformité ? Pas le PCI SSC lui-même — l’organisation publie la norme, mais la vérification est effectuée par l’entité qui accepte la conformité, généralement un acquéreur (la banque du commerçant pour les paiements par carte) ou une marque de paiement. La FAQ officielle du PCI SSC est explicite sur ce point : « Merchants should continue to consult with their compliance-accepting entity, the entity to which the SAQ will be submitted (typically, an acquirer (merchant bank) or the payment brands), to determine if the merchant is required to submit an SAQ, and if so, which SAQ is appropriate for the merchant's environment » (pcisecuritystandards.org/faqs/1588, consulté le 2026-10-01). En d’autres termes : c’est votre banque acquéreuse, ou le prestataire de paiement avec lequel vous travaillez, qui décide quel document vous devez remplir — pas vous, et pas cet article.

Les prestataires de paiement publient des attestations pour leurs propres services : Stripe, qui sert aussi les commerçants suisses, indique avoir été audité par un évaluateur certifié PCI et bénéficier de la certification « Fournisseur de services PCI de niveau 1 » (docs.stripe.com/security, consulté le 2026-10-01). Cette certification couvre les systèmes du prestataire, pas votre site. Certains prestataires vont plus loin et vous indiquent quel SAQ remplir selon votre mode d’intégration (Stripe dit le faire dans son Dashboard), mais la conformité de votre boutique reste de votre responsabilité.

Quel SAQ s’applique à votre boutique

Le SAQ (Self-Assessment Questionnaire) est le questionnaire d’auto-évaluation par lequel un commerçant confirme sa conformité au PCI DSS — son périmètre dépend exactement de la manière dont le paiement par carte est intégré sur votre site.

Si vous redirigez le client vers la page du prestataire de paiement (par exemple une redirection HTTP 30x, une méta-redirection ou une redirection JavaScript) ou si vous externalisez entièrement le paiement (par exemple un lien de paiement envoyé par e-mail vers un TPSP) — c’est le périmètre le plus restreint : vous êtes généralement éligible au SAQ A, le plus simple (à condition de remplir les autres critères d’éligibilité, que votre acquéreur confirmera), et le critère spécifique et supplémentaire de protection des scripts ne s’applique pas à votre boutique. La FAQ #1588 du PCI SSC l’énonce directement : le critère de script du SAQ A r1 « does not apply to e-commerce merchants with a webpage that redirects customers from the merchant's webpage to a TPSP/payment processor […] or e-commerce merchants that fully outsource payment functions to a TPSP/payment processor » (consulté le 2026-10-01). Cela ne signifie pas une obligation nulle, cependant — une autre FAQ du PCI SSC (#1604) confirme que le SAQ A « includes requirements for external vulnerability scanning by a PCI SSC Approved Scanning Vendor (ASV)… even where payment processing is fully outsourced to a third party » — donc même avec une redirection complète, un scan ASV de votre propre site reste nécessaire. Une redirection donne le périmètre le plus restreint, pas un périmètre nul.

Si vous intégrez le formulaire de paiement du prestataire dans un iframe sur votre propre page (le client paie sans quitter votre domaine, mais le champ carte lui-même est rendu par l’iframe du prestataire) — le critère de script du SAQ A r1 s’applique à vous. FAQ #1588 : « The above SAQ A eligibility criteria only applies to e-commerce merchants with a webpage that includes a TPSP's/payment processor's embedded payment page/form (for example, one or more inline frame(s) (iframes)) ». Dans ce cas, vous devez remplir le critère de l’une des deux manières suivantes : appliquer des techniques de protection des scripts contre les attaques visant les données de carte, y compris celles décrites dans les exigences PCI DSS 6.4.3 et 11.6.1, ou obtenir de votre fournisseur d’iframe (conforme au PCI DSS) la confirmation que sa solution intègre déjà ces techniques de protection — les deux voies sont explicitement mentionnées dans la même FAQ.

« PCI 4.0 » — ce qui a changé, et pourquoi le 31 mars 2025 compte

Le PCI DSS v4.0 a introduit un mécanisme d’exigences « à date différée » (future-dated) — de nouvelles exigences annoncées à l’avance, qui pouvaient être marquées « Not Applicable » dans une évaluation de conformité avant leur date d’entrée en vigueur, et devaient être pleinement évaluées à partir de cette date (FAQ #1564). Pour les exigences à date différée introduites par la v4.0, cette échéance était le 31 mars 2025 — la publication de la v4.0.1 ne l’a pas changée (blog du PCI SSC, 11 juin 2024). Le PCI SSC confirme également directement que les exigences 6.4.3, 11.6.1 et 12.3.1 — relatives à la sécurité de la page de paiement et des scripts — s’appliquent depuis le 31 mars 2025. Dans la même annonce, il les a retirées du SAQ A lui-même, les remplaçant par le critère d’éligibilité relatif aux scripts décrit plus haut, et a précisé que ce changement ne supprime ni n’affaiblit ces exigences dans la norme elle-même (blog du PCI SSC, 30 janvier 2025, consulté le 2026-10-01).

Une FAQ distincte, la #1593 (mars 2025), porte sur un point plus restreint : trois exigences qui, au 31 mars 2025, ont remplacé leurs prédécesseurs (devenus « Not Applicable »). Il s’agit de 6.4.2 (détection/prévention automatisée des attaques web sur les applications accessibles au public, remplaçant 6.4.1), 8.3.10.1 (pour les fournisseurs de services : changement du mot de passe client au moins tous les 90 jours, ou accès déterminé par une analyse dynamique de la posture de sécurité des comptes (« dynamic analysis of accounts' security posture »), remplaçant 8.3.10) et 10.7.2 (détection/alerte/réponse en cas de défaillance des systèmes de contrôle de sécurité critiques, remplaçant 10.7.1). Ce n’est pas une liste complète de ce qui est entré en vigueur ce jour-là — seulement les éléments qui en ont remplacé d’autres.

La formule « le PCI 4.0 est strictement appliqué depuis 2025 » est à lire avec prudence : le PCI SSC affirme explicitement que « PCI SSC does not define compliance requirements for any organization or set compliance validation responsibilities » — les exigences de validation sont fixées par les marques de paiement et les acquéreurs (blog du PCI SSC, 30 janvier 2025). Les exigences sont obligatoires dans la norme ; la manière et le moment où votre acquéreur les vérifie se règlent avec lui.

La protection des données selon le droit suisse (LPD)

La Suisse n’est membre ni de l’UE ni de l’EEE : une boutique qui vend en Suisse relève de la loi fédérale sur la protection des données (LPD, RS 235.1), dont la version révisée, souvent appelée nLPD, est en vigueur depuis le 1er septembre 2023 (Fedlex, LPD, état le 1er septembre 2023, consulté le 2026-10-01). Si vous vendez aussi dans l’UE, les règles du RGPD sur son champ d’application territorial peuvent s’appliquer en parallèle ; c’est une question distincte, que cet article ne traite pas.

La LPD n’est pas construite comme le RGPD. Elle n’exige pas une base légale tirée d’une liste pour chaque traitement ; l’art. 6 pose des principes que tout traitement doit respecter : il « doit être licite », « conforme aux principes de la bonne foi et de la proportionnalité », et les données ne peuvent être collectées « que pour des finalités déterminées et reconnaissables pour la personne concernée ». Quatre dispositions comptent le plus au quotidien d’une boutique.

L’article 19 (devoir d’informer lors de la collecte de données personnelles) vous oblige à communiquer au client, au moment de la collecte, au moins l’identité et les coordonnées du responsable du traitement, la finalité du traitement et, le cas échéant, les destinataires ou catégories de destinataires des données. Si des données sont communiquées à l’étranger (par exemple à un hébergeur ou à un prestataire d’e-mailing hors de Suisse), il faut aussi indiquer l’État concerné. En pratique, c’est le contenu minimal de votre déclaration de protection des données.

L’article 9 (sous-traitance) permet de confier un traitement à un sous-traitant par contrat ou en vertu de la loi, à condition que seuls soient effectués les traitements que vous seriez en droit d’effectuer vous-même et qu’aucune obligation de secret ne l’interdise. Le responsable doit en outre s’assurer que le sous-traitant est en mesure de garantir la sécurité des données. L’hébergement, une plateforme e-commerce en SaaS, un prestataire d’e-mails ou de SMS et un prestataire logistique sont des sous-traitants typiques.

L’article 8 (sécurité des données) impose aux responsables du traitement et aux sous-traitants d’assurer, « par des mesures organisationnelles et techniques appropriées, une sécurité adéquate des données personnelles par rapport au risque encouru » ; ces mesures « doivent permettre d’éviter toute violation de la sécurité des données ». Le Conseil fédéral fixe les exigences minimales dans une ordonnance.

Les sanctions diffèrent aussi de celles du RGPD. Au lieu d’amendes administratives contre l’entreprise, les art. 60 et 61 prévoient des amendes pénales de 250 000 francs au plus contre les personnes privées responsables qui agissent intentionnellement : par exemple omettre de fournir aux clients les informations exigées par l’art. 19, confier des données à un sous-traitant sans respecter les conditions de l’art. 9, ou ne pas respecter les exigences minimales de sécurité édictées par le Conseil fédéral.

Les e-mails publicitaires relèvent d’une autre loi, la loi fédérale contre la concurrence déloyale (LCD, RS 241), art. 3, al. 1, let. o : envoyer de la publicité de masse par voie de télécommunication sans le consentement préalable du client est déloyal, avec une exception. Le commerçant qui a obtenu les coordonnées d’un client lors d’une vente, et lui a indiqué qu’il pouvait s’opposer à ces envois, peut lui adresser de la publicité sans consentement, « pour autant que cette publicité concerne des marchandises, œuvres et prestations propres analogues ». Chaque envoi doit mentionner correctement l’émetteur et permettre de s’y opposer gratuitement et facilement.

Une violation de la sécurité des données : pas de délai chiffré, information des clients sous conditions

Là où le RGPD impose un délai de 72 heures, la LPD fonctionne autrement. L’article 24 (« Annonce des violations de la sécurité des données ») fixe l’essentiel dans ses quatre premiers alinéas :

> « 1 Le responsable du traitement annonce dans les meilleurs délais au PFPDT les cas de violation de la sécurité des données entraînant vraisemblablement un risque élevé pour la personnalité ou les droits fondamentaux de la personne concernée.

> 2 L’annonce doit indiquer au moins la nature de la violation de la sécurité des données, ses conséquences et les mesures prises ou envisagées.

> 3 Le sous-traitant annonce dans les meilleurs délais au responsable du traitement tout cas de violation de la sécurité des données.

> 4 Le responsable du traitement informe la personne concernée lorsque cela est nécessaire à sa protection ou lorsque le PFPDT l’exige. »

L’al. 5 permet de restreindre l’information de la personne concernée, de la différer ou d’y renoncer dans certains cas, notamment lorsqu’elle est impossible à fournir ou exige des efforts disproportionnés, ou lorsqu’une communication publique la garantit de manière équivalente. L’al. 6 précise qu’une annonce ne peut être utilisée dans une procédure pénale contre la personne tenue d’annoncer qu’avec son consentement.

Deux différences avec le RGPD ressortent. D’abord, le droit suisse ne fixe aucun délai en heures : la règle est « dans les meilleurs délais », et l’annonce au Préposé fédéral à la protection des données et à la transparence (PFPDT) n’est due que si la violation entraîne vraisemblablement un risque élevé. Ensuite, l’information des clients eux-mêmes est conditionnelle, ce qui est plus proche de l’obligation distincte du RGPD, elle aussi fondée sur le risque, que ne le laisse croire le raccourci « 72 heures contre aucun délai ». Si vous recourez à un sous-traitant externe (un hébergeur ou une plateforme SaaS, par exemple), il doit vous avertir « dans les meilleurs délais », sans délai chiffré non plus.

L’obligation suisse de signaler les cyberattaques contre les infrastructures critiques

La directive européenne NIS2 ne s’applique pas en Suisse : les directives lient les États membres de l’UE par leur transposition nationale, et la Suisse n’en fait pas partie. La Suisse a sa propre obligation de signaler les cyberattaques contre les infrastructures critiques, inscrite dans la loi sur la sécurité de l’information (LSI). Depuis le 1er avril 2025, les exploitants concernés doivent annoncer les cyberattaques à l’Office fédéral de la cybersécurité (OFCS) dans les 24 heures suivant leur détection ; si toutes les informations requises ne peuvent pas être fournies dans ce délai, ils disposent de 14 jours pour compléter leur annonce (OFCS, information sur l’obligation de signaler, consulté le 2026-10-02).

Les assujettis figurent dans une liste fermée, à l’art. 74b LSI (RO 2024 257, Fedlex) : entre autres les autorités fédérales, cantonales et communales, les entreprises de l’approvisionnement énergétique et en eau potable, les banques et les assurances, les hôpitaux, les transports ferroviaires et aériens, les prestataires de services postaux enregistrés, les fournisseurs de télécommunication, les exploitants d’informatique en nuage, de moteurs de recherche et de centres de calcul ayant leur siège en Suisse, ainsi que les « entreprises qui approvisionnent la population en biens d’usage quotidien indispensables et dont la défaillance partielle ou complète entraînerait de graves difficultés d’approvisionnement ». En vertu de l’art. 74c, le Conseil fédéral exempte de l’obligation les organisations lorsque les perturbations provoquées par une cyberattaque n’auraient qu’un effet limité sur le fonctionnement de l’économie ou sur le bien-être de la population.

Une boutique en ligne qui vend directement à ses propres clients ne figure pas dans cette liste. Seule la dernière catégorie mérite un second regard : un grand distributeur de biens de première nécessité pourrait y entrer. Pour les autres, mieux vaut consigner cette conclusion par écrit que la supposer.

Liste de contrôle sécurité

• Vous avez vérifié avec votre acquéreur ou votre prestataire de paiement quel SAQ s’applique réellement à vous — sans le deviner à partir de l’apparence de votre tunnel de paiement.
• Si vous intégrez un formulaire de paiement dans un iframe, vous disposez soit d’une confirmation du fournisseur de l’iframe, soit de vos propres techniques de protection des scripts (selon le critère de la FAQ #1588) — vous n’avez pas simplement supposé que « c’est le problème du prestataire de paiement ».
• Votre déclaration de protection des données contient au moins ce qu’exige l’art. 19 LPD : identité et coordonnées du responsable du traitement, finalité, destinataires ou catégories de destinataires et, si des données partent à l’étranger, les États concernés.
• Vous avez un contrat avec chaque sous-traitant qui traite des données pour vous (hébergement, SaaS, e-mail/SMS, logistique) et vous vous êtes assuré qu’il peut garantir la sécurité des données (art. 9).
• Vos e-mails publicitaires ne partent qu’aux clients qui ont consenti, ou à des clients existants pour des produits analogues, avec la possibilité de refuser indiquée lors de la collecte et dans chaque envoi (art. 3, al. 1, let. o LCD).
• Vous avez une procédure en cas de violation : qui évalue si le risque est élevé, qui annonce le cas au PFPDT « dans les meilleurs délais » (le droit suisse ne fixe aucun délai en heures, contrairement aux 72 heures du RGPD), et quand vous informez aussi les clients concernés.
• Vous avez vérifié l’art. 74b LSI et consigné que votre boutique ne figure pas parmi les organisations tenues de signaler les cyberattaques, au lieu de simplement le supposer.

Si une grande partie de votre dispositif de vente repose sur des services SaaS tiers (hébergement, paiements, un ERP dans le cloud), la répartition de la responsabilité de la sécurité des données entre vous et le prestataire est un sujet distinct, plus large — nous le traitons dans notre article sur la sécurité du cloud.