Application de bureau DeepSeek Harness : ce que l’installateur met réellement sur votre machine

L’application de bureau DeepSeek Harness est une coque Electron enveloppant la même interface web que celle que vous obtenez avec npx @deepseek-ai/dsh web, et elle est fournie sous forme de trois installateurs spécifiques à chaque plateforme pour un harness qui en est actuellement à la version 0.2.1-rc.2. Cette description peut sembler dédaigneuse, et ce n’est pas voulu. Envelopper une interface fonctionnelle dans un conteneur de bureau ne prend qu’un week-end ; l’envelopper dans un conteneur qui possède son propre répertoire d’exécution, garde vos tâches actives lorsque vous fermez la fenêtre, se met à jour sur un canal sans version stable et préserve vos sessions au fil de chacune de ces opérations, voilà la partie qui prend des mois, et c’est celle qui vaut la peine d’être lue. Si vous souhaitez exécuter DeepSeek-V4.1-Flash via un harness qui vit dans une fenêtre plutôt que dans un terminal, c’est ce build-là, et les questions intéressantes portent toutes sur ce qui se passe autour de la fenêtre.

Deux choses doivent être dites avant d’entrer dans les détails. Premièrement, cet article remplace nos précédentes indications selon lesquelles il n’existait pas d’application de bureau — ces indications étaient correctes lorsqu’elles ont été rédigées en août 2026, et elles sont désormais erronées. Deuxièmement, il s’agit d’un aperçu public, toujours étiqueté comme tel sur le site de DeepSeek, et l’empaquetage présente les aspérités que cette étiquette implique. L’installateur fonctionne. La distribution qui l’entoure est moins étoffée que vous ne le devineriez.

Ce qu'est réellement la version desktop

L’application de bureau est une fine couche Electron dont le rôle est de démarrer un processus Host et de pointer une fenêtre vers celui-ci. La fenêtre ne compose pas sa propre interface de chat : elle charge l’entrée Web empaquetée intégrée à l’application à l’adresse dsh-app://app/, et les boîtes de dialogue de mise à jour que vous verrez proviennent d’une seconde origine intégrée à l’adresse dsh-app://shell/. Un processus Node enfant est lancé en mode RunAsNode d’Electron pour démarrer l’exécuteur de profil partagé, et le shell transmet les requêtes HTTP vers le Host Web authentifié, en supprimant les en-têtes transfer-encoding, connection et keep-alive au passage. Les réponses de bundle de plugin sont marquées no-store, ce qui est un petit détail avec une conséquence visible : modifiez un plugin et le prochain rechargement affichera la modification.

Étant donné que l'URL est dsh-app:// plutôt que localhost, il n'y a pas de port fixe à mémoriser ni de collision de ports à contourner. Par défaut, l'hôte de bureau écoute sur un port attribué par le système d'exploitation. Si vous avez besoin d'un port précis, vous pouvez le définir via une surcharge webserver.config.port, mais la valeur par défaut n'est délibérément pas une constante, et l'hôte se lie à 127.0.0.1. Cela a son importance si vous avez suivi des instructions plus anciennes : le nombre 19387 qui a circulé dans les guides d'installation d'août n'est pas le port de bureau, et le considérer comme tel vous amènera à chercher un service qui n'existe pas.

L'épinglage des versions est plus strict qu'il n'y paraît au premier abord. Electron et @deepseek-ai/dsh portent toujours exactement la même version — pas une plage, pas une version majeure compatible — de sorte qu'une mise à niveau du harnais correspond à une version de bureau, et il n'existe aucune combinaison prise en charge d'un nouveau dsh avec une ancienne fenêtre. Le processus Electron prend un verrou à instance unique pendant toute la durée de vie du processus et possède exclusivement $DSH_HOME/profiles/desktop. Cette exclusivité est réelle : la CLI ne peut pas démarrer ce profil, et un npminstallé dsh ne peut pas le modifier. Ce que les deux installations partagent, c'est l'état qui compte pour vous — sessions, paramètres, identifiants, espaces de travail et stockage, tous sous $DSH_HOME. Ce qu'elles ne partagent pas, ce sont les paquets exécutables, l'activation des plugins, les fichiers de verrouillage ou node_modules, c'est pourquoi installer un plugin dans le profil de bureau n'est pas la même opération que de l'installer dans le profil CLI.

