Au quotidien, le travail est difficile pour les responsables des services Open Data des administrations publiques. Il faut faciliter la possibilité de trouver des données, poursuit Hadley Beeman (voir la 1re partie du dossier). Il faut les harmoniser. Bien souvent par exemple, les données de géolocalisation dont disposent les administrations sont imparfaites et rares sont celles qui proposent des adresses géocodées c’est-à-dire avec des coordonnées géographiques précises. Les adresses de mise à disposition des jeux de données doivent rester stables et ne pas se superposer. « On a besoin de vocabulaires communs dans la description des données, de catégories utilisées d’une administration à l’autre… et l’internationalisation ne fait que renforcer ces questions d’interopérabilités. »

L’impossible interopérabilité ?

La tâche semble énorme, peuplée de chausse-trappes. Et les problématiques techniques de l’ouverture et de la réutilisation des données publiques semblent submerger tous les acteurs.

Même son de cloche du côté d’Ivan Herman qui travaille à ces questions de standardisation de l’Open Data pour le W3C, l’organisme de normalisation du web (voir sa présentation) : « L’infrastructure et l’écosystème à créer sont très complexes ». La réalité des données ouvertes repose sur des espaces très désordonnés et hétérogènes. Les développeurs n’utilisent pas RDF, le langage du web sémantique, considéré comme trop complexe, d’autant que la plupart des applications savent s’en passer. L’essentiel des données est publié sous des formats plus simples, puis fouillés, extraits et intégrés par des applications logicielles. Au final, on se retrouve en face de deux alternatives, deux clans. D’un côté, ceux qui promeuvent le RDF mais pour lequel il faut encore créer les outils et les environnements pour en faciliter l’intégration, et ceux qui préfèrent les données brutes. Mais même la communauté du web sémantique semble avoir besoin d’un peu de stabilité technique. Le monde des métadonnées demeure très chaotique estime Ivan Herman : les vocabulaires se chevauchent, ils ne sont pas toujours faciles à localiser, ne sont pas toujours bien gérés ou entretenus… Le W3C travaille à un service de vocabulaire… Il travaille aussi à trouver des moyens d’ajouter des métadonnées au format CSV, un format de données très simple et très utilisé, qui représente des données tabulaires sous forme de valeurs séparées par des virgules. Il travaille enfin à un groupe pour documenter les bonnes pratiques de publication de données ouvertes permettant de mieux gérer la persistance, le versionning…

Irina Bolychevsky (@shevski) travaille pour l’Open Knowledge Foundation (Okfn, qui mène de nombreuses actions pour l’ouverture de la connaissance) au développement du projet Ckan une plate-forme open source de développement de portail de données. Comme elle l’explique elle-même (voir sa présentation), c’est un catalogue de métadonnées open source qui facilite l’indexation des jeux de données pour les réutilisateurs ainsi qu’une plateforme de management de données pour les éditeurs. Le logiciel fait tourner de nombreux portails de données comme les plateformes PublicData.eu, le répertoire de données national britannique et américain… Ckan travaille d’ailleurs à un protocole d’interopérabilité des catalogues de données.

Quand les machines comprendront les données

Raphael Troncy (@rtroncy) de l’école d’ingénieur et centre de recherche en Télécommunications Eurecom, travaille notamment sur le projet Event Media qui vise à faciliter la réutilisation de données événementielles (voir sa présentation). A l’occasion de sa venue à Marseille pour l’Open Data Week, Raphaël a tenté de trouver un événement culturel qui pourrait distraire sa soirée. Sur le portail Open Data Paca, il y a bien des ensembles de données événementiels, mais aucun ne mentionnait par exemple l’Open Data Week. Pas plus de bonheur du côté d’EventBrite ou d’Eventful, les deux plus importants moteurs de recherche d’événements.

