Consentement multiappareil : éviter les raccourcis

Vous pouvez proposer des préférences cookies liées au compte et applicables sur plusieurs appareils. Vous ne pouvez pas transformer silencieusement un accord donné sur un navigateur en autorisation pour tous les appareils du client. Le projet doit expliquer cette portée, recueillir un choix adapté et propager aussi le refus et le retrait.

Le premier arbitrage consiste à délimiter le service et les environnements couverts. Ensuite viennent la migration des choix existants, leur application technique et la preuve. Copier un champ « consentement : oui » dans le compte ne règle aucune de ces trois questions.

Ce que permet le dispositif multiappareil

La CNIL a publié le 16 janvier 2026 ses recommandations finales sur le consentement multi-terminaux. Ce mécanisme facultatif rattache les choix au compte pour un site ou une application et les applique aux environnements authentifiés. Il exige une information préalable et une portée identique pour accepter, refuser et retirer son consentement. La CNIL recommande aussi un rappel adapté lors du rattachement d’un nouvel appareil : présentation officielle.

Cette possibilité ne crée pas un passeport publicitaire valable sur toutes les marques d’un groupe. Un même identifiant de connexion peut donner accès à des services ayant des responsables, destinataires et finalités différents. Le projet de CMP multisites demande alors une analyse distincte.

Le vocabulaire commercial peut également tromper : deux navigateurs sur un ordinateur peuvent conserver des états différents. Une application et le navigateur du téléphone ne partagent pas nécessairement leurs réglages. L’inventaire doit donc décrire les environnements réellement reliés au compte, pas seulement compter les appareils vendus ou déclarés par le client.

Le compte ne dispense pas du consentement aux traceurs

L’Art. 82 de la loi Informatique et Libertés encadre les lectures et écritures dans le terminal. En dehors de ses exceptions, l’utilisateur doit recevoir l’information requise et consentir. Les exceptions concernent la communication électronique et les opérations strictement nécessaires au service expressément demandé, selon les conditions du texte.

Se connecter à son espace client n’est donc pas, par cette seule action, un accord pour la publicité personnalisée. Le service doit distinguer les opérations nécessaires à la connexion, celles qui gèrent les préférences et celles qui exploitent le comportement à des fins commerciales. Une même donnée technique ne doit pas être présentée comme exclusivement fonctionnelle si elle sert aussi une finalité publicitaire.

Le consentement doit être libre, spécifique, éclairé et univoque : Art. 4(11) du RGPD. Le responsable doit pouvoir le démontrer et permettre son retrait aussi simplement qu’il a été donné, Art. 7(1) et (3). Le changement d’architecture n’efface pas ces exigences.

Préparer la migration sans réécrire l’histoire

La section 7.6 de la recommandation consolidée prévoit un nouveau recueil lors du passage au multi-terminaux : un ancien accord local ne couvrait pas les autres terminaux lorsque l’utilisateur n’avait pas été informé de cette portée. Sa section 7.4 précise aussi que les choix authentifiés ne doivent pas modifier ceux préalablement enregistrés hors connexion.

Concrètement, séparez trois informations : ce que la personne avait choisi, le périmètre alors présenté et le nouveau choix éventuel. Le dossier de migration doit conserver la possibilité de les distinguer. Modifier le libellé de la notice dans la base sans nouvelle action ne transforme pas l’ancien événement en accord plus large.

Une fiche de passage peut indiquer : « Choix local enregistré le 3 septembre ; information limitée à ce navigateur ; compte créé auparavant ; aucun accord multiappareil établi. » L’état du compte demeure alors distinct du choix local. Le projet peut conserver les fonctions nécessaires et présenter une demande appropriée ; il ne doit pas appliquer l’ancien “oui” aux autres environnements dans l’attente d’une réponse.

Un ancien refus mérite la même attention. La migration ne doit pas profiter du changement technique pour réactiver les traceurs. Elle doit conserver la signification du choix dans son périmètre, puis permettre à la personne d’exprimer les préférences du compte avec une information claire.

Spécification renseignée : un compte, trois environnements

Voici un exemple fictif de conception, sans logiciel réellement testé. Le site Atelier Rive prévoit des préférences liées au compte A17. Les environnements sont le navigateur personnel de l’ordinateur, le navigateur du téléphone et celui d’une tablette partagée. Le projet ne couvre aucun autre site ni application.

L’équipe retient trois états distincts pour chaque finalité : accord établi, refus ou retrait enregistré, et choix non établi. Elle conserve séparément l’état local hors connexion et celui du compte. Ces états sont une proposition d’organisation ; leurs noms ne constituent pas un format réglementaire.

L’équipe doit aussi décider comment résoudre une contradiction entre un choix local récent et celui du compte. Il existe plusieurs modalités envisagées par la CNIL ; le produit doit annoncer et appliquer celle qu’il retient. Le guide sur la connexion après un refus de cookies détaille cette transition. La spécification présente ne suppose pas qu’un “oui” ancien l’emporte toujours.

