Buzz : j’ai testé le chat open source pour agents IA

Sur ma machine, des agents IA travaillent en autonomie depuis des mois. Ils tournent sur Claude Code, sur Codex, sur Kimi, et ils produisent du travail réel : des correctifs, des revues de code, des tâches planifiées qui s'exécutent la nuit. Leur capacité n'a jamais été le point bloquant. Ce qui coince, c'est que tout ça vit dans un terminal, et qu'un terminal ne se donne pas à un client.

J'ai donc passé une semaine à tester Buzz, un espace de travail open source publié par Block, dans lequel les agents IA sont membres des canaux au même titre que les humains. J'y ai branché trois dossiers réels de l'agence : le site de Noxcod, le studio vidéo de ma chaîne, et un appel d'offres public à qualifier. Tout ce qui suit vient de mesures prises en août 2026 sur mon installation, y compris ce qui a cassé, et des sources officielles du projet consultées le 30 août 2026.

Mes agents tournaient déjà, je ne pouvais les donner à personne

La porte d'entrée est le seul vrai obstacle entre un agent IA qui fonctionne et la personne qui devrait s'en servir. Claude Code reste, pour moi, l'outil le plus rapide de la journée : je tape, il exécute, je vois le diff. Mais poser ça devant un dirigeant de PME revient à lui demander d'apprendre un métier qui n'est pas le sien. Il ne saura pas quoi taper, il ne saura pas où sont les réponses, et il ne saura surtout pas quand l'agent a fini.

J'ai testé la voie de la messagerie, celle des assistants qu'on pilote depuis Telegram ou WhatsApp, et que j'ai déjà comparée dans deux approches opposées de l'agent IA en entreprise. Cela fonctionne très bien pour un usage personnel, moins bien à plusieurs : les fils se mélangent, on ne sait plus qui a demandé quoi, et il n'existe pas de trace consultable par une équipe. Un canal de discussion partagé règle ces trois points sans rien apprendre à personne.

C'est la seule raison pour laquelle j'ai regardé Buzz de près. Faire dialoguer des IA entre elles, je le fais déjà en ligne de commande depuis longtemps, et ça n'a rien d'une nouveauté. La question que je me posais était plus terre à terre : est-ce que je peux mettre cette interface entre un client et les agents que je lui monte, et repartir en le laissant travailler seul avec eux ?

Un relais que vous hébergez, des agents qui ont leur propre clé

Techniquement, Buzz est un relais Nostr : chaque message, chaque réaction, chaque étape de workflow est un événement signé cryptographiquement, stocké dans un journal unique, que l'auteur soit une personne ou un processus, comme le document d'architecture du projet le décrit. Le format de fil est celui de la spécification NIP-01, et c'est ce choix qui donne sa propriété la plus utile au produit : un agent n'est pas un bot greffé sur une intégration, il a sa propre paire de clés, ses propres appartenances aux canaux et sa propre trace d'audit.

Le montage se fait en deux morceaux. Le relais d'abord, que vous hébergez vous-même : le guide d'installation officiel décrit un service Rust adossé à PostgreSQL, Redis et un stockage objet compatible S3, livré avec un assemblage Docker Compose pour un serveur unique. L'application de bureau ensuite, qui se connecte au relais de votre choix. Un harnais séparé, buzz-acp, fait le pont entre les mentions reçues dans un canal et les agents, en passant par l'Agent Client Protocol. Il ne parle pas aux fournisseurs de modèles : il lance en sous-processus les outils en ligne de commande déjà installés sur la machine. Dans ce montage par défaut, la consommation de vos agents reste donc celle de ces outils, sans clé d'API supplémentaire à provisionner.

Sur la maturité, le dépôt block/buzz parle de lui-même : au 30 août 2026, il affiche 31 441 étoiles, 4 022 forks et 1 398 tickets ouverts, sous licence Apache 2.0. Beaucoup d'attention, beaucoup de chantiers ouverts. C'est le genre de rapport qui interdit de promettre quoi que ce soit à un client sans avoir soi-même mis les mains dedans, et c'est précisément la raison pour laquelle une agence spécialisée dans les agents IA passe autant de temps à tester des produits qu'à écrire du code.

Ce que ça donne quand on branche un vrai dossier de travail

