Global Privacy Control et modes de consentement hybrides : un modèle opérationnel

Il s’agit de recherche sur la vie privée, et non d’un conseil juridique. Voir l’avertissement complet en pied de page.

TL;DR

Le GPC est désormais contraignant au titre du CCPA § 7025(c)(6) depuis le 1 janvier 2026 — les entreprises doivent indiquer visiblement que le signal a été honoré. 12 États américains exigent la reconnaissance du GPC ou d’un signal universel d’opt-out.
Le GPC est présomptif — pas encore contraignant — au titre du droit de l’UE. Le projet d’article 88b du Digital Omnibus accorderait une présomption de conformité aux opérateurs qui honorent le signal, six mois après l’adoption des normes par les navigateurs.
Une application à deux couches est le bon modèle — court-circuit côté client via data-statnive-honour-gpc="1" pour le chemin à friction minimale, plus une application côté serveur consent.respect_gpc en défense en profondeur.
Le mode hybride est appliqué côté serveur, pas confié au client — le serveur conserve l’enregistrement faisant autorité du consentement, de sorte que le navigateur ne peut pas mentir sur l’état du consentement.
Le plugin WordPress ne livre que 2 modes de consentement aujourd’hui ; Statnive Live en a les 4. Le mode hybride est exclusif à Statnive Live à ce jour.

Pourquoi le GPC compte en 2026

La révision ePrivacy de 2009 a donné aux résidents de l’UE le droit de refuser le stockage et l’accès sur leur équipement terminal. Seize ans plus tard, la façon dont la plupart des opérateurs sollicitent ce refus — un bandeau cookies avec un bouton Refuser enterré — est la responsabilité réglementaire qui a produit les sanctions jumelles 325 M€ / 150 M€ de la CNIL du 1 septembre 2025 et l’amende de 600 000 € de l’AP néerlandaise contre Kruidvat du 16 juillet 2024. Le bandeau est ce qui se fait sanctionner, pas seulement les cookies derrière.

Global Privacy Control est l’alternative au niveau du navigateur. Un seul bit défini sur chaque requête HTTP sortante — Sec-GPC: 1 — qui dit : ce visiteur refuse le suivi non essentiel, point final, aucun bandeau par site requis. Le CCPA californien traite le GPC comme un signal juridiquement contraignant au titre du § 7025 du règlement CCPA. La CPPA a finalisé le paquet réglementaire 2026 en septembre 2025 ; le § 7025(c)(6) — effectif depuis le 1 janvier 2026 — exige en outre que les entreprises indiquent visiblement que le signal a été honoré (par exemple un message « Demande d’opt-out honorée »). Douze États américains exigent désormais la reconnaissance du GPC ou d’un signal universel d’opt-out début 2026, et en septembre 2025 les procureurs généraux de Californie, du Colorado et du Connecticut ont annoncé une investigation coordonnée contre les entreprises qui n’honorent pas le signal. Le projet d’article 88b du Digital Omnibus accorderait aux opérateurs UE honorant le GPC une présomption de conformité une fois les normes techniques adoptées — ce qui est exactement ce dont l’UE a besoin pour la réforme cookies depuis 2018.

L’article qui suit est le modèle de l’opérateur. Ce qu’est le GPC et ce qu’il n’est pas, comment Statnive Live l’honore à deux couches, pourquoi le mode de consentement « hybride » est le défaut réaliste 2026 pour les sites aux besoins réglementaires mixtes, l’API du traceur pour les opérateurs intégrant leur propre bandeau, là où le plugin WordPress diverge, et le plan de test de bout en bout qui vérifie que le GPC est réellement honoré.

Ce qu’est le GPC, et ce qu’il n’est pas

Global Privacy Control est un en-tête HTTP et une propriété JavaScript correspondante navigator.globalPrivacyControl. Les deux véhiculent un seul bit : ce visiteur refuse la vente et le partage de ses informations personnelles et refuse le suivi non essentiel. La spécification technique se trouve à globalprivacycontrol.github.io/gpc-spec.

