PCI-DSS — Analyse de scope

Statut : draft / analyse préliminaire. Cette page détermine si le périmètre Nex actuel est soumis à la norme PCI-DSS (Payment Card Industry Data Security Standard) et, le cas échéant, dans quelle mesure.

1. Rappel — PCI-DSS

PCI-DSS est une norme de sécurité éditée par le PCI Security Standards Council (Visa, MasterCard, AmEx, Discover, JCB). Elle s'applique à toute entité qui stocke, traite ou transmet des données de titulaires de cartes (CHD — Cardholder Data).

Catégories de données

Type	Définition	PCI-DSS scope ?
PAN (Primary Account Number)	Numéro de carte	✅ Oui
Cardholder name	Nom du titulaire	✅ Oui (si stocké avec PAN)
Expiration date	Date d'expiration	✅ Oui (si stocké avec PAN)
Service code	Code de service de la piste	✅ Oui (si stocké avec PAN)
CVV / CVC / CID	Code de validation au verso	❌ Stockage interdit (même chiffré)
Full track data	Données complètes des pistes magnétiques	❌ Stockage interdit
PIN block	PIN chiffré utilisé en transit	❌ Stockage interdit

2. Périmètre Nex actuel

Surface	Données carte présentes ?	Statut
Apps mobiles (Nex, Nex Pro, Nex Business)	❌ Aucune saisie de PAN	Hors scope
Backend microservices (auth, ledger, etc.)	❌ Pas de PAN dans la DB	Hors scope
ledger-wallets — cards (Card entity)	⚠️ La table cards stocke un card_number 8 caractères qui est un identifiant interne de carte physique merchant (cf. ADR-0005), PAS un PAN ISO 13.4 (qui fait 16 chiffres).	Hors scope PCI-DSS
service-catalog — payment-methods	Référence aux moyens de paiement (Mobile Money, comptes bancaires), pas de PAN	Hors scope
Providers Mobile Money	Pas de carte	Hors scope

3. Conclusion préliminaire

Le périmètre Nex V1 est hors scope PCI-DSS car aucune donnée de titulaire de carte au sens PCI (PAN, CVV…) n'est stockée, traitée ou transmise par la plateforme.

La carte merchant 8 caractères est un identifiant interne (similaire à un code-barre ou un numéro de fidélité), non un numéro de carte bancaire.

4. Scénarios où PCI-DSS deviendrait applicable

À l'avenir, si l'un de ces scénarios se concrétise, une nouvelle analyse de scope sera requise et un programme PCI-DSS devra être lancé.

Scénario	Conséquence
Acceptation de cartes Visa/MasterCard côté consumer (paiement par carte d'un consumer vers son wallet)	Scope CDE défini autour des composants traitant le PAN
Émission de cartes physiques de paiement (Visa/MasterCard) liées au wallet	Scope CDE complet + cardholder data lifecycle
Intégration 3D Secure	Scope étendu
Stockage du PAN même tokenisé	Scope étendu

5. Recommandation

• Maintenir cette analyse de scope à jour : revoir à chaque évolution majeure du produit qui touche aux moyens de paiement.
• Avant tout projet d'acceptation carte : engager un QSA (Qualified Security Assessor) pour valider le scope cible.
• Tokenisation systématique si scope card activé : utiliser un PSP certifié PCI-DSS Level 1 (Stripe, Adyen, Mangopay…) pour ne jamais voir le PAN.
• Segmenter réseau et services pour limiter le CDE.

6. Si PCI-DSS devient applicable — structure cible

Document à produire à ce moment-là :

• Scope diagram : composants in-scope / out-of-scope.
• Data Flow Diagram CDE (obligatoire Req 1.2.4) : flux de PAN.
• Network segmentation evidence : isolation du CDE.
• Annual ROC (Report on Compliance) ou SAQ (Self-Assessment Questionnaire) selon le niveau (1 à 4).
• Quarterly ASV scans : Approved Scanning Vendor scans externes.
• Annual pentest sur le CDE.
• PA-DSS si Nex développe une application de paiement.

7. Pour aller plus loin

• PCI-DSS v4.0 : standard actuel (depuis 2022, période de transition jusqu'en 2025).
• PCI Security Standards Council : https://www.pcisecuritystandards.org/
• ANSSI : guide bonnes pratiques pour les opérateurs CB en France (utile en complément).

8. Suivi

Évaluation	Date	Résultat
V1 initiale	2026-05-21	Hors scope PCI-DSS
Prochaine évaluation	À tout changement majeur ou annuel	—