Blog · Conformité

Le cookie n'est pas le problème — c'est la case dans laquelle il est rangé

Un chercheur a publié le 20 septembre la description d'un cookie d'OpenAI qui suit l'utilisateur d'un site annonceur à l'autre, lié à son compte, et déclaré « analytics » — donc posé même lorsqu'on refuse le consentement marketing. L'intérêt du cas n'est pas où vous croyez.

Ce que je peux affirmer, et ce que je ne peux pas

Tout ce qui suit sur le cookie lui-même provient d'une seule source : une analyse technique publiée le 20 septembre 2026 par Buchodi's Threat Intel. Je ne l'ai pas reproduite, et aucune autre publication ne l'a confirmée à ma connaissance au moment où j'écris.

Je rapporte donc des constats de chercheur, pas des faits établis. La bonne nouvelle, c'est que la partie vérifiable l'est par n'importe qui en trente secondes — et je dis plus bas comment. Le raisonnement qui occupe la seconde moitié de cet article, lui, ne dépend pas de ce cas particulier.

Ce que décrit l'analyse

Un cookie nommé __obi, posé sur le domaine .openai.com, d'une durée d'un an, lié au compte ChatGPT connecté. Il porte les attributs SameSite=None et Secure, ce qui signifie en clair que le navigateur l'envoie en contexte tiers : depuis un autre site que celui qui l'a posé.

Concrètement, d'après l'analyse : quand un internaute arrive sur un site commercial qui fait tourner un pixel OpenAI, ce cookie repart vers OpenAI accompagné de ce que le pixel a relevé sur la page. Le chercheur dit avoir observé le mécanisme sur douze sites commerciaux, et rapporte avoir décodé 932 jetons, dont 736 rattachés à un compte.

Et le point qui fait l'affaire : OpenAI le classe comme cookie d'analyse et non de marketing. Conséquence directe — refuser le consentement marketing ne l'empêche pas d'être posé.

La réponse d'OpenAI

Le chercheur indique avoir transmis ses constats le 14 septembre 2026 aux adresses presse et vie privée de l'entreprise. Le support a accusé réception et indiqué que les observations seraient partagées en interne pour examen. Il n'a pas répondu aux questions portant sur la classification du cookie ni sur la gestion du consentement.

C'est une réponse d'accusé de réception. Elle ne confirme ni n'infirme quoi que ce soit, et il serait malhonnête de la présenter autrement.

Vérifiez vous-même

Trente secondes, sans outil

C'est le principal intérêt de ce dossier par rapport à la plupart des controverses techniques : il ne demande pas de vous fier à qui que ce soit.

La manipulation

Ouvrez les outils de développement de votre navigateur — F12 sur la plupart —, onglet Application ou Stockage selon le navigateur, section Cookies. Regardez le domaine openai.com.

Vous verrez le nom du cookie s'il est présent, sa date d'expiration, et surtout les colonnes SameSite et Secure. Un SameSite=None est ce qui autorise l'envoi depuis un autre site : c'est la signature technique d'un cookie conçu pour le suivi inter-sites, quelle que soit l'étiquette qu'on lui donne par ailleurs.

Ce que cette vérification ne prouve pas : la présence du cookie ne dit rien de ce qui est fait des données, ni de la classification déclarée dans la politique de l'éditeur. Elle établit une caractéristique technique, pas une intention. C'est déjà beaucoup plus que ce dont on dispose d'habitude.

Le vrai sujet

Un bandeau de consentement n'agit pas sur les cookies. Il agit sur des catégories.

Voici pourquoi ce cas mérite mieux qu'un haussement d'épaules, et pourquoi il vous concerne même si vous ne mettez jamais les pieds sur openai.com.

Quand un internaute clique « refuser tout sauf le nécessaire » sur votre site, il ne refuse pas des cookies. Il refuse des catégories — strictement nécessaire, préférences, mesure d'audience, marketing. Et c'est un humain, quelque part, qui a décidé dans quelle catégorie chaque cookie tombe.

