Les 3 couches secrètes qui font fonctionner tous les systèmes RAG (et comment les déboguer)

Un système RAG ne se résume pas à un simple appel à un modèle de langage. Derrière chaque réponse générée se cachent trois couches techniques empilées, comme les étages d'un immeuble. La première couche, l'ingénierie de prompt, correspond à l'appel lui-même : le message système, les instructions, le schéma qui fixe la forme de la réponse. La deuxième couche, l'ingénierie de contexte, détermine ce qui entre dans la fenêtre du modèle : la récupération des documents pertinents, leur compression, le choix de ce qui reste ou part. La troisième couche, l'ingénierie de boucle, gère ce qui se passe autour de l'appel : quand le prochain appel est déclenché, quand la boucle s'arrête, comment le système se remet d'un échec. Presque toutes les discussions sur les systèmes RAG tournent en réalité autour de la couche sur laquelle on se place.

Cet article est une boussole pour l'intelligence documentaire d'entreprise, une série qui construit un système RAG d'entreprise à partir de quatre briques. Il adopte le cadre des trois couches (ingénierie de prompt, ingénierie de contexte, ingénierie de boucle) devenu dominant en 2026, mais pose une question plus complexe : cette évolution d'une couche à l'autre est-elle vraiment une séquence logique, ou une histoire rétrospective imposée à des schémas qui existaient déjà ?

LES TROIS COUCHES TECHNIQUES QUI PILOTENT TOUS LES SYSTÈMES RAG

Trois disciplines s'empilent sur un seul appel à un modèle de langage. Chacune contrôle un levier différent. Ensemble, elles décrivent la majeure partie du travail des équipes en production lorsqu'elles passent du simple « bonjour monde » à des systèmes opérationnels.

1. L'INGÉNIERIE DE PROMPT : LA PREMIÈRE COUCHE QUE TOUT LE MONDE CONNAÎT

L'ingénierie de prompt est la couche que tout le monde rencontre en premier. Le modèle a besoin d'un message système qui définit son rôle et ses contraintes, d'un message utilisateur qui porte la question et le bloc de contexte, et éventuellement d'un schéma qui fixe la forme de la réponse attendue. Écrire ces trois éléments correctement fait la différence entre un modèle qui suit les règles et un modèle qui improvise. Cette discipline s'est imposée entre 2022 et 2023 avec GPT-3.5 et ChatGPT. Le terme ingénierie de prompt s'est installé dans le discours public à la même période.

Concrètement, le prompt est comme une fiche de mission précise donnée à un employé. Sans cette fiche, l'employé improvise. Avec une fiche bien écrite, il sait exactement ce qu'il doit faire, comment le faire, et sous quelle forme rendre son travail. Dans un système RAG, le prompt inclut :

• Le rôle du modèle (« Tu es un assistant qui répond aux questions sur des documents techniques »)
• Les contraintes (« Réponds uniquement en français », « Ne dépasse pas 200 mots »)
• La structure de la réponse (« Retourne un JSON avec les champs : titre, extrait, source »)

Un prompt mal conçu produit des réponses bruyantes : le modèle dit quelque chose de décalé ou hors sujet. C'est un échec facile à repérer, car le modèle « casse les règles » de manière évidente.

2. L'INGÉNIERIE DE CONTEXTE : QUAND LE PROMPT NE SUFFIT PLUS

L'ingénierie de contexte intervient quand le prompt seul ne suffit plus. Le modèle dispose d'une fenêtre de contexte limitée. Le praticien doit décider quoi y mettre. La récupération sélectionne les documents pertinents. La compression élimine le bruit. L'isolation empêche les sorties d'agents secondaires de polluer la fenêtre principale. Les quatre stratégies canoniques (écrire, sélectionner, compresser, isoler) nomment ce que le praticien fait depuis le premier article sur le RAG. Le terme s'installe en 2025, popularisé par Karpathy et Tobi Lütke, avec la publication par Anthropic de l'article « L'ingénierie de contexte efficace pour les agents IA ».

Imaginez la fenêtre de contexte comme un bureau. Vous ne pouvez pas y mettre tous vos dossiers en même temps. Vous devez choisir : quels documents sont vraiment nécessaires pour répondre à la question ? Quels extraits sont trop longs et doivent être résumés ? Quels calculs intermédiaires doivent rester dans un autre bureau (une autre fenêtre) pour ne pas encombrer le principal ?

Les quatre stratégies de LangChain fonctionnent ainsi :

• Écrire : le préfixe fixe qui ne change pas d'un tour à l'autre (message système, définitions des Outils).
• Sélectionner : la récupération et la mémoire, c'est-à-dire choisir ce qui est pertinent maintenant parmi un ensemble plus large.
• Compresser : la summarisation, la troncature, la réduction de taille pour éviter le débordement.
• Isoler : les appels d'agents secondaires dans leurs propres fenêtres, les outils de mémoire qui conservent l'état en dehors du contexte principal, les appels d'outils programmatiques où les résultats intermédiaires n'entrent jamais dans la fenêtre principale.

Un échec d'ingénierie de contexte est silencieux : le modèle produit une réponse fluide mais fausse, car le contexte récupéré était erroné. C'est comme si vous donniez à un employé un dossier incomplet : il rédige un rapport parfait… mais basé sur de mauvaises informations.

3. L'INGÉNIERIE DE BOUCLE : QUAND UN SEUL APPEL NE SUFFIT PLUS

L'ingénierie de boucle devient nécessaire quand un seul appel ne suffit plus. Le modèle a produit une réponse plausible qui échoue au schéma. La liste retournée contenait douze éléments mais le modèle lui-même a signalé la réponse comme incomplète. L'API a timeout. L'agent a choisi le mauvais outil. Le praticien doit alors gérer quatre surfaces de contrôle :

• Le déclencheur : quelle condition lance le prochain appel ?
• La terminaison : quand la boucle s'arrête-t-elle ? (« jusqu'à ce que ce soit fait » vs « jusqu'à épuisement du budget » vs « jusqu'à ce qu'il n'y ait plus rien à faire »)
• La récupération : comment le système se remet-il d'un échec ? (réessayer avec un backoff, basculer vers un modèle plus grand, escalader vers un humain, sauter l'élément et retourner ce qui a été calculé)
• La vérification adversariale : d'autres agents tentent-ils de réfuter la réponse avant qu'elle ne soit validée ?

Le nom « ingénierie de boucle » s'installe en mai 2026 avec la déclaration de Boris Cherny : « Je ne fais plus de prompt à Claude. J'ai des boucles qui font ça à ma place », suivie dix jours plus tard par le lancement des Dynamic Workflows par Anthropic.

Une boucle mal conçue échoue de manière coûteuse : elle tourne en boucle sur la même charge, brûle le budget de tokens, finit par timeout. C'est comme si vous donniez à un employé une tâche impossible à réaliser avec les ressources disponibles : il passe son temps à réessayer, sans jamais avancer.

UNE HISTOIRE TROP SIMPLE : L'ÉVOLUTION DES COUCHES N'EST PAS LINÉAIRE

Le récit classique raconte que l'ingénierie de prompt a été remplacée par l'ingénierie de contexte, elle-même remplacée par l'ingénierie de boucle. C'est une histoire propre. Elle est aussi légèrement fausse.

Les schémas de chaque couche existaient avant leur nom. ReAct (Princeton et Google, octobre 2022) est la boucle de raisonnement-plus-action canonique, plus de trois ans plus ancienne que le terme ingénierie de boucle. AutoGPT a rendu publiques les boucles autonomes orientées objectifs en mars 2023. Reflexion a ajouté l'auto-évaluation à NeurIPS 2023. Le Ralph Loop de Geoffrey Huntley a mis les objectifs sur disque en juillet 2025. Au moment où le terme ingénierie de boucle s'est imposé en mai 2026, ces schémas étaient en production depuis plus de trois ans.

