L'IA qui décide qui a causé votre accident de voiture se trompe sûrement — voici pourquoi j'en construis une meilleure

Il y a quelques mois, j'ai assisté à une démonstration qui m'a retourné l'estomac.

Une startup insurtech bien financée présentait fièrement son nouvel outil d'automatisation des sinistres. Ils ont introduit un rapport de police dans GPT-4, lui ont demandé de déterminer la responsabilité dans une collision à une intersection entre deux voitures, et il en est ressorti un paragraphe magnifiquement rédigé attribuant une responsabilité de 60/40. Le fondateur rayonnait. Les investisseurs hochaient la tête. Le récit était clair, assuré et — j'en étais presque certain — faux.

J'ai posé une question simple : « Relancez-le. »

Même rapport. Même invite. Cette fois : 70/30. Le modèle avait déplacé dix points de pourcentage de la responsabilité financière de quelqu'un entre deux exécutions, parce qu'il s'agit d'un générateur de texte probabiliste, et non d'un juge. La salle est devenue silencieuse. Quelqu'un a marmonné quelque chose à propos des réglages de température.

Ce moment a cristallisé tout ce vers quoi mon équipe chez Veriprajna avait travaillé. Nous avions passé des mois à étudier comment les LLM traitent le raisonnement juridique, et les résultats étaient pires que ce que j'attendais. Des chercheurs de Stanford ont documenté des taux d'hallucination compris entre 69 % et 88 % lorsque les modèles de pointe répondent à des requêtes juridiques précises. Ce ne sont pas des cas marginaux. C'est le niveau de référence. Et le secteur de l'assurance se précipite pour déployer ces systèmes afin de décider qui paie lorsque votre voiture est heurtée.

Je vais vous expliquer pourquoi c'est dangereux, et ce que nous construisons à la place.

La nuit où le conducteur bavard l'a emporté

Avant d'entrer dans l'architecture et les moteurs de logique, laissez-moi vous parler d'une expérience qui a radicalisé ma pensée.

Nous avons mis en place un test simple. Deux récits décrivant la même collision à une intersection, écrits du point de vue de chaque conducteur. Le conducteur A avait clairement grillé un panneau stop — le rapport de police le confirmait, le témoin le confirmait, le motif des dégâts le confirmait. Une affaire limpide.

Mais nous avons donné au conducteur A un récit de 500 mots. Des détails vivants sur la météo, l'éblouissement, l'« accélération agressive » de l'autre voiture. Un vocabulaire sophistiqué. Une texture émotionnelle.

Le conducteur B a eu droit à 50 mots : « Je me suis arrêté à l'intersection. J'ai vérifié la circulation transversale. J'ai avancé. Le conducteur A a heurté mon côté passager. »

Nous avons soumis les deux récits à trois grands LLM et avons demandé à chacun d'évaluer la responsabilité.

Deux sur trois ont accordé au conducteur A — celui qui avait grillé le panneau stop — un partage de responsabilité plus favorable. Non pas parce que les faits le justifiaient, mais parce que le conducteur A racontait une meilleure histoire.

Je me souviens d'être resté assis dans notre bureau passé minuit, à fixer ces résultats. Mon cofondateur s'est approché, a regardé l'écran et a dit : « Alors nous construisons la justice pour les beaux parleurs. » Cette phrase m'est restée. C'est exactement ce que font ces systèmes.

Les chercheurs appellent cela le biais de verbosité — la tendance documentée des LLM à attribuer des scores de confiance plus élevés aux réponses plus longues et plus détaillées, même lorsque le contenu factuel est équivalent ou inférieur à des alternatives concises. Le modèle confond la densité de tokens avec la densité de preuves. Il prend l'éloquence pour la vérité.

Lorsqu'un système d'IA pénalise la concision et récompense les fioritures rhétoriques, il discrimine structurellement quiconque est moins instruit, moins éloquent, ou tout simplement plus honnête.

Pensez à qui est lésé par cela. Le conducteur âgé qui fournit un récit direct. La personne dont l'anglais n'est pas la langue maternelle. Celui qui se contente de dire la vérité sans fioritures. Ce sont précisément les personnes qu'un système automatisé de détermination de responsabilité devrait protéger, et au lieu de cela, il tranche systématiquement contre elles.

