Publier une application mobile sur le Play Store et l’App Store c’est facile ! (…ou pas)

Ce sujet est souvent complètement ignoré par les porteurs de projets d’application. Pourtant, tous les efforts d’un projet peuvent être réduits à néant si l’application est refusée par les plateformes. Voyons pourquoi être accompagné dès le début évite retards, refus, mauvaises surprises et pertes colossales d’argent.

Lorsqu’on discute d’un projet d’application mobile et plus particulièrement de sa mise en production souhaitée “sur les stores”, au début la majorité de nos clients pensent que “ça doit être comme pour un site internet, on appuie sur un bouton et c’est en ligne !”
En réalité, publier une application sur l’App Store d’Apple ou le Play Store de Google est presque un projet à part entière. Il y a des conditions et contraintes très strictes imposées par les éditeurs et personne ne peut y échapper !

Heureusement avec près de 15 ans d’expérience dans le domaine, Nartex a l’habitude de travailler avec les règles imposées par Apple et Google. Nous faisons même en sorte de veiller à ce sujet dès la phase de conception pour que ça ne soit pas un problème.

Les règles des stores : des centaines de pages de contraintes… et des interprétations variables

Les deux stores ont des réglementations strictes qui se sont construites au fil des ans. Elles sont dictées bien évidemment par le bon vouloir des éditeurs, mais aussi par les évolutions légales et la technologie. Si au début des années 2010 les règles étaient encore limitées (tout comme les applications et leur diffusion), elles se sont étoffé lorsque l’usage du smartphone a pris de l’ampleur.

Apple App Store Review Guidelines (un document de +200 pages)

Google Play Developer Policies

Ce sont de vraies lois internes et une application peut être refusée pour des détails parfois, disons très “ponctuels”.

Exemples:
– L’application d’un de nos clients est 100% fonctionnelle et éligible aux stores, elle est soumise aux stores mais lors de la review (les tests faits par Apple et Google) une page web hébergée par le client avec ses CGV (conditions générales de vente) est inaccessible depuis le lien “CGV” intégré à l’application: l’app est refusée.
– Une application métier a été soumise à l’App Store mais s’est vue refusé la publication car le texte accompagnant le message de demande d’utilisation du micro du téléphone n’était pas suffisamment explicite.

Et ne croyez pas que seule l’application en elle même est concernée. Si dans la fiche store de l’application, vous classifiez mal l’âge requis pour utiliser votre app ou que vous prenez trop d’aise avec le contenu descriptif (exemple: “mon appli intègre une IA” alors qu’il s’agit de simples filtres) alors votre app sera refusée… ou éjectée du store si la découverte se fait après la publication de l’app.

Apple et Google n’ont pas les mêmes exigences

Bien entendu, les règles que l’on pourrait qualifier de “logiques” ou généralistes sont identiques, comme par exemple:
– L’application ne doit pas contenir de contenu choquant, offensant ou discriminatoire (par ex. violence gratuite, propos haineux).
– L’application doit être stable, fonctionnelle, sans bugs évidents, et livrée complètement (pas de contenu placeholder).

Mais il n’existe pas de “règle commune”.
Une application peut être validée sur Android et totalement refusée sur iOS, ou l’inverse.

Prenons le cas d’une appli e-commerce intégrant un formulaire de paiement via un site externe.
Chez Google, l’appli est autorisée à partir du moment où le procédé est sécurisé.
Du côté d’Apple, le refus est catégorique car le paiement doit suivre les règles Apple et passer obligatoirement par l’in-app purchase (achats inapp soumis à la commission Apple).

Si un professionnel découvre ce point au moment de passer son projet en production, c’est tout le business model qui est à revoir et le projet prendra du retard…

Les tests : votre application doit fonctionner parfaitement sur des dizaines d’appareils

Sur Android, il existe des milliers de modèles de smartphones, tablettes… issus de plusieurs constructeurs. Réaliser une application qui fonctionnera sur 100% des modèles du marché est presque mission impossible, surtout si vous visez des version d’OS (système Android) qui sont obsolètes.
Sur iOS, “seulement” quelques gammes et un nombre d’OS restreint, mais Apple vérifie tout : comportement en mode sombre, permissions mal demandées, lenteur au lancement, absence de texte d’explications dans certaines boîtes de dialogue, réaction spécifique sur un modèle précis d’iPad…

Les délais de validation : non, ça ne sera pas “en production” aujourd’hui…

Une fois votre application prête, testée et validée par vous, le moment est venu de la soumettre (le terme est important) à Apple et Google. Vous êtes connecté sur vos comptes “Developer”, que vous avez préalablement créé et complétés car oui, cette partie là aussi peut prendre plusieurs jours de part les vérifications et sécurités nécessaires. Ensuite vous déposez le code de votre application qui va être passé en revue par Apple et Google.
Si tout va bien, les délais sont limités:
– Google Play : entre 24 h et 48h, rarement d’avantage
– App Store : entre 24 h et… parfois plusieurs jours

En cas de refus ou de suspicion de non-conformité : délai prolongé, échange humain, parfois appel téléphonique avec Apple.

Vous comprendrez l’importance de prendre ces éléments en considération avant de vous engager sur des dates !

Autre chose: après la première publication, chaque mise à jour doit de nouveau être validée, même si c’est pour changer la couleur d’un bouton.

Les stores peuvent refuser les applications trop « web »

Ces dernières années, on assiste à un “grand nettoyage” des Stores: Apple et Google veulent des applications utiles et qualitatives sur leurs Stores, ils suppriment donc toutes les applications qui ne parviennent pas à justifier leur “usage mobile” ou qui ont une mission que l’on qualifiera de “douteuse”. Si on souhaite prendre un raccourci, on peut dire que toute appli qui peut être remplacée par un site internet, sera refusée sans détour.

Apple, particulièrement, refuse régulièrement :
– les apps qui ne font qu’afficher un site web
– les apps “shell” sans vraie valeur ajoutée
– les apps trop proches d’une PWA
– les apps avec un contenu uniquement externe

Confiez votre projet à Nartex et gagnez en sérénité

Publier une application n’est pas automatique : c’est un processus réglementé, parfois long, et souvent étonnamment exigeant.

Les stores, et c’est bien normal, veulent protéger :
– la sécurité des utilisateurs
– l’expérience utilisateur
– la cohérence des apps publiées
– leur propre écosystème

Pour vous, cela signifie qu’un projet mobile nécessite bien plus qu’un “simple développement”.

Comment Nartex sécurise votre projet dès le début ?

Chez Nartex, on ne se contente pas de “développer l’app”, on intègre les règles des stores dès la conception, ce qui évite les refus, les retards, les fonctionnalités à refaire, les mauvaises surprises budgétaires…

Nous proposons pour cela:
– une veille permanente des règles Apple & Google
– des conseils et avis dès la phase de conception
– des tests exhaustifs multi-appareils
– des parcours utilisateurs conformes
– des API adaptées aux impératifs mobiles
– un accompagnement jusqu’à la publication validée

La réussite d’un projet mobile dépend autant de l’expertise technique que de la connaissance profonde des stores, de leurs contraintes, et de leurs pratiques parfois imprévisibles.

Chez Nartex, notre rôle est de vous éviter ces pièges pour que votre application soit complète, conforme, performante
… et publiée.