Pourquoi il n’y a pas de prix unique pour une application
Demander combien coûte une application revient un peu à demander combien coûte une maison. Cela dépend de la taille, du terrain, des finitions et de ce que l’on met à l’intérieur. Une application de réservation avec paiement pour un salon et une application de livraison où le client suit le coursier en direct sur une carte sont deux produits très différents, même si les deux « ont une connexion et envoient des notifications ».
Méfiez-vous donc de tout chiffre annoncé avant que quelqu’un ait compris votre projet. Ce que nous pouvons faire, c’est vous montrer les éléments qui composent un devis. Une fois que vous les connaissez, vous comprenez pourquoi une proposition est plus élevée qu’une autre et vous décidez ce qui vaut la peine d’être construit maintenant et ce qui peut attendre.
Le périmètre : écrans, parcours et rôles d’utilisateurs
Le périmètre est le facteur le plus lourd. Chaque écran doit être conçu, développé, relié à la base de données et testé. Compter les écrans ne suffit pas pourtant. Le vrai travail se trouve dans les parcours, c’est-à-dire le chemin complet suivi par un utilisateur. Une inscription simple est un parcours court. Un paiement avec codes promo, livraison, moyens de paiement et e-mail de confirmation est un parcours long, avec de nombreuses règles et de nombreuses façons de dysfonctionner.
Les rôles d’utilisateurs multiplient ce travail. Une application destinée uniquement aux clients finaux est une chose. Une application avec clients, équipe et responsables, chacun avec des écrans et des permissions différents, en est une autre. Une application de livraison compte au moins trois expériences : l’acheteur, le coursier et l’administrateur.
Presque toute application métier a aussi besoin d’un tableau de bord d’administration, l’espace web où l’entreprise gère les produits, les plannings et les prix et suit les commandes. On l’oublie facilement quand on imagine l’application, mais il fait partie du produit et du devis. Un tableau de bord avec rapports, export de données et gestion d’équipe demande plus de travail qu’un simple outil de modification d’enregistrements.
Les intégrations et les fonctionnalités spécifiques
Intégrer, c’est faire dialoguer l’application avec des systèmes que vous utilisez déjà. Certaines intégrations sont simples parce que le service dispose d’une API bien documentée. D’autres obligent à fouiller un système ancien, à nettoyer des données désordonnées et à gérer ce qui se passe quand l’autre côté tombe en panne.
Certaines fonctionnalités ressemblent aussi à de petites lignes dans une liste, mais changent la taille du projet, car elles demandent plus d’architecture, plus de tests et parfois des services externes payants. Les règles métier complexes, comme les commissions, les niveaux d’accès et les circuits de validation, entrent dans la même catégorie. Ce qui pèse généralement le plus :
- Paiements : cartes, portefeuilles numériques, abonnements récurrents, répartition des paiements entre vendeurs.
- ERP et CRM : stocks, facturation, catalogues synchronisés, envoi des prospects à l’équipe commerciale.
- WhatsApp et API tierces : confirmations, rappels, livraison, connexion via les réseaux sociaux.
- Temps réel : chat, suivi des coursiers, tableaux de bord qui se mettent à jour seuls.
- Cartes et géolocalisation : itinéraires, zones de livraison, recherche à proximité.
- Intelligence artificielle : assistants, lecture de documents, recommandations.
- Mode hors ligne : stockage des données sur l’appareil et synchronisation au retour de la connexion.
Design, plateformes et publication sur les stores
Si votre entreprise possède déjà une identité visuelle, avec logo, couleurs et typographie, le design part de là et le travail consiste à appliquer la marque aux écrans. Si vous partez de zéro, l’identité doit d’abord être créée, ce qui ajoute du temps. Les prototypes cliquables, qui permettent de tester l’expérience avant d’écrire la moindre ligne de code, relèvent aussi de cette étape et évitent généralement des reprises par la suite.
Le choix des plateformes modifie le coût. Aujourd’hui, on peut servir iPhone et Android avec un seul code source, et une application web progressive (PWA) peut s’installer directement depuis le navigateur sans passer par les stores. Les applications entièrement natives, avec un code distinct pour chaque système, demandent plus de travail et se justifient quand le produit dépend fortement des fonctions de l’appareil.
La publication sur l’App Store et Google Play est une étape à part. Elle exige des comptes développeur, des images et des textes pour la fiche, une politique de confidentialité et la validation de chaque store, qui peut demander des modifications avant l’approbation.
Le coût ne s’arrête pas au lancement
Beaucoup de personnes ne budgètent que le développement et sont surprises ensuite. Une application en ligne a des coûts récurrents : serveurs et base de données, nom de domaine, services d’e-mail et de notifications push, API payantes pour les cartes ou l’IA, et frais de traitement des paiements. Si l’application est dans les stores, Apple facture un abonnement annuel de développeur et Google des frais d’inscription. Beaucoup de ces coûts augmentent avec votre base d’utilisateurs.
Il y a ensuite la maintenance. Les systèmes d’exploitation évoluent, les bibliothèques reçoivent des correctifs de sécurité et les stores mettent à jour leurs règles. L’usage réel révèle aussi des améliorations et de nouvelles fonctionnalités qui valent la peine. Prévoyez dès le premier jour comment fonctionneront le support et l’évolution continue une fois l’application en ligne.
Pourquoi les devis varient autant d’une agence à l’autre
Il est courant de recevoir des propositions très différentes pour un même projet. Le plus souvent, elles ne chiffrent pas la même chose. L’une inclut un tableau de bord d’administration, des tests sur de vrais appareils et la publication sur les stores. Une autre livre uniquement l’application, sans tableau de bord, et laisse le reste en « options » qui apparaissent en cours de route.
La manière dont l’application est construite et par qui comptent aussi. Adapter un modèle existant coûte moins cher qu’un développement sur mesure, mais limite ce que vous pourrez modifier ensuite. Un code propre et documenté coûte plus cher au départ et beaucoup moins quand l’application doit grandir ou passer à une autre équipe. Ne comparez pas les montants finaux. Comparez ce qui est écrit dans chaque proposition.
Comment réduire les coûts sans sacrifier la qualité
Le moyen le plus sûr de dépenser moins est de construire moins de choses, pas de les construire moins bien. Se passer de tests ou se contenter d’un code fragile devient coûteux dès que l’application a besoin de corrections ou d’une nouvelle fonctionnalité. Réduire le périmètre avec soin permet de garder l’essentiel.
Commencer par un MVP, la plus petite version qui résout déjà le problème principal, est le chemin le plus courant. Nous expliquons comment cadrer cette première version dans notre article sur ce qu’est un MVP. Quelques pratiques utiles :
- Écrire en une phrase le problème que l’application résout et écarter tout ce qui n’y contribue pas.
- Séparer ce dont vous avez besoin au lancement de ce qui serait agréable plus tard.
- Découper le projet en étapes, chacune avec un livrable fonctionnel.
- Commencer par une PWA et attendre, pour la publication sur les stores, que l’usage la justifie.
- Utiliser des services prêts à l’emploi pour les parties qui ne vous différencient pas, comme la connexion et l’envoi d’e-mails.
Ce qu’une proposition sérieuse doit préciser
Une bonne proposition laisse peu de place aux mauvaises surprises. Avant de signer, vérifiez qu’elle couvre :
- Le périmètre détaillé : écrans, parcours, rôles d’utilisateurs, tableau de bord et intégrations.
- Le délai total, ventilé par étape.
- Un prix ferme, avec des paiements liés aux livrables.
- Ce que vous recevez à la fin de chaque étape et comment vous le testerez.
- Ce qui n’est pas inclus, comme l’hébergement, les comptes des stores et les services tiers.
- Le fonctionnement du support et des modifications de périmètre une fois le projet lancé.
Comment BG Coding construit un devis
Nous ne travaillons pas avec une grille tarifaire. Nous commençons par connaître votre entreprise, votre public et le problème que l’application doit résoudre, lors d’un appel de diagnostic. Nous envoyons ensuite une proposition avec périmètre, étapes, délai et prix ferme, en précisant ce qui est exclu. Si le budget est serré, nous suggérons un MVP ou une première phase qui résout déjà le problème principal.
Si vous avez une idée d’application et souhaitez savoir ce qu’il faut pour la réaliser, présentez-la-nous sur notre page de devis et nous reviendrons vers vous avec un diagnostic.