Administrer un VPS avec un agent IA : guide SSH, Hermes et retour d’expérience sur 579 sites

Mis à jour le 24 octobre 2026 : Tutoriel et retour d’expérience sur des serveurs de production. Les identifiants, noms de machines et adresses techniques des exemples sont fictifs.

Vous éditez des sites web et l’idée de louer un VPS ou un serveur dédié vous intimide ? Je connais la difficulté : héberger des sites est une chose, maintenir Linux, PHP, les bases de données, le pare-feu et les sauvegardes en est une autre. Pourtant, il est aujourd’hui possible de confier une grande partie de ces interventions à un agent IA capable d’utiliser SSH, en gardant le contrôle des décisions importantes.

Ce n’est pas une promesse théorique. J’utilise Hermes pour m’aider à déployer, auditer et entretenir plusieurs serveurs. Il installe des panneaux d’hébergement, effectue des migrations WordPress, surveille les erreurs, organise les sauvegardes et m’accompagne lorsqu’une faille critique apparaît. Dans cet article, je détaille comment donner accès à un agent, puis je raconte deux opérations réelles d’octobre 2026 : une alerte PHP sur cinq serveurs déjà connectés et l’audit d’un VPS plus ancien raccordé ensuite à l’agent.

À retenir : un agent ne rend pas un VPS infaillible. Il vous aide à exécuter, documenter et contrôler l’administration. Les privilèges système restent puissants : gardez des sauvegardes testées et imposez une approbation humaine avant les modifications à risque.

1. Qu’est-ce qu’un agent IA administrateur de serveur ?

Un chatbot classique peut vous proposer des commandes Linux. Un agent outillé peut aller plus loin : il se connecte à un système, lit les configurations, lance des diagnostics, prépare des modifications et contrôle leurs effets. La différence est comparable à celle entre demander à quelqu’un de vous expliquer comment réparer un moteur et lui permettre de travailler réellement dans l’atelier : tout en lui demandant de présenter son plan avant de toucher aux pièces.

Hermes est l’outil que j’emploie, mais la méthode présentée ici s’applique à d’autres agents capables d’utiliser un client SSH et de respecter des instructions d’approbation. L’agent lui-même peut tourner sur une machine distincte du VPS : aucune obligation d’installer son moteur d’IA sur chaque serveur administré.

De la première installation à la maintenance quotidienne

Sur mes propres machines, je lui ai déjà confié des missions de plusieurs types :

• Déploiement initial : préparation d’un serveur neuf, comptes administrateurs, accès SSH et installation de Hestia Control Panel.
• Durcissement : pare-feu, contrôle des ports exposés, autorisations, restrictions des accès et protections contre les robots indésirables.
• Hébergement : installation de sites WordPress, certificats TLS, configuration PHP, base de données, cache et diagnostic des erreurs.
• Surveillance : inspections des journaux, scans planifiés quotidiens ou hebdomadaires, alertes Telegram en cas d’anomalie nécessitant une enquête.
• Sauvegardes : routines automatiques, stockage distant, contrôle des échecs et essais de restauration.
• Migration : transfert de sites, fichiers, bases et configurations d’un serveur à un autre, avec vérifications après bascule.
• Maintenance : audits de versions, correctifs de sécurité, recherches de régressions et suivi des incidents.

Dans la pratique, je préfère lui donner un objectif et des contraintes plutôt qu’une suite de commandes dictées à l’aveugle : « inventorie », « présente les risques », « sauvegarde », « ne modifie rien avant mon accord », puis « vérifie les sites après l’intervention ».

2. Mon organisation : une fiche Joplin par serveur comme mémoire

Un point joue un rôle important dans ma méthode : chaque serveur possède sa propre fiche Joplin. Hermes y conserve les informations opérationnelles utiles et la met à jour après les audits ou interventions. C’est une mémoire structurée, indépendante du fil d’une conversation.

