Consentement multi-terminaux : ce que la recommandation CNIL change vraiment pour le tracking RGPD

Le 16 janvier 2026, la CNIL a publié ses recommandations finales sur le consentement multi-terminaux, aussi appelé cross-device consent. L’objectif est clair : aider les acteurs numériques à recueillir un consentement conforme au RGPD lorsqu’un utilisateur navigue sur plusieurs appareils connectés à son compte.

L’idée paraît simple : un utilisateur donne ou refuse son consentement aux cookies une fois, puis ce choix est appliqué sur ses autres appareils connectés au même compte.

Ordinateur. Mobile. Tablette. Application. TV connectée.

Sur le papier, c’est propre. Moins de bandeaux. Moins de fatigue utilisateur. Une préférence rattachée à un compte plutôt qu’à un navigateur isolé.

Mais dès qu’on descend dans la réalité technique, le sujet devient beaucoup plus délicat.

Parce que pour appliquer un consentement sur plusieurs terminaux, il faut d’abord savoir qu’il s’agit du même utilisateur. Et dans la majorité des cas sérieux, cette reconnaissance passe par un compte utilisateur, donc par une authentification.

C’est précisément le point central de la recommandation CNIL : le consentement multi-terminaux vise les univers authentifiés. Pas le web anonyme. Pas le visiteur inconnu qu’on essaierait de recoller entre son mobile et son ordinateur avec une bidouille technique. La recommandation CNIL précise que le dispositif concerne les sites web et applications mobiles dans un univers authentifié, avec des choix rattachés au compte utilisateur.

Pour les équipes marketing, data, analytics et conformité, le sujet dépasse largement la bannière cookies. On parle de tracking RGPD, de CMP, de Consent Mode, de tracking cross-device, de preuve du consentement, de gouvernance des traceurs et d’audit de conformité tracking.

C’est exactement le type de sujet que nous traitons dans notre agence : à la croisée de la conformité RGPD, de la qualité de la donnée et de l’architecture technique de collecte. Parce qu’un bandeau peut être juridiquement rassurant en apparence, tout en laissant passer des tags mal contrôlés dans Google Tag Manager, GA4, Matomo, Piwik PRO, Meta Ads ou LinkedIn Ads.

Et c’est souvent là que les vrais problèmes commencent.

De quoi parle-t-on exactement ?

Le consentement multi-terminaux consiste à rattacher les choix cookies et traceurs d’un utilisateur à son compte, au lieu de les rattacher uniquement à un terminal, un navigateur ou une application.

Exemple simple.

Un utilisateur se connecte à son compte sur une application mobile. Il refuse les cookies publicitaires et accepte uniquement les traceurs de mesure d’audience. Plus tard, il se connecte au même compte depuis son ordinateur. Le site peut appliquer automatiquement les mêmes choix, sans lui redemander de tout paramétrer.

L’objectif est légitime : éviter de faire répéter quinze fois le même choix à une personne déjà identifiée.

Mais la CNIL fixe un cadre strict : ce mécanisme est facultatif. Il ne devient pas une obligation. Et il ne dispense jamais de recueillir un consentement valable lorsque des traceurs soumis au consentement sont utilisés.

Autrement dit : le cross-device ne sert pas à contourner le consentement. Il sert à synchroniser un choix déjà exprimé dans un cadre conforme.

Ce que la CNIL autorise vraiment

La CNIL ne dit pas : “vous pouvez suivre un utilisateur partout pour deviner que son mobile, son ordinateur et sa télévision lui appartiennent”.

Elle dit plutôt : dans un univers où l’utilisateur est authentifié, ses choix peuvent être appliqués à l’ensemble des environnements depuis lesquels il accède au même service.

La nuance est énorme.

Le périmètre couvre les terminaux, les navigateurs et les interfaces applicatives utilisés pour accéder à un site ou une application donnée. Les choix sont alors rattachés au compte utilisateur.

