Un logiciel LegalTech doit faire plus que produire des documents

Les technologies juridiques sont l’un des cinq domaines dans lesquels nous développons des logiciels. L’erreur la plus fréquente que nous voyons ici est de chercher la valeur du produit dans le document qu’il produit. La vraie valeur, c’est que la règle s’applique à chaque fois de la même façon dans le système.

En examinant la présentation d'un produit de technologie juridique, vous verrez très probablement ceci. Il génère des projets de contrats, propose des clauses, met en forme le document. Ce sont des tâches utiles. Le problème est que la véritable question du domaine n'est pas là, et que le problème que ces outils sont censés résoudre n'est en réalité que la partie la plus facile du problème.

La véritable question se situe ici. Une organisation est soumise à une obligation juridique. Une interprétation est faite sur ce que signifie cette obligation. L'interprétation est consignée dans un document. Ce document est ensuite classé, et le fonctionnement quotidien de l'organisation se poursuit sans tenir compte de ce document. Cette rupture entre le document et le système est l'erreur la plus coûteuse que je constate en pratique, et aucun outil de modèles de contrats ne la résout.

Interpréter relève de l'humain, appliquer relève du système

Transformer une règle en logiciel ne consiste pas à écrire la règle dans le code. Entre les deux se trouve une étape qui ne peut être automatisée.

L'article 7 de la loi n° 6698 dispose que, lorsque disparaissent les motifs qui rendaient nécessaire son traitement, la donnée personnelle est effacée, détruite ou anonymisée. Cette disposition est claire. Mais que signifie exactement « la disparition du motif » s'agissant des données de facturation d'une organisation ? La fin de la relation client, l'expiration du délai de conservation prévu par la législation fiscale, ou la plus tardive des deux échéances ? C'est à un juriste de répondre à cette question. Sa réponse constitue une interprétation, et tant que cette interprétation n'est pas consignée, personne ne se souviendra, six mois plus tard, pourquoi ce délai précis a été choisi.

C'est là que commence le travail du logiciel. Une fois l'interprétation arrêtée, veiller à ce qu'elle soit appliquée de la même manière à chaque fois et que cette application puisse être démontrée. Si vous disposez d'un système qui accomplit cela, vous utilisez une technologie juridique. Si vous vous contentez de générer des modèles, vous utilisez un traitement de texte.

Ce qui se passe lorsque document et système se dissocient

Prenons un exemple concret. La politique de conservation d'une organisation indique que les enregistrements de communication avec les clients seront conservés pendant deux ans. Lorsqu'un audit survient, cette politique est présentée.

L'auditeur pose une seule question. Quel composant applique ce délai ?

La réponse, le plus souvent, n'existe pas. La base de données comporte un champ created_at, mais pas de champ expires_at. Il n'existe aucun traitement qui supprime l'enregistrement à l'échéance du délai. Même si une suppression a lieu, elle ne produit aucune trace. Au final, l'organisation ne peut pas démontrer qu'elle fait ce que sa politique indique. La politique elle-même n'est pas une preuve, tout au plus une déclaration d'intention.

La façon de corriger ce tableau n'est pas de rédiger un meilleur texte de politique. C'est d'ajouter au modèle de données un champ portant le délai de conservation, d'écrire un composant qui applique ce délai, et de faire en sorte que ce composant produise une trace lorsqu'il s'exécute. Lorsque ces trois éléments sont réunis, le texte de la politique cesse d'être une simple affirmation pour devenir la description de ce que le système fait réellement.

Les cinq maillons de la chaîne

La transformation d'un texte juridique en un contrôle qui fonctionne dans le système se fait en cinq étapes. L'ordre de ces étapes compte, et l'omission de l'une d'elles rend le résultat non fiable.

On identifie d'abord la disposition. On détermine la règle applicable et, le cas échéant, son exception. Puis on procède à l'interprétation, c'est-à-dire que l'on décide de ce que la règle signifie dans le processus métier concret. Cette étape relève de l'humain et doit être consignée. À la troisième étape, l'interprétation est rattachée à l'architecture, en déterminant quel champ portera quelle règle. À la quatrième étape, on rédige le composant qui applique la règle au moment de l'opération. À la cinquième étape, l'exécution de ce composant est enregistrée.

Un contrôle rédigé sans interprétation préalable applique la mauvaise règle. Un contrôle qui ne produit pas de preuve ne sert à rien lors d'un audit. L'erreur que je rencontre fréquemment consiste à sauter les troisième et quatrième étapes pour passer directement à la cinquième. L'organisation tient un journal, y consigne des éléments, mais on ne sait pas quelle règle ce journal démontre avoir été appliquée.

La question du monopole de l'avocat

Il existe une limite que toute personne développant des produits dans ce domaine doit connaître. L'article 35 de la loi sur la profession d'avocat n° 1136 réserve aux avocats le suivi des affaires juridiques et la délivrance de consultations juridiques.

En pratique, cela détermine ce que votre produit peut et ne peut pas dire. Dire « il manque cette clause dans votre contrat » relève de l'information. Dire « ne signez pas ce contrat, cela se retournera contre vous » relève de la consultation. La frontière entre les deux est ténue et doit être délibérément préservée dans la conception du produit. La méthode la plus solide pour préserver cette frontière consiste à ce que le système ne prenne pas lui-même la décision et qu'une décision humaine reste visible derrière chaque résultat.

Cette limite ressemble à un obstacle, mais elle constitue en réalité une bonne contrainte de conception. Un système qui n'assume pas la décision n'assume pas non plus la responsabilité lorsqu'il commet une erreur, ce qui empêche l'utilisateur de faire aveuglément confiance au système.

Ce que l'intelligence artificielle a changé, et ce qu'elle n'a pas changé

Le traitement du langage naturel apporte un véritable gain d'efficacité dans l'examen des documents. Retrouver un type de clause précis parmi des centaines de contrats était autrefois un travail de plusieurs semaines. Cela prend désormais quelques heures.

Ce qui ne change pas, c'est la responsabilité. Si l'on ne peut pas retracer de quel document et de quel paragraphe provient le résultat produit par le modèle, ce résultat n'est pas une constatation, c'est une supposition. De même, si le système ne distingue pas visiblement un résultat dont il n'est pas sûr d'un résultat dont il est sûr, l'utilisateur leur accorde à tous une confiance égale, et l'erreur passe inaperçue.

Lorsque ces deux conditions ne sont pas réunies, le gain d'efficacité obtenu est ensuite compensé par le risque qui en découle. Et le pire, c'est que l'on ne sait pas quand ce risque se matérialisera.

Par où commencer

Au lancement d'un projet d'entreprise en technologie juridique, je recommande de choisir une seule obligation. Les aborder toutes en même temps semble séduisant, mais en pratique, aucune n'aboutit.

Pour l'obligation choisie, les cinq maillons sont construits dans leur intégralité. La disposition est rédigée, l'interprétation est consignée, rattachée au modèle de données, le contrôle fonctionne, la preuve est produite. Ce travail se termine en six semaines, et à la fin, vous ne disposerez pas d'un rapport, mais d'un contrôle opérationnel et d'un enregistrement présentable lors d'un audit.

La deuxième obligation avance beaucoup plus vite. Car la difficulté ne réside pas dans la règle, mais dans le fait de construire la chaîne pour la première fois.