DeepSeek Harness Job Panel : répartir les sous-agents

Symptôme : plusieurs sous-agents apparaissent dans le même panneau, mais personne ne sait qui peut écrire, fusionner ou reprendre une tâche.

Solution la plus rapide : ne répartissez pas les rôles selon le nom de l’agent. Écrivez un contrat par tâche avec un objectif unique, une zone de travail, des permissions, un livrable et un responsable de reprise. DeepSeek Harness Job Panel sert à observer et coordonner ; il ne garantit pas automatiquement l’isolation des fichiers, la résolution des conflits ni la reprise après redémarrage.

Ce guide s’adresse aux développeurs indépendants qui veulent découper un travail complexe entre plusieurs sous-agents, aux petites équipes qui doivent contrôler les écritures dans un dépôt partagé et aux ingénieurs plateforme responsables des permissions, de l’exécution distante et de la récupération des tâches.

Point de contrôle : une tâche affichée comme « en cours » dans un panneau ne prouve ni qu’un processus tourne encore, ni que son espace de travail est isolé, ni que son contexte pourra être restauré.

Le vrai partage n’est pas celui des agents, mais celui de la responsabilité

Le premier risque vient d’une frontière mal définie. Votre agent principal demande à un sous-agent d’actualiser l’authentification, puis continue lui-même à modifier le même module. Les deux exécutions peuvent réussir séparément, tout en produisant un résultat impossible à attribuer.

Pour éviter cette situation, chaque tâche de sous-agent doit avoir les cinq éléments suivants :

• un identifiant stable, par exemple AUTH-READ-01 ou TEST-API-02 ;
• un objectif formulé avec un seul verbe d’action ;
• une source d’entrée versionnée : commit, branche, fichier ou rapport ;
• une zone de responsabilité explicite ;
• un livrable contrôlable par l’agent principal.

L’agent qui crée la tâche n’est pas forcément celui qui doit écrire le code. Il peut rester propriétaire de la décision, tandis qu’un autre agent produit une analyse ou un correctif. Cette distinction réduit les doublons, notamment lorsque le panneau affiche plusieurs activités sans exposer clairement la relation entre le parent et ses sous-tâches.

Les documents de référence sur l’orchestration d’agents distinguent déjà les travailleurs délégués, les sessions parallèles et les espaces Git isolés. La surveillance centralisée est donc une fonction différente de l’isolation des modifications. (code.claude.com)

Comparer les missions avant de comparer Codex et Claude Code

Codex et Claude Code peuvent apparaître dans la même architecture, mais leur nom ne suffit pas à définir leur responsabilité. Avant toute répartition, vous devez tester le comportement réel de la version utilisée : accès aux outils, écriture autorisée, exécution des commandes, visibilité des journaux et format de sortie.

Pour une recherche d’architecture, une analyse de dépendances ou une vérification de convention, commencez par une mission en lecture seule. Elle permet de mesurer la qualité du contexte transmis sans exposer le dépôt à une modification.

Pour une correction locale, donnez à l’agent une liste courte de fichiers et une condition d’acceptation. Une demande telle que « améliorez le module de connexion » est trop large : elle ne permet pas de savoir si l’agent devait modifier le code, les tests, la documentation ou la configuration.

Pour les tests, séparez l’exécution de la correction lorsque l’échec est susceptible de modifier l’environnement. Un agent qui peut corriger et relancer en boucle risque de masquer la cause initiale. Le rôle de validation doit produire des preuves, pas seulement une phrase indiquant que « tout semble correct ».

La documentation de Codex recommande d’utiliser des fichiers de consignes permettant de préciser comment naviguer dans le dépôt et quelles commandes exécuter. (openai.com) De son côté, la documentation de Claude Code décrit des sous-agents avec des outils et des modes de permission distincts. (code.claude.com) Dans les deux cas, cela confirme une règle de méthode : partez du contrat d’exécution, puis choisissez l’agent compatible.

Ces notes ne mesurent pas la qualité d’un produit. Elles mesurent l’adéquation d’un profil à une tâche donnée. Un agent d’écriture peut obtenir une bonne note de productivité et une mauvaise note de sécurité si vous lui accordez un accès réseau ou des permissions trop larges.

Trois espaces de travail, trois niveaux de responsabilité

La question « plusieurs agents peuvent-ils modifier le même dépôt ? » appelle une réponse conditionnelle. Oui, techniquement, mais la décision doit dépendre du recouvrement des fichiers et de la responsabilité de fusion.

Option A : partage en lecture seule

Utilisez un même espace lorsque les agents observent le dépôt sans l’altérer. Vous pouvez alors lancer une analyse de structure, une recherche de régression et une lecture de documentation en parallèle.