Mais la CNIL pose plusieurs conditions.

Première condition : l’acceptation, le refus et le retrait doivent avoir la même portée. Si je peux accepter en une fois pour tous mes terminaux, je dois pouvoir refuser ou retirer mon consentement en une fois pour tous mes terminaux. Pas de piège. Pas d’acceptation globale magique avec un retrait terminal par terminal.

Deuxième condition : l’utilisateur doit être informé clairement, avant de faire son choix, que ce choix sera appliqué à tous les appareils connectés à son compte. La CNIL précise que cette information peut être donnée dès le premier niveau d’information de l’interface de consentement.

Troisième condition : lors de la connexion depuis un nouveau terminal, la CNIL recommande d’afficher un message temporaire rappelant que les choix associés au compte ont été appliqués ou modifiés.

Quatrième condition : il faut prévoir le cas où l’utilisateur a déjà exprimé un choix local avant de se connecter, puis se connecte ensuite à son compte où d’autres préférences sont enregistrées.

Et là, la CNIL admet deux logiques possibles :

• donner priorité au dernier choix exprimé avant connexion ;
• donner priorité aux préférences déjà enregistrées dans le compte.

Les deux options peuvent être défendables. Mais il faut choisir, documenter et expliquer clairement la logique retenue.

Dans un audit de conformité tracking, ce point est essentiel. Il ne suffit pas de dire “notre CMP gère le cross-device”. Il faut vérifier quelle règle est réellement appliquée, à quel moment, avec quelle preuve, et avec quel impact sur les tags.

Le vrai sujet : la clé de jointure

Le consentement multi-terminaux repose sur une évidence technique parfois oubliée dans les beaux schémas de conformité : il faut une clé de rapprochement fiable.

Sans clé de jointure, pas de synchronisation sérieuse.

Cette clé peut être un identifiant interne utilisateur, un identifiant de compte, un email haché ou tout autre identifiant technique maîtrisé. Mais elle doit permettre de rattacher plusieurs environnements au même compte.

Et c’est là que beaucoup de cas d’usage s’effondrent.

Pour qu’un choix exprimé sur desktop s’applique ensuite sur mobile, il faut que l’utilisateur se connecte sur desktop, puis se connecte aussi sur mobile.

Or, dans beaucoup de parcours web, le bandeau cookies apparaît avant la connexion. Parfois il est bloquant. Parfois il masque partiellement l’interface. Parfois il force l’utilisateur à choisir avant même qu’il puisse accéder au bouton de connexion.

Résultat : le mécanisme censé éviter la répétition du consentement arrive parfois trop tard.

La séquence réelle ressemble souvent à ça :

C’est pourquoi le consentement multi-terminaux est pertinent surtout pour les environnements où la connexion est naturelle, fréquente et précoce : banque, assurance, plateformes SaaS, médias abonnés, services de streaming, e-commerce avec espace client très utilisé, applications mobiles connectées.

Sur un site vitrine, un blog, un site B2B classique ou un e-commerce où la majorité du trafic reste anonyme, l’intérêt peut être très limité.

C’est aussi pour cela qu’un audit sérieux ne doit jamais s’arrêter à la CMP. Lorsque nous analysons un dispositif de tracking RGPD, nous regardons l’ensemble de la chaîne : CMP, dataLayer, Google Tag Manager, Consent Mode, tags publicitaires, analytics, server-side tracking, stockage de la preuve et documentation technique.

Le consentement n’est pas une case à cocher. C’est une donnée opérationnelle qui doit circuler proprement dans tout le système de mesure.

Ce que la CNIL exclut implicitement : le cross-device sauvage

La CNIL a choisi de ne pas étendre sa recommandation aux univers non authentifiés. Et c’est une bonne chose.

Pourquoi ? Parce que reconnaître une même personne sur plusieurs terminaux sans login implique vite des techniques intrusives : fingerprinting, rapprochement probabiliste, signaux réseau, device graph, identifiants indirects, corrélations comportementales.

