Enchanted : un client Ollama natif pour l'écosystème Apple

Le problème : discuter avec un modèle local depuis un iPhone

Ollama expose une API HTTP locale, généralement sur le port 11434. Cela suffit pour un script ou un terminal, pas pour une conversation confortable sur mobile. Enchanted comble cet écart : c'est un client natif qui se connecte à un point de terminaison Ollama que vous contrôlez, et qui reprend les codes d'interface d'une application de chat classique. Le README le formule ainsi : il s'agit essentiellement d'une interface de type ChatGPT reliée à vos modèles privés. Le public visé est donc précis. Des développeurs et utilisateurs avancés qui ont déjà des modèles téléchargés via Ollama, qui veulent y accéder depuis un Mac, un iPhone ou un Vision Pro, et qui préfèrent garder l'historique des conversations sur leur appareil plutôt que sur un serveur distant. Le README indique que l'historique est stocké localement et que toutes les fonctionnalités marchent hors ligne, ce qui n'est cohérent que si le serveur Ollama est lui-même joignable sur le réseau local.

Une application native, pas un relais vers le cloud

Le dépôt est en Swift et couvre macOS, iOS et visionOS. L'application ne fait pas d'inférence : elle envoie des requêtes au serveur Ollama et affiche les réponses. Le README précise que l'historique de conversation est inclus dans les appels API, ce qui signifie que le contexte envoyé au modèle grandit à chaque échange. C'est une décision de conception qui a un coût direct : plus la conversation est longue, plus la requête est lourde, et c'est le serveur Ollama qui absorbe cette charge. Sur un Mac récent, cela reste gérable. Sur un serveur modeste, une longue session peut saturer la mémoire disponible. Le README ne donne aucune indication sur une éventuelle troncature du contexte. À vérifier dans le code si ce point vous concerne. Les fonctionnalités listées dans le README incluent la synthèse vocale (Read Aloud), les invites vocales, les pièces jointes d'images, le rendu Markdown avec tableaux et blocs de code, ainsi qu'un panneau Spotlight sur macOS accessible par Ctrl+Cmd+K. L'édition d'un message pour le renvoyer à un modèle différent est également mentionnée, ce qui suppose que le changement de modèle se fait au niveau du message et non seulement au niveau de la conversation.

Mise en route : deux scénarios, une seule clé de configuration

Le README décrit deux cas. Si votre serveur Ollama est déjà accessible publiquement, il suffit d'installer l'application depuis l'App Store et de renseigner le point de terminaison du serveur dans les réglages. Si Ollama tourne sur votre machine locale, le README recommande ngrok pour exposer le port. La commande donnée est : ngrok http 11434 --host-header="localhost:11434". ngrok renvoie une URL de transfert du type https://b377-82-132-216-51.ngrok-free.app, que vous collez dans les réglages de l'application. La prérequis de version est explicite : Ollama v0.1.14 ou ultérieur. Ce point mérite attention, car une version antérieure peut produire des erreurs difficiles à diagnostiquer si l'on ne consulte pas cette ligne du README. La configuration tient donc en une seule valeur : l'URL du serveur. Il n'y a pas de fichier de configuration à éditer, pas de variable d'environnement à définir côté application. C'est simple, mais cela signifie aussi que toute la sécurité repose sur l'URL elle-même.

Le tunnel ngrok comme point de fragilité

Le scénario local repose entièrement sur ngrok. L'URL de transfert est temporaire : elle change à chaque redémarrage du tunnel, sauf configuration payante. Il faut donc la recopier dans les réglages de l'application à chaque fois. Pour un usage quotidien sur iPhone, c'est une friction réelle que le README ne cherche pas à masquer. Plus important : exposer un serveur Ollama sur Internet, même via un tunnel, signifie que toute personne qui obtient l'URL peut envoyer des requêtes à votre serveur et consommer vos ressources. Le README ne mentionne aucun mécanisme d'authentification côté Enchanted. Si vous utilisez ce scénario, la question de la protection du tunnel se pose indépendamment de l'application. C'est une limite de conception, pas un bug : l'outil suppose que vous savez ce que vous exposez.

