Comment configurer OpenTelemetry dans DeepSeek Harness en 2026 sans divulguer les sessions ?

Le protocole OTLP/HTTP réserve le chemin /v1/logs aux journaux et recommande de limiter la taille d’une requête à 64 MiB avant son traitement côté serveur (spécification OTLP officielle). Cela suffit à établir le bon ordre de mise en œuvre : la configuration OpenTelemetry de DeepSeek Harness doit rester sur DISABLED tant que vous n’avez pas classifié les données, protégé le point de terminaison OTLP et défini la suppression côté réception. Si un besoin de retour utilisateur existe, passez d’abord par FEEDBACK_ONLY, puis n’évaluez FULL qu’après un test d’envoi, d’échec, d’arrêt et de récupération.

Cette méthode s’applique aux équipes qui doivent observer des agents sur un Mac distant sans exporter par inadvertance des conversations, des résultats d’outils ou des chemins de dépôt. Elle concerne aussi les responsables sécurité qui doivent valider ce qui quitte l’environnement d’exécution, ainsi que les équipes d’exploitation chargées de remettre un poste propre à la fin d’une location ou d’un transfert.

SECTION 01 Pourquoi la télémétrie d’une session ne se traite-t-elle pas comme un journal classique ?

Un journal système décrit généralement un événement technique : démarrage d’un processus, code de retour, durée d’une requête ou erreur réseau. Une télémétrie de session d’agent peut toutefois se trouver à la frontière entre l’événement et le contenu métier. Elle peut inclure, selon la version du logiciel et le mode activé :

l’identifiant ou le statut d’une session ;
le texte saisi par l’utilisateur ou une partie de l’instruction active ;
la sortie d’un outil, notamment une commande, une réponse d’API ou un extrait de fichier ;
des chemins locaux, noms de dépôts, noms de projets ou identifiants de compte ;
des retours de l’utilisateur servant à améliorer le comportement de l’agent ;
des informations de diagnostic permettant de reconstruire la chronologie d’une tâche.

Le fait qu’un événement soit envoyé via OpenTelemetry ne le rend donc pas automatiquement anonyme. OpenTelemetry définit un modèle et un protocole de transport ; il ne décide pas si un champ est acceptable pour votre politique de confidentialité. La documentation de configuration montre d’ailleurs que l’exporteur peut recevoir un point de terminaison et des en-têtes d’authentification, tandis que la sélection des données instrumentées dépend de l’application et du kit logiciel utilisé (configuration officielle OpenTelemetry).

Avant toute activation, créez une fiche de classification avec quatre colonnes :

Donnée candidate : session, outil, entrée utilisateur, erreur, métadonnée ;
Propriétaire : équipe produit, client, sécurité, exploitation ;
Usage autorisé : diagnostic, mesure de qualité, analyse de panne ou aucun ;
Interdiction explicite : secret, contenu client, code source, chemin interne, jeton ou donnée personnelle.

Si le propriétaire ne peut pas confirmer l’usage autorisé, la décision opérationnelle est simple : conserver DISABLED. Ne remplacez pas une incertitude de gouvernance par un filtre supposé efficace.

DeepSeek Harness téléverse-t-il automatiquement la télémétrie de session ?
Ne répondez pas par une règle générale. Vérifiez le catalogue de configuration et le code de la version réellement déployée. Le catalogue mentionne trois politiques de partage — DISABLED, FEEDBACK_ONLY et FULL — ainsi qu’un exporteur de journaux OTLP/HTTP ; il ne faut pas en déduire que les champs exacts ou le comportement par défaut resteront identiques dans toutes les versions. Le dépôt de référence expose également la structure de l’agent, la persistance de session et les composants de transport, ce qui justifie une vérification versionnée plutôt qu’une lecture d’un ancien billet (dépôt et documentation DeepSeek Harness).

SECTION 02 Première étape : verrouiller la politique de partage avant le réseau

Les trois modes ne sont pas des niveaux de détail d’un même journal. Ils correspondent à des politiques différentes de partage :

DISABLED : aucun besoin d’export de télémétrie de session n’est assumé. C’est le choix de départ pour une nouvelle installation, un environnement client non classifié ou un poste qui doit être remis rapidement ;
FEEDBACK_ONLY : vous cherchez à recueillir un retour limité lié à l’évaluation de l’agent, sans ouvrir toute la surface de données d’une session ;
FULL : vous acceptez une collecte plus large, potentiellement utile pour diagnostiquer les interactions entre modèle, outils, entrées et résultats, mais qui exige une classification et une rétention beaucoup plus strictes.

