Créer votre propre agent IA sur un VPS

Ce qu’est réellement un agent d’IA

Un agent d’IA est une boucle construite autour d’un modèle de langage. Le modèle analyse la situation, choisit une action, votre code exécute cette action, puis le résultat est renvoyé au modèle. La boucle recommence jusqu’à ce que la tâche soit terminée. C’est tout le principe. Un chatbot classique répond une fois, puis s’arrête. Un agent continue d’agir entre ses propres tours, jusqu’à atteindre l’objectif que vous lui avez donné. Cette boucle est suffisamment courte pour être écrite vous-même en une après-midi. C’est le point de départ de un parcours progressif pour apprendre à créer des agents depuis zéro, avant d’ajouter des outils, une mémoire et des mécanismes de sécurité.

L’action est l’élément important. Seul, un modèle de langage produit uniquement du texte. Il ne peut pas lire un fichier, appeler une API ou exécuter une commande. Un agent fournit au modèle un ensemble d’outils qu’il est autorisé à utiliser, ainsi qu’un moyen de les demander. Lorsque le modèle veut effectuer une recherche sur le Web ou écrire un fichier, il ne réalise pas lui-même cette opération. Il émet une requête structurée, votre code exécute l’outil, puis la réponse revient comme l’élément suivant que le modèle analyse. Le modèle fournit le jugement ; votre serveur fournit les moyens d’action.

Toutes les tâches ne nécessitent pas un agent, et utiliser un agent par défaut est une erreur fréquente. Si les étapes sont connues à l’avance, un simple script est plus facile, plus rapide et plus fiable. « Récupérer cette page toutes les heures et m’envoyer le prix par e-mail » correspond à une tâche planifiée, pas à un agent. Créez un agent lorsque le déroulement n’est pas défini à l’avance, lorsque le modèle doit examiner ce qu’il trouve et décider de la suite. Le coût d’un agent est son imprévisibilité. N’acceptez donc ce coût que lorsque la flexibilité le justifie.

Outils : fonctionnement d’un agent

Un outil est une fonctionnalité que vous fournissez au modèle et que vous décrivez suffisamment pour qu’il sache quand l’utiliser. Lire un fichier, exécuter une commande shell, interroger une base de données ou envoyer un message : chacune de ces actions constitue un outil avec un nom, une courte description et une liste d’entrées. Vous définissez les outils ; le modèle décide quand les appeler. La recherche web est généralement le premier outil à ajouter. Si vous exécutez déjà votre propre instance SearXNG, vous pouvez en faire le backend de recherche de l’agent au lieu de payer une API de recherche commerciale.

Le mécanisme est le même partout, quel que soit le modèle utilisé. Le modèle renvoie une requête structurée qui indique un outil et renseigne ses entrées. Votre code détecte cette requête, exécute la fonction correspondante, puis renvoie le résultat au tour suivant. Le modèle lit le résultat et appelle un autre outil ou rédige sa réponse finale. Le function calling constitue le mécanisme sous-jacent de chaque agent, et la boucle qui le pilote ne nécessite que quelques lignes de code courant.

C’est également à ce niveau que s’exerce votre contrôle. Le modèle peut demander l’exécution d’une commande, mais rien ne s’exécute tant que votre code n’a pas décidé de l’exécuter. C’est à cet endroit que vous ajoutez les demandes d’approbation pour les actions dangereuses, les limites concernant les ressources auxquelles un outil peut accéder et un journal de toutes les actions effectuées par l’agent. La sécurité d’un agent dépend des outils que vous lui fournissez et des contrôles que vous placez devant eux.

MCP : une méthode standard pour connecter des outils

Écrire manuellement une nouvelle intégration pour chaque service devient vite fastidieux. Le Model Context Protocol, ou MCP, est un standard ouvert qui résout ce problème. Au lieu de coder un nouvel outil pour vos fichiers, votre base de données et votre issue tracker, vous dirigez l’agent vers un serveur MCP qui les expose déjà sous forme d’outils. L’agent utilise un seul protocole ; le serveur se charge de communiquer avec le système réel.

L’intérêt principal est la réutilisation. Un serveur MCP écrit par quelqu’un d’autre pour un service que vous utilisez devient disponible pour votre agent sans nouveau code d’intégration. De même, un serveur que vous écrivez peut être utilisé par tout agent compatible avec le protocole. Certaines applications self-hosted en fournissent maintenant un : openGym, un suivi des entraînements expose un serveur MCP en lecture seule. Un agent peut ainsi répondre à des questions sur votre historique d’entraînement sans pouvoir le modifier. Sur un VPS, cette approche est utile, car vous pouvez exécuter les serveurs MCP comme de petits services indépendants à côté de l’agent, chacun avec les seuls accès nécessaires. Lorsque les systèmes situés derrière ces serveurs se trouvent sur un réseau que le VPS ne peut pas voir, par exemple une base de données à votre domicile ou dans un bureau, annoncer ce réseau à votre tailnet avec un subnet router permet à l’agent de les joindre via des adresses privées sans rien exposer sur l’internet public. Je présente la configuration dans exécuter des serveurs MCP sur un VPS.

