DeepSeek Flash vient de dépasser V4 Pro Preview dans les tests d’agents, mais le plus difficile commence maintenant

DeepSeek Flash est entré en bêta publique le 31 juillet avec une affirmation frappante : ses résultats d’agents mis à jour dépassent désormais ceux du plus grand V4 Pro Preview dans tous les tests rapportés.

L’entreprise a également ajouté une prise en charge native de la Responses API, l’interface utilisée par l’agent de codage Codex d’OpenAI. Cela transforme DeepSeek-V4-Flash, d’un modèle rapide que les développeurs pouvaient placer derrière un agent, en un modèle conçu pour fonctionner au sein d’un client d’agent établi.

Ce renversement est important, car DeepSeek positionnait initialement Flash en dessous de V4 Pro. Son plus petit modèle était l’option la plus rapide, tandis que Pro portait le récit le plus ambitieux sur les agents. Le post-entraînement semble avoir réduit, voire inversé, cette hiérarchie sans modifier l’architecture de Flash.

Toutefois, ces chiffres proviennent de l’évaluation de DeepSeek elle-même. Deux tests sont internes, plusieurs résultats dépendent d’un banc d’essai non publié, et les développeurs indépendants commencent à peine à tester le nouvel endpoint. La bêta publique ouvre donc un défi crédible aux grands modèles de codage, mais elle ne tranche pas la compétition.

Ce qui a changé dans la bêta publique de DeepSeek Flash

DeepSeek a amélioré le comportement autour de son architecture Flash existante au lieu d’introduire un modèle de remplacement plus grand.

Selon l’annonce des benchmarks de DeepSeek, DeepSeek-V4-Flash-0731 conserve l’architecture et la taille du modèle en préversion. L’entreprise indique avoir appliqué uniquement un post-entraînement supplémentaire, l’étape qui façonne la manière dont un modèle entraîné raisonne, suit les instructions et utilise des outils.

Cette distinction est au cœur de la sortie. DeepSeek ne soutient pas que davantage de paramètres ont produit l’amélioration rapportée. L’entreprise affirme qu’un modèle plus petit est devenu un bien meilleur agent après avoir reçu un entraînement plus ciblé.

DeepSeek-V4-Flash compte 284 milliards de paramètres au total, dont 13 milliards activés pour chaque token. L’architecture de mélange d’experts ne sélectionne qu’une partie du modèle à chaque étape d’inférence. V4 Pro est bien plus grand, avec 1 600 milliards de paramètres au total et 49 milliards de paramètres actifs.

Les deux modèles sont apparus initialement en préversion le 24 avril. DeepSeek décrivait Flash comme son option rapide et efficace, avec un raisonnement proche de Pro et des performances similaires sur des tâches d’agents simples. Ses notes de version V4 attribuaient également aux deux modèles une fenêtre de contexte d’un million de tokens.

La nouvelle mise à jour modifie cette relation. DeepSeek a rapporté les résultats de bêta publique suivants : 82,7 sur Terminal Bench 2.1, 54,2 sur NL2Repo, 76,7 sur Cybergym et 54,4 sur DeepSWE. L’entreprise a également indiqué 70,3 sur Toolathlon Verified et 25,2 sur Agent Last Exam.

DeepSeek a rapporté un autre score de 25,1 sur la partie publique d’Automation Bench. Ses deux tests de codage internes ont produit 68,7 sur DSBench-FullStack et 59,6 sur DSBench-Hard.

Ces chiffres couvrent différentes dimensions du travail d’agent. Les benchmarks de terminal mesurent la capacité d’un modèle à accomplir des tâches via une interaction en ligne de commande. Les tests de dépôt examinent la navigation et les modifications dans des bases de code existantes. Les benchmarks d’outils testent la capacité d’un modèle à sélectionner et exploiter des fonctions externes en plusieurs étapes.

DeepSeek affirme que le modèle Flash mis à jour a dépassé V4 Pro Preview dans les neuf évaluations rapportées. Les évolutions les plus spectaculaires sont apparues, selon les résultats rapportés, sur les tâches nécessitant une action de codage soutenue plutôt que des réponses courtes ou une complétion de code isolée.

La bêta publique ne concerne que l’API officielle de Flash. DeepSeek a indiqué que son application web, son application grand public et l’API V4 Pro restaient inchangées. Les développeurs utilisant ces produits ne doivent pas supposer qu’ils disposent déjà du comportement mis à jour.

