De la comparabilité du droit et du logiciel

Bonjour, je suis Martin Kurtz, avocat et l'un des deux fondateurs de MaraDocs. Bienvenue sur le blog MaraDocs. Nous écrivons sur des sujets à l'intersection entre le droit et l'informatique.

Voici le premier article de la série Anwalt2Dev - A Journey. Cette série abordera mon parcours professionnel et mes motivations, mais surtout, j'expliquerai en profondeur les nombreux concepts et technologies qui constituent le paysage informatique actuel selon moi. Et oui - il y aura certainement aussi un peu de code. :)

// anwalt2dev - a journey
const SERIES_NAME = "Anwalt2Dev - A Journey"

export const tellReader = (whatDoesHeRead: string) => {
  if (whatDoesHeRead === SERIES_NAME) {
    return "There will be code, my friend :) "
  } else {
    throw new Error("you are reading the wrong stuff, buddy!")
  }
}

Bon, maintenant entrons dans le vif du sujet !

Le droit

J'ai commencé à étudier le droit à l'université de Bonn en 2005. Je ne peux pas raconter grand-chose de mes premières années à l'université : Madame le Professeur Puppe (une pénaliste légendaire connue pour ses opinions minoritaires) enseignait encore activement et le séminaire juridique disposait encore de salles informatiques dédiées où les étudiants pouvaient utiliser les ordinateurs de l'institut.

Je me souviens bien que les premiers examens avaient un niveau étonnamment différent de ceux auxquels j'étais habitué au lycée. Le droit que l'on pouvait apprendre en tant qu'étudiant se présentait à moi comme un concept vraiment vaste et cohérent. Il m'a fallu du temps pour comprendre qu'il existait des structures de pensée sous-jacentes, des modèles systémiques et des méthodes qui restaient valables dans tous les domaines.

Certes, les trois grands domaines (droit civil, droit public et droit pénal) ont chacun leur propre caractère, presque leur propre saveur, que l'on apprend à connaître en tant que jeune étudiant petit à petit au fil de nombreuses, nombreuses heures, mais néanmoins l'ensemble repose sur un schéma récurrent : la démarche pas à pas.

Les schémas d'examen

Nous apprenions surtout des schémas d'examen : par exemple les conditions de différents fondements de réclamation ou de la légalité de certaines actions étatiques. Derrière chaque point d'examen se cache une bifurcation et l'on est obligé de vraiment s'arrêter à cette bifurcation et d'examiner attentivement si tous les sous-points sont remplis. C'est seulement alors que la voie vers le point d'examen suivant est libre.

Exemple : Schéma de légalité d'un acte administratif, représenté ici sur la base d'une classe TypeScript fictive d'acte administratif.

I. Base d'habilitation (EGL)
  1. Nécessaire ?
  2. Choix de l'EGL 
  
II. Légalité formelle
  1. Compétence
  2. Procédure
    a. Audition
    b. Interdictions de participation
    c. Participation d'autres autorités
  3. Forme
  
III. Légalité matérielle
  1. Conditions de la base d'habilitation 
  2. Conditions générales de légalité
    a) Détermination, § 37 I VwVfG
    b) Pas d'impossibilité factuelle ou juridique
  3. Bon destinataire
  4. Conséquence juridique : décision discrétionnaire ou décision liée ?
    a) Décision liée : ordre de la conséquence prévue
    b) Décision discrétionnaire :
      aa) Erreur d'appréciation ?
        (1) Non-exercice du pouvoir discrétionnaire
        (2) Exercice insuffisant du pouvoir discrétionnaire
        (3) Abus de pouvoir discrétionnaire
        (4) Dépassement du pouvoir discrétionnaire
      bb) Éventuellement réduction du pouvoir discrétionnaire à zéro
      cc) Éventuellement pouvoir discrétionnaire prévu

Cette manière de procéder pas à pas est très similaire au déroulement des programmes informatiques. Le déroulement d'un programme classique (mono-thread) prévoit à chaque instant exactement une étape de vérification ou de traitement qui ne peut jamais être sautée. Inversement, un programme ne peut répondre qu'aux questions ou résoudre les problèmes qui ont été prévus au moment de la création du programme. Cela exige, lors de la création de logiciels, une capacité particulière à transposer le problème à résoudre en un modèle logique qui peut être parcouru de manière atomique. Toutes les sous-questions envisageables doivent également faire partie du modèle. Si des états inattendus surviennent ultérieurement (cas limites) qui ne sont pas interceptés (par exemple au moyen de patterns try catch), le programme plante.

La démarche pas à pas de la pensée juridique et la modélisation de problèmes dans le développement logiciel sont donc très similaires.

Pas de solutions univoques

Le logiciel peut être exécuté, testé et débogué de manière exacte et reproductible. Une entrée conduit (si correctement implémentée) à une sortie définie. Les examens juridiques en revanche se caractérisent généralement par le fait qu'ils s'appuient certes sur une structure d'examen structurée (subsomption etc.), mais contiennent toujours aussi des éléments dépendant de l'évaluation et restent ouverts à la pondération dans leur résultat. Le résultat n'est donc pas déterministe.

