DeepSeek Harness Plan Mode : planifier ou exécuter ?

Le premier critère n’est pas la longueur de la demande, mais la réversibilité réelle de la modification. Une demande apparemment courte peut toucher une configuration partagée, une génération automatique ou une interface publique ; à l’inverse, plusieurs changements locaux peuvent rester faciles à annuler lorsqu’un test automatique existe déjà.

L’exécution directe convient généralement lorsque les conditions suivantes sont réunies :

• un seul fichier ou un périmètre clairement isolé est concerné ;
• la modification ne touche ni les secrets, ni les dépendances, ni la configuration de production, ni le schéma de données ;
• un commit ou un diff permet de revenir en arrière sans reconstituer manuellement l’état précédent ;
• la commande de validation est connue avant le lancement ;
• le responsable de l’acceptation finale est identifié.

Un renommage local, une correction de typographie dans une interface, l’ajout d’un test ciblé ou une petite adaptation CSS dans un projet audio, vidéo ou design peuvent donc rester en exécution directe, à condition que le dépôt soit déjà compris et que le résultat soit immédiatement contrôlable.

La documentation officielle de DeepSeek précise que le mode de réflexion peut être activé ou désactivé séparément et que les appels d’outils nécessitent une gestion correcte du champ reasoning_content dans les échanges suivants (documentation officielle sur le mode de réflexion). Cette information concerne le protocole du modèle, non une garantie automatique sur les permissions de votre harness. Il faut donc éviter de transformer un comportement observé dans une version de développement en règle permanente.

Contrôle à cocher avant l’exécution directe

• [ ] Le périmètre de fichiers est explicitement limité.
• [ ] Le retour arrière peut être réalisé avec un commit ou un diff.
• [ ] Aucun secret ou fichier de production n’est nécessaire.
• [ ] La commande de test est connue et disponible.
• [ ] Le résultat attendu peut être vérifié sans nouvelle enquête.
• [ ] Une personne identifiée accepte la livraison.

DeepSeek Harness Plan Mode modifie-t-il réellement le code ?
Il ne faut pas répondre par un « oui » ou un « non » universel sans vérifier la version utilisée. Le rôle documenté d’un mode de planification est de séparer l’exploration, la rédaction du plan et l’autorisation d’exécuter. Toutefois, l’existence du mode ne prouve pas à elle seule que chaque outil d’écriture, chaque commande shell ou chaque plugin est bloqué dans toutes les configurations.

La vérification doit porter sur la liste effective des outils et sur les permissions actives dans le workspace. Un test sur un dépôt jetable peut confirmer qu’un fichier hors périmètre ne peut pas être écrit avant approbation. Il faut également conserver la version du harness, le commit utilisé et la configuration examinée, car le dépôt de référence de DeepSeek Harness peut évoluer plus rapidement qu’une procédure interne.

Pour un mainteneur qui découvre un dépôt, l’erreur la plus coûteuse consiste à confondre un plan plausible avec une compréhension suffisante du code. Avant toute écriture, l’agent doit établir au minimum :

1. le point d’entrée de l’application ou du service ;
2. les modules qui consomment la fonctionnalité ciblée ;
3. les fichiers de configuration et les variables d’environnement nécessaires ;
4. les dépendances directes et les générateurs éventuellement impliqués ;
5. la commande exacte de test, de compilation ou de prévisualisation ;
6. les contraintes locales inscrites dans les fichiers d’instructions du projet ;
7. l’état initial de la branche et les modifications déjà présentes.

Cette phase répond à une difficulté souvent sous-estimée : un plan peut être correctement rédigé tout en reposant sur une hypothèse erronée concernant l’architecture. Dans une application vidéo, par exemple, le composant visible à l’écran peut être généré depuis un modèle ou alimenté par une couche de données distincte. Dans un outil audio, le fichier apparemment central peut n’être qu’un artefact produit par un script. La lecture seule doit donc suivre les dépendances, et non seulement rechercher le mot-clé de la demande.

