Combien coûte le développement d'une application mobile

Le développement d’une application mobile se chiffre en jours avant de se chiffrer en euros. Comptez 60 à 90 jours-homme pour une première version réellement publiée, multipliés par un tarif journalier de 450 à 900 euros selon le prestataire. Le montant obtenu, souvent entre 30 000 et 60 000 euros, découle entièrement de cette équation.

Une équation à deux facteurs, jamais un tarif au forfait

Tout devis d’application repose sur une multiplication : une charge exprimée en jours-homme, multipliée par un tarif journalier. Le prix affiché n’est que le résultat. Discuter le montant global sans toucher à ces deux facteurs revient à négocier une ombre.

Le second facteur, le tarif, varie peu. D’après le baromètre Malt 2026, un développeur mobile freelance affiche un tarif moyen de 551 euros par jour, contre environ 485 euros pour un développeur généraliste. L’amplitude entre un bon prestataire et un excellent prestataire dépasse rarement 40 pour cent.

Le premier facteur, lui, varie du simple au quadruple sur un même besoin décrit dans les mêmes mots. Toute la valeur d’une négociation se trouve là. Un acheteur qui sait recalculer la charge cesse de subir les devis et commence à arbitrer le périmètre.

Découper le besoin en unités réellement chiffrables

Personne ne sait estimer « une application de réservation ». Tout le monde sait estimer « un écran de choix de créneau, connecté à un agenda existant, avec gestion des annulations ». Le découpage précède le chiffre, sans exception.

Trois familles d’unités structurent un chiffrage sérieux :

• les parcours utilisateur menés de bout en bout, pas les écrans isolés ;
• les règles métier, c’est-à-dire les calculs, conditions et cas particuliers ;
• les échanges avec l’existant, chaque système tiers comptant pour lui-même.

Les postes que les devis courts escamotent

Le code représente rarement plus de la moitié de la charge. La conception d’interface, la recette fonctionnelle, le pilotage, la préparation des fiches boutique et les reprises après retours consomment le reste. Un devis qui affiche 30 jours de développement et rien d’autre ne coûte pas moins cher : il déplace simplement ces jours vers vos équipes ou vers un futur avenant.

La connexion aux logiciels déjà en place mérite une attention particulière. Quand aucun point d’échange moderne n’existe, la couche d’interface se construit avant l’application elle-même. Notre article sur le fonctionnement concret d’une API REST détaille ce que recouvre ce chantier intermédiaire, régulièrement sous-estimé au cadrage.

Estimer la charge sans se raconter d’histoires

Une estimation unique par lot est une prédiction, donc une illusion. Les méthodes éprouvées produisent plutôt une fourchette pondérée.

L’estimation en trois points, héritée de la technique PERT développée par l’US Navy en 1958, demande trois valeurs par lot : optimiste, probable, pessimiste. La charge retenue vaut alors la somme de l’optimiste, du pessimiste et de quatre fois la valeur probable, divisée par six. Le pessimiste pèse dans le résultat sans l’écraser.

Le planning poker complète l’exercice côté équipe. Chaque personne annonce simultanément sa valeur sur une échelle inspirée de la suite de Fibonacci, puis les écarts extrêmes s’expliquent avant un second tour. La discussion révèle les hypothèses divergentes, qui sont la vraie source des dérapages.

Le quatrième lot mérite un commentaire. Son écart entre optimiste et pessimiste, de un à cinq, signale une inconnue technique réelle. Un tel lot se traite par une étude courte facturée à part, avant l’engagement sur le reste.

Convertir les jours en euros avec le bon tarif

Le tarif dépend du profil et du mode de collaboration, pas de la complexité du projet. Les niveaux observés en France en 2026 se répartissent nettement.

Le tarif d’agence intègre des rôles qu’un tarif freelance exclut. Comparer 550 euros et 750 euros sans regarder ce que chacun couvre conduit systématiquement à choisir le devis le plus incomplet. Le bon réflexe consiste à ramener les deux propositions au même périmètre, quitte à ajouter des jours de pilotage interne côté freelance.

Un tarif nettement inférieur au marché mérite une question directe : quel profil intervient réellement, et qui relit son travail ? Une facture basse obtenue par un profil non encadré se paie en reprises, que le devis initial ne mentionne jamais.

Chiffrer une application de réservation, de bout en bout

Reprenons les quatre lots estimés plus haut : 48,4 jours de développement au total. Un projet réel ajoute la conception d’interface, comptez 8 jours, la recette fonctionnelle, 7 jours, le pilotage et les points de suivi, 6 jours, la préparation des fiches boutique et la publication, 3 jours. La charge complète atteint environ 72 jours-homme, cohérente avec les 60 à 90 jours régulièrement annoncés pour une première version publiée.

