Buzz Jack Dorsey: workspace humains et agents IA (buzz.xyz)

Buzz Jack Dorsey en une phrase

Buzz (buzz.xyz) est un workspace open source, annoncé le 21 juillet 2026 par Block, où humains et agents IA partagent les mêmes canaux, threads et permissions, plutôt que de coller le résultat d'un agent dans Slack.

Si tu cherches « Buzz Jack Dorsey », tu tombes surtout sur des annonces. Ici, on détaille qui l'a construit, comment l'installer, ce que les agents peuvent faire concrètement, ce qu'on en a tiré en prise en main, et ce que tu dois figer en PME avant d'y coller des agents en production.

Qui a créé Buzz ?

Buzz est un produit de Block (ex-Square), la société de Jack Dorsey, aussi connue pour Cash App et son investissement dans l'open source IA (dont goose). L'annonce officielle est sur le blog de Block: Introducing Buzz: where humans and agents work together.

Jack Dorsey porte le lancement dans la presse: TechCrunch et d'autres le présentent comme un concurrent potentiel de Slack sur la collab augmentée d'agents. Buzz n'a rien d'un side-project anonyme: Block en fait une brique stratégique sur l'infrastructure d'agents.

Côté produit, Bradley Axen (Head of AI Capabilities chez Block) résume le pari: chaque entreprise aura besoin d'un lieu où humains et agents travaillent ensemble, et la question est de savoir si ce lieu sera propriétaire ou ouvert. Block a construit Buzz pour le second camp.

La licence annoncée est Apache-2.0, avec le code sur github.com/block/buzz. L'hébergement passe par buzz.xyz en version gérée, ou par une instance self-host. Le choix de l'open source porte l'argument central du projet: sortir du lock-in des plateformes d'agents propriétaires.

Pourquoi Buzz a été créé

Block dit avoir open-sourcé des outils IA pendant deux ans, puis constaté un pattern: le travail productif n'arrive pas quand quelqu'un « demande de l'aide à l'IA » dans son coin. Il arrive quand humains et agents sont dans la même pièce, sur la même tâche, avec le même contexte. Aucune plateforme n'était conçue pour ça, donc Block en a bâti une.

Le second « pourquoi » est structurel. Beaucoup d'entreprises construisent leur stack agents dans des plateformes propriétaires, avec des règles d'accès, des modèles autorisés et des formats de conversation imposés par le vendeur. Cette dépendance fragmente l'organisation. Buzz veut un standard ouvert de collab humains/agents, comme le code qu'on versionne soi-même.

Le troisième « pourquoi » est l'identité. Buzz s'appuie sur Nostr: chaque participant, humain ou agent, détient une paire de clés crypto qui lui appartient, pas un compte plateforme. L'identité de l'agent ne se résume plus à une API key du vendeur: elle est portable et vérifiable. Sans identité propre, un agent reste un plugin collé à un SaaS.

En pratique, l'objectif est d'arrêter le copier-coller permanent entre le terminal d'agent (Claude Code, Codex, goose) et le chat d'équipe (Slack), et de réunir la conversation, le code et les agents sous un relais que tu peux contrôler.

Ce que fait Buzz (fonctionnellement)

L'interface est familière: des canaux, des threads, des DMs, de la voix, des médias, de la recherche. S'y ajoutent des dépôts Git encore early et des workflows automatisés. Les agents n'y sont pas des assistants one-shot dans un panneau latéral: ils ont des permissions, peuvent poster, revoir du code, lancer des automatisations approuvées, et travailler à plusieurs avec plusieurs humains sur le même fil.

Buzz se présente comme model-agnostic et agent-agnostic: Claude Code, Codex, goose, un modèle local ou un harness maison. Le workspace ne prescrit pas le moteur. Il prescrit le lieu et les règles d'accès aux outils (le CRM, le repo, les fichiers) que l'équipe configure.

Dans le détail, voilà ce qu'un agent peut faire nativement via le protocole et la CLI, au-delà du chat:

Le lien entre la conversation et le code mérite un arrêt. Une pull request Buzz porte la référence du canal d'origine: la traçabilité entre la décision, la discussion et le patch est native, sans outil externe à brancher.

Ça reste une surface de collab, sans magie: la qualité dépend toujours du harness, du modèle, des permissions et de ta policy d'approbation.

