DeepSeek Harness : service de modèle personnalisé

Avant d’ajouter une route, il faut distinguer quatre situations. Le risque le plus courant consiste à recréer un Provider personnalisé alors que le service est déjà disponible dans le catalogue intégré, ce qui produit des doublons et complique ensuite le suivi des sessions.

Le dépôt officiel classe actuellement DeepSeek Harness en developer preview et avertit que des changements incompatibles peuvent encore intervenir. Il ne faut donc pas déduire qu’un service simplement déclaré « compatible » par son éditeur fonctionnera automatiquement avec les outils, le raisonnement, le streaming ou la découverte des modèles. La mention du mode de préversion et le risque de rupture sont indiqués dans le README officiel du projet.

L’objectif n’est pas seulement d’obtenir une réponse HTTP. Un Provider doit aussi être sélectionnable par l’interface ou la session, exposer un modèle identifiable et produire un format de réponse que la boucle d’agent peut interpréter. Une passerelle peut donc réussir une requête de test directe tout en échouant dans DeepSeek Harness dès qu’un appel d’outil ou un champ de raisonnement est ajouté.

Le choix du Provider doit être fait avant la configuration technique, car il détermine la maintenance future.

Dans le cas d’une API officielle DeepSeek, la route intégrée reste le choix de référence. La documentation de l’API décrit notamment le point d’accès de type /chat/completions, les identifiants de modèles et les appels d’outils ; ces éléments ne doivent pas être réécrits dans une nouvelle route uniquement pour changer une clé d’accès. Les détails du format sont disponibles dans la référence officielle de création d’une réponse de chat.

À l’inverse, un modèle servi par une passerelle interne peut avoir une URL différente, un identifiant propre à l’organisation ou une politique d’authentification que le catalogue ne connaît pas. Dans ce cas, le Provider personnalisé répond à un besoin réel.

La configuration doit commencer par une fiche courte, validée par l’équipe qui exploite la passerelle. Il faut éviter de remplir l’interface au hasard, car un champ incorrect peut être accepté au moment de l’enregistrement puis échouer lors de la découverte ou de la première génération.

Le catalogue officiel de configuration décrit les routes sous la forme d’un dictionnaire de Providers. La clé du dictionnaire représente la route, tandis que les propriétés associées peuvent inclure la référence de clé, le protocole, l’URL de base, la liste des modèles, les en-têtes et certaines capacités déclarées. Cette structure explique pourquoi le Provider ID n’est pas un simple libellé visuel.

Un identifiant comme gateway-interne peut sembler interchangeable avec modele-test, mais les deux ne doivent pas être traités comme des alias après le premier enregistrement. Les journaux, les sélecteurs et les sessions peuvent conserver la route initiale. Si l’équipe renomme l’identifiant trop tôt, elle risque de confondre une nouvelle route avec une modification de l’ancienne.

Pour les secrets, la référence à une variable d’environnement ou à un coffre de credentials est préférable à une clé saisie dans un fichier partagé. Cette séparation permet de changer le secret sans changer l’identité de la route, tout en évitant d’inclure une valeur sensible dans un dépôt ou une capture d’écran.

La Base URL doit être testée comme une adresse de service et non comme une simple indication administrative. Certaines passerelles attendent une racine générale, d’autres exposent directement une version de l’API. Il ne faut donc pas ajouter automatiquement /v1, /api ou /chat/completions sans vérifier le chemin réellement documenté par le service.

Le protocole est tout aussi important. Une route inconnue du catalogue doit annoncer le protocole qu’elle utilise, tandis qu’une route cataloguée peut conserver les informations du modèle installé. Le catalogue officiel précise également que les modèles définis manuellement doivent comporter un identifiant envoyé au fournisseur ; le nom d’affichage, lui, sert seulement à la sélection humaine.

Enfin, l’identifiant de modèle doit être copié depuis la passerelle, et non reconstruit à partir du nom commercial. Une route peut afficher « modèle raisonneur interne » tout en exigeant un identifiant technique différent. Cette différence est une cause fréquente de configuration enregistrée mais inutilisable.

Un Provider personnalisé peut-il utiliser une passerelle interne ?

Oui, à condition que la passerelle expose réellement le protocole attendu et que DeepSeek Harness puisse associer la route à au moins un modèle utilisable. La compatibilité ne se limite pas à accepter une requête de conversation : la réponse doit aussi contenir les champs nécessaires à l’adaptateur, et les appels d’outils doivent respecter le format prévu.

