Exemples de notes de version App Store : un texte « Nouveautés » qui dit ce qui a changé (2026)

De bonnes notes de version App Store répondent à une seule question : qu'est-ce qui change pour moi après la mise à jour ? Les exemples de notes de version App Store ci-dessous suivent tous le même schéma. Commencez par le changement que l'utilisateur remarquera, nommez précisément chaque correctif et laissez de côté tout ce qu'il ne peut pas voir. Les recommandations d'Apple pour le champ Nouveautés de cette version vont dans le même sens : elles demandent de décrire les nouvelles fonctionnalités, améliorations de l'interface ou corrections de bugs, et conseillent d'indiquer aux utilisateurs « le détail des changements, améliorations ou correctifs de la version ».

Quelles sont les règles des notes de version dans App Store Connect et Google Play ?

Le champ « Nouveautés » d'Apple accepte 4 000 caractères et est obligatoire pour chaque version après la première. Google Play accepte 500 caractères Unicode par langue et interdit le contenu promotionnel.

En octobre 2026, l'aide de la Play Console indique : « N'utilisez pas les notes de version à des fins promotionnelles ni pour solliciter des actions de l'utilisateur. » Chez Apple, placez plutôt vos messages marketing dans le Texte promotionnel. Ce champ accepte 170 caractères, s'affiche au-dessus de votre description, et Apple vous permet de le modifier sans soumettre de nouvelle version.

À quoi ressemblent de bonnes notes de version App Store ?

De bonnes notes de version nomment la situation dans laquelle se trouvait l'utilisateur et le résultat qu'il obtient désormais. Les exemples ci-dessous proviennent d'une app fictive de suivi d'habitudes. Les versions vagues sont le genre de notes rédigées à la dernière minute.

Si un correctif est trop technique pour être expliqué en une phrase, les utilisateurs ne le remarqueront probablement pas : il peut alors figurer sous une seule ligne « améliorations de stabilité » à la fin. La règle 2.3.12 l'autorise pour les correctifs mineurs, mais pas pour de vrais changements de fonctionnalités.

Existe-t-il un modèle de notes de version réutilisable ?

Oui. Un modèle réutilisable comporte un titre, puis des sections Nouveau, Amélioré et Corrigé. Conservez-le dans votre dépôt à côté du changelog et remplissez-le au moment où vous créez la branche de release, pas après l'envoi du build.

[One-line headline: the change most users will notice]

New
- [Feature]: [what you can now do], [where to find it]

Improved
- [Screen or flow]: [what feels different]

Fixed
- [Symptom the user saw] when [situation]

Thanks for the reports. Reply via Settings > Help if anything looks off.

Pour Google Play, réduisez ces mêmes notes au titre et aux deux ou trois premières puces afin qu'elles tiennent en 500 caractères. Placez les balises de chaque langue sur leurs propres lignes, par exemple <en-US> et </en-US>. Supprimez la phrase de conclusion sur Play, car elle demande à l'utilisateur de faire quelque chose.

Comment transformer des pull requests fusionnées en notes de version ?

Pour transformer des pull requests fusionnées en notes de version, écartez les changements invisibles pour les utilisateurs, puis réécrivez chaque changement restant sous forme de symptôme ou de résultat. Suivez ces étapes à chaque release.

1. Exportez les titres des pull requests fusionnées depuis le dernier tag, puis supprimez tout ce que les utilisateurs ne voient pas : refactorisations, mises à jour de dépendances, changements de CI.
2. Réécrivez chaque élément restant sous forme de symptôme ou de résultat. « Fix nil coordinator » devient « Correction d'un écran vide après la connexion avec Apple ».
3. Classez les éléments selon le nombre d'utilisateurs concernés, pas selon l'effort d'ingénierie qu'ils ont demandé.
4. Dans App Store Connect, créez la nouvelle version, puis effacez le texte « Nouveautés » copié avant de coller les nouvelles notes, car les métadonnées de la version précédente sont reprises.
5. Collez les notes dans chaque localisation prise en charge, traduites ou au moins vérifiées dans chaque langue, pour que les utilisateurs des autres langues ne voient pas les notes de la version précédente.
6. Pour Play, collez la version raccourcie entre les balises de langue et vérifiez que chaque langue reste sous les 500 caractères.
7. Lisez les notes à voix haute une fois. Si une phrase nécessite l'explication d'un développeur, réécrivez-la.

Que doivent dire les notes de version d'un correctif urgent ?

Les notes d'un correctif urgent (hotfix) doivent nommer la version défectueuse, décrire le symptôme désormais corrigé et indiquer aux utilisateurs concernés ce qui se passe après la mise à jour. Apple ne permet pas de revenir à une version précédente sur l'App Store : un correctif est donc toujours publié sous forme de nouvelle version.

