Héberger un agent IA sur VPS : installation et sécurité

Pour héberger un agent IA sur un VPS, installez son environnement d’exécution sur un serveur maintenu, gardez son interface d’administration privée et préparez une restauration avant de lui confier des tâches réelles. Le modèle peut rester accessible par API : héberger l’agent ne signifie pas héberger le modèle. Le budget comprend le serveur, les appels au modèle, les services annexes et le temps de maintenance.

Prérequis et architecture à retenir

Ce guide prend OpenClaw comme parcours concret. Les principes de choix du serveur, de séparation des droits et de reprise s’appliquent aussi aux solutions de notre annuaire des agents IA, mais leurs commandes d’installation diffèrent.

Prévoyez avant de commencer :

un VPS neuf avec une distribution Linux maintenue ;
un compte d’administration accessible par clé SSH ;
l’accès à la console de secours de l’hébergeur ;
un compte système dédié à l’agent ;
une clé API réservée à ce déploiement ;
une destination de sauvegarde extérieure au VPS ;
un responsable capable d’arrêter le service et de révoquer ses accès.

L’architecture proposée est simple : votre ordinateur rejoint le VPS par SSH ; l’interface de l’agent reste sur l’adresse de boucle locale ; l’agent appelle le modèle et les outils autorisés. Aucun accès public à son tableau de bord n’est nécessaire.

Un VPS maintient le service disponible lorsque votre ordinateur est éteint. Il ajoute cependant une machine à administrer : correctifs, espace disque, surveillance, renouvellement et reprise après panne. Si personne ne peut assurer ces tâches, comparez avec une offre administrée avant de déplacer des données.

Enfin, fixez une première mission limitée, par exemple analyser des documents déposés dans un répertoire dédié et produire un brouillon. Les envois, suppressions et modifications de comptes viendront seulement après validation de cette base.

Choisir le serveur selon les tâches exécutées

Distinguez la consommation de l’agent de celle de ses outils. Une boucle qui attend une API, un navigateur automatisé et une compilation ne sollicitent pas le serveur de la même manière. La documentation d’hébergement Linux d’OpenClaw constitue le point de départ spécifique au produit.

Critère	Agent avec modèle distant	Agent avec navigateur ou calcul	Agent avec modèle local
Processeur	Orchestration et traitement des réponses	Pages, scripts et traitements simultanés	Inférence et outils concurrents
Mémoire	État et services applicatifs	Navigateur et processus enfants	Poids du modèle et contexte
Stockage	Conversations, fichiers et journaux	Caches et artefacts supplémentaires	Modèles et données applicatives
Réseau	Dépendance à l’API	API et sites consultés	Téléchargements et services externes
Dimensionnement	Mesurer une mission représentative	Mesurer les pics de concurrence	Évaluer le modèle avant l’achat

Ne traitez pas une taille de VPS comme un minimum universel. Faites une mesure avec les outils réellement utilisés, puis gardez une marge pour les pointes et la maintenance. Une moyenne de mémoire acceptable peut masquer un arrêt pendant une tâche plus lourde.

Comparez également la possibilité d’agrandir le disque, les limites de trafic, l’existence d’un réseau privé et les modalités de récupération des données. Vérifiez la compatibilité des dépendances avec l’architecture du processeur, surtout pour les extensions natives et les navigateurs.

La localisation du serveur ne décrit pas tout le trajet des informations. Inventoriez séparément les destinations du modèle, des outils, des sauvegardes et de la supervision. Un serveur situé dans le pays choisi ne contraint pas automatiquement les autres services à y traiter les données.

1. Préparer Linux et préserver l’accès de secours

Effectuez les mises à jour du système avant l’installation applicative. Créez ensuite un utilisateur réservé au service, sans lui donner durablement les pouvoirs d’administration. Le compte qui entretient le serveur et celui qui exécute les tâches doivent avoir des responsabilités distinctes.

Testez votre connexion par clé dans une seconde session avant de modifier l’authentification SSH. Gardez la première session ouverte et vérifiez que la console de secours fonctionne. Désactiver trop tôt un moyen d’accès peut transformer une opération courante en récupération de serveur.

Sur Ubuntu, les commandes suivantes sont celles de la documentation officielle du pare-feu, consultée le 24 octobre 2026 :

