Sécurité des applications mobiles : protéger les données utilisateurs

Un développeur m'a montré son appli de suivi sportif, un truc qu'il avait mis dix mois à construire. Le code était propre, l'interface nickel. J'ai ouvert le fichier de config et j'ai trouvé une clé API d'accès à sa base utilisateurs, en clair, versionnée sur GitHub. Sa base contenait 40 000 emails, des dates de naissance et des tracés GPS au mètre près. Il a mis trois jours à comprendre pourquoi c'était grave. Trois jours. Voilà où on en est sur la sécurité des applications mobiles et la protection des données utilisateurs : le problème n'est presque jamais l'attaque sophistiquée qu'on imagine. C'est la ligne qu'on a oubliée.

Sécurité des applications mobiles : la vraie menace n'est pas celle qu'on croit

Quand on parle de protéger les données utilisateurs, l'imaginaire colle tout de suite au scénario du grand piratage. Un groupe organisé, des serveurs attaqués, un écran noir avec un crâne. Franchement, ça fait vendre des conférences. Mais dans la pratique, ce que je vois sur le terrain ressemble beaucoup moins à un film.

Les incidents que j'ai pu observer de près — une dizaine sur des projets qui m'entouraient, plus deux sur les miens — avaient tous la même origine : une négligence triviale. Aucun n'était spectaculaire.

• Un endpoint d'API sans authentification qui renvoyait le profil complet de n'importe quel utilisateur à partir d'un simple identifiant incrémental.
• Des logs de crash qui enregistraient en clair les tokens de session, conservés des mois sur un serveur tiers.
• Une fonction de partage qui transmettait le numéro de téléphone en paramètre d'URL, donc visible dans n'importe quel historique de proxy.
• Et le classique : la base de données de développement laissée ouverte, avec un dump de production importé dedans "pour tester plus vite".

Pourquoi une fuite de données reste souvent invisible

Le drame, c'est que rien de tout ça ne déclenche d'alarme. Une clé en clair ne fait pas de bruit. Un endpoint ouvert répond gentiment à qui le demande. Beaucoup d'applications mobiles se font vider discrètement pendant des mois sans que personne ne s'en aperçoive, parce qu'il n'y a aucun pic de trafic, aucune erreur serveur, aucun signe extérieur. On découvre le problème quand un utilisateur curieux écrit "tiens, j'ai vu mon mot de passe en clair dans l'appli". Et là, on réalise.

Ce constat change tout sur la méthode. Si la menace principale est l'accumulation de petites erreurs, alors la réponse n'est pas un pare-feu géant. C'est une discipline de tous les jours.

Ce que la CNIL attend vraiment d'une application mobile

Beaucoup d'éditeurs considèrent la conformité comme une formalité administrative. On télécharge un modèle de politique de confidentialité, on l'adapte à la va-vite, on l'accroche dans l'appli, et on passe à autre chose. J'ai fait exactement ça sur mon premier projet. Mauvaise idée.

Le régulateur ne lit pas votre politique de confidentialité en premier. Il regarde votre appli. Il l'installe, il l'ouvre, il observe ce qui part sur le réseau, et il compare avec ce que vous avez écrit. Si les deux ne collent pas, le problème n'est pas la formulation, c'est le fonctionnement même du produit.

La minimisation des données, un principe très concret

Le principe de minimisation dit qu'on ne collecte que ce qui est nécessaire à la finalité annoncée. Ça a l'air abstrait, ça ne l'est pas du tout. Prenons une appli de réservation de restaurant. A-t-elle besoin de l'accès permanent à la localisation en arrière-plan ? Non. Du carnet de contacts ? Certainement pas. De l'identifiant publicitaire ? Seulement si elle fait de la publicité ciblée, et il faut alors le dire.

Chaque permission que vous demandez sans justification réelle est une dette. Elle vous expose, et elle érode la confiance de l'utilisateur qui voit une demande qui n'a aucun sens pour le service rendu.

