DeepSeek 4.1 Flash est le nouveau modèle léger de DeepSeek, pensé pour la vitesse et le coût, avec un cache de contexte qui fait fondre la facture. Je l'ai mis à l'épreuve dans le DeepSeek Harness sur deux vrais projets : un site vitrine complet et une API de 50 endpoints. Verdict : environ 1 dollar par projet pour un résultat propre, mais des temps d'exécution qui dépendent énormément de ton prompt.
Dans la vidéo ci-dessus, je fais les deux tests en direct. Voici ce qui s'est passé, minute par minute et dollar par dollar.
DeepSeek 4.1 Flash, c'est quoi ?
DeepSeek a publié V4.1 Flash le 10 septembre 2026 (journal des mises à jour DeepSeek). C'est la version légère de sa famille de modèles, conçue pour aller vite et coûter peu. Le modèle est open source, sous licence MIT, donc utilisable commercialement.
Si tu veux l'angle stratégique (open source, souveraineté, ce que ça change face aux modèles américains), je l'ai traité dans un article dédié à DeepSeek V4 Flash et l'open source. Ici, on parle uniquement de pratique : qu'est-ce que ça donne quand tu lui confies un vrai projet ?
Des experts spécialisés plutôt qu'un seul gros cerveau
DeepSeek 4.1 Flash est un modèle à mélange d'experts (MoE). L'analogie que j'utilise dans la vidéo : l'hôpital.
Tu arrives avec un mal de dos, entouré de spécialistes, sans savoir vers qui te tourner. Le routeur, c'est l'accueil qui t'oriente vers le bon. Chaque token de ta demande part vers des experts spécialisés au lieu de mobiliser tout le modèle.
Lire vite, écrire fort
Deuxième choix de conception : le modèle survole vite ce qu'il lit (PDF, scans, images, dossiers de 500 pages) et met plus de puissance sur l'écriture. Selon DeepSeek, 8 milliards de paramètres sont actifs par token en lecture et 16 milliards en écriture, sur un total de 552 milliards (annonce officielle DeepSeek).
Un cache beaucoup plus léger
Le cache, c'est la mémoire de ce que le modèle a déjà lu, pour ne pas tout relire à chaque mot. DeepSeek annonce que ce cache nécessite quatre fois moins de mémoire vive (HBM) que la génération précédente (annonce officielle).
C'est là que se font les économies : avec les premiers Opus de Claude, on se trimballait énormément de contexte facturé. Ici, la partie déjà envoyée coûte beaucoup moins cher.
Les benchmarks publiés
Dans la vidéo, je passe en revue les benchmarks publiés par DeepSeek. Le modèle y gagne sur le terminal, les bugs réels, l'automatisation et la cybersécurité, jusqu'à 2,5 fois mieux que V4 Pro sur les tâches difficiles en terminal. Opus 5 reste devant sur les gros projets de code (NL2Repo Bench) et le raisonnement sans outils.
Ce sont des chiffres de l'éditeur, à confirmer par des tests indépendants. D'où les miens.
Les prix : c'est là que ça devient fou
Voici la grille officielle pour le modèle deepseek-flash (tarifs DeepSeek), par million de tokens :
| Type de token | Heures creuses | Heures pleines |
|---|---|---|
| Entrée, lue depuis le cache | 0,003 $ | 0,006 $ |
| Entrée, hors cache | 0,15 $ | 0,30 $ |
| Sortie | 0,60 $ | 1,20 $ |
Deux points à retenir :
- Heures pleines = tarif x 2. Regarde bien les horaires, sinon tu peux avoir des surprises.
- Le cache coûte 50 fois moins cher que l'entrée normale. Quand un agent renvoie le même contexte encore et encore, c'est ça qui fait baisser la facture.
Mon test pas à pas dans le DeepSeek Harness
Étape 1 : vérifier qu'on tourne vraiment sur 4.1 Flash
J'ai fait le test dans le DeepSeek Harness, l'équivalent de Cursor ou de Claude Code, mais directement chez DeepSeek.
Premier réflexe : je demande au modèle s'il tourne bien sur V4.1 Flash. Réponse : pas de 4.1 en vue.
J'ai donc vérifié dans la documentation. Le nom de modèle à utiliser, c'est deepseek-flash : il pointe directement vers V4.1 Flash. Une fois le modèle ajouté dans les réglages, le harness confirme qu'il tourne bien sur DeepSeek Flash V4.1.
Conseil pratique : DeepSeek change parfois le nom de ses modèles. Si tu as des applications en production branchées sur un nom précis, vérifie et mets à jour. Sinon, un jour, ça ne passe plus.
Étape 2 : un premier prompt raté
J'ai fait générer un prompt de test de rapidité par Grok. DeepSeek s'est contenté d'un petit quiz autoévalué (5/5, 4/5, 4/5). Pas ce que je voulais : place à un vrai projet.
Étape 3 : un site web one page pour une marque de montres de luxe
Le prompt : livrer un site one page premium pour une marque de montres de luxe, écrire tout le copywriting en français, avec des exigences du type « design parfait, mobile impeccable ».
Ce que j'ai vu pendant l'exécution :
- Il fait des captures d'écran et vérifie ce qu'il produit.
- Il lance trois relectures visuelles en parallèle, avec des agents parallèles.
- Il fait des allers-retours tout seul, ce qui m'évite d'en faire moi-même.
Résultat après environ 42 minutes. Le site est propre, bien fait et complet : les produits, les pages derrière, des pages dynamiques, même une prise de rendez-vous. Il est parti loin. Côté design, ce n'est pas trop mon goût, mais le site est fonctionnel. Il ne reste qu'à brancher le paiement et à fournir de vraies images.
Pourquoi 42 minutes ? L'écriture du site et sa vérification ont pris 12 minutes. Le reste, ce sont deux phases de relecture visuelle (9 et 20 minutes), soit environ 30 minutes. La cause : mes mots « design parfait, mobile impeccable » dans le prompt. Il a pris ça au sérieux et a mis en place une énorme phase de vérification.
Consommation. 13 millions de tokens, dont 99 % de l'entrée servie depuis le cache. Coût : environ 1 dollar.
Un dollar pour 40 minutes de travail avec autant de vérifications. Très honnêtement, c'est très peu cher.
Étape 4 : une API REST de 50 endpoints sécurisés et testables
Deuxième exercice, beaucoup plus exigeant : une API complète avec 50 endpoints, authentification, vérification des permissions. Pas une API de démo, une API qu'on pourrait lancer en production.
Pendant l'exécution, le harness affiche ses sous-agents : il organise et délègue, et ce sont les instances de DeepSeek Flash qui exécutent. L'interface est bien faite, tu peux entrer dans le détail de chaque partie.
Résultat. L'API elle-même était terminée en 14 minutes, tests compris. Je lui ai ensuite demandé d'ajouter un Swagger pour tester dans le navigateur. Au total, environ 21 minutes.
Ce qu'il a livré :
- Une spécification OpenAPI avec exactement 50 opérations.
- Environ 240 tests unitaires, avec une couverture de 96 %.
- Un README propre, les codes d'erreur, du rate limiting, la gestion du cross-origin.
- Une API cohérente avec le site des montres (marque, commandes…). Il a fait le lien tout seul.
Le seul accroc. Au premier appel dans Swagger, une erreur. C'était un problème de CORS : il fallait redémarrer le serveur pour qu'il prenne en compte la nouvelle configuration. Corrigé en quelques secondes, et la réponse est passée en code 200.
Consommation. 44 millions de tokens, pour environ 1 dollar de plus. Donc à peu près 2 dollars au total pour le site et l'API.
Ce genre d'API, avant, c'était des semaines de développement pour tout faire et tout tester.
Étape 5 : comprendre où sont passés le temps et les tokens
J'ai demandé au modèle pourquoi c'était aussi long. Son récapitulatif :
- La production de code ne pèse que 13 %, les corrections 5 %, la lecture 9 %. L'essentiel (73 %) est lié au cache.
- Le poste numéro 1, ce sont les boucles de vérification : 140 appels en ligne de commande (type check, lint, curl), dont neuf suites de tests complètes.
- Les 12 étapes les plus chères sont toutes des étapes d'écriture, ce qui confirme le choix de conception du modèle : il écrit beaucoup plus qu'il ne lit.
- Un vrai bug a coûté 10 minutes : une incompatibilité de la bibliothèque Zod 3 avec le fournisseur utilisé, qui bloquait tout.
Écrire les tests va vite, les exécuter prend du temps (et la puissance de ta machine joue). Le modèle m'a même proposé de supprimer certaines vérifications pour aller plus vite la prochaine fois.
Points forts et limites
Ce qui m'a convaincu : le prix (environ 1 dollar par projet), le cache, la compréhension de l'intention, la fiabilité du premier jet grâce à ses propres vérifications, et l'interface du harness.
Ce qui me freine :
- Le temps : 42 minutes pour un site one page, c'est long. Il faudrait comparer avec Claude Code ou Cursor.
- La sensibilité au prompt : un mot comme « impeccable » peut tripler la durée.
- Les noms de modèles qui changent : à surveiller en production.
- D'après les benchmarks publiés, Opus 5 reste devant sur les très gros projets de code.
Le problème n'a jamais été la vitesse du modèle. Le problème, c'est ce que tu lui demandes de vérifier.
Pour qui c'est utile
Si tu es entrepreneur, c'est la preuve qu'un site vitrine complet ou le backend d'une application peuvent sortir pour quelques dollars. À condition de savoir écrire le prompt.
Si tu es consultant IA, un modèle aussi peu cher change l'économie de tes missions : des agents qui tournent longtemps, avec beaucoup de vérifications, sans exploser le budget du client. C'est le genre de choix de modèle que je fais au quotidien en accompagnement consultant IA. Et si tu hésites entre les modèles du moment, j'ai aussi comparé GPT-6 Astra et Fable 5.1.
Récapitulatif du test
| Critère | Site one page (montres de luxe) | API REST 50 endpoints |
|---|---|---|
| Outil | DeepSeek Harness, modèle deepseek-flash | DeepSeek Harness, modèle deepseek-flash |
| Durée totale | Environ 42 minutes | Environ 21 minutes (14 min sans le Swagger) |
| Dont vérification | Environ 30 minutes de relecture visuelle | 140 appels de vérification, 9 suites de tests |
| Tokens | 13 millions (99 % de l'entrée en cache) | 44 millions |
| Coût | Environ 1 $ | Environ 1 $ |
| Qualité | Complet, propre, design à retravailler | 50 opérations OpenAPI, environ 240 tests, 96 % de couverture |
| Accroc | Aucun bloquant | Erreur CORS corrigée par un redémarrage |
FAQ
Qu'est-ce que DeepSeek 4.1 Flash ?
C'est la version légère et rapide de la famille DeepSeek V4, publiée le 10 septembre 2026. Un modèle à mélange d'experts, open source sous licence MIT, conçu pour la vitesse et un coût très bas grâce à un cache de contexte compressé.
Combien coûte DeepSeek 4.1 Flash ?
En heures creuses : 0,15 $ le million de tokens en entrée, 0,003 $ quand l'entrée vient du cache, 0,60 $ en sortie. En heures pleines, tout est multiplié par deux. Dans mon test, un site complet et une API de 50 endpoints m'ont coûté environ 1 dollar chacun.
Quel nom de modèle utiliser dans l'API DeepSeek ?
La documentation officielle indique d'utiliser deepseek-flash pour appeler V4.1 Flash. Le modèle est compatible avec la librairie OpenAI et déjà intégré dans la plupart des environnements de développement.
Pourquoi mon site a-t-il pris 42 minutes ?
Parce que mon prompt exigeait un « design parfait » et un « mobile impeccable ». Le modèle a lancé deux longues phases de relecture visuelle (environ 30 minutes au total). L'écriture du site elle-même n'a pris que 12 minutes. Allège les exigences de vérification si tu veux aller plus vite.
DeepSeek 4.1 Flash peut-il remplacer Claude pour coder ?
Pour des projets de taille moyenne, il livre un résultat propre pour un coût dérisoire. Sur les très gros projets de code, les benchmarks publiés placent encore Opus 5 devant. Mon conseil : teste-le sur tes propres projets avant de basculer.
Conclusion
DeepSeek 4.1 Flash, c'est un site et une API prêts à l'emploi pour environ 2 dollars. Le vrai levier n'est pas le modèle, c'est ton prompt : ce que tu lui demandes de vérifier décide du temps qu'il va passer.
La prochaine étape, c'est de refaire le même test dans Claude Code et Cursor pour comparer. Abonne-toi à ma chaîne YouTube pour ne pas le rater.
Si tu veux apprendre à piloter ces agents de code sans être développeur, regarde Maîtrise Claude. Et si tu veux qu'on voie ensemble quel modèle utiliser pour quel projet dans ton entreprise, prends rendez-vous ici : rdv.sophieneia.com.