Au-delà du SSH : pourquoi WebSocket surpasse les protocoles terminal pour les agents de codage IA

Quand les développeurs entendent parler de contrôler Claude Code depuis un téléphone, la réaction naturelle est : "Pourquoi ne pas simplement faire un SSH vers mon Mac ?"

C'est une question légitime. SSH est éprouvé, sécurisé, omniprésent. Chaque développeur le connaît. Il existe d'excellents clients SSH mobiles comme Termius, Blink Shell et Prompt. Pourquoi construire quelque chose de différent ?

La réponse n'est pas que SSH est mauvais. C'est que les agents de codage IA ont des patterns d'interaction fondamentalement différents des sessions shell interactives, et ces différences s'accumulent pour dégrader l'expérience quand on force le modèle SSH.

Le décalage du modèle d'interaction

SSH a été conçu en 1995 pour un modèle spécifique : un humain assis devant un terminal, tape des commandes, lit la sortie, tape d'autres commandes. La session est interactive et synchrone — vous êtes activement engagé tout le temps.

Les agents de codage IA inversent ce modèle :

Les deux dernières lignes sont le problème. Quand Claude Code termine une tâche ou a besoin de votre approbation pour une opération dangereuse, SSH n'a aucun moyen de vous le dire. Vous devez être en train de regarder.

Problème 1 : Pas de notifications push

C'est le fossé le plus important. Avec un agent de codage IA, le workflow le plus précieux est :

1. Envoyer une tâche : "Refactorise le module de paiement pour utiliser la nouvelle API"
2. Ranger son téléphone
3. Être notifié quand Claude finit ou a besoin d'une saisie
4. Examiner et continuer

SSH ne peut pas faire l'étape 3. Le protocole SSH n'a pas de mécanisme pour envoyer des notifications à un appareil mobile. La connexion TCP n'existe que tant que votre client SSH est au premier plan (ou avec Mosh, tant que la session UDP est active). Et même alors, il n'y a pas de pont entre "des données sont apparues dans le terminal" et "envoyer une notification push à cet appareil".

Vous pouvez contourner cela avec des scripts shell qui envoient des notifications via des services externes, mais c'est une infrastructure fragile à construire et maintenir vous-même.

Approche WebSocket : Le serveur surveille la sortie de Claude Code et les événements de hooks. Quand il détecte une fin de tâche ou une demande d'approbation, il envoie un événement structuré aux clients connectés. L'app iOS les convertit en notifications push natives. Pas de polling, pas de services externes.

Problème 2 : Comportement iOS en arrière-plan

iOS suspend agressivement les apps qui ne sont pas au premier plan. Un client SSH qui passe en arrière-plan a environ 30 secondes avant qu'iOS ne suspende ses connexions réseau. Après cela :

• SSH : La connexion tombe. Quand vous rouvrez l'app, vous obtenez une erreur "broken pipe". Vous vous reconnectez, mais vous avez perdu votre position de défilement et toute sortie produite pendant votre absence.
• Mosh : Mieux — il utilise UDP et peut reprendre. Mais vous ratez quand même tout ce qui s'est passé pendant la suspension. Et Mosh ne résout pas le problème de notification.

C'est une contrainte fondamentale d'iOS, pas un bug des clients SSH. Apple n'autorise pas les connexions réseau arbitraires en arrière-plan pour des raisons de batterie.

Approche WebSocket : Le serveur met en tampon la sortie terminal indépendamment de l'état de connexion du client. Quand l'app iOS revient au premier plan, elle se reconnecte automatiquement et effectue une restauration d'état en plusieurs étapes — rafraîchissant à 0.2s, 0.7s et 1.5s après reconnexion pour capturer l'état courant complet. Pendant ce temps, les événements critiques (fin de tâche, erreurs) sont délivrés comme notifications push même quand l'app est suspendue.

Problème 3 : Gestion de l'état de session

Les agents de codage IA exécutent souvent plusieurs tâches en parallèle. Vous pourriez avoir :

• Session A : refactoring du module d'authentification
• Session B : écriture des tests pour la couche API
• Session C : correction d'un bug en production

Avec SSH, gérer cela implique :

1. SSH vers votre Mac
2. S'attacher manuellement à la bonne session tmux : tmux attach -t session-a
3. Vérifier le statut, se détacher : Ctrl+B, D
4. S'attacher à la session suivante : tmux attach -t session-b
5. Répéter

Ça fonctionne, mais c'est manuel et sujet aux erreurs sur un clavier de téléphone.

Approche WebSocket : Le serveur expose la gestion de session comme des commandes structurées. L'app iOS affiche une liste de sessions actives avec leurs états. Tapez pour basculer. Créez de nouvelles sessions avec un sélecteur de chemin qui parcourt le système de fichiers de votre Mac. Supprimez des sessions d'un balayage. Le serveur gère toute l'orchestration tmux.

Problème 4 : Sémantique des événements d'agent

SSH transporte des octets bruts. Il ne comprend pas ce qui se passe dans le terminal. Il ne fait pas la différence entre Claude qui réfléchit, Claude qui écrit du code, Claude qui attend une approbation ou Claude qui termine une tâche.

