DeepSeek : comment choisir entre l’API officielle, les poids publiés et des fournisseurs tiers sans confondre ouverture et contrôle opérationnel

L’unité de décision n’est pas le nom DeepSeek

Adopter DeepSeek ne revient pas à sélectionner en une fois une famille, une variante et un canal d’exécution. Une organisation peut utiliser un endpoint exploité par DeepSeek, télécharger et exécuter des poids publiés, ou souscrire auprès d’un tiers qui expose un modèle sous ce nom. Ces options peuvent partager une partie d’une généalogie technique, mais elles répartissent différemment le contrôle, le risque et la responsabilité opérationnelle.

La première discipline consiste à empêcher qu’un nom commercial se substitue à l’inventaire technique. « DeepSeek-R1 », « DeepSeek-V3 » ou une dénomination ultérieure peuvent apparaître dans des annonces, des dépôts, des interfaces de chat et des catalogues d’API. Aucune de ces occurrences ne démontre, à elle seule, quelle révision reçoit une requête, quels poids la produisent, quelle configuration d’inférence est appliquée ou qui traite les données. Avant de comparer les capacités, l’équipe doit identifier l’objet exact qu’elle souhaite approuver.

Cette précaution importe particulièrement lorsqu’un alias d’API conserve un nom stable. Le journal des modifications de l’API DeepSeek documente des lancements, des retraits, des redirections d’alias et des périodes de compatibilité. Un identifiant invocable peut donc ne pas garantir l’immuabilité du modèle sous-jacent. Ce n’est pas un défaut en soi : cela peut faciliter des mises à jour gérées. Mais il faut alors décider si le produit a besoin d’une capacité mise à jour par l’opérateur ou d’une version figée et reproductible.

La bonne question opérationnelle est la suivante : « quel modèle ou service, exploité par qui, dans quelles conditions et avec quelles preuves, sera utilisé pour cette fonction précise ? ». L’annuaire des organisations peut aider à trouver le profil de DeepSeek, et le comparateur à situer des alternatives, mais la décision doit conserver ses propres preuves pour chaque canal d’accès.

Inventaire des surfaces d’accès et des preuves qui les identifient

L’API officielle est un service distant. L’équipe consomme une interface, un identifiant de modèle et des conditions de plateforme, tandis que l’infrastructure d’inférence demeure sous le contrôle de l’opérateur. Ses avantages potentiels sont de réduire l’exploitation interne et de permettre des changements administrés ; ses contreparties sont la dépendance à la disponibilité, aux limites, à l’évolution du service et aux informations envoyées à l’endpoint.

Les poids publiés constituent un artefact qu’une organisation peut obtenir et exécuter sur une infrastructure qu’elle contrôle, à condition de respecter la licence applicable. Ce contrôle peut aider à figer une révision, restreindre le réseau, choisir une région et définir la conservation des journaux. Il ne fournit toutefois pas automatiquement un service de production : il faut construire ou souscrire l’inférence, l’authentification, l’observabilité, la montée en charge, l’évaluation, la réponse aux incidents et la gestion des vulnérabilités.

Un fournisseur tiers ajoute une couche supplémentaire. Il peut proposer une région donnée, une facturation intégrée, des contrôles réseau, des métriques ou un support commercial. Il peut aussi servir une variante adaptée, quantifiée, routée via un alias ou remplacée au fil du temps. Son affirmation de compatibilité avec une API ou de disponibilité d’un modèle DeepSeek ne prouve pas l’identité avec le service officiel ni avec un checkpoint publié.

L’inventaire initial doit consigner, pour chaque cas, le canal, l’opérateur, le nom affiché à l’utilisateur, l’identifiant envoyé dans la requête, la date d’observation, l’environnement, la version du client et la source documentaire. Pour les poids, il doit aussi inclure le dépôt, la révision ou le hash vérifiable, le format, la méthode de conversion et la configuration d’inférence. Sans ce registre, un incident ultérieur ne pourra pas être attribué rigoureusement à un changement de modèle, d’infrastructure ou d’application.

Licences : les poids, le code et le service sont des couches distinctes

La licence du code ne doit pas servir de résumé des droits portant sur les poids. Dans le dépôt DeepSeek-V3, le fichier de licence du code est sous MIT, tandis que le fichier de licence du modèle contient des conditions propres au modèle. Cette différence documentaire est déterminante : une autorisation large sur le code n’efface pas les obligations, avis, restrictions ou conditions susceptibles d’affecter l’artefact de modèle.