sudo ufw allow 22
sudo ufw enable
sudo ufw status verbose

Elles supposent que SSH utilise le port indiqué. Si votre configuration diffère, adaptez la règle avant d’activer le pare-feu. Contrôlez aussi les règles réseau de l’hébergeur : elles constituent une couche distincte.

N’ouvrez que les accès nécessaires. Un agent qui interroge une API ou relève une file de tâches n’a pas, pour cette seule raison, besoin de recevoir des connexions applicatives publiques. Vérifiez également l’exposition en IPv6.

Consignez enfin les opérations de préparation dans une fiche de déploiement : distribution, utilisateurs, accès autorisés, emplacement des données et procédure de secours. Cette fiche doit permettre de reconstruire le serveur sans dépendre de l’historique du terminal.

2. Installer l’agent avec la procédure officielle

Pour ce parcours, utilisez l’installation native, sous le compte dédié. La documentation d’installation d’OpenClaw, vérifiée le 24 octobre 2026, fournit cette commande :

curl -fsSL https://openclaw.ai/install.sh | bash

Elle télécharge et exécute un script distant. Examinez-le avant de l’employer sur un serveur contenant déjà des données sensibles. Évitez d’ajouter des privilèges administrateur par réflexe : une demande de droits doit correspondre à une opération système identifiée.

L’assistant configure l’accès au fournisseur. Utilisez une clé réservée à ce serveur, avec les restrictions disponibles chez le fournisseur. Ne recopiez pas votre environnement personnel complet : ses connexions et fichiers d’authentification dépassent probablement le besoin de l’agent.

Le parcours officiel de démarrage indique ensuite comment installer le service et contrôler son état. Si la passerelle fonctionne au premier plan, arrêtez cette instance avec Ctrl+C avant d’installer le service :

openclaw gateway install
openclaw gateway status

Sur Linux, cette procédure installe un service utilisateur. Vérifiez sa persistance après déconnexion et après redémarrage du VPS ; une réponse obtenue pendant la session d’installation ne démontre pas ce comportement.

Notez la version effectivement installée et les choix de configuration. L’installateur peut évoluer : pour une reconstruction ultérieure, il faudra retrouver un état compatible, pas simplement relancer une commande en supposant un résultat identique. Le guide de référence OpenClaw complète les réglages applicatifs.

3. Accéder à l’interface sans l’exposer publiquement

Conservez la passerelle sur la boucle locale et ouvrez un tunnel depuis votre ordinateur. La documentation d’accès distant donne cette commande :

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

Remplacez user@gateway-host par votre utilisateur et votre serveur. Les ports correspondent à l’exemple officiel consulté le 24 octobre 2026 ; adaptez-les si vous avez changé la configuration.

Laissez le tunnel ouvert, puis accédez dans votre navigateur à l’adresse locale :

http://127.0.0.1:18789/

Appliquez l’authentification demandée par la passerelle. Le tunnel transporte la connexion ; il ne justifie pas la suppression des contrôles applicatifs.

Vérifiez ensuite le résultat depuis l’extérieur : l’adresse publique du VPS ne doit pas donner accès au tableau de bord. Contrôlez la configuration d’écoute et les règles réseau, plutôt que de déduire la protection du seul fonctionnement du tunnel.

Si vous choisissez ultérieurement un conteneur, reprenez cette vérification. La documentation Docker pour Ubuntu précise que les ports publiés peuvent contourner les règles UFW. Un conteneur ne rend donc pas automatiquement son interface privée.

Un accès partagé par HTTPS demande une conception supplémentaire : authentification, configuration du mandataire inverse et contrôle des utilisateurs. Ne publiez pas le tableau de bord uniquement pour faciliter une première connexion.

4. Restreindre les outils, les secrets et les utilisateurs

Le compte système dédié limite les dégâts possibles, mais il ne suffit pas. Un agent qui peut lire tous les documents de ce compte et contacter Internet conserve une capacité de fuite. Appliquez le moindre privilège aux fichiers comme aux comptes externes.

Établissez une liste des actions nécessaires. Pour chacune, indiquez les données accessibles, la destination autorisée et le besoin éventuel d’approbation. Une tâche de classement documentaire n’exige pas un accès général au terminal, à la messagerie et aux sauvegardes.

