Connecter une IA à votre serveur : déploiement et administration par un agent IA

Jusqu'ici, la plupart des gens utilisent l'IA comme un collègue très érudit au bout du fil : on décrit un problème de serveur, on se voit proposer une commande, on la copie dans la console, on recolle le message d'erreur dans le chat et on recommence jusqu'à ce que tout fonctionne. Dès que vous connectez l'IA à votre serveur, ce détour disparaît. Un agent IA comme Claude Code, OpenAI Codex CLI ou Gemini CLI se connecte lui-même au serveur via SSH, lit les journaux, vérifie la configuration, applique les modifications, teste le résultat et consigne ce qu'il a fait. Vous fixez la tâche et vous validez les étapes qui ne peuvent pas être annulées.

Cet article est un retour d'expérience. Chez KernelHost, un agent IA prend part chaque jour, depuis des mois, au travail sur notre propre infrastructure : portail client, supervision, flux de paiement, documentation. Nous montrons comment la connexion entre l'agent et le serveur est construite, selon quelle procédure l'agent déploie sur les systèmes de production, quelles règles évitent que quelque chose tourne mal ou fuite vers l'extérieur, et ce qu'un serveur doit offrir pour que l'ensemble fonctionne. Les bases sur les outils et les architectures se trouvent dans l'article Serveur géré par IA : connecter des agents IA en toute sécurité, l'installation sur le serveur dans le guide pour Claude Code et Codex CLI.

Connecter l'IA au serveur : ce que cela signifie

Connecter une IA au serveur, c'est donner à un agent IA son propre accès contrôlé à la ligne de commande du serveur, le plus souvent au moyen d'une clé SSH. À partir de ce moment, l'agent ne se contente plus de proposer des commandes : il les exécute lui-même, lit la sortie et en déduit l'étape suivante. Le modèle de langage lui-même continue de tourner chez le fournisseur (Anthropic, OpenAI ou Google) ; sur votre ordinateur ou votre serveur ne tourne qu'un outil en ligne de commande léger, qui envoie les commandes.

Le mot décisif est « contrôlé ». Un agent disposant d'un accès au serveur n'est pas un pilote automatique, mais un collaborateur très rapide qui demande avant toute action intrusive. C'est vous qui décidez de ce qu'il peut faire sans demander : de la simple lecture jusqu'à l'installation autonome de mises à jour selon une procédure établie.

Chatbot ou agent : la différence en un tableau

Une demi-heure d'allers-retours se réduit ainsi souvent à quelques minutes, et la source d'erreur « mal recopié » disparaît complètement.

Ce qu'un agent IA accomplit sur le serveur : exemples tirés de notre exploitation

Les exemples suivants sont tirés de notre quotidien. Nous omettons les noms, les adresses et les identifiants, mais les procédures sont réelles.

Déploiements avec sauvegarde et retour arrière

Quand nous modifions quelque chose dans le portail client ou dans un script serveur, l'agent se charge du déploiement. Il compare d'abord le fichier présent sur le serveur à la dernière version connue, afin de ne pas écraser la modification de quelqu'un d'autre. Il crée ensuite une sauvegarde datée en dehors du répertoire web, écrit un script de retour arrière, vérifie la syntaxe du nouveau fichier, le met en place avec les mêmes propriétaires et les mêmes droits qu'auparavant, puis teste la fonction concernée. Ce n'est que lorsque tout est au vert qu'il annonce que le travail est terminé. La procédure exacte est décrite plus bas, dans la section consacrée au déploiement.

Dépannage : du symptôme à la cause en quelques minutes

« Le site n'est pas joignable depuis notre bureau, mais il l'est en déplacement. » Autrefois, cela aurait signifié une longue recherche. L'agent vérifie les règles du pare-feu, parcourt les journaux du logiciel de protection à la recherche de l'adresse du bureau, trouve la règle qui s'est déclenchée et explique quelle requête l'a provoquée. La décision sur ce qu'il faut faire nous revient, le travail de détective non. Face aux erreurs typiques des serveurs web, comme 502 Bad Gateway ou un disque plein, il procède de la même manière : il consulte journalctl et les journaux de l'application, formule une hypothèse et l'étaye avant de modifier quoi que ce soit.

