Bonnes pratiques du code dans le cycle de vie des données

Posted on

Devrions-nous considérer les données comme du code informatique ? Devrions-nous leur appliquer une gestion similaire ? Je me suis posé ces questions récemment souhaitant appliquer les mêmes bonnes pratiques à des données qu’à mon code, à savoir :

  • Historisation des modifications, et son corrolaire, réversibilité des changements
  • Annotation des modifications
  • Concurrence d’accès et de modifications
  • Identification d’une suite de changements

La phrase bien connue “Data is code” (les données sont du code informatique) offre un raccourci assez grossier mais intéressant à ce sujet. Si l’on peut considérer la donnée comme du code, pourquoi ne pas lui appliquer les mêmes pratiques ?

Journal des modifications, aka changelog

Une donnée est un fait, c’est la racine même du mot, si un changement s’opère sur celle-ci et qu’un nouveau fait en résulte, il peut sembler pertinent de tracer alors les raisons et les mécanismes de cette évolution.

Prenons un exemple. Je travail avec les informations du SIG de Rennes metropole concernant les données géographiques du réseau de transport en commun de Keolis sur la métropole. Les données fournies représentent un fait, celui de l’empreinte du réseau à l’instant de la création du jeu. Il est évident que l’information décrite par ces données évolue, amenant le SIG à publier des mises à jours.

Or, la publication ne s’accompagne pas d’explication sur ce qui a changé, ni pour quelles raisons. Je crois que c’est dommageable dans le sens où l’utilisateur doit alors faire la comparaison entre deux versions pour tenter de déterminer, a minima, l’étendu des modifications.

Notons ici que je ne pointe pas du doigt le SIG qui propose des données structurées et très faciles de réutilisation. Ce constant s’applique à tous les jeux de données que j’ai pu voir sur Rennes ou ailleurs.

Pourquoi est-ce un problème ? Mon utilisation des données du SIG est essentiellement programmatique. Après un téléchargement d’un jeu de données, je le stocke dans une base de données relationnelle pour les manipuler via le langage programmatique SQL. Si une donnée change, elle peut avoir un effet important sur le résultat de mes requêtes. Parfois un changement est attendu (une correction apportée par le SIG), parfois il peut casser mon applicatif et ne peut donc pas être utiliser sans travail supplémentaire. Si le SIG exprimait avec précision les modifications apportées dans une mise à jour, il me serait aisé de savoir si oui ou non je dois la récupérer et ce à quoi je dois porter attention. Il s’agit d’un gain de temps non négligeable mais aussi une sécurité dans mon process de développement.

Revenons à la notion de “Data is code“. En tant que développeur, la bonne pratique est de fournir ce que l’on nomme un changelog qui se traduit littéralement par “journal des modifications“. Dans la pratique, il s’agit généralement d’un fichier texte ou d’une page HTML avec une structure simple :

Voir, par exemple, celui-du logiciel Jenkins.

Ce format à la double propriété d’historiser les changements et d’offrir une vue rapide et efficace des modifications apportées lors d’une publication.

Un changelog peut aussi être accompagné de notes de livraison plus poussées qui offrent le raisonnement derrière les changements ainsi que le cheminement à suivre pour mettre à jour. Un bel exemple de telles notes peut se trouver dans le projet Django. Même sans connaitre le projet, on peut apprécier la richesse du document produit.

Un peu pour l’humain, un peu pour la machine

Bien qu’un changelog soit utile, il n’est pas suffisant pour une automatisation du cycle de vie des modifications. Dit autrement, le changelog vise l’humain mais pas la machine. De part son format peu structuré et basé sur le langage naturel, il n’est pas propice à une automatisation. Il manque une pièce au puzzle.

C’est là où entre en jeu les systèmes de gestion de versions. Sans entrer dans les détails, ces systèmes permettent de répondre aux exigences de développement logicielles mentionnées plus haut. Subversion, git et mecurial sont les plus connues dans le logiciel libre. Grâce à ces outils, un développeur peut ainsi effectuer des modifications locales puis les enregistrer et, potentiellement, les mettre à disposition. En interne, le logiciel conserve des meta-informations telles que la date de l’enregistrement, le nom du développeur, la raison de l’enregistrement, etc. Mais surtout, il n’enregistre que la variation entre la version précédente et la nouvelle. Un enregistrement s’appelle généralement une révision ou un changeset (lot de modifications).

L’intérêt ici, hormis la bonne pratique logicielle, est de pouvoir automatiser certaines tâches, en tant que réutilisateur, en s’appuyant sur ces outils pour reconstruire n’importe quelle état depuis une version donnée. Simplement en appliquant chaque lots de modifications les uns après les autres.

Cela peut se révéler très utile dans le cadre de la consommation de données. En effet, prenons un simple fichier au format CSV par exemple. Il serait très facile de voir les différences d’une version à l’autre simplement en parcourant le journal des modifications proposés par l’outil. Mais aussi de simplifier les tâches de mise à jour puisqu’on pourrait utiliser l’outil pour récupérer uniquement les différences depuis la dernière publication.

Prenons ainsi le fichier représentant la France au format GeoJSON et disponible sur la plateforme github. On peut inspecter l’historique de cette ressource ainsi qu’un changement en particulier.

Un autre effet intéressant des outils de gestion de versions est qu’il très facile pour un réutilisateur de faire sa propre modification et de la proposer au producteur qui peut ainsi la rejetter ou l’intégrer de manière naturelle et formalisée. Grâce à aux plateformes telles que github, il est aussi aisé d’annoter un changement pour le discuter.

Comment y parvenir ?

Les apports des changelogs et de la gestion de version sont indéniables dans le monde du logiciel, libre notamment. Si on part du principe que la donnée numérique possède des propriétés proches du code informatique, on peut s’attendre à utiliser les mêmes outils et bonnes pratiques. Mais cela requiert une évolution du travail des agents publics ainsi que de la plateforme hébergeant leurs données.

Malheureusement, le second aspect requiert de la formation,une feuille de route et du budget. En ces temps de crise économique, l’Open Data est-il une prioriété de la collectivité ou de l’état ? Rien n’est moin sûr.

En revanche, la création d’un changelog simple et mis à disposition sur les portails ne demandent pas beaucoup d’effort, puisqu’il s’agit pour les agents de lister au fur et à mesure les modifications qu’ils apportent ainsi que les raisons de ces changements dans un fichier texte.

Espérons donc que les mentalités et méthodes de travail évoluent chez les producteurs de données. Il me semble que cela est nécessaire pour rendre l’usage de leurs données plus naturelles et efficaces par les réutilisateurs. Cela enrichirait aussi le dialogue entre réutilisateurs d’une donnée.


Nouveau départ pour l’Open Data à Rennes Métropole ?

Posted on

Cela n’aura échappé à personne : nous sortons des élections municipales avec des changements de maires pour certaines municipalités de Rennes métropole. Concernant Rennes même, l’équipe semble être dans la continuité de la précédente, et il nous faut désormais attendre le changement de pilotage de la métropole courant avril.

De tous ces mouvements, qu’est-ce que l’open-data peut attendre ?

Un peu d’histoire…

Même si les avis divergent sur le vrai point de départ de l’open-data à Rennes, il semblerait que tout se soit passé début 2010. Si l’on regarde du côté des anglo-saxons, nous n’étions alors pas en retard, plutôt le contraire. Comme quoi, Rennes peut effectivement sentir un mouvement innovant et y investir sans tergiverser : bravo à l’équipe qui a porté le projet à l’époque !

Au printemps 2010, Rennes sortait son portail de données ouvertes et, dans le même temps, Keolis (la société ayant la délégation de service concernant les transports en commun de Rennes métropole) sortait aussi son portail. À l’automne de la même année, la métropole lançait son concours d’applications et organisait une conférence internationale autour du sujet des données publiques.

