Publier une mise à jour iOS : déploiement progressif

Pour publier une mise à jour iOS, tu crées une nouvelle version dans App Store Connect, avec un numéro plus haut. Tu y attaches un nouveau build, tu écris le texte « Nouveautés », puis tu l'envoies à App Review. Chaque nouvelle version repasse par la revue d'Apple, même pour un simple correctif. Avant l'envoi, tu choisis comment elle sortira après l'accord : à la main, tout de suite, pas avant une date, ou en déploiement progressif sur 7 jours.

Le déploiement progressif ne touche que les mises à jour automatiques : 1 % de ces utilisateurs le premier jour, tous le septième. Tu peux le mettre en pause jusqu'à 30 jours au total, ou le terminer d'un coup. Ce guide suit les pages d'aide d'Apple, relues le 3 novembre 2026.

Je publie les mises à jour de mes apps iOS avec Expo et EAS, dont Solys, TradaZen et Nolera. Les cas cités plus bas viennent de ces sorties.

Publier une mise à jour iOS : les étapes dans l'ordre

L'aide d'App Store Connect sur les nouvelles versions donne ce parcours :

1. Dans Apps, choisis ton app, puis clique sur le bouton + à côté de la plateforme.
2. Saisis un numéro de version plus haut que le précédent, puis clique sur Create.
3. Relis les métadonnées : celles de la version en ligne sont recopiées automatiquement.
4. Envoie un nouveau build, avec un numéro de build incrémenté.
5. Teste ce build dans TestFlight, ajoute-le à la version, puis soumets-la à App Review.

Deux conditions avant de commencer. La version en ligne doit être au statut Ready for Distribution. Et il te faut l'un de ces rôles : Account Holder, Admin, App Manager ou Marketing.

Il n'existe pas de retour arrière. Apple l'écrit sur la même page : si une version pose problème, tu ne peux pas revenir à la précédente. Tu dois créer et soumettre une nouvelle version.

Numéro de version et numéro de build

La version est le numéro que tes clients voient sur ta fiche. Le build identifie chaque envoi. Le couple version et build doit être unique : les règles et les erreurs associées sont dans version et numéro de build.

Ma convention, qui n'est pas une règle d'Apple : le dernier chiffre monte pour un correctif, de 1.4.0 à 1.4.1. Celui du milieu monte pour une nouvelle fonction, de 1.4.1 à 1.5.0. Le numéro de build, lui, ne fait que monter, d'une version à l'autre. Avec Expo, la version vit dans app.json et EAS peut incrémenter le build à chaque compilation de production. La mise en place est dans publier une app Expo avec EAS.

Le texte « Nouveautés » : ce qu'Apple exige

La page des informations de version décrit le champ What's New in This Version :

• 4 000 caractères au plus.
• Absent pour la première version, obligatoire pour toutes les suivantes.
• Traduisible dans chaque langue de ta fiche.

La règle 2.3.12 des App Review Guidelines ajoute une exigence : décrire clairement les nouvelles fonctions et les changements du produit. Une formule générale suffit pour de simples corrections de bugs, de sécurité ou de performance. Un changement important doit être listé. « Corrections de bugs et améliorations » ne suffit donc pas pour une version qui change ton abonnement ou ton écran principal.

Apple conseille aussi, sur sa page consacrée aux avis, de signaler dans les notes les problèmes corrigés que des clients avaient décrits dans leurs avis.

Voici trois modèles à adapter, un par type de version.

Pour un correctif :

Corrections et stabilité.
- [Fonction] : [ce qui ne marchait pas] est corrigé.
- [Écran] se charge plus vite.
Merci à celles et ceux qui l'ont signalé.

Pour une nouvelle fonction :

Nouveau : [la fonction, en cinq mots].
[Ce que tu peux faire maintenant, en une phrase.]
Où la trouver : [onglet] > [bouton].

Aussi dans cette version :
- [Amélioration visible].
- Corrections de bugs.

Pour un parcours qui change :

[Écran ou parcours] change.
- Ce qui change pour toi : [effet concret].
- Ce que tu gardes : [données, réglages, achat].
Une question ? [Réglages] > [Aide].

La dernière ligne du modèle de correctif ne vaut que si quelqu'un a vraiment signalé le problème. N'écris jamais une nouveauté qui n'est pas dans le build : la règle 2.3 demande des métadonnées fidèles à l'app.

Sortie manuelle, automatique ou à une date

L'aide sur les options de sortie en propose trois :

Option	Après l'accord d'Apple
Manuelle	Statut Pending Developer Release, tu publies quand tu veux
Automatique	La version sort dès l'accord
Automatique, pas avant le...	Elle attend la date choisie, puis sort seule