Claude Code a un système de hooks qui exécute des scripts shell sur des événements spécifiques : démarrage de tâche, fin de tâche, événements de notification. Ces hooks sont la façon dont le serveur apprend les transitions d'état de l'agent.

Limite SSH : Il n'y a pas de moyen propre de router ces événements de hook à travers une session SSH. Vous auriez besoin d'un canal séparé (une autre connexion SSH, un service de webhook, quelque chose) fonctionnant en parallèle de votre session terminal.

Approche WebSocket : Le serveur reçoit les événements de hook via HTTP POST des scripts de hook de Claude Code. Il les parse, les déduplique (avec une fenêtre de 3 secondes pour éviter les alertes dupliquées), et les envoie à l'app iOS sur la même connexion WebSocket qui transporte les données terminal. Une seule connexion, plusieurs types de données.

Problème 5 : Authentification et contrôle d'accès

L'authentification SSH est puissante mais complexe pour les cas d'usage mobiles :

• La gestion des clés sur iOS est délicate
• Vous devez configurer sshd sur votre Mac
• Le transfert de port à travers le NAT nécessite une configuration supplémentaire
• Exposer SSH à internet demande une configuration de sécurité minutieuse

Approche WebSocket : Tactic Remote utilise l'authentification par clé API via WebSocket. Pour les connexions LAN, la clé API est optionnelle (votre réseau domestique est la frontière de confiance). Pour les connexions Cloudflare Tunnel, la clé API est obligatoire. L'app Mac génère une clé aléatoire de 32 caractères et la transfère via QR code — pas de gestion de fichiers de clé, pas de configuration sshd.

C'est un modèle de sécurité délibérément plus simple. Il échange la flexibilité de SSH contre la facilité de configuration. Si vous avez besoin des garanties de sécurité de l'authentification par clé publique SSH, SSH est le bon outil — mais probablement pour un cas d'usage différent.

Quand SSH est encore meilleur

SSH gagne quand :

• Vous gérez beaucoup de serveurs — SSH est le protocole standard pour l'accès serveur. Un client, beaucoup d'hôtes.
• Vous avez besoin de transfert de fichiers — SFTP/SCP sont intégrés à SSH. Tactic Remote ne fait pas de transfert de fichiers.
• Vous utilisez des outils non-Claude — SSH est agnostique. Il fonctionne avec toute application terminal.
• Vous avez besoin de transfert de port — les tunnels SSH sont éprouvés pour le proxy de services.
• Vos exigences de conformité imposent SSH — certaines organisations exigent SSH pour l'audit et le contrôle d'accès.

L'architecture en pratique

Voici à quoi ressemble l'architecture WebSocket pour Tactic Remote :

iPhone App                    Mac Server                    Claude Code
    │                             │                              │
    │  WebSocket (ws:// or wss://)│                              │
    │◄───────────────────────────►│  tmux send-keys              │
    │  • Terminal I/O             │─────────────────────────────►│
    │  • Session commands         │  tmux capture-pane           │
    │  • Event stream             │◄─────────────────────────────│
    │                             │                              │
    │  Push notification          │  HTTP POST /hook             │
    │◄────────────────────────────│◄─────────────────────────────│
    │  (via WebSocket event)      │  (Claude Code hook scripts)  │
    │                             │                              │

Le serveur se place entre le téléphone et Claude Code, ajoutant :

• Sémantique des événements (les octets terminal bruts deviennent des événements structurés)
• Gestion de session (un serveur, plusieurs sessions tmux)
• Résilience de reconnexion (état en tampon, restauration automatique)
• Routage des notifications (les événements de hook deviennent des notifications push)

SSH vous donnerait la connexion terminal brute (les flèches du haut), mais aucune intelligence intermédiaire.

Et Mosh ?

Mosh (Mobile Shell) est la suggestion la plus courante pour améliorer SSH sur mobile. Il utilise UDP au lieu de TCP, ce qui aide pour :

• Le roaming réseau (passage entre WiFi et cellulaire)
• La persistance de connexion (le serveur garde l'état même quand le client se déconnecte)
• L'écho local (retour de frappe instantané quelle que soit la latence)

Mosh améliore véritablement l'expérience SSH sur mobile. Mais il ne résout toujours pas les problèmes fondamentaux :

• Pas de notifications push
• Pas de conscience des événements d'agent
• Pas de gestion structurée de session
• Toujours soumis à la suspension en arrière-plan iOS (même si la récupération est plus rapide)

Si vous êtes attaché aux outils basés sur SSH, Blink Shell avec Mosh est la meilleure option iOS. C'est un bon outil qui résout un problème différent.

Conclusion

La question n'est pas "SSH ou WebSocket ?" comme comparaison abstraite de protocoles. C'est "de quel modèle d'interaction votre workflow a-t-il besoin ?"

Si vous gérez des serveurs et exécutez des commandes interactives, SSH est le bon protocole avec des décennies de fiabilité prouvée.

Si vous contrôlez un agent IA qui s'exécute de manière autonome, nécessite votre attention de façon intermittente, et bénéficie de notifications push et de gestion structurée d'événements, une architecture WebSocket dédiée résout des problèmes que SSH ne peut pas résoudre — non pas parce que SSH est défaillant, mais parce qu'il a été conçu pour une ère différente de l'interaction homme-machine.