Le client et le contexte
La DRIEAT est la Direction Régionale et Interdépartementale de l’Environnement, de l’Aménagement et des Transports d’Île-de-France, un service de l’État. Elle pilote un projet national, le tableau de bord des mobilités durables, destiné aux services de l’État et aux collectivités. Ce tableau de bord présente des indicateurs de mobilité à cinq échelles, de la commune à la France entière.
Les indicateurs sont calculés en R à partir de données publiques, enregistrés dans une base de données, puis lus par une application web. Notre mission a porté sur la chaîne de calcul en R, l’application étant développée par un autre prestataire. Le projet est dirigé à la DRIEAT par Cindie Andrieu-Dupin, dont le témoignage est publié sur ce site.
Le problème
La DRIEAT disposait d’un prototype d’une douzaine d’indicateurs, calculés dans un package R écrit pour la première version de l’application. Chaque indicateur y avait son propre script, et beaucoup de code se répétait de l’un à l’autre.
Pour passer à l’outil définitif, elle voulait une suite d’étapes identique pour tous les indicateurs, et des fonctions que d’autres équipes du ministère puissent réutiliser pour leurs propres calculs. Il fallait aussi recalculer les indicateurs existants selon ce standard, pendant que l’application se développait et attendait ses premières tables.
Ce qu’on a fait
La mission repose sur trois choix.
Deux dépôts de code. La DRIEAT voulait des fonctions que d’autres équipes puissent reprendre, et on a donc séparé ce qui sert à tous les indicateurs de ce qui est propre à la mobilité. Le premier dépôt, territoRy, est un package R générique qui télécharge une source, contrôle les données, met à jour les codes des communes selon le découpage officiel le plus récent, agrège les résultats aux cinq échelles et les écrit en base. Le second contient les indicateurs de mobilité et s’appuie sur le premier, qu’une autre équipe peut reprendre seul. Cindie Andrieu-Dupin le raconte ainsi : « l’équipe Data Champ’ a très rapidement proposé ce découpage en deux packages qui ont été optimisés au fur et à mesure de la mission ».
Les mêmes étapes pour chaque indicateur. Chaque calcul passe par l’extraction, l’harmonisation, la mise à jour des codes communes et l’agrégation. La douzaine de familles d’indicateurs et leurs 13 sources publiques nationales sont décrites dans des fichiers de référence, si bien que pour ajouter une année de données, l’équipe complète une ligne dans le fichier des sources et relance le calcul. Le package est livré avec des tests automatiques et une documentation qui décrit pas à pas l’ajout d’un indicateur.
Des contrôles menés avec la DRIEAT. À chaque livraison, l’équipe de la DRIEAT relançait les calculs sur ses postes et relisait les valeurs, et on cherchait avec elle la cause de chaque écart. Le premier comptage des stations de métro à Paris en donnait par exemple 656 quand la DRIEAT en attendait 303, parce qu’il comptait chaque arrêt alors qu’une station en regroupe plusieurs. Les vérifications utiles à tous les indicateurs, comme la recherche de doublons ou de communes manquantes, sont devenues des fonctions du package.
La difficulté : des calculs trop lourds pour les postes du ministère
Les agents de la DRIEAT lancent les calculs sur leurs PC de bureau, sous Windows, derrière le réseau du ministère. Celui de la data analyst a 16 Go de mémoire, et deux indicateurs dépassaient ces moyens.
Le premier est le nombre de stations de transport en commun. Il se calcule à partir des fichiers GTFS, le format dans lequel les réseaux de transport publient leurs horaires et leurs arrêts. Il en existe environ 500 jeux pour la France, soit plusieurs centaines de millions de lignes, et en charger 100 à la fois demandait déjà plus de 40 Go de mémoire sur notre machine. C’est d’un échange avec l’équipe de la DRIEAT qu’est venue l’idée de traiter les réseaux un par un. Le calcul lit un réseau, en extrait les arrêts, libère la mémoire et passe au suivant, et on a mesuré 7 Go au maximum sur les 500 jeux.
Le second est le linéaire cyclable, c’est-à-dire la longueur des aménagements cyclables de chaque commune. Son calcul croise chaque tronçon avec les contours des communes, et on a confié ce croisement à DuckDB, un moteur de base de données qui s’exécute sur le poste, et à son extension spatial. Comme le réseau du ministère bloquait le téléchargement de cette extension, on a ajouté un mode d’installation dans lequel R télécharge le fichier de l’extension, puis l’installe depuis un dossier local. Il a fallu plusieurs essais avec l’équipe avant que le calcul passe chez elle.
Cindie Andrieu-Dupin en parle ainsi : « Ils ont su contourner ces limites pour nous proposer des solutions permettant d’optimiser certains calculs complexes nécessitant des traitements spécifiques. »
Les résultats
La DRIEAT dispose d’un package générique et d’un projet qui calcule ses indicateurs de mobilité, dont certains n’existaient pas dans le prototype.
Son équipe les fait évoluer sans nous. Dans son témoignage, Cindie Andrieu-Dupin déclarait : « on a pris en main le package et on est plutôt autonomes sur l’ajout de nouveaux indicateurs. On en a déjà rajouté quelques uns depuis la fin de la prestation. » Six mois après la fin de la mission, la data analyst de la DRIEAT assurait elle-même la maintenance de territoRy, et l’équipe préparait le passage de tous les indicateurs au nouveau découpage communal.
D’après ce même témoignage, d’autres projets du ministère commencent à utiliser le package, dont un outil sur la rénovation énergétique des logements. Le tableau de bord des mobilités durables est aujourd’hui en ligne.
Vous avez des indicateurs à calculer à partir de données publiques, ou un code R à rendre maintenable par votre équipe ? Écrivez-nous.
Commentaires