Créer un chatbot avec l’API DeepSeek : guide 2026

Créer un chatbot avec l’API DeepSeek ne consiste pas seulement à relier un champ de texte à un modèle. Un assistant conversationnel fiable a besoin d’un backend, d’une mémoire contrôlée par l’application, de règles d’accès, d’une stratégie de récupération documentaire, de validations pour les outils et d’un protocole d’évaluation. Ce guide présente une architecture exploitable en production sans confondre « stateless », cache de contexte et conservation des données.

Indépendance : deepseek-fr.ai est un guide indépendant, non affilié à DeepSeek. Il n’héberge pas le service et ne reçoit pas vos prompts.

Dernière vérification factuelle : 20 juillet 2026. Les noms de modèles, limites, tarifs et conditions peuvent évoluer ; vérifiez les documents officiels DeepSeek avant une mise en production.

L’architecture recommandée en bref

Le navigateur ou l’application mobile ne doit jamais appeler DeepSeek avec votre clé secrète. Il envoie la requête à votre backend, qui authentifie l’utilisateur, recharge la conversation autorisée, récupère éventuellement des documents, appelle l’API, exécute les outils autorisés et enregistre uniquement les données prévues par votre politique.

Interface : saisie, affichage, streaming, annulation et retour utilisateur.
Backend : authentification, autorisation, validation, limitation de débit et protection de la clé API.
Mémoire applicative : historique par utilisateur et par conversation, résumé, suppression et durée de conservation définie par vous.
RAG facultatif : recherche dans une base documentaire avec contrôle des droits avant d’ajouter les passages au prompt.
API DeepSeek : génération de la réponse ou proposition d’appels d’outils.
Couche d’outils : validation, autorisation, exécution, confirmation humaine et audit des actions sensibles.
Observabilité : erreurs, latence, consommation de tokens, qualité et incidents, avec des journaux minimisés.

Composant	Responsabilité	Erreur à éviter
Client web ou mobile	Expérience utilisateur	Y intégrer la clé DeepSeek
Backend	Contrôle d’accès et orchestration	Faire confiance à un historique envoyé par le navigateur
Stockage de conversations	Mémoire du chatbot	Conserver sans limite ni mécanisme de suppression
Index documentaire	Récupération de passages pertinents	Ignorer les droits d’accès ou les instructions malveillantes dans les documents
Exécuteur d’outils	Actions réelles	Exécuter directement les arguments proposés par le modèle

« Stateless » : ce que cela signifie réellement

L’endpoint ne réinjecte pas automatiquement les tours précédents dans le contexte du modèle : l’application doit renvoyer les messages utiles à chaque requête. Cela ne décrit ni la journalisation, ni le cache disque, ni la durée de conservation des données par DeepSeek.

La documentation officielle sur les conversations multi-tours qualifie l’API de stateless au niveau du contexte d’inférence. Autrement dit, si votre backend n’envoie que le dernier message, le modèle ne dispose pas automatiquement des échanges précédents pour produire cette réponse. Votre application doit sélectionner et renvoyer le message système, les tours utiles, les résultats d’outils nécessaires et le nouveau message utilisateur.

Notion	Fonction	Qui la contrôle ?
Contexte d’inférence	Messages transmis pour générer la réponse courante	Votre backend construit la requête
Mémoire du chatbot	Historique, résumés, préférences et état métier	Votre application et vos bases
Cache de contexte DeepSeek	Réutilisation possible de préfixes d’entrée identiques pour optimiser le traitement	DeepSeek ; mécanisme distinct de la mémoire conversationnelle
Journaux et conservation	Traitement ou stockage pour d’autres finalités	Chaque responsable de traitement selon ses pratiques et conditions

Le cache de contexte sur disque est activé par défaut d’après la documentation consultée. Une requête ultérieure peut obtenir un cache hit lorsque son préfixe correspond à des unités déjà persistées, mais le résultat n’est pas garanti. La réponse reste nouvellement générée. Les champs prompt_cache_hit_tokens et prompt_cache_miss_tokens permettent d’observer l’usage du cache. Ce mécanisme n’est ni une base de conversations, ni une garantie d’effacement, ni une déclaration de confidentialité.

1. Définir le contrat du chatbot avant de coder

Écrivez d’abord ce que l’assistant peut faire, ce qu’il ne doit pas faire et quand il doit transférer la demande à un humain. Un chatbot de documentation, un copilote interne et un assistant transactionnel n’ont pas le même niveau de risque.