Bref, en l’espace d’une année, Rennes métropole installait l’open-data dans le paysage de la démocratie locale, tout en se positionnant sur le terrain de l’innovation numérique et sociale et, par la même occasion, lançait l’open-data en France.

Le concours passé, une deuxième phase s’installa : celle de la discussion entre Rennes métropole et les développeurs d’applications. Cette étape fut riche en rencontres et discussions. Néanmoins, force est de constater que la production, en termes d’applications concrètes et pertinentes pour les usagers, n’a pas été au rendez-vous.

Finalement, c’est en 2012 (un an plus tard) que le collectif Open-Data Rennes a été créé sous l’impulsion de Léa avec pour objectif de fédérer la communauté de réutilisateurs de données et de tenter d’animer le territoire autour de l’open-data.

Où en sommes-nous ?

Quatre ans plus tard, où en sommes-nous sur le sujet de l’open-data à Rennes métropole ? Objectivement, pas beaucoup plus loin qu’en fin 2011. Le mouvement rennais s’est graduellement calmé pour finalement pratiquement s’arrêter. Question légitime : pourquoi ?

S’il serait malheureux de pointer telle ou telle direction pour redémarrer, tentons d’abord de brosser un portrait lucide du mouvement.

Une politique publique nationale longue à décanter

Etalab, la mission gouvernementale chargée de l’ouverture des données publiques à l’échelon national, a vu le jour en 2011, un délai raisonnable. Mais, dans un premier temps, il s’agissait surtout de poser cette première pierre fondatrice de l’open-data à un niveau étatique. Le vrai travail de fond d’Etalab a pris encore deux ans, avec la nouvelle mouture du portail, plus riche et plus fonctionnel ; ainsi qu’avec le traitement de sujets plus complexes et sensibles, comme ceux de la santé.

Pendant le même temps, un ensemble d’acteurs territoriaux se sont associés afin de mutualiser les discours et coordonner les efforts. Ils ont officialisé leur statuts en 2013 au sein de l’association Open Data France. A priori, cet effort n’est pas là pour créer un rapport de force avec la mission Etalab, mais plutôt pour la compléter par un retour local mieux organisé.

Ces structures sont fondatrices et structurantes mais, dans la temporalité de l’Internet et du numérique, elles ont été longues à décanter, et leur apport concret n’est pas toujours évident à mesurer.

Surprise (ou non ?), ces structures reproduisent le schéma administratif classique : un échelon national, des échelons locaux, et une certaine opacité. On assiste encore à une approche centralisée, où l’administration ne s’appuie pas sur les citoyens mais continue de rester dans son entre-soi.

Pour l’exemple, il suffit de regarder la liste des membres d’Open Data France : seuls LiberTIC et la Fing représentent la société civile, mais sans droit d’éligibilité au CA.

Soyons positifs malgré tout : la coordination de la mission Etalab avec les collectivités territoriales est essentielle à la construction d’une politique d’ouverture des données publiques réussie ; et la démarche de concertation faite sur le terrain avec les acteurs de l’open-data français, à l’occasion de la refonte du portail data.gouv.fr a été très appréciée – le résultat n’est d’ailleurs pas décevant !

Une politique locale brouillonne et sans moyens

Rennes métropole soutient l’open-data depuis début 2010, et ne l’a jamais retiré de ses programmes. Malgré cela, il est difficile d’y voir clair dans la politique publique mise en œuvre. Alors que la métropole organisait des rencontres autour de différents sujets de l’open-data durant les deux premières années, les choses semblent stagner depuis : quelques sorties de données intéressantes (temps réel des transports en commun, agenda des événements culturels, etc.), mais il ne semble toujours pas exister de ligne précise quant au développement des données ouvertes, ou quant à un calendrier public sur lequel travailler.

Bref, quel est le canevas d’ouverture des données publiques de la métropole ? Nul ne semble vraiment le savoir, ou du moins, ce n’est pas une donnée publique. Autre question : quels sont les moyens mis en œuvre ?

À Rennes métropole, aucun poste n’a été semble-t-il créé pour s’occuper du rôle de data scientist (un urbaniste de la donnée pourrait-on dire). Ironiquement, le budget alloué à l’open-data n’apparaît pas dans les données budgétaires (ouvertes) de la métropole. Faute de moyens, les données culturelles sont liées à un partenariat avec Infolocale, où l’ouverture reste toujours la grande absente pour les réutilisateurs (et est-ce vraiment de l’open-data ?).

Alors que faire ?

Nous pouvons espérer que la nouvelle équipe saura comprendre l’importance de l’ouverture des données publiques et mettra les moyens derrière le discours. Aujourd’hui, le dossier open-data dépend de la communication et de l’événementiel (tout un symbole), plutôt que du développement territorial ou de la coordination générale des services – ce qui serait sans doute plus sa place. Les récentes élections seront peut-être l’occasion de changer cela ?

Une attente trop forte ?

Il existe plusieurs stimuli derrière l’ouverture des données publiques :

  • Démocratique : Ouvrir la porte sur l’information publique à la citoyenneté. Un objectif de transparence défendu, par exemple, par l’association Regards Citoyens et plusieurs partis politiques dans plusieurs villes aux dernières élections.
  • Économique : La donnée brute peut-être transformée et corrélée pour devenir information avec une valeur économique intéressante.
  • Juridico-légal : Moyen de contrôle de décision publique (une ZAC respecte-t-elle par exemple certains critères d’urbanisme ?)

Les attentes furent fortes et comme souvent, sur ce qui touche au numérique, la loupe que l’Internet pose sur un sujet peut parfois déformer la réalité. En l’occurrence, le discours de révolution opéré par l’ouverture des données était, au mieux optimiste, au pire totalement hors de proportion. La révolution n’est pas dans l’open-data. Il semblerait que le réveil ait été rude. L’open-data porte en lui tout ce qu’il faut pour devenir essentiel à l’économie ainsi que comme agent d’une démocratie moins crainte, mais le retour sur investissement ne sera peut-être pas aussi simple à détourer.

Par ailleurs, l’open-data ne reste qu’un moyen de communication : partout en France, les données ouvertes sont choisies avec soin. La création d’une politique volontariste visant à normaliser les jeux de données ou à travailler à plusieurs pour proposer des contenus de qualité égale entre producteurs n’est que très récente, en plus d’être rare. Cela serait pourtant le bon moyen pour tirer l’open-data administratif de son marasme actuel : “S’il n’y a pas de réutilisation, pourquoi ouvrir des données ?” entend-t-on dans les couloirs. Tout simplement parce que les données ne sont pas d’une qualité suffisante, unifiées ou d’un intérêt invitant à les exploiter ? L’initiative en cours autour des données culturelles de Rennes Métropole est très intéressante à suivre, car menée avec une politique volontariste, destinée à unifier les données ; et il faut encourager ces approches, qui apportent un changement positif aussi pour les agents du service public.

Une communauté segmentée

L’open-data, comme bien des mouvements liés au libre, est fortement porté par des acteurs de la société civile. Il ne s’agit pas toujours de militantisme, mais plutôt d’actes politiques, au sens originel “d’agir dans la vie de la société”.

Mais, peut-on parler d’une communauté ? Probablement pas. C’est une force mais aussi une limitation. Un atout car il n’existe pas de guerres intestines, pas de volonté de contrôle par une personne, avec un agenda personnel. Les mouvements citoyens sur le sujet sont donc plutôt constructeurs et de bonne volonté. Mais de part leur segmentation, ils n’ont finalement qu’une capacité limitée pour activer les bon leviers.

