seize-infra-doc/HANDOVER.md
Hedi Kalboussi 1e90a85359 Documentation initiale infra Seize — passation J7
- 6 docs racine (README, HANDOVER, ARCHITECTURE, DECISIONS, INSTALL, OPERATIONS)
- 9 docs thématiques dans docs/
- 10 templates docker-compose dans configs/
- 7 scripts Python/Shell d'import Furious vers Zitadel
- 2 matrices RBAC

Etat infra au 5 juin 2026 :
- 88 users Furious importes dans Zitadel
- 8 roles RBAC crees et attribues
- Intranet filtre les cartes selon role (Approche A)
- 7 outils SSO operationnels
2026-06-05 17:49:43 +00:00

8.9 KiB

🚨 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 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.

4. Nettoyer Authentik (plus utilisé)

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)
  • 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 ! 🚀