BP 6 - Réduire le volume unitaire des jeux de données
Priorité :
- prioritaire,
- recommandée,
- pour aller plus loin
Mise en œuvre :
- facile,
- moyenne,
- difficile
Exemple(s) d’indicateur(s) de pilotage
- Volume moyen des fichiers disponibles en Mo
- % de jeux de données supérieur à 240 Mo
Exemple de pilote : Référent aux données ouvertes et responsables
Service à associer : DSI
Les premières externalités négatives de la donnée sont liées à son stockage et sa diffusion qui nécessitent une infrastructure matérielle (réseau, et data centers), mais aussi des terminaux utilisateurs. Cela se traduit naturellement par de la consommation de matière première (minerais, eau, beaucoup d'eau) pour produire ces équipements, et de la consommation électrique.
Non seulement la production de données est colossale mais elle croit à une vitesse vertigineuse en raison des usages, des multiples sources (IoT) et leur distribution/duplication via internet.
Nous le savons, l'OpenData propose généralement des jeux de données au volume limité, sans commune mesure à certaines ressources ou services mobilisant des données en temps réel, voire des données cartographiques (voir : OpenData, ordre de grandeur et enjeux).
En 2021, le Shift project estime la part du numérique à 12% de la consommation totale d'électricité et 3 à 4 % des émissions de gaz à effet de serre (GES) dans le monde (voir : Impact environnemental du numérique, état des lieux). Par ailleurs, la production de donnée au niveau mondial est exponentielle. Portée par une explosion des usages, en 2020, les données générées, copiées et consommées en ligne est estimée à plus de 60 Zettabytes (1 zetta représente environ 1 milliard de terabytes).
Bien que ce volume soit essentiellement porté par une croissante forte du contenu vidéo et temps réel, et que la volumétrie seule n'est pas un indicateur suffisant d'impact du numérique, une attention particulière peut être portée sur la volumétrie des données produites, utilisées par les métiers, exposées et archivées. (Voir : Réduire le volume de données stockées par MinNumEco, DINUM)
1 - choix du format de fichier
Privilégier le format de fichier plus plus sobre
Il faut avoir conscience que les formats de fichiers peuvent être plus ou moins "gourmands" : par exemple, Il peut y avoir un rapport de 1 à 10 entre le volume d’un fichier au format .csv et les mêmes données dans un format .xls
2 - réduire le nombre de ressources :
Limiter le nombre de formats proposés si cela n'est pas indispensable
Il est bien entendu possible de présenter plusieurs formats pour un jeu de données. Cela facilite le traitement du point de vue du réutilisateur. Mais il faut avoir conscience que chaque duplication avec un format particulier augmente le volume de données stockées
La co-existance fréquente de multiples formats (csv, json, xls, shp, …) pour un même jeu de données doit poser la question de la pertinence de cette multiplication. Sans la bannir, cette pratique doit être mise en oeuvre si elle est vraiment indispensable.
3 - proposer la récupération des informations sous forme d'API
Proposer systématique un accès sous format d'API dans le cas des données volumineuses ou à changement d'état fréquent afin d’effectuer des requêtes pour filtrer/trier les données à la source.
Lorsque le fichier est trop volumineux, il vaut mieux accéder directement à une partie des données à travers les critères d'accès que proposera un service d'accès informatique ou API.
De même pour les données changeant d'état fréquemment (par exemple; la disponibilité en temps réel des parkings), il sera plus pertinent de ne charger que les enregistrements récents ou les derniers changements plutôt que la base entière.
On ne réduit pas le fichier source mais uniquement les données transmises.
4 - formater le fichier pour éviter les redondances
Choisir le format de présentation des données le plus adapté
On trouve parfois plus pratique de publier les données au format tabulaire alors que certains jeux de données sont plus légers dans un format type json. Vouloir les rendre tabulaires multiplie énormément les redondances dans les chaines de caractère communes.
5- réduire les informations aux données essentielles (filtre à la production).
Supprimer les informations inutiles, redondantes ou non essentielles
Supprimer les colonnes redondantes (doublon ou déductibles). Par exemple, si un jeu de données précise le code INSEE d’une commune, inutile de fournir son nom, son département ou sa région. Ces informations peuvent être obtenues par croisement avec un référentiel.
6 - fragmenter le fichier pour permettre des téléchargements partiels à l'utilisateur.
Découper les ressources avec une granularité et une couverture géographique et temporelle adaptée
Par exemple, un fichier des résultats des 10 dernières élections peut être découpé en 10 fichiers, un pour chaque élection et ainsi limiter les flux de données de données non-utilisées côté utilisateurs.
7 - compresser le fichier pour optimiser les téléchargements
Mettre en oeuvre quand cela est possible des fonctions de compression des données ou des transferts.
Il est possible de proposer au téléchargement des fichiers compressés lorsque le volume et l'efficacité de la compression le justifie. Certains portails offrent des fonctions de compression lors des transferts (exemple : opendatasoft).
- un jeu de données indépendant pour chaque élection
- aucun jeu de donnée ne dépasse 40 Ko
A l'inverse, une autre collectivité publie par exemple le résultats de toutes les élections depuis 1992 dans un même fichier. Le fichier .csv résultant est de 42 Mo, soit x1000 plus volumineux que celui d'une seule élection à Poitiers.
Certaine plateforme comme opendatasoft limite la taille maximum d'importation d’un jeu de données à 240 Mo. Au-delà, il convient soit de compresser ou de fragmenter le jeu de donnée.
- Réduire le volume de données stockées : https://ecoresponsable.numerique.gouv.fr/publications/bonnes-pratiques/usage-administration-parametrages/reduire-volume-donnees-stockees/
Dernière mise à jour 10mo ago