C’est tout le paradoxe de l’open-data, mouvement qui prône la transparence et l’ouverture démocratique, mais qui se réalise de manière très classique par des acteurs territoriaux et nationaux retombant rapidement dans le “nous possédons l’information, nous vous la distribuerons à notre bon vouloir”. Finalement, la société civile en revient donc souvent à des rapports de forces plutôt qu’à une collégialité sur le fond. Par ailleurs, l’absence de coordination nationale pour les collectifs et associations manque encore aujourd’hui.

La donnée est technique, le citoyen ne l’est pas

Une erreur frappante quand il s’agit d’open-data est à quel point le discours reste technique. Après une longue période autour des licences, le sujet a pu enfin se porter sur la donnée elle-même. Malheureusement, il semblerait que nous ne réussissions pas sur Rennes à dépasser ce cadre.

Pourtant, dans le même temps, il existe une volonté et une attente d’appropriation par le citoyen des données publiques. Or la donnée est un sujet hautement technique, dont le citoyen ne peut pas faire grand chose, sauf à être expert ou amateur éclairé sur le domaine – cela se ressent aussi au sein de l’association. La réconciliation entre la valeur finale portée par une donnée et l’usager est encore à proposer.

Ne serait-il pas pertinent que Rennes discute désormais d’usages qui pourraient, peut-être, trouver une réponse partielle dans la donnée publique ? L’usage déterminerait alors les données à ouvrir, inversant le processus actuel.

À qui parler ? Comment communiquer ? La démocratie participative à l’épreuve…

L’open-data stimule l’échange entre les acteurs publics et la société civile. Il semble néanmoins que les premiers n’aient pas encore ni les outils ni la culture adéquate – du moins pas de manière institutionnalisée.

Par exemple sur Rennes, nous nous retrouvons avec un forum pratiquement délaissé, et aucun canal officiel pour proposer l’accès à un jeu de donnée. Le dialogue existe mais sur un fil ténu. Il repose sur la bonne volonté de personnes au sein de l’organisme public (qui sont plusieurs à Rennes heureusement). Mais là encore, puisque la métropole n’a aucune politique ni aucun budget alloués sur le sujet, tout ceci est fragile.

Un collectif dispersé

Notre association est constituée d’une poignée de membres seulement, et l’activité général est très fluctuante. Nous avons eu une saison 2012/2013 riche, mais depuis la rentrée 2013 le collectif n’a pas réussi ni à lancer ni à porter beaucoup de sujets. Nous ne souhaitons pas forcément mener un projet complet, ni nous positionner comme fournisseur de services : nous avons fait le choix de nous positionner sur l’animation, la médiation et le dialogue. Parfois, nous créons un prototype, mais il ne sert qu’à porter une discussion avec différents acteurs. Nous ne souhaitons pas nous substituer ni pallier à l’absence de ce qui doit être une volonté politique des acteurs publics : nous n’en avons ni les moyens, ni la légitimité.

Ainsi, nous n’avons pas un projet clairement défini, et les efforts de chacun sont dilués dans le temps. Ajoutez à cela un manque de temps et une sensation de ne pas savoir comment interagir efficacement avec la métropole, et cela résulte dans une motivation en berne.

Un second souffle pour l’open-data rennais

Le tableau dressé n’est guère enthousiasmant et nous ne souhaitons pas tirer sur l’ambulance. L’open-data est un mouvement de fond qui a enfin laissé derrière lui les cheerleaders de tout ce qui est nouveau. Nous sommes entrés dans une phase qui va être longue, mais beaucoup plus constructive et productive sur le long terme.

Il est plus que temps que les acteurs de l’open-data se retrouvent, et proposent une stratégie et une gouvernance au niveau local de la donnée publique. Il existe plusieurs axes que le collectif estime envisageables :

  • Débloquer un budget et identifier un vrai rôle autour de ce sujet
  • Proposer une politique structurée au niveau métropolitain, avec les moyens d’une mise en œuvre
  • Améliorer le canal de communication entre services, mais aussi vers la société civile
  • Ouvrir la collaboration avec les autres collectivités (Nantes, Brest, Lorient…) ainsi que la région
  • Proposer un portail plus participatif comme le fait Etalab. Intégrer la communauté dans l’élaboration du cahier des charges de ce nouveau portail
  • Envisager le soutien d’efforts de crowd-sourcing
  • Engager les communautés numériques pour apporter le regard d’usages innovants

Le collectif espère une confirmation de l’engagement de Rennes métropole pour une politique de l’open-data, concrète et pérenne, et un renouveau de son activité locale et collaborative.


Question subsidaire sur la réutilisation des données Star

Posted on

Ce billet est un petit ajout que je me suis surpris à faire à la fin de l’article : Réutiliser des données du réseau Star.

Combien ça coûte un développeur ?

Question complètement annexe, mais je me suis surpris à calculer un “coût” pour mes développements. Bien entendu, j’ai tout fait en bénévole, sur mon temps libre, et je ne compte absolument pas demander de l’argent pour ça.

Mais quand même, par curiosité, je vous propose de jouer le jeu avec moi.

Coût du temps passé

Pour rappel, j’ai donc passé 12h sur l’API elle-même, 16h sur les données téléchargées, et 20h à faire une API moderne RESTFull. En arrondissant les angles, et sans trop compter les multiples moments de réflexions entre deux voyages en bus/métro/train/marche à pied/réflexion le matin en me rasant, j’arrive à 48h de travail.

Coût du temps restant

Pour donner une autre représentation de ce temps, sachez que mon coût horaire moyen tourne entre 50 et 75€ brut, soit entre 2400 et 3600€. Je pense que je peux coûter bien plus cher (surtout si je prends des tarifs parisiens), mais c’est à peu près ce que j’avais calculé pour vivre sereinement à Rennes en débutant comme freelance.

J’estime que pour finir mon travail, 30h supplémentaires sont nécessaires, soit entre 1500 et 2250€. Cela correspond à :

  • Finaliser l’API RESTFull en ajoutant entre autre les métros et les bus
  • Optimiser le traitement et l’analyse des données à télécharger
  • Installer le tout sur un serveur disponible au public
  • Écrire plus de documentation

Pour un total entre 3900 et 5850€, avec 78h de travail pour l’ensemble (passé et restant).

Coût de la gestion et des frais divers

Je propose de rajouter :

  • De la gestion de projet (discussion avec le client, réunion, etc.) soit 20% de temps en plus à 50€ de l’heure, soit 780€.
  • Des frais de gestions divers et variés, remboursement de transports éventuels, et quelques menus frais pour 5% du temps à 50€ de l’heure, soit 195€.
  • Du bug-fixing. Le sujet est relativement simple au final, les bugs déjà pris en compte en bonne partie dans le temps de travail, mais par sécurité, j’ajoute une maintenance corrective de 10% du temps au tarif horaire normal, soit entre 390 et 585€.

Le total final d’une livraison stable correspond donc à : 5265 à 7410€. Et ça, c’est pour le travail d’un seul et un unique homme. Cela devrait prendre entre 2 et 3 semaines de temps réel.

Les coûts invisibles ou non pris en compte

Tous ces calculs sa basent sur l’existant, et donc, cela ne prend pas en compte :

  • Le développement pour l’accès aux données temps réel entre l’API et le système réel Kéolis (j’ai déjà une API pour ça, cela fausse donc le temps passé sur cette partie là, qui est pour le moment de 12h).
  • La mise en forme des données à télécharger, qui peut cependant être mis à part (puisque nécessaire quel que soit le projet derrière).

Et pour l’hébergement ?

Pour ajouter une petite note supplémentaire, je pourrais estimer rapidement le coût en hébergement serveur. Considérant une architecture assez standard : une BDD, un serveur Web, un serveur Proxy/Cache. Mettons que chacune soit un serveur de taille honorable, entre 1500 et 2000€/an.

