internal-api — vue métier
À quoi sert ce projet ?
Section intitulée « À quoi sert ce projet ? »internal-api est le cerveau backend d’erevo. C’est là que vivent les données métier (apprenants, formateurs, sessions DPC, classes virtuelles, rappels, produits, versions de formation) et c’est ce projet qui fait fonctionner le dashboard EasyAdmin utilisé par les équipes CSM et IT. Tout ce qui apparaît dans le dashboard — la liste des apprenants, les sessions, les rappels, les formateurs — est servi par ce projet.
Ce qui est automatique
Section intitulée « Ce qui est automatique »Chaque jour, plusieurs tâches tournent toutes seules depuis GitLab pour maintenir les données à jour :
- Copie de sécurité de la base — toutes les 4 heures, une sauvegarde complète de la base est envoyée sur le serveur de backup. → Voir la page dédiée
- Nettoyage des vieilles copies de sécurité — chaque dimanche vers 1h du matin (heure de Paris), les backups de plus de 60 jours sont supprimés pour ne pas saturer l’espace disque. → Voir la page dédiée
- Vérification quotidienne des rappels — tous les soirs vers 1h du matin (heure de Paris), le système regarde quels rappels (notifications, classes virtuelles à venir) doivent partir ce jour-là et les déclenche. → Voir la page dédiée
- Mise à jour de la vitrine et des upsells apprenants — tous les soirs vers 1h du matin, erevo recalcule pour chaque apprenant actif quelles formations sont mises en avant dans la vitrine publique et quelles formations complémentaires sont proposées en upsell. → Voir la page dédiée
- Extraction des sessions OGDPC — tous les soirs vers 1h du matin, erevo se connecte au portail OGDPC pour récupérer la liste à jour des sessions DPC ouvertes (dates, formateurs, liens participants) et la stocke en CSV sur MinIO. → Voir la page dédiée
- Rapprochement des dates de session — tous les soirs vers 2h30 du matin (juste après l’extraction), erevo compare les dates des sessions OGDPC avec celles de la base et corrige automatiquement les écarts (y compris les horaires des classes virtuelles). → Voir la page dédiée
Ce qui n’est pas automatique (encore)
Section intitulée « Ce qui n’est pas automatique (encore) »- Rapprochement des formateurs de classe virtuelle : le code qui aligne les formateurs OGDPC avec ceux de la base erevo existe, mais il n’est pas encore planifié côté GitLab. → Voir la page dédiée. Planification à créer prochainement.
Que se passe-t-il si ça casse ?
Section intitulée « Que se passe-t-il si ça casse ? »- Les erreurs techniques (exception PHP, échec de login OGDPC, problème MinIO, etc.) remontent automatiquement dans Sentry : l’équipe IT les voit apparaître dans l’outil de monitoring et peut relancer la tâche manuellement depuis GitLab.
- Les tâches 100 % shell (sauvegarde et nettoyage de la base de données) ne sont pas vues par Sentry — pour celles-là, il faut regarder directement la page des schedules côté GitLab pour voir si un run a échoué.
- Les équipes CSM / compta ne voient pas directement l’échec — elles constatent seulement que la donnée attendue n’est pas à jour dans le dashboard (par exemple : un rappel pas parti, une session sans formateur). Dans ce cas, ping l’équipe IT.
- Les sauvegardes de base ont lieu toutes les 4h : une exécution manquée n’est pas critique tant que la prochaine passe bien.
Détails techniques (équipe IT) : voir Pipeline — internal-api.