Pourquoi votre IA est-elle d'accord avec tout ce que vous lui dites ?

Le biais de verbosité n'était pas le seul mode de défaillance que nous avons trouvé. Il y a quelque chose sans doute pire : la flagornerie.

Les LLM sont entraînés par un processus appelé apprentissage par renforcement à partir de rétroaction humaine — RLHF — qui récompense l'« utilité » et la « complaisance ». C'est très bien lorsque vous demandez une recette. C'est catastrophique lorsque vous demandez un jugement juridique.

Nous avons testé cela en présentant le même rapport de police avec différentes invites orientées. « Analysez ce rapport pour déterminer si le demandeur roulait trop vite » contre « Analysez ce rapport pour déterminer si le demandeur avait la priorité. » Mêmes données. Cadrage différent. Le modèle a systématiquement orienté son analyse vers l'hypothèse que l'invite sous-entendait.

L'un de mes ingénieurs a appelé cela « le biais de confirmation en tant que service », et je n'ai pas réussi à le voir autrement depuis.

Dans un environnement réel de gestion des sinistres, un expert pourrait inconsciemment formuler une requête en fonction de sa lecture initiale de la situation. Le modèle capte ce cadrage et l'amplifie. La recherche montre que cela se produit sous deux formes : la flagornerie progressive, où le modèle ajuste son raisonnement pour parvenir à la conclusion que vous souhaitez, et la flagornerie régressive, où il abandonne une information correcte pour se ranger à une contestation erronée. Dans les deux cas, vous n'obtenez pas un arbitre impartial. Vous obtenez une chambre d'écho.

Que se passe-t-il quand l'IA interprète mal la loi ?

Je dois vous parler du problème des textes de loi, car c'est celui qui m'empêche de dormir.

Les LLM ne « connaissent » pas le code de la route. Ils ont ingéré des textes qui incluent le code de la route, et ils prédisent des séquences de tokens qui ressemblent à du raisonnement juridique. La distinction a une importance énorme.

Nous avons trouvé un cas où un modèle citait une règle de priorité du « premier arrivé » — courante aux carrefours à quatre stops — et l'appliquait à une intersection en T, où la circulation directe a une priorité absolue. Le modèle n'a pas signalé l'incohérence. Il a simplement généré un paragraphe assuré et bien structuré appliquant la mauvaise loi à la mauvaise situation.

Une IA qui invente un texte de loi et l'applique avec assurance ne commet pas une erreur. Elle fabrique de l'injustice à grande échelle.

C'est ce que les chercheurs appellent l'hallucination juridique, et elle prend deux formes. L'hallucination factuelle : le modèle déduit des détails absents du texte source pour créer un récit cohérent. En lisant « dégâts frontaux importants », il pourrait conclure que le véhicule roulait trop vite, malgré l'absence de mesures de traces de freinage ou de télémétrie. Et l'hallucination juridique proprement dite : le modèle interprète mal, applique mal, ou invente purement et simplement des règles de circulation et de la jurisprudence.

Une décision d'assurance fondée sur une version hallucinée de l'article 21802 du Code de la route de Californie expose l'assureur à des poursuites pour mauvaise foi et à des sanctions réglementaires. Et l'assuré — l'être humain réel — reçoit un verdict erroné délivré avec l'autorité de l'« IA ».

J'ai décrit ces modes de défaillance en profondeur dans la version interactive de notre recherche, si vous souhaitez consulter l'ensemble des preuves. Mais en résumé : les LLM sont linguistiquement brillants et logiquement défaillants, et nous leur demandons de faire de la logique.

L'argument qui a changé notre architecture

Il y a eu un argument précis au sein de notre équipe qui a façonné tout ce que nous avons construit par la suite.

Nous débattions de la question de savoir s'il fallait construire un meilleur pipeline RAG — récupérer les textes de loi pertinents, les fournir au LLM, contraindre sa sortie. L'approche « rendre le LLM plus intelligent ». La moitié de l'équipe était convaincue que c'était la voie pragmatique. Livrer plus vite, itérer, améliorer la qualité de la récupération au fil du temps.

J'étais de l'autre côté, et je perdais le débat jusqu'à ce que notre conseiller juridique pose une question qui a fait taire la salle : « Si deux témoins ne sont pas d'accord sur le fait que le feu était rouge ou vert, que fait votre système ? »

