OpenAI Codex vs Claude Code vs Kimi Code : la battle

Difficile de choisir le meilleur agent de codage. Les benchmarks sont trop éloignés des usages réels, et les publications des fournisseurs sont biaisées. Pour y voir plus clair, j’ai fait développer le même projet par 3 agents différents, et j’ai comparé le résultat.

Le problème : comment comparer les agents ?

OpenAI, Anthropic et les autres publient régulièrement des benchmarks dans lesquels leurs agents sont meilleurs que ceux de leurs concurrents. Souvent, ils sélectionnent les benchmarks qui les avantagent (qui sont souvent des benchmarks sur lesquels ils ont été spécifiquement entraînés). Si l’on en croit ces publications, tous les agents sont meilleurs, ça n’a pas de sens.

Comment démêler les arguments publicitaires des gains réels ? Et comment dépasser l’horizon des benchmarks, dont on sait qu’ils sont biaisés, et qu’ils évaluent des capacités parfois très éloignées de ce dont on a besoin dans notre métier ?

Pas le choix : il faut faire son propre benchmark.

Le vrai benchmark : recoder un projet from scratch

Pour répondre à cette question, j’ai décidé de faire développer la même application web par 3 agents différents, et de comparer le résultat.

L’application en question est une single page app en React qui reproduit un jeu de table nommé “LINKX” (un mélange de Tetris, de Puissance 4, et de Blokus, édité par Blue Orange Games).

Comme j’ai déjà développé une version fonctionnelle de cette application par ailleurs, je dispose d’une solution de référence et d’une spécification détaillée, qui va me servir de point d’entrée pour chaque agent.

Chaque agent reçoit le même prompt :

I want you to develop the LINKX game as a React SPA. The entire specification is in plan.md. This is a large job, so feel free to split it in tasks and delegate to sub agents to avoid overwhelming your context. I’m not around, so don’t ask me for confirmation, and make the most sensible choice. You’re in auto mode.

Le fichier plan.md, qui fait un peu plus de 20 pages, contient le détail des règles, les fonctionnalités attendues, les contraintes ergonomiques, et des critères d’acceptation.

La tâche demandée est relativement aisée (l’application cible n’a pas de backend, le domaine métier est bien défini, il n’y a pas de contraintes de sécurité ni de performance), mais le résultat demande déjà pas mal de temps pour être interprété, donc j’ai volontairement limité le périmètre.

J’ai choisi un modèle de puissance équivalent pour chaque fournisseur :

• OpenAI Codex GPT-5-6 Sol, effort élevé
• Anthropic Claude Code 1.0 Opus 4.8, effort extra
• Kimi Code K3, effort max

Je n’ai pas apporté de correction au premier jet de chaque agent, à part un reformattage du code pour rendre comparable des métriques de volumétrie et de documentation. J’ai commité chaque version dans un dépôt séparé, qui est testable en ligne.

• Codex : source, démo
• Claude Code : source, démo
• Kimi Code : source, démo

Disclaimer : En tant que lead développeur d’un projet open-source populaire, je dispose d’un abonnement Claude Code Max gratuit et d’un abonnement OpenAI Codex gratuit. Je n’ai pas d’abonnement Kimi Code, et j’ai payé l’usage de l’API pour cette expérience.

Synthèse des résultats

J’ai testé et audité le travail de chaque agent, à la main (pas de revue par un agent). Et voici le tableau de comparaison :

En résumé :

• Codex est cheap dans tous les sens du terme : rapide et pas cher, mais il fait la moitié du travail, et le code qu’il produit est difficile à relire et à corriger.
• Claude Code et Kimi K3 se tiennent dans un mouchoir de poche. Chacun a un inconvénient majeur : le prix pour Claude Code, le temps de développement pour Kimi K3. Mais la qualité du code est bonne dans les deux cas.
• Aucun des modèles n’est capable de produire une application prête à être mise en production. Il faut toujours un humain pour relire, corriger et compléter le code généré par les agents, notamment sur l’UI où ils ont tous du mal.

Voici, plus en détail, les caractéristiques de chaque version.

Codex

J’ai lancé Codex depuis son application desktop. L’agent lui-même est stable (aucun bug pendant la session), mais il donne peu de visibilité sur ce qu’il fait au fil de l’eau. Il a consommé 191k tokens sur les 250k de sa fenêtre de contexte, et bouclé le développement très vite : c’est de loin le plus rapide et le moins cher des trois candidats.

Cette rapidité se paie en profondeur. Codex ne vérifie jamais son travail, ni par des tests unitaires, ni en ouvrant l’application dans un navigateur. Il ne commente pas non plus son code, et laisse derrière lui quelques fichiers très volumineux. Le résultat est fonctionnel mais parsemé de bugs graphiques.

Le code est disponible sur marmelab/linkx-codex. Après reformatage, cloc montre un code concentré pour l’essentiel dans le TypeScript et le CSS :

