Combien coûte une application : ce qui fait varier le prix

Pourquoi une fourchette de prix ne dit rien de votre projet

Quand on se demande combien coûte une application, une fourchette « de X à Y euros » ne vous apprend rien sur votre projet. Deux applications qui ont le même nombre d’écrans peuvent avoir des devis très éloignés, selon des choix que l’on peut nommer un par un. Un bon devis les nomme, fonction par fonction, et chiffre à part ce qui coûtera chaque mois une fois l’application en service.

Nous développons des applications web et mobiles et nous en exploitons une : Challenge Us, une application de défis de groupe que nous avons développée, en service dans le navigateur depuis le 2 septembre 2026, avec un seul code pour le web, l’iPhone et Android (React Native et Expo) et un back-end Supabase avec temps réel et fonctions serveur. Ce qui suit vient de ce que nous avons appris en la construisant et en la faisant tourner, et c’est ainsi que nous chiffrons notre développement d’applications, qui commence par un cadrage écrit de ce que l’application fait le premier jour.

Ce qui fait varier le prix de développement

Les comptes et les droits

Une application sans compte (un catalogue, un calculateur) est simple. Dès qu’il y a des comptes, il faut l’inscription, la connexion, la récupération d’un compte perdu, la suppression du compte, et souvent plusieurs rôles (client, collaborateur, administrateur) avec des règles d’accès différentes. Chaque rôle ajoute des écrans et, surtout, des règles à tester : qui peut voir quoi, et qui ne doit jamais le voir.

Les données partagées en temps réel

Si deux personnes doivent voir la même information se mettre à jour sous leurs yeux (un compteur commun, un fil d’activité, une disponibilité), il faut un mécanisme de temps réel et des règles pour départager deux modifications simultanées. C’est le cœur de Challenge Us : le jour d’une saisie y est calculé par le serveur, dans le fuseau de chaque participant, et non par l’horloge du téléphone, qui pourrait antidater.

Le hors ligne

Une application qui doit fonctionner sans réseau (sur un chantier, en entrepôt, en déplacement) doit stocker les données sur le téléphone, puis les synchroniser au retour du réseau sans rien perdre ni rien dupliquer. C’est une décision coûteuse, à ne prendre que si l’usage l’exige vraiment.

Les paiements

Encaisser dans l’application, c’est intégrer un prestataire de paiement, gérer les remboursements, les échecs, les factures. Et sur les stores, la vente de contenus numériques est soumise aux règles d’achat intégré des plateformes, ce qui change le modèle économique. À clarifier dès le cadrage.

Les notifications

Prévenir un utilisateur quand quelque chose se passe demande un service d’envoi, des réglages par utilisateur (et la possibilité de les couper), et des règles pour ne pas noyer les gens. Sur iPhone, une application web installée peut recevoir des notifications depuis iOS 16.4, selon l’annonce de WebKit de février 2023, à condition d’avoir été ajoutée à l’écran d’accueil. Une application installable peut donc notifier ses utilisateurs sans passer par les stores, comme nous l’expliquons dans PWA ou application native : que choisir en entreprise.

Les intégrations

Brancher l’application sur votre CRM, votre ERP, votre outil de facturation : chaque intégration dépend de la qualité de l’interface de programmation de l’autre logiciel. Une API documentée se branche vite ; un logiciel sans API demande des contournements. C’est souvent la ligne la plus incertaine d’un devis, et un bon devis le dit.

La publication sur les stores

Publier sur l’App Store et Google Play, c’est préparer les fiches, les captures, la politique de confidentialité, répondre aux revues, et respecter des obligations précises (la suppression de compte dans l’application, par exemple, exigée par Apple). Nous détaillons le parcours dans notre guide pour publier une application sous le compte de votre entreprise.

L’administration

Il faut presque toujours un écran pour vous : voir les comptes, corriger une donnée, suivre l’usage. Il est souvent oublié dans les premiers devis, et ajouté plus tard au prix fort.

Ce que coûte l’application une fois en service

C’est la partie que beaucoup de pages de prix résument par un pourcentage annuel de maintenance, sans détail. Or une application en service a des coûts mensuels précis :

