En France, il n’existe pas de prix unique pour une application mobile. Un baromètre 2026 fondé sur 216 projets situe la médiane à 30 000 €, avec la moitié centrale entre 15 000 et 50 000 €. Ce repère n’est pas un devis : le budget dépend surtout des parcours, du back-office, des intégrations, de la sécurité, des tests et de l’exploitation après le lancement.
Un prix moyen donne un repère, pas le prix de votre application
Le baromètre de La Fabrique du Net place le premier quartile des projets observés à 15 000 €, la médiane à 30 000 € et le troisième quartile à 50 000 €. Les données, arrêtées en juin 2026, viennent des agences référencées ; la source qualifie son analyse des fonctionnalités d’approximative.
Cette fourchette peut signaler une attente décalée, mais elle ne dit ni ce que comprend la prestation, ni ce qui restera à payer après la première version.
Pour préparer une enveloppe, ne demandez pas seulement « combien coûte une application ? ». Posez plutôt cette question : quel système faut-il concevoir, construire, mettre en service et maintenir pour que l’usage principal fonctionne ?
Pourquoi deux applications de six écrans peuvent-elles coûter très différemment ?
Un écran n’est pas une unité de travail stable. Un catalogue de six écrans qui affiche des contenus déjà disponibles peut être simple. Six écrans de réservation avec comptes, disponibilités en temps réel, paiement, annulation, remboursement et droits d’administration couvrent beaucoup plus de règles.
Le prix augmente avec les états à gérer. Une action peut réussir, échouer, attendre une validation ou être reprise hors connexion. Il faut concevoir ces situations, développer leur traitement et les tester.
Le premier travail d’estimation consiste donc à regarder derrière les écrans : qui agit, sur quelles données, avec quel droit, que se passe-t-il en cas d’erreur et qui résout le problème ?
Les sept postes qui composent le budget initial
Une estimation exploitable décompose le projet. Cette grille ne fixe pas un pourcentage universel ; elle évite qu’un poste disparaisse simplement parce qu’il est moins visible qu’une interface.
| Poste | Ce qu’il faut réellement chiffrer | Ce qui fait varier l’effort |
|---|---|---|
| Cadrage et UX | Besoin, parcours, priorités, prototype et critères d’acceptation | Nombre d’utilisateurs, règles contradictoires, disponibilité des équipes |
| Interface mobile | Écrans, navigation, états d’erreur et accessibilité | Variantes de parcours, animations, appareils et versions de système |
| Services et back-office | API, comptes, rôles, base de données, administration et historique | Volume de règles métier, droits, opérations internes et auditabilité |
| Données et intégrations | Import, export, paiement, cartographie, messagerie ou outil métier | Qualité des données, documentation des API, limites et erreurs des tiers |
| Sécurité et vie privée | Authentification, permissions, protection des échanges et minimisation | Sensibilité des données, rôles, obligations sectorielles et sous-traitants |
| Qualité et tests | Scénarios métier, appareils, performance, reprise après erreur | Nombre de combinaisons, hors-ligne, paiements et criticité de l’usage |
| Lancement | Comptes éditeur, fiches des stores, bêta, soumission et suivi | Plateformes, contenus à fournir, validations et corrections demandées |
Si un client crée une demande, l’équipe doit souvent la retrouver, la corriger, l’attribuer ou l’annuler. Chaque opération interne ajoute des droits et des contrôles. Supprimer le back-office réduit le budget seulement si une procédure manuelle fiable permet d’exploiter le service.
La sécurité n’est pas une option ajoutée en fin de projet. La CNIL recommande notamment de minimiser les données et permissions, de formaliser les objectifs de sécurité avec le développeur et de contrôler les composants externes intégrés (CNIL). Ces choix influencent l’architecture, les tests et le travail de maintenance.
Quelles fonctionnalités créent le plus d’incertitude ?
Certaines fonctions ne sont pas coûteuses par leur nom, mais par leurs conditions de fonctionnement.
Le hors-ligne et la synchronisation
Modifier un dossier sans réseau, puis le synchroniser, oblige à arbitrer les conflits, signaler les éléments en attente et éviter les doublons. Si l’usage se déroule dans des zones mal couvertes, traitez cette contrainte dès le périmètre initial.
Les rôles et les validations
« Avoir des comptes » peut désigner un profil unique ou plusieurs niveaux de responsabilité. Le budget suit les permissions, les invitations et les actions sensibles, pas le formulaire de connexion.
Les paiements, abonnements et remboursements
Encaisser un montant est une étape. Gérer échecs, renouvellements, annulations, remboursements et support en est une autre. Clarifiez le modèle économique avant de choisir le parcours de paiement.
Les intégrations avec un outil existant
Une API documentée et testable réduit l’incertitude. Un accès non confirmé impose parfois une exploration. Isolez alors la vérification, puis chiffrez l’intégration avec les informations obtenues.
Le temps réel et les notifications
Une information « instantanée » impose un délai cible et un comportement en cas d’échec. Pour certains usages, un rafraîchissement à la demande ou un e-mail suffit au lancement.
Il faut séparer trois budgets
Le budget de construction ne couvre pas toute la vie du produit. Avant de décider, séparez trois enveloppes.
- Construction initiale : cadrage, conception, développement, intégrations et tests de la première version.
- Mise en service : préparation des comptes, contenus des stores, bêta, publication, accompagnement de l’équipe et correction des problèmes de lancement.
- Exploitation : hébergement, services tiers, supervision, support, correctifs de sécurité et adaptations aux évolutions d’iOS, d’Android ou des outils connectés.
Les frais de compte illustrent cette distinction. Au 8 septembre 2026, Apple affiche une adhésion à son programme développeur de 99 USD par an (Apple Developer). Google Play affiche 25 USD de frais d’inscription uniques et demande à certains nouveaux comptes personnels de satisfaire des exigences de test (Google Play Console). Ces montants ne couvrent ni les tests, ni les fiches, ni la soumission, ni le traitement d’un refus.
Demandez qui paie et possède chaque compte. L’entreprise doit garder la maîtrise de ses accès éditeur, de son hébergement et de ses données.
Exemple rempli : une application d’intervention terrain
Prenons un exemple fictif. Une PME de douze techniciens veut remplacer ses fiches papier par une application : interventions du jour, photos et signature du client. Le réseau est irrégulier et l’API de l’outil de planning n’a pas été vérifiée.
Le dirigeant ne cherche pas encore un devis définitif. Il veut savoir quelle première version peut entrer dans son enveloppe sans promettre une intégration incertaine.
| Élément | Décision pour la première version | Classement budgétaire | Conséquence attendue |
|---|---|---|---|
| Parcours technicien | Consulter une intervention, rédiger le compte rendu, ajouter deux photos et signer | Inclus | Définit le cœur à concevoir et tester |
| Mode hors-ligne | Enregistrer un brouillon local, puis synchroniser avec un état visible | Inclus | Ajoute gestion des erreurs, conflits et reprise |
| Outil métier | Vérifier l’API sur un échantillon avant engagement | Exploration | Évite de chiffrer une connexion sur une hypothèse |
| Back-office | Rechercher un rapport et corriger son statut, sans éditeur complet de planning | Inclus, périmètre réduit | Donne à l’équipe un moyen de résoudre les incidents |
| Notifications | E-mail au responsable en cas d’échec de synchronisation | Inclus | Remplace des notifications mobiles plus poussées au lancement |
| Tableau de bord | Indicateurs avancés et exports personnalisés | Option reportée | Conserve les données nécessaires sans construire tous les rapports |
| Hébergement et suivi | Environnement, sauvegardes, supervision et maintenance | Récurrent | Rend visible le budget après livraison |
La décision devient lisible : chiffrer le parcours terrain, le hors-ligne limité et le back-office ; explorer l’API séparément ; reporter les analyses avancées. Si l’API est inutilisable, le dirigeant comparera import quotidien, ressaisie temporaire et changement d’outil.
Une base de code partagée peut mutualiser une partie de l’interface iOS et Android. Elle ne divise pas le budget par deux : cadrage, back-office, données, intégrations, tests et lancement restent nécessaires.
Comment préparer une enveloppe avant de demander un devis ?
Commencez par le parcours qui rend le produit utile. Ajoutez le travail de l’équipe, les données, les erreurs et les services externes. S’ils restent implicites, utilisez le modèle de cahier des charges d’application avant de chercher un prix ferme.
Pour chaque élément, choisissez l’une de ces quatre colonnes :
- Inclus : nécessaire pour rendre le parcours principal utilisable.
- Option : utile, mais chiffrable et reportable sans casser ce parcours.
- Exploration : inconnue technique ou métier à vérifier avant un engagement.
- Récurrent : coût ou travail qui continue après le lancement.
Demandez une estimation avec ses hypothèses. Une fourchette large est acceptable si elle explique ce qui la resserrera. Un montant précis bâti sur des accès ou des règles inconnus ne réduit pas le risque ; il le masque. Nommez chaque inconnue, son responsable et le moment de l’arbitrage.
Quand un outil existant suffit-il ?
Si votre besoin reprend un processus courant, testez d’abord un SaaS ou une solution configurable. Évaluez les rôles, les données, les intégrations, l’export et le coût dans la durée, pas seulement la démonstration commerciale.
Le sur-mesure devient cohérent si le parcours constitue un avantage métier ou si les outils existants imposent des contournements coûteux. Comparez son coût aux adaptations internes et à la dépendance au SaaS.
Les erreurs qui rendent une estimation trompeuse
- Prendre la fourchette la plus basse comme promesse. Elle peut couvrir une prestation partielle, une seule plateforme ou un périmètre très réduit.
- Compter uniquement les écrans. Les rôles, états, erreurs et opérations internes expliquent mieux l’effort.
- Reporter sécurité et tests. Cela déplace le travail vers la mise en service, où les corrections coûtent aussi du temps et peuvent bloquer le lancement.
- Présenter une intégration inconnue comme certaine. Une exploration isolée produit une meilleure décision qu’un forfait artificiellement rassurant.
- Oublier l’exploitation. Une application sans suivi, sauvegarde, mises à jour et responsable identifié se dégrade après sa première livraison.
Klaapp accompagne le cadrage et la création de logiciels et d’applications mobiles. Un premier échange peut servir à examiner le parcours principal, les opérations internes, les dépendances et les inconnues, puis à décider si le projet est assez défini pour une estimation ou s’il faut d’abord réduire le risque sur un point précis.
Questions fréquentes
Combien coûte une application mobile simple ?
« Simple » ne décrit pas un périmètre. Le baromètre cité place la moitié centrale des projets observés entre 15 000 et 50 000 €, mais une prestation partielle peut coûter moins et une plateforme complexe davantage. Décrivez parcours, back-office, données, plateformes et intégrations.
Développer pour iOS et Android double-t-il le budget ?
Pas nécessairement. Une base partagée mutualise une partie du développement. Les tests, comptes de distribution et comportements propres à chaque système restent à prévoir.
Le no-code réduit-il toujours le prix ?
Le no-code peut réduire le travail initial si le processus correspond aux composants disponibles. Vérifiez personnalisation, intégrations, export, abonnements et migration. Un prototype rapide n’est économique que s’il teste la décision visée.
Faut-il prévoir la maintenance dans le devis initial ?
Il faut au moins la rendre visible séparément : responsabilités, délai de correction, mises à jour des dépendances, supervision et services récurrents. Le niveau de maintenance dépend de la criticité, de la fréquence d’usage et du rythme d’évolution ; un pourcentage standard ne remplace pas ce périmètre.
Sources
- La Fabrique du Net — Tarifs d’une agence de développement mobile
- CNIL — Sécurité : applications mobiles, conception et développement
- Apple Developer — Membership Details
- Google Play Console — Get started with Play Console
Valentin Merault est cofondateur de Klaapp. Il intervient sur le cadrage, le produit, l’IHM et l’expérience utilisateur. Découvrir le studio Klaapp.