Bref, tout ce qu’on ne veut pas voir déguisé en “amélioration de l’expérience utilisateur”.

La synthèse de la consultation publique rappelle d’ailleurs que plusieurs contributeurs ont soulevé la question du périmètre, notamment des univers non authentifiés, mais la recommandation finale reste centrée sur les univers logués.

L’adresse IP, par exemple, n’est pas une preuve sérieuse d’identité. Une famille peut partager la même IP. Une entreprise entière peut sortir avec la même IP publique. Des utilisateurs de VPN peuvent partager des adresses. Une box, une TV connectée et plusieurs mobiles peuvent appartenir à des personnes différentes du même foyer.

Donc non, une IP commune ne permet pas proprement d’affirmer : “c’est le même utilisateur, appliquons-lui le même consentement”.

Le consentement multi-terminaux utile et défendable repose d’abord sur l’authentification. Tout le reste devient vite glissant.

Le paradoxe du bandeau bloquant

Le point le plus délicat est là : pour savoir si un utilisateur a déjà des préférences rattachées à son compte, il faut parfois l’identifier avant de lui afficher le bandeau.

Mais si le bandeau est bloquant, l’utilisateur doit choisir avant de se connecter.

C’est le serpent qui se mord la queue.

Plusieurs stratégies existent, mais aucune n’est magique.

Option 1 : afficher la CMP avant connexion

C’est la logique classique.

L’utilisateur arrive, voit la CMP, exprime un choix local, puis se connecte ensuite. Une fois connecté, le site doit gérer l’éventuelle contradiction entre le choix local et les préférences du compte.

C’est robuste juridiquement, mais peu fluide.

Option 2 : permettre la connexion sans forcer l’interaction CMP immédiate

Cela peut permettre d’appliquer plus vite les préférences du compte. Mais il faut être très prudent : tant que le consentement n’est pas connu, les traceurs soumis au consentement ne doivent pas être déclenchés.

La FAQ de la CNIL rappelle qu’aucun traceur non essentiel ne peut être déposé sans consentement préalable de la personne concernée.

Cela suppose une architecture propre :

• tags marketing bloqués par défaut ;
• consentement initial en mode refus ou attente ;
• mise à jour après récupération des préférences ;
• journalisation de la décision appliquée ;
• contrôle strict des déclencheurs GTM ou Matomo Tag Manager ;
• vérification du comportement réel dans le navigateur.

C’est faisable. Mais cela demande une vraie coordination entre CMP, front-end, tag manager, analytics, CRM et équipe juridique.

Option 3 : appliquer les préférences du compte uniquement après authentification

C’est souvent le compromis le plus réaliste.

Avant connexion, on applique le choix local du terminal ou on affiche la CMP. Après connexion, on applique les préférences rattachées au compte, en informant l’utilisateur.

C’est moins élégant que la promesse marketing du “consentement une fois partout”, mais c’est souvent plus honnête techniquement.

Ce que cela change pour le tracking RGPD

Pour les équipes data, analytics et tag management, cette recommandation impose une discipline beaucoup plus forte.

On ne parle pas seulement d’ajouter une option dans une CMP.

Il faut savoir :

• où sont stockées les préférences ;
• comment elles sont synchronisées ;
• quel identifiant relie les terminaux au compte ;
• à quel moment les préférences sont lues ;
• quels tags sont bloqués avant décision ;
• quel choix prévaut en cas de conflit ;
• comment l’utilisateur peut modifier ou retirer son consentement ;
• comment la preuve du consentement est conservée.

Dans un setup GA4, Google Ads, Meta Ads, LinkedIn Ads, Matomo, Piwik PRO ou server-side GTM, ce point devient critique. Le consentement n’est plus seulement un état local dans le navigateur. Il peut devenir une préférence utilisateur centralisée, propagée dans plusieurs environnements.