Cette décision est une déclaration. Elle n'est vérifiée par aucun mécanisme technique. Le navigateur ne sait pas ce que fait un cookie ; il sait seulement ce que le script de gestion du consentement lui dit d'autoriser ou de bloquer.

Les trois façons de se tromper, par ordre de fréquence

1. Le classement de bonne foi qui vieillit mal. Un outil déclaré « mesure d'audience » à l'installation a depuis ajouté du suivi inter-sites dans une mise à jour. Personne n'a relu la fiche. C'est de loin le cas le plus courant, et il ne demande aucune mauvaise intention.

2. La catégorie recopiée du fournisseur. Le bandeau affiche ce que la documentation du prestataire annonce. Si elle se trompe ou si elle est optimiste, vous relayez son erreur sous votre nom — et c'est vous, éditeur du site, qui répondez du consentement recueilli chez vous.

3. Le cookie que le bandeau ne connaît pas du tout. Ajouté par une intégration, un outil de chat, une carte, une vidéo intégrée. Il n'apparaît dans aucune catégorie, donc aucun refus ne le touche.

Dans les trois cas, le bandeau fonctionne parfaitement — il applique exactement ce qu'on lui a dit. Le problème n'est jamais dans l'outil de consentement, il est toujours dans l'inventaire qui l'alimente.

Et cet inventaire, presque personne ne le refait. Il est établi une fois, au moment de la mise en conformité, souvent par le prestataire qui a posé le bandeau — puis le site vit, les intégrations s'ajoutent, les outils se mettent à jour, et la liste reste celle de la première année.

La mécanique

Bloquer avant, ou nettoyer après

Pour comprendre pourquoi la catégorie déclarée décide de tout, il faut savoir ce que fait réellement un outil de gestion du consentement. Il existe deux façons de s'y prendre, et elles n'offrent pas du tout les mêmes garanties.

Le blocage préalable

L'outil empêche les scripts tiers de se charger tant que le consentement n'est pas donné. Il neutralise les balises — en les réécrivant dans un type que le navigateur n'exécute pas — puis les libère catégorie par catégorie selon les choix.

C'est la méthode correcte, et elle suppose que chaque script ait été identifié et rattaché à une catégorie à l'avance. Un script inconnu de l'outil n'est pas bloqué : il se charge normalement.

Le nettoyage a posteriori

Les scripts se chargent, posent leurs cookies, et l'outil supprime ensuite ceux qui ne correspondent pas aux choix de l'utilisateur.

C'est une illusion de conformité. Au moment où le cookie est supprimé, la requête est déjà partie, l'adresse IP est déjà arrivée chez le tiers, et le profil a déjà pu être alimenté. On efface une trace locale, pas un traitement distant. Et cette méthode reste répandue, parce qu'elle est infiniment plus simple à installer sur un site existant.

La conséquence rejoint le fil de cet article : dans les deux approches, tout repose sur une liste établie à la main. Le blocage préalable protège de ce qu'il connaît ; le nettoyage a posteriori ne protège de rien mais entretient l'illusion. Dans aucun des deux cas le navigateur ne décide par lui-même qu'un cookie relève du marketing.

Une façon simple de savoir dans quelle configuration vous êtes : en navigation privée, refusez tout, puis regardez l'onglet réseau des outils de développement avant de cliquer quoi que ce soit. Si des requêtes partent déjà vers des domaines tiers, vous êtes en nettoyage a posteriori.

Ce que dit le cadre

Ce n'est pas le nom qui compte, c'est la finalité

Le principe européen tient en une idée simple : ce qui déclenche l'obligation de consentement, c'est la finalité poursuivie, pas l'étiquette que l'éditeur choisit. Un traceur qui sert à la publicité relève du consentement, qu'on l'ait rangé dans « marketing », dans « analyse » ou ailleurs.

