L’identifiant publicitaire est-il une donnée personnelle ?

Oui. C’est un identifiant en ligne rattaché à un appareil, donc à son détenteur, et il est conçu pour suivre la même personne d’une application à l’autre. Le RGPD cite les identifiants en ligne parmi les éléments qui rendent identifiable, et sa lecture sur le téléphone relève en France de l’article 82 de la loi Informatique et Libertés.

Faut-il un consentement pour lire l’identifiant publicitaire ?

Dès lors qu’il sert au pistage publicitaire, oui : ce n’est pas une opération strictement nécessaire au service demandé. L’autorisation technique du système ne vaut pas consentement, et la recommandation de la CNIL le dit expressément. Elle précise en outre que l’éditeur et le fournisseur de SDK sont responsables conjoints de cet accès.

Que signifie un identifiant composé uniquement de zéros ?

Que l’utilisateur a supprimé son identifiant dans les réglages Android, ou que l’application, dès lors qu’elle cible Android 13 ou une version ultérieure, ne déclare pas la permission AD_ID. Dans les deux cas la valeur zéro est un refus lisible : la remplacer par un autre identifiant ou par une empreinte de l’appareil revient à contourner le choix exprimé, et enfreint aussi le règlement de Google Play.

Que faut-il utiliser pour la mesure d’audience ou l’antifraude ?

Google renvoie vers l’ID du groupe d’applications (app set ID), qui est rattaché à l’ensemble des applications publiées sous le même compte développeur Google Play. Deux applications du même éditeur partagent la valeur sur un appareil donné, mais un tiers ne la retrouve pas ailleurs. Il se réinitialise notamment après treize mois sans appel de l’API ou après désinstallation de la dernière application du groupe.

Mon application peut-elle demander AD_ID sans que je l’aie décidé ?

Oui. Google documente le cas : si un SDK déclare la permission AD_ID dans le manifeste de sa bibliothèque, elle est fusionnée par défaut avec le manifeste de votre application, même sans déclaration explicite de votre part. La seule façon de savoir ce que votre application déclare vraiment est d’examiner le paquet publié.

Comment savoir qui reçoit l’identifiant de mon application ?

En observant le trafic réel : l’identifiant apparaît dans les requêtes sortantes, avec le domaine qui le reçoit et l’instant de l’envoi. Un audit relève ces envois acteur par acteur et les situe par rapport au consentement.

Tous les articles

L’identifiant publicitaire Android : une donnée personnelle, pas un réglage technique

L’identifiant publicitaire Android (GAID, AAID ou AD_ID) est une chaîne unique attribuée à l’appareil par les services Google Play, lue à l’identique par toutes les applications du téléphone, réinitialisable par l’utilisateur, et c’est une donnée personnelle au sens du RGPD. Sa lecture à des fins publicitaires suppose un consentement, la permission technique n’en tenant pas lieu ; un identifiant remplacé par des zéros est un refus lisible, que compenser par un autre identifiant persistant enfreint à la fois le RGPD et le règlement de Google Play.

26 août 2026 · 8 min de lectureMis à jour le 11 septembre 2026

Rares sont les applications Android qui connaissent le nom de leurs utilisateurs. Toutes, en revanche, peuvent demander à lire une même chaîne de trente-six caractères : l’identifiant publicitaire. GAID, AAID ou AD_ID selon la documentation qui le nomme, il est la clé de voûte de la publicité mobile, l’une des données qui quittent le plus souvent un téléphone.

Un identifiant conçu pour être partagé

L’identifiant publicitaire est attribué à l’appareil par les services Google Play. Sa propriété décisive tient en une phrase : toutes les applications du téléphone lisent la même valeur. C’est sa raison d’être, permettre aux acteurs publicitaires de recouper ce que chaque application sait d’une même personne, pour cibler, plafonner, attribuer une installation à une campagne.

