Quand vos clients demandent RAG en 2026 : notre arbre de décision (et pourquoi nous ne commençons presque jamais par là)

Nous construisons encore des pipelines RAG pour les clients qui en font la demande, mais en 2026 nous les recommandons rarement en premier. La stack d'outillage agent 2024, celle qui avait fait de la génération augmentée par récupération la réponse par défaut à toute question de gestion des connaissances, a été largement rendue obsolète entre janvier et avril de cette année. Cet article présente l'arbre de décision que nous parcourons avec chaque prospect et la stack que nous livrons quand cet arbre s'éloigne de RAG.

La plupart des agences qui vendent RAG aujourd'hui vendent un manuel de jeu de 2024. Vous en avez probablement reçu un : une ligne budgétaire pour une base de données vectorielle, une stratégie de découpage, un cron de réindexation, une feuille de route de six mois avant que le système réponde à sa première question. Si vous avez déjà une proposition sur votre bureau, envoyez-la-nous avant de signer et nous parcourrons l'arbre avec vous. Voici pourquoi la façon dont on vous a dit de construire des agents sensibles à la connaissance a changé, et ce que nous livrons à la place.

Points clés à retenir

• Nous construisons RAG quand les clients insistent. Nous le recommandons rarement en premier en 2026. Le changement d'outillage est réel, et notre rôle est de vous en avertir avant que vous signiez.

• Sam Hogan a déclaré la majeure partie de la stack d'outillage LLM 2024 obsolète le 18 avril 2026. RAG, l'orchestration multi-agents, les frameworks ReAct, la gestion des prompts, LLMOps, les outils d'évaluation, les passerelles, les bibliothèques de fine-tuning. Les concepts restent valides. Les implémentations populaires ont pris du retard sur l'évolution des modèles.

• Zep a rebrandé de la mémoire vers le context engineering. Une entreprise financée qui renomme sa propre catégorie est le signal de marché le plus fort indiquant où l'infrastructure agent se dirige.

• Les skill graphs ont remplacé la recherche vectorielle comme substrat par défaut. Un dossier de fichiers markdown et cinq commandes shell traitent plus de cas clients que n'importe quel pipeline RAG que nous avons livré.

• RAG mérite encore sa place sur quatre catégories de travaux spécifiques. Les corpus multimodaux, les millions de documents à haute fréquence de mise à jour, les filtres de métadonnées stricts au moment de la récupération, et les contenus adversariaux non fiables. Tout le reste est un skill graph.

L'arbre de décision que nous appliquons avant de construire quoi que ce soit

Chaque engagement client commence par les mêmes quatre questions, et neuf fois sur dix les réponses pointent loin de RAG. Nous avons construit cet arbre à partir d'une étude de 450 dépôts portant sur les outils de mémoire agent et de gestion du contexte sur GitHub, publiée le 15 avril 2026. Presque personne ne trace explicitement la frontière entre les deux. Nous le faisons, parce que cette frontière détermine la facture.

La plupart des corpus clients que nous voyons sont des wikis internes, des playbooks commerciaux, des guides d'intégration, de la documentation produit et des procédures opérationnelles standard. Petits, stables, maintenus par quelques personnes. Chacun de ces cas relève d'un skill graph. L'argument du petit corpus avec de vraies données chiffrées et le guide complet de configuration de la couche de connaissances couvrent la version praticienne.

Ce qui a réellement été rendu obsolète entre janvier et avril 2026

Sam Hogan a publié le diagnostic le plus précis de ce changement le 18 avril 2026. Sa thèse : la majeure partie de la catégorie d'outillage LLM a été construite pour un monde qui n'existe plus vraiment, et une grande partie a été rendue obsolète au cours des trois mois précédents. La liste qu'il a citée :

• RAG et GraphRAG. L'approche de récupération construite pour des fenêtres de contexte inférieures à 32K.

• Les frameworks d'orchestration multi-agents. Les premières couches de coordination codées à la main, déplacées par une coordination au niveau du runtime.

• Les frameworks ReAct. Des échafaudages de raisonnement structuré que les modèles plus récents produisent sans scaffolding.

• Les outils de gestion et de versionnage des prompts. Construits pour un monde où les prompts étaient l'actif. Les skills et les substrats de contexte sont l'actif désormais.

