Réponse rapide : Mises à jour OTA (over-the-air) sont des modifications logicielles livrées à un appareil via un réseau, sans câble ni réinstallation physique. Apps OTA sont de vraies applications installées qui récupèrent ces mises à jour après téléchargement depuis le store ou l’image d’usine. Sur les téléphones, l’expression englobe les deux OTA sur l’appareil (par exemple les mises à jour système Android) OTA au niveau de l’app (live updates de la couche web dans les apps Capacitor ou Cordova, et live updates des bundles JavaScript dans les apps React Native).
Pour les limites conformes aux stores, lisez guide ultime des mises à jour OTA conformes aux stores. Pour la livraison live au niveau produit, voir les live updates Capacitor et le fonctionnement des live updates pour Capacitor.
OTA matériel et firmware vs OTA au niveau de l’application
OTA de l’appareil et du firmware met à jour le système d’exploitation ou le firmware radio. Les mises à jour OTA Android de Google ou du fabricant remplacent la partition système. iOS utilise des chemins over-the-air similaires pour les releases de la plateforme. Les utilisateurs les voient dans les réglages système, pas dans les notes de version de votre produit.
OTA au niveau de l’app les mises à jour que votre application charge à l’exécution, une fois l’installation déjà présente sur l’appareil. Dans les stacks hybrides, cela désigne généralement le JavaScript, le HTML, le CSS, les images, la configuration et les textes dans un WebView ou un moteur JavaScript. Le binaire natif qui a passé la revue de l’App Store ou de Google Play reste en place jusqu’à ce que vous déployiez une nouvelle build store.
| Couche | Ce qui change | Exemple typique |
|---|---|---|
| OTA de l’appareil | OS, pilotes, correctifs de sécurité | Prompt de mise à jour système Android |
| Mise à jour d’app via le store | APK ou IPA complet | Mise à jour in-app Google Play |
| OTA au niveau de l’app | Bundle web et assets d’exécution | canal Capacitor live update |
Les équipes Cordova et Capacitor font presque toujours référence à la troisième ligne lorsqu’elles posent la question les applications over the air ou un release OTA en CI. Si vous avez besoin d’une définition plus précise, qu’est-ce qu’une mise à jour OTA présente la même distinction avec des exemples mobiles.
Les mises à jour OTA sont-elles sûres et autorisées par Apple et Google ?
Sécurité repose sur la signature, les contrôles d’intégrité, les canaux progressifs, le rollback et la télémétrie, pas sur le mot OTA. Un updater de production doit vérifier les manifests, conserver un bundle connu bon et activer de façon atomique pour qu’un téléchargement partiel ne puisse pas casser l’app.
Politique des stores est distinct de l’ingénierie de la sécurité. Le contrat de licence du Apple Developer Program (section 3.3.1(B)) limite le code interprété livré après examen. Il doit rester dans le cadre de la fonction principale de l’application et éviter de contourner la sécurité de la plateforme. La directive 2.5.2 des App Review Guidelines interdit aussi les code téléchargés qui introduisent ou modifient des fonctionnalités. La directive 2.5.19 interdit les fonctionnalités cachées ou non documentées. Google Play autorise généralement les mises à jour de JavaScript et d’autres code web exécutés dans une WebView ou un moteur JavaScript embarqué, à condition qu’ils correspondent à la fonctionnalité déclarée de l’application. Les plugins natifs, les nouvelles autorisations ou les changements de SDK relèvent toujours d’une release sur le store sur les deux plateformes.
de Capgo guide des mises à jour OTA conformes aux stores traduit ces règles en choix concrets au quotidien. Pour le build vs buy en matière d’infrastructure, voir solutions de mise à jour d’application open source vs propriétaires.
Table des matières
- OTA matériel et firmware vs OTA au niveau de l’application
- Les mises à jour OTA sont-elles sûres et autorisées par Apple et Google ?
- Une définition pratique des mises à jour OTA
- Comment une mise à jour OTA atteint réellement un appareil
- Comparaison : mises à jour OS, in-app et live updates de bundle web
- Taux d'adoption : pourquoi ils comptent pour l'ingénierie
- Les vrais compromis des mises à jour OTA
- Framework de classification des changements : OTA vs releases sur les stores
- Les contrôles de sécurité qui rendent l'OTA fiable
- Questions fréquentes sur les mises à jour OTA
- Synthèse et choix d'une approche OTA
Une définition pratique des mises à jour OTA
C’est le vendredi après-midi que ces problèmes ont toujours l’air de surgir. Un parcours de paiement plante, le support contacte l’équipe technique, et quelqu’un se demande si ça nécessite une release sur le store ou si on peut déployer tout de suite. Si la modification ne touche que la couche web d’une app hybride, l’OTA peut faire la différence entre une récupération rapide et un long week-end d’attente.
At the simplest level, les mises à jour OTA sont des mises à jour logicielles livrées directement sur un appareil via un réseau sans fil, plutôt que par câble, installateur de bureau ou passage en atelier. En informatique mobile, Apple a fait de l’OTA un modèle de distribution central en ajoutant le support des mises à jour OTA dans iOS 5 en 2011. Le flux de base est direct : l’éditeur publie une release, les appareils éligibles sont notifiés, le package est téléchargé via le Wi-Fi ou la 4G/5G, l’appareil le vérifie, puis l’installe localement, généralement après un redémarrage. Présentation des mises à jour OTA sur Wikipédia capture clairement ce modèl’au niveau de l’appareil.
Le terme devient confus car on l’utilise pour plusieurs couches différentes. L’une d’elles est le système d’exploitation, où Apple ou un fabricant d’appareils Android pousse la mise à jour de la plateforme. L’autre est app package, où le flux de mise à jour in-app de Google Play peut mettre à jour le paquet d’application Android distribué. Une troisième est le bundle web runtime, où une application de type Capacitor peut récupérer du JavaScript, du CSS, des images ou du texte après que le binaire natif a déjà passé la revue.
Règle pratique : si l’appareil a déjà l’application ou le système d’exploitation installé et que la nouvelle version arrive par le réseau plutôt que par une nouvelle installation physique, vous êtes dans le périmètre de l’OTA.
Cette distinction est importante, car la même expression peut décrire des chemins de release radicalement différents. Un product manager peut dire « on le déploie en OTA », tandis que la réponse côté ingénierie dépend de savoir si le changement touche le code natif, le code interprété ou le système d’exploitation lui-même.
Comment une mise à jour OTA atteint réellement un appareil
Le pipeline semble simple en apparence, mais les systèmes OTA fiables doivent effectuer plusieurs étapes dans un ordre strict. Un éditeur compile une release, la signe, l'associe à un canal ou à une règle de version, puis la rend disponible aux appareils éligibles. Le client effectue un check-in ou reçoit une notification, télécharge le paquet, le vérifie, le met en file d'attente, et ne l'active qu'ensuite.
Les éléments qui doivent s'aligner
Un téléchargement n’est pas une installation, et une installation n’est pas une activation. L’appareil doit savoir que l’artefact est authentique, complet et destiné à cette version de l’application avant de toucher au runtime actif. C’est pourquoi les bons systèmes OTA séparent le slot de téléchargement issu de la slot actif, puis ne basculent le pointeur qu’après la vérification.
En pratique, les points fragiles sont prévisibles. Perte de connexion pendant le téléchargement, mauvaise version sur le mauvais canal, échec des contrôles d’intégrité du package, ou redémarrage de l’application avant que le nouveau bundle ne soit prêt. Un système qui traite l’OTA comme une simple fonction « télécharger et exécuter » apprend généralement ces leçons à ses dépens.
Un flux OTA sûr suppose toujours une défaillance entre le téléchargement et l’activation, puis offre à l’application un repli fiable.
La structure de bout en bout est visible dans la plupart des updaters de production, même si les détails d’implémentation varient selon la plateforme. Certains systèmes misent sur les téléchargements en arrière-plan pour que l’utilisateur puisse continuer à travailler. D’autres utilisent un flux au premier plan lorsque la mise à jour est trop importante pour être différée. L’essentiel est que le package de mise à jour passe par la vérification, le staging, l’activation et la récupération, et non par un simple transfert.
Pour les équipes qui intègrent cela dans leur CI/CD, le déclencheur de livraison compte aussi. Un build peut être publié automatiquement une fois les tests passés, puis exposé à un canal d'appareils visible uniquement par l'audience concernée. Ce type d'automatisation fait passer le release engineering d'une simple publication d'app à une distribution logicielle maîtrisée. Ce guide sur le déclenchement des live updates OTA par la CI/CD est une référence utile pour ce workflow.
Comparaison : mises à jour OS, in-app et live updates de bundle web
La principale source de confusion est que l'OTA peut signifier trois choses différentes, chacune ayant ses propres règles. Une OTA du système d'exploitation est contrôlée par le propriétaire de la plateforme. Une mise à jour in-app via un store met à jour le package de l'app. Une mise à jour de bundle web au runtime modifie les assets que l'app installée charge au lancement.
Trois couches où l'OTA intervient
| Couche | Artefact mis à jour | Contrôle | Validation du store |
|---|---|---|---|
| OTA au niveau de l’OS | Le système d’exploitation et ses correctifs | Politique de signature et de déploiement de la plateforme | Hors revue du store, contrôlé par la plateforme |
| Mise à jour in-app | Le paquet d’application Android distribué | Flux de mise à jour Google Play, flexible ou immédiat | Via le store |
| Bundle web live update | JavaScript, CSS, textes, images, configuration et autres assets d’exécution | Règles de canal et d’éligibilité définies par l’app | A généralement déjà passé la revue du store natif |
Il est particulièrement important de distinguer le mécanisme de mise à jour in-app de Google Play des outils « live update ». Il prend en charge Android 5.0 et versions ultérieures, et propose deux modes de fonctionnement. Une mise à jour flexible se télécharge en arrière-plan pendant que l'utilisateur continue d'utiliser l'app, mais l'app doit détecter l'état prêt et finaliser explicitement l'installation. Une mise à jour immédiate bloque l'utilisateur avec un flux plein écran et nécessite l'installation puis un redémarrage avant de pouvoir continuer. La documentation de Google sur les mises à jour in-app est la référence la plus claire pour cette distinction.
Cette différence influence le design de l'app. Les mises à jour flexibles réduisent les interruptions, mais l'ancien code continue de tourner jusqu'à ce que l'app finalise la bascule. Les mises à jour immédiates réduisent les décalages de version, ce qui est utile pour les correctifs urgents, mais elles interrompent aussi la session. Pour les apps de type Capacitor, la séparation est encore plus nette car les assets web peuvent souvent évoluer indépendamment du binaire natif, tandis que les fonctionnalités natives nécessitent toujours le flux classique de mise à jour du package.
Si vous travaillez avec Ionic, Capacitor, ou des workflows proches d'Electron, il est courant de superposer ces chemins plutôt que d'en choisir un seul définitivement. L'OS met à jour le shell, le store met à jour le binaire, et les mises à jour OTA mettent à jour le payload web. Ce n'est pas de la duplication, c'est du contrôle de version à différentes couches de la stack.
Taux d'adoption : pourquoi ils comptent pour l'ingénierie
L'OTA n'a d'intérêt que si les appareils finissent par passer à la nouvelle version. Les chiffres historiques d'Apple sur iOS montrent ce qu'une distribution sans fil centralisée peut accomplir quand un seul propriétaire de plateforme contrôle la signature, l'éligibilité, la notification et la diffusion. Apple a indiqué que 81 % de tous les iPhones actifs tournaient sous iOS 16 en février 2023, et 90 % pour les iPhones sortis au cours des quatre années précédentes, en juin 2023. Plus tard, Apple a indiqué que 76 % des iPhones sortis au cours des quatre années précédentes tournaient sous iOS 18 début 2025, comparé à 74 % tournant sous iOS 26 environ cinq mois après sa sortie du 15 septembre 2025, mesuré le 12 février 2026. La synthèse de Computerworld des données d'adoption d'Apple est un endroit pratique pour retrouver ces chiffres au même endroit.
Ce que ces chiffres révèlent aux ingénieurs
Le premier enseignement est qu’une gestion centralisée des mises à jour OTA peut atteindre une adoption majoritaire en quelques mois. Le second est que l’adoption n’est jamais instantanée et ne touche jamais tout le monde d’un coup. Les appareils plus anciens, le choix des utilisateurs, les contraintes de stockage, les problèmes de connectivité, les déploiements progressifs et le risque perçu laissent toujours une traîne d’appareils sur des versions antérieures.
That tail is why production OTA systems need more than a download endpoint. They need ciblage de version, vérification d’intégrité, télémétrie, gestion des échecs, et mécanismes de rollback ou de récupération. Sans ces contrôles, vous pouvez déployer une release rapidement, mais sans savoir qui l’a reçue, qui a planté au lancement, ou quel public a besoin d’un rollback.
Les métriques d’adoption ne sont pas de simples chiffres de vanité. Elles prouvent que le mécanisme de release atteint la base installée de manière suffisamment sûre pour être fiable.
Pour les équipes qui évaluent une plateforme de live update, la visibilité des releases devient rapidement un critère produit essentiel. Exemples de métriques d’adoption de Capgo illustrent bien la façon dont les équipes ont tendance à envisager la santé des déploiements en pratique.
Les vrais compromis des mises à jour OTA
L'OTA semble rapide car elle évite la file d'attente des stores, mais cette vitesse implique un budget d'interruption. Une mise à jour flexible permet à l'utilisateur de continuer à travailler pendant que le nouveau bundle se télécharge, ce qui est très pratique, mais risqué pour les correctifs urgents, car l'ancien code peut continuer de tourner jusqu'à ce que l'app termine explicitement la mise à jour. Une mise à jour immédiate réduit plus vite l'écart de version, mais elle bloque l'utilisateur et force un redémarrage.
Le prix à payer pour aller plus vite
Ce compromis apparaît à trois niveaux. D'abord, l'UX. Une mise à jour forcée peut interrompre un parcours en pleine session, ce qui est particulièrement visible dans les apps grand public. Ensuite, la sécurité des releases. L'OTA augmente le rayon d'impact d'un package défectueux si votre signature, votre contrôle des canaux ou votre logique de rollback laissent à désirer. Enfin, le risque de conformité, car une équipe peut être tentée de pousser des changements qui relèvent normalement d'une release sur les stores.
Si vos utilisateurs souhaitent un contrôle plus strict sur le moment des mises à jour, la mécanique compte autant que la politique produit. Un aperçu pratique comme Le guide SpecStory sur le contrôle des mises à jour est utile car il rappelle aux équipes que les utilisateurs perçoivent les mises à jour comme des interruptions, et non comme des abstractions.
A mature rollout strategy usually uses canaux et des audiences pour contrôler ces interruptions. Les utilisateurs bêta voient un flux, le staging en voit un autre, et la production suit la voie la plus prudente. Cela donne aux équipes d'ingénierie un moyen d'avancer vite sans transformer chaque release en événement tout ou rien.
Les mises à jour delta qui réduisent la taille du payload peuvent aussi aider quand la bande passante ou le temps de démarrage est critique, mais le téléchargement, même plus petit, doit être traité comme une release complète et vérifiée avant activation. Plus petit ne veut pas dire plus sûr, sauf si les contrôles d'intégrité sont en place.
Framework de classification des changements : OTA vs releases sur les stores
C'est la partie dont la plupart des équipes ont réellement besoin. La question n'est pas « peut-on utiliser l'OTA ? ». La question est « quel type de changement faisons-nous, et quelle voie de release ce changement mérite-t-il ? ». Une bonne méthode consiste à classer chaque pull request avant son déploiement.
Une règle de décision vraiment utilisable par les ingénieurs
Commencez par l'artefact, pas par l'étiquette. Logique JavaScript, CSS, textes, images, configuration et autres assets interprétés ou de la couche web sont généralement éligibles à l'OTA s'ils restent dans la finalité existante de l'app et le périmètre validé. Les plugins natifs, les permissions, les changements SDK et tout ce qui modifie la finalité principale de l'app relèvent d'une release sur les stores.
Cette distinction est cruciale car le « tout JavaScript » n'est pas automatiquement conforme aux politiques. L'autorisation d'Apple pour le code interprété est conditionnelle : elle ne peut pas modifier la finalité principale de l'app, contourner la sécurité de la plateforme ni introduire des fonctionnalités non validées. Une équipe ne doit donc pas se demander seulement « est-ce du JS ? ». La meilleure question est de savoir si le changement modifie fondamentalement ce que fait l'app.
Un tableau de classification pratique peut aider ici :
- Logique de la couche web ou textes de l'UI, généralement en OTA s'il reste dans le comportement validé.
- Assets et images, généralement en OTA lorsqu'ils n'altèrent pas les capacités natives.
- Config et flags backend, généralement en OTA si le client les supporte déjà.
- Plugins natifs, permissions ou changements SDK, release sur les stores.
- Modifications mixtes ambiguës, privilégiez une release binaire et documentez la justification de cette politique.
Lorsqu'une pull request touche à la fois au comportement de la couche web et aux capacités natives, le côté natif prime. Traitez-la comme une release sur les stores, sauf si la modification est clairement dissociable.
Cette règle préserve la cohérence du train de release. Elle donne aussi au produit et au QA un vocabulaire commun, ce qui compte plus qu'on ne l'imagine quand les délais se resserrent.
Les contrôles de sécurité qui rendent l'OTA fiable
L'OTA sécurisé est avant tout un problème de supply chain, et une fonctionnalité de téléchargement ensuite. Un système de mise à jour en production doit authentifier le bundle, vérifier l'intégrité avant activation, conserver une version de référence fiable et rendre l'activation atomique, pour qu'un téléchargement défectueux ne remplace pas la release en cours par un artefact partiel. Ce guide sur la vérification de signature couvre bien le volet confiance de ce modèle.
Les contrôles indispensables de tout système OTA sérieux
Le premier contrôl’est Signature. Le manifeste et les assets qu'il pointe doivent être signés, puis vérifiés avant que l'app ne leur fasse confiance. Le deuxième est la liaison de canal, où la release est liée à une version d'app et à une audience pour qu'un appareil ne récupère pas le mauvais bundle. Le troisième est téléchargement du slot inactif, qui garde le nouveau payload séparé jusqu'à ce que tous les contrôles soient validés.
Ensuite vient l'étape que les équipes sautent parfois : l'activation atomique. L'app ne doit basculer sur le nouveau bundle qu'une fois que les hashes et les signatures correspondent, et non en plein milieu d'un téléchargement ou pendant un redémarrage qui échoue. Un bundle antérieur immuable est essentiel ici, car le rollback ne fonctionne que si la dernière version valide connue est toujours disponible.
Les mises à jour différentielles peuvent aider à réduire la bande passante, mais elles ne remplacent pas la vérification. Un delta doit toujours être reconstruit et vérifié par rapport au bundle cible complet avant que l'app ne l'utilise. Sinon, vous avez simplement réduit la taille du payload, sans rendre la release plus sûre.
Le dernier élément est la télémétrie. Au démarrage, l'app doit logger le bundle actif, le résultat de l'installation, toute crash-loop ou tout échec de lancement, ainsi que la décision de rollback. C'est cet historique qui transforme un incident bizarre en un problème que l'équipe peut expliquer et corriger.
Pour les environnements réglementés, la règle est simple. Gardez les changements de capacités natives dans les binaires validés par les stores, limitez l'OTA aux changements compatibles de la couche web, utilisez des audiences en déploiement progressif et gardez la récupération automatique activée.
Questions fréquentes sur les mises à jour OTA
Les applications OTA existent-elles vraiment ?
Oui. Apps OTA are normal installed mobile apps that download updates over Wi-Fi or cellular after install. Device makers use OTA for operating system patches. Hybrid apps use app-level OTA to refresh the web layer inside Capacitor or Cordova shells. React Native apps use app-level OTA to refresh their JavaScript bundles.
Do OTA updates work on Android and iOS?
Oui, mais avec des formes différentes. Android peut mettre à jour le système d’exploitation, l’APK du Play Store via des mises à jour in-app, ou le bundle web dans une application hybride. iOS utilise l’OTA pour les mises à jour système. L’OTA au niveau de l’application met généralement à jour le JavaScript, le HTML, le CSS et les ressources dans la coquille WebView approuvée. Les modifications de plugins natifs ou d’autorisations nécessitent toujours un nouveau binaire store sur les deux plateformes.
Les mises à jour OTA sont-elles autorisées sur l’App Store et Google Play ?
Les règles des stores autorisent de nombreuses modifications de la couche web via OTA, à condition qu’elles ne modifient pas l’objectif principal de l’application ni ne contournent la sécurité de la plateforme. Le Contrat de licence du programme Apple Developer (section 3.3.1(B)) définit les conditions pour le code interprété. La ligne directrice 2.5.2 des App Review Guidelines interdit le téléchargement de code qui introduit ou modifie des fonctionnalités. La ligne directrice 2.5.19 interdit les fonctionnalités cachées ou non documentées. Google Play autorise les mises à jour du JavaScript et des code web dans un WebView ou un moteur JavaScript, tant qu’elles restent dans le cadre du comportement déclaré de l’application. Voir Mises à jour OTA conformes à l’App Store pour une liste de contrôle pratique.
Quelle est la différence entre les mises à jour OTA Android et l’OTA d’application ?
Mise à jour OTA du système Android met à jour le firmware et l’image de l’OS du fabricant de l’appareil ou de l’opérateur. App OTA met à jour ce que votre application charge après l’installation, comme un nouveau bundle web, une config ou du texte. Les mises à jour in-app de Google Play sont une troisième voie qui remplace l’APK distribué. Précisez la couche visée avant de planifier une release.
Faut-il développer ou acheter un système de mise à jour OTA ?
Développez si vous voulez un contrôle total, pouvez gérer vous-même la signature, les canaux, le rollback et la télémétrie, et avez la capacité de faire une revue de sécurité. Achetez ou utilisez une plateforme managée pour un déploiement plus rapide, une infra hébergée et des workflows conformes aux stores éprouvés. Comparez les compromis dans solutions de mise à jour d’application open source vs propriétaires avant de vous engager.
Qu’est-ce qu’une release OTA pour une application mobile ?
Une release OTA est un package versionné publié sur un canal, téléchargé par les clients éligibles, vérifié, déployé progressivement et activé sans réinstallation depuis le store. Pour les apps de type Capacitor, c’est souvent un bundle web signé. Le même pipeline de release peut cibler les audiences beta, staging et production.
Synthèse et choix d'une approche OTA
Une bonne décision en matière d’OTA est généralement ennuyeuse, au meilleur sens du terme. Classifiez le changement, choisissez le bon canal, signez et vérifiez le bundle, planifiez le rollback et surveillez la télémétrie. Si l’une de ces étapes vous semble floue, le changement devrait probablement passer par le store.
Les questions à poser à un fournisseur
- Peut-il gérer des manifests signés et la vérification des assets ? Sinon, le modèle de confiance est trop faible pour la production.
- Prend-il en charge les canaux progressifs et le ciblage d’audience ? Vous voulez du contrôle, pas un simple interrupteur global.
- Le rollback est-il automatique et observable ? Un chemin de récupération que l’on doit se souvenir d’appliquer manuellement est fragile.
- Des logs par appareil existent-ils ? Sans eux, le support et l’équipe technique devinent.
- Peut-on déclencher des releases via CI/CD grâce à un API ? Publier manuellement ne scale pas bien.
- Prend-il en charge les mises à jour différentielles ? Cela peut aider, mais seulement si les contrôles d'intégrité restent intacts.
Si vous comparez les plateformes, les patterns d'automatisation du déploiement sont un bon moyen de juger si l'outil relève d'une vraie ingénierie de release ou d'un simple argumentaire marketing. C'est particulièrement pertinent pour les équipes qui veulent de l'automatisation sans renoncer au contrôle.
Capgo est une option dans ce domaine pour les équipes CapacitorJS qui ont besoin de mises à jour de bundles web signées, de déploiement par canal, de rollback et de télémétrie de release. Si votre équipe cherche à distinguer les changements compatibles OTA de ceux qui passent par les stores, visitez Capgo et voyez si son workflow correspond à votre façon de déployer.
