Vous n'avez pas à nous croire sur parole.

Vérifiez par vous-même

Voici, une par une, les affirmations de nos pages sur la souveraineté. Les tests sont livrés avec le logiciel du hub, et la plupart des commandes ci-dessous s'exécutent sur le hub lui-même, dans le dossier où Elysium est installé : /opt/elysium sur un hub livré prêt à l'emploi. Ces commandes nécessitent un shell sur le hub. Un hub livré prêt à l'emploi a l'ouverture de session à distance désactivée et aucun mot de passe de console connu : l'accès au shell doit donc être configuré lors de sa mise en service.

Votre hub a aussi sa propre page de confiance, à l'adresse hub.local/trust sur votre réseau domestique, sauf si vous lui avez donné un autre nom. Elle explique comment faire confiance au certificat du hub et ce que révèle l'accès à distance, et tant que le raisonnement du hub se fait dans le cloud, elle liste ce qui sort de la maison.

1. Dès sa mise en service, il fonctionne en mode Sovereign.

   Comment ça marche

   Un hub est livré configuré pour que la connexion des membres du foyer se fasse sur le hub, sans clé Anthropic ni OpenAI, et avec chaque modèle sur le hub, y compris celui qui extrait les souvenirs des conversations. Tel qu'il est livré, il refuse un passage en mode Hybrid depuis le tableau de bord : ouvrir le mode Hybrid demande de modifier sa configuration.

   Le test

   Les sections 1 et 2 de l'autotest lisent les réglages qu'utilisent les services en marche. Elles échouent si la connexion ne se fait pas sur le hub, si des réglages de connexion cloud sont présents sans que le propriétaire les ait associés à dessein, ou si une clé cloud est définie ou l'extraction des souvenirs n'est pas locale alors que le raisonnement reste sur le hub. Avec --expect-posture sovereign, tout autre mode fait échouer l'exécution.

   Ce qu'il ne voit pas

   Il lit les réglages avec lesquels tournent les services et n'examine pas leur code. Sans l'option, un hub dont le propriétaire a associé à dessein un compte cloud réussit le test, et son rapport nomme ce mode.

   Lancez-le vous-même

   Sur le hub, dans le dossier d'installation :

   ./scripts/sovereign/sovereign-selftest.sh --expect-posture sovereign

2. En mode Sovereign, rien de ce qu'il apprend ne quitte la maison.

   Comment ça marche

   Le raisonnement, la mémoire et la connexion se font sur le hub, et quand le modèle local échoue, la demande se termine par un message d'erreur au lieu de partir vers un service cloud. Six types de contact avec l'extérieur restent désactivés tant que personne au foyer ne les active : la consultation de données publiques comme la météo, la recherche sur le web, un compte e-mail associé, un serveur d'outils, l'accès à distance et le téléchargement d'un autre modèle local. Un type est activé dès la livraison : le contrôleur Matter du hub télécharge au démarrage, puis une fois par jour, les listes publiques de certificats d'appareils et de fabricants de la norme Matter. Quand vous associez un appareil, il contrôle aussi ses certificats auprès du registre public de la norme et, si le fabricant de l'appareil y indique un serveur, auprès de ce serveur ; tous deux peuvent alors savoir qu'un appareil de ce fabricant est ajouté depuis l'adresse internet de votre maison.

   Le test

   La section 3 de l'autotest lit la table des connexions de chaque service que fait tourner le hub et échoue si l'un d'eux maintient une connexion avec une adresse publique. La section 5 échoue si un service écoute sur une adresse publique. La section 6 indique si la consultation de données publiques est activée, nomme le moteur de recherche qu'utiliserait la recherche sur le web et liste les connexions que maintient le système d'exploitation du hub.

   Ce qu'il ne voit pas

   Il voit les connexions ouvertes au moment où il tourne : une connexion qui s'ouvre et se ferme entre deux exécutions lui échappe. Il voit les connexions TCP et les sockets UDP connectés : un paquet UDP envoyé sans connexion ne laisse aucune trace. Il ne liste ni les comptes e-mail associés, ni les serveurs d'outils, ni les téléchargements de modèles, ni les contacts du contrôleur Matter, et ne voit pas les canaux auxiliaires comme le rythme du trafic. Pour une preuve qui ne dépend pas de notre logiciel, observez le trafic du hub sur votre routeur.

   Lancez-le vous-même

   Sur le hub, dans le dossier d'installation :

   ./scripts/sovereign/sovereign-selftest.sh