La CNIL en donne la meilleure explication, dans une note de sa recommandation applications mobiles : « À l’inverse des cookies, dont la valeur est fixée indépendamment pour chaque tiers publicitaire, ces identifiants sont générés aléatoirement lors du premier démarrage du téléphone et sont les mêmes pour tous les tiers. Ils facilitent ainsi la mise en relation entre ces tiers des données collectées relatives à un individu. » Et elle ajoute l’effet de levier : « Couplé à un environnement authentifié, ils permettent également de relier ces données à une activité sur d’autres terminaux informatiques de l’utilisateur depuis lesquels celui-ci s’est également authentifié. »

L’utilisateur peut le réinitialiser ou le supprimer dans les réglages. Mais tant qu’il est là, chaque SDK qui le lit l’envoie accompagné du reste : modèle du téléphone, version du système, adresse IP. Un identifiant stable, partagé entre applications et adossé à un profil, voilà exactement ce que le pistage demande.

Une donnée personnelle au sens plein

Le RGPD cite les identifiants en ligne parmi les éléments qui rendent une personne identifiable (considérant 30), et celui-ci est précisément conçu pour suivre la même personne d’une application à l’autre : l’identifiant publicitaire est une donnée personnelle.

En France, sa lecture sur le téléphone relève en outre de l’article 82 de la loi Informatique et Libertés, comme toute lecture ou écriture d’informations sur un terminal. La recommandation de la CNIL en tire la conséquence : hors stricte nécessité du service, ce geste suppose un consentement, et l’autorisation technique accordée par le système n’en tient pas lieu.

Le texte va plus loin : il règle la question de savoir qui répond de cette lecture quand elle est faite par un SDK. Dans l’exemple qu’il détaille, « l’éditeur et le fournisseur de SDK sont responsables conjoints du traitement s’agissant de l’accès à l’identifiant publicitaire (qui constitue une opération de lecture et/ou écriture au sens de l’article 82 de la loi Informatique et Libertés) par le fournisseur de SDK car ils participent de manière conjointe à la détermination des finalités et des moyens du traitement concernant cette opération ». La responsabilité ne se délègue pas avec la ligne de code.

Ce que Google a déjà verrouillé

La plateforme elle-même a resserré l’accès, en deux temps.

Fin 2021 d’abord : « l’identifiant publicitaire sera supprimé lorsqu’un utilisateur le supprimera dans les paramètres Android. Toute personne qui tentera d’accéder à cet identifiant recevra alors une chaîne de zéros. » Le déploiement a visé les appareils Android 12 dès la fin 2021, puis « tous les appareils compatibles avec Google Play à partir du 1er avril 2022 ».

Android 13 ensuite : une application qui cible le niveau d’API 33 ou supérieur doit déclarer une permission dédiée, com.google.android.gms.permission.AD_ID, dans son manifeste. Sans elle, écrit la documentation Android, l’identifiant publicitaire est automatiquement retiré et remplacé par une chaîne de zéros.

Ce que l’application reçoit quand elle demande l’identifiant publicitaire (règles Google Play et documentation Android)

valeur réelle     l’utilisateur n’a rien changé
                  ET l’application déclare la permission AD_ID

chaîne de zéros   l’utilisateur a supprimé l’identifiant dans les
                  réglages Android
                  OU l’application cible Android 13 ou plus sans
                  déclarer la permission AD_ID

La permission que vous n’avez pas écrite

Détail qui compte pour un éditeur : cette permission peut arriver dans votre application sans qu’aucun développeur de votre équipe ne l’ait écrite. Google le documente noir sur blanc, à propos de ses propres kits : « Si votre application utilise ces SDK comme dépendances, l’autorisation AD_ID du fichier manifeste de la bibliothèque du SDK sera fusionnée par défaut avec le fichier manifeste de votre application, même si vous ne déclarez pas explicitement l’autorisation dans le fichier manifeste principal de votre application. »

Autrement dit, ce que votre application embarque décide de ce qu’elle demande, permissions comprises. La seule façon de savoir ce que votre manifeste déclare vraiment est de regarder le paquet publié, pas le code source.

Pour les applications destinées aux enfants, c’est zéro tout court

La politique Familles de Google Play ne s’embarrasse pas de nuances, et sa liste mérite d’être lue en entier : « Les applications qui ciblent uniquement les enfants ne doivent transmettre aucun identifiant publicitaire Android (AAID), numéro de série de SIM, numéro de série de la build, BSSID, adresse MAC, SSID, code IMEI ni IMSI. » Elle ajoute que ces applications « ne doivent pas demander d’autorisation AD_ID » lorsqu’elles ciblent le niveau d’API 33 ou supérieur.

