Conformité PCI DSS pour la Banque Cloud-Native en 2026
Guide pratique sur PCI DSS v4.0 pour les fintechs et les banques cloud-natives en France : qui doit se conformer, les 12 exigences résumées, les environnements Kubernetes et conteneurs, la réduction du périmètre par la tokenisation et la segmentation, SAQ vs ROC, et l'interaction avec l'ACPR, l'AMF et le RGPD.
Qu'est-ce que PCI DSS et qui doit s'y conformer ?
PCI DSS - le Payment Card Industry Data Security Standard - est un ensemble mondial de contrôles techniques et opérationnels applicables à toute organisation qui stocke, traite ou transmet des données de cartes de paiement. Il est maintenu par le PCI Security Standards Council, fondé par Visa, Mastercard, American Express, Discover et JCB.
Si votre produit touche un numéro de compte primaire (PAN) de quelque manière que ce soit, PCI DSS vous est applicable. Cela inclut les émetteurs de cartes, les processeurs de paiement, les banques acquéreuses, les plateformes fintech qui gèrent des transactions par carte, et tout service SaaS qui se trouve dans le flux de données entre le titulaire de la carte et un réseau de paiement.
Émetteurs de cartes
Toute plateforme qui émet des cartes virtuelles ou physiques et conserve des numéros de carte doit respecter les exigences PCI DSS relatives au stockage et à la transmission des PAN.
Processeurs de paiement
Tout intermédiaire qui achemine des transactions par carte entre un commerçant et un réseau de cartes - y compris les fournisseurs BaaS et les passerelles de paiement - est dans le périmètre.
Prestataires de services
Les plateformes cloud, les fournisseurs de services gérés et les éditeurs SaaS susceptibles d'affecter la sécurité de l'environnement de données de titulaires de cartes d'un client sont également dans le périmètre.
Depuis le 31 mars 2025, PCI DSS v4.0.1 est la seule version active. Les 64 exigences nouvelles ou mises à jour introduites dans v4.0 sont désormais obligatoires : la période de transition est terminée. En France, les fintechs agréées par l'ACPR ou supervises par l'AMF constateront que de nombreux contrôles PCI DSS recoupent les attentes de sécurité IT de leurs superviseurs et les obligations du RGPD, ce qui rend une stratégie de conformité intégrée particulièrement pertinente.
La non-conformité entraîne de réelles conséquences financières : les banques acquéreuses peuvent imposer des pénalités mensuelles de 5 000 à 100 000 EUR pour les violations non résolues. Une violation de données dans un environnement non conforme peut déclencher des amendes des réseaux de cartes, une investigation forensique obligatoire et la perte du droit de traiter des paiements par carte.
Discutons de votre projet et voyons comment nous pouvons lancer votre projet. produit bancaire numérique ensemble
Demander une démoLes 12 exigences résumées pour la banque
PCI DSS v4.0.1 organise ses contrôles en 12 familles d'exigences regroupées sous six objectifs. Le tableau suivant met en correspondance chaque exigence avec les contrôles les plus pertinents pour un fintech ou une banque cloud-native.
| # | Exigence | Ce que cela signifie en pratique |
|---|---|---|
| 1 | Contrôles de sécurité réseau | Pare-feux, groupes de sécurité et règles VPC qui isolent l'environnement de données de titulaires de cartes (CDE) des autres réseaux. |
| 2 | Configurations sécurisées | Pas de mots de passe par défaut ; images OS et conteneurs renforcées ; pas de ports ou services inutilisés. |
| 3 | Protéger les données de compte stockées | Chiffrer les PAN au repos avec AES-256 ou équivalent. Les rendre illisibles dans tout stockage : bases de données, sauvegardes, journaux. |
| 4 | Protéger les données des titulaires en transit | TLS 1.2+ pour toutes les transmissions ; pas de protocoles non chiffrés dans le CDE. |
| 5 | Se protéger contre les logiciels malveillants | Antimalware pour les systèmes applicables ; analyse des images de conteneurs dans les pipelines CI/CD. |
| 6 | Développer et maintenir des systèmes et logiciels sécurisés | Gestion des correctifs, SDLC sécurisé, pare-feu applicatif web, intégrité des scripts de pages de paiement (nouveau dans v4.0). |
| 7 | Restreindre l'accès selon le besoin métier | Contrôle d'accès basé sur les rôles (RBAC) ; principe du moindre privilège appliqué aux comptes de service et aux personnes. |
| 8 | Identifier les utilisateurs et authentifier les accès | MFA requise pour tous les accès au CDE, y compris les utilisateurs non administrateurs (nouvelle obligation dans v4.0). |
| 9 | Restreindre l'accès physique aux données des titulaires | Contrôles des supports physiques ; registres des visiteurs ; procédures de destruction. En cloud : attestation de sécurité du CSP. |
| 10 | Journaliser et surveiller tous les accès | Pistes d'audit pour toute activité du CDE ; intégration SIEM ; stockage de journaux inviolables ; rétention minimale de 12 mois. |
| 11 | Tester régulièrement la sécurité | Analyses ASV trimestrielles, tests d'intrusion annuels, analyses internes de vulnérabilités ; IDS/IPS le cas échéant. |
| 12 | Soutenir la sécurité par des politiques organisationnelles | Politique de sécurité documentée, évaluations des risques, formation à la sensibilisation à la sécurité, gestion des fournisseurs tiers. |
L'un des changements conceptuels les plus importants de la v4.0 est le passage d'événements de conformité annuels à une surveillance continue. Les contrôles qui étaient auparavant vérifiés une fois par an lors d'un audit doivent maintenant être démontrables en continu. En France, l'ACPR et l'AMF ont toutes deux développé des approches de conformité basées sur l'innovation : elles soutiennent l'adoption de contrôles automatisés et la supervision par le code, ce qui s'aligne bien avec les exigences de surveillance continue de PCI DSS v4.0.
PCI DSS dans les environnements cloud-natifs et de conteneurs
Les lignes directrices PCI DSS traditionnelles ont été rédigées pour des salles de serveurs avec des plages d'IP fixes. Les environnements cloud-natifs - clusters Kubernetes, fonctions serverless, conteneurs éphémères, configurations multi-comptes - nécessitent une approche différente pour la plupart des 12 exigences. La norme s'adapte grâce à l'"Approche personnalisée" qui permet de satisfaire aux objectifs de sécurité par des contrôles adaptés à sa propre architecture.
Le modèle de responsabilité partagée. Lorsqu'on opère sur un cloud public, le fournisseur cloud (CSP) possède la couche physique et l'hyperviseur. Tout ce qui est au-dessus relève de votre responsabilité. Cartographier clairement cette frontière est la première étape de la définition du périmètre PCI en cloud.
| Couche | Responsable | Contrôles PCI |
|---|---|---|
| Infrastructure physique et hyperviseur | Fournisseur cloud (CSP) | Sécurité physique, isolation matérielle. Le CSP fournit une Attestation de Conformité (AoC). |
| VPC, groupes de sécurité, politiques IAM | Votre équipe | Segmentation réseau, IAM à moindre privilège, chiffrement en transit entre services. |
| Cluster Kubernetes, plan de contrôle | Votre équipe | Durcissement du cluster, RBAC, normes de sécurité des pods, analyse des images, contrôleurs d'admission. |
| Couche applicative et logique métier | Votre équipe | mTLS entre services, validation des entrées, SDLC sécurisé, WAF pour les pages de paiement. |
| Données au repos (bases de données, stockage objet) | Votre équipe | Chiffrement via KMS, rotation des clés, journalisation des accès, chiffrement des sauvegardes. |
Zero-trust et service mesh. Dans une architecture de microservices, le périmètre traditionnel n'existe pas. Chaque pod et service a besoin de sa propre identité. Un service mesh comme Istio ou Linkerd impose le TLS mutuel entre tous les services, fournit une observabilité par requête et limite le rayon d'explosion : si un conteneur est compromis, le mTLS empêche le mouvement latéral vers les services adjacents. Cela correspond directement à l'Exigence 4 (chiffrement en transit) et soutient le mandat de surveillance continue de l'Exigence 10.
La politique en tant que code. Des outils comme Open Policy Agent (OPA) ou Kyverno permettent de définir des contrôles PCI en tant que code et de les appliquer au moment de l'admission : interdire les conteneurs avec des privilèges root, bloquer les équilibreurs de charge publics pour les services internes, exiger la provenance des images depuis un registre signé, détecter les dérives de configuration. Pour les environnements soumis à la réglementation française sur la souveraineté numérique, la politique en tant que code peut également imposer des restrictions de résidence des données, garantissant que les données des titulaires restent dans des centres de données européens - un point particulièrement important dans le contexte de la doctrine cloud de confiance promue par l'ANSSI.
Réduction du périmètre par la tokenisation et la segmentation réseau
Le moyen le plus efficace de réduire le coût et la complexité de la conformité PCI est de minimiser la taille de l'environnement de données des titulaires de cartes. Moins de systèmes dans le périmètre signifie un audit plus restreint, moins de preuves à rassembler et une surface d'attaque réduite. Deux techniques permettent de réduire le périmètre : la tokenisation et la segmentation réseau.
La tokenisation. Un système de tokenisation remplace le PAN brut par une valeur de substitution (le token) qui n'a aucune relation cryptographique avec l'original. Les systèmes qui ne voient que le token - votre CRM, portail client, pipeline d'analyse - sont hors périmètre. Les seuls composants dans le périmètre sont le coffre de tokenisation, le système de gestion des clés et toute application qui appelle l'API de détokenisation.
Pour qu'un token retire un système du périmètre, deux conditions doivent être remplies : le système token-only ne doit pas avoir accès au coffre, aux clés ni à l'endpoint de détokenisation ; et le token doit être irréversible par le système récepteur sans appel API au coffre. Si ces deux conditions sont réunies, les lignes directrices de tokenisation du PCI Security Standards Council confirment que ces systèmes tombent en dehors du CDE.
La segmentation réseau. La segmentation sépare les systèmes qui contiennent ou touchent des PAN de ceux qui n'en ont pas. Dans un environnement Kubernetes, cela signifie des namespaces ou des pools de nœuds dédiés aux workloads CDE, des politiques réseau bloquant tout le trafic des namespaces non CDE vers les namespaces CDE (sauf les chemins explicitement autorisés), et des VPC ou comptes séparés pour le traitement des données de cartes.
Avantages de la tokenisation
- Retire des niveaux applicatifs entiers du périmètre PCI
- Protège les données même si un système non CDE est compromis
- Fonctionne avec le chiffrement (complémentaire, pas alternatif)
- Les contrôles d'accès requis sont plus simples à auditer
Avantages de la segmentation
- Limite le rayon d'explosion d'un incident de sécurité
- Réduit le nombre de systèmes soumis aux contrôles PCI complets
- Permet des postures de sécurité distinctes pour CDE et non CDE
- Fournit une frontière d'audit claire pour le QSA ou le SAQ
Les erreurs de périmètre sont la défaillance la plus courante et la plus coûteuse lors des évaluations PCI. Une erreur fréquente consiste à supposer que le chiffrement seul retire un système du périmètre. Le chiffrement protège les données au sein du CDE, mais ne contracte pas la frontière du CDE. Seule la tokenisation (correctement mise en œuvre) et la segmentation démontrée retirent des systèmes du périmètre. En France, où les données des titulaires de cartes sont aussi des données personnelles au sens du RGPD, une violation déclenche simultanément des obligations de notification PCI DSS et une notification à la CNIL dans un délai de 72 heures.
SAQ vs ROC, niveaux commerçants et le processus d'évaluation
Les exigences de validation PCI DSS dépendent de votre niveau de commerçant ou de prestataire de services, fixé par les réseaux de cartes (Visa, Mastercard, etc.) en fonction du volume annuel de transactions et du profil de risque.
| Niveau | Seuil de transactions | Méthode de validation |
|---|---|---|
| Niveau 1 | Plus de 6 millions de transactions par carte/an (commerçants) ; plus de 300 000/an (prestataires de services ou après violation) | Rapport de conformité (ROC) annuel par un Qualified Security Assessor (QSA) ; analyses ASV trimestrielles |
| Niveau 2 | 1 à 6 millions de transactions/an | SAQ annuel ou évaluation menée par un QSA ; analyses ASV trimestrielles |
| Niveau 3 | 20 000 à 1 million de transactions e-commerce/an | SAQ annuel ; analyses ASV trimestrielles |
| Niveau 4 | Moins de 20 000 transactions e-commerce ou moins de 1 million de transactions totales/an | SAQ annuel recommandé ; analyses ASV selon les exigences de l'acquéreur |
SAQ (Self-Assessment Questionnaire). Le SAQ est une autodéclaration. Il existe plusieurs types de SAQ (A, A-EP, B, B-IP, C, C-VT, D, P2PE-HW) selon la façon dont les données de cartes sont gérées. Le SAQ-A couvre les commerçants qui externalisent entièrement la gestion des données de cartes. Le SAQ-D - le plus complet - s'applique lorsque les PAN sont stockés, traités ou transmis en interne, et reflète presque l'ensemble complet des contrôles PCI DSS. Compléter un SAQ-D demande typiquement six à douze mois pour un fintech qui part de zéro.
ROC (Report on Compliance). Le ROC est un audit indépendant effectué par un QSA ou un Internal Security Assessor (ISA) certifié. Il est obligatoire pour les entités de Niveau 1 et est fréquent chez les prestataires de services et les fintechs à fort volume. De nombreux fintechs poursuivent volontairement une évaluation de type ROC avant d'en avoir techniquement besoin, car les clients enterprise et les partenaires de réseaux de cartes l'exigent souvent comme condition de partenariat. En France, l'ACPR supervise les établissements de paiement et peut exiger des garanties de sécurité spécifiques au-delà de PCI DSS - une conformité proactive est donc un avantage concurrentiel, pas seulement une obligation réglementaire.
Comment la plateforme Crassula soutient la réduction du périmètre PCI
La plateforme bancaire white-label de Crassula est conçue pour gérer les parties les plus sensibles de l'environnement de données de cartes, permettant aux clients de construire des produits de cartes et de paiements sans assumer la totalité de la charge de la propriété du CDE.
Données de cartes tokenisées
Les PAN émis sur la plateforme Crassula sont stockés et transmis sous forme tokenisée. Les applications clientes travaillent avec des tokens, pas avec des numéros de carte bruts, ce qui maintient la majorité des systèmes clients hors du périmètre PCI.
Données chiffrées au repos et en transit
Toutes les données des titulaires de cartes stockées sur l'infrastructure Crassula sont chiffrées avec AES-256. Toutes les communications inter-services utilisent TLS 1.3. La rotation des clés gérée par KMS est automatisée.
Segmentation réseau
Les workloads CDE s'exécutent dans des namespaces dédiés et renforcés avec des politiques d'entrée/sortie strictes. Les niveaux applicatifs non CDE sont séparés au niveau réseau et ne peuvent pas accéder aux stockages de données de cartes.
Journalisation prête pour l'audit
Tous les accès aux environnements de données des titulaires de cartes sont journalisés avec des traces inviolables conservées au moins 12 mois. Les clients reçoivent des exports de journaux pour leurs propres rapports de conformité.
Lorsque vous construisez un produit d'émission de cartes ou de paiement sur Crassula, vous héritez des contrôles de sécurité déjà intégrés dans la plateforme plutôt que de les implémenter de zéro. Cela réduit le périmètre de votre propre évaluation PCI aux points d'intégration entre votre application et les API Crassula. Pour les équipes lançant un premier programme de cartes en France, cette approche peut comprimer le délai jusqu'à la première évaluation PCI de 12-18 mois (en construisant votre propre CDE) à 3-6 mois. Contactez l'équipe Crassula pour une présentation technique de la frontière de responsabilité partagée et la documentation dont votre QSA aura besoin.
FAQ
PCI DSS (Payment Card Industry Data Security Standard) est un ensemble de contrôles de sécurité qui s'applique à toute organisation qui stocke, traite ou transmet des données de cartes de paiement, y compris les PAN, CVV, PIN et données de piste. Si votre fintech émet des cartes, traite des transactions par carte ou se trouve dans le chemin de données entre le titulaire de la carte et un réseau de cartes, PCI DSS vous est applicable. Cela comprend les émetteurs de cartes, les processeurs de paiement, les facilitateurs de paiement et les prestataires de services qui hébergent ou gèrent des données de cartes pour le compte de clients. Si vous ne faites que transmettre des données de cartes à un tiers entièrement conforme à PCI DSS et n'avez pas accès aux numéros de carte bruts, vous pouvez entrer dans une catégorie SAQ à périmètre réduit.
PCI DSS v4.0 (actuellement en v4.0.1, la version active) a apporté plusieurs changements significatifs par rapport à v3.2.1. Les plus importants pour les fintechs cloud-natifs sont : la MFA est désormais requise pour tous les accès au CDE, pas seulement pour les accès administratifs ; les scripts de pages de paiement doivent avoir des contrôles d'intégrité pour prévenir le skimming côté client (Exigence 6.4) ; l'"Approche personnalisée" permet aux organisations de satisfaire aux objectifs de sécurité par des contrôles adaptés à leur propre architecture ; la surveillance continue est explicitement requise au lieu de vérifications ponctuelles annuelles ; et les 64 nouvelles exigences introduites dans v4.0 sont devenues obligatoires le 31 mars 2025. Il n'y a pas de grandfathering : à partir de 2026, toutes les évaluations utilisent v4.0.1 comme référence.
La conformité PCI DSS en cloud commence par la compréhension du modèle de responsabilité partagée : votre fournisseur cloud gère la sécurité physique (et fournit un AoC pour le prouver), tandis que vous possédez tout à partir de la couche de virtualisation. Les étapes clés sont : définir précisément le périmètre CDE ; mettre en place la segmentation réseau pour isoler le CDE ; appliquer le chiffrement en transit avec TLS 1.3 et le mTLS entre les microservices ; gérer les clés de chiffrement dans un KMS cloud avec rotation automatique ; appliquer le RBAC à moindre privilège et la MFA pour tous les accès au CDE ; déployer la politique en tant que code (OPA, Kyverno) pour empêcher les configurations non conformes d'atteindre la production ; configurer un SIEM et une journalisation centralisée avec rétention de 12 mois ; et effectuer des analyses ASV trimestrielles et des tests d'intrusion annuels. En France, la superposition avec le RGPD signifie que les violations de données de cartes déclenchent également des obligations de notification à la CNIL dans les 72 heures.
La tokenisation remplace un PAN brut par un token de substitution sans relation mathématique avec l'original. Tout système qui ne voit que le token - votre CRM, plateforme d'analyse ou portail client - est hors périmètre PCI, à condition qu'il ne puisse pas appeler l'API de détokenisation ni accéder au coffre de clés. La segmentation réseau sépare les systèmes CDE des systèmes non CDE au niveau réseau via des pare-feux, des frontières VPC, des politiques réseau Kubernetes et des namespaces ou comptes dédiés. Les systèmes du côté non CDE ne peuvent pas initier de connexions vers le CDE et sont donc exclus de l'audit. Les deux techniques sont complémentaires : la tokenisation retire des éléments de données individuels du périmètre ; la segmentation retire des niveaux réseau entiers.
Un SAQ (Self-Assessment Questionnaire) est une autodéclaration attestant que votre environnement répond aux exigences PCI DSS. Il s'applique aux commerçants à faible volume et à certains prestataires de services, et est complété en interne (bien que les preuves doivent être conservées pour étayer la déclaration). Un ROC (Report on Compliance) est un audit indépendant réalisé par un QSA externe ou un ISA certifié. Il est obligatoire pour les entités de Niveau 1 et est de plus en plus exigé par les clients enterprise et les partenaires de réseaux de cartes comme condition pour faire des affaires. Le résultat d'une évaluation ROC est un rapport technique détaillé accompagné d'une Attestation de Conformité (AoC). Pour la plupart des fintechs qui gèrent directement des données de cartes, le chemin vers un ROC de prestataire de services de Niveau 1 est la destination finale, même si beaucoup commencent par un SAQ pendant qu'ils accumulent du volume. En France, l'ACPR peut demander des garanties de conformité PCI DSS dans le cadre de son contrôle des établissements de paiement agréés.
