Comment fonctionne l'agent de soumission : du dépôt à la revue du store

Publier est la partie du développement d'apps que la plupart des gens repoussent. Le build est terminé, et il reste le bundle ID, la question du chiffrement à l'export, le questionnaire de classification par âge, la page de politique de confidentialité que vous n'avez pas, les tailles de captures d'écran et le numéro de build qui doit être supérieur au précédent. L'agent de soumission existe pour faire cette partie. Voici ce qu'il fait réellement, étape par étape, et où il s'arrête pour vous attendre.

La version courte : il lit votre dépôt, prépare la fiche du store, vérifie la version contre ce pour quoi les stores rejettent des apps, construit votre build ou le récupère, l'envoie et s'arrête. Une première sortie n'est jamais soumise à la revue sans votre validation. Une mise à jour peut aller directement en revue, mais seulement si vous avez choisi ce chemin et approuvé la fiche.

Ce que vous connectez une fois

Trois connexions font le travail, et vous les configurez une fois par app.

GitHub. Uprate lit le dépôt via l'API GitHub pour détecter l'app et l'analyser. Il ne clone pas votre code, n'affiche pas votre source dans son interface et n'ouvre pas de pull request dessus, à une exception près expliquée plus bas.

Une clé de store pour publier. Pour l'App Store, vous ajoutez dans les réglages une clé API App Store Connect, distincte de celle qui lit les avis. Uprate la valide en listant les apps qu'elle peut atteindre, la stocke chiffrée et vous montre quelles apps cette clé peut publier. Pour Google Play, vous connectez un compte de service pour le package, la même connexion que celle utilisée par la boîte de réception des avis. Si vous construisez avec Expo, vous connectez aussi le compte Expo propriétaire du projet.

Qui peut appuyer sur le bouton. Dans une équipe, les propriétaires et les membres peuvent lancer une soumission. Les sièges relecteur et analytique peuvent ouvrir le processus et lire chaque étape, mais pas le démarrer, le soumettre ni l'annuler.

Ajouter l'app

Vous choisissez un dépôt et Uprate y cherche l'app : package.json, app.json ou app.config, l'Info.plist iOS et le projet Xcode, le build.gradle Android et le manifeste. Il en déduit le nom de l'app, le bundle ID iOS, le package Android et le projet Expo, et dans un monorepo il demande dans quel dossier vit l'app. Vous pouvez corriger tout ce qu'il a mal détecté avant que l'app soit créée.

iOS et Android sont des voies séparées. Apple peut approuver pendant que Google demande davantage, donc chaque store a son propre processus, avec son statut et ses actions, et une app qui n'a qu'un bundle iOS n'affiche qu'une voie. Il n'y a qu'une soumission en cours par store et par app ; si l'une est ouverte, le bouton de lancement vous y conduit au lieu d'en démarrer une seconde.

Où doit-il s'arrêter

Chaque lancement commence par une question, et la réponse décide jusqu'où le processus va de lui-même.

Plan	Ce qui se passe	Où il attend
Tester d'abord (par défaut)	Prépare la fiche, exécute les vérifications, construit ou récupère votre build et l'envoie sur TestFlight ou sur les tests internes de Google Play. Rien n'atteint App Review.	Sur « Ready to submit », jusqu'à ce que vous appuyiez sur soumettre.
Passer en production	Pareil, puis continue vers la revue du store. Pour une première sortie, vous validez d'abord les informations préparées ; pour une mise à jour, la fiche vous est montrée avant d'être écrite.	Nulle part après le build, sauf si une vérification échoue.
Vérifier seulement (App Store)	Parcourt chaque étape et rapporte ce qu'une vraie sortie ferait. Rien n'est construit et rien ne change chez Apple.	Se termine par « Check complete ».

La seconde question est d'où vient le build. Avec Build with Expo, Uprate construit depuis votre dépôt. Avec Upload IPA ou Upload AAB, vous glissez un build signé issu de vos propres outils ; Uprate le valide, y lit la version et le numéro de build, et envoie celui d'iOS avec Transporter d'Apple. Avec Use ASC build ou Use Google Play build, vous choisissez un build déjà traité dans la console du store, le chemin de ceux qui envoient depuis Xcode ou leur propre CI.

