Du RAG au CAG : Pourquoi l’explosion du contexte rend votre infrastructure obsolète

Le RAG a été la réponse dominante à un problème réel : comment donner à un LLM accès à des connaissances qu’il ne possède pas en mémoire ? Pendant deux ans, la réponse de l’industrie a été unanime — construire des pipelines de retrieval, fragmenter les documents, générer des embeddings, alimenter des bases vectorielles. Une infrastructure entière s’est constituée autour de cette idée.

Mais quelque chose a changé. Les fenêtres de contexte ont explosé. Le prompt caching est devenu une réalité économique. Et une technique discrète, le Cache-Augmented Generation — le CAG — commence à remettre en question les fondements de cette architecture. Non pas comme une amélioration marginale du RAG, mais comme une alternative structurellement différente.

Cet article est le troisième volet d’une série : après le guide fondationnel sur le RAG et l’analyse du Semantic Collapse à grande échelle, il est temps de regarder en face ce qui vient après. Ou plutôt : ce qui vient à côté, et qui pourrait, pour une large classe de cas d’usage, rendre le RAG superflu.

Ce que le RAG ne peut pas résoudre : la RAG Debt

Si vous avez lu les deux articles précédents, vous savez déjà que le RAG n’est pas une solution magique. Le guide fondationnel le démontrait sur le plan technique : le chunking est une décision arbitraire, les embeddings dérivent, le re-ranking est coûteux. L’article sur le Semantic Collapse allait plus loin : à grande échelle, les pipelines RAG perdent en précision de façon non linéaire, et les benchmarks Stanford 2025 en donnaient la mesure brutale.

Mais il y a un problème encore plus fondamental que les articles techniques ne posent pas assez clairement : le RAG, c’est une infra.

Pas un bout de code. Une infrastructure complète avec ses composants, ses dépendances, ses points de défaillance, et sa maintenance permanente. Concrètement, un pipeline RAG en production implique une base vectorielle à opérer (ChromaDB, Pinecone, Weaviate, pgvector — au choix, mais aucune option gratuite en termes de charge opérationnelle), un modèle d’embedding à figer et à ne jamais changer sous peine de rendre tout l’index incohérent, des pipelines ETL pour ingérer, nettoyer, chunker et indexer les documents, une logique de re-ranking pour améliorer la pertinence du retrieval, et une gestion de la synchronisation entre la source de vérité et l’index vectoriel.

Chacun de ces composants accumule ce que j’appelle de la RAG Debt — une dette technique spécifique aux systèmes de retrieval. Elle se manifeste de plusieurs façons. La dette de chunking : chaque décision sur la taille et le chevauchement des fragments est une dette potentielle, car il n’existe pas de valeur universellement correcte. La dette d’index : votre index vectoriel est une photographie de votre corpus à un instant T. Dès que la source évolue, la dette s’accumule. La dette de contexte global : un pipeline RAG ne récupère que des fragments. Il ne « voit » jamais l’ensemble du corpus simultanément. Toute question qui requiert une synthèse transverse — « quelles sont les contradictions entre ces cinquante documents ? » — est structurellement difficile à répondre correctement, parce que le retrieval ne remonte jamais tout.

C’est sur ce dernier point que le CAG apporte sa réponse la plus radicale.

Le CAG : définition, mécanique, et la fin du chunking

Le Cache-Augmented Generation repose sur une idée que sa simplicité apparente rend presque suspecte : au lieu d’aller chercher des fragments pertinents dans un index, on charge l’intégralité du corpus dans la fenêtre de contexte du modèle.

Pas de chunking. Pas d’embeddings. Pas de base vectorielle. Pas de retrieval. Le modèle « voit » tout, simultanément, et répond en ayant accès à l’ensemble des informations disponibles.

Le terme et le cadre formel ont été posés dans un paper de décembre 2024 signé par des chercheurs de la National Chengchi University et d’Academia Sinica (Taïwan), publié sous le titre sans ambiguïté Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks. Le repo GitHub du framework CAG est public. Ce paper est la référence académique fondatrice sur le sujet — et son titre est une déclaration de guerre au pipeline RAG classique.

