Prix d’une application mobile au Maroc : ce qui fait vraiment le coût

Le prix d’une application mobile dépend de sept postes de travail précis, pas du nombre d’écrans : le parcours, les comptes utilisateurs, le serveur, l’espace d’administration, les paiements, les notifications et le design. Deux applications de dix écrans peuvent coûter du simple au quintuple, parce que l’une affiche des informations et que l’autre gère des comptes, des réservations et des paiements.

Ce guide détaille chaque poste, les frais publics de Google et d’Apple, les coûts qui arrivent après la mise en ligne, et la façon de réduire la facture sans rater le projet. Je ne donne volontairement pas de fourchette de prix : sans cahier des charges, ce serait un chiffre commercial, pas une estimation.

Pourquoi personne ne peut te donner un prix sans en savoir plus

Une application mobile n’est pas un produit sur étagère : c’est un assemblage de fonctions, et chacune a son coût propre.

Quand quelqu’un m’écrit « combien pour une application comme Glovo ? », la vraie réponse commence par des questions. Faut-il un compte pour commander ? Qui gère les commandes, et depuis où ? Le paiement se fait-il en ligne ou à la livraison ? Faut-il suivre un livreur sur une carte ? Chaque « oui » ajoute un bloc de travail, et c’est la somme de ces blocs qui fait le prix.

C’est aussi pour ça qu’un prix annoncé d’emblée, sans aucune question, doit t’alerter. Soit il couvre une version beaucoup plus simple que ce que tu imagines, soit il sera rattrapé plus tard par des avenants.

La bonne démarche est l’inverse : décrire d’abord ce que l’application doit faire, puis demander un chiffrage. Le modèle de cahier des charges que je propose pour les sites s’applique très bien aux applications, et il te fera gagner plusieurs allers-retours.

Les sept postes qui font le prix d’une application mobile

Voici les blocs qui composent presque toutes les applications. Pour chacun, la question qui fait varier le prix.

Poste	Ce qui fait monter le prix	La question à te poser
Parcours et écrans	Le nombre de chemins différents, pas d’écrans	Combien de choses différentes l’utilisateur peut-il faire ?
Comptes utilisateurs	Rôles multiples, connexion par téléphone ou réseaux sociaux	Faut-il un compte, et y a-t-il plusieurs types d’utilisateurs ?
Serveur et données	Données partagées entre utilisateurs, synchronisation	Les données restent-elles sur le téléphone ou sont-elles partagées ?
Administration	Tableaux de bord, statistiques, validation de contenus	Qui gère l’application au quotidien, et depuis quoi ?
Paiements	Paiement en ligne, abonnements, remboursements	L’utilisateur paie-t-il dans l’application ?
Notifications	Notifications personnalisées ou programmées	Faut-il prévenir l’utilisateur, et selon quelles règles ?
Design	Interface entièrement sur mesure, animations	Faut-il une identité visuelle unique ou un design sobre et efficace ?

Le parcours et les écrans

Dix écrans qui affichent des informations coûtent peu. Dix écrans qui permettent de créer, modifier, filtrer et partager coûtent beaucoup plus, parce que chaque action demande de la logique, des contrôles et des tests. On chiffre des parcours, pas des écrans.

Les comptes utilisateurs

Dès qu’un utilisateur doit se connecter, il faut gérer l’inscription, la connexion, le mot de passe oublié, la suppression du compte, que les stores exigent désormais, et la protection des données personnelles. Si en plus l’application a plusieurs types d’utilisateurs, par exemple un client et un livreur, c’est presque deux applications dans une.

Le serveur et la base de données

Une application dont les données restent sur le téléphone n’a pas besoin de serveur. Dès que les données sont partagées, qu’un client voit ce qu’un autre a publié ou qu’un gérant suit ses commandes, il faut un serveur, une base de données et une interface de programmation pour les relier. C’est souvent le poste le plus lourd, et le moins visible.

L’espace d’administration

Quelqu’un doit gérer l’application : ajouter des produits, valider des inscriptions, répondre aux demandes, consulter les chiffres. Cet espace, souvent un site web réservé à l’équipe, est un projet à part entière. On l’oublie presque toujours dans les premières estimations.

Les paiements

Payer dans l’application implique une passerelle de paiement, la gestion des échecs, des remboursements et des reçus, et des règles propres aux stores : un contenu numérique vendu dans une application passe en principe par le système de paiement de Google ou d’Apple, avec leur commission. Au Maroc, l’intégration d’une passerelle locale a ses propres étapes, détaillées dans le guide pour accepter les paiements en ligne au Maroc.

