Derrière le pitch : autopsie d'un système d'automatisation IA pour cabinet d'avocats

J’ai récemment remarqué un système d’automatisation pour cabinet d’avocats présenté sur Reddit comme une solution complète : accueil des prospects, standard téléphonique par IA, lecture automatique des documents, relances de dossiers, analyse de contrats. Cinq modules, un seul outil d’automatisation et d’orchestration – le genre de plateforme qui permet d’enchaîner des tâches sans écrire de code ligne par ligne – et la promesse d’un cabinet qui tourne presque tout seul.

Le montage technique de ce système est en libre accès sur Github. Je l’ai examiné, et j’ai regardé ce qu’il fait réellement plutôt que ce qu’il annonce. L’exercice mérite d’être raconté, parce qu’il pointe un problème récurrent quant aux outils d’automatisation IA qui circulent aujourd’hui : entre l’idée et sa mise en œuvre technique, il peut y avoir un monde. Même si – on ne le peut nier – c’est une bonne idée. Enfin…

Une bonne idée, sur le papier

Commençons par rendre justice à l’intention. L’architecture proposée est cohérente : un client contacte le cabinet, une IA qualifie sa demande et alerte l’avocat ; un agent vocal peut mener un premier échange téléphonique et, si besoin, prendre rendez-vous ; les documents envoyés par le client sont lus et résumés automatiquement, avec un signalement si des pièces manquent ; chaque matin, le système relance les dossiers qui approchent d’une échéance ; et surtout, pour l’analyse de contrats, rien ne part au client sans qu’un avocat ait donné son feu vert.

Ce dernier point mérite d’être souligné, parce qu’il est réellement bien pensé. Le système ne se contente pas de dire qu’un avocat “doit” valider – il est techniquement impossible pour le client de recevoir un résultat tant que cette validation n’a pas eu lieu. C’est le genre de garde-fou qu’on aimerait voir plus souvent dans les outils qui touchent à des sujets sensibles.

Ce que révèle un examen attentif

Un système d’automatisation n’est jamais que ce qu’il fait réellement – pas ce que sa présentation promet. Sur ce point, l’écart est net, et il tient en quatre constats.

Un système en double

Un examen plus poussé a révélé quelque chose d’assez frappant : sur les 155 composants qui constituent le système, 75 appartiennent à une seconde copie quasi intégrale du système entier. Ce n’est pas une redondance voulue, du type solution de secours : les deux copies utilisent la même adresse d’entrée, ce qui les mettrait en conflit si elles tournaient ensemble. Il est probable qu’il s’agisse d’un accident survenu lors de la création ou de la duplication de ce montage technique – un doublement qui n’a simplement pas été remarqué avant d’être partagé.

Une question de confidentialité qui reste sans réponse

Une partie du système fait transiter les conversations téléphoniques par un service extérieur. Pour un cabinet d’avocats, dont les échanges avec les clients sont par défaut couverts par le secret professionnel, ce choix n’est pas anodin : recourir à un prestataire externe n’est pas incompatible avec le secret professionnel, mais il est indispensable, dans un tel cas de figure, de connaître précisément les conditions de traitement, de conservation, de sous-traitance et de localisation des données. Rien, dans le système observé, ne permet de répondre à ces questions.

Une lecture tronquée des documents

Pour analyser un document ou un contrat, le système n’en traite qu’une portion – les premiers milliers de caractères. Découper un document long n’est pas un problème en soi : c’est une technique courante et légitime. Le problème est que ce découpage ne s’accompagne d’aucun mécanisme permettant ensuite de retrouver et de confronter les autres passages pertinents du document, ni de reformer un ensemble cohérent et fidèle à l’original. Dans un domaine où une clause peut être conditionnée par un renvoi situé bien plus loin dans le texte, lire un fragment sans pouvoir le recroiser avec le reste revient à travailler à l’aveugle sur le reste de l’acte.

La vérification de l’agenda est fictive

Le système annonce vérifier la disponibilité de l’agenda avant de réserver un rendez-vous. En réalité, il consulte bien le calendrier, mais n’exploite pas l’information avant de créer le créneau : il réserve simplement un horaire par défaut. La vérification existe dans le discours, pas dans le comportement. Dans un cabinet réel, ça se traduirait tôt ou tard par un double rendez-vous.

Pris isolément, chacun de ces constats pourrait passer pour un détail d’implémentation. Ensemble, ils dessinent une tendance : plusieurs présentations optimistes qui, cumulées, créent un écart significatif entre ce que le système semble faire et ce qu’il fait réellement.

Ce que ça dit, au-delà de ce cas précis

Ce système n’est pas conçu pour tromper. L’intention est bonne, une partie fonctionne réellement, et le principe de la validation humaine sur les contrats est un exemple à suivre plutôt qu’à critiquer. Mais une vérification qui n’en est pas une, un document lu en partie, un doublon accidentel… l’addition de ces éléments finit par peser lourd. Le problème n’est pas la mauvaise foi : c’est la distance, souvent invisible, entre une démonstration convaincante et un outil capable de tenir une vraie charge de travail.

Cette distance est particulièrement facile à sous-estimer avec les outils d’automatisation IA, parce qu’ils donnent une impression de finition qui ne demande qu’à être crue. Un pitch bien écrit, une liste de fonctionnalités impressionnante, et on a vite fait de considérer qu’un système “fonctionne” simplement parce qu’il tourne devant nous lors d’une démonstration.

Le vrai problème n’est pas l’automatisation

C’est peut-être le point le plus intéressant : corriger ces défauts ne transformerait pas pour autant ce système en véritable outil d’analyse juridique.

