PCI DSS : réduire le périmètre de conformité de votre plateforme de paiement

Tout système qui touche un numéro de carte bancaire entre dans le champ de PCI DSS, le standard de sécurité des données de l’industrie des cartes de paiement. À la date de rédaction de cet article, la version en vigueur est la v4.0.1, publiée par le PCI Security Standards Council (PCI SSC) en juin 2024. Le standard s’applique à l’environnement des données de carte (en anglais cardholder data environment, ou CDE) et aux systèmes qui y sont connectés. Plus ce périmètre est large, plus les exigences à respecter, les contrôles à documenter et l’audit à passer sont lourds. La meilleure stratégie de conformité commence donc par l’architecture : faire en sorte que le moins de systèmes possible voient passer une donnée de carte. Voici les leviers, et la façon de les combiner.

Qu’est-ce que le périmètre PCI DSS ?

PCI DSS distingue deux familles de données :

• les données du titulaire de carte : le numéro de carte (PAN, pour primary account number), et, lorsqu’ils l’accompagnent, le nom du titulaire, la date d’expiration et le code de service ;
• les données d’authentification sensibles : les données complètes de la piste magnétique ou de la puce, le cryptogramme visuel (CVV, CVC) et les codes PIN.

Entrent dans le périmètre tous les systèmes, personnes et processus qui stockent, traitent ou transmettent ces données. S’y ajoutent les systèmes connectés à ces composants ou capables d’influer sur leur sécurité : serveur d’administration, annuaire, outil de supervision, poste d’un développeur qui accède à la production.

Le périmètre n’est donc pas « le serveur de paiement » : c’est souvent une bonne partie du système d’information, tant qu’aucune frontière n’a été tracée. Le travail consiste à tracer cette frontière et à la rapprocher au maximum du prestataire de paiement (PSP).

Ne jamais toucher le numéro de carte

Le levier le plus puissant : que le numéro de carte ne transite jamais par vos serveurs. Les PSP proposent trois grandes intégrations qui le permettent :

• la page de paiement hébergée : le client est redirigé vers une page du PSP, puis revient sur votre site une fois le paiement effectué ;
• l’iframe : le formulaire du PSP est affiché dans votre page, mais servi par ses serveurs ;
• les champs hébergés : chaque champ sensible (numéro, date, cryptogramme) est une petite iframe du PSP, intégrée dans votre propre formulaire.

Dans ces trois cas, le numéro de carte part directement du navigateur vers le PSP, qui vous renvoie un jeton. Pour un site marchand, ces intégrations ouvrent généralement l’éligibilité au SAQ A, le questionnaire d’auto-évaluation le plus court. La même logique vaut pour les applications mobiles : les SDK des PSP collectent la carte dans des composants fournis par le prestataire et l’envoient directement à ses serveurs, sans passer par votre back-end ; votre PSP indique le questionnaire applicable.

Externaliser ne fait pas disparaître la responsabilité. PCI DSS demande de tenir la liste de vos prestataires, de connaître leur statut de conformité et de documenter qui assume quelle exigence : c’est la matrice de répartition des responsabilités, que les PSP mettent généralement à disposition de leurs clients.

Une réserve importante concerne les scripts de la page qui accueille le paiement. Un script compromis sur votre page peut remplacer le formulaire ou détourner le client vers une fausse page. La v4.0 a introduit des exigences sur l’inventaire et l’intégrité de ces scripts, puis le PCI SSC a précisé, dans une nouvelle version du SAQ A publiée en 2025 et dans ses FAQ, la façon dont les commerçants concernés doivent en tenir compte. Ces précisions ont encore évolué depuis : vérifiez la version du questionnaire en vigueur et, en cas de doute, demandez à votre acquéreur.

La tokenisation

Une fois le paiement effectué, vous avez souvent besoin de réutiliser la carte : abonnement, paiement en un clic, remboursement. La réponse est le jeton (token) : une valeur de substitution, inutilisable en dehors de son contexte, qui remplace le numéro de carte.

• Les jetons du PSP désignent une carte enregistrée chez ce PSP. Vous les stockez et les utilisez pour débiter la carte, sans jamais connaître le numéro.
• Les jetons réseau, émis par les réseaux de cartes, remplacent le numéro de carte pour un commerçant donné. Ils sont en général mis à jour automatiquement quand la banque renouvelle la carte, ce qui limite les échecs de paiement récurrents.

La règle est simple : stockez des jetons, jamais le PAN. Si votre base ne contient que des jetons, elle sort en grande partie du périmètre. Attention toutefois : le système capable de retrouver le numéro à partir du jeton, lui, y reste.

Segmenter le réseau

Quand certains systèmes doivent traiter des données de carte, il faut les isoler du reste. La segmentation n’est pas imposée par PCI DSS, mais sans elle tout le réseau plat entre dans le périmètre.

En pratique : un réseau dédié au CDE, des pare-feu ou des groupes de sécurité qui n’autorisent que les flux nécessaires et documentés, des accès d’administration passant par un bastion avec authentification multifacteur, et des comptes distincts pour la production.