Une réserve sur Android : les builds depuis le dépôt ont besoin d'un runner isolé, et ce runner ne fait pas partie du produit hébergé. Les processus Android utilisent donc aujourd'hui un AAB ou un APK envoyé par vous, ou un build déjà présent sur Google Play.

Ce que produit l'analyse pour une première sortie

Une première sortie est le cas où l'app n'existe pas encore dans le store, et c'est là que se passe l'essentiel de l'analyse. Uprate lit une tranche bornée du dépôt, app.json, package.json, le README et une poignée d'extraits de source, et y passe huit analyseurs.

Le texte de la fiche revient sous la forme d'un nom et d'un sous-titre dans les 30 caractères d'Apple, d'une description courte pour Google Play, d'une description sous 4 000 caractères, de mots-clés sous 100 caractères, d'un texte promotionnel et des URL de support et de marketing qu'il a trouvées. Les catégories et le questionnaire de classification par âge sont remplis à partir de ce que fait l'app. La question du chiffrement à l'export est tranchée depuis le code, avec les preuves utilisées. Les étiquettes de confidentialité sont proposées à partir des dépendances et des API que le code appelle, là encore avec chemins de fichiers et extraits comme preuves. Une politique de confidentialité et des conditions d'utilisation sont générées et hébergées sur une page publique Uprate, parce que le store exige une URL et que la plupart des premières apps n'en ont pas. Enfin, un audit ASO lit l'ensemble et liste les problèmes en critique, majeur, mineur ou information, et il signale le jargon technique dans les textes destinés aux utilisateurs, pour que « construit avec React Native et TypeScript » ne finisse pas dans une description.

Tout ce que l'analyse a produit est modifiable dans le processus, par langue, et reste une suggestion tant que vous ne l'avez pas approuvé.

Les mises à jour sautent presque tout cela. La fiche est reprise de ce qui est en ligne dans le store, la réponse sur le chiffrement à l'export est recalculée depuis le code parce qu'Apple la demande à chaque build, l'analyse de confidentialité tourne quand même pour vous donner une suggestion fondée sur le code à comparer avec vos étiquettes actuelles, et le texte « Nouveautés » est rédigé à partir des commits depuis la dernière sortie.

Les vérifications avant de construire quoi que ce soit

Avant qu'un build démarre, le processus passe une liste de contrôle contre le store et le dépôt. Elle confirme que la configuration Expo et eas.json existent et sont valides, que le propriétaire Expo correspond à votre compte, que la version de l'app et le numéro de build sont supérieurs à ce qu'App Store Connect a déjà, que le bundle ID de la configuration correspond au store, que la réponse sur le chiffrement, la classification par âge et la catégorie principale sont renseignées, que l'URL de la politique de confidentialité est publique et se charge vraiment, et que les tailles de captures exigées par le store sont couvertes. Chaque point en échec tient en une phrase avec le champ à corriger, et vous pouvez relancer l'étape après correction.

Une seconde passe lit le dépôt à la recherche de ce pour quoi App Review renvoie des apps : des textes de permission manquants pour l'appareil photo, les photos, la localisation, les contacts ou le micro, une permission de suivi absente sur des apps qui semblent suivre, une connexion tierce sans Sign in with Apple, des comptes sans moyen de les supprimer dans l'app, des métadonnées d'achats intégrés, et du contenu généré par les utilisateurs sans signalement ni modération.

La troisième passe est la vérification App Review. Elle prend les preuves des passes précédentes et les métadonnées préparées, et les confronte à un ensemble de 26 règles des App Review Guidelines d'Apple, sélectionnées à la main. Le résultat est une liste de constats, chacun un risque ou un point d'attention, chacun citant la preuve sur laquelle il repose et la règle à laquelle il correspond. Les règles qu'elle n'a pas pu vérifier sont listées comme non vérifiées plutôt que devinées. Cette vérification ne bloque jamais une soumission à elle seule et n'annonce jamais une probabilité de rejet.