Où s'exécute quoi: l'architecture en clair

La question revient dans toutes les discussions sérieuses sur Buzz: où s'exécute quoi, et qui voit quoi. La réponse tient en deux plans. Le relay, le serveur Nostr qui stocke et distribue les messages, est hébergé: chez Block en version gérée, ou chez toi en self-host. Les agents, eux, tournent sur la machine où leur runtime est installé, en général ton poste via Buzz Desktop.

Quand tu demandes à un agent de modifier du code, il travaille donc sur le disque de sa machine hôte: ses fichiers, son terminal, son checkout git. Rien ne s'exécute sur une instance partagée chez un tiers. Seuls les messages, signés par leurs auteurs, transitent par le relay.

Machine hôte éteinte, les agents passent hors ligne, mais la communauté continue de vivre. Le chat reste accessible, l'historique reste lisible, et les mentions s'accumulent sur le relay sous forme d'événements. Au redémarrage, l'agent rattrape ce qui l'attend et reprend le travail. Une demande postée pendant la nuit sera traitée au réveil de la machine.

Pour des agents disponibles en continu, deux options existent. Tu empêches la machine hôte de dormir, ou tu déplaces le runtime sur une machine toujours allumée: un Mac mini de bureau, ou un VPS Linux en headless. On détaille ce chemin dans la section installation.

Installer Buzz: trois chemins

En pratique, l'installation dépend de ce que tu veux posséder. On distingue trois chemins, du plus simple au plus autonome, cumulables dans le temps.

Chemin 1, le poste de travail. C'est celui qu'on recommande pour un premier essai, sans serveur à gérer.

1. Télécharge le client Desktop depuis les releases du dépôt GitHub: un .dmg sur macOS, un .AppImage ou un .deb sur Linux, un .exe sur Windows.
2. Installe l'app, puis crée ta communauté ou rejoins-en une existante avec l'URL de son relay.
3. Ajoute ton premier agent depuis l'app: Desktop résout le runtime, le provider de modèle et les valeurs par défaut.

En version gérée, ta communauté vit sur un relay hébergé par Block (la nôtre tourne sur un sous-domaine de communities.buzz.xyz). Tu n'as rien à maintenir côté serveur.

Chemin 2, le relay self-host. Il sert à posséder toute la chaîne, messages compris. Le dépôt fournit un bundle Docker Compose de production dans le dossier deploy/compose, avec Postgres, Redis, MinIO et un Caddy optionnel pour le TLS. Pour un environnement de développement local, la séquence documentée est courte: cloner le dépôt, activer Hermit, lancer « just setup » puis « just build », et démarrer avec « just dev ». Le relay écoute alors sur ws://localhost:3000. Les prérequis annoncés sont Docker et Hermit, ou à défaut Rust 1.88+, Node 24+, pnpm 10+ et l'outil just.

Chemin 3, les agents headless sur serveur. Le runtime d'agents n'a pas besoin de l'interface graphique. Le harnais buzz-acp fait le pont vers Claude Code, Goose ou Codex, et buzz-cli expose toutes les opérations en JSON, pensé pour les tool calls d'un LLM. L'authentification passe par des variables d'environnement, dont la clé Nostr privée de l'agent. Sur un VPS Linux, tu obtiens des agents joignables 24/7, qui travaillent alors sur le disque du serveur (un clone git de tes projets) plutôt que sur ton poste.

Pour choisir, la grille est simple:

Ajouter et créer des agents

Un agent Buzz a une identité propre: une paire de clés Nostr, un nom, un system prompt, des permissions. Tu l'ajoutes depuis Buzz Desktop, qui règle le harnais, le provider et le modèle par défaut. Les moteurs restent interchangeables, et un même canal peut mélanger des agents motorisés différemment.

Le détail que peu de briefs mentionnent: un agent peut préparer la création d'un autre agent, en conversation. Tu écris « crée-moi un agent qui rédige mes brouillons SEO », l'agent ouvre un brouillon de configuration, et Desktop te le présente pour relecture. Rien n'existe tant que tu n'as pas validé. Comparé à un bot Discord ou Slack, il n'y a ni application à enregistrer, ni token à générer, ni écran OAuth à cocher.

Une communauté héberge plusieurs agents sans friction particulière. Chez nous, trois agents cohabitent dans les mêmes canaux et se passent le travail par mention, comme entre humains. Chacun garde une mémoire persistante de ses projets entre les sessions: le contexte n'est pas à rebriefer à chaque conversation.

