Payer un abonnement pour un projet qu'on n'utilise plus : les applications dormantes

Cinq applications jamais publiées, quatre laissées de côté depuis des semaines, et un compteur qui avance quand même. Ce que coûte un projet qu'on n'ouvre plus, ce que cette dépense achète, et le moment où elle n'achète plus rien.

Payer un abonnement pour un projet qu'on n'utilise plus a un coût mesurable. Un utilisateur de Lovable raconte sur Reddit (r/lovable, juin 2026) que cinq applications jamais publiées, dont quatre laissées de côté depuis un à deux mois, consomment 2,67 crédits par jour, soit une projection de 80 crédits par mois sur une allocation Pro de 100.

Une application qui dort tourne quand même

Un projet hébergé chez l'éditeur reste allumé. L'adresse répond, la base attend une requête, l'aperçu se réveille au moindre passage. Le même utilisateur écrit avoir demandé s'il pouvait mettre ses projets inactifs en veille : la réponse de l'assistance a été non, il fallait soit accepter la consommation, soit supprimer les projets, et supprimer revenait à jeter le temps et les crédits déjà dépensés. Entre les deux, aucun bouton.

Le compteur avance sans dire pourquoi

Un autre utilisateur de la même plateforme a fait ses comptes sur trois mois (r/lovable, septembre 2026) : 1 364 crédits sur les 30 derniers jours contre 2 389 sur 90, soit 57 % de sa consommation trimestrielle concentrée sur le dernier mois. En reprenant 20 échanges un par un, il arrive à 14,07 crédits par message, de 8,9 à 21,1 selon l'échange, ce qu'il traduit par 70,4 % d'une allocation mensuelle de 400 crédits pour vingt interactions. Il écrit : « Pourquoi sommes-nous à ce point dans le noir ? » Le projet dormant pose la même question par l'autre bout, celle que nous avons déjà creusée sur ce que consomme un agent : arrêter une dépense qu'on ne voit pas.

Le piège tient à la façon dont on essaie des idées. On en teste trois pour n'en garder qu'une, ce qui est sain, sauf que les deux abandonnées restent allumées et facturées au même titre que celle qui marche. Aucune ligne de votre relevé ne porte la mention « projet laissé de côté en mars ». Vous voyez un total mensuel stable, un peu plus haut chaque trimestre, et il faut un après-midi de comptes pour découvrir que la moitié paie des applications que plus personne n'ouvre.

Ce que l'hébergement vous rend en échange

Cette dépense achète quelque chose. Une application qui reste en ligne pendant vos vacances, une adresse que vos clients retrouvent, des sauvegardes, des correctifs de sécurité posés par l'éditeur sans que vous ayez à les demander. Pour une boutique ou un outil que vos équipes ouvrent tous les jours, le service est réel et le facturer se défend. Le calcul se retourne sur les projets auxquels vous n'avez plus touché depuis deux mois : vous payez un serveur pour qu'il attende une visite qui ne vient pas, et vous ne pouvez pas repartir avec sans tout perdre.

Un projet fermé qui ne consomme rien

Maestro prend le problème par l'autre bout : le code et les documents de vos projets vivent sur votre Mac. Fermer un projet le laisse sur votre disque, sans serveur allumé pour lui et sans crédit qui s'écoule, et il n'y a rien à supprimer pour interrompre la dépense. Le travail des agents se paie selon l'offre de l'assistant : un abonnement peut rester dû même si vous ne travaillez pas, tandis qu'une API facture la consommation. Les dépenses d'IA de nos essais ne sont pas un budget total ; ajoutez la validation, la maintenance et les services ou l'hébergement du produit publié, qui peuvent continuer à être facturés lorsqu'un projet est fermé dans Maestro. Un projet rouvert dans six mois vous attend au même endroit, avec son cahier des charges et l'historique de ses versions.

En échange, Maestro s'arrête au code sur votre machine. Le jour où votre application doit répondre à vos clients depuis une adresse publique, il vous faudra un hébergeur, et cet hébergeur facturera son service comme les autres. La ligne de partage se trouve là : vos essais et vos brouillons ne coûtent rien tant qu'ils dorment, ce que vous mettez en ligne coûte ce qu'il coûte. Les outils qui ont ajouté un plafond de dépense traitent l'autre moitié du problème, celle du travail en cours. Cette différence a un envers que nous assumons : rien ne tourne pendant votre absence, donc rien ne se met à jour tout seul et personne ne surveille votre application à votre place. Un projet qui dort chez vous dort pour de bon, mises à jour de sécurité comprises, et c'est à vous de le rouvrir avant de le remettre en service.

Faire le compte ce soir

Ouvrez la liste de vos projets et notez, pour chacun, la date de la dernière fois que vous l'avez ouvert. Ceux qui dépassent deux mois forment votre facture dormante. Demandez ensuite à votre éditeur, par écrit, ce que consomme un projet inactif par jour et s'il existe une mise en veille : la question est légitime et la réponse écrite vous servira. Multipliez par douze, comparez au prix de tout garder, et pour ceux que vous ne rouvrirez jamais, récupérez le code chez vous avant de fermer la ligne d'abonnement.