Cela fait entre 4500 et 6000€ par an pour une plateforme “premier pas”. Si je veux assurer un peu plus, j’ajouterais bien quelques parts de plus (chez Gandi.net évidement), pour arriver plutôt vers 2500€/an, pour finir donc à 7500€ par an pour l’hébergement.

Conclusion

Peut-être que je devrais monter un projet sur Ulule.fr, pour développer une API qui ne serait pas qu’en lecture seule (comme aujourd’hui). Peut-être qu’il y a un business-model à imaginer avec ces données. Peut-être…

Honnêtement, je n’en sais rien, je n’ai pas les réponses à ces questions. Je sais juste que ce que je fais, je le fais bénévolement, et que je sais ce que ça représente. Je serais curieux de savoir ce que ça représente pour quelqu’un comme Yan Bonnel, dont l’application est – oui, j’insiste – une vrai petite merveille.

Et tout ceci n’est qu’une goutte d’eau.


Réutiliser des données du réseau Star

Posted on

Le Service des transports en commun de l’agglomération rennaise, que je vais appeler le réseau Star, a commencé à ouvrir ses données vers le 1er Mars 2010. En tant que membre du collectif et usager quotidien du métro et des bus de Rennes, ces données m’intéressent. En tant que développeur (web, mais pas que), c’est plutôt le transport de ces données qui m’intéresse.

Et c’est ce dont je suis venu vous parler aujourd’hui : comment ces données se retrouvent dans nos téléphones, dans les applications de développeurs indépendants, voire le plus souvent complètement bénévoles (oui, je pense à l’excellente application Android de Yan Bonnel (et le compte twitter associé @TransportRennes)). Plus exactement, je vais vous parler de ma propre expérience, cela devrait vous donner un aperçu du travail que cela représente, et des difficultés rencontrées.

Si vous n’êtes pas développeur, j’essaie dans la suite de l’article de rester dans la vulgarisation, j’espère donc rester assez accessible. Mon but est de transmettre mes impressions sur mon expérience avec les données, en ajoutant le temps que cela m’a pris. N’hésitez pas à poser des questions en commentaire !

Où sont les données ?

Première question à se poser : où sont les données ? Non, la réponse n’est pas si simple que ça, parce que les données ne sont pas à un seul et même endroit. Le bon point, c’est que les données sont référencées à la même adresse : sur le site officiel data.keolis-rennes.fr. Mais il y a les données à télécharger, et les données de l’API.

Télécharger n’est pas encore réutiliser

Celles à télécharger sont dans un format normalisé par Google : le format GTFS. C’est une bonne et une mauvaise nouvelle. La bonne, c’est que c’est un format ouvert et relativement bien documenté, donc après quelques heures de lecture de la documentation, un développeur peut comprendre comment interpréter les fichiers. Si vous savez vous servir d’un tableur, vous pouvez ouvrir ces fichiers aussi (avec le mode CSV), et vous en sortir avec quelques bons filtres.

La mauvaise nouvelle, c’est que ce format est vu du point de vue du transporteur. C’est à dire que si vous cherchez à adopter le point de vue d’un usager, vous n’allez pas arriver bien loin. Ce qui est un peu dommage, parce que le but de ces données, quand même, c’est d’être finalement présentées par le développeur aux usagers. Orienter la structure des données vers la vision des usagers, c’est faciliter le travail des développeurs (sauf si vous voulez développer un système pour le transporteur).

Bon, pour comprendre, rien ne vaut un exemple : un usager voudra savoir si une ligne de bus peut l’emmener de l’arrêt de bus A à l’arrêt de bus B. Il regarde la fiche d’une ligne, et voit que c’est possible, parce que la fiche lui donne toute la liste des arrêts, dans l’ordre.

Le format GTFS n’a pas de concept de “fiche de voyage type”. Il propose l’ensemble des voyages complets (chacun part à telle heure, termine à telle heure, et passe par A, B, C, D, E, etc. dans un ordre précis). Mais il ne permet pas facilement de savoir quels sont les arrêts de bus d’une ligne.

C’est tout à fait logique du point de vue du transporteur, mais c’est un vrai casse-tête pour le développeur qui veut présenter l’information aux voyageurs.

En bonus point, nonobstant une qualité générale plutôt bonne, il y a des incohérences dans les données fournis dans ces fichiers par Keolis.

Deux trajets peuvent indiquer la même direction dans le même sens (c’est à dire qu’ils viennent par le même côté de la ligne, et dans le même ordre), mais ils ne partent pas toujours du même endroit. Pourtant, si vous lisez la seule donnée disponible à ce sujet, vous allez faire comme moi : vous tromper et obtenir une fausse analyse des données.

Un autre soucis que j’ai remarqué : pour un usager, globalement, un bus a trois types de journées de circulation. Les journées de la semaine (lundi au vendredi), le Samedi, et enfin le Dimanche et jour férié. Il y a un fichier pour ça dans le format GTFS, mais il est très mal exploité par Kéolis. Il n’y a pas de service type pour 5 jours, un pour le samedi, un pour le dimanche et jours fériés, et d’autres pour les cas spécifiques. À la place, il y a plusieurs fois le même service par jour de circulation. Cela créé des “faux” doublons dans la base, et si vous recherchez la performance, il faut, là encore, faire un travail long et coûteux supplémentaire.

Heureusement, vous pouvez quand même déterminer quels sont les trajets types en poussant vos analyses avec de gros traitements un petit peu plus lourd (à programmer et à exécuter). Autant vous dire que ce n’est pas pour nous rendre la tâche facile.

La faute à qui ? Un peu à GTFS, mais l’utilisation par Kéolis n’est vraiment pas optimale (même si je veux bien croire qu’il y a un effort fourni, j’ai pu en discuter rapidement avec l’ingénieur qui travaille sur le sujet pour Kéolis).

API mon amour

Une autre partie des données est disponible via une API. Ce qui est bien, car cela permet d’obtenir des données en temps réel : prochain passage, disponibilité des vélos, etc. Le soucis, de mon point de vue (d’usager et de développeur), c’est que cette API n’est ni complète ni bien documentée.

Attention, je ne critique pas ici ni l’intention ni l’ouverture des données via une API. C’est une bonne idée et je remercie Rennes, Star et Kéolis de proposer cette API. Mais en tant que développeur, je suis souvent frustré par ce que j’ai à ma disposition.

J’ai d’ailleurs écrit un petit article sur un sujet bien précis au sujet des API : “Pour qui sont les API ?”. Cet article fait suite à la rencontre qui s’est tenue à la Cantine Numérique Rennaise en décembre dernier. Lors de cette rencontre, j’ai présenté mon travail à quelques autres développeurs sur les données.

Travailler avec les données.

Une fois les données en main (façon de parler), j’ai beaucoup travaillé à les rendre réutilisables (pour moi entre autres). Tout d’abord j’ai commencé par l’API, en proposant un client python (pour développeur). Sur la douzaines d’heures que cela représente, je me suis confronté à plusieurs problèmes :

  • L’API est mal documentée. Certes il y a toutes les méthodes appelables, mais la présentation des paramètres, leur usage, etc. est très peu voire parfois pas du tout expliqué. J’ai dû passer plusieurs heures à comprendre comment faire certains appels, pourtant relativement simples une fois le tout posé à plat. Pour l’exemple, ma documentation du client pour Le Velo Star, et la documentation de la méthode principale côté API Kéolis.
  • Détail supplémentaire, la langue de la documentation est un mélange entre l’anglais et le français, ce que je trouve pour le moins surprenant, et ne me donne pas confiance en ce que je lis.
  • L’API ne retourne pas d’erreur lorsqu’il ne peut pas y avoir de contenu. Ce n’est pas normal : si je demande la ligne de bus 7814, je demande une ligne qui n’existe pas, mais l’API ne m’informe pas de mon erreur. Cela peut paraître anecdotique, mais cela induit, encore une fois, un manque de confiance dans les résultats obtenus.
  • En fonction du format de sortie demandé (JSON ou XML), les données ne sont pas toujours identiques. J’ai eu l’occasion de remonter une erreur sur l’API temps réel pour le bus (et elle a été corrigée). C’est inquiétant, parce qu’une API en laquelle on ne peut pas avoir confiance nuit à la qualité générale. S’il y a une erreur sur un cas, rien ne dit qu’il n’y en a pas pour d’autres.
  • Quelques soucis de latences, d’autres soucis avec les formats, les paramètres, la clé de l’application qui passe en clair dans l’url, etc. mais ça devient vraiment très technique.