Les événements sont des occurrences observables qui regroupent des gens, des lieux et une date documentés par des médias, explique le jeune chercheur. EventMedia a pour but de découvrir des événements passés, présents ou à venir, de permettre de les revivre ou de les préparer et d’améliorer la recherche et les mécanismes de recommandation. Pour cela, le défi porte sur la sémantisation, la réconciliation de données hétérogènes et clairsemées, estime Raphaël Troncy, puisqu’il faut rassembler à la fois des répertoires d’événements, des informations provenant des réseaux sociaux et de plateformes de médias. Pour EventMedia, le défi est d’explorer les connections sémantiques pour créer une meilleure vue et compréhension des événements à partir d’une vaste agrégation de données qu’il faut nettoyer avec des algorithmes de conciliation pour identifier et trier les événements (notamment quand les informations qui semblent évoquer un même événement ne sont pas exactement les mêmes, comme l’heure qui peut différer d’un site l’autre). Aujourd’hui, leur système engrange quelque 130 événements quotidiens (bien que de nombreux événements ne soient pas publiés sous une forme facilement récupérable). Certains types d’événements génèrent plus d’images que d’autres, comme les concerts ou les festivals. Le nombre de photos relatif à un événement n’est pas proportionnel au nombre de participants et dans la répartition par pays, on constate que les Américains et les Britanniques par exemple, ont tendance à plus partager de photos d’un événement que ceux d’autres pays.

Un premier démonstrateur d’EventMedia est en ligne.

François Scharffe (@lechatpito), chercheur au Laboratoire informatique robotique et microélectronique de l’université de Montpellier est le coordinateur du projet Datalift qui vise à améliorer les données et faciliter leurs croisements grâce à la sémantisation.

Bien souvent, les ensembles de données sont difficiles à intégrer, du fait des différences de formats, de champs, de métadonnées, de vocabulaires… Les technologies sémantiques permettant de créer un web de données interconnectées apparaissent alors comme la seule solution pour créer des identifiants et vocabulaires communs. Mais intégrer des données liées n’est pas une tâche facile. Il faut convertir les données, sélectionner les vocabulaires et ontologies de description, les interconnecter… Datalift est un projet de recherche qui vise à automatiser ces processus qui se font encore trop souvent manuellement, étape par étape. Pour cela, Datalift utilise des vocabulaires ouverts et liés. Mais cela demeure compliqué. Il faut apprendre à différencier les ressources, les documents et les données, favoriser les bonnes pratiques de nommage, trouver des solutions pour gérer les droits d’accès aux données en fonction du contexte.

Ces exemples montrent tous combien il est difficile de passer de la publication de données à faire que les machines comprennent ce qu’elles sont et sachent les relier entre elles. Tout le monde semble à la recherche d’une organisation idéale ou au moins plus structurée qu’elle n’est. En mettant le doigt dans l’ouverture des données, les spécialistes de l’Open Data, ont vite compris que les ouvrir ne suffirait pas. Pour qu’elles prennent sens, encore faut-il parvenir à les organiser… Le risque bien sûr est de s’embourber dans cette complexe organisation qui a le potentiel de révolutionner un jour les usages, mais qui, en attendant, semble laisser les usagers de côté.

Des solutions plus simples ?

Andrew Byrd (@globalvoid) est consultant pour Conveyal et travaille au projet Open Trip Planner, une plateforme open source pour la planification d’itinéraires de voyages. Il est venu évoquer le succès de la norme General Transit Feed Specification (GTFS, spécification générale pour les flux relatifs aux transports en commun), un format informatique standardisé pour communiquer des horaires de transports en commun et les informations géographiques associées.

GTFS est né à Portland en 2005 quand l’agence de transport locale, TriMet, a voulu créer une certification haute qualité pour les informations de transports. Le format GTFS adopté depuis par Google Transit est très simple : ce sont des données sous forme de fichiers textes où les données sont séparées par de simples virgules. GTFS a été créé comme une alternative aux normes XML très lourdes qui existaient afin d’échanger très simplement des données. Pour TriMet, les formats de données d’information sur les transports étaient trop compliqués. Leur conclusion était qu’il fallait des éléments plus petits et plus simples pour échanger les données sur les trajets et les horaires. GTFS est donc un schéma très simple, basé sur le format CSV (un format informatique ouvert représentant des données tabulaires sous forme de valeurs séparées par des virgules) qui produit des données légères, mais peu enrichies (sans métadonnées par exemple).

