Construire un chatbot IA sur mesure avec RAG pour les PME suisses

La plupart des PME qui demandent un 'chatbot IA sur mesure' imaginent un modèle entraîné sur leurs documents. Ce n'est presque jamais la bonne réponse. Le fine-tuning change la façon dont un modèle écrit ; il ne change pas de manière fiable ce qu'il sait, et il incorpore silencieusement vos données dans un modèle coûteux à mettre à jour et impossible à auditer ligne par ligne.

Le Retrieval-Augmented Generation résout le vrai problème. Vos documents restent dans une base de données que vous contrôlez. Au moment de la question, les passages pertinents sont récupérés et transmis à un modèle de langage généraliste comme contexte, avec la consigne stricte de ne répondre qu'à partir de ce contexte. Le chatbot répond avec des citations ; vous pouvez tracer chaque réponse jusqu'au paragraphe source, supprimer un document et le voir disparaître immédiatement des réponses, et changer de modèle sous-jacent sans rien réentraîner.

Un chatbot en production, c'est cinq composants, pas un. Sautez-en un seul et vous obtenez une démo qui hallucine.

Premièrement, un pipeline d'ingestion qui lit vos sources, PDF, pages wiki, exports de tickets, contrats, et les normalise en texte propre avec des identifiants stables. Deuxièmement, un chunker qui découpe ce texte en passages assez petits pour qu'un modèle puisse raisonner dessus et assez grands pour porter du sens, avec l'URL source et le numéro de page attachés. Troisièmement, un modèle d'embedding qui transforme chaque chunk en vecteur, stocké dans une base vectorielle (pgvector, Qdrant, Weaviate). Quatrièmement, un retriever qui, pour chaque question utilisateur, trouve les top-k chunks les plus pertinents et, idéalement, les réordonne avec un modèle plus fort. Cinquièmement, une étape de réponse où un modèle de langage reçoit la question, les chunks récupérés et un system prompt qui interdit toute réponse en dehors d'eux.

Tout le reste, mémoire de la conversation, routage multilingue, filtres de sécurité, analytics, se greffe autour de ces cinq.

L'expression 'entraîner un chatbot sur une base de connaissances personnalisée' est trompeuse. Vous n'entraînez pas un modèle. Vous curatez un corpus, l'embeddez et pointez un retriever dessus.

Commencez petit et honnête. Choisissez un domaine borné, politique RH interne, documentation produit, une ligne de service précise, où la vérité de base existe réellement sous forme écrite. Ingérez cela en premier. Mesurez la qualité de la récupération avant de toucher au prompt de génération : pour un ensemble de vraies questions, les top-3 chunks contiennent-ils effectivement la réponse ? Si non, aucun prompt engineering ne sauvera le chatbot ; corrigez d'abord le chunking et les embeddings.

Une fois la récupération solide, réglez le prompt de réponse pour qu'il refuse poliment quand le contexte ne contient pas la réponse. Un chatbot qui dit 'Je n'ai pas cette information' est infiniment plus utile qu'un qui l'invente.

Pour une PME suisse, l'ingénierie intéressante n'est pas le choix du modèle. C'est le chemin des données. La nLPD et le RGPD s'intéressent tous deux à l'endroit où voyagent les données personnelles, à leur durée de conservation et à qui peut les voir, et les stacks fournisseurs par défaut font transiter tout par des API d'inférence américaines à conditions opaques.

Un déploiement RAG conforme garde documents et embeddings dans une base suisse ou européenne que vous contrôlez. Il utilise des fournisseurs d'inférence avec résidence des données en UE ou en Suisse, des accords de rétention zéro et aucun entraînement sur les données soumises. Il journalise chaque prompt et chaque réponse pour l'audit, chiffre les embeddings au repos et impose un accès par utilisateur, pour qu'un commercial ne puisse pas récupérer des documents RH.

Rien de tout cela n'est exotique. C'est une question de choisir l'option ennuyeuse à chaque couche et de la coucher dans un diagramme de flux de données avant d'ingérer le premier document.

Quatre modes d'échec couvrent la plupart des projets RAG qu'il nous faut sauver.

La récupération est calibrée sur des questions synthétiques plutôt que réelles. Le système est superbe en démo et rate dès le premier jour en production. Évaluez toujours contre un ensemble de questions posées par de vrais utilisateurs.

Les chunks sont trop grands ou trop petits. Des passages qui couvrent trois sujets diluent la récupération ; des chunks d'une seule phrase perdent le contexte. Partez sur 400-800 tokens avec recouvrement, puis ajustez à la mesure.

Le prompt laisse le modèle répondre depuis ses connaissances antérieures. Une consigne système sérieuse interdit explicitement d'utiliser quoi que ce soit hors du contexte fourni et exige des citations par ID de source.

Personne ne possède le corpus. Les documents vieillissent, se dupliquent ou se contredisent, et le chatbot présente sereinement la mauvaise version. Un RAG en production a besoin d'un responsable humain nommé et d'une revue mensuelle, exactement comme n'importe quel autre système de référence.