Le signal est défini par le navigateur, typiquement via une extension de confidentialité (DuckDuckGo Privacy Essentials, Privacy Badger) ou par un navigateur axé sur la confidentialité par défaut (Brave, Mullvad Browser, DuckDuckGo Browser). Chrome — avec environ 65 % de part de marché mondial à la mi-2026 — n’a pas de support GPC natif et ne s’est pas engagé sur un ; Safari et Microsoft Edge manquent aussi de support natif ; Firefox a un support intégré derrière la préférence privacy.globalprivacycontrol.enabled. Le résultat est que le GPC atteint une part significative mais minoritaire du trafic UE — la part croît à mesure que les utilisateurs sensibles à la confidentialité adoptent les outils, et le projet d’article 88b exigerait que les navigateurs majeurs offrent des capacités GPC une fois les normes techniques adoptées. Une étude relue par les pairs publiée le 5 mai 2026 a conclu que le GPC peut réduire les bandeaux cookies de l’UE — mais seulement partiellement, et seulement si les régulateurs et législateurs européens prennent des mesures délibérées pour clarifier comment le signal se mappe au droit existant en matière de protection des données.

Ce qu’est le GPC : une préférence de confidentialité contraignante au titre du droit californien et une préférence de confidentialité présomptive au titre du projet d’article 88b. Un opérateur qui l’honore n’a pas besoin de redemander au visiteur — le visiteur a déjà répondu.

Ce que le GPC n’est pas : un substitut à la posture de conformité plus large de l’opérateur. Honorer le GPC n’élimine pas les obligations de transparence de l’article 13 RGPD de l’opérateur, le point d’accès du droit d’opposition de l’article 21, l’accord de sous-traitant de l’article 28 avec les fournisseurs en aval, ou l’AIPD de l’article 35 le cas échéant. Le GPC est une entrée dans la décision de consentement / refus ; le reste de la machinerie RGPD s’applique toujours.

Ce que le GPC n’est pas, deuxième partie : automatiquement activé dans les juridictions UE. La position actuelle du RGPD est que le GPC n’est pas un retrait contraignant du consentement — les opérateurs peuvent choisir de l’honorer (et la plupart des outils d’analyse web axés sur la confidentialité le font) mais ne sont pas légalement obligés. Le projet d’article 88b changerait cela, six mois après l’adoption de la norme technique. Les opérateurs qui planifient à l’avance honorent par défaut le GPC dès maintenant pour éviter le basculement de politique plus tard.

Deux couches d’application du GPC

Statnive Live honore le GPC à deux couches — côté client et côté serveur. Les deux couches importent car elles échouent de manières différentes.

Court-circuit côté client. Le traceur vérifie navigator.globalPrivacyControl === true à l’initialisation du script. Si la propriété est définie à true ET que l’opérateur a activé l’honorabilité GPC via l’attribut data-statnive-honour-gpc="1" sur la balise de script, le traceur court-circuite vers des fonctions no-op. Aucun événement de suivi n’est envoyé. Aucun aller-retour serveur. Aucune donnée ne quitte le navigateur du visiteur.

C’est le défaut préservant la vie privée pour les opérateurs qui veulent l’implémentation GPC à friction minimale. Cela économise l’aller-retour serveur ; cela économise la bande passante du visiteur ; cela rend la réponse GPC auditable par quiconque dispose des DevTools du navigateur (aucune requête sortante ne se déclenche).

Application côté serveur. Le point d’accès d’ingest vérifie l’en-tête Sec-GPC: 1 sur chaque requête entrante. Si la politique du site a consent.respect_gpc = true et que l’en-tête est défini, la requête est rejetée avant le calcul de l’identifiant du visiteur. Aucun enregistrement pseudonyme n’est créé pour un visiteur qui refuse — il n’y a rien dans la base de données à supprimer plus tard car rien n’a été écrit.

