Confidentialité des jeux Android en 2026 : quelles données les SDK publicitaires et analytiques peuvent-ils collecter ?

Un jeu Android peut sembler constituer un produit unique, mais son fichier d’installation peut contenir plusieurs kits de développement tiers, généralement appelés SDK. Ces composants prêts à l’emploi assurent la diffusion des publicités, la mesure de l’audience, le signalement des plantages, les achats, la connexion aux comptes, les notifications et d’autres fonctions qu’un studio mettrait beaucoup plus de temps à développer lui-même. Le principal enjeu de confidentialité tient au fait que chaque composant peut transmettre son propre ensemble de données, parfois dès le lancement du jeu. En 2026, la question essentielle ne consiste donc pas seulement à savoir quelles informations le joueur saisit volontairement, mais aussi quelles données le jeu et ses SDK intégrés envoient en arrière-plan, dans quel but et avec quels contrôles. Les outils publicitaires et analytiques peuvent traiter des identifiants, des historiques d’interaction, des caractéristiques techniques, des événements d’achat et une localisation estimée. La collecte exacte dépend de la version du SDK, de ses réglages, de la région du joueur et de ses choix de consentement. Une évaluation sérieuse doit donc porter sur la version réellement distribuée du jeu plutôt que sur une déclaration de confidentialité générale.

Pourquoi la collecte de données par les SDK est importante dans les jeux Android

Les SDK sont courants parce qu’ils permettent aux développeurs d’ajouter des fonctions pratiques sans devoir tout créer à partir de zéro. Un SDK publicitaire peut demander et afficher une annonce, mesurer une impression, détecter un clic et indiquer si le joueur a ensuite installé une application ou effectué un achat. Un SDK analytique peut compter les sessions, suivre la progression dans les niveaux et montrer à quel moment les joueurs quittent un tutoriel. Un composant de signalement des erreurs peut transmettre l’état technique du jeu lorsqu’il se ferme de manière inattendue. Ces usages peuvent être légitimes et utiles, mais les flux de données ne sont pas toujours visibles pour la personne qui utilise le téléphone. Le développeur choisit les SDK à intégrer et leurs réglages, tandis que le fournisseur du SDK détermine une grande partie de leur fonctionnement par défaut. Un même jeu peut également utiliser un système de médiation dans lequel un outil publicitaire sollicite plusieurs réseaux, ce qui peut augmenter le nombre de destinataires des données.

La collecte de données ne provoque pas systématiquement l’affichage d’une demande d’autorisation Android. L’accès au microphone, aux contacts ou à la localisation précise nécessite généralement une autorisation visible, mais de nombreux signaux utiles peuvent être transmis sans cette étape. Un SDK peut recevoir l’adresse IP de l’appareil lorsqu’il communique avec un serveur, enregistrer la version du jeu et le modèle du téléphone, détecter les pressions sur l’écran, créer un identifiant d’installation ou mesurer la durée d’une session. L’absence de fenêtre d’autorisation ne signifie donc pas qu’aucune information ne quitte l’appareil. Les autorisations Android concernent l’accès à certaines fonctions protégées, tandis que la politique de confidentialité et la section Sécurité des données de Google Play doivent décrire une collecte plus large. Les joueurs devraient consulter ces deux sources, et les développeurs devraient tester les communications réelles du jeu, car l’examen du manifeste ne permet pas d’identifier tous les événements, identifiants ou échanges générés pendant une partie.

La responsabilité reste celle de l’éditeur du jeu, même lorsque le code a été écrit par une entreprise tierce. Google Play demande aux développeurs de déclarer dans la section Sécurité des données les informations traitées par leurs bibliothèques et leurs SDK, de maintenir cette déclaration à jour et de veiller à sa cohérence avec la politique de confidentialité. Le même principe existe dans le droit relatif aux données personnelles. Selon le RGPD, les données doivent être utilisées de manière licite, transparente et uniquement dans la mesure nécessaire à une finalité définie. Au Royaume-Uni, l’Information Commissioner’s Office a confirmé dans ses recommandations d’avril 2026 que les règles concernant le stockage ou l’accès aux informations présentes sur un appareil s’appliquent également aux applications mobiles et aux SDK intégrés. Un consentement préalable peut être nécessaire lorsqu’aucune exception ne s’applique, notamment pour le suivi publicitaire. Un studio ne peut pas écarter sa responsabilité en affirmant qu’une entreprise publicitaire ou analytique a collecté les informations de manière indépendante : il doit comprendre le fonctionnement du composant qu’il a ajouté au jeu.