La première vérification doit porter sur la découverte des modèles, avant toute utilisation dans un dépôt important. Il faut procéder dans cet ordre :

1. ouvrir une session de configuration séparée du travail courant ;
2. créer le Provider ID définitif ;
3. saisir la Base URL et la référence de credentials ;
4. choisir le protocole documenté par la passerelle ;
5. lancer la récupération du catalogue si l’interface le propose ;
6. comparer les identifiants retournés avec ceux fournis par l’équipe modèle ;
7. enregistrer uniquement après avoir noté le résultat de la découverte.

La présence d’un bouton ou d’un statut « enregistré » ne prouve pas qu’un modèle est appelable. L’enregistrement valide généralement la forme de la configuration, alors que la découverte et la génération valident la chaîne complète.

Une réponse 401 lors de la récupération du catalogue doit être traitée comme un problème d’authentification, pas comme une preuve que le modèle est absent. Il faut vérifier la variable réellement lue par le processus, la présence du préfixe attendu dans l’en-tête et les règles de la passerelle. Modifier le modèle ou recréer plusieurs Providers à ce stade ne corrige pas un secret incorrect.

Si la passerelle ne propose aucun catalogue, l’équipe doit choisir entre une déclaration manuelle du modèle et un autre service de découverte. La décision dépend des champs acceptés par la version installée de DeepSeek Harness ; les noms de propriétés ne doivent pas être inventés à partir d’anciens exemples, puisque le projet évolue encore rapidement.

Une fois le modèle visible, la validation doit rester progressive. Un test directement exécuté sur un dépôt de production mélange trop de variables : contexte du projet, outils disponibles, permissions locales, taille des fichiers et comportement du modèle.

La séquence recommandée est la suivante :

1. créer un espace de travail vide ou sans données sensibles ;
2. démarrer une nouvelle session, distincte des sessions existantes ;
3. sélectionner explicitement le Provider personnalisé et le modèle ;
4. envoyer une demande textuelle courte, déterministe et facilement vérifiable ;
5. relever l’identité de la route, l’identifiant du modèle, le statut de réponse et le message d’échec éventuel ;
6. ajouter un seul outil sans effet destructif, par exemple une lecture d’un fichier de test ;
7. vérifier que l’appel est proposé dans le format attendu ;
8. exécuter le même scénario avec la route de secours ;
9. conserver les résultats dans le journal de changement.

L’API officielle documente les réponses de conversation, le streaming et les appels d’outils ; ces éléments fournissent une grille de contrôle utile, mais ne prouvent pas que chaque passerelle tierce reproduit exactement le même comportement. Un service peut accepter le texte et refuser les fonctions, ou accepter un appel d’outil mais renvoyer des arguments sous une forme que l’agent ne sait pas exploiter. Les instructions officielles consacrées aux appels d’outils doivent donc être comparées avec la documentation de la passerelle cible.

Le test doit produire trois résultats distincts :

• texte valide : l’identité du Provider et du modèle est bien résolue ;
• outil correctement interprété : la compatibilité dépasse la simple génération ;
• échec récupérable : la route de secours peut être sélectionnée sans modifier le dépôt ni réécrire la session.

Modifier le service fait-il basculer automatiquement les anciennes sessions ?

Non, il ne faut pas partir de cette hypothèse. Une session ayant déjà envoyé des requêtes peut conserver son propre enregistrement de modèle. Modifier la valeur par défaut influence principalement les nouvelles sessions ou les nouveaux agents créés après le changement, tandis qu’une conversation existante peut continuer à référencer son Provider initial.

Ce comportement est important pour éviter une fausse conclusion. Si une ancienne session continue d’appeler le service précédent, cela ne signifie pas que le nouveau Provider est ignoré. Il faut ouvrir une nouvelle session, sélectionner la nouvelle route et refaire le test minimal. Le catalogue officiel distingue justement la sélection du Provider et du modèle au niveau des agents ou des composants qui créent une session ; le catalogue de configuration généré par le projet constitue la référence à consulter pour la version installée.

Lorsque le Provider d’origine a été supprimé ou que son modèle n’est plus disponible, la meilleure approche consiste à :

• ne pas réécrire l’historique à l’aveugle ;
• créer une nouvelle session avec la route validée ;
• comparer les résultats sur une tâche minimale ;
• archiver l’ancien identifiant et la raison du changement ;
• ne supprimer l’ancienne route qu’après confirmation que les sessions nécessaires ne dépendent plus d’elle.

