08 — Hébergement, propriété & livraison

Objectif : client autonome + propriétaire de ses actifs, sans lock-in caché — MAIS Songe garde la main sur le push live (beaucoup de clients n’ont pas de maintenance mensuelle et demandent des modifs ponctuelles → il faut pouvoir déployer sans friction).

Hébergement — défaut = Cloudflare Pages

Cloudflare Pages par défaut : compte client + Songe membre, intégration Git → déploiement auto au git push, edge mondial gratuit + HTTPS auto + DDoS. C’est ce qui rend une modif ponctuelle = un simple git push (fluide, donc rentable).
o2switch UNIQUEMENT si le client est dogmatique « hébergement 100 % français ». Inconvénient assumé : pas de modèle collaborateur + pas de Git auto-deploy → chaque modif = creds FTP + upload manuel. À éviter pour les clients à modifs ponctuelles.
Cas audience DOM (ex. Réunion + Guadeloupe) → Cloudflare Pages obligatoire (PoP proches, vs latence ~120-220 ms d’un serveur France unique).
Vercel = bon aussi (host Node natif) si le site garde du runtime.

Propriété des comptes (qui possède quoi)

Le client POSSÈDE (ses actifs business, facturés sur SA carte) : domaine (registrar), hébergement, Sanity (org), service de formulaires. ⚠️ Sous une adresse de RÔLE entreprise (admin@client.com), jamais l’email perso d’un salarié (sinon perte d’accès quand il part). 2FA côté client.

Songe GARDE (outillage dev que le client ne touche jamais) : le repo Git (dans le GitHub de Songe) + un accès collaborateur/membre à l’hébergement → push live à volonté pour les modifs ponctuelles, sans re-onboarding.

Mécanisme d’accès — collaborateur, PAS clés API

On ne se fait pas « donner une clé API à chaque fois ». Pour un humain = invité comme collaborateur/membre sous SON propre login (GitHub, Cloudflare, Sanity). Les tokens/clés = pour le build seulement (token read-only Sanity posé 1× dans l’env). Déploiement = git push sur le repo Songe → auto-deploy sur l’hébergement client.

Autonomie réelle du client (sans lock-in)

Contenu : il édite seul dans Sanity (textes/images) — son vrai besoin quotidien.
Pas de lock-in : il possède domaine + hébergement + données ; le code source lui est livrable sur demande (transfert repo 1-clic ou archive) ; il peut révoquer l’accès Songe quand il veut. → À dire explicitement : « Tu possèdes tout ; Songe garde un accès prestataire révocable pour te servir au coup par coup. » Choisi, pas subi.

Modèle de revenu

Clients sans retainer → modifs facturées à l’intervention (forfait/régie). Le push fluide (Cloudflare Pages) rend les petites interventions rentables.
Clients avec suivi → retainer de maintenance explicite (service nommé), jamais du récurrent « de lock-in » via le contrôle de l’infra.

Livraison / passation

Doc de passation : inventaire des comptes / qui-possède-quoi / accès, procédure deploy + rebuild.
MAINTENANCE.md (→ 09).
Creds dans un gestionnaire que le client possède.
Mini-formation Sanity (autonome ≠ sait s’en servir).

RGPD / sécu (rappel)

Vitrine statique = surface quasi nulle (→ 07). Token d’écriture Sanity server-side only ; dataset Sanity région EU ; données perso (formulaire) traitées par le tiers (Brevo EU), pas par l’hébergeur.