Déployer depuis votre assistant

Une ligne, et c’est branché

Collez la ligne ci-dessous dans un terminal, redémarrez votre client, et c’est branché. Il n’y a rien à installer, rien à télécharger, aucune configuration d’hébergement à écrire, et aucun jeton à copier.

ChatGPTClaude CodeClaude (web et Desktop)CodexCursorVS CodeWindsurfZedUn autre client

ChatGPT ne demande qu’une adresse. Collez celle-ci dans Réglages, Connecteurs, Ajouter un connecteur personnalisé, puis connectez-vous à Swigs Cloud sur l’écran qui s’ouvre.

adresse

https://swigs.cloud/api/mcp

Au premier usage, votre client ouvre une page Swigs Cloud qui demande votre accord. Vous vous y connectez, ou vous y créez votre compte, si vous n’en avez pas encore : trente jours d’essai, deux sites offerts, sans carte bancaire. L’autorisation se révoque à tout moment depuis le tableau de bord.

C’est le protocole qui fait le travail : le serveur répond au premier appel qu’une autorisation est nécessaire et indique où l’obtenir, le client s’enregistre seul et ouvre le navigateur. Nous demandions auparavant d’aller chercher un jeton dans la console et de le coller dans un fichier : cinq clics, un secret en clair sur le disque, et une configuration à refaire chaque semaine, puisque ce jeton expirait.

À partir de là, vous parlez à votre assistant comme d’habitude. Il sait désormais mettre un projet en ligne, en lister l’état, lire un journal et redéployer.

> liste mes projets sur Swigs Cloud

• demo-ia-blog [running] https://demo-ia-blog.swigs.cloud
• demo-next-suisse [running] https://demo-next-suisse.swigs.cloud
• demo-vite-blog-3 [running] https://demo-vite-blog-3.swigs.cloud
• demo-vite-node24 [running] https://demo-vite-node24.swigs.cloud

Aucune commande à retenir, aucun format à connaître. C’est tout l’intérêt du protocole qui se cache derrière : l’assistant découvre seul ce que le serveur sait faire, et choisit l’outil qui convient.

Le protocole est ouvert

MCP n’est pas une fonction de Claude : c’est un protocole. Tout client qui le parle en HTTP se branche sur la même adresse, et le sélecteur ci-dessus donne à chacun ce qu’il attend, une commande ou un fichier de configuration. Ceux qui n’y figurent pas encore acceptent presque tous le même bloc JSON.

Ce que l’assistant sait faire

Nous avons interrogé le serveur en direct plutôt que de recopier une documentation. Voici ce qu’il déclare.

deploy           name*, repo, files, slug, family, env, port
update_site      id*, files*
list_projects    (aucun paramètre)
project_status   id*
logs             id*
redeploy         id*
set_env          id*, env*
delete_project   id*

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

Envoyer un dossier plutôt qu’un dépôt

Le serveur distant sait recevoir des fichiers depuis le 10 septembre : deploy accepte files, et l’agent y met le code qu’il vient d’écrire. C’est la voie à privilégier, y compris pour un projet jamais poussé sur git, elle ne demande rien à installer.

Il reste un cas où elle ne suffit pas : envoyer un dossier déjà présent sur votre disque, volumineux, qu’on ne veut pas faire transiter par la conversation. Un serveur distant ne lit pas votre machine. Pour celui-là, il faut un serveur qui tourne chez vous. Il existe, sur npm, et npx s’en occupe.

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

Son outil deploy prend alors un paramètre de plus, directory, et l’archivage exclut node_modules, .git, dist et .next. Rien d’autre n’est exclu : vérifiez qu’aucun .env ne traîne dans le dossier avant d’envoyer.

Un serveur MCP est un programme qui agit

Il faut le dire clairement, à propos du nôtre comme des autres : brancher un serveur MCP, c’est donner à un assistant le droit d’exécuter des actions avec vos identifiants. Trois réflexes valent pour tous.

Lisez le code avant de le brancher : le nôtre fait cent vingt-six lignes, il est publié sous licence MIT, et s’il n’était pas lisible vous auriez raison de ne pas le brancher. Donnez-lui un jeton dont vous connaissez la portée. Et souvenez-vous que npx -y va 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, avec @swigs-cloud/mcp@0.1.0.

Ce qu’il faut retenir

Une commande à coller, aucun jeton, et l’assistant qui a écrit votre code est aussi celui qui le met en ligne. Le gain de temps est réel mais modeste. Ce qui change vraiment, c’est qu’en cas d’échec il lit le journal et corrige dans la foulée, sans que vous serviez de messager entre deux fenêtres.