Sécuriser une application mobile : les points clés pour ne rien rater

Un développeur m'a envoyé un jour une capture d'écran de son app bancaire : il avait réussi à lire le jeton d'authentification d'un utilisateur en branchant simplement son téléphone sur un ordinateur, sans rien casser, sans root, sans jailbreak. Le téléphone était dans sa poche, déverrouillé par biométrie quelques secondes plus tôt, et toutes les données sensibles étaient rangées dans un fichier texte accessible à n'importe quel outil de débogage. Sécuriser une application mobile, ce n'est pas ajouter un cadenas visuel à la fin du projet. C'est une suite de décisions prises bien avant d'écrire la première ligne de code.

Je vais vous donner les points clés, dans l'ordre où ils comptent. Pas une liste de principes vagues, mais les endroits précis où les failles se logent réellement, et ce qu'on peut y faire.

Sécuriser une application mobile : qui protège quoi, exactement

La première confusion que je vois partout, c'est de mélanger trois périmètres distincts. Le système d'exploitation protège le téléphone. L'utilisateur protège ses accès. Vous protégez votre application et son backend. Personne ne fait le travail des deux autres.

Concrètement : vous ne pouvez pas empêcher un utilisateur de rooter son Android ou de jailbreaker son iPhone. Vous ne pouvez pas l'empêcher d'installer une app vérolée. Ce que vous pouvez faire, c'est refuser de faire confiance à l'environnement dans lequel votre code s'exécute, et adapter votre comportement en conséquence.

Ce que vous ne contrôlez jamais

Un appareil rooté peut lire la mémoire de votre processus. Un appareil avec un débogueur attaché peut intercepter vos appels. Une version modifiée de votre APK peut exécuter du code que vous n'avez pas écrit.

Je me souviens d'un projet où l'équipe avait passé deux semaines à implémenter une détection de root très élaborée. Elle fonctionnait. Le problème, c'est qu'au lieu de bloquer l'application, la détection se contentait de remonter un événement au serveur. Résultat : le serveur recevait un signal d'alerte et continuait à servir les données normalement. Détection sans conséquence, c'est du théâtre.

Ce que vous contrôlez vraiment

Le backend. C'est là que se joue la partie. Si votre API vérifie systématiquement l'identité de l'appelant, la portée de ses droits et la légitimité de chaque requête, alors même une app compromise ne peut pas faire grand-chose. Une app mobile est un client parmi d'autres. Traitez-la comme tel.

Le principe est simple à énoncer, moins à appliquer : ne faites jamais confiance à une décision prise côté client. Un prix, un rôle, un identifiant de compte, une limite d'usage — tout ça doit être revérifié à l'arrivée sur le serveur.

La checklist technique, phase par phase

Voici l'ordre dans lequel je travaille aujourd'hui. Il m'a fallu quelques ratés pour arriver à cette séquence.

Conception

Avant de coder, définissez ce qui est sensible. Un identifiant de session n'a pas la même valeur qu'un historique de navigation. Cette cartographie vous dit où concentrer l'effort, et surtout où vous n'avez pas besoin de vous battre.

Adossez-vous à un référentiel public plutôt que de réinventer vos propres règles. L'OWASP MASVS (Mobile Application Security Verification Standard) est le document le plus utile que je connaisse sur le sujet. Il liste les contrôles attendus par niveau, et il vous donne un vocabulaire commun avec votre équipe et vos auditeurs.

Développement

C'est ici que se prennent la plupart des mauvaises décisions, en général par commodité. Le stockage d'abord :

• Jetons et clés → Keychain sur iOS, Keystore sur Android. Pas de SharedPreferences, pas de fichier plist, pas de base locale non chiffrée.
• Données de session temporaires → mémoire uniquement, avec expiration explicite.
• Tout le reste, y compris les caches et les logs → considéré comme potentiellement lisible par un tiers.

Les logs, justement. Un jour, une équipe m'a montré une app qui écrivait le corps complet des réponses API dans ses logs de débogage. En production, la journalisation était désactivée — sauf qu'un build de test avait été distribué en interne et que les logs partaient sur un service de collecte tiers. Onze mois de trafic, dont des jetons d'accès, stockés chez un sous-traitant.

Autre point non négociable : le chiffrement du transport se vérifie côté client. HTTPS seul ne suffit pas si vous n'épinglez pas le certificat. Le certificate pinning empêche un proxy d'intercepter le trafic entre l'app et votre serveur, ce qui est le scénario classique quand quelqu'un veut comprendre comment votre API fonctionne.

Le pinning a un piège classique : si vous épinglez un certificat et que celui-ci expire sans qu'on ait prévu la rotation, vous rendez l'app inutilisable. J'ai vu une application grand public rester hors service pendant presque deux jours à cause de ça. Prévoyez toujours une clé de secours dans le pinning, et une procédure documentée pour la mettre à jour.

Publication

L'obfuscation ne protège pas vos secrets, elle ralentit simplement celui qui cherche. Sur Android, R8 fait déjà une partie du travail. Sur iOS, la compilation est plus fermée, ce qui ne vous dispense de rien.

Ce qui compte davantage à cette étape : vérifier qu'aucune clé d'API secrète ne se balade dans le binaire. Une clé de service embarquée dans une app est une clé publique, peu importe le nombre de couches d'obfuscation. Si vous avez besoin d'un secret côté serveur, faites-le transiter par votre backend.

Post-publication

Une fois l'app dans les stores, il vous reste à traiter deux choses : détecter et corriger.

La détection passe par la supervision : erreurs inhabituelles, pics de requêtes sur un endpoint sensible, tentatives d'authentification échouées qui s'enchaînent. Un changement de comportement est souvent le premier signe qu'un attaquant teste quelque chose.

