Un SDK de notifications a envoyé 36 catégories de données pendant quatre ans. L’éditeur l’ignorait.

Le signalement n’est pas venu d’un audit

Tout commence le 17 novembre 2023 par la réclamation d’un particulier. Il a installé l’application sur son téléphone et, rapporte la décision, « après avoir utilisé l’application, il a constaté qu’elle envoie à [une société tierce] 47 informations différentes sur son appareil (localisation, coordonnées GPS, cookies, état du micro, adresse IP, etc.) ». Il joint une capture d’écran.

Cette capture ne vient pas d’un outil d’expert. Elle vient d’une fonction de protection intégrée à un navigateur grand public, qui détecte les envois d’une application vers des sociétés de suivi connues et les bloque. L’autorité a refait la manipulation le 4 avril 2024, sur la version 1.8.13 de l’application : la fonction relève « 150 tentatives de pistage » causées par l’application.

Les inspecteurs ont ensuite fait ce que fait un analyste. La décision nomme leur second outil, une application libre qui « permet de suivre, d’analyser et de bloquer les connexions effectuées par d’autres applications » et « d’exporter un fichier PCAP du trafic ». Ils ont installé plusieurs versions successives sur un appareil et relevé, requête par requête, les paramètres transmis, en décodant les corps des appels.

Retenez le chemin : ni revue de code, ni relecture de contrat, ni questionnaire au fournisseur. Un téléphone, du trafic capturé, une comparaison version par version. C’était aussi la seule méthode capable d’établir les faits, puisque l’éditeur lui-même ne les connaissait pas.

Un module de notifications, et une option restée active

La Direction générale de la circulation répond le 23 janvier 2024, et sa réponse est la partie la plus utile du dossier. L’application intègre le module d’un tiers « pour la gestion des notifications push envoyées sur le terminal mobile de l’utilisateur ». Puis vient la phrase qui explique tout : « De plus, ce module intègre une fonctionnalité qui envoie des données d’usage depuis le terminal mobile. » Et la date : « cet envoi se produit depuis le 13 janvier 2020 ».

L’éditeur précise que les deux choses sont distinctes. Le module est nécessaire pour recevoir les notifications, mais « il est optionnel que ce module envoie les données d’usage ». Optionnel, donc, et actif pendant quatre ans.

La liste de ces données figure dans la décision, telle que l’éditeur l’a lui-même produite dans un rapport technique du 10 janvier 2024. Trente-six catégories, qui vont de l’anodin au sensible sans transition : nom, prénom, adresse électronique, sexe, code postal, ville, pays, coordonnées GPS, identifiant unique, identifiant publicitaire Android, cookies, adresse IP locale, opérateur de réseau, marque et modèle de l’appareil, nom de l’appareil, niveau de batterie, état de charge, état des écouteurs, volume du système, orientation de l’appareil, stockage interne disponible.

Ce que le module fait, et que sa documentation dit déjà

La mécanique se vérifie sans sortir de la documentation du fournisseur. La décision ne nomme pas la plateforme, mais elle cite les paramètres relevés dans le trafic, dont un identifiant d’installation et un identifiant d’instance d’application, ainsi que les tableaux de bord consultés. Ce sont ceux de Firebase, la plateforme de Google, que la presse espagnole a identifiée.

Premier point : le service de notifications ne vient jamais seul. Sa documentation indique qu’il dépend du module d’installations, « inclus de façon transitive dans votre application », et que ce dernier « génère et collecte un identifiant par installation (FID) ». Intégrer les notifications revient donc à écrire et relire un identifiant sur le terminal, avant toute décision de l’éditeur.

Second point : la brique de mesure d’audience, quand elle est présente, collecte par défaut. Google l’écrit sans détour : « 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. » La désactivation existe et elle est documentée, mais c’est un geste à poser, pas un état initial.

