Un chatbot souverain pour l'entreprise : RAG, RGPD, local

Un chatbot interne n'a pas besoin d'un service américain pour répondre aux questions des collaborateurs. Hébergé sur vos machines et branché sur vos sources, il reste à l'intérieur du périmètre de l'entreprise.

Par QDNA · Publié le 16 juillet 2026 · 8 min de lecture

Le cas d'usage : un ChatGPT interne qui connaît votre métier

Une direction métier demande un assistant capable de répondre aux questions des équipes sur les procédures internes, les contrats, la documentation technique ou la base de connaissances. L'attente concrète tient en une phrase : un ChatGPT qui connaît notre entreprise, et qui ne parle pas à quelqu'un d'autre.

Cette attente recouvre trois exigences. Premièrement, l'outil doit citer ses sources et s'appuyer sur les documents internes, pas sur une mémoire générale approximative. Deuxièmement, les questions des collaborateurs, les documents indexés et les réponses produites doivent rester dans le périmètre de l'entreprise. Troisièmement, l'outil doit fonctionner sans dépendance à un service tiers qui journaliserait les échanges ou les utiliserait pour entraîner ses modèles.

Un chatbot souverain répond à ces trois exigences. Le modèle tourne sur une machine de l'entreprise, l'index des sources internes est reconstruit en local, et le filtrage des requêtes bloque toute fuite vers un fournisseur extérieur. La conversation reste privée, l'indexation reste privée, l'inférence reste privée.

Pourquoi le cloud public ne convient pas pour ce cas d'usage

Les offres SaaS conversationnelles présentent plusieurs limites pour un usage métier interne. La politique de l'éditeur s'applique aux données soumises : selon les conditions générales, les entrées peuvent être journalisées, conservées, et parfois réutilisées pour l'amélioration des modèles. Le règlement européen sur la protection des données classe cette pratique comme un transfert vers un sous-traitant situé hors Union, ce qui oblige à une analyse d'impact et à des clauses contractuelles spécifiques.

Le risque de fuite ne se limite pas à la console d'administration. Les invites saisies par les collaborateurs circulent vers les datacenters de l'éditeur, transitent par des points de présence internationaux, et subissent les obligations juridiques locales du fournisseur. Pour des contenus sensibles, comme des dossiers clients, des données RH, des pièces contractuelles ou des secrets industriels, cette chaîne de traitement expose l'entreprise à un risque qu'aucune mesure technique côté client ne permet de neutraliser.

Un modèle ouvert servi sur une machine de l'entreprise inverse le raisonnement. Les données ne quittent pas le réseau interne. L'opérateur reste seul maître du chiffrement, de la journalisation, de la rétention et de la purge. La conformité au règlement européen se démontre par construction, et non par accumulation de clauses contractuelles.

Le RAG : brancher le chatbot sur les sources internes

Le modèle seul ne connaît pas votre entreprise. La génération augmentée par récupération, ou RAG, complète la réponse du modèle avec des passages extraits en temps réel d'un index de documents. L'indexation reconstruit cet index à partir des sources internes : serveur de fichiers, wiki, base documentaire, gestion électronique des documents, messagerie archivée.

Cette chaîne présente un avantage pratique pour les directions métier. Le chatbot ne se contente pas de répondre, il cite les documents dont il s'inspire. Une procédure interne obsolète peut ainsi être détectée par les équipes et mise à jour, plutôt que propagée par un modèle qui ne dispose d'aucune référence temporelle. La pertinence progresse avec la qualité de l'index, et l'index s'enrichit au fil des contributions.

L'architecture derrière le chatbot

L'architecture QDNA reprend les briques décrites sur le site : modèles ouverts, runtime vLLM ou llama.cpp, passerelle LiteLLM et routeur sémantique. La fiche matériel précise les configurations par segment.

Le modèle ouvert sert l'inférence. GLM 5.2, DeepSeek V4, Mistral Large et Qwen 3.6 couvrent les besoins du quotidien, et Mistral Magistral, Nemotron 3 Ultra ou GLM 5.2 en mode raisonnement traitent les questions complexes. Le runtime vLLM sert les grands modèles sur GPU NVIDIA avec gestion fine du cache clé-valeur, et llama.cpp ou MLX prend le relais sur les configurations plus compactes, notamment Mac Studio et DGX Spark.