Mais mon plus gros problème a été le suivant : L’API ne dispose pas de toutes les données. Il faut coupler les appels avec une analyse et un traitement des données à télécharger. Autant dire qu’il est impossible de se reposer naïvement sur une seule source de données.

Objectifs et réalisations

À l’origine je souhaitais simplement tester l’API, comprendre son fonctionnement, et pourquoi pas, proposer un client en python complet, pour que d’autres développeurs puissent, sereinement, reposer toute leur application sur ce client. Lorsque je me suis rendu compte que toutes les données n’étaient pas dans l’API, et qu’une bonne partie devaient être récupérer dans le flux GTFS, je me suis posé quelques questions.

Et j’ai foncé tête baissée dans un WE (environ 16h sur deux jours) de développement de scripts, d’analyses, de traitements et de formatages des données. J’ai ensuite continué quelques jours de plus (environ 20h de plus) à développer un concept d’API REST autour des données complètes (pour information, c’était mi-Décembre 2012).

En un peu moins d’une semaine de travail (aux 35h et des poussières), j’ai obtenu une API qui présente les données statiques du réseau de bus de Rennes, avec ses arrêts de bus, ses lignes, ses trajets et ses heures de passage, le tout avec des données liées les unes aux autres, une structure plus à plat et plus facile à comprendre.

Bref, quelque part, j’ai refait le travail de Kéolis avec ses propres données. Et je ne sais pas quoi en faire.

La motivation après le premier effort

Au début j’étais très motivé. Le sujet me passionne toujours autant aujourd’hui, mais après une semaine de développement, je ne suis plus trop sûr de vouloir continuer.

Parce que si mon objectif de base est à peu près atteint (un client python fonctionnel, bien que largement améliorable), je sens bien qu’il y a beaucoup plus que ça à faire. Et une partie de mon travail d’analyse et de réflexion, je ne suis pas complètement certain que c’est à moi de le faire.

Je m’explique.

Je pense qu’il faut un juste milieu. D’un côté il y a une API et des données à télécharger. De l’autre il y a des développeurs. Je veux bien travailler pour créer des outils pratiques pour les développeurs : client python, php, java, ou que sais-je encore. Je veux bien travailler pour rendre la vie plus facile aux développeurs, avec des outils d’analyses des requêtes, un vérificateur, etc.

Mais je ne veux pas refaire le travail de Kéolis, c’est à dire, refaire une API complète. Peut-être que je vais y venir quand même. Peut-être que d’autres développeurs vont trouver l’idée intéressante finalement, et je les invite à me contacter. Peut-être que, dans tout ça, il y a quelque chose “en plus” à faire, que je n’ai pas vu, pas compris, pas utilisé.

Le premier effort était super, et mes résultats sont très satisfaisants. Aujourd’hui, ma motivation fait défaut face à ce que je considère comme un service à moitié rendu – et je me demande si cela ne soulève pas non plus la question de cette notion de “service rendu” – et des attentes que cela provoque !

J’ai beaucoup d’autres choses à dire sur ces données, notamment sur ce que l’on peut faire avec, ce dont je n’ai pas parlé ici. Mais pour le moment, j’en suis là, avec mes interrogations d’usager et de développeur. Avec mon temps libre vaguement réduit et mes différents projets.

Le mieux peut-être maintenant, c’est de faire comme je le disais le 19 décembre dernier en introduction : discutons !

Edit : Petite annexe sur le “coût” de développement.


Dataviz et relations entre les données : attention aux pièges

Posted on

Parfois, vous tombez sur un joli diagramme qui vous explique en quoi deux éléments apparemment sans relation sont liés par une obscure courbe de tendances identiques.

Ce fut le cas récemment sur Twitter, où j’ai découvert cette visualisation : Internet Explorer vs Murder Rate (US). Alors oui, j’ai souri trois secondes, le temps de me rendre compte que cette dataviz était une tromperie – pour la blague, certes, mais quand même.

Une question d’échelle(s) et de référentiel(s)

Pour comprendre le souci, j’ai fait le petit calcul suivant : si 18000 meurtres (ce qui n’est pas un taux, au passage mais un nombre arbitraire) représentent 90% (comme pour l’axe de valeur du taux pour IE), alors que représentent 14000 meurtres ? Sur le diagramme, 30%, mais avec le calcul suivant : 90* 14000 / 18000 = 70 : un écart de 40% se serait donc glissé dans ce diagramme ?

Le premier problème donc, c’est d’avoir deux axes qui ne sont pas réellement en relation. Pour résoudre ce premier problème, je vous propose le diagramme suivant :

IE vs Meurtre aux US (échelle de % identique)Tout de suite, ce n’est plus tout à fait la même chose. Vous pouvez constater que la courbe des meurtres aux USA n’a pas tout à fait la même tête que la descente des parts de marché d’Internet Explorer (il chute plus vite que le taux de meurtres).

Pour obtenir ce diagramme, j’ai évalué (un peu à la louche je l’admets) le nombre de meurtre et le % d’IE, j’ai ensuite transformé en pourcentage (selon la formule précédemment citée) pour obtenir le taux de meurtres à la place des chiffres (18000, etc.).

Mais cette dataviz aussi est incorrecte ! Parce qu’elle essaye de comparer deux choses qui n’ont rien à voir pour commencer. Certes, l’échelle est plus intéressante, mais ne permet toujours pas de répondre à la question de la relation entre les deux données.

D’ailleurs, chose amusante, si je demande à mon tableur de représenter les deux échelles sur deux axes différents, voici ce que j’obtiens : IE vs Meurtre aux US (échelles de % différentes)

Comparer ce qui est comparable

Lorsque vous étiez à l’école un professeur a dû vous expliquer que comparer des Poires et des Pommes, ça ne donnait pas de très bon résultat (à propos des comparaisons de fractions, de mémoire). Et là, c’est exactement la même chose !

Voici les deux types de données ici présentées :

  • Une quantité fixe : le nombre de meurtres.
  • Un ratio : la part de marché d’Internet Explorer.

Autant dire que ces deux données ne peuvent pas être comparée telle qu’elles sont ! Si quelqu’un cherche à savoir s’il y a une relation entre le nombre de meurtres et la part d’IE, il faudrait d’abord transformer un peu tout ça en quelque chose de comparable.

Qu’est-ce qui est comparable ?

Il y a un tas de façon de comparer deux données différentes, mais je ne suis pas sûr que toutes soient pertinentes. Je vais essayer d’en présenter une et nous verrons ensuite si ça veut dire quelque chose.

Tout d’abord, je reviens aux données sur IE : ce sont des parts de marché. En gros, c’est le pourcentage de gens utilisant le logiciel. Il est plutôt difficile de trouver le même genre de comparaison pour les meurtres : faut-il prendre le nombre total de décès comme référence ? Le nombre de personnes que cela représente par rapport à la population globale ?

