RAG dans un SaaS : quand l'utiliser et comment l'architecturer

Utilisez le RAG quand la bonne réponse dépend de documents ou de données que le modèle ne connaît pas : la base de connaissances d'un client, ses contrats, ses procédures, l'historique de ses tickets. Le principe : rechercher les passages pertinents, puis les donner au modèle avec la question. La qualité d'un RAG se joue presque entièrement dans la recherche — un modèle excellent ne peut pas bien répondre à partir des mauvais passages.

RAG ou pas RAG ?

Le RAG n'est pas une étape obligatoire d'un produit IA. Il est inutile si :

• la tâche porte uniquement sur le texte fourni par l'utilisateur (résumer, reformuler, extraire) ;
• les informations nécessaires tiennent dans quelques pages, que l'on peut envoyer entièrement au modèle ;
• la réponse vient d'une base de données structurée : une requête SQL classique est alors plus fiable qu'une recherche sémantique.

Il devient nécessaire quand le corpus est volumineux, change souvent, diffère d'un client à l'autre, ou quand vous devez citer précisément vos sources.

L'architecture en cinq étapes

1. L'ingestion

Récupérer les documents (téléversement, connecteur vers un outil tiers), extraire le texte proprement — y compris les tableaux et les PDF mal structurés — et conserver les métadonnées : client, auteur, date, type de document, droits d'accès. Cette étape est la plus sous-estimée : un texte mal extrait ne sera jamais bien retrouvé.

2. Le découpage

Les documents sont coupés en passages d'une taille adaptée, en respectant la structure (titres, sections, articles d'un contrat) plutôt qu'un nombre fixe de caractères. Chaque passage garde le contexte de son titre parent. Un mauvais découpage coupe une règle en deux, et le modèle n'en reçoit que la moitié.

3. L'indexation

Chaque passage est transformé en vecteur par un modèle d'embedding, puis stocké. Pour la plupart des SaaS, PostgreSQL avec l'extension pgvector suffit largement : les vecteurs vivent à côté de vos données, dans la même base, avec les mêmes règles d'isolation par client. Une base vectorielle dédiée ne se justifie qu'à des volumes importants.

4. La recherche

La recherche purement vectorielle trouve les passages proches par le sens, mais rate souvent les termes exacts : une référence produit, un numéro d'article, un nom propre. La recherche hybride — sémantique et plein texte combinés — corrige ce défaut. On ajoute ensuite souvent une étape de reclassement (reranking) qui réordonne les meilleurs candidats avant de les envoyer au modèle.

5. La génération avec citations

Le modèle reçoit la question et les passages retenus, avec pour consigne de répondre uniquement à partir d'eux, de citer leur source et de dire clairement quand l'information n'y figure pas. Afficher les sources à l'utilisateur est la meilleure protection contre les réponses inventées : il peut vérifier.

La sécurité : le point qu'on ne rattrape pas après coup

Dans un SaaS multi-clients, un RAG mal conçu peut faire remonter le document d'un client dans la réponse d'un autre. Le filtrage par client et par droits d'accès doit s'appliquer dans la requête de recherche elle-même, pas après. C'est l'avantage de garder les vecteurs dans PostgreSQL : les mêmes règles d'isolation s'appliquent à tout, et l'isolation par client se décide dès la conception du modèle de données.

Mesurer la qualité

Un RAG s'évalue en deux temps. D'abord la recherche : pour un jeu de questions réelles, les bons passages sont-ils dans les premiers résultats ? Ensuite la réponse : est-elle correcte, fidèle aux sources, complète ? Sans ce jeu de test, chaque réglage — taille des passages, nombre de résultats, modèle — se fait à l'aveugle.

Coût et performance

Le RAG ajoute un coût d'embedding (faible, payé surtout à l'ingestion) et augmente la taille des requêtes envoyées au modèle. Envoyer cinq passages bien choisis plutôt que vingt passages moyens améliore à la fois la qualité et la facture. Pour le reste du raisonnement économique, voyez comment fixer le prix d'un SaaS IA.

Le RAG fait partie des approches que nous mettons en place sur nos projets de SaaS IA, avec l'appel direct au modèle, la génération encadrée et les agents.