Open Data : les propositions des industriels du logiciel au gouvernement

Open Data : les propositions des industriels du logiciel au gouvernement

Le club des cinq propositions

Avatar de l'auteur
Xavier Berne

Publié dans

Droit

24/04/2014 5 minutes
21

Open Data : les propositions des industriels du logiciel au gouvernement

À l’occasion de la tenue de la Conférence de Paris consacrée à l’Open Data, l’association des industriels français du logiciel, l’AFDEL, a dévoilé cinq propositions (PDF) visant à accélérer l’impact économique de l’ouverture des données publiques en France. Petit tour d’horizon. 

afdel data

 

La présentation de ces cinq propositions par l’Association française des éditeurs de logiciels et solutions internet (AFDEL) n’est absolument pas anodine, puisqu’elle intervient au même moment que la Conférence de Paris sur l’Open Data, où sont notamment attendus plusieurs membres du gouvernement. Après avoir souligné que la politique française d’ouverture des données publiques avait « considérablement progressé ces dernières années, en particulier au niveau du cadre réglementaire », l’AFDEL explique avoir constaté que le développement de l’Open Data demeurait aujourd’hui « en deçà des ambitions affichées initialement » par les autorités, tout du moins sur le plan économique.

Encore un peu de ménage dans les redevances

Rappelons qu’en contrepartie de l’ouverture de certains jeux de données publiques, les administrations peuvent demander une redevance aux professionnels (ou aux particuliers) qui souhaiteraient en faire une réutilisation, éventuellement commerciale. Le rapport Trojette estimait d’ailleurs l’année dernière que ces licences avaient rapporté 36,8 millions d’euros à l’État en 2010, 52,1 millions d’euros en 2011, puis 34,7 millions d’euros en 2012. Sauf que ces barrières financières étaient décrites par ce magistrat de la Cour des comptes comme un frein à la transparence, à la modernisation de l’action publique mais aussi au développement économique - certaines start-up n’ayant parfois pas les moyens de payer plusieurs dizaines de milliers d’euros pour un jeu de données publiques.

 

De ce fait, Jean-Marc Ayrault a annoncé en décembre 2013 qu’aucune redevance nouvelle ne serait créée, et que certaines actuellement en vigueur avaient vocation à disparaître dès cette année. L’objectif était clair : affirmer et soutenir le principe de gratuité des données publiques, alors que certaines administrations plaident au contraire pour pouvoir continuer d'exploiter cette manne financière.

 

Quelles sont donc ces idées à même de promouvoir « une politique de l’Open Data plus volontariste et ambitieuse » ? Tout d’abord, l’AFDEL préconise de revoir la notion de redevance. L’association préconise en effet de la supprimer « dès lors que cette redevance n’a pas d’impact sur l’équilibre économique de l’organisme public producteur de ces données ». En clair, l’idée est d’imposer aux administrations ne dépendant pas économiquement des redevances (ministère de l’Éducation nationale, la DILA,...) la gratuité, sans forcément remettre en cause celles d’organismes tels que Météo France ou l’IGN. Cette proposition se situe dans les pas du rapport Trojette, dont les annonces de Jean-Marc Ayrault constituaient une première étape (suppression des redevances de la DILA notamment).

Davantage de gouvernance, aux niveaux national et européen

Ensuite, les industriels du logiciels plaident pour une meilleure gouvernance, en réclamant la création d’un « organe de gouvernance » au niveau national, et un second au niveau européen. Le premier serait ainsi chargé « de coordonner les initiatives Open Data des collectivités territoriales pour définir et maintenir un référentiel commun (taxonomie) », notamment à propos des types de données mises à disposition, des API proposées... Soulignons à cet égard que ce mouvement semble sur le point de s'engager, puisque la ministre de la Réforme de l’État a récemment indiqué au Sénat que la mission Etalab, qui assiste actuellement les administrations souhaitant ouvrir des données, pourrait bientôt se transformer en un « Secrétariat général des données » à part entière (voir notre article). S’agissant de l’organe de gouvernance de niveau européen, il pourrait avoir à « coordonner les initiatives Open Data nationales pour définir et maintenir un référentiel commun ».

Plus d’harmonisation pour les API, ainsi que des formats ouverts et libres

Ces deux organes auraient également pour mission de décider des formats dans lesquels les données doivent être ouvertes (alors que ce choix est aujourd’hui entre les mains des administrations). À cet égard, l’AFDEL réclame à ce qu’un format de mise à disposition de données « pivot » soit imposé « pour la majorité des données de l’Open Data ». L’association plaide pour un format « libre de tous droits » et basé sur le XML.

 

