Rapprochement des dates de session OGDPC — vue métier

À quoi ça sert ?

Chaque nuit à 2h30 (heure de Paris), erevo compare les dates de session qu’on a enregistrées en interne avec celles qui sont publiées côté OGDPC, et met automatiquement à jour ce qui a bougé. C’est utile parce que les dates côté ANDPC peuvent être corrigées après coup (décalage de quelques jours, ajustement d’horaires, etc.) et on veut que la plateforme reste alignée sans intervention manuelle.

Pour les classes virtuelles en particulier, la tâche remet aussi les horaires standards des modules (demi-journées 9h–12h30 / 13h30–17h, heure de Paris) si jamais une session a été modifiée.

Un rapport CSV est produit après chaque exécution : il liste les dates corrigées, les erreurs rencontrées, les sessions manquantes, et les cas non standards laissés de côté.

Quand ça tourne ?

Toutes les nuits vers 2h30 (heure de Paris), c’est-à-dire 1h30 après l’extraction OGDPC qui fournit les données d’entrée.

Ce que ça change concrètement

Les dates de session visibles côté plateforme (début, fin, pivot LMS, fin de partie « formation continue », début de la seconde évaluation) sont alignées sur ce qui est déclaré à l’ANDPC.
Pour les classes virtuelles, les horaires de chaque module sont remis au standard 9h–12h30 / 13h30–17h (heure de Paris).
Un rapport CSV est déposé sur le stockage interne pour audit (avec la copie « latest » à jour).

Qui est concerné ?

Apprenants et formateurs : voient les dates à jour dès le lendemain matin.
CSM : moins de cas « la date a bougé sur l’ANDPC mais pas chez erevo » à traiter manuellement.
Équipe produit / DPC : peut consulter le rapport CSV pour voir ce qui a été corrigé et ce qui reste à traiter à la main.

Cas connus / points d’attention

Si une session erevo n’a pas de correspondance dans l’extraction OGDPC (référence absente, numéro de session absent), elle est signalée comme « missing » dans le rapport, mais ne fait pas échouer la tâche. C’est au CSM de regarder.
Pour les classes virtuelles, si le nombre de modules en base ne colle pas à la durée de la session côté OGDPC, la tâche laisse les modules tels quels et marque le cas comme « skipped » dans le rapport (layout non standard) — à réviser à la main.
Cas de l’intervenant renommé : cette tâche ne touche pas au rattachement formateur-classe virtuelle. Si le nom de l’intervenant change côté ANDPC (orthographe, prénom/nom inversés, etc.), c’est une autre tâche qui s’en occupe — et celle-là n’est pas encore automatisée (voir Rapprochement des formateurs).
Une vérification par IA (Gemini) relit l’enchaînement des 4 dates clés après correction pour détecter des incohérences (par exemple, date de fin avant date de début). Les alertes produites par l’IA sont consignées en warning mais ne bloquent pas la tâche.
Point actif (avril 2026) : le dernier passage (2026-04-23) a échoué. L’équipe IT doit investiguer via Sentry avant la prochaine nuit pour éviter que l’écart s’accumule.

Qui est alerté si ça plante ?

Les erreurs techniques sont remontées dans Sentry → visibles par l’équipe IT. Conséquence si la tâche ne tourne pas une nuit : les dates erevo ne sont plus synchronisées avec l’ANDPC pour la nuit concernée ; ça se rattrape la nuit suivante si tout redevient normal.

Détails techniques (équipe IT) : voir Rapprochement des dates de session OGDPC.