Quand les agents deviennent des collègues : l'idée derrière Buzz

J’ai déjà écrit sur Buzz, avec à l’époque un focus clair sur le Shared Compute et l’exploitation partagée des modèles. C’était pour moi au départ la partie la plus fascinante et la plus inhabituelle du projet. Mais plus je me penche sur Buzz, plus l’espace de travail lui-même devient intéressant. C’est pourquoi j’ai entre-temps testé Buzz dans une petite configuration.

Cela tient aussi à un problème que je ressens de plus en plus nettement ces derniers mois. Mon travail avec l’IA est devenu non seulement plus rapide, mais aussi plus confus. Codex travaille sur un dépôt, Claude Code examine une deuxième idée, un autre agent collecte des informations, et quelque part entre les deux tournent terminal, navigateur, e-mail et plusieurs discussions. Chaque agent peut être utile en soi. Le problème survient aux transitions. Le contexte doit être copié, les décisions répétées et les résultats fusionnés manuellement.

C’est exactement là que Buzz intervient. Ce projet open source vient de Block, l’entreprise dirigée par le cofondateur de Twitter Jack Dorsey et à l’origine de Square. Il ne cherche pas à construire encore un assistant IA de plus. Buzz crée un espace de travail commun où humains et agents utilisent les mêmes channels, threads, projets et protocoles. Un agent Codex peut créer un plan, Claude Code peut le critiquer, un humain peut prendre la décision et l’agent suivant peut en faire une modification dans le dépôt. Toute la chaîne reste visible dans le même espace.

Le raccourci « tueur de Slack » me semble trop réducteur. Buzz montre une forme de travail possible pour des équipes composées de nombreux agents. En même temps, il est encore jeune, gourmand en ressources et plus exigeant en matière de sécurité que sa surface conviviale ne le laisse penser. C’est justement ce mélange entre grande idée et stade de développement précoce qui rend un examen plus approfondi intéressant.

Le vrai problème n’est pas le modèle

La plupart des outils d’IA sont nés d’une relation entre un humain et un agent. J’ouvre Codex, je saisis une tâche et j’obtiens un résultat. Ensuite j’ouvre Claude Code, j’explique à nouveau le même contexte et je demande un second avis. Pour des tâches isolées, cela fonctionne bien. Mais dans une équipe ou avec plusieurs agents travaillant en parallèle, un nouveau problème de coordination apparaît.

Je connais exactement ce problème dans mon quotidien. Claude Code, Codex, Hermes, navigateur, discussions et différents terminaux tournent en parallèle. Les journaux de session migrent d’un outil à l’autre. Un agent connaît les notes de réunion, un autre le dépôt et un troisième les accès ou skills nécessaires. Chacun possède un fragment, mais personne l’état de travail commun.

Les tableaux de bord de mission control ne résolvent cela qu’en partie. Ils montrent peut-être que cinq agents sont actifs. Mais ils ne créent pas encore un lieu compréhensible en commun où mission, discussion, état intermédiaire, revue et décision restent réunis. Buzz ne s’attaque donc pas à une liste d’agents plus jolie, mais à l’espace de travail lui-même.

Les agents sont des membres, pas des bots collés

Au premier regard, Buzz paraît familier. Il y a des communautés, des channels publics et privés, des threads, des messages directs, des forums, une recherche, des huddles et une application mobile. La différence décisive avec une simple intégration Slack se trouve en dessous.

Dans Buzz, un agent est un membre à part entière. Il possède un profil, une paire de clés cryptographiques, des appartenances à des channels et sa propre piste d’audit. Ses messages apparaissent sous son identité. On peut ainsi voir non seulement que « l’IA » a fait quelque chose, mais aussi quel agent a agi, dans quel channel il a reçu la mission et quel humain ou autre agent l’a déclenché.

Cela ressemble d’abord à une petite modification de la gestion des utilisateurs. Mais pour un vrai travail, c’est central. Un bot Slack dépend en général d’une intégration et attend d’être mentionné par un humain. Deux bots de fournisseurs différents ne savent en général rien l’un de l’autre. Dans Buzz, les agents peuvent s’adresser à d’autres agents, se transmettre des tâches et discuter de leurs résultats dans le même thread. Codex et Claude Code ne deviennent pas pour autant un système unique. Mais ils obtiennent un espace de communication commun.

Buzz n’apporte pas automatiquement toute l’intelligence. L’espace de travail relie des « harnesses » et modèles qui tournent déjà localement, sur un serveur ou via un fournisseur. Selon l’état actuel du projet, cela inclut notamment Codex, Claude Code et Goose. D’autres agents peuvent être connectés via des interfaces ouvertes. C’est un modèle « bring your own agent » : Buzz coordonne, l’agent respectif pense et agit avec ses propres outils, skills, accès et coûts de modèle.

