Quand l’agent attend une validation ou une connexion : conserver l’instruction et reprendre la session

Vous ouvrez un projet de votre ordinateur sur votre iPhone et saisissez : « Corriger la page de connexion pour qu'elle défile, tout en conservant les méthodes de connexion existantes ». Après avoir appuyé sur Envoyer, l'application vous avertit que l'agent ne peut pas recevoir de message pour le moment. Pourtant, le terminal affiche une interface active et rien n'indique que le processus s'est arrêté.

Deux questions se posent alors : qu'attend l'agent ? Et qu'est-il advenu de l'instruction ? En résoudre une seule ne suffit pas. Après avoir franchi l'étape de connexion, il reste parfois un message conservé en attente de décision ; et après le rétablissement du réseau, la requête envoyée s'exécute peut-être déjà en arrière-plan.

Tactic Remote 1.11, associé à un compagnon hôte mis à jour, explique les blocages de saisie identifiés et conserve les messages refusés. Les trois scénarios ci-dessous illustrent la marche à suivre. Ils permettent de comprendre le processus de reprise et ne constituent ni des rapports d'incidents réels ni une description universelle de toutes les interfaces d'agents.

Distinguer processus en cours, saisie prête et tâche terminée

Qu'un processus de terminal soit actif ne signifie pas qu'il puisse accepter des instructions de code dans l'immédiat. Il peut demander la confirmation du projet, attendre des identifiants de fournisseur ou préparer son invite de saisie. À l'inverse, une interface au repos ne prouve pas que le code est corrigé ; elle peut simplement indiquer qu'aucune tâche n'est en cours d'exécution.

Les autorisations d’outils sont des mécanismes de contrôle en cours d'exécution ; elles ne constituent pas nécessairement un « refus d'envoi ». Chaque agent, mode et version présente des invites différentes. Fiez-vous toujours à la sortie réelle du terminal et aux indications de l’application.

Cas 1 : Un nouveau projet attend la confirmation de confiance du répertoire

Vous basculez sur un nouveau dépôt et le terminal vous demande si vous faites confiance au répertoire actuel. Lors d'une session interactive, Claude Code affiche une boîte de dialogue de confiance pour les répertoires non préalablement approuvés ; sa documentation officielle de sécurité décrit ce comportement.

Vérifiez d'abord le chemin complet affiché dans le terminal. S'agit-il bien du dépôt souhaité ? De votre propre code, du projet d'un collègue ou d'un contenu téléchargé inconnu ? Des répertoires portant le même nom peuvent appartenir à des branches différentes, des copies locales ou des espaces de travail distincts ; le titre de la session ne suffit pas.

Lorsque 1.11 détecte cette attente, l'action de récupération vous oriente vers le terminal. Répondez selon les options proposées à l'écran, puis vérifiez que l'agent atteint son interface de saisie. Redémarrer un processus en attente vous ramènera généralement devant la même décision.

Examinez ensuite l'instruction conservée. Si elle demandait des modifications ou un commit, vous pouvez la renvoyer dans le champ de saisie pour en restreindre la portée :

Effectuez un examen en lecture seule du mode de démarrage de ce dépôt, des pages de connexion concernées et des tests existants. Énumérez les fichiers susceptibles de nécessiter des modifications et le comportement à préserver. Proposez d’abord une approche ; ne modifiez aucun fichier, n’installez aucune dépendance et ne créez aucun commit.

Vérifiez que les chemins figurant dans la réponse correspondent au dépôt actuel avant de passer à l'implémentation. Les demandes d'autorisation d'outils ultérieures devront être jugées individuellement ; faire confiance à un répertoire n'autorise pas automatiquement l'ensemble des actions suivantes. La documentation des autorisations précise ces règles.

Cas 2 : L’ordinateur est connecté, mais l’agent demande toujours une connexion

Votre compte Tactic gère l'association et l'accès à l'ordinateur de développement. Claude Code, Codex, Amp et Droid utilisent leurs propres comptes de fournisseur sur cet ordinateur. Ouvrir un projet depuis son mobile ne signifie pas que ces comptes tiers soient configurés.

Identifiez d'abord quel programme réclame une authentification. S'il s'agit d'une invite dans le terminal de l'agent, suivez sa procédure de validation. Si l'opération nécessite le navigateur de l'ordinateur, terminez-la sur ce dernier avant de revenir à la même session. Ne copiez jamais d'URL de connexion, de code à usage unique ou d'identifiant dans des messages de chat ordinaires.

Une fois la connexion établie, vérifiez que le terminal a quitté l'écran d'authentification et accepte les saisies. Si l'erreur réelle relève des droits du compte, d'un abonnement, de l'accès réseau ou de la configuration, traitez-la selon son contexte. Vous reconnecter sans cesse à Tactic ou réassocier l'ordinateur ne remplacera jamais l'authentification auprès du fournisseur.

Vérifiez ensuite le message conservé, le champ de saisie et la file d'attente. Si l'instruction n'est pas encore partie, choisissez comment poursuivre. Si une nouvelle sortie correspond déjà à cette instruction, examinez le résultat en cours. Ce n'est pas parce que l'écran reste silencieux après la connexion qu'il faut coller à nouveau l'intégralité de la tâche.

