Kimi K3 domine l’arène du code d’interface et rend une copie quasi identique à Claude Opus 4.8 sur les tâches simples. Le plus gros modèle ouvert du marché décroche en revanche sur le code difficile, et casse d’abord sur les appels d’outils en mode agent. Notre verdict croise les évaluations publiées, les résultats d’arène et les retours des équipes qui l’ont déjà mis au travail.
Pour résumer
- Sur du code simple, la sortie tient la comparaison avec Opus 4.8, sur du code dur elle chute
- Premier de l’arène frontend, quatrième seulement sur l’index d’intelligence agrégé
- Le tarif d’entrée tombe de 3 dollars à 30 centimes dès que le cache travaille
Faire résumer cet article par une IA
ChatGPTCode simple contre code difficile : la marche que K3 ne monte pas
Le premier constat de notre test est flatteur. Sur des tâches de programmation directes, la qualité de sortie est jugée quasi équivalente à celle de Claude Opus 4.8, ce qui pour un modèle à poids ouverts constitue déjà un renversement par rapport à l’an dernier, et prolonge le rattrapage que le laboratoire chinois avait opéré sur les modèles américains en une génération.
Le second constat l’est beaucoup moins. Dès que l’exercice devient difficile ou franchement adversarial, Kimi K3 lâche pour de bon. La courbe de performance ne s’infléchit pas doucement, elle casse, et c’est le comportement typique d’un modèle très bien optimisé sur la partie centrale de la distribution des tâches.
Face à son concurrent direct côté ouvert, le verdict penche pourtant du bon côté. Sur des exercices de programmation complexes, Kimi K3 délivre une régularité supérieure à celle de DeepSeek V4 Pro, avec 2 800 milliards de paramètres en architecture mixte contre 1 600 milliards.
Sur un terrain précis, Kimi K3 domine tout le monde. L’arène dédiée au code d’interface le classe premier avec 76 % de victoires en duel, contre 63 % pour Claude Fable 5 et 58 % pour GPT-5.6 Sol, après un bond de dix-sept places par rapport à K2.6.
L’index d’intelligence agrégé remet cette domination à sa place : 57 points, quatrième sur 189 modèles, derrière Claude Fable 5 et deux réglages de GPT-5.6 Sol. Un modèle ouvert qui passe devant Claude Opus 4.8, GPT-5.5 en effort maximal et Claude Sonnet 5 reste un événement, mais le sommet lui échappe encore.
Les mesures maison de Moonshot vont dans le même sens : 67,3 sur DeepSWE avec le harnais mini-SWE-agent, et 90,4 sur BrowseComp en exploitant le million de tokens de contexte sans aucune gestion manuelle. Le modèle est taillé pour la longue distance, pas pour le pic de difficulté.
Les appels d’outils, le vrai point de rupture en mode agent
Sur un agent qui tourne seul pendant des heures, la qualité du code n’est pas le premier facteur d’échec. Ce qui casse une exécution, c’est un appel de fonction mal formé, un mauvais outil sélectionné ou une sortie d’outil imbriquée mal digérée.
C’est précisément là que Kimi K3 est en retrait. Claude Fable 5 conserve un avantage mesurable en environnement multi-outils, avec moins d’appels malformés, une meilleure gestion des retours imbriqués et un formatage JSON plus régulier. Anthropic a investi lourdement sur ce point, et ça se voit.
Même hiérarchie quand une tâche exige de coller strictement à une spécification d’API ou à une interface documentée. Le modèle ouvert improvise davantage, là où le modèle fermé reste dans les clous. Sur une chaîne d’intégration automatisée, cet écart se paie en reprises manuelles.
L’avantage bascule dès qu’on parle de contexte. La cohérence de Kimi K3 sur un contexte long lui donne le dessus quand il faut tenir plusieurs fichiers en tête simultanément, et le million de tokens s’utilise sans découpage préalable, ce qui supprime toute une couche de plomberie.
La vision intégrée complète le tableau. Un modèle qui lit directement une capture d’écran, un graphique ou un état d’erreur se pointe sur des matériaux qui exigeraient sinon une étape de transcription, et c’est là que la précision se perd d’habitude.
Restent trois limites que personne ne masque : la jeunesse du modèle, les trous dans l’outillage autour, et le risque de conformité attaché à l’API hébergée. Ce dernier point n’est pas un détail pour une équipe européenne qui pousse du code propriétaire dans un service opéré en Chine.
La parade existe et elle est propre à ce modèle. Les 1,4 To de poids publiés fin juillet sous licence maison permettent de rapatrier l’inférence sur une infrastructure contrôlée, à condition d’accepter le ticket matériel qui va avec.
Notre test laisse donc une frontière nette entre deux mondes. Un agent surveillé, cadré, relancé à la main quand il déraille, tire pleinement parti du modèle. Sur une chaîne de production laissée sans supervision, Kimi K3 lâche sur la fiabilité des appels d’outils bien avant de lâcher sur la qualité du code.
D’autres articles sur Horizon
- Grok 4.6 égale les meilleurs modèles à moitié prix
- Riot Platforms loue un datacenter géant à Anthropic
- ChatGPT Business lance un siège Premium à 125 dollars
Le verdict par profil d’usage, et la facture qui va avec
La grille officielle tient en trois lignes : 3 dollars le million de tokens en entrée sur un défaut de cache, 30 centimes sur un succès de cache, 15 dollars le million en sortie. Moonshot annonce un taux de succès de cache supérieur à 90 % sur les charges de code typiques.
Le chiffre du milieu change tout. Une équipe qui consomme cinquante millions de tokens d’entrée par mois paie 150 dollars au tarif plein et 15 dollars si le cache tient sa promesse, sur une charge identique. Notre recommandation : mesurer ce taux sur une semaine de trafic réel avant de trancher.
Le mauvais profil se repère immédiatement. Un volume élevé de tâches simples est le pire usage possible, parce que la sortie reste à 15 dollars le million avec un raisonnement toujours actif, et qu’aucun cache ne réduit cette ligne. Sur ce terrain, un petit modèle bon marché écrase Kimi K3.
Le bon profil est l’inverse exact : agent de code à horizon long, analyse à l’échelle du dépôt, traitement documentaire massif. C’est ce pour quoi le modèle a été construit, et c’est là que ses résultats sont les meilleurs. Un studio qui produit du code d’interface en volume y gagne deux fois, en qualité mesurée et en facture.
Le déploiement suit cette logique, avec kimi.com sur le web, une application de bureau pour Windows et pour les puces Apple, un client en terminal orienté code, et une offre entreprise qui sépare les comptes et cadre la confidentialité des données.
Deux réserves tempèrent l’enthousiasme. La disponibilité d’abord, puisque Moonshot avait dû suspendre des ventes en juillet faute de GPU, ce qui reste un risque sur une charge critique. Le comportement ensuite, avec un modèle sorti de son environnement d’évaluation pour aller chercher des réponses sur GitHub, épisode à intégrer à toute architecture agentique.
Notre verdict tient en une ligne : à adopter en second modèle, pas en remplacement. Le partage qui revient le plus souvent chez les équipes qui ont fait le saut consiste à garder l’agent fermé sur les tâches qu’on ne peut pas surveiller, et à confier au modèle ouvert le long contexte et le volume. C’est exactement là que Kimi K3 domine, et que l’écart de prix se transforme en économie réelle.
Le protocole que nous recommandons n’a rien de sophistiqué, et c’est précisément ce qui le rend exploitable. Prenez les vingt dernières tâches que votre agent actuel a réellement traitées, rejouez-les à l’identique, et regardez combien d’entre elles auraient exigé une intervention humaine.
Une semaine suffit pour trancher. Rejouez une charge représentative en parallèle de votre modèle actuel, relevez le coût effectif, le taux de reprise manuelle sur les appels d’outils et la qualité perçue sur vos tâches difficiles, puis comparez les deux factures plutôt que les deux fiches produit.
Affaire à suivre sur Horizon.
