🚀 Recherche locale pour agents IA : Pensieve & MCP
Découvrez comment Pensieve améliore la recherche locale pour agents IA avec du contexte de code, et comment MCP pour agents de programmation s’intègre.
Pensieve : donner aux agents IA le bon contexte de code, sans fouiller tout le disque
Un agent de programmation peut écrire du code assez vite. Le vrai défi, c'est souvent de trouver le bon endroit : le fichier pertinent, les décisions déjà prises, et le contexte qui évite de relire le dépôt ligne par ligne. Du coup, une partie du temps et des jetons part dans la recherche d'informations : plusieurs recherches textuelles, l'ouverture de fichiers, puis on recommence quand le premier résultat ne répond pas vraiment à la question.
Pensieve propose une approche différente : indexer localement des fichiers, des dépôts Git et certaines conversations avec des agents, puis fournir ces résultats à l'utilisateur ou à l'agent de code. La recherche peut se faire par sens, par expression exacte, ou les deux. Connecté via MCP, l'objectif est simple : remonter quelques passages pertinents (avec leur fichier et leur ligne), plutôt que de laisser l'agent explorer tout le disque.
L'idée est intéressante, mais elle mérite un examen attentif. Que cherche Pensieve, exactement ? Que mesurent les benchmarks ? Qu'est-ce qui reste réellement local, et quand l'outil apporte assez de valeur pour justifier son installation ? Voilà les points qui comptent.
Le problème : les agents manquent souvent de contexte
Un agent de programmation ne comprend pas spontanément un dépôt entier. Il reçoit une tâche, interroge des outils, lit les résultats disponibles et reconstruit une image partielle du système. La qualité de la réponse dépend donc autant du contexte récupéré que du modèle qui raisonne.
Prenons une question concrète : « Pourquoi les paiements ne sont-ils plus retentés après un refus de carte ? » Une recherche sur « retry » peut renvoyer des dizaines, voire des centaines de résultats. Ensuite, l'agent doit ouvrir plusieurs fichiers, retrouver la logique de traitement des refus, puis éventuellement lire des tests ou un compte rendu d'incident. La réponse existe peut-être dans quelques lignes, mais pour y arriver, le chemin est souvent dispersé.
Ce n'est pas forcément "mauvais" en soi. Si vous cherchez un identifiant précis, un message d'erreur, ou une fonction dont vous connaissez déjà le nom, grep et la recherche textuelle restent efficaces : simples, rapides, prévisibles. Le souci apparaît surtout quand la question décrit une intention sans reprendre les mots du code, ou quand la réponse se trouve entre code, documentation et historique d'équipe.
Le coût caché des recherches répétées
Chaque fichier ouvert ajoute du contexte à la conversation. Résultat : plus de jetons envoyés au modèle, plus de coût sur l'appel, et plus de temps passé à trier du contenu qui ne servira peut-être pas. Et si la recherche renvoie trop de bruit, rien ne garantit que l'agent finira par tomber sur la règle importante.
À l'échelle d'une tâche isolée, ça paraît acceptable. Dans une équipe qui utilise l'agent plusieurs fois par jour et sur plusieurs dépôts, le coût s'accumule : appels d'outils en plus, réponses plus lentes, et davantage de chances de partir d'une mauvaise hypothèse. Le but n'est donc pas de "remplacer grep", mais de réduire le temps nécessaire pour retrouver le passage pertinent.
La recherche sémantique ne remplace pas la recherche exacte
La recherche sémantique tente de rapprocher une formulation de son sens, même si le fichier n'utilise pas les mêmes mots. Par exemple, une question sur les « tentatives de paiement après refus » peut pointer vers une règle nommée hard_decline dans le code, ou vers une phrase dans un document d'incident comme « arrêt de la file de relance ».
Mais ça ne rend pas la recherche exacte inutile. Si vous connaissez le nom d'une classe, d'un identifiant ou d'une erreur, une recherche littérale reste souvent le meilleur point de départ. Pensieve vise donc à couvrir trois cas : sens, expression exacte, ou combinaison des deux. Il propose aussi des filtres pour limiter la recherche à des fichiers, du code, des sessions, un type de fichier, ou un dossier/dépôt précis.
Au final, ce n'est pas "sémantique contre grep". C'est : choisir le bon outil pour la question, et éviter que l'agent lise inutilement tout ce qui ressemble de loin à un résultat.
Comment Pensieve fonctionne et s'intègre aux agents
Pensieve est une application et un outil de recherche pour macOS. Il indexe, selon les sources activées, des dossiers, des dépôts Git, des modifications non validées et des sessions de certains agents. Les coffres Obsidian sont aussi pris en charge ; Apple Notes peut être activé en option. On peut ouvrir un panneau de recherche au clavier, parcourir les résultats et choisir une action sans sortir de son environnement de travail.
L'index suit les changements : fichiers modifiés et worktrees sont pris en compte, pour éviter de travailler à partir d'une version trop ancienne du dépôt. Sur ce point, Pensieve est plus qu'un simple moteur "statique" : un index figé rend vite la recherche moins utile pour le travail en cours.
Le rĂ´le de MCP : donner un outil de recherche Ă l'agent
Pour les agents compatibles, Pensieve expose ses fonctions via MCP, un protocole qui permet à un modèle ou à un agent d'appeler des outils externes. Concrètement, l'agent peut poser une question en langage naturel et recevoir des extraits associés à leur chemin de fichier et à leur ligne. Au lieu d'ouvrir une série de fichiers, il peut lire le passage ciblé.
L'intégration concerne notamment Claude Code, Codex, Cursor, Gemini CLI, Windsurf, Claude Desktop et VS Code, ainsi que d'autres clients MCP. La connexion peut se faire en local via stdio avec pensieve mcp, ou via HTTP. L'installation recommandée configure les agents concernés, ajoute des consignes du type "rechercher avec Pensieve avant une recherche textuelle", et propose des compétences et des hooks optionnels.
Cette étape compte plus qu'on ne le croit. Installer un outil ne suffit pas : sans consigne, intégration claire ou mécanisme visible, un agent peut continuer à lancer grep par habitude. Et si des agents tournent déjà , il faut souvent les redémarrer pour qu'ils chargent correctement les serveurs MCP.
Le périmètre peut suivre le travail en cours
Par défaut, un agent lancé dans un dépôt peut être limité à ce dépôt, à ses worktrees et aux sessions associées. Vous pouvez aussi définir un périmètre plus large, couvrant plusieurs dépôts et un dossier de spécifications. Ce périmètre joue sur la pertinence, mais aussi sur la confidentialité : l'agent n'a pas besoin d'interroger tout le contenu indexé pour répondre à une question qui concerne un projet précis.
Pensieve ne sert pas uniquement à retrouver des passages. En s'appuyant sur git blame et l'historique récent, il peut aussi indiquer quelles personnes ont contribué à une zone, qui semble encore active sur cette partie, et où se concentre la connaissance dans l'équipe. Ce n'est pas une mesure parfaite de compétence : c'est plutôt un point de départ pratique pour savoir à qui demander une revue ou organiser un transfert.
À noter : une ligne "attribuée" par git blame ne prouve pas qu'une personne maîtrise encore le sujet. Et selon les workflows de l'équipe (comptes partagés, réécritures, pratiques Git particulières), le signal peut être trompeur. Ces vues sont donc des indices de discussion, pas un classement des collaborateurs.
Ce que montrent les mesures, et ce qu'elles ne prouvent pas
Le créateur de Pensieve publie un benchmark réalisé avec Claude Sonnet dans Claude Code, sur quatre dépôts réels allant de 504 à 34 847 fichiers. Les tâches de recherche ont été construites à partir de bases de code, formulées de plusieurs façons : description en langage courant, nom exact, ou message d'erreur. Elles ont été réservées à l'évaluation et n'ont pas servi à ajuster Pensieve.
Dans la comparaison la plus récente affichée, les deux configurations ont exécuté 72 tâches sur chacun des quatre dépôts, deux fois, soit 144 exécutions. Pensieve a trouvé le bon fichier dans 131 exécutions, contre 123 avec les outils de recherche habituels. Le rapport indique aussi 43 % d'appels d'outils en moins et un coût moyen par recherche inférieur de 18 % ; les économies annoncées varient de 6 à 28 % selon le dépôt. Pensieve aurait utilisé 16 % de jetons en moins. Les temps de recherche annoncés sont de 0,1 à 0,2 seconde.
Ces chiffres aident à comprendre le type de gain : moins de résultats à trier et une probabilité plus élevée d'atteindre le bon fichier rapidement. Le document donne aussi un exemple illustratif où des agents équipés de Pensieve font en moyenne 2 appels d'outils par recherche, contre 3,4 avec grep, et répondent après un seul appel dans 82 cas sur 144. Cet exemple est distinct du benchmark détaillé : il faut le lire comme tel.
Comment lire un benchmark fourni par l'Ă©diteur
Les résultats donnent envie, mais ils ne garantissent pas le même gain chez vous. Le test dépend d'un modèle, d'un environnement d'exécution, d'un ensemble de dépôts, et surtout de tâches définies par l'auteur de l'outil. Et le coût dépend aussi du cache de prompt de Claude au moment de l'exécution. Les scripts du benchmark sont annoncés disponibles dans le dépôt du projet, ce qui permet (au moins en partie) de vérifier le protocole.
Il faut aussi regarder le périmètre de ce qui est évalué. Le critère central, c'est la capacité à retrouver le bon fichier pour une tâche donnée, avec des mesures de coût et d'appels d'outils. Ça ne mesure pas directement : si le code produit est correct, si les tests passent, si une modification d'architecture est pertinente, ni la sécurité de la réponse finale. Trouver le bon fichier est nécessaire dans beaucoup de cas, mais ce n'est pas la même chose que résoudre correctement un problème logiciel.
La recherche exacte garde aussi un avantage dans un scénario : le benchmark indique qu'une recherche textuelle unique gagne dans ce cas, tandis que Pensieve fait mieux sur les autres types de tâches testés. C'est finalement assez logique. Un outil de recherche sémantique peut réduire les détours, sans rendre les outils existants inutiles.
Avant un déploiement en équipe, le test pertinent est assez simple : prenez une dizaine de questions récurrentes sur vos dépôts, notez le fichier attendu, puis comparez nombre d'actions, temps, pertinence des passages remontés et coût. Les scripts ouverts sont intéressants, mais votre flux de travail reste le meilleur banc d'essai.
Données locales, sécurité et limites pratiques
Pensieve indique que l'index et la recherche s'exécutent sur le Mac de l'utilisateur. L'index local est stocké dans ~/.pensieve. Le serveur répond uniquement sur cette machine, pas sur le réseau local ni vers des sites tiers. Les sources indexées sont contrôlables : désactiver une source supprime ce qu'elle avait indexé. Les fichiers sensibles (exports de gestionnaires de mots de passe, clés, fichiers .env, identifiants) sont annoncés comme exclus de l'indexation.
Cette architecture limite les transferts pendant la recherche. Mais "local" ne veut pas dire "aucune dépendance externe" dans tous les cas. L'outil télécharge des modèles et peut vérifier les mises à jour auprès de GitHub ; ces vérifications peuvent être désactivées. Surtout, les analyses générées par IA sont optionnelles : si vous demandez à Claude Code ou Codex de produire ce contenu, il peut être envoyé au service cloud utilisé. On peut aussi générer ces analyses avec un modèle local (par exemple via LM Studio) ou les désactiver.
Ce qu'il faut vérifier avant l'indexation
Dans un contexte professionnel en France ou en Europe, l'architecture locale ne remplace pas les règles internes de sécurité et de confidentialité. Avant d'activer des sources, vérifiez : ce qui est activé, ce que ces sources contiennent, qui utilise le poste, et si les outils connectés sont autorisés. Si vous travaillez avec des données personnelles ou des infos client, l'analyse doit s'inscrire dans les pratiques de conformité de l'entreprise, notamment au regard du RGPD et des politiques de sécurité en vigueur.
Voici quelques vérifications concrètes avant de démarrer :
- définir clairement les dossiers et dépôts autorisés à être indexés ;
- exclure les répertoires contenant des secrets, des données de production ou des informations client qui ne doivent pas être accessibles à l'agent ;
- vérifier si des résumés/analyses IA sont activés et quel modèle les produit ;
- confirmer le périmètre MCP accessible à chaque agent ;
- tester la suppression d'une source désactivée et la procédure de désinstallation ;
- rappeler que les données d'attribution Git sont des indices, pas une mesure de "performance".
Coût matériel et disponibilité
L'indexation locale a aussi un coût matériel. Pensieve signale qu'elle peut consommer beaucoup d'énergie pendant le traitement initial et recommande de brancher l'ordinateur. L'application nécessite un Mac Apple Silicon pour l'interface complète. Sur Linux et sur les Mac Intel, le backend et le visualiseur web sont disponibles ; sur Mac Intel, le panneau de recherche peut fonctionner aussi si les outils en ligne de commande Xcode sont installés.
L'application macOS n'étant pas encore notariée d'après la documentation fournie, macOS peut demander une autorisation manuelle dans les réglages de confidentialité et de sécurité. Ce n'est pas une étape à "contourner" : en entreprise, il faut suivre la procédure d'installation approuvée par l'équipe informatique.
Pensieve est présenté comme gratuit, libre et distribué sous licence MIT. Ça réduit le coût d'entrée, mais ça ne supprime pas la validation interne, ni le support, ni les exigences de gouvernance. Comme pour tout outil qui indexe du code et des conversations, la décision doit se baser sur le périmètre réel, pas seulement sur le prix de licence.
Dans quels cas Pensieve vaut-il la peine d'être essayé ?
Pensieve paraît le plus utile quand plusieurs conditions se cumulent : dépôts suffisamment volumineux ou mal documentés, agents qui passent beaucoup de temps à retrouver les bons fichiers, questions formulées souvent en langage naturel, et besoin de relier du code à des décisions ou à des discussions passées. Les fonctions d'attribution et de repérage des zones à faible "couverture de connaissances" peuvent aussi être utiles à l'arrivée dans une équipe, pendant une maintenance, ou pour préparer un transfert.
Le gain est moins évident sur un petit projet très simple, une base de code que tout le monde connaît déjà , ou dans des cas où la recherche exacte suffit. Et il faut éviter d'interpréter les contributions comme un organigramme de l'expertise : le nombre de lignes attribuées à une personne ne raconte pas toute l'histoire d'un système.
Une méthode de test en quatre étapes
Pour évaluer l'outil sans transformer l'essai en projet parallèle, faites-le simplement :
- Choisissez un dépôt représentatif. Un projet assez vivant et complexe pour que la recherche contextuelle serve, mais avec des données indexables selon vos règles.
- Établissez une référence. Prenez quelques questions réelles, notez le fichier attendu, puis comparez : nombre d'outils utilisés avec votre méthode actuelle, et temps pour obtenir une réponse exploitable.
- Configurez un périmètre limité. Activez seulement le dépôt et les sources nécessaires. Vérifiez que l'agent charge MCP et suit bien les consignes de recherche avant d'aller explorer les fichiers.
- Comparez sur les mêmes tâches. Mesurez le temps, les appels d'outils, le coût si vous l'avez, la pertinence des passages remontés et la qualité de la réponse. Gardez aussi quelques recherches exactes pour vérifier que l'outil n'abîme pas un usage déjà efficace.
Le critère de décision, à mon avis, devrait être : réduit-il les détours sur vos tâches, sans introduire un nouveau risque ni une charge de maintenance démesurée ? Si oui, élargissez progressivement. Sinon, le meilleur système reste celui que l'équipe utilise déjà et comprend.
Conclusion
Pensieve s'attaque à un problème concret : quand les agents de code cherchent "l'information" dans un dépôt, elle est souvent éparpillée entre code, documentation et historique de travail. L'index local, la recherche par sens et par termes exacts, l'intégration MCP et des vues basées sur git blame donnent un ensemble cohérent.
Les mesures publiées sont encourageantes, mais elles restent liées à un benchmark réalisé par le projet. Elles ne prouvent pas, à elles seules, une amélioration de la qualité du code produit.
La voie raisonnable : l'essayer sur un dépôt représentatif, avec un périmètre de données clair, et des tâches mesurables. Comparez-le à votre pratique actuelle, gardez la recherche textuelle quand elle est plus rapide, et validez la configuration de confidentialité avant d'étendre l'indexation.
Si vous voulez creuser, commencez par la présentation de Pensieve et sa documentation, puis testez l'outil sur quelques recherches que vos développeurs font vraiment tous les jours. Le bon contexte n'a de valeur que s'il améliore le travail - et s'il reste facile à contrôler.