Le projet apparaît bien sur le Mac cloud, mais l’agent ne retrouve ni son Provider, ni ses plugins, ni le contexte de la session.
La solution la plus sûre consiste à éviter la copie intégrale du dossier : créez un environnement cible réversible, séparez les actifs, réinjectez les secrets, puis validez chaque fonction avec une nouvelle session avant de basculer les tâches continues.
[ SECTION_01 ] À qui s’adresse cette méthode ?
Cette procédure concerne les utilisateurs qui transforment un essai local en tâche d’agent exécutée en continu, les personnes chargées de l’exploitation d’un environnement DeepSeek Harness et les responsables qui doivent décider quelles données conserver ou régénérer.
La migration de DeepSeek Harness vers un Mac cloud n’est donc pas un simple transfert de fichiers. Elle doit être traitée comme une opération de changement d’environnement, avec inventaire, contrôle des permissions, preuve de fonctionnement et condition de retour arrière.
Point de vigilance : la documentation officielle classe encore DeepSeek Harness en developer preview et prévient explicitement que des changements incompatibles peuvent survenir. Les journaux et configurations doivent donc être conservés, mais aucune reprise interversion ne doit être présumée.
Dernière mise à jour : 18 août 2026. Les comportements mentionnés ont été vérifiés à partir du dépôt officiel et de son README, du guide de l’interface Web, du guide de développement et de la documentation d’architecture.
[ SECTION_02 ] Pourquoi la copie intégrale crée-t-elle un état difficile à récupérer ?
Une archive complète paraît rassurante. Elle peut pourtant mélanger des chemins absolus, des identifiants persistants, des dépendances binaires, des références d’environnement et des journaux écrits par une version différente.
Le symptôme le plus trompeur est le suivant : les fichiers du projet sont visibles, mais l’agent travaille dans le mauvais répertoire, le modèle refuse la requête ou le plugin échoue au démarrage. Trois coûts cachés apparaissent alors :
- Perte de contexte opérationnel : les journaux de session existent, mais leur format ou leurs références ne correspondent plus à la version active.
- Risque de fuite : une archive peut contenir une clé API, un fichier
.env, un historique de terminal ou des traces de requêtes. - Dépendances invisibles : un plugin peut dépendre d’une version précise de Node.js, de
pnpm, d’un outil système ou d’une variable non documentée. - Erreur de périmètre : l’agent peut voir un autre dépôt que celui attendu, surtout si le chemin local diffère du chemin distant.
- Retour arrière incertain : si l’environnement source est modifié avant validation, il devient difficile de distinguer un problème de migration d’un problème de configuration initiale.
La bonne décision consiste à classer chaque actif avant de le déplacer.
| Actif à inventorier | Action recommandée | Critère de conservation |
|---|---|---|
| Code, fichiers de projet, branches Git | Copier ou cloner proprement | Le dépôt, la branche et les changements non commités sont identifiés |
| Configuration Harness | Documenter puis recopier sélectivement | Les chemins, identifiants et références d’environnement sont compris |
| Clés API et secrets | Réinjecter sur la cible | Aucune valeur en clair ne figure dans l’archive |
| Plugins et dépendances | Recréer avec les versions contrôlées | La combinaison d’exécution est reproductible |
| Journaux de session | Conserver une copie originale | Leur lecture ou leur reprise est testée séparément |
| Cache et fichiers temporaires | Généralement abandonner | Aucun état métier ou historique indispensable n’y est stocké |
Cette séparation est plus fiable qu’un déplacement aveugle de DSH_HOME. La variable doit être relevée dans l’environnement source et vérifiée sur la cible, mais son contenu ne doit pas être traité comme un bloc homogène.
[ SECTION_03 ] Première étape : figer la source avant toute opération
Avant de louer ou de préparer le Mac cloud, la personne responsable doit créer une photographie de l’environnement local. Elle doit noter la version de DeepSeek Harness, la version de Node.js, la version de pnpm, le commit du dépôt, la branche active, les plugins chargés et la valeur attendue de DSH_HOME, sans publier de secret.
La documentation officielle du projet indique notamment que le développement actuel s’appuie sur Node.js 22.19 ou une version 24 et que le dépôt épingle pnpm 11.7.0. Elle mentionne également Git 2.26 ou une version ultérieure pour le flux de développement. Ces informations ne constituent pas une promesse de compatibilité générale, mais elles donnent une base de comparaison pour une installation source. (github.com)
Le relevé doit contenir :
- la version affichée par l’outil ;
- la version de Node.js et du gestionnaire de paquets ;
- le chemin absolu du projet ;
- la branche et le commit Git ;
- la liste des plugins et leur version ;
- les noms des variables d’environnement attendues, jamais leurs valeurs ;
- les journaux de session et leur emplacement ;
- les tâches continues actuellement actives.
Il faut ensuite arrêter les tâches d’écriture ou les mettre en pause. Le dossier source devient la référence de retour arrière. Une copie compressée chiffrée des journaux peut être conservée hors du dossier de travail, avec un contrôle d’intégrité adapté à la politique de l’équipe.
[ SECTION_04 ] Deuxième étape : éliminer le risque de mauvais workspace
Un agent qui travaille dans le mauvais workspace peut produire une réponse apparemment correcte tout en analysant ou modifiant le mauvais projet. Ce risque est supérieur à une simple erreur d’installation, car il touche directement les fichiers et les commandes autorisées.
Le guide officiel de l’interface Web précise que le processus utilise son répertoire d’invocation comme emplacement de système de fichiers par défaut, mais qu’une nouvelle interface n’a aucun workspace sélectionné tant qu’un projet n’a pas été ajouté. Le compositeur de session reste indisponible avant cette sélection. (github.com)
Sur le Mac cloud, la vérification doit suivre cet ordre :
- créer le répertoire cible avec un chemin absolu clairement identifié ;
- cloner ou recopier le dépôt dans ce chemin ;
- contrôler le commit et la branche ;
- afficher le chemin courant depuis le terminal ;
- ouvrir DeepSeek Harness depuis le répertoire prévu ;
- sélectionner explicitement le workspace dans l’interface ;
- lancer une tâche en lecture seule, par exemple un inventaire des paquets et des fichiers principaux ;
- comparer le résultat avec la source.
Tant que cette comparaison n’est pas satisfaisante, l’édition de fichiers, l’exécution de commandes et la délégation à des sous-agents doivent rester fermées.
| Contrôle du workspace | Résultat attendu | Échec à traiter |
|---|---|---|
| Chemin absolu | Identique au chemin documenté sur la cible | L’interface pointe vers un parent ou un ancien clone |
| Branche Git | Branche prévue pour la migration | Branche par défaut ou branche de test inattendue |
| Changements locaux | Liste connue avant transfert | Modifications manquantes ou apparues sans explication |
| Analyse en lecture seule | Même périmètre fonctionnel | L’agent décrit un autre projet ou ignore des fichiers |
| Permissions | Lecture avant écriture | Des commandes d’écriture sont disponibles trop tôt |
Pour les équipes qui préparent plusieurs environnements, le guide de déploiement Mac de NOVAKVM peut servir de point de départ pour organiser le choix du Mac distant, mais il ne remplace pas la validation du workspace DeepSeek Harness.
[ SECTION_05 ] Configuration, Provider et modèle : recopier sans casser les références
Une configuration fonctionnelle contient plusieurs couches. Les préférences générales ne doivent pas être confondues avec l’identité du Provider, le modèle sélectionné et les variables d’environnement qui permettent l’authentification.
Le guide officiel indique que la clé API peut être saisie dans les réglages de modèles et que la route devient utilisable sans redémarrage du serveur. Il indique aussi que les autres Providers et les points d’accès compatibles nécessitent une configuration distincte. (github.com)
La migration doit donc distinguer :
- les réglages d’interface et de comportement ;
- l’identifiant permanent du Provider ;
- l’identifiant du modèle ;
- l’URL de base éventuelle ;
- le nom de la variable d’environnement ;
- la valeur secrète, qui doit être injectée séparément ;
- les sessions enregistrées qui peuvent faire référence à l’ancien Provider.
Un renommage improvisé peut rendre d’anciennes sessions illisibles ou modifier le routage des requêtes. Il est préférable de conserver l’identifiant existant lorsque son rôle est compris, puis de créer une nouvelle session pour vérifier l’appel au modèle. Le test doit confirmer le modèle réellement sélectionné, et pas seulement l’absence de message d’erreur.
| Élément de configuration | Peut être documenté | Peut être copié tel quel | Doit être vérifié ou recréé |
|---|---|---|---|
| Nom du modèle | Oui | Parfois | Toujours avec une nouvelle requête |
| Identifiant du Provider | Oui | Oui, si stable | Oui, s’il est lié à des sessions |
| URL de base | Oui | Oui, si autorisée | Vérifier la route et le certificat |
| Nom de variable d’environnement | Oui | Oui | Confirmer sa présence dans le processus |
| Valeur de la clé API | Non dans une archive | Non | Réinjecter par un canal contrôlé |
| Préférences d’interface | Oui | Souvent | Vérifier l’effet sur la session |
Un test minimal consiste à demander une réponse courte, puis une lecture contrôlée du dépôt. Si la lecture fonctionne mais que l’appel au modèle échoue, le problème se situe probablement dans le Provider ou la source du secret. Si le modèle répond mais que le dépôt est inaccessible, le problème se situe dans le workspace.
[ SECTION_06 ] Secrets : réinjecter, contrôler, nettoyer
Une clé API ne doit jamais être copiée avec le répertoire de configuration. Le guide de développement officiel montre que le projet peut lire DEEPSEEK_API_KEY depuis l’environnement ou un fichier .env ignoré par Git, et rappelle qu’une véritable clé ne doit pas être commitée. (github.com)
La méthode de travail est la suivante :
- inscrire uniquement le nom du secret dans la fiche de migration ;
- préparer la variable ou le gestionnaire de secrets sur le Mac cloud ;
- injecter la valeur hors de l’archive ;
- démarrer le processus avec l’identité prévue ;
- vérifier que le processus lit bien cette source ;
- effectuer un appel de modèle contrôlé ;
- examiner les journaux, l’historique du shell et les fichiers temporaires ;
- révoquer toute clé qui aurait été exposée pendant un essai.
Le contrôle ne doit pas se limiter à l’interface. Une interface peut afficher un Provider enregistré tandis que le processus distant utilise une variable vide, une ancienne valeur ou une autre configuration de session.
[ SECTION_07 ] Plugins et versions : revenir au socle officiel plutôt que réinstaller au hasard
Les plugins concentrent souvent les incompatibilités les plus difficiles à diagnostiquer. Un plugin local peut fonctionner grâce à une dépendance installée globalement, à un chemin implicite ou à une version précise du moteur JavaScript.
Le dépôt officiel décrit une architecture où les composants sont organisés comme des plugins et fournit un mécanisme de découverte via le sujet dsh-plugin. Il reste toutefois en developer preview, ce qui interdit de déduire une compatibilité durable à partir d’une seule installation réussie. (github.com)
Sur la cible, il faut d’abord installer et démarrer la combinaison de base. Ensuite seulement, les plugins sont ajoutés un par un. Le responsable doit conserver pour chaque plugin :
- son nom exact ;
- sa version ou son commit ;
- ses variables requises ;
- ses dépendances système ;
- son point de chargement ;
- sa permission d’accès aux fichiers et aux commandes ;
- son test de démarrage.
Si le démarrage échoue, la réinstallation complète est une mauvaise réponse : elle efface souvent le signal utile. Il faut désactiver le dernier plugin, relancer le socle, puis comparer les versions et les variables. Le résultat attendu est un environnement minimal qui démarre, même si certains plugins restent temporairement absents.
[ SECTION_08 ] Les journaux de session servent d’archive avant de servir de reprise
Les journaux de session DeepSeek Harness ont deux fonctions : conserver le contexte utile et fournir une trace d’audit. Ils ne doivent pourtant pas être assimilés à une sauvegarde garantie de l’état exécutable.
Le dépôt officiel prévient que le projet évolue rapidement et peut introduire des changements incompatibles. Cette limite concerne particulièrement une reprise de session entre versions, chemins ou combinaisons de plugins différentes. (github.com)
La stratégie recommandée est graduelle :
- conserver le journal original en lecture seule ;
- travailler sur une copie ;
- tester l’ouverture ou la restauration dans l’environnement cible ;
- comparer le Provider, le modèle et le workspace associés ;
- ne pas écraser la source si la lecture échoue ;
- créer une nouvelle session lorsque la compatibilité n’est pas démontrée ;
- recopier dans le nouveau contexte les décisions, contraintes et résultats utiles, sans importer aveuglément tout l’état interne.
Un journal qui ne peut pas être repris conserve une valeur historique et d’audit. Il n’est pas pour autant inutilisable. Il peut servir à reconstruire un prompt de reprise, une note de décision ou une liste de tests.
[ SECTION_09 ] Questions fréquentes
Les réponses suivantes couvrent les quatre décisions qui bloquent le plus souvent une migration vers un Mac cloud.
DeepSeek Harness change-t-il automatiquement de projet après migration ?
Non. Le workspace doit être sélectionné et vérifié explicitement sur la cible. Le processus peut démarrer dans un répertoire différent du projet attendu, notamment après un clonage dans un chemin nouveau. La première session doit donc rester en lecture seule et confirmer le dépôt, la branche, les fichiers visibles et le périmètre d’action avant toute modification.
Faut-il migrer tous les fichiers placés dans DSH_HOME ?
Non. DSH_HOME doit être considéré comme un emplacement technique à inventorier, pas comme une unité de restauration. Les fichiers de configuration, secrets, plugins, caches et journaux n’ont pas le même niveau de compatibilité ni le même risque. Copiez les éléments identifiés, recréez les dépendances et laissez de côté les caches ou temporaires non nécessaires.
Une session peut-elle continuer après un redémarrage du Mac cloud ?
La continuité doit être prouvée par un test de redémarrage, pas supposée. Après l’arrêt et le redémarrage, vérifiez le workspace, la source des secrets, le Provider, le modèle, les plugins et la visibilité des journaux. Si un seul de ces éléments change, démarrez une nouvelle session et conservez l’ancienne pour référence.
Quelle solution choisir si une tâche doit rester active pendant une migration ?
Conservez l’environnement local intact, préparez une cible indépendante, puis exécutez la tâche en parallèle avec des permissions réduites. La bascule n’intervient qu’après validation du modèle, des fichiers et du redémarrage. Pour des essais courts, la location d’un Mac distant limite le risque de modifier le poste de travail principal.
[ SECTION_10 ] La validation finale doit produire une preuve exploitable
Une migration terminée n’est pas une migration réussie tant que la cible n’a pas passé un parcours complet. La liste suivante sert de décision opérationnelle.
- [ ] Le chemin absolu du workspace est documenté et confirmé dans l’interface.
- [ ] Le dépôt, la branche, le commit et les changements non commités sont comparés.
- [ ] Une tâche en lecture seule décrit correctement le projet.
- [ ] Le Provider conserve son identifiant prévu.
- [ ] Le modèle répond depuis une nouvelle session.
- [ ] La source réelle de la clé API est vérifiée.
- [ ] Aucun secret ne figure dans l’archive, les journaux ou l’historique du terminal.
- [ ] Le socle DeepSeek Harness démarre sans plugin additionnel.
- [ ] Les plugins sont réintroduits et testés individuellement.
- [ ] Les journaux originaux sont sauvegardés en lecture seule.
- [ ] Une copie de journal a été testée sans écraser l’original.
- [ ] Une modification de fichier contrôlée demande l’autorisation attendue.
- [ ] Une commande contrôlée respecte la politique d’approbation.
- [ ] Le Mac cloud a été redémarré.
- [ ] Le workspace et la configuration restent corrects après redémarrage.
- [ ] La condition de retour vers l’environnement source est écrite.
- [ ] La période de conservation de l’environnement source est décidée.
Pour une exploitation par plusieurs personnes, le guide de validation de sécurité DeepSeek Harness peut compléter cette vérification, notamment pour les permissions et la gestion des secrets. Si les plugins constituent le principal risque, le contenu consacré au rétablissement des plugins DeepSeek Harness peut être utilisé comme support de préparation d’un environnement de secours.
Une note d’acceptation doit enfin consigner la version testée, la date, les résultats, les écarts connus et le déclencheur de retour arrière. Sans cette trace, une panne ultérieure obligera l’équipe à reconstruire le diagnostic depuis zéro.
[ SECTION_11 ] Le Mac cloud doit d’abord servir de zone d’essai indépendante
La solution locale actuelle conserve souvent des dépendances invisibles, un chemin de travail implicite et des secrets difficiles à auditer. Elle immobilise aussi le poste principal lorsque l’agent doit rester actif, et un changement de configuration peut perturber les tâches quotidiennes.
Un environnement distant générique peut résoudre la disponibilité, mais il ajoute parfois une image logicielle non maîtrisée, une gestion des permissions peu adaptée à macOS et une restauration de session incertaine. Pour un projet qui dépend de plugins, d’outils audio ou vidéo, de logiciels de design et d’une interface macOS persistante, ces limites deviennent vite concrètes.
Dans ce contexte, louer auprès de NOVAKVM un Mac cloud séparé du poste local permet de mener la répétition sans toucher à l’environnement source. La location ne remplace pas l’inventaire ni les tests : elle fournit surtout une cible indépendante pour vérifier le workspace, le modèle, les plugins, les journaux et le redémarrage avant le transfert des tâches continues. Cette approche est moins pertinente pour une charge lourde stable à long terme ou pour un besoin d’accès direct à des interfaces physiques ; elle est en revanche adaptée à une migration progressive, à une validation temporaire et à un environnement de secours.