Le coût caché du gratuit : quand ma console brûlait mes crédits Netlify à chaque clic

Vingt publications gratuites par mois, consommées en une seule journée de tri. Enquête sur trois fuites de déploiement dans Feed Me Odd, et ce qu'elles disent des automatisations « gratuites ».

Feed Me Odd est hébergé sur Netlify. Quand Netlify est passé à une facturation en crédits, la règle est devenue simple : une mise en production coûte 15 crédits, le plan gratuit en donne 300 par mois. Vingt publications. Le 18 septembre, elles étaient toutes parties, en une seule journée. Aucune ligne du site n'avait changé ce jour-là. J'avais simplement trié des sujets dans ma console. Voici les trois fuites trouvées dans l'historique, et comment elles ont été bouchées. Fuite n°1 : la console publiait le site à chaque décision La console de curation enregistre ses décisions dans le dépôt : un fichier à chaque tri, un autre à chaque relecture. Ces fichiers ne sont jamais copiés sur le site. Mais Netlify, lui, voyait un commit, et reconstruisait tout. Une séance de tri pouvait vider l'allocation du mois. La correction (version 8.24) pose deux verrous : - la console marque ses commits privés d'un [skip netlify] : Netlify ne construit rien, et les GitHub Actions, qui ignorent ce marqueur, continuent de tourner ; - une règle dans la configuration de Netlify annule la construction quand seuls des fichiers privés ont changé, y compris pour les commits des robots. Le choix important est dans le détail : un chemin inconnu est traité comme public. Au pire on dépense un crédit de trop ; jamais on ne cache une correction aux lecteurs. Fuite n°2 : deux déploiements par jour, pour rien Deux jours plus tard, le tableau de bord montrait encore un déploiement « moisson » à 6 h et un déploiement « publication » à midi, un samedi et un dimanche, deux jours où rien n'était publié. 30 crédits par jour, 900 par mois. La cause : trois fichiers publics portaient une date de fabrication réécrite à chaque passage. Git voit un fichier modifié, il commite ; Netlify voit un commit, il reconstruit. Le site servi était identique au précédent, à un champ près que personne ne lit. La correction (8.25) : comparer le contenu en ignorant la date, et n'écrire que si le reste a bougé. Effet secondaire bienvenu : la date indique désormais le dernier vrai changement. Fuite n°3 : un compteur qui fondait tout seul Dernière trouvaille (8.26) : le compteur « nouveau cette semaine » était calculé au moment de la construction. Huit jours après chaque publication, il baissait tout seul, le fichier changeait, et le site repartait en production. Chaque publication coûtait deux déploiements. La solution est élégante : on n'écrit plus le compteur, on écrit le calendrier des sorties, une ligne par jour de publication, qui ne bouge plus jamais. La soustraction se fait dans le navigateur du lecteur. C'est moins cher, et plus juste : le chiffre ne dépend plus de l'heure à laquelle le robot a tourné. Ce que j'en retiens pour tous mes projets 1. « Gratuit » veut dire « avec un quota ». Dès qu'un service compte quelque chose, chaque automatisation doit répondre à la question : qu'est-ce qui déclenche quoi ? 2. Les horodatages sont les ennemis des automatisations. Un fichier qui change à chaque passage, même pour rien, déclenche toute la chaîne derrière lui. 3. Préférer les données qui ne bougent plus (un calendrier) aux valeurs recalculées (un compteur). 4. L'IA est excellente pour ce genre d'enquête si on lui donne les bons indices : le relevé du tableau de bord, les heures, les fichiers touchés. Elle a lu les trois écrivains de fichiers, trouvé les dates, et proposé des corrections éprouvées sur le code réel. Résultat : 5 à 9 déploiements par mois selon le rythme de publication, bien en dessous du plafond. Le plan gratuit redevient confortable.