Une supervision que l'agent construit lui-même

Une grande partie de notre supervision est née en collaboration avec l'agent : de petits scripts de contrôle qui, toutes les quelques minutes, testent un service de bout en bout via une tâche cron et qui, en cas d'erreur, envoient un message sur le téléphone, par exemple par un bot Telegram. L'agent écrit le script, le teste en provoquant volontairement une erreur, met en place la tâche cron et documente la façon de couper l'alarme. La manière de construire un tel dispositif est expliquée dans l'article Mettre en place un monitoring serveur.

Vues d'ensemble et nettoyage

Quels serveurs tournent encore alors que le contrat correspondant a été résilié ? Quels services complémentaires sont payés, mais ne sont plus utilisés ? L'agent répond à ce genre de questions en interrogeant les bases de données et les API en lecture seule, puis en présentant le résultat sous forme de tableau. Il n'a le droit de faire le ménage qu'après validation, et il vérifie au préalable que la machine est réellement inutilisée, par exemple d'après son trafic des derniers jours.

Une documentation qui s'enrichit d'elle-même

Chaque modification se termine par une entrée dans le journal des modifications et, si nécessaire, par un complément dans le manuel d'exploitation. Cela coûte quelques secondes à l'agent et nous fait gagner des heures par la suite, car la question « Au fait, pourquoi est-ce comme ça ? » a une réponse écrite.

Les avantages quand l'IA travaille directement sur le serveur

• Rapidité : l'agent lit en quelques secondes ce qui prend des minutes à un humain, et il teste une hypothèse immédiatement au lieu de commencer par la décrire.
• Exhaustivité : il lit toute la configuration, fichiers inclus, ainsi que les lignes de journal autour de l'erreur, et pas seulement l'extrait que quelqu'un a jugé pertinent.
• Une procédure constante : sauvegarde, vérification de la syntaxe et contrôle ont lieu à chaque fois, y compris le vendredi soir et pour la vingtième petite modification.
• Une documentation sans effort supplémentaire : chaque modification est décrite, avec sa raison, l'emplacement de la sauvegarde et le retour arrière.
• L'automatisation sans apprendre à écrire des scripts : scripts de contrôle, tâches cron et rapports naissent d'une description en langage courant et sont testés avant leur mise en service.
• Apprendre au passage : l'agent explique ce qu'il fait et pourquoi. En suivant ses explications, on comprend nettement mieux son serveur au bout de quelques semaines.

Trois architectures, et celle que nous utilisons

Il existe trois façons éprouvées de connecter un agent à un serveur. Elles se distinguent par l'endroit où tourne l'outil et par celui où se trouvent les identifiants.

Notre choix : l'agent sur le poste de travail, les serveurs via SSH

Nous travaillons avec la première variante. L'agent tourne sur le poste de travail, chaque serveur a une entrée dans la configuration SSH, et l'agent se connecte avec sa propre clé. La raison principale : nous gérons de nombreux systèmes, et c'est précisément ainsi qu'un seul agent peut, dans une même session, suivre une cause à travers plusieurs serveurs, par exemple du serveur web à la base de données, puis jusqu'au pare-feu. De plus, la connexion au fournisseur IA et les clés se trouvent à un endroit que nous protégeons de toute façon. Si vous n'avez qu'un serveur et souhaitez des rapports automatiques la nuit, la deuxième variante vous conviendra bien. Les avantages et les inconvénients sont détaillés dans l'article sur le serveur géré par IA.

Guide : connecter un agent IA au serveur via SSH

Les sept étapes suivantes fonctionnent de la même manière avec Claude Code, Codex CLI et Gemini CLI. Les exemples utilisent l'adresse de documentation 203.0.113.10 et le nom d'utilisateur deploy : remplacez-les par vos propres valeurs. Le prérequis est un serveur avec connexion par clé SSH, comme décrit dans l'article Sécuriser SSH et mettre en place l'authentification par clé.

Étape 1 : générer une clé SSH réservée à l'agent