Dans le même ordre d’idée, les industriels du logiciel demandent à ce que les API, les interfaces de programmation, soit normalisées « au maximum ». L’idée est d’éviter que chaque fournisseur de données développe sa propre API, ce qui contraint les réutilisateurs à s’adapter à chaque système.

Écrit par Xavier Berne

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Encore un peu de ménage dans les redevances

Davantage de gouvernance, aux niveaux national et européen

Plus d’harmonisation pour les API, ainsi que des formats ouverts et libres

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (21)




L’association plaide pour un format « libre de tous droits » et basé sur le XML.



RDF?http://www.w3.org/RDF/

Et puis sinon pourquoi XML? C’est lourd comme langage et le parseur DOM est bien moins performant qu’un parseur JSON ou yaml.



Autant c’est nécessaire de faire ce genre d’initiatives politique autant les solutions techniques proposées me font penser à “comme ça existe déjà on fera pas plus”.








artragis a écrit :



RDF?http://www.w3.org/RDF/

Et puis sinon pourquoi XML? C’est lourd comme langage et le parseur DOM est bien moins performant qu’un parseur JSON ou yaml.



Autant c’est nécessaire de faire ce genre d’initiatives politique autant les solutions techniques proposées me font penser à “comme ça existe déjà on fera pas plus”.







A l’heure de l’abandon progressif du XML pour le passage au JSON, l’état décide de pousser le XML <img data-src=" /> Comme d’habitude, 2 trains de retard.

Après, l’XML a un avantage certain, c’est qu’il est simple d’écrire des DTD permettant de définir proprement (et de valider) le format d’échange. C’est un peu plus délicat en JSON.









vermi a écrit :



A l’heure de l’abandon progressif du XML pour le passage au JSON, l’état décide de pousser le XML <img data-src=" /> Comme d’habitude, 2 trains de retard.







Il est question de l’AFDEL pour le coup dans l’article qui n’a rien à voir avec l’état à priori…









cactusbidon a écrit :



Il est question de l’AFDEL pour le coup dans l’article qui n’a rien à voir avec l’état à priori…









cactusbidon a écrit :



Il est question de l’AFDEL pour le coup dans l’article qui n’a rien à voir avec l’état à priori…







Effectivement, autant pour moi. C’est du coup encore plus problématique si c’est l’organisation qui doit représenter le secteur <img data-src=" />









artragis a écrit :



RDF?http://www.w3.org/RDF/

Et puis sinon pourquoi XML? C’est lourd comme langage et le parseur DOM est bien moins performant qu’un parseur JSON ou yaml.



Autant c’est nécessaire de faire ce genre d’initiatives politique autant les solutions techniques proposées me font penser à “comme ça existe déjà on fera pas plus”.







J’ai participé au dernier open data camp et ai pu à cette occasion rencontrer les ingénieurs d’Etalab. Je leur ai demandé s’il y avait une feuille de route pour RDF et et le Web sémantique, et ils m’ont répondu qu’ils en comprenaient les avantages, mais que l’effort était pour l’instant focalisé sur la quantité de données libérées et réutilisées.



XML c’est dans un certain sens mieux que du XLS (Excel), mais seulement si ce sont des données en forme d’arbre (hierarchiques). Pour des données tabulaires, le CSV est ce qu’il y a de plus simple à traiter.



Edit: pour être pointilleux, RDF n’est pas un format de fichier dérivé de XML, mais un modèle de données standard dont une des sérialisation est en XML (RDF/XML).









artragis a écrit :



RDF?http://www.w3.org/RDF/

Et puis sinon pourquoi XML? C’est lourd comme langage et le parseur DOM est bien moins performant qu’un parseur JSON ou yaml.



Autant c’est nécessaire de faire ce genre d’initiatives politique autant les solutions techniques proposées me font penser à “comme ça existe déjà on fera pas plus”.





Un parser yaml est bien plus complexe qu’un parser JSON ou XML. Il est simplement plus facile humainement à lire.



Sinon parser du JSON ou du XML, c’est pareil.







vermi a écrit :



A l’heure de l’abandon progressif du XML pour le passage au JSON, l’état décide de pousser le XML <img data-src=" /> Comme d’habitude, 2 trains de retard.

Après, l’XML a un avantage certain, c’est qu’il est simple d’écrire des DTD permettant de définir proprement (et de valider) le format d’échange. C’est un peu plus délicat en JSON.







Abandon ? Ou ça ? Dans le web peut être.







supercolino a écrit :



