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. C'est la couche logicielle qui transforme un grand modèle linguistique en un agent de codage fonctionnel, avec une boucle de session, l'exécution d'outils, des vérifications de permissions et une interface utilisateur web locale. Il a été lancé le même jour que DeepSeek V4-Pro sur l'API, et VentureBeat l'a présenté comme un rival open source de Claude Code.

La communauté des développeurs a réagi rapidement. Au 20 août, le répertoire deepseek-harness compte environ 169 000 étoiles et 18 100 forks, une semaine après sa sortie. Des chiffres de cette taille en sept jours en disent moins sur le code et plus sur l'appétit : les développeurs veulent une armature d'agent qu'ils peuvent inspecter, modifier et pointer vers n'importe quel modèle.

Ce qu'est réellement DeepSeek Harness

Une armature est tout ce qui entoure le modèle. Le modèle prédit des jetons. L'armature décide ce que le modèle voit, quels outils il peut appeler, comment les modifications de fichiers et les commandes shell sont approuvées, et comment une session multi-étapes est maintenue. Claude Code, Codex CLI et Gemini CLI sont tous des armatures enveloppant les modèles de leurs fournisseurs. Si vous souhaitez en savoir plus sur la comparaison entre ces deux-là, nous l'avons abordé dans Claude Code vs Codex CLI.

DeepSeek Harness est l'entrée de DeepSeek dans cette catégorie, avec trois propriétés qui définissent le cadre :

• C'est officiel. Il s'agit d'un projet de première partie de DeepSeek AI, et non d'un wrapper communautaire autour de leur API.
• C'est open source. Sous licence MIT, avec les dépendances tierces documentées dans le fichier THIRD_PARTY_NOTICES du dépôt. Vous pouvez lire la boucle de l'agent à laquelle vous confiez votre codebase.
• C'est une version préliminaire pour les développeurs. Le README avertit, textuellement : "IL Y AURA DES CHANGEMENTS BRISANT LA COMPATIBILITÉ." Prenez cela au pied de la lettre. Plus d'informations sur ce que cela signifie en pratique ci-dessous.

Le moment du lancement est également important. dsh est arrivé en même temps que DeepSeek V4-Pro sur l'API, de sorte que l'armature et son modèle phare par défaut ont atterri en couple. Si vous évaluez le côté modèle, notre guide sur l'API DeepSeek V4-Pro couvre les points d'accès, les ID de modèle et des exemples de requêtes.

L'architecture : tout est un plugin

C'est là que dsh diffère de tous les agents de codage courants. La plupart des armatures sont monolithiques. La boucle de l'agent, le client du modèle, les définitions des outils et le magasin de session sont livrés comme une seule application. Vous pouvez les configurer, parfois les étendre, mais vous ne pouvez pas échanger les parties centrales.

dsh inverse cela. Son principe de conception est "tout est un plugin", construit sur un framework appelé Cordis, dont la conception est décrite dans un article intitulé "A Programming Paradigm for Spatiotemporal Composability". Si l'on retire le titre académique, l'affirmation pratique est la suivante : les pièces d'un agent qui sont habituellement soudées ensemble sont, dans dsh, des modules remplaçables. Cela inclut :

• L'adaptateur de modèle. La couche qui communique avec l'API LLM est un plugin. Échangez-le et dsh pilotera un backend différent.
• Le registre d'outils. L'ensemble des outils que l'agent peut appeler (modifications de fichiers, shell, recherche) est enregistré par des plugins, non codé en dur.
• Le journal de session. La manière dont les sessions sont enregistrées et rejouées est modulable.
• La boucle de l'agent elle-même. Même le cycle central décider-agir-observer est un plugin que vous pouvez remplacer.

Pourquoi est-ce important ? Parce que la couche de l'armature est l'endroit où la véritable expérimentation a lieu en 2026. Les équipes veulent essayer différentes stratégies de gestion de contexte, différents modèles de permission, différents ensembles d'outils pour différents dépôts. Avec un agent monolithique, vous attendez que le fournisseur livre votre idée. Avec dsh, vous écrivez un plugin.

