Build actif TestFlight

Build actif TestFlight : Livraison actuellement proposée aux testeurs, remplacée dès qu’un nouveau build est activé pour le groupe concerné.

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.

Pourquoi Build actif TestFlight compte sur un projet mobile

Build actif TestFlight relève de la publication, une étape que beaucoup de plannings traitent comme une formalité de dernière semaine. C’est souvent là que les projets prennent leur dernier retard.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

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

Dans un cahier des charges, Build actif TestFlight se range au chapitre publication, avec les comptes développeur, les pays de diffusion et le calendrier de soumission.

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

• Qui rédige la fiche produit, et qui la valide avant soumission.
• Le nombre d’allers-retours de revue inclus dans le forfait.
• Les déclarations de collecte de données exigées par les deux boutiques.
• Le mode de déploiement retenu : diffusion progressive ou mise à disposition immédiate.

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.

Ce que ça change au moment de la recette

À la recette, Build actif TestFlight se vérifie deux fois, une par boutique : les exigences d’Apple et celles de Google ne se recouvrent pas.

• 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.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Les pièges à éviter

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 :

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

Questions fréquentes

Que signifie « Build actif TestFlight » ?

Livraison actuellement proposée aux testeurs, remplacée dès qu’un nouveau build est activé pour le groupe concerné. 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.

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.

Où placer ce point dans le cahier des charges ?

Dans le chapitre qui correspond à sa nature, jamais dans une ligne fourre-tout. Le modèle de cahier des charges propose les rubriques attendues et l’ordre dans lequel les remplir.

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