Combien coûte la construction d’une application mobile ?

Les estimations d’applications mobiles sous-évaluent souvent le coût parce qu’elles chiffrent l’app et oublient le backend dont elle a besoin pour être utile. Une app de liste de tâches sans serveur peut être réellement peu coûteuse. Une app avec des comptes, des notifications push, des paiements, ou quoi que ce soit de partagé entre appareils a besoin d’un vrai backend — et ce backend est souvent un poste plus important que les écrans que l’on voit réellement.

React Native ou Flutter contre le natif complet (Swift et Kotlin séparément) est le premier vrai embranchement de coût. Les frameworks cross-platform permettent à une seule base de code de couvrir iOS et Android, ce qui coûte généralement moins cher que de construire et maintenir deux bases natives distinctes — sauf si l’app s’appuie fortement sur des capacités spécifiques à la plateforme, où l’accès natif reste nécessaire, comme une intégration matérielle poussée ou des fonctionnalités OS très récentes.

La soumission aux stores n’est pas un détail. Le processus de revue d’Apple en particulier peut rejeter une app pour des raisons sans rapport avec des bugs — captures d’écran, métadonnées, déclarations de confidentialité, ou un parcours de connexion que le relecteur n’a pas pu franchir. Budgétez du temps, pas seulement du coût de développement, pour au moins un cycle de revue, et concevez les parcours de compte et de paiement en tenant compte des règles des stores dès le départ, pas comme un exercice de dernière minute avant lancement.

Une app simple, sans backend, sur une seule plateforme, peut être une petite construction. Un vrai produit — comptes, API backend, notifications push, gestion hors-ligne et les deux stores — se rapproche d’une fourchette comparable à un bon projet de logiciel sur mesure, car c’est fonctionnellement ce que c’est : un client mobile au-dessus d’un vrai système. Traitez l’estimation « de l’app » et celle « du produit complet » comme deux chiffres différents.

Les apps qui restent peu coûteuses à faire vivre après le lancement sont celles conçues avec un plan de maintenance dès le premier jour : un panneau d’administration qui ne nécessite pas un développeur pour répondre aux tickets de support, des analytics branchés avant le premier utilisateur, et un backend construit pour survivre à une mise à jour d’OS sans panique. Le coût de construction est le début de la facture, pas la totalité.

Une comparaison concrète : une app de carte de fidélité sans compte, stockant tout sur l'appareil, peut être une construction réellement petite — quelques semaines, une plateforme ou du cross-platform, aucun coût de backend. Dès que cette même app doit synchroniser un solde entre le téléphone et la tablette d'un client, elle a besoin de comptes et d'un backend, et l'estimation change de nature, pas seulement de taille.

Les notifications push sont un poste de coût caché fréquent. Ce n'est pas juste « activer un service » — elles nécessitent un backend pour cibler et planifier les envois, gérer les échecs de livraison et l'expiration des tokens, et respecter des règles propres à chaque plateforme (APNs d'Apple et FCM de Google se comportent assez différemment pour que la plupart des équipes sous-évaluent ce travail d'intégration de moitié).

Le coût après lancement est ce qui différencie le plus le mobile du web : une mise à jour d'OS peut casser une app sans aucun changement de code de votre part, un changement de politique de l'App Store ou du Play Store peut forcer une nouvelle soumission, et un correctif de sécurité d'une dépendance peut exiger une nouvelle build et un nouveau cycle de revue. Budgétiser zéro pour la maintenance, c'est budgétiser une app qui cessera discrètement de fonctionner dans l'année.