C’est une interdiction de transmission, pas une obligation de consentement : aucune bannière ne la lève. Elle rejoint le front ouvert par la CNIL sur les applications utilisées par des mineurs, où plusieurs éditeurs ont été mis en demeure en 2025.

Le zéro n’est pas un blanc-seing

Une suite de zéros à la place de l’identifiant est un refus lisible, pas un vide à combler. La tentation existe pourtant : compenser la perte par un autre identifiant de l’appareil, ou par une empreinte composée du modèle, de la langue et de la résolution d’écran.

C’est précisément ce type de contournement que les autorités sanctionnent. Le 29 décembre 2022, la CNIL a infligé 3 millions d’euros d’amende à une société de développement de jeux mobiles, sur le terrain du consentement aux traceurs. Sa recommandation applications mobiles cite cette décision, la n° SAN-2022-026, parmi les précédents où « l’usage non conforme d’identifiants du mobile » a valu une sanction, aux côtés d’une autre visant un magasin d’applications le même jour.

Google dit la même chose depuis l’autre bout de la chaîne : son règlement « exige que, pour la publicité, toutes les mises à jour et les nouvelles applications importées sur Google Play utilisent l’identifiant publicitaire (si disponible sur l’appareil) à la place de tout autre identifiant d’appareil », et « les applications utilisant un identifiant persistant différent de l’identifiant publicitaire peuvent recevoir un avertissement pour non-respect des règles ». Le contournement se paie donc deux fois, côté autorité et côté magasin.

La règle de lecture est simple : le choix exprimé vaut pour la finalité, pas pour la technique employée. Changer d’identifiant ne change pas le refus.

Ce qu’il faut utiliser à la place, et pour quoi

Tous les usages d’un identifiant ne sont pas publicitaires. Pour la mesure d’audience interne ou la lutte contre la fraude, Google renvoie vers un autre mécanisme : « Pour les cas d’utilisation essentiels non liés aux annonces, comme les analyses et la prévention de la fraude, utilisez l’ID du groupe d’applications. »

Cet identifiant de groupe d’applications a une portée volontairement étroite. Pour les applications installées depuis Google Play, il est « rattaché à l’ensemble des applications publiées sous le même compte développeur Google Play » : deux applications du même éditeur installées sur un téléphone partagent la même valeur, et un tiers ne la retrouve pas ailleurs. Il se réinitialise si l’API n’a pas été appelée pendant plus de treize mois, si la dernière application du groupe est désinstallée, ou lors d’une remise à zéro de l’appareil.

La différence avec l’identifiant publicitaire est exactement celle que décrit la CNIL : l’un est le même pour tous les tiers et permet de recouper, l’autre s’arrête à la frontière de votre catalogue. Cela ne dispense pas d’une base légale, mais cela change la nature du traitement, et donc l’analyse de nécessité.

Comment il part sans que personne l’ait décidé

Le scénario le plus fréquent n’est pas la décision d’un éditeur, c’est une configuration par défaut. Google le documente : « Par défaut, le SDK Firebase collecte les identifiants des appareils mobiles (par exemple l’identifiant publicitaire Android et l’Advertising Identifier pour iOS) et utilise des technologies similaires aux cookies. » Et plus loin : « Par défaut, sur Android, le SDK collecte l’identifiant publicitaire. »

Ce n’est pas une hypothèse. En septembre 2026, l’autorité espagnole a rendu publique une décision qui déclare une infraction au principe de minimisation contre une administration dont l’application envoyait à un tiers trente-six catégories de données, identifiant publicitaire compris, à cause d’un module de notifications mal configuré. L’éditeur l’ignorait, et le dossier tient sur des captures de trafic : c’est l’affaire du SDK de notifications.

Ce qu’un éditeur doit savoir répondre

