Cette page décrit Calíope 1.7, la version que je construis en ce moment. La 1.6 est sur l'App Store pour Mac, iPad, iPhone, Apple Watch, Apple TV et Apple Vision Pro. Le changelog indique dans quelle version chaque fonction est arrivée.

Ajoute un bouton « Ouvrir dans Calíope » à chaque sujet. Ne fonctionne qu'avec l'app installée.

Connexions

Créer un profil de connexion

Enregistrez les informations d'un serveur pour vous connecter rapidement.

Où le trouver : Panneau latéral › Bouton + (nouvelle connexion)

Dans le Gestionnaire de connexions, appuyez sur + dans la barre latérale gauche. Saisissez un nom descriptif, la famille du serveur (le protocole qu'il parle) et le produit dans celle-ci, puis l'hôte, le port, l'utilisateur et le mot de passe. Le champ « Base de données par défaut » est optionnel.

La ligne Environnement attribue au profil l’une de vos étiquettes d’environnement —Aucune par défaut—, et Étiquettes d’environnement… ouvre le catalogue où vous les créez.

Dans la section Options du serveur, vous pouvez configurer le jeu de caractères, la collation et activer SSL/TLS. Si SSL est activé, des champs apparaissent pour sélectionner le certificat et la clé du client.

ClickHouse

Avec ClickHouse, la section n'a ni jeu de caractères ni collation, ni certificat ni clé client, et cocher SSL/TLS fait passer le port de 8123 à 8443 s'il était celui par défaut, et inversement en le décochant.

Oracle

Avec Oracle Database, le champ de la base s'appelle Service et demande le nom du service (SERVICE_NAME, FREEPDB1 sur une installation Free), pas un SID. La section n'a ni jeu de caractères ni collation, ni certificat ni clé client, et cocher SSL/TLS fait passer le port de 1521 à 2484 s'il était celui par défaut, et inversement en le décochant.

MySQLMariaDBAurora

Comment il s'authentifie. Calíope prend en charge les cinq méthodes de MySQL et MariaDB : caching_sha2_password (celle par défaut depuis MySQL 8), mysql_native_password, client_ed25519 et parsec de MariaDB, et mysql_clear_password, qui envoie le mot de passe en clair et ne s'utilise donc qu'avec SSL/TLS activé : sans lui, Calíope ne l'envoie pas et le dit. C'est celle que demandent PAM, LDAP et l'authentification IAM d'Aurora. La méthode est fixée par le compte sur le serveur, pas par le profil.

PostgreSQL

Comment il s'authentifie. Calíope prend en charge les trois méthodes de PostgreSQL qui utilisent un mot de passe : SCRAM-SHA-256 (celle par défaut depuis PostgreSQL 14), md5, et le mot de passe en clair (password dans pg_hba.conf), qui n'est envoyé qu'avec SSL/TLS activé : sans lui, Calíope ne l'envoie pas et le dit. C'est celle que demandent LDAP, PAM, RADIUS et l'authentification IAM de RDS et d'Aurora. Kerberos (GSSAPI) et SSPI ne sont pas pris en charge : avec un serveur qui n'admet que ceux-là, la connexion échoue en disant que Calíope ne sait pas utiliser cette méthode.

Mots-clés : profil, nouvelle connexion, enregistrer serveur, hôte, configurer, authentification, caching_sha2_password, mysql_native_password, ed25519, parsec, mysql_clear_password, SCRAM-SHA-256, md5, PAM, LDAP, IAM

Modifier une connexion existante

Modifiez les informations d'un profil enregistré.

Où le trouver : Panneau latéral › Liste de profils

Sélectionnez le profil dans la liste de la barre latérale. Le formulaire à droite se charge avec ses données actuelles et vous pouvez modifier n'importe quel champ directement. Il n'y a pas de bouton Enregistrer : chaque modification est enregistrée dès que vous la faites.

Supprimer un profil a son propre thème, car c'est irréversible et cela emporte plus de choses qu'il n'y paraît : voir Supprimer une connexion.

Mots-clés : modifier profil, modifier connexion, supprimer profil

Supprimer une connexion

Les trois endroits d'où l'on supprime un profil, ce qui part avec lui, et pourquoi c'est irréversible.

Où le trouver : Panneau latéral › Bouton − (supprimer la connexion)

Supprimer une connexion n'efface pas seulement son adresse et son nom d'utilisateur : cela emporte tout ce que Calíope avait enregistré de ce serveur. C'est pour cela qu'il demande d'abord, et que la question dit le nom de la connexion — si ce n'est pas celle que vous croyiez, c'est le moment de le découvrir.

D'où
- macOS : sélectionnez le profil et cliquez sur − dans la barre sous la liste, à côté du +. Ou faites un clic droit sur la ligne et choisissez Supprimer.
- iPad : sélectionnez le profil et touchez − dans la barre inférieure ; ou maintenez appuyée la ligne et choisissez Supprimer ; ou balayez la ligne de droite à gauche. Le balayage ne supprime pas quand vous relâchez : il révèle le bouton, et la question arrive quand même. Balayer dans l'autre sens — de gauche à droite — c'est Déplacer vers le groupe.

Ce qui part avec elle
- Le profil et toutes ses données.
- Son mot de passe du trousseau, ainsi que celui de SSH et la phrase secrète de sa clé privée.
- Son historique de requêtes, et ses lignes dans le journal d'erreurs et dans le journal des messages du serveur.
- Le SQL qu'elle avait enregistré dans l'éditeur de cette connexion, et son cache de schéma.

C'est irréversible. Il n'y a ni corbeille ni annulation : la confirmation est la seule occasion de faire marche arrière.

Sur vos autres appareils. Avec la synchronisation iCloud activée, la suppression voyage et la connexion disparaît là-bas aussi. Dans l'autre sens rien d'étrange ne se produit : un profil créé sur l'autre machine et que celle-ci n'a pas encore vu n'est pas lu comme une suppression, il ne disparaît donc pas tout seul.

Un groupe entier. Supprimer un groupe supprime aussi les connexions qu'il contient, avec la même question et la même portée ; c'est expliqué dans Organiser les profils en groupes.

Mots-clés : supprimer connexion, supprimer profil, retirer serveur, annuler, corbeille, mot de passe, trousseau, balayer

Un même serveur avec deux adresses

Comment utiliser l’hôte alternatif lorsque l’adresse du serveur dépend de l’appareil depuis lequel vous vous connectez.

Où le trouver : Panneau latéral › Connexions › Hôte alternatif

Le champ « Hôte alternatif » du profil sert pour un serveur que l’on atteint par deux adresses différentes. Le cas typique est une machine de développement : depuis l’ordinateur lui-même, elle répond sur 127.0.0.1, tandis que depuis l’iPad il faut utiliser son adresse sur le réseau local. Comme les profils se synchronisent entre vos appareils, un seul champ d’hôte ne peut pas être juste des deux côtés.

À la connexion, l’hôte principal est essayé en premier. S’il ne répond pas, l’alternatif est essayé avec le même port, le même utilisateur, le même mot de passe et les mêmes options : seule l’adresse change. S’il vous faut aussi un autre port, écrivez « adresse:port » (par exemple, 10.0.0.20:3307).

Quand la session passe par l’adresse alternative, un repère apparaît à côté du nom du serveur et « Tester la connexion » indique quelle adresse a répondu, afin que vous sachiez toujours sur quelle machine vous travaillez.

Avec un tunnel SSH, le champ est ignoré, et c’est voulu : l’adresse du serveur y est résolue par la machine du tunnel, pas par votre appareil, elle ne change donc pas selon l’endroit d’où vous vous connectez.

Mots-clés : hôte alternatif, seconde adresse, ip locale, réseau local, bascule, 127.0.0.1, ipad, deux adresses

La chaîne de connexion MongoDB

Quand faut-il l'écrire, quels champs Calíope cesse d'utiliser dans ce cas, et où finit le mot de passe.

Où le trouver : Panneau latéral › Connexions › Chaîne de connexion

Le champ « Chaîne de connexion » n'apparaît que si le moteur du profil est MongoDB, et il est facultatif. Si vous le laissez vide, Calíope construit la connexion avec les champs du dessus : adresse, port, utilisateur, mot de passe, TLS et base de données. Pour un serveur ordinaire, cela suffit.

Écrivez-la quand la connexion ne peut pas se décrire avec ces champs. Trois cas : un jeu de répliques, qui exige plusieurs adresses et le nom du jeu ; une base d'authentification différente de l'habituelle, indiquée par authSource ; et un cluster Atlas, dont l'adresse commence par mongodb+srv:// et n'a pas de port à saisir. Avec mongodb+srv://, Calíope demande les serveurs du cluster au DNS de votre système, celui qu'utilise le reste de l'appareil, VPN comprise.

Quand vous l'écrivez, ce que dit la chaîne l'emporte sur les champs du dessus : les adresses, l'utilisateur, le mot de passe, l'usage de TLS et les options. Ce qu'elle ne dit pas vient du profil : si elle ne contient ni utilisateur ni mot de passe, ceux des champs sont utilisés, et si elle ne nomme aucune base de données, celle du profil, ou admin à défaut. Avec plusieurs adresses et replicaSet, Calíope cherche le membre primaire et travaille avec lui. Deux choses ne dépendent jamais de la chaîne. Si le profil utilise un tunnel SSH, l'adresse vient du tunnel et non de la chaîne, car le serveur que nomme la chaîne est celui que voit la machine du tunnel, pas votre appareil. Et les certificats viennent toujours du profil : la chaîne peut activer ou désactiver TLS et demander de ne pas vérifier le certificat, mais le Certificat CA (.pem) et le Certificat client (.pem) se choisissent dans Certificats SSL.

Si la chaîne n'indique pas authSource, l'authentification se fait contre admin. C'est là que vivent les comptes d'administration et c'est ce que supposent mongosh et Compass quand on saisit simplement un utilisateur et un mot de passe ; si les vôtres sont dans une autre base, précisez-le avec authSource.

Certaines options sont acceptées par la chaîne sans être utilisées. tlsCAFile et tlsCertificateKeyFile sont ignorées : ce sont des chemins vers un fichier, et Calíope n'ouvre que les fichiers que vous choisissez vous-même ; le certificat se met donc dans le profil. Les options de lecture et d'écriture, comme readPreference, w ou retryWrites, sont acceptées pour qu'une chaîne copiée d'Atlas fonctionne telle quelle, mais elles ne changent rien à ce que fait Calíope.

Un avertissement sur le mot de passe : celui du champ du dessus est enregistré dans le trousseau, mais un mot de passe écrit dans la chaîne, non. La chaîne est enregistrée avec le reste du profil et, si la synchronisation iCloud est active, elle voyage avec lui. Si cela vous importe, laissez le mot de passe dans son champ et n'utilisez la chaîne que pour le reste.

Si la chaîne est mal formée, la connexion échoue en le disant : c'est une erreur de formulaire, elle se corrige là et non en réessayant.

Mots-clés : chaîne de connexion, mongodb, uri, srv, atlas, jeu de réplicas, replica set, authSource, mongodb+srv

Tester la connexion

Vérifiez les informations du serveur avant de vous connecter.

Où le trouver : Gestionnaire de connexions › Tester la connexion

Appuyez sur Tester la connexion dans le formulaire du profil. Calíope tente d'ouvrir une connexion réelle avec les informations saisies et affiche le résultat dans une bannière verte (succès) ou rouge (erreur avec description).

Le test est particulièrement utile pour valider les identifiants SSL, les pare-feux ou les configurations d'hôte avant d'enregistrer le profil.

Mots-clés : test, tester, vérifier, check connection, tester connexion

Se connecter au serveur

Établissez la connexion et ouvrez l'Espace de travail.

Où le trouver : Gestionnaire de connexions › Se connecter

Une fois les informations du profil complétées, appuyez sur le bouton Connecter (icône d'éclair). Calíope ouvre le pool de connexions avec le pilote du moteur et charge l'arborescence des schémas.

Si la connexion échoue, une feuille s'ouvre et dit ce qui s'est passé et quoi vérifier. Voir la solution, quand il apparaît, mène au sujet de cette Aide qui l'explique, et Détails techniques montre le texte du serveur ou du réseau, tel quel. Le formulaire le répète dans l'encadré où s'affiche le résultat de Tester la connexion, sous la forme « Erreur de connexion : … ». Vérifiez l'hôte, les identifiants et que le serveur est actif et accessible depuis votre réseau.

Mots-clés : connexion, connecter, ouvrir workspace, pool

Changer la base de données active

Changez la base de données de la session depuis le panneau de schéma.

Où le trouver : Éditeur SQL › Panneau de schéma › Définir comme base de données active

Dans le panneau de schéma de l'Éditeur SQL, faites un clic droit sur une base de données (sur iPad, maintenez-la appuyée) et choisissez Définir comme base de données active. La session y passe sans se reconnecter — cela équivaut à exécuter USE nom_bd — et le menu serveur affiche son nom à côté de celui du serveur. Le changement n'affecte que la session en cours.

Oracle

Avec Oracle l’arbre liste des schémas, pas des bases : un schéma est un utilisateur, et la base est le service auquel vous êtes connecté. Oracle n’a pas de USE : le schéma choisi est celui où l’éditeur résout les noms non qualifiés, et chaque exécution le fixe dans la session, comme ALTER SESSION SET CURRENT_SCHEMA. Le profil ne change pas : son service reste le même.

Mots-clés : use database, changer base de données, sélectionner base de données

Fermer la connexion

Déconnectez-vous du serveur et revenez au Gestionnaire de connexions.

Où le trouver : Espace de travail › Déconnecter

Appuyez sur le bouton Déconnecter dans l'en-tête de l'Espace de travail. Calíope ferme le pool de connexions et revient à l'écran du Gestionnaire de connexions avec une animation.

La déconnexion est automatique lors de la fermeture de la fenêtre principale de l'application.

Mots-clés : déconnecter, fermer session, disconnect, quitter

Reconnexion automatique

Reconnectez-vous automatiquement si le serveur ferme la session.

Où le trouver : Panneau latéral › Formulaire profil › Reconnexion automatique

Dans le formulaire du profil de connexion, activez le commutateur Reconnexion automatique. Calíope s’en sert quand vous changez la base de données active (Définir comme base de données active dans le panneau du schéma) : si la connexion est coupée à ce moment-là —le serveur l’a fermée pour inactivité ou a redémarré, ou le tunnel SSH est tombé—, elle rouvre la session entière, tunnel compris, et refait le changement.

Elle ne relance pas les requêtes de l’éditeur ni des outils : la coupure s’affiche comme une coupure de connexion.

Avec un tunnel SSH, c’est ce même moment qui déclenche les notifications de tunnel perdu et rétabli (voir Notifications de tunnel SSH).

Mots-clés : reconnexion, reconnexion automatique, timeout, inactivité, rétablir connexion

Connexions simultanées à plusieurs serveurs

Travaillez avec plusieurs serveurs en même temps sans perdre le contexte.

Où le trouver : Espace de travail › Menu serveur

Calíope prend en charge plusieurs connexions actives à des serveurs simultanément. Chaque serveur dispose de sa propre session indépendante avec son propre arbre de schémas, ses onglets SQL ouverts, son historique de requêtes et l'état de l'assistant IA.

Fonctionnement :
Chaque fois que vous appuyez sur Connecter dans le Gestionnaire de connexions, une nouvelle session s'ouvre sans fermer les précédentes. Toutes les sessions coexistent et vous pouvez basculer entre elles sans rien perdre.

État de chaque session :
- Les onglets SQL et leur contenu sont conservés lors du changement de serveur.
- L'arbre des schémas affiche les bases de données du serveur actif.
- L'assistant IA conserve son historique de conversation par session.

Vous pouvez ouvrir autant de sessions que nécessaire — par exemple, pour comparer des données entre les environnements de développement, de staging et de production simultanément.

Mots-clés : multi-serveur, connexions multiples, simultané, plusieurs connexions, sessions, multiserver

Menu de sélection du serveur

Basculez entre les serveurs connectés depuis le menu déroulant de l'Espace de travail.

Où le trouver : Espace de travail › Menu serveur

Le menu de sélection du serveur affiche le nom du serveur actif et un indicateur d'état de connexion (point vert = connecté, rouge = erreur). En appuyant dessus, un menu s'affiche avec toutes les sessions ouvertes.

Sur macOS : le sélecteur apparaît dans la barre d'outils de la fenêtre, dans le coin supérieur gauche. Il affiche le nom du serveur, la base de données active et la flèche déroulante.

Sur iPad : le sélecteur apparaît à gauche de la barre d'onglets, toujours visible en haut de l'Espace de travail.

Sur iPhone : il se trouve aussi en haut de la liste Outils, pour changer de session, ajouter un serveur ou vous déconnecter depuis n'importe quel écran de l'Espace de travail.

Options du menu :
- Appuyez ou cliquez sur le nom de n'importe quel serveur pour activer cette session.
- La session active est marquée d'un ✓.
- Ajouter un serveur ouvre le Gestionnaire de connexions par-dessus l'Espace de travail actuel pour se connecter à un autre serveur sans perdre les sessions ouvertes.
- Déconnecter ferme la session du serveur actif.

Mots-clés : menu serveur, sélecteur, changer serveur, switcher, session active, indicateur connexion

Ajouter un serveur depuis l'Espace de travail

Connectez-vous à un serveur supplémentaire sans quitter votre travail actuel.

Où le trouver : Espace de travail › Menu serveur › Ajouter un serveur

Pour ajouter une nouvelle connexion pendant que vous travaillez déjà sur un autre serveur :

1. Ouvrez le menu de sélection du serveur (dans la barre d'outils de la fenêtre sur macOS, dans la barre d'onglets sur iPad).
2. Choisissez Ajouter un serveur.
3. Le Gestionnaire de connexions s'ouvre : dans sa propre fenêtre sur macOS, en feuille sur iPad.
4. Sélectionnez un profil existant ou créez-en un nouveau et appuyez sur Connecter.
5. Le Gestionnaire de connexions se ferme tout seul et la nouvelle session devient disponible dans le sélecteur.

Les sessions précédentes restent ouvertes et intactes tout au long du processus.

Mots-clés : ajouter serveur, nouvelle session, deuxième connexion, connecter autre serveur

Déconnecter un serveur individuel

Fermez la session d'un serveur sans affecter les autres connexions actives.

Où le trouver : Espace de travail › Déconnecter

Lorsque vous avez plusieurs sessions ouvertes, vous pouvez fermer n'importe laquelle de façon indépendante :

Serveur actif :
- Ouvrez le menu de sélection du serveur et appuyez sur Déconnecter, ou utilisez le bouton rouge de déconnexion dans la barre d'outils.

N'importe quelle session (en y basculant d'abord) :
1. Ouvrez le menu de sélection du serveur.
2. Sélectionnez le serveur que vous souhaitez fermer pour l'activer.
3. Appuyez sur Déconnecter.

Lors de la fermeture d'une session, Calíope active automatiquement la dernière session disponible. Si c'était la seule session ouverte, il revient au Gestionnaire de connexions.

Mots-clés : déconnecter serveur, fermer session, fermer connexion, disconnect, supprimer serveur

Configurer SSL/TLS

Chiffrez la connexion au serveur avec des certificats SSL.

Où le trouver : Panneau latéral › Formulaire profil › SSL

Dans le formulaire du profil de connexion, activez le commutateur SSL dans la section Options du serveur. Trois champs optionnels apparaissent pour les certificats du client :

- Certificat CA — fichier du certificat de l'Autorité de Certification (.pem ou .crt). Calíope utilise ce fichier pour vérifier l'identité du serveur.
- Certificat client — fichier du certificat du client pour l'authentification mutuelle.
- Clé client — clé privée correspondant au certificat du client.

Si vous activez SSL sans fournir de certificat CA, Calíope vérifie le certificat du serveur par rapport aux autorités de certification du système (comportement par défaut sécurisé). Si le serveur utilise un certificat auto-signé, la connexion échouera à moins que vous ne fournissiez le CA correspondant.

Accepter un certificat non vérifié (non sécurisé) : cochez cette case uniquement si vous vous connectez à un serveur de développement avec un certificat auto-signé et que vous ne pouvez pas fournir le CA. La connexion reste chiffrée mais est vulnérable aux attaques de l'homme du milieu. À ne pas activer pour les serveurs de production.

Où se trouve le fichier : quand vous choisissez un CA, un certificat ou une clé client — ou le collez, ailleurs que sur le Mac —, Calíope garde sa propre copie sur cet appareil, jamais dans iCloud Drive, et le profil pointe vers cette copie. Vous pouvez ensuite déplacer ou supprimer l'original, et sur le Mac il est toujours lu après un relancement. Pour renouveler un certificat, choisissez-le de nouveau, même s'il porte le même nom. Le fichier reste sur l'appareil où vous l'avez choisi, et son emplacement aussi : un profil configuré sur un autre appareil arrive sans lui. Avant de vous connecter, la liste des connexions affiche Choisissez ses fichiers sur cet appareil et le formulaire indique « Ce profil utilise un certificat choisi sur un autre appareil : choisissez-le ici. » ; choisissez-le là-bas, et dès lors cet appareil garde sa propre copie.

Si un fichier ne peut pas être lu, Calíope ne se connecte pas sans lui : il s'arrête avec « Impossible de lire un fichier TLS », qui nomme le fichier et lequel des trois il est.

La connexion SSL est testée lorsque vous appuyez sur Tester la connexion ; la bannière verte confirmera si le chiffrement est actif.

ClickHouse

Avec ClickHouse, il n'y a que Certificat CA et la case pour accepter un certificat non vérifié : ClickHouse se connecte avec un utilisateur et un mot de passe, donc le formulaire n'affiche ni Certificat client ni Clé client, et un profil qui en contient ne se connecte pas tant qu'on ne les retire pas. Activer SSL fait passer le port de 8123 à 8443 s'il était celui par défaut. Avec un tunnel SSH, le certificat est vérifié contre l'hôte du profil.

Oracle

Avec Oracle, il n'y a que Certificat CA et la case pour accepter un certificat non vérifié : Oracle se connecte avec un utilisateur et un mot de passe en TLS dans un seul sens (TCPS), donc le formulaire n'affiche ni Certificat client ni Clé client. Activer SSL fait passer le port de 1521 à 2484 s'il était celui par défaut : le listener sert TCPS sur un autre port. Le certificat est vérifié contre l'hôte du profil, avec un tunnel SSH aussi et avec votre propre CA aussi : le nom du serveur doit figurer dans le certificat. Si un profil contient un certificat ou une clé client —importé, ou hérité d’une autre famille—, la connexion ne s’ouvre pas et l’erreur le dit : retirez-les du profil.

Mots-clés : ssl, tls, certificat, chiffrement, ca, client, sécurité, pem, crt, ssl_mode, mitm, vérification, auto-signé

Authentification biométrique

Exigez Touch ID, Face ID ou Optic ID avant de vous connecter à n'importe quel serveur.

Où le trouver : Panneau latéral › Réglages › Général › Sécurité

Calíope peut demander la biométrie de l'appareil avant d'ouvrir toute connexion : Touch ID sur le Mac et sur les iPad qui en ont, Face ID sur l'iPhone et les autres iPad, et Optic ID sur Apple Vision Pro. C'est un seul interrupteur pour toute l'application, pas un réglage de chaque profil.

Où l'activer
- Réglages › Général › Sécurité › Exiger Touch ID pour se connecter (ou Exiger Face ID pour se connecter, ou Exiger Optic ID pour se connecter : l'interrupteur nomme la biométrie de l'appareil), de la même façon sur toutes les plateformes. Il n'apparaît que si l'appareil dispose de la biométrie.

Une fois activé, Connexion demande d'abord, et si l'authentification échoue la connexion n'aboutit pas. Tester un profil ne demande rien. Vérifiez les autorisations dans Réglages Système › Touch ID et mot de passe (Mac), Réglages › Face ID et code ou Réglages › Touch ID et code (iPad et iPhone), ou Réglages › Optic ID et code (Apple Vision Pro).

Mots-clés : biométrie, touch id, face id, optic id, authentification, sécurité, empreinte, biometric, exiger biométrie

Organiser les profils en groupes

Comment regrouper vos connexions (Production, Développement, Client X, etc.) et déplacer des profils entre groupes sur macOS, iPad, iPhone et Apple Vision Pro.

Où le trouver : Gestionnaire de connexions › clic droit › Déplacer vers le groupe

Lorsque la liste des connexions grandit, vous pouvez les regrouper par environnement, client ou tout autre critère. Les groupes sont pliables et persistent dans connections.json sous forme de collections ordonnées.

Créer un groupe
- macOS : clic droit sur n'importe quel groupe existant (ou sur l'en-tête de la barre latérale) et choisissez Nouveau groupe. Il est créé avec le nom par défaut Nouveau groupe et passe immédiatement en mode d'édition pour que vous le renommiez.
- iPad, iPhone et Apple Vision Pro : dans le Gestionnaire de connexions, touchez Gérer les groupes (le dossier avec un engrenage dans la barre du bas) puis, dans la feuille, Nouveau groupe.

