# Peut-on garder un tag manager sur une page de paiement avec PCI DSS 6.4.3 ?

> Un tag manager est un script autorisé qui en charge d'autres que vous n'avez jamais approuvés, précisément ce que 6.4.3 demande de maîtriser. Ce qu'attend un évaluateur, pourquoi un crawl ne produit pas l'inventaire, et comment gérer la rotation de hash du conteneur.

- Canonical: https://info.centralcsp.com/fr/articles/pci-dss-payment-page-tag-manager/
- Published: 2026-09-21
- Language: fr
- Publisher: CentralCSP (https://centralcsp.com)

L'exigence 6.4.3 demande trois choses de chaque script d'une page de paiement : qu'il soit autorisé, que son intégrité soit assurée, et qu'un inventaire existe avec une justification écrite de sa présence. 6.4.3 et 11.6.1 sont obligatoires en évaluation depuis le 31 mars 2025.

Un tag manager est un script autorisé unique dont le métier entier consiste à charger des scripts que vous n'avez pas approuvés individuellement, modifiés par une équipe qui ne déploie pas de code, sans passer par une revue. Ce n'est pas qu'un tag manager soit dangereux. C'est que le mécanisme qu'il offre est exactement celui que 6.4.3 est écrite pour encadrer.

Réponse courte, donc : vous pouvez le garder, mais le conteneur n'est pas l'unité d'autorisation, et inscrire `gtm.js` dans votre inventaire ne satisfait rien. Il faut inventorier les tags qu'il charge, dans l'environnement où il les charge, et justifier chacun. La plupart des équipes qui chiffrent l'opération finissent par sortir le tag manager de la page de paiement, et elles ont raison.

## Pourquoi « le conteneur est un script approuvé » ne passe pas une évaluation

Mettons l'exigence en face de ce que fait un conteneur.

| Ce que demande 6.4.3 | Ce que donne un tag manager |
| --- | --- |
| Chaque script est autorisé | Une autorisation couvrant un ensemble ouvert et mouvant |
| L'intégrité de chaque script est assurée | Un chargeur dont la charge utile change sans préavis |
| Une justification écrite par script | Une justification du mécanisme de chargement |
| Un inventaire tenu à jour | Un inventaire à jour jusqu'à la prochaine publication marketing |

Le point fatal est en bas de la deuxième colonne. La justification que vous avez rédigée dit « nous utilisons un tag manager pour gérer les tags marketing ». Elle ne dit pas pourquoi un prestataire d'enregistrement de session accède au DOM de la page où l'on saisit un numéro de carte, ce qui est la vraie question de l'évaluateur, et celle qui compte indépendamment de l'évaluation.

Un second problème n'a rien à voir avec la conformité. Publier un conteneur, c'est faire une modification de production sur votre page de paiement, par quelqu'un dont l'objectif est le taux de conversion, en général sans revue de code, sans préproduction et sans discussion de retour arrière. Les opérateurs Magecart le savent, et le tag manager est une voie connue vers les pages de paiement précisément parce que c'est le seul endroit où un changement est banal.

## Un crawl ne produit pas cet inventaire

Le réflexe consiste à ouvrir la page de paiement, regarder l'onglet réseau, noter ce qui s'est chargé, et appeler cela l'inventaire.

Cela en rate l'essentiel, parce que les tags se déclenchent sous condition. Les déclencheurs dépendent du chemin de la page, du montant du panier, du consentement accordé et de sa catégorie, de la géographie, de l'affectation à un test A/B, de l'état de connexion. Une visite synthétique depuis un datacenter d'un seul pays, sans état de consentement et avec un panier vide, n'exerce qu'une fraction du conteneur. Les tags qui ne se déclenchent que pour de vrais clients dans le tunnel d'achat sont ceux qui se tiennent le plus près du formulaire de carte.

Les skimmers exploitent exactement cela. Les charges dissimulées vérifient la présence d'une session réelle, d'un panier rempli ou d'un navigateur non automatisé avant d'agir, justement pour qu'un scan ne les voie pas.

L'inventaire doit donc venir de sessions réelles. Le mécanisme est le rapport de hash CSP : ajouter `'report-sha256'` à la politique fait remonter par le navigateur chaque script réellement exécuté avec son SHA-256, depuis les visiteurs qui l'ont déclenché. Aucun agent sur la page, aucun crawler, aucun JavaScript de prestataire ajouté à une page dont vous cherchez justement à défendre le nombre de scripts. Les scripts de première, tierce et quatrième partie apparaissent tous, y compris ceux qu'un tag a chargés parce qu'un autre tag l'avait chargé. Le mécanisme général est détaillé dans [construire un inventaire de scripts sans agent](/fr/articles/script-inventory-without-an-agent/).

## Le problème de la rotation de hash, celui qui fait abandonner

C'est ce qui coule les tentatives maison. Les scripts de conteneur changent en permanence. Chaque publication régénère le conteneur, et l'éditeur met à jour le loader hébergé à son propre rythme. Si votre inventaire traite un nouveau hash comme un changement à examiner, votre journal se remplit d'une douzaine d'entrées par semaine qui signifient toutes « le marketing a republié », et au bout d'un mois plus personne ne le lit.

Puis un vrai changement arrive et atterrit dans le même tas.

La sortie passe par des règles de validation qui distinguent un script connu qui tourne d'un script réellement nouveau qui apparaît. Dans le module PCI DSS de CentralCSP, un script porte une justification et un jeu de règles d'auto-validation pour ses motifs connus : une rotation de conteneur de routine est consignée dans la chronologie sans repasser par la file d'attente, tandis que tout ce qui n'a pas de justification correspondante y va et déclenche une alerte. La distinction se fait entre « ce fichier a changé comme toujours » et « quelque chose qui n'a jamais été autorisé s'exécute désormais sur la page ».

Ce module produit aussi les pièces qu'un évaluateur réclame : une chronologie datée par page de paiement (script ajouté, modifié, retiré, nouvelle origine), le texte de justification par script avec son auteur et sa date, et un export de preuves en CSV et PDF accompagné d'un SBOM des technologies de la page. Les enregistrements de conformité sont conservés jusqu'à la suppression du compte, ce qui compte puisque les rapports bruts du navigateur sont retenus 90 jours et qu'une fenêtre d'évaluation est plus longue.

Le module PCI DSS est sur l'offre Scale (349,99 €/mois) et Enterprise. L'inventaire de scripts qui l'alimente est présent sur toutes les offres, Start comprise.

## La 11.6.1 et le plancher des sept jours

La 11.6.1 est la moitié détection : il faut détecter les modifications non autorisées des en-têtes HTTP et du contenu des pages de paiement, avec une évaluation au moins tous les sept jours.

Sept jours est un plancher, pas un objectif. Un skimmer qui moissonne pendant six jours avant d'être repéré a moissonné pendant six jours. La détection pilotée par les rapports est continue plutôt que planifiée, puisque l'évaluation se fait à l'arrivée d'un rapport de navigateur, et les règles d'alerte de CentralCSP sont évaluées à l'ingestion et non par une tâche planifiée. Les règles utiles ici sont l'apparition d'un script non justifié sur une page de paiement et l'apparition d'une nouvelle origine, routées vers six canaux au choix (Slack, Teams, Google Chat, Telegram, e-mail, webhooks signés) avec un délai de garde pour qu'un mauvais déploiement ne produise pas quatre cents messages. L'alerting démarre sur Business (129,99 €/mois).

Les en-têtes comptent aussi. La 11.6.1 les nomme explicitement, et une CSP discrètement supprimée par un changement de proxy est une modification non autorisée de la posture de la page qu'aucun inventaire de scripts ne montrera.

## Ce que nous ferions

Par ordre de conviction :

1. **Sortir le tag manager de la page de paiement.** Le garder partout ailleurs. La page de paiement reçoit une liste courte de scripts, tenue à la main, chacun avec un nom de responsable. Le suivi de conversion y survit en général, puisque l'événement d'achat peut partir côté serveur ou sur la page de confirmation, qui n'est pas celle où l'on saisit la carte. C'est l'option qui rend 6.4.3 simple au lieu de permanente.
2. **S'il reste, faire des tags l'inventaire.** Énumérer ce qui se déclenche réellement dans le tunnel d'achat depuis du trafic réel, justifier chaque élément, et faire entrer le conteneur dans un processus de changement qui vous prévient au minimum. Une publication sur le conteneur du paiement devrait réveiller quelqu'un, pas simplement apparaître dans un historique que personne ne lit.
3. **Retirer au conteneur sa capacité à injecter du code arbitraire.** Les tag managers peuvent injecter du HTML personnalisé et du JavaScript inline. Restreindre les droits de publication et désactiver les tags HTML personnalisés sur le conteneur du paiement supprime le pire scénario, celui d'un attaquant disposant des identifiants du tag manager plutôt que d'un accès serveur.
4. **Surveiller ce qui s'exécute, en continu.** Quelle que soit l'option retenue, la page doit rapporter ce qui s'est exécuté et alerter sur tout ce qui n'est pas justifié. C'est le contrôle autour duquel tournent 6.4.3 et 11.6.1.

Une remarque sur la CSP elle-même. Un tag manager et une politique stricte se combattent : les tags HTML personnalisés réclament de l'exécution inline, alors les équipes ajoutent `'unsafe-inline'` et défont la politique pour que le conteneur continue de fonctionner. Si le conteneur reste, il lui faut une propagation de nonce plutôt qu'une exception générale, et c'est en général le moment où quelqu'un recalcule le coût de l'option un.

Le détail exigence par exigence se trouve dans [PCI DSS 6.4.3 et 11.6.1 pour les pages de paiement](/fr/articles/pci-dss-6-4-3-and-11-6-1-payment-page-requirements/), et le volet preuves dans [prouver que vos scripts de paiement n'ont pas changé](/fr/articles/prove-payment-scripts-unchanged/). CentralCSP produit les preuves pour une évaluation. Il ne certifie pas la conformité, et quiconque prétend le contraire vous vend quelque chose.

## Questions fréquentes

### PCI DSS interdit-il un tag manager sur une page de paiement ?

Le texte ne mentionne pas les tag managers. L'exigence 6.4.3 demande que chaque script soit autorisé, que son intégrité soit assurée, et qu'un inventaire soit tenu avec une justification métier ou technique écrite. Un script conteneur ne remplit rien de tout cela pour les tags qu'il charge, donc le conteneur n'est pas l'unité de contrôle. Vous pouvez le garder à condition d'inventorier et de justifier ce qu'il charge réellement, ce qui représente plus de travail que de le sortir de la page.

### Puis-je déclarer le tag manager comme un seul script autorisé ?

Les évaluateurs que nous avons croisés ne l'acceptent pas, et le raisonnement est difficile à contester : ce que vous avez autorisé peut charger autre chose demain, sans déploiement, sans revue de code et sans ticket. Autoriser le conteneur revient à autoriser un mécanisme, pas un script. L'inventaire doit descendre jusqu'aux tags.

### Pourquoi le hash du conteneur change-t-il tous les jours ?

Les conteneurs sont régénérés à chaque publication, et le loader hébergé est mis à jour par l'éditeur à son propre rythme. Un inventaire naïf traite chaque régénération comme un changement à examiner et enterre les vrais. Il faut des règles de validation qui reconnaissent la rotation de routine d'un script connu et ne mettent un changement en file d'attente que si les tags chargés diffèrent.

### La 11.6.1 s'applique-t-elle si ma page de paiement est une iframe hébergée ?

La page parente compte toujours. Si votre page encadre un prestataire de paiement, la page encadrante peut être modifiée pour superposer ou remplacer cette iframe, et c'est pourquoi l'éligibilité au SAQ A, depuis la révision de 2025, repose sur l'exposition aux attaques par script plutôt que sur le fait de toucher directement aux données de carte. Surveillez la page qui porte l'iframe.