DEV Community

Cover image for DeepSeek Harness (dsh) : Décryptage du rival open source de Claude pour le code
Antoine Laurent
Antoine Laurent

Posted on Originally published at apidog.com

DeepSeek Harness (dsh) : Décryptage du rival open source de Claude pour le code

DeepSeek a livré quelque chose d'inhabituel le 13 août 2026 : non pas un modèle, mais la machine qui en exécute un. DeepSeek Harness (dsh) est l'armature d'agent open source officielle de l'entreprise. Cette couche logicielle transforme un grand modèle linguistique en agent de codage : boucle de session, exécution d'outils, contrôles de permissions et interface web locale. Lancé le même jour que DeepSeek V4-Pro sur l'API, VentureBeat l'a présenté comme un rival open source de Claude Code.

Essayez Apidog dès aujourd’hui

La communauté a réagi rapidement. Au 20 août, le dépôt deepseek-harness comptait environ 169 000 étoiles et 18 100 forks, une semaine après sa sortie. Ces chiffres reflètent surtout un besoin : disposer d'une armature d'agent que les développeurs peuvent inspecter, modifier et connecter au modèle de leur choix.

Ce qu'est réellement DeepSeek Harness

Une armature regroupe tout ce qui entoure le modèle.

Le modèle prédit des jetons. L'armature, elle :

  • construit le contexte envoyé au modèle ;
  • expose les outils que le modèle peut appeler ;
  • contrôle les écritures de fichiers et les commandes shell ;
  • demande les approbations nécessaires ;
  • conserve l'état d'une session multi-étapes.

Claude Code, Codex CLI et Gemini CLI sont également des armatures autour des modèles de leurs fournisseurs. Pour comparer les deux premiers, consultez Claude Code vs Codex CLI.

DeepSeek Harness se distingue par trois caractéristiques :

  • C'est un projet officiel. Il est maintenu par DeepSeek AI, et non par la communauté autour de l'API.
  • C'est open source. Le projet est sous licence MIT et documente ses dépendances tierces dans THIRD_PARTY_NOTICES. Vous pouvez lire la boucle d'agent qui intervient dans votre codebase.
  • C'est une préversion destinée aux développeurs. Le README indique explicitement : « IL Y AURA DES CHANGEMENTS BRISANT LA COMPATIBILITÉ. » Considérez ce point comme une contrainte d'implémentation, pas comme un avertissement théorique.

dsh est arrivé en même temps que DeepSeek V4-Pro sur l'API. Si vous évaluez aussi le modèle, le guide sur l'API DeepSeek V4-Pro couvre les endpoints, les identifiants de modèles et les requêtes de base.

L'architecture : tout est un plugin

La plupart des agents de codage sont monolithiques : boucle d'agent, client de modèle, outils et stockage de session sont regroupés dans une même application. Vous pouvez généralement les configurer, parfois les étendre, mais rarement remplacer leurs composants centraux.

dsh adopte l'approche inverse : tout est un plugin.

Son architecture repose sur Cordis, décrit dans l'article “A Programming Paradigm for Spatiotemporal Composability”. En pratique, les composants habituellement intégrés en dur dans un agent deviennent interchangeables :

  • Adaptateur de modèle : la couche qui appelle l'API LLM est un plugin. Remplacez-la pour utiliser un autre backend.
  • Registre d'outils : les outils accessibles à l'agent — édition de fichiers, shell, recherche — sont ajoutés par des plugins.
  • Journal de session : le stockage et la relecture des sessions sont configurables.
  • Boucle d'agent : le cycle décider → agir → observer peut lui aussi être remplacé.

Cette architecture est utile si vous devez tester plusieurs stratégies :

  • différents modèles selon les tâches ;
  • politiques de permissions spécifiques à un dépôt ;
  • outils internes ;
  • gestion du contexte adaptée à une codebase volumineuse ;
  • exécution locale ou via une passerelle API.

Le compromis est clair : plus de modularité signifie plus de points de rupture. Puisque dsh est une préversion avec des changements incompatibles annoncés, prévoyez de maintenir vos plugins et votre configuration.

Démarrage rapide : lancer un agent local

Lancez l'interface web locale avec npx :

npx @deepseek-ai/dsh web
Enter fullscreen mode Exit fullscreen mode

La commande démarre l'interface sur :

http://127.0.0.1:3080
Enter fullscreen mode Exit fullscreen mode

Le navigateur s'ouvre automatiquement. Pour empêcher cette ouverture :

npx @deepseek-ai/dsh web --no-open
Enter fullscreen mode Exit fullscreen mode

Aucune installation globale ni création de compte n'est requise pour démarrer l'interface.

Compiler depuis les sources

Si vous préférez utiliser le dépôt directement :

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web
Enter fullscreen mode Exit fullscreen mode

Configurer la première session