Le bac à sable concerne l’exécution des outils. Installer la passerelle dans un conteneur ne prouve pas que chaque commande lancée bénéficie d’une isolation adaptée. Examinez les répertoires montés, les droits d’écriture et les accès réseau.

Gardez les secrets hors des instructions et des documents remis au modèle. Séparez les clés par environnement, protégez les fichiers d’authentification et prévoyez leur révocation. Les journaux et les exports de diagnostic doivent également être considérés comme potentiellement sensibles.

La documentation de sécurité d’OpenClaw fournit un audit :

openclaw security audit

Examinez ses résultats avant d’ajouter des intégrations. Cet audit ne remplace pas l’analyse de vos autorisations métier. Le guide pour sécuriser un agent IA aide à formaliser ces décisions.

Enfin, traitez les pages, messages et documents consultés comme des données non fiables. Une injection de prompt peut chercher à détourner un outil pourtant correctement installé. Les limites techniques doivent subsister même lorsque le modèle reçoit une instruction trompeuse.

5. Sauvegarder hors du VPS et tester la restauration

Définissez d’abord ce qu’il faut récupérer : configuration, état des tâches, fichiers de travail, connexions et dépendances externes. Une image système et un export applicatif répondent à des besoins différents ; prévoyez les deux lorsque votre reprise l’exige.

La documentation de sauvegarde d’OpenClaw propose :

openclaw backup create --verify

L’archive locale peut contenir des secrets et n’est pas chiffrée simplement parce qu’elle est compressée. Protégez-la et transférez une copie chiffrée hors du VPS. Vérifiez les conditions de cohérence de votre stockage ; la documentation demande notamment l’arrêt de la passerelle pour certaines sauvegardes utilisant PostgreSQL.

Pour une archive locale, la restauration officielle utilise un répertoire de préparation :

openclaw backup restore <archive.tar.gz> --target <fresh-directory>

Remplacez les paramètres entre chevrons. La cible doit être vide ou inexistante. Cette extraction ne réactive pas automatiquement le service : l’activation constitue une opération séparée.

Votre exercice de reprise doit aller plus loin que l’extraction. Sur un environnement isolé, vérifiez les documents, les chemins, les permissions et une tâche sans effet externe. Gardez les connexions de production désactivées pour éviter qu’une copie restaurée ne traite les mêmes demandes que le serveur actif.

Choisissez la fréquence selon la perte de travail acceptable et mesurez le temps de remise en service. Conservez les moyens de déchiffrement ailleurs que sur le VPS. Une sauvegarde accessible uniquement avec les identifiants perdus lors de la panne ne constitue pas une solution de secours.

6. Surveiller et mettre à jour sans perdre le contrôle

La disponibilité du processus ne prouve pas que l’agent accomplit sa mission. Surveillez séparément la machine, la passerelle et le résultat des tâches. Un service peut rester actif tout en recevant uniquement des erreurs d’authentification ou en produisant des sorties inutilisables.

Retenez des signaux directement exploitables :

saturation de la mémoire et espace disque disponible ;
erreurs du fournisseur et délais d’attente ;
tâches bloquées, répétées ou abandonnées ;
consommation API par mission ;
date du dernier transfert de sauvegarde réussi.

Associez chaque alerte à une action et à un destinataire. Préférez un message permettant de décider entre arrêt, diagnostic et reprise à une accumulation de notifications sans priorité.

Avant une mise à jour, lisez les changements, sauvegardez et préparez le retour arrière. Vérifiez surtout les migrations de données : revenir à l’ancien programme peut ne pas suffire après une modification du stockage. Testez ensuite une tâche représentative et les restrictions d’accès.

Préparez également une procédure d’incident accessible sans l’agent. Elle doit expliquer comment suspendre les déclencheurs, arrêter le service, conserver les éléments de diagnostic et révoquer les secrets depuis un appareil sain.

Lors d’un retrait définitif, exportez les données utiles, révoquez les clés et supprimez les accès annexes. Résilier le VPS ne ferme pas nécessairement les comptes API, le stockage externe ou les intégrations associés.

Budgéter le serveur et l’usage réel

Comparez les offres d’hébergement avec un devis daté incluant renouvellement, taxes applicables, stockage, trafic et sauvegardes. Un tarif promotionnel ne décrit pas le coût durable. Ajoutez le temps consacré aux mises à jour, aux incidents et aux restaurations.

