Agents, utilisation d’outils et orchestration

De la réponse à l’action

Les systèmes des sections précédentes produisent du texte. Beaucoup de systèmes utiles doivent aussi agir : consulter une commande, chercher dans une base de connaissances, émettre un remboursement, réserver une table, lancer une suite de tests. L’appel d’outils (tool calling), souvent appelé function calling, en est le mécanisme. L’application décrit les outils disponibles, chacun avec un nom, une description et un JSON Schema pour ses paramètres. Au lieu de répondre en prose, le modèle peut renvoyer une demande structurée d’appel d’un ou plusieurs de ces outils avec des arguments précis. C’est l’application, et non le modèle, qui décide d’exécuter ou non l’appel, l’exécute et renvoie le résultat au modèle, qui poursuit alors. Le modèle ne touche jamais lui-même une base de données ou une API ; chaque effet dans le monde passe par du code que vous avez écrit.

Un agent est un système dans lequel le modèle choisit ses actions de manière répétée : il appelle un outil, lit le résultat, décide de la suite et continue jusqu’à ce que l’objectif soit atteint ou qu’une limite l’arrête. L’autonomie est un continuum. À une extrémité, du code appelle le modèle une fois pour remplir un formulaire ; à l’autre, un modèle planifie et exécute une longue tâche avec des dizaines d’appels d’outils et peu de supervision. Sur le plan architectural, le point important est que chaque pas vers l’autonomie fait passer des décisions d’un code déterministe et vérifiable à un composant probabiliste, ce qui augmente la flexibilité et diminue la prévisibilité, la testabilité et le contrôle. Ce compromis doit être fait délibérément, aussi tard et aussi peu que le problème l’exige.

{
  "name": "get_order_status",
  "description": "Look up the current status of one order placed by the signed-in customer. Use when the customer asks where an order is. Returns status, estimated arrival and courier position. Changes nothing.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "pattern": "^ORD-[0-9]{6}$",
        "description": "Order number, for example ORD-104233"
      }
    },
    "required": ["order_id"],
    "additionalProperties": false
  }
}

La boucle de l’agent : raisonner, agir, observer

La boucle qui sous-tend presque tous les agents a été décrite par Shunyu Yao et ses collègues dans ReAct: Synergizing Reasoning and Acting in Language Models (2022). ReAct entrelace le raisonnement (le modèle écrit ce qu’il cherche à faire), les actions (il appelle un outil) et les observations (le résultat de l’outil est ajouté à son contexte), de sorte que chaque étape s’appuie sur ce que la précédente a trouvé. Avant ReAct, les modèles soit raisonnaient sans accès aux faits, et hallucinaient, soit agissaient sans raisonner, et erraient. Les interfaces d’appel d’outils et les modèles de raisonnement actuels intègrent cette boucle, mais c’est toujours autour de sa structure qu’il faut concevoir.

En code, la boucle est courte. Construire le contexte (instructions, objectif, historique, définitions d’outils, résultats obtenus jusque-là) ; appeler le modèle ; s’il renvoie une réponse finale, s’arrêter ; s’il renvoie des appels d’outils, valider chacun par rapport à son schéma et aux règles métier, vérifier que l’utilisateur y a droit, l’exécuter avec un délai d’expiration (timeout), ajouter le résultat (ou un message d’erreur clair) au contexte, vérifier les limites et recommencer. Le diagramme ci-dessous montre où le code déterministe entoure le modèle. Tout ce qui se trouve hors du bloc du modèle est un logiciel ordinaire qui peut être testé, revu et appliqué ; c’est de là que viennent la fiabilité et la sûreté d’un agent.

Workflows et agents

Dans Building effective agents (décembre 2024), Erik Schluntz et Barry Zhang, d’Anthropic, ont établi une distinction devenue depuis du vocabulaire courant. Les workflows orchestrent les modèles et les outils selon des chemins de code prédéfinis ; les agents laissent le modèle diriger son propre processus et son utilisation des outils. Ils ont décrit un petit ensemble de patrons de workflow, tous construits à partir d’un LLM augmenté (un modèle doté de récupération, d’outils et de mémoire), et ont conseillé de commencer par la conception la plus simple qui fonctionne, souvent un seul appel bien formulé avec récupération, et de n’ajouter un comportement agentique que lorsqu’il améliore les résultats de façon démontrable.

