Bandeau cookies conforme : bloque-t-il vraiment les scripts non essentiels ? 7 erreurs courantes

Le bouton « Tout refuser » ne prouve pas que le suivi s’arrête. Un guide pratique pour tester un bandeau avec Network, Application, le mode Consentement et des vérifications répétées.

Vous ouvrez un site dans un nouveau profil de navigateur, cliquez sur « Tout refuser » et voyez disparaître l’avis relatif aux cookies ; en apparence, tout est en ordre. Pourtant, c’est précisément à ce moment que commence la vérification d’un bandeau cookies conforme : une requête avait-elle déjà été envoyée à une plateforme publicitaire avant le clic, la réponse avait-elle tenté de définir un identifiant resté dans le stockage du navigateur, et les balises ont-elles reçu le bon état de consentement après le refus ? Le bouton n’est qu’un tableau de commande, et l’audit doit vérifier si les câbles sont réellement raccordés derrière lui, car la CMP peut ne pas avoir encore défini l’état par défaut lorsque le gestionnaire de balises exécute déjà sa première règle.

L’examen visuel du bandeau ou la coche verte d’un scanner automatique ne dit pas ce qui s’est passé pendant les premières secondes du chargement. Il ne révèle pas non plus quel script a déclenché l’action, quel état de consentement lui était accessible à cet instant ni si l’état final visible reflète toute la séquence des événements antérieurs. Nous comparons donc, sur une même chronologie, le comportement du site avant tout choix, après le refus de toutes les catégories non essentielles, après leur acceptation puis après le retrait ultérieur du consentement. Dans chaque état, nous évaluons les requêtes réseau, les en-têtes de réponse, les cookies, localStorage et les autres stockages, l’ordre des signaux de consentement et l’initiateur précis de l’action. Seule cette comparaison distingue une configuration correcte d’un bandeau qui se contente de se fermer.

Cet article est technique ; il ne constitue pas un avis juridique individuel. Il montre comment recueillir des faits vérifiables sans en tirer des conclusions que les preuves ne permettent pas. Si le site utilise Google Tag Manager, Google Analytics 4, Google Ads, Meta Pixel, une vidéo intégrée, un module de chat ou d’autres outils tiers, la liste de cookies visible sur un seul écran ne représentera qu’une partie de la situation. La vraie question n’est donc pas « le bandeau est-il installé ? », mais « que fait le site à chaque étape du choix de l’utilisateur ? ».

Bandeau cookies conforme : ce que l’audit vérifie — et ce qu’il ne prouve pas

L’audit examine la chaîne technique du consentement, depuis la première requête de la page jusqu’au changement d’état consécutif au choix de l’utilisateur. Cette chaîne ne peut pas être évaluée à partir du seul état final, car la séquence de chargement initiale peut avoir déjà déclenché une action que la fermeture ultérieure du bandeau n’annule pas. Le périmètre couvre l’ordre de chargement des scripts, les connexions réseau, les cookies et les autres stockages, les signaux de la plateforme de gestion du consentement (CMP), la configuration du mode Consentement de Google, le comportement des catégories et la possibilité de modifier son choix par la suite. Le résultat est un ensemble de preuves techniques concernant les cookies et le suivi, pas un certificat attestant que tous les traitements de données à caractère personnel de l’organisation sont juridiquement irréprochables.

En France, il faut distinguer deux niveaux liés entre eux. L’article 82 de la loi Informatique et Libertés, qui transpose l’article 5, paragraphe 3, de la directive ePrivacy, encadre le stockage d’informations dans le terminal de l’utilisateur et l’accès à celles qui y sont déjà conservées ; ce périmètre technique ne se limite pas aux fichiers dont le nom contient « cookie ». Le RGPD devient pertinent lorsque des données à caractère personnel sont traitées et fixe également les conditions d’un consentement valable ainsi que les principes de son retrait. Un contrôle technique relevant d’un régime ne remplace donc pas l’analyse juridique de l’autre. Dans le rapport d’audit, nous nommons séparément ces deux niveaux afin qu’un fait technique observé ne soit pas présenté comme une conclusion juridique plus large.

