Prix application mobile : comprendre le budget avant le devis.

À la question « combien coûte la création d’une application », une réponse utile commence par le type de produit et le périmètre livré. Dans la grille publique de Sirocco, une application mobile iOS et Android, du MVP à l’application complète, se situe entre 25 000 et 120 000 € HT par projet. Il s’agit d’une fourchette indicative, en cours de validation. Le montant ferme dépend d’un cadrage et d’un devis.

La même grille distingue trois repères voisins. Une application web, un portail client ou une plateforme métier se situe entre 15 000 et 90 000 € HT par projet. Un MVP de SaaS prêt à accueillir ses premiers clients se situe entre 25 000 et 80 000 € HT par projet. La TMA couvre la maintenance corrective, évolutive et la supervision d’une application entre 800 et 5 000 € HT par mois. Toutes ces fourchettes sont indicatives, en cours de validation.

Ces montants ne s’additionnent pas automatiquement. Une interface mobile, un espace web et un back-office peuvent partager une base de données, une authentification et des services côté serveur. À l’inverse, une application apparemment simple peut exiger des règles métier, des droits et des connexions qui représentent une part importante du travail. La comparaison pertinente porte donc sur les livrables, les hypothèses et les responsabilités, pas uniquement sur le total affiché.

Pour situer votre projet, commencez par décrire l’utilisateur, l’action qu’il doit accomplir, les informations nécessaires et le résultat attendu. Ajoutez ensuite les exceptions : donnée absente, droit insuffisant, service tiers indisponible ou appareil sans réseau. Ce périmètre permet de comprendre pourquoi deux applications ayant un nombre d’écrans proche peuvent relever de budgets très différents.

Le prix développement application augmente avec la diversité des comportements à construire et à vérifier. Le nombre d’écrans donne un premier indice, mais il ne décrit ni les règles, ni les erreurs, ni les droits. Un écran de paiement relié à une commande et à une facture demande généralement plus de conception et de tests qu’une suite de pages informatives.

• Plateformes : iOS, Android et navigateur ont leurs propres comportements, formats et contrôles. Une base de code partagée réduit certaines reprises, sans supprimer les vérifications sur chaque environnement.
• Écrans et parcours : l’effort dépend du nombre d’actions complètes, de leurs variantes et des cas d’échec, pas seulement du nombre de vues dessinées.
• Comptes et rôles : inscription, invitation, récupération d’accès, administration et permissions exigent des règles explicites. Chaque rôle supplémentaire ajoute des situations à contrôler.
• Paiement : un paiement en ligne ajoute un module, des états de commande, des retours d’erreur et des échanges avec un prestataire financier.
• Back-office : la gestion des comptes, contenus, commandes ou incidents demande une interface distincte et des droits d’administration.
• Intégrations : CRM, ERP, annuaire, cartographie ou gestion documentaire impliquent des accès, des formats, des limites et une stratégie en cas d’indisponibilité.

Le niveau de conception visuelle, le multilingue et les exigences d’accessibilité modifient également le travail. Une interface adaptée à une charte existante ne demande pas les mêmes recherches qu’un système graphique entièrement défini pour le produit. Plusieurs langues ajoutent des contenus, des formats locaux et des cas de mise en page à tester.

Ces facteurs doivent être décrits en mots dans le devis. Une mention générale telle que « comptes utilisateurs inclus » ne suffit pas : demandez quels rôles, quelles actions et quelles procédures sont couvertes. Cette précision transforme une option abstraite en périmètre vérifiable pendant la recette.

Certaines fonctions élargissent le travail au-delà des écrans visibles. Une fonction d’IA ajoute le choix du modèle, la préparation du contexte, les contrôles humains, les journaux et le suivi des coûts d’usage. Un assistant qui propose un texte n’a pas les mêmes exigences qu’un agent autorisé à déclencher une action. Plus l’autonomie est grande, plus les droits, les confirmations et la reprise d’une erreur doivent être documentés.

Le mode hors ligne demande de définir ce qui reste accessible sans réseau, ce qui peut être modifié et comment les changements sont synchronisés ensuite. Il faut traiter les conflits lorsque deux personnes modifient la même donnée, la protection des informations conservées sur l’appareil et les messages affichés tant que l’envoi n’est pas confirmé. Une simple case « hors connexion » masque donc plusieurs décisions de produit et d’architecture.

La sécurité intervient dans l’authentification, les permissions, le stockage local, les échanges avec le serveur, la journalisation et la suppression des données. Le niveau attendu dépend de l’usage et des informations traitées. Le devis doit distinguer les contrôles intégrés au développement, les revues spécifiques et les audits externes éventuels. Il doit aussi préciser qui fournit les règles de conservation et qui valide les accès.

La publication sur les stores comprend les comptes de diffusion, les certificats, les informations de présentation, les versions de test et le traitement des demandes formulées lors de la revue. Le titulaire des comptes doit être nommé. Les visuels, textes, déclarations liées aux données et procédures de nouvelle version doivent figurer dans les responsabilités, même lorsqu’ils sont préparés par votre équipe.

Ces sujets doivent être décidés assez tôt pour influencer le produit. Les ajouter juste avant la mise en ligne crée des reprises et rend le calendrier moins prévisible. Un cahier des charges d’application aide à consigner les droits, les dépendances, les critères de recette et les personnes responsables de chaque validation.

Un devis application mobile devient comparable lorsqu’il relie chaque montant à un périmètre. Le document doit décrire les parcours, les rôles, les plateformes, les intégrations, les livrables et les conditions de validation. Il doit aussi rendre visibles les informations encore inconnues. Une hypothèse écrite peut être discutée ; une hypothèse implicite devient souvent un désaccord pendant le projet.