3. Débranchez le câble internet, et votre maison continue de vous répondre.

   Comment ça marche

   Le modèle, la mémoire, la connexion et le contrôleur Matter propre au hub fonctionnent tous sur le hub, qui atteint vos appareils par votre réseau domestique et Thread.

   Le test

   Câble débranché, lancez l'autotest avec --strict : sa section 4 tente alors de joindre une adresse publique depuis chaque service et échoue si l'un d'eux y parvient. Le reste se vérifie à la main : posez une question à The Butler, connectez-vous depuis un téléphone sur votre réseau domestique et allumez ou éteignez une lampe.

   Ce qu'il ne voit pas

   Il montre qu'aucun service ne peut atteindre internet ; utiliser la maison est votre part de la vérification. Il échoue tant que le raisonnement dans le cloud est activé, ou tant que l'accès à distance est activé et que vous lui avez donné l'adresse du tunnel, car un hub ne peut pas être coupé du réseau et joindre le cloud en même temps. Aujourd'hui, il échoue sur un hub tel qu'il est livré, même câble débranché : il échoue sur tout service qu'il ne peut pas sonder, et le service de base de données n'a aucun des outils qu'utilise sa sonde.

   Lancez-le vous-même

   Débranchez le câble, puis sur le hub, dans le dossier d'installation :

   ./scripts/sovereign/sovereign-selftest.sh --strict

4. La connexion fonctionne hors ligne.

   Comment ça marche

   Les comptes sont stockés sur le hub, qui vérifie lui-même les mots de passe et émet lui-même les jetons de connexion. Un compte cloud n'entre en jeu que si le propriétaire en associe un, et même alors, le mot de passe local reste la voie d'accès principale.

   Le test

   La section 1 de l'autotest échoue si la connexion ne se fait pas sur le hub, quel que soit le mode, et échoue sur des réglages de connexion cloud que le propriétaire n'a pas associés à dessein.

   Ce qu'il ne voit pas

   Il vérifie le réglage avec lequel tourne le service de connexion. La vérification directe consiste à vous connecter câble débranché, et vous seul pouvez la faire sur votre hub.

   Lancez-le vous-même

   Câble débranché, connectez-vous à l'adresse du hub. Pour vérifier le réglage qui est derrière, lancez ceci sur le hub, dans le dossier d'installation :

   ./scripts/sovereign/sovereign-selftest.sh

5. En mode Sovereign, aucun repli vers le cloud.

   Comment ça marche

   En mode Sovereign, le service d'IA du hub ne peut utiliser que les modèles du hub. Quand le modèle local échoue, vous recevez un message d'erreur et la demande ne part nulle part ailleurs.

   Le test

   Un test de bout en bout démarre un hub de test dont le modèle local fait échouer chaque demande, avec une clé cloud déposée dessus, et envoie un message de chat. Il échoue si les journaux montrent un repli, ou si le service d'IA maintient une connexion publique dans l'un de ses relevés, pris toutes les 0,2 seconde. La section 6 de notre rapport décrit une exécution pendant le développement : 15 relevés pris au fil d'une conversation en échec n'ont montré aucune connexion publique.

   Ce qu'il ne voit pas

   Il tourne sur une copie de test du hub, envoie un seul message de chat et ne relève que le service d'IA. Une connexion plus courte que l'intervalle entre deux relevés pourrait passer inaperçue.

   Lancez-le vous-même

   Sur le hub, ou sur tout ordinateur équipé de Docker et d'une copie de son dossier d'installation. Il construit ses propres images, il a donc besoin d'internet, et il utilise ses propres conteneurs et données sans toucher à ceux de votre hub :

   ./scripts/sovereign/sovereign-failclosed-e2e.sh

