Comment effectuer une publication progressive des plugins DeepSeek Harness en 2026 ?

01

La fenêtre de publication

Au 19 août 2026, DeepSeek Harness reste présenté comme un aperçu destiné aux développeurs et sa documentation officielle avertit que des changements rompant la compatibilité peuvent survenir. Le dépôt décrit également une architecture où les composants sont des plugins et où Cordis fournit le cadre d’exécution. Une mise à jour d’un plugin ne doit donc pas être traitée comme une simple correction isolée : elle peut modifier le chargement, l’enregistrement des outils, les contrats de configuration ou la relation entre Host et Client. Le dépôt officiel de DeepSeek Harness confirme ces limites de maturité et cette architecture.

Le cycle recommandé peut être organisé ainsi :

Étape	Surface concernée	Condition d’entrée	Preuve de réussite	Action en cas d’échec
Préparation	Version et dépendances	Combinaison actuelle identifiée	Inventaire restaurable	Bloquer l’actualisation automatique
Validation isolée	Environnement séparé	Configuration non sensible copiée	Harness démarre selon la même logique	Détruire et recréer l’environnement
Chargement	Host, Client, configuration	Installation candidate terminée	Plugins découverts et configuration lue	Revenir à la combinaison précédente
Tâche minimale	Outils et permissions	Chargement validé	Lecture seule et écriture réversible réussies	Retirer la candidate du circuit
Persistance	Session et processus	Tâches minimales validées	Reprise et redémarrage vérifiés séparément	Restaurer l’ensemble du profil
Déploiement	Environnements partagés	Fenêtre d’observation définie	Aucun écart bloquant sur le lot	Retour arrière global

La publication progressive n’est donc pas une attente passive. Chaque phase possède une condition d’entrée, une preuve observable et une action de sortie.

02

L’inventaire de la combinaison actuelle

Une liste contenant uniquement les noms des plugins ne permet pas de restaurer un environnement fiable. Dans DeepSeek Harness, la version du Harness, les paquets installés, les dépendances transitives, la configuration Cordis, les variables d’environnement et le mode de lancement peuvent tous influencer le résultat.

Avant toute mise à jour, l’équipe doit conserver au minimum :

• la version exacte de DeepSeek Harness ;
• la source de chaque plugin : registre, archive, dépôt ou construction locale ;
• le fichier de verrouillage et les sommes de contrôle disponibles ;
• les versions des dépendances résolues ;
• les chemins d’installation et le répertoire de travail ;
• les profils actifs et les points d’entrée de configuration ;
• la liste des outils réellement exposés à l’agent ;
• un scénario de référence pouvant être exécuté sans donnée client ;
• la sortie complète du démarrage, y compris les avertissements ;
• le mode de lancement utilisé sur le Mac local ou le Mac distant.

Le dépôt officiel indique notamment que l’installation depuis les sources passe par pnpm install, que la version de pnpm est verrouillée dans le projet et que le contrôle de type constitue une étape de vérification du dépôt. Ces éléments illustrent pourquoi un simple numéro de plugin ne suffit pas à décrire un environnement reproductible. Le guide officiel de développement doit être consulté avant de déduire une procédure à partir d’un nom de paquet. (github.com)

Un inventaire peut être produit dans un fichier réservé à l’exploitation :

mkdir -p release-records/current
node --version > release-records/current/runtime.txt
pnpm --version >> release-records/current/runtime.txt
git rev-parse HEAD > release-records/current/harness-commit.txt
pnpm list --depth Infinity > release-records/current/dependencies.txt
cp pnpm-lock.yaml release-records/current/

La sortie attendue n’est pas une valeur particulière, mais un ensemble de fichiers conservés avec la configuration candidate. Si l’environnement utilise une installation empaquetée plutôt qu’un dépôt source, l’équipe doit remplacer ces commandes par les commandes d’inspection réellement disponibles, sans inventer un fichier de verrouillage qui n’existe pas.

Il faut également arrêter les mises à jour automatiques qui ne disposent d’aucun chemin de restauration. Un mécanisme automatique peut rester actif dans un environnement de développement isolé, mais il ne doit pas modifier le seul profil utilisé par des agents partagés ou des tâches longues.

03

