Depuis la loi n° 2019-222 du 23 mars 2019 de programmation 2018-2022 et de réforme pour la justice et son décret d’application du 29 juin 2020, la justice française s’est engagée dans un processus d’ « Open Data » visant à la mise à disposition du public de l’ensemble des décisions des cours et tribunaux.
Côté juridictions judiciaires, la Cour de cassation a mis en place le service « Judilibre » qui intègre un moteur de recherche en ligne et une API (afin de permettre à des services tiers de se connecter à la base de données). Cette API est un outil formidable pour la mise en place d’applications web de valorisation des données produites par les juridictions judiciaires. Elle facilite grandement cette mise en œuvre, notamment pour des projets gratuits ou Open Source, en évitant le coût du téléchargement et du stockage de l’ensemble des décisions mise en ligne.
Côté juridictions administratives, le choix a été fait d’un simple téléchargement des décisions par lots et d’un moteur de recherche simplifié. L’article XI des conditions générales d’utilisation du site précise ainsi que « Le site Open Data de la juridiction administrative ne comporte pas d’API« . Ce choix est dommageable pour les développeurs qui souhaiteraient mettre en place des services à bas coût et laisse le champs libre aux plus gros acteurs (type doctrine, pappers…) disposant des ressources pour télécharger, stocker et traiter l’ensemble des décisions mises en ligne.
Toutefois, comme je le montrais dans un post précédant à propos de l’API cachée de la base ArianeWeb du Conseil d’Etat, j’ai voulu voir s’il n’existait également pas une API cachée pour ce service d’Open Data des juridictions administratives.
Or tel est en fait le cas.
Et on va se servir de cette API « secrète » pour cloner le moteur de recherche proposé par le site d’Open Data des juridictions administratives et tenter d’y ajouter des fonctionnalités supplémentaires.
En utilisant l’outil d’inspection de Firefox sur la page d’accueil du moteur de recherche, on se rend compte que le serveur fait un appel GET initié par XHR sur l’URL https://opendata.justice-administrative.fr/recherche/api/elastic/decisions (cf. image ci-dessous).
Tout d’abord, cette adresse, plus particulièrement la partie « api/elastic », nous apprend que le moteur semble être basé sur le logiciel Elasticsearch développé par la société Elastic. C’est le logiciel d’indexation et de recherche de données le plus utilisé aujourd’hui par les professionnels. Les opérations y sont effectuées à partir d’une API REST et les données échangées sont au format JSON.
Il existe donc a priori une API utilisable.
Reste à savoir si elle est accessible en dehors d’un contexte local (c’est-à-dire en dehors d’une requête effectuée par le seul site opendata.justice-administrative.fr). Pour ce faire, il suffit d’essayer de se connecter à l’URL https://opendata.justice-administrative.fr/recherche/api/elastic/decisions. On obtient alors la réponse présentée ci-dessous, à savoir un document JSON des deux cents décisions présentées en page d’accueil du moteur de recherche. L’accès à l’API est donc ouvert.
Pour voir comment utiliser cette API, le premier réflexe est de s’intéresser au code source du site.
Ce code source très succinct nous indique que le site est créé à partir du framework REACT, une bibliothèque JavaScript utilisée pour créer des interfaces utilisateurs. Cette bibliothèque est notamment utilisé pour le design de certains des sites officiels de l’Etat français dans le cadre du Système de Design de l’État (voir les composants REACT).
Il faut alors consulter le fichier « main.e20361e8.js » appelé par la page pour connaître le fonctionnement du site. Ce fichier regroupe en effet tous les composants javascript et REACT utilisés pour créer le site. Or le fichier est très, trop, long, avec 87293 lignes de code. Pour une simple interface de moteur de recherche, c’est clairement surdimensionné. On verra que l’on peut faire nettement plus simple et court en PHP (un langage de programmation très utilisée sur Internet).
En fouillant dans le code, on se rend compte que l’adresse https://opendata.justice-administrative.fr/recherche/api/elastic/decisions n’est pas celle de l’API, mais simplement la « route » utilisée pour demander à l’API les dernière décisions. Et le système a été construit d’une manière assez étrange avec des routes et des appels de paramètres différents suivant les éléments du formulaire utilisé (cf. image ci-dessous).
Par exemple, une recherche sur le mot « urbanisme » et la case « Conseil d’Etat » cochée utilisera la route « model_search_juri » puis ajout d’un élément « /openData/ » puis les paramètres « juridiction » et « mot » pour donner une URL GET de la forme : https://opendata.justice-administrative.fr/recherche/api/model_search_juri/openData/CE/urbanisme/200 (le 200 correspondant au maximum de décisions à rechercher en une fois).
Après avoir testé toutes les combinaisons possibles (le formulaire comprend une zone de texte, une sélection de la juridiction, une sélection du type de décision et une sélection d’une période temporelle), on arrive au résultat suivant :
| Combinaison | Route | Paramètres |
|---|---|---|
| mot | Simple_Search | mot |
| mot + juridiction | model_search_juri | juridiction/mot |
| mot + juridiction + type | model_search_check_juri | type/juridiction/mot |
| mot + juridiction + période | model_search_date_juri | Date_Lecture/mot/juridiction/date_debut/date_fin |
| mot + juridiction + type + période | model_ABCD | Date_Lecture/mot/type/juridiction/date_debut/date_fin |
| mot + période | model_searchANDdates | Date_Lecture/mot/date_debut/date_fin |
| mot + type + période | model_all | Date_Lecture/mot/type/date_debut/date_fin |
| mot + type | Check_Search | type/mot |
| type + période | Date_Checkbox | Date_Lecture/type/juridiction/date_debut/date_fin/null |
| type | model_noTyped | null/type |
| juridiction + type | model_noTyped | juridiction/type |
| juridiction + type + période | Date_Checkbox | Date_Lecture/type/date_debut/date_fin/juridiction |
| juridiction + période | model_date_juri | Date_Lecture/type/juridiction/date_debut/date_fin/null |
| période | model_Dates | Date_Lecture/date_debut/date_fin |
Il se confirme que la gestion des routes et des paramètres est assez atypique, pour ne pas dire autre chose. Il n’y a aucune cohérence dans les formats de nommage ou dans l’ordre des paramètres. C’est un problème pour son utilisation sous forme d’API, mais aussi pour le bon maintien et l’évolution du moteur de recherche proposé par le site.
Pour pouvoir utiliser l’API, il nous faut donc coder un petit script qui va attribuer à chaque combinaison la bonne route, puis les bons paramètres (dans le « bon » ordre). On va utiliser une technique de traitement en logique binaire.
En binaire, les nombres s’écrivent seulement avec des suites de 0 et des 1 qui représentent des interrupteurs sur ON (« 1 ») ou sur OFF (« 0 »). Ce système d’interrupteur (à la base de tout système informatique) permet de coder facilement des combinaisons comme en l’espèce. Nous avons en effet ici attribué le bit de rang 1 au paramètre « Période », puis le bit de rang 2 au paramètre « Type ». Dans ce cadre (en l’absence pour le moment de prise en compte des autres paramètres) :
- si « Période » est sur « ON » et « Type » sur « OFF », le résultat s’écrira « 01 » ;
- si « Période » est sur « OFF » et « Type » sur « ON », le résultat s’écrira « 10 » ;
- si les deux sont sur « OFF », le résultat s’écrira « 00 » ;
- si les deux sont sur « OFF », le résultat s’écrira « 11 ».
Retranscrit dans un système hexadécimal, cela revient à attribuer le chiffre 1 (équivalent hexadécimal d’un bit de rang 1) à « Période » et le chiffre 2 (équivalent hexadécimal d’un bit de rang 2), ce qui donne en les additionnant :
- si « Période » est sur « ON » et « Type » sur « OFF », le résultat sera « 1 » ;
- si « Période » est sur « OFF » et « Type » sur « ON », le résultat sera « 2 » ;
- si les deux sont sur « OFF », le résultat sera « 0 » ;
- si les deux sont sur « OFF », le résultat sera « 3 ».
Pour quatre paramètres, on travaillera sur 4 bits (c’est-à-dire une suite de quatre « 0 » ou « 1 ») où le rang 3 a pour valeur hexadécimale « 4 » et le rang 4 a pour valeur hexadécimale « 8 ». On peut alors compter de 0 à 15 (0 s’écrivant « 0000 » et 15 s’écrivant « 1111 »).
Suivant cette méthode, chaque combinaison de paramètres envoyée par le formulaire de recherche correspond à un résultat unique compris entre 0 et 15 (cf. tableau ci-dessous).
Retranscrit en code PHP, cela donne :
Et pour le traitement des paramètres, on passe par un sélecteur « switch » qui effectue une action (« case ») suivant la valeur de la variable « $pattern » correspondant à la combinaison de formulaire utilisée :
Ensuite, ce n’est plus qu’une question d’utilisation de la librairie « cURL » pour récupérer les données de l’API et de mise en forme du résultat.
A partir de là, on peut reproduire le moteur de recherche du site, en test sur https://juriadmin.fondamentaux.org/ (1700 lignes de code en PHP, JS et CSS, soit beaucoup moins que le mastodonte actuel codé en REACT).
On peut ensuite facilement ajouter de nouvelles fonctionnalités, par exemple celle de pouvoir télécharger par lot l’ensemble des décisions obtenues par la recherche (dans une limite de 100 décisions pour ne pas surcharger le serveur).
Malheureusement, certaines fonctionnalités sont plus difficiles à mettre en place. Par exemple, il est en l’état compliqué d’ajouter un paramètre de recherche sur le sens de la décision. Si les fichiers XML des décisions des juridictions, disponibles en téléchargement, intègrent directement cette information (cf. image ci-dessous), tel n’est pas le cas pour les données renvoyées par l’API. Il en est de même pour le type de recours.
Après, si vous pensez à des fonctionnalités qui pourraient vous intéresser, n’hésitez pas à les proposer en commentaire et je verrais si je peux les implémenter.
Commentaires