Agent IA, LLM ou assistant IA : quelles différences ?

Quelle est la différence entre un agent IA, un LLM et un assistant IA ?

Un agent IA, un LLM et un assistant IA sont trois couches d’une même pile. Pour les distinguer, demandez-vous ce dont chacune a besoin sur un serveur. Un LLM (large language model) est un fichier de poids qui a besoin de RAM et de puissance de calcul. Un assistant est ce modèle intégré à une interface de chat, avec un compte et un historique enregistré, presque toujours sur le matériel de quelqu’un d’autre. Un agent est un assistant qui dispose également d’outils et d’une boucle d’exécution. Il détient aussi des credentials, ce qui l’oblige à fonctionner sur une machine qui reste allumée.

La plupart des articles consacrés à cette question s’arrêtent aux définitions. Ces définitions ne sont utiles que parce que chaque couche vous est facturée différemment. La première consomme de la RAM. La suivante nécessite une URL publique et TLS (transport layer security). La dernière nécessite des credentials. Tout credential qu’un agent a utilisé doit ensuite être renouvelé.

Un LLM, ce sont des poids, et les poids ont besoin de RAM

Un LLM est un fichier de nombres. Vous le téléchargez, un runtime le charge en mémoire, puis il répond à une requête à la fois. Le contrat est limité : du texte en entrée, du texte en sortie. Le modèle n’a aucune mémoire entre les appels, aucune horloge, aucun accès réseau et aucun moyen d’ouvrir un fichier. Tout ce qu’un LLM semble retenir a été placé dans son contexte par le programme qui l’appelle.

Le nombre qui détermine le forfait VPS est la taille de ce fichier, car il reste entièrement en mémoire pendant l’exécution du modèle. Avec la quantification sur 4 bits fournie par défaut par Ollama, comptez environ 0.6 GB par milliard de paramètres, puis ajoutez un ou deux gigaoctets pour la fenêtre de contexte et le runtime lui-même.

[
  {
    "label": "qwen3:4b",
    "download_gb": 2.5,
    "ram_gb_needed": 6
  },
  {
    "label": "qwen3:8b",
    "download_gb": 5.2,
    "ram_gb_needed": 8
  },
  {
    "label": "qwen3:14b",
    "download_gb": 9.3,
    "ram_gb_needed": 12
  },
  {
    "label": "qwen3:32b",
    "download_gb": 20.0,
    "ram_gb_needed": 24
  }
]

La build qwen3:8b fait 5.2 GB sur disque et nécessite environ 8 GB de RAM pour fonctionner sans swap. Un VPS de 4 GB ne pourra pas charger qwen3:14b, qui fait 9.3 GB avant même que vous lui saisissiez un seul mot. La plus grande ligne de ce tableau, qwen3:32b, nécessite environ 24 GB, ce qui correspond généralement à un forfait différent et à une facture mensuelle différente dans la plupart des grilles tarifaires.

Tenir en mémoire est une question. La vitesse en est une autre. Sur un VPS utilisant uniquement le CPU, le goulot d’étranglement est la bande passante mémoire plutôt que la fréquence d’horloge. Un modèle qui tient en mémoire peut donc répondre à seulement quelques tokens par seconde. Cela convient à une tâche exécutée pendant la nuit, mais c’est désagréable pour une conversation. Un GPU augmente ce débit d’environ un ordre de grandeur, et augmente aussi votre facture. Prenez donc votre décision à partir d’une mesure : évaluez les performances du VPS avec la charge que vous prévoyez d’exécuter et consultez dans quels cas un VPS avec GPU justifie son prix. Pour faire fonctionner les poids, commencez par Ollama sur votre propre VPS.

Un assistant est un LLM avec une interface de chat

Un assistant est la couche produit qui entoure un modèle. ChatGPT et Claude sont des assistants : un modèle, une fenêtre de chat, un compte, des conversations enregistrées et une limite de débit. Presque aucun de ces éléments ne s’exécute sur du matériel que vous contrôlez. C’est pourquoi un assistant hébergé coûte un abonnement et 0 RAM.