Les identifiants qui relient les événements à un appareil ou à une installation

L’identifiant publicitaire Android, souvent appelé AAID ou GAID, est l’un des identifiants les plus connus pour la publicité, la mesure des campagnes et la prévention de la fraude. Il est conçu pour pouvoir être réinitialisé et ne correspond pas au numéro de série matériel du téléphone. Android permet aux utilisateurs de le réinitialiser ou de le supprimer dans les paramètres publicitaires, et les applications doivent respecter le choix concernant les annonces personnalisées. Les jeux ciblant Android 13 ou une version ultérieure doivent également disposer de l’autorisation AD_ID correspondante pour qu’un SDK puisse obtenir cet identifiant de manière habituelle. Les règles de Google Play interdisent de contourner une réinitialisation en associant le nouvel identifiant publicitaire à un ancien profil. Elles interdisent également de le relier à des identifiants matériels permanents à des fins publicitaires ou analytiques. Son association avec des données de compte permettant d’identifier directement une personne peut aussi entraîner de graves problèmes de conformité en l’absence de justification valable et clairement expliquée.

Les jeux et leurs SDK peuvent utiliser d’autres identifiants lorsque l’identifiant publicitaire n’est pas disponible ou n’est pas adapté. Un identifiant d’installation Firebase correspond à une installation précise d’une application et change généralement lorsque le jeu est désinstallé puis réinstallé. Un App Set ID peut aider un même développeur à analyser l’activité entre ses propres applications, mais il n’est pas destiné à la publicité. Les entreprises publicitaires et les services d’attribution peuvent également créer leurs propres identifiants d’installation ou d’utilisateur. Ces valeurs peuvent sembler anonymes parce qu’elles prennent la forme de longues chaînes de caractères plutôt que de noms, mais elles peuvent tout de même constituer des données personnelles lorsqu’elles permettent d’isoler un comportement, de le suivre dans le temps ou de l’associer à un compte. L’impact dépend de leur portée et de leur durée : un code de session temporaire présente moins de risques qu’un identifiant conservé pendant plusieurs mois et transmis à plusieurs entreprises.

Des caractéristiques techniques peuvent contribuer à reconnaître un appareil, même lorsqu’aucune d’elles n’est présentée comme un identifiant. Les connexions aux serveurs exposent une adresse IP, qui peut indiquer une zone géographique générale. Les SDK peuvent également recevoir la version du système d’exploitation, le fabricant et le modèle de l’appareil, la langue, le fuseau horaire, les dimensions de l’écran, le type de réseau, la version du jeu et la source d’installation. Une seule de ces informations peut correspondre à des millions d’appareils, mais leur combinaison détaillée peut rendre un téléphone plus facile à distinguer. C’est pourquoi la création d’une empreinte numérique est sensible : elle vise à reconnaître un appareil grâce à plusieurs caractéristiques plutôt qu’au moyen d’un identifiant réinitialisable unique. Android limite l’accès aux identifiants matériels tels que l’IMEI et les adresses MAC pour les applications ordinaires, et Google recommande aux développeurs d’utiliser l’identifiant le moins intrusif et le plus facilement réinitialisable permettant d’atteindre l’objectif prévu.

Ce que les SDK publicitaires et analytiques peuvent enregistrer

Les SDK publicitaires ont besoin de certaines informations pour sélectionner une annonce, la diffuser, compter les résultats et limiter les abus. La déclaration publiée par Google en juillet 2026 pour son SDK publicitaire mobile de nouvelle génération mentionne notamment le traitement automatique de l’adresse IP, des lancements d’application, des pressions sur l’écran, des vues de vidéos, des données de diagnostic et d’identifiants tels que l’identifiant publicitaire Android et l’App Set ID. L’adresse IP peut servir à estimer une localisation générale. Les données de diagnostic peuvent comprendre l’heure de lancement, les blocages et la consommation d’énergie. Les informations d’interaction peuvent montrer qu’une annonce a été affichée, combien de temps une vidéo a été regardée, si elle a été ignorée et si le joueur a appuyé dessus. Certaines données sont utilisées pour la facturation ou la détection de fraude plutôt que pour la personnalisation. La désactivation des annonces personnalisées n’interrompt donc pas nécessairement toutes les transmissions liées à la publicité. Les annonces contextuelles nécessitent encore des informations relatives à la diffusion, à la mesure des impressions et à la sécurité de base.