Une segmentation se prouve. Le standard exige de la valider par des tests d’intrusion au moins une fois par an pour les commerçants, plus souvent pour les prestataires de services, ainsi qu’après toute modification des contrôles de segmentation. Un pare-feu mal configuré suffit à remettre dans le périmètre un réseau entier.

Minimiser les données

La donnée la plus sûre est celle que vous ne conservez pas.

• Ne conservez jamais le cryptogramme visuel après l’autorisation, même chiffré. Il en va de même pour les autres données d’authentification sensibles.
• Masquez le numéro à l’affichage : au plus les six ou huit premiers chiffres (le BIN) et les quatre derniers, et seulement pour les personnes qui en ont besoin.
• Fixez des durées de conservation et supprimez régulièrement ce qui les dépasse.
• Surveillez les fuites involontaires : journaux applicatifs, outils de suivi d’erreurs, e-mails au support, tickets, enregistrements d’appels. Un numéro de carte copié dans un ticket fait entrer l’outil de ticketing dans le périmètre.

SAQ A, SAQ A-EP ou SAQ D ?

Les commerçants qui ne sont pas soumis à un audit sur site valident leur conformité avec un questionnaire d’auto-évaluation (SAQ). Le questionnaire dépend de votre intégration :

D’autres questionnaires couvrent le paiement par terminal ou en magasin (SAQ B, B-IP, C, P2PE) et la saisie dans un terminal virtuel, pour les commandes par courrier ou par téléphone (SAQ C-VT). Le tableau donne les cas habituels : les critères d’éligibilité de chaque SAQ font foi, et votre PSP indique le questionnaire correspondant à chacune de ses intégrations.

Les niveaux de commerçant sont fixés par les réseaux de cartes, selon le volume annuel de transactions, et c’est votre acquéreur qui vous indique ce qu’il attend. Pour les plus gros volumes, la validation passe par un rapport de conformité, généralement établi par un QSA, un évaluateur qualifié par le PCI SSC, au lieu d’un questionnaire.

Orchestration multi-PSP : attention au périmètre

Une couche d’orchestration répartit les paiements entre plusieurs PSP : par pays, par moyen de paiement, par coût, ou pour basculer en cas d’incident. Si cette couche reçoit le numéro de carte pour le transmettre au PSP choisi, elle entre dans le périmètre, et avec elle toute l’infrastructure qui l’héberge. Le gain d’agilité se paie alors d’un SAQ D, voire d’un audit complet.

Trois approches permettent de l’éviter ou de le contenir :

• un coffre de tokenisation indépendant, lui-même conforme PCI DSS, qui reçoit la carte depuis le navigateur et la transmet au PSP retenu : votre orchestrateur ne manipule que des jetons ;
• les jetons réseau, qui facilitent l’usage d’une même carte enregistrée auprès de plusieurs PSP, selon ce que chaque PSP prend en charge ;
• un orchestrateur du marché, évalué comme prestataire de services PCI DSS, auquel vous déléguez cette partie du périmètre.

Pour un exemple concret, voir notre réalisation d’orchestration multi-PSP. Dans tous les cas, faites valider le choix par votre QSA ou votre acquéreur avant de le mettre en œuvre.

Plan d’action

1. Inventorier les flux : chaque endroit où une donnée de carte entre, circule ou est stockée, y compris les processus manuels.
2. Dessiner le schéma de flux de données, exigé par le standard, et le tenir à jour.
3. Choisir l’intégration qui garde le numéro de carte hors de vos serveurs.
4. Tokeniser tout ce qui doit être réutilisé et purger les numéros existants.
5. Segmenter les systèmes qui restent dans le périmètre.
6. Documenter les rôles, les politiques et la répartition des responsabilités avec chaque prestataire.
7. Tester : scans de vulnérabilités, tests d’intrusion, validation de la segmentation.
8. Revoir chaque année le périmètre, et après chaque changement d’architecture.

Conclusion

Réduire le périmètre PCI DSS n’est pas une astuce de conformité : c’est une décision d’architecture qui réduit aussi le risque réel. Page ou champs hébergés, jetons au lieu des numéros, réseau segmenté et données minimisées : chaque levier retire des systèmes du périmètre, et les exigences restantes deviennent plus faciles à tenir.

Nous concevons ces architectures et préparons la documentation technique de l’audit ; l’attestation de conformité relève de vous et, selon votre niveau, d’un QSA. Pour en savoir plus, découvrez notre expertise FinTech ou parlons de votre plateforme.

Pour aller plus loin

• Bibliothèque documentaire du PCI SSC : standard PCI DSS v4.0.1, questionnaires SAQ et leurs instructions
• Mise à jour du SAQ A (blog du PCI SSC)
• Guide de conformité PCI DSS d’Adyen (documentation Adyen)
• Guide de sécurité de Stripe (documentation Stripe)