Documentation Planche

Démarrer

Planche est un client de base de données dans le navigateur. Les fichiers SQLite s’ouvrent directement dans la page ; pour MySQL, PostgreSQL et les autres bases réseau, la connexion passe par un agent lancé sur votre machine. Les deux modes peuvent rester ouverts en même temps.

Fichiers SQLite : rien à installer

Déposez un fichier .sqlite, .db ou .sqlite3 sur la page (ou choisissez-en un depuis l’écran d’accueil). Il est chargé par SQLite compilé en WebAssembly dans la page ; le fichier n’est jamais envoyé. Les modifications peuvent être réécrites dans le fichier d’origine si votre navigateur prend en charge la File System Access API, sinon vous téléchargez une copie.

MySQL, PostgreSQL, SQL Server, Oracle, Neon, Supabase, Cloudflare D1 : une commande

Un navigateur ne peut pas ouvrir lui-même une connexion TCP vers une base. Un petit agent local s’en charge :

npx planche

L’agent démarre sur 127.0.0.1:8888, et affiche un lien d’appairage à ouvrir (avec --open, il l’ouvre lui-même dans le navigateur). Ce lien contient un code à usage unique, échangé par l’application contre le jeton de l’agent ; le jeton ne se retrouve donc ni dans une URL ni dans l’historique du terminal. Ensuite, le navigateur parle uniquement à 127.0.0.1 et l’agent se connecte à la base. L’hôte, l’utilisateur et le mot de passe restent sur votre machine.

L’agent demande Node.js 22 ou plus récent. npx le récupère depuis le registre npm et l’exécute. npx planche@latest lance la version la plus récente ; remplacez latest par un numéro de version pour en choisir une précisément.

Installer plutôt qu’utiliser npx

Pas de Node.js sur la machine — ou vous préférez une commande permanente ? Une ligne installe l’agent :

curl -fsSL https://planche.dev/install.sh | sh

irm https://planche.dev/install.ps1 | iex

Tout est placé dans votre dossier personnel et rien ne demande de droits d’administrateur. Si Node.js 22 ou plus récent est déjà là, il est utilisé ; sinon le script télécharge sa propre copie de l’exécution officielle et la vérifie avec les sommes de contrôle publiées par nodejs.org. Ensuite planche est une commande de votre PATH qui démarre immédiatement, sans aller-retour vers le registre. À la fin, le script démarre lui-même l’agent : le tout premier lancement ne demande rien de plus — un shell ne prend un nouveau PATH en compte que dans un nouveau terminal.

Mettez-le à jour avec planche upgrade et retirez-le avec planche uninstall ; vos réglages dans ~/.planche survivent aux deux. Quand une version plus récente existe, l’agent le signale au plus une fois par jour ; PLANCHE_NO_UPDATE_CHECK=1 le désactive. Les scripts d’installation sont du texte brut, vous pouvez donc les lire avant : curl -fsSL https://planche.dev/install.sh -o install.sh.

Si planche.dev est injoignable — pas d’Internet, ou un réseau qui le bloque — l’agent s’en aperçoit au démarrage et sert la copie de l’application qu’il embarque, à sa propre adresse, pour que vous puissiez continuer. Tout se comporte de la même façon, sauf la base d’exemple, qui ne fait pas partie de cette copie. L’application a alors l’âge de l’agent ; npx planche@latest la garde à jour.

Réseaux restreints et coupés d’Internet

Une seule étape a besoin de l’extérieur : npx récupère l’agent depuis le registre npm. Si c’est bloqué, installez-le une fois sur une machine qui atteint npm (npm i -g planche), ou faites npm pack planche pour obtenir une archive à copier ou à publier sur un registre interne.

Ensuite, plus rien ne sort du réseau. L’agent sert l’application depuis sa propre adresse, et cette page n’émet aucune requête en dehors de votre machine — l’éditeur, le moteur SQLite et toutes les icônes font partie du paquet : pas de CDN, pas de police distante, pas de statistiques. --serve-app saute le test d’accessibilité et sert en local dès le départ ; c’est aussi la bonne option quand le réseau avale les requêtes au lieu de les refuser (un portail captif, par exemple, répond à n’importe quelle adresse).

Ce à quoi vous renoncez, c’est ce qui a vraiment besoin d’Internet : les services hébergés (Neon, Supabase, Cloudflare D1), le SSH vers des hôtes inaccessibles, et la base d’exemple. Les bases situées dans le réseau — y compris une passerelle pour toute l’équipe — fonctionnent exactement comme ailleurs.

L’espace de travail

Vous pouvez garder plusieurs connexions ouvertes dans un même onglet de navigateur. Chacune reçoit son propre onglet sous la barre d’outils ; cliquez dessus pour passer à la base correspondante.

Changer de connexion remplace tout l’espace de travail, car chaque connexion garde son propre état. Revenez sur une connexion et vous retrouvez les mêmes onglets de requête, le même SQL à moitié écrit et les mêmes lignes de résultat que vous y aviez laissés.

• Arbre de schéma (à gauche) — les bases, tables, vues et routines de cette connexion. Cliquez pour déplier un nœud, clic droit pour les actions possibles dessus.
• Onglets de requête (en haut à droite) — un éditeur SQL chacun ; ouvrez-en autant que nécessaire. Un onglet ouvert par « Open Table » affiche les lignes de la table dans une grille au lieu d’un éditeur.
• Panneau de résultats (en bas) — Message indique ce qu’a fait chaque instruction (lignes affectées, erreurs, durée), avec Info et History à côté. Chaque jeu de résultats renvoyé reçoit son propre onglet Result.
• Pied de page — le nom de la connexion courante, des badges quand elle est en lecture seule ou qu’une transaction est ouverte, et le dernier message d’état.

Fermer le navigateur ne détruit rien : au rechargement les connexions se rouvrent d’elles-mêmes, les onglets de requête et leur texte reviennent, et une base SQLite ouverte depuis un fichier est restaurée depuis une copie locale, avant même que vous n’autorisiez à nouveau l’accès au fichier.

Se connecter à une base

Ouvrez le gestionnaire de connexions avec Connection › Connect (Alt + N), cliquez sur Add New, puis choisissez le SGBD. Le formulaire n’affiche que les champs utiles à ce moteur. Test Connection vérifie les paramètres sans ouvrir de session ; Connect ouvre la connexion dans un nouvel onglet.