Choisir une action de reprise selon son effet sur le message

La version 1.11 propose différentes actions en fonction de l'état détecté. Lorsque l'agent n'est explicitement pas lancé, vous pouvez choisir Start & Send (Démarrer et envoyer). Pour les attentes de confiance, de connexion ou de démarrage identifiées, Open Terminal (Ouvrir le terminal) vous dirige vers l'invite active.

Pour ce même message conservé, vous pouvez également opter pour Queue (Mettre en file d'attente) ou Edit (Modifier) :

Si le champ de saisie contient déjà du texte, le bouton Edit est désactivé afin d'éviter d'écraser votre nouveau brouillon par le message conservé. Si la file est suspendue, si une approbation est en attente ou si le statut de la tâche est incertain, la seule reconnexion réseau ne prouve pas que les messages de la file ont été envoyés.

Un compagnon hôte plus ancien peut ne pas fournir la classification complète des états d'attente, ce qui conduit l'application à afficher un bouton générique Start & Send. Ce bouton ne prouve pas que le processus s'est arrêté ; examinez l'état réel dans le terminal avant de décider de démarrer et mettez à jour le compagnon utilisé sur l'ordinateur.

Cas 3 : Déconnexion après envoi : vérifier d’abord la transmission

Lorsque l'application reçoit un refus explicite de l'ordinateur, le message peut être récupéré comme une requête non acceptée. Mais si une déconnexion ou un délai d'attente survient pendant l'envoi, la situation est différente : la requête a pu atteindre l'ordinateur sans que le téléphone n'en reçoive le résultat.

Revenez au même ordinateur, projet et session, et recherchez la sortie la plus récente correspondant à cette demande. Si l'agent est en train de modifier la page de connexion, laissez-le poursuivre ; s'il a déjà produit un résultat, inspectez-le en premier. Dans la vue de discussion, l'absence de nouvelle bulle de réponse ou la simple présence de l'ancien historique ne prouve pas que la demande n'a pas été exécutée ; l'hôte a pu la réceptionner en arrière-plan.

Par exemple, si l'instruction demandait « corriger puis committer », un renvoi impulsif risquerait de provoquer des modifications superflues, un second commit ou l'exécution répétée de commandes lourdes. Tant que la situation n'est pas clarifiée, « réessayer » ne doit pas constituer l'action de reprise par défaut.

Une fois que vous avez confirmé que la session est inactive, vous pouvez demander un point d'avancement :

Indiquez si la tâche précédente a commencé, quels fichiers ont été modifiés à ce stade, quelles vérifications ont réellement été exécutées et si un commit a été créé. Ne réexécutez pas la tâche précédente, n’apportez aucune modification supplémentaire et ne publiez rien.

Il s'agit d'une simple requête d'état. Si le terminal est toujours bloqué sur un choix de confiance, de connexion ou d'autorisation, traitez d'abord cette invite ; sinon, la demande de statut elle-même risque d'être rejetée. Si la session d'origine ne peut être lue, inspectez le projet et les processus directement sur l'ordinateur avant de choisir comment poursuivre.

Après la reprise, valider le travail par les résultats plutôt que par les indicateurs d’état

Utilisez d'abord une requête ciblée pour vérifier que la session d'origine répond normalement avant de donner des ordres d'implémentation. Pour le problème de défilement initial, explicitez à la fois l'objectif et les contraintes à préserver :

Corrigez le problème de défilement de la page de connexion sur petit écran. Préservez les méthodes de connexion existantes, le flux de retour de connexion et le message affiché lors de l'annulation de la vérification. Expliquez d'abord le périmètre minimal des modifications. Une fois terminé, détaillez les modifications réelles, les vérifications exécutées, les échecs et les actions nécessitant encore une validation manuelle. Ne publiez pas encore.

Lors de la recette, assurez-vous au minimum que les modifications ont bien eu lieu dans le dépôt prévu, que la page défile réellement et que les flux de connexion et d'annulation fonctionnent toujours comme attendu. Les résultats de tests doivent correspondre aux modifications actuelles ; si le code est retouché après une vérification, revalidez le comportement concerné. Recevoir une réponse montre que la communication a repris, mais ne remplace pas ces contrôles.

Ne créez une nouvelle session que si vous avez établi avec certitude que l'ancienne n'existe plus ou ne peut continuer. Enregistrez au préalable le résumé de la tâche, les fichiers modifiés, les tests exécutés et les questions en suspens. Ouvrir une nouvelle session dans le même répertoire ou changer d'agent ne transfère pas automatiquement l'intégralité du contexte antérieur.

Si l'ordinateur redevient inaccessible, revenez au guide de dépannage des connexions ; s'il se connecte mais ne renvoie aucune réponse utile, notez le nom de l'agent, les versions des deux appareils, l'invite d'attente exacte et le statut du dernier message avant de contacter le support. Pour connaître les exigences de mise à jour et les autres nouveautés de cette version, consultez la présentation de Tactic Remote 1.11.