Un devis application mobile sérieux ne tient pas sur une ligne « développement : 30 000 € ». Aquilapp montre d'ailleurs pourquoi deux offres apparemment comparables peuvent aller de 40 000 à 180 000 € selon le périmètre réellement inclus. Le bon réflexe n'est donc pas de choisir le total le plus bas, mais de vérifier ce que chaque ligne permet de livrer, de tester et de maintenir.
À retenir
- Exigez un périmètre fonctionnel, des hypothèses et des livrables vérifiables pour chaque poste.
- Séparez cadrage, UX/UI, mobile, backend, QA, publication et pilotage.
- Comparez les exclusions et les responsabilités, pas seulement les montants.
- Prévoyez la maintenance, les mises à jour des stores et une réserve pour les changements.
Les lignes indispensables d'un devis d'application mobile
Un devis utile traduit un produit en blocs de travail. Il doit permettre à une personne qui n'a pas participé aux échanges de comprendre ce qui sera construit, sur quelles plateformes et avec quel niveau de finition. Bercy rappelle que lorsqu'un prix exact ne peut pas être annoncé à l'avance, le prestataire doit au moins fournir une méthode de calcul vérifiable ou un devis suffisamment détaillé.
Le document commercial ne remplace pas le cahier des charges. Il doit toutefois en reprendre les décisions qui changent le prix : authentification, profils utilisateurs, paiement, notifications, mode hors ligne, géolocalisation, administration, intégrations tierces, reprise de données et exigences de sécurité.
Cadrage et conception fonctionnelle
Le cadrage transforme une idée en parcours et en critères d'acceptation. La ligne doit préciser le nombre d'ateliers, les profils interrogés, les livrables et le nombre d'allers-retours inclus. « Atelier produit » ne veut rien dire si personne ne sait si la sortie sera une liste d'écrans, un backlog priorisé ou une spécification exploitable par l'équipe technique.
Je préfère payer quelques jours de cadrage explicite plutôt que découvrir au milieu du développement que « connexion utilisateur » signifiait mot de passe pour le prestataire et SSO d'entreprise pour le client. Une hypothèse écrite coûte peu. Une hypothèse implicite devient souvent un avenant.
UX/UI et prototype
Demandez si le poste couvre les wireframes, la direction visuelle, les écrans définitifs, les états d'erreur, les variantes mobiles et le prototype cliquable. Le devis doit aussi indiquer si un design system existe déjà ou doit être créé.
Compter uniquement les écrans principaux sous-estime le travail. Un formulaire a des états vide, en cours, valide, invalide et hors connexion. Une liste a un chargement, une absence de résultat, une pagination et parfois plusieurs droits d'accès. Ces états font partie du produit.
Application, backend et intégrations
Le mot « application » masque souvent deux produits : le client mobile et les services qui gèrent les comptes, les données, les permissions et les notifications. Un chiffrage doit distinguer le développement iOS/Android, le backend, l'administration et chaque connexion à un service externe.
Le choix technique modifie aussi la structure de l'offre. Deux applications natives impliquent deux bases de code. Une approche multiplateforme avec React Native peut mutualiser une grande partie du travail, mais pas automatiquement les tests, les comportements propres à chaque système ni toutes les intégrations matérielles. Si ce choix est encore ouvert, demandez deux scénarios plutôt qu'un montant moyen impossible à défendre.
QA, stores et passage en production
Une application qui compile n'est pas une application prête à publier. La QA doit couvrir les appareils ciblés, les versions minimales d'iOS et Android, les cas limites, les performances, l'accessibilité utile et les tests de non-régression.
La publication doit être une ligne visible : préparation des fiches, captures, configuration des certificats, politique de confidentialité, comptes de démonstration et corrections demandées pendant la revue. Apple exige notamment que les fonctions soient décrites précisément et accessibles à son équipe de validation. Le compte éditeur, les certificats et les accès doivent appartenir au client.
Exemple de devis commenté pour une application mobile
Le tableau suivant est un modèle pédagogique, pas le prix d'un projet client. Il suppose un MVP B2B multiplateforme avec authentification, profils, catalogue, favoris, notifications, administration simple et API. Il sert à vérifier la forme d'un devis et la cohérence entre charges, livrables et exclusions.
| Poste | Charge indicative | Livrable à exiger | Question de contrôle |
|---|---|---|---|
| Cadrage produit | 5 à 8 jours | Backlog priorisé, parcours, hypothèses | Qui valide le périmètre et les critères d'acceptation ? |
| UX/UI | 10 à 15 jours | Maquettes, prototype, états d'erreur | Combien d'écrans et d'itérations sont inclus ? |
| Architecture et socle | 4 à 7 jours | Dépôts, environnements, CI/CD | Les comptes cloud et le code appartiennent-ils au client ? |
| Application React Native | 30 à 45 jours | App iOS et Android testable | Quelles fonctions restent spécifiques à chaque plateforme ? |
| Backend et administration | 20 à 30 jours | API, données, rôles, back-office | Les migrations, sauvegardes et journaux sont-ils inclus ? |
| QA et stabilisation | 10 à 15 jours | Plan de test, anomalies, recette | Quels appareils et versions sont couverts ? |
| Publication stores | 3 à 5 jours | Builds signés et fiches publiées | Les retours de revue sont-ils compris ? |
| Pilotage | 10 à 15 % de la charge | Démonstrations, suivi, arbitrages | Quelle fréquence de démonstration et quel interlocuteur ? |
SOURCE : modèle GoLive Software construit à partir d'un périmètre MVP illustratif. Il ne constitue pas un tarif contractuel.
Transformer les jours en prix comparable
Une fois la charge visible, le calcul devient contrôlable : nombre de jours multiplié par le TJM, puis ajout des licences, services tiers et frais fixes. Pour une équipe au forfait, demandez malgré tout les hypothèses de charge. Sans elles, vous ne pourrez pas comparer une offre qui inclut la QA et le pilotage avec une autre qui les facture après signature.
Le prix final dépend surtout du nombre de parcours, des rôles, des intégrations et du niveau de risque technique. Aquilapp donne une fourchette générale de 8 000 à plus de 250 000 € selon la complexité et estime la maintenance annuelle à 15 à 20 % du coût initial. Ce sont des repères de marché publiés par un prestataire, pas un barème. Utilisez-les pour détecter un écart qui mérite une explication, jamais pour remplacer votre propre chiffrage.
La vidéo d'AppCreative sur le coût d'une application insiste sur le même point : le frontend, le backend et les tests consomment chacun un travail incompressible. Sa fourchette de 30 000 à 70 000 dollars concerne son propre cadre commercial. Le signal utile n'est pas la conversion en euros, mais la nécessité de savoir quels blocs sont financés.
Comparer deux offres sans se tromper de colonne
Normalisez les devis dans un tableau unique. Replacez chaque montant dans les mêmes catégories et marquez « inclus », « exclu » ou « non précisé ». Une offre à 35 000 € sans backend, migration de données ni publication peut être plus chère qu'une offre à 48 000 € qui livre le produit exploitable.
Comparez aussi le calendrier et la composition réelle de l'équipe. Dix semaines avec un senior stable ne sont pas équivalentes à dix semaines avec plusieurs profils qui se relaient. Pour vérifier une agence, utilisez les critères de notre article sur le prix d'une agence de création d'application mobile et demandez les noms, rôles et disponibilités avant la signature.
Les pièges du devis et mon verdict avant signature
Le premier piège est le périmètre flou. Des discussions Reddit entre développeurs comparent l'estimation d'une « app simple » à la question « combien coûte une maison ? ». Ce n'est pas une statistique, mais le signal terrain est juste : sans fonctionnalités, contraintes et niveau de qualité, une estimation précise donne une fausse impression de maîtrise.
Le deuxième piège est le faux forfait. Si le document exclut toutes les décisions encore ouvertes, le prix affiché ne couvre que la version la plus favorable du projet. Les changements arriveront forcément, mais sans règle de chiffrage. Prévoyez un mécanisme simple : estimation écrite, validation avant exécution et suivi séparé du budget de changement.
Le troisième piège est d'oublier l'après-publication. Les développeurs interrogés sur Reddit rappellent qu'une application n'est jamais vraiment terminée : les systèmes évoluent, les dépendances doivent être mises à jour et les retours utilisateurs créent de nouveaux besoins. Là encore, c'est un retour de communauté, pas une mesure de marché. Il confirme cependant qu'un devis initial doit distinguer garantie corrective, maintenance technique et évolutions produit.
Les exclusions à faire écrire noir sur blanc
Vérifiez au minimum les contenus, traductions, données initiales, abonnements tiers, frais des stores, matériel de test, conformité juridique, pentest, migration, hébergement, support, analytics et maintenance. Une exclusion n'est pas forcément mauvaise. Une exclusion découverte trop tard l'est presque toujours.
Ajoutez les conditions de recette, la propriété intellectuelle, l'accès au dépôt, la propriété des comptes, les sauvegardes et la réversibilité. Le devis accepté engage les parties sur l'étendue, la durée et le coût annoncés. Les zones importantes doivent donc apparaître dans le devis, le contrat ou une annexe explicitement liée.
Mon verdict
Je ne signerais pas un devis d'application mobile qui ne permet pas de répondre à trois questions : qu'est-ce qui sera démontrable toutes les une à deux semaines, qui possède les actifs techniques, et combien coûte un changement de périmètre ? Un total bas sans ces réponses n'est pas une économie. C'est un risque déplacé après la signature.
Pour un projet dont les fonctions sont encore mouvantes, je préfère une courte phase de cadrage payée, puis un premier lot réversible. Pour un périmètre stable, le forfait peut fonctionner si les critères d'acceptation et les exclusions sont précis. Si vous envisagez une équipe au Vietnam, notre retour sur le choix d'une agence React Native au Vietnam complète l'analyse du devis par les questions de séniorité, communication et pilotage.
FAQ
Combien coûte un devis d'application mobile ?
L'établissement du devis peut être gratuit ou intégré à une phase de cadrage payée. Pour un produit complexe, un cadrage payant est souvent plus honnête qu'une estimation commerciale faite après un appel. Demandez ce que vous pourrez réutiliser si vous ne poursuivez pas : backlog, maquettes, architecture et estimation détaillée.
Quelle marge d'imprévu prévoir dans le budget ?
Prévoyez une réserve séparée pour les décisions découvertes pendant le projet, sans la cacher dans chaque ligne. Le bon niveau dépend de la maturité du besoin, des intégrations et de l'existant. Une réserve ne dispense pas de faire valider chaque changement avant de le développer.
Faut-il choisir un forfait ou une régie ?
Choisissez le forfait quand le périmètre et les critères d'acceptation sont stables. Choisissez la régie quand vous voulez arbitrer le produit au fil des retours. Dans les deux cas, exigez une démonstration régulière, un suivi de charge et une personne clairement responsable du résultat.
Comment savoir si deux devis couvrent vraiment la même application ?
Reclassez les deux offres poste par poste : cadrage, UX/UI, mobile, backend, administration, intégrations, QA, publication, pilotage et maintenance. Comparez ensuite les hypothèses, exclusions, appareils couverts, livrables et responsabilités. Les deux totaux ne sont comparables qu'après cette normalisation.
Vidéos YouTube
Discussions Reddit
- How much do you charge for a mobile app? - Reddit r/reactnative
- How much does mobile app development cost? - Reddit r/webdev
