Qu'est-ce que le RAG et pourquoi est-ce utile pour les entreprises françaises ?

Le Retrieval-Augmented Generation (RAG) permet de construire un assistant IA qui répond à des questions sur vos propres documents et données, contrats, fiches produit, base de connaissances interne. Pour les entreprises françaises, c'est particulièrement utile dans les cabinets d'avocats, les services RH ou les équipes support qui gèrent de grandes bases documentaires avec des utilisateurs non techniques.

Faut-il des compétences en Python ou en machine learning pour construire une app RAG no-code ?

Non, c'est précisément l'objet de ce guide. L'architecture complète repose sur Supabase (pour stocker les embeddings vectoriels via pgvector), Xano (pour appeler l'API OpenAI et exécuter la recherche sémantique), et WeWeb (pour l'interface de chat). La seule chose à écrire est une ligne SQL pour activer l'extension pgvector dans Supabase.

Comment fonctionne la recherche sémantique pgvector dans Supabase ?

pgvector stocke des représentations numériques (embeddings) de vos documents générées par OpenAI. Quand un utilisateur pose une question, son texte est converti en embedding, puis Supabase recherche les documents les plus proches par similarité cosinus. Cette approche comprend le sens et le contexte, un utilisateur qui demande "procédure de remboursement" trouvera aussi les documents sur "politique de retour", ce qu'une recherche par mots-clés manquerait.

Comment éviter les hallucinations dans une application RAG ?

L'ancrage dans les données réelles est la clé. Dans le prompt système envoyé à GPT-4o, instruisez le modèle de répondre uniquement à partir du contexte fourni et de déclarer explicitement quand la réponse n'est pas dans les documents. Afficher les citations des sources récupérées dans l'interface de chat renforce la confiance des utilisateurs et facilite la détection des erreurs.

Construire une application RAG sans code

Qu'est-ce que le RAG et pourquoi c'est important

GPT-4o standard ne connaît pas les documents internes de votre entreprise, votre catalogue produit, ni vos données clients. Le RAG résout ce problème : vous stockez votre contenu sous forme d'embeddings vectoriels dans une base de données, et au moment de la requête, vous trouvez les fragments les plus pertinents et les envoyez comme contexte au LLM.

Résultat : un assistant IA qui répond à des questions sur vos données spécifiques, avec précision et en citant ses sources. Pour les entreprises françaises, c'est particulièrement utile pour construire des bases de connaissances internes, des bots de support client, ou des assistants juridiques sur corpus documentaire.

La bonne nouvelle : vous n'avez besoin ni de Python, ni de compétences en ML pour déployer cette architecture.

Étape 1 : Activer pgvector dans Supabase

Supabase est livré avec pgvector intégré. Dans l'éditeur SQL de Supabase, exécutez : CREATE EXTENSION IF NOT EXISTS vector;

Créez ensuite votre table documents avec les colonnes content (texte), embedding (vector(1536)), metadata (jsonb) et created_at.

Créez un index pour la recherche de similarité rapide : CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops);

C'est le seul SQL que vous devez écrire. Supabase gère tout le reste, hébergement, sauvegardes, scalabilité. Pour un projet en France, choisissez la région EU West (Paris ou Francfort) pour la conformité RGPD.

Étape 2 : Générer des embeddings avec Xano

Dans Xano, créez un endpoint qui accepte une chaîne de texte, appelle l'API OpenAI Embeddings (text-embedding-3-small), et stocke le résultat dans votre table documents Supabase.

Le function stack : (1) Récupérer l'entrée texte, (2) Appeler l'API OpenAI POST /v1/embeddings, (3) Extraire le tableau d'embedding de la réponse, (4) Insérer dans Supabase via le connecteur API Supabase.

Exécutez ceci pour chaque document, article ou entrée FAQ que vous voulez que votre IA connaisse. Une bonne pratique : découpez les longs documents en chunks de 500-800 mots pour une meilleure précision de recherche.

Étape 3 : Recherche sémantique dans Xano

Créez un second endpoint qui : (1) Accepte une chaîne de requête utilisateur, (2) Génère un embedding pour la requête (même appel OpenAI), (3) Exécute une recherche de similarité vectorielle dans Supabase.

La fonction RPC Supabase pour cela retourne le contenu et les scores de similarité avec la requête, ordonnés du plus pertinent au moins pertinent, limités aux 5 meilleurs résultats.

Cette recherche sémantique est fondamentalement différente d'une recherche par mots-clés : elle comprend le sens et le contexte, pas juste les termes exacts. Un utilisateur qui demande "procédure de remboursement" trouvera aussi les documents sur "politique de retour".