6. Les mises à jour sont signées et ne s'installent que si vous les lancez.

   Comment ça marche

   Le hub n'installe une version qu'après avoir vérifié sa signature avec la clé publique de son image système, refuse une version qui n'est pas plus récente que celle en service, et vous demande de confirmer avant de modifier quoi que ce soit. Rien sur le hub ne va chercher de version de lui-même : vous en apportez une sur un support amovible, ou vous la téléchargez par votre propre connexion, ce qui ouvre une connexion au serveur de versions le temps du téléchargement. La vérification de la signature échoue si une nouvelle connexion avec l'extérieur apparaît pendant qu'elle tourne, et l'image des hubs livrés prêts à l'emploi désactive les minuteurs de mise à jour propres au système d'exploitation.

   Le test

   Un test de bout en bout signe de vraies versions et vérifie qu'une version altérée, une mauvaise signature et une version plus ancienne sont refusées avant que quoi que ce soit change, qu'une version plus récente est acceptée, et que la vérification d'une version n'ouvre aucune connexion avec l'extérieur. La section 6 de l'autotest indique si le système d'exploitation interroge les dépôts de paquets à intervalles réguliers.

   Ce qu'il ne voit pas

   Chaque mise à jour repose sur notre clé de signature, à laquelle vous faites confiance sans pouvoir la vérifier. La clé qui signera les versions destinées aux propriétaires n'a pas encore été créée ; aujourd'hui, l'image est construite avec une clé de développement. Les mises à jour du système d'exploitation et du pilote graphique sont hors de ce circuit signé, et vous les installez à la main. Si une version installée échoue à son contrôle de santé, le hub revient à la précédente ; ce mécanisme n'a été testé jusqu'ici que sur un environnement de conteneurs simulé.

   Lancez-le vous-même

   Sur le hub, dans le dossier d'installation. L'outil de mise à jour s'exécute en tant que root, c'est pourquoi les deux commandes commencent par sudo. La première vérifie une version sans rien modifier ; la seconde affiche la version installée :

   sudo ./scripts/sovereign/sovereign-update.sh --bundle /media/usb/elysium-release-<version>.tar --dry-run
   sudo ./scripts/sovereign/sovereign-update.sh --status

7. La vidéo et le pilotage des appareils restent sur le hub, en mode Sovereign comme en mode Hybrid.

   Comment ça marche

   Seul un hub exécute les commandes des appareils : sa propre API met chacune en file d'attente, et son contrôleur Matter l'envoie par votre réseau domestique et Thread. En mode Hybrid, un modèle cloud peut choisir une commande, d'après l'état des appareils que nomme la liste Hybrid, et c'est toujours le hub qui l'exécute. La prise en charge des caméras est en développement : aucune partie du produit ne traite encore de vidéo.

   Le test

   En mode Hybrid, la section 3 de l'autotest n'accepte de connexions vers l'extérieur que du service d'IA. Elle échoue toujours si un service qui exécute des commandes d'appareils, ou tout autre service, en maintient une.

   Ce qu'il ne voit pas

   Il n'y a pas encore de code de caméra à tester. Le test voit les connexions et ne peut pas voir ce qui y circule ; en mode Hybrid, il ne peut donc pas dire ce qu'envoie le service d'IA.

   Lancez-le vous-même

   Sur le hub, dans le dossier d'installation :

   ./scripts/sovereign/sovereign-selftest.sh

8. En mode Sovereign, rien de ce qu'il entend ne quitte la maison.

   Comment ça marche

   La détection du mot d'activation, la reconnaissance vocale et la voix parlée fonctionnent sur le hub. La reconnaissance et la synthèse vocales dans le cloud et la détection des relances dans le cloud sont des options du mode Hybrid, et chacune vérifie le mode du hub avant de contacter un service cloud ; aucune n'en joint donc un tant que le hub est en mode Sovereign, même si elle est configurée.

   Le test

   La section 6 de l'autotest lit les réglages vocaux : une option cloud configurée apparaît comme retenue tant que le raisonnement du hub ne se fait pas dans le cloud, et comme activée quand il s'y fait.

   Ce qu'il ne voit pas

   Il signale des réglages et n'échoue sur aucun ; savoir si quelque chose sort revient ensuite à la vérification des connexions de la section 3, avec ses limites. L'interface vocale toujours active est encore en cours d'intégration.

   Lancez-le vous-même

   Sur le hub, dans le dossier d'installation :

   ./scripts/sovereign/sovereign-selftest.sh