La décision ne doit pas être prise uniquement par l’administrateur du Mac. Définissez une personne ou un groupe autorisé à changer le mode, consignez la justification, puis imposez une revue lorsque le modèle, le connecteur, l’équipe utilisatrice ou le point de terminaison change.

Pour un pilote audio, vidéo ou design, FEEDBACK_ONLY peut suffire si votre objectif est de comparer la qualité de l’assistance ou de repérer les échecs d’orchestration. À l’inverse, une enquête sur une commande qui lit des fichiers, lance une conversion vidéo ou interroge un dépôt peut exposer bien plus que le retour final. Dans ce cas, un environnement synthétique est préférable à une session réelle.

Quelle différence entre FEEDBACK_ONLY et FULL ?
FEEDBACK_ONLY doit être traité comme une collecte restreinte par finalité, pas comme une promesse d’absence de contenu. FULL élargit la surface d’observation et doit donc être soumis à une approbation distincte. Dans les deux cas, vous devez demander à la version déployée quels attributs sont effectivement produits, puis confirmer le résultat sur le point de réception. Une politique interne peut décider que FULL est interdit pour les espaces contenant du code client, même si le transport est chiffré.

Ajoutez ce contrôle à votre dossier de changement :

mode choisi et objectif du pilote ;
propriétaire de la décision ;
catégories de données autorisées ;
catégories explicitement interdites ;
durée du test ;
responsable de la suppression ;
procédure de retour à DISABLED.

Une fois cette étape approuvée, vous pouvez seulement préparer un point de terminaison de test isolé. Ne branchez pas directement un collecteur de production.

SECTION 03 Deuxième étape : créer un point de terminaison OTLP isolé et vérifiable

Pour des journaux OTLP/HTTP, le chemin conventionnel est /v1/logs, et l’URL complète doit être fournie à l’exporteur lorsque vous ne souhaitez pas utiliser la valeur locale par défaut (schéma officiel des exporteurs OTLP). Vous devez également décider si le serveur accepte le format protobuf binaire ou JSON, s’il impose TLS, comment il authentifie les requêtes et combien de temps il conserve les événements.

Un exemple de configuration volontairement incomplet peut ressembler à ceci :

telemetry:
  sharing_mode: FEEDBACK_ONLY
  exporter:
    protocol: otlp_http
    endpoint: https://otel-test.example.invalid/v1/logs
    headers:
      Authorization: ${OTEL_AUTH_PLACEHOLDER}
    tls:
      verify_peer: true
    timeout: ${OTEL_TIMEOUT_PLACEHOLDER}

Cet exemple ne constitue pas un schéma universel : utilisez les noms de clés du catalogue de votre version. Ne copiez jamais un véritable en-tête dans un article, un ticket ou un dépôt. Stockez le secret dans le mécanisme de variables sécurisé de votre orchestration, avec une autorité différente pour la lecture et la modification lorsque votre modèle de menace le justifie. L’authentification de l’API DeepSeek elle-même repose sur un schéma Bearer, mais cette clé ne doit pas être réutilisée comme secret d’un collecteur OTLP (documentation officielle de l’API DeepSeek).

Le test initial doit utiliser une session artificielle :

créez un espace de travail sans dépôt réel ;
saisissez un texte sans donnée personnelle ni secret ;
exécutez un outil inoffensif qui produit une sortie prévisible ;
activez le mode approuvé et l’exporteur de test ;
vérifiez l’URL réellement contactée depuis le Mac ;
comparez le nombre d’événements émis avec les enregistrements reçus ;
recherchez les champs inattendus avant de poursuivre.

Le point important n’est pas uniquement que le serveur reçoive quelque chose. Vous devez établir la correspondance entre la session locale, le lot envoyé et l’événement reçu, sans transmettre un identifiant qui permettrait de relier durablement un utilisateur à son contenu si ce lien n’est pas nécessaire.

Attention : TLS protège le trajet entre le Mac et le collecteur, mais ne supprime pas les données présentes dans le message. Un collecteur compromis, mal configuré ou conservant les journaux trop longtemps reste une fuite possible.

Pour les équipes qui centralisent l’observation de plusieurs postes, placez le collecteur derrière une sortie réseau explicitement autorisée, limitez les destinations et journalisez les connexions sans enregistrer le secret. La documentation des fonctions de reprise de l’exporteur OpenTelemetry Collector montre que les files d’attente, délais d’attente et reprises sont des fonctions configurables du collecteur ; elles ne doivent pas être attribuées automatiquement à DeepSeek Harness sans vérification du composant concerné.

