DeepSeek V4 vs Claude Opus 4.5 pour le Codage : Comparaison des Benchmarks

Salut ! Dora ici. Dimanche dernier matin, je passais mon temps entre mon éditeur et une fenêtre de chat pour corriger un test instable, et le modèle n’arrêtait pas d’inventer une importation qui n’existait pas. Pas grave, juste l’un de ces petits problèmes qui ralentit vos mains. Je voulais voir si changer de modèle allègerait la charge, non seulement sur le temps, mais aussi sur l’effort mental nécessaire pour faire confiance à ce qui atterrit dans mon dépôt.

J’ai donc passé la dernière semaine (27 janvier - 1er février 2026) à exécuter une boucle simple et répétable : mêmes tâches, mêmes instantanés du dépôt, en alternant DeepSeek V4 et Claude Opus 4.5. Ce n’est pas une étude de laboratoire. C’est le type de vérification que je ferais avant de câbler un modèle dans CI. Si vous pesez aussi DeepSeek V4 contre Claude Opus 4.5 pour le codage, ce sont les notes que je voudrais lire avant de faire le changement.

Chefs de file des benchmarks actuels

Classements SWE-bench Verified

Quand j’ai besoin d’une évaluation rapide de la direction prise, je commence par les classements publics. Sur le classement SWE-bench Verified, les modèles récents de DeepSeek et la famille Claude plus récente d’Anthropic se situent près du sommet, avec de petits écarts qui changent de semaine en semaine à mesure que les invites, les outils et les harnais d’évaluation se modifient. Ce qui compte pour moi, ce n’est pas le nombre unique, c’est le schéma : quels modèles résolvent les problèmes de bout en bout sans béquilles d’outils, et à quel point sont-ils sensibles aux ajustements d’invite.

Ma lecture rapide, au début février 2026 :

DeepSeek V4 montre un mouvement fort sur les tâches multi-fichiers à l’échelle du dépôt quand vous lui donnez tout le contexte qu’il demande. Il bénéficie des invites longues et des cartes de fichiers explicites.
Claude Opus 4.5 produit des résultats réguliers et tend à régresser moins quand je réduis le contexte ou supprime les messages système. Ce n’est pas spectaculaire, mais le plancher semble élevé.

Scores HumanEval

HumanEval est plus étroit, des problèmes de codage courts avec des tests unitaires, mais c’est un test utile pour la génération de code prête à l’emploi. Les résumés actuels sur le dépôt OpenAI HumanEval et les traceurs communautaires comme le classement EvalPlus placent les deux modèles dans la première catégorie. Je ne m’accroche pas à la réussite exacte pass@1 ici : je surveille la stabilité dans les graines et la fréquence à laquelle un modèle s’appuie sur des astuces linguistiques au lieu d’écrire du code direct et idiomatique. Dans mes exécutions, DeepSeek V4 a parfois produit des solutions plus longues et plus “explicatives”, bien, mais pas toujours ce que je veux dans un diff serré. Claude Opus 4.5 retournait plus souvent des fonctions compactes qui réussissaient les tests sans commentaire supplémentaire. Les benchmarks font allusion à cette différence : le travail pratique l’a rendue évidente.

Où chaque modèle excelle

Contexte long (DeepSeek)

Si vous voulez reproduire cette configuration de bout en bout, j’ai rassemblé un court guide de démarrage rapide DeepSeek V4 qui explique le chat et les bases API sur lesquelles je m’appuie ici.

J’ai donné aux deux modèles une véritable tâche : refactoriser un petit service FastAPI qui s’était discrètement transformé en un enchevêtrement. Environ 14 fichiers comptaient, plus un README qui était… optimiste. J’ai compressé l’instantané du dépôt et j’ai alimenté les résumés de fichiers ainsi qu’un graphique d’appel que j’avais généré avec un court script. DeepSeek V4 s’est senti calme face à la complexité. Il a gardé la trace des effets multi-fichiers et ne s’est pas affolé quand je lui ai demandé un plan par étapes : d’abord les interfaces, ensuite les tests, enfin les gestionnaires. La partie surprenante était la façon dont il a bien utilisé les indices structurels ; quand je lui ai remis une simple “carte” des noms de fichiers et des responsabilités, il a cessé de suggérer des modifications aux fichiers qui n’existaient pas.

Deux notes pratiques :

Il avait besoin d’espace. Quand j’ai trop agressivement réduit le contexte, il est devenu prudent et a commencé à demander à voir des fichiers que j’avais déjà fournis. Une fois que je lui ai donné l’image complète, il s’est déplacé proprement.
Il s’est bien comporté avec les invites “Qu’est-ce qu’il me manque ?”. Je lui demanderais les cas limites basés sur la suite de tests et il en surfacerait trois que j’avais oubliés : les en-têtes d’authentification vides, un paramètre de pagination cassé et un chemin lent dans la journalisation des erreurs.

Cela n’a pas gagné du temps au départ. La configuration initiale, l’empaquetage du contexte, l’écriture d’une courte carte de fichiers, ont pris environ 20 minutes. Mais après quelques exécutions, la charge mentale a diminué. Je ne jonglais pas avec autant de soucis “est-ce que je lui ai dit X ?”. Si votre journée de codage ressemble à de grands diffs répartis dans plusieurs modules, DeepSeek V4 a une main ferme quand le contexte s’élargit.