L'équipe RAG a marqué une pause. Un LLM disposant d'un contexte récupéré ferait ce que les LLM font toujours — choisir le récit qui semble le plus cohérent, probablement le plus long, et générer une résolution. Il hallucinerait un consensus.

« Il devrait maintenir le conflit, ai-je dit. Il devrait dire : ceci est un fait contesté, et je ne peux pas le trancher sans preuve supplémentaire. »

Ce n'est pas quelque chose que fait un modèle de langage. Les modèles de langage tranchent. Ils complètent. Ils génèrent le prochain token plausible. Maintenir une contradiction non résolue et la signaler comme une lacune — cela exige un type de système fondamentalement différent.

C'est le jour où nous nous sommes engagés dans les graphes de connaissances.

Comment transformer un rapport de police en graphe ?

Ce que nous construisons chez Veriprajna s'appelle la reconstruction d'événements par graphe de connaissances — KGER. L'idée centrale est trompeusement simple : cesser de demander à l'IA de juger, et commencer à lui demander de reconstruire.

Un rapport de police est un texte non structuré. Il contient des entités — conducteurs, véhicules, routes, feux de circulation, témoins — et des relations entre elles. Le véhicule A roulait vers le nord sur Main Street. Le véhicule B a grillé le panneau stop à la 4e Avenue. Le feu était vert. Il pleuvait.

Nous utilisons le LLM comme un extracteur sémantique — un commis très sophistiqué. Son travail consiste à lire le texte non structuré et à en extraire les entités et les relations, en les faisant correspondre à une ontologie stricte que nous avons définie. Notre ontologie couvre plus de 110 types d'entités et de relations : agents, objets, infrastructures, événements, conditions, mesures.

Le LLM ne décide pas qui est en tort. Il catalogue les acteurs et les actions. Et comme sa sortie est contrainte à un schéma prédéfini, nous pouvons valider tout ce qu'il produit. S'il extrait un « panneau stop » là où notre base de données cartographique n'en montre aucun, le système signale un conflit au lieu d'accepter silencieusement l'hallucination.

Une fois extraites, ces entités deviennent des nœuds dans un graphe de connaissances. Les relations deviennent des arêtes. Véhicule_A → CIRCULE_SUR → Main_Street. Véhicule_B → A_VIOLÉ → Panneau_Stop_1. Témoin_A → A_OBSERVÉ → État_Feu_Vert.

Le récit subjectif est désormais une topologie objective. Et une fois que vous disposez d'une topologie, la faute devient une question de parcours de graphe et de correspondance de motifs — et non d'analyse de sentiment.

Peut-on transformer le code de la route en code informatique ?

C'est la partie qui m'enthousiasme véritablement, et c'est celle que la plupart des gens jugent impossible.

Les règles de circulation sont rédigées en langage naturel, truffées de termes vagues comme « danger immédiat » et « distance de sécurité ». Les tribunaux les interprètent à travers la jurisprudence et le jugement. Comment rendre cela exécutable ?

La réponse est la logique déontique défaisable — DDL. La logique déontique traite des obligations, des interdictions et des permissions. « Défaisable » signifie qu'elle gère les exceptions. C'est exactement ce qu'est le code de la route : un ensemble de normes assorties d'exceptions structurées.

Prenons l'article 21802 du Code de la route de Californie, la règle du panneau stop. En langage naturel : « Le conducteur de tout véhicule s'approchant d'un panneau stop doit s'arrêter... Le conducteur doit ensuite céder la priorité à tout véhicule ayant abordé depuis une autre voie. »

Dans notre système, cela devient une logique exécutable :

Règle 1 — Obligation de s'arrêter : Si un véhicule s'approche d'une intersection dotée d'un panneau stop, le conducteur est tenu de ramener sa vitesse à zéro à la ligne d'arrêt. Si la vitesse est supérieure à zéro à l'entrée de l'intersection, c'est une infraction.

Règle 2 — Obligation de céder le passage : Si le conducteur s'est arrêté mais qu'un autre véhicule se trouve dans l'intersection ou s'en approche, le conducteur doit attendre. S'il s'engage alors que l'autre véhicule est présent et qu'une collision se produit, c'est une infraction de refus de priorité.

