Non, et c'est normal, ce n'est pas ce que le VPS fait. Il héberge l'agent, c'est-à-dire le programme qui reçoit vos instructions, appelle un modèle et fait le travail. Le calcul, lui, reste chez le fournisseur du modèle (Anthropic, OpenAI, Mistral…) et vous êtes facturé à l'usage avec vos propres clés API. Du coup pas de GPU nécessaire, juste de la mémoire, un réseau qui tient la route et un serveur allumé en permanence. Un LLM en local demande une machine avec GPU, nos VPS n'en proposent pas. Si vous voulez malgré tout un modèle local pour de petites tâches (embeddings, classification légère), certains modèles compacts tournent sur CPU avec quelques Go de RAM, mais les performances restent loin d'un LLM de taille commerciale. Pour un agent de production, l'API reste le choix le plus simple : vous changez de fournisseur ou de modèle en une ligne de configuration, sans jamais réinstaller de driver GPU ni gérer de quantization.

Non, il arrive nu (enfin, avec l'OS de votre choix et un accès root complet). C'est à vous d'installer le runtime d'agent IA que vous voulez. Le serveur est prêt en moins de 5 minutes, et vous gardez la main sur les versions et sur vos données. Concrètement, une fois le VPS livré, vous vous connectez en SSH, vous clonez le dépôt du runtime choisi (OpenClaw, Hermes Agent, un framework Python…), vous installez ses dépendances puis vous le lancez comme service systemd pour qu'il survive aux redémarrages. Comptez généralement entre quinze minutes et une heure pour un premier déploiement, selon le runtime choisi. Notre documentation détaille l'installation des runtimes les plus demandés, et le support technique répond si vous bloquez sur la partie serveur (réseau, pare-feu, ressources) — l'installation et la configuration de l'agent lui-même restent de votre côté.

Ça dépend surtout du runtime. Pour se faire une idée, la doc officielle de chaque projet donne des ordres de grandeur : 1 Go de RAM pour Hermes Agent, 2 Go pour OpenClaw ou n8n (4 à 8 Go si OpenClaw pilote un navigateur), 4 Go pour Claude Code. Le CPU compte moins que la RAM ici, le calcul du modèle part chez le fournisseur via API. Le plus simple reste de tester avec votre charge réelle, puis d'ajuster vCore, RAM et stockage depuis l'espace client. Le stockage compte surtout si votre agent garde un historique long ou un index vectoriel local : comptez quelques Go pour un usage courant, plus si vous stockez des embeddings ou des journaux détaillés. Pour démarrer, une configuration à 2 vCore et 4 Go de RAM couvre la plupart des runtimes cités ; vous surveillez l'usage réel via l'espace client et ajustez à la hausse dès que la RAM ou le CPU approchent leur limite, sans migrer vers un autre serveur.

Oui. Accès root complet, donc vous configurez le fournisseur que vous voulez (Anthropic, OpenAI, Mistral, open source, peu importe) avec vos propres clés API. Rien n'est bloqué côté services externes, dans le cadre de nos conditions d'utilisation. Vous pouvez même faire cohabiter plusieurs clés et plusieurs fournisseurs sur le même agent : un modèle rapide et bon marché pour le tri des demandes, un modèle plus capable pour les tâches complexes, chacun facturé séparément à l'usage. Les clés se stockent comme des variables d'environnement classiques (fichier .env, gestionnaire de secrets) : FirstHeberg n'y a pas accès et ne les transmet à personne. Si un fournisseur change ses tarifs ou ses limites de débit, vous basculez vers un autre en modifiant simplement la configuration de votre agent, sans réinstaller quoi que ce soit côté serveur.

Ça dépend de l'usage. Vous échangez un forfait fixe contre deux coûts variables, le VPS et les appels de modèles facturés à l'usage réel. Ce qui fait baisser la note, c'est que plusieurs agents peuvent tourner sur le même serveur et que vous changez de modèle selon la tâche. Pour un usage léger et ponctuel, l'abonnement reste plus simple ; pour un agent qui tourne en continu, ou plusieurs projets en même temps, l'auto-hébergement devient vite rentable. Un ordre de grandeur concret : un abonnement IA classique tourne autour de 20 à 30 € par mois pour un usage individuel, quel que soit le trafic réel. Avec un VPS à quelques euros par mois plus les appels API facturés au token, un agent qui traite un volume modéré revient souvent moins cher dès qu'il tourne plusieurs heures par jour. L'avantage disparaît si l'agent reste inactif la plupart du temps : dans ce cas, un abonnement à l'usage reste plus simple à budgétiser.

Oui, et c'est même tout l'intérêt. Chaque agent est un processus : vous les lancez côte à côte, en services systemd ou en conteneurs Docker séparés, sur la même machine. La seule limite, c'est la mémoire disponible : pas de licence, pas de nombre de sièges. Comptez la RAM de chaque agent plus ses dépendances (base de données, index vectoriel) et augmentez les ressources depuis l'espace client si besoin. Dans la pratique, la plupart des utilisateurs font tourner entre 2 et 5 agents sur un VPS de taille moyenne (4 à 8 Go de RAM) sans ressentir de ralentissement, tant que les agents ne partagent pas tous le même modèle local ou la même base de données volumineuse. Un bon réflexe est de donner à chaque agent son propre utilisateur système et son propre dossier de configuration : ça évite les conflits de dépendances et facilite le redémarrage ou l'arrêt d'un seul agent sans toucher aux autres.

Oui, dans les deux sens. Rien ne filtre les appels sortants vers les API de modèles ou vos services tiers. Pour recevoir des webhooks, le VPS a une IPv4 publique, vous ouvrez le port voulu et ça arrive directement, pas besoin d'un tunnel temporaire comme depuis une machine à la maison. Le pare-feu reste sous votre contrôle, comme le reste du système. Pour les intégrations qui exigent une URL HTTPS (la plupart des plateformes de webhooks modernes), vous installez un reverse proxy léger (Nginx ou Caddy) avec un certificat Let's Encrypt gratuit devant votre agent : quelques lignes de configuration suffisent, et le renouvellement du certificat se fait automatiquement. Vous pouvez aussi limiter les webhooks à une liste d'IP autorisées ou ajouter un jeton secret dans l'URL pour éviter qu'un tiers déclenche votre agent par erreur.

Lancez l'agent en service systemd avec « systemctl enable » et il redémarre tout seul avec la machine. Côté infra, on s'engage sur une GTR de 4 heures ouvrées en cas de panne matérielle ou réseau, avec un support joignable 24/7. Sauvegardes et snapshots restent en option depuis l'espace client. Pour aller plus loin, un gestionnaire de processus comme supervisor ou une simple règle Restart=on-failure dans le fichier de service systemd relance automatiquement l'agent s'il plante, sans attendre un redémarrage complet du serveur. Nous surveillons la disponibilité de l'infrastructure (réseau, hyperviseur, stockage) 24/7 de notre côté ; la surveillance applicative de l'agent lui-même (logs, alertes en cas d'erreur métier) reste à configurer par vos soins, par exemple avec un script qui vous notifie sur Telegram ou par e-mail en cas d'échec répété, sans attendre que vous le remarquiez vous-même.

Non. Le tarif affiché est le tarif mensuel, sans engagement, sans majoration au renouvellement : même montant le treizième mois que le premier. Vous pouvez augmenter vCore, RAM et stockage quand vous voulez, le prix suit alors juste les ressources ajoutées. C'est une politique appliquée à l'ensemble de notre gamme VPS, pas une promotion réservée à l'agent IA : contrairement à certains hébergeurs qui affichent un prix d'appel valable seulement la première année, le tarif que vous voyez au moment de la commande reste celui que vous payez ensuite, mois après mois, sans surprise sur la facture suivante. Si vous changez de configuration (plus de RAM pour faire tourner un agent supplémentaire, par exemple), seul le supplément lié aux nouvelles ressources s'ajoute à la facture ; le prix de base ne bouge pas rétroactivement.