3 ateliers pour jouer avec les données ouvertes

En passant

3 ateliers pour jouer avec les données ouvertes !

Dans le cadre de Viva-Cités à Rennes, j’organise du 2 au 7 octobre prochain trois ateliers Infolab pour découvrir les données ouvertes et imaginer des réutilisations. L’open data, ce n’est pas (seulement) pour les développeurs ! Inscription gratuite et recommandée en ligne.

Les conflits liés aux données « fermées » se multiplient

La Deutsche Bahn ne veut pas ouvrir ses données ? OpenPlanB s’en charge …

Le récent conflit qui oppose le site FourmiSanté et l’Assurance Maladie (1) vient s’ajouter à une longue liste de confrontations liées à des données « fermées ». Partout en Europe, nous assistons à la multiplication de cas similaires.

Comment peut-on analyser ces conflits ? L’open data peut-il être une réponse aux défis qu’ils posent ?

En Allemagne le groupe de data hacktivists Open Plan B vient de publier les données de la Deutsche Bahn, en réponse expliquent-ils à l’immobilisme du transporteur en matière d’open data. En Suisse, c’est le site fédéral permettant de calculer le montant des primes d’assurance maladie qui a lui aussi fait la une de l’actualité, un député réclamant récemment l’ouverture des données fédérales. En Belgique, le groupe de développeurs iRail.be propose une interface non-officielle d’accès aux données de la compagnie ferroviaire nationale, … On voit donc que cette question n’est pas spécifique à la France. 

1 – A l’origine, la multiplication des services en ligne

La réutilisation non-autorisée de données n’est pas une invention de l’ère Internet. Qui se souvient par exemple du 36 17 ANNU, le premier annuaire inversé sur Minitel qui a fait la fortune du tycoon français Xavier Niel ? Les numéros des abonnés étaient récupérés à partir de l’annuaire 36 11 proposé par France Telecom, en veillant à ne pas dépasser la limite fatidique des 3 minutes, au-delà desquelles le service devenait payant. Une pratique qui a d’ailleurs valu à cet éditeur l’une des plus lourdes condamnations jamais prononcées en matière de bases de données en France (pour mémoire, 100 millions de francs et une astreinte de 4 millions supplémentaires par jour).

Aujourd’hui ce ne sont pas seulement la liste des abonnés au téléphone que l’on peut retrouver sur Internet, mais la plupart des services et administrations publics : localisation et horaires des équipements, informations détaillées sur les transports et leur qualité, données sur la qualité des établissements hospitaliers ou sur les tarifs pratiqués par les médecins, … Ce qui demandait, à l’époque du Minitel, une batterie de serveurs, est aujourd’hui accessible à n’importe quel individu un peu motivé et équipé. La « barrière à l’entrée » pour la collecte non-autorisée de données s’est donc très largement abaissée.

Ajoutons aussi que le travail de collecte est aussi largement facilité par le fait que nombre d’administrations et d’entreprises ont recours aux mêmes prestataires et aux mêmes systèmes pour mettre en ligne leurs données. C’est l’exemple du calculateur d’itinéraires développé en Allemagne par la société Hafas et largement utilisée par de très nombreux réseaux de transport en Europe et aux Etats-Unis. Une fois que l’accès au système Hafas via des API devient documenté pour une ville, il le devient rapidement pour toutes

2 – En face, la réutilisation non-autorisée se professionnalise

L’histoire se déroule souvent de cette manière : une entreprise (ou une administration) découvre un jour qu’une application non-officielle a fait son apparition sur l’AppStore. Parfois – trop souvent -, on s’aperçoit aussi que le dit-développeur avait d’ailleurs fait auparavant une demande officielle d’accès à ces données mais que, ne sachant pas quelle position adopter, on ne lui a pas répondu. Face au « fait accompli« , la première réaction est de mettre en route la machine juridique : mise en demeure, demande du retrait de l’application ou du service en ligne, …

