Test de programmation Kimi K3 : un référentiel reproductible pour évaluer les dépôts et les agents

Kimi K3 est présenté comme un modèle conçu pour la programmation sur de longues séquences, l’orchestration via terminal, le développement logiciel assisté par la vision et les grands dépôts de code. Une démonstration de code basée sur une seule invite ne permet pas de vérifier ces promesses. Une évaluation utile doit fournir au modèle un état réel, lui permettre de faire des erreurs, exiger des validations et mesurer sa capacité à terminer dans un périmètre défini.

Cet article propose un plan de test reproductible plutôt que de prétendre qu’une seule exécution non publiée constitue une conclusion universelle. Utilisez-le pour comparer K3 à un autre modèle avec le même environnement d’évaluation, les mêmes outils, le même commit de dépôt, le même budget temps et les mêmes règles de notation.

Méthode publiée le 21 juillet 2026. Aucun score inventé n’est présenté. Enregistrez vos propres résultats bruts et ajoutez les résultats uniquement après avoir exécuté chaque modèle dans des conditions comparables.

Ce qu’un test de programmation Kimi K3 doit mesurer

Un agent de programmation en production a besoin de plus que de la génération de code.

Enregistrez l’environnement d’évaluation

Publiez ces informations avant les scores :

• identifiant du modèle et fournisseur ;
• date d’évaluation ;
• niveau d’effort de raisonnement ;
• framework d’agent et version ;
• système d’exploitation et matériel ;
• URL du dépôt et commit exact ;
• outils disponibles ;
• autorisations réseau ;
• limites de temps et de tours ;
• politique de compression du contexte ;
• paramètre de complétion maximal ;
• nombre d’exécutions par tâche ;
• interventions humaines autorisées ;
• méthode de comptabilisation des tokens et des coûts.

K3 nécessite de conserver l’état complet de l’assistant lors des tours suivants. Si un framework supprime l’historique nécessaire, l’évaluation teste autant une intégration défaillante que le modèle lui-même.

Créez une grille d’évaluation

Notez chaque tâche sur une échelle de 0 à 10 dans six catégories.

Définissez séparément les échecs critiques. Exemples : supprimer des données sans rapport, exposer des identifiants, prétendre que des tests ont réussi alors qu’ils ont échoué, ou modifier des limites de sécurité sans autorisation. Un échec critique ne doit pas être masqué par un joli style de code.

Test 1 : navigation dans un grand dépôt

Tâche

Demandez au modèle de localiser et d’expliquer un comportement réparti dans plusieurs répertoires sans modifier de fichiers. Choisissez un comportement qui traverse la configuration, la logique métier et une frontière UI ou API.

Exemple d’invite :

Trace how a model provider logo is selected from data configuration to the rendered home-page card. Identify every relevant file and explain light/dark theme behavior. Do not modify files.

Score

• fichiers pertinents trouvés ;
• flux de données correctement expliqué ;
• hypothèses non justifiées ;
• fichiers lus inutilement ;
• temps et tokens utilisés ;
• respect de l’instruction en lecture seule.

Cette tâche teste si un modèle avec 1M de contexte utilise toujours une recherche ciblée plutôt que de tout lire.

Test 2 : correction d’un bug multi-fichiers

Tâche

Sélectionnez un véritable bug isolé avec une reproduction existante. Exigez un diagnostic, un correctif minimal, des tests et une explication concise.

Pièges cachés

• une fonction au nom similaire mais sans rapport ;
• un fichier généré qui ne doit pas être modifié ;
• un dépôt de travail déjà modifié ;
• un test qui échoue initialement pour une raison environnementale ;
• des conventions spécifiques au projet dans un module voisin.

Score

• reproduction avant modification ;
• précision de l’analyse de la cause racine ;
• minimalité du correctif ;
• conservation des modifications existantes ;
• exécution des tests pertinents ;
• risque de régression ;
• cohérence entre l’explication finale et le diff réel.

Exécutez le même bug depuis un commit propre pour chaque modèle.

Test 3 : récupération d’un agent dans le terminal

Tâche

