DeepSeek Harness Agent Preset 2026 : système ou utilisateur ?

Le preset se charge, mais personne ne sait quelle copie est réellement active ni qui peut la modifier.

La solution la plus sûre est la suivante : gardez les essais et itérations rapides au niveau utilisateur, déployez les workflows d’équipe au niveau système, puis utilisez sur un Mac partagé une base système en lecture seule avec des extensions utilisateur limitées.

Cette décision concerne les développeurs qui veulent conserver leurs combinaisons personnelles sans modifier les autres comptes, les mainteneurs de plateforme qui livrent un Agent Preset identique à toute l’équipe et les responsables sécurité qui doivent contrôler les écritures, les audits et les retours arrière sur des Mac partagés ou distants.

SECTION 01Pourquoi la confiance doit passer avant le confort de l’emplacement

Dans DeepSeek Harness, un Agent Preset n’est pas seulement un dossier contenant quelques préférences. Il décrit une composition de services et de composants qui peuvent modifier la manière dont l’agent travaille. L’architecture officielle présente Harness comme un arbre de plugins composé par couches, avec des profils et des ensembles ordonnés au démarrage. La configuration d’un preset peut donc influencer des services visibles par l’agent, la présentation des outils, les compétences disponibles ou les capacités d’exécution. Documentation officielle de l’architecture Harness

La différence fondamentale entre une racine système et une racine utilisateur n’est donc pas simplement « globale contre personnelle ». Elle concerne surtout l’origine déclarée et la responsabilité de la modification.

• Une racine marquée system correspond à un preset fourni avec le déploiement. Elle peut servir de référence d’équipe, à condition que son contenu soit versionné, examiné et déployé par une procédure identifiable.
• Une racine marquée user correspond à un preset écrit localement, par une personne ou par un agent. Le catalogue officiel distingue cette source de la source système et prévoit l’inclusion de la racine utilisateur selon la configuration active. Déclaration officielle du catalogue de configuration
• Une configuration de sécurité, une règle de livraison ou une combinaison d’outils nécessitant la même interprétation pour tous les comptes ne devrait pas dépendre uniquement d’une copie personnelle.

Cette distinction devient particulièrement importante lorsque le preset assemble plusieurs plugins Cordis. Cordis fournit le contexte partagé, les services, les événements typés et les effets réversibles qui permettent aux composants de s’inscrire dans l’arbre d’exécution. Les principes de composition et d’injection des composants sont décrits dans la documentation technique du dépôt officiel. Présentation officielle de la composition des composants

Autrement dit, un fichier apparemment anodin peut devenir une porte d’entrée vers une composition beaucoup plus large. Vous devez donc demander : « qui a écrit ce preset, qui l’a validé et qui peut le retirer ? », plutôt que : « dans quel dossier est-il le plus facile à déposer ? ».

Un Agent Preset est-il la même chose qu’un preset de permissions, qu’un Plan Mode ou qu’une Skill ?

Non. Un Agent Preset décrit une composition d’agent et de services. Un preset de permissions gouverne les capacités autorisées. Le Plan Mode concerne la manière de préparer ou de conduire une tâche. Une Skill est une unité de connaissance ou de comportement découvrable par le système de compétences. Ces objets peuvent être réunis dans une même chaîne d’exécution, mais ils ne doivent pas être confondus lors de la revue ou de l’audit.

Pour les détails de configuration des capacités, consultez notre guide sur la validation des presets de permissions DeepSeek Harness plutôt que de placer une règle de sécurité dans un Agent Preset uniquement parce que l’interface les affiche à proximité.

SECTION 02Comment vérifier la racine réellement utilisée en cas de doublon

Le catalogue officiel déclare plusieurs éléments déterminants pour les presets : une valeur par défaut, une liste de racines analysées dans un ordre défini, une option permettant d’ajouter la racine utilisateur du répertoire Harness et un type de confiance associé à la source. Il précise également que les racines multiples doivent être interprétées selon leur ordre de parcours et que les identifiants dupliqués doivent être testés au lieu d’être déduits de l’interface. Référence officielle des options de catalogue

Vous devez distinguer deux notions souvent mélangées :

• L’ordre des racines configurées, qui détermine quelle copie portant le même identifiant est retenue.
• L’ordre des couches de composition, qui détermine comment une configuration retenue est ensuite assemblée avec les bundles, le profil, le correctif du répertoire personnel et une éventuelle surcharge de ligne de commande.

Ne déduisez jamais le chemin chargé à partir du seul nom affiché dans l’interface. Le nom peut être identique dans plusieurs emplacements, tandis que l’origine, la confiance et le contenu diffèrent.

Un preset portant le même identifiant est-il chargé depuis le système ou depuis l’utilisateur ?

Vous devez le vérifier par un test d’ombre contrôlé, sans outil sensible et sans contenu client. Créez temporairement deux presets portant le même identifiant, chacun avec un marqueur visuel différent dans une propriété sans impact opérationnel, puis lancez Harness avec une configuration isolée. Conservez la sortie de diagnostic, la configuration effective et la version de la release testée. Supprimez ensuite les marqueurs et refaites le lancement avec le preset approuvé.

La sortie de composition est utile pour comprendre l’arbre démarré : l’architecture officielle documente l’inspection de la configuration effective avec l’option --dump-config. Procédure officielle d’inspection de la configuration Si la version utilisée ne détaille pas encore l’origine du preset dans cette sortie, complétez avec le test d’identifiant dupliqué ; ne remplacez pas cette preuve par une supposition fondée sur l’apparence de l’interface.

Conservez au minimum :

• la version exacte de DeepSeek Harness testée ;
• le profil utilisé ;
• l’ordre des racines présent dans la configuration ;
• l’état de l’option d’inclusion de la racine utilisateur ;
• l’identifiant du preset testé ;
• le résultat observé avec chaque marqueur ;
• la procédure de nettoyage et le preset finalement retenu.

Le comportement des chemins, des valeurs par défaut et de la priorité doit être réexaminé à chaque évolution importante, car le dépôt officiel présente Harness comme un logiciel en aperçu développeur susceptible de changements incompatibles. Dépôt officiel et état du projet

SECTION 03Quel niveau choisir selon la responsabilité de livraison

Le niveau utilisateur est adapté lorsque vous cherchez à accélérer une expérimentation personnelle. Vous pouvez y conserver une combinaison d’outils pour la création vidéo, une chaîne de travail audio, des préférences de conception ou un agent de prototypage qui évolue plusieurs fois dans la même journée. Le coût d’une erreur reste alors limité au compte concerné, à condition que ce compte ne partage pas des secrets ni des privilèges importants.

Ses avantages sont clairs :

• itération rapide sans attendre une revue de plateforme ;
• personnalisation adaptée à votre manière de coder, de monter une vidéo ou de préparer des maquettes ;
• séparation naturelle entre vos essais et la base commune ;
• possibilité de tester une nouvelle composition sans modifier le preset livré aux autres utilisateurs.

Ses limites sont tout aussi importantes :

• origine parfois impossible à prouver après plusieurs modifications ;
• risque de divergence entre deux comptes utilisant le même nom ;
• restauration difficile si le dossier n’est pas versionné ;
• possibilité qu’un agent local écrive une configuration que personne n’a revue ;
• confusion entre préférence personnelle et règle que l’équipe croit obligatoire.

Le niveau système devient préférable dès que le preset constitue une promesse de livraison. C’est le cas pour un environnement remis à un nouveau développeur, une image de Mac distant, une chaîne de génération destinée à plusieurs projets, un workflow audio ou vidéo partagé, ou une configuration qui doit rester identique après réinstallation.

Ses avantages :

• source identifiable et contrôlée par l’équipe de plateforme ;
• déploiement reproductible sur une nouvelle machine ;
• séparation plus nette entre la référence commune et les préférences individuelles ;
• possibilité d’imposer une révision avant changement ;
• retour arrière préparé à partir d’une version connue.

Ses inconvénients :

• cycle de validation plus lent ;
• risque de bloquer une expérimentation légitime si la base est trop rigide ;
• nécessité de gérer les droits de lecture, d’écriture et de remplacement ;
• obligation de tester la compatibilité entre la release de Harness et le contenu livré.

Le projet officiel décrit Harness comme un logiciel en développement actif et publie les informations de version dans son espace de releases. Vous devez donc rattacher chaque preset distribué à une release vérifiée, au lieu de considérer que le comportement observé sur une installation précédente restera identique. Historique officiel des releases

