Pour Halloween, une fenêtre Android qui demande position, contacts, identité du téléphone et accès réseau fait déjà assez peur. Le bouton Accepter donne l’impression d’une décision unique, alors que chaque permission ouvre un trajet de données différent.

L’application demande ses permissions dans son manifeste. Le système les affiche à l’installation, puis lui permet d’appeler les API correspondantes. Lire les contacts retourne des noms et numéros; le réseau permet de les transmettre; l’identifiant de l’appareil permet de relier plusieurs envois. Prises ensemble, trois permissions banales peuvent produire un profil très précis.

Décomposer la fonction annoncée

Une lampe de poche a besoin d’allumer la DEL. Si elle demande aussi les contacts, la position et le réseau, je ne vois pas le lien fonctionnel. Pour une application de restaurants, le besoin est plus nuancé :

1. obtenir une position au moment de la recherche;
2. l’arrondir à la précision nécessaire;
3. envoyer la zone et la catégorie au service;
4. recevoir les commerces proches;
5. supprimer la position lorsque la réponse est rendue.

Ce flux ne demande ni le carnet d’adresses ni un suivi permanent. Si l’application veut proposer des amis à proximité, c’est une autre fonction, avec une explication et un choix séparés. Regrouper les deux sous « améliorer votre expérience » empêche de comprendre la contrepartie.

Le serveur doit lui aussi limiter la donnée. Un journal technique peut garder heure, version et code de réponse sans latitude exacte. Les accès administratifs doivent être audités, le transport chiffré et la rétention définie. Une base de localisation copiée dans les sauvegardes peut survivre longtemps après la suppression visible.

Le refus et le retrait doivent fonctionner

Un consentement n’est pas libre si refuser ferme une fonction sans rapport. L’application devrait dégrader seulement ce qui dépend de la permission : saisir une adresse manuellement au lieu de forcer le GPS, par exemple. Elle doit également réagir lorsque la permission est retirée plus tard, sans boucler ni planter.

Le téléphone perdu crée une autre fuite. Les données locales sensibles devraient être chiffrées et protégées par le verrouillage. Une session longue doit pouvoir être révoquée. L’application ne devrait pas écrire des coordonnées ou des jetons dans ses logs, surtout si ces logs sont joints automatiquement à un rapport de bogue.

L’erreur est possible même sans mauvaise intention : une librairie publicitaire peut collecter davantage que l’équipe ne réalise, ou un endpoint de test peut rester ouvert. Je ferais un inventaire des SDK, capturerais le trafic d’un parcours et comparerais chaque champ envoyé avec la promesse affichée.

Avant de publier, je remplirais une petite fiche par donnée : source, usage, destinataire, durée, protection et comportement au refus. Si une colonne reste vague, le bouton Accepter l’est aussi. La vie privée se construit dans ces flux précis, bien avant le texte juridique.