Renommer / supprimer
- macOS : clic droit sur le nom du groupe → Renommer le groupe ou Supprimer le groupe.
- iPad : pour renommer, touchez le crayon de la ligne dans la feuille Gérer les groupes ; pour supprimer, balayez cette ligne de droite à gauche. Vous pouvez aussi maintenir l'en-tête du groupe dans la liste.
- Supprimer un groupe supprime aussi les connexions qu'il contient, avec leur mot de passe enregistré, leur historique de requêtes et le SQL qu'elles avaient enregistré. Avant de supprimer quoi que ce soit, Calíope demande confirmation et indique combien de connexions partent et comment elles s'appellent. C'est irréversible : si vous voulez seulement défaire le regroupement, sortez d'abord les profils avec Déplacer vers le groupe ▸ Sans groupe.

Déplacer un profil
- macOS : clic droit sur le profil → Déplacer vers le groupe ▸ → choisissez le groupe cible ou Sans groupe pour le retirer de tout regroupement.
- iPad : balayez le profil de gauche à droite pour révéler l'action Déplacer (icône dossier, couleur indigo) ; la feuille de sélection de groupe s'ouvre.

Réordonner les groupes (iPad)
- Ouvrez Gérer les groupes et faites glisser avec la poignée ☰ pour réordonner. L'ordre persiste dans le champ sortOrder de chaque groupe.

