Le contrôle à distance de DeepSeek Harness depuis un téléphone fonctionne-t-il directement en 2026 ?

Une application communautaire Android appelée DeepSeek Harness Mobile propose actuellement un compagnon distant avec affichage des sessions, objectifs, validations et notifications sur le réseau local. Sa version publiée le 18 août 2026 indique une compatibilité testée avec DeepSeek Harness 0.1.0-rc.7 et Android 8 ou version ultérieure. Ce sont des informations déclarées par le projet communautaire, pas par l’équipe officielle de DeepSeek Harness. (github.com)

Le dépôt officiel, lui, documente surtout l’exécution du framework et son interface Web. La commande publiée démarre l’interface sur http://127.0.0.1:3080 par défaut. Le README officiel ne présente pas d’application mobile native comme point d’entrée pris en charge. (github.com)

Il faut également distinguer l’application mobile officielle DeepSeek, qui synchronise l’historique de conversations du service de chat, d’un client capable de contrôler un agent DeepSeek Harness exécutant des fichiers, des commandes ou des outils sur votre Mac. L’existence de la première ne prouve pas l’existence de la seconde. (api-docs.deepseek.com)

La première limite est donc sémantique. Une interface qui ressemble à la Web UI ne garantit pas que le téléphone soit une extension officielle du runtime. La deuxième est fonctionnelle. Le projet mobile peut interpréter certains événements différemment selon la version installée. La troisième est opérationnelle. Une alerte contenant le nom du dépôt, le texte d’une invite ou le résultat d’un outil peut déjà révéler des informations sensibles, même si vous n’autorisez aucune action.

La consultation en lecture seule est le meilleur point de départ. Elle paraît inoffensive, mais elle peut exposer davantage que le titre de la tâche. Selon l’architecture du client, la charge utile affichée peut contenir le nom du dépôt, le chemin d’un fichier, une portion d’invite, la réponse de l’agent, le résultat d’une commande ou le détail d’une question en attente.

Vous devez donc distinguer trois niveaux de lecture :

Avant toute connexion, créez un projet de test sans clé privée, sans fichier client et sans accès aux répertoires de production. Lancez une tâche qui lit uniquement un fichier factice. Vérifiez ensuite ce qui apparaît dans la notification, la liste et le détail de session.

La question « DeepSeek Harness permet-il de consulter une tâche en arrière-plan depuis un téléphone ? » reçoit donc une réponse conditionnelle. Oui, un client communautaire peut afficher l’état d’une tâche si le runtime reste accessible et si le protocole attendu correspond. Non, vous ne devez pas considérer cet affichage comme une preuve de fiabilité du traitement, de l’ordre des événements ou de la confidentialité des données.

Le nombre d’étoiles d’un dépôt ne permet pas d’établir sa sécurité. Cherchez plutôt un historique de versions, une documentation des limites, une politique de sécurité, un tableau de compatibilité et des corrections décrivant les erreurs silencieuses.

Le projet DeepSeek Harness Mobile documente plusieurs corrections importantes dans sa version 0.4.0. Une réponse saisie dans une carte de question pouvait auparavant être ignorée avant son envoi au modèle. D’autres problèmes concernaient les réponses multiples, l’annulation et les questions affichées simultanément. Le projet indique que ces comportements ont été corrigés et que la version a été testée avec DeepSeek Harness 0.1.0-rc.7. (github.com)

Ces détails sont significatifs. Ils montrent qu’une interface mobile peut afficher « succès » alors que l’agent n’a pas reçu la réponse attendue. Ce n’est pas un simple défaut visuel. Pour un agent distant, une réponse perdue peut laisser une tâche bloquée, déclencher une reprise manuelle ou vous pousser à envoyer une seconde validation qui n’est plus nécessaire.

Android pose aussi un problème de distribution. Une application installée depuis une source externe doit être vérifiée par son empreinte, son historique de versions et ses permissions. Le dépôt communautaire publie un fichier de somme de contrôle avec son paquet Android, mais cela ne remplace ni une revue du code ni une analyse du trafic réseau. (github.com)

Pour iOS, la prudence doit être encore plus stricte si aucun client équivalent n’est officiellement annoncé. Une page Web ouverte dans Safari n’est pas automatiquement une application native, et une interface Web adaptée au mobile ne démontre pas que les validations, notifications et reconnexions ont été conçues pour un écran tactile.

Continuer une conversation depuis le téléphone ne revient pas seulement à consulter un tableau de bord. Une invite ajoutée peut modifier l’objectif en cours. Un changement de modèle peut altérer la stratégie de l’agent. Une réponse à une question peut autoriser une écriture alors que la tâche originale semblait limitée à une analyse.