Le plan ne doit être considéré comme prêt à l’exécution que s’il contient des éléments qu’un autre intervenant peut vérifier sans refaire toute l’enquête :

• chemins de fichiers concernés ;
• symboles, fonctions ou composants à modifier ;
• hypothèses encore non confirmées ;
• tests existants et tests à ajouter ;
• effets possibles sur les interfaces publiques ;
• données qui ne doivent jamais être lues ou exportées ;
• condition explicite de retour arrière.

Les appels d’outils constituent ici un point technique important. La documentation officielle de DeepSeek sur les appels d’outils indique que, lorsqu’un tour implique un outil, le champ reasoning_content doit être correctement renvoyé dans les requêtes suivantes. Une intégration qui perd cet état peut interrompre la boucle avec une erreur HTTP 400, même si le plan fonctionnel paraît correct. Le contrôle du protocole fait donc partie de la preuve de préparation.

Quels travaux nécessitent d’abord le mode plan ?
La planification devient le choix par défaut dès qu’au moins une de ces conditions apparaît : le périmètre traverse plusieurs répertoires, le dépôt n’est pas connu, la modification change une interface consommée ailleurs, le retour arrière demande une migration ou une régénération, ou encore l’approbation doit être donnée par une autre personne.

Une demande de « nettoyage » ou de « modernisation » est particulièrement ambiguë. Sans limites précises, elle doit être transformée en contrat de tâche avant toute écriture. Ce contrat peut rester court, mais il doit fixer :

• ce qui est inclus et exclu ;
• les fichiers ou modules autorisés ;
• les commandes que l’agent peut exécuter ;
• la personne qui valide le plan ;
• les critères de succès ;
• le format de la livraison ;
• la procédure de restauration.

Ainsi, le Plan Mode n’est pas uniquement un écran de réflexion. Il sert à rendre les hypothèses visibles avant qu’elles ne deviennent des modifications difficiles à isoler.

Dans une équipe, la question « planifier ou exécuter ? » devient rapidement une question de responsabilité. Si l’agent rédige un plan mais que personne n’est désigné pour l’approuver, la planification ajoute un document sans créer de contrôle. À l’inverse, si plusieurs personnes doivent valider chaque changement mineur, le délai de coordination devient disproportionné par rapport au risque.

Une organisation claire sépare au moins trois fonctions :

• l’auteur de l’analyse, qui rassemble les preuves et formule le plan ;
• l’approbateur de l’écriture, qui autorise le périmètre et les droits ;
• le responsable de la validation, qui exécute ou supervise les tests et accepte le résultat.

Ces fonctions peuvent être tenues par une seule personne dans un projet indépendant, mais elles doivent rester distinctes dans le journal de la tâche. Cela évite qu’un développeur interprète la génération du plan comme une autorisation implicite d’écrire.

Un plan trop détaillé pose aussi un problème. S’il décrit chaque commande sans expliquer la décision technique, il devient lent à relire et difficile à maintenir lorsque le dépôt évolue. Un plan trop vague produit l’effet inverse : l’agent ou le second développeur doit choisir lui-même les fichiers, l’ordre des changements et le niveau de risque. Le bon niveau de détail est celui qui permet une reprise par une personne absente du premier échange.

Comment passer du Plan Mode à l’exécution ?
Le passage doit être traité comme une décision explicite, et non comme une simple fin de conversation. Avant de quitter la planification, le responsable vérifie le commit de départ, la branche, l’état des fichiers modifiés, les dépendances détectées et les commandes de validation. Il approuve ensuite un périmètre précis : une approbation générale de « modifier le projet » n’est pas équivalente à l’autorisation d’écrire dans tous les répertoires.

La transition opérationnelle peut suivre cette séquence :

