Sécuriser ses applications mobiles contre les failles : le guide indispensable

Un client m'appelle l'autre matin, paniqué. Son app de gestion de stock affiche un écran blanc depuis la veille, et son prestataire lui répond « c'est un problème serveur, on regarde ». Deux jours plus tard, on découvre que le « problème serveur » était en fait une clé d'API laissée en clair dans le code de l'application Android. N'importe qui pouvait la récupérer en décompilant l'APK. Le préjudice réel ? Des données de facturation exposées pendant des semaines.

Cette histoire résume à peu près tout ce qui cloche dans la façon dont on aborde la sécurisation des applications mobiles contre les failles. On parle beaucoup de « protéger son téléphone », on installe un antivirus rassurant, et on oublie que la moitié des problèmes ne viennent pas de l'utilisateur mais du code lui-même. Alors il faut séparer deux métiers : celui qui développe l'app, et celui qui l'utilise. Les deux ont des gestes radicalement différents à faire.

Sécuriser ses applications mobiles : il y a deux camps, et ils ne font pas le même travail

La confusion la plus répandue, et celle qui coûte le plus cher, tient en une phrase : on demande à un utilisateur de faire le boulot d'un développeur. Combien de fois j'ai vu un patron d'entreprise installer un « anti-piratage » sur son téléphone en pensant que ça allait protéger l'app qu'il venait de financer ? Beaucoup trop.