En sortie manuelle, tu ouvres la version au statut Pending Developer Release, tu cliques sur Release This Version, puis tu confirmes. Apple prévient qu'elle peut mettre jusqu'à 24 heures à apparaître sur l'App Store. Un message sur la page de la version propose Cancel This Release pour annuler. Si la version reste plus de 30 jours en attente, Apple t'envoie un rappel par e-mail.

La sortie manuelle sert à choisir le moment, par exemple pour publier le jour d'une annonce. Solys 2.0.0, qui embarquait une nouvelle version de l'abonnement annuel, est partie en revue fin septembre 2026 en sortie manuelle.

Pour une version de routine, je laisse la sortie automatique. Nolera 1.0.2, acceptée le 12 octobre 2026, est apparue dans l'App Store moins d'une minute après l'e-mail d'Apple, d'après l'API publique de recherche d'iTunes. C'est une seule observation : compte large.

Le déploiement progressif sur 7 jours

L'aide d'Apple sur le déploiement progressif donne le calendrier exact :

Jour	Part des utilisateurs
1	1 %
2	2 %
3	5 %
4	10 %
5	20 %
6	50 %
7	100 %

La mise à jour part vers un échantillon aléatoire des utilisateurs qui ont activé les mises à jour automatiques, sur les appareils compatibles. Ils ne sont pas prévenus qu'ils en font partie.

Le déploiement progressif ne freine que les mises à jour automatiques. Apple précise que n'importe qui peut télécharger la nouvelle version depuis l'App Store, à tout moment. Une personne qui installe ton app, ou qui touche « Mettre à jour » sur ta fiche, peut donc l'avoir dès le premier jour. Ce n'est pas un test sur 1 % de tes utilisateurs : c'est un frein sur les autres.

Pour l'activer, ouvre la version, descends jusqu'à la section Phased Release for Automatic Updates, coche « Release update over a 7-day period using phased release », puis enregistre. Il faut le rôle Account Holder, Admin ou App Manager. L'option reste disponible jusqu'au statut Pending Developer Release : tu peux encore l'activer après l'accord d'Apple, tant que la version attend ta sortie manuelle.

Une fois la version approuvée, son statut Ready for Distribution porte la mention « Phased Release ». À la fin des 7 jours, les Admin et App Manager de l'app reçoivent une notification.

Pause, reprise et sortie pour tous

• Pause : jusqu'à 30 jours au total, en autant de fois que tu veux. Une pause de 10 jours laisse 20 jours pour les suivantes.
• Reprise : le déploiement repart au jour où tu l'avais arrêté.
• Sortie pour tous : le bouton Release to All Users, en haut à droite de la version, envoie la mise à jour à tous les appareils en mise à jour automatique.
• Retrait de la vente : il arrête le déploiement pour de bon, y compris si ton adhésion au programme développeur expire. Si l'app revient en vente, la version est disponible pour tous d'un coup.

Après la sortie pour tous, plus rien ne se règle, précise le tableau des propriétés modifiables.

Nolera 1.0.2 est sortie sans déploiement progressif. Voici comment je m'en servirais pendant la semaine :

Ce que tu vois	Ce que tu fais	Ce qui se passe
Des plantages ou des avis inquiets	Pause	Les mises à jour automatiques s'arrêtent
Le correctif est prêt	Nouvelle version	Elle repasse en revue, avec son propre déploiement
Rien d'anormal après 3 ou 4 jours	Release to All Users	Tout le monde la reçoit
Tu attends un retour d'Apple	Pause, 30 jours au total	Reprise au jour où tu t'es arrêté

Pendant une pause, les téléchargements manuels continuent. Coche le déploiement progressif pour toute version qui touche le paiement ou le premier lancement : c'est là qu'un défaut coûte le plus cher, et tu ne pourras pas revenir en arrière.

Quand le correctif est urgent : la revue accélérée

Apple permet de demander une revue accélérée. Elle est réservée aux vraies urgences : un bug critique à corriger, ou une sortie liée à un événement.

1. Soumets d'abord ta version. Décris le bug dans le champ Notes destiné au reviewer.
2. Remplis le formulaire de demande de revue accélérée, puis choisis ton app et sa plateforme.
3. Apple accélère la revue selon ses disponibilités. Rien n'est garanti.

Pour un événement, indique dans les notes sa date et ton lien avec lui. Les délais habituels sont dans le délai de validation App Store.

Ce qui repasse en review, et ce qui n'y passe pas