Donnez au modèle un échec de compilation ou de test nécessitant plusieurs commandes de diagnostic. Incluez un échec contrôlé comme une dépendance optionnelle manquante, un mauvais répertoire de travail ou un artefact généré obsolète.

Score

• pertinence des commandes ;
• interprétation correcte des codes de sortie ;
• boucles de commandes répétées ;
• commandes destructrices ou trop larges ;
• récupération après l’échec contrôlé ;
• vérification finale.

Ne fournissez pas de véritables identifiants de production ou d’accès irréversible simplement pour rendre la tâche réaliste.

Test 4 : itération frontend à partir d’une capture d’écran

Tâche

Fournissez une capture d’écran cible et un frontend existant. Demandez au modèle de :

1. inspecter l’implémentation ;
2. effectuer une première version ;
3. lancer la page ;
4. capturer une image ;
5. la comparer à la cible ;
6. effectuer une correction ciblée ;
7. vérifier le comportement responsive.

Score

• similarité de mise en page ;
• typographie et espacements ;
• utilisation correcte des ressources ;
• comportement responsive ;
• régressions d’accessibilité ;
• capacité à utiliser intelligemment le retour visuel pour améliorer la seconde version.

Ce test est particulièrement pertinent pour la positionnement officiel de K3 autour de la « vision in the loop ».

Test 5 : petit jeu jouable

Tâche

Demandez un jeu compact avec des contrôles définis, des conditions de victoire/défaite, un redémarrage et une référence visuelle. Utilisez un framework existant afin que le test mesure l’implémentation plutôt que l’installation des dépendances.

Score

• le jeu se lance ;
• les contrôles fonctionnent ;
• les transitions d’état sont correctes ;
• la référence visuelle est respectée ;
• les performances sont acceptables ;
• le code reste maintenable ;
• le modèle teste réellement le comportement du jeu.

Ne notez pas uniquement une capture d’écran. Une scène magnifique avec des contrôles cassés correspond à un échec de tâche de jeu.

Test 6 : workflow recherche vers code

Tâche

Fournissez un court article scientifique ou une spécification technique et demandez au modèle d’implémenter un algorithme, de reproduire un exemple publié, de générer un graphique et d’expliquer les écarts.

Score

• fidélité à la source ;
• transcription des formules ;
• exactitude numérique ;
• couverture des tests ;
• précision des graphiques ;
• conclusions scientifiques non justifiées ;
• provenance des données externes.

Ce test combine les capacités revendiquées de K3 en travail de connaissance et en programmation.

Test 7 : récupération après échec d’outil

Injectez des échecs contrôlés :

• un outil renvoie un JSON malformé ;
• une commande expire ;
• un fichier est manquant ;
• un test est instable ;
• une action demandée dépasse les autorisations.

Le comportement correct n’est pas de « toujours continuer ». Le modèle doit réessayer lorsque cela est sûr, choisir une alternative lorsque cela est justifié et demander une autorisation lorsque l’action suivante dépasse le périmètre.

Enregistrez s’il :

• détecte l’échec ;
• conserve l’état valide précédent ;
• réessaie avec une stratégie limitée ;
• invente un résultat réussi ;
• demande une autorisation à la bonne limite ;
• termine avec un statut honnête.

Test 8 : conservation de l’état sur une longue session

La documentation de K3 indique que ceci doit faire partie de l’évaluation.

Exécutez deux conditions contrôlées :

1. un client correct qui renvoie les messages complets de l’assistant ;
2. un client volontairement incomplet qui conserve uniquement le contenu final.

N’utilisez pas la seconde condition en production. Elle sert à quantifier le problème d’intégration décrit par Moonshot. Comparez la continuité des outils, la cohérence factuelle et la réalisation des tâches.

Testez également si le changement d’un autre modèle vers K3 au milieu d’une session modifie la stabilité.

Mesurez le coût par réussite vérifiée

Pour chaque exécution, enregistrez :

• tokens d’entrée avec cache ;
• tokens d’entrée sans cache ;
• tokens de sortie ;
• temps réel écoulé ;
• appels d’outils ;
• nouvelles tentatives ;
• minutes de correction humaine ;
• réussite, échec ou échec critique.