La suite a un air de déjà-vu : le développeur un peu malin médiatise le conflit et interpelle les pouvoirs publics. D’ailleurs cela marche souvent et le changement de champ de bataille (du juridique au moral) tourne rarement à l’avantage de celui qui voit ses données utilisées sans son accord : les élus s’en mêlent, écrivent des lettres ouvertes comme à New-York en 2009 (le fait déclencheur de l’open data du transporteur new-yorkais) ou à Lyon plus récemment.

Le conflit est alors plutôt de type asymétrique : le détenteur des données a le sentiment d’avoir le droit de son côté (n’a-t-il d’ailleurs pas pris le soin de détailler des conditions d’utilisation sur son site web ?), mais le réutilisateur a les « cartes médiatiques » en main, et le moment « open data » (déjà évoqué dans un précédent billet) joue à plein. L’incompréhension est totale.

Mais il y a mieux que les applications non-officielles. J’ai cité plus haut l’exemple de Open Plan B en Allemagne, on peut aussi citer aussi la kyrielle d’API (interfaces de programmation) non-officielles qui se multiplient, à Montpellier, en Suisse, en Belgique. Ceux qui développent ces outils font en quelque sorte le boulot que les détenteurs de données ne veulent pas faire. En voulant contrôler leurs données, ils encouragent l’émergence de tels services et in fine, abandonnent encore davantage leur capacité à maîtriser l’usage qui en est fait.

3 – L’open data : ouvrir pour fournir un cadre à la réutilisation

Personne n’a intérêt à la réutilisation non-autorisée des données, même pas le développeur. En procédant hors d’un cadre technique et juridique clair, il doit faire face à une incertitude juridique qui freine aussi sûrement l’innovation que les redevances tarifaires. A Londres, c’est l’exemple de ce développeur d’une application très populaire qui a découvert un matin que son service ne fonctionnait plus : le site web de l’opérateur Transport for London (TfL) avait modifié la structure de ses pages web sans avertir personne, …

Le détenteur de données a lui aussi intérêt à préciser le cadre juridique, technique et économique de réutilisation des données. Les mises en demeures, les demandes de retrait d’application : cela fonctionne peut-être dans un premier temps (en témoigne la prudence affichée par les réutilisateurs concernés) mais in fine cela ne saurait constituer une politique en matière de diffusion et de valorisation des données.

Hier la RATP, aujourd’hui l’assurance maladie ou certains opérateurs ferroviaires européens : si vos données ne sont pas encore réutilisées sans votre accord, vous savez ce qu’il vous reste à faire : commencer à réfléchir sérieusement à votre politique open data

(1) : Il s’agit dans le cas présent de la réutilisation non-autorisée des tarifs des médecins publiés sur le site ameli-direct.

Oups, on a fait un infolab

A l’occasion du Forum des Usages coopératifs de l’Internet à Brest, j’ai eu le plaisir de co-animer une session consacrée à la fabrique des données avec Loïc Hay de La Fonderie (agence numérique d’Ile-de-France) et la Fondation Internet nouvelle génération. Ce billet retrace cette expérience pratique de mise en place d’un infolab, dans un temps et un lieu déterminé.

De droite à gauche : Denis Pansu (Fing), Loïc Haÿ (La Fonderie) et moi – crédit photo La Fonderie

1 – La fabrique des données

La fabrique des données propose d’illustrer une démarche de réutilisation de données ouvertes. De la recherche de la matière première, jusqu’à la réalisation de quelques infovisualisations, cet atelier combine dans un format court (2h30) une approche critique (d’où viennent les données ?) et pratique (comment les représenter ?).

2 – Le thème retenu : les prénoms