Le contraste avec le pipeline RAG est saisissant dès qu’on le visualise côte à côte :

La question immédiate — et légitime — est : pourquoi ne pas avoir fait ça depuis le début ? La réponse tient en deux contraintes historiques. Premièrement, les fenêtres de contexte étaient trop petites. GPT-3 travaillait sur 4 096 tokens. Impossible d’y loger une documentation entière. Deuxièmement, et c’est le point crucial, charger un corpus entier à chaque requête était prohibitivement coûteux. Si chaque appel API doit tokeniser et traiter 500 000 tokens de contexte, le coût explose à un niveau intenable.

C’est là qu’intervient le mécanisme qui rend le CAG économiquement viable : le KV-cache — Key-Value cache.

Pour comprendre le KV-cache, il faut saisir comment fonctionne un transformer à un niveau minimal. Lorsqu’un LLM traite un texte, il calcule pour chaque token des vecteurs clé (K) et valeur (V) qui représentent la relation de ce token avec tous les autres. Ces calculs sont coûteux. Le KV-cache est le mécanisme par lequel le modèle mémorise ces vecteurs K et V pour les parties du contexte qui ne changent pas d’une requête à l’autre.

Le paper de référence formalise le cycle de vie du CAG en trois phases distinctes — et le schéma suivant illustre ce qui est gelé et ce qui est recalculé à chaque requête :

La première est le preloading : le corpus est encodé une fois en KV-cache et stocké en mémoire ou sur disque — le coût de traitement est payé une seule fois, quel que soit le nombre de requêtes suivantes. La deuxième est l’inférence : le cache est chargé aux côtés de la question de l’utilisateur, le modèle génère sa réponse sans aucune étape de retrieval. La troisième, et c’est un détail technique souvent omis, est le cache reset : entre deux sessions, le KV-cache s’accumule de façon append-only avec les tokens de chaque échange. La réinitialisation ne consiste pas à recharger le corpus depuis le disque — elle consiste simplement à tronquer les tokens ajoutés par la session précédente, ce qui est quasi-instantané. C’est ce mécanisme de reset qui rend le CAG opérationnellement propre sur des sessions multiples.

En pratique : si votre corpus de 200 000 tokens est chargé en début de session, le modèle calcule les K et V de ce corpus une seule fois, les met en cache, et les réutilise pour toutes les requêtes suivantes. La deuxième requête, la centième, la millième — elles bénéficient toutes du cache. Seule la question de l’utilisateur (quelques centaines de tokens) est traitée à frais plein.

Ce n’est donc pas « bourrer le contexte ». C’est du caching au sens informatique rigoureux du terme : calcul coûteux effectué une fois, résultat mis en mémoire, réutilisé indéfiniment.

La conséquence pratique est vertigineuse pour quiconque a passé du temps à tuner des pipelines RAG : le problème du chunking disparaît. Entièrement. Il n’y a plus à décider si un chunk doit faire 256, 512 ou 1024 tokens. Plus à arbitrer entre overlap agressif (redondance, coût) et overlap minimal (perte de contexte aux frontières). Plus à se demander si la stratégie de découpage sémantique vaut mieux que le découpage par paragraphe. Plus à maintenir une cohérence entre la stratégie de chunking à l’ingestion et la stratégie de retrieval à la requête.

Le gain en Developer Experience est lui aussi concret. Avec le RAG, itérer sur la qualité des réponses implique souvent de modifier l’infrastructure : changer la taille des chunks, réentraîner ou changer le modèle d’embedding, reconstruire l’index, réévaluer le re-ranking. Avec le CAG, on itère sur le prompt. L’infrastructure n’existe plus. On teste, on ajuste le message système, on relance. Le cycle de développement s’accélère considérablement.

Prompt caching Anthropic : le CAG industrialisé

