Ne soyez pas le meat proxy de votre équipe

Quand vos agents tournent sur vos machines, votre équipe ne peut les joindre qu’en passant par vous. Peter Steinberger, le créateur d’OpenClaw, qui travaille aujourd’hui sur les agents chez OpenAI, appelle ça être un meat proxy, un proxy en chair et en os. À l’OpenAI DevDay, il a présenté sa solution : déplacer les sessions d’agents sur un serveur d’équipe partagé, où chacun peut lire, prompter ou reprendre la session de n’importe qui.

Les deux dernières conférences que j’ai résumées portaient sur les agents eux-mêmes : l’usine logicielle de Dex Horthy et les collègues IA dans Slack de MintMCP. Celle de Peter porte sur les gens autour. Dans son équipe, tout le monde avait des agents. Ils ne travaillaient pas ensemble pour autant.

Ajouter des machines n’a rien réglé

Il commence par raconter comment son installation a grossi cette année. D’abord le terminal : écran divisé, des tas de sessions Codex, un doigt sur la touche Échap pour recadrer. Les modèles se sont améliorés, il a moins eu à recadrer, alors il est passé à l’app de bureau Codex, où lancer beaucoup de sessions à la fois est plus simple. Puis son portable a manqué de disque et ses ventilateurs « faisaient un bruit de réacteur d’avion », alors il a réparti le travail sur six à dix machines : des devboxes, plus des machines dans le cloud qui lancent les tests.

Rien de tout ça n’a réglé le vrai goulot d’étranglement :

Quand mes collègues voulaient s’impliquer, ils devaient toujours passer par moi. Vous voyez, on travaillait tous avec des agents, mais on ne travaillait pas vraiment ensemble.

Meat proxy, deuxième sens

Le terme vient de Niklas Gruhn. Son billet d’août, Don’t be a meat proxy, parle de quelqu’un qui colle des réponses d’IA à ses collègues sans les lire, si bien que le collègue aurait aussi bien pu interroger l’IA lui-même. C’est une insulte qui vise une habitude.

Peter l’emploie pour quelque chose de plus large : servir d’interface avec l’IA, faire passer les messages dans un sens puis dans l’autre. Vous pouvez lire chaque mot qu’écrit votre agent et en être un quand même, si les agents n’existent que sur votre portable. C’est ce que cette conférence m’apporte de neuf. Ce n’est pas une question de discipline. C’est une question de lieu : là où vivent les sessions.

Montrez-moi le prompt

Sa première tentative n’était pas un serveur. Une seule phrase peut aujourd’hui produire des dizaines de milliers de lignes de code, mais la conversation qui les a produites reste sur la machine de quelqu’un. Il a relu bon nombre de PR où il comprenait ce qui avait changé, mais pas pourquoi.

Il a donc ajouté une skill qui demandait aux contributeurs de joindre à leur PR une transcription nettoyée. Très peu ont accepté, et il reconnaît qu’il a parfois refusé lui aussi. Montrer comment on parle à son agent a quelque chose d’étonnamment intime.

Quand son équipe a rendu toutes les sessions visibles, ça a été gênant pendant une journée. Ils ont lu les conversations des uns et des autres, en ont un peu ri, puis c’est devenu normal. Aujourd’hui, ils apprennent de la façon dont les autres promptent et repèrent les erreurs plus tôt.

La démo convainc mieux que les slides. Il se réveille devant une PR où Victor, un collègue, a réduit les tableaux, le lendemain du jour où Peter les avait agrandis. L’ancien réflexe aurait été ce qu’il appelle un « message pas très californien ». À la place, il ouvre la session de travail derrière la PR. Victor avait repris la propre session de Peter, l’avait prévenu d’abord, et corrigé ce que Peter avait raté. Crise réglée avant le déjeuner.

Sa conclusion est sans détour : les pull requests comme façon de collaborer, ça « ne ressemble tout simplement plus à l’avenir ». Sur le serveur d’équipe, chacun voit et prompte la session de n’importe qui, donc la seule règle est de n’inviter que des gens qui peuvent mettre les mains dans vos sessions sans que ça vous gêne. Ensuite, il veut inviter les principaux contributeurs d’OpenClaw : eux reçoivent les tokens, et le projet récupère un peu de leurs idées. « Je trouve que c’est une super affaire. »

Le serveur est un lieu, pas une app

