Configuration Supabase¶

Ce document décrit les actions manuelles nécessaires pour préparer le projet Supabase de Serpe : création/vérification du projet, application des migrations SQL, contrôle de pgvector, ajustement de la configuration métier et test de l'isolation RLS entre agences.

Prérequis¶

Accès au dashboard Supabase du projet (référence de projet, ex. rnxuwktlbyczulacznoy, visible dans l'URL https://<project-ref>.supabase.co et dans Project Settings > General).
Optionnel : la CLI Supabase installée si vous préférez supabase db push à l'éditeur SQL du dashboard.
Optionnel : le MCP Supabase configuré côté agent — une fois authentifié, il permet d'appliquer/vérifier les migrations et d'interroger la base directement depuis une session d'agent, en alternative aux étapes manuelles ci-dessous.

Étape 1 — Créer ou pointer le projet Supabase¶

Sur app.supabase.com, créez un nouveau projet (région recommandée proche des utilisateurs, ex. eu-west) ou utilisez le projet déjà provisionné pour Serpe.
Notez son URL (https://<project-ref>.supabase.co) et ses clés — dans Project Settings > API :
URL → variable SUPABASE_URL
anon public key → variable SUPABASE_ANON_KEY
service_role key (secrète, ne jamais exposer côté client) → variable SUPABASE_SERVICE_ROLE_KEY
Reportez ces valeurs dans votre .env local (copié depuis .env.example, jamais commité) et dans les variables d'environnement Cloudflare Pages (voir docs/SETUP_CLOUDFLARE.md).

Étape 2 — Appliquer les migrations, dans l'ordre¶

Le schéma est défini par trois fichiers dans supabase/migrations/, à appliquer strictement dans cet ordre (chaque fichier dépend du précédent) :

0001_init.sql — schéma métier complet (agences, users, appels_offres, documents, corpus_chunks, assets_visuels, memoires, memoire_sections, projets_scores), extensions vector et pg_trgm, fonctions helper RLS (current_user_agence, current_user_is_admin), activation de la RLS et des policies sur toutes les tables métier.
0002_retrieval_fn.sql — fonction match_corpus_chunks (recherche vectorielle par similarité cosinus, cloisonnée par agence_id).
0003_auth_config_triggers.sql — table app_config (domaine autorisé, email admin), trigger enforce_email_domain (restriction de domaine sur auth.users) et trigger provision_app_user (création automatique du profil applicatif + attribution du rôle après inscription).

Option A — via l'éditeur SQL du dashboard¶

Dashboard Supabase > SQL Editor.
Ouvrez un nouveau script, collez le contenu de 0001_init.sql, exécutez.
Répétez pour 0002_retrieval_fn.sql, puis 0003_auth_config_triggers.sql.
Vérifiez qu'aucune erreur n'apparaît à chaque étape avant de passer à la suivante.

Option B — via la CLI Supabase¶

supabase link --project-ref <project-ref>
supabase db push

La CLI applique les migrations du dossier supabase/migrations/ dans l'ordre lexicographique (donc 0001 → 0002 → 0003), ce qui correspond à l'ordre requis.

Étape 3 — Vérifier que `pgvector` est actif¶

Dans le SQL Editor :

select * from pg_extension where extname = 'vector';

Une ligne doit être retournée. Vérifiez également la version :

select extversion from pg_extension where extname = 'vector';

Important : les index HNSW créés par 0001_init.sql (corpus_chunks, assets_visuels) nécessitent pgvector ≥ 0.5.0. Si la version est inférieure, mettez à jour l'extension avant d'appliquer les migrations :

alter extension vector update;

(Sur les projets Supabase récents, pgvector est déjà en version ≥ 0.5.0 par défaut — cette vérification sert surtout de garde-fou.)

Étape 4 — Ajuster `app_config` si besoin¶

La migration 0003 seed deux valeurs par défaut dans app_config :

key	valeur seedée
`allowed_email_domain`	`serpe.fr`
`admin_email`	`dev-ia@serpe.fr`

Ces valeurs doivent correspondre à ALLOWED_EMAIL_DOMAIN et ADMIN_EMAIL dans votre .env. Si le domaine réel ou l'email admin diffère (autre client, autre environnement), mettez à jour la table directement :

update app_config set value = 'autre-domaine.fr' where key = 'allowed_email_domain';
update app_config set value = 'admin@autre-domaine.fr' where key = 'admin_email';

Ces deux lignes pilotent respectivement le trigger enforce_email_domain (qui domaines peuvent créer un compte) et provision_app_user (quel compte reçoit automatiquement le rôle admin à l'inscription). Voir docs/SETUP_GOOGLE.md pour le contexte SSO complet.

Étape 5 — Test de l'isolation RLS entre agences¶

Objectif : vérifier qu'un utilisateur de l'agence A ne peut pas voir les appels_offres (ni documents, corpus, etc.) de l'agence B.

Créez deux agences de test :

insert into agences (nom) values ('AGENCE-TEST-A'), ('AGENCE-TEST-B');

Créez ou assignez deux comptes utilisateurs de test, un par agence (via inscription SSO réelle, ou en mettant à jour manuellement users.agence_id pour deux comptes existants — hors compte admin, qui bypasse toute la RLS).

Créez un appel_offres de test rattaché à chaque agence :

insert into appels_offres (agence_id, titre) values
  ((select id from agences where nom = 'AGENCE-TEST-A'), 'AO test A'),
  ((select id from agences where nom = 'AGENCE-TEST-B'), 'AO test B');

Connectez-vous côté application (ou via un client Supabase authentifié avec le JWT de l'utilisateur de l'agence A) et interrogez appels_offres : seul l'AO de l'agence A doit apparaître.
Répétez avec l'utilisateur de l'agence B : seul l'AO de l'agence B doit apparaître.
Nettoyez les données de test une fois la vérification faite.

Si un utilisateur voit des lignes d'une autre agence, vérifiez que la RLS est bien activée sur la table concernée (alter table ... enable row level security, déjà présent dans 0001_init.sql) et que la policy *_rw correspondante est bien appliquée.

Récapitulatif des vérifications¶

[ ] Projet Supabase créé/identifié, URL et clés récupérées.
[ ] 0001_init.sql, 0002_retrieval_fn.sql, 0003_auth_config_triggers.sql appliquées dans l'ordre, sans erreur.
[ ] pgvector actif, version ≥ 0.5.0.
[ ] app_config cohérent avec .env (domaine, admin).
[ ] Test RLS multi-agences passé (aucune fuite de données cross-agence).