La couche côté serveur est la défense en profondeur qui rattrape les cas que la couche côté client manque : les visiteurs qui arrivent via un rendu côté serveur (aucun script de traceur n’a tourné sur la machine du visiteur), les visiteurs dont le script de traceur a été bloqué par une extension avant qu’il ne puisse court-circuiter, les visiteurs utilisant un client HTTP en ligne de commande, et les visiteurs sur des navigateurs où la propriété JavaScript GPC est absente mais l’en-tête HTTP est défini.

Les deux couches se composent. La couche côté client est le chemin préféré de l’opérateur ; la couche côté serveur est la garantie que la politique est honorée indépendamment de ce qui s’est passé dans le navigateur.

Pourquoi le mode « hybride » existe

Un déploiement consent-free est le modèle mental le plus simple : aucun bandeau, aucun cookie, mesure d’audience côté serveur uniquement. Un déploiement consent-required est l’autre modèle le plus simple : un bandeau bloque le traceur jusqu’à ce que le visiteur accepte. Les deux fonctionnent pour les sites aux besoins réglementaires uniformes.

Le site 2026 réaliste a des besoins réglementaires mixtes. Les pages marketing ont besoin de mesure d’audience sans consentement ; le flux de paiement a besoin d’attribution e-commerce que l’exemption de mesure d’audience de la Fiche 16 de la CNIL ne couvre pas ; le tableau de bord connecté n’a besoin d’aucune analyse web car l’utilisateur est un client connu.

hybrid est le mode de consentement pour les sites aux besoins réglementaires mixtes. Le modèle :

Avant que le visiteur n’interagisse avec le bandeau : la mesure d’audience agrégée anonyme tourne. Sans cookies, sel quotidien-rotatif, référent réduit à l’hôte, IP tronquée, User-Agent minimisé — l’architecture consent-free par défaut.
Après l’acceptation du consentement par le visiteur : le traceur passe à une attribution complète. Un identifiant de cookie est émis vers le navigateur ; la continuité de session par visiteur est préservée ; les événements e-commerce sont capturés ; l’attribution de conversion circule.
Après le refus (ou retrait après acceptation) : le traceur revient au mode anonyme. Aucun cookie ; aucune continuité par visiteur. Si le visiteur avait précédemment accepté, l’identifiant de cookie existant est invalidé côté serveur via la liste de suppression.

C’est le même modèle que Google a déployé en mars 2024 sous le nom de « Consent Mode v2 », mais avec une différence critique : le mode hybride de Statnive Live est appliqué côté serveur, pas confié au client. Le modèle Google envoie un paramètre sur chaque événement indiquant l’état du consentement ; le serveur de réception est censé appliquer le bon traitement. Le mode hybride de Statnive Live applique l’état du consentement à la couche d’ingest sur la base de l’enregistrement propre au serveur du consentement du visiteur. Le navigateur ne peut pas mentir sur le fait que le consentement a été donné car le serveur conserve l’enregistrement faisant autorité.

La charge jour-1 de l’opérateur est plus faible avec hybrid qu’avec consent-required. Les métriques d’audience circulent quoi qu’il en soit. Le bandeau devient un chemin vers plus d’attribution, pas une porte vers aucune attribution.

L’API du traceur

Les opérateurs intègrent leur propre bandeau de consentement avec Statnive Live en appelant deux fonctions exposées par le traceur :

// Visitor accepts consent (typically from a banner's Accept button)
statnive.acceptConsent(csrfToken);

// Visitor withdraws consent (from the privacy policy's withdraw link)
statnive.withdrawConsent(csrfToken);

Les deux fonctions POSTent vers /api/privacy/consent avec le jeton CSRF dérivé de la session de l’opérateur. Le serveur met à jour l’état de consentement du visiteur et émet l’événement d’audit privacy.consent_given ou privacy.consent_withdrawn. Les événements de traceur ultérieurs utilisent le nouvel état de consentement à la couche d’ingest côté serveur.

