Ton propre Claude Code, accessible depuis ton téléphone

L'application mobile te donne une conversation. Ce qui suit te donne autre chose : un terminal qui tourne en permanence sur ta propre machine, qui voit tes fichiers, tes dépôts et tes automatisations, et que tu peux déclencher depuis ton téléphone — dans la file d'attente, chez le coiffeur, n'importe où.

La différence n'est pas le confort, c'est ce qu'il peut faire. Une conversation te répond. Un terminal agit : il écrit dans tes fichiers, lance tes scripts, commite, déploie. Et comme il tourne chez toi, il n'oublie rien entre deux sessions.

Un VPS est un ordinateur loué, allumé en permanence, chez un hébergeur. C'est la seule pièce que tu ne peux pas remplacer par autre chose : il faut une machine qui reste debout quand ton portable est fermé.

Deux critères, et un seul compte vraiment :

• La mémoire vive. C'est là que ça se joue. Un agent qui code ouvre des processus, un navigateur sans interface, parfois un encodage vidéo. Quand la RAM sature, les symptômes ne ressemblent pas du tout à un manque de mémoire : un rendu s'arrête au milieu, une commande meurt sans message. Tu chercheras le bug pendant une heure au mauvais endroit.
• Le disque. Moins critique, mais il se remplit sans prévenir — images Docker, journaux, anciens déploiements. Un disque plein bloque les déploiements avec des messages qui parlent de tout sauf de disque.

Le processeur n'est pas le sujet : le modèle ne tourne pas chez toi, il répond depuis les serveurs d'Anthropic. Ta machine ne fait qu'orchestrer.

Coolify est une interface que tu installes sur ton VPS pour déployer des applications sans écrire de fichiers de configuration à la main. C'est ce qui transforme un serveur nu en quelque chose que tu peux piloter depuis un navigateur — y compris depuis un téléphone.

Tu t'en serviras pour trois choses : héberger Claude Code, héberger tes autres outils (une instance n8n, tes sites), et surtout redémarrer quelque chose quand tu n'es pas devant ton ordinateur.

Claude Code s'installe dans un conteneur Docker que Coolify gère comme n'importe quelle autre application. Le conteneur monte le dossier de travail que tu veux lui confier — tes dépôts, tes projets — et c'est tout ce qu'il voit.

L'utilisateur non-root, et pourquoi ça n'est pas un détail

Fais tourner le processus sous un utilisateur normal, pas sous root. La raison est très concrète : si l'agent écrit dans ton dépôt Git en tant que root, une partie des fichiers internes de Git appartiendra à root. Plus tard, tes commits échoueront — pas systématiquement, une fois sur vingt, ce qui est bien pire qu'une panne franche : tu croiras à un problème réseau, à un verrou, à n'importe quoi d'autre.

Concrètement, on appelle le binaire en imposant l'utilisateur :

Deux options méritent une explication :

• -p exécute une consigne et rend la réponse sur la sortie standard, sans session interactive. C'est ce qui rend l'appel utilisable depuis un script.
• --dangerously-skip-permissions supprime les demandes de confirmation. Sans elle, l'appel reste bloqué à attendre un « oui » que personne ne tapera. Le nom est volontairement alarmant : ne mets ce conteneur en contact qu'avec des dossiers que tu acceptes de voir modifiés.

Ce que ça coûte, et ce que ça ne coûte pas

Ce montage consomme ton abonnement, pas une facturation à l'usage. C'est exactement l'inverse d'un appel d'API classique, où chaque requête est débitée d'un solde de crédits. La distinction devient très concrète le jour où ton solde d'API tombe à zéro et où la moitié de tes automatisations s'arrête — pendant que ce terminal-là, lui, continue de répondre.

Les MCP sont les connecteurs qui donnent à l'agent l'accès à tes outils. Et il y a ici une limite qu'aucune documentation ne met en avant, parce qu'elle ne se voit pas sur un poste de travail.