Ces deux propriétés expliquent le dossier mieux que n’importe quelle intention. L’éditeur voulait des notifications. La configuration par défaut lui a donné une mesure d’audience complète, avec un identifiant publicitaire et des identifiants persistants ; et, dans cette application précise, le nom et l’adresse électronique de la personne, que la décision relève dans la liste fournie par l’éditeur. Sur l’identifiant publicitaire, la logique est celle que nous avons décrite ailleurs : c’est une donnée personnelle, pas un réglage technique.

Le registre des traitements disait le contraire

Le 27 mars 2024, l’autorité regarde la politique de confidentialité et la fiche du registre des activités de traitement. La fiche existe, elle est publique, elle nomme le responsable et la base légale, le consentement. Elle décrit les données : « nom, prénom, identifiant, date de naissance, date de délivrance du permis, observations, plaque, données du véhicule, points ». Ni coordonnées GPS, ni identifiant publicitaire, ni adresse électronique.

Puis viennent les deux lignes que la capture de trafic contredit : « Catégories de destinataires : aucune communication de données n’est prévue. » et « Transferts internationaux : aucun transfert international de données n’est prévu. »

Sur le second point, l’autorité est allée lire les conditions contractuelles du fournisseur, qui prévoient que « les données du client peuvent être traitées dans tout pays où [le fournisseur] ou ses sous-traitants ultérieurs disposent d’installations ». Elle note n’avoir trouvé, dans les conditions des deux services utilisés, aucun engagement de localisation des données.

Un registre de ce genre n’est pas faux par négligence de rédaction. Il est faux parce qu’il décrit ce que l’éditeur a voulu, et que personne n’a comparé cette description à ce qui sortait du téléphone. C’est le même écart que celui de la section Sécurité des données du Play Store, et il se mesure de la même façon : en regardant où atterrissent réellement les données.

Quatre versions, quatre captures

Alerté, l’éditeur agit vite. La version 1.11.5 est publiée le 11 janvier 2024 pour supprimer l’envoi. C’est à partir de là que le dossier devient utile à quiconque publie une application.

Fin mai et début juin 2024, l’autorité capture le trafic de quatre versions successives, installées l’une après l’autre. Voici ce qu’elle relève encore à chaque étape. La décision écrit « des données comme » : la liste n’est pas exhaustive, c’est ce qui a été observé.

1.8.13   modèle, pays, build, langue, version de l’app, fuseau horaire,
         user-agent, adresse IP, identifiant d’instance, code pays+opérateur

1.11.4   modèle, pays, build, langue, version de l’app, user-agent,
         adresse IP, identifiant d’installation, code pays+opérateur

1.11.5   pays, build, langue, version de l’app, fuseau horaire, user-agent,
         adresse IP, identifiant d’installation, identifiant d’instance

1.12.12  build, user-agent, adresse IP, identifiant d’installation

Le correctif n’a pas tout arrêté

La version publiée quatre mois après le correctif envoyait donc toujours l’adresse IP, l’agent utilisateur et l’identifiant d’installation. L’autorité en tire une conclusion sans détour : « Même dans la dernière version réalisée postérieurement à la demande de cette agence, des données personnelles comme l’adresse IP seraient capturées. »

Sur l’adresse IP, elle rappelle sa propre doctrine, un avis de 2003 : « les adresses IP, tant fixes que dynamiques, quel que soit le type d’accès, sont considérées comme des données à caractère personnel ». L’éditeur avait plaidé qu’une adresse IP est une donnée de transport, inévitable dès qu’un terminal parle à un serveur. L’argument n’a pas prospéré.

Un autre paramètre disparaît en cours de route et mérite d’être nommé, parce qu’on ne le cherche jamais : un code qui, écrit la décision, « désigne le pays auquel appartient l’abonné ainsi que l’opérateur concret de l’abonné ». Il ne figure dans aucune liste de permissions, il ne déclenche aucune boîte de dialogue, et il sortait à chaque appel.