Développer/replier
- Chaque groupe dispose d'un ▸ pour replier/développer sa liste de profils. L'état est enregistré par groupe.

Persistance
- Les groupes et leurs affectations vivent dans le fichier connections.json sur l'appareil actuel. Si la synchronisation iCloud est activée, ils sont partagés entre vos appareils.

Filtrer
- Le champ au-dessus de la liste ne laisse que les connexions correspondantes ; tant qu'il contient du texte, tous les groupes sont dessinés ouverts sans modifier ce que vous avez enregistré (voir Filtrer la liste des connexions).

Mots-clés : groupe, groupes, organiser, dossier, catégorie, production, développement, déplacer profil, glisser, balayer, nouveau groupe, renommer, supprimer groupe, sans groupe, connections.json

Étiquettes d’environnement

Marquez chaque connexion comme locale, de recette, de production ou selon vos besoins, avec le nom et la couleur de votre choix, et voyez-la comme une bande au-dessus de chaque outil.

Où le trouver : Gestionnaire de connexions › clic droit › Étiquettes d’environnement…

Une étiquette d’environnement indique où pointe une connexion — local, recette, production ou ce que vous décidez — avec un nom et une couleur que vous choisissez. Une fois connecté, l’étiquette apparaît comme une bande de sa couleur au-dessus de l’outil, dans tous les outils, et dans le menu du serveur : avant d’exécuter quoi que ce soit, vous voyez sur quel serveur vous êtes.

