La première soumission à la boutique doit avoir lieu plusieurs semaines avant le lancement, et non le jour où le développement est terminé. Non pas parce que l’examen est lent, mais parce que le travail lié au compte et aux métadonnées est systématiquement sous-estimé.
La configuration du compte prend plus de temps que l’examen
Avant toute soumission, un compte développeur doit exister. Pour un compte d’entreprise, cela nécessite généralement des documents d’immatriculation de l’entreprise et une étape de vérification qui prend de quelques jours à quelques semaines, selon la juridiction et la rapidité avec laquelle les documents concordent.
Les retards sont banals et prévisibles : un nom d’entreprise qui ne correspond pas exactement à celui figurant sur l’immatriculation, un format d’adresse que la vérification n’accepte pas, ou un type d’entité juridique nécessitant des justificatifs supplémentaires. Rien n’est difficile ; tout prend du temps calendaire.
Cette démarche doit commencer au début du projet, et non à la fin. Il s’agit de la cause la plus fréquente d’un report de la date de lancement pour des raisons sans rapport avec le développement.
Les rejets qui se répètent
La plupart des rejets lors d’une première soumission relèvent d’un petit nombre de catégories :
- Informations incomplètes pour l’examen. Si l’application nécessite une connexion, des identifiants de test fonctionnels doivent être fournis. Les examinateurs qui ne peuvent pas accéder à l’application rejettent la soumission. Lorsqu’un flux nécessite des données spécifiques ou un état particulier de l’appareil, cela doit être expliqué.
- Plantages ou bugs évidents. Les examinateurs utilisent l’application et la rejettent en cas de plantage.
- Déclarations de confidentialité absentes ou incohérentes. Une politique de confidentialité est requise, doit être accessible à une URL active et doit correspondre aux données réellement collectées par l’application. Déclarer qu’aucune donnée n’est collectée tout en demandant des autorisations d’accès aux contacts constitue une incohérence que les examinateurs vérifient.
- Autorisations demandées sans finalité évidente. La demande d’accès à la localisation, à l’appareil photo ou aux contacts exige une justification que l’examinateur juge plausible, et le texte explicatif dans l’application doit être précis plutôt que générique.
- Contenu d’attente. Lorem ipsum, écrans vides, boutons non fonctionnels, sections « bientôt disponible ». Une fiche de boutique est destinée à un produit terminé.
- Gestion des paiements non conforme aux règles de la plateforme. Les règles concernant les éléments qui doivent utiliser le mécanisme de paiement propre à la plateforme sont précises et strictement appliquées. Une erreur à ce niveau peut nécessiter la refonte d’un flux essentiel.
- Incohérences dans les métadonnées. Captures d’écran présentant des fonctionnalités absentes, descriptions promettant des fonctions qui n’existent pas.
Chacun de ces problèmes peut être évité avant la soumission, et une vérification préalable basée sur cette liste prend une heure.
Les métadonnées constituent une tâche à part entière
La fiche nécessite, pour chaque plateforme et chaque langue :
- Le nom et le sous-titre de l’application, dans les limites de caractères.
- La description, généralement en versions courte et longue.
- Les mots-clés, lorsque la plateforme les utilise.
- Des captures d’écran aux dimensions requises pour plusieurs catégories d’appareils.
- Une icône dans plusieurs résolutions.
- La catégorie, la classification d’âge et les déclarations relatives au contenu.
- Les URL d’assistance et de politique de confidentialité, toutes deux actives.
Les captures d’écran aux dimensions précises des appareils sont l’élément qui provoque le plus souvent une course contre la montre, car elles nécessitent une version fonctionnelle sur ces appareils. Leur production correcte prend une journée, et la précipiter donne une fiche qui sous-évalue le produit.
Délais d’examen
L’examen est généralement terminé en un ou deux jours sur les principales plateformes, mais les délais varient et s’allongent autour des périodes de vacances. Prévoyez plusieurs jours et au moins un rejet lors d’une première soumission — c’est normal plutôt qu’un échec, et une nouvelle soumission après correction est généralement plus rapide.
Ne planifiez pas d’événement de lancement pour le lendemain de la soumission. Soumettez l’application, obtenez l’approbation, puis différez sa mise en ligne jusqu’à ce que vous soyez prêt — les deux principales plateformes permettent d’approuver une version et de la publier ultérieurement, ce qui élimine entièrement le risque lié au calendrier.
Après la première publication
Les mises à jour sont elles aussi soumises à examen. Pour tout élément urgent — comme un correctif pour un bug grave — prévoyez un délai d’un ou deux jours pour l’examen plutôt que de supposer une publication immédiate.
Notez également que les utilisateurs ne mettent pas tous leur application à jour. Une proportion significative reste longtemps sur d’anciennes versions, ce qui signifie que les modifications côté serveur doivent rester compatibles avec les versions encore utilisées, et qu’il est utile de décider rapidement combien de temps vous les prendrez en charge.
Services Manboo associés
- Développement d’applications Flutter pour les MVP iOS et Android.
- Développement de logiciels métier pour les CRM, systèmes de réservation, de gestion des stocks et de gestion des flux de travail.
- Développement de panneaux d’administration pour les tableaux de bord opérationnels et la gestion backend.
- Intégration d’API d’IA lorsque votre produit est prêt pour la recherche intelligente, le chat ou l’automatisation.
- Demander un examen du périmètre et une estimation du projet lorsque vous êtes prêt à planifier la première version.