Lealone : le SGBD Java qui se présente aussi comme un agent autonome

Deux projets dans un seul dépôt

Lealone se décrit dans son README comme un moteur de base de données relationnelle orienté OLTP, avec les mots-clés acid, newsql, replication et sharding dans les topics du dépôt. La même page annonce un agent conversationnel capable de générer une application à partir d'une phrase. Ces deux ensembles ne s'adressent pas aux mêmes personnes. Un moteur transactionnel se juge sur ses garanties ACID, ses performances en écriture concurrente et sa tolérance aux pannes. Un agent de génération de code se juge sur la qualité du code produit, sa reproductibilité et son coût par appel. Le dépôt ne sépare pas ces deux évaluations, et le lecteur doit faire le tri lui-même.

Le public visé, d'après le README, couvre le « 氛围编程 », c'est-à-dire la programmation par ambiance ou par intention, et les applications d'entreprise de toute taille. La fourchette est large. Un développeur solo qui veut prototyper une interface en quelques minutes et une équipe qui doit garantir la cohérence d'un schéma sur plusieurs nœuds n'ont pas les mêmes exigences de traçabilité. Le README ne précise pas laquelle des deux cibles prime dans les choix de conception.

Ce que fait réellement l'agent : du SQL qui crée du SQL

Le mécanisme central visible dans le matériel est une extension du langage SQL. L'agent ne produit pas de code Java ni de fichiers de configuration : il produit des instructions SQL que le serveur interprète. Le README donne cet exemple :

create service if not exists my_service ( hello(name varchar) varchar, get_current_time() varchar );

Puis execute service my_service hello('zhh'); pour appeler la fonction créée. Le service devient immédiatement accessible en HTTP, le README indiquant les URL http://localhost:8080/service/my_service/hello?name=zhh et http://localhost:8080/service/my_service/get_current_time. Le même schéma s'applique aux tables (create table if not exists user avec id long auto_increment primary key) et aux workflows (create workflow if not exists my_workflow avec un commentaire en langage naturel décrivant l'objectif).

Le flux est donc : une intention en langage naturel, une instruction SQL générée par le modèle, une exécution côté serveur, une route HTTP exposée. C'est une architecture qui a l'avantage de rester dans un seul langage de bout en bout. Elle a aussi une conséquence : tout ce que l'agent peut faire est borné par ce que la grammaire SQL de Lealone accepte. Un service qui aurait besoin d'une bibliothèque externe, d'un appel réseau sortant ou d'une logique de retry complexe ne rentre pas dans ce moule, du moins pas d'après les exemples fournis.

Mise en route : trois commandes et une clé d'API

La compilation se fait avec mvn assembly:assembly -Dmaven.test.skip=true. Le README précise que JDK 21 ou supérieur est nécessaire. Un jar précompilé est téléchargeable à l'adresse lealone-8.0.0-SNAPSHOT.jar sur le site du projet, ce qui évite la compilation pour un premier essai.

Le lancement du serveur se fait par java -jar lealone-8.0.0-SNAPSHOT.jar. Pour ouvrir l'agent, la commande est java -jar lealone-8.0.0-SNAPSHOT.jar -agent. La configuration du modèle se fait une seule fois, dans la fenêtre de l'agent, avec :

set llm ( provider: 'doubao', model: 'doubao-seed-2-0-pro-260215', api_key: 'remplacer par votre clé' );

Le README indique que seuls doubao et deepseek sont pris en charge à ce jour. Aucune variable d'environnement, aucun fichier de configuration externe n'est mentionné : la clé d'API passe par cette instruction SQL. Ce choix mérite attention, car il implique que la clé transite par le même canal que les requêtes et qu'elle est stockée quelque part côté serveur. Le README ne dit pas où.

Pour lancer une application décrite dans un fichier, la commande est java -jar lealone-8.0.0-SNAPSHOT.jar services.sql. Le fichier d'exemple contient les services, la table et le workflow dans un seul script.

Ce que le README ne dit pas

Plusieurs questions restent sans réponse dans le matériel fourni. La persistance des services créés n'est pas décrite : un service créé par create service survit-il à un redémarrage du serveur, et sous quelle forme ? Le README ne le précise pas. La gestion des erreurs de l'agent non plus : que se passe-t-il si le modèle produit une instruction SQL invalide, ou si l'API du fournisseur est indisponible ? Aucun comportement de repli n'est documenté.

Le coût est également absent. Générer une application complète prend, selon le README, « une vingtaine de secondes », mais le nombre de jetons consommés et le tarif correspondant ne sont pas indiqués. Pour une utilisation en production, cette omission est gênante, car le coût par génération devient un paramètre d'exploitation.