Le catalogue
- Les étiquettes vivent dans un seul catalogue, Étiquettes d’environnement. On l’ouvre avec le bouton Étiquettes d’environnement… du formulaire du profil, à côté de Environnement, ou depuis le menu contextuel de l’en-tête Sans groupe ou de celui de n’importe quel groupe : clic droit sur macOS, appui prolongé sur iPad, iPhone et Apple Vision Pro.
- Le catalogue est vide au départ. Nouvelle étiquette ouvre le formulaire, et Partir de propose trois modèles en un geste : Local (vert, sans protection), Recette (ambre, confirme les écritures) et Production (rouge, confirme les écritures). Ensuite, modifiez ce que vous voulez : Nom de l’étiquette, Couleur et Protection.
- Faites glisser les lignes pour changer l’ordre dans lequel elles apparaissent dans le sélecteur ; sur iPad, iPhone et Apple Vision Pro, touchez d’abord Modifier.
- Supprimer l’étiquette demande d’abord et indique combien de connexions l’utilisent. Ces connexions restent sans étiquette ; elles ne sont pas supprimées.

Étiqueter un profil
- Dans le formulaire du profil, le sélecteur Environnement propose Aucune et les étiquettes du catalogue. Les listes de connexions du Gestionnaire de connexions et des Réglages affichent devant le nom une pastille de la couleur.

