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. Tout ce qu’il doit savoir sur la tâche en cours doit lui être transmis à chaque tour. 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 fenêtre de contexte. Un modèle auto-hébergé servi par Ollama sur un serveur disposant de moins de 24 GiB de mémoire GPU, ou d’aucune mémoire GPU, utilise par défaut une petite fenêtre de 4k. Il supprime alors discrètement les tours les plus anciens. Il est donc préférable de définir num_ctx pour l’adapter au trafic généré par votre boucle avant d’attribuer les oublis à l’agent. Pour les tâches plus longues, vous devez gérer vous-même la mémoire. Deux méthodes sont particulièrement utiles.

La première méthode est le 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 la tâche. Au tour suivant, ou lors de la session suivante, il relit le fichier et reprend là où il s’était arrêté. La mémoire prend ici la forme d’un simple document. Cette méthode fonctionne parce que l’agent traite le fichier comme un outil supplémentaire.

La seconde méthode est la récupération. 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. Vous injectez ensuite dans le contexte du modèle uniquement les éléments pertinents, au moment où ils sont nécessaires. Cette méthode s’appelle la génération augmentée par récupération, ou RAG. L’agent pose une question, votre code recherche les quelques passages correspondants, puis transmet uniquement ces passages au modèle. Le stockage se trouve 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.

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’êtes pas obligé d’exécuter vous-même. Le choix de son emplacement est la décision la plus importante à prendre. Un modèle hébergé, accessible via une API, offre le meilleur raisonnement sans vous demander d’exploiter l’infrastructure : vous envoyez du texte et vous recevez du texte en retour. Un modèle auto-hébergé s’exécute sur votre propre serveur. Vos requêtes restent ainsi sur du matériel que vous contrôlez. Vous remplacez le coût par token par le prix du serveur et vous ne dépendez pas de la disponibilité de l’API d’un fournisseur de modèles. Le compromis porte sur les capacités et l’effort d’exploitation. Les meilleurs modèles hébergés sont plus performants que ceux que vous pouvez exécuter vous-même. L’exécution de votre propre modèle exige aussi de lui fournir suffisamment de mémoire.

C’est le point pratique le plus contraignant. Un modèle doit tenir dans la mémoire de votre serveur. Si vous utilisez un GPU, il doit également tenir dans sa mémoire vidéo. Un modèle trop volumineux pour le matériel ne pourra pas être chargé. Avant de planifier un agent auto-hébergé, vérifiez que le modèle souhaité tient sur la machine dont vous disposez :

Si les valeurs ne correspondent pas, quatre possibilités s’offrent à vous : choisir un modèle plus petit, utiliser une quantification plus agressive pour le réduire, passer à un serveur disposant de davantage de mémoire ou répartir le modèle sur plusieurs GPU, ou utiliser une API hébergée pour le raisonnement tout en conservant 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.