Le prix d'une application mobile est la première question posée, et la plus mal posée : sans périmètre, aucun chiffre n'a de sens. Ce tutoriel vous donne une méthode en 5 étapes pour estimer vous-même un budget réaliste, comprendre ce qui le fait varier et comparer des devis sur des bases saines.
Pourquoi les prix annoncés varient autant
Deux devis pour « la même application » peuvent aller du simple au quintuple. Ce n'est pas toujours de la mauvaise foi : chaque prestataire a compris un périmètre différent. L'un a chiffré trois écrans branchés sur un fichier, l'autre une application hors ligne synchronisée avec votre ERP, un back-office et des tests sur une dizaine de téléphones.
Le prix d'une application mobile dépend en réalité de quatre familles de facteurs :
- Le nombre de parcours et d'écrans que l'utilisateur doit traverser ;
- La complexité technique de chaque fonctionnalité (hors ligne, caméra, géolocalisation, paiement) ;
- Les intégrations avec vos outils existants (CRM, ERP, annuaire, outil de facturation) ;
- Tout ce qui entoure le code : back-office, tests, publication, hébergement et maintenance.
La méthode qui suit consiste à rendre ces quatre familles visibles, ligne par ligne.
Étape 1 : décrire les parcours, pas les fonctionnalités
Une liste du type « gestion des clients, gestion des commandes, notifications » ne se chiffre pas. Partez plutôt des parcours concrets : qui ouvre l'application, pour faire quoi, et dans quel ordre.
Par exemple : « le commercial ouvre la fiche client, consulte l'historique, saisit une commande, la fait signer sur l'écran et l'envoie à l'ADV ». Ce parcours révèle immédiatement les écrans (fiche, historique, saisie, signature), les données nécessaires et l'intégration attendue. Visez un tableau simple : une ligne par écran, avec son rôle et les données affichées ou saisies.
Si vous avez déjà rédigé un cahier des charges, cette étape revient à le traduire en écrans. Sinon, une heure d'atelier avec deux futurs utilisateurs suffit souvent à poser la première version.
Étape 2 : classer chaque écran par niveau de complexité
Attribuez à chaque ligne un niveau : simple (affichage d'une liste, formulaire classique), moyen (recherche, filtres, photo, carte) ou complexe (fonctionnement hors ligne avec synchronisation, scan de codes-barres en série, paiement, calculs métier, signature à valeur probante).
Quelques fonctionnalités pèsent systématiquement plus lourd qu'on ne l'imagine :
- Le mode hors ligne : il impose de stocker les données sur le téléphone et de gérer les conflits au retour du réseau ;
- Les intégrations : une API documentée se branche vite, un logiciel ancien sans API peut exiger un connecteur dédié ;
- Les rôles et droits : chaque profil d'utilisateur multiplie les cas à tester ;
- Les notifications : simples à envoyer, plus délicates à fiabiliser et à cibler.
Ce classement est la base de l'estimation : votre prestataire convertit ensuite chaque niveau en jours de travail.
Étape 3 : choisir le socle technique et les plateformes
Le même périmètre ne coûte pas la même chose selon la manière de le construire. Deux applications natives (une pour iPhone, une pour Android) représentent deux bases de code à développer et à maintenir. Un framework multiplateforme comme Flutter ou React Native mutualise l'essentiel du code. Une application web progressive (PWA) peut suffire quand les besoins matériels sont modestes.
Posez-vous trois questions : vos utilisateurs sont-ils tous sur le même système (flotte de téléphones fournie par l'entreprise) ? Avez-vous besoin de capteurs avancés comme le Bluetooth ou le NFC ? L'application doit-elle être publiée sur les stores publics ou seulement diffusée en interne ? Les réponses orientent le socle, donc une part importante du prix.
Étape 4 : ajouter les postes que l'on oublie
C'est là que la plupart des budgets dérapent. Les écrans visibles ne représentent qu'une partie du travail. Ajoutez systématiquement :
- Le back-office et l'API : l'application doit lire et écrire ses données quelque part, et quelqu'un doit pouvoir les administrer ;
- Le design des interfaces : maquettes, charte, adaptation aux tailles d'écran et à l'accessibilité ;
- Les tests : sur plusieurs modèles et versions de système, puis la recette avec vos utilisateurs ;
- La gestion de projet : ateliers, points de suivi, arbitrages ;
- Les comptes de publication : l'Apple Developer Program coûte 99 dollars par an, avec une exonération possible sur demande pour les associations, établissements d'enseignement et entités publiques ; l'inscription à la Google Play Console se règle une seule fois, 25 dollars ;
- L'hébergement du serveur et de la base de données, ainsi que les services tiers éventuels (cartographie, envoi de SMS, stockage de photos).
Étape 5 : raisonner en coût sur trois ans
Une application mobile n'est jamais terminée. Apple et Google publient chaque année une nouvelle version de leur système, et Google Play impose de cibler une version récente d'Android pour continuer à publier des mises à jour. Les bibliothèques utilisées évoluent, des failles sont corrigées, vos utilisateurs demandent des améliorations.
Pour comparer des options honnêtement, additionnez donc :
- le coût de construction initial ;
- la maintenance annuelle (compatibilité système, sécurité, corrections) ;
- les évolutions prévisibles (un deuxième lot de fonctionnalités, souvent dès la première année) ;
- les frais récurrents (hébergement, comptes, services tiers).
Une option moins chère au départ mais coûteuse à maintenir, comme deux bases de code natives pour une petite équipe, peut se révéler la plus onéreuse sur trois ans.
Comparer des devis et réduire la facture
Votre tableau d'écrans devient votre meilleur outil de négociation. Envoyez-le à chaque prestataire consulté et demandez un devis d'application mobile détaillé par ligne. Vérifiez ensuite quatre points : les hypothèses retenues (hors ligne inclus ou non, nombre de plateformes), la propriété du code source, le contenu exact de la recette et les conditions de maintenance après livraison.
Pour alléger le budget sans sacrifier l'essentiel, la piste la plus efficace reste de commencer petit : une première version centrée sur le parcours qui apporte le plus de valeur, mise entre les mains des utilisateurs, puis enrichie au vu de leurs retours. C'est le principe d'un MVP ou prototype rapide, qui transforme une grosse dépense incertaine en plusieurs lots maîtrisés.
Un bon chiffrage ne se juge pas à son montant, mais à la clarté de ses hypothèses : si vous ne savez pas ce qui est inclus, vous ne savez pas ce que vous payez.
Questions fréquentes
Peut-on connaître le prix d'une application mobile sans cahier des charges ?
Seulement sous forme de fourchette très large. Une liste d'écrans classés par complexité, même rédigée en une heure, suffit en revanche à obtenir une estimation exploitable et des devis comparables.
Une application multiplateforme coûte-t-elle vraiment moins cher ?
En général oui, car l'essentiel du code est partagé entre iPhone et Android, à la construction comme en maintenance. Le natif reste pertinent pour des besoins matériels pointus ou des performances exigeantes.
Quels frais récurrents prévoir après la mise en ligne ?
Le compte Apple Developer (99 dollars par an, exonération possible pour les associations et entités publiques), l'hébergement du serveur, les services tiers et une maintenance annuelle pour suivre les nouvelles versions d'iOS et d'Android.
Comment réduire le budget de son application mobile ?
En limitant la première version au parcours le plus utile, en évitant le hors ligne s'il n'est pas indispensable et en réutilisant les API de vos outils existants plutôt qu'en ressaisissant les données.
Faut-il publier l'application sur les stores publics ?
Pas forcément. Une application réservée à vos équipes peut être diffusée en interne, ce qui simplifie la validation et la confidentialité, mais le compte développeur reste nécessaire côté Apple.
Vous avez une idée d'application et souhaitez un chiffrage clair, ligne par ligne ? Parlons de votre projet : nous vous aidons à cadrer le périmètre et à estimer un budget réaliste.