D’autres outils publicitaires spécialisés dans les jeux publient des déclarations comparables. Unity Ads indique par exemple que son SDK Android peut collecter une localisation approximative, des identifiants personnels, un historique d’achats, des interactions avec l’application, des données de diagnostic et des identifiants d’appareil à des fins comprenant la publicité, l’analyse, le fonctionnement du service et la prévention de la fraude. Les champs exacts dépendent de la version et de la configuration. La médiation ajoute une couche supplémentaire : le SDK principal sélectionne une offre parmi plusieurs sources publicitaires, et chaque réseau connecté peut exécuter son propre code ou recevoir une demande contenant des informations sur l’appareil et la publicité. Les développeurs doivent donc examiner chaque adaptateur actif, et pas seulement le principal outil de médiation. Les joueurs peuvent voir le nom d’une seule entreprise publicitaire alors que plusieurs intervenants participent aux échanges en arrière-plan. Une politique de confidentialité claire doit préciser les catégories de destinataires et expliquer comment une personne peut s’opposer au traitement, retirer son consentement ou demander la suppression de ses données lorsque ces droits s’appliquent.

Les SDK analytiques se concentrent sur la manière dont le jeu est utilisé. Les événements automatiques courants comprennent le premier lancement, le début d’une session, le temps passé au premier plan, la catégorie de l’appareil, le pays, la langue et la version de l’application. Les développeurs peuvent ensuite ajouter des événements personnalisés tels que la fin d’un tutoriel, le début ou l’échec d’un niveau, l’obtention de monnaie virtuelle, la visite d’une boutique, le visionnage d’une publicité ou la réalisation d’un achat. Ces données peuvent révéler des habitudes de jeu détaillées même lorsqu’elles ne contiennent aucun nom réel. Un événement mal conçu peut transmettre plus d’informations que prévu : le nom d’un niveau peut contenir un texte libre, une propriété utilisateur peut inclure une adresse électronique ou un événement d’achat peut être associé à un identifiant de compte. Un SDK peut traiter de nombreux champs personnalisés uniquement parce que le développeur les lui transmet. Les réglages sont donc aussi importants que la liste de données collectées par défaut par le fournisseur. Une analyse utile doit répondre à une question précise sur le jeu plutôt que d’enregistrer indéfiniment toutes les actions possibles.

Données de plantage, de performances et d’attribution

Les SDK de signalement des plantages recueillent un ensemble d’informations différent, mais néanmoins significatif. Firebase Crashlytics enregistre automatiquement les traces d’exécution, l’état pertinent de l’application, les métadonnées de l’appareil et un identifiant unique d’installation lorsqu’un plantage se produit. Ces éléments aident les ingénieurs à reproduire les erreurs affectant certaines versions d’Android ou certains modèles de téléphone. Les développeurs peuvent également ajouter des clés personnalisées, des journaux, des erreurs non fatales et des identifiants d’utilisateur. Cette souplesse crée un risque fréquent : un journal destiné au débogage peut contenir le nom ou l’adresse électronique d’un joueur, un message de discussion, un jeton d’accès, une référence de paiement ou une action précise réalisée dans le jeu. Les rapports de plantage doivent être considérés comme des données de production, et non comme de simples notes privées réservées aux ingénieurs. Les équipes doivent définir les champs autorisés, retirer les informations sensibles avant leur enregistrement, limiter l’accès aux rapports et fixer une durée de conservation correspondant au temps réellement nécessaire pour diagnostiquer puis vérifier la correction d’un problème.