Après le lancement, suivez ce flux :

  1. Ajoutez une clé API DeepSeek dans les paramètres. Les identifiants sont stockés dans : 
   $DSH_HOME/.credentials.yaml
Enter fullscreen mode Exit fullscreen mode

Le fichier de paramètres principal ne contient que des références à ces identifiants.

  1. Sélectionnez un espace de travail.
    Cliquez sur Choose workspace, ajoutez le répertoire du projet, puis sélectionnez-le. Tant qu'aucun espace de travail n'est défini, le composeur de session reste désactivé.

  2. Lancez une tâche et validez les opérations.
    Les écritures de fichiers et les commandes shell qui nécessitent une approbation selon la politique active apparaissent sous forme de demandes de confirmation.

Par exemple, commencez par une tâche limitée :

Analyse la structure du projet, liste les tests existants et propose les commandes à exécuter. Ne modifie aucun fichier.
Enter fullscreen mode Exit fullscreen mode

Ensuite, passez à une modification ciblée :

Ajoute un test unitaire pour le module src/utils/slug.ts. Affiche le diff avant toute écriture.
Enter fullscreen mode Exit fullscreen mode

Utiliser les profils et le mode headless

dsh web est un raccourci pour :

dsh --profile web
Enter fullscreen mode Exit fullscreen mode

Les profils sont stockés sous :

$DSH_HOME/profiles/<name>
Enter fullscreen mode Exit fullscreen mode

Pour l'automatisation, utilisez le mode sans interface :

dsh --profile headless "Analyse les tests en échec et propose un correctif."
Enter fullscreen mode Exit fullscreen mode

Ce mode démarre une session fraîche, affiche le résultat, puis s'arrête. Il est adapté aux scripts et à l'intégration continue.

Commandes utiles :

# Afficher la configuration finale sans démarrer dsh
dsh --dump-config

# Afficher la configuration par défaut
dsh --dump-default-config

# Gérer les plugins d'un profil
dsh plugin
Enter fullscreen mode Exit fullscreen mode

La liste complète des options est disponible dans le README de la CLI.

Quels modèles peut-il exécuter ?

Les modèles DeepSeek sont les modèles par défaut, avec V4-Pro comme paire phare. DeepSeek a rendu sa réduction hors pointe permanente, ce qui peut modifier le coût d'un agent qui consomme des jetons en continu. Consultez l'article sur la réduction de prix permanente de DeepSeek V4-Pro ainsi que la documentation officielle sur api-docs.deepseek.com.

Comme l'adaptateur de modèle est un plugin, vous n'êtes pas limité à DeepSeek.

Deux approches sont disponibles :

  • Fournisseurs de catalogue : Anthropic, OpenAI, Bedrock, Vertex et Azure, avec une gestion des identifiants propre à chaque fournisseur.
  • Fournisseurs personnalisés : tout endpoint compatible OpenAI peut être déclaré dans : 
  $DSH_HOME/settings.yaml
Enter fullscreen mode Exit fullscreen mode

Vous y configurez l'URL de base, la variable d'environnement contenant la clé et la liste des modèles.

Cette seconde approche couvre notamment les modèles locaux, les proxys et les passerelles d'entreprise.

Chaque session enregistre le modèle utilisé à son démarrage. Vous pouvez donc changer le modèle par défaut sans altérer l'historique des sessions déjà créées.

Le guide des fournisseurs documente le format de configuration. Pour les exemples YAML complets des endpoints personnalisés, consultez comment exécuter n'importe quel modèle dans DeepSeek Harness.

L'écosystème de plugins, une semaine après

Les plugins sont référencés via le sujet GitHub dsh-plugin. La communauté se coordonne aussi sur GitHub Discussions et Discord.

Les catégories déjà visibles sont les suivantes :

  • Wrappers de bureau : des projets comme deepseek-harness-desktop avec Tauri et dsh_desktop pour Windows empaquettent l'interface web dans une application native. Ce sont des projets communautaires, pas des livrables officiels DeepSeek. Auditez-les avant de leur confier vos clés API.
  • Plugins de capacités : des dépôts comme dsh-context et dsh-vision-router étendent le contexte ou le routage des sessions. Ils restent du code tiers.
  • Support MCP : dsh ne fournit pas encore de support MCP natif dans son noyau. Le support disponible passe par le plugin communautaire dsh-mcp-manager.

dsh-mcp-manager peut notamment gérer :

  • des serveurs MCP HTTP distants ;
  • des serveurs MCP locaux via stdio ;
  • l'authentification OAuth ou par jeton statique ;
  • des outils enregistrés sous la forme mcp__<name>__* ;
  • des configurations par projet dans le répertoire .dsh de l'espace de travail.

La formulation exacte est importante : dsh ne prend pas encore en charge MCP dans son noyau, mais la communauté a ajouté MCP via un plugin. C'est précisément le type d'extension que l'architecture modulaire est censée permettre.