L'agent ne reçoit jamais votre clé personnelle, mais une clé à lui. Vous pouvez ainsi lui retirer l'accès à tout moment sans perdre le vôtre, et les journaux montrent quelle connexion provient de l'agent.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 est compact, rapide et réputé sûr. Le commentaire ki-agent apparaît ensuite dans le fichier authorized_keys du serveur et rend la clé reconnaissable au premier coup d'œil.

Étape 2 : déposer la clé publique sur le serveur

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Pour restreindre davantage l'accès, ajoutez des options devant la clé dans le fichier ~/.ssh/authorized_keys du serveur. from= n'autorise la connexion que depuis une adresse précise, no-agent-forwarding et no-port-forwarding empêchent la connexion de servir de point de rebond :

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Si le serveur répond ensuite Permission denied (publickey), l'article Corriger l'erreur SSH Permission denied (publickey) vous aidera.

Étape 3 : créer un alias d'hôte dans la configuration SSH

Grâce à un alias, l'agent n'a besoin de connaître qu'un nom court et utilise toujours la bonne clé :

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

Ensuite, ssh web-prod "systemctl status nginx" suffit. IdentitiesOnly yes empêche SSH d'essayer une à une d'autres clés de votre trousseau. Pour chaque serveur supplémentaire, créez un bloc distinct, de préférence avec des noms différents pour les systèmes de test et de production, comme web-test et web-prod, afin qu'une confusion saute aux yeux dès le nom.

Étape 4 : installer l'agent et se connecter

Claude Code, Codex CLI et Gemini CLI fonctionnent sous Linux, macOS et Windows et se connectent avec un compte chez le fournisseur ou avec une clé API. L'installation et la connexion sans navigateur sont décrites dans le guide pas à pas. Pour la variante poste de travail, installez l'outil sur votre ordinateur, pas sur le serveur.

Étape 5 : définir les règles que l'agent respecte

Au démarrage, les trois outils lisent un fichier de règles dans le répertoire de travail : Claude Code lit CLAUDE.md, Codex CLI AGENTS.md et Gemini CLI GEMINI.md. On y décrit la façon de travailler sur vos serveurs. Un point de départ éprouvé :

# Règles pour travailler sur les serveurs

- Avant chaque modification, créer une sauvegarde datée, en dehors du répertoire web.
- Avant de déployer, vérifier la syntaxe (nginx -t, php -l, apachectl configtest).
- Après le déploiement, vérifier le service, le journal et la fonction, puis signaler le résultat.
- Ne jamais afficher les mots de passe, clés API et tokens, ne jamais les copier dans des fichiers.
- Suppressions, modifications de base de données et tout ce qui est irréversible : uniquement après validation explicite.
- Ne pas modifier directement les fichiers gérés par le panneau de contrôle.
- Supprimer les fichiers de test après le test.

Les règles évoluent avec le temps. Chaque fois que l'agent fait quelque chose autrement que vous ne le souhaitez, la correction doit rejoindre ce fichier sous forme de règle. Au bout de quelques semaines, il travaille comme vous le feriez vous-même.

Étape 6 : configurer les validations et la liste blanche

Par défaut, les outils demandent avant chaque commande qui modifie quelque chose. C'est la bonne approche au début. Les commandes en lecture que vous confirmez sans arrêt peuvent être autorisées. Dans Claude Code, cela se fait dans le fichier .claude/settings.json :

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Tout ce qui ne figure pas sur cette liste nécessite toujours votre accord. Les options qui désactivent toutes les demandes de confirmation ont leur place, tout au plus, sur une machine de test jetable.

Étape 7 : une première tâche en lecture seule

Commencez par des tâches qui ne peuvent rien modifier et observez comment l'agent procède :

Vérifie sur web-prod les erreurs nginx des dernières 24 heures et nomme les trois
causes les plus fréquentes, avec pour chacune une preuve tirée du journal. Ne modifie rien.

Ce n'est que lorsque les analyses sont justes que viennent de petites modifications, comme une nouvelle rotation des journaux ou un service systemd, et seulement ensuite des déploiements sur le système de production.

