RAG¶

Les 7 mauvais réflexes des équipes RAG (et comment les corriger)

Introduction

Quand un projet RAG patine, ce n'est presque jamais à cause d'une techno manquante. C'est à cause d'un enchaînement de réflexes contre-productifs que les équipes adoptent sans s'en rendre compte. On retouche le prompt alors que le problème est dans le retrieval. On juge "ça marche" sur quatre essais à la main. On empile les techniques avancées avant d'avoir compris où ça bloque.

Après une vingtaine de projets RAG en mission ou en audit, je retrouve toujours les mêmes 7 réflexes. Ce ne sont pas des erreurs techniques, ce sont des biais cognitifs. Mais ils sabotent les performances aussi sûrement qu'un mauvais chunking. Voici la liste, et à chaque fois le réflexe à substituer.

Long context vs RAG en 2026 : quand utiliser quoi ?

Introduction

À chaque sortie d'un modèle avec une fenêtre contextuelle plus grande, le débat revient : « le RAG, c'est fini, on met tout dans le contexte ». En 2026, Gemini 3.1 Pro pousse jusqu'à 2 millions de tokens, Claude et GPT tiennent le 1M. La question est légitime.

Mais sur le terrain, ce n'est pas si simple. J'ai vu des équipes brûler des milliers d'euros en API en pensant qu'elles « simplifiaient » leur stack en virant le RAG. J'ai vu aussi des équipes monter un RAG pour répondre à des questions sur 3 pages de doc. Dans les deux cas, on utilise le mauvais outil pour le problème.

Parsing PDF pour RAG : extraire vraiment la donnée

Le parsing, première cause d'échec des RAG en entreprise

Sur 10 RAG qui ne fonctionnent pas en entreprise, 8 ont un problème de parsing en amont. Pas de modèle, pas de prompt, pas de retriever. Juste un PDF mal lu au départ.

C'est le constat que je fais sur presque tous les projets que j'accompagne. Une entreprise investit des semaines à choisir son modèle de langage, à configurer sa base vectorielle, à affiner ses prompts... et le système répond à côté. Parce que le document source a été mal lu dès le début.

