Données ouvertes et données utiles

Les derniers à résister à l'ouverture des données sont en général les premiers à en attendre des "résultats concrets". Ceux qui subissent l'Open Data demandent immédiatement : où sont les multiples applications innovantes développées à peu de frais pour l'entreprise ou la collectivité ? quel est le modèle économique ? ces données ouvertes ont elles une utilité économique ? 

Voici quelques pistes pour évaluer et si possible augmenter l'utilité des données ouvertes.

Savoir ce que vous en attendez
Il n'y a pas de vent favorable pour le bateau qui ne sait pas où il va. L'ouverture des données peut servir plusieurs objectifs : assurer la conformité réglementaire, améliorer l'image de votre organisation, catalyser la co-création d'apps ou de services, informer vos clients ou vos administrés, focaliser vos ressources sur vos missions essentielles, servir la stratégie de plateforme de votre organisation, attirer des partenaires...
Toutes les données ne sont pas bonnes à ouvrir, une ouverture subie ou mal maîtrisée peut menacer vos revenus ou augmenter les risques de désintermédiations. Il est nécessaire de choisir les données ouvertes, les modalités d'ouverture : licences, documentation, API ou fichiers, fréquences de mise à jour, volume et représentativité des données ouvertes... en fonction de vos objectifs et de proportionner vos attentes aux moyens mis en oeuvre.

Soigner l'animation
Il ne suffit en général pas d'ouvrir des données (ou quoique ce soit) pour que les ré-utilisateurs (les clients) se pressent au portillon.
L'animation des communautés visées, la prise en compte des remarques éventuelles sur la qualité de vos données, l'animation interne et externe, la documentation, le cas échéant des exemples d'utilisation... sont des ingrédients importants du succès. Les hackathons et autres concours sont des temps forts et visibles, mais l'écoute et l'appui au quotidien sont indispensables comme l'expliquait le MassDOT dès 2009.


Prendre en compte les effets internes
L'ouverture des données est rarement "neutre" du point de vue des processus et des outils de production habituels de l'entreprise ou de la collectivité. Il est rare, par exemple, que le processus d'ouverture ne soit pas l'occasion d'améliorer la ré-utilisation en interne. L'ouverture est naturellement un moyen efficace de développer la culture des données dans l'organisation. Ces gains de productivité ou de qualité, dans la durée, peuvent être significatifs.

Evaluer sur un temps long (12 mois au moins)
L'utilité de l'open data ne s'apprécie pas dans les jours qui suivent l'ouverture des données et elle n'est pas automatique. Il faut un temps pour que la "communauté" repère les données, se les approprie, puis commence à les utiliser. Il faut encore un peu de temps pour certaines réalisations deviennent visibles.
En outre, une large part de l'utilité est conditionnée par le développement de nouvelles coopérations entre l'entreprise ou la collectivité "ouvrant" et les "communautés" réutilisant. Les conséquences de ces nouvelles coopérations et les bénéfices internes qui en découlent, sont perçus lorsque l'organisation s'adapte. Or le temps de la transformation, en particulier dans les grandes structures, est un temps long.

Ratisser suffisamment large
L'utilité des données ouverte est liée à la force de la communauté qui va s'en saisir. Pour mobiliser et développer une communauté importante vous pouvez utiliser les réseaux sociaux et faire de la pub mais mieux vaut proposer une offre excellente et  à "large bande".
  1. Une stabilité sur une bande de temps large. Le temps que les ré-utilisateurs vont consacrer à vos données est précieux. Il est nécessaire de sécuriser leurs investissements en garantissant une certaine stabilité dans la publication des données (fréquences, format, qualité...). Cette stabilité attendue par ceux qui ont déjà développé leurs applications s'oppose parfois aux demandes d'évolutions et d'innovations venant de ceux qui n'ont pas encore la matière première suffisante pour développer la leur... Tout est donc question de mesure ! Les évolutions importantes voir la fermeture d'une API doivent être annoncées longtemps à l'avance pour permettre aux développeurs d'anticiper et garder leur confiance.
  2. Un niveau de service (et de prix) à large bande. Malheureusement il y a peu de miracles, les ré-utilisateurs doivent trouver des clients pour pouvoir vivre et faire vivre leurs applications... Il faut le comprendre et les aider via une offre adaptée aux besoins des clients des ré-utilisateurs ! Si pour certains la gratuité de l'accès est une condition sine qua none, pour d'autres, la qualité du service, sa tenue à la charge peuvent être des exigences fortes pour lesquelles un contrat avec Service Level Agreement payant sera nécessaire.  
  3. Des données à large couverture. La force de la communauté est directement liée à la couverture de données. On salue l'initiative de Thierry Verdier qui a développé Ma ligne C sous Windows 8, sur les seules données du RER C ouvertes par Transilien en 2012, mais il faut attendre une ouverture plus large de données pour mobiliser plus d'utilisateurs potentiels, et plus de développeurs. A l'inverse, JCDecaux, a ouvert, certes tardivement, mais dans une vingtaine de métropoles d'un coup ! Voilà une zone de chalandise intéressante parce qu'elle est suffisamment large. 
Designez vos API
Les promoteurs de l'open data au sens strict privilégient la mise à disposition  de "données brutes" sur l'ouverture d'API. En pratique, néanmoins, certaines données sont plus "utiles" si elles le sont sous forme d'API. Dans le domaine du transport, par exemple, l'ouverture des données "temps réel" passe par la mise à disposition d'API. L'ouverture des données théoriques peut être faites via des fichiers statiques (typiquement au format GTFS), mais les complexités métiers de ces données, font que certains développeurs préféreront  utiliser des API comme celles proposées par Transilien ou celles de navivitia.io (une initiative intéressante qui mériterait d'ailleurs un article dédié).
Les API présentent aussi le mérite, du point de vue de l'organisation qui ouvre, de constituer un lien pérenne avec les communautés ré-utilisatrices.
Les API sont certes des objets techniques, mais les considérations de design sont extrêmement importantes. Des API bien conçues seront découvertes, comprises et utilisées aisément par les développeurs. Elles doivent être à la fois simples pour être faciles à utiliser, mais suffisamment flexibles pour ne pas contraindre les développeurs quelques soient leurs objectifs applicatifs.
Twitter, par exemple, propose trois niveaux d'API avec des rapports complexité/flexibilité différents.
D'une part des API très simples permettant de "citer un tweet" ou une Timeline.
Cette API est très simple, mais elle ne permet pas d'accéder aux données détaillées du tweet (par exemple les caractéristiques du compte de l'auteur). L'API rest le permet, mais son utilisation est un peu plus complexe. Enfin pour ceux qui seraient tentés d'analyser non pas un tweet, mais véritablement un flux de tweets à la volée, l'API streaming est nécessaire. L'ensemble de ces API est naturellement copieusement documenté et commenté sur le site de Twitter mais aussi sur diverses autres ressources techniques.
Des entreprises se spécialisent dans l'assistance à la conception d'API. Apigee, qui en fait partie, propose de  nombreuses présentations sur le sujet.

Cet article fait partie d'une série "post open data" introduite par Open data dans les transports en Île de France : et après ?
Thèmes:

Aucun commentaire:

Enregistrer un commentaire

Inscription à : Publier les commentaires (Atom)