J’ai souvent entendu cette question de la part de personnes souhaitant ardemment voir ces données être davantage réutilisées. Le format CSV est effectivement simple à utiliser, principalement en raison du fait qu’il peut être édité et lu dans un logiciel de tableur.
Cependant, la simplicité d’utilisation va avec la simplicité de la structure des données qu’il est possible d’y ajouter. Prenons les données de marchés publics. Le décret impose que les données suivantes (entre autres) soient représentées :
- identifiant de marché
- montant
- procédure utilisée
- titulaires
- identifiant (SIRET) du titulaire
- nom du titulaire
- modifications
- de montant
- de titulaires
- identifiant (SIRET) du titulaire
- nom du titulaire
Dans un fichier CSV, les données sont stockées en ligne et colonnes (exemple avec les bornes de recharge). Chaque ligne est un truc qui a des caractéristiques. On parle d’objet et de propriétés en informatique. Donc dans un fichier CSV de marchés publics, on aurait, idéalement, une ligne par marché. On aurait donc les colonnes identifiant, montant, procedure, titulaires….
Comment stocker plusieurs titulaires et leurs propriétés dans une case ? On pourrait avoir les colonnes siretTitulaire1, siretTitulaire2, etc. mais il n’y a en théorie pas de nombre maximum de titulaires dans un marché. Et comme il s’agit d’un format standard, tous les acheteurs publics devraient se coltiner un fichier avec 20 colonnes dédiées aux titulaires. Donc non.
Et je ne parle même pas des modifications de titulaires, sachant qu’un marché peut avoir une infinité de modifications, qui elles mêmes peuvent avoir une infinité de titulaires !
Tableau vs. arbre
Heureusement, il existe des formats de fichiers qui ne sont pas en lignes, mais en arbre, comme XML et JSON. Un exemple commenté vaut mieux qu’un long discours, avec un marché fictif au format JSON (les objets sont délimités pas des { }, les listes par des [ ]) :
La structure du fichier est en arbre, car des « branches » peuvent pousser d’autres « branches » : la propriété modifications peut avoir une infinité d’enfants (ici 1), et la propriété titulaires en a 2.
Je sais que ce format n’est pas utilisable directement sans outil dédié. En revanche, JSON étant le format de données standard des applications Web, il est très facile de concevoir des applications qui permettent de visualiser ces données (j’ai fait ça, et le développement Web n’est pas ma spécialité : sireneLD).
En fait, il est possible de reproduire ces données en CSV. On pourrait avoir un CSV pour les données simples du marché (id, montant, procedure, etc.), un CSV pour les titulaires, et un CSV pour les modifications. Les CSV seraient liés entre eux grâce à l’identifiant de marché. Je réfléchis à proposer ce CSV, mais il ne serait pas non plus facilement utilisable par des non-informaticien·nes.
Les formats de données ne sont pas une question de goût, et ne sont pas interchangeables. Compte tenu de la structure des données à représenter, le format CSV ne convenait pas, et nous avons indiqué dans l’arrêté que les formats des données seraient XML et JSON (au choix de l’acheteur public). Le format CSV convient très bien pour les subventions, les bornes de recharge, mais pas pour des données plus complexes comme les marchés publics. L’avantage d’une structure plus complexe, c’est qu’elle permet de représenter le réel plus fidèlement, et donc de poser des questions plus complexes aux données.
Voilà, j’espère que c’est clair ! N’hésitez pas à poser vos questions et vos commentaires ci-dessous ou sur Twitter.