Cela veut dire qu’un simple plan de taggage ne suffit plus. Il faut un vrai schéma de gouvernance du consentement.

Dans un audit GTM, GA4 ou CMP, le consentement multi-terminaux ajoute une nouvelle question : le consentement appliqué est-il local, serveur, rattaché au compte, ou synchronisé entre plusieurs terminaux ?

Ce n’est pas un détail technique. C’est une condition de conformité et de qualité de donnée.

Un tracking cross-device mal conçu peut créer trois problèmes :

• des tags déclenchés avant consentement valable ;
• des préférences utilisateur contradictoires entre compte, navigateur et application ;
• une donnée analytics difficile à expliquer en cas d’audit.

Et quand la donnée devient inexplicable, elle perd sa valeur.

Ce que j’auditerais avant d’activer le consentement cross-device

Avant d’activer une option de consentement multi-terminaux dans une CMP, je vérifierais au minimum ces points.

C’est exactement le type de sujet qui justifie un audit de conformité tracking. Pas seulement un audit juridique, et pas seulement un audit technique. Il faut les deux.

Le juridique définit les règles. La technique vérifie si elles sont réellement appliquées.

Le vrai travail commence là : ne pas se contenter de lire la recommandation CNIL, mais vérifier comment elle se traduit réellement dans le navigateur, dans les appels réseau, dans le dataLayer, dans GTM, dans GA4, dans les pixels publicitaires, dans les outils analytics et dans les logs de consentement.

Parce que la conformité ne se décrète pas. Elle se teste.

Exemple d’architecture propre

Une architecture sérieuse pourrait ressembler à ceci :

Le point important : les tags ne doivent pas partir “en attendant de savoir”. Le défaut doit être maîtrisé.

Dans Google Tag Manager, cela suppose une gestion stricte du Consent Mode, des déclencheurs conditionnés, des balises marketing bloquées avant signal valide, et idéalement une couche de données claire.

Dans Matomo Tag Manager ou Piwik PRO, même logique : la décision de consentement doit être disponible avant l’exécution des tags concernés.

Dans un contexte server-side, il faut aussi éviter une illusion fréquente : déplacer les requêtes côté serveur ne règle pas le problème du consentement. Le serveur ne donne pas une immunité juridique. Il ne fait que changer l’architecture de collecte.

Un tracking server-side peut être très propre. Il peut aussi devenir une boîte noire très problématique s’il relaie des données sans respecter correctement les préférences utilisateur.

Le piège classique : confondre confort UX et conformité

Le consentement multi-terminaux est souvent vendu avec un argument séduisant : réduire la fatigue du consentement.

C’est vrai. Les bandeaux répétés fatiguent tout le monde. Les utilisateurs, les équipes marketing, les équipes produit, les DPO, les analytics.

Mais la réduction de la friction ne doit pas devenir une réduction du contrôle.

Un bon dispositif doit permettre à l’utilisateur de comprendre :

• que son choix vaut pour plusieurs appareils ;
• quels appareils ou environnements sont concernés ;
• comment modifier son choix ;
• si le choix local ou le choix du compte prévaut ;
• si son refus a exactement la même portée que son acceptation.

Si l’utilisateur accepte globalement mais doit fouiller terminal par terminal pour retirer son accord, le dispositif est déséquilibré.

Et s’il ne comprend pas que son choix mobile s’applique aussi à sa TV connectée, son consentement risque de ne plus être réellement éclairé.

Faut-il activer le consentement multi-terminaux ?

Ma réponse est simple : pas par défaut.

Il faut d’abord vérifier si le cas d’usage existe vraiment.

Avant d’activer une fonctionnalité cross-device dans une CMP, je poserais ces questions :

Si les réponses sont floues, il ne faut pas activer. Pas encore.