Cette option convient à :

• l’inventaire des modules ;
• la recherche de points d’entrée ;
• l’analyse de journaux déjà produits ;
• la préparation d’un plan de correction ;
• la comparaison de solutions pour un flux audio, vidéo ou de conception.

Son avantage est la simplicité. Son défaut est que les agents peuvent lire un état qui change pendant leur analyse si un autre processus écrit dans le même répertoire. Fixez donc un commit ou une archive de référence.

Option B : espace isolé par agent

Dès que deux agents peuvent modifier des fichiers proches, créez une branche ou un espace de travail distinct. Les worktrees Git sont conçus précisément pour que plusieurs sessions ne touchent pas les mêmes fichiers de travail. La documentation de Claude Code décrit cette approche avec une branche et un répertoire propres à chaque session. (code.claude.com)

Cette stratégie convient à :

• deux corrections indépendantes ;
• une migration mécanique et une correction fonctionnelle ;
• une modification d’interface et une modification de tests ;
• des expérimentations qui ne doivent pas affecter la branche principale.

L’isolement ne résout pas la fusion. Il déplace la responsabilité vers le coordinateur, qui doit examiner les diffs, vérifier les tests et décider de l’ordre d’intégration.

Option C : exécution séquentielle

Si deux missions touchent le même fichier, la meilleure solution est souvent de les exécuter l’une après l’autre. Le premier agent produit son diff et son rapport. Le second reçoit ensuite le nouvel état validé.

Vous perdez du parallélisme, mais vous gagnez une chaîne de responsabilité claire. Cette stratégie est adaptée aux migrations de schéma, aux changements de configuration et aux modifications d’un même composant critique.

Expérience de runbook : augmenter le nombre d’agents avant de séparer les espaces de travail ne crée pas de capacité utile. Vous obtenez surtout davantage de sorties à comparer et davantage de points de fusion.

Les permissions visibles ne sont pas l’isolation du système

Un panneau peut afficher la tâche, son titre et son état sans vous montrer l’ensemble des droits du processus. Vous devez donc vérifier séparément :

• les fichiers lisibles ;
• les fichiers modifiables ;
• les commandes disponibles ;
• l’accès au réseau ;
• les variables d’environnement ;
• les fichiers de configuration ;
• les identifiants ou jetons montés dans l’environnement.

Dans Claude Code, les sous-agents héritent du contexte de permission de la session principale, avec des règles spécifiques selon le mode utilisé. Certains modes permettent d’accepter automatiquement des modifications, tandis qu’un mode de contournement supprime les demandes d’autorisation ; la documentation recommande de l’utiliser avec prudence. (code.claude.com)

La conséquence opérationnelle est importante : créer un sous-agent nommé « testeur » ne le rend pas automatiquement incapable d’écrire. Inversement, afficher un agent dans Job Panel ne signifie pas que le panneau fournit une isolation au niveau du système d’exploitation.

Pour les tâches à risque, conservez un point d’approbation avant :

• l’écriture dans .git ou dans une configuration de déploiement ;
• l’envoi de données vers un service externe ;
• la rotation ou l’utilisation d’un secret ;
• la suppression d’un répertoire ;
• la publication d’un artefact ;
• la modification d’une branche protégée.

Si vous utilisez un environnement Mac distant, comparez également l’isolation matérielle ou virtuelle avant de choisir votre architecture. La différence entre un espace macOS dédié et une virtualisation partagée peut modifier la portée réelle des permissions ; voyez à ce sujet notre guide sur le Mac bare metal et la virtualisation macOS.

Première étape : écrire le contrat de tâche

Un contrat utile tient dans une fiche courte, mais il doit empêcher les interprétations concurrentes. Utilisez cette structure :

Identifiant :
Objectif unique :
Entrée de référence :
Fichiers autorisés :
Commandes autorisées :
Réseau et secrets :
Espace de travail :
Livrables obligatoires :
Critères d’acceptation :
Responsable de fusion :
Responsable de reprise :
Condition d’arrêt :

L’objectif doit être vérifiable. Préférez « ajouter les tests de validation du format de date dans le module X » à « fiabiliser la gestion des dates ».

Les livrables doivent également être imposés. Un sous-agent qui rend uniquement une conclusion oblige l’agent principal à refaire l’enquête. Demandez au minimum :

• la liste des fichiers lus ou modifiés ;
• le diff ou le commit produit ;
• les commandes exécutées ;
• les résultats de test ;
• un résumé des erreurs ;
• les éléments non terminés ;
• les risques connus.

Deuxième étape : tester la frontière avec une mission minimale