• Les stacks LLMOps. Davantage axées maintenant sur le traçage des agents que sur la gestion des prompts à tour unique.

• Les outils d'évaluation, les passerelles, les bibliothèques de fine-tuning. Chacun construit pour un comportement de modèle qui a changé.

Nuance importante formulée par Hogan lui-même : les concepts restent précieux. Ce qui a été rendu obsolète, ce sont les implémentations populaires actuelles. Certains outils, il a expressément concédé CrewAI, conservent un pouvoir de résistance. Sa thèse plus profonde est celle qui compte pour les clients : les modèles frontier récents avec des fenêtres de contexte très longues ont à peu près résolu le problème de rappel de faits que RAG avait été conçu pour contourner.

Le signal de marché le plus fort est venu de Zep, une entreprise financée dans l'espace de la mémoire agent. Elle a entièrement repositionné son offre, passant de la mémoire au context engineering. MemSearch, de la société de bases de données vectorielles Zilliz, a livré un système où leur propre base de données vectorielle se place en aval de simples fichiers markdown. Un fournisseur de base de données vectorielle qui concède que les fichiers détiennent la connaissance et que l'index n'est que la couche d'accès : c'est le genre de signal qui prend des années à apparaître dans un communiqué de presse et des semaines à lire dans une mise à jour produit.

Ce qui a remplacé RAG pour la majorité du travail agent

L'étude des 450 dépôts a classé la mémoire agent en deux camps. Le premier regroupe les backends de mémoire : extraire des faits des conversations, les stocker dans des bases de données vectorielles, les récupérer sur demande. Mem0 (53 100 étoiles GitHub), MemPalace (46 200), Honcho, Cognee. Optimisés pour le rappel.

Le deuxième camp regroupe les substrats de contexte : un contexte structuré et lisible par l'humain qui s'accumule d'une session à l'autre. Zep se trouve ici désormais. OpenClaw (358 000 étoiles) est l'implémentation de référence. Le vault qui produit cet article est un système du deuxième camp.

La boucle commune du deuxième camp : l'agent lit un contexte structuré, travaille à l'intérieur, écrit en retour, et la session suivante le contexte est plus riche. Pas de stratégie de découpage, pas de modèle d'embedding à maintenir, pas de tâche de réindexation en batch, pas de suite d'évaluation de la récupération. Un dossier de fichiers markdown avec des wikilinks entre eux, un fichier d'index à la racine, et une poignée de commandes de lecture et d'écriture. Voilà le substrat.

Shiv Sakhuja a publié le modèle de composition de ce substrat le 23 avril 2026, sous le nom Skill Graphs 2.0. Trois niveaux : les atomes (primitives à usage unique, quasi-déterministes), les molécules (tâches délimitées composant 2 à 10 atomes avec un chaînage explicite), les composés (orchestrateurs multi-molécules avec une véritable autonomie agent, pilotés par l'humain aujourd'hui). Le framework plafonne la profondeur du graphe de dépendances, ce qui le rend fiable là où les skill graphs plats dérivent silencieusement au-delà de 3 ou 4 sauts. Pour les clients, cela se traduit en structure de coûts : les atomes sont bon marché et déterministes, les molécules sont là où vit le travail d'ingénierie, les composés sont là où vous budgétisez un opérateur humain.

Les cas limites où RAG mérite encore sa place

Nous sommes une agence. Nous livrons ce que le projet exige. RAG surpasse encore un skill graph sur quatre catégories spécifiques de travaux, et nous le proposerons quand l'arbre de décision y aboutit :

• Les corpus multimodaux. Des PDF avec des tableaux, des documents numérisés, des transcriptions audio, des rapports très illustrés. Un graphe markdown suppose que tout se réduit au texte. Quand ce n'est pas le cas, la récupération couplée à l'embedding multimodal est la solution la plus propre.

• Les mises à jour à haute fréquence et grande échelle. Des millions de documents qui changent à la minute et doivent être interrogeables dans les secondes suivant leur publication. Le coût de réindexation d'une base de données vectorielle est inférieur au coût humain de la maintenance d'un fichier d'index à ce volume.

• Le filtrage strict de métadonnées au moment de la récupération. Quand les requêtes doivent filtrer par plages de dates, type de document ou auteur avant que la recherche sémantique s'exécute, des bases de données vectorielles sensibles aux métadonnées comme Pinecone et Qdrant réalisent la composition proprement.

• Le contenu non fiable ou adversarial. Quand le corpus provient de nombreux auteurs aux agendas contradictoires et qu'aucun humain ne peut être chargé de maintenir un index curé, vous souhaitez une récupération qui ne présuppose pas de supervision éditoriale.

Si votre projet entre dans l'une de ces quatre catégories, RAG est le bon outil et nous le construirons. Sinon, le skill graph est moins coûteux à livrer, moins coûteux à faire fonctionner et plus facile à maintenir. Parlez-nous avant de commander l'un ou l'autre et nous parcourrons l'arbre de décision sur votre corpus spécifique.

Ce que nous utilisons en interne et ce que nous avons livré pour nos clients

Notre wiki interne compte 22 pages de connaissances structurées, maintenu par cinq commandes shell. Pas de base de données vectorielle, pas d'embeddings, pas de cron de réindexation. La configuration complète se trouve dans notre article précédent.

Ce même substrat produit le blog webvise que vous lisez : 76 articles traduits en 7 langues grâce à un seul skill graph de contenu. Pas d'équipe éditoriale. Pas de réseau de freelances. Un seul skill, sept sorties par article, livré depuis le même dossier que la documentation technique.

Côté clients, nos travaux d'agent en production reposent sur la même architecture. Hermes, la plateforme agent auto-améliorante que nous avons documentée le mois dernier, fonctionne sur des skills robustes et un runtime léger. Paperclip, notre système d'orchestration IA à l'échelle de l'entreprise, compose des molécules sur une base de connaissances markdown. Aucun des deux ne possède de base de données vectorielle dans la stack de production, et aucun n'en a eu besoin.

Garry Tan raconte la même histoire depuis YC. Son CLAUDE.md personnel a commencé à 20 000 lignes, avec chaque particularité, chaque pattern, chaque leçon qu'il avait rencontrés. L'attention du modèle se dégradait sous ce poids, et Claude Code lui-même lui a conseillé de le réduire.

Sa solution a été 200 lignes de pointeurs vers des documents qui se chargent à la demande. Les 20 000 lignes complètes existent toujours, mais le modèle ne les lit que lorsque c'est pertinent. Sa bibliothèque gstack a atteint 23 000 étoiles GitHub en sa première semaine et a livré 600 000 lignes de code de production en 60 jours. Le substrat passe à l'échelle parce que le substrat, ce sont des fichiers, pas de l'infrastructure.

Les questions à poser à un fournisseur avant de signer un contrat RAG en 2026

Si vous avez déjà une proposition RAG sur votre bureau, posez ces cinq questions avant de signer :

• Quelle est la taille du corpus aujourd'hui et dans 24 mois ? Moins de 1 000 documents dans les deux cas signifie que la base de données vectorielle est une ligne budgétaire dont vous n'avez pas besoin.

• Qui rédige le contenu ? Si ce sont quelques personnes en interne soucieuses de l'exactitude, un fichier d'index maintenu surpasse les embeddings en qualité de récupération. Si ce sont des milliers d'auteurs adversariaux ou anonymes, RAG l'emporte.

• Quelle est la fréquence de mise à jour ? Des modifications une fois par semaine signifient que vous n'avez pas besoin d'un pipeline de réindexation. Des modifications chaque minute à grande échelle, si.

• La requête nécessite-t-elle des filtres de métadonnées stricts au moment de la récupération ? Si oui, une base de données vectorielle sensible aux métadonnées mérite sa place. Si non, la logique de filtrage est moins coûteuse à exécuter dans la couche de skills.

• À quoi ressemble le devis du fournisseur dans 18 mois ? Les coûts des bases de données vectorielles s'accumulent avec la croissance documentaire. Les coûts des skill graphs, non. La différence compte au moment du renouvellement.

Si les réponses pointent vers RAG, construisez RAG. Si elles pointent vers un skill graph, la partie difficile consiste à désapprendre le manuel de jeu de 2024. Chez webvise, nous parcourons l'arbre de décision avec vous sur votre corpus réel, livrons l'architecture vers laquelle l'arbre pointe, et réaffectons les économies vers le travail qui en a réellement besoin. Prenez contact avant que le fournisseur dont vous avez entendu parler dans un podcast ne vous envoie la facture.