La CNIL rappelle que l’activation d’outils non essentiels avant le choix et un mécanisme de refus inopérant ne permettent pas de recueillir un consentement libre. L’étiquette « nécessaire » attribuée à une catégorie ne prouve toutefois rien à elle seule. L’exception strictement nécessaire doit être appréciée de manière restrictive : l’opération concernée doit soit avoir pour finalité exclusive de permettre ou faciliter la communication par voie électronique, soit être strictement nécessaire à la fourniture d’un service de communication en ligne à la demande expresse de l’utilisateur, et non simplement utile à la mesure d’audience, au marketing ou aux besoins internes de l’éditeur. L’auditeur doit relier cette opération à la fonction qui la rend nécessaire, tout en vérifiant que la même catégorie ne dissimule pas une finalité distincte que la fonction demandée ne saurait justifier.

Dans ce service, la requête « audit RGPD d’un site web » désigne uniquement le périmètre des cookies, du suivi et de la gestion du consentement. Elle exclut les bases juridiques des autres traitements, les demandes des personnes concernées, les contrats et la gouvernance interne. Notre service d’audit des cookies et du suivi fournit les faits techniques sur lesquels un juriste ou un délégué à la protection des données peut fonder l’évaluation de cette partie du site. La conformité au RGPD n’est cependant pas un interrupteur unique qu’un scanner technique pourrait actionner pour toute une organisation. Cette limite n’est pas une manière d’éluder la responsabilité : elle indique clairement ce que le rapport prouve et les questions qui restent à trancher en dehors de l’audit technique.

Comment l’audit réunit des preuves, pas seulement le résultat d’un scanner

Un test solide commence dans un profil de navigateur vierge, sans choix de consentement déjà enregistré, sans cookie du site ni requête créée par une extension. Avant tout clic, le journal Network est activé, le panneau Application est contrôlé et l’état initial est consigné. La même suite d’actions est ensuite répétée après le refus, après le consentement puis après son retrait, chaque scénario partant d’un état documenté et conservant l’intégralité du journal. À défaut, le choix d’hier peut passer pour une défaillance du bandeau d’aujourd’hui ou, au contraire, masquer la véritable erreur.

Une entrée Network prouve que le navigateur a tenté de joindre une adresse précise et permet d’examiner l’initiateur, le statut, les en-têtes de la requête et de la réponse ainsi que les informations envoyées ; elle ne prouve pas encore qu’un cookie a été stocké. L’en-tête de réponse Set-Cookie indique que le serveur a essayé d’en définir un, mais le navigateur peut bloquer cette tentative, tandis que JavaScript peut écrire dans document.cookie ou localStorage sans cet en-tête. Le résultat effectif doit donc être contrôlé dans le panneau Application, aucun indice ne pouvant se substituer aux autres. Une requête visible vers un domaine de mesure d’audience atteste une tentative de flux de données, pas nécessairement la création réussie d’un cookie de mesure ni la réception par le serveur d’un ensemble précis de données à caractère personnel.

Pour chaque constat, nous consignons l’URL et le parcours testés, l’heure, le contexte de l’appareil et du navigateur, l’état de consentement choisi, l’initiateur et la destination de la requête, le résultat de l’envoi et les changements de stockage. Après correction, il devient ainsi possible de reproduire exactement le même test. L’analyse automatique fournit un large inventaire de départ, mais elle ne parcourt pas tous les menus, toutes les étapes d’achat, les espaces connectés, les versions linguistiques ni les intégrations ouvertes dynamiquement, et elle ne peut pas déterminer de façon fiable une finalité à partir du seul nom d’un fichier ou d’un domaine. Elle est donc suivie de scénarios manuels et d’un échange avec les responsables des outils. Nous établissons qui a introduit l’outil, dans quel but, dans quel conteneur de balises il réside et à quel signal de consentement il doit obéir, afin de relier le constat technique à la configuration attendue. Une preuve sans contexte n’est qu’une capture d’écran ; un contexte sans preuve n’est qu’une promesse.

1. Les scripts non essentiels sont exécutés avant le choix de l’utilisateur

Une erreur critique de séquencement se produit lorsque le bandeau de la CMP s’affiche rapidement, mais qu’une balise de mesure d’audience ou de publicité s’est déjà déclenchée : l’utilisateur lit encore le texte des boutons alors que son navigateur a contacté un tiers ou enregistré un identifiant. La position de la CNIL est sans ambiguïté sur ce point : les cookies soumis au consentement ne peuvent pas être déposés avant le choix. Le contrôle technique commence donc au tout premier chargement du document, pas au moment où l’auditeur a enfin trouvé le bouton « Tout refuser » et cliqué dessus.

