OM1 : un runtime Go pour agents multimodaux, du webcam au TurtleBot 4

Le problème : un seul cerveau d'agent, plusieurs corps

Le README formule l'objectif ainsi : rendre facile la création de robots « easy to upgrade and (re)configure to accommodate different physical form factors ». Autrement dit, le problème visé n'est pas la robotique en général, c'est la duplication. Un agent qui parle, voit et se déplace possède un pipeline qui ne change pas beaucoup entre un humanoïde, un quadrupède, une application mobile et un TurtleBot 4. Ce qui change, ce sont les capteurs et les actionneurs. OM1 place donc la couche matérielle derrière des plugins, et garde le pipeline agent côté runtime. Le public visé est précis : développeurs qui assemblent des entrées multimodales (caméra, micro, LIDAR, données web ou réseaux sociaux) et des sorties physiques (motion, navigation autonome, synthèse vocale), sans vouloir réécrire la logique d'agent à chaque changement de châssis. Le projet cite aussi les simulateurs Gazebo et Isaac Sim, ce qui laisse entendre un usage en simulation avant déploiement matériel. Rien dans le matériel fourni ne décrit de cas d'usage industriel certifié : c'est un runtime de développement.

Go plutôt que Python : ce que la migration implique vraiment

OM1 a d'abord été écrit en Python. Le runtime Go est présenté comme une réécriture orientée performance, motivée par la latence, la concurrence, une empreinte mémoire plus faible sur les appareils en périphérie et un déploiement simplifié sous forme d'un binaire Go unique, avec la bibliothèque C de Zenoh embarquée à côté. La recommandation du README est nette : pour tout nouveau développement, utilisez le Go. La branche Python reste accessible mais elle est marquée comme dépréciée et non maintenue. C'est un choix de projet assumé, et il a un coût pour l'adoptant : si une capacité dont vous avez besoin n'existe que côté Python, vous héritez d'une branche qui ne recevra pas de correctifs. Le README reconnaît d'ailleurs que le runtime Go couvre le pipeline agent principal tandis que plusieurs capacités du Python sont encore en développement actif. La conséquence pratique est simple : la parité fonctionnelle entre les deux runtimes n'est pas garantie à ce jour, et c'est le premier point à vérifier avant de s'engager.

Le pipeline : entrées, LLM, actions, et des plugins pour le reste

Le README décrit un flux entrée-LLM-action, et l'agent de démarrage rapide, nommé conversation, l'illustre : la webcam et le microphone alimentent le modèle, qui répond par la voix, pendant que les mises à jour d'état s'affichent dans le terminal. Côté matériel, la couche d'abstraction passe par des plugins pour les points d'API et les connexions robotiques à ROS2, Zenoh et CycloneDDS. Le README recommande Zenoh pour tout nouveau développement, ce qui suggère que les deux autres chemins servent surtout d'interopérabilité avec l'existant. Les endpoints sont préconfigurés pour la synthèse vocale, plusieurs fournisseurs de LLM (OpenAI, xAI, DeepSeek, Anthropic, Meta, Gemini, NearAI, et Ollama en local) ainsi que plusieurs modèles vision-langage. Cette liste de fournisseurs est un point de conception, pas un argument de qualité : elle indique que le projet parie sur la substituabilité des modèles plutôt que sur un modèle propre. À noter que le README précise que pour les interactions vocales, l'ASR et le TTS doivent être configurés dans le fichier config/conversation.json5. Le format de configuration est donc du JSON5, pas du YAML ni du TOML.

Mise en route : dépendances système, clé, et un piège de chemin de bibliothèque

Le démarrage rapide tient en quatre étapes. D'abord les dépendances système : sur macOS, brew install portaudio ffmpeg ; sur Linux, sudo apt-get update puis sudo apt-get install -y portaudio19-dev ffmpeg pkg-config. Ensuite, deux voies. Le binaire précompilé, sans installation de Go, avec chmod +x om1 puis ./om1 -config ./config/conversation.json5, après avoir exporté DYLD_LIBRARY_PATH sur macOS ou LD_LIBRARY_PATH sur Linux pour pointer vers le dossier courant. Sur macOS, le README prévoit aussi xattr -d com.apple.quarantine om1 si Gatekeeper bloque l'exécutable. La compilation depuis les sources demande Go 1.25.0 ou plus récent et make : git clone, puis make deps et make build, et le lancement via CONFIG=conversation make run, ou make dev pour des journaux de débogage. La clé s'obtient sur le portail OpenMind et se place dans OM_API_KEY, soit dans le profil shell, soit dans un fichier .env copié depuis .env.example. Le point que je retiens : l'archive de release contient déjà config/, knowledge_base/ et les fichiers libzenohc, donc cloner le dépôt n'est pas nécessaire pour les ressources d'exécution. En revanche, la variable de chemin de bibliothèque n'est pas optionnelle, et c'est la cause d'échec la plus probable au premier lancement.

