Brigade : une crew d'agents auto-hébergée, jugée sur ce que le dépôt montre

Le problème visé : des agents qui ne se parlent pas

La plupart des assistants en terminal traitent chaque session comme une ardoise vierge. Vous relancez, vous réexpliquez le contexte, vous recopiez la même clé API dans un fichier de configuration, et l'agent qui a appris hier une convention de nommage l'a oubliée aujourd'hui. Brigade attaque ce point précis : le README décrit une crew d'agents partageant une mémoire longue durée nommée Tideline, avec une hiérarchie qui détermine qui peut déléguer à qui. Le public visé est celui qui veut plusieurs agents spécialisés (un pour le code, un pour la veille, un pour les messages) sans monter une usine à gaz SaaS.

Le positionnement est explicite dans le README : pas de compte à créer, pas d'intermédiaire, les clés restent sur la machine. Ce n'est pas un argument marketing isolé, c'est une contrainte d'architecture qui explique la suite : un répertoire ~/.brigade/ que vous possédez, et un backend Convex que vous pouvez héberger vous-même si le système de fichiers ne suffit plus.

Tideline, org chart et le trajet réel d'une tâche

Le mécanisme central tient en une phrase du README : les agents partagent une mémoire, donc ce que l'un apprend, les autres peuvent s'en servir. Tideline est décrite comme un moteur de rappel hybride, mot-clé plus vecteur, avec portée par origine et décroissance (decay). Concrètement, cela signifie qu'un fait mémorisé n'est pas éternel : il perd du poids avec le temps, et sa provenance compte dans la manière dont il est restitué. C'est un choix défendable, parce qu'une mémoire d'agent qui accumule sans jamais oublier finit par noyer les faits utiles sous les résidus.

La délégation est l'autre moitié. Le README parle d'une org chart qui gouverne qui peut déléguer à qui, d'agents isolés avec leurs propres personas, identifiants et espaces de travail, et d'un fan-out de sous-agents. Le changement de modèle en cours de tâche est annoncé sans perte du fil. Ce dernier point est le plus difficile à tenir techniquement : conserver le contexte quand on passe de Claude à GPT ou à un modèle local suppose une représentation de l'état qui ne dépende pas du format d'un fournisseur. Le dépôt ne donne pas de détail d'implémentation sur ce point dans le matériel fourni, et il faut le noter comme une zone à vérifier plutôt que comme un acquis.

Installation : deux commandes et un répertoire

Le README donne une procédure courte pour macOS et Linux. Elle installe Node si nécessaire, puis Brigade, sans sudo :

curl -fsSL https://brigade.spinabot.com/install.sh | sh brigade

Un pipe direct de curl vers sh mérite d'être dit franchement : vous exécutez un script distant sans l'avoir lu. Si cela vous gêne, la section Develop from source du README existe précisément pour ce cas, et le paquet npm @spinabot/brigade est l'autre voie. Le dépôt publie un badge de version Node, ce qui indique une contrainte de moteur explicite, mais la valeur exacte n'est pas lisible dans le matériel fourni : vérifiez-la avant de déployer sur une machine dont la version de Node est figée.

Une fois lancé, vous obtenez une TUI de chat. Le README insiste sur l'absence de navigateur et d'Electron. Tout l'état vit sous ~/.brigade/. La documentation mentionne aussi un serveur MCP de mémoire, ce qui ouvre la réutilisation de Tideline par d'autres clients compatibles MCP, et un planificateur cron pour les tâches récurrentes.

Stockage : fichiers par défaut, Convex si besoin

Le choix de persistance est présenté comme un interrupteur, pas comme une réécriture. Par défaut, Brigade s'installe en mode fichiers, décrit comme petit. Quand vous voulez une base, vous passez à un Convex auto-hébergé. Le README résume cela en une ligne : la même crew tourne sur un Raspberry Pi ou sur un serveur.

Cette dualité a un coût réel. Deux modes de stockage, c'est deux chemins de code à maintenir, deux façons de sauvegarder, et un risque de divergence entre ce que le mode fichiers tolère et ce que Convex accepte. Le README ne décrit pas de procédure de migration entre les deux, ni de garantie de compatibilité des données d'un mode à l'autre. Si vous démarrez en fichiers avec l'intention de basculer plus tard sur Convex, traitez cette absence comme un point à clarifier avant de stocker des mois de mémoire d'agents. Le point positif est symétrique : le mode fichiers rend la sauvegarde triviale, un simple archivage de ~/.brigade/ suffit.

Exposer la crew : ce que brigade bloody benchmark fait vraiment

La fonction la plus singulière du projet est l'exposition réseau. Le README annonce HTTPS en périphérie, sans compte ni configuration, via Cloudflare par défaut, ou avec votre propre relais parmi bore, frp et sish. Une clé secrète accompagne l'exposition de manière invisible pour vous, et les visiteurs non autorisés reçoivent un 401. Deux commandes sont documentées : brigade bloody benchmark et son alias plus sobre brigade expose, plus brigade expose stop pour arrêter.

