C’est la première question posée dans presque tous nos rendez-vous, et c’est aussi celle à laquelle on répond le plus mal dans notre métier : combien coûte une application mobile ?
La réponse honnête tient en une phrase : entre 5 000 € pour une première version testable et plus de 150 000 € pour une application complexe, avec une médiane autour de 30 000 € sur les projets réellement engagés en France (La Fabrique du Net).
Cette fourchette est trop large pour être utile telle quelle. Voici comment la resserrer.
Les fourchettes par type d’application
Le prix ne dépend pas du nombre d’écrans. Il dépend du nombre de règles métier et du niveau d’intégration avec vos systèmes existants.
| Type d’application | Fourchette 2026 |
|---|---|
| Simple / vitrine | 8 000 – 20 000 € |
| MVP, prototype fonctionnel | 10 000 – 40 000 € |
| Application métier (e-commerce, réservation) | 25 000 – 80 000 € |
| Complexe (marketplace, temps réel, social) | 80 000 – 150 000 € + |
Ces ordres de grandeur sont cohérents d’une source à l’autre du marché français (EID Lab, Yeeply).
Le saut le plus coûteux n’est pas visuel, il est invisible : c’est le passage d’une application qui affiche des données à une application qui en modifie. Dès qu’il y a comptes utilisateurs, paiement, synchronisation ou droits d’accès, vous changez de catégorie de budget.
Natif ou hybride : l’arbitrage qui pèse le plus
C’est la décision qui a le plus d’impact sur votre facture.
Le natif consiste à développer deux applications distinctes, une pour iOS et une pour Android. Les performances sont maximales, mais vous doublez le travail : comptez 27 000 à 135 000 € par plateforme.
L’hybride utilise une base de code unique pour les deux systèmes. La facture baisse de 30 à 50 % (KBCOM).
Le natif se justifie si vous faites du jeu, de la réalité augmentée, du traitement vidéo lourd ou de l’accès matériel avancé. Pour une application métier — commande, réservation, suivi, gestion — l’hybride est le bon choix dans la grande majorité des cas, et l’écart de qualité perçue par l’utilisateur est aujourd’hui négligeable.
Le coût que personne ne budgète : la maintenance
C’est la ligne qui manque dans la plupart des business plans qu’on nous présente.
Une application mobile n’est pas un site web qu’on peut laisser tourner trois ans sans y toucher. iOS et Android publient une version majeure par an, les règles des stores évoluent, et une application non maintenue finit par être refusée ou retirée.
Le budget à prévoir : 15 à 20 % de l’investissement initial, chaque année. Sur une application à 40 000 €, cela fait 6 000 à 8 000 € par an.
Une agence qui ne vous parle pas de maintenance dans son devis ne vous a pas donné le prix de votre application. Elle vous a donné le prix de sa livraison.
Pourquoi deux devis peuvent varier du simple au quadruple
Vous décrivez le même projet à quatre prestataires et vous recevez 12 000 €, 28 000 €, 45 000 € et 90 000 €. Ce n’est pas forcément que trois d’entre eux sont malhonnêtes.
L’écart vient presque toujours de ce qui n’est pas écrit :
- Le back-office. Qui administre le contenu, les utilisateurs, les commandes ? Une interface d’administration, c’est souvent 30 % du projet.
- Les tests. Sur combien d’appareils réels, dans combien de scénarios ?
- La publication. Comptes développeurs, fiches store, conformité RGPD, gestion des refus d’Apple.
- La reprise de données depuis votre système existant.
- Le nombre d’allers-retours inclus avant que chaque modification devienne facturable.
Avant de comparer des montants, comparez des périmètres. Demandez à chaque prestataire ce que son devis ne couvre pas : la réponse est plus instructive que le total.
Commencez plus petit que vous ne le pensez
Le réflexe naturel est de lister toutes les fonctionnalités souhaitées puis d’en demander le prix. C’est le meilleur moyen de payer cher des fonctions dont personne ne se servira.
Un MVP entre 10 000 et 40 000 € met l’application entre les mains d’utilisateurs réels en quelques semaines. Vous découvrez alors ce qui est utilisé, ce qui est ignoré, et ce qui manquait et que personne n’avait demandé.
La règle est simple : les usages observés coûtent moins cher à corriger que les usages supposés.
C’est la même logique de cadrage budgétaire que nous appliquons aux projets web, détaillée dans notre article sur le coût d’un site web professionnel.
Notre approche
Chez DIGABLO, nous cadrons le budget avant d’écrire une ligne de code :
- Un atelier de cadrage pour distinguer ce qui est indispensable au lancement de ce qui peut attendre.
- Un périmètre écrit, avec ce qui est inclus et surtout ce qui ne l’est pas.
- Hybride par défaut, natif seulement quand votre usage le justifie vraiment.
- Maintenance chiffrée dès le devis, pas découverte six mois après la livraison.
- Livraisons intermédiaires, pour que vous voyiez l’application tourner avant la fin du budget.
Vous avez un projet d’application et besoin d’un ordre de grandeur fiable ? Parlons de votre projet : on vous donne une fourchette argumentée, même si la réponse est que vous n’avez pas besoin d’une application.