Flock : un harness multi-agents de bureau, écrit en Rust au-dessus de langgraph-rust

Le problème : orchestrer des agents sans perdre le contrôle

La plupart des clients de chat traitent un agent comme une conversation. Vous écrivez, il répond, et tout ce qui touche au disque ou au shell reste hors de portée ou invisible. Flock part d'un constat différent : un agent utile lit et écrit des fichiers, lance des commandes bash, navigue sur le web et enchaîne plusieurs étapes sans supervision. Le projet se présente comme un harness multi-agents, c'est-à-dire une couche qui exécute ces agents localement ou dans des conteneurs tout en montrant chaque action.

Le public visé est précis. Il s'agit de développeurs qui veulent concevoir des pipelines d'agents sur un canevas, les versionner, les planifier, et reprendre la main quand une étape tourne mal. Le README donne l'exemple d'un agent bloqué sur un captcha : l'utilisateur reprend le contrôle clavier et souris via VNC. Cette fonction suppose une machine de bureau, pas un serveur headless.

La comparaison que dresse le README avec les clients de chat classiques tient en une ligne : édition visuelle de workflows, accès complet au système de fichiers, boucle autonome avec demandes d'approbation, planificateur cron, orchestration multi-agents. C'est un cahier des charges, pas une preuve. Le dépôt ne contient pas de mesures comparatives.

Une architecture en crates, du canevas React jusqu'au checkpointer SQLite

Le diagramme d'architecture du README décrit une chaîne en trois couches. L'interface Tauri, écrite en React avec Mantine, communique avec le cœur src-tauri par IPC et commandes Tauri. Ce cœur parle à flock-agent, l'exécuteur d'agents, via un protocole JSON. flock-agent fait tourner une machine à états langgraph-rust et persiste son état dans une base SQLite via un checkpointer.

Le découpage en crates est explicite dans le tableau du README. flock-core porte les schémas de configuration, les modèles SQLite, les utilitaires de chiffrement et les canaux IPC. flock-agent contient la boucle d'exécution, le moteur d'états, le checkpointer et le système de mémoire. flock-workflow héberge la logique des nœuds et un compilateur qui transforme le JSON du canevas en AST LangGraph. flock-tools regroupe les outils natifs et sandboxés, les proxys WebSocket VNC et les gestionnaires de bac à sable. flock-skills charge les prompts système.

Ce dernier point mérite attention. Le compilateur JSON vers AST signifie que le graphe visuel n'est pas interprété à la volée : il est traduit en structure exécutable. C'est une décision de conception qui facilite la validation en amont, mais elle impose que chaque type de nœud ait sa traduction. Le README annonce dix types de nœuds livrés, dont start, answer, llm, agent, classifier, ifelse, code, human, plugin et parameter_extractor. Toute extension du canevas devra donc passer par flock-workflow.

Démarrer : clé API, canevas, et rien d'autre à installer

Le README insiste sur l'absence de configuration externe : pas d'outil CLI à télécharger, on colle une clé API et on commence. Les fournisseurs cités sont OpenAI, Gemini, Anthropic Claude, AWS Bedrock et Ollama en local. Le dépôt ne détaille pas les clés de configuration exactes pour chaque fournisseur, ni le chemin des fichiers de configuration. C'est une lacune du matériel fourni, pas une affirmation sur le code.

Ce qui est documenté, ce sont les commandes de lecture du dépôt. La branche main contient le code Rust actuel. La branche legacy/python conserve l'implémentation d'origine en Python, avec LangGraph, LangChain et FastAPI en backend. Le README précise que Flock a été entièrement réécrit et que cette branche sert de référence.

Pour les tâches récurrentes, le planificateur cron intégré accepte la syntaxe cron standard. Le README cite trois usages : maintenance système automatisée, agrégation quotidienne de fichiers, génération de rapports. Pour MCP, la promesse est différente : connecter un serveur tiers une fois, et tous les assistants et workflows héritent des schémas et outils exposés. C'est un mécanisme d'héritage global, pas une configuration par agent. La conséquence pratique est qu'un serveur MCP ajouté devient visible partout, ce qui peut surprendre dans un projet où plusieurs workflows coexistent.

Les approbations humaines et le bac à sable : le vrai différenciateur

Le README place les approbations interactives au premier plan. Les actions sensibles, écriture de fichiers, exécution de scripts bash, modification de configurations, exigent une approbation explicite avant exécution. L'utilisateur peut inspecter le plan, approuver ou refuser. Le nœud human du canevas ajoute des points d'arrêt manuels dans le flux, pour demander une décision, un formulaire ou une modification de variable.

L'exécution risquée est isolée dans des conteneurs. Le README mentionne x11vnc et websockify pour diffuser le bureau du bac à sable dans l'interface via WebSocket. L'automatisation navigateur repose sur Playwright, et le computer use sur des commandes OS de type xdotool, avec surveillance du framebuffer. Ces choix techniques impliquent une dépendance à un environnement X11 côté conteneur. Sur macOS ou Windows, le bac à sable VNC suppose donc une couche de virtualisation ou un conteneur Linux, ce que le README ne détaille pas.

La prise de contrôle VNC est présentée comme un filet de sécurité. C'est un aveu : le projet part du principe que l'automatisation échouera parfois, et préfère donner accès à l'écran plutôt que de promettre une fiabilité totale. Cette position est plus honnête que la plupart des outils du même genre.

La dépendance à langgraph-rust, et ce qu'elle implique