Le niveau appartient à l’étiquette, pas au profil
- Chaque étiquette porte un niveau de Protection : sans protection, confirme les écritures ou lecture seule. Vingt connexions étiquetées « Production » en prennent le nom, la couleur et le niveau : modifier l’étiquette les modifie toutes les vingt. Si une connexion a besoin d’un autre niveau, créez une autre étiquette. Ce que fait chaque niveau est expliqué dans la rubrique « Niveaux de protection ».
- Le groupe n’hérite de rien : groupe et étiquette sont indépendants. Dans le groupe « Client X », il peut y avoir une connexion « Local », une « Recette » et une « Production ».

Où c’est enregistré
- Le catalogue est enregistré dans connections.json, avec les groupes et les profils : il voyage par iCloud Drive avec eux quand la synchronisation est activée, et l’export de Réglages › Connexions l’inclut.

Mots-clés : étiquette, étiquettes, environnement, production, recette, local, couleur, bande, protection, lecture seule, confirmer, catalogue, modèle, connections.json

Niveaux de protection

Ce que fait le niveau de protection de chaque étiquette d’environnement : aucun, confirmer ce qui écrit, ou lecture seule.

Où le trouver : Gestionnaire de connexions › clic droit › Étiquettes d’environnement…

Chaque étiquette d’environnement porte un niveau de Protection que vous choisissez dans son formulaire, dans Étiquettes d’environnement. Le niveau appartient à l’étiquette : toutes les connexions qui la portent le partagent.