La barre latérale de ce serveur est pleine de petites apps : les temps de CI, les chiffres de la communauté (PR ouvertes, issues, merges), un journal « daily Claw » écrit à partir de tout ce qui a été mergé, un slopomètre qui pousse sans arrêt les agents à faire le ménage, des rapports d’activité et les réunions. Ils payaient un logiciel de réunion, jusqu’au jour où il s’est dit « ça, c’est un prompt ». Aujourd’hui, l’agent rejoint leurs appels Discord, rédige le compte rendu et peut répondre à voix haute.

Pour lui, un tableau de bord, c’est une session qui génère un artefact, plus une automatisation qui le tient à jour. Vous le voulez en bleu ? Dites-le à l’agent. Ça change si vite qu’il préfère parler de jellyware plutôt que de software. Et comme chaque tableau de bord est une session sur le serveur partagé, n’importe qui dans l’équipe peut le modifier, pas seulement la personne qui l’a construit.

Il pense aussi que la CI telle qu’on la pratique n’a plus de sens, et il essaie Codex pour choisir les tests dont un changement a vraiment besoin. Il garde ce sujet pour une autre conférence.

Boucles, objectifs et goût

Vient ensuite la partie usine. Il fait tourner deux sortes de travaux au long cours :

La boucle de tri, c’est celle que je copierais :

Ces boucles tournaient avant sur ses propres machines. Parfois elles s’arrêtaient, et parfois il ne savait plus trop quelle machine faisait tourner quoi. Il les déplace maintenant une par une sur le serveur d’équipe, pour que d’autres puissent les maintenir et en tirer des leçons. Le goût, c’est la partie qu’il ne déléguera pas : c’est difficile à décrire et « souvent juste une intuition ». Là où il veut arriver : un agent par projet, avec sa propre mémoire, ses automatisations, ses objectifs et ses boucles, qui reçoit de lui les grandes orientations.

On retrouve l’usine logicielle, avec un changement : l’usine est une pièce partagée, pas le terminal d’une seule personne.

Les agents ont leur propre badge

Kevin Lin, qui dirige OpenClaw Enterprise chez OpenAI, a assuré la seconde moitié. Il a publié le projet en open source : un plan de contrôle qui rend OpenClaw multi-tenant. Les contrôles qu’il a passés en revue :

• le code déterministe tourne dans un conteneur séparé, dans leur cas un cluster séparé, pour qu’un agent ne puisse pas modifier son propre runtime
• une sandbox pour l’accès réseau, les fichiers qu’un agent peut écrire et les dépôts sur lesquels il peut pousser
• la revue automatique : un autre modèle vérifie les actions de l’agent et bloque les dangereuses avant qu’elles ne s’exécutent
• les agents tournent sous leur propre identité, avec des comptes de service et leurs propres connecteurs, parce que « les agents ne se font pas passer pour les utilisateurs »

Ce dernier point, c’est tout le propos de ma note sur les collègues IA, désormais dans une plateforme open source. OpenAI fait tourner plus de 400 Claws en interne avec ces contrôles. Selon lui, si vous avez ouvert une issue Codex le mois dernier, il y a de bonnes chances qu’un agent OpenClaw l’ait triée, reproduite et, dans bien des cas, ait mergé le correctif. Il l’a présenté comme un Kubernetes pour agents. L’annonce précise qu’il est réservé à des pilotes internes jusqu’à la 1.0, prévue plus tard cette année.

Où en est ma propre flotte

Hier, j’écrivais que la prochaine étape serait que Nova, mon agent généraliste, ouvre un canal pour une tâche de code et y fasse venir Spark, mon codeur. C’est en place. Nova ouvre un canal de job dans Slack, nous invite, Spark et moi, et poste le brief. Spark construit, Nova tranche, et on ne me tague que pour des choses comme les secrets, les dépenses ou tout ce qui est destructif. Depuis ce matin, le même circuit tourne dans des fils de forum Discord.

Les agents se parlent donc au grand jour. Selon le critère de Peter, je reste pourtant à moitié proxy : le canal montre ce que Nova et Spark se disent, pas les sessions derrière ces messages, et personne d’autre que moi ne peut les ouvrir. Pour une équipe d’une personne, ça va. Le jour où quelqu’un travaillera avec moi sur ces projets, le serveur de Peter sera la première chose que j’essaierai.

La conférence dure 35 minutes. La slide du meat proxy est à 2:27, et l’histoire de Victor, à 11:46, est le passage que je montrerais à un responsable d’équipe. Si votre équipe partage déjà ses sessions d’agents, j’aimerais beaucoup savoir comment s’est passé ce premier jour gênant.

Texte brut: dont-be-your-teams-meat-proxy.md · Flux Atom · Toutes les notes