Permissions Android : ce que la minimisation veut dire pour votre application
Les permissions sont la couche de consentement du système Android : l’utilisateur accorde ou refuse l’accès à sa position, ses contacts, son micro. Mais elles ne règlent qu’une question, l’accès, et pas celle que pose le RGPD, l’usage. La grille de lecture de la CNIL tient en un mot, la minimisation : une permission par fonctionnalité réelle. Voici comment le modèle fonctionne, ce que la plateforme impose déjà, et ce qui ne se vérifie qu’en regardant l’application tourner.
Trois familles de permissions
La documentation Android distingue trois familles. Les permissions accordées à l’installation, dites normales, couvrent des accès qui sortent du bac à sable de l’application mais présentent peu de risque pour la vie privée. Les permissions d’exécution, dites dangereuses, protègent les données et actions sensibles, position, contacts, micro, caméra : l’application doit les demander en cours d’usage, par une boîte de dialogue du système, et l’utilisateur peut dire non. Les permissions spéciales, enfin, couvrent des opérations particulières et se gèrent dans les réglages.
Pour un DPO, l’essentiel se joue dans la deuxième famille : ce sont les permissions dangereuses qui ouvrent l’accès aux données personnelles, et ce sont elles qu’un contrôleur regarde en premier.
Ce que la plateforme impose déjà
Android pousse lui-même vers la minimisation. Depuis Android 11, la boîte de dialogue des permissions liées à la position, au micro et à la caméra propose une autorisation à usage unique : l’accès vaut pour la session, pas pour toujours. Et pour les applications qui ciblent Android 11 ou plus, le système réinitialise automatiquement les permissions sensibles d’une application restée inutilisée quelques mois.
Autrement dit, une permission n’est plus un acquis : elle se re-mérite. Une application qui repose sur des accès accordés une fois pour toutes construit sur du sable.
La permission n’est pas le consentement
Accorder une permission est un geste technique : il ouvre un accès. Le consentement du RGPD, lui, porte sur une finalité, et la recommandation de la CNIL le dit expressément : l’autorisation accordée par le système ne vaut pas consentement. La permission de localisation autorise l’application à lire la position ; elle ne l’autorise pas à l’envoyer à des régies publicitaires.
Le même raisonnement vaut pour l’identifiant publicitaire : l’accès technique est une chose, le pistage en est une autre, et c’est la seconde qui exige un consentement.
Minimiser : une permission par fonctionnalité visible
L’attente de la CNIL est concrète : chaque permission demandée doit correspondre à une fonctionnalité réelle et visible pour l’utilisateur. Une permission sans usage apparent est un signal pour un contrôleur, et une application qui demande tout au premier lancement, avant tout geste, dit quelque chose de sa conception.
La bonne pratique rejoint la règle : demander la permission au moment du geste qui en a besoin, pas à l’ouverture, et s’en passer quand une alternative existe.
Le vrai test : l’usage observé
Le manifeste d’une application liste les permissions déclarées ; il ne dit ni lesquelles sont demandées à l’utilisateur, ni quand, ni lesquelles servent réellement. Ces trois faits ne s’observent qu’à l’exécution, sur un vrai téléphone, en suivant un parcours réel : le moment de chaque demande dans le parcours, et l’usage effectif qui la justifie, ou pas.
C’est l’un des six relevés d’un audit de conformité RGPD d’une application mobile, et l’une des vérifications qu’un contrôle mène : la proportionnalité se juge sur l’usage, pas sur la déclaration. Se préparer, c’est le mesurer avant qu’on ne vous le demande.
Sources
Chaque constat de cet article renvoie à l’un de ces documents.
- AndroidPermissions on AndroidDocumentation Android Developers, Google
- AndroidRequest runtime permissionsDocumentation Android Developers, Google
- CNIL ’25Recommandation relative aux applications mobiles, version modifiéeCNIL, délibération n° 2025-024 du 27 mars 2025
Questions fréquentes
- Quelle différence entre une permission normale et une permission dangereuse ?
- Une permission normale est accordée à l’installation et couvre un accès à faible risque pour la vie privée. Une permission dangereuse protège des données ou des actions sensibles, position, contacts, micro, caméra : elle se demande en cours d’usage, par une boîte de dialogue du système, et l’utilisateur peut la refuser ou la retirer.
- Une permission accordée vaut-elle consentement RGPD ?
- Non. La permission ouvre un accès technique ; le consentement du RGPD porte sur une finalité, et doit rester libre, spécifique, éclairé et univoque. La recommandation de la CNIL le dit expressément : l’autorisation accordée par le système ne vaut pas consentement.
- Que deviennent les permissions d’une application inutilisée ?
- Pour les applications qui ciblent Android 11 ou plus, le système réinitialise automatiquement les permissions sensibles après quelques mois sans utilisation. L’application doit les redemander, et l’utilisateur peut refuser.
- Comment vérifier qu’une permission est réellement utilisée ?
- En observant l’application pendant qu’elle tourne : le moment où chaque permission est demandée dans le parcours, et l’usage qui en est fait ensuite. Une permission demandée mais jamais utilisée interroge la minimisation, et c’est un constat qu’un rapport d’analyse documente, preuve à l’appui.