La licence du modèle V3 prévoit des conditions relatives à l’utilisation, à l’hébergement ou à la redistribution, à la conservation des avis et aux dérivés. Une personne responsable des achats ou de la conformité ne doit pas transformer cette description en conclusion juridique simplifiée. Elle doit lire la version applicable à l’artefact qui sera téléchargé, la conserver dans le dossier de décision et vérifier si son mode de distribution, son application finale et ses modifications déclenchent des obligations précises.

Il ne faut pas non plus confondre une licence et le support. Une licence peut autoriser certains usages d’un checkpoint sans promettre la disponibilité d’un endpoint, des correctifs de sécurité, un niveau de service, la compatibilité avec des outils, une réponse aux incidents ou la continuité d’une variante. De même, un contrat d’API encadre une relation de plateforme et ne fait pas automatiquement de ses utilisateurs des distributeurs de poids.

Les conditions d’utilisation de la plateforme ouverte décrivent le cadre d’usage de la plateforme destinée aux développeurs et attribuent au développeur des responsabilités concernant ses applications et leurs utilisateurs en aval. Cela impose une revue conjointe entre ingénierie, sécurité, confidentialité, achats et conseil juridique. Cet article ne remplace pas cette revue : l’applicabilité concrète dépend de l’artefact, du pays, de l’architecture et de la relation contractuelle.

API officielle : contrôler le contrat d’intégration, pas seulement l’appel

Dans une intégration via l’API officielle, le modèle n’est qu’une partie de la dépendance. Il faut vérifier l’authentification, les quotas, les limites de débit, les fenêtres de contexte, les formats de réponse, la compatibilité avec les outils, la gestion des erreurs et le comportement lors des nouvelles tentatives. Le test doit être réalisé avec l’identifiant qui sera utilisé en production et avec une charge représentative, non pas uniquement au moyen d’une conversation manuelle réussie.

Le journal des modifications est une source opérationnelle essentielle, car il publie des changements de lancement, de retrait et de compatibilité. Il convient d’intégrer sa consultation au processus de gestion des changements. Si l’application dépend d’un alias, le dossier doit indiquer qu’il existe un risque de modification du modèle effectif. Si elle exige de la reproductibilité, elle doit demander à l’opérateur quel mécanisme documenté permet de figer une version ou, en son absence, limiter la promesse produit et conserver les résultats de test par date.

Les conditions de la plateforme ouverte sont pertinentes pour délimiter les responsabilités du développeur. La politique de confidentialité de DeepSeek déclare des catégories de données traitées, notamment des entrées utilisateur et des données liées aux paiements de la plateforme ouverte, et décrit le stockage et le traitement. Cette documentation est utile pour ouvrir une évaluation, mais elle ne suffit pas à déduire un isolement exclusif, une résidence précise, des durées de conservation applicables à chaque type de compte, l’utilisation à des fins d’entraînement ou des garanties contractuelles qui ne sont pas exprimées dans les documents disponibles.

Par conséquent, une équipe qui prévoit d’envoyer des informations internes, des données clients ou des données réglementées doit distinguer ce qui est publié de ce qui est garanti. Elle doit obtenir, par le canal commercial ou juridique approprié, des réponses écrites sur le traitement, les emplacements, la conservation, les sous-traitants ultérieurs, la notification d’incidents, l’effacement, les contrôles d’accès et les annexes applicables. Jusque-là, la classification des données et la conception de minimisation doivent tenir compte de cette incertitude.

Poids propres : davantage de contrôle technique, un périmètre de responsabilité plus étendu

Exploiter ses propres poids peut offrir un moyen plus direct de figer une révision et de décider où elle s’exécute. Cette affirmation n’est toutefois valable que si l’artefact exact est conservé, si ses identifiants sont vérifiés et si toute la chaîne de déploiement est contrôlée. Télécharger un dépôt par son nom, utiliser une étiquette mobile ou accepter une image de conteneur sans enregistrer sa provenance ne constitue pas de la reproductibilité.

L’équipe assume des tâches que l’opérateur gère dans le cadre d’une API : sélection et maintenance du moteur d’inférence, compatibilité matérielle, quantification, parallélisme, limites de concurrence, protection des secrets, filtrage des entrées, journalisation des événements, sauvegardes, mise à jour des dépendances, observabilité et réponse aux incidents. Elle doit également évaluer les changements induits par les modèles de conversation, les paramètres de décodage, les outils connectés et ses propres couches de sécurité. Deux installations fondées sur les mêmes poids peuvent produire des réponses différentes.

