1. Le périmètre fonctionnel
Le nombre d’écrans et de règles métier. Un catalogue consultable n’a rien à voir avec une place de marché où l’on paie, discute et note.
Il n’existe pas de tarif unique : le coût d’une application dépend de son périmètre fonctionnel, de la technologie retenue et du backend nécessaire. Cette page explique ce qui fait réellement varier la facture, pour que vous puissiez lire un devis — le nôtre ou celui d’un autre.
Ce sont eux qui expliquent qu’un même « projet d’application » puisse être chiffré du simple au décuple.
Le nombre d’écrans et de règles métier. Un catalogue consultable n’a rien à voir avec une place de marché où l’on paie, discute et note.
Dès qu’il y a des comptes, de la synchronisation ou des notifications, il faut un serveur, une base de données et une interface d’administration. C’est souvent la moitié du travail.
Deux applications natives, c’est deux développements et deux maintenances. Une base de code commune divise sensiblement le coût, quand le projet s’y prête.
Reprendre une charte existante coûte peu. Concevoir une identité, des parcours et un système de composants complet est un poste à part entière.
Paiement, facturation, logiciel de gestion, cartographie, signature électronique : chaque connexion à un système tiers demande développement et tests.
RGPD, accessibilité, secteur santé ou finance, hébergement souverain : la conformité se conçoit dès le départ, elle ne se rajoute pas à la fin.
Un devis nettement moins cher qu’un autre ne couvre presque jamais le même périmètre. Voici les postes que l’on retrouve le plus souvent absents, et qui reviennent ensuite en avenant.
Ils s’ajoutent à toute prestation, quel que soit le prestataire, et sont souvent oubliés des budgets.
Un budget contraint n’oblige pas à livrer un produit bâclé. Il oblige à choisir. Voici comment nous procédons, et ce sur quoi nous refusons de rogner.
La première version n’a pas besoin de tout. Sortez avec ce qui porte la valeur, observez ce que les gens utilisent réellement, puis investissez là-dessus. La plupart des applications comportent des écrans que personne n’ouvre jamais.
Publier d’abord sur une seule plateforme, ou d’abord une application web, permet de valider le besoin à moindre coût. On ajoute la seconde quand la première a fait ses preuves.
S’appuyer sur les composants standard d’iOS et d’Android donne un résultat sobre et familier pour un coût nettement inférieur à une identité entièrement conçue.
Sécurité, gestion des comptes, sauvegardes, tests. Économiser dessus ne fait pas baisser le coût du projet : cela le décale, majoré, au moment où quelque chose casse en production.
Le mode de facturation n’est pas un détail administratif : il détermine qui porte le risque quand le projet dérape.
Forfait pour la construction initiale, quand le périmètre est clair — c’est le cas de la plupart des premiers projets. Régie ensuite, pour faire vivre le produit au rythme de vos retours.
Le paiement est échelonné sur les étapes : cadrage, design, développement, mise en ligne. Le calendrier de facturation figure au devis, et aucune demande hors périmètre n’est réalisée sans un avenant que vous avez accepté par écrit.
Le prix se construit à partir de trois éléments : le nombre de fonctionnalités, le besoin ou non d’un serveur et d’une base de données, et le choix entre une base de code commune ou deux applications natives. Une application de consultation simple, sans compte utilisateur, coûte plusieurs fois moins cher qu’une plateforme avec paiement et temps réel. Nous chiffrons chaque devis à partir de votre périmètre réel, gratuitement et sous 48 heures.
Le plus souvent parce qu’ils ne couvrent pas le même périmètre. Un devis bas exclut fréquemment le backend, le design, les tests, la publication sur les stores ou la maintenance. Comparez les lignes, pas les totaux : demandez systématiquement ce qui est inclus et ce qui ne l’est pas.
Trois postes récurrents : les comptes développeur, soit environ 99 $ par an pour Apple et 25 $ une seule fois pour Google ; l’hébergement du backend, qui dépend de votre trafic ; et la maintenance. Les systèmes iOS et Android évoluent chaque année, une application non maintenue finit par être retirée des stores.
Oui, en réduisant le périmètre de la première version plutôt que la qualité. Nous commençons par les fonctionnalités qui portent la valeur, mettons l’application entre les mains d’utilisateurs réels, puis investissons sur ce qui sert vraiment. C’est la façon la plus sûre de ne pas financer des écrans que personne n’ouvrira.
Non. L’étude de votre besoin et le devis détaillé sont gratuits et sans engagement. Nous vous répondons sous 48 heures ouvrées.
Au forfait quand le périmètre est clair, ce qui est le cas de la plupart des premiers projets : vous connaissez le montant à l’avance et le risque de dépassement est pour nous. En régie lorsque le besoin doit être découvert chemin faisant, ou pour les évolutions après le lancement. Nous vous disons franchement lequel convient à votre situation.
Sur un forfait, un dépassement dû à une mauvaise estimation de notre part est à notre charge : c’est le principe même du forfait. En revanche, une demande nouvelle qui n’était pas au périmètre fait l’objet d’un avenant chiffré, que vous acceptez ou non avant que nous le réalisions. Rien ne se décide sans votre accord écrit.
Oui. Le paiement est échelonné sur les étapes du projet — cadrage, design, développement, mise en ligne — plutôt que réglé d’un bloc. Le calendrier de facturation figure au devis.
Décrivez-le en quelques lignes : nous vous répondons sous 48 h avec un devis détaillé, gratuit et sans engagement.