Auto-héberger un agent IA ou le faire héberger : le vrai calcul

Auto-héberger un agent IA n’a rien de sorcier sur le plan technique : un serveur Linux, un processus Python, une clé d’API ou un modèle local via Ollama, et c’est parti. Le calcul ne tombe pourtant souvent pas juste, et pas à cause du matériel. Un agent de code qui écrit des fichiers, pilote Git et dispose d’un terminal est un processus qui exécute du code arbitraire sur votre serveur. Tout ce qui vient ensuite (bac à sable, limites de mémoire, gestion des clés, protection contre les boucles, sauvegardes) est à construire ou à exploiter vous-même. Cet article passe ces postes en revue, avec les chiffres de notre propre exploitation chez Hetzner à Nuremberg. Il ne se termine pas par un conseil d’achat, mais par un tableau de décision.

Ce que « agent » veut dire ici

Le terme sert à beaucoup de choses. Il s’agit ici de la catégorie exigeante : un agent de code qui travaille en boucle.

• Outils : l’agent lit et écrit des fichiers, appelle Git, lance des commandes dans le terminal, ouvre un navigateur. Chez UltraNOS, cela représente de 7 à 38 outils par session selon le mode de fonctionnement.
• Boucles : réfléchir, agir, vérifier, recommencer. Un tour peut durer des dizaines de cycles d’outils ; en mode longue durée, le nombre de cycles n’est même plus plafonné.
• Sous-agents : l’agent de chat peut lancer d’autres agents qui travaillent en parallèle. Chez nous : profondeur 2 au maximum, 16 tâches simultanées au maximum, profondeur de rappel 8.

Un chatbot qui ne renvoie que du texte n’a besoin de rien de tout cela. Un agent doté d’un terminal a besoin de tout, et chacun de ces points est un endroit où un serveur peut s’effondrer.

Le calcul matériel

La première question de l’auto-hébergement n’est pas « quel serveur », mais « où le modèle calcule-t-il ».

Variante A : modèle local

Avec Ollama, le modèle tourne sur votre matériel. Avantage : les prompts ne quittent pas la machine, aucun coût par requête. Inconvénient : les poids du modèle et la fenêtre de contexte doivent tenir en RAM ou en VRAM, et un agent de code remplit vite sa fenêtre de contexte avec des contenus de fichiers et des sorties de terminal. Les besoins en mémoire de chaque modèle figurent dans la bibliothèque de modèles sur ollama.com ; pour des modèles de code utilisables, ils dépassent nettement ce qu’offre un petit VPS.

Variante B : modèle via API

Le modèle tourne chez le fournisseur, votre serveur ne fait qu’orchestrer. C’est ainsi que nous procédons : la production d’UltraNOS dispose de 8 Go de RAM et ne calcule aucun modèle elle-même. La mémoire part dans ce que l’agent déclenche : clones Git, npm run build, séries de tests, navigateurs Playwright.

Un exemple tiré de notre VM de développement : deux navigateurs Playwright simultanés pour un test mobile, et l’OOM killer du noyau fait le ménage. Nous mesurons donc Firefox et Chromium l’un après l’autre. C’est le genre d’expérience qu’aucun tutoriel sur le « VPS pour agent IA » ne mentionne.

Poste	Modèle local	Modèle via API
RAM pour le modèle	Poids + contexte, selon le modèle d’après ollama.com	0
RAM pour le travail de l’agent (builds, clones, navigateur)	nécessaire en plus	chez nous : les 8 Go complets
Coût par requête	0	selon le fournisseur
Les prompts quittent le serveur	non	oui, vers le fournisseur choisi
Carte graphique utile	oui	non

Disque : le sujet sous-estimé

Un agent de code clone des dépôts. Notre objectif est qu’un seul dépôt de 50 Go tienne sans peine. C’est pourquoi, chez UltraNOS, le clone partiel est le réglage par défaut (umfang teil, superficiel ou complet, plus des chemins sparse), et Git-LFS est ignoré au clonage. Les espaces de travail se trouvent sur un volume dédié de 145 Go, qui coûte environ 10 € par mois et dispose d’une protection contre la suppression. Qui s’auto-héberge doit prendre la même décision avant que le premier agent ne lance git clone sur un monorepo.