Invités, accès et sécurité

Inviter quelqu'un dans ta communauté ne lui donne pas la main sur tes agents. Par défaut, un agent n'obéit qu'à son propriétaire: un invité lit ses réponses et discute dans les canaux, mais ne peut pas lui commander du travail. L'élargissement d'accès est un choix explicite, réglé agent par agent.

Si tu ouvres cet accès, mesure ce que ça implique: les demandes de l'invité s'exécutent sur la machine hôte de l'agent, avec les permissions de l'agent. La pratique qu'on applique chez kengdev: les agents qui touchent au code restent réservés au propriétaire, et un agent séparé, au périmètre réduit et sans accès disque sensible, peut servir les invités.

Les garde-fous techniques complètent la policy. Un agent travaille sur une branche dédiée et livre en pull request: rien n'atterrit sur la branche principale sans un merge humain. Chaque message est signé par la clé de son auteur, humain ou agent, ce qui rend l'historique auditable. Les permissions d'outils, elles, se règlent individuellement dans Desktop.

Notre prise en main (kengdev)

On a ouvert un workspace Buzz et branché un agent dans un canal type Welcome. Le premier réflexe a été une question banale, pour voir si l'agent se comporte comme un collègue de fil plutôt que comme un chat latéral. On lui demande: « donne-moi des exemples de ce que tu peux faire ».

La réponse arrive dans le thread, structurée (dev, recherche, contenu, design, automatisation), avec des phrases d'amorçage et une invitation à préciser le gain de temps attendu. Aucun panneau magique hors contexte: le travail se voit là où l'équipe lit déjà. C'est le premier « ah »: on délègue par mention, comme à un humain, avec un fil que n'importe qui peut relire après.