Ce que chaque moteur demande

• MySQL / MariaDB — hôte, port (3306), utilisateur, mot de passe. La base est facultative ; l’arbre les affiche toutes. Le jeu de caractères vaut utf8mb4 par défaut.
• PostgreSQL — hôte, port (5432), utilisateur, mot de passe et une base obligatoire : une session PostgreSQL ne peut pas changer de base. Ce sont alors ses schémas qui jouent le rôle de « bases » dans l’arbre, et Planche bascule avec SET search_path.
• SQL Server — hôte, port (1433), login, mot de passe, base. Les schémas (dbo, …) jouent le rôle de « bases ». Activez TLS pour Azure SQL ; pour un certificat auto-signé, laissez Vérifier le certificat du serveur désactivé.
• Oracle — hôte, port (1521), utilisateur, mot de passe et un nom de service (par exemple FREEPDB1). L’agent utilise le pilote thin en JavaScript pur : aucun Instant Client à installer. Les schémas sont les utilisateurs, et Planche bascule avec ALTER SESSION SET CURRENT_SCHEMA.
• SQLite — choisissez le mode d’ouverture. Dans le navigateur ne demande rien à installer et travaille sur une copie du fichier en mémoire. Via l’agent ouvre le fichier avec le vrai SQLite sur la machine de l’agent : verrous et WAL fonctionnent, y compris en parallèle d’autres programmes ; vous saisissez alors un chemin et pouvez laisser Planche créer le fichier.
• Neon / Supabase — collez la chaîne de connexion de la console et hôte, utilisateur, mot de passe et base se remplissent seuls. TLS est toujours actif et il n’y a pas d’étape SSH. Pour Supabase, utilisez le pooler de session (port 5432) ou la connexion directe ; le port 6543 est le pooler transactionnel, où chaque instruction peut atterrir sur un backend différent, ce qui casse le changement de schéma, les tables temporaires et les transactions manuelles — Planche vous avertit si vous le choisissez.
• Cloudflare D1 — identifiant de compte, identifiant de base et un jeton API avec la permission D1 Edit (D1 Read en lecture seule). L’agent appelle l’API REST Cloudflare avec ; il n’y a ni connexion TCP ni SSH. Chaque requête valide automatiquement, donc les transactions manuelles sont désactivées pour D1.
• Redis — hôte, port (6379), mot de passe, et un utilisateur ACL si le serveur en a un (laissez vide pour l’utilisateur default). Le champ base indique la base logique de départ (db0). TLS et SSH fonctionnent comme pour les moteurs SQL.
• Elasticsearch / OpenSearch — hôte et port (9200). Avec un utilisateur et un mot de passe, Planche s’authentifie en basic auth ; si l’utilisateur est laissé vide, le mot de passe est envoyé comme clé API (le id:key encodé). Activez TLS pour https ; pour un certificat auto-signé, ce qu’Elasticsearch 8 utilise par défaut, laissez Vérifier le certificat du serveur désactivé.
• Cloudflare DO (wrangler dev) — uniquement l’URL du serveur wrangler dev (http://localhost:8787 par défaut), sans identifiant de compte, jeton ni mot de passe. Lit une session wrangler dev locale, pas les Durable Objects déployés ; chaque objet apparaît comme une base distincte.

Mots de passe, jetons et garde-fous

• Save password — décoché, le mot de passe ne vit que jusqu’à la fermeture de l’onglet ; coché, il est enregistré avec le profil dans ce navigateur. Dans les deux cas il ne va nulle part ailleurs que vers votre agent.
• Agent token — laissez vide pour utiliser le jeton du lien d’appairage. Ne le remplissez que si vous faites tourner plusieurs agents ou avez appairé à la main.
• Lecture seule, couleur d’environnement et mode transactionnel se règlent par profil ; voir Sécurité.

Tunnels SSH

Si la base n’est accessible que depuis un hôte bastion, utilisez un tunnel SSH. Activez SSH tunnel dans le profil, puis indiquez l’hôte de rebond. L’agent local ouvre le tunnel et fait passer le pilote par celui-ci ; la base n’a pas besoin d’être exposée directement.

Les champs

• SSH Host / Port — l’hôte bastion. Vous pouvez utiliser un alias Host de votre ~/.ssh/config : Planche le résout comme la commande ssh, avec HostName, User, Port et IdentityFile. Les directives Include sont suivies, mais pas ProxyJump.
• SSH User — laissez vide pour reprendre l’utilisateur du bloc de configuration.
• SSH Auth — clé privée, mot de passe ou ssh-agent.
  • Clé privée : choisissez le fichier de clé, ou laissez vide pour utiliser l’IdentityFile de la configuration — à défaut ~/.ssh/id_*. Ajoutez la passphrase si la clé en a une.
  • ssh-agent : utilise la socket d’agent (SSH_AUTH_SOCK) de la machine où tourne npx planche, donc les clés matérielles et les agents transférés fonctionnent.
• L’hôte et le port de la base, dans le formulaire au-dessus, sont résolus depuis le rebond : souvent 127.0.0.1 ou un nom interne.

Clés d’hôte

La première connexion à un rebond inconnu affiche son empreinte et vous demande de l’accepter. Les clés acceptées sont ajoutées à ~/.planche/known_hosts, et votre ~/.ssh/known_hosts existant est lu également. Si la clé change plus tard, la connexion est refusée plutôt que refaite en confiance — la même règle que la commande ssh.

Bon à savoir

• Clés et passphrases suivent le réglage Save password et ne quittent jamais votre machine : elles vont du navigateur à votre agent local, point.
• Le tunnel se ferme en même temps que la connexion.
• Un échec d’authentification SSH est signalé comme tel, distinct d’une erreur de base, pour savoir quelle moitié corriger.
• Définissez PLANCHE_SSH_CONFIG=none avant de démarrer l’agent si vous préférez qu’il ignore ~/.ssh/config et les clés par défaut.

Cloudflare Durable Objects avec wrangler dev

Cloudflare DO (wrangler dev) est réservé au développement local. Il lit les Durable Objects d’une session wrangler dev active sur votre propre machine. Les Durable Objects déployés ne sont pas pris en charge.

Pourquoi chaque objet apparaît comme une base

Chaque Durable Object possède sa propre base SQLite privée. Les objets apparaissent donc comme des bases distinctes dans l’arborescence. Un objet nommé est affiché sous la forme <namespaceId>/<object>. Par exemple, do-probe-Counter/probe-one désigne l’objet probe-one du namespace do-probe-Counter, dont l’identifiant suit la forme <script>-<ClassName>. Ce n’est pas un nom de base traditionnel, mais le nom d’objet passé à idFromName(). Les objets créés avec newUniqueId() n’ont pas de nom et apparaissent sous leur identifiant hexadécimal de 64 caractères.

wrangler tient un registre de développement. Les Durable Objects d’autres sessions wrangler dev actives au même moment apparaissent aussi. Un seul profil Planche peut donc examiner plusieurs projets locaux.

Connexion

1. Lancez wrangler dev dans le projet Worker.
2. Lancez npx planche, puis créez une connexion Cloudflare DO (wrangler dev).
3. Saisissez l’URL du serveur wrangler dev. La valeur par défaut est http://localhost:8787. Il n’y a ni ID de compte, ni jeton API, ni mot de passe, ni réglage SSH.

L’agent local lit l’API Local Explorer de wrangler à l’adresse <devUrl>/cdn-cgi/local/explorer/api ; aucun composant ne doit donc être installé ou déployé côté Worker. L’URL doit être une adresse de bouclage ; sinon l’agent servirait de proxy HTTP vers des hôtes arbitraires.

Si rien n’écoute : Cannot reach a wrangler dev server at http://localhost:8787 (fetch failed). Run `wrangler dev` in your Worker project and try again.

Si le port appartient à un autre serveur : ... answered (HTTP 401) but is not a wrangler dev server. Check the port, and that `wrangler dev` (wrangler 4.x) is what is running there.

Outils SQLite et stockage

Le stockage des Durable Objects étant SQLite, l’éditeur SQL et les tables de ctx.storage.sql fonctionnent comme avec les autres bases SQLite. Planche lit tables, vues, déclencheurs, colonnes et index via sqlite_master et PRAGMA, prend en charge le DDL CREATE TABLE et l’ERD construit à partir des clés étrangères, et associe les résultats d’un SELECT sur une seule table à leur table source pour permettre la modification des lignes dans la grille.

Planche masque dans l’arborescence la table de gestion interne de miniflare __miniflare_do_name. Il laisse _cf_KV visible, car cette table contient les données écrites avec ctx.storage.put().

Chaque requête est validée automatiquement. BEGIN, COMMIT et ROLLBACK sont refusés avec une explication, et l’option de transaction manuelle est masquée comme pour Cloudflare D1.

Pourquoi les objets déployés ne sont pas pris en charge

L’API publique de Cloudflare documente deux méthodes Durable Objects : lister les namespaces et lister les objets. Elle ne documente aucun endpoint SQL permettant d’interroger le stockage d’un objet.

Le tableau de bord Cloudflare possède un onglet Data Studio (Beta) qui interroge les objets déployés, et l’endpoint sous-jacent est accessible avec un jeton API. Mais il ne figure pas dans la référence de l’API publique et peut changer sans préavis. Il n’existe pas non plus de permission de jeton propre aux Durable Objects. D1 a D1 Read/D1 Edit, et Workers KV et R2 ont leurs permissions dédiées. La seule permission qui ouvre cet endpoint est Workers Scripts Edit. Elle donne l’accès en écriture pour déployer et modifier tous les Workers du compte. Planche ne demandera pas cette permission pour parcourir des données.

Pour accéder aujourd’hui aux objets déployés, utilisez Data Studio dans le tableau de bord ou exposez votre propre endpoint depuis un Worker.

Redis

Un profil Redis fonctionne avec Redis 6 et 7 et avec les serveurs qui parlent le même protocole (Valkey, KeyDB, Dragonfly). L’agent garde une connexion par profil, plus une autre tant qu’un onglet Pub/Sub ou Monitor est ouvert.

Arbre des clés

L’arbre liste les bases logiques (db0 à db15 par défaut) avec leur nombre de clés. Déplier une base groupe ses clés selon le premier segment : (user:, session:), et chaque groupe se déplie de la même façon. Chaque niveau est lu avec SCAN par pages de 1 000 clés et s’arrête à 10 000 avec une note ; Planche n’exécute jamais KEYS, qui bloque le serveur pendant tout le parcours de l’espace de clés. Les noms de clés ne sont pas conservés d’une session à l’autre.

Visionneuse de clé

Double-cliquez sur une clé pour l’ouvrir dans son propre onglet. L’en-tête affiche son type, sa durée de vie, sa longueur et sa mémoire (MEMORY USAGE) ; la durée de vie et le nom s’y modifient, et la clé peut être supprimée après confirmation. Le renommage utilise RENAMENX, donc une clé existante n’est jamais écrasée.

• Hash, set, sorted set — une table lue avec HSCAN / SSCAN / ZSCAN, avec un filtre (texte simple ou motif glob comme a*) et Load more. Valeurs et scores se modifient sur place ; les lignes s’ajoutent et se retirent depuis la table.
• List — index et valeur, lus par 200 ; les éléments se modifient, s’ajoutent à l’une ou l’autre extrémité et se retirent. Redis ne sait retirer un élément de liste que par sa valeur : un retrait remplace donc d’abord l’élément par un marqueur unique, puis retire ce marqueur. Ce sont deux commandes, et un autre client qui décale la liste entre les deux peut déplacer l’index.
• Stream — les entrées les plus récentes d’abord, avec leurs champs ; les entrées s’ajoutent (field value; field value) et se suppriment.
• String et RedisJSON — une valeur JSON s’ouvre en arbre repliable et une valeur HTML en page rendue ; passez en Text pour modifier. Au-delà de 1 Mo, seul le premier mégaoctet est chargé jusqu’à ce que vous demandiez la suite. Le HTML est rendu dans un cadre isolé (sandbox) qui n’exécute aucun script et ne charge rien depuis d’autres hôtes.

Console

Un onglet de requête sur une connexion Redis est une console : une commande par ligne en syntaxe redis-cli (guillemets doubles avec les échappements \n, \xHH ; guillemets simples littéraux), commentaires # et //. Ctrl / ⌘ + Enter exécute la commande de la ligne du curseur ; le script entier s’exécute une commande après l’autre. SELECT n fait passer l’onglet sur cette base. Une réponse qui est un objet unique s’ouvre en JSON, des enregistrements en tableau, et le sélecteur Table / JSON au-dessus du résultat change l’affichage.

SUBSCRIBE, PSUBSCRIBE et MONITOR sont refusés dans la console : ils occupent la connexion, ce qui bloquerait l’arbre et tous les autres onglets. Utilisez plutôt les outils Pub/Sub et Monitor.

Outils

Faites un clic droit sur un espace vide de l’arbre, ou passez par le menu Tools :

• Server info — INFO sous forme de cartes (version, mémoire, taux de succès du cache, opérations par seconde, persistance, réplication), le nombre de clés de chaque base, et chaque champ avec un filtre ; actualisation toutes les 5 secondes sur demande.
• Slow log — les 128 entrées les plus récentes de SLOWLOG GET avec leur durée et leur client, et le seuil qui les y fait entrer ; le vider demande confirmation.
• Clients — CLIENT LIST ; un autre client peut être déconnecté après confirmation. La connexion de l’application elle-même est signalée et ne peut pas être déconnectée d’ici.
• Pub/Sub — abonnez-vous à des canaux et à des motifs glob (news orders.*) et regardez les messages arriver ; publiez sur un canal et voyez combien d’abonnés l’ont reçu.
• Monitor — chaque commande de chaque client, au moment où elle s’exécute. Redis copie chaque commande vers chaque moniteur, ce qui réduit le débit d’un serveur chargé : lancez-le brièvement. Quand le flux dépasse la limite de l’agent de 500 événements par 100 ms, le nombre de commandes sautées est affiché.
• Memory analysis — parcourt une base (jusqu’à 10 000, 100 000 ou 1 000 000 de clés) et demande par lots la taille, le type et l’expiration de chaque clé : mémoire par type, par préfixe et par expiration, et les 50 plus grosses clés. 20 000 clés prennent environ une seconde. MEMORY USAGE estime les grandes collections à partir d’un échantillon de leurs éléments. Cliquez sur une clé pour l’ouvrir, sur un préfixe pour supprimer ses clés.
• Delete keys by pattern — trouve les clés qui correspondent à un motif (jusqu’à 100 000 par exécution), affiche leur nombre et vingt d’entre elles, vous demande de retaper le motif, puis les supprime avec UNLINK par 500. L’historique enregistre une seule entrée pour l’exécution. Également disponible dans le menu d’un nœud de base ou de préfixe.

Sécurité

Un profil en lecture seule n’accepte que les commandes de la liste des lectures de Planche, et un agent passerelle vérifie chaque commande d’après les drapeaux COMMAND INFO du serveur lui-même. FLUSHDB, FLUSHALL, SWAPDB, SHUTDOWN et les commandes similaires demandent confirmation avant de s’exécuter. Les mots de passe de AUTH, HELLO … AUTH, MIGRATE … AUTH, CONFIG SET requirepass et ACL SETUSER sont masqués dans l’historique.

Pas encore pris en charge

Redis Cluster et Sentinel. Connecté à un nœud de cluster, Planche n’affiche que les clés de ce nœud dans db0 et, pour une clé détenue par un autre nœud, nomme ce nœud au lieu de suivre la redirection.

Elasticsearch et OpenSearch

Elasticsearch (7 et 8) et OpenSearch (1 et 2) sont des entrées distinctes du gestionnaire de connexions et fonctionnent de la même façon : l’agent envoie vos requêtes à l’API REST du cluster, et à rien d’autre.

Console

Un onglet de requête est une console en syntaxe Kibana Dev Tools : une ligne avec la méthode et le chemin commence une requête, et les lignes qui suivent forment son corps.

GET /_cat/indices?v

POST /products/_search
{
  "query": { "match": { "name": "keyboard" } }
}

Ctrl / ⌘ + Enter exécute la requête qui entoure le curseur. Les corps de _bulk et _msearch sont envoyés tels qu’écrits (NDJSON). La complétion propose les endpoints courants après la méthode, ainsi que les noms d’index déjà chargés dans l’arbre. Le SQL passe par la même console : POST /_sql?format=txt sur Elasticsearch, POST /_plugins/_sql sur OpenSearch.

Résultats

Les résultats de recherche reviennent à raison d’une ligne par document : _index, _id, _score, puis les champs de _source ; les objets imbriqués et les tableaux s’ouvrent dans la visionneuse JSON. La sortie de _cat devient des lignes. Une réponse qui est un objet unique, comme _cluster/health ou un mapping, s’ouvre en JSON ; le sélecteur Table / JSON change l’une ou l’autre vue. Faites un clic droit sur un résultat et choisissez Open pour modifier le document.

Arbre des index

L’arbre liste les index avec leur nombre de documents, un dossier Aliases, et les index système préfixés par un point repliés dans System indices. Déplier un index liste son mapping sous forme de chemins de champs pointés avec leurs types (customer.country: keyword, items: nested). Double-cliquez sur un index pour lancer une recherche de 50 documents dans un nouvel onglet de console. Après une requête qui écrit, l’arbre se recharge : un index créé ou supprimé apparaît ou disparaît aussitôt. Faites un clic droit sur un espace vide de l’arbre pour l’état du cluster, les nœuds, les shards, les modèles d’index et un modèle de création d’index.

Visionneuse de documents

La visionneuse affiche la version du document, son _seq_no et son _primary_term, et son _source en arbre. Passez en Text pour modifier ; l’enregistrement envoie PUT /<index>/_doc/<id>?if_seq_no=…&if_primary_term=…, donc si quelqu’un a modifié le document après que vous l’avez ouvert, l’enregistrement est refusé avec un conflit au lieu d’écraser sa modification. Actualisez pour lire la version courante, puis modifiez à nouveau.

Sécurité

Un profil en lecture seule autorise les requêtes GET et HEAD, les POST vers les endpoints de type recherche (_search, _count, _msearch, _mget, …) et le SQL en lecture seule. Les contextes point-in-time et scroll conservent un état sur le cluster et sont refusés. Supprimer un index, un alias, un modèle ou un snapshot, toute cible à joker ou séparée par des virgules, _delete_by_query et _restore demandent confirmation avant de s’exécuter ; supprimer un seul document par son id, non. Dans les requêtes vers les API de sécurité, les champs mot de passe, hash, clé API, secret et jeton sont masqués dans l’historique.

Arbre de schéma

L’arbre de schéma s’adapte au moteur : MySQL et SQLite affichent bases › objets, tandis que PostgreSQL et SQL Server ajoutent un niveau de schéma. Le nombre sur chaque dossier indique combien de tables il contient avant même de le déplier.

Un clic droit sur n’importe quel nœud propose les actions qui y ont un sens :

• Open Table — la grille de données, avec la limite de lignes de vos paramètres.
• Generate SQL — un squelette SELECT, INSERT, UPDATE ou DELETE construit à partir des vraies colonnes et de la clé primaire, déposé au curseur.
• Show Create / Alter — le DDL de l’objet, ou le concepteur de table.
• Copy Table to… / Comparer / Comparer les données — voir les sections plus bas.
• Truncate / Drop — isolés en bas du menu, et tous deux exigent de retaper le nom de l’objet.

Éditeur SQL

L’éditeur utilise Monaco, celui de VS Code, et fait partie de l’application : il n’est jamais chargé depuis un CDN. La complétion connaît les mots-clés et fonctions de votre dialecte, ainsi que les tables et colonnes de la base connectée.

Exécuter des instructions

• Ctrl / ⌘ + Entrée exécute la sélection, ou l’instruction sous le curseur.
• F9 suit Paramètres › Sécurité › Portée d’exécution — le script entier par défaut.
• Ctrl / ⌘ + Maj + Entrée exécute toujours le script entier.

Les scripts sont découpés par un vrai analyseur, pas aux points-virgules : les corps BEGIN … END restent intacts, et la commande client DELIMITER, le quoting $$ de PostgreSQL, les lots GO de SQL Server et les blocs PL/SQL Oracle terminés par / sont compris. Chaque instruction est classée, et c’est ce qui rend possibles la limite de lignes, la confirmation des instructions destructrices et l’exécution à blanc.

Limite de lignes

Les SELECT sans limite reçoivent un LIMIT (ou TOP / FETCH FIRST selon le moteur) pour qu’un SELECT * lancé par erreur sur une grosse table ne noie pas le navigateur. La valeur par défaut est 500 lignes et le résultat le signale. Les instructions qui se limitent déjà elles-mêmes ne sont pas touchées.

Historique et instantanés locaux

L’onglet History liste ce que vous avez exécuté ; Query › Local History conserve des instantanés du texte de chaque onglet, si bien qu’un texte remplacé ou exécuté peut être récupéré. Les mots de passe littéraux sont masqués avant tout enregistrement, et la persistance peut être coupée dans les paramètres.

Grille de résultats

La grille n’affiche que la zone visible, ce qui garde le défilement fluide même avec plusieurs centaines de milliers de cellules. Si toutes les colonnes du résultat viennent d’une seule table dotée d’une clé primaire, vous pouvez les modifier directement.

Modifier

Double-cliquez une cellule pour la modifier (ou F2 / Entrée sur la dernière cellule cliquée), utilisez Add row ou Add with form pour insérer, et sélectionnez des lignes pour les supprimer. Rien ne s’exécute avant Commit, et par défaut Planche vous montre d’abord les instructions UPDATE / INSERT / DELETE générées. Discard jette les modifications en attente.

Sélectionner et copier

Le texte de l’interface ne se sélectionne pas au glisser : passer la souris sur la grille ne laisse donc jamais des libellés surlignés. Les lignes se sélectionnent au clic : cliquez une ligne, Maj-cliquez-en une autre pour prendre tout ce qui est entre les deux, ⌘ / Ctrl-cliquez pour ajouter ou retirer une ligne. Ce que vous choisissez ensuite dans le menu de cellule s’applique à toutes les lignes sélectionnées.

• Filtrer : colonne = cette valeur — recharge la table filtrée sur cette valeur (correspondance exacte).
• Copier — la cellule, le nom de la colonne, ou les lignes sélectionnées en TSV (avec en-tête), CSV, JSON ou instructions INSERT prêtes à exécuter.
• Modifier / Mettre à NULL / Mettre une chaîne vide / Supprimer les lignes — tout reste en attente jusqu’au Commit.
• Envoyer les lignes au bloc-notes — voir plus bas.
• Masquer la colonne — le sélecteur de colonnes de la barre la ramène.

Ce qui a changé depuis le dernier chargement

Actualiser un onglet de table compare les nouvelles lignes avec le chargement précédent, par clé primaire. Les cellules modifiées sont surlignées (le survol montre la valeur précédente), les nouvelles lignes marquées, et un badge compte les lignes disparues — pratique juste après un déploiement ou un traitement par lots. La comparaison ne vit que dans l’onglet ; le × l’efface.

Naviguer par les clés étrangères

Là où la base connectée a une clé étrangère, Planche transforme les valeurs de cette colonne en liens. Un clic ouvre la ligne référencée dans un nouvel onglet, déjà filtrée — sans écrire de requête ni copier un identifiant.

Rien à configurer : les clés étrangères sont lues dans la base au chargement de la grille. Survolez un lien pour voir où il mène.

Relier vous-même deux tables

De nombreux schémas réels contiennent des relations sans clé étrangère : une colonne créée sans contrainte, une table déplacée dans une autre base, ou un service dont les utilisateurs se trouvent sur un autre serveur. Planche vous permet de déclarer ces relations, puis de les suivre comme des clés étrangères ordinaires.

Faites un clic droit sur une valeur de la colonne et choisissez Lier « … » à une autre table.

• Rien n’est écrit dans la base. Le lien est une information que Planche conserve pour vous : vous pouvez donc le créer sur une base où vous n’avez que le droit de lecture.
• La cible peut appartenir à n’importe quelle connexion ouverte. Il peut s’agir d’une autre base sur le même serveur ou d’une connexion utilisant un autre moteur. Par exemple, vous pouvez relier orders.user_id sous MySQL à users.id sous PostgreSQL ; suivre le lien bascule alors vers cette connexion et ouvre la table filtrée.
• Il persiste. Les liens sont enregistrés par profil de connexion et reviennent après un rechargement.
• Il se partage. Export › Exporter les liens de colonnes les écrit dans un fichier JSON ; à l’import, les profils sont associés par id, puis par nom, puis par hôte, si bien qu’un collègue sur une autre machine obtient les mêmes chemins.
• Il apparaît dans l’ERD en pointillés, avec une entité fantôme si la cible est hors du diagramme.

Une base sans la moindre clé étrangère devient ainsi navigable en quelques minutes — et le reste pour tous ceux à qui vous transmettez le fichier.

Bloc-notes

Le bloc-notes est une base SQLite qui vit dans votre navigateur. N’importe quelle grille peut y copier des lignes via le menu contextuel de cellule — une ligne, la sélection, ou tout ce qui est chargé.

Les colonnes sont typées d’après les types source, et la table apparaît immédiatement dans l’arbre de schéma du bloc-notes. Comme c’est une connexion SQLite de navigateur ordinaire, vous pouvez l’interroger et la modifier comme n’importe quelle base, et Connection › Save Database File l’écrit sous forme de fichier .db. Elle est mise en cache localement, donc elle est encore là après un rechargement. Rien du bloc-notes n’est jamais envoyé ailleurs.

Ouvrez-le ou revenez-y à tout moment avec Tools › Bloc-notes.

Requêtes entre connexions

Dans un onglet de requête du bloc-notes, vous pouvez référencer une table de n’importe quelle connexion ouverte avec un nom en trois parties — "Nom de connexion".base.table — puis la joindre aux autres :

SELECT o.id, o.total, u.email
FROM "Shop MySQL".shop.orders o
JOIN "User service".public.users u ON u.id = o.user_id
WHERE o.status = 'paid';

Avant l’exécution, chaque table référencée est copiée localement et le SQL est réécrit pour utiliser cette copie. SQLite, dans votre navigateur, effectue alors la jointure. Vous pouvez ainsi joindre une table MySQL et une table PostgreSQL sans préparation côté serveur.

Les copies sont rafraîchies à chaque exécution et plafonnées à 100 000 lignes par table, avec la progression affichée dans le pied de page. Tools › Requête fédérée ouvre un onglet pré-rempli avec la syntaxe et le nom de vos connexions ouvertes.

Comparer et copier

Ces trois outils n’exécutent rien d’eux-mêmes. Ils produisent un script que vous pouvez relire, modifier, puis lancer vous-même.

Comparer les schémas

Database › Comparer les schémas (ou « Comparer la table… » sur un nœud de l’arbre) compare tables, colonnes, index, vues, procédures, fonctions, déclencheurs et événements entre deux connexions ouvertes. Les instructions CREATE sont comparées après suppression du bruit — DEFINER, SQL SECURITY, algorithme et préfixe de base — pour ne montrer que les vraies différences. Ouvrir le script dans l’éditeur vous remet les instructions ALTER / CREATE dans le dialecte cible, chaque DROP restant en commentaire tant que vous ne cochez pas la case.

Comparer les données

Database › Comparer les données associe les lignes par la clé primaire de la table source et compare les valeurs comme du texte normalisé : les différences de représentation des dates, décimaux et JSON selon les pilotes ne créent donc pas de faux écarts. Vous obtenez les lignes absentes de la cible, celles qui diffèrent (colonne par colonne) et celles que seule la cible possède, plus un script INSERT / UPDATE / DELETE — les DELETE en commentaire par défaut. Jusqu’à 50 000 lignes par côté sont chargées, avec progression.

Copier la table vers…

Clic droit sur une table puis Copy Table to… la reconstruit sur n’importe quelle autre connexion ou base ouverte. Le CREATE TABLE est généré dans le dialecte cible et affiché pour édition : une table MySQL peut donc être copiée vers PostgreSQL après ajustement d’un type. Les lignes sont transférées par lots avec une barre de progression. Si une table du même nom existe déjà, la copie est abandonnée — choisir « Supprimer et recréer » exige d’abord de retaper le nom de la table.

Assistant IA

Le panneau de droite n'écrit pas du SQL à copier : il se sert de l'application. Il lit le schéma, ouvre un onglet de requête, y exécute ce qu'il a écrit, et demande votre accord avant de modifier quoi que ce soit. Ouvrez-le par l'icône du bord droit ou Outils › Assistant IA.

D'une question à une réponse

Demandez dans votre langue. Le modèle ne voit pas votre écran : il commence par demander à l'application ce qui est ouvert et par lire les colonnes des tables qu'il compte utiliser. Chaque appel laisse une carte, donc ce sur quoi la requête est construite se voit au lieu d'être affirmé. L'instruction finie s'ouvre dans un onglet et s'exécute là : vous la voyez tourner, vous pouvez l'annuler, et trier ou exporter le résultat comme n'importe quel autre.

Ce qu'il a écrit passe d'abord par le planificateur du moteur. Une colonne inexistante revient au modèle sous forme d'erreur qu'il corrige lui-même, si bien qu'une requête cassée n'arrive jamais à votre écran ; un plan qui balaie une grande table en entier vous demande avant de partir.

Ce qu'il ne fera pas

• Une seule connexion — celle que vous avez ouverte. Aucun argument ne permet d'en nommer une autre, aucun outil n'en ouvre ni n'en ferme. La base concernée est celle que vous utilisez.
• DROP et TRUNCATE ne s'exécutent jamais — ni avec votre accord, ni reformulés, ni cachés après un point-virgule. Il peut en écrire un dans un onglet et dire ce qu'il détruit ; l'exécuter vous revient.
• Écrire demande d'abord — puis passe par les mêmes garde-fous qu'une instruction tapée par vous : l'aperçu du nombre de lignes, la confirmation destructive, le refus sur une connexion en lecture seule.

D'où vient le modèle

Paramètres › IA. La clé est remise à votre agent local et utilisée là ; elle ne reste jamais dans le navigateur et ne part jamais vers planche.dev — votre SQL et votre schéma non plus.

• Une clé d'API — Anthropic, un endpoint compatible OpenAI, ou Gemini. L'enregistrer est un choix, et le fichier est nommé avant que vous ne le fassiez.
• La session de cette machine — après ant auth login, le SDK trouve seul les identifiants : rien à coller.
• Une CLI locale — Claude Code ou Codex, déjà installé et connecté. Aucune clé.

Laisser un autre agent piloter Planche

Aide › Connecter un agent IA vous donne la configuration pour tout ce qui parle MCP en HTTP, afin qu'un agent de votre éditeur utilise ces mêmes outils. Les appels s'exécutent dans l'onglet du navigateur, avec les mêmes garde-fous ; une écriture y demande votre accord et est signalée comme venant de l'extérieur. Le jeton ne sert qu'à ce point d'accès et survit aux redémarrages ; le révoquer déconnecte tous les programmes à qui vous l'avez donné.

Sécurité

Un DELETE sans WHERE en production arrive plus vite qu’on ne le pense. Planche place plusieurs contrôles avant cette instruction ; vous pouvez les désactiver un par un dans les paramètres si nécessaire.

Exécution à blanc : voir les lignes avant de les changer

Avant d’exécuter un UPDATE ou un DELETE depuis l’éditeur, Planche le transforme en SELECT des lignes concernées. Vous voyez ainsi leur nombre et un échantillon. Les formes avec jointure sont prises en charge selon le dialecte : UPDATE a JOIN b en MySQL, UPDATE … FROM et DELETE … USING en PostgreSQL, UPDATE alias … FROM en SQL Server, ainsi que les sous-requêtes corrélées d’Oracle. Lorsqu’une instruction ne peut pas être réécrite de façon fiable, elle est exécutée sans aperçu.

Autres protections

• Confirmation des instructions destructrices — DROP, TRUNCATE, et DELETE/UPDATE sans WHERE demandent d’abord et listent exactement ce qui va s’exécuter. Supprimer une table ou une base depuis l’arbre exige en plus de retaper son nom.
• Connexions en lecture seule — les écritures sont refusées avant d’atteindre la base.
• Aperçu du commit dans la grille — les instructions générées s’affichent avant l’écriture.
• Transactions manuelles — rien n’est validé tant que vous ne le dites pas.
• Couleur d’environnement — la production ne ressemble pas à la préproduction.

ERD

Tools › Voir l’ERD construit le diagramme entité-association de la base sélectionnée à partir de ses clés étrangères. Il utilise la notation « patte-d’oie » ; les entités se déplacent et les colonnes se redimensionnent. La disposition est enregistrée pour chaque base.

Les liens de colonnes que vous avez définis apparaissent en pointillés. Quand un lien pointe vers une table hors du diagramme — une autre base, ou une autre connexion — une entité fantôme est ajoutée à côté de la source pour que la relation reste visible.

Conception de tables

Create Table et Alter Table ouvrent un concepteur en trois onglets : colonnes, index et, lorsque le moteur le permet, propriétés de stockage.

L’onglet SQL montre l’instruction que Planche exécuterait, dans le dialecte de votre moteur, mise à jour à mesure que vous tapez — une bonne façon d’apprendre un dialecte, et de vérifier ce que vous vous apprêtez à faire.

Le reste se trouve dans les menus Table et Database : renommer, dupliquer la structure, créer et supprimer des bases, et — là où le moteur le permet — gestion des utilisateurs, liste des processus, variables et état du serveur.

Exporter

• Télécharger en CSV — le résultat courant, ou une table entière. Une table est lue page par page, dans l’ordre de sa clé primaire, et écrite directement dans le fichier que vous choisissez (quand le navigateur prend en charge la File System Access API), si bien qu’une grosse table n’a jamais besoin de tenir en mémoire. La progression s’affiche et l’export peut être arrêté.
• Schéma en HTML — une page autonome avec les colonnes et index des tables cochées.
• Exporter / importer les liens de colonnes — vos clés étrangères virtuelles dans un fichier JSON, pour une autre machine ou un collègue.
• Copier en INSERT — depuis la grille, pour déplacer quelques lignes à la main.
• Enregistrer le fichier de base — réécrit sur le disque les bases SQLite du navigateur (bloc-notes compris).

Les valeurs CSV commençant par =, +, - ou @ sont préfixées d’une apostrophe pour que les tableurs les traitent comme du texte et non comme des formules.

Mode passerelle (équipes)

Un agent peut servir toute une équipe. En mode passerelle, les identifiants de base restent dans un fichier de configuration sur un hôte partagé ; le navigateur choisit seulement un profil par son nom.

npx planche --gateway gateway.json --addr 0.0.0.0 --allow-remote \
  --token "$(openssl rand -base64 24)" --public-url https://sql.example.com

{
  "name": "Acme staging",
  "profiles": [
    {
      "name": "Shop (read-only)",
      "driver": "mysql",
      "host": "db.internal",
      "port": 3306,
      "user": "reporting",
      "password": "…",
      "database": "shop"
    },
    {
      "name": "Shop (writable)",
      "readOnly": false,
      "driver": "postgres",
      "host": "pg.internal",
      "port": 5432,
      "user": "app",
      "password": "…",
      "database": "shop"
    }
  ]
}

• name — le nom de la passerelle, affiché dans la boîte de connexion.
• profiles[].name — ce que le navigateur propose ; c’est la seule partie d’un profil qu’un client renvoie.
• profiles[].readOnly — omis, le profil est en lecture seule ; mettez false pour autoriser l’écriture.
• Le reste correspond aux champs du formulaire de connexion, sous les mêmes noms : driver (mysql, postgres, mssql, oracle, sqlite, d1), host, port, user, password, database — plus serviceName pour Oracle, file pour SQLite et accountId / databaseId / apiToken pour Cloudflare D1. Un bloc ssh fonctionne aussi.

Ajoutez un bloc ssh à un profil pour joindre sa base via un hôte bastion. L’host et le port du profil sont alors résolus depuis cet hôte ; il s’agit souvent de 127.0.0.1 :

{
  "name": "Shop via hôte bastion (lecture seule)",
  "driver": "mysql",
  "host": "127.0.0.1",
  "port": 3306,
  "user": "reporting",
  "password": "…",
  "database": "shop",
  "ssh": {
    "host": "bastion.example.com",
    "port": 22,
    "user": "deploy",
    "auth": "key"
  }
}

• auth vaut key, agent ou password. Avec key et sans privateKey, l’agent utilise l’IdentityFile que le ~/.ssh/config de la machine passerelle indique pour cet hôte, sinon ~/.ssh/id_* — la configuration habituelle sur un serveur, puisque la clé ne se retrouve pas dans le fichier. agent utilise le SSH_AUTH_SOCK de la passerelle ; password demande un champ password.
• Si vous renseignez privateKey, sa valeur est le contenu de la clé (PEM / OpenSSH), pas un chemin. Ajoutez passphrase si la clé en a une.
• La clé du rebond doit déjà être approuvée sur la machine passerelle. Connectez-vous une fois avec ssh bastion.example.com, ou figez-la dans le profil via acceptHostKey et son empreinte SHA256:… : en mode passerelle, le navigateur n’envoie qu’un nom de profil et ne peut pas répondre à la question sur une clé d’hôte inconnue.

• Les profils sont en lecture seule par défaut, et cette lecture seule est imposée par l’agent : il n’accepte qu’une seule instruction de forme SELECT par requête et met la session elle-même en lecture seule là où le moteur le permet. Les garde-fous du navigateur sont un confort ; celui-ci ne se contourne pas depuis le client.
• Les requêtes qui portent des identifiants au lieu d’un nom de profil sont refusées.
• L’agent sert lui-même l’application web : la page ne parle donc qu’à sa propre origine et la politique de sécurité du contenu reste stricte.
• Il parle du HTTP en clair : placez un reverse proxy TLS devant lui et indiquez son adresse publique avec --public-url.

Vos collègues ouvrent cette URL et collent une fois le jeton dans le champ Configure de la boîte de connexion ; les profils apparaissent ensuite dans l’écran d’accueil et le gestionnaire de connexions.

Synchronisation des connexions (chiffrée de bout en bout)

La synchronisation conserve vos profils de connexion sur planche.dev pour que vous les retrouviez sur un autre ordinateur. Tout est chiffré dans votre navigateur avant l’envoi, avec une clé que le serveur ne voit jamais. Elle se trouve dans Connexion › Synchronisation des connexions. C’est une fonction Pro à partir de la 1.0, gratuite dans toutes les versions 0.x.

Activer la synchronisation

1. Connectez-vous avec GitHub. Cette connexion sert uniquement au serveur à savoir quel coffre vous appartient.
2. Choisissez une phrase secrète d’au moins 10 caractères et saisissez-la deux fois. Elle est volontairement distincte de votre compte GitHub : le serveur voit votre connexion, elle ne peut donc pas être ce qui déverrouille vos données.
3. Vos profils sont chiffrés puis envoyés. Sur un autre ordinateur, connectez-vous avec le même compte et saisissez la même phrase secrète pour les déverrouiller.

Comment fonctionne le chiffrement

• Le navigateur dérive de votre phrase secrète une clé AES-GCM de 256 bits avec PBKDF2-SHA256 (600 000 itérations, sel aléatoire de 16 octets). Chaque enregistrement utilise un nouveau nonce de 12 octets.
• La clé est créée non exportable et ne vit que dans la mémoire de l’onglet. Ni la clé ni la phrase secrète ne sont écrites sur le disque ou envoyées où que ce soit : chaque nouvelle session vous redemande donc la phrase secrète.
• Le serveur stocke un seul coffre chiffré par compte. À côté, en clair, figurent ce qu’il faut pour reconstruire la clé (le sel et le nombre d’itérations), le nonce, un numéro de version et l’heure du dernier enregistrement. Aucune de ces valeurs ne révèle quoi que ce soit du contenu.
• Pour votre compte, le serveur conserve votre identifiant GitHub et votre adresse e-mail (ou votre nom d’utilisateur GitHub si l’adresse est privée), ainsi qu’une session tant que vous restez connecté.

Ce que contient le coffre

• Vos profils de connexion : hôtes, ports, utilisateurs, options, et les liens de colonnes que vous y avez définis.
• Les mots de passe, mots de passe SSH et clés privées, mais seulement pour les profils où Enregistrer le mot de passe est coché. Un secret que vous n’avez pas voulu garder sur cet ordinateur n’est pas non plus gardé sur le serveur.
• Ni la base d’exemple ni le scratchpad : ils sont recréés sur l’ordinateur qui en a besoin.
• Jamais l’historique des requêtes, les résultats ou les données de vos bases.

Deux ordinateurs

Chaque profil porte la date de sa dernière modification, et la copie la plus récente l’emporte quand deux coffres sont fusionnés. Une suppression est mémorisée pendant 90 jours : un profil supprimé sur un ordinateur ne réapparaît pas depuis l’autre. Si deux ordinateurs enregistrent au même moment, le serveur refuse le second enregistrement ; cet ordinateur fusionne alors le coffre le plus récent et enregistre de nouveau, au lieu de l’écraser.

Si vous oubliez la phrase secrète

Personne, nous compris, ne peut déchiffrer le coffre stocké sur le serveur : il est donc irrécupérable. Sur un ordinateur qui a encore vos profils, choisissez Supprimer du serveur, puis réactivez la synchronisation avec une nouvelle phrase secrète. Supprimer le compte efface le coffre et votre connexion ; dans les deux cas, les profils présents sur vos ordinateurs ne sont jamais touchés.

La synchronisation ne fonctionne que sur planche.dev. La copie de l’application servie par votre agent local ne contacte pas Internet : la synchronisation n’y est donc pas disponible.

Confidentialité et sécurité

• Vos données ne nous parviennent jamais. planche.dev sert une page statique ; requêtes et résultats circulent entre votre navigateur et votre propre agent (ou restent dans la page, pour SQLite dans le navigateur).
• Les identifiants restent locaux. Les profils vivent dans le stockage de votre navigateur ; mots de passe et secrets SSH ne sont conservés que le temps de la session, sauf si vous demandez leur enregistrement. L’application refuse de parler à un agent qui n’est pas sur la boucle locale (ou qui n’a pas servi la page lui-même), car un agent distant reviendrait à envoyer des identifiants sur le réseau.
• L’agent authentifie tout. Toutes les routes sauf le contrôle de santé exigent un jeton, des jetons erronés répétés verrouillent brièvement l’authentification, seule l’origine de l’application peut l’appeler, et écouter ailleurs que sur la boucle locale demande une autorisation explicite et un jeton.
• Les fichiers SQLite sont cloisonnés. L’agent n’ouvre que des fichiers sous votre répertoire personnel (hors dossiers cachés et système) ou sous un répertoire que vous désignez, et refuse ATTACH tant que vous ne l’activez pas.
• L’historique est expurgé. Les mots de passe littéraux sont masqués avant l’enregistrement de l’historique ou des instantanés, et la persistance peut être désactivée.
• Les statistiques sont anonymes et facultatives. Seuls des faits catégoriels sont comptés — quel moteur, quelle boîte de dialogue, si une instruction a réussi — jamais le texte SQL, les noms d’hôte, de base, de table ou de fichier. Un interrupteur dans les paramètres les désactive.

Planche est fourni en l’état. Ces protections réduisent les risques, sans remplacer votre vérification : vous restez responsable des instructions exécutées. Gardez donc des sauvegardes.

Raccourcis clavier

Les raccourcis de l’éditeur fonctionnent quand l’éditeur SQL a le focus ; les autres sont globaux.