Kimi K3 bat Claude sur le frontend et le terminal, Claude reprend l'avantage sur la maintenance logicielle et sur la vitesse : les deux affirmations sont vraies, parce que les benchmarks ne mesurent pas le même métier. Mais la question qui décide vraiment n'est ni l'une ni l'autre. Kimi K3 se facture au token — 3 $ le million en entrée, 15 $ en sortie — pendant que Claude Code arrive inclus dans un abonnement forfaitaire à 18 € ou 100 € par mois, et à usage intensif, le compteur perd contre le forfait. Quant au mot « open source », il ne signifie pas que tu peux l'héberger : il faut environ 1,4 To de mémoire vidéo pour faire tourner le modèle.
Kimi K3 est-il meilleur que Claude pour coder ?
Ça dépend du travail. Sur les benchmarks publiés, K3 gagne trois manches et en perd deux — et les manches perdues sont celles qui ressemblent le plus à une vraie journée de dev.
| Test | Kimi K3 | Claude Fable 5 | Ce que ça mesure |
|---|---|---|---|
| Frontend Code Arena | 1 679 pts (1ᵉʳ) | 2ᵉ | Générer une interface |
| Terminal Bench 2.1 | 88,3 % | 84,6 % | Enchaîner des commandes shell |
| SWE Marathon | 42,0 % | 35,0 % | Tâches longues sur dépôt |
| FrontierSWE | 81,2 % | 86,6 % | Corriger du code existant |
| Vitesse de sortie | 62 tokens/s | plus rapide | Temps d'attente réel |
FrontierSWE est le test le plus proche de ce qu'on fait toute la journée dans un studio : reprendre un dépôt qu'on n'a pas écrit, comprendre pourquoi ça casse, réparer sans rien détruire d'autre. C'est précisément là que K3 décroche.
Une réserve honnête, que peu d'articles français assument : au 22 juillet, les poids de K3 ne sont pas encore publiés, la sortie étant annoncée pour le 27. La plupart de ces scores viennent donc encore de Moonshot, pas de mesures tierces indépendantes. À prendre comme tel.
Combien ça coûte vraiment, Kimi K3 face à Claude ?
C'est ici que la quasi-totalité des comparatifs se trompe, et l'erreur coûte cher. Ils alignent deux grilles d'API — 3/15 $ pour K3 contre 5/25 $ pour Opus 4.8 — et concluent « 40 % moins cher », parfois « trois fois moins cher ». Sauf que personne ne code avec Claude via l'API brute : on code avec Claude Code, et Claude Code est inclus dans l'abonnement.
La vraie comparaison n'oppose donc pas deux prix au token. Elle oppose un forfait à un compteur.
| Kimi K3 | Claude | |
|---|---|---|
| Modèle économique | Facturation au token | Abonnement forfaitaire |
| Entrée / sortie (API) | 3 $ / 15 $ le million | 5 $ / 25 $ le million |
| Accès agent | À brancher soi-même | Claude Code inclus |
| Coût mensuel typique | Variable, sans plafond | 18 € (Pro) ou 100 € (Max) |
| Journée intensive | Le compteur tourne | Rien ne bouge |
Une session de développement agentique consomme énormément, parce que l'agent relit le dépôt, planifie, édite, relance les tests et recommence : quarante tours sur une seule tâche, ce n'est pas rare. Au forfait, ça ne change rien à la facture. Au token, chaque tour se paie.
« Open source », est-ce qu'on peut vraiment l'héberger ?
Non. Pas dans une PME française, pas dans une ETI, pas sur le serveur du sous-sol.
Kimi K3 pèse 2 800 milliards de paramètres — deux mille huit cents, pas 2,8 comme on peut le lire ici ou là. Même compressé au format MXFP4, le modèle réclame environ 1,4 To de mémoire vidéo, et Moonshot recommande 64 accélérateurs ou plus pour un déploiement sérieux, alors qu'une RTX 4090, la carte de référence du dev bien équipé, en offre 24 Go. Il en faudrait une soixantaine. Et encore, avec la bonne interconnexion.
L'argument de la souveraineté est réel sur le papier et s'effondre sur la facture du datacenter. Concrètement, tu utiliseras K3 comme tu utilises Claude : via une API, hébergée par quelqu'un d'autre. La différence de licence te donne le droit théorique de faire autrement. Elle ne te donne pas les machines.
Modèle ou harness : que compares-tu exactement ?
Voilà l'erreur de catégorie qui traverse tout le débat. Kimi K3 est un modèle, quand Claude Code est un harness — l'agent qui lit ton dépôt, décide quoi ouvrir, édite plusieurs fichiers, lance les tests et lit les erreurs pour recommencer. Ce n'est pas le même objet.
Sur un vrai chantier, ce n'est pas le modèle qui écrit ton application : c'est la boucle. Et la boucle décide de la majeure partie de la productivité :
- Ce que le modèle apporte : la qualité d'un bloc de code isolé, la justesse d'un raisonnement, la compréhension d'une consigne floue.
- Ce que le harness apporte : la gestion du contexte sur un dépôt de 400 fichiers, la reprise après une erreur de compilation, les commits propres, l'exécution des tests, les permissions.
Un modèle légèrement meilleur dans une boucle médiocre livre moins vite qu'un modèle correct dans une boucle excellente. Nous le constatons projet après projet, et c'est aussi la raison pour laquelle un comparatif de scores ne dit presque rien du temps réel passé à livrer. Nous détaillons ce fonctionnement dans notre guide complet Claude Code et dans le comparatif Claude Code vs Cursor.
Rien n'interdit techniquement de brancher K3 dans une boucle agentique, puisque l'API est compatible avec les formats du marché. Mais tu récupères le modèle, pas les années d'ingénierie de l'agent.
Alors, faut-il changer maintenant ?
Non, et pour une raison simple : dans cinq jours les poids sortent, et les premiers tests indépendants tomberont dans la foulée. Décider aujourd'hui sur des chiffres de communiqué, c'est signer avant l'audit.
Voici comment nous arbitrons, chez Neova, pour un projet client :
- Tu paies déjà un abonnement Claude et tu codes tous les jours → tu ne gagnes rien à migrer, tu perds ton outillage et tu ouvres un compteur.
- Tu génères beaucoup d'interfaces frontend en volume, à l'API → K3 mérite un test comparatif sur ton propre corpus.
- Ton sujet est la souveraineté des données → l'auto-hébergement est hors de portée, la question se règle par contrat et par localisation, pas par licence.
- Tu n'as pas encore d'abonnement et tu explores → teste les deux une semaine, sur la même tâche, et chronomètre.
Ce dernier point mérite qu'on s'y arrête, parce que c'est le seul qui tranche vraiment : prends une fonctionnalité réelle de ton produit, fais-la traiter par les deux, et mesure trois choses — le temps total au mur, le nombre d'allers-retours pour arriver à un résultat qui passe les tests, et ce qui a cassé ailleurs. Le benchmark ne te dira jamais ça.
Tu veux qu'on fasse ce test sur ton projet plutôt que sur un benchmark ? Parle-nous de ton application — nous livrons des logiciels métier et des SaaS avec ces outils toutes les semaines, et nous te dirons franchement ce qui change quelque chose pour toi et ce qui n'est que du bruit.
Photo : Lisa from Pexels — Pexels