Le compromis est tout aussi réel. Un système où tout est interchangeable présente une plus grande surface de rupture, et une version préliminaire pour les développeurs qui promet des changements brisant la compatibilité cassera les plugins en cours de route. C'est le pari que dsh vous demande de faire : la flexibilité maintenant, la stabilité plus tard.

Démarrage rapide : de zéro à un agent en fonctionnement

Le chemin d'installation est une seule commande :

npx @deepseek-ai/dsh web

Cela lance une interface utilisateur web locale à l'adresse http://127.0.0.1:3080 et ouvre votre navigateur dessus (passez --no-open si vous préférez que cela ne se fasse pas). Pas d'installation globale, pas de création de compte comme barrière.

Si vous préférez compiler à partir des sources, le chemin du dépôt fonctionne aussi : clonez le dépôt, puis pnpm install, pnpm run build, et pnpm dsh web.

De là, le flux de première exécution comporte trois étapes :

1. Configurez une clé API DeepSeek dans les paramètres. Les clés résident dans $DSH_HOME/.credentials.yaml, séparées du fichier de paramètres principal, qui ne contient que des références à celles-ci.
2. Choisissez un espace de travail. Cliquez sur "Choose workspace", ajoutez le répertoire du projet où vous avez démarré dsh, et sélectionnez-le. Cette étape n'est pas facultative : le composeur de session reste indisponible tant qu'un espace de travail n'est pas sélectionné. dsh veut une réponse explicite à la question "quels fichiers suis-je autorisé à considérer" avant d'exécuter quoi que ce soit.
3. Exécutez une tâche et approuvez les opérations. L'interface utilisateur web demande avant les opérations "qui nécessitent une approbation selon la politique de permissions active". Les écritures de fichiers et les commandes shell apparaissent comme des invites plutôt que de s'exécuter silencieusement.

L'interface utilisateur web n'est qu'un point d'entrée. Sous le capot, dsh démarre des profils : dsh web est un raccourci pour dsh --profile web, et les profils vivent sous $DSH_HOME/profiles/<name>. Il existe un mode sans tête (dsh --profile headless "job") qui exécute une seule session fraîche, imprime le résultat et quitte, ce qui est la forme que vous souhaitez pour les scripts et l'intégration continue. Une sous-commande dsh plugin gère les plugins d'un profil en les transmettant à pnpm dans le répertoire du profil, et des drapeaux de lancement comme --dump-config et --dump-default-config impriment l'arborescence de configuration composée sans démarrer. La liste complète se trouve dans le README de la CLI.

Quels modèles peut-il exécuter ?

Les modèles DeepSeek sont les par défaut, et V4-Pro est la paire phare. Bon à savoir côté coût : DeepSeek a rendu sa réduction hors pointe permanente, ce qui modifie l'économie de l'exécution d'un agent qui consomme des jetons toute la journée. Les détails se trouvent dans notre article sur la réduction de prix permanente de DeepSeek V4-Pro, et la référence officielle se trouve sur api-docs.deepseek.com.

Mais l'adaptateur de modèle est un plugin, et dsh s'appuie là-dessus. Deux chemins existent au-delà du défaut :

• Fournisseurs de catalogue. Entrées de fournisseurs intégrées pour Anthropic, OpenAI, Bedrock, Vertex et Azure, chacune avec une gestion des identifiants spécifique au fournisseur.
• Fournisseurs personnalisés. Tout point de terminaison compatible OpenAI peut être enregistré dans $DSH_HOME/settings.yaml avec une URL de base, une variable d'environnement pour la clé et une liste de modèles. Cela couvre les runtimes locaux et les passerelles, pas seulement les API cloud.

