Publication progressive App Store : le déploiement en 7 jours, la pause et le correctif (2026)

Une publication progressive sur l'App Store envoie une mise à jour de version à une part croissante des utilisateurs ayant activé les mises à jour automatiques, sur sept jours : 1 % le premier jour, 100 % le septième. Si vous surveillez les crashs et les e-mails du support chaque jour et mettez en pause dès que quelque chose cloche, un mauvais build n'atteint qu'un petit groupe de personnes au lieu de toute votre base d'utilisateurs. La publication progressive a toutefois une limite majeure : elle ne contrôle que les mises à jour automatiques. N'importe qui peut toujours télécharger la nouvelle version manuellement.

Que contrôle la publication progressive de l'App Store, et que ne contrôle-t-elle pas ?

La publication progressive contrôle uniquement quels utilisateurs avec mises à jour automatiques reçoivent votre mise à jour de version, et quand. Elle ne cache pas la nouvelle version aux téléchargements manuels et ne fait revenir en arrière aucun utilisateur qui l'a déjà.

Selon l'aide App Store Connect d'Apple, « un échantillon aléatoire d'utilisateurs ayant activé les mises à jour automatiques sur des appareils éligibles recevra la mise à jour, sans être notifié de sa participation à la publication progressive ». Elle fonctionne pour les mises à jour de version iOS, macOS et tvOS : vous ne pouvez donc pas l'utiliser pour la toute première publication d'une app. Sa configuration nécessite le rôle Account Holder, Admin ou App Manager. Apple indique aussi : « Les apps et mises à jour d'apps en publication progressive peuvent être téléchargées manuellement depuis l'App Store par n'importe qui, à tout moment. »

Quel est le calendrier de la publication progressive App Store ?

En novembre 2026, le calendrier est fixe — 1 %, 2 %, 5 %, 10 %, 20 %, 50 % et 100 % sur sept jours — et vous ne pouvez pas le modifier. Ce que vous contrôlez, c'est quand mettre en pause et quand passer directement à 100 %.

Considérez chaque jour comme un point de contrôle qui se conclut par une seule décision : continuer ou mettre en pause.

Comment activer la publication progressive dans App Store Connect ?

La publication progressive s'active depuis la page de la version, dans la section Phased Release for Automatic Updates, à tout moment avant la mise en ligne de la mise à jour. Vous n'êtes pas obligé de trancher avant la soumission.

Apple l'autorise lorsque la version est dans l'un des statuts Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected ou Metadata Rejected.

1. Dans Apps, sélectionnez votre app, puis cliquez sur la version que vous soumettez dans la barre latérale.
2. Faites défiler jusqu'à Phased Release for Automatic Updates.
3. Sélectionnez Release update over a 7-day period using phased release.
4. Cliquez sur Save. Après approbation, le statut affiche Ready for Distribution, accompagné de la mention Phased Release.

Vous pouvez aussi gérer les publications progressives via l'API App Store Connect, ce qui est pratique si votre pipeline de release est déjà scripté.

Quand mettre en pause une publication progressive, et comment fonctionne la limite de 30 jours ?

Mettez en pause dès qu'un de vos déclencheurs convenus à l'avance se déclenche. Les pauses peuvent totaliser jusqu'à 30 jours, et à la reprise, le déploiement continue à partir du jour où il s'était arrêté.

Rédigez vos déclencheurs avant le jour du lancement, pour que personne n'en débatte pendant que les utilisateurs subissent le bug. Les bons déclencheurs sont concrets : les sessions sans crash passent sous la référence de la version précédente, le paiement ou la connexion échoue pour une part mesurable des tentatives, ou plusieurs utilisateurs signalent le même bug.

Pour mettre en pause, ouvrez la version au statut Ready for Distribution, sélectionnez Pause Phased Release et cliquez sur Save. Pour reprendre, sélectionnez Use Phased Release. L'exemple d'Apple : si vous mettez en pause 10 jours puis reprenez, il vous reste 20 jours de pause. Vous pouvez faire autant de pauses que vous voulez dans cette limite totale. Pour sauter les phases restantes, cliquez sur Release to All Users en haut à droite de la page de la version.

À quoi ressemble une publication progressive quand un bug apparaît ?

Quand un bug apparaît, vous mettez en pause, vous le corrigez et vous publiez une nouvelle version, de nouveau en publication progressive. Les utilisateurs qui attendent encore la mise à jour automatique restent sur la version précédente pendant que vous travaillez.

Imaginons que la version 3.4 remplace votre moteur de synchronisation. Le premier jour, 1 % des utilisateurs en mise à jour automatique la reçoivent, et vous consultez deux fois votre outil de crash reporting et vos logs d'erreurs de synchronisation. Le troisième jour, à 5 %, une série d'échecs de synchronisation apparaît sur une ancienne version d'iOS. Vous mettez en pause immédiatement. Bien moins d'utilisateurs sont touchés que si tout le monde l'avait reçue, et les utilisateurs en mise à jour automatique pas encore atteints restent sur la 3.3.