Trois installateurs, un seul canal de mise à jour, aucune version stable

Trois installateurs existent et tous les trois répondent. L'exécutable Windows 64 bits fait 289 385 456 octets et est servi avec un code HTTP 200. L'image disque Apple Silicon fait 264 990 950 octets, également avec un code 200. L'image disque Mac Intel fait 289 480 824 octets, également avec un code 200. Les trois ont été modifiés pour la dernière fois le 17 octobre 2026. Seuls deux d'entre eux sont référencés par des liens depuis la page de téléchargement. La version Intel est en ligne, est accessible, et aucun lien ne pointe vers elle nulle part sur deepseek.com/en/harness/ — si vous êtes sur un Mac Intel et que vous avez suivi la page, vous concluriez raisonnablement qu'il n'y avait pas de version pour vous.

La version Intel est également en retard d'une version. Son flux de mise à jour indique 0.2.1-rc.1 ; les flux Windows et Apple-silicon indiquent tous deux 0.2.1-rc.2. Une release candidate d'écart ne représente pas un grand écart de fonctionnalités, mais c'est un signal réel sur les cibles qui sont compilées en premier et celles qui sont vérifiées en dernier, et c'est exactement le genre de chose que vous voulez savoir avant d'engager vos sessions de travail sur une plateforme.

Les canaux de mise à jour sont là où l’histoire de la distribution perd de sa substance. Les flux sont par cible, sous /dsh-desk/feeds/<target>/ sur le même hôte. Windows x64 résout nightly.yml ; les deux cibles macOS résolvent nightly-mac.yml. Demandez à l’un des trois latest.yml ou latest-mac.yml et vous obtenez un 404 — il n’y a pas de canal stable, pas de canal bêta, et aucun moyen de se retirer de celui qui existe. Les notes de publication de DeepSeek elles-mêmes confirment cet agencement plutôt que de le contredire : chaque version publie un flux nightly, et seules les versions stables publient un flux latest pointant vers les mêmes artefacts. « Nightly » dans ce contexte est un nom de canal plutôt qu’une cadence de build — les flux Windows et Apple-silicon servent tous deux la même build 0.2.1-rc.2, datée du 17 octobre, avec le paquet Windows horodaté à 09:22 UTC et le paquet Apple-silicon à 09:57 UTC. Vous obtenez donc la mécanique de mise à jour automatique, l’interrogation avec gigue, le backoff jusqu’à un plafond d’une heure, et aucun moyen de demander autre chose que ce que le canal d’aperçu contient actuellement.

GitHub fait le même constat sous un autre angle. Le dépôt deepseek-ai/deepseek-harness — 256 559 étoiles et 30 921 forks au moment de sa consultation le 21 octobre 2026 — comptait 31 versions à la même date, toutes signalées comme préversions, et toutes sans aucun fichier binaire joint. Rien sur la page Releases n’est téléchargeable. Si vous voulez un build, vous l’obtenez depuis download.deepseek.com ou via npm, où @deepseek-ai/dsh résout actuellement latest en 0.2.1-rc.2. Le dépôt est une source de vérité pour le changelog et une impasse pour l’artefact, ce qui est suffisamment inhabituel pour mériter d’être dit clairement, car l’instinct, en voyant 31 versions, est de s’attendre à un installateur sur l’une d’elles.

Ce que l'installateur écrit, et ce qu'il refuse de toucher

L'installateur Windows est un paquet NSIS natif, et non un habillage autour d'un MSI, et il se comporte comme tel. Vous disposez de palettes claire, sombre et automatique — sélectionnables au moment de l'installation avec /THEME=light, /THEME=dark ou /THEME=auto —, d'un répertoire de destination modifiable et d'une portée d'installation limitée à l'utilisateur actuel. Les racines de lecteur sont rejetées comme destinations, et une destination non vide n'est acceptée que si elle correspond déjà à une installation enregistrée, autrement dit l'installateur refuse d'écraser un dossier sans rapport. Lors d'une mise à jour, le mode silencieux attend jusqu'à dix secondes que l'application en cours d'exécution se ferme, puis s'arrête avec le code de sortie 2 si elle tourne toujours. Il s'agit d'un échec honnête plutôt que d'une installation corrompue, et cela se manifestera dans tout déploiement scripté qui ne ferme pas d'abord l'application.