L’identifiant du modèle reste deepseek-v4-flash, ce qui réduit le travail de migration pour les utilisateurs existants de l’API. Cette commodité crée toutefois une préoccupation de versionnement. Les équipes ont besoin de leurs propres dossiers d’évaluation afin de déterminer si le comportement a changé après la mise à jour de l’endpoint.

Il ne s’agit pas d’une simple actualisation de modèle, car elle remet en cause une hypothèse familière. Un modèle plus grand ne reste pas automatiquement le meilleur agent lorsque le post-entraînement, le formatage des outils et le système d’exécution évoluent ensemble.

DeepSeek Flash parle désormais le langage attendu par Codex

La prise en charge native de la Responses API rend cette sortie importante sur le plan opérationnel, avant même que les affirmations des benchmarks ne reçoivent une confirmation indépendante.

Un modèle de codage ne fonctionne pas seul au sein d’un agent. Le client environnant envoie les instructions, déclare les outils, enregistre les sorties, gère le contexte et décide quand le modèle doit continuer. De petites défaillances de compatibilité peuvent compromettre un modèle par ailleurs capable.

La Responses API d’OpenAI fournit une interface structurée pour ces interactions. DeepSeek affirme désormais que son API prend ce format en charge nativement, permettant aux clients Codex d’utiliser DeepSeek comme fournisseur de modèles alternatif.

La configuration officielle de Codex de DeepSeek couvre la CLI Codex, l’application de bureau ChatGPT et l’extension Codex pour Visual Studio Code. Ces clients partagent un fichier de configuration ; une seule configuration de fournisseur peut donc exposer le modèle dans les trois environnements.

La documentation identifie actuellement DeepSeek-V4-Flash comme le seul modèle DeepSeek disponible via cette intégration. Elle indique que la prise en charge de V4 Pro est attendue début août 2026.

DeepSeek fournit un catalogue de modèles qui décrit Flash à Codex. Il spécifie une fenêtre de contexte de 1 048 576 tokens, la prise en charge des appels d’outils parallèles, trois niveaux d’effort de raisonnement et un outil de patch en format libre. Il déclare également les interfaces de shell et de recherche web attendues par le client.

Ce catalogue n’est pas un ajout cosmétique. Les clients d’agents doivent comprendre les limites de contexte de chaque modèle, les formats d’outils pris en charge et les contrôles de raisonnement. Des métadonnées incorrectes peuvent entraîner des tâches tronquées, des requêtes non valides ou des appels d’outils que le client ne peut pas exécuter.

DeepSeek propose un script de configuration automatisé ainsi qu’une méthode de configuration manuelle. Le script sauvegarde la configuration Codex existante, écrit le catalogue de modèles DeepSeek, ajoute le fournisseur et valide les fichiers obtenus.

L’intégration directe crée un cas d’usage concret. Un développeur peut ouvrir un dépôt inconnu, demander à l’agent d’examiner un test défaillant et le laisser rechercher des fichiers, modifier le code et exécuter des commandes. Le modèle doit conserver son état tout au long de la séquence.

Ce flux de travail est plus difficile que de générer une fonction à partir d’un prompt. L’agent doit interpréter les résultats des outils, repérer les hypothèses erronées, préserver les contraintes et éviter de répéter une action invalide. Il doit aussi produire des patchs adaptés au dépôt plutôt que simplement plausibles en apparence.

La Responses API élimine une couche d’adaptation entre Flash et Codex. Elle ne garantit pas que le modèle prendra de bonnes décisions. Elle donne toutefois aux développeurs un client standard par lequel ils peuvent tester ces décisions.

Cela met sous pression les fournisseurs qui s’appuient sur des ensembles propriétaires de clients et de modèles. Si Codex peut exploiter plusieurs backends de modèles via le même flux de travail, les développeurs peuvent comparer les modèles sans remplacer toute leur interface.

Cela met également DeepSeek sous pression. La compatibilité native facilite la comparaison dans les deux sens. Les utilisateurs peuvent tester Flash sur les dépôts et les commandes qu’ils utilisent déjà, puis changer de solution si son avantage dans les benchmarks ne résiste pas au travail réel.

Pourquoi un modèle plus petit peut dépasser V4 Pro Preview

Le bond rapporté désigne le post-entraînement et l’infrastructure des agents comme mécanisme, plutôt qu’une augmentation soudaine de la taille du modèle.