L’ouverture d’un artefact ne démontre pas non plus, à elle seule, sa sécurité pour un cas d’usage. Les sources disponibles pour cette analyse n’apportent ni garantie contractuelle de sécurité, ni system card permettant de déduire une évaluation complète pour chaque famille. L’absence de telles preuves publiques ne prouve pas que le modèle est non sécurisé ; elle signifie qu’il ne faut pas affirmer qu’il satisfait un niveau donné sans tests indépendants et critères définis par l’adoptant.

L’évaluation doit couvrir le flux réel de l’application. Mesurer une tâche de référence ou un taux global de bonnes réponses ne suffit pas. Il faut des tests de fuite d’instructions, de contenu indésirable, d’extraction de données, d’abus d’outils, de dégradation sous charge, de reprise après redémarrage et de régression entre révisions. Les décisions de production doivent dépendre de seuils documentés et d’un responsable qui accepte le risque résiduel.

Fournisseurs tiers : évaluer la couche ajoutée sans présumer une identité

Un fournisseur tiers peut être pertinent lorsqu’il apporte une condition dont l’équipe a besoin, par exemple une facturation centralisée, une zone de déploiement, une connectivité privée, de l’observabilité ou du support. Ces capacités doivent être validées comme des propriétés de ce fournisseur, non comme des propriétés intrinsèques de DeepSeek. De même, une garantie offerte par le tiers ne se transfère pas automatiquement à l’API officielle, aux poids publiés ou à un autre revendeur.

La diligence minimale commence par l’identification de l’opérateur qui reçoit la requête et facture le service. Il faut ensuite demander la variante déclarée, le mécanisme de versionnage, les règles de remplacement, l’infrastructure ou la région applicable, la politique de journaux, le traitement des données, les sous-fournisseurs, le support et le processus de notification des changements. Si la réponse se limite à une étiquette commerciale, la version doit être classée comme non vérifiée.

La compatibilité de protocole décrit seulement une interface. Un endpoint compatible peut accepter une structure de requête semblable et néanmoins appliquer une version différente, une quantification distincte, un modèle de conversation propre, des limites différentes ou un routage vers plusieurs backends. Il est également impossible de déduire, sans test et déclaration de l’opérateur, qu’il sert le même checkpoint et la même configuration qu’un autre endpoint.

Dans l’achat, les vérifications doivent combiner revue documentaire et mesure. Exécutez des cas de régression, évaluez les limites et les temps de réponse, vérifiez l’exportation autorisée des journaux et simulez un retrait ou un changement de modèle. Si l’application utilise des fonctions, des outils ou des sorties structurées, testez-les avec des entrées adverses et des défaillances partielles. L’objectif n’est pas de démontrer une équivalence abstraite, mais de vérifier que le service souscrit satisfait les exigences déclarées.

Classification des usages et registre des changements

L’approbation ne doit pas être binaire. Un canal peut suffire pour l’exploration sans convenir à la production. Pour une expérimentation, un compte contrôlé, des données synthétiques, un test fonctionnel et une annotation des incertitudes peuvent suffire. Pour un usage interne limité, il faut ajouter la classification des données, des contrôles d’accès, une évaluation des risques et le suivi des changements. Pour une production tournée vers les clients, l’exigence augmente : architecture de continuité, propriétaire opérationnel, preuves contractuelles lorsque nécessaire, tests de sécurité et mécanisme de retour arrière.

Le registre des changements doit être un artefact vivant, et non une note dans une présentation. Pour chaque déploiement, conservez le canal d’accès, l’opérateur, l’identifiant invoqué, la famille et la variante déclarées, la révision ou le hash lorsqu’ils existent, la date, la configuration pertinente, la version du client, la région connue, les limites observées, la batterie d’évaluation et les résultats. Ajoutez une décision explicite sur les incertitudes acceptées.

Cette discipline permet de répondre précisément aux questions ultérieures : une sortie a-t-elle changé, l’endpoint a-t-il été modifié, l’application a-t-elle changé son modèle de conversation, un poids a-t-il été mis à jour ou une dépendance a-t-elle échoué ? Elle évite également que l’organisation attribue à DeepSeek une propriété qui appartient au fournisseur tiers ou à son propre environnement. L’ouverture peut élargir les options de déploiement, mais elle ne remplace ni la gestion de configuration, ni l’évaluation, ni la responsabilité de l’entité qui livre le produit final.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.