Combien coûte une application mobile pour son entreprise ?

Un prestataire vous annonce 8 000 €, un autre 80 000 €, pour ce que vous décrivez comme le même projet. Les deux ont probablement raison, parce qu’ils ne chiffrent pas la même chose. Voici une grille de prix réelle, poste par poste, ce qui fait varier le budget d’une application mobile, et ce qu’elle coûte encore après sa mise en ligne sur les stores.

Quel budget prévoir pour une application mobile en 2026 ?

La réponse courte : entre 12 000 et 25 000 € HT pour un MVP mobile, entre 25 000 et 60 000 € HT pour une application complète. Le MVP (minimum viable product : la première version réduite mais opérationnelle d’un produit) couvre 5 à 8 écrans, l’authentification et la fonctionnalité cœur de votre usage métier, publiée sur l’App Store et Google Play.

Ces montants viennent de notre grille réelle, une base de code Flutter qui produit iOS et Android en parallèle. Melimelo, notre application d’organisation du foyer, et Trottr, notre application de gestion d’interventions terrain utilisée quotidiennement par des techniciens en connexion instable, sont construites et maintenues sur ce modèle : nous connaissons le coût complet parce que nous le payons nous-mêmes chaque mois.

Une précision qui change tout : ces montants incluent la publication sur les stores. Un projet livré en fichier source, jamais soumis à Apple ni à Google, n’est pas une application mobile, c’est du code qui attend.

Que finance exactement ce prix ?

Vous payez du temps de spécialistes, au même tarif que le reste du développement logiciel : un développeur confirmé facture 700 à 800 € par jour en France, un expert 850 à 950 € (taux journaliers moyens de l’IT en France, BDM). Un MVP mobile à 18 000 €, c’est l’équivalent d’une vingtaine de jours de travail confirmé, répartis sur cinq postes :

• Le cadrage (environ 10 %) : transformer votre besoin en écrans précis. Sur mobile plus qu’ailleurs, un parcours mal pensé au départ coûte cher à corriger une fois développé.
• Le design (10 à 15 %) : chaque écran pensé pour un pouce sur un petit rectangle, pas pour une souris sur un grand moniteur. Les règles d’interface d’Apple et de Google sont strictes, et un design qui les ignore se fait rejeter en review.
• Le développement (50 à 55 %) : le cœur de la facture. Sur Flutter, une ligne de code sert les deux plateformes, ce qui réduit ce poste par rapport à deux développements natifs séparés.
• Les tests multi-appareils et la soumission stores (15 à 20 %) : tester sur plusieurs modèles de téléphones et versions d’OS, préparer les visuels et textes exigés par Apple et Google, gérer la review et ses éventuels rejets. C’est le poste le plus souvent sous-estimé dans les devis low cost.
• Le pilotage (5 à 10 %) : quelqu’un qui arbitre les compromis et tient le planning jusqu’à la mise en ligne effective, pas jusqu’à la dernière ligne de code.

Natif ou cross-platform : quel choix change le budget ?

Le choix technique le plus structurant pour votre budget. Le développement natif consiste à écrire deux applications séparées, une en Swift pour iOS, une en Kotlin pour Android : deux bases de code, deux équipes ou deux fois plus de temps, deux fois plus de tests, deux fois plus de bugs à corriger dans la durée. Le cross-platform (Flutter en tête, un framework créé par Google) compile une seule base de code vers les deux plateformes, avec des performances identiques au natif pur et un accès complet aux fonctionnalités du téléphone : caméra, géolocalisation, notifications, capteurs.

L’écart de budget se joue surtout dans la durée. Au développement initial, l’écart entre natif et cross-platform reste modéré si le projet est simple. Il se creuse ensuite, à chaque évolution et à chaque correctif : sur un développement natif séparé, toute nouvelle fonctionnalité se code, se teste et se maintient deux fois. Sur une base Flutter unique, elle se code, se teste et se maintient une fois. Sur trois ans de vie d’un produit, avec plusieurs évolutions par an, cette différence pèse largement plus que l’écart au lancement.

Le natif garde un intérêt réel dans deux cas précis : une application qui exploite des capacités matérielles très récentes et propres à une seule plateforme, ou un jeu avec des exigences graphiques extrêmes. Pour une application métier ou grand public classique, formulaire, liste, carte, notification, paiement, le cross-platform couvre la quasi-totalité des besoins d’une PME sans compromis visible pour l’utilisateur final.

Combien de temps pour publier une application sur les stores ?

Un MVP mobile est publiable en 8 à 12 semaines, une application complète en 3 à 5 mois. Ce délai couvre le cadrage, le design, le développement et les tests, mais pas encore la review des stores, la dernière étape avant que vos utilisateurs puissent télécharger l’application.

Cette review suit un calendrier que vous ne maîtrisez pas entièrement, mais qui reste prévisible :