Jaz, la suite annoncée, et ce que cela implique

La première ligne du README est sans ambiguïté : Jaz est la nouvelle itération de ce projet. Cela ne signifie pas que le dépôt est abandonné (il n'est pas archivé, et une release v1.8.2 datée de juin 2026 est listée), mais cela change la lecture du projet. Entre v1.7.0 en mai 2024 et v1.8.2 en juin 2026, l'écart est de deux ans. Le rythme de publication est donc irrégulier. Un lecteur qui cherche une base de code à maintenir sur plusieurs années doit peser ce fait : la trajectoire annoncée pointe ailleurs. Cela ne disqualifie pas Enchanted pour un usage immédiat, mais cela doit entrer dans la décision si vous prévoyez de contribuer ou de dépendre de l'application à long terme. Le README ne détaille pas ce que Jaz apporte ni si Enchanted continuera de recevoir des correctifs. C'est une information manquante, et elle est importante.

Licence Apache-2.0 et coût de maintenance

Le dépôt est sous Apache-2.0. Cette licence permet l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le fichier de licence, et d'indiquer les modifications apportées. Elle inclut une clause de brevet explicite. Pour une application distribuée sur l'App Store, cela ne pose pas de problème particulier en soi, mais toute redistribution modifiée doit respecter ces obligations. Ce paragraphe n'est pas un avis juridique. Le coût de maintenance, lui, dépend de votre usage. Si vous consommez l'application depuis l'App Store, vous dépendez des mises à jour de l'auteur et de la compatibilité avec les versions successives d'Ollama. Si vous compilez vous-même, il faut suivre les évolutions de Swift et des API Apple, ce que le dépôt ne documente pas dans le README fourni. Il n'existe pas de fichier de configuration à maintenir, ce qui réduit la surface. En revanche, la dépendance à Ollama v0.1.14 ou ultérieur signifie qu'une montée de version majeure d'Ollama pourrait casser la compatibilité sans que rien ne le signale côté application.

Alternatives : l'interface web d'Ollama et les clients génériques

Ollama fournit sa propre interface en ligne de commande et, selon sa documentation, une interface web accessible localement. La différence d'approche est nette : l'interface d'Ollama est liée à la machine qui exécute le serveur, tandis qu'Enchanted est un client déporté qui se connecte à distance. Si vous travaillez uniquement sur la machine qui fait tourner Ollama, l'interface native suffit et Enchanted n'apporte rien. Si vous voulez discuter depuis un iPhone ou un Vision Pro, l'interface locale ne vous sert à rien. Un autre type d'alternative existe : les clients HTTP génériques capables d'appeler une API compatible OpenAI, qu'Ollama expose également selon sa documentation. Ces clients ne sont pas conçus pour Ollama, mais ils fonctionnent. La différence se joue sur les détails : le rendu Markdown, la synthèse vocale, le panneau Spotlight macOS et l'intégration visionOS sont propres à Enchanted. Si ces éléments ne vous importent pas, un client générique peut suffire et vous évite de dépendre d'un projet dont la suite est déjà annoncée ailleurs.

Conclusion éditoriale

Enchanted convient à qui fait déjà tourner Ollama et veut une interface Apple soignée sans exposer ses conversations à un service tiers. Ce n'est pas le bon outil si vous n'avez pas de serveur Ollama joignable depuis vos appareils, ni si vous refusez de dépendre d'un tunnel ngrok pour l'accès distant. Avant d'adopter, vérifiez deux choses dans le dépôt : l'état de la branche main par rapport à la dernière release, et le contenu du README qui oriente vers Jaz.

Sources officielles

1. gluonfield/enchanted on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases