Le kit de fiche : des pages boutique écrites à partir de votre code

Les chiffres d'abord : une fiche moyenne nécessite

• des captures d'écran à quatre ou cinq tailles de pixels différentes par store
• une icône déclinée en plus de huit dimensions
• une liste de permissions qui peut dépasser une douzaine d'entrées pour tout ce qui touche aux contacts ou à la localisation
• un questionnaire de confidentialité avec des dizaines de branches oui/non qui détermine si un évaluateur rejette votre appli dès le premier jour

Multipliez cela par trois stores — Play, l'App Store, la fiche d'extension de Firefox si vous publiez une extension — et vous voilà avec trois après-midi de recadrage de captures d'écran et de remplissage de formulaires pour une appli déjà terminée. Ça, c'est le chiffre ennuyeux.

Chaque build destiné à un store reçoit un kit de fiche produit, généré automatiquement, conçu pour combler cet écart précis — celui entre ce qu'un développeur veut que son appli fasse et ce que le binaire compilé fait réellement.

Le reste du kit, c'est la partie facile

• Les captures d'écran proviennent de l'application en cours d'exécution, pas de maquettes — composées, dimensionnées selon les specs de chaque store, sous-titrées lorsque le format l'exige.
• Les icônes sont exportées dans toute la famille de tailles requise par chaque store, ainsi que les visuels promotionnels ou graphiques de mise en avant exigés en plus.
• Le texte de fiche — titre, description courte, description complète — est rédigé à partir de ce que l'application fait réellement, ce qui paraît évident jusqu'à ce qu'on ait lu suffisamment de fiches App Store qui ne sont qu'un empilement d'adjectifs.
• Les justifications de permissions sont générées permission par permission, dans le format attendu par chaque store.

Rien de tout cela n'est vraiment difficile. C'est juste assez fastidieux pour que les gens le sautent, ou le fassent vite et mal.

Là où c'est strict : le questionnaire de confidentialité

Voici la partie facile à mal faire, même avec de bonnes intentions. Vous construisez une appli, vous êtes plutôt sûr qu'elle ne collecte rien, vous cochez « aucune donnée collectée » sur le questionnaire et vous passez à autre chose. Sauf que vous avez intégré un SDK de rapport de plantage il y a trois semaines et que vous l'avez oublié, ou qu'un appel analytique s'est glissé via une mise à jour de dépendance. Maintenant votre fiche dit une chose et votre binaire en fait une autre — ce qui est soit un mensonge involontaire à vos utilisateurs, soit un moyen rapide d'être signalé en révision, et ni l'un ni l'autre n'est un bon résultat.

Le kit ne vous croit donc pas sur parole. Il scanne le code source réel de l'application avant de répondre : une déclaration « ne collecte aucune donnée » n'est faite que lorsque le code n'effectue aucun appel réseau et n'intègre aucun outil d'analyse. Si l'application communique effectivement avec un serveur, la déclaration le dit — avec précision, que ce soit flatteur ou non. Nous préférons une fiche honnête plutôt qu'indulgente envers elle-même. Ce n'est d'ailleurs pas un hasard si c'est aussi la version qui passe la révision, car les évaluateurs vérifient exactement ce que le scan vérifie.

Remplie, pas seulement déposée

Lorsqu'un store expose une API, le kit publie la fiche directement, sans intervention humaine. Lorsqu'un store impose sa propre console, le kit automatise le remplissage des formulaires et ne vous laisse que la poignée de clics réservée à un humain par le store.

Le détail complet par store se trouve dans From prompt to app store.