PCI DSS pour un site de petites annonces pour adultes : ce qui decide vraiment de la charge de conformite

Faire accepter un site de petites annonces pour adultes par un prestataire de paiement est deja un combat en soi, et une fois gagne, la plupart des exploitants pensent que le plus dur est passe. Ce n'est pas le cas. Le compte qui finit par dire oui vient avec une obligation permanente qui n'a rien a voir avec la verification d'age, la moderation, ou les regles qu'un Etat ou un moteur de recherche pourrait imposer. C'est une norme de securite ecrite par les reseaux de cartes eux-memes, et elle s'applique des qu'un numero de carte touche une partie quelconque de votre activite, aussi petite soit-elle.

Ce qui suit n'est pas un conseil juridique, et toute personne qui manipule reellement des donnees de carte devrait faire examiner son cas par un Qualified Security Assessor. C'est la forme d'une decision que presque aucun exploitant ne se rend compte de prendre, parce que c'est generalement un developpeur qui veut construire une page de paiement plus soignee qui la prend a sa place, bien avant que la question n'atteigne le cote commercial de l'entreprise.

La regle que vous avez signee sans la lire

Le PCI DSS, la norme de securite des donnees de l'industrie des cartes de paiement, n'est pas une loi et aucune agence d'Etat ne la fait appliquer. C'est une obligation contractuelle inscrite dans l'accord que chaque commercant signe avec une banque acquereuse ou un facilitateur de paiement, et elle existe parce que Visa, Mastercard et les autres reseaux exigent de leurs acquereurs qu'ils la repercutent sur toute entreprise qui stocke, traite ou transmet un numero de carte. L'organisme meme qui gere la norme est explicite : elle s'applique a toute entite qui manipule des donnees de carte, que ce soit directement ou via un tiers, sans exception liee a la taille ou au volume de transactions.

C'est une question differente de celle que pose un prestataire de paiement avant d'accepter de vous ouvrir un compte. Ce qu'un prestataire veut savoir avant d'accepter de travailler avec vous porte sur l'activite elle-meme : qui la possede, comment les annonces sont controlees, comment les annonceurs sont verifies. Le PCI DSS commence apres que ce compte existe, et il ne s'arrete jamais vraiment. Il se renouvelle chaque annee tant que l'activite accepte les cartes, et il change de forme des que change la maniere dont les cartes sont acceptees.

Le volume de transactions compte, mais pas de la maniere qu'on imagine generalement. Il fixe un "niveau" de commercant, de un a quatre, et ce niveau decide comment la conformite est validee : un petit exploitant remplit un questionnaire d'auto-evaluation, tandis qu'une entreprise traitant des millions de transactions par an a besoin d'un auditeur externe. Ce que le volume ne fait pas, c'est exempter qui que ce soit. Un commercant a haut risque traitant quelques centaines de transactions par mois est soumis exactement a la meme norme de fond qu'une grande chaine, validee simplement par un formulaire plus court.

La seule decision qui fixe votre charge pour des annees

Le formulaire qui s'applique a une activite donnee ne se choisit pas librement. Il est entierement determine par un fait technique : le numero de carte passe-t-il, a un moment quelconque, par un systeme controle par l'exploitant. Envoyer le client vers une page de paiement hebergee par le prestataire, ou integrer un iframe de paiement correctement isole fourni par ce prestataire, fait que le numero de carte ne touche jamais le serveur propre de l'exploitant. Construire au contraire un formulaire de paiement qui recueille le numero de carte et l'envoie vers son propre serveur avant de le transmettre, meme brievement, fait qu'il le touche.

Ce seul fait separe le questionnaire le plus leger du plus lourd par un ordre de grandeur. La voie entierement externalisee, appelee SAQ A, compte environ vingt exigences. La voie ou la propre page de l'exploitant livre ou influence une partie du processus de paiement, meme sans toucher directement le numero de carte, comme un formulaire heberge en interne dont les champs retransmettent les donnees, releve du SAQ A-EP, pres de deux cents exigences. Stocker, traiter ou transmettre reellement les donnees de carte sur ses propres systemes releve du SAQ D, qui couvre l'ensemble complet des controles de la norme : chiffrement, gestion des cles, segmentation reseau, journalisation des acces, controle des acces, le tout, sur plusieurs centaines de points.

Il vaut la peine de dissiper d'emblee un malentendu frequent. Utiliser un iframe fourni par un prestataire conforme ne fait pas automatiquement basculer un site dans le niveau plus lourd du SAQ A-EP : un iframe tiers correctement isole, ou la page propre de l'exploitant n'apporte aucun code capable de voir ou de toucher les champs de paiement, reste generalement eligible a la voie legere du SAQ A. Ce qui fait monter une activite de niveau, c'est le propre code de l'exploitant qui s'introduit dans cette page, que ce soit un formulaire construit maison, un script ajoute pour "ameliorer" le paiement, ou une integration a l'ancienne ou le navigateur envoie les donnees de carte via un code ecrit par l'exploitant plutot que par le prestataire.

Ce que la voie legere exige encore, depuis un an

Il convient de corriger une croyance qui etait vraie auparavant et ne l'est plus. Les exploitants qui ont choisi la voie externalisee ont appris, a juste titre, que cela les tenait a l'ecart de la majeure partie de la charge technique de la norme, et certains pensent encore que cela signifie l'absence totale de controle de securite recurrent. Depuis la version 4.0.1 du PCI DSS, exigible depuis avril 2025, ce n'est plus le cas. Le SAQ A inclut desormais une exigence d'analyses trimestrielles de vulnerabilite externes par un Approved Scanning Vendor, menees contre le site meme de l'exploitant, celui qui heberge la redirection ou l'iframe, meme si ce site ne voit jamais de numero de carte.