Comparez ensuite les propositions à périmètre égal. Une offre moins élevée peut exclure la reprise de données, le back-office, la publication, les tests sur appareils ou la maintenance. Une offre plus élevée peut inclure une phase de conception, une migration et une documentation absentes ailleurs. Le total ne permet pas de conclure tant que ces différences ne sont pas alignées.

Vérifiez enfin la gestion des changements. Le devis doit expliquer comment une demande nouvelle est décrite, chiffrée, acceptée et ajoutée au calendrier. Consultez la page tarifs pour retrouver les fourchettes publiques, puis l’article sur le prix d’un logiciel sur mesure si votre besoin dépasse l’application mobile et concerne un système métier plus large.

Réduire le budget application mobile ne consiste pas à retirer quelques écrans au hasard. Le levier le plus solide est de conserver un parcours complet pour un usage prioritaire. Une personne identifiable doit pouvoir partir d’une situation réelle, effectuer l’action prévue et constater le résultat. Les fonctions secondaires peuvent attendre si leur absence ne bloque pas ce parcours.

1. Choisissez un besoin principal : une demande à transmettre, une intervention à documenter, une information à consulter ou une décision à valider.
2. Limitez les rôles initiaux : commencez par les personnes indispensables, avec des droits simples et contrôlables.
3. Réutilisez les services disponibles : identité, paiement, stockage ou données métier peuvent parfois s’appuyer sur un système déjà exploité, si ses interfaces sont adaptées.
4. Reportez les variantes : personnalisation avancée, second canal, tableaux détaillés ou automatisations périphériques peuvent suivre après les premiers usages.
5. Assumez les tâches provisoires : une opération manuelle clairement attribuée vaut mieux qu’une automatisation fragile ajoutée uniquement pour compléter une liste.

La réutilisation doit rester explicite. Employer un service existant évite de reconstruire une fonction, mais ajoute une dépendance, un contrat et parfois un coût d’usage. Vérifiez l’accès aux données, la documentation, les limites et la possibilité de changer de fournisseur. Une intégration mal connue peut coûter davantage qu’un module simple dont le comportement est maîtrisé.

Le MVP sert à vérifier un usage, pas à présenter une version incomplète de toutes les idées. Définissez les critères qui permettront de décider la suite : parcours accompli, erreurs observées, demandes récurrentes et contraintes découvertes. Cette discipline aide à investir dans les évolutions justifiées et à écarter celles qui ne répondent à aucun besoin constaté.

Le coût de construction n’est qu’une partie du budget. Après la mise en ligne, l’application dépend des systèmes mobiles, de services tiers, d’un hébergement et de données qui continuent d’évoluer. La grille publique de Sirocco situe la TMA entre 800 et 5 000 € HT par mois pour la maintenance corrective, évolutive et la supervision d’une application. Cette fourchette est indicative, en cours de validation.

• Maintenance corrective : investigation et correction d’un comportement qui ne respecte pas le périmètre accepté.
• Maintenance évolutive : modification d’un parcours, ajout d’une règle ou adaptation à un nouveau besoin.
• Compatibilité : mises à jour liées à iOS, Android, aux bibliothèques, aux appareils et aux exigences des stores.
• Exploitation : hébergement, sauvegardes, supervision, journaux, alertes et traitement des incidents.
• Services facturés à l’usage : paiement, cartographie, SMS, courriels, stockage, authentification ou modèles d’IA.

Demandez ce que couvre le contrat de suivi : horaires, délai de prise en compte, surveillance, volume de changements et procédure en cas d’incident. Une garantie de correction après livraison n’est pas équivalente à une maintenance continue. Les responsabilités de votre équipe comptent également : administration des comptes, mise à jour des contenus, validation des versions et réponse aux utilisateurs.

Prévoyez enfin la transmission. La documentation, le dépôt de code, les accès et les procédures de déploiement doivent permettre à une autre équipe de comprendre le produit. Cette réversibilité protège la continuité et facilite la comparaison entre une évolution, une reprise technique ou un changement de prestataire.

Avant de demander un prix ferme, rassemblez les informations qui changent réellement le chiffrage. Décrivez le parcours principal, les utilisateurs, les plateformes, les systèmes à connecter et les contraintes de sécurité. Joignez des exemples anonymisés de données et indiquez les inconnues plutôt que de les masquer. Un prestataire peut alors séparer ce qui est confirmé, ce qui doit être conçu et ce qui dépend d’un tiers.

Pour un besoin mobile, préparez aussi la diffusion : organisation titulaire des comptes de store, personnes habilitées à publier, langues, appareils visés et mode hors ligne éventuel. Pour un produit vendu en ligne, ajoutez la logique des organisations, des rôles, des formules et du paiement. Pour un outil interne, précisez l’annuaire, les règles d’accès, l’administration et les systèmes qui font foi.

Si votre sujet comporte une fonction d’IA, le diagnostic de maturité IA aide à examiner les données, la gouvernance, les compétences et les risques. Il ne calcule pas le prix d’une application ; il structure les conditions nécessaires pour décider si un cas d’usage mérite un cadrage plus approfondi.

Terminez votre demande par la décision attendue. Cherchez-vous à choisir entre mobile et web, à définir un MVP, à comparer deux architectures ou à obtenir un devis sur un périmètre déjà documenté ? Cette indication aide l’interlocuteur à proposer une étape proportionnée. Vous pouvez ensuite présenter votre projet à Sirocco avec les éléments disponibles, sans prétendre que toutes les questions sont déjà résolues.

Un budget sérieux reste lisible lorsque le projet change. Conservez une version datée du périmètre, des hypothèses et des exclusions. Chaque nouvelle décision peut alors être reliée à son effet sur la conception, le développement, les tests et l’exploitation, au lieu de modifier silencieusement le montant initial.