Le relay est l’état de travail commun

Techniquement, Buzz se compose de plusieurs éléments. L’application de bureau est l’interface. Une communauté est l’espace de travail proprement dit. Le Buzz Relay stocke et distribue ses messages, membres, agents, règles, médias, données de recherche, workflows et événements Git. Les agents peuvent travailler sur la même machine que l’application de bureau, sur un serveur qui tourne en permanence ou sur une machine totalement différente.

Comme protocole, Buzz utilise Nostr. Humains et agents signent des événements avec leurs clés privées. Le relay vérifie l’identité et l’appartenance, stocke les events et les distribue aux clients autorisés. Cela ne fait cependant pas de Buzz un réseau pair-à-pair magique. Le relay est la source centrale d’une communauté. Il n’y a pas de réplication automatique entre relays, et les messages restent sur le relay où ils ont été envoyés.

Cette construction a deux conséquences intéressantes. L’identité n’appartient pas simplement à un compte Slack central, mais repose sur une paire de clés propre. En même temps, une équipe peut exploiter l’espace de travail elle-même. Qui veut d’abord simplement tester peut utiliser une communauté hébergée par Block. Qui veut contrôler lui-même le stockage des données, la disponibilité et la sauvegarde exploite le relay sur sa propre infrastructure.

L’architecture serveur actuelle utilise des composants connus : PostgreSQL pour les events et la recherche en texte intégral, Redis pour le pub/sub, ainsi qu’un stockage compatible S3 pour les médias. Ce n’est pas un petit service qu’on peut oublier après l’installation. Un relay auto-hébergé a besoin de TLS, de mises à jour, de sauvegardes, de surveillance et d’une gestion propre des clés.

Pourquoi le contexte commun est si précieux

L’idée la plus forte de Buzz est le contexte durable et visible en commun. Un projet ne se compose plus d’un message dans Slack, d’une exécution d’agent séparée, d’une pull request sur GitHub et d’une décision prise en visioconférence. Buzz tente de réunir ces traces dans un espace d’événements.

C’est particulièrement utile quand différents agents ont des forces différentes. Un déroulement réaliste peut ressembler à ceci :

1. Un humain décrit l’objectif et les limites dans le channel du projet.
2. Un agent de recherche collecte des informations et documente ses sources.
3. Un deuxième agent attaque les points faibles et cherche des contre-arguments.
4. Codex ou Claude Code crée un plan concret.
5. Un autre agent vérifie le plan pour la sécurité, des tests manquants ou des hypothèses peu claires.
6. Après validation humaine, la modification est mise en œuvre dans un worktree séparé.
7. Diff, résultats de tests, revue et décision restent retrouvables dans le channel concerné.

Ce schéma est particulièrement intéressant pour les revues adversariales. Un modèle reçoit expressément le rôle d’attaquer un plan produit ou une implémentation. Un deuxième modèle doit défendre ou améliorer les décisions. Comme les deux voient le thread complet, une véritable confrontation avec l’état de travail existant se met en place, et non un simple review isolé d’un texte copié.

Ce schéma est également intéressant pour les processus de contenu et d’affaires. Un agent recherche des sujets, un deuxième écrit, un troisième corrige. Des chiffres clés ou de nouvelles informations peuvent affluer régulièrement dans un channel afin que humains et agents puissent discuter ensemble de l’évolution. Les huddles vont encore plus loin : humains et agents parlent dans une conférence audio, la conversation est transcrite en texte et peut ensuite se transformer en tâches concrètes.

C’est le point où Buzz devient plus qu’un simple chat de groupe. Le channel n’est pas seulement un lieu de communication. Il devient un journal de travail traçable.

Buzz veut aussi remplacer GitHub

Buzz intègre dépôts Git, patches, revues et événements de statut dans le même espace de travail. Le relay peut héberger lui-même des dépôts. Les agents peuvent utiliser des worktrees, travailler séparément sur des variantes, fournir des modifications sous forme de patch et discuter des revues dans le contexte du projet.

La vision derrière cela est forte : une branche de fonctionnalité devient un espace. On y trouve non seulement les commits, mais aussi la discussion sur les raisons pour lesquelles une modification était nécessaire, les alternatives écartées, ce que la CI a signalé et qui a validé le merge. C’est précisément cette histoire de création qui manque souvent aujourd’hui pour le code généré de façon agentique.

Néanmoins, je ne rayerais pas GitHub trop vite de la carte. GitHub n’est pas seulement un stockage Git, mais un écosystème mûri pendant des années pour les droits, les revues, la CI/CD, les scans de sécurité, les releases, les intégrations et la collaboration externe. Buzz possède des bases Git fonctionnelles et une approche de forge intéressante. Mais l’état actuel du projet distingue clairement les parties déjà fonctionnelles, les fonctions encore en cours de câblage et la vision. Pour des dépôts critiques, un déploiement progressif est plus raisonnable qu’une migration immédiate.

Mon premier test avec Buzz

J’ai délibérément commencé petit : une communauté propre, un channel et deux agents aux rôles clairement séparés. Codex devait créer un plan technique, Claude Code devait attaquer les hypothèses, les failles de sécurité et la complexité inutile. Les identifiants de production, les données clients et les dépôts sensibles sont restés à l’écart. Je voulais d’abord tester la collaboration, pas l’autonomie maximale.

La première mission ouverte était trop imprécise. Les deux agents ont commencé à planifier, à réagir l’un à l’autre, et à un moment attendaient la prochaine impulsion. C’était un bon rappel qu’un channel commun ne remplace pas encore une orchestration. Avec une instruction claire du type « Codex crée le plan, Claude le vérifie, ensuite vous attendez une validation », le déroulement est devenu nettement plus calme et traçable. Davantage d’agents ne remplace pas une définition de processus.

Ce qui m’a le plus convaincu n’est pas une réponse isolée spectaculaire, mais l’absence de rupture de support. Les deux agents voyaient le même thread, la critique restait à côté du plan initial, et je pouvais à tout moment suivre qui travaillait. Je n’ai eu à copier aucun texte entre fenêtres ni à réexpliquer l’historique à un second agent. C’est précisément là, pour moi, que se situe la vraie valeur de Buzz.

Pour un développement logiciel intensif, le travail direct dans Codex ou Claude Code est resté malgré tout plus rapide. Buzz ajoute communication, journalisation et contexte commun. Cette couche coûte du temps et des tokens. Chaque agent supplémentaire possède sa propre session, et un historique de channel volumineux peut être traité plusieurs fois avec plusieurs modèles. Pour une longue session de code, je continuerais donc à utiliser le harness natif et à réserver Buzz plutôt à la planification, aux transmissions et aux revues.

Je n’ai pas encore testé en profondeur les workflows, les huddles plus longs, les modèles locaux et plusieurs agents distants tournant en permanence. C’est précisément là que Buzz doit prouver au quotidien que les tâches ne sont pas seulement joliment visibles, mais aussi menées à bien de façon fiable. Le logiciel est avant la version 1.0 et paraît en conséquence jeune à certains endroits. Pour des expérimentations, c’est tout à fait acceptable. Mais les processus centraux ont toujours besoin de contrôle, de logique de reprise et d’un chemin de retour manuel clair.

Le contexte commun est aussi une frontière de sécurité

Ce qui rend Buzz utile élargit en même temps la surface d’attaque. Un agent Codex, Claude Code ou Hermes connecté apporte potentiellement un accès aux fichiers, un shell, un navigateur, des serveurs MCP, l’e-mail, le calendrier ou d’autres outils internes. Si un membre de l’équipe peut s’adresser à cet agent, le droit va bien au-delà de la simple rédaction d’une réponse dans le chat.

La règle la plus importante est donc : un agent ne doit travailler que dans des channels dont le contenu et les membres correspondent à son accès aux outils. L’appartenance au channel est la porte d’accès centrale. Qui est membre peut lire et écrire. Qui n’est pas membre ne devrait ni voir les channels privés ni pouvoir s’abonner à leurs events.

Les signatures cryptographiques ne résolvent pourtant pas tout problème d’audit. Buzz tient un journal d’audit chaîné, où toute manipulation devient visible. Un attaquant disposant d’un accès en écriture à la base de données pourrait toutefois recalculer la chaîne après une manipulation. Le journal est donc tamper-evident, pas tamper-resistant. Il rend les modifications repérables, tant que la base de confiance du stockage n’est pas totalement compromise.

Pour les communautés hébergées par Block, un point supplémentaire s’ajoute : les messages, messages directs et médias téléversés ne sont pas chiffrés de bout en bout. Block peut consulter ces contenus pour l’exploitation, la sécurité, la modération ou des obligations légales. De plus, le fournisseur de modèle respectif peut recevoir les prompts et le contenu des channels lorsqu’un agent utilise un service cloud.

L’auto-hébergement modifie la souveraineté des données, mais pas automatiquement l’ensemble du flux de données. Un relay propre garde messages et fichiers sur sa propre infrastructure. Si l’agent continue d’utiliser un modèle cloud, les données nécessaires à la mission quittent tout de même le relay. Une exploitation vraiment locale exige donc à la fois un relay propre, des modèles locaux et des outils locaux. J’ai déjà écrit séparément sur les possibilités et limites de Buzz Shared Compute.

Comment j’utilise Buzz pour l’instant

Pour mon premier test, j’ai utilisé une petite communauté clairement délimitée. Aucun identifiant de production, aucune donnée client et aucun dépôt contenant des secrets. Deux agents suffisaient amplement : l’un crée, l’autre vérifie. À cela s’ajoute moi, en tant qu’humain qui fixe la mission, le point de validation et le critère d’interruption.

Ma première configuration n’était pas une entreprise autonome avec cent agents, mais une revue limitée :

• Un agent crée un plan technique à partir d’une issue existante.
• Un deuxième agent cherche les failles de sécurité, les hypothèses manquantes et la complexité inutile.
• Les deux doivent citer sources, fichiers et questions ouvertes.
• Après au maximum deux tours de discussion, l’équipe attend une validation humaine.
• Ce n’est qu’ensuite qu’un agent peut préparer des modifications dans un worktree isolé.

Cela m’a permis de tester la véritable force de Buzz sans reconstruire immédiatement toute mon exploitation. En même temps, la consommation de tokens, la latence, les droits et la traçabilité sont devenus visibles.

Pour un travail solo avec une seule tâche de code, je reste sur l’interface d’agent directe. Elle est plus rapide et plus facile à contrôler. Buzz devient intéressant dès que plusieurs humains, plusieurs agents ou plusieurs flux de travail ont besoin du même contexte. Les petites équipes de développeurs, les agences, les groupes de recherche et les solopreneurs technophiles sont donc le public cible évident.

Pour une plus grande entreprise, je serais plus prudent. Avant la version 1.0, sans ligne de support à long terme et avec des workflows encore jeunes, je ne ferais pas de Buzz le seul lieu pour la communication critique ou le code source. Un projet pilote peut avoir du sens. Un remplacement complet de Slack et GitHub serait actuellement un pari sur la vitesse de développement du projet.

L’idée derrière Buzz est plus grande que le client actuel

La partie la plus fascinante de Buzz n’est pas pour moi une fonctionnalité isolée. Channels, forums, huddles, hébergement Git et modèles locaux existent aussi ailleurs. Ce qui est nouveau, c’est l’hypothèse assumée que les agents ne sont plus seulement des outils privés d’utilisateurs individuels. Ils deviennent des participants visibles d’un processus de travail commun.

Cela déplace la question. Nous ne demandons plus seulement quel modèle écrit le meilleur code. Nous devons décider comment humains et plusieurs agents répartissent les tâches, partagent le contexte, se contrôlent mutuellement et rendent la responsabilité traçable. C’est précisément là que manque souvent aujourd’hui l’infrastructure sociale et technique.

Buzz n’apporte pas encore de réponse achevée. Le logiciel est jeune, certains workflows sont peu fiables, le contexte commun peut devenir coûteux, et l’auto-hébergement implique une vraie responsabilité d’exploitation. Malgré cela, le projet touche un problème réel. Lorsque les agents prennent en charge toujours plus de travail, il ne suffit plus d’ouvrir cinq chats individuels côte à côte. Nous avons besoin d’un lieu commun où leur travail reste visible, limité et vérifiable.

Buzz remplacera peut-être un jour Slack et GitHub. Pour aujourd’hui, une affirmation plus modeste mais plus importante suffit : Buzz est une esquisse convaincante de ce à quoi peut ressembler un espace de travail lorsque ce ne sont plus seulement des humains qui y travaillent. Le Shared Compute m’a fait découvrir le projet. L’espace de travail commun est la raison pour laquelle je continuerai à tester Buzz.

Mon bilan après le premier test

Buzz a touché exactement, lors de mon court test, le problème que je rencontre actuellement avec les agents IA. Les modèles individuels ne sont plus depuis longtemps le goulot d’étranglement. Ce qui est difficile, c’est de maintenir plusieurs agents, décisions et résultats sur une même ligne. Buzz rend ce travail visible et donne à Codex, Claude Code et aux autres agents un lieu où ils peuvent réagir non seulement à moi, mais aussi les uns aux autres.

Ce qui m’a convaincu, c’est le contexte commun, les identités d’agents clairement séparées et la possibilité de faire attaquer directement un résultat par un second modèle. Ce qui m’a moins convaincu, c’est la charge supplémentaire. Pour une seule tâche de code, le chemin direct via Codex ou Claude Code reste plus rapide. Dès que plusieurs agents ou humains sont impliqués, Buzz commence à déployer sa force.

Mon test était volontairement court. Je n’ai vérifié ni une exploitation d’équipe durable, ni de grands dépôts, ni des workflows complexes, ni des pics de charge plus longs. Le logiciel est encore trop jeune et évolue trop vite pour cela. Je ne ferais pas aujourd’hui de Buzz le seul lieu pour la communication critique ou le code source. Mais pour une petite équipe, une agence ou un labo IA personnel, c’est déjà plus qu’une démo intéressante. C’est un outil que je veux continuer à utiliser et intégrer de façon ciblée dans mon quotidien de travail.

À la prochaine,
Joe

FAQ