RAG en entreprise : comment connecter Claude/ChatGPT à vos données privées

TL;DR

• RAG (Retrieval-Augmented Generation) = une architecture de recherche et de génération qui répond à partir de vos données internes, pas seulement de la connaissance générale d'un LLM.
• Adapté pour : cabinets juridiques (jurisprudence + précédents internes), fiduciaires (doctrine fiscale), bureaux d'études (références projets), organismes de formation (manuels), tout knowledge worker.
• À titre de scénario budgétaire : 15–30 KCHF en cloud et 25–60 KCHF avec infrastructure dédiée, à préciser par devis après cadrage. Ces fourchettes ne sont pas des coûts clients observés.
• Prévoir les droits d’accès documentaires, la vérification des sources et des tests de réponses : une citation ne garantit pas à elle seule l’exactitude.

---

Qu'est-ce qu'un système RAG (concrètement)

Un système RAG répond à une question en deux temps :

1. Retrieval (récupération) : il cherche dans votre base documentaire les passages pertinents (contrats, notes, jurisprudence, manuels…)
2. Generation (génération) : il rédige une réponse synthétique en s'appuyant sur ces passages, avec citation des sources

À la différence de ChatGPT générique :

• Un assistant sans documents ou outil de recherche connecté s’appuie principalement sur le modèle et le contexte fourni
• RAG répond à partir de vos documents — donc avec votre terminologie, vos précédents, votre jurisprudence interne

C'est ce qui transforme l'IA d'un assistant générique en un outil d’aide à la recherche adapté à votre organisation.

Pour qui c'est pertinent

Le RAG crée le plus de valeur dans les organisations où :

• La connaissance est dispersée dans beaucoup de documents non-structurés (PDF, Word, emails, intranet)
• Les collaborateurs experts passent du temps à chercher des précédents, références, doctrine
• L'expertise se perd quand un senior part (knowledge management défaillant)
• Les juniors ont du mal à monter en compétence parce qu'ils n'ont pas accès rapidement à la mémoire de l'organisation

Cas d’usage à évaluer :

• Cabinets juridiques : RAG sur jurisprudence + précédents internes + doctrine.
• Fiduciaires : RAG sur doctrine fiscale + arrêts du TF + notes internes.
• Bureaux d'études et architectes : RAG sur réglementations (SIA, OFEN, OFEV) + projets passés + comptes-rendus de chantier.
• Organismes de formation : RAG sur manuels + supports de cours + Q&A des sessions précédentes.
• PME industrielles : RAG sur documentation produit + manuels d'utilisation + tickets SAV historiques (pour le support technique).
• Cabinets RH / paie : RAG sur CCT applicables + jurisprudence du travail + procédures internes.

Les 4 composants techniques d'un RAG

Composant 1 — L'indexation (préparer la donnée)

Vos documents (PDF, Word, intranet…) sont :

1. Découpés en chunks (passages de 500-1500 caractères)
2. Convertis en embeddings vectoriels (représentations mathématiques du sens)
3. Stockés dans une base vectorielle (Pinecone, Weaviate, pgvector…)

Le piège : la qualité du découpage impacte fortement la qualité des résultats. Découper en milieu de phrase ou ignorer les tableaux structurés tue la pertinence.

Composant 2 — Le moteur de retrieval

Quand un utilisateur pose une question :

1. La question est elle-même convertie en embedding
2. Le moteur cherche les chunks les plus similaires sémantiquement dans la base
3. Optionnel : un re-ranking peut améliorer la pertinence, à évaluer sur vos questions de référence

Appliquer les droits d’accès documentaires de l’utilisateur avant de récupérer les passages et de les transmettre au modèle. Tester aussi les révocations et les documents partagés. Contrôles documentaires.

