Automatisation du processus de publication des décisions de CanLII : présent et futur

Résumé

Problématique

 Publication des décisions de 65 tribunaux
 Traitement de plus de 1500 décisions par semaine
 Bilinguisme
 Équipe éditoriale de 3 personnes

Processus de publication

Cinq étapes
 Acquisition des documents
 Extraction et validation des méta-données
 Insertion dans le système et conversion
 Génération des pages Web
 Vérification post-publication

Conclusion

Notre procédure est complète, mais plusieurs étapes manuelles demeurent ; certaines de nos collections ne passent pas par l’ensemble de ce processus

Nous voulons donc uniformiser le traitement plus tôt dans le processus :
 Étendre notre processus à l’ensemble de nos collections
 Devancer l’étape de l’insertion des documents afin de minimiser les manipulations
 Promouvoir des normes d’uniformisation (référence neutre, préparation des jugements)

Texte

Automatisation du processus de publication des décisions de CanLII : présent et futur (texte)

Introduction
IIJCan entre dans sa 5e année d’existence. Ce qui était à l’origine un projet ambitieux, est maintenant une entreprise complexe qui travaille à réunir en une source unique et accessible un vaste ensemble de documents juridiques provenant de partout au Canada. Si les besoins et les attentes des usagers n’ont pas grandement changé depuis le début du projet, les problèmes et les solutions adoptés se sont à la fois diversifiés et multipliés. Ces aspects seront d’abord étudiés. Par la suite, nous pourrons faire un survol des principaux éléments du travail effectué par IIJCan, ce qui nous permettra de dégager les stratégies de gestions des problèmes identifiées.
Besoins et attentes
Malgré une portée potentiellement plus vaste, la publication électronique de documents juridiques sur le web répond d’abord au même besoin que l’édition papier, sa contrepartie traditionnelle. L’enjeu de la publication juridique demeure d’offrir une information aux professionnels du domaine, ce qui soulève en soi des enjeux spécifiques. Les besoins des utilisateurs d’IIJCan sont, à prime abord, les mêmes que ceux des autres média : l’accès et la fiabilité des documents offerts.
Ces deux caractéristiques essentielles méritent qu’on s’y attarde. D’abord, tout comme il ne suffit pas d’entreposer quelques millions de livres dans une bibliothèque pour que ceux-ci puissent être utiles, l’accès au document à l’aide de l’Internet ne repose pas simplement sur la présence d’une quantité de documents dans un serveur web. L’organisation des documents publiés et les méthodes pour y accéder constituent la porte d’entrée du système et est, en ce sens, le premier contact de l’usager. Pour que les recherches de ce dernier puissent être fructueuses, il doit être en mesure d’obtenir un document ou de limiter ses recherches à l’aide d’informations partielles. Il doit aussi être en mesure d’obtenir, de manière exhaustive, les informations associées à une cause.
De toute évidence, les technologies informatiques maintenant fort bien connues et maîtrisées du grand public, tels les outils de recherches, constituent un élément central pour cette tâche, bien qu’ils ne soient pas les seules solutions utilisées.
Quant à l’accès aux documents, les attentes de l’usager ne sont pas comblées. Il peut paraître évident qu’une présentation correcte et uniforme, garante minimale de fiabilité, doit être présente. Les documents offerts doivent aussi être à jour, à la fois sur le plan de la diffusion des décisions contemporaines que sur celui des corrections officielles occasionnellement apportées à un jugement.
Dans un contexte web, il est aussi essentiel que les documents puissent être imprimables.
Ces quelques attentes des usagers constituent certes les considérations premières de la publication d’IIJCan. Elles présentent toutefois des défis considérables d’un point de vue technique.
Problématiques
 Bilinguisme
