Presque tous les articles qui répondent à cette question annoncent un prix de développement, puis s'arrêtent net, comme si une application était un meuble que l'on achète une fois et que l'on pose dans un coin du salon. Ce n'est pas ce qui se passe dans la vraie vie d'un projet, parce que le développement est bien un achat unique, alors que l'application, elle, se comporte ensuite comme un abonnement dont vous seriez propriétaire. Nous allons donc chiffrer toute sa vie, du premier devis au cinquième anniversaire : les fourchettes que nous pratiquons réellement, les petites lignes que personne ne détaille, le travail que les mises à jour des téléphones vous imposent chaque année, les coûts qui arrivent avec vos utilisateurs plutôt qu'avec votre code, et un total sur cinq ans que vous pourrez refaire vous-même sur un coin de table. Tous les montants sont exprimés en dollars américains.
Ce que vous achetez réellement quand vous payez une application mobile
Quand quelqu'un vous annonce un prix pour « une application mobile », ce chiffre recouvre presque toujours cinq objets distincts, et savoir lesquels fait toute la différence entre lire un devis et le deviner. Le premier est l'application iPhone, celle que vos clients installeront depuis l'App Store d'Apple. Le deuxième est l'application Android, celle qui vient de Google Play, et c'est un logiciel réellement différent même quand les deux se ressemblent trait pour trait à l'écran. Le troisième est le serveur, c'est-à-dire un ordinateur loué dans un centre de données, qui retient tout ce que les applications doivent mémoriser : les comptes, les commandes, les réservations, les photos et les messages. Le quatrième est le tableau de bord d'administration, un site privé sur lequel vos équipes se connectent pour voir les commandes, changer les prix, répondre aux clients et faire tourner la maison au quotidien. Le cinquième, enfin, ce sont les deux fiches de publication : l'icône, les captures d'écran, le texte de présentation, la politique de confidentialité et les comptes développeur sans lesquels une entreprise n'a tout simplement pas le droit de publier.
Voici maintenant le cadre sur lequel repose tout le reste de cet article, parce que c'est précisément ce que les guides de prix laissent de côté. Le développement est un achat unique, mais l'application que vous possédez ensuite se comporte comme un abonnement. Les téléphones changent, les deux systèmes d'exploitation reçoivent une version majeure chaque année, à date fixe, sans que personne ne vous demande votre avis, si bien qu'une application laissée telle quelle se dégrade même si vous ne touchez plus une seule ligne de code. Ce n'est pas un argument de vente, c'est le calendrier d'Apple et de Google, et il tombe que vous ayez prévu un budget ou non.
Cet article s'adresse à la personne qui doit décider si elle dépense, pas au développeur qui compare des technologies. Tout y est donc exprimé en argent et en semaines plutôt qu'en unités techniques, et chaque terme est expliqué la première fois qu'il apparaît. Chez Linkysoft, nous concevons et développons des applications mobiles depuis assez longtemps pour savoir que le mauvais devis n'est presque jamais le plus cher : c'est celui qui a laissé la moitié de la facture en dehors du cadre.
Les trois paliers de prix que nous voyons vraiment, et ce que chacun contient
Dans la pratique, les projets se rangent dans trois familles assez nettes, et vous saurez à laquelle appartient la vôtre en une minute de lecture.
Palier un : l'application simple
Un catalogue que l'on feuillette, une prise de rendez-vous, une connexion par compte, des notifications qui s'affichent sur l'écran du téléphone et un petit serveur derrière le tout : comptez 8 000 à 25 000 dollars et 6 à 10 semaines. C'est le palier des restaurants, des salles de sport, des cabinets et des commerces qui veulent une présence dans la poche de leurs clients sans réinventer leur métier. Rien n'y est bricolé, mais rien n'y est inventé non plus : chaque brique existe déjà et se réassemble.
Palier deux : l'application transactionnelle
Comptes clients, paiements, rôles différents pour vos employés selon ce qu'ils ont le droit de voir, tableau de bord d'administration complet, et un comportement correct quand le réseau tombe dans un ascenseur ou un sous-sol : 25 000 à 70 000 dollars et 3 à 5 mois. L'écart de prix avec le palier précédent ne vient pas du nombre d'écrans, il vient de l'argent qui circule, car du moment qu'une application encaisse, chaque cas bizarre doit être prévu, testé et rejoué avant la mise en ligne.
Palier trois : la place de marché ou l'application réglementée
Deux populations d'utilisateurs qui ne voient pas la même chose, suivi en direct sur une carte, messagerie interne, journal d'audit qui garde la trace de qui a fait quoi et quand, et tout le travail de conformité qui accompagne un secteur surveillé : 70 000 à 200 000 dollars et au-delà, sur 6 à 12 mois. Ici, vous ne payez plus une application, vous payez une entreprise numérique complète, avec ses règles, ses litiges et ses preuves.
Reste la question qui agace tout le monde : pourquoi un cahier des charges identique revient-il avec des devis du simple au triple ? La réponse est arithmétique, pas morale. Une application de taille moyenne représente 700 à 1 400 heures de travail, et les équipes se facturent entre 20 et 50 dollars de l'heure à une extrémité du marché et entre 90 et 180 dollars de l'heure à l'autre. Multipliez, et vous obtenez sans tricher un écart de trois entre deux propositions sérieuses. Ce qui change d'un devis à l'autre, ce n'est donc pas le talent, c'est l'ancienneté des personnes affectées, la profondeur des tests, et surtout la réponse à une question très concrète : qui répare à deux heures du matin quand les paiements ne passent plus ?
Il existe un calcul que vous pouvez refaire seul et qui tombe presque toujours juste. Comptez vos écrans, c'est-à-dire les pages distinctes que verra l'utilisateur, puis comptez 1 200 à 2 500 dollars par écran fini, design compris, les deux applications comprises, le serveur et les tests compris. Trente écrans vous placent ainsi entre 36 000 et 75 000 dollars, et si un devis s'écarte franchement de cette fourchette, ce n'est pas forcément qu'il vous trompe, mais vous tenez là une excellente première question à poser. Si vous en êtes encore à construire votre budget avant de consulter, ce simple comptage vaut mieux qu'une intuition.
Où passe l'argent à l'intérieur du développement
Une fois le montant global accepté, il se répartit de façon remarquablement stable d'un projet à l'autre. Sur un budget type, nous planifions environ 15 pour cent pour le design et l'expérience utilisateur, environ 40 pour cent pour les deux applications elles-mêmes, environ 20 pour cent pour le serveur et son interface d'administration, environ 13 pour cent pour les tests et environ 12 pour cent pour la gestion de projet, c'est-à-dire la personne qui organise, arbitre et vous tient au courant.
Regardez cette liste une deuxième fois et vous verrez le point qui dérange : près de la moitié de votre argent achète des choses que votre client final ne verra jamais. Le serveur, les tests, la coordination, tout cela reste invisible depuis l'écran du téléphone, et c'est exactement pour cette raison que la première économie tentante consiste à rogner sur les tests. C'est aussi la plus coûteuse, car une anomalie trouvée après le lancement se paie plusieurs fois ce qu'elle aurait coûté avant, entre le temps de reproduction, la correction, une nouvelle soumission aux stores et les clients qui ont vu le problème entre-temps.
Il y a une autre raison, moins connue, pour laquelle un devis sérieux paraît cher : un écran simple n'est jamais un seul écran. Une liste de commandes doit exister en version chargement pendant que les données arrivent, en version vide quand il n'y a encore rien à montrer, en version erreur quand le serveur ne répond pas, et en version hors connexion quand le téléphone n'a plus de réseau. Une liste de trente écrans représente donc environ cent vingt comportements à dessiner, à coder et à vérifier, ce qui explique pourquoi le compte final ne ressemble jamais à la liste que vous aviez en tête.
Un seul code ou deux, et ce que ce choix fait à la facture
Deux routes s'offrent à vous, et elles se résument sans jargon. Le natif consiste à écrire deux applications séparées, chacune dans le langage préféré du fabricant du téléphone. Le multiplateforme consiste à écrire un seul code partagé, avec des outils comme Flutter ou React Native, qui produit ensuite les deux applications à partir du même travail.
Financièrement, l'écart est net. Deux applications natives reviennent à environ 1,6 à 1,8 fois le prix d'une seule plateforme, et non au double, parce que le design et le serveur sont partagés de toute façon. Un développement multiplateforme économise en général 30 à 40 pour cent sur la facture initiale, et à peu près la même proportion sur chaque modification que vous demanderez pendant les années suivantes, ce qui est en réalité la plus importante des deux économies.
Le natif garde pourtant sa place, et nous le recommandons sans hésiter dans quatre cas : un usage intensif de l'appareil photo ou de la réalité augmentée, un dialogue avec du matériel en Bluetooth, une localisation qui doit tourner en arrière-plan toute la journée, ou un jeu. Pour une application d'entreprise ordinaire, catalogue, comptes, paiements et suivi, le multiplateforme est le bon choix, et nous le disons à nos clients même quand le devis natif nous rapporterait davantage.
Reste l'économie la plus tranchante de toutes, celle que peu de prestataires proposent spontanément : lancer sur une seule plateforme d'abord réduit la première facture de 35 à 45 pour cent. La plateforme à retenir n'est pas celle que vous préférez, c'est celle que vos clients ont réellement dans la poche, et une journée passée à regarder les téléphones qui arrivent à votre comptoir vous le dira mieux que n'importe quelle étude de marché.
Les petites factures que personne n'inscrit dans le devis
Ce sont rarement de gros montants, mais ils arrivent tous en même temps, souvent la semaine où vous pensiez avoir fini de payer.
- Les comptes de publication. Apple facture 99 dollars par an pour qu'une application reste publiée, et Google Play demande 25 dollars une seule fois, soit 124 dollars la première année puis 99 dollars ensuite. Un point qui ne se négocie pas : ces deux comptes doivent être ouverts au nom de votre société, jamais à celui de l'agence, sinon votre application ne vous appartient pas vraiment le jour où vous changez de prestataire.
- Les éléments de la fiche. Une icône, des captures d'écran à plusieurs tailles d'appareil, une description par langue, une politique de confidentialité, une déclaration sur les données collectées, et un chemin dans l'application permettant à l'utilisateur de supprimer son compte lui-même. Cette dernière ligne est l'un des motifs de refus les plus fréquents lors d'une première soumission, et elle coûte une demi-journée si elle est prévue, une semaine si elle est découverte le jour du refus.
- Les frais de mise en route. L'ouverture d'un compte chez un prestataire de paiement avec vérification de l'entreprise, un nom de domaine et son certificat, quelques vrais téléphones pour tester sur du matériel réel plutôt que sur un simulateur, et la conservation en lieu sûr de la clé de signature, ce fichier qui prouve que l'application est bien la vôtre. La perdre reste l'un des rares accidents véritablement pénibles de ce métier.
- L'arabe et les langues qui s'écrivent de droite à gauche. Bien faites, elles ajoutent environ 15 à 25 pour cent aux lignes design et tests, pas au budget entier, et les prévoir dès le départ coûte une fraction de ce que coûte leur ajout après coup.
Ce que coûte une application vivante pendant une année
La règle de travail que nous appliquons tient en une phrase : prévoyez chaque année 15 à 20 pour cent du prix de développement pour la maintenance. Une application achetée 45 000 dollars coûte donc de l'ordre de 6 750 à 9 000 dollars par an rien que pour rester à sa place, hébergement non compris. Ce n'est pas une taxe déguisée, c'est du travail imposé de l'extérieur.
Le calendrier explique tout. iPhone et Android publient chacun une version majeure par an, et Apple relève environ une fois par an la version minimale des outils avec lesquels une application peut être envoyée, si bien qu'une application abandonnée finit par ne plus pouvoir publier ne serait-ce qu'une correction de bug. Dans notre expérience, une application laissée sans entretien commence à se dégrader visiblement au bout de 18 à 24 mois : un écran qui s'affiche de travers, une connexion qui échoue sur les téléphones récents, puis un retrait du store. La maintenance après le lancement n'est donc pas un service optionnel, c'est la condition pour que l'achat initial garde sa valeur.
L'hébergement, lui, ne suit pas votre ambition mais votre fréquentation. En dessous d'environ 5 000 personnes par mois, comptez 40 à 150 dollars par mois. Autour de 50 000 personnes par mois avec des images et de la vidéo, comptez plutôt 300 à 800 dollars par mois. Ajoutez à cela deux lignes discrètes mais indispensables : la surveillance des plantages et des erreurs, autour de 50 dollars par mois, qui vous prévient avant vos clients, ainsi que les sauvegardes et une copie de test sur laquelle essayer les modifications avant que le public ne les voie.
Les coûts qui grandissent avec vos utilisateurs, pas avec votre code
Il existe une catégorie de dépenses que personne ne peut chiffrer au moment du devis, parce qu'elles dépendent du succès. Elles sont pourtant très prévisibles une fois qu'on les connaît.
Les codes de connexion envoyés par SMS coûtent environ 0,02 à 0,09 dollar par message selon le pays, ce qui paraît dérisoire jusqu'au calcul complet : 5 000 connexions par mois à deux messages chacune vous placent entre 200 et 900 dollars mensuels. C'est la raison pour laquelle une connexion par courriel ou par application d'authentification se rembourse souvent en un seul trimestre, et c'est une décision de produit bien plus qu'une décision technique.
Les cartes et le calcul d'itinéraires se paient au compteur. Une application de type livraison qui génère environ 100 000 affichages de carte par mois se situe couramment entre 200 et 700 dollars mensuels, et cette ligne grimpe exactement au rythme de vos courses.
La commission des stores mérite quant à elle une lecture attentive, parce qu'elle décide si les paiements ont leur place dans l'application ou pas. Elle est d'environ 30 pour cent sur les biens numériques, tombe à environ 15 pour cent pour les petites entreprises qui réalisent moins d'un million de dollars par an ainsi que pour les abonnements au-delà de la première année, et elle est nulle quand vous vendez un bien physique ou un service rendu en personne. À comparer avec le paiement par carte sur votre propre site, qui revient à environ 2,9 pour cent plus une petite somme fixe par transaction : l'écart entre les deux vaut parfois plusieurs salaires par an, et il se décide avant la première ligne de code.
Enfin, le coût le plus humain de tous. Autour de 10 000 utilisateurs actifs, attendez-vous à 20 à 60 messages de support par semaine, entre les mots de passe oubliés, les commandes introuvables et les remboursements. C'est un vrai mi-temps, et il doit figurer dans votre budget comme un salaire, pas comme une dépense logicielle.
Quand vous payez, et pas seulement combien
Une application ne se règle presque jamais en une fois, ce qui est une bonne nouvelle pour votre trésorerie à condition de savoir à l'avance quand partent les échéances. Le rythme habituel est le suivant : environ 2 semaines de cadrage, environ 3 semaines de design, 8 à 12 semaines de développement, environ 3 semaines de tests et 1 à 2 semaines de soumission aux stores, si bien que le paiement se découpe en général en quatre ou cinq versements étalés sur le projet.
La mise en ligne, elle, n'est pas un interrupteur. La validation d'Apple se termine couramment en moins de 48 heures, Google Play prend souvent 1 à 7 jours pour une première version, et dans notre pratique, environ une première soumission sur trois revient avec un refus, presque toujours pour un motif administratif réparable en quelques heures. Prévoyez donc une fenêtre de lancement de deux semaines plutôt qu'une date de lancement, et évitez d'annoncer publiquement un jour précis.
Gardez aussi 10 à 15 pour cent du budget en réserve, parce qu'une modification demandée après la validation du design coûte typiquement deux à trois fois ce que la même modification aurait coûté pendant le design. Ce qui nous amène au levier le plus puissant de toute cette histoire : le total que vous paierez se joue dans les trois premières semaines, au moment où changer d'avis est encore gratuit. Une heure de réflexion supplémentaire à ce stade vaut souvent plusieurs milliers de dollars plus tard.
Quand la solution la moins chère est la bonne, et nous vous le dirons
Il arrive très souvent qu'une application mobile ne soit pas la bonne réponse, et le dire fait partie du travail. Un site adapté au téléphone ou une application web, c'est-à-dire un outil qui s'ouvre dans le navigateur sans rien installer, coûte fréquemment 30 à 50 pour cent d'un développement natif, se met en ligne en quelques semaines, ne passe par aucune validation de store et ne paie aucun abonnement annuel de compte développeur. Elle prouve surtout une chose que le budget ne peut pas prouver : que quelqu'un veut de votre service.
Entre les deux extrêmes, il existe des marches intermédiaires très raisonnables. Publier sur une seule plateforme, ou mener un pilote avec 200 vrais utilisateurs pour quelques milliers de dollars, vous apprendra plus sur votre produit que six mois de réunions, et vous garderez la marge nécessaire pour construire ensuite la bonne version.
Voici le test le plus brutal et le plus utile que nous connaissions : si votre application se résume à un formulaire, une liste et une connexion, vos clients ne l'installeront pas, parce que personne ne consacre de la place sur son téléphone à une chose qu'il utilisera trois fois par an. Cela doit être une page de votre site, pas une icône. Chez Linkysoft, il nous est arrivé plus d'une fois de conseiller à un client de dépenser moins que ce qu'il venait nous demander, tout simplement parce qu'une application que personne n'ouvre coûte exactement autant à entretenir qu'une application qui rapporte, et que la facture de maintenance arrive dans les deux cas.
Comment lire un devis pour ne pas être surpris au septième mois
Cinq questions suffisent à départager deux propositions, et elles se posent avant la signature, jamais après :
- Qu'est-ce qui est explicitement exclu ? Un devis sérieux contient une liste de ce qu'il ne fait pas, et c'est souvent la partie la plus instructive du document.
- Qui possède le code source et les comptes des stores ? La réponse doit être vous, par écrit, avec les identifiants à votre nom.
- Quel est le tarif horaire pour les modifications après le lancement ? Un prestataire qui refuse de le fixer maintenant le fixera quand vous n'aurez plus le choix.
- Que se passe-t-il quand une mise à jour du système casse l'application ? Délai d'intervention, prise en charge, et qui paie.
- Qui détient la clé de signature ? Sans elle, personne ne peut publier une nouvelle version de votre application, pas même vous.
Sur la forme du contrat, ne croyez pas qu'un prix ferme soit une assurance gratuite : la marge de sécurité est déjà incluse dans le nombre que vous avez accepté. Un prix ferme convient quand le périmètre est défini au détail près, tandis qu'une facturation au temps passé convient quand le produit se cherche encore, et le pire des deux mondes consiste à signer un prix ferme sur un périmètre flou, puis à payer chaque précision en avenant. Exigez par ailleurs que la première année de maintenance soit chiffrée dans le même document que le développement, faute de quoi vous signez sans connaître le vrai total.
Demandez enfin quelles données l'application conserve, où elles sont stockées et qui peut les lire, car une fuite coûte infiniment plus cher que l'audit qui l'aurait évitée. Un examen de sécurité informatique avant la mise en ligne représente quelques jours de travail, et c'est le meilleur rapport entre dépense et tranquillité de tout le projet. Si le sujet vous paraît lointain, parcourez nos articles sur la sécurité des applications avant votre prochain rendez-vous.
Un total sur cinq ans, calculé de bout en bout
Prenons un cas concret et suivons-le jusqu'au bout. Une entreprise de services fait développer une application multiplateforme de trente écrans pour environ 45 000 dollars. Sa première année de fonctionnement se décompose ainsi : environ 7 500 dollars de maintenance et de mises à jour système, environ 3 000 dollars d'hébergement et de base de données, environ 1 800 dollars de services tiers comme les SMS et les cartes, environ 600 dollars de surveillance des erreurs et 124 dollars de comptes Apple et Google, soit à peu près 13 000 dollars. Sur cinq ans, le total atteint donc environ 110 000 dollars, et le développement, ce chiffre unique qui occupait toute la discussion au départ, ne représente plus qu'environ 41 pour cent de la dépense réelle.
Transformez maintenant ce total en décision, ce que vous pouvez faire à votre bureau en deux minutes. Cent dix mille dollars sur cinq ans reviennent à environ 1 830 dollars par mois, ce qui veut dire que l'application doit vous rapporter ou vous faire économiser plus que cette somme chaque mois pour mériter d'exister. Comptez les commandes supplémentaires, les rendez-vous qui ne seront plus manqués, les heures de saisie évitées, puis comparez. Si le compte n'y est pas, la réponse honnête est de ne pas construire, ou de construire beaucoup plus petit.
Le même raisonnement fonctionne évidemment plus bas dans l'échelle. Une application du premier palier développée pour 12 000 dollars coûte environ 4 000 dollars par an à faire vivre, soit environ 32 000 dollars sur cinq ans, ce qui représente un peu plus de 530 dollars par mois : un seuil que beaucoup de commerces franchissent dès la première année, alors qu'ils auraient renoncé en regardant le total sans le ramener au mois.
Si vous voulez ce calcul pour votre projet à vous, ligne par ligne et sans pression, nous le faisons volontiers avant que vous ne vous engagiez sur quoi que ce soit : écrivez-nous depuis la page contact avec la liste de vos écrans, même approximative, et regardez au passage nos études de cas pour voir des budgets, des délais et des résultats sur des projets voisins du vôtre. Vous repartirez de chez Linkysoft avec un chiffre sur cinq ans que vous pourrez défendre devant votre associé ou votre banque, et avec notre avis franc sur la question de savoir s'il faut le dépenser.
Mots-clés
- coût de développement d'une application mobile
- combien coûte la création d'une application
- coût de maintenance annuel d'une application
- prix d'une application iOS et Android
- natif ou multiplateforme, quel coût
- frais et commission des stores
- coût de publication d'une application
- agence de développement d'applications mobiles
