Prêt pour la vente

Prêt pour la vente : Statut App Store d’une version approuvée et disponible, ou en attente de la date de publication choisie.

Classé dans la famille « Stores et publication », ce terme revient dans les échanges entre un client et son agence. Voici ce qu’il faut en comprendre avant d’en discuter le prix.

Où intervient Prêt pour la vente dans un projet

Prêt pour la vente intervient au moment le plus risqué du projet, celui où le code est terminé et où la mise en ligne dépend d’un tiers qui applique ses propres critères.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

De la définition à la ligne de cahier des charges

Le cahier des charges doit dire qui prend en charge « Prêt pour la vente » : 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.

Cette formulation se rédige avant la consultation, pas après réception des propositions : c’est elle qui rend deux devis comparables entre eux.

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.

Les contrôles à prévoir

Prêt pour la vente se vérifie sur un appareil réel et sur la version publiée, pas sur la préversion distribuée aux testeurs.

• Confronter les déclarations de collecte à ce que fait réellement l’application.
• Regarder les captures d’écran aux formats d’appareils réellement utilisés.
• Noter les dates d’expiration des certificats et des comptes payants.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

Erreurs fréquentes

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

• Ouvrir les comptes développeur au nom de l’agence plutôt qu’à celui du client.
• Bâcler la fiche produit, alors que le trafic des boutiques se joue dessus.
• Sous-estimer la vérification d’identité du compte développeur, qui bloque tout le reste.
• Prendre un rejet pour une fatalité au lieu de répondre point par point au motif invoqué.
• 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 :

• Trafic de recherche
• Guideline 3.1.1
• ASO
• TestFlight
• Partage familial App Store

Questions fréquentes

Prêt pour la vente : de quoi parle-t-on exactement ?

Statut App Store d’une version approuvée et disponible, ou en attente de la date de publication choisie. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Combien de temps prévoir avant la mise en ligne ?

Prévoyez une marge, sans promettre de date au jour près : la revue des boutiques échappe au prestataire. Les plannings qui calent une sortie sur un événement commercial sans marge sont ceux qui dérapent.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

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