seize-infra-doc/HANDOVER.md

# 🚨 HANDOVER — Passation au prochain mainteneur

> Ce document est **prioritaire**. Lis-le **avant tout** si tu reprends le projet.

---

## ✅ Ce qui marche (état au 5 juin 2026)

### Infrastructure
- ✅ Stack Docker sur Scaleway, 24 conteneurs actifs
- ✅ Traefik comme reverse proxy avec Let's Encrypt auto
- ✅ Zitadel comme IDP, accessible sur `sso.seizeconsulting.com`
- ✅ 7 sous-domaines en HTTPS opérationnels
- ✅ Pattern OAuth2-Proxy par outil pour le SSO

### Utilisateurs
- ✅ 88 collaborateurs Seize importés dans Zitadel
- ✅ 4 anciens comptes (HKA, PSP, PYT, Jules) conservés avec leur MFA
- ✅ Metadata Furious copiées sur tous les comptes (job_title, bu_name, manager, etc.)
- ✅ Mots de passe temporaires générés dans `users-credentials.csv`

### RBAC
- ✅ 8 rôles créés dans le project "Infra Seize" (Zitadel)
- ✅ 87/88 users avec rôle attribué (1 sans : le user "vide" Furious à corriger)
- ✅ Intranet filtre les cartes selon le rôle
- ✅ Testé sur HKA (consultant_junior) : voit Gitea + Code Server uniquement

### Imports automatisés
- ✅ Scripts Python dans `~/furious-to-zitadel/` opérationnels
- ✅ Mode dry-run / test / prod pour `import-furious-to-zitadel.py`
- ✅ Script de fusion de doublons (`merge-duplicates.py`)
- ✅ Script de génération du mapping RBAC (`generate-roles-mapping.py`)
- ✅ Script d'attribution des rôles (`assign-roles.py`)

---

## 🔴 À faire en priorité (urgent)

### 1. Rotation des secrets exposés

Plusieurs secrets ont été partagés dans des conversations IA pendant le développement. **À régénérer immédiatement** :

| Secret | Où | Action |
|---|---|---|
| Compte API Furious `mick.emmaus.90849` | Furious > Configuration API | Régénérer le mdp |
| Token JWT user HKA (1 fois, expiré) | N/A | Déjà expiré, juste vérifier |
| Mdp Postgres Gitea | `~/docker/gitea/.env` (`GITEA_DB_PASSWORD`) | Régénérer + restart |
| Secrets Gitea (LFS_JWT, INTERNAL_TOKEN, JWT_SECRET) | `~/docker/gitea/.env` | Régénérer + restart |
| Clé service account Zitadel `zitadelfuriousimportkey.json` | `~/furious-to-zitadel/` | Régénérer si suspicion compromission |

### 2. Distribuer les 88 mdp temporaires

Le fichier `~/furious-to-zitadel/distribution-teams.csv` contient 88 lignes :
`Nom complet | Email | Mot de passe temporaire`

**Procédure recommandée** (validée avec Philippe) :
- Envoyer 1 mdp par message **privé Teams** (jamais en canal public)
- Indiquer URL : https://intranet.seizeconsulting.com
- Préciser : "Mdp temporaire à changer à la 1ère connexion"
- Étaler sur 5-7 jours (10-20 par jour) pour gérer le support 1er login

**Une fois distribution terminée** : supprimer le CSV (corbeille + vider la corbeille).

### 3. Configurer SMTP M365 (délégué à l'admin M365)

Sans SMTP, Zitadel ne peut pas envoyer d'emails (welcome, reset password, MFA).

**Procédure** :
1. Demander à l'admin M365 de créer `noreply@seizeconsulting.com`
2. Activer SMTP AUTH sur ce compte
3. Générer un App Password
4. Configurer dans Zitadel : Default settings → SMTP Provider
5. Tester l'envoi

Détails dans [docs/08-secrets-management.md](./docs/08-secrets-management.md).

### 4. Nettoyer Authentik (plus utilisé)

```bash
cd ~/docker/authentik
sudo docker compose down
# Optionnel : sauvegarder le dossier avant suppression
mv ~/docker/authentik ~/docker/authentik.archived
```

Idem pour Redis si plus utilisé par d'autres services (à vérifier).

---

## 🟡 À faire ensuite (important)

### 5. Documenter pour Philippe

Philippe a validé l'import et la matrice RBAC en oral mais **n'a pas vu la liste exacte** des 88 users.

À lui transmettre :
- Liste des 88 users importés (sans les mdp, pour traçabilité)
- Matrice RBAC effective (cf. [matrices/rbac-matrix.md](./matrices/rbac-matrix.md))
- Date/heure d'import : 5 juin 2026 07:27-07:42

### 6. Workshop validation matrice RBAC

La matrice actuelle a été **tranchée par Hedi seul** car Philippe pas dispo le jour de l'import. À valider en workshop :
- Direction = Président + Directeur + Directeur Associé ?
- Manager = inclut Manager BI ?
- Experts = au-dessus ou en parallèle des Managers ?
- Apprentis vs Stagiaires : 2 rôles distincts ou 1 seul ?

### 7. Corriger l'anomalie du user "vide" Furious

1 collaborateur a `job_title` vide dans Furious → pas de rôle Zitadel attribué.
**Action** : identifier qui (Hedi sait) et compléter dans Furious, puis relancer `assign-roles.py`.

