L'architecture derrière Tactic Remote : Construire une plateforme de codification distribuée

Construire une plateforme de développement à distance semble simple sur le papier : exécuter du code sur une machine, l'afficher sur une autre. En pratique, les défis d'ingénierie sont profonds. Chaque milliseconde de latence érode la confiance. Chaque connexion interrompue risque la perte de travail. Chaque raccourci de sécurité invite la catastrophe.

Cet article parcourt l'architecture de Tactic Remote — les décisions que nous avons prises, les compromis que nous avons acceptés et les principes qui guident notre direction technique.

Le problème central

Les développeurs s'appuient de plus en plus sur des outils de codification assistés par l'IA comme Claude Code, mais ces outils sont liés aux terminaux de bureau. Vous ne pouvez pas vous éloigner de votre bureau sans perdre la visibilité sur ce que fait votre assistant IA. Tactic Remote existe pour résoudre cela : votre Mac reste le moteur d'exécution, tandis que votre iPhone devient une surface de contrôle de premier ordre.

Le défi est de rendre cela fluide plutôt que de ressembler à une session de bureau à distance maladroite.

Architecture en couches

Tactic Remote est construit en quatre couches distinctes, chacune avec une frontière de responsabilité claire :

Couche 1 : Le moteur d'exécution (Mac)

À la base se trouve votre Mac exécutant Claude Code dans une session tmux. Nous avons choisi tmux délibérément — il fournit la persistance des processus, le multiplexage de sessions et une interface bien connue pour le contrôle programmatique du terminal. L'application compagnon Mac gère le cycle de vie de tmux, surveille la santé des sessions et expose une API HTTP légère pour les consommateurs en amont.

Décisions de conception clés à cette couche :

• Isolation des processus : Chaque session Claude Code s'exécute dans sa propre fenêtre tmux, empêchant la contamination croisée entre projets.
• Persistance de l'état : Les sessions tmux survivent aux redémarrages de l'app, aux coupures réseau et même aux cycles de mise en veille du système.
• Empreinte minimale : L'application compagnon ajoute une surcharge CPU et mémoire négligeable au repos.

Couche 2 : La couche de transport

Entre votre Mac et votre iPhone se trouve le transport — soit une connexion réseau locale directe, soit un Cloudflare Tunnel pour l'accès à distance.

Le mode local utilise mDNS/Bonjour pour la découverte des appareils et HTTP direct pour le transfert de données. Cela donne des temps aller-retour inférieurs à 10 ms sur un bon réseau, rendant la diffusion du terminal instantanée.

Le mode Cloudflare Tunnel achemine le trafic via le réseau edge de Cloudflare. Cela ajoute de la latence (typiquement 30-80 ms) mais permet l'accès de n'importe où — un café, un train de banlieue ou à l'autre bout du monde. Nous tirons parti du daemon cloudflared de Cloudflare côté Mac, qui établit une connexion sortante uniquement, ce qui signifie qu'aucun port n'a besoin d'être ouvert sur votre pare-feu.

┌─────────────┐         ┌──────────────────┐         ┌─────────────┐
│   iPhone    │◄───────►│ Couche transport  │◄───────►│     Mac     │
│ (Contrôle)  │   HTTP  │  Local / CF Edge  │   HTTP  │ (Exécution) │
└─────────────┘         └──────────────────┘         └─────────────┘

Couche 3 : Le gestionnaire de sessions

Le gestionnaire de sessions est le cerveau de l'opération. S'exécutant sur le Mac, il maintient un registre des sessions tmux actives, suit leur état (inactive, en cours d'exécution, en attente d'entrée) et gère la chorégraphie complexe de la reconnexion.

Lorsque votre iPhone se reconnecte après une interruption réseau, le gestionnaire de sessions doit répondre à plusieurs questions en millisecondes :

1. Quelles sessions étaient actives avant la déconnexion ?
2. De la sortie terminal s'est-elle accumulée pendant l'intervalle ?
3. Des sessions attendent-elles l'approbation de l'utilisateur pour des opérations sensibles ?
4. Quel est l'état actuel du processus de chaque instance Claude Code ?

Nous résolvons cela par une combinaison d'event sourcing (enregistrement des transitions d'état comme événements immuables) et de cache d'instantanés (capture périodique de l'état du buffer terminal pour une restauration rapide).

Couche 4 : L'interface mobile

L'application iPhone n'est intentionnellement pas un émulateur de terminal. Nous avons pris tôt la décision qu'entasser un terminal complet sur l'écran d'un téléphone créerait une expérience utilisateur terrible. Au lieu de cela, la couche mobile fournit :

• Vue conversation : Voir le raisonnement et les sorties de Claude dans un format lisible.
• Aperçu terminal : Accès rapide à la sortie brute du terminal quand nécessaire.
• Contrôles d'approbation : Approbation/rejet en un clic pour les opérations nécessitant une confirmation humaine.
• Pont de notifications : Notifications push pour les complétions de tâches et les demandes d'approbation.

Modèles de résilience

Les réseaux du monde réel ne sont pas fiables. Les téléphones perdent le signal dans les ascenseurs. Le Wi-Fi se coupe quand vous changez de pièce. Notre stratégie de résilience repose sur trois principes :

Considérer la déconnexion comme normale. Chaque composant est conçu pour fonctionner indépendamment pendant une partition réseau. Le Mac continue d'exécuter. L'iPhone met en cache le dernier état connu. La reconnexion déclenche un protocole de réconciliation d'état, pas un redémarrage complet.

Ne jamais perdre de travail. La sortie du terminal est mise en tampon côté Mac avec une rétention configurable. Même si votre iPhone est hors ligne pendant une heure, la reconnexion vous montre tout ce qui s'est passé.

Échouer visiblement. Quand quelque chose ne va pas, l'utilisateur voit un message d'erreur honnête, pas un spinner qui ne se résout jamais. Nous avons investi massivement dans des indicateurs d'état de connexion qui reflètent la réalité en quelques secondes.

Sécurité par conception

L'exécution à distance de code généré par l'IA soulève de sérieuses questions de sécurité. Notre modèle de sécurité est couvert en profondeur dans notre documentation du modèle de sécurité, mais les points forts architecturaux incluent :

• Transport zero-trust : Toute communication est chiffrée, que ce soit en local (TLS) ou par tunnel (couche de chiffrement de Cloudflare).
• Portes d'approbation : Les opérations sensibles (écritures de fichiers, commandes shell, accès réseau) nécessitent une approbation mobile explicite avant exécution.
• Aucune dépendance cloud : Votre code ne quitte jamais votre Mac. Tactic Remote est un plan de contrôle, pas un plan de données.

La suite

L'architecture n'est jamais terminée. Nous travaillons activement sur le support multi-Mac (connecter un iPhone à plusieurs machines de développement), les sessions collaboratives (plusieurs membres de l'équipe surveillant le même run Claude Code) et des intégrations IDE plus profondes. Chacune de ces fonctionnalités nécessite d'étendre l'architecture sans compromettre la fiabilité que nous avons construite.

Si vous construisez des outils distribués pour développeurs, nous espérons que cette vue d'ensemble est utile. Et si vous voulez expérimenter cette architecture de première main, commencez ici.