Si les attentes ne sont pas en soi déraisonnables, les problèmes techniques qui en découlent, dans un pays bilingue comme le Canada, s’additionnent à une vitesse impressionnante. La présence de deux langues officielles, ayant valeur juridique égale, rend nécessaire la diffusion de décisions qui peuvent être dans chacune des deux langues. Il faut aussi parvenir à uniformiser une masse d’informations qui ne l’est pas à l’origine. IIJCan publie en effet les décisions de plus de 65 tribunaux localisés dans différentes provinces. Bien qu’il y ait quelques similarités structurelles entre les documents produits par les différentes instances, elles ne sont pas suffisantes, à elles seules, pour garantir l’uniformité désirée. Il y a en effet une première étape nécessaire dans l’élaboration d’IIJCan, que constitue la cueillette des documents.
 Grand nombre de sources
Dans un monde idéal, cette récolte serait uniforme et organisée de façon à obtenir une série de documents clairement identifiés et utilisables, pratiquement sans traitement. IIJCan n’étant malheureusement pas en amont de la production des documents, une telle procédure demeure un idéal à construire.
La réalité repose plutôt sur une série d’ententes avec les cours, élaborées individuellement dans un effort de collaboration. Dans certains cas, les cours ont des sites officiels sur lesquels elles publient leurs décisions, et IIJCan y accède par l’entremise de ces sites, alors que d’autres instances nous font parvenir les documents par l’entremise de courriels. Dans certains cas, l’accès aux documents nous est fourni par des éditeurs concurrents.
 Méta-données
Dépendant de la cour, nous obtenons un certain nombre de méta-données associées à chaque document. Des informations de base comme l’intitulé ou la date de jugement se trouvent certainement à l’intérieur du document. Cependant, de manière générale, elles demeurent habituellement difficiles à extraire, étant donné les différences de structures entre les produits des différentes cours. Si les méta-données ne sont pas fournies avec la décision, il nous faut effectuer l’extraction, et ce, généralement de manière manuelle.
 Conversions
Ces documents nous parviennent certes sous forme électronique, mais pas nécessairement sous le même format. Enregistrements faits à partir de Word Perfect, Microsoft Word, fichier PDF, RTF ou HTML forment une panoplie de versions qui ajoutent un niveau additionnel de traitement, étant donné la nécessité de convertir ces documents afin de conserver l’uniformité du site et des collections. Ce traitement est un problème complexe même lorsqu’il est automatisé, étant donné l’évolution constante des formats d’origine. Les différentes versions de Microsoft Word par exemple ne produisent pas le même code HTML lorsque ce mode de sauvegarde est choisi. Ces différences, particulièrement évidentes au niveau de la disposition du texte dans le HTML, peuvent même créer des incompatibilités avec certains navigateurs n’étant pas produit par Microsoft.
 Vie privée
L’anonymisation des décisions présente elle aussi une série de défis techniques particuliers. Plusieurs cours font ce travail avant de nous faire parvenir les documents, afin de respecter les lois de protection des victimes. Dans certains cas, des documents nous parviennent dans leur intégralité, alors qu’il n’est pas légal de publier leur contenu. Comme il est nécessaire de concilier protection des victimes et diffusion intégrale des collections, on se doit d’identifier les documents « à risque » et de leur appliquer un traitement particulier.
 Corrigenda
En règle générale, les documents qui nous parviennent ne sont pas modifiés par l’équipe éditoriale, sauf suite à un avis spécifique de la cour. Dans une majorité de cas, une telle demande consiste en un nouvel envoi du document problématique. Dans d’autres cas, la cour nous indique de rajouter un paragraphe ou de corriger un mot isolé. Plutôt que de simplement rendre le document accessible, il nous faut être en mesure d’assurer un suivi de la présence d’une décision sur le web et connaître l’état particulier des corrections ou modifications qui lui ont été faites.
 Relations entre les décisions
Il est clair que toute décision de la Cour suprême du Canada, ou de toute autre instance d’appel, peut être associée aux jugements rendus par la ou les instances inférieures. De façon plus générale, il existe plusieurs liens identifiables et nécessaires entre les décisions. Ces relations constituent un élément essentiel au suivi et à la compréhension d’une cause ou de l’argumentation s’y référant. En ce sens, elles constituent une valeur essentielle et souhaitable étant donné le medium (Internet). Les associations ne sont toutefois pas simples à identifier de manière automatique, étant donné l’absence d’un système de référence universel.
 Encodage