Obligations de sécurité que personne ne vous retire

C’est là que se trouve l’essentiel du travail. Un agent doté d’un terminal est un utilisateur avec accès shell qui ne se fatigue jamais et peut prendre pour des commandes des instructions contenues dans des fichiers. Ce que nous avons construit pour cela est décrit dans la documentation, et chaque point a été une leçon.

Bac à sable

Le terminal, les builds et l’exécution de scripts tournent chez nous dans bubblewrap (bwrap), avec un environnement construit exprès plutôt que celui du service. Le déclencheur a été une découverte : l’onglet de build était le dernier chemin sans bac à sable et transmettait, avec {**os.environ}, toutes les clés des fournisseurs à npm run build. Un seul script de build malveillant aurait suffi.

Soyons honnêtes : ce n’est pas terminé non plus. Aujourd’hui, les valeurs d’environnement du bac à sable atterrissent encore via --setenv dans la liste d’arguments du processus bwrap, où des processus de l’hôte hors bac à sable pourraient les lire. La solution par descripteur de fichier est connue et figure sur la liste.

Limites de charge pour chaque processus enfant

Avant chaque exec, engine/lastgrenzen.py pose des limites strictes selon quatre profils (interactif, service, build, court) : temps de calcul, taille de fichier, nombre de processus, descripteurs. Trois détails que l’on n’apprend, en construisant soi-même, qu’après la panne :

1. Mémoire via cgroup, pas via RLIMIT_AS. La limite d’espace d’adressage tue Node et la JVM, qui réservent de grandes zones virtuelles sans les utiliser.
2. RLIMIT_NPROC mesure dans l’espace de noms utilisateur, alors que /proc ne montre que l’espace de noms PID. Sur une VM, nous voyions 1001 processus contre environ 2500 réels. Une formule fixe « visibles plus 64 » n’y était pas une limite, mais un blocage au démarrage.
3. Réutilisation des PID : avant chaque arrêt de groupe, la sentinelle de charge vérifie l’heure de démarrage dans /proc/<pid>/stat. Sinon, l’arrêt finit un jour par toucher le mauvais processus.

Sentinelle de charge

Des limites par processus ne suffisent pas, car la somme finit quand même par remplir l’hôte. La sentinelle de charge contrôle toutes les 15 secondes l’espace disque libre et MemAvailable, bloque les nouveaux démarrages sous la réserve et, en cas de pénurie de mémoire, abat le plus gros arbre de processus lancé par nos soins avant que l’OOM killer du noyau ne frappe au hasard. Toutes les 10 minutes, les espaces de travail sont remesurés. La sortie du terminal est limitée à 512 Ko/s, et chaque mandant dispose d’au plus 8 terminaux.

Protection contre les boucles

Les agents tournent en rond. La sentinelle de boucles compare des paires appel d’outil et résultat : au troisième appel identique, un avertissement est émis ; à partir du cinquième, plus rien n’est exécuté ; l’oscillation entre deux états est détectée à part. Chaque tour a un budget de temps, 45 minutes par défaut. S’y ajoutent quatre garde-fous intégrés (no-rm-rf, no-force-push, no-drop-table, no-curl-pipe-bash) ainsi que des règles regex personnalisées. Qui s’auto-héberge n’a rien de tout cela tant qu’il ne l’a pas écrit.

Ce que nous n’avons pas résolu non plus

L’injection de prompt reste ouverte chez nous : le modèle ne distingue pas les données des ordres, et les contenus de dépôts tiers clonés, d’e-mails ou de pages web peuvent contenir des instructions. Une détection ne fonctionne pas de façon fiable ; l’étape réaliste consiste à placer les outils ayant un effet vers l’extérieur derrière une confirmation. Cette obligation vous incombe tout autant sur votre propre serveur.

Clés : coffre-fort et masquage