Ce conseil rejoint la position générale de ce cours sur la simplicité. Un workflow a une forme connue : son coût, sa latence et ses modes de défaillance peuvent être prévus et ses étapes testées une à une. Un agent peut traiter des tâches ouvertes dont les étapes ne peuvent pas être connues à l’avance, comme enquêter sur un bug inconnu ou étudier une question à travers de nombreuses sources, au prix d’un coût variable, de tests plus difficiles et de davantage de façons de mal tourner. Beaucoup de systèmes présentés comme des agents seraient meilleurs sous forme de workflows, et beaucoup de bons agents contiennent des workflows.

Concevoir des outils pour les modèles

Les outils sont une interface dont l’utilisateur est un modèle, et ils méritent le soin accordé à toute API. Schluntz et Zhang parlent d’interface agent-ordinateur. Donnez à chaque outil un objectif clair, ainsi qu’un nom et une description qui disent quand l’utiliser, quand ne pas l’utiliser et ce qu’il renvoie ; les modèles choisissent les outils surtout d’après leur description. Gardez des paramètres peu nombreux et typés, utilisez des énumérations plutôt que du texte libre et rejetez les champs inconnus. Rendez les erreurs difficiles à commettre, par exemple en exigeant des identifiants absolus plutôt que des positions dans une liste. Renvoyez des résultats concis et pertinents, car chaque token d’un résultat d’outil est payé et occupe la fenêtre de contexte ; paginez et résumez les résultats volumineux. Renvoyez des erreurs sur lesquelles le modèle peut agir (commande introuvable ; demandez au client de vérifier le numéro) plutôt que des traces de pile.

Séparez la lecture de l’écriture. Les outils de lecture peuvent généralement s’exécuter librement ; les outils d’écriture modifient le monde et exigent validation, autorisation, idempotence et parfois approbation. Gardez petit le nombre d’outils disponibles à un instant donné, car de grands ensembles d’outils embrouillent les modèles et élargissent la surface d’attaque ; routez vers un sous-ensemble, ou chargez les définitions d’outils à la demande. Demandez une sortie structurée chaque fois que du code consommera le résultat : beaucoup d’API peuvent contraindre la génération à un JSON Schema, ce qui élimine les échecs d’analyse mais pas les valeurs erronées ; la validation du contenu reste donc nécessaire.

Le Model Context Protocol

Sans cela, chaque assistant qui veut atteindre chaque source de données ou chaque outil aurait besoin d’une intégration sur mesure pour chaque paire : N applications fois M systèmes. Le Model Context Protocol (MCP), présenté par Anthropic comme un standard ouvert en novembre 2024, remplace cela par un seul protocole, comme le Language Server Protocol l’a fait pour les éditeurs de code. Une application hôte (un assistant conversationnel, un IDE, un agent) exécute un client MCP par connexion à un serveur MCP. Les serveurs exposent des outils (des fonctions que le modèle peut appeler), des ressources (des données que l’application peut charger dans le contexte) et des prompts (des modèles réutilisables). Les messages utilisent JSON-RPC 2.0, via l’entrée et la sortie standard pour les serveurs locaux ou via HTTP pour les serveurs distants, et les serveurs distants utilisent une autorisation fondée sur OAuth.

L’adoption a été rapide. En décembre 2025, Anthropic faisait état de plus de 10 000 serveurs MCP publics actifs et d’une prise en charge dans des produits comme ChatGPT, Cursor, Gemini, Microsoft Copilot et Visual Studio Code. Le 9 décembre 2025, Anthropic a fait don de MCP à l’Agentic AI Foundation, nouvellement créée, un fonds dédié au sein de la Linux Foundation cofondé par Anthropic, Block et OpenAI : le protocole est donc désormais gouverné dans un cadre neutre vis-à-vis des fournisseurs. La spécification est versionnée par date. La révision 2026-07-28 a rendu le protocole de base sans état, afin que les serveurs distants puissent fonctionner derrière des équilibreurs de charge ordinaires sans sessions persistantes ; elle a ajouté la prise en charge d’extensions facultatives et sorti les tâches de longue durée du cœur pour les placer dans une extension officielle ; elle a renforcé l’autorisation ; et elle a déprécié d’anciennes fonctionnalités (roots, sampling et logging) avec une période de transition d’au moins un an. Pour la communication entre agents indépendants, plutôt qu’entre une application et ses outils, Google a présenté le protocole Agent2Agent (A2A) en avril 2025 ; il a été confié à la Linux Foundation en juin 2025 et, en août 2026, ses promoteurs ont annoncé qu’il rejoindrait lui aussi l’Agentic AI Foundation.