Comment l'agent déploie : notre procédure pour chaque modification en production

Un agent IA ne doit déployer sur un système de production qu'en suivant une procédure fixe, qui comprend une sauvegarde, un retour arrière préparé et une vérification avant et après le déploiement. Chez nous, cette procédure se présente ainsi :

1. Vérifier l'état actuel. Le fichier présent sur le serveur est comparé à la dernière version connue. Si quelqu'un d'autre l'a modifié entre-temps, l'agent s'arrête et pose la question au lieu d'écraser cette modification.
2. Créer une sauvegarde. Les fichiers concernés sont copiés, avec la date, dans un dossier de sauvegarde situé en dehors du répertoire web. Une sauvegarde placée dans le répertoire web pourrait, selon les cas, être accessible publiquement.
3. Préparer le retour arrière. Un petit script qui restaure l'ancien état en une seule commande est écrit avant la modification, et non en pleine urgence.
4. Vérifier la syntaxe. Le nouveau fichier est contrôlé avant le déploiement, avec php -l pour PHP et nginx -t pour nginx. Une erreur de syntaxe n'atteint ainsi jamais le système de production.
5. Déployer avec les bons droits. Le propriétaire, le groupe et les droits du fichier sont repris de l'ancienne version. Après les erreurs de syntaxe, des droits incorrects sont la cause la plus fréquente de pannes après une mise à jour.
6. Tester sans effets de bord. Les tests se font en lecture, avec des données de test fictives ou dans un environnement isolé, jamais avec de vraies commandes ni de vraies données clients.
7. Vérifier en production. Le statut HTTP, le journal d'erreurs et la fonction modifiée sont contrôlés après le déploiement.
8. Documenter. Le journal des modifications et le manuel d'exploitation sont complétés, avec l'emplacement de la sauvegarde et la commande de retour arrière.

Sous forme de suite de commandes, avec des chemins d'exemple au lieu de chemins réels, cela ressemble à peu près à ceci :

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Pourquoi le retour arrière est préparé avant la modification

Quand une erreur survient, personne n'est dans les meilleures dispositions pour concevoir un retour arrière propre. Si le script est déjà prêt, l'annulation ne prend que quelques secondes, et l'agent peut aussi l'exécuter lui-même si la vérification après le déploiement échoue. C'est la plus grande différence entre un agent qui modifie quelque chose « vite fait » et un agent à qui l'on confie un système de production.

Des tests qui ne peuvent rien casser

Beaucoup de fonctions ne se testent pas sans que quelque chose se produise : une commande, un paiement, un e-mail. Trois techniques aident ici. Premièrement, les exécutions à blanc que l'outil propose lui-même. Deuxièmement, des ID inventés dont on est certain qu'ils n'existent nulle part. Troisièmement, un environnement isolé : un processus qui tourne dans son propre espace de noms réseau, sans aucun réseau (unshare -n), ne peut ni joindre une API externe ni acheter quoi que ce soit par erreur, mais il voit toujours la base de données locale via le socket Unix. Après le test, tous les fichiers de test sont supprimés.

Les actions qui coûtent de l'argent ont besoin d'un verrou

Quand une procédure commande, facture ou supprime quelque chose, elle ne doit pas tourner deux fois en même temps, pas même quand quelqu'un double-clique ou que l'agent répète une commande. La solution la plus simple sous Linux est flock :

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "déjà en cours"

Dans les applications de base de données, un verrou nommé (GET_LOCK dans MySQL et MariaDB) remplit le même rôle, et pour les API, c'est une Idempotency-Key qui s'en charge. Nous y revenons plus bas avec la KernelHost API.

Sécurité : un accès pour l'agent sans que rien ne fuite

L'inquiétude que nous entendons le plus souvent : « Et mes données, dans tout ça ? » La réponse honnête : tout ce que l'agent lit, il l'envoie pour traitement au modèle de langage du fournisseur. C'est pourquoi les règles suivantes vous permettent de décider de ce qu'il a le droit de voir.

Les secrets n'ont rien à faire dans le chat