Le concept de CAG n’a de valeur pratique que s’il est économiquement viable. Et c’est précisément ce qu’Anthropic a résolu avec son implémentation du prompt caching. C’est, d’une certaine façon, le passage de l’artisanat à la logistique : le RAG vous demandait de tailler vos documents à la main, morceau par morceau, avec le soin minutieux d’un ébéniste. Le CAG vous demande d’organiser un entrepôt — charger une fois, expédier à volonté.

Pour situer le contexte historique : c’est Google avec Gemini 1.5 Pro qui a ouvert la voie en proposant des fenêtres de contexte de un million de tokens. Ce saut quantitatif a été le premier signal que « tout mettre dans le contexte » devenait techniquement envisageable. Anthropic a ensuite franchi l’étape suivante en industrialisant le caching avec une tarification explicite et prévisible. Le CAG, dans sa forme actuelle, est le fils spirituel de ces deux avancées.

Voici comment fonctionne concrètement le prompt caching d’Anthropic. Lorsque vous structurez un appel API avec un bloc de contexte marqué comme cacheable, Anthropic stocke les KV-states correspondants pendant cinq minutes (TTL par défaut, extensible). Toute requête suivante qui présente le même préfixe de contexte bénéficie du cache et ne repaye pas le coût de traitement de ce contexte.

La différence de prix est l’argument massue, et les chiffres 2026 sont devenus franchement brutaux pour le RAG traditionnel. La règle des 90/25 s’applique uniformément sur toute la gamme Claude 4.5 : les cache write tokens (construction du cache, première utilisation) coûtent 25 % de plus que le token d’entrée standard — c’est le coût du cold start, payé une seule fois. Les cache read tokens (toutes les utilisations suivantes) coûtent 10 % du prix standard, soit une réduction de 90 % sur chaque appel en cache hit.

Voici les tarifs en vigueur au moment de la rédaction, en dollars par million de tokens :

Le chiffre qui mérite qu’on s’y arrête, c’est celui d’Opus. Il y a encore peu, Opus 3 était facturé 15 $ le million de tokens en entrée — un tarif qui le réservait de fait aux usages à très haute valeur ajoutée. Opus 4.5 est passé à 5 $, soit une baisse de 67 %. Avec le caching actif, un cache hit sur Opus revient à 0,50 $ par million de tokens. Pour mettre ce chiffre en perspective : 500 pages de texte dense représentent environ un million de tokens. Faire tourner le modèle le plus puissant d’Anthropic sur 500 pages de documentation, de contrats ou de jurisprudence, pour chaque question posée après le cold start, coûte littéralement moins qu’un café. C’est un renversement économique complet — le caching rend l’intelligence « flagship » moins chère qu’un modèle mid-tier utilisé sans cache.

Le break-even est lui aussi brutal dans sa simplicité : dès la deuxième requête sur le même corpus, vous avez déjà économisé. Le premier appel coûte 1,25× le prix standard (cache write). Le deuxième coûte 0,10× (cache read). Total sur deux appels : 1,35× le prix d’un appel standard. Sans caching, deux appels coûtent 2,00×. L’avantage est acquis à partir de la deuxième requête, quelle que soit la taille du corpus.

Pour un corpus de 100 000 tokens accédé cent fois dans la journée : sans caching, vous payez 100 000 tokens × 100 requêtes. Avec caching, vous payez 100 000 × 1,25 (cache write) + 100 000 × 0,10 × 99 (cache reads). Le rapport est sans appel.

Concrètement, voici à quoi ressemble la structure d’un appel API avec cache_control dans le SDK Python d’Anthropic :

import anthropic

client = anthropic.Anthropic()

# Charger le corpus une fois (ex : documentation, contrats, base de connaissances)
with open("corpus.txt", "r") as f:
    corpus = f.read()

response = client.messages.create(
    model="claude-sonnet-4-5-20251001",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Vous êtes un assistant expert. Répondez en vous appuyant exclusivement sur le corpus fourni.",
        },
        {
            "type": "text",
            "text": corpus,
            "cache_control": {"type": "ephemeral"}  # ← marqueur de mise en cache
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Quelles sont les clauses de résiliation présentes dans les contrats ?"
        }
    ]
)

