Comment prouver à un auditeur que les scripts de vos pages de paiement n’ont pas changé

Le moment inconfortable d’une évaluation PCI DSS v4 n’est presque jamais la discussion de politique. C’est la question de relance. Vous expliquez vos contrôles de page de paiement, le QSA hoche la tête, puis demande : « Montrez-moi ce qui a changé sur votre checkout entre janvier et mars, et qui l’a approuvé. » Si votre réponse commence par « alors, normalement… », l’entretien vient de devenir une non-conformité.

Voici la version courte de ce qui fonctionne. Pour prouver que les scripts de vos pages de paiement n’ont pas changé (ou que chaque changement a été détecté et autorisé), les assesseurs attendent quatre artefacts : un inventaire de scripts par page de paiement avec une justification métier écrite pour chacun, la preuve que cet inventaire reflète la production actuelle, une preuve d’intégrité par script et un journal de changements couvrant la période évaluée avec au moins une alerte démontrant que la détection s’est réellement déclenchée. Les captures d’écran et les explications orales échouent parce qu’elles prouvent un instant. L’évaluation porte sur une période.

Ce que les QSA demandent vraiment pour 6.4.3 et 11.6.1

Nous avons passé assez d’entretiens côté marchand pour savoir que les demandes sont prévisibles. Pour la 6.4.3, l’assesseur veut l’inventaire, puis teste immédiatement s’il est vivant : il choisit un script, demande quand il est apparu, qui l’a justifié, s’il charge encore aujourd’hui. Pour la 11.6.1, les questions portent sur le mécanisme et sa production : qu’est-ce qui observe la page telle que le navigateur du consommateur la reçoit, à quelle fréquence, et, celle qui coule le plus d’évaluations, « montrez-moi une détection ». Un contrôle de détection de falsification au journal vide est indiscernable d’un contrôle qui ne fonctionne pas. Sur un vrai checkout, il y a toujours un pixel marketing qui arrive ou une version de CDN qui bouge. Si votre journal n’en montre aucun, l’assesseur en conclut que le journal est aveugle, pas que votre page est figée.

Une demande qui surprend souvent : le texte des justifications. Les assesseurs le lisent. « Nécessaire pour l’analytics » recopié par l’équipe sécurité sur quarante scripts se lit pour ce que c’est, un remplissage en masse. Une justification écrite par l’équipe propriétaire du script (« A/B test sur l’étape livraison, porté par growth, contrat renouvelé 2026-01 ») se lit comme de la gouvernance.

Pourquoi captures d’écran et explications orales échouent

Une capture de votre dashboard prouve l’état de la page le jour où vous l’avez prise. La période évaluée couvre en général l’année entière depuis la dernière évaluation. Entre ces deux faits se logent tous les incidents Magecart jamais documentés : le skimmer resté trois semaines sur un checkout et disparu avant que quiconque ne regarde. C’est exactement l’attaque que la 11.6.1 existe pour attraper, et un artefact ponctuel n’en dit rien.

Les explications orales échouent pour une raison voisine. Décrire le fonctionnement du reporting CSP ou de SRI montre à l’assesseur que le mécanisme pourrait détecter une falsification. Une preuve montre qu’il a détecté des changements, plusieurs fois, horodatés, sur toute la période. L’écart entre « pourrait » et « a fait » est l’endroit où naissent les non-conformités.

À quoi ressemble un dossier de preuves prêt pour l’audit

C’est ce que produit le module PCI DSS de CentralCSP, sur Scale (349,99 €/mois) et Enterprise. Les preuves se posent une à une sur les demandes ci-dessus.

Pour l’inventaire : vous déclarez quelles pages sont des pages de paiement, et le module construit pour chacune une liste de scripts depuis ce que les navigateurs des vrais consommateurs ont chargé, chaque entrée portant son origine, son URL et son hash d’intégrité SHA-256/384/512. Aucun agent sur la page, aucun crawler qui devine : la source de données, ce sont les navigateurs de vos clients, soit très exactement la formulation « tels que reçus par le navigateur du consommateur » de la 11.6.1. Chaque script porte son statut d’autorisation et la justification métier ou technique consignée en face : la question « qui a approuvé ça et pourquoi » devient un clic, pas une chasse aux emails. Des règles d’auto-validation évitent que les rotations de hash de routine ne repassent en file d’attente, si bien que cette file ne contient jamais que ce qu’une personne doit vraiment regarder.

Pour la période : une chronologie datée de chaque script ajouté, modifié ou retiré et de chaque nouvelle origine, exportable en CSV et en PDF, avec un SBOM des technologies du site à côté. Cet export est votre journal de changements pour l’évaluation, et l’historique de livraison des alertes qui l’accompagne (la règle « script non justifié sur une page de paiement », sur Slack, Teams, email ou webhook signé, avec un journal de livraison par canal) prouve que la détection se déclenche. Les règles s’évaluent à l’ingestion, confortablement au-delà du minimum de sept jours de la 11.6.1. Les rapports bruts vivent 90 jours, mais les justifications et le registre des changements sont conservés jusqu’à la suppression du compte : « montrez-moi mars » posé en novembre, c’est un export, pas de l’archéologie.

L’honnêteté impose une réserve, la même que dans chacun de nos articles PCI : l’acceptation des approches basées CSP pour la 11.6.1 varie selon les QSA, nous avons vu les deux. C’est précisément pourquoi le dossier de preuves compte plus que le mécanisme. Un assesseur sceptique sur l’en-tête cesse de l’être devant un inventaire daté, des justifications par script, des hashes et un trimestre d’historique. Personne ne discute avec un bon journal.

Préparer le dossier avant que l’auditeur ne le demande

Entre un entretien fluide et un entretien pénible, il y a en général une demi-journée de préparation :

1. Exportez les preuves avant le début de l’évaluation : inventaire par page de paiement, chronologie de changements, historique d’alertes. Arriver avec le dossier vaut mieux que le générer en séance.
2. Reliez chaque export à la ligne d’exigence qu’il couvre (inventaire et justifications pour 6.4.3, chronologie et alertes pour 11.6.1) dans une note de cadrage d’une page. Les assesseurs se souviennent des marchands qui font leur classement à leur place.
3. Faites écrire les justifications par le propriétaire du script, pas par l’équipe sécurité. Relancez les propriétaires des semaines à l’avance, c’est l’étape la plus lente.
4. Sortez une vraie détection de la période et soyez capable de la raconter : ce qui a changé, qui a été alerté, quelle décision a été prise.

Si votre organisation regarde aussi où vivent ces preuves : les rapports sont stockés et traités chez OVH, en France, sans jamais quitter l’UE, un point qui compte pour certains assesseurs et pour la plupart des DPO européens (nous avons traité l’angle résidence des données à part).

Les équipes qui passent ces entretiens sans douleur ne sont pas celles qui ont le mécanisme le plus malin. Ce sont celles qui savent répondre à « montrez-moi mars » en moins d’une minute.