Vous avez déjà vu ce message d'alerte : une application installée depuis des mois qui demande soudain l'accès à vos contacts, à votre micro, à votre position. Vous cliquez sur « Autoriser » par réflexe, parce qu'il est 23 h et que vous voulez juste ouvrir le fichier. C'est exactement à ce moment-là que la plupart des fuites de données commencent. Pas dans un film de hackers. Dans un clic fatigué.
Sécuriser ses applications mobiles, ce n'est pas installer un antivirus et considérer le dossier clos. J'ai passé des années à auditer des apps, côté éditeur puis côté utilisateur, et je vais être franc : 90 % des problèmes que j'ai vus ne venaient pas d'une faille exotique. Ils venaient d'un token stocké en clair, d'une permission accordée sans regarder, ou d'un téléphone rooté sur lequel personne n'avait rien verrouillé.
Points clés à retenir
- Sur Android, Play Protect analyse le comportement des apps installées : activez-le, il ne sert à rien laissé éteint.
- Chaque permission refusée est une porte fermée. Accordez au cas par cas, jamais « tout autoriser ».
- Le verrouillage d'une app (code, empreinte) est natif sur la plupart des téléphones — pas besoin d'une app tierce.
- Côté éditeur, les vraies failles sont dans l'API et le stockage des clés, pas dans l'interface.
- Un téléphone rooté ou jailbreaké annule une grande partie de vos protections.
- Les mises à jour de sécurité corrigent des failles déjà exploitées : les retarder, c'est rester exposé.
Sécuriser ses applications mobiles : il y a deux côtés, et on les confond tout le temps
La question « comment faire pour sécuriser les applications ? » a deux réponses opposées selon qui vous êtes. Si vous êtes utilisateur, vous protégez votre téléphone et vos données. Si vous êtes éditeur, vous protégez votre code et les données de vos clients contre des gens comme moi, qui allons essayer de les casser. Confondre les deux mène à des articles qui mélangent conseils grand public et vocabulaire de développeur, et qui n'aident personne.
Je vais traiter les deux, mais séparément. Parce que la personne qui installe une appli bancaire et celle qui la publie n'ont pas les mêmes ennemis.
Côté utilisateur : ce que vous contrôlez réellement
Vous ne contrôlez pas le code de l'app. Vous contrôlez ce que vous lui donnez. C'est tout, et c'est énorme.
Côté éditeur : ce que vous ne voyez pas
Là, le terrain de jeu change. Les vulnérabilités les plus exploitées sur mobile ne sont pas dans l'écran que l'utilisateur touche. Elles sont dans les échanges entre l'application et le serveur qui la fait fonctionner. Et cette partie, quasiment aucun article grand public n'en parle.
Le contrôle des permissions : la base que tout le monde saute
Une app de retouche photo n'a aucune raison légitime de lire vos SMS. Une app de notes n'a pas besoin de votre position GPS en permanence. Pourtant, quand j'ai passé en revue les permissions accordées sur le téléphone d'un ami la semaine dernière, trois applications sur sept avaient accès à son micro sans raison apparente. Il n'en avait aucune idée.
Le réflexe à adopter est simple, mais demande de résister à la fatigue :
- À l'installation, refusez tout ce qui n'est pas nécessaire au fonctionnement immédiat.
- Activez l'autorisation « uniquement pendant l'utilisation » pour la localisation et la caméra quand l'option existe.
- Une fois par trimestre, ouvrez les réglages de permissions et retirez ce qui n'a plus de sens.
Sur Android, l'analyse des comportements dangereux passe par Google Play Protect, intégré au système. Il scanne les apps installées et signale celles qui se comportent de façon suspecte. Le problème ? Beaucoup de gens le désactivent parce qu'il ralentit l'installation. C'est une erreur, franchement. C'est votre première ligne de défense contre une application malveillante Android, et elle est gratuite.
Comment repérer une application malveillante avant qu'il ne soit trop tard
Trois signaux que j'ai vus se répéter sur les cas que j'ai traités : une batterie qui se vide anormalement vite, de la data consommée la nuit alors que le téléphone est posé, et une app qui n'apparaît pas dans le tiroir d'applications classique. Si vous cochez deux de ces cases, désinstallez. Vous ne perdrez rien d'important.
Verrouillage application Android : natif, gratuit, et sous-utilisé
Verrouiller une app avec un code ou une empreinte, c'est la fonctionnalité que les gens cherchent sur le Play Store alors qu'elle est déjà dans leur téléphone. Samsung, Xiaomi, Huawei et Android stock proposent tous une option de verrouillage d'application dans les réglages de sécurité. Pas besoin d'installer quoi que ce soit.
Concrètement, ça empêche quelqu'un qui a votre téléphone déverrouillé dans les mains — un collègue, un proche, un inconnu dans le métro — d'ouvrir votre messagerie ou votre app bancaire. Ça ne protège pas contre un attaquant qui a accès au système de fichiers. Mais dans la vraie vie, la vraie menace, c'est le téléphone qu'on vous prend des mains. Le verrouillage répond exactement à ça.
Pourquoi je le mentionne ? Parce que j'ai vu un commercial perdre l'accès à son compte pro après avoir prêté son téléphone « deux minutes » pour passer un appel. Deux minutes, ça suffit largement.
Faut-il vraiment une application de sécurité gratuite en plus ?
La plupart du temps, non. Android embarque déjà l'analyse des menaces, le verrouillage et le chiffrement du stockage. Ajouter une app tierce, c'est souvent ajouter une app qui demande elle-même des permissions larges pour faire ce que le système fait déjà. Le gain réel est marginal. Si vous tenez absolument à une couche supplémentaire, choisissez-la parmi les rares qui ne monétisent pas vos données — et lisez la liste des permissions avant d'installer, pas après.
Le vrai trou dans la raquure : la sécurité des échanges entre l'app et son serveur
Voici l'angle que je n'ai trouvé nulle part quand j'ai commencé à creuser ce sujet. Sur les incidents que j'ai traités, la majorité des fuites ne venaient ni d'une permission mal configurée ni d'un antivirus absent. Elles venaient d'une API mal protégée. Une app peut avoir une interface impeccable et envoyer vos identifiants en clair vers un serveur.
Ce qu'il faut vérifier quand on développe, et que je vois trop souvent bâclé :
- Stockage des clés : jamais en dur dans le code, jamais dans un fichier de config versionné. Toujours dans le Keychain (iOS) ou le Keystore (Android).
- Authentification des échanges : chaque requête vers le backend doit porter un jeton valide, avec une durée de vie courte et une révocation possible.
- TLS avec épinglage de certificat : ça empêche une attaque par interception quand l'utilisateur est sur un réseau public.
- Détection de root ou de jailbreak : si le système est compromis, votre stockage sécurisé ne l'est plus.
- Obfuscation du code et anti-tampering pour compliquer la rétro-ingénierie.
Et une chose que j'ai apprise à mes dépens : la gestion du cycle de vie des sessions compte autant que la connexion initiale. Une session qui reste valide indéfiniment après une déconnexion, c'est une porte laissée ouverte. Révocation de jetons, expiration, dépréciation forcée des anciennes versions de l'app — ce sont des mécanismes qu'on oublie de mettre en place tant que tout va bien.
Comment on teste vraiment la sécurité d'une app
Un audit sérieux ne se fait pas au feeling. Il suit des référentiels reconnus — côté mobile, les standards de l'OWASP pour la vérification et les tests de sécurité des applications mobiles font référence. On combine analyse statique (lire le code à la recherche de mauvaises pratiques) et analyse dynamique (observer l'app en fonctionnement, sur un appareil contrôlé). Un pentest mobile, c'est ça : quelqu'un essaie activement de casser votre app, avec votre autorisation, avant que quelqu'un le fasse sans.
Je l'ai vu à mes frais sur un projet : on avait tout verrouillé côté serveur, on se sentait solides. Sauf que l'app stockait un jeton de session dans un fichier loggé par le système. Il a fallu trois semaines pour s'en rendre compte, et une version d'urgence à publier.
Comparer les leviers selon votre rôle
Pour y voir clair, voici comment les mêmes protections se traduisent selon des deux côtés.
| Levier | Côté utilisateur | Côté éditeur | Effort |
|---|---|---|---|
| Permissions | Refuser tout ce qui n'est pas nécessaire | Demander le strict minimum, expliquer pourquoi | Faible |
| Verrouillage | Activer le verrou dans les réglages | Prévoir une authentification à la réouverture | Faible |
| Mises à jour | Installer les correctifs sans traîner | Publier, et forcer la mise à jour si critique | Moyen |
| Sécurité des échanges | Éviter le Wi-Fi public pour les opérations sensibles | TLS, jetons courts, épinglage, révocation | Élevé |
| Stockage des clés | Rien à faire | Keychain / Keystore, jamais en dur | Élevé |
Ce tableau n'est pas une checklist à cocher une fois. C'est un rappel que chaque ligne a un coût, et que le coût le plus élevé se paie côté éditeur — souvent parce qu'il a été repoussé le plus longtemps.
Ce qui ne sert à rien, et sur quoi j'ai perdu du temps
Il faut le dire : installer trois antivirus sur son téléphone ne rend pas plus sûr. Ça ralentit la machine et donne un faux sentiment de protection. La plupart des infections que j'ai rencontrées venaient d'applications installées hors des stores officiels, pas d'un fichier qui aurait échappé à un scanner.
Autre croyance tenace : rooter son téléphone « pour avoir le contrôle ». Vous avez plus de contrôle, oui — mais vous brisez les mécanismes de sécurité que le système utilisait pour vous protéger. Un appareil rooté fait tomber une bonne partie des garde-fous que je viens de décrire. C'est un choix qu'on peut faire, mais en connaissance de cause, pas par curiosité.
Et les VPN gratuits, tant qu'on y est : beaucoup ne chiffrent rien et revendent ce qu'ils interceptent. Un outil de protection devrait être le dernier à monétiser vos données. Je sais, c'est un peu la douche froide.
Par où commencer, concrètement, ce soir
Si vous êtes utilisateur, trois gestes suffisent pour couvrir l'essentiel : vérifier que Google Play Protect est actif, passer en revue vos permissions une à une, et activer le verrouillage sur vos deux ou trois apps les plus sensibles. Comptez dix minutes. Pas de téléchargement, pas de compte à créer.
Si vous êtes éditeur, la priorité n'est pas l'interface. C'est le stockage des secrets et la robustesse de vos échanges avec le backend. Un attaquant motivé ne regardera pas vos belles animations. Il regardera ce que votre app envoie sur le réseau et où elle range ses clés.
La sécurité mobile n'est pas un produit qu'on achète une fois. C'est une série de petites décisions, prises quand vous êtes fatigué, et qui s'accumulent dans un sens ou dans l'autre. Ce que je ne vous dis pas, c'est qu'il existe un moment où tout est enfin réglé. Ce moment n'existe pas. Il y a juste un téléphone qui, ce soir, refuse une permission qu'il aurait acceptée hier par réflexe.