# Inspecter l'utilisation du cache dans la réponse
usage = response.usage
print(f"Cache write tokens : {usage.cache_creation_input_tokens}")
print(f"Cache read tokens  : {usage.cache_read_input_tokens}")
print(f"Tokens standards   : {usage.input_tokens}")
Langage du code : Python (python)

Le marqueur cache_control: {"type": "ephemeral"} indique à l’API qu’elle doit stocker le KV-state de ce bloc. Le TTL par défaut est de cinq minutes — toute requête suivante présentant le même préfixe système bénéficie automatiquement du cache read, sans aucune modification côté code. L’inspection de usage.cache_read_input_tokens permet de vérifier en production que le cache est bien actif et de mesurer le gain effectif sur chaque appel.

RAG vs CAG : la matrice de décision

Ni le RAG ni le CAG ne sont des solutions universelles. Ce qui détermine le bon choix, c’est la nature du problème. Voici la grille d’analyse honnête.

Taille du corpus : la limite physique de la fenêtre

Le CAG est contraint par la fenêtre de contexte du modèle. Claude Sonnet 4.5 dispose d’une fenêtre de 200 000 tokens, soit environ 150 000 mots ou 400 à 500 pages. C’est suffisant pour une documentation technique, une base de connaissances interne, un ensemble de contrats. Ce n’est pas suffisant pour Wikipedia, une base juridique nationale complète, ou un corpus de millions de documents. Au-delà de la fenêtre de contexte, le RAG n’a pas d’alternative.

Fréquence de mise à jour : flux dynamique vs photographie figée

Un cache est une photographie figée. Si votre corpus est mis à jour en temps réel — flux de news, données de marché, tickets de support actifs — le CAG impose un invalidation et une reconstruction du cache à chaque mise à jour significative. Le RAG, avec une base vectorielle correctement synchronisée, gère les mises à jour incrémentales bien mieux. Sur corpus vivant, le RAG conserve l’avantage structurel.

Complexité du raisonnement : l’avantage de la synthèse transverse

C’est ici que le CAG gagne le plus nettement, et c’est le critère le moins souvent mentionné. Lorsque la question requiert une synthèse transverse — « Identifie toutes les contradictions entre ces documents », « Quels sont les thèmes récurrents sur l’ensemble du corpus ? », « Résume l’évolution de la position de l’entreprise sur ce sujet sur les trois dernières années » — le RAG échoue structurellement. Il ne récupère que des fragments, et aucune stratégie de re-ranking ne compense l’absence de vision globale. Le CAG, lui, voit tout. La synthèse transverse est son terrain naturel.

En revanche, pour un retrieval de fait précis — « Quelle est la clause de résiliation à l’article 7.3 ? » — le RAG ciblé sur le bon chunk est parfaitement efficace, et le CAG n’apporte pas de valeur supplémentaire.

Latence et performance : le compromis du Cold Start

La première requête avec le CAG paie le prefill complet du corpus : sur 100 000 tokens, la latence du cold start est perceptible. Les requêtes suivantes, en cache hit, sont rapides. Si votre application exige une latence constante et prévisible dès la première requête, le RAG avec retrieval ciblé reste plus régulier.

Budget tokens : l’équation de rentabilité

Sur sessions longues avec corpus stable et questions répétées, le CAG devient moins cher. Sur requêtes ponctuelles avec corpus variable, le RAG est plus économique.

Traçabilité et citations : l’enjeu de l’auditabilité

Le RAG permet nativement d’indiquer quels chunks ont été utilisés pour générer la réponse. Le CAG produit des réponses synthèses sans mécanisme natif de citation source — le modèle a tout vu, mais ne « sait » pas forcément ce qu’il a utilisé. Pour les applications où l’auditabilité est critique (légal, médical, compliance), c’est un point de vigilance.

