Rapprochement des formateurs de classe virtuelle OGDPC — vue métier

Cette tâche existe dans le code mais n’est pas encore déclenchée automatiquement. Sa mise en production (planification GitLab) est prévue prochainement.

À quoi ça sert ?

L’objectif est de vérifier, pour chaque classe virtuelle à venir, que le formateur affecté côté erevo correspond bien à l’intervenant déclaré côté OGDPC/ANDPC — et de corriger automatiquement les écarts. En cas de petite divergence orthographique (prénom/nom inversés, accent manquant, typo, abréviation), l’IA (Gemini) prend le relais du matching exact et propose le bon formateur. Quand aucun formateur erevo ne correspond à un intervenant déclaré, la tâche le signale explicitement pour correction manuelle.

Quand ça tournera ?

Elle ne tourne pas encore automatiquement. Une planification nocturne est prévue (idéalement vers 3h du matin, heure de Paris, juste après le rapprochement des dates), mais elle n’est pas encore en place. En attendant, la tâche peut être lancée à la main par l’équipe IT quand c’est nécessaire.

Ce que ça change concrètement (une fois lancée)

Les formateurs affectés à chaque classe virtuelle à venir sont alignés sur ce qui est déclaré à l’ANDPC.
Un rapport CSV est produit : il liste les classes pour lesquelles on a corrigé (fixed), celles dont le nom d’intervenant côté OGDPC n’a pas pu être rattaché à un utilisateur existant chez erevo (unresolved_user), et celles qui n’apparaissent pas dans l’extraction OGDPC (not_in_csv).
Le rapport est accessible sur le stockage interne.

Qui est concerné ?

Formateurs : leur affectation aux classes virtuelles peut être réajustée.
CSM / opérations : destinataires naturels du rapport, pour vérifier que les cas unresolved_user sont bien dus à un nom à aligner (par exemple un formateur déclaré « Jean-Pierre Martin » côté ANDPC et « JP Martin » côté erevo).
Apprenants : indirectement, puisque c’est la bonne affectation qui garantit que le bon formateur animera leur classe virtuelle.

Cas connus / points d’attention

Tâche à planifier : la principale limite actuelle est qu’elle ne tourne pas toute seule. Tant que la planification GitLab n’est pas en place, les divergences éventuelles entre erevo et l’ANDPC ne sont pas rattrapées automatiquement.
Quand elle tombe sur un nom d’intervenant qu’elle ne peut pas rattacher à un utilisateur erevo (même avec l’aide de l’IA), la tâche se termine en erreur et produit une ligne unresolved_user dans le rapport — c’est volontaire, pour attirer l’attention.
Les classes virtuelles dont la référence + numéro de session ne sont pas trouvés dans l’extraction OGDPC sont marquées not_in_csv dans le rapport (pas forcément un problème — la session peut ne plus être ouverte côté ANDPC).

Qui est alerté si ça plante ?

Une fois la tâche planifiée, les erreurs techniques seront remontées dans Sentry → visibles par l’équipe IT. Pour l’instant (tâche non planifiée), il n’y a aucune couverture : ni Sentry ni GitLab schedule ne la surveille.

Détails techniques (équipe IT) : voir Rapprochement des formateurs de classe virtuelle OGDPC.