Étape 4 : Générer la réponse avec GPT-4o

Avec les fragments récupérés, appelez l'API Chat Completions d'OpenAI. Le prompt système guide le LLM pour qu'il réponde uniquement à partir du contexte fourni, en déclarant clairement quand la réponse n'est pas dans les documents.

Cette ancrage de la réponse dans vos données réelles empêche les hallucinations, problème majeur des LLMs non contextualisés. Pour les cas d'usage professionnels (support client, documentation technique, conformité réglementaire), c'est la différence entre un outil fiable et un outil inutilisable.

Pensez à adapter le prompt en français pour de meilleurs résultats avec des utilisateurs francophones.

Étape 5 : Construire l'interface de chat dans WeWeb

Dans WeWeb, créez une interface de chat avec une liste de messages et un champ de saisie. Au moment de l'envoi : appelez votre endpoint de recherche Xano, puis streamez la réponse GPT via le support de streaming de Xano ou un appel direct OpenAI depuis le code personnalisé de WeWeb.

Pour la production, ajoutez : historique des messages (stocké dans Supabase), citations des sources (montrez quels documents ont été récupérés), et un mécanisme de feedback (pouce haut/bas pour améliorer la qualité de récupération).

Ce type d'application est particulièrement demandé par les cabinets d'avocats, les services RH et les équipes support en France, secteurs avec de grandes bases documentaires et des utilisateurs non techniques.

Choisir le bon modèle d'embedding

OpenAI propose trois modèles d'embedding en 2025 : text-embedding-3-small (1536 dimensions, 0,02 $/1M tokens), text-embedding-3-large (3072 dimensions, 0,13 $/1M tokens), et l'ancien text-embedding-ada-002. Pour la plupart des applications RAG, text-embedding-3-small est le bon choix : il équilibre coût, vitesse et qualité de récupération pour une recherche documentaire standard.

text-embedding-3-large vaut la peine d'être considéré quand la précision de récupération est critique, analyse de contrats juridiques, recherche dans la littérature médicale, ou applications où un passage pertinent manqué a des conséquences significatives. Dans nos projets, nous avons comparé 3-small et 3-large sur une base de connaissances de 10 000 documents et constaté que 3-small atteignait 94 % de la précision de récupération de 3-large pour 15 % du coût.

Pour les applications multilingues (fréquentes dans notre base de clients européens), les deux modèles OpenAI gèrent raisonnablement bien le français, l'allemand, le suédois et le néerlandais. Cependant, pour une terminologie sectorielle spécialisée dans des langues autres que l'anglais, envisagez de tester des modèles spécifiquement multilingues comme multilingual-22-12 de Cohere via l'API Cohere, à titre de comparaison.

Stratégies de chunking : la variable cachée de la qualité du RAG

La façon dont vous découpez vos documents en chunks est sans doute la variable la plus importante pour la qualité du RAG, plus déterminante que le choix du modèle pour la plupart des applications. Trop grand, et vos chunks récupérés contiennent du contenu non pertinent qui perturbe le LLM. Trop petit, et vous perdez le contexte dont le LLM a besoin pour répondre de façon cohérente.

Dans nos projets RAG en production, nous utilisons une stratégie de chunking hybride : découper d'abord sur les frontières de paragraphe (unités sémantiques naturelles), puis imposer une taille maximale de chunk de 512 tokens et un minimum de 100 tokens. Les chunks trop petits sont fusionnés avec leur voisin. Cela préserve la cohérence sémantique tout en évitant les chunks surdimensionnés. Pour les documents structurés (pages FAQ, fiches produit), nous découpons au niveau question/réponse ou section plutôt que par nombre de tokens.

Une technique souvent négligée : ajouter un chevauchement entre les chunks. Si le chunk N se termine à la phrase 10 et que le chunk N+1 commence à la phrase 11, le contexte qui relie la frontière est perdu. Nous ajoutons un chevauchement de 50 tokens, les phrases 9 et 10 du chunk N sont répétées au début du chunk N+1. Ce surcoût de 10 % améliore significativement la récupération pour les requêtes qui font référence à des concepts qui traversent les frontières de chunks.

Seuils de similarité vectorielle et réglage de la récupération

Tous les chunks récupérés ne sont pas également pertinents. Le score de similarité cosinus renvoyé par pgvector va de 0 (aucune similarité) à 1 (identique). En pratique, les chunks pertinents obtiennent typiquement un score au-dessus de 0,75, et vous devriez filtrer tout ce qui est en dessous de 0,60 pour éviter de fournir un contexte non pertinent au LLM.