9. En mode Hybrid, l'application liste ce qui sort avant que vous changiez de mode.

   Comment ça marche

   Avant qu'un administrateur passe en mode Hybrid dans le tableau de bord, celui-ci affiche la liste du hub de ce que le mode Hybrid envoie, demande le mot de passe local et enregistre le moment où l'administrateur a accepté la liste. Le retour en mode Sovereign s'applique dès la demande suivante. La liste elle-même figure sur Comment ça marche.

   Le test

   La liste est tenue à quatre endroits : le tableau de bord, la page de confiance propre au hub, l'autotest et ce site. Nos tests échouent dès qu'une copie diffère des autres. Sur un hub dont le raisonnement se fait dans le cloud, la section 2b de l'autotest affiche la liste.

   Ce qu'il ne voit pas

   Ces tests gardent les copies identiques et ne surveillent pas le trafic. En mode Hybrid, la section 3 accepte les connexions du service d'IA vers l'extérieur ; elle ne peut donc pas montrer quels éléments de la liste partent.

   Lancez-le vous-même

   Ouvrez la page de confiance propre au hub et, sur un hub en mode Hybrid, lancez ceci dans le dossier d'installation :

   ./scripts/sovereign/sovereign-selftest.sh

Ce que ce site conserve

Ce que le site elysium-labs.ai enregistre lors de votre visite, en bref. Notre politique de confidentialité en est le texte complet, et les chiffres d'ici viennent de la même source que les siens.

Cookies et stockage du navigateur

Les pages ne déposent aucun cookie quand vous les lisez, et aucun cookie ne sert à la mesure d'audience, à la publicité ou au pistage. Vous pouvez le vérifier dans les outils de développement de votre navigateur : les réponses des pages ne contiennent aucun en-tête Set-Cookie. Les cookies n'arrivent qu'avec ce que vous faites. La connexion, ou l'association de Google à votre compte, utilise nos propres cookies (elysium_session, elysium_access, elysium_refresh, elysium_oauth_state et elysium_oauth_link), et tant que vous êtes connecté, le site renouvelle votre session. Quand votre navigateur utilise notre API, par exemple pour vous connecter ou dans Ask Elysium, l'équilibreur de charge placé devant elle dépose AWSALB et AWSALBCORS, qui durent 7 jours. Dans le stockage de votre navigateur, le site conserve quelques éléments pour la langue choisie et pour Ask Elysium (els-lang, els-orb-sound, els-ask-thread-v1:… et els-ask-chat-id). La politique de confidentialité dit à quoi sert chacun.

Serveurs d'autres entreprises

Les pages ne chargent aucun script, aucune police ni aucune image depuis les serveurs d'autres entreprises. Chaque page, hormis la connexion et votre compte, envoie une politique de sécurité du contenu (Content Security Policy) qui ne permet à votre navigateur de charger scripts, styles, polices, images et médias que depuis ce site, et de se connecter qu'à ce site et à notre API. Notre politique de confidentialité dit ce que nos serveurs journalisent.

Réseau de diffusion de contenu

Vos requêtes vers elysium-labs.ai et www.elysium-labs.ai peuvent d'abord atteindre Amazon CloudFront, le réseau de diffusion de contenu d'Amazon Web Services, dans un point de présence proche de vous, qui peut se trouver hors de Suisse. Il envoie une page depuis sa propre copie quand il en a une, et sinon transmet la requête à nos serveurs à Zurich. Il ne garde de copies que des pages et des fichiers identiques pour tous les visiteurs. Nous n'avons pas activé ses journaux d'accès : il ne tient donc aucun journal de vos requêtes pour nous. Pour une requête passée par lui, l'adresse IP inscrite dans le journal de notre équilibreur de charge est celle de CloudFront. La politique de confidentialité donne les détails.