• Transparence : l'utilisateur doit comprendre ce qui est collecté, pourquoi, et combien de temps c'est conservé.
• Consentement : un accord libre, spécifique et révocable. Pas une case pré-cochée glissée dans des conditions générales de 40 pages.
• Contrôle : la possibilité concrète de supprimer son compte et ses données, pas un formulaire de contact renvoyant vers un service client injoignable.
• Finalité : une donnée collectée pour gérer un abonnement ne peut pas servir à alimenter un modèle publicitaire sans nouvelle base légale.

Que doivent contenir les mentions légales d'une application mobile ?

Une appli doit afficher, de façon accessible, l'identité de l'éditeur, ses coordonnées, et les informations sur le traitement des données. Ces mentions ne peuvent pas être enterrées au fond d'un écran qu'on n'atteint qu'après cinq clics. Un utilisateur qui cherche qui édite l'appli doit pouvoir le trouver en quelques secondes — sinon, en pratique, l'information n'existe pas.

Un détail que j'ai appris à mes dépens : une politique de confidentialité qui décrit une autre appli que la vôtre, parce qu'elle a été recopiée d'un modèle générique, est pire que pas de politique du tout. Elle prouve que vous n'avez pas réfléchi à votre propre traitement. C'est une pièce à charge, pas une défense.

Protéger les données personnelles : ce qui se joue côté technique

Voici le cœur du sujet. La conformité, c'est bien, mais elle ne vaut rien si le code laisse les données accessibles à qui sait où regarder. Et là, il y a des choix techniques qui changent tout.

Stocker les données au bon endroit sur iOS et Android

Sur un téléphone, il y a une différence énorme entre écrire un token dans un fichier de préférences ordinaire et l'écrire dans le trousseau sécurisé du système. Android propose le KeyStore, iOS propose le Keychain. Ces mécanismes protègent les secrets même si l'appareil est compromis ou si quelqu'un accède au système de fichiers. Un token de session dans un fichier texte, à l'inverse, c'est une clé sous le paillasson.

Je me souviens d'avoir repris une appli où tout était stocké dans les sharedPreferences, en clair. Une matinée de travail pour migrer les secrets vers le KeyStore. Une matinée. Le coût de cette négligence, lui, se compte en utilisateurs mécontents et en confiance perdue.

Permissions à l'exécution et cloisonnement

Le sandboxing empêche une appli d'accéder aux données d'une autre. C'est une protection de base du système, mais elle ne sert à rien si votre propre appli demande trop de permissions. La bonne pratique est simple : demander la permission au moment exact où elle devient utile, pas au démarrage. Une appli qui réclame l'accès à la caméra dès l'écran d'accueil, avant même d'avoir montré à quoi elle sert, c'est un signal d'alerte pour l'utilisateur comme pour un auditeur.

Pour les échanges réseau, deux réflexes rattrapent énormément de situations : forcer HTTPS partout (aucune exception pour le debug, même en recette) et bloquer les certificats non attendus. Cette dernière technique, le certificate pinning, empêche une attaque de type homme du milieu quand un utilisateur se connecte sur un réseau douteux. On verra plus loin que le Wi-Fi public reste le terrain de chasse favori.

Protéger ses données personnelles côté utilisateur : ce qui marche vraiment

On demande toujours aux utilisateurs d'être vigilants. C'est un peu facile de reporter la responsabilité sur eux. Mais il y a des gestes qui protègent réellement, et d'autres qui relèvent du rituel.

Pratique	Efficacité réelle	Effort demandé
Vérifier les permissions d'une appli à l'installation	Élevée — coupe l'accès direct aux données sensibles	Faible
Mettre à jour l'OS et les applis	Élevée — corrige des failles connues et exploitées	Minime, automatique
Installer une appli antivirus	Faible sur smartphone — surtout marketing	Moyen
Éviter les Wi-Fi publics non chiffrés pour les opérations sensibles	Moyenne à élevée selon l'usage	Faible si on utilise sa 4G/5G
Utiliser un gestionnaire de mots de passe	Élevée — élimine la réutilisation de mots de passe	Moyen au début, puis nul