Poste	Déclencheur du coût	Contrôle à prévoir
VPS	Durée et capacité réservée	Révision du dimensionnement
Modèle distant	Entrées, sorties et options facturées	Mesure par tâche et plafonds
Outils externes	Recherches, navigation ou traitements	Quotas par intégration
Sauvegardes	Volume, rétention et restauration	Politique de conservation
Exploitation	Maintenance et incidents	Responsable et procédure

Pour illustrer le calcul, Claude Sonnet 5.5 est affiché à 2 dollars par million de tokens en entrée et 10 dollars en sortie, selon le relevé du site, octobre 2026. Dans une hypothèse de consommation d’un million en entrée et d’un million en sortie, le calcul donne 12 dollars, avant les autres postes.

Cette hypothèse n’est pas une consommation moyenne. Un agent peut multiplier les appels, réintroduire les résultats d’outils et recommencer une action après échec. Mesurez donc le coût d’une mission achevée, avec ses tentatives infructueuses.

Le calculateur de prix LLM aide à comparer les hypothèses. Fixez aussi une durée maximale, une limite de concurrence et des conditions d’arrêt : une simple alerte de dépenses n’interrompt pas forcément une boucle.

L’article Combien coûte vraiment un agent IA par mois ? complète cette lecture budgétaire. Pour décider du dimensionnement, rapprochez toujours dépenses et résultats acceptables, plutôt que le seul nombre de tâches lancées.

Problèmes fréquents

L’interface ne s’ouvre pas. Vérifiez d’abord l’état de la passerelle, puis le tunnel et son port local. Recherchez un conflit avec un service déjà présent sur votre ordinateur. Ouvrir le port public du VPS ne constitue pas un diagnostic.

Le service s’arrête après déconnexion. Contrôlez le service utilisateur installé et les règles de persistance du gestionnaire de services. Reproduisez le problème avec une fermeture de session, puis avec un redémarrage planifié.

Le modèle répond, mais les outils échouent. Examinez les droits du compte de service, les chemins et les secrets disponibles dans son environnement. Une session SSH interactive peut disposer d’autorisations absentes du service.

Le serveur ralentit. Identifiez la ressource saturée avant d’agrandir l’offre. Une attente réseau, un navigateur trop concurrent et un disque rempli demandent des corrections différentes.

La facture augmente sans résultat supplémentaire. Cherchez les reprises automatiques, les demandes dupliquées et les appels répétés. Avant de relancer une action interrompue, vérifiez si elle a déjà produit un effet externe.

La restauration semble complète, mais rien ne fonctionne. Contrôlez les chemins, les dépendances et l’activation de l’état restauré. Une archive présente ne garantit pas que les services externes et leurs autorisations sont encore disponibles.

Checklist avant les premières tâches réelles

Pages liées

Questions fréquentes

Peut-on héberger un agent IA sans GPU ?

Oui, si le modèle est appelé par une API distante : le serveur exécute alors l'agent et ses outils. Un GPU concerne surtout l'inférence locale, dont les besoins doivent être évalués séparément.

Un VPS rend-il les conversations confidentielles ?

Le VPS vous donne la maîtrise de l'environnement d'exécution, mais le fournisseur du modèle reçoit les contenus envoyés à son API. Il faut également examiner les accès de l'hébergeur, les sauvegardes et les services connectés.

Faut-il un nom de domaine pour accéder à son agent ?

Un tunnel SSH permet d'accéder à une interface privée sans domaine. Un domaine devient utile pour organiser un accès HTTPS partagé ou recevoir certains événements externes.

Peut-on installer plusieurs agents sur le même VPS ?

Oui, à condition de séparer leurs comptes, leurs secrets et leurs données. Pour des utilisateurs qui ne se font pas confiance, privilégiez des environnements distincts plutôt qu'une simple séparation des conversations.

Peut-on déplacer un agent vers un autre hébergeur ?

Préparez un export de l'état applicatif et conservez la procédure d'installation. La migration doit aussi couvrir les secrets externes, les chemins de fichiers et les connexions aux services tiers ; copier le disque ne suffit pas toujours.

Héberger un agent IA sur un VPS : choix du serveur, installation, sécurité, sauvegardes, coûts