Un agent travaille avec des secrets : clés d’API, jetons Git, clés SSH, mots de passe de serveurs. Deux questions à trancher en auto-hébergement.

Où se trouvent les clés ? Chez UltraNOS, dans un coffre-fort chiffré ; douze services en dépendent. Une sentinelle (engine/kek_wache.py) interrompt le démarrage si la clé de déchiffrement manque alors que des chiffrés existent. Auparavant, il y avait à cet endroit un redémarrage à neuf silencieux, c’est-à-dire un coffre-fort vide sans message d’erreur. Dans un montage maison, un fichier .env est la voie habituelle, et il finit, l’expérience le montre, dans un chat ou un commit.

Que voit le modèle ? Tout ce qui figure dans le prompt. Chez UltraNOS, le masquage cloak intervient avant l’envoi : 27 règles de préfixe pour des fournisseurs connus (sk-ant-…, ghp_…, glpat-…), 13 règles structurelles pour les affectations, en-têtes et chaînes de connexion, plus les adresses e-mail et les valeurs du coffre-fort. La clé devient un substitut de la forme CLOAK_SECRET_…, le modèle travaille avec lui, et la conversion inverse n’a lieu qu’à l’exécution de l’outil. Le profil enforce est le réglage par défaut ; si le paquet manque, le tour échoue de façon lisible au lieu d’envoyer du texte en clair.

Les limites sont indiquées : sur la voie CLI via Claude Code, seuls le prompt et le prompt système sont masqués, car la CLI exécute ses outils elle-même. Les formats inconnus, sans préfixe et sans contexte, passent. Le champ cloak de GET /api/health indique si la protection est active. Plus d’informations dans Protéger les clés d’API dans le prompt.

Comparaison des coûts : VPS contre hébergé

Les coûts de modèle existent dans les deux cas et dépendent du fournisseur. La différence tient au serveur et au temps.

Poste	VPS personnel	UltraNOS hébergé
Serveur	Tarif sur hetzner.com, pour un travail d’agent avec builds au moins la classe à 8 Go de RAM	inclus dans le tarif
Volume pour les dépôts	Exemple : 145 Go pour environ 10 €/mois	Starter 200 Mo, Pro 5 Go, Team illimité
Pare-feu, mises à jour, bac à sable, limites de charge	votre temps, chaque mois	inclus dans l’exploitation
Coffre-fort de clés, masquage	à construire soi-même ou se fier à .env	cloak en profil enforce
Sauvegardes	à mettre en place soi-même	disque système sauvegardé ; le volume des espaces de travail reste chez nous en suspens (borg est la prochaine étape)
Coûts de modèle	selon le fournisseur	selon le fournisseur
Prix	Serveur + volume + heures	Starter 0 €, Pro 19 €/mois, Team 49 €/mois

Les heures sont le poste que chacun sous-estime. Attribuez une valeur honnête à votre temps de travail et calculez combien d’heures par mois un serveur qui exécute un agent exige : mises à jour du noyau, un build cassé qui remplit le disque, un agent en boucle qui maintient le processeur à 100 % toute la nuit. Si ce chiffre dépasse l’écart avec 19 €, la décision est prise.

Ce que « hébergé » signifie concrètement ici : serveur situé à Nuremberg, l’hôte web derrière un pare-feu cloud qui ne laisse passer depuis Internet que les ports 80 et 443, contrat de sous-traitance (AV) disponible. Les prompts continuent d’aller chez le fournisseur de modèle que vous choisissez.

Aide à la décision

Si vous …	alors …
voulez un modèle local parce que les prompts ne doivent pas quitter la machine	auto-hébergement avec Ollama, sur un matériel doté de suffisamment de RAM ou de VRAM
exploitez déjà des serveurs Linux et aimez les cgroups	auto-hébergement, avec la liste d’obligations ci-dessus comme modèle
voulez un agent de code avec éditeur, Git et terminal, mais pas un second métier d’administrateur	hébergé
travaillez en équipe sur les mêmes dépôts	hébergé (Team) ou un serveur personnel sérieusement entretenu
voulez d’abord voir si les agents vous conviennent	Starter à 0 € sur ultranos.de, 14 jours de toutes les fonctions à l’essai