Dans Google Tag Manager, une cause fréquente est le mauvais ordre des événements. L’état de consentement par défaut doit être défini avant les balises, au moyen du déclencheur « Initialisation du consentement – Toutes les pages » ou d’une autre solution garantissant le même ordre ; la mise à jour n’est envoyée qu’après l’action de l’utilisateur. Si l’état par défaut arrive trop tard, une balise peut, pendant un bref instant, voir un état indéfini ou précédemment enregistré et se déclencher. Un bandeau qui se ferme vite ne corrige pas cette condition de concurrence, car le problème tient à l’ordre d’exécution, pas à l’animation.

Dans un audit, la formule « des cookies se chargent avant le consentement » doit être décomposée en événements plus précis : le script lui-même peut avoir été chargé, une requête réseau peut être partie, un signal sans cookie peut avoir été envoyé, le serveur peut avoir tenté de définir Set-Cookie, ou un identifiant peut avoir été effectivement stocké. Chacune de ces actions a une portée probante différente. En mode Consentement avancé, certaines balises Google peuvent se charger alors que l’accès au stockage est refusé et envoyer des signaux sans cookie ; la seule présence d’un script ne suffit donc à conclure ni à une violation ni à une conformité.

La correction commence par une cartographie des outils et un modèle d’états unique et clair : quelles balises peuvent fonctionner sans choix, lesquelles exigent une catégorie précise et quel événement modifie l’état par défaut. Une fois la configuration modifiée, le contrôle est répété dans un profil vierge en conservant le journal Network, avec une attention particulière aux premières requêtes et à leurs initiateurs. Si l’erreur n’apparaît que par intermittence, cela indique généralement une condition de concurrence entre la CMP, le conteneur de balises et le code du site ; elle doit être corrigée dans l’ordre de chargement lui-même, et non dissimulée par un bandeau à l’animation plus rapide.

2. « Tout refuser » modifie l’interface, mais pas le flux de données

Un bouton peut fermer le bandeau, griser un choix et même enregistrer la valeur « denied », tandis que les balises tierces continuent de fonctionner comme auparavant. Le test du refus ne consiste donc pas à constater la disparition d’un texte, mais à comparer deux états. Nous relevons les requêtes et le stockage avant et après le refus de toutes les catégories non essentielles, puis vérifions que les balises concernées ne reçoivent pas d’événement déclencheur, qu’aucun nouvel identifiant n’apparaît et que les pages consultées ensuite conservent le refus. Une session antérieure fausse facilement ce test : si le consentement a été donné hier, le bouton « Tout refuser » peut aujourd’hui charger d’abord la page avec l’état d’hier, puis seulement le modifier, alors que la première requête est déjà partie. Supprimer manuellement les cookies entre les étapes crée également une propreté artificielle et ne teste pas le véritable mécanisme de retrait. Le refus initial et le retrait ultérieur sont donc deux scénarios distincts : le premier commence sans décision, le second avec un consentement donné sciemment, et leurs résultats ne doivent pas être confondus dans une seule capture d’écran.

Même après un refus, le site peut effectuer des opérations réellement nécessaires à une fonction de sécurité, de panier ou à une autre fonction expressément demandée par l’utilisateur. Affirmer que « toute requête après un refus est mauvaise » serait donc aussi imprécis que la coche verte du bandeau. Il faut déterminer la finalité, l’initiateur et l’action de stockage de chaque connexion restante, puis configurer la CMP de sorte que le refus mette d’abord à jour l’état de consentement et que les balises utilisent leurs vérifications intégrées ou celles qui leur ont été explicitement attribuées. Un bouton fonctionnel est celui qui modifie de manière prévisible, sur plusieurs pages, le flux de données auquel il est relié. Si le refus arrête une balise publicitaire mais laisse un cookie de session propriétaire, il peut s’agir du résultat attendu ; si une catégorie en active discrètement une autre, la configuration n’est pas fiable. Après correction, le refus doit pouvoir être répété sur plusieurs pages, sans nettoyage manuel du stockage, et produire chaque fois le même état reproductible et démontrable.

3. Les catégories et la politique relative aux cookies ne correspondent pas à l’inventaire réel