Changement	Ce qu'il faut
Code natif, autorisations, version du SDK	Nouveau build, nouvelle version, revue complète
Captures, description, mots-clés, nouveautés	Une nouvelle version, revue avec elle
Texte promotionnel	Rien : il change sans nouvelle soumission
Pause, reprise, sortie pour tous	Rien : ce sont des réglages de sortie
En-tête de fiche iOS 27	Seul dans Asset Library, ou avec une version
Correctif JavaScript, avec Expo	Une mise à jour à distance est possible

Le texte promotionnel change sans nouvelle soumission, d'après la page des informations de version. Avec Expo, une mise à jour à distance change le JavaScript, les textes et les images sans passer par l'App Store. La documentation d'Expo pose deux limites : le code natif, les autorisations et la version du SDK exigent un nouveau binaire, et les mises à jour doivent respecter les règles de l'App Store.

Mon cas : un correctif à distance que le reviewer n'a jamais vu

En septembre 2026, un build de Nolera attendait la revue. J'avais corrigé un défaut de l'écran de scan, et publié ce correctif en mise à jour à distance pendant l'attente. Le build a quand même été refusé, pour ce défaut déjà corrigé.

L'explication est dans la documentation d'expo-updates : par défaut, l'app télécharge la mise à jour au lancement et l'applique au lancement suivant. Le reviewer installe l'app, la lance une fois, et teste le code embarqué dans le build. La même règle vaut pour tes nouveaux utilisateurs : leur première session tourne sur le code du build.

Depuis, tout changement de l'accueil, du paywall ou de la fonction principale part dans un nouveau build. La mise à jour à distance ne sert qu'aux personnes qui ont déjà l'app.

Remettre la note à zéro avec une version

Chaque nouvelle version propose l'option Reset rating when this version is released. D'après l'aide d'Apple sur la remise à zéro, elle vaut pour tous les pays, garde les avis écrits et ne s'annule pas après la sortie. Apple conseille d'en user avec parcimonie, car une fiche avec peu de notes peut décourager.

La check-list avant de soumettre ta mise à jour

• Le numéro de version est plus haut, le build est incrémenté.
• Le build est testé dans TestFlight, sur un petit iPhone et sur iPad si ton app y tourne.
• Les nouveautés sont écrites dans chaque langue, et les changements importants sont listés.
• Les captures montrent l'interface actuelle si elle a changé.
• Les notes pour le reviewer disent ce qui a changé et où le trouver.
• L'option de sortie est choisie : manuelle si tu dois tenir une date.
• Le déploiement progressif est coché si la version touche le paiement ou le premier lancement.
• Tu sais si un correctif éventuel peut partir à distance, ou s'il demandera un build.

Passer la revue à chaque mise à jour

Chaque mise à jour repasse devant App Review, et un refus bloque ton correctif. Le Kit Review Apple réunit ma checklist avant l'envoi, mes refus corrigés et deux skills Claude Code qui relisent ton projet et ta fiche, puis préparent ta réponse si Apple refuse. Le parcours complet est sur la page publier une application sur l'App Store.

Si tu prépares ta première sortie, fais ton diagnostic gratuit : il remet les étapes dans l'ordre et t'envoie ma checklist anti-refus Apple.

Questions fréquentes

Combien de temps dure le déploiement progressif sur l'App Store ?

Sept jours : 1 % des utilisateurs en mise à jour automatique le premier jour, puis 2, 5, 10, 20 et 50 %, et 100 % le septième. Tu peux le mettre en pause jusqu'à 30 jours au total, ou le terminer à tout moment avec Release to All Users.

Une mise à jour d'app iOS repasse-t-elle par la review d'Apple ?

Oui. Chaque nouvelle version, avec son build et ses métadonnées, passe par App Review. Le texte promotionnel et les réglages de sortie, eux, se changent sans nouvelle soumission.

Peut-on revenir à l'ancienne version d'une app sur l'App Store ?

Non. Il faut créer une nouvelle version, avec le correctif, et la soumettre à la revue. C'est pour ça que le déploiement progressif et sa pause sont utiles.

Les nouveaux utilisateurs reçoivent-ils la mise à jour pendant le déploiement progressif ?

Oui, s'ils téléchargent l'app depuis l'App Store. Le déploiement progressif ne règle que les mises à jour automatiques : n'importe qui peut télécharger la nouvelle version à tout moment.

Peut-on activer le déploiement progressif après l'approbation d'Apple ?

Oui, tant que la version est au statut Pending Developer Release, c'est-à-dire en sortie manuelle et pas encore publiée. Une fois la version sortie, il est trop tard pour cette version.

Que mettre dans les notes de version d'une mise à jour ?

Les nouvelles fonctions et les changements importants, clairement listés : c'est la règle 2.3.12. Pour un simple correctif de bugs, de sécurité ou de performance, une formule générale suffit. Le champ accepte 4 000 caractères et se traduit dans chaque langue.