Ma stack qui ne coûte (presque) rien

Chaque produit est un dossier, et chaque dossier est son propre dépôt Git. Au-dessus, un dossier racine qui les tient tous, avec un fichier qui dit en une ligne où en est chacun : son domaine, son statut (en construction, en pause, en ligne sans ambition), et ce qu'il ne faut surtout pas casser.

Pourquoi un fichier et pas un Notion ? Parce que je code avec Claude Code, et que ce fichier, il le lit à chaque session. Il sait tout de suite quel site est en test, lequel a de vrais utilisateurs, et où sont les clés. Je ne réexplique jamais le contexte.

À côté des produits, trois dossiers qui ne sont pas des produits : l'usine (_ops, le modèle de nouveau projet), les secrets (_secrets, jamais dans Git) et les chiffres de chaque site (_cockpit).

cockpit/├── CLAUDE.md  # la table des produits : nom, domaine, statut, garde-fou├── .claude/skills/  # les process partagés (SEO, scripts vidéo…)├── _ops/  # l'usine : le modèle de nouveau produit, les scripts├── _secrets/  # les clés, par produit — jamais dans Git├── _cockpit/  # les chiffres de chaque produit├── deviensdev/  # un dossier = un produit = un repo│   ├── CLAUDE.md  # ce que l'IA doit savoir de ce produit│   ├── apps/marketing/  # Astro → Cloudflare│   ├── apps/app/  # Next.js + Better Auth + Neon → Vercel│   └── docs/roadmap/  # ce qui reste à faire├── photocv/  # même forme├── templatefox/  # même forme, + un backend/ → Cloud Run└── …  # une dizaine en tout

Un produit, ce n'est pas un site. C'est deux choses qui n'ont pas les mêmes besoins :

• Le site marketing — l'accueil, les articles, les tarifs. Des pages qui ne changent pas d'un visiteur à l'autre. C'est là qu'arrive presque tout le trafic, de Google comme des réseaux.
• L'app — ce qu'on voit une fois connecté. Chaque page est différente pour chaque utilisateur, il faut un serveur, une base, des comptes.

Alors je les sépare : deux dossiers (apps/marketing et apps/app), deux déploiements, deux adresses — monproduit.com et app.monproduit.com. Et surtout, deux hébergeurs différents. Ce site-ci est construit exactement comme ça.

Mes sites marketing sont écrits avec Astro : au moment de la mise en ligne, il fabrique des fichiers HTML une bonne fois pour toutes. Plus de serveur qui calcule la page à chaque visite — juste des fichiers à envoyer.

Et des fichiers, Cloudflare adore ça. C'est écrit dans leur doc : les requêtes vers les fichiers statiques sont gratuites et illimitées, et rien ne t'interdit d'en faire un business. Mille visites ou un million, la facture ne bouge pas.

Si j'ai besoin d'un tout petit bout de code côté serveur (une redirection, un formulaire), il tourne au même endroit : 100 000 requêtes offertes par jour.

Vercel fabrique Next.js, et ça se sent : tu relies ton dépôt GitHub, chaque push est en ligne une minute plus tard. Pour la partie app, je n'ai jamais trouvé plus simple.

Par contre, leur modèle, c'est de te faire payer ce qui tourne chez eux : le transfert, les appels de fonctions. Des pages statiques, là-bas, passent dans le même compteur. Chez Cloudflare, elles sont gratuites. C'est pour ça que mon marketing n'y est pas : je ne paye pas pour servir des fichiers qui ne changent jamais.

Et une ligne à connaître : la version gratuite est réservée à un usage perso, non commercial. Un paiement, une pub AdSense, un client qui te paye pour le site — c'est déjà commercial. Mes applis qui encaissent sont donc sur l'offre payante.

Neon, c'est du Postgres — la base de données la plus classique du métier — mais en « serverless » : quand personne ne s'en sert, elle s'éteint, et tu ne payes pas. Quand une requête arrive, elle se rallume.

L'offre gratuite donne 0,5 Go par projet, sans carte. Pour une app qui démarre, c'est énorme : les comptes de milliers d'utilisateurs tiennent dans un demi-giga.

Et comme c'est du Postgres standard, le jour où tu veux partir, tu pars : ta base se copie ailleurs, ton code ne change pas.

Les comptes, c'est le piège classique : les services d'authentification clés en main sont gratuits au début, puis facturent par utilisateur actif. Ton app marche, ta facture grossit avec elle.

Better Auth, c'est l'inverse : une bibliothèque open source que tu installes dans ton app. Les utilisateurs, les sessions, les mots de passe sont rangés dans ta propre base — ici, Neon. Pas de service à part, pas de compteur. Dix utilisateurs ou dix mille, ça coûte pareil : rien de plus que ta base.

Certains produits ont besoin de plus qu'une app : du Python qui génère des fichiers, un robot qui parcourt des sites, un appel à une IA qui dure. Ça, je le mets dans un conteneur, et je le donne à Cloud Run.

C'est du serverless : pas de machine allumée en permanence. Une requête arrive, Google démarre ton conteneur, il répond, il s'arrête. 2 millions de requêtes gratuites par mois, et au-delà tu payes ce qui a vraiment tourné.

La contrepartie, c'est le démarrage à froid : si personne n'a appelé depuis un moment, le premier visiteur attend que le conteneur démarre. Pour un traitement en arrière-plan, on s'en fiche. Pour une page que quelqu'un attend devant son écran, à toi de voir — tu peux garder une instance allumée en permanence, mais celle-là, tu la payes.