Un bandeau peut être techniquement rigoureux et néanmoins induire en erreur si ses catégories ou sa politique décrivent un autre site. Cela se produit notamment après la copie d’un modèle, la reprise d’un conteneur de balises ou l’ajout d’un nouvel outil sans mise à jour de la documentation. La politique mentionne alors un cookie qui n’est plus utilisé, tandis qu’un lecteur vidéo, un module de chat ou une balise de conversion publicitaire en est absent ; l’utilisateur fait son choix sur la base d’informations incomplètes. Dans cette situation, l’entreprise ne peut pas justifier quel destinataire reçoit les données, dans quel but ni combien de temps l’identifiant subsiste.

La CNIL rattache la politique relative aux cookies à l’inventaire réellement utilisé, qui doit indiquer la finalité, le fournisseur du service ou le destinataire et la durée de conservation, et non uniquement ce que le catalogue de la CMP a reconnu automatiquement. Un cookie portant le même nom peut servir à des usages différents selon la configuration, tandis qu’un identifiant propriétaire personnalisé peut ne figurer dans aucune base publique. L’audit relie donc l’objet technique à la finalité réelle de l’éditeur et au responsable de l’outil. Il ne s’agit pas de recopier l’hypothèse d’un catalogue, mais de vérifier que la configuration, le destinataire et la durée correspondent à ce que l’entreprise utilise effectivement et sait expliquer.

L’inventaire ne s’arrête pas à l’onglet Cookies : il doit couvrir localStorage, sessionStorage, IndexedDB, les requêtes de pixels et de serveurs ainsi que les identifiants employés dans les URL ou les parcours de formulaire lorsqu’ils interviennent dans le suivi. Les lignes directrices techniques du CEPD expliquent que le champ d’ePrivacy n’est pas lié à une seule technologie de stockage. Une politique qui promet « nous n’utilisons pas de cookies » ne répond donc pas encore à la question de savoir si le site accède autrement aux informations du terminal ou envoie des signaux de mesure. La liste des noms de cookies est ainsi le début de l’inventaire, pas un relevé complet des technologies susceptibles de stocker, lire ou transmettre des identifiants.

La solution pratique consiste à maintenir une source de référence unique pour la classification de la CMP, le tableau technique de la politique et les scénarios d’audit. Chaque entrée indique le responsable de l’outil dans l’entreprise, le fournisseur, la finalité, l’état de consentement qui l’active, le stockage utilisé, le destinataire et la durée. L’ajout d’une nouvelle balise cesse alors d’être une simple tâche dans un conteneur Google Tag Manager : il devient une modification maîtrisée qui, avant la mise en ligne, doit actualiser les informations fournies à l’utilisateur et les cas de test. Après la modification, ce même registre donne au contrôle reproductible son point de départ et montre qui, dans l’entreprise, doit corriger l’écart.

4. Une requête Network est prise pour la preuve qu’un cookie a été créé

Voir un domaine de mesure d’audience dans le panneau Network constitue un constat important, mais ne permet pas à lui seul d’affirmer qu’« un cookie a été créé ». L’entrée prouve une tentative de connexion et montre ce que le navigateur a ajouté à l’URL, aux en-têtes ou au contenu de la requête ; une requête échouée, bloquée ou annulée n’équivaut toutefois pas à des données reçues avec succès par le serveur. Pour le cookie lui-même, il faut vérifier si l’en-tête de la requête contenait Cookie, si la réponse comportait Set-Cookie, si le navigateur ne l’a pas bloqué et si l’entrée a réellement été enregistrée dans le stockage. Une requête peut être bloquée ou annulée avant que le serveur ne reçoive les données ; cette limite de la preuve doit aussi apparaître dans la formulation du constat, sans fusionner en une seule affirmation la tentative de connexion, le résultat de l’envoi et le stockage.

