maxburst/cookie-privacy-compliance

Conformité des cookies, du suivi et de la vie privée

Cette compétence fait passer un site web de « nous pensons avoir une bannière cookies » à « voici la preuve que le site se comporte légalement pour les visiteurs qu'il sert ». Le travail comporte quatre phases : définition du périmètre, audit, mise en œuvre et vérification. Une demande peut n'en nécessiter que certaines (une mission d'audit s'arrête après le rapport), mais elles s'exécutent toujours dans cet ordre, car chacune dépend de la précédente.

Trois idées guident tout ce qui suit.

Le comportement réel est ce qui compte, et il doit être mesuré. Les régulateurs et les plaignants testent ce que le navigateur fait réellement : quels cookies existent et quels tiers sont contactés avant un choix, après un refus, après un retrait. Une bannière ne prouve rien. La plupart des constats réels sont une bannière qui est présente et semble correcte alors que les balises se déclenchent quand même. Ne concluez donc jamais de la présence d'un outil de consentement, d'un réglage de plugin ou d'une ligne de code ; concluez à partir d'un scan.

Les règles dépendent de qui sont les visiteurs. L'Europe est en opt-in (rien de non essentiel avant le consentement). Les États-Unis sont en opt-out avec des poches d'opt-in et un risque contentieux élevé. Une grande partie du reste du monde se situe entre les deux. Le même site peut être acceptable pour un public et illégal pour un autre, donc la définition du périmètre vient en premier, et chaque constat est formulé par rapport à un régime nommé.

Une bannière qui ment est pire que pas de bannière. Un bouton « Refuser » qui n'arrête pas les balises transforme un écart de conformité en une réclamation pour tromperie (c'est le scénario factuel de presque chaque action en justice en Californie). Ne mettez jamais en ligne et ne laissez jamais en place une bannière décorative. Si quelque chose ne peut pas encore être bloqué, dites-le et retirez la promesse.

Vous n'êtes pas l'avocat de l'utilisateur. Donnez des constats clairs et pratiques avec la règle qui sous-tend chacun, signalez les endroits où la loi n'est pas fixée ou où les faits nécessitent un jugement juridique, et dites-le dans le rapport. Ne vous cachez pas non plus derrière des clauses de non-responsabilité : l'utilisateur veut savoir quoi corriger.

Fichiers de référence

Lisez ce dont la mission a besoin, pas tout.

Fichier	Lisez-le quand
references/jurisdictions.md	Toujours, pendant la définition du périmètre. Mappe l'audience du site aux régimes de consentement et vous indique quel fichier de loi ouvrir.
references/law-europe.md	Tous les visiteurs UE/EEE, Royaume-Uni ou Suisse. Différences par pays, règles de conception des bannières, exemptions analytiques, application.
references/law-us.md	Tous les visiteurs américains. Seuils par État, GPC, spécificités californiennes, contentieux pour écoute électronique, santé/enfants/finance.
references/law-rest-of-world.md	Canada, Amérique latine, Asie-Pacifique, Moyen-Orient, Afrique.
references/audit-playbook.md	Exécution de l'audit : utilisation du scanner, lecture des résultats, inspection du code et de la configuration, diagnostic d'un outil de consentement existant.
references/failure-patterns.md	Interprétation des résultats du scan. 27 schémas qui expliquent la plupart des constats.
references/implementation.md	Planification et réalisation de la correction : choix ou réparation d'un outil de consentement, ordre de déploiement, politiques, GPC.
references/consent-signals.md	Câblage d'un fournisseur spécifique : Google Consent Mode v2, Meta, Microsoft, TikTok, TCF/GPP, Shopify, API de consentement WP.
references/consent-tools.md	Choix entre les outils de consentement, ou recherche du nom du cookie, du balisage et de l'API JS d'un outil.
references/script-blocking.md	Blocage d'une balise, d'une intégration, d'une police ou d'un événement côté serveur ; spécificités WordPress, Shopify, Next.js et SPA.
references/testing-tools.md	Vérification : la matrice de test complète, les contrôles d'accessibilité et de performance, la simulation géographique.
references/report-template.md	Rédaction du rapport d'audit ou du rapport de vérification.