La passerelle LiteLLM présente une interface unique à l'application de chat. Les alias de modèles, les clés virtuelles par utilisateur et le routage par coût s'y configurent une fois pour toutes, et l'application n'a pas à connaître la liste des modèles disponibles. Le routeur sémantique classe la requête avant LiteLLM : par similarité d'embeddings, il distingue le contenu confidentiel du contenu public, et oriente la demande vers un modèle souverain local ou vers un modèle externe quand le sujet s'y prête. Ce filtrage prévient la fuite de données par construction, sans intervention de l'utilisateur.

L'ensemble forme une chaîne reproductible : indexation des sources, classification de la requête, sélection du modèle, inférence, citation des sources, journalisation interne. Chaque maillon reste sur l'infrastructure de l'entreprise, et la chaîne se supervise comme n'importe quel service de production.

Quel matériel selon la taille de l'organisation

Le choix du matériel découle du modèle retenu et du volume de requêtes simultanées. Les fiches matériel détaillent les configurations validées par segment.

Le DGX Spark présente un intérêt particulier pour les très petites structures : la superpuce GB10 délivre 1 PFLOP en FP4 dans un format desktop de 150 mm, avec une mémoire unifiée de 128 Go. Un cluster de deux à quatre nœuds réunis par ConnectX-7 porte la capacité au-delà de 400 milliards de paramètres. Le Mac Studio M3 Ultra, avec jusqu'à 512 Go de mémoire unifiée, accepte les modèles à mélange d'experts quantifiés et reste silencieux dans un bureau. Pour une PME, le serveur RTX PRO 6000 accueille les modèles de 70 à 200 milliards de paramètres et traite plusieurs conversations simultanées sans congestion.

Conformité RGPD et hébergement des données

La conformité au règlement européen sur la protection des données résulte de la conjonction de trois éléments. Le modèle traite les questions sans transmettre les données à un tiers. L'index vectoriel stocke les embeddings et les passages sources sur une infrastructure contrôlée par l'entreprise. Les journaux d'audit, conservés en local, documentent chaque requête pour les besoins de traçabilité.

Le routeur sémantique renforce cette conformité par un mécanisme simple. Toute requête identifiée comme potentiellement sensible, par exemple par la présence d'un identifiant, d'un nom de client ou d'une référence contractuelle, est orientée d'office vers un modèle local. Aucune exception de configuration ne peut faire sortir ce type de contenu, ce qui élimine l'erreur humaine à la source. Pour les données de santé, l'hébergement sur une infrastructure certifiée HDS devient un prérequis, et la plateforme s'adapte par le choix du datacenter.

La documentation technique de l'entreprise gagne également à passer par ce pipeline. Les fiches produits, les procédures internes et les bases de connaissances s'indexent une fois, se rafraîchissent à intervalles réguliers, et deviennent interrogeables par les collaborateurs autorisés. La souveraineté ne se limite pas à l'inférence : elle s'étend à la mémoire documentaire de l'organisation.

Du chatbot à la plateforme agentique

Un chatbot souverain couvre le cas d'usage de la question-réponse sur les sources internes. La plateforme agentique va plus loin : elle orchestre plusieurs agents, leur délègue des sous-tâches, capitalise les procédures répétées en skills réutilisables et conserve le contexte entre les sessions. Le chatbot représente le point d'entrée, et la plateforme représente la cible.

Cette trajectoire se construit par étapes. Un chatbot interne valide l'indexation des sources et la conformité du pipeline. Une deuxième étape ajoute des agents spécialisés, par exemple un agent pour la rédaction de comptes rendus et un agent pour la synthèse de documents longs. Une troisième étape installe le harness d'agent, la mémoire à trois couches et la supervision humaine des actions à risque. Chaque étape s'appuie sur les briques déjà en place, et le chatbot souverain en constitue le socle opérationnel.

La décision utile ne consiste pas à ajouter un chatbot à une pile existante. Elle consiste à identifier les deux ou trois tâches internes qui gagnent à passer par un modèle, et à les équiper d'un pipeline conforme, observable et réversible.

Références

• RAG Series, Part 6: From Prototype to Production: Building Scalable, Reliable RAG Systems
• Your RAG system works on 10,000 documents. Here's why it dies at 30 million