Analytique pour le Service National Universel : Création d'un pipeline pour générer des bases de données d'événements à partir des données de production

Contexte

Nous avions une base de données composée de collections MongoDB représentant les jeunes s'inscrivant à un programme gouvernemental (le Service National Universel, une sorte de colonie de vacances gérée par l'État), et effectuant par la suite des missions d'intérêt public dans des organisations à travers le pays. Pour les deux phases, les candidatures devaient passer par un processus en plusieurs étapes, incluant la création d'utilisateur, la complétion, la validation administrative, et les éventuelles demandes de refus ou de correction. Tout était enregistré dans des champs "statut". Bien que nous enregistrions la date de la dernière mise à jour, nous ne gardions pas trace de chaque changement de statut directement dans les données utilisateur.

Au cours de la troisième année du projet, le client (le Ministère de l'Éducation) a reçu une demande d'un organisme de réglementation pour des statistiques détaillées sur l'évolution du pool de candidats. Cela nécessitait de présenter clairement les chiffres quotidiens des candidatures créées, complétées, traitées, validées et refusées, ainsi que des projections et des comparaisons avec les objectifs annuels.

Afin de répondre à ce besoin le plus rapidement et simplement possible, nous avons choisi de créer notre propre pipeline à partir de zéro, en utilisant les outils déjà déployés sur le projet (une instance Nodejs et des bases de données, tous gérés par le service CleverCloud).

Ingestion

Heureusement, un système existant de génération automatique de données d'événements était déjà en place : chaque mise à jour de la collection utilisateur générait un document dans la collection "patches", enregistrant l'ID du document mis à jour et les valeurs des champs modifiés. Cette collection servait à des fins de sécurité (suivi des modifications et de leur origine) et permettait la restauration des données en cas de bugs ou d'erreur humaine. Elle serait désormais également utilisée pour notre service d'analyse naissant.

Cependant, ces patches ne répondaient pas entièrement aux exigences du client. Pour fournir une base de données adaptée au recoupement et à la génération de rapports anonymisés détaillés - comme le nombre de candidatures créées et validées par genre, âge ou région du candidat - une transformation des données était nécessaire. Par conséquent, une tâche automatisée a été configurée pour s'exécuter chaque nuit pour le traitement.

Transformation

Le besoin :

• Données complètes : nous devions reconstruire l'état de l'utilisateur avant et après chaque événement enregistré.

• Données structurées : les enregistrements devaient être convertis de notre stockage de documents vers une base de données relationnelle pour faciliter l'utilisation sur l'outil de visualisation de données choisi (Metabase).

• Données anonymisées : aucune information d'identification ne pouvait être enregistrée sur cette base de données, qui allait être accessible par des personnes extérieures à l'équipe du client et dans le strict respect des règles RGPD.

Nous avons développé des scripts JavaScript pour peupler une base de données PostgreSQL externe. Pour chaque événement (par exemple, création de candidature, validation, achèvement du processus), une nouvelle entrée était générée dans la table d'analyse. Chaque entrée incluait le nom de l'événement et les données utilisateur reconstruites, avant et après le changement. Cette reconstruction utilisait les informations d'événement de la collection patch et le document utilisateur le plus récent, avec toutes les informations d'identification supprimées. Ces profils utilisateur reconstruits étaient stockés dans des colonnes JSONB, et les champs clés étaient dupliqués dans des colonnes séparées pour rationaliser les requêtes ultérieures.

De plus, ces scripts devaient supporter l'exécution manuelle, en cas de panne serveur ou de mauvaise configuration, sans générer d'entrées en double dans la table des événements.

Partage des données

Avec ces événements soigneusement enregistrés dans une base de données relationnelle, le département des données a pu créer de beaux tableaux de bord et PDF, répondant à la plupart des questions de l'administration et mettant ainsi en valeur le rôle de l'ensemble du programme.