Il existe cependant une parade simple : demander explicitement au modèle, dans le prompt système, de citer des extraits verbatim à l’appui de chaque assertion. Le CAG rend cet exercice plus fiable que dans un pipeline RAG classique, précisément parce que le modèle a l’ensemble du corpus sous les yeux — il ne cite pas de mémoire ou par inférence, il peut localiser et reproduire le passage exact. Une instruction du type « Pour chaque affirmation, citez le passage source entre guillemets et précisez le document d’origine » suffit généralement à obtenir une traçabilité exploitable, sans infrastructure supplémentaire.

La conclusion de cette matrice est nette : pour un corpus stable, de taille raisonnable, avec des questions qui demandent compréhension globale et synthèse, le CAG est supérieur au RAG sur presque tous les critères. L’inverse est tout aussi vrai pour les corpus larges, vivants, avec des besoins de retrieval précis et traçable.

Les benchmarks du paper fondateur de 2024 l’illustrent empiriquement. Les chercheurs ont comparé le CAG à deux baselines RAG classiques — retrieval BM25 (sparse) et retrieval dense par embeddings OpenAI — sur deux datasets : SQuAD (questions à réponse précise dans un passage unique) et HotPotQA (raisonnement multi-hop sur plusieurs documents en parallèle). Résultat : sur HotPotQA, c’est-à-dire exactement le type de raisonnement transverse pour lequel le CAG est théoriquement avantageux, le CAG égale ou dépasse le RAG sur les configurations small et medium. Sur SQuAD, les deux approches sont comparables. La dégradation du RAG s’accentue à mesure que le nombre de documents augmente — plus le corpus grossit, plus le retrieval accumule des erreurs de sélection, et plus l’avantage du CAG se creuse.

Les limites réelles du CAG (ce que les enthousiastes taisent)

Le CAG mérite le même traitement que j’ai appliqué au RAG dans les articles précédents : une analyse sans complaisance de ses failles réelles.

Le Lost in the Middle : le trou noir du contexte

Les recherches sur les LLMs à contexte long ont mis en évidence un phénomène préoccupant : les modèles ont tendance à mieux se souvenir des informations placées en début et en fin de contexte, et à dégrader leurs performances sur ce qui est placé au milieu. Avec un corpus de 150 000 tokens, les documents positionnés entre les tokens 40 000 et 100 000 sont structurellement défavorisés. Pour les cas d’usage où la localisation précise de l’information dans le corpus importe, c’est un biais à connaître et à tester. Les modèles les plus récents ont progressé sur ce point, mais le phénomène n’a pas disparu.

Le Cold Start : la taxe de première requête

Le premier appel CAG sur un corpus conséquent paie le prefill intégral. Sur 200 000 tokens, la latence est réelle et le coût est celui des cache write tokens, légèrement supérieur aux tokens standard. Pour une application avec des sessions courtes ou des utilisateurs uniques qui n’interrogent le corpus qu’une fois, le bénéfice du cache ne se matérialise jamais et le CAG revient plus cher que le RAG. L’économie du CAG repose entièrement sur la réutilisation du cache.

À cela s’ajoute une contrainte technique que la documentation d’Anthropic mentionne discrètement : le cache ne s’active qu’à partir d’un seuil minimum de tokens. Sur Sonnet et Opus, ce seuil est de 1 024 tokens. Sur Haiku, il monte à 4 096 tokens. En dessous de ces seuils, le marqueur cache_control est simplement ignoré — aucune erreur n’est levée, mais aucun cache n’est constitué. Pour les petits corpus ou les prompts courts, le CAG ne s’applique pas et l’approche classique reste la seule option.

Dernier point tarifaire à connaître pour les power users : Anthropic applique un multiplicateur sur les appels dont la requête dépasse 200 000 tokens. Si votre corpus est très volumineux et que vous approchez ou dépassez ce plafond, le tarif d’entrée est généralement doublé. Ce n’est pas rédhibitoire compte tenu de la réduction sur les cache reads, mais le calcul de rentabilité doit intégrer ce facteur sur les corpus de grande taille.

