Aller au contenu

Continuité — accès externes détenus par une seule personne (Alert-Parent)

Pourquoi ce document existe

Suit le même modèle que l'audit EPIDOCS API : plusieurs accès externes critiques pour Alert-Parent (backend + frontend) sont aujourd'hui détenus par une seule personne (Yémalin). Ce document liste chaque dépendance externe connue pour ce projet, ce qui a été vérifié pour de vrai (pas supposé), et ce qui reste à faire pour donner un accès de secours à Cédric Gnansounou (GitHub cedricgnans), repreneur du projet.

Statut vérifié pour Alert-Parent

Dépendance Ce qui a été vérifié Statut
GitHub — repo alert-parent-backend gh api repos/EpitechAfrik/alert-parent-backend/collaborators ✅ Cédric (cedricgnans) a déjà accès admin — rien à faire
GitHub — repo alert-parent-frontend gh api repos/EpitechAfrik/alert-parent-frontend/collaborators ✅ Cédric (cedricgnans) a déjà accès admin — rien à faire
GitHub Actions secrets (SERVER_HOST, SERVER_SSH_KEY, DOTENV_FILE, etc.) gh secret list --repo ... sur les deux repos — confirme que ce sont des secrets de repo, pas d'organisation ✅ Couvert par l'accès admin GitHub ci-dessus (un admin repo peut créer/modifier ces secrets, jamais lire leur valeur)
Runner GitHub Actions self-hosted (les deux pipelines tournent en runs-on: self-hosted) gh api repos/.../actions/runners → 0 runner enregistré au niveau du repo ; gh api orgs/EpitechAfrik/actions/runners → 403 you must be an org admin avec le compte actuel ✅ Confirmé par Yémalin (2026-09-11) : Cédric a déjà accès à la machine qui héberge le runner — rien à faire
Azure AD — App Registration Alert-Parent (SSO) App Registration Alert-Parent ✅ Cédric et Pissano ajoutés comme membres (2026-09-11) — rotation du secret possible sans Yémalin
VPS (SSH, hébergement Hostinger) Non vérifiable depuis ce poste (pas de session SSH active) ⬜ À vérifier — voir ci-dessous
MongoDB Atlas (cluster partagé, base al3rtParent) Non vérifiable — nécessite le dashboard Atlas ⬜ À vérifier — voir ci-dessous
Resend (envoi des mails de campagne) Non vérifiable — nécessite le dashboard Resend ⬜ À vérifier — voir ci-dessous
Registrar DNS epitools.bj Même domaine que les autres projets de la plateforme — voir l'audit EPIDOCS API ⬜ À vérifier (dépendance déjà documentée, pas spécifique à Alert-Parent)

À faire, par dépendance

