Une application bancaire qui plante après une mise à jour reportée trois fois, un outil métier qui expose les données clients parce que le correctif n’a pas été appliqué : on rencontre ces situations chaque semaine en gestion de flotte mobile. Les mises à jour de sécurité pour les applications mobiles ne relèvent plus du simple réflexe d’hygiène numérique. Depuis l’entrée en vigueur du Cyber Resilience Act européen, elles engagent aussi la responsabilité légale des éditeurs.
Cyber Resilience Act : les mises à jour de sécurité deviennent une obligation légale
La plupart des guides en ligne répètent le même conseil : « pensez à mettre à jour vos applications ». Ce qu’ils ne précisent pas, c’est que le cadre réglementaire a changé en profondeur.
Le Cyber Resilience Act (CRA), règlement UE 2024/2847, publié au Journal officiel de l’Union européenne le 23 octobre 2024, impose aux fabricants et éditeurs de logiciels des exigences de cybersécurité couvrant tout le cycle de vie des produits numériques. Concrètement, une application mobile distribuée sur le marché européen doit bénéficier d’un suivi des vulnérabilités pendant toute sa durée d’utilisation prévue.
Les sanctions possibles vont jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial. On n’est plus dans la recommandation : l’éditeur qui ne fournit pas de correctifs de sécurité s’expose à des poursuites.
Pour les équipes de développement, cela change la donne sur plusieurs points :
- La transparence sur la durée de support devient obligatoire : dates de fin de maintenance, fréquence des mises à jour de sécurité, tout doit être documenté et accessible à l’utilisateur.
- Les applications préinstallées sur les smartphones sont concernées au même titre que celles téléchargées sur les stores.
- La notification rapide des vulnérabilités exploitées est désormais encadrée par des délais stricts, ce qui force les éditeurs à structurer leur processus de réponse aux incidents.
Vulnérabilités API et failles côté serveur : le angle mort des applications mobiles
Quand on parle de mise à jour d’application mobile, on pense d’abord au code installé sur le téléphone. En pratique, une part significative des failles de sécurité se situe côté serveur, dans les API que l’application appelle.
Le référentiel OWASP Mobile Top 10, dans sa version 2024, place les failles d’authentification et d’autorisation parmi les risques les plus fréquents. Une application peut afficher « à jour » sur le store tout en communiquant avec une API vulnérable qui n’a reçu aucun correctif.
Ce que ça implique en maintenance
Mettre à jour l’application sans patcher l’API revient à verrouiller la porte en laissant la fenêtre ouverte. On voit régulièrement des équipes qui déploient un correctif côté client Android ou iOS mais oublient la partie backend. Le plan de mise à jour doit couvrir l’application et son infrastructure serveur de façon synchronisée.
Les retours varient sur ce point selon la taille de l’équipe : une startup avec deux développeurs n’a pas la même capacité de réaction qu’un éditeur disposant d’une équipe sécurité dédiée. Le CRA ne fait pas de distinction, ce qui pose un vrai défi opérationnel pour les petites structures.
Différences Android et iOS dans la gestion des correctifs de sécurité
Sur le terrain, la gestion des mises à jour de sécurité ne se déroule pas de la même façon selon le système d’exploitation.
Android : fragmentation et mises à jour forcées
Google peut forcer la mise à jour d’une application via le Play Store lorsqu’une faille de sécurité critique est identifiée, quels que soient les paramètres configurés sur l’appareil. C’est un filet de sécurité utile, mais qui ne couvre que les applications distribuées via le store officiel.
La fragmentation reste le problème principal. Les correctifs du système d’exploitation Android dépendent du fabricant du téléphone, pas seulement de Google. Un appareil Samsung, Xiaomi ou Pixel ne reçoit pas les patchs au même rythme. Pour une flotte d’entreprise, cela complique le suivi.
iOS : uniformité mais dépendance totale à Apple
Apple contrôle la chaîne de bout en bout. Les mises à jour de sécurité iOS arrivent simultanément sur tous les appareils compatibles. En contrepartie, l’éditeur d’une application n’a aucune marge de manœuvre sur le calendrier de déploiement des correctifs système.
Avec iOS 26, Apple renforce encore les exigences de conformité pour les applications manipulant des données de paiement, ce qui oblige certains éditeurs à adapter leur code sous peine de rejet du store.
Mettre en place un cycle de mises à jour de sécurité efficace
Un correctif qui dort trois semaines dans une file d’attente de validation ne protège personne. La rapidité de déploiement est aussi déterminante que la qualité du patch.
Voici les points qu’on vérifie systématiquement quand on audite le processus de mise à jour d’une application mobile :
- Le monitoring des vulnérabilités couvre à la fois le code applicatif, les dépendances tierces (bibliothèques, SDK) et les API backend.
- Un processus de hotfix est documenté et testé : pouvoir déployer un correctif critique en moins de 48 heures n’est pas un luxe, c’est la norme que le CRA va imposer.
- Les données de support (durée de maintenance, fréquence des mises à jour) sont publiées et accessibles aux utilisateurs, conformément aux nouvelles obligations européennes.
- Les mises à jour automatiques sont activées par défaut côté utilisateur, avec une communication claire sur ce que chaque mise à jour corrige.
Protection des données personnelles et mises à jour
Chaque mise à jour d’application qui touche au traitement des données personnelles doit rester conforme au RGPD. Modifier un SDK de tracking ou changer de prestataire d’analytics dans un patch de sécurité peut créer un nouveau traitement de données non déclaré. Le correctif de sécurité ne dispense pas d’une vérification RGPD.
Le développement d’applications mobiles sécurisées repose sur cette double exigence : corriger vite les vulnérabilités tout en maintenant la conformité réglementaire sur la protection des données. Négliger l’un des deux expose l’éditeur autant que l’utilisateur.
