Mises à jour OTA que mises à jour over the air poussées vers une application mobile après l'installation, généralement vers le JavaScript, le HTML, le CSS et les assets dans un shell natif, sans remplacer le binaire complet du store. Cela est distinct des mises à jour OTA système, qui mettent à jour iOS ou Android lui-même. Une L'app OTA est conçu pour recevoir ces livraisons au niveau applicatif en toute sécurité.
L’OTA est la solution que les équipes privilégient lorsqu’une correction JavaScript, une modification de texte, un ajustement CSS ou une mise à jour d’asset approuvée doit être déployée tout de suite, sans attendre la revue. Pour les limites de l’App Store et de Google Play, voir Mises à jour OTA et règles des stores. Pour le suivi des déploiements, voir les workflows de surveillance OTA pour Capacitor.
Vous avez probablement déjà vécu cette situation. Un libellé de paiement cassé, une coquille sur un écran en production ou une régression de style est corrigé en quelques minutes, puis reste bloqué dans la file de release de quelqu’un d’autre pendant que les clients continuent de voir le bug.
Table des matières
- Le problème d’attente que connaît chaque équipe mobile
- Mises à jour OTA : ce que signifie vraiment OTA
- Paquets complets, patchs différentiels et instantanés
- Signature, transport et rollback : les bases de la sécurité
- Capacitor live updates, Ionic OTA et applications natives côte à côte
- Canaux de déploiement et rollback comme boucle opérationnelle
- Pièges courants et garde-fous pour les éviter
Le problème d’attente que connaît chaque équipe mobile
Un développeur déploie un correctif de production avant le déjeuner, puis passe l’après-midi à surveiller le statut de la revue. Le code est prêt, mais la release ne l’est pas, car le store d’applications a son propre processus d’approbation et ses propres délais. Apple indique qu’elle examine les applications, mises à jour, bundles, achats in-app et événements in-app soumis via App Store Connect, avec des objectifs affichés de au moins 50 % en moins de 24 heures et 90 % en moins de 48 heures. Pour une équipe qui corrige une chaîne de caractères, un problème de mise en page ou un asset non natif, cette attente peut donner l’impression d’attendre devant la porte alors que le correctif est déjà compilé. Processus de revue des applications Apple et objectifs de délais
L’OTA vous offre une seconde voie de livraison pour les modifications éligibles au niveau de l’application. Le store conserve le contrôle du binaire natif et de tout ce qui est lié aux permissions de la plateforme ou au comportement exécutable. Pour un workflow Capacitor, consultez les live updates Capacitor sur Capgo et lire Le guide de Capgo : mises à jour via les stores ou directes pour identifier précisément quels changements relèvent de chaque voie.
L’OTA n’est pas un contournement de la revue. C’est un chemin contrôlé pour les parties de l’application qui peuvent évoluer sans remplacer la coquille native. La question centrale n’est donc pas de savoir si la mise à jour est petite, mais si elle reste dans la limite autorisée par le store et votre runtime.
Mises à jour OTA : ce que signifie vraiment OTA
OTA signifie over-the-air. En pratique, cela signifie que la mise à jour atteint un appareil ou une app à distance via Internet, plutôt que par un câble, une réinstallation manuelle ou un nouveau package physique. Pour les applications mobiles, cela signifie généralement que le shell natif reste en place pendant que le runtime récupère de nouveaux assets de la couche web tels que JavaScript, CSS, texte, configuration et autres ressources autorisées. L’explication de Capgo sur les live updates pour Capacitor
Deux sens que l’on confond souvent
Dans le domaine des systèmes d'exploitation, l'OTA peut désigner une mise à jour du firmware ou du système livrée directement à un téléphone ou un appareil. Dans le développement d'apps, cela désigne souvent un bundle qui met à jour la couche web sans remplacer le conteneur natif. La documentation OTA d'Android couvre le côté système, y compris les chemins de mise à jour pour l'OS et les composants de la partition système, tandis que des frameworks comme Capacitor appliquent ce même modèle de livraison aux assets web à l'intérieur d'un shell d'app validé. L’architecture OTA d’Android
Cette distinction est importante, car la validation par les stores et l'OTA remplissent des rôles différents. Le store agit comme l'inspecteur du bâtiment lors d'une rénovation de cuisine, en vérifiant les travaux structurels majeurs avant la livraison. L'OTA, c'est l'équipe de réparation qui peut changer les poignées de tiroirs, les équipements et la déco murale sans démolir la pièce. Cette comparaison ne vaut que dans le shell d'app approuvé. Dès que le changement touche à un nouveau comportement natif, la limite est franchie.
Règle pratique : si la modification altère le code exécutable, les permissions, les entitlements ou l'objectif principal de l'app, elle ne relève pas de l'OTA.
Les directives d'App Review d'Apple 2.5.2 tracent clairement cette limite. Capacitor et la livraison OTA d'Ionic restent dans le périmètre du binaire déjà examiné, tandis que le store garde la main sur tout ce qui modifie le comportement natif. Pour retrouver les règles d'Apple et de Google au même endroit, voir Les apps OTA : les règles de l'App Store et de Google Play. Cette même limite explique pourquoi les équipes qui utilisent les live updates pour Capacitor doivent séparer les correctifs de la couche web des changements qui exigent un nouveau binaire, comme décrit dans les limites des live updates et des releases Capacitor et Ligne directrice 2.5.2 et limites OTA pour Capacitor et Ionic.
Paquets complets, patchs différentiels et instantanés
Les systèmes OTA n’envoient pas tous le même type de payload. Certains renvoyent l’intégralité du bundle, d’autres seulement les modifications, et d’autres encore conservent un instantané de l’état pour que le client puisse activer la version en toute sécurité et effectuer un rollback si nécessaire. Le meilleur choix dépend de la fréquence des modifications des fichiers et du coût de leur transfert.
Un package complet est le modèle le plus simple. Il réémet l'intégralité du bundle, ce qui est facile à appréhender mais plus lourd à télécharger. La livraison différentielle est plus ciblée, car elle n'envoie que les différences entre les versions. Cela convient aux bundles JS mobiles qui changent souvent et ne doivent pas gaspiller les données de l'utilisateur à chaque release. Les systèmes de type snapshot vont encore plus loin. Ils conservent un enregistrement compact de l'état précédent, ce qui permet au client de changer de version avec moins de stockage et un rollback plus propre. Why delta updates reduce payload size
| Comparaison des formats OTA | Ce qui est déployé | Le plus adapté | Compromis |
|---|---|---|---|
| Package complet | Le bundle entier à nouveau | Petites apps, releases rares, pipelines simples | Plus facile à build, plus lourd à télécharger |
| Patch différentiel | Uniquement les fichiers ou blocs modifiés | bundles JS, mises à jour d'assets, correctifs fréquents | Plus de logique pour générer et appliquer |
| Mise à jour de type snapshot | Représentation compacte de l'état entre les checkpoints | Systèmes nécessitant une activation compatible avec le rollback | Plus de composants à gérer dans l'updater |
Choisir la forme qui correspond à l'app
Pour une équipe Capacitor ou Electron, la question centrale est de savoir si le format du payload correspond au pattern de release. Si une seule image ou un seul fichier texte change, forcer un retéléchargement complet rend chaque mise à jour plus lourde qu'elle ne devrait l'être. Si le package est minuscule et rare, un moteur de delta peut ajouter de la complexité sans réel bénéfice.
Règle pratique : choisissez la forme de mise à jour qui reflète la façon dont vos fichiers changent réellement, pas celle qui a le diagramme d'architecture le plus tape-à-l'œil.
Android applique la même idée au niveau de l'OS. Les mises à jour Virtual A/B gardent les partitions critiques au démarrage compatibles avec le rollback, tandis que les modifications de partitions dynamiques sont représentées sous forme de snapshots compressés. Cela réduit le besoin de tout dupliquer physiquement et permet à l'appareil d'activer les changements avec moins de stockage gaspillé. Le modèle de mise à jour Virtual A/B d'Android
Si votre cadence de release est hebdomadaire et qu'un ou deux fichiers seulement changent, un patch différentiel vaut généralement le coup. Si vous déployez un bundle complet chaque trimestre, le moteur de delta est une complexité dont vous n'avez pas besoin.
Signature, transport et rollback : les bases de la sécurité
L'OTA est un canal de diffusion privilégié, la sécurité doit donc être multicouche et réfléchie. Commencez par un transport chiffré, ajoutez un bundle signé, protégez les clés de signature et prévoyez un rollback si le nouveau bundle pose problème. Vérification de la signature pour les live updates
Chaque contrôle bloque une attaque différente
Transport HTTPS protège le canal, mais le chiffrement du transport ne suffit pas à prouver l'auteur du payload. Signature cryptographique comble cette lacune. Le NIST indique que les signatures numériques garantissent l'intégrité et l'authentification de la source, afin que le runtime puisse confirmer que le package n'a pas été altéré et qu'il provient bien du signataire autorisé. Le NIST sur l'intégrité de la signature code et l'authentification de la source
Android concrétise ce contrôle de confiance. Les packages OTA doivent être signés avec une clé reconnue par le système, sinon l'installation est rejetée avant même l'exécution du bundle. La protection de la clé est aussi cruciale que la vérification de la signature. Des contrôles d'accès stricts et des procédures de rotation réduisent le risque qu'une clé compromise ne rende toutes les autres protections inutiles. Pour une vue pratique de l'implémentation, consultez la vérification de signature pour les live updates.
Le rollback fait partie de la sécurité, pas d'un add-on d'urgence
Le rollback doit faire partie de la même chaîne de contrôle que la signature, car un mauvais bundle qui reste actif crée un risque tant pour la sécurité que pour la fiabilité. Les tests de compatibilité réduisent les crashs dus à des interfaces natives incompatibles, le déploiement progressif limite le rayon d'impact, et le rollback basé sur l'état de santé de l'app permet de revenir à un état stable si la mise à jour échoue. L'artefact immuable exact doit être validé, pas seulement le manifeste ou une URL de téléchargement. Si seule la métadonnée est vérifiée, un attaquant peut remplacer les fichiers de payload après la validation.
Un package signé a tout de même besoin d'une porte de sortie. Si l'on ne peut pas revenir proprement à la version précédente, le processus de release expose les utilisateurs à un risque évitable.
Capacitor live updates, Ionic OTA et applications natives côte à côte
La réponse en matière d'OTA dépend de l'environnement d'exécution. Capacitor et Ionic s'exécutent dans un shell natif, l'OTA consiste donc généralement à déployer des assets web de confiance sans toucher au binaire natif. Electron offre une surface de mise à jour plus large, car il n'est pas soumis de la même manière à la revue de l'App Store ou du Play Store, mais la confiance dans le signataire reste essentielle, car les mises à jour automatiques peuvent être altérées si les contrôles d'intégrité sont insuffisants. Limites de l'OTA pour Capacitor et Ionic
Vue rapide par plateforme
| Plateforme | OTA fit | Ce qui nécessite encore une revue du store |
|---|---|---|
| Capacitor | JS, CSS, textes, config, assets compatibles | code natif, permissions, entitlements |
| Ionic | Identique à Capacitor, avec un ciblage par canal en complément | Tout ce qui modifie le comportement exécutable |
| Electron | Auto-update bundles from a trusted server or CDN | Pas de revue App Store ou Play, mais intégrité signée requise |
| Apps natives | L’OTA au niveau OS existe pour l’appareil lui-même | Les changements de logique applicative passent toujours par le store |
Les mises à jour des apps Android natives via Google Play restent médiatisées par le store, tandis que l’OTA système sur Android est un mécanisme distinct pour le système d’exploitation et les partitions système. Sur iOS, le binaire de l’app ne reçoit pas de mises à jour code qui modifient le comportement exécutable. C’est un point souvent confondu par les équipes produit, mais les règles des plateformes les maintiennent séparées.
Utilisez une checklist avant de qualifier quelque chose d’OTA
- Le code natif a-t-il changé ? Si oui, passez par la revue du store.
- Les permissions ou les entitlements ont-ils changé ? Si oui, il s'agit d'une release sur les stores.
- Le SDK ou le but de l’app a changé ? Si oui, traitez-le comme une mise à jour binaire.
- Seuls les assets web, le contenu ou une configuration approuvée ont changé ? Si oui, l'OTA est peut-être la bonne voie.
- Le runtime peut-il vérifier le bundle, cibler la bonne cohorte et effectuer un rollback ? Si non, bloquez la release.
Cette checklist trace la limite pratique. Elle évite aux équipes d'utiliser l'OTA comme une échappatoire et les aide à s'en servir pour ce qu'il fait de mieux : livrer des correctifs éligibles dans un shell validé.
Canaux de déploiement et rollback comme boucle opérationnelle
La valeur de l'OTA n'est pas la vitesse pure, mais la boucle qui l'entoure. Une équipe publie un bundle signé sur un canal spécifique, le client vérifie s'il est éligible, télécharge le delta ou le bundle, l'active au lancement et confirme si la nouvelle version est stable. Cela transforme la livraison de mises à jour en un système contrôlé plutôt qu'en un simple push unidirectionnel. L'approche de déploiement progressif de Capgo pour les live updates
Les canaux rendent le risque de release visible
Des flux distincts sont adaptés au développement, à la QA interne, à la bêta, à la production par étapes et à la production complète. Un bundle peut cibler une cohorte, une classe d'appareils, une plage d'ID client ou une version d'app, puis être promu uniquement quand les indicateurs sont au vert. C'est le même principe qu'une stratégie de déploiement blue-green, mais appliquée aux bundles mobiles que les utilisateurs téléchargent au lancement plutôt qu'aux serveurs backend qui basculent le trafic instantanément. Stratégie de déploiement blue-green de GoReplay
Les données de transparence d'Apple montrent l'échelle à laquelle ces systèmes opèrent, avec une moyenne de plus de 46,6 milliards de mises à jour automatiques d'apps et environ 701 millions de mises à jour manuelles d'apps par semaine en 2025. Données de transparence 2025 d'Apple À ce volume, un modèle de canaux n'est pas qu'une question d'esthétique : c'est ainsi que les équipes empêchent une mauvaise release de devenir un problème généralisé.
Le rollback doit être automatique, pas une cérémonie
Une bonne boucle OTA inclut des signaux d'échec clairs. Les pics de crash, les échecs d'installation, les problèmes de redémarrage ou les contrôles de boot-health doivent ramener le client vers le dernier bundle stable sans attendre qu'un humain remarque le problème sur le dashboard. Certaines plateformes, dont Capgo, exposent les canaux, les logs par appareil, les métriques d'adoption et d'échec, l'historique des versions, l'intégration CI/CD et la protection contre le rollback pour que le support et l'ingénierie puissent comprendre ce qui s'est passé après la release.
Bonne pratique : publiez un bundle, surveillez une cohorte, confirmez une base saine, puis élargissez la release uniquement si les données le permettent.
C'est cette boucle qui fait que l'OTA ressemble moins à un transfert de fichier qu'à de l'orchestration de release. Le bundle est important, mais c'est le plan de contrôle qui l'entoure qui sécurise la release.
Pièges courants et garde-fous pour les éviter
Une erreur OTA classique consiste à aller trop vite sans savoir qui a reçu la mise à jour, ce qui a échoué, ou si le nouveau bundle dépend d'une capacité native qui n'est pas encore présente. Une fois qu'une équipe s'habitue à pousser des changements en quelques minutes, il est facile de négliger la discipline qui rendait justement la voie des stores plus lente au départ.
Le premier mode de défaillance est la non-adoption pure et simple. Un appareil peut être hors ligne, occupé ou incompatible : la publication réussit, mais l'installation échoue. Le deuxième est l'adoption partielle, où un déploiement progressif n'atteint qu'une partie des utilisateurs et l'équipe confond une exposition limitée avec un succès généralisé. Le troisième est la casse silencieuse, où un bundle JS suppose une interface native plus récente et tout semble normal jusqu'à l'ouverture d'un écran précis.
Des garde-fous pour combler ces lacunes
- Vérification de la signature avant activation détecte les bundles altérés.
- Vérifications de compatibilité empêchent les runtimes incompatibles de charger le mauvais payload.
- Rollback basé sur l'état de santé empêche une mauvaise release de s'installer.
- Logs par appareil et historique des versions affichent ce que chaque utilisateur a exécuté.
- Une règle d'éligibilité OTA écrite exclut les changements natifs du canal de live update.
Les équipes soumises à des réglementations ont besoin d'une couche supplémentaire : l'auditabilité. Si un patch modifie un comportement visible par les clients, l'équipe doit pouvoir montrer exactement ce qui a changé, quelle cohorte l'a reçu et pourquoi le changement est resté dans le shell natif déjà revu. Cette piste d'audit évite que les OTA ne deviennent un canal de release non tracé.
Les objectifs de revue d'Apple, 50 % en moins de 24 heures et 90 % en moins de 48 heures, constituent le seuil opérationnel, pas le plafond. Les OTA existent pour les changements éligibles qui doivent être déployés entre ces deux fenêtres, et non pour ceux qui relèvent d'une publication sur les stores. La checklist de décision est simple. Si le correctif modifie le code natif, nécessite un nouvel entitlement ou dépend d'une capacité de plateforme qui n'est pas déjà présente, il ne peut pas être déployé via OTA. S'il reste dans le bundle signé, fonctionne avec le runtime actuel et peut subir un rollback propre, il a sa place dans le flux de live update.
