Comment réduire les coûts d'hébergement de votre application

Pour réduire les coûts d'hébergement, identifiez ce qui tourne réellement et pourquoi, puis laissez tout se mettre en veille lorsque personne ne l'utilise. Chez les hébergeurs qui passent à zéro, une app inactive et une base endormie coûtent très peu. Les plus grosses économies viennent donc généralement de la suppression de ce qui les maintient éveillées, le plus souvent un code qui interroge la base de données toutes les quelques secondes, puis de la réduction de la bande passante et de la suppression des apps que personne n'utilise.

La plupart des petites apps n'ont pas un problème de trafic. Elles ont un problème de « quelque chose tourne en permanence ». Ce guide montre comment le trouver et le corriger, avec des prompts à donner à un créateur d'apps IA.

Ce que vous payez réellement

Les factures d'hébergement des petites apps proviennent d'un petit nombre de postes. Savoir lequel est élevé indique où chercher.

De nombreux hébergeurs modernes, dont Mythex, passent à zéro : lorsque personne n'utilise l'app, le serveur s'arrête et ne coûte rien en calcul, puis il se réveille à la prochaine visite. La question n'est plus « quelle est la taille de mon serveur ? » mais « pourquoi mon serveur est-il éveillé ? »

Étape 1 : regarder où part l'argent

Avant de modifier quoi que ce soit, ouvrez la page d'utilisation de votre hébergeur et repérez :

• Quel projet coûte le plus cher. Souvent, une seule app représente la plus grande partie de la facture.
• Quelle catégorie : calcul, base de données, bande passante ou stockage.
• Quand la dépense a lieu. Une consommation constante la nuit, quand vous n'avez pas d'utilisateurs, indique que quelque chose maintient l'app éveillée.

Sur Mythex, les détails d'utilisation affichent les 30 derniers jours répartis entre Build (l'agent IA) et Run (hébergement, bande passante, base de données et stockage de fichiers), avec une ventilation par projet.

Étape 2 : laisser les apps et les bases inactives dormir

C'est le levier principal pour la plupart des petites apps. Une base qui se met en veille lorsqu'elle est inactive, et qui se réveille à la requête suivante, coûte presque rien pendant les heures calmes. Une base interrogée toutes les quelques secondes n'est jamais inactive, vous la payez donc toute la journée.

Les limites d'hébergement de Mythex détaillent ce fonctionnement pour les apps publiées : une app en veille ne consomme rien en calcul, la base démarre à sa taille minimale, grandit pendant les pics d'activité, se met en veille après 5 minutes d'inactivité, et est facturée selon sa taille multipliée par la durée pendant laquelle elle était éveillée. Ainsi, une app qui interroge sa base même une fois toutes les quelques minutes, jour et nuit, est facturée comme si elle était toujours occupée, alors que la même app sans activité de fond coûte très peu.

Ce qui maintient souvent une app éveillée :

• Les requêtes permanentes (polling). Une page qui demande au serveur « quoi de neuf ? » toutes les 2 à 5 secondes. Si cet onglet reste ouvert sur un seul ordinateur, la base ne se met jamais en veille.
• Les tableaux de bord qui se rafraîchissent automatiquement et rechargent les données à intervalles réguliers, même lorsque personne ne les regarde.
• Les surveillances de disponibilité qui envoient une requête à l'app chaque minute.
• Les boucles d'arrière-plan dans le code serveur, par exemple un setInterval qui nettoie ou synchronise les données en permanence.
• Les requêtes « keep-alive » programmées ajoutées pour éviter une première visite lente. Elles fonctionnent en empêchant la mise en veille, ce qui coûte précisément de l'argent.

Demandez à l'IA de les trouver :

Parcours le code à la recherche de tout ce qui s'exécute à intervalles réguliers ou interroge la base de données de façon répétée : polling, setInterval, rafraîchissement automatique, boucles d'arrière-plan. Liste chacun, sa fréquence d'exécution, et s'il tourne lorsque personne n'a la page ouverte. Ne modifie encore rien.

Puis corrigez-les un à un :

Le tableau de bord interroge /api/orders toutes les 3 secondes. Modifie-le pour qu'il ne se rafraîchisse que lorsque l'onglet du navigateur est visible, et toutes les 60 secondes au lieu de 3. Ajoute un bouton Actualiser manuel.

Si votre app a réellement besoin de mises à jour en direct (un chat, un tableau de scores en direct), demandez si elle peut envoyer les mises à jour uniquement lorsque quelque chose change, au lieu de demander en permanence. Pour beaucoup d'apps, « rafraîchir quand l'utilisateur revient sur l'onglet » suffit.

Étape 3 : dimensionner correctement le serveur

Les machines plus grandes coûtent plus cher à l'heure. Beaucoup d'apps créées avec l'IA démarrent sur une taille par défaut suffisante ; les problèmes viennent de la demande de « plus de puissance » pour corriger une lenteur qui était en réalité une requête lente.

• Gardez la plus petite taille qui sert votre trafic sans erreurs.
• Si vous constatez des plantages de mémoire, demandez d'abord à l'IA si l'app charge trop de données en mémoire (une table entière au lieu d'une seule page de résultats).
• N'ajoutez des machines que si vous avez mesuré un trafic qui les justifie.

Sur Mythex, la taille de la machine est choisie à la publication selon les besoins de l'app ; des machines supplémentaires ne démarrent que lorsque le trafic est élevé, puis se remettent en veille quand il baisse. Le coût suit la taille : si vous pensez qu'elle est surdimensionnée, demandez dans le chat une taille plus petite.

