IA agentique en local : débuter avec un modèle sur son PC
Modèle, moteur, mémoire et outils : les repères pour débuter avec un agent IA local, un premier exercice en lecture seule et les limites à connaître.
Un agent IA local associe un modèle, un moteur comme Ollama et un programme qui contrôle les outils. Pour débuter, une petite tâche vérifiable compte davantage que le plus gros modèle.
- Un modèle local peut fonctionner hors ligne, mais les outils et les services reliés à l’agent peuvent envoyer des données à l’extérieur.
- La mémoire doit accueillir les poids du modèle, le contexte et le travail du moteur. Le format GGUF ne signifie pas automatiquement « quantifié ».
- Ollama et LM Studio sont deux points de départ. Le choix du moteur dépend du matériel, des usages et des réglages dont vous avez besoin.
- Le parcours proposé utilise qwen3:4b et un seul outil en lecture seule. Une réponse qui affirme avoir consulté un dossier ne prouve pas que l’outil a été appelé.
- Fixez une limite d’étapes, observez les résultats réels et gardez une validation humaine pour les actions sensibles.
Vous demandez à une IA de regarder un dossier. Elle répond « c’est fait ». Très bien. Mais a-t-elle réellement ouvert quelque chose, ou a-t-elle seulement rédigé une réponse convaincante ? Pour débuter avec un agent local, c’est cette différence qu’il faut apprendre à voir.
Ce guide explique les éléments à assembler, les limites du matériel et un premier exercice volontairement modeste. Il porte sur l’utilisation de modèles de langage, pas sur leur entraînement. Les illustrations sont des métaphores générées par IA, pas des captures de logiciels ni des schémas de matériel réel.
IA agentique : de quoi parle-t-on exactement ?
Dans un échange de texte simple, un modèle produit une réponse à partir de ce qu’il reçoit. Un agent ajoute un programme qui peut lui présenter des outils, exécuter les appels autorisés et lui renvoyer leurs résultats. Le modèle peut alors choisir une étape suivante, jusqu’à une réponse finale ou une condition d’arrêt.
Le modèle ne lit donc pas votre disque par magie. Si un outil de lecture est disponible, il peut demander son utilisation ; c’est le programme autour du modèle qui effectue l’opération. Ce programme, parfois appelé « harnais », gère aussi les permissions, l’historique et les erreurs.
La boucle d’un agent
Recevoir un objectif
Une demande précise et un résultat que vous savez vérifier.
Demander un outil
Le modèle produit un appel structuré parmi les outils autorisés.
Observer le résultat
Le programme exécute l’outil et renvoie ce qui s’est réellement passé.
Continuer ou s’arrêter
Le modèle répond ou demande une autre étape, dans les limites fixées.
Classer des factures, lire des PDF et préparer un tableau demande déjà plusieurs outils et des vérifications. Pour un premier essai, lister les noms de quelques fichiers suffit. Un agent qui enchaîne dix mauvaises actions ne devient pas dix fois plus utile.
Modèle, moteur et agent : trois éléments à distinguer
Qui fait quoi ?
Le modèle
Les poids entraînés produisent des réponses et, si le modèle le permet, des demandes d’appel d’outils.
Le moteur local
Ollama, LM Studio ou un autre moteur charge le modèle et calcule ses réponses sur le matériel disponible.
Le programme de l’agent
Il transmet les consignes, contrôle les appels d’outils, conserve les échanges et décide quand interrompre la boucle.
Le modèle propose ; le programme autorise et exécute. Cette distinction aide à comprendre une panne : modèle mal adapté, moteur mal réglé ou outil mal défini ne se corrigent pas de la même manière.
Pourquoi choisir un modèle local plutôt que le cloud ?
Le local vous donne la main sur les fichiers du modèle, sa version et les réglages d’exécution. Il peut éviter d’envoyer les requêtes d’inférence à un fournisseur distant et de payer ces requêtes au token. Certaines fonctions restent disponibles sans connexion une fois les logiciels et les modèles téléchargés.
Ce contrôle a un coût : matériel éventuel, électricité, maintenance et temps de configuration. Un outil externe peut aussi rester payant. Une machine dédiée ne devient pas automatiquement rentable parce qu’elle tourne tous les jours ; il faut comparer le coût complet pour votre volume de travail.
Local ou cloud : les compromis
Confidentialité
Le calcul peut rester sur la machine. Les recherches web, connecteurs, modèles distants et services de traçage doivent être contrôlés séparément.
Coût
Le cloud peut facturer l’usage ou un abonnement. Le local déplace une partie de la dépense vers le matériel, l’énergie et l’entretien.
Vitesse
Le local évite un aller-retour vers un serveur distant, mais un modèle trop lourd ou un contexte mal réglé peut le rendre lent.
Qualité
Comparez les erreurs et les résultats sur votre tâche. Ni le lieu d’exécution ni la taille du modèle ne suffisent à établir un classement.
La documentation de LM Studio distingue les fonctions locales utilisables hors ligne des recherches, téléchargements et mises à jour qui demandent une connexion. La documentation de LangChain propose aussi un traçage distant facultatif avec LangSmith. « Modèle local » et « aucun échange réseau » sont donc deux choses à vérifier séparément.
Choisir son matériel : VRAM, RAM et stockage
Sur un PC avec une carte graphique dédiée, la VRAM est un premier filtre : elle accueille les poids du modèle, le cache de contexte et les espaces de travail du moteur. La taille du fichier téléchargé ne correspond pas à toute la mémoire nécessaire pendant l’utilisation.
- Vérifiez d’abord que le moteur prend en charge votre carte et votre système. Une grande quantité de mémoire ne compense pas une incompatibilité.
- Gardez une marge pour le contexte et les autres applications. Charger aussi un modèle d’image, par exemple dans ComfyUI, ajoute une autre demande de mémoire.
- La RAM système peut accueillir une partie du calcul avec certains moteurs. Ce partage CPU/GPU peut aider à charger le modèle, mais aussi ralentir les réponses.
- Un SSD facilite le chargement et le stockage des modèles. Prévoyez l’espace de plusieurs variantes ; un SSD NVMe n’est pas une condition universelle pour commencer.
Pour les cartes et les repères de mémoire, retrouvez le guide IA locale sur GPU. Avant un achat, essayez une petite tâche avec votre machine actuelle : vous saurez mieux ce qui vous manque.
Windows ou Linux pour l’IA locale ?
Pour un premier essai, gardez le système que vous connaissez. Ollama et LM Studio proposent des versions pour Windows, macOS et Linux, avec des exigences matérielles à vérifier. Il n’est pas nécessaire de monter un serveur avant de tester un modèle.
Linux peut devenir intéressant pour une installation de serveur ou certains moteurs. La documentation de vLLM indique que Windows n’est pas pris en charge nativement ; WSL est une possibilité. Elle décrit aussi plusieurs familles de GPU, pas uniquement NVIDIA. Avant de passer à Linux et vLLM pour servir plusieurs utilisateurs, mesurez la charge réelle.
Choisir un modèle : capacité d’outil, taille et quantification
Pour un agent, cherchez une référence dont la prise en charge des appels d’outils est documentée. Deux modèles de la même famille peuvent avoir des comportements différents. Vérifiez le nom exact, la version, la licence, le format et les capacités indiquées dans la fiche.
La quantification représente les poids avec moins de précision pour réduire leur place en mémoire. Son effet sur la qualité dépend du modèle, de la méthode et de la tâche. Le format GGUF, lui, est un conteneur : il peut accueillir des poids de haute précision ou quantifiés. La documentation de llama.cpp décrit justement la quantification d’un fichier GGUF de départ en F32 ou BF16.
Dans le parcours pratique, qwen3:4b sert de petit modèle d’essai. Sa fiche Ollama signale la prise en charge des outils, environ 4 milliards de paramètres et une variante Q4_K_M de 2,5 GB à télécharger. Ce volume n’est pas une promesse de consommation mémoire totale. Ce choix documenté n’est ni un classement des modèles ni une recommandation d’achat.
Contexte long et modèles MoE : éviter les raccourcis
Un agent accumule des consignes, des messages et des résultats d’outils. Le contexte peut donc grossir rapidement, surtout si les outils renvoient des pages entières ou de longs fichiers. Augmenter sa limite consomme davantage de ressources et ne garantit pas que chaque information sera bien utilisée.
Un modèle MoE, à mélange d’experts, n’active qu’une partie de ses paramètres pour chaque token. Le nombre de paramètres actifs ne suffit pourtant pas à prévoir la mémoire nécessaire : il faut regarder l’ensemble des poids et la manière dont le moteur les charge. Sans modèle précis ni mesures, « petit modèle à très long contexte » contre « grand MoE » n’a pas de vainqueur universel.
Les proportions de cette illustration ne sont pas des mesures. L’idée utile est simple : le modèle, le contexte et le moteur partagent un budget mémoire. Limitez d’abord ce que les outils renvoient, puis augmentez le contexte si la tâche le demande.
Ollama, LM Studio, llama.cpp ou vLLM ?
Quatre moteurs, des usages différents
Ollama
Un point de départ pratique pour télécharger un modèle et l’appeler depuis un terminal ou une API locale. Vérifiez le modèle choisi : le logiciel propose aussi des fonctions cloud.
LM Studio
Une interface graphique pour chercher, charger et essayer des modèles, avec un serveur local. L’application est propriétaire ; ses composants et les modèles ont leurs propres licences.
llama.cpp
Des outils pour exécuter des modèles GGUF et régler la répartition CPU/GPU. Utile quand vous voulez comprendre et ajuster plus finement l’exécution.
vLLM
Un moteur à examiner pour le service de modèles et les requêtes concurrentes. Sa configuration et ses exigences matérielles demandent davantage de préparation.
LM Studio annonce un usage gratuit à la maison et au travail. Ses conditions encadrent l’usage personnel et professionnel interne et prévoient aussi des fonctionnalités payantes. Ne confondez pas gratuité de l’application, offre d’équipe et autorisation commerciale des modèles téléchargés.
Les interfaces compatibles OpenAI facilitent le raccordement à des applications existantes, mais elles ne rendent pas tous les moteurs interchangeables. Ollama parle d’un sous-ensemble de l’API OpenAI, accessible localement à http://localhost:11434/v1/. Les endpoints, les paramètres et le support des outils doivent être contrôlés pour votre configuration.
Open WebUI se situe encore à un autre niveau : c’est une interface que l’on peut relier à un moteur. Ajouter une interface n’augmente pas à lui seul la mémoire disponible ni la capacité du modèle à utiliser des outils.
Frameworks et MCP : utiles, mais pas obligatoires pour démarrer
Un framework fournit des éléments pour organiser les messages, les outils et les étapes. CrewAI et LangChain ont des intégrations documentées avec Ollama. Pour LangChain, le paquet langchain-ollama fournit ChatOllama ; CrewAI documente la connexion locale avec sa classe LLM et l’intégration LiteLLM. Configurez explicitement le modèle et l’adresse locale au lieu de compter sur les valeurs par défaut.
MCP, le Model Context Protocol, est un standard de connexion entre une application IA et des outils ou sources de données. Un serveur MCP peut être local ou distant. Il ne remplace ni le moteur d’inférence, ni les permissions, ni la boucle de l’agent. Le function calling désigne, lui, la production d’une demande d’appel de fonction structurée par le modèle.
Pour voir ce qui se passe réellement, le premier exercice suivant utilise directement l’API native d’Ollama avec la bibliothèque standard de Python. Aucun framework ni serveur MCP n’est nécessaire pour cet exercice.
Premier essai : un modèle, un dossier de test, un outil
1. Installer Ollama et tester le modèle seul
Installez Ollama depuis son site officiel et démarrez-le. Dans un terminal, téléchargez puis lancez la référence choisie :
ollama pull qwen3:4b
ollama run qwen3:4bDemandez une réponse courte en français. Si le modèle ne charge pas ou répond trop lentement, réglez ce problème avant d’ajouter des outils. Cette conversation teste le modèle, pas encore un agent. Quittez ensuite la conversation avec /bye ; gardez le service Ollama démarré. Si aucun service n’est actif, la commande ollama serve permet de le lancer.
2. Préparer un dossier sans données sensibles
Installez Python si vous ne l’avez pas. Créez un dossier pour cet exercice, puis un sous-dossier nommé dossier-test. Placez-y deux ou trois fichiers de démonstration aux noms reconnaissables. Aucun document client, mot de passe ou fichier personnel n’est nécessaire.
Enregistrez le code suivant en UTF-8 sous le nom premier_agent_local.py, dans le dossier de l’exercice, à côté de dossier-test. L’outil retourne uniquement les noms des fichiers de ce sous-dossier ; il ne lit pas leur contenu et ne parcourt pas les sous-dossiers. Le modèle ne reçoit pas de paramètre pour choisir un autre chemin.
Afficher le code complet du premier agent local
"""Exemple pédagogique : un seul outil, aucun accès en écriture.
Requiert Ollama déjà démarré et le modèle qwen3:4b téléchargé.
"""
import json
from pathlib import Path
from urllib.request import Request, build_opener, ProxyHandler
MODELE = "qwen3:4b"
URL = "http://127.0.0.1:11434/api/chat"
DOSSIER = Path(__file__).resolve().parent / "dossier-test"
OUTIL = {
"type": "function",
"function": {
"name": "lister_fichiers",
"description": "Liste les noms de fichiers du seul dossier de test autorisé. Ne lit pas leur contenu.",
"parameters": {"type": "object", "properties": {}, "required": []},
},
}
def lister_fichiers():
if not DOSSIER.is_dir() or DOSSIER.is_symlink():
raise ValueError("Créez un vrai dossier dossier-test à côté du script.")
return sorted(p.name for p in DOSSIER.iterdir() if p.is_file() and not p.is_symlink())[:100]
def demander(messages):
donnees = json.dumps({
"model": MODELE,
"messages": messages,
"tools": [OUTIL],
"stream": False,
"think": False,
"options": {"num_ctx": 4096, "num_predict": 512, "temperature": 0},
}).encode("utf-8")
requete = Request(URL, data=donnees, headers={"Content-Type": "application/json"})
# Pas de proxy pour cette requête destinée à la boucle locale.
with build_opener(ProxyHandler({})).open(requete, timeout=120) as reponse:
return json.load(reponse)["message"]
def main():
messages = [{"role": "user", "content": (
"Utilise lister_fichiers pour connaître les noms de fichiers du dossier de test. "
"Rapporte uniquement les noms obtenus. Si tu ne peux pas appeler l’outil, dis-le."
)}]
outil_appele = False
for _ in range(3):
message = demander(messages)
messages.append(message)
appels = message.get("tool_calls", [])
if not appels:
if not outil_appele:
raise RuntimeError("Aucun outil appelé : la réponse ne prouve pas un accès au dossier.")
print(message.get("content", ""))
return
if len(appels) > 1:
raise RuntimeError("Cet exercice autorise un seul appel d’outil par étape.")
fonction = appels[0].get("function", {})
if fonction.get("name") != "lister_fichiers" or fonction.get("arguments", {}) != {}:
raise ValueError("Outil ou arguments non autorisés.")
resultat = lister_fichiers()
outil_appele = True
print("Résultat réel de l’outil :", resultat)
messages.append({"role": "tool", "tool_name": "lister_fichiers", "content": json.dumps(resultat, ensure_ascii=False)})
raise RuntimeError("Limite de trois appels au modèle atteinte.")
if __name__ == "__main__":
main()
3. Lancer et regarder les appels réels
python premier_agent_local.pySur un système où l’exécutable se nomme python3, utilisez python3 à la place de python. Le script n’a pas de dépendance Python supplémentaire. Il contacte le service local à l’adresse 127.0.0.1 et limite la boucle à trois appels au modèle.
Regardez la ligne « Résultat réel de l’outil » et comparez les noms à votre dossier. La réponse finale du modèle doit correspondre à ce résultat. Si le modèle répond sans appeler l’outil, le script s’arrête explicitement : une phrase assurée ne vaut pas une lecture.
Le réglage de contexte à 4 096 et la limite de génération sont propres à ce petit exercice. Ce ne sont pas des valeurs universelles. Si le modèle répète l’appel, demande un outil inconnu ou produit des arguments inattendus, l’exemple s’interrompt plutôt que d’exécuter une commande improvisée.
Ce qui a été vérifié pour cet exemple
Le comportement peut varier selon votre version d’Ollama et votre matériel : lancez d’abord le script sur une tâche simple avant de lui confier un vrai travail.
Les erreurs de débutant à surveiller
- Le modèle ne tient pas en mémoire : essayez une référence plus petite, réduisez le contexte ou examinez la répartition CPU/GPU disponible.
- Le modèle répond sans appeler l’outil : contrôlez sa prise en charge du function calling et la description de l’outil. Ne prenez pas la réponse pour une preuve d’exécution.
- Les arguments sont mal formés : refusez l’appel au lieu de lancer une action approximative. Simplifiez la fonction et vérifiez sa définition.
- L’historique grossit trop vite : faites retourner moins de données par les outils et gardez seulement les informations nécessaires à la tâche.
- La boucle se répète : fixez un nombre maximal d’étapes, une durée limite et une condition d’arrêt visible.
- Le modèle local appelle quand même un service distant : vérifiez le modèle sélectionné, les outils, les connecteurs et les services de traçage activés.
Sécurité et passage à un usage régulier
Commencez avec des copies et un compte qui n’a que les droits nécessaires. Un outil capable d’exécuter du code, d’écrire ou de supprimer n’a pas le même risque qu’un outil qui liste des noms. Exigez une validation humaine pour les actions sensibles et conservez un moyen de revenir en arrière.
Un conteneur Docker peut aider à isoler le programme, mais il faut encore limiter les dossiers montés, les droits et le réseau. Un conteneur avec accès à tous vos fichiers ou au contrôle de la machine n’offre pas la séparation attendue. Évitez aussi d’exposer directement le serveur de modèles sur Internet.
Traitez les documents et les résultats d’outils comme des données à analyser, pas comme des instructions qui pourraient élargir les permissions de l’agent. Gardez les journaux utiles, sans y accumuler inutilement des données sensibles.
Pour plusieurs utilisateurs, mesurez les attentes, la mémoire et la fiabilité avant de changer de moteur. vLLM est une option possible, pas un passage obligé. Une chaîne de petites étapes contrôlées sera souvent plus facile à comprendre qu’un agent auquel vous confiez tout d’un coup.
Questions fréquentes sur les agents IA locaux
Un agent local fonctionne-t-il sans Internet ?
Puis-je utiliser LM Studio dans mon travail sans payer ?
Faut-il savoir programmer pour débuter ?
GGUF signifie-t-il que le modèle est quantifié ?
Une grosse carte graphique est-elle indispensable ?
Pourquoi le premier exercice ne lit-il que des noms de fichiers ?
Sources et documentation
Documentation consultée le 5 novembre 2026. Ce guide distingue les capacités documentées des essais de modèle qui n’ont pas été réalisés pour cet article. Les adresses des sources sont indiquées en texte, sans liens externes cliquables.
- Ollama, « Tool calling » : docs.ollama.com/capabilities/tool-calling. Structure des outils, messages et retour de résultat.
- Ollama, fiche « qwen3:4b » : ollama.com/library/qwen3:4b. Référence, quantification, volume du téléchargement et capacité d’outils.
- Ollama, « OpenAI compatibility » : docs.ollama.com/api/openai-compatibility. Compatibilité partielle et adresses locales ou cloud.
- llama.cpp, documentation de quantize : dépôt ggml-org/llama.cpp, tools/quantize/README.md, sur github.com. GGUF de haute précision et quantification.
- LM Studio, « Offline Operation » : lmstudio.ai/docs/app/offline. Fonctions locales et opérations réseau.
- LM Studio, « Free for use at work » et conditions de l’application : lmstudio.ai/blog/free-for-work et lmstudio.ai/terms, version des conditions datée du 23 août 2026.
- vLLM, « GPU » : docs.vllm.ai/en/latest/getting_started/installation/gpu/. Systèmes et matériels pris en charge.
- LangChain, « ChatOllama integration » : docs.langchain.com/oss/python/integrations/chat/ollama. Intégration locale et traçage facultatif.
- CrewAI, « Connect to any LLM » : docs.crewai.com/en/learn/llm-connections. Connexion Ollama, configuration explicite et LiteLLM.
- Model Context Protocol, introduction : modelcontextprotocol.io/docs/getting-started/intro. Rôle du protocole et connexions aux systèmes externes.
Continuer avec votre matériel et vos usages
Retrouvez les guides locaux, les repères matériels et les cas de création sur votre ordinateur.