Gérer le versionnage de ses apps

Le versionnage sémantique est la convention très répandue qui consiste à écrire votre nom de version en trois numéros, majeur.mineur.correctif, où chaque position signale l'ampleur du changement. Vous augmentez le numéro majeur pour les gros changements ou les changements cassants et les refontes, le numéro mineur pour les nouvelles fonctionnalités qui ne cassent pas le comportement existant, et le numéro de correctif pour les corrections de bugs et petits ajustements. Ainsi 2.4.1 signifie version majeure 2, quatrième publication de fonctionnalités dans cette lignée, avec un correctif par-dessus. C'est une convention, pas une règle des stores, mais l'adopter rend votre historique lisible d'un coup d'œil et aide toute l'équipe à s'accorder sur le contenu d'une publication avant sa sortie.

• Majeur (le premier numéro) : changements cassants, refontes majeures ou nouvelle version payante. Exemple : 1.9.0 devient 2.0.0.
• Mineur (le numéro du milieu) : nouvelles fonctionnalités rétrocompatibles. Exemple : 2.3.4 devient 2.4.0.
• Correctif (le dernier numéro) : corrections de bugs et petites corrections sans nouvelle fonctionnalité. Exemple : 2.4.0 devient 2.4.1.

Une habitude à garder : remettez les numéros inférieurs à zéro quand un numéro supérieur change. Quand vous augmentez le numéro mineur, le correctif revient à 0, et quand vous augmentez le majeur, le mineur et le correctif reviennent tous les deux à 0. C'est ce qui fait que 3.0.0 se lit comme une nouvelle lignée propre plutôt que 3.4.7 sorti de nulle part.

Sur iOS, le nom de version réside dans un champ appelé CFBundleShortVersionString, que App Store Connect et Xcode nomment simplement Version. C'est le numéro public de style 2.4.1 que vos utilisateurs voient. Le numéro de build réside dans un champ distinct appelé CFBundleVersion, nommé Build. Apple exige qu'à l'intérieur d'un même nom de version, chaque nouveau build envoyé ait un numéro de build supérieur, et accepte plusieurs formats courants comme un entier simple ou une forme à points comme 1043 ou 1.0.43. Quand vous soumettez une nouvelle version à la review, vous choisissez le build précis à lui attacher. Un détail utile : une fois qu'un nom de version a été publié sur l'App Store, vous ne pouvez pas le réutiliser pour une autre publication, alors traitez vos noms de version publiés comme définitifs.

Sur Android, le nom de version s'appelle versionName et se comporte comme le champ Version d'iOS : c'est votre chaîne publique 2.4.1 et elle peut être ce que vous voulez. Le numéro de build s'appelle versionCode, et c'est là qu'Android est plus strict qu'iOS. Le versionCode doit être un entier positif, sans points, et il doit toujours augmenter à chaque build envoyé sur un canal donné de Google Play. Google Play utilise le versionCode seul pour décider quel build est le plus récent, donc un build avec un versionCode plus élevé est toujours traité comme la mise à jour. Si vous oubliez de l'augmenter, la Play Console rejette l'envoi purement et simplement. Comme c'est un entier, les équipes le dérivent souvent d'un compteur de build ou d'une date, mais la seule exigence stricte est qu'il ne recule jamais.

