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.
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.
| Poste | Nature | Ce 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.
Questions fréquentes
À 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
Le prix d'une application
Les six leviers qui font varier un devis, et les fourchettes qui servent de socle à cet estimateur.
Construire un MVP
Comment réduire le périmètre de départ sans vider le produit de sa valeur.
La maintenance d'une application
Ce que recouvre la ligne annuelle affichée sous la fourchette.
Les délais d'un projet d'application
Le pendant calendaire de cette estimation, phase par phase.