Exemple de plan de rollback : 7 playbooks pour les apps Capacitor

À 16h, une mise à jour de la couche web arrive en production. En quelques minutes, les rapports de crash grimpent, les tickets de support affluent et l'équipe découvre que le nouveau bundle JavaScript échoue sur un sous-ensemble d'appareils. Attendre la validation de l'App Store ou du Google Play n'est pas une option, mais restaurer un ancien fichier ne suffit pas si la configuration, les API, les feature flags ou les données stockées ont également changé. Un bon exemple de plan de rollback doit indiquer à l'opérateur ce qui déclenche la réponse, quelle version restaurer, comment vérifier le rétablissement et quand revenir à code pourrait aggraver l'incident.

Les sept playbooks ci-dessous associent les actions de rollback à des types d'échecs spécifiques dans applications Capacitor et Electron, incluant les releases distribuées via les canaux Capgo. Utilisez-les comme modèles de runbook, puis remplacez les déclencheurs d'exemple par vos propres indicateurs de crash, de business et d'intégrité des données.

Table of Contents

• 1. Rollback automatique en cas de crash
  • Déclencheur, action et mode d'échec
• 2. Rollback de mise à jour différentielle avec historique des versions
• 3. Déploiement progressif avec rollback automatique en cas de dégradation des métriques
• 4. Rollback de configuration uniquement avec des feature flags
  • Exécutez le rollback du flag comme un playbook encadré
• 5. Rollback canary avec consentement utilisateur et override manuel
• 6. Rollback de migration de base de données avec versionnage de schéma
• 7. Rollback piloté par l'incident avec observabilité automatisée et post-mortems
• 7 exemples de plans de rollback comparés
• Transformez ces exemples de plans de rollback en runbook

1. Rollback automatique en cas de crash

Le rollback automatique est la première réponse appropriée lorsqu'un nouveau bundle web provoque un échec de démarrage manifeste, une exception JavaScript, une défaillance d'un plugin natif ou un motif de crash absent de la version précédente. Le déclencheur doit être lisible par machine et associé à une version, un canal, un groupe d'appareils et une fenêtre d'observation. Un contrôleur de release peut suspendre la distribution et restaurer le dernier bundle fonctionnel connu sans attendre qu'un ingénieur le remarque sur le dashboard.

Pour une application Capacitor, surveillez plus que les crashes natifs. Suivez si l'application démarre, si la webview se charge, si elle notifyAppReady() se termine, si les plugins critiques s'initialisent et si le premier parcours utilisateur réussit. Les équipes Electron doivent ajouter les échecs du processus de rendu, les exceptions du processus principal, les échecs d'installation des mises à jour et les appels IPC en échec.

Règle pratique : Le rollback automatique doit d'abord arrêter l'exposition, puis rétablir le service. Il ne doit pas tenter de diagnostiquer la cause racine tant que les utilisateurs reçoivent encore le bundle suspect.

Un déclencheur concret peut être une augmentation soutenue des crashes ou des échecs de contrôles de disponibilité par rapport à la référence de la release. Ne copiez pas le seuil d'une autre application. Définissez une limite prudente pour la production, validez-la par rapport aux variations normales des appareils et des OS, et exigez suffisamment d'observations pour éviter de réagir à un appareil isolé.

Déclencheur, action et mode d'échec

• Déclencheur : Crash, démarrage, état de préparation ou signaux de plugin natif : la release est bloquée pour le canal concerné.
• Action : Geler l'expansion du canal, marquer le bundle comme instable, redéployer le précédent bundle signé, puis vérifier le démarrage et les flux critiques.
• Compromis : La récupération est rapide, mais un déclencheur trop sensible peut annuler une release saine à cause d'un problème de backend ou d'appareil sans rapport.
• Mode d'échec : L'ancien bundle dépend d'un API ou d'une configuration modifiée, l'app démarre mais échoue plus tard. Maintenez des tests de compatibilité dans la health gate.

Pour le diagnostic par appareil et la corrélation des crashs, utilisez ce guide pour connecter Firebase Crashlytics aux apps Capacitor. Testez le parcours complet dans un canal de staging, incluant la détection, le gel du canal, le redéploiement, le téléchargement client, l'activation et la confirmation que l'ancienne version reste utilisable.

2. Rollback de mise à jour différentielle avec historique des versions

