Le défi
Les professionnels du droit cherchaient dans des dizaines de milliers de décisions en français avec des outils par mots-clés qui passaient à côté du sens, du contexte et des précédents. Trouver la bonne décision, et les appels qui ont suivi, prenait des heures.
Les documents contenaient des données personnelles sensibles, y compris sur des mineurs : rien ne pouvait être indexé ni affiché sans une anonymisation rigoureuse. L’accès devait être contrôlé par rôle, et la plateforme devait respecter les conventions du droit des affaires OHADA dans plusieurs juridictions.
50K+ décisions· < 2 s· BM25 + vecteurs· réponses citées
- Cour d’appel · Commercial0.94
…la juridiction relève que [PARTIE A] a procédé à la résiliation du bailsans préavis, en méconnaissance de l’Acte uniforme OHADArelatif au droit commercial général…
[1] Arrêt n° ••• · chaîne d’appel ↗
- Tribunal de commerce · Bail0.86
…[PARTIE B], preneur, sollicite des dommages-intérêts pour rupture abusive…
Architecture · 6 étapes
- 01
Ingestion
Extraction PDF/Word, découpage selon la structure
- 02
Masquage
Anonymisation à triple recherche, règles pour les mineurs
- 03
Conformité
Règles OHADA et confidentialité, RBAC à trois niveaux
- 04
Indexation
Elasticsearch à triple index + vecteurs Pinecone
- 05
Recherche
Fusion hybride BM25 + dense, filtres de métadonnées
- 06
Génération
Réponses sourcées et rédaction de documents
La solution
J’ai conçu et construit la plateforme de bout en bout. Un pipeline d’ingestion en plusieurs étapes extrait le texte des fichiers PDF et Word et applique un découpage tenant compte de la structure, avec chevauchement, pour ne pas couper un raisonnement juridique en plein argument.
La recherche s’appuie sur une couche Elasticsearch à triple index (sémantique, métadonnées et chaîne d’appels) associée à la recherche vectorielle Pinecone. La fusion du score BM25 et des vecteurs denses a amélioré la précision de récupération de 15 % par rapport à chaque méthode seule.
Un moteur d’anonymisation basé sur Claude, avec une architecture à triple recherche, détecte et masque les données personnelles avant toute indexation, avec des protections dédiées aux mineurs et aux parties vulnérables. Un RBAC à trois niveaux contrôle qui voit quoi, et un module de génération rédige des documents juridiques à partir des précédents retrouvés.
La conformité est appliquée par le pipeline, pas par une politique : aucun document n’atteint l’index ni le modèle sans passer d’abord par l’anonymisation, donc 100 % du contenu indexé est protégé par construction. Les conventions OHADA et les règles de confidentialité multi-juridictions sont appliquées dès l’ingestion, et chaque accès est limité par rôle.
Chaque changement d’architecture a été validé sur un jeu d’évaluation de 200 questions construit avec un avocat en exercice, ce qui a permis de détecter les régressions avant qu’elles n’atteignent les utilisateurs.
Points forts techniques
- Recherche hybride BM25 + vecteurs, 15 % plus précise que chaque méthode seule
- Elasticsearch à triple index : sémantique, métadonnées et chaîne d’appels
- Anonymisation à triple recherche : 98 % de détection, protection des mineurs
- Conformité par conception : 100 % des documents anonymisés avant indexation
- Règles OHADA et de confidentialité multi-juridictions appliquées à l’ingestion
- Jeu d’évaluation de 200 questions construit avec un avocat pour chaque version
- Contrôle d’accès par rôle (RBAC) à trois niveaux
- Génération de documents par IA : temps de rédaction réduit de 80 %
- Environ 23 endpoints REST documentés pour l’intégration
Technologies
- Python
- Flask
- Claude API
- OpenAI
- Pinecone
- Elasticsearch
- Docker
- REST API
Un projet similaire ?
Obtenez un avis franc sur l’architecture, les risques et le calendrier lors d’un appel gratuit de 30 minutes, ou demandez à l’assistant IA comment cette approche s’appliquerait à votre projet.