Compter les visites

Chaque page que vous ouvrez, hormis celles de votre compte, envoie à notre API un comptage qui contient quatre éléments : la page, sa langue, le nom d'hôte du site dont le lien vous y a mené, et si votre fenêtre a la taille d'un téléphone, d'une tablette ou d'un ordinateur. L'API l'ajoute à un total journalier qui ne contient ni adresse IP, ni cookie, ni rien qui vous identifie, vous ou votre navigateur. Si votre navigateur envoie Do Not Track ou Global Privacy Control, vos visites ne sont pas comptées. Nous conservons les totaux 13 mois, et le rapport de notre équipe masque chaque total de 1 à 4. Le comptage passe tout de même par notre équilibreur de charge, dont le journal conserve votre adresse IP et l'agent utilisateur de votre navigateur pendant 30 jours ; un jour de faible fréquentation, ce journal et les totaux peuvent être lus ensemble. La politique de confidentialité donne les détails.

Ask Elysium

Si vous n'êtes pas connecté, nous ne gardons aucune copie de votre conversation, et votre navigateur la garde jusqu'à ce que vous fermiez l'onglet ou commenciez une nouvelle discussion. Si vous êtes connecté, nous conservons vos questions et les réponses avec votre compte pendant 180 jours. L'évaluation d'une réponse est conservée 180 jours. Pour prévenir les abus, des compteurs gardent votre adresse IP jusqu'à 24 heures, et la trace d'une discussion mise en pause, avec votre adresse IP, est conservée jusqu'à 7 jours après sa dernière pause. Anthropic rédige les réponses et OpenAI transforme chaque question en vecteur de recherche ; aucun des deux n'utilise votre texte pour entraîner ses modèles, et tous deux peuvent le conserver pendant une durée limitée pour détecter les abus. La politique de confidentialité donne les détails.

Demandes d'accès anticipé

Une demande contient votre adresse e-mail, la page et le formulaire utilisés, la langue de la page, le moment de la demande, la version de notre avis que vous avez vue et la façon dont votre visite a commencé : le nom d'hôte du site qui a renvoyé vers celui-ci et les balises de campagne de la première page ouverte, ni l'un ni l'autre si votre navigateur envoie Do Not Track ou Global Privacy Control. Si vous êtes connecté, elle est liée à votre compte. Nous conservons aussi une empreinte de votre adresse, pour limiter les e-mails qu'elle reçoit, et une trace de chaque e-mail que nous vous envoyons au sujet de la demande. Si vous ne la confirmez pas, nous la supprimons dans les 7 jours qui suivent votre dernière demande ; une demande confirmée reste jusqu'à ce que vous la retiriez, que vous supprimiez votre compte ou que nous fermions la liste. Chaque e-mail que nous envoyons automatiquement à son sujet contient un lien qui la retire. La politique de confidentialité donne les détails.

Journaux et sauvegardes

Notre équilibreur de charge journalise chaque requête qu'il transmet : l'adresse IP d'où elle vient, l'adresse demandée, l'heure, l'agent utilisateur et le résultat. Notre API journalise les requêtes qu'elle reçoit, hormis les comptages de visites. Nous conservons ces journaux 30 jours. Les relevés de connexions réseau, avec les adresses IP et les ports mais sans contenu, sont conservés 14 jours, et les sauvegardes de la base de données 7 jours. La politique de confidentialité donne chaque durée.

Qui reçoit des données, et où

Les entreprises qui reçoivent des données personnelles de ce site, d'Ask Elysium et de l'application Elysium hébergée, où elles se trouvent et ce qu'elles font pour nous. C'est la liste de notre politique de confidentialité, en anglais et lue à la même source, de sorte que les deux concordent toujours. La politique indique aussi la garantie qui s'applique à chacune.

Signaler un problème de sécurité

Écrivez à security@elysium-labs.ai. Notre politique de sécurité indique ce que vous pouvez tester, comment tester de bonne foi et la protection juridique (safe harbor) que nous accordons aux chercheurs. Le même contact est publié sous une forme lisible par machine à l'adresse /.well-known/security.txt.