Créer un SaaS B2B souverain avec Lampion

Votre interlocuteur métier est convaincu, puis le dossier passe au responsable de la sécurité et au juriste. Arrivent alors les mêmes questions : où sont nos données, qui peut les lire, comment garantissez-vous qu’un autre client n’y accède pas, et comment les récupérons-nous si nous partons. Aucune ne se répond après coup.

Les deux premières questions se règlent dans les étapes 01 et 03. Les deux autres tombent presque toutes seules ensuite.

C’est l’erreur la plus fréquente : une base hébergée en France, et le reste du service chez un fournisseur non européen. Or les données personnelles ne restent pas dans la base. Elles passent par l’API, s’écrivent dans les logs, se posent dans un cache, se retrouvent dans un e-mail transactionnel et dans les sauvegardes de tout ce qui précède. Chaque brique hébergée ailleurs est une copie ailleurs.

Pourquoi l’opérateur compte autant que la région

Sur Lampion, chaque projet est un tenant du moteur de stockage : ses pages, son WAL et ses fichiers dans le stockage objet sont rangés sous son propre identifiant. Depuis le 10 octobre 2026, le serveur de pages vérifie à chaque lecture un jeton propre au projet : un compute ne lit que les pages de son tenant. Chaque projet a aussi son propre historique — restaurer un projet à un instant donné ne touche aucun autre projet — et supprimer un projet supprime son tenant, sur le serveur de pages, le safekeeper et le stockage objet.

Ce qu’un projet par client apporte

Le prix : une migration et une connection string par client. Startup autorise jusqu’à 1 000 projets, Souverain bien davantage ; au-delà de quelques dizaines de clients, le schéma partagé reste le plus simple à exploiter.

Vous avez donc deux façons de séparer vos clients. Un projet par client : le cloisonnement va jusqu’au stockage, et chaque client a son historique, sa restauration et son effacement. Un schéma partagé avec row-level security : tous les clients dans un même projet, filtrés par le moteur PostgreSQL. Les deux cohabitent très bien — vos grands comptes dans leur propre projet, les autres dans un projet partagé —, et la suite de cette étape met en place le second, qui demande le plus de rigueur.

-- Toute table portant des données client a un tenant_id.
CREATE TABLE tenants (
  id         uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  slug       text UNIQUE NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE orders (
  id         uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id  uuid NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
  amount_cts integer NOT NULL CHECK (amount_cts >= 0),
  created_at timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX orders_tenant_created_idx
  ON orders (tenant_id, created_at DESC);

-- Le moteur filtre, plus seulement le code applicatif.
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
-- FORCE : la policy s'applique aussi au propriétaire de la table.
ALTER TABLE orders FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING      (tenant_id = NULLIF(current_setting('app.tenant_id', true), '')::uuid)
  WITH CHECK (tenant_id = NULLIF(current_setting('app.tenant_id', true), '')::uuid);

-- Le rôle applicatif n'est jamais le propriétaire.
GRANT SELECT, INSERT, UPDATE, DELETE ON orders TO app_user;
GRANT SELECT ON tenants TO app_user;

# Le rôle de l'application, puis sa connection string
$ export APP_PASSWORD="$(openssl rand -hex 24)"
$ lampion roles create 4f9c21ab8d3e47b0a6c95e1d2b3f7a08 ep-4f9c21ab8d3e app_user --password "$APP_PASSWORD"
Role 'app_user' created.
$ export DATABASE_URL="postgresql://app_user:[email protected]:5432/ep-4f9c21ab8d3e.postgres?sslmode=require"

# Appliquer le schéma et les policies
$ psql "$ADMIN_DATABASE_URL" -v ON_ERROR_STOP=1 -f schema.sql -f policies.sql

# Une ligne de test, écrite par le propriétaire
$ psql "$ADMIN_DATABASE_URL" -c "INSERT INTO tenants (slug) VALUES ('acme')"
$ psql "$ADMIN_DATABASE_URL" -c "INSERT INTO orders (tenant_id, amount_cts) SELECT id, 1000 FROM tenants"

# Relue par l'application, sans tenant posé : la policy ne rend rien
$ psql "$DATABASE_URL" -c "SELECT count(*) FROM orders"
 count 
-------
     0

# Une branch forkée depuis main, supprimée d’office au bout de 72 h
$ lampion branches create 4f9c21ab8d3e47b0a6c95e1d2b3f7a08 pr-482 --parent 4f9c21ab8d3e47b0a6c95e1d2b3f7a08 --ttl 72
Branch created: 9b2e7c41d0a54f3e8c6a1b7d2e9f0c35 (pr-482)

# Une base éphémère par pull request : supprimée à la fermeture, TTL en filet
name: preview
on:
  pull_request:
    types: [opened, synchronize, reopened, closed]

# Un seul run à la fois par pull request : deux pushes rapprochés ne créent pas deux branches.
concurrency: preview-${{ github.event.number }}

env:
  LAMPION_TOKEN: ${{ secrets.LAMPION_TOKEN }}
  PROJECT_ID: 4f9c21ab8d3e47b0a6c95e1d2b3f7a08
  BRANCH: pr-${{ github.event.number }}

jobs:
  test:
    if: github.event.action != 'closed'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install lampion-cli

      - name: Créer la branch au premier passage, la remettre à neuf ensuite
        run: |
          BRANCH_ID=$(lampion branches list "$PROJECT_ID" --json \
            | jq -r --arg b "$BRANCH" '.[] | select(.name == $b) | .id')
          if [ -z "$BRANCH_ID" ]; then
            # TTL de 72 h : le filet si le job cleanup ne passe pas
            lampion branches create "$PROJECT_ID" "$BRANCH" \
              --parent "$PROJECT_ID" --ttl 72 --json
          else
            # Push suivant : repartir de l'état courant de main
            lampion branches reset "$PROJECT_ID" "$BRANCH_ID" --yes
          fi

      - name: Récupérer son URL
        run: |
          URL=$(lampion endpoints list "$PROJECT_ID" --json \
            | jq -r --arg b "$BRANCH" '.[] | select(.name == $b) | .connection_string')
          echo "::add-mask::$URL"
          echo "ADMIN_DATABASE_URL=$URL" >> "$GITHUB_ENV"

      - name: Migrations et tests
        run: |
          npm ci
          npm run migrate   # les migrations de la PR, sur la copie de la production
          npm test

  cleanup:
    if: github.event.action == 'closed'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install lampion-cli

      - name: Supprimer la branch
        run: |
          BRANCH_ID=$(lampion branches list "$PROJECT_ID" --json \
            | jq -r --arg b "$BRANCH" '.[] | select(.name == $b) | .id')
          # Vide si le TTL l'a déjà supprimée : rien à faire
          if [ -n "$BRANCH_ID" ]; then
            lampion branches delete "$PROJECT_ID" "$BRANCH_ID"
          fi

Aucun frais par branche, quel que soit le plan — seuls le compute consommé et le stockage sont facturés. Une branch inactive se suspend après cinq minutes. Pour aller plus loin et faire tourner les tests sur des données masquées, il y a un article dédié.

Tester sur des données de production masquées, à chaque pull request →

# Le questionnaire pré-rempli, à donner à votre assistant IA
$ lampion compliance questionnaire --format md -o questionnaire.md

# Accepter le DPA au nom de la société, puis télécharger l’attestation
$ lampion compliance dpa-accept --company "Acme SAS" --signer "Camille Martin" --title "CEO"
$ lampion compliance dpa-certificate --pdf dpa-attestation.pdf

# Le rapport de résidence et la liste des sous-traitants
$ lampion compliance residency --pdf residence.pdf
$ lampion compliance subprocessors

Les mêmes documents, en ligne de commande. Chaque réponse du questionnaire porte un statut — oui, partiel, non, prévu — que l’assistant ne doit pas arrondir. Seul l’owner de l’organisation peut accepter le DPA. Les documents sont en français par défaut ; --locale en donne la version anglaise.