ITSkillsCenter
Intelligence Artificielle

DeepSeek : modèles, API et déploiement local

17 دقائق للقراءة

En l’espace de deux ans, DeepSeek est passé du statut d’outsider à celui d’acteur majeur des modèles de langage, avec une particularité qui change tout pour un développeur : ses modèles les plus puissants sont publiés en poids ouverts, sous licence permissive, et son API figure parmi les moins chères du marché. Concrètement, vous pouvez appeler un modèle de pointe dans le nuage pour quelques centimes, ou télécharger une version et la faire tourner chez vous, gratuitement. Ce guide pose la carte complète : quels modèles existent, comment les appeler, où les déployer, et comment choisir entre le nuage et votre propre machine. Les tutoriels pratiques qui l’accompagnent prennent ensuite chaque brique en main, pas à pas.

Sommaire

🎯 Ce que ce parcours vous permettra de faire

  • Nommer les principaux modèles DeepSeek et savoir lequel choisir pour un besoin donné.
  • Appeler l’API DeepSeek depuis Python en réutilisant l’écosystème OpenAI.
  • Faire tourner un modèle DeepSeek sur votre propre machine, avec ou sans carte graphique.
  • Exploiter le raisonnement et produire des sorties structurées exploitables par un programme.
  • Intégrer le modèle à votre éditeur de code et le servir en production sous charge.
  • Arbitrer en connaissance de cause entre l’API distante et l’auto-hébergement.

🗺️ Par où commencer

Cette série se suit dans un ordre naturel, du plus simple au plus avancé, et chaque étape construit une brique d’un assistant que l’on enrichit au fil de l’eau. Voici l’itinéraire conseillé.

  1. Commencez par les premiers pas avec l’API en Python : c’est le chemin le plus rapide pour obtenir une réponse et comprendre la mécanique de base.
  2. Enchaînez sur le déploiement local avec Ollama pour faire tourner un modèle sans clé ni crédit, hors ligne.
  3. Montez d’un cran avec le raisonnement et les sorties JSON fiables, indispensables dès qu’un programme doit consommer la réponse.
  4. Installez l’assistant dans VS Code avec Continue pour coder plus vite au quotidien.
  5. Terminez par la mise en production avec vLLM quand le besoin passe du poste individuel au service partagé.

Pourquoi DeepSeek compte aujourd’hui

Trois raisons expliquent l’intérêt soudain pour DeepSeek. La première est l’ouverture : là où la plupart des modèles de pointe restent enfermés derrière une API, DeepSeek publie les poids de ses modèles phares sur les plateformes de partage, sous licence MIT pour les plus récents. Vous n’êtes donc pas prisonnier d’un fournisseur : si l’API ferme ou augmente ses prix, vous pouvez toujours héberger le modèle vous-même.

La deuxième raison est le coût. La tarification de l’API DeepSeek est agressive — de l’ordre de quelques dizaines de centimes pour des milliers de requêtes courtes — grâce notamment à un mécanisme de cache de contexte qui réduit drastiquement le prix des entrées répétées. Pour un projet à petit budget, cela fait la différence entre une idée qui reste sur le papier et un service que l’on peut réellement mettre en ligne.

La troisième est la performance, en particulier sur le raisonnement. Les modèles DeepSeek se distinguent sur les tâches qui demandent de réfléchir par étapes — mathématiques, logique, code — grâce à des modèles spécialisés qui exposent leur cheminement avant de conclure. Cette combinaison rare — ouvert, abordable et capable — est ce qui place DeepSeek au centre des conversations techniques.

Les concepts à connaître

Avant de plonger dans les modèles, quelques notions éclairent les choix techniques que vous ferez. Elles reviennent dans tous les tutoriels de la série.

Le mélange d’experts

Les grands modèles DeepSeek reposent sur une architecture dite de mélange d’experts. L’idée : plutôt qu’un seul réseau géant activé pour chaque mot, le modèle est découpé en nombreux sous-réseaux spécialisés, et seuls quelques-uns sont sollicités à chaque jeton. Résultat, un modèle peut compter des centaines de milliards de paramètres au total tout en n’en activant qu’une petite fraction par calcul. On obtient la richesse d’un très grand modèle pour le coût de calcul d’un modèle bien plus petit — c’est ce qui rend ces modèles à la fois puissants et exploitables.

L’attention efficace et le contexte long