Les fichiers de loi ont été vérifiés le 2026-11-11 et marquent chaque affirmation d'une étiquette de confiance. Le droit de la vie privée évolue tous les mois. Lorsqu'une recommandation repose sur un détail étiqueté comme incertain, listé sous « choses en mouvement », ou vieux de plus de quelques mois, vérifiez-le par rapport à une source primaire actuelle avant de vous y fier, et dites à l'utilisateur quels points vous avez revérifiés.

Phase 1 : Définition du périmètre

Établissez ces éléments avant de scanner. Trouvez ce que vous pouvez par vous-même (le site, son pied de page, ses politiques, la base de code), puis demandez à l'utilisateur uniquement ce que vous ne pouvez pas trouver. Limitez-vous à un seul tour de questions.

1. Quels sites et hôtes. Domaine principal, sous-domaines, nom de domaine de paiement ou d'application séparé, site de préproduction.
2. Où se trouvent les visiteurs. Demandez le public réel et vérifiez-le par rapport aux preuves : langues, devises, pays de livraison, géographie des analyses si vous y avez accès. « États-Unis uniquement » pour une boutique en anglais qui expédie dans le monde entier n'est pas « États-Unis uniquement ». Un site est soumis à une loi lorsqu'il cible ou dessert des personnes qui s'y trouvent, quelle que soit la localisation de l'entreprise.
3. Ce que le site fait avec les données. Publicité et reciblage, analyses, marketing par e-mail, comptes, commerce électronique, médias intégrés, chat, relecture de session. Et si cela touche un domaine sensible : santé, enfants ou adolescents, finances, localisation précise, quoi que ce soit révélant une caractéristique protégée. Les domaines sensibles changent la réponse dans chaque juridiction.
4. Taille, pour la loi américaine. Le chiffre d'affaires annuel approximatif et le volume de visiteurs par État déterminent quelles lois d'État s'appliquent. Les visiteurs uniques avec un cookie publicitaire comptent comme des « consommateurs », donc les seuils sont atteints plus tôt que ce que les propriétaires imaginent.
5. À quoi vous avez accès. Site public en lecture seule, connexion administrateur, dépôt de code, hébergement ou SSH, gestionnaire de balises, tableau de bord de l'outil de consentement, comptes de plateformes publicitaires. Cela définit la profondeur de l'audit et si vous pouvez mettre en œuvre.
6. Ce que l'utilisateur souhaite en retirer. Rapport d'audit uniquement, ou correction et vérification également. Toute mesure qu'ils ne peuvent pas se permettre de perdre. Budget pour les outils payants.

Lorsqu'il n'y a pas encore de site à scanner (l'utilisateur demande un plan, un devis ou un conseil et ne donne pas d'URL, ou décrit le site de mémoire) : ne sautez pas la mesure, déplacez-la. Considérez ce qui vous a été dit comme une hypothèse, rédigez le plan en conséquence, et faites de « scanner depuis chaque région cible pour confirmer le point de départ » la première étape du plan, avec les commandes du scanner remplies. Dites quelles parties du plan dépendent de faits que vous n'avez pas observés.

Ouvrez ensuite references/jurisdictions.md et notez les régimes cibles : pour chaque public, le régime qui s'applique et les deux ou trois règles qui guideront les constats. Présentez cela à l'utilisateur en quelques lignes avant l'audit. Si le public est inconnu ou mondial, la valeur par défaut est un opt-in strict pour tout le monde, assoupli uniquement pour une courte liste de pays où la loi est établie.

Phase 2 : Audit

Suivez references/audit-playbook.md. En résumé :

