Roomi Fields

RTFM — rendre la mémoire à votre agent IA

Pourquoi un assistant IA cherche mal, et comment une couche de récupération change tout

Vous avez payé pour un modèle plus intelligent. Ça n’a rien changé. Parce que le problème n’était pas l’intelligence — c’était la recherche.

 

L’agent qui cherche à l’aveugle

Si vous avez utilisé un assistant de programmation moderne — Claude Code, Cursor, Codex — sur un projet un peu gros, vous avez vu le symptôme. L’agent parcourt des milliers de fichiers à la recherche d’une information, rate le document qui contient pourtant la réponse, invente une fonction qui n’existe pas, et oublie ce que vous aviez décidé ensemble la session précédente.

Plus le projet grossit, pire c’est. Le réflexe naturel, c’est d’attribuer le problème au modèle : « il n’est pas assez intelligent ». On passe à un modèle plus puissant. Et ça ne change presque rien.

C’est le constat de départ. Le goulot d’étranglement n’est pas l’intelligence du modèle — c’est sa capacité à retrouver la bonne information au bon moment. Un humain très intelligent enfermé dans une bibliothèque sans catalogue ne trouvera pas le bon livre plus vite qu’un humain moyen. Il lui faut le catalogue.

RTFM — Retrieve The Forgotten Memory, « retrouver la mémoire oubliée » — est ce catalogue.

Une parenthèse nécessaire : qu’est-ce qu’un MCP ?

Les trois logiciels de cette série sont des serveurs MCP. Le terme revient à chaque article, autant le poser proprement une fois.

MCP signifie Model Context Protocol — protocole de contexte pour les modèles. C’est un standard publié par Anthropic fin 2024. L’analogie la plus simple : c’est la prise USB des outils pour IA.

Avant l’USB, chaque périphérique avait son propre câble et son propre connecteur. Avant MCP, brancher un outil sur un assistant IA demandait une intégration sur mesure, refaite pour chaque assistant. MCP fixe une prise commune : un serveur MCP déclare une liste d’outils (« cherche dans l’index », « envoie ce message », « pilote ce synthétiseur »), et n’importe quel client compatible — Claude Code, Cursor, Codex — peut découvrir ces outils et les appeler, sans code de colle.

RTFM est donc un serveur MCP : il expose à l’agent un outil « cherche dans la base de connaissance du projet ». L’agent, lui, décide quand l’utiliser. Nous verrons que ce « quand » est un problème à part entière.

La genèse : cinquante pages de droit fiscal

RTFM n’est pas né d’une réflexion abstraite. Il est né d’une frustration précise.

J’écrivais un article sur la fiscalité française : une cinquantaine de pages de texte réglementaire, avec des renvois croisés entre articles de code, de la jurisprudence, de la doctrine administrative. Un corpus de près de 2 000 fichiers.

L’agent tournait en rond. Il parcourait les mêmes répertoires en boucle, saturait sa mémoire de travail, et produisait des citations fausses — fausses mais énoncées avec aplomb. J’ai ajouté de la mémoire, de meilleures consignes, un modèle plus performant. Rien n’a marché. Parce que l’agent ne raisonnait pas mal : il n’arrivait simplement pas à trouver le bon paragraphe dans un corpus juridique de 2 000 fichiers.

J’ai donc arrêté d’essayer de rendre le modèle plus intelligent, et j’ai construit la couche qui lui manquait.

RAG : « le modèle va chercher »

Cette couche porte un nom dans la littérature : RAG, pour Retrieval-Augmented Generation — génération augmentée par la récupération.

L’idée est simple à énoncer. Un modèle de langage ne connaît que deux choses : ce qu’il a vu pendant son entraînement, et ce que vous mettez dans sa fenêtre de contexte (l’espace de travail temporaire où tient la conversation en cours). Votre projet n’est ni dans l’un, ni dans l’autre. Le RAG comble le trou : avant de répondre, le modèle interroge une base externe, en extrait les morceaux pertinents, et fonde sa réponse sur ces morceaux plutôt que sur ses seuls souvenirs d’entraînement.

La « génération » — rédiger la réponse — c’est le travail du modèle. Mais tout ce qui se passe en amont — que stocke-t-on, comment le découpe-t-on, comment le cherche-t-on, comment le présente-t-on au modèle — c’est ce qui sépare un RAG qui fonctionne d’un RAG qui déçoit.

« RAG » est en réalité un mot-valise. Il cache plusieurs décisions de conception très différentes — la documentation de RTFM en détaille six. En voici trois, les plus parlantes.

Décision n° 1 — comment découper le contenu

Avant toute recherche, il faut découper le contenu en unités cherchables, qu’on appelle des morceaux (chunks). Ce découpage décide de ce qu’une recherche pourra, plus tard, retrouver.

