Du modèle qui répond au modèle qui agit

Du modèle qui répond au modèle qui agit

Jusqu'ici, tous les chapitres décrivaient un LLM dans un rôle passif : il reçoit un prompt, il génère une réponse, c'est fini. Le modèle ne fait rien dans le monde — il produit du texte.

Mais quelque chose a changé. Les LLMs peuvent maintenant appeler des outils : rechercher sur le web, exécuter du code, lire un fichier, envoyer un email. Et avec cette capacité, une architecture complètement différente devient possible.

La limite du modèle sans outils

Pose la question à un LLM sans accès à internet : "Quel est le cours de l'action Apple en ce moment ?"

Il inventera quelque chose de plausible. Ou il dira qu'il ne sait pas. Dans les deux cas, il ne peut pas répondre correctement, parce que l'information n'est pas dans ses paramètres.

Donne-lui un outil — une API de cotations en temps réel — et la réponse devient triviale. Le modèle n'a pas besoin d'apprendre cette information pendant l'entraînement. Il l'obtient au moment où il en a besoin.

La boucle ReAct

L'architecture de référence pour les agents s'appelle ReAct (Reasoning + Acting). Elle fonctionne en trois phases cycliques :

Think (Réfléchir) — Le modèle analyse la situation. Il écrit sa chaîne de raisonnement : "Pour répondre à cette question, j'ai besoin de X. Je vais appeler l'outil Y avec ces paramètres."

Act (Agir) — Le modèle génère un appel d'outil structuré : le nom de l'outil et ses paramètres. Le système exécute l'appel et récupère le résultat.

Observe (Observer) — Le résultat de l'outil est injecté dans le contexte. Le modèle voit ce qui s'est passé et décide quoi faire ensuite.

Puis on recommence. Jusqu'à ce que le modèle estime avoir assez d'informations pour répondre.

Avance pas à pas

Voici trois tâches : une simple (calcul), une qui nécessite une API, une qui enchaîne plusieurs outils. Avance étape par étape pour voir le raisonnement du modèle et comment le contexte s'accumule à chaque tour.

Observe la boucle : le modèle pense, choisit un outil, lit son résultat, recommence. Chaque cycle est une nouvelle prédiction de token — l'« agent » émerge d'un LLM qu'on a appris à appeler des fonctions, pas d'une nouvelle architecture.

Comment les outils sont définis

Un outil n'est pas un bout de code que le modèle "comprend magiquement". C'est une définition structurée — nom, description, paramètres — que le modèle voit dans son contexte :

{
  "name": "web_search",
  "description": "Recherche des informations récentes sur le web.",
  "parameters": {
    "query": "string — la requête de recherche"
  }
}

Le modèle a appris pendant son entraînement à produire des appels d'outils dans ce format. Quand il "choisit d'utiliser un outil", il génère simplement du texte qui ressemble à un appel d'API.

C'est le système qui détecte ce texte, exécute l'appel réel, et renvoie le résultat dans le contexte.

Le contexte qui grandit

Chaque itération de la boucle ajoute des tokens au contexte : la réflexion, l'appel d'outil, le résultat. Une tâche complexe qui demande cinq itérations peut facilement consommer plusieurs milliers de tokens.

C'est pourquoi les agents ont tendance à être plus lents et plus coûteux que les simples échanges question-réponse. Et c'est pourquoi la gestion du contexte — savoir quoi garder, quoi résumer, quoi jeter — est un problème ouvert dans la conception des systèmes agentiques.

Tool use vs fine-tuning

Une question naturelle : pourquoi apprendre au modèle à utiliser des outils plutôt que de lui apprendre directement les informations ?

Plusieurs raisons :

Les données changent. Un cours de bourse, la météo, l'état d'une base de données — ces informations changent en permanence. Aucun entraînement ne peut les capturer.

La précision. Un calcul, une requête SQL, une conversion d'unités — les outils sont déterministes et exacts. Les LLMs ne le sont pas.

La modularité. Donner un nouvel outil à un modèle prend quelques lignes. Réentraîner un modèle pour intégrer une nouvelle compétence prend des semaines et des millions de dollars.

Le planning et la décomposition de tâches

Les agents les plus capables ne se contentent pas d'une boucle linéaire. Ils décomposent une tâche complexe en sous-tâches, exécutent certaines en parallèle, et combinent les résultats.

Par exemple, "rédige un rapport comparatif sur trois concurrents" peut se décomposer en : rechercher les informations de chaque concurrent (trois appels en parallèle), puis synthétiser les résultats.