La conclusion inverse n’est pas plus sûre. Une requête sans cookie peut contenir l’état de consentement et d’autres paramètres, tandis que le site peut utiliser un identifiant localStorage, un paramètre d’URL ou une autre méthode technique ; l’absence de cookie ne rend pas automatiquement la connexion anonyme ou vide. De son côté, Set-Cookie est une instruction du serveur au navigateur, pas la garantie qu’une entrée a été enregistrée : le navigateur peut la refuser en raison du domaine, des attributs de sécurité, de restrictions sur les cookies tiers ou d’une autre politique, alors qu’un cookie propriétaire créé par JavaScript peut apparaître sans cet en-tête de réponse. DevTools affiche aussi les motifs de blocage ; la présence de Set-Cookie doit donc être lue avec la décision du navigateur et l’état réel dans Application. Si aucune nouvelle ligne n’apparaît dans l’onglet Cookies, nous ne rebaptisons pas le signal « sans données » : nous examinons l’URL, les en-têtes, les paramètres et les autres stockages.

La méthode la plus sûre réunit trois vues sur une même chronologie : ce qui a déclenché la requête, ce que le serveur a demandé au navigateur de faire et ce qui a ensuite été effectivement conservé dans ce profil précis. Le rapport d’audit s’en tient délibérément aux faits démontrés. Nous écrivons « une requête a été envoyée au domaine X avant le choix », « la réponse contient une tentative de création d’un cookie » ou « l’identifiant Y est resté dans Application après le refus », car un développeur peut répéter l’étape, un juriste voit la limite du fait technique et le résultat peut être comparé objectivement après la correction. Nous ne déduisons pas toute la chaîne de traitement des données d’une seule capture d’écran : elle ne peut prouver que l’action, l’état et l’instant précis où elle a été prise.

5. Le retrait du consentement est caché ou techniquement incomplet

Le consentement n’est pas un clic unique que le site pourrait ensuite oublier. L’article 7, paragraphe 3, du RGPD permet de le retirer à tout moment et exige que le retrait soit aussi simple que l’octroi du consentement, ce que la CNIL traduit également en recommandations pratiques. Si l’utilisateur peut consentir dès le premier écran de la page d’accueil, mais doit fouiller une sous-section de la politique de confidentialité, envoyer un e-mail ou effacer les cookies dans les paramètres du navigateur pour retirer son accord, le mécanisme n’est pas aussi accessible. Une solution courante consiste à placer un lien permanent vers les préférences de cookies dans le pied de page. Nous vérifions qu’il reste facile à trouver depuis chaque page, y compris lorsque le bandeau n’est plus visible, car c’est précisément dans cet état que l’utilisateur cherchera à modifier une décision antérieure.

Le test technique commence par un consentement accordé délibérément et des balises réellement activées. L’auditeur ouvre ensuite le gestionnaire de préférences, retire son consentement pour les catégories non essentielles et poursuit sa navigation sans créer un faux point de départ en effaçant manuellement le stockage. Il faut vérifier si la CMP envoie l’état mis à jour et si les balises le reçoivent, si de nouveaux flux de données fondés sur le consentement cessent bien de se déclencher et ce qu’il advient des identifiants enregistrés localement. C’est ainsi qu’apparaît un bouton qui enregistre le nouveau choix sans le communiquer aux balises déjà chargées. Nous consignons aussi l’ordre des événements de la modification afin de distinguer un choix correctement enregistré d’une mise à jour transmise trop tard à la balise dépendante, voire jamais transmise.

Le retrait vaut pour l’avenir ; à lui seul, il ne réécrit pas le passé et n’efface pas toutes les données traitées licitement auparavant. Les traitements ultérieurs fondés sur ce consentement doivent cesser, mais la conservation ou l’effacement de données déjà reçues par le serveur peut nécessiter une analyse distincte. Le rapport sépare donc l’arrêt des futurs flux de données de la question de la conservation des données antérieures, sans prétendre qu’un changement technique de préférence résout les deux. La correction doit relier l’interface à l’intégration : le lien doit être accessible sur chaque page, la CMP doit afficher l’état actuel, le changement doit parvenir à chaque balise dépendante et le test doit être répété avec plusieurs combinaisons de catégories. « Tout refuser » peut fonctionner alors que la désactivation du seul interrupteur marketing reste sans effet. La suppression des identifiants du navigateur doit elle aussi être appréciée selon leur fonction ; nous ne promettons pas qu’un clic dans une CMP purgera automatiquement chaque système tiers.

6. Le mode Consentement de base et le mode Consentement avancé sont confondus, ou les données modélisées sont promises