Il existe deux façons pour un serveur MCP de communiquer : en lançant un programme local et en lui parlant par son entrée-sortie (stdio), ou par le réseau (HTTP / SSE).

Un serveur en stdio suppose qu'il peut démarrer un programme sur la même machine que le client. Dans un conteneur qui n'a ni ce programme ni son environnement, la connexion échoue — et l'échec ressemble à une erreur de configuration. Tu relis ton fichier de config dix fois, tu changes les chemins, tu recommences. Le fichier est bon ; c'est le transport qui ne passe pas.

La règle est donc simple, et elle conditionne le choix de tes outils : dans ce montage, ne retiens que les MCP joignables par HTTP ou SSE. Ça écarte certains connecteurs pratiques — mieux vaut le savoir avant de bâtir dessus qu'après.

C'est la partie qui donne son intérêt à tout le reste. Deux chemins, et ils ne se valent pas.

Le terminal web

Coolify donne un accès console dans le navigateur. Ça marche, et c'est parfait pour dépanner. Mais taper des commandes sur un clavier de téléphone, dans une file d'attente, n'est agréable à personne. À réserver à l'urgence.

Un déclencheur qui fait le travail — la bonne réponse

Le vrai usage mobile, ce n'est pas de taper des commandes : c'est de déclencher une tâche déjà écrite. Tu montes un webhook dans ton outil d'automatisation, il ouvre une connexion SSH vers le serveur, exécute la commande vue plus haut, et te renvoie la réponse — par message, par email, comme tu veux. Depuis ton téléphone, tu remplis un champ et tu ranges le téléphone.

Trois choses à savoir avant de brancher ça sur quoi que ce soit de sérieux :

1. La réponse est du texte libre, pas des données structurées. Si la suite de ta chaîne attend un format précis, demande-le explicitement dans la consigne et vérifie le résultat derrière. Sinon tu recevras une phrase là où tu attendais un objet.
2. Ce n'est pas instantané. L'appel traverse le réseau, le conteneur, puis une génération complète. On compte en dizaines de secondes, pas en millisecondes. Sur un webhook qui doit répondre tout de suite à quelqu'un, passe en asynchrone.
3. La consigne doit être sans ambiguïté. Le modèle interprète : si ton gabarit dit une chose et ta consigne réelle une autre, il suivra la consigne réelle et te le dira. C'est une qualité chez un humain, un piège dans une chaîne automatique.

Et surtout : protège ce déclencheur. Une URL qui exécute des commandes sur ton serveur ne doit pas être devinable. Mets une authentification dessus, dès le premier jour, pas « plus tard ».

Les quatre pannes que tu auras, dans l'ordre de fréquence. Aucune ne se présente sous son vrai nom — c'est précisément ce qui les rend coûteuses.

Une cinquième, plus sournoise : ce qui est mis en cache devant ton site. Si tu passes par un service comme Cloudflare, il garde les réponses — et les en-têtes — plusieurs heures. Tu corriges quelque chose, tu recharges, rien ne bouge, tu recorriges. Pour vérifier une correction, ajoute toujours un paramètre inutile à l'URL (?x=123) : ça force une vraie réponse au lieu d'une copie.

Comptez trois à sept heures pour la mise en place, selon votre aisance avec un serveur. C'est un investissement, pas un après-midi.

Ce que ça change : le temps mort redevient du temps de travail. Une idée qui arrive dans une file d'attente devient une tâche lancée, pas une note qu'on relira jamais. Et ce que l'agent produit reste sur ta machine, dans tes dépôts.

Ce que ça ne change pas, et qu'il faut entendre : ça n'écrit pas ta stratégie à ta place. Un terminal qui exécute vite amplifie ce que tu lui demandes — y compris les mauvaises décisions. L'outil sert ceux qui savaient déjà quoi faire et manquaient de temps. Si le problème est ailleurs, ce montage ne le réglera pas.