Un rollback différentiel convient aux échecs isolés à une feuille de style, un asset, une valeur de configuration ou un module JavaScript. L'updater ne transfère que les fichiers qui diffèrent entre la release active et une cible saine, réduisant le téléchargement pour les utilisateurs sur des connexions instables. La cible doit toujours reconstruire une release complète.

Le déclencheur est un défaut confirmé au niveau des fichiers qui ne nécessite pas de modification du runtime natif. Avant d'agir, comparez les manifestes actif et précédent, vérifiez la version du runtime Capacitor ou Electron, et confirmez que le canal concerné dispose d'un bundle signé compatible. Si le défaut dépasse ce périmètre, déployez le bundle précédent complet plutôt que de tenter une réparation limitée aux fichiers.

La livraison différentielle n'est pas une récupération partielle. Ne combinez jamais des fichiers arbitraires provenant de plusieurs releases. Stockez des manifestes immuables, validez les checksums et les signatures, conservez l'artefact complet précédent et enregistrez la version active dans l'historique du canal. Un bundle JS et un plugin natif incompatibles peuvent laisser l'app se lancer, puis faire échouer un flux critique plus tard.

Les Capgo historique des versions de l'app aide les opérateurs à localiser un build validé avant le redéploiement. Enregistrez l'identifiant du bundle, la version du runtime natif, le canal Capgo, la révision de configuration et les notes de migration pour chaque release.

Utilisez ce runbook :

1. Confirmez que le défaut est limité aux assets web, à la configuration ou à code.
2. Gelez le canal concerné pour éviter que d'autres appareils ne reçoivent la version suspecte.
3. Sélectionnez le dernier bundle signé compatible, pas seulement le fichier antérieur le plus proche.
4. Générez une mise à jour différentielle uniquement lorsque le client et le manifeste permettent une reconstruction sécurisée.
5. Test de démarrage, vérifications d'intégrité, compatibilité API et parcours utilisateur impacté.
6. Surveillez les téléchargements, l'activation et la fin du rollback sur les clients Capacitor et Electron.

Une reconstruction échouée, une erreur de checksum, une dépendance native incompatible ou une boucle d'activation constitue un mode de défaillance. Arrêtez la livraison différentielle et redéployez le bundle complet conservé. L'historique des versions permet de savoir ce qui a changé et quelle release peut franchir la limite de compatibilité en toute sécurité. Cela ne remplace pas les artefacts de rollback testés ou les notes de migration.

3. Déploiement progressif avec rollback automatisé en cas de dégradation des métriques

Une release peut passer les tests de démarrage tout en endommageant un workflow critique. Pour un déploiement progressif, placez les cohortes bêta, staging, production ou clients dans des canaux Capgo distincts. Promouvez un seul bundle signé à la fois, et gardez la version compatible précédente disponible pour chaque canal. Cela limite l'exposition tout en préservant un chemin de récupération direct pour les clients Capacitor et Electron.

Définissez la porte de release avant la promotion. Pour un changement lié au checkout, surveillez les paiements complétés plutôt que les seuls crashs. Pour la messagerie, vérifiez la latence et le succès de la livraison. Pour la synchronisation de données de santé, validez l'exhaustivité des dossiers. Comparez chaque signal avec la référence pour la même audience, le même mix d'appareils et le même canal. Une release n'est saine que lorsque l'action critique est complétée correctement.

Utilisez cette séquence lors de la promotion :

1. Désignez un responsable pour réviser les signaux techniques et business.
2. Observez la cohorte définie pendant la période convenue.
3. Arrêtez la promotion dès qu'une métrique surveillée franchit son seuil approuvé.
4. Gelez le canal Capgo affecté et conservez l'ID de la release, les versions client, la configuration et les relevés de métriques.
5. Redéployez le dernier bundle compatible sur cette cohorte.
6. Vérifiez le démarrage, l'activation de la mise à jour et le workflow affecté sur des appareils Capacitor et Electron représentatifs.
7. Resume promotion only after the owner confirms recovery.

Le guide sur les déploiements progressifs pour les live updates Capacitor offre un contexte de déploiement pour les releases par canal. Un rollback automatisé ne doit s'exécuter que si les métriques et les seuils sont sans ambiguïté. Un échec de paiement, de confidentialité, de sécurité ou d'intégrité des données peut justifier une action immédiate, même avant de disposer d'une confiance statistique.