Chaque fiche peut contenir un identifiant interne, le type de machine (VPS ou dédié), l’OS, le panneau d’administration, le port SSH, le chemin de la clé locale, les services essentiels, les sauvegardes existantes, la date du dernier audit et un journal des changements. Les informations sensibles doivent être rangées avec précaution : évitez les clés privées, les mots de passe ou les jetons en clair dans les notes. Une référence vers un coffre-fort sécurisé est préférable.

Cela change la manière de travailler. Quand je demande à Hermes d’intervenir plusieurs semaines plus tard, il peut relire la fiche, retrouver les choix de configuration et éviter de repartir de zéro. Après une correction, il inscrit les vérifications réalisées et les éventuelles tâches restantes.

3. Tutoriel : donner à un agent IA un accès SSH à son VPS

Pour être transparent sur ma méthode, je ne suis pas allé chercher une liste de commandes Linux pour réaliser cette installation. J’ai simplement expliqué à ChatGPT ce que je voulais faire, puis nous avons procédé étape par étape, en vérifiant chaque résultat avant de passer au suivant. Voici le type de demande que je lui ai adressée :

Je voudrais ajouter un utilisateur dédié à mon agent IA avec les droits sudo, comme mon utilisateur principal. Il doit pouvoir se connecter avec une clé SSH. Le serveur héberge des sites Internet via Hestia Control Panel. Le rôle de l’agent est d’être mon assistant d’administration système. Aide-moi à configurer cet accès, une étape à la fois, en vérifiant les résultats et sans modifier mon accès SSH existant.

Voici les étapes détaillées et expliquées. Vous pouvez reprendre ces instructions avec votre propre chatbot pour être accompagné à chaque étape, en adaptant les commandes et les paramètres à votre serveur.

Nous allons créer un compte distinct du compte personnel, avec une clé Ed25519 propre au serveur. L’exemple utilise Ubuntu ou Debian, un utilisateur d’administration existant et un port SSH personnalisé. Il ne nécessite pas de changer votre configuration SSH actuelle.

Voici les paramètres utilisés dans les commandes, avec des valeurs de démonstration à remplacer par les vôtres :

Étape 1 : Vérifier son accès administrateur

Sur votre ordinateur habituel, connectez-vous avec votre méthode SSH déjà fonctionnelle :

ssh -p 2222 [email protected]

Puis vérifiez l’accès sudo sur le VPS :

sudo id

Si la sortie commence par uid=0(root), votre compte peut exécuter des opérations administratives. Selon la configuration, sudo pourra demander votre mot de passe : c’est normal.

Étape 2 : Créer un compte séparé pour l’agent

Dans la session du VPS :

sudo adduser --disabled-password --gecos "" agentadmin

Le compte est créé sans mot de passe de connexion défini. Son répertoire personnel sera /home/agentadmin. Il ne possède pas encore de clé SSH ni d’autorisation sudo spéciale.

Étape 3 : Accorder les privilèges nécessaires

Pour un agent qui doit réellement administrer tout le serveur, ajoutez-le au groupe sudo :

sudo usermod -aG sudo agentadmin

Choix de sécurité important : un compte sudo non restreint peut prendre le contrôle de tout le serveur. Si votre usage se limite aux diagnostics, privilégiez un compte en lecture seule ou des commandes explicitement autorisées. Dans mon environnement d’administration complète, j’ai choisi une règle NOPASSWD pour éviter les demandes interactives de mot de passe ; ce n’est pas un réglage obligatoire ni le meilleur choix pour tous les lecteurs.

Si vous retenez volontairement ce niveau de privilèges, créez un fichier sudoers dédié :

echo 'agentadmin ALL=(ALL:ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/agentadmin

Vérifiez immédiatement sa syntaxe :

sudo visudo -cf /etc/sudoers.d/agentadmin

Puis son fonctionnement :

sudo -u agentadmin sudo -n id