Language      files  blank  comment  code
TypeScript        5    109        2  2554
JSON              7      4        0  1498
CSS               3     59        5  1408
Markdown          2    224        0   424
JavaScript        1     19        3   118
SVG               6      0        0    71
HTML              1      2        0    56
SUM:             25    417       10  6129

Tests. Codex n’a produit aucun test, ni unitaire, ni navigateur. Il a en revanche lancé de lui-même un agent de revue en fin de session, qui a remonté 2 problèmes majeurs et 2 moyens, tous corrigés. Mais même après cette passe, le code reste de piètre qualité.

Structure du code. Tout tient dans trois gros fichiers (un pour la logique de jeu, 952 loc, et deux pour l’UI dont un de 1463 loc), complétés par trois feuilles de style séparées. Aucun découpage réel du domaine. Ce n’est pas tout-à-fait du code spaghetti, mais on est loin des standards de qualité attendus.

Qualité du code. Quelques bons réflexes : un typage fort avec des data objects en lecture seule, des fonctions qui renvoient une réponse structurée, et des valeurs CSS regroupées dans des constantes. Mais les défauts l’emportent : des noms de fonctions trop génériques (jusqu’à un “trsnform”), un Math.random appelé au coeur de la logique qui interdit de seeder les parties ou de rejouer un run à l’identique, des fonctions volumineuses, un code touffu truffé de valeurs magiques, de la logique métier mélangée au code des composants, un découpage React approximatif (gros composants regroupés dans un même fichier), et une profusion de useState là où un useReducer s’imposait.

UI/UX. L’application est à peine jouable à cause des bugs graphiques. L’aspect général et les animations sont corrects, l’écran de démarrage affiche une image de fond (qui présente hélas une grille de jeu impossible), et la navigation au clavier fonctionne. Mais l’écran de démarrage clignote en partie à deux joueurs, la réserve montre des pièces de tailles différentes et décalées les unes par rapport aux autres, l’écran de fin de partie ne signale pas clairement les ex-aequo, et l’interface est tout bonnement injouable sur mobile (pièces et polices trop petites). Le projet ne fournit même pas de README (il conserve celui, par défaut, généré par Vite) ni de fichier Agents.md.

Fonctionnalités. Tout est présent, y compris l’IA.

Claude Code

J’ai utilisé Claude Code depuis son CLI, une expérience sans accroc. L’agent principal a consommé 356k tokens sur son million disponible, pour un total de 851k tokens sur l’ensemble des sous-agents (523k en entrée, 257,3k en sortie, plus 62,6M de lecture de cache et 445k d’écriture de cache). C’est le plus cher des trois, mais aussi le plus rigoureux.

Claude Code teste son travail au fur et à mesure avec son navigateur interne Preview, écrit des tests unitaires, et documente abondamment son code, peut-être même un peu trop. Il laisse derrière lui de nombreux fichiers, tous bien documentés, et une UI globalement satisfaisante.

Le code est ici: marmelab/linkx-claude. Le projet est plus volumineux, mais ce n’est pas une mauvaise chose car c’est dû aux tests et aux commentaires (dont aucun n’a d’impact en production) :

Language      files  blank  comment  code
TypeScript       45    769      754  6557
CSS              12    176      245  1033
Markdown          2    240        0   517
JSON              6      4        0   104
HTML              1      0        0    27
JavaScript        1      2        1    19
SVG               1      0        1    18
SUM:             68   1191     1001  8293

Tests. Claude Code teste la logique et les composants, avec 79% de couverture, des tests clairs, bien structurés et bien nommés. Côté navigateur, il est allé jusqu’à créer des pages dédiées aux tests visuels (comme la liste des pièces), et il a détecté puis corrigé plusieurs bugs graphiques par lui-même. En revanche, il n’a pas lancé de revue de code interne, là où les deux autres l’ont fait.

Structure du code. Le code est bien structuré : le domaine est découpé en fichiers faiblement couplés, chacun testable unitairement, chaque composant React dispose de son propre CSS, et on ne trouve ni grosse fonction ni gros composant.

Qualité du code. Typage fort, y compris sur les props des composants React, un useReducer pour la logique de jeu, des hooks custom pour empaqueter la logique, des variables CSS regroupées dans un theme.css, et un README clair. Les seuls reproches : un peu trop de commentaires, et l’absence de fichier AGENTS.md / CLAUDE.md.

UI/UX. Les pièces sont joliment dessinées, la prévisualisation de la pièce et le hint sont présents, la navigation au clavier fonctionne et le favicon est personnalisé. Mais la réserve et les pièces sont trop petites, il y a des chevauchements entre pièces et texte, il manque une navigation globale pour revenir au menu principal, la fenêtre des règles est trop grande pour l’écran et non scrollable, l’illustration de la page d’accueil n’est pas correcte, et sur mobile le board est partiellement caché, ce qui rend le jeu injouable.

Fonctionnalités. Tout est là.

Kimi K3

Kimi Code passe aussi par un CLI, mais l’outil est encore en développement : j’ai rencontré quelques bugs, et l’UI de l’agent donne peu de visibilité sur l’avancement de la tâche en cours. La session principale affiche, en fin d’implémentation, 196k tokens sur 1M, mais ce chiffre est douteux (il ne bouge que très lentement malgré des phases de réflexion très longues). Surtout, il est de très loin le plus lent des trois.

Malgré cette lenteur, le travail est sérieux. Kimi teste dans Chrome, écrit des tests unitaires, documente raisonnablement son code, et a même mené sa propre revue de code avant de corriger les problèmes trouvés. L’UI est correcte. Il est moitié moins cher que Claude Code, pour un résultat quasi équivalent.

Retrouvez le code sur GitHub : marmelab/linkx-kimi. Après reformatage, on comprend qu’il a utilisé une partie de son temps supplémentaire pour écrire plus de code :

Language      files  blank  comment  code
TypeScript       42    477      436  5709
JSON              4      0        0  2920
CSS               1    126       45   659
Markdown          2    224        0   432
JavaScript        4     30       23   300
HTML              1      0        0    33
SUM:             54    857      504 10053

Tests. Kimi teste la logique et les composants avec une couverture de 89%, des tests clairs et bien nommés, et il a même généré un fichier de smoke tests qui simule une partie complète. Deux bémols côté tests unitaires : les composants React ne sont pas testés directement, et les fichiers de test sont nommés indépendamment des fichiers du modèle. Côté navigateur, il a lancé Chrome en mode headless, pris des captures d’écran, puis détecté et corrigé des bugs graphiques. C’est aussi lui qui pousse le plus loin la revue interne : un sous-agent dédié, lancé en fin de session, a remonté 2 problèmes majeurs et 4 mineurs, retesté toutes les cartes, et délégué les corrections à l’orchestrateur.

Structure du code. Bonne séparation entre domaine, IA et UI, des fonctions globalement raisonnables (sauf dans le code React), et une extraction spontanée de tous les textes de l’interface, ce qui facilite une future traduction au prix d’un peu plus de complexité. Points faibles : un unique gros style.css non découpé par composant, et une désynchronisation entre le nommage du code et celui des tests.

Qualité du code. Un bon niveau de commentaires, rédigés en anglais comme le code, des types centralisés avec des discriminated unions, une fonction play indépendante de React et un code immutable, des helpers extraits dans un fichier .ts agnostique de React, la notion de gameController, et un fichier AGENTS.md. En face : du prop drilling (pas de React context), certains textes en dur (comme les règles), un gameController pas assez découpé, beaucoup de setState, et l’absence de README.

UI/UX. La navigation au clavier fonctionne et le favicon est personnalisé. Mais l’illustration de l’écran d’accueil est cachée par les contrôles, le contenu manque d’aération alors que les marges extérieures sont gigantesques, la fin de partie n’est pas évidente lorsqu’elle se joue à la plus grande zone, et sur mobile la réserve est minuscule et la navigation mal agencée, ce qui rend le jeu inutilisable.

Fonctionnalités. Tout est présent.

Conclusion

J’utilise Claude Code au quotidien, donc je m’attendais au bon résultat de cet agent. J’ai été déçu par Codex, qui à mon sens n’est tout simplement pas au niveau. Et j’ai été agréablement surpris par Kimi K3, qui sort un très bon résultat. En rapport qualité/prix, si le temps n’est pas un problème, il remporte la palme.

Mais l’argument du prix est ambivalent : avec Claude Code, les développeurs ont en général un abonnement et ne paient qu’une fraction du coût de l’API, alors que Kimi Code a suspendu ses abonnements pour cause de trop grande demande, et on est forcé de passer par l’API. Donc, dans les faits, le coût de Claude Code est (pour l’instant) inférieur à celui de Kimi Code, et on n’a donc aucun intérêt à se précipiter sur Kimi Code.

Un point important, c’est l’expérience développeur : les interfaces graphiques des outils testés (qu’ils soient en CLI ou en desktop) ne se valent pas, et Claude Code est clairement au-dessus de la mêlée. On sent qu’ils sont sur le sujet depuis plus longtemps que les autres. Et à l’opposé, Kimi Code donne l’impression d’un produit pas tout à fait fini (il n’est, en tout cas, pas très agréable à utiliser). Codex court après Claude Code mais n’y est pas encore.

Dernier point : un petit outil m’a particulièrement aidé pour cette comparaison. Il s’agit d’AgentsView, un outil open source qui fournit des stats sur les sessions de codage de tous les agents installés sur la machine. Si vous n’avez pas de télémétrie centralisée au niveau de votre entreprise, c’est un très bon outil pour comprendre où vont vos tokens.