Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Open Data : les propositions des industriels du logiciel au gouvernement

Le club des cinq propositions

À 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.

21 commentaires
Avatar de artragis Abonné
Avatar de artragisartragis- 24/04/14 à 11:06:46

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".

Avatar de vermi Abonné
Avatar de vermivermi- 24/04/14 à 11:21:37

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 :D 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.

Avatar de cactusbidon Abonné
Avatar de cactusbidoncactusbidon- 24/04/14 à 11:35:32

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 :D 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...

Avatar de vermi Abonné
Avatar de vermivermi- 24/04/14 à 11:38:32

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 :mdr:

Avatar de ColinMaudry Abonné
Avatar de ColinMaudryColinMaudry- 24/04/14 à 12:02:20

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).

Édité par supercolino le 24/04/2014 à 12:04
Avatar de cyrano2 Abonné
Avatar de cyrano2cyrano2- 24/04/14 à 12:24:40

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 :D 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.

Avatar de vermi Abonné
Avatar de vermivermi- 24/04/14 à 12:30:01

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).

Avatar de Mimoza Abonné
Avatar de MimozaMimoza- 24/04/14 à 13:00:13

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

Avatar de ColinMaudry Abonné
Avatar de ColinMaudryColinMaudry- 24/04/14 à 13:10:07

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/

Avatar de cyrano2 Abonné
Avatar de cyrano2cyrano2- 24/04/14 à 13:12:03

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, ...)

Il n'est plus possible de commenter cette actualité.
Page 1 / 3
  • 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
S'abonner à partir de 3,75 €