Tout dépend ce que l’on cherche à savoir : est-ce que la proportion de décès par meurtre a augmenté ? Ou est-ce que la proportion de meurtres a augmenté par rapport à la population totale ?

Je vais choisir de faire une comparaison avec la population totale, ce qui m’arrange plutôt bien, puisque sur Wikipédia il y a quelques statistiques à ce sujet : Classement des pays par taux d’homicide volontaire. Je sais, il y a plus drôle comme données, mais je fais avec ce que j’ai sous la main.

En outre, je ne vais pas comparer les deux données : je vais faire le ratio entre chaque valeur à la même année. Si la tendance est la même entre les deux, alors je dois obtenir une ligne droite : si le ratio est différent, cela implique qu’une valeur change plus qu’une autre (en plus ou en moins).

Ratio part de marché IE / nombre de meurtre pour 100 000 habitants

Et voilà ! J’annonce fièrement que… et bien rien en fait. J’ai seulement tracé un diagramme avec une ligne qui plonge, mais ça ne veut rien dire du tout en réalité.

Tout ceci ne prouve rien

Vous avez vu mon précédent diagramme, et vous vous êtes dit : “c’est la preuve qu’il n’y a aucun rapport entre les données !”.

En fait, ce n’est pas vrai. Plus précisément : ceci ne permet pas d’affirmer ou d’infirmer la relation. Ce n’est pas vraiment pertinent.

Si vous regardez bien, j’ai placé l’échelle du ratio à droite, qui va de 13% à 15.5%. En somme, 2.5 points séparent le maximum du minimum. Je n’ai pas non plus affiché la valeur de chaque ratio. Tout ce que vous pouvez voir c’est une ligne qui plonge. Que se serait-il passé si j’avais choisi une autre échelle, allant, par exemple, de 0 à 100% ? Vous auriez vu plutôt une ligne droite – ce qui aurait alors indiqué exactement le message inverse de mon diagramme !

C’est là qu’est le piège : lorsque vous choisissez des échelles et des représentations, vous orientez la vision de l’observateur vers le message qui vous intéresse, que vous en soyez conscient ou non. Au passage, le premier observateur, c’est vous-même !

Il faut faire attention : même en essayant de comparer ce qui peut l’être a priori, vous pouvez avoir des surprises.

Attention aux visualisations

Le but n’était pas de démontrer que la blague d’origine n’est qu’une (bonne) blague : tout le monde doit pouvoir s’en rendre compte en réfléchissant un peu.

Non, mon but ici était plutôt ceci :

  • Faire comprendre qu’une visualisation de données, c’est sortir de la donnée brute et aller vers de l’analyse.
  • Montrer que les relations entre les données sont très complexes à démontrer.

Ce n’est pas vraiment une surprise pour les connaisseurs et les analystes en la matière, mais c’est un piège très fréquent, et dans lequel il est facile de tomber. C’est l’un des problèmes le plus fréquent d’ailleurs lorsque vous regardez les sites d’informations ou la TV : des visualisations avec des données de types et d’origines très différents, des échelles trompeuses, etc.

En outre, il faut rester vigilant : parfois, nous voyons des relations entre les données parce que nous voulons les y trouver (nous sommes le premier observateur). Pourtant, un travail de fond et des analyses supplémentaires sont toujours nécessaires pour trouver et décortiquer les relations entre les données.

C’est, à mon avis, un argument important pour favoriser la culture de la donnée, et une plus large éducation et sensibilisation du public (dès l’enfance), aux visualisations et aux traitements des données.


Les bibliothèques de Rennes Métropole à l’heure de l’Open Data

Posted on

Depuis 2010, Rennes Métropole s’est lancée dans l’open data et a ouvert des données d’horizons variés. Un domaine reste malgré tout plutôt pauvre, c’est celui de la culture. Pourtant Rennes ne manque pas d’acteurs publics ou privés liés à la culture sous toutes ses formes. Le terreau est riche et fertile.

Un acteur a quand même commencé à proposer certains jeux de données, il s’agit de la bibliothèque des Champs Libres, avec ses statistiques de fréquentations par heure et par jour. Ces données sont intéressantes car elles permettent de percevoir la distribution des visites tout au long de l’année et peut-être en faire des corrélations (va-t-on plus à la bibliothèque lorsqu’il fait froid ? quand il pleut ? le printemps est-il plus propice à la lecture ? etc.). Le Collectif Open Data Rennes s’est d’ailleurs appuyé sur ces données pour en proposer un jeu de visualisations. La culture nourrit la culture.

Néanmoins, nous pensons qu’il y a plus à faire avec l’information qu’une bibliothèque peut générer et manipuler au quotidien: nombre de documents empruntés, retournés, en retard, emprunts par heure ou jour, quelle section d’une bibliothèque est la plus dévalisée. Bien entendu on peut ajouter aussi son catalogue, l’âme d’un tel lieu.

Une approche en douceur

Initialement, lorsque vous souhaitez travailler sur des données d’un acteur public, il est bon de faire un tour sur leur site afin de voir ce qui est accessible, même si ce n’est pas programmatiquement exploitable. Ainsi les Champs Libres possèdent une section évoquant l’histoire et les chiffres, notamment ceux liés à la bibliothèque.

Mais nous parlons d’open data, nous voulons des données structurées. Si aucun jeu de données ou d’API n’est proposés librement par l’acteur public en question, il est temps de prendre contact avec eux pour en discuter. La manière pour le faire dépend très largement de la politique d’ouverture de la commune et des institutions qui en dépendent, ainsi que de l’acteur lui même. Bien entendu, une sensibilisation à l’open data et à ses enjeux est un préalable important pour que l’acteur s’engage dans l’initiative. La prise de contact peut se faire par email mais il est probable qu’une entrevue de visu sera plus productive. Trouver le bon interlocuteur va requérir toute votre sagacité. Dans le cas de la Bibliothèque, ils étaient déjà engagés dans une démarche d’ouverture des statistiques, et nous avons eu la chance de les avoir rencontrés au travers de réunions sur le sujet à la Cantine Numérique Rennaise. Par ailleurs, Léa étant en très bon rapport avec des membres de la bibliothèque facilitant ainsi les premiers échanges.

Ne jamais hésiter à ouvrir la discussion, si vous trouvez le bon interlocuteur.

Un jeu de patience donnant/donnant

Dans le cas où l’acteur répond positivement à la demande d’ouverture de certaines de ses données, vous allez devoir vous armer de patience. En effet, l’existence d’une donnée ne signifie pas qu’elle soit facilement accessible ou exploitable. L’open data demande un effort et un processus qui peut se révéler complexe ou coûteux, au moins en temps.

Par ailleurs, afin de justifier ce surcoût, il est possible que l’acteur public ou privé propose d’abord un jeu de données simples afin de voir l’engouement à son égard. Cela peut faire bondir les défenseurs de l’open data qui estiment que les données ne doivent pas être prises en otage, mais le pragmatisme est de mise dans l’action publique. Par conséquent, un jeu de donnée basique attisant les appétits, il peut se révéler judicieux de montrer qu’il y a effectivement une attente réelle pour plus de données. Le collectif, sous l’impulsion de Léa, a ainsi proposé l’opération #biblioviz.

Une fois que la discussion est engagée, il convient alors de faire un état des lieux des données qu’une bibliothèque manipule et celles qui peuvent intéresser la collectivité, et enfin lesquelles entrent dans le cadre légal de l’open data.

Des contraintes à prévoir

Techniques

