Quand on cherche un serveur pour faire tourner un agent IA, on regarde presque toujours le nombre de cœurs en premier. Je pense que c’est une erreur. La mémoire, le type de virtualisation, les droits donnés à l’agent et la juridiction de l’hébergeur comptent bien plus, de loin.
Prenez un workflow n8n qui trie des factures fournisseurs pendant la nuit. Vers 3 h, il s’arrête en plein milieu d’une exécution. Le processeur du VPS n’a jamais dépassé 15 % de charge de toute la nuit (les graphes de l’hébergeur le montrent bien) et pourtant tout est tombé, parce qu’un Chromium lancé par Playwright a gonflé jusqu’à ce que le noyau tue PostgreSQL pour récupérer de la mémoire.
Ce genre de panne est d’une banalité assez désespérante. Sur un petit déploiement, un agent plante bien plus souvent pour une histoire de RAM, de boucle qui brûle le budget d’API en une nuit ou de droits trop larges que par manque de puissance de calcul. Du coup, je préfère partir de ce que l’agent va faire (et de ce qu’il pourrait casser) avant de regarder la moindre fiche technique.
Le processeur, rarement le vrai problème
Un agent passe le plus clair de son temps à attendre. Il envoie un prompt à l’API d’OpenAI, d’Anthropic ou de Mistral, attend, appelle un outil, attend encore, renvoie le résultat au modèle et recommence. Chaque étape de calcul local se règle en quelques millisecondes quand l’appel au modèle distant, lui, se compte en secondes. Que l’agent tourne sur n8n, sur LangGraph ou dans un script Python bricolé un dimanche après-midi ne change pas grand-chose à l’affaire.
Le CPU sert surtout à orchestrer (parser du JSON, envoyer des requêtes HTTP). Deux vCPU tiennent largement un prototype et on ne monte en gamme que le jour où plusieurs agents tournent en même temps.
Sur les VPS pas chers, le souci vient plutôt des vCPU partagés avec les autres clients de la machine physique. Lancez top et regardez la valeur st sur la ligne %Cpu(s). Ce steal time indique combien de temps l’hyperviseur a « prêté » votre processeur à quelqu’un d’autre. S’il reste durablement au-dessus de 5 à 10 %, vos agents rament sans raison visible dans le code et vous pourrez optimiser tant que vous voudrez, ça ne changera rien. Changez d’offre, voire d’hébergeur.
Pour le réseau, je ne perdrais pas de temps à comparer Paris et Francfort. L’écart se chiffre en millisecondes alors qu’un grand modèle met des centaines de millisecondes, parfois plusieurs secondes, à répondre. La stabilité de la connexion me paraît bien plus importante, parce qu’un agent qui enchaîne 40 appels d’outils sur une même tâche supporte mal la moindre micro-coupure. Sans relance automatique avec reprise sur l’état intermédiaire, une seule requête perdue au mauvais moment le renvoie à la case départ.
Combien de RAM pour un agent IA ?
4 Go de RAM sur un VPS KVM avec SSD NVMe, c’est le minimum qu’on voit partout pour un agent IA ou une instance n8n. Ça suffit pour tester, beaucoup moins pour de la production.
Il suffit de lister ce qui tourne sur la machine pour s’en rendre compte. Ubuntu et le démon Docker se servent en premier. Passez n8n en mode queue (EXECUTIONS_MODE=queue) et il vous faut Redis pour la file d’attente plus, en pratique, PostgreSQL comme base. Si l’agent fait du RAG, ajoutez Qdrant, Chroma ou pgvector. Un reverse proxy type Caddy ou Traefik, un collecteur de logs… et on n’a toujours pas parlé du navigateur. Un agent qui surfe avec Playwright ou Puppeteer lance des Chromium headless qui prennent chacun plusieurs centaines de Mo, si bien que trois ou quatre instances en parallèle suffisent à remplir 4 Go avec le reste de la pile.
Le problème, c’est que Linux ne prévient pas. Quand la mémoire manque, le noyau appelle l’OOM killer (Out Of Memory) qui tue un processus, en général le plus gourmand, donc souvent la base de données ou l’agent lui-même. La doc Docker précise noir sur blanc que n’importe quel processus peut y passer, Docker compris. Le lendemain matin vous trouvez un workflow à moitié exécuté sans rien d’évident dans les logs de l’application. La trace se cache dans le journal du noyau (journalctl -k | grep -i oom) ou dans le champ OOMKilled de docker inspect.
Un fichier swap de 1 à 2 Go ne remplace évidemment pas la RAM mais il transforme un crash net en ralentissement, ce qui laisse le temps de voir venir. Mettez aussi une limite mémoire sur chaque conteneur (–memory avec docker run, mem_limit dans le fichier Compose) pour qu’un service qui part en vrille n’entraîne pas les autres avec lui. Et pour de l’automatisation en production dans une PME, avec plusieurs conteneurs et des logs gardés quelques semaines, je partirais directement sur 8 Go. La différence de prix avec une offre à 4 Go tient souvent en quelques euros par mois.
Quelle VRAM pour faire tourner un modèle en local ?
Là, tout change. Si vous faites tourner le modèle chez vous, pour garder la main sur les données ou pour ne dépendre de personne, il doit tenir dans la RAM de la machine et, avec un GPU, dans sa VRAM.
Le calcul se fait de tête. En FP16, un paramètre pèse 2 octets, donc un modèle de 8 milliards de paramètres demande environ 16 Go rien que pour ses poids, 8 Go une fois quantifié en 8 bits. En 4 bits, le format que presque tout le monde utilise sur Ollama ou llama.cpp, le fichier de Llama 3.1 8B fait un peu moins de 5 Go (légèrement plus que la moitié théorique, certaines couches restant en précision supérieure).
| Modèle (exemple) | Poids en FP16 | Fichier Q4 dans Ollama |
|---|---|---|
| Llama 3.1 8B | environ 16 Go | environ 5 Go |
| Phi-4 14B | environ 28 Go | environ 9 Go |
| DeepSeek-R1 32B (version distillée) | environ 64 Go | environ 20 Go |
| Llama 3.3 70B | environ 140 Go | environ 43 Go |
Poids seuls, hors cache de contexte. Tailles FP16 calculées à partir du nombre de paramètres, tailles Q4 relevées dans la bibliothèque Ollama.
À ces poids s’ajoute le KV cache, qui stocke le contexte de la conversation et grossit avec lui. Un agent qui avale de longs documents ou garde un gros historique peut réclamer plusieurs Go de plus. Or accumuler du contexte à chaque étape, c’est exactement ce que fait un agent. Sous Ollama, ollama ps affiche la mémoire réellement occupée par le modèle chargé et vous dit s’il tient entièrement sur le GPU ou s’il déborde sur le CPU.
La RTX 5090, haut de gamme grand public de Nvidia, a 32 Go de GDDR7. Llama 3.3 70B en 4 bits (43 Go) n’y rentre pas. Il faut deux cartes, un GPU de datacenter type H100 avec ses 80 Go ou laisser une partie des couches déborder sur la RAM système. Dans ce dernier cas le débit s’effondre et vous le sentez à chaque réponse.
On pense moins souvent aux Mac à mémoire unifiée, où CPU et GPU partagent la même mémoire, alors qu’un Mac Studio se configure jusqu’à 512 Go. Ce n’est pas avec ça que vous servirez cent utilisateurs mais pour un agent interne qui bosse seul dans son coin, l’option mérite franchement un coup d’œil.
KVM, NVMe et Ubuntu LTS, les lignes à lire sur la fiche de l’hébergeur
Si l’offre ne mentionne pas KVM, méfiance. KVM est une virtualisation complète qui vous donne votre propre noyau Linux. Les offres très bas prix sous OpenVZ ou LXC vous font partager celui de l’hôte, Docker y marche mal (quand il marche) et une partie des réglages système vous reste fermée. Pour un agent en conteneurs, je ne vois aucune raison de prendre ce risque.
Le NVMe se justifie par tout ce qu’un agent écrit sur le disque, des logs aux embeddings en passant par les fichiers téléchargés puis analysés. Sur un disque lent, chaque accès ajoute un peu de latence qui finit par se voir au bout de quelques centaines d’étapes.
Côté système, Ubuntu 24.04 LTS reste couverte par le support standard jusqu’en 2029, donc aucun souci. Sur un serveur neuf, je regarderais quand même Ubuntu 26.04 LTS, sortie en avril 2026 et suivie jusqu’en 2031. Canonical conseille d’attendre la première version corrective avant de migrer depuis la LTS précédente, ce qui me paraît sage tant que vos images Docker et vos pilotes GPU n’ont pas été testés dessus.
Faut-il héberger un agent IA en serverless ?
Pour des tâches courtes, le serverless est très bien (on paie à l’usage et il n’y a rien à administrer). Pour un agent, on se cogne vite à la durée d’exécution. AWS Lambda coupe une fonction au bout de 900 secondes (15 minutes). Un agent qui mène une recherche en plusieurs dizaines d’étapes ou qui attend une validation humaine dépasse ce seuil sans forcer. On peut toujours découper le tout avec AWS Step Functions, sauf que ça revient à reconstruire en plus compliqué ce qu’un VPS à quelques euros par mois fait tout seul en laissant tourner un processus aussi longtemps qu’il le faut.
Quels droits donner à votre agent IA ?
L’OWASP place l’injection de prompt en tête de l’édition 2025 de son Top 10 des risques pour les applications LLM. Plus bas, au sixième rang, on trouve l’« agentivité excessive » (Excessive Agency), autrement dit un système qui dispose de plus de permissions ou d’autonomie que sa tâche n’en demande.
Les deux vont ensemble et c’est bien là le problème. Votre agent lit un e-mail piégé ou une page web bourrée d’instructions cachées, les prend pour des ordres et les exécute avec les droits que vous lui avez donnés. Plus ces droits sont larges, plus la casse est sévère.
Simon Willison, le développeur britannique à qui l’on doit l’expression « prompt injection », a donné un nom à ce danger en juin 2025 en parlant de « trifecta létale ». Dès qu’un agent a accès à des données privées, qu’il lit du contenu non fiable et qu’il peut communiquer vers l’extérieur, il devient exploitable. Il suffit à un attaquant de déposer les bonnes instructions là où l’agent passera. Willison cite des attaques de ce genre contre Microsoft 365 Copilot, GitLab Duo ou le serveur MCP de GitHub, donc pas vraiment des bricolages d’amateurs.
C’est là que le serveur redevient intéressant. Couper l’accès aux données ou la lecture de contenus extérieurs est difficile, puisqu’un agent qui ne lit rien ne sert à rien. La communication vers l’extérieur se bloque, elle, au niveau du réseau. Si l’agent ne peut joindre que l’API du modèle et vos outils métier, la fuite n’a plus de sortie. Curieusement, la quasi-totalité des tutos de déploiement ne parlent que du trafic entrant.
Attention, ufw seul ne suffit pas. Il raisonne en adresses IP et en ports, pas en noms de domaine. Or les API des fournisseurs de modèles changent souvent d’adresse derrière leurs CDN. Le montage le plus propre, à mon sens, consiste à mettre les conteneurs de l’agent sur un réseau Docker internal (sans accès direct à Internet) et à les faire sortir par un proxy HTTP filtrant comme Squid ou Smokescreen, l’outil open source de Stripe, réglé sur une liste blanche de domaines.
Petite digression au passage. Docker écrit ses propres règles iptables et les ports publiés d’un conteneur passent à côté de vos règles ufw. Vous croyez un port fermé alors qu’il ne l’est pas du tout.
Pour le reste, on reste sur de l’hygiène classique avec SSH par clé uniquement (PasswordAuthentication no dans sshd_config), un pare-feu strict en entrée, un utilisateur Linux dédié à l’agent sans sudo et des conteneurs en –read-only quand l’appli le supporte.
Un point qu’on oublie tout le temps, ce sont les logs. Ils dorment en général sur le serveur même où tourne l’agent. Si l’agent (ou la personne qui le manipule) peut effacer ses traces, votre journal d’audit ne sert plus à grand-chose. Envoyez-les ailleurs, avec Vector ou Grafana Alloy vers une instance Loki par exemple. Le service de logs de l’hébergeur fait aussi très bien l’affaire.
Serveurs MCP, qui a le droit de faire quoi ?
Anthropic a sorti le Model Context Protocol en novembre 2024, puis OpenAI et Google DeepMind l’ont adopté. Un serveur MCP expose vos outils (CRM, base de données, messagerie, fichiers) à un agent via une interface standard. Pratique, sans aucun doute, sauf qu’on ouvre du même coup beaucoup d’accès à un programme qui obéit à ce qu’il lit.
Pour juger un serveur MCP, je regarderais à peine la performance. Je veux savoir s’il travaille en lecture seule ou en lecture-écriture, comment il authentifie l’agent et quels scopes OAuth il réclame. Accessoirement, si l’automatisation sert vraiment à quelque chose. Un connecteur CRM en lecture seule qui prépare des comptes rendus n’a rien à voir, niveau risque, avec le même connecteur autorisé à modifier les fiches clients.
Avec plusieurs agents et une dizaine de serveurs MCP, je passerais par une passerelle unique (un gateway MCP) qui centralise l’authentification et journalise chaque appel. Rien de révolutionnaire, c’est le principe de l’API gateway des microservices des années 2010. Sauf que la passerelle devient un passage obligé. Si elle tombe, plus aucun agent ne travaille, donc c’est elle qui mérite votre infrastructure la plus fiable, bien plus que l’agent.
Héberger ses données en Europe suffit-il ?
Pour des données sensibles, le conseil habituel est de prendre un hébergement avec des serveurs dans l’Union européenne. Beaucoup cochent alors la région « Europe » chez n’importe quel fournisseur et s’estiment tranquilles. Ce n’est pas si simple.
Le CLOUD Act américain, voté en 2018, permet aux autorités des États-Unis d’exiger d’une entreprise américaine les données qu’elle contrôle, même stockées hors du pays. Un serveur à Francfort exploité par un hyperscaler américain reste donc exposé. C’est pour ça que l’ANSSI a ajouté en 2022, dans la version 3.2 de SecNumCloud, des exigences de protection contre les lois extra-européennes. Un prestataire qualifié ne peut pas être détenu à plus de 24 % par un actionnaire hors UE ni à plus de 39 % par l’ensemble de ces actionnaires. Outscale a été le premier opérateur qualifié en 3.2 et Numspot comme OVHcloud (pour sa SNC Cloud Platform) ont rejoint la liste le 1er septembre 2026.
Avec un agent, il faut regarder plus loin que l’emplacement du serveur. Votre machine peut très bien être chez un acteur européen qualifié et vos documents partir quand même aux États-Unis, simplement parce que l’agent les envoie à l’API d’un modèle américain. La souveraineté se joue sur toute la chaîne. Pour les briques vraiment sensibles, je combinerais un hébergement qualifié avec un modèle local ou européen et un contrôle d’accès serré.
Le serveur, poste le moins cher de la facture
On compare des offres à quelques euros d’écart alors que l’argent part ailleurs. Installation, supervision, mises à jour, durcissement, sauvegardes… Comptez les heures que tout ça représente sur un an et vous dépasserez souvent le prix de la machine.
Puis il y a les tokens. L’OWASP a rangé la consommation non bornée (Unbounded Consumption) dans son Top 10 et ce n’est pas un hasard. Un agent qui boucle, parce qu’un outil lui renvoie une erreur qu’il essaie de corriger à l’infini par exemple, peut griller en une nuit plus d’appels d’API que votre VPS ne coûte en un an. Aucun serveur ne vous protège de ça. Mettez un plafond de dépenses dans la console du fournisseur de modèle et une limite d’itérations dans le code (recursion_limit sous LangGraph, max_iter sous CrewAI). Ajoutez une alerte sur la conso quotidienne et le problème est réglé pour zéro euro. Ces garde-fous, presque tout le monde les installe après le premier incident.
Quelle configuration choisir selon votre projet ?
Pour un prototype, un VPS KVM de 4 Go avec SSD NVMe et Ubuntu LTS suffit, à condition d’avoir sécurisé SSH et ajouté un swap. Dès que ça part en production dans une PME, je monterais à 8 Go avec des limites mémoire par conteneur et des sauvegardes testées (testées, pas seulement configurées). Pour un usage critique, un serveur dédié ou un environnement très cloisonné s’impose, avec des logs envoyés hors de la machine.
Mais surtout, partez d’une tâche précise plutôt que de l’outil à la mode et testez-la avec de vraies données et de vrais utilisateurs. Une semaine à surveiller docker stats et free -h en conditions réelles vous en dira plus qu’un mois de comparatifs.
La question à poser avant de commander un serveur
Les fiches des hébergeurs parlent de cœurs, de Go et de bande passante. Aucune ne vous demande ce que votre agent aura le droit de faire, alors que c’est ça qui sépare un agent utile d’un incident en préparation.
Avant de commander, prenez une feuille. Notez à gauche tout ce que l’agent doit pouvoir lire, modifier ou envoyer, puis à droite le pire qu’il pourrait faire avec chacun de ces accès si quelqu’un lui soufflait les mauvaises instructions. Si la colonne de droite vous fait un peu peur, 8 Go de RAM en plus n’y changeront rien. Commencez par rogner les droits.