Nous avons retenu la thématique des prénoms pour ce premier atelier. Le prénom présente plusieurs avantages :
– d’abord on en a tous un ! (voire deux, trois ou quatre). Chacun peut se sentir concerné par cette thématique, a fortiori s’il a des enfants et s’est donc déjà retrouvé en position de choisir un prénom,
– ensuite, la matière première est disponible : les jeux concernant les prénoms les plus populaires sont disponibles sur les portails open data de Paris, Nantes et Rennes. Plutôt que de râler contre la non-disponibilité des données, utilisons celles qui sont déjà proposées !
– les jeux de données sont faciles à appréhender et à comprendre. Nul besoin de savoir développer une application mobile ou d’être un expert de la comptabilité publique pour s’en saisir.

Nous nous sommes ensuite appuyé sur une actualité de ce début juillet : la publication par Baptiste Coulmont (sociologue et auteur de « Sociologie des prénoms » aux éditions La Découverte) d’une étude sur les prénoms des candidats au bac ayant reçu la mention très bien. Elle révele des succès très différents pour les Eleonore et les Jessica, les Augustin et les Kevin.

Prénoms et mentions TB au bac par Baptiste Coulmont (source coulmont.com/blog)

La représentation graphique fait réagir la salle, et elle est surtout pour nous l’occasion de souligner la confusion fréquente entre corrélation et causalité – ce n’est pas le prénom qui détermine le résultat au bac (contrairement à ce que laissent penser nombre d’articles de presse qui ont repris l’information) !

Le prénom est un marqueur d’un milieu social ou d’une région. Ainsi, Loïc explique qu’on lui demande souvent quelles sont ses racines bretonnes (réponse : aucune). Bref le prénom laisse imaginer – à tort ou à raison – beaucoup de choses sur celui qui le porte … et sur celui qui le donne (voire sur celui qui le juge).

3 – D’abord, apprendre à lire les données

Après cette introduction sur les prénoms, j’aborde le « tronçon commun » de tous les ateliers que j’anime, c’est-à-dire une courte séquence pour expliquer la différence entre une donnée et une information, une donnée publique et une donnée ouverte… Donner des bases de compréhension me semble plus que jamais indispensable et c’est en tout cas un pré-requis avant de pénétrer dans la fabrique des données.

Nous proposons ensuite aux participants de découvrir les jeux de données disponibles sur les portails open data de Paris, Nantes et Rennes. Chacun est invité à suivre les liens à partir de son propre ordinateur. J’ai volontairement fourni l’adresse des pages descriptives des jeux de données (et non le lien de téléchargement) or la majorité de nos participants commencent d’abord par télécharger le fichier lui-même… Comment ce fichier a-t-il été constitué ? Que comprend-t-il ? Que nous raconte-t-il ? Quelle est la licence  juridique applicable ? On ne peut répondre à aucune de ces questions sans consulter la notice de chaque jeu de données – c’est une démonstration « par l’exemple » et une première illustration de l’importance des métadonnées.

crédit photo La Fonderie

Une dizaine de minutes sont consacrées à une lecture critique et comparée des trois jeux de données. Les participants notent ainsi que les stratégies de diffusion ne sont pas les mêmes selon les villes. Paris ne distingue pas les filles des garçons pour les naissances intervenues avant 2011 – Camille par exemple est un prénom populaire dans la capitale. Rennes et Paris proposent un fichier consolidé pour plusieurs années, alors que Nantes a scindé chaque année dans un fichier spécifique – un moyen pas bien méchant mais pas discret non plus de « gonfler » artificiellement le nombre de jeux de données disponibles…

On constate aussi que d’une manière générale les prénoms les plus populaires – ceux qui figurent dans le top10 – sont souvent les mêmes dans les 3 villes : Emma, Manon, Matthis, …

Les participants remarquent aussi, sur les portails de Rennes et Nantes, la mention d’une soi-disant recommandation de la CNIL sur les prénoms ayant été donnés moins de 6 fois au cours de l’année considérée (nous reviendrons dans un prochain billet sur cette « recommandation »… l’histoire vaut vraiment le détour !). Cela signifie en pratique que les fichiers ne comportent pas tous les prénoms donnés afin de respecter la vie privée des individus. Cela nous amène à évoquer rapidement les problématiques d’anonymisation à partir des données personnelles.