La question de l’encodage demeure un problème technique. Les documents provenant de différentes sources, un petit groupe d’encodage (Unicode, CP-1252) se trouve indifféremment dans différentes collections d’IIJCan. Les problèmes associés à ces différentes représentations informatiques des textes ne sont pas toujours évidents, puisque les encodages utilisés sont voisins. Pourtant, les caractères spéciaux que l’on retrouve dans la langue française, par exemple, peuvent être remplacés de manière peu concluante par les navigateurs. Par exemple, certains apostrophes utilisés par Word ne peuvent être reconnus par certains systèmes ne possédant pas les polices nécessaires. Le tout vient nuire à l’uniformité et à la sémantique des documents.
 Volume élevé
Toute la problématique est intimement liée au volume de traitement d’IIJCan, lequel publie, avec des effectifs limités, plus de 1500 décisions par semaine. Quoiqu’il soit possible d’envisager la résolution de ces problèmes par le biais d’un traitement manuel, cette solution n’est efficace que pour de petites collections. En effet, la quantité de documents publiés par IIJCan vient rendre cette avenue impraticable. L’ensemble du traitement doit donc reposer sur la maximisation de l’automatisation des tâches ne nécessitant pas le jugement humain.
Solutions choisies
Afin d’atteindre les objectifs fixés malgré les problèmes et difficultés énumérées plus haut, nous avons dû adopter une série de solutions générales et spécifiques à la publication de la jurisprudence.
Solutions générales
Uniformisation en amont lorsque possible
La majorité de nos efforts sont orientés vers l’uniformisation des informations et le traitement préalable. Nous avons par exemple cherché à influencer le traitement fait par les cours lors de la préparation des documents, afin d’uniformiser les informations qui nous sont transmises. Nous faisons aussi la promotion de la référence neutre, qui se veut un système de référence universel pour les juridictions canadiennes, permettant d’identifier clairement une décision.
Shipments, bordereaux et traitement des méta-données
Nous avons adopté l’utilisation d’envoi (« shipment ») comme unité de publication. Un envoi est un ensemble comprenant au moins une décision sauvegardée dans un format supporté, ainsi que les méta-données qui lui sont associées. Dans certains cas, les méta-données nous sont envoyées par la cour, ce qui simplifie le traitement fait afin d’en faire un envoi complet. Si les méta-données ne sont pas connues lors de la réception de la décision, des efforts sont mis en œuvre afin de les identifier automatiquement à l’aide de programmes informatiques. Si cette solution est insatisfaisante, le travail est fait manuellement par des éditeurs. Une fois l’extraction des informations associées à chaque jugement, l’envoi peut être inséré dans notre système et passer à l’étape de publication.
La solution de l’envoi est une autre forme d’uniformisation du traitement, puisque chaque document publié sur IIJCan est traité de cette façon.
Bases de données et DMS
Afin d’assurer un suivi complet des décisions, chaque fichier reçu est inséré dans un système de gestion des documents (« Document Management System » - DMS). Ce dernier contient toutes les informations nécessaires à la publication des décisions. Ces informations incluent notamment les noms des juridictions et cours, un historique des informations associées au jugement, ainsi que les informations plus spécifiques au document, telles les différentes versions de la décision qui nous sont parvenues et les corrections qui y ont été apportées. De plus, d’autres outils conservent des informations associées à la fois aux documents et décisions dans des tables associées de la base de données.

