Un refus de l’App Store exige une réponse adaptée au problème cité. Commencez par le message de l’App Review et vérifiez ce qui a échoué. Les consignes actuelles d’Apple permettent de répondre après une correction portant sur les informations, les métadonnées ou l’accès côté serveur. Une correction du code du build envoyé nécessite un nouveau build. Si vous contestez la décision, clarifiez-la avant de faire appel.
Un nouvel envoi immédiat peut relancer un travail que vous auriez pu résoudre dans la conversation.
Nous commençons par rapprocher le message de l’app envoyée et par consigner ce que la personne chargée de la vérification pouvait voir. Vous obtenez ainsi une tâche concrète à examiner avec le développeur, même si vous ne pouvez pas modifier le code vous-même.
Que dit réellement votre refus de l’App Store ?
Lisez le statut et l’élément concerné avant de choisir une correction. La référence d’Apple sur les statuts distingue une soumission en attente de vérification d’une app refusée ou d’informations de fiche refusées. Une soumission peut comprendre plusieurs éléments. Notez celui qui présente le problème, la règle citée et l’explication de la personne chargée de la vérification. Une ancienne pastille de refus ne fournit pas à elle seule assez d’informations pour agir.
Les métadonnées désignent les informations de la fiche, comme les descriptions et les captures d’écran, qui se trouvent hors du paquet exécutable de l’app. Un build est la version empaquetée envoyée pour vérification. Les App Review Guidelines d’Apple traitent l’exhaustivité, l’exactitude des métadonnées et les fonctionnalités suffisantes de l’app comme des exigences distinctes. Une description plus claire ne peut pas réparer un plantage, tandis qu’une fonctionnalité opérationnelle peut tout de même nécessiter de meilleures informations pour la vérification.
Tenez une fiche de tâche comprenant les champs suivants : élément concerné, règle, problème observé, correction proposée, preuve, personne responsable et prochaine action. Reprenez le problème réellement soulevé par la personne chargée de la vérification. Indiquez qu’un champ est inconnu lorsque le message ne l’explique pas, puis posez une question ciblée.
Trouvez le problème que la personne chargée de la vérification a pu reproduire
Testez la version envoyée en partant du point décrit dans le message. Il est possible que votre compte habituel dispose déjà d’un accès ou ait terminé une configuration qui manque à la personne chargée de la vérification. Les consignes de préparation d’Apple demandent des identifiants de démonstration opérationnels et les informations nécessaires pour accéder aux fonctionnalités de l’app. Vérifiez le parcours complet avant de demander une nouvelle version au développeur.
- Faites correspondre la version et l’environnement. Demandez au développeur quel build a été envoyé, et sur quel appareil et système d’exploitation les tests ont été effectués. L’aide d’Apple sur les tests d’appareils demande de tester sur des appareils physiques, y compris dans les modes de compatibilité pertinents. Consignez tout ce que vous ne pouvez pas reproduire sur les appareils dont vous disposez.
- Essayez le compte de vérification après une nouvelle connexion. Suivez les étapes fournies jusqu’à la fonctionnalité signalée. Vérifiez les rôles du compte et les éventuelles instructions relatives aux codes d’authentification. L’aide d’Apple sur la préparation d’une vérification complète demande de fournir ces informations à l’avance. Les identifiants doivent rester utilisables lorsque la vérification commence.
- Lisez la fiche à côté de l’app. Comparez les captures d’écran et la description avec ce que fait réellement ce build. Si le refus concerne un message d’autorisation, les consignes d’Apple sur les textes d’utilisation exigent une explication concrète de la manière dont l’app utilise la ressource demandée.
- Vérifiez le comportement cité en matière de confidentialité. Pour un problème de suppression de compte, testez le parcours réel. Les consignes d’Apple exigent que les apps permettant de créer un compte proposent de lancer sa suppression depuis l’app. Une simple désactivation ne suffit pas. Les obligations de conservation et les exceptions applicables aux apps réglementées doivent faire l’objet d’une vérification distincte.
Utilisez un compte de test avec des données d’exemple sans risque. Un enregistrement ou une pièce jointe doit montrer le parcours qui échoue ou qui a été corrigé, sans exposer de dossiers client ni d’identifiants.
Répondre, envoyer un nouveau build ou faire appel ?
Choisissez la voie à suivre une fois que vous savez ce qui a changé. L’aide d’Apple sur le statut de vérification distingue les corrections qui peuvent être expliquées dans une réponse des modifications qui nécessitent une nouvelle vérification. Le tableau aide à décider face à un refus existant. Un avis de retrait ou une mesure touchant un compte nécessite sa propre procédure.
| Situation | Prochaine action prise en charge |
|---|---|
| Informations manquantes, métadonnées corrigées ou correction de l’accès côté serveur | Corriger le problème et répondre dans App Store Connect |
| Un défaut du build envoyé a été corrigé | Importer le build modifié et l’envoyer pour une nouvelle vérification |
| Vous estimez que la décision applique mal la règle citée | Clarifier dans la conversation, puis faire appel si le désaccord persiste |
Apple avertit qu’un nouvel envoi lance une nouvelle vérification et met fin aux réponses au message précédent. Un nouvel envoi pendant un appel clôt cet appel. Consultez la personne qui gère la conversation avant de modifier la soumission.
Une offre explicite de Bug Fix Submission constitue un cas distinct. L’aide d’Apple la limite aux mises à jour éligibles d’apps déjà approuvées, lorsqu’il n’existe aucun problème juridique ou de sécurité. L’acceptation se fait par une réponse, avec l’engagement de corriger les problèmes lors de la prochaine mise à jour. Lisez l’offre avant d’emprunter la voie habituelle du nouveau build.
Préparez ensemble la correction et les preuves
Associez à chaque problème une correction et un moyen de la vérifier. Nous conservons la tâche du développeur et la réponse destinée à la personne chargée de la vérification dans la même fiche, afin qu’une modification de l’app se retrouve dans les informations envoyées avec elle. Commencez par les contrôles que vous pouvez effectuer vous-même, puis confiez les modifications de code au développeur.
- Supprimez les lacunes d’accès et d’information. Conformément à l’aide d’Apple sur la préparation d’une vérification complète, mettez à jour les notes destinées à l’App Review avec l’objectif de l’app, les fonctionnalités modifiées, les services externes et, le cas échéant, les différences régionales. Testez de nouveau les identifiants après les avoir modifiés.
- Vérifiez le site web associé. Ouvrez sur un téléphone les URL d’assistance et de confidentialité indiquées dans votre soumission. Comparez la destination et la formulation à l’app en cours de vérification. Ce contrôle de cohérence peut faire partie du développement du site web lorsqu’un site accompagne une app.
- Demandez une correction technique démontrable. Pour un problème de build, demandez au développeur de montrer le parcours signalé après la correction et d’identifier le build qui la contient. Cette transmission fait partie du développement et de la publication d’applications mobiles, avec la préparation de la vérification.
- Envoyez une réponse ciblée. Les instructions d’Apple pour répondre passent par le lien des problèmes non résolus de l’app, puis par In Progress, Resolve et Reply to App Review. Un accès Account Holder, Admin ou App Manager est requis. Expliquez le problème, indiquez où trouver la correction et comment la tester. Joignez des preuves pertinentes si elles sont utiles, puis choisissez Reply.
- Faites appel si le désaccord persiste. L’aide d’Apple sur les appels vous demande d’abord de clarifier la situation, puis de répondre avec des preuves aux exigences citées. Incluez dans l’appel toutes les infractions concernant cette app. Une demande d’état d’avancement ou de vérification plus rapide doit être adressée ailleurs.
Ne placez pas de mots de passe Apple personnels dans la fiche de tâche. Gardez le compte développeur sous le contrôle de l’entreprise et utilisez un accès adapté au travail de chaque personne.
Comment savoir si le problème est résolu ?
Distinguez une correction que vous avez testée de la décision d’Apple. Reproduisez exactement le même parcours après la modification et conservez le résultat, la version du build ou des informations, ainsi que la réponse envoyée. Consultez ensuite le statut actuel dans App Store Connect. La réussite d’un test local ne renseigne que sur ce test. Apple reste décisionnaire pour la soumission.
Suivez, pour chaque problème cité, la présence de preuves, le fonctionnement persistant de l’accès pour la vérification et la répétition éventuelle du même problème dans un message ultérieur. Si cela se produit, comparez le nouveau message à votre fiche avant d’apporter une autre modification. Une fois l’app publiée, obtenir des téléchargements pour l’app constitue un travail distinct.
Notre intervention
Nous partons du message de refus, de la version envoyée et d’un parcours reproductible dans l’app. Nous pouvons ensuite distinguer les corrections de la fiche et du site web des travaux de développement, puis préparer les informations destinées à la personne chargée de la vérification. Remettez ces éléments à la personne responsable de la publication, en signalant les questions non résolues, avant d’accepter un autre build.
