GaijinToSensei : une app en production

Une app pour apprendre le japonais, en production avec des utilisateurs réels.

Next.js
PostgreSQL (Neon)
Prisma
Upstash Redis
Resend
Cloudflare Workers
Playwright
Bash

Contexte

Je suis seul sur le projet. Des agents Claude Code écrivent la plupart du code. Mon travail, c'est le cadre autour : comment le code arrive en prod, comment on sait qu'il marche, et comment on répare.

L'app tourne sur Cloudflare Workers (Next.js adapté par OpenNext), avec une base PostgreSQL serverless chez Neon (via Prisma), Redis chez Upstash pour limiter le débit et Resend pour les e-mails.

Problème

Beaucoup de changements par jour, plusieurs agents en parallèle, et un quota de déploiements par jour sur l'hébergeur d'origine.

Chaque mise en prod doit rester sûre : une version cassée ne doit pas rester en ligne, et deux déploiements ne doivent pas se marcher dessus.

Ce que j'ai fait

Une chaîne d'agents qui livre

Plusieurs agents travaillent en parallèle, chacun sur sa branche. Ils codent, testent (QA automatisée avec Playwright), fusionnent et déploient.
Des verrous évitent les conflits entre agents.
Les fusions s'accumulent sur la branche principale et partent en un seul déploiement, pour tenir dans le quota de la plateforme.

Une mise en prod contrôlée

Un script construit l'export exact d'un commit et le publie comme nouvelle version du Worker, sans trafic, puis vérifie les pages publiques sur l'adresse de cette version : code 200, titre, URL canonique, sitemap complet, robots.
La version ne reçoit le trafic qu'après ces contrôles. La branche principale n'avance qu'en avance rapide, jamais en force.
Après l'activation, le site est revérifié. En cas d'échec, le script revient seul à la version précédente et envoie une alerte.
Un verrou de fichier empêche deux mises en prod en même temps.
Toutes les 10 minutes, une tâche planifiée vérifie que la prod n'est pas en retard sur la branche principale. Si elle l'est, elle relance une mise en prod sûre. Sinon elle n'envoie qu'une alerte.

Migration de Vercel vers Cloudflare Workers

Le 5 novembre 2026, le compte gratuit Vercel a dépassé son quota d'usage et ses projets ont été coupés. J'ai migré l'app vers Cloudflare Workers le jour même, pour 5 $ par mois.
Devant l'app, un second Worker met en cache les pages publiques pour les visiteurs non connectés, jamais pour une session. Temps de réponse du serveur (TTFB) passé de 0,26-0,30 s à 0,07-0,09 s, LCP de l'accueil à 1,4 s.

Supervision et protections

Une route de santé vérifie la base, Redis, l'envoi d'e-mails et le stockage, avec un délai maximum par service et un cache court pour ne pas les surcharger.
Les erreurs serveur sont enregistrées en base et visibles dans une page Santé de l'outil d'administration.
Limitation de débit par fenêtres glissantes sur la connexion, le chat, les signalements et le support.
Depuis l'incident du 29 octobre 2026, les migrations de base sont additives uniquement. Le script refuse tout DROP, RENAME, TRUNCATE ou ALTER COLUMN, et n'applique jamais de migration lui-même.

Résultat

L'app est en production, avec des utilisateurs réels.
Les nouveautés partent groupées, ce qui tient dans le quota. Un déploiement qui échoue aux contrôles ne reste pas en ligne.

Ce que j'ai appris

Les garde-fous comptent plus que la vitesse. Un agent rapide sans garde-fou finit par casser la prod.
Une étape de déploiement doit pouvoir être annulée sans moi.
Une route de santé simple, appelée souvent, dit plus qu'un tableau de bord qu'on ne regarde pas.