Combien coûte la maintenance d’une application mobile : le coût serveur de 100 à 100 000 utilisateurs

Une application mobile qui tourne coûte de l’argent tous les mois, même les mois où personne ne touche au code. La question revient dans presque tous les premiers rendez-vous : « une fois l’application publiée, je paie combien ? » Les réponses vagues ne manquent pas. Alors on a préféré regarder des chiffres relevés sur une vraie montée en charge, palier par palier.

Le banc d’essai : une API de réseau social (publier, répondre, republier, aimer, se connecter), écrite avec FastAPI, adossée à une base Postgres, le tout dans des conteneurs Docker chez un hébergeur de type plateforme managée. La même application a été poussée de 100 à 100 000 utilisateurs simultanés, avec un outil de test de charge et un relevé du coût à chaque étage. C’est exactement le back-end qu’une application mobile appelle derrière ses écrans.

Attention au périmètre : cet article traite la partie serveur de la maintenance, celle qui tombe automatiquement sur la carte bancaire chaque mois. Le reste du budget (corrections, mises à jour d’OS, nouvelles fonctionnalités) se chiffre autrement, et on le détaille dans le guide des prix d’une application mobile. Ici, on cherche une chose : savoir quel palier vous coûtera quoi, et quel levier tirer quand ça coince.

Étape 1 : simuler la charge avant de la payer

Quand une application vit sur un serveur, elle encaisse ce qui arrive, sans prévenir. Un serveur donné absorbe une certaine quantité de trafic, et plus la machine est grosse, plus elle coûte cher. Le seul moyen honnête de savoir à quel étage vous êtes, c’est de fabriquer le trafic vous-même.

C’est le rôle des outils de test de charge. On les branche sur un environnement de recette, jamais sur la production, et on simule différents niveaux de trafic et d’interactions. L’intérêt : observer le comportement du système sous pression sans mettre en danger les vrais utilisateurs. Imaginez qu’un streamer connu lance votre jeu en direct et vous amène un pic de popularité en dix minutes. Vous préférez découvrir la réaction de votre serveur avant, ou pendant ?

Le choix entre les deux se joue surtout sur votre confort : celui que votre équipe sait lire produira de meilleures décisions que celui qui a la plus belle documentation.

Un détail qui change tout, et qu’on répète en cadrage de projet : le type d’application dicte le résultat. Une application qui lit beaucoup et écrit peu ne se comporte pas du tout comme une application qui écrit à chaque geste. C’est une donnée à poser noir sur blanc dans le cahier des charges, parce qu’elle conditionne l’infrastructure et donc la facture mensuelle.

Étape 2 : le palier 100 utilisateurs, le socle

Le premier déploiement est volontairement minuscule : une seule instance de serveur avec 0,3 CPU et 0,3 Go de RAM, plus une base Postgres 17 dotée de 0,25 CPU et 0,25 Go. Sur le papier, c’est ridicule. Dans les faits, ça encaisse déjà beaucoup pour ce que fait l’application.

Le tir de calibrage monte à 60 utilisateurs pour environ 200 requêtes par seconde, avec un outil de suivi d’erreurs branché pour repérer les bogues au passage. Voici ce que donne le palier des 100 utilisateurs actifs, ceux qui utilisent l’application intensément :

1. Environ 15 $ par mois pour l’ensemble serveur plus base de données.
2. 20 % de CPU consommé en moyenne, donc quatre cinquièmes de marge.
3. 500 à 600 Mo de mémoire en moyenne, en grande partie à cause du cache.
4. 45 ms de temps de réponse, ce qui est confortable.
5. Un profil d’usage réaliste : 70 % de lecteurs, 30 % de créateurs de contenu.

Une nuance qui compte pour votre budget : à ce niveau de consommation, beaucoup d’hébergeurs vous rangeraient dans leur offre gratuite et ne factureraient rien du tout. Autrement dit, les premiers mois d’une application qui démarre coûtent souvent zéro côté serveur. Ce n’est pas là que se joue votre trésorerie.

Étape 3 : le palier 1 000, quand le code coûte plus cher que le serveur

On garde exactement le même déploiement et on pousse le curseur à 1 000 utilisateurs maximum, avec une arrivée de 5 nouveaux utilisateurs par seconde, ce qui donne 10 à 15 requêtes par seconde. Le résultat surprend.

Aux alentours des 1 000 utilisateurs, tout ralentit : une dizaine de secondes de temps de réponse. Et le point de blocage n’est pas celui qu’on attendait. Ce n’est pas la base de données, qui reste parfaitement calme, c’est un seul endpoint : celui qui enregistre les « j’aime ». Le code appelait plusieurs fois la base sans même vérifier le cache.