C'est encore un domaine de recherche active. Les LLMs actuels font un planning raisonnable sur des tâches courtes, mais dérivent facilement sur des tâches longues et complexes.

Les risques des agents

Avec la capacité d'agir vient la capacité de faire des dégâts.

Les actions irréversibles. Un agent qui a accès à ta boîte mail peut envoyer un email. Pas d'annulation possible. Les bonnes architectures agentiques distinguent les actions de lecture (inoffensives) des actions d'écriture (à confirmer).

Les boucles infinies. Sans garde-fou, un agent peut se retrouver bloqué dans une boucle : il cherche une information, ne la trouve pas, reformule, cherche à nouveau… indéfiniment.

Le reward hacking. Si l'objectif est mal spécifié, un agent peut trouver des raccourcis inattendus pour maximiser son score — sans faire ce qu'on voulait vraiment.

Les hallucinations sur les outils. Le modèle peut inventer des appels à des outils qui n'existent pas, ou avec des paramètres incorrects.

MCP : vers un standard pour les outils

Au début, chaque éditeur définissait son propre format de tool use : OpenAI avait function calling, Anthropic avait son protocole interne, chaque framework agentique réinventait la roue. Le résultat : incompatibilités, intégrations refaites pour chaque modèle, écosystème fragmenté.

En novembre 2024, Anthropic publie le Model Context Protocol (MCP) : un standard ouvert pour décrire des outils, des ressources et des prompts d'une manière indépendante du modèle. Un serveur MCP expose un ensemble d'outils (par exemple "lire ce fichier", "interroger cette base de données"). N'importe quel client compatible MCP — Claude Desktop, Cursor, des extensions VSCode, des frameworks agentiques — peut s'y connecter.

L'analogie qui revient souvent : MCP est aux LLMs ce que USB-C est aux périphériques. Une prise commune.

L'adoption a été rapide : OpenAI, Microsoft, et la plupart des éditeurs majeurs ont annoncé en 2025 leur compatibilité MCP. C'est devenu de facto le protocole standard pour le tool use.

Code interpreter, sandboxes, computer use

Quelques classes d'outils particulièrement importantes :

Code interpreter. Un sandbox Python (parfois JavaScript) où le modèle peut exécuter du code arbitraire. Calculs précis, manipulations de données, génération de graphiques — tout ce que les LLMs font mal nativement, ils peuvent le déléguer à Python. Disponible chez OpenAI, Claude, Google.

Browser / web automation. Un outil qui rend le modèle capable de cliquer, scroller, remplir des formulaires sur des pages web. Anthropic appelle ça computer use, OpenAI propose Operator. Encore fragile, mais l'évolution est rapide.

File system & shell. Un outil qui donne accès à un disque virtuel, à un terminal. Cœur des "coding agents" comme Cursor, Cline, Aider, Claude Code.

Mémoire long-terme

Le contexte d'un agent grandit, mais reste borné. Comment un assistant te reconnaît-il à la conversation suivante ? Avec une mémoire long-terme externe.

Plusieurs approches :

• Mémoire vectorielle — chaque interaction importante est résumée et stockée comme embedding. À chaque nouvelle conversation, on récupère les souvenirs pertinents (RAG, version mémoire).
• Profil utilisateur structuré — l'agent met à jour un dossier sur l'utilisateur (préférences, projets en cours, historique).
• Mémoire procédurale — l'agent garde la trace des recettes qui ont marché ("pour résumer un papier, suis ces étapes").

ChatGPT a introduit une mémoire en 2024, Claude en 2025. C'est un des chantiers les plus actifs de la conception agentique.

Multi-agent : plusieurs LLMs qui collaborent

Une tendance récente : au lieu d'un seul agent, faire collaborer plusieurs LLMs spécialisés.

Un agent orchestrateur reçoit la tâche, la décompose et délègue à des agents spécialisés (un expert en code, un expert en recherche web, un vérificateur). Les résultats remontent à l'orchestrateur, qui les combine.

Cette architecture ressemble à une organisation humaine — et elle a les mêmes avantages (parallélisation, spécialisation) et les mêmes problèmes (communication, coordination, perte d'information entre agents).

Ce que ça change

Le LLM n'est plus un oracle qu'on interroge — c'est un cerveau qu'on connecte à des bras.

Cette transition est encore récente. Les agents actuels sont impressionnants sur des tâches bien délimitées et fragiles sur des tâches longues et ambiguës. Mais l'évolution est rapide, et comprendre l'architecture fondamentale — ReAct, tool use, contexte qui grandit — est le meilleur point de départ.

Mis à jour le 10 mai 2026