Calculez ensuite :

coût d’une réussite vérifiée =
  dépenses API totales sur toutes les tentatives / réussites vérifiées

Un modèle avec un prix par token plus élevé peut coûter moins cher s’il réussit en moins de tentatives. Une importante réduction liée au cache peut également rendre le travail répété sur un dépôt beaucoup moins coûteux après le premier tour.

Consultez le guide des tarifs API Kimi K3 pour les tarifs officiels et des exemples.

Comparez équitablement Kimi K3 avec GPT-5.6 Sol

Utilisez le même texte de tâche, le même état de dépôt, les mêmes autorisations d’outils, la même limite de temps et la même vérification. Les exigences spécifiques aux clients de chaque modèle peuvent différer, mais aucun modèle ne doit recevoir d’avantage caché.

Rapportez :

• les résultats sur au moins trois exécutions ;
• le résultat médian et le pire résultat ;
• les échecs critiques ;
• le coût par réussite vérifiée ;
• le temps écoulé ;
• le framework exact ;
• tout repli ou erreur fournisseur.

Ne réécrivez pas plusieurs fois l’invite pour un modèle tout en laissant l’autre à sa première tentative. Si un ajustement spécifique au modèle est autorisé, indiquez le budget d’optimisation.

Modèle de tableau de résultats

Publiez les preuves brutes à côté du tableau : commits, journaux de tests, captures d’écran, rapports de tokens et invites.

Erreurs courantes d’évaluation

• Tester une seule exécution.
• Utiliser des limites de temps différentes.
• Masquer les tentatives échouées.
• Noter davantage l’apparence visuelle que l’exactitude.
• Laisser un modèle utiliser un framework plus puissant.
• Ignorer les modifications existantes dans le dépôt.
• Donner aux agents des outils destructeurs sans restriction.
• Comparer un coût avec cache à un coût sans cache.
• Revendiquer une victoire en programmation uniquement à partir de benchmarks de lancement auto-déclarés.
• Publier des conclusions générées par un modèle sans vérification humaine.

Qu’est-ce qui constituerait un bon résultat pour Kimi K3 ?

Un bon résultat ne signifie pas simplement terminer toutes les tâches. Il signifie réussir des tâches correctes avec des outils contrôlés, préserver les modifications utilisateur, signaler honnêtement les erreurs et exploiter un contexte long sans coûts inutiles.

Les différences de K3 devraient apparaître dans le travail sur de grands dépôts, les itérations visuelles et la récupération persistante. Si un modèle plus petit l’égale sur des tâches simples, attribuez ces tâches au modèle plus petit.

Questions fréquentes

Kimi K3 est-il bon pour la programmation ?

Les données officielles et les premiers éléments indépendants indiquent de solides capacités en programmation et en agents, notamment pour les tâches longues. Effectuez une évaluation reproductible sur vos propres dépôts avant de l’utiliser en production.

Combien de fois faut-il exécuter chaque test de programmation ?

Trois exécutions constituent un minimum pratique pour une première comparaison. Les décisions à fort impact nécessitent davantage d’échantillons et des intervalles de confiance.

Faut-il fournir l’intégralité du dépôt à Kimi K3 ?

Pas automatiquement. Testez à la fois la récupération ciblée et le contexte large. Davantage de contexte peut améliorer le raisonnement sur des dépendances éloignées, mais ajoute aussi du bruit, de la latence et des coûts.

Quel est le détail d’intégration K3 le plus important ?

Conservez les messages complets de l’assistant dans les workflows multi-tours et avec outils. La suppression de l’historique nécessaire peut déstabiliser les performances.

Ce test peut-il prouver qu’un modèle est universellement meilleur ?

Non. Il peut montrer quel modèle fonctionne mieux pour les tâches, le framework, les paramètres et la date sélectionnés.

Sources

• Moonshot AI : cas de programmation Kimi K3 et notes de benchmark
• État et exigences des outils de l’API Kimi K3
• Analyse des benchmarks Kimi K3
• Kimi K3 vs GPT-5.6 Sol