Je pense qu’on est nombreux à être d’accord là dessus.
Un cycle prévisible d’évolution du RGI serait nécessaire car on ne peut pas rester figé trop longtemps, ni changer sans arrêt les règles.
Il faut de plus des périodes de recouvrement pour permettre de basculer petit à petit, ce qui veut dire que la diffusion doit se faire pendant un certain temps selon plusieurs standards.
Je pense qu’on est tous d’accords que le RGI mériterait des évolutions et que d’autres formats que le CSV pourraient être utiles pour les usages de beaucoup.
Pour autant n’oublions pas le plus grand nombre : l’immense majorité des gens ne sait pas et ne saura jamais utiliser autre chose que des logiciels de tableur.
IMHO Parquet ne saurait donc venir en remplacement, tout au plus en complément.
Oui, le csv est loin de disparaitre et je partage totalement la remarque de @boogheta « Pour autant n’oublions pas le plus grand nombre : l’immense majorité des gens ne sait pas et ne saura jamais utiliser autre chose que des logiciels de tableur. »
Une question au passage sur le CSV pour OpenDataSoft (@jean-marc.lazard) : pourquoi ne proposer que l’export csv point-virgule sur les portails ODS (cf documentation ? Et ne pas laisser le choix à l’usager avec le séparateur virgule qui est la norme internationale de facto ?
@boogheta et @samgoeta , je suis d’accord avec vous : le plus grand nombre n’utilisera jamais autre chose qu’un logiciel de tableur… mais cela ne veut pas dire qu’ils continueront à utiliser le format CSV. Ni un éventuel autre format en texte plein mal standardisé et dont l’ouverture dans un logiciel de tableur est tout sauf facile dès qu’elle requiert de sélectionner soi-même le séparateur ou l’encodage et qu’ils ne sont pas ceux par défaut de son tableur avec ses paramètres de localisation.
Les utilisateurs de tableur préfèrent télécharger un jeu de données au format XLSX ou ODS plutôt que CSV, quand ils ont le choix, et ils ont raison car les premiers s’ouvrent directement correctement dans leur tableur (en plus d’inclure les éventuelles formules, tableaux croisés et liens entre feuilles).
À mon sens, l’avenir pour le plus grand nombre ne sera pas le format CSV, mais sans doute plutôt Parquet ou un autre format de données de ce type que les tableurs sauront ouvrir (il existe par exemple déjà un add-in pour ouvrir du Parquet dans Excel: https://www.cdata.com/drivers/parquet/excel/).
Il n’est pas exclus non plus que le tableur soit remplacé ou rendu obsolète dans ses usages actuels détournés par de nouveaux outils, qui répondront mieux et plus simplement à ces besoins, et utiliseront des formats standards ouverts mais binaires et pas en texte plein.
Bref, actuellement, Parquet ne répond pas aux besoins du plus grand nombre, mais le format CSV a trop de défauts même pour ces utilisateurs, ce qui en fait tout sauf un horizon indépassable.
J’ai trouvé comment exporter en csv avec séparateur virgule sur ODS : il faut changer le delimiter dans le lien d’export en CSV.
A la fin, il y a delimiter=%3B. Il faut remplacer par delimiter=%2C.
Celle-ci est construite à partir de vos nombreuses contributions (cf historique) et d’un sondage Mastodon.
Le sondage a obtenu 53 réponses à la question « quelle solution est à mettre en oeuvre ? » avec la répartition suivante parmi les quatre réponses possibles :
La synthèse s’appuie sur les questions posées dans le message initial.
J’espère que celle-ci reflète bien tous les avis exprimés.
Bonne lecture !
La première réponse est oui. En effet, la norme (RFC4180) est très restrictive et n’a pas été mise à jour depuis 2005 :
Le RGI (Référentiel Général d’Interopérabilité), dans sa dernière version de 2015 (qui demanderait à être actualisée), avait déja classé ce format « en fin de vie ».
La deuxième réponse est non. En effet, le format CSV, malgré ses limitations, est le format le plus utilisé dans les échanges de données tabulaires.
Il est simple et compréhensible, lisible par n’importe quel éditeur de texte et la majorité des applications traitant des données tabulaires proposent ce format d’échange.
Cependant, les formats CSV utilisés sont des variantes et extensions de la norme permettant par exemple d’avoir d’autres types de séparateur, d’intégrer des formats UTF8 ou encore d’avoir une gestion d’entête plus ou moins sophistiquée. L’utilisation de ce format associé à une compression (ex. zip) permet d’obtenir des tailles de fichiers comparables à d’autres solutions plus optimisées.
En synthèse :
La encore, les avis sont partagés :
En synthèse, la réponse est dans la question : Comme il n’y a pas de format alternatif largement déployé, on continue de fonctionner avec l’existant mais si un format
alternatif émerge et répond aux limitations et attentes identifiées, il remplacera le format CSV.
De même que pour la question précédente, deux approches distinctes émergent :
Les deux approches sont complémentaires (avoir de bonnes performances sur des volumes de données importants n’est pas toujours compatible avec la capacité à traiter des données complexes avec un niveau sémantique élevé). Les deux solutions sont donc nécessaires. Il reste néanmoins dans la seconde approche à identifier une solution JSON déployable sur la majorité des applications (ce qui prendra du temps).
Peu de réponses ont été apportées à ces questions qui sont trop orientées sur une solution technique. Celles-ci ne pourront être abordées que dans le cadre d’une réflexion autour d’un format texte alternatif qui reste à engager.
Merci pour ce résumé très intéressant.
Ralala j’ai manqué la conversation, donc j’arrive un peu en retard…
Pour apporter ma petite pierre à la réflexion, nous utilisons CSV comme un de nos formats d’export chez Open Food Facts : Data
Comme le volume de données est très important (~7 Go) l’export n’est pas fait pour s’ouvrir dans Excel. On a donc dû documenter quelques manières d’exploiter nos exports dont le CSV :
Reusing Open Food Facts Data - Open Food Facts wiki
L’avantage du CSV c’est quand même que beaucoup savent le lire et qu’il existe une myriade d’outils permettant de le manipuler. Même sur un fichier de 7 Go comme le nôtre, je fais tourner csvclean, visidata, xsv, etc. Même de bon vieux outils comme grep peuvent rendre des services avec CSV.
Dans notre cas, CSV a quelques inconvénients importants :
C’est pour toutes ces raisons qu’on a commencé à regarder Parquet (sur les conseils judicieux de @mathieu). J’ai ouvert une « issue » et effectué quelques tests déjà très prometteurs : Investigate database export as parquet file · Issue #7660 · openfoodfacts/openfoodfacts-server · GitHub
Merci pour ce retour très clair !
J’ai l’impression que cela conforte le fait que d’une part le CSV devient chaque jour un peu plus obsolète et que d’autre part il y a bien les deux types de solutions alternatives proposées dans le dernier message posté (Parquet semblant être la solution qui réponde actuellement le mieux au volet ‹ performances ›).
J’en profite également pour poser une question sur Open Food Facts Data :
les données manipulées notamment au niveau des API (cf lien Data) ont l’air très complexes. Est-ce qu’une approche comme celle présentée dans le projet JSON-NTV(voir exemples également) pourrait avoir un apport ?
Un cas intéressant où la diffusion en parquet présente des avantages clairs (ici interrogation rapide d’une « grosse » base) :
`@InseeFr commence à diffuser au format Parquet !
— Éric Mauvière 🇺🇦 (@ericMauviere) September 5, 2023
Avec https://t.co/Z9ahRPdVsv, requête en direct sur le fichier de 470 mo des adresses géocodées des électeurs par bureau de vote (https://t.co/SPxzVIo8BC).
Toulouse en tête pour le nb d'adresses, résultat en 1 s, chapeau @duckdb 🙌 pic.twitter.com/f651WCtAE5
En effet, l’Insee a bien compris l’intérêt du Parquet, et propose pour que ce soit le format par défaut pour les « micro-données ».
Je profite de la découverte de cet outil … 
… pour partager d’autres références :
Présentation à la conférence du High-Level Group for the Modernisation of Official Statistics (HLG-MOS) de novembre
Article du courrier des statistiques de juin dernier
Chez Open Food Facts on a fait pas mal de tests sur le format Parquet (long thread ici), à partir de notre fichier CSV de 8 Go (3 000 000+ de lignes, ~200 colonnes).
En comparaison avec CSV, Parquet est assez bluffant :
Les résultats sont tellement bons qu’on envisage même de diffuser les données ET leurs mises à jour au fil de l’eau dans le même fichier (pour un surcoût très faible).
Il ne manque plus qu’une interface de consultation qui abaisse la barrière à l’usage. Pour ma part je suis un fan de Datasette, mais hélas ce dernier ne le gère pas.
Merci pour les suggestions. Je pensais cependant à des interfaces plus faciles d’accès pour le commun des mortels.
L’intérêt de Datasette c’est que tu peux monter progressivement en compétence : démarrer par l’interface tableau+filtres+tris et basculer progressivement sur le mode SQL au fur et à mesure de tes besoins.
Merci Tam Kien ! J’avais manqué ta première référence, qui a l’air prometteuse, quoiqu’un peu expérimentale. Elle devrait peut-être suffire pour mes besoins, je vais investiguer.
Quant à la seconde c’est moins intéressant pour moi pour plusieurs raisons : elle n’utilise pas parquet nativement, c’est une conversion, donc autant convertir en sqlite pour utiliser Datasette.
Un document Observable aménagé, avec des listes de critères et aussi un espace de saisie pour entrer des requêtes SQL, éventuellement assistées, c’est faisable et ce peut être, en effet, un bon compromis.
D’autant que l’on peut insérer dans une page web quelconque des composants venant d’un classeur Observable, pour une intégration plus transparente.
Je ne connaissais pas non plus le RGI. Je lis qu’il est un cadre de recommandations et non une obligation.
A titre personnel, je vais créer trois formats différents pour un jeu de données :
Je vous ferai des retours sur les stats de téléchargements !
Pas vraiment… le respect du RGI est une obligation pour les administrations :
https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000006317216 article 14…
II. - Les systèmes d’information existant à la date de publication du référentiel général d’interopérabilité mentionné à l’article 11 sont mis en conformité avec celui-ci dans un délai de trois ans à compter de cette date. Les applications créées dans les six mois suivant la date de publication du référentiel sont mises en conformité avec celui-ci au plus tard douze mois après cette date.
En vigueur depuis 2005.
Repéré grâce à un post LinkedIn de @BorisM, le format parquet est désormais disponible par défaut pour toutes les plateformes OpenDataSoft
