Cet outil va probablement de résoudre le sujet du contexte en entreprise (et j'en suis vraiment fan)

Avant de commencer, une précision importante : Buzz.xyz est encore un projet early, en alpha, qui avance rapidement. Sa propre documentation distingue ce qui fonctionne aujourd’hui, ce qui est en cours de raccordement et ce qui relève encore de la vision. Il ne faut donc pas lire cette newsletter comme l’annonce d’un produit déjà mature.

Mais Buzz est intéressant pour une autre raison : il s’attaque à un problème que la plupart des outils actuels ne résolvent pas vraiment.

Les entreprises commencent à travailler avec des agents. Pourtant, leurs équipes, leurs conversations, leurs décisions, leur code et leurs agents restent organisés dans des espaces séparés.

Et plus on ajoute d’agents, plus cette fragmentation devient difficile à gérer.

Et cette problématique, c’est actuellement sur ce sujet précisément que je travaille actuellement pour aider des entreprises à mieux gérer leur travail avec des agents et leur contexte.

• C’est quoi Buzz ?

• Le problème du contexte éclaté

• Pourquoi ajouter des agents à Slack ne suffit pas

• Buzz comme espace de travail, pas seulement comme messagerie

• Des agents qui deviennent des membres de l’équipe

• Le rôle de l’identité, des permissions et de la gouvernance

• Du message à l’événement traçable

• Quand une conversation devient un processus de travail

• La mémoire de travail avec les Canvas

• Ce que Buzz change par rapport à Slack, GitHub et Discord

• Ce que cela peut changer concrètement pour une équipe

Buzz n’est pas un projet open source isolé lancé par quelques développeurs indépendants. Il est porté par Block, l’entreprise derrière Square, Cash App et d’autres produits technologiques, et son lancement public a été annoncé par Jack Dorsey le 21 juillet 2026.

Au moment où je vous présente le pojet, est à déjà plus de 2 000 commits, avec des releases et des évolutions très fréquentes. La réaction de la communauté open source est également très forte. Quelques repères publics donnent une idée de la courbe : environ 6 700 stars le 24 juillet, plus de 13 000 le 26 juillet, puis 22 751 stars le 5 août 2026, selon l’API GitHub.

Concrètement Buzz est un outil open source et auto-hébergeable, publié sous licence Apache 2.0. Son objectif est de créer un espace de travail dans lequel humains et agents peuvent collaborer au même endroit : échanger, consulter du contexte, modifier des fichiers, lancer des workflows et suivre les décisions.

Techniquement, Buzz fonctionne avec Nostr, un protocole d’événements signés. Ces événements sont transmis et conservés par un relay, c’est-à-dire l’infrastructure qui fait circuler les messages et les actions du workspace. Tu peux utiliser un relay existant ou héberger le tien, avec davantage de contrôle sur tes données et ton environnement.

L’idée centrale est donc simple : Buzz n’est pas seulement une application de messagerie. C’est un workspace construit autour d’un relay, où les conversations, les agents, les workflows, les événements Git et l’historique du travail peuvent être réunis dans un même espace.

Dans une entreprise classique, le travail est rarement contenu dans un seul outil.

Une décision peut commencer dans une réunion, être précisée dans Slack, transformée en ticket dans Jira, implémentée dans GitHub, documentée dans Notion, puis commentée dans un email.

Quelques semaines plus tard, quelqu’un retrouve le résultat final, mais plus forcément la raison du choix.

Le code existe. Le ticket est fermé. Le document est à jour.

Mais le contexte a disparu.

Slack       → conversations
GitHub      → code et pull requests
Notion      → documentation
Jira        → tâches
Email       → échanges externes
CI/CD       → résultats techniques
Interfaces IA → conversations avec des agents

Le problème n’est pas seulement le nombre d’outils. C’est le fait qu’aucun d’entre eux ne possède vraiment la continuité du travail.

Or cette continuité devient encore plus importante lorsque des agents interviennent.

Un agent peut résumer une discussion, modifier un fichier, lancer des tests ou proposer une réponse. Mais si son action est séparée du contexte, de la décision et de la validation, l’entreprise obtient surtout une nouvelle couche de fragmentation.

La première réaction consiste souvent à ajouter un bot dans Slack.

C’est utile pour commencer, mais cela ne règle pas le problème de fond.

Un bot dans un channel reste généralement un acteur périphérique :

• il répond à une demande ponctuelle ;

• il utilise un contexte partiel ;

• il produit une réponse dans un flux qui se perd rapidement ;

• il n’a pas toujours une identité ou des permissions clairement séparées ;

• son action est rarement reliée à toute la chaîne de travail.

• Et même si un Agent peut accéder à tout votre Slack, ce n’est pas vous qui détenez votre contexte (c’est Slack...)

Le sujet n’est donc pas simplement :

Comment faire répondre un agent dans notre outil de communication ?

La vraie question est plutôt :

Comment faire travailler un agent dans le même environnement que l’équipe, avec le bon contexte, les bons accès, des étapes visibles et une validation traçable ?

C’est à cet endroit que Buzz devient intéressant.

Le dépôt officiel décrit Buzz comme un workspace où les humains et les agents construisent ensemble, sur un relay que l’on possède. Une communauté Buzz est accessible par une URL et rassemble les échanges, les agents, les workflows, les événements Git et la mémoire du projet. Buzz ne veut pas héberger tous les agents. Il veut être l’endroit où les agents sont identifiés, reçoivent leur travail et rendent leurs résultats.

Buzz a la tête d’une messagerie, mais la différence avec une messagerie est importante.

Dans Buzz, un channel ne sert pas uniquement à discuter. Il peut aussi accueillir :

• des agents ;

• des documents ;

• des Canvas ;

• des fichiers ;

• des workflows ;

• des événements Git ;

• des validations ;

• des résultats d’exécution.

Le channel devient progressivement un espace de travail autour d’un sujet, d’un projet ou d’une décision.

Ce n’est plus seulement :

“Parlons du problème ici.”

Mais plutôt :

“Le problème, son contexte, les propositions, le code,
les tests et la décision finale vivent ici.”

La documentation actuelle de Buzz présente cette idée comme une ambition en construction, avec plusieurs briques déjà disponibles et d’autres encore en cours de raccordement. README officiel de Buzz

P.S. : on y reviendra dans de prochaines édition, mais le frontend de Buzz est ultra personnalisable. Ici, ça a la tête d’une messagerie “à la Slack”, mais vous pouvez envisager d’autres type de frontends. On y reviendra, parce que ce point-là est très loin d’être négligeable à la fois en termes métier et en termes business.

Dans la plupart des logiciels, un agent est une capacité invisible : on clique sur un bouton, on obtient une réponse, puis l’agent disparaît.

Buzz propose une autre manière de le penser.

Un agent peut avoir :

• sa propre identité ;

• ses propres clés ;

• ses propres channels ;

• ses propres permissions ;

• sa propre activité ;

• son propre historique ;

• une spécialité définie.

On l’ajoute à un channel comme on ajouterait un collègue.

Cela change la nature de l’interaction.

Un agent SEO peut être présent dans les channels éditoriaux. Un agent support peut être limité aux demandes clients. Un agent technique peut travailler sur un repository précis. Aucun de ces agents ne devrait avoir accès automatiquement à l’ensemble de l’entreprise.

L’agent cesse alors d’être un chatbot généraliste placé à côté du travail. Il devient un participant du travail, avec un périmètre précis.

Faire travailler des agents est “relativement simple”.

Faire travailler des agents de manière contrôlée dans un environnement collaboratif d’entreprise est beaucoup plus difficile.

Une entreprise doit pouvoir répondre à des questions très concrètes :

• Quel agent a effectué cette action ?

• Quel contexte a-t-il consulté ?

• À quels fichiers avait-il accès ?

• Qui l’a autorisé à intervenir ?

• Quel humain a validé le résultat ?

• Quelle proposition a été refusée ?

• Peut-on retrouver la chaîne complète plusieurs mois plus tard ?

Dans Buzz, les humains et les agents utilisent le même modèle général d’identité et d’événements signés. Le but n’est pas de rendre les agents autonomes à tout prix, mais de rendre leur activité visible et contrôlable.

La gouvernance ne devrait donc pas être un document oublié dans un dossier de conformité. Elle devrait être intégrée dans le fonctionnement quotidien du workspace : membership des channels, permissions, workflows, approbations et historique.

Le dépôt insiste d’ailleurs sur un principe important : Buzz n’est pas présenté comme un plan de remplacement des humains. Le projet se décrit plutôt comme un espace où les humains restent dans la boucle et où les agents restent dans la pièce. README officiel

Buzz s’appuie sur Nostr, un protocole d’événements signés.

Dit simplement, un message n’est pas seulement une ligne de texte dans une base de données. Il est associé à une identité, à un type d’action et à une signature.

Dans cette logique, un événement peut représenter :

• un message ;

• une réaction ;

• une étape de workflow ;

• une approbation ;

• une modification Git ;

• une action d’agent ;

• une activité de projet.

L’intérêt est de pouvoir rechercher et relier les différentes traces du travail dans un même historique : la conversation, la proposition de l’agent, le patch, le résultat des tests et la validation humaine.

Le relay devient alors une mémoire opérationnelle du projet.

Ce choix distingue aussi Buzz d’une application de communication classique : la discussion n’est pas seulement destinée à être lue dans l’instant. Elle peut devenir une partie de l’historique du travail.

Pour une explication plus technique de cette architecture, le projet publie son document d’architecture et sa vision souveraine.

Prenons un exemple simple : un bug est signalé.

Dans beaucoup d’équipes, le parcours ressemble à ceci :

Message Slack
→ ticket Jira
→ discussion privée
→ branche GitHub
→ pull request
→ résultat CI
→ validation dans Slack
→ mise en production

Chaque étape existe, mais le lien entre elles est souvent fragile.

La vision de Buzz propose de rapprocher ces étapes :

Le bug est signalé
→ un espace de travail est ouvert
→ un agent analyse le contexte
→ une branche est créée
→ le patch est proposé
→ les tests sont lancés
→ un humain valide
→ la décision est conservée dans le même historique

Le channel n’est plus un endroit où l’on parle d’une branche. Il devient la pièce dans laquelle la branche, les échanges, les agents, les tests et la décision sont réunis.

La documentation de Buzz donne aussi des exemples de workflows de release et de recherche dans l’historique d’incidents. README de Buzz

Les messages sont utiles pour conserver l’historique, mais ils ne sont pas toujours le meilleur endroit pour conserver l’état actuel d’un projet.

C’est le rôle du Canvas.

Un Canvas peut servir à maintenir :

• l’objectif du channel ;

• les contraintes ;

• les décisions prises ;

• les informations importantes ;

• les prochaines étapes ;

• les ressources utiles.

La distinction est simple :

Messages
→ ce qui s’est passé
Canvas
→ ce qui est important maintenant

Les agents peuvent utiliser ce contexte partagé pour éviter de reconstruire toute l’histoire à partir de centaines de messages.

À terme, on peut imaginer que chaque sujet important dispose d’une discussion et d’une mémoire de travail structurée : la conversation reste vivante, tandis que le Canvas conserve les éléments stabilisés.

Cette distinction entre historique et état actuel est probablement indispensable dans les équipes qui travaillent avec plusieurs agents.

Buzz peut se connecter à différents programmes d’agents grâce à une architecture qui sépare plusieurs rôles.

Buzz
→ l’espace de travail
ACP
→ le protocole qui permet de dialoguer avec un programme agent
Runtime
→ l’environnement qui fait fonctionner l’agent
MCP
→ les outils que l’agent peut utiliser
Modèle
→ le moteur d’intelligence utilisé par le runtime

Une analogie :

• Buzz est le bureau ;

• l’agent est le collaborateur ;

• le runtime est son environnement de travail ;

• ACP est le standard téléphonique ;

• MCP est sa boîte à outils ;

• le modèle est son cerveau.

Cette séparation est importante parce que Buzz ne dépend pas nécessairement d’un seul modèle ou d’un seul fournisseur. Le dépôt mentionne notamment un harness ACP pour Goose, Codex et Claude Code, ainsi qu’un buzz-cli conçu pour les appels d’agents en JSON. Architecture et README de Buzz

Dans mon cas, j’ai plusieurs agents branchés à Codex (mon abonnement) avec des personnalités différentes que j’appelle dans différentes channels.

Slack organise principalement la conversation.

GitHub organise principalement le code.

Discord organise principalement la communauté et la présence sociale.

Buzz cherche à organiser la continuité du travail entre ces différents éléments.

Slack
→ Où parle-t-on de ce sujet ?
GitHub
→ Quel code a été produit ?
Discord
→ Comment faire vivre une communauté ?
Buzz
→ Quel est le contexte, qui agit, quelles sont les étapes,
   qui valide et pourquoi la décision a-t-elle été prise ?

Cela ne signifie pas que Buzz remplace déjà chacun de ces outils.

Cela signifie que sa philosophie est différente : au lieu de juxtaposer des applications spécialisées, Buzz essaie de faire reposer conversations, agents, workflows, Git et historique sur un même relay et un même modèle d’identité.

Bref, comme je le dis depuis un certain temps, le contexte est un véritable actif pour une entreprise et il faut savoir l’organiser. Je crois véritablement que Buzz est un projet qui coche les cases de ce qu’on attendrait en entreprise pour organiser ce contexte.

Si cette vision fonctionne, le changement le plus important ne sera pas l’arrivée d’un nouveau chatbot.

Ce sera la possibilité de faire évoluer l’organisation autour d’un nouvel objet : le travail partagé entre humains et agents.

Un travail pourrait être décrit ainsi :

Un objectif
+ un contexte partagé
+ des humains identifiés
+ des agents spécialisés et bien identifiés
+ des outils accessibles
+ des permissions explicites
+ un workflow
+ une validation
+ un historique durable

Cela peut rendre les agents plus utiles, parce qu’ils ne travaillent plus dans des conversations isolées.

Cela peut aussi les rendre plus sûrs, parce que leurs actions, leurs accès et leurs validations sont visibles.

Et cela peut améliorer la mémoire de l’entreprise, parce que les décisions ne sont plus obligées de disparaître entre un message, un ticket et une pull request.

Buzz est encore en phase alpha pour l’heure (0.5.5 pour l’heure). Il reste encore des sujets importants à résoudre jusqu’à la version 1.0 : l’onboarding, la gestion des clés, la maturité de certaines fonctions, l’hébergement, les sauvegardes et la validation de scénarios réellement persistants notamment.

Mais son intuition est forte : les entreprises ne vont pas seulement devoir apprendre à utiliser des agents. Elles vont devoir leur donner un espace de travail, un contexte, des permissions et une gouvernance.

Buzz essaie de construire cet espace.

Pas seulement une messagerie avec de l’IA.

Pas seulement un outil de développement.

Un workspace où humains et agents peuvent travailler dans la même pièce, avec la même mémoire de travail et une trace de ce qui a été fait.

Le projet est encore jeune et je n’ai pas encore pu insister sur plein d’autres points vraiment intéressants qui distinguent Buzz. Mais je pari fortement sur ce projet qui coche beaucoup de cases.

Comme tu l’auras peut-être compris / senti, je suis vraiment emballé par ce projet qui va constituer une part importante de mon travail à la rentrée pour continuer de te montrer des cas d’usages de ce projet et plus largement l’impact du contexte en entreprise.

J’ai plein de projets prochainement et des entreprises commencent à me contacter pour parler de contexte donc je pense que les choses vont s’affiner à la rentrée.

Je suis ouvert à toute discussion pour faire avancer les choses !

Hâte de t’en dire plus.

Ce sujet t’a intéressé ? Tu as des questions ou un projet ? Répond simplement à cet email.

Si cette édition t’a apporté quelque chose, le meilleur coup de pouce que tu puisses me donner, c’est de la partager à quelqu’un qui en ferait quelque chose 👇

Partager

Tu peux aussi me retrouver sur LinkedIn pour suivre ce que je construis en dehors des éditions.

Bonne semaine de vacances,

— Milan