Traiter de très longs documents coûte cher en mémoire, car le mécanisme d’attention compare chaque mot à tous les autres. DeepSeek a développé des techniques d’attention plus économes — une attention latente compressée, puis une attention parcimonieuse dans les modèles les plus récents — qui réduisent fortement cette consommation. C’est ce qui permet aux modèles DeepSeek-V4 d’accepter jusqu’à un million de jetons de contexte, soit l’équivalent de gros volumes de documentation injectés en une seule fois.

La distillation

Un modèle de pointe est trop lourd pour tourner sur un ordinateur ordinaire. La distillation consiste à entraîner un modèle plus petit à imiter le comportement du grand. Le petit modèle conserve une bonne part de la qualité du grand pour une fraction des ressources. C’est exactement ce que sont les versions « distillées » de DeepSeek-R1 que l’on fait tourner en local : des modèles de 1,5 à 70 milliards de paramètres qui héritent du raisonnement du modèle complet.

Les modèles de raisonnement

Un modèle de raisonnement ne répond pas du tac au tac : il déroule d’abord une réflexion, étape par étape, puis livre sa conclusion. Cette chaîne de pensée améliore nettement la fiabilité sur les problèmes complexes. DeepSeek expose ce cheminement dans un champ séparé de la réponse, ce qui permet de l’inspecter ou de le masquer. Le revers : le raisonnement consomme plus de jetons et prend plus de temps, d’où l’intérêt de l’activer seulement quand il apporte vraiment quelque chose.

Le paysage des modèles

L’offre DeepSeek se répartit en deux familles complémentaires : les modèles récents pour l’API, et les modèles à poids ouverts que l’on déploie soi-même. Le tableau ci-dessous donne les repères essentiels.

Modèle Type Repères Usage typique
deepseek-v4-flash API, rapide 284 milliards de paramètres au total, 13 activés ; contexte 1 million Le choix par défaut : vite, peu cher
deepseek-v4-pro API, capable 1 600 milliards au total, 49 activés ; contexte 1 million Raisonnement difficile, tâches exigeantes
DeepSeek-V3 / V3.2 Poids ouverts Environ 671 à 685 milliards au total Auto-hébergement sur grosse infrastructure
DeepSeek-R1 (distillé) Poids ouverts 1,5 à 70 milliards selon la version Raisonnement en local, du portable au serveur

Pour l’API, DeepSeek-V4 a été présenté en avril 2026 avec deux variantes : flash, rapide et économique, et pro, plus capable. Toutes deux acceptent un contexte d’un million de jetons et proposent un mode de raisonnement activable. Les anciens noms deepseek-chat et deepseek-reasoner restent utilisables un temps mais sont en voie de retrait : ils pointent désormais vers les variantes de flash. Pour tout nouveau projet, mieux vaut viser directement les noms de la génération V4.

Du côté des poids ouverts, DeepSeek-V3 et sa révision V3.2 sont les mastodontes que l’on héberge sur une infrastructure sérieuse, tandis que les versions distillées de DeepSeek-R1 — bâties sur les familles Qwen et Llama — descendent jusqu’à 1,5 milliard de paramètres, assez léger pour un ordinateur portable. Les poids de DeepSeek-V4 ont eux aussi été publiés sous licence MIT, ce qui en fait une option d’auto-hébergement pour qui dispose du matériel.

Appeler l’API

Le grand atout de l’API DeepSeek est sa compatibilité. Elle parle le même langage que l’API d’OpenAI : la bibliothèque openai fonctionne telle quelle, il suffit de la faire pointer vers l’adresse https://api.deepseek.com. Tout le code, tous les outils et tous les tutoriels écrits pour OpenAI deviennent réutilisables en changeant deux paramètres. Il existe même un point d’entrée compatible avec le format d’Anthropic, ce qui permet de brancher DeepSeek derrière des outils conçus pour cet écosystème.

Côté tarif, le modèle flash est facturé à des niveaux très bas, avec un cache de contexte qui réduit encore le coût des entrées répétées — un atout décisif pour un assistant qui réutilise sans cesse la même consigne système. Le détail des appels, du streaming, de la conversation à plusieurs tours et de la gestion du coût est couvert pas à pas dans les premiers pas avec l’API en Python. Et dès qu’il s’agit de faire raisonner le modèle puis de récupérer des données structurées, le guide sur le raisonnement et le JSON montre comment éviter les pièges classiques.

Déployer en local

Faire tourner un modèle chez soi répond à deux besoins : la confidentialité — les données ne sortent jamais de la machine — et l’indépendance vis-à-vis d’un service payant. Deux outils dominent, selon l’échelle visée.

Ollama est la voie la plus simple. En une commande, il télécharge un modèle DeepSeek-R1 distillé et l’expose derrière une API locale compatible OpenAI. C’est l’idéal pour un poste de travail individuel, des essais, ou un assistant hors ligne. Tout le parcours d’installation et d’usage est détaillé dans le guide consacré à Ollama.