Les mots de passe, clés API et tokens ne sont jamais écrits dans une tâche et jamais affichés par l'agent. Les scripts les lisent dans des fichiers aux droits 600, que l'agent n'a pas besoin d'afficher pour utiliser le script. Si une clé atterrit malgré tout dans le chat, elle est aussitôt révoquée chez le fournisseur et régénérée. Les fragments n'y ont pas leur place non plus : les premiers caractères d'une clé n'aident personne à trouver une erreur, mais ils raccourcissent le travail d'un attaquant.

Des clés dédiées, des droits dédiés, révocables à tout moment

Chaque agent reçoit sa propre clé SSH, et chaque clé se reconnaît à son commentaire dans authorized_keys. Pour retirer l'accès, on supprime cette seule ligne. Lorsque c'est suffisant, l'agent travaille avec son propre utilisateur et une règle sudo qui n'autorise que les commandes nécessaires. Les API reçoivent leurs propres clés, avec les droits les plus restreints possible, en lecture seule pour les simples analyses.

Validations : ce qui ne se fait jamais sans un humain

Chez nous, sans accord explicite, l'agent n'a pas le droit de supprimer, d'écrire dans des bases de données, d'assouplir des règles de pare-feu ou de protection, d'arrêter des machines ni de commander quoi que ce soit. Les outils vont dans ce sens : Claude Code met en pause les actions intrusives et peut en outre être configuré pour qu'un filtre de sécurité détecte les commandes risquées et les bloque jusqu'à leur validation. Un exemple tiré de notre quotidien : ce filtre a plus d'une fois arrêté une action correcte sur le fond, mais tout simplement irréversible. Elle ne s'est exécutée qu'après la validation explicite d'un humain. C'est exactement ainsi que cela doit se passer.

Traçabilité : journal, liste des modifications, sauvegardes

Chaque session laisse des traces lisibles par un humain : les sauvegardes datées, le script de retour arrière, l'entrée dans le journal des modifications et les connexions dans le journal système. Si vous gérez en plus /etc dans Git avec etckeeper, vous voyez chaque modification de configuration sous forme de diff. Ce qui n'est pas traçable ne peut pas non plus être annulé. La base reste une stratégie de sauvegarde qui fonctionne, car un agent ne remplace pas une sauvegarde.

Quel serveur convient à un agent IA ?

Un serveur destiné à une administration assistée par IA a besoin d'un accès root complet, d'une connexion par clé SSH, de connexions sortantes sans restriction, d'une protection DDoS permanente et, idéalement, d'une API permettant de commander et de piloter des serveurs de façon automatisée. Il n'a pas besoin de GPU, car le modèle de langage tourne chez le fournisseur.

Pourquoi KernelHost pour des serveurs gérés par IA

En principe, un agent IA peut travailler avec n'importe quel serveur sur lequel il obtient un shell. En pratique, c'est pourtant l'environnement qui détermine la part de travail que vous pouvez réellement lui confier. Sur un serveur root KVM ou un serveur dédié KernelHost, il n'y a ni comptes restreints, ni obstacles aux connexions HTTPS vers les fournisseurs IA, ni engagement contractuel qui rendrait les essais coûteux. La protection DDoS permanente est active sans supplément sur chaque serveur, et pour les tâches gourmandes en calcul, il existe les Professional VDS avec des cœurs dédiés. La facturation se fait en PrePaid : pas de contrat, pas de durée minimale, pas de frais de mise en service. Si vous voulez d'abord essayer, commencez par le serveur de test gratuit.

La KernelHost API : votre agent commande et pilote lui-même des serveurs

Le levier le plus important se situe un niveau au-dessus du serveur individuel. Via la KernelHost API, un agent peut consulter les produits et les prix, commander des serveurs, lire l'état de ses services, démarrer, arrêter et redémarrer des serveurs, ainsi que déclencher et annuler des résiliations. « Prépare-moi un serveur de test » devient ainsi une seule tâche : l'agent commande la machine, attend sa mise à disposition, se connecte via SSH, installe l'application et communique l'adresse en retour.

