Auditer une application mobile : aussi essentiel qu’un site web, bien plus difficile

La même loi, désormais contrôlée

Ce qui encadre la lecture et l’écriture d’informations sur un appareil, en France, c’est l’article 82 de la loi Informatique et Libertés. Il ne distingue pas le navigateur de l’application : déposer un identifiant ou lire une donnée sur un téléphone relève des mêmes règles, page web ou application installée.

En septembre 2024, la CNIL a publié sa recommandation sur les applications mobiles, avec une mise en conformité attendue au printemps 2025. Elle nomme les responsabilités le long de la chaîne, de l’éditeur aux fournisseurs de SDK, en passant par les développeurs, les magasins d’applications et les systèmes d’exploitation. L’éditeur est responsable de traitement ; un fournisseur de SDK peut n’être que sous-traitant, mais dès lors qu’il réutilise les données pour son propre compte, l’éditeur en assume au minimum une co-responsabilité. En 2025, la CNIL a fait des applications mobiles une thématique prioritaire de ses contrôles, en s’intéressant en particulier à la configuration des SDK tiers et aux permissions demandées.

L’obligation est donc identique à celle du web. Le contrôle, lui, est désormais réel sur le mobile.

Le web se lit à livre ouvert

Sur le web, les signaux sont en clair, ou presque. Une page est du texte que le navigateur reçoit et affiche ; ses outils de développement, intégrés et gratuits, montrent les cookies écrits, les scripts chargés, chaque requête sortante et le domaine qu’elle vise. Une simple extension suffit à lister les traqueurs d’une page.

La raison est structurelle. Le navigateur est lui-même le point où le chiffrement s’ouvre : ses outils intégrés montrent l’échange en clair, et l’on peut au besoin insérer un intermédiaire de confiance pour tout relire. Le suivi se déroule dans un bac à sable que l’on peut ouvrir et inspecter, sans matériel particulier. C’est ce qui rend l’audit d’un site accessible, parfois même en libre-service.

L’application est une boîte fermée

L’application, elle, n’offre pas cette transparence. Elle est livrée sous forme de binaire compilé : ni le code, ni les SDK tiers qu’elle embarque ne se lisent comme une page web. Il n’y a pas d’« afficher le code source », pas de console ouverte d’un clic.

L’éditeur lui-même connaît rarement le détail de ce que chaque SDK envoie. Un kit d’analytics, de publicité ou d’attribution est une boîte noire intégrée à une autre : on l’inclut pour une fonction, et il emporte ses propres comportements réseau, que la documentation ne décrit pas toujours.

Le signal est chiffré, et l’application le verrouille

Comme le web, le trafic d’une application est chiffré en TLS. Mais une différence change tout. Sur un ordinateur, on lit le trafic web en insérant un intermédiaire de confiance, une autorité ajoutée au système. Depuis Android 7, une application ne fait plus confiance, par défaut, à une autorité ajoutée par l’utilisateur : elle ne s’en remet qu’au magasin du système. Le geste qui ouvre le trafic web ne fonctionne donc pas tel quel sur mobile.

Les applications les plus sensibles vont plus loin et épinglent leur certificat : elles n’acceptent que celui de leur propre serveur et rejettent tout intermédiaire. Pour voir ce qui sort, il faut déchiffrer le signal sur un appareil maîtrisé, pas seulement ouvrir un onglet. L’information part, mais elle part scellée.

L’application se défend contre l’observation

Sur le web, l’obstacle courant est l’anti-bot. Sur mobile, les défenses sont d’un autre ordre. Beaucoup d’applications embarquent un durcissement conçu pour résister à l’analyse : détection des appareils rootés, des émulateurs, des débogueurs et de l’instrumentation, obfuscation du code, protection à l’exécution. Ce n’est pas anecdotique : le standard OWASP MASVS en fait une catégorie entière, dédiée à la résistance à la falsification et à la rétro-ingénierie.

Ces mécanismes visent la fraude et le vol de propriété intellectuelle. Mais ils gênent tout autant une observation légitime : une application peut détecter qu’on l’observe et, en réponse, modifier son comportement ou s’arrêter. L’objet même que l’on cherche à mesurer se dérobe quand on l’approche.

Le comportement dépend du matériel

Une application ne se comporte pas de la même façon partout. Son comportement tient au terminal réel : le matériel, la version du système, les capteurs, les identifiants propres à l’appareil. Les émulateurs sont souvent détectés et traités différemment, quand ils ne sont pas purement refusés.

Or l’appareil est aussi une partie de ce qui est collecté. L’identifiant publicitaire, l’empreinte du téléphone, son modèle et sa version de système figurent parmi les données qui partent. Observer le vrai comportement suppose donc un vrai téléphone, pas une simulation, sans quoi l’on mesure une application qui se sait observée.

Déclencher le vrai comportement demande d’agir comme un utilisateur

Un site révèle ses traqueurs au chargement de la page. Une application, souvent, ne révèle ses flux qu’à l’usage. Les SDK se déclenchent à des moments précis : au premier démarrage, au passage de la bannière de consentement, en ouvrant tel écran, en lançant une vidéo, en faisant défiler un fil.

Reproduire ces flux ne se résume pas à charger une adresse. Il faut conduire l’interface comme le ferait un utilisateur, sur l’appareil, et traverser les parcours où les SDK s’activent réellement. Le premier lancement à froid, bannière comprise, et l’usage qui suit sont là où se trouve la preuve.

Un angle mort que le DPO ne peut pas lever seul

Mis bout à bout, l’écart est net. Le web s’audite avec des outils à portée de main. L’application, elle, demande un appareil réel, le déchiffrement du trafic, le contournement d’un durcissement pensé pour l’en empêcher, et une conduite de l’interface proche de l’usage réel. C’est un laboratoire et un savoir-faire hors de portée de la plupart des DPO et des éditeurs.

La conséquence est un paradoxe : la couche où l’exposition est la plus forte, et que la CNIL regarde désormais de près, est aussi la moins examinée. Le déclaré y tient lieu de preuve, faute de mieux.

C’est précisément ce que Skanopy rend accessible : auditer une application mobile sans monter le laboratoire. L’analyse s’exécute sur un vrai appareil, en suivant de vrais parcours, et rend un relevé documenté et reproductible de ce que l’application transmet réellement, sur n’importe quelle application Android, sans accès au code source de l’éditeur. Ce sont des signaux, pas des verdicts : la qualification juridique revient au DPO, avec le contexte de chaque application en main. Nous, on la rend mesurable. Une étude récente sur vingt applications de presse après un refus de pistage montre ce que cela donne en pratique.