Le désinstalleur fixe la limite que la plupart des désinstalleurs fixent mal. Il supprime le répertoire userData d’Electron, le répertoire du produit sous %APPDATA%, ainsi que le cache du programme de mise à jour sous %LOCALAPPDATA%. Il ne touche pas au répertoire personnel du harnais — ~/.dsh, ni à l’endroit où DSH_HOME pointe — qui contient vos sessions, vos paramètres, vos identifiants et vos plugins. Le fait de passer --updated ou /KEEP_APP_DATA conserve également les données Electron. Ainsi, désinstaller et réinstaller est un moyen pris en charge de réparer une fenêtre défaillante sans perdre votre travail, et il s’agit d’une décision de conception délibérée plutôt que d’un accident.

Les runtimes fournis méritent d’être connus, car ils sont volumineux et résident en dehors du répertoire de l’application. Python avec numpy, pandas, python-docx, python-pptx, openpyxl, Pillow, lxml et XlsxWriter, ainsi que Node et pnpm, sont installés sous $DSH_HOME/dsh-runtimes/dsh-primary-runtime — normalement ~/.dsh/... sur les deux plateformes — la première fois qu’un espace de travail déclare en avoir besoin. C’est pourquoi l’empreinte disque après une semaine d’utilisation n’est pas celle après l’installation, et pourquoi une désinstallation qui préserve $DSH_HOME préserve aussi plusieurs centaines de mégaoctets de runtimes.

Les paramètres sont lus une seule fois au démarrage depuis desktop/settings.json dans le répertoire userData d’Electron, ce qui, sous Windows, correspond à %APPDATA%\@deepseek-ai\dsh-desktop\desktop\settings.json et, sous macOS, à ~/Library/Application Support/@deepseek-ai/dsh-desktop/desktop/settings.json. DSH_HOME ne déplace pas ce fichier — un point à signaler, car c’est le seul élément de configuration qui ne suit pas la variable que tout le reste suit. Les paramètres de mise à jour dans ce fichier sont exprimés en millisecondes : intervalMs vaut 600 000 par défaut, et maxBackoffMs vaut 3 600 000 par défaut et doit être au moins égal à intervalMs. Le jitter vaut 0,2 par défaut, est limité à une plage allant de zéro à un et a un minimum d’une seconde, tout en ne dépassant jamais le plafond de backoff. Un délai d’inactivité par connexion de 60 000 millisecondes s’applique au trafic HTTP de mise à jour, bien qu’un téléchargement actif n’ait pas de délai total — une liaison lente ne sera pas interrompue en cours de téléchargement.

Fermer la fenêtre ne ferme pas l'application

Sur les deux plateformes, fermer la fenêtre la masque. Sur macOS, il s’agit de Command-W ; sous Windows, c’est le bouton de fermeture, Alt-F4, ou Fermer depuis la barre des tâches. Windows demande une confirmation avant le premier masquage et écrit un indicateur background-close-confirmed dans le répertoire userData d’Electron afin qu’il ne le demande qu’une fois, et non à chaque fois. Windows conserve également une icône de zone de notification pendant toute l’exécution. macOS ne fournit aucune icône dans la barre des menus, ce qui rend l’état masqué véritablement invisible : l’application fonctionne, des tâches s’exécutent, et rien à l’écran ne l’indique tant que vous ne la rouvrez pas avec dsh://open ou la zone de notification, selon la plateforme.

Ce qui survit au masquage est la partie utile. Les tâches en cours continuent de s’exécuter, et la prochaine fois que la fenêtre est affichée, elle présente le même document avec la même session, les mêmes brouillons et la même position de défilement. Ce comportement diffère de celui d’un onglet de navigateur que l’on ferme et rouvre, et c’est la raison pour laquelle la version de bureau vaut vraiment la peine d’exister si votre travail implique des tâches d’agent de longue durée : vous pouvez fermer la fenêtre et laisser la tâche se terminer.