La sélection d'un modèle en fait le défaut pour les nouvelles sessions, et chaque session enregistre le modèle avec lequel elle a démarré, de sorte que le changement en cours de projet n'entache pas votre historique. Le guide des fournisseurs documente le format de configuration. Nous gardons cette section courte à dessein : la procédure complète, y compris le YAML exact pour les points de terminaison personnalisés, se trouve dans comment exécuter n'importe quel modèle dans DeepSeek Harness.

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

Les plugins sont découverts via le sujet GitHub dsh-plugin, et la communauté se coordonne via GitHub Discussions et un serveur Discord. Une semaine après le lancement, l'écosystème montre déjà la forme de la demande :

• Wrappers de bureau. Des projets comme deepseek-harness-desktop (Tauri) et dsh_desktop (Windows) empaquettent l'interface utilisateur web en tant qu'application native. Ce sont des projets communautaires, pas des versions officielles de DeepSeek, alors appliquez le même examen minutieux que vous appliqueriez à tout wrapper tiers qui touche vos clés API.
• Plugins de capacités. Des dépôts communautaires comme dsh-context et dsh-vision-router étendent ce que les sessions peuvent voir et router. Même mise en garde : construits par la communauté.
• Support MCP. dsh ne livre pas de support natif du protocole MCP (Model Context Protocol) dans le noyau à ce jour. Ce qui existe est un plugin communautaire, dsh-mcp-manager, qui ajoute une page de paramètres pour MCP : serveurs HTTP distants ou stdio locaux, authentification OAuth ou par jeton statique, outils enregistrés sous les noms mcp__<name>__*, et des configurations de serveur par projet dans le répertoire .dsh de l'espace de travail.

Ce dernier point mérite d'être souligné car il est facile de se tromper. Si vous lisez un article affirmant que dsh "prend en charge le MCP", la version précise est la suivante : la communauté a intégré le support du MCP sous forme de plugin, ce qui est exactement la raison d'être de l'architecture "tout est un plugin". Le noyau pourrait l'absorber plus tard. Ce n'est pas encore le cas.

Où votre flux de travail API s'intègre

Une armature d'agent est, au fond, une machine pour exécuter des appels API : l'API de modèle qu'elle pilote, et les API au sein de tout projet vers lequel vous la pointez. Lorsque dsh écrit du code pour votre backend, il travaille à partir de toute compréhension de vos points d'accès qu'il peut extraire de la base de code. Si le comportement réel de votre API ne correspond pas à sa spécification, l'agent code en toute confiance contre le mauvais contrat, et vous le découvrez à l'exécution.

La solution est ennuyeuse et efficace : vérifiez la surface de l'API avant que l'agent ne la touche. Apidog couvre cette couche. Concevez ou importez la spécification OpenAPI, testez les points de terminaison réels par rapport à celle-ci, et lancez des serveurs de maquette afin que l'agent puisse développer avec des réponses stables et conformes à la spécification, même lorsque le backend évolue. Un agent itérant avec une maquette vérifiée produit beaucoup moins d'intégrations hallucinées qu'un agent devinant à partir de code obsolète.

Il existe également un chemin d'intégration direct. Apidog MCP Server expose vos spécifications d'API aux outils d'IA via MCP. Dans dsh, cela passe par le plugin communautaire dsh-mcp-manager décrit ci-dessus : installez le plugin, enregistrez l'Apidog MCP Server, et les sessions pourront interroger votre spécification réelle au lieu de l'inférer. Nous décrivons l'intégralité du processus, y compris les exécutions de tests basées sur la CLI que l'agent peut déclencher lui-même, dans utiliser Apidog CLI dans DeepSeek Harness. Si vous voulez que la partie API soit prête avant d'expérimenter, téléchargez Apidog et importez d'abord votre spécification. C'est une configuration de cinq minutes qui élimine la plus grande source d'erreurs d'agent.

Faut-il l'essayer maintenant ou attendre ?

La réponse honnête dépend de l'usage que vous en feriez.

