Vous voyez une clé enregistrée dans DeepSeek Harness, mais vous ne savez plus quel compte Mac peut la lire ni comment la remplacer sans interrompre vos tâches.
La solution la plus rapide est de choisir selon l’identité qui exécute le travail : interface Web pour un essai individuel, variable d’environnement pour le SDK Python, injection contrôlée pour les tâches automatisées et compte restreint pour un Mac partagé.
SECTION 01 À qui s’adresse cette décision ?
Cet article vous concerne si vous configurez DeepSeek Harness pour la première fois sur un Mac personnel, si vous maintenez un Mac distant utilisé par plusieurs personnes ou si vous devez formaliser une procédure de rotation après un changement d’équipe.
Il s’adresse également aux responsables sécurité qui veulent répondre à trois questions avant l’exécution : qui possède la clé, qui peut la lire et qui doit la remplacer ou la révoquer ?
SECTION 02 Le calendrier de décision à suivre cette semaine
Ne commencez pas par copier la clé dans le premier champ disponible. Utilisez plutôt cette séquence :
- Aujourd’hui : identifiez le propriétaire réel de la clé et le compte qui lancera DeepSeek Harness.
- Avant le premier essai : choisissez l’interface Web pour une utilisation interactive individuelle, ou une variable d’environnement pour un processus Python ou automatisé.
- Avant tout partage : séparez les comptes administrateur, exécution et consultation sur le Mac distant.
- Avant la mise en production : vérifiez que les journaux, les erreurs, les scripts de démarrage et les historiques de session ne reproduisent pas la valeur secrète.
- Lors d’une rotation : remplacez la credential, testez une nouvelle requête, puis définissez le signal qui doit arrêter les anciennes tâches si l’ancienne clé est révoquée.
Le point important n’est donc pas de savoir quelle méthode paraît la plus simple. Il est de savoir si vous pouvez reconstruire l’environnement, limiter la lecture et effectuer une rotation sans perdre la traçabilité.
SECTION 03 Ce que chaque méthode change réellement
L’interface Web, le fichier de credentials et la variable d’environnement ne sont pas trois copies équivalentes du même mécanisme. Ils déplacent la responsabilité vers des endroits différents.
Avec l’interface Web, vous saisissez la clé dans l’entrée prévue par DeepSeek Harness. D’après le comportement confirmé dans le guide officiel des fournisseurs, la configuration est écrite dans $DSH_HOME/.credentials.yaml. La page ne renvoie ensuite qu’une description masquée et conserve une référence plutôt que d’afficher la valeur complète. Pour un utilisateur seul, ce flux est adapté à un essai interactif, notamment lorsque vous testez un agent de montage vidéo, une analyse de fichiers audio ou une première génération de code sur votre Mac personnel.
Cependant, un fichier non affiché dans l’interface n’est pas un fichier illisible. Le compte système qui possède les droits nécessaires peut potentiellement accéder au fichier, à ses sauvegardes ou au répertoire utilisateur. Vous devez donc limiter les droits du compte, contrôler les copies de sauvegarde et éviter d’exposer l’accès distant au profil personnel.
La variable d’environnement convient mieux à un script qui doit démarrer avec un répertoire de session indépendant. La documentation officielle de l’API DeepSeek utilise une authentification par jeton Bearer, tandis que les exemples Python consultés lisent DEEPSEEK_API_KEY depuis l’environnement du processus. Voir la documentation officielle de l’authentification DeepSeek et l’exemple officiel d’appel depuis Python.
Cette séparation présente trois avantages concrets :
- votre code ne contient pas la valeur secrète ;
- le même script peut fonctionner avec une clé de test, de préproduction ou de production ;
- la rotation peut être réalisée avant le redémarrage du processus, sans modifier le dépôt.
Elle crée aussi des risques spécifiques : une commande export peut apparaître dans l’historique du shell, un fichier .env peut être copié par erreur, et un service lancé par un autre compte peut ne pas recevoir la variable attendue.
Attention : une variable d’environnement n’est pas automatiquement plus sûre qu’un fichier. Elle réduit souvent le risque de commit accidentel, mais elle reste lisible par le processus, ses outils de diagnostic et certains mécanismes de journalisation.
SECTION 04 Comparaison des options selon votre usage
| Usage dominant | Méthode recommandée | Responsable de la lecture | Risque principal à contrôler | Décision |
|---|---|---|---|---|
| Essai individuel dans l’interface Web | Entrée de credentials intégrée | Votre compte Mac | Sauvegarde du profil ou accès distant | Choisissez l’interface si vous êtes l’unique utilisateur |
| Script Python lancé manuellement | DEEPSEEK_API_KEY au démarrage |
Le processus Python | Historique du shell et fichiers .env |
Choisissez l’environnement |
| CI ou tâche distante récurrente | Injection par l’identité d’exécution | Compte ou tâche dédiée | Journaux, erreurs et artefacts | Utilisez une injection limitée au processus |
| Mac partagé par plusieurs personnes | Compte d’exécution séparé | Administrateur désigné et tâche autorisée | Lecture croisée et absence de traçabilité | Évitez la clé commune |
| Projet sensible avec rotation fréquente | Gestion par périmètre de projet | Responsable du projet et sécurité | Révocation trop large | Séparez les clés par responsabilité |
Cette comparaison ne signifie pas qu’il faut éliminer toute écriture locale. Elle signifie que la méthode doit suivre le cycle de vie du travail. Une interaction personnelle et un traitement automatisé n’ont pas le même propriétaire, même s’ils utilisent le même modèle.
SECTION 05 Première étape : attribuer la clé à une identité, pas à une machine
Avant de configurer DeepSeek Harness, inscrivez le propriétaire de la clé dans votre documentation interne, sans jamais y recopier sa valeur. Le propriétaire peut être une personne pour un essai individuel, une équipe pour un projet, ou un compte d’exécution pour une tâche distante.
Évitez la formulation « la clé du Mac de production ». Elle associe un secret à une machine plutôt qu’à une responsabilité. Si le Mac est remplacé, cloné ou accessible par un autre utilisateur, vous ne saurez plus qui devait effectuer la rotation.
Pour chaque clé, notez au minimum :
- le projet ou le centre de coût concerné ;
- le compte qui peut l’utiliser ;
- le type de tâche autorisé ;
- la personne responsable de la rotation ;
- le signal qui déclenche la révocation ;
- la procédure de test après remplacement.
Cette fiche ne doit contenir ni clé complète, ni fichier de credentials intégral, ni capture d’écran montrant la valeur.
SECTION 06 Deuxième étape : configurer un utilisateur Web sans élargir l’accès
Pour un essai personnel, utilisez l’entrée de credentials de DeepSeek Harness plutôt que de coller la clé dans une note, un script ou un réglage de projet. Après l’enregistrement, vérifiez que l’interface affiche seulement une description masquée et que le réglage actif fait référence à la credential sans révéler sa valeur.
Ensuite, contrôlez le contexte local :
- vérifiez que vous êtes connecté au bon compte Mac ;
- confirmez que le répertoire
$DSH_HOMEappartient au bon utilisateur ; - excluez le fichier de credentials des copies de projet et des archives partagées ;
- limitez les sessions distantes au compte nécessaire ;
- lancez une requête de test qui ne transmet pas de données client.
Le dernier point est important pour les usages créatifs. Un test sur une courte piste audio, une image de maquette ou un petit extrait vidéo doit rester un test technique ; il ne doit pas devenir une occasion de déplacer des données sensibles vers une session dont les journaux ne sont pas encore contrôlés.
SECTION 07 Troisième étape : privilégier l’environnement pour le SDK Python
Le SDK Python doit lire DEEPSEEK_API_KEY au lancement, et non recevoir la valeur directement dans le code source. Le principe est le même pour une commande locale, un service lancé par un gestionnaire de processus ou une tâche de traitement vidéo en arrière-plan.
Un schéma minimal peut ressembler à ceci, sans valeur réelle :
import os
api_key = os.environ["DEEPSEEK_API_KEY"]
if not api_key:
raise RuntimeError("Clé API absente")
Dans votre environnement de développement, exportez la variable depuis un mécanisme qui n’est pas versionné. Ne placez pas la commande export DEEPSEEK_API_KEY=... dans un fichier partagé, un script d’installation ou une documentation destinée à toute l’équipe.
Vérifiez également les points souvent oubliés :
- le processus Python reçoit-il réellement la variable ?
- le script imprime-t-il sa configuration en mode débogage ?
- les exceptions incluent-elles les en-têtes ou les paramètres de requête ?
- le gestionnaire de tâches conserve-t-il l’environnement dans un rapport d’erreur ?
- le fichier
.envest-il exclu du dépôt et des pièces jointes ?
La documentation officielle du mode de raisonnement DeepSeek montre également l’usage d’une variable d’environnement pour construire le client Python, ce qui confirme l’intérêt de cette séparation entre le code et la credential.
SECTION 08
Quatrième étape : traiter credentials.yaml comme une donnée sensible
La question « où est enregistrée la clé API DeepSeek Harness ? » ne doit pas conduire à publier le chemin complet dans un script de support. Pour la version vérifiée au moment de la rédaction, l’interface Web utilise $DSH_HOME/.credentials.yaml, mais vous devez confirmer ce comportement lors d’une mise à jour de DeepSeek Harness avant de généraliser la procédure.
Le fichier contient une référence de credential selon le comportement confirmé, et l’interface ne montre qu’une description masquée. Néanmoins, vous devez traiter le fichier et son répertoire comme des données sensibles, car :
- les droits du compte peuvent permettre sa lecture ;
- une sauvegarde peut inclure le fichier même si l’interface ne l’affiche pas ;
- une copie de profil peut transporter la configuration vers un autre Mac ;
- une personne disposant des droits administrateur peut inspecter le stockage local ;
- une restauration peut réactiver une configuration que vous pensiez supprimée.
Ne déduisez donc jamais « non visible » de « non récupérable ». Cette distinction doit apparaître dans votre procédure d’audit et dans la formation des utilisateurs.
SECTION 09 Cinquième étape : injecter la credential selon l’identité d’exécution
Pour une tâche distante, la bonne question n’est pas « sur quel Mac la clé est-elle installée ? », mais « quel compte doit pouvoir l’utiliser pendant cette tâche précise ? ».
Créez une séparation entre :
- le compte administrateur, qui configure l’environnement mais ne lance pas nécessairement les travaux ;
- le compte d’exécution, qui reçoit la credential au moment du lancement ;
- les utilisateurs ordinaires, qui peuvent consulter les résultats autorisés sans lire la clé.
Cette organisation est particulièrement utile pour les compilations, les analyses de code, les traitements audio et les exports vidéo qui continuent après la fermeture d’une session interactive. Si la tâche appartient à un projet client, ne réutilisez pas automatiquement la clé d’un projet interne. Sinon, la rotation d’un seul secret peut interrompre plusieurs activités et rendre impossible l’attribution des appels.
La documentation officielle sur les modèles et les appels DeepSeek rappelle que la configuration dépend du point d’accès et de la credential active ; elle ne constitue pas, à elle seule, un système de séparation des responsabilités.
SECTION 10 Choisir une architecture par conditions
Utilisez les règles suivantes avant de valider votre configuration :
- Si vous êtes seul sur un Mac personnel et que la tâche reste interactive, choisissez l’entrée de credentials de l’interface Web.
- Si le code doit être relancé sur plusieurs environnements, choisissez
DEEPSEEK_API_KEYinjectée au démarrage. - Si une tâche s’exécute sans présence humaine, associez la clé au compte d’exécution plutôt qu’au compte administrateur.
- Si plusieurs personnes utilisent le même Mac distant, créez des comptes ou profils d’exécution séparés ; sinon, reportez le démarrage.
- Si plusieurs projets doivent être facturés ou suivis séparément, ne partagez pas une seule clé par commodité.
- Si vous ne pouvez pas identifier qui lit, remplace et révoque la clé, ne retenez ni le fichier partagé ni l’environnement global de la machine.
- Si la rotation doit être fréquente, préférez une injection externe contrôlée et documentez le redémarrage obligatoire du processus.
- Si vous avez seulement besoin d’un test temporaire, évitez de transformer la credential de test en secret permanent d’un service.
La troisième option, souvent la plus réaliste pour une équipe, est donc une architecture en couches : interface Web pour le compte personnel, variable d’environnement pour les tâches et stockage local limité au compte d’exécution sur le Mac distant.
SECTION 11 Tableau de contrôle avant mise en service
| Point de contrôle | Résultat attendu | Si le contrôle échoue |
|---|---|---|
| Propriétaire identifié | Une personne ou une équipe est responsable | Suspendre la configuration |
| Compte de lecture défini | Le processus et le compte autorisés sont connus | Séparer les comptes |
| Valeur absente du dépôt | Aucun secret dans le code ou les fichiers versionnés | Révoquer puis recréer la clé |
| Journaux inspectés | Pas de clé dans les sorties standard ou erreurs | Réduire le niveau de détail |
| Session de test validée | Une nouvelle requête fonctionne avec la bonne identité | Corriger l’injection |
| Rotation documentée | Responsable, date interne et procédure connus | Ne pas partager la clé |
| Révocation testée conceptuellement | Un signal d’arrêt est défini pour les anciennes tâches | Ajouter une procédure d’arrêt |
SECTION 12 Rotation, remplacement et anciennes sessions
Une rotation correcte suit cinq actions : créer, transmettre, utiliser, remplacer et révoquer. Pour chacune, vous devez désigner un responsable et conserver une preuve opérationnelle, par exemple un ticket interne sans valeur secrète, un identifiant de tâche ou un résultat de test.
Lors du remplacement :
- préparez la nouvelle clé dans le périmètre prévu ;
- injectez-la dans le compte ou le processus concerné ;
- lancez une requête minimale ;
- contrôlez le journal et la session ;
- retirez ou révoquez l’ancienne clé ;
- arrêtez les tâches qui continuent d’utiliser l’ancien contexte.
Ne promettez pas qu’une ancienne session continuera automatiquement. Le changement affecte les nouvelles requêtes qui doivent s’authentifier avec la configuration active, tandis qu’une session déjà ouverte peut conserver un état local jusqu’à sa prochaine interaction réseau. Après une modification de fournisseur ou la suppression d’une credential, vérifiez donc séparément le modèle, l’identifiant du fournisseur et le contenu enregistré dans les sessions.
La documentation officielle du premier appel API DeepSeek confirme que chaque nouvel appel repose sur une clé API et un point d’accès configurés ; utilisez cette référence pour vérifier l’authentification, mais ne l’interprétez pas comme une garantie de continuité des sessions existantes.
SECTION 13 Quand un Mac distant loué devient plus simple à gouverner
Votre solution actuelle peut fonctionner sur un Mac personnel, mais elle devient fragile lorsque la clé est copiée dans plusieurs profils, que les tâches tournent sous des comptes différents et que personne ne sait précisément quel processus doit être arrêté après une révocation. Un poste local partagé ajoute souvent trois défauts : sauvegardes difficiles à contrôler, permissions héritées et rotation qui interrompt des projets sans rapport.
Dans ce contexte, louer un environnement Mac auprès de VPSNIX peut offrir un cadre plus lisible pour les tâches temporaires, les essais de SDK Python, les rendus audio ou vidéo et les sessions distantes, à condition de définir dès le départ le compte d’exécution et le propriétaire de la credential. Consultez la présentation des environnements Mac de VPSNIX avant de choisir, puis vérifiez les conditions adaptées à votre usage dans le centre d’aide de VPSNIX.
Si votre charge est stable, lourde et permanente, l’achat d’un Mac dédié peut rester plus cohérent. Si vous avez besoin d’un accès physique spécifique ou d’une politique interne de secrets déjà imposée, une location ne résoudra pas automatiquement le problème. En revanche, pour un test, une migration, un projet client limité dans le temps ou une tâche distante dont le périmètre doit rester isolé, un environnement loué peut éviter de transformer votre Mac principal en coffre-fort partagé.
Avant de lancer DeepSeek Harness, choisissez donc la méthode qui rend l’ownership et la rotation vérifiables. Vous pouvez ensuite télécharger ou recopier une grille de rotation ne contenant aucune valeur secrète, et ne démarrer l’Agent sur un environnement partagé qu’une fois les comptes, les droits de lecture et le signal d’arrêt clairement définis.
SECTION 14 FAQ
Où DeepSeek Harness conserve-t-il la clé API saisie dans l’interface ?
Selon le guide officiel des fournisseurs vérifié pour cet article, DeepSeek Harness écrit la configuration dans « $DSH_HOME/.credentials.yaml ». L’interface ne réaffiche ensuite pas la valeur complète : elle conserve une référence et renvoie une description masquée. Cela limite l’exposition visuelle, mais ne signifie pas que le fichier est inaccessible au compte système qui l’utilise.
Comment le SDK Python doit-il lire une clé API DeepSeek ?
Pour un script Python, privilégiez la variable d’environnement « DEEPSEEK_API_KEY » lue au démarrage du processus. Cette méthode sépare le code de la credential, facilite le remplacement entre les environnements et évite de modifier le dépôt. Ne committez ni la commande export, ni un fichier de démarrage contenant la valeur réelle.
Plusieurs personnes peuvent-elles utiliser la même clé sur un Mac distant ?
C’est techniquement possible, mais rarement acceptable pour une équipe. Une clé commune empêche d’attribuer précisément les appels, complique la rotation et peut interrompre des projets sans rapport lorsqu’elle est révoquée. Sur un Mac partagé, associez plutôt chaque credential à un compte d’exécution ou à un périmètre de tâche clairement identifié.
Une nouvelle clé permet-elle de poursuivre une ancienne session ?
Le remplacement d’une clé agit surtout sur les nouvelles requêtes lancées avec la configuration active. Une session déjà ouverte peut toutefois dépendre de son état local, de son processus et de la prochaine requête réseau. Après rotation, vérifiez donc séparément les anciennes sessions, leurs journaux et l’identifiant du modèle ou du fournisseur enregistré.