Pour des données tabulaires, le CSV est ce qu’il y a de plus simple à traiter.







Ou là, non, CSV n’est pas du tout un format. J’ai essayé de partager des données entre Excel et LibreOffice en CSV. C’est juste l’enfer. Excel rajoute des ‘“’ autour des string, il utilise ‘,’ pour les nombres flottant au lieu du ‘.’ habituel, il tronque les données trop longues, le retour chariot créait une nouvelle ligne…



Si ils veulent du CSV, qu’ils le définissent clairement :

Avec l’élément de séparation au début du fichier, “.” comme virgule de nombre, pas de “ pour les strings, et un encodage comme \n \; , pour définir les retour à la ligne dans une case, l’utilisation du caractère de séparation dans la ligne (ou alors utiliser le U du XML), et imposer vraiment l’UTF-8.










cyrano2 a écrit :



Abandon ? Ou ça ? Dans le web peut être.







Dans les webservice sur le web oui. C’est plus léger, plus lisible, beaucoup d’avantages. Après, comme je l’ai indiqué, le XML a l’avantage de pouvoir être transporté avec sa DTD, ce que le json ne sait pas faire (du moins directement).









cyrano2 a écrit :



Ou là, non, CSV n’est pas du tout un format.





Jusqu’a preuve du contraire si







cyrano2 a écrit :



J’ai essayé de partager des données entre Excel et LibreOffice en CSV. C’est juste l’enfer. Excel rajoute des ‘“’ autour des string, il utilise ‘,’ pour les nombres flottant au lieu du ‘.’ habituel, il tronque les données trop longues, le retour chariot créait une nouvelle ligne…





Excel et LO implémente ce format de différente manière c’est tout.

Pour ce qui est des virgule Excel est dans de vrai si il a été réglé avec des options régional Française. Pour ce qui est des troncature et autre ça c’est une autre histoire







cyrano2 a écrit :



Si ils veulent du CSV, qu’ils le définissent clairement :





On est d’accord





cyrano2 a écrit :



Avec l’élément de séparation au début du fichier, “.” comme virgule de nombre, pas de “ pour les strings, et un encodage comme \n \; , pour définir les retour à la ligne dans une case, l’utilisation du caractère de séparation dans la ligne (ou alors utiliser le U du XML), et imposer vraiment l’UTF-8.





Là les avis vont diverger.

Pourquoi mettre l’élément de séparation en début de fichier ? La spec dois le dire, le mettre dans le fichier d’export n’est qu’une redondance inutile.

Le point n’est pas le séparateur pour les décimal en France





Mais utiliser du CSV n’est peut être pas la meilleur solution









cyrano2 a écrit :



Ou là, non, CSV n’est pas du tout un format. J’ai essayé de partager des données entre Excel et LibreOffice en CSV. C’est juste l’enfer. Excel rajoute des ‘“’ autour des string, il utilise ‘,’ pour les nombres flottant au lieu du ‘.’ habituel, il tronque les données trop longues, le retour chariot créait une nouvelle ligne…



Si ils veulent du CSV, qu’ils le définissent clairement :

Avec l’élément de séparation au début du fichier, “.” comme virgule de nombre, pas de “ pour les strings, et un encodage comme \n \; , pour définir les retour à la ligne dans une case, l’utilisation du caractère de séparation dans la ligne (ou alors utiliser le U du XML), et imposer vraiment l’UTF-8.







Si si, le CSV est standardisé, sauf que Microsoft n’applique pas les specs :

http://tools.ietf.org/html/rfc4180



Excel est un très bon outil de tableur, mais LibreOffice est à recommander pour la manipulation de CSV/TSV (tab separated).



Au passage, un outil vient de sortir pour vérifier la validité d’un CSV:

http://csvlint.io/












mimoza a écrit :



Jusqu’a preuve du contraire si







C’est une blague ? Donnes moi la spécification dans ce cas !





Excel et LO implémente ce format de différente manière c’est tout.





Donc, ce n’est pas UN format. C’est une famille de format au mieux. Un fichier texte, qui sépare ses lignes par un retour chariot et ses colonnes par un signe, cela ne suffit pas !





Pour ce qui est des virgule Excel est dans de vrai si il a été réglé avec des options régional Française. Pour ce qui est des troncature et autre ça c’est une autre histoire



Là les avis vont diverger.

Pourquoi mettre l’élément de séparation en début de fichier ? La spec dois le dire, le mettre dans le fichier d’export n’est qu’une redondance inutile.





Selon les données, certain préfère ‘,’ qui est une horreur à lire avec des chiffres, ou “;” qui peut être lourd à lire avec des string.





