Comment Atlas Légal a divisé par trois le temps de recherche de ses juristes.

On a commencé par regarder comment travaillaient vraiment les juristes.

Atlas Légal, c’est 25 personnes, 15 juristes, et 8 200 documents accumulés en 12 ans : contrats types, avis juridiques, notes de jurisprudence, correspondances clients. Tout ça réparti entre un NAS, SharePoint et les boîtes mail de l’équipe.

Le problème : un juriste passait en moyenne 45 minutes par recherche pour retrouver un précédent pertinent. Multiplié par 8 à 10 recherches par jour, ça représentait 30 % du temps de travail perdu à fouiller au lieu de raisonner.

Le managing partner avait essayé deux solutions :

• Un moteur de recherche plein texte sur le NAS — trop de bruit, pas de contexte
• ChatGPT directement — hallucinations sur les références juridiques belges

Aucune des deux ne convenait. Il fallait un outil qui comprenne le contexte juridique et qui cite ses sources dans les documents internes.

Trois surfaces, un seul cerveau.

On a livré un système RAG accessible de trois façons, toutes connectées à la même base de connaissances vectorielle :

Chat web — Interface principale. Les juristes posent leur question en langage naturel, le système cherche dans les 8 200 documents et formule une réponse avec les extraits pertinents et les liens vers les sources originales.

Plugin Word — Un panneau latéral dans Microsoft Word. Le juriste rédige son avis, sélectionne un passage, et demande “Trouve-moi les précédents pertinents pour ce point”. Les résultats s’insèrent directement dans le document.

Chat interne — Un canal dédié dans Teams pour les questions rapides entre collègues. Le bot répond avec les mêmes sources, et les échanges sont archivés pour enrichir la base de connaissances.

L’architecture en détail

Le pipeline technique :

1. Ingestion : les 8 200 documents sont extraits (PDF, Word, emails) via un pipeline n8n qui tourne toutes les nuits pour capter les nouvelles pièces
2. Chunking : découpage intelligent par section juridique (pas par nombre de tokens brut) pour préserver le contexte des clauses et articles
3. Embeddings : vectorisation via le modèle text-embedding-3-large d’OpenAI, stocké dans Qdrant
4. Retrieval : recherche hybride (sémantique + BM25) pour combiner la pertinence contextuelle et la correspondance exacte des termes juridiques
5. Generation : Claude 3.5 Sonnet avec un prompt système calibré pour le droit belge — instructions strictes de ne jamais inventer de référence

Les chiffres après 30 jours

On a mesuré les performances sur un mois complet d’utilisation par les 15 juristes :

• Le temps moyen par recherche est passé de 45 minutes à 14 minutes (-68 %)
• Le nombre de recherches abouties par heure a été multiplié par 3,2
• Sur 500 réponses auditées manuellement, le taux d’hallucination est de 1,4 % (7 réponses sans source valide)
• Les 3 erreurs restantes concernaient des documents mal formatés à l’ingestion — corrigées depuis

Quelques moments clés du projet

Semaine 1-2 : audit de la documentation existante. On a découvert que 30 % des fichiers étaient des doublons ou des versions obsolètes. Le nettoyage initial a été le plus gros investissement en temps.

Semaine 3-4 : développement du pipeline RAG et premiers tests avec 500 documents. Le chunking par section juridique (au lieu du chunking par tokens) a été la décision technique la plus impactante.

Semaine 5-6 : déploiement du chat web auprès de 5 juristes pilotes. Ajustements du prompt système pour réduire les réponses trop génériques.

Semaine 7-8 : déploiement complet + plugin Word + intégration Teams. Formation de 1h pour l’ensemble de l’équipe.

Ce qu’on ferait différemment

• Commencer par le nettoyage des données plutôt que par le développement. On aurait gagné une semaine.
• Tester le chunking plus tôt — la granularité du découpage est le facteur n°1 de qualité des réponses.
• Prévoir un dashboard de monitoring dès le jour 1 — on l’a ajouté en semaine 6, mais il aurait été utile dès les tests pilotes.