Le piège : ne pas faire que du sémantique. Pour des termes techniques précis (références d'arrêt, codes ISO, noms de produits), un mix sémantique + recherche lexicale (BM25) donne de bien meilleurs résultats.

Composant 3 — Le LLM générateur

Les chunks retrouvés sont fournis au LLM (Claude, GPT, Mistral, Llama) en contexte, avec une instruction claire :

"Réponds à cette question en t'appuyant uniquement sur les passages fournis. Cite les sources de chaque affirmation. Si aucun passage ne couvre la question, dis-le explicitement."

Cette instruction ne garantit pas l’exactitude. Traiter les documents récupérés comme des entrées non fiables, vérifier les citations et tester les réponses sans source ou contradictoires. Limites du RAG.

Composant 4 — L'interface et les garde-fous

L'utilisateur final voit :

• La réponse synthétique
• Les sources citées (avec lien vers le document original)
• Des indications de couverture des sources, sans présenter un score comme une probabilité d’exactitude s’il n’a pas été calibré
• Un avertissement si la base est ancienne ou incomplète sur le sujet

Scénarios budgétaires indicatifs pour un RAG en PME suisse

Les montants ci-dessous sont des hypothèses de cadrage, non des résultats clients ou des tarifs universels. Volumes, droits d’accès, matériel, intégrations et exploitation doivent être chiffrés pour le projet.

Option 1 — Cloud : région et services à vérifier

Hypothèse de build : 15-30 KCHF

• Architecture, indexation initiale, calibration, garde-fous, interface
• À évaluer selon les données, les obligations de secret et les conditions des services utilisés

Run mensuel : 400-1200 CHF

• Appels au LLM (variable selon volume)
• Hosting de la base vectorielle
• Monitoring, logs

Données et responsabilités : vérifier séparément le stockage documentaire, les embeddings, le LLM, les logs et les connecteurs. La région de la ressource ne garantit pas la même région d’inférence : Azure distingue notamment les déploiements régionaux, DataZone et Global. Un DPA ne suffit pas à établir la conformité du traitement. Conditions Azure, PFPDT : sous-traitance.

Chez Claude commercial, le routage régional ne signifie pas un stockage européen ; chez Mistral, certaines fonctionnalités peuvent transférer des données hors UE. Vérifier le produit et les fonctions retenus. Localisation Claude, Localisation Mistral.

Option 2 — On-premise (modèle ouvert compatible avec l’infrastructure locale)

Hypothèse de build : 25-60 KCHF

• Tout ce qui est dans l'option 1, plus l'installation et la configuration de l'infra dédiée
• À évaluer lorsque les données ou les contrats nécessitent davantage de contrôle local, avec les moyens d’exploitation correspondants

Infrastructure : 8-15 KCHF one-shot (serveur GPU dédié), puis 200-500 CHF/mois en run + maintenance.

Maintenance évolutive : 5-12 KCHF/an (re-indexation, mise à jour des modèles, sécurité).

Données et responsabilités : une architecture locale peut limiter les flux externes si l’OCR, les embeddings, la recherche et le LLM fonctionnent localement. Vérifier aussi les logs, la télémétrie, les sauvegardes, le support et les connecteurs ; le seul hébergement on-premise ne prouve ni l’absence de sortie de données ni la conformité.

Points de vigilance (et comment les traiter)

Piège 1 — Hallucinations de sources

Sans contraintes strictes, le LLM peut inventer des références (un arrêt du TF qui n'existe pas, un article de loi inexistant). En contexte juridique ou fiscal, c'est inacceptable.

Solution : politique de réponse stricte. "Si aucune source n'est trouvée, refuse de répondre." Implémenter un vérificateur post-génération qui valide que toutes les références citées existent réellement dans la base.

Piège 2 — Base documentaire sale

Si votre base contient des doublons, des versions obsolètes, des documents contradictoires — le RAG va vous renvoyer du bruit ou des conseils contradictoires.

Solution : nettoyage et structuration de la base avant indexation. Identifier la version "source de vérité" pour chaque type de document.

Piège 3 — Pas de gestion de la fraîcheur

La jurisprudence évolue. La doctrine fiscale aussi. Un RAG qui répond avec un arrêt cassé en appel l'année dernière est dangereux.

Solution : pipeline de re-indexation régulier (quotidien, hebdo selon vitesse de changement) + métadonnées de date sur chaque document + avertissement automatique quand la source la plus pertinente date de > X mois.

Piège 4 — Sur-estimation de l'autonomie

Un RAG n'est pas un avocat, ni un fiscaliste, ni un médecin. Il est un outil de productivité pour les experts humains. La signature et la responsabilité restent humaines.

Solution : positionner le RAG comme un outil d'aide à la recherche, pas comme un système de décision. La validation et les responsabilités doivent rester explicitement définies.

Piège 5 — Ignorer la formation des utilisateurs

La qualité d'un RAG dépend en grande partie de la formulation de la question.

Solution : workshop d'1-2h sur "comment poser la bonne question" en début d'usage.

Exemple indicatif de déploiement (cabinet 10-30 personnes)

Ces phases sont un exemple à adapter après cadrage et pilote, selon la qualité documentaire, les droits d’accès, les intégrations et les validations.

Mois 1 — Cadrage et architecture

• Audit documentaire (volume, types, qualité, sensibilité)
• Choix architecture : cloud EU vs on-premise
• Choix du LLM (Mistral, Claude, GPT, Llama)
• Définition des garde-fous métier

Mois 2-3 — Build et indexation

• Installation infrastructure
• Pipeline d'ingestion de la base documentaire
• Calibration du retrieval (test sur 50-100 questions étalon)
• Interface utilisateur + connexion aux outils existants (Outlook, intranet)

Mois 4 — Formation et adoption

• Formation 4-6h sur 2 sessions
• Workshop "bons prompts" par métier
• Pilote sur une cohorte de 5-10 utilisateurs avant rollout
• Hypercare 30 jours

Mois 5+ — Run et amélioration continue

• Monitoring qualité (taux de pertinence, taux d'escalade)
• Enrichissement progressif de la base
• Itérations sur les prompts et les garde-fous

FAQ

Quelle différence entre un RAG et un fine-tuning ? Le fine-tuning adapte le comportement du modèle ; le RAG apporte des contenus récupérés au moment de la requête. Les deux répondent à des besoins différents et peuvent être combinés.

Quels documents peut-on indexer ? PDF (incluant les scans avec OCR préalable), Word, PowerPoint, HTML, Markdown, emails, transcriptions audio. Les tableaux et données structurées (Excel, bases de données) demandent un traitement spécifique.

Quel volume de données un RAG peut-il gérer ? De quelques milliers à plusieurs millions de documents. Le coût et la complexité augmentent avec le volume, et doivent être testés sur l’architecture retenue.

Combien de temps pour mettre en place un RAG en production ? Le délai dépend de la préparation documentaire, des droits d’accès, des intégrations et des validations. Établir le calendrier après cadrage et pilote ; les phases présentées sont indicatives.

Mes données restent-elles confidentielles ? La confidentialité dépend de l’architecture et des accès réels. Cartographier tous les services qui reçoivent documents, questions, passages et réponses ; vérifier conservation, entraînement, transferts et contrats. Tester les droits documentaires avant de transmettre les passages au modèle. Hébergement UE, DPA et on-premise ne constituent pas, isolément, une garantie. PFPDT.

Pour aller plus loin

• Voir un scénario illustratif : RAG juridique pour un cabinet genevois
• Audit IA PME — la check-list 2026
• Voir notre service Agents IA sur mesure
• Diagnostic gratuit 60 min