Pratique, ouverte, non propriétaire… la simplicité de GTFS a fait son succès. TriMet a favorisé son développement et fait école, tant et si bien qu’aux Etats-Unis, la norme s’est très largement répandue dans le domaine de l’information de transport. En France, plusieurs transporteurs l’utilisent : à Rennes, Nantes, Bordeaux. La RATP, le Transilien, le TER, l’INtercités également… Aux Pays-Bas, GTFS est la norme dans le transport public. Sa commodité permet bien sûr de générer de l’information passager, mais également de faciliter la planification urbaine, la communication, la recherche sur la mobilité ou les études d’impact des changements dans les systèmes de transport. TripPlanner de TriMet est un planificateur de trajet qui permet aux utilisateurs de faire leurs itinéraires, de visualiser la disponibilité des véhicules… GTFS est un bon contre-exemple à la complexité de bien des formats de l’Open Data. Certes, il n’est pas parfait, mais il fonctionne est peu coûteux et simple à mettre en place.

Pieter Colpaert (@pietercolpaert) responsable du groupe de travail sur l’ouverture des transports de l’Okfn est venu souligner (voir sa présentation) combien GTFS était devenu un standard de fait en évoquant l’initiative de l’Epsi Platform sur le transport un groupe de travail européen qui a publié un manifeste pour l’ouverture des données de transport. Pour que l’information de transport s’ouvre, nous avons besoin d’un cadre légal. « Nous avons besoin que les gouvernements demandent aux sociétés de transports que l’ouverture de leurs données soit partie intégrante du service qu’elles rendent », rappelle l’activiste.

Helsinki Open Transport Data Manifesto Infographic by ePSI Platform

Data ou API ?

L’excellente intervention de Christian Fauré (@christianfaure) a bien résumé les enjeux de ce débat technique. « Comment expliquer à une organisation quelle peut-être sa stratégie en matière de publication de données ? »

Pour Christian Fauré, il y a 2 chemins, qui n’ont ni les mêmes bénéfices, ni les mêmes contraintes, qui ne sont pas opposés, mais plus certainement combinables. Ces 2 chemins, il les appelle la Data Culture et l’API Culture.

La question de la publication des données pose des problèmes, car le fait de rendre publiques des données modifie par essence l’espace public lui-même. La distinction entre public et privé n’existe que par l’outil de publication, comme le rappelle la première technique de publication, celle des lois. « Toute organisation qui doit rendre public des données voit les frontières de son organisation devenir floue, poreuse et lui pose des questions. »

2 chemins donc. 2 cultures. D’un côté, il y a la « Data Culture » : l’idée est de publier des données sur le web pour qu’elles puissent être utilisables par des machines. Les données ont donc besoin d’être formalisées, normalisées selon les techniques du web sémantique et du RDF pour que les machines puissent les comprendre. Les difficultés de cette forme de publication c’est qu’un certain nombre de disciplines s’en sont emparées pour faire des choses intéressantes, mais en oubliant que le but n’était pas de faire des choses fabuleuses, mais de publier. Depuis 5 à 6 ans, face à une forme d’impasse, le web sémantique a changé de point de vue pour adopter l’approche des données liées (ou web des données, Linked Data). L’idée était alors de proposer plusieurs niveaux de qualité des données pour permettre aux gens d’avancer, selon le principe des 5 étoiles du chemin de déploiement des données ouvertes. Reste que les données publiées sont peu réutilisables par les machines si elles ne sont pas de grande qualité, à 4 ou 5 étoiles.

« L’initiative d’un Open Data lisible par les machines est devenue le plus souvent une poubelle de données », estime le spécialiste. « La bonne volonté de ne pas publier au bon format a été une catastrophe. Les mauvaises données ont contaminé toutes les données, toutes les autres initiatives. Il y a eu bien sûr quelques succès, d’estime, des expérimentations… mais dans ce régime de pratiques, les standards complexes à mettre en oeuvre, sont loin de proposer une économie avec du business« , souligne, pragmatique, le consultant indépendant.

