De « ça tourne en local » → à « c'est en prod »

◆ Le parti pris — souveraineté-first, pas souveraineté-only

Un parti pris qui traverse tout le doc : il influence l'hébergement, l'auth, l'IA et la conformité.

« First » : par défaut, on choisit la brique la plus souveraine possible — données en UE, briques open-source auto-hébergées, fournisseurs européens. C'est un choix technique et commercial : dans un SaaS B2B européen, « vos données ne quittent pas l'UE » se vend, et t'évite de dépendre du bon vouloir (et des conditions tarifaires) d'un géant américain.

« Pas only » : ce n'est pas de la pureté idéologique. Là où un outil non-UE est nettement supérieur et sans substitut crédible — typiquement le meilleur modèle d'IA généraliste — on l'utilise, mais on l'architecture comme remplaçable : données minimisées, résidence choisie quand l'option existe, et une alternative souveraine câblée comme citoyen de première classe pour ne jamais être piégé.

01 Les décisions de fond

Ces choix structurent tout le reste. Les prendre avant d'écrire une ligne de déploiement évite de tout refaire dans trois semaines.

1.1 Où héberger

Deux familles. Plateforme managée (Vercel, Railway, Render, Coolify) : tu pushes, ça se déploie tout seul, zéro admin système — mais coûts qui grimpent avec le trafic, moins de contrôle, souvent données hors UE. Serveur nu / VPS (Hetzner, OVH, Scaleway) : une machine à toi, ~5-20 €/mois, contrôle total, données en UE — en échange c'est toi qui l'installes (mais une fois posée, ça bouge peu).

Le vrai critère n'est pas « lequel est le mieux » mais « combien de SaaS vais-je faire tourner ? ». Un seul produit qui démarre → un PaaS peut suffire. Dès deux produits → un VPS mutualisé devient nettement moins cher. Et côté souveraineté (§◆), un hébergeur européen ne coûte pas plus cher : c'est du souverain gratuit.

1.2 La base de données

C'est là que vivent tes clients. Trois règles non négociables : PostgreSQL par défaut (robuste, standard, gratuit) ; une base par produit, jamais de tables mélangées entre deux SaaS ; et les migrations sont du code versionné — le schéma évolue par fichiers commités dans git, jamais par des modifications manuelles en prod (intraçable, irréproductible).

1.3 L'authentification

Ne jamais coder son propre système de mots de passe. Sessions, cookies, reset, OAuth : un nid à failles. Soit un service managé (Clerk, Auth0 — rapide mais payant au MAU et données chez un tiers), soit une librairie open-source auto-hébergée (Better Auth, Lucia — gratuit, données chez toi, souverain).

1.4 Le paiement

Stripe, quasi sans débat. Le point qui piège tout le monde : les webhooks. Stripe rappelle ton serveur pour dire « cet abonnement est actif / a échoué / annulé ». Mal branchés ou non vérifiés par signature → des clients qui paient sans être débloqués, ou l'inverse. À cadrer dès le départ : produits/prix créés par script idempotent (pas à la main), URL de webhook enregistrée + secret stocké, et un bypass de test pour dev/staging — strictement désactivé en prod.

1.5 Les emails transactionnels

« Vérifiez votre email », magic links, reçus : ça doit arriver, pas finir en spam. Jamais de SMTP perso ni de Gmail. Un service dédié (Resend, Postmark) + un domaine vérifié (SPF, DKIM, DMARC dans le DNS). Sans ça, la moitié de tes emails de bienvenue n'arrivent jamais et tu perds des inscrits sans le savoir.

1.6 L'IA / le LLM — souveraineté-first en action

Un appel à un modèle d'IA n'est pas un appel normal : lent (secondes à dizaines de secondes), payant au token, faillible (format inattendu possible), non déterministe. Quatre règles :

• Timeout explicite sur chaque appel. 2 s en local, 40 s ou timeout en prod sous charge. Sans timeout, une requête bloquée fige tout.
• Ne jamais faire confiance au format de sortie. Même avec un schéma imposé, le modèle peut le déborder. Valider et re-couper côté serveur.
• Streaming pour les réponses longues, plutôt qu'un écran blanc.
• Suivre le coût par appel et par mois dès le départ.

C'est aussi l'endroit où la souveraineté se joue vraiment (§◆). Le LLM est là où la tentation du 100 % américain est la plus forte. Le parti pris n'est pas de s'en priver, mais de ne pas s'y enchaîner : câbler un modèle européen comme runtime de première classe, derrière la même interface, pour faire tourner l'un, l'autre, ou les deux en consensus — sans réécrire une ligne de produit.

02 La parité dev / prod

La section à faire lire à ton dev (ou à toi, si tu codes avec Claude). C'est ici que 80 % du travail sérieux se joue.

La quasi-totalité des bugs livrés en prod passent les tests locaux et cassent quand même — parce qu'ils naissent d'une divergence silencieuse entre l'environnement local et celui de prod. Les diffs inévitables (adresse du site, mode de build) sont OK ; ce sont les diffs invisibles qui tuent.

03 Le chemin de mise en ligne

La séquence réelle du premier déploiement. À faire une fois à la main pour tout comprendre, puis à automatiser.