SECTION 04Décision rapide : dans quel cas retenir le système ou l’utilisateur ?

Utilisez la liste de contrôle suivante avant de choisir l’emplacement. Cochez les affirmations qui correspondent à votre cas ; la dernière condition cochée indique généralement le niveau de gouvernance nécessaire.

• [ ] Le preset ne sert qu’à votre expérimentation personnelle, à une préférence d’interface ou à un assemblage d’outils sans obligation d’équipe : retenez le niveau utilisateur.
• [ ] Le preset doit produire le même comportement pour plusieurs comptes : retenez le niveau système.
• [ ] Le preset est livré à des clients, à plusieurs Mac distants ou après une réinstallation : retenez le niveau système avec une source versionnée et un retour arrière documenté.
• [ ] Vous devez préserver une base commune tout en autorisant des variantes personnelles : retenez une base système en lecture seule avec des extensions utilisateur séparées.
• [ ] Vous ne pouvez pas démontrer quelle racine gagne en cas de doublon : n’autorisez pas encore la distribution ; revenez à une seule racine active et réalisez le test d’ombre.
• [ ] Le preset contient un secret, une autorisation ou un chemin dépendant d’un client : séparez la configuration du secret et n’utilisez pas une racine partagée pour cette donnée.
• [ ] Un compte utilisateur peut remplacer silencieusement un preset système par un identifiant identique : interdisez ce modèle sur le Mac partagé ou passez à des environnements séparés.
• [ ] Les comptes appartiennent à des clients ou projets qui exigent des audits et des récupérations indépendants : abandonnez le partage de racine et séparez les environnements.

Cette liste est le principal outil de décision : vous ne choisissez pas un emplacement parce qu’il est plus pratique, mais parce que vous pouvez attribuer la confiance, l’écriture, la livraison et le retour arrière à une personne ou à une équipe précise.

SECTION 05Quelle stratégie appliquer sur un Mac partagé

Pour un Mac partagé, trois modèles sont réalistes.

Base système en lecture seule et extension utilisateur limitée

C’est le meilleur compromis lorsque plusieurs utilisateurs doivent conserver leurs préférences sans modifier la référence commune.

La base système contient les éléments approuvés : composition d’agent, outils attendus, services nécessaires et paramètres de livraison. Les comptes utilisateurs peuvent ajouter des presets personnels sous un identifiant différent, mais ne peuvent pas remplacer la copie système ni écrire dans sa racine.

Ce modèle convient aux équipes de développement, aux ateliers de design et aux workflows audio ou vidéo où chaque utilisateur peut avoir ses propres assistants, tout en gardant les mêmes limites opérationnelles.

La gouvernance doit préciser :

• quels identifiants sont réservés à l’équipe ;
• quels types d’extension sont autorisés ;
• qui valide une nouvelle version ;
• comment les fichiers sont retirés après le départ d’un utilisateur ;
• comment vous démontrez qu’un preset système était présent lors d’un incident.

Base système et utilisateur totalement séparés

Choisissez cette option lorsque les comptes correspondent à des clients, des projets soumis à des règles différentes ou des niveaux de confidentialité incompatibles. Il ne suffit alors plus de séparer les dossiers : vous devez aussi séparer les comptes, les secrets, les sessions et idéalement les espaces de travail.

Un même preset racine ne doit pas devenir un point de rencontre entre deux périmètres qui exigent une récupération indépendante. Le répertoire Harness peut également intervenir dans le contexte local et la découverte des Skills ; une mauvaise frontière de compte peut donc devenir une mauvaise frontière de comportement.

Preset partagé modifiable par tous

Évitez ce modèle sauf pour un laboratoire sans données sensibles. Il est séduisant parce qu’il réduit les opérations de livraison, mais il rend l’auteur réel d’une modification difficile à identifier et complique le retour à un état connu.

Un Mac partagé peut-il laisser les utilisateurs modifier le preset par défaut ?

Oui, techniquement, mais ce n’est pas un bon choix de gouvernance dès que le preset influence un workflow livré, des outils d’exécution ou une frontière client. Autorisez plutôt une copie utilisateur sous un autre identifiant, ou fournissez un mécanisme de surcharge temporaire avec journal, expiration et restauration automatique.