La surface de validation séparée

L’environnement de validation doit reproduire la logique de l’environnement officiel, mais pas ses secrets ni ses effets irréversibles. Il peut s’agir d’un espace de travail distinct, d’un profil isolé ou d’un second Mac distant. L’important est de conserver les mêmes chemins d’installation, le même mode de lancement et la même chaîne de résolution de configuration.

Il ne faut pas copier :

• les clés d’accès réelles ;
• les identifiants de clients ;
• les répertoires contenant des données sensibles ;
• les tâches qui déclenchent une suppression ou une publication ;
• les files d’attente dont la reprise pourrait doubler une opération ;
• les jetons d’authentification conservés dans des fichiers locaux.

Il faut copier uniquement ce qui permet de vérifier le contrat technique : structure de configuration, plugins nécessaires, paramètres non sensibles, faux jeux de données et scripts de démarrage. Le guide utilisateur officiel précise que le processus dsh utilise le répertoire d’appel comme emplacement de fichiers par défaut et qu’un nouvel espace Web doit sélectionner un espace de travail avant l’exécution d’une tâche. Cette dépendance au répertoire de lancement doit être reproduite dans la validation, faute de quoi un test réussi peut être trompeur. Le guide officiel de l’interface Web décrit ce comportement. (github.com)

Si aucun second environnement ne peut être conservé en parallèle, la mise à jour doit être reportée. Mettre à niveau l’unique exécuteur revient à supprimer le point de comparaison avant même d’avoir obtenu une preuve de compatibilité.

Sur un Mac distant, le contrôle initial peut rester simple :

printf '%s\n' "$PWD"
node --version
pnpm --version
ls -la

Le résultat doit être comparé à celui de l’environnement officiel, notamment pour le répertoire d’appel, les droits d’accès et le binaire réellement utilisé. Les versions minimales documentées pour le développement actuel comprennent Node.js 22.19 ou une version 24, avec une chaîne pnpm gérée par Corepack. Ces valeurs concernent le dépôt de développement ; elles ne doivent pas être transformées automatiquement en exigence pour chaque plugin tiers. (github.com)

04

Les contrôles par profondeur

Chargement et contrat de configuration

La première passe ne doit exécuter aucune opération d’écriture. Elle vérifie seulement que le candidat est découvrable, que la configuration est lisible et que Host et Client démarrent ensemble.

Les contrôles à consigner sont :

• nom et version effectivement chargés ;
• chemin de chaque module résolu ;
• avertissements de configuration ;
• absence de conflit entre plugins ;
• démarrage complet du Host ;
• initialisation du Client ;
• création d’une session vide ;
• fermeture propre du processus.

Le nom d’un plugin ne constitue pas une preuve de compatibilité. Pour chaque changement, l’auteur ou le mainteneur doit comparer le code source du plugin avec la version actuelle de Harness, le fichier de version et la documentation officielle. La fonctionnalité de carte de paramètres introduite dans v0.1.0-rc.7, publiée comme préversion le 17 août 2026, montre précisément pourquoi une nouveauté d’interface ne doit pas être interprétée comme une garantie générale pour les plugins tiers. Les notes officielles de v0.1.0-rc.7 indiquent que les plugins peuvent enregistrer leurs propres cartes de paramètres, sans déclarer pour autant une compatibilité universelle. (github.com)

La commande ou le script de démarrage doit enregistrer l’erreur réelle, et non un résumé manuel :

pnpm dsh web 2>&1 | tee release-records/candidate-startup.log

Dans une installation différente, la commande doit être adaptée à l’entrée officiellement utilisée. Il est préférable de conserver une erreur explicite « configuration inconnue » que de contourner le contrôle en ajoutant une clé supposée.

Tâches minimales et permissions

Après validation du chargement, la deuxième passe vérifie deux tâches volontairement limitées :

• une tâche en lecture seule, par exemple l’analyse de la structure d’un projet de démonstration ;
• une écriture réversible, par exemple la création d’un fichier temporaire dans un espace de travail jetable.

L’objectif n’est pas de mesurer la qualité générale de l’agent, mais de vérifier que la mise à jour n’a pas modifié silencieusement la surface d’action. L’équipe doit comparer avant et après :

