Développer une application mobile coûte entre 3 990 € et 50 000 € HT selon l'approche retenue. Une application web progressive démarre autour de 3 990 €, une application multiplateforme en React Native ou Flutter entre 12 000 et 35 000 €, et un développement natif séparé pour iOS et Android dépasse généralement 40 000 €. L'écart ne vient pas de la qualité du code mais du nombre de bases à développer et maintenir.

Avant même de parler budget, une question tranche la moitié des projets : avez-vous réellement besoin d'une application, ou d'un site web bien conçu pour mobile ?

Application ou site mobile : la question à trancher d'abord

Beaucoup d'entreprises demandent une application alors qu'un site adapté au mobile répondrait mieux à leur besoin, pour cinq fois moins cher.

Un site web mobile suffit quand votre objectif est d'être trouvé, consulté puis contacté. Pas d'installation, pas de validation par les magasins d'applications, référencement naturel possible, mise à jour instantanée. Pour un commerce, un artisan, un cabinet de conseil ou un restaurant, c'est presque toujours le bon choix.

Une application se justifie dans quatre cas précis : vous avez besoin des notifications push pour réengager vos utilisateurs, d'un fonctionnement hors connexion, d'un accès approfondi au matériel (appareil photo en continu, géolocalisation en arrière-plan, Bluetooth, lecture NFC), ou vos utilisateurs reviennent plusieurs fois par semaine.

Le test le plus simple : si vos utilisateurs n'ouvriraient pas votre application au moins une fois par semaine, ils la désinstalleront dans le mois. L'icône sur l'écran d'accueil est un espace rare et disputé.

Les quatre approches techniques

L'application web progressive (PWA) : à partir de 3 990 €

C'est un site web qui s'installe sur l'écran d'accueil et fonctionne comme une application : plein écran, icône, fonctionnement hors ligne partiel, notifications push sur Android et désormais sur iOS.

Ses forces : une seule base de code pour tous les appareils, pas de validation par les magasins, mises à jour instantanées sans intervention de l'utilisateur, et surtout référencement naturel — votre contenu reste trouvable par Google, ce qu'aucune application native ne permet.

Ses limites : accès au matériel plus restreint, absence des magasins d'applications comme canal de découverte, et des notifications encore moins fiables sur iOS que sur Android.

Pour qui : outils métier internes, espaces clients, applications de réservation ou de suivi, catalogues. C'est l'approche la plus sous-estimée du marché, et de loin la plus économique.

Le multiplateforme : 12 000 à 35 000 €

React Native et Flutter permettent d'écrire une seule base de code qui produit une vraie application iOS et une vraie application Android, publiables sur les deux magasins.

Ses forces : une équipe au lieu de deux, un coût proche de celui d'une application unique pour deux plateformes, des performances suffisantes pour la grande majorité des usages, et un accès complet aux fonctions du téléphone.

Ses limites : les fonctionnalités très spécifiques à une plateforme demandent du code natif ponctuel, et les mises à jour majeures d'iOS ou d'Android peuvent exiger des adaptations.

Pour qui : la majorité des projets d'application d'entreprise. C'est le choix par défaut aujourd'hui, sauf raison contraire identifiée.

Le natif : 40 000 € et au-delà

Deux applications distinctes, Swift pour iOS et Kotlin pour Android. Vous développez et maintenez deux fois.

Ses forces : performance maximale, accès immédiat aux nouveautés de chaque système, meilleure intégration visuelle avec le système.

Quand c'est justifié : jeux, traitement vidéo ou audio intensif, réalité augmentée, applications où une fraction de seconde compte. En dehors de ces cas, c'est payer deux fois pour une différence que vos utilisateurs ne percevront pas.

L'application hybride légère : 6 000 à 15 000 €

Un site web encapsulé dans une coque native, publiable sur les magasins. Approche parfois critiquée, mais pertinente quand vous voulez une présence sur les magasins sans développer deux applications complètes, à condition que l'interface web soit réellement pensée pour le mobile.

Notre page développement d'applications mobiles détaille les périmètres que nous couvrons sur chaque approche.