Le bandeau de l’opérateur est l’UI de l’opérateur. Statnive Live ne livre pas de bandeau — il existe des dizaines de plateformes de gestion du consentement et la plupart des opérateurs ont leur préférée. La surface d’intégration est deux appels de fonction et un flux d’événements d’audit. La formulation exacte, la couleur du bandeau, l’implémentation « Refuser aussi simple qu’Accepter » (pour laquelle la CNIL a sanctionné les opérateurs à plusieurs reprises) sont la responsabilité de l’opérateur.

Pour les opérateurs utilisant un CMP tiers (Cookiebot, OneTrust, Sourcepoint, Didomi), le modèle d’intégration est le même : les callbacks onAccept et onReject du CMP appellent statnive.acceptConsent() et statnive.withdrawConsent(). Le CMP continue de gérer l’UI de consentement par fournisseur ; la contribution de Statnive Live est l’état appliqué côté serveur.

Là où le plugin WordPress diverge

Une note sur la parité produit qui importe pour les opérateurs choisissant entre les deux produits Statnive.

Statnive Live (le serveur d’analyse web autonome) livre les quatre modes de consentement — permissive, consent-free, consent-required et hybrid — et le contrôle de consentement appliqué côté serveur décrit ci-dessus. L’énumération à 11 juridictions avec validation par règle stricte s’applique ; l’application GPC à deux couches s’applique ; la matrice quatre-modes × 11-juridictions est la surface complète.

Le plugin WordPress Statnive livre actuellement deux modes de consentement — cookieless et disabled-until-consent — correspondant grosso modo aux modes consent-free et consent-required de Statnive Live. Le plugin honore GPC et DNT côté client et respecte l’API de confidentialité de WordPress pour l’enregistrement DSAR. Il ne livre pas actuellement le mode hybrid ni l’énumération complète à 11 juridictions.

L’arbre de décision pour les opérateurs :

Site aux besoins réglementaires uniformes (sans consentement sur toutes les surfaces, ou avec bandeau-bloquant sur toutes les surfaces) : les deux modes du plugin WordPress suffisent.
Site aux besoins réglementaires mixtes (pages marketing sans consentement + paiement avec consentement requis, ou différences par juridiction dans le trafic UE + non-UE) : le produit SaaS ou auto-hébergé Statnive Live est le bon choix. Le plugin WordPress peut coexister sur le même site si la portée du plugin est les pages vues de l’admin WordPress et la portée de Statnive Live est le frontend public.

Le post auto-hébergement vs SaaS européen privé et la comparaison plugin WP vs Statnive Live couvrent la décision plus large en détail. Pour les spécificités GPC et consentement hybride dont parle ce post, Statnive Live est le produit avec un support complet ; le plugin WordPress a le sous-ensemble plus simple et est le bon choix pour les opérateurs dont la surface réglementaire est aussi plus simple.

Un chemin de migration depuis un bandeau existant

Pour les opérateurs qui ont déjà un bandeau cookies — qu’il soit fait maison ou via un CMP — et veulent passer en mode hybrid avec honorabilité GPC, une séquence de migration fonctionnelle :

Phase 1 (semaine 1) : activer l’honorabilité GPC sans changer le bandeau. Ajoutez data-statnive-honour-gpc="1" à la balise de script Statnive Live ; définissez consent.respect_gpc = true dans la politique du site. Le bandeau continue de se déclencher pour les visiteurs non-GPC ; les visiteurs GPC sont mis en no-op avant même de voir le bandeau. C’est un changement sans régression — les visiteurs qui refusaient via le bandeau avant continuent d’être refusés ; les visiteurs qui acceptaient via le bandeau avant continuent d’être acceptés ; les visiteurs GPC qui voyaient précédemment le bandeau (et probablement le refusaient) sont maintenant court-circuités avant le rendu du bandeau.