SECTION 04 Que faut-il vérifier avant d’élargir vers `FULL` ?

Le passage de FEEDBACK_ONLY à FULL doit être un jalon distinct, avec un nouveau jeu de données de test. Les équipes font souvent trois erreurs :

elles vérifient uniquement le texte visible de la réponse et oublient les sorties d’outils ;
elles filtrent les messages mais laissent passer les chemins locaux, les noms de dépôts ou les attributs de transport ;
elles activent la collecte sur un Mac contenant des données réelles avant d’avoir observé le comportement d’erreur.

Organisez un test par catégories :

entrée utilisateur : texte neutre, texte contenant un faux secret, texte contenant un chemin fictif ;
résultat d’outil : sortie courte, erreur contrôlée, nom de fichier synthétique ;
contexte de dépôt : dépôt de démonstration sans contenu confidentiel ;
retour utilisateur : commentaire positif, commentaire négatif et absence de commentaire ;
panne réseau : résolution impossible, refus TLS, réponse HTTP non réussie ;
arrêt normal : fermeture de l’agent, arrêt du service et extinction du Mac.

Le faux secret doit être inutilisable et ne doit pas reprendre le format d’un jeton actif. L’objectif est de repérer la présence d’un champ, non de tester vos propres secrets en les exposant.

Les journaux OTLP contiennent-ils les résultats des outils et les chemins locaux ?
La réponse dépend du plugin et de la version de DeepSeek Harness. OpenTelemetry permet de transporter des attributs et des enregistrements de journal, mais la spécification ne définit pas le contenu métier de votre agent. Vous devez donc inspecter le schéma de l’extension, la sérialisation et le contenu reçu. Tant que vous ne pouvez pas exclure les résultats d’outils, les chemins de dépôt et les entrées utilisateur, ne classez pas FULL comme « sans contenu ».

Sur le plan du transport, la spécification OTLP indique que les réponses 429, 502, 503 et 504 sont généralement considérées comme récupérables, tandis qu’une réponse 400 ne doit pas être réessayée, car elle indique normalement une requête invalide ou des données impossibles à décoder (règles OTLP/HTTP officielles). Cela décrit le protocole, pas nécessairement la politique interne de DeepSeek Harness.

Un échec d’envoi OTLP peut-il interrompre la tâche de l’agent ?
Ne l’affirmez pas sans test. Il faut déterminer si l’exportation est synchrone ou différée, si l’agent attend la confirmation du collecteur, si le lot est mis en mémoire et si une erreur est seulement journalisée localement. La documentation générale d’OpenTelemetry précise que la mise en file et la reprise sont souvent fournies par des composants auxiliaires ou par le kit logiciel, et non garanties par le protocole seul (recommandations pour les bibliothèques OpenTelemetry).

Pendant le test, observez séparément :

le code de sortie de la tâche agent ;
la réponse affichée à l’utilisateur ;
l’état du processus ;
le nombre d’événements reçus ;
le contenu resté localement ;
le délai supplémentaire avant la fin.

Ne publiez pas un nombre de tentatives ou une durée de conservation comme s’il s’agissait d’un comportement universel. Si votre version ne documente pas le nombre de reprises, écrivez « comportement non garanti » dans le dossier d’exploitation et imposez un test de régression après mise à jour.

SECTION 05 Troisième étape : passer sur un Mac distant avec un contrat d’arrêt explicite

Un Mac distant ajoute des risques qui n’existent pas dans un poste de développement local. Le service peut être arrêté par une fermeture de session, une commande d’orchestration, une expiration de location ou une coupure d’alimentation. Dans chacun de ces cas, les événements déjà produits peuvent se trouver dans une file mémoire, un fichier temporaire ou un tampon de l’exporteur.

Avant le transfert, définissez un arrêt ordonné :

bloquer le démarrage de nouvelles sessions ;
attendre la fin des tâches agent encore autorisées ;
désactiver le mode de partage et revenir à DISABLED ;
demander au processus d’exportation de terminer son cycle d’export ;
enregistrer le résultat de la vidange ;
vérifier les fichiers temporaires et journaux locaux ;
arrêter le service ;
révoquer le secret du point de terminaison ;
demander au propriétaire du collecteur de supprimer les événements reçus ;
joindre les preuves au procès-verbal de remise.