Après refactorisation de cet endpoint, la situation s’améliore un peu, mais vers 605 utilisateurs simultanés la courbe repart en flèche et ne redescend plus. Le goulot d’étranglement est visible : le processeur. Pour un demi-CPU tenant 500 utilisateurs actifs, la performance reste honorable, sauf que 10 secondes d’attente sur un écran mobile, personne ne l’accepte.

Retenez la leçon budgétaire : à ce palier, un après-midi de développement vaut mieux qu’une machine plus grosse. Une requête inutile supprimée, c’est un poste de coût qui disparaît définitivement, alors qu’un serveur plus gros se paie tous les mois.

Étape 4 : le scaling vertical, 8 $ pour doubler le processeur

Le levier le plus simple reste la machine plus grande. Chez la plupart des hébergeurs, les tailles se choisissent dans une grille : un premier étage à 0,3 CPU pour 0,3 Go, puis des paliers standards qui doublent à chaque cran, jusqu’à 8 CPU et 16 Go, avec des gammes optimisées pour le calcul.

Le résultat est net : la nouvelle machine encaisse la totalité de la charge. Un seul incident sur toute la session, et il vient d’une configuration mal réglée : au-delà de 730 utilisateurs actifs, un des workers du serveur d’application redémarrait en boucle, ce qui a fait monter légèrement le taux d’échec. Au pire moment, le temps de réponse plafonnait à 1 400 ms. Ce n’est pas brillant, mais l’application reste utilisable.

Traduction pour un budget de maintenance : entre 100 et 1 000 utilisateurs actifs, on parle d’une différence de l’ordre de quelques dollars par mois. Le coût réel de ce palier, c’est le temps humain passé à trouver le worker qui se relance, pas la ligne d’hébergement.

Étape 5 : le palier 10 000, sortir le cache et débloquer les threads

Changement d’échelle : 10 000 utilisateurs maximum, avec 35 arrivées par seconde. Premier obstacle, et il est cocasse : en envoyant 30 000 requêtes par minute, c’est la connexion Internet de la machine qui génère le test qui a lâché, avec 54 % d’échecs à la clé. Le problème n’était pas le serveur testé, mais le testeur.

La parade s’appelle le test de charge distribué : un serveur maître pilote des serveurs enfants, et chacun héberge une partie des utilisateurs virtuels. Locust sait le faire nativement. Le revers, c’est qu’il faut déployer plusieurs machines puissantes, et ça se paie.

Côté application, deux décisions ont tout changé :

1. Déporter le cache. Le cache vivait dans la mémoire du serveur, ce qui expliquait les 500 à 600 Mo consommés. Plutôt que d’acheter encore de la RAM, on le pousse dans un magasin clé-valeur (Redis) ajouté à côté, avec une variable d’environnement à renseigner. La mémoire du serveur applicatif redevient disponible pour servir des requêtes.
2. Changer le type de worker. Le serveur qui reçoit les requêtes HTTP tournait avec des threads bloquants, ce qui exploitait mal le processeur. Le passage à un mode asynchrone (gevent) a débloqué la situation.

Résultat : 10 000 utilisateurs actifs tenus simultanément, avec 800 à 850 requêtes par seconde, à l’exception d’un petit pic. Deux réglages, aucune dépense supplémentaire de machine.

Étape 6 : le palier 100 000, horizontal, pool de connexions et facture à l’heure

Arrivé là, on arrête d’agrandir la machine et on en ajoute plusieurs. C’est le scaling horizontal : au lieu d’une instance qui grossit sans fin, plusieurs instances reçoivent le même trafic réparti. La règle appliquée ici : dès que le CPU dépasse 80 %, une nouvelle instance se déploie et prend sa part du trafic. Le plafond a d’abord été fixé à 5 instances, puis relevé à 10, la base de données étant, elle, agrandie verticalement.

Pour un réseau social, ce mode a un avantage financier direct : on ne paie que le temps pendant lequel les machines tournent. En cas de pic soudain, vous ne payez les serveurs supplémentaires que sur la durée du pic. Encore faut-il savoir quand vos utilisateurs se connectent, ce qui devient un vrai sujet d’analyse.

Le coût du test lui-même devient visible. Pour simuler 100 000 utilisateurs, il a fallu mobiliser une vingtaine de machines de 8 cœurs, à environ 0,35 $ de l’heure chacune, soit près de 3,50 $ pour un quart d’heure de test. Un test de charge sérieux ne coûte donc pas une fortune, à condition de ne pas le relancer cinquante fois.

La simulation à 100 000 a demandé un contournement (augmenter le nombre de requêtes par utilisateur pour compenser les utilisateurs virtuels manquants), des serveurs de secours et une mise à niveau supplémentaire. Mais la vraie différence est venue d’une brique posée entre les serveurs applicatifs et Postgres : un pool de connexions, PgBouncer, chargé de mutualiser les connexions à la base.