Ne passez à la suite qu’une fois chaque test validé. Ne modifiez pas votre accès SSH principal pendant cette manipulation.

Étape 4 : Générer une clé SSH sur la machine de l’agent

Sur l’ordinateur où tourne Hermes (pas sur le VPS), créez une nouvelle paire de clés :

ssh-keygen -t ed25519 -f ~/.ssh/agent-vps-exemple -C "agentadmin@vps-exemple"

Vous obtenez agent-vps-exemple (privée) et agent-vps-exemple.pub (publique). Une paire distincte par serveur facilite la révocation. Pour une automatisation sans intervention, une clé sans passphrase est possible, mais expose davantage en cas d’accès non autorisé à la machine de l’agent ; un agent SSH avec déverrouillage contrôlé est préférable lorsque cela est possible.

Affichez uniquement la clé publique :

cat ~/.ssh/agent-vps-exemple.pub

Copiez la ligne complète. Ne partagez jamais la clé privée.

Étape 5 : Installer la clé publique dans le bon compte

Revenez sur votre session administrateur du VPS et créez le dossier SSH :

sudo install -d -m 700 -o agentadmin -g agentadmin /home/agentadmin/.ssh

Ouvrez ensuite le fichier des clés autorisées :

sudo nano /home/agentadmin/.ssh/authorized_keys

Collez la ligne ssh-ed25519 ... complète, enregistrez, puis appliquez les droits :

sudo chown agentadmin:agentadmin /home/agentadmin/.ssh/authorized_keys
sudo chmod 600 /home/agentadmin/.ssh/authorized_keys

Si le fichier existe déjà, ajoutez une ligne au lieu d’effacer les clés en place.

Étape 6 : Tester depuis le poste de l’agent

ssh -i ~/.ssh/agent-vps-exemple -o IdentitiesOnly=yes -p 2222 [email protected]

Vous devez obtenir une invite comparable à agentadmin@vps:~$. La première connexion peut demander la confirmation de la clé d’hôte : vérifiez son empreinte par un canal fiable avant de l’accepter. Gardez l’ancienne session administrateur ouverte jusqu’à la fin des tests.

Étape 7 : Vérifier l’accès à Hestia

Si Hestia est installé, depuis la session de l’agent :

sudo -n /usr/local/hestia/bin/v-list-sys-info json

Le serveur doit retourner un JSON contenant le système et la version de Hestia. Cette commande de lecture vérifie que le compte dispose effectivement des permissions nécessaires pour appeler la CLI Hestia. Sur un serveur sans Hestia, ignorez ce test.

À ce stade, l’agent est connecté. Commencez par un audit en lecture seule, avant de lui confier une modification en production.

4. Première mission à confier à l’agent : un audit sans modification

Voici une instruction pratique à personnaliser :

Tu es mon assistant d’administration système. Commence par inventorier les services, les versions PHP actives, le panneau d’hébergement, les sauvegardes, la configuration SSH, le pare-feu et les domaines hébergés. Ne modifie rien. Signale les risques classés par priorité, les prérequis des corrections et les vérifications après intervention. Ne redémarre aucun service et ne change aucune règle réseau sans ma validation explicite.

L’intérêt de cette approche est simple : le serveur réel peut disposer de configurations anciennes, de dépôts logiciels spécifiques et d’applications incompatibles avec certaines mises à jour. Le bon agent vérifie d’abord ce qui existe.

5. Cas réel n° 1 : l’alerte PHP du 21 octobre 2026 sur mes serveurs déjà connectés

Le 21 octobre 2026, mon hébergeur m’a prévenu de deux vulnérabilités critiques au niveau du moteur PHP : CVE-2026-109618 et CVE-2026-109619. Dans certaines conditions, elles permettaient une exécution de code à distance sans authentification. Les versions correctives du projet étaient PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les branches plus anciennes nécessitaient une migration ou des correctifs rétroportés spécifiques au fournisseur : elles ne recevaient plus les publications habituelles du projet PHP.

