Pourquoi j'ai monté mon propre environnement agentique sur un VPS

TL;DR

Les agents IA facturés au token deviennent chers dès qu'on les utilise en continu : veille, batch, génération répétée, tests. J'ai loué un VPS à coût fixe et prévisible (environ 28 € TTC par mois) pour en faire une machine de travail agentique permanente, avec des modèles locaux pour le volume et des agents cloud pour ce qui l'exige vraiment. Cet article ouvre une série de retours d'expérience au long cours : ce qui marche, ce qui casse, et l'architecture qui en ressort semaine après semaine.

Sommaire

Le problème : facturé au token, en continu
Un VPS, pas juste un hébergeur
La stack visée
Le choix du matériel
Hybride par nécessité, pas par idéologie
Ce que cette série va documenter

Le problème : facturé au token, en continu

Utiliser un agent IA cloud pour une tâche ponctuelle (un refactoring, une revue de code, une question d'architecture) coûte peu et se justifie largement par le temps gagné. Le calcul change quand l'usage devient permanent : veille technologique automatisée, génération de tests en masse, transformations de données répétitives, classification de contenu, batch de nuit. Multiplié par des dizaines d'exécutions par jour, le coût au token cesse d'être négligeable. Et surtout, il devient difficile à prévoir.

Je ne voulais pas renoncer aux agents cloud pour autant. Savoir sur quoi ils gardent l'avantage, et sur quoi le local peut suffire, c'est justement ce que cette série va mettre à l'épreuve. Je voulais simplement ne plus être obligé de les solliciter pour tout, y compris pour du travail simple, répétitif, ou qui peut attendre.

Un VPS, pas juste un hébergeur

L'idée de départ était modeste : louer une machine Linux permanente et l'utiliser comme base arrière pour mes expérimentations agentiques, plutôt que de tout faire tourner sur mon poste de travail ou de tout payer à l'usage chez un fournisseur d'IA.

Un VPS a un avantage qu'un poste local n'a pas : il tourne 24 heures sur 24, il est accessible de n'importe où, et il peut accueillir des processus longs (background, batch) sans dépendre de mon PC allumé. Cette permanence en fait progressivement autre chose qu'un simple hébergeur : une vraie machine de travail agentique, sur laquelle peuvent vivre des modèles locaux et des orchestrateurs.

La stack visée

Le terrain de jeu que je voulais couvrir avec cet environnement correspond à mon usage professionnel réel, pas à une démo :

.NET / C#, et F# en exploration ;
TypeScript ;
BDD (Gherkin) ;
CI/CD (GitHub Actions) ;
bases de données relationnelles et non relationnelles.

L'objectif n'était pas de construire un laboratoire IA isolé, mais un environnement capable de produire du code réellement compilable, testable et déployable sur cette stack. C'est un critère plus exigeant qu'il n'y paraît dès qu'on le confronte à un agent IA réel plutôt qu'à une démo.

Le choix du matériel

Après comparaison, j'ai retenu un VPS OVH :

Ubuntu 24.04 ;
8 vCPU ;
24 Go de RAM ;
200 Go de stockage NVMe ;
environ 28 € TTC par mois.

Ce n'est pas une machine surdimensionnée pour de l'inférence LLM. On verra dans un prochain article à quel point le CPU seul est un facteur limitant pour des modèles de plusieurs dizaines de milliards de paramètres. J'aurais pu partir directement sur une instance GPU pour lever cette limite, à un coût mensuel plus élevé et moins prévisible. J'ai préféré l'inverse : démarrer sur un budget fixe et modeste, mesurer ce que le CPU permet réellement, et ne faire évoluer le matériel que si les résultats le justifient.

Hybride par nécessité, pas par idéologie

Je n'ai pas cherché à tout faire tourner en local par principe. L'idée directrice est plus pragmatique : un fonctionnement hybride, où les modèles locaux (via Ollama) absorbent ce qui peut être lent et asynchrone, et où les agents cloud (Claude Code, Codex) prennent le relais pour tout ce qui est interactif, complexe, ou qui doit aboutir vite.

Cette répartition n'était pas arrêtée dès le départ. Elle s'est construite, et parfois corrigée, au fil des tests.

Ce que cette série va documenter

Je ne pars pas d'une architecture déjà validée que je viendrais présenter a posteriori. Je pars des expérimentations réelles, dans l'ordre où elles se sont produites, avec leurs erreurs :

la sécurisation du VPS avant d'y laisser tourner des agents capables d'exécuter des commandes ;
l'installation de Docker, Ollama et Hermes, et les pièges qu'on ne voit pas au premier abord, comme le contexte tronqué ;
des benchmarks locaux qui semblaient d'abord démontrer qu'un modèle « ne sait pas utiliser les outils », avant de découvrir que le problème était ailleurs ;
le passage progressif d'Hermes vers des Dev Containers et un agent de développement directement dans l'environnement du projet.

Chaque article suivra la même règle : ce que j'ai essayé, pourquoi ça a échoué quand ça a échoué, ce qu'il ne faut pas refaire, et le chemin que je recommanderais aujourd'hui avec le recul. Le but n'est pas de retracer chaque détour, mais d'éviter aux lecteurs de perdre le même temps que moi.

La suite dans une semaine, avec la sécurisation du VPS avant d'y installer le premier agent.