1. Domaine + DNS. Acheter le domaine, pointer l'enregistrement A vers l'IP du serveur. (Piège : le www n'est pas créé automatiquement — l'ajouter à la main.)
2. Accès serveur. SSH par clé uniquement (jamais par mot de passe), firewall fermé par défaut.
3. Base de données. Créer la base + l'utilisateur dédiés, noter l'URL de connexion.
4. Fichier de secrets de prod. Un .env.production sur le serveur, permissions restreintes (chmod 600), toutes les vraies clés. Jamais dans git.
5. Code → install → migration → build. Transférer le code, installer avec un lockfile figé (versions exactes), appliquer les migrations, builder pour la prod.
6. Faire tourner en service. Le déclarer en service système (systemd) pour qu'il redémarre tout seul après un crash ou un reboot.
7. Reverse proxy (Nginx). La porte d'entrée : reçoit le HTTPS public, le passe au programme en interne. Gère aussi rate-limiting et taille max des uploads.
8. Certificat HTTPS. Let's Encrypt (gratuit), renouvellement automatique. (Piège : la mauvaise méthode coupe le serveur web et fait tomber tes autres sites — utiliser « webroot ».)
9. Vérifier depuis 3 angles. Santé interne, santé via le proxy, santé publique en HTTPS. Un endpoint /api/health qui répond ok est le minimum vital.

04 Ce qui doit tourner tout seul

La prod n'est pas « mise en ligne puis oubliée ». Quatre automatismes, par priorité — à ne monter qu'une fois le déploiement manuel maîtrisé.

4.1 Déploiement automatique (CI/CD)

Quand le code est stable : un push sur la branche principale déclenche synchro + déploiement + test de fumée (la page d'accueil et la connexion répondent) + notification.

4.2 Surveillance (monitoring)

• Logs consultables.
• Capture d'erreurs (Sentry) : t'alerte quand un utilisateur rencontre une erreur, avec la trace. Free tier suffisant.
• Uptime externe : ping /api/health chaque minute, alerte si le site tombe.
• Analytics produit (PostHog, Plausible — auto-hébergés, souverains) pour comprendre l'usage.

4.3 Sauvegardes (backups)

La question qui tranche : « si le serveur brûle maintenant, qu'est-ce que je perds ? » La réponse doit être « quelques heures de données, pas tout ».

• Base de données : dump quotidien, rétention 30 j, copie hors-site (un backup sur la même machine ne protège de rien).
• Code : git/GitHub est déjà ta source de vérité.
• Secrets : copie chiffrée hors serveur.
• Tester la restauration : un backup jamais restauré n'est pas un backup.

4.4 Tâches planifiées (cron)

Relances, rapports hebdo, agrégations : des appels déclenchés par l'horloge. Les sécuriser avec un secret pour que seul le cron puisse les déclencher, pas n'importe qui sur internet.

05 Sécurité & conformité

Le minimum sérieux pour un SaaS UE qui manipule des données clients.

• Secrets. Jamais dans git. Fichier de prod en chmod 600. Copie chiffrée hors ligne. Préparer le geste de révocation si un secret fuite.
• Accès serveur. SSH par clé, firewall fermé par défaut, seuls les ports nécessaires ouverts.
• Isolation multi-clients. Aucune requête ne doit pouvoir lire les données d'un autre client. Centraliser ce filtre — un oubli = une fuite.
• RGPD. Données en UE (argument commercial en plus), suppression réelle sur demande, politique de confidentialité claire. Session replay → masquer les champs sensibles + opt-out.
• Rate limiting au niveau du proxy pour absorber les abus.
• Dépendances. Scan de vulnérabilités en intégration continue, avec un seuil qui bloque en cas de faille grave.

06 Les coûts

Ordre de grandeur pour un SaaS solo. Le seul poste qui scale avec l'usage, c'est l'IA.

07 Checklist « go-live »

À cocher avant d'ouvrir au public.

08 Modèle de PRD à remplir

À copier pour chaque nouveau SaaS. Une page, remplie en 30 min, qui fige les décisions avant de coder le déploiement.

# PRD mise en prod — <NOM DU SAAS>

## Produit
- Pitch en une phrase :
- Cible :
- Scope V1 (ce qui doit marcher au lancement) :
- HORS V1 (explicitement) :

## Décisions de fond  (souveraineté-first, pas -only)
- Hébergement :       # PaaS / VPS — lequel, UE ?
- Base de données :   # Postgres partagé / dédié
- Auth :              # managé / auto-hébergé — lequel
- Paiement :          # Stripe ? offres, prix, script setup ?
- Emails :            # fournisseur EU + domaine vérifié
- IA / LLM :          # runtime souverain (Mistral) + US (Claude) ?
                     # mode interchangeable ? voix en EU ?

## Domaine & infra
- Domaine :
- IP serveur / port :
- Base + user :
- Secrets de prod : chemin + copie chiffrée

## Variables critiques au boot
| Variable | Règle prod | Pourquoi |
|----------|------------|----------|
|          |            |          |

## Automatismes
- CI/CD :        # oui/non, quand
- Monitoring :   # erreurs / uptime / analytics
- Backups :      # fréquence, rétention, hors-site
- Crons :        # quels jobs, quelle fréquence

## Coûts / mois
- Fixe :
- Variable (IA) :
- Seuil de rentabilité (nb clients × prix) :

## Go-live
- Date cible :
- Checklist §7 cochée : oui / non

Ce PRD et les checklists sont prêts à copier — versions Markdown dans le repo, avec un CLAUDE.md à déposer dans ton projet pour que ton IA les déroule avec toi : → github.com/garniera93/saas-souverain-methode