PCI DSS (Payment Card Industry Data Security Standard) est la norme qui s'applique à toute organisation qui traite, stocke ou transmet des données de cartes bancaires. Version 4.0.1 (publiée juin 2024, applicable à tout audit après le 31 mars 2025) introduit des nouveautés non triviales par rapport à 3.2.1, notamment sur l'authentification, la sécurité des scripts e-commerce, et la posture continuous compliance. Voici ce qui change vraiment.
Rappel — les niveaux PCI DSS
Le périmètre dépend du volume de transactions annuelles :
- Level 1 : >6M transactions / an. Audit annuel par QSA (Qualified Security Assessor) externe.
- Level 2 : 1-6M transactions. Auto-évaluation SAQ + scan trimestriel ASV.
- Level 3 : 20k-1M transactions e-commerce. SAQ + scan ASV.
- Level 4 : <20k transactions e-commerce. SAQ.
Pour la plupart des SaaS B2B, vous êtes Level 2-4 et l'effort est gérable. Pour un éditeur orienté retail / e-commerce avec gros volumes, c'est Level 1 et l'audit QSA est lourd.
Ce qui change vraiment en 4.0.1
1. MFA étendu à tous les accès au CDE
CDE = Cardholder Data Environment. Dans 3.2.1, le MFA était requis pour les administrateurs et les accès distants. Dans 4.0.1, toute personne qui se connecte au CDE doit utiliser MFA, y compris les utilisateurs non-admin en accès local.
Conséquence pratique :
- Tous vos collaborateurs qui peuvent voir des données carte (support, ops, dev) doivent passer par MFA.
- Le MFA doit être phishing-resistant pour les accès admin (passkeys, FIDO2). Les push notifications classiques sont remises en question.
- Mise en place d'une session policy stricte : timeout court, ré-authentification périodique.
2. Sécurité des scripts e-commerce (req. 6.4.3 et 11.6.1)
Nouveauté majeure pour les sites e-commerce qui intègrent des scripts tiers (analytics, chatbots, payment widgets). Suite à des incidents Magecart répétés où les scripts JavaScript étaient compromis pour exfiltrer les données carte, PCI DSS 4.0.1 exige :
- Inventaire des scripts présents sur les pages de paiement, justification de chaque script.
- Intégrité : Subresource Integrity (SRI) hash, ou autre mécanisme équivalent.
- Monitoring : détection des modifications non autorisées des scripts en cours.
- Content Security Policy (CSP) stricte sur les pages de paiement.
C'est probablement la nouveauté la plus opérationnelle. Beaucoup de sites e-commerce ont des dizaines de scripts tiers chargés sur la page de paiement — chacun est un risque.
3. Authenticated scanning au lieu de simple network scan
Les scans ASV (Approved Scanning Vendor) trimestriels passent à un mode authenticated : le scanner se connecte avec un compte applicatif et explore les surfaces internes. Beaucoup plus profond, beaucoup plus de findings, mais aussi beaucoup plus utile.
4. Posture continuous compliance
Plusieurs requirements (4.x, 6.x, 11.x) demandent maintenant une démonstration de fonctionnement continu, pas juste un état à un instant T. Concrètement :
- Logs de monitoring activés et consultés régulièrement.
- Reviews d'accès trimestrielles (pas annuelles).
- Patches Critical sous 30 jours (était 90).
- Tests de pénétration annuels + après tout changement significatif.
C'est dans cet esprit que les outils de continuous compliance (SOC 2 Type II) commencent à intégrer aussi un mode PCI : Drata, Vanta, A-LIGN ASSURIST.
5. Customized approach (option flexible mais piégeuse)
PCI DSS 4.0 introduit la possibilité de "customized approach" pour certains contrôles : au lieu d'appliquer la prescription textuelle, vous pouvez démontrer que votre approche atteint l'objectif équivalent.
Cette flexibilité est intéressante pour les architectures cloud-native modernes mais demande une documentation très solide et un QSA expérimenté. À ne pas tenter sans accompagnement.
La timeline 2024-2026
- Mars 2024 : v4.0 obligatoire, fin de v3.2.1.
- Juin 2024 : v4.0.1 publiée (corrections mineures de v4.0).
- 31 mars 2025 : tous les nouveaux requirements de v4.x sont obligatoires (avant cette date, certains étaient "best practice" optionnels).
- 2026 : c'est l'année où les premiers audits "full v4.0.1" tournent. Les findings sont nombreux pour les organisations qui ont sous-estimé.
L'erreur classique 2026 : "on était PCI 3.2.1, on l'est encore"
Faux. Les organisations qui ont reconduit leur certification 3.2.1 en mars 2024 ou avant ont valable jusqu'à leur prochain renouvellement. À ce renouvellement, il faut être conforme à 4.0.1, ce qui demande des chantiers significatifs.
Démarrage typique 2026 :
- Diagnostic 4.0.1 : où en êtes-vous par rapport à la nouvelle version (3-4 semaines).
- Roadmap : prioriser les chantiers selon le calendrier de renouvellement.
- Mise en œuvre : MFA étendu, SRI sur les scripts e-commerce, outillage continuous compliance, etc.
- Pré-audit : validation que vous êtes prêt avant l'audit officiel.
- Audit : QSA pour Level 1, SAQ + ASV pour les autres.
Articulation avec les autres normes
- SOC 2 Type II : recoupement fort, surtout sur la partie sécurité opérationnelle. Une organisation SOC 2 a 50-60% du chemin PCI fait.
- ISO 27001 : recoupement plus large, gain de 40-50%.
- CRA : pour les éditeurs de produits logiciels payment, recoupement avec les obligations CRA — un audit CRA et un audit PCI peuvent partager 60% des contrôles.
- AI Act : si vous utilisez l'IA pour la détection de fraude (cas fréquent), des exigences AI Act s'ajoutent (système haut risque catégorie crédit/finance).
Pour démarrer
Si votre organisation traite des paiements en 2026, la question n'est pas "faut-il être PCI" mais "où en sommes-nous sur 4.0.1". Les conséquences d'une non-conformité ne sont pas que théoriques : amendes Visa/Mastercard, perte du droit de traiter, sans parler de l'impact d'un breach évitable.
L'aspect le plus sous-estimé en 2026 reste la sécurité des scripts e-commerce. C'est aussi celui où les missions chez WeeSec ont le plus d'impact rapide — instrumentation, CSP stricte, monitoring runtime.
