Ce que ça coûte

Combien coûte une application mobile

Une application coûte plus cher qu'un site, et ce n'est pas une question de complexité : c'est qu'on la paie deux fois, puis chaque année. Deux fois, parce qu'iPhone et Android sont deux systèmes distincts. Chaque année, parce que les deux boutiques imposent des mises à jour pour rester publiable — une application qu'on ne touche plus finit retirée. Le devis de fabrication ne dit rien de cette part-là, et c'est celle qui décide si le projet survit. Cette page détaille la méthode de chiffrage, les postes qui reviennent, et ce que change un abonnement où une équipe reste après la publication.

1. Pourquoi on paie deux fois

C'est le fait qui gouverne tout le budget, et celui qu'on découvre le plus souvent après avoir demandé un premier devis.

Deux systèmes, deux mondes. iOS et Android n'ont ni le même langage, ni les mêmes conventions d'affichage, ni les mêmes règles de permission. Historiquement, cela signifiait deux développements complets, donc à peu près deux fois la charge.
Les technologies communes réduisent l'écart sans l'effacer. Écrire une base partagée est aujourd'hui la norme, mais le réglage fin, les tests et les particularités de chaque plateforme restent à faire deux fois. Comptez un supplément réel, pas un doublement.
Deux boutiques à satisfaire. Chacune a ses règles de publication, ses visuels à produire aux bonnes dimensions, ses textes à traduire et son examen à passer. C'est un travail administratif à part entière, distinct du développement.
Un parc d'appareils, pas un appareil. Des tailles d'écran très différentes, des versions de système anciennes encore en service. Ce que le site web règle avec une feuille de style demande ici des essais sur plusieurs configurations.

À charge égale, une application coûte donc structurellement plus qu'un site. La vraie question n'est pas comment payer moins, mais si l'application est nécessaire — c'est la section 5, et elle mérite d'être lue avant de demander un devis.

2. Chiffrer un développement, poste par poste

Comme pour un site, aucun tarif de référence n'existe. Voici les postes à faire chiffrer séparément : un devis qui les fond en une ligne ne peut être comparé à aucun autre.

Les écrans. Comptez-les, et distinguez ceux qui affichent de ceux qui saisissent : un formulaire, avec ses erreurs et ses cas limites, coûte plusieurs fois un écran de consultation.
Le compte utilisateur. Inscription, connexion, mot de passe oublié, suppression du compte — cette dernière étant exigée par les boutiques dès qu'il y a inscription. Ce bloc est presque toujours sous-estimé.
Le serveur et les données. Une application qui ne fait qu'afficher du contenu figé est peu coûteuse. Dès qu'elle enregistre quelque chose, il faut une base, une interface pour l'administrer et une sauvegarde. C'est souvent le premier poste du devis.
Les notifications. Techniquement simples, coûteuses en réglages : autorisations à demander, comportements différents sur les deux systèmes, et une logique métier à écrire pour décider quoi envoyer et quand.
Le paiement dans l'application. S'il y a un achat, les boutiques imposent leur propre mécanisme et prélèvent une commission. C'est à la fois un développement et une part de votre chiffre d'affaires.
La recette sur appareils réels. Non négociable, et le premier poste rogné dans un devis serré — ce qui se paie en corrections après publication, au tarif de l'urgence.

3. Ce qui court chaque année

Un site négligé reste en ligne. Une application négligée devient inutilisable, puis disparaît. C'est la différence essentielle, et elle est financière.

Les frais de compte développeur. Publier exige un compte sur chaque boutique : un abonnement annuel du côté d'Apple, des frais uniques du côté de Google. Modeste, mais l'abonnement Apple non renouvelé retire l'application de la vente.
Les mises à jour imposées. Chaque année, les nouvelles versions d'iOS et d'Android déplacent des règles, et les boutiques exigent une compilation avec des outils récents pour accepter une mise à jour. Il faut donc intervenir même sans rien changer à l'application.
Le serveur. Hébergement, base de données, sauvegardes : une dépense mensuelle qui grandit avec l'usage.
Les corrections. Un plantage ne se voit pas comme une page cassée : il se voit dans les notes de la boutique, où il reste des mois.
Le suivi des avis. Personne ne s'en occupe, et ils sont la première chose que lit un futur utilisateur.

Provisionnez ces postes sur trois ans avant de signer. Une application livrée sans budget de suite est une application qui sera retirée des boutiques — parfois avant d'avoir servi.

4. Le coût des boutiques : le refus

C'est un poste absent de tous les devis, et il est réel : la publication n'est pas un dépôt, c'est un examen. Les deux boutiques relisent l'application et refusent pour des motifs souvent étrangers au développement — une politique de confidentialité incomplète, une suppression de compte introuvable, des identifiants de test qui ne fonctionnent pas, une explication de permission jugée insuffisante, une ressemblance avec un site web sans valeur propre.

Chaque refus coûte deux choses. Du temps : une correction, un nouvel envoi, une nouvelle attente. Et une date : si la sortie était annoncée, elle glisse. Un projet mené sans marge sur ce point se retrouve à payer une urgence pour un motif administratif.

Demandez donc à tout prestataire qui gère la publication et qui reprend les refus. La réponse vaut une ligne de devis.

5. La question à se poser avant de payer

Beaucoup d'applications n'auraient pas dû être développées, et le budget serait mieux allé ailleurs. Trois questions tranchent honnêtement.