Autrement dit, la catégorie déclarée n'est pas un moyen de défense. Elle est au mieux un indice de bonne foi, et au pire un aveu d'inattention.

Je m'arrête là volontairement. Qualifier une pratique donnée relève des autorités de protection des données et, en dernier ressort, des tribunaux — pas d'un billet de blog, et certainement pas sur la base d'une source unique. Je n'affirme rien sur la conformité du cas décrit plus haut, et je n'ai pas les éléments pour le faire.

Ce que je peux dire sans risque, en revanche, c'est que la question posée à OpenAI est exactement celle qu'une autorité poserait à n'importe quel éditeur : sur quelle base ce traceur est-il classé ainsi, et que se passe-t-il quand l'utilisateur refuse ? Si vous n'avez pas la réponse écrite pour votre propre site, le problème n'est pas chez OpenAI.

Ce qui se transpose

Quatre questions sur votre propre bandeau

Aucune ne demande de juriste pour commencer

1. De quand date l'inventaire ? Si la réponse est « de la mise en conformité », il a l'âge du bandeau. Entre-temps, vous avez ajouté des choses.

2. Que se passe-t-il vraiment quand on refuse ? Testez-le. Navigation privée, refus de tout sauf le nécessaire, puis ouverture des outils de développement. Comparez la liste obtenue avec celle que votre bandeau annonce comme « strictement nécessaires ». L'écart est l'information.

3. Qui a décidé des catégories ? Si c'est le prestataire, sur quelle base ? S'il a recopié la documentation des éditeurs tiers, quand l'a-t-il relue pour la dernière fois ?

4. Y a-t-il un SameSite=None dans vos « nécessaires » ? Ce n'est pas une preuve en soi, mais c'est un signal : un cookie strictement nécessaire au fonctionnement d'un site n'a en général aucune raison d'être envoyé depuis un autre site.

La quatrième question est celle qui remonte le plus de choses, et elle se pose sans connaître le droit. C'est une caractéristique technique lisible dans un navigateur, opposable en réunion, et qui ouvre la discussion sur les trois autres.

Il y a une ironie, pour finir, qu'il serait dommage de ne pas relever. Le débat sur l'IA et la vie privée se concentre sur ce que les modèles font des données qu'on leur confie — c'est le sujet qu'on a traité ici à propos des obligations de transparence. Pendant ce temps, le mécanisme décrit dans cet article n'a rien à voir avec l'IA : c'est un cookie tiers, une technique de 1994, et une case cochée dans un tableau de configuration.

Les problèmes les plus banals restent les plus efficaces, et ce sont ceux qu'on arrête de regarder.

Sources, consultées le 21 septembre 2026. Source unique pour la partie factuelle sur le cookie : analyse technique publiée le 20 septembre 2026 par Buchodi's Threat Intel — nom et domaine du cookie, durée d'un an, attributs SameSite=None et Secure, liaison au compte connecté, classification déclarée en cookie d'analyse, observation sur douze sites commerciaux, 932 jetons décodés dont 736 rattachés à un compte, divulgation à OpenAI le 14 septembre 2026 et teneur de la réponse du support. Je n'ai pas reproduit cette analyse et je n'ai trouvé aucune confirmation indépendante à la date d'écriture : tout ce qui précède est rapporté comme constat de chercheur, pas comme fait établi. OpenAI n'a, à ma connaissance, ni confirmé ni contesté publiquement ces éléments. La description du principe de finalité dans le cadre européen est une formulation générale de ma part et ne constitue pas un avis juridique ; aucune appréciation de conformité n'est portée ici, ni sur le cas décrit ni sur aucun autre. Les quatre questions de la fin sont les miennes.

Quand avez-vous relu l'inventaire de vos cookies ?

Le test prend dix minutes : navigation privée, refus de tout, et comparaison entre ce qui reste et ce que le bandeau annonce.

Demander un premier échange