Des problèmes, pas des scores Uprate n'affiche ni pourcentage de préparation ni score de risque. Il affiche des comptes de problèmes, chacun avec le champ et le correctif. Quand une étape échoue, « Copy fix prompt » produit un prompt avec le diagnostic et les références de fichiers pour votre propre agent de code. Uprate n'écrit pas de code dans votre dépôt.

Écrire dans le store, et la pause

Une fois la fiche approuvée, le processus l'écrit dans le store via son API : la version, les textes de la fiche dans chaque langue, les catégories, la classification par âge et le jeu de captures que vous avez attaché. Le prix et la disponibilité sont vérifiés et fixés avant la soumission en revue. Si l'app n'existe pas encore dans App Store Connect, le bundle ID est enregistré et la fiche de l'app est créée d'abord. Une chose n'est pas écrite : les étiquettes de confidentialité d'Apple n'ont pas d'API publique, donc Uprate montre sa suggestion et vous demande de confirmer que vous les avez remplies dans App Store Connect avant qu'une première sortie aille plus loin. Pendant qu'un processus écrit, construit ou est en revue, l'éditeur de fiche de cette app est verrouillé pour que les deux ne se marchent pas dessus.

Avec Build with Expo sur iOS, Uprate ouvre une seule pull request sur votre dépôt qui ajoute un fichier de workflow sous .eas/workflows/. Vous la fusionnez, et à partir de là Uprate déclenche ce workflow via la GitHub App d'Expo pour un commit précis. Le workflow construit le binaire de production et le soumet à App Store Connect en passant par le service d'identifiants d'Expo, si bien qu'aucune clé App Store Connect n'atterrit dans les secrets de votre dépôt. C'est le seul endroit où Uprate touche votre dépôt, et c'est un fichier de workflow, pas votre source.

Le build est envoyé sur TestFlight ou en tests internes. Dans le plan par défaut, le processus se gare alors sur « Ready to submit ». Vous installez le build, vous l'essayez et vous appuyez sur soumettre quand vous êtes satisfait. Avec « Passer en production », le processus continue vers la revue. Sur Google Play, un compte encore soumis à l'exigence de test fermé de Google atterrit plutôt sur « Live on internal testing », et le processus continue de surveiller et passe de lui-même à approuvé une fois la sortie de production en ligne.

En revue, et après

Uprate interroge le statut de la revue et montre le processus en une ligne par phase, avec le détail de chaque événement derrière un bouton. Approuvé est approuvé. Un rejet est affiché avec les détails d'état d'Apple traduits en langage clair, plus un renvoi vers Review Issues & Messages dans App Store Connect, parce que le message complet sur la règle n'est pas exposé par l'API. Corrigez l'app ou la fiche et appuyez sur resoumettre, avec une note si vous voulez consigner ce qui a changé.

Une étape en échec n'est pas un processus en échec. Le processus vous dit quelle étape a échoué et propose de reprendre à partir de là ou de réessayer. Vous pouvez aussi annuler un processus, y compris un qui est déjà dans la file d'Apple, où Uprate retire la soumission en revue pour vous.

Ce que ça coûte

L'agent de soumission est disponible dans toutes les formules, y compris la gratuite. L'analyse du dépôt pour une première sortie est une action à 5 crédits pour l'ensemble des analyseurs, l'audit ASO en coûte 5 de plus, et un prompt de correction 2. Les builds tournent sur votre compte Expo ou viennent de vous, ils ne sont donc pas comptés en crédits Uprate.

Où ça se situe

L'agent de soumission est la deuxième chose à mettre en place après avoir connecté les stores. Ce dont il vous protège est décrit dans Combien de temps prend la revue App Store et dans les guides sur les rejets de ce blog, et la façon dont il s'articule avec la boîte de réception des avis et les brouillons de fiche est dans Gérer les opérations de store sans recruter quelqu'un pour l'ops.