Google Play n'est pas disponible sur les appareils de Chine continentale, et les services Google sur lesquels s'appuie d'ordinaire une application Android construite en Europe ne le sont pas davantage. La conséquence n'est pas que la distribution Android est difficile en Chine ; c'est qu'elle est une autre activité. Les utilisateurs prennent les applications dans les boutiques opérées par le fabricant de leur téléphone, ou dans de grandes boutiques de plateforme, et chacune est une relation commerciale distincte avec son propre jeu de documents à produire. Une équipe qui avait budgété un dépôt en trouve plusieurs, et une équipe qui avait budgété une mise à jour trouve la même chose.
Il n'y a pas une boutique, il y en a plusieurs
Les boutiques qui comptent se répartissent en deux familles. La première est celle des constructeurs : la boutique préinstallée sur le téléphone, là où la plupart des utilisateurs de cette marque prennent leurs applications, avec l'avantage d'être présente par défaut et l'inconvénient de ne toucher que les utilisateurs de cette marque. La seconde est celle des plateformes, qui ne sont pas liées à un appareil et touchent plusieurs marques. La boutique d'Apple existe en Chine continentale comme une vitrine distincte, avec son propre examen et ses propres obligations de dépôt, ce qui rend iOS plus simple dans sa structure et pas dans sa substance.
Le choix pratique n'est ni « toutes » ni une seule. C'est de regarder quels appareils portent réellement vos utilisateurs — question à laquelle, pour une application B2B, vous répondez en interrogeant une douzaine d'entre eux — et de publier dans les deux ou trois boutiques qui couvrent l'essentiel de cette population, puis d'en ajouter si l'application se révèle importante. Chaque boutique supplémentaire coûte un dépôt, un cycle d'examen et, pour toujours ensuite, une place dans la routine de mise à jour.
| Boutiques de constructeurs | Boutiques de plateformes | |
|---|---|---|
| Qui elles touchent | Les utilisateurs de cette marque d'appareil, sur la boutique déjà présente dans le téléphone | Des utilisateurs de plusieurs marques, qui sont allés chercher une boutique au lieu d'utiliser celle par défaut |
| Ce qu'elles demandent | Une identité d'entreprise vérifiée, les justificatifs habituels de propriété du logiciel, et la conformité aux règles techniques propres au constructeur | À peu près les mêmes documents, avec des critères d'examen et des règles de contenu qui diffèrent dans le détail d'une boutique à l'autre |
| Ce qu'elles coûtent dans la durée | Une file d'examen par constructeur, et des comportements spécifiques à tester sur les appareils de cette marque | Une autre file d'examen, et un deuxième jeu de fiches et de captures à tenir à jour |
Ce qu'une boutique demande avant de publier
Les documents varient dans le détail d'une boutique à l'autre et ils changent : traitez ce qui suit comme la forme de l'exigence plutôt que comme une liste sur laquelle s'appuyer, et confirmez la liste en vigueur auprès de chaque boutique avant d'arrêter une date. La forme est constante : une boutique veut savoir quelle société immatriculée publie, que cette société détient le logiciel, et que l'application respecte les règles applicables à sa catégorie.
Trois choses en découlent, et ce sont celles qui surprennent les équipes européennes. D'abord, publier suppose normalement une entité chinoise, parce que l'identité qu'une boutique vérifie est une immatriculation d'entreprise locale ; une application peut parfois être publiée sous l'entité d'un partenaire, ce qui est un arrangement réel et aussi un arrangement qui place votre fiche, vos avis et vos utilisateurs sous le nom de quelqu'un d'autre. Ensuite, les boutiques demandent la preuve que le logiciel est le vôtre, ce qui signifie ordinairement en Chine un enregistrement de droit d'auteur sur le logiciel — un dépôt avec son propre délai, à lancer bien avant la date de publication souhaitée. Enfin, tout ce à quoi l'application se connecte et qui est hébergé en Chine relève du dépôt d'hébergement applicable aux services locaux, et toute application traitant des données personnelles doit pouvoir dire ce qu'elle collecte et pourquoi, dans la forme que les règles locales exigent. Certaines catégories — les jeux, et tout ce qui est financier ou médical — supportent des autorisations supplémentaires qui sont un projet à elles seules ; si vous êtes dans l'une d'elles, apprenez-le avant tout le reste, car cela détermine tout le calendrier.
La signature, et la mise à jour que vous ferez plusieurs fois
Un paquet Android est signé, et la clé de signature est l'identité de l'application telle que toutes les boutiques et tous les appareils la comprennent. Perdez-la et vous ne pouvez plus mettre à jour ce que vous avez publié ; laissez-la détenir par un tiers et lui peut le faire. Décidez où vit cette clé et qui peut s'en servir avant le premier dépôt, et gardez l'arrangement écrit ailleurs que dans la mémoire d'une personne. Là où une boutique propose de gérer la signature pour vous, comprenez ce que cela implique pour le paquet que reçoivent les utilisateurs et pour votre capacité à publier la même application ailleurs.
La mise à jour est la partie que personne ne prévoit correctement. Une nouvelle version doit être déposée séparément dans chaque boutique, chacune examine à son propre rythme, et elles ne terminent pas ensemble. Pendant quelques jours ou plus, vos utilisateurs font donc tourner des versions différentes selon la boutique d'où ils viennent, avec une conséquence pratique : tout ce qui, de votre côté, dialogue avec l'application doit tolérer la version précédente aussi longtemps qu'un examen peut durer. Les équipes habituées à une boutique unique livrent une rupture en supposant que tout le monde a mis à jour en même temps, et l'apprennent par ceux dont la boutique était la plus lente.
Quand le mini-programme remplace l'application
Avant tout cela, la question qui vaut d'être posée est de savoir si une application native est ce dont vous avez besoin. Un mini-programme WeChat ne demande ni boutique, ni fiche, ni installation ; il se trouve dans une application que l'utilisateur a déjà, il s'ouvre depuis un message, un code ou une recherche, il hérite d'une identité et d'un moyen de paiement, et vous le mettez à jour en un seul endroit. Pour un catalogue, un formulaire de commande, un configurateur, une bibliothèque de documentation, un outil de réservation ou un portail de service, ce n'est pas un compromis — c'est le meilleur instrument, et le fait qu'il n'y ait rien à installer en est l'essentiel de la raison.
Une application native mérite son coût quand elle a besoin de ce que le mini-programme ne donne pas : du travail en arrière-plan prolongé, un accès profond à l'appareil, du calcul local lourd, un fonctionnement sans réseau, une liaison à un matériel particulier, ou une interface qui doit être sur l'écran d'accueil parce qu'elle sert toute la journée. Ce sont des cas réels et ils sont plus rares qu'ils n'en ont l'air dans un cahier des charges. Si vous n'êtes pas clairement dans l'un d'eux, le mini-programme vaut d'être construit d'abord, et il vous dit si l'application que l'on réclamait aurait été utilisée.
Ce qui casse quand une application européenne est simplement recompilée
- Tout ce qui repose sur les services Google. Notifications poussées, cartes, connexion, localisation, remontée de plantages, facturation de la boutique : cela ne fait pas partie d'Android, c'est une couche absente des appareils que portent vos utilisateurs. Chacun demande un remplaçant local, et la notification poussée en demande un par constructeur.
- Tout ce qui est chargé depuis l'étranger. Polices, scripts, mesure d'audience, images sur un réseau de diffusion étranger, carte intégrée, lecteur vidéo : chacun est une requête qui peut être lente ou ne pas aboutir, et un écran qui attend tout le monde n'apparaît jamais.
- La connexion et le paiement. Un compte créé avec une adresse e-mail et un mot de passe, payé avec une carte étrangère, décrit un utilisateur qui n'existe pas ici. Attendez un numéro de téléphone comme identité et un moyen de paiement local comme seule option, et traitez les deux comme une partie du produit plutôt que comme des intégrations.
- Les autorisations et les déclarations de confidentialité. Les règles locales comme l'examen des boutiques regardent de près ce qu'une application demande et si elle en a besoin. Une autorisation réclamée au lancement « pour améliorer l'expérience » est un refus dans plusieurs boutiques et un problème dans toutes.
- Le parc d'appareils. Formes d'écran, versions système, modifications d'Android par les constructeurs et gestion agressive de la batterie varient plus que la gamme européenne sur laquelle l'application a été testée. Le travail en arrière-plan en particulier se comporte autrement, et autrement selon la marque.
Pris ensemble, ce n'est pas un portage mais une version. La façon honnête de la planifier est de traiter la sortie chinoise comme un produit à part, avec ses appareils de test, sa conception de l'identité et du paiement, et son calendrier de livraison — et de commencer par décider, ce coût sous les yeux, si un mini-programme n'aurait pas fait l'affaire.
Tranchez la question de l'entité avant toute question technique. Quelle société immatriculée publie décide des boutiques accessibles, du nom qui figure sur la fiche, du détenteur de la clé de signature et du propriétaire des utilisateurs — et c'est la décision la plus douloureuse à défaire une fois qu'une application a été téléchargée sous le nom de quelqu'un d'autre.