OTA update (EAS Update)

Le flux de production recommandé par Expo est le suivant : eas update --channel staging sur un build de test, vérification, puis eas update:republish --destination-channel production pour promouvoir exactement le même bundle, ou eas update --channel production si les variables d’environnement diffèrent. --rollout-percentage permet un déploiement progressif, eas update:rollback revient à l’update précédente ou à celle embarquée dans le binaire. Le comportement côté app se règle dans app.json (updates.checkAutomatically, fallbackToCacheTimeout) et via l’API Updates (checkForUpdateAsync, fetchUpdateAsync, reloadAsync) pour les équipes qui veulent proposer un rechargement plutôt que l’attendre au prochain démarrage.

Le piège numéro un est l’update incompatible : du JavaScript qui appelle un module natif absent du binaire installé. La runtime version existe pour ça, et la politique fingerprint la calcule à partir du natif réel. Numéro deux : publier une update depuis un poste de dev avec des variables EXPO_PUBLIC_* de staging. Numéro trois : oublier que les stores ont des règles ; une update qui change le comportement de l’app au-delà d’un correctif reste soumise à leurs conditions.

En audit, je regarde eas update:list --branch production, la correspondance canal/branche (eas channel:list), et si les crashs sont bien associés à un identifiant d’update dans l’outil de monitoring, sinon personne ne sait quel code tourne vraiment chez les utilisateurs.