À 550 euros de tarif moyen pondéré, le calcul donne 39 600 euros. À 700 euros avec une agence assurant le pilotage complet, il monte à 50 400 euros. Deux montants éloignés de 27 pour cent, pour exactement le même produit livré.

Ce chiffre suppose une seule base de code servant les deux plateformes. Un développement natif séparé pour chaque système ajoute rarement 100 pour cent de charge, mais entre 40 et 70 pour cent sur la partie mobile, la conception et la partie serveur restant communes.

Les hypothèses qui doublent la charge sans changer une ligne du besoin

Deux chiffrages du même cahier des charges divergent presque toujours sur des hypothèses implicites, jamais écrites. Les expliciter avant la signature vaut mieux que les découvrir au troisième mois.

La première hypothèse porte sur la qualité des données existantes. Un chiffreur suppose des référentiels propres et exploitables. La réalité livre souvent des doublons, des champs libres et des formats hétérogènes, dont le nettoyage constitue un lot à part entière. Posez la question au cadrage : qui reprend les données, et sur combien de jours ?

La deuxième hypothèse porte sur la disponibilité côté client. Une estimation à 72 jours suppose un interlocuteur capable de trancher sous 48 heures. Avec un comité qui se réunit toutes les trois semaines, les mêmes 72 jours s’étalent sur un calendrier double et les reprises se multiplient. Le délai de décision appartient au coût, même s’il n’apparaît sur aucune ligne de devis.

La troisième hypothèse porte sur le niveau d’exigence attendu. Une application interne utilisée par quarante personnes tolère des imperfections qu’un public large sanctionne par une désinstallation immédiate. Accessibilité, comportement hors connexion, temps de démarrage et gestion des mises à jour se traduisent chacun en jours de recette supplémentaires. Situez le curseur avant de comparer les montants, sans quoi vous comparerez un prototype et un produit.

La quatrième hypothèse concerne la publication. Chaque soumission passe par une revue qui peut refuser l’application pour un motif administratif, du texte d’une page légale à la procédure de suppression de compte. Prévoir un premier dépôt de test très en amont retire ce risque calendaire du chemin critique, sans coûter plus d’un ou deux jours.

Trois tests pour vérifier un devis reçu

Le premier test porte sur l’unité. Un devis exprimé uniquement en euros globaux ne se vérifie pas. Demandez la charge en jours par lot, puis le tarif appliqué. Un prestataire sérieux fournit les deux sans hésiter.

Le deuxième test porte sur la couverture. Additionnez les jours des postes hors code. Sous 25 pour cent du total, le devis suppose que quelqu’un d’autre fera ce travail, et cette personne, c’est vous.

Le troisième test porte sur l’écart. Confrontez votre propre estimation en trois points à la sienne, lot par lot. Un écart de 20 pour cent traduit une hypothèse différente, discutable en réunion. Un écart de 200 pour cent traduit deux projets différents portant le même nom.

Ce que l’équation ne couvre jamais

La multiplication charge par tarif s’arrête à la livraison. La vie de l’application commence après, avec ses propres lignes budgétaires.

Les comptes de publication figurent parmi les plus prévisibles : le programme développeur d’Apple se facture 99 dollars par an, l’inscription chez Google Play représente un paiement unique de 25 dollars. Sur les ventes numériques réalisées dans l’application, les deux boutiques prélèvent 15 pour cent en dessous d’un million de dollars de revenus annuels, 30 pour cent au-delà. Un modèle économique reposant sur des abonnements intègre ce prélèvement dès le calcul de rentabilité.

S’ajoutent l’hébergement, la maintenance annuelle et les services tiers facturés à l’usage. Notre analyse des coûts réels d’une application d’entreprise détaille ces postes récurrents et leur poids sur trois ans. La même logique de vérification s’applique aux projets web : notre méthode d’audit technique d’un site repose sur le même principe, mesurer avant de payer.

Reste la question de l’usage réel. Financer vingt fonctionnalités dont trois seront ouvertes coûte plus cher que n’importe quel écart de tarif journalier. Un suivi d’usage sobre, branché dès la première version, transforme la deuxième estimation en décision documentée plutôt qu’en pari.

Prochaine étape : découpez votre besoin en lots, estimez chacun en trois points, multipliez par 550 euros. Vous obtiendrez en une heure une fourchette suffisamment solide pour lire n’importe quel devis avant de le signer.