Périmètre : sujets autorisés, langues, sources et utilisateurs concernés.
Réponse attendue : texte libre, JSON validé, citations ou appel d’outil.
Limites : demandes à refuser, sujets à escalader et seuil d’incertitude.
Données : informations autorisées dans les prompts, durée de mémoire et procédure de suppression.
Actions : lecture seule, création, modification, paiement ou autre effet externe.
Objectifs mesurables : réussite de tâche, exactitude des sources, taux d’escalade, latence et consommation.

2. Choisir le modèle et rendre le mode de raisonnement explicite

Au 20 juillet 2026, les identifiants recommandés dans le Quick Start officiel sont deepseek-v4-flash et deepseek-v4-pro. Commencez par deepseek-v4-flash pour les échanges courants, puis comparez deepseek-v4-pro sur votre propre jeu d’évaluation lorsque la complexité justifie un arbitrage différent. Ne choisissez pas sur la base d’une affirmation générale de « meilleur modèle ».

Les identifiants historiques deepseek-chat et deepseek-reasoner sont encore présentés comme des alias de V4 Flash — respectivement sans et avec raisonnement — à la date de vérification. DeepSeek annonce leur retrait complet après le 24 juillet 2026 à 15 h 59 UTC. Ne les utilisez donc pas dans un nouveau chatbot et planifiez immédiatement la migration d’un projet existant.

Le raisonnement est activé par défaut dans la documentation actuelle. Envoyez explicitement thinking: { type: "disabled" } pour un échange simple ou thinking: { type: "enabled" } lorsqu’il apporte une valeur mesurée. En mode raisonnement, les paramètres temperature et top_p sont ignorés ; ne prétendez pas les utiliser pour régler la créativité dans ce mode. Consultez le guide officiel du mode Thinking.

Les tarifs et limites pouvant changer, évitez de les coder en dur dans votre documentation produit. Consultez la page des tarifs DeepSeek et la source officielle au moment de dimensionner le service.

3. Appeler DeepSeek uniquement depuis le backend

Créez une clé selon notre guide de clé API DeepSeek, placez-la dans un secret géré par votre hébergeur et exposez au client uniquement votre propre route authentifiée. Les conditions de la plateforme exigent de protéger les identifiants d’accès : une clé intégrée dans du JavaScript public, une application mobile ou un dépôt est récupérable.

DeepSeek documente une interface Chat Completions compatible avec le SDK OpenAI. Le squelette TypeScript suivant illustre la séparation correcte : le backend vérifie l’accès à la conversation, charge l’historique côté serveur et appelle client.chat.completions.create(). Les adaptateurs de stockage et d’autorisation restent à implémenter selon votre infrastructure.

import OpenAI from "openai";

type DeepSeekChatRequest =
  OpenAI.ChatCompletionCreateParamsNonStreaming & {
    thinking?: { type: "enabled" | "disabled" };
  };

const deepseek = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: "https://api.deepseek.com",
});

const SYSTEM_PROMPT = `
Tu es l’assistant de notre produit.
- Réponds uniquement dans le périmètre autorisé.
- N’invente ni source, ni action exécutée.
- Si les éléments fournis sont insuffisants, dis-le clairement.
`;

async function answerChat(input: {
  authenticatedUserId: string;
  conversationId: string;
  userText: string;
}) {
  await requireConversationAccess(
    input.authenticatedUserId,
    input.conversationId,
  );

  const history: OpenAI.ChatCompletionMessageParam[] =
    await conversationStore.read(input.conversationId);

  const messages: OpenAI.ChatCompletionMessageParam[] = [
    { role: "system", content: SYSTEM_PROMPT },
    ...selectUsefulHistory(history),
    { role: "user", content: input.userText },
  ];

  const request: DeepSeekChatRequest = {
    model: "deepseek-v4-flash",
    messages,
    thinking: { type: "disabled" },
  };

  const completion = await deepseek.chat.completions.create(request);
  const answer = completion.choices[0]?.message.content?.trim();

  if (!answer) throw new Error("Réponse DeepSeek vide");

  await conversationStore.append(input.conversationId, [
    { role: "user", content: input.userText },
    { role: "assistant", content: answer },
  ]);

  return {
    answer,
    finishReason: completion.choices[0]?.finish_reason,
    usage: completion.usage,
  };
}

