sqlite-utils 4.0 : quand l'IA Claude Fable livre une release open source

Le 5 juillet 2026, Simon Willison, créateur de sqlite-utils et de Datasette, a publié le récit complet et documenté de la sortie de sqlite-utils 4.0rc2 : une release candidate rédigée quasiment en intégralité par l'agent Claude Fable, pour un coût estimé à 149,25 dollars. Pas une démo, pas un proof of concept : un correctif réel sur une bibliothèque Python utilisée par des milliers de développeurs, avec des bugs critiques trouvés, corrigés et documentés au fil de l'eau.

Ce cas mérite qu'on s'y attarde, au-delà du hype habituel sur les agents IA. Il est rare d'avoir un chantier de cette ampleur documenté de bout en bout : pull requests publiques, transcripts partagés, coût détaillé au centime près.

sqlite-utils et Simon Willison, en quelques mots

sqlite-utils est un outil en ligne de commande et une bibliothèque Python qui permet de manipuler des bases SQLite sans écrire de SQL à la main : créer des tables, insérer des données, gérer des index ou de la recherche plein texte. Willison, qui maintient également Datasette, applique une politique stricte de compatibilité (semver) et cherche à limiter au maximum les versions majeures incompatibles. Avant de figer la version 4.0 stable, il voulait une dernière relecture complète du code, exhaustive, avant que la porte ne se referme sur d'éventuelles ruptures de compatibilité.

Un prompt, cinq bugs bloquants

Willison a lancé la demande dans Claude Code for web, depuis son iPhone, avec un prompt volontairement simple : repérer, avant la sortie stable, tout ce qui constituerait une rupture de compatibilité s'il fallait le corriger plus tard. Résultat : un rapport détaillé, dans lequel l'agent a lui-même classé cinq problèmes comme release blockers, des bugs bloquants pour une mise en production.

Le bug qui aurait pu corrompre des bases en production

Le plus grave concernait la méthode Table.delete_where(), qui exécutait sa requête DELETE via un simple self.db.execute(), sans l'enrober dans un atomic(), contrairement à Table.delete() qui le fait correctement. Conséquence : la connexion restait bloquée en in_transaction=True, et tous les appels atomic() suivants prenaient alors la branche savepoint sans jamais valider la transaction.

En clair, après un appel à delete_where(), toutes les écritures suivantes, y compris sur d'autres tables, pouvaient être silencieusement perdues à la fermeture de la connexion. La reproduction fournie par l'agent est parlante :

db = sqlite_utils.Database("dw.db")
db["t"].insert_all([{"id": i} for i in range(3)], pk="id")
db["t"].delete_where("id = ?", [0])
# conn.in_transaction vaut maintenant True
db["t"].insert({"id": 50})
db["u"].insert({"a": 1})
db.close()
# A la reouverture : les lignes sont [0, 1, 2].
# La suppression, la ligne 50 et la table u ont toutes disparu.

Un bug de perte de données, dans une bibliothèque déjà passée par une première release candidate, sur une fonctionnalité aussi banale qu'une suppression de lignes. Willison le dit lui-même : il est très content de ne pas l'avoir découvert après coup.

37 prompts, 34 commits, un défilé du 4 juillet

Au fil de 37 prompts et 34 commits, avec 1 321 lignes ajoutées et 190 supprimées sur 30 fichiers, Willison a traité un par un les points soulevés, ajoutant au passage plusieurs améliorations de conception. Il a suivi une partie du travail depuis son téléphone en assistant au défilé du 4 juillet à Half Moon Bay, avant de reprendre la relecture finale sur ordinateur portable, directement dans l'interface des pull requests de GitHub.

Un nouveau modèle transactionnel, documenté par l'IA elle-même

Le chantier touchait aussi la fonctionnalité phare de la précédente RC : la gestion des transactions. La nouvelle documentation, en grande partie rédigée par l'agent, résume la règle centrale de la bibliothèque :

db = Database("data.db")
db.table("news").insert({"headline": "Un chien remporte un prix"})
# La nouvelle ligne est deja enregistree, aucun commit() requis

Chaque méthode d'écriture (insert(), upsert(), update(), delete(), delete_where(), transform(), create_table(), create_index(), enable_fts(), et les autres) s'exécute désormais dans sa propre transaction et la valide avant de retourner la main. Aucun commit() manuel n'est nécessaire, sauf dans deux cas précis : regrouper plusieurs écritures avec db.atomic(), ou gérer soi-même une transaction avec db.begin().