Lire l’annonce de la PHP Foundation et l’avis PHP officiel.

J’ai transmis le message de mon hébergeur à Hermes, en lui demandant en substance : « Vérifie mes autres VPS et dédiés : PHP est très utilisé dans notre infrastructure. Il s’agit d’une faille du moteur PHP, pas simplement d’une extension WordPress. »

Hermes a commencé par dresser un inventaire des branches installées sur mes machines déjà connectées : serveurs Hestia, Plesk et applications conteneurisées. Il a identifié les mises à jour disponibles, les rétroportages nécessaires, les dépôts problématiques et les machines qui ne pouvaient pas être corrigées de la même façon.

Des interventions coordonnées, mais pas aveugles

Après validation, l’agent a exécuté les mises à jour disponibles sur cinq serveurs. Ses contrôles ont porté sur 506 domaines, comparés avant/après intervention. Le rapport ne relevait aucune nouvelle indisponibilité ni erreur HTTP 5xx sur cet ensemble au moment des vérifications. Les configurations et les sauvegardes ont été conservées, avec des traces destinées au retour arrière.

Il restait cependant un cas particulier : le moteur PHP interne du panneau Plesk sur un serveur n’était pas encore corrigé. Hermes a adopté une mesure provisoire de réduction du risque : arrêt du panneau d’administration, tout en laissant les sites et les services web accessibles. Il a également expliqué pourquoi cette mesure devait être rendue persistante après redémarrage et demandait mon approbation.

Quelques jours après, une mise à jour Plesk Obsidian 18.0.81 Update 4 apportant le correctif était disponible et installée selon son contrôle. Le moteur du panneau utilisait alors PHP 8.4.27. J’ai autorisé la réactivation de Plesk : l’agent a remis le service en route, vérifié l’interface HTTPS d’administration et contrôlé à nouveau 62 domaines, sans nouvelle erreur 5xx détectée.

Le fait le plus intéressant, à mes yeux, n’est pas seulement l’installation des paquets. L’agent a isolé temporairement un composant vulnérable, signalé ce qu’il ne pouvait pas corriger immédiatement, puis levé la mesure uniquement après vérification du correctif et mon autorisation.

6. Cas réel n° 2 : connecter un ancien VPS, l’auditer et corriger ses failles

En faisant l’inventaire de mes machines, j’ai constaté qu’un VPS secondaire n’était pas encore connecté à Hermes. Ce serveur était déjà en production avant que j’utilise les agents IA pour l’administration. Comme il fallait aussi mettre PHP à jour, j’en ai profité, le 24 octobre 2026, pour lui donner accès à cette machine et appliquer exactement le même processus d’audit et de maintenance que sur mes autres serveurs.

Ce VPS sous Ubuntu et Hestia hébergeait 73 domaines, 41 comptes Hestia et 31 sites WordPress. J’ai suivi la procédure décrite plus haut : un compte Linux distinct, des droits adaptés, une clé SSH dédiée et un test de l’accès à la CLI Hestia. Puis j’ai demandé un audit de sécurité et la préparation des correctifs PHP.

L’agent trouve davantage qu’un simple PHP obsolète

Le premier rapport confirmait plusieurs branches PHP exposées, ainsi qu’un problème de clé du dépôt Nginx empêchant apt update de fonctionner normalement. Avant de modifier les paquets, l’agent a sauvegardé les configurations et les bases, puis simulé une transaction ciblée de 97 mises à jour, zéro ajout et zéro suppression.

Mais l’audit a également mis en évidence une anomalie distincte, beaucoup plus grave : dans la base de données d’un site WordPress, un ancien trigger MariaDB nommé after_insert_comment pouvait créer un compte administrateur en réaction à un commentaire contenant une chaîne secrète. D’après l’analyse, cette porte dérobée remontait au 5 mai 2026 : elle précédait donc les vulnérabilités PHP d’octobre. Aucun lien de cause à effet n’a été établi entre les deux événements.