Avant de lancer une modification importante, donnez à Codex ou Claude Code une tâche volontairement petite. Demandez-lui de lire un fichier, de produire un rapport et d’exécuter une commande sans écriture. Ensuite, vérifiez ce que Job Panel affiche réellement.

Répétez le test avec une modification limitée dans un espace isolé. Contrôlez si :

• la tâche voit le bon répertoire ;
• le diff apparaît au bon endroit ;
• l’agent peut accéder à des fichiers hors périmètre ;
• les demandes d’autorisation remontent à l’opérateur ;
• le résultat reste exploitable après la fin du processus.

Le dépôt public de DeepSeek Harness décrit une architecture de contrats et d’adaptateurs pour plusieurs modes d’intégration, mais cette information ne suffit pas à prouver les propriétés de séparation ou de récupération d’un panneau de tâches. (github.com)

Troisième étape : attribuer une seule écriture par fichier critique

Pour chaque fichier sensible, nommez un propriétaire temporaire. L’agent principal peut conserver la décision finale, mais un seul sous-agent doit être autorisé à produire la modification active.

Si deux tâches ont besoin du même fichier, transformez l’une d’elles en analyse ou placez les deux dans des espaces isolés. Une règle simple fonctionne bien :

• lecture partagée si aucun fichier n’est modifié ;
• écriture isolée si les fichiers sont différents ;
• séquence obligatoire si le périmètre se recouvre.

Ne demandez pas à deux agents de « travailler en parallèle sur le même dépôt » sans préciser s’ils partagent le dossier, la branche ou seulement l’historique Git. Ces trois notions ne sont pas équivalentes.

Quatrième étape : organiser la validation hors de l’agent producteur

Le sous-agent qui modifie ne doit pas être l’unique juge de son résultat. Attribuez la validation à l’agent principal ou à un profil distinct en lecture seule.

La validation doit répondre à quatre questions :

1. Le diff reste-t-il dans le périmètre autorisé ?
2. Les tests correspondent-ils à l’objectif de la tâche ?
3. Les erreurs non résolues sont-elles documentées ?
4. La fusion peut-elle être annulée sans perdre une autre modification ?

Pour un projet audio ou vidéo, ajoutez les contrôles propres au scénario : présence des fichiers générés, cohérence des métadonnées, lecture d’un échantillon, absence d’écrasement dans le dossier d’export. Pour du design, contrôlez les formats, les dépendances liées et la possibilité de régénérer les livrables.

Cinquième étape : définir la reprise avant l’échec

Une tâche échouée doit produire un état exploitable, pas seulement un statut. La procédure de reprise doit distinguer :

• échec avant toute écriture ;
• écriture partielle avec diff récupérable ;
• test échoué après modification ;
• perte de connexion ;
• arrêt du processus principal ;
• expiration ou annulation ;
• résultat affiché mais processus disparu.

Le responsable de reprise décide alors entre trois actions :

• reprendre dans le même espace si l’état est vérifiable ;
• créer une nouvelle tâche à partir du dernier commit propre ;
• supprimer les changements et recommencer avec un contrat corrigé.

Ne relancez pas automatiquement une tâche qui a échoué à cause d’une permission manquante. Elle échouera probablement de la même manière, ou demandera une permission plus large que nécessaire. Les tâches d’arrière-plan peuvent aussi se comporter différemment des tâches interactives lorsqu’une question d’autorisation apparaît ; ce point est documenté pour les sous-agents Claude Code. (code.claude.com)

Questions fréquentes sur Job Panel et les sous-agents

Comment gérer des sous-agents avec DeepSeek Harness Job Panel ?

Commencez par attribuer à chaque tâche un identifiant, un objectif unique, une source d’entrée, un responsable et un livrable vérifiable. Le panneau peut centraliser l’observation, mais vous devez encore contrôler les fichiers accessibles, les commandes autorisées, l’espace de travail et la procédure de reprise. Ne considérez jamais l’affichage d’un état comme une preuve d’isolation ou de persistance.

Comment répartir les sous-tâches entre Codex et Claude Code ?

Ne choisissez pas selon le nom de l’outil. Donnez d’abord les tâches en lecture seule, les modifications contrôlées, les tests et les actions externes à des profils distincts. Vérifiez ensuite les capacités réellement disponibles dans votre version. Codex ou Claude Code peut devenir coordinateur, analyste ou exécutant selon ses permissions, son environnement et la nature du livrable demandé.

Plusieurs sous-agents peuvent-ils modifier le même dépôt ?

Oui, mais le partage direct du même espace de travail crée un risque élevé de fichiers écrasés, d’index Git incohérent et de validation ambiguë. Préférez un espace isolé par tâche lorsque deux agents écrivent. Le partage peut rester acceptable pour une analyse en lecture seule ou pour des fichiers strictement séparés, à condition de définir qui fusionne et qui valide.

