09 — Maintenance

Le modèle mental à resservir au client : un site déployé est du compilé figé — il ne pourrit pas tout seul (les navigateurs sont ultra-rétrocompatibles). Ce qui « vieillit », c’est le code source / l’env de dev, et ça ne mord QUE le jour où on veut re-modifier le site. La question « est-ce que ça va péter ? » → le live, non ; l’entretien porte sur la capacité à re-modifier sans douleur.

Baseline à poser d’office (copier depuis le projet le plus à jour)

1. Lockfile commité (package-lock.json) → npm ci reproductible. Filet n°1, jamais retiré du repo.
2. Node pinné : .nvmrc (LTS) + engines.node (>=20 plancher). Cloudflare/Vercel respectent .nvmrc → même Node local/prod. Évite qu’un rebuild futur prenne un Node random.
3. .github/dependabot.yml : npm mensuel, minors/patchs groupés en 1 PR, jamais auto-mergé ; majeures isolées et délibérées. + alertes sécu GitHub natives.
4. MAINTENANCE.md (runbook racine) : modèle mental + procédure d’update (patch vs majeure + codemods npx @next/codemod) + déployer (preview→prod) + cadence + ce qui peut casser.
5. Avant tout deploy : npm run qa + npm run build verts, puis preview deploy avant prod → un build cassé n’atteint jamais la prod en silence.
6. Cadence réaliste vitrine : 1-2×/an (npm audit + patchs + rebuild + vérif). Majeures (Next/React/Tailwind) tous les ~1-2 ans, délibérées, jamais subies.

Option durabilité max (vitrine sans API/DB)

next.config → output: "export" + images: { unoptimized: true } ⇒ site 100 % statique, hébergeable n’importe où, quasi indestructible. Tradeoff : perd l’Image Optimization de next/image (compensé par le CDN Sanity).

Ce qui pourrait VRAIMENT casser (à dire honnêtement)

• Expiration domaine / hébergement.
• Fermeture ou changement d’API d’un service tiers branché sur un formulaire (Formspree/Brevo/CRM) ou le CDN Sanity.
• Un npm update majeur fait à l’aveugle puis redéployé sans test.

Pas « le web qui évolue » en soi. → documenter ces dépendances dans MAINTENANCE.md.