Résumé

  • L’OCDE consulte sur un cadre commun pour représenter sous forme exécutable des lois déjà en vigueur. Elle précise que le texte de référence reste contraignant et que l’interprétation, le pouvoir d’appréciation et les décisions individuelles relèvent toujours des institutions compétentes.
  • La réutilisation d’une logique commune pourrait réduire les conversions répétées. Mais un simple lien vers la loi ne révèle ni la version appliquée, ni l’exception pertinente, ni la personne qui a validé la règle déployée dans le service.

La décision s’affiche avant sa justification

Un simulateur public indique qu’une personne n’est pas admissible à une prestation. Le résultat est immédiat, cohérent et produit par un logiciel. Pour comprendre ou contester cette réponse, il faut pourtant pouvoir remonter à une chaîne précise : quel texte était en vigueur, quelle disposition concernait le cas, quelle version de la règle informatique a été lancée et qui l’a autorisée ?

La consultation de l’OCDE sur Law as Code, ouverte en 2026, tente de rendre cette chaîne plus réutilisable. L’organisation entend par là la mise à disposition, sous forme exécutable, du droit faisant autorité et déjà en vigueur, avec un lien explicite vers les textes dont la représentation est issue. Elle ne propose pas de substituer le logiciel à la loi. Le texte demeure la source juridiquement contraignante ; le code ne modifie pas l’interprétation, les responsabilités institutionnelles ou la décision au cas par cas. Les éléments qui relèvent de l’appréciation doivent rester visibles.

Cette réserve est essentielle, mais elle ne suffit pas à expliquer comment un résultat est obtenu. Une disposition peut avoir été amendée, assortie d’une période transitoire ou interprétée par une autorité. Une agence peut déployer une version différente de celle utilisée par un prestataire ou par un autre service. Si l’écran renvoie seulement vers la loi, la personne ne sait pas laquelle de ces étapes a produit la réponse.

Mutualiser la logique, concentrer l’entretien

L’OCDE observe que les organismes traduisent souvent séparément le droit en règles numériques pour chaque système. Elle associe cette répétition au risque de doublons, d’application incohérente, de faible interopérabilité et de dépendance envers des systèmes ou fournisseurs particuliers. Un référentiel commun pourrait réduire ce travail répété. Il s’agit de l’objectif annoncé par l’OCDE, pas d’une économie mesurée ou déjà démontrée.

La mutualisation déplace cependant la responsabilité. Quelqu’un doit décider comment une disposition devient une condition informatique, faire vérifier cette interprétation, publier une version et prévenir les services qui l’utilisent lorsqu’elle change. Si chaque agence produit ses propres règles, elle supporte des coûts de maintenance séparés. Si plusieurs services utilisent le même composant, une erreur ou une mise à jour périmée peut au contraire se propager.

L’identification d’un texte n’est pas son exécution. L’European Legislation Identifier de l’Union européenne fournit des URI, des métadonnées structurées et un format d’échange pour retrouver les actes et synchroniser leurs données. Il facilite la traçabilité, sans transformer les dispositions en logique exécutable. Un identifiant commun relie une règle à sa source ; il ne prouve pas que le logiciel traduit correctement cette source.

GovCMS, en Australie, a annoncé en août que sa capacité Rules as Code était disponible sur sa plateforme. Le premier exemple en production qu’il cite vérifie si une administration peut rejoindre GovCMS ; les règles sont ouvertes. C’est un cas d’usage limité et utile pour observer un outil en service. Ce n’est pas la preuve qu’une loi est exécutée de façon faisant autorité pour les citoyens. GovCMS précise d’ailleurs que ses outils ne donnent pas de conseil juridique, ne rendent pas de décision contraignante et ne remplacent pas le jugement humain requis.

Le Service numérique du Canada a décrit un prototype destiné aux demandes d’exploitation minière et a relevé un risque plus banal : le règlement peut évoluer alors que l’outil conserve l’ancienne logique. Cette observation ne prouve pas qu’un usager a subi une décision erronée. Elle rappelle qu’une règle numérique doit avoir un responsable et un calendrier de mise à jour.

Une filiation vérifiable plutôt qu’une simple citation

Pour être utile, le dossier d’une règle devrait nommer la juridiction et le texte faisant autorité, la disposition concernée, la version et la période d’effet, les cas visés et les exceptions. Il devrait indiquer les choix d’interprétation nécessaires au codage, la personne ou l’autorité qui a validé la représentation, la version exécutable publiée et celle qu’un service a utilisée à une date donnée.

Ces informations répondent à des questions différentes. Une citation indique l’origine. Une date d’effet précise le droit applicable. Les exceptions et le périmètre permettent de vérifier si le cas entre dans la règle. Le relevé d’interprétation montre où une traduction a exigé un choix. Le journal de publication identifie l’autorité qui a permis l’usage du code. Le relevé de déploiement relie cette approbation au service qui a répondu.

Aucun journal ne tranche à lui seul un désaccord juridique. Un tribunal peut rester compétent pour établir le sens d’un texte ; une administration peut conserver un pouvoir d’appréciation ; un service peut disposer d’un recours interne. Le système devrait toutefois permettre de trouver ces limites, signaler les situations qu’il ne peut pas décider et orienter la personne vers une demande d’explication ou de correction. À défaut, l’autorité reste claire en théorie tandis que le contrôle pratique se déplace vers le chemin logiciel le moins visible.

Les tests doivent eux aussi distinguer deux niveaux. Un test informatique établit qu’une même entrée produit la même sortie. Un contrôle juridique demande si la condition codée correspond au texte, y compris ses exceptions, ses amendements et la marge d’appréciation. Les deux sont nécessaires. Une règle ambiguë peut être rendue visible par le codage ; elle ne peut être résolue sans interprétation autorisée.

Le cadre distribuera des rôles

L’OCDE ne choisit ni plateforme ni modèle institutionnel. Elle indique que la mise en œuvre demande une coopération entre juristes, équipes techniques, administrations, responsables politiques, chercheurs, acteurs économiques et société civile, avec une répartition des responsabilités compatible avec chaque ordre constitutionnel. Il reste donc à déterminer comment un cadre commun peut rendre ces rôles visibles sans prétendre que tous les pays attribuent l’interprétation de la même façon.

La première phase, consacrée à l’inventaire des initiatives, se termine le 16 octobre 2026. Une phase ultérieure doit recueillir des principes et exigences, avant l’élaboration collective d’un projet de cadre en 2027. La publication finale est attendue fin 2027 ou début 2028. Au 14 octobre, ces étapes restent prévues, non réalisées ; la date proche sert à cartographier l’existant, elle n’entérine pas une norme.

Pour une administration, le test pratique est de savoir si une personne peut reconstruire le trajet du texte à la réponse affichée. Pour les achats publics, il s’agit de désigner le mainteneur, l’autorité de mise en production, les conditions de sortie et le budget de mise à jour. Pour l’audit, il faut comparer la version approuvée à celle déployée. Pour les usagers, il faut pouvoir contester une règle sans rétro-ingénierie.

Law as Code peut rendre la traduction du droit vers les services plus réutilisable et vérifiable. Cela suppose de gouverner la représentation comme une infrastructure dotée d’un cycle de vie, tout en gardant visibles le texte et les institutions habilitées à l’interpréter. Une citation établit l’origine. La responsabilité commence quand le dossier montre aussi ce qui a été transformé, qui l’a approuvé, où cela a été exécuté et comment le corriger.

Sources