La sécurité application mobile se prépare avant la publication, pas après le premier incident. Pour réduire les risques, il faut vérifier le stockage des données, les échanges réseau, l’authentification, les permissions, les dépendances logicielles, la conformité RGPD et les exigences App Store et Google Play. Comptez souvent 2 à 5 jours d’audit pour une application simple, davantage si elle manipule paiement, santé, géolocalisation ou données sensibles.
Sécurité application mobile : ce qu’il faut contrôler avant publication
Une application mobile n’est pas seulement une interface posée sur un téléphone. Elle stocke parfois des informations, dialogue avec une API (serveur qui fournit les données), utilise des capteurs, demande des permissions et dépend de bibliothèques tierces. Chaque élément peut créer une faille.
Le référentiel le plus utile pour cadrer le sujet reste l’OWASP MASVS, maintenu par l’OWASP, une fondation reconnue en sécurité applicative. En 2025, sa checklist MAS couvre notamment le stockage, la cryptographie, l’authentification, le réseau, la plateforme, le code, la résilience et la confidentialité. Ce n’est pas réservé aux banques. C’est une base saine pour toute application sérieuse.
Le NIST, organisme américain de normalisation, a aussi formalisé dès 2019 un processus de vérification des applications mobiles dans la publication SP 800-163 Rev. 1. Son idée est simple : une application doit être évaluée par rapport à des exigences de sécurité définies, avec des analyses statiques, dynamiques et comportementales. En clair : lire le code, tester l’application en fonctionnement et observer ce qu’elle fait réellement.
La checklist avant mise en ligne
Voici la liste courte que tout dirigeant peut demander à son prestataire avant de valider une publication. Elle ne remplace pas un test d’intrusion, mais elle évite les oublis grossiers, ceux qui coûtent cher une fois l’application entre les mains des utilisateurs.
- Vérifier que les données sensibles ne sont pas stockées en clair sur le téléphone.
- Forcer HTTPS pour les échanges avec le serveur, quand le protocole est supporté.
- Limiter les permissions Android et iOS au strict nécessaire.
- Contrôler les dépendances open source et supprimer celles qui ont des vulnérabilités connues.
- Tester l’authentification, la déconnexion, l’expiration de session et la récupération de mot de passe.
- Valider les entrées utilisateur pour éviter injections, abus et plantages.
- Préparer une politique de confidentialité claire, accessible dans l’app et dans les métadonnées des stores.
- Mettre en place une procédure de mise à jour rapide en cas de faille.
Sur les projets que nous menons, nous voyons souvent un écart entre l’effort mis sur l’interface et celui consacré aux scénarios d’abus. Pourtant, le risque ne vient pas toujours d’un pirate sophistiqué. Il vient parfois d’un jeton d’accès (clé temporaire de connexion) gardé trop longtemps, d’un fichier de logs trop bavard ou d’une permission caméra demandée “au cas où”.
Données, permissions et RGPD : le triptyque qui pèse sur le risque
La première économie consiste à ne pas collecter ce dont vous n’avez pas besoin. Moins de données, c’est moins de responsabilité, moins de coûts de sécurisation et moins de friction lors de la validation par les stores. Le RGPD, applicable depuis 2018, impose de justifier la collecte, d’informer l’utilisateur et de protéger les données personnelles.
Android recommande en 2026 de minimiser les permissions, d’utiliser le stockage interne quand c’est possible et de valider les entrées. Le stockage interne signifie que les fichiers sont isolés dans l’espace privé de l’application, plutôt qu’exposés à d’autres apps ou à l’utilisateur via un dossier partagé. Ce choix technique a un effet direct sur votre niveau de risque.
Apple exige également, dans ses App Store Review Guidelines mises à jour en juin 2026, un lien vers la politique de confidentialité dans App Store Connect et à l’intérieur de l’application. C’est un point simple à anticiper, mais un oubli peut bloquer la publication. Perdre une semaine pour une page de confidentialité manquante, c’est rageant.
Le piège classique : demander trop de permissions au lancement. Une app de prise de rendez-vous qui réclame contacts, géolocalisation et notifications avant d’avoir expliqué leur usage déclenche de la méfiance. À budget égal, mieux vaut un parcours plus sobre qu’un tunnel riche en fonctionnalités mais anxiogène.
Code, dépendances et plateformes : ce que les stores regardent aussi
La sécurité application mobile dépend aussi de la fraîcheur technique. Google Play impose en 2025 que les nouvelles applications Android et les mises à jour ciblent Android 15, API level 35 ou supérieur, avec des règles spécifiques pour Wear OS, Android Automotive OS et Android TV. Ce niveau cible indique à Android quelles protections modernes l’application accepte d’utiliser.
Google Play exige aussi Play App Signing pour les apps distribuées via Google Play, sauf anciennes applications créées avant août 2021 qui peuvent encore distribuer des APK auto-signés. La signature sert à prouver qu’une mise à jour vient du bon éditeur. Si cette chaîne est mal gérée, vous pouvez vous retrouver bloqué au moment de corriger une faille.
L’OWASP MASVS-CODE recommande en 2025 trois réflexes pré-publication : utiliser une version de plateforme à jour, imposer les mises à jour applicatives quand nécessaire et n’utiliser que des composants sans vulnérabilités connues. Dit autrement : une belle app construite sur une dépendance abandonnée reste fragile.
Pour les architectures hybrides ou JavaScript, la vigilance concerne aussi le runtime, les packages npm et les ponts natifs. Le choix technique initial a donc un impact sécurité, maintenance et délai ; notre comparatif sur les runtimes JavaScript modernes aide à comprendre ces arbitrages côté serveur ou outillage.
Budget et délais réalistes pour sécuriser une application
La question budgétaire arrive vite. Elle est légitime. En France, selon les prestataires, une revue de sécurité légère avant publication démarre souvent autour de 1 500 à 3 000 € HT pour une application simple, sans données très sensibles. Un audit plus complet avec analyse de code, tests dynamiques et rapport exploitable se situe plutôt entre 4 000 et 12 000 € HT.
Pour une application fintech, santé, marketplace ou avec espace client exposant des documents, le budget peut grimper. Pas par luxe. Parce qu’il faut tester plus de scénarios : usurpation de compte, accès à des données d’un autre utilisateur, interception réseau, compromission du téléphone, contournement de paiement.
| Contrôle avant publication | Délai courant | Budget indicatif France | Quand le prévoir |
|---|---|---|---|
| Checklist OWASP MAS de base | 1 à 2 jours | 800 à 2 000 € HT | Application vitrine ou MVP sans données sensibles |
| Audit sécurité mobile standard | 3 à 5 jours | 3 000 à 7 000 € HT | Espace client, API, authentification, données personnelles |
| Test d’intrusion mobile approfondi | 1 à 3 semaines | 8 000 à 20 000 € HT | Paiement, santé, finance, données confidentielles |
| Remédiation après audit | 2 jours à 3 semaines | Selon corrections | Avant soumission App Store et Google Play |
Honnêtement, faire un test d’intrusion complet sur un prototype jetable ne se justifie pas toujours. En revanche, publier une app client sans revue minimale du stockage, des permissions et de l’API est une fausse économie. La bonne approche consiste à adapter le niveau de contrôle à l’exposition réelle.
Les erreurs qui font échouer une publication ou exploser la maintenance
Apple demande des applications finales et testées lors de la soumission. Ses règles 2026 indiquent aussi que les apps sont analysées pour détecter malware, logiciels nuisibles à la sécurité, à la sûreté et à la vie privée. Une app instable ou incomplète peut donc être refusée sans même parler de cybersécurité avancée.
Côté Android, le problème vient souvent d’une accumulation de compromis : permissions trop larges, dépendances non maintenues, configuration réseau permissive, absence de stratégie de mise à jour. Individuellement, chaque point semble mineur. Ensemble, ils créent une dette de sécurité.
Un cas fréquent : l’équipe reporte la sécurité “après la V1”. Mauvais calcul si l’architecture d’authentification est faible, car la corriger après coup touche l’application, l’API, les comptes utilisateurs et parfois le support client. À ce stade, le coût n’est plus celui d’un contrôle ; c’est celui d’une reprise.
La réglementation renforce aussi la pression sur certains secteurs. Les PME concernées par des obligations cyber peuvent consulter nos repères sur le Cyber Resilience Act, DORA pour les services financiers ou la directive NIS2. Même si votre application n’entre pas directement dans ces cadres, vos clients grands comptes peuvent vous demander des preuves de sécurité.
Comment piloter le sujet sans devenir expert technique
Vous n’avez pas besoin de lire tout le code pour piloter correctement la sécurité application mobile. Demandez plutôt des livrables vérifiables : une checklist remplie, la liste des dépendances, les versions cibles Android et iOS, les permissions justifiées, un rapport d’audit avec sévérité et corrections priorisées. Du concret.
Côté agence, le réflexe est de traiter la sécurité comme un critère de recette, au même titre que la performance ou l’ergonomie. Cela change les délais : on réserve quelques jours avant publication, au lieu de découvrir les failles pendant la soumission ou après un retour utilisateur inquiétant.
La sécurité serveur compte autant que l’application elle-même. Une app mobile irréprochable qui interroge une API mal protégée reste vulnérable. Les sujets de certificats, chiffrement et durcissement d’infrastructure rejoignent d’ailleurs les questions abordées dans notre analyse sur l’évolution des certificats SSL.
Cadrer ce type de projet en amont évite la plupart des mauvaises surprises : refus de store, dépassement budgétaire, correction tardive ou perte de confiance. Un regard extérieur aide surtout à choisir le bon niveau d’effort, ni symbolique, ni disproportionné.
FAQ sur la sécurité d’une application mobile
Quand faut-il faire un audit de sécurité mobile ?
Idéalement avant la publication, lorsque les fonctionnalités sont stables mais qu’il reste du temps pour corriger. Pour une app sensible, prévoyez l’audit au moins 2 à 4 semaines avant la date de lancement.
Une application validée par Apple ou Google est-elle sécurisée ?
Pas forcément. Les stores filtrent certains risques, imposent des règles et peuvent analyser les apps, mais leur validation ne remplace pas un audit de votre code, de votre API et de vos choix de stockage.
Quelle est la priorité si le budget sécurité est limité ?
Commencez par l’authentification, les données stockées sur le téléphone, les permissions et les communications HTTPS avec l’API. Ce sont souvent les zones où une erreur simple crée un risque élevé.
La sécurité retarde-t-elle forcément la sortie de l’application ?
Elle retarde surtout les projets où elle arrive trop tard. Intégrée dès la recette, une checklist sérieuse ajoute quelques jours, mais évite des corrections plus longues après refus du store ou incident.