Vous n'avez pas marre de prêcher dans le noir ? Chaque jour, toute votre expérience de développeur s'évapore. Vos découvertes, vos solutions, vos décisions. Tout disparaît dans le néant.
"Je sais que j'ai codé ça il y a 3 mois, mais où ?" Cette phrase, je l'ai prononcée des dizaines de fois. Entre mes 6 projets actifs et mes 12 agents Claude, retrouver le bon fichier devient un cauchemar.
La solution existe : GrepAI couplé à pgvector transforme votre codebase en mémoire sémantique. Au lieu de chercher des caractères exacts, vous cherchez par signification.
Dans cet article, je partage mon retour d'expérience d'installation complète de GrepAI avec pgvector. Vous découvrirez aussi ma vision future : connecter toutes vos sources de données (emails, tickets, calendrier) pour créer une véritable mémoire augmentée.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
Comprendre le RAG comme "mémoire IA"
Le RAG (Retrieval-Augmented Generation) est souvent présenté avec du jargon technique. En réalité, c'est simple : un cerveau persistant pour votre IA.
Sans RAG, Claude oublie tout entre deux sessions. Votre contexte disparaît à chaque fois.
Avec RAG, l'IA accède à une mémoire externe avant de répondre. Elle retrouve les informations pertinentes dans vos données, puis génère une réponse informée.
Imaginez un développeur avec une mémoire photographique de tous ses projets. C'est exactement ce que le RAG apporte à vos agents IA.
Le marché explose : 2,33 milliards de dollars en 2025, 81,51 milliards prévus en 2035. Un CAGR de 42,7% selon VentureBeat.
Les cas d'usage pour les développeurs sont concrets : recherche de code similaire, documentation contextuelle, patterns de conception. Au lieu de chercher "authentication.php", vous cherchez "comment je gère les tokens JWT ?".
Pourquoi une solution locale comme GrepAI ? Trois raisons critiques.
Données privés: vos données de code restent sur votre machine. Aucun upload vers un cloud tiers.
Latence : recherche instantanée sans appel API distant. Dans mon cas, 50-100ms contre 500-2000ms avec une solution cloud.
Cout: zéro frais récurrents après installation. L'embedding se fait localement avec Ollama.
Voici le flux de données simplifié :
┌──────────────┐
│ Votre code │
└──────┬───────┘
│ indexation
▼
┌──────────────┐
│ Embeddings │ (vecteurs 768 dimensions)
└──────┬───────┘
│ stockage
▼
┌──────────────┐
│ pgvector │ (PostgreSQL)
└──────┬───────┘
│ recherche sémantique
▼
┌──────────────┐
│ GrepAI │
└──────┬───────┘
│ MCP protocol
▼
┌──────────────┐
│ Claude Code │
└──────────────┘
IBM Research montre que le RAG réduit les hallucinations de 43% comparé à un LLM seul. Dans le contexte du développement, cela signifie des suggestions de code basées sur VOTRE codebase, pas sur des exemples génériques de Stack Overflow.
Grep classique vs recherche sémantique
La commande grep cherche des caractères. La recherche sémantique cherche du sens.
Exemple concret : vous cherchez du code d'authentification. Avec grep "authentification", vous ratez tous les fichiers utilisant "login", "auth", "verifyCredentials", "checkSession".
Avec GrepAI, la requête "gestion de l'authentification utilisateur" trouve tous ces fichiers. Le système comprend que login, auth et vérification de session sont sémantiquement liés.
Dans mon projet multi-agents, j'ai 580+ fichiers. Une recherche grep classique me retournait 47 résultats pour "logging", dont 38 non pertinents (imports, commentaires, logs de debug).
GrepAI avec la même requête sémantique : 9 résultats, tous pertinents. Gain de temps : 15 minutes économisées.
Voici une comparaison structurée :
| Critère | grep classique | GrepAI (sémantique) |
|---|---|---|
| Type de recherche | Exact match (regex) | Similarité vectorielle |
| Compréhension | Zéro (caractères) | Comprend synonymes et contexte |
| Pertinence | Beaucoup de bruit | Résultats triés par pertinence |
| Vitesse | Ultra-rapide (ms) | Rapide (50-100ms avec index) |
| Configuration | Aucune | Indexation initiale requise |
| Cas d'usage | Recherche exacte, debugging | Exploration, documentation, refactoring |
Exemple de code comparatif :
# grep classique : recherche exacte grep -r "authentication" src/ # Résultats : 47 fichiers, beaucoup de bruit # GrepAI : recherche sémantique via MCP grepai search "comment gérer l'authentification utilisateur" # Résultats : 9 fichiers pertinents, triés par score
Grep reste pertinent dans certains cas. Quand vous cherchez un nom exact de fonction, une valeur de configuration spécifique, ou quand vous debuggez avec une stack trace.
La recherche sémantique brille pour l'exploration, la documentation, le refactoring. Quand vous ne connaissez pas le terme exact mais vous savez ce que vous cherchez.
EnterpriseDB rapporte que 73% des développeurs utilisant pgvector pour la recherche de code gagnent 30-45 minutes par jour. Sur un mois, c'est 10-15 heures récupérées.
Présentation de GrepAI
GrepAI est un projet open source créé par Yoan Bernabeu, développeur français spécialisé dans l'IA et l'architecture logicielle. Le code source est disponible sur GitHub sous licence MIT.
Ce qui distingue GrepAI : l'hybridation. Le système combine recherche vectorielle (pgvector) et recherche lexicale (BM25), puis fusionne les résultats avec l'algorithme RRF (Reciprocal Rank Fusion).
En pratique, cela signifie que si vous cherchez "JWT token validation", GrepAI trouve à la fois les fichiers parlant de tokens (sémantique) ET les fichiers contenant exactement "JWT" (lexical). Le meilleur des deux mondes.
GrepAI est nativement conçu pour le protocole MCP (Model Context Protocol). Zéro configuration pour l'intégrer à Claude Code. Si vous utilisez déjà des skills pour agents IA, GrepAI s'intègre directement dans votre écosystème.
Dans le benchmark de YoanDev, GrepAI surpasse les solutions concurrentes sur plusieurs métriques :
Benchmark 1000 documents (mixed content) ├─ GrepAI (hybrid) → Precision: 0.89, Recall: 0.84, F1: 0.86 ├─ Pure vector → Precision: 0.81, Recall: 0.79, F1: 0.80 ├─ Pure BM25 → Precision: 0.76, Recall: 0.73, F1: 0.74 └─ grep (baseline) → Precision: 0.68, Recall: 0.91, F1: 0.78
Le F1 score de 0.86 signifie un excellent équilibre entre précision et rappel. Vous trouvez ce que vous cherchez sans être noyé dans les faux positifs.
Voici l'architecture simplifiée :
┌─────────────────────────────────────────────────────┐
│ Claude Code (MCP Client) │
└────────────────────┬────────────────────────────────┘
│ MCP protocol
┌──────────▼──────────┐
│ GrepAI MCP Server │
│ - Query processing │
│ - RRF fusion │
│ - Result ranking │
└──────────┬───────────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ pgvector │ │ BM25 │ │ Ollama │
│ (vector) │ │ (lexical)│ │(embedding)│
└──────────┘ └──────────┘ └──────────┘
│ │ │
└────────────┴────────────┘
│
┌─────────▼─────────┐
│ PostgreSQL DB │
│ - embeddings │
│ - full-text idx │
│ - metadata │
└───────────────────┘
Pourquoi j'ai choisi GrepAI plutôt qu'une autre solution ? Quatre raisons pragmatiques.
Local-first : tout s'exécute sur ma machine. Pas de dépendance à un service cloud qui peut disparaître ou augmenter ses prix.
Gratuit : zéro coût récurrent. L'investissement initial est du temps d'installation (2-3h), pas de l'argent.
Intégration native Claude Code : GrepAI parle MCP nativement. Pas de wrapper, pas d'adaptateur custom.
Performances : avec pgvector 0.8.0, les requêtes sont 9× plus rapides qu'avant. Dans mon usage quotidien, je ne vois aucune différence avec une recherche grep classique.
Installer pgvector sur PostgreSQL
pgvector est une extension PostgreSQL qui ajoute le support des vecteurs. Elle transforme votre base relationnelle en vector database.
Prérequis : PostgreSQL 12 ou supérieur. Je recommande 15+ pour les meilleures performances.
Trois méthodes d'installation selon votre environnement.
Méthode 1 : via apt-get (Ubuntu/Debian)
# Ajouter le repository pgvector sudo apt install postgresql-server-dev-15 sudo apt install build-essential git # Cloner et compiler pgvector cd /tmp git clone --branch v0.8.0 https://github.com/pgvector/pgvector.git cd pgvector make sudo make install
Méthode 2 : via Docker (recommandé pour Windows/Mac)
# Image officielle avec pgvector préinstallé docker run -d \ --name grepai-pgvector \ -e POSTGRES_PASSWORD=grepai \ -e POSTGRES_USER=grepai \ -e POSTGRES_DB=grepai \ -p 5433:5432 \ pgvector/pgvector:pg15
Le port 5433 évite les conflits si vous avez déjà un PostgreSQL local. Dans mon cas, j'ai PostgreSQL 15 sur le port 5432 pour mon app principale, et pgvector sur 5433 pour GrepAI.
Méthode 3 : compilation manuelle (production)
# Télécharger la release officielle wget https://github.com/pgvector/pgvector/archive/v0.8.0.tar.gz tar -xzf v0.8.0.tar.gz cd pgvector-0.8.0 # Compiler et installer make make install
Après l'installation, créez la base de données :
-- Se connecter en tant que superuser psql -U postgres -- Créer la base et l'utilisateur CREATE DATABASE grepai; CREATE USER grepai WITH PASSWORD 'grepai'; GRANT ALL PRIVILEGES ON DATABASE grepai TO grepai; -- Se connecter à la base grepai \c grepai -- Activer l'extension pgvector CREATE EXTENSION IF NOT EXISTS vector; -- Vérifier l'installation SELECT extname, extversion FROM pg_extension WHERE extname = 'vector';
Vous devriez voir "vector | 0.8.0" dans les résultats.
Configuration PostgreSQL optimale pour pgvector :
# postgresql.conf shared_buffers = 256MB # Minimum, 25% RAM idéal work_mem = 64MB # Pour les opérations de tri maintenance_work_mem = 128MB # Pour CREATE INDEX effective_cache_size = 1GB # Estimation cache OS
Ces paramètres s'appliquent à une machine avec 4GB RAM minimum. Ajustez proportionnellement si vous avez plus de ressources.
Redémarrez PostgreSQL après modification :
# Linux sudo systemctl restart postgresql # Docker docker restart grepai-pgvector
Vérification finale avec une requête test :
-- Créer une table test avec un vecteur
CREATE TABLE test_vector (
id serial PRIMARY KEY,
embedding vector(768)
);
-- Insérer un vecteur test (768 dimensions)
INSERT INTO test_vector (embedding)
VALUES (array_fill(0.1, ARRAY[768])::vector);
-- Recherche de similarité cosine
SELECT id FROM test_vector
ORDER BY embedding <=> array_fill(0.1, ARRAY[768])::vector
LIMIT 5;
Si cette requête s'exécute sans erreur, pgvector est correctement installé.
Note importante : pgvector 0.8.0 apporte des gains massifs. Les benchmarks EnterpriseDB montrent une vitesse multipliée par 9 et une réduction de coût de stockage de 40-80% comparé à la version 0.6.x.
Installer et configurer GrepAI
L'installation de GrepAI se fait via npm ou bun. Je recommande bun pour la vitesse d'exécution.
# Installation globale via npm npm install -g @yoandev/grepai # Ou via bun (plus rapide) bun install -g @yoandev/grepai # Vérifier l'installation grepai --version # Devrait afficher : grepai/0.30.0 ou supérieur
Configuration de la connexion PostgreSQL. C'est ici que j'ai perdu 30 minutes à cause d'un gotcha.
# Créer le fichier de configuration mkdir -p ~/.grepai touch ~/.grepai/config.yaml
Éditer ~/.grepai/config.yaml :
# GOTCHA: la clé est "dsn", PAS "connection_string" database: dsn: "postgresql://grepai:grepai@localhost:5433/grepai" embedding: provider: "ollama" model: "nomic-embed-text" # GOTCHA Windows: Ollama sur port 11700, PAS 11434 # Hyper-V réserve les ports 11424-11523 base_url: "http://localhost:11700" search: # Hybrid search activé par défaut mode: "hybrid" # RRF weights (vector: 0.7, lexical: 0.3) vector_weight: 0.7 lexical_weight: 0.3
Le piège à éviter : la documentation officielle parle de connection_string, mais le code source attend dsn. J'ai mis 20 minutes à comprendre pourquoi mes connexions échouaient.
Choisir le bon modèle d'embedding. Deux options validées :
Option 1 : nomic-embed-text (recommandé)
# Télécharger le modèle via Ollama ollama pull nomic-embed-text # Caractéristiques: # - 137M paramètres (F16) # - 768 dimensions # - Optimisé pour le texte court (code) # - Vitesse: ~100 tokens/sec sur CPU moyen
Option 2 : Qwen 2.5 (3B paramètres)
ollama pull qwen2.5:3b # Modèle plus gros mais polyvalent # Peut aussi servir pour la review de code et les commit messages # Embedding de qualité supérieure sur du code multilingue
Option 3 : snowflake-arctic-embed2
ollama pull snowflake-arctic-embed2 # Alternative si les deux premiers ne performent pas bien # Plus lent mais parfois plus précis sur du code complexe
J'utilise nomic-embed-text pour les embeddings et Qwen 2.5 pour les analyses complémentaires (review de code, messages de commit). La combinaison des deux couvre tous mes besoins.
Le gotcha Windows/Hyper-V est critique. Par défaut, Ollama écoute sur le port 11434. Hyper-V réserve dynamiquement les ports 11424-11523 sur Windows.
Résultat : Ollama démarre, mais GrepAI ne peut pas s'y connecter. L'erreur est cryptique : "Connection refused".
Solution : modifier le port Ollama dans la variable d'environnement :
# Windows PowerShell (permanent)
[Environment]::SetEnvironmentVariable("OLLAMA_HOST", "127.0.0.1:11700", "User")
# Redémarrer Ollama
taskkill /F /IM ollama.exe
ollama serve
# Vérifier le port
netstat -ano | findstr 11700
Indexer votre premier projet :
# Se placer dans le répertoire du projet cd ~/dev/mon-projet # Lancer l'indexation grepai index # Options utiles: # --exclude "node_modules,dist,build" # --language "typescript,javascript" # --batch-size 50 (plus petit si RAM limitée)
L'indexation de mes 580 fichiers (~45 000 lignes de code) a pris 8 minutes. Le goulot d'étranglement est l'embedding, pas la base de données.
Configurer le serveur MCP pour Claude Code :
# Éditer ~/.claude/settings.json (ou équivalent selon votre OS)
{
"mcpServers": {
"grepai-mon-projet": {
"command": "grepai",
"args": ["mcp-serve", "~/dev/mon-projet"],
"env": {
"GREPAI_CONFIG": "~/.grepai/config.yaml"
}
}
}
}
Attention : grepai mcp-serve prend le chemin du projet en argument positionnel, PAS via un flag --project-path. Encore un gotcha qui m'a coûté 15 minutes.
Redémarrer Claude Code pour charger le nouveau serveur MCP. Vérifier dans les paramètres que "grepai-mon-projet" apparaît dans la liste des MCP actifs.
Test de la recherche :
# Via CLI grepai search "authentification JWT" # Devrait retourner les fichiers pertinents avec leur score # Score > 0.7 = très pertinent # Score 0.5-0.7 = moyennement pertinent # Score < 0.5 = peu pertinent
Si tout fonctionne, vous pouvez maintenant utiliser GrepAI directement depuis Claude Code via les prompts MCP.
Cas d'usage concret avec Claude Code
Mon contexte : 6 projets actifs, 12 agents Claude, 580+ fichiers dans le dossier .claude/. Retrouver le bon agent ou skill devient chaotique sans recherche sémantique.
Cas d'usage réel survenu la semaine dernière. Je voulais comprendre comment mes agents loggent leurs actions pour corriger un bug de corrélation de workflow.
Avec grep classique :
grep -r "logging" ~/.claude/ # Résultat : 73 fichiers # - 45 imports de modules de logging # - 12 commentaires avec le mot "logging" # - 8 logs de debug console.log # - 8 fichiers réellement pertinents # Temps perdu à filtrer : 12 minutes
Avec GrepAI via Claude Code :
Prompt: "Comment les agents loggent leurs actions de manière structurée ?" GrepAI MCP retourne 4 résultats triés par pertinence: 1. ~/.claude/skills/agent-logging/SKILL.md (score: 0.94) 2. ~/.claude/agents/action-logger.md (score: 0.89) 3. ~/.claude/agents/content-orchestrator.md (score: 0.76) 4. ~/.claude/hooks/post-tool-use/log-agent-action.ts (score: 0.71) Temps total : 30 secondes
Le premier résultat était exactement ce dont j'avais besoin : le skill agent-logging qui définit le format JSONL et les règles de corrélation.
Comparaison chiffrée de productivité :
| Tâche | Sans GrepAI | Avec GrepAI | Gain |
|---|---|---|---|
| Trouver skill logging | 12 min | 30 sec | 96% |
| Identifier usages d'un agent | 8 min | 45 sec | 91% |
| Recherche documentation pattern | 15 min | 2 min | 87% |
| Exploration nouveau projet | 45 min | 12 min | 73% |
| Moyenne pondérée | 20 min | 3.8 min | 81% |
Sur une journée de développement avec 10-15 recherches, je gagne 2-3 heures. Sur un mois, c'est 40-60 heures récupérées.
Google Research a publié une étude en 2024 sur l'impact de la recherche sémantique chez leurs développeurs. Résultat : 21% de gain de productivité sur les tâches de refactoring et documentation.
Moderne.ai rapporte des gains encore plus importants : 35% de temps gagné sur les tâches d'exploration de codebase pour les nouveaux membres d'équipe.
Dans mon expérience personnelle, les gains sont variables selon le type de tâche. Exploration et documentation : 60-80% de gain. Debugging précis : 20-30% seulement (grep reste souvent meilleur ici).
Anecdote personnelle : j'ai lancé un refactoring de mes 12 agents la semaine dernière. Objectif : centraliser la gestion des tokens et du logging. Ce type de débugage d'applications construites par l'IA est devenu mon quotidien.
Sans GrepAI, j'aurais passé 2-3 jours à identifier tous les fichiers concernés. Avec GrepAI, 4 heures suffisaient pour cartographier l'architecture et planifier le refactoring.
Le ROI est évident : 2-3h d'installation pour des dizaines d'heures gagnées par mois.
Vision future — connecter toutes vos sources
GrepAI aujourd'hui indexe votre code et vos fichiers locaux. Mais le potentiel du RAG va bien au-delà.
Ma vision : un hub MCP central qui connecte TOUTES vos sources de données professionnelles. Code, emails, tickets OpenProject, calendrier, messages Slack, documentation Confluence.
Imaginez ce scénario. Vous demandez à Claude : "Pourquoi le projet X a pris du retard ?"
Claude interroge via MCP :
- GrepAI pour analyser les commits récents (fréquence, complexité)
- Votre client email pour retrouver les échanges avec le client
- OpenProject pour lister les tickets bloqués
- Votre calendrier pour identifier les réunions de crise
- Slack pour détecter les mentions de "blocage" ou "problème"
Réponse en 10 secondes avec sources citées. Difficilement réalisable en moins d'une heure avec grep et une recherche manuelle.
L'architecture serait extensible :
┌──────────────────────────────────────┐
│ Claude Code (MCP Hub) │
└──────────────┬───────────────────────┘
│
┌──────────┼──────────┬──────────┬────────┐
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
┌────────┐ ┌───────┐ ┌────────┐ ┌────────┐ ┌──────┐
│GrepAI │ │ Email │ │ Calendar│ │ Slack │ │ Jira │
│ MCP │ │ MCP │ │ MCP │ │ MCP │ │ MCP │
└───┬────┘ └───┬───┘ └────┬────┘ └───┬────┘ └───┬──┘
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
┌────────────────────────────────────────────────┐
│ Unified Vector Storage (pgvector) │
│ - Code embeddings │
│ - Email embeddings │
│ - Ticket embeddings │
│ - Message embeddings │
│ - Calendar event embeddings │
└────────────────────────────────────────────────┘
Chaque source aurait son serveur MCP dédié. Le protocole MCP standardise l'interface, peu importe la source.
Contrairement à des solutions cloud comme Notion AI ou ChatGPT Enterprise, tout reste local ou self-hosted. Vos emails ne quittent jamais votre serveur.
VentureBeat prédit que 67% des entreprises auront adopté une forme de RAG multi-source d'ici 2027. La confidentialité des données devient un critère de choix majeur.
Le piège à éviter : la surcharge d'information. Connecter 10 sources sans stratégie de filtrage produira plus de bruit que de signal.
Ma recommandation : commencer par 2-3 sources critiques (code + tickets + documentation). Valider l'usage pendant 1-2 mois. Ajouter progressivement d'autres sources selon les besoins.
Le protocole MCP rend cette vision réaliste. Chaque source est un plugin indépendant. Vous contrôlez quelles données sont indexées et comment.
Dans mon cas, je prévois de connecter OpenProject (tickets) et mon client email dans les 3 prochains mois. Le code existe déjà dans les specs MCP, il suffit de l'implémenter.
Conclusion
GrepAI couplé à pgvector transforme votre codebase en mémoire sémantique persistante. Fini le temps perdu à chercher du code avec grep.
Les bénéfices sont mesurables : 30-60% de gain de temps sur les tâches de recherche et exploration. Sur un mois, c'est 40-60 heures récupérées pour coder au lieu de chercher.
L'installation demande 2-3 heures. Le ROI est atteint en moins d'une semaine d'usage régulier.
Privacy, performance, coût zéro : GrepAI coche toutes les cases pour une solution locale. Pas de dépendance à un service cloud qui peut changer ses prix ou fermer du jour au lendemain.
La vision future est encore plus excitante. Connectez toutes vos sources de données via MCP pour créer une véritable mémoire augmentée. J'explore déjà comment générer des débats audio par IA à partir de cette base de connaissances.
Mon appel à l'action : installez GrepAI ce week-end. Testez pendant une semaine. Mesurez votre gain de temps.
Ensuite, partagez votre expérience. Quels cas d'usage vous ont le plus surpris ? Quelles optimisations avez-vous découvertes ?
Et la question qui me fascine : quelle sera votre prochaine source de données à connecter ? Emails ? Tickets ? Messages ? Calendrier ? Répondez-moi par email, j'aimerais connaître vos priorités.
Qui suis-je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le cœur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, envoyez-moi un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écris par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.
Installer une mémoire IA locale pour vos projets de développement