Pour un Mac distant fourni par MACNOX, formalisez cette séparation avant le démarrage : compte attribué, répertoire de travail, permissions d’écriture, source du preset et procédure de remise à zéro. Vous pouvez consulter la page de livraison d’un environnement Mac distant lorsque vous préparez une configuration répétable, puis vérifier que le niveau de contrôle retenu correspond à vos obligations d’audit.

SECTION 06Comment rendre le déploiement reproductible après une réinstallation

Une équipe ne devrait jamais distribuer un Agent Preset par simple copie d’un répertoire découvert sur une ancienne machine. Cette méthode masque la source, les modifications locales et les dépendances implicites.

Procédez plutôt ainsi :

• Identifiez l’artefact source. Conservez le dépôt, l’archive ou le paquet utilisé, ainsi que la release de DeepSeek Harness avec laquelle il a été validé.
• Déclarez la racine et son niveau de confiance. La configuration officielle distingue les racines analysées et les types system ou user; cette information doit figurer dans votre dossier de livraison.
• Réservez les identifiants. Un nom d’Agent Preset utilisé par l’équipe ne doit pas être réutilisé pour une expérimentation personnelle sur la même machine.
• Testez le doublon. Dans un environnement isolé, placez deux copies inoffensives portant le même identifiant et vérifiez laquelle est retenue selon l’ordre de vos racines.
• Vérifiez la configuration effective. Utilisez la sortie de composition disponible dans la release testée, notamment l’inspection de configuration documentée par Harness, puis comparez-la à la version attendue.
• Contrôlez les permissions. Le compte qui exécute l’agent doit pouvoir lire la référence, mais seuls les comptes de déploiement doivent pouvoir la remplacer.
• Préparez le retour arrière. Gardez la version précédente, la preuve de son bon chargement et une procédure de restauration qui ne dépend pas d’un chemin personnel.
• Répétez le test après mise à niveau. Les changements de développement peuvent modifier les chemins, les valeurs par défaut ou les règles de composition ; la release utilisée doit donc être inscrite dans chaque procès-verbal de validation.

Le mot « Cordis » doit ici rester dans son rôle : c’est le cadre de composition sous-jacent, pas un synonyme de preset ni une indication automatique de niveau système. Votre décision porte sur la source du preset et la responsabilité de sa modification ; Cordis explique pourquoi cette composition peut avoir des effets étendus.

SECTION 07Que faire lorsque l’équipe grandit ou que les projets changent

Un modèle utilisateur peut convenir à une petite équipe qui expérimente sur une machine personnelle, puis devenir insuffisant lorsque le même Agent Preset est utilisé sur plusieurs comptes. La croissance de l’équipe introduit trois coûts souvent sous-estimés : la vérification des différences, la récupération après incident et la preuve de la version réellement exécutée.

À ce stade, vous devez déplacer la source de référence vers un artefact système et conserver les variantes personnelles sous des identifiants distincts. Ne cherchez pas à rendre chaque utilisateur identique jusque dans ses préférences ; rendez identiques les éléments qui portent une responsabilité d’équipe.

Pour les projets créatifs, cette séparation est utile. Un monteur vidéo peut avoir un ensemble d’outils différent de celui d’un développeur qui automatise une chaîne de traitement audio, tandis que la base système conserve les services, les limites et les composants exigés par la plateforme. Pour un environnement de design, le même principe évite qu’une extension personnelle modifie silencieusement la base utilisée pour une livraison client.

Si vous préparez un environnement temporaire, vous pouvez d’abord valider le modèle sur un Mac distant MACNOX, puis décider si la charge de gouvernance justifie un achat local ou une infrastructure permanente. La location n’est pas la meilleure réponse pour un service qui exige une charge soutenue stable, des interfaces physiques spécifiques ou une conservation durable de l’état ; elle devient en revanche intéressante pour tester une release, préparer une image d’équipe ou reproduire un incident sans modifier votre poste principal.

La bonne question n’est donc pas seulement « système ou utilisateur ? ». Demandez-vous plutôt quelle source vous pouvez faire confiance, qui assume la modification, comment vous prouvez la priorité en cas de doublon et quelle version vous pouvez restaurer. Si la réponse varie selon les utilisateurs, choisissez la double couche ; si elle doit rester identique pour toute l’équipe, imposez une référence système ; si elle ne concerne que votre expérimentation, gardez-la au niveau utilisateur.