Ouvrir une base SQLite distante en SSH sans la télécharger

Parcourez, interrogez et modifiez un fichier SQLite qui vit sur votre serveur, directement en SSH, avec un mode lecture seule pour la production et aucune copie à resynchroniser.

Par Équipe éditoriale NaucturneVérifié le 30 septembre 2026

SQLite

SSH

Base de données

Naucturne

SQLite est partout sur les serveurs : applications Laravel ou Rails sur de petits déploiements, Home Assistant, Gitea, Uptime Kuma, WordPress avec l'extension SQLite, outils d'analytics, état de tâches cron. Pour en inspecter une, on fait souvent un scp du fichier, on l'ouvre en local, puis on espère ne pas avoir de modification à renvoyer pendant que l'application continuait d'écrire dans l'original.

Le téléchargement casse aussi avec le mode WAL : le fichier -wal contient les écritures récentes, et copier le fichier principal seul donne une vue dépassée.

Comment Naucturne l'ouvre sur place

Connectez-vous au site SSH
L'accès SQLite utilise la session SSH du site. Les sites SFTP et SSH conviennent tous les deux.
Choisissez le fichier dans l'explorateur distant
Depuis l'onglet Bases de données du gestionnaire de sites, ajoutez une base SQLite et parcourez le serveur jusqu'au fichier. Cochez lecture seule s'il s'agit d'une base de production.
Ouvrez-la depuis la barre latérale
La base apparaît dans la section Bases de données. Parcourez les tables, consultez la structure, filtrez et lancez du SQL comme avec n'importe quel autre moteur.

Client base de données Naucturne affichant les tables et les lignes — Le même client sert MySQL, MariaDB, PostgreSQL, SQLite et Redis.

Pourquoi exécuter les requêtes sur le serveur

Toujours à jour. Vous lisez le fichier vivant, WAL compris, pas un instantané d'il y a dix minutes.
Pas de transfert de gros fichiers. Une base de 2 Go reste où elle est ; seules les pages de résultats voyagent.
Rien à ouvrir. Il n'existe pas de port SQLite, et aucun n'est ajouté : tout passe par SSH.
Un seul endroit pour tout le site. Fichiers, terminal et base du même serveur, dans la même fenêtre et le même coffre chiffré.

Prérequis

Le serveur doit disposer de Python 3 avec le module sqlite3. Il fait partie de la bibliothèque standard sur Debian, Ubuntu, les distributions de la famille RHEL et le paquet python3 d'Alpine. Un hébergement uniquement FTP ne peut pas l'exécuter : utilisez SSH.

Bonnes pratiques en production

Utilisez la lecture seule pour inspecter. Passez à un profil en écriture uniquement pour une correction délibérée.
Pour les gros exports, préférez l'outillage de l'application ou sqlite3 .backup dans le terminal, puis téléchargez le résultat.
SQLite verrouille la base pendant les écritures : une longue transaction lancée depuis une interface peut bloquer l'application.

Quand utiliser autre chose

Si vous travaillez chaque jour sur un fichier SQLite local, un outil de bureau comme DB Browser for SQLite est excellent. Naucturne est à son meilleur quand le fichier vit sur un serveur que vous gérez déjà, à côté de son code et de ses autres bases.

Consultez le guide des bases de données pour tous les moteurs et modes de connexion pris en charge.

Questions fréquentes

De quoi le serveur a-t-il besoin ?

D'un accès SSH et de Python 3 avec le module standard sqlite3, présent sur presque toutes les distributions Linux. Rien n'est installé durablement et aucun port n'est ouvert.

Le fichier est-il téléchargé sur mon poste ?

Non. Les requêtes s'exécutent sur le serveur via la session SSH et seuls les résultats reviennent. Vous ne travaillez jamais sur une copie locale périmée.

Peut-on éviter les écritures accidentelles en production ?

Oui. Cochez lecture seule en ajoutant la base : Naucturne ouvre le fichier en lecture seule, la navigation et les SELECT fonctionnent mais les écritures sont refusées.