Un agent IA qui tourne accumule de la mémoire : historiques de conversation, traces d’outils, résultats mis en cache. Et il range cette mémoire dans un endroit qu’on croyait jetable, un simple fichier SQLite posé sur le disque.
Sauf que ce fichier ne se régénère plus à chaque déploiement. Ce n’est plus la base qu’on recrée en trois lignes, c’est la mémoire de travail d’un agent qui doit survivre aux versions du code. La sortie de sqlite-utils 4.0 cette semaine est le dernier signal que l’écosystème prend enfin ce virage au sérieux.
Pourquoi un agent a besoin d’une mémoire qui dure
Un modèle, seul, n’a pas de mémoire : chaque appel repart d’une page blanche. Tout ce qui ressemble à de la continuité (se souvenir de la conversation d’hier, reprendre une tâche interrompue, ne pas refaire deux fois le même appel d’outil) est de l’état que le code autour du modèle doit stocker quelque part.
Et ce quelque part, en local, c’est massivement SQLite : sans serveur, transactionnel, trivial à embarquer. LangGraph, l’un des frameworks d’agents les plus répandus, écrit nativement l’état des conversations dans un fichier SQLite via son checkpointer dédié. Simon Willison, l’auteur de sqlite-utils, journalise lui-même chaque prompt et chaque réponse de son outil llm dans une base SQLite. Et Letta, l’ex-MemGPT, calque carrément la mémoire d’un agent sur celle d’un système d’exploitation : une mémoire vive toujours en contexte, une mémoire d’archive externe, un journal de conversation paginable, le tout persisté dans une base.
Le point commun de ces trois approches : la mémoire d’un agent n’est plus un cache qu’on vide, c’est un actif qu’on conserve. Et dès qu’on conserve, la question du schéma versionné devient inévitable.
Ce que sqlite-utils 4.0 vient régler
sqlite-utils est la bibliothèque Python et l’outil en ligne de commande de Simon Willison pour manipuler des bases SQLite. La version 4.0, sortie en première version candidate, ajoute deux briques qui parlent directement à ce besoin de mémoire durable.
La première, ce sont les migrations versionnées. Vous décrivez vos évolutions de schéma dans un fichier migrations.py, chaque fonction décorée représentant une étape : créer une table, ajouter une colonne. Puis vous appliquez le tout, en Python ou via la commande sqlite-utils migrate. Concrètement, c’est ce qui permet à la mémoire d’un agent d’évoluer sans être effacée : on fait passer la base d’une version à l’autre au lieu de la régénérer. Le code reprend le paquet sqlite-migrate que Willison maintenait depuis des années, déjà utilisé par son outil llm. Une mécanique éprouvée, pas un prototype.
La seconde, c’est db.atomic(), une abstraction pour les transactions imbriquées. SQLite les gère depuis longtemps via les savepoints, mais l’API restait rugueuse. Le nouveau contexte, emprunté à Django et Peewee, permet d’imbriquer un bloc transactionnel dans un autre : si l’interne échoue, on l’annule sans faire tomber l’externe. Utile dès qu’un agent enchaîne plusieurs écritures qui doivent réussir ou échouer ensemble. Willison le dit lui-même, cette partie est moins éprouvée que les migrations et mérite des testeurs.
Pourquoi maintenant, et pas il y a cinq ans
Le détail qui compte n’est pas la fonction, c’est sa date. Les migrations existent depuis des décennies côté PostgreSQL ou MySQL. Les voir débarquer proprement dans l’écosystème SQLite en 2026 n’a rien d’anodin.
Pendant longtemps, SQLite a occupé une case mentale précise : la base jetable. On l’embarquait dans une application mobile, on s’en servait pour un script, on la régénérait à volonté. Personne ne se souciait de versionner le schéma d’un fichier qu’on pouvait recréer en trois lignes.
Ce qui a bougé, c’est l’usage, et l’IA en est le moteur. Les architectures d’agents ont besoin d’une persistance locale fiable et évolutive, et elles la posent dans SQLite. À partir du moment où ce fichier survit à plusieurs versions du code, on ne régénère plus la mémoire d’un agent à chaque déploiement : on la fait migrer. L’outillage ne fait que rattraper un usage que l’IA a imposé.
Ce qu’il faut anticiper si vous construisez des agents
Si vous bâtissez des agents qui gardent de la mémoire, ou des pipelines de données locaux qui les alimentent, deux réflexes s’imposent dès maintenant.
- Traitez vos fichiers SQLite comme une vraie base : versionnez le schéma au lieu de le faire évoluer à la main. La 4.0 vous en donne enfin l’outil intégré, sans dépendance externe.
- Surveillez la rupture de compatibilité de cette version majeure. Les opérations d’upsert passent désormais à la syntaxe
INSERT ... ON CONFLICTde SQLite pour toutes les versions postérieures à 3.23.1. Le comportement change légèrement par rapport à l’ancienINSERT OR IGNOREsuivi d’unUPDATE; une optionuse_old_upsert=Truepermet de revenir à l’ancien mode si votre code en dépendait. Python 3.8 disparaît, 3.13 entre.
Le système de migrations est par ailleurs volontairement minimal : pas de migrations inverses. Une erreur ne s’annule pas, elle se corrige en déployant une nouvelle migration par-dessus. Un choix de discipline qui privilégie la simplicité au filet de sécurité, à chacun de juger s’il tient à l’échelle de sa propre dette de schéma.
Le point de bascule à surveiller
Posons le pari. Dans les dix-huit mois, manipuler la mémoire d’un agent ressemblera de moins en moins à du bricolage et de plus en plus à de la gestion de base « sérieuse », migrations et transactions robustes comprises.
Mais le vrai basculement ne se jouera pas à la sortie de la version stable de sqlite-utils. Il se jouera le jour où des frameworks d’agents grand public livreront, par défaut, un schéma SQLite versionné avec migrations intégrées, comme on livre aujourd’hui un fichier de configuration. Ce jour-là, la mémoire d’un agent ne sera plus un fichier qu’on régénère mais une base qu’on fait évoluer dans le temps. sqlite-utils 4.0 est l’un des premiers outils à parier là-dessus. Reste à savoir quels frameworks suivront, et à quelle vitesse.
