Par Thomas Binetruy
Un développeur débogue avec un agent, ou prépare un plan d’implémentation, et a besoin d’un second avis. Il m’envoie le problème. Je le soumets à mon propre agent, nous l’examinons ensemble, puis je lui renvoie une réponse. Le développeur rapporte ensuite cette réponse dans la conversation d’origine.
C’est ainsi que nous travaillons chez Pyratz. Cela fonctionne, mais le contexte circule sans cesse entre les personnes, les outils et les sessions d’agent. Une clarification utile peut demander plusieurs allers-retours.
Au bureau, je peux aller voir le développeur sur son ordinateur et participer à la discussion. À distance, nous partageons un écran. C’est utile, mais cela mobilise aussi son environnement de travail. Même avec deux écrans, il ne peut pas toujours passer à autre chose pendant que j’examine le problème.
Nous voulions pouvoir rejoindre directement la conversation tout en laissant le développeur continuer son travail. C’est ainsi qu’est né Paseo Rooms.
Un salon autour du travail déjà engagé
Le développeur ouvre Share session dans Paseo et crée un lien. Un collègue l’ouvre dans son navigateur, choisit un nom et rejoint la conversation existante avec l’agent. Il peut consulter l’historique, suivre les réponses en direct, envoyer un message ou une capture d’écran, et répondre aux questions et validations de plan prises en charge.
L’intérêt dépasse l’équipe technique. Nous pouvons inviter un client pendant la préparation d’un plan, afin qu’il réponde aux questions métier au moment où elles se posent. « Que doit-il se passer lorsqu’un client annule ? » se résout plus facilement avec la personne qui connaît le métier dans la discussion. L’équipe choisit une session dont le contenu et les autorisations de l’agent conviennent à cette collaboration.
Le démon rend la conversation programmable
Paseo s’appuie sur un démon : un service qui fonctionne en arrière-plan sur la machine où travaillent les agents de développement. Ses interfaces de bureau, web et mobile se connectent à ce service. Fermer une vue ne met pas, en soi, fin à la session de l’agent. Le démon gère les outils d’agent sous-jacents, les « harness » tels que Claude Code ou Codex, qui interagissent avec vos fichiers et vos outils.
Chaque outil possède son propre protocole et sa façon de signaler l’avancement ou de demander une intervention. Les adaptateurs de Paseo les traduisent en un modèle commun d’agents, de fils de conversation, d’événements et de demandes en attente. Un appel d’outil peut ainsi être un événement typé. Une question prise en charge peut fournir son texte, ses choix et un identifiant de demande. Une intégration peut exploiter ces données structurées plutôt que tenter de reconnaître une question sur une capture de terminal.
C’était le socle dont nous avions besoin. Le système de plugins de Paseo place Share session à côté de la session dont nous voulons discuter. Notre composant côté hôte utilise ensuite le SDK TypeScript pour récupérer l’historique, s’abonner aux événements en direct, envoyer les contributions et répondre aux demandes en attente prises en charge. Le démon gère les différences entre les outils sous-jacents ; Rooms construit la collaboration sur cette interface commune.
Paseo illustre concrètement l’idée que je défendais dans mon article sur les logiciels extensibles à l’ère des agents : les agents de programmation rendent les logiciels dotés de bons points d’extension plus utiles, car les équipes peuvent les adapter à leur façon de travailler. Rooms en est une application directe. Nous avons pu transformer un problème récurrent de notre équipe en un parcours de partage au sein de l’outil que nous utilisions déjà, grâce aux interfaces proposées par Paseo.
Lire mon précédent article sur les logiciels extensibles à l’ère des agents →
La question de l’exemple Gather est davantage qu’une ligne de discussion. Rooms reçoit une demande structurée, affiche les choix pris en charge et renvoie la réponse sélectionnée en l’associant à cette demande. Avant de répondre, le composant hôte vérifie que la demande est toujours en attente et que la réponse est autorisée. Un clic tardif dans le navigateur ne déclenche donc pas aveuglément une action sur un état périmé.
Une API commune ne rend pas tous les outils identiques. Rooms affiche actuellement les questions prises en charge et un parcours précis de validation de plan ; les autres demandes d’autorisation restent à la charge de l’hôte dans Paseo. Le composant hôte conserve les identifiants d’accès au démon sur la machine et limite les opérations du navigateur au salon sélectionné. La documentation d’architecture décrit cette limite.
documentation d’architecture →
Un chiffrement du navigateur jusqu’à l’hôte
Partager une conversation pose immédiatement une question : qui peut la lire pendant son transport ?
La machine hôte ouvre une connexion sortante vers un relais public, auquel les participants se connectent depuis leur navigateur. Ils peuvent ainsi joindre un ordinateur portable sans y ouvrir de port public. HTTPS et les WebSockets sécurisés protègent ces connexions réseau, mais leur protection TLS s’arrête au relais. Rooms ajoute un chiffrement dont les extrémités sont le navigateur du participant et le composant Rooms côté hôte. Le relais transmet les messages chiffrés entre les deux.
Nous utilisons l’implémentation de canal chiffré publiée par Paseo dans @getpaseo/relay/e2ee. La connexion se déroule en trois étapes :
1. L’invitation indique l’hôte attendu. Chaque nouveau salon reçoit une paire de clés publique et privée, ainsi qu’un secret d’invitation aléatoire. La clé privée reste sur l’hôte. La clé publique et le secret d’invitation figurent dans le fragment de l’URL, la partie après #. Les navigateurs n’envoient pas ce fragment dans les requêtes HTTP ordinaires ; l’interface du salon le lit localement, puis le retire de la barre d’adresse.
2. Le navigateur et l’hôte établissent une clé de canal. Le navigateur crée une nouvelle paire de clés pour sa connexion. Il utilise sa clé privée et la clé publique de l’hôte contenue dans l’invitation pour calculer une clé de chiffrement partagée. L’hôte calcule la même clé à partir de sa propre clé privée et de la clé publique du navigateur. Ni les clés privées ni la clé partagée n’ont besoin de traverser le réseau. L’implémentation de Paseo utilise Curve25519 pour l’accord de clés et XSalsa20-Poly1305 pour le chiffrement authentifié, avec une nouvelle valeur aléatoire, appelée nonce, pour chaque message chiffré. Un message altéré échoue au contrôle d’authenticité.
3. L’hôte vérifie l’invitation à l’intérieur de ce canal. Établir le chiffrement ne suffit pas pour accéder au salon. Le navigateur transmet le secret d’invitation dans le canal chiffré ; l’hôte le vérifie avant de communiquer la conversation. La réception d’un message d’accueil chiffré valide prouve également au navigateur qu’il a joint un détenteur de la clé privée de l’hôte attendu.
Chaque participant répète ce processus et dispose de son propre canal vers l’hôte. Lorsqu’une réponse de l’agent arrive, l’hôte la chiffre séparément pour chaque participant. Il n’existe pas de clé de chiffrement commune à tout le salon qui permettrait à un participant de fabriquer des mises à jour authentifiées comme provenant de l’hôte. Rooms vérifie aussi les identifiants de session, les numéros de séquence et les identifiants de message pour rejeter les messages rejoués ou reçus dans le désordre ; le chiffrement seul ne garantirait pas cet ordre.
Le relais peut toujours observer les informations de connexion, les routes des salons, le volume du trafic et sa chronologie. Il peut interrompre la transmission. L’hôte voit le contenu en clair, et les contributions envoyées à l’agent sont traitées selon les règles propres au fournisseur de cet agent. Ce sont les limites du chiffrement, pas des garanties supplémentaires sur le service de modèle.
La confiance inclut aussi le code du navigateur
Le JavaScript qui réalise le chiffrement manipule nécessairement l’invitation et le contenu en clair. Quelqu’un capable de remplacer ce code pourrait capturer les messages avant leur chiffrement. Notre interface par défaut est distribuée séparément sur GitHub Pages : contrôler le relais seul ne donne donc pas le contrôle de ce premier chargement de page. Il faut néanmoins faire confiance au déploiement de l’interface et à ses administrateurs. L’interface servie par le relais sur notre domaine produit réunit ces responsabilités chez un même opérateur.
Une équipe peut héberger elle-même le relais et l’interface sous son propre domaine, ou distribuer l’interface depuis un hébergement statique distinct qu’elle contrôle. Elle choisit ainsi les opérateurs du routage et de la distribution du code. Elle doit toujours faire confiance à ses machines hôtes et aux personnes qu’elle invite.
héberger elle-même le relais et l’interface →
Le lien complet fait office de droit d’accès : toute personne qui le détient peut rejoindre le salon tant qu’il est actif. Un nom d’affichage choisi ne vérifie pas une identité. Les participants peuvent aussi influencer l’utilisation des outils autorisés de l’agent. Enfin, cette conception ne fournit pas de confidentialité persistante, ou forward secrecy, en cas de compromission ultérieure de la clé privée du salon : une personne disposant de cette clé et d’un échange enregistré pourrait le déchiffrer. Les clés propres à chaque salon, conservées en mémoire, limitent leur durée de vie ; la révocation ou l’arrêt du processus hôte met fin au salon. La documentation de sécurité détaille ces compromis.
Comment une capture d’écran parvient à l’agent et au salon
Une capture d’écran est souvent la pièce manquante dans une discussion de débogage. Dans Rooms, un participant peut joindre à son message une image PNG, JPEG ou WebP de 2 Mio maximum.
Le navigateur vérifie le fichier et l’envoie par blocs de 24 Kio dont la réception est confirmée, à l’intérieur de son canal chiffré. L’hôte reconstitue les octets, valide le format et les dimensions, puis conserve la pièce jointe dans un espace mémoire plafonné propre au salon. Le découpage permet d’afficher la progression et de confirmer chaque bloc sans dépendre d’un seul message surdimensionné.
Lorsque le participant envoie sa contribution, l’hôte transmet le message et les octets de l’image à l’agent sélectionné via le SDK de Paseo. Il attribue un identifiant au message et s’en sert pour associer la pièce jointe à l’entrée correspondante du fil de conversation. Les autres participants reçoivent les métadonnées locales de l’image et récupèrent ses octets depuis l’hôte via leur propre canal chiffré lorsqu’ils ont besoin de l’aperçu. Il n’existe ni URL publique de l’image ni point d’accès permettant au navigateur de télécharger des fichiers arbitraires sur la machine hôte.
Le transfert du fichier et l’envoi à l’agent sont deux étapes distinctes. Si une déconnexion rend la livraison incertaine, Rooms peut vérifier son accusé de prise en compte plutôt que soumettre immédiatement la même image une seconde fois. Une acceptation signifie que le SDK a accepté l’envoi, pas que le modèle a terminé l’interprétation de l’image. La capacité de l’agent à exploiter celle-ci dépend aussi de l’outil et du modèle sélectionnés.
Cette fonctionnalité concerne les images envoyées depuis Rooms. Les images jointes directement dans l’éditeur de messages de Paseo ne sont pas automatiquement importées dans le salon. La copie du salon disparaît lors de sa révocation ou de l’arrêt du processus hôte ; cela n’efface pas les copies déjà téléchargées par les participants ou transmises au fournisseur de l’agent. Le guide de partage d’images précise les limites et les états de livraison.
Et ensuite : des agents parmi les participants ?
Nous avons fait une petite expérience : un agent a ouvert un salon depuis un second navigateur et envoyé un message dans sa propre session. Le message est arrivé, et l’agent a répondu. Nous nous sommes arrêtés après cet échange.
C’est un point de départ pour vérifier si des agents distincts peuvent échanger leurs conclusions ou discuter un plan dans un salon, avec des personnes qui suivent la conversation.
Ces expériences demandent des rôles explicites, un nombre de tours borné, une autorité claire et des conditions d’arrêt. Une boucle de réponses se crée facilement ; une collaboration utile a besoin de davantage de structure.
Essayez-le avec votre équipe
Nous vous invitons à tester Paseo Rooms sur une véritable session de planification ou de débogage. Installez le plugin, créez un salon et invitez un collègue ou un client qui peut aider à répondre à la prochaine question. Les participants ont seulement besoin du lien d’invitation complet et d’un navigateur.
Choisissez d’abord une session que vous acceptez de partager, vérifiez les autorisations des outils de l’agent et révoquez le lien lorsque vous avez terminé. Dites-nous ce qui vous a aidé ou freiné en ouvrant un ticket sur GitHub.
ouvrant un ticket sur GitHub →
Pyratz2036 — Mobiliser la puissance de l’intelligence de manière responsable
Une thèse d’investissement pour l’ère de l’intelligence : financer les technologies qui créent l’abondance, les ressources rares dont elles dépendent et les institutions réglementées qui permettent leur déploiement, tout en préservant la propriété, la liberté de choix et la capacité d’agir.
L'usine logicielle
Avec les agents IA, le développeur ne se contente plus d’écrire du code. Il conçoit et supervise un système capable de développer, vérifier, déployer et faire fonctionner des logiciels.
Le logiciel extensible à l’ère des agents IA
Avec les agents de programmation, il devient plus facile d’adapter un logiciel à ses besoins. De petits problèmes du quotidien peuvent enfin trouver une solution sur mesure.