La leçon est mécanique, pas morale : un correctif est une hypothèse jusqu’à ce qu’on le mesure sur le fil, version par version. C’est exactement l’objet du suivi de conformité plutôt que de l’audit ponctuel.

Ce qu’on ne peut pas rappeler

Reste le problème que la décision traite le plus sérieusement et dont on parle le moins : les versions déjà installées.

L’éditeur l’écrit lui-même : « La DGT ne peut pas effectuer de corrections sur des versions publiées dans le passé. Elle peut seulement publier une nouvelle version qui intègre les corrections. » Et : « Les canaux officiels de distribution ne permettent pas l’invalidation ou la révocation de versions obsolètes déjà installées sur les terminaux des utilisateurs. »

Il dispose d’un garde-fou, ajouté en novembre 2020 : une fonction qui empêche l’application de fonctionner en dessous d’une version minimale et invite l’utilisateur à la mettre à jour. Il constate en revanche, sans pouvoir l’empêcher, que d’anciennes versions restent téléchargeables hors des magasins officiels. Ce sont d’ailleurs celles que l’autorité a installées pour ses tests.

Les tableaux de bord du fournisseur donnent l’ordre de grandeur du sursis. Pour les versions antérieures au correctif, la console affichait « 2,3 M » utilisateurs en Espagne et « 7,6 mille » au Maroc ; pour les versions postérieures, 25 utilisateurs. Entre le 17 février et le 16 mars 2025, plus d’un an après le correctif, l’événement de premier lancement s’est encore déclenché 2 009 fois pour 2 007 utilisateurs, toutes versions confondues.

La mesure finalement proposée par l’éditeur dit bien où se situe le problème : supprimer le projet chez le fournisseur, pour que les anciennes versions continuent d’écrire vers une installation qui n’existe plus. On ne rappelle pas une version. On peut seulement fermer la porte à l’arrivée, et savoir laquelle des versions en circulation envoie quoi, ce qui suppose de les suivre une par une.

Ce que l’autorité a retenu

Le manquement retenu est l’article 5.1.c du RGPD, la minimisation : les données doivent être « adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées ». Le raisonnement tient en deux temps : « L’application de la DGT est fondée à collecter les données nécessaires à sa fonctionnalité. Toutefois, en l’espèce, il se produit un excès dans les données collectées par cette application. »

L’autorité vise ensuite nommément ce qui restait : « les différentes versions de l’application collecteraient plus de données que strictement nécessaire, comme c’est le cas de l’adresse IP, du pays ou de l’opérateur auquel les personnes concernées sont abonnées ».

Deux points méritent d’être notés, parce qu’ils valent partout en Europe. Le premier : l’ignorance n’efface rien. L’éditeur a reconnu le manquement en précisant que « ce manquement n’a pas été conscient de la part de la DGT » et qu’il découlait « comme effet collatéral, de l’usage d’une fonctionnalité légitime et habituelle dans le développement d’applications mobiles ». L’infraction est déclarée malgré tout. Le second : corriger n’efface pas davantage. La reconnaissance et les mesures prises, écrit l’autorité, « ne privent pas d’effet la violation de l’article 5.1.c du RGPD pour les faits constatés jusqu’à l’adoption desdites mesures ».

Aucune amende n’a été prononcée, et c’est le seul élément du dossier qui ne se transpose pas : le droit espagnol interdit d’infliger une amende à un organisme public et prévoit à la place une déclaration d’infraction, notifiée à l’organisme et communiquée au Défenseur du peuple. Pour un éditeur privé, le même manquement relève de l’article 83.5 du RGPD, dont le plafond est de 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu.

En France, la CNIL a déjà écrit la méthode

Rien de ce dossier n’est propre à l’Espagne, et la recommandation de la CNIL sur les applications mobiles en couvre chaque étape.