Le mode Consentement de base et le mode Consentement avancé ne sont pas deux apparences d’un même interrupteur. Dans la version de base, les balises Google ne se chargent pas avant le consentement et Google ne reçoit jusque-là aucune donnée de mesure provenant de ces balises ; une fois le consentement donné, elles peuvent commencer la mesure habituelle. Dans la version avancée, les balises se chargent avec l’accès au stockage refusé par défaut et peuvent, tant que le consentement n’est pas accordé, envoyer des signaux sans cookie. Ce mode ne doit donc pas être décrit comme un état où « rien n’est envoyé », et la version de base n’est pas automatiquement une moins bonne configuration de mesure. La différence réside dans le comportement effectif des balises avant le choix, pas dans l’apparence du bandeau ni dans le nom d’un réglage.

Le choix doit reposer sur l’analyse juridique de l’entreprise et ses besoins de mesure, et non sur l’idée que le nom d’un produit Google résoudrait à lui seul les exigences d’ePrivacy ou du RGPD. La documentation de Google sur le mode Consentement distingue le blocage des balises dans la version de base des signaux sans cookie de la version avancée. Pendant l’audit, nous contrôlons cependant la configuration réelle : les états par défaut prennent-ils effet avant les balises, quelle mise à jour part après le clic et quelles requêtes apparaissent effectivement dans chaque état ? Le nom du mode n’est pas une conclusion juridique ; le rapport décrit donc le flux testé et la configuration choisie par l’entreprise, sans lui attribuer automatiquement un label de conformité.

« Sans cookie » ne signifie pas « sans information » ; le nom du signal ne doit donc jamais remplacer l’évaluation de son contenu et de sa finalité dans le rapport. Dans le panneau Network, il faut examiner la destination, les paramètres, l’état de consentement et l’initiateur, tandis que Google Tag Assistant et les outils de débogage du mode Consentement aident à contrôler les états par défaut et ceux mis à jour. Ces vues se complètent : la première révèle le flux de données de la tentative précise, la seconde montre la logique de la configuration. Si elles ne concordent pas, il ne faut pas privilégier l’écran le plus flatteur, mais trouver où l’événement par défaut ou sa mise à jour n’est pas parvenu à la balise dans l’ordre prévu.

L’activation du mode avancé ne garantit pas non plus l’accès à des données modélisées. Dans Google Analytics 4, l’accès à la modélisation du comportement dépend des critères définis par Google pour la propriété concernée, notamment du volume et de la qualité des données ; la fonction peut ne jamais être disponible ou disparaître si ces critères cessent d’être remplis. La modélisation ne reconstitue pas les sessions individuelles des utilisateurs ayant refusé. Notre offre promet donc une configuration correcte et un ordre de signaux vérifiable, pas un volume précis de données modélisées ; leur disponibilité dépend du système de Google et de l’éligibilité de la propriété concernée. Le résultat de l’audit est ainsi une configuration reproductible et une vérification des signaux, non une promesse portant sur un volume de données que le prestataire ne maîtrise pas.

7. Le test s’arrête à la première page et au premier jour

La page d’accueil couvre rarement tout l’inventaire du suivi. Une balise vidéo peut ne se charger qu’au lancement de la lecture, une carte seulement sur la page de contact, une conversion publicitaire après l’envoi d’un formulaire, un outil de paiement à la dernière étape du panier, et un script de chat ou de personnalisation après un certain délai. Un auditeur qui ouvre une URL, attend quelques secondes puis ferme le scanner peut rédiger un rapport techniquement exact sur cette seule vue, mais dangereusement incomplet sur le site dans son ensemble. Chacun de ces états doit être ouvert par l’action qui l’active réellement ; il ne faut pas supposer que l’inventaire de la page d’accueil représente automatiquement tous les gabarits et tous les parcours utilisateurs.

Nous construisons les scénarios à partir des véritables parcours et gabarits du site : page publique, article, formulaire de contact, espace client, processus d’achat, contenu intégré et chaque version linguistique ou régionale importante. La version mobile doit aussi être contrôlée, car les boutons de la CMP peuvent s’y chevaucher ou le lien vers les préférences devenir inaccessible alors que tout fonctionne sur ordinateur. Un robot d’exploration assure une couverture étendue, tandis qu’un scénario manuel ouvre les états qu’il ne verra jamais sans compte, clic ou saisie. Les versions linguistiques et régionales, tout comme l’affichage mobile, ne sont pas des copies décoratives si elles modifient le chargement des intégrations ou les choix proposés à l’utilisateur.