La version auto-hébergée est un frontend tel qu’Open WebUI, connecté à une instance Ollama locale ou à une API hébergée. Le frontend est un logiciel léger. Prévoyez environ 1 Go de mémoire résidente pour l’interface de chat, en plus de la mémoire nécessaire au modèle. En revanche, il a besoin d’une URL publique et d’un certificat, contrairement à un modèle seul, car vous voulez y accéder depuis un téléphone : émettre le certificat avec Certbot et Nginx, ou terminer TLS avec Traefik devant plusieurs applications. Si vous cherchez encore un frontend, comparez les alternatives à Open WebUI.

Un assistant répond. Il n’agit pas. Lorsqu’il écrit une commande shell, une personne lit cette commande et décide de la coller ou non. Cette personne constitue une couche de sécurité ; un agent est ce qui la supprime.

Un agent ajoute des outils et une boucle

Un agent est un assistant capable d’appeler des fonctions, puis d’en lire les résultats. Deux éléments assurent ce fonctionnement. Le premier est un outil : la description d’une fonction que le modèle peut demander, ainsi que votre code qui l’exécute réellement. Le second est la boucle : votre programme appelle le modèle, le modèle demande un outil, votre programme l’exécute, ajoute sa sortie à la conversation, puis rappelle le modèle. Le cycle se répète jusqu’à ce que le modèle indique qu’il a terminé ou qu’une limite l’arrête.

La boucle est du code ordinaire, et une version de base tient en moins de cent lignes. Ce qui en fait un agent, c’est que les outils utilisent de véritables credentials : la boucle peut donc modifier quelque chose à l’extérieur d’elle-même. Ce point détermine tous les choix d’hébergement présentés ci-dessous. Les compétences des agents et les serveurs MCP (model context protocol) sont deux moyens de fournir davantage d’outils à un agent sans réécrire la boucle.

• Il doit continuer à fonctionner en dehors de votre session. Un chat se termine lorsque vous fermez l’onglet. Une exécution d’agent peut durer vingt minutes et doit survivre à la mise en veille de votre laptop. Elle doit donc être exécutée sur une machine qui reste allumée, et lancée par un service ou un timer systemd qui la redémarre après un reboot.
• Il contient des secrets : une clé API, une clé SSH ou le mot de passe d’une base de données. Tout ce que l’agent peut lire peut être utilisé par une instruction hostile dissimulée dans son entrée. Vous devez donc garder les secrets hors de portée de l’agent.
• Son coût augmente avec la boucle, et non avec votre question. À chaque étape, l’intégralité de la conversation est renvoyée comme entrée. Une exécution en dix étapes facture donc cette transcription dix fois. C’est pourquoi les tokens d’entrée représentent l’essentiel du coût d’un agent et pourquoi vous devez définir une limite stricte sur le montant qu’une exécution peut dépenser.
• Il peut produire une erreur qui modifie réellement le système. Une mauvaise réponse dans un chat vous oblige à relire le résultat. Une mauvaise commande delete dans une boucle peut supprimer le répertoire. Exécutez-le avec un utilisateur disposant des privilèges minimaux nécessaires à son fonctionnement et, pour les coding agents, utilisez un sandbox avant de lui donner accès à votre repository.

Ce dont chaque couche a besoin sur la machine

[
  {
    "label": "LLM (weights you host)",
    "ram_gb": 8,
    "gpu": "helps a lot",
    "public_url": "no",
    "credentials": "none"
  },
  {
    "label": "Assistant (chat surface)",
    "ram_gb": 1,
    "gpu": "no",
    "public_url": "yes",
    "credentials": "one login"
  },
  {
    "label": "Agent (tools and a loop)",
    "ram_gb": 2,
    "gpu": "no",
    "public_url": "only for webhooks",
    "credentials": "several"
  }
]

Lisez attentivement la colonne RAM, car elle exclut le modèle. Une interface de chat et un runtime d’agent sont deux petits programmes. Si l’agent appelle un modèle hébergé, 2 Go de RAM suffisent pour l’exécuter, et un forfait peu coûteux constitue une réponse réelle, pas un compromis. Si vous placez les poids sur la même machine, la ligne du modèle de 8 Go domine tout le reste.