Les outils de suivi des performances peuvent enregistrer la durée de démarrage, les retards d’affichage ou de réponse, la latence des requêtes réseau, l’utilisation du processeur et de la mémoire, le type de connexion et les caractéristiques de l’appareil. Ces informations permettent de comprendre pourquoi un jeu fonctionne correctement sur un téléphone mais ralentit sur un autre. Elles peuvent aussi révéler davantage de données que prévu si les développeurs placent des informations personnelles dans les adresses de requêtes, les noms de traces personnalisées ou les attributs de diagnostic. Par exemple, une adresse de serveur contenant un numéro de compte dans ses paramètres peut se retrouver dans un rapport de performances. Une méthode plus sûre consiste à utiliser des noms de routes neutres et des références internes qui ne permettent pas d’identifier directement un joueur. Les données de performances présentent généralement moins de risques que la publicité comportementale, mais elles doivent tout de même répondre à une finalité définie, être accessibles uniquement aux personnes autorisées, bénéficier d’une durée de conservation adaptée et faire l’objet d’une déclaration exacte lorsqu’elles sont transmises hors de l’appareil.

Les SDK d’attribution cherchent à relier une publicité ou une campagne à une installation puis aux activités ultérieures. Ils peuvent traiter l’identifiant publicitaire, l’adresse IP, l’heure d’installation, la version de l’application, les informations de parrainage, les libellés de campagne et certains événements réalisés dans le jeu. La mesure des revenus peut ajouter la valeur des achats, la devise utilisée et les revenus publicitaires. Certains fournisseurs proposent des commandes permettant de retarder le démarrage du SDK jusqu’au recueil du consentement, de désactiver les identifiants publicitaires, d’arrêter la transmission ou d’anonymiser les identifiants après leur réception. Ces options ne sont efficaces que si elles sont correctement mises en œuvre avant le début de la collecte. Un écran de consentement affiché après le démarrage d’un SDK d’attribution n’annule pas la requête initiale. Les studios doivent également vérifier les intégrations entre serveurs, car la suppression d’un SDK du jeu n’interrompt pas automatiquement les données envoyées par les tableaux de gestion publicitaire, les fonctions en ligne ou les anciennes versions du jeu encore installées.

Comment les développeurs et les joueurs peuvent limiter le suivi inutile

Un audit de confidentialité doit commencer par un inventaire complet de la version distribuée du jeu. Les développeurs doivent recenser les SDK directs, les adaptateurs de médiation et les dépendances intégrées par d’autres bibliothèques. Pour chaque composant, l’équipe doit noter la version utilisée, les catégories de données, les destinataires, les finalités, la collecte activée par défaut, les fonctions facultatives, les règles de conservation et les possibilités de suppression. L’index des SDK de Google Play et les déclarations des fournisseurs constituent de bons points de départ, mais la documentation doit être comparée au fonctionnement réel du jeu. L’analyse du trafic réseau lors du premier lancement, d’une partie normale, du visionnage d’une annonce, d’un achat, d’une déconnexion et d’un retrait du consentement peut révéler des communications absentes des documents. Cet audit doit être répété après les mises à jour, car les données collectées peuvent changer d’une version à l’autre. Un inventaire précis facilite également la suppression d’un outil inutilisé dont le code continue malgré tout à se lancer et à transmettre des informations.

Une bonne configuration permet de réduire les risques sans supprimer toutes les fonctions de mesure utiles. Les SDK compatibles peuvent rester désactivés jusqu’à ce que le joueur ait exprimé le choix requis. Le consentement doit être suffisamment précis pour distinguer les fonctions nécessaires, l’analyse et la publicité personnalisée, au lieu d’imposer une seule réponse pour plusieurs finalités sans rapport direct. Un refus doit être transmis à chaque adaptateur publicitaire, et des annonces contextuelles peuvent être utilisées lorsque cela convient. Les développeurs peuvent désactiver la collecte de l’identifiant publicitaire, éviter les identifiants reliés au compte, réduire les périodes de conservation, limiter les paramètres des événements et empêcher l’enregistrement de données personnelles dans les journaux. La mesure des achats doit utiliser uniquement les champs nécessaires à la comptabilité ou à l’évaluation des campagnes. Un menu de confidentialité accessible doit permettre aux joueurs de modifier leurs choix, de demander la suppression de leurs données et de comprendre quels traitements continuent pour la sécurité, la prévention de la fraude ou le fonctionnement essentiel du jeu.