• la liste des outils enregistrés ;
• les paramètres exposés à l’agent ;
• les demandes d’approbation ;
• les chemins accessibles ;
• les commandes bloquées ;
• la forme des résultats renvoyés ;
• les journaux produits.

Une permission supplémentaire doit être traitée comme une modification indépendante, même si elle accompagne une correction sans rapport. Un plugin qui passe d’un accès en lecture à une capacité d’écriture ne doit pas être accepté uniquement parce que la tâche de référence réussit.

Le contrôle peut produire une comparaison lisible :

Avant : lecture du workspace, recherche de fichiers, sortie texte
Après : lecture du workspace, recherche de fichiers, sortie texte, écriture fichier
Décision : blocage — permission supplémentaire à approuver

Pour les auteurs de dsh-plugin, cette phase est également celle où il faut vérifier que les contrats publics exposés par le Host et le Client correspondent aux versions réellement compilées. La documentation d’architecture décrit des agrégats Host et Client distincts, ce qui impose de vérifier les deux faces lorsqu’un plugin touche à la fois au processus serveur et à l’interface. La documentation officielle d’architecture détaille cette séparation. (github.com)

Sessions, reprise et redémarrage

La troisième passe porte sur la continuité. Elle doit distinguer trois événements souvent confondus :

• le service démarre à nouveau ;
• une nouvelle session peut être ouverte ;
• une tâche existante peut réellement reprendre son exécution.

Le premier événement ne prouve pas le troisième. Pour le vérifier, l’équipe doit créer une session de test, interrompre le processus à un point contrôlé, redémarrer le service, puis demander explicitement la reprise. Le journal doit montrer que le contexte, les outils disponibles, les permissions et l’état de la tâche correspondent à la situation antérieure.

Un scénario de validation peut suivre cette séquence :

1. Ouvrir une session de test.
2. Exécuter une tâche de lecture.
3. Créer un artefact temporaire réversible.
4. Arrêter le processus.
5. Redémarrer avec la même combinaison.
6. Vérifier l’état de la session.
7. Reprendre ou déclarer proprement la tâche interrompue.

Une longue tâche ne doit entrer dans cette phase qu’après réussite des tests de chargement, de tâche minimale et de permissions. Les tâches audio, vidéo ou de design peuvent servir de bons cas de validation lorsque le plugin manipule des fichiers volumineux, des aperçus ou des outils externes, mais elles doivent rester limitées à des artefacts jetables tant que le retour arrière n’est pas prouvé.

La vérification doit couvrir aussi la persistance de la configuration. Une carte de paramètres qui s’affiche après redémarrage, mais qui perd une valeur non sensible ou réactive un outil par défaut, constitue un échec de régression, même si l’interface semble fonctionnelle.

05

Le basculement par lots

Une fois la candidate validée, le déploiement commence par la tâche présentant le moins de conséquences en cas d’arrêt. Il peut s’agir d’un agent d’analyse, d’un espace de développement ou d’un flux de génération d’aperçus. Les tâches client, les agents persistants et les opérations externes doivent rester sur l’ancienne combinaison jusqu’à la fin de la fenêtre d’observation.

La progression recommandée est la suivante :

• affecter la candidate à un profil non critique ;
• vérifier le démarrage et le scénario de référence ;
• observer les journaux et les demandes d’approbation ;
• ouvrir un second lot uniquement si aucun écart bloquant n’apparaît ;
• conserver l’ancien profil jusqu’à la confirmation du dernier lot ;
• consigner le responsable de version et la condition de prochaine revue.

Sur un Mac distant, le basculement peut être réalisé en conservant deux répertoires ou deux profils clairement nommés, par exemple release-current et release-candidate. Le choix doit être explicite dans le script de lancement, au lieu de dépendre d’un lien symbolique modifié sans journal :

PROFILE="${DSH_PROFILE:-release-current}"
exec ./bin/dsh --profile "$PROFILE" web

Le nom exact de l’option doit toutefois provenir de la version et du mode d’installation utilisés. Cet exemple décrit une stratégie de sélection, pas une clé de configuration garantie par DeepSeek Harness.

