veilletech.frCe qui se passe
PCI DSS 4.0 est sorti en 2022 avec 51 exigences étiquetées « bonnes pratiques ». Depuis le 31 mars 2025, elles sont notées comme les autres. La période de transition est close : une évaluation menée en 2026 les couvre toutes, et l'essentiel du poids nouveau se situe au niveau applicatif — précisément la partie du périmètre que les programmes de conformité n'avaient pas été conçus pour atteindre.
Le test tient en deux questions, que l'assesseur est désormais fondé à poser : quels scripts s'exécutent sur votre page de paiement, et comment sauriez-vous que l'un d'eux a changé ?
Les exigences qui touchent le code
Elles se concentrent dans deux des douze chapitres du standard.
Exigence 6 — développer et maintenir des logiciels sûrs
| Réf. | Ce qu'elle impose |
|---|---|
| 6.3.1 | Classer les vulnérabilités selon le contexte et l'impact réel, pas selon le score brut du scanner |
| 6.3.2 | Nouveau. Inventaire complet et à jour des applications, des API et de leurs composants tiers |
| 6.4.2 | Nouveau, remplace 6.4.1. La revue manuelle annuelle d'une application exposée n'est plus une option : il faut une protection automatisée continue |
| 6.4.3 | Nouveau. Inventaire de chaque script chargé dans le navigateur de l'acheteur, autorisé par écrit et vérifié en intégrité |
Exigence 11 — tester régulièrement
- 11.3.1.1 : on ne peut plus se contenter de fermer les vulnérabilités critiques et élevées ; tout ce qui reste ouvert exige une décision documentée et fondée sur le risque.
- 11.3.1.2 : le scan authentifié devient obligatoire. Un scan anonyme voit la porte d'entrée et manque le reste du bâtiment.
- 11.6.1 : nouveau, un mécanisme qui détecte et alerte sur toute modification non autorisée du contenu et des en-têtes HTTP des pages de paiement. C'est le pendant de 6.4.3 : l'une dit ce qui doit être là, l'autre attrape ce qui change.
Les API, elles, ne figurent dans presque aucun intitulé — c'est pourquoi on les oublie. Elles entrent dans la définition du logiciel sur mesure, donc la revue avant mise en production (6.2.3), la protection contre l'injection et l'abus de logique métier (6.2.4) et l'inventaire (6.3.2) s'y appliquent. Points d'accès non documentés, versions oubliées, intégrations partenaires : ils n'apparaissent nulle part avant que quelqu'un ne demande la liste.
Pourquoi ça compte
La menace visée est l'e-skimming, et elle est silencieuse par construction : le script malveillant tourne dans le navigateur de l'acheteur, capture le numéro et le cryptogramme à la frappe, et les envoie ailleurs. Les journaux du back-end restent propres, l'outillage antifraude ne voit rien, et le temps de présence moyen se compte en mois.
Le rapport 2024 de Recorded Future sur la fraude aux paiements relevait des infections d'e-skimmers sur près de 11 000 domaines de commerce en ligne — environ le triple de l'année précédente — et 269 millions d'enregistrements de cartes diffusés sur des sources ouvertes ou clandestines. Les campagnes Magecart étaient toujours actives en 2026.
Un piège de paperasse pour finir : le Conseil a bien retiré 6.4.3 et 11.6.1 du questionnaire d'auto-évaluation SAQ A, en les remplaçant par un critère d'éligibilité — vous confirmez que votre site n'est pas exposé aux attaques de scripts. Les exigences restent dans le standard complet. Et si votre tunnel de paiement passe par une iframe, c'est toujours vous qui servez la page qui charge les scripts : seule la déclaration a changé, pas le risque.
Source : Qualys, PCI DSS 4.0.1: Application Requirements You're Being Assessed On in 2026