Les trois niveaux
- Sans protection : les instructions s’exécutent comme d’habitude ; l’étiquette marque seulement la connexion avec sa bande.
- Confirme les écritures : avant d’exécuter ce qui écrit, Calíope demande « Écrire dans … ? », avec la source et le nombre d’instructions, et ne continue que si vous touchez Exécuter dans … avec le nom de l’étiquette. Il demande une fois par exécution : un script de vingt instructions, c’est une seule question. Ce qui avait déjà sa propre confirmation — exécuter le script complet, restaurer, supprimer un objet dans Catalogues, terminer un processus, supprimer un utilisateur — porte le nom de l’étiquette dans son titre et ne demande pas deux fois. Si une feuille est ouverte, la question s’affiche par-dessus. Annuler dans l’éditeur SQL laisse la requête arrêtée ; ailleurs, un avis indique qu’elle n’a pas été exécutée parce que vous avez annulé, et il ne va pas dans le journal des erreurs.
- Lecture seule : ce qui écrit n’est pas envoyé au serveur, et l’erreur nomme l’étiquette. De plus, les outils qui ne font qu’écrire — Constructeur de tables, Gestion des utilisateurs, Maintenance des tables et Migration de données — ne sont pas proposés, et dans les autres ce qui écrit n’est pas dessiné : restaurer, remplacer, importer, peupler, créer et supprimer des objets, terminer des processus, modifier et supprimer des lignes d’un résultat.

Ce qui compte comme écriture
- Tout ce qui n’est ni une lecture ni un contrôle de transaction. Ouvrir, valider ou annuler une transaction et changer de base (USE) n’écrivent pas. SET oui, ainsi que le contrôle de transaction qui demande READ WRITE : c’est ce qu’utiliserait une session pour retirer la lecture seule du serveur. Un bloc BEGIN … END compte comme écriture.
- La vérification lit le texte, pas ce que fera le serveur : un SELECT qui appelle une fonction à effets, comme SELECT nextval('s'), passe comme lecture.
- Annuler ou rétablir une modification de cellule sont de nouvelles écritures, et avec « confirme les écritures » elles demandent à chaque fois.

Où cela s’applique
- L’éditeur SQL — Exécuter, le terminal et le SQL Player — et ce que l’assistant IA laisse dans l’éditeur passent par la même vérification. L’assistant connaît aussi le niveau de l’étiquette et en tient compte quand il propose.
- Le Mode sécurisé de l’éditeur SQL passe en premier et ne change pas : ce qu’il bloque n’arrive jamais à la question.
- Siri et Raccourcis ne peuvent pas afficher la question : avec une étiquette qui confirme les écritures, une écriture via Siri n’est pas exécutée, et avec une étiquette en lecture seule elle échoue. Le serveur MCP a toujours été en lecture seule.
- Une base liée dans l’éditeur et la destination de Migration de données sont protégées par l’étiquette de leur propre profil.
- Rapports ne fait que lire. Sur une connexion en lecture seule, un rapport peut créer ses tables temporaires ; rien de plus.
- Une alerte SQL dont la règle écrit ne s’exécute pas avec une étiquette qui protège, à aucun des deux niveaux.

La couche du serveur
En lecture seule, là où le moteur sait se mettre en lecture seule par session, Calíope le lui demande aussi : ce qui échappe à la vérification, le serveur le refuse.

MySQLMariaDBAurora

Chaque connexion travaille avec SET SESSION TRANSACTION READ ONLY. Le serveur refuse avec l’erreur 1792 INSERT, UPDATE, DELETE, CREATE et DROP — une table temporaire aussi — et SELECT … FOR UPDATE. Il laisse passer SET GLOBAL, KILL et FLUSH, que la vérification de Calíope refuse déjà avant, et ANALYZE TABLE, que Calíope ne refuse pas non plus parce qu’il ne modifie aucune ligne.

PostgreSQL