Essayez-le maintenant si :

• Vous voulez comprendre comment fonctionnent les armatures d'agents en interne. dsh est l'armature majeure la plus inspectable disponible, et la lecture d'une vraie boucle d'agent en apprend plus que n'importe quel article de blog.
• Vous avez besoin de flexibilité de modèle. Si votre équipe utilise différents modèles pour différentes tâches, ou les héberge elle-même, l'adaptateur de modèle enfichable est la fonctionnalité que les agents monolithiques ne vous offriront pas.
• Vous développez des outils. L'écosystème de plugins a une semaine. Les premiers auteurs de plugins dans un dépôt avec autant d'attention obtiennent une visibilité démesurée.
• Vous utilisez déjà l'API de DeepSeek et souhaitez l'expérience d'agent de première partie pour V4-Pro.

Attendez si :

• Vous avez besoin d'un pilote quotidien stable. "IL Y AURA DES CHANGEMENTS BRISANT LA COMPATIBILITÉ" n'est pas une modestie marketing, c'est une promesse. Votre configuration, vos plugins et votre mémoire musculaire peuvent tous être cassés entre les versions.
• Votre organisation exige des outils validés et pris en charge. Une version préliminaire pour les développeurs avec des plugins communautaires gérant les identifiants présente un profil de risque différent d'un produit en disponibilité générale avec un contrat de support.
• Vous voulez le raffinement des armatures matures. Claude Code a eu une longue avance en matière d'ergonomie, et une version préliminaire d'une semaine ne l'égalera pas encore partout.

Pour la plupart des développeurs en activité, la démarche pragmatique est double : gardez votre agent actuel pour le travail de production, exécutez dsh dans un projet parallèle, et forgez votre propre opinion avant que l'étiquette de prévisualisation ne soit retirée. Si votre question principale est de savoir comment il se compare à l'actuel, nous avons fait la comparaison côte à côte dans DeepSeek Harness vs Claude Code.

FAQ

DeepSeek Harness est-il gratuit ?

L'armature elle-même est gratuite et open source sous licence MIT. Ce qui coûte de l'argent est le modèle derrière elle : l'utilisation de l'API sur la plateforme de DeepSeek (ou de tout autre fournisseur que vous configurez) est facturée normalement par ce fournisseur. Comme la couche d'adaptateur est enfichable, vous pouvez également pointer dsh vers un modèle hébergé localement et ne rien payer par jeton ; voir exécuter n'importe quel modèle dans DeepSeek Harness pour la configuration.

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

Non. Les modèles DeepSeek sont les par défaut, mais l'adaptateur de modèle est un plugin. Les fournisseurs de catalogue couvrent Anthropic, OpenAI, Bedrock, Vertex et Azure, et tout point de terminaison compatible OpenAI peut être ajouté via $DSH_HOME/settings.yaml.

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

C'est aussi sûr que son modèle de permission plus votre jugement. L'interface utilisateur web vous demande de sélectionner un espace de travail avant qu'une session ne puisse s'exécuter, et elle vous invite avant les opérations qui nécessitent une approbation sous la politique de permission active. Cela dit, il s'agit d'une version préliminaire pour les développeurs, et les plugins communautaires (y compris les wrappers de bureau) sont du code tiers qui peut gérer vos clés API. Examinez ce que vous installez, et tenez la version préliminaire éloignée des dépôts où une modification erronée causerait des dommages.

En quoi une "armature" est-elle différente d'un modèle ?

Le modèle est le moteur de raisonnement ; l'armature est tout ce qui lui permet d'agir. La gestion de session, les appels d'outils, l'accès aux fichiers, les invites de permission et l'assemblage de contexte résident tous dans l'armature. Deux agents utilisant le même modèle peuvent se comporter de manière complètement différente parce que leurs armatures diffèrent, c'est pourquoi la couche d'armature est l'endroit où se déroule la majeure partie de la concurrence des agents de codage actuellement.