Structure et architecture générale

Structure et architecture générale

Par une loi du 16 août 2016, le législateur avait imposé au Conseil d'État de publier l'intégralité de ses avis, le premier datant tout de même du 21 septembre 1948. Le délai ? Le service devait être prêt pour le 1er janvier 2017.

L'effort à fournir était colossal: recherche, scannage, vérification de la qualité, etc.. Une bonne partie des effectifs du Conseil étaient mobilisés et ont travaillé sans relâche, avec succès: le 1er janvier 2017, le Conseil d'État inaugura 3 accès aux Avis: un moteur de recherche et de consultation, des listes mensuelles et à travers une intégration dans un de ses autres outils, refLex.

J'étais en charge de la réalisation technique de la publication des avis, ainsi que du développement du moteur et de l'interface de recherche. Le procédé était fort simple (vu les contraintes de temps, une solution complexe était par définition écartée):

  1. le back-office du Conseil signale la publication d'un avis (y compris son numéro et l'emplacement du fichier, accompagné d'autres données diverses) à un service d'importation ;
  2. le service d'importation démarre un simple flux de traitement, qui enrichit par étapes les données sur l'avis:

    • extraction du texte, via une instance Tika, un composant open source ;
    • obtention de diverses métadonnées internes ;
    • indexation dans le moteur de recherche (Solr, un moteur de recherche en texte intégral, open source)
    • enregistrement dans le moteur de publication (un composant open source, une API complète développée par le Conseil d'État, chaque avis étant accessible en PDF, Texte brut et HTML)
    • ...
  3. dés la fin du traitement, l'avis est publié et à disposition du public.

Cette approche par flux de traitement permet l'ajout, le remplacement et le retrait d'étapes et de composants sans impacter les autres éléments du système.

Une approche similaire, basée sur 3 piliers (back-office, flux de traitement, moteur de recherche et de consultation), me semble donc le plus efficace, le plus évolutif et le plus réaliste pour assurer un service numérique de publication des jugements et arrêts de la justice, vu les délais à respecter.

Reste une question importante, en termes d'architecture logicielle et opérationnelle: la quantité de documents est bien plus vaste. C'est l'un des défis du service, mais loin d'être le plus inquiétant. Le passage à l'échelle est la raison d'être du numérique. Remplacez le pipe unix synchrone employé par la solution du Conseil d'État par un message broker qui alimente les composants eux-mêmes distribués et multipliés selon les besoins, et la quantité des données à traiter ne pose plus vraiment problème.

La réelle difficulté est ailleurs: définir les besoins des usagers, les inclure, tester et faire valider le service envisagé, ... Sans oublier la sécurité des données, du service, de la protection de la vie privée, des sauvegardes, le monitoring, l'accessibilité pour assurer l'accès à tous, et l'amélioration continue (personne ne dit d'amazon ou de google qu'ils sont en "maintenance"). Bref, la quantité des données, c'est vraiment le moindre des soucis 😉