Le README est explicite : Flock est construit au-dessus de langgraph-rust, présenté comme l'implémentation Rust personnelle de LangGraph par l'auteur du projet. Cette phrase a deux conséquences. La première est que la maturité de Flock est liée à celle de langgraph-rust, un projet maintenu par la même personne. La seconde est que la compatibilité avec l'écosystème LangGraph Python n'est pas garantie.

Le dépôt ne documente pas les écarts entre les deux implémentations. Un développeur qui possède déjà des graphes LangGraph en Python ne peut pas supposer qu'ils se transposent. Le checkpointer SQLite et le système de mémoire sont propres à flock-agent, décrits dans le tableau des crates sans détail sur le format de persistance.

Il faut aussi noter ce que le README ne dit pas. Aucune information sur les performances de la réécriture Rust, malgré la mention d'améliorations significatives. Aucune indication sur le nombre de contributeurs, la cadence de correction de bugs, ou la couverture de tests. Les releases v0.3.0 et v0.3.1 datent de juin 2026, le dernier push de juillet 2026. Le rythme de publication semble soutenu, mais cela ne renseigne pas sur la stabilité.

Quand Flock n'est pas le bon outil

Flock suppose une application de bureau. Une équipe qui veut exécuter des agents dans un pipeline CI, sur un serveur sans affichage, ou dans un cluster Kubernetes, devra chercher ailleurs. Le bac à sable VNC et le computer use n'ont pas de sens sans écran. Le planificateur cron intégré suppose une machine allumée.

Le projet suppose aussi que l'utilisateur veut voir et approuver. Une organisation qui cherche une autonomie totale, sans interruption humaine, trouvera les approbations interactives et le nœud human contre-productifs. Le README présente ces mécanismes comme des garanties, pas comme des options désactivables. Rien dans le matériel fourni n'indique qu'on puisse les contourner globalement.

Enfin, le canevas visuel a un coût. Concevoir un pipeline à la souris est plus lent qu'écrire un graphe en code, surtout pour des branches conditionnelles nombreuses. Le nœud ifelse et le nœud classifier couvrent les cas simples, mais un workflow à vingt nœuds deviendra probablement plus lisible en Python. Flock vise l'inspection et la reprise en main, pas la productivité d'écriture.

Alternatives : LangGraph en Python, ou un client de chat simple

L'alternative la plus directe est LangGraph en Python, la bibliothèque d'origine. La différence d'approche est nette. LangGraph fournit une bibliothèque de graphes que vous intégrez dans votre propre application, avec votre serveur, votre interface et votre déploiement. Flock fournit une application complète, avec interface graphique, éditeur visuel et bac à sable, mais vous adoptez ses choix : Tauri, React, SQLite, et langgraph-rust plutôt que l'implémentation de référence.

Pour un besoin plus modeste, un client de chat avec appels d'outils suffit. Le README lui-même oppose Flock aux clients de chat traditionnels sur l'édition visuelle, l'accès aux fichiers, l'autonomie multi-étapes et la planification. Si aucune de ces quatre capacités n'est nécessaire, la complexité de Flock, avec ses conteneurs, son VNC et ses crates, n'est pas justifiée.

Un troisième cas existe : les outils d'automatisation navigateur seuls. Flock intègre Playwright et xdotool, mais si votre problème se limite à scraper des pages, une bibliothèque Playwright directement dans votre langage habituel sera plus simple à déboguer que l'ensemble Tauri plus conteneur VNC.

Licence, maintenance et coût de mise à jour

Flock est publié sous Apache-2.0. Cette licence autorise l'usage commercial, la modification et la redistribution, avec conservation des mentions de copyright et des brevets accordés. Elle ne donne pas d'avis juridique : une organisation qui redistribue Flock modifié doit vérifier ses propres obligations, notamment la fourniture du texte de licence et la signalisation des fichiers modifiés. Le README ne mentionne pas de licence pour langgraph-rust, ce qu'il faudrait vérifier séparément puisque Flock en dépend directement.

Le coût de maintenance tient à trois facteurs visibles dans le dépôt. D'abord la dépendance à langgraph-rust, maintenue par le même auteur : une rupture d'API dans cette bibliothèque se répercute sur flock-agent et flock-workflow. Ensuite l'interface Tauri et React, qui suit les versions de Tauri et de Mantine, avec les migrations que cela implique. Enfin le bac à sable, qui repose sur des composants Linux (x11vnc, websockify, Playwright, xdotool) dont les mises à jour de sécurité doivent être suivies indépendamment de Flock.

Les releases récentes, v0.2.9 en juin 2026, v0.3.0 puis v0.3.1 le même mois, suggèrent un projet actif. Le README ne fournit pas de politique de support ni de compatibilité ascendante entre versions. Un workflow visuel créé en v0.2.9 pourrait nécessiter une migration en v0.3.0, mais le matériel fourni ne permet pas de l'affirmer.

Conclusion éditoriale

Flock convient aux développeurs qui veulent un poste de travail local pour agents, avec approbations explicites et bac à sable conteneurisé, et qui acceptent de dépendre de langgraph-rust. Ceux qui ont besoin d'une implémentation LangGraph éprouvée en production, ou d'un simple client de chat, devraient passer leur chemin. Avant d'adopter, vérifiez la compatibilité de langgraph-rust avec vos graphes existants, le contenu de crates/flock-workflow pour le compilateur AST, et si les nœuds code exécutent bien du JavaScript et du Python comme l'annonce le README.

Sources officielles

1. Issues
2. License: Apache-2.0
3. Onelevenvy/flock on GitHub
4. README
5. Releases