Pour un projet réel, ajoutez une validation de schéma, une taille maximale du message, une limite par compte, un délai d’expiration, une annulation et des erreurs génériques côté client. Ne laissez jamais l’utilisateur choisir librement un autre conversationId sans contrôle de propriété. Le guide DeepSeek avec Node.js et TypeScript détaille l’installation, le typage et le streaming.

4. Concevoir une mémoire conversationnelle maîtrisée

Renvoyer toute la conversation à chaque tour finit par augmenter le coût, la latence et le risque d’exposer des données inutiles. Une mémoire robuste combine plusieurs niveaux :

Fenêtre récente : les derniers tours nécessaires pour conserver la continuité immédiate.
Résumé contrôlé : les décisions, contraintes et faits utiles, avec la possibilité de corriger ou supprimer le résumé.
État structuré : identifiants, étape d’un workflow et préférences dans des champs validés, plutôt que cachés dans du texte libre.
Mémoire documentaire : passages récupérés à la demande, distincts de l’historique de conversation.

Conservez la séparation par locataire et par utilisateur. Appliquez une durée de conservation explicite, chiffrez les données au repos et en transit, et fournissez les fonctions d’export ou de suppression exigées par votre produit et votre cadre juridique. N’envoyez pas l’intégralité d’un profil si deux attributs suffisent à répondre.

5. Ajouter le streaming sans exposer la clé

Pour réduire la latence perçue, le backend peut appeler Chat Completions avec stream: true, lire les événements SSE envoyés par DeepSeek, puis relayer uniquement le texte utile au navigateur via votre propre flux SSE ou WebSocket. Le flux officiel se termine par [DONE]. L’option stream_options.include_usage permet de demander un bloc d’usage dans le flux.

Propagez l’annulation du navigateur jusqu’à l’appel amont lorsque c’est possible.
N’enregistrez pas un message partiel comme réponse complète ; marquez clairement les générations interrompues.
Encodez le texte à l’affichage et n’interprétez jamais une sortie modèle comme du HTML fiable.
Traitez tous les finish_reason utiles, notamment stop, length, content_filter, tool_calls et les erreurs de ressource.
Ne transmettez pas automatiquement le contenu de raisonnement à l’interface ou aux journaux.

6. Relier le chatbot à vos documents avec un RAG

Le RAG, ou génération augmentée par récupération, sert à répondre à partir de contenus contrôlés et récents. Le flux recommandé est : ingérer les documents, les découper, créer un index, filtrer selon les droits de l’utilisateur, récupérer quelques passages pertinents, puis les transmettre avec leurs identifiants de source.

Point de vérification : dans la documentation publique officielle consultée le 20 juillet 2026, nous n’avons pas identifié d’endpoint DeepSeek dédié aux embeddings. Ne construisez donc pas votre architecture en supposant qu’il existe. Utilisez une solution d’embeddings ou de recherche séparée dont les conditions, la localisation des données et la qualité conviennent à votre projet, puis utilisez DeepSeek pour la génération.

Filtrez d’abord les documents selon l’organisation, l’utilisateur et le niveau d’accès.
Transmettez des extraits courts avec un identifiant, un titre, une URL et une date lorsque ces champs sont fiables.
Indiquez que le contenu récupéré est une donnée à analyser, pas une instruction prioritaire.
Demandez une citation vers les identifiants fournis et vérifiez côté serveur que chaque citation existe réellement.
Si les sources ne suffisent pas, exigez une réponse d’incertitude ou une escalade, pas une invention.
Réévaluez l’index après chaque mise à jour importante et supprimez les documents devenus inaccessibles.

Le contexte cache peut réduire le traitement de préfixes identiques, mais il ne remplace ni l’index, ni la recherche, ni les contrôles d’accès. Consultez notre guide du Context Caching DeepSeek.

7. Utiliser les outils sans déléguer l’autorisation au modèle

Avec les tool calls, le modèle ne réalise pas lui-même l’action. Il propose le nom d’une fonction et des arguments ; votre application doit valider, autoriser et exécuter la fonction, puis renvoyer le résultat au modèle pour poursuivre la conversation. La documentation officielle des tool calls décrit cette boucle.

N’exposez qu’une liste minimale d’outils et des schémas d’arguments stricts.
Revalidez tous les arguments côté serveur ; une sortie modèle reste une entrée non fiable.
Vérifiez l’identité, le rôle et la propriété de la ressource au moment de l’exécution.
Demandez une confirmation humaine avant un paiement, une suppression, un envoi ou une modification sensible.
Utilisez des clés d’idempotence afin qu’un nouvel essai ne répète pas une action irréversible.
Consignez le résultat de l’action séparément du texte généré, avec un audit minimisé.