L'usage est-il répété ? On installe une application pour ce qu'on ouvre souvent — commander, suivre, pointer, fidéliser. Pour une consultation occasionnelle, un site sur téléphone fait mieux, sans installation à obtenir.
Avez-vous besoin de l'appareil ? Notifications, appareil photo, position, fonctionnement hors réseau, code-barres : si rien de tout cela ne sert, l'application n'apporte pas ce que le web ne sait pas faire.
Qui va l'installer ? C'est le point qui coule le plus de projets. Obtenir une installation est plus difficile qu'obtenir une visite. Sans une audience déjà captive — des clients réguliers, des adhérents, des équipes de terrain — l'application restera vide, quelle que soit sa qualité.

Si les trois réponses ne sont pas franches, commencez par le site : la page sur le coût d'un site internet détaille cette voie. L'application viendra quand l'usage existera.

6. Payer pour l'après, pas pour la publication

Si la dépense se concentre après la mise en vente, alors ce qu'il faut acheter n'est pas un développement : c'est une présence qui dure.

Chez nullbot, l'application se décrit en conversation, comme le site. On la voit tourner dans un simulateur iOS et Android avant toute publication — on peut la manipuler et en prendre des captures. Elle peut avoir sa base de données, elle passe une recette, on produit le binaire pour chaque cible, et la publication vers l'App Store et Google Play se pilote depuis le même endroit, avec le statut de chaque boutique sous les yeux.

Ce n'est toujours pas ce qu'on vend. Ce qu'on vend, c'est l'année suivante : l'équipe d'agents qui reste. Elle prépare les mises à jour que les boutiques réclament, reprend un refus d'examen, corrige ce qui plante, tient les fiches et leurs traductions, surveille les avis. L'application n'attend pas un budget de maintenance qui n'arrivera pas — c'est le travail courant de l'équipe.

La dépense cesse d'être un projet à financer puis à refinancer. Elle devient un abonnement mensuel, et la publication n'est plus une fin de course.

7. Semaine 1, mois 3, année 2

Les trois moments qui départagent les offres — et ils ne sont pas les mêmes que pour un site, parce que les boutiques imposent leur calendrier.

Semaine 1. L'application est publiée sur les deux boutiques, ses fiches sont remplies, un compte de test fonctionne pour l'examen. Un prestataire compétent sait faire cela.
Mois 3. Trois plaintes portent sur le même écran, une note à deux étoiles est en tête, une version de système est sortie. La question devient : qui a publié la correction ? Un projet livré sans suite est ici déjà en train de perdre ses utilisateurs.
Année 2. Les deux boutiques exigent une compilation avec des outils plus récents, sous peine de refuser toute mise à jour. Sans intervention, l'application reste installée chez ceux qui l'ont, ne s'installe plus nulle part, et finit par ne plus démarrer. C'est le moment où un budget de refonte apparaît — pour la même raison qu'il réapparaîtra.

8. Les limites, dites franchement

Une application très spécialisée reste un développement sur mesure. Traitement d'image avancé, matériel connecté par Bluetooth, cartographie fine, jeu : ce sont des métiers, et un budget de développement classique.
L'examen des boutiques ne se garantit pas. Aucun prestataire ne peut promettre une acceptation, ni un délai. Ce qui se promet, c'est de reprendre le dossier jusqu'à ce que ça passe.
Une application ne crée pas son audience. Si personne ne l'installe, aucune équipe n'y changera rien. Relisez la section 5 : c'est la décision la plus économe du projet.
Ce qui engage l'entreprise passe par une validation. Une mise en vente, un changement de tarif, un message envoyé à tous les utilisateurs vous sont soumis avant de partir.

9. Questions fréquentes

Pourquoi ne pas donner un prix moyen pour une application mobile ?

Parce que l'écart entre une application de consultation et une application avec comptes, paiement et notifications est tel qu'une moyenne ne renseignerait sur rien. Les postes de la section 2, chiffrés pour votre cas, donnent un ordre de grandeur défendable. Un montant unique donnerait surtout une fausse assurance au moment de comparer deux devis.

Une seule application pour iPhone et Android coûte-t-elle moins cher ?

Moins que deux développements séparés, oui, et c'est la pratique courante. Mais l'économie n'est pas de moitié : le réglage fin, les essais et les particularités de chaque plateforme restent à faire des deux côtés, et les fiches de boutique sont à produire deux fois. Comptez un supplément par rapport à une plateforme unique, pas une gratuité de la seconde.

Faut-il un compte Apple et Google à son nom ?

C'est fortement préférable, et c'est un point à régler avant de signer. Une application publiée sur le compte d'un prestataire est difficile à récupérer, et son historique de notes ne se transfère pas. Ouvrez les comptes au nom de l'entreprise, quitte à déléguer ensuite l'accès : c'est un quart d'heure au début, et un blocage complet plus tard.

Que se passe-t-il si je ne mets jamais l'application à jour ?

Trois choses, dans cet ordre. Les boutiques refusent d'abord vos nouvelles versions parce que les outils de compilation sont trop anciens. Puis l'application cesse de fonctionner correctement sur les téléphones récents. Enfin, une application sans mise à jour depuis longtemps peut être retirée de la vente. C'est ce qui distingue une application d'un site : l'inaction ne la laisse pas en place, elle la supprime.

Mon site suffit-il au lieu d'une application ?

Dans la majorité des cas d'entreprise, oui — et cela reste vrai même quand une application ferait plaisir. Un site fonctionne sur tous les téléphones, ne demande aucune installation, n'a pas d'examen à passer et n'a pas de mise à jour imposée chaque année. L'application se justifie quand l'usage est répété et qu'il faut quelque chose de l'appareil. Les trois questions de la section 5 tranchent en quelques minutes.

Pour aller plus loin

Lire ensuite : comment se crée l'application, étape par étape, ce que coûte un site internet, ou ce que coûte un salarié.