• La base de données et le serveur. À titre d’exemple, la page tarifs de Supabase indiquait en octobre 2026 que l’offre Free est limitée à deux projets actifs, que ses projets sont mis en pause après une semaine d’inactivité et qu’elle n’inclut pas de sauvegarde automatique ; l’offre Pro démarre à 25 $US par mois, avec des sauvegardes quotidiennes gardées sept jours. Une application d’entreprise ne tourne pas sur une offre qui peut se mettre en pause et ne sauvegarde rien.
• L’hébergement de l’interface web, souvent modeste pour une application servie en fichiers statiques.
• Les emails (codes de connexion, notifications) via un service d’envoi, avec des limites d’envoi à surveiller.
• Les comptes développeur des stores : en octobre 2026, 99 $US par année d’adhésion chez Apple, d’après la page d’inscription au programme développeur, qui précise que le prix peut varier selon la région, et 25 $US une seule fois chez Google, d’après l’aide de la Play Console.
• Les mises à jour : nouvelles versions des systèmes iOS et Android, des bibliothèques, des règles des stores. Une application qu’on ne met jamais à jour finit par ne plus répondre aux exigences des stores.

Demandez que ces lignes figurent dans le devis, avec un ordre de grandeur pour votre volume d’utilisateurs. Elles changent avec le succès de l’application, et c’est normal.

Ce qui fait baisser le prix sans dégrader le résultat

• Un périmètre de premier jour écrit. Ce que l’application fait au lancement, et ce qui attendra. Les dépassements viennent souvent de fonctions ajoutées en route.
• Un seul code pour toutes les plateformes. Développer séparément pour l’iPhone, Android et le web multiplie le travail et les corrections. Challenge Us partage un seul code entre les trois.
• Une version installable d’abord. Mettre l’application entre les mains de vrais utilisateurs avant les stores permet de corriger le tir tôt, quand c’est encore peu cher.
• Des services éprouvés plutôt que du sur-mesure pour l’authentification, la base de données et l’envoi d’emails.

Les limites honnêtes

Une application sur mesure n’est pas toujours la bonne réponse. Si un logiciel du marché couvre l’essentiel de votre besoin et que vous pouvez vivre avec ses choix, l’abonnement coûtera moins cher. Et si votre besoin tient dans un formulaire et un tableau partagé, une automatisation bien faite suffit parfois. Le sur-mesure se justifie quand la façon de travailler est votre avantage, ou quand aucun outil ne la respecte.

Par où commencer

Écrivez le périmètre du premier jour : ce que l’application fait au lancement, pour qui, et ce qui attendra. Puis demandez un devis qui chiffre chacune de ces décisions à part, avec les coûts mensuels d’exploitation en face. Pour ce cadrage, notre développement d’applications livre d’abord un cadrage écrit, puis une version entre les mains de vos premiers utilisateurs. Les autres choix d’un projet, de la PWA à la publication sur les stores, sont rassemblés dans notre rubrique applications web et mobiles.

Questions fréquentes

Combien de temps faut-il pour développer une application ?

Cela dépend des mêmes décisions que le prix : comptes, temps réel, hors ligne, intégrations. Un périmètre de premier jour serré permet de mettre une première version entre les mains d’utilisateurs en quelques semaines, puis d’avancer par versions. Comptez à part la publication sur les stores : ses démarches administratives, comme l’ouverture des comptes développeur au nom de la société, peuvent démarrer dès le premier jour du développement.

Combien coûte la maintenance d’une application ?

Demandez un chiffrage par ligne plutôt qu’un pourcentage : hébergement, base de données, envoi d’emails, comptes des stores, et un budget de mises à jour pour suivre les nouvelles versions d’iOS, d’Android et des bibliothèques. Les premières lignes dépendent surtout du nombre d’utilisateurs, la dernière du rythme d’évolution que vous souhaitez.

Qui possède le code de mon application ?

Vous devriez : le code, la base de données et les comptes développeur doivent être à votre nom, et le contrat doit le dire avant la signature. Vérifiez aussi que vous recevez les accès à l’hébergement et aux services utilisés. Sans cela, changer de prestataire peut vouloir dire republier l’application sous un autre compte.