Quitter est une action distincte, dotée de sa propre logique. Avant de quitter, le shell inspecte l'hôte pour détecter les agents en cours d'exécution, y compris les sous-agents et les agents en attente d'approbation, les messages en file d'attente, les tâches en cours d'exécution ou d'arrêt, ainsi que les rappels planifiés qui sont activés. Si aucun de ces éléments n'est présent, il quitte silencieusement. Si certains le sont, une boîte de dialogue de confirmation native intitulée Quitter DeepSeek Harness ? s'affiche, accompagnée de l'une des trois explications selon ce qu'il a trouvé : les tâches seront interrompues, les tâches planifiées ne s'exécuteront pas, ou les deux. Un hôte qui n'a jamais atteint l'état prêt n'a pas pu démarrer de tâches ; quitter dans cet état se fait donc sans demander. La distinction entre « fermer » et « quitter » est tout l'intérêt de cette conception, et elle vaut sur les deux plateformes, même si une seule d'entre elles vous affiche une icône persistante.

La commande dsh, et l'ordre qui compte

L'installateur peut placer dsh dans votre PATH, ce qui vous permet d'exécuter la CLI sur le même dossier de harness que celui utilisé par l'application de bureau. Le contrôle correspondant est Gérer la commande dsh…, et il se trouve juste en dessous de Rechercher les mises à jour… dans le menu, avec trois actions : Installer, Réparer et Supprimer. Sur macOS, il écrit un lanceur à l'emplacement /usr/local/bin/dsh et demandera une autorisation administrateur lorsque c'est nécessaire ; sous Windows, il enregistre la commande dans le PATH de l'utilisateur actuel.

Deux règles de séquencement sont faciles à oublier et pénibles à découvrir après coup. La première : exécutez Remove avant de désinstaller l’application de bureau, car le désinstalleur ne supprime pas l’enregistrement de dsh. Si vous désinstallez d’abord, il vous reste une entrée PATH qui pointe vers un binaire qui n’existe plus. La seconde : si vous déplacez l’application vers un autre emplacement, utilisez Repair sur macOS ou Install depuis le nouvel emplacement sur Windows, plutôt que de supposer que l’enregistrement suit l’application.

La gestion des plugins pour le profil de bureau présente une subtilité particulière. Comme Electron a l'usage exclusif de $DSH_HOME/profiles/desktop pendant son exécution, l'installation dans ce profil ne se fait pas avec l'application ouverte. La procédure prise en charge consiste à lancer l'application de bureau une fois, à la quitter, puis à exécuter dsh plugin --profile desktop add <package> depuis la ligne de commande. Le paquet est déposé dans le profil de bureau et devient actif la prochaine fois que vous ouvrez la fenêtre.

Ce que l’emballage vous dit déjà est inachevé

La section des limitations connues du README est d'une franchise inhabituelle, et deux de ses entrées sont celles qui vous affecteront en premier.

• La connexion au compte n’est pas connectée. Le bouton Se connecter est désactivé. À la place, le premier lancement ouvre une fenêtre d’accueil de 600 × 700 avec un formulaire de clé API ; Enregistrer et continuer écrit la clé dans le magasin d’identifiants de développement, et Configurer plus tard ouvre l’espace de travail réel sans en enregistrer. Appuyer sur Se connecter là où il apparaît ouvre la page de la plateforme configurée dans le navigateur de votre système, l’hôte prenant en charge l’échange PKCE et un rappel loopback temporaire — la plomberie existe, mais pas la liaison du compte. En pratique, prévoyez de fournir une clé.

• La signature de publication et la notarisation sont indiquées comme nécessitant l’environnement de publication de production. C’est le README qui se veut prudent, et c’est aussi un cas où une mesure est plus utile qu’une phrase. L’exécutable Windows publié porte une signature Authenticode valide avec une chaîne à validation étendue : GlobalSign Root CA–R3, en descendant par GlobalSign Code Signing Root R45 et GlobalSign GCC R45 EV CodeSigning CA 2020, jusqu’à un certificat feuille délivré à Hangzhou DeepSeek Artificial Intelligence Co., Ltd., avec une juridiction indiquée comme CN / Zhejiang / Hangzhou et une catégorie d’entreprise « organisation privée ». L’horodatage RFC-3161 de cette signature indique 2026-10-17T09:22:04Z, ce qui correspond à la date de publication du flux de mise à jour Windows à la minute près, et le condensé SHA-512 du fichier téléchargé correspond octet pour octet au hachage publié dans ce flux. Ainsi, sous Windows, le binaire est aujourd’hui signé, horodaté et son hachage concorde, quoi que dise le README sur le fait que le processus n’est pas entièrement industrialisé. Le côté macOS est une autre question et nous n’y avons pas vérifié la notarisation ; ne pas transposer le résultat Windows.