Pour Open WebUI et les interfaces similaires, si vous cherchez un simple frontal de chat, la comparaison se trouve dans Alternatives à Open WebUI en 2026. C’est une tâche différente d’un agent avec terminal.

FAQ

Comment créer soi-même des agents IA ?

Il vous faut, pour l’essentiel, un modèle capable d’appels d’outils, une boucle (réfléchir, agir, vérifier) et les outils eux-mêmes : lire et écrire un fichier, exécuter une commande, Git. Cela se construit en un week-end. Le travail commence après : bac à sable, limites de mémoire et de processus, détection des boucles, gestion des clés. Intégrez ces points dès le départ, sinon vous aurez un agent qui remplit le serveur au troisième jour.

Quelle plateforme convient aux agents IA ?

Cela dépend de ce que vous voulez : une bibliothèque à assembler ou un poste de travail prêt à l’emploi. Pour le montage maison, Ollama plus un framework de votre choix est la voie habituelle. UltraNOS est le poste de travail prêt à l’emploi dans le navigateur : chat, éditeur Monaco, Git, terminal et agents dans une seule interface, avec un fournisseur de modèle librement choisi (Claude via API ou CLI, compatible OpenAI, Ollama, point de terminaison personnel). L’auto-hébergement est optionnel et possible sur demande.

Puis-je créer un agent IA gratuitement ?

Le tarif Starter d’UltraNOS coûte 0 €. L’existence de coûts de modèle dépend du fournisseur choisi : un modèle local via Ollama ne coûte rien par requête, mais exige son propre matériel. Un agent qui écrit et teste vraiment du code consomme nettement plus de jetons qu’un chat, car les contenus de fichiers et les sorties de terminal circulent à chaque tour.

De combien de RAM un agent IA auto-hébergé a-t-il besoin ?

Avec un modèle via API, notre production tourne avec 8 Go, qui partent entièrement dans les builds, les clones et le navigateur, pas dans le modèle. Avec un modèle local, les poids du modèle et la fenêtre de contexte s’y ajoutent ; les valeurs par modèle figurent sur ollama.com. Plus que le chiffre, c’est la limite qui compte : sans plafond cgroup par processus enfant, c’est l’OOM killer qui décide de ce qui survit.

Un agent de code fonctionne-t-il avec un modèle local via Ollama ?

Oui, Ollama est sélectionnable comme fournisseur chez UltraNOS, et le masquage cloak s’applique aussi sur cette voie. La qualité des résultats dépend du modèle : un agent a besoin d’appels d’outils fiables, et un modèle dépourvu de cette capacité ne peut que parler d’une tâche au lieu de l’exécuter. La liste des modèles l’indique donc par un avertissement.

Pour qui l’auto-hébergement reste le bon choix

L’auto-hébergement est le bon choix si les prompts ne doivent pas quitter votre propre machine, si vous avez une carte graphique qui s’ennuie, ou si l’exploitation de serveurs n’est pas une charge pour vous mais un passe-temps. Dans ce cas, la liste d’obligations ci-dessus n’est pas dissuasive, c’est un modèle, et vous obtenez un système que vous comprenez jusque dans le noyau.

Pour tous les autres, le calcul honnête est le suivant : le serveur est le plus petit poste. Le temps consacré à la protection qu’exige un agent qui exécute du code est le plus grand. Et si vous ne nous croyez pas, vous pouvez lire chez nous combien des points ci-dessus nous n’avons construits qu’après une panne.

Vos clés restent chez vous : le reste tourne dans le navigateur.

UltraNOS est l’IDE web agentique : des agents IA en parallèle, un éditeur, git et un terminal. cloak remplace les clés d’API et les mots de passe avant qu’un prompt n’atteigne le fournisseur. Hébergé en Allemagne, 14 jours gratuits.

Essayer 14 jours gratuitement →