Exemple : « Correction d'un problème de la version 3.4.0 qui empêchait les rappels de se déclencher chez certains utilisateurs. Les rappels définis avant la mise à jour reprendront automatiquement. » Les utilisateurs touchés savent qu'ils doivent mettre à jour, et les autres comprennent que le correctif ne les concerne pas. Ne rejetez pas la faute sur le système d'exploitation et ne promettez pas de dates pour de futurs correctifs. Si vous publiez vos mises à jour en déploiement progressif, mettre le déploiement en pause limite le nombre d'utilisateurs qui reçoivent le build défectueux pendant que le correctif est en revue. Si le hotfix modifie le comportement d'une fonctionnalité, repassez la checklist de soumission App Store pour que les notes, les captures d'écran et les notes de revue concordent.

App Review peut-il rejeter une mise à jour à cause de ses notes de version ?

Oui. Les notes de version sont des métadonnées, et les App Review Guidelines les couvrent directement. La règle 2.3.12 indique : « Les apps doivent décrire clairement les nouvelles fonctionnalités et les changements de produit dans leur texte "Nouveautés". »

Une formulation générique est autorisée pour « les simples corrections de bugs, mises à jour de sécurité et améliorations de performances », mais « les changements plus importants doivent être listés dans les notes ». La règle 2.3.10 interdit les noms ou visuels d'autres plateformes mobiles dans les métadonnées, ce qui inclut « Nouveautés ». Ne décrivez pas de fonctionnalités cachées derrière des feature flags ni quoi que ce soit qui ne figure pas dans le build soumis. La règle 2.3.1(a) exige par ailleurs que les nouvelles fonctionnalités soient « décrites de manière précise dans la section Notes for Review » : placez-y les étapes destinées au réviseur et un compte de démonstration, pas dans les notes publiques. Si vous recevez une question sur vos métadonnées, notre guide sur la résolution des rejets App Store explique comment répondre.

Quels problèmes de notes de version d'autres développeurs ont-ils rencontrés ?

Les cas signalés publiquement montrent deux types d'échec : des envois rejetés pour dépassement de la limite de longueur d'une boutique, et des rejets en revue dont les instructions de nettoyage incluent le texte « Nouveautés ».

• Limite de longueur Play en CI. Une issue GitHub dans un template de déploiement Flutter signale un changelog généré par IA qui a fait échouer un envoi en test interne Google Play via fastlane avec : « The release created has notes in language ko-KR with length 612, which is too long (max: 500). » Les mainteneurs ont ajouté un script qui tronque les notes avant l'envoi : 480 caractères pour Play et 3 800 octets pour TestFlight, dont la limite se mesure en octets.
• Nettoyage 2.3.10 incluant « Nouveautés ». Un développeur a publié sur les Apple Developer Forums un rejet au titre de la règle 2.3.10, provoqué par des barres d'état non iOS dans ses captures d'écran. Les étapes suivantes indiquées par Apple demandaient de « supprimer toutes les occurrences de ces informations de votre app et de ses métadonnées, y compris la description de l'app, le texte promotionnel, les informations "Nouveautés", les aperçus et les captures d'écran ». Les réponses conseillaient de refaire les captures d'écran et de vérifier chaque champ de métadonnées, notes de version comprises.

À retenir : la limite de longueur est mécanique et échoue bruyamment à l'envoi, tandis que les règles de revue portent sur le contenu et s'appliquent à chaque champ de métadonnées. Automatisez une vérification du nombre de caractères, et relisez « Nouveautés » avec le même soin que vos captures d'écran.

Que vérifier avant de soumettre ses notes de version ?

Avant de soumettre, vérifiez que les notes ne décrivent que ce qui se trouve dans le build, respectent les limites de chaque boutique et remplacent le texte de la version précédente dans chaque langue.

• Le titre nomme le changement que la plupart des utilisateurs remarqueront.
• Chaque fonctionnalité ou changement de produit important est listé, comme l'exige la règle 2.3.12.
• Chaque correctif décrit un symptôme constaté par l'utilisateur, pas du code interne.
• Aucune fonctionnalité derrière un feature flag, aucune promesse future, aucun numéro de ticket interne, aucun nom d'autre plateforme.
• Le texte « Nouveautés » de la version précédente est effacé et remplacé dans chaque localisation.
• Les notes Play font moins de 500 caractères par langue, sont encadrées par les bonnes balises de langue et ne contiennent ni promotion ni appel à l'action.
• Les messages marketing sont déplacés dans le Texte promotionnel chez Apple.
• Si vous avez aussi des testeurs Android, les mêmes notes ont été vérifiées par rapport à votre plan de test fermé.

Si vous souhaitez un regard extérieur sur les métadonnées de votre mise à jour avant de la soumettre, envoyez un e-mail à yagyeshsrbobde@gmail.com avec votre brouillon de notes et la liste des changements du build, ou consultez nos services.