Le raisonnement derriere ce changement est simple une fois enonce : la page qui envoie le client vers le processeur de paiement fait toujours partie de la surface d'attaque. Une page de paiement compromise peut rediriger un client vers un endroit different du veritable processeur de paiement, ou charger un script malveillant qui lit les donnees de carte directement dans le navigateur avant meme que l'iframe ne se charge, un schema d'attaque qui a deja frappe de vrais commercants. Deux exigences liees decoulent de la meme logique : l'exploitant doit tenir un inventaire de chaque script qui tourne sur la page de paiement, et detecter les modifications non autorisees du contenu de cette page, des obligations qui s'appliquent dans le SAQ A precisement parce que la page de paiement appartient a l'exploitant, meme quand le numero de carte, lui, ne lui a jamais appartenu.

Ce que la voie legere continue d'eviter, et c'est la l'ecart qui compte vraiment, c'est le test d'intrusion annuel exige par le SAQ A-EP et le SAQ D, ainsi que les controles internes profonds que ces niveaux imposent : chiffrer les donnees de carte stockees, gerer les cles qui les protegent, segmenter le reseau autour de tout systeme qui les touche, et journaliser en detail chaque acces. Choisir la voie externalisee ne signifie pas l'absence de travail de securite. Cela signifie quelques heures d'analyse et d'hygiene des scripts par an, plutot qu'un programme de securite permanent construit autour de donnees que l'activite se retrouverait sinon a stocker.

Ce que coute une erreur sur ce point

Rien de tout cela n'est impose par un tribunal ou un regulateur, ce qui explique en partie pourquoi il est facile de le sous-estimer. Les reseaux amendent la banque acquereuse lorsqu'un commercant de son portefeuille n'est pas conforme, et l'acquereur repercute ce cout directement sur le commercant via le contrat, en partant generalement de montants modestes qui augmentent tant que la non-conformite se prolonge. Aucun barreme public ne fixe ces montants pour chaque acquereur, car l'accord releve de contrats prives plutot que de regles publiques, mais la direction est constante : l'amende augmente avec le temps, pas avec la qualite des explications fournies par l'entreprise sur le retard.

Cela, c'est le cout de la simple non-conformite. Une violation reelle, ou des numeros de carte stockes sont exposes parce qu'un exploitant traitait des donnees que le SAQ A etait justement concu pour lui eviter, represente une depense d'un tout autre ordre. Les reseaux peuvent exiger une enquete forensique menee par un cabinet specialise avant que quiconque soit autorise a rouvrir le compte, payee par le commercant quelle qu'en soit l'issue, et les cartes concernees sont reemises aux frais du commercant. L'assurance responsabilite civile cyber comble rarement ce type de trou pour une activite comme celle-ci, le contenu pour adultes figurant sur la liste des secteurs exclus de plus d'une police cyber de grands assureurs, ce qui signifie que l'exposition decrite ici est tres souvent non assuree, et pas seulement couteuse.

La consequence la plus durable n'est ni l'amende ni meme l'enquete. C'est la decision de l'acquereur, une fois qu'une violation ou une non-conformite prolongee figure au dossier, de fermer le compte plutot que de continuer a assumer le risque, et d'enregistrer cette fermeture d'une maniere que d'autres acquereurs peuvent consulter avant d'en ouvrir un nouveau. Une relation de paiement qui a mis des mois a se construire la premiere fois est bien plus difficile a reconstruire avec cet historique attache a l'activite.

Que faire ce mois-ci

Commencez par decouvrir, par ecrit, quel questionnaire s'applique vraiment aujourd'hui. Demandez-le directement au prestataire de paiement plutot que de supposer la reponse : confirmez si le paiement actuel est une redirection, un iframe correctement isole, ou quelque chose qui touche le serveur propre de l'exploitant a un moment quelconque du parcours, car la reponse a cette question resume a elle seule tout le programme de conformite. Obtenez-la par courriel, pas par telephone, car c'est le point de reference pour chaque decision qui suivra.

Traitez toute demande de modification de la maniere de collecter les cartes comme une question de conformite avant d'etre une question de design. Un developpeur qui veut construire un formulaire de paiement sur mesure parce que la page hebergee parait generique, ou qui ajoute un chat ou un script d'analyse sur la meme page qui heberge l'iframe de paiement, prend une decision PCI, que quelqu'un la presente ainsi ou non. Passez ce genre de changement en revue avant sa mise en ligne, pas apres qu'une analyse l'ait signale.

Deposez l'attestation annuelle dans les delais et conservez les resultats de chaque analyse trimestrielle, meme les plus banales ou rien ne change, car une attestation perimee se lit, aux yeux d'un acquereur, exactement comme si elle n'avait jamais ete deposee. Rien de tout cela n'est difficile quand l'architecture de base est la bonne. Un paiement construit une fois pour toutes autour d'une page hebergee ou d'un iframe correctement isole transforme tout cela en un apres-midi de paperasse, repete une fois par an. Un paiement qui a lentement pris l'habitude de toucher aux donnees de carte transforme la meme obligation en un programme de securite permanent que l'activite n'avait jamais prevu de gerer.