Ce qu'implique vraiment l'auto-hébergement d'un agent IA : les quatre composants, les runtimes open source, quelques précautions sur le matériel et une checklist de sécurité interactive.
Un agent IA auto-hébergé fonctionne sur du matériel que vous contrôlez, et non dans le cloud d'un fournisseur. Vous exploitez vous-même quatre composants : un runtime qui sert un modèle à poids ouverts, un orchestrateur qui exécute la boucle de l'agent, les outils qu'il peut appeler et un espace de mémoire. Le bénéfice, c'est la maîtrise des données ; le prix, c'est que la sécurité devient votre affaire.
Les quatre composants d'un agent auto-hébergé
L'auto-hébergement séduit les entreprises qui ne peuvent pas transmettre des données clients à un tiers, ou qui préfèrent des coûts fixes à une facturation à la requête. C'est cependant un vrai travail d'ingénierie : vous mettez à jour les serveurs, dimensionnez le matériel et décidez de ce à quoi l'agent peut accéder. Cette page passe en revue chaque composant en termes simples et se termine par une checklist à cocher avant toute mise en production.
Il peut l'être, car les prompts et les données restent sur des machines que vous contrôlez. Ce n'est vrai que si le runtime, les journaux et les sauvegardes restent eux aussi privés, et si aucun outil n'envoie discrètement des données à un service extérieur.
Cela dépend fortement de la taille du modèle et du nombre d'utilisateurs simultanés, nous ne donnerons donc pas de chiffre. À titre indicatif, le guide d'installation de vLLM mentionne Linux et un GPU de compute capability 7.5 ou plus, tandis que LocalAI indique qu'aucun GPU n'est requis. Testez d'abord sur du matériel loué.
Certains outils d'automatisation peuvent être auto-hébergés. n8n, par exemple, propose l'auto-hébergement sous sa propre Sustainable Use License, une licence fair-code dont les limites diffèrent de MIT ou Apache : lisez-la avant tout usage commercial.
L'injection de prompt : un texte lu par l'agent, comme un e-mail ou une page web, qui le pousse à agir contre vous. L'OWASP le place en tête des risques pour les applications de modèles de langage. Limiter les outils et exiger une validation humaine pour les actions à fort impact sont les principales parades.
Une esquisse du principe réseau, pas un déploiement complet. Seul l'orchestrateur est exposé sur l'hôte ; le runtime n'a aucun port publié.
Le runtime se trouve uniquement sur un réseau interne sans accès vers l'extérieur ; l'agent rejoint ce réseau et le réseau par défaut. Remplacez les noms d'image par le runtime et l'agent que vous avez choisis.
Cochez ce qui est déjà en place. Vos coches restent uniquement dans cet onglet du navigateur.
{n} sur {v} terminés
Tous les éléments sont cochés. Testez-le sur des données de test avant que de vrais clients ne l'utilisent.
Tout effacer
Runtime du modèle
Orchestrateur
Mémoire et données
Exploitation
L'API du runtime n'est accessible que depuis l'orchestrateur, pas depuis Internet.
La licence du modèle autorise votre usage commercial.
Vous avez testé le modèle sur le matériel cible avec une charge réaliste.
La boucle de l'agent a un nombre maximal d'étapes et un délai d'expiration.
Les remboursements, suppressions, paiements et e-mails sortants attendent la validation d'un humain.
L'agent ne dispose que des outils nécessaires à cette tâche.
Chaque outil utilise son propre compte ou sa propre clé avec les permissions les plus restreintes.
Chaque serveur MCP ou plugin provient d'une source de confiance que vous avez vérifiée.
Les conversations et documents stockés sont chiffrés et sauvegardés.
Vous avez fixé une durée de conservation des conversations, et les anciennes sont supprimées.
Chaque appel d'outil est journalisé avec ses entrées et son résultat.
Une personne est responsable des mises à jour du runtime, du framework et de l'OS.
Une personne désignée est joignable quand l'agent se comporte mal.
Commencer gratuitement · Sans carte bancaire