Sécuriser ses applications mobiles : 7 bonnes pratiques à adopter

Il y a deux façons de lire la requête « sécuriser ses applications mobiles ». La première, c'est celle de l'utilisateur : comment empêcher quelqu'un qui a mis la main sur mon téléphone d'ouvrir ma banque ou mes photos. La seconde, c'est celle du développeur : comment empêcher quelqu'un qui a mis la main sur mon application de lire les données de mes utilisateurs. La plupart des pages qui sortent sur le sujet ne traitent que la première, et à coups d'AppLock. Le problème, c'est que la seconde est celle qui coûte cher quand elle est ratée.

Je vais vous parler des deux, mais je vais insister sur la partie dont personne ne parle : celle qui se joue dans le code. Un téléphone volé, ça se remplace. Une base d'utilisateurs exposée parce qu'un jeton d'authentification était stocké en clair dans les préférences partagées, ça se remplace beaucoup moins bien.

Verrouiller une application : ce que ça protège vraiment

Commençons par évacuer le malentendu. Quand vous activez le verrouillage d'une application, vous ajoutez une couche d'authentification au-dessus de l'application, gérée par le système ou par un outil tiers. L'appel n'est jamais atteint sans le code. C'est efficace contre un collègue curieux, un enfant qui a récupéré le téléphone déverrouillé, un ami qui « voulait juste regarder ».

Ce n'est pas efficace contre quelqu'un qui a le téléphone rooté, débogage USB activé, ou qui restaure votre sauvegarde sur un autre appareil. Dans ces cas, la serrure est un rideau.

Comment verrouiller les applications sur Android

Depuis plusieurs versions, Android embarque un verrouillage natif accessible dans Paramètres → Sécurité → Verrouillage d'applications. Vous choisissez un code, puis vous cochez les apps à protéger. Concrètement, quand une app verrouillée est ouverte, le système réclame votre schéma ou votre empreinte avant de laisser passer.

Samsung, de son côté, a fait le choix d'un conteneur sécurisé (Secure Folder) plutôt que d'un verrouillage app-par-app. Vous y déplacez les applications et les fichiers sensibles ; elles deviennent invisibles depuis le tiroir d'applications standard. Franchement, c'est plus propre, mais aussi plus contraignant : il faut y penser à chaque installation.

Huawei propose un mécanisme similaire, et plusieurs constructeurs chinois ont leur variante. Le point commun de tous ces systèmes : ils dépendent de la version d'Android et de la surcouche. Ce qui fonctionne sur un Galaxy ne fonctionne pas forcément sur un Pixel.

Mettre un mot de passe sur une application iPhone

Apple n'a jamais ouvert de verrouillage d'applications généralisé. Ce qu'on peut faire, c'est utiliser Raccourcis pour créer une automatisation qui verrouille l'appareil quand une app donnée s'ouvre. C'est bricolé, ça fonctionne à moitié, et ça ralentit l'ouverture. L'autre option, plus solide, c'est de compter sur le verrouillage de l'appareil lui-même, avec un code à six chiffres et la désactivation de l'accès depuis l'écran verrouillé.

Pour les applications individuelles — banque, gestionnaire de mots de passe, messagerie — la plupart intègrent leur propre code ou une authentification biométrique. C'est de loin la meilleure défense côté iPhone, parce qu'elle est contrôlée par l'app elle-même et non par une surcouche.

Les applications tierces de type app lock

Elles existent, elles sont gratuites pour la plupart, et elles reviennent systématiquement dans les recherches. Un avertissement : ces outils demandent des permissions très larges (accessibilité, superposition d'écran, accès aux statistiques d'usage). Une application qui peut lire tout ce qui s'affiche sur votre écran pour « protéger » vos applications, c'est un pari sur l'honnêteté de son éditeur.

J'ai testé trois d'entre elles il y a un moment. Deux affichaient de la publicité en plein écran à chaque déverrouillage — donc un SDK publicitaire avec accès à l'écran. J'ai désinstallé.

Sécuriser une application côté développeur : le vrai sujet

Ici, on change complètement de terrain. Il ne s'agit plus de cacher une app derrière un code, mais de faire en sorte que l'app elle-même ne crache pas les données qu'elle manipule. Et croyez-moi, la liste des erreurs est longue.

Le stockage des données, premier poste de fuite

Sur Android, les SharedPreferences ne sont pas chiffrées par défaut. Sur iOS, les NSUserDefaults non plus. Et pourtant, combien de projets y stockent un jeton d'authentification, une clé d'API, un identifiant de session ? Beaucoup. Trop.

La bonne pratique tient en deux lignes : si la donnée est sensible, elle passe par EncryptedSharedPreferences (Android) ou par le Keychain (iOS). Si c'est une clé cryptographique, elle passe par le Keystore matériel quand l'appareil en dispose, ce qui est le cas sur la quasi-totalité des téléphones sortis depuis des années.

Sur un projet que j'ai repris, un jeton OAuth vivait en clair dans un fichier de préférences. N'importe quelle app avec accès au stockage externe pouvait le lire sur les versions d'Android antérieures au stockage scopé. Le correctif a pris une demi-journée. L'audit qui l'a révélé, deux jours. Le risque évité, lui, était une compromission complète des comptes.

Les communications et le certificate pinning

Le HTTPS est un plancher, pas un plafond. Si votre application accepte n'importe quel certificat présenté par un proxy, un attaquant en position d'intermédiaire — sur un Wi-Fi public, dans un hôtel, dans un aéroport — lit tout le trafic en clair après déchiffrement.

