JamAI Base : un tableur déclaratif pour pipelines RAG, avec SQLite et LanceDB intégrés
The collaborative spreadsheet for AI. Chain cells into powerful pipelines, experiment with prompts and models, and evaluate LLM responses in real-time. Work together seamlessly to build and iterate on AI applications.
En bref
- De quoi s’agit-il ?
- JamAI Base transforme des tables en pipelines LLM : colonnes génératives, tables de connaissances, tables de chat et orchestration de modèles, le tout derrière une interface proche d'un tableur et une API REST. Le point à trancher n'est pas la richesse fonctionnelle annoncée, mais le coût réel de l'auto-hébergement et les limites d'une base vectorielle embarquée.
- À qui s’adresse-t-il ?
- JamAI Base convient aux équipes qui veulent livrer une fonctionnalité RAG ou un chatbot adossé à des documents sans écrire elles-mêmes la boucle d'embedding, de recherche hybride et de reranking, et qui acceptent d'exploiter un service Python avec SQLite et LanceDB en local. Il ne convient pas aux charges multi-locataires à forte écriture, ni aux projets qui exigent un stockage vectoriel distribué et répliqué dès le départ.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 13 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : assembler une chaîne RAG sans écrire la plomberie
Le README décrit JamAI Base comme une plateforme backend RAG open source qui intègre une base de données embarquée SQLite et une base vectorielle embarquée LanceDB, avec mémoire gérée et capacités RAG. La cible est donc précise : une équipe qui sait ce qu'elle veut obtenir d'un modèle, mais qui ne veut pas coder elle-même la découpe des documents, le calcul des embeddings, la recherche hybride et le reranking. Le projet revendique une orchestration intégrée des LLM, des embeddings vectoriels et du reranker, exposée par une interface en forme de tableur et une API REST.
La notion de tableur n'est pas cosmétique. Elle sert à rendre visible une chaîne qui, ailleurs, vit dans du code : chaque colonne correspond à une étape, et l'ordre des colonnes décrit l'ordre du traitement. C'est un choix lisible pour un profil produit ou data, moins confortable pour un développeur qui veut versionner sa logique dans Git et la tester unitairement. Le README ne décrit pas de mécanisme d'export de la définition d'une table vers un fichier de configuration, donc ce point reste à vérifier dans la documentation SDK.
Quatre types de tables, un seul moteur d'exécution
Le README distingue quatre familles. Les tables génératives transforment une table statique en entité dynamique : les colonnes sont remplies par des LLM et exposées via un point de terminaison REST. Les tables d'action gèrent les échanges en temps réel entre un frontend et le backend LLM, avec, selon le README, une gestion automatique des entrées et sorties utilisateur. Les tables de connaissances stockent documents et données structurées pour fournir le contexte. Les tables de chat servent à construire des chatbots et peuvent s'appuyer sur n'importe quelle table de connaissances pour la partie RAG.
Cette séparation a une conséquence pratique : la même base SQLite héberge la métadonnée de toutes ces tables, tandis que LanceDB porte les vecteurs. Le README ne détaille pas le schéma interne ni la façon dont une table de chat référence une table de connaissances. On sait seulement que l'intégration est prévue. C'est suffisant pour comprendre l'architecture, insuffisant pour prédire le comportement quand plusieurs tables de connaissances alimentent un même chat.
Le RAG revendiqué : réécriture de requête, recherche hybride, chunking adaptatif
La section sur les techniques RAG est la plus concrète du README. Elle liste la réécriture de requête, la recherche hybride combinant recherche par mots-clés, recherche structurée et recherche vectorielle, le reranking, une gestion structurée du contenu, un chunking qualifié d'adaptatif et l'usage de BGE M3-Embedding, décrit comme multilingue et gratuit. C'est un ensemble cohérent : la réécriture améliore le rappel, la recherche hybride compense les faiblesses du seul vecteur, le reranking réordonne ce qui remonte.
Rien dans le README ne quantifie ces gains, et c'est normal : un README n'est pas un banc d'essai. Le point à retenir est ailleurs. Le chunking adaptatif est présenté comme automatique, ce qui veut dire que vous ne choisissez pas la taille des segments. Pour des documents très structurés (tableaux, code, contrats à articles numérotés), un découpage imposé par l'outil peut produire des frontières absurdes. Avant d'adopter JamAI Base pour ce type de corpus, il faut vérifier dans la documentation s'il existe un moyen de reprendre la main sur le découpage. Le README n'en mentionne aucun.
Mise en route : cloud ou services auto-hébergés
Le README propose deux chemins. Le premier est le cloud JamAI Base, avec inscription sur cloud.jamaibase.com ; le README mentionne des jetons LLM gratuits sans préciser de quota. Le second est l'auto-hébergement, renvoyé vers un guide pas à pas dont l'ancre est docs.jamaibase.com/sdk/python-sdk-documentation#oss. Le README lui-même ne donne aucune commande d'installation, aucun fichier de composition, aucune variable d'environnement. C'est une lacune réelle pour un lecteur qui veut évaluer la difficulté d'exploitation avant de cloner le dépôt.
Ce que le README fournit, ce sont les points d'entrée documentaires : la documentation SDK et plateforme sur docs.jamaibase.com, la documentation API sur jamaibase.readme.io, un CHANGELOG.md et un VERSIONING.md. Il signale aussi un MIGRATION_GUIDE.md pour passer de v1 à v2. Ce dernier document est le premier à ouvrir : une rupture majeure entre deux versions majeures indique un projet qui n'a pas encore stabilisé ses interfaces. Le README mentionne également des exemples de frontend, dont un chatbot avec NLUX sans backend, une variante NLUX avec Express.js et une démo Streamlit côté Python. Ces exemples sont utiles pour juger de l'ergonomie de l'API, pas pour juger de la tenue en charge.
La limite structurelle : SQLite et LanceDB dans le même processus
Le choix d'embarquer SQLite et LanceDB est ce qui rend l'installation simple et ce qui plafonne l'architecture. SQLite sérialise les écritures : sur une charge où plusieurs utilisateurs écrivent simultanément dans des tables d'action, c'est le premier point de contention, avant même le modèle. LanceDB est une base vectorielle orientée fichiers, sans service réseau séparé. Le README parle d'un design serverless et de scalabilité, mais un stockage local n'offre pas la réplication ni le basculement qu'on attend d'un backend partagé. La scalabilité annoncée repose donc sur la possibilité de dupliquer des instances, pas sur une montée en charge d'un même corpus.
Autre angle mort : la sauvegarde. Le README ne décrit aucune stratégie de copie de sécurité ni de migration de schéma. Si vos tables de connaissances contiennent des milliers de documents, la question n'est pas théorique. C'est le genre de sujet qui se traite avant la mise en production, pas après.
Face à LangChain : cadre imposé contre boîte à outils
La comparaison la plus directe se fait avec LangChain, que le README ne cite pas. La différence d'approche est nette. LangChain fournit des briques : chargeurs de documents, découpeurs, magasins vectoriels, chaînes, et vous assemblez le tout dans du code Python que vous contrôlez entièrement. JamAI Base fournit un cadre : les tables, leurs types et l'interface graphique déterminent la forme de votre application, et le REST prend le relais pour l'intégration.
Le compromis se lit ainsi. Avec LangChain, vous payez en code et en maintenance, mais vous choisissez votre base vectorielle, votre découpeur et votre stratégie de déploiement. Avec JamAI Base, vous payez en flexibilité : vous héritez de LanceDB, du chunking adaptatif et d'un modèle de données en tables. Pour un prototype de chatbot documentaire livré en quelques jours, le second est plus rapide. Pour un système où le découpage et le stockage sont des décisions d'architecture, le premier reste plus adapté. Aucun des deux n'est un mauvais choix en soi ; ils ne répondent pas à la même contrainte.
Maintenance, licence et coût de mise à jour
Le dépôt n'est pas archivé et le dernier push indiqué est le 3 septembre 2026. Les versions publiées dans le matériel fourni sont v0.3, v0.3.1 et v0.4, cette dernière datée du 14 février 2025. Un lecteur attentif remarquera l'écart entre cette date de version et la date du dernier push : le matériel ne permet pas de savoir ce qui a été livré entre les deux, ni si des versions plus récentes existent. Le CHANGELOG.md est le document à consulter pour combler ce trou.
La licence est Apache-2.0, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le texte de licence, et de signaler les fichiers modifiés. Apache-2.0 contient aussi une clause de brevets. Cela ne règle pas la question des modèles : si vous branchez une API propriétaire, ce sont les conditions du fournisseur qui s'appliquent, pas celles du dépôt. Je ne donne pas de conseil juridique ici ; faites relire votre cas si la redistribution fait partie de votre modèle.
Le coût de mise à jour se concentre sur un point : la migration v1 vers v2 documentée dans MIGRATION_GUIDE.md. Une rupture de ce type, sur un projet encore en v0.x, signifie que les mises à jour suivantes demanderont probablement une relecture du guide avant chaque montée de version. Budgétez ce temps, ou épinglez une version et assumez de ne plus suivre le dépôt.
Conclusion éditoriale
JamAI Base convient aux équipes qui veulent livrer une fonctionnalité RAG ou un chatbot adossé à des documents sans écrire elles-mêmes la boucle d'embedding, de recherche hybride et de reranking, et qui acceptent d'exploiter un service Python avec SQLite et LanceDB en local. Il ne convient pas aux charges multi-locataires à forte écriture, ni aux projets qui exigent un stockage vectoriel distribué et répliqué dès le départ. Avant de vous engager, vérifiez trois choses concrètes : le contenu réel de MIGRATION_GUIDE.md entre v1 et v2, la version exacte de LanceDB épinglée dans le dépôt, et le chemin de sauvegarde des fichiers SQLite et LanceDB dans votre déploiement. Le reste se décide sur ces trois points, pas sur la promesse d'interface.
Notes de la communauté