1. Scannez le site en ligne avec le scanner intégré. Il charge le site dans un navigateur propre selon différents scénarios (aucune interaction, refus, acceptation, Global Privacy Control, éventuellement retrait) et enregistre les cookies, le stockage web, les requêtes tierces et les signaux de consentement Google dans chaque phase.

   # installation unique
   npm install --prefix <skill-dir>/scripts && npx --prefix <skill-dir>/scripts playwright install chromium
   
   node <skill-dir>/scripts/scan.mjs https://example.com --out ./scan-quick                    # aperçu rapide : page de démarrage + quelques liens
   node <skill-dir>/scripts/scan.mjs https://example.com --coverage types --out ./scan-us       # audit : chaque type de page dans le sitemap
   node <skill-dir>/scripts/scan.mjs https://example.com --coverage all --out ./scan-full       # chaque URL du sitemap (lent)
   node <skill-dir>/scripts/scan.mjs https://example.com --coverage types --scenarios baseline,reject,accept,withdraw \
        --proxy http://user:pass@de-proxy:8080 --locale de-DE --timezone Europe/Berlin --out ./scan-de
   

   Utilisez --coverage types pour tout ce qui devient un rapport : les modèles de pages diffèrent (les articles intègrent des vidéos, les pages produits chargent des widgets, les pages de contact chargent un captcha), et un scan de la page d'accueil en manque la majeure partie. Ajoutez les pages de panier, de paiement et de remerciement manuellement ; elles ne sont pas dans les sitemaps.

   Lisez d'abord le tableau « Faits » en haut de summary.md, puis les captures d'écran, puis les détails par scénario dont vous avez besoin (sur les sites très publicitaires, les détails sont longs ; cherchez plutôt que de tout lire). Le scanner indique d'où il a été exécuté. Les outils de consentement changent de comportement selon le pays du visiteur, donc un scan ne décrit que ce pays. Scannez depuis chaque régime cible (via un proxy ou une sortie VPN) ou indiquez clairement dans le rapport quels régimes n'ont pas été observés. Ne présentez jamais un scan depuis une IP américaine comme une preuve concernant des visiteurs européens.

2. Regardez derrière le navigateur autant que vos accès le permettent : où chaque balise est injectée (thème, plugin, gestionnaire de balises, codé en dur, edge), comment l'outil de consentement est configuré, le suivi côté serveur qu'un scan navigateur ne peut pas voir, la mise en cache et les couches d'optimisation de scripts qui réorganisent les choses.

   Deux types de sites nécessitent plus que l'exécution par défaut, et le playbook couvre les deux : les sites dont l'optimiseur retient chaque script jusqu'au premier mouvement de souris ou à une minuterie d'inactivité (un scan rapide de ceux-ci semble propre alors qu'il ne l'est pas), et les sites de type opt-out américains sans bouton de refus, où la question est de savoir si l'opt-out et le GPC atteignent l'ensemble de la pile publicitaire. Lorsque le scanner ne peut pas répondre à une question dont dépend la mission, écrivez une courte sonde avec la même bibliothèque de navigateur et conservez-la avec les preuves.

3. Diagnostiquez l'outil de consentement déjà présent. Généralement un est installé et à moitié configuré. Déterminez exactement pourquoi il échoue (le playbook a une séquence de décision) car la correction est bien plus souvent une réparation qu'un remplacement.

4. Vérifiez le côté papier : politique de confidentialité, politique de cookies, liens et formulations requis, formulaires et leur langage de consentement, voie de demande de droits, enregistrements de consentement.

5. Rédigez les constats par rapport aux régimes cibles. Chaque constat : ce qui a été observé (avec preuve du scan), quelle règle il enfreint pour quel public, la gravité et la correction. Utilisez references/report-template.md. Le rapport a deux niveaux : un résumé en langage simple sur lequel le propriétaire du site peut agir, puis les détails techniques pour celui qui met en œuvre.

Arrêtez-vous ici si la mission est uniquement un audit. Ne modifiez rien sur un site pendant un audit.

Phase 3 : Mise en œuvre

Suivez references/implementation.md. Les éléments essentiels :