En relisant cette documentation (une méthode qu'il recommande pour comprendre rapidement l'ampleur d'un changement), Willison a découvert un angle mort qu'il n'avait pas anticipé : le mode autocommit introduit par Python 3.12 sur les connexions SQLite n'est pas compatible avec ce modèle. La quasi-totalité de la suite de tests échouait dans ce mode, et il a fallu retravailler avec l'agent pour que la bibliothèque s'en accommode correctement.

GPT-5.5 relit le travail de Claude Fable, et trouve deux bugs de plus

Willison confie avoir longtemps trouvé un peu absurde l'idée de faire relire le travail d'un modèle par un autre. Il a changé d'avis : il fait désormais relire systématiquement les productions d'Anthropic par les modèles d'OpenAI, et inversement, parce que ça fait remonter des résultats intéressants assez souvent pour être utile. Sur ce projet, il a demandé à Codex Desktop et GPT-5.5 de revoir les changements depuis la dernière RC et de confirmer que le changelog était à jour.

Deux problèmes classés P1 (priorité haute) sont remontés :

• db.query() valide trop tard. La méthode vérifie qu'une requête retourne bien des lignes seulement après avoir appelé db.execute(), qui a déjà committé les écritures entre-temps. Un db.query("update ...") finit par lever une erreur, mais la mise à jour a déjà été appliquée.
• INSERT RETURNING ne commit pas toujours. Pour les requêtes INSERT ... RETURNING passées via db.query(), le commit n'intervenait qu'une fois le générateur entièrement épuisé. Un usage aussi courant que next(db.query(...)) laissait la transaction ouverte, ce qui contredisait la documentation et le changelog.

Willison a soumis ce rapport à une nouvelle session Claude Fable, qui a confirmé les deux bugs par l'expérimentation avant de les corriger.

Le prix réel d'une release critique écrite par IA

Curieux de connaître le coût réel de la session, Willison a fait tourner l'outil open source AgentsView directement depuis sa session Claude Code for web. Détail du calcul obtenu :

• Session principale (claude-fable-5) : 141,02 dollars
• Agent de relecture de l'API : 2,40 dollars
• Agent de relecture des transactions et de atomic() : 2,39 dollars
• Agent de relecture des commits post-rc1 : 1,72 dollar
• Agent de relecture des migrations : 1,40 dollar
• Agent de comptage de prompts (claude-opus-4-8) : 0,32 dollar
• Total : 149,25 dollars

Willison précise avoir upgradé son abonnement Claude Max de 100 à 200 dollars par mois pour disposer d'un quota Fable suffisant avant le 7 juillet, date à laquelle même les abonnés Max devront payer le tarif API plein pour ce modèle. Il reconnaît aussi qu'il aurait dû, par cohérence avec ses propres conseils, déléguer davantage de tâches à des sous-agents tournant sur des modèles moins chers : le sous-agent à 0,32 dollar sous Opus a fait le travail aussi bien que les autres, pour huit fois moins cher.

Notre lecture chez CZSyn

Ce qui rend ce cas intéressant, ce n'est pas que l'IA ait écrit du code : c'est la transparence totale du processus. Pull requests publiques, transcripts partagés, coût détaillé au centime près. Ça change du discours marketing habituel sur les agents qui « livrent en production ». Et le détail le plus instructif n'est pas la performance de l'agent, mais ce qu'il a fallu autour pour la sécuriser : un mainteneur expérimenté qui relit la documentation avant le code, une seconde IA d'un fournisseur concurrent pour l'audit croisé, et une méthodologie de test poussée jusqu'à découvrir un cas limite lié à une fonctionnalité récente de Python. Trois filtres, pas un seul.

Pour une PME ou une équipe de développement française qui envisage de confier des tâches de maintenance à un agent, la leçon est directement transposable : ne jamais fusionner du code d'agent qui touche à la persistance, aux transactions ou à la concurrence sans une relecture dédiée à ces points précis, idéalement par un second modèle. C'est l'inverse du narratif où l'IA remplacerait le développeur : ici, l'agent a fait gagner un temps considérable sur l'exécution, mais le jugement humain, et un second regard IA, reste ce qui a évité un bug de perte de données en production.

Le chiffre de 149,25 dollars donne aussi une base de comparaison concrète pour budgétiser ce type de chantier, à condition de garder à l'esprit qu'il s'agit d'un tarif subventionné par un abonnement, pas du coût API brut. Chez CZSyn, nous appliquons ce même principe sur les projets clients où des agents IA touchent à du code de production : jamais de fusion automatique sur les couches de persistance, systématiquement une passe de relecture ciblée sur l'état et la concurrence avant mise en ligne.

Sources primaires

• Simon Willison, « sqlite-utils 4.0rc2, mostly written by Claude Fable », 5 juillet 2026.
• Documentation officielle, sqlite-utils.datasette.io.
• Dépôt officiel, github.com/simonw/sqlite-utils.