L’accueil des prospects, la lecture de documents, les relances ou la prise de rendez-vous peuvent être correctement automatisés avec une ingénierie logicielle relativement classique. Le véritable problème commence lorsqu’on prétend analyser juridiquement un dossier.

Ce problème n’est pas seulement documentaire, il est également structurel.

Le droit forme un système multidimensionnel : les domaines juridiques interagissent entre eux – une même opération peut relever simultanément du droit civil, pénal et administratif – une version précise de chaque texte s’applique selon la date des faits, et cette version doit elle-même rester cohérente avec les versions des textes connexes en vigueur à ce même moment. Un système capable de faire du recherche documentaire efficace sur de la documentation technique échoue presque nécessairement ici, parce que la pertinence d’un texte ne dépend pas seulement de son contenu, mais de sa validité au regard de la date des faits – une dimension qu’une simple recherche par similarité ne capture pas.

Un exemple tiré du droit des contrats l’illustre bien, et reste dans le champ exact du système critiqué ici.

L’article 1171 du Code civil, entré en vigueur le 1ᵉʳ octobre 2016, sanctionne le déséquilibre significatif dans les contrats d’adhésion.

Sa rédaction d’origine était large : « toute clause qui crée un déséquilibre significatif […] est réputée non écrite », sans autre condition que le cadre du contrat d’adhésion – y compris, en apparence, une clause réellement négociée par les parties.

La loi de ratification du 20 avril 2018 a resserré ce champ en ajoutant deux conditions au texte lui-même : la clause doit être non négociable et déterminée à l’avance par l’une des parties. Cette version resserrée s’applique aux contrats conclus à compter du 1ᵉʳ octobre 2018.

Prenons deux contrats contenant exactement la même clause déséquilibrée, réellement négociée par les parties : l’un signé en 2017, l’autre en 2019.

Avec la version de 2016, applicable au premier, le caractère négocié de la clause n’empêche pas, en théorie, de la voir réputée non écrite.

Mais en prenant la version de 2018, applicable au second, cette même négociation suffit à écarter l’article 1171 : la clause n’est ni non négociable ni prédéterminée. Un système qui se contenterait de retrouver l’article 1171 pour analyser la clause, sans déterminer quelle version s’applique à la date du contrat, produirait potentiellement une analyse juridiquement fausse – alors même que le texte cité serait effectivement le texte exact – mais pas dans la version applicable.

De plus, un cabinet d’affaires ne travaille pas avec un document isolé. Il travaille avec plusieurs documents, plusieurs parties, des versions successives, des événements datés, des règles applicables à des dates différentes, de la jurisprudence, parfois plusieurs juridictions – et des éléments qui peuvent sembler extérieurs au dossier initial mais qui en modifient complètement l’analyse. Une opération qui semble relever du seul droit commercial peut, selon les personnes impliquées, la nature des données ou l’intervention d’une autorité publique, faire intervenir du droit civil, pénal, administratif, voire international ou étranger. Le problème n’est alors plus seulement de retrouver le bon passage dans un document : il faut déterminer quels éléments du corpus deviennent pertinents à mesure que l’on comprend le dossier.

Un tel système suppose une représentation structurée du corpus, de ses versions, de ses relations et de leur temporalité, avec une traçabilité permettant de remonter de chaque conclusion aux éléments qui la justifient.

C’est une infrastructure de connaissance bien plus complexe qu’un simple enchaînement lecture automatique → IA → résumé – et c’est cette marche-là, invisible dans une démonstration, qui sépare un prototype convaincant d’un outil réellement utilisable par un cabinet.

Cette complexité n’est pas qu’un problème de spécialiste en LegalTech. Elle a une conséquence très concrète pour quiconque envisage d’adopter ou de commander un outil de ce genre : le système présenté ici est un bon prototype, pas un produit fini – et la distance entre les deux se paie généralement au moment où on l’a déjà commercialisé, déjà déployé, ou déjà budgété comme terminé.

C’est là qu’un projet de ce type s’effondre le plus souvent : non pas parce que l’idée était mauvaise, mais parce que personne n’a pris le temps, en amont, de mesurer l’écart entre la démonstration qui convainc et le produit qui tient une charge réelle. Un cabinet, une startup ou une équipe technique qui se lance sur cette base sans avoir posé cet écart noir sur blanc prend le risque d’investir des mois de développement avant de découvrir – trop tard – que la difficulté ne se trouvait pas là où on la croyait. C’est précisément le rôle d’un cahier des charges initial, même sommaire : non pas freiner le projet, mais forcer à formuler, avant d’écrire la moindre ligne de code, ce que le système doit réellement garantir – quelles vérifications doivent être réelles et pas seulement affichées, quelles données doivent rester sous contrôle, quelle profondeur d’analyse est attendue – pour savoir, dès le départ, si le projet est viable tel qu’il est envisagé, ou s’il doit être redimensionné avant d’engager du budget.

Quelques questions à se poser avant d’adopter ce genre de solution

• Si les défauts techniques étaient corrigés, le système ferait-il vraiment ce qu’on lui demande – ou resterait-il, au fond, un outil d’automatisation administrative habillé en outil d’analyse ?
• Le système a-t-il été testé dans des conditions réelles, ou seulement démontré ?
• Connaît-on précisément les conditions de traitement, de conservation et de sous-traitance des données sensibles qui transitent par des services tiers ?
• Les documents sont-ils traités dans leur intégralité, ou seulement en partie – et si c’est le cas, le système peut-il recroiser les fragments entre eux ?
• Ce qui est annoncé comme “vérifié” ou “validé” par le système l’est-il réellement, ou seulement consulté sans conséquence ?

Ce sont des questions simples, qui ne demandent pas d’expertise technique poussée pour être posées – seulement la curiosité de regarder sous le capot avant de faire confiance à l’étiquette.