Utiliser l'IA pour démêler 10 000 titres de propriété brésiliens : une étude de cas technique

Contexte du projet et problème

Une entreprise immobilière brésilienne a hérité d'environ 10 000 titres de propriété répartis sur plus de 10 municipalités, après des décennies de mauvaise gestion. Les données comprennent des centaines de "contrats de tiroir" non enregistrés (ventes informelles jamais déposées), des ventes en double des mêmes propriétés, des contrats frauduleux, des procurations falsifiées, des occupations irrégulières et environ 500 procès en cours, incluant des revendications de prescription acquisitive, des adjudications forcées, des expulsions, des litiges sur des ventes en double et 2 actions collectives. Les archives physiques des documents sont partiellement détenues par la police dans le cadre d'une ancienne enquête.

Approche technique

L'équipe (6 avocats + 3 opérateurs) a décidé de ne pas construire d'infrastructure au préalable, optant plutôt pour une approche de découverte d'abord avec l'aide de l'IA. Le plan comprend cinq étapes :

• Étape 1 - Numérisation physique : Les documents sont organisés par municipalité, numérisés par lots avec la convention de nommage : [municipalité]_[type-de-document]_[séquence] à l'aide d'un scanner de documents avec chargeur automatique (ADF).
• Étape 2 - OCR : Envisage Google Document AI, Mistral OCR 3, AWS Textract ou d'autres outils. L'équipe sollicite des retours sur des outils spécifiquement testés sur des documents dégradés des registres latino-américains.
• Étape 3 - Découverte : Envoi direct de la sortie OCR dans des outils d'IA avec de grandes fenêtres de contexte pour une analyse ouverte avant la mise en place de la base de données. Utilisation de Gemini 3.1 Pro (dans NotebookLM ou une autre interface) pour une analyse large par lots avec des invites comme "quels lots semblent liés à plus d'un acheteur ?", "signaler les contrats avec des dates incohérentes", "identifier des groupes de noms ou d'activités suspects" et "aidez-nous à voir les problèmes et solutions pour ce que nous ne voyons pas". Exécution de projets Claude en parallèle pour une analyse similaire.
• Étape 4 - Nettoyage et standardisation des données : Normalisation des données brutes extraites avant insertion dans la base de données. Traitement des noms de municipalités écrits de multiples façons ("B. Vista", "Bela Vista de GO", "Bela V. Goiás") pour les ramener à une forme canonique, standardisation des CPF (numéros d'identification personnelle brésiliens) avec et sans ponctuation, correction des descriptions incohérentes du statut des lots pour les catégoriser, et appariement flou des noms d'acheteurs avec des variations orthographiques. Outils : Python + rapidfuzz pour l'appariement flou, API Claude pour normaliser les champs de texte libre en catégories. L'équipe se demande si l'appariement flou + la normalisation par LLM est suffisant pour 10 000 enregistrements avec des décennies d'incohérences ou s'ils ont besoin d'une résolution d'entités plus rigoureuse (par exemple, Dedupe.io).
• Étape 5 - Base de données : Pile choisie : Supabase (PostgreSQL + pgvector) avec NocoDB par-dessus. Trois options ont été évaluées : Airtable (le plus facile à démarrer mais limité à grande échelle), PostgreSQL direct (le plus de contrôle mais itération plus lente), et Supabase + NocoDB (choisi comme compromis).

L'objectif est d'obtenir une image consolidée réelle en 30 à 60 jours, évitant les précédentes tentatives d'organisation infructueuses.