1. Ce que demande la Guideline 1.5

Dans ses App Review Guidelines, Apple classe la règle 1.5 dans la section Safety sous le titre Developer Information. Les utilisateurs doivent pouvoir contacter le développeur pour leurs questions et problèmes de support. L’application et son URL de support doivent donc offrir un moyen de contact facile, exact et à jour.

Une page vide, une erreur, une redirection incohérente, une adresse absente ou une localisation qui pointe vers la mauvaise URL peuvent suffire à créer un problème. La qualité du code principal n’est alors pas le sujet de la décision.

2. Le cas rencontré avec BeSafe

BeSafe a reçu un refus lié à la Guideline 1.5 parce qu’une URL de support ou de confidentialité renseignée dans App Store Connect ne fonctionnait pas correctement dans une ou plusieurs localisations. Le parcours a été simple une fois la cause comprise : refus, page corrigée, nouvelle soumission, validation.

L’enseignement important est que la fiche App Store fait partie du produit soumis. Le reviewer ne distingue pas ton interface, tes pages publiques et tes métadonnées comme trois projets séparés : tout doit former un parcours accessible et cohérent.

3. Diagnostiquer avant de modifier

Relis le message de review mot par mot et identifie la règle, l’écran, la localisation et l’URL mentionnés. Reproduis ensuite le contrôle dans une fenêtre privée, sur mobile et sans session administrateur. Vérifie le statut HTTPS, les redirections et la présence d’un contact réellement utilisable.

Dans App Store Connect, passe en revue toutes les localisations actives. Une URL correcte dans la langue principale ne garantit pas que les autres champs reprennent automatiquement cette valeur.

  • URL de support et politique de confidentialité accessibles publiquement.
  • Adresse email ou autre moyen de contact visible et fonctionnel.
  • Aucun écran protégé par une connexion pour lire les informations essentielles.
  • Même identité et mêmes informations entre l’app, le site et la fiche.

4. Corriger la cause minimale et la vérifier

Corrige l’élément signalé, puis répète exactement le parcours du reviewer. Évite d’ajouter simultanément des modifications fonctionnelles sans rapport : elles compliquent la vérification et peuvent introduire une nouvelle raison de refus.

Si la correction concerne uniquement une page publique ou une métadonnée modifiable dans App Store Connect, vérifie si un nouveau binaire est réellement nécessaire. La réponse dépend de l’élément en cause, pas d’un automatisme.

5. Répondre clairement dans App Store Connect

Réponds dans le fil de review avec trois informations : ce qui causait le problème, ce qui a été corrigé et où le reviewer peut vérifier. Une réponse factuelle réduit l’ambiguïté. Il n’est pas nécessaire de raconter tout l’historique du projet ni de contester la règle lorsque le problème est reproductible.

Apple prévoit aussi une procédure d’appel lorsqu’une décision paraît incorrecte. Avant cette étape, une question précise ou une information complémentaire dans App Store Connect peut suffire à clarifier le contrôle.

6. Transformer le refus en checklist permanente

Ajoute un contrôle des liens publics et des localisations à chaque soumission et mise à jour importante. Vérifie aussi les coordonnées de contact, les comptes de démonstration et les notes de review.

Le but n’est pas de garantir qu’Apple ne refusera jamais une version. Il est de supprimer les erreurs évitables et de disposer d’un processus rapide lorsque la review révèle un angle mort réel.