Se connecter à un serveur distant

Tout client est un moteur de rendu au-dessus d’un cc_server qui détient les données. L’application de bureau peut en exécuter un en son sein ; l’application web sur app.usectrl.dev ne le peut pas, car un onglet de navigateur ne peut pas héberger de serveur. Dans un cas comme dans l’autre, ce guide pointe un client vers un serveur exécuté ailleurs — une petite machine, une VM cloud, un serveur de build.

Prérequis

Un cc_server en cours d’exécution. Si vous n’en avez pas, voir Exécuter un serveur sans interface.
Soit les trois valeurs d’appairage émises 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, enregistre votre appartenance et émet pour vous l’identifiant de ce client : vous n’avez donc jamais à manipuler un identifiant d’appareil ni une clé.

Vérifier que le serveur est joignable

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

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

un certificat directement, avec --tls-cert et --tls-key
un proxy inverse qui termine le TLS en amont, le serveur étant démarré avec --insecure (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 équivalent. Paramètres → Serveur → Connexion et état propose l’activation du tunnel intégré 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 — par défaut, elle correspond à la liaison locale, si bien que sans ce réglage, les clients essaient le mauvais hôte. Et si vous hébergez votre propre copie de la version web, ajoutez son origine à --allowed-origins, qui ne contient par défaut que https://app.usectrl.dev ; 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 de premier lancement demande Comment exécuter Control Center ?
Au lieu de Exécuter dans cette application, renseignez les champs de connexion : l’URL du serveur, plus soit un code d’invitation, soit un identifiant d’appareil et une clé d’appairage.
Cliquez sur Connecter. Control Center joint le serveur et arrive sur 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 soit un code d’invitation, soit un identifiant d’appareil et une clé d’appairage. Le bouton suffixe du champ d’URL découvre les instances cc_server sur votre réseau local ou votre tailnet.
Cliquez sur Connecter, puis sur Basculer dans la ligne du nouveau serveur.

La bascule s’effectue à chaud : l’application se reconstruit autour de la nouvelle session sur place, 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’a pas d’action Basculer ; le serveur local est la première ligne, intitulée Exécuter dans cette application.

Une fois la bascule effectuée, le bureau ne détient plus de base de données. Chaque écran lit et écrit via le serveur distant par 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, plus soit un code d’invitation, soit un identifiant d’appareil et une clé d’appairage.
Le client joint le serveur et affiche la même interface que le bureau.

Si un lien profond d’appairage figure dans l’URL, les champs sont préremplis. La clé d’appairage voyage dans le fragment d’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 bureau, mais quelques surfaces nécessitent une fenêtre native ou les périphériques propres à la machine :

aucune notification toast du système d’exploitation, aucun son de notification ni rail de bannières d’ambiance (le centre de notifications intégré 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 d’actualités s’ouvrent dans un nouvel onglet
impossible de relancer un résumé de réunion ni d’en annuler un en cours de traitement

Deux fonctions se comportent différemment plutôt que d’être absentes. L’enregistrement de réunion fonctionne dans le navigateur, en capturant votre microphone ainsi qu’un partage d’écran comportant une piste audio. Ouvrir dans l’IDE fonctionne aussi, mais demande au serveur de lancer l’éditeur sur l’affichage du serveur, si bien que le bouton se masque face à un hôte sans interface où aucun éditeur n’est installé.

Résolution des problèmes

La connexion expire : le serveur doit être joignable depuis le client. Vérifiez la liaison (--bind any), l’ouverture du port et que --public-url désigne l’adresse que le client peut réellement joindre. Sur l’internet ouvert, TLS est obligatoire — une liaison en clair sur une adresse autre que la boucle locale est refusée au démarrage, sauf si le serveur a été démarré avec --insecure derrière un proxy.
Le navigateur refuse de se connecter alors qu’un client natif fonctionne : l’origine du navigateur ne figure pas dans la liste --allowed-origins du serveur. Par défaut, seule https://app.usectrl.dev est autorisée (plus la boucle locale).
Clé d’appairage rejetée : relancez cc_server pair sur le serveur pour renouveler la clé de cet appareil, puis saisissez la nouvelle. Un appareil révoqué constate la disparition de son identifiant et échoue en refusant l’accès ; la révocation coupe une session active en quelques secondes.
Mauvais espace de travail : l’espace de travail fait partie de l’URL (/workspaces/:workspaceId/…) et accompagne chaque appel, si bien que changer d’espace de travail dans un client ne modifie que votre propre vue. Vous ne pouvez atteindre que les espaces de travail dont vous êtes membre — tout le reste est refusé par « Not a member of this workspace ». Voir Espaces de travail et isolation.

Guides connexes

Exécuter un serveur sans interface
Associer un appareil : la voie du relais téléphonique