Qui reprend une tâche de sous-agent après un échec ?

Le contrat de tâche doit nommer le responsable de reprise avant le lancement. Le sous-agent fournit les modifications partielles, les journaux, les tests exécutés et le point exact d’arrêt. Le coordinateur décide alors entre nouvelle tentative, retour arrière ou reprise humaine. Sans ces preuves, relancer automatiquement risque de répéter la même erreur ou d’empiler des changements incompatibles.

Job Panel permet-il de poursuivre une tâche après un redémarrage ?

Ne le supposez pas. Une tâche visible après une reconnexion peut être seulement conservée dans l’interface, sans processus actif ni contexte récupérable. Testez séparément l’annulation, l’expiration, l’arrêt du processus principal, la coupure réseau et le redémarrage de l’environnement. Seule la documentation officielle ou un essai reproductible peut confirmer une reprise réelle.

La grille de décision pour choisir votre architecture

Utilisez les conditions suivantes avant de créer la deuxième tâche :

• Si les deux missions sont en lecture seule et utilisent le même commit, choisissez le partage d’espace ; sinon, passez à un espace isolé.
• Si les agents écrivent dans des fichiers différents et qu’un responsable de fusion est nommé, choisissez l’exécution parallèle isolée ; sinon, exécutez les missions en séquence.
• Si une tâche appelle un outil externe, utilise un secret ou peut modifier une cible de production, choisissez une validation humaine obligatoire ; sinon, un profil automatisé contrôlé peut suffire.
• Si le livrable contient un diff, des tests et des journaux exploitables, autorisez la reprise automatisée limitée ; sinon, exigez une analyse humaine.
• Si vous n’avez pas testé l’état après redémarrage, considérez la tâche comme non persistante ; sinon, documentez précisément le mécanisme observé.
• Si deux agents revendiquent le même fichier ou le même objectif, arrêtez la seconde tâche avant écriture et corrigez le contrat.

Cette grille aboutit généralement à trois architectures :

1. Un seul sous-agent pour les tâches courtes, sensibles ou fortement couplées.
2. Plusieurs sous-agents en série lorsque les étapes dépendent du même état de dépôt.
3. Plusieurs sous-agents isolés en parallèle lorsque les périmètres sont séparés et que la fusion est explicitement attribuée.

Pour préparer une infrastructure durable, complétez cette méthode avec un guide consacré au déploiement de DeepSeek Harness sur plusieurs projets et, lorsque les sessions deviennent persistantes, avec une réflexion sur la planification du nombre de nœuds de calcul Mac. Cette étape permet de relier le nombre de tâches simultanées à la capacité réellement disponible, sans confondre parallélisme logiciel et isolation opérationnelle.

Dernière vérification avant lancement

Avant de cliquer sur le lancement dans Job Panel, vérifiez les six points suivants :

• l’identifiant de la tâche n’est pas réutilisé ;
• l’objectif ne contient qu’un changement principal ;
• l’espace de travail est documenté ;
• les fichiers autorisés sont listés ;
• le livrable comporte des preuves ;
• le responsable de reprise est joignable.

Dernière mise à jour : 18 août 2026. Le périmètre doit être revérifié sur la release rc.7, la documentation d’architecture, le code du panneau et un dépôt isolé. Les propriétés de permissions, d’annulation, de reprise et de continuité après redémarrage ne doivent pas être déduites de la seule présence de Codex ou Claude Code dans Job Panel.

Votre environnement actuel devient difficile à maintenir lorsque plusieurs agents écrivent dans le même répertoire, que les permissions sont héritées sans contrôle et que les tâches longues dépendent d’une connexion distante unique. Vous perdez alors du temps dans les conflits de fichiers, les relances ambiguës et la recherche de journaux incomplets. Un Mac local partagé ajoute souvent une autre limite : concurrence entre sessions, accès physique non séparé et capacité difficile à réserver pour les tests audio, vidéo ou de design.

Pour deux tâches indépendantes, commencez par un essai à faible risque sur un espace isolé. Si vous devez ensuite maintenir plusieurs agents actifs avec des environnements macOS séparés, une location de Mac auprès de MacDate peut offrir une base plus lisible : une machine par flux, des périmètres de travail distincts et une capacité que vous pouvez ajuster sans acheter immédiatement plusieurs postes. Consultez la présentation française de MacDate lorsque votre besoin porte sur un environnement temporaire, des tests de compatibilité ou une exécution distante contrôlée ; pour une charge stable et permanente, comparez plutôt l’achat d’un Mac dédié avec vos exigences d’accès physique et de conservation des données.