Le point n’est pas le séparateur pour les décimal en France





Qu’est-ce que vienne faire les préférences régionales dans un format de fichier ?!









Mais utiliser du CSV n’est peut être pas la meilleur solution





XML, c’est ok, si il y a un bon schéma. Mais les fonctionnalités avancés de XML peuvent être pénible (namespace, …)









mimoza a écrit :



Jusqu’a preuve du contraire si





Excel et LO implémente ce format de différente manière c’est tout.

Pour ce qui est des virgule Excel est dans de vrai si il a été réglé avec des options régional Française. Pour ce qui est des troncature et autre ça c’est une autre histoire





On est d’accord



Là les avis vont diverger.

Pourquoi mettre l’élément de séparation en début de fichier ? La spec dois le dire, le mettre dans le fichier d’export n’est qu’une redondance inutile.

Le point n’est pas le séparateur pour les décimal en France





Mais utiliser du CSV n’est peut être pas la meilleur solution







Les recommandations pour la création de CSV, trop peu connues !

https://tools.ietf.org/html/rfc4180









cyrano2 a écrit :



XML, c’est ok, si il y a un bon schéma. Mais les fonctionnalités avancés de XML peuvent être pénible (namespace, …)







Si le schéma n’est pas standard, c’est pire que le CSV en terme de normalisation.









supercolino a écrit :



Si si, le CSV est standardisé, sauf que Microsoft n’applique pas les specs :

http://tools.ietf.org/html/rfc4180



Excel est un très bon outil de tableur, mais LibreOffice est à recommander pour la manipulation de CSV/TSV (tab separated).



Au passage, un outil vient de sortir pour vérifier la validité d’un CSV:

http://csvlint.io/







Je n’ai pas vu la définition de l’encodage du fichier. L’UTF-8 devrait être forcé.

Il n’y a rien pour l’usage de ‘,’ à l’intérieur d’un champ. A priori, ce n’est pas possible, sauf peut être entre ‘ “ ‘.









cyrano2 a écrit :



Qu’est-ce que vienne faire les préférences régionales dans un format de fichier ?!







Là où il veut en venir c’est que comme les nombres ne sont pas délimités par des guillemets, la valeurs de Pi devient:



France

“Valeur de Pi”,3,14 =&gt; Valeur de Pi | 3 | 14



US

“Value of Pi”,3.14 =&gt; Value of Pi | 3.14









supercolino a écrit :



Si le schéma n’est pas standard, c’est pire que le CSV en terme de normalisation.







Pourquoi ? Il y a un tas d’outils qui te file le parser juste avec la DTD. C’est assez pratique. C’est sûr que la DTD doit être réutilisé, mais cela n’est pas pire qu’avec la définition du contenu du CSV.









cyrano2 a écrit :



Je n’ai pas vu la définition de l’encodage du fichier. L’UTF-8 devrait être forcé.

Il n’y a rien pour l’usage de ‘,’ à l’intérieur d’un champ. A priori, ce n’est pas possible, sauf peut être entre ‘ “ ‘.







Oui, en toute logique les virgules ne devraient être utilisées que dans des chaînes de caractères (strings), donc ‘échappées’ par des guillemets.



Quant à l’encodage, je suppose que tu voulais parler d’unicode en général. L’UTF-8 couvre 95% des cas, mais d’autres encodages peuvent parfois être nécessaires.









cyrano2 a écrit :



Pourquoi ? Il y a un tas d’outils qui te file le parser juste avec la DTD. C’est assez pratique. C’est sûr que la DTD doit être réutilisé, mais cela n’est pas pire qu’avec la définition du contenu du CSV.







Ah oui, effectivement, si le nom des colonnes dans un CSV varie tout le temps, c’est pas pratique.





L’association plaide pour un format « libre de tous droits » et basé sur le XML.





ok, j’ai eu la même réaction : WTF !








trevisev a écrit :



ok, j’ai eu la même réaction : WTF !





C’est quoi comme format , ca ?





Le club des cinq propositions





Ou le Club Med F ?








Drepanocytose a écrit :



C’est quoi comme format , ca ?







Le WTF est un format qui est couramment utilisé dans les projets utilisant la méthodologie RACHE. L’intérêt de ce format est qu’il s’applique à tous les langages et qu’il est devenu de facto un standard. Par exemple en Java, Javascript et Ruby.



A noter qu’il existe une licence WTFPL. Bien qu’elle n’ait pas de lien direct avec le format éponyme, elle peut tout à fait convenir aux API en format WTF.