Indexation et recherche
La recherche dans les collections d’IIJCan étant essentielle au travail juridique, nous avons investi beaucoup de temps à l’élaboration de notre nouvel outil de recherche. La recherche est maintenant faite à l’aide d’Eliisa, notre adaptation de l’engin de recherche Open Source Lucene, répondant aux besoins spécifiques du monde juridique. L’élaboration d’Eliisa s’est avérée nécessaire pour répondre au contexte particulier d’IIJCan (p. ex., bilinguisme et quantité importante d’informations à indexer), pour lequel notre engin précédent, Sino, n’avait pas été conçu.
Clarté de la navigation
En plus d’un outil de recherche puissant, nous offrons une navigation uniforme. Chacune des juridictions est présentée par une page d’accueil, il en est de même pour les tribunaux. À partir de ce point, il est possible de naviguer les décisions par date de jugement ou par ordre alphabétique.
Liens hypertextes
Afin de faciliter la navigation entre les décisions associées, l’utilisation des liens hypertextes a été favorisée. Bien qu’un tel choix technique peut sembler évident, il faut mentionner que cette avenue nécessite l’utilisation du HTML / XHTML. Ce choix a des répercutions importantes à plusieurs niveaux. En effet, s’il est plus simple d’insérer des liens dans un document HTML, la conservation de l’apparence originale du document demeure plus difficile que lorsque un format tel PDF est employé.
URI / URL (organisés)
Comme troisième mesure de simplification de la navigation, nous avons adopté des URI organisés. D’abord divisés par juridictions, ensuite par cours et années, les décisions sont regroupées selon un hiérarchique logique et uniforme pour tous les tribunaux. Les décisions elles-mêmes se trouvent dans des fichiers, nommés à l’aide d’une conjonction des caractères composant la référence neutre de la décision, lorsque disponible. En l’absence d’une référence neutre, une référence propre à IIJCan, construite de façon similaire à la référence neutre, est utilisée.
Open source
D’un point de vue technique, nous avons, adopté les produits Open Source. Linux constitue un excellent système pour nos serveurs et les applications plus particulières, comme le système de bases de données PostgreSQL ou le serveur web Apache, et offrent des performances comparables aux meilleurs alternatives commerciales.
Java
Dans un effort d’uniformisation des procédures de traitement, les nouvelles applications développées dans le cadre du projet IIJCan sont faites en Java. Ce langage, malgré une licence fermée, est très puissant, et offre plusieurs librairies (p. ex., projet Jakarta) et outils spécifiques (p. ex., Tomcat, Eclipse, Maven), lesquels répondent efficacement aux besoins liés au type de travail effectué par notre équipe informatique.
HTML statique
Les jugements sont publiés en HTML. Ce choix n’empêche pas pour autant d’avoir un site dynamique, dans lequel les pages affichées sont produites sur demande. Nous avons toutefois préféré, pour des raisons de performances, offrir un contenu statique, quoique cette solution soit plus difficile à entretenir lorsqu’il est nécessaire d’apporter des changements.
Solutions spécifiques à la jurisprudence
Si les solutions énumérées jusqu’à présent peuvent s’appliquer à l’ensemble de la publication des documents juridiques disponibles sur IIJCan, les solutions qui suivent sont particulièrement liées à la jurisprudence.
Caviardage
La problématique de l’anonymisation mentionnée plus haut est, de toute évidence, spécifique à la jurisprudence.
Nos efforts liés à la résolution de cette question se limitaient, par le passé, à réclamer une nouvelle version d’un document jugé problématique à la cour l’ayant originalement produit. Cette solution a l’avantage de laisser entre les mains de la cour la décision de caviarder ou non la décision. Elle a pourtant plusieurs inconvénients : chaque traitement suppose une correspondance avec la cour et un délai d’attente plus ou moins long.
Nous avons récemment décidé de développer nos propres outils et de procéder au caviardage nous-même. L’hypothèse initiale, voulant qu’une telle tâche serait démesurée pour une équipe aux ressources limitées comme la nôtre, a été réfutée. Bien que la tâche ait requis plusieurs outils afin d’assister le travail fait par l’équipe éditoriale, le temps requis pour l’anonymisation demeure raisonnable et très efficace.
L’utilisation d’une macro pour Word (NOME) permet d’accélérer le traitement et de garantir l’uniformité des remplacements faits dans un document.
Validation
Avant d’être insérée dans la base de données, nous avons vu qu’une décision est associée à un envoi. Chacun de ces envois voit ses informations vérifiées par un programme de validation. La validation permet d’éviter l’insertion d’informations erronées dans le système. Le programme va, par exemple, donner un message d’erreur lorsqu’une référence neutre est manquante dans les méta-données associées à la décision soumises au système, ou donner un avertissement lorsqu’il détecte une erreur potentielle. L’éditeur peut alors régler les problèmes identifiés avant qu’ils ne soient insérés dans le système.
Polyglotte
Polyglotte est notre application de conversion, dont la tâche est de sauvegarder en HTML les documents qui nous parviennent dans divers formats (Word, WordPerfect, etc.). Ce serveur accomplit cette tâche colossale de traduction de tous les documents qui ne sont pas reçu en format HTML. Bien entendu, ce travail doit être automatisé en raison du volume considérable traité par IIJCan.
Tests
Afin d’identifier les documents problématiques à divers niveaux (présentation, contenu, etc.), une série de tests a été mise sur pied. Une fois identifiés, les documents peuvent être revus et une procédure peut être entreprise par un responsable afin de régler le problème. Chacune des décisions est testée pour chacune des modifications qui y est faite.
Un exemple de traitement associé aux tests peut éclairer leur fonction : un test passe chaque jour afin de trouver des incohérences entre les informations recueillies dans la base de données et les informations contenues dans le texte du jugement. Si le test détecte une incohérence du numéro de greffe par exemple, il va ajouter dans la base de données un drapeau (« flag »), réclamant l’attention d’un éditeur, afin de régler ce qui semble être un problème. Puisque le test est avant tout un programme, et qu’aucun programme n’est parfait, l’éditeur pourra d’abord déterminer si le programme était dans l’erreur. Dans un tel cas, un éditeur peut choisir de désactiver un test pour le soustraire aux évaluations ultérieures. Le système de tests cessera alors d’identifier cette décision comme problématique. Dans la majorité des cas toutefois, le programme soulève un problème réel et l’éditeur peut alors faire la correction nécessaire. Le système de test vérifiera le travail de l’éditeur et va lui-même retirer le drapeau associé au problème, ou encore le laisser en place si le problème n’a pas été corrigé de manière satisfaisante.
La force de ce système repose sur sa simplicité et la capacité de représenter plusieurs problèmes de nature très différentes à l’aide des drapeaux. Le fait que les corrections apportées sont faites par une intervention intelligente permet d’avoir des tests qui sont surtout un filet de protection plutôt qu’un système qui devrait être particulièrement élaboré et très spécialisé pour faire les corrections lui-même.
Pour plusieurs types de problèmes, la quantité limitée d’occurrences identifiées réclame une correction manuelle plutôt que la solution, plus coûteuse, qu’est l’élaboration d’un programme complet.
Il existe des tests pour des problèmes d’affichage, pour des questions d’anonymisation, et pour la vérification de la cohérence des informations de la base de données.
Génération
La génération est la création du document HTML statique qui sera présent sur le site web. À partir du document inséré dans le système, l’entête et le pied de page d’IIJCan sont ajoutés et une version finale du fichier est entreposée dans la structure web interne pour vérification ultérieure. Notre processus actuel utilise un serveur ColdFusion afin de produire cette version, de même que de générer les pages d’index de navigation relatives aux nouveaux documents publiés.
Vérification post-publication
La vérification post-publication est le pré-requis à l’autorisation de publication d’une décision sur le web. Une fois la publication complétée (i.e., l’étape d’insertion des envois dans le système), une vérification manuelle est faite par un éditeur. Cette étape vient garantir que l’ensemble des processus liés à la publication ont fonctionné tel que prévu et que les informations présentes dans la base de données sont correctes. Elle permet également la vérification de l’apparence finale des pages web générées (i.e., telles qu’elles seront perçues par les usagers), puisque ce n’est qu’à cette étape qu’elles peuvent être visualisées. Il est ici possible que l’éditeur détermine qu’une décision ne peut être publiée dans l’état actuel. Dans ce cas, un statut particulier est attribué à la décision, de telle sorte que la décision est soustraite à la publication sur le web jusqu’à ce qu’une correction ait pu être apportée.
Un seul processus, le meilleur
LexUM assure la publication de plusieurs sites juridiques, dont ceux de la Cour suprême du Canada et des deux instances de la Cour fédérale du Canada. Ces différents projets ont précédé l’élaboration d’IIJCan et ont des processus de publications distincts et indépendants. Lors de la mise sur pied d’IIJCan, quelques programmeurs ingénieux ont développé des programmes permettant la mise à jour des bases de données d’IIJCan à même les informations comprises dans celles de ces divers projets. Ce processus est mis en marche lorsque de récentes publications ou modifications apparaissent sur les sites desdits projets. Une telle approche fut sélectionnée puisqu’elle permettait d’éviter le dédoublement des tâches de publications ayant déjà été effectuées pour les autres sites. Maintenant qu’IIJCan a fait ses preuves, que son équipe a pris de l’expansion et qu’il dispose de plus d’outils que ces projets plus modestes, cette méthode n’est plus à privilégier.
La procédure de publication d’IIJCan, de même que les outils disponibles aux éditeurs, ayant beaucoup progressé, il est incontestable qu’elle est beaucoup plus complète et prévient les erreurs de manière plus efficace que ses contreparties. Ainsi, il serait préférable d’inverser le processus de mise à jour et d’alimenter les autres projets à même les informations comprises dans IIJCan.
Conclusion
Les besoins et attentes des usagers sont fort simples : accessibilité et fiabilité. Ces deux qualités constituent, dans le cadre qui est le nôtre, des objectifs ambitieux. Les ressources limitées d’IIJCan et les sources variées des documents destinés à la publication constituent les problématiques générales auxquelles nous sommes confrontés quotidiennement. Les méthodes et technologies employées par IIJCan ont été choisies et développées afin de pouvoir atteindre ces objectifs. Uniformité du traitement et élaboration d’une procédure détaillée de la publication, comprenant plusieurs étapes de vérification à la fois automatisée et humaine, permettent de garantir un contenu de qualité et de limiter les erreurs.

