Supposons une application de prise de commande terminée côté code le 20 du mois, avec un lancement annoncé au réseau commercial pour le 1er. Le build compile, la recette interne est passée, le solde du développement est facturé. Mais le compte développeur Apple de l’entreprise n’existe pas encore, personne n’a demandé de numéro D-U-N-S, et la politique de confidentialité n’est pas écrite. Le lancement n’aura pas lieu le 1er, et le retard n’aura rien à voir avec la qualité du code.
C’est la situation la plus courante en fin de projet mobile. Les budgets et les choix de technologie sont documentés partout, y compris dans notre guide des prix du développement d’applications mobiles au Maroc. Le dernier kilomètre, lui, passe pour une formalité : on « met l’app sur les stores ». En réalité, c’est une procédure administrative et de conformité, avec ses pièces à fournir, ses vérifications d’identité, ses files d’attente de revue et ses motifs de refus.
Deux semaines entre « le code est prêt » et « l’app est téléchargeable » constituent un planning optimiste pour une première publication. Quatre à six semaines sont plus réalistes si les comptes développeur doivent encore être créés.
Pourquoi la publication est l’étape la plus sous-estimée du planning
Trois causes se cumulent. D’abord, un cahier des charges décrit des fonctionnalités, presque jamais une procédure de mise en ligne : il n’y a donc ni ligne « soumission » dans le planning, ni responsable désigné. Ensuite, une partie des délais ne dépend ni de vous ni de votre prestataire. Apple et Google examinent l’application quand ils l’examinent, et un refus renvoie l’envoi dans la file.
Enfin, les tâches administratives s’enchaînent en série et non en parallèle. Obtenir un numéro D-U-N-S, puis faire valider l’inscription de l’entité, puis confirmer l’adresse, puis seulement créer la fiche de l’application : chaque étape attend la précédente. Trois jours perdus au début se retrouvent intégralement à la fin.
Les comptes développeur : qui doit les détenir
Le compte développeur appartient à l’entreprise qui exploite l’application, pas à l’agence qui la développe. Cela paraît évident et c’est pourtant l’erreur la plus coûteuse : une app publiée sous le compte personnel d’un développeur devient difficile à récupérer le jour où la relation s’arrête, et un transfert d’application entre comptes a ses propres conditions. Faites créer les comptes au nom de la société, avec une adresse e-mail générique que vous contrôlez, pas celle d’un salarié qui peut partir.
Côté Apple, l’Apple Developer Program coûte 99 USD par an. Une inscription en tant qu’organisation exige un numéro D-U-N-S attribué par Dun & Bradstreet, gratuit, mais dont l’obtention peut prendre plusieurs jours ouvrés. La raison sociale et l’adresse doivent correspondre exactement à celles de votre immatriculation. C’est précisément là que la création d’un compte développeur Apple au Maroc se bloque : un nom commercial utilisé au quotidien mais différent du registre de commerce suffit à faire échouer la vérification. Apple demande aussi que la personne qui s’inscrit ait l’autorité légale d’engager la société.
Côté Google, le compte Play Console se paie une seule fois, 25 USD. Les vérifications d’identité et d’adresse se sont durcies, et un compte de type « particulier » créé récemment doit en principe passer par une phase de test fermé auprès d’un petit groupe de testeurs pendant deux semaines avant de pouvoir demander l’accès à la production. Pour une PME, le compte au nom de la société évite ce détour. Prévoyez également le moyen de paiement : ces frais sont en devises et demandent une carte bancaire internationale, ce qui n’est pas toujours immédiat dans une structure où la carte dort dans le bureau du gérant.
Mentions obligatoires, données personnelles et loi 09-08
Les deux stores exigent une URL de politique de confidentialité accessible publiquement avant la soumission. Un lien mort, une page en construction ou un copier-coller de la politique du site web, qui ne parle ni de l’application, ni de ses permissions, ni de ses SDK, sont des motifs de rejet classiques et parfaitement évitables.
Le point sensible est la cohérence. Apple vous fait déclarer, catégorie de donnée par catégorie de donnée, ce que l’application collecte. Google demande la même chose dans le formulaire « Sécurité des données ». Ces déclarations doivent correspondre à ce que le code fait réellement, SDK tiers compris. Firebase Analytics, Crashlytics, une régie publicitaire ou un outil de support intégré collectent des identifiants et des données d’usage même si votre équipe n’y a jamais pensé. Demandez à votre prestataire la liste exacte des SDK embarqués dans le build avant de remplir quoi que ce soit.
S’ajoute le volet marocain. Une politique de confidentialité d’application CNDP indique la finalité du traitement, les données collectées, la durée de conservation, les droits d’accès, de rectification et d’opposition, le contact du responsable de traitement, et le cas des transferts hors du Maroc, ce qui concerne de fait toute app dont le back-end tourne sur un cloud étranger. La loi 09-08 impose une déclaration préalable du traitement, et le numéro de récépissé se cite dans la politique. Le détail de la procédure est dans notre checklist de conformité CNDP et loi 09-08 ; vérifiez la version en vigueur des formulaires sur le site de la CNDP avant de déposer. Dernier détail souvent oublié : si l’application permet de créer un compte, elle doit aussi permettre de le supprimer, et les deux stores y regardent désormais.
Délais de revue réels et motifs de rejet, store par store
App Store
Apple annonce que la grande majorité des envois est examinée en moins de 24 heures. C’est souvent vrai pour une mise à jour mineure. Pour une première publication, comptez plus large, surtout si des achats intégrés sont validés en même temps. Les refus tournent presque toujours autour des mêmes points : application incomplète ou inutilisable par le relecteur (guideline 2.1), typiquement un écran de connexion sans compte de démonstration fourni ; collecte de données excessive ou inscription imposée pour des fonctions qui n’en ont pas besoin (5.1.1) ; fonctionnalité jugée minimale, cas du site web simplement encapsulé (4.2) ; absence de « Se connecter avec Apple » alors que l’app propose déjà une connexion via un réseau social (4.8) ; contenu numérique payé en dehors de l’achat intégré (3.1.1). Viennent ensuite les rejets de métadonnées : captures d’écran non conformes, mention d’Android dans la fiche iOS, URL de support qui ne répond pas.
Un rejet app store au Maroc n’a donc presque jamais de cause locale. Ce sont les mêmes règles que partout, appliquées par un relecteur qui dispose de quelques minutes et du téléphone qu’il a sous la main.
Google Play
Le délai de validation Play est plus variable : quelques heures pour certaines mises à jour, plusieurs jours pour un premier envoi, parfois davantage quand le compte est récent ou quand l’application demande des permissions sensibles. Les blocages typiques concernent les permissions à justifier (localisation en arrière-plan, SMS, journal d’appels, accès à la liste des applications installées), un formulaire de sécurité des données incomplet ou contredit par le code, un niveau d’API cible inférieur au minimum exigé pour l’année en cours, ou une catégorie réglementée comme la finance, le crédit ou la santé, qui demande des justificatifs supplémentaires. Relisez le niveau d’API cible attendu dans la console avant de compiler la version finale : ce refus est purement mécanique et il tombe toujours au mauvais moment.
Achats intégrés et paiement : ce qui se complique au Maroc
La règle de base est simple à énoncer : un contenu ou un service numérique consommé dans l’application (abonnement, crédits, déblocage de fonctions) passe par l’achat intégré du store, avec la commission correspondante. Un bien physique, une prestation réalisée hors de l’app ou une commande payée à la livraison peuvent utiliser une autre solution, par exemple une passerelle CMI. La frontière n’est pas toujours intuitive, et cet arbitrage se fait au moment du cahier des charges, pas la veille de la soumission, parce qu’il touche directement au modèle économique.
Avant de vous engager sur un abonnement, deux vérifications concrètes : la devise et les grilles de prix disponibles pour le Maroc dans App Store Connect et dans la Play Console, puis les conditions de versement des revenus (coordonnées bancaires acceptées, formulaires fiscaux, encaissement en devises). Parlez-en à votre banque et, si les montants sont significatifs, à votre comptable, avant d’afficher un prix dans l’application.
Checklist : publier application mobile Maroc sans retard
À préparer en parallèle des dernières semaines de développement, pas après :
- Comptes développeur Apple et Google au nom de la société, D-U-N-S obtenu, adresse e-mail générique, carte bancaire internationale disponible.
- Identité de l’éditeur cohérente partout : raison sociale, adresse, téléphone de contact, URL de support qui fonctionne réellement.
- Politique de confidentialité en ligne, propre à l’application, conforme à la loi 09-08, avec le numéro de déclaration CNDP.
- Liste des SDK tiers fournie par l’équipe technique, pour remplir les déclarations de collecte sans se contredire.
- Compte de démonstration valide et sans expiration, accompagné des notes au relecteur : comment atteindre les écrans protégés, quel code utiliser si l’inscription passe par SMS.
- Visuels aux formats exigés au moment de l’envoi, icône incluse, captures sans texte provisoire ni données clients réelles.
- Fiche store dans la langue de vos utilisateurs, classification d’âge remplie, catégorie choisie, description sans promesse qui n’existe pas dans l’app.
- Build signé, numéros de version et de build cohérents, traces de debug retirées, test sur un appareil récent et sur un appareil de trois ou quatre ans.
- Suppression de compte accessible depuis l’application, et par un lien web si vous publiez sur Play.
- Un responsable nommé côté entreprise, qui a les accès aux deux consoles et peut répondre à un relecteur dans la journée.
En cas de rejet : corriger sans perdre deux semaines
Un refus n’est pas une sanction, c’est un ticket. Le temps perdu vient presque toujours de la réaction, rarement de la décision. Commencez par lire le numéro de guideline cité et la capture jointe, puis classez le problème : build, métadonnées ou interprétation. Un rejet de métadonnées se corrige sans recompiler, ce qui change complètement l’impact sur le planning.
Si le motif repose sur un malentendu, une fonction que le relecteur n’a pas trouvée ou une contrainte réglementaire mal comprise, répondez dans le centre de résolution d’App Store Connect avec une explication courte, des captures et le chemin exact pour reproduire. C’est souvent plus rapide qu’un nouvel envoi et la discussion reste attachée au même dossier. Quand la lecture de la règle est réellement contestable, une procédure de recours existe ; gardez-la pour les vrais désaccords. Côté Play, corrigez la déclaration ou la permission en cause, documentez son usage dans l’app, et utilisez le formulaire de contestation si la décision vous paraît erronée.
Les réflexes qui coûtent cher : resoumettre à l’identique en espérant tomber sur un autre relecteur, répondre trois jours plus tard, ou laisser prestataire et client s’attendre mutuellement sans que personne ne tranche. Une réponse envoyée le jour même se résout fréquemment en 24 à 48 heures. Une semaine de silence coûte une semaine de lancement.
Questions fréquentes
Combien coûte la publication sur les deux stores ?
Les frais de compte sont de 99 USD par an pour l’Apple Developer Program et de 25 USD une seule fois pour la Play Console. Le reste du coût est du temps : rédaction juridique, visuels, déclarations de collecte, allers-retours de revue. C’est marginal face au budget de développement, mais ce n’est pas zéro, et cela ne couvre ni l’hébergement du back-end ni la maintenance.
Peut-on publier une application sans société au Maroc ?
Oui, un compte individuel est possible sur les deux stores. Deux conséquences : votre nom personnel peut apparaître comme éditeur sur la fiche, et un compte Play de type particulier créé récemment doit passer par la phase de test fermé avant d’accéder à la production. Pour une activité commerciale, le compte au nom de la société est plus simple à transmettre et plus crédible côté utilisateurs.
Combien de temps faut-il entre la soumission et la mise en ligne ?
Avec des comptes déjà vérifiés et un dossier complet, quelques jours suffisent souvent sur les deux stores. Avec des comptes à créer, un D-U-N-S à obtenir et une politique de confidentialité à écrire, raisonnez en semaines. Chaque rejet ajoute le temps de correction plus un nouveau passage en revue.
Faut-il déclarer l’application à la CNDP ?
Si l’application traite des données personnelles d’utilisateurs au Maroc (compte client, numéro de téléphone, géolocalisation, historique de commandes), le traitement entre dans le champ de la loi 09-08 et la déclaration préalable s’applique comme pour un site web ou un CRM. Le formulaire adéquat et les éventuels cas de dispense sont à vérifier sur le site de la CNDP.
Avant d’annoncer votre date de lancement
Le bon réflexe est de traiter la publication comme un livrable, avec ses pièces jointes et son responsable, et de la planifier au moment du cahier des charges plutôt qu’après la dernière recette. Annoncez la date au marché une fois l’application acceptée par les deux stores : la mise en ligne effective, elle, se déclenche quand vous le décidez.
Chez Arrowlancer, la soumission fait partie intégrante des projets de développement d’applications mobiles : création et configuration des comptes, politique de confidentialité conforme à la CNDP, déclarations de collecte, préparation des fiches, corrections et resoumission en cas de refus. Si votre app approche de la fin et que la question des stores reste ouverte, parlez-nous de votre date de lancement : c’est elle qui détermine l’ordre des tâches. La suite se prépare dans la foulée, et notre guide du budget de maintenance mobile donne les ordres de grandeur à prévoir après la mise en ligne.