Les communes possèdent des fonds patrimoniaux bien antérieurs aux nouvelles technologies sans parler des mouvements d’ouvertures comme l’open data, l’open content, voire l’opensource et le logiciel libre (on parle de dizaines d’années pour les logiciels, et des centaines d’années pour certain bien du patrimoine). Ces considérations ne sont pas entrées en ligne de compte dans les appels d’offres de logiciels tels que les SIGB. Par conséquent, il est fort à parier que le logiciel équipant votre bibliothèque soit fermé (qu’il soit privateur ou privé, en tout cas non-libre d’accès). Cela pose des difficultés certaines pour l’ouverture des données, sans parler de requérir parfois une licence spécifique d’un montant substantiel. C’est le cas des bibliothèques des Rennes Métropole et ce qui a poussé le collectif à contourner cette contrainte en aspirant le catalogue via le moteur de recherche. Nous y reviendrons dans un prochain article.

Légales et politiques

La culture n’est pas un domaine simple lorsqu’il s’agit d’accéder à des données. Celles-ci sont gardées jalousement et/ou sont simplement trop complexes et coûteuses à rendre disponibles. Par ailleurs, la culture est le monde du droit : droit d’auteur, droits voisins, etc. Il peut se révéler très complexe pour un acteur de savoir comment l’open data s’inscrit dans ce contexte. Dans tous les cas, les acteurs de la culture se doivent d’être prudents avec les données, car il peut ne pas leur appartenir le droit de les mettre à disposition.

Compétences métier

Comme tout domaine, la bibliothèque a ses métiers, avec ses codes, ses règles, et son vocabulaire. Lorsque le Collectif a rencontré la Bibliothèque, il a d’abord fallu expliquer certain termes employés (rien que SIGB par exemple). De même, les données peuvent être classées et codifiées selon une norme spécifique à un métier. Cette contrainte est indéniablement une occasion de s’intéresser et de discuter du métier de la bibliothèque, et d’écouter ses acteurs et ses professionnels.

Demandeur mais aussi acteur

La démarche de l’open data doit se faire avec de la patience au ventre. Il est en effet indispensable de se remémorer que les acteurs publics ou privés, même lorsqu’ils sont moteurs, prendront le temps qu’il faut pour libérer leurs données. Il existe un temps incompressible dont il faut tenir compte, et prendre patience afin de respecter le planning des différents interlocuteurs.

Malgré tout, il est possible, comme avec le catalogue des bibliothèques, de déjà vous faire une idée des données que vous pourriez traiter et ainsi aiguiller votre interlocuteur.

L’opendata propose au citoyen un outil supplémentaire pour agir sur sa vie locale.

Conclusion

Les bibliothèques de Rennes Métropole semblent accueillir avec bienveillance l’idée d’un accès à leurs données. Mais pour des raisons de contraintes techniques liées à leur SIGB ainsi qu’à des impératifs liés à leur planning, il apparaît clair au Collectif qu’une partie du travail devra se faire par des moyens indirects tels que nous évoquions plus haut. Nous présenterons ce travail lors d’un prochain article.


Une cartographie des jardins potagers des rennais

Posted on

Quelles sont les habitudes potagères des habitants de Rennes Métropole ? Est-ce qu’ils font pousser des fruits et légumes dans leur jardin, est-ce qu’ils échangent leur productions ? Existe-t-il des réseaux de partage de denrées locales ?

Ce sont les questions que se posait Bernadette Kessler, responsable du service Innovation Numérique de Rennes Métropole, lorsqu’elle a proposé au collectif Open Data Rennes et Rennes1720 de réaliser une cartographie collaborative durant l’évènement Viva-Cités, fin septembre.

L’idée ? Afficher une grande carte de la métropole et proposer aux visiteurs de venir ajouter leur contribution, sous forme d’une punaise plantée sur leur lieu -approximatif- d’habitation.

“Alors j’ai des tomates, des fraises, des carottes, ah et aussi de la menthe sur le balcon”

Lorsque les visiteurs approchaient de la carte, deux questions leur étaient posées :

  • Combien de variétés de fruits, légumes et plantes aromatiques cultivez-vous chez vous ?
  • Quel usage global en faites-vous ?

A cette deuxième question nous proposions trois réponses : garder (pour un usage personnel et familial), donner (régulièrement à des amis, collègues, voisins) ou vendre.

Sur les neuf jours de l’évènement, plus de 120 habitants de Rennes Métropole ont participé à l’expérience et apposé leur punaise sur la carte. Une grande majorité de Rennes même, des habitants des communes de l’agglomération, et même quelques visiteurs venus de plus loin qui ont quand même voulu apporter leur contribution… tant que leur commune était visible sur la carte !

La carte en ligne

Une fois Viva-Cités terminé, nous avons numérisé les participations afin de reconstituer une carte en ligne, que voici. (cliquer pour accéder à la carte dynamique)
CarteJardinsOSM

Légende :

De 1 à 5 variétés produites

De 6 à 15 variétés

Plus de 15 variétés

Blanc : je garde / Vert : je donne / Rouge : je vends (cette option n’a jamais été donnée par les participants)
Remarque : compte tenu de l’échelle de la carte d’origine, l’emplacement des points est approximatif. Ils ne pointent pas exactement le jardin de chacun mais restent représentatifs de la rue ou du quartier choisi.

“Bien sûr, je donne quand j’en ai trop. A mes voisins surtout, on s’échange des légumes”

Le panel de participants est trop petit pour pouvoir tirer de véritables conclusions statistiques sur les usages des rennais et de leurs potagers. Néanmoins, au travers des résultats obtenus et de tous les témoignages que nous avons recueillis, nous pouvons tout de même proposer des pistes de réflexion sur le sujet.

De nombreux habitants cultivent des végétaux consommables, en ville comme en campagne, ne serait-ce qu’un pot de thym ou de ciboulette sur le balcon. Nous n’avons eu que peu de visiteurs qui déclaraient ne rien faire pousser chez eux, et les réponses étaient le plus souvent de la forme “j’aimerais bien” ou “je viens d’emménager, mais je vais m’y mettre !”

Ceux qui cultivent peu de produits ont plutôt tendance à les garder pour eux. Même si notre expérience étudiait le nombre de variétés produites, et non pas la quantité, les deux vont souvent de paire. Et cela paraît logique : celui qui ne récolte que quelques tomates dans l’année va les garder pour un usage personnel, tandis que les personnes qui font pousser de multiples légumes auront plus de facilité à donner ou échanger autour d’eux.

Cela suffit-il à expliquer le fait que, d’après nos résultats, les habitants du centre-ville de Rennes ne donnent que peu leurs fruits et légumes ? Pas forcément. L’ambiance urbaine, ne pas connaître ses voisins, ne pas savoir avec qui échanger… sont aussi des pistes à creuser pour améliorer ou créer cet esprit de partage entre les résidents d’une même zone.

Cependant, l’un des quartiers de Rennes s’est fait remarquer lors de notre expérience : Sainte-Thérèse, quartier résidentiel au sud-est de la ville, semble être un lieu très vivant, très potager, où les habitants de “ce petit village”, dixit un de nos visiteurs, se connaissent et n’hésite pas à partager entre eux les fruits de leurs cultures saisonnières. Nous avons d’ailleurs rencontré plusieurs membres de l’association Les Jardins (ou)verts, dont nous avions sans le savoir emprunté le nom pour notre opération. Les Jardiniers cherchent à développer le locavorisme (consommer des produits locaux) et la protection de l’environnement, tout en créant du lien social. Opération réussie au vu des témoignages des habitants de Sainte-Thérèse !

A la découverte des usages

Dès la conception de l’expérience, nous nous sommes rendus compte qu’il serait impossible de détailler précisément toutes les données : chaque plante cultivée, chaque utilisation, pour chaque participant, cela n’aurait pas été lisible sur la carte. Nous avons donc fait le choix de conserver seulement trois données, le nombre de variétés, l’usage global et la localisation.