1. Soumission à Apple et Google. Les deux stores exigent des captures d’écran, une description, une politique de confidentialité et, pour Apple, souvent une démonstration vidéo ou des identifiants de test.
2. Examen automatisé et humain. Apple annonce qu’en moyenne 90 % des soumissions sont examinées en moins de 24 heures (Apple Developer, App Review). Google Play est généralement encore plus rapide sur ce délai.
3. Rejet éventuel et correction. Un premier rejet pour un détail de conformité (texte manquant, permission mal justifiée, parcours de test incomplet) est fréquent et ajoute 2 à 5 jours, rarement plus si le correctif est ciblé.
4. Mise en ligne. Une fois validée, l’application est disponible immédiatement ou à la date programmée par vos soins.

Prévoyez une marge d’une à deux semaines entre la fin du développement et la disponibilité effective sur les stores : c’est rarement zéro, ce n’est presque jamais long non plus.

Combien coûte une application mobile après son lancement ?

C’est le poste que la plupart des devis ignorent, et il ne s’arrête jamais tant que l’application existe. Une application mobile en production coûte quatre choses :

Les frais de comptes développeurs sont fixes et documentés par les plateformes elles-mêmes (Apple Developer Program, Google Play Console). Le vrai budget récurrent est ailleurs, dans la maintenance : iOS et Android publient plusieurs mises à jour majeures par an, et une application qui ne suit pas ce rythme finit par ne plus fonctionner correctement, voire par être retirée des stores pour non-conformité. C’est exactement le rôle de la tierce maintenance applicative, et c’est un budget à prévoir dès le cadrage, pas à découvrir six mois après le lancement.

Posez le calcul sur un MVP à 18 000 €, hébergé à 80 € par mois et maintenu à 1 000 € par mois en bas de fourchette : 18 000 + 2 900 + 36 000, soit près de 57 000 € sur 3 ans. Le développement pèse moins d’un tiers du total. Le mobile a ceci de particulier que sa maintenance n’est pas optionnelle : chaque version majeure annuelle d’iOS et d’Android peut casser une application laissée à l’abandon, et les stores retirent progressivement les applications qui ne suivent plus leurs exigences techniques. Un site web vieillit doucement ; une application mobile non maintenue a une date de péremption.

Comment réduire le budget sans sacrifier la qualité ?

Un budget de 15 à 30 k€ bien employé suffit à lancer une vraie application mobile. Quatre leviers, dans l’ordre d’efficacité :

1. Choisir le cross-platform par défaut. Sauf besoin natif avéré, Flutter divise le budget de maintenance par deux sur la durée de vie du produit : c’est le levier le plus rentable de cette liste, et il ne coûte rien de plus au lancement.
2. Réduire le périmètre du MVP, pas sa qualité. 5 écrans excellents valent mieux que 12 écrans approximatifs. Notre approche prototype vers MVP applique cette discipline dès le cadrage.
3. Ne pas réinventer le standard. Authentification, paiement, notifications push : des briques éprouvées existent, votre budget doit financer ce qui différencie votre application, pas ce que toutes les applications font déjà.
4. Activer le dev for equity si le budget cash est le point bloquant. Sur les projets qui nous convainquent, nous prenons une part du capital en échange d’une partie du développement : c’est le principe du dev for equity, et une application mobile s’y prête aussi bien qu’un SaaS.

Nous avons détaillé l’arbitrage entre freelance, agence et studio, transposable au mobile sans changer une ligne, dans freelance, agence ou studio : qui choisir pour votre projet.

Une application mobile est-elle toujours la bonne réponse ?

Non, et le dire honnêtement évite de dépenser 20 000 € pour résoudre un problème qui n’en demandait pas tant. Trois signaux indiquent qu’un site web suffit :

• L’usage est purement consultatif. Si personne n’a besoin d’utiliser votre outil hors ligne, ni de recevoir une notification en temps réel, ni d’accéder à la caméra ou à la géolocalisation, un site web responsive fait le même travail pour un budget inférieur, sans review de store ni compte développeur.
• L’audience n’a aucune raison d’installer une application. Une application se justifie par un usage répété : un client qui revient chaque semaine, un technicien qui l’ouvre chaque jour. Pour un usage occasionnel ou grand public non fidélisé, le taux d’installation reste souvent trop bas pour justifier l’investissement.
• Le besoin n’est pas encore validé. Si vous testez une idée avant de savoir si elle trouve son marché, un prototype web se construit plus vite et moins cher qu’une application mobile, avec la possibilité de basculer ensuite si la traction est là.

À l’inverse, dès qu’un usage hors ligne, une notification poussée ou un accès régulier et répété entrent en jeu, comme c’est le cas pour Trottr sur le terrain, l’application mobile cesse d’être un choix de confort pour devenir la seule réponse qui fonctionne réellement.

Le budget exact de votre projet sort d’un cadrage, pas d’un article de blog. 30 minutes en visio avec un fondateur suffisent pour une première fourchette honnête, natif ou cross-platform, avec ou sans interfaçage : si les chiffres de cette page vous semblent compatibles avec votre projet, parlons-en.