Les autres colonnes comptent davantage qu’on ne le pense. Seule la couche du modèle accélère avec un GPU. Seule la couche assistant a systématiquement besoin d’une URL publique, car un navigateur doit pouvoir y accéder ; un agent n’en a besoin que lorsqu’un système externe doit l’appeler, par exemple via un webhook. De plus, un agent détient several identifiants, ce qui constitue la véritable différence avec une fenêtre de chat. Une fenêtre de chat peut se tromper. Un agent peut se tromper, puis agir en conséquence.

Faut-il un GPU pour exécuter un agent IA ?

Non, sauf si vous hébergez également les weights sur la même machine. La boucle de l’agent consiste à envoyer des requêtes HTTP, à analyser du JSON et à lancer des subprocess. Le CPU reste presque inactif pendant l’attente du réseau. La question du GPU concerne en réalité la couche LLM.

Il faut donc séparer les deux décisions. Si le texte ne peut pas quitter votre serveur, prévoyez suffisamment de mémoire pour charger un modèle et, pour obtenir une vitesse utilisable, un GPU pour l’exécuter. Si vous voulez uniquement l’automatisation, louez le modèle à l’usage, par token, et consacrez plutôt votre budget à la disponibilité et aux sauvegardes. En 2026, la plupart des agents self-hosted appellent un modèle hébergé. Leur coût d’exploitation est donc inférieur.

Pouvez-vous auto-héberger un agent IA ?

Oui. L’agent est la couche qui mérite le plus d’être auto-hébergée, car c’est dans la boucle que se trouvent vos données et vos identifiants. Un petit VPS avec 2 GB de RAM, un gestionnaire de services et un accès réseau sortant suffit pour exécuter un véritable agent. Suivez la méthode de création sur un VPS si vous voulez contrôler toute la boucle, ou déployez l’un des agents self-hosted prêts à l’emploi si vous préférez partir d’une solution déjà terminée.

L’auto-hébergement de l’assistant est simple : un conteneur et un certificat suffisent. L’auto-hébergement du modèle est la partie coûteuse. Beaucoup abandonnent après avoir vu les tokens être générés au ralenti par un CPU. Hébergez vous-même les weights lorsque les données ne peuvent pas quitter le serveur, ou lorsque votre volume d’utilisation rend la tarification par token trop coûteuse. Sinon, laissez l’agent appeler une API et gardez les composants intéressants en local.

ChatGPT est-il un agent d’IA ?

Un produit conversationnel devient un agent dès qu’il peut appeler un outil et agir sur le résultat sans vous demander votre accord au préalable. Selon ce critère, les assistants hébergés qui disposent de fonctions de navigation web, d’exécution de code ou de connecteurs sont des agents. Pour vous, la différence tient à l’endroit où s’exécute la boucle et aux identifiants qu’elle utilise. Dans un produit hébergé, ces deux éléments relèvent du fournisseur. Sur votre propre serveur, ils relèvent de vous, tout comme la responsabilité de ce que la boucle exécute à trois heures du matin.

Réactif, planification et multi-agent

Les récapitulatifs aiment distinguer sept types d’agents. La plupart de ces catégories relèvent du marketing. Deux distinctions modifient le code que vous écrivez, et une autre modifie la facture. Un agent réactif appelle un outil, lit la réponse, puis répond. Un agent de planification rédige d’abord un plan, puis l’exécute étape par étape. Cette approche tient mieux sur les tâches longues, mais elle consomme davantage de tokens, car le plan est renvoyé à chaque étape. Une architecture multi-agent permet à un agent d’en lancer d’autres. Elle multiplie donc simultanément la consommation de tokens et les modes de défaillance. Elle n’est rentable que lorsque les sous-tâches sont réellement indépendantes, par exemple pour rechercher quatre sources en parallèle. Commencez par le mode réactif. Ajoutez la planification lorsque les exécutions deviennent longues. Ne passez au multi-agent qu’en dernier recours. Pour une vue d’ensemble, consultez ce qu’il vaut la peine d’apprendre sur les agents IA en 2026.