Règle 3 — Exception : Si un agent de police dirige la circulation, les indications de l'agent priment sur le panneau. L'exception défait formellement la règle principale.

Voici maintenant ce qui rend cela puissant. Nous confrontons le graphe physique — la reconstruction de la vitesse et de la position de chaque véhicule au fil du temps — à ce modèle logique. Si le graphe montre que le véhicule A s'est engagé dans l'intersection alors que le véhicule B était présent, le moteur de logique déclenche une infraction de refus de priorité. C'est un fait calculé, et non une opinion.

Nous ne demandons pas à l'IA « Était-ce dangereux ? » Nous calculons le danger à partir de la physique et appliquons la loi à partir de la logique. L'ambiguïté disparaît.

Pour les termes vagues comme « danger immédiat », nous les ancrons dans la physique. Nous définissons Danger_Immédiat comme un temps avant collision inférieur à 3,0 secondes, ou une distance inférieure à la distance de freinage à la vitesse actuelle. Le graphe calcule le TTC à partir des nœuds de vitesse et de distance. Si le TTC est inférieur au seuil, le nœud de danger s'active, et la règle correspondante se déclenche. Aucune interprétation n'est nécessaire.

Pour une description technique complète de notre processus de formalisation et de notre architecture, consultez notre article de recherche.

Le contrefactuel qui prouve la causalité

La faute ne concerne pas seulement la violation d'une règle. Elle concerne la causalité. Un conducteur peut avoir un permis expiré — c'est une infraction — mais s'il a été percuté à l'arrière alors qu'il était arrêté à un feu rouge, le permis expiré n'a pas causé l'accident.

C'est là que la plupart des systèmes d'IA s'effondrent. Les LLM ne savent pas raisonner de manière contrefactuelle. Ils ne peuvent pas se demander : « Cette collision se serait-elle produite si le véhicule A s'était arrêté au panneau ? » Ils ne peuvent que prédire la phrase suivante dans un récit d'accident.

Notre système construit ce que nous appelons des graphes de connaissances causaux. Pour tester la causalité, nous créons une branche contrefactuelle : nous modifions la vitesse du véhicule A pour la ramener à zéro à la ligne d'arrêt et exécutons la simulation physique en avant à travers la couche temporelle. Si le nœud de collision disparaît dans le graphe contrefactuel, l'infraction est la cause prochaine.

C'est la différence entre « il roulait trop vite et il a eu un accident » (corrélation) et « la vitesse excessive a causé l'accident » (causalité). Dans un carambolage impliquant plusieurs véhicules, cela a une importance énorme. Vous pouvez retracer les chaînes causales à travers le graphe, mesurer ce que nous appelons la « centralité de faute » — à quel point les infractions de chaque acteur sont centrales dans l'événement de collision — et produire un partage de responsabilité comparatif mathématiquement fondé. Non pas 60/40 parce que le modèle en avait l'intuition. 80/20 parce que la topologie le prouve.

Pourquoi ne pas simplement rendre les LLM plus précis ?

Les gens me posent constamment cette question. « Affinez le modèle sur le code de la route. Utilisez de meilleures invites. Ajoutez des garde-fous. » Je comprends cette impulsion. Les LLM sont faciles à déployer, et les résultats semblent impressionnants.

Mais le problème n'est pas la précision au sens traditionnel. Le problème est architectural. Un générateur de texte probabiliste ne sera jamais déterministe. Exécutez-le cent fois sur la même entrée, et vous obtiendrez des variations. Dans un domaine où les mêmes faits doivent produire le même verdict à chaque fois — où une variation de dix points dans la responsabilité représente des milliers de dollars qui changent de mains — la stochasticité n'est pas un bug à corriger. C'est un facteur d'exclusion fondamental.

Notre moteur de graphe produit exactement la même détermination de responsabilité pour exactement la même entrée, à chaque fois. Ce n'est pas un simple avantage optionnel. Pour la conformité réglementaire, pour la défendabilité juridique, pour une équité élémentaire — c'est l'exigence minimale.

