Une CMP installée trop tard ne peut pas corriger ce qui s’est déjà produit.
Cette phrase résume probablement l’une des erreurs les plus fréquentes dans les intégrations de gestion du consentement.
Le bandeau peut apparaître immédiatement. Le bouton "Refuser" peut fonctionner parfaitement. La configuration peut sembler correcte. Mais si Google Analytics ou un autre service a déjà envoyé une requête avant que la CMP puisse intervenir, cette première collecte a déjà eu lieu.
Le navigateur exécute la page dans un ordre
Lorsqu’un navigateur reçoit un document HTML, il commence à le lire et à traiter les ressources qu’il rencontre.
Il découvre des feuilles de style, des scripts, des images, des iframes et différentes ressources externes.
Un script tiers rencontré suffisamment tôt peut donc être téléchargé puis exécuté alors que la suite du document n’a pas encore été traitée.
La CMP n’existe pas encore du point de vue de la page si son propre script arrive plus loin.
Une requête réseau est irréversible
Imaginons une page qui charge directement Google Analytics avant tarteaucitron.
Le navigateur télécharge le script Google. Celui-ci s’exécute et peut effectuer ses propres requêtes.
Quelques millisecondes plus tard, tarteaucitron se charge et affiche le bandeau.
À cet instant, la CMP peut éventuellement empêcher de futures actions, mais elle ne peut pas rappeler les paquets réseau déjà envoyés vers un serveur externe.
Il n’existe pas de fonction JavaScript permettant de dire au navigateur : "annule ce qui a été transmis il y a 100 millisecondes".
Supprimer ensuite le script ne change rien
Il est également possible de supprimer un élément <script> du DOM après son apparition.
Cela ne signifie pas que son exécution passée est annulée.
Une fois le JavaScript téléchargé et exécuté, retirer sa balise revient un peu à jeter une enveloppe après avoir déjà envoyé la lettre.
Cette distinction est importante pour comprendre pourquoi la détection automatique doit intervenir suffisamment tôt.
Le problème existe aussi avec les iframes
Une iframe YouTube ou Google Maps directement présente dans le HTML peut commencer à charger son contenu dès que le navigateur la rencontre.
Remplacer ensuite cette iframe par un placeholder ne permet pas d’annuler les requêtes qui ont déjà été effectuées.
Pour réellement conditionner son chargement, il faut empêcher la ressource externe d’être demandée avant le choix du visiteur.
C’est le principe utilisé par tarteaucitron lorsqu’un contenu externe est correctement intégré.
Le mode manuel règle le problème à la source
Avec tarteaucitron open source en mode manuel, l’approche est assez facile à comprendre.
La balise directe du service est retirée du site. Le service est ensuite déclaré dans tarteaucitron.
Google Analytics, par exemple, n’existe donc plus comme script indépendant chargé directement par le template. C’est tarteaucitron qui décide quand son intégration doit être exécutée.
Il n’y a plus besoin d’intercepter un script déjà présent puisqu’il n’est simplement pas ajouté avant l’autorisation.
La détection automatique doit intervenir avant le service
Avec tarteaucitron Pro, le principe est différent puisque l’objectif est justement de pouvoir conserver de nombreuses intégrations existantes.
Le script Pro doit alors être chargé très tôt afin de détecter les éléments supportés avant leur exécution effective.
C’est pourquoi le marqueur doit être placé aussi haut que possible dans le <head>, avant les services qu’il doit contrôler.
La détection automatique n’est pas une machine à remonter le temps. Elle fonctionne parce qu’elle arrive avant ce qu’elle doit détecter.
async peut rendre l’ordre imprévisible
L’attribut async demande au navigateur de télécharger un script sans bloquer l’analyse du document puis de l’exécuter dès qu’il est disponible.
Deux scripts async ne conservent donc pas nécessairement leur ordre d’apparition dans le HTML.
Si une CMP et un tracker sont tous les deux chargés de cette manière, le simple fait de placer visuellement la CMP avant le tracker dans le code ne garantit plus qu’elle s’exécutera la première.
Pour le script principal de tarteaucitron, ajouter arbitrairement async ou defer peut donc casser le comportement attendu.
defer change lui aussi le moment d’exécution
defer conserve mieux l’ordre relatif entre les scripts concernés, mais repousse leur exécution après l’analyse du document HTML.
Ce comportement peut être utile pour de nombreux scripts classiques destinés à améliorer le chargement d’une page.
Il est beaucoup moins logique pour un script dont le rôle est précisément d’intervenir le plus tôt possible sur d’autres éléments.
Optimiser quelques millisecondes de chargement ne doit pas déplacer la CMP après les services qu’elle est censée contrôler.
Google Tag Manager ajoute un niveau supplémentaire
GTM peut lui-même charger de nombreux services.
Si la CMP est chargée après le conteneur, des balises configurées dans GTM peuvent avoir eu le temps de se déclencher avant son intervention.
Je préfère donc une architecture simple : la CMP en premier, puis les gestionnaires de balises et services qu’elle doit contrôler.
J’ai détaillé ce cas dans mon article sur GTM et le consentement en cascade.
Le bandeau visible ne donne aucune indication sur l’ordre réel
C’est probablement ce qui rend l’erreur trompeuse.
Un bandeau peut apparaître presque instantanément alors qu’une requête analytique est partie quelques millisecondes auparavant.
À l’œil nu, les deux événements semblent simultanés.
Le seul moyen fiable de vérifier l’ordre consiste à regarder les requêtes réseau et l’exécution réelle avec les outils du navigateur.
La méthode est détaillée dans mon guide de test d’une CMP avec les DevTools.
Le cache ne change pas le principe
Le fait qu’un script tiers soit déjà présent dans le cache du navigateur ne résout pas le problème.
Même lorsqu’une ressource JavaScript n’a pas besoin d’être téléchargée à nouveau depuis le réseau, son exécution peut provoquer de nouvelles requêtes et traitements.
Le sujet n’est donc pas seulement le téléchargement du fichier JavaScript lui-même, mais tout ce que son exécution déclenche ensuite.
Les scripts injectés dynamiquement doivent aussi être contrôlés
Tous les services ne sont pas présents directement dans le HTML initial.
Un plugin, un gestionnaire de balises ou un autre JavaScript peut créer dynamiquement une balise <script> ou une iframe après le chargement.
Une détection automatique peut justement observer ce type de comportement, à condition d’être déjà active lorsque l’élément est créé.
Là encore, le timing est la clé.
Pourquoi ne pas simplement charger la CMP absolument en premier ?
Dans la pratique, quelques éléments techniques peuvent naturellement précéder la CMP : métadonnées, styles ou scripts internes indispensables selon l’architecture du site.
La règle importante n’est pas de gagner une compétition pour être le premier octet JavaScript de la page.
La CMP doit surtout être active avant les services tiers qu’elle a pour mission de contrôler.
C’est cette relation d’ordre qui compte.
Le bon ordre simplifie toute l’architecture
Plus l’ordre de chargement est clair, moins il faut construire de mécanismes compliqués pour rattraper ensuite les services.
Dans une architecture simple, la CMP prend sa place tôt, connaît les choix du visiteur puis autorise ou bloque les éléments concernés.
Les services tiers arrivent ensuite.
Cette organisation est beaucoup plus robuste qu’un système dans lequel tous les trackers sont chargés librement puis où l’on essaie de les neutraliser après coup.
Une règle simple à retenir
Pour chaque service nécessitant un consentement, il suffit finalement de poser une question : qui s’exécute en premier ?
Si le service tiers peut fonctionner avant que le mécanisme de consentement soit capable de le contrôler, l’intégration est fragile ou incorrecte.
Si la CMP contrôle le point à partir duquel ce service peut être chargé, le fonctionnement devient beaucoup plus prévisible.
Le consentement doit être préalable. Techniquement, cela implique que le mécanisme chargé de le faire respecter soit lui aussi en place suffisamment tôt.
