L'IA qui lit les dossiers d'assurance comme un expert : la révolution des tables relationnelles

UN DOSSIER D'ASSURANCE, C'EST COMME UNE LISTE DE COURSES POUR UN MÉCANICIEN

Imaginez un dossier d'assurance avec onze PDF différents : une déclaration de sinistre, un rapport d'expert, deux devis de réparation, une facture, des photos de dégâts, et bien d'autres documents disparates. Aucun ne se ressemble, et pourtant, ils parlent tous du même événement. L'intelligence artificielle classique va chercher dans ces documents des mots-clés, comme si elle feuilletait un catalogue. Mais le vrai travail, c'est de comprendre ce qui manque ou ce qui cloche dans ce puzzle.

Prenons un exemple concret : un atelier de menuiserie incendié le 12 mars. L'assureur doit vérifier deux choses : le rapport des pompiers est-il présent ? Et la date du sinistre sur la déclaration correspond-elle à celle du rapport de l'expert ? Ces questions ne sont pas des recherches de documents. Ce sont des questions sur l'absence ou l'incohérence entre des éléments précis. Et aucun modèle d'IA ne peut y répondre simplement en lisant des passages au hasard.

POURQUOI LES FENÊTRES DE CONTEXTE DES MODÈLES D'IA NE SUFFISENT PAS

Les modèles d'IA comme ceux d'OpenAI ou Mistral ont des fenêtres de contexte de plus en plus grandes. La tentation est forte : mettre tout le dossier dans le prompt et laisser le modèle trouver les réponses. Avec onze PDF totalisant une soixantaine de pages, cela tient largement dans une fenêtre de 200 000 tokens. Pourtant, le modèle va échouer sur les deux questions clés de l'assureur.

Pourquoi ? Parce que ces questions ne sont pas des recherches. La première porte sur un document qui n'existe pas : le rapport des pompiers. Aucune quantité de texte ne peut répondre à une absence. La seconde demande de comparer deux valeurs précises : la date du sinistre sur la déclaration et celle dans le rapport de l'expert. Ces deux dates se trouvent au milieu des documents, là où les modèles lisent moins bien. Dans un dossier de onze fichiers, les informations utiles sont noyées dans la masse.

Le problème n'est pas la qualité du modèle, mais la nature du dossier. Un dossier d'assurance est un ensemble hétéroclite : des contrats en tableaux, des rapports en prose, des photos sans texte, des factures avec des chiffres. Aucune structure ne domine. Et les réponses viennent de la comparaison entre ces éléments, pas de leur lecture isolée.

LA SOLUTION : UNE LISTE DES PIÈCES ATTENDUES AVANT MÊME D'OUVRIR UN DOSSIER

La clé, c'est de ne plus partir des documents, mais d'une liste prédéfinie. Avant même d'ouvrir le moindre PDF, il faut savoir ce qu'un dossier de sinistre doit contenir. Pour un sinistre incendie, par exemple, il faut :

• • Une déclaration de sinistre
• • Un certificat de police en vigueur
• • Une preuve de paiement de la prime
• • Un rapport d'expert
• • Au moins un devis de réparation
• • Une facture pour chaque devis accepté
• • Des photographies des dégâts
• • Un rapport des pompiers si le sinistre est un incendie

Cette liste ne vient pas des documents, mais du processus métier. Elle est écrite par quelqu'un qui vérifie manuellement ces dossiers tous les jours. C'est une liste de rôles attendus, pas de fichiers existants. Certains éléments sont obligatoires, d'autres optionnels. Certains ne sont requis que sous conditions, comme le rapport des pompiers pour un incendie.

Voici comment cette liste est structurée en code (en Python) :

class ExpectedPiece(BaseModel):
    """Une ligne de ce qu'un type de dossier exige, qu'il soit présent ou non."""
    role: str                  # le terme métier : "rapport d'expert"
    min_count: int             # 0 si la pièce est optionnelle
    max_count: int | None      # None si n'importe quel nombre est acceptable
    required_when: str | None  # une condition sur les champs du dossier
    blocks_payment: bool       # le dossier peut-il avancer sans cette pièce ?

PROPERTYDAMAGECLAIM = [
    ExpectedPiece(role="déclaration de sinistre", mincount=1, maxcount=1,
                  requiredwhen=None, blockspayment=True),
    ExpectedPiece(role="rapport des pompiers", mincount=1, maxcount=1,
                  requiredwhen="causedu_sinistre == 'incendie'",
                  blocks_payment=True),
    ExpectedPiece(role="facture de réparation", mincount=1, maxcount=None,
                  requiredwhen="devisacceptés >= 1",
                  blocks_payment=True),
    ExpectedPiece(role="correspondance", mincount=0, maxcount=None,
                  requiredwhen=None, blockspayment=False),
]

Cette structure permet de vérifier systématiquement si un dossier est complet. Elle évite les fausses alertes : un rapport des pompiers n'est pas requis pour un dégât des eaux, donc la liste ne va pas se plaindre sur chaque dossier qui n'est pas un incendie.

LE VÉRIFICATEUR DE COMPLÉTUDE : TROIS RÉSULTATS POSSIBLES POUR CHAQUE PIÈCE

Avec cette liste et les onze fichiers d'un dossier, le vérificateur de complétude produit trois types de résultats :

Dans notre exemple d'atelier incendié :

• • Sept rôles sur neuf sont présents (déclaration, certificat, preuve de paiement, rapport d'expert, devis, facture, photos).
• • Deux rôles manquent : le rapport des pompiers (car le sinistre est un incendie mais aucun rapport n'est présent) et la deuxième facture de réparation (car deux devis ont été acceptés mais une seule facture est arrivée).
• • Un fichier est non apparié : un calendrier de véhicule appartenant à une autre police, glissé par erreur dans le dossier.

Le vérificateur ne se contente pas de dire