Le déploiement progressif est un mécanisme de sortie Google Play qui déploie une nouvelle version d'application auprès d'un pourcentage configurable d'utilisateurs avant le déploiement complet. Le développeur définit le pourcentage initial (couramment 1 % ou 5 %), surveille le taux sans crash et d'autres métriques de qualité, et augmente progressivement le pourcentage (ex. : 5 % → 20 % → 50 % → 100 %) sur plusieurs heures à jours. Si un problème critique est détecté en cours de déploiement, le développeur peut arrêter le déploiement, empêchant la build défectueuse d'atteindre davantage d'utilisateurs.
Cadence typique d'un déploiement progressif
- 1-5 % : premières 24-48 heures. Vérifier le taux sans crash, le taux ANR, la conversion des flux clés. Mettre en pause si toute régression > 0,1 %.
- 5-20 % : 24-48 heures suivantes. Une distribution plus large valide que la build fonctionne sur davantage de combinaisons appareil + région.
- 20-50 % : 2-3 jours suivants. À ce stade, les régressions sévères ont fait surface. Continuer si les métriques sont stables.
- 50-100 % : rampe finale. Compléter le déploiement dans les 5-7 jours suivant la sortie initiale.
L'équivalent Apple : la « Phased Release » dans App Store Connect. Même concept, implémentation légèrement différente. La Phased Release d'Apple suit un calendrier fixe de 7 jours (1 % → 2 % → 5 % → 10 % → 20 % → 50 % → 100 %) avec des incréments automatiques quotidiens. Moins de contrôle granulaire que le système basé sur des pourcentages de Google Play, mais l'objectif sous-jacent est identique.
Capacité critique : la possibilité d'arrêter un déploiement. Si le taux sans crash baisse, si le taux ANR augmente ou si une métrique de conversion clé régresse, le développeur arrête le déploiement depuis la Play Console. La build reste disponible pour les utilisateurs qui ont déjà mis à jour, mais aucun nouvel utilisateur ne la reçoit. La sortie d'un correctif peut ensuite être déployée progressivement dans un nouveau déploiement, remplaçant la build défectueuse.