Continuité — accès externes détenus par une seule personne (epitech-tracker)¶

Pourquoi ce document existe

Voir le modèle général : guides/continuite-acces-externes.md. Cette page applique la même grille au projet epitech-tracker : lister chaque dépendance externe nécessaire pour opérer ce projet, vérifier ce qui est réellement accessible à Cédric Gnansounou (cedricgnans), et documenter ce qui reste à faire.

Statut vérifié pour epitech-tracker¶

Dépendance	Ce qui a été vérifié	Statut
GitHub — repo `epitech-tracker`	`gh api repos/EpitechAfrik/epitech-tracker/collaborators`	✅ Cédric (`cedricgnans`) a déjà accès admin — rien à faire
GitHub Actions secrets (`RELEASE_TOKEN`)	Un admin repo peut gérer les secrets (créer/modifier — jamais lire la valeur) ; `gh api .../actions/secrets` confirme qu'il n'y a qu'un seul secret configuré sur ce repo	✅ Couvert par l'accès admin GitHub ci-dessus
Dépôt miroir public `YemalinModeste/epitech-tools`	`gh api repos/YemalinModeste/epitech-tools` + `.../collaborators` ; historique des runs `release.yml` (`gh run list --workflow=release.yml`)	🟡 Dépôt personnel de Yémalin, un seul collaborateur — mais la migration finale vers 1.1.0 a déjà été exécutée (voir ci-dessous), l'usage opérationnel restant est résiduel
API Zeno (`zeno.epitech.africa`)	Hors périmètre de ce dépôt — c'est un projet/dépôt distinct qui héberge l'enrôlement, l'ingestion et la distribution des mises à jour	⬜ À vérifier — audit à faire dans le dépôt Zeno, pas ici (déjà signalé dans le modèle général)
VPS hébergeant le conteneur `epitech-api-prod` (dépôt de `tools.deb` par `docker cp`, cf. README §7)	Non vérifiable depuis ce poste (pas de session SSH établie) — c'est probablement le même VPS que celui audité pour EPIDOCS API, à confirmer	⬜ À vérifier — voir le runbook EPIDOCS ou demander confirmation directe
Signature/intégrité des paquets `.deb`	Le mécanisme n'utilise aucune clé de signature séparée : l'intégrité repose sur un sha256 publié par Zeno lui-même (`tools.deb.sha256`, vérifié par `updater.py`)	✅ Pas de custodian de clé à transférer — dépend uniquement de l'accès à Zeno (déjà listé ci-dessus)

Détail critique — le dépôt miroir public¶

gh api repos/YemalinModeste/epitech-tools --jq '{private, visibility, owner: .owner.login}'
# → {"private": false, "visibility": "public", "owner": "YemalinModeste"}

gh api repos/YemalinModeste/epitech-tools/collaborators --jq '.[].login'
# → YemalinModeste

Finding réel : ce n'est pas un dépôt de l'organisation — mais la migration a déjà tourné

.github/workflows/release.yml de epitech-tracker peut publier une release sur YemalinModeste/epitech-tools (job « Miroir public », déclenché manuellement avec mirror_public: true, authentifié par le secret RELEASE_TOKEN). Ce dépôt appartient personnellement à Yémalin et n'a aucun autre collaborateur.

Vérifié le 2026-09-11 (gh run list --repo EpitechAfrik/epitech-tracker --workflow=release.yml) : un run workflow_dispatch a tourné avec succès le 2026-09-09, publiant la release v1.1.0 sur YemalinModeste/epitech-tools avec pour message « Migration du parc vers la 1.1.0 ». Le code actuel (TRACKER_VERSION = "1.1.0" dans src/config.py) n'interroge plus api.github.com du tout — src/updater.py n'appelle que {API_URL}/sonde/version (Zeno). La bascule documentée a donc déjà été exécutée, deux jours avant cet audit.

Ce qui reste comme risque résiduel (pas nul, mais bien plus faible qu'un dépôt encore activement nécessaire) :

Un poste resté injoignable pendant cette fenêtre de migration (éteint, hors ligne, en panne) ne l'aura pas reçue et resterait bloqué sur l'ancien chemin GitHub jusqu'à sa prochaine vérification — improbable en volume, mais pas à exclure sans un inventaire du parc.
Le secret RELEASE_TOKEN (dans epitech-tracker) a toujours un droit d'écriture sur ce dépôt personnel ; il reste utilisable pour republier si un tel cas apparaît.

Action recommandée (moins urgente qu'initialement estimé, mais à faire avant le départ) :

Documenter ce dépôt comme legacy / migration terminée plutôt que comme dépendance active — ne plus le traiter comme un blocage opérationnel courant.
Par hygiène (au cas où un poste isolé refasse surface plus tard), soit :
transférer la propriété du dépôt epitech-tools vers l'organisation EpitechAfrik (gh repo transfer YemalinModeste/epitech-tools EpitechAfrik, à confirmer côté destinataire) ;
ou, plus simple, ajouter Cédric comme collaborateur direct sur ce dépôt personnel (gh api -X PUT repos/YemalinModeste/epitech-tools/collaborators/cedricgnans), en sachant que ça reste un accès révocable unilatéralement par le propriétaire du compte personnel.
Si le dépôt est un jour transféré/abandonné, révoquer/régénérer le secret RELEASE_TOKEN en conséquence.

Autres dépendances identifiées dans le code, à auditer côté Zeno (pas ici)¶

Ces éléments sont nécessaires pour opérer epitech-tracker mais vivent entièrement dans le dépôt/l'infrastructure Zeno — à couvrir dans leur propre audit de continuité, pas dans celui-ci :

Enrôlement des postes (POST /api/sonde/enroll) et base des deviceId/clés.
Ingestion des snapshots (POST /api/sonde/ingest) et agrégation en score d'effort.
Distribution des mises à jour (GET /sonde/version, GET /sonde/tools.deb) — dépôt du binaire dans le conteneur epitech-api-prod, ce qui suppose un accès SSH/VPS et Docker sur l'hôte qui fait tourner Zeno.
install.sh servi par Zeno (script d'installation/enrôlement exécuté sur les postes).

Autres projets à auditer avec la même grille¶

Voir la liste au bas du modèle général — Tracker_student_work / tracker-platform y est déjà cité. Cette page constitue cet audit pour epitech-tracker ; le composant Zeno reste à faire séparément.