Le logiciel peut être testé en raison de sa nature déterministe : dans un test unitaire par exemple, une fonction à tester est alimentée de manière programmatique avec une entrée définie et l'on vérifie ensuite si elle fournit la sortie attendue. Les lois en revanche sont linguistiquement ambiguës ou du moins sujettes à interprétation. Cela signifie que l'on ne peut pas tester les résultats au sens classique du terme.

Exemple d'un test unitaire (ici dans le style du framework Jest)

describe('tellReader function', () => {
  test('should return success message when given correct series name', () => {
    // préparer
    const correctSeriesName = "Reise vom Rechtsanwalt zum Softwareentwickler";
    const expectedMessage = "There will be code, my friend :) ";

    // exécuter
    const result = tellReader(correctSeriesName);

    // comparer
    expect(result).toBe(expectedMessage);
  });
});

Les LLM et la nouvelle compréhension de l'informatique : probabilités plutôt que vérités ?

Alors que le développement logiciel classique a longtemps été considéré comme l'incarnation de la logique déterministe – entrée, sortie clairement définie –, l'utilisation de grands modèles de langage (LLM) comme Claude, LLama ou ChatGPT apporte une nouvelle forme peut-être plus souple de l'informatique. Ces systèmes n'opèrent pas sur la base d'arbres de décision codés de manière fixe, mais sur la base de modèles statistiques qu'ils ont extraits de quantités de données inimaginablement grandes. La sortie n'est donc pas prévisible au sens mathématique strict, mais se situe dans le cadre du probable, du typique, du contextuellement plausible.

Dans cette caractéristique, les résultats des LLM et les résultats et méthodes de l'argumentation juridique se ressemblent. Dans le droit également, les décisions ne sont pas purement déduites logiquement, mais prises dans un champ de tension entre texte normatif, faits, interprétation et pondération. Le résultat d'un examen juridique est rarement « correct » au sens d'une valeur objective – il est plutôt défendable, convaincant, méthodiquement bien déduit. Sachant que cela (et nous revenons ici au manque de vérifiabilité) ne peut à nouveau être jugé que par l'évaluation d'un tiers, qui doit à son tour appliquer un modèle vague pour évaluer le résultat précédemment trouvé. Le parallèle avec la réponse d'un modèle de langage est évident : ici aussi, la plausibilité basée sur les structures de modèles statistiques existantes compte plus que la vérité absolue.

Ainsi naît un nouveau pont entre droit et technologie. Alors qu'auparavant, comme décrit précédemment, la comparaison structurelle entre subsomption juridique et conception logicielle détaillée était au premier plan, le développement actuel de l'IA permet une analogie plus profonde : le travail avec les probabilités, la sensibilité au contexte et l'ouverture discursive n'est plus seulement le domaine des sciences humaines.

Parce que les exemples de code sont si jolis visuellement, voici encore une comparaison de l'ancien et du nouveau monde sous forme de deux fonctions TypeScript.

Classique et déterministe :

function isValidPurchase(userAge: number): boolean {
  if (userAge >= 18) {
    return true // Majeur – achat autorisé
  } else {
    return false // Pas majeur – achat refusé
  }
}

console.log(isValidPurchase(17)) // false
console.log(isValidPurchase(18)) // true

Style LLM moderne (ou : l'argumentation juridique comme fonction)

function assessPurchaseEligibility(userAge: number, maturityLevel: "hoch" | "mittel" | "niedrig"): string {
  if (userAge >= 18) {
    return "Achat probablement autorisé – majorité classique atteinte."
  }

  if (userAge >= 16 && maturityLevel === "hoch") {
    return "Argumentation défendable pour l'achat – marge d'interprétation possible."
  }

  if (userAge < 16 || maturityLevel === "niedrig") {
    return "Achat plutôt non autorisé – risque trop élevé."
  }

  // return en cas de mauvais prompt sans paramètre d'entrée
  return "Je suis un LLM et j'hallucine n'importe quoi, et si vous ne faites pas attention, vous ne le remarquerez pas et penserez que c'est vrai."
}

Et la suite ?

Après cette petite incursion dans les similitudes et différences entre la pensée juridique et la "pensée" des ordinateurs et des programmes, le prochain article sera un peu moins théorique.

Dans ma propre pratique d'avocat (beaucoup de droit de la circulation), une véritable frustration face aux processus inefficaces s'est développée, qui m'a tellement dérangé que pendant plusieurs années je me suis penché si intensivement sur le développement logiciel qu'aujourd'hui je suis parfois incertain de savoir si je dois me présenter comme juriste ou comme développeur logiciel quand on me demande ce que je fais :)

Deuxième article de la série : Anwalt2Dev - A Journey - Digitalisierung von Kanzleiprozessen