Les performances d’un agent dépendent de plus que des connaissances stockées durant le préentraînement. Un modèle doit apprendre quand appeler un outil, comment lire le résultat, quand réviser un plan et quand s’arrêter. Ces comportements peuvent s’améliorer grâce à l’apprentissage par renforcement dans des environnements exécutables.

DeepSeek a précédemment décrit un système d’entraînement d’agents appelé DeepSeek Elastic Compute, ou DSec. Il prend en charge les appels de fonctions, les conteneurs, les micro-machines virtuelles et les machines virtuelles complètes derrière une même interface logicielle.

Selon une analyse technique de l’architecture V4, DSec peut exécuter des centaines de milliers de sandboxes simultanés. Ces environnements permettent aux tâches d’entraînement de récompenser les résultats issus d’interactions réelles avec des outils au lieu d’évaluer le texte seul.

La conception de V4 cherche aussi à réduire le coût des longues traces d’agents. Chaque résultat de terminal, extrait de fichier, message d’erreur et réponse du modèle ajoute des tokens. Les étapes ultérieures doivent traiter cet historique qui s’allonge.

DeepSeek combine deux mécanismes d’attention compressée dans l’ensemble du modèle. Compressed Sparse Attention réduit la séquence avant de sélectionner les blocs pertinents. Heavily Compressed Attention crée une représentation beaucoup plus courte que chaque requête peut examiner.

L’analyse a indiqué que V4 Flash utilise 10 % du calcul d’inférence à un token requis par DeepSeek-V3.2 à un million de tokens. Il utilise également 7 % du cache clé-valeur de V3.2, la mémoire qui conserve le contexte antérieur pendant la génération.

Ces chiffres concernent l’efficacité architecturale, et non la mise à jour d’agent de juillet elle-même. Ils expliquent néanmoins pourquoi Flash constitue une base plausible pour des agents fonctionnant sur de longues durées. Un agent ne peut pas bénéficier d’une vaste fenêtre de contexte si chaque étape supplémentaire rend l’inférence impraticable.

V4 préserve également le contenu de raisonnement entre les messages utilisateur lorsque des outils sont impliqués. Ce comportement vise les flux de travail dans lesquels un développeur ajoute des instructions après qu’un agent a déjà inspecté des fichiers ou exécuté des commandes.

Le formatage des outils compte aussi. DeepSeek a introduit des tokens dédiés et un schéma fondé sur XML pour les appels d’outils. Cette approche sépare les chaînes simples des paramètres structurés et vise à réduire les erreurs d’échappement dans les requêtes imbriquées.

La mise à jour de juillet ne modifierait aucune de ces fondations architecturales. Elle ajuste le comportement de Flash par-dessus celles-ci. Cela suggère que DeepSeek a trouvé des gains supplémentaires dans les données d’entraînement, la conception des récompenses, les trajectoires d’outils ou les politiques d’instructions.

La recette exacte reste non divulguée. DeepSeek n’a pas publié assez d’informations pour distinguer la contribution du modèle mis à jour de celle du banc d’essai d’évaluation. Cette lacune empêche les observateurs externes d’attribuer l’augmentation des scores à une seule technique.

Malgré cela, cette direction correspond à une évolution plus large du développement des modèles. Les fournisseurs optimisent de plus en plus les modèles pour des trajectoires de tâches complètes plutôt que pour des réponses isolées. L’unité de performance devient un flux de travail réussi.

Cela favorise les modèles plus petits lorsqu’ils peuvent agir de manière fiable. Un modèle compact qui sélectionne le bon outil et se remet des erreurs peut surpasser un modèle plus grand qui raisonne bien mais perd le contrôle du flux de travail.

Cela change également la manière dont les équipes d’ingénierie devraient évaluer un agent de codage IA. Un score général de codage indique peu de choses sur la capacité du modèle à fonctionner dans un dépôt particulier, à respecter les conventions locales et à vérifier son propre patch.

Les équipes qui maintiennent déjà une documentation technique consultable peuvent relier les essais d’agents à leur base de connaissances d’ingénierie existante. Cela permet aux évaluateurs de comparer les changements générés avec les notes d’architecture, les décisions et les incidents antérieurs, au lieu de juger les sorties sur leur seule apparence.

L’avantage du modèle plus petit est donc conditionnel. Flash a besoin du bon client, des bonnes définitions d’outils, du contexte du dépôt et des autorisations d’exécution adéquates. DeepSeek a amélioré plusieurs couches de cette pile, mais les déploiements réels doivent fournir le reste.