Ensuite, corrigez le bug et soumettez la 3.4.1 avec la publication progressive activée. Testez le correctif dans un build release, pas seulement en debug ; notre plan de test en build release couvre cette étape. Indiquez clairement dans les notes de version de la 3.4.1 que la synchronisation est corrigée ; nos exemples de notes de version montrent comment faire. Si le correctif est urgent et que vous en êtes sûr, utilisez Release to All Users après l'approbation au lieu d'attendre une semaine de plus.

Une protection de plus : placez le nouveau moteur de synchronisation derrière un flag côté serveur. La pause empêche la mise à jour de se propager, mais un flag vous permet de désactiver le code risqué pour ceux qui ont déjà installé la 3.4. Les deux se complètent bien.

Quels problèmes d'autres développeurs ont-ils rencontrés en mettant en pause une publication progressive ?

Les discussions publiques montrent le même schéma : des développeurs mettent en pause une version boguée, puis ne savent pas ce qu'une nouvelle publication progressive fait pour les utilisateurs qui ont déjà reçu la précédente. La documentation d'Apple ne répond pas à cette question, donc planifiez comme si le correctif nécessitait son propre déploiement.

• Un développeur sur les Apple Developer Forums a raconté avoir « remarqué un crash, mis en pause le déploiement de la mise à jour, corrigé l'app, envoyé le build et lancé un autre déploiement progressif » alors que moins de 10 % des utilisateurs avaient le mauvais build. Il demandait si les mêmes utilisateurs recevraient le nouveau déploiement. Le fil n'a jamais obtenu de réponse officielle ; une réponse indiquait que les utilisateurs de la 8.0 « devraient être informés qu'une mise à jour 8.1 est disponible dès sa sortie ».
• Dans un autre fil du forum, un développeur expliquait s'être « arrêté à 1 % » sur la version 15.0.1 à cause d'un bug critique et voulait aussi échelonner la 15.0.2, en espérant que la 15.0.1 serait « pratiquement sautée pour la majorité des utilisateurs ». Une réponse antérieure dans ce fil suggérait de demander une revue accélérée pendant que la version boguée était en pause, et éventuellement de retirer l'app de la vente « pour qu'aucun nouvel utilisateur ne récupère la version défectueuse ». Avant de faire cela, rappelez-vous la règle sur le retrait de la vente détaillée dans l'encadré ci-dessus.
• L'équipe d'outillage de release à l'origine des notes store-quirks de Tramline documente que lancer une nouvelle release « annulera simplement le déploiement en cours », et que l'ancienne version passe à REPLACED_WITH_NEW_VERSION avec sa publication progressive marquée COMPLETE. Les mêmes notes précisent qu'une pause « ne pourra rien faire pour les utilisateurs qui ont déjà reçu la mise à jour ».

Dans les trois cas, la pause n'a fait que gagner du temps. Le correctif a toujours été une nouvelle version, et personne ne pouvait compter sur le fait que la même cohorte serait mise à jour en premier. C'est pourquoi les flags côté serveur et une branche de hotfix publiable rapidement comptent davantage que le bouton pause.

Comment se compare le déploiement progressif de Google Play ?

Le déploiement progressif de Google Play utilise un pourcentage que vous choisissez et augmentez manuellement. Après un arrêt, une reprise touche le même ensemble d'utilisateurs. Planifiez les déploiements des deux stores séparément.

D'après l'aide Play Console, « le pourcentage de déploiement progressif de votre app n'augmentera pas automatiquement », et les déploiements progressifs « ne peuvent être utilisés que pour les mises à jour d'apps, pas lors de la première publication d'une app ». Après un arrêt, les utilisateurs qui ont déjà reçu la version la conservent, et Google conseille de publier une nouvelle version avec un bundle corrigé plutôt que de reprendre une version défectueuse. Les déploiements en production peuvent être limités à certains pays, mais une fois le déploiement lancé, vous ne pouvez plus retirer de pays. Si votre prochaine mise à jour Android doit aussi respecter le nouveau SDK cible, consultez notre guide sur le niveau d'API cible 36 sur Google Play.

Que vérifier avant de lancer une publication progressive ?

Avant le début du déploiement, assurez-vous que la publication progressive est enregistrée sur la version, que vos références et déclencheurs de pause sont écrits, et qu'un correctif peut être publié rapidement. Utilisez cette checklist :

• Publication progressive sélectionnée et enregistrée sur la page de la version
• Tableaux de bord de crash reporting et d'erreurs backend en favoris, avec les références de la version précédente
• Déclencheurs de pause écrits et validés par toutes les personnes habilitées à appuyer sur le bouton
• Fonctionnalités risquées derrière des flags côté serveur
• Une personne désignée qui vérifie les métriques chacun des 7 jours
• Une branche de hotfix prête, ainsi que notre checklist de soumission App Store pour le build suivant
• Modifications de la fiche store retenues jusqu'à ce que le déploiement atteigne tout le monde

Si vous préférez déléguer la release elle-même, notre service de soumission App Store couvre la configuration d'App Store Connect et de la Play Console, la préparation à la revue et les publications sur les deux stores pour $599 (frais de compte développeur en sus). Pour un second avis sur une mise à jour risquée, écrivez à yagyeshsrbobde@gmail.com en précisant votre app et ce qui change.