• Acceptez le plan d'abord. Montrez à l'utilisateur ce qui changera, quelle mesure ils perdront ou conserveront, tout plan payant nécessaire, et obtenez un accord. Supprimer ou bloquer un traqueur modifie les rapports et les performances publicitaires de quelqu'un ; c'est leur décision, pas la vôtre.
• Travaillez dans un endroit sûr. La préproduction si elle existe. En production : sauvegardez d'abord, modifiez une chose à la fois, sachez comment revenir en arrière, et ne laissez jamais un site dans un état où la bannière promet quelque chose que les balises ne font pas.
• Corrigez dans l'ordre des dépendances : supprimez ce qui n'est pas utilisé, établissez un outil de consentement comme seul propriétaire du consentement, définissez les valeurs par défaut du consentement avant le chargement de toute balise, bloquez chaque balise et intégration via celui-ci, câblez les signaux des fournisseurs (Consent Mode et le reste), gérez le GPC et les liens d'opt-out américains, faites fonctionner le retrait, puis mettez à jour les politiques pour correspondre à ce que le site fait désormais.
• Videz chaque couche de cache après les modifications (cache de page, CDN, regroupement minification/combinaison), sinon vous testerez le site d'hier.

Phase 4 : Vérification

Rien n'est corrigé tant qu'un nouveau scan ne le montre pas. Relancez le scanner avec les mêmes scénarios et points de vue que l'audit et comparez avec l'exécution d'audit. references/testing-tools.md contient la matrice complète ; le minimum pour la validation est :

• Publics en opt-in : zéro cookie non essentiel et zéro requête de traqueur avant un choix et après un refus, y compris après un mouvement réel de souris et un défilement ; le refus sur la première couche avec une proéminence égale ; l'acceptation charge effectivement les balises ; le retrait les arrête et supprime les cookies traqueurs propriétaires ; le choix persiste entre les pages et n'est pas redemandé.
• Publics en opt-out : le lien d'opt-out et le GPC arrêtent chacun les balises de vente/partage/publicité ciblée sans clics supplémentaires ; les visiteurs californiens voient une confirmation que le signal a été honoré ; rien ne se déclenche avant le consentement sur les pages touchant des données sensibles.
• Partout : les signaux de consentement sur les hits Google sortants correspondent à l'état choisi par le visiteur ; les résultats sont les mêmes sur les chargements en cache et sans cache, sur mobile et sur les types de pages importants (produit, paiement, remerciement, formulaires) ; la politique de cookies liste ce que le scan trouve.

Rapportez ce qui a réussi, ce qui a échoué et ce qui n'a pas pu être testé (par exemple une région pour laquelle vous n'aviez aucun point de vue, ou des événements côté serveur auxquels vous n'aviez pas accès). Un contrôle non testé est signalé comme non testé, jamais comme réussi.

Notes de travail

• Preuve avant affirmation. Citez le nom du cookie, l'hôte de la requête, le paramètre de consentement, la capture d'écran. Un constat sans preuve est une opinion.
• Les cookies et hôtes inconnus sont des constats à résoudre, pas à laisser passer. Identifiez-les (qui les pose, à quoi ils servent) ou listez-les comme non résolus.
• La gravité suit l'exposition réelle : qui est le public, quelles données sont impliquées, à quel point l'échec est visible, à quel point cette règle est activement appliquée ou contestée en justice. Un pixel publicitaire qui se déclenche avant le consentement pour des visiteurs français, ou sur une page de santé américaine, est critique. Un lien d'empreinte manquant ne l'est pas.
• Conservez la mesure de l'utilisateur là où la loi le permet. La conformité ne signifie pas supprimer les analyses. Préférez l'option qui satisfait la règle et conserve les données les plus utiles : balises bloquées par consentement, Consent Mode, analyses sans cookies ou en configuration exemptée, comportement spécifique à une région. Expliquez le compromis et laissez l'utilisateur choisir.
• Dites ce que vous n'avez pas vérifié. Les applications mobiles, les pixels de suivi des e-mails, le partage de données hors ligne, les contrats avec les fournisseurs et la paperasse sur les transferts internationaux font partie de la conformité à la vie privée et sont pour la plupart extérieurs à un scan de site web. Nommez ceux qui semblent pertinents afin qu'ils ne soient pas considérés comme faits.