L’avance dans les benchmarks s’accompagne de réserves importantes

Les résultats de DeepSeek constituent des éléments significatifs pour tester le modèle, mais ils ne sont pas une preuve indépendante de sa fiabilité en production.

La première réserve concerne le contrôle de l’évaluation. DeepSeek a choisi les paramètres du modèle, le harnais, les limites des tâches et le format de présentation des résultats. Les évaluations menées par les fournisseurs sont utiles pour montrer les atouts visés, mais elles couvrent rarement tous les échecs auxquels les utilisateurs seront confrontés.

DeepSeek a testé des tâches publiques d’agents de programmation avec ce qu’il appelle le DeepSeek Harness, en mode minimal. L’entreprise a utilisé le paramètre d’effort maximal, un top_p de 0.95 et une température de 1.0.

Le harnais n’a pas été publié. Les chercheurs indépendants ne peuvent donc pas reproduire la configuration exacte ni déterminer dans quelle mesure elle a contribué aux résultats. Les scores des agents évoluent souvent lorsque le prompt, l’enveloppe d’outils, le délai d’expiration ou la politique de relance change.

La deuxième réserve porte sur la composition des tests. DSBench-FullStack et DSBench-Hard sont des jeux de données internes. Les évaluateurs externes ne peuvent pas examiner leur répartition des tâches, leurs contrôles de contamination, leurs règles de notation ou leurs cas d’échec.

Les évaluations internes peuvent révéler des faiblesses ignorées par les benchmarks publics. Elles ne peuvent toutefois pas garantir une responsabilité publique tant que les tâches ou un processus d’audit crédible ne sont pas disponibles.

Le troisième enjeu est la saturation des benchmarks et l’optimisation qui en découle. Lorsque des tâches publiques sont largement utilisées, les développeurs de modèles peuvent orienter l’entraînement vers leurs formats. Un score plus élevé peut refléter un apprentissage utile, une spécialisation étroite, ou les deux.

Le quatrième enjeu est la fiabilité opérationnelle. Un modèle peut réussir un benchmark délimité tout en se comportant de manière incohérente lors d’une tâche de plusieurs heures. Les agents en production font face à des instructions ambiguës, des dépendances changeantes, des services indisponibles et des limites d’autorisation.

La sécurité soulève un autre défi. Cybergym peut mesurer certains aspects du raisonnement en cybersécurité, mais les déploiements en entreprise nécessitent aussi des contrôles sur l’exécution de commandes, la gestion des secrets, l’accès réseau et les actions destructrices. Les capacités du modèle ne remplacent pas un environnement d’exécution contraint.

Des analystes indépendants ont soulevé des préoccupations similaires après l’aperçu V4 d’avril. Ivan Su, analyste chez Morningstar, a décrit V4 comme une suite compétente, tout en indiquant qu’une évaluation indépendante était nécessaire avant de tirer des conclusions définitives.

Lian Jye Su, analyste chez Omdia, a proposé une lecture plus positive, affirmant que les premiers benchmarks indiquaient que V4 rivaliserait avec les principaux modèles américains. Les deux points de vue figuraient dans un rapport indépendant sur V4.

Ces positions ne sont pas contradictoires. DeepSeek peut être un concurrent sérieux tout en devant encore faire tester ses affirmations les plus ambitieuses par des acteurs externes. La bêta publique est l’étape où ces propositions se confrontent.

Les comparaisons avec OpenAI, Anthropic et Google exigent également de la prudence. Les différents fournisseurs présentent leurs résultats avec des paramètres de modèle et des structures d’agents distincts. Un score attribué à un modèle reflète souvent un système complet.

La mise à jour V4 Flash crée un problème de comparaison supplémentaire, car V4 Pro Preview est une cible mouvante. DeepSeek indique que la version officielle de V4 Pro suivra, et sa documentation Codex prévoit bientôt une prise en charge de l’intégration.

Une victoire de Flash sur le modèle en aperçu pourrait donc être temporaire. La comparaison reste importante, car elle montre ce qu’un post-entraînement ciblé a permis d’accomplir, mais elle n’établit pas une hiérarchie durable entre les produits.

Les développeurs devraient également surveiller les régressions. Un apprentissage par renforcement supplémentaire peut améliorer la persistance dans l’usage des outils tout en rendant un modèle plus verbeux, moins prudent ou plus enclin à exécuter un plan incertain.

