Pourquoi une IA sans contexte reste moyenne ? Vous posez une question métier, l’IA répond vite, bien formulé mais souvent à côté de la plaque. Un modèle IA brut reste souvent décevant en entreprise.
Le problème n’est pas le modèle, c’est l’absence de contexte.
Un modèle IA sans données internes ne connaît pas vos process, n’a jamais vu vos documents, ne comprend pas vos règles métier et improvise dès que la question sort du cadre généraliste.
Résultat : des réponses génériques, parfois justes, souvent inutilisables en production.
Et encore pire, des réponses fausses mais convaincantes.
Pourtant, dès que l’on partage du contexte à un agent IA, tout change, et c’est ce que je voulais vous montrer dans cette édition.
Et il n’y a pas une seule manière de donner de la donnée à une IA. Certaines sont simples, d’autres plus avancées comme le RAG.
Je vous explique tout pas à pas.
4 approches concrètes pour partager du contexte à l’IA
Avant de parler de technique avancée comme le RAG, il existe d’autres façons de donner accès à de la donnée à un agent IA.
Certaines sont très simples, d’autres plus puissantes, et surtout chaque approche a son bon usage.
1️⃣ Les filtres classiques : simple, rapide, fiable
C’est l’approche la plus sous-estimée. Et pourtant, c’est souvent la meilleure pour commencer.
Le principe est simple : l’agent IA ne réfléchit pas sur toute une base de données mais applique des filtres précis comme la date, statut, catégorie, ID, client…
Exemple :
“Combien de commandes validées hier pour le client X ?”
→ L’agent filtre les lignes concernées, fait le calcul et répond.
C’est rapide, peu coûteux et sans ambiguïté.
Règle simple 👉 si un humain utiliserait des filtres dans un tableur, alors utilisez des filtres.
Un exemple ici avec un agent sur n8n pour récupérer des données de vente :
2️⃣ Les requêtes SQL générées par l’IA
Quand on commence à vouloir agréger, classer, calculer des moyennes ou comparer des périodes, les filtres atteignent leurs limites.
Là, on laisse l’agent IA générer la requête SQL pertinente par rapport à la structure de la base de données.
Exemple :
“Quels sont nos 3 produits les plus rentables ce trimestre ?”
L’agent écrit la requête SQL, interroge la base, récupère un résultat structuré puis explique.
C’est très pratique si vous avez des données structurées, beaucoup plus fiable que de passer par des filtres puis faire des calculs et adaptées aux bases métiers (CRM, ventes, finance).
Règle simple 👉 Si un humain utiliserait un tableau croisé dynamique ou des formules → SQL.
Un exemple ici avec un agent IA connecté à une base SQL :
3️⃣ Partager tout le document
Autre approche classique que l’on peut faire, on donne tout le document à lire à l’IA (comme des contrats, procédures, transcriptions, rapports…)
Mais il existe une limite clé = la fenêtre de contexte. Un modèle ne peut pas ingérer une quantité infinie de texte. Au-delà d’un certain volume, les performances chutent, jusqu’à la saturation.
Avec les modèles récents, on peut aller jusqu’à 1M de tokens (GPT 4.1 par API), sinon 400k tokens pour GPT-5.2.
Le gros plus, c’est d’avoir aucune complexité technique, le contexte complet et c’est très pertinent pour l’analyse globale ou un résumé.
Forcément, ça vient avec des limites (longueur du document), coût de traitement sur une partie du document qui est inutile. Pas l’idéal quand on a des dizaines ou centaines de documents.
Règle simple 👉 C’est une bonne solution quand le volume est maîtrisé et que le besoin reste ponctuel.
Dans tous les autres cas, on va vouloir être plus sélectif, et c’est précisément là que le RAG devient intéressant.
4️⃣ La recherche sémantique : comprendre le sens, pas juste les mots
C’est ici qu’entre en jeu le RAG. Au lieu de filtrer, ou tout envoyer au modèle, on va découper les documents, transformer les textes en vecteurs, chercher les passages les plus proches en sens de la question.
Exemple :
“Comment gérer un litige client lié à un retard de livraison ?”
Même si le document ne contient jamais cette phrase exacte, l’agent retrouve les bons passages.
C’est puissant car ça fonctionne même si les mots ne sont pas identiques, c’est scalable sur des milliers de documents et idéal pour la documentation, le support, le juridique, le knowledge management.
Je vous explique plus en détails le RAG mais à ce stade, il faut garder en tête de partager du contexte simplement au modèle puis d’ajouter de l’intelligence quand c’est nécessaire.
Explication sur Le RAG, simplement (sans jargon)
Le RAG (Retrieval Augmented Generation), c’est une chose assez simple : aller chercher l’information avant de répondre. Exactement comme un humain qui va chercher la documentation pertinente dans un espace de gestion de connaissance (Notion, sharepoint, google drive, ..).
Concrètement, un RAG suit toujours la même logique :
- La question est posée
- L’IA va chercher les passages les plus pertinents dans vos documents
- Elle utilise uniquement ces extraits pour générer la réponse
Schématiquement, ça donne :
👉 Important : le modèle ne répond pas avec sa “mémoire”, il s’appuie sur vos données.
Et ça change tout en entreprise quand il y a des connaissances métiers à avoir et des logiques bien précises à suivre.
Découpage des documents
Pour faire une recherche sur vos documents, il est nécessaire de les découper en amont. C’est la petite subtilité. On ne donne pas les documents entiers au RAG.
Ils sont découpés en petits morceaux (chunks), transformés en vecteurs (embedding), stockés dans une base dédiée (aka base vectorielle).
On fait ça parce que chercher dans 3 paragraphes pertinents est plus efficace que lire 200 pages à chaque question.
ça c’est le RAG classique mais comme vous le voyez, c’est linéaire, passif, ça manque d’intelligence pour que le modèle choisisse entre filtre classique, requête SQL, recherche web ou RAG.
Cette approche a ses limites : récupération de passages “à peu près” pertinents, manquement d’info clé, contexte insuffisant. Et surtout le modèle répond quand même, même si la donnée est mauvaise.
On a des réponses bien rédigées mais parfois incorrectes. Un gros problème en production.
Pour aller plus loin, il faut donner plus de contrôle, plus de logique et une meilleure capacité de décision. C’est exactement là qu’entre en jeu le RAG agentique.
RAG agentique, quand l’IA commence à raisonner
Le RAG agentique, c’est l’étape d’après. On ne parle plus d’un simple pipeline, mais d’un agent IA autonome.
Un agent RAG ne se contente plus de “je cherche → je réponds”
Il va être capable de choisir quel outil utiliser (vecteurs, SQL, document complet), vérifier si le contexte est suffisant, relancer une recherche si besoin, combiner plusieurs sources avant de répondre.
Exemple avec ce schéma où l’agent a 3 outils à sa disposition (recherche vectorielle, recherche SQL, recherche web) :
C’est cette boucle itérative jusqu’à atteinte de l’objectif qui est intéressante.
Une question utilisateur peut nécessiter à la fois une règle interne (doc), une donnée chiffrée (SQL) et un historique client (CRM).
Un RAG classique ferait un seul appel. Ici, avec le RAG agentique, l’agent orchestre. On passe d’une logique linéaire à une logique de raisonnement outillé.
Pour aller plus loin, je fais un rapide zoom sur 2 éléments essentiels pour améliorer la recherche vectorielle.
Le reranking : trier après la recherche
Le principe est simple, au lieu de récupérer seulement 3 ou 4 passages,
on en récupère 10, 20, parfois plus… Puis, un second modèle reclasse les résultats, attribue un score de pertinence et ne garde que les meilleurs.
Pour cela, on utilise le modèle de reranking de Cohere.
Ici un exemple sur un scénario n8n avec le reranker de Cohere qui intervient une fois que les passages des docs ont été récupérés.
Les metadata : redonner du contexte perdu
Quand on découpe un document, on perd souvent la source, la date, la catégorie, le client, …
Les metadata servent à garder tout le contexte. ça permet à l’agent de filtrer avant la recherche sur des chunks précis, regrouper des morceaux liés et répondre à des questions plus globales.
Pour cela, on ajoute des metadata lors de la vectorisation, puis on permet à l’agent de filtrer sur ces metadata lors de la recherche vectorielle. Un exemple avec “doc_date” :
Cas concret : un agent RAG utile en entreprise
Pour sortir un peu de la théorie, prenons un cas réel.
Contexte : un groupe hôtelier, plusieurs établissements en France, a des milliers d’avis clients répartis sur Google, Booking, TripAdvisor, …
Les équipes font face à plusieurs problèmes : trop d’avis pour tout lire, des irritants clients qui reviennent… mais mal identifiés, des réponses aux avis parfois incohérentes selon les hôtels.
L’objectif avec le RAG : construire un agent IA capable d’analyser les avis clients pour l’équipe de direction, détecter les points de friction par établissement, aider à formuler des réponses adaptées, produire une vision claire pour les équipes terrain.
Côté des données, les avis clients sont scrapés, stockés dans une base de données SQL avec des règles internes dans une base de données vectorielle avec des metadata de catégorisation métier (accueil, propreté, petit-déjeuner, localisation…).
Concrètement, on va avoir plusieurs scénarios :
1/ La vectorisation des avis clients
Le workflow va vectoriser les avis clients, enrichir chaque avis avec des metadata (établissement, note, catégorie). Ici on utilise supabase pour la création de la base de données vectorielle.
2/ L’agent IA RAG
L’agent capable de rechercher sémantiquement les avis pertinents, regrouper les signaux faibles et générer des synthèses actionnables.
Exemples de requêtes possibles :
- “Résume les avis négatifs de l’hôtel d’Annecy”
- “Quels sont les principaux irritants ce mois-ci à Toulouse ?”
- “Comment répondre à un avis 4 étoiles mentionnant le petit-déjeuner ?”
Ici, c’est juste un exemple concret pour montrer le champ des possibles, mais ce type d’agent est réplicable sur beaucoup d’autres métiers dont le support client pour l’automatisation des tickets entrants.
