Créer votre propre agent IA sur un VPS

Ce qu'est réellement un agent IA

Un agent IA est une boucle enroulée autour d'un modèle de langage. Le modèle lit la situation, décide d'une action, votre code exécute cette action, le résultat repart vers le modèle, et la boucle recommence jusqu'à ce que la tâche soit terminée. C'est toute l'idée. Un simple chatbot répond une fois puis s'arrête. Un agent continue, en prenant de vraies actions entre ses propres tours, jusqu'à atteindre l'objectif que vous lui avez donné.

L'action est la partie importante. Seul, un modèle de langage ne produit que du texte. Il ne peut pas lire un fichier, appeler une API, ni exécuter une commande. Un agent donne au modèle un ensemble d'outils qu'il est autorisé à utiliser, et un moyen de les demander. Quand le modèle veut chercher sur le web ou écrire un fichier, il ne fait pas le travail lui-même. Il émet une requête structurée, votre code exécute l'outil, et la réponse revient comme la prochaine chose que le modèle lit. Le modèle fournit le jugement ; votre serveur fournit les mains.

Toutes les tâches n'ont pas besoin d'un agent, et en choisir un par défaut est une erreur courante. Si les étapes sont connues à l'avance, un simple script est plus simple, plus rapide et plus fiable. « Récupérer cette page toutes les heures et m'envoyer le prix par e-mail » est une tâche planifiée, pas un agent. Construisez un agent quand le chemin n'est pas fixé à l'avance, quand le modèle doit regarder ce qu'il trouve et décider de la suite. Le coût d'un agent est l'imprévisibilité, alors ne le payez que lorsque la flexibilité en vaut la peine.

Les outils : comment un agent agit

Un outil est n'importe quelle capacité que vous confiez au modèle, décrite assez bien pour qu'il sache quand y recourir. Lire un fichier, exécuter une commande shell, interroger une base de données, envoyer un message : chacun est 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.

Le mécanisme est le même partout, quel que soit le modèle que vous utilisez. Le modèle renvoie une requête structurée qui nomme un outil et remplit ses entrées. Votre code voit cette requête, exécute la fonction correspondante et renvoie le résultat au tour suivant. Le modèle lit le résultat et soit appelle un autre outil, soit rédige sa réponse finale. L'appel de fonction (function calling) est la tuyauterie sous chaque agent, et la boucle qui l'anime ne fait que quelques lignes de code ordinaire.

C'est aussi là que réside votre contrôle. Le modèle peut demander d'exécuter une commande, mais rien ne s'exécute tant que votre code n'a pas choisi de le faire. Cet écart est l'endroit où vous placez les demandes d'approbation pour les actions dangereuses, les limites sur ce qu'un outil peut toucher, et un journal de tout ce que l'agent a fait. Un agent n'est jamais plus sûr que les outils que vous lui donnez et que les contrôles que vous placez devant eux.

MCP : une façon standard de connecter des outils

Écrire à la main une nouvelle intégration pour chaque service devient vite lassant. 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 suivi de tickets, vous pointez l'agent vers un serveur MCP qui expose déjà ces éléments sous forme d'outils. L'agent parle un seul protocole ; le serveur se charge de dialoguer avec le vrai système.

Le bénéfice 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, et un serveur que vous écrivez est utilisable par n'importe quel agent qui parle le protocole. Sur un VPS, cela compte, car vous pouvez faire tourner les serveurs MCP comme leurs propres petits services à côté de l'agent, chacun n'ayant que l'accès dont il a besoin. Je détaille la mise en place dans exécuter des serveurs MCP sur un VPS.

Mémoire et récupération

Un modèle de langage n'a aucune mémoire propre entre deux appels. Tout ce qu'il sait sur la tâche en cours doit lui être fourni à chaque tour. Pour une tâche courte, c'est très bien, car toute la conversation tient dans une seule requête. Pour quoi que ce soit de plus long, vous devez gérer la mémoire vous-même, et il y a deux approches à connaître.

La première est un bloc-notes. Vous donnez à l'agent un fichier qu'il peut lire et écrire, et vous lui dites d'y noter ce qu'il apprend au fil de l'eau. Au tour suivant, ou à la session suivante, il relit le fichier et reprend là où il s'était arrêté. C'est la mémoire sous forme de simple document, et cela fonctionne parce que l'agent traite le fichier comme un outil parmi d'autres.

La seconde est la récupération. Quand l'agent a besoin de connaissances issues d'un grand ensemble de documents qui ne tiendraient jamais dans une seule requête, vous stockez ces documents sous une forme interrogeable et vous n'apportez à la vue du modèle que les passages pertinents, au moment où ils sont nécessaires. Cette approche s'appelle la génération augmentée par récupération, ou RAG (retrieval-augmented generation). L'agent pose une question, votre code trouve la poignée de passages correspondants, et seuls ceux-là vont au modèle. Le stockage vit sur votre serveur, donc vos documents privés ne le quittent jamais.

Plusieurs agents, un coordinateur

Un seul agent doté de nombreux outils convient à la plupart des tâches. Quand un travail est vaste ou se divise naturellement en plusieurs parties, une autre forme aide : un agent coordinateur qui délègue à des sous-agents spécialisés. Le coordinateur découpe l'objectif en morceaux, confie chaque morceau à un sous-agent conçu pour ce type de travail, et combine les résultats.