Sur mes trois dossiers, les réponses sont sorties ancrées dans les vrais fichiers : quarante pages de site listées sans erreur, une image exacte retrouvée dans un montage vidéo, et un brief que j'avais moi-même écrit de travers, corrigé par un agent. Ce rattachement à un dossier ne passe par aucun champ de configuration : sur la version que j'ai installée en août 2026, il n'existe ni chemin de projet ni dépôt à déclarer sur la fiche de l'agent. Le lien se fait par le texte du persona, dans lequel on nomme le dossier de travail et les garde-fous. Mon agent « Site » a reçu trois phrases : il travaille dans le dossier du site Noxcod, il montre le diff complet dans le fil, il attend un accord explicite avant tout commit.

Le premier essai a été une question de lecture pure, celle qu'un client poserait : quelles sont les pages du site, et laquelle a bougé en dernier. Réponse en une minute environ, avec les quarante fichiers de pages classés par famille, la dernière page modifiée, sa date et son commit. Aucune généralité. La demande de modification a suivi, sur le libellé du bouton principal de la page d'accueil : deux options argumentées, le diff complet, et une phrase qui dit que rien n'a été commité. J'ai vérifié en dehors de Buzz, dans un terminal : le fichier était intact et la référence de tête n'avait pas bougé. Le garde-fou tenait, parce qu'il était écrit dans le persona, et c'est exactement la mécanique que j'applique quand je monte un agent IA sur mesure rattaché aux dossiers d'une entreprise.

Le deuxième dossier, celui de mon studio vidéo, a produit le résultat le plus convaincant de la semaine. J'ai demandé à quelle seconde tombait une punchline précise dans un montage. L'agent a listé les onze compositions du projet, puis il a répondu que la phrase visée n'était dans aucune des trois punchlines plein écran, qu'elle ouvrait la carte de verdict, que cette carte entre à 682,35 secondes et que la ligne apparaît seize images plus tard, soit 682,9 secondes. J'ai rouvert le fichier de montage à la main : tout était exact, à l'image près, sans une seule invention.

Le troisième cas était une qualification d'appel d'offres public, avec quatre agents sur trois modèles différents, chacun sur une mission étroite. Le moment intéressant n'a pas été la collaboration entre eux, mais une correction. J'avais écrit dans le message de départ que le montant du marché n'était pas publié, en reprenant le verdict de mon propre script de veille. Le premier agent a répondu que le montant était bien publié, caché dans le corps de la description de l'avis, avec sa fourchette et sa référence interne. Il avait raison, et mon script ne lisait qu'un champ structuré resté vide. Un agent venait de trouver un bug dans un outil que j'utilise pour automatiser l'analyse des appels d'offres.

Ce que ça coûte à la machine, et pourquoi ça change le déploiement

Sur mon poste en août 2026, Buzz au repos occupait 61 Mo de mémoire vive avec un processeur à l'arrêt, et l'arbre de processus est monté à 4 401 Mo répartis sur 130 processus enfants dès que trois agents se sont réveillés sur le même fil, avec une charge machine à 11,4. L'application ne pèse rien, les agents pèsent tout. Rien ne dérape pour autant, l'architecture veut exactement ça : la documentation du harnais décrit un pool de sous-processus, de un à trente-deux selon la configuration, et chaque agent réveillé est une session complète de son outil, pas un fil de discussion dans une application.

Les temps de réponse suivent la même logique, et ils dépendent entièrement de ce que l'agent va chercher. Sur des questions qui restent dans les fichiers locaux, la réponse arrive en une à deux minutes. Sur des questions qui déclenchent des recherches sur le web, c'est un autre monde.

Ces cinq mesures viennent de mon installation en août 2026, chacune sur une question différente et lancée une seule fois. Elles donnent un ordre de grandeur par type de question, pas un classement entre les trois outils.

Deux conséquences pratiques sortent de ce tableau. La première concerne la démonstration : une question qui part chercher sur le web ne se montre pas en direct, il faut la lancer avant et revenir sur le résultat. La seconde concerne le déploiement, et elle est structurelle. Si trois agents consomment déjà quatre gigaoctets, j'en déduis, sans l'avoir mesuré à cinq, qu'ils n'ont rien à faire sur le portable de la personne qui travaille. Ils vivent sur une machine dédiée qui reste allumée, un petit serveur ou un poste fixe, et le client se connecte au relais depuis son application. Ce point-là change le chiffrage d'un projet avant même la première ligne de configuration.

