Échéance de niveau d’API

Échéance de niveau d’API : Date après laquelle une application qui ne vise pas le palier requis cesse d’être proposée aux nouveaux utilisateurs.

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.

À quoi sert Échéance de niveau d’API

Échéance de niveau d’API 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.

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.

Comment l’écrire dans un cahier des charges

Écrire « Échéance de niveau d’API » dans un cahier des charges suppose d’avoir lu les règles en vigueur des deux boutiques. Elles ne disent pas la même chose et changent plusieurs fois par an.

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

Rien n’oblige à tout figer dès le premier jour. Ce qui reste ouvert doit alors être signalé comme tel, avec la date à laquelle la décision sera prise.

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

Échéance de niveau d’API se recette avec les règles des boutiques sous les yeux, dans leur version en vigueur ce mois-là.

• Relire la fiche produit dans chaque langue publiée, sur un vrai téléphone.
• Vérifier que le compte développeur est au nom du client avant la première soumission.
• Dérouler le parcours de suppression de compte, exigé par les deux boutiques.

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.

Erreurs fréquentes

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• 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.
• Confier la décision au prestataire, puis la contester au moment de la recette.

Termes liés

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

• Achat de test
• ASO
• TestFlight
• Partage familial App Store
• Notifications temps réel Play

Questions fréquentes

Échéance de niveau d’API : de quoi parle-t-on exactement ?

Date après laquelle une application qui ne vise pas le palier requis cesse d’être proposée aux nouveaux utilisateurs. 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.

Qui doit s’en occuper, l’agence ou le client ?

Le cahier des charges tranche. En pratique, l’agence prépare et soumet, le client valide et détient les comptes. Ce partage s’écrit avant la signature, pas la veille de la mise en ligne.

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.