Propriété, partage d'appareils & API par locataire
Un système qui gère les ordinateurs des clients doit répondre à deux questions opposées en même temps : comment empêcher différents locataires de se voir les uns les autres, tout en permettant malgré tout le partage d'appareils entre utilisateurs sans perdre la propriété. Voici comment nous avons résolu les deux.
L'isolation des locataires — la fondation
Chaque appareil (DEVICE) est lié à un unique espace de travail, et chaque requête du système — lister, se connecter, supprimer, et même le WebSocket — est filtrée par ce même espace de travail. Nous l'avons vérifié non seulement dans le code mais aussi en direct contre la base de données : 0 appareil sur 12 sans affectation, et l'accès inter-locataire est tout simplement impossible. Même le mot de passe de l'appareil est chiffré avec la clé de l'espace de travail, de sorte qu'un appareil appartenant à un locataire ne peut être déchiffré avec la clé d'un autre locataire.
La propriété par utilisateur
Au sein de la même organisation, chaque utilisateur est un locataire distinct : l'appareil appartient à celui qui l'a connecté (owner_id), et il lui est privé par défaut. C'est la séparation qui manquait lorsque chaque membre de l'équipe pouvait tout voir — désormais, un appareil non partagé reste avec son seul propriétaire.
Le partage — explicite et par appareil
Le partage est une action délibérée : le propriétaire choisit un utilisateur de l'organisation et partage avec lui un seul appareil (device_grants) ou tous ses appareils (account_grants), en choisissant entre contrôle total et consultation seule. L'appareil partagé est accessible aux deux et se comporte de façon identique — à une exception près :
Le tableau de bord dispose d'une zone « 🔗 Appareils partagés » avec deux onglets — ce que j'ai partagé, et ce qui est partagé avec moi — pour que la gestion des accès soit claire et pratique. La cryptographie n'a pas changé : le Worker déchiffre toujours avec la clé de l'espace de travail, et la ligne d'octroi constitue le droit. Il n'y a pas d'échange de clés ni de rotation — le même modèle de confiance, simplement centré par appareil plutôt que par organisation.
API et MCP par locataire
Chaque locataire peut émettre sa propre clé d'API (drk_…) qui accorde un accès programmatique exactement au même périmètre que celui dont il dispose dans le tableau de bord — pas davantage. La clé est isolée par locataire par définition. Elle alimente à la fois REST (/api/v1/*) et un serveur MCP hébergé (/api/mcp), de sorte que vous pouvez connecter un agent IA (comme Claude) et lui donner des outils : lister les appareils, voir ce qui est partagé, et obtenir un jeton de connexion à usage unique. Tout se trouve derrière le même droit — un agent ne peut pas voir un appareil que vous ne pouvez pas voir.
Carte de connexions 3D
Et enfin, une vue façon FROG : tous vos appareils et serveurs sous forme de nœuds autour d'un centre (« nous »), enveloppés dans un bouclier de protection translucide, avec des flèches entrantes/sortantes montrant le trafic, un pouls de surveillance qui se répète sur toute la connectivité, et un code couleur selon la santé de chaque appareil. Centré sur le client : chaque locataire ne voit que ses propres connexions. Ce n'est pas de la décoration — c'est un moyen de saisir d'un coup d'œil ce qui est connecté, ce qui est protégé et ce qui nécessite de l'attention.