vLLM vise l’autre extrémité : le service partagé sous charge. C’est un moteur d’inférence à haut débit, capable de traiter des dizaines de requêtes simultanées, que l’on déploie sur une ou plusieurs cartes graphiques pour offrir une API interne à toute une équipe. Sa mise en service, du démarrage à la sécurisation, fait l’objet du guide sur la mise en production avec vLLM. Entre les deux, un même principe rassurant : ces serveurs locaux exposent eux aussi le format OpenAI, si bien que votre code ne change presque pas d’un environnement à l’autre.

Nuage ou local : comment trancher

La question revient à chaque projet, et la réponse dépend de trois critères. Le premier est le volume. En dessous d’un certain trafic, l’API distante, sans matériel à entretenir et facturée à l’usage, est imbattable. Au-delà, quand la facture mensuelle de jetons dépasse le coût amorti d’une carte graphique, l’auto-hébergement devient rentable.

Le deuxième critère est la confidentialité. Si vos données ne doivent en aucun cas sortir de votre infrastructure — documents internes sensibles, contraintes réglementaires —, le déploiement local n’est pas un luxe mais une nécessité, et la question du coût passe au second plan.

Le troisième est la simplicité opérationnelle. L’API ne demande aucune maintenance : ni pilotes, ni matériel, ni surveillance. L’auto-hébergement, lui, suppose de gérer des cartes graphiques, des mises à jour et une supervision. Beaucoup d’équipes adoptent une approche mixte : l’API distante pour démarrer vite et pour les pics, un serveur local pour les volumes stables et les données sensibles. Les tutoriels de cette série couvrent les deux mondes précisément pour vous laisser ce choix ouvert.

Les guides de cette série

Chaque guide ci-dessous construit une brique concrète et peut se suivre seul, mais l’ensemble forme un parcours cohérent, de la première requête jusqu’au service en production.

Au-delà de la simple discussion

Réduire un modèle de langage à un robot conversationnel serait passer à côté de l’essentiel. Les modèles DeepSeek exposent plusieurs capacités qui, une fois maîtrisées, transforment un gadget en véritable outil d’ingénierie.

Les sorties structurées

Pour qu’un programme exploite une réponse, il lui faut des données prévisibles, pas de la prose. Le mode de sortie JSON force le modèle à produire un objet structuré et parsable, que l’on branche directement sur une base de données ou une file de traitement. C’est la clé pour passer d’un assistant qui « discute » à un composant qui « traite » — le sujet central du guide sur le raisonnement et le JSON.

L’appel d’outils

Un modèle ne sait rien du monde extérieur ni de l’heure qu’il est. L’appel d’outils — souvent désigné par son nom anglais, function calling — lui permet de demander l’exécution d’une fonction que vous avez définie : interroger une base, lancer un calcul, consulter une API météo. Le modèle ne fait pas l’action lui-même ; il indique laquelle déclencher et avec quels arguments, et votre code s’exécute. C’est le fondement des agents capables d’agir, pas seulement de répondre.

La complétion de code

Les modèles DeepSeek savent compléter du code en tenant compte de ce qui précède et de ce qui suit le curseur — une capacité appelée « remplissage au milieu ». C’est précisément ce qui alimente l’autocomplétion dans un éditeur, abordée dans le guide sur Continue dans VS Code. Là où un modèle de chat classique ne verrait que le début d’une ligne, un modèle de code raisonne sur le contexte complet du fichier.

Le contexte long et la recherche augmentée

Avec une fenêtre d’un million de jetons, les modèles V4 peuvent ingérer des volumes considérables de documentation en une seule requête. Cela ouvre la voie à la recherche augmentée : on sélectionne les passages pertinents d’une base documentaire, on les injecte en contexte, et le modèle répond en s’appuyant dessus plutôt que sur ses seules connaissances générales. C’est le principe d’un assistant ancré sur vos contenus, illustré côté local dans le guide Ollama.

La quantification : faire tenir un grand modèle sur peu de mémoire

Quand on déploie en local, une notion devient incontournable : la quantification. Un modèle stocke ses paramètres sous forme de nombres ; par défaut, chacun occupe seize bits de mémoire. La quantification réduit cette précision — à huit, quatre, voire moins de bits — ce qui divise d’autant la mémoire nécessaire, au prix d’une légère perte de qualité.

