Chaque capacité, vérifiée face au code source.
Calíope est distribuée comme une application unique dont les capacités ci-dessous sont disponibles sur Mac, iPad, iPhone et Apple Vision Pro. Chaque entrée correspond à du code qui existe aujourd'hui — c'est un catalogue, pas une liste de souhaits. Utilisez les raccourcis pour sauter à une catégorie, ou parcourez la liste complète.
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.
“Votre tunnel SSH, sans terminal ni .ssh/config.”
Atteignez des serveurs derrière un bastion depuis le sandbox macOS — sans ssh local, sans ~/.ssh/config, sans batailles de permissions.
SwiftNIO + NIOSSH. Authentification par mot de passe ou par clé privée (ed25519, ECDSA P-256/P-384/P-521). Parseur OpenSSH et déchiffrement de passphrase en mémoire. Proxy local sur 127.0.0.1 ponté via SSH direct-tcpip.
“Vous alerte si quelqu'un a intercepté votre tunnel — avant que vous ne tapiez quoi que ce soit.”
Détecte un MITM contre votre bastion SSH sans conserver un fichier known_hosts sur disque.
Empreintes stockées dans le Keychain. La première connexion demande une confirmation explicite ; une empreinte modifiée échoue durement — équivalent à StrictHostKeyChecking=yes.
“SSL qui protège vraiment — pas juste un interrupteur.”
Activer « SSL » signifie SSL vérifié. Les certificats auto-signés exigent une CA ou un opt-out explicite avec un avertissement visible.
Politique unique : sauter la vérification est opt-in ; une CA fournie donne une vérification sans nom d’hôte ; sinon, vérification complète.
“Vos mots de passe ne visitent pas iCloud sauf si vous les invitez.”
Vous décidez quels identifiants voyagent entre vos appareils. Par défaut, aucun.
Le mode local-only fixe les identifiants à WhenUnlockedThisDeviceOnly ; activer la synchronisation les migre à AfterFirstUnlock pour iCloud Keychain. L’interrupteur est idempotent.
“Votre empreinte déverrouille la production, pas seulement votre Mac endormi.”
Ajoutez une porte Touch ID / Face ID avant de vous connecter à des serveurs de production, configurable par profil.
Construit sur le framework LocalAuthentication. Activable par profil de connexion.
“Un pool de connexions qui ferme toujours — même quand quelque chose échoue.”
Des connexions qui ne fuient pas de ressources ni ne bloquent l'interface, même lors du changement de session.
SwiftNIO EventLoopGroupConnectionPool, plafonné à 5 connexions par event loop dans un event-loop group mono-thread. Fermeture asynchrone avec timeout de sécurité et fermeture SSH propre lorsque le binding local échoue.
“Bindings préparés, pas d'interpolation de chaînes — dès la base de la pile.”
Les valeurs que les outils de Calíope envoient pour vous — un filtre, une cellule modifiée, une ligne insérée — ne sont jamais concaténées au SQL : elles voyagent via le protocole réseau, séparées de l’instruction. Ce que vous écrivez dans l’éditeur SQL part tel quel, comme dans n’importe quel client.
La requête préparée propre à chaque moteur, dans un client que j’ai écrit : sans bindings → requête simple (COM_QUERY pour MySQL et MariaDB, la requête simple pour PostgreSQL) ; avec bindings → COM_STMT_PREPARE et COM_STMT_EXECUTE pour MySQL et MariaDB, l’instruction étant fermée sur tout chemin où la connexion survit, le pool ne fuit donc jamais, et Parse, Bind et Execute pour PostgreSQL, avec des marqueurs $n. SQL Server : sp_executesql par RPC, avec des paramètres typés. Oracle Database : binds :1 typés dans l’appel d’exécution. ClickHouse : paramètres typés {name:Type}, envoyés comme champs param_ de la requête HTTP. Les identifiants passent toujours par le helper d’échappement centralisé pour les cas résiduels DCL/DDL.
“Un serveur, deux adresses — et il essaie les deux.”
On atteint souvent le même serveur par une adresse depuis le Mac et par une autre depuis l'iPad. Donnez au profil une seconde adresse et Calíope l'essaie quand la première ne répond pas, avec le même port et les mêmes identifiants.
La destination est résolue par connectionEndpoints, jamais en lisant le champ hôte : les trois endroits qui ouvrent un pool reçoivent l'endpoint. Ordre fixe, principal puis alternatif, sans mémoriser lequel a gagné — cet état est précisément ce qui ne peut pas voyager entre appareils. Accepte hôte:port pour une route publiant un autre port. Ignoré avec un tunnel SSH, et l'interface le dit : là, l'hôte est résolu par le bastion, pas par votre appareil.
“Vous savez sur quel serveur vous êtes avant d’exécuter quoi que ce soit.”
Chaque connexion peut porter une étiquette avec le nom et la couleur que vous choisissez — local, recette, production — et un bandeau de sa couleur se place au-dessus de chaque outil, avec un niveau de protection qui peut demander avant ce qui écrit ou le refuser tout net.
Un seul garde, écrit une fois, juge chaque instruction avant de l’envoyer ; en lecture seule, le serveur lui-même passe aussi en lecture seule là où il sait le faire — SET SESSION TRANSACTION READ ONLY avec MySQL et MariaDB, default_transaction_read_only au démarrage avec PostgreSQL, readonly=2 à chaque requête vers ClickHouse —, tandis qu’avec SQL Server, Oracle, Redis et MongoDB il n’y a que le garde du client. Cela protège contre les accidents, pas contre les attaquants : c’est le rôle d’un utilisateur en lecture seule sur le serveur.
“L'éditeur sait si vous êtes dans le FROM, le WHERE ou la liste de colonnes.”
Écrivez moins, et commettez moins d'erreurs, car la suggestion comprend où vous êtes dans l’instruction.
Suggère les colonnes de la table active, les noms de bases de données, les tokens de schéma (tables, vues, fonctions), les mots-clés DML/DDL/de contrôle, les types de données et les phrases auxiliaires SQL filtrées par moteur.
“Les parenthèses déséquilibrées n'atteignent jamais le serveur.”
Attrape l'erreur évidente avant que le serveur ne la rejette.
Détecte les commentaires non fermés, les chaînes non fermées, les parenthèses déséquilibrées et les identifiants avec backtick ouvert. Balayage O(n), sans parseur complet.
“Un DROP ne part pas par accident.”
Un formatage lisible pour vos requêtes, et un verrou qui empêche un UPDATE ou un DROP d'atteindre le serveur avant que vous le vouliez.
Le formateur met en majuscules les mots-clés à partir du vocabulaire propre au moteur. Le mode sécurisé, activé par défaut et enregistré par profil et par onglet de l'éditeur, refuse d'exécuter toute instruction qui contient ALTER, CREATE, DELETE, DROP, GRANT, TRUNCATE, UPDATE, REPLACE ou RENAME — depuis l'éditeur, le Terminal comme le SQL Player. Il cherche le mot, pas le WHERE : un UPDATE qui en a un est arrêté lui aussi, et rien ne part tant que vous ne le désactivez pas.
“Synchronisez votre historique, pas vos identifiants.”
Votre journal de requêtes ne devient pas un fichier de mots de passe sur iCloud.
Neutralise IDENTIFIED BY, IDENTIFIED WITH … AS, IDENTIFIED BY PASSWORD, SET PASSWORD FOR et PASSWORD(…). Occultation idempotente, appliquée avant d'exporter le journal de requêtes vers CloudKit.
“Composez des requêtes en cliquant ; elles sortent prêtes pour la production.”
Un SELECT … WHERE … JOIN … correct sans mémoriser la syntaxe.
Constructeurs visuels dédiés aux quatre formes les plus fréquentes : SELECT, WHERE, UPDATE et CREATE de table.
“Renommez id sans casser client_id.”
Refactorisez des identifiants en toute sécurité, sans détruire des noms similaires.
Regex avec bornes de mot \b et échappement adéquat. Ne matche jamais à l'intérieur d'identifiants plus longs.
“⌘⇧O et vous êtes sur la table que vous cherchiez.”
Atteignez n'importe quel objet du schéma sans descendre dans l'arbre.
Recherche floue incrémentale sur tables, vues, routines et objets, avec navigation aux flèches et Entrée pour ouvrir.
“Vos snippets s'adaptent au moteur, pas l'inverse.”
Vos recettes SQL toujours à portée, filtrées selon le moteur utilisé.
Stockés dans snippets.json, qui voyage par iCloud avec l'interrupteur général de synchronisation et reste sur l'appareil quand il est désactivé. Chaque snippet déclare à quels moteurs il s'applique (MySQL, MariaDB, PostgreSQL…). La connexion à un nouveau moteur ajoute les valeurs par défaut sans doublons. Prend en charge la catégorisation.
“La documentation de GROUP_CONCAT s'ouvre là où vous tapez.”
Documentation sans quitter l'éditeur ni ouvrir un navigateur.
Affiche le DDL de l'objet du schéma sous le curseur, ou la fiche de la fonction : signature, description, paramètres, un exemple et la version où elle est apparue. Chaque moteur a ses fiches, SQLite et DuckDB compris, tout comme les opérateurs MongoDB dans l'outil Requête. Sans souris, ⌥⌘?.
“Éditez la cellule, voyez le SQL, et décidez.”
Modifiez les données rapidement et prévisualisez le SQL exact qui sera exécuté.
Édition façon tableur sur les résultats, avec un aperçu de l'UPDATE ou du DELETE généré avant exécution.
“Lecture, pause et pas à pas dans votre script, comme une vidéo.”
Exécutez une migration une instruction à la fois et vérifiez chaque résultat avant que la suivante ne parte.
Découpe le script de l'éditeur en instructions et les exécute une par une, à la main ou à intervalle, avec les commandes première, précédente, suivante et dernière ; la lecture automatique s'arrête à la première erreur. Chaque instruction affiche son état, son temps et les lignes renvoyées ou modifiées, et entre dans l'historique des requêtes. Le mode sécurisé s'applique.
“L'invite mysql>, sans quitter l'app.”
Tapez une instruction, appuyez sur Retour, lisez la réponse en texte — comme le client en ligne de commande, à côté de votre script.
Un panneau sous l'éditeur avec l'invite propre au moteur (mysql>, postgres=#…), les résultats en tableau ASCII, « Query OK » avec les lignes que le serveur dit avoir modifiées, et les avertissements du serveur en dessous. Son propre historique, avec les flèches sur le Mac et des boutons sur iPad, iPhone et Apple Vision Pro ; chaque instruction entre aussi dans l'historique de la session. Le mode sécurisé s'applique.
“D'un jeu de résultats à un graphique, sans rien exporter.”
Barres, lignes ou camembert à partir des lignes que vous venez d'obtenir, dans un panneau de l'éditeur.
Les axes sont choisis pour vous — la première colonne de texte pour les catégories, la première numérique pour les valeurs — et vous pouvez les changer. Le graphique s'exporte en PNG ou en PDF.
“La préproduction est-elle identique à la production ? Demandez aux deux à la fois.”
Exécutez la même requête sur deux connexions et voyez, ligne par ligne, ce qui diffère.
Exécuter sur deux bases… envoie l'instruction aux deux et remplace la grille par une comparaison : cellules modifiées marquées, lignes présentes d'un seul côté, et un filtre pour n'afficher que les différences. Les lignes sont appariées par position, et seulement quand les deux côtés renvoient les mêmes colonnes.
“Clavier iPad avec des super-pouvoirs SQL.”
Suggestions tactiles rapides juste au-dessus du clavier virtuel.
Barres contextuelles pour l'objet ou la fonction sous le curseur, avec un accès rapide à « Voir DDL » et aux paramètres de fonction.
“Votre barre, dans votre ordre.”
Chacun a son ergonomie ; les DBAs réorganisent une fois et oublient.
Réorganisez ou masquez les groupes de boutons depuis une feuille de personnalisation dédiée. La mise en page est persistée.
“Une recherche dans toutes vos colonnes textuelles.”
Cherchez une chaîne dans toutes les colonnes textuelles de toutes les tables à la fois, voyez les correspondances par table et par colonne, prévisualisez le résultat calculé par le serveur et remplacez en masse dans une transaction par table.
Deux chiffres sont affichés, pas un : la collation ignore souvent la casse, REPLACE() jamais, donc sans cet avertissement une modification en masse annonce 300 lignes et en change 100 sans que rien n'échoue. L'écart est mesuré avec CAST(col AS BINARY) plutôt qu'avec une collation nommée. Colonnes générées, clé primaire et uniques sont exclues par défaut — MariaDB accepte l'UPDATE d'une colonne générée, signale une ligne affectée et ne change rien. L'échappement utilise |, car l'antislash casse sous NO_BACKSLASH_ESCAPES.
“Vos colonnes GEOMETRY cessent d'être 25 octets.”
Points, lignes et polygones dessinés sur une carte ancrée dans l'éditeur, avec styles satellite et plat, regroupement et un contrôle d'ajustement aux données. Faites glisser un point ou un sommet et Calíope compose l'instruction — il vous la montre avant d'écrire quoi que ce soit.
Le WKB transmis est toujours en (longitude, latitude) ; ce qui change, c'est le texte, car MySQL 8 sous un SRID géographique écrit la latitude d'abord, et MariaDB jamais. L'échange ne vit qu'à la frontière textuelle, où le paramètre n'a pas de valeur par défaut : se tromper ne produit pas d'erreur, cela déplace la ligne d'un continent et le serveur l'accepte. Le SRID voyage avec la géométrie, sans clé primaire fiable l'édition est bloquée et la raison est affichée, et il n'y a aucun CoreLocation.
“Une requête enregistrée qui répond deux fois la même chose.”
Enregistrez une requête avec ses paramètres déclarés et sa sortie définie — quelles colonnes, dans quel ordre, avec quels titres et formats — et exécutez-la quand vous voulez, à la main ou planifiée. Exportez-la en CSV, TSV, JSON, Markdown, HTML, XML, texte, Excel ou PDF paginé. Les définitions des rapports voyagent avec la synchronisation iCloud ; leurs résultats et leur historique d’exécutions restent sur l’appareil qui les a exécutés.
Les paramètres sont liés, jamais collés dans le texte de la requête : rien de ce qu’on y saisit ne peut changer ce qu’elle fait, dans aucun des deux modes SQL. Le contrat de colonnes est vérifié à l’exécution — une colonne qui cesse d’arriver, ou qui arrive avec un autre type, est annoncée au lieu d’être dessinée en silence. Chaque exécution laisse sa ligne dans un historique partagé avec les sauvegardes, avec ses paramètres, son décompte et la machine qui l’a exécutée. Le planifié ouvre sa propre connexion depuis le profil, et ne promet jamais de tourner app fermée.
“Le même rapport, contre trois sortes de base différentes.”
Le même artefact et le même écran servent votre MySQL de production, le fichier .sqlite d’une app, un fichier .duckdb et une collection MongoDB.
Le moteur de rapports ne dépend pas du fournisseur de base de données : il a sa propre couture, plus étroite, avec trois membres et pas un de plus. Il existe des implémentations pour les bases relationnelles, pour les fichiers SQLite et DuckDB que vous avez ouverts vous-même et pour MongoDB avec find et aggregate. Ajouter une source, c’est implémenter ce protocole sans toucher au moteur. Et aucune source ne garde l’état de l’exécution précédente — quand l’une l’a fait, le deuxième rapport se projetait avec les colonnes du premier : un tableau de cellules vides, sans erreur ni avertissement.
“Préparer, indexer et lire — sur une seule connexion, sans toucher à vos tables.”
Les rapports qu’un DBA écrirait comme un script en cinq étapes tiennent dans un rapport, sans renoncer à la garantie qu’il ne touche pas vos données.
Tout rapport ne sort pas d’une requête : fixer une variable de session, construire une table temporaire en plusieurs passes, l’indexer et la lire à la fin. Le lot entier tourne sur une seule connexion empruntée — avec une connexion par instruction, la table temporaire créée par la première n’existerait plus à la dernière. Les instructions de préparation passent par une liste blanche et ne peuvent écrire que dans les temporaires de leur propre lot ; le plafond de lignes s’applique à la dernière.
“Neuf formats, et le PDF sait où la page se termine.”
Le PDF que vous envoyez à la direction dit « Montant », et le CSV du même rapport dit « Montant » — pas total_eur.
CSV, TSV, JSON, Markdown, HTML, XML, texte brut et XLSX — écrit par Calíope elle-même en ZIP plus XML, sans dépendances — plus un PDF paginé. Ce qui est exporté est ce que déclare la sortie, pas ce qui est revenu du serveur. Et le découpage du PDF est mesuré à partir de l’ascendante, de la descendante et de l’interligne de la police au lieu d’être estimé avec une constante : une constante coupe en deux la dernière ligne de chaque page, et cela ne se voit qu’une fois imprimé.
“Votre schéma, dans un arbre qui reflète comment vous le pensez.”
Une seule vue pour tout le catalogue du serveur.
Bases de données → tables / vues / routines / triggers / événements, avec chargement paresseux et actions contextuelles : DDL, colonnes, index, import de données, constructeur de WHERE.
ALTER“Comparez votre schéma, générez l'ALTER, relisez avant d'appliquer.”
Promouvez un schéma du staging à la production sans collecter les diffs à la main.
Compare deux schémas et génère l'ALTER TABLE nécessaire pour amener l'un à l'autre. La comparaison de colonnes tourne en parallèle via la structured concurrency. Source de vérité : INFORMATION_SCHEMA.
“Vous savez quel DDL vous avez exécuté, quand, et contre quel serveur.”
Traçabilité des changements de schéma, sans toucher au serveur.
Chaque CREATE / ALTER / DROP / RENAME est enregistré localement avec horodatage et serveur cible, dans le store SQLite local de l'app.
“Du staging à la production en trois clics — avec un aperçu.”
Clonez des objets entre environnements sans mysqldump ni fichiers .sql écrits à la main.
Double connexion (source + destination), sélection granulaire de tables, vues, routines, triggers et événements, avec options REPLACE, inclure les données ou ignorer les clés étrangères. Aperçu du SQL avant exécution.
“Un éditeur par type d'objet, pas un .sql générique pour tout.”
Éditez routines et événements correctement, dans un éditeur pensé pour l'objet.
Feuilles dédiées pour routines stockées, triggers, événements, vues et index. Chacune émet un DDL bien formé.
“Une table conçue colonne par colonne, pas tapée à la main.”
Créez une table ou modifiez-en une existante — colonnes, types, clés, index, clés étrangères — et lisez le CREATE ou l’ALTER TABLE avant qu’il ne s’exécute.
Chaque moteur déclare son propre catalogue de types et d’options : le constructeur propose ce que ce serveur possède, clé de tri et index de saut de ClickHouse compris. Modifier une table la compare à un instantané de l’originale et écrit l’ALTER TABLE de ce qui a changé, et rien d’autre. S’ouvre depuis Catalogues.
“CHECK, REPAIR, OPTIMIZE, ANALYZE et CHECKSUM, en un bouton.”
Entretien de vos tables, sur MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, Oracle Database et ClickHouse, sans mémoriser les commandes.
Exécute CHECK TABLE, REPAIR TABLE, OPTIMIZE TABLE, ANALYZE TABLE et CHECKSUM TABLE sur MySQL et MariaDB, et ANALYZE plus VACUUM et REINDEX TABLE CONCURRENTLY sur PostgreSQL, et UPDATE STATISTICS, DBCC CHECKTABLE et la reconstruction des index sur SQL Server, et CHECK TABLE et OPTIMIZE (toute la table ou une partition) sur ClickHouse, et les statistiques avec DBMS_STATS sur Oracle Database, avec un retour de progression.
“GRANTs et REVOKEs — avec des cases à cocher.”
Gérez les utilisateurs du serveur sans écrire chaque GRANT à la main.
CREATE / ALTER / DROP USER, ainsi que GRANT et REVOKE depuis une UI dédiée.
“Les index en trop, et ceux qui manquent — avec preuves.”
Identifiez les index redondants ou manquants à partir des données que le serveur expose déjà.
Vue conseiller qui analyse l'usage des index, associée à un éditeur dédié au catalogue d'index.
“Profilez la colonne, ne devinez pas les données.”
Comprenez la qualité de vos données avant d'écrire la requête analytique.
Statistiques d'une colonne du résultat chargé : nulls et leur part, valeurs distinctes, minimum, maximum et moyenne, et les dix valeurs les plus fréquentes, avec un graphique en barres des huit premières.
“Le diagramme ER que vous n'avez plus à dessiner.”
Documentez les relations sans dessiner des boîtes dans Miro.
Génération automatique à partir du schéma actif, avec visualisation des clés étrangères.
“Les bases de documents, avec leur propre vocabulaire.”
Parcourez collections et documents, modifiez-les en JSON, écrivez des filtres et des pipelines d’agrégation, gérez les index et consultez le serveur, ses opérations en cours et ses utilisateurs — sans quitter l’app que vous utilisez déjà pour MySQL.
Outil autonome : rien de MongoDB ne touche la couche des providers relationnels. Les documents s’affichent en arbres repliables avec le type de chaque valeur (ObjectId, decimal128, dates, binaires), car une collection n’a pas de schéma et deux documents voisins peuvent ne partager aucun champ. JSON étendu dans les deux sens avec un analyseur maison : l’ordre des champs et la largeur des nombres survivent à l’aller-retour. Réutilise le profil de connexion, le trousseau et le tunnel SSH natif. Curseurs paginés, fermés dès qu’on les abandonne. Six outils dans le navigateur : Collections MongoDB, Requête MongoDB, Index MongoDB, Serveur MongoDB, Commandes MongoDB et Profileur MongoDB.
“Des clés, de la mémoire et des commandes — pas des tables déguisées.”
Une session Redis ouvre sept outils à elle : l'Explorateur de clés, le Panneau du serveur, l'Analyseur de mémoire, les Commandes lentes, les Clients connectés, la Console de commandes et la Topologie des nœuds. Vous voyez quel préfixe dévore la mémoire, quelle commande a dépassé le seuil et quel client déconnecter, depuis la même app que pour le SQL.
Son propre client RESP, hors de la couche des providers relationnels. Les clés se parcourent avec SCAN, jamais KEYS, et aucune collection n'est lue en entier — un gros HGETALL bloque le serveur tout autant. Dans un cluster, MOVED relit la carte des slots et ASK non ; un cluster ne s'ouvre pas par un tunnel SSH, car il annonce des adresses que le tunnel n'atteint pas, et la session le dit avant d'ouvrir. La console refuse ce qui laisserait un état sur la connexion (MULTI, WATCH, SUBSCRIBE…) et les commandes bloquantes sans délai. Le seuil du journal des commandes lentes est en microsecondes, et c'est écrit ainsi.
“Les mêmes sept outils, sur le fork ouvert.”
Valkey, le fork de Redis de la Linux Foundation, s'ouvre dans les mêmes sept outils : clés, serveur, mémoire, commandes lentes, clients, console et topologie, cluster compris. Le panneau du serveur montre la version et le mode propres à Valkey, l'invite de la console dit valkey>, et Tester la connexion le reconnaît et propose « Utiliser Valkey ».
Le même client RESP écrit pour Redis, parce que Valkey parle le même protocole : le produit se lit dans le salut du serveur, jamais dans une liste de noms, et ce qui change entre les deux est une différence déclarée, pas une copie du code. Mesuré contre Valkey 8.0 et 9.1, en serveur autonome et en cluster avec des slots en migration. Extraits, Rapports et l'Assistant IA fonctionnent aussi avec Valkey, et les douze chapitres Redis du Manuel du DBA disent où il diffère. Valkey 8.0 ou ultérieur.
“Deux moteurs, une app : votre MySQL distant et votre SQLite local.”
Ouvrez et modifiez le .sqlite d'une app iOS ou d'un script Python dans l'outil même où vous administrez MySQL — avec une transaction explicite avant toute écriture.
Couche autonome (acteur SQLiteConnection sur l'API C du système — sans pilote de serveur) avec Structure · Données · Exécuter SQL · Pragmas : concepteurs de tables, d'index et de vues, renommage, recherche et filtres, pagination avec la même taille de page que l'Éditeur SQL, tri, éditeur de cellule avancé, Exécuter SQL avec coloration syntaxique, autocomplétion depuis le schéma du fichier et plafond de lignes sur les résultats, transactions Enregistrer/Annuler, maintenance (integrity_check, VACUUM, ANALYZE, REINDEX), pragmas modifiables et import/export CSV · JSON · SQL. Compatible sandbox via des security-scoped bookmarks. Bases non chiffrées uniquement.
“L'analytique sur votre portable : un moteur en colonnes, sans serveur à installer.”
Ouvrez un fichier .duckdb, ou interrogez un Parquet, un CSV ou un JSON là où ils sont déjà, sans rien importer et sans serveur — dans l'app où vous administrez MySQL.
DuckDB 1.5.5 compilé dans l'app (paquet SPM local, DuckDBKit au-dessus de l'API C), hors du fournisseur de base de données comme l'Éditeur SQLite. Structure · Données · Exécuter SQL · Réglages, avec séquences, types et macros dans l'arborescence, SUMMARIZE, plafond de lignes et Arrêter sur les requêtes longues, export et import de la base entière, Enregistrer sous… pour les bases en mémoire, et l'attachement d'un autre fichier DuckDB en lecture seule. Les extensions ne sont pas téléchargées : les quatre incluses sont tout ce qu'il y a. Depuis la 1.7, DuckDB est un framework que l'app partage avec son extension Coup d'œil (Quick Look) : la barre d'espace dans le Finder ou l'aperçu dans Fichiers lisent un .duckdb ou un Parquet avec ce même moteur, et un .parquet ouvert depuis le Finder ou depuis Fichiers arrive ici, dans une base en mémoire, avec sa requête déjà écrite.
“Lire un fichier ne devrait pas exiger une connexion.”
Lisez le .md de la documentation, le .sql d'un collègue, le .json de configuration, un .csv exporté, un .rtf qu'on vous a envoyé ou le .log du serveur sans quitter l'app, sans vous connecter et sans risque d'exécuter quoi que ce soit par accident.
Lecture seule, un fichier à la fois, résolu par extension : moteur de rendu Markdown maison (ATX et setext, listes imbriquées, cases à cocher, code en bloc et indenté de quatre espaces, citations, règles, tableaux GFM), coloration SQL, formateur JSON, lecteur CSV conforme RFC 4180 avec détection du séparateur, et lecteur RTF qui conserve la structure et les emphases — titres, listes imbriquées, gras, italique, souligné, barré, liens et alignement — tandis que la police, les tailles et les couleurs restent celles de Calíope, afin que le texte suive la taille de texte dynamique et se lise dans les deux thèmes. Tout est analysé hors du thread principal et parvient à la vue sous forme de données inertes. Surveille le chemin du fichier avec DispatchSource, ce qui résiste aux sauvegardes atomiques. Plafonds déclarés et signalés en pied de page : 5 Mo de lecture, 500 Ko de coloration SQL, 2 Mo de formatage JSON, 10 000 lignes et 64 colonnes CSV. N'ouvre jamais le réseau — les images Markdown distantes affichent leur texte alt.
Apportez votre propre clé. L'achat n'inclut pas de crédits IA — vous utilisez votre propre clé d'API. Cela est déclaré ouvertement dans le paywall : « L'assistant fonctionne sans aucune clé avec Apple Intelligence ou Ollama ; les fournisseurs cloud (OpenAI, Google Gemini, Anthropic Claude) demandent votre propre clé, non incluse dans l'achat. »
Avec Apple Intelligence, rien ne quitte l'appareil ; avec Ollama, rien ne va au-delà de la machine que vous lui indiquez. Avec OpenAI, Gemini ou Claude, le schéma de la base de données active — noms de tables, colonnes et clés étrangères — part bien chez ce fournisseur, sous votre propre clé. Les lignes et les identifiants, jamais. Sauf si vous en décidez autrement : l’interrupteur Envoyer le schéma au modèle, dans le panneau même de l’assistant, en décide avant chaque question et avec n’importe quel fournisseur. Désactivé, rien du schéma n’est envoyé — pas même les noms des tables — et c’est vous qui les nommez dans la question. Sur macOS, Calíope peut aussi faire office de serveur MCP pour un client IA du même Mac : lecture seule, sur 127.0.0.1, désactivé par défaut.
“Deux fournisseurs qui ne coûtent rien et ne demandent rien.”
Apple Intelligence exécute le modèle du système sur votre propre appareil : sans clé, sans compte, sans coût, et votre question ne quitte pas l'appareil. Ollama exécute des modèles ouverts là où vous voulez — votre machine, ou une machine de votre réseau — et Calíope lui parle à l'adresse que vous écrivez.
Apple Intelligence via FoundationModels ; il n'est proposé que là où le système dit qu'il est disponible. Ollama via le protocole OpenAI contre votre propre URL de base, sans en-tête Authorization, et avec la liste des modèles non filtrée — leurs noms sont ceux que vous avez téléchargés. Quand le schéma ne tient pas dans la fenêtre locale, l'assistant le dit dans la conversation et propose quoi faire.
“IA qui tourne sur vos tokens, pas sur votre facture.”
Utilisez le modèle que vous payez déjà, et ne dépendez pas d'une hausse de tarif de Calíope par token.
OpenAI (modèles gpt-, o1, o3 et o4) avec token Bearer. Google Gemini avec clé d'API ; filtré aux modèles exposant generateContent. Anthropic Claude (claude-*) avec x-api-key et system prompt dans son propre champ (pas dans messages). System prompt avec le contexte du schéma actif, conservant les trois derniers échanges.
“Votre clé n'apparaît jamais dans une stack trace.”
Si un message d'erreur fuit dans une capture d'écran ou un canal Slack, votre clé d'API ne voyage pas avec.
Masquage par regex pour sk-* (OpenAI), AIza* (Gemini), sk-ant-* (Anthropic Claude, y compris sk-ant-api03-…) et Bearer … dans tout message d'erreur de fournisseur.
Retry-After“Si OpenAI dit attendez, Calíope attend exactement ce délai.”
Les pics de rate-limit ne cassent pas votre session.
Sur 429 / 503, réessai jusqu'à trois fois (1 s / 2 s / 4 s), en respectant l'en-tête Retry-After. Timeouts : 30 s pour la génération, 15 s pour lister les modèles.
“Dictez la question ; exécutez le SQL.”
Dictez une demande et l'assistant la transforme en SQL — utile sur iPad et en sessions pair-DBA quand les mains sont prises. Votre voix ne quitte pas l'appareil.
Basé sur SpeechAnalyzer et DictationTranscriber d'Apple (macOS 26 / iPadOS 26 / iOS 26 / visionOS 26) : la reconnaissance a lieu sur l'appareil, aucun audio n'est envoyé à un serveur et la dictée fonctionne hors connexion. Le modèle de langue est téléchargé une fois, avec progression visible, dans la langue choisie dans Calíope — ou dans toute autre langue prise en charge par la dictée du système, choisie depuis la capsule à côté du microphone, qui indique celle qui est écoutée. Seule l'autorisation du micro est demandée — la reconnaissance locale n'a pas besoin de celle de reconnaissance vocale. Résultats partiels en direct.
“Une conversation avec votre base de données, pas un prompt isolé.”
Demandez « maintenant avec un LEFT JOIN » et il sait de quelle requête vous parlez.
Conserve le contexte du schéma actif plus les derniers échanges, par conversation.
“Cursor ou Claude Desktop peuvent interroger votre base — en lecture seule.”
Un client IA sur le même Mac peut lister les bases, décrire les tables et lancer des requêtes en lecture seule sur les connexions que vous choisissez d'exposer.
JSON-RPC 2.0 sur HTTP, en écoute uniquement sur 127.0.0.1, sur le port 41500 sauf si vous le changez. Uniquement sur macOS, désactivé par défaut, et il ne répond que tant que Calíope est ouverte. Cinq outils, documentés avec les descriptions que reçoit le client sur leur propre page.
“Sauvegardes avec gzip natif — et pas de mots de passe exportés par accident.”
Des dumps compacts et sûrs par défaut — personne n'exporte de hashes de mots de passe par accident.
Génère un .sql avec les options de drop-before, inclusion des données, inclusion des utilisateurs, inclusion des identifiants utilisateurs (opt-in, désactivé par défaut) et compression gzip native. CREATE USER / ALTER USER / GRANT sont neutralisés quand les identifiants sont exclus. Événements de progression avec ETA.
“Des sauvegardes qui ne comptent pas sur votre mémoire.”
Votre Mac effectue la sauvegarde à l'heure, même s'il dormait, et ne remplit pas votre disque.
Planifications quotidiennes, hebdomadaires, les jours ouvrés, mensuelles ou toutes les N heures. Utilise des bookmarks security-scoped vers la destination pour fonctionner dans le sandbox. Gère les planifications ratées entre redémarrages, les noms de fichiers suffixés en nanosecondes pour éviter les collisions, la purge par rétention, et les notifications de succès/erreur/ignoré.
“D'un tableur à une table en trois clics.”
Importez des fichiers tabulaires du monde réel — pas seulement le CSV idéal.
CSV style RFC 4180 (guillemets échappés, champs avec virgules), JSON (tableau d'objets) et XLSX en streaming. Trois modes — Insérer, Ignorer les doublons et Remplacer les doublons — proposés là où le moteur les a : les trois sur MySQL et MariaDB, les deux premiers sur PostgreSQL, et seulement Insérer sur SQL Server, Oracle Database et ClickHouse.
“La commande que vous avez exécutée mardi, en deux secondes.”
Cherchez parmi des milliers de requêtes passées par texte SQL ou date.
Store SQLite local dans Application Support avec tables pour requêtes exécutées et journal d'audit DDL, indexé par texte de requête (asc) et date (desc).
“Votre historique SQL, dans votre iCloud, sans vos identifiants.”
Cherchez dans l'historique de votre Mac depuis votre iPad — sans les identifiants.
Conteneur CloudKit iCloud.org.caliope.caliope, lots de 400 enregistrements, rétention configurable (par défaut 90 jours). Applique l'occultation des identifiants avant l'envoi. Vérifie l'état du compte iCloud avant de synchroniser.
“Vous décidez ce qui part vers iCloud.”
Synchronisez uniquement ce qui vous intéresse — pas de tout ou rien.
À côté de l’interrupteur général d’iCloud, d’autres, indépendants, pour ce qui est copié dans votre iCloud : dans les Réglages, le trousseau iCloud, le journal d’erreurs de l’app et les messages système ; le journal des requêtes, depuis son propre outil, et les conversations de l’assistant IA, depuis leur panneau d’historique.
“722 Mo dumpés avec 68 Mo de mémoire.”
Sauvegarder et restaurer ne dépendent plus de la RAM de la machine. Un dump de 722 Mo avec 4 millions de lignes culmine à 68 Mo ; le restaurer prend 19 secondes avec 14 Mo. Annuler arrête vraiment le dump au lieu de le laisser aller au bout.
Le moteur orchestre et le provider écrit le SQL : ajouter un moteur à la sauvegarde revient à implémenter BackupDataSource et rien d'autre — le harnais de test l'implémente en mémoire avec des dialectes SQLite et Postgres sans toucher au moteur. La restauration tire une instruction à la fois au lieu de les recevoir poussées, car un flux tamponné perd des instructions en silence et finit en annonçant un succès. La lecture utilise read(2) et non un fichier mappé : le même découpage a mesuré +201 Mo résidents avec FileHandle et 1,1 Mo ainsi.
“Avant de toucher à iCloud, il y a une copie.”
Exportez et importez tout ce que Calíope conserve hors de l'appareil — profils, groupes, préférences — avec des copies programmées vers le conteneur iCloud et des points de restauration locaux pris automatiquement avant toute opération risquée : activer ou désactiver la synchronisation, effacer, importer.
Cela existe à cause d'un incident mesuré : activer la synchronisation sur un iPad a remplacé un connections.json de 16 470 octets avec 28 profils par un autre de 514 octets contenant un profil d'exemple. Les secrets sont en opt-in et toujours chiffrés (AES-GCM, PBKDF2-SHA256 avec 210 000 itérations, sel et coût écrits dans le fichier). Ce qui reste dehors est inscrit dans la copie avec sa raison — une copie qui tait ses absences est celle qui fait croire qu'on peut tout restaurer. La restauration fusionne ; une sauvegarde n'efface jamais.
“Le client entier, sans le Mac devant vous.”
La même Calíope, disposée pour le téléphone — le client entier, pas une visionneuse. Elle se connecte à vos serveurs et exécute vos requêtes, avec l'éditeur SQL, l'explorateur de schéma, le tableau de bord, le diagramme ER et les rapports sur place ; et vos profils de connexion, vos extraits enregistrés, votre historique et vos conversations avec l'assistant vous attendent déjà, apportés par votre propre iCloud. Face ID pour déverrouiller, cinq langues, et un mode démonstration pour explorer avant de connecter quoi que ce soit. Elle s'installe depuis la même page de l'App Store que le Mac et l'iPad, et apporte sur l'écran d'accueil les deux mêmes widgets : les métriques du serveur épinglé, aussi sur l'écran de verrouillage, et la santé de tout le parc.
C'est le binaire iOS, et c'est le même code que celui de l'iPad : pas un outil en moins, et pas une seule vérification d'appareil dans tout l'arbre — ce qui change, c'est la disposition, pas la liste des fonctions. Les profils de connexion sont fusionnés dans le fichier iCloud partagé au lieu de le remplacer, pour que les champs qu'un écran étroit n'affiche pas — tunnel SSH, certificats, jeu de caractères — restent intacts. Sans iCloud, elle nomme l'interrupteur fermé au lieu d'afficher un écran vide en vous laissant supposer que tout va bien.
“Ce qu'ont fait vos serveurs, sans sortir le téléphone.”
Calíope au poignet, qui arrive avec Calíope sur l'iPhone et que le même achat couvre, sans achat séparé. Elle affiche les messages système que Calíope publie : dix-sept types en sept groupes, avec les sauvegardes et rapports terminés ou en échec, les requêtes trop longues, les tunnels SSH tombés puis rétablis, la synchronisation iCloud en échec et les serveurs proches de vos seuils. Groupés par jour, avec des notifications optionnelles sur un réglage à part, et un mode démo qui montre aussi les écrans vides.
Les messages voyagent comme un identifiant accompagné de ses chiffres bruts, jamais comme une phrase déjà écrite : la montre est réglée dans une autre langue que le Mac plus souvent qu'à son tour, la phrase s'écrit donc au poignet. La cadence que vous choisissez est un minimum et non une promesse — app fermée, watchOS décide quand la réveiller — et l'app le dit en haut de son propre écran de réglages, pas en gris tout en bas. Le repère est le dernier message livré et non l'horloge murale, car les réveils sautent et demander « quelque chose dans les quinze dernières minutes ? » écarte le reste sans échouer. Elle ne fait que lire : elle n'ouvre aucune connexion vers un de vos serveurs.
“La santé du parc, lue de l'autre bout de la pièce.”
Un tableau mural pour vos serveurs MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, Oracle Database et ClickHouse : une tuile chacun, avec son état — Correct, Avertissement, Critique, Injoignable ou Aucune donnée — et, quand quelque chose ne va pas, quoi. Temps de fonctionnement, connexions, threads actifs, requêtes par seconde, taux de cache, requête la plus longue et retard du réplica. Deux onglets, parce qu'un téléviseur n'est pas un appareil dans lequel on navigue, et un parc de démonstration de huit serveurs pour regarder avant. Placez Calíope dans la rangée du haut de l'écran d'accueil et la bande au-dessus montre vos serveurs publiés, les plus urgents d'abord, puis les vidéos de démonstration de ce site ; choisir une carte ouvre ce serveur.
La fraîcheur est calculée par celui qui lit, à partir de la cadence que Calíope déclare : celui qui publiait ne sait pas qu'il a cessé de publier, un Mac éteint le vendredi laisserait donc le tableau au vert tout le week-end. L'état ne se distingue jamais par la seule couleur, et les seuils sont ceux de Calíope : le téléviseur peint, il ne juge pas. L'Apple TV n'a ni iCloud Drive ni Trousseau iCloud : « elle ne fait que lire » tient donc à la plateforme et non à une promesse.
“Le client complet, accroché dans la pièce.”
À partir de la 1.6, Calíope est une app native visionOS sur Apple Vision Pro : l'éditeur SQL, le navigateur de schéma, le diagramme ER, les sauvegardes, les rapports, le constructeur de requêtes — tous les outils, sans en retirer un seul. Elle se connecte à vos serveurs et elle écrit. Le navigateur d'outils et vos onglets ouverts se placent dans des ornements hors de la vitre, chaque commande est à la taille du regard et s'éclaire quand vous la regardez, et vous pouvez ouvrir plusieurs fenêtres et laisser chacune où vous voulez dans la pièce. Les widgets s'accrochent à un mur ou se posent sur une table. Elle vient de la même page de l'App Store et du même achat que le Mac et l'iPad.
C'est la même app que sur l'iPad, compilée pour visionOS au lieu d'être exécutée en mode compatible : le verre du système au lieu de fonds opaques, les barres en ornements, des cibles de 60 points avec la mise en évidence du regard, des feuilles à la taille de la fenêtre, et Optic ID là où l'iPad dit Face ID. J'avais déjà un panneau natif et je ne l'ai pas publié, parce qu'il en faisait moins que l'app iPad ; celle-ci fait tout ce que fait l'iPad. Jusqu'à la 1.6, Calíope tournait sur Apple Vision Pro comme l'app iPad, en mode compatible.
“Métriques de vos serveurs, stockées sur un serveur à vous.”
Monitoring historique sans installer Prometheus.
Un collecteur dédié écrit des snapshots sur un serveur de stockage de votre choix, en provisionnant des tables pour les échantillons (CPU, mémoire, connexions, QPS) et les événements (dépassements de seuil, retard de réplication). Rétention automatique.
“Votre plan d'exécution comme un diagramme vivant.”
Repérez le full scan qui tue votre requête sans lire du JSON ou du XML à la main.
Demande à chaque moteur son propre plan sans exécuter la requête — EXPLAIN FORMAT=JSON sur MySQL et MariaDB, EXPLAIN FORMAT='tidb_json' sur TiDB, EXPLAIN (FORMAT JSON) sur PostgreSQL, SHOWPLAN_XML sur SQL Server, EXPLAIN PLAN sur Oracle Database, EXPLAIN PLAN json = 1 sur ClickHouse — et le dessine en arbre. Codage couleur par type d'accès : full scan, range / index merge, optimisé, sort, join. Info-bulles avec access_type, lignes estimées et temps. Zoom à la molette, au pincement du trackpad ou avec les boutons de la barre — l'échelle est toujours affichée, et ⌘+ / ⌘− / ⌘0 font la même chose sans trackpad. Pan en faisant glisser.
“Voyez où vous perdez les millisecondes.”
Localisez quelle phase de la requête prend le temps.
Sur MySQL et MariaDB, basé sur SHOW PROFILE ; sur ClickHouse, qui n'en a pas, il lit la ligne de la requête dans system.query_log. Tableau et graphique en barres par phase (starting, Sending data, etc.) avec des temps en millisecondes. Sur PostgreSQL, SQL Server et Oracle Database, le bouton n'apparaît pas.
“Ce que votre serveur a déjà noté des requêtes qui ont trop duré.”
Vous lisez ce que le serveur a enregistré — de tous les clients qui s'y connectent, pas seulement de Calíope — et depuis le même écran vous activez le journal, déplacez le seuil et le videz. Un bouton envoie la requête dans l'éditeur, et le profileur est juste là.
Chaque moteur avec son vocabulaire. MySQL et MariaDB : les entrées viennent de mysql.slow_log quand le serveur écrit dans une table, et le résumé par instruction de performance_schema ; le seuil est long_query_time. PostgreSQL : pg_stat_statements, agrégé par forme d'instruction et non une ligne par exécution, et le seuil s'écrit avec ALTER SYSTEM plus pg_reload_conf() — celui qui vient de la ligne de commande de démarrage du serveur est déclaré non modifiable depuis ici au lieu d'échouer en silence. Oracle Database : le cache des curseurs de V$SQL, avec le seuil appliqué à la lecture, car Oracle ne tient pas de journal des requêtes lentes ; AWR reste dehors, il exige un pack payant. SQL Server : le cache des plans de sys.dm_exec_query_stats, agrégé par instruction — il ne tient pas non plus de journal des requêtes lentes, et rien n’est à activer pour le lire. ClickHouse : system.query_log, avec le seuil en millisecondes et le journal vidé sur disque avant lecture. TiDB : CLUSTER_SLOW_QUERY et le résumé par instruction de STATEMENTS_SUMMARY, avec le seuil en millisecondes. Redis et Valkey : un outil à part, Commandes lentes, avec le seuil en microsecondes. MongoDB : un outil à part, car le profileur est par base de données. Une liste vide n'est jamais la réponse : si le journal part dans un fichier de la machine du serveur, si performance_schema est désactivé ou si l'extension n'est pas créée dans cette base, ce motif exact est à l'écran. Sur Aurora les réglages sont en lecture seule — ils vivent dans le parameter group du cluster. Pas de graphiques, et rien n'est copié dans Calíope : vous voyez la fenêtre que le serveur conserve, à l'heure du serveur.
KILL guidé“Un KILL pour la requête qui a bloqué votre production.”
Terminez une requête incontrôlée sans ouvrir de terminal.
SHOW FULL PROCESSLIST avec colonnes pour id, user, host, database, command, time, state et info. Actions KILL QUERY et KILL CONNECTION. Sur PostgreSQL, la liste vient de pg_stat_activity et s’arrête avec pg_cancel_backend ou pg_terminate_backend ; sur SQL Server, de sys.dm_exec_sessions et sys.dm_exec_requests, et s’arrête avec KILL ; sur Oracle Database, de V$SESSION, chaque session désignée par SID,SERIAL#, et s’arrête avec ALTER SYSTEM CANCEL SQL ou ALTER SYSTEM KILL SESSION ; sur ClickHouse, depuis system.processes, où ce qui tourne est une requête et non une connexion, donc une seule action, KILL QUERY.
“Anciennes et nouvelles répliques, dans le même panneau.”
Voyez le retard de la réplique sans vous battre avec l'ancien et le nouveau vocabulaire.
SHOW REPLICA STATUS sur MySQL 8.0.22+ et MariaDB 10.5.1+, avec fallback automatique vers SHOW SLAVE STATUS sur les versions antérieures. Sur ClickHouse, où la réplication se fait par table, il affiche les tables répliquées, Keeper, le pire retard en secondes et la file en entrées. Métriques : IO/SQL running, secondes de retard sur la source, dernières erreurs avec horodatage, GTID sets, positions de log. Auto-rafraîchissement configurable.
“Une réplique peut annoncer zéro seconde alors qu’elle a des heures de retard. Ici, cela se voit.”
Vous voyez le groupe entier d’un coup, et vous cessez de vous fier à un « 0 seconde » qui signifie en réalité « je viens de me reconnecter ».
Vous déclarez quelle machine est la primaire et lesquelles sont les répliques. Rien n’est détecté automatiquement : SHOW REPLICA HOSTS ne voit que ce qui est connecté à cet instant, donc un groupe détecté changerait tout seul et « cette réplique n’est plus là » serait indiscernable de « cette réplique est tombée ». Cette requête sert à contredire une configuration incohérente, jamais à la reconfigurer. Qu’une réplique lise d’une autre machine se décide par server_id, jamais par nom d’hôte — derrière Docker, NAT, un VPN ou un tunnel, comparer des chaînes donne un avertissement permanent et faux. Un thread IO arrêté est critique même quand le retard affiche zéro, et à côté figure la dérive de GTID, comptée par origine plutôt que soustraite. Un membre qui ne répond pas n’entraîne pas les autres : « 7 sur 9 » est une lecture normale, et ceux qui manquent sont nommés. Elle ne fait que lire — elle n’opère jamais sur le groupe. Le diagramme porte un tableau comme alternative accessible, et aucun état ne se distingue par la seule couleur.
PURGE“Votre binlog, filtrable et purgable — depuis l'app.”
Auditez quels événements vos instructions ont produits sans descendre à mysqlbinlog.
SHOW BINLOG EVENTS avec catégorisation en DDL / DML / Système, recherche par texte et une limite de lignes configurable (par défaut 300). Prend en charge les binlogs chiffrés (MySQL 8.0.14+). PURGE BINARY LOGS TO avec confirmation explicite. MySQL et MariaDB seulement : les autres moteurs ne tiennent pas de journal binaire, et l'outil n'y est pas proposé.
“Le pouls de votre serveur, dans une seule vue.”
Consolidez la santé du serveur sans ouvrir cinq clients.
Informations serveur en plusieurs onglets (variables globales et de session, statuts globaux et de session, usage HDD), un Tableau de bord avec des graphiques en direct, et un Moniteur de santé du serveur.
“Deux requêtes sur la balance ; l'une gagne.”
Choisissez entre deux requêtes avec des preuves, pas de l'intuition.
Compare les temps d'exécution de variantes de requêtes côte à côte.
“Votre Mac vous prévient quand la réplique décroche.”
Le système vous prévient — vous n'avez pas à fixer l'app.
Alertes par seuil sur CPU, mémoire, connexions et retard de réplication. Notifications natives macOS/iOS.
“Votre propre règle, écrite en SQL, surveillée pour vous.”
Écrivez une requête qui renvoie une valeur, choisissez un opérateur et un seuil, et Calíope la relance à l’intervalle que vous fixez et signale la règle quand elle franchit la limite.
Opérateurs >, <, = et <>, comparés en décimaux exacts et non en doubles, et = et <> aussi sur du texte. Six états, pas un oui ou un non : pas encore mesurée, OK, alerte, aucune ligne, en échec avec le message du serveur lui-même, et refusée parce qu’elle écrit sous une étiquette d’environnement qui protège. Les règles voyagent par iCloud avec l’interrupteur général ; les mesures restent dans la session, si bien qu’une lecture ancienne n’est jamais présentée comme actuelle.
“Ce qui tourne ne disparaît plus quand vous changez d'onglet.”
Requêtes, sauvegardes, migrations et tâches planifiées sont enregistrées au même endroit, avec temps écoulé, destination et un Arrêter qui arrête vraiment. Visible depuis le pied de la barre latérale, depuis l'onglet qui travaille et depuis le sélecteur de serveurs.
Les opérations s'inscrivent elles-mêmes — rien ne sonde les drapeaux des autres, car un registre qui devine finit par mentir dans les deux sens. Les tâches (qui commencent et finissent) et les modes (allumés jusqu'à ce qu'on les éteigne) sont des types distincts, donc un mode n'a ni barre de progression ni chronomètre. Un lot survit à la destruction de sa vue : le contrôleur vit dans un store indexé par onglet, pas dans l'état de la vue. Seuil de 0,8 s avant que quoi que ce soit n'apparaisse — une requête de 40 ms n'est pas un processus.
“Une panne avec sa cause, sa suggestion et sa trace.”
Quand quelque chose échoue, Calíope dit ce qui s'est passé, suggère quoi vérifier et renvoie vers la rubrique d'aide correspondante. Tout atterrit dans un journal avec sa date et son appareil, que l'app iPhone peut lire d'où que vous soyez.
Aucun code d'erreur ne nomme un moteur : la table des codes natifs vit avec son provider, donc en ajouter un revient à implémenter un protocole. Le numéro natif est lu du paquet typé, pas extrait du message — l'ancien pilote ne l'écrivait pas, si bien qu'une erreur d'identifiants était classée en échec de connexion et vous envoyait vérifier le port. Le téléphone est en lecture seule : élaguer et supprimer restent sur le bureau. Et « aucune erreur » est une affirmation — six raisons différentes d'écran vide sont distinguées, car annoncer la bonne nouvelle alors que le canal est fermé est un mensonge en soi. Le tout se lit dans le Journal des erreurs.
“État du serveur, visible d'un coup d'œil, sur votre bureau.”
Voyez le pouls de votre serveur sans ouvrir Calíope.
Familles Small, Medium, Large et ExtraLarge. Les snapshots sont lus depuis un app group partagé avec file coordination pour des lectures concurrentes sûres. Les payloads dépassant un seuil sûr sont rejetés (protection DoS).
“Votre serveur sur l'écran de verrouillage.”
Métriques du serveur sur l'écran de verrouillage de votre iPhone ou de votre iPad — à quelques secondes.
Sept familles sur iPad — Small, Medium, Large, ExtraLarge, plus les accessoires Rectangular, Circular et Inline — et six sur iPhone, qui n'a pas d'ExtraLarge.
“Le pouls de votre serveur, accroché à côté de la fenêtre.”
Le même widget, posé sur un mur de la pièce : les métriques de votre serveur épinglé, là où vous levez les yeux pour les voir.
Small, Medium, Large et ExtraLarge, les quatre du Mac : visionOS n'a pas d'écran de verrouillage. Texture de verre, pour que le mur se voie à travers, et encastré dans le mur ou en saillie, au choix quand vous le placez.
“Tous les serveurs que vous surveillez, et lequel va le plus mal.”
Un second widget qui regarde toute la flotte au lieu d'un seul serveur : combien de serveurs vous surveillez et l'état du pire, sur le bureau du Mac, sur l'écran d'accueil de l'iPhone et de l'iPad, et sur un mur dans l'Apple Vision Pro.
Familles Small, Medium et Large, les mêmes sur le Mac, sur iOS et sur visionOS. Il lit ce que le moniteur de santé des serveurs a mesuré sur cet appareil, via l'App Group partagé ; l'extension n'interroge rien d'elle-même. Ni ExtraLarge ni familles d'écran de verrouillage, à dessein.
“Touchez le widget → le dashboard du bon serveur, d'un seul geste.”
Un toucher et vous êtes sur le dashboard du serveur correct.
URL du widget caliope://server/<uuid> quand un profil est lié ; sinon, retour à caliope://.
“Un widget par serveur — édité comme un widget météo.”
Épinglez un widget différent à chaque serveur — configuré en quelques secondes.
Configurable depuis l'UI d'édition de widget du système via une AppIntentConfiguration. Aucun code requis de l'utilisateur.
“Se rafraîchit quand ça compte ; dort quand ça ne compte pas.”
Le widget n'épuise pas votre batterie tout en affichant des données fraîches.
La politique de timeline confie le contrôle à WidgetKit, en respectant le budget de rafraîchissement du système. Retour au dernier snapshot lorsqu'aucune donnée fraîche n'est disponible.
“Un SELECT COUNT(*) depuis Siri, sans ouvrir Calíope.”
Exécutez une requête ou listez les bases de données depuis Raccourcis, sans ouvrir l'app.
Intents enregistrés : se connecter à un serveur, exécuter une requête (renvoie TSV avec en-têtes), lister les bases de données, ouvrir un onglet du workspace. Adossé à un pont interne qui expose les session et database managers aux AppIntents.
.sql“Sait s'ouvrir depuis Spotlight avec un .sql — comme toute app native.”
Se comporte comme une vraie app Mac — pas comme un portage Windows ou Electron.
Barre de menu complète : À propos, Ouvrir un fichier SQL, Fichiers récents, Quick Open, navigation entre onglets, Aide, Nouveautés, Politique de confidentialité, Support. Gère l'ouverture de fichiers .sql via NotificationCenter.
“Une icône dans la barre de menu : vous savez si vous êtes connecté sans changer de fenêtre.”
Contexte de connexion d'un coup d'œil, sans ramener l'app au premier plan.
Icône dans la barre de menu reflétant l'état de connexion et le profil actif.
“Découvrez ce dont vous avez besoin, quand vous en avez besoin.”
Apprenez à connaître les fonctionnalités au moment où elles sont pertinentes.
Des conseils contextuels dans tous les outils — Quick Open, le constructeur de WHERE, l’import de données, Visual EXPLAIN et l’arbre de schéma, entre autres —, un par outil et par visite, dans l’ordre, pour qu’ils ne s’empilent jamais.
“Le SQL que vous écrivez sur le Mac vous attend sur l'iPad — même Mac éteint.”
Sur iPad avec un Magic Keyboard, travaillez comme vous le feriez sur le Mac.
La synchronisation iCloud optionnelle transporte vos connexions, le contenu de l'éditeur et vos préférences d'un appareil à l'autre — sans proximité ni Bluetooth. Gestion native du pointeur et du clavier sur iPad. Gestes : pincer pour dimensionner la police dans l'éditeur et dans la grille de résultats, pincer pour agrandir l'image d'une cellule, swipe sur les lignes de résultats, appui long pour les menus contextuels, pan et zoom dans les diagrammes ER et Visual EXPLAIN, séparateurs de panneaux déplaçables. Split View.
“Des captures prêtes pour la doc — pas amateur.”
Prenez des captures prêtes pour la documentation avec un rendu cohérent.
Cmd+Opt+P sur macOS produit des PNG stylisés pour la documentation et le marketing.
“Les nouveautés, dans l'app — pas dans un changelog.”
Apprenez ce qui est nouveau sans lire les notes de version de l'App Store.
Points forts par version, avec un état local « déjà vu ».
“Calíope parle votre langue — espagnol, anglais, français, allemand ou italien.”
Une app conçue d'abord en espagnol, elle ne donne donc pas l'impression d'une traduction automatique.
Bundles de ressources complets en, es, fr, de et it. La langue est celle que vous choisissez pour Calíope dans les réglages du système, app par app, et les widgets la suivent. Fallback vers l'anglais.
“Sandbox activé — fait ce qu'il déclare, et rien de plus.”
Calíope ne peut pas accéder à quoi que ce soit en dehors des entitlements déclarés. Le système l'applique.
App sandbox activé avec un jeu d'entitlements restreint : client et serveur réseau (pour le proxy SSH), entrée audio (voix vers SQL), fichiers sélectionnés par l'utilisateur (documents), app groups (pour les widgets), impression et iCloud (CloudKit, Cloud Documents et le stockage clé-valeur).
“Un bouton, et il ne reste rien.”
Un bouton pour laisser la machine propre avant de la rendre ou de la vendre.
Suppression à la demande de tout ce que Calíope conserve, aux six endroits énumérés plus bas sous “Tout effacer”.
“Prix honnête — quel assistant demande une clé, dit à l'achat.”
Vous savez exactement ce que l'achat paie et ce qu'il ne paie pas.
Le paywall indique qu'Apple Intelligence et Ollama ne demandent aucune clé et qu'OpenAI, Gemini et Claude demandent la vôtre, que l'achat n'inclut pas, à côté des conditions de l'achat : un seul prélèvement, sans renouvellement, restaurable sur chaque appareil.
“Soixante jours gratuits, sans piège.”
Essayez Calíope pendant soixante jours gratuitement ; si vous la gardez, vous payez une seule fois.
Produit non consommable StoreKit 2 avec 60 jours d'essai gratuit sous forme de non consommable à prix zéro (règle 3.1.1 de l'App Review). Vérification via AppTransaction.shared et Transaction.latest(for:) de StoreKit 2. Restauration via AppStore.sync(). Le prix est toujours affiché depuis product.displayPrice.
“Six endroits, un rapport, aucun échec muet.”
Le bouton d'effacement atteint les fichiers locaux, le Trousseau, le conteneur iCloud Drive, le magasin clé-valeur, CloudKit et les données du widget — et publie une marque pour que vos autres appareils effacent aussi au lieu de tout renvoyer.
Un effacement distant ne consulte pas l'interrupteur de synchronisation : l'interrupteur dit si les choses montent désormais, pas s'il y a déjà quelque chose là-haut, et celui qui l'a activé, envoyé puis désactivé est précisément le cas qu'un effacement de confidentialité ne peut pas laisser de côté. La propagation est asymétrique pour ne pas boucler, et la comparaison est > et non !=, afin qu'une vieille marque republiée par un appareil endormi ne déclenche pas un second effacement. Le rapport comporte une ligne par canal avec son décompte et son échec — la version précédente était écrite avec des try? muets et finissait toujours par « toutes vos données ont été supprimées avec succès », une phrase qui ne pouvait pas être fausse, même avec CloudKit hors service.
Toutes les capacités de cette page sont incluses dans l'achat unique. Soixante jours gratuits, puis un achat unique et c'est à vous pour toujours.