Chaque connexion démarre avec default_transaction_read_only = on. Le serveur refuse avec l’erreur 25006 ce qui écrit, une table temporaire aussi, SELECT nextval(…) et SELECT … FOR UPDATE : ici s’arrête la fonction à effets que la vérification laisse passer. Il laisse passer ALTER SYSTEM, que Calíope refuse avant, et SELECT pg_terminate_backend(…), qu’aucun des deux ne refuse. Un SET default_transaction_read_only = off désactiverait la couche : c’est pourquoi Calíope refuse SET.

ClickHouse

Chaque requête porte readonly=2. Le serveur refuse avec le code 164 INSERT, les mutations (ALTER TABLE … UPDATE), CREATE, DROP, TRUNCATE, OPTIMIZE et SYSTEM FLUSH LOGS. Il laisse passer SET, la clause SETTINGS, KILL QUERY — Arrêter fonctionne toujours — et les tables temporaires d’un lot. SET readonly = 0 ne peut pas le désactiver.

SQL Server

Pas de couche du serveur : T-SQL n’a pas d’état de lecture seule par session, et ApplicationIntent=ReadOnly ne fait qu’envoyer vers une réplique lisible d’un groupe de disponibilité ; contre un serveur seul, il n’empêche rien. C’est la vérification de Calíope qui protège.

Oracle

Pas de couche du serveur : SET TRANSACTION READ ONLY vaut pour une transaction et se termine au COMMIT ou ROLLBACK suivant ; il n’y a pas d’équivalent par session. C’est la vérification de Calíope qui protège.

Redis

Pas de couche du serveur : Redis n’a pas de lecture seule par connexion (READONLY est autre chose : il permet de lire depuis une réplique d’un cluster). Dans la console, Calíope demande au serveur ce qui écrit, et ce qui est administratif et que le serveur ne marque pas — CONFIG SET, CLIENT KILL… — compte quand même comme écriture. Le détail est dans la rubrique « La console de commandes ».

MongoDB

Pas de couche du serveur : MongoDB n’a pas de lecture seule par connexion ; ce qui existe, ce sont les rôles du compte (read). Une commande de Commandes MongoDB est jugée d’après une liste de celles qui lisent, et une agrégation avec $out ou $merge écrit. Le détail est dans la rubrique « Envoyer des commandes au serveur ».

Ce que ce n’est pas
C’est une protection contre les accidents, pas de la sécurité. La sécurité, c’est un utilisateur en lecture seule sur le serveur.

Mots-clés : protection, niveau, lecture seule, confirmer, écrire, environnement, étiquette, production

Filtrer la liste des connexions

Tapez dans le champ au-dessus de la liste pour ne garder que les connexions qui correspondent, par nom, hôte ou groupe.

Avec trente ou quarante profils, déplier un groupe ne suffit plus. Le champ en haut de la barre latérale ne laisse que les connexions qui correspondent à ce que vous tapez.

Ce qu'il cherche : le nom du profil, son hôte et son hôte alternatif, la base par défaut, le nom d'utilisateur, le nom du moteur et le nom de son groupe. Taper le nom d'un groupe l'affiche donc en entier — c'est la façon de dire montre-moi la production. Les accents et les majuscules n'ont pas d'importance.

Pendant le filtrage, les groupes s'ouvrent tout seuls, y compris ceux que vous aviez repliés, pour que rien de correspondant ne reste caché dans un groupe fermé. Cette ouverture n'est pas enregistrée : videz le champ et chaque groupe revient exactement comme vous l'aviez laissé.

La sélection ne bouge pas. Si le profil que vous éditiez sort du filtre, le formulaire de droite continue de l'afficher : perdre ce que vous éditiez parce que vous avez tapé dans une recherche serait pire que le problème que la recherche résout.

Appuyez sur Échap ou sur le × pour vider le champ. Le filtre n'est pas conservé à la fermeture de l'app.

Mots-clés : filtrer, rechercher, connexions, liste, groupe, hôte, trouver un profil

Familles de serveurs et produits

Ce qu'est une famille, ce qu'est un produit, et comment Calíope propose le produit que le serveur déclare être lorsque vous testez la connexion.

Où le trouver : Panneau latéral › Gestionnaire de connexions

Calíope regroupe les serveurs par famille, c'est-à-dire le protocole qu'il parle : MySQL / MariaDB, PostgreSQL, SQL Server, Oracle Database, ClickHouse, MongoDB et Redis. Dans chaque famille, vous choisissez le produit : le nom précis de ce que vous avez devant vous.

Familles et produits
- MySQL / MariaDB : MySQL, MariaDB, Amazon Aurora MySQL et « Autre compatible MySQL ».
- PostgreSQL : PostgreSQL, Amazon Aurora PostgreSQL et « Autre compatible PostgreSQL ».
- SQL Server : Microsoft SQL Server.
- Oracle Database : Oracle Database.
- ClickHouse : ClickHouse.
- MongoDB : MongoDB et « Autre compatible MongoDB ».
- Redis : Redis.

Ce que décide chacun. La famille décide avec quel moteur Calíope se connecte et quels outils sont proposés. Le produit fixe le nom, l'invite du terminal et les fragments préchargés ; Aurora MySQL, par exemple, apporte les siens. Un produit qui n'est pas la référence de sa famille affiche un avis dans le formulaire pour le rappeler ; vous pouvez le masquer avec Ne plus afficher.

Créer le profil
1. Sous Serveur (Type sur iPad et iPhone), choisissez la famille.
2. Sous Produit, qui sur le Mac est le menu d'à côté, choisissez le produit. Si le vôtre n'y est pas, choisissez « Autre compatible… ». Une famille à produit unique —SQL Server, Oracle Database, ClickHouse, Redis— n’affiche pas le menu Produit.
3. Renseignez hôte, port, utilisateur et mot de passe comme d'habitude. Avec Aurora, collez l'endpoint du cluster et activez SSL/TLS.