Rapports de plantage, et un détail à connaître

Les rapports de plantage sont écrits sous la forme crash-<UTC time>-<source>.log, dans ~/Library/Logs/DeepSeek Harness sur macOS ou un logs répertoire sous le chemin userData d’Electron sous Windows, et les dix plus récents sont conservés. Ce nombre de journaux conservés est suffisamment faible pour avoir des conséquences : si quelque chose échoue de manière répétée et que vous ne vérifiez pas pendant quelques jours, le journal qui aurait expliqué la première défaillance aura disparu. Copiez le répertoire si vous déboguez un problème intermittent.

Le chemin de récupération d’une configuration corrompue est tout aussi spécifique. Le shell renomme cordis.patch.yml en cordis.patch.yml.bak-<timestamp> sans l’analyser, de sorte que le fichier est préservé plutôt que réparé, et l’application démarre avec les valeurs par défaut. Si vous avez modifié ce fichier à la main, le .bak est l’endroit où sont allées vos modifications, et il est toujours lisible.

Ce que cela change pour le conseil antérieur « pas d'application de bureau »

Nous avons publié en août 2026 des consignes indiquant que le harness n’avait pas d’application de bureau et que les utilisateurs de Windows devaient exécuter la version terminale — c’était exact à l’époque et c’est désormais obsolète. La version terminale fonctionne toujours et reste le bon choix pour un serveur, un conteneur ou tout ce qui est scripté. Ce qui a changé, c’est que la version bureau n’est pas une simple surcouche : elle dispose de son propre profil, maintient les tâches actives même après la fermeture d’une fenêtre, se met à jour elle-même et partage son état avec le CLI dans le sens qui vous aide. Si vous reportiez la version bureau parce que l’article précédent disait qu’elle n’existait pas, cette raison n’en est plus une.

Les étapes d’installation elles-mêmes sont couvertes dans notre tutoriel d’installation et ne sont volontairement pas répétées ici. Ce que ce tutoriel ne peut pas vous dire, c’est lequel des trois programmes d’installation n’a pas de lien sur la page de téléchargement, quelle cible est en retard d’une version, qu’il n’existe aucun canal de mise à jour stable à rejoindre, et que le binaire Windows est signé même si le README indique que la signature fait partie d’une future version. Ce sont ces faits qui déterminent si la version de bureau est la bonne chose à installer, et c’est la raison pour laquelle cette page existe séparément.

Si vous préférez ne rien installer

Installer un harnais pour accéder à un seul modèle représente beaucoup de surface à gérer pour peu de travail, et l’application de bureau est une preview avec un seul canal de mise à jour et une build Intel vers laquelle personne ne pointe. Si ce que vous voulez vraiment, c’est DeepSeek-V4.1-Flash — le modèle par défaut du harnais, celui dont les notes de la 0.2.1-rc.2 ajoutent la prise en charge —, un endpoint API fait cela sans installateur, sans répertoire de profil et sans icône de barre d’état système dont il faut se rappeler qu’elle tourne.

La comparaison à établir n'oppose pas l'application de bureau à l'API dans l'abstrait. Il s'agit de savoir si le travail exige un agent capable de maintenir un espace de travail ouvert au-delà d'une fenêtre fermée, d'exécuter des scripts sur votre machine et de garder une session active pendant des heures — auquel cas les problèmes d'empaquetage évoqués ci-dessus valent la peine d'être supportés, et la version de bureau est le seul moyen d'obtenir ce comportement — ou si le travail consiste en un flux de requêtes adressées à un modèle déjà servi ailleurs. Dans le second cas, le répertoire de modèles est le chemin le plus court, et rien dans cet article ne change cela.