Runner GitHub Actions self-hosted

  • Où : probablement le VPS de production lui-même, ou une machine dédiée à proximité — les deux pipelines (alert-parent-backend et alert-parent-frontend) déclarent runs-on: self-hosted, et le job deploy fait ensuite un SSH séparé vers le VPS (SERVER_HOST), ce qui suggère que ce n'est pas forcément la même machine.
  • Pourquoi c'était signalé : si ce runner est arrêté, désenregistré ou perd sa connexion à GitHub, aucun déploiement ne part pour ces deux projets — le job reste "queued" indéfiniment côté GitHub Actions, sans message d'erreur explicite. gh api repos/EpitechAfrik/alert-parent-backend/actions/runners renvoie 0 runner au niveau du repo (donc très probablement enregistré au niveau de l'organisation EpitechAfrik) et gh api orgs/EpitechAfrik/actions/runners renvoie 403 You must be an org admin avec le compte actuel — l'accès admin sur un repo ne couvre pas la gestion de ce runner au niveau GitHub.
  • Statut : ✅ résolu — confirmé par Yémalin (2026-09-11), Cédric a déjà accès à la machine qui héberge le runner (accès direct à la machine, indépendant du rôle GitHub). En cas de panne, il peut donc intervenir dessus sans avoir besoin du rôle admin/owner d'organisation sur GitHub.

Azure AD — App Registration Alert-Parent

  • Où : App Registration Alert-Parent (Client ID / Tenant ID distincts de ceux d'EPIDOCS — les valeurs elles-mêmes sont dans les build-args du workflow frontend et dans le .env backend, jamais à reporter en clair ici).
  • Pourquoi c'était critique : le SSO Microsoft est actif en production (MICROSOFT_CLIENT_ID/ MICROSOFT_TENANT_ID côté backend, VITE_MICROSOFT_CLIENT_ID/VITE_MICROSOFT_TENANT_ID côdés en dur dans .github/workflows/deploy.yml du frontend). Un secret d'App Registration expiré ou révoqué casse la connexion Microsoft pour tous les utilisateurs (même symptomatologie que documentée pour EPIDOCS : panne silencieuse jusqu'à ce que quelqu'un essaie de se connecter).
  • 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. Date d'expiration du secret actuel (Certificates & secrets) encore à noter ici une fois vérifiée.

VPS (hébergement de production — Hostinger)

  • Où : accès SSH sur le serveur référencé dans les secrets GitHub SERVER_HOST/SERVER_SSH_KEY ; panel d'hébergement hpanel.hostinger.com (référencé dans runbook.md comme hébergeur).
  • Pourquoi c'est critique : c'est là que tournent les conteneurs alert-parent-backend/ alert-parent-frontend, le .env de chaque projet, et potentiellement le runner self-hosted lui-même (voir ci-dessus). Sans accès SSH, aucune intervention manuelle (rollback, lecture de logs, redémarrage) n'est possible — seul le pipeline CI/CD automatique fonctionne encore, et seulement si le runner est en vie.
  • Action : créer un utilisateur SSH dédié pour Cédric sur le VPS (même procédure que documentée pour EPIDOCS — pas de partage de la clé privée root existante) : 
    # Sur le VPS, en root
adduser cedric
usermod -aG docker cedric
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
    Vérifier aussi l'accès au compte Hostinger (panel d'hébergement) séparément de l'accès SSH — les deux sont souvent détenus par des comptes différents.

MongoDB Atlas (cluster al3rtParent)

  • Où : dashboard cloud.mongodb.com.
  • Pourquoi c'est critique : sans accès, impossible de vérifier l'IP whitelist (Network Access), l'état du cluster, de faire une restauration point-in-time, ou de régénérer les identifiants de connexion si MONGO_URI doit être renouvelé.
  • Action : inviter Cédric comme membre du projet Atlas hébergeant al3rtParent (Project Access Manager → Add). Vérifier si ce cluster est partagé avec d'autres projets de la plateforme (auquel cas l'ajouter une seule fois y suffit pour tous).

Resend (envoi des mails de campagne)

  • Où : dashboard resend.com.
  • Pourquoi c'est critique : sans accès, impossible de régénérer RESEND_TOKEN si le token actuel est révoqué/expiré, de vérifier le domaine d'envoi, ou de diagnostiquer un problème de délivrabilité (quota dépassé, domaine non vérifié, etc. — voir troubleshooting.md § Emails ne s'envoient pas).
  • Action : inviter Cédric comme membre de l'organisation/compte Resend (Settings → Team).

Registrar DNS (epitools.bj)

  • Dépendance déjà documentée en détail dans l'audit EPIDOCS API (même domaine, sous-domaine alert. pour ce projet). Pas besoin de la répéter en détail ici : une fois l'accès donné pour EPIDOCS, il couvre tous les sous-domaines epitools.bj, Alert-Parent inclus.

Ce qui n'a PAS besoin d'action supplémentaire

  • GHCR (registre d'images Docker) : les images sont poussées sous ghcr.io/epitechafrik/alert-parent-backend/-frontend, liées aux repos GitHub — couvert par l'accès admin repo déjà confirmé pour Cédric.
  • Secrets GitHub Actions : confirmé ci-dessus être des secrets de repo, pas d'organisation — l'accès admin déjà en place suffit à les gérer (créer/modifier, jamais lire une valeur existante).