Le serveur dit qui il est. Lorsque vous appuyez sur Tester la connexion ou chargez la liste des bases, Calíope interroge le serveur et, s'il s'identifie comme un autre produit de la même famille, le propose sous le sélecteur : appuyez sur Utiliser … pour corriger le profil, ou ignorez-le. Il ne le change jamais de lui-même. MongoDB n'est pas interrogé.

Remarque
Les fonctions propres à un produit (authentification IAM d'Aurora, endpoints différenciés, métriques aurora_%) ne reçoivent aucun traitement particulier : Calíope gère le serveur comme un membre standard de sa famille. Un jeton IAM entre donc comme il le ferait avec MySQL 8 ou PostgreSQL : comme mot de passe en clair, que Calíope n'envoie qu'avec SSL/TLS activé. Le jeton est généré par la personne qui se connecte, pas par Calíope.

SQL Server se connecte à la version 2022 ou ultérieure, toujours chiffré. Un profil SQL Server synchronisé vers un appareil qui a encore Calíope 1.4 s'y affiche comme MariaDB, car cette version ne connaît pas la famille ; l'ouvrir là-bas ne fonctionnera pas tant que cet appareil n'est pas mis à jour.

ClickHouse se connecte à la version 25.3 ou ultérieure par son interface HTTP —le port 8123, ou 8443 avec TLS—, y compris à travers un tunnel SSH. Un profil ClickHouse synchronisé vers un appareil qui a une version antérieure de Calíope s'y affiche comme MariaDB ; une fois cet appareil mis à jour, on le récupère en choisissant de nouveau ClickHouse dans le profil.

Redis numérote ses bases au lieu de les nommer : le formulaire demande donc un Numéro de base —de 0 à 15, sauf si le serveur est configuré avec davantage— et n’a ni encodage ni collation. L’Utilisateur est facultatif : le mot de passe seul suffit pour se connecter, et l’utilisateur n’est nécessaire qu’avec des utilisateurs ACL (Redis 6 ou ultérieur).

Oracle Database se connecte à un service, pas à une base : le formulaire demande le Service —le SERVICE_NAME, FREEPDB1 sur une installation Free— sur le port 1521, ou 2484 avec SSL/TLS. Un SID ne convient pas ; saisissez le nom du service. Pour le connaître, lsnrctl status sur le serveur liste les services qu’il écoute. Calíope est mesuré contre Oracle AI Database 26ai, la version Free que Docker télécharge sans compte ; 19c et 23ai parlent le même protocole, mais ne sont pas mesurés. On se connecte avec utilisateur et mot de passe, y compris en TLS dans un seul sens ; l’authentification par jeton (OCI IAM, OAuth), Kerberos, celle du système d’exploitation et le wallet avec certificat client n’y sont pas —avec Autonomous on se connecte en TLS sans wallet—. Un profil Oracle synchronisé avec un appareil qui a une version antérieure de Calíope y apparaît comme MariaDB ; une fois cet appareil mis à jour, on le récupère en choisissant à nouveau Oracle Database dans le profil.

Mots-clés : famille, produit, aurora, amazon aurora, aws, rds, mysql, mariadb, postgresql, mongodb, compatible, protocole, détecter, type de serveur

Dupliquer un profil de connexion

Dupliquer copie entièrement le profil choisi, avec son mot de passe, et laisse le double sélectionné pour que vous y changiez ce qu’il faut.

Dupliquer copie entièrement le profil choisi —champs, groupe, étiquette d’environnement, ainsi que les fichiers TLS et la clé SSH choisis sur cet appareil— et son mot de passe. Le double porte le nom de l’original précédé de « Copie de », démarre avec son compteur d’utilisation à zéro et reste sélectionné pour que vous y changiez ce qu’il faut.

Il se trouve dans la barre de la liste des connexions, dans le menu contextuel de chaque ligne et, hors du Mac, en faisant glisser la ligne.

Mots-clés : dupliquer, copier, cloner, profil, connexion

Charger la liste des bases, jeux de caractères et collations

Charger les données du serveur demande au serveur ses bases, jeux de caractères et collations, pour les choisir dans une liste au lieu de les saisir.

Le bouton à flèche circulaire à côté de la base de données et du jeu de caractères, Charger les données du serveur, demande au serveur ses bases, jeux de caractères et collations, pour que vous les choisissiez dans une liste au lieu de les saisir. Il est désactivé tant que l’hôte ou l’utilisateur manque.

Si la base par défaut du profil n’existe pas sur le serveur, le formulaire le signale. Le jeu de caractères et la collation n’apparaissent que pour les moteurs qui les utilisent à la connexion : pas pour ClickHouse, Oracle ni Redis. Si le profil passe par un tunnel SSH, la clé du bastion est demandée comme à la connexion.

Mots-clés : base de données, jeu de caractères, collation, serveur, charger, profil

Notifications de tunnel SSH

Calíope vous avertit lorsque le tunnel SSH tombe et lorsqu'il se rétablit automatiquement.

Où le trouver : Calíope › Réglages › Général → Notifications

Lorsqu’un profil a le Tunnel SSH et la Reconnexion automatique activés, Calíope envoie des notifications locales à deux moments :

- Tunnel perdu — quand elle trouve la connexion coupée, avant de tenter la reconnexion.
- Tunnel rétabli — quand la reconnexion restaure le tunnel.

Les deux viennent de la reconnexion automatique, et Calíope la tente quand vous changez la base de données active : une requête qui trouve le tunnel tombé ne prévient pas ici. Sans Reconnexion automatique, aucune n’est envoyée.

Activer ou désactiver :
Allez dans Réglages › Général › Notifications et utilisez le bouton Tunnel SSH perdu / rétabli.

Si la reconnexion échoue, aucune notification de rétablissement n’est envoyée ; la chute a déjà été notifiée. L’intervalle minimal entre deux notifications pour le même hôte est de 60 s.

Mots-clés : notification, ssh, tunnel, perdu, reconnexion, alerte, automatique