Écrire une information qui décrit vraiment la portée

Une première couche pourrait indiquer, pour ce projet : « Vos choix concernant les traceurs de ce site seront associés à votre compte et appliqués lorsque vous l’utilisez connecté sur vos autres appareils. Vous pouvez les modifier depuis “Mes préférences”. » Ce texte original est un extrait à adapter et compléter ; il ne décrit ni les finalités ni les destinataires à lui seul.

Présentez cette portée avant le choix, avec les finalités concernées et les possibilités de refus. Le libellé du bouton ne suffit pas si l’explication est enfouie ailleurs. Après rattachement d’un environnement, le message doit correspondre à l’action réellement effectuée : préférence reprise, modifiée ou contradiction à résoudre.

Évitez « vos préférences sont synchronisées partout » si certains environnements ne sont pas couverts. Une formulation exacte peut expliquer que les choix concernent l’utilisation authentifiée du même site et distinguer les usages hors connexion. Le support client doit disposer de cette même description pour répondre sans promettre une maîtrise technique inexistante.

Faire du retrait une opération suivie

Le retrait sur le téléphone ne doit pas se limiter à changer un écran. Dans l’architecture A17, le service qui conserve les choix doit rendre la nouvelle version disponible aux composants qui autorisent les opérations. Les sessions déjà ouvertes, les copies intermédiaires et les environnements qui se reconnectent font partie de cette analyse.

Le cahier de recette proposé contient quatre parcours : acceptation informée, refus initial, retrait après acceptation, puis retour d’un environnement temporairement déconnecté du service de préférences. Pour chacun, relevez l’état affiché et les opérations réellement déclenchées. Le témoin utile est l’absence des opérations soumises au choix lorsqu’elles ne sont plus autorisées, pas seulement la valeur d’un champ.

Si une ancienne copie d’accord réactive des envois après le retrait, conservez les fonctions du service qui peuvent fonctionner licitement et suspendez le mécanisme comportemental concerné. Corrigez la propagation avant sa remise en service. Une clause demandant au client de refaire son retrait sur chaque appareil ne résout pas une promesse de retrait valable pour tout le compte.

Aucun délai technique uniforme n’est inventé ici. L’organisation doit concevoir et contrôler un mécanisme permettant de respecter effectivement les choix. Si la version applicable ne peut pas être déterminée, elle ne doit pas assimiler cette incertitude à une nouvelle acceptation. La conception doit expliquer ce comportement et prévoir le retour à un état connu.

Prouver le choix sans constituer un historique publicitaire supplémentaire

Pour A17, le dossier peut conserver une référence du compte, l’événement, sa date, les finalités, la portée et la version de l’information. Le lien avec les paramètres réellement appliqués permet d’expliquer ce que l’événement autorisait. Un historique complet des pages consultées n’est pas nécessaire, par principe, pour prouver ce choix.

L’Art. 5(1)(c) et (e) exige de limiter données et conservation aux besoins. L’Art. 7(1) exige la démonstration du consentement, sans imposer une adresse IP pour chaque cas : principes et preuve. Le guide de la preuve du consentement aide à organiser les justificatifs et leurs accès.

La CNIL recommande, section 7.5, un identifiant technique à la place d’un identifiant contenant en clair une adresse électronique ou un nom transmis à la CMP. Cette substitution ne rend pas automatiquement les données anonymes. L’identifiant reste personnel lorsqu’il permet le rapprochement avec un utilisateur.

La fonction de gestion des choix ne doit pas être réutilisée discrètement pour reconstituer sa navigation publicitaire. Décrivez les instructions du prestataire, ses accès et le sort des traces. Si le compte est supprimé, examinez séparément les préférences devenues inutiles et les preuves dont une conservation reste justifiée, avec un accès limité.

Ce qu’il faut retenir

• Délimitez le service, les environnements et l’utilisation authentifiée.
• Un ancien accord local ne s’étend pas silencieusement au compte.
• Refus et retrait doivent avoir une portée équivalente à l’acceptation.
• Contrôlez les opérations effectives, y compris après une reconnexion.

FAQ

Faut-il proposer un consentement multiappareil ?

Non. Le mécanisme est facultatif. Si vous conservez des choix locaux, décrivez et respectez leur périmètre sans promettre une synchronisation globale que le service ne fournit pas.

Peut-on laisser des préférences différentes par appareil ?

La section 7.7 de la recommandation l’encourage comme bonne pratique. L’interface doit rendre compréhensible cette possibilité et ses effets ; ajouter une option visuelle sans application technique ne suffit pas.

Un compte partagé représente-t-il nécessairement une seule personne ?

Non. Il peut être utilisé par plusieurs personnes. Le concepteur doit tenir compte de cette limite pour l’information et les parcours, notamment sur un terminal partagé ; une connexion n’autorise pas à attribuer automatiquement tous les usages à une seule personne physique.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.