### 8. Corriger les anomalies d'orthographe Furious

Doublons dans Furious à standardiser :
- `Senior Manager` vs `Sénior Manager`
- `Consultant Expérimenté` vs `Consultant Expérimentée` vs `Consultant Sénior`
- `Consultant Expert niveau 1` (avec espace en début parfois)

Le script `assign-roles.py` gère ces variantes via mapping mais c'est mieux de standardiser à la source.

---

## 🟢 À faire à terme (moyen/long terme)

### 9. Décision business : migrations outils gratuits OU licences pro ?

Pour avoir un **vrai RBAC** (pas juste cosmétique sur l'intranet), il faut :

**Option A** — Migrations gratuites (5-6j de boulot, 0€/an) :
- n8n → Activepieces
- Portainer CE → Komodo
- Uptime Kuma → Gatus
- Code Server → OpenVSCode Server (RBAC limité)

**Option B** — Licences pro (~25 800€/an, 1j de config) :
- n8n Enterprise
- Portainer Business
- (le reste reste gratuit)

**Décision sponsor** : Philippe + Pierre-Yves Tachon.

### 10. Workflow n8n de sync continue Furious → Zitadel

Idée : tous les jours à 3h du matin, n8n :
- Récupère la liste des users Furious
- Identifie les nouveaux arrivants → crée dans Zitadel
- Identifie les départs (`departure_date != "0000-00-00"`) → désactive dans Zitadel
- Met à jour les metadata si changement

⏱️ ~1 journée de dev n8n.

### 11. Custom Claims OIDC (attendre Actions V2 Zitadel)

Pour vraiment transmettre les rôles aux outils backends (Gitea, n8n, etc.) en plus de l'intranet, on attend la stabilisation d'**Actions V2** dans Zitadel.

### 12. Fédération M365/Entra ID ↔ Zitadel

Plus tard : permettre aux users de se logger via leur compte M365 entreprise.

### 13. Backup chiffré + plan de reprise

Actuellement, **aucun backup automatisé**. Critique pour la base PostgreSQL de Zitadel et Gitea.

À mettre en place :
- Backup quotidien de PostgreSQL (avec `pg_dump`)
- Backup des volumes Docker (Gitea data, Zitadel data)
- Stockage offsite (Scaleway Object Storage chiffré)

### 14. Monitoring sécurité avancé

- **Fail2ban** ou **Crowdsec** pour bloquer les IPs malveillantes (les logs OAuth2-Proxy montrent beaucoup de tentatives de scans)
- Alerting sur tentatives de login échouées (via Uptime Kuma ou autre)

---

## 🗣️ Conversations / décisions clés à connaître

### Décisions architecturales tranchées

1. **Zitadel plutôt qu'Authentik** : meilleur support API, plus stable, mieux documenté
2. **OAuth2-Proxy par outil (pas centralisé)** : permet config différenciée par app
3. **RBAC sur intranet uniquement (Approche A)** : zéro coût, suffisant à 90% pour 88 employés non-techniques
4. **Garder anciens comptes (HKA, PSP, PYT, Jules)** avec MFA, supprimer les doublons importés
5. **Metadata custom plutôt que rôles "vrais" Zitadel** au moment de l'import (rôles ajoutés ensuite)
6. **Pas de SMTP configuré** : mdp distribués manuellement via Teams
7. **Pas de migration M365 immédiate** : les users gardent leurs comptes Zitadel locaux

### Anti-patterns identifiés

- ❌ **Ne PAS donner IAM_OWNER aux service accounts** → utiliser le rôle minimal (`IAM_USER_MANAGER`)
- ❌ **Ne PAS créer un nouveau project Zitadel** pour les rôles si "Infra Seize" existe déjà (sinon OAuth2-Proxy ne les voit pas)
- ❌ **Ne PAS exécuter `scp` depuis le serveur SSH** vers lui-même — toujours depuis le PC client
- ❌ **Ne PAS coller de secrets** (tokens, mdp, clés API) dans des conversations IA — utiliser un gestionnaire de mots de passe
- ❌ **Ne PAS supprimer un user admin** sans avoir vérifié qu'on a un autre accès admin (risque de blocage)

---

## 📞 Contacts utiles

| Personne | Rôle | Contact |
|---|---|---|
| Hedi Kalboussi (HKA) | Mainteneur sortant | Slack/Teams interne |
| Philippe Spoljaric (PSP) | Sponsor + Admin Infra | Slack/Teams interne |
| Pierre-Yves Tachon (PYT) | CEO + arbitrage budget | Slack/Teams interne |
| Support Furious Squad | API + données RH | seize-consulting.furious-squad.com |
| Scaleway | Hébergeur | console.scaleway.com |

---

## 🎯 Premier jour de la passation — checklist

- [ ] Lire ce HANDOVER en entier
- [ ] Lire ARCHITECTURE.md
- [ ] Se connecter en SSH au serveur : `ssh hedi@151.115.148.243`
- [ ] Demander accès Zitadel admin à Hedi
- [ ] Lister les conteneurs : `sudo docker ps`
- [ ] Vérifier les logs récents : `sudo docker logs --tail 50 traefik`
- [ ] Tester un login en HKA depuis incognito
- [ ] Faire un point téléphone avec Hedi pour Q&A
- [ ] Identifier les 1-2 actions urgentes à reprendre

---

**Bon courage, et bienvenue dans le projet !** 🚀