Le principal mode de défaillance est un dashboard trop restreint. La santé technique peut rester normale alors qu'un résultat métier se dégrade, et des conditions rares (appareil, compte ou réseau) peuvent ne jamais apparaître dans la première cohorte. Notez ces lacunes dans le runbook avant la prochaine release.

4. Rollback de configuration uniquement avec des feature flags

Un rollback de configuration convient aux échecs isolés à une seule fonctionnalité. Gardez le nouveau bundle Capacitor ou Electron installé, puis désactivez le chemin risqué via un flag distant pour le canal Capgo ou l'audience affectée. L'app peut restaurer une logique de recommandation, une variante d'interface, une synchronisation optionnelle, un stockage expérimental ou un autre comportement protégé sans remplacer les code non concernés.

Le fallback doit déjà être en place. Confirmez qu'il reste compatible avec l’API actuel et le modèle de données, désignez un responsable et documentez la portée du flag ainsi que sa valeur par défaut d'urgence avant la release. Supprimer l'ancien chemin et ajouter un flag après un incident ne laisse rien à activer.

Exécutez le rollback du flag comme un playbook encadré

1. Déclencheur : Une erreur sur une fonctionnalité, un workflow échoué, un problème de confidentialité, de batterie ou une régression métier dépasse le seuil convenu par l'équipe.
2. Action : Désactivez le flag pour le canal Capgo concerné ou l'audience concernée. Confirmez que les clients reçoivent bien le changement, puis testez le fallback sur des appareils Capacitor et Electron représentatifs.
3. Vérifiez : Vérifiez l'état du flag actif, les événements pertinents, le comportement au démarrage et le workflow concerné. Laissez le nouveau bundle en place pendant que l'équipe isole la cause.
4. Compromis : Le changement est rapide et ciblé, mais il ne peut pas réparer une dépendance partagée, un code natif incompatible ou des données corrompues.
5. Mode d'échec : La mise à jour peut ne pas arriver, être ignorée au démarrage ou rester en cache. Loggez l'état du flag à chaque événement pertinent et définissez l'expiration du cache.

Utilisez le guide d'implémentation des feature flags pour structurer ce contrôle dans un workflow Capgo. Conservez une valeur par défaut locale de secours pour les fonctionnalités critiques. Si la configuration ne peut pas être récupérée, refusez l'accès par défaut. Les fonctionnalités sensibles en matière de sécurité et de confidentialité doivent désactiver l'accès pendant une panne du control plane plutôt que de le maintenir.

5. Rollback canary avec consentement utilisateur et override manuel

Une release canary peut sembler saine dans la télémétrie tout en échouant pour un compte entreprise, un rôl’utilisateur ou une intégration spécifique. Offrez à ce groupe un fallback clair et un moyen de signaler le problème. Leurs retours peuvent révéler des problèmes de workflow ou d'ergonomie que les métriques agrégées ne détectent pas.

Utilisez des contrôles distincts pour les utilisateurs et les opérateurs. L'action côté utilisateur doit être disponible en dehors du workflow défectueux, expliquer ce que le retour en arrière modifie, et collecter le bundle actif, la version de l'app native, le canal Capgo, l'appareil et l'horodatage. Pour les apps Capacitor, vérifiez la compatibilité du bundle web précédent avec le shell natif installé. Pour Electron, confirmez que le fallback reste compatible avec le runtime desktop packagé.

Définissez le déclencheur canary avant la release :

• Déclencheur : Gelez le canal après des désinscriptions répétées d'un segment, des rapports groupés ou si une métrique technique dépasse son seuil convenu.
• Action utilisateur : Affichez le choix du fallback, enregistrez le consentement et le contexte de diagnostic, puis renvoyez l'utilisateur vers le bundle compatible précédent.
• Action de l'opérateur : Suspendre l'exposition, examiner les rapports et rediriger le canal canary vers le build stable. Gardez une commande manuelle disponible en cas d'indisponibilité du control plane ou de l'interface client.
• Compromis : Le consentement améliore la transparence et permet de détecter les problèmes tôt, mais la coexistence de versions mixtes augmente l'effort de support et complique les comparaisons.
• Mode d'échec : Un utilisateur peut effectuer un rollback sans transmettre de contexte, ou l'ancien client peut échouer face à un backend modifié. Traitez user consent best practices for OTA updates comme faisant partie de la communication et du design de l'opt-out, et maintenez la compatibilité serveur ou un retour contrôlé des fonctionnalités.