Phase 2 (semaine 2-3) : basculer en mode hybrid. Mettez à jour consent_mode de la politique du site de consent-required à hybrid. Le traceur collecte maintenant des métriques agrégées anonymes avant l’interaction avec le bandeau, et passe à une attribution complète après acceptation du visiteur. La visibilité jour-1 de l’opérateur sur le trafic bondit — la taxe de refus de bandeau de 55,6 % (selon l’étude bandeau-cookies de Plausible) s’effondre à près de zéro pour la couche de mesure d’audience.

Phase 3 (semaine 3-4) : câbler le bandeau de l’opérateur à l’API du traceur. Remplacez le callback onAccept existant du CMP (qui active actuellement les balises tierces) par un qui appelle statnive.acceptConsent(csrfToken). L’UX du bandeau ne change pas pour le visiteur ; la machinerie de suivi sous-jacente de l’opérateur transitionne vers un état appliqué côté serveur.

Phase 4 (semaine 4+) : retirer les cookies que le bandeau gardait. Une fois que l’opérateur confirme que le flux de consentement fonctionne côté serveur, les cookies tiers que le bandeau d’origine gardait (pixels publicitaires, balises de reciblage) peuvent être passés en revue et élagués. Pour les opérateurs allant complètement sans consentement, c’est l’étape qui retire entièrement le bandeau (sous réserve des conditions cumulatives de la Fiche 16 CNIL et du § 25 TDDDG). Pour les opérateurs conservant l’attribution e-commerce, le bandeau reste mais perd la majorité de son poids UX.

La migration est réversible à chaque étape. Les opérateurs qui veulent reculer à n’importe quelle phase peuvent annuler le changement de politique du site ; le journal d’audit conserve la preuve contemporaine du mode actif à chaque horodatage.

Plan de test de bout en bout

Un plan de test fonctionnel pour vérifier que le GPC est honoré aux deux couches et que le mode hybride se comporte correctement :

Test 1 : court-circuit côté client.

Installez une extension de navigateur qui définit navigator.globalPrivacyControl = true (DuckDuckGo Privacy Essentials, ou définissez la préférence Firefox privacy.globalprivacycontrol.enabled).
Confirmez que la propriété est définie en tapant navigator.globalPrivacyControl dans la console DevTools ; attendez true.
Chargez le site de l’opérateur.
Ouvrez DevTools → Network → filtrez sur /api/track.
Attendu : zéro requête sortante vers le point d’accès du traceur. Le traceur a court-circuité.

Test 2 : application côté serveur.

Utilisez curl ou tout client HTTP pour POSTer directement vers le point d’accès du traceur de l’opérateur :

curl -X POST https://app.statnive.live/api/track \
  -H 'Sec-GPC: 1' \
  -H 'Content-Type: application/json' \
  -d '{"site_id": "...", "page": "/test"}'

Attendu : HTTP 204 avec l’en-tête X-Statnive-GPC-Honoured: 1. La requête a été acceptée mais l’événement a été rejeté avant le calcul de l’identifiant du visiteur.
Inspectez la table ClickHouse events_raw de l’opérateur. Attendu : aucune ligne correspondant à la page de test et à l’horodatage.

Test 3 : mode hybride anonyme-avant-consentement.

Désactivez le GPC (supprimez l’extension ; réinitialisez la préférence Firefox).
Chargez le site de l’opérateur dans un profil propre.
N’interagissez pas avec le bandeau. Parcourez 2-3 pages.
Inspectez events_raw pour la session de test. Attendu : des lignes sont présentes, mais cookie_id_hash est NULL et visitor_signature est la valeur dérivée du sel quotidien-rotatif.

Test 4 : mode hybride passage-après-consentement.

