Estimateur

Situer le budget de votre application

Répondez aux huit questions, puis lancez le calcul. Tout se passe dans votre navigateur : aucune donnée n'est envoyée ni enregistrée.

C'est ce choix qui fixe le socle de l'estimation.

Comptez les parcours complets, pas les écrans.

Deux populations impliquent presque toujours un back-office en plus.

Chaque plateforme ajoute du développement, des tests et de la maintenance.

La reprise de données est le poste le plus souvent sous-estimé.

CRM, ERP, paie, facturation, outil métier historique.

Santé, finance, secteur public, données sensibles.

Le pilotage et le cadrage restent en France dans les deux cas.

Le résultat s'affichera ici, sous la forme d'une fourchette de budget de développement et d'un coût annuel de maintenance.

Comment le calcul est construit

Le socle vient des fourchettes que je publie dans mon guide sur le prix d'une application : 30 000 à 80 000 € Pour une plateforme riche, mes repères publiés donnent un seuil de départ sans plafond : l'outil affiche donc un plancher, pas une fourchette haute. Au-delà de ce montant, le chiffrage dépend entièrement du périmètre retenu et se construit au cadrage.

La configuration de référence, celle où le résultat vaut exactement la fourchette publiée, est : 5 à 10 parcours, usage interne, web uniquement, aucune reprise de données, aucune intégration, aucune contrainte particulière, équipe en France. Les autres réponses ajoutent des points de pourcentage à ce socle :

  • Parcours utilisateur : -10 % en dessous de 5, +25 % de 10 à 20, +50 % au-delà de 20.
  • Utilisateurs : +10 % pour des clients externes, +20 % pour les deux populations.
  • Plateformes : +25 % pour web et mobile, +50 % pour deux applications natives.
  • Données : +10 % pour une reprise, +25 % pour une migration de plusieurs systèmes.
  • Intégrations : +10 % pour une ou deux, +25 % pour plusieurs systèmes critiques.
  • Contraintes : +10 % pour du RGPD, +25 % pour un secteur réglementé.
  • Offshore encadré : facteur 0,80 appliqué au total, et non une division par deux ou par trois.

Comment cette estimation est calculée

Cette estimation part des fourchettes que je constate sur les projets d'application sur-mesure : 30 000 à 80 000 € pour un premier périmètre resserré, 80 000 à 250 000 € pour une application complète, davantage pour une plateforme riche. Vos huit réponses ajustent ce socle avec des coefficients affichés en clair dans le détail du résultat, plutôt que dans une boîte noire. Le calcul s'exécute dans votre navigateur, sans inscription et sans que rien ne soit transmis.

J'ai construit cet outil parce que la question du budget arrive presque toujours trop tard dans les projets, une fois que des attentes se sont installées. Avoir un ordre de grandeur avant de rédiger un cahier des charges change la conversation : on arbitre le périmètre en connaissance de cause au lieu de découvrir l'écart à la réception des devis.

Ce que l'estimateur ne peut pas deviner

Huit questions décrivent la forme d'un projet, pas sa matière. Ce qui déplace le plus un chiffrage, dans mon expérience, reste hors de portée d'un formulaire.

  • La complexité des règles de gestion. Deux applications avec le même nombre d'écrans peuvent demander un travail du simple au triple selon les règles de calcul, les statuts, les droits par profil et les cas particuliers hérités de votre métier. C'est le premier facteur d'écart, et il ne se déclare pas en une réponse.
  • La qualité de vos données existantes. Reprendre une base propre et documentée n'a rien à voir avec reprendre vingt ans de saisies libres, de doublons et de champs détournés de leur usage.
  • La disponibilité de vos équipes. Un projet avance à la vitesse des décisions. Sans interlocuteur métier disponible pour trancher, les délais s'allongent et le coût de pilotage grimpe.
  • Le niveau de design attendu. Une interface d'outil interne et une expérience travaillée écran par écran pour des clients ne se chiffrent pas de la même façon.
  • Le degré de finition à la livraison. Une recette sérieuse, des tests automatisés, une documentation et une reprise en main par vos équipes représentent une part réelle du budget, souvent la première rognée quand un devis doit rentrer dans une enveloppe.

Ces angles morts sont exactement ce qu'un cadrage sert à lever. C'est aussi la raison pour laquelle je conseille de commencer petit, avec un MVP qui met le produit entre les mains d'utilisateurs réels avant d'engager le gros du budget.

Pourquoi le coût de départ n'est pas le coût total

