Cette page décrit Calíope 1.5, la version que nous construisons en ce moment. La 1.4 est terminée et en cours d'examen par Apple, et la boutique propose aujourd'hui la 1.3 sur le Mac et la 1.2 sur iPad. 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.
Ce qui a échoué dans Calíope, quand et sur quel appareil.
Où le trouver : Espace de travail › Outils › Erreurs
Le Journal des erreurs enregistre une ligne par échec de l’application, avec son horodatage en temps universel, l’appareil concerné, la zone touchée et le profil de connexion impliqué, le cas échéant.
Ce n’est pas le journal des requêtes. Celui-ci enregistre la réponse du serveur à une instruction — une ERROR 1064 de syntaxe, par exemple —, ce qui est le résultat normal de l’écriture de SQL. Celui-là enregistre ce qui arrive à l’app : une connexion qui ne s’établit pas, un tunnel qui tombe, une sauvegarde impossible à écrire.
Il fonctionne hors connexion, et c’est voulu : le journal est local et il faut pouvoir le lire précisément quand la connexion échoue, c’est-à-dire quand il est le plus utile.
Ce qui n’est jamais enregistré : aucun mot de passe, même tronqué. Un échec d’authentification enregistre qu’il a échoué et sur quel profil, jamais avec quel identifiant. Le serveur est identifié par l’alias du profil, pas par hôte, port et utilisateur.
Une panne qui se répète toute seule ne remplit pas le journal. Le moniteur de santé interroge chaque serveur toutes les quelques secondes : un serveur éteint laisserait des milliers de lignes identiques en une nuit. Elle est consignée la première fois, puis de nouveau si le problème change, si le serveur se rétablit et retombe en panne, ou s'il en est toujours au même point six heures plus tard. Voir une seule ligne ne signifie pas que cela n'est arrivé qu'une fois.
Double-cliquez sur une ligne (ou touchez-la sur iPad) pour ouvrir le détail complet, avec le texte technique utile au support et un bouton pour le copier. Si l’erreur a sa propre explication, le bouton Voir la solution s’y trouve.
Mots-clés : erreurs, journal, diagnostic, échecs, support
Fonctionnement de la synchronisation et ce qui quitte l’appareil.
Où le trouver : Calíope › Préférences › Général
Le journal peut être répliqué dans votre iCloud privé, de sorte que ce qui a échoué sur l’iPad apparaisse aussi sur le Mac. Chaque ligne conserve l’appareil concerné : un journal fusionné où l’on ignore qui a écrit chaque ligne ne sert à rien pour le diagnostic.
L’interrupteur est désactivé au départ, ce n’est pas un oubli. Un journal local est votre fichier sur votre machine ; le téléverser fait sortir de l’appareil les alias de vos profils et le détail technique de chaque échec. Cela se demande, cela ne se présume pas. Il se trouve dans Préférences › Général, séparé de l’interrupteur qui active le journal : l’un décide si l’on enregistre, l’autre si cela sort d’ici.
Pourquoi il ne voyage pas avec les autres préférences. Les préférences transitent par un petit stockage iCloud plafonné à un mégaoctet partagé par tout ; une fois plein, tout cesse de se synchroniser, pas seulement ce qui l’a rempli. Un journal d’erreurs grossit avec l’usage : il passe donc par un autre canal — CloudKit, enregistrement par enregistrement —, ce qui permet en outre au Mac, à l’iPad et à l’iPhone d’écrire en même temps sans s’écraser.
Conservation. 90 jours par défaut, réglable dans les Préférences. L’élagage s’applique au fichier local et à iCloud : vider le journal ne laisse donc pas une copie en ligne qui redescendrait à la synchronisation suivante.
Le serveur n’a pas répondu : que vérifier, et dans quel ordre.
S'applique à :MySQLMariaDBAurora
Cette erreur signifie que la tentative de connexion n’a jamais dialogué avec un serveur : soit rien n’écoute sur cet hôte et ce port, soit quelque chose l’empêche en chemin.
Dans l’ordre, du plus probable au moins probable :
1. L’hôte et le port du profil. Le port par défaut est 3306 ; un serveur en conteneur en publie généralement un autre.
2. Le serveur est démarré. Vérifiez depuis la machine où il tourne, si vous y avez accès.
3. Le tunnel SSH, si vous en utilisez un. Un échec de tunnel se présente très souvent comme « connexion impossible » : cherchez une erreur SSH dans le journal, juste avant celle-ci.
4. Un pare-feu ou le réseau. Un VPN tombé, un réseau d’entreprise qui filtre le 3306 ou une règle de groupe de sécurité cloud donnent la même erreur.
5. L’interface d’écoute du serveur. Un serveur qui n’écoute que sur 127.0.0.1 est inaccessible depuis une autre machine même s’il tourne ; la réponse est alors un tunnel SSH, pas l’ouverture du port.
La connexion a abouti, mais les identifiants ne sont pas valides d’ici.
S'applique à :MySQLMariaDBAurora
Cette erreur est une demi-bonne nouvelle : le réseau fonctionne et le serveur est vivant. C’est l’identité qui échoue.
Trois causes, corrigées différemment :
- Le mot de passe ou le nom d’utilisateur ne correspond pas. Vérifiez-les dans le gestionnaire de connexions. Attention aux espaces au début ou à la fin lors d’un collage.
- Le compte existe, mais pas depuis cette machine. Sous MySQL et MariaDB, un compte est le couple utilisateur + hôte d’origine : dba@localhost et dba@% sont deux comptes distincts avec des mots de passe distincts. Via un tunnel SSH, le serveur vous voit arriver de localhost ; sans tunnel, de votre IP. C’est la cause la plus fréquente du « ça marche d’un endroit et pas de l’autre ».
- Le compte n’a pas de droits sur cette base précise. Si le message nomme une base, l’utilisateur est entré mais ne peut pas l’utiliser ; il manque un GRANT dessus.
L’Administration des utilisateurs montre, pour chaque compte, depuis quels hôtes il peut se connecter et quels privilèges il détient.
Mots-clés : accès, refusé, identifiants, mot de passe, privilèges, 1045
Elle a été supprimée, renommée, ou votre compte ne peut pas la voir.
S'applique à :MySQLMariaDBAurora
Calíope mémorise la dernière base utilisée dans chaque profil : cette erreur apparaît donc souvent lors d’une reconnexion à un serveur qui a changé.
Que regarder :
- La casse. Sous Linux, les noms de bases sont sensibles à la casse par défaut ; sous macOS et Windows, non. Une base créée sur un portable puis cherchée sur un serveur Linux peut disparaître pour cette seule raison.
- Les privilèges. Un compte sans droits sur une base ne la voit pas dans la liste : « n’existe pas » et « vous ne pouvez pas la voir » se ressemblent beaucoup d’ici. Si un autre utilisateur la voit, c’est cela.
- Le mauvais serveur. Avec plusieurs profils semblables, il est facile de regarder la production en croyant être sur la préproduction.
Actualisez l’arbre du schéma pour voir la liste réellement renvoyée par le serveur.
Mots-clés : base de données, inconnue, schéma, privilèges, 1049
Elle s’est coupée en pleine opération : pourquoi, et ce qui reste inachevé.
S'applique à :MySQLMariaDBAurora
La connexion était établie puis est tombée. L’important n’est pas de se reconnecter — c’est facile — mais de savoir ce qui est resté à moitié fait.
Si une instruction d’écriture s’exécutait hors transaction explicite, elle a pu être appliquée entièrement, partiellement ou pas du tout, selon l’endroit de la coupure. Le journal des requêtes indique laquelle est partie en dernier ; vérifiez-la sur le serveur avant de la rejouer.
Causes habituelles :
- Délai d’attente du serveur. Une connexion inactive plus longtemps que wait_timeout (8 heures par défaut, souvent abaissé à quelques minutes) se ferme d’elle-même. Cela se manifeste par « ça a coupé juste quand je suis revenu ».
- Une requête plus longue qu’autorisé. C’est alors net_read_timeout, ou une limite d’un proxy intermédiaire, qui expire.
- Un paquet trop gros. Un INSERT dépassant max_allowed_packet ferme la connexion au lieu de renvoyer une erreur lisible.
- Le réseau. Changer de wifi, mettre la machine en veille ou un VPN qui se reconnecte coupent la connexion sans prévenir.
Échec d’authentification SSH : clé, mot de passe et le cas du second appareil.
Le tunnel a atteint le serveur SSH mais n’a pas pu s’identifier. La base de données n’a même pas encore été tentée.
Le cas le plus déroutant : vous venez de configurer votre autre appareil. Les profils se synchronisent via iCloud, mais pas l’autorisation de lire votre fichier de clé privée, et ce n’est pas un oubli : cette autorisation est une référence au système de fichiers d’une machine et ne signifie rien sur une autre. Sur le nouvel appareil, il faut resélectionner le fichier de clé dans le profil. C’est la cause numéro un du « le même profil marche sur le Mac et pas sur l’iPad ».
Le reste, dans l’ordre :
- L’utilisateur SSH n’est pas l’utilisateur de la base. Ce sont deux identités distinctes, souvent avec des noms différents.
- La clé publique n’est pas sur le serveur. Elle doit figurer dans le ~/.ssh/authorized_keys de cet utilisateur, sur cette machine.
- Les permissions du fichier sur le serveur. Un authorized_keys lisible par d’autres est ignoré silencieusement par le serveur, sans explication.
- La phrase secrète de la clé. Si la clé est protégée, il faut la saisir ; une clé protégée sans sa phrase se comporte comme une mauvaise clé.
Quand c’est normal, quand ça ne l’est pas, et comment vérifier avant d’accepter.
À la première connexion à un serveur SSH, Calíope enregistre l’empreinte de sa clé. Si, lors d’une connexion ultérieure, le serveur en présente une autre, il s’arrête et vous avertit.
Cet avertissement n’est pas une formalité. Un changement de clé est exactement ce que l’on observe lorsqu’un tiers s’interpose entre votre machine et le serveur : accepter la nouvelle clé reviendrait à lui livrer vos identifiants sans le savoir.
Quand le changement est légitime :
- Le système du serveur a été réinstallé.
- La machine virtuelle ou le conteneur a été recréé.
- Le nom ou l’IP a été réattribué à une autre machine (fréquent dans le cloud).
Comment vérifier correctement : demandez l’empreinte à l’administrateur de la machine par un canal distinct de la connexion elle-même — un message, un appel — et comparez-la avec celle affichée. Si elle correspond, acceptez. Si vous ne pouvez pas vérifier, n’acceptez pas.
Mots-clés : ssh, clé d’hôte, empreinte, sécurité, homme du milieu
Formats pris en charge et pourquoi le fichier devient illisible tout seul.
Calíope embarque sa propre implémentation SSH et n’utilise pas le ssh du système : il prend donc en charge un jeu précis de formats — clés ed25519 et ECDSA au format OpenSSH.
Si le fichier existe mais ne se lit pas :
- L’autorisation a peut-être expiré. Calíope n’accède qu’aux fichiers que vous choisissez vous-même dans une boîte de dialogue, et cette autorisation est enregistrée comme une référence qui cesse parfois d’être valide : si vous déplacez le fichier, renommez le dossier ou restaurez la machine depuis une sauvegarde, il faut le resélectionner.
- C’est peut-être une ancienne clé RSA. Convertissez-la en ed25519, plus rapide et plus courte.
- Vous avez peut-être choisi la clé publique. Le bon fichier est celui qui ne se termine pas par .pub.
- Elle est peut-être protégée par une phrase secrète. Il faut alors la saisir à la connexion ; sans elle, la clé ne peut être déchiffrée et le résultat est indiscernable d’un fichier illisible.
Il tombe toutes les quelques minutes : presque toujours le serveur qui ferme les sessions inactives.
Le tunnel était ouvert, puis ne l’était plus. Reconnecter le profil suffit, mais si cela arrive souvent, une cause précise peut être supprimée.
La plus fréquente : le serveur SSH lui-même qui ferme les sessions inactives. Beaucoup de sshd ont ClientAliveInterval et ClientAliveCountMax réglés pour déconnecter après quelques minutes sans trafic. Comme une session de travail sur une base comporte de longues plages de lecture sans rien envoyer, le tunnel tombe juste quand vous revenez à l’app.
Autres causes :
- La machine s’est mise en veille. Au réveil, les connexions réseau existantes ne sont plus valides.
- Un changement de réseau. Passer du wifi à l’ethernet, ou d’un wifi à un autre, change l’adresse source et coupe la session.
- Une limite de sessions simultanées sur le serveur, si plusieurs personnes partagent le même utilisateur SSH.
Le panneau Activité affiche le tunnel comme un mode actif tant qu’il vit : on voit donc d’un coup d’œil s’il est encore ouvert.
Ce que Calíope attend d’iCloud et ce qui cesse de fonctionner sans lui.
Calíope utilise iCloud pour transporter vos profils, vos préférences et — si vous l’activez — vos journaux d’un appareil à l’autre. Sans compte actif, tout cela reste local.
Que vérifier :
1. Que vous êtes connecté à iCloud dans les Réglages du système.
2. Que iCloud Drive est activé, pas seulement le compte.
3. Que Calíope figure dans la liste des apps autorisées à utiliser iCloud Drive. C’est facile à manquer : le compte peut être en règle et l’app décochée.
Rien n’est perdu entre-temps. Tout reste enregistré sur cet appareil ; ce qui n’a pas lieu, c’est la copie vers l’autre. Dès le retour d’iCloud, la synchronisation se met à jour toute seule.
Un échec d’envoi ne perd pas de données ; que faire si cela se répète.
D’abord : rien n’a été perdu. Tout ce que Calíope synchronise possède sa copie sur cet appareil, l’envoi n’étant qu’une copie supplémentaire. Un échec ici signifie que l’autre appareil verra les données plus tard, pas qu’elles ont été supprimées.
Si cela arrive une fois sans se reproduire, c’était presque toujours le réseau. Une nouvelle tentative a lieu automatiquement.
Si cela se répète :
- Vérifiez l’espace de votre compte. Un iCloud plein produit cette erreur en permanence.
- Regardez s’il y a trop d’écritures d’affilée. Calíope regroupe les envois par lots justement pour rester sous la limite de fréquence d’iCloud, mais un premier envoi d’un journal très volumineux peut demander plusieurs tentatives.
- Désactivez puis réactivez la synchronisation concernée. La réactivation renvoie tout depuis le début.
Avant de toucher à quoi que ce soit, faites une copie. Les Préférences proposent un export complet de la configuration ; il existe parce qu’une activation de synchronisation mal menée peut remplacer le fichier de connexions du conteneur par un fichier vide. C’est un incident mesuré, pas une hypothèse.
Ce qui occupe de l’espace dans Calíope et ce que l’on peut réduire sans rien perdre d’important.
Calíope stocke très peu de choses dans iCloud par défaut : vos profils de connexion et vos préférences occupent quelques kilo-octets.
Ce qui grossit avec l’usage, ce sont les journaux, et seulement si vous les activez : le journal des requêtes et le journal des erreurs. Les deux ont une durée de conservation réglable dans les Préférences ; la réduire est le moyen le plus direct de récupérer de l’espace sans rien perdre de ce que vous consultiez.
Que réduire, par ordre d’effet :
1. Les jours de conservation du journal des requêtes. De loin le plus volumineux : il stocke le texte complet de chaque instruction.
2. Les jours du journal des erreurs.
3. L’historique de l’assistant IA, si vous le synchronisez.
Vider l’un des trois depuis son propre outil supprime aussi la copie iCloud : l’espace est réellement récupéré et ne revient pas à la synchronisation suivante.
Rien de tout cela ne concerne vos données de travail : les bases vivent sur leurs serveurs et Calíope ne les copie jamais dans iCloud.
Fonctionnement de l’accès aux fichiers dans une app de l’App Store.
Calíope s’exécute dans un bac à sable, exigence de l’App Store : il ne peut pas ouvrir un fichier par son chemin, uniquement ceux que vous choisissez explicitement dans une boîte de dialogue d’ouverture ou d’enregistrement.
Cela a une conséquence pratique surprenante la première fois : saisir le chemin à la main ne suffit pas. Même si le fichier existe et vous appartient, s’il n’est pas passé par une boîte de dialogue, l’app ne le voit pas.
Comment accorder l’autorisation : ouvrez le fichier ou le dossier avec Ouvrir… ou Enregistrer sous…. Calíope conserve ensuite l’autorisation et peut la réutiliser sans demander.
Quand il faut la redonner :
- Si vous déplacez ou renommez le fichier ou son dossier.
- Si vous restaurez la machine depuis une sauvegarde.
- S’il s’agit d’un autre appareil. Ces autorisations ne se synchronisent volontairement pas : sur une autre machine, elles ne signifient rien.
C’est pour la même raison qu’une clé privée SSH ou un dossier de sauvegardes planifiées doit être resélectionné sur chaque appareil.
Pourquoi un fichier qui fonctionnait cesse de s’ouvrir sans que vous ayez rien fait.
Lorsque vous choisissez un fichier dans une boîte de dialogue, Calíope n’enregistre pas son chemin : il enregistre une autorisation d’accès, une référence émise par le système qui peut expirer. Une fois expirée, l’app ne peut plus ouvrir le fichier même s’il est resté au même endroit.
Ce qui l’invalide :
- Déplacer, renommer ou recréer le fichier.
- Renommer un dossier de son chemin.
- Restaurer la machine depuis une sauvegarde.
- Que le fichier soit sur un volume externe ou réseau démonté.
Et il existe un cas qui n’est pas un défaut mais une règle : ces autorisations ne se synchronisent pas entre appareils, et ce n’est pas une négligence. Une telle autorisation référence le système de fichiers d’une machine précise ; sur une autre elle ne pointe vers rien, et la transporter provoque des échecs sans explication visible — typiquement une authentification SSH qui échoue sans raison apparente.
La solution est toujours la même : resélectionnez le fichier. Vous ne perdez rien d’autre ; il suffit de redonner l’accès.
Ce qu’il intercepte, pourquoi, et comment l’exécuter quand même si vous êtes sûr.
Le mode sécurisé inspecte les instructions avant de les envoyer et arrête celles qui peuvent détruire des données de façon irréversible : DROP, TRUNCATE, ainsi que les DELETE ou UPDATE sans clause WHERE.
Ce n’est pas une restriction de droits. Votre compte peut parfaitement en avoir le droit ; le mode sécurisé vous oblige simplement à confirmer que c’était bien votre intention. Il existe pour l’erreur d’une seconde : le DELETE dont le WHERE est resté dehors parce que vous l’aviez sélectionné à moitié avant d’exécuter.
Pour l’exécuter quand même, désactivez le mode sécurisé dans la barre de l’éditeur SQL et relancez. L’interrupteur est bien visible, pas enfoui dans les préférences, précisément pour que le désactiver soit un acte conscient et momentané.
Conseil d’usage : laissez-le activé sur les profils de production et désactivé sur ceux de développement. Le réglage est par profil, inutile donc d’y penser à chaque fois.
Où la saisir, où elle est stockée et pourquoi elle ne voyage pas avec les réglages.
Où le trouver : Calíope › Préférences › Assistant IA
L’assistant SQL utilise un fournisseur externe et a besoin d’une clé d’API vous appartenant pour lui parler. Elle se saisit dans Préférences › Assistant IA.
Où elle est stockée : dans le trousseau du système, pas dans un fichier de l’app. Ni la sauvegarde de configuration ni la synchronisation ordinaire ne l’emportent par défaut : un secret ne quitte cet appareil que si vous le demandez explicitement et le chiffrez avec un mot de passe choisi à ce moment-là.
Si vous venez de configurer un autre appareil et que l’assistant n’y fonctionne pas, c’est cela : la clé doit être saisie sur chaque appareil, ou la synchronisation du trousseau activée dans les Préférences.
Calíope ne s’interpose pas dans cette relation. La clé est la vôtre, elle va directement à votre fournisseur et la consommation est facturée sur votre compte. C’est pourquoi les limites d’usage et le solde se gèrent dans le tableau de bord du fournisseur, pas ici.
Limites d’utilisation du fournisseur et ce que l’on peut ajuster depuis Calíope.
Le quota n’est pas imposé par Calíope : il vient du fournisseur d’IA que vous avez configuré, selon votre offre et votre solde.
Deux limites distinctes donnant la même erreur :
- La fréquence. Trop de requêtes en peu de temps. Attendre une minute suffit.
- La consommation. Le crédit ou le quota de la période est épuisé. Il faut alors le recharger dans le tableau de bord du fournisseur.
Ce que l’on peut régler ici : dans Préférences › Assistant IA, vous pouvez abaisser le nombre maximal de jetons par réponse — le principal poste de consommation — et passer à un modèle moins coûteux. Une longue conversation coûte aussi davantage, car l’historique accompagne chaque requête : démarrer une nouvelle conversation réduit le coût des suivantes.
Le reste du programme fonctionne à l’identique. L’assistant n’est qu’un outil parmi d’autres ; rien de ce que vous faites avec l’éditeur SQL, les sauvegardes ou les catalogues n’en dépend.
La base reste dans un état intermédiaire : comment savoir où elle s’est arrêtée et que faire.
Où le trouver : Espace de travail › Outils › Sauvegarde
S'applique à :MySQLMariaDBAurora
Une restauration applique le fichier instruction par instruction. Si elle s’arrête, ce qui a été appliqué jusque-là l’est bel et bien : la base ne revient pas d’elle-même à son état antérieur.
D’abord : ne la considérez pas comme valide. Une base à moitié restaurée comporte des tables complètes, des tables vides et des tables absentes ; au premier regard, elle peut sembler fonctionner.
Où regarder : le détail technique de l’erreur indique l’instruction où cela s’est arrêté. C’est généralement l’une de ces trois causes :
- Une table qui existait déjà. Restaurer sur une base non vide bute sur le premier CREATE TABLE répété.
- Un DEFINER inexistant sur ce serveur. Vues, routines et déclencheurs portent l’utilisateur qui les a créés ; si ce compte n’existe pas ici, ils échouent. Calíope retire cette clause dans ses propres sauvegardes, mais un fichier produit par un autre outil peut la contenir.
- Une limite de taille d’instruction. Une sauvegarde prise sur un serveur au max_allowed_packet élevé produit des instructions qu’un serveur à la valeur par défaut refuse.
Comment s’en sortir : le plus propre est de supprimer la base et de restaurer depuis zéro sur une base vide. Reprendre en cours de route suppose de savoir exactement ce qui a été appliqué, et le fichier ne porte pas cette information.
Mots-clés : restaurer, sauvegarde, definer, max_allowed_packet, à moitié