Aller au contenu principal
Projet personnel

Conductor — Miroir mobile pour Claude Code

Miroir mobile sécurisé pour suivre et piloter une session Claude Code à distance

Conception & développement

NestJS Angular TypeScript SQLite WebSocket VSCode API
23
Workspaces analysés
791
Messages traités
16
Bugs corrigés (audit)

Le défi

Saad travaille au quotidien avec Claude Code en local dans VSCode, mais cet outil l’attache à son poste : rien ne permet de savoir, une fois loin de l’écran, qu’une longue tâche vient de se terminer ou qu’une approbation d’action est en attente. Claude Code n’expose aucune API officielle pour interroger cet état à distance. Le défi consistait à construire un miroir fiable de la session de travail sur son téléphone, sans exposer le code source à un serveur tiers, sans mot de passe partagé fixe, et en assumant clairement les limites d’un outil pensé pour un seul utilisateur sur une seule machine.

La solution

Conductor a été conçu comme un monorepo TypeScript (pnpm workspaces, mode strict) autour de trois composants communiquant via un package partagé @conductor/types, seule source de vérité du protocole d’échange :

  • un daemon NestJS 10, exécuté comme service Windows, qui stocke l’état local via better-sqlite3, surveille les fichiers de session avec chokidar et diffuse les mises à jour en WebSocket ;
  • une PWA Angular 18 installable sur téléphone (composants standalone, Signals, Angular Material, CodeMirror 6 et xterm.js) recevant les notifications push via web-push/VAPID ;
  • une extension VSCode compagnon, qui observe les transcripts JSONL de Claude Code et déclenche à distance l’ouverture d’une conversation ou l’acceptation d’un diff proposé.

Les résultats

Faute d’API officielle exposant l’état d’approbation de Claude Code, Saad a documenté et assumé une heuristique : surveiller le transcript JSONL de la session pour détecter un motif d’attente caractéristique — une solution pragmatique, explicitement présentée comme un "meilleur effort" plutôt qu’une garantie. Il a validé fonctionnellement l’outil sur ses propres données réelles : 23 workspaces, 249 sessions de chat et 791 messages correctement analysés et affichés, avec un test de bout en bout confirmant l’affichage sans erreur console des 23 cartes de workspace. Le projet reste un outil personnel, mono-utilisateur et mono-machine — pas un produit à l’usage quotidien prouvé dans la durée.

Méthodologie et gestion de projet

Une fois le MVP terminé, Saad a mené son propre audit de code en quatre passes, identifiant 5 bugs critiques et 11 bugs majeurs — dont la fonctionnalité phare de notification d’approbation, entièrement non fonctionnelle de bout en bout (le service worker n’était jamais enregistré), un affichage en double de chaque message de chat, et une boucle silencieuse de reconnexion WebSocket infinie. Les 16 anomalies ont toutes été corrigées dès le lendemain, lors d’une passe de correction dédiée. Cette démarche d’auto-vérification rigoureuse avant mise en confiance illustre une discipline propre à un profil de Tech Lead : ne jamais livrer sans avoir soi-même remis en question son propre travail.

Architecture technique et performance

Le daemon n’écoute que sur localhost (loopback), avec un port dédié à la PWA (HTTP + WebSocket) et un second port, protégé par secret, réservé à l’extension VSCode. L’accessibilité depuis le téléphone hors réseau local passe par un tunnel Cloudflare, sans ouverture de port ni serveur public — le code et les prompts ne transitent jamais par un serveur tiers, seul le relais du tunnel y passe. La sécurité repose sur des JWT à courte durée de vie combinés à des refresh tokens rotatifs hashés en bcrypt, des comparaisons de secrets en temps constant, et un appairage par code à 6 chiffres expirant après 10 minutes, plutôt qu’un mot de passe partagé fixe.

Accélération IA des Équipes

Questions fréquentes sur ce type de mission

Vous avez un projet similaire ?

Contactez-moi pour en discuter.

Discuter sur WhatsApp