Franchement, c'est deux chantiers distincts. Le premier concerne votre téléphone, l'autre concerne le logiciel que vous (ou quelqu'un que vous payez) avez écrit.

Côté utilisateur : ce que vous contrôlez vraiment

Vous ne pouvez pas auditer le code d'une app que vous téléchargez. Point. Ce que vous pouvez faire, c'est limiter la surface d'attaque : vérifier ce que l'app demande comme permissions, la tenir à jour, et éviter les sources d'installation douteuses. Un exemple concret : une app de lampe torche qui réclame l'accès à vos contacts et à votre position, c'est un signal. Pas une preuve de malware, mais un drapeau rouge que j'ai appris à ne plus ignorer.

Côté développeur : ce que vous devez absolument faire

Là, le travail est réel et mesurable. Le référentiel de référence s'appelle l'OWASP Mobile Application Security Verification Standard (MASVS). C'est un document public, gratuit, et il liste noir sur blanc ce qu'une app doit respecter : stockage sécurisé, communication chiffrée, authentification robuste, résistance à la falsification. Ce n'est pas une opinion, c'est un standard. Si votre prestataire ne le connaît pas, changez de prestataire.

Et le meilleur point de départ ? Faites tourner un outil d'analyse statique (SAST) sur votre base de code. J'ai vu des projets où la simple activation de ces outils remontait plusieurs dizaines d'avertissements que personne n'avait jamais regardés.

Faut-il activer la protection des applications ?

Oui, activez-la. Sur Android, cela veut dire laisser Play Protect allumé (c'est le cas par défaut, mais vérifiez), et sur iOS, garder les protections système du téléphone activées plutôt que de les désactiver pour « aller plus vite ». Le gain est réel : ces mécanismes scannent les apps installées et bloquent une partie des logiciels malveillants connus.

Mais attention à ne pas en attendre la lune. Un antivirus mobile, c'est une ceinture de sécurité — utile, pas magique. Il ne détectera pas une app parfaitement légitime qui envoie vos données vers un serveur non sécurisé. Cette faille-là se joue dans le code, pas dans le téléphone.

Comment puis-je sécuriser mon téléphone portable ?

La liste est courte, mais je vois encore beaucoup de monde sauter les deux premières lignes. Voici ce que je fais moi-même sur mon propre appareil, dans l'ordre :

• Verrouiller l'écran avec un code long (six chiffres minimum) plutôt qu'un simple schéma à quatre points.
• Activer le chiffrement du stockage — sur Android et iOS modernes, c'est natif dès que vous avez un code, il suffit de ne pas le désactiver.
• Vérifier les mises à jour système et ne pas repousser les mises à jour de sécurité « pour plus tard ».
• Passer en revue les autorisations app par app, une fois par trimestre, pour retirer celles dont l'app n'a pas besoin.
• Désactiver l'installation depuis des sources inconnues. Permanence.

Sur Samsung, c'est le même principe, avec des menus légèrement différents : le tableau de bord de sécurité dans les paramètres permet de lancer un scan et de vérifier l'état du chiffrement. Sur iPhone, la vérification de sécurité intégrée à l'appareil permet de révoquer l'accès partagé et de couper les partages de position que vous ne voulez plus.

Franchement, la plupart des piratages de téléphone que j'ai vus passer venaient de trois choses : un code trop simple, une app installée depuis un lien WhatsApp, ou une mise à jour repoussée pendant six mois.

Quelle application Android puis-je utiliser pour sécuriser mes applications ?

Aucune ne fera le travail à votre place, mais certaines aident. Play Protect est le garde-fou de base, intégré à Android, gratuit. Au-delà, un gestionnaire de mots de passe (Bitwarden, Proton Pass, celui de votre choix) est, à mon avis, la « security app » la plus utile qu'on puisse installer sur un téléphone. Il ne scanne rien, il empêche juste la pratique la plus dangereuse de toutes : réutiliser le même mot de passe partout.

Un VPN réputé, un gestionnaire de permissions (comme ceux intégrés aux surcouches récentes), un détecteur de fuite de mots de passe : ces outils ont leur valeur, mais aucun ne protège l'app elle-même contre ses propres failles.

Comment puis-je protéger mon application ?

Si vous êtes du côté développement, c'est ici que le vrai travail se joue. Voici les failles que je cite systématiquement, parce que ce sont celles que je retrouve dans presque tous les audits que j'ai pu faire ou voir de près.

Le stockage local non chiffré

La palme. Les tokens d'authentification, les identifiants de session, voire des mots de passe en clair dans les SharedPreferences Android ou les UserDefaults iOS. Un appareil volé ou rooté, et tout est lisible. La correction est simple : passer par le Keychain iOS ou le Keystore Android, ne jamais écrire de secret en clair.

Les communications mal protégées

Une app qui appelle une API en HTTP plutôt qu'en HTTPS, ou qui accepte n'importe quel certificat serveur. J'ai déjà vu une équipe désactiver la vérification de certificat « pour tester » — et oublier de la remettre en production. Une erreur à un caractère, des mois d'exposition.

Les dépendances tierces non vérifiées

Votre app embarque des bibliothèques écrites par d'autres. Si l'une d'elles a une faille, votre app l'a aussi. Auditez régulièrement vos dépendances, mettez-les à jour, supprimez celles qui ne servent plus.

L'absence de tests d'intrusion

Un test d'intrusion mobile, ce n'est pas du luxe. C'est ce qui a permis à mon client de découvrir sa clé d'API en clair. Une journée de travail d'un expert, souvent moins, et vous savez exactement où vous êtes exposé.

Faille	Côté concerné	Correctif principal	Effort
Stockage local en clair	Développeur	Keychain / Keystore	Faible
HTTP non chiffré	Développeur	TLS strict, pinning	Moyen
Dépendance obsolète	Développeur	Audit + mises à jour	Récurrent
Code d'écran faible	Utilisateur	Code long + biométrie	2 minutes
App installée hors store	Utilisateur	Sources inconnues désactivées	Immédiat

Ce que je retiens, et ce que j'ai raté au début

Quand j'ai commencé à m'intéresser sérieusement à ce sujet, je pensais qu'un antivirus mobile et un bon mot de passe suffiraient. J'ai eu tort. Les vraies failles vivent dans le code, dans une clé oubliée, dans une bibliothèque datée de deux ans. L'utilisateur, lui, a un rôle modeste mais non négligeable : fermer les portes qu'il peut fermer.

La prochaine fois que vous entendrez « c'est un problème serveur », posez une seule question : est-ce que quelqu'un a regardé le code de l'app ? Parce que, souvent, la réponse est non.