La méthode paresseuse : couper tous les 800 caractères. Simple, rapide, et complètement aveugle à la structure. Une fonction est coupée en plein milieu. Une section de documentation se retrouve éparpillée sur trois morceaux. C’est pourtant le réglage par défaut de beaucoup d’outils, parce qu’il ne demande aucune connaissance du format.

La méthode propre : couper aux frontières naturelles du contenu. Une fonction de code = un morceau. Une section de document = un morceau. Un article de loi = un morceau. C’est plus coûteux à construire — il faut un analyseur par format — mais chaque morceau est alors une unité qui a du sens avant même qu’on cherche dedans.

RTFM fait ce choix : il embarque quinze analyseurs (parseurs) qui connaissent la structure de leur format — Markdown, Python, LaTeX, PDF, JSON, XML juridique, tableurs, carnets Jupyter… Un format manquant s’ajoute en une cinquantaine de lignes. Un morceau qui correspond exactement à une fonction ou à un article de loi, c’est déjà 80 % du problème de récupération résolu.

Décision n° 2 — comment chercher le bon morceau

Une fois les morceaux constitués, il faut relier une question au meilleur morceau. Deux grandes familles, aux forces opposées.

La recherche lexicale (la recherche « plein texte » classique) compare les mots. Elle est excellente sur les identifiants exacts : un numéro d’article (« article 39 »), un nom propre, un symbole de code (authenticate_user). Elle est faible sur les reformulations : une question sur « comment gérer la connexion » ne trouvera pas un passage intitulé « flux d’authentification » s’ils ne partagent aucun mot. Son grand avantage : aucun coût, aucun modèle à charger, ça marche dès la première seconde.

La recherche sémantique repose sur des embeddings — chaque morceau est traduit en un vecteur de nombres qui capture son sens. Une question est traduite de la même façon, et on cherche les vecteurs les plus proches. Elle gère les synonymes, les reformulations, les langues différentes. Mais elle est floue sur les identifiants exacts : elle range authenticate_user et login_handler au même endroit. Et elle a un coût : un modèle à télécharger, une étape de calcul.

RTFM choisit la recherche lexicale par défaut — zéro installation, ça fonctionne le premier jour — et propose les embeddings en option, plus un mode hybride qui combine les deux. Aucune des deux familles n’est « meilleure » : elles répondent à des questions de nature différente.

Décision n° 3 — comment présenter les résultats au modèle

Le modèle a maintenant ses meilleurs morceaux. Comment les lui donner ?

Le piège classique, c’est le bourrage de contexte (context stuffing) : on colle tous les morceaux retrouvés dans le prompt, en bloc. Facile à coder, mais ça gaspille le budget de tokens, ça force le modèle à survoler des passages inutiles, et le coût grimpe avec chaque résultat ajouté.

RTFM fait l’inverse, avec une approche appelée divulgation progressive. La recherche ne renvoie d’abord que des métadonnées : chemins de fichiers, titres de sections, scores de pertinence — environ 300 tokens pour cinq résultats. Le modèle lit ce résumé, décide ce qui mérite d’être ouvert, et réclame alors le contenu complet d’un morceau précis. Le coût ne dépend plus de ce qui a été retrouvé, mais de ce que le modèle a vraiment choisi de lire.

C’est une conversation, pas un déversement. L’agent voit trois lignes, puis demande : « montre-moi celui-là ».

Le paradoxe de la navigation

Il reste un obstacle, et il est contre-intuitif. Brancher RTFM via MCP suffit à le rendre disponible. Ça ne suffit pas à ce qu’il soit utilisé.

Une étude — le Navigation Paradox (arXiv 2503.09089) — a mesuré le phénomène : 58 % des agents ignorent un outil externe quand on ne le leur impose pas explicitement. Ils retombent sur leurs réflexes natifs — parcourir les fichiers à la main — même quand un outil de récupération conçu pour ça est juste à côté.

La découverte technique (« l’outil existe ») ne suffit donc pas ; il faut une orientation comportementale (« quand l’utiliser »). En pratique, c’est trois lignes de consignes dans le fichier de configuration du projet : pour toute recherche exploratoire, utilise rtfm_search avant de parcourir les fichiers à la main. RTFM installe ces trois lignes automatiquement. C’est un détail de menuiserie — mais sans lui, la moitié du bénéfice s’évapore.

Ce que RTFM fait concrètement

En une commande, RTFM indexe un projet entier dans un seul fichier SQLite, en local. Pas de clé d’API, pas de cloud, pas de coût récurrent — vos données restent chez vous. Le projet est open source, sous licence MIT.

Et il indexe tout, pas seulement le code : documentation, PDF, textes juridiques en XML, articles de recherche en LaTeX, tableurs, carnets de calcul. C’est sa différence avec les indexeurs de code classiques, qui ne voient que le code — alors qu’un vrai projet, c’est aussi des spécifications, des décisions d’architecture, des notes, des documents réglementaires.