L’agent a enregistré la définition du trigger et sauvegardé la base avant de supprimer précisément ce mécanisme. Il a ensuite confirmé son absence dans MariaDB et recherché la présence d’un compte suspect correspondant. Aucun compte résiduel correspondant n’a été identifié au moment de ses contrôles.

La suppression du trigger n’est qu’une première étape. Je peux maintenant demander à Hermes de poursuivre l’enquête : vérifier les comptes et les journaux, rechercher d’autres mécanismes de persistance et tenter de comprendre l’origine de l’intrusion. La correction d’un élément malveillant ne suffit pas, à elle seule, à garantir que tout le site est assaini.

La mise à jour s’achève sans nouvelle régression détectée

Après correction de la signature du dépôt Nginx et préparation des sauvegardes, Hermes a appliqué 97 mises à jour PHP. Selon son rapport :

• Les branches PHP 7.4, 8.0 et 8.1 ont reçu des paquets intégrant des rétroportages du mainteneur du dépôt : cela ne les rend pas pour autant à nouveau maintenues officiellement par PHP.
• Les branches PHP 8.2 et 8.3 ont été mises aux versions correctives disponibles.
• Les cinq services PHP-FPM et Apache ont été redémarrés, et les exécutables actifs vérifiés.
• Les 73 domaines ont été contrôlés avant/après. 65 étaient sains, huit présentaient déjà des anomalies DNS/HTTP, et aucune nouvelle régression n’a été constatée lors des tests.
• Les configurations PHP personnalisées ont été préservées ; les services essentiels, dont Hestia et MariaDB, ont été contrôlés.
• Des sauvegardes et des manifestes de vérification ont été conservés pour documenter les changements.

La suite du travail n’est pas facultative : sortir progressivement des anciennes branches PHP, résoudre les huit anomalies préexistantes, et approfondir l’enquête sur la compromission historique. Une version ancienne avec un rétroportage précis n’est pas équivalente à une branche maintenue à long terme.

7. Les règles que j’impose à mon agent IA

Je ne laisse pas l’agent modifier librement l’infrastructure sous prétexte qu’il sait utiliser sudo. Pour les tâches sensibles, ma méthode repose sur quelques principes :

1. Inventaire d’abord : identifier OS, panneaux, versions, dépôts, pare-feu et applications avant de prescrire une commande.
2. Sauvegarde vérifiée : un dump qui existe n’est pas nécessairement restaurable. Pour une opération à risque, prévoir une restauration testée et, si possible, un snapshot externe.
3. Simulation quand c’est possible : connaître les paquets ajoutés, retirés ou modifiés avant d’accepter une transaction.
4. Approbation explicite : changements SSH, pare-feu, effacements, redémarrages, mises à jour massives et actions irréversibles exigent ma validation.
5. Contrôles après action : vérifier services, processus réellement chargés, HTTPS, erreurs 5xx et fonctions essentielles des applications.
6. Journal d’intervention : consigner les décisions, commandes, sauvegardes et tâches restantes dans la fiche Joplin du serveur.
7. Accès minimaux : isoler les clés par serveur, protéger la machine de l’agent, limiter les sources IP via pare-feu ou VPN, et supprimer les droits devenus inutiles.

Un point mérite d’être souligné : un agent disposant de NOPASSWD:ALL peut faire beaucoup de dégâts, même sans intention malveillante. L’autonomie doit être proportionnelle à ce que vous êtes capable de restaurer, pas seulement à ce que l’agent sait exécuter.

8. Alertes Telegram, scans programmés et migrations : ce que j’utilise déjà

