targetSdkVersion

targetSdkVersion : Version d’Android pour laquelle l’application déclare être conçue, réglage qui détermine les comportements imposés par le système.

Famille « Développement ». La définition ci-dessus suffit pour suivre une réunion. La suite sert à écrire une exigence que personne ne pourra interpréter à sa façon.

À quoi sert targetSdkVersion

targetSdkVersion fait partie des notions invisibles à l’usage et bien réelles dans la facture. Ce point décide de la facilité avec laquelle une équipe reprendra le code dans deux ans, avec d’autres développeurs.

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

La traduction en exigences

Le cahier des charges gagne à formuler « targetSdkVersion » en résultat attendu plutôt qu’en solution : ce que l’application doit savoir faire, à quel moment, et comment on le vérifiera à la recette.

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

• Les versions minimales d’iOS et d’Android supportées, qui décident des API disponibles.
• Le sort du code : dépôt remis, licences des bibliothèques, cession des droits à la livraison.
• Les bibliothèques tierces autorisées, et qui paie leurs licences dans la durée.
• La procédure de mise à jour de l’application une fois qu’elle est publiée.

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, targetSdkVersion se contrôle avec les mêmes gestes à chaque version. Ce sont ces gestes qu’il faut écrire une fois pour toutes.

• Lancer l’application sur un appareil ancien, pas seulement sur le dernier modèle.
• Contrôler la liste des bibliothèques tierces et le régime de leurs licences.
• Suivre soi-même, une fois, la documentation d’installation remise.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

Les pièges à éviter

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

• Imposer une technologie dans le cahier des charges sans écrire le besoin qu’elle sert.
• Accepter un devis où le développement iOS et le développement Android tiennent dans une seule ligne.
• Repousser les tests automatisés à la fin du projet, c’est-à-dire ne jamais les écrire.
• Changer de socle technique en cours de route sans rechiffrer le reste du planning.
• Se contenter d’une réponse orale en réunion, jamais reprise dans le document contractuel.

Termes liés

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

• ObservableObject
• Modifier
• encapsulation
• test instrumenté
• MainActor

Questions fréquentes

Qu’est-ce que « targetSdkVersion » ?

Version d’Android pour laquelle l’application déclare être conçue, réglage qui détermine les comportements imposés par le système. 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.

Comment vérifier qu’une agence maîtrise le sujet ?

Demandez un exemple tiré d’un projet livré, pas une définition. L’écart entre les deux réponses se voit en trente secondes, et il est plus parlant qu’une liste de technologies sur un site vitrine.

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.