Ayant bien fait le tour de notre matière première, de ses atouts mais aussi de ses limites, je passe la main à Loïc Haÿ pour la suite de l’atelier. Maintenant que nous savons « lire » les données, on passe au niveau supérieur : l’écriture.

4 – Ensuite, apprendre à écrire

Loïc montre tout d’abord deux exemples de visualisations que l’on peut réaliser facilement : des « nuages de tag » reprenant les 150 prénoms les plus populaires à Rennes et Nantes pour l’année 2008. Il explique ensuite comment les réaliser à partir du site wordle.net.

« La Dataviz de la dataviz » par WeDoData pour Expoviz – La Fonderie

La Fonderie, agence numérique Ile de France est à l’origine de l’exposition Expoviz consacrée à la visualisation de données. A cette occasion, l’agence WeDoData a réalisé le poster « La Dataviz de la dataviz » que Loïc nous détaille. Il insiste notamment sur la grande diversité des modes de représentation possibles des données (dont la photovisualisation). La parole est ensuite donnée à la salle : et vous, comment aimeriez-vous représenter les données concernant les prénoms ?

Léa Lacroix explique le travail qu’elle a réalisée pour son site LesPtitsRennais, on évoque l’idée d’une photographie de petites Emma, Manon et Louise sur les marches d’un escalier, pour illustrer le classement qui change d’une année sur l’autre. L’idée de classement revient souvent et nous cherchons donc de l’inspiration du côté des résultats sportifs… Un participant nous fait à juste titre remarquer que l’on devrait d’abord définir ce que l’on cherche à montrer – avant de chercher le bon outil pour le faire !

Loïc présente différents outils de représentation de données dont Many Eyes. Certains sont accessibles au plus grand nombre, d’autres réclament plus de temps pour les maîtriser.

5 – Oups, on a fait un infolab !

Revenons maintenant sur le titre de ce billet, « oups, on a fait un infolab« . Le concept d’infolab a connu récemment un regain d’intérêt suite à l’article d’Internet Actu « Avons-nous besoin d’infolabs ?« , article qui reprend les réflexions en cours à la Fondation Internet nouvelle génération sur les modes d’appropriation des données. Notre atelier brestois s’est d’ailleurs conclu par une intervention de Denis Pansu de la FING sur ce propos.

On sent bien que la problématique de l’animation autour de l’open data, de son accès à un public plus large que les seuls développeurs suscite de nombreuses réflexions – le sujet était d’ailleurs central lors de la semaine européenne de l’open data. La Fonderie avec Expoviz, ou moi-même avec les ateliers autour des données de mobilité, nous expérimentons de nouveaux formats d’animation et de transmission…

Initialement une blague partagée avec Loïc, le titre de ce billet traduit aussi une conviction : ce dont nous avons avant tout besoin ce sont des médiateurs motivés (et si possible compétents)… qu’ils travaillent ou pas dans un « infolab ».

Les 3 leçons de l’ouverture des données de la RATP

C’était incontestablement l’actualité open data de l’été : la régie des transports parisiens a fait un premier pas en ouvrant quelques jeux de données. Au-delà du buzz généré par cette annonce, retour sur les leçons de l’ouverture des données façon RATP. Des leçons qui ne s’adressent pas uniquement au domaine de la mobilité … 

1 – L’ouverture des données est-elle inéluctable ?

L’open data et la RATP c’était déjà toute une histoire. Pour fédérer un mouvement, rien de tel que de se donner un ennemi commun, et il faut bien avouer que la régie a tout fait pour tenir au mieux le rôle du méchant. La très médiatisée affaire qui a opposé l’an dernier l’éditeur de l’application CheckMyMetro et la RATP en est le point de départ, le « moment » open data a fait le reste.