Étape 4 : réduire la bande passante

La bande passante correspond à ce que téléchargent les visiteurs. Les images en représentent généralement la plus grande part.

• Compressez les images et servez des formats modernes comme WebP ou AVIF.
• Redimensionnez les images à la taille à laquelle elles sont affichées. Une photo de 4 000 pixels affichée en miniature de 400 pixels gaspille l'essentiel de ce qui est téléchargé.
• Activez le chargement différé pour les images situées sous la ligne de flottaison.
• Mettez en cache les fichiers statiques (scripts, styles, images) pour que les visiteurs de retour ne les téléchargent pas à nouveau. Voir ce qu'est la mise en cache.
• Ne laissez pas l'app fournir de gros fichiers à chaque affichage de page.

Vérifie chaque image de l'app. Redimensionne-les à la plus grande taille à laquelle elles sont affichées, convertis-les en WebP et active le chargement différé pour tout ce qui se trouve sous le premier écran. Indique-moi la taille totale avant et après.

Des pages plus rapides et une bande passante plus faible vont généralement de pair ; voir comment rendre votre site web plus rapide.

Étape 5 : supprimer ce que personne n'utilise

• Dépubliez les anciennes apps : déploiements de test, expériences terminées, site de l'événement de l'an dernier.
• Supprimez les anciens envois, journaux et exports dont vous n'avez plus besoin.
• Supprimez les liens d'aperçu partagés que vous n'utilisez plus. Sur Mythex, ouvrir un lien d'aperçu réveille le projet et consomme vos crédits : un lien oublié que quelqu'un continue d'ouvrir coûte donc encore de l'argent.
• Retirez les services inutilisés, comme un serveur d'API ou un worker que l'app n'appelle plus.

Étape 6 : envisager un site statique

Si votre site n'a ni connexion, ni données utilisateur enregistrées, ni logique serveur (un site vitrine, un portfolio, une carte de restaurant), il peut être un site statique : de simples fichiers servis depuis un CDN. Il n'y a ni serveur ni base de données à faire tourner. Sur Mythex, les sites statiques ne consomment pas de crédits lorsqu'ils restent en place.

Ce site n'a ni connexion ni données enregistrées. Peut-il être reconstruit en site statique sans serveur ? Qu'est-ce qu'on perdrait ?

Étape 7 : surveiller les appels d'API payants

Pour les apps qui appellent des modèles d'IA, des cartes ou des SMS, les factures tierces peuvent dépasser celle de l'hébergement.

• Exigez une connexion pour tout ce qui coûte de l'argent à chaque appel.
• Ajoutez une limite par utilisateur (voir ce qu'est la limitation de débit).
• Mettez en cache les réponses qui ne changent pas, comme le géocodage d'une même adresse.
• Définissez des plafonds de dépenses ou des alertes chez chaque fournisseur.

Erreurs courantes

• Deviner au lieu de mesurer. Consultez d'abord la ventilation d'utilisation ; la partie coûteuse n'est souvent pas celle que l'on imagine.
• Acheter un serveur plus puissant pour corriger la lenteur. Un index de base de données manquant ou un chargement de données excessif est en général la vraie cause.
• Interroger tout en permanence. Chaque minuteur toutes les quelques secondes est une raison pour que la base reste éveillée.
• Envoyer des requêtes à l'app pour la garder « au chaud ». Cela annule l'économie que procure le passage à zéro. Acceptez un court réveil à la première visite, ou payez délibérément pour un service toujours actif.
• Oublier les anciens déploiements. Les apps inutilisées avec bases de données et tâches d'arrière-plan s'accumulent discrètement.
• Images non compressées. Souvent le plus gros poste de bande passante sur les petits sites.

Liste de contrôle

• Je sais quel projet et quelle catégorie (calcul, base de données, bande passante, stockage) coûtent le plus.
• Rien n'interroge la base de données toutes les quelques secondes lorsque personne ne regarde.
• Les tableaux de bord se rafraîchissent à un intervalle raisonnable ou seulement lorsque l'onglet est visible.
• Aucune surveillance de disponibilité ni boucle d'arrière-plan ne maintient l'app éveillée sans raison.
• Le serveur est de la plus petite taille qui fonctionne.
• Les images sont redimensionnées, compressées et chargées de façon différée ; les fichiers statiques sont mis en cache.
• Les anciennes apps sont dépubliées, les anciens fichiers supprimés, les liens d'aperçu inutilisés retirés.
• Les sites sans données ni connexion sont statiques.
• Les API payantes ont une connexion, des limites par utilisateur et des alertes de dépenses chez le fournisseur.

Réduire les coûts sur Mythex

Mythex utilise un seul solde de crédits pour la création et l'hébergement, donc les économies d'hébergement laissent plus de crédits pour créer. Quelques points propres à Mythex :

• Les apps publiées et leurs bases de données se mettent en veille lorsqu'elles sont inactives et se réveillent à la visite suivante. La base se met en veille après 5 minutes d'inactivité ; supprimer les requêtes permanentes est donc généralement le gain le plus important.
• Le forfait Pro paie la moitié du tarif Gratuit pour l'hébergement, les bases de données, la bande passante, le stockage de fichiers et le bac à sable d'aperçu ; l'IA coûte le même prix dans les deux forfaits. Voir Crédits.
• Vous recevez un e-mail avant qu'un solde faible ne mette en pause une app publiée, et les apps en pause conservent leur base de données et leurs fichiers.

Pour une vue d'ensemble des coûts de fonctionnement, consultez combien coûte la création d'une app et ce qu'est l'hébergement web.

Questions