Les notifications

Envoyer la même notification à tout le monde est simple. Envoyer la bonne notification à la bonne personne au bon moment, un rappel la veille d’un rendez-vous par exemple, demande des règles, un planificateur et des tests sur les deux systèmes.

Le design

Un design sobre qui suit les conventions d’Android et d’iOS se conçoit vite et vieillit bien. Une interface entièrement sur mesure, avec animations et identité forte, demande beaucoup plus de temps de conception et de développement. Les deux sont légitimes ; ce qui compte, c’est de choisir en connaissance de cause.

Android seul, ou Android et iPhone ?

Au Maroc, Android est très largement majoritaire sur le parc de téléphones, ce qui fait souvent de Google Play le premier store à viser. Si ta clientèle est plus aisée, ou située en Europe et dans le Golfe, la part d’iPhone augmente nettement et l’App Store devient indispensable.

Le choix a un effet direct sur le budget, mais moins qu’on ne le croit, grâce aux technologies multiplateformes présentées juste après. Le vrai surcoût d’iOS tient surtout au compte Apple, payant chaque année, à la révision d’Apple, plus exigeante, et aux tests sur un second système.

Ma recommandation habituelle : lancer sur Android si c’est là que sont tes utilisateurs, prouver que l’application sert, puis ouvrir la version iPhone avec le même code quand les chiffres le justifient.

Application native, multiplateforme ou PWA : l’effet sur le budget

Trois grandes façons de construire une application, avec des budgets très différents.

L’application native est écrite séparément pour Android et pour iOS, chacune dans son langage. C’est l’option la plus performante pour les usages exigeants, comme les jeux ou le traitement vidéo, mais c’est deux développements, donc deux budgets.

L’application multiplateforme utilise un seul code pour produire les deux versions. Pour la très grande majorité des applications de services, de réservation ou de gestion, c’est le meilleur rapport entre coût et qualité, et c’est l’option que je recommande le plus souvent.

La PWA, ou application web progressive, est un site qui s’installe sur l’écran d’accueil comme une application. Elle ne passe pas par les stores et coûte beaucoup moins cher, avec des limites sur les notifications, surtout sur iPhone, et sur l’accès au téléphone. Si tu hésites encore entre application et site, le guide application mobile ou site responsive t’aide à trancher avant de dépenser quoi que ce soit.

Les frais fixes et publics : Google Play, Apple, hébergement

Ce sont les seuls montants qu’on peut annoncer sans connaître ton projet, parce qu’ils sont publiés par les plateformes elles-mêmes.

Frais	Montant	Fréquence
Compte développeur Google Play	25 dollars	Une seule fois
Apple Developer Program	99 dollars	Chaque année
Nom de domaine (si site ou serveur)	Selon l’extension	Chaque année
Serveur (si données partagées)	Selon l’usage	Chaque mois

Les 25 dollars de Google sont indiqués dans l’aide officielle de la Play Console, et les 99 dollars annuels d’Apple sur la page du programme développeur. Ce sont des frais faibles : ce n’est jamais eux qui font le budget d’un projet.

Une règle récente pèse en revanche sur le calendrier. Depuis le 13 novembre 2023, un compte Google Play personnel doit faire tester chaque nouvelle application en test fermé, par au moins 12 testeurs pendant 14 jours consécutifs, avant de pouvoir la publier pour tout le monde. Il faut trouver ces testeurs et compter ces deux semaines. Les comptes d’organisation ne sont pas concernés, mais demandent d’autres démarches, décrites dans le guide pour publier une application depuis le Maroc.

Les coûts qui arrivent après la mise en ligne

C’est le poste que presque tous les porteurs de projet oublient, et celui qui fait mourir le plus d’applications.

Le serveur se paie chaque mois dès que l’application stocke des données partagées. Son coût monte avec le nombre d’utilisateurs, ce qui est une bonne nouvelle, mais il faut le prévoir.

Les mises à jour imposées. Google et Apple font évoluer leurs systèmes chaque année, et Google Play exige que les applications ciblent une version récente d’Android pour pouvoir continuer à être mises à jour. Une application jamais retouchée devient progressivement incompatible, puis invisible pour les nouveaux utilisateurs.

Les corrections. Une application utilisée par de vrais gens révèle des cas que personne n’avait prévus. Les premières semaines après le lancement sont toujours celles des ajustements.

