Simba : un assistant client open source dont l'argument est l'évaluation, pas la démo

Le problème visé : un assistant client qu'on peut noter

Le README pose le diagnostic en une ligne : les solutions fermées empêchent de mesurer la qualité de l'IA. Simba répond par une conception organisée autour de l'évaluation et de la personnalisation. C'est la promesse centrale du projet, et elle détermine tout le reste : le pipeline RAG est fait pour être remplacé pièce par pièce, pas pour être consommé tel quel.

Le public visé est donc précis. Une équipe qui branche un chatbot sur sa documentation et qui veut savoir si les réponses s'appuient réellement sur les documents récupérés. Pas une équipe qui cherche à mettre un widget en ligne en dix minutes et à ne plus y toucher. Le README parle de contrôle total et d'absence de dépendance à un fournisseur, ce qui suppose d'accepter la charge d'exploitation correspondante.

Les thèmes déclarés du dépôt (customer-service, evals, knowledge-base, llm, rag) confirment le positionnement. Rien n'indique un module de ticketing, de routage d'agents humains ou de gestion de files d'attente : le périmètre est la réponse automatique appuyée sur une base de connaissances, avec des mesures autour.

Ce qui circule entre le navigateur, FastAPI, Celery et le magasin vectoriel

Le schéma d'architecture du README est le document le plus utile du dépôt. Le widget installé sur le site appelle une API Simba écrite avec FastAPI. Cette API interroge un magasin vectoriel, Qdrant ou FAISS selon la configuration, et un LLM, OpenAI ou un modèle local. En parallèle, une file Celery alimentée par Redis prend en charge l'ingestion des documents : c'est le chemin asynchrone, séparé du chemin de réponse.

Cette séparation a une conséquence pratique. L'indexation d'un gros volume de fichiers ne bloque pas les conversations en cours, puisque les tâches passent par Redis et sont exécutées par les workers Celery. En contrepartie, il faut surveiller deux files de travail distinctes : celle des requêtes utilisateur et celle de l'ingestion. Un worker Celery arrêté ne casse pas le chat, mais la base de connaissances cesse silencieusement de se mettre à jour. Le README ne décrit pas de mécanisme d'alerte sur ce point.

La personnalisation annoncée couvre cinq familles : magasin vectoriel (Qdrant, FAISS, Chroma), embeddings (OpenAI, HuggingFace, Cohere), LLM (OpenAI, Anthropic, modèles locaux), reranker (Cohere, ColBERT, cross-encoder) et parseurs (Docling, Unstructured, PyMuPDF). Le README présente ces options sous forme de tableau, sans indiquer lesquelles sont réellement testées ensemble. C'est une réserve à garder en tête : une liste de compatibilités n'est pas une matrice de validation.

Démarrer : deux chemins, dont un qui suppose Docker

La voie recommandée par le README passe par Docker. On clone le dépôt, on crée un fichier .env contenant une clé OPENAI_API_KEY, puis on lance la construction et le démarrage avec une variable DEVICE qui choisit le matériel : DEVICE=cpu make build && make up, ou DEVICE=cpu remplacé par DEVICE=cuda pour une carte NVIDIA. Le tableau de bord est ensuite accessible sur http://localhost:3000.

L'autre chemin évite Docker : pip install simba-core, puis deux commandes séparées, simba server et simba front. Le README ne précise pas ce que ces deux processus attendent comme configuration, ni s'ils démarrent Redis et le magasin vectoriel. Si vous prenez cette route, prévoyez de vérifier vous-même ces dépendances : le matériel fourni ne le dit pas.

Pour le développement, le dépôt documente une intégration avec Claude Code : /setup --all installe les dépendances Python, le frontend et le paquet npm, et démarre les services d'infrastructure. Des variantes existent, /setup --backend, /setup --frontend et /setup --services, pour ne faire qu'une partie du travail. C'est un choix inhabituel : l'outillage de développement dépend d'un assistant tiers, ce qui n'aide pas un contributeur qui ne l'utilise pas.

Côté site web, l'intégration tient en un paquet npm, simba-chat-widget, et un composant SimbaChat qui prend au minimum apiUrl et theme. Le README ne documente pas d'autres propriétés, ni la gestion de l'authentification entre le navigateur et l'API.

Les métriques annoncées et ce que le dépôt n'en dit pas

Le README distingue trois familles de mesures. Pour la récupération : précision, rappel, scores de pertinence. Pour la génération : fidélité au contexte, pertinence de la réponse, latence. Pour les conversations : satisfaction utilisateur et taux de résolution.

Cette liste est celle des indicateurs visés, pas la preuve qu'ils sont tous calculés. La satisfaction utilisateur, en particulier, ne peut pas être déduite automatiquement d'un échange : elle suppose un retour explicite du client ou une notation par un humain, et le README ne décrit aucun de ces deux mécanismes. Le taux de résolution pose le même problème de définition. À l'inverse, la précision et le rappel de la récupération sont calculables sans intervention humaine, mais seulement si l'on dispose d'un jeu de questions avec les documents attendus. Le README ne mentionne pas un tel jeu de référence, ni comment le constituer.