Quatre questions résument le sujet, et ce sont celles d’un contrôle. Votre manifeste publié déclare-t-il la permission AD_ID, et si oui, à cause de quel SDK ? L’identifiant part-il avant que le consentement soit donné ? Vers quels acteurs part-il, sachant que chacun peut le recouper avec ce qu’il collecte ailleurs ? Et après un refus, la valeur à zéro est-elle respectée, ou un autre identifiant prend-il le relais ?

Aucune de ces réponses ne se lit dans une documentation. Elles s’observent dans le trafic réel de l’application, requête par requête, horodatage à l’appui. C’est exactement ce qu’établit un audit de conformité RGPD de votre application mobile : la liste des acteurs qui reçoivent l’identifiant, et le moment de chaque envoi par rapport au choix de l’utilisateur, donnée par donnée.

Sources

Chaque constat de cet article renvoie à l’un de ces documents.

Google PlayIdentifiant publicitaire : chaîne de zéros, permission AD_ID, fusion des manifestesAide Console Play, Google
Android 13Behavior changes : Apps targeting Android 13 or higherDocumentation Android Developers, Google
AndroidApp set ID : portée, réinitialisation, usages hors publicitéDocumentation Android Developers, Google
Google PlayRègles Google Play pour les contenus familiaux : identifiants dont la transmission est interditeAide Console Play, Google
GoogleData collection : identifiants collectés par défaut par le SDK Google Analytics pour FirebaseDocumentation Firebase, centre d’aide
CNIL ’25Recommandation relative aux applications mobiles, version modifiéeCNIL, délibération n° 2025-024 du 27 mars 2025
CNIL ’22Sanction du 29 décembre 2022, société de développement de jeux mobiles, 3 millions d’euros (délibération n° SAN-2022-026)CNIL, liste des sanctions prononcées
RGPDRèglement (UE) 2016/679, considérant 30 : les identifiants en ligneJournal officiel de l’Union européenne

Questions fréquentes

L’identifiant publicitaire est-il une donnée personnelle ?: Oui. C’est un identifiant en ligne rattaché à un appareil, donc à son détenteur, et il est conçu pour suivre la même personne d’une application à l’autre. Le RGPD cite les identifiants en ligne parmi les éléments qui rendent identifiable, et sa lecture sur le téléphone relève en France de l’article 82 de la loi Informatique et Libertés.
Faut-il un consentement pour lire l’identifiant publicitaire ?: Dès lors qu’il sert au pistage publicitaire, oui : ce n’est pas une opération strictement nécessaire au service demandé. L’autorisation technique du système ne vaut pas consentement, et la recommandation de la CNIL le dit expressément. Elle précise en outre que l’éditeur et le fournisseur de SDK sont responsables conjoints de cet accès.
Que signifie un identifiant composé uniquement de zéros ?: Que l’utilisateur a supprimé son identifiant dans les réglages Android, ou que l’application, dès lors qu’elle cible Android 13 ou une version ultérieure, ne déclare pas la permission AD_ID. Dans les deux cas la valeur zéro est un refus lisible : la remplacer par un autre identifiant ou par une empreinte de l’appareil revient à contourner le choix exprimé, et enfreint aussi le règlement de Google Play.
Que faut-il utiliser pour la mesure d’audience ou l’antifraude ?: Google renvoie vers l’ID du groupe d’applications (app set ID), qui est rattaché à l’ensemble des applications publiées sous le même compte développeur Google Play. Deux applications du même éditeur partagent la valeur sur un appareil donné, mais un tiers ne la retrouve pas ailleurs. Il se réinitialise notamment après treize mois sans appel de l’API ou après désinstallation de la dernière application du groupe.
Mon application peut-elle demander AD_ID sans que je l’aie décidé ?: Oui. Google documente le cas : si un SDK déclare la permission AD_ID dans le manifeste de sa bibliothèque, elle est fusionnée par défaut avec le manifeste de votre application, même sans déclaration explicite de votre part. La seule façon de savoir ce que votre application déclare vraiment est d’examiner le paquet publié.
Comment savoir qui reçoit l’identifiant de mon application ?: En observant le trafic réel : l’identifiant apparaît dans les requêtes sortantes, avec le domaine qui le reçoit et l’instant de l’envoi. Un audit relève ces envois acteur par acteur et les situe par rapport au consentement.