Le corpus figé : la gestion de l’invalidation

Un cache est une photographie. Le TTL par défaut chez Anthropic est de cinq minutes, ce qui signifie qu’un corpus inactif doit être rechargé passé ce délai. Pour les applications avec des sessions longues et un trafic continu, ce n’est pas un problème. Pour les applications avec un usage sporadique sur un corpus qui évolue, la gestion de l’invalidation de cache devient un sujet à part entière — et une complexité qui commence à ressembler à celle qu’on voulait éviter.

Le Vendor Lock-in : l’adhérence au fournisseur

C’est la limite la moins visible mais potentiellement la plus structurante. Le prompt caching est implémenté différemment selon les fournisseurs. La gestion du KV-cache, les TTL, les formats de structuration des blocs cacheables — tout cela est spécifique à chaque plateforme. Si vous optimisez votre architecture autour du caching Anthropic, migrer vers Gemini, GPT-4o ou un modèle open source signifie revoir une partie significative de votre code et de votre logique de gestion du contexte. Ce n’est pas rédhibitoire, mais c’est un coût de migration à intégrer dans la décision architecturale.

Cas d’usage concrets : où le CAG change vraiment la donne

La théorie est utile, mais le CAG prend tout son sens appliqué à des contextes réels. Voici les cas où le rapport effort/bénéfice est le plus favorable.

Documentation technique interne : la fin du « CTRL+F »

Une équipe de développement avec 300 pages de documentation interne, des specs fonctionnelles, des ADR (Architecture Decision Records) et des runbooks. Le corpus est stable à 90 %, mis à jour une à deux fois par semaine. Les questions sont du type synthèse : « Quels sont tous les choix d’architecture qui impactent le module de paiement ? », « Y a-t-il des contradictions entre la spec V2 et les runbooks actuels ? ». Le CAG est ici en situation idéale. Zéro infrastructure vectorielle, zéro problème de chunking des documents techniques, synthèse transverse native.

Support client : une base de connaissances vivante

Un corpus de FAQ, de procédures, de réponses types et de cas résolus. Stable dans ses grandes lignes, avec des mises à jour hebdomadaires. Les agents traitent des dizaines de requêtes par heure sur le même corpus. Le caching devient rentable dès la troisième requête de la session. La réduction du coût par requête est immédiate et mesurable.

Corpus juridique : l’analyse de contrats à 360°

Un cabinet qui travaille sur un ensemble de contrats-cadres, de jurisprudences internes, de modèles de clauses. Questions typiques : « Est-ce que la clause de force majeure dans ce contrat est compatible avec notre modèle standard ? », « Quels contrats contiennent des clauses de révision de prix non plafonnées ? ». Ces questions requièrent une vision transverse de l’ensemble du corpus. Le RAG, qui fragmente les contrats en chunks, perd systématiquement le contexte des clauses adjacentes. Le CAG lit le document en entier.

CertifiK : audit analytique de certifications blockchain

Dans le contexte de CertifiK.io, un corpus de fichiers certifiés avec leurs métadonnées, leurs hash et leurs historiques de certification forme un corpus structuré et stable. Des requêtes analytiques sur ce corpus — « Quels fichiers certifiés dans cette période présentent des métadonnées incomplètes ? » — sont exactement le type de question transverse que le CAG traite bien, là où un RAG sur ce même corpus produirait des résultats fragmentés et peu fiables.

Sites éditoriaux (WordPress) : l’assistant thématique expert

Pour un blog avec 382 articles comme paul.argoud.net, l’ensemble du corpus dépasse la fenêtre de contexte actuelle des modèles — trop grand pour le CAG intégral. En revanche, un sous-corpus thématique (tous les articles IA, soit une cinquantaine d’articles) est parfaitement adapté. Un assistant CAG sur ce sous-corpus répond à « Quels articles ont traité du coût des LLMs en production ? » ou « Y a-t-il des contradictions entre ma position sur le RAG en février et en mars ? » avec une précision qu’un RAG classique ne peut pas atteindre.