Ne présentez pas ce rollback comme un correctif pour une incompatibilité côté serveur. Si le contrat du backend a changé, restaurez la compatibilité d'abord ou maintenez le workflow concerné désactivé.

6. Rollback de migration de base de données avec versionnage de schéma

Un rollback de bundle ne peut pas réparer un schéma incompatible. Un client Capacitor ou Electron peut revenir à son code précédent alors que l’API ou la base de données locale attend toujours de nouveaux champs, des types modifiés ou des données partiellement migrées. Cela peut entraîner des échecs de lecture, des écritures rejetées ou des enregistrements incorrects.

Considérez la migration comme une release à part entière avec un plan de secours. Commencez par une phase d'extension : ajoutez des champs ou des tables compatibles sans supprimer l'ancienne représentation. Déployez code capable de lire et d'écrire dans les deux formats, puis migrez les enregistrements existants avec validation. Basculez le trafic de façon contrôlée. Ne supprimez les structures héritées qu'une fois que le client précédent n'est plus nécessaire. Cela permet de garder la possibilité d'un rollback du canal Capgo tant que le nouveau schéma reste déployé.

La revue sur migrations de base de données réversibles couvre les migrations transactionnelles, les schémas rétrocompatibles et les déploiements séparés de la base de données et de l'application. Appliquez ces contrôles aux enregistrements de paiement, aux commandes, aux informations patients et à toute autre donnée qui ne peut être recréée en toute sécurité.

Définissez le plan de secours avant de déployer :

• Rollback de l'application : Restaurez la version précédente du bundle Capacitor ou du package Electron uniquement après avoir confirmé qu'elle peut lire le schéma actuel.
• Rollback de fonctionnalité : Désactivez le nouveau chemin d'écriture ou le feature flag tout en conservant les modifications de schéma compatibles.
• Récupération de migration : Arrêtez les écritures affectées, inspectez les enregistrements et exécutez une procédure de correction ou de récupération revue.
• Restauration des données : Use backup or point-in-time recovery when code reversal cannot restore data correctness.

Gardez les scripts de migration et de récupération sous surveillance. Testez-les avec des données représentatives de la production, et utilisez des transactions ou des savepoints lorsque c'est pris en charge. Ne générez pas de SQL de rollback destructeur pendant un incident. Définissez des conditions de réussite pour la santé de l'application, la validité des données et la compatibilité d'écriture, avec des responsables distincts pour chaque décision. Un plan de migration qui n'a pas été répété en staging n'est pas un exemple fiable de plan de rollback.

7. Rollback piloté par l'incident avec observabilité automatisée et post-mortems

Un canal Capgo peut afficher un déploiement progressif sain alors qu'une cohorte spécifique Capacitor ou Electron échoue après le lancement. Définissez le déclencheur de l'incident avant la release, par exemple un signal de crash persistant, un check de readiness en échec, un flux API cassé ou une erreur d'intégrité des données confirmée. En cas d'alerte, gélérez l'extension du canal et enregistrez le bundle actif, la version de l'app native, le canal, l'état du déploiement progressif, la cohorte affectée, la catégorie d'erreur et les horodatages. Capturez ces éléments de preuve avant de modifier l'état du déploiement.

Recommandations DORA sur les métriques de déploiement et de récupération présente le rollback à la fois comme un signal d'échec de changement et un événement de récupération. Stockez l'identifiant de la release et le résultat du rollback, puis comparez le temps entre détection et restauration, les sessions ou appareils affectés, et les taux d'erreur après récupération. Ces mesures indiquent si le bundle restauré a bien éliminé la défaillance.

Gérez l'incident comme une séquence courte et documentée :

1. Déclencheur : Confirmez l'alerte à partir des signaux de crash, de disponibilité, API, métier ou de données.
2. Figer : Arrêtez l'extension du canal et désactivez le feature flag si cela réduit davantage l'impact qu'un rollback complet.
3. Conserver : Conservez les logs, les traces, l'historique des versions, l'état d'adoption et les détails des segments affectés.
4. Rollback : Redéployez le dernier bundle compatible pour Capacitor ou Electron, et tenez compte de la compatibilité avec la version native.
5. Vérifier : Testez le démarrage et les flux critiques, puis confirmez que le signal d'erreur diminue.
6. Revue : Notez la cause, le défaut de détection, la décision et la modification du runbook.

