Ibou lance ArseneLupin, ses modèles de décision open source

Sylvain Peyronnet, créateur du moteur de recherche français Ibou, a publié trois modèles de langage réunis sous le nom ArseneLupin. Contrairement aux chatbots classiques, ces modèles de décision ne génèrent pas de texte libre. Ils reçoivent un état, un texte, un ticket ou un objet JSON, ainsi que des questions typées : oui ou non, un choix parmi plusieurs options, ou une note sur une échelle.

Le système renvoie ensuite des probabilités directement exploitables par du code, pour trier des tickets de support, filtrer du spam ou router des contenus. Les trois versions, ArseneLupin v1.1, sa déclinaison mini et ArseneLupinstral, ont été mises en ligne sur Hugging Face sous licence Apache 2.0. Le code de service est fourni, mais pas celui de l'entraînement ni les données utilisées.

Un défi lancé à Jev de TypeSafe

Cette publication s'inscrit dans le sillage de Jev, le modèle de la société TypeSafe, présenté comme le premier des « System One », des IA pensées pour décider plutôt que bavarder. Depuis son lancement, plusieurs alternatives ouvertes sont apparues, dont Kev, développé par Jared Palmer sur la base de Qwen3.5 et Qwen3.8, et Laya, bâti sur un encodeur ModernBERT-large de 421 millions de paramètres.

ArseneLupin est la réponse d'Ibou à ce mouvement. Sur un test interne de classification d'intentions de recherche en dix catégories, la version 1.1 obtient 50,7 % de bonnes réponses, contre 39,7 % pour la version mini et 43,9 % pour Jev 1.13, selon les chiffres publiés par Ibou et rapportés par Korben. Ces résultats restent des mesures maison : aucun benchmark indépendant n'a encore été mené sur ces modèles, encore jeunes.

Trois tailles, trois usages

La v1.1 repose sur Qwen3.5-4B, la version mini sur Qwen3.5-0.8B, et ArseneLupinstral s'appuie sur Ministral 8B. Le modèle complet en bfloat16 pèse 9,3 Go, tandis qu'une version compressée en 8 bits pour llama.cpp descend à 4,5 Go. Le serveur accepte jusqu'à 32 768 tokens par option, un point que Korben juge décisif face à Kev, limité à des textes de 384 tokens au maximum lors de son entraînement.

Fonctionnement technique et premiers tests

Chaque option soumise au modèle devient une question fermée posée au Qwen affiné, du type « ce candidat décrit-il la bonne réponse ? ». Une petite tête de lecture, 2 561 paramètres sur la v1.1, transforme le dernier état caché du modèle en score, puis un softmax répartit ces scores en probabilités. Le serveur lit une seule fois le texte commun aux options avant de calculer tous les résultats en parallèle, ce qui limite le temps de traitement.

Testé sur un exemple de classification de veille technologique, le modèle attribue 0,72 de probabilité à la catégorie « ia », loin devant « dev » à 0,19, avec un score d'intérêt moyen de 1,47 sur une échelle de 0 à 2. Sur un cas de commentaire de spam grossier, la version v1.1 le détecte à 0,86 de probabilité, contre 0,76 pour la version mini, deux fois plus rapide en réponse. Aucun seuil de décision n'est imposé par le serveur : le champ « decision_status » reste « unthresholded », laissant à chaque développeur le soin de fixer sa propre limite de confiance avant d'automatiser une action.

Les formats de réponse diffèrent de ceux de Jev. Là où TypeSafe utilise un champ nommé « noul » pour les questions oui/non et un dictionnaire pour les notes, ArseneLupin renvoie un champ « p_yes » et range ses scores dans une liste. Un client déjà écrit pour l'API de Jev ne peut donc pas lire directement les réponses d'ArseneLupin, ce qui impose une couche de conversion pour comparer les deux systèmes sur les mêmes données.