Sur le plan architectural, un serveur MCP est une dépendance qui peut lire vos données et agir en votre nom : traitez-le comme tel. Approuvez et épinglez les serveurs autorisés, dans le cadre de la sécurité de la chaîne d’approvisionnement ; préférez les serveurs exploités par vous ou par un fournisseur de confiance ; donnez aux identifiants de chaque serveur le moindre privilège dont ses outils ont besoin ; souvenez-vous que les descriptions et les résultats des outils entrent dans le contexte du modèle et peuvent transporter des instructions injectées ; et faites passer le trafic MCP distant par la même passerelle et les mêmes contrôles de journalisation et de politique que le reste du trafic vers les modèles. Le protocole normalise la tuyauterie ; il ne décide pas de ce qu’un agent devrait être autorisé à faire.

Mémoire et état

Les modèles sont sans état : la mémoire d’un agent est donc tout ce que le système environnant stocke et replace dans le contexte. La mémoire à court terme est la conversation et les résultats des appels d’outils effectués jusque-là. Elle grandit à chaque étape, ce qui augmente le coût et la latence et finit par dépasser la fenêtre ; les agents de longue durée la gèrent donc : ils suppriment ou raccourcissent les anciens résultats d’outils, résument les tours précédents (compaction) et tiennent un plan courant ou un fichier de notes que le modèle met à jour. La mémoire à long terme est l’information conservée d’une session à l’autre, comme les préférences alimentaires d’un client ou des faits qu’un assistant a appris sur un projet, stockée dans une base de données et récupérée quand elle est pertinente, ce qui en fait un petit système RAG, avec les mêmes questions de pertinence, de fraîcheur et de contrôle d’accès.

L’état d’exécution est ce qui compte le plus pour la fiabilité. Si un agent est à mi-chemin d’une tâche de vingt étapes quand son processus redémarre, il doit reprendre, et non recommencer en répétant des effets de bord. Persistez l’état après chaque étape (le contexte, le plan, les appels d’outils terminés et leurs résultats) sous forme de point de reprise, ou exécutez l’agent sur un moteur d’exécution durable qui s’en charge pour vous, comme on exécute les processus métier de longue durée et les sagas. La mémoire est aussi une donnée à caractère personnel : décidez de ce qui est mémorisé, pour combien de temps, si les utilisateurs peuvent le consulter et le supprimer, et tenez la mémoire d’un client hors du contexte d’un autre (voir protection de la vie privée dès la conception).

Systèmes multi-agents

Un système multi-agents répartit le travail entre plusieurs agents pilotés par des modèles, en général un agent principal qui planifie et délègue à des sous-agents, chacun avec ses propres instructions, ses outils et sa fenêtre de contexte, et dont l’agent principal combine les résultats. Les avantages sont le parallélisme, la spécialisation et, surtout, la séparation des contextes : chaque sous-agent peut explorer une grande quantité de matériau et ne renvoyer qu’un court résumé. Anthropic a indiqué en juin 2025 que son système de recherche multi-agents surpassait nettement un agent unique dans son évaluation de recherche interne, mais aussi que de tels systèmes consommaient environ 15 fois plus de tokens que des conversations ordinaires, et qu’ils convenaient mieux à des tâches larges et parallélisables qu’à des tâches fortement couplées comme la plupart des tâches de programmation.

Les praticiens ne s’accordent pas sur le degré à atteindre. Le même mois, Walden Yan, de Cognition, soutenait dans Don’t Build Multi-Agents que des sous-agents travaillant à partir d’un contexte partiel font des hypothèses contradictoires, et recommandait par défaut un agent à fil unique avec une gestion soignée du contexte. Les deux positions s’accordent sur la cause profonde : la coordination entre agents est une communication avec pertes entre des composants qui ne partagent pas d’état. C’est le problème central des systèmes distribués, et les mêmes conseils s’appliquent. Ne distribuez pas sans raison ; gardez des interfaces explicites et étroites entre les agents ; préférez des sous-tâches indépendantes ; tracez chaque saut ; et attendez-vous à ce que le coût, la latence et les modes de défaillance se multiplient avec le nombre d’agents.

Ingénierie de la fiabilité des agents

Les agents échouent de façons nouvelles : ils tournent en boucle, appelant le même outil avec les mêmes arguments ; ils s’égarent, poursuivant une question secondaire jusqu’à épuisement du budget ; ils abandonnent trop tôt ou revendiquent un succès qu’ils n’ont pas obtenu ; et ils entreprennent des actions que leurs concepteurs n’avaient pas prévues. Les remèdes sont les patrons du chapitre 9 et du chapitre 6, appliqués à chaque étape plutôt qu’une fois par requête, plus une règle ferme : les effets de bord lourds de conséquences exigent davantage que l’avis du modèle. La section 12.6 traite en profondeur le versant sécurité, l’autonomie excessive ; la liste de contrôle ci-dessous couvre la fiabilité.