Dans le même temps, une autre stratégie d’ouverture des données est apparue et est devenu massive : c’est l’API Culture, celle des interfaces de programmation. « Le succès de ces démarches-là n’est pas de publier directement des données, mais des interfaces pour accéder à ces données. Ceux qui publient des API savent très bien que leur public n’est composé que de développeurs. Les développeurs comprennent les API mais pas le web sémantique ni le RDF. Ils ne savent pas à quels problèmes répond le web des données. Par contre, si vous donnez à un développeur une API, il sait créer un écosystème avec. » Cette forme de publication s’accompagne d’évangélistes, de gens qui savent et viennent travailler avec les développeurs. « On ne trouve nulle part encore d’évangélistes de données pour faire la promotion des corpus de données ».

Une stratégie consiste donc à publier des données, l’autre à publier des questions, des requêtes… Ces deux stratégies sont à la fois différentes et semblables. Elles reposent toutes deux sur des catalogues : catalogues de données ou catalogues de requêtes possibles pour accéder aux données. Dans les deux cas, le catalogue demeure l’interface et nécessite d’avoir une stratégie de catalogage. « Combien d’organisations aujourd’hui se conçoivent comme devant organiser des catalogues ? »
Toute organisation doit donc désormais faire un choix. Quel catalogue doit-elle rendre public ? Une liste de données ou une liste de requêtes ? Pour répondre à cette question, il faut se poser quelques questions. L’organisation en question a-t-elle une culture des métadonnées et une richesse des jeux de données ? Si elle ne dispose pas de base de données riche (avec des liens, des métadonnées), il vaut mieux aller vers une stratégie Open API qu’Open Data.

S’il faut développer des services rapides, capables de monter en charge, là encore, on privilégiera une stratégie Open API. Si vous publiez des données et souhaitez que les utilisateurs puissent les enrichir, il faut privilégier encore une stratégie d’API. Si c’est juste une exposition de données, l’Open Data suffit, estime Christian Fauré.

Bien souvent, les requêtes s’avèrent plus précieuses pour mesurer l’usage. Quand vous ne publiez que des données, leur cycle de vie vous échappe. Dans le cadre de projets de types API, on peut plus finement gérer les niveaux d’accès que ce soit pour des collaborateurs internes, pour des partenaires spécifiques ou pour l’innovation externe.

Enfin, il faut regarder aussi le facteur temps. L’accès temps réel favorise le recours aux API, que ce soit pour les horaires des bus ou les dernières informations publiées sur les réseaux sociaux. « Si les données n’ont une valeur que si elles sont fraiches, on est traditionnellement dans une économie de l’attention, financée par le marketing et la pub, c’est une business culture, une API culture. Si on travaille avec des données qui prennent de la valeur dans le temps, il est évident que je me retrouve dans un contexte de Data Culture qui bénéficie du travail sémantique, de l’économie de la mémoire, bien souvent non marchand ou qui relève de la puissance publique. »

Image : Data Culture vs API Culture. Image extraite de la présentation de Christian Fauré.

Data Culture et API Culture convergent, reconnaît Christian Fauré. Les développeurs qui ne comprenaient pas beaucoup le RDF, commencent à en comprendre le fonctionnement en travaillant sur les API. Le numérique demeure une structure client-serveur. « Si votre application passe par le web, la richesse de vos données ne sera perçue que dans la richesse des messages que votre serveur renverra au client. Vous pouvez avoir des données très riches, mais si elles ne renvoient rien, elles ne valent rien. »

Dans les contenus, comme dans l’échange des données, le contenu doit être intelligent. « Le message est l’interface ». La conception d’API amène les développeurs à s’intéresser à des formats de données formalisés, génériques et pas propres à telle ou telle entreprises. Or pour l’instant, chaque entreprise développe son API. Chaque développeur doit s’adapter à chacune. Il y a un besoin d’API génériques, avec des requêtes et des messages génériques… Et ils ne deviendront génériques que si les développeurs travaillent à la normalisation de leurs API, via RDF, le format du web des données, conclut Christian Fauré.

Bien sûr, l’intervention de Christian Fauré a fait puissamment réagir l’assemblée, qui depuis le matin se perdait dans les problématiques techniques et la complexité des formats des données ouvertes. Christian Fauré rappelait alors que son propos était de distinguer les choses plus que de les opposer. « Je suis un promoteur du web sémantique et je me demande pourquoi les gens ne l’utilisent pas. La question du time to market pour les développeurs est une réalité économique qu’il faut prendre en compte. »