Les jeux destinés aux enfants exigent des décisions plus strictes. Les identifiants publicitaires, le profilage comportemental et le partage étendu avec des tiers peuvent être interdits ou fortement limités selon l’âge de l’enfant, son lieu de résidence et les règles du magasin d’applications concerné. Les SDK proposent souvent des réglages pour les contenus destinés aux enfants ou soumis à des restrictions d’âge, mais le développeur doit les activer correctement et vérifier que chaque entreprise publicitaire connectée reçoit le même signal. Les tests doivent comparer l’état du consentement, le trafic réseau, la politique de confidentialité et la déclaration fournie à Google Play. Les développeurs ne doivent pas supposer que l’ancien projet Privacy Sandbox on Android réglera ces questions : la documentation officielle indique que cette initiative a été abandonnée le 17 octobre 2025. En 2026, la protection pratique repose toujours sur la réduction des données, l’utilisation d’identifiants réinitialisables, une gestion correcte du consentement, des déclarations honnêtes et un contrôle attentif de chaque SDK intégré au jeu.

Contrôles pratiques de confidentialité en 2026

Avant d’installer un jeu, les joueurs peuvent obtenir de nombreuses informations en consultant à la fois sa section Sécurité des données sur Google Play et sa politique de confidentialité. La déclaration du magasin doit indiquer si le jeu collecte ou partage la localisation, des informations personnelles, des données financières, l’activité dans l’application, des diagnostics et des identifiants d’appareil, ainsi que les finalités annoncées. Il s’agit d’un résumé fourni par le développeur et non d’un audit indépendant. Des formulations vagues ou des différences avec la politique de confidentialité doivent donc inciter à la prudence. Une déclaration mondiale peut aussi décrire le fonctionnement le plus large parmi plusieurs versions ou régions, ce qui signifie que certaines collectes mentionnées ne concernent pas nécessairement tous les joueurs. La liste des autorisations reste utile pour repérer l’accès à des fonctions sensibles du téléphone, mais elle ne montre pas les données ordinaires envoyées aux serveurs, telles que les adresses IP, les événements de session ou les mesures publicitaires.

Les réglages Android fournissent plusieurs contrôles pratiques. Un joueur peut examiner les autorisations accordées au jeu, retirer celles qui ne sont pas nécessaires, gérer ses choix relatifs à la publicité et réinitialiser ou supprimer l’identifiant publicitaire lorsque son appareil propose cette option. L’effacement des données du jeu ou sa réinstallation peut réinitialiser certains identifiants liés à l’installation, même si les informations associées à un compte en ligne peuvent rester sur les serveurs du développeur. Dans le jeu, les utilisateurs devraient rechercher des réglages distincts pour l’analyse et les annonces personnalisées, ainsi qu’un moyen de retirer leur consentement. La suppression du compte et celle des données ne correspondent pas toujours à la même opération : la politique de confidentialité doit expliquer les deux procédures. Le blocage d’une autorisation peut également désactiver une fonction sans interrompre les analyses qui n’en dépendent pas. Les commandes intégrées au jeu et les paramètres Android sont donc plus efficaces lorsqu’ils sont utilisés ensemble.

Parmi les signes préoccupants figurent un écran publicitaire ou analytique sans possibilité de refus, une politique de confidentialité qui ne précise aucune catégorie de données, un jeu demandant des autorisations sans rapport avec ses fonctions ou l’affirmation que toutes les informations sont anonymes alors que des identifiants persistants sont utilisés. Un trafic continu en arrière-plan après un refus mérite également une vérification, même si certaines connexions peuvent rester nécessaires pour les sauvegardes, la sécurité, le mode multijoueur ou les annonces contextuelles. La collecte de données n’est pas automatiquement nuisible : les rapports de plantage peuvent résoudre des problèmes graves, les analyses peuvent améliorer un tutoriel mal compris et les contrôles antifraude peuvent protéger les achats. Le critère raisonnable consiste à vérifier si chaque donnée répond à une finalité claire, reste limitée à ce qui est nécessaire, est conservée pendant une durée expliquée et fait l’objet de contrôles réels. En 2026, la fiabilité d’un jeu Android en matière de confidentialité dépend moins de déclarations rassurantes que d’un comportement vérifiable sur l’ensemble de la chaîne des SDK.