Release notes mobiles : ce que la limite fait sauter

Tout ce que ce hub dit sur l’écriture de release notes suppose une page qu’on contrôle entièrement : n’importe quelle longueur, des liens qui fonctionnent, une mise en forme qui s’affiche. Les release notes d’une app mobile vivent dans la boîte de quelqu’un d’autre. Apple donne environ 4 000 caractères mais n’affiche que les premières lignes avant qu’on touche « plus » ; Google donne un espace similaire avec le même problème d’aperçu, et aucune des deux plateformes n’affiche de lien cliquable dans le texte. Les règles de comment écrire des release notes que les gens lisent vraiment s’appliquent toujours : dire ce qui a changé et ce que la lectrice doit faire, mais l’espace pour le faire est une fraction de ce que permet une page de changelog, et les coupes doivent être délibérées, pas accidentelles.

Qu’est-ce qui entre vraiment dans l’aperçu visible ?

Les une à deux premières lignes, environ 80 à 170 caractères selon l’appareil et la taille de police, avant que la lectrice doive toucher pour développer. C’est tout le budget pour la partie de la release note qui décide si quelqu’un va lire le reste, et ça veut dire que la phrase la plus importante doit venir en premier, pas le numéro de version, pas une salutation, pas un en-tête de catégorie. Une release note qui commence par « Nouveautés de cette version : » a déjà dépensé un tiers de son espace visible sur quatre mots qui ne disent rien à la lectrice.

La règle « ce que vous pouvez faire maintenant, ce qu’on vous doit » fonctionne-t-elle toujours à cette longueur ?

Oui, et elle devient plus stricte, pas différente. Une phrase par entrée, verbe en premier, sans mise en contexte : « Exportez vos données en CSV depuis Paramètres. » bat « Nous avons ajouté la possibilité pour les utilisateurs d’exporter désormais leurs données au format CSV » en utilisant un tiers des mots pour dire la même chose. À la longueur d’une page de changelog, une phrase un peu bavarde coûte une demi-seconde à la lectrice. À la longueur d’une release note mobile, cette même verbosité peut pousser la phrase entière hors de l’aperçu visible, si bien que la lectrice ne voit jamais le verbe qui lui aurait dit ce qui a changé.

Mauvais, gaspille l'aperçu sur l'emballage :
"Nous sommes ravis de vous apporter une nouvelle mise
à jour pleine d'améliorations ! Lisez la suite pour
les détails."

Bon, toute la valeur dans la première ligne :
"Exportez vos données en CSV. Le mode sombre respecte
désormais le réglage système. Correction d'un plantage
à l'ouverture de liens partagés."

Qu’est-ce qui doit être coupé qu’une entrée de changelog web garderait normalement ?

Les liens, d’abord, parce qu’aucun des deux stores ne les rend cliquables, donc une URL dans le texte est un poids mort que la lectrice devrait retaper. Si l’entrée a besoin d’une destination, dites plutôt quoi toucher dans l’app : « Voyez les nouveaux filtres sous Paramètres > Recherche » fonctionne ; « Lisez-en plus sur example.com/blog/filtres » ne fonctionne pas, sur cette surface. Ensuite, tout ce qui est conditionnel ou spécifique à un public : un changelog web peut dire « si vous utilisez l’API, ça vous concerne », mais une fiche de store atteint chaque utilisatrice installée en même temps, donc une ligne conditionnelle se lit comme du bruit pour les 95 % à qui ça ne s’applique pas. Mettez le détail conditionnel dans un message in-app à la place, déclenché pour les comptes que ça concerne réellement.

Chaque version devrait-elle avoir ses propres notes, ou est-ce correct de réutiliser « corrections de bugs et améliorations de performances » ?

Réutilisez-le pour les versions qui sont vraiment ça, mais vérifiez à quelle fréquence c’est vraiment vrai. Comment écrire des release notes couvre déjà pourquoi cette phrase trahit une note écrite de l’intérieur plutôt que pour la lectrice ; sur mobile, elle fait un double dégât, parce que les release notes du store sont l’un des rares endroits où certaines utilisatrices voient quoi que ce soit entre deux mises à jour, et une longue série de « corrections de bugs et améliorations de performances » se lit comme si l’app ne changeait pas, ce qui est une impression pire qu’aucune note du tout pour cette période.

Les release notes influencent-elles si les gens mettent à jour l’app ?

Indirectement, via la visibilité plutôt que la persuasion. La plupart des utilisatrices mettent à jour automatiquement et ne lisent jamais les notes avant de le faire ; les notes comptent le plus pour la minorité qui vérifie les mises à jour manuellement, et pour les critiques ou la presse qui parcourent l’historique d’une fiche de store. Écrire pour ce public plus restreint est quand même rentable, parce qu’une fiche avec un vrai historique d’entrées spécifiques et datées se lit comme une app activement maintenue, et une fiche avec un an de « corrections de bugs et améliorations de performances » non, peu importe ce qui a réellement été livré durant cette période.

Et une mise à jour forcée, où la note doit expliquer pourquoi l’utilisatrice n’a pas le choix ?

Indiquez la raison et l’échéance dans la première ligne, avant tout le reste, parce qu’une mise à jour forcée est le seul cas où la lectrice est agacée avant même de commencer à lire. « Cette mise à jour est nécessaire pour continuer à synchroniser vos données. Mettez à jour avant le [date] pour éviter une interruption. » dit quoi faire et pourquoi en une seule phrase ; enterrer cette raison sous trois lignes de notes de fonctionnalités sans rapport se lit comme si l’app cachait la partie gênante.

FAQ

Les release notes mobiles devraient-elles correspondre au changelog web de la même version ? Couvrir les mêmes changements sous-jacents, mais pas mot pour mot. Le changelog web peut se permettre l’explication complète ; la note mobile a besoin des mêmes faits compressés en une phrase avec le verbe en premier, ce qui veut généralement dire que c’est une réécriture, pas un copier-coller.

Vaut-il la peine de localiser les release notes mobiles pour chaque langue supportée ? Oui, plus que pour un changelog web, parce que la fiche du store est souvent la seule surface localisée que certaines utilisatrices voient entre deux sessions, et les deux plateformes supportent des release notes par locale sans travail d’ingénierie supplémentaire au-delà de la traduction elle-même.

Quelle longueur devrait avoir une release note mobile s’il n’y a pas de limite forçant la concision ? Courte quand même. Le plafond de 4 000 caractères sur iOS est rarement la vraie contrainte ; c’est l’aperçu de 2-3 lignes qui l’est, et écrire au-delà de ce que cet aperçu montre veut juste dire que moins de gens lisent la partie qui comptait.

Les release notes ont-elles besoin du numéro de version dans le texte visible ? Non. Le store affiche déjà le numéro de version à côté des notes. Le répéter dans le texte dépense des caractères visibles sur une information que la lectrice a déjà sous les yeux.

Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.

À voir sur changeloop : Modèle de release notes, Exemples de changelog