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

Pour réduire les coûts d'hébergement, trouvez d'abord ce qui tourne réellement et pourquoi, puis laissez tout s'endormir lorsque personne ne l'utilise. Sur les hébergeurs qui mettent à zéro, une app inactive et une base de données endormie coûtent très peu; les plus grandes économies viennent donc généralement de la suppression de ce qui les garde éveillées, le plus souvent du code qui vérifie 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 de problème de trafic. Elles ont un problème de « quelque chose tourne toujours ». Ce guide montre comment le repérer et le corriger, avec des instructions à donner à un générateur d'apps IA.

Ce que vous payez réellement

La facture d'hébergement d'une petite app provient d'un petit nombre d'éléments. Savoir lequel est important indique où regarder.

De nombreux hébergeurs modernes, dont Mythex, mettent à 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 : Voir où passe l'argent

Avant de rien modifier, 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 il dépense. Une consommation constante la nuit, alors que vous n'avez pas d'utilisateurs, indique que quelque chose garde l'app éveillée.

Sur Mythex, Détails de l'utilisation affiche 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 dormir les apps et les bases de données inactives

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

Les limites d'hébergement de Mythex décrivent ce fonctionnement pour les apps publiées : une app endormie ne consomme rien en calcul, et la base de données démarre à sa plus petite taille, grandit pendant les périodes d'activité, s'endort après 5 minutes d'inactivité et est facturée selon sa taille multipliée par le temps pendant lequel elle était éveillée. Ainsi, une app qui interroge sa base de données ne serait-ce qu'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.

Voici ce qui garde couramment une app éveillée :

• L'interrogation. Une page qui demande au serveur « quoi de neuf? » toutes les 2 à 5 secondes. Si cet onglet reste ouvert sur un seul portable, la base de données ne s'endort jamais.
• Les tableaux de bord à rafraîchissement automatique qui rechargent les données selon une minuterie, même lorsque personne ne les regarde.
• Les moniteurs de disponibilité qui envoient une requête à l'app chaque minute.
• Les boucles d'arrière-plan dans le code serveur, comme un setInterval qui nettoie ou synchronise les données indéfiniment.
• Les requêtes de « maintien en vie » programmées qu'on a 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 selon une minuterie ou qui interroge la base de données de façon répétée : interrogation, setInterval, rafraîchissement automatique, boucles d'arrière-plan. Énumère chacun, indique à quelle fréquence il s'exécute et s'il s'exécute lorsque personne n'a la page ouverte. Ne modifie rien pour l'instant.

Puis corrigez-les un par 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 vraiment besoin de mises à jour en direct (un clavardage, un tableau de pointage en direct), demandez s'il est possible de pousser les mises à jour seulement lorsque quelque chose change, plutôt que de les demander constamment. Pour de nombreuses apps, « rafraîchir lorsque l'utilisateur revient dans l'onglet » suffit.

Étape 3 : Ajuster la taille du serveur

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

• Gardez la plus petite taille qui sert votre trafic sans erreurs.
• Si vous voyez des plantages liés à la 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 en a besoin.

Sur Mythex, la taille de la machine est choisie lors de 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, alors demandez dans le clavardage une taille plus petite si vous pensez qu'elle est surdimensionnée.

Étape 4 : Réduire la bande passante

La bande passante correspond aux données téléchargées par 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é.
• Utilisez 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 qui reviennent ne les téléchargent pas à nouveau. Voir qu'est-ce que la mise en cache.
• Ne laissez pas l'app remettre 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 charge en différé tout ce qui se trouve sous le premier écran. Indique-moi la taille totale avant et après.

Une page plus rapide et une bande passante réduite vont généralement de pair. Voir comment rendre votre site web plus rapide.

Étape 5 : Nettoyer 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 téléversements, journaux et exportations dont vous n'avez pas 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 toujours de l'argent.
• Retirez les services inutilisés : un serveur d'API ou un travailleur que l'app n'appelle plus.

Étape 6 : Envisager un site statique

Si votre site n'a ni connexion, ni données d'utilisateurs sauvegardées, ni logique serveur (un site vitrine, un portfolio, un menu), il peut être un site statique : des fichiers simples servis depuis un CDN. Il n'y a ni serveur ni base de données à faire tourner. Sur Mythex, les sites statiques ne consomment aucun crédit lorsqu'ils restent en ligne.

Ce site n'a ni connexion ni données sauvegardées. Peut-il être reconstruit comme site statique sans serveur? Que perdrions-nous?

Étape 7 : Surveiller les appels API payants

Pour les apps qui appellent des modèles d'IA, des services de cartes ou des SMS, les factures des tiers peuvent dépasser largement 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 qu'est-ce que 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 de l'utilisation; la partie coûteuse n'est souvent pas celle à laquelle on s'attend.
• Acheter un serveur plus gros pour corriger une lenteur. Un index manquant dans la base de données ou le chargement d'un trop grand volume de données est généralement la vraie cause.
• Interroger tout en continu. Chaque minuterie de quelques secondes est une raison pour que la base de données reste éveillée.
• Envoyer une requête à l'app pour la garder « au chaud ». Cela annule l'économie que procure la mise à zéro. Acceptez un court délai au premier accès, ou payez délibérément pour une disponibilité permanente.
• Oublier les anciens déploiements. Les apps inutilisées avec leurs bases de données et tâches de fond s'accumulent discrètement.
• Images non compressées. Souvent la plus grande dépense de bande passante des petits sites.

Liste de vérification

• Je sais quel projet et quelle catégorie (calcul, base de données, bande passante, stockage) coûtent le plus cher.
• 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.
• Aucun moniteur de disponibilité ni aucune boucle d'arrière-plan ne garde 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 en différé; les fichiers statiques sont mis en cache.
• Les anciennes apps sont dépubliées, les anciens fichiers supprimés et 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épense 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; les économies d'hébergement laissent donc plus de crédits pour créer. Quelques points propres à Mythex :

• Les apps publiées et leurs bases de données s'endorment lorsqu'elles sont inactives et se réveillent à la visite suivante. La base de données s'endort après 5 minutes d'inactivité; supprimer l'interrogation constante 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 courriel avant qu'un solde faible ne suspende une app publiée, et les apps suspendues conservent leur base de données et leurs fichiers.

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

Questions