Transfert sécurisé d’agent IA entre appareils : état, approbation et reprise
Guide du transfert sécurisé d’un agent IA entre appareils : pilotage à distance, état de tâche, permissions, déconnexion, exemple GitHub Copilot CLI et continuité FoneClaw.
- Un pilotage à distance, une migration de tâche, une notification de suivi et un passage entre deux interfaces du même téléphone correspondent à quatre mécanismes différents.
- Un transfert fiable doit identifier la tâche, son intention, ses entrées, l’étape actuelle, les résultats déjà produits, l’appareil qui exécute et la fraîcheur du contexte.
- Une approbation reste liée à l’action, à la session et à l’appareil qui produira l’effet ; déplacer l’interface de contrôle ne déplace pas automatiquement les permissions.
- GitHub Copilot CLI illustre le pilotage distant d’une session qui continue dans son environnement d’origine, tandis que FoneClaw assure une continuité entre l’accueil et l’assistant flottant sur un même téléphone Android.
Distinguer pilotage, migration, notification et continuité locale
Un transfert sécurisé d’agent IA entre appareils commence par une définition précise du mouvement attendu. Quatre situations sont souvent confondues. Le pilotage à distance permet de suivre et diriger une tâche qui continue ailleurs. La migration déplace réellement la responsabilité de l’exécution vers un nouvel appareil. Une notification de suivi informe l’utilisateur et peut ouvrir un point de contrôle. Enfin, la continuité locale permet de passer entre plusieurs interfaces d’un même appareil sans changer de moteur d’exécution.
Imaginons une analyse de code lancée sur un ordinateur. Si le téléphone affiche la progression et permet d’ajouter une instruction, l’ordinateur reste responsable de l’exécution : c’est du pilotage distant. Si le téléphone récupérait les fichiers, l’environnement et le processus pour poursuivre localement, il s’agirait d’une migration. Une notification « intervention nécessaire » ne réalise aucun de ces deux transferts tant qu’elle ne permet pas de retrouver la session et son état.
Le déplacement d’une conversation ne suffit pas non plus. Un historique de messages peut expliquer l’intention sans contenir les fichiers ouverts, les résultats intermédiaires, les permissions accordées ou l’étape exacte où l’agent s’est arrêté. La nouvelle interface doit donc annoncer où la tâche fonctionne, ce qu’elle peut contrôler et quelles données demeurent sur l’appareil d’origine.
Sur Android, les capacités actuellement disponibles de FoneClaw proposent un quatrième modèle : l’accueil et l’assistant flottant donnent accès à la même tâche sur le même téléphone. L’exécution ne migre vers aucun autre appareil. Cette distinction évite d’attribuer à une continuité d’interface les propriétés d’une synchronisation multi-appareils. Pour approfondir le rôle du téléphone comme poste de suivi, consultez Contrôle d’agent IA mobile : quand le téléphone devient le centre de commande.
Définir le contrat minimal de l’état de tâche
Une continuité fiable exige davantage qu’un identifiant de conversation. L’interface qui reprend le contrôle doit recevoir un état structuré et suffisamment récent pour présenter la tâche sans la réinterpréter. Ce contrat minimal comprend l’identité de la tâche, l’intention validée, les entrées utilisées, l’étape actuelle, les résultats déjà produits, le responsable de l’exécution et l’heure de la dernière mise à jour.
| Élément | Ce qu’il doit préciser | Pourquoi il compte |
|---|---|---|
| Identité | Tâche, session, utilisateur et appareil concernés | Évite de mélanger deux travaux ou deux comptes |
| Intention | Résultat demandé et limites formulées | Empêche une nouvelle interface d’élargir la mission |
| Entrées | Fichiers, écran, message ou données utilisés | Permet de savoir sur quoi repose la décision |
| Étape actuelle | Action terminée, active, suspendue ou en attente | Évite les répétitions et les effets en double |
| Résultats | Sorties provisoires et effets déjà confirmés | Montre ce qui peut être repris ou corrigé |
| Responsable | Appareil et processus qui exécutent réellement | Indique où se trouvent les outils et permissions |
| Fraîcheur | Horodatage et version de l’état | Signale un contexte devenu périmé |
Prenons la préparation d’un message à partir d’un document ouvert sur ordinateur. Le téléphone peut afficher le brouillon, mais il doit aussi indiquer que le fichier source reste sur l’ordinateur et que l’envoi n’a pas eu lieu. Si le document a changé depuis la dernière synchronisation d’état, la tâche doit être marquée comme potentiellement périmée avant toute approbation.
Le contexte personnel mérite la même rigueur. Un contact, un calendrier ou une préférence peuvent différer selon l’appareil et le compte actif. Agent IA avec contexte personnel : le guide téléphone explique comment utiliser ces informations sans confondre mémoire pratique, identité de compte et autorisation d’agir.
Lier permissions et approbations à l’action exécutée
Une permission appartient à l’environnement qui réalisera l’action. Une approbation appartient à une tâche, à une opération précise et à un état donné. Le fait de contrôler une session depuis un second appareil ne copie donc ni les autorisations du système source ni celles de l’appareil distant. L’interface peut transmettre une décision, mais l’exécutant doit encore vérifier qu’elle correspond à la bonne session et que ses propres permissions restent valides.
Supposons qu’un ordinateur prépare une modification de fichier et que le téléphone affiche la demande d’approbation. L’écran mobile doit nommer le dépôt, le fichier, le changement proposé et l’ordinateur qui appliquera la modification. Si le fichier a évolué depuis la création de l’aperçu, l’approbation devient périmée. La session source doit demander une nouvelle vérification plutôt que réutiliser une décision fondée sur un ancien contenu.
Le même principe vaut pour Android. Une demande formulée depuis une montre ou un navigateur ne donne pas automatiquement accès aux contacts, aux messages ou au calendrier du téléphone. L’action finale dépend des permissions accordées à l’application qui l’exécutera. Une validation distante peut autoriser une étape déterminée ; elle ne crée pas un droit permanent sur les autres outils du téléphone.
La carte d’approbation doit au minimum afficher l’action, sa cible, sa conséquence, le responsable de l’exécution et la durée de validité de la demande. Les choix « Approuver », « Refuser » et « Examiner sur l’appareil source » sont plus clairs qu’un bouton générique. Notre guide Interface d’approbation des agents IA sur téléphone : confiance, contexte et reprise développe ces décisions à l’échelle d’un écran mobile.
Après validation, l’exécutant enregistre le résultat et le renvoie aux autres interfaces. Une approbation sans accusé d’exécution reste incomplète : l’utilisateur doit savoir si l’action a réussi, a échoué ou attend encore une permission locale.
Prévoir la déconnexion et la reprise sans doublon
Une continuité sécurisée doit définir le comportement de chaque rupture avant qu’elle se produise. Si l’appareil source se met en veille, si le réseau disparaît, si l’application ciblée change d’état ou si le jeton de transfert expire, l’interface distante ne peut pas continuer à afficher une tâche comme pleinement active. Elle doit annoncer l’état connu, son ancienneté et l’action de récupération disponible.
Lorsque la connexion se coupe pendant une opération de lecture, la tâche peut généralement attendre puis reprendre. Pour une action à effet externe, la règle est plus stricte. Si l’envoi d’un message ou la modification d’un fichier se trouve dans un état incertain, aucune nouvelle tentative ne doit partir avant vérification. L’exécutant recherche d’abord le résultat réel, puis signale « terminé », « non appliqué » ou « état indéterminé nécessitant un contrôle ».
Un jeton expiré ferme l’accès distant sans supprimer nécessairement la session source. L’utilisateur peut devoir s’authentifier de nouveau et rattacher l’interface à la tâche existante. Cette reconnexion ne doit pas créer une seconde session concurrente. Elle doit récupérer l’identité et la version de l’état, puis comparer leur fraîcheur avant de réactiver les commandes.
Si l’application change entre-temps, la reprise doit repartir d’un point observable. Une boîte de dialogue peut avoir disparu, un document peut avoir été modifié ou un téléphone peut être verrouillé. L’agent signale alors que le contexte précédent n’est plus fiable et demande une nouvelle capture, un retour tactile ou une confirmation mise à jour.
L’arrêt suit une logique similaire. Une commande envoyée depuis le téléphone doit viser une tâche précise et produire un accusé de réception. Si la source est inaccessible, l’interface indique que la demande d’arrêt est en attente plutôt que de prétendre que le processus est déjà terminé.
Le modèle de pilotage distant de GitHub Copilot CLI
GitHub Copilot CLI fournit un exemple actuel de pilotage distant sans migration de l’exécution. La session continue dans son environnement source, où se trouvent le terminal, le dépôt, les fichiers et les outils. GitHub Mobile, github.com, VS Code ou JetBrains peuvent servir d’interfaces pour suivre et orienter cette même session. Le téléphone ne devient pas la machine qui exécute localement la commande CLI.
D’après l’explication officielle du contrôle distant de Copilot CLI, l’utilisateur peut consulter la progression, envoyer ou mettre en file une instruction, répondre aux questions de l’agent, accepter ou refuser une demande de permission et arrêter la session. La responsabilité d’exécution reste pourtant dans l’environnement où la session CLI a été lancée.
Ce modèle est disponible de manière générale sur mobile, sur le web et dans les environnements de développement mentionnés par GitHub. L’annonce de disponibilité générale du pilotage distant confirme cette séparation entre la session en cours et ses différentes interfaces de contrôle.
Depuis juillet 2026, GitHub Mobile peut également fournir des notifications en direct sur iOS et Android pour les sessions CLI pilotées à distance. Ces notifications mobiles pour les sessions Copilot CLI aident l’utilisateur à revenir lorsqu’une question, une permission ou une décision demande son attention.
La leçon d’architecture est précise : un appareil distant peut piloter une tâche sans recevoir les fichiers ni exécuter le processus. Cette conception convient bien à une session de développement maintenue sur une machine source. Elle ne prouve pas que tous les assistants, toutes les actions Android ou tous les transferts entre appareils suivent le même contrat.
La continuité FoneClaw sur un même téléphone
FoneClaw traite un problème différent avec ses capacités actuellement disponibles : conserver une tâche accessible entre l’accueil FoneClaw et un assistant flottant déplaçable sur le même téléphone Android. Le panneau compact permet de suivre l’agent depuis l’application utilisée, sans déplacer l’exécution ni synchroniser la session avec un second appareil.
L’utilisateur peut joindre en un geste l’écran courant à la demande. Les éléments d’interface propres à FoneClaw sont exclus de cette pièce jointe afin que le modèle reçoive le contenu pertinent de l’application active. Un modèle configuré interprète alors la demande, tandis que les outils Android gouvernés réalisent les actions prises en charge.
Imaginons qu’un utilisateur consulte une confirmation de rendez-vous dans une application. Depuis l’assistant flottant, il peut joindre l’écran et demander de préparer un rappel. Si la création exige une approbation ou une permission, la tâche reste liée à son contexte. L’utilisateur peut ouvrir l’accueil FoneClaw, examiner la proposition, approuver ou refuser, puis revenir à l’application sans perdre l’état de l’opération.
La continuité couvre aussi l’arrêt et la récupération des permissions. Une tâche commencée depuis le panneau flottant peut être interrompue depuis l’accueil. Si un accès Android manque, l’utilisateur rejoint le réglage nécessaire puis reprend la même tâche. La base actuelle de FoneClaw rassemble des états indépendants, des approbations liées à la session et l’isolation des tâches, puis rend ces mécanismes disponibles entre les deux interfaces du téléphone.
Nous présentons cette fonction pour ce qu’elle est : une continuité multi-interface sur un appareil Android. Elle constitue un contrat utile à tester avant toute extension multi-appareils, car elle vérifie déjà l’identité de tâche, l’approbation, l’arrêt et la reprise sans changer de responsable d’exécution.
Tester un transfert sécurisé de bout en bout
Un test utile doit suivre la tâche depuis son lancement jusqu’à la suppression de son accès distant. Choisissez une opération réversible, comme analyser un fichier d’essai et préparer une modification sans la publier. Identifiez à l’avance l’environnement source, l’interface distante et le résultat attendu.
- Démarrer : lancez la session sur l’appareil source et notez son identifiant, son intention, ses entrées et l’heure de départ.
- Piloter : ouvrez la session sur le second appareil, vérifiez que l’exécution reste attribuée à la source, puis ajoutez une instruction non destructive.
- Approuver : provoquez une demande de permission limitée et contrôlez que la carte nomme l’action, la cible, la session et l’appareil exécutant.
- Arrêter : envoyez une commande d’arrêt depuis l’interface distante et attendez la confirmation de la source.
- Reconnecter : coupez temporairement le réseau, rétablissez-le et vérifiez que la même session revient avec un état daté, sans duplication.
- Examiner la trace : contrôlez les instructions, décisions, résultats et erreurs enregistrés, ainsi que l’appareil qui a produit chaque effet.
- Supprimer l’accès : fermez la session distante ou révoquez son jeton, puis confirmez qu’une ancienne interface ne peut plus envoyer de commande.
Ajoutez ensuite deux scénarios d’échec. Dans le premier, modifiez le fichier source pendant la déconnexion : l’approbation préparée auparavant doit devenir périmée. Dans le second, laissez expirer l’accès distant : la reconnexion doit exiger une nouvelle authentification sans créer une seconde tâche.
Les agents peuvent aussi découvrir des services ou des outils à distance. Cette découverte doit rester liée à une source identifiable et à des capacités vérifiables. Agentic Resource Discovery : ai-catalog.json, registres et confiance pour agents mobiles explique comment examiner ces ressources avant de les intégrer à une tâche.
Le critère final est simple : l’utilisateur doit toujours savoir où la tâche fonctionne, quelle version de l’état il consulte, quelle action attend son accord et comment arrêter ou reprendre. Cette visibilité transforme une continuité séduisante en transfert réellement testable.