Se connecter à un serveur distant

Chaque client est un moteur de rendu au-dessus d’un cc_server qui détient les données. Le poste de bureau peut en exécuter un à l’intérieur de lui-même ; l’application web à app.usectrl.dev ne le peut pas, car un onglet de navigateur ne peut pas héberger un serveur. Dans un cas comme dans l’autre, ce guide pointe un client vers un serveur exécuté ailleurs — une petite machine, une VM infonuagique, un serveur de compilation.

Prérequis

Un cc_server en cours d’exécution. Si vous n’en avez pas, consultez Exécuter un serveur sans interface.
Soit les trois valeurs d’appairage générées par le serveur — l’URL du serveur (ws://…/rpc ou wss://…/rpc), un identifiant d’appareil et une clé d’appairage —, soit un code d’invitation à usage unique fourni par un administrateur de l’espace de travail. Utiliser une invitation provisionne votre utilisateur, consigne votre appartenance et émet le justificatif de ce client pour vous, de sorte que vous ne manipulez jamais un identifiant d’appareil ni une clé.

Vérifiez que le serveur est joignable

Un serveur local n’a besoin de rien : ws://localhost:9030/rpc fonctionne depuis le poste de bureau comme depuis le navigateur, car les navigateurs considèrent la boucle locale comme une origine digne de confiance.

Un serveur sur une autre machine, c’est différent. app.usectrl.dev est servi en HTTPS, de sorte que le navigateur n’ouvrira une connexion wss:// qu’avec un certificat auquel il fait déjà confiance — et cc_server refuse d’emblée de lier une adresse autre que la boucle locale sans TLS. Donnez-lui l’un des éléments suivants :

un certificat directement, avec --tls-cert et --tls-key
un proxy inverse qui termine le TLS, placé devant, avec le serveur démarré --insecure (texte en clair derrière le proxy, sur un réseau de confiance uniquement)
un tunnel ou un VPN qui fournit le certificat — Tailscale, cloudflared ou similaire. Paramètres → Serveur → Connexion et état contient l’option de tunnel intégrée sous Partager ce serveur.

Deux réglages côté serveur sont faciles à manquer. Derrière un proxy, un NAT ou un tunnel, définissez --public-url sur l’adresse que les clients doivent réellement joindre — il vaut par défaut l’adresse de liaison locale ; sans lui, les clients tentent le mauvais hôte. Et si vous hébergez votre propre copie de la version web, ajoutez son origine à --allowed-origins, qui vaut par défaut https://app.usectrl.dev seul ; la boucle locale et les clients natifs sont toujours autorisés.

Connecter l’application de bureau

Sur une installation neuve :

Lancez Control Center. L’écran du premier démarrage demande Comment exécuter Control Center ?
Au lieu de Exécuter dans cette application, remplissez les champs de connexion : l’URL du serveur, puis soit un code d’invitation, soit un identifiant d’appareil et une clé d’appairage.
Cliquez sur Se connecter. Control Center joint le serveur et arrive dans la boîte de réception de l’espace de travail.

Sur un poste de bureau qui exécute déjà son propre serveur :

Ouvrez Paramètres → Serveur → Connexion et état.
Cliquez sur Ajouter un serveur. Saisissez l’URL du serveur (wss://host:9030/rpc) et, au choix, un code d’invitation ou un identifiant d’appareil et une clé d’appairage. Le bouton situé au bout du champ d’URL découvre les instances cc_server sur votre réseau local ou votre tailnet.
Cliquez sur Se connecter, puis sur Basculer dans la ligne du nouveau serveur.

La bascule est immédiate : l’application se reconstruit autour de la nouvelle session, sans redémarrage. Si la connexion échoue, vous restez sur le serveur actuel et voyez l’erreur. La ligne du serveur sur lequel vous êtes n’offre aucune action Basculer ; le serveur local est la première ligne, étiquetée Exécuter dans cette application.

Une fois la bascule faite, le poste de bureau ne détient aucune base de données. Chaque écran lit et écrit par l’intermédiaire du serveur distant, au moyen d’une connexion WebSocket.

Connecter le client web

La version web est toujours distante.

Ouvrez app.usectrl.dev, ou votre propre copie de la version web.
Saisissez l’URL du serveur et, au choix, un code d’invitation ou un identifiant d’appareil et une clé d’appairage.
Le client joint le serveur et affiche la même interface que le poste de bureau.

Si un lien profond d’appairage se trouve dans l’URL, les champs sont préremplis. La clé d’appairage voyage dans le fragment de l’URL, que les navigateurs n’envoient jamais au serveur qui héberge la page ; l’hôte statique ne la voit donc jamais.

Ce que le navigateur ne fait pas

Le client web lit et écrit sur le même serveur que le poste de bureau, mais quelques surfaces ont besoin d’une fenêtre native ou des appareils de la machine :

aucun toast du système d’exploitation, aucun son de notification ni aucune bannière d’ambiance (le centre de notifications de l’application fonctionne toujours)
aucune découverte de serveurs sur le réseau local ou le tailnet dans la boîte de dialogue Ajouter un serveur
aucun lecteur d’articles intégré — les articles du fil de nouvelles s’ouvrent dans un nouvel onglet
impossible de relancer un résumé de réunion ni d’annuler celui qui est en cours de traitement

Deux éléments se comportent différemment plutôt que d’être absents. L’enregistrement d’une réunion fonctionne dans le navigateur : il capte votre microphone plus un partage d’écran qui comprend une piste audio. Ouvrir dans l’éditeur fonctionne aussi, mais demande au serveur de lancer l’éditeur sur l’écran du serveur ; le bouton se masque donc devant un hôte sans interface où aucun éditeur n’est installé.

Dépannage

La connexion expire : le serveur doit être joignable depuis le client. Vérifiez l’adresse de liaison (--bind any), que le port est ouvert et que --public-url nomme l’adresse que le client peut réellement joindre. Sur l’internet ouvert, TLS est obligatoire — une liaison en texte clair autre que la boucle locale est refusée au démarrage, à moins que le serveur n’ait été démarré --insecure derrière un proxy.
Le navigateur refuse de se connecter, mais un client natif fonctionne : l’origine du navigateur ne figure pas dans la liste --allowed-origins du serveur. La valeur par défaut n’autorise que https://app.usectrl.dev (et la boucle locale).
Clé d’appairage refusée : relancez cc_server pair sur le serveur pour permuter la clé de cet appareil, puis saisissez la nouvelle. Un appareil révoqué constate que son justificatif a disparu et échoue en mode fermé ; la révocation interrompt une session active en quelques secondes.
Mauvais espace de travail : l’espace de travail fait partie de l’URL (/workspaces/:workspaceId/…) et voyage avec chaque appel, de sorte que basculer d’un espace de travail à l’autre dans un client ne change que votre propre vue. Vous ne pouvez atteindre que les espaces de travail dont vous êtes membre — tout autre est refusé avec « Not a member of this workspace ». Consultez Espaces de travail et isolation.

Guides connexes

Exécuter un serveur sans interface
Associer un appareil : le chemin de relais pour le téléphone