Le prix d'une application mobile au Maroc ne se lit pas sur une grille tarifaire, et tout prestataire qui vous en annonce un avant d'avoir posé cinq questions vous vend autre chose que ce dont vous avez besoin. La facture tient à cinq variables et à elles seules : le nombre d'écrans réellement différents, l'existence ou non de comptes utilisateurs, la présence d'un paiement, la connexion à un système existant, et le fait de viser une plateforme ou les deux. Cet article explique comment chacune agit sur le budget, ce qui revient tous les ans après la livraison, et comment découper un projet pour mettre en ligne une première version utile au lieu d'attendre un an.
Ce qui fait le prix d'une application mobile au Maroc
1. Le nombre d'écrans réellement différents
C'est la variable la plus visible, et la plus mal comptée. Un catalogue de 500 produits n'est pas 500 écrans : c'est un écran de liste et un écran de détail. En revanche, une application qui affiche un tableau de bord, un historique, un profil, un formulaire de demande, un suivi et une messagerie compte six chantiers distincts, chacun avec ses états vides, ses erreurs et ses cas limites.
Comptez les écrans qui se ressemblent comme un seul, et les écrans qui ne se ressemblent pas comme autant de sous-projets.
2. Les comptes utilisateurs
Une application sans compte — un catalogue, un guide, un horaire, une carte — reste simple. Dès qu'il y a inscription, il faut gérer la connexion, le mot de passe oublié, la vérification du numéro ou de l'e-mail, la suppression du compte, les données personnelles, et les différents rôles si tous les utilisateurs ne voient pas la même chose.
Au Maroc, ajoutez une décision structurante : la vérification par SMS a un coût par message qui vous suivra tous les mois. Beaucoup de projets choisissent la vérification par WhatsApp ou l'e-mail pour cette raison.
3. Le paiement
Il ne s'agit pas d'ajouter un bouton. Il faut choisir qui encaisse, ouvrir le dossier correspondant, gérer les échecs, les remboursements, les reçus, et décider du comportement quand un paiement est accepté par la passerelle mais que la commande échoue côté application. Selon ce que vous vendez, les règles des magasins d'applications s'invitent également dans la discussion. Le paysage des acteurs et les conditions d'accès sont décrits dans notre guide des passerelles de paiement au Maroc.
4. La connexion à ce que vous utilisez déjà
C'est la variable qui fait le plus varier un devis, et celle qu'on mentionne en dernier. Une application qui doit lire votre stock réel, écrire une commande dans votre logiciel de gestion ou créer une facture dans votre comptabilité dépend de ce que ce logiciel sait faire.
Trois cas, trois budgets très différents :
- le logiciel expose une interface de programmation documentée : l'intégration est un travail prévisible ;
- le logiciel n'expose rien, mais permet des exports et des imports : on construit une synchronisation, avec ses décalages ;
- le logiciel est fermé, ou c'est un tableur partagé : il faut d'abord construire la source de données, et cela devient un projet en soi.
Posez la question à votre éditeur avant de demander un devis d'application. La réponse change le chiffre davantage que le design.
5. Une plateforme ou les deux
iOS et Android ne coûtent plus deux fois le même prix depuis que les technologies multiplateformes permettent d'écrire une base commune, mais cela ne rend pas la deuxième plateforme gratuite : il reste des ajustements d'interface, deux publications, deux processus de validation et deux campagnes de tests sur des appareils réels. Au Maroc, beaucoup de projets grand public démarrent sur Android seul puis ajoutent iOS, selon le profil de leur clientèle.
| Variable | La question à trancher | Effet sur le budget |
|---|---|---|
| Écrans | Combien d'écrans réellement différents, hors listes répétées ? | Proportionnel, poste principal |
| Comptes utilisateurs | Inscription, rôles, vérification : oui ou non ? | Saut net dès le premier compte |
| Paiement | Qui encaisse, et que se passe-t-il en cas d'échec ? | Saut net, plus des frais récurrents |
| Connexion à un logiciel | Interface disponible, exports, ou rien ? | De prévisible à multiplicateur |
| Plateformes | Android, iOS, ou les deux dès la V1 ? | Ajout partiel, pas un doublement |
Les trois formats de projet qu'on rencontre le plus
L'application vitrine ou catalogue. Elle présente, informe, localise, prend un contact. Pas de compte, pas de paiement, contenu administré depuis un site. C'est le format le plus léger — et souvent celui qui ne justifie pas une application du tout, question traitée dans notre comparatif application mobile ou site web.
L'application métier interne. Les équipes terrain saisissent, les responsables consultent. Peu d'utilisateurs, beaucoup de règles, une connexion obligatoire au système de gestion, un besoin fréquent de fonctionnement hors connexion. Le prix vient de la logique, pas du design. C'est le format le plus rentable quand il remplace des allers-retours en papier ou en messagerie.
L'application produit. Comptes, paiement, notifications, contenu qui change. Le budget initial n'est qu'une partie du sujet : il faut prévoir la vie de l'application après le lancement, parce qu'elle ne s'arrête jamais.
Ce qui revient chaque année, même si vous ne changez rien
Une application n'est pas un achat, c'est un abonnement déguisé. Quatre lignes reviennent, indépendamment de toute nouvelle fonctionnalité :
- Les comptes développeurs. Apple et Google facturent l'accès à leurs programmes de publication, l'un sur une base annuelle, l'autre sur une inscription initiale. Le détail des démarches figure dans notre guide pour publier une application sur le Play Store et l'App Store.
- L'hébergement et les services connectés. Votre application parle à un serveur : il tourne, il sauvegarde, il coûte tous les mois.
- Les mises à jour imposées. Les systèmes iOS et Android évoluent chaque année, et les magasins exigent régulièrement que les applications soient recompilées avec des versions récentes. Une application qu'on ne touche pas pendant deux ans finit par être retirée ou refusée.
- Les corrections et les petites évolutions. Le détail de ce poste et des formules d'accompagnement est dans notre article sur le prix de la maintenance d'une application mobile.
Le bon réflexe, au moment du devis : demander ce que coûtera la deuxième année, pas seulement la livraison. Un prestataire qui n'a pas de réponse claire à cette question n'a pas prévu la suite.
Comment découper pour livrer une première version utile
La méthode qui tient, projet après projet, tient en trois règles.
Définir l'action principale. Une application sert d'abord à une chose : commander, réserver, déclarer une intervention, consulter un solde, suivre une livraison. Tout ce qui n'est pas cette action est une option. Écrivez la phrase « l'utilisateur ouvre l'application pour… » et coupez tout ce qui ne la sert pas dans la première version.
Livrer d'abord le chemin complet, pas la moitié des fonctions. Mieux vaut un seul parcours qui va de l'ouverture jusqu'à la confirmation, en conditions réelles, que six fonctionnalités qui s'arrêtent avant la fin. Un parcours complet peut être utilisé, donc mesuré, donc corrigé.
Tester avec de vrais utilisateurs avant d'ajouter. Dix personnes qui utilisent l'application une semaine vous apprennent plus que trois réunions de cadrage. Les demandes qui remontent ne sont jamais celles qu'on avait listées.
Chez nous, un site vitrine se livre en cinq à dix jours ouvrables, et un e-commerce ou une application sur mesure en trois à six semaines. Ces délais ne sont tenables que parce que le périmètre est tranché avant de commencer : c'est le rôle du cahier des charges, dont la trame est détaillée dans notre guide du cahier des charges d'une application mobile.
Lire un devis d'application sans se faire piéger
Un devis exploitable contient au minimum : la liste des écrans, le détail de ce qui est administrable par vous après la livraison, les plateformes visées, ce qui est fait côté serveur, qui possède le code et les comptes, le nombre de cycles de retours inclus, ce qui se passe après la mise en ligne, et le coût de la deuxième année.
Trois signaux doivent vous alerter. Un prix annoncé sans questions sur votre logiciel de gestion : l'intégration sera facturée en supplément. Un devis où « application iOS et Android » tient en une ligne : le périmètre n'a pas été analysé. Et l'absence de mention sur la propriété du code et des comptes développeurs : c'est le point qui vous empêchera de changer de prestataire.
Vous avez un projet d'application et vous voulez savoir ce qui, dans votre cas précis, fait monter ou descendre la facture ? Décrivez-nous l'action principale de votre application, vos utilisateurs et le logiciel auquel elle devra se connecter. Nous vous répondons avec un périmètre chiffré et un découpage en versions. Devis gratuit sous 24 heures sur samedagency.com.
Questions fréquentes
Pourquoi les devis d'applications varient-ils autant d'un prestataire à l'autre ? Parce qu'ils ne décrivent pas le même produit. L'un chiffre un catalogue connecté à un site, l'autre une application avec comptes, paiement et synchronisation avec votre gestion. Comparez les périmètres écran par écran avant de comparer les montants : l'écart vient presque toujours de là.
Une application no-code revient-elle moins cher ? À la construction, souvent oui. Sur la durée, cela dépend : vous payez un abonnement par utilisateur ou par volume, et vous dépendez des limites de l'outil. C'est un bon choix pour valider un usage interne rapidement, un moins bon pour une application grand public destinée à évoluer pendant des années.
Faut-il développer iOS et Android dès le départ ? Pas toujours. Regardez les appareils de vos clients ou de vos équipes avant de trancher. Pour une application interne, l'inventaire du parc décide en cinq minutes. Pour une application grand public, démarrer sur une seule plateforme réduit le budget initial et accélère les premiers retours d'usage.
Combien de temps faut-il pour une première version ? Cela dépend du périmètre, mais l'ordre de grandeur d'une application sur mesure chez nous se compte en semaines, pas en mois, à condition que le périmètre soit arrêté et que les accès aux systèmes existants soient disponibles dès le début. Les projets qui dérapent dérapent presque toujours sur ces deux points.
Qui doit posséder le compte développeur ? Vous. Le compte Apple et le compte Google Play doivent être ouverts au nom de votre entreprise, avec vos accès, même si votre prestataire s'en sert pour publier. C'est ce qui vous garantit de garder votre application et ses avis le jour où vous changez d'équipe technique.