Ces possibilités ne sont pas de simples projets. J’ai déjà mis en place avec mon agent des scans planifiés et des alertes Telegram, ainsi que des routines de sauvegarde et de surveillance. Selon le serveur, les contrôles sont quotidiens ou hebdomadaires : journaux d’authentification, fichiers inattendus, versions, sauvegardes et disponibilité des sites. Quand une anomalie apparaît, une notification peut m’avertir pour que je décide de la suite. Une alerte automatique n’est pas une preuve de compromission : il faut analyser les indices et éviter les faux positifs.

J’utilise également Hermes pour les migrations de sites d’un serveur à un autre : inventaire, sauvegarde des fichiers et des bases, restauration sur le nouveau serveur, contrôles DNS/TLS, bascule et surveillance. Je le sollicite aussi dès la création de certains VPS neufs : préparation du système, installation de Hestia et mise en place des premières protections et sauvegardes.

Ces opérations sont accessibles sans avoir une connaissance exhaustive des commandes Linux, à condition de savoir formuler le résultat attendu, faire valider le plan, comprendre les risques majeurs et disposer d’un moyen de reprise en cas de problème.

9. Les questions que vous vous posez sur l’utilisation d’un agent Hermes

Faut-il installer Hermes directement sur chaque VPS ?

Non. Dans mon organisation, l’agent fonctionne sur une machine distincte et utilise SSH pour intervenir sur plusieurs serveurs. Cela évite d’installer le moteur de l’agent partout, mais impose de protéger sérieusement sa machine et ses clés.

Peut-on faire la même chose avec un autre agent ?

Oui, s’il est capable d’exécuter des commandes SSH de manière contrôlée et de gérer correctement ses autorisations. Les paramètres et l’installation varient selon l’outil.

Est-il prudent de donner les droits root à une IA ?

Pas sans conditions. Un accès complet augmente le risque d’erreur, de commande destructrice ou d’exploitation d’une instruction malveillante. Commencez en lecture seule, autorisez progressivement les opérations nécessaires et réservez les droits complets à un environnement correctement protégé et sauvegardé.

Un agent IA remplace-t-il un administrateur système ?

Non, notamment lors d’un incident grave ou lorsqu’il faut analyser un risque complexe. Il peut toutefois assister efficacement un éditeur de sites, préparer une grande partie du travail, documenter les actions et accélérer la maintenance quotidienne.

Est-ce que les mises à jour PHP suffisent à sécuriser WordPress ?

Non. WordPress, ses extensions, ses thèmes, les comptes administrateurs, les accès SSH, les sauvegardes et les bases de données nécessitent chacun une surveillance. L’ancienne porte dérobée SQL découverte lors de mon audit le démontre.

Conclusion : le VPS devient plus accessible, pas sans responsabilité

L’arrivée des agents IA capables d’agir sur des serveurs change la donne pour les éditeurs de sites. Je peux désormais faire intervenir Hermes sur des tâches qui auraient nécessité beaucoup plus de recherches et de manipulations manuelles : installation de Hestia, maintenance PHP, sauvegardes, contrôles de sécurité et migrations WordPress.

Le cas d’octobre 2026 est particulièrement parlant : une alerte urgente traitée sur cinq serveurs et 506 domaines contrôlés, puis un VPS historique de 73 domaines ajouté à la gestion de l’agent, avec une mise à jour PHP et la découverte d’une ancienne porte dérobée WordPress. Cela représente 579 contrôles de domaines répartis sur deux interventions, et non nécessairement 579 sites distincts.

Pour autant, je garde une règle simple : l’agent propose, documente et exécute dans le cadre que je fixe ; les opérations critiques restent sous mon contrôle. C’est cette combinaison, bien plus qu’une automatisation aveugle, qui rend l’exploitation d’un VPS envisageable pour des profils qui ne sont pas administrateurs système de métier.

Sources officielles : PHP Foundation : 21 octobre 2026 · Archive des annonces PHP · Documentation OpenSSH · Documentation Hestia