Déterminer sur quelle couche vous exécutez réellement le service

Sur le serveur, vérifiez quels processus utilisent la mémoire.

free -h
ps -eo rss,comm --sort=-rss | head -5

Si la première ligne correspond à ollama ou llama-server et utilise plusieurs gigaoctets de RSS (resident set size, c’est-à-dire la mémoire réellement occupée par un processus), vous hébergez le modèle. Si aucun processus ne dépasse quelques centaines de mégaoctets et que votre facture d’API continue d’augmenter, vous hébergez un agent ou un assistant et vous louez le modèle. Si la liste est vide parce que tout s’exécute dans un onglet du navigateur, vous utilisez un assistant en tant que client. C’est une situation tout à fait acceptable jusqu’à ce que vous ayez besoin d’un logiciel qui agisse en votre nom.

Lequel souhaitez-vous exécuter ?

• Pour garder le texte privé, exécutez le modèle : héberger un LLM avec Ollama, puis comparez les moteurs avec Ollama et vLLM lorsqu’un utilisateur devient dix.
• Pour contrôler la boucle et les outils, construisez l’agent : construire votre propre agent IA sur un VPS.
• Pour disposer d’un système fonctionnel dès ce soir, déployez-en un prêt à l’emploi parmi les agents auto-hébergés qui valent la peine d’être exécutés.
• Si aucun de ces éléments ne repose encore sur un serveur, commencez par ce qu’un VPS vous fournit réellement.

FAQ

Un agent IA est-il simplement un LLM avec quelques étapes supplémentaires ?

Les étapes supplémentaires constituent le produit. Un LLM transforme du texte en texte, rien de plus. Un agent l’entoure d’outils qu’il peut appeler et d’une boucle qui continue de les appeler. Ces outils disposent d’identifiants d’authentification. La sortie peut donc modifier un fichier, une base de données ou un service en production. C’est pourquoi un agent a besoin d’une machine qui reste allumée, d’un service manager et d’une politique de gestion des secrets. Un LLM a seulement besoin de suffisamment de mémoire pour conserver ses poids pendant qu’il répond.

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

Pas pour l’agent. La boucle effectue des requêtes HTTP, traite du JSON et lance des subprocess. N’importe quel CPU peut gérer ces opérations pendant les attentes réseau. Vous avez besoin d’un GPU uniquement si vous hébergez vous-même les poids du modèle et souhaitez obtenir plus de quelques tokens par seconde. Un agent qui appelle un modèle hébergé fonctionne parfaitement sur un petit VPS sans GPU.

De quelle quantité de RAM un VPS a-t-il besoin pour un agent IA ?

Environ 2 Go lorsque l’agent appelle un modèle hébergé, car il ne conserve que le runtime, ses dépendances et une petite base de données locale. Si vous hébergez les poids, ajoutez le modèle à cette quantité : qwen3:8b demande à lui seul environ 8 Go. Un serveur tout-en-un commence donc à ce niveau et augmente selon le modèle choisi.

Puis-je auto-héberger un assistant IA et garder mes conversations privées ?

Oui, avec une réserve qui détermine tout. Un front end auto-hébergé comme Open WebUI conserve les comptes et l’historique sur votre serveur. Les conversations restent privées uniquement si le modèle utilisé est lui aussi local. Si vous connectez le même front end à une API hébergée, le texte quitte votre serveur à chaque message. Vous conservez donc l’historique, mais pas la confidentialité.

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

Un chatbot répond, puis s’arrête. Un agent décide de l’étape suivante, appelle un outil, lit le résultat et décide à nouveau, jusqu’à ce que la tâche soit terminée ou qu’une limite l’arrête. Le test pratique est simple : si le logiciel peut modifier quelque chose sans qu’un humain appuie sur un bouton entre la réponse et l’action, il s’agit d’un agent. Il a donc besoin de l’hébergement et des garde-fous associés.