Annexe 1 : Étapes de la publication
Acquisition de la décision. Peut consister en la réception d’un courriel, un téléchargement sur l’Internet ou la réception d’un CD.
Extraction des méta-données, automatiquement et/ou manuellement
Préparation des méta-données et du document en un envoi (shipment).
Validation. Un premier programme vient vérifier les informations soumises avec le document lui-même et avec la base de données. Les erreurs et avertissements sont clairement affichés à l’éditeur.
Corrections des informations de l’envoi en fonction des résultats de l’étape de validation par l’éditeur ayant fait l’extraction des informations.
Préparation de la publication, tous les envois sont regroupés en un envoi global du jour. Cet envoi est nommé « Uber ».
Validation de l’envoi global (Uber) par le programme de validation, qui est exécuté par un autre éditeur que celui qui a fait l’extraction des données.
Correction par cet éditeur des informations se trouvant dans l’envoi global.
Enregistrement (Recorder). Les informations sont soumises à nouveau au système. Ce dernier va refuser les entrées lorsqu’elles ne correspondent pas à ce qui est requis. Les méta-informations associées aux documents sont insérées dans la base de données, les fichiers sont insérés tel quel dans le DMS et chacune des décisions est convertie en format HTML, afin qu’elle soit accessible à la génération.
Génération. Les nouveaux documents et les pages d’index qui y font références sont générés, c’est-à-dire qu’une version finale de ces documents est préparée à partir des informations de la base de données et de la version convertie en HTML à l’étape précédente. Une fois cette étape complétée, une version identique au résultat final du site dans son ensemble est disponible, afin de pouvoir l’examiner.
Tests (Vérification). Les tests, dont la tâche recoupe celle de l’étape de la validation à plusieurs niveaux, sont exécutés sur les nouvelles décisions et les corrections soumises afin de repérer des problèmes potentiels.
Vérification post-publication. Chacune des entrées d’une publication est vérifiée manuellement afin de corriger des problèmes s’étant glissés à un moment ou un autre du processus. C’est aussi la première opportunité de voir le résultat final, soit la décision telle qu’elle sera affichée sur le web avec les styles d’IIJCan. En fonction des résultats des tests, il est possible que certaines décisions soient retirées de la publication de manière temporaire, afin de régler des problèmes, tel le caviardage. Ces décisions se voient attribuées un statut de publication particulier, en attente de traitement ou d’une confirmation de la cour.
Synchronisation. Le site tel qu’il est sur le web est mis à jour afin d’être identique à la version disponible à l’interne.