Déployer un site depuis Claude Code

Le problème que ça règle

Vous travaillez dans un terminal, avec un assistant qui écrit et corrige votre code. Le projet est prêt. Et là, vous ouvrez un navigateur, vous vous connectez à une console d’hébergement, vous cherchez le bon bouton, vous copiez une URL. Rupture. Vous êtes sorti de l’endroit où vous travailliez pour aller cliquer ailleurs.

Le protocole MCP — Model Context Protocol — sert exactement à supprimer cette rupture. C’est une prise standard entre un assistant et un outil : le serveur MCP déclare ce qu’il sait faire, l’assistant l’appelle quand la conversation le demande. Pour un hébergeur, cela signifie que « mets ce projet en ligne » devient une phrase, pas une procédure.

Le brancher, en trois lignes

Le serveur est publié sur npm. Il n’y a rien à installer globalement : npx le télécharge et l’exécute à la demande. Il lui faut deux choses — l’adresse de l’API et un jeton, qui se récupère dans votre console.

{
  "mcpServers": {
    "swigs-cloud": {
      "command": "npx",
      "args": ["-y", "@swigs-cloud/mcp"],
      "env": {
        "SWC_API_URL": "https://swigs.cloud/api",
        "SWC_TOKEN": "<votre jeton>"
      }
    }
  }
}

Ce que le serveur expose, vérifié

Plutôt que de reproduire la documentation, nous avons interrogé le paquet publié directement, avec une poignée de main MCP brute sur l’entrée standard — ce que fait Claude Code au démarrage. Voici ce que le serveur répond.

initialize -> {"name": "swigs-cloud", "version": "0.1.0"} | protocole 2024-11-05

tools/list -> 5 outils
   deploy          name, directory, repo, port
   list_projects   (aucun paramètre)
   project_status  id
   logs            id
   redeploy        id

Cinq outils, et c’est tout. C’est délibérément peu : un serveur MCP qui expose quarante outils force l’assistant à choisir, et il choisit mal. Ceux-ci couvrent le cycle complet — mettre en ligne, voir l’état, lire le journal quand ça casse, remettre en ligne.

Ce que ça donne dans la conversation

Une fois branché, il n’y a plus de commande à retenir. On décrit ce qu’on veut, et l’assistant choisit l’outil.

> liste mes projets sur Swigs Cloud

• demo-ia-blog [running] https://demo-ia-blog.swigs.cloud — proj_01M1GSZ44J45…
• demo-vite-blog-3 [failed]  — proj_01M1GSWPT2YKQWRZJHRTG05TGW
• demo-vite-blog-2 [failed]  — proj_01M1GSR2TKN3933MJB945J8PN1
• demo-vite-blog [failed]  — proj_01M1GSMA7M5F1VBFBTY60K6JN5

Les trois échecs de cette liste sont réels — ce sont ceux d’un autre guide, où nous avons cassé un déploiement trois fois de suite pour comprendre pourquoi. Nous ne les avons pas retirés de la capture.

Ce qui se passe réellement quand vous dites « déploie »

Le serveur fait quatre choses, dans cet ordre, et rien d’autre. Le code tient en cent vingt-six lignes, il est publié sous licence MIT, et vous pouvez le lire avant de le brancher — ce que nous vous encourageons à faire pour n’importe quel serveur MCP, le nôtre compris.

• Il archive le dossier courant en tar.gz, en excluant node_modules, .git, dist et .next. Rien d’autre n’est exclu : vérifiez qu’aucun .env ne traîne dans le dossier.
• Il envoie l’archive, crée le projet, et laisse le constructeur détecter la nature du code.
• Il interroge l’état toutes les trois secondes, jusqu’à deux minutes.
• Il retourne l’URL si c’est en ligne, ou vous renvoie vers l’outil logs si ça a échoué.

function archiveDirectory(dir: string): Buffer {
  const tgz = join(tmpdir(), `swc-${Date.now()}.tar.gz`);
  execFileSync('tar', [
    'czf', tgz,
    '--exclude=node_modules', '--exclude=.git',
    '--exclude=dist', '--exclude=.next',
    '-C', dir, '.',
  ], { env: { ...process.env, COPYFILE_DISABLE: '1' } });
  ...
}

Un serveur MCP est un programme qui agit

Il faut le dire clairement, y compris à propos du nôtre : brancher un serveur MCP, c’est donner à un assistant le droit d’exécuter des actions avec vos identifiants. Ce n’est pas une extension de navigateur, c’est un programme qui tourne sur votre machine avec vos droits.

Trois réflexes valent pour tous les serveurs MCP, quels qu’ils soient : lisez le code avant de le brancher — s’il n’est pas lisible, ne le branchez pas ; donnez-lui un jeton dont vous connaissez la portée ; et souvenez-vous que npx -y ira chercher la dernière version publiée à chaque démarrage, ce qui est commode et signifie que vous exécutez du code que vous n’avez pas relu. Épinglez une version si cela vous gêne — @swigs-cloud/mcp@0.1.0.

Ce qu’il faut retenir

Un serveur MCP d’hébergement supprime l’aller-retour vers une console pendant qu’on code. Le gain est réel mais modeste : il fait gagner des minutes, pas des heures. Ce qu’il change vraiment, c’est que l’assistant qui a écrit le code est aussi celui qui le met en ligne, et qui peut donc lire le journal d’erreur et corriger dans la foulée, sans que vous serviez de messager entre deux fenêtres.