Une évaluation utile devrait consigner l’achèvement des tâches, le temps de correction humaine, les appels d’outils invalides, les actions répétées, les échecs de tests et les modifications involontaires de fichiers. La latence et la consommation de contexte comptent également, car les agents sollicitent le modèle de manière répétée.

Les preuves les plus solides proviendront de dépôts qui n’ont jamais fait partie du processus d’entraînement ou de benchmark. Les résultats devraient inclure les tâches échouées, et pas seulement des démonstrations soignées.

En attendant ces évaluations, la conclusion précise reste limitée. DeepSeek rapporte une nette amélioration de ses agents, rend le point de terminaison mis à jour accessible aux tests publics et fournit une intégration Codex directe. L’entreprise n’a pas encore démontré le même avantage dans des environnements de production non contrôlés.

Qui subit la pression de la mise à niveau de l’agent DeepSeek V4

La pression immédiate pèse sur les fournisseurs de modèles qui facturent aux développeurs l’intelligence tout en la liant à une expérience d’agent propriétaire.

OpenAI a conçu Codex autour de ses propres modèles et de l’API Responses. La prise en charge native de DeepSeek transforme cette interface en terrain de concurrence. Le client reste familier, tandis que le fournisseur sous-jacent change.

Cela ne fait pas de DeepSeek un équivalent immédiatement interchangeable pour toutes les charges de travail Codex. Les modèles peuvent interpréter différemment les mêmes définitions d’outils, et certaines fonctionnalités du client peuvent dépendre de comportements propres au fournisseur. La compatibilité réduit néanmoins l’effort nécessaire pour mener une comparaison sérieuse.

Anthropic fait face à un défi similaire avec Claude Code. DeepSeek avait déjà documenté des intégrations avec Claude Code, OpenCode, OpenClaw et d’autres systèmes d’agents pendant la période d’aperçu de V4.

Google est en concurrence via ses produits de programmation fondés sur Gemini et ses API destinées aux développeurs. Son échelle, ses capacités multimodales et sa distribution cloud restent des avantages considérables. Chaque fournisseur doit toutefois désormais expliquer pourquoi les développeurs devraient accepter une pile étroitement couplée.

La pression atteint aussi les plus petits fournisseurs de modèles de programmation. DeepSeek Flash combine une grande fenêtre de contexte, une API officielle, des poids de modèle ouverts issus de la version d’aperçu et la prise en charge de plusieurs clients d’agents.

La distribution compte ici autant que les performances sur les benchmarks. Un modèle très bien noté qui exige une intégration personnalisée peut être moins testé qu’un modèle légèrement moins performant, disponible dans des outils familiers.

La stratégie de DeepSeek semble viser à réduire les frictions de changement au niveau de l’interface. Les développeurs peuvent conserver un client, exposer le même dépôt et comparer les résultats. Cela met davantage l’accent sur l’achèvement réel des tâches.

L’entreprise est également en concurrence avec son propre modèle V4 Pro. Flash servait auparavant d’option plus légère pour les tâches sensibles à la vitesse. Ses nouveaux scores donnent aux développeurs une raison de le tester sur des tâches auparavant réservées à Pro.

Cette concurrence interne peut aider DeepSeek à segmenter les charges de travail plus efficacement. Les équipes pourraient envoyer le travail de dépôt courant à Flash et réserver Pro aux tâches exigeant un raisonnement plus approfondi.

DeepSeek n’a toutefois pas montré que cette stratégie de routage fonctionne de manière constante. Les nouveaux résultats de Flash se concentrent sur les benchmarks d’agents, tandis que Pro peut conserver des avantages en matière de connaissances, de raisonnement et de planification complexe.

Les entreprises doivent prendre en compte des éléments qui dépassent la capacité brute. La résidence des données, les règles de conformité, la gouvernance des fournisseurs, les engagements de support et les restrictions géopolitiques peuvent empêcher l’adoption, quelles que soient les performances sur les benchmarks.

DeepSeek fait également l’objet d’un examen attentif concernant ses pratiques d’entraînement et sa politique de sécurité. Anthropic et OpenAI ont accusé des laboratoires chinois, dont DeepSeek, d’extraire des capacités par distillation. DeepSeek n’a pas accepté ces accusations.

Ce différend ne détermine pas si Flash fonctionne bien. Il influence toutefois les examens d’approvisionnement, notamment dans les organisations réglementées et les environnements du secteur public.

Pour les développeurs indépendants et les petites équipes, la décision est plus directe. Ils peuvent exécuter des tâches représentatives, inspecter chaque commande et comparer les correctifs produits. La bêta offre suffisamment d’accès pour commencer ce travail immédiatement.

