Note par version

Note par version : Répartition des évaluations selon la version installée, utile pour repérer la mise à jour qui a fait chuter la moyenne.

Cette entrée du glossaire relève de la famille « Stores et publication ». Elle donne la définition, sa traduction en exigences, et les erreurs vues le plus souvent sur des projets réels.

Ce que recouvre Note par version, concrètement

Note par version appartient au vocabulaire des boutiques. Apple et Google fixent les règles, les font évoluer sans préavis, et une application non conforme ne se négocie pas : elle est refusée.

Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.

Comment l’écrire dans un cahier des charges

Le cahier des charges doit dire qui prend en charge « Note par version » : l’agence, le client, ou les deux avec un point de validation. C’est un des trous les plus fréquents des projets mobiles.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les boutiques visées et les pays de diffusion, dès la version 1.
• Le titulaire des comptes développeur, et qui règle leurs frais.
• La procédure en cas de rejet, et le délai de reprise engagé.
• Les captures d’écran et la vidéo de prévisualisation : qui les produit, à quel format.

Le niveau de détail à viser est celui qui permet à deux prestataires différents de chiffrer la même chose. En dessous, les écarts de prix ne veulent rien dire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Vérifier plutôt que croire

Le contrôle de « Note par version » a lieu avant la soumission. Une fois le build parti, la correction coûte un cycle de revue complet.

• Vérifier que le compte développeur est au nom du client avant la première soumission.
• Installer la version publiée depuis la boutique, pas seulement la préversion de test.
• Dérouler le parcours de suppression de compte, exigé par les deux boutiques.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Ce qui tourne mal le plus souvent

Ces erreurs ne viennent presque jamais d’un manque de compétence, mais d’un point qui n’a été écrit nulle part.

• Découvrir les règles d’une boutique au moment de la soumission plutôt qu’au cadrage.
• Caler la mise en ligne la veille d’un événement commercial, sans marge pour un rejet.
• Publier la même fiche dans tous les pays sans traduire ni adapter les captures.
• Oublier la suppression de compte depuis l’application, désormais exigée.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• JWT
• ASO
• TestFlight
• Partage familial App Store
• Notifications temps réel Play

Questions fréquentes

Qu’est-ce que « Note par version » ?

Répartition des évaluations selon la version installée, utile pour repérer la mise à jour qui a fait chuter la moyenne. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

Apple et Google appliquent-ils les mêmes règles ?

Non. Chaque boutique a ses exigences, ses délais et ses motifs de rejet. Un projet qui ne prévoit qu’un seul jeu de contraintes découvre l’autre au moment le plus coûteux.

Par où commencer quand le sujet est nouveau ?

Par les parcours et les règles de gestion, pas par les outils. Le guide du cahier des charges donne l’ordre dans lequel poser les questions à une agence.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.