Le mode strict est documenté sur l’URL bêta https://api.deepseek.com/beta et n’accepte qu’un sous-ensemble de schémas. Traitez-le comme une fonctionnalité bêta, testez vos schémas et ne confondez pas conformité de forme et autorisation métier. Notre guide du function calling DeepSeek fournit davantage de détails.

8. Choisir entre JSON et appels d’outils

Utilisez le JSON lorsqu’une réponse doit alimenter votre interface ou un traitement local sans effet externe. Utilisez un tool call lorsqu’une fonction du backend doit être proposée. Dans les deux cas, validez le résultat avant usage.

Le mode JSON utilise response_format: { type: "json_object" }. Le prompt doit demander explicitement du JSON et préciser sa forme. La documentation avertit qu’une sortie peut parfois être vide et recommande un budget de sortie raisonnable. Prévoyez donc parsing, validation de schéma et voie d’échec ; consultez notre guide des sorties JSON DeepSeek.

9. Confidentialité : ne déduisez rien du mot « stateless »

La politique de confidentialité de DeepSeek indique que le service peut collecter les entrées, notamment prompts, historique de chat et fichiers, et que les données sont traitées et stockées en Chine. Elle décrit une conservation aussi longtemps que nécessaire pour les finalités annoncées, sans promettre dans ce texte une durée universelle fixe applicable à toutes les données.

Si vous fournissez le chatbot à vos propres utilisateurs, vous déterminez aussi des finalités et moyens de traitement pour votre service. Les conditions de l’Open Platform vous imposent notamment d’informer vos utilisateurs et de protéger leurs données. Ne présentez pas votre chatbot comme « sans conservation », « hébergé en Europe » ou « conforme au RGPD » sur la seule base du caractère stateless de l’endpoint. Une telle affirmation exige une analyse factuelle, contractuelle, technique et juridique propre à votre déploiement.

Minimisez et expurgez les prompts avant l’envoi lorsque c’est possible.
Évitez les secrets, données de santé, identifiants officiels et autres informations sensibles sauf nécessité validée.
Affichez une information claire sur les fournisseurs, finalités, transferts, conservation et droits.
Définissez séparément la rétention de vos conversations, journaux, sauvegardes et évaluations.
Si vous utilisez user_id, envoyez un identifiant pseudonyme sans donnée personnelle ; respectez le format documenté.
Évaluez les options d’opposition à l’utilisation des données pour l’entraînement décrites par DeepSeek, sans les confondre avec une garantie de non-conservation.

Pour un examen plus large, consultez notre analyse DeepSeek est-il sûr ?, notre politique de confidentialité et notre clause d’indépendance.

10. Gérer erreurs, surcharge et répétition des requêtes

Le chatbot doit distinguer une erreur de requête d’une panne temporaire. DeepSeek documente notamment les codes 400 (format), 401 (authentification), 402 (solde), 422 (paramètres), 429 (limite), 500 (serveur) et 503 (surcharge). Ne renvoyez pas automatiquement toutes les requêtes.

Situation	Réponse recommandée
400, 401, 402 ou 422	Corriger la requête, le secret, le compte ou les paramètres ; pas de répétition aveugle
429	Mettre en file, réduire la concurrence et réessayer avec backoff exponentiel et jitter
500 ou 503	Réessayer un nombre limité de fois, puis afficher une voie de repli
Action d’outil	Ne jamais répéter sans idempotence et vérification de l’état réel
Réponse tronquée	Détecter `finish_reason: "length"` et demander une continuation contrôlée ou réduire le contexte

La documentation actuelle publie des limites de concurrence au niveau du compte et renvoie 429 en cas de dépassement. Ne supposez pas qu’un en-tête Retry-After sera toujours présent : votre stratégie doit fonctionner sans lui. Voir les guides limites de l’API DeepSeek et codes d’erreur DeepSeek.

11. Évaluer le chatbot avant et après le lancement

N’utilisez pas quelques conversations réussies comme preuve de qualité. Constituez un jeu d’évaluation versionné qui reflète les demandes réelles, y compris les formulations ambiguës, documents contradictoires, tentatives d’injection, utilisateurs sans permission, demandes hors périmètre et pannes d’outils.