Le compte Apple, à renouveler chaque année, faute de quoi tes applications disparaissent de l’App Store.

Les obligations de confidentialité. Google Play demande une politique de confidentialité et une déclaration sur la façon dont l’application collecte et partage les données, et Apple exige des informations équivalentes. Au Maroc, si l’application collecte des données personnelles, la loi 09-08 s’applique aussi, avec une déclaration auprès de la CNDP. Ce ne sont pas des formalités à expédier la veille de la publication : elles se préparent en même temps que l’application, parce qu’elles décrivent exactement ce qu’elle fait. Mon outil gratuit de conformité CNDP vérifie déjà ce point pour le site qui accompagne ton application.

Un budget d’application sérieux prévoit donc deux lignes : la création, et l’entretien. Si seule la première existe, le projet n’est pas financé, il est seulement commencé.

Un cas réel : ce que contient Mol Event

Pour rendre tout cela concret, voici ce qu’il y a dans une application que j’ai conçue et publiée sur Google Play : Mol Event, un organisateur d’événements, du mariage à l’anniversaire.

Vue de l’extérieur, elle paraît simple : un compte à rebours jusqu’au jour J, une liste de tâches, une liste d’invités, un budget et un carnet de prestataires. Mais chaque module est un petit logiciel en soi.

La liste d’invités gère les statuts de réponse et la répartition par table. Le budget calcule en temps réel ce qui a été dépensé et ce qui reste, ligne par ligne, en dirhams. Le carnet de prestataires suit l’avancement de chaque contact, de « à contacter » à « réservé ». Et surtout, chaque événement garde ses propres données, ce qui oblige à penser la structure dès le premier jour : ajouter cette séparation après coup aurait coûté plus cher que de la prévoir.

C’est exactement la leçon que je retiens de ce projet pour mes clients : le prix se joue dans les décisions de structure prises au début, bien plus que dans le nombre d’écrans.

Si ton projet ressemble à celui-ci et que tu te demandes par où commencer, c’est le moment où un regard extérieur fait gagner le plus de temps : la création d’application mobile commence toujours chez moi par un découpage en fonctions, avant tout chiffrage.

Comment réduire le prix sans rater l’application

La seule méthode fiable est de réduire ce que fait la première version.

Pars de la question : quelle est la plus petite application qui prouve que l’idée marche ? Pour une application de réservation, c’est peut-être la réservation seule, sans paiement en ligne au départ, sans programme de fidélité, sans messagerie intégrée. Chaque fonction retirée fait baisser le prix mécaniquement, et chaque fonction ajoutée plus tard le sera en connaissant l’avis de vrais utilisateurs.

Autres leviers qui fonctionnent :

• Choisir le multiplateforme plutôt que deux applications natives, sauf besoin technique précis.
• Commencer par un seul store, celui où sont réellement tes utilisateurs.
• Utiliser des services éprouvés pour l’authentification, les notifications ou les cartes, plutôt que de tout réinventer.
• Garder un design sobre pour la première version, et investir dans l’identité visuelle une fois l’usage confirmé.

Ce qui ne fonctionne pas : choisir le devis le plus bas. Une application mal structurée coûte plus cher à corriger qu’à refaire, et c’est un scénario que je vois régulièrement.

Les devis qui doivent t’alerter

Un prix sans aucune question. Personne ne peut chiffrer une application sans savoir ce qu’elle fait.

Aucune ligne pour le serveur ou l’administration. Soit ils sont absents du projet, soit ils seront facturés plus tard.

L’application publiée sur le compte du prestataire. Elle doit l’être sur ton propre compte développeur. Sinon, tu ne contrôles ni tes mises à jour ni ta fiche, et changer de prestataire devient presque impossible.

Pas de mention du code source. Le code doit t’être livré. Sans lui, tu ne possèdes qu’un droit d’usage.

Rien sur l’après-lancement. Un devis qui s’arrête le jour de la publication ignore la partie la plus longue de la vie d’une application.

Ce qu’un bon devis d’application doit contenir

• La liste des fonctions, découpée en parcours, avec ce qui est inclus et ce qui ne l’est pas.
• Les plateformes visées : Android, iOS, ou les deux.
• La technologie choisie et la raison de ce choix.
• Le serveur, l’administration et les services tiers, chacun sur sa ligne.
• La publication sur les stores, faite sur ton compte.
• La livraison du code source et des accès.
• Une période de corrections après le lancement, et le coût de l’entretien ensuite.
• Un calendrier réaliste qui inclut les révisions des stores et, si besoin, les 14 jours de test fermé.