Vous devez vérifier quatre relations avant d’autoriser la moindre reprise :

1. Le téléphone et le bureau affichent-ils le même identifiant de session ?
2. Le message saisi sur mobile apparaît-il une seule fois sur le bureau ?
3. La reconnexion reprend-elle le dernier état confirmé ou renvoie-t-elle une ancienne carte ?
4. Une réponse envoyée pendant une coupure est-elle rejetée, mise en attente ou appliquée deux fois ?

L’apparence synchronisée ne suffit pas. Une interface peut recevoir un événement de mise à jour sans garantir que l’action correspondante a été traitée par le runtime. La causalité doit être vérifiée avec une tâche contrôlée : demandez à l’agent de créer un marqueur temporaire, envoyez une seule instruction depuis le téléphone, puis contrôlez le journal côté bureau.

Si vous modifiez l’objectif depuis un téléphone dans un train, un café ou un réseau cellulaire instable, prévoyez une procédure de récupération. Ne renvoyez pas immédiatement l’invite après un délai d’affichage. Attendez d’abord la confirmation côté bureau. Un mécanisme de nouvelle tentative réseau peut donner l’impression que le premier message a échoué alors qu’il a déjà été exécuté.

Rappel de runbook : une notification arrivée sur votre téléphone prouve seulement qu’un événement a été transmis. Elle ne prouve ni que l’agent est encore dans le même état, ni que la dernière action est terminée.

La validation est le point où le contrôle mobile devient un véritable accès de commande. Un bouton « autoriser » peut permettre une écriture de fichier, l’exécution d’une commande, l’appel d’un outil externe ou une modification persistante. Sur un petit écran, le risque vient souvent du contexte manquant : chemin tronqué, commande partiellement visible, objectif initial non affiché ou résultat précédent masqué.

Pour chaque carte de validation, vous devez retrouver au minimum :

• l’identité de la session et du projet ;
• l’action exacte, sans troncature ;
• le chemin ou la ressource ciblée ;
• le niveau de conséquence attendu ;
• l’option de refus ;
• le délai d’expiration ;
• l’état de la demande après une nouvelle tentative.

Une validation refusée doit rester refusée. Une validation expirée ne doit pas être automatiquement convertie en accord. Une demande répétée après une reconnexion doit être identifiable comme nouvelle ou déjà traitée. Testez ces trois scénarios avec une tâche sans valeur : autorisez une action sans danger, refusez la suivante, puis coupez la connexion avant la troisième.

Le contrôle mobile d’un agent distant n’est pas sûr simplement parce qu’il propose des boutons de confirmation. La sécurité dépend de la qualité de l’information affichée et de la manière dont le serveur traite les doublons, les délais et les changements de session.

Le terme « réseau local » recouvre au moins trois périmètres différents :

Le dépôt officiel indique que la Web UI écoute sur 127.0.0.1:3080 par défaut. Pour atteindre cette adresse depuis un téléphone, il faut modifier le périmètre d’écoute ou interposer un mécanisme d’accès. Cette modification n’est pas la configuration officielle par défaut. (github.com)

Ne suivez pas une procédure qui consiste uniquement à écouter sur toutes les interfaces et à transférer un port vers Internet. Elle peut exposer les tâches, les résultats d’outils et les contrôles de l’agent sans authentification suffisante. Elle transforme un outil personnel en surface de commande distante.

Avant un essai sur réseau privé, cochez chaque point :

• [ ] Le Mac de test n’héberge aucun dépôt sensible.
• [ ] Le téléphone et le Mac sont sur un réseau que vous contrôlez.
• [ ] L’identité de l’utilisateur est vérifiée, et non seulement l’adresse IP.
• [ ] Le transport est chiffré si les données quittent la machine.
• [ ] Les journaux indiquent qui a consulté ou validé une action.
• [ ] Vous pouvez révoquer l’accès sans arrêter tout l’environnement.
• [ ] Une coupure réseau ne provoque pas de nouvelle validation automatique.

Si une seule case reste indéterminée, revenez à un accès de bureau contrôlé ou à un tunnel administré. Le but n’est pas de rendre le test impossible, mais de conserver un périmètre réversible.

Pour un usage personnel, vous pouvez accepter un environnement isolé et une vérification manuelle. Pour une équipe, le problème change. Il faut identifier chaque utilisateur, définir ses droits, conserver un audit et retirer rapidement un appareil perdu ou compromis.

Un lien partagé qui permet à plusieurs personnes d’ouvrir le même Harness ne constitue pas une gestion des rôles. Il ne permet pas de savoir qui a approuvé une commande. Il ne limite pas forcément les actions selon le projet. Il complique également la révocation : changer un secret commun oblige à reconnecter tout le monde, tandis qu’un appareil oublié peut rester autorisé.