Le futur : RAG-CAG hybride et Long-Context RAG

L’opposition RAG vs CAG est, en réalité, une vue de l’esprit utile pour comprendre les deux approches, mais trop binaire pour décrire ce que l’industrie est en train de construire.

L’architecture émergente la plus prometteuse est ce que certains appellent le Long-Context RAG : un premier étage de retrieval grossier qui identifie les documents les plus pertinents parmi un très large corpus, suivi d’un second étage CAG qui charge ces documents entiers dans le contexte. On ne récupère plus des chunks — on récupère des documents complets, qu’on traite ensuite avec la pleine capacité de compréhension du modèle.

Cette architecture hybride combine les avantages des deux approches : la scalabilité du RAG pour le premier filtrage sur corpus très large, et la profondeur de compréhension du CAG pour l’analyse détaillée du sous-ensemble récupéré. Elle corrige aussi la limite principale du CAG pur — la contrainte de la fenêtre de contexte — en n’y chargeant que ce qui est pertinent, mais dans son intégralité.

On peut aussi imaginer des architectures à trois niveaux pour les cas d’usage les plus exigeants : un index vectoriel léger pour la présélection large, un re-ranking sémantique pour affiner la sélection, et un CAG sur le résultat final. C’est plus complexe que le CAG pur, mais significativement plus puissant que le RAG classique.

Le parallèle avec le stockage est éclairant : le SSD n’a pas tué le HDD. Il a redéfini les cas d’usage de chacun. Le HDD reste pertinent pour le stockage froid, massif et économique. Le SSD domine tout ce qui requiert de la vitesse et des accès aléatoires. RAG et CAG cohabiteront de la même façon, chacun dominant sa niche, avec une zone d’hybridation croissante pour les cas complexes.

Ce qui est certain, c’est que la fenêtre de contexte va continuer à grandir. Gemini 2.0 dépasse déjà le million de tokens. Le paper fondateur de 2024 l’anticipait déjà explicitement : à mesure que les modèles étendront leur capacité de contexte, ils pourront traiter des collections de connaissances de plus en plus larges en une seule passe d’inférence, ce qui élargira mécaniquement le périmètre d’application du CAG. Si les modèles atteignent dix millions de tokens avec un caching efficace dans les deux prochaines années — ce qui n’est pas un scénario fantaisiste — la question « RAG ou CAG ? » ne se posera plus dans les mêmes termes. Le retrieval deviendra optionnel pour la majorité des cas d’usage.

Ce que je retiens pour mes propres projets

J’ai relu mes deux articles précédents sur le RAG en préparant celui-ci. Le guide fondationnel reste valide dans sa description du pipeline. L’article sur le Semantic Collapse l’est encore plus — les limites qu’il décrit sont précisément celles que le CAG adresse.

Ce que j’en retire concrètement : pour CertifiK, le corpus de certifications est un candidat naturel au CAG sur des sous-ensembles thématiques ou temporels. Pour paul.argoud.net, un assistant CAG sur le corpus IA serait plus utile qu’un RAG sur l’ensemble des 382 articles — la synthèse transverse entre articles est exactement ce que mes lecteurs cherchent parfois à faire.

Sur le plan architectural, ma règle de décision personnelle est devenue simple. Si le corpus tient dans la fenêtre de contexte et qu’il est stable : CAG par défaut, sans hésitation. Si le corpus est trop grand ou trop dynamique : RAG, en acceptant ses limites documentées. Si la question requiert une synthèse transverse sur corpus large : architecture hybride, avec tout ce que cela implique en complexité.

Ce qui a changé dans ma façon de penser ces systèmes, c’est le renversement de la charge de la preuve. Pendant deux ans, la question par défaut était « comment construire un bon pipeline RAG ? ». La question pertinente est désormais : « Pourquoi construire un pipeline RAG si le CAG suffit ? »

Ce n’est pas la mort du RAG. C’est la fin de sa position de solution par défaut.