Un devis qui contient tout cela est comparable à un autre. Un devis qui n’en contient que la moitié ne l’est pas, même s’il est moins cher.

Les questions à préparer avant de demander un devis

Un devis d’application n’est jamais meilleur que la description qu’on donne au prestataire. Voici les questions auxquelles tu devrais pouvoir répondre avant le premier rendez-vous. Chacune fait basculer le prix d’un côté ou de l’autre.

Qui utilise l’application ? Un seul type d’utilisateur, ou plusieurs, comme un client et un prestataire ? Chaque rôle supplémentaire ajoute ses écrans, ses droits et ses tests.

Faut-il un compte pour l’utiliser ? Si oui, comment se connecte-t-on : email, numéro de téléphone, compte Google ? La connexion par numéro de téléphone, très appréciée au Maroc, demande l’envoi de codes par SMS, qui a un coût à chaque envoi.

Les données sont-elles partagées ? Si ce que fait un utilisateur doit être visible par un autre, il faut un serveur. C’est la question qui fait le plus varier le budget.

Qui gère l’application au quotidien ? Toi, une équipe, personne ? La réponse décide de la taille de l’espace d’administration.

L’utilisateur paie-t-il ? Et si oui, paie-t-il un service réel, comme une livraison ou une réservation, ou un contenu numérique, comme un abonnement premium ? Les règles des stores ne sont pas les mêmes dans les deux cas.

Dans quelles langues ? Une application en français et en arabe demande une interface qui s’inverse pour l’arabe, de droite à gauche, et une traduction relue. Ce n’est pas un détail d’affichage, c’est un chantier.

Qu’est-ce qui doit marcher sans connexion ? Le mode hors ligne complique fortement la synchronisation des données. S’il n’est pas indispensable, il vaut mieux l’écarter de la première version.

Si tu arrives avec ces réponses, même approximatives, tu obtiendras des devis comparables entre eux, et beaucoup plus proches du coût réel.

Les délais : ce qui allonge vraiment un projet d’application

Le développement n’est qu’une partie du calendrier. Ce sont les étapes autour qui font glisser les dates.

Les allers-retours sur la conception. Chaque écran validé tard, ou modifié après développement, coûte du temps deux fois. Valider les maquettes avant d’écrire la moindre ligne de code est la meilleure économie de temps d’un projet.

Les contenus. Textes, photos, listes de produits, conditions d’utilisation : si c’est à toi de les fournir et qu’ils arrivent en fin de projet, l’application attend.

La révision des stores. Google et Apple examinent chaque application avant publication, et Apple peut la refuser pour des raisons de contenu, de confidentialité ou de conception. Un refus n’est pas grave, mais il ajoute un cycle de correction.

Le test fermé de 14 jours pour un compte Google Play personnel récent, déjà évoqué plus haut, qu’il faut planifier dès le départ.

Les services tiers. L’ouverture d’un compte chez un prestataire de paiement, la validation d’un fournisseur de SMS ou la création d’un compte organisation chez Apple ont leurs propres délais, indépendants de ton prestataire.

Un calendrier réaliste intègre toutes ces étapes. Celui qui ne prévoit que le développement promet une date qu’il ne pourra pas tenir.

Et depuis la France, la Belgique, la Suisse ou le Canada ?

Les postes sont exactement les mêmes, et les frais des stores aussi : Google et Apple appliquent leurs tarifs dans le monde entier. Ce qui change, c’est le coût du développement lui-même, qui dépend du marché du travail de chaque pays.

Beaucoup d’entreprises européennes et canadiennes font développer leur application au Maroc pour cette raison, avec un fuseau horaire proche de l’Europe et une langue de travail commune. Le point d’attention reste le même partout : un contrat clair sur la propriété du code et la publication sur ton compte.

Par où commencer

Écris d’abord ce que ton application doit permettre de faire, en une liste de verbes : réserver, payer, suivre, être prévenu. Pour chaque verbe, note qui le fait et depuis quel appareil. Cette liste te dira déjà si tu as besoin d’un serveur, de comptes et d’une administration, c’est-à-dire des trois postes qui pèsent le plus.

Ensuite, coupe tout ce qui n’est pas indispensable à la première version.

Et quand ta liste est prête, envoie-la-moi : je te dis quels postes elle déclenche, ce que je retirerais de la première version, et je te propose un chiffrage détaillé, poste par poste, que tu pourras comparer à n’importe quel autre devis.