Inkling 2 Small : un nouveau modèle à poids ouverts
Découvrez les performances d’Inkling 2 Small, ses limites et ce que son ouverture pourrait changer pour l’IA à poids ouverts hors de Chine.
Inkling 2 Small peut-il rebattre les cartes de l'IA ouverte ?
Les modèles d'intelligence artificielle à poids ouverts sont devenus un vrai terrain de jeu stratégique. L'idée, c'est de pouvoir adapter un modèle à ses besoins, mieux contrôler son déploiement et, parfois, réduire la dépendance aux offres des grands fournisseurs. Le problème, c'est que, ces dernières années, beaucoup des modèles les plus performants dans cette catégorie ont souvent été lancés depuis la Chine. Pour les acteurs européens et américains, combler l'écart relève autant de la technique que du business.
Thinking Machines Lab, la jeune entreprise fondée par Mira Murati (ex-directrice technique d'OpenAI), a annoncé Inkling 2 Small. D'après l'évaluation d'Artificial Analysis relayée à sa sortie, le modèle obtient de bons résultats pour sa catégorie, notamment en programmation et en automatisation. L'entreprise a aussi annoncé qu'elle publierait ses poids après une période de vérification, plutôt que de les livrer dès le lancement.
Tout ça mérite d'être pris au sérieux. Mais attention : de bons scores ne suffisent pas à dire qu'Inkling 2 Small est « le meilleur choix » pour un produit ou une équipe donnée. Il faut regarder le coût, la vitesse, la fiabilité, et surtout ce que ça change concrètement quand on déploie le modèle. Voici ce que l'annonce dit, ce qu'elle ne prouve pas encore, et comment évaluer le modèle sans confondre un benchmark et un avantage opérationnel.
Qu'est-ce qu'Inkling 2 Small ?
Inkling 2 Small est un modèle d'IA développé par Thinking Machines Lab. Il compte 594 milliards de paramètres, accepte des images en entrée et produit du texte. L'entreprise met en avant ses capacités en conception web et en création de jeux, ainsi que des performances en programmation et dans des boucles d'agents capables d'enchaîner plusieurs actions.
Le terme « Small » ne veut pas forcément dire « facile à faire tourner ». Avec 594 milliards de paramètres, le déploiement peut demander des ressources importantes, selon l'architecture, les formats de poids disponibles et les techniques d'inférence. Pour une entreprise, la taille du modèle est donc un point de départ - pas une promesse directe sur le coût réel.
Un modèle présenté comme plus efficace pour les agents
Thinking Machines affirme avoir évalué non seulement le code généré, mais aussi l'approche du modèle pour résoudre des problèmes de programmation. Sur le papier, c'est pertinent. Dans une tâche réelle, un agent doit souvent : comprendre la demande, choisir une action, utiliser un outil, interpréter le résultat et corriger si besoin. Le code final compte, mais il ne raconte pas toute la séquence.
Un modèle peut sortir du code « correct » mais exiger beaucoup de relances. Dans ce cas, il coûte plus cher et ralentit le travail. À l'inverse, un modèle qui planifie mieux, respecte les contraintes et sait s'arrêter au bon moment peut être plus utile, même si son score sur un test isolé est moins impressionnant. L'entreprise décrit Inkling 2 Small comme plus simple à intégrer dans des boucles d'agents et plus performant en programmation. Ça vaut la peine d'y croire - mais ça doit être confirmé sur vos cas d'usage et vos outils.
Une ouverture annoncée après des vérifications
Au moment de l'annonce, Thinking Machines indiquait que les poids seraient publiés la semaine suivante. Donc le modèle était présenté avant d'être réellement disponible sous forme de fichiers exploitables. L'entreprise justifiait ce délai par la nécessité de faire des vérifications de sécurité et de cybersécurité avant une diffusion plus large.
Cette logique « on annonce, puis on publie » est importante à comprendre : une entreprise peut présenter un modèle via une interface et ne pas livrer immédiatement les fichiers nécessaires à une exécution autonome. Il faut donc distinguer le lancement du modèle, l'accès API éventuel et la mise à disposition effective des poids. Et l'annonce d'une publication future ne garantit ni que les poids seront utilisables comme vous l'entendez, ni que la licence couvrira tous les usages envisagés.
Que disent les scores et où sont les limites ?
Artificial Analysis attribue à Inkling 2 Small un score de 31 sur son Intelligence Index. Cet indice composite combine des évaluations de programmation, de sciences et de capacités générales. Dans le classement rapporté, le modèle se situe au-dessus de la moyenne de sa catégorie et serait au même niveau que Gemini 3.8 Flash. À titre de comparaison, Gemini 4 Carbon et Claude Opus 5.5 affichent respectivement 60 et 59 dans ce classement.
Ces comparaisons méritent d'être lues avec prudence. Un indice synthétique facilite le suivi - mais il agrège des tests différents et ne répond pas à une question du type : « est-ce que, chez nous, on divise vraiment le temps de traitement par deux ? ». Deux modèles proches dans un classement peuvent se comporter très différemment sur du français, dans vos outils internes, sur des consignes longues ou dans vos données métier.
Des progrès mesurés par rapport au modèle précédent
L'évaluation citée mentionne une progression de 41 % des capacités d'automatisation et de 20 % en programmation par rapport au prédécesseur, Inkling Small. Ce sont des chiffres intéressants, mais leur portée dépend de la façon dont les tests sont composés et des tâches réellement mesurées. Et surtout : ce n'est pas une preuve que, dans un contexte professionnel, le gain sera du même ordre.
Pour analyser ça sérieusement, l'idéal est de regarder trois niveaux séparément :
- Le score de benchmark : utile pour situer le modèle par rapport à d'autres évalués avec une même méthode.
- La qualité sur des tâches proches de votre usage : génération de code, analyse de documents, assistance aux équipes ou automatisation de processus.
- Le coût complet : appels, reprises, supervision humaine, infrastructure et incidents (ceux qu'on évite, mais aussi ceux qu'on provoque).
Sinon, on retombe dans une erreur classique : choisir un modèle parce qu'il est bien classé, puis découvrir que le « gain » disparaît dès qu'on ajoute confidentialité, contrôles métier et temps de correction.
Une amélioration de l'exactitude, mais une fiabilité pas encore « verrouillée »
Artificial Analysis rapporte aussi une baisse du taux d'hallucination sur son test AA-Omniscience v1.1 : de 61 % (Inkling Small) à 27 % (Inkling 2 Small). L'exactitude passe de 32 % à 34 %, tandis que le taux de tentative baisse de 77 % à 53 %.
Ces chiffres ne racontent pas la même histoire. La baisse des hallucinations est plutôt rassurante. Mais l'augmentation de l'exactitude reste modeste. La baisse du taux de tentative peut aussi vouloir dire que le modèle s'abstient plus souvent quand sa confiance est faible. Dans un contexte sensible, ça peut être une bonne chose - mieux vaut ne pas répondre que répondre n'importe quoi. Mais dans un outil d'assistance où l'utilisateur attend une proposition initiale, ça peut au contraire multiplier les demandes sans réponse claire.
D'où la question pratique : « ne pas tenter » veut dire quoi dans votre cas d'usage ? Pour une recherche interne, une réponse du type « je n'ai pas d'éléments fiables » peut être saine. Pour un agent chargé de préparer un brouillon, trop d'abstention peut rendre le système peu utile. Au final, la bonne mesure n'est pas seulement le taux d'hallucination : c'est l'équilibre entre exactitude, abstention, coût de vérification et conséquences d'une erreur.
Le coût et la vitesse changent vraiment la donne
L'analyse décrit le modèle comme relativement lent par tâche et un tarif « quelque peu élevé » pour sa catégorie : 0,30 dollar par million de jetons en entrée, contre une médiane de 0,24 dollar. Le prix affiché ne suffit pas à comparer toute l'économie d'un système. Un modèle plus cher peut rester intéressant s'il réduit les erreurs, les appels répétés ou le temps de supervision. Inversement, un modèle moins cher peut revenir plus coûteux si les corrections sont plus nombreuses.
La vitesse compte aussi, au-delà du confort utilisateur. Pour un agent qui enchaîne plusieurs appels, quelques secondes de plus par étape peuvent faire exploser le temps total. Ça limite le parallélisme et augmente la facture d'infrastructure. Les équipes devraient donc raisonner en coût par tâche terminée et validée, pas en « coût théorique par million de jetons ».
Pourquoi l'ouverture des poids compte-t-elle ?
Les poids, ce sont les paramètres appris par le modèle. Les rendre disponibles peut permettre à des équipes de déployer sur leur propre infrastructure, d'adapter le modèle ou de l'étudier plus directement. C'est particulièrement utile quand on veut mieux contrôler la localisation des données, réduire la dépendance à un fournisseur ou intégrer le modèle à une architecture existante.
Mais « à poids ouverts » ne veut pas dire automatiquement « logiciel libre » au sens où tout le monde pourrait utiliser, modifier et redistribuer sans contrainte. Tout dépend de la licence, des restrictions d'usage, des fichiers réellement fournis, de la documentation et des outils nécessaires. Avant de décider, il faut lire les conditions de distribution et vérifier qu'elles correspondent à votre projet.
Une compétition qui ne se limite pas aux scores
Les modèles de DeepSeek et de Moonshot ont souvent occupé une place importante dans les classements de modèles ouverts. Ça alimente une compétition qui ne porte pas seulement sur la qualité des réponses. Elle touche aussi les coûts, l'accès à l'infrastructure, la capacité à déployer rapidement des mises à jour et, pour les développeurs, la possibilité de construire au-dessus des modèles.
L'annonce d'Inkling 2 Small va donc dans le sens d'une diversification. Selon Artificial Analysis, si les poids sont bien publiés, le modèle pourrait devenir le mieux classé des modèles à poids ouverts développé hors de Chine, d'après les classements disponibles à ce moment-là. Mais cette formulation a des limites : elle dépend de la date, des modèles comparés et de la méthode. Elle ne prouve pas qu'un acteur occidental aurait durablement dépassé l'ensemble de ses concurrents.
Le précédent français de Mistral et son modèle Le Chonk illustre bien aussi ce mouvement. D'après les éléments rapportés, ce modèle a été diffusé progressivement et se démarque en programmation. Pour les entreprises européennes, le point n'est pas de « privilégier l'origine ». L'enjeu, c'est d'avoir plusieurs options compétitives, documentées et compatibles avec les exigences locales.
Ouverture, sécurité et gouvernance
Publier les poids élargit les possibilités de déploiement, mais ça réduit aussi la capacité du fournisseur à contrôler chaque usage. Une fois téléchargé, un modèle peut être exécuté dans différents environnements et modifié dans les limites techniques et juridiques applicables. C'est à la fois un avantage de contrôle et une responsabilité supplémentaire pour l'organisation qui opère le système.
Concrètement, un déploiement en entreprise française ou européenne doit intégrer :
- La protection des données : décider quelles données sont transmises, stockées ou utilisées pour adapter le système, conformément aux règles applicables (dont le RGPD).
- La gestion des accès : limiter qui peut appeler le modèle et qui peut consulter ses résultats.
- La traçabilité : garder des traces des versions du modèle, des consignes, des outils utilisés et des résultats pertinents pour analyser les erreurs.
- La supervision : déterminer quelles réponses peuvent être utilisées directement et lesquelles nécessitent validation.
- La sécurité opérationnelle : tester les comportements face aux entrées malveillantes, aux données douteuses et aux tentatives d'extraction d'informations.
Le fait de publier après examen peut réduire certains risques avant la sortie, mais ça ne remplace pas l'évaluation menée par votre équipe au moment du déploiement. L'organisation reste responsable de son intégration, de ses données et des décisions prises à partir des résultats. Et le mot « ouvert » ne doit donc pas être interprété comme une garantie automatique de conformité ou de sécurité.
Comment une entreprise peut-elle évaluer ce modèle ?
La vraie question n'est pas « Inkling 2 Small est-il meilleur ? », mais : « est-ce qu'il est meilleur pour cette tâche, avec nos contraintes et notre coût cible ? ». Sans ça, on tombe vite dans des évaluations générales qui ne servent à rien au moment de choisir.
Pour une équipe produit, une banque, un éditeur de logiciel ou une administration, les critères de réussite ne seront pas les mêmes.
Construire un test représentatif
Commencez par sélectionner un ensemble limité de tâches réelles (anonymisées si nécessaire). L'objectif est de couvrir à la fois les cas fréquents et les cas difficiles. Pour un assistant de programmation, ça peut inclure la compréhension d'une base de code, la correction d'un défaut, l'écriture de tests et l'explication d'un changement. Pour un service client, retrouver une règle dans une base documentaire, rédiger une réponse et signaler les cas qui doivent passer à un humain.
Évitez de ne tester que des exemples qui « avantagent » le modèle. Votre jeu de tests doit inclure des demandes ambiguës, des informations manquantes et des consignes contradictoires. Il doit aussi refléter la langue et le vocabulaire réellement utilisés par vos équipes : français métier, acronymes internes, formulations typiques des clients.
Mesurer le résultat, pas seulement la réponse
Pour chaque tâche, définissez au départ ce qu'est un succès. Une réponse fluide n'est pas forcément correcte. Une fonction peut compiler tout en introduisant une régression. Une synthèse peut paraître convaincante en omettant une réserve importante.
Un tableau d'évaluation pragmatique peut aider :
| Mesure | Question à trancher |
|---|---|
| Exactitude | La réponse est-elle correcte selon une grille validée par un expert métier ? |
| Taux de reprise | Quelle part des résultats doit être corrigée ou rejetée ? |
| Abstention | Le modèle sait-il signaler qu'il manque d'informations ? |
| Latence | Le délai reste-t-il acceptable dans le parcours utilisateur ? |
| Coût par résultat utile | Combien coûte une tâche terminée et validée, reprises comprises ? |
| Robustesse | Le résultat reste-t-il stable face à des variantes réalistes de la demande ? |
Comparez ensuite Inkling 2 Small à au moins une solution déjà utilisée et à une option de référence. Sans comparaison, une amélioration mesurée « en soi » ne suffit pas à justifier migration et intégration.
Décider si les poids ouverts apportent une vraie valeur
L'accès aux poids devient intéressant quand l'entreprise a une raison opérationnelle de les exploiter : déploiement sur site, personnalisation, contrôle de version, ou réduction d'une dépendance fournisseur. Si vous comptez n'utiliser qu'une API gérée, l'ouverture des poids pèsera moins face à la stabilité du service, la latence, les engagements contractuels et le coût.
Avant de lancer un projet, vérifiez notamment :
- Disponibilité effective : les poids sont-ils publiés, et les formats nécessaires sont-ils accessibles ?
- Licence : autorise-t-elle l'usage commercial et la redistribution ou l'adaptation envisagées ?
- Coût d'exploitation : de quelles ressources matérielles et compétences avez-vous besoin ?
- Gouvernance : qui suit les versions, les vulnérabilités, les incidents et les changements de comportement ?
- Plan de repli : que se passe-t-il si les performances baissent, si la licence change, ou si la disponibilité se dégrade ?
Un essai en environnement contrôlé est souvent le meilleur compromis. Il permet de tester la valeur sur vos tâches sans lancer d'emblée toute l'architecture ni envoyer vos données sensibles à un service externe. Ensuite, la production devrait dépendre de seuils clairs : qualité minimale, coût maximal, latence acceptable, et procédure de supervision.
Conclusion : un signal à suivre, pas une décision d'achat
Inkling 2 Small représente un progrès pour Thinking Machines Lab : l'évaluation rapportée indique des gains en automatisation et en programmation, et une baisse des hallucinations sur un test donné. Si les poids annoncés sont bien publiés dans des conditions réellement exploitables, le modèle pourrait renforcer l'offre à poids ouverts hors de Chine.
Mais les réserves sont aussi concrètes : le modèle est décrit comme lent, son tarif dépasse la médiane de sa catégorie, et les scores ne prédisent pas automatiquement la qualité d'un système en production. Pour une entreprise, la décision doit reposer sur des tests représentatifs, le coût par tâche validée, la licence, la sécurité et vos besoins réels de contrôle.
Le plus pragmatique reste simple : surveiller la publication des poids, puis lancer un pilote limité avant tout engagement important. Un modèle ne crée de valeur que s'il améliore un processus mesurable, sans transférer la facture vers la supervision, l'infrastructure ou la gestion des risques.