Expiration d’un build TestFlight

Expiration d’un build TestFlight : Fin de validité automatique au bout de quatre-vingt-dix jours, qui coupe l’accès des testeurs faute de nouveau build.

Entrée de la famille « Stores et publication » du glossaire. Elle s’adresse à un porteur de projet qui doit rédiger, comparer ou recetter, pas à un spécialiste du sujet.

Pourquoi Expiration d’un build TestFlight compte sur un projet mobile

Expiration d’un build 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.

Le sujet mérite trois minutes d’attention au cadrage. C’est le seul moment du projet où il ne coûte rien à traiter.

Comment l’écrire dans un cahier des charges

Un cahier des charges complet chiffre « Expiration d’un build TestFlight » comme une tâche à part entière, avec les allers-retours possibles avec la revue des boutiques.

À é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.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

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, Expiration d’un build 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.

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.

• 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é.
• Repousser l’arbitrage au sprint suivant, autant de fois qu’il y a de sprints.

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
• Build actif TestFlight

Questions fréquentes

Expiration d’un build TestFlight : de quoi parle-t-on exactement ?

Fin de validité automatique au bout de quatre-vingt-dix jours, qui coupe l’accès des testeurs faute de nouveau build. 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.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

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