Cette méthode évite de masquer un défaut de configuration en modifiant simultanément la session, le modèle et le secret.

Un Provider personnalisé doit être géré comme une dépendance de production, même lorsqu’il ne sert d’abord qu’à un prototype. Le registre de changement doit contenir au minimum :

• la date et la version de DeepSeek Harness ;
• le Provider ID ;
• la Base URL utilisée ;
• la référence du secret, jamais la valeur du secret ;
• le protocole déclaré ;
• les identifiants de modèles acceptés ;
• le résultat de la découverte ;
• le résultat du test texte ;
• le résultat du test d’outil ;
• la route de repli et la condition qui déclenche son activation.

Après une mise à niveau de DeepSeek Harness ou de la passerelle, il faut rejouer le même scénario minimal. La régression peut toucher le catalogue, le protocole, le format du raisonnement, le streaming ou les tool calls, sans apparaître dans une simple vérification de connexion.

Le repli doit rester opérationnel et documenté. Une route de secours déjà validée vaut mieux qu’une nouvelle configuration créée dans l’urgence, surtout lorsque le modèle sert des agents capables de modifier des fichiers ou d’exécuter des commandes. Pour les aspects de déploiement distant et de continuité d’accès, le centre d’aide en français de NUKCLOUD peut compléter cette procédure avec les contraintes propres à l’environnement utilisé.

Liste de contrôle avant passage en équipe

• [ ] Le routage intégré a été écarté pour une raison précise.
• [ ] Le Provider ID définitif a été choisi avant le premier enregistrement.
• [ ] La Base URL a été testée sans ajout automatique de suffixe.
• [ ] Le protocole a été confirmé par la documentation de la passerelle.
• [ ] La référence de credentials fonctionne dans le même environnement que DeepSeek Harness.
• [ ] Le catalogue a été découvert ou le modèle a été déclaré selon les possibilités de la version installée.
• [ ] L’identifiant technique du modèle a été vérifié caractère par caractère.
• [ ] Une nouvelle session a réussi une requête texte.
• [ ] Un outil non destructif a été testé séparément.
• [ ] Une route de repli a été exécutée avec le même scénario.
• [ ] Le changement a été consigné avant l’ouverture à d’autres utilisateurs.

Pour une équipe qui doit également vérifier un usage audio, vidéo ou design, la validation peut ensuite être étendue aux pièces jointes et aux contextes plus volumineux, mais uniquement après la réussite du chemin texte et outil. Cela sépare les problèmes de Provider des limites propres aux modalités d’entrée ou aux capacités du modèle.

Une passerelle interne testée depuis un poste de travail peut donner des résultats trompeurs : réseau différent, variables d’environnement absentes, certificats locaux, processus interrompu lors de la fermeture de session ou accès limité au VPN. Une machine macOS distante et toujours disponible apporte un environnement plus stable pour les essais répétés, notamment lorsqu’un agent doit être contrôlé pendant plusieurs heures ou lorsqu’un flux audio, vidéo ou design doit être vérifié dans les mêmes conditions.

La solution actuelle — poste local, tunnel ponctuel ou machine personnelle — présente toutefois plusieurs limites : elle dépend de la disponibilité d’un collaborateur, elle reproduit mal les conditions d’un service continu et elle rend les tests difficiles à rejouer après une modification du modèle. Elle peut convenir à une validation unique, mais devient moins adaptée lorsqu’il faut comparer une route, une route de secours et une nouvelle version de passerelle.

Dans ce contexte, louer un environnement Mac auprès de NUKCLOUD permet de séparer le test du poste quotidien, de garder un espace dédié en ligne et de refaire la même procédure après chaque changement. Le choix reste à nuancer : l’achat d’un Mac est plus cohérent pour une charge lourde et permanente, tandis qu’un autre hébergement peut convenir si macOS ou les interfaces spécifiques ne sont pas nécessaires. En revanche, pour une validation temporaire de DeepSeek Harness, une passerelle interne et des outils d’agent dans un environnement macOS isolé, la location d’un Mac distant évite d’immobiliser du matériel avant que la route modèle soit réellement validée. Les équipes peuvent consulter les options de commande Mac de NUKCLOUD puis appliquer la liste de contrôle ci-dessus avant de décider d’un déploiement durable.

Pour aller plus loin, le site français de NUKCLOUD permet de préparer le cadre d’accès avant de transformer une validation ponctuelle en environnement d’exploitation.