Simon Willison a publié un outil web qui exécute tes requêtes SQL sur une base de données SQLite dans le navigateur et t’explique, ligne par ligne, ce que le moteur fait sous le capot. Il prend la sortie de EXPLAIN QUERY PLAN et du bytecode bas niveau de EXPLAIN, et l’annote avec des descriptions en langage simple.

Pourquoi ça te concerne. Comprendre ce que fait le query planner, c’est la différence entre une requête qui répond en 50 millisecondes et une qui scanne toute la table. Jusqu’à présent, il y avait deux options : apprendre à lire la sortie de EXPLAIN à l’œil nu (difficile, peu de gens le font vraiment), ou coller la requête dans une discussion avec un LLM à chaque fois (ça marche, mais ne construit pas une compréhension durable). Cet outil se situe entre les deux : il te montre le plan réel avec des annotations, donc tu apprends en regardant, pas en demandant.

Il l’a construit avec Claude Fable, le même outil avec lequel il a récemment réécrit sqlite-utils, après avoir lu un article de Julia Evans où elle disait qu’elle voulait apprendre à lire les query plan de SQLite.

Une limite déclarée : Willison écrit lui-même qu’il ne sait pas assez sur les query plan de SQLite pour vérifier les résultats. Les explications doivent être considérées comme une aide pour apprendre, pas comme la vérité définitive.

Si tu veux l’essayer, l’outil est public et ne nécessite pas d’installation : ouvre la page, écris une requête, lis les annotations.

En détail

SQLite, comme chaque base de données, a un query planner : quand tu lui donnes une requête, il décide comment l’exécuter. Il peut utiliser un index, faire un scan complet de la table, joindre les tables dans un certain ordre. La même requête écrite de deux manières différentes peut s’exécuter en millisecondes ou en minutes, selon les choix du planner.

La commande EXPLAIN QUERY PLAN te permet de voir ces choix. La sortie est compacte : quelques lignes qui disent, par exemple, SEARCH TABLE orders USING INDEX idx_customer ou SCAN TABLE orders. La différence entre SEARCH et SCAN est énorme : le premier utilise un index et touche peu de lignes, le second lit toute la table.

Il y a aussi un niveau plus profond, EXPLAIN, qui montre le bytecode que la machine virtuelle de SQLite exécute vraiment : une séquence d’instructions comme OpenRead, Column, Next, Close. C’est l’assembleur de SQLite, et le lire nécessite une certaine familiarité avec l’architecture interne de la base de données.

L’outil de Willison prend les deux sorties et les annote. Pour chaque ligne de EXPLAIN QUERY PLAN, il ajoute une phrase qui explique ce que cela signifie. Pour chaque instruction du bytecode, il dit ce qu’elle fait et pourquoi elle est là. Le résultat est une explication lisible de quelque chose que normalement seul un DBA expert saurait interpréter.

Techniquement, l’outil s’exécute entièrement dans le navigateur. SQLite est compilé en WebAssembly et Python s’exécute via Pyodide, aussi en WebAssembly. Pas de serveur, pas de clé API, aucune donnée qui quitte ton ordinateur.

Le pattern de construction est aussi intéressant que le résultat. Willison a utilisé Claude Fable pour se faire écrire l’outil après avoir lu l’article de Julia Evans. C’est la même approche que la récente mise à jour de sqlite-utils 4.0 : une idée claire, un agent qui la réalise, un contrôle humain à la fin. Le fait que Willison admette ne pas pouvoir vérifier les explications est significatif : l’outil est utile pour explorer, mais ce n’est pas un oracle.

Ceci se connecte à un thème qui traverse le discours sur l’IA qui donne du pouvoir aux gens. L’outil ne remplace pas ta compréhension de SQL : il l’accélère. Au lieu de lire une documentation abstraite sur ce que fait Next dans le bytecode de SQLite, tu vois l’instruction appliquée à ta requête, avec une explication contextualisée. Tu apprends du cas réel, pas de la théorie.

La limite, honnêtement déclarée, est que les annotations pourraient contenir des erreurs. Si tu optimises une requête en production, cet outil est un point de départ pour comprendre ce qui se passe, pas la réponse définitive. Pour celle-ci, il faut toujours quelqu’un qui sait lire un plan d’exécution à la main et peut confirmer ou démentir ce que l’outil dit.