2026 DeepSeek Harness : modifier du code en parallèle, Git worktree ou clonage indépendant ?

La confusion vient souvent du mot « isolation », utilisé pour désigner quatre réalités différentes.

L’espace de travail concerne les fichiers visibles par l’agent : branche active, index, fichiers modifiés et répertoire courant. Un Git worktree sépare efficacement cette couche. La documentation de Git précise que chaque espace possède notamment son propre HEAD et son propre index, tandis qu’une partie des références et des métadonnées reste commune au dépôt principal. Manuel officiel de git worktree

Les processus concernent les serveurs de développement, les tests, les observateurs de fichiers, les émulateurs et les tâches lancées en arrière-plan. Deux worktrees peuvent donc avoir des fichiers distincts tout en essayant d’utiliser le même port, le même répertoire temporaire ou le même service local.

Les dépendances et les produits dérivés comprennent les répertoires de paquets, les index, les caches de compilation, les fichiers générés, les bases de données de test et les exports audio ou vidéo. Git ne les dédouble pas automatiquement. Un worktree ne transforme pas un dépôt en environnement de construction hermétique.

La sécurité concerne les identités, les jetons, les certificats, les clés SSH, les fichiers .env, les droits macOS et les données auxquelles un processus peut accéder. Sur ce point, un worktree n’est pas un bac à sable. Si deux sessions partagent le même compte et le même trousseau, elles partagent potentiellement les mêmes secrets.

DeepSeek Harness impose, pour ses tâches indépendantes de référence, des espaces et des identifiants de session différents. Cela fournit une règle de séparation opérationnelle, mais ne signifie pas que DeepSeek Harness crée, associe et supprime automatiquement les worktrees. Le dépôt officiel décrit l’obligation de séparer les tâches ; l’orchestration complète reste une responsabilité de l’environnement d’exécution. Consigne officielle du fichier BENCHMARK

Pour deux tâches brèves sur le même dépôt, le Git worktree est généralement le meilleur premier choix. Il permet de conserver une origine Git commune tout en donnant à chaque agent un chemin et une branche propres.

Une session doit être associée explicitement à un contrat minimal :

• chemin exact du worktree ;
• nom de branche ou état détaché ;
• objectif de la tâche ;
• fichiers ou modules autorisés ;
• commande de validation ;
• responsable du commit et de la fusion ;
• condition de suppression.

Un exemple de création avec la syntaxe officielle de Git peut prendre cette forme :

git worktree add -b <branche-tache-a> <chemin-worktree-a> <branche-base>
git worktree add -b <branche-tache-b> <chemin-worktree-b> <branche-base>
git worktree list --porcelain

Le choix devient moins sûr dans plusieurs situations :

• les deux agents modifient fréquemment le même fichier ;
• une tâche doit intégrer les changements non validés de l’autre ;
• un générateur écrit dans un répertoire situé hors du worktree ;
• un serveur de développement utilise un port fixe ;
• un outil conserve son état dans le répertoire utilisateur commun ;
• les sous-modules ou les scripts de construction ne supportent pas correctement plusieurs extractions.

Dans ces cas, l’isolation des fichiers ne supprime pas le conflit logique. Si les tâches touchent les mêmes interfaces ou les mêmes fichiers centraux, l’exécution en parallèle peut simplement déplacer le conflit vers la revue de code et la fusion. Pour un refactoring transversal, la bonne décision est souvent de lancer l’analyse en parallèle, puis de sérialiser les modifications.

Réponse opérationnelle aux cas fréquents

Plusieurs sessions peuvent-elles utiliser le même dépôt ? Oui, si chaque session utilise un worktree distinct, une branche distincte et un chemin de travail déclaré. Il ne faut pas faire pointer deux agents vers le même répertoire physique en espérant que leurs branches suffiront à les séparer.

Comment éviter les conflits de branches ? Il faut créer la branche au moment de créer le worktree, vérifier avec git worktree list --porcelain, puis interdire la réutilisation d’une branche déjà attachée à un autre espace. Le nom de branche doit contenir un identifiant de tâche, pas seulement le nom du développeur.

Le worktree convient-il aux tâches d’IA longues ? Il convient aux tâches longues si les fichiers produits, les processus, les ports, les caches et les règles de récupération sont maîtrisés. Pour une session qui conserve de nombreux artefacts ou installe des versions incompatibles, un clonage indépendant devient plus prévisible.

Un cache de dépendances commun est-il sûr ? Un cache en lecture seule peut être partagé lorsque l’outil garantit l’atomicité des écritures et l’intégrité des entrées. En revanche, le répertoire de sortie, les fichiers de verrouillage et les bases de données locales doivent rester propres à la tâche.

Dans une équipe, un worktree ne remplace jamais la responsabilité de fusion. Le dossier sépare les fichiers, mais il ne décide pas quelle modification est acceptable, qui la relit ou quelle branche reçoit le commit.