Mesure	Question
Réussite de tâche	L’utilisateur obtient-il le résultat attendu ?
Ancrage	Les affirmations sont-elles soutenues par les passages fournis ?
Citations	Pointent-elles vers des sources réellement transmises et pertinentes ?
Escalade	Le bot transfère-t-il les cas prévus sans abandon prématuré ?
Sécurité des outils	Une action interdite, non autorisée ou dupliquée est-elle bloquée ?
Latence	Quels sont les percentiles, pas seulement la moyenne ?
Consommation	Combien de tokens d’entrée, sortie, cache hit et cache miss par tâche ?

Comparez les modèles, prompts, modes de raisonnement et stratégies RAG sur le même jeu. N’annoncez aucun gain sans mesure reproductible. Après le lancement, échantillonnez des conversations selon une procédure respectueuse de la confidentialité, surveillez les régressions et conservez une possibilité de retour à la version précédente.

Checklist de mise en production

La clé DeepSeek est uniquement côté serveur et stockée dans un gestionnaire de secrets.
Chaque route vérifie l’identité, le rôle et l’accès à la conversation ou au document.
Le chatbot utilise deepseek-v4-flash ou deepseek-v4-pro, pas un alias en fin de vie.
Le mode thinking est défini explicitement et testé.
L’historique envoyé est limité aux messages utiles ; le résumé est contrôlable et supprimable.
Le RAG filtre les documents avant récupération et vérifie les citations.
Chaque tool call passe par validation, autorisation, confirmation et idempotence adaptées au risque.
Les sorties JSON sont parsées et validées ; les sorties texte sont encodées.
Les délais, annulations, 429, 500, 503 et réponses tronquées sont gérés.
Les journaux évitent prompts complets, clés, données personnelles et raisonnement inutile.
L’information utilisateur décrit la sous-traitance, la localisation, les finalités et la conservation réelles.
Un jeu d’évaluation et des seuils de lancement sont définis.
Une voie d’escalade humaine et un mécanisme de désactivation existent.

Questions fréquentes

L’API DeepSeek mémorise-t-elle automatiquement une conversation ?

Non pour le contexte d’inférence multi-tour : votre application doit renvoyer les messages utiles à chaque requête. Cette propriété ne permet toutefois aucune conclusion générale sur les journaux, le cache ou la conservation des données par DeepSeek.

Puis-je appeler DeepSeek directement depuis le navigateur ?

Pas avec votre clé secrète. Faites passer les requêtes par un backend authentifié qui protège la clé, valide les entrées, contrôle les droits et limite l’usage.

Quel modèle choisir pour un chatbot DeepSeek ?

Utilisez un identifiant V4 actuel. deepseek-v4-flash constitue un point de départ pour les échanges courants ; comparez deepseek-v4-pro sur vos tâches lorsque la qualité mesurée justifie un autre compromis. N’utilisez plus les alias historiques dans un nouveau projet.

DeepSeek fournit-il un endpoint d’embeddings ?

Nous n’en avons pas identifié dans la documentation publique officielle consultée le 20 juillet 2026. Utilisez une solution séparée pour les embeddings ou la recherche, et revérifiez la documentation officielle avant de décider.

Le cache de contexte remplace-t-il la mémoire du chatbot ?

Non. Le cache de contexte peut réutiliser des préfixes d’entrée correspondants pour optimiser le traitement. Il ne sélectionne pas l’historique pertinent, ne gère pas les droits et ne constitue pas votre base de conversations.

« Stateless » signifie-t-il que DeepSeek ne conserve rien ?

Non. Le terme décrit ici l’absence de réinjection automatique des tours précédents dans le contexte du modèle. Consultez séparément la politique de confidentialité, les conditions de la plateforme et la documentation du cache pour comprendre les autres traitements.

Un chatbot DeepSeek est-il automatiquement conforme au RGPD ?

Non. La conformité dépend de votre finalité, des données, des utilisateurs, des bases juridiques, de l’information fournie, des contrats, des transferts, de la sécurité, de la conservation et des droits. La politique de DeepSeek indique un traitement et un stockage en Chine ; obtenez un avis qualifié pour votre cas.

Sources officielles vérifiées

Vous pouvez maintenant adapter cette architecture à votre cas d’usage. Pour une vue plus générale de l’intégration, consultez la documentation API DeepSeek en français ; pour le code serveur, utilisez notre guide Node.js et TypeScript.