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

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 de « 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 :

Date - Numéro de version (si il existe)
- [numéro de défaut si il existe]: description du changement - explications
- [numéro de défaut si il existe]: description du changement suivant - explications

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.