La correction, c'est le cycle de mise à jour. Vous ne pouvez pas forcer tous les utilisateurs à mettre à jour, mais vous pouvez refuser de servir une version trop ancienne. Bloquez les versions qui ont une faille connue — pas toutes les versions anciennes, seulement celles qui posent un problème réel.

Le backend : la surface d'attaque qu'on oublie trop souvent

Je le redis parce que c'est l'erreur la plus répandue dans les projets mobiles : la sécurité de votre app, c'est majoritairement la sécurité de votre API. Or c'est là qu'on voit le plus d'approximations.

Les API sans contrôle d'accès

Un cas que j'ai rencontré : une API dont les routes étaient protégées par un jeton, sauf trois d'entre elles. Ces trois routes acceptaient un identifiant utilisateur en paramètre d'URL, et renvoyaient les données correspondantes. Sur quelqu'un d'autre. Sans vérification. L'app ne les appelait jamais dans ce cas de figure — mais l'app n'est pas le seul client possible.

Ce type de faille ne se voit pas dans une app mobile soignée. Elle se voit dans l'API. Corollaire : votre modèle de menace doit inclure un attaquant qui n'utilise pas votre app.

Tests et audit

Un audit ponctuel ne sert à rien s'il n'y avait pas de tests avant. L'ordre logique, c'est :

1. Analyse statique du code (SAST) à chaque build, pour attraper les mauvaises pratiques.
2. Analyse dynamique (DAST) sur les environnements de test, pour voir le comportement réel.
3. Test d'intrusion sur les flux critiques — authentification, paiement, récupération de compte.
4. Un canal de signalement ouvert, pour que quelqu'un d'extérieur puisse vous alerter au lieu de publier la faille.

Le point 4 est celui qu'on néglige le plus. Une page de contact dédiée à la sécurité coûte presque rien et évite de découvrir une faille par un post public.

Ce que coûte une faille, en vrai

Je ne vais pas vous sortir un chiffre tiré d'une étude que je n'ai pas lue. Ce que je peux vous dire, c'est ce que j'ai observé sur des projets réels.

Une correction de dernière minute sur un flux d'authentification, trois semaines avant une mise en production, a coûté à une équipe l'équivalent de deux mois-homme. Le problème n'était pas technique : il fallait reprendre le parcours utilisateur, retester, redéployer, et repasser par la validation des stores. Le coût réel d'une faille, c'est rarement l'exploitation. C'est la reprise.

Ajoutez à cela le volet réglementaire. En Europe, une violation de données personnelles peut impliquer une notification à l'autorité de contrôle et, dans certains cas, aux personnes concernées. Les amendes prévues par le RGPD sont proportionnées à la gravité et au chiffre d'affaires, ce qui rend tout calcul théorique peu utile. Ce qui est certain, c'est que la charge de la preuve vous incombe : si vous ne pouvez pas montrer que vous avez mis en place des mesures adaptées, la discussion est difficile.

Périmètre	Qui en est responsable	Ce qu'on peut réellement faire
Stockage local	L'éditeur	Keychain / Keystore, pas de secrets en clair
Transport réseau	L'éditeur	HTTPS + certificate pinning avec rotation prévue
Authentification	L'éditeur et l'utilisateur	Biométrie ou second facteur, jetons courts
Système d'exploitation	Le fabricant	Rien : on subit les correctifs, on bloque les versions trop anciennes
Comportement de l'utilisateur	L'utilisateur	Sensibilisation, et refus de faire confiance à l'appareil

Les questions qu'on me pose le plus souvent

Comment protéger son téléphone contre le piratage ?

Du côté de l'utilisateur, l'essentiel tient en quelques gestes : mettre à jour le système dès que le fabricant le propose, n'installer des applications que depuis les stores officiels, vérifier les permissions demandées par chaque app (une lampe torche n'a pas besoin d'accéder aux contacts), et activer le verrouillage biométrique avec un code long plutôt qu'un schéma à quatre points.

Mais la vérité, c'est que la majorité des compromissions de comptes ne passent pas par une faille technique sur le téléphone. Elles passent par un mot de passe réutilisé, un lien de phishing, ou une app installée depuis une source douteuse. La protection technique ne sert à rien si le facteur humain ouvre la porte.

Un point concret, souvent négligé : le verrouillage d'écran. Un téléphone sans code est un téléphone ouvert à toute personne qui le tient trente secondes. C'est le premier verrou, et il est gratuit.

Faut-il verrouiller les applications une par une ?

Les systèmes proposent maintenant un verrouillage par application, avec réauthentification à l'ouverture. C'est utile pour les apps bancaires ou de messagerie, surtout si vous prêtez votre téléphone. Cela dit, ce mécanisme protège contre quelqu'un qui a déjà votre téléphone déverrouillé. Il ne protège pas contre une app compromise : si le code de l'application est vulnérable, le cadenas de l'interface ne change rien à ce qui se passe en dessous.

Je le vois comme une ceinture de sécurité, pas comme un airbag. Utile, jamais suffisant.

Ce qui reste après tout ça

La sécurité d'une application mobile n'a pas de fin. Chaque mise à jour peut rouvrir une porte fermée, chaque nouvelle dépendance ajoute du code que vous n'avez pas écrit, chaque changement de comportement utilisateur déplace le risque.

Si je devais ne retenir qu'une chose : le jour où vous vous dites que votre app est sécurisée, c'est probablement le moment où vous avez arrêté de regarder. Le travail utile, c'est la surveillance régulière, les mises à jour de dépendances, et la relecture des flux sensibles à chaque nouvelle fonctionnalité. Le reste, c'est du confort.