Une application de suivi de règles qui envoie vos données de santé à cinq sociétés publicitaires. Un jeu de coloriage pour enfants qui demande l'accès aux contacts. Une appli de lampe torche qui réclame la géolocalisation en arrière-plan. Vous avez déjà vu ces permissions absurdes, non ? Moi si. Et pendant longtemps je les ai acceptées sans réfléchir, comme tout le monde.
Jusqu'au jour où j'ai commencé à développer moi-même des applications. Là, j'ai découvert l'envers du décor : ce que je croyais être une simple case à cocher dans mon code envoyait en réalité des identifiants uniques vers des serveurs que je n'avais jamais choisis. Un SDK ajouté pour "améliorer l'expérience utilisateur" collectait plus d'infos que mon application entière. Depuis, je regarde les permissions d'un œil beaucoup moins innocent.
Alors parlons concret : qu'est-ce qui distingue vraiment une application mobile respectueuse des données personnelles d'une appli juste "à peu près conforme au RGPD" ? Et surtout, comment le vérifier par vous-même ?
Points clés à retenir
- Le RGPD impose aux éditeurs mobiles une base légale pour chaque donnée collectée : consentement, intérêt légitime, ou contrat — et le consentement seul exige d'être libre, spécifique, éclairé et univoque.
- La CNIL a publié des recommandations dédiées aux applications mobiles qui ciblent notamment les SDK tiers, souvent plus gourmands que l'appli elle-même.
- Une permission accordée ne signifie pas une permission justifiée : le principe de minimisation reste la clé.
- Les données concernées vont bien au-delà du nom et de l'email : identifiants publicitaires, géolocalisation, contacts, journaux d'usage.
- Un éditeur sérieux documente sa politique de confidentialité, sa politique interne de protection des données et ses mentions légales avant la mise en ligne.
Quelles réglementations encadrent les applications mobiles en France ?
En France, une application mobile ne vit pas sous un seul régime juridique. Elle en cumule plusieurs, et c'est là que beaucoup d'éditeurs se perdent.
Le RGPD, socle européen
Le Règlement général sur la protection des données s'applique dès qu'une application traite des données de personnes situées dans l'Union européenne — peu importe où l'éditeur est établi. Concrètement, cela implique :
- une base légale identifiée pour chaque finalité de traitement ;
- une information claire au moment de la collecte ;
- la possibilité pour l'utilisateur d'exercer ses droits (accès, effacement, opposition) ;
- des durées de conservation définies ;
- un encadrement contractuel des sous-traitants, y compris les fournisseurs de SDK.
La loi Informatique et Libertés et le rôle de la CNIL
La loi française de 1978 complète le RGPD sur des points nationaux (traitements de recherche, données de santé, etc.). La CNIL, elle, n'est pas qu'un gendarme : elle publie des référentiels, des recommandations sectorielles et mène des contrôles. Depuis quelques années, elle a clairement mis les applications mobiles dans son viseur, avec une attention particulière portée aux traceurs publicitaires.
Les autres textes à ne pas oublier
Selon votre secteur, d'autres règles s'ajoutent : le Code des postes et communications électroniques (cookies et traceurs), le règlement ePrivacy, ou encore des obligations sectorielles (santé, finance, éducation). Et côté boutiques d'applications, les règles de l'App Store et de Google Play ajoutent leur propre couche de déclaration de confidentialité — souvent plus strictes que le strict minimum légal.
Quelle est la recommandation de la CNIL concernant les applications mobiles ?
La CNIL a adopté des recommandations spécifiques aux applications mobiles, qui traitent d'un angle longtemps négligé : le cycle de vie complet d'une permission, et surtout les SDK publicitaires intégrés par les éditeurs.
Un consentement par permission, pas un consentement global
Première exigence : le consentement doit être spécifique. Une fenêtre "J'accepte tout" qui englobe accès aux contacts, géolocalisation et identifiant publicitaire dans une même case n'est pas conforme. Chaque finalité doit pouvoir être acceptée ou refusée individuellement.
Le cas des SDK tiers
Voilà l'angle que je trouve le plus utile, et le moins traité par les articles grand public. Un SDK (kit de développement logiciel) est un bout de code que vous intégrez à votre appli pour ajouter une fonctionnalité — analytics, pub, crash reporting, attribution. Le problème : ces bouts de code collectent souvent davantage de données que votre propre application, et pas toujours de façon transparente.
La recommandation de la CNIL insiste sur la nécessité de recenser les SDK embarqués, de documenter leurs traitements, et de conditionner leur activation au consentement quand la base légale le requiert. Une checklist que j'utilise désormais systématiquement :
- Lister tous les SDK présents dans le build de production.
- Pour chacun, identifier l'éditeur et la finalité réelle.
- Vérifier si un consentement est nécessaire et, si oui, bloquer son activation tant qu'il n'est pas recueilli.
- Tester en conditions réelles (pas seulement en debug) avec un outil d'interception réseau.
- Documenter tout ça dans un registre de traitement.
Informer au bon moment
La CNIL rappelle aussi qu'une information générique dans les conditions d'utilisation ne suffit pas. L'utilisateur doit comprendre, au moment où il accorde une permission, à quoi elle sert concrètement. Pas "cette appli utilise vos données pour améliorer ses services", mais "nous utilisons votre position pour vous proposer les commerces à proximité".
Quelles données personnelles sont concernées par le RGPD ?
Question piège. Beaucoup pensent "nom, prénom, email" et s'arrêtent là. En réalité, dans une appli mobile, la liste est beaucoup plus longue.
| Catégorie | Exemples dans une appli | Sensibilité |
|---|---|---|
| Identifiants | IDFA, GAID, identifiant d'installation | Élevée (traçage publicitaire) |
| Localisation | GPS, position approximative, historique de lieux | Élevée |
| Contacts et carnet d'adresses | Accès répertoire, invitations | Élevée |
| Données techniques | Type d'appareil, OS, adresse IP, logs | Moyenne |
| Contenus personnels | Photos, fichiers, messages | Variable |
| Données comportementales | Écrans visités, fréquence d'usage | Moyenne à élevée |
Un point souvent oublié : un identifiant publicitaire est une donnée personnelle, même s'il ne contient aucun nom. Dès lors qu'il permet de reconnaître un appareil de façon stable, il tombe sous le RGPD.
"Respectueuse" n'est pas synonyme de "conforme"
Ici je prends position, et j'assume. Une application peut être parfaitement conforme au RGPD sur le papier et rester profondément irrespectueuse. Comment ? En cochant toutes les cases légales — bandeau de consentement, politique de confidentialité, mentions légales — tout en rendant le refus si pénible qu'aucun utilisateur ne le choisit vraiment.
Les dark patterns de consentement sont partout : bouton "Accepter" en gros, "Refuser" en gris minuscule au fond de l'écran, trois clics supplémentaires pour désactiver un traceur. Techniquement, la case est là. Éthiquement, c'est du théâtre.
La différence entre conforme et respectueuse tient à trois choses :
- la symétrie du choix : accepter et refuser doivent coûter le même effort ;
- la minimisation assumée : collecter moins que ce que la loi permet quand ce n'est pas nécessaire ;
- la transparence active : documenter publiquement les SDK utilisés et les finalités.
Personnellement, je considère la minimisation comme le meilleur indicateur de sérieux d'un éditeur. Une appli qui ne vous demande que ce dont elle a besoin pour fonctionner inspire plus confiance que celle qui réclame tout "au cas où".
Quelles applications pour sécuriser ses données personnelles ?
Vous n'êtes pas obligé de faire confiance aveuglément. Quelques outils changent réellement la donne, à condition de savoir ce qu'ils font.
Côté utilisateur
- Gestionnaire de permissions : sur Android comme sur iOS, vous pouvez révoquer une permission a posteriori, y compris la localisation "approximative" plutôt que précise.
- Bloqueurs de traqueurs réseau : un VPN local ou un DNS filtrant permet de repérer quelles applis contactent des serveurs publicitaires.
- Profils séparés : isoler les applis les moins regardantes dans un profil Android Work empêche la contamination croisée des données.
- Désactivation de l'identifiant publicitaire : côté systèmes, l'option existe et désactive le ciblage personnalisé.
Côté développeur
Pour un éditeur qui veut vraiment construire une application respectueuse, deux réflexes indispensables : d'abord, une privacy by design dès la conception — pas en rustine après la sortie. Ensuite, un inventaire vivant des SDK intégrés, revu à chaque mise à jour de dépendance. J'ai perdu une semaine sur un projet parce qu'une mise à jour mineure d'un SDK analytics avait changé ses règles de collecte sans que rien ne le signale dans les logs. Depuis, je fais tourner un test d'interception réseau à chaque release.
Les questions qu'on me pose le plus souvent
Une politique de confidentialité suffit-elle à rendre mon application conforme ?
Non. C'est un document indispensable, mais il ne remplace ni le recueil du consentement, ni la base légale, ni la minimisation. Une politique de confidentialité bien rédigée sur une appli qui collecte trop ne rend rien conforme.
Faut-il des mentions légales spécifiques pour une application mobile ?
Oui, et elles doivent identifier l'éditeur, l'hébergeur, ainsi que les moyens de contact. Elles s'ajoutent à la politique de confidentialité : l'une dit qui vous êtes, l'autre dit ce que vous faites des données.
Une politique interne de protection des données est-elle obligatoire ?
Elle n'est pas nommée ainsi dans le RGPD, mais le principe d'accountability impose de pouvoir démontrer votre conformité. Dans les faits, cela suppose un registre des traitements, une documentation des SDK, et des procédures internes. Autant l'écrire noir sur blanc.
La vraie question n'est pas "quelle appli est conforme". C'est : "quelle appli me traite comme une personne plutôt que comme une source de données". Et ça, aucun texte de loi ne peut l'imposer à la place de l'éditeur.