Pour chaque tâche, le contrat doit donc enregistrer :

1. le propriétaire de la tâche ;
2. la branche de départ ;
3. la branche cible ;
4. le périmètre de modification ;
5. le responsable de la validation ;
6. la règle applicable en cas d’annulation ;
7. la personne autorisée à supprimer l’espace.

Les tâches n’ont pas toutes le même besoin d’exclusivité :

• analyse en lecture seule : un worktree ou une copie temporaire suffit généralement, à condition que l’agent ne lance pas de commande destructive ;
• modification de code : un worktree dédié et une branche dédiée sont nécessaires ;
• correction de tests : le worktree peut être partagé au niveau du dépôt, mais les sorties de test et les bases locales doivent être séparées ;
• migration ou régénération massive : le clonage indépendant est préférable si l’outil réécrit de nombreux fichiers ou produit des artefacts difficiles à distinguer ;
• modification d’un fichier très disputé : l’exécution doit repasser en série, même si les répertoires sont séparés.

Une équipe peut aussi utiliser un worktree pour une analyse préparatoire, puis convertir la tâche en exécution séquentielle dès qu’un agent doit appliquer une modification dans une zone déjà touchée. Cette règle évite de confondre « capacité à lancer deux sessions » et « capacité à fusionner proprement deux résultats ».

Le partage du dépôt Git est rarement le principal problème. Les collisions apparaissent plutôt dans les répertoires que les outils supposent uniques.

Un projet peut écrire dans un dossier de dépendances situé à la racine, dans un cache utilisateur, dans un répertoire de compilation externe ou dans un emplacement temporaire déterminé par une variable d’environnement. Si deux agents lancent simultanément une installation ou une compilation, le résultat peut dépendre de l’ordre des écritures, et non de la branche choisie.

Le tableau suivant sert à séparer les éléments qui peuvent parfois être mutualisés de ceux qui doivent être propres à chaque tâche.

La configuration du dépôt mérite une attention particulière. Git indique que le fichier de configuration du dépôt est partagé par défaut entre les worktrees ; l’extension extensions.worktreeConfig permet de déplacer certaines options vers une configuration propre à chaque espace. Référence officielle sur extensions.worktreeConfig

Il faut donc examiner les paramètres tels que le répertoire de construction, le mode de récupération des sous-modules, les options de dépôt local et les scripts qui calculent leurs chemins à partir du répertoire principal. Un clonage indépendant ne résout pas non plus les ports ou les secrets, mais il limite les effets de bord liés au dépôt et aux outils qui inspectent sa configuration.

Attention : un worktree réduit le risque d’écrasement des fichiers suivis par Git ; il ne garantit ni l’isolement des processus, ni l’absence de partage des clés, ni l’indépendance des caches utilisateur.

Le worktree est adapté aux tâches courtes, homogènes et placées dans le même périmètre de confiance. Le clonage indépendant est le compromis pour les builds lourds, les dépendances incompatibles ou les tâches qui doivent conserver une configuration de dépôt autonome. L’environnement indépendant s’impose lorsque deux projets ne doivent pas voir les mêmes identités, les mêmes clés ou les mêmes données.

Pour un pool de Mac distants, l’outil de plateforme doit enregistrer l’association entre session DeepSeek Harness, identifiant de tâche, chemin, branche, processus et responsable. La présentation de NUKCLOUD peut servir de point de départ pour évaluer le contexte d’exécution distant, tandis que le centre d’aide NUKCLOUD doit être consulté lorsque la livraison ou la récupération d’une machine fait partie du processus.

Une chaîne automatisée fiable doit répartir les responsabilités au lieu de laisser chaque agent manipuler directement le dépôt principal.

Création

1. Réserver un identifiant de tâche et vérifier qu’il n’est pas déjà actif.
2. Choisir la branche de base et enregistrer son identifiant de validation.
3. Créer le worktree ou le clonage dans un chemin déterministe.
4. Attribuer une branche unique et générer un fichier de métadonnées hors du code.
5. Définir les variables de sortie, le répertoire temporaire et le port.
6. Lancer DeepSeek Harness avec la session liée à ce chemin.
7. Effectuer une modification sans conséquence, un test court et une vérification de statut.

Suivi

Le contrôleur doit interroger périodiquement :

git worktree list --porcelain
git -C <chemin-worktree> status --short
git -C <chemin-worktree> branch --show-current

Le résultat doit être conservé avec l’état de la session, les journaux de commandes et la décision de fusion. Un espace « inactif » ne doit pas être déclaré récupérable tant qu’un processus ou un fichier non suivi peut encore produire un résultat.

Récupération

Avant suppression, l’opérateur doit :

• arrêter les processus lancés par la tâche ;
• sauvegarder ou rejeter explicitement les artefacts ;
• vérifier les fichiers suivis modifiés et les fichiers non suivis ;
• confirmer que le commit attendu est poussé ou archivé ;
• retirer l’espace avec la commande Git prévue.

