Forfaits gratuits : qui les paie?

Une appli gratuite qui tourne tout le mois occupe autant de mémoire qu’une appli payante. La grille de prix du fournisseur dit ce que vaut cette mémoire, puisque c’est ce qu’il la facturerait.

• La mémoire inactive. Dix mille applis gratuites laissées en marche au prix de 7 $ de Render, c’est 70 000 $ de capacité par mois au prix affiché. La plupart reçoivent un visiteur par jour, au mieux.
• Le disque et les bases de données. Une appli en veille garde une image, un volume et souvent une base de données, et une base dort mal : elle garde des connexions, écrit des journaux et doit être sauvegardée.
• Les abus. Du calcul gratuit avec accès réseau sortant sert au minage de cryptomonnaie, au moissonnage, au pourriel et aux pages d’hameçonnage. Chaque cas coûte du temps au personnel, et l’hameçonnage sur votre domaine peut faire bloquer vos plages d’adresses IP pour les clients payants aussi.
• Le soutien. Les utilisateurs gratuits ouvrent des demandes. Y répondre coûte autant que répondre à un client payant.

Chaque fournisseur ci-dessous décrit son propre changement sur ses propres pages. Le fil commun : le calcul gratuit, illimité et toujours actif n’a pas résisté aux abus, et ce qui l’a remplacé échange la générosité contre des limites peu coûteuses à appliquer.

• La mise en veille. Arrêter l’appli quand personne ne l’utilise et la relancer à la requête suivante. La mémoire est la partie coûteuse, et une appli en veille n’en occupe aucune. Le coût passe au premier visiteur, qui attend.
• Des limites sur ce qui coûte. Plafonnez ce qui fait grossir la facture : trafic, temps de compilation, taille de la base, courriels. Un forfait gratuit qui limite les projets mais pas la bande passante invite quelqu’un à y héberger des fichiers.
• L’expiration. Render supprime les bases gratuites après 30 jours plus le délai de grâce. C’est dur, mais ça empêche le forfait gratuit de devenir du stockage permanent.
• La vérification. Railway examine l’âge et l’activité d’un compte GitHub avant d’accorder un essai complet. Toute étape facile pour un vrai développeur et coûteuse pour qui crée mille comptes est utile.
• La restriction du réseau. Le Limited Trial de Railway bloque l’essentiel du trafic sortant, ce qui retire la principale raison d’abuser du calcul gratuit.
• Les clauses d’usage commercial. Le forfait Hobby de Vercel est réservé aux projets personnels. Une clause n’empêche rien techniquement, mais elle indique aux entreprises quel forfait leur revient.

Le forfait Démarrage de Canner utilise les mêmes leviers. Les applis se mettent en veille après 3 heures sans requête et se réveillent à la suivante; le visiteur attend quelques secondes. Le trafic est plafonné à 250 Go par mois, comme mesure contre la fraude plutôt que comme argument de vente. Les applis ont 512 Mo de mémoire. Un projet Démarrage sans requête ni déploiement depuis 60 jours est suspendu, avec un courriel, et un redéploiement le ramène avec son code, ses variables et sa base de données intacts. Les forfaits payants ne sont pas suspendus, puisqu’ils paient la capacité. La documentation des déploiements décrit la veille et le réveil, et la page forfaits et limites donne le reste.

• Prévoyez le réveil. Une appli en veille répond lentement à sa première requête. Correct pour une démo, un portfolio ou un outil interne; pas pour un point de terminaison de webhook avec un délai de 10 secondes ou une page de paiement.
• Lisez les règles d’expiration avant de stocker des données. Une base gratuite supprimée après 30 jours est une base de test. N’y mettez pas les dossiers d’un client.
• Tenez pour acquis que les conditions changeront. Chaque ligne du tableau ci-dessus est un changement. Gardez votre appli portable : un Dockerfile ou une compilation standard, des variables d’environnement pour la configuration, et une base que vous pouvez extraire avec pg_dump.
• Sachez quand vous l’avez dépassé. Dès qu’un client payant dépend de l’appli, les limites du forfait gratuit deviennent votre niveau de service. Du projet personnel à la production couvre cette étape.

Le même calcul s’applique à votre produit. Mesurez ce que coûte un compte gratuit, comme dans coût d’hébergement par client, et divisez-le par le nombre de comptes qui passent à un forfait payant chaque mois. C’est ce que le forfait gratuit dépense pour gagner un client payant, et vous pouvez le comparer à toute autre façon d’en trouver un.

• Limitez ce qui coûte cher, pas la fonction qui montre la valeur. Si le courriel est votre plus gros coût, plafonnez les envois des comptes gratuits; laissez-les utiliser la fonction principale.
• Cessez de travailler pour les comptes inactifs. Suspendez les tâches en arrière-plan, les rapports programmés et la synchronisation des comptes que personne n’a ouverts depuis 30 jours.
• Vérifiez avant la partie coûteuse. Confirmez l’adresse courriel avant le premier envoi, et demandez une carte avant tout ce qui coûte vraiment de l’argent, comme les appels d’IA ou les textos.
• Écrivez les limites. Un forfait gratuit aux limites publiées peut changer avec un préavis. Un forfait aux limites « généreuses » changera avec des excuses.