Transformers.js 4.3 : du JSON garanti par un modèle qui tourne dans le navigateur

Transformers.js permet de faire tourner des modèles d'IA directement dans une page web ou dans Node.js, sans envoyer les données à un service extérieur. Le modèle est téléchargé une fois, puis s'exécute sur la machine de l'utilisateur. La série 4.3, publiée entre le 16 septembre et le 28 octobre, lève un des freins à un usage sérieux : obtenir une réponse dans un format que le code peut exploiter.

La sortie structurée arrive

Un petit modèle local répond volontiers à côté du format demandé : un JSON mal fermé, un champ oublié, une phrase d'introduction en trop. La version 4.3.0 ajoute un mécanisme qui contraint la génération, jeton après jeton, à respecter l'un de ces trois cadres :

• un schéma JSON précis ;
• un objet JSON quelconque ;
• une expression régulière.

La fonction est livrée dans un paquet séparé, @huggingface/transformers-structured-output, décrit comme expérimental et sans dépendance. Le principe : on crée le pipeline de génération, on construit un StructuredOutputProcessor à partir de son tokenizer et du schéma, puis on le passe à l'appel avec l'option logits_processor.

L'exemple des notes de version s'appuie sur un modèle de 350 millions de paramètres, onnx-community/LFM2.5-350M-ONNX, exécuté sur la carte graphique avec device: "webgpu".

Deux limites sont indiquées :

• une seule séquence générée à la fois ;
• il faut prévoir une valeur de max_new_tokens assez grande pour que la réponse se termine, faute de quoi le JSON sera coupé.

WebGPU dans Safari

WebGPU est l'interface qui donne à une page web l'accès à la carte graphique, donc à des temps de réponse acceptables. La 4.3.0 l'active pour Safari 26 et les versions suivantes. Les notes de version n'en disent pas plus. Pour une application destinée au public, c'est un obstacle de moins : les utilisateurs de Safari 26 peuvent eux aussi faire travailler leur carte graphique.

Les deux correctifs d'octobre

• 4.3.1, le 7 octobre : prise en charge d'EmbeddingGemma 2, le modèle de Google DeepMind qui place texte, images, vidéo et audio dans un même espace de 768 dimensions. Le modèle est publié sous l'identifiant onnx-community/embeddinggemma-2-ONNX et compte 740 millions de paramètres au total. Les notes fournissent des exemples de recherche textuelle et de comparaison entre médias.
• 4.3.2, le 28 octobre : prise en charge des modèles LFM3 et LFM3-VL, une fonction getSupportedDevices() pour savoir quels modes d'exécution sont disponibles sur la machine, et deux corrections, dont un blocage de from_pretrained quand le téléchargement d'un fichier de données externe échouait.

La 4.3.0 ajoutait par ailleurs trois architectures de modèles (DeepSeek-V4, Zaya, HRM-Text) et corrigeait un double téléchargement des fichiers de modèle quand un suivi de progression était actif.

Ce qu'il faut garder en tête

• Aucune rupture de compatibilité n'est signalée dans ces trois notes de version.
• « Expérimental » signifie que l'interface du paquet de sortie structurée peut encore changer.
• Un JSON valide n'est pas un JSON exact. La contrainte garantit la forme, pas la justesse des valeurs. Un modèle de quelques centaines de millions de paramètres se trompe plus souvent qu'un grand modèle en ligne.
• Le premier chargement reste lourd : l'utilisateur télécharge le modèle avant de pouvoir s'en servir.
• Les notes de version ne donnent aucune mesure de vitesse.

Notre lecture

Pour une PME, l'intérêt est concret : extraire les champs d'un formulaire libre, classer un message ou préremplir une fiche sans qu'aucune donnée ne quitte le poste de l'utilisateur. C'est un argument simple face aux questions de confidentialité, et il n'y a pas de facture à l'appel. La bonne démarche consiste à monter un prototype sur un cas étroit, à mesurer le taux d'erreur sur de vrais exemples, et à prévoir une validation humaine ou un repli vers un modèle plus puissant quand le résultat paraît douteux. Le paquet étant expérimental, fixez précisément sa version dans vos dépendances.