Publier sur l’App Store : ce qui bloque vraiment

Une application terminée n’est pas une application publiée, et c’est le moment du projet où l’écart entre les deux se paie le plus cher : l’équipe a fini, le client attend, et il reste un dossier que personne n’a préparé.

La bonne nouvelle est que rien de tout cela n’est imprévisible. Les motifs de refus sont publics, stables d’une année sur l’autre, et se règlent presque tous avant d’écrire la première ligne de code — à condition de savoir qu’ils existent.

Un examinateur installe l’application et l’utilise, sur un vrai appareil, pendant quelques minutes. Il ne lit pas le code, il ne mesure pas les performances, il ne juge pas le design. Il vérifie trois choses.

• Que l’application fonctionne entièrement, sans écran vide, sans fonction annoncée qui ne répond pas, sans dépendance à un serveur de test. Une application livrée avec une section « bientôt disponible » est incomplète au sens du règlement.
• Qu’il puisse aller partout. Si l’accès demande un compte, il lui faut des identifiants de démonstration valides, fournis dans le formulaire de soumission. Un examinateur bloqué sur un écran de connexion ne cherche pas : il refuse.
• Que ce que la fiche promet corresponde à ce que l’application fait. C’est particulièrement surveillé sur tout ce qui touche à la santé, même animale : une fiche qui annonce un diagnostic là où l’application signale un risque est un refus assuré. Une formulation commerciale un peu large suffit à faire repartir le dossier.

Quatre motifs reviennent constamment, et tous les quatre sont des décisions de produit, pas des bugs.

L’application n’apporte rien de plus qu’un site

C’est le refus le plus brutal, parce qu’il ne se corrige pas en une journée. Une application qui se contente d’afficher un site web dans une fenêtre est refusée : Apple considère qu’elle n’a pas sa place dans un magasin d’applications. Si votre projet ne prévoit ni notifications, ni fonctionnement hors connexion, ni usage d’un capteur du téléphone, la question à se poser n’est pas comment passer l’examen mais si l’application est le bon support.

On peut créer un compte, pas le supprimer

Toute application qui permet de créer un compte doit permettre de le supprimer, depuis l’application elle-même, sans passer par un e-mail au support. La règle date de 2022 et ne souffre aucune exception. C’est trois jours de développement si on y pense au cadrage, une semaine de retard si on le découvre au refus.

La déclaration de confidentialité ne correspond pas

Chaque fiche déclare les données collectées, leur usage, et si elles sont rattachées à l’identité de l’utilisateur. Cette déclaration doit couvrir aussi ce que collectent les briques intégrées — mesure d’audience, outil de plantage, service d’abonnement. Une déclaration qui oublie un outil tiers est fausse, et se voit.

Le paiement contourne le magasin

Un contenu numérique consommé dans l’application se paie par le système d’Apple, commission comprise. Rediriger l’utilisateur vers un paiement extérieur pour l’éviter est le refus le plus certain qui soit. En revanche, un bien physique ou une prestation réalisée hors de l’application — une livraison, un rendez-vous — n’entre pas dans ce cadre.

Aucun de ces quatre motifs ne se découvre en testant l’application. Tous se décident au cadrage, et tous coûtent une à deux semaines quand on les découvre au refus.

Google a longtemps eu la réputation d’être le magasin facile. Ce n’est plus vrai, et le piège est ailleurs : il ne bloque pas à l’examen, il bloque avant.

• Un compte développeur personnel créé récemment doit d’abord passer par une phase de test fermé : une douzaine de testeurs inscrits, actifs pendant deux semaines consécutives, avant même de pouvoir demander l’accès à la production. Sur un projet où l’application est prête, c’est un mois de calendrier qui apparaît de nulle part.
• Un compte d’entreprise demande une vérification d’identité de la société, avec un identifiant d’entreprise reconnu. La démarche est gratuite mais prend des jours, parfois plus.
• Le formulaire de sécurité des données joue le même rôle que la déclaration d’Apple, mais avec ses propres catégories. Il se remplit à part, jamais en recopiant celle d’Apple.

Voici ce qu’il faut avoir sous la main le jour de la soumission. Rien n’est difficile ; tout prend du temps, et tout tombe au moment où l’équipe pensait avoir fini.

• Les comptes développeur, au nom du client. Jamais au nom du prestataire : une application publiée sur le compte de son développeur est une application dont le client ne dispose pas.
• Une politique de confidentialité en ligne, à une adresse publique et stable, cohérente avec ce que l’application collecte réellement.
• Les captures d’écran aux formats demandés, pour chaque taille d’appareil visée. Les formats changent avec les gammes : ce sont des visuels à refaire, pas à archiver.
• L’icône, la description, les mots-clés, la catégorie et la classification d’âge, dans chaque langue publiée. Une fiche traduite à moitié est une fiche qui convertit à moitié.
• Un compte de démonstration, et une note à l’examinateur expliquant en trois lignes ce que fait l’application et comment y accéder.
• Le statut de professionnel déclaré et vérifié, exigé pour être distribué dans l’Union européenne. Sans lui, l’application ne paraît pas en France.

Ajoutez-y une contrainte qui ne se voit pas : l’application doit être construite avec une version récente du kit de développement d’Apple. Ce plancher est relevé chaque année, et il vaut aussi pour les mises à jour — c’est l’une des raisons pour lesquelles une application qu’on ne touche plus cesse d’être publiable en deux ou trois ans.

Un refus n’est pas un verdict, c’est un message dans une messagerie, avec un numéro de règle et souvent une capture d’écran. La réponse compte autant que la correction.

• Lisez le numéro de règle cité, pas seulement le texte. Il renvoie à un paragraphe précis du règlement, qui dit exactement ce qui est attendu.
• Répondez dans le fil, avant de renvoyer une version. Si le refus repose sur un malentendu — une fonction que l’examinateur n’a pas trouvée, un usage qu’il n’a pas compris — l’expliquer coûte quelques heures ; renvoyer un binaire coûte un cycle complet.
• Ne corrigez qu’une chose à la fois si le motif est discutable. Une soumission qui change dix éléments après un refus ambigu s’expose à un deuxième refus sur un autre point.

Et prévoyez le calendrier en conséquence : ne promettez jamais une date de mise en ligne au public tant que l’application n’est pas acceptée. Une campagne annoncée sur une application encore en examen est la seule erreur de cette liste qui se voie de l’extérieur.

Publier n’est pas la dernière ligne du développement. C’est une étape du projet, avec sa durée propre, ses dépendances administratives, et son risque de refus.

Equio, VetSafe et Ellyo sont publiées sur les deux magasins et suivies depuis. Si vous avez une application en préparation et que vous voulez savoir ce que sa publication demandera — dossier, comptes, délais, points de refus probables — décrivez-la en quelques lignes : je vous réponds sous 48 heures.