Mon blog

Les textes de loi (et assimilés : décrets, par exemple) ne sont pas évidents à trouver et donc à citer. Ce RFC crée un espace URN (RFC 8141), lex, pour pouvoir identifier les textes juridiques. S'il est largement adopté par les juristes (ce n'est pas gagné…), il facilitera les références aux textes légaux. Ainsi,urn:lex:fr:etat:loi:2011-03-22;2011-302 pourrait identifier la loi n° 2011-302 portant diverses dispositions d'adaptation de la législation au droit de l'Union européenne en matière de santé, de travail et de communications électroniques, par exemple (elle change entre autres le régime applicable aux noms de domaine).

Comme toujours avec les URN (RFC 8141) et avec les URI en général, le but est d'attribuer des identificateurs uniques désignant une source de loi. Cette source peut être une loi, un décret, un texte d'une autorité de régulation, un jugement, etc. En revanche, les opinions et commentaires des juristes ne sont pas prévus. Comme avec tous les URN, l'identificateur ne dépend pas de la localisation en ligne d'un document (c'est un URN, pas un URL), ou même d'ailleurs de si le document est en ligne ou pas. Le but est que l'identificateur soit unique, et stable sur le long terme.

Le projet est né en Italie, sur la base du projet NormeInRete, datant de 2001. Des projets similaires existent dans d'autres pays. (Voir le livre « Technologies for European Integration; Standards-based Interoperability of Legal Information Systems ». Au niveau européen, voir « Law via the Internet; Free Access, Quality of Information, Effectiveness of Rights ».) Au niveau mondial, on peut noter que le document « Access to Foreign Law in Civil and Commercial Matters » pronait « State Parties are encouraged to adopt neutral methods of citation of their legal materials, including methods that are medium-neutral, provider-neutral and internationally consistent. ». Un tel système d'identificateurs est évidemment d'autant plus indispensable que l'inflation législative fait qu'on dépend tout le temps de textes de lois, et qu'on a besoin de les référencer dans de nombreux contextes. Toute ambiguïté dans cette référence serait bien sûr très gênante.

En pratique, le problème n'est pas trivial. Le mécanisme pour créer ces identificateurs doit être assez rigide pour assurer l'interopérabilité mais en même temps assez souple pour s'adapter aux évolutions futures. Et il doit être décentralisé car il n'y a pas d'institution mondiale supervisant les lois de tous les pays et chaque pays (voire davantage, notamment dans les États fédéraux) a déjà un mécanisme d'identification des lois.

L'approche choisie est donc un système hiérarchique, indiquant successivement le pays (via son TLD, ou via un nom de second niveau comme un.org pour l'ONU qui, curieusement, n'utilise pas son .int), la juridiction émettrice et enfin le document. On ne change donc pas les systèmes existants et on n'oblige pas les juridictions locales à adopter un système radicalement différent. La référence locale du document suit donc un schéma qui dépend de la juridiction, schéma qu'il n'est pas prévu d'uniformiser. Ainsi, urn:lex:eu:commission:directive:2010-03-09;2010-19-EU sera un texte européen (le eu), émis par la Commission, plus précisément ce sera une directive, la 2010-19-EU (la directive « modifiant la directive 91/226/CEE du Conseil et la directive 2007/46/CE du Parlement européen et du Conseil afin de les adapter aux progrès techniques dans le domaine des systèmes antiprojections de certaines catégories de véhicules à moteur et de leurs remorques »). Et urn:lex:be:conseil.etat:decision:2024-08-29;260.536 sera une décision du Conseil d'État belge (demande l’annulation de « la décision de non-classement et de non-retenue de la candidature notifiée par la partie adverse le 14 mars 2022 à la partie requérante »). Pour un pays fédéral, on aura une indication de l'entité qui émet le texte, par exemple urn:lex:br;sao.paulo:governo:decreto précédera l'identificateur d'un décret de l'État de São Paulo. (Notez le point-virgule, certains caractères sont réservés pour séparer des sous-champs dans l'URN, cf. section 3.2.)

Il devrait y avoir dans le futur un registre (pas un registre IANA) des codes identifiants les juridictions (section 2.2) du RFC mais, en septembre 2024, il n'était pas encore créé. Sa politique d'enregistrement sera « Examen par un expert » (« Expert review » du RFC 8126). Même en cas de changement géopolitique (fusion de deux pays, par exemple), les codes ne sont jamais réattribués, puisque les URN doivent être stables sur le long terme.

Les URN n'ont pas de mécanisme de résolution standard. Si on veut, à partir d'un URN, accéder à une ressource en ligne, il faut une méthode spécifique à chaque espace sous les URN. Pour lex, il est envisagé d'utiliser le DNS, en transformant l'URN en un URL, contenant un nom de domaine (section 10 du RFC, commentée plus loin). C'est d'ailleurs pour faciliter la correspondance avec les noms de domaine que le RFC (à tort, à mon avis), déconseille (section 3.4) d'utiliser des caractères non-ASCII dans les URN lex et donc d'utiliser un système de correspondance, depuis la langue de la juridiction concernée (urn:lex:de:stadt.muenchen:rundschreiben:... au lieu de urn:lex:de:stadt.münchen:rundschreiben:...). Si c'est assez évident pour l'italien ou le français (ministère → ministere), cela va nécessiter des correspondances plus élaborées dans d'autres cas. Si c'est vraiment trop difficile, le RFC recommande d'utiliser Unicode et, si on utilise le DNS et qu'on fait une correspondance en nom de domaine, de se servir de Punycode.

Quant au nom des juridictions, le RFC recommande de ne pas utiliser d'abréviations (même si elles sont courantes dans les textes juridiques), car elles ne sont pas toujours cohérentes. Donc, ministere et pas min.. Toujours pour des raisons d'uniformité, les dates doivent être en ISO 8601. [Encore une mauvaise idée : contrairement à ce qu'on lit souvent, cette norme ne garantit pas un format unique, loin de là. Utiliser le RFC 3339 aurait été une meilleure idée. Mais, en fait, le RFC suggère un profil réduit de ISO 8601 donc, en pratique, cela devrait marcher.]

Parmi les pièges amusants, il y a le fait que certains textes sont issus de plusieurs juridictions. C'est le cas des traités internationaux, par exemple. Si l'Espagne et le Portugal signent un accord, doit-il être sous urn:lex:es ou bien urn:lex:pt ? La solution du RFC (section 5.5) est simple : le texte a plusieurs URN (deux dans l'exemple ibérique ci-dessus). D'autres cas peuvent d'ailleurs se produire où un texte légal a plusieurs URN donc il n'y a pas d'URL « canonique » pour un texte. La fonction URN → texte est sans ambiguïté mais il n'y a pas de fonction texte → URN.

Maintenant, un peu de bureaucratie (section 9). Si je veux enregistrer un ou plusieurs URN lex, quelle est la marche à suivre ? D'abord, trouver le code de juridiction (en général le TLD du pays) puis l'organisation (registrar dans le RFC) chargée de gérer ce code. (Rappelez-vous que cette infrastructure n'existe pas encore.) Ces organisations doivent être stables sur le long terme, si on veut assurer la stabilité des identificateurs. Ensuite, comme chacune de ces organisations a sa propre politique, il faut suivre la politique en question.

Bon, c'est bien joli d'avoir des identificateurs stables. Mais, de nos jours, la plupart des utilisateurices voudraient davantage. Ils voudraient de l'opérationnel : je mets (je tape, je copie/colle…) un identificateur dans un navigateur et pouf, j'ai une jolie page avec le texte de loi ainsi identifié. Pour que ce beau projet fonctionne, il faut un système de résolution (section 10), qui va prendre en entrée un URN dans l'espace lex et nous donner un identificateur de plus bas niveau, un URL, par exemple, utilisable par le logiciel pour récupérer un contenu. La conception d'un tel système n'est pas triviale, entre autres parce que certains des URN lex seront invalides, par exemple lorsqu'ils auront été fabriqués automatiquement ou semi-automatiquement à partir de références informelles.

La méthode proposée dans cette section 10 (mais rappelez-vous que, pour l'instant, tout cela n'existe que sur le papier) est de s'appuyer sur le DNS et plus précisément sur les enregistrements de type NAPTR (normalisés dans le RFC 3404). Cela passera par le nom (déjà créé, cf. section 12 du RFC) lex.urn.arpa :

% dig lex.urn.arpa NAPTR
…
;; ANSWER SECTION:
lex.urn.arpa.		86400 IN NAPTR 100 10 "" "" "" lex-nameserver.nic.it.

  

Du point de vue gouvernance, il est prévu que le CNR maintienne la racine du système, notamment le serveur lex-nameserver.nic.it mentionné plus haut (ne cherchez pas à l'interroger, il semble ne pas avoir de données encore). Quand tout cela fonctionnera, un URN lex sera traduit en un URL (RFC 3405), par exemple quand le Brésil aura mis en place son système, et envoyé au CNR les informations nécessaires, urn:lex:br:senado:… sera traduit via les NAPTR en https://lex.senado.gov.br/… qui sera ensuite utilisé, par exemple par un navigateur.

L'espace lex a été enregistré (section 12) dans le registre des espaces de noms pour les URN via cette demande.