Ce que tu peux modifier sans nouvelle version d'app : Apple vs Google
Avant de toucher à une fiche store, une question mérite d'être posée : cette modification va-t-elle te coûter une soumission complète, ou peut-elle sortir discrètement ? Se tromper, c'est soit attendre dans une file de revue que tu n'avais pas prévue, soit croire qu'un changement est en ligne alors qu'il attend encore d'être approuvé. Les deux stores répondent à cette question de façon opposée, et c'est toute la raison pour laquelle synchroniser des fiches entre les deux est pénible.
Voici la version honnête, champ par champ — en commençant par le tableau, puis le raisonnement derrière les règles de chaque store pour anticiper les cas que ce tableau ne détaille pas.
Le tableau
Chaque champ de fiche courant, et ce que chaque store exige quand tu le modifies. « Nouvelle version / release » signifie que le store traite la modification comme faisant partie d'une soumission que tu dois envoyer ; « vérifié » signifie qu'un contrôle humain ou automatisé s'exécute avant la mise en ligne.
| Icône de l'app | L'icône principale est intégrée au binaire — la changer nécessite un nouveau build. Vérifiée avec ce build. | L'icône du store est un asset de fiche. Pas de nouvelle release. Vérifiée. |
Deux choses ressortent. Apple fait passer presque tout par un enregistrement de version. Google laisse toute la fiche évoluer seule. Aucun des deux stores ne saute la revue sur les éléments qui comptent — le mot « vérifié » apparaît dans presque chaque case. La vraie question est donc rarement « est-ce que ça va être vérifié », mais « est-ce que cette modification entraîne une soumission avec elle ».
Apple : un nouvel enregistrement de version n'est pas la même chose qu'un nouveau build
C'est la distinction qui piège tout le monde. Sur l'App Store, modifier tes captures d'écran, ton nom, ton sous-titre, ton champ de mots-clés ou ta description crée une nouvelle version de ta fiche. Cela pourrait laisser penser que tu dois retourner sur Xcode. Ce n'est pas le cas. Apple reporte automatiquement tes métadonnées actuelles vers la nouvelle version, et une modification purement de métadonnées ne nécessite aucun nouveau code d'app — tu attaches un build (App Store Connect en exige quand même un sur la version) sans rien changer au fonctionnement de l'app. Tu modifies les champs mis en file, tu soumets, et un seul cycle de revue couvre tout.
Donc « pas de nouveau code, mais quand même vérifié » est la bonne façon de le retenir. Pas d'étape de compilation ni de nouvelles fonctionnalités — mais la modification entre quand même en App Review et attend son tour avant d'être publique. Groupe tes changements : puisqu'un seul enregistrement de version peut contenir de nouvelles captures d'écran, une description réécrite, un sous-titre revu et des mots-clés mis à jour en même temps, aucune raison de consommer un cycle de revue séparé pour chacun.
L'icône de l'app est l'exception qui nécessite bien un build. Ton icône principale est intégrée au binaire et en est extraite, donc une icône réellement nouvelle signifie un nouveau build. C'est aussi vrai pour les icônes alternatives — elles doivent être incluses dans l'app pour être utilisables, donc en ajouter une est un build, pas une modification de fiche.
Les deux échappatoires d'Apple
Le texte promotionnel. C'est le seul champ modifiable sans version et sans revue. Il fait 170 caractères, se place au-dessus de la description, et se met à jour quand tu veux — pratique pour une promotion, une annonce de lancement, ou un texte lié au moment. Il n'affecte pas le classement dans les recherches et ne fait partie d'aucune soumission, ce qui explique pourquoi c'est l'élément le plus rapide à modifier sur le store. Si tu dois publier quelque chose aujourd'hui même, c'est ce champ qui le permet.
La Product Page Optimization. La PPO te permet de tester jusqu'à trois variantes de tes captures d'écran, App Preview et icône contre ta page produit en direct — sans livrer de nouvelle version d'app. C'est ce qu'Apple propose de plus proche d'une modification visuelle en dehors d'une soumission classique. Deux réserves à garder à l'esprit : les métadonnées de la variante doivent quand même être approuvées avant que le test ne démarre (donc c'est vérifié, pas instantané), et toute icône que tu veux tester doit déjà faire partie du binaire actuel de l'app. La PPO change ce que voient les visiteurs ; elle ne saute pas la revue.
Google Play : publier la fiche sans release
Play fonctionne dans l'autre sens. Ta fiche store — titre, description courte, description complète, captures d'écran, feature graphic, icône, vidéo promo — est modifiable et publiable seule, sans nouvelle release d'app associée. Tu fais les modifications, elles apparaissent dans l'aperçu de publication sous les changements prêts à envoyer en revue. Tu les envoies, elles passent par la revue de Google, et elles sont mises en ligne indépendamment de tout build.
Quelques points à garder précis pour ne pas exagérer. Les changements sont quand même vérifiés — la revue de Play s'applique aussi aux modifications de fiche, et des éléments comme le nom de l'app et l'icône sont contrôlés, donc ce n'est pas un remplacement instantané et silencieux. Et la fiche ne peut pas exister indépendamment d'une app déjà publiée : Play exige que l'app ait eu une release préalable pour qu'il y ait une fiche publique à modifier. Tu ne peux pas pousser une page store autonome pour quelque chose qui n'a jamais été publié. La publication managée ajoute une subtilité à connaître — si elle est activée, les changements approuvés attendent que tu les publies activement, ce qui est une fonctionnalité, pas un retard, une fois que tu t'y attends.
L'asymétrie, et pourquoi elle te coûte du temps
Aligne les deux modèles et le clivage est net. Apple lie presque toute modification de texte et d'image à un enregistrement de version et à une passe de revue, le texte promotionnel et la PPO étant les seuls moyens d'y échapper. Google découple entièrement la fiche de la release, vérifie les modifications, et les publie selon son propre calendrier tant que l'app existe déjà.
Cette asymétrie coûte cher discrètement quand tu gères les deux stores. Le même renouvellement de captures d'écran est une soumission d'enregistrement de version sur un store et une mise à jour de fiche autonome sur l'autre. Une réécriture de description est une version vérifiée sur Apple et une modification de fiche vérifiée sur Google. Le contenu est identique ; la mécanique ne l'est pas, donc un changement qui est une seule action sur Play devient une action différente sur l'App Store — et il est facile de publier l'un et d'oublier l'autre, ou de croire que quelque chose est en ligne sur Apple alors que c'est encore en revue.
Où Mokbi s'intègre
Cette asymétrie entre stores est exactement ce qui justifie l'existence d'un outil de publication. Mokbi a commencé comme un éditeur de captures d'écran, mais une fiche est du texte et des images ensemble — il conçoit donc le jeu de captures d'écran et rédige le texte de la fiche pour les deux stores en un seul endroit : nom, sous-titre, champ de mots-clés et description pour l'App Store ; titre, description courte et description complète pour Play. Tu obtiens les champs que chaque store indexe réellement, adaptés à ce store, au lieu d'un seul bloc de texte que tu colles deux fois.
Ensuite, il traduit toute la fiche — captures d'écran et texte — en 50 langues, pour qu'un changement fait une seule fois se retrouve dans le bon champ sur chaque marché plutôt que de rester en anglais dans une fiche localisée partout ailleurs. Et il publie : Mokbi pousse la fiche finalisée directement vers Google Play via l'API Play Developer, et la prépare dans App Store Connect prête à soumettre — Apple exige toujours le Submit final et le passage en revue de son côté, ce qui est une règle d'Apple et exactement l'asymétrie entre stores dont traite tout cet article. Cette dernière revue est aussi le moment où les délais évoqués dans cet article commencent à courir.