Concrètement, c’est ce qui permet de faire tourner un modèle de plusieurs milliards de paramètres sur un ordinateur portable. Une version fortement quantifiée tient dans la mémoire d’une machine modeste mais perd un peu en finesse ; une version peu quantifiée reste proche de la qualité d’origine mais réclame davantage de ressources. Les outils comme Ollama proposent par défaut un niveau équilibré, et laissent choisir une variante plus ou moins compressée selon le matériel. Comprendre cet arbitrage évite deux écueils symétriques : viser un modèle trop gros qui sature la mémoire, ou se contenter d’un modèle trop compressé qui déçoit. Les modèles DeepSeek-V4 poussent l’idée plus loin encore en mêlant plusieurs précisions au sein d’un même modèle, réservant la haute précision aux parties qui en ont le plus besoin.

Bien démarrer : cinq décisions à prendre

Face à l’éventail des modèles et des modes de déploiement, on peut se sentir perdu. Cinq questions, posées dans l’ordre, suffisent à cadrer n’importe quel projet.

  1. Vos données peuvent-elles sortir de chez vous ? Si non, le déploiement local s’impose d’emblée et oriente toute la suite. Si oui, l’API distante reste la voie la plus rapide.
  2. Quel est votre volume d’appels ? Faible ou irrégulier, l’API au jeton est parfaite. Élevé et stable, l’auto-hébergement devient économiquement pertinent.
  3. La tâche demande-t-elle du raisonnement ? Pour de la classification ou de l’extraction simple, un modèle rapide en mode direct suffit. Pour des problèmes complexes, activez le raisonnement ou choisissez un modèle plus capable.
  4. Avez-vous une carte graphique ? Elle conditionne le choix de l’outil local : Ollama se contente d’un processeur pour les petites tailles, vLLM exige une carte pour le haut débit.
  5. Qui va consommer le service ? Un développeur seul se contente d’Ollama sur son poste. Une équipe entière a besoin d’une API partagée, sécurisée et supervisée, terrain de vLLM.

Répondre à ces cinq questions vous mène droit au bon tutoriel de la série, sans détour. Et rien n’est figé : on commence souvent par l’API pour valider une idée, avant de basculer en local une fois le besoin confirmé.

Erreurs fréquentes

Erreur Cause Solution
Choisir pro pour tout On suppose que le plus capable est toujours préférable Réserver pro au raisonnement difficile, utiliser flash par défaut
Mal gérer la chaîne de raisonnement On la renvoie en conversation simple, ou on l’omet lors d’un appel d’outils En conversation simple, garder le résultat ; en flux d’outils, préserver le raisonnement attendu
Espérer du JSON sans l’imposer On compte sur le modèle pour bien formater Activer le mode JSON et valider la sortie côté code
Héberger trop tôt On self-héberge avant d’en avoir le volume Commencer par l’API, basculer quand le coût le justifie
Modèle local trop gros On choisit une taille au-dessus de sa mémoire Adapter la taille au matériel, quitte à descendre d’un cran

Questions fréquentes

Les modèles DeepSeek sont-ils vraiment ouverts ?
Oui, les modèles phares — V3, R1 et leurs distillations, ainsi que V4 — ont leurs poids publiés, sous licence MIT pour la génération la plus récente. Vous pouvez les télécharger et les héberger librement.

Puis-je réutiliser mon code écrit pour OpenAI ?
Dans la grande majorité des cas, oui. L’API DeepSeek, comme les serveurs locaux Ollama et vLLM, expose le format OpenAI. Il suffit de changer l’adresse de base et le nom du modèle.

Quel modèle choisir pour débuter ?
Pour l’API, commencez par deepseek-v4-flash : rapide et économique. Pour le local, la version distillée de 8 milliards de paramètres de DeepSeek-R1 offre le meilleur compromis sur une machine ordinaire.

Faut-il une carte graphique pour le local ?
Pas forcément avec Ollama, qui fonctionne aussi sur processeur pour les petites tailles, plus lentement. Pour un service à haut débit avec vLLM, une carte compatible CUDA est nécessaire.

Le mode raisonnement est-il toujours préférable ?
Non. Il améliore les tâches complexes mais consomme plus de jetons et de temps. Pour des réponses simples ou de l’extraction, le mode direct est plus efficace.

DeepSeek convient-il à un assistant de code ?
Oui. Branché sur un éditeur via Continue, il assure aussi bien l’autocomplétion que la revue de code, en local pour la confidentialité ou dans le nuage pour la qualité.

Pour aller plus loin

مشاركة
Service ITSkillsCenter

Application mobile Android et iOS

Création d'application mobile Android et iOS. À partir de 350 000 FCFA.

Démarrer mon projet
Publicité