1. enregistrer l’identifiant du commit ou un point de reprise ;
2. comparer le workspace réel avec celui décrit dans le plan ;
3. relire les fichiers inclus et exclus ;
4. valider les droits temporaires nécessaires ;
5. lancer l’exécution dans la même branche, ou dans une branche dédiée ;
6. interrompre la tâche si l’agent découvre une hypothèse non prévue ;
7. produire le diff, les journaux de test et les écarts par rapport au plan.

Une modification qui sort du périmètre doit revenir en Plan Mode ou obtenir une nouvelle approbation. Cette règle est plus fiable qu’un réglage permanent, car elle suit le risque concret de la tâche.

Pour les permissions de l’espace de travail, il est préférable de reprendre le principe du moindre privilège : les fichiers nécessaires à l’analyse peuvent être accessibles en lecture, tandis que l’écriture, la suppression et les commandes ayant un effet externe doivent être accordées séparément. Les rôles et niveaux d’accès documentés pour les dépôts illustrent cette séparation entre maintenance courante et actions sensibles.

Le Plan Mode ne rend pas automatiquement un dépôt sûr. Il peut limiter certaines actions, mais il ne supprime ni les secrets présents dans l’environnement, ni les données accessibles en lecture, ni les risques liés à un plugin mal configuré. Les identifiants, les fichiers de production, les clés de signature et les données personnelles doivent rester séparés même pendant la planification.

Pour un projet sensible, l’environnement de préparation devrait fournir uniquement :

• le code nécessaire à la compréhension ;
• des variables d’environnement factices ou minimales ;
• des données anonymisées ;
• des commandes de lecture et de validation sans effet externe ;
• une branche ou une copie de travail isolée.

L’environnement d’exécution peut ensuite recevoir des permissions supplémentaires, mais seulement pour la durée et le périmètre de la tâche. Les droits d’écriture ne doivent pas être élargis simplement parce que le plan a été accepté. L’approbation du contenu et l’approbation des permissions sont deux décisions différentes.

La documentation officielle sur les secrets dans les workflows rappelle qu’un secret n’est transmis à une action que lorsqu’il est explicitement exposé comme entrée ou variable d’environnement. La page officielle consacrée à l’utilisation sécurisée des workflows insiste également sur le principe du moindre privilège et avertit que la suppression automatique des secrets dans les journaux n’est pas garantie dans toutes les transformations (référence de sécurité sur les workflows). Ces règles sont transposables à un agent de code : un mode de planification ne doit pas recevoir plus de secrets que nécessaire pour produire son analyse.

La persistance des sessions mérite une attention particulière. Un événement de session conservé par le harness peut prouver qu’un état de planification existait, mais il ne garantit pas que les fichiers, les variables, la branche ou les services associés sont restés identiques. Le responsable doit donc considérer la session comme une trace de workflow, non comme une sauvegarde complète de l’environnement.

Cette distinction est importante dans les projets de design et de production de contenu : un rendu généré, une bibliothèque média ou un cache de compilation peut modifier l’état de travail sans apparaître dans le plan textuel. Les répertoires générés et les volumes de travail doivent être explicitement inclus ou exclus.

Une session distante peut être interrompue par une perte réseau, un redémarrage, une fermeture de l’interface ou un transfert de responsabilité. Le point critique est alors le décalage possible entre le plan conservé dans la session et le workspace réellement disponible au retour.

Le mode plan est-il plus sûr à distance ?
Il peut réduire la probabilité d’une écriture prématurée si les outils et les permissions sont effectivement limités, mais il ne suffit pas à lui seul. Une session distante interrompue peut laisser une commande terminée, un fichier partiellement modifié, un processus actif ou une branche avancée. La sécurité dépend donc de la vérification de l’état au retour, pas uniquement du nom du mode.

Avant de reprendre, il faut contrôler :

• la machine et le workspace utilisés ;
• le commit courant et la branche active ;
• le résultat de git status ou de l’équivalent disponible ;
• les fichiers modifiés depuis la dernière trace ;
• la version des dépendances ;
• les processus encore actifs ;
• la présence ou l’absence des secrets attendus ;
• l’association entre le plan approuvé et le périmètre actuel.

