Un détecteur d’irrégularités dans les contrats de crédit, sans transfert des données hors du cabinet

Le client et son problème

Un cabinet d’avocats. Après un arrêt très médiatisé concernant des contrats de crédit, une vague de dossiers est arrivée : les contrats de nouveaux clients affluaient. Chacun compte plusieurs dizaines de pages, alors que seules quelques valeurs et clauses sont réellement déterminantes. L’examen manuel d’un contrat prend beaucoup de temps à un avocat. Face à un tel volume, le choix était simple : trouver un moyen de trier rapidement les dossiers ou commencer à refuser des clients.

L’idée naturelle est de soumettre le contrat à un modèle de langage et de lui demander s’il contient une irrégularité. Mais cette approche se heurte à quatre contraintes au sein d’un cabinet.

La première, et la plus importante : les données personnelles des clients ne peuvent pas quitter le serveur du cabinet. Un contrat de crédit contient le nom, le numéro PESEL, l’adresse, le numéro de compte et l’historique complet des engagements d’une personne. Transmettre ces informations à un service externe est inacceptable dans ce contexte ; les assurances du fournisseur n’y changent rien. C’était une exigence incontournable du projet, pas une préférence à discuter.

Deuxième exigence : le verdict doit être reproductible. Un avocat ne peut pas fonder un acte de procédure sur le fait que le modèle a conclu cette fois qu’il y avait une irrégularité. Le même contrat soumis deux fois doit donner le même résultat, que l’on doit pouvoir expliquer.

Troisième contrainte : les contrats arrivent sous toutes les formes. PDF numérique, scan imprimé ou photo prise au téléphone. Le système doit les traiter et distinguer un contrat de crédit d’un fichier chargé par erreur.

Quatrième contrainte : le droit évolue. Après de nouveaux arrêts, la logique de détection doit pouvoir être actualisée en quelques heures, et non à la faveur d’une prochaine refonte importante.

Ce que nous avons fait

Nous avons commencé par l’emplacement du système. Tout fonctionne sur le serveur du cabinet, dans des conteneurs Docker gérés avec Coolify ; rien n’a donc besoin de sortir vers l’extérieur. Le cabinet peut connecter son propre abonnement à un modèle, sans dépendre d’un fournisseur unique ni de notre compte. La couche d’agents prend en charge quatre moteurs de modèles, dont Claude et Codex ; passer de l’un à l’autre demande un changement de configuration, pas une réécriture du système.

Avant que le moindre document arrive au modèle, il est traité localement. Les scans et les photos passent par l’OCR pour devenir lisibles. Les données personnelles sont ensuite anonymisées sur place. L’agent ne reçoit que des montants, des dates et des extraits de clauses. Il ne sait pas à qui appartient le contrat, car cette information ne lui est pas nécessaire pour évaluer une irrégularité. C’est le principe central de la solution : les données personnelles ne quittent pas le serveur du cabinet, et le modèle travaille sur un contenu qui ne permet pas de retrouver le client.

Nous avons délibérément retiré le verdict des mains du modèle. Une logique déterministe distincte détecte les irrégularités et calcule la réclamation à partir des valeurs extraites du document. Le modèle sert à lire le contrat, pas à rendre un jugement. Le résultat peut ainsi être reproduit ; lorsqu’une décision de justice change, nous modifions les règles, pas les prompts. Le calculateur présente la valeur de la réclamation selon trois scénarios, du plus prudent au plus favorable, afin que l’avocat voie une fourchette plutôt qu’un chiffre sorti de nulle part.

Une file de tâches Supabase coordonne le traitement par lots. Nous avons également ajouté la génération d’actes et le suivi de la jurisprudence, avec actualisation des règles après de nouveaux arrêts.

Le fonctionnement aujourd’hui

Il a fallu quatre jours ouvrés pour produire une version opérationnelle. Le cabinet charge les contrats depuis un navigateur, individuellement ou par lots. Chacun suit le même parcours : vérification qu’il s’agit bien d’un contrat de crédit, OCR si nécessaire, anonymisation, extraction des valeurs, évaluation selon les règles et calcul de la réclamation dans trois scénarios. L’avocat reçoit une liste de dossiers avec les résultats et les fourchettes, au lieu d’une pile de documents à lire.

Tout s’exécute sur le serveur du cabinet. Nous avons conçu la solution comme un produit, et non comme une intégration ponctuelle : la déployer de la même façon pour un autre cabinet est donc reproductible.

Résultats

Le système traite 200 contrats en un après-midi. Aucune donnée personnelle ne quitte le serveur du cabinet. Le calculateur estime la valeur de la réclamation selon trois scénarios. Les contrats peuvent être importés en PDF ou en scan, car l’OCR est intégré.

Ce que nous ferions autrement

Nous avons sous-estimé la qualité des documents en entrée. Un scan pris au téléphone de travers, avec une ombre au milieu de la page, peut faire échouer l’OCR ; la meilleure logique n’a alors plus rien à calculer. La prochaine fois, dès le premier jour, le système signalera clairement qu’un document est illisible et demandera un meilleur fichier, au lieu d’essayer de deviner.

Deuxième point : l’anonymisation. La placer dans une étape distincte avant le modèle était une bonne décision, mais nous avons ajouté ses tests plus tard qu’il aurait fallu. Dans un système dont toute la promesse repose sur la non-divulgation des données, cette étape mérite sa propre suite de tests dès le début.

Enfin, les règles juridiques devraient être conservées dans un format qu’un avocat peut lire et contester sans notre intervention.