Guide de déploiement - Sprint 07 (Bloc 1 + Bloc 2)

Guide pas-à-pas pour passer de l'état actuel (dev/perf, testé sur la base de prod Supabase) à un déploiement Netlify fonctionnel. Aucune valeur secrète n'est écrite dans ce fichier - les clés VAPID sont à récupérer dans ton .env local (jamais commit, jamais dans ce guide).

⚠️ Ce guide touche la base de production et le site Netlify de production. Vérifie chaque étape avant de valider (ex. git push, déploiement) - ne saute pas les étapes de vérification.

0. Pré-requis avant de commencer

Nettoyage des tâches de test terminé (toi, en cours) - ne garder que projets et membres réels.
Un accès à ta base Supabase (SQL Editor) et à ton dashboard Netlify.

1. Migration SQL Supabase - `push_subscriptions`

Toutes les autres migrations (01_cleanup.sql → 09_create_logs_table.sql) sont déjà appliquées sur cette base (confirmé : member, project, task, app_logs fonctionnent déjà en prod). Il ne manque que celle-ci :

Ouvre le Supabase Dashboard → ton projet → SQL Editor → New query.
Colle exactement le contenu de docs/features/sql/10_push_subscriptions.sql :

create table if not exists public.push_subscriptions (
  id         uuid primary key default gen_random_uuid(),
  member_id  uuid not null references public.member(id) on delete cascade,
  endpoint   text not null unique,
  p256dh     text not null,
  auth       text not null,
  created_at timestamptz not null default now()
);

create index if not exists push_subscriptions_member_id_idx on public.push_subscriptions (member_id);

alter table public.push_subscriptions enable row level security;

drop policy if exists push_subscriptions_select on public.push_subscriptions;
create policy push_subscriptions_select on public.push_subscriptions for select
using (member_id = auth.uid());

drop policy if exists push_subscriptions_insert on public.push_subscriptions;
create policy push_subscriptions_insert on public.push_subscriptions for insert
with check (member_id = auth.uid());

drop policy if exists push_subscriptions_delete on public.push_subscriptions;
create policy push_subscriptions_delete on public.push_subscriptions for delete
using (member_id = auth.uid());

Clique Run. Le script est idempotent (rejouable sans risque).
Vérification rapide (nouvelle requête dans le même éditeur) :

select table_name from information_schema.tables where table_name = 'push_subscriptions';
select policyname from pg_policies where tablename = 'push_subscriptions';

→ doit renvoyer 1 ligne pour la table, 3 lignes pour les policies (push_subscriptions_select, _insert, _delete).

2. Variables d'environnement Netlify

Dans le dashboard Netlify → ton site → Site configuration → Environment variables, vérifie/ajoute ces clés (valeurs à copier depuis ton .env local, jamais à écrire en clair dans un fichier du repo) :

Variable	Déjà présente ?	Où trouver la valeur
`VITE_SUPABASE_URL`	à vérifier	`.env` local
`VITE_SUPABASE_ANON_KEY`	à vérifier	`.env` local
`SUPABASE_SERVICE_ROLE_KEY`	à vérifier	`.env` local
`SUPABASE_JWT_SECRET`	à vérifier	`.env` local
`VAPID_PUBLIC_KEY`	nouvelle	`.env` local (générée ce sprint)
`VAPID_PRIVATE_KEY`	nouvelle - secret serveur	`.env` local - ⚠️ NE JAMAIS préfixer `VITE_`
`VAPID_SUBJECT`	nouvelle	`.env` local (`mailto:admin@engwe-france.fr`)
`VITE_VAPID_PUBLIC_KEY`	nouvelle	`.env` local (même valeur que `VAPID_PUBLIC_KEY`)
`VITE_ANTHROPIC_API_KEY`	optionnelle	`.env` local - sans elle, `/api/import` utilise un mode de secours heuristique (fonctionnel mais moins précis)

Commande pour lister ce qui est déjà configuré côté Netlify (si la CLI est installée) :

netlify env:list