Continuez depuis le Test 3. Acceptez le bandeau.
Parcourez 2-3 pages supplémentaires.
Inspectez events_raw pour les lignes post-consentement. Attendu : cookie_id_hash est maintenant peuplé (préfixe h: + SHA-256), même valeur sur les lignes post-consentement.

Test 5 : mode hybride retour-après-retrait.

Continuez depuis le Test 4. Retirez le consentement (appelez statnive.withdrawConsent(csrfToken) depuis la console DevTools, ou cliquez sur le lien de retrait dans la politique de confidentialité de l’opérateur).
Inspectez l’événement d’audit privacy.consent_withdrawn. Attendu : émis avec la signature du visiteur et l’horodatage.
Parcourez 2-3 pages supplémentaires.
Inspectez events_raw pour les lignes post-retrait. Attendu : cookie_id_hash est à nouveau NULL ; le visiteur revient au mode anonyme.

Test 6 : complétude du journal d’audit.

Inspectez le journal d’audit pour la session entière.
Événements attendus dans l’ordre : privacy.consent_given (Test 4), privacy.consent_withdrawn (Test 5). Les événements opt-out, DSAR-accès et DSAR-effacement sont absents car non exercés dans ce test.

Le plan de test complet tient dans une seule session de navigateur plus un appel curl. Les opérateurs qui l’exécutent une fois et capturent les captures d’écran ont le pack de démonstration dont ils ont besoin pour une inspection ou un audit interne.

Ce que cela apporte à l’opérateur

Le résultat pratique :

GPC honoré aux deux couches — court-circuit côté client évite l’aller-retour, application côté serveur est la défense en profondeur qui rattrape tout ce que la couche côté client manque.
Mode hybrid qui récupère les métriques d’audience que la plupart des déploiements consent-required perdent à la taxe de refus de bandeau de 55,6 %, tout en préservant le chemin d’attribution complète pour les visiteurs consentants.
État de consentement appliqué côté serveur plutôt que confié au client, éliminant le mode d’échec « le navigateur ment sur le consentement » que le modèle Google Consent Mode v2 expose.
Une API de traceur à deux fonctions qui s’intègre proprement avec n’importe quel bandeau — fait maison ou CMP tiers — et émet une piste d’audit structurée.
Une migration réversible en 4 phases pour les opérateurs migrant depuis un bandeau hérité sans bascule en un jour.
Un plan de test de bout en bout en 6 étapes qui vérifie que l’implémentation fonctionne en production.

Ce que cela n’apporte pas : un bandeau prêt à livrer — c’est le choix d’UI de l’opérateur. Un moyen d’outrepasser le signal GPC d’un visiteur réticent dans les juridictions UE où la politique du site honore le GPC — par conception, la couche côté serveur n’est pas outrepassable. Une compatibilité avec le mode hybride du plugin WordPress — car le plugin WordPress ne livre pas actuellement le mode hybride (la section arbre de décision couvre quand utiliser quel produit).

Quoi faire, et quoi éviter

À faire	À éviter
Activer les deux couches — côté client via `data-statnive-honour-gpc="1"` sur la balise de script + côté serveur `consent.respect_gpc = true` dans la politique du site.	Honorer le GPC seulement côté client — les extensions de confidentialité peuvent bloquer le traceur avant que le court-circuit ne se déclenche ; la couche côté serveur est la défense en profondeur.
Défaut à mode `hybrid` pour les sites aux besoins réglementaires mixtes — agrégé anonyme avant consentement, attribution complète après, état appliqué côté serveur.	Défaut à `consent-required` pour tout le site si les pages marketing n’ont pas besoin d’attribution — vous perdez 55,6 % de visibilité visiteur pour rien.
Indiquer visiblement quand le GPC est honoré (selon la mise à jour CCPA § 7025(c)(6) du 1 janvier 2026).	Traiter le GPC silencieusement et supposer que le visiteur n’a pas besoin de confirmation. Le CCPA exige désormais une indication visible.
Câbler `statnive.acceptConsent()` et `statnive.withdrawConsent()` aux callbacks `onAccept` / `onReject` du bandeau / CMP existant.	S’appuyer sur un paramètre de consentement confié au client sur chaque événement (le modèle Google Consent Mode v2). Le navigateur peut mentir ; l’enregistrement faisant autorité du serveur ne le peut pas.
Pour les sites avec trafic UE + US, défaut `consent.respect_gpc = true` quelle que soit la juridiction — cela satisfait le CCPA et 11 autres États américains, plus le mode UE `consent-free`.	Traiter le GPC comme US-uniquement. Le projet d’article 88b rendrait l’honorabilité UE présomptive une fois les normes adoptées ; honorer maintenant est la posture compatible vers l’avant.

