Ce qu’un lien doit transporter pour partager une session de code en direct
Partager une session de code en direct implique d’envoyer un lien contenant trois éléments : le canvas ciblé, les droits accordés (lecture ou édition) et le nom associé au curseur. L’application en cours de test est relayée via cette même session authentifiée.
Un partage d’écran montre l’écran d’un individu. C’est inadapté pour un agent opérant pendant vingt minutes, car l’intérêt réside dans le travail accompli par la machine et non dans le regard d’un observateur qui peut s’absenter. Nous voulions un simple lien : vous l’envoyez, la personne l’ouvre et se retrouve dans la pièce.
Trois éléments, sans aucun flux vidéo
Aucun flux vidéo n’est transmis. La session ne tourne sur le portable de personne au départ, rejoindre la session ne consiste donc pas à dupliquer des pixels. Le lien ne transporte que trois faits : le canvas concerné, les autorisations de l’invité et le nom à lui attribuer.
Le deuxième point est souvent sous-estimé. Un canvas en lecture seule et un canvas de travail présentent la même vue mais constituent deux produits distincts. La restriction réside dans le jeton d’accès et non dans l’interface graphique.
Le troisième élément transforme un écran partagé en une pièce collaborative. Chaque participant est représenté par un point coloré et un nom, avec son état (observation ou édition). Une couleur vive sur ce canvas désigne toujours un agent ou un humain, jamais une décoration.
Le piège critique de la prévisualisation
Les agents construisent une application, et le but est de la voir s’exécuter. Le canvas intègre un aperçu en direct : une fenêtre affichant ce que le serveur de dev produit dans la sandbox, rafraîchi à chaque modification de code.
La tentation classique est d’assigner un sous-domaine public à chaque sandbox. Nous avons exclu cette approche : toute URL publique prévisible exposerait sur Internet une application inachevée contenant potentiellement des failles ou des données sensibles.
L’aperçu est donc relayé directement par la session authentifiée. Le navigateur interroge le plan de contrôle avec un jeton éphémère. Le plan de contrôle achemine la requête via le lien existant et la résolution de localhost s’effectue au cœur de la sandbox. Aucun nom d’hôte public n’existe.
Le compromis assumé
Relayer un serveur de développement via une session WebSocket demande davantage d’ingénierie que de configurer des DNS, et impose des limites sur les volumes de données.
C’est le bon choix architectural. Un aperçu sert à vérifier la construction d’une application entre collaborateurs autorisés, avec le niveau exact de permissions du canvas, sans publication sauvage.
Ce que le partage transforme
Quand une session devient un lien plutôt qu’une machine locale, inviter un collègue ne nécessite plus d’organisation préalable ni d’appel vidéo. Les agents continuent leur travail même après fermeture de l’onglet. Garder ce navigateur connecté de façon intègre garantit qu’un second visiteur ne ralentit jamais le premier.
La collaboration en direct est présentée dans coder à plusieurs avec des agents IA, et la résilience du flux dans observer un terminal distant.
Réponses directes
Comment partager une session Claude Code avec votre équipe ?
Sur Murmell, en envoyant simplement le lien du canvas. Quiconque l’ouvre rejoint le même espace, voit les terminaux en direct et apparaît sous forme de curseur identifié.
Une personne peut-elle observer sans pouvoir modifier le code ?
Oui. Le lien intègre le rôle, permettant d’attribuer un statut de simple spectateur ou d’éditeur actif.
L’application construite par les agents est-elle accessible à quiconque possède l’URL ?
Non. Le serveur de développement écoute sur localhost dans la sandbox et transite par la session authentifiée du canvas avec des autorisations temporaires, sans domaine public exposé.