Le pire scénario serait d’ajouter une fonctionnalité “privacy avancée” qui complexifie le tracking, perturbe les données, et crée une zone grise de conformité.

Les cas où le dispositif a du sens

Le consentement multi-terminaux peut être pertinent dans plusieurs cas.

1. Plateforme SaaS

L’utilisateur est presque toujours connecté. L’expérience repose sur le compte. Les préférences peuvent être gérées dans un espace personnel.

C’est probablement l’un des cas les plus propres.

2. Média avec abonnement

Un abonné consulte le même média sur mobile, desktop et application. Le rattachement au compte peut réduire la répétition des bandeaux.

Attention toutefois aux visiteurs anonymes, souvent très nombreux.

3. Application mobile avec espace web associé

Par exemple : banque, assurance, énergie, transport, livraison, santé selon le cadre applicable.

L’utilisateur se connecte naturellement dans l’app et sur le web.

4. Service de streaming ou TV connectée

Le multi-device est structurel. Mais il faut traiter finement les profils, les comptes familiaux et les terminaux partagés.

5. E-commerce avec compte client réellement utilisé

Cas intéressant, mais à vérifier. Beaucoup de visiteurs e-commerce naviguent sans se connecter jusqu’au checkout. Le cross-device consent peut alors ne concerner qu’une partie réduite des sessions.

Les cas où je serais très prudent

Je serais beaucoup plus réservé pour :

• les sites vitrines ;
• les blogs ;
• les sites B2B à faible authentification ;
• les e-commerces où la connexion arrive très tard ;
• les sites média très majoritairement anonymes ;
• les dispositifs reposant sur des rapprochements probabilistes ;
• les environnements où plusieurs personnes utilisent le même compte ou terminal.

Dans ces cas, le concept peut être plus beau dans une slide que dans une implémentation réelle.

Ce que les entreprises doivent documenter

Une mise en œuvre sérieuse doit être documentée. Pas dans un fichier oublié au fond d’un Drive. Dans un document exploitable par les équipes produit, data, juridique et technique.

À minima, il faut formaliser :

1. Le périmètre des environnements concernés
   Web, app mobile, TV connectée, navigateur, domaine, sous-domaine, application.
2. Le mode d’identification
   Identifiant interne, compte utilisateur, email haché, autre identifiant technique.
3. Le stockage du consentement
   Local, serveur, CMP, backend, CRM, data warehouse.
4. La règle de priorité
   Choix local avant connexion ou préférence compte.
5. Le comportement avant authentification
   CMP locale, attente, refus par défaut, accès à la connexion.
6. Le comportement après authentification
   Application des préférences, message d’information, mise à jour éventuelle.
7. Le retrait
   Depuis quel écran ? Avec quelle portée ? Avec quel délai ?
8. La preuve
   Horodatage, finalités, version de la CMP, source du choix, terminal, compte, journal d’événement.
9. Les tags concernés
   Analytics, ads, personnalisation, A/B testing, affiliation, pixels sociaux, replay session, emailing tracking si applicable.
10. Les tests
    Scénarios desktop/mobile, connecté/non connecté, acceptation/refus/retrait, conflit local/compte.

Mon analyse : une recommandation utile, mais pas un feu vert technique général

Je trouve la recommandation utile parce qu’elle clarifie enfin un sujet qui existait déjà dans les outils CMP et dans les architectures des grands comptes.

Mais il ne faut pas la lire comme une invitation à généraliser le cross-device consent partout.

La CNIL encadre un cas précis : l’univers authentifié.

Elle ne valide pas le bricolage cross-device en environnement anonyme. Elle ne dit pas que l’IP suffit. Elle ne dit pas que le fingerprinting devient acceptable parce que l’objectif serait de synchroniser un consentement. Elle ne dit pas non plus que tous les sites doivent mettre en place ce mécanisme.

En réalité, cette recommandation va surtout concerner les acteurs qui ont déjà :