Pour Simon Chignard, ce débat entre API et web sémantique laisse à penser que les seuls réutilisateurs de données sont des développeurs. « Mais personne d’autre que des développeurs ne savent faire ou utiliser une API, alors que tout le monde est capable de faire des données en CSV. Si on souhaite offrir un accès plus large aux données, nous ne devons pas ajouter de la complexité », recommande-t-il. Pour l’instant, les critères qui guident le choix de prendre une API reposent souvent sur le filtrage et la gestion des accès… « ce qui n’est pas un critère de grande ouverture, contrairement à l’Open Data, ouvert par nature ».

Le fait de choisir une démarche d’API ne rejette pas pour autant l’ouverture. « L’Open Data ne signifie pas non plus nécessairement Open Bar », rappelle Christian Fauré. Force est de constater que pour l’instant, les API proposent une plus grande richesse de modèles d’affaires et de catalogues. La stratégie d’API permet d’entrer dans une stratégie d’Open Data, non pas de manière politique, mais de manière pragmatique, quitte à ensuite évoluer. Certaines administrations publiques doivent avoir des stratégies d’API, comme les impôts, alors que les institutions culturelles iront plutôt privilégier une stratégie Open Data.

Dépasser l’Open Data ?

Derrière ce débat, technique certes, se dessine à mon sens une question et une réflexion sur le rôle des Open Data, la stratégie et la vision de l’avenir des services publics. L’Open Data est-elle une fin en soi ? C’est l’impression que donnaient les débats techniques de cette journée. Si l’enjeu est d’évoluer demain vers l’e-governement, l’administration électronique, on perçoit alors que la stratégie ne peut se limiter à la publication de données publiques, mais doit être toujours évolutive. L’Open Data comme seule perspective semble avoir un peu endormi l’administration électronique, au détriment d’une ambition d’e-government plus large, plus diverse.

Comme l’expliquait Alex Howard pour O’Reilly Radar en évoquant le lancement de Gov.uk en février 2012, le plus intéressant n’est pas le site du gouvernement britannique (même s’il est particulièrement réussi), mais la culture qu’il y a derrière. Un site ouvert, modulaire, doté de nombreuses API pour simplifier le web britannique. « Nous ne voulons pas éduquer les gens sur la façon d’utiliser un service, mais éduquer le gouvernement sur la façon de servir les citoyens », expliquait Francis Maude le responsable de cette politique.

Même chose côté Etats-Unis. Depuis la publication de la feuille de route vers le gouvernement numérique, l’administration de la Maison Blanche a inscrit dans les mesures d’avenir d’autres choses que l’Open Data et notamment la nécessité pour chaque agence fédérale de fournir des services web et des API. La stratégie eGov va bien au-delà de la seule ouverture des données, pour trouver des solutions pour optimiser le fonctionnement, les dépenses et les investissements des gouvernements via les Big Data et les web services.

A ne parler que d’Open Data, le risque n’est-il pas de ne parler que d’interopérabilité en oubliant d’introduire une vision qui permette de projeter les services publics vers une transformation plus étendue, comme le fait le projet britannique en proposant de transformer les services publics en ligne. La feuille de route américaine propose une vision pour l’avenir de l’administration centrée sur les API et les Big Data plus que l’Open Data. L’Open Data n’était qu’une première étape dans un projet d’évolution des services publics qui s’est depuis complexifié. Qui n’oublie pas non plus la participation et la cocréation avec les administrés…

Assurément, le gouvernement comme plateforme n’est pas qu’une plateforme technique. Elle nécessite une ambition, une vision. On a un peu l’impression qu’en France et en Europe, depuis l’ouverture du sujet Open Data, la vision s’est arrêtée en chemin. Et que ce cantonnement à l’ouverture des données publiques enferme cette politique sur elle-même. Il est temps d’aller plus loin !

Hubert Guillaud

Retrouvez le dossier sur l’Open Data week 2013 :

• 1e partie : la technique a-t-elle pris le pas ?
• 2e partie : dépasser l’Open Data ?
• 3e partie : Et les gens ?