Mémoire et récupération

Un modèle de langage n’a pas de mémoire propre entre deux appels. Vous devez lui transmettre à chaque tour tout ce qu’il doit savoir sur la tâche en cours. Pour une tâche courte, cela ne pose pas de problème, car toute la conversation tient dans une seule requête. La quantité de contenu dépend de la context window. Un modèle auto-hébergé servi par Ollama utilise par défaut une context window réduite qui supprime discrètement les tours les plus anciens. Il est donc préférable de configurer num_ctx en fonction du trafic généré par votre boucle avant d’accuser l’agent d’oublier. Pour les tâches plus longues, vous devez gérer vous-même la mémoire. Deux méthodes sont utiles à connaître.

La première est un scratchpad. Vous donnez à l’agent un fichier qu’il peut lire et modifier, puis vous lui demandez d’y enregistrer ce qu’il apprend au fil de l’exécution. Au tour suivant ou lors de la session suivante, il relit le fichier et reprend là où il s’était arrêté. Il s’agit d’une mémoire sous forme de document texte. Cette méthode fonctionne parce que l’agent traite le fichier comme un outil parmi d’autres.

La seconde est la retrieval. Lorsque l’agent doit exploiter les informations d’un grand ensemble de documents qui ne tiendrait jamais dans une seule requête, vous stockez ces documents dans un format interrogeable et vous n’injectez dans le contexte du modèle que les éléments pertinents au moment où ils sont nécessaires. Ce modèle est appelé retrieval-augmented generation, ou RAG. L’agent pose une question, votre code trouve les quelques passages correspondants, puis seuls ces passages sont transmis au modèle. Le stockage reste sur votre serveur. Vos documents privés ne le quittent donc jamais.

Plusieurs agents, un coordinateur

Un agent doté de nombreux outils suffit pour la plupart des tâches. Lorsqu’un travail est important ou se divise naturellement en plusieurs parties, une autre architecture est plus adaptée : un agent coordinateur qui délègue les tâches à des sous-agents spécialisés. Le coordinateur découpe l’objectif en plusieurs éléments, confie chaque élément à un sous-agent conçu pour ce type de travail, puis regroupe les résultats. La délégation nécessite un canal de communication entre les différentes parties. La solution la plus simple est déjà disponible sur votre serveur : deux sessions Claude Code sur le même VPS peuvent s’envoyer des messages. C’est un moyen peu coûteux de comprendre le fonctionnement des transferts de tâches avant de mettre en place votre propre mécanisme de coordination.

Le principal avantage est la concentration. Un sous-agent chargé d’une tâche précise et disposant d’un petit ensemble d’outils prend de meilleures décisions qu’un agent généraliste qui doit tout gérer. Les parties indépendantes peuvent également s’exécuter en parallèle. La coordination a toutefois un coût réel. Conservez donc un seul agent tant qu’une tâche ne nécessite pas clairement davantage. Commencez simplement et n’ajoutez des agents que lorsqu’un agent montre clairement ses limites.

Modèle auto-hébergé ou hébergé : quel modèle exécute votre agent

Le modèle est le seul composant d’un agent que vous n’avez pas besoin d’exécuter vous-même. Choisir où il s’exécute est la décision la plus importante. Un modèle hébergé, accessible via une API, fournit les meilleures capacités de raisonnement sans rien avoir à administrer : vous envoyez du texte et vous récupérez du texte. Un modèle auto-hébergé s’exécute sur votre propre serveur. Toutes les requêtes restent privées, le coût est fixe au lieu de dépendre du nombre de tokens, et le service ne dépend jamais de la disponibilité d’un tiers. Le compromis concerne les capacités et les efforts d’administration. Les meilleurs modèles hébergés sont plus performants que ceux que vous pouvez exécuter vous-même. L’exécution d’un modèle sur votre propre infrastructure exige aussi suffisamment de mémoire pour le charger.

C’est le principal point à vérifier en pratique. Le modèle doit tenir dans la mémoire de votre serveur et, si vous utilisez un GPU, dans sa mémoire vidéo. Un modèle trop volumineux pour le matériel ne se chargera pas. Avant de concevoir un agent auto-hébergé, vérifiez que le modèle choisi tient sur la machine dont vous disposez :