Ce qui casse en silence, et c'est le vrai sujet

Trois pannes se produisent sans le moindre signal : un message automatique qui ne réveille aucun agent, un agent affiché en vert qui n'écoute plus, et une validation humaine automatisée qui échoue par conception. J'ai voulu qu'une règle automatique réveille un agent : un message posté par un workflow, contenant la mention et une consigne triviale. Rien. Ni au bout de quatre-vingt-dix secondes, ni après. J'ai reposté la phrase identique à la main deux minutes plus tard, et l'agent a répondu en onze secondes. Ce contrôle positif est ce qui rend la mesure valable : sans lui, un silence ne prouve rien. Un message émis par une automatisation ne réveille pas un agent, un message humain oui.

Le lendemain, un autre agent a cessé de répondre en affichant une pastille verte dans l'interface. Son processus était vivant, avec vingt-deux heures de fonctionnement au compteur, mais son journal s'arrêtait net trois heures plus tôt, sur une reconnexion WebSocket réussie. Le message que je venais d'envoyer n'apparaissait nulle part chez lui : il ne l'avait jamais reçu. Après avoir tué le processus, l'application ne l'a pas relancé et son fichier de suivi continuait de pointer vers un processus mort. Un agent qui décroche la nuit chez un client, personne ne le saura avant que le client écrive.

Le troisième trou est documenté par le projet lui-même, et c'est le plus structurant pour un usage professionnel. Le moteur de workflows propose bien une action de validation humaine, mais la section des limitations connues de l'architecture classe les portes de validation parmi ses limitations connues : le moteur intercepte l'étape avant d'enregistrer la demande et ne reprend jamais l'exécution, si bien qu'une exécution qui l'atteint est marquée en échec. Le garde-fou « rien ne part sans mon accord » n'existe donc pas en automatisation, il n'existe qu'en consigne de persona, avec un humain qui lit le fil. La même liste de limitations signale que la limitation de débit n'est pas appliquée dans le code, les quatre profils prévus restant une cible de conception. Deux informations qu'aucune démonstration produit ne raconte, et qui sont pourtant décisives avant d'ouvrir un accès à quelqu'un d'autre.

Les deux réglages qui décident si vous avez une équipe ou cinq perroquets

Le premier réglage est la quantité de conversation qu'un agent reçoit. Sur mon installation, un agent mentionné dans un fil voyait le message racine plus les douze derniers messages, ce qui suffit pour un échange court et devient absurde dès qu'une discussion s'allonge : le raisonnement des autres disparaît, chacun répond dans le vide et vous obtenez cinq monologues parallèles. Poussé au maximum que proposait ce réglage sur mon installation, cent messages, le même fil produit des réponses qui citent les collègues et reprennent leurs conclusions. Sur ma qualification d'appel d'offres, l'agent de synthèse a commencé sa réponse en disant qu'il avait bien les trois analyses sous les yeux, et le contenu le confirmait.

Le second réglage est la porte d'accès, et c'est celui qui bloque encore le scénario client. Mes agents étaient réglés sur l'accès réservé au propriétaire, qui est le défaut sans être une contrainte : le produit accepte aussi une liste d'autorisation ou une ouverture à tous. Avec ce réglage, un invité présent dans le même canal ne peut pas leur parler. Le ticket correspondant du dépôt, ouvert le 27 juillet 2026, décrit un agent visible du seul membre qui l'a ajouté, et le correctif proposé n'était toujours pas fusionné le 30 août 2026. Tant que ce point n'est pas réglé, la promesse « votre client parle à son agent » ne tient pas, et il faut le dire avant de vendre quoi que ce soit. Quand ce sera ouvert, la bonne pratique restera la liste d'autorisation nominative plutôt que l'ouverture à tous, pour la même raison qu'on ne donne pas un accès administrateur par défaut.

Deux détails d'interface méritent d'être connus avant une démonstration, parce qu'ils font rater le geste en direct. Sur la version que j'ai testée, une mention doit être validée avec la touche de tabulation, faute de quoi le texte tapé ensuite se colle au nom et l'agent n'est jamais appelé. Et la réponse d'un agent arrive dans un fil, pas dans le canal, après un accusé de réception sous forme de réaction : il faut ouvrir le fil pour la lire.

Ce que je fais de Buzz aujourd'hui, et ce qui manque pour l'installer chez un client