Le nom est assumé et le README l'explique longuement : jeter la crew sur l'internet ouvert et voir si elle survit à des inconnus qui la sollicitent. C'est un test d'exposition, pas un benchmark de qualité de modèle, et il faut le lire ainsi. La conséquence pratique est directe : cette commande ouvre un tunnel depuis votre machine vers l'extérieur. Le README affirme que la clé secrète protège l'accès, ce qui est cohérent avec le 401 annoncé, mais l'étendue exacte de ce que les agents peuvent faire une fois atteints n'est pas détaillée. Sur une machine qui contient vos identifiants et vos connecteurs vers plus de 1 000 applications, c'est le point que je vérifierais en premier, en environnement isolé, avant de lancer la commande sur un poste de travail principal.

Ce que le dépôt ne permet pas de conclure

Le matériel fourni est un README et une liste de versions. Il ne contient ni guide d'architecture, ni documentation d'API, ni chiffres de performance, ni détail sur la manière dont la décroissance de Tideline est paramétrée. Les sections annoncées dans la table des matières (Multi-agent isolation, Providers & web search, Configuration & storage, Extending Brigade) ne sont visibles que par leurs titres. Toute affirmation sur la qualité du rappel hybride, sur le coût en jetons d'une délégation ou sur la robustesse du fan-out de sous-agents serait donc une extrapolation.

Deuxième réserve : le rythme de publication. Trois versions apparaissent sur une fenêtre d'environ dix jours en septembre 2026 (1.36.1, 1.37.0, 1.37.1), ce qui suggère un développement actif mais aussi des correctifs fréquents. Un projet qui bouge à ce rythme demande de suivre les notes de version avant chaque mise à jour, surtout si vous avez personnalisé des agents ou des compétences. Ce n'est ni un défaut ni une qualité en soi : c'est une charge de maintenance à intégrer dans votre décision.

Face à un framework d'agents classique : la différence de posture

Un framework comme LangChain ou l'API Agents d'un fournisseur vous donne des primitives : vous écrivez le graphe, vous gérez l'état, vous branchez la mémoire. Brigade prend la posture inverse. Le README le formule en une ligne : « It's an ecosystem, not an app. » Vous n'assembl ez pas des briques, vous démarrez une crew déjà câblée, avec org chart, mémoire partagée, planificateur cron et canaux de messagerie (WhatsApp, Telegram, Slack, Discord, iMessage, BlueBubbles).

La contrepartie est nette. Un framework vous laisse choisir votre modèle de données et votre fournisseur de vecteurs ; Brigade impose Tideline et son mode de stockage. Un framework s'intègre dans votre code existant ; Brigade vit dans ~/.brigade/ et vous adaptez votre usage à sa TUI et à ses commandes. Si vous avez besoin d'un agent embarqué dans un service, appelé par votre propre API, Brigade est probablement le mauvais outil. Si vous voulez une crew opérationnelle ce soir, sur votre machine, sans écrire de graphe, l'échange est raisonnable. Le README mentionne aussi le support d'Ollama en local, ce qui distingue Brigade d'une solution entièrement dépendante d'un fournisseur cloud.

Licence, maintenance et ce qu'il faut vérifier avant d'adopter

La licence est MIT, indiquée dans le dépôt et dans le badge du README. Cela autorise l'usage commercial, la modification et la redistribution, avec conservation du texte de licence et de l'avis de copyright. Je ne donne pas d'avis juridique : si vous redistribuez Brigade dans un produit, faites relire les mentions par qui de droit, notamment parce que le projet s'appuie sur des services tiers (Cloudflare par défaut, ou un relais bore, frp ou sish que vous hébergez) dont les conditions vous concernent séparément.

Côté maintenance, le coût se répartit en trois postes identifiables dans le matériel fourni : suivre les versions fréquentes, sauvegarder ~/.brigade/ (ou votre Convex auto-hébergé), et gérer les identifiants des agents isolés. Le README promet l'absence de télémétrie et le maintien des clés en local, ce qui réduit la surface de fuite mais déplace la responsabilité vers vous : personne d'autre ne sauvegardera votre mémoire d'agents. Le README annonce plus de 1 000 connecteurs d'applications ; chacun est une autorisation supplémentaire à accorder, et donc à révoquer le jour où vous retirez un agent. Commencez par un seul agent, un seul canal, et le mode fichiers, puis élargissez.

Conclusion éditoriale

Adoptez Brigade si vous voulez une crew d'agents qui tourne sur votre matériel, avec des clés qui restent locales et un stockage que vous pouvez sauvegarder vous-même. Ne l'adoptez pas si votre besoin est un seul agent scriptable en bibliothèque, sans TUI ni org chart : la surface de configuration de ~/.brigade/ et le choix fichiers/Convex n'ont alors aucun intérêt. Avant de vous engager, vérifiez trois choses concrètes : la version de Node exigée par le badge du dépôt, le contenu réel de ~/.brigade/ après un premier lancement, et le fait que brigade bloody benchmark déclenche bien une exposition réseau publique.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. spinabot/brigade on GitHub