Le point sur l'antivirus mérite qu'on s'y arrête, parce qu'il va contre une idée reçue. Sur un smartphone moderne, où les applis sont cloisonnées et distribuées via des stores qui filtrent, un antivirus tiers apporte peu. Il consomme de la batterie et donne surtout un faux sentiment de sécurité. Ce qui protège, c'est de refuser les permissions inutiles et de ne pas installer n'importe quoi hors des stores officiels.

Le Wi-Fi public est-il vraiment dangereux ?

Pas systématiquement, mais le risque existe réellement sur les réseaux ouverts sans chiffrement, où une personne placée sur le même réseau peut intercepter du trafic mal protégé. La parade est simple : pour consulter vos comptes bancaires ou vos messages, préférez votre connexion mobile. Et vérifiez que le cadenas HTTPS est bien là — c'est le minimum vital.

Auditer son appli : une grille de départ sans jargon

Concevoir une politique interne de protection des données personnelles, c'est bien. La tester, c'est mieux. Voici ce que je vérifie systématiquement quand je reprends une appli, et que beaucoup d'éditeurs sautent.

1. Chercher dans tout le dépôt de code les clés, tokens et mots de passe en dur. Un outil automatisé fait ça en quelques secondes. Si j'en trouve un seul, je considère qu'il faut tout reprendre.
2. Ouvrir l'appli et observer précisément ce qui part sur le réseau, requête par requête. Comparer avec ce que prétend la politique de confidentialité.
3. Passer en revue chaque permission demandée et se demander : à quelle finalité sert-elle ? Si la réponse est floue, la retirer.
4. Tester la suppression de compte de bout en bout. Est-ce que les données disparaissent réellement des serveurs, ou seulement de l'interface ?
5. Vérifier le comportement hors ligne. Les données mises en cache sont-elles chiffrées, ou lisibles par n'importe qui ayant accès au fichier ?

Ce n'est pas une méthode exhaustive, et ça ne remplace pas un test d'intrusion sérieux sur une appli financière ou de santé. Mais pour la grande majorité des applis, cette grille élimine déjà 80 % des problèmes que je rencontre.

Trois erreurs que je continue de voir partout

La première, c'est la politique de confidentialité copiée d'un concurrent. Elle mentionne des sous-traitants que vous n'utilisez pas et omet ceux que vous utilisez vraiment. C'est un aveu de négligence, et c'est facile à repérer.

La deuxième, c'est de croire que le chiffrement règle tout. Chiffrer une donnée qu'on n'aurait jamais dû collecter, c'est protéger un problème qu'on s'est créé soi-même. Si vous n'avez pas besoin de l'information, ne la stockez pas. Le meilleur chiffrement reste celui d'une donnée qui n'existe pas.

La troisième — et c'est celle qui m'a le plus coûté — c'est de considérer la sécurité comme un sprint. On sécurise avant la mise en production, on coche, on passe à la suite. Sauf que le code évolue, les dépendances changent, et un choix sûr aujourd'hui devient bancal dans six mois. J'ai vu une appli parfaitement sécurisée à sa sortie se retrouver exposée après deux ans, simplement parce que personne n'avait mis à jour une bibliothèque.

Alors voilà ce que j'ai fini par admettre : la sécurité d'une appli mobile ne se mesure pas au jour du lancement. Elle se mesure à la régularité avec laquelle on revient regarder ce qu'on a construit. Le développeur de l'appli de sport a corrigé sa clé en un après-midi. Ce qu'il a vraiment changé, ce jour-là, c'est de mettre un rappel dans son agenda pour tout revérifier, tous les trois mois. Cette habitude-là vaut plus que n'importe quel audit ponctuel. La vraie question n'est pas de savoir si votre appli est sécurisée aujourd'hui. C'est de savoir qui va vérifier, et quand — demain.