Le certificate pinning consiste à embarquer dans l'app l'empreinte du certificat (ou de la clé publique) attendue, et à refuser toute connexion qui ne correspond pas. C'est simple à mettre en place, ça casse les proxys d'analyse… ce qui est précisément le but. Et ça se contourne, avec un appareil rooté et un peu de patience, mais ça élimine 95 % des scénarios d'interception opportuniste.

Obfuscation, intégrité et détection de root

Une application compilée n'est pas une boîte noire. Sans obfuscation, un attaquant récupère vos noms de classes, vos points d'entrée réseau, parfois vos clés. R8 sur Android et les outils équivalents côté iOS réduisent la surface. Ça ne rend pas l'appareil inviolable, ça rend l'attaque plus coûteuse — ce qui est exactement le calcul à faire.

La vérification d'intégrité (signature de l'APK, détection du root, détection du débogage) ajoute une couche. Attention cependant : toutes ces protections sont contournables. Elles servent à filtrer les attaquants amateurs et les scripts automatisés, pas une équipe motivée. Ne construisez pas votre modèle de sécurité dessus.

Les vulnérabilités que je rencontre le plus souvent

Après plusieurs audits, la liste finit par être prévisible. La voici, dans l'ordre de fréquence observée :

• Stockage non chiffré de jetons, mots de passe temporaires, données personnelles.
• Communications acceptant un certificat quelconque en environnement de test, et jamais corrigées en production.
• Clés d'API en dur dans le code, publiées dans le dépôt, et parfois encore visibles dans le binaire final.
• Gestion de session trop permissive : jetons qui n'expirent jamais, pas de révocation côté serveur.
• Journalisation excessive : des données personnelles écrites dans les logs système, lisibles par d'autres apps sur les versions anciennes.

La cinquième est la plus sournoise, parce qu'elle n'est jamais intentionnelle. Un Log.d() oublié, une exception qui affiche le contenu de la requête, et voilà un identifiant utilisateur dans les journaux.

Cadre légal et tests : la partie qu'on reporte toujours

Le RGPD impose la sécurité des données personnelles par défaut, ce qui signifie que l'absence de chiffrement doit être justifiée, pas l'inverse. Concrètement, lors d'une violation de données, la question posée est rarement « avez-vous été piraté ? » mais « aviez-vous pris les mesures raisonnables ? ». Un stockage en clair sur un téléphone, très mal.

Le OWASP Mobile Top 10 reste la référence la plus utile pour se situer, même s'il est imparfait.

Pratique	Effort à mettre en place	Impact réel observé
Chiffrement du stockage local	Faible (une librairie)	Élevé — supprime la fuite la plus banale
Certificate pinning	Moyen — quelques heures, plus les mises à jour de certificat	Élevé contre l'interception
Obfuscation	Faible en configuration, moyen à maintenir	Moyen — retarde l'analyse
Détection de root et d'intégrité	Moyen	Faible seul, utile en complément
Test d'intrusion annuel	Élevé (budget)	Élevé — trouve ce que les outils ne voient pas

Les tests d'intrusion mobiles coûtent généralement entre quelques milliers et quelques dizaines de milliers d'euros selon la surface. C'est un budget, pas une formalité. Mais l'analyse statique (SAST) et dynamique (DAST) intégrée à la CI détecte une bonne partie des erreurs les plus grossières sans mobiliser d'humain.

Trois erreurs que j'ai commises — et que je vois partout

La première, c'est d'avoir cru qu'une application « interne » pouvait se passer de protections. Une app distribuée à cinquante commerciaux, sans vérification d'intégrité, sans pinning, avec les données clients en clair dans une base locale. Elle a fini sur un téléphone perdu dans un taxi.

La deuxième, c'est d'avoir repoussé la migration vers EncryptedSharedPreferences « au prochain sprint ». Le prochain sprint a duré huit mois.

La troisième, plus embarrassante : avoir fait confiance à un SDK tiers pour la gestion de session sans vérifier comment il stockait son jeton. Il le stockait dans un fichier de préférences non chiffré, évidemment. On a fini par écrire la couche nous-mêmes.

Par où commencer, concrètement

Si vous êtes utilisateur, la réponse est simple : activez le verrouillage natif de votre système (Samsung, Android stock, ce que vous avez), utilisez les codes intégrés des applications sensibles, et méfiez-vous des app lock publicitaires. Ça couvre l'immense majorité des scénarios quotidiens.

Si vous développez, l'ordre qui me paraît le plus rentable est celui-ci :

1. Auditez ce qui est stocké localement. Chiffrez tout ce qui est sensible.
2. Activez le pinning sur les endpoints critiques.
3. Passez l'obfuscation en configuration de production, systématiquement.
4. Mettez en place une analyse automatique dans la CI.
5. Planifiez un test d'intrusion quand le produit est stable — pas après la première fuite.

Cette hiérarchie n'est pas magique. Elle vient de ce que j'ai vu échouer et de ce qui a tenu. Le reste, c'est du raffinement.

Ce qui reste après tout ça

La sécurité mobile n'est pas un état, c'est une trajectoire. Chaque mise à jour de dépendance rouvre des questions, chaque nouvelle API ajoute une surface, chaque raccourci pris « pour aller plus vite » devient une dette qu'un attaquant finira par rembourser à votre place.

Ce qui m'a le plus surpris en observant ce milieu, c'est à quel point les fuites sont rarement sophistiquées. Il n'y a presque jamais d'exploit exotique. Il y a un jeton en clair, un certificat accepté sans vérification, un log oublié. La sécurité des applications mobiles, c'est essentiellement une discipline de propreté, appliquée avec constance.

La question qui vaut la peine d'être posée n'est donc pas « mon application est-elle sécurisée ? » — la réponse est toujours non. C'est : « quel est le prochain raccourci que je m'apprête à prendre, et combien me coûtera-t-il dans dix-huit mois ? »