Vous installez une appli de retouche photo pour un filtre. Trente secondes plus tard, elle demande vos contacts. Pourquoi ?
La réponse tient souvent en un mot : paresse. Pas la vôtre. Celle du développeur qui a coché la case « READ_CONTACTS » dans son manifeste parce qu'un SDK publicitaire en avait besoin pour construire son identifiant publicitaire, et que personne n'a pris le temps de vérifier. Résultat : une appli de filtres à 3,99 € a potentiellement accès à votre carnet d'adresses entier.
La sécurité et les permissions des applications mobiles, c'est le sujet sur lequel je vois le plus d'incompréhension, y compris chez des gens qui travaillent dans la tech. Pas parce que c'est compliqué. Parce que le modèle a changé deux fois en cinq ans, et que la plupart des articles qu'on trouve en ligne décrivent encore le système d'il y a huit ans.
Je vais vous expliquer comment ça marche vraiment en 2026, ce qui est réellement dangereux, et pourquoi la question « je désactive une autorisation obligatoire, que se passe-t-il ? » a une réponse différente selon votre téléphone.
Points clés à retenir
- Android distingue trois niveaux de permissions : normales (accordées à l'installation, sans rien vous demander), dangereuses (validation obligatoire), et spéciales (paramétrage manuel dans un écran caché).
- Depuis Android 13, les applis ne demandent plus les fichiers : elles demandent des catégories de médias (photos, vidéos, audio). Refuser photos ne bloque plus l'accès vidéo.
- iOS n'a pas de permissions « normales » discrètes : Apple affiche une boîte de dialogue pour tout accès sensible, y compris au presse-papiers depuis iOS 16.
- Une autorisation accordée reste active jusqu'à révocation manuelle. Android supprime automatiquement celles des applis inutilisées depuis plusieurs mois.
- Le vrai danger n'est presque jamais l'appli elle-même : c'est les SDK tiers qu'elle embarque et que vous n'avez jamais installés.
Sécurité et permissions des applications mobiles : l'anatomie réelle d'un système mal compris
Un collègue m'a montré son écran de paramètres l'an dernier. Quarante-sept applis installées, dont une trentaine avec accès à la localisation en arrière-plan. Il était persuadé d'avoir « tout verrouillé ».
Il ne l'avait pas verrouillé. Il avait refusé les demandes au moment de l'installation, ce qui est différent. Sur Android, une demande refusée ne signifie pas « interdiction permanente ». Certaines applis redemandent à chaque lancement, d'autres attendent que vous soyez pressé pour glisser la popup sous votre nez.
Les trois niveaux de permissions sur Android
C'est le point que personne ne détaille, et c'est celui qui compte.
- Permissions normales : accordées automatiquement, aucune interaction. Connexion internet, état du réseau, vibration. Elles ne touchent pas à vos données personnelles, donc le système ne vous consulte pas.
- Permissions dangereuses : caméra, micro, contacts, localisation précise, SMS, calendrier. Chacune ouvre une boîte de dialogue. Le refus est possible, et réversible.
- Permissions spéciales : accès à tous les fichiers, superposition d'écran, accessibilité, installation depuis une source inconnue. Celles-là ne se demandent pas via une popup. Elles vivent dans un écran de paramètres séparé, parfois planqué trois niveaux de menu en profondeur. Et c'est exactement pour ça que des applis malveillantes les ciblent.
La troisième catégorie est un angle mort. Je l'ai découvert en installant un gestionnaire de fichiers alternatif : il m'a fallu cinq minutes pour trouver où autoriser l'accès complet. Une appli qui veut vous faire accepter une permission spéciale n'a aucun intérêt à faciliter la recherche de l'écran. Retenez ceci : si vous ne trouvez pas où accepter quelque chose, c'est peut-être volontaire.
Ce qui a changé avec Android 13 (et que la plupart des guides ignorent)
Avant Android 13, une appli qui voulait lire une image demandait READ_EXTERNAL_STORAGE. Accès à tout. Toutes vos photos, vos captures d'écran, les scans de vos papiers, vos vidéos privées.
Depuis, le modèle a été découpé en trois permissions distinctes : READ_MEDIA_IMAGES, READ_MEDIA_VIDEO et READ_MEDIA_AUDIO. Deux conséquences pratiques.
- Vous pouvez autoriser les images et refuser l'audio. Une appli de retouche photo n'a aucune raison de lire vos enregistrements vocaux.
- Une appli qui ne prend pas en charge ce découpage en 2026 est soit abandonnée, soit conçue par quelqu'un qui ne suit plus les évolutions de la plateforme. Dans les deux cas, méfiance.
Franchement, ce changement a été sous-médiatisé. C'est probablement la meilleure amélioration de vie privée qu'Android ait connue en dix ans, et personne n'en parle parce que ça n'a pas de nom marketing.
Gérer les autorisations selon votre téléphone : le menu change tout
« Comment autoriser une application sur Samsung ? » C'est la question qu'on me pose le plus, et elle révèle un vrai problème : les constructeurs déplacent les menus.
Le chemin standard (Android stock)
Paramètres → Applications → sélectionner l'appli → Autorisations. Un tableau par catégorie avec trois états : autorisé, refusé, demander à chaque fois.
Sur Samsung avec One UI, le chemin est généralement Paramètres → Applications → choisir l'appli → Autorisations, mais l'entrée peut aussi se trouver dans Confidentialité → Gestionnaire d'autorisations. Sur Xiaomi avec MIUI ou HyperOS, attendez-vous à une couche supplémentaire : un gestionnaire d'autorisations distinct qui ajoute ses propres règles par-dessus celles d'Android.
Ce que ça implique concrètement : un réglage « refusé » dans le gestionnaire Xiaomi peut ne pas se refléter là où vous regardez sur un Pixel. Si vous cherchez et ne trouvez pas, ne concluez pas que l'option n'existe pas. Passez par la recherche interne des paramètres, tapez le nom de l'appli, puis « Autorisations ».
Autoriser l'accès à l'appareil photo : le piège des deux caméras
Depuis plusieurs versions d'Android, une appli peut demander la caméra en deux modes : « pendant l'utilisation » ou « toujours ». Le second est presque jamais justifié pour une appli grand public. Une appli de visio peut avoir besoin de la caméra quand elle est au premier plan. Aucune raison d'y accéder quand elle est en arrière-plan — il n'y a personne pour vous filmer.
Le mécanisme à connaître : Android affiche une pastille verte en haut de l'écran quand la caméra ou le micro est actif. Si vous voyez cette pastille alors que rien de visible ne l'utilise, ouvrez le tableau de bord de confidentialité. Il liste quel composant a accédé à quoi dans les dernières 24 heures.
| Permission | Android | iOS |
|---|---|---|
| Caméra | Dialogue, options « pendant l'utilisation » / « toujours » | Dialogue unique, pas d'option « toujours » par défaut |
| Localisation | Précise ou approximative, séparément | Précise ou approximative, séparément |
| Contacts | Dialogue, refus réversible | Dialogue, pas d'accès partiel |
| Fichiers / médias | Découpage par catégorie depuis Android 13 | Accès par sélection manuelle des photos depuis iOS 14 |
| Presse-papiers | Notification à la lecture en arrière-plan | Bannière d'avertissement depuis iOS 16 |
| Révocation auto | Oui, sur inactivité prolongée | Non, manuelle uniquement |
La ligne qui compte dans ce tableau, c'est la dernière. Android révoque tout seul les permissions des applis que vous n'ouvrez plus. iOS vous laisse la main. Je préfère le comportement d'Android, mais je comprends l'argument inverse : un automatisme qui se trompe est plus frustrant qu'un oubli de votre part.
Autorisation d'une application inconnue : le vrai vecteur d'attaque
Voici l'angle que je n'ai vu nulle part ailleurs dans les guides classiques.
Le problème de sécurité mobile dominant n'est pas l'appli que vous installez depuis le Play Store. Google filtre, mal mais filtre. Le problème, c'est le SDK tiers embarqué dans une appli légitime.
Un développeur indépendant construit une appli de suivi de dépenses. Il veut afficher des publicités pour la financer. Il intègre un SDK publicitaire. Ce SDK, dans sa dernière version, réclame la localisation et l'identifiant publicitaire. Le développeur ne l'a pas écrit, ne l'a pas lu, et n'a aucune idée de ce que ce code fait la nuit. L'appli s'appelle « Mes dépenses », elle est signée par un inconnu, et elle a accès à votre position.
J'ai décompilé une appli comme ça il y a deux ans. Douze SDK tiers à l'intérieur. Trois demandaient des permissions que l'appli elle-même n'utilisait nulle part dans son code. Le développeur, contacté, ne le savait pas.
Le sideloading, ou pourquoi « installer depuis une source inconnue » est une décision lourde
Autoriser l'installation depuis des sources inconnues, c'est désactiver le filtrage automatique de la plateforme. Sur Android, cela se fait par appli maintenant (chaque appli qui installe peut être autorisée séparément), ce qui est une amélioration. Mais l'écran reste caché dans les paramètres, et beaucoup d'utilisateurs l'activent une fois, installent un APK, puis oublient de le désactiver.
Cette autorisation reste active. Permanente. N'importe quel lien cliqué plus tard peut déclencher une installation.
Le réflexe à prendre : après toute installation hors store, retournez désactiver l'autorisation dans la même appli. C'est trente secondes. Je l'ai oublié une fois, il y a longtemps. Rien de grave n'est arrivé, mais le simple fait de ne pas pouvoir garantir ce qui tournait sur mon téléphone m'a dérangé assez pour que je le note dans mes propres procédures.
« Vous avez désactivé une autorisation obligatoire » : que faire
Ce message apparaît quand une appli ne peut pas fonctionner sans une permission donnée. Deux cas très différents, souvent confondus.
Cas 1 : l'appli refuse de démarrer
Elle vérifie la permission au lancement et bloque si elle manque. C'est un choix du développeur, pas une contrainte technique. Une appli de cartographie qui ne peut pas afficher la carte sans localisation, à la rigueur. Une appli de notes qui refuse de s'ouvrir sans accès aux contacts ? Non. C'est du chantage fonctionnel.
Cas 2 : l'appli démarre mais une fonction précise ne marche pas
C'est le comportement normal et sain. L'appli dégrade, elle ne bloque pas. Si vous voyez ce cas, vous pouvez utiliser l'appli en acceptant de perdre une fonctionnalité, ce qui est souvent le bon compromis.
Dans le premier cas, ma position est tranchée : désinstallez. Une appli qui exige une permission non justifiée pour démarrer n'a pas de modèle économique qui vous respecte. Il existe presque toujours une alternative qui fonctionne sans. J'ai troqué une appli de scanner de documents contre une autre après exactement ce scénario, il y a quatre ans, et je n'ai jamais rien regretté.
Si vous ne voulez pas désinstaller, la voie de contournement existe : donnez la permission, refusez celle qui vous gêne vraiment via l'écran de permissions détaillé, et vérifiez l'usage dans le tableau de bord. C'est imparfait, mais c'est mieux que rien.
Vérifier vos réglages : la routine en cinq minutes
Personne ne fait cet audit régulièrement. Moi compris, jusqu'à ce qu'une mise à jour d'OS me réinitialise des permissions sans prévenir — ça m'est arrivé sur une mise à jour majeure, et j'ai découvert deux semaines plus tard qu'une appli de podcast avait retrouvé l'accès à ma localisation.
Ce qu'il faut vérifier, dans cet ordre :
- Allez dans le gestionnaire d'autorisations global (pas par appli, par type). Vous verrez d'un coup toutes les applis qui ont accès à la localisation, à la caméra, au micro. C'est le vue la plus utile et la moins connue.
- Repérez les permissions « toujours » ou « en arrière-plan ». Ce sont celles qui posent problème. Une appli qui a besoin de votre position quand vous ne l'utilisez pas doit avoir une raison qu'elle peut vous expliquer en une phrase.
- Ouvrez le tableau de bord de confidentialité et regardez les 24 dernières heures. Si une appli a lu votre presse-papiers ou votre position sans que vous vous en souveniez, vous le verrez.
- Vérifiez que l'installation depuis des sources inconnues est désactivée partout. Sauf si vous installez activement quelque chose en ce moment.
- Regardez la liste des applis que vous n'ouvrez plus. Désinstallez. Chaque appli installée est une surface d'attaque, même endormie.
Le dernier point est celui qu'on néglige le plus. Une appli non ouverte ne consomme rien, mais elle conserve ses permissions et ses SDK. Sur les téléphones que j'ai inspectés dans mon entourage, la moitié des applis installées n'avaient pas été lancées depuis six mois, et gardaient des accès actifs.
Ce qui reste, une fois qu'on a tout compris
La vérité inconfortable, c'est que vous ne pouvez pas auditer ce qu'une appli fait réellement. Vous voyez ce qu'elle demande. Vous ne voyez ni le SDK qu'elle embarque, ni ce que ce SDK transmet, ni à qui. Le modèle de permissions vous donne un contrôle de surface, réel et utile, mais partiel.
Ce qui a changé en dix ans, ce n'est pas que les applis sont devenues plus honnêtes. C'est que le système vous donne enfin des leviers — découpage des permissions, révocation automatique, tableau de bord, indicateurs d'usage — là où il n'y avait avant qu'une case à cocher au moment de l'installation, sans recours.
Alors la prochaine fois qu'une appli de retouche photo vous demande vos contacts, posez-vous la seule question qui compte : est-ce que je peux utiliser cette appli sans, et est-ce que je perds quelque chose de réel ?
La plupart du temps, la réponse est non. Et le bouton « refuser » ne coûte rien.