larlet-fr-david/david/blog/2017/donnees-communs/index.md

title: Des données aux communs
slug: donnees-communs
date: 2017-03-08
chapo: La libération d’une donnée est un lâcher-prise progressif.

> Le numérique auquel nous aspirons est différent. Il ne menace ni l’économie, ni l’environnement, ni la démocratie, ni la culture. Il permet au contraire de renouveler ces domaines dans leurs fondements par une perspective centrée sur l’humain. Il protège nos libertés tout en nous donnant des moyens puissants d’exercer nos droits. Il ne concentre pas de nouveaux pouvoirs ainsi que les ressources entre les mains d’un petit nombre. Il contribue plutôt à redistribuer équitablement les pouvoirs et les richesses d’une manière durable. Il pose que nous sommes tous égaux et interdépendants, il vise à restaurer notre relation au monde et en prendre soin dans une démocratie inclusive.
>
> Ce numérique auquel nous aspirons est un commun, une ressource partagée par les communautés qui se mobilisent et s’organisent pour la produire, la créer, la protéger, la valoriser au bénéfice de toutes et de tous. Ce numérique existe et prospère. Pour des communautés engagées dans le partage des savoirs co-créés, ces pratiques issues du modèle des communaux trouvent, par l’entremise du numérique, un territoire qui n’aura jamais été aussi vaste. Le domaine public, les logiciels libres sont des exemples de communs de la connaissance, de communs numériques, qui sont vitaux pour le travail, l’éducation, la science, la culture, la liberté d’expression aujourd’hui. De surcroit, ce numérique constitue la dorsale d’une économie collaborative en plein essor mobilisant les ressources, le talent et l’énergie des citoyen.ne.s dans la concrétisation de projets inédits et porteurs.
>
> Nous aspirons à voir ce numérique humaniste reconnu et soutenu.
> 
> <cite>*[SavoirsCom1 salue la « Déclaration des communs numériques » au Québec](http://www.savoirscom1.info/2017/03/savoirscom1-salue-la-declaration-des-communs-numeriques-au-quebec/)* ([cache](/david/cache/d99b422f8d9c986fc88ad37da8af084d/))</cite>

*Ceci est un résumé de mon intervention à [Confoo](https://confoo.ca), il s’agit même d’une suite de [ce que j’ai pu partager l’année dernière autour de l’OpenData](/david/blog/2016/opendata-liens-casses/). Le déroulé était ponctué de fragments de Python que je n’ai pas reproduits ici mais que vous pourrez retrouver [sur le support](/david/talks/#35).*

## 1. Données ouvertes

[Data.gouv.fr](http://www.data.gouv.fr/fr/) est la plateforme ouverte des données publiques françaises. Il s’agit d’un moyen de publier ses données brutes et de consulter celles des autres. Elle s’adresse aussi bien aux ministères et collectivités publiques qu’aux citoyens ou aux entreprises et associations. Elle est ouverte à tous et la modération se fait a posteriori. Elle est gratuite et tous les développements sont publiés en open-source. D’autres pays réutilisent le code de la plateforme.

Je participe à son évolution depuis bientôt deux ans.

## 2. Données exploitables

La publication des données n’est que la première étape d’un long processus d’appropriation par les personnes intéressées. Un format de fichier propriétaire ou un encoding non spécifié et cela devient plus compliqué de plonger le nez dedans. Une archive corrompue ou un site inaccessible et l’on arrive rapidement à une frustration ainsi qu’une perte de confiance qui seront difficiles à aller récupérer.

Les discussions permettent aujourd’hui d’exprimer ces freins de la part des consommateur potentiels et d’engager une discussion avec les producteurs de la donnée.

## 3. Données compréhensibles

Une fois le fichier ouvert, il s’agit de comprendre ce qu’il y a dedans. C’est loin d’être intuitif dans la majorité des cas s’il n’y a pas une documentation exhaustive associée à la donnée. La description des jeux de données et de leurs ressources permet à ceux qui soumettent leurs données de préciser à quoi correspondent les termes métier par exemple ou les intitulés de colonnes peu explicites.

Il est parfois pertinent de proposer une [interface simplifiée](https://pachevalier.github.io/documentation_sirene/) à une documentation PDF de plusieurs centaines de pages.

## 4. Données interopérables

Même documentées, certaines données sont difficiles à appréhender du fait de leur complexité ou de leur taille. Retraiter cette donnée brute en aval est ce que j’ai tenté de faire avec [GeoHisto](https://github.com/etalab/geohisto/) pour le [diff du Code Officiel Géographique](https://www.insee.fr/fr/information/2114819#titre-bloc-10) de l’INSEE ou avec [Ulysse](https://github.com/etalab/sirene) pour traiter le [fichier volumineux du SIRENE](https://www.data.gouv.fr/fr/datasets/base-sirene-des-entreprises-et-de-leurs-etablissements-siren-siret/).

Il ne s’agit aucunement de remplacer les données initialement publiées mais de proposer des outils et éventuellement leurs résultats pour être à même de les exploiter plus rapidement.

## 5. Données requêtables

Par exemple, l’une des problématiques à laquelle nous sommes confrontés est de pouvoir découper des fichiers CSV à la volée en fonction de certains paramètres. Un petit [sécateur](https://github.com/etalab/secateur) nous permettrait de réaliser ceci de manière asynchrone et de proposer des liens vers des sous-ensembles propres à des territoires par exemple.

Lorsque le fichier est trop volumineux, il est possible de [fournir les outils](https://github.com/etalab/sirene#tools) pour réaliser cela de manière relativement performante.

## 6. Données conviviales

Parfois le simple fait de [proposer un sous-ensemble](https://github.com/etalab/geohisto/blob/master/exports/towns/towns_head.csv) des données générées facilite leur représentation et donc leur compréhension. C’est une suite de petits détails qui semblent insignifiants mais qui une fois mis bout à bout montrent que vous prenez soin de vos données et de leurs utilisateurs potentiels.

Encore une fois, la [documentation est critique](https://github.com/etalab/geohisto/tree/master/exports/towns#history-of-towns) pour encourager l’adoption et la réutilisation. Fournir des exemples de réutilisations réalisés ou imaginés peut également aider. Expliquer ce qui ne peut pas être fait avec est encore mieux en documentant par exemple les précédentes tentatives qui ont échouées. De même qu’il peut être pertinent de décrire la façon dont les données sources sont générées pour en comprendre les contraintes.

## 7. Données résilientes

La rapidité avec laquelle la Maison Blanche a [vidé son portail](https://twitter.com/denormalize/status/831581871230193664) opendata [soulève forcément des questions](https://www.meritalk.com/articles/white-house-open-data-disappears-transparency-donald-trump-sunlight-foundation/) ([cache](/david/cache/0a5a968deddfd30e2fbaf8ac8c2c98d5/)) lorsqu’on a en charge un tel portail dans un pays qui pourrait prochainement devenir tout aussi totalitaire. L’hébergement des données en utilisant un outil décentralisé comme `git` permet de les répliquer (et de les enrichir) à l’infini tout en conservant l’historique des modifications apportées.

Il y aurait beaucoup à faire à partir de [git-lfs](https://git-lfs.github.com/) ou [dat](https://datproject.org/) par exemple. Je ne suis pas loin de prendre le temps de faire ça en tant que citoyen [à partir de l’API](https://www.data.gouv.fr/fr/apidoc/).

## 8. Données pérennes

Les problématiques liées à l’historique sont intéressantes car l’on peut distinguer les versions de la donnée brute et celles des sujets qu’elle traite. Je me suis par exemple focalisé sur ce second point avec [GeoHisto](https://github.com/etalab/geohisto) et l’évolution des communes ainsi qu’avec l’[historique des entreprises](https://github.com/etalab/sirene#dealing-with-history-optional) du fichier SIRENE. Il s’agit d’un angle d’attaque qui se focalise sur une exploitation particulière des données, celle de travailler sur des versions/diffs pour une commune ou une entreprise précise.

Dans le [cas des départements](https://github.com/etalab/geohisto/tree/master/exports/counties), cela m’a permis de revoir mon Histoire d’une manière pratique et assez ludique.

## 9. Gouvernance ouverte

Il ne s’agit pas de s’en tenir à publier des données et à les rendre utilisables mais d’être à l’écoute de la communauté des réutilisateurs pour l’améliorer. Aussi bien dans le fond que dans la forme, il est difficile de savoir *a priori* ce qui va être pertinent pour un type de données. Prendre en compte les retours dans une boucle de rétro-action vertueuse constitue le graal de la donnée ouverte.

Avoir un lieu d’expression et de décision qui soit documenté et ouvert à tous permet de fédérer une communauté autour d’un besoin et d’itérer, aussi bien sur le plan technique que politique.

## 10. Biens communs

Au même titre que la libération du code, au début on souhaite garder le contrôle et nombreux sont les projets open-source qui ne dépassent pas cette étape. Puis l’on s’ouvre à l’autre, à ses différences de points de vues et d’expériences et on prend le temps de l’écouter pour améliorer le produit. Et enfin on s’en remet à l’intelligence collective de la communauté pour continuer d’avancer et alors seulement la résultante prend vie.

**La libération d’une donnée est un lâcher-prise progressif.**

Un bien ne peut se transformer en commun sans que son initiateur dépasse son propre ego et accepte les divergences de la communauté qui vient itérativement polliniser cette production.

## Administration ?

Le rôle de l’État dans cette démarche n’est plus d’administrer mais de mettre en relation des personnes autour de la donnée pour faciliter la production d’externalités positives. La finalité n’étant pas le *bien* commun en lui-même mais le *faire* en commun qui nous permet de *vivre* en commun.

> Je pense pour ma part que nous pouvons opposer à ces deux options un État qui serait au service des communs, où les communs seraient le moyen de créer de la valeur pour les citoyens. Cet État serait centré sur les citoyens, son rôle serait de faciliter et de responsabiliser ; il serait au service des citoyens et c’est ainsi qu’il se percevrait.
>
> <cite>*[Confrontation Constructive ou Tension Constructive - l’État et les Communs](http://www.greeneuropeanjournal.eu/confrontation-constructive-ou-tension-constructive-letat-et-les-communs/)* ([cache](/david/cache/2ec56f6dca4493e4dbd463332ef518aa/))</cite>

*Il y avait une dizaine de personnes durant la session et voici [les retours](/static/david/blog/donnees-communs-retours.pdf) proposés par Confoo dans l’heure qui suit (!) par email.*