Pour les grandes organisations, la meilleure question n’est pas de savoir si Flash remporte un classement public. Elle consiste à déterminer si le modèle réduit l’effort total d’ingénierie sans créer une exposition inacceptable en matière de sécurité ou de gouvernance.

Cette norme s’applique aussi à ses concurrents. La publication de DeepSeek met le marché sous pression en rendant l’interchangeabilité des modèles plus pratique, mais chaque fournisseur doit encore gagner la confiance nécessaire à la production.

Trois signaux détermineront si DeepSeek Flash conserve son avance

La prochaine phase dépendra de la reproductibilité, de la sortie officielle de V4 Pro et d’une adoption durable dans de véritables flux de travail d’agents.

Le premier signal est la publication du DeepSeek Harness. DeepSeek affirme avoir utilisé ce cadre en mode minimal pour les évaluations publiques d’agents de programmation et prévoit de le publier.

Un harnais public permettrait aux chercheurs de réexécuter les tests, d’examiner les prompts et de comparer Flash à d’autres modèles dans des conditions similaires. Des résultats concordants renforceraient l’affirmation de DeepSeek selon laquelle le post-entraînement a produit une véritable hausse de capacités.

De grands écarts affaibliraient cette conclusion. Ils pourraient montrer que des relances cachées, des prompts spécifiques aux tâches ou des politiques d’exécution ont contribué davantage que le modèle lui-même.

Le deuxième signal est le lancement officiel de V4 Pro. DeepSeek indique que Pro suivra prochainement, tandis que sa documentation mentionne une prise en charge de Codex au début du mois d’août.

Cette sortie mettra à l’épreuve le renversement central de l’article. Si le modèle Pro final reprend une nette avance pour les agents, Flash deviendra une option secondaire efficace plutôt que la nouvelle référence de performance.

Si Flash reste proche ou en tête, DeepSeek devra expliquer le rôle de son modèle beaucoup plus grand. Les développeurs pourraient alors préférer Flash, à moins que Pro ne procure un avantage mesurable sur leurs tâches les plus difficiles.

Le troisième signal est constitué des données d’adoption réelles provenant des utilisateurs de Codex. Des preuves utiles incluront des traces complètes de dépôts, des correctifs reproductibles et des rapports d’échec issus de bases de code diverses.

Observez à quelle fréquence Flash se rétablit après une commande échouée. Suivez s’il répète des opérations invalides, modifie des fichiers non concernés ou s’arrête avant la vérification. Ces comportements déterminent si un agent fait réellement gagner du temps.

Des essais de longue durée révéleront également si le contexte d’un million de tokens demeure utile à mesure que les historiques s’accumulent. La capacité seule ne garantit pas que le modèle retrouve le bon détail après des centaines d’interactions avec des outils.

Les développeurs devraient commencer par des tâches circonscrites. Un essai adapté pourrait consister à localiser un défaut, écrire un correctif ciblé, exécuter les tests existants et expliquer le résultat. Le dépôt devrait utiliser le contrôle de version, des identifiants restreints et un environnement d’exécution isolé.

Les équipes peuvent ensuite comparer Flash à leur modèle actuel en utilisant le même ensemble de tâches. Elles devraient conserver les exécutions échouées et les interventions humaines, car les exemples ne montrant que les succès masquent la charge opérationnelle.

La bêta publique de DeepSeek Flash mérite l’attention parce qu’elle associe trois évolutions : des scores d’agents rapportés par le fournisseur plus élevés, la prise en charge standard de l’API Responses et une compatibilité Codex directe. Ensemble, ces changements facilitent l’évaluation du modèle là où les agents de programmation opèrent réellement.

Ils ne suppriment pas la nécessité de faire preuve de scepticisme. L’avance rapportée du modèle repose sur des tests menés par l’entreprise, deux benchmarks internes et un harnais que les observateurs externes ne peuvent pas encore examiner.

La prochaine décision appartient aux développeurs. Choisissez plusieurs tâches représentatives du travail réel, exécutez-les avec des autorisations contrôlées et mesurez les résultats achevés plutôt que des réponses attrayantes. Si DeepSeek Flash conserve son avance dans ces conditions, le plus petit modèle aura fait davantage que battre un benchmark d’aperçu. Il aura remis en question la manière dont les équipes choisissent l’intelligence qui se trouve derrière leurs agents.