Si vous regardez comment la plupart des systèmes de mémoire d’agents IA en production sont architecturés, vous trouverez un schéma familier : une base de données vectorielle comme Pinecone ou Weaviate pour la recherche sémantique, Elasticsearch ou OpenSearch pour la recherche par mots-clés, Redis pour mettre en cache les mémoires chaudes, et Postgres pour les données structurées. Quatre services à déployer, quatre services à surveiller, quatre services qui peuvent tomber en panne, quatre factures à la fin du mois.
La complexité est traitée comme inévitable — le prix à payer pour une mémoire capable. Mais elle ne l’est pas. C’est la conséquence d’avoir recours à des outils de systèmes distribués pour résoudre un problème qui n’en a pas besoin.
La mémoire de ZeroClaw est un seul fichier SQLite. Voici pourquoi ce n’est pas un compromis.
Le piège de l’infrastructure
Les bases de données vectorielles sont de vrais outils puissants. Pour un système RAG sur des millions de documents, ou un moteur de recherche sur un large corpus, elles sont le bon choix. Mais la mémoire d’un agent IA est un problème différent.
La plupart des agents stockent des milliers de souvenirs, pas des millions. Une année de conversations quotidiennes peut produire 50 000 tours de conversation. Ce n’est pas un problème de big data — c’est un petit problème de données traité comme un grand parce que les outils ont été conçus pour autre chose.
Le coût de ce décalage est réel. Pinecone commence à 70 €/mois pour un usage en production. Weaviate nécessite un serveur en cours d’exécution. Chaque recherche en mémoire est un aller-retour réseau — typiquement 10 à 50 ms — qui ajoute de la latence à chaque réponse. Votre mémoire est stockée dans un format propriétaire qui rend la migration pénible. Et vous avez ajouté un autre service à votre surface opérationnelle : encore une chose à surveiller, à mettre à jour, qui peut tomber à 3h du matin.
Pour un agent IA tournant sur un Raspberry Pi ou un VPS à 5 €, cette architecture n’est tout simplement pas viable. Mais même pour des déploiements bien dotés en ressources, la complexité ne vous apporte rien qu’une approche plus simple ne puisse fournir.
Pourquoi SQLite est la bonne fondation
SQLite est la base de données la plus déployée au monde. Elle tourne sur chaque smartphone, chaque navigateur, chaque appareil embarqué. Elle est en développement continu depuis 2000, dispose d’une suite de tests exhaustive, et est utilisée en production par des entreprises gérant des milliards de transactions. Ce n’est absolument pas un jouet.
Ce qui la rend adaptée à la mémoire d’agent spécifiquement, c’est la combinaison de propriétés qu’elle offre : conformité ACID avec le mode WAL pour les lectures concurrentes, zéro configuration (pas de serveur, pas d’identifiants, pas de setup), un seul fichier portable contenant toute votre mémoire, et des caractéristiques de performance difficiles à battre pour les patterns d’accès que les agents utilisent réellement.
ZeroClaw utilise deux extensions SQLite ensemble pour construire un système de mémoire qui gère les deux choses dont les agents ont besoin : le rappel exact et la compréhension sémantique.
FTS5 : recherche plein texte
L’extension FTS5 de SQLite fournit une recherche rapide par mots-clés avec classement BM25 :
```sql CREATE VIRTUAL TABLE memory_fts USING fts5(content, tokenize='porter');
-- Recherche de souvenirs sur “Rust deployment” SELECT * FROM memory_fts WHERE memory_fts MATCH 'rust deployment' ORDER BY rank; ```
FTS5 gère la tokenisation, le stemming et le classement automatiquement. C’est rapide — sous la milliseconde pour les tailles de mémoire typiques d’un agent — et excelle dans le rappel exact. Quand vous devez retrouver un fait précis, un nom spécifique ou un terme technique particulier, la recherche par mots-clés le trouve de façon fiable.
Recherche vectorielle : similarité sémantique
ZeroClaw stocke les vecteurs d’embedding aux côtés du texte et effectue une recherche de similarité cosinus directement dans SQLite. Cela gère les cas où la recherche par mots-clés est insuffisante : trouver des souvenirs conceptuellement liés même quand ils ne partagent pas de mots exacts.
“Mon installation Raspberry Pi” correspond à “déploiement sur matériel ARM” même s’ils ne partagent aucun mot-clé. “La date limite du projet” correspond à “c’est pour quand” même si la formulation est complètement différente. La recherche vectorielle comprend le sens, pas seulement les mots.
Recherche hybride : obtenir les deux
Aucune approche seule n’est suffisante. La recherche par mots-clés rate les connexions sémantiques — “voiture” ne trouvera pas “automobile”. La recherche vectorielle rate les correspondances exactes — chercher “CVE-2026-25253” pourrait retourner du contenu vaguement lié à la sécurité plutôt que le CVE spécifique que vous cherchez.
ZeroClaw exécute les deux recherches en parallèle et fusionne les résultats avec la Reciprocal Rank Fusion :
``` score(doc) = 1/(k + rank_fts) + 1/(k + rank_vector) ```
Où `k` est une constante (typiquement 60) qui contrôle le poids accordé aux résultats les mieux classés. Les documents bien classés dans les deux recherches remontent en haut. Les documents qui ne correspondent qu’à une méthode apparaissent quand même, mais plus bas. Le résultat est une récupération de mémoire qui gère correctement à la fois “qu’est-ce que j’ai dit exactement sur X” et “qu’est-ce que j’ai dit en rapport avec X”.
Les chiffres de performance
Sur un Raspberry Pi Zero 2 W — le matériel le plus contraint sur lequel ZeroClaw tourne couramment — la récupération de mémoire prend moins de 3 ms au total : environ 0,3 ms pour la recherche FTS5, 2 ms pour la recherche vectorielle, et 0,1 ms pour fusionner les résultats. Sur matériel x86, ces chiffres sont sous la milliseconde.
Pour comparaison, un aller-retour réseau vers Pinecone ou Weaviate prend typiquement 10 à 50 ms. La récupération de mémoire de ZeroClaw est plus rapide que le temps qu’il faut à un seul paquet réseau pour traverser une ville.
Votre mémoire n’est qu’un fichier
La conséquence pratique de la mémoire basée sur SQLite, c’est que tout votre historique de conversation, tout le contexte appris par votre agent, tout ce qu’il sait de vous — vit dans un seul fichier appelé `memory.db`.
Le sauvegarder, c’est `cp memory.db memory.db.bak`. Le déplacer sur une nouvelle machine, c’est copier le fichier. L’inspecter, c’est l’ouvrir avec n’importe quel client SQLite. Pas d’outils d’export, pas de scripts de migration, pas d’appels API. C’est un fichier, et les fichiers sont le format de données le plus portable, le plus compris, le plus durable qui existe.
C’est plus important qu’il n’y paraît. Quand votre mémoire est dans Pinecone, elle est dans le format de Pinecone, sur les serveurs de Pinecone, accessible via l’API de Pinecone. Quand Pinecone change ses tarifs, son API, ou tombe en panne, votre mémoire est affectée. Quand votre mémoire est dans un fichier SQLite sur votre machine, rien de tout cela ne s’applique.
Zéro infrastructure, zéro coût, zéro complexité, et des performances que les bases de données externes ne peuvent pas égaler parce qu’il n’y a pas de réseau entre les deux. Pour la mémoire d’un agent IA, ce n’est pas un compromis — c’est la bonne conception.