• versionName : la chaîne publique, par exemple 2.4.1. Montrée aux utilisateurs, libre, pas forcément numérique.
• versionCode : un entier positif, par exemple 1043. Jamais montré aux utilisateurs, doit strictement augmenter, et c'est ainsi que Google Play classe les builds.
• Les deux résident dans votre configuration de build (build.gradle pour l'Android natif, ou pubspec.yaml pour Flutter où le format est versionName+versionCode, comme 2.4.1+1043).

Garder le nom de version identique sur les deux plateformes est une bonne habitude qui paie constamment. Quand un utilisateur signale un bug sur 2.4.1, vous voulez que cela désigne la même publication sur iOS et Android, pas deux états de code différents. Quand votre support, votre changelog et vos analytics reposent tous sur un seul nom de version, le débogage multiplateforme devient nettement plus simple. Les numéros de build, en revanche, n'ont pas besoin de correspondre, car iOS et Android les incrémentent indépendamment et les stores ne les comparent jamais. La règle pratique est donc : partagez le nom de version marketing entre les deux stores, et laissez chaque plateforme gérer son propre numéro de build. Si vous compilez avec Flutter ou React Native depuis une seule base de code, vous produisez déjà les deux apps depuis la même source, ce qui fait d'un nom de version partagé le choix naturel par défaut.

Les notes de version, souvent appelées le texte Nouveautés, sont la courte description attachée à chaque version qui explique ce qui a changé. Les deux stores les affichent sur la fiche et sur l'écran de mise à jour, elles sont donc bien plus lues que les développeurs ne le pensent. De bonnes notes sont précises et orientées utilisateur : elles décrivent ce que la personne obtient ou ce qui a été corrigé, pas des numéros de tickets internes ou des refactorisations. Commencez par le changement que les utilisateurs remarqueront le plus, gardez chaque ligne courte, et évitez le remplissage générique du type corrections de bugs et améliorations de performance quand vous avez vraiment quelque chose de concret à dire. Comme les deux stores acceptent des notes de version localisées, les traduire pour vos principaux marchés est un moyen peu coûteux de faire sentir qu'une mise à jour a été soignée plutôt que publiée et oubliée.

1. Ouvrez par le changement phare, la seule chose qui intéressera le plus les utilisateurs.
2. Listez les ajouts ou corrections notables en langage clair, un par ligne.
3. Harmonisez le ton entre iOS et Android pour qu'un utilisateur voie la même histoire sur les deux.
4. Localisez les notes pour vos principaux marchés, comme vous localisez la fiche.
5. Gardez aussi un changelog interne, pour que la version 2.4.1 corresponde toujours à un ensemble connu de commits.

Les deux stores vous permettent de publier une nouvelle version à une partie de vos utilisateurs d'abord, puis de l'élargir, pour qu'un mauvais build n'atteigne pas tout le monde d'un coup. Sur Google Play, cela s'appelle le déploiement progressif : vous choisissez un pourcentage, par exemple 10 pour cent, et Google livre la mise à jour à cette part d'utilisateurs, vous laissant augmenter le pourcentage ou arrêter le déploiement si les taux de crash grimpent. Sur l'App Store, l'équivalent est la publication par phases, qui déploie automatiquement une mise à jour automatique sur une fenêtre de sept jours par étapes croissantes, avec une option de pause. Dans les deux cas, les utilisateurs peuvent quand même obtenir la dernière version immédiatement s'ils mettent à jour manuellement depuis le store, donc un déploiement par phases ralentit les mises à jour automatiques plutôt que de cacher la publication. Pour toute mise à jour touchant du code risqué, l'activer vous donne une soupape de sécurité.

La plupart des soucis de versionnage viennent d'une courte liste d'erreurs évitables, et presque toutes surgissent au moment de l'envoi, quand vous voulez le moins de ce retard. Les connaître à l'avance vous évite un build rejeté pendant une publication que vous essayiez de sortir vite.

• Oublier d'augmenter le versionCode Android, si bien que Google Play rejette le .aab parce que le numéro existe déjà. C'est le point bloquant numéro un le jour d'une publication.
• Réutiliser un numéro de build iOS sous le même nom de version, ce qu'App Store Connect refuse de la même façon.
• Laisser les noms de version iOS et Android diverger, si bien que 2.4.1 sur iOS n'est pas le même code que 2.4.1 sur Android et que les rapports de bugs deviennent ambigus.
• Éditer les versions à la main dans le fichier de build et en oublier une plateforme, ce qui est facile quand les deux numéros vivent dans des fichiers différents.
• Publier un nom de version qui recule ou saute, ce que les stores ne bloquent pas mais qui déroute les utilisateurs et votre propre changelog.

La correction fiable est de faire de l'incrémentation de version une partie de votre processus de publication plutôt que quelque chose que vous retenez à la main. Que vous le scriptiez en CI ou le gériez dans une plateforme de publication, l'objectif est que le bon nom de version et un numéro de build toujours croissant soient définis de la même façon à chaque fois, pour les deux stores, pour qu'un envoi rejeté ne vous coûte jamais une heure le jour d'une publication. Si vous compilez en multiplateforme, voyez comment fonctionne le côté iOS de ce pipeline pour Flutter et pour React Native.

versionName est la chaîne publique que les utilisateurs voient, comme 2.4.1, et elle peut être n'importe quoi. versionCode est un entier positif, comme 1043, que les utilisateurs ne voient jamais et que Google Play utilise pour décider quel build est le plus récent. Le versionCode doit augmenter à chaque envoi, tandis que le versionName peut se répéter ou suivre n'importe quel schéma. Ce sont les équivalents Android des champs Version et Build d'iOS.

Non, pas au sein du même canal de store. Sur Google Play, le versionCode doit être strictement supérieur à l'envoi précédent, et sur l'App Store, le numéro de build doit être supérieur au sein d'un nom de version donné. Vous pouvez garder le nom de version public identique sur plusieurs builds, par exemple en corrigeant un rejet de review, mais chacun de ces builds a besoin de son propre numéro de build supérieur pour être accepté.

Les stores ne l'exigent pas, et ils ne comparent jamais les deux plateformes. Faire correspondre le nom de version public entre iOS et Android est une convention forte, car elle rend les rapports de bugs, les analytics et le support sans ambiguïté. Les numéros de build, en revanche, sont gérés indépendamment par plateforme et n'ont pas besoin de correspondre, puisque chaque store suit son propre compteur et ne regarde jamais l'autre.

Vous ne pouvez pas vraiment annuler une version, car aucun store ne vous laisse remplacer un build publié par du code plus ancien sous le même nom de version. Si vous l'avez attrapé pendant un déploiement progressif ou par phases, arrêtez le déploiement pour empêcher de nouveaux utilisateurs de l'obtenir. Puis corrigez le bug et publiez une nouvelle version supérieure. C'est pourquoi une incrémentation de version rapide et correcte compte : votre chemin de récupération va toujours vers l'avant, jamais vers l'arrière. Versionner de la même façon vos documents légaux et métadonnées de store évite des surprises similaires.