Pour une utilisation par des agents, l'API est volontairement conçue avec prudence. Les clés API ne reçoivent que les droits dont elles ont besoin : une clé destinée aux analyses ne peut rien commander du tout. Une Idempotency-Key garantit qu'une commande que l'agent répète après une erreur de dépassement de délai n'est pas exécutée deux fois. Les requêtes sont limitées par clé, par compte et par adresse, si bien que même un agent pris dans une boucle infinie ne déclenche pas d'avalanche. Enfin, chaque consultation d'identifiants déclenche une notification par e-mail, pour que vous sachiez quand un agent a lu des identifiants.

Combien coûte un serveur géré par IA ?

Il y a deux postes de coûts. Premièrement, le serveur lui-même : pour un agent qui travaille via SSH, il n'a besoin d'aucun équipement particulier, n'importe quel serveur root sur lequel votre application tourne déjà suffit. Si l'agent tourne directement sur le serveur, l'outil lui-même n'a besoin que de quelques centaines de mégaoctets de mémoire vive, et un serveur root avec 2 vCPU et 4 Go de RAM suffit si peu d'autres services y tournent. Deuxièmement, le modèle de langage : soit un abonnement chez le fournisseur, qui inclut l'utilisation de l'outil en ligne de commande, soit une clé API facturée à l'usage. En usage quotidien intensif, l'abonnement revient généralement moins cher ; pour les tâches automatisées sans humain devant, la clé API est la voie propre, car elle peut être plafonnée par un budget mensuel. Vous trouverez les prix actuels des serveurs sur la page Louer un serveur root.

Erreurs fréquentes et comment les éviter

• L'agent travaille avec la clé personnelle de l'administrateur. Son accès ne peut alors ni être retiré séparément ni être distingué dans les journaux. Solution : une clé dédiée, avec son propre commentaire.
• Toutes les demandes de confirmation sont désactivées. Cela économise des clics le premier jour et coûte un serveur tôt ou tard. Solution : une liste blanche pour les commandes en lecture, une validation pour tout ce qui est intrusif.
• Aucune sauvegarde avant la modification. Solution : la sauvegarde et le script de retour arrière comme règle fixe dans CLAUDE.md ou AGENTS.md.
• Des sauvegardes dans le répertoire web. Un fichier comme config.php.bak à la racine du site peut être accessible publiquement, mot de passe de la base de données compris. Solution : un dossier de sauvegarde en dehors du répertoire web, avec les droits 700.
• Des secrets dans le prompt. Solution : les identifiants uniquement dans des fichiers aux droits 600 lus par les scripts, et en cas d'erreur, les régénérer immédiatement.
• Double exécution. Un double-clic ou une requête répétée commande deux fois. Solution : un verrou avec flock ou une Idempotency-Key.
• Des fichiers gérés par le panneau de contrôle modifiés directement. Le panneau les écrase à la prochaine mise à jour ou plante à cause d'eux. Solution : exclure ces fichiers dans les règles et effectuer les modifications via le panneau ou son API.
• Des sorties reprises sans vérification. Un agent qui ne comprend pas une sortie devine. Solution : exiger des preuves (« montre-moi la ligne du journal ») et faire vérifier les résultats en conditions réelles.

En résumé

• Connecter une IA au serveur, c'est donner à un agent comme Claude Code, Codex CLI ou Gemini CLI sa propre clé SSH et des règles claires.
• L'agent lit les journaux, applique les modifications, vérifie le résultat et le documente ; les étapes intrusives ne s'exécutent qu'après validation.
• Chaque déploiement suit une procédure fixe : vérifier l'état actuel, sauvegarder, préparer le retour arrière, vérifier la syntaxe, déployer, tester, vérifier en production, documenter.
• Les secrets n'ont jamais leur place dans le chat, et les actions qui coûtent de l'argent ont besoin d'un verrou contre la double exécution.
• Le serveur a besoin d'un accès root, de clés SSH, de connexions sortantes libres et d'une protection DDoS, mais pas de GPU.
• Les serveurs KernelHost remplissent toutes ces exigences d'emblée, en PrePaid sans engagement, et grâce à la KernelHost API, l'agent peut même commander et piloter lui-même des serveurs.