Sur la configuration par défaut, elle s’adresse au fournisseur de SDK : « Des configurations par défaut des SDK qui respectent ce principe doivent être proposées, y compris dans les exemples de configuration proposés dans ses documentations. » Elle nomme même la donnée du dossier espagnol : « la collecte ou la conservation d’identifiants de terminaux, de réseau (adresse IP, matériels réseau environnants) pouvant être reliés à des individus doivent être évités si l’usage du SDK ne le nécessite pas ».

Sur le couplage des fonctionnalités, elle demande que le fournisseur conçoive son service « de sorte à ce que ses fonctionnalités puissent être décorrélées les unes des autres ». Et elle ferme l’échappatoire la plus courante : « Ces recommandations s’appliquent également aux SDK fournis par les fournisseurs d’OS ou à ceux qui sont proposés par défaut dans les documentations d’Apple et Google ». Un module estampillé par la plateforme n’est pas dispensé d’examen : c’est l’angle mort du fournisseur, et ce que la CNIL attend de lui.

Sur la vérification, enfin, la recommandation décrit exactement ce qu’a fait l’autorité espagnole : « Une méthode d’audit par interception des communications réseaux peut être envisagée. » Elle en donne la grille, cinq points, dont un qui décrit le dossier mot pour mot : « le SDK ne collecte pas plus de données que défini dans le registre fourni ». Et elle ajoute la clause qui transforme un audit en suivi : « En cas d’évolution du SDK, ces analyses peuvent être mises à jour. »

Côté éditeur, à propos cette fois des outils de recueil du consentement, elle va jusqu’au dispositif : mettre en place « (ou engager un prestataire tiers à cette fin) un banc de tests », « équiper un téléphone de test ou un émulateur pour l’interception des communications réseaux », puis tester l’application. Le reste de la grille est dans la recommandation applications mobiles, et la responsabilité qui va avec dans ce que votre application embarque vous engage.

Les questions auxquelles seule l’exécution répond

Le dossier espagnol se résume à une série de questions qu’aucun document ne tranche.

Quels tiers l’application contacte-t-elle au premier lancement, avant toute action de l’utilisateur ? Quels identifiants persistants sortent, et lesquels ont été écrits sur le terminal par un module que personne n’a paramétré ? La liste des données réellement transmises correspond-elle à celle du registre ? L’adresse IP, le code d’opérateur, l’identifiant d’installation partent-ils encore après le correctif ? Et la version d’avant, celle qui reste installée sur des milliers de téléphones, envoie-t-elle toujours ?

On y répond en exécutant l’application sur un vrai téléphone et en lisant son trafic. C’est ce que fait Skanopy : la cartographie des acteurs tiers réellement contactés, chaque constat adossé à la requête datée qui le prouve, et l’analyse rejouée à chaque version publiée. Le rapport établit les faits ; leur qualification reste au DPO. C’est la matière d’un audit RGPD d’application mobile.

Sources

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

1. AEPD ’26Résolution PS/00287/2025, dossier EXP202317928 : déclaration d’infraction à l’article 5.1.c du RGPDAgencia Española de Protección de Datos, décision rendue publique le 9 septembre 2026
2. RGPDRèglement (UE) 2016/679, article 5.1.c : minimisation des donnéesJournal officiel de l’Union européenne
3. LOPDGDDLoi organique 3/2018, article 77 : régime applicable aux organismes publics espagnolsBoletín Oficial del Estado
4. GoogleData collection : identifiants collectés par défaut par le SDK Google Analytics pour FirebaseDocumentation Firebase, centre d’aide
5. GooglePrepare for Google Play’s data disclosure requirements : données collectées par Cloud Messaging et par le module d’installationsDocumentation Firebase pour Android
6. GoogleConfigure Analytics data collection and usage : désactivation de la collecteDocumentation Firebase
7. CNIL ’25Recommandation relative aux applications mobiles, version modifiéeCNIL, délibération n° 2025-024 du 27 mars 2025
8. CNIL ’25Applications mobiles : comment intégrer des SDK et respecter la vie privée des utilisateursCNIL, 21 janvier 2025