DeepSeek V4 Preview vs V3.2 : ce qui change vraiment avant la mise à niveau

1. Le contexte à 1 million de tokens change les cas d’usage

La nouveauté la plus visible de DeepSeek V4 Preview est la fenêtre de contexte de 1 million de tokens. En pratique, cela compte si un seul appel au modèle doit contenir de nombreux fichiers d’un dépôt, une documentation technique volumineuse, des journaux système, un long historique de conversation ou une chaîne d’actions menée par un agent.

Il ne faut pas en déduire que le long contexte commence avec V4. DeepSeek-V3.2-Exp avait déjà introduit DeepSeek Sparse Attention, présenté comme un moyen d’améliorer l’efficacité de l’entraînement et de l’inférence sur long contexte. La bonne lecture est plutôt la suivante : V3.2-Exp a été une étape expérimentale importante dans cette direction, tandis que V4 place le long contexte au centre de la nouvelle génération de modèles.

2. V4-Pro et V4-Flash rendent les arbitrages plus lisibles

Avec V3.2, DeepSeek liste DeepSeek-V3.2 et DeepSeek-V3.2-Speciale dans son changelog. Avec V4, la Preview distingue deux branches : DeepSeek-V4-Pro et DeepSeek-V4-Flash.

Selon la page V4 Preview, V4-Pro compte 1,6 billion de paramètres au total, soit environ 1 600 milliards, dont 49 milliards de paramètres actifs ; V4-Flash compte 284 milliards de paramètres au total, dont 13 milliards actifs. Pour une équipe d’ingénierie, cette séparation donne un cadre de test plus concret : V4-Pro pour les tâches difficiles où l’on cherche la meilleure qualité dans la gamme V4, V4-Flash pour mesurer le compromis entre qualité, latence, coût et débit sur un grand volume de requêtes.

Le piège serait de choisir uniquement sur le nom du modèle. La méthode la plus sûre reste de rejouer les mêmes prompts, les mêmes données, les mêmes limites de tokens et les mêmes critères d’évaluation sur V3.2, V4-Flash et V4-Pro avant de changer de modèle par défaut.

3. Les agents de code deviennent un axe plus central

DeepSeek V3.2 était déjà une version importante pour les agents, car sa release mettait en avant la combinaison du thinking et du tool-use. Autrement dit, V3.2 n’était pas seulement positionné pour répondre à une question en un tour : il visait aussi des enchaînements où le modèle raisonne, appelle un outil, lit le résultat puis poursuit le traitement.

V4 Preview prolonge cette direction, mais insiste davantage sur l’agentic coding, c’est-à-dire des workflows où le modèle doit lire un contexte de code, planifier, modifier et coordonner plusieurs étapes, plutôt que produire un simple extrait de code isolé.

La différence n’est donc pas que V3.2 ne saurait pas faire d’agent et que V4 l’inventerait. Elle est plus nuancée : V3.2 consolide la base reasoning + tool-use ; V4 cherche à l’étendre aux agents de programmation et aux workflows à très long contexte.

4. Les benchmarks sont un signal, pas une garantie pour votre production

DeepSeek publie des benchmarks et des indications de performance dans la release V3.2 comme dans la V4 Preview Release. En dehors des sources officielles, une analyse technique consacrée aux modèles DeepSeek de V3 à V3.2 souligne aussi l’intérêt de V3.2 pour ses performances et son caractère open-weight.

Mais les sources disponibles ici restent principalement des notes de release, de la documentation API et une analyse technique fondée sur les informations publiées. Elles sont utiles pour repérer une direction, pas pour remplacer vos propres mesures sur vos charges réelles.

En production, la bonne question n’est pas « quel modèle gagne le benchmark général ? ». C’est plutôt : quel modèle répond le mieux à vos prompts, avec vos données, votre budget tokens, votre SLA de latence et votre grille qualité ? Tant que ces critères ne sont pas mesurés, V4 doit être vue comme une candidate très sérieuse à tester, pas comme un remplacement automatique.

5. La migration API est le point à ne pas rater

V4 s’accompagne d’un changement important côté appels API. DeepSeek indique dans la V4 Preview que deepseek-chat et deepseek-reasoner routent désormais vers deepseek-v4-flash, en modes non-thinking et thinking, et que ces deux alias seront totalement retirés après le 24 juillet 2026 à 15 h 59 UTC.

Ce point est critique, car la documentation API indiquait auparavant que deepseek-chat et deepseek-reasoner correspondaient à DeepSeek-V3.2. Si une application de production appelle un alias au lieu d’un identifiant de modèle explicite, le comportement du modèle peut évoluer sans que l’équipe ne le pilote réellement.

Côté intégration, la documentation DeepSeek précise que l’API adopte un format compatible avec OpenAI, ce qui permet d’utiliser le SDK OpenAI ou des logiciels compatibles OpenAI en ajustant la configuration de l’endpoint. DeepSeek fournit aussi une documentation de compatibilité avec l’API Anthropic, qui détaille la prise en charge de champs comme max_tokens, stream, system, temperature et thinking.

Checklist de migration :

1. Rechercher dans le code, les fichiers de configuration et les secrets si l’application appelle deepseek-chat, deepseek-reasoner ou un identifiant de modèle précis.
2. Rejouer les prompts en modes thinking et non-thinking si votre workflow dépend du raisonnement.
3. Mesurer à nouveau la latence, le coût, les erreurs, les timeouts et la qualité des réponses sur données réelles.
4. Sortir des anciens alias avant l’échéance du 24 juillet 2026 à 15 h 59 UTC.
5. Vérifier les champs API si vous passez par une couche compatible OpenAI ou Anthropic.

Faut-il passer de DeepSeek V3.2 à V4 ?

Oui, il faut essayer V4 si votre produit a besoin d’un très long contexte, si vous construisez un agent de code, si vous voulez comparer V4-Pro sur des tâches difficiles ou si vous cherchez à évaluer V4-Flash sur un volume élevé de requêtes.

En revanche, garder V3.2 comme baseline reste raisonnable si votre pipeline est stable, si vous n’avez pas besoin d’un contexte de 1 million de tokens ou si votre production exige encore un benchmark interne avant tout changement de modèle.

En résumé : V3.2 marque une étape forte sur le reasoning et l’usage d’outils ; V4 Preview pousse plus loin le long contexte, la séparation Pro/Flash et les agents de code. Pour les équipes techniques, la qualité du modèle n’est qu’une partie du sujet : le plan de migration hors des alias API historiques est tout aussi important.