Contrôle à distance et mobile
Control Center est une application de bureau, mais le travail qu’elle suit ne
s’arrête pas lorsque vous quittez votre poste. Le contrôle à distance associe
votre téléphone à votre cc_server au moyen de
Remote, l’application compagnon à
remote.usectrl.dev, de sorte que vous pouvez suivre la flotte à partir de là :
lire les messages et les tickets, répondre à un agent, trier votre fil de
nouvelles, sans que l’audio, la transcription, le code source ou les identifiants
qui résident sur le serveur ne le quittent jamais.
Voyez-la comme un compagnon essentiellement en lecture de l’application de bureau principale. Elle n’est pas destinée à remplacer le client de bureau complet.
Transport
Section intitulée “Transport”Le téléphone joint cc_server par un WebSocket : soit une connexion directe
(boucle locale, réseau local, tailnet ou wss://), soit un salon accessible sur
invitation sur un courtier de signalisation qui relaie des trames scellées. Il
n’y a 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é atteint une tranche petite et délibérée de la surface du serveur :
- Lire les tickets, les agents, les espaces, leurs messages et votre fil de nouvelles
- Répondre : envoyer un message dans un espace, mettre à jour ou assigner un ticket, marquer un article comme lu ou enregistré
- Exécuter 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 presque 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’espaces de travail. Voir le modèle d’accès pour savoir comment cela est appliqué plutôt que simplement souhaité.
Comment le lien est établi
Section intitulée “Comment le lien est établi”La connexion passe par un relais à courtier : le serveur rejoint un salon
accessible sur invitation sur un courtier wss:// à titre de propriétaire, et
chaque client associé — bureau, web, téléphone — rejoint le même salon avec un
jeton d’admission à durée limitée. Trois pièces entrent en jeu :
| Pièce | Rôle |
|---|---|
| Remote (application téléphonique) | L’application web compagnon, hébergée à remote.usectrl.dev par défaut, 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 salons à 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, de sorte que le courtier ne voit jamais les données de l’application ni le secret d’appairage et n’interprète jamais ce qu’il relaie. |
cc_server |
Le propriétaire du salon. Il répond aux appels du téléphone par le même répartiteur que tout autre client. |
Une offre d’appairage porte 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 en l’absence de chemin direct, sans jamais
pouvoir lire le trafic.
Ce que contient la charge utile d’appairage
Section intitulée “Ce que contient la charge utile d’appairage”L’appairage est créé à partir de l’application et livré sous forme de lien profond ; voir Associer un appareil pour la procédure. C’est son 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, de sorte que l’hôte HTTPS de la PWA ne
la voit jamais. Elle porte tout ce dont le téléphone a besoin pour joindre le
serveur et prouver son identité : le descripteur de connexion (tous les chemins
plus l’empreinte d’identité), un identifiant d’appareil fraîchement créé, une clé
prépartagée de 32 octets et une estampille d’expiration. Le téléphone la décode,
enregistre localement un enregistrement d’appairage 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 code QR pour téléphone créé à partir du panneau d’appairage intégré à
l’application est le PairingPayload v2 ci-dessus, pointé vers l’hôte de la PWA
Remote. cc_server pair --client-url produit un lien v1 différent et plus ancien
({s, i, k} — URL du serveur, identifiant d’appareil, clé) destiné uniquement au
client web.
Ils diffèrent aussi par leur durée de vie, ce qui est facile à confondre :
| Créé par | Expiration du justificatif |
|---|---|
Panneau d’appairage intégré (pairing.mint) |
30 jours, toujours |
cc_server pair en ligne de commande |
Aucune — le justificatif 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 complet 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 de nouveau à chaque appel, ainsi que par les autorisations par dépôt sur tout ce qui expose le contenu d’un 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é, est refusé avec « Not a member of this workspace ».
Le seuil de rôle est déduit du type d’opération, à moins que celle-ci ne déclare
le sien : la lecture exige guest, la mutation exige member, la destruction
exige admin.
2. Un téléphone relève d’un palier de session inférieur
Section intitulée “2. Un téléphone relève d’un palier de session inférieur”Au-delà du contrôle de rôle, une session de téléphone dispose d’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 l’exécution du gestionnaire, peu importe le privilège de l’utilisateur qui le pilote : créer, lister, renommer et révoquer des appairages d’appareil ; lire et définir la connectivité du tunnel ; la sauvegarde du serveur et l’exportation/importation d’espaces de travail ; la détection et l’arrêt de processus ; les sondes d’adaptateurs ; les paramètres du serveur ; l’administration du SSO ; le contrôle de la flotte ; et la prise de contrôle d’un agent en cours d’exécution ou la remise de la main.
3. Une liste d’autorisation qui refuse tout par défaut
Section intitulée “3. Une liste d’autorisation qui refuse tout par défaut”Pour la surface d’outils MCP en particulier (tools/call), une liste
d’autorisation qui refuse tout par défaut régit les outils que le téléphone peut
invoquer. Tout ce qui n’y figure pas est rejeté avant son exécution. La liste est
surtout axée sur la lecture et l’observation, plus une poignée d’écritures
strictement locales — 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é, par exemple : consulter un agent, lancer une révision par IA, arrêter un agent, publier une révision vers GitHub, embaucher ou congédier des agents, créer un espace de travail.
4. Délimitation de l’espace de travail à chaque appel
Section intitulée “4. Délimitation de l’espace de travail à chaque 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 carrément
l’appel lorsque celui-ci est absent ou qu’il 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 non plus, parce
que le contrôle d’appartenance de la barrière 1 s’applique encore. C’est le même
invariant d’isolation des espaces de travail que le reste du
produit impose.
5. Des trames scellées de bout en bout, chiffrées au moyen de la clé prépartagée
Section intitulée “5. Des trames scellées de bout en bout, chiffrées au moyen de la 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’ouvrir le salon à un client, il ne déchiffre rien. Le courtier relaie du texte chiffré et ne voit jamais la clé. Un appareil révoqué constate que son justificatif a déjà disparu, de sorte qu’il échoue en refusant à la reconnexion.
Un justificatif créé 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 de 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 à distance à 120 appels par minute, avec un sous-plafond plus serré de 30 par minute pour les verbes de mutation. Le budget appartient au principal, et non à la session : trois de vos appareils puisent dans une même allocation, de sorte qu’un client détourné ne peut pas se procurer de marge supplémentaire en ouvrant plus 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 salons, transmet des trames scellées et ne détient aucun compte, aucune donnée d’application et aucune clé. Les salons sont accessibles sur invitation et éphémères. Les données d’application, l’audio, la transcription, le code source 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 d’état — à l’image des notifications du poste de bureau lui-même. Le serveur diffuse ces trames à chaque session connectée et le filtre d’espace de travail est appliqué côté client, de sorte que ce que vous voyez est dé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 état en direct, plus Associer un nouveau client (navigateur web, application de bureau ou téléphone) et la révocation |
Le même panneau crée des appairages pour un deuxième navigateur ou une application de bureau, et pas seulement pour les téléphones — le déroulement est identique, seul le lien profond diffère.
Voir aussi
Section intitulée “Voir aussi”- Espaces de travail et isolation : la délimitation par appel sur laquelle ce modèle repose
- Multijoueur — identité, appartenance et présence : rôles, appartenance et autorisations par dépôt
- Déploiement et clients : où se situe le contrôle à distance parmi les paliers de clients
- Architecture : où se situe le contrôle à distance dans la pile
- Associer un appareil