Import en une commande : un fichier netlify-vapid-import.env.local a été généré à la racine du projet (4 lignes : VAPID_PUBLIC_KEY, VAPID_PRIVATE_KEY, VAPID_SUBJECT, VITE_VAPID_PUBLIC_KEY, valeurs copiées depuis .env). Il est gitignoré (*.local) - jamais commit.

netlify env:import netlify-vapid-import.env.local

Supprime ce fichier une fois l'import fait (rm netlify-vapid-import.env.local) : il contient la clé privée VAPID en clair, inutile de le garder sur disque au-delà de l'import.

Après ajout, redéployer (une simple modification de variable d'env ne redéclenche pas automatiquement le build).

3. Committer le travail du Bloc 2 (non commit à ce jour)

Depuis la racine du projet, sur la branche dev/perf :

git status   # relire ce qui part dans le commit avant de valider
git add src/utils/notifications.js src/__tests__/notifications.test.js \
        src/pages/ManagerDashboard.jsx src/pages/SuperManagerDashboard.jsx \
        src/hooks/useData.jsx
git commit -m "feat(notifications): badge temps réel \"à valider\" côté manager (US7-NOTIF-04)

Dérive les tâches en attente de validation depuis les données déjà
chargées (aucune requête supplémentaire), avec marquage lu/non-lu
local. Corrige aussi une boucle de refetch (useData.jsx calé sur
l'objet Session au lieu de user.id/access_token)."

git add lib/pushBackend.js netlify/functions/notify-validation.js \
        public/ src/services/pushService.js src/components/modals/ProfileModal.jsx \
        server.js index.html package.json package-lock.json \
        docs/features/sql/10_push_subscriptions.sql docs/ADR/ADR_0010_web_push_vapid.md
git commit -m "feat(notifications): Web Push VAPID pour les tâches à valider (US7-NOTIF-05)

Service Worker minimal + abonnement client par RLS + endpoint
d'envoi best-effort (server.js et netlify/functions, parité).
Nécessite la migration 10_push_subscriptions.sql et les variables
VAPID côté Netlify (voir guide_deploiement.md)."

(Adapte les listes de fichiers si git status montre autre chose entre temps - notamment les fichiers docs/ déjà présents avant ce sprint.)

4. Passer de `dev/perf` à `main`

Ce projet utilise main comme branche de référence pour les PR. Deux options :

Option recommandée - Pull Request (garde une trace de revue) :

git push origin dev/perf
gh pr create --base main --head dev/perf --title "Sprint 07 - Bloc 1 (profil/PIN) + Bloc 2 (notifications in-app + Web Push)"

Puis merger la PR depuis GitHub une fois relue.

Option directe (si tu veux aller vite, sans revue) :

git checkout main
git pull origin main
git merge dev/perf
git push origin main

5. Déploiement Netlify

Si le site est configuré en auto-deploy sur main : le git push ci-dessus déclenche déjà le build. Vérifie l'onglet Deploys du dashboard Netlify.
Sinon, déclenche manuellement : dashboard Netlify → Deploys → Trigger deploy → Deploy site, ou via CLI :
```
netlify deploy --prod
```

6. Smoke tests post-déploiement (sur l'URL de prod)

Connexion réussie pour les 3 rôles (super_manager, manager, employee) via le roster.
Page Profil : consultation + édition du nom.
Changement de PIN : ancien PIN incorrect → refusé ; nominal → succès.
Badge « 🔔 X à valider » : créer une tâche employé → apparaît côté manager sans rechargement.
Notifications Push : bouton « Activer » dans Profil → accepter la permission navigateur → vérifier qu'une ligne apparaît dans push_subscriptions (SQL Editor : select * from push_subscriptions;).
Faire passer une tâche en validation → vérifier réception d'une notification système (app fermée si possible).
Vérifier les logs de la fonction Netlify notify-validation (dashboard Netlify → Functions → notify-validation → logs) en cas de doute.

Rollback

En cas de souci après déploiement : revert le commit de merge sur main et re-déployer, ou utiliser Deploys → [ancien build] → Publish deploy dans le dashboard Netlify pour revenir instantanément à la version précédente.