La conclusion

Global Privacy Control est le mécanisme au niveau du navigateur auquel le projet d’article 88b du Digital Omnibus accorderait une présomption de conformité. Le modèle technique est simple : un signal d’un bit que le serveur de l’opérateur honore à l’ingest. Le modèle architectural est appliqué côté serveur, pas confié au client. Le modèle de migration est réversible et en 4 phases. Le modèle de test tient dans une seule session de navigateur.

Statnive Live livre tout cela par défaut. Quatre modes de consentement, honorabilité GPC à deux couches, modèle hybride appliqué côté serveur, API de traceur à deux fonctions, les huit événements d’audit de confidentialité couverts dans le post DSAR, et un traceur first-party ~2,0 Ko minifié / ~0,9 Ko gzippé qui fait tout cela.

Le plugin WordPress est le bon choix pour les opérateurs à posture réglementaire uniforme et déploiement de forme WordPress. Statnive Live est le bon choix pour les opérateurs aux besoins réglementaires mixtes ou aux piles non-WordPress. Pour les deux, le signal GPC est honoré.

Pour le cadre plus large, voir le Manuel 2026 de l’analyse web sans consentement dans l’UE. Pour les deltas spécifiques aux pays, voir les posts Fiche 16 CNIL et § 25 TDDDG. Pour l’angle d’actualité sur l’article 88b du Digital Omnibus qui standardiserait l’honorabilité GPC dans l’UE, voir le post Digital Omnibus. Pour la surface des droits des personnes concernées qui s’intègre à l’état de consentement, voir le post DSAR.

Il s’agit de recherche sur la vie privée, et non d’un conseil juridique. Le GPC est un signal de confidentialité contraignant au titre du CCPA californien et un signal présomptif au titre du projet d’article 88b du Digital Omnibus ; au titre du droit UE actuel, ce n’est pas un retrait contraignant du consentement. Les opérateurs choisissant d’honorer le GPC le font comme choix de politique, soutenu par les modèles d’implémentation ci-dessus. Chaque client de Statnive demeure le responsable de traitement et porte la responsabilité de sa propre configuration et AIPD. À recouper avec un conseil qualifié dans votre juridiction avant publication.

Statut des références réglementaires au 13 mai 2026 : spécification GPC à globalprivacycontrol.github.io/gpc-spec ; statut CCPA effectif le 1 janvier 2026 — § 7025(c)(6) exige une indication visible que le signal GPC a été honoré ; la CPPA a finalisé le paquet réglementaire 2026 en septembre 2025 ; 12 États américains exigent la reconnaissance GPC / signal universel d’opt-out début 2026 ; investigation coordonnée GPC AG Californie / Colorado / Connecticut de septembre 2025 ; Digital Omnibus COM(2025) 837 final (proposition de la Commission du 19 novembre 2025) article 88b — pas de vote en plénière du Parlement européen sur COM(2025) 837 à la date du 13 mai 2026 ; Avis conjoint CEPD-CEPD 2/2026 du 11 février 2026 ; directive ePrivacy 2002/58/CE et ses transpositions nationales ; lignes directrices 2/2023 v2.0 du CEPD du 7 octobre 2024 (en vigueur).