Avec ce dispositif, 10 000 à 15 000 requêtes par seconde ont été encaissées, malgré quelques ratés. Un poste n’a pas été testé et mérite d’être budgété à part : la diffusion de fichiers. L’application ne servait aucune image. Dès que vous en servez ou que vous en recevez, un réseau de diffusion de contenu (CDN) devient indispensable, et il s’ajoute à la note.

Ce que montrent les écrans, fonction par fonction

Un budget d’infrastructure ne se lit pas sur une facture, il se lit sur les écrans. Chaque bouton déclenche des lectures ou des écritures, et ce sont ces appels qui remplissent la ligne « hébergement ». Prenons quatre écrans réels, tels qu’ils sont présentés sur les fiches App Store françaises, et lisons-les comme un cahier des charges.

Ce qu’on voit : un champ de recherche unique, des onglets de catégories, puis un carrousel de logements déjà consultés, avec photo, ville, capacité et note. Le geste : ouvrir l’application, faire défiler du pouce, sans rien saisir. Le lien avec l’écran suivant : cette rangée personnalisée est le déclencheur au sens de Hooked (2014). Elle rappelle une intention laissée en plan et pousse au premier tap. Côté serveur, c’est de la lecture pure, plusieurs requêtes par ouverture, exactement le profil « 70 % de lecteurs » qui restait à 45 ms sur le banc d’essai. Ce type d’accueil se détaille dans notre modèle d’application Airbnb.

Ce qu’on voit : un en-tête qui rappelle les critères, un accès aux filtres, et des cartes plein écran comportant chacune un carrousel de photos. Le geste : faire défiler, balayer les photos, taper le cœur. Le lien avec l’écran suivant : c’est l’action, suivie de la récompense variable, puisqu’on ne sait jamais quel logement apparaîtra plus bas. Pour l’infrastructure, l’addition est différente : autant d’images à servir que de cartes affichées, donc le fameux CDN, plus une écriture à chaque cœur touché. Souvenez-vous de l’endpoint « j’aime » qui a fait plier le serveur bien avant la base de données.

Ce qu’on voit : une liste sobre, une entrée par cours, un chevron à droite, un bouton de fermeture en haut. Le geste : parcourir puis choisir une seule ligne. Le lien avec l’écran suivant : ce choix est un investissement. L’utilisateur dépose une préférence que l’application stockera et réutilisera pour tous ses déclencheurs futurs, notifications comprises. Une écriture unique, une valeur durable : le meilleur rapport coût sur bénéfice de toute l’application. Le parcours complet est décortiqué dans notre modèle d’application Duolingo.

Ce qu’on voit : une progression en haut, quatre vignettes cliquables, un retour immédiat « Bien joué » et un bouton unique. Le geste : taper une image, puis « Continuer », des dizaines de fois par session. Le lien avec l’écran suivant : action, récompense variable et investissement s’enchaînent dans la même seconde, et la boucle repart. C’est le profil le plus coûteux pour un back-end : chaque réponse est une écriture, la progression doit rester cohérente, et le cache doit être invalidé au bon moment. C’est précisément là qu’un cache déporté et des workers asynchrones cessent d’être un luxe.

Les erreurs fréquentes

• Tester en production. Le test de charge se fait sur un environnement de recette, sinon vous découvrez vos limites en même temps que vos utilisateurs.
• Confondre le coût du service et le coût du test. Les machines qui génèrent la charge coûtent parfois plus cher, à l’heure, que le serveur testé.
• Acheter de la RAM pour un cache mal placé. Un cache logé dans la mémoire du serveur applicatif gonfle la taille de machine à louer. Déporté, il coûte moins et scale mieux.
• Laisser la configuration par défaut. Un type de worker inadapté, un processus qui redémarre en boucle : ces réglages font varier la capacité d’une machine du simple au multiple, sans changer une ligne de facture.
• Oublier les fichiers. Un test sans images ne dit rien du jour où vous servirez des photos. Le CDN se budgète séparément.
• Croire à un prix universel par utilisateur. Une application avec un long traitement gourmand en calcul et une application qui interroge sa base en permanence n’ont pas le même profil de coût. Chaque produit demande sa propre analyse.
• Raisonner sur une application figée. Le banc d’essai portait sur une application terminée, sans nouvelle fonctionnalité. Dans la vraie vie, vous déployez de nouvelles versions en continu, et le dimensionnement se refait à chaque étape. C’est un processus itératif, pas un réglage définitif.

Questions fréquentes

Combien coûte l’hébergement d’une application mobile au démarrage ?