Dans votre fonction RPC Supabase, ajoutez un seuil de similarité : WHERE 1 - (embedding <=> query_embedding) > 0.70 ORDER BY embedding <=> query_embedding LIMIT 5. Commencez à 0,70 et ajustez selon vos données. Si votre assistant dit "je n'ai pas d'information à ce sujet" pour des requêtes auxquelles vous savez qu'il devrait répondre, baissez le seuil. S'il donne des réponses à partir de chunks faiblement liés, augmentez-le.

Pour une récupération avancée, implémentez une recherche hybride combinant similarité vectorielle et recherche par mots-clés (la recherche full-text intégrée de PostgreSQL). Cette approche hybride, souvent appelée "reciprocal rank fusion", améliore la précision pour les requêtes contenant des noms propres spécifiques, des noms de produits ou des termes techniques que les embeddings gèrent parfois mal. Supabase supporte nativement à la fois la recherche vectorielle et full-text, ce qui rend la récupération hybride réalisable sans infrastructure sur mesure.

Optimisation des coûts pour un RAG en production

Les principaux facteurs de coût d'un système RAG sont : la génération d'embeddings (quand vous ajoutez de nouveaux documents), les embeddings de requêtes (chaque message utilisateur), et l'inférence du LLM (chaque appel GPT-4o). Pour une base de connaissances interne typique de 5 000 documents et 500 requêtes quotidiennes, la répartition mensuelle des coûts est approximativement : ingestion des embeddings (unique) 0,20 $, embeddings de requêtes quotidiennes 0,30 $/mois, réponses GPT-4o avec un contexte moyen de 3 000 tokens 45 $/mois. Total : environ 50 $/mois pour 500 utilisateurs quotidiens.

Pour réduire les coûts LLM, implémentez une couche de cache pour les requêtes courantes. Stockez les 100 questions les plus fréquentes et leurs réponses dans Supabase. Avant d'appeler GPT-4o, vérifiez si une question sémantiquement similaire a été répondue récemment (similarité cosinus > 0,95 avec un embedding de requête en cache). Les cache hits servent la réponse stockée instantanément, sans appel LLM nécessaire. Dans nos applications RAG en production, 30 à 40 % des requêtes sont des cache hits, ce qui réduit les coûts LLM d'un tiers.

Pour les applications à très fort volume, envisagez de basculer la génération de réponse de GPT-4o vers GPT-4o-mini pour les requêtes à faible complexité. Implémentez une couche de routage qui classe les requêtes comme simples (recherche factuelle, réponse à source unique) vs complexes (synthèse multi-sources, analyse), et route vers le modèle moins cher pour les requêtes simples. Cette approche LLM hybride réduit les coûts d'inférence de 60 à 70 % sur des charges de travail typiques de base de connaissances.

Considérations de production : fiabilité, monitoring et fraîcheur des données

Les systèmes RAG en production ont des exigences opérationnelles que les tutoriels de prototype ignorent. La fraîcheur des documents est critique : si votre base de connaissances est obsolète, votre IA donne de mauvaises réponses avec un langage qui sonne confiant. Implémentez un pipeline de ré-ingestion automatisé, quand un document est mis à jour dans votre CMS ou votre base de données, déclenchez une tâche en arrière-plan Xano pour ré-embedder les chunks concernés et mettre à jour l'index vectoriel.

Le monitoring en production signifie suivre : la latence des requêtes (embedding + récupération + LLM combinés, devrait être sous les 3 secondes pour une bonne UX), la qualité de récupération (journalisez les scores de similarité des chunks récupérés, une baisse du score moyen signale que votre ensemble de documents ne couvre peut-être plus les requêtes récentes), et la satisfaction utilisateur (feedback pouce haut/bas stocké dans Supabase, passé en revue chaque semaine). Dans nos projets, la revue hebdomadaire des réponses mal notées est l'activité d'amélioration de la qualité la plus efficace.

Pour l'isolation des données dans les applications RAG multi-tenants, ajoutez une colonne workspace_id à votre table documents et ajoutez-la à chaque politique RLS et requête de récupération. La base de connaissances de chaque tenant est complètement isolée, un utilisateur ne peut récupérer et recevoir des réponses que depuis ses propres documents. Ce n'est pas négociable pour toute application qui traite des données métier confidentielles, et le RLS de Supabase rend cela simple à implémenter correctement.

Construire une application RAG sans code : OpenAI + Supabase pgvector + WeWeb