Un rollback qui échoue est en soi un déclencheur. Passez au canal précédent connu comme stable ou à un déploiement manuel si la version restaurée crash, ne démarre pas ou reproduit le même échec API. Utilisez ce guide de Forge Reliability sur la cause racine pour structurer l'enquête. Réalisez le post-mortem sans recherche de coupable tant que les preuves sont disponibles, attribuez un responsable à chaque action corrective et testez le contrôle de préparation ou la garde du canal qui en résulte.

7 exemples de plans de rollback comparés

Transformez ces exemples de plans de rollback en runbook

Ne choisissez pas un seul mécanisme de rollback pour chaque incident. Commencez par l'action la plus ciblée et la plus sûre. Si un feature flag peut désactiver le chemin défaillant tout en préservant l'intégrité des données, utilisez-l’en priorité. Si la release elle-même est instable, stoppez l'expansion du canal et utilisez des contrôles de canaux progressifs avec des passerelles automatisées de crash et de readiness. Si la défaillance affecte code partagé, la configuration ou des API incompatibles, restaurez le dernier bundle compatible et vérifiez l'intégralité du parcours utilisateur.

La décision la plus difficile concerne les données. Un rollback de bundle n'annule pas une migration de schéma, une écriture partielle ou un changement de comportement côté serveur. Pour ces incidents, gélérez les écritures risquées, impliquez le propriétaire des données et suivez la procédure de migration sécurisée plutôt que de supposer que l'ancien client est automatiquement plus sûr. L'échec de Knight Capital en 2012 illustre pourquoi restaurer un binaire antérieur ne suffit pas : un serveur conservait une fonctionnalité héritée dormante, un flag réutilisé l'a activée, et la tentative de rollback a laissé le comportement problématique actif dans tout l'environnement. L'incident a généré environ 397 millions d'exécutions d'actions erronées, une position notionnelle d'environ 7 milliards $, et une perte initiale avant impôts signalée d'environ 440 millions $, plus tard rapprochés de 460 millions $ dans des rapports plus larges, comme documenté dans ce compte rendu de l'échec du rollback de Knight Capital.

Le déploiement Storm de Spotify offre un autre principe utile pour les systèmes avec état. Maintenir deux versions complètes de la topologie, préserver les positions des consommateurs et utiliser une activation réversible permet aux opérateurs de restaurer la version précédente sans perdre le flux, comme décrit dans Le compte de déploiement Apache Storm de Spotify. Le design Capgo analogue consiste à conserver le précédent bundle signé, préserver les health gates spécifiques à la version et confirmer la compatibilité avant de supprimer l'ancienne release.

Transformez ces idées en un arbre de décision rapide :

• Échec spécifique à une fonctionnalité : Désactivez le feature flag, vérifiez le fallback et investiguez.
• Instabilité de la release : Gelez le canal, redéployez le dernier bundle compatible et surveillez la récupération.
• Incertitude liée à un segment : Arrêtez la promotion et utilisez les retours canary ainsi qu'une intervention manuelle.
• Risque de schéma ou de données : Ne faites pas de rollback aveugle sur code. Gelez les changements et exécutez le plan de migration ou de récupération de données.
• Cause incertaine : Capturez d'abord les preuves, limitez l'exposition, puis choisissez l'action réversible la plus ciblée.

Choisissez un playbook dès aujourd'hui. Définissez son déclencheur, son responsable, la commande de rollback exacte ou l'action sur le dashboard, les étapes de vérification et le processus d'escalade. Testez-le sur un canal de staging avant la prochaine release en production, en simulant une mise à jour échouée, un signal de readiness défectueux, une inversion de configuration et un test de compatibilité. Les équipes récupèrent plus vite quand le rollback est une opération pratiquée, et non un paragraphe écrit après l'incident.

Capgo fournit des live updates signés pour les apps CapacitorJS et Electron, avec des canaux ciblés, l'historique des versions, des logs par appareil, des métriques d'adoption et d'échec, la livraison différentielle et une protection automatique contre les rollbacks. Utilisez Capgo pour transformer l'exemple de plan de rollback adapté à votre app en un workflow de release et de récupération testé.