Base de données vectorielle et embeddings : est-ce que ton agent en a vraiment besoin ?
Tu as probablement vu passer le terme « base de données vectorielle » une bonne dizaine de fois cette année. Pinecone, Weaviate, Qdrant, Chroma. Chaque outil promet de rendre ton agent IA plus intelligent, plus rapide, plus pertinent.
Et si je te disais que tu n’en as probablement pas besoin ?
Pas parce que la technologie est mauvaise. Parce que ton cas d’usage ne la justifie pas. La plupart des solopreneurs qui bricolent un agent pour leurs docs, leurs clients ou leurs process tournent avec 10, 50, parfois 200 documents. Pas 100 000. Et à cette échelle, une base vectorielle, c’est une Ferrari pour aller chercher le pain.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Je vais te montrer ce que fait vraiment une base vectorielle, à quel moment elle devient utile, et ce que tu peux utiliser à la place quand ton besoin est plus simple.
Ce que fait une base vectorielle
Une base de données vectorielle stocke des vecteurs. Un vecteur, c’est une liste de nombres qui représente le sens d’un texte dans un espace mathématique. Deux phrases qui veulent dire la même chose auront des vecteurs proches. Deux phrases sans rapport auront des vecteurs éloignés.
Quand tu fais une recherche, la base vectorielle ne cherche pas un mot exact. Elle cherche les vecteurs les plus proches de ta question. C’est ce qu’on appelle la recherche sémantique : tu peux demander « comment réduire mes impôts » et tomber sur un document qui parle d’optimisation fiscale, même si le mot « impôts » n’apparaît pas dedans.
Le vrai intérêt d’une base vectorielle dédiée, c’est la performance à grande échelle. Indexer des millions de vecteurs, répondre en quelques millisecondes, filtrer par métadonnées, tout ça en parallèle. Si tu as 500 000 documents et que tu veux une recherche sémantique instantanée, Pinecone ou Qdrant sont faits pour toi.
Mais si tu as 30 notes dans un dossier, le calcul est différent.
Le rôle des embeddings
Avant de parler des cas concrets, il faut distinguer deux choses qu’on mélange souvent : les embeddings et la base vectorielle.
Un embedding, c’est la transformation d’un texte en vecteur. C’est le modèle d’embedding qui fait ce travail (OpenAI text-embedding-3-small, Cohere, ou un modèle local comme all-MiniLM). La base vectorielle, elle, ne fait que stocker et chercher ces vecteurs.
Tu peux parfaitement utiliser des embeddings sans base vectorielle. Un fichier JSON avec des vecteurs et un calcul de similarité cosinus en Python, ça marche pour quelques centaines de documents. Pas besoin d’infrastructure supplémentaire.
Le raccourci « embedding = base vectorielle » est faux. Et c’est ce raccourci qui pousse des solopreneurs à installer Chroma ou Pinecone alors qu’un script de 30 lignes ferait le job.
Cas 1 : recherche sémantique dans des centaines de documents
Imagine que tu as 500 notes clients, 300 articles de base de connaissance, ou un historique de 800 conversations. Tu veux qu’un agent puisse chercher dedans avec des questions en langage naturel, pas avec des mots-clés exacts.
Ici, une base vectorielle commence à avoir du sens. Pas forcément un service cloud payant : Chroma ou LanceDB en local font très bien le travail pour quelques milliers de documents. Tu charges tes embeddings une fois, tu interroges en langage naturel, et la latence reste sous la seconde.
Mais même à cette échelle, pose-toi la question : est-ce que la recherche plein texte ne suffirait pas ? Si tes documents sont structurés, si les termes utilisés sont cohérents, une recherche classique avec SQLite FTS5 ou PostgreSQL full-text search peut couvrir 90 % des besoins. La recherche sémantique brille quand le vocabulaire est varié, quand les questions sont formulées différemment des documents sources, ou quand tu cherches des concepts plutôt que des termes.
Cas 2 : recherche plein texte dans une dizaine de docs
C’est le cas le plus fréquent chez les solopreneurs. Tu as 15 notes Obsidian, 8 PDFs de contrats, 3 fichiers de process. Tu veux qu’un agent retrouve une info dedans.
La réponse la plus simple, c’est la recherche plein texte. Un grep bien placé, un index FTS5 dans SQLite, ou même la recherche intégrée de ton outil de notes. Pas d’embedding, pas de vecteur, pas de base spécialisée.
Hermes Agent, par exemple, stocke sa mémoire dans deux fichiers texte : MEMORY.md et USER.md. La recherche se fait avec FTS5, un moteur de recherche plein texte intégré à SQLite. Pas de base vectorielle. Et ça suffit pour retrouver une préférence utilisateur, un fait d’environnement ou une leçon apprise il y a trois semaines.
Le point important : la mémoire d’un agent n’a pas besoin d’être sémantique pour être utile. Si tu cherches « Docker » et que le mot « Docker » est dans la note, FTS5 le trouve. Si ta note parle de conteneurs sans jamais dire Docker, c’est peut-être ta note qu’il faut améliorer, pas ton infrastructure de recherche.
Cas 3 : mémoire de conversation
Un agent qui se souvient de ce que tu lui as dit la semaine dernière, c’est utile. Mais la question, c’est comment il s’en souvient.
La mémoire d’un agent peut prendre plusieurs formes. La plus simple : un résumé injecté dans le prompt au début de chaque session. C’est ce que fait Hermes avec ses fichiers MEMORY.md et USER.md. L’agent lit ces notes en début de session, et ça lui suffit pour savoir qui tu es, quel est ton projet, et ce qu’il a appris.
Pour aller plus loin, tu peux utiliser ce qu’on appelle le RAG pour solopreneur : l’agent cherche dans l’historique des conversations passées les messages pertinents pour la question en cours, et les ajoute au contexte. Là encore, la recherche plein texte suffit dans la majorité des cas. Les conversations sont datées, elles contiennent des termes précis, et le volume reste gérable pour un solopreneur.
Quand la base vectorielle est indispensable
Il y a des cas où une base vectorielle n’est pas un luxe. Les voici, sans détour :
- Tu as plus de 10 000 documents et la latence de recherche devient un problème.
- Tu fais de la recherche sémantique cross-lingue : une question en français doit matcher des documents en anglais.
- Tu as besoin de recherche multimodale : trouver une image à partir d’une description textuelle.
- Tu construis un moteur de recommandation basé sur la similarité de contenu.
- Tu gères des mises à jour fréquentes sur un gros volume et tu as besoin de réindexer sans tout recalculer.
Si aucun de ces cas ne te concerne, tu peux probablement te passer d’une base vectorielle. Et économiser du temps, de la complexité et de l’argent.
Alternatives plus simples
Voici ce que tu peux utiliser selon ton volume et ton besoin, du plus simple au plus avancé :
- Grep / ripgrep : pour moins de 50 fichiers texte. Instantané, zéro setup.
- SQLite FTS5 : recherche plein texte avec ranking, snippets, et filtres. Intégré dans SQLite, pas de serveur à gérer.
- Embeddings + cosine similarity en Python : pour quelques centaines de documents. Un fichier JSON ou pickle, numpy, et c’est réglé.
- Chroma / LanceDB en local : si tu veux une API propre sans sortir de ta machine. Pas de cloud, pas de facture.
- Pinecone / Qdrant / Weaviate : quand tu passes à l’échelle et que le local ne suffit plus.
La règle que j’applique : commence par le plus simple qui marche. Si FTS5 fait le job, ne passe pas aux embeddings. Si un script Python avec numpy fait le job, n’installe pas Chroma. Tu ajouteras de la complexité quand le besoin sera là, pas avant.
Un agent IA utile, ce n’est pas une stack technologique impressionnante. C’est un système qui retrouve la bonne info au bon moment, avec le minimum de pièces mobiles. Et souvent, cette info tient dans un fichier texte de 2 200 caractères.
Si tu veux construire un agent qui se souvient de ton business sans te compliquer la vie, rejoins Kavyro gratuitement et commence à constituer ton équipe IA. On a déjà fait l’arbitrage pour toi.
