Hexabot v3 : workflows agentiques en YAML, du poste local à la production

Le problème : recoller des briques d'IA à chaque nouveau canal

Monter un assistant qui répond sur un site, puis sur une messagerie, puis dans un outil interne, revient souvent à réécrire la même logique trois fois. La partie modèle change peu, mais la plomberie autour (routage des messages, mémoire de conversation, appel d'outils, validation des entrées) est reprise à chaque fois. Hexabot v3 se positionne exactement là : le README le présente comme une plateforme d'automatisation avec des capacités IA de premier ordre, réunissant workflows, actions et canaux conversationnels dans un seul runtime. Le public visé n'est pas le data scientist qui prototyppe un prompt, mais l'équipe qui doit faire tourner ce prompt quelque part, avec des contrats de données et un minimum de structure. Le vocabulaire du dépôt (agent, agentic, bot-framework, workflow) confirme cette cible : des développeurs TypeScript qui veulent un cadre, pas un script. La promesse tient en une phrase du README : automatiser ce qui est ennuyeux, garder ce qui a de la valeur.

Schema-first : Zod comme contrat entre workflow et exécution

L'architecture repose sur une idée simple à énoncer et contraignante à tenir : tout ce qui entre et sort d'une étape est décrit par un schéma. Le README parle d'une architecture schema-first avec un usage large de Zod pour la validation et les contrats partagés. Concrètement, une action ne se contente pas d'exécuter du code : elle déclare ses entrées, ses sorties et ses réglages, et le runtime valide ces échanges. C'est ce qui rend un workflow YAML lisible par une machine avant de l'être par un humain. Le système de bindings ajoute une couche : les capacités réutilisables et la configuration sont séparées de la logique de tâche, ce qui évite de dupliquer une connexion ou un réglage dans dix actions. La mémoire fait l'objet de définitions explicites, intégrées au runtime, plutôt que d'être laissée à une variable globale quelque part. Cette discipline a un coût : écrire une action demande plus de travail que d'appeler une fonction, parce qu'il faut décrire le contrat avant le comportement. En échange, les erreurs de type se voient à la validation et non en production, à condition que les schémas soient réellement maintenus à jour.

MCP, mémoire et canaux : ce que le runtime met en relation

Trois mécanismes structurent l'exécution. D'abord les workflows agentiques, définis en YAML avec des contrats typés côté runtime. Ensuite les points d'intégration MCP (Model Context Protocol), que le README mentionne comme support pour l'interopérabilité des outils et du contexte : c'est la porte par laquelle des serveurs d'outils externes peuvent être branchés sans réécrire une couche d'appel maison. Enfin la continuité multi-canal, où canaux et helpers restent des concepts centraux : la même logique de workflow peut être reliée à plusieurs points d'entrée conversationnels. Le README ne détaille pas la liste des canaux pris en charge, ni la manière dont l'état d'une conversation est conservé entre deux messages. C'est une lacune documentaire réelle pour qui doit estimer un projet : savoir qu'un concept existe ne dit rien du travail d'intégration. La documentation en ligne, sur docs.hexabot.ai, est l'endroit où chercher ces détails avant de s'engager.

Démarrage : trois commandes, une TTY obligatoire

Le README donne un chemin court. Il faut Node.js ^24.17.0 et un gestionnaire de paquets parmi npm, pnpm, yarn ou bun. Docker reste optionnel, pour les services lancés en conteneurs. On installe la CLI avec npm install -g @hexabot-ai/cli, ou on l'exécute sans installation globale via npx @hexabot-ai/cli --help. Ensuite : hexabot create my-project, cd my-project, hexabot dev. La création détecte le gestionnaire de paquets et accepte une contrainte explicite avec --pm, par exemple hexabot create my-project --pm npm. Point important pour l'automatisation : create demande les identifiants administrateur initiaux et exige un terminal interactif (TTY). Dans un shell non interactif, il faut donc passer d'abord par un terminal local. Les points d'entrée par défaut sont l'interface d'administration sur http://localhost:3000, l'API sur http://localhost:3000/api et la documentation d'API sur http://localhost:3000/docs, cette dernière étant indiquée comme non disponible en production. La CLI couvre aussi dev, start, stop, env, check, config et migrate, avec des options comme --docker, --services, --build ou -v selon la commande. Pour le monorepo lui-même, le README renvoie à PNPM et à CONTRIBUTING.md.

Données : SQLite pour démarrer, Postgres pour tenir

Le README est clair sur la couche de données. TypeORM est la couche standard, SQLite l'option locale par défaut, Postgres le choix de première classe pour la production. La configuration passe par les variables DB_TYPE et DB_*, sans que le README énumère les clés exactes ni les valeurs acceptées. Ce silence a une conséquence pratique : la migration de SQLite vers Postgres n'est pas décrite, et rien n'indique si les types de colonnes ou les migrations TypeORM sont écrits pour rester portables entre les deux moteurs. Pour un projet qui reste sur un seul serveur, SQLite suffit et évite un service supplémentaire. Pour un déploiement avec plusieurs instances applicatives, la question du verrouillage et de la concurrence en écriture se pose, et le README n'y répond pas. La commande hexabot migrate existe, ce qui suggère un chemin de mise à jour du schéma, mais son comportement en cas de migration partielle n'est pas documenté dans le matériel fourni.

La licence FCL-1.0-ALv2, et ce qu'elle implique

Le dépôt affiche NOASSERTION comme identifiant de licence, et le README renvoie à LICENSE.md pour les termes complets, en indiquant FCL-1.0-ALv2 avec un copyright Hexastack 2025. Le suffixe ALv2 évoque une licence applicable avec Apache 2.0, mais c'est une déduction, pas une certitude : le texte de LICENSE.md n'est pas fourni ici et doit être lu avant tout usage commercial. Le point à retenir est méthodologique. GitHub n'a pas su reconnaître la licence, ce qui signifie que les outils automatiques de conformité ne trancheront pas à votre place. Si votre organisation filtre les dépendances par identifiant SPDX, Hexabot passera probablement en revue manuelle. Ce n'est ni un blocage ni un feu vert : c'est une étape à prévoir, avec un examen du texte réel plutôt qu'une interprétation du nom.

Le décalage v3 / v2.2.2, et les cas où Hexabot est le mauvais outil

Le README annonce Hexabot v3, mais la release la plus récente listée est v2.2.2, publiée le 24 janvier 2025, précédée de v2.1.5 et v2.0.2. Le dernier push sur main date d'août 2026. Autrement dit, le dépôt bouge, mais rien dans le matériel fourni ne montre une publication étiquetée v3. Installer @hexabot-ai/cli depuis npm ne garantit donc pas que vous obtenez le runtime décrit par le README : il faut vérifier la version effectivement installée avant de bâtir dessus. C'est le principal risque d'adoption à ce stade. Deuxième limite, plus structurelle : Hexabot est une plateforme avec serveur, interface d'administration et base de données. Si votre besoin est d'appeler un modèle depuis une fonction dans une application existante, cette pile est surdimensionnée, et une bibliothèque cliente d'API suffit. Troisième cas défavorable, la contrainte de TTY sur hexabot create complique l'amorçage entièrement scripté dans un pipeline d'intégration continue, puisque la commande doit d'abord être passée depuis un terminal local.

Face à un framework de bots classique : où se situe la différence

La comparaison la plus utile n'est pas entre deux plateformes d'IA, mais entre Hexabot et un framework de bots conversationnels généraliste, du type de ceux qui organisent une conversation autour d'intents, de middlewares et de connecteurs de canaux. Dans ce modèle, la logique vit dans du code applicatif et la configuration reste mince. Hexabot déplace le centre de gravité : le workflow est décrit en YAML, les actions déclarent leurs contrats via Zod, et les capacités réutilisables passent par le système de bindings. La différence se voit au moment de la revue : un changement de parcours se lit dans un fichier de workflow plutôt que dans un diff de code, et la validation des entrées est portée par le runtime. En contrepartie, vous héritez d'un vocabulaire et d'une pile serveur à comprendre, là où un framework de bots classique s'insère souvent dans une application déjà en place. Le choix se joue donc sur la nature de l'équipe : celle qui veut versionner des parcours lisibles par des non-développeurs gagnera au change, celle qui veut ajouter un assistant à un service existant y perdra du temps.

Conclusion éditoriale

Adoptez Hexabot v3 si vous voulez décrire des workflows agentiques en YAML et les exécuter sur plusieurs canaux depuis un runtime TypeScript unique, avec SQLite en local et Postgres en production. Écartez-le si vous cherchez une bibliothèque légère à embarquer dans une application existante, ou si vous avez besoin d'un historique de versions stable : le README annonce v3 alors que la dernière release publiée est v2.2.2. Avant tout engagement, ouvrez LICENSE.md pour comprendre les termes de FCL-1.0-ALv2, puis vérifiez le contenu réel de votre projet généré, en particulier le dossier des workflows et le fichier de variables d'environnement.

Sources officielles

1. hexabot-ai/Hexabot on GitHub
2. Issues
3. Project website
4. README
5. Releases