Sideloading

Sideloading : Installation d’une application en dehors d’une boutique officielle, encadrée par les règles et les protections du système.

Le mot appartient à la famille « Stores et publication » du lexique. Cette page dit ce qu’il recouvre, comment il se formule dans un cahier des charges, et ce qu’il vaut mieux ne pas écrire.

Pourquoi Sideloading compte sur un projet mobile

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

Dans la pratique, deux interlocuteurs qui n’ont pas la même définition en tête avancent d’accord pendant des semaines, puis découvrent le désaccord à la livraison.

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

Le cahier des charges doit dire qui prend en charge « Sideloading » : 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 :

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

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.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Vérifier plutôt que croire

Sideloading se recette avec les règles des boutiques sous les yeux, dans leur version en vigueur ce mois-là.

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

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.

• 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

Qu’est-ce que « Sideloading » ?

Installation d’une application en dehors d’une boutique officielle, encadrée par les règles et les protections du système. 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.

Apple et Google appliquent-ils les mêmes règles ?

Non. Chaque boutique a ses exigences, ses délais et ses motifs de rejet. Un projet qui ne prévoit qu’un seul jeu de contraintes découvre l’autre au moment le plus coûteux.

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.