Comment fermer la télémétrie avant de remettre un Mac distant ?
Ne vous contentez pas de supprimer une variable d’environnement. Modifiez la politique persistante de DeepSeek Harness, redémarrez le service pour confirmer qu’il relit bien DISABLED, révoquez le secret côté réception et contrôlez le trafic sortant après l’arrêt. La suppression côté Mac ne supprime pas automatiquement les données déjà reçues par le collecteur.

Le paramètre d’arrêt ou de délai doit être contrôlé dans la documentation et le code de la version installée. Si le catalogue officiel expose un délai de fermeture, utilisez cette valeur comme borne de planification, mais vérifiez sur le Mac distant que le processus termine réellement son export. Un arrêt brutal ne doit jamais être présenté comme une garantie de livraison ou de suppression.

Pour vos procédures, séparez clairement trois responsabilités :

l’équipe qui exploite le Mac : arrêt, nettoyage local et retrait du secret ;
l’équipe qui gère le collecteur : recherche, conservation et suppression des événements ;
le responsable de la donnée : confirmation que la suppression répond à l’obligation interne ou contractuelle.

Cette séparation est particulièrement importante lorsque vous fournissez un environnement temporaire pour une production vidéo, une session de design, une compilation ou une analyse de dépôt. La politique de confidentialité de VPSNIX peut compléter votre propre registre, mais elle ne remplace pas la procédure de suppression du collecteur que vous avez choisi.

SECTION 06 La checklist de décision avant activation

Utilisez cette liste comme jalon de changement. Une case non cochée signifie que le mode doit rester DISABLED.

[ ] Le propriétaire de chaque catégorie de donnée a été nommé.
[ ] Les entrées utilisateur, sorties d’outils, chemins, noms de dépôts et retours ont été classifiés séparément.
[ ] Le mode choisi est justifié par un objectif précis et documenté.
[ ] La personne autorisée à modifier la politique est identifiée.
[ ] Le point de terminaison OTLP de test est isolé de la production.
[ ] Le chemin /v1/logs, le protocole et le format attendus ont été vérifiés.
[ ] TLS valide et vérification du certificat sont activés.
[ ] Le secret est injecté sans apparaître dans le dépôt, l’écran ou les journaux.
[ ] Une session synthétique a été envoyée et comparée aux événements reçus.
[ ] Les champs sensibles potentiels ont été recherchés dans le contenu reçu.
[ ] Une panne DNS ou réseau a été testée.
[ ] Une réponse d’erreur non récupérable a été testée sans inventer de politique de reprise.
[ ] Le comportement de la tâche agent pendant l’échec est connu.
[ ] L’arrêt normal et la vidange de l’exporteur ont été observés.
[ ] Le retour à DISABLED a été vérifié après redémarrage.
[ ] La révocation du secret et la suppression côté collecteur ont un responsable.
[ ] Le dossier de livraison contient la version, le mode, le point de terminaison masqué et les preuves d’arrêt.

Si les cinq dernières cases ne peuvent pas être validées, n’élargissez pas la collecte, même si le test fonctionnel semble réussi. La visibilité gagnée ne compense pas une chaîne de conservation inconnue.

SECTION 07 Ce que vous devez choisir cette semaine

Le choix recommandé pour une nouvelle plateforme reste DISABLED. Si vous avez besoin de comprendre la qualité des retours ou les échecs d’orchestration, utilisez un environnement synthétique et essayez FEEDBACK_ONLY. Réservez FULL aux équipes capables d’examiner les champs, de contrôler l’accès au collecteur, de limiter la rétention et de prouver la suppression.

Votre solution actuelle — un Mac local partagé, un poste Windows ou Linux adapté, ou une machine virtuelle cloud — peut sembler plus simple au départ, mais elle présente souvent des défauts concrets : sortie réseau mal documentée, secrets dispersés dans plusieurs scripts, absence de procédure d’arrêt unifiée et difficulté à prouver ce qui a été supprimé après la fin d’une session. Pour un pilote temporaire, un Mac distant administré avec un inventaire d’accès, une sortie réseau contrôlée et une remise documentée offre un cadre plus facile à auditer.

Si vous devez concentrer l’exploitation de plusieurs environnements DeepSeek Harness sans immobiliser un poste de développement, consultez les offres de Mac distant de VPSNIX, puis utilisez le centre d’aide VPSNIX pour préparer les contrôles de connectivité et de restitution. La location ne remplace pas votre classification des données : elle devient intéressante lorsque vous avez besoin d’une capacité temporaire, d’un environnement de test séparé ou d’un Mac à remettre proprement après l’expérimentation.