Checklist dashboard Vercel : les réglages que le repo ne peut pas porter

État au 6 septembre 2026 : les six cases sont encore vides, douze semaines après l'audit qui a ouvert les cinq premières (la sixième arrive avec l'endpoint qu'elle surveille, platform-ops-22). Le repo ne sait donc PAS si Fluid Compute, Skew Protection, le Firewall, un drain de logs et la version Node sont actifs en production : une case cochée ici est la seule trace, et personne ne l'a cochée. Le titre annonçait « post-merge PR #272 », un cadrage qui n'a plus de sens à cette distance.

À faire une seule fois, ~30 minutes. Ces réglages ne sont PAS exprimables dans le repo (vercel.json ne les couvre pas), ils vivent dans l'interface Vercel — sauf le dernier, qui vit chez le fournisseur de monitoring et pointe sur une URL que le repo, lui, sert. Issus de l'audit plateforme du 11 juin 2026 (doc officielle vérifiée à cette date). Cocher au fur et à mesure.

1. ☐ Fluid Compute — LE plus important

Où : Project Settings → Functions → Fluid Compute → Enable

Pourquoi :

• Sans Fluid, le maxDuration par défaut Pro est 15 secondes : tout cron/route sans export explicite est tronqué silencieusement (les routes du repo exportent désormais toutes un budget, mais Fluid reste le filet).
• Avec Fluid : défaut 300s, plafond 800s, Active CPU pricing (CPU facturé seulement pendant l'exécution réelle) → économie massive sur les workloads I/O (streaming AI Gateway, Browserbase, scans Firecrawl).
• Les instances sont réutilisées entre invocations concurrentes → moins de cold starts → moins de passages du schema guard.

Vérifier après : Functions tab d'un deployment → "Fluid" badge ; la facture bascule sur Active CPU au cycle suivant.

2. ☐ Skew Protection

Où : Project Settings → Advanced → Skew Protection → Enable (max age : 1 jour suffit)

Pourquoi : un onglet ouvert AVANT un deploy continue d'appeler la version d'API qu'il connaît au lieu de la nouvelle (fini les erreurs client après chaque deploy). Activé par défaut uniquement pour les NOUVEAUX projets : celui-ci doit l'activer manuellement.

Note : complète le schema guard (drift client↔serveur vs code↔base), les deux sont nécessaires, aucun ne remplace l'autre.

3. ☐ Firewall — ruleset bot + rules ciblées

Où : Project → Firewall → Bot Management → activer le managed ruleset (mode "Challenge" recommandé après 24-48h en mode "Log")

Rules custom à ajouter (gratuites) :

• Challenge sur les bursts /api/auth/* (brute-force OTP/magic-link)
• Rate-limit WAF sur POST /api/status/subscribe (email bombing)

Pourquoi : le trafic bloqué par le firewall est gratuit et n'invoque jamais une fonction (l'app paie aujourd'hui chaque requête poubelle avant que le rate-limit Upstash la refuse). Upstash reste en place pour les quotas métier (par org, par plan) que le WAF ne voit pas.

4. ☐ Drain de logs (Axiom / Grafana Cloud / Datadog)

Où : Team Settings → Drains → Add Drain → Logs (+ Traces si dispo)

Pourquoi : le structured logger du repo a été conçu pour ça et aucun drain ne consomme, les logs meurent après la rétention Vercel. Une fois branché :

• requête failureKind=platform_credits_exhausted → alerte AVANT que les données se tarissent (crédits Firecrawl/Apify/AI Gateway épuisés)
• event:cron.*.started sans completed correspondant → identifie instantanément un cron tué par timeout
• les traces @vercel/otel déjà émises se corrèlent aux logs

Coût : ~0,50 $/GB côté Vercel + le plan du fournisseur (Axiom a un free tier généreux).

5. ☑ Version Node du projet — rien à cocher, le repo décide

Où : nulle part. Le repo pinne "engines": { "node": "22.x" } dans package.json (plus .nvmrc pour la CI et les postes), et la doc Vercel est explicite : une valeur dans engines écrase le réglage de Project Settings. Le dashboard peut afficher n'importe quoi, c'est engines qui est déployé — vérifié en production, le build journalise alors :

Warning: Due to "engines": { "node": "24.x" } in your package.json file,
the Node.js Version defined in your Project Settings ("22.x") will not
apply, Node.js Version "24.x" will be used instead.

Cette case demandait de faire correspondre le dashboard au repo pour éviter qu'ils divergent. La divergence n'a jamais été possible dans ce sens-là : le repo gagne toujours. La seule chose à faire est donc de ne pas retirer engines — c'est lui qui rend ce réglage sans objet.

Pourquoi pas 24.x, alors que ce serait le bon choix sur le papier. Node 22 est en Maintenance LTS depuis le 21 octobre 2025 et meurt le 30 avril 2027 ; Node 24 est l'Active LTS jusqu'au 30 avril 2028 et le défaut Vercel depuis novembre 2025. La montée a pourtant été faite puis annulée le 8 septembre 2026 : le commit qui la portait est le premier echec d'une serie de builds Vercel rouges, en preview et avant tout merge, avec tous ses voisins immediats verts. Le typecheck local passe sous Node 22, donc le code n'etait pas en cause.

La cause exacte reste inconnue — les logs Vercel n'etaient plus accessibles au moment du diagnostic. Refaire la montee demande d'abord de lire l'erreur de build, pas de rejouer le meme changement. Voir platform-ops/0552.

6. ☐ Moniteur externe sur /api/health

Où : chez le fournisseur de monitoring (UptimeRobot, Better Stack, Pingdom — le choix n'est pas dans le repo), pas dans le dashboard Vercel.

URL : https://www.boostecom.app/api/health (src/app/api/health/route.ts)

Reglage : GET toutes les 60 s, alerte a partir de 2 echecs consecutifs, timeout client 10 s. Le handler borne chaque sonde a 2 s et les lance en parallele, donc il repond en ~2 s meme quand les deux dependances pendent.

Ce que la reponse dit :

{ "ok": true, "checks": { "db": true, "cache": true }, "version": "<sha>" }

• 200 : la fonction sert, Postgres repond a un SELECT 1, Upstash repond a une lecture.
• 503 : au moins une des deux ne repond pas. La RAISON n'est jamais dans le corps (l'endpoint est public, sans authentification) : elle est dans le drain, sous health.degraded. C'est la case 4 ci-dessus qui la rend lisible — sans drain, ce moniteur dit qu'il y a une panne sans dire laquelle.
• Cache-Control: no-store : aucun CDN ne peut servir un « ok » perime pendant la panne. C'est exactement le defaut de /status, qui rend derriere un revalidate.

Pourquoi ce n'est pas /status : /status est une PAGE. Il faut un humain pour l'ouvrir, trois de ses neuf services sont codes en dur operational, et elle peut etre servie depuis le cache pendant la panne qu'elle est censee signaler. platform-ops-22.

Verifier apres : curl -i https://www.boostecom.app/api/health rend 200 et cache-control: no-store. Couper la variable KV_REST_API_URL sur un preview et verifier que le meme appel rend 503 avec "cache": false — un moniteur qu'on n'a jamais vu rougir n'est pas un moniteur.

Après les réglages : vérifications sous 24h

1. Logs : plus aucun DeduplicationId cannot contain ni timeout 300s inexpliqué.
2. refresh_hot.done avec orphansQueued > 0 puis = 0 (stores tenants ré-indexés).
3. Premier refresh_hot_deep.done (01:20/07:20/13:20/19:20 UTC), la couverture full-depth des stores focus démarre.
4. /admin/ai/intelligence/health : sonde Firecrawl verte avec le solde de crédits restants.

Une fois les 5 cases cochées, ce fichier peut rester comme référence d'onboarding ops — ou être supprimé.