Blog
Dépannage des connexions iPhone : réseaux locaux et Tactic Relay
Que prouvent un même réseau Wi-Fi, un ordinateur affiché ou un port joignable ? Repartez de la dernière étape fonctionnelle, préservez la session et validez la reprise.
Vous pouvez vous connecter à votre Mac chez vous, mais la liaison échoue dans un café. L’ordinateur apparaît dans la liste de votre compte, mais l’ouverture d’un projet expire systématiquement. Ou le terminal s’affiche, mais aucune nouvelle réponse n’arrive. Ces trois situations ressemblent à des pannes de connexion identiques, mais le point à examiner est différent dans chaque cas.
Lors du dépannage, commencez toujours par « la dernière étape dont le bon fonctionnement est avéré ». Si l’ordinateur ne tourne pas du tout, rétablissez d’abord l’hôte. Si la connexion locale échoue alors qu’un relais Relay configuré fonctionne, examinez le réseau local. Si la session d’origine affiche une sortie de terminal en direct, vérifiez l’état de l’agent. Chaque étape fournit ainsi un résultat concret à évaluer, tout en préservant le travail déjà en cours.
Consignez l’état actuel avant de modifier la configuration réseau
Notez le nom de l’ordinateur, le projet et la session, le mode de connexion, le texte exact de l’erreur et l’heure approximative. Vérifiez également si des modifications récentes sont survenues : changement de réseau, mise en veille de l’ordinateur, mise à jour de l’hôte ou annulation d’une connexion.
Évitez de commencer par dissocier l’ordinateur, supprimer la session ou réinitialiser l’ensemble des réglages réseau. Ces actions modifient les autorisations et l’état de travail sans résoudre la mise en veille ni l’isolation des réseaux invités. Modifiez une seule condition pertinente à la fois et comparez les résultats.
La séquence ci-dessous s’applique au diagnostic d’une connexion existante. Pour une configuration initiale, suivez le guide de démarrage sur iPhone pour installer le compagnon et procéder au jumelage.
Les deux modes partagent le même ordinateur de développement, mais traversent des étapes réseau et d’autorisation distinctes. Vérifiez la voie que vous utilisez en pratique.
Étape 1 : Vérifier que l’ordinateur et le service compagnon sont en cours d’exécution
L’ordinateur doit être disponible pour le travail et l’application compagnon ou le service CLI doit tourner. Un écran éteint est différent d’un ordinateur en veille complète. La présence de l’ordinateur dans la liste de votre compte ne remplace pas non plus la validation de la connexion active. Vérifiez sur l’hôte l’état du service, l’absence d’erreurs et l’assurance de cibler l’ordinateur prévu.
Sur Mac, cette commande en lecture seule permet de contrôler le port par défaut :
Le port par défaut est 8765. Si vous l’avez modifié, utilisez le port configuré. Les informations COMMAND, PID et l’adresse d’écoute aident à identifier quel processus assure le service.
| Résultat | Ce que cela indique | Étape suivante |
|---|---|---|
| Aucune sortie | Aucun processus à l’écoute n’a été trouvé sur ce port | Vérifier si le service a démarré, s’il signale une erreur et si le port correspond |
| Processus à l’écoute | Un service local écoute sur le port | Vérifier le processus par rapport au compagnon, puis tester la route du téléphone |
| Écoute sur boucle locale uniquement | L’adresse d’écoute n’est accessible que depuis l’ordinateur lui-même | Vérifier la configuration réseau local du service ; maintenir l’authentification active |
| Processus inattendu ou conflit de port | Vous êtes peut-être connecté à un autre service | Identifier l’origine du processus avant d’envisager son arrêt |
Cette vérification ne valide pas l’identité Tactic et ne prouve pas que l’iPhone peut se connecter. L’application Mac et la CLI autonome pouvant utiliser le même port par défaut, déterminez clairement laquelle est lancée. Si vous ne pouvez pas inspecter directement l’ordinateur, maintenez le statut de l’hôte comme « non confirmé » et poursuivez avec les erreurs affichées sur le téléphone.
Étape 2 : Pour une connexion locale, vérifier les autorisations et l’accessibilité réelle
Le fait que deux appareils affichent le même nom de réseau Wi-Fi ne garantit pas qu’ils puissent communiquer. Les réseaux invités, l’isolation réseau d’entreprise et les routes VPN peuvent bloquer la liaison. Sur l’iPhone, accédez à Réglages → Confidentialité et sécurité → Réseau local et vérifiez les autorisations de Tactic Remote ; le guide d’Apple sur les autorisations réseau local détaille ce réglage.
Comparez ensuite l’adresse actuelle de l’ordinateur avec celle enregistrée dans l’application. Un changement de routeur, le passage du Wi-Fi à l’Ethernet ou un renouvellement DHCP peuvent rendre l’ancienne adresse caduque. Fiez-vous à l’adresse affichée par le compagnon hôte et ne partez pas du principe que le Wi-Fi de chaque Mac utilise en0.
Si un second Mac est disponible sur le même réseau de confiance, vous pouvez tester la connexion TCP vers l’ordinateur de développement :
Cette commande tente uniquement d’établir une liaison TCP ; elle n’envoie ni identifiants Tactic ni instructions de code. L’option -G 3 définit le délai d’expiration sur le nc de macOS ; les arguments peuvent différer sur d’autres systèmes.
| Résultat | Interprétation |
|---|---|
| Connexion réussie | L’appareil de test atteint le port cible ; l’authentification Tactic et la route de l’iPhone nécessitent des vérifications séparées |
| Connection refused | La demande de connexion a été activement refusée. Vérifiez le port, le service, l’écoute et le filtrage. Cela ne valide pas l’authentification Tactic ni l’appareil émetteur |
| Expiration du délai | Aucune réponse reçue ; vérifiez l’adresse, l’isolation, le routage, le pare-feu et l’état de l’hôte |
Tester 127.0.0.1 sur l’ordinateur de développement ne vérifie que lui-même. Dans le navigateur d’un iPhone, 127.0.0.1 pointe vers le téléphone, pas vers le Mac. De même, un échec de ping ne prouve pas à lui seul que le service est hors ligne, le réseau pouvant bloquer l’ICMP.
Si vous devez ajuster le pare-feu, autorisez uniquement l’accès requis pour le compagnon réellement actif et maintenez l’authentification. Si un VPN est utilisé, comparez les modifications de routage dans le respect des règles de votre organisation. Désactiver l’ensemble du pare-feu, supprimer l’authentification ou ouvrir les ports d’un routeur ne doivent pas constituer des méthodes habituelles de dépannage. Consultez la documentation réseau local pour les bases.
Étape 3 : Pour Relay, vérifier l’état du compte et de l’hôte
Dès que vous quittez votre domicile, le téléphone ne peut plus joindre l’adresse réseau local de votre ordinateur. Avec Tactic Relay, assurez-vous que les deux appareils utilisent le compte Tactic prévu, que l’ordinateur est associé et que la connexion Relay du compagnon hôte est active.
Procédez dans cet ordre :
- L’ordinateur est éveillé, le compagnon tourne et l’accès à Internet est disponible.
- Le téléphone et l’ordinateur sont connectés au bon compte, et le nom de l’ordinateur choisi est correct.
- L’ordinateur indique une connexion Relay normale, sans reconnexions incessantes ni erreurs spécifiques.
- Les éventuelles demandes de validation de compte, de reconnexion ou de retour du navigateur vers l’application ont été exécutées.
- Une fois ces points validés, connectez-vous à l’ordinateur et ouvrez le projet.
La connexion au compte Tactic gère l’association de l’hôte et l’autorisation d’accès. Les agents de programmation comme Claude Code utilisent leurs propres comptes de fournisseur sur l’ordinateur. Voir un ordinateur dans son compte, accéder à son espace de travail et disposer d’un agent connecté sont trois états distincts.
La version 1.11 corrige un dysfonctionnement où l’association d’un ordinateur pouvait échouer quelque temps après la connexion. Si une vérification est demandée, menez-la à bien avant de tenter une nouvelle association. Dissocier et réassocier en boucle multiplie les facteurs d’incertitude et ne doit pas constituer la première réaction face à un délai d’attente.
Si les deux modes sont configurés, ils permettent d’isoler le problème par comparaison : si le réseau local échoue mais que Relay fonctionne sur le même ordinateur, concentrez-vous sur le réseau local. Si le réseau local fonctionne mais que Relay échoue, privilégiez la vérification du compte, l’état Relay de l’hôte et l’accès à Internet. Cette comparaison resserre l’analyse, mais ne garantit pas l’absence totale de défaut sur un composant donné.
En cas d’utilisation de Cloudflare Tunnel, vérifier son adresse séparément
Avec Cloudflare Tunnel, vérifiez le processus du tunnel, son adresse active et le service auquel il est associé. Le redémarrage d’un tunnel temporaire pouvant modifier son adresse, une URL enregistrée peut ne plus pointer vers le bon ordinateur.
L’ouverture d’une page HTTP dans un navigateur ne garantit pas à elle seule le bon fonctionnement des connexions WebSocket ou de l’authentification de l’application. Conservez l’erreur exacte, vérifiez l’adresse actuelle et suivez le guide de configuration de Cloudflare Tunnel. Évitez de modifier simultanément les règles du tunnel et l’association de compte Tactic Relay.
Étape 4 : Revenir à la session d’origine et valider les nouvelles sorties
Une fois connecté, sélectionnez l’ordinateur, le projet et la session utilisés avant la panne. Si la liste des projets s’affiche, l’accès à l’espace de travail est rétabli. Si des modifications en direct apparaissent dans le terminal d’origine, les sorties de session parviennent bien au téléphone. L’historique passé atteste seulement d’une activité antérieure ; il ne prouve pas que la liaison actuelle est opérationnelle.
Si le terminal reste bloqué sur la confiance accordée au projet, la connexion du fournisseur ou une invite de démarrage, consultez le guide de déblocage des agents. Modifier sans cesse les réglages Wi-Fi ou réassocier le compte ne permettra pas de répondre à cette invite dans le terminal.
Si la déconnexion est survenue lors de l’envoi, recherchez d’abord les sorties récentes correspondant à cette instruction ; elle a pu atteindre l’ordinateur. Une fois le réseau rétabli, ne renvoyez pas immédiatement la tâche complète. Après avoir confirmé que la session est inactive, vous pouvez soumettre une requête d’état succincte :
Fournissez un résumé en lecture seule du projet actuel, du travail déjà effectué et des éléments en attente de décision. Ne réexécutez pas la tâche précédente et ne modifiez aucun fichier.
Vérifiez que le répertoire et les résultats correspondent à la tâche d’origine avant de décider de la suite. Si une nouvelle session s’avère indispensable, notez au préalable l’état réel de l’ancienne ; une nouvelle session n’hérite pas automatiquement de l’intégralité du contexte.
Si le problème persiste, transmettez vos constats au support
Vous pouvez copier ce modèle et y consigner les faits établis ; indiquez « non confirmé » pour tout élément non vérifié.
Avant tout partage externe, supprimez les identifiants, codes QR d’appairage, liens de connexion et contenus privés du terminal. Masquez les comptes, chemins et adresses réseau si nécessaire. Transmettre au support un constat précis (« Le port local répond, l’application signale un échec de vérification et la version de l’hôte est... ») permet une résolution bien plus rapide qu’un simple signalement « impossible de se connecter ».
Une fois la connexion rétablie, comparez les deux versions sur la page de téléchargement afin d’éviter qu’un écart de version ne perturbe votre prochaine session distante. Pour découvrir les autres nouveautés de la version 1.11 et la procédure de mise à jour sur mobile et ordinateur, consultez la vue d'ensemble de Tactic Remote 1.11.
Essayez Tactic Remote
Pilotez vos agents de programmation depuis votre téléphone
Connectez-vous à Claude Code, Codex et aux autres agents sur votre Mac, PC Windows ou Linux. Consultez leur progression et envoyez la prochaine instruction depuis votre iPhone ou iPad.