Les coûts que les devis oublient

  • Les comptes développeur : 99 $ par an chez Apple, 25 $ une fois chez Google. Obligatoires pour publier.
  • La publication et les refus : la validation Apple prend de quelques heures à plusieurs jours, et un premier refus est fréquent. Prévoyez deux à trois allers-retours.
  • La maintenance obligatoire : Apple et Google imposent des mises à jour techniques régulières. Une application non maintenue est retirée des magasins au bout de quelques années. Comptez 15 à 25 % du coût initial par an.
  • Le serveur : une application affiche des données qui viennent de quelque part. Si vous n'avez pas déjà une interface de programmation, il faut la développer — un poste souvent équivalent à celui de l'application elle-même.
  • L'acquisition d'utilisateurs : personne ne trouve une application par hasard. Sans budget de promotion, votre application sera téléchargée par vos clients existants et personne d'autre.

Les règles des magasins d'applications à connaître avant de commencer

Apple et Google imposent des règles qui peuvent remettre en cause un modèle économique entier. Mieux vaut les connaître avant le développement qu'au moment du refus.

La commission sur les achats dans l'application. Si vous vendez un contenu ou un abonnement consommé dans l'application, vous devez passer par le système de paiement du magasin, qui prélève une commission — généralement 30 %, réduite à 15 % pour les petits éditeurs et sur les abonnements au-delà d'un an. Les biens physiques et les services consommés hors de l'application y échappent.

Le refus pour application trop simple. Apple rejette les applications qui se contentent d'afficher un site web sans valeur ajoutée propre. Si vous optez pour l'approche hybride, prévoyez au minimum des notifications, un mode hors ligne ou une fonction native réelle.

Les exigences de confidentialité. Les deux magasins imposent de déclarer précisément les données collectées, et Apple exige une autorisation explicite pour le suivi publicitaire. Une déclaration inexacte entraîne un retrait.

La suppression de compte. Si votre application permet de créer un compte, elle doit permettre de le supprimer depuis l'application. C'est une cause de refus fréquente et facile à anticiper.

Quelle application pour quel secteur

Quelques cas d'usage où une application apporte une valeur mesurable, tirés de projets réels.

Transport et livraison : l'application conducteur est le cas le plus évident. Géolocalisation en arrière-plan, acceptation de courses, preuve de livraison par photo et signature, fonctionnement en zone mal couverte. Ici, le site web ne peut pas faire le travail.

Commerce de proximité et restauration : la carte de fidélité numérique et les notifications de promotion justifient une application à partir d'une base de clients réguliers suffisante. En dessous de quelques centaines de clients actifs, le coût d'acquisition par utilisateur dépasse le gain.

Services aux entreprises : une application interne pour les équipes terrain — relevés, inventaires, interventions — se rentabilise vite par le temps de ressaisie économisé. C'est souvent le meilleur premier projet d'application d'une PME, car l'adoption est garantie.

Santé et bien-être : le suivi quotidien crée l'usage répété qui justifie une application. Attention toutefois au cadre réglementaire sur les données de santé, qui conditionne l'hébergement et l'architecture.

Combien de temps pour développer une application

Les délais usuels à partir de la validation du cahier des charges : 4 à 8 semaines pour une application web progressive, 10 à 20 semaines pour une application multiplateforme, 16 à 30 semaines pour du natif sur deux plateformes.

Ajoutez une à trois semaines pour la publication sur les magasins, variable et peu prévisible côté Apple.

Réussir un projet d'application

Les projets qui aboutissent partagent quatre caractéristiques.

Un périmètre volontairement réduit au départ. Une première version avec trois fonctionnalités bien faites, livrée en trois mois, vaut mieux qu'un projet de douze mois tentant de tout couvrir. Les retours des premiers utilisateurs orienteront la suite bien mieux que vos hypothèses initiales.

Un vrai besoin d'usage répété. Posez la question honnêtement : qu'est-ce qui fera revenir l'utilisateur la semaine prochaine ? Si vous n'avez pas de réponse claire, revoyez le projet avant de dépenser.

Un parcours de première utilisation soigné. La majorité des désinstallations surviennent dans les premières minutes. Si votre application demande de créer un compte avant d'avoir montré la moindre valeur, vous perdez l'essentiel de vos utilisateurs sur cet écran.

Un plan de maintenance budgété dès le départ. Une application est un engagement de plusieurs années, pas une livraison ponctuelle. Les entreprises qui l'oublient se retrouvent deux ans plus tard avec une application obsolète et un budget épuisé.

Si vous hésitez entre une application et un site mobile, nous le disons franchement lors du cadrage gratuit : dans près de la moitié des demandes que nous recevons, un site bien conçu répond mieux au besoin pour une fraction du budget.