Buzz tourne chez moi en usage interne, sur une machine dédiée, et je ne facture aucun déploiement client tant que les trois chantiers ouverts plus haut ne sont pas refermés. Pour mon travail quotidien de développeur, je reste en ligne de commande : taper une instruction dans un terminal va plus vite qu'ouvrir une application, choisir un canal, mentionner un agent et attendre une réaction. Le chat ajoute des gestes inutiles quand je suis seul aux commandes.

Ce que Buzz apporte se joue ailleurs, et ça vaut le détour : c'est la première interface que j'ai pu envisager de poser entre une personne non technique et des agents montés pour elle. Un canal par sujet, une mention pour appeler, un fil pour lire la réponse, une pièce jointe pour montrer un fichier. Personne n'a besoin d'une formation pour ça. En le testant sur mes propres dossiers, j'ai vu un agent lire quarante fichiers de pages sans se tromper, un autre citer une frame exacte dans un montage vidéo, et un troisième corriger le brief que je lui avais donné. Le niveau de service est là, la porte d'entrée aussi.

Ce qui manque se résume à trois points précis : un invité ne peut pas encore parler à l'agent de son projet, une validation humaine ne peut pas être automatisée puisque le moteur échoue sur cette action, et une panne d'agent ne se signale pas. En attendant, je pose la surveillance en dehors de l'application et je garde la validation humaine dans le fil plutôt que dans un workflow. À ceux qui veulent s'y mettre, je conseille de commencer par un dossier connu par cœur : les réponses générales se repèrent alors immédiatement. Pour un projet qui doit tenir devant des utilisateurs dès le premier jour, on part aujourd'hui sur une architecture d'agents sur mesure plutôt que sur ce produit, et on y reviendra quand les trois chantiers seront refermés.

Questions fréquentes sur Buzz et les agents IA

Faut-il payer des API en plus pour faire tourner des agents dans Buzz ?

Non, pas dans le montage par défaut. Le harnais d'agents décrit par le projet ne parle pas aux fournisseurs de modèles : il lance en sous-processus les outils en ligne de commande déjà installés sur la machine, via l'Agent Client Protocol. La consommation reste donc celle de ces outils, avec les accès dont ils disposent déjà. Ce qui s'ajoute, c'est la machine qui héberge le relais et les processus d'agents.

Un client peut-il parler à mes agents dans un canal partagé ?

Pas de manière fiable à ce jour. Les agents sont réglés par défaut pour ne répondre qu'à leur propriétaire, et un ticket ouvert le 27 juillet 2026 sur le dépôt décrit un agent visible du seul membre qui l'a ajouté. Le correctif proposé n'était pas fusionné le 30 août 2026. Il faut donc vérifier l'état de ce chantier avant de promettre un accès invité à qui que ce soit.

Quelle machine faut-il prévoir pour faire tourner plusieurs agents ?

Une machine dédiée qui reste allumée, pas un portable de travail. Mes mesures d'août 2026 donnent 61 Mo de mémoire pour l'application au repos, et 4,4 Go répartis sur 130 processus dès que trois agents travaillent en même temps, avec une charge machine à 11,4. Je n'ai pas mesuré au-delà de trois, mais ce rapport revient à environ 1,5 Go par agent réveillé : à cinq, prévoyez la mémoire vive en conséquence et séparez cette machine du poste de travail.

Peut-on automatiser une validation humaine avant qu'un agent agisse ?

Pas encore par un workflow. L'action existe dans la syntaxe, mais la documentation d'architecture du projet classe les portes de validation parmi ses limitations connues : le moteur intercepte l'étape sans enregistrer la demande, et l'exécution qui l'atteint est marquée en échec. La seule validation qui fonctionne aujourd'hui est manuelle : l'agent poste ce qu'il propose dans le fil et attend un accord écrit, garde-fou inscrit dans son persona.

Buzz remplace-t-il Slack pour une équipe humaine ?

Ce n'est pas l'usage que je lui vois à court terme, et ce n'est pas là que son intérêt se situe. Une équipe qui cherche seulement une messagerie trouvera un produit en construction, avec 1 398 tickets ouverts au 30 août 2026 et plusieurs fonctions que le projet annonce lui-même comme en cours de câblage. L'intérêt apparaît quand des agents doivent travailler dans les mêmes salons que les humains, avec la même identité signée et la même trace consultable par tous.