• un vrai compte utilisateur ;
• une volumétrie significative d’utilisateurs connectés ;
• une CMP avancée ;
• une architecture consentement côté serveur ;
• une équipe capable de tester et maintenir le dispositif.

Pour beaucoup d’entreprises, le meilleur choix restera de garder une gestion classique, propre, locale, compréhensible, avec un bandeau bien conçu et un retrait facile.

Ce n’est pas moins moderne. C’est parfois simplement plus robuste.

Le cas revient souvent en audit : l’entreprise veut moderniser son tracking, mais la base n’est pas encore fiable. La CMP est installée, mais les tags ne sont pas tous conditionnés. Le Consent Mode est présent, mais mal configuré. Le server-side GTM est déployé, mais sans vraie gouvernance des finalités. GA4 collecte, mais personne ne sait exactement ce qui part avant et après consentement.

Dans ce contexte, ajouter du consentement multi-terminaux sans audit préalable revient à construire un étage supplémentaire sur des fondations incertaines.

La prochaine étape : le consentement multi-propriétés

La CNIL annonce aussi des travaux en 2026 sur le consentement multi-propriétés, souvent appelé cross-domain. Là, le sujet sera encore plus sensible.

Il ne s’agira plus seulement d’appliquer un choix entre plusieurs terminaux d’un même service, mais potentiellement entre plusieurs sites ou médias, notamment au sein d’un même groupe. La CNIL indique que ces travaux viseront à limiter les demandes redondantes, notamment dans les groupes médias ou les univers multi-marques, tout en protégeant la vie privée et la liberté de choix des utilisateurs.

Typiquement : un groupe média avec plusieurs marques, plusieurs domaines, plusieurs applications.

L’enjeu est évident : limiter les demandes répétées.

Mais le risque l’est aussi : créer un consentement trop large, mal compris, appliqué à des environnements que l’utilisateur ne perçoit pas comme un seul et même espace.

Le débat sera probablement plus complexe que le multi-terminaux. Parce que la frontière entre “même service”, “même groupe” et “écosystème publicitaire élargi” peut devenir très floue.

Pour les groupes multi-sites, les réseaux de marques, les médias et les acteurs e-commerce avec plusieurs domaines, ce sera un sujet majeur de gouvernance tracking. Il faudra aligner la CMP, le plan de taggage, les outils analytics, les pixels publicitaires, les règles de consentement et la preuve utilisateur.

Conclusion

Le consentement multi-terminaux est une bonne idée dans un monde idéal : un utilisateur, un compte, plusieurs appareils, un choix clair.

Dans le monde réel, il faut ajouter quelques contraintes :

• tous les utilisateurs ne sont pas connectés ;
• tous les sites n’ont pas de compte ;
• tous les comptes ne sont pas personnels ;
• tous les terminaux ne sont pas individuels ;
• tous les bandeaux ne permettent pas une connexion fluide avant choix ;
• toutes les architectures tag management ne sont pas capables de bloquer proprement les traceurs avant décision.

La recommandation CNIL donne un cadre. Elle ne résout pas l’implémentation.

Pour les entreprises, la bonne approche est donc simple : ne pas activer le cross-device consent parce que la fonctionnalité existe. L’activer uniquement si le parcours utilisateur, l’architecture technique et la gouvernance du consentement le justifient réellement.

Le consentement multi-terminaux peut réduire la friction. Mais mal conçu, il peut surtout déplacer le problème : moins de bandeaux visibles, plus de complexité invisible.

Et en matière de tracking RGPD, ce qui est invisible finit souvent par coûter cher.

Avant d’activer ce type de dispositif, le bon réflexe est simple : auditer. Vérifier. Tester. Documenter.

C’est moins spectaculaire qu’une nouvelle fonctionnalité CMP. Mais c’est ce qui sépare une conformité affichée d’une conformité réellement maîtrisée.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐

• Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

• Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
• Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
• Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.