SMILE : une bibliothèque Java pour faire tenir statistiques, ML et tenseurs dans une seule JVM
Statistical Machine Intelligence & Learning Engine
En bref
- De quoi s’agit-il ?
- SMILE couvre la classification, la régression, la réduction de dimension et l'algèbre linéaire sous une même API Java, avec des variantes Scala et Kotlin. Sa contrainte la plus visible n'est pas algorithmique : elle est dans la version de Java exigée.
- À qui s’adresse-t-il ?
- SMILE convient aux équipes déjà sur la JVM qui veulent un seul jeu d'API pour les statistiques, la classification, la régression et la réduction de dimension, sans ajouter un service Python à côté. Il ne convient pas à un projet bloqué sur Java 17 ou 21, ni à ceux qui attendent une bibliothèque de deep learning généraliste : le volet deep learning repose sur LibTorch et le GPU.
- Puis-je l’utiliser commercialement ?
- À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 2 jours.
- En quel langage est-il écrit ?
- Principalement Java, 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 trou que SMILE cherche à combler sur la JVM
Un projet Java qui doit classer, régresser, réduire une matrice de plusieurs milliers de colonnes et tester une hypothèse se retrouve vite avec trois dépendances qui ne partagent ni types ni conventions. SMILE prend le problème par l'autre bout : un seul dépôt, un module base pour les structures de données, l'algèbre linéaire, les distributions, les tests d'hypothèses et les distances, et un module core pour les algorithmes d'apprentissage. Le README présente la bibliothèque comme un framework d'apprentissage automatique pour la JVM, avec des API Scala et Kotlin en plus de Java. Le public visé est donc précis : des ingénieurs et des data scientists qui produisent du code compilé, pas des notebooks. Si votre travail se fait en Python avec scikit-learn, SMILE n'apporte rien que vous n'ayez déjà. Si votre production est un service Java ou un pipeline Scala, la question devient celle du coût d'un pont vers Python, et c'est là que SMILE se défend.
base et core : la frontière entre calcul et apprentissage
La séparation des deux modules n'est pas cosmétique. base contient ce dont un algorithme a besoin pour exister : data frames, lecteurs et écrivains CSV, JSON, Parquet, Arrow, JDBC et Avro, transformations et encodeurs, formules à la R pour construire des matrices de modèle, distributions de probabilité, tests statistiques, noyaux, interpolation, graphes, tri, générateurs aléatoires, tenseurs CPU sans LibTorch, ondelettes et calcul parcimonieux. core empile les algorithmes : SVM, forêts aléatoires, AdaBoost, gradient boosting, KNN, Naïve Bayes, analyse discriminante, régression par processus gaussiens, LASSO, Ridge, ElasticNet, une longue liste de méthodes de clustering, t-SNE, UMAP, IsoMap, LLE, détection d'anomalies, HMM et CRF, ARIMA, extraction de règles d'association par FP-growth, et l'optimisation d'hyperparamètres. Cette organisation a une conséquence pratique : on peut dépendre de base seul pour de la statistique et du traitement de données, sans embarquer la totalité des algorithmes. Le README indique également un module dédié au deep learning avec un backend LibTorch et GPU, ainsi qu'un volet LLM avec inférence LLaMA-3, un tokenizer BPE de type tiktoken et un serveur REST compatible OpenAI avec streaming SSE. Ces deux derniers points méritent d'être lus comme des ajouts récents à un socle statistique, pas comme le cœur du projet.
Installer SMILE et choisir sa version de Java
Le point à trancher avant toute ligne de code est la version du JDK. Le README est explicite : SMILE v5 et au-delà exigent Java 25, la branche v4.x exige Java 21, et toutes les versions antérieures exigent Java 8. Une équipe sur Java 17 n'a donc pas de chemin simple vers la version courante : elle doit soit monter de version, soit rester sur une branche plus ancienne. Côté gestionnaire de paquets, l'artefact central est com.github.haifengl:smile-core, publié sur Maven Central. Le README donne les trois déclarations correspondantes : Maven, SBT pour Scala, Gradle pour Kotlin. Le module base se déclare séparément, ce qui permet de ne pas tirer core si l'on n'utilise que les data frames et les tests statistiques. Un point d'infrastructure est signalé dans la table des matières : une section Native Libraries (BLAS / LAPACK). Autrement dit, une partie des performances en algèbre linéaire dépend de bibliothèques natives à installer selon la plateforme. Le README ne détaille pas dans l'extrait fourni quelles opérations basculent sur ces bibliothèques et lesquelles restent en Java pur. C'est une zone à vérifier avant de dimensionner une machine de calcul.
Sérialisation, visualisation et l'IDE agentique
Trois sections du README sortent du catalogue d'algorithmes. La sérialisation des modèles permet d'entraîner quelque part et de servir ailleurs, ce qui est la condition d'un usage en production. La visualisation couvre deux mondes : des graphiques Swing (nuages de points, lignes, barres, boîtes, histogrammes, surfaces, heatmaps, contours) et des charts déclaratifs en Vega-Lite. Le choix de Swing surprend en 2026, mais il a une logique : c'est la seule boîte à outils graphique livrée avec la JVM, donc zéro dépendance supplémentaire pour un outil interne. Pour un rendu web, c'est Vega-Lite qu'il faut regarder. Le troisième élément est SMILE Studio, décrit comme un IDE agentique pour la data science en Python, Java ou Scala, avec une interaction en langage naturel. Le README renvoie à studio/README.md pour démarrer un premier projet. Je n'ai pas d'information dans le matériel fourni sur ce que produit réellement cet assistant, ni sur son mode de distribution. À traiter comme une brique à évaluer séparément, pas comme une raison d'adopter la bibliothèque.
Ce que SMILE ne fera pas pour vous
La liste des algorithmes est longue, et c'est précisément ce qui peut induire en erreur. Une bibliothèque qui propose à la fois du clustering spectral, des ondelettes et un serveur REST compatible OpenAI n'est pas nécessairement la meilleure sur chacun de ces terrains. Le volet deep learning s'appuie sur LibTorch : vous héritez donc d'une dépendance native lourde, avec ses propres contraintes de version CUDA et de plateforme, sans l'écosystème de modèles pré-entraînés qui accompagne PyTorch côté Python. Le volet LLM est décrit par des mots-clés (inférence LLaMA-3, tokenizer BPE, streaming SSE) sans indication dans l'extrait sur les tailles de modèle praticables ni sur le matériel requis. Un autre point de friction est la documentation : elle est éclatée en une trentaine de fichiers Markdown par module, chacun avec son propre guide. C'est une bonne chose pour la précision, moins pour la découverte. Enfin, la licence : l'identifiant renvoyé est NOASSERTION, ce qui signifie que l'outil d'analyse n'a pas su rattacher le fichier LICENSE à un identifiant SPDX connu. Le README contient bien une section License, mais son contenu n'est pas dans l'extrait fourni. Avant tout usage commercial, lisez le fichier LICENSE du dépôt. Je ne peux pas vous dire ici de quels termes il s'agit.
Face à Tribuo et aux bindings Python
L'alternative la plus directe sur la JVM est Tribuo, la bibliothèque d'Oracle Labs. La différence d'approche est nette : Tribuo s'organise autour de la notion de provenance et du suivi de l'origine des données et des modèles, avec des types de jeux de données fortement paramétrés, là où SMILE met en avant l'étendue des algorithmes et des primitives numériques. Si votre contrainte est l'auditabilité d'un modèle en production, Tribuo attaque le problème de front et SMILE ne propose rien d'équivalent dans le matériel fourni. L'autre alternative est de garder Python pour l'entraînement et d'exposer le modèle via un service, avec un client Java côté application. Le coût est un processus supplémentaire, un contrat d'interface à maintenir et une latence réseau par appel. Le gain est l'accès à l'écosystème Python. Le choix se joue donc sur une question simple : votre modèle doit-il être entraîné et servi dans le même processus JVM, ou acceptez-vous une frontière réseau ? SMILE n'a de sens que dans le premier cas.
Coût de maintenance et rythme de publication
Le dépôt n'est pas archivé et la dernière poussée indiquée est le 9 septembre 2026. Les versions récentes s'enchaînent : 6.3.0 le 18 août 2026, 6.2.5 le 2 août 2026, 6.2.4 le 13 juillet 2026. Ce rythme a deux effets opposés. Il indique un projet actif, ce qui limite le risque de rester bloqué sur un bug. Il implique aussi des montées de version fréquentes, et le saut de Java 8 à Java 21 puis à Java 25 sur les branches successives montre que ces montées ne sont pas toujours indolores. Une équipe qui épingle une version mineure devra prévoir un cycle de validation à chaque passage. Sur la licence, je répète la limite : l'identifiant NOASSERTION empêche toute conclusion automatique, et le contenu du fichier LICENSE n'est pas dans le matériel fourni. Vérifiez-le avant de bâtir dessus.
Conclusion éditoriale
SMILE convient aux équipes déjà sur la JVM qui veulent un seul jeu d'API pour les statistiques, la classification, la régression et la réduction de dimension, sans ajouter un service Python à côté. Il ne convient pas à un projet bloqué sur Java 17 ou 21, ni à ceux qui attendent une bibliothèque de deep learning généraliste : le volet deep learning repose sur LibTorch et le GPU. Avant d'adopter, vérifiez trois choses : la version exacte de Java dans vos images de build, le contenu réel du fichier LICENSE (l'identifiant NOASSERTION n'est pas un identifiant SPDX), et si vous avez besoin des routines natives BLAS/LAPACK ou si le chemin Java pur suffit.
Notes de la communauté