Le Retrieval-Augmented Generation (RAG) est une architecture dans laquelle le prompt d'un LLM est complété dynamiquement par des documents récupérés depuis un store externe, juste avant la génération. Au lieu de s'appuyer uniquement sur les poids figés lors de l'entraînement, le modèle lit du contexte fraîchement récupéré et ancre sa réponse dans ce contenu.La boucle minimale est la suivante : (1) générer des embeddings pour la requête de l'utilisateur, (2) récupérer les k chunks les plus proches dans un vector store, (3) préfixer ces chunks au prompt, (4) générer. Chaque étape a des implications en termes de coût et de qualité.
Pourquoi le RAG est important pour les agents de coding IA en 2026
Les agents de coding comptent parmi les plus gros utilisateurs de RAG en production. Leurs « documents » sont des fichiers sources, des pages README, des références API, des runbooks et des logs d'erreurs — du contenu qui change à chaque commit et qu'aucun modèle ne peut avoir mémorisé avec précision.Pression sur le budget de contexte. Un agent travaillant sur un grand monorepo ne peut pas charger l'intégralité du code dans sa context window. Le RAG est le mécanisme de sélection : il décide quels fichiers entrent dans la fenêtre. La qualité du retrieval détermine directement combien de tokens du modèle sont consacrés à du code pertinent plutôt qu'à du bruit.Fraîcheur. Les données d'entraînement ont une date limite. Votre API interne, votre SDK personnalisé, le guide de style de votre équipe — rien de tout cela ne figure dans les poids d'un modèle public. Le RAG est la réponse standard : maintenir un index vectoriel en temps réel, récupérer à la demande, rester à jour sans fine-tuning.Maîtrise des coûts. Un agent naïf pourrait injecter dans le prompt tous les fichiers potentiellement liés « au cas où ». Le RAG discipline cette approche : seuls les top-k chunks sont inclus, plaçant la taille du prompt sous un plafond prévisible. Associé à une étape de compaction (suppression du boilerplate des chunks récupérés avant leur entrée dans le prompt), il est possible de réduire drastiquement le coût en tokens par requête. Voir réduire l'utilisation de tokens des agents de coding IA.
Le goulot d'étranglement de la qualité du retrieval
Le plafond du RAG est fixé par le retrieval, pas par la génération. Un modèle puissant lisant des chunks non pertinents hallucine avec confiance. Les trois leviers :
Taille des chunks. Trop grande : le signal se dilue dans du remplissage. Trop petite : le contexte inter-lignes se perd. Pour du code source, les chunks au niveau des fonctions surpassent généralement les chunks au niveau des lignes ou des fichiers.
Modèle d'embeddings. Les embeddings constituent la colonne vertébrale du retrieval. Un modèle d'embeddings faible signifie que du code sémantiquement pertinent se classe derrière des correspondances superficiellement similaires mais inutiles.
Re-ranking. Un cross-encoder léger re-score les 50 meilleurs candidats avant que les 5 finalistes n'entrent dans le prompt. Cela ajoute un petit coût en tokens pour un gain de précision significatif.
RAG vs fine-tuning
Le fine-tuning ancre la connaissance dans les poids — coûteux, lent à mettre à jour, et opaque. Le RAG stocke la connaissance en externe — facile à mettre à jour, auditable et débogable (vous pouvez journaliser exactement quels chunks ont été récupérés). Pour la plupart des cas d'usage d'agents en 2026, le RAG est le bon choix par défaut et le fine-tuning est l'optimisation à laquelle on recourt une fois que le RAG atteint ses limites.
Quand le RAG n'est PAS le bon outil
Bases de connaissances petites et stables. Si l'intégralité de votre référence tient dans une context window et change rarement, sautez la couche de retrieval et chargez-la directement. Le RAG ajoute de la latence et de la complexité sans apporter de bénéfice.
Recherches syntaxiques précises. Trouver toutes les occurrences d'une signature de fonction spécifique est un problème de grep/AST, pas de retrieval. La semantic search et le RAG sont complémentaires aux outils de correspondance exacte, non des remplaçants.
Chemins critiques en latence. Chaque aller-retour RAG ajoute un appel d'embeddings plus une requête vers le vector store avant même que la génération ne commence. Si votre budget de rate limit ou votre SLA utilisateur est serré, un prompt mis en cache peut surpasser un retrieval frais.
Requêtes hautement structurées. Quand la réponse est déterministe — « quel est le type de retour de la fonction X ? » — un outil d'analyse statique fournit une réponse plus rapide, moins coûteuse et exacte.
Voir aussi
Embeddings — la colonne vertébrale vectorielle qui rend le retrieval possible
Context window — le budget que le RAG est conçu à remplir intelligemment
Token — l'unité de coût pour chaque chunk injecté par le RAG
Tokenizer — détermine comment les chunks sont comptés dans le budget de contexte