Je parle de « moment » parce qu’objectivement la situation était plus complexe que la fable de David contre Goliath. Le débat s’est dans un premier temps concentré sur l’usage non-autorisé du plan de métro parisien par la start-up. Or un plan c’est un document, pas une donnée. Evoquer l’open data dans ce cas, c’est tout à fait abusif. La CADA, qui avait été sollicitée pour rendre son avis a d’ailleurs très clairement précisé que le plan est le fruit d’une création intellectuelle et qu’il ne rentre donc pas dans le champ de la donnée publique.

La loi CADA de 1978 exonère d’ailleurs clairement certains établissements, dont la RATP, de certaines obligations en matière de réutilisation des données publiques. Précisons enfin que l’application CheckMyMetro permet à ses utilisateurs de signaler les contrôleurs. Une telle fonction, de nature à encourager la fraude, n’aide bien entendu pas à apaiser les relations !

Sur le papier donc, et si l’on se reporte aux textes juridiques, il n’y avait pas de raison que la RATP publie des données en open data. Elle n’y était pas obligée.

La première leçon de cette histoire, c’est la combinaison d’une maladresse initiale (la gestion du conflit), du « moment » open data et d’un emballement médiatique généralisé, renforcé par les prises de position répétées de l’ancien président du Conseil national du numérique.

Ce que la loi n’exigeait pas est devenu une obligation quasi-morale. Bref, à bien des points de vue, la RATP se trouvait alors dans une position défensive – et je suis prêt à parier que d’autres prendront bientôt la place de la régie dans cette position plutôt inconfortable (JC Decaux ?).

2 – Valoriser sa marque ou limiter l’usage sauvage des données ?

Comment dès lors passer d’une position défensive à une position offensive ? J’ai décrit dans un billet précédent 9 stratégies de diffusion des données. La RATP me semble une très bonne illustration des mouvements possibles pour passer d’une position défensive à une position offensive. Le premier problème à résoudre était celui de la réutilisation non-autorisée de son plan de métro et des éléments graphiques s’y référant. Le second était lié à l’utilisation sauvage des données horaires, récupérées à partir de son site Wap.

La RATP vient de résoudre la première question, en permettant un usage bien encadré de certains éléments graphiques – dont le fameux plan. « Volte-face » a écrit l’éditeur de CheckMyMetro dans une communiqué de presse à la tonalité victorieuse (poursuivant ainsi la fable de David contre Goliath).

J’y vois plutôt un mouvement habile de la part de la régie pour protéger et valoriser sa marque. On peut par exemple lire dans les conditions d’utilisation que seule la RATP peut utiliser le logo vert comme icône d’application mobile. En ce sens, on se rapproche davantage du programme « Don’t pretend to be us » des transports londoniens.

Force est de reconnaître que sur le deuxième sujet, celui des données, rien n’est acquis. Les jeux de données aujourd’hui publiés sur Etalab ne brillent pas par leur extraordinaire richesse. On est encore loin de ce que d’autres réseaux en France (Rennes, Nantes, Toulouse, …) ou ailleurs (New-York, San Francisco, Londres) ont pu proposer. La prochaine étape sera de passer des intentions aux actes, notamment en proposant des API sur un vrai site dédié, et non quelques fichiers sur le portail gouvernemental. Mais la régie aura au moins su faire baisser la pression médiatique sur le sujet… et c’est déjà beaucoup !

3 – Qui doit gérer l’ouverture des données « publiques » ?

Le premier pas de la RATP marque aussi une tendance : ce sont de plus en plus les exploitants de services – et non les administrations et autorités organisatrices – qui gèrent l’ouverture des données. En région Ile-de-France, cela est particulièrement flagrant : Transilien et la régie se sont lancés dans l’open data bien avant le STIF, pourtant l’autorité qui organise les transports sur ce territoire.

Cette troisième et dernière leçon ne concerne pas uniquement le domaine de la mobilité mais s’adresse à tous ceux qui gèrent des délégations de service public, pour l’eau, l’énergie ou les déchets. Cette mission d’ouverture (et le travail d’animation qui va de pair) va-t-elle peu à peu être intégrée dans de futurs appels d’offres ?