Le contexte a beaucoup chang\u00e9 depuis les premi\u00e8res versions du syst\u00e8me. Google filtre davantage les applications, impose des versions cibles r\u00e9centes et a lanc\u00e9 la v\u00e9rification d\u2019identit\u00e9 des d\u00e9veloppeurs. Mais les attaques ont suivi : chevaux de Troie bancaires, kits de d\u00e9veloppement (SDK) pi\u00e9g\u00e9s, abus des services d\u2019accessibilit\u00e9. Voici les six risques \u00e0 surveiller dans tout projet de d\u00e9veloppement Android, avec les mesures recommand\u00e9es par l\u2019OWASP et par la documentation officielle d\u2019Android.<\/p>\n Les malwares restent la premi\u00e8re menace sur Android. Selon le bilan de s\u00e9curit\u00e9 2025 publi\u00e9 par Google<\/a>, plus de 1,75 million d\u2019applications contraires aux r\u00e8gles ont \u00e9t\u00e9 bloqu\u00e9es avant leur publication sur Google Play, plus de 80\u202f000 comptes de d\u00e9veloppeurs malveillants ont \u00e9t\u00e9 bannis, et Google Play Protect a rep\u00e9r\u00e9 plus de 27 millions de nouvelles applications malveillantes provenant de l\u2019ext\u00e9rieur du store.<\/p>\n Les familles qui dominent aujourd\u2019hui ne se contentent plus d\u2019envoyer des SMS surtax\u00e9s. On trouve surtout :<\/p>\n Pour le d\u00e9veloppeur, la cons\u00e9quence est directe : l\u2019application doit supposer qu\u2019elle peut tourner sur un appareil compromis. Il faut prot\u00e9ger les \u00e9crans sensibles contre la capture et la superposition, ne jamais faire confiance aux donn\u00e9es venant de l\u2019appareil et v\u00e9rifier c\u00f4t\u00e9 serveur, avec l\u2019API Play Integrity<\/a>, que les requ\u00eates viennent bien de votre application authentique.<\/p>\n Les smartphones Android ne fonctionnent pas tous sous la m\u00eame version du syst\u00e8me. Les fabricants arr\u00eatent les mises \u00e0 jour au bout de quelques ann\u00e9es et de nombreux appareils en circulation ne re\u00e7oivent plus les correctifs mensuels publi\u00e9s dans les bulletins de s\u00e9curit\u00e9 Android<\/a>. Une faille corrig\u00e9e dans une version r\u00e9cente reste donc exploitable sur une partie de vos utilisateurs.<\/p>\n Google a durci les r\u00e8gles pour limiter le probl\u00e8me. Depuis Android 14, une application qui cible une version d\u2019API inf\u00e9rieure \u00e0 23 ne peut plus \u00eatre install\u00e9e<\/a>, car de nombreux malwares visaient d\u2019anciennes versions pour contourner le syst\u00e8me d\u2019autorisations. Et Google Play impose une version cible r\u00e9cente : depuis le 31 ao\u00fbt 2026, les nouvelles applications et les mises \u00e0 jour doivent cibler Android 16 (API 36)<\/a>.<\/p>\n En pratique, choisissez une version minimale (minSdk) qui \u00e9carte les appareils sans correctifs quand votre application manipule des donn\u00e9es sensibles, et pr\u00e9voyez dans le budget la mise \u00e0 jour annuelle de la version cible. C\u2019est un poste de maintenance \u00e0 part enti\u00e8re, au m\u00eame titre que les correctifs fonctionnels.<\/p>\n La libert\u00e9 de personnalisation d\u2019Android a un revers. Les constructeurs (Samsung, Xiaomi, Oppo et bien d\u2019autres) ajoutent leurs propres surcouches et applications syst\u00e8me, avec un rythme de correctifs qui varie d\u2019une marque \u00e0 l\u2019autre. Certains utilisateurs vont plus loin : appareil root\u00e9, ROM alternative ou lanceur tiers t\u00e9l\u00e9charg\u00e9 hors du store. Sur ces appareils, les protections du syst\u00e8me ne sont plus garanties et un lanceur malveillant peut, par exemple, rediriger une ic\u00f4ne vers une fausse application pour du hame\u00e7onnage.<\/p>\n Une application qui manipule de l\u2019argent, des donn\u00e9es de sant\u00e9 ou des acc\u00e8s professionnels doit savoir dans quel environnement elle tourne. Le verdict d\u2019int\u00e9grit\u00e9 de l\u2019API Play Integrity indique si l\u2019appareil est certifi\u00e9 et si l\u2019application n\u2019a pas \u00e9t\u00e9 modifi\u00e9e. \u00c0 vous de d\u00e9cider ensuite de la r\u00e9ponse : simple avertissement, fonctionnalit\u00e9s limit\u00e9es ou blocage des op\u00e9rations sensibles.<\/p>\n Le t\u00e9l\u00e9chargement d\u2019applications depuis des sites non officiels reste la principale porte d\u2019entr\u00e9e des malwares. L\u2019utilisateur cherche une version gratuite d\u2019une application payante et r\u00e9cup\u00e8re une copie modifi\u00e9e qui installe un virus. Pour votre application, le risque est double : vos utilisateurs peuvent installer une fausse version qui porte votre nom, et votre code peut \u00eatre d\u00e9compil\u00e9 pour en extraire des cl\u00e9s ou de la logique m\u00e9tier.<\/p>\n Google a lanc\u00e9 en 2026 la v\u00e9rification des d\u00e9veloppeurs Android<\/a> : sur les appareils certifi\u00e9s, les applications devront provenir de d\u00e9veloppeurs dont l\u2019identit\u00e9 a \u00e9t\u00e9 v\u00e9rifi\u00e9e, m\u00eame lorsqu\u2019elles sont distribu\u00e9es hors de Google Play. Les protections ont d\u00e9marr\u00e9 le 30 septembre 2026 au Br\u00e9sil, en Indon\u00e9sie, \u00e0 Singapour et en Tha\u00eflande, et doivent s\u2019\u00e9tendre au monde entier en 2027. Si vous distribuez une application en dehors du store, par exemple une application interne d\u2019entreprise, inscrivez votre compte de d\u00e9veloppeur d\u00e8s maintenant.<\/p>\n C\u00f4t\u00e9 code, ne stockez aucun secret dans l\u2019application (cl\u00e9 d\u2019API priv\u00e9e, mot de passe de service) : tout ce qui est embarqu\u00e9 dans l\u2019APK finit par \u00eatre lu. Les secrets restent sur le serveur, et l\u2019application obtient des jetons \u00e0 dur\u00e9e de vie courte.<\/p>\n Publier une application Android sur Google Play<\/a> reste simple, et des milliers d\u2019applications arrivent chaque jour. Malgr\u00e9 les contr\u00f4les automatiques et humains, certaines applications malveillantes passent le filtre et sont retir\u00e9es apr\u00e8s coup. Le risque ne vient pas seulement des autres applications install\u00e9es sur le t\u00e9l\u00e9phone : il peut se trouver dans la v\u00f4tre.<\/p>\n Une application Android moderne embarque des dizaines de biblioth\u00e8ques : analytics, publicit\u00e9, paiement, cartographie, chat. Chacune a acc\u00e8s aux m\u00eames autorisations que votre application. Un SDK compromis ou trop curieux peut collecter des donn\u00e9es \u00e0 votre insu, et c\u2019est votre application qui sera retir\u00e9e du store ou mise en cause au titre du RGPD. C\u2019est le m\u00eame probl\u00e8me de cha\u00eene d\u2019approvisionnement logicielle que l\u2019OWASP classe d\u00e9sormais parmi les risques majeurs des applications web.<\/p>\n Les bonnes pratiques : n\u2019ajouter que les SDK n\u00e9cessaires, consulter le Google Play SDK Index avant de choisir une biblioth\u00e8que, figer les versions, surveiller les vuln\u00e9rabilit\u00e9s connues des d\u00e9pendances et v\u00e9rifier ce que chaque SDK d\u00e9clare dans la section \u00ab S\u00e9curit\u00e9 des donn\u00e9es \u00bb de votre fiche Play Store.<\/p>\n En 2014, la faille Heartbleed dans OpenSSL a montr\u00e9 qu\u2019une biblioth\u00e8que largement utilis\u00e9e pouvait exposer des millions d\u2019applications sans faute de leurs d\u00e9veloppeurs. Ce risque existe toujours, mais la plupart des incidents viennent aujourd\u2019hui d\u2019erreurs dans le code de l\u2019application elle-m\u00eame. Les plus fr\u00e9quentes dans le d\u00e9veloppement Android :<\/p>\n Beaucoup de ces erreurs viennent aussi du comportement des utilisateurs, qui accordent trop vite des autorisations. Nous l\u2019expliquons dans notre article sur la s\u00e9curit\u00e9 et les autorisations dans le d\u00e9veloppement mobile<\/a>.<\/p>\n Pour ne rien oublier, la r\u00e9f\u00e9rence est l\u2019OWASP MASVS<\/a> (Mobile Application Security Verification Standard), le standard de l\u2019OWASP pour la s\u00e9curit\u00e9 des applications mobiles. Il regroupe les exigences en huit familles, que l\u2019on peut traduire en questions concr\u00e8tes pour un projet de d\u00e9veloppement Android :<\/p>\n Le guide de test associ\u00e9, l\u2019OWASP MASTG<\/a>, d\u00e9crit comment v\u00e9rifier chaque exigence. C\u2019est la grille qu\u2019utilisent la plupart des auditeurs lors d\u2019un test d\u2019intrusion mobile.<\/p>\n Chaque version d\u2019Android ajoute des protections qui obligent \u00e0 adapter le code. Celles d\u2019Android 16 (API 36)<\/a> concernent directement la s\u00e9curit\u00e9 :<\/p>\n Ajoutez-y les deux r\u00e8gles de Google d\u00e9j\u00e0 cit\u00e9es : la version cible Android 16 exig\u00e9e sur Google Play depuis le 31 ao\u00fbt 2026 et la v\u00e9rification des d\u00e9veloppeurs, qui s\u2019\u00e9tend en 2027. Android 17 (API 37) est d\u00e9j\u00e0 disponible pour les d\u00e9veloppeurs : int\u00e9grez ses changements de comportement dans votre plan de maintenance avant que Google Play ne l\u2019impose.<\/p>\n Aucun logiciel n\u2019est infaillible. La bonne nouvelle est que la plupart des failles se d\u00e9tectent avant la mise en production, \u00e0 condition de les chercher. Trois niveaux de contr\u00f4le se compl\u00e8tent : l\u2019analyse automatique du code et des d\u00e9pendances \u00e0 chaque build, la revue de code sur les fonctions sensibles, et un test d\u2019intrusion mobile avant chaque version majeure.<\/p>\n Un pentest d\u2019application mobile men\u00e9 selon l\u2019OWASP MASTG co\u00fbte en g\u00e9n\u00e9ral entre 3\u202f500 et 12\u202f000\u00a0\u20ac HT selon le nombre d\u2019\u00e9crans, les API test\u00e9es et la profondeur demand\u00e9e. Le d\u00e9tail des prix par type de test est dans notre guide sur le co\u00fbt d\u2019un test d\u2019intrusion en France<\/a>. Fourchettes indicatives de march\u00e9, hors TVA. Le prix ferme figure dans la proposition de l\u2019entreprise que vous retenez.<\/em><\/p>\n Chez Yeeply, nous travaillons avec des entreprises certifi\u00e9es sp\u00e9cialis\u00e9es en d\u00e9veloppement d\u2019applications Android et iOS<\/a>, qui int\u00e8grent ces contr\u00f4les d\u00e8s la conception et peuvent faire auditer l\u2019application avant sa sortie. Pour recevoir une proposition, cliquez sur \u00ab Recevoir un devis \u00bb<\/strong> en haut \u00e0 droite de la page ou \u00e9crivez-nous \u00e0 sales@yeeply.com.<\/p>\nSommaire<\/summary>\n
\n
1. Les logiciels malveillants ou malware<\/em><\/h2>\n
![\"S\u00e9curit\u00e9](\"https:\/\/yeeply.com\/fr\/wp-content\/uploads\/2016\/08\/S\u00e9curit\u00e9-dans-le-d\u00e9veloppement-dapplication-Android.png\" "\\"logo")
<\/p>\n\n
2. La fragmentation du parc Android<\/h2>\n
3. Les surcouches constructeurs et les appareils modifi\u00e9s<\/h2>\n
4. Les applications install\u00e9es en dehors de Google Play<\/h2>\n
5. Les applications malveillantes et les SDK tiers<\/h2>\n
6. Les failles introduites pendant le d\u00e9veloppement<\/h2>\n
\n
S\u00e9curiser le d\u00e9veloppement Android avec l\u2019OWASP MASVS<\/h2>\n
\n
Ce qui change avec Android 16 et les r\u00e8gles de Google Play<\/h2>\n
\n
Tester la s\u00e9curit\u00e9 d\u2019une application Android<\/h2>\n
![\"Proyecto](\"https:\/\/yeeply.com\/fr\/wp-content\/uploads\/2020\/04\/FR-CTA-projet-app.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"