Exemple illustratif : RAG pour la recherche juridique d’un cabinet genevois

TL;DR

• Contexte hypothétique : cabinet juridique genevois d’environ 15 personnes, spécialisé en droit des affaires et droit du travail
• Problème : recherches longues sur jurisprudence, conventions collectives et précédents internes
• Solution envisagée : système RAG (Retrieval-Augmented Generation) on-premise sur la base documentaire du cabinet + jurisprudence publique
• Objectif à évaluer : réduire le temps de recherche sans dégrader la vérification des sources ni les droits d’accès

Note : scénario hypothétique pour expliquer une architecture RAG juridique. Il ne décrit pas une livraison client vérifiée et ne présente pas de résultats mesurés. Effectif, budget, durée et composants techniques sont des hypothèses à valider après cadrage ; la stack décrite est envisagée.

Hypothèses du scénario

Imaginons un cabinet juridique de taille intermédiaire à Genève, ~15 personnes (8 avocats inscrits + paralegals + administratif), spécialisé en droit des affaires (M&A, contrats commerciaux internationaux) et droit du travail (contentieux RH, CCT).

Le point de départ serait de mesurer le temps consacré aux recherches de référence avant le pilote :

• Jurisprudence du Tribunal fédéral et des tribunaux cantonaux pertinents
• Doctrine (commentaires, articles) sur la question
• Précédents internes du cabinet (notes de recherche, mémoires, accords transactionnels antérieurs)
• Pour le droit du travail : conventions collectives applicables (CCT) et règlements internes

Dans ce scénario, les recherches pourraient mobiliser les paralegals et les avocats. Le cadrage vérifierait quels documents internes sont utiles, à jour et accessibles aux personnes concernées.

Architecture et déploiement envisagés

Un calendrier indicatif de 10 semaines serait à valider après cadrage, selon la préparation documentaire et les exigences de confidentialité et de secret professionnel.

Phase 1 — Diagnostic et architecture

• Cartographie des 6 types de recherches récurrentes (jurisprudence TF, jurisprudence cantonale, doctrine, précédents internes, CCT applicables, contrats types)
• Option étudiée : traitements locaux pour les données confidentielles, sous réserve de vérifier OCR, embeddings, LLM, logs, sauvegardes, télémétrie et connecteurs
• Modèle LLM local envisagé pour les données confidentielles ; des données publiques pourraient être traitées par un service externe après validation des flux

Phase 2 — Build (durée indicative : 7 semaines)

Composants envisagés :

• Indexation : documents autorisés et sources publiques pertinentes, avec gestion des droits et des versions. Les passages transmis au modèle doivent provenir de documents que l’utilisateur est autorisé à consulter ; tester les accès et révocations avant mise en service

• Pipeline d’ingestion : ré-indexation incrémentale à prévoir, avec tests de suppression, de modification et de révocation ; certains changements peuvent nécessiter une reconstruction de l’index

• Interface conversationnelle envisagée : pour une question en langage naturel, présenter :

  1. Une synthèse rédigée en français juridique
  2. Les sources citées, avec références permettant leur vérification (arrêt et considérant, ou note interne avec auteur et date)
  3. Des indications de couverture et de fraîcheur des sources, à vérifier ; pas de score présenté comme probabilité d’exactitude sans calibration

• Garde-fous critiques :

  • Politique de refus en absence de source à implémenter et tester
  • Dates et statut des sources à contrôler ; une règle d’âge ne suffit pas à déterminer leur validité
  • Journalisation proportionnée, accès restreints, durée de conservation définie et minimisation des contenus confidentiels

Phase 3 — Adoption

• Hypothèse de formation : 6h pour une cohorte de 8 avocats, à adapter selon leurs besoins
• Workshop spécifique sur "comment poser la bonne question au système" (la formulation impacte fortement la qualité)
• Intégration Outlook à étudier et tester

Mesures à collecter pendant un pilote

Aucun résultat client mesuré n’est présenté dans ce scénario. Un pilote devrait comparer :

• Le temps de recherche et de relecture sur des dossiers comparables
• La pertinence et l’exactitude des passages et citations, évaluées par des juristes
• La couverture des documents internes autorisés et la fraîcheur des sources
• Les réponses sans source, les refus attendus, les citations erronées et les tentatives d’accès non autorisé

La présence d’une citation ne garantit pas sa validité ni l’exactitude de la réponse. Définir les critères d’acceptation avant le pilote et conserver la validation humaine.

Points à valider

1. Citations et politique de refus : tester les sources, les réponses contradictoires et l’absence de source ; une instruction seule ne garantit pas l’exactitude.
2. Rôles et validation : définir le travail des juristes, la relecture et les responsabilités avant le pilote.
3. Budget local et cloud : comparer à périmètre, droits d’accès et exploitation équivalents, sans supposer un rapport de coût universel.

Microsoft : limites du RAG et droits documentaires, PFPDT : secret, sécurité et responsabilités.

Vous êtes un cabinet juridique romand ?

Des scénarios comparables peuvent être étudiés pour : cabinets de notaires, fiduciaires sur la veille fiscale, cabinets d'experts-comptables sur la doctrine, et tout métier où la connaissance est dispersée dans des documents non-structurés.

Diagnostic gratuit 60 min : on identifie ensemble les recherches récurrentes qui justifient un système RAG, et celles qui ne valent pas la peine.