Odysseus AI est-il privé avec un modèle local ? Données et réseau

Odysseus AI est-il privé ? Quatre frontières à distinguer

L’auto-hébergement change l’entité qui exploite l’espace de travail, mais ne retire pas tous les autres acteurs d’un processus. Il est utile de distinguer quatre limites : la machine ou le serveur qui stocke l’espace, le modèle qui reçoit un prompt, les services externes contactés par une fonction et les utilisateurs du réseau qui peuvent atteindre l’application. Chacune répond à une question de confidentialité différente.

Un modèle local peut éviter d’envoyer le prompt à un fournisseur hébergé, mais la recherche peut contacter SearXNG et des moteurs externes, et le calendrier son serveur configuré. Un proxy ou un port public change aussi les personnes qui peuvent accéder à l’espace. Vérifiez chaque destination plutôt que de traiter l’auto-hébergement comme un réglage unique.

Ce qui reste local avec un modèle local

La page officielle de sécurité d’Odysseus AI indique qu’un modèle local exécuté par des backends tels qu’Ollama, llama.cpp ou vLLM, les prompts et les réponses restent sur votre matériel. Elle précise également que les conversations, documents, souvenirs et caches de courrier résident dans le dossier `data/` de l’application. C’est la base la plus claire pour dire que l’inférence locale peut éviter d’envoyer prompts et réponses à un fournisseur distant.

La portée compte : un modèle local décrit l’inférence, pas toutes les fonctions. Recherche Web, appel cloud ponctuel et synchronisation possèdent leurs destinations propres. Système, sauvegardes, disque, navigateur et administrateurs restent dans la frontière de confiance ; les données conservées en local nécessitent des accès contrôlés.

La page officielle indique aussi que le projet ne contient ni télémétrie ni analytique automatique. C’est une déclaration, pas une mesure indépendante des fournisseurs, des journaux de l’hôte ou des déploiements modifiés.

Où les fonctions connectées envoient les données

Odysseus AI est-il privé lorsque des intégrations sont activées ? Cela dépend de l’action. La documentation indique que les fournisseurs cloud reçoivent les prompts qui leur sont envoyés, que la recherche Web fait passer les requêtes par SearXNG vers les moteurs en amont et que la synchronisation du courrier ou de CalDAV communique avec le serveur configuré. Ce sont des routes de données prévues, pas la preuve que chaque demande est copiée vers chaque service.

Avant une tâche sensible, identifiez l’endpoint, la recherche, le compte connecté et tout effet externe d’un outil. L’image est conceptuelle : vérifiez la fonction et la configuration réelles au lieu d’en déduire le comportement à partir du dessin. Même quand l’inférence tourne en local, chaque service connecté garde sa propre destination et ses règles de traitement.

Pourquoi l’exposition réseau est un autre risque

Un modèle local ne détermine pas qui peut ouvrir l’espace de travail. La page officielle indique que Docker lie par défaut l’application, ChromaDB, SearXNG et ntfy à `127.0.0.1`. Elle précise que `APP_BIND=0.0.0.0` est destiné à une configuration LAN ou proxy inverse volontaire et doit être associé aux origines autorisées correspondantes. Une adresse d’écoute change l’accessibilité réseau ; elle ne rend pas à elle seule un service exposé sûr.

Le modèle de menace du projet décrit Odysseus comme conçu pour des utilisateurs de confiance sur un réseau privé et recommande de le traiter comme une console d’administration. Il déconseille un service public sans authentification. Gardez les ports internes privés, évitez le transfert direct vers Internet et utilisez une couche d’accès privée, comme Tailscale, Cloudflare Access ou WireGuard, pour un accès distant adapté à votre environnement.

Hors localhost, examinez proxy, HTTPS, origines autorisées, authentification et pare-feu ensemble. Identifiez le service touché : élargir les ports peut exposer une base de données ou la recherche avec l’application.

Comptes, accès administrateur et outils