Enfin, la licence. GitHub renvoie NOASSERTION, ce qui signifie que l'outil n'a pas su reconnaître un identifiant SPDX standard. Le dépôt pointe vers LICENSE.md, mais le contenu de ce fichier n'est pas reproduit dans le matériel fourni. Tant que ce point n'est pas clarifié, aucune décision d'adoption en entreprise ne peut être prise sérieusement. Ce n'est pas un détail administratif : une licence non standard peut restreindre la redistribution ou l'usage commercial de manière non évidente.

Le cas où Lealone est le mauvais outil

Lealone n'est pas adapté si vous avez besoin d'un moteur de base de données que vous pouvez auditer ligne par ligne avant de le mettre en production. Le projet se présente comme un moteur NewSQL avec réplication et sharding, mais aucune documentation de ces mécanismes n'apparaît dans le matériel fourni. Comparé à PostgreSQL, dont la documentation de réplication et de partitionnement est publique et détaillée, Lealone demande une confiance que rien ici ne vient étayer.

Il n'est pas non plus adapté si votre équipe ne peut pas utiliser un fournisseur de modèle externe. L'agent dépend de doubao ou deepseek, et le README ne mentionne aucun mode local ou auto-hébergé. Une organisation qui interdit l'envoi de code ou de schémas à un service tiers ne pourra pas utiliser la partie agent, même si le moteur SQL seul reste utilisable.

Un troisième cas : les projets où la logique métier ne se laisse pas exprimer en SQL. Le workflow décrit par un commentaire en langage naturel est séduisant, mais le README ne montre qu'un exemple trivial (trouver un utilisateur, le saluer, donner l'heure). Rien n'indique comment un workflow gère une branche conditionnelle, une transaction distribuée ou une compensation en cas d'échec partiel.

Comparaison avec jOOQ et les générateurs de code SQL

jOOQ part d'un principe inverse. Là où Lealone accepte du SQL écrit à la main ou généré par un modèle, jOOQ génère du code Java typé à partir d'un schéma existant. La différence est structurelle : avec jOOQ, le schéma est la source de vérité et le code Java en découle, avec vérification à la compilation. Avec Lealone, l'instruction SQL est la source de vérité et le service HTTP en découle, sans vérification statique côté client.

Concrètement, une requête jOOQ qui référence une colonne inexistante ne compile pas. Un create service Lealone qui référence une table inexistante échoue à l'exécution, au moment où l'agent tente de l'appeler. Pour un prototype, cette différence est mineure. Pour une application d'entreprise avec plusieurs développeurs, elle change la nature des erreurs que l'on découvre en production.

jOOQ ne propose pas d'agent conversationnel, et Lealone ne propose pas de génération de code typé. Les deux outils ne résolvent pas le même problème, mais ils occupent tous deux l'espace entre le SQL brut et le code applicatif. Le choix dépend de ce que vous voulez comme source de vérité.

Coût de maintenance et rythme de publication

Les releases listées dans le matériel sont lealone-6.0.1 (août 2024), lealone-6.0.0 (mars 2024) et lealone-5.2.2 (mars 2024). Le README, lui, renvoie vers un jar lealone-8.0.0-SNAPSHOT, et le dernier push sur le dépôt date de septembre 2026. Il y a donc un écart entre la dernière version publiée et la version snapshot utilisée dans les exemples. Une équipe qui veut une version stable devra se contenter de la 6.0.1, dont on ne sait pas si elle dispose des fonctionnalités d'agent décrites dans le README, qui semblent viser la 8.0.0.

Ce décalage a un coût direct : les instructions du README (set llm, create service, create workflow) ne sont peut-être pas disponibles dans la dernière version publiée. Il faut soit compiler le snapshot soi-même, soit attendre une release 8.0.0 stable. Le README ne donne aucune indication sur ce point.

Sur la licence, la seule chose vérifiable est que GitHub ne reconnaît pas d'identifiant SPDX. Avant toute intégration dans un produit distribué, il faut ouvrir LICENSE.md et le faire lire par quelqu'un dont c'est le métier. Le README ne donne aucune indication sur les obligations de mention ou de redistribution.

Conclusion éditoriale

Lealone vise deux publics distincts que le README traite ensemble : les équipes Java qui veulent un moteur OLTP ACID avec réplication et sharding, et celles qui veulent générer des services via un agent LLM. Les premières devraient vérifier d'abord la licence (GitHub renvoie NOASSERTION, il faut lire LICENSE.md) et la compatibilité JDK 21 avant tout essai. Les secondes doivent savoir que le README ne documente ni la persistance des services générés, ni la gestion des erreurs de l'agent, ni le coût des appels au modèle. La commande à exécuter en premier reste java -jar lealone-8.0.0-SNAPSHOT.jar services.sql pour voir si le fichier d'exemple passe sur votre machine.

Sources officielles

1. Issues
2. lealone/Lealone on GitHub
3. README
4. Releases