Fiabilité du code (Claude)

Claude Opus 4.5 m’a conquis d’une autre manière : moins de problèmes aigus. Quand j’ai demandé un correctif minimal, il m’en a donné un. Quand j’ai demandé un plan en trois étapes avec une exécution à sec, il n’a pas halluciner de commandes. Et il a résisté à l’envie “d’améliorer” les choses que je n’avais pas demandées.

Un petit exemple : j’avais un test instable autour des mathématiques de fuseau horaire. Mon invité était directe : “Corriger le test sans changer le code de production, et expliquer la cause première en une phrase.” Claude a suggéré de paramétriser le fixture tz et d’ajuster une seule assertion pour utiliser un datetime conscient. Cela a réussi du premier coup. DeepSeek l’a également corrigé, mais il a essayé de refactoriser l’assistant en même temps. Ce n’est pas faux, juste plus lourd que ce que je voulait.

Sur cinq tâches, les diffs de Claude étaient constamment plus petits. Moins d’importations apparaissaient de nulle part. Et quand il a deviné, il a laissé une note nette : “En supposant que pytz soit disponible : sinon, remplacez par zoneinfo.” Ce type de suggestion couverte est facile à auditer.

Deux limites se sont présentées :

Claude a joué la sécurité sur les performances. Dans un cas, il a choisi la clarté plutôt qu’une simple amélioration O(n) que DeepSeek a soulignée immédiatement. J’ai dû le pousser : “Optimiser dans les mêmes contraintes.” Il l’a fait, mais il ne sauterait pas en premier.
Avec des invites très longues, j’ai atteint la limite plus vite. Les résumés ont aidé, mais DeepSeek s’est senti moins à l’étroit quand je voulais que le modèle “tienne toute l’application dans sa tête.”

Si votre journée consiste principalement en correctifs chirurgicaux, réparations de tests et code de glace autour des API, Claude Opus 4.5 garde les changements minces et prévisibles. C’est, en pratique, une fiabilité que je peux ressentir.

Comment exécuter votre propre comparaison

Si vous hésitez sur DeepSeek V4 contre Claude Opus 4.5 pour le codage, une courte expérience ennuyeuse vous dit plus que n’importe quel classement. Voici la boucle que j’ai utilisée, modifiez librement.

1. Choisissez des tâches qui correspondent à votre semaine

Une tâche du dépôt (refactor ou extraction de module)
Un test instable
Un changement d’intégration API
Un petit ajustement d’algorithme

Gardez chacun moins de 45 minutes. Délimitez l’interaction, pas seulement la génération du modèle.

2. Geler les entrées

Épingler un commit spécifique. Ne déplacez pas la cible pendant que vous testez.
Décidez ce que le modèle peut voir : fichiers complets vs. extraits. Écrivez une courte carte de fichiers si vous passez des extraits.
Utilisez le même style de message système pour les deux modèles. Je le garde simple : “Vous êtes un assistant de codage utile. Préférez les diffs minimales et le code exécutable.”

3. Écrivez des invites que vous pouvez réutiliser

Tâche : “Voici l’objectif, les contraintes et les tests.”
Contexte : liste de fichiers ou résumés, ainsi que les pièges connus.
Format de sortie : “Proposez un plan (puces), puis le diff, puis une note de risque d’une phrase.”

4. Capturez les mêmes signaux pour les deux

Tentatives de passage des tests (1–N)
Lignes modifiées dans diff (approximatif est bien)
Notes que vous avez dû écrire pour le modèle (“Arrêter d’éditer X”, “Utiliser l’assistant existant Y”)
Temps jusqu’au premier test vert

5. Gardez-vous contre les fuites

Désactivez les outils à moins que vous prévoyiez de comparer l’utilisation des outils. Si un modèle sort un shell et l’autre non, vous ne testez pas la même chose.
Si vous autorisez la récupération, pointez tous les deux vers le même instantané docs.

6. Vérifier l’assainissement avec des benchmarks, ne les adorez pas

Jeter un coup d’œil à SWE-bench Verified pour voir si vos résultats sont sauvages. Si c’est le cas, vérifiez vos invites avant de blâmer le modèle.
Pour les problèmes de petit format, parcourez les exemples HumanEval sur le dépôt officiel ou exécutez-en quelques-uns localement. La cohérence sur quelques graines est plus révélatrice qu’une seule exécution.

7. Optionnel : ajouter une petite rubrique

Notez 1–5 sur :

Minimalisme diff (a-t-il touché seulement ce dont il avait besoin ?)
Discipline des fixtures (tests, env, dépendances)
Comportement de récupération (se corrige-t-il quand vous soulevez un manque ?)
Qualité de l’explication (une ou deux phrases claires, pas un article de blog)

Ce que je surveille en pratique

Le modèle respecte-t-il les contraintes la première fois ?
Quand il se trompe, est-ce d’une manière facile à repérer ?
Suis-je en sécurité en le laissant proposer un correctif alors que je change de contexte ?

C’est fonctionné pour moi, votre kilométrage peut varier. Le but n’est pas de couronner un gagnant : c’est de voir lequel réduit votre friction cognitive avec votre code, selon votre horaire.