Le gain est la concentration. Un sous-agent avec une tâche étroite et un petit ensemble d'outils prend de meilleures décisions qu'un généraliste qui jongle avec tout, et des morceaux indépendants peuvent s'exécuter en même temps. Le coût est la coordination, qui est réelle, alors tenez-vous-en à un seul agent jusqu'à ce qu'une tâche en réclame clairement davantage. Commencez simplement, et n'ajoutez des agents que lorsque l'un d'eux peine visiblement.

Auto-hébergé ou hébergé : quel modèle fait tourner votre agent

Le modèle est la seule partie d'un agent que vous n'êtes pas obligé de faire tourner vous-même, et choisir où il vit est la plus grande décision que vous prendrez. Un modèle hébergé, atteint via une API, vous donne le raisonnement le plus puissant sans rien à exploiter : vous envoyez du texte, vous récupérez du texte. Un modèle auto-hébergé tourne sur votre propre serveur, ce qui garde chaque requête privée, coûte un prix fixe au lieu d'un tarif par jeton, et ne dépend jamais du maintien en ligne d'un tiers. Le compromis porte sur la capacité et l'effort. Les meilleurs modèles hébergés sont en avance sur ce que vous pouvez faire tourner vous-même, et faire tourner le vôtre implique de lui fournir assez de mémoire pour le contenir.

Ce dernier point est le piège pratique. Un 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 grand pour le matériel ne se chargera pas. Avant de planifier un agent auto-hébergé, vérifiez si le modèle que vous voulez tient sur la machine dont vous disposez :

Si les chiffres ne collent pas, vous avez trois options : 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 ne garder que vos outils et vos données sur le serveur. Beaucoup d'agents auto-hébergés commencent avec un modèle local via Ollama sur un VPS et se rabattent sur une API hébergée pour les étapes les plus difficiles.

Le serveur est la partie dangereuse

Un agent qui peut exécuter des commandes shell et écrire des fichiers est puissant, et c'est exactement pour cela qu'il est dangereux. Le jugement du modèle est bon mais pas parfait, et une mauvaise instruction, un bug, ou une entrée hostile peut transformer un agent utile en un agent qui supprime la mauvaise chose ou divulgue un secret. Le travail de sécurité n'est pas optionnel, et sur un serveur c'est la partie qui compte le plus.

Quelques habitudes portent l'essentiel du poids. Exécutez l'agent en tant qu'utilisateur dédié non privilégié, jamais en root, pour qu'une erreur ait un plafond ; le même raisonnement figure dans exécuter des services avec un utilisateur non privilégié. Gardez ses secrets, comme les clés d'API, hors du code et lisibles uniquement par cet utilisateur. Et isolez dans un bac à sable les outils qui touchent au système, pour que l'agent ne puisse atteindre que ce dont il a réellement besoin. Pour un exemple concret de durcissement d'un vrai agent auto-hébergé, voyez 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 compagnon sur créer un agent avec Claude sur un VPS reprend les mêmes idées et place un modèle précis derrière elles.

Pour un exemple concret, créer un agent personnel de type OpenClaw applique ces éléments, et si vous préférez en faire tourner un déjà prêt, commencez par héberger vous-même Hermes Agent sur un VPS ou exécuter Agent Zero sur votre propre serveur, et les meilleurs agents IA auto-hébergés en 2026 compare toutes les options prêtes à l'emploi que nous couvrons, côte à côte.

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 décide d'une action, votre code l'exécute, le résultat repart vers le modèle, et cela se répète jusqu'à ce que la tâche soit finie. La différence, c'est qu'un agent prend de vraies actions entre ses tours, en appelant des outils pour lire des fichiers, exécuter des commandes ou interroger des services, plutôt que de seulement produire du texte.

Ai-je besoin d'un GPU pour faire tourner un agent IA sur un VPS ?

Seulement si vous auto-hébergez le modèle. La boucle de l'agent, les outils et la mémoire sont du code ordinaire qui tourne très bien sur un VPS normal sans GPU. Un GPU compte quand vous voulez faire tourner 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, le gros du calcul se fait ailleurs et un VPS modeste suffit.

Qu'est-ce que MCP et en ai-je besoin pour construire un agent ?

MCP, le Model Context Protocol, est un standard ouvert pour connecter un agent à des outils et des sources de données. Vous n'en avez pas strictement besoin, puisque vous pouvez écrire chaque outil à la main. MCP vous épargne ce travail en vous laissant réutiliser des serveurs existants pour les services courants et exposer vos propres systèmes une seule fois pour n'importe quel agent. C'est un confort qui devient rentable à mesure que le nombre d'intégrations grandit.

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

Cela peut l'être, si vous le contenez. Un agent qui exécute des commandes n'est jamais plus sûr que le compte sous lequel il tourne et les outils que vous autorisez. Exécutez-le en tant qu'utilisateur non privilégié, gardez ses secrets hors de portée, isolez dans un bac à sable les outils qui touchent au système de fichiers, et exigez une approbation pour les actions difficiles à annuler. Traitez l'agent comme du code non fiable qui se trouve être astucieux, et ne lui donnez que ce dont la tâche a besoin.