C'est la limite la plus sérieuse de la documentation actuelle. Un cadre d'évaluation sans corpus annoté mesure surtout la latence et la pertinence perçue. Avant d'adopter Simba pour cette raison précise, la première chose à inspecter est le code d'évaluation lui-même, pour voir quelles métriques ont une implémentation et sur quelles entrées elles s'appuient.

Ce que l'absence de multi-tenant implique concrètement

La feuille de route du README coche trois éléments : cadre d'évaluation, widget npm, réponses en streaming. Quatre restent ouverts : support multi-tenant, tableau de bord analytique avancé, intégrations par webhooks, pipeline de fine-tuning.

Le multi-tenant non coché est le point le plus lourd pour un usage réel. Une équipe qui héberge Simba pour plusieurs marques ou plusieurs clients doit aujourd'hui séparer les déploiements, avec un magasin vectoriel et un jeu de workers par locataire. Le README ne décrit aucune notion d'espace de travail, de cloisonnement d'index ou de filtre par organisation. Si votre cas d'usage est une plateforme unique servant plusieurs clients, Simba vous demandera de construire cette couche vous-même, au-dessus de l'API.

Deux autres absences comptent. Pas de webhooks signifie qu'il faut interroger l'API pour récupérer des conversations ou des métriques, sans notification sortante. Pas de pipeline de fine-tuning signifie que l'amélioration passe par la base de connaissances et les prompts, pas par l'ajustement du modèle.

Un dernier point relève de la maintenance : le README indique qu'on peut remplacer chaque composant, mais cette liberté a un coût. Chaque combinaison de parseur, d'embedding et de reranker est une configuration à maintenir et à revalider lors des mises à jour. Une équipe qui change de modèle d'embedding doit réindexer l'intégralité du corpus, ce que le README ne rappelle pas.

Face à quoi le comparer vraiment

La comparaison la plus directe se fait avec une chaîne RAG assemblée à la main : LlamaIndex ou LangChain pour l'orchestration, un serveur FastAPI écrit par vous, un magasin vectoriel, et un outil d'observabilité LLM séparé pour les traces et les métriques.

La différence n'est pas la technologie employée, qui est largement la même, mais ce qui est fourni d'avance. Avec une chaîne assemblée, vous écrivez le service d'ingestion, la file de tâches, le tableau de bord et le widget. Avec Simba, ces quatre éléments existent déjà et sont reliés entre eux. En échange, vous héritez de ses choix : Celery et Redis comme file de tâches, FastAPI comme API, Next.js côté interface. Remplacer Celery par autre chose revient à réécrire la partie ingestion.

L'autre différence tient à la place de l'évaluation. Dans une chaîne assemblée, les métriques sont un ajout que l'on branche après coup, souvent via une plateforme externe. Simba les présente comme faisant partie du produit. C'est un avantage réel si les métriques sont effectivement implémentées, et un surcoût de documentation si elles ne le sont qu'en partie. La vérification tient en une question : ouvrez le code d'évaluation et regardez quelles fonctions calculent quoi.

Licence, coût de mise à jour et rythme du dépôt

Simba est publié sous Apache-2.0. Cette licence permet l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le texte de licence, et d'indiquer les fichiers modifiés. Elle comporte aussi une clause de brevets. Le dépôt n'indique pas de fichier NOTICE, et rien dans le matériel fourni ne précise quelles dépendances sont embarquées : si vous redistribuez Simba, c'est le point à vérifier en premier. Ce paragraphe décrit la licence, il ne constitue pas un avis juridique.

Le rythme des versions publiées est irrégulier. Trois versions se succèdent en mars 2025 : v0.2.0 le 6, v0.3.0 le 7, v0.4.0 le 11. Ensuite, le matériel fourni ne montre plus de publication de version, alors que le dépôt a reçu des commits jusqu'en juin 2026. Autrement dit, du travail continue sur la branche principale sans être étiqueté. Pour une équipe qui épingle une version, cela signifie que les correctifs récents ne sont accessibles qu'en suivant main, avec le risque de rupture que cela comporte sur une API encore en 0.x.

Le coût de mise à jour se répartit sur trois surfaces : le paquet Python simba-core, le paquet npm simba-chat-widget et les images Docker. Une montée de version du backend peut exiger une réindexation si le format d'embedding change. Le README ne fournit pas de procédure de migration entre versions, ce qui rend ce point à vérifier au cas par cas.

Conclusion éditoriale

Simba convient aux équipes qui veulent un assistant client auto-hébergé et qui acceptent de faire tourner elles-mêmes FastAPI, Celery, Redis et un magasin vectoriel, parce qu'elles ont besoin de mesurer la récupération et la génération sur leurs propres documents. Il ne convient pas à qui cherche un SaaS clé en main ou du multi-tenant : la feuille de route le liste encore comme non coché. Avant de vous engager, vérifiez le contenu de simba-core sur PyPI, les options réellement acceptées par le widget simba-chat-widget, et si le tableau des métriques décrit des calculs disponibles ou seulement des intentions.

Sources officielles

1. GitHamza0206/simba on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases