Création d'une stack data performante chez beta.gouv

Client : beta.gouv - Incubateur d’État du numérique.

Mission : Accompagnement en Data Engineering, amélioration et optimisation de la stack data.

Durée : 12 mois

Résultat : Optimisation des processus de reporting, réduction du temps de chargement des tableaux de bord, automatisation des flux de données.

Qu’est-ce que beta.gouv et le Service National Universel (SNU) ?

Simplifier le quotidien des Français en s’appuyant sur le numérique. C’est l’objectif principal de la DINUM (Direction Interministérielle du Numérique), rattachée au ministère de la Transformation et de la Fonction publiques.

Pour ce faire, il y a une dizaine d’années, la DINUM a créé beta.gouv, un incubateur de services numériques. Cet incubateur crée, via des Startups d’État, des services numériques basés sur les besoins des usagers et répondant aux Politiques Prioritaires du Gouvernement (PPG). Chaque Startup porte un projet numérique, en suivant les mêmes phases de développement :

1. La phase de construction : l’équipe se constitue, et livre une première version

2. La phase d’accélération : assurer la mise à l’échelle du produit au niveau national

3. La phase de transfert : migrer le service au sein de son administration d’origine

Quant au SNU, il s’agit d’une initiative gouvernementale visant à progressivement remplacer la Journée Défense et Citoyenneté (JDC, ex-JAPD). Elle permet aux jeunes de 15 à 17 ans de participer à un séjour de cohésion de 12 jours en dehors de son département de scolarisation, mais aussi de s’engager dans une mission d’intérêt général de 84 heures.

La mise en place d'une stack data sur-mesure

L’objectif était de mettre en place une base de données centralisée, ainsi que des rapports 100% automatisés. Avec un enjeu de taille tout de même : les données devaient être stockées en France, chez un hébergeur français.

Il y avait aussi un gros enjeu d’optimisation des tableaux de bord sur l'outil BI (Metabase), qui étaient pour beaucoup surchargés, avec un temps de chargement qui pouvait atteindre la minute.

L’architecture cible était donc la suivante : utiliser la base Postgres existante comme entrepôt de données, utiliser un orchestrateur (Airflow) pour réunir deux bases de données séparées, et utiliser un transformateur de données (dbt) pour effectuer des calculs beaucoup plus rapidement, ce qui permettait de rendre les tableaux de bord beaucoup plus rapides lors du chargement.

Le résultat

Avant la mise en place de ces outils, les agents publics passaient environ 3 à 4h par semaine à extraire les données de la plateforme, à es consolider et à créer leurs reportings. Aussi, les tableaux de bord existants mettaient en moyenne 20 secondes à charger, avec parfois des temps de chargement pouvant atteindre une minute.

Suite à notre intervention, les agents publics recevaient de manière totalement automatisée les chiffres du jour dans leur boîte mail sous forme de tableau, sans aucune intervention nécessaire de leur part. Le temps de chargement des tableaux de bord est également tombé à une seconde.