Observabilité et coût : Prometheus, Grafana, et le compteur OMCU

Le projet embarque une pile Prometheus et Grafana, lancée par docker-compose up -d grafana prometheus, avec un tableau de bord « OM1 Latency Monitoring » provisionné automatiquement et accessible sur localhost:3000 avec le couple admin/admin par défaut. Les métriques citées sont les latences du pipeline, notamment celles du LLM et de l'ASR. C'est utile pour un runtime d'agent où la latence perçue conditionne l'usage, mais cela suppose Docker sur la machine cible, ce qui n'est pas anodin sur un robot embarqué. Le dépannage mentionne d'ailleurs un conflit possible sur le port 9090, occupé par un autre Prometheus. Le second aspect, moins technique, est le modèle économique : OMCU est l'unité de facturation de la plateforme OpenMind, le plan gratuit en fournit 50 renouvelés chaque mois, et l'augmentation se fait via le portail. Le README ne détaille pas la consommation d'OMCU par appel ni par type d'agent. C'est une lacune documentaire réelle pour quiconque veut estimer un coût d'exploitation, et le fait que la clé OM_API_KEY soit requise pour l'agent conversationnel suggère une dépendance à la plateforme hébergée, même si des endpoints locaux comme Ollama sont listés.

Ce qu'OM1 ne fait pas, et à quoi le comparer

Trois limites ressortent du matériel fourni. La première est la parité Go/Python, déjà évoquée : des capacités annoncées pour OM1 vivent encore dans une branche dépréciée, donc la promesse modulaire n'est pas uniformément tenue selon le runtime. La deuxième est le couplage à l'écosystème OpenMind : le plan gratuit, l'unité OMCU et la clé d'API installent une dépendance commerciale que la licence MIT ne couvre pas, puisqu'une licence de code ne dit rien des conditions d'accès à un service. La troisième est l'absence, dans ce README, de tout détail sur le déploiement multi-agents alors que le dépôt est tagué multiagent. Face à cela, l'alternative la plus directe n'est pas un autre framework d'agent mais l'assemblage manuel : un nœud ROS2 qui publie les topics capteurs, un client Zenoh ou CycloneDDS pour le transport, et un service LLM appelé directement. La différence d'approche est nette. L'assemblage manuel vous laisse choisir chaque brique et ne dépend d'aucun portail, mais vous réécrivez la gestion d'état, la boucle perception-action et l'instrumentation de latence. OM1 fournit cette boucle et cette instrumentation en échange d'une configuration JSON5 à respecter et d'un fournisseur de clé. Pour une équipe qui possède déjà une pile ROS2 mature, l'apport d'OM1 se limite surtout au pipeline agent et aux endpoints préconfigurés ; pour une équipe qui part de zéro, c'est l'inverse.

Maintenance, versions et implications de licence

Le rythme de publication est irrégulier : des builds nightly datés du 4 juin 2026, puis deux bêtas v1.0.2-beta.1 et v1.0.2-beta.2 en avril 2026, avec un dernier push sur main au 4 septembre 2026. Autrement dit, la branche principale bouge après la dernière version étiquetée, et l'étiquette la plus récente est une bêta. Adopter OM1 aujourd'hui signifie donc suivre de près les nightly ou compiler depuis les sources, ce qui a un coût de maintenance : make deps et make build à chaque mise à jour, et une configuration JSON5 à faire évoluer avec le runtime. La licence est MIT, ce qui autorise en principe la modification et la redistribution du code. Deux réserves cependant. La bibliothèque C de Zenoh est embarquée dans le binaire, et sa licence propre n'est pas décrite dans le matériel fourni. Et surtout, la licence MIT porte sur le code, pas sur l'accès à la plateforme OpenMind ni sur les crédits OMCU, qui relèvent de conditions séparées. Je ne peux pas, à partir de ces seuls éléments, dire si un déploiement entièrement hors ligne est possible en pratique : le README liste Ollama parmi les endpoints, mais ne documente pas de mode sans clé OM_API_KEY. C'est la question à poser avant tout pilote.

Conclusion éditoriale

OM1 convient aux équipes qui veulent un pipeline agent unique, en Go, déployable sur linux-arm64 ou darwin-arm64 et branché sur Zenoh, ROS2 ou CycloneDDS. Il ne convient pas à qui refuse une clé OM_API_KEY, un quota OMCU ou un runtime dont une partie des capacités reste dans la branche Python dépréciée. Avant d'adopter, vérifiez deux choses concrètes : que le binaire de votre plateforme est présent dans les releases (linux-amd64, linux-arm64, darwin-arm64, darwin-amd64) et que les endpoints dont vous dépendez sont bien couverts par le runtime Go et non par le Python.

Sources officielles

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