Un audit ponctuel ne couvre pas les changements dans le temps. Une nouvelle balise marketing, le remplacement d’un modèle de CMP ou l’importation d’un conteneur Google Tag Manager peuvent rompre une séquence jusque-là correcte sans modifier visiblement le bandeau. Tout nouvel outil doit donc être testé avant sa mise en ligne, puis faire l’objet d’une nouvelle comparaison. Cette discipline mérite d’être prévue dès le contrat de développement du site, comme nous l’expliquions dans notre article sur les 10 erreurs à éviter lors de la création d’un site web. Notre processus d’audit prévoit une nouvelle analyse 30 et 180 jours après la mise en œuvre, avec les mêmes scénarios et les mêmes rubriques de preuve, afin de vérifier si la correction résiste au rythme réel des mises en ligne et si de nouveaux outils ou écarts de configuration ne sont pas apparus. La première échéance montre si l’intégration a tenu pendant les publications courantes ; la seconde révèle les changements plus tardifs. À chaque contrôle, nous comparons la requête, le stockage et l’état de consentement précis avec le constat initial, au lieu de nous contenter de l’impression que « cela semble mieux maintenant ».

Ce que vous recevez dans un audit technique des cookies et du suivi

Le premier livrable est un inventaire vérifié des cookies, des stockages, des balises et des requêtes tierces. Chaque constat y est relié à une page, à une action de l’utilisateur et à un état de consentement ; il précise aussi la preuve et sa limite : entrée Network, tentative Set-Cookie, cookie effectivement visible dans Application, entrée localStorage ou événement de la CMP. Le développeur reçoit ainsi une erreur reproductible, pas une note vague demandant de « corriger le RGPD », tandis que le responsable de la protection des données voit quels faits nécessitent encore une décision juridique. Chaque constat est également accompagné d’une procédure de reproduction, afin de contrôler après la mise en œuvre exactement la même page, le même choix, la même requête et le même résultat de stockage.

La deuxième partie est la mise en œuvre. Nous corrigeons les catégories de la CMP ainsi que l’ordre des états par défaut et des mises à jour dans Google Tag Manager, configurons les vérifications du consentement pour Google Analytics 4, Google Ads, Meta Pixel et les autres outils, et préparons la déclaration relative aux cookies et le texte de la politique de confidentialité. Nous choisissons entre le mode Consentement de base et le mode avancé selon votre analyse juridique et vos besoins de mesure, sans présenter la version avancée comme la solution universelle ni promettre des données modélisées lorsque la propriété Google Analytics 4 concernée ne remplit pas les conditions de Google. Le résultat de la mise en œuvre est contrôlé dans les mêmes états de consentement que le constat initial, afin d’étayer le changement de configuration par des preuves comparables.

Le service est proposé à partir de 800 € et le délai de réalisation est de 1 à 4 semaines, selon la taille du site, le nombre de langues et de gabarits, la complexité de la CMP et des conteneurs de balises, ainsi que le nombre d’intégrations nécessaires. Avant le début des travaux, nous distinguons clairement dans le prix et le calendrier les preuves d’audit, les corrections techniques et les questions qui doivent être tranchées par le juriste ou le délégué à la protection des données de l’entreprise. Nous effectuons ensuite de nouvelles analyses après 30 et 180 jours en reprenant les scénarios fixés. Le prix et le délai portent ainsi sur un périmètre technique clairement défini, pas sur une promesse indéterminée de régler toute la protection des données de l’entreprise.

Si vous recherchez un « audit RGPD d’un site web », nous commençons par convenir qu’il désigne ici les cookies, le suivi, la CMP et le mode Consentement, et non un examen complet de la conformité au RGPD de toute l’organisation. Nous ne promettons donc que ce que nous pouvons démontrer techniquement : le comportement du site avant le choix, après le refus, après le consentement et après son retrait, les signaux envoyés aux outils et les points où les preuves ne suffisent pas encore à une conclusion juridique. Cette distinction permet d’achever le travail technique avec un résultat vérifiable et de confier les questions juridiques à la personne chargée d’examiner l’ensemble des traitements de données à caractère personnel. Pour demander un audit des cookies et du suivi, envoyez-nous l’adresse du site et le nom de la CMP ou du gestionnaire de balises utilisé.