Le point essentiel est le retour arrière global. Si Harness, un plugin et une dépendance ont changé ensemble, il faut restaurer l’ensemble de la combinaison validée. Rétrograder seulement le plugin peut créer un mélange inédit entre une nouvelle API Host, une ancienne implémentation et une configuration intermédiaire. Ce mélange est souvent plus difficile à diagnostiquer que l’échec initial.

La méthode complète doit être vérifiable à l’aide de cette liste :

• [ ] La version de Harness et le commit ou paquet exact sont archivés.
• [ ] Chaque plugin possède une source et une version identifiables.
• [ ] Le fichier de verrouillage et les dépendances résolues sont conservés.
• [ ] Les chemins d’installation et le répertoire de lancement sont documentés.
• [ ] Les secrets réels sont exclus de l’environnement de validation.
• [ ] Une tâche en lecture seule est passée sans effet externe.
• [ ] Une écriture réversible est passée avec approbation attendue.
• [ ] La liste des outils avant et après a été comparée.
• [ ] Les permissions supplémentaires ont été approuvées séparément.
• [ ] Une nouvelle session fonctionne après redémarrage.
• [ ] Une tâche interrompue a été testée séparément pour la reprise.
• [ ] L’ancien profil peut être restauré sans reconstruire les dépendances.
• [ ] Le responsable du lot et la condition de retour arrière sont écrits.

06

Les options d’environnement

Option	Avantage	Limite opérationnelle	Choix recommandé
Mac unique	Coût et administration réduits	Aucun point de comparaison pendant l’actualisation	Développement non critique
Deux profils sur un même Mac	Comparaison rapide des combinaisons	Les ressources, processus et permissions restent partagés	Validation courte et contrôlée
Deux Mac séparés	Isolation claire des sessions et des dépendances	Préparation et supervision supplémentaires	Plugins expérimentaux ou agents persistants
Mac distant temporaire	Création rapide d’une surface de test sans modifier l’exécuteur principal	Il faut gérer les accès, les fichiers et la durée de conservation	Publication progressive et validation ponctuelle

Un Mac unique peut convenir à un projet personnel peu concurrent, mais il devient un mauvais choix dès qu’il héberge simultanément des plugins expérimentaux, des tâches persistantes et des données dont la reprise doit être garantie. Pour comparer une architecture Mac stable et de validation en double voie, l’équipe doit surtout vérifier la séparation des espaces, des identifiants et des profils de lancement, plutôt que de comparer uniquement la puissance matérielle.

Lorsque la validation doit être isolée rapidement, un Mac distant temporaire pour les essais de Harness peut servir de seconde surface d’exécution. Cette option n’est pas adaptée à une charge longue et constante qui exige un contrôle physique des périphériques, mais elle évite de transformer l’environnement partagé en banc d’essai.

La combinaison actuelle, elle, doit être restaurée si un des contrôles suivants échoue : plugin non découvert, configuration partiellement ignorée, outil ajouté sans approbation, session qui démarre mais ne reprend pas, ou dépendance différente de celle enregistrée.

07

Quand remplacer l’environnement actuel

L’environnement actuel est souvent un Mac local ou un Mac distant déjà configuré, avec des dépendances accumulées, une procédure de démarrage implicite et parfois plusieurs utilisateurs qui partagent le même espace. Ses principaux défauts sont l’absence de seconde voie, la difficulté à reproduire exactement la combinaison installée, le risque d’interrompre une tâche persistante et la tentation de corriger directement la production lorsqu’un plugin échoue.

Une location NodeMini apporte une séparation plus nette pour une validation temporaire : un environnement peut être réservé à la candidate, tandis que l’ancien reste disponible pour les sessions qui ne peuvent pas être arrêtées. La recommandation reste conditionnelle : pour une charge stable et lourde sur le long terme, un Mac détenu et administré directement peut être plus cohérent ; pour une validation courte, un test de compatibilité ou une rotation contrôlée, disposer d’un Mac distant séparé réduit le risque de modifier l’unique exécuteur.

La décision raisonnable consiste donc à conserver une combinaison immédiatement restaurable, puis à utiliser une seconde surface seulement lorsque la publication progressive des plugins DeepSeek Harness l’exige. Pour démarrer cette validation sans déplacer les tâches existantes, consultez les environnements Mac distants proposés par NodeMini.