Publié par Pour le monde de l’information juridique, en 2021 l’attente majeure est la publication complète des décisions de justice, en application de la loi Lemaire. Cela concerne de l’ordre de 4 millions de décisions par an : un tel volume suppose des modes de publication adaptés.
Depuis une dizaine d’années l’ouverture des données (Open Data) est demandée et discutée auprès de toutes les institutions publiques. Le sujet est trop souvent résumé à la publication de données brutes : fichiers textes, CSV, XLS, PDF. Parce qu’ils sont faciles à produire, satisfont l’exigence de transparence et sont simples à utiliser. Mais le traitement approfondi et suivi de données (publiques ou non) nécessite une structuration plus élaborée, permise par le XML, le JSON ou les API.
Chez Regmind nous traitons quotidiennement des flux documentaires de toutes sortes depuis de nombreuses années. A la lumière de cette expérience, dans cet article notre CTO Martin Kirchgessner explique la distinction entre données brutes et structurées et les implications pour leur utilisation.
Différents modes de publication et différents usages
La publication de données réutilisables automatiquement se fait de deux manières : soit les données intégrales sont disponibles au téléchargement, soit elles sont récupérables individuellement via une API. Commençons par les fichiers à télécharger : on distingue les fichiers “à plat” des fichiers “structurés”.
Quelle est la différence ?
Un fichier dit “plat” est l’équivalent d’une feuille de tableur. Chaque entrée est décrite par un nombre pre-déterminé de colonnes. C’est donc adapté aux listes, par exemple les demandes de valeurs foncières qui sont une liste de transactions, ou les indicateurs français de l’épidémie de COVID-19 qui listent 4 indicateurs par date et par département.
Les formats plats les plus courants sont le CSV, les tableurs Excel ou du texte brut.
Pour des données documentaires, cela peut aussi être une collection de fichiers PDFs. C’est toutefois plus rare car l’extraction automatique du contenu d’un PDF est moins fiable.
Un fichier “structuré” encadre plus librement les champs de chaque entrée, comme si le nombre de colonnes n’était pas fixe; il permet surtout d’imbriquer des données les unes dans les autres. Cela permet entre autres d’obtenir une table des matières utilisable directement dans un programme, ou de fournir des références annotées vers d’autres documents.
C’est dans cette optique que le Journal Officiel de la République Française (JORF) est publié parallèlement en ligne et en XML. Les deux formats structurés les plus courants sont le JSON et le XML.
L’exemple du JORF soulève un autre aspect : ai-je besoin du journal du jour, chaque jour ? Ou bien de l’intégralité des journaux publiés, pour une étude statistique ? On appelle ces deux cas flux et stock, respectivement. Souvent, le stock est publié annuellement et le flux quotidiennement. Chaque publication en flux représente un volume bien inférieur au stock, ce qui se prête mieux aux API.
Dans l’open data, une API désigne la mise à disposition de données à la demande via une interface HTTP
“A la demande”, c’est à dire qu’à chaque appel nous devons indiquer quelles données nous intéressent : l’API est un formulaire de questions-réponses pour nos programmes. Les API fournissent des données structurées. Une API majeure dans le monde du droit est celle de l’Union Européenne, EUR-Lex. En France la DINUM a dédié un portail aux API publiques.
Les possibilités de publication sont donc variées. Si le mode de publication est souvent très contraint par les moyens des institutions, ils sont aussi un choix qui impacte fortement les utilisations possibles.
Le mode idéal ? Plusieurs à la fois
Les différents modes de publication impliquent différents efforts, tant à la publication qu’à l’usage. Un fichier plat annuel est simple à produire et à utiliser… mais se limitera à la production de statistiques, ou l’alimentation d’une base qui sera vite obsolète. Par exemple, vous saurez sans problème extraire des statistiques de la liste des valeurs foncières. Cependant, le fichier seul ne tiendra pas longtemps : afficher ces valeurs sur une carte interactive nécessitera de passer par plusieurs API, et après l’avoir développée la carte n’indiquera pas les dernières tendances.
Pourtant la plate-forme data.gouv.fr relève un nombre de téléchargements nettement plus important pour les fichiers plats. Ce n’est pas surprenant ; en comparaison les 84 pages du manuel EUR-Lex sont évidemment une barrière à l’utilisation… mais les possibilités sont à la hauteur.
Notons qu’il existe aussi des modes intermédiaires. Pour rester dans la jurisprudence : la base Jurica est une série presque quotidienne de décisions en PDF (format plat, pratique pour la lecture) et chacune est accompagnée de méta-données en XML (format structuré, pratique pour le traitement en masse).
Comme sur la distinction plat/structuré, la publication et l’utilisation d’un stock sont plus simples que pour un flux, mais la valeur ajoutée du flux est supérieure. Surtout dans le domaine juridique, où il n’est plus question en 2021 d’acheter chaque année l’édition “à jour” d’un code.
Ainsi la publication quotidienne d’un flux structuré est indispensable pour la comparaison de versions de code proposée par Regmind depuis ses débuts. Nous utilisons le même système de comparaison pour les codes et pour le règlement géneral de l’AMF, grâce à une structuration robuste des documents mais aussi grâce à la précision des mises à jour publiées, qui allègent l’intégration quotidienne des modifications.
Comparé aux fichiers, une API propose une flexibilité très importante lors des processus de rafraîchissement des données.
Une API permet aussi des mises à jour et applications de pointe car elle fournit des données précises, à jour, à la demande. L’utilisateur peut choisir quelles parties sont mises à jour, dans quel ordre, bref programmer en fonction de sa propre organisation des documents. Toutefois, une API demande plus de moyens à la publication, et va plus difficilement passer à l’échelle. Ainsi les API publiques limitent souvent le nombre de requêtes quotidiennes à bien moins d’un million.
Du point de vue de la ré-utilisation, les critères d’appréciation d’une démarche open data sont :
– la structuration
– la fréquence
– et la flexibilité
L’idéal est l’existence d’un flux et d’une API, comme c’est à l’oeuvre depuis 4 ans dans Regmind pour la reprise d’EUR-Lex. Les deux modes sont complémentaires et permettent une tenue à jour au plus près de la publication, très efficacement.
Car en plus d’être corrects – ce qui n’est pas évident avec des données aussi précises que les documents juridiques – les traitements doivent être performants. C’est criant lors du chargement initial (le fameux ETL). Qu’il s’agisse de jurisprudence ou de législation, le stock compte souvent en millions de documents. Au départ il est donc plus rapide d’utiliser un stock (une archive de fichiers, structurés) plutôt qu’une API. Mais au fil des jours, c’est plutôt l’API qui sera le meilleur point d’accès.
Un effort des institutions à encourager
La publication à la fois par fichiers et par API pourrait passer pour une incapacité à choisir ou une débauche de moyens : au contraire, les deux se complètent et le double mode d’accès rend la ré-utilisation plus simple, plus performante et plus riche. En offrant ce choix, des services comme Légifrance ou EUR-Lex sont à la pointe des publications en open data. Nous saluons ces efforts, qui sont un pilier de notre capacité à proposer aux juristes des outils de veille et de recherche avancés.
Alors que se prépare la publication en masse des décisions de justice, la discussion en 2020 était centrée sur l’anonymisation. Cela doit bien sûr être la première préoccupation, mais une récente présentation de la Cour de Cassation suggère que la Cour saura atteindre ses ambitions de pseudonymisation précise, en masse. Il s’agit maintenant d’anticiper le mode de publication : Comment allons-nous accéder à 4 millions de décisions de justice par an ?