Présentation

nanoMuse est un agent personnel basé sur l'intelligence artificielle, publié sous licence GPL‑3.0‑or‑later. La version la plus récente, 0.1.40, propose des binaires pour Android 8.0+ (arm64), iOS/iPadOS via TestFlight, macOS 12+ (Apple Silicon et Intel), Windows 10+ et Linux x64 (AppImage, .deb, tar.gz). Tous les fichiers d’installation sont signés avec la même clé, ce qui permet des mises à jour incrémentales sans re‑signature.

L’application se présente comme un « visage » numérique capable d’exécuter des actions concrètes – lancer un shell Linux, piloter un navigateur ou interagir avec l’interface graphique d’un appareil – plutôt que de se limiter à répondre à des questions.

Architecture et déploiement

Le projet regroupe quatre composants dans un même dépôt : l’application mobile, l’application de bureau, une console web et un relais serveur qui assure la synchronisation des comptes. Le relais peut être utilisé via l’infrastructure communautaire, où le développeur finance un quota d’appels modèle, ou auto‑hébergé pour garantir que les données ne quittent jamais le réseau local.

Le mode auto‑hébergement s’appuie sur Docker. Un script d’installation localise le relais :

bash scripts/self-host.sh --local

et le compose démarre le service web :

docker compose up -d app

Cette approche minimise les dépendances externes : le conteneur expose uniquement les ports nécessaires à la communication entre les clients et le serveur, et le code source reste entièrement accessible pour un audit de sécurité.

Fonctionnalités et limites

nanoMuse exécute des « skills » définies dans le répertoire AGENTS.md. Chaque skill peut appeler des API internes, lancer des scripts shell ou manipuler l’interface utilisateur via la capture d’écran. Avant toute opération irréversible (suppression de fichiers, envoi d’e‑mail, paiement), l’agent demande une confirmation explicite, ce qui réduit le risque d’exécution accidentelle.

Le modèle de langage utilisé est fourni par le relais communautaire ; lorsqu le quota est épuisé, l’utilisateur doit fournir sa propre clé d’API. Cette dépendance externe introduit une latence variable selon la charge du serveur distant et la qualité du réseau. De plus, le modèle n’est pas entraîné spécifiquement sur les actions système, ce qui peut entraîner des réponses imprécises dans des contextes très techniques.

Sur le plan de la confidentialité, le stockage des conversations se fait sur le serveur du relais. En mode auto‑hébergé, les données restent sous le contrôle de l’utilisateur, mais la configuration nécessite une gestion des certificats TLS et des sauvegardes régulières. L’absence de notarisation pour les builds Windows et macOS Intel peut compliquer le déploiement dans des environnements d’entreprise où les politiques de sécurité interdisent les exécutables non signés.