En creusant, on retrouve le même ressenti que d'autres prises en main sérieuses du produit: Buzz ne se résume pas à « un autre chatbot dans Slack ». C'est plutôt un mix familier (des canaux et des threads type messagerie d'équipe), une couche d'agents first-class (l'identité, l'historique, la délégation) et un harness au choix (Claude Code, Codex, goose, des modèles locaux). L'agent peut s'appuyer sur un harness, choisir un modèle et, dans les scénarios plus avancés, déléguer et travailler en parallèle, worktrees git inclus.

Ce qu'on aime vraiment à l'usage: tagger l'agent et le voir répondre dans le fil, avec des mises à jour de statut quand il avance (il compile, il commit, il déploie), reste naturel. Le fil devient un brief pour le reste de l'équipe, et on n'a plus à reconstituer un transcript terminal pour expliquer ce que l'agent a fait. Le compute partagé (un relais ou une machine plus costaude mise à disposition d'une communauté) et l'ancrage Nostr (une identité portable, une piste Lightning pour des micropaiements de compute à terme) séparent aussi Buzz d'un simple agent manager collé à un SaaS fermé.

Ce qui freine encore, et ça se voit dès les premières sessions: on ne voit pas le terminal de l'agent. Une vue d'activité existe, mais si tu as l'habitude de regarder une session Claude Code défiler, l'UI de Buzz reste abstraite. On a aussi eu l'impression, sans mesure stricte, que les allers-retours sont plus lents qu'une session locale dans le harness: pour les one-shot, on retombe instinctivement sur le terminal. Dernière limite: on aimerait plus de contrôle sur la session backend, pour réutiliser le même id de session avec le même agent, rejouer, inspecter. Sans ça, l'intégration à plein temps dans le flux d'une équipe reste hésitante.

Le verdict interne après cette prise en main: on aime le modèle et on peut imaginer travailler en équipe comme ça. Pour des tâches moyennes (le cadrage, les explications, les petits lots, les status partagés), Buzz est déjà pertinent. Pour les gros chantiers complexes, il ne fait pas encore socle unique. Le différenciateur long terme (le compute partagé, l'identité ouverte, le fil commun) est réel, mais le produit reste early. On garde Claude Code et Codex pour le deep coding, et on utilise Buzz pour la collab visible multi-humains multi-agents, avec une policy d'approbation écrite avant d'élargir le périmètre.

Trois cas d'usage qu'on pratique

Le pipeline de contenu, du brief au déploiement. Tu mentionnes l'agent avec un sujet d'article. Il fait la recherche de mots-clés, rédige dans la voix du site, ouvre une pull request reliée au fil, et te la signale. Tu relis, tu merges, l'hébergeur déploie. Cet article même a suivi ce chemin: la demande de compléments est partie d'un fil Buzz, et la PR est revenue dans le même fil. Le brief, la discussion et le code partagent une seule trace.

La relecture croisée entre agents. Un agent rédige, un second relit avant la pull request, dans le même thread. Les objections et les choix restent visibles pour l'équipe, au lieu de disparaître dans une session de terminal privée. Le pattern vaut pour le code comme pour le contenu.

Les routines qui tournent sans toi. Une veille quotidienne qui poste son rapport dans un canal dédié, un récapitulatif hebdomadaire des données Search Console, un brouillon d'article planifié chaque semaine selon le calendrier éditorial. L'humain reste le point de merge: les routines proposent, tu valides. C'est le scénario qui justifie, à terme, de déplacer les agents sur une machine allumée en continu.

Ce que les briefs FR ne disent pas assez (PME)

Beaucoup de contenus FR se contentent de résumer: « Jack Dorsey sort Buzz, open source, agents membres, Nostr ». Tout cela est vrai, et insuffisant pour décider.

Ce qui manque le plus souvent: le contrat d'approbation (HITL), la cartographie des secrets et des écritures, le partage des rôles entre le terminal et le workspace, et la différence entre un chat multi-agents et un agent ops packagé sur un process métier (les devis, le support, le CRM).

Si tu pilotes une PME, pose trois questions avant de céder au FOMO:

1. Où tourne le relais et qui lit les logs ?
2. Quelles actions l'agent peut-il faire sans clic humain ?
3. Que se passe-t-il si Buzz ou le harness plante en plein sprint ?

Tant que ces réponses ne sont pas écrites, la migration reste une démo sociale.

Garde-fous avant d'y coller des agents

Une page de policy suffit pour démarrer: les actions automatiques (le format, le lint, le résumé), les actions qui demandent un clic (un push sur main, un secret, une migration), et les actions interdites (la prod live, le paiement, la suppression large). Versionne-la comme du code.

Cartographie ensuite les flux: les clés API, les outils branchés, les données client, la rétention des threads. L'open source et le self-host ne remplacent ni une lecture RGPD ni un least-privilege réel.

Sépare enfin les usages: le deep coding dans un harness terminal, la collab visible (la revue, les status, les handoffs) dans un workspace type Buzz, et les ops métier récurrents avec une allowlist d'écritures. Chez kengdev, le pattern « la machine propose, l'humain valide » reste non négociable, quelle que soit l'UI.

Mesure le temps gagné et le taux d'escalade plutôt que le nombre de messages de l'agent. Plus de commits ne veut pas dire plus de valeur.

Buzz vs Claude Code, bot Discord, Hermès Ops

Chaque outil a son périmètre. Claude Code et Codex sont des harness d'exécution, forts sur le terminal et le patch. Buzz est une surface de collab multi-humains multi-agents, forte sur le contexte partagé et l'identité ouverte. Hermès Ops (le pack kengdev) est un agent ops branché sur la messagerie et les outils métier, avec les écritures critiques derrière confirmation humaine, sur un périmètre process plutôt qu'un chat généraliste.

La question du bot Discord revient aussi: pourquoi pas un agent type Hermes Agent greffé sur un serveur existant ? La différence est structurelle. Sur Discord, l'agent est un bot sur une plateforme centralisée: un compte applicatif à enregistrer, des intents à configurer, des données hébergées chez Discord, un gateway à maintenir. Sur Buzz, l'agent est un membre natif du protocole, avec sa propre clé, sur un relay que tu peux posséder. Si ton audience vit déjà sur Discord, le bot y garde du sens; pour un espace de travail dont tu contrôles les données, les deux ne jouent pas dans la même catégorie.

La grille de lecture qu'on utilise en cadrage:

Tu n'as pas à choisir un seul outil pour toujours: tu choisis un périmètre. Buzz pousse la « salle commune », et ça ne remplace ni un runbook de production ni une policy d'approbation.

Si vous voulez cadrer un premier agent sur un process réel (support, devis, ops), avec ou sans Buzz dans la boucle, on peut le faire en 20-40 minutes.

Questions fréquentes