Le montant du développement est la ligne visible, et c'est presque toujours la seule que l'on compare. Avec une maintenance de 15 à 20 % par an, trois ans d'exploitation ajoutent déjà de l'ordre de la moitié du budget initial, avant même l'hébergement et les évolutions. Une application est un logiciel vivant : elle se maintient, s'héberge et évolue, sinon elle se dégrade toute seule.

Les postes récurrents à budgéter dès le cadrage
PosteNatureCe que j'en dis
Maintenance applicative Annuel Repère couramment admis de l'ordre de 15 à 20 % du coût initial par an. C'est ce que l'estimateur affiche sous la fourchette.
Hébergement et infrastructure Mensuel Croît avec le nombre d'utilisateurs et le volume de données. Négligeable au départ, structurant à l'échelle.
Comptes développeurs Annuel et ponctuel Compte Apple Developer à 99 $ par an et inscription Google Play à 25 $ une fois, si vous publiez sur les stores.
Évolutions fonctionnelles Selon les usages À prévoir dès la première année. Un produit qui rencontre ses utilisateurs génère des demandes, c'est bon signe.
Pilotage Pendant le projet Le pilotage par un profil senior se chiffre sur devis, et se rembourse sur les dérives évitées.

Le bon réflexe est de raisonner en coût sur trois ans plutôt que sur la seule ligne du devis initial. Le contrat qui porte cette dépense s'appelle souvent une TMA, et ce qu'il couvre exactement mérite d'être lu de près : j'en détaille les familles dans mon guide sur la maintenance d'une application.

Comment lire un devis à la lumière de ce résultat

Une fois la fourchette obtenue, elle sert de grille de lecture. Quand vous recevez des propositions, quatre réflexes suffisent à voir où sont les vrais écarts.

  • Un devis nettement sous la fourchette n'est pas une bonne affaire. C'est presque toujours le signe d'un périmètre plus étroit que celui que vous avez en tête, ou d'une recette et d'une reprise de données réduites à la portion congrue. Demandez ce qui est explicitement exclu, la réponse est plus instructive que le total.
  • Un devis nettement au-dessus mérite la même question, à l'envers. Il inclut peut-être des postes que les autres ont omis, ce qui en fait le seul chiffrage honnête du lot. Comparez les lignes, pas les totaux.
  • Vérifiez le mode de facturation. Un forfait et une régie ne portent pas le même risque et ne se comparent pas directement. La distinction est détaillée dans ma fiche régie ou forfait.
  • Cherchez la ligne maintenance. Un devis qui ne mentionne ni garantie, ni maintenance, ni réversibilité vous laisse le coût réel à découvrir l'année suivante.

Si les propositions que vous recevez s'écartent fortement les unes des autres, ce n'est pas un problème de tarif mais de périmètre implicite. C'est ce que règle un cahier des charges écrit, et c'est le travail que je fais en amont sur les projets que j'accompagne.

L'approche de Laurent. Je ne chiffre jamais une application au doigt mouillé, et cet outil ne le fait pas davantage : il situe un ordre de grandeur pour que vous entriez dans la discussion avec des repères. Le vrai chiffre sort d'un cadrage, quand le périmètre est écrit et que les arbitrages entre ce qui crée de la valeur et ce qui peut attendre ont été posés.

Discuter du budget de votre application

Questions fréquentes

Non. L'estimateur donne un ordre de grandeur, pour savoir dans quel palier de budget votre projet se situe et pour préparer vos échanges avec des prestataires. Un devis engage un prestataire sur un périmètre écrit, ligne par ligne, après un cadrage qui pose les règles de gestion, les cas limites et les critères de recette. Ce sont deux exercices différents : le premier oriente une décision d'investissement, le second engage une exécution.
Parce qu'un montant unique donnerait une fausse impression de précision. Huit questions ne suffisent pas à décrire les règles de gestion d'une application, et à ce stade l'écart réel entre deux chiffrages sérieux tient au périmètre implicite, pas au tarif du prestataire. Une fourchette rend visible cette incertitude au lieu de la masquer. Elle se resserre à mesure que le cahier des charges se précise.
Non. Le coût horaire d'une équipe offshore encadrée est couramment 2 à 3 fois inférieur à celui d'une équipe en France, mais ce rapport ne s'applique qu'aux heures de développement effectivement délocalisées. Le cadrage, la conception, le pilotage, la recette et la relation métier restent en France, et l'écriture des spécifications doit être plus poussée qu'en local. C'est pourquoi l'estimateur applique une réduction prudente de 20 % sur le total, et non une division par deux.
Laurent Tulpan

À propos de l'auteur

Laurent Tulpan

Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il chiffre et arbitre des budgets d'application depuis vingt ans, et a construit cet estimateur avec les repères qu'il utilise en cadrage. Découvrir son approche.

À lire ensuite