git worktree remove <chemin-worktree>
git worktree prune --dry-run
git worktree prune

La documentation officielle précise qu’un worktree non propre ne peut pas être retiré sans forçage et qu’un répertoire supprimé manuellement peut laisser des métadonnées administratives à nettoyer. Il ne faut donc pas supprimer le dossier puis supposer que le dépôt est propre. Procédure officielle de suppression et de nettoyage

Si la récupération échoue, le système doit conserver le chemin, la branche, le dernier état Git, les journaux et la cause de l’échec. Un opérateur humain reprend la main lorsque des fichiers non suivis sont encore nécessaires, qu’un processus ne répond plus, qu’un sous-module est présent ou que la provenance d’un artefact n’est pas claire. Le forçage ne doit jamais devenir la procédure normale.

Un dépôt client, un projet soumis à plusieurs niveaux d’autorisation ou une tâche utilisant un jeu de clés différent doit être traité comme un changement de frontière de confiance.

Le clonage indépendant est utile lorsque l’équipe veut séparer les configurations du dépôt, les fichiers locaux et la durée de vie des artefacts. Il ne suffit cependant pas à protéger des secrets accessibles au même compte macOS. Dans ce cas, il faut créer un compte distinct, isoler le trousseau, limiter les autorisations des répertoires et, si nécessaire, réserver un Mac séparé.

Le refus de partager un worktree doit être automatique lorsque l’une de ces conditions est remplie :

• les deux tâches appartiennent à des clients différents ;
• les clés ou certificats utilisés ne sont pas les mêmes ;
• les règles de conservation des journaux diffèrent ;
• les données ne peuvent pas être visibles par le même compte ;
• la révocation doit être possible pour une tâche sans interrompre l’autre ;
• un agent peut exécuter des commandes d’administration ou accéder à des interfaces physiques.

Dans ces cas, la question n’est plus « quelle structure Git économise le plus d’espace ? », mais « quelle identité doit pouvoir être révoquée sans toucher au reste ? ».

Avant de déployer un modèle dans une équipe, il faut réaliser un test reproductible avec deux branches jetables et le même dépôt de référence.

• [ ] Créer deux worktrees avec deux branches et deux sessions DeepSeek Harness distinctes.
• [ ] Faire modifier un fichier différent dans chaque espace.
• [ ] Faire modifier ensuite le même fichier et vérifier que la fusion reste explicite.
• [ ] Lancer deux constructions avec des chemins de sortie différents.
• [ ] Vérifier qu’aucun processus ne réutilise le même port sans réservation.
• [ ] Annuler une tâche pendant qu’elle écrit des fichiers temporaires.
• [ ] Contrôler les dépendances et déterminer ce qui peut réellement être lu en commun.
• [ ] Fermer une session avec des fichiers non suivis et confirmer que la récupération est bloquée.
• [ ] Exécuter git worktree list --porcelain après suppression.
• [ ] Vérifier qu’un responsable peut retrouver la branche, les journaux et les artefacts de chaque tâche.
• [ ] Refaire le scénario avec un clonage indépendant.
• [ ] Répéter le test avec un compte macOS ou un Mac distinct si les secrets diffèrent.

Le résultat doit être mesuré sur la stabilité, la traçabilité, le temps de récupération et la capacité à expliquer chaque fichier restant, pas seulement sur la rapidité de création. Une équipe qui ne peut pas identifier le propriétaire d’un artefact ne dispose pas encore d’une isolation opérationnelle suffisante.

Pour un usage temporaire, le worktree reste le choix rationnel lorsque le code, les dépendances et le niveau de confiance sont communs. Pour un build qui installe une chaîne différente, un clonage indépendant évite plusieurs effets de bord. Pour un projet client ou une identité séparée, le bon niveau est le compte ou le Mac indépendant, même si cela demande davantage d’administration.

Si l’environnement actuel mélange branches, caches, processus et secrets sur un seul Mac, ses principaux défauts sont prévisibles : les erreurs de nettoyage deviennent difficiles à attribuer, les dépendances peuvent se remplacer mutuellement, les sessions abandonnées laissent des processus actifs et la révocation d’un accès risque d’affecter d’autres tâches. Dans ce contexte, louer un Mac distant avec NUKCLOUD peut offrir une séparation opérationnelle plus nette pour une phase de test, une campagne de build ou un besoin temporaire de capacité, à condition de conserver les mêmes règles de branche, de session et de récupération.

La démarche la plus sûre consiste à commencer par deux branches jetables, à exécuter une modification puis une récupération complète, et à documenter les collisions observées. Si le Mac existant ne permet pas de réserver des espaces indépendants ou si les tâches restent actives assez longtemps pour saturer l’environnement, consultez ensuite un guide de planification de capacité pour des Mac distants parallèles avant de choisir entre un clonage séparé et plusieurs environnements.