Pour comparer les options de poste local, de Mac distant et d’accès mobile, vous pouvez consulter la présentation des environnements Mac distants. Cette comparaison aide à séparer la machine de test, le bureau utilisé pour l’audit et le téléphone réservé au suivi limité. L’architecture d’accès doit toutefois être validée indépendamment du client mobile, notamment pour l’identité, le chiffrement et la révocation.

1. Créez une session sans conséquence

Utilisez un dépôt de démonstration et un fichier factice. Interdisez les clés d’API persistantes, les répertoires personnels et les commandes destructives. Notez l’identifiant de session affiché sur le bureau.

2. Mesurez ce que le téléphone reçoit

Comparez la notification, la liste de sessions et la conversation détaillée. Relevez les chemins, les noms de fichiers, les résultats d’outils et les invites transmis. Si le client affiche plus de données que prévu, arrêtez le test.

3. Vérifiez l’identité de la session

Envoyez une instruction distincte depuis le bureau et le téléphone. Confirmez que les deux messages arrivent dans le même ordre et une seule fois. Ne vous fiez pas uniquement au titre de la conversation.

4. Testez les validations négatives

Refusez une demande. Laissez-en une autre expirer. Provoquez une reconnexion pendant une troisième. Contrôlez ensuite le journal côté runtime pour vérifier qu’aucune action n’a été exécutée malgré le refus ou l’expiration.

5. Fermez le périmètre réseau

Commencez par la boucle locale, poursuivez sur un réseau privé contrôlé, puis arrêtez-vous avant toute exposition publique. Documentez l’adresse d’écoute, le mode d’authentification, le chiffrement et la procédure de révocation.

Utilisez les conditions suivantes plutôt qu’un avis général sur l’application :

• Si vous avez un environnement isolé, aucune donnée sensible, un client dont la version est documentée et une authentification vérifiable, alors choisissez le niveau « lecture seule ».
• Si la lecture est correcte, que l’identifiant de session est confirmé et que les refus, expirations et doublons sont testés, alors ajoutez seulement des interactions réversibles.
• Si l’application affiche une commande tronquée, si la reconnexion est ambiguë ou si l’accès repose sur un secret partagé, alors revenez à la Web UI depuis un poste contrôlé.
• Si vous ne pouvez pas identifier chaque utilisateur ou révoquer un appareil, alors ne partagez pas l’instance avec une équipe.
• Si la seule manière de connecter le téléphone consiste à exposer un port sans authentification démontrée, alors n’ouvrez pas l’accès public.
• Si votre tâche touche un dépôt client, des secrets, une publication ou une modification irréversible, alors exigez un environnement où vous pouvez examiner toutes les preuves, et non une carte mobile réduite.

La conclusion opérationnelle est donc la suivante :

Vous pouvez revoir cette décision lorsqu’un changement précis apparaît, et non lorsqu’une application gagne simplement en visibilité. Surveillez l’ajout d’une prise en charge mobile dans la documentation officielle, une matrice de compatibilité couvrant les versions récentes, une description claire de l’authentification et des correctifs concernant les validations répétées.

Le client communautaire consulté documente une compatibilité avec DeepSeek Harness 0.1.0-rc.7. Cette indication ne garantit pas la compatibilité avec une version ultérieure, surtout lorsque le dépôt officiel prévient que des changements incompatibles peuvent survenir pendant la préversion développeur. (github.com)

Vous devez aussi contrôler les fichiers README, Release, SECURITY et la matrice de compatibilité avant chaque mise à jour. Une nouvelle version du mobile peut corriger un problème d’affichage tout en changeant la manière dont une réponse ou une validation est envoyée.

Par rapport à une Web UI ouverte directement sur votre poste actuel, le contrôle mobile ajoute trois défauts réels : le contexte est réduit, la reconnexion peut masquer l’état de la tâche et l’identité de l’utilisateur est souvent moins claire. Par rapport à un Mac local, votre poste peut également être éteint, inaccessible derrière un routeur ou difficile à isoler lorsque vous êtes en déplacement. Pour un essai ponctuel, un environnement Mac distant administré par CALMVPS offre un cadre plus prévisible : vous pouvez séparer la machine de test, garder le bureau comme point d’audit et n’utiliser le téléphone que pour une consultation limitée. Cela ne rend pas automatiquement une application mobile sûre, mais cela évite de placer un agent expérimental au cœur de votre poste principal.

Avant de connecter DeepSeek Harness Mobile, consultez notre guide sur l’accès Web distant sécurisé et la validation des tâches en arrière-plan, puis utilisez le mobile uniquement comme interface d’essai tant que les preuves de session, d’autorisation et de révocation ne sont pas complètes.