Cependant, dès l’arrivée des premiers visiteurs, nous avons découvert de multiples cas auxquels nous n’avions pas pensé. “Moi je fais du troc, alors je choisis donner ou vendre ?” “Et le don de graines, ça compte ?” Untel fait partie d’un jardin familial, un autre partage le sien avec ses voisins, un troisième squatte illégalement un bout de terrain inoccupé pour faire pousser ses légumes. Autant d’usages qui font la diversité de l’expérience.

Une habitante du quartier Sainte-Thérèse nous racontait par exemple qu’elle produit plus d’une trentaine de variétés de plantes aromatiques, qu’elle dépose sur le bord de la route avec un “pot d’honnêteté” où les passants sont invités à déposer une pièce ou deux après s’être servis. On n’est plus très loin du concept britannique des incredible edible, jardiner collectivement dans l’espace public et partager avec tous les fruits et légumes qui n’auront pas traversé le pays pour venir être mangés.

Le sujet des jardins familiaux est également beaucoup revenu dans les conversations, l’affaire des prairies Saint Martin ayant marqué les esprits.

Une expérience à renouveler

Collecter des informations individuelles avec les participants, pour construire une base de données, cela s’appelle du crowdsourcing. Ce mode de collecte existe sous bien d’autres formes et dans de nombreux domaines.

Lors de cette expérience, nous avons pu constater que le thème des jardins et potagers a attiré des publics très divers, sans connaissances particulières du crowdsourcing ou de l’open data. C’est également la conclusion de Simon Chignard qui a mené lors de Viva-Cités trois ateliers sur des thématiques diverses : choisir un angle précis et concret permet d’aborder en toute simplicité avec le public le sujet encore pointu de l’open data.

De plus, nous avions choisi de présenter la carte sur une structure physique : pas d’outil numérique, rien que du papier, du liège et des punaises. En enlevant cette barrière numérique, nous avons pu ainsi toucher tous les publics présents lors de l’évènement, ce qui aurait été plus difficile avec un écran d’ordinateur, un clavier ou une souris à appréhender avant de pouvoir ajouter un point sur la carte. Nous avons déjà constaté lors de notre atelier avec des élèves de CE2-CM1 que l’outil numérique n’est pas forcément nécessaire pour parler d’open data ou de visualisation des données.

Au vu des bons résultats de l’expérience et des retours enthousiastes, nous envisageons déjà de recommencer cette opération, pourquoi pas dans un autre cadre (un quartier précis de Rennes) ou sur d’autres sujets.

Partage et diffusion des résultats

Les données collectées lors de l’opération Jardin Ouvert sont rassemblées sous forme d’un fichier KML. Nous le proposons en open data, sous la licence “Licence Ouverte” : vous êtes libre de réutiliser, tranformer, republier ce fichier, à condition de mentionner l’auteur et la source de ces données (collectif Open Data Rennes).

Télécharger le fichier source .kml
Voir la carte sur Google Maps
Voir la carte sur Open Street Map

Les photos ainsi que les visuels de cet article sont publiés sous licence Creative Commons BY-SA : vous êtes libre de réutiliser, transformer, republier ces fichier, à condition d’en mentionner l’auteur (collectif Open Data Rennes) et de rediffuser les documents sous la même licence.


Partager ne veut pas dire ouvrir

Posted on

Suite à plusieurs rencontres, faites aussi bien au sein du collectif ou d’autres engagements personnels ou professionnels, je rencontre, lis ou entend régulièrement des personnes intéressées par le partage de données ou de contenus en ligne, en particulier dans le milieu muséal ou patrimonial. Certains sont encore sceptiques quant aux avantages, craignant, qui pour son image, qui pour ses euros : pour une fois, ce billet ne les concerne (presque) pas. D’autres ont franchi le pas et se sont décidés à ouvrir leurs données, à les émanciper, à les rendre « libres ». Chouette !

« On a tout mis sous licence Creative Commons »

Il y a encore peu de temps, j’étais heureux d’entendre cela. Je le suis toujours, mais je souris moins. Saluons en premier lieu l’application d’une licence permettant de s’affranchir d’un certain nombre de démarches avant de permettre une réutilisation : c’est déjà un premier pas, qui facilite bien des usages et permet de partager. Je souris moins, car toutes les licences Creative Commons (CC) ne sont pas libres.

Les CC sont une grande famille : on peut autoriser ou interdire de nombreuses choses, la citation de l’auteur étant néanmoins obligatoire (en application du droit français et de la plupart des systèmes existants). Il est donc possible :
* d’interdire la réutilisation commerciale ;
* d’interdire la modification ;
* de forcer l’application de la licence à l’identique aux travaux dérivés.

L’ouverture, dans le sens où on l’entend pour l’open-data et l’open-content, impose de ne pas mettre en place de restrictions. Les données et les contenus doivent donc être libres, impliquant la possibilité d’en faire commerce, de les modifier et d’en faire ce qu’on veut, à la condition indéfectible de citer l’auteur. Interdire de faire quelque chose est donc incompatible avec l’étiquette open-data (quelques exemples).

L’usage d’une licence CC n’est donc pas systématiquement synonyme de partage libre, mais permet au moins une réutilisation simplifiée. C’est déjà un début, mais cela pourrait être mieux.

« On a tout mis sur Dailymotion »

Autre phrase entendue, qui représente également un effort : il est possible de consulter librement le média, et même de le placer sur son propre site. Cependant, le fait de publier sur Flickr, Dailymotion, Youtube, Vimeo et consorts est une option de partage, pas d’ouverture. En réalité, que peut faire l’utilisateur ? Cette simple question est déjà floue : ces plateformes proposent toutes des systèmes d’intégration, mais rarement des explications claires quant à l’usage qui peut être fait du contenu.

Une fois de plus, partager n’est pas ouvrir : que peut faire l’internaute de la vidéo ou des photos présentées ? Cela s’étend aux flux RSS ou aux calendriers exportables, que de nombreux sites culturels proposent pour leurs visiteurs. L’usage dans un cercle privé est bien entendu l’utilisation attendue de ces éléments, mais un blog, ou une page Facebook grande ouverte n’entrent pas dans ces cas.

L’expérience nous prouve que l’usage tend à s’affranchir des lois, fussent-elles justes ou stupides. N’importe qui reprend n’importe quoi et s’en sert pour recréer autre chose, sous une autre forme. Regardez les sites de partage de vidéos, qui regorgent de dérivés réussis (et aussi de beaucoup de râtés, certes). Concernant un contenu, l’intérêt n’est-il pas de le faire connaître et d’inciter à reprendre pour aller de l’avant ?

L’étape suivante

Le grand public commence à être sensible aux licences et aux droits de réutilisation. Quand c’est marqué clairement, il commence à savoir quoi faire : « on ne touche pas à du © » et « on peut avoir un truc à insérer automatiquement », puis « on peut prendre du CC », voire pour les plus avancés « on ne modifie pas du CC-by-nd » (pas de dérivés). Il est vraiment important d’accompagner ces personnes, en rendant plus visibles ces nouveaux usages : c’est là aussi une mission de diffusion.

Il ne faut pas hésiter à aller au delà du simple partage. Plus que de suivre une mode, l’ouverture vous amènera un regard différent, avec des personnes sincèrement intéressées par vos missions, qui vous aideront à mettre en valeur et à faire connaître vos collections, vos médiations, vos productions. De plus en étant novateur, vous entrerez dans le cercle des prescripteurs. Si vous aviez l’impression de faire déjà beaucoup, et d’en avoir autant en retour, essayez l’étape suivante : licences libres, formats ouverts et ouverture à la communauté. Vous n’aurez que de bonnes surprises !