Intégrer votre flux de travail API

Une armature d'agent effectue des appels vers l'API du modèle, mais elle travaille aussi sur les API présentes dans votre projet.

Si l'agent génère du code backend à partir d'une spécification API obsolète ou incomplète, il risque d'implémenter le mauvais contrat avec beaucoup de confiance. Le correctif est simple : validez l'API avant de demander à l'agent de construire une intégration.

Apidog peut couvrir cette étape :

  1. concevez ou importez votre spécification OpenAPI ;
  2. testez les endpoints réels contre cette spécification ;
  3. lancez des serveurs mock avec des réponses stables et conformes au contrat ;
  4. donnez à l'agent une source de vérité vérifiée.

Cette approche réduit les intégrations inventées à partir de code ancien ou de comportements implicites.

Exposer votre spécification via MCP

L'Apidog MCP Server expose vos spécifications API aux outils d'IA via MCP.

Dans dsh, le flux passe actuellement par le plugin communautaire dsh-mcp-manager :

  1. installez le plugin ;
  2. enregistrez l'Apidog MCP Server ;
  3. autorisez les sessions à interroger la spécification réelle ;
  4. utilisez les outils MCP au lieu de laisser l'agent inférer le contrat depuis le code.

Pour un exemple complet incluant les exécutions de tests via CLI, consultez utiliser Apidog CLI dans DeepSeek Harness.

Si votre contrat API n'est pas encore centralisé, téléchargez Apidog et importez d'abord votre spécification.

Faut-il l'essayer maintenant ou attendre ?

La réponse dépend de votre usage.

Essayez-le maintenant si :

  • Vous voulez lire et comprendre une boucle d'agent réelle.
  • Vous avez besoin de choisir différents modèles selon les tâches ou de connecter des modèles auto-hébergés.
  • Vous développez des outils et souhaitez publier tôt dans un écosystème de plugins récent.
  • Vous utilisez déjà l'API DeepSeek et voulez tester l'expérience d'agent officielle avec V4-Pro.

Attendez si :

  • Vous avez besoin d'un outil de production stable au quotidien.
  • Votre organisation exige des outils validés avec support contractuel.
  • Vous ne pouvez pas absorber les changements de configuration, de plugins ou de comportement entre deux versions.
  • Vous recherchez le niveau de finition d'une armature mature comme Claude Code.

L'approche pragmatique consiste à conserver votre agent actuel pour la production et à tester dsh dans un projet parallèle ou une sandbox. Commencez avec un dépôt non critique, limitez les permissions, inspectez les plugins installés et évaluez son comportement avant de l'adopter plus largement.

Pour une comparaison directe, consultez DeepSeek Harness vs Claude Code.

FAQ

DeepSeek Harness est-il gratuit ?

L'armature est gratuite et open source sous licence MIT.

Le coût vient du modèle utilisé : l'API DeepSeek, ou tout autre fournisseur configuré, facture ses requêtes selon ses propres tarifs. Vous pouvez aussi connecter un modèle hébergé localement et éviter un coût par jeton. Consultez exécuter n'importe quel modèle dans DeepSeek Harness pour la configuration.

dsh fonctionne-t-il uniquement avec les modèles DeepSeek ?

Non. DeepSeek est le choix par défaut, mais l'adaptateur de modèle est un plugin.

Les fournisseurs de catalogue couvrent Anthropic, OpenAI, Bedrock, Vertex et Azure. Vous pouvez également ajouter un endpoint compatible OpenAI dans :

$DSH_HOME/settings.yaml
Enter fullscreen mode Exit fullscreen mode

DeepSeek Harness est-il sûr à exécuter sur ma base de code ?

Sa sécurité dépend de la politique de permissions active et de vos validations.

L'interface impose la sélection d'un espace de travail avant l'exécution d'une session et demande une approbation pour les opérations concernées par la politique configurée. Cependant, dsh reste une préversion, et les plugins communautaires peuvent manipuler des clés API.

Appliquez ces règles :

  • n'installez que des plugins que vous avez inspectés ;
  • testez dans un dépôt non critique ;
  • limitez l'accès au shell et aux fichiers ;
  • vérifiez les diffs avant d'approuver les écritures ;
  • ne confiez pas vos secrets à des wrappers tiers non audités.

En quoi une armature diffère-t-elle d'un modèle ?

Le modèle est le moteur de raisonnement. L'armature permet à ce moteur d'agir.

L'armature gère notamment :

  • les sessions ;
  • les outils ;
  • l'accès aux fichiers ;
  • les commandes shell ;
  • les demandes de permission ;
  • la construction du contexte.

Deux agents peuvent utiliser le même modèle et produire des résultats très différents, car leurs armatures, leurs outils et leurs politiques de permissions ne sont pas les mêmes.

Top comments (0)