Pourquoi ne pas diffuser votre application mobile à tout le monde en même temps
Vous venez d'obtenir l'approbation de l'app store. Votre équipe attendait ce moment. L'instinct naturel est de cliquer sur "diffuser à tous les utilisateurs" et de passer à la fonctionnalité suivante. Mais voici ce qui se passe quand vous faites cela : un crash qui n'apparaît que sur les appareils Android 12 avec 4 Go de RAM touche tous ces utilisateurs en même temps. Vous ne le découvrez que lorsque votre tableau de bord de surveillance des crashs devient rouge, et à ce moment-là, des centaines ou des milliers d'utilisateurs ont déjà vécu une expérience terrible.
Ce n'est pas un scénario hypothétique. Cela arrive régulièrement. La solution n'est pas seulement de mieux tester. La solution est de changer la façon dont vous diffusez : au lieu d'un seul déploiement massif, vous diffusez d'abord à un petit groupe, vous observez ce qui se passe, puis vous élargissez.
Le problème de diffuser à tout le monde
Quand vous diffusez à tous les utilisateurs en même temps, vous perdez votre filet de sécurité. Le processus de révision de l'app store détecte les problèmes évidents, mais il ne peut pas tout attraper. Les crashs spécifiques à certains appareils, les incompatibilités de version d'OS, les problèmes de conditions réseau et les régressions de performances subtiles passent souvent entre les mailles du filet. Ces problèmes n'apparaissent que lorsque de vrais utilisateurs exécutent l'application sur de vrais appareils dans des conditions réelles.
Le risque ne se limite pas aux crashs. Une fonctionnalité qui fonctionne parfaitement en staging peut se comporter différemment lorsque des milliers d'utilisateurs l'utilisent simultanément. Une requête de base de données rapide avec des données de test peut ralentir considérablement avec des volumes de données de production. Un appel API qui fonctionnait bien pendant le développement peut échouer sous une latence réseau réelle.
Diffuser à tout le monde signifie que vous découvrez ces problèmes de la manière la plus difficile : tous en même temps, sans aucune chance d'arrêter les dégâts.
Déploiement progressif et diffusion par phases
C'est là qu'interviennent le déploiement progressif (staged rollout) et la diffusion par phases (phased release). Ce sont deux mécanismes pour diffuser une nouvelle version à un sous-ensemble d'utilisateurs d'abord, surveiller l'impact, puis étendre progressivement au reste. Android appelle cela staged rollout. iOS appelle cela phased release. Le concept est le même, mais l'implémentation diffère.
L'idée centrale est simple : réduire le rayon d'explosion. Si quelque chose tourne mal, seul un petit pourcentage d'utilisateurs est affecté. Vous avez le temps de détecter le problème, de retirer la version et de la corriger avant que les dégâts ne se propagent.
Le diagramme suivant illustre le processus typique de déploiement progressif avec des points de contrôle de surveillance et des décisions de retour en arrière :
Comment fonctionne le déploiement progressif sur Android
Dans Google Play Console, le déploiement progressif vous permet de choisir le pourcentage d'utilisateurs qui reçoivent la mise à jour. Vous pouvez commencer avec 10 pour cent. Votre pipeline CI/CD peut automatiser cela en envoyant la nouvelle version vers une piste spécifique via l'API Google Play Console.
Voici à quoi ressemble un déploiement progressif typique en pratique :
- Le pipeline construit la version de publication et exécute les tests automatisés.
- Le pipeline télécharge le build vers la piste de déploiement progressif à 10 %.
- Le pipeline attend 48 heures tout en surveillant les taux de crash et les rapports d'erreurs.
- Si tout semble normal, le pipeline étend à 25 %.
- Après une autre période de surveillance, étendre à 50 %.
- Enfin, étendre à 100 %.
Si à un moment donné le taux de crash augmente ou les rapports d'erreurs augmentent significativement, le pipeline peut arrêter le déploiement et prévenir l'équipe. Vous pouvez également arrêter manuellement le déploiement depuis la Play Console si vous repérez un problème avant que les vérifications automatisées ne le détectent.
L'avantage clé sur Android est le contrôle. Vous décidez des pourcentages et du timing. Vous pouvez aller vite quand tout va bien, et vous pouvez faire une pause ou arrêter quand ce n'est pas le cas.
Comment fonctionne la diffusion par phases sur iOS
Apple adopte une approche différente. Avec la diffusion par phases, Apple contrôle le calendrier. Vous activez l'option dans App Store Connect lorsque vous soumettez la nouvelle version. Après approbation, Apple diffuse la mise à jour à un petit pourcentage d'utilisateurs le premier jour, puis l'étend progressivement sur sept jours.
Vous ne pouvez pas définir manuellement les pourcentages comme sur Android. Vous ne pouvez pas accélérer le déploiement si tout semble propre. Mais vous pouvez toujours surveiller l'impact via les analyses App Store Connect ou des outils tiers comme Firebase Crashlytics.
Si vous détectez un problème pendant la diffusion par phases, vous pouvez retirer la version d'App Store Connect avant que tous les utilisateurs ne la reçoivent. C'est le filet de sécurité critique. Même si vous avez moins de contrôle sur la vitesse de déploiement, vous avez toujours la capacité d'arrêter les dégâts.
La fenêtre de sept jours peut sembler lente, surtout quand vous êtes impatient de livrer une fonctionnalité. Mais considérez l'alternative : diffuser à tout le monde et découvrir un bug critique après que 100 000 utilisateurs aient déjà téléchargé la mise à jour.
Automatiser le déploiement progressif dans votre pipeline
Votre pipeline CI/CD peut gérer tout le processus de déploiement progressif automatiquement. Voici une approche pratique pour Android :
- Construire et signer l'APK ou l'AAB de publication.
- Télécharger vers Google Play Console via l'API, en ciblant la piste de déploiement progressif.
- Définir le pourcentage initial à 10 %.
- Attendre une période de surveillance définie, généralement 24 à 48 heures.
- Vérifier les métriques depuis Firebase Crashlytics ou votre outil de rapport de crash.
- Décider : si le taux de crash est inférieur au seuil, étendre au pourcentage suivant. Si supérieur, arrêter et prévenir.
- Répéter jusqu'à atteindre 100 %.
Pour iOS, l'automatisation est plus simple car vous ne pouvez pas contrôler les pourcentages. Votre pipeline peut :
Voici un extrait YAML pour un job GitHub Actions qui télécharge un build Android et définit un déploiement progressif à 10 % :
- name: Upload to Google Play (10% staged rollout)
uses: r0adkll/upload-google-play@v1
with:
serviceAccountJsonPlainText: ${{ secrets.PLAY_SERVICE_ACCOUNT_JSON }}
packageName: com.example.app
releaseFiles: app/build/outputs/bundle/release/app-release.aab
track: production
userFraction: 0.1
releaseStatus: completed
Cette étape utilise le paramètre userFraction pour limiter le déploiement à 10 % des utilisateurs. Le pipeline peut ensuite étendre cette fraction après surveillance.
- Construire et signer l'IPA.
- Télécharger vers App Store Connect.
- Activer la diffusion par phases dans la soumission.
- Surveiller les taux de crash et les analyses pendant la fenêtre de sept jours.
- Retirer la version si des problèmes apparaissent.
Le pipeline ne remplace pas le jugement humain. Il gère les parties mécaniques : téléchargement, attente, vérification des métriques et extension. L'équipe doit toujours examiner les rapports de crash, enquêter sur les anomalies et prendre la décision finale de continuer ou d'arrêter.
Ce que le déploiement progressif n'est pas
Le déploiement progressif ne remplace pas des tests appropriés. Vous avez toujours besoin de tests unitaires, de tests d'intégration et d'une QA manuelle avant de soumettre à l'app store. Le déploiement progressif est la dernière ligne de défense, pas la première.
Le déploiement progressif n'est pas non plus un moyen de livrer du code cassé en espérant que tout ira bien. L'objectif est de détecter les problèmes qui passent malgré vos meilleurs efforts de test. Si vous comptez sur le déploiement progressif pour attraper des bugs basiques, votre processus de test a besoin d'être amélioré.
Liste de contrôle pratique pour votre prochaine version
- Mettez en place une surveillance des crashs avec des alertes avant la version.
- Définissez votre seuil de taux de crash pour arrêter le déploiement.
- Configurez votre pipeline pour télécharger vers la piste de déploiement progressif.
- Définissez le pourcentage initial à 10 % ou moins.
- Définissez la période de surveillance entre les extensions.
- Testez le mécanisme d'arrêt : pouvez-vous arrêter le déploiement rapidement ?
- Désignez quelqu'un pour surveiller les rapports de crash pendant la fenêtre de déploiement.
- Documentez la procédure de retour en arrière au cas où vous devriez retirer la version.
L'essentiel
Diffuser une application mobile à tous les utilisateurs en même temps est un pari que vous n'avez pas besoin de prendre. Le déploiement progressif et la diffusion par phases vous offrent un chemin contrôlé et observable, de zéro à un déploiement complet. Vous échangez quelques jours supplémentaires de déploiement contre la capacité de détecter les problèmes avant qu'ils n'affectent tout le monde. Cet échange en vaut presque toujours la peine.
La prochaine fois que votre application sera approuvée, résistez à l'envie de diffuser à tout le monde. Commencez petit, surveillez les métriques, et étendez seulement quand vous êtes confiant. Vos utilisateurs ne sauront jamais que vous avez retenu la version, mais ils remarqueront que l'application ne crashe pas le jour du lancement.