La reprise ne doit jamais être résumée par « continuer la session ». Si l’état du workspace diffère du plan, l’agent revient d’abord à une phase de lecture et produit un écart. Un redémarrage de l’environnement ne signifie pas que le contexte d’exécution, les montages de fichiers ou les autorisations temporaires ont été restaurés.

Dans une procédure à distance, le livrable minimal d’une reprise comprend un nouveau point de contrôle, la liste des changements déjà appliqués, les étapes restantes et la confirmation de la commande de validation. Cette discipline est particulièrement utile lorsque le développement alterne entre un Mac local et une machine distante destinée au rendu, à la compilation ou aux essais d’intégration.

Vérification de reprise à cocher

• [ ] Le commit de référence est encore identifiable.
• [ ] La branche correspond à celle approuvée.
• [ ] Le workspace ne contient pas de changement extérieur au plan.
• [ ] Les dépendances sont dans l’état attendu.
• [ ] Les processus lancés avant l’interruption ont été contrôlés.
• [ ] Les permissions temporaires ont été réévaluées.
• [ ] Le prochain livrable est clairement défini.
• [ ] Une nouvelle validation est demandée lorsque l’état ne correspond plus au plan.

Une équipe peut formaliser sa politique avec les conditions suivantes :

• Si le changement est local, réversible, couvert par un test connu et réalisé dans un dépôt maîtrisé, alors choisir l’exécution directe ;
• si plusieurs critères manquent, alors commencer par un Plan Mode limité à la reconnaissance et à la rédaction du plan ;
• si le changement touche plusieurs modules, des permissions sensibles ou une responsabilité d’approbation distincte, alors imposer le parcours en deux phases ;
• si le plan révèle une dépendance inconnue, une migration ou une modification de configuration, alors suspendre l’exécution et réviser le plan ;
• si une session distante est interrompue avant la validation, alors ne pas reprendre directement : vérifier le workspace et recréer un point de contrôle ;
• si le plan est approuvé mais que le commit, la branche ou les dépendances ont changé, alors considérer l’approbation comme expirée.

Cette approche évite deux erreurs opposées : exécuter chaque petite tâche comme une opération réglementée, ou laisser l’agent modifier un dépôt complexe sous prétexte qu’un mode de planification est activé. Les utilisateurs qui souhaitent contrôler les droits avant la mise en œuvre peuvent consulter le centre d’aide de NUKCLOUD, notamment pour organiser un environnement distant contrôlé.

Le choix du Mac distant doit lui aussi rester conditionnel. Une machine distante est pertinente lorsqu’il faut reproduire un environnement Apple, maintenir un poste accessible pendant une longue tâche, réaliser des tests d’interface ou coordonner une livraison entre plusieurs personnes. En revanche, elle ne remplace pas une politique de branches, de secrets et de validation. Pour comparer le contexte local et distant avant de réserver une machine, le site français de NUKCLOUD permet de partir des options réellement disponibles, tandis que les informations générales sur le service sont présentées dans la page à propos de NUKCLOUD.

Dans la pratique, le poste actuel — ordinateur local partagé, environnement Windows ou serveur Linux — présente souvent trois limites pour ce type de workflow : l’état du workspace dépend d’une seule machine, la reprise après interruption exige une reconstruction manuelle du contexte, et l’accès aux outils Apple ou aux validations graphiques n’est pas toujours disponible au même endroit. La location d’un Mac via NUKCLOUD peut offrir un environnement de travail plus facile à remettre à disposition pour une tâche temporaire, à condition de conserver la séparation des permissions et de vérifier chaque reprise. Elle convient surtout aux essais, aux audits, aux validations créatives audio ou vidéo et aux missions de développement à durée limitée ; pour une charge lourde permanente ou un besoin de périphériques physiques dédiés, l’achat et la gestion d’un poste propre restent parfois plus cohérents.