Laissez vos agents requêter la base,
en lecture seule tant que vous n'en décidez pas autrement
AgentsRoom gère vos connexions MySQL, PostgreSQL, SQL Server, MongoDB, SQLite et Google BigQuery et donne à vos agents IA de code un moyen d'y lancer des requêtes. Lecture seule par défaut, une instruction à la fois, avec le mot de passe hors de portée.
Un agent qui peut lire les vraies lignes arrête de deviner vos données. Un agent qui ne peut pas les écrire arrête d'être un risque à surveiller ligne par ligne.
Comment AgentsRoom atteint une base dans un sous-réseau privé et répond à une requête en lecture seule venue d'un agent IA.
Un agent IA de code qui ne voit pas vos données écrit du code contre le schéma qu'il a imaginé. Il invente une colonne, suppose qu'un enum a trois valeurs alors qu'il en a sept, et explique un bug avec une théorie au lieu d'une ligne. Lui donner une connexion à la base règle ça, et c'est aussi le moyen le plus rapide de transformer un agent utile en incident. AgentsRoom est construit autour de cette tension.
Vous enregistrez vos connexions dans l'app comme dans n'importe quel client de base de données : moteur, hôte, port, utilisateur, base, et TLS quand le serveur l'attend. Si la base n'est pas joignable depuis l'internet ouvert, la connexion passe par un tunnel SSH ou une session de redirection de port AWS SSM, en réutilisant les connexions SSH et SSM déjà enregistrées dans AgentsRoom. C'est comme ça qu'une base posée dans un sous-réseau privé devient quelque chose que vous pouvez interroger sans l'ouvrir au monde.
Chaque connexion démarre en lecture seule. Un SELECT s'exécute. Une instruction qui modifierait les données, non, tant que vous n'avez pas rendu cette connexion précise accessible en écriture et confirmé l'opération. Une seule instruction est acceptée par appel, donc rien ne se cache derrière un point-virgule, et les résultats sont plafonnés pour qu'une requête large ne noie ni un agent ni une fenêtre. Une connexion peut aussi être marquée comme production, ce qui rend la confirmation plus difficile à donner par accident.
Lire n'est pas tout le travail. Une connexion enregistrée sur une machine apparaît sur vos autres machines : vous configurez une base une fois, pas une fois par ordinateur. Et une base s'exporte dans un fichier, se restaure depuis un fichier, ou se copie directement sur un autre serveur, à travers les mêmes tunnels : les opérations pour lesquelles vous quittiez l'application.
Un client de base de données pensé pour qu'un agent soit aux commandes
MySQL, PostgreSQL, SQL Server, MongoDB, SQLite et Google BigQuery, avec les moteurs serveur joignables en réseau privé et les garde-fous actifs par défaut.
Connexions MySQL, PostgreSQL, SQL Server et MongoDB
Enregistrez une connexion par base : hôte, port, utilisateur, la base à ouvrir et TLS quand le serveur l'exige. Votre base locale, celle de staging et le réplica de production vivent dans la même liste, prêtes à être choisies plutôt que retapées.
Atteindre une base privée
Une base dans un sous-réseau privé n'est pas un cas particulier. Faites passer la connexion par un tunnel SSH ou une session de redirection de port AWS SSM et AgentsRoom l'ouvre pour vous, en réutilisant les connexions SSH et SSM déjà enregistrées dans l'app. Une instance Google Cloud SQL s'atteint par son nom de connexion via le Cloud SQL Auth Proxy, avec votre propre connexion gcloud et rien de stocké.
Lecture seule par défaut
Une nouvelle connexion peut lire, et rien d'autre. Les requêtes renvoient des lignes, les instructions qui changeraient les données sont refusées. Personne n'a à penser à activer le mode sûr, parce que le mode sûr est le point de départ de chaque connexion.
Deux verrous avant une écriture
Écrire demande deux gestes délibérés, pas un. La connexion doit être rendue accessible en écriture, et l'opération elle-même doit être confirmée explicitement. Un seul clic distrait ne peut pas enchaîner sur un UPDATE sans clause WHERE.
Une instruction par appel
Chaque appel porte exactement une instruction. Tout ce qui est empilé derrière un point-virgule est refusé plutôt qu'exécuté, donc une lecture qui ressemble à une lecture ne peut pas faire passer une seconde instruction avec elle. Les résultats sont plafonnés en plus de ça.
La production est signalée
Marquez une connexion comme production et la confirmation devient plus exigeante. La base qui compte cesse de ressembler exactement à la copie locale, autant pour vous en fin de journée longue que pour un agent qui déroule une liste de tâches.
Vos connexions, sur chaque machine
Une connexion enregistrée au bureau est là sur le portable : nom, hôte, port, utilisateur, base par défaut et le tunnel qu'elle emprunte. Seul le mot de passe reste sur place, chiffré sur la machine où vous l'avez saisi, si bien que chaque machine vous le demande une fois.
Exporter, importer, copier
Sortez une base dans un fichier .sql, rejouez un fichier dans une base, ou copiez une base directement sur une autre. La cible est sauvegardée avant d'être écrasée, et la remplacer complètement est une décision distincte, confirmée à part.
Les agents requêtent la base, ils ne détiennent jamais le mot de passe
Vos identifiants de base de données sont stockés par AgentsRoom, pas distribués. Un agent demande à exécuter une requête sur une connexion qu'il connaît par son nom, l'app ouvre la connexion, exécute l'instruction et renvoie les lignes. Le mot de passe ne fait jamais partie de ce que l'agent reçoit, jamais partie de la requête qu'il écrit, et jamais partie de la conversation qu'il conserve.
La règle de lecture seule est la seconde moitié de tout ça, et pour un agent ce n'est pas une consigne dont il pourrait se sortir par la parole. L'outil avec lequel un agent interroge refuse tout ce qui n'est pas une lecture, sauf si deux conditions sont réunies : la connexion est inscriptible, et vous avez activé « Autoriser les agents à écrire » sur cette connexion. L'option est désactivée par défaut, et le contrôle se fait dans l'app desktop, pas dans le processus de l'agent. Vos propres écritures dans la console demandent toujours une confirmation explicite, volontairement plus difficile à donner quand la connexion est marquée production. Une fois une connexion ouverte aux écritures des agents, elles s'exécutent sans cette confirmation : réservez l'option à une base que vous confieriez à l'agent. Partout ailleurs, le pire résultat d'une mauvaise requête reste une réponse fausse, pas une table perdue.
La règle d'une seule instruction ferme la faille classique. Un appel qui porte une instruction ne peut pas être prolongé par un point-virgule et une seconde, donc une requête qui paraît inoffensive à la relecture ne peut pas faire autre chose à l'exécution. SQL Server n'exige pas ce point-virgule : là, une lecture est un SELECT ou un WITH qui ne contient aucun mot d'écriture ni de transaction, et elle s'exécute dans une transaction toujours annulée. Combinée aux résultats plafonnés, une erreur reste une erreur au lieu de devenir un export.
Six moteurs, et on nomme ceux qui manquent
MySQL et MariaDB, PostgreSQL, SQL Server (Azure SQL et Amazon RDS for SQL Server compris), MongoDB, SQLite et Google BigQuery. Chacun a son propre driver plutôt qu'une couche de traduction, parce qu'ils diffèrent vraiment : une session PostgreSQL ou SQL Server est liée à une seule base, MongoDB prend une requête et pas du SQL, T-SQL n'exige pas de point-virgule entre deux instructions, chaque export s'appuie sur les outils livrés avec ce moteur, SQLite est simplement un fichier sur votre ordinateur, sans hôte, utilisateur ni mot de passe, et une connexion BigQuery correspond à un projet Google Cloud et à un ensemble de données par défaut, authentifiée avec votre propre compte Google (gcloud auth application-default login), sans aucune clé stockée. Les quatre moteurs serveur se joignent en direct, ou via un tunnel SSH ou une session de redirection de port AWS SSM quand ils ne sont pas exposés sur l'internet ouvert.
Oracle, Redis et les autres ne sont pas supportés. Sur SQL Server, vous vous connectez avec un login SQL (l'authentification Windows, Active Directory et Entra ID n'est pas proposée), et il n'y a ni export, ni import, ni copie. Sur BigQuery, Google facture chaque requête selon le volume de données qu'elle lit, donc chaque connexion a un plafond de facturation par requête (1 GiB par défaut, réglable) : une requête qui le dépasse est refusée au lieu d'être facturée. Ouvrir une table est gratuit et en lecture seule, vos agents utilisent les mêmes outils db_list, db_schema et db_query avec les mêmes garde-fous et voient le volume lu par chaque requête, et là non plus il n'y a ni export, ni import, ni copie. Vous méritez de le savoir avant le téléchargement plutôt qu'après. Le prochain moteur est décidé par ce que les gens demandent : si le vôtre manque, dites lequel sur le backlog public et il sera compté.
Demander votre moteur de base de donnéesDéplacer une base, pas seulement la lire
Exportez une base vers un fichier. Importez un fichier dans une base. Ou copiez une base directement sur une autre, y compris à travers le tunnel SSH ou la session AWS SSM que vous avez déjà enregistrée. Chaque moteur s'appuie sur ses propres outils officiels, écrits en flux sur le disque : une base de plusieurs gigaoctets devient une barre de progression, pas un plantage.
Ces outils sont livrés avec la base de données, pas avec AgentsRoom : mysqldump et mysql, pg_dump et psql, mongodump et mongorestore. SQL Server n'a pas d'équivalent qui transfère une base entière en flux, donc ses connexions n'ont ni export, ni import, ni copie. Quand les outils manquent, l'app dit exactement lesquels et vous laisse pointer le dossier qui les contient, comme doit le faire un client de base de données : lancée depuis le Dock ou le menu Démarrer, une app ne voit qu'un PATH nu et prétendrait sinon qu'ils sont absents sur une machine qui les a.
C'est sur la copie qu'un mauvais clic coûte une journée : elle est construite autour de ça, pas autour du cas idéal.
- Une connexion en lecture seule refuse l'import d'emblée, avant que quoi que ce soit ne soit ouvert.
- La cible est sauvegardée dans un fichier que vous choisissez avant la première instruction appliquée.
- La confirmation nomme la connexion et la base, et le dit plus fort quand la connexion est marquée production.
- Supprimer et recréer la base cible est une option à part, et sur une connexion production vous devez retaper le nom de la base.
D'une base privée à une réponse
Enregistrez la connexion, routez-la, puis requêtez-la ou laissez un agent le faire.
Enregistrez la connexion
Ajoutez la base : hôte, port, utilisateur, le nom de la base, et TLS si le serveur l'attend. Donnez-lui un nom que vous reconnaîtrez plus tard, et marquez-la comme production si c'en est une.
Routez-la si elle est privée
Si la base n'est pas joignable directement, faites pointer la connexion vers un tunnel SSH ou une session de redirection de port AWS SSM construite à partir des connexions déjà enregistrées dans AgentsRoom. Une base dans un sous-réseau privé devient joignable sans être exposée publiquement. Sur Google Cloud, choisissez plutôt l'instance Cloud SQL : AgentsRoom lance le Cloud SQL Auth Proxy pour vous.
Requêtez-la, ou laissez un agent la requêter
Lancez votre instruction depuis l'app, ou laissez un agent en lancer une via MCP. Lecture seule tant que vous n'y touchez pas, une instruction par appel, des résultats plafonnés, et une confirmation explicite entre chaque écriture et vos données.
Quand un agent a besoin des vraies lignes
Les moments où lire les données de production est le chemin le plus court vers le correctif.
Déboguer sur de vraies données
Le bug n'apparaît que pour une poignée de comptes. Laissez l'agent lire ces lignes et il trouve la valeur qui casse la logique, au lieu de proposer trois théories sur ce à quoi les données pourraient ressembler.
Une base qui n'est pas publique
La base vit dans un sous-réseau privé, sans point d'entrée public. Faites passer la connexion par un tunnel SSH ou une session AWS SSM construite sur vos connexions enregistrées, et requêtez-la sans ouvrir un port sur l'internet.
Laissez l'agent vérifier, pas deviner
Avant d'écrire une migration ou une requête, un agent peut regarder ce qui est réellement stocké. Il lit, il rapporte, et tant que vous n'avez pas ouvert cette connexion aux écritures des agents, il n'a aucun moyen de changer quoi que ce soit au passage.
La production, sans le risque d'écriture
Lire la production est souvent nécessaire, y écrire ne l'est presque jamais au milieu d'une tâche. Marquez la connexion comme production, gardez-la en lecture seule, et la différence entre enquêter et casser cesse de dépendre de l'attention de qui que ce soit.
Rafraîchir la préproduction avec de vraies données
Le bug ne se reproduit que sur de vraies lignes. Copiez la base sur votre serveur de préproduction, à travers le tunnel déjà enregistré, avec un dump de ce qui s'y trouvait pris avant.
Vous ouvrez le portable, tout est là
Vos connexions suivent votre compte : mêmes hôtes, mêmes tunnels, mêmes drapeaux lecture seule et production. Avec les mots de passe synchronisés, les mots de passe suivent aussi, chiffrés de bout en bout, et rien n'est ressaisi ; sans eux, chaque machine demande le mot de passe une fois.
Comment mes agents requêtent-ils la base ?
Via AgentsRoom MCP, avec quatre outils. db_list renvoie vos connexions enregistrées et leurs métadonnées, db_schema parcourt les schémas, les tables et les colonnes sans une ligne de SQL, db_query exécute une instruction et renvoie les lignes, et db_connection_new propose une base que vous n'avez pas encore enregistrée. AgentsRoom ouvre la connexion, y compris le tunnel SSH ou la session AWS SSM placée devant quand il y en a une. Ce qui repart vers l'agent, c'est un jeu de résultats, jamais un identifiant.
Un agent peut écrire uniquement si vous activez « Autoriser les agents à écrire » sur une connexion également définie comme inscriptible. Cette option est désactivée par défaut et suit la connexion sur votre compte. Une fois activée, les écritures sont exécutées immédiatement : utilisez-la seulement si vous faites confiance à l’agent pour cette base. Le desktop vérifie cette permission dans son processus principal et db_query n’accepte toujours qu’une instruction par appel.
Enregistrer une base peut aussi être entièrement le travail de l'agent. db_connection_new garde le chemin relu : il ouvre le formulaire de création pré-rempli avec l'hôte, l'utilisateur et la connexion SSH ou AWS SSM par laquelle elle doit être jointe, et c'est vous qui relisez, qui tapez le mot de passe et qui enregistrez, rien n'étant stocké avant que vous le fassiez. Sauf si vous désactivez "Les agents peuvent gérer les connexions" (Paramètres, activé par défaut), db_connection_save écrit la connexion directement, et le mot de passe ne transite toujours pas par la conversation : il est copié depuis un secret du coffre que l'agent se contente de nommer. L'agent obtient ce qu'il lui faut pour raisonner sur vos données, et aucune des façons dont cet accès tourne d'habitude à l'incident ne lui est accessible.
Chaque requête d'un agent est visible elle aussi. Les appels db_query et db_schema arrivent dans l'onglet Activité du panneau de droite, avec le SQL et les premières lignes renvoyées, dans un journal par base ; l'avatar de l'agent apparaît sur le bouton Bases de données et, avec un badge Agent au travail, dans votre liste de bases. Vous pouvez aussi le suivre depuis votre téléphone, dans la fiche de l'agent de l'app mobile. Ce journal ne circule qu'entre votre ordinateur et votre téléphone, chiffré de bout en bout et secrets masqués : aucun résultat n'est stocké sur un serveur.
Découvrir AgentsRoom MCPLe même onglet Activité qui liste vos appels db_query et db_schema, filmé ici sur un serveur SSH enregistré : un agent lance trois commandes, chacune arrive avec sa sortie, son code de sortie et sa durée, puis le journal de cette connexion s'ouvre en entier. Ce journal reste sur votre ordinateur.
Quelles bases de données sont supportées ?
Un agent IA peut-il écrire dans ma base ?
Comment atteindre une base dans un sous-réseau privé ?
Mes agents voient-ils le mot de passe de la base ?
Un agent peut-il lancer plusieurs instructions d'un coup ?
Qu'est-ce que ça change de marquer une connexion comme production ?
Que se passe-t-il avec une requête qui renvoie beaucoup de lignes ?
Un agent peut-il ajouter une connexion à une base de données ?
Comment un agent découvre-t-il mon schéma ?
Mes connexions aux bases sont-elles synchronisées entre mes machines ?
Puis-je exporter une base et l'importer ailleurs ?
Comment est protégé le compte qui porte mes connexions ?
Captures d'écran
De vraies captures de l'application, ajoutées au fil des évolutions de cette fonctionnalité.
Connectez Google BigQuery avec votre propre identifiant Google 
Limitez ce qu'une requête BigQuery peut facturer, par connexion 
Les connexions TLS directes vérifient le certificat du serveur, avec une option pour les serveurs auto-signés
Vous pourriez aussi aimer
RDS via AWS SSM
Atteignez une instance Amazon RDS sans endpoint public, depuis votre propre machine, via aws ssm start-session et le document AWS-StartPortForwardingSessionToRemoteHost. Pas de bastion à maintenir, pas de VPN, pas de règle SSH entrante. AgentsRoom ouvre la session sur un port loopback et y branche son client de base de données. MySQL, PostgreSQL, SQL Server et MongoDB, donc RDS MySQL, RDS PostgreSQL, RDS for SQL Server, Aurora et DocumentDB.
Cloud SQL Auth Proxy
Atteignez une instance Cloud SQL for MySQL ou PostgreSQL depuis votre propre machine, IP privée comprise, sans VM bastion. AgentsRoom lance le Cloud SQL Auth Proxy sur un port loopback avec vos Application Default Credentials gcloud, gère l'authentification IAM à la base et laisse les agents IA l'interroger en lecture seule.
Connexions SSH
Enregistrez vos connexions SSH, ouvrez un terminal SSH intégré et lancez Claude Code, Codex ou Antigravity CLI directement sur votre serveur distant ou votre VPS. Authentification par clé ou mot de passe, profils de connexion par projet, sans client SSH séparé.
Gestionnaire de secrets
Rangez vos clés d'API, vos tokens et vos mots de passe dans le trousseau de votre système, référencez-les avec {{secret:NAME}} dans vos commandes de dev et les environnements de vos agents, et laissez AgentsRoom les résoudre au lancement. Les agents voient les noms, jamais les valeurs, et rien n'est jamais synchronisé vers un serveur.
Terminaux de dev
Gestionnaire de terminaux et lanceur de process par projet. Démarrez backend, frontend et workers en un clic, en local ou sur un serveur distant.
AgentsRoom MCP
Le serveur MCP qui laisse vos agents piloter AgentsRoom lui-même : projets, terminaux, backlog et connexions, avec les garde-fous qui vont avec.
Donnez à vos agents les données, pas les clés
Téléchargez AgentsRoom, enregistrez vos connexions MySQL, PostgreSQL, SQL Server, MongoDB, SQLite et Google BigQuery, atteignez les connexions serveur via un tunnel SSH ou une session AWS SSM, et laissez vos agents les interroger, en lecture seule tant que vous n'ouvrez pas une connexion à leurs écritures.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.
Des agents qu'on lit comme une conversation
Chaque agent a un rôle, un visage et un fil que vous lisez comme une messagerie.