Le parsing (l'extraction structurée des données depuis un document) est l'étape la plus sous-estimée du RAG. Si la récupération d'informations depuis vos fichiers est approximative, peu importe la sophistication du reste du pipeline : vous construisez sur du sable. Un tableau mal extrait, des colonnes confondues, un schéma technique ignoré... et votre LLM génère des réponses fausses avec une confiance absolue.

Dans cet article, je vais vous montrer pourquoi cette structuration des documents est si difficile, comment les 4 grands outils du marché se comparent vraiment, et ce que j'ai appris sur deux projets très différents : des documentations d'usine chez Continental, et un site e-commerce avec des milliers de fiches produit.

Évaluer un RAG en production : métriques et RAGAS

80% des RAG que j'audite n'ont pas de système d'évaluation

C'est un chiffre que j'aurais aimé pouvoir citer avec une source académique. Mais il vient directement du terrain : sur les projets RAG en production que j'ai eu à auditer ces deux dernières années, environ 8 sur 10 n'ont aucun système d'évaluation structuré en place.

Le scénario est toujours le même. Le projet a été livré. L'équipe a "vérifié à la main" sur 10 ou 15 questions pendant la recette. Les retours utilisateurs semblent corrects. Et plus personne ne mesure rien.

Le coût caché de cette absence est massif. Vous ne savez pas si le RAG dérive après une mise à jour des documents. Vous ne savez pas si un changement de modèle d'embeddings a cassé quelque chose. Vous ne savez pas si les améliorations que vous apportez apportent vraiment un gain, ou si elles compensent juste une régression ailleurs. Vous optimisez à l'aveugle.

C'est le sujet numéro un qui sépare un RAG POC d'un RAG production mature. Un POC, ça "marche". Un système production, ça se mesure, ça se surveille, et ça s'améliore de façon contrôlée. Cet article couvre les métriques RAG qui comptent, les frameworks d'évaluation (RAGAS, DeepEval, TruLens), comment construire un dataset d'évaluation solide, et comment mettre en place une évaluation continue en production.

Optimiser un RAG : 8 Techniques de Production & Gains Mesurés

Vous optimisez probablement dans le mauvais sens

Quand un RAG ne fonctionne pas bien, voici ce que font 90% des équipes : elles changent le prompt.

On reformule les instructions, on essaie différents modèles, on ajuste la température. Et parfois ça aide un peu. Mais le plus souvent, le problème n'est pas là.

Jason Liu, l'un des experts RAG les plus suivis, a une formulation que j'ai trouvée juste : "Avant de toucher à quoi que ce soit, atteignez 97% de recall en retrieval."

97% de recall, ça veut dire que dans 97 cas sur 100, le chunk qui contient la bonne réponse est bien dans les résultats que vous passez au LLM. Si vous n'êtes pas là, le meilleur prompt du monde ne changera rien. Le LLM ne peut pas inventer une information qui n'est pas dans son contexte.

Le vrai ordre d'optimisation d'un RAG, c'est : mesurer d'abord, puis retrieval, puis génération. Pas l'inverse.

Chunking RAG : quelle stratégie choisir en 2026 ?

Le chunking que vous utilisez probablement est le pire testé

Je vais commencer par un résultat qui m'a surpris quand je l'ai vu.

Chroma Research a publié un benchmark comparant toutes les stratégies de chunking courantes. Ils ont testé les paramètres par défaut d'OpenAI Assistants : 800 tokens, 400 tokens d'overlap. Leur verdict est sans appel, c'est la configuration avec la précision la plus basse de tous les tests. 1.4% de précision. Leur commentaire exact : "particularly poor recall-efficiency tradeoffs".

Ce sont les paramètres que des dizaines de milliers de projets utilisent en ce moment, souvent parce que c'est ce que suggère le quick start de LangChain ou LlamaIndex.

Et pendant ce temps, des configurations 4x plus simples (200 tokens, zéro overlap) font 3.7x mieux en précision.

Le chunking, c'est la décision sur laquelle la plupart des équipes passent le moins de temps. Et pourtant, c'est probablement celle qui a le plus d'impact sur la qualité de votre RAG.

RAG hybride BM25 + vectoriel : implémentation

Votre RAG vectoriel rate des questions que vous ne voyez pas

C'est une remarque que j'entends souvent sur les projets RAG : "Ça marche bien en général, mais parfois il ne trouve rien sur des questions pourtant simples."

Exemple concret : "Quelle est la procédure ISO-27001 pour les accès distants ?" → 0 résultat pertinent.

Le vectoriel encode le sens. Mais quand la question contient un identifiant exact (une norme, un code produit, un acronyme métier), l'encodage sémantique rate complètement.

C'est ce qu'on appelle le vocabulary mismatch. Et c'est le problème que le hybrid search résout.

Les 5 erreurs les plus fréquentes avec le RAG

Introduction

Depuis 2023, j'ai réalisé une dizaine de projets RAG moi-même, et j'en ai dirigé une autre dizaine avec des équipes. Certains se sont très bien passés, d'autres un peu moins, mais on a toujours essayé d'apprendre et se corriger tout au long du projet. Avec le recul, je retrouve toujours les mêmes erreurs, que ce soit chez moi au début, chez des clients, ou chez des confrères. Ce ne sont pas des erreurs techniques (j'en parle dans cet article), mais des erreurs de posture, d'approche et de méthode.

Ce sont des erreurs qu'on fait tous au moins une fois. L'idée ici, c'est de les poser clairement pour éviter de les répéter.

RAG vs Long Context LLM : le RAG est-il fini ?

Introduction : le RAG, une méthode magique ?

À chaque sortie d'un nouveau modèle avec une fenêtre contextuelle plus grande, on annonce le RAG comme dépassé. Pourtant, le RAG est né d'un besoin très concret : on ne peut pas donner un document de 400 ou 500 pages à un LLM et lui poser des questions dessus.

En entreprise, on a souvent des dizaines (voire des centaines) de fichiers. Le RAG apporte une réponse simple : construire une base documentaire avec des petits morceaux (chunks) de documents, puis fournir dynamiquement les morceaux pertinents à l'IA à chaque question.

4 causes techniques d'échec d'un RAG (et correctifs)

Introduction

Un RAG "basique" est rapide à mettre en place, mais il plafonne souvent entre 50 et 70 % de bonnes réponses. En entreprise, ce n'est pas suffisant pour un usage fiable.

Si tu cherches plutôt une méthode d'analyse d'erreur pour prioriser les actions d'amélioration, l'article dédié est ici :
Mon RAG ne marche pas : pourquoi l’analyse d’erreur change tout

Si tu veux d'abord comprendre pourquoi le RAG reste utile malgré les grandes fenêtres contextuelles, j'ai un article dédié :
Le RAG est-il vraiment fini ?

Ici, on se concentre sur l'autre question : pourquoi un RAG ne répond pas correctement, et comment l'améliorer.