Après la commande : comment un agent IA gère seul son VPS via MCP

La plupart des démos où un agent achète un serveur s'arrêtent au moment où la commande passe. C'est le moment le moins intéressant. Le serveur existe, l'agent a un identifiant comme 47HZ7YF, et personne n'a dit ce qui se passe ensuite.

Ensuite, il y a tout ce qu'un admin fait sans y penser : attendre que SSH réponde vraiment, retrouver le mot de passe, remarquer que le disque se remplit, redémarrer après une mise à jour du noyau, renouveler avant la fin du mois, solliciter le support quand quelque chose cloche. Si un agent doit posséder de l'infrastructure, cette partie lui revient aussi. Voici comment cela se passe avec notre serveur MCP. Nous avons testé chaque étape dans notre environnement de test avant de l'écrire.

Si vous n'avez pas encore connecté de client, commencez par Claude Code et Codex ou Claude Desktop et Cursor.

Première minute : « active » ne veut pas dire « prêt »

order_vps répond dès que la commande est payée sur le solde. Le serveur est créé en arrière-plan, en général en une minute environ. L'appel suivant de l'agent est get_vps_status, qu'il peut répéter sans crainte : l'outil ne fait que lire.

Deux champs comptent. status passe à active quand la machine existe. access contient ce qu'il faut pour se connecter : hôte, port et une commande SSH toute prête. Sur les offres avec IPv4 propre, le port est 22. Sur les offres NAT, c'est un port redirigé personnel, et la réponse le dit explicitement, avec un avertissement : ne vous enfermez pas dehors avec un pare-feu qui n'autorise que le port externe.

Entre ces deux moments se trouve un trou où l'on trébuche. Le premier démarrage installe les mises à jour de l'OS, ce qui peut prendre quelques minutes, et SSH peut refuser les connexions pendant ce temps. Un agent soigneux attend access.ssh_ready au lieu de marteler le port 22.

Si la commande n'avait pas de clé SSH, le mot de passe root vous attend. reveal_password le donne exactement une fois, et seulement quand la VM a fini de démarrer. Si vous demandez trop tôt, vous obtenez password_pending sans consommer l'affichage unique. Nous l'avons conçu ainsi après avoir vu des agents récupérer un mot de passe que la VM, encore en démarrage, n'avait pas appliqué. Honnêtement, passez plutôt une ssh_key à la commande et sautez cette étape.

Deuxième jour : surveiller

get_vps_metrics renvoie CPU, mémoire, réseau et disque sous forme de séries temporelles sur la dernière heure, le jour, la semaine ou le mois. Un agent qui y jette un œil une fois par jour peut repérer ce qui tue les petits serveurs : la mémoire qui grimpe jusqu'à ce que l'OOM killer choisisse une victime. Il ne peut pas corriger la cause de l'extérieur, mais il peut vous prévenir ou se connecter en SSH pour regarder.

power_vps fait start, stop et reboot. Un détail vu en test : si le serveur n'est pas actif (encore en création ou suspendu pour un renouvellement impayé), l'outil répond 409 avec le conseil de vérifier d'abord l'état. Un agent qui traite toute réponse non-200 comme « réessayer indéfiniment » tournera en boucle ici. L'erreur lui dit quoi faire, car nos messages d'erreur sont écrits pour les agents autant que pour les humains.

set_hostname renomme la machine via l'agent invité qui tourne dedans, donc sous Linux le changement s'applique sans redémarrage. Supprimez qemu-guest-agent et l'outil cesse de fonctionner : il renvoie agent_unavailable et ne change rien.

Trentième jour : l'argent

C'est ici que l'infrastructure des agents meurt d'habitude. Le renouvellement est un rappel dans l'agenda de quelqu'un, ce quelqu'un est occupé, le serveur est suspendu.

Chez nous, le renouvellement ne dépend pas de la mémoire de l'agent. Chaque serveur se renouvelle chaque mois sur le solde prépayé, et l'e-mail du compte reçoit des rappels avant l'échéance. L'agent doit seulement garder le solde au-dessus du prochain prélèvement, et get_balance lui dit où il en est.

Il n'y a pas de délai de grâce : si le solde ne couvre pas le renouvellement à la fin de la période, le serveur est suspendu et son IP dédiée retourne dans le pool.

Quand le solde est bas, topup_balance génère un lien de paiement crypto : USDT, USDC ou ETH sur Base, Ethereum ou Polygon. C'est le premier endroit où l'agent a besoin de vous. Il peut créer la facture, mais il ne peut pas signer de transaction sauf si vous lui donnez un portefeuille, et nous y réfléchirions à deux fois. En pratique, on recharge une fois pour plusieurs mois et l'agent dépense sur ce solde. Si une commande ou une facture est restée impayée faute de solde, après votre recharge l'agent appelle pay_invoice et elle est payée sur le solde.

Une lacune honnête : les outils MCP ne renouvellent pas un serveur plusieurs mois à l'avance sur demande. Le renouvellement mensuel est automatique, et payer 3, 6 ou 12 mois d'avance se fait dans le tableau de bord ou avec un appel REST. Si vous voulez une durée plus longue dès le départ, order_vps accepte months (de 1 à 36) à la commande.

La croissance passe par get_upgrade_options et change_plan. L'offre change sur place, les fichiers et l'OS restent, le serveur redémarre une fois, et la différence de prix pour le reste de la période est prélevée sur le solde. L'agent doit passer confirm: true — notre façon de dire « tu dépenses de l'argent, sois sûr de toi ».

Quand ça tourne mal

Les actions destructives sont volontairement peu pratiques. reinstall_vps et un cancel_service immédiat exigent tous deux le hostname exact du serveur dans confirm, et leurs descriptions demandent à l'agent de consulter un humain d'abord. C'est le deuxième endroit où l'agent a besoin de vous, et c'est voulu.

La résiliation sûre, end_of_period, garde le serveur jusqu'à la fin de la période payée. undo_cancel l'annule, et c'est plus important qu'il n'y paraît : les agents changent d'avis en cours de tâche aussi souvent que les humains.

Quand l'agent est bloqué, create_ticket ouvre un ticket lié au serveur et reply_ticket poursuit l'échange. C'est une personne de notre côté qui le lit, pas un chatbot qui répond à un chatbot.

Et quand un humain doit intervenir, delegate_service l'invite par e-mail comme opérateur de ce seul serveur. Il obtient l'alimentation, la console, la réinstallation et le hostname. Il n'obtient ni la facturation, ni le renouvellement, ni la résiliation, et il ne voit jamais le jeton de l'agent.

Ce que l'agent ne peut toujours pas faire

Pour être clair sur les limites :

• Alimenter le solde. Il peut créer une facture de recharge et payer des factures sur le solde avec pay_invoice. Mettre de la crypto sur le solde demande un portefeuille, donc en général vous.
• Travailler dans l'OS via MCP. Paquets, configuration et déploiements passent par SSH. MCP gère la machine de l'extérieur.
• Lever une suspension seul. Si un serveur est suspendu pour abus, c'est une conversation avec une personne, et c'est voulu.

Rien de tout cela ne rend les outils moins utiles. Cela veut dire qu'il faut construire la boucle de l'agent autour d'eux : interroger l'état, garder le solde dans les clous, escalader par ticket et vous attendre pour tout ce qui supprime des données.

Si le travail de l'agent est de courte durée, un serveur entier n'est peut-être pas la bonne unité. VPS ou sandbox ? explique quand une microVM qui vit une minute convient mieux. Sinon, les offres sont ici, et la référence MCP liste chaque outil avec ses paramètres.