Si les valeurs ne correspondent pas, vous avez trois possibilités : choisir un modèle plus petit, utiliser une quantification plus agressive pour le réduire, ou utiliser une API hébergée pour le raisonnement et conserver uniquement vos outils et vos données sur le serveur. De nombreux agents auto-hébergés commencent avec un modèle local via Ollama sur un VPS, puis utilisent une API hébergée pour les étapes les plus complexes.

Le serveur est la partie dangereuse

Un agent capable d’exécuter des commandes shell et d’écrire des fichiers est puissant. C’est précisément ce qui le rend dangereux. Le jugement du modèle est bon, mais pas parfait. Une mauvaise instruction, un bug ou une entrée malveillante peut transformer un agent utile en un agent qui supprime le mauvais élément ou divulgue un secret. La sécurité n’est pas facultative. Sur un serveur, c’est l’aspect le plus important.

Quelques bonnes pratiques couvrent l’essentiel. Exécutez l’agent avec un utilisateur dédié sans privilèges, jamais avec root, afin de limiter les conséquences d’une erreur. Le même principe s’applique à l’exécution des services avec un utilisateur sans privilèges. Conservez ses secrets, comme les clés d’API, en dehors du code et rendez-les lisibles uniquement par cet utilisateur. Isolez également les outils qui accèdent au système, afin que l’agent ne puisse atteindre que ce dont il a réellement besoin. Si vous préférez ne pas écrire vous-même chaque contrôle, les plugins DeepSeek Harness à installer couvrent les mêmes besoins avec des composants prêts à l’emploi : règles d’autorisation des outils, détection des prompt injections et plafond des dépenses de l’agent avant son arrêt. Pour un exemple complet de sécurisation d’un agent auto-hébergé réel, consultez exécuter OpenClaw en toute sécurité sur un VPS. Si vous préférez utiliser un modèle hébergé pour l’intelligence, le guide associé créer un agent avec Claude sur un VPS reprend les mêmes principes et leur associe un modèle précis.

Pour un exemple complet, créer un agent personnel de type OpenClaw met en œuvre ces éléments. Si vous préférez exécuter un agent déjà finalisé, commencez par auto-héberger Hermes Agent sur un VPS ou exécuter Agent Zero sur votre propre serveur. La page meilleurs agents IA auto-hébergés en 2026 compare côte à côte toutes les solutions prêtes à l’emploi que nous présentons.

FAQ

Quelle est la différence entre un agent IA et un chatbot ?

Un chatbot répond à un message, puis s’arrête. Un agent exécute une boucle : le modèle choisit une action, votre code l’exécute, le résultat est renvoyé au modèle, puis le processus recommence jusqu’à la fin de la tâche. La différence est qu’un agent effectue de véritables actions entre ses tours, en appelant des outils pour lire des fichiers, exécuter des commandes ou interroger des services, au lieu de produire uniquement du texte.

Ai-je besoin d’un GPU pour exécuter un agent IA sur un VPS ?

Uniquement si vous hébergez vous-même le modèle. La boucle de l’agent, les outils et la mémoire sont du code classique qui fonctionne sur un VPS standard sans GPU. Un GPU devient utile lorsque vous voulez exécuter le modèle de langage sur votre propre matériel, car le modèle doit tenir en mémoire. Si vous utilisez un modèle hébergé via une API, les calculs lourds sont effectués ailleurs et un VPS modeste suffit.

Qu’est-ce que MCP et en ai-je besoin pour créer un agent ?

MCP, le Model Context Protocol, est un standard ouvert qui permet de connecter un agent à des outils et à des sources de données. Vous n’en avez pas strictement besoin, car vous pouvez écrire chaque outil manuellement. MCP vous évite ce travail en vous permettant de réutiliser des serveurs existants pour les services courants et d’exposer vos propres systèmes une seule fois afin que n’importe quel agent puisse les utiliser. C’est une solution pratique qui devient intéressante lorsque le nombre d’intégrations augmente.

Est-il sûr de donner à un agent IA l’accès à mon serveur ?

Cela peut être sûr si vous l’isolez. Un agent qui exécute des commandes n’est pas plus sûr que le compte sous lequel il s’exécute et les outils que vous l’autorisez à utiliser. Exécutez-le avec un utilisateur non privilégié, gardez ses secrets hors de sa portée, sandboxez les outils qui accèdent au système de fichiers et exigez une approbation pour les actions difficiles à annuler. Traitez l’agent comme du code non fiable qui serait simplement capable de raisonner, et donnez-lui uniquement ce dont la tâche a besoin.