Aller au contenu

Continuité — accès externes détenus par une seule personne

Pourquoi ce document existe

Plusieurs comptes/accès externes critiques (Azure Portal, VPS, services SaaS) sont aujourd'hui détenus par une seule personne (Yémalin). Si cette personne devient indisponible, la plateforme reste techniquement en ligne mais personne ne peut réagir à un incident (secret expiré, panne serveur, service tiers coupé) sans ces accès. Ce document liste chaque dépendance externe connue, ce qui a été vérifié, et ce qui reste à faire pour donner un accès de secours à une seconde personne (Cédric Gnansounou, désigné comme second contact).

Portée de cet audit

Cet audit a été fait en détail pour EPIDOCS API (le projet en cours au moment de la rédaction, 2026-09). Les mêmes catégories de dépendances existent très probablement pour les autres projets de la plateforme (voir la liste en bas de page) — à refaire projet par projet, ce document donne le modèle à suivre, pas un audit déjà complet de tout.

Statut vérifié pour EPIDOCS API

Dépendance Ce qui a été vérifié Statut
GitHub — repo epidocs-api gh api repos/EpitechAfrik/epidocs-api/collaborators ✅ Cédric (cedricgnans) a déjà accès admin — rien à faire
GitHub — repo pedago-tools-docs idem ✅ Cédric a déjà accès admin — rien à faire
GitHub Actions secrets (SSH_PRIVATE_KEY, VPS_IP, VPS_USER, ENV_FILE) Un admin repo peut gérer les secrets (créer/modifier — jamais lire la valeur, même en admin) ✅ Couvert par l'accès admin GitHub ci-dessus
Azure AD — App Registration EPIDOCS App Registration EPIDOCS (SSO) ✅ Cédric et Pissano ajoutés comme membres (2026-09-11) — rotation du secret possible sans Yémalin
VPS (SSH root) Non vérifiable depuis ce poste (pas de connexion SSH établie dans cette session) ⬜ À vérifier — voir ci-dessous
Resend (envoi d'email, RESEND_API_KEY) Non vérifiable — nécessite le dashboard Resend ⬜ À vérifier — voir ci-dessous
Registrar DNS epitools.bj Non vérifiable — nécessite le panel du registrar ⬜ À vérifier — voir ci-dessous

À faire, par dépendance

Azure AD — App Registration EPIDOCS

  • Où : App Registration EPIDOCS (SSO) → App Registrations
  • Pourquoi c'était critique : sans accès, impossible de renouveler AZURE_CLIENT_SECRET à son expiration (voir Erreurs courantes — secret expiré) → connexion cassée pour tout le monde jusqu'à ce que quelqu'un avec accès intervienne.
  • Statut : ✅ résolu — Cédric Gnansounou et Pissano ont été ajoutés comme membres sur cette App Registration (2026-09-11), ce qui couvre la rotation du secret et les autres opérations courantes sans dépendre uniquement de Yémalin.
  • Aussi à noter une fois vérifié : la date d'expiration actuelle du secret (Certificates & secrets), pour ne pas attendre la panne.

VPS (hébergement de production)

  • Où : accès SSH root sur le serveur (IP dans le secret GitHub VPS_IP)
  • Pourquoi c'est critique : c'est là que tourne tout (conteneurs Docker, .env de chaque projet, PostgreSQL). Sans accès SSH, aucune intervention manuelle possible (redémarrage, rollback, backup, lecture de logs) — seul le pipeline CI/CD automatique fonctionne encore.
  • Action : créer un utilisateur SSH dédié pour Cédric sur le VPS (pas de partage de la clé privée root existante — une clé par personne) :
    # Sur le VPS, en root
    adduser cedric
    usermod -aG docker cedric   # accès docker sans sudo
    mkdir -p /home/cedric/.ssh
    echo "CLE_PUBLIQUE_DE_CEDRIC" >> /home/cedric/.ssh/authorized_keys
    chown -R cedric:cedric /home/cedric/.ssh
    chmod 700 /home/cedric/.ssh && chmod 600 /home/cedric/.ssh/authorized_keys
    
  • Une fois fait : mettre à jour ce tableau avec la date et confirmer que Cédric peut se connecter (ssh cedric@VPS_IP).

Resend (envoi d'emails transactionnels)

  • Où : dashboard resend.com
  • Pourquoi c'est critique : sans accès, impossible de régénérer une clé API révoquée/expirée, de vérifier un domaine d'envoi, ou de diagnostiquer un problème de délivrabilité.
  • Action : inviter Cédric comme membre de l'organisation/compte Resend (Settings → Team, selon le plan).

Registrar DNS (epitools.bj)

  • Où : panel du registrar qui gère le domaine epitools.bj
  • Pourquoi c'est critique : sans accès, impossible de modifier un enregistrement DNS (changement d'IP de VPS, ajout d'un sous-domaine, certificat SSL qui dépend d'une validation DNS).
  • Action : identifier le registrar utilisé, puis ajouter Cédric comme contact autorisé ou lui donner un accès secondaire selon ce que permet le registrar.

Projets déjà audités avec cette grille

Ces projets ont désormais leur propre page "Continuité — accès externes", produite avec la même méthode (vérification réelle via gh api .../collaborators, pas de suppositions) :

  • Alert-Parent (backend + frontend) — GitHub OK (Cédric admin sur les deux repos) ; le runner GitHub Actions self-hosted partagé n'est pas couvert par l'accès admin repo au niveau GitHub, mais Cédric a déjà accès à la machine qui l'héberge (confirmé par Yémalin) — point résolu.
  • epitech-tracker — GitHub OK ; un secret d'Actions publie vers YemalinModeste/epitech-tools, un repo GitHub personnel (pas dans l'org EpitechAfrik) utilisé pour migrer les anciens appareils 1.0.x — la migration a déjà été exécutée le 2026-09-09 (le parc parle désormais à Zeno), donc risque résiduel plutôt que blocage actif ; transfert du repo ou partage à Cédric reste recommandé par hygiène.
  • Registre public de diplômes (public-diploma-verify) — GitHub OK ; nouvelle dépendance identifiée : le domaine epitech.africa est chez un registrar différent (Gandi, organisation IONIS GROUP, nameservers o2switch) de celui des autres projets (epitools.bj) — accès non encore vérifié.
  • Zeno Suivi (zeno-suivi) — GitHub OK ; dépendance non technique à ne pas oublier : l'accès à l'Artifact Claude utilisé comme source de la vue "Plan de charge" doit être partagé avec Cédric, sans quoi cette vue ne peut plus être mise à jour.
  • TrainHub — audit partiel : Azure AD (SSO Microsoft) OK, Cédric et Pissano ajoutés comme membres (2026-09-11) ; GitHub, Vercel, Supabase et Resend restent à auditer.

Autres projets à auditer avec la même grille

Cet audit n'a couvert que EPIDOCS API en détail, et les quatre ci-dessus. Les projets suivants ont très probablement les mêmes catégories de dépendances (Azure AD ou autre SSO, VPS, service d'email, DNS, GitHub) et méritent le même passage :

  • epidocs-frontend
  • Zeno (la plateforme elle-même, distincte de zeno-suivi déjà auditée ci-dessus)
  • EDMS
  • showcase_parents
  • pedago-tools-monitoring (Grafana / Uptime Kuma — comptes séparés à vérifier aussi)

Pour chacun : reproduire le tableau "Statut vérifié" ci-dessus (gh api repos/.../collaborators pour GitHub — rapide et vérifiable soi-même — puis lister les services externes présents dans son .env/sa config, et vérifier l'accès un par un).