Contrôle à distance et mobile
Control Center est une application de bureau, mais le travail qu’il suit ne
s’arrête pas lorsque vous vous éloignez de votre poste. Le contrôle à
distance associe votre téléphone à votre cc_server, au moyen de
Remote, l’application compagnon disponible à
l’adresse remote.usectrl.dev, afin que vous puissiez suivre la flotte depuis là :
lire les messages et les tickets, répondre à un agent, trier votre fil
d’actualités, sans que l’audio, la transcription, le code source ou les
identifiants qui résident sur le serveur ne le quittent jamais.
Voyez-y un compagnon du deck, essentiellement en lecture. Il n’a pas vocation à remplacer le client de bureau complet.
Transport
Section intitulée « Transport »Le téléphone atteint cc_server par WebSocket : soit une connexion directe
(boucle locale, réseau local, tailnet ou wss://), soit une salle protégée par
invitation sur un courtier de signalisation qui relaie les trames scellées. Il
n’existe aucun canal de données pair à pair.
Ce que le téléphone peut faire
Section intitulée « Ce que le téléphone peut faire »Le téléphone associé n’atteint qu’une tranche étroite et délibérée de la surface du serveur :
- Lire les tickets, les agents, les espaces et leurs messages, ainsi que votre fil d’actualités
- Répondre : envoyer un message dans un espace, mettre à jour ou assigner un ticket, marquer un article comme lu ou enregistré
- Lancer un playbook : instancier un modèle de plan enregistré avec ses paramètres. Cela ne fait que proposer un plan ; rien ne s’exécute ni ne dépense tant qu’un opérateur ne l’approuve pas dans Plan Studio sur un client complet
- Changer d’espace de travail, depuis le sélecteur propre au téléphone
C’est à peu près tout. Un téléphone est un principal moins privilégié qu’un client complet. Il ne peut pas lancer de processus, dépenser du budget LLM, pousser vers GitHub ni créer d’espace de travail. Voir le modèle d’accès pour la manière dont cela est appliqué, et pas seulement souhaité.
Comment la liaison s’établit
Section intitulée « Comment la liaison s’établit »La connexion passe par un relais à courtage : le serveur rejoint une salle
protégée par invitation sur un courtier wss:// en tant que propriétaire, et
chaque client associé — bureau, web, téléphone — rejoint la même salle avec un
jeton d’admission à durée limitée. Trois pièces entrent en jeu :
| Pièce | Rôle |
|---|---|
| Remote (application téléphone) | L’application web compagnon, hébergée par défaut à remote.usectrl.dev, ou auto-hébergée. Se charge dans un navigateur et conserve l’enregistrement d’appairage dans IndexedDB. |
| Courtier relais | Un relais wss:// sans état (cc_signaling_server) qui héberge des salles à N participants. Il ne transporte que des trames opaques : chaque charge utile est scellée de bout en bout entre le téléphone et le serveur, si bien que le courtier ne voit jamais les données applicatives ni le secret d’appairage et n’interprète jamais ce qu’il relaie. |
cc_server |
Le propriétaire de la salle. Il répond aux appels du téléphone par le même répartiteur que tous les autres clients. |
Une offre d’appairage transporte un descripteur de connexion qui énumère
tous les chemins vers le serveur (réseau local, tailnet, wss:// public,
relais) ainsi que son empreinte d’identité. Le résolveur du téléphone choisit le
meilleur chemin joignable et épingle l’empreinte à la première connexion (TOFU) ;
le relais garantit la connectivité même lorsqu’aucun chemin direct n’existe,
sans jamais pouvoir lire le trafic.
Ce qu’est la charge utile d’appairage
Section intitulée « Ce qu’est la charge utile d’appairage »L’appairage est émis depuis l’application et transmis sous forme de lien profond ; voir Associer un appareil pour la procédure. C’est l’anatomie qui importe ici.
https://<pwa-host>/#<payload>La charge utile voyage dans le fragment de l’URL, la partie après # que
les navigateurs n’envoient jamais au serveur, si bien que l’hôte HTTPS de la PWA
ne la voit jamais. Elle transporte tout ce dont le téléphone a besoin pour
atteindre le serveur et prouver son identité : le descripteur de connexion
(chaque chemin plus l’empreinte d’identité), un identifiant d’appareil
fraîchement émis, une clé pré-partagée de 32 octets et un horodatage
d’expiration. Le téléphone la décode, conserve un enregistrement d’appairage en
local et retire le fragment pour que le secret quitte l’URL.
Il existe deux formes de charge utile et elles ne sont pas interchangeables.
Le QR code émis depuis le panneau d’appairage de l’application est la
PairingPayload v2 décrite ci-dessus, pointée vers l’hôte de la PWA Remote.
cc_server pair --client-url émet un lien v1 plus ancien et différent
({s, i, k} — URL du serveur, identifiant d’appareil, clé), destiné au client
web uniquement.
Elles diffèrent aussi par leur durée de vie, ce qu’il est facile de se représenter à tort :
| Émis par | Expiration de l’identifiant |
|---|---|
Panneau d’appairage de l’application (pairing.mint) |
30 jours, toujours |
cc_server pair en ligne de commande |
Aucune — l’identifiant n’expire pas |
Le modèle d’accès
Section intitulée « Le modèle d’accès »Un appareil associé est authentifié mais non fiable. Plusieurs barrières indépendantes empêchent un appairage approuvé (ou divulgué) de devenir un contrôle total du serveur.
1. L’appartenance, et non l’appairage, constitue la frontière
Section intitulée « 1. L’appartenance, et non l’appairage, constitue la frontière »Une clé d’appairage valide prouve quel appareil vous êtes. Ce que vous pouvez lire ou modifier est décidé par votre rôle dans l’espace de travail, résolu à nouveau à chaque appel, ainsi que par les attributions par dépôt pour tout ce qui expose du contenu de dépôt. Un appareil qui détient une clé parfaitement valide mais qui appartient à un utilisateur non membre de l’espace de travail nommé se voit refuser l’accès avec « Not a member of this workspace ».
Le plancher de rôle est dérivé du type de l’opération, sauf si celle-ci déclare
le sien : les lectures exigent guest, les mutations exigent member, les
opérations destructrices exigent admin.
2. Un téléphone relève d’un niveau de session inférieur
Section intitulée « 2. Un téléphone relève d’un niveau de session inférieur »Au-delà du contrôle de rôle, une session de téléphone porte une capacité inférieure à celle d’une session de bureau ou web. Les opérations déclarées réservées au client complet sont refusées à un téléphone avant même l’exécution du gestionnaire, quel que soit le privilège de l’utilisateur qui se trouve derrière : émettre, lister, renommer et révoquer des appairages d’appareil ; lire et définir la connectivité de tunnel ; sauvegarde du serveur et export/import d’espace de travail ; détection et arrêt de processus ; sondes d’adaptateur ; paramètres du serveur ; administration SSO ; contrôle de la flotte ; et la prise en main ou la restitution d’un agent en cours d’exécution.
3. Une liste d’autorisations en refus par défaut
Section intitulée « 3. Une liste d’autorisations en refus par défaut »Pour la surface d’outils MCP spécifiquement (tools/call), une liste
d’autorisations en refus par défaut régit les outils que le téléphone peut
invoquer. Tout ce qui n’y figure pas est rejeté avant d’être exécuté. La liste
est surtout orientée lecture et observation, plus une poignée d’écritures
locales uniquement — un message, une mise à jour de ticket, un marquage
d’article — qui ne dépensent aucun budget LLM, ne lancent aucun processus et ne
touchent aucun système externe.
Refusés, par exemple : consulter un agent, démarrer une revue par IA, arrêter un agent, publier une revue sur GitHub, embaucher ou renvoyer des agents, créer un espace de travail.
4. Portée d’espace de travail par appel
Section intitulée « 4. Portée d’espace de travail par appel »Le serveur ne détient aucun « espace de travail courant ». Il est sans état
par conception : chaque appel propre à un espace de travail doit nommer son
workspace_id cible dans ses arguments, et le répartiteur refuse purement et
simplement l’appel lorsque celui-ci manque ou nomme un espace de travail que le
serveur n’a pas enregistré — avant que quoi que ce soit n’ouvre une base de
données. Un téléphone ne peut donc jamais hériter de la portée d’un autre client
ni y dériver, et nommer un espace de travail étranger n’aide pas davantage, car
le contrôle d’appartenance de la barrière 1 s’applique toujours. C’est le même
invariant d’isolation des espaces de travail que le reste du
produit applique.
5. Des trames scellées de bout en bout, à clé pré-partagée
Section intitulée « 5. Des trames scellées de bout en bout, à clé pré-partagée »Chaque trame entre le téléphone et le serveur est scellée avec la clé d’appairage ; le jeton d’admission ne fait qu’introduire un client dans la salle, il ne déchiffre rien. Le courtier relaie du texte chiffré et ne voit jamais la clé. Un appareil révoqué constate que son identifiant a déjà disparu, si bien qu’il échoue en mode fermé à la reconnexion.
Un identifiant émis par l’application est limité à 30 jours ; passé ce délai, la barrière de connexion le refuse et le téléphone doit s’associer à nouveau. La révocation est immédiate : le serveur surveille la table des appareils et coupe les sessions ouvertes d’un appareil révoqué en quelques secondes, plutôt que d’attendre sa prochaine connexion.
6. Limitation de débit par principal
Section intitulée « 6. Limitation de débit par principal »Un limiteur à fenêtre glissante plafonne le trafic d’outils distant à 120 appels par minute, avec un sous-plafond plus serré de 30 par minute sur les verbes de mutation. Le budget appartient au principal, et non à la session : trois de vos appareils puisent dans une même enveloppe, si bien qu’un client détourné ne peut pas se procurer de la marge en ouvrant davantage de sessions, et qu’un membre bruyant ne peut pas affamer les autres.
7. Un courtier qui n’apprend rien
Section intitulée « 7. Un courtier qui n’apprend rien »Le courtier relais est délibérément simple : il héberge des salles, relaie des trames scellées et ne détient aucun compte, aucune donnée applicative et aucune clé. Les salles sont protégées par invitation et éphémères. Les données applicatives, l’audio, la transcription, les sources et les identifiants restent tous sur le serveur.
Mises à jour en direct
Section intitulée « Mises à jour en direct »Une fois associé, le téléphone reçoit des mises à jour en direct sous forme de trames de notification — nouveaux messages d’agent, tickets qui vous sont assignés, changements de statut — à l’image des notifications du poste de bureau. Le serveur diffuse ces trames à chaque session connectée et le filtre d’espace de travail est appliqué côté client, si bien que ce que vous voyez est limité à l’espace de travail que vous consultez.
Où cela se trouve
Section intitulée « Où cela se trouve »| Surface | Ce qu’elle affiche |
|---|---|
Paramètres → Vous → Vos appareils (/workspaces/:workspaceId/settings/you/devices) |
Les clients associés avec leur statut en direct, plus Associer un nouveau client (navigateur web, application de bureau ou téléphone) et la révocation |
Le même panneau émet des appairages pour un second navigateur ou une application de bureau, pas seulement pour des téléphones — le déroulement est identique, seul le lien profond change.
Voir aussi
Section intitulée « Voir aussi »- Espaces de travail et isolation : la portée par appel sur laquelle ceci s’appuie
- Multijoueur — identité, appartenance et présence : rôles, appartenance et attributions par dépôt
- Déploiement et clients : où se situe le contrôle à distance parmi les niveaux de clients
- Architecture : où se situe le contrôle à distance dans la pile
- Associer un appareil