Sur le banc d’essai décrit ici, 100 utilisateurs actifs et intensifs tenaient pour environ 15 $ par mois, serveur et base de données compris. Et à ce niveau de consommation, beaucoup d’hébergeurs classent ce type de charge dans leur offre gratuite. Pour le coût global d’un projet, au-delà de la seule infrastructure, consultez notre guide des prix.

Pourquoi la base de données n’est-elle presque jamais le premier problème ?

Parce qu’une base bien indexée absorbe un volume de requêtes très supérieur à ce que le serveur applicatif sait produire. Sur toute la montée en charge de 100 à 1 000 utilisateurs, c’est le processeur du serveur d’API qui a saturé, jamais Postgres. La base n’a demandé de l’attention qu’à partir des dizaines de milliers d’utilisateurs, et encore, à travers un pool de connexions.

Vaut-il mieux une grosse machine ou plusieurs petites ?

Les deux, dans cet ordre. Agrandir la machine est le geste le plus simple et coûte quelques dollars par mois au début. Multiplier les instances devient pertinent quand le trafic est irrégulier, puisque vous ne payez alors que le temps d’exécution réel des machines supplémentaires.

Combien coûte un test de charge à grande échelle ?

Simuler 100 000 utilisateurs a demandé une vingtaine de machines de 8 cœurs, autour de 0,35 $ de l’heure chacune, soit environ 3,50 $ pour un quart d’heure. Le coût réel n’est pas la machine, c’est le temps passé à interpréter les courbes et à corriger ce qu’elles révèlent. Si vous voulez chiffrer cet accompagnement sur votre projet, demandez un devis.

Quiz : avez-vous tout retenu ?

À 100 utilisateurs actifs, quel était le coût mensuel relevé pour le serveur et la base ?

• Environ 1 $
• Environ 15 $
• Environ 150 $
• Environ 1 500 $

Environ 15 $ par mois, avec 20 % de CPU utilisé et 45 ms de temps de réponse. Beaucoup d’hébergeurs ne factureraient même pas cette charge.

Vers 1 000 utilisateurs, quel composant a saturé en premier ?

• La base de données Postgres
• Le processeur du serveur applicatif
• Le réseau de diffusion de contenu
• Le stockage disque

Le CPU du serveur d’API. Postgres est resté parfaitement calme pendant que les temps de réponse montaient à une dizaine de secondes.

Comment la mémoire a-t-elle été libérée avant le palier des 10 000 utilisateurs ?

• En achetant une machine avec plus de RAM
• En désactivant complètement le cache
• En déportant le cache dans un magasin clé-valeur (Redis)
• En compressant les images servies

Le cache occupait la mémoire du serveur applicatif. Déplacé dans Redis, il libère la machine sans qu’on paie une taille supérieure.

Quelle brique a fait la différence pour tenir 100 000 utilisateurs ?

• Un second nom de domaine
• Un pool de connexions PgBouncer devant Postgres
• Le passage à une base NoSQL
• La suppression du cache

PgBouncer, placé entre les serveurs applicatifs et la base, mutualise les connexions. C’est ce qui a permis d’encaisser 10 000 à 15 000 requêtes par seconde.

Une dernière chose, et elle vaut pour tous les paliers : garder une application disponible en permanence reste difficile. Des pics de trafic imprévus, une configuration oubliée, un endpoint mal écrit, et la note grimpe pour de mauvaises raisons. Si vous préparez le lancement, nos guides sur la publication sur l’App Store, sur les bases de l’ASO et sur le choix entre Flutter et React Native complètent utilement ce chiffrage.

Besoin d’un avis technique sur votre projet d’application ?

Derrière ce guide, il y a des développeurs mobiles en exercice. On répond aux questions techniques, on chiffre les projets, et on dit aussi franchement quand une idée n’est pas prête.

Choisir un créneau

Par téléphone : 06 32 64 24 80

Cadre du projet, ensuite

Un tutoriel store ou technique ne remplace pas un cahier des charges. Quand le périmètre existe (deux stores, un back-office, un paiement), ouvrez le modèle de CDC, les fourchettes du guide des prix, et la grille de devis. Les captures annotées de nos articles suivent la même logique que l’analyse d’écrans du CDC : une source réelle, une exigence écrite, pas une moodboard.

Fourchettes HT, France : MVP 15 000 à 40 000 €, ambition moyenne 40 000 à 120 000 €, complexe 120 000 à 300 000 €. Maintenance 15 à 20 % par an. Aucune note d’avis sur les agences : le classement est Sirene, millésimé, déclaré.

Un e-mail par semaine, et rien d’autre

Chaque semaine : un tutoriel mobile, les actualités des stores, les prix constatés qui bougent, et rien à vendre. Désinscription en un clic.

Votre adresse e-mail Je m’abonne

Aucune revente d’adresse. Vos données

Par la rédaction d’Agence Application Mobile. Article publié le 21 août 2026.