Côté contexte, c'est similaire. L'article original sur le RAG (Lewis et al., 2020) date de deux ans avant que le terme ingénierie de prompt ne s'installe. Dès 2022, chaque application sérieuse de modèle de langage avait une stratégie de gestion de contexte (découpage, récupération, déduplication, troncature) que personne n'appelait encore ingénierie de contexte. La taxonomie des quatre stratégies de LangChain (écrire, sélectionner, compresser, isoler) nomme ce qui se faisait implicitement dans chaque système RAG de production depuis quatre ans.

La lecture honnête est que les trois couches ont existé simultanément dès le début de l'ère des modèles de langage. Ce qui a changé sur la période de quatre ans, c'est le goulot d'étranglement dominant en production. Tant que le goulot concernait la qualité du prompt, personne ne prêtait attention à la boucle. Dès que le goulot s'est déplacé vers la discipline du contexte, la taxonomie de LangChain s'est cristallisée. Dès que le goulot s'est déplacé vers la fiabilité de l'agent sur plusieurs tours, le catalogue des Dynamic Workflows d'Anthropic a suivi.

TROIS FORCES QUI POUSSENT LE GOULOT VERS LE HAUT DE LA PILE

Trois forces poussent le goulot d'étranglement vers le haut de la pile au fil du temps.

1. Les modèles deviennent meilleurs à leur couche

Chaque génération de modèles nécessite moins d'ingénierie de prompt pour produire une réponse fluide. GPT-4 suivait des instructions que GPT-3 ignorait. Claude 3.5 retournait du JSON valide que les modèles précédents auraient enveloppé dans du texte. La couche d'ingénierie de prompt n'a pas disparu ; elle a simplement cessé d'être le facteur limitant. La prochaine génération de modèles rendra obsolète une grande partie de ce qu'on considère aujourd'hui comme de l'ingénierie de contexte (fenêtres de contexte plus longues, moins de dégradation d'attention en milieu de contexte, raisonnement natif multi-documents). La couche supérieure est ce qui reste.

2. Les tailles de fenêtre grandissent

Les modèles du début 2023 disposaient de fenêtres de 4 000 tokens. En 2023, on est passé à 100 000 tokens (Claude 2), puis à un million de tokens en 2024 (Gemini 1.5). En 2026, un million est un chiffre qui fait la une. Les titres surestiment encore le rappel effectif (un modèle avec une fenêtre d'1M souffre de pourriture de contexte bien avant la limite nominale), mais la pression technique sur la gestion du contexte change de forme. Le choix n'est plus comment tout faire entrer mais quoi garder pour que le modèle puisse encore le trouver. Le goulot passe du remplissage à la curation, ce qui correspond exactement à ce que font sélectionner et isoler.

3. Les exécutions durent plus longtemps

En 2022, un cas d'usage typique était une session de question-réponse en un seul tour. En 2026, c'est un agent qui tourne pendant quarante tours sur six heures, créant des sous-agents qui s'étendent et synthétisent. Le cas d'usage de 2022 n'avait pas besoin d'ingénierie de boucle, car il n'y avait pas de boucle à concevoir. Le cas d'usage de 2026 ne peut pas survivre sans elle. Le goulot ne se déplace pas parce que la pratique change ; il se déplace parce que le cas d'usage change.

Ces trois forces agissent ensemble. Les meilleurs modèles réduisent la pression sur les couches inférieures. Les fenêtres plus longues déplacent la pression vers la curation plutôt que le remplissage. Les exécutions plus longues ajoutent une couche qui n'existait pas auparavant. Le résultat est la séquence des noms. Ce n'est pas une évolution de techniques, mais une séquence de ce qui fait le plus mal en production.

CE QUE CHAQUE COUCHE CONTRÔLE : UNE CARTE POUR DÉBOQUER

Le schéma des trois couches est le plus utile quand il rend les frontières claires. Chaque couche possède une question qui lui est propre.

Couche 1 – Ingénierie de prompt : Que lit le modèle lors de cet appel unique ?

Tout ce qui se trouve entre l'ouverture {