Le moteur IA multi-agents
Un serveur Python placé entre ce qui demande (une discussion, un script, un éditeur de code, un assistant vocal) et ce qui répond (environ dix-huit fournisseurs de modèles d'IA, des modèles locaux, Home Assistant). Pour chaque demande, il prend le chemin le moins cher qui suffit : une règle sans IA quand c'est possible, un modèle sinon, avec une bascule quand un fournisseur tombe. Il est né pour donner une voix à mon écran Home Assistant.
- Langage
- Python 3.12+
- API
- Compatible OpenAI
- Fournisseurs d'IA
- Environ 18
- Licence
- MIT
- Statut
- Développement actif
« Un cerveau fait maison pour Home Assistant et vos fournisseurs de LLM : des règles d'abord, un modèle seulement quand il sert. »
Première ligne du README de vromvrom-engine.
Ce qu'il fait
Pour chaque demande, le moteur prend le chemin le moins cher qui suffit : une règle, sans IA, quand la phrase est une commande ou une question connue de la maison (« éteins la lumière du salon ») ; un modèle sinon, avec une bascule quand un fournisseur échoue ; un plan de plusieurs agents seulement pour une tâche complexe. Il fonctionne aussi sans Home Assistant.
Choisir le bon modèle
Des mots-clés d'abord, sans modèle ; si la demande est ambiguë, un petit classifieur ou un petit modèle la range. Les modèles d'un même niveau sont ensuite classés selon un score Elo par domaine, le coût, le quota restant et la latence.
Travailler en parallèle
Une demande complexe devient un plan (planificateur, exécutants, relecteur) dont les tâches tournent en même temps (asyncio). C'est la partie la moins aboutie : elle marche dans les tests, mais aucune tâche complexe n'a tourné en 30 jours chez l'auteur.
Se réparer seul
Un coupe-circuit par fournisseur, des nouvelles tentatives espacées, la bascule vers le suivant selon la disponibilité et le budget, et une sonde de santé qui coupe les modèles en panne.
Se souvenir
Des faits, des résumés de sessions et un graphe, rangés dans SQLite, et une recherche dans vos documents par mots et par sens (ChromaDB, à construire une fois).
Parler à vos outils
Une API compatible OpenAI (/v1/chat/completions, en flux) utilisable depuis Cursor, Cline ou Continue ; un serveur MCP de 17 outils pour Claude ou Cursor et un client pour des serveurs MCP tiers ; des routes dédiées à Home Assistant.
Garder la main
En discussion, le modèle n'a que des outils de lecture sur Home Assistant : les appareils ne sont commandés que par des règles écrites. Les actions risquées demandent une validation humaine. Un système de plugins, des travailleurs distants et un tableau de bord (FastAPI et React).
Où il en est
Utilisé tous les jours
Les commandes et questions de la maison sans modèle (110 à 196 ms côté moteur pour une phrase du catalogue), la discussion avec bascule entre fournisseurs, le comptage des coûts : 86 vrais appels en 30 jours ont coûté 0,81 $ chez l'auteur.
Testé, moins utilisé
Le point d'accès compatible OpenAI (flux compris), MCP dans les deux sens et, depuis novembre 2026, la sauvegarde à chaud des bases de données.
Expérimental
Les plans multi-agents, le routeur d'apprentissage local (éteint sur une installation neuve) et le cycle autonome (Dreamer, DreamCoder).
Pas prêt à brancher
La voix de bout en bout par Home Assistant Assist : le composant qui envoie le texte reconnu au moteur (moteur_ia_conversation) n'est pas dans le dépôt. Le chat, l'API, les agents et MCP marchent sans lui.
Mesures du 01/11/2026 sur l'installation de l'auteur (un foyer, en français, avec Home Assistant). Le tableau complet, avec ses preuves, est dans le README.
Par où commencer
Le dépôt a un guide en cinq pages, en français et en anglais. Il a été vérifié par un vrai démarrage du moteur sur Windows 11 avec Python 3.13, sans clé de fournisseur ni Home Assistant ; Linux, macOS, Docker et systemd n'ont pas été essayés. Dans l'ordre :
- Installer : prérequis, Windows ou Linux, Docker, premier lancement et première demande.
- Exploiter, paragraphe sur les coûts : à lire avant de poser une clé de fournisseur, pour savoir ce qui consomme des jetons tout seul.
- Comprendre : ce qui se passe quand on envoie une demande.
- Réglages : chaque variable du
.envet chaque clé deconfig.json, avec son défaut. - Maison et voix : seulement si vous avez Home Assistant.
Ses limites
- Une seule personne, une seule clé d'API : ni comptes, ni rôles, ni budget par personne. Pour une équipe, une passerelle comme LiteLLM convient mieux.
- La voix demande un composant qui n'est pas publié (voir plus haut).
- Les statistiques de coût sont faussées : les sondes de santé sont comptées avec les vrais appels (27 805 appels comptés en 30 jours, dont 86 vrais).
- Beaucoup de fournisseurs, pas tous vivants : sur l'instance de l'auteur, la sonde de santé a coupé 42 modèles sur 76.
- Fait d'abord pour un développeur : le code, ses commentaires et beaucoup de ses noms sont en français ; environ la moitié du code est couverte par les tests (54 % le 01/11/2026).
- Un seul mainteneur, un code écrit en grande partie avec l'IA, aucune promesse de support.
La technique
- Python 3.12+ (la version testée en CI), FastAPI, asyncio, SQLite, ChromaDB, scikit-learn ; tableau de bord en React, Vite et TypeScript.
- Environ dix-huit fournisseurs d'IA pris en charge par le code, dans le cloud (Gemini, GitHub Models, DeepSeek, Anthropic, Mistral, OpenRouter…) ou en local (LM Studio, Ollama). Un fournisseur listé ne répond pas forcément aujourd'hui : la sonde de santé coupe ceux qui échouent.
- Tout tient dans des fichiers SQLite, sans serveur de base de données à faire tourner : l'instance de l'auteur tourne sur un Steam Deck, jour et nuit.
- Une image Docker et docker-compose, des tests pytest et une intégration continue. Quels modèles utiliser, à quel prix : STRATEGIES.
Outil personnel partagé tel quel, écrit avec beaucoup d'aide de l'IA : le tableau de bord a encore des angles vifs, et aucune version n'est publiée pour l'instant.