L'autre objection que j'entends : « Cela semble coûteux et complexe comparé à un appel d'API. » C'est en effet plus complexe à construire. Mais considérez le coût d'une erreur. La fuite de sinistres — payer plus que ce que vous devriez en raison d'une responsabilité mal évaluée — est un poste de dépense colossal pour les assureurs. Un système probabiliste qui suggère 50/50 parce que les récits sont confus, alors qu'une logique déterministe révèle un clair 100/0 fondé sur une violation précise de priorité, coûte de l'argent réel sur chaque sinistre.

Et puis il y a le contentieux. Essayez de défendre devant un tribunal une décision de responsabilité prise par une IA lorsque le système ne peut pas expliquer son raisonnement, et que le relancer produit une réponse différente. La piste d'audit issue d'un graphe de connaissances — « Le véhicule A a violé la règle 21802(a) à l'horodatage 12:01:30, et la simulation contrefactuelle confirme cette violation comme cause prochaine » — est quelque chose de fondamentalement différent à présenter à un juge.

Le sandwich, pas la boîte noire

Je veux être clair sur un point : je ne suis pas anti-LLM. Nous utilisons des LLM. Ce sont des outils extraordinaires pour traiter le langage non structuré, et il serait insensé de l'ignorer.

Ce à quoi je m'oppose, c'est à leur utilisation comme juges.

Notre architecture est ce que nous appelons un « sandwich ». De l'IA neuronale à l'extérieur, de l'IA symbolique au milieu. La première couche neuronale gère l'ingestion — OCR sur les rapports de police, reconnaissance vocale sur les enregistrements audio des témoins, extraction d'entités à partir de données non structurées désordonnées. La couche symbolique intermédiaire construit le graphe, fusionne les données de plusieurs sources, exécute le moteur de logique déontique, réalise la simulation causale. La dernière couche neuronale retraduit le rapport de responsabilité structuré en langage naturel lisible, strictement ancré dans les faits du graphe.

Le LLM ne décide jamais. Il lit et il écrit. C'est le graphe qui raisonne.

Demander à un LLM de lire un rapport de police et de juger de la responsabilité, c'est demander à un poète de faire de la physique. Vous obtiendrez une réponse magnifique, mais ce sera probablement de la fiction.

C'est ce que le secteur commence à appeler l'IA neuro-symbolique — la fusion de l'apprentissage et de la logique. Kennedys IQ, un important cabinet de technologie juridique, a récemment lancé ce qu'il décrit comme la première solution d'IA neuro-symbolique du secteur de l'assurance, explicitement pour éliminer le problème de la « boîte noire ». La direction est claire. La question est de savoir à quelle vitesse le reste du secteur suivra.

La justice est un graphe, pas une probabilité

Je repense à cette démonstration à laquelle j'ai assisté — celle où la responsabilité a basculé de dix points entre deux exécutions — plus souvent que je ne le voudrais. Non pas parce que c'était un mauvais produit. L'équipe était talentueuse. La technologie était impressionnante. Mais impressionnant n'est pas synonyme de juste. Et dans le domaine de la faute et de la responsabilité, « presque juste » est faux.

Chaque fois qu'un système d'IA attribue une faute en fonction de qui a raconté la meilleure histoire, ou change son verdict à cause d'un réglage de température, ou cite un texte de loi qui n'existe pas — une personne réelle absorbe cette erreur. Elle paie une prime plus élevée. Elle perd un litige qu'elle aurait dû gagner. Elle porte une faute qui appartient à quelqu'un d'autre.

Nous pouvons faire mieux. Non pas en rendant les modèles de langage plus intelligents, mais en reconnaissant ce qu'ils sont et ce qu'ils ne sont pas. Ils sont brillants avec le langage. Ils sont catastrophiques avec la justice. La justice exige du déterminisme — les mêmes faits, le même verdict, à chaque fois. Elle exige l'auditabilité — montrez-moi exactement quelle preuve et quel texte de loi ont produit cette conclusion. Elle exige la capacité de maintenir un conflit non résolu et de dire « je ne sais pas encore » au lieu de générer une fiction assurée.

Ce ne sont pas des fonctionnalités que l'on ajoute à un modèle de langage. Ce sont les propriétés d'un type de système entiè­rement différent. Un système où les faits sont des nœuds immuables, les lois sont une logique exécutable, et la faute se trouve non pas dans le sentiment d'un récit mais dans la topologie de ce qui s'est réellement passé.

La justice est un graphe. Il est temps que nous commencions à la construire ainsi.