Les sources officielles décrivent des rôles multi-utilisateurs, une authentification à deux facteurs TOTP, des mots de passe hachés, des contrôles de session et une restriction aux administrateurs pour les outils privilégiés. Elles recommandent de garder l’authentification active et le contournement localhost désactivé hors développement local. Ces contrôles peuvent réduire les accès non autorisés, mais n’empêchent pas un administrateur d’utiliser les capacités puissantes attribuées à son compte.

Cette limite est explicite dans le modèle de menace : un administrateur connecté peut exécuter des commandes shell, lire et écrire des fichiers, envoyer des courriels et contrôler le service de modèles. Le document vise l’accès sans authentification, le respect des privilèges, l’injection par du contenu non fiable et l’accessibilité extérieure des services internes. Il ne cherche pas à empêcher un administrateur d’exercer ses pouvoirs.

Le modèle décrit l’approbation des outils et la protection des prompts face au contenu externe. Ce sont des défenses, pas la preuve qu’une attaque est impossible. Utilisez un compte non administrateur, limitez les administrateurs et remplacez les identifiants divulgués.

Vérification pratique avant un vrai travail

Avant une tâche sensible, notez si l’inférence s’exécute en local et quels comptes ou services la complètent. Faites une courte vérification avant de connecter des comptes personnels ou d’ajouter des informations confidentielles. Le but est de comprendre les routes et de réduire l’exposition inutile, pas de certifier l’installation comme sûre. Commencez par un test sans risque et observez les services qui s’activent.

1. Choisir l’endpoint d’inférence

   Vérifiez si le modèle est local ou hébergé. Pour un modèle local, confirmez que l’adresse pointe vers le service Ollama, llama.cpp ou vLLM que vous contrôlez.

2. Examiner les intégrations

   Listez la recherche, le courrier, le calendrier, les notifications et les modèles distants. Désactivez ce qui est inutile et identifiez la destination de chaque fonction active. Vérifiez si la demande passe par un modèle local ou un fournisseur distant.

3. Limiter les accès

   Gardez l’authentification active, évitez le contournement localhost hors développement et réservez les rôles administrateur aux personnes qui en ont besoin. Un modèle local ne remplace ni une connexion sécurisée ni des rôles adaptés.

4. Vérifier les ports et le proxy

   Distinguez les services en loopback de ceux du LAN. Gardez les ports internes privés et protégez l’accès distant par une couche adaptée. Gardez aussi privé le port du backend de modèle local.

5. Protéger les données locales

   Limitez l’accès à `data/`, repérez l’emplacement des sauvegardes et protégez les archives aussi soigneusement que le serveur actif. Un modèle local ne protège pas les sauvegardes copiées ailleurs.

6. Tester avec des données anodines

   Effectuez un prompt inoffensif, observez sa destination et vérifiez l’authentification et les approbations avant un vrai travail. Comparez un modèle local et un endpoint distant avec la même requête neutre.

Odysseus AI est-il privé selon l’usage ?

Une même installation change selon la tâche. Résumer un fichier local avec un modèle local ouvre moins de routes qu’un prompt cloud, mais l’accès au compte et à l’hôte compte toujours. La recherche ajoute des moteurs ; le courrier ajoute un serveur et des autorisations d’action.

Une équipe doit définir quelles données peuvent être traitées par un modèle local, lesquelles peuvent aller à un fournisseur approuvé et quelles intégrations exigent une autorisation. Consignez les choix et revérifiez-les après un changement d’endpoint ou de proxy.

Ce que cet examen ne prouve pas

Cet article résume les sources officielles vérifiées le 23 octobre 2026 ; ce n’est ni un test d’intrusion, ni un audit, ni une évaluation juridique, ni une garantie fournisseur. Les affirmations sur la télémétrie et l’inférence locale sont celles du projet et ne sont pas vérifiées indépendamment ici. Le comportement dépend aussi du commit et de la configuration : consultez les sources actuelles et votre déploiement.