Deux propriétés méritent d’être soulignées :

  • La fraîcheur sans effort. L’index se met à jour tout seul, accroché aux événements naturels de la session de travail (à chaque message, en fin de tour). Pas de tâche planifiée, pas de processus qui tourne en arrière-plan : l’index est frais parce que la session est en cours.
  • La mémoire entre les sessions. RTFM indexe aussi les fichiers de mémoire que l’agent rédige lui-même, à travers tous vos projets, avec un historique complet des versions. La décision d’architecture prise il y a trois semaines dans un autre dépôt redevient trouvable.

Ce que ça mesure — et ce que ça ne fait pas

Un outil qui se respecte se mesure. Sur le cas qui l’a fait naître — la rédaction d’un article réglementaire à partir d’un gros corpus juridique, même agent, même consigne :

Configuration Durée Coût Tokens
Sans RTFM 8 min 16 22,61 $ 8,21 M
Avec RTFM 6 min 58 11,14 $ 3,22 M

Soit −51 % de coût, −61 % de tokens, −16 % de durée — avec, en prime, des citations plus exactes.

Mais l’honnêteté impose les limites. Sur un petit dépôt (moins de 1 000 fichiers), une simple recherche texte suffit largement, et RTFM n’apporte qu’une surcharge inutile. Les mesures portent sur un seul modèle, un seul agent — ce n’est pas une preuve statistique blindée. Et surtout : RTFM ne rend pas soluble une tâche qui ne l’est pas. Il ne remplace pas le raisonnement du modèle. Il s’assure simplement que le modèle a, sous les yeux, le bon contexte pour raisonner.

RTFM gagne nettement quand le problème est : « trouver le bon paragraphe dans un corpus de 2 000 fichiers ». C’est précisément le problème pour lequel il a été écrit.

Pourquoi ça compte

RTFM est utile partout où un projet n’est pas que du code : un cabinet qui mêle code et droit fiscal, un laboratoire qui mêle code, articles et jeux de données, n’importe quel secteur réglementé, un utilisateur d’Obsidian qui veut que son IA fouille vraiment ses notes, un développeur seul qui en a assez de regarder son agent re-parcourir les mêmes 8 000 fichiers à chaque session.

C’est gratuit, local, open source. La couche de connaissance que l’agent aurait dû avoir dès le départ.

Ce qu’il faut retenir

  1. Le goulot d’étranglement d’un agent IA n’est pas l’intelligence, c’est la récupération. Un modèle plus puissant ne compense pas une mauvaise recherche.
  2. Un MCP est la prise standard entre un modèle de langage et des outils externes. RTFM est un serveur MCP.
  3. Le RAG cache plusieurs décisions de conception. Le découpage, la méthode de recherche et la présentation des résultats comptent autant que le modèle.
  4. Découpage structurel, divulgation progressive. Couper aux frontières naturelles du contenu ; ne montrer d’abord que des métadonnées, laisser l’agent réclamer le reste.
  5. Disponible ne veut pas dire utilisé. Sans consigne explicite, la majorité des agents ignorent un outil externe.
  6. Mesuré et honnête. −51 % de coût sur un gros corpus documentaire ; aucun gain — voire une surcharge — sur un petit projet où la recherche texte suffit.

Glossaire

  • MCP (Model Context Protocol) : standard qui permet à un assistant IA de découvrir et d’appeler des outils externes. La « prise USB » des outils pour IA.
  • RAG (Retrieval-Augmented Generation) : technique où le modèle interroge une base externe avant de répondre, au lieu de s’appuyer uniquement sur sa mémoire d’entraînement.
  • Fenêtre de contexte : l’espace de travail temporaire d’un modèle de langage, où tient la conversation en cours.
  • Morceau (chunk) : unité cherchable obtenue en découpant un document.
  • Découpage structurel : découpage qui suit les frontières naturelles du contenu (fonction, section, article) plutôt qu’un nombre fixe de caractères.
  • Recherche lexicale : recherche par correspondance de mots ; forte sur les termes exacts, faible sur les reformulations.
  • Recherche sémantique (embeddings) : recherche par proximité de sens ; forte sur les reformulations, floue sur les identifiants exacts.
  • Divulgation progressive : présenter d’abord des métadonnées légères, puis le contenu complet uniquement sur demande de l’agent.

Pour aller plus loin

Dans cette série

  1. RTFM — rendre la mémoire à votre agent IA ← vous êtes ici
  2. A2 — NotebookLM piloté : quand l’automatisation devient une API
  3. A3 — osc-bridge : un pont déclaratif vers 849 synthétiseurs

Prérequis : aucun
Temps de lecture : 13 min
Tags : #MCP #RTFM #RAG #agents-IA #récupération-information

roomi-fields — vulgarisation à l’intersection des outils, des formalismes et de l’intelligence augmentée.

← Retour à l’index