Agents IA et MCP : le guide complet pour comprendre et automatiser

Un agent IA ne se contente pas de répondre. Il peut rechercher une information, choisir un outil, agir dans un logiciel, vérifier le résultat et recommencer jusqu’à atteindre un objectif. Cette capacité ouvre des automatisations puissantes, mais elle augmente aussi le coût, l’incertitude et le risque. Ce guide explique comment distinguer un véritable agent d’un simple chatbot, à quoi servent le function calling, MCP et A2A, puis comment construire une première architecture utile, observable et contrôlable.

Sommaire

1. Qu’est-ce qu’un agent IA ?
2. Chatbot, workflow, copilote ou agent
3. La boucle agentique, étape par étape
4. Modèle, outils, RAG, mémoire et état
5. Comprendre le function calling
6. MCP : un standard pour connecter les outils
7. A2A : faire collaborer des agents
8. Une architecture minimale de production
9. Sécurité, permissions et approbations
10. Évaluer un agent sans se tromper de métrique
11. Cas d’usage pertinents
12. Plan de déploiement en quatre étapes
13. Checklist avant mise en production
14. FAQ sur les agents IA et MCP
15. Sources officielles

Qu’est-ce qu’un agent IA ?

Un agent IA est une application dans laquelle un modèle peut orienter une partie du processus nécessaire pour accomplir une tâche. Il reçoit un objectif, dispose d’un contexte et d’outils, observe les effets de ses actions et décide de la suite. Le mot important n’est pas « intelligence », mais contrôle de la prochaine étape.

Anthropic distingue utilement les workflows, dont les chemins sont définis par le code, et les agents, dont le modèle dirige dynamiquement le processus et l’usage des outils. Cette définition évite d’appeler « agent » n’importe quelle interface conversationnelle. Elle rappelle aussi qu’il existe un continuum : une application peut contenir un workflow déterministe, puis déléguer seulement une sous-tâche ambiguë à une boucle agentique.

La définition doit rester opérationnelle. Pour qualifier un système, posez quatre questions : peut-il décider de la prochaine action, peut-il agir sur un environnement, reçoit-il une observation exploitable et dispose-t-il d’une condition d’arrêt ? Si l’une de ces briques manque, vous avez probablement un assistant textuel ou un workflow augmenté, ce qui peut être exactement la bonne solution.

Si vous souhaitez d’abord consolider les notions de modèle, entraînement, inférence et génération, le guide Intelligence artificielle générative : le guide complet constitue le point de départ du parcours.

Chatbot, workflow, copilote ou agent : les vraies différences

Type de système	Qui décide des étapes ?	Point fort	Limite principale
Chatbot	L’utilisateur conduit la conversation	Simplicité et interaction naturelle	Peu ou pas d’action autonome
Workflow	Le code et les règles métier	Prévisibilité, audit et répétabilité	Gère mal les cas très variables
Copilote	L’humain garde la décision, l’IA prépare	Gain de temps avec supervision directe	Dépend de la disponibilité et de l’attention humaine
Agent	Le modèle choisit certaines actions dans des limites fixées	Adaptation aux tâches ouvertes et multi-étapes	Trajectoires variables, coût et risque supérieurs

L’agent adapte son chemin

Un agent est pertinent lorsque la tâche possède un objectif clair, mais que le bon chemin dépend de ce qui sera découvert en cours d’exécution. Une recherche approfondie illustre bien ce cas : l’agent formule une requête, lit des résultats, repère un indice, modifie sa stratégie, croise les preuves et s’arrête lorsque les éléments sont suffisants. L’article Promptique sur BrowseComp et les agents de recherche web montre pourquoi persistance et navigation multi-étapes doivent être évaluées séparément d’une simple connaissance factuelle.

La boucle agentique, étape par étape

Le cœur d’un agent n’est pas un long prompt. C’est une boucle d’orchestration. Les variantes comme ReAct combinent raisonnement, action et observation, mais une implémentation de production doit surtout rendre chaque transition explicite et contrôlable.

1. Interpréter l’objectif. Le système transforme la demande en objectif, contraintes, critères de réussite et données autorisées.
2. Choisir la prochaine action. Le modèle peut répondre, demander une précision, rechercher une donnée, appeler un outil ou proposer un plan.
3. Valider l’appel. Le code vérifie le nom de l’outil, le schéma des arguments, les droits, le budget, les règles métier et l’éventuelle approbation.
4. Exécuter dans l’environnement. L’application, et non le modèle, appelle l’API, lit le fichier, lance la requête ou prépare la mutation.
5. Observer le résultat. L’outil renvoie une sortie structurée, une erreur ou un état partiel. Cette observation rejoint le contexte de la boucle.
6. Évaluer la progression. Le système vérifie si le résultat est suffisant, contradictoire, risqué ou incomplet.
7. Continuer, escalader ou arrêter. Une limite d’étapes, un délai, un coût maximal et des règles d’arrêt empêchent une boucle sans fin.

La boucle ne doit pas dépendre uniquement du jugement du modèle. Les conditions simples appartiennent au code : montant maximal, domaine autorisé, présence d’un identifiant, statut d’un dossier, nombre de tentatives ou expiration d’un délai. Le modèle intervient là où la décision nécessite une interprétation. Le logiciel tranche là où la règle peut être déterministe.

Une bonne condition d’arrêt est positive et négative. Positive : « trois sources indépendantes soutiennent la conclusion ». Négative : « arrêter après huit appels, deux échecs consécutifs ou 90 secondes ». Ajoutez une sortie explicite pour les cas non résolus. Un agent fiable sait dire qu’il n’a pas terminé et transmettre un dossier lisible à un humain.

Pour approfondir ce mécanisme avec un exercice guidé, consultez la leçon Agents, ReAct, approbation humaine et mémoire.

Les briques d’un agent : modèle, outils, RAG, mémoire et état

Les mots « contexte », « connaissance », « mémoire » et « état » sont souvent mélangés. Les séparer améliore l’architecture et réduit les fuites de données.

Le modèle et les instructions

Le modèle interprète la tâche et produit soit une réponse, soit une demande d’outil. Les instructions définissent son rôle opérationnel, ses priorités, les outils disponibles, les interdictions et la forme attendue du résultat. Elles ne remplacent jamais les contrôles d’accès. Une phrase dans un prompt n’est pas une barrière de sécurité.

La conception de ces instructions, leurs exemples et leur versionnement seront approfondis dans le guide complet du prompt engineering.

Les outils

Un outil est une capacité exposée au modèle : chercher un client, lire un document, calculer une échéance, créer un brouillon, envoyer un message ou modifier un dossier. Chaque outil doit posséder un contrat précis, une entrée validée, une sortie stable, des droits minimaux, des erreurs intelligibles et une propriété claire. Un bon outil réalise une opération métier cohérente, pas une primitive dangereusement générale.

Le RAG et la recherche

Le RAG, retrieval-augmented generation, récupère des passages pertinents dans une base de connaissances avant la génération. Il répond à la question « quelles preuves faut-il placer dans le contexte maintenant ? ». Un agent peut piloter plusieurs recherches, reformuler une requête, filtrer les résultats et demander une autre source. Le RAG apporte des informations, mais ne garantit ni leur vérité ni leur bonne utilisation. La leçon RAG fiable et cité détaille l’indexation, la récupération et les citations.

La mémoire

La mémoire conserve des informations au-delà d’un tour ou d’une exécution. Une mémoire courte peut résumer la session en cours. Une mémoire longue peut enregistrer une préférence validée, une décision ou un fait durable. N’enregistrez pas automatiquement tout ce que le modèle lit. Une instruction malveillante trouvée dans un document peut empoisonner la mémoire et influencer les prochaines tâches. Définissez ce qui peut être écrit, qui le valide, combien de temps l’information reste et comment elle est supprimée.

L’état du workflow

L’état décrit ce qui s’est réellement passé : identifiant d’exécution, objectif, étape courante, outils appelés, approbations, résultats, erreurs et statut final. Il doit vivre dans un stockage contrôlé par l’application, pas seulement dans le texte de la conversation. Cette séparation permet de reprendre une tâche, d’éviter les doubles actions et de construire un journal d’audit.

Comprendre le function calling

Le tool calling désigne le mécanisme par lequel un modèle demande l’utilisation d’un outil. Une fonction fournie par l’application est un type d’outil parmi d’autres : certaines plateformes proposent aussi des outils intégrés, des outils libres ou des connexions MCP. Dans le cas du function calling, l’application présente au modèle des fonctions avec leur nom, leur description et le schéma de leurs paramètres. Le modèle peut alors produire une demande structurée telle que « rechercher le dossier 1842 » ou « préparer un brouillon de réponse ».

Pour une fonction fournie par votre application, la documentation OpenAI décrit un flux en cinq temps : envoyer la requête avec les outils disponibles, recevoir un appel, exécuter le code côté application, renvoyer le résultat au modèle, puis obtenir une réponse finale ou un nouvel appel. Cette séparation est fondamentale. Le modèle propose des arguments, mais le serveur les traite comme une entrée non fiable. MCP standardise pour sa part la connexion entre un hôte et un serveur ; le tool calling reste le mécanisme par lequel le modèle demande l’utilisation d’une capacité.

• Validez les arguments avec un schéma strict et des règles métier.
• Refusez tout outil inconnu, paramètre supplémentaire ou identifiant hors périmètre.
• Injectez côté serveur les informations déjà connues, comme l’utilisateur ou le tenant, au lieu de laisser le modèle les choisir.
• Rendez les opérations d’écriture idempotentes avec une clé de requête.
• Traitez séparément les outils de lecture, de préparation et d’exécution.
• Retournez des erreurs structurées qui permettent une correction sans divulguer de secret.

Les sorties structurées diminuent les ambiguïtés entre le modèle et le code. Elles ne prouvent pas que la valeur est correcte, mais garantissent mieux sa forme. Pour concevoir les schémas et éviter les formats fragiles, lisez Sorties structurées et appels d’outils.

Function calling ou API classique ?

Gardez une API classique lorsque le logiciel sait déjà quelle fonction appeler. Utilisez le function calling lorsque le choix de l’outil ou la construction des paramètres dépend d’une demande en langage naturel. Le modèle ne doit pas être placé au milieu d’une décision déterministe uniquement parce qu’il sait produire du JSON.

MCP : un standard pour connecter les outils et le contexte

MCP signifie Model Context Protocol. C’est un protocole ouvert qui standardise la manière dont une application d’IA découvre et utilise des capacités externes. L’analogie fréquente avec un port universel est utile : au lieu de construire une intégration spécifique pour chaque couple application-service, un serveur MCP expose un contrat que plusieurs clients compatibles peuvent comprendre.

Selon l’architecture officielle, un hôte est l’application d’IA qui coordonne l’expérience et les politiques. Il crée un client MCP pour chaque connexion. Chaque client communique avec un serveur MCP spécialisé. Le serveur expose des capacités sans recevoir automatiquement toute la conversation ni voir les autres serveurs. Le protocole s’appuie sur JSON-RPC. Depuis la révision 2026-07-28, les requêtes sont autonomes et sans état : version et capacités sont transmises dans les métadonnées de chaque requête, au lieu d’être négociées par un échange d’initialisation persistant.

Primitive MCP	Rôle	Exemple
Outil	Fonction exécutable que le modèle peut demander	Rechercher une facture ou créer un ticket
Ressource	Contenu adressable fourni au client	Documentation, fichier, schéma ou historique
Prompt	Modèle d’instruction réutilisable proposé par le serveur	Analyser un incident selon une procédure

La spécification courante 2026-07-28 conserve notamment les transports stdio pour un serveur local lancé comme sous-processus et Streamable HTTP pour les connexions distantes. Elle impose aussi server/discover, qui permet au serveur d’annoncer ses versions, capacités et informations d’identité. Les tâches longues ont quitté le protocole de base pour une extension officielle incompatible avec l’ancien mécanisme expérimental. Un projet doit donc épingler la version qu’il supporte, tester la compatibilité et prévoir une migration explicite.

Ce que MCP résout

• Une découverte cohérente des outils et de leurs schémas.
• Une interface commune pour des serveurs locaux ou distants.
• Une séparation entre l’hôte qui orchestre et le serveur qui fournit une capacité.
• La réutilisation d’une intégration dans plusieurs applications compatibles.
• La négociation des fonctions réellement supportées.

Ce que MCP ne résout pas

• Il ne choisit pas votre objectif métier.
• Il ne construit pas la boucle agentique à votre place.
• Il ne rend pas un serveur tiers digne de confiance.
• Il ne remplace pas l’autorisation dans le système source.
• Il ne garantit ni la qualité des descriptions d’outils ni la justesse de leurs résultats.
• Il ne protège pas automatiquement contre l’injection de prompt ou l’exfiltration de données.

Pour un premier projet, n’ajoutez pas MCP si vous contrôlez une seule application et trois fonctions stables. Un registre de fonctions interne sera plus simple. MCP devient intéressant quand plusieurs clients doivent réutiliser les mêmes capacités, quand l’écosystème fournit déjà un serveur officiel ou quand vous voulez découpler proprement l’outil de l’orchestrateur.

Migrer vers MCP 2026-07-28 sans casser les intégrations

La révision du 28 juillet 2026 constitue une rupture réelle. Elle retire initialize, initialized et Mcp-Session-Id du protocole courant. La découverte passe par server/discover, l’écoute par subscriptions/listen et la fonction Tasks quitte le cœur pour devenir une extension à négocier séparément. Roots, Sampling et Logging sont dépréciés dans cette révision, sans disparaître rétroactivement des anciennes implémentations.

Contrôles minimaux pour une migration vers MCP 2026-07-28

Zone	Dépendance à rechercher	Preuve attendue
Initialisation	initialize, initialized ou état lié à Mcp-Session-Id	Version et capacités validées dans chaque échange concerné
Découverte	Capacités mises en cache sans portée ni expiration	server/discover testé avec identité, portée et durée
Transport	GET persistant ou abonnements historiques	Coupure, reprise, annulation et client lent testés avec subscriptions/listen
Extensions	Tasks supposé présent dans le cœur	Extension activée uniquement après négociation explicite
Compatibilité	Un seul couple client-serveur testé	Tests croisés avec 2025-11-25 et 2026-07-28

« Sans session » ne signifie pas « sans état métier ». Une tâche longue, une approbation, un panier ou la progression d’un dossier nécessitent encore un identifiant, un stockage, une durée de vie et des contrôles d’accès explicites. Ils ne doivent simplement plus dépendre d’une session protocolaire implicite. Le dossier MCP 2026-07-28 : changements et méthode de migration fournit l’inventaire complet et une procédure de retour.

Un Skill gouverné n’est pas automatiquement un serveur MCP

Un Skill formalise une méthode, ses conditions d’usage et ses ressources. MCP décrit la manière de présenter une capacité à un hôte compatible. Mistral indique depuis juillet 2026 que les Skills utilisés par ses agents peuvent être accessibles comme serveurs MCP directement depuis Studio. Cette intégration évite certaines copies, mais elle ne transforme pas n’importe quel texte en outil sûr. Le Skill doit rester versionné, testé et limité, tandis que le serveur applique authentification, autorisation et validation. Consultez l’analyse du registre de Prompts et Skills de Mistral Studio.

A2A : faire collaborer des agents sans confondre les protocoles

A2A, Agent2Agent, est un protocole lancé par Google en 2025 puis confié à la Linux Foundation. Sa version 1.0 est désormais stable. Il vise l’interopérabilité entre agents construits avec des frameworks ou fournisseurs différents. Un serveur A2A peut publier une carte décrivant ses capacités, recevoir des messages, gérer des tâches longues et retourner des résultats ou artefacts sans exiger l’exposition de son raisonnement interne, de sa mémoire ou de ses outils privés.

Le guide Google des protocoles d’agents publié en mars 2026 formule bien la complémentarité : MCP aide un agent à accéder à des outils et des données, tandis qu’A2A l’aide à solliciter l’expertise d’un autre agent. Dans une chaîne logistique, un agent coordinateur peut utiliser MCP pour lire le stock interne, puis A2A pour interroger les agents de plusieurs fournisseurs.

Mécanisme	Connexion principale	Question traitée
API	Logiciel vers service	Comment appeler cette fonction connue ?
Function calling	Modèle vers fonctions de l’application	Quel outil décrit par le développeur faut-il demander ?
MCP	Application d’IA vers serveur de contexte ou d’outils	Comment découvrir et utiliser des capacités standardisées ?
A2A	Client A2A, application, service ou agent, vers serveur A2A	Comment découvrir une expertise et déléguer une tâche agentique ?

Ne transformez pas chaque service en agent. Un calcul fiscal, une recherche de stock ou une création de ticket sont des outils. Un agent distant est pertinent s’il possède sa propre logique de décision, un cycle de vie, une expertise et la responsabilité d’un résultat. Dans la majorité des premiers projets, un agent unique avec quelques outils est souvent plus simple à sécuriser, observer et évaluer qu’un réseau multi-agent.

Une architecture minimale de production

Une architecture viable ne se résume pas au modèle et à quelques outils. Elle entoure la boucle d’un ensemble de contrôles déterministes. Voici une base suffisamment simple pour être comprise, testée et exploitée.

1. Une interface d’entrée authentifie l’utilisateur, collecte la demande et affiche les actions proposées.
2. Un service d’orchestration porte l’objectif, la boucle, les limites, le routage des outils et les conditions d’arrêt.
3. Un registre d’outils conserve schémas, descriptions, niveaux de risque, permissions, délais et propriétaires.
4. Une couche de politique décide si l’appel est autorisé, interdit ou soumis à approbation.
5. Des adaptateurs exécutent les fonctions internes, API ou connexions MCP et normalisent leurs erreurs.
6. Un stockage d’état conserve l’exécution, les identifiants d’idempotence, les validations et le résultat.
7. Une couche de connaissance réalise la recherche et fournit des passages sourcés, sans les mélanger avec la mémoire durable.
8. Une observabilité enregistre événements, latence, coût, décisions de politique et résultats, avec masquage des données sensibles.
9. Un banc d’évaluation rejoue des cas versionnés avant chaque changement de modèle, de prompt, d’outil ou de serveur MCP.

Exemple : traiter une demande de remboursement

L’agent reçoit la demande et appelle un outil de lecture pour retrouver la commande. Il consulte la politique via le RAG. Il calcule l’éligibilité avec une fonction déterministe. S’il manque une preuve, il demande le document. Si le remboursement est admissible, il prépare l’action et explique le montant. Une approbation humaine est exigée au-dessus d’un seuil. Après validation, un outil d’écriture limité effectue l’opération avec une clé d’idempotence. L’état final et la référence sont enregistrés.

Cette architecture est plus robuste qu’un outil unique « gérer le remboursement » donnant un accès large au modèle. Chaque étape possède un propriétaire, des entrées vérifiables et un niveau de risque. En cas d’erreur, l’équipe sait si le problème vient de la recherche, du calcul, du choix d’outil, de l’autorisation ou de l’API.

Quand passer au multi-agent ?

Ajoutez un second agent seulement si une frontière claire le justifie : contexte très différent, permissions isolées, équipe propriétaire distincte, spécialité nécessitant d’autres outils ou besoin de délégation à un service distant. Si deux agents partagent le même objectif, les mêmes données et les mêmes outils, vous avez probablement créé de la complexité sans isolation utile.

Router les modèles sans multiplier les agents

Un système peut utiliser plusieurs modèles tout en restant un seul agent. Un modèle capable planifie ou traite l’ambiguïté. Un modèle plus rapide et économique exécute les extractions, classifications ou transformations dont le contrat est déjà clair. Une règle déterministe vérifie le format et transmet les échecs au niveau supérieur.

Exemple de routage par difficulté dans une boucle agentique

Étape	Traitement adapté	Condition d’escalade
Extraire	Modèle économique avec sortie structurée	Champ obligatoire absent ou format invalide
Planifier	Modèle plus capable avec outils limités	Objectif contradictoire ou risque élevé
Exécuter	Code déterministe après validation	Permission, plafond ou cible non conforme
Arbitrer	Humain compétent avec dossier de preuve	Action sensible, exception ou incertitude résiduelle

Les baisses de prix de GPT-5.6 Luna et Terra, ainsi que le positionnement de Gemini 3.5 Flash-Lite pour les sous-agents à fort volume, rendent ce routage plus accessible. Elles ne garantissent pas qu’un modèle léger réussira votre sous-tâche. Mesurez le coût par objectif atteint, le nombre d’appels, les escalades et les corrections. Une chaîne économique qui boucle dix fois peut coûter plus cher qu’un appel mieux choisi.

Le choix du fournisseur et du modèle dépend ensuite des outils, du contexte, de la latence, du coût et des exigences de données. Le comparatif ChatGPT, Claude, Gemini et Mistral aide à cadrer cette décision sans confondre le produit conversationnel et l’API utilisée par l’agent.

Sécurité, permissions et approbations humaines

Un agent transforme des erreurs de texte en erreurs d’action. Le risque dépend donc moins de l’éloquence du modèle que de ce qu’il peut lire, modifier, envoyer ou supprimer. Le NIST AI RMF 1.0 est un cadre volontaire, organisé autour de quatre fonctions continues : gouverner, cartographier, mesurer et gérer. Il est en cours de révision. L’initiative NIST sur les standards d’agents traite notamment de l’interopérabilité, de l’authentification, de l’identité, de l’autorisation et des évaluations de sécurité.

Appliquer le moindre privilège

• Utilisez selon le cas une identité de workload dédiée ou une identité utilisateur déléguée, toujours limitée au tenant et à l’action.
• Restreignez le périmètre par utilisateur, organisation, dossier et environnement.
• Séparez lecture, préparation, approbation et exécution.
• Utilisez des jetons courts et liés à une audience précise.
• N’exposez pas au modèle les secrets, clés ou jetons.
• Autorisez explicitement les domaines réseau et chemins de fichiers nécessaires.
• Placez l’exécution de code ou les outils tiers dans un bac à sable.

Pour MCP distant, la documentation officielle recommande OAuth, HTTPS, validation de l’audience et scopes minimaux. Le passage direct d’un jeton reçu vers un service en aval est explicitement présenté comme un anti-pattern. La découverte OAuth peut aussi ouvrir un risque SSRF : validez les redirections et les URL récupérées, imposez HTTPS et bloquez les destinations privées ou locales non autorisées. Un serveur MCP agit comme une frontière de sécurité, pas comme un tuyau opaque.

Un serveur MCP local peut exécuter du code avec les droits du processus hôte. Vérifiez son origine, épinglez sa version et contrôlez sa signature ou son empreinte lorsqu’elle est fournie. Isolez son exécution, limitez ses accès aux fichiers et au réseau et n’installez jamais un serveur inconnu uniquement parce qu’un dépôt ou une page le recommande.

Traiter toute donnée externe comme non fiable

Un document, une page web, un courriel ou la sortie d’un serveur MCP peut contenir une instruction destinée à détourner l’agent. C’est l’injection indirecte de prompt. Séparez les instructions de confiance des contenus récupérés, réduisez les données transmises aux outils, filtrez les sorties et exigez une approbation avant toute action sensible déclenchée à partir d’un contenu externe. La leçon Prompt injection, confidentialité et sécurité présente les scénarios et défenses en profondeur.

Concevoir une approbation utile

Une boîte « Autoriser ? » sans contexte crée une fatigue de validation. L’écran doit afficher l’action, la cible, les données qui seront envoyées, la raison, l’effet attendu, le caractère réversible et les différences par rapport à l’état actuel. L’approbation doit porter sur une action précise et expirer. Une validation générale accordée au début d’une longue tâche ne protège pas contre un changement de trajectoire.

Prévoir le rayon d’impact

Limitez le nombre d’enregistrements, le montant, la fréquence et le volume de données par exécution. Ajoutez des quotas par utilisateur et par outil. Préférez les brouillons et opérations réversibles. Un bouton d’arrêt doit couper les nouveaux appels, révoquer les jetons temporaires et préserver les traces nécessaires à l’enquête.

Évaluer un agent sans se tromper de métrique

Un test manuel montre qu’un scénario peut fonctionner. Il ne mesure ni sa fréquence de réussite ni ses régressions. Les agents sont difficiles à évaluer parce que plusieurs trajectoires peuvent mener à un bon résultat, tandis qu’une trajectoire apparemment propre peut produire une mauvaise action.

Anthropic recommande de combiner des évaluateurs programmatiques, des juges modèles et des évaluations humaines. Le code vérifie les invariants objectifs. Un modèle peut comparer une réponse à une grille pour des dimensions nuancées. L’humain examine l’utilité, les cas ambigus et les décisions à fort impact. Aucun de ces évaluateurs ne doit porter seul toute la mesure.

Construire un jeu de tâches représentatif

• Cas courants avec une réussite clairement définie.
• Demandes incomplètes nécessitant une clarification.
• Cas limites et données contradictoires.
• Erreurs d’API, délais, outils indisponibles et résultats vides.
• Tentatives d’injection, exfiltration et élévation de privilèges.
• Actions nécessitant une approbation, puis refus ou expiration.
• Tâches impossibles qui doivent produire une escalade propre.
• Variantes linguistiques et formulations réalistes des utilisateurs.

Mesurer le résultat et la trajectoire

• Résultat : objectif atteint, exactitude, complétude, preuves et absence d’effet indésirable.
• Trajectoire : bons outils choisis, arguments valides, ordre acceptable, erreurs récupérées et aucune action interdite.
• Efficacité : nombre d’étapes, tokens, coût, latence et appels inutiles.
• Robustesse : stabilité sur plusieurs exécutions et face aux variations de formulation.
• Sécurité : respect des permissions, approbations, frontières de données et règles d’arrêt.
• Expérience : clarté des demandes de précision, des validations et du compte rendu final.

Ne rendez pas obligatoire une trajectoire unique si plusieurs chemins sont légitimes. Évaluez plutôt des invariants : l’agent doit consulter la politique avant une décision, ne peut écrire qu’après validation, doit citer les sources utilisées et ne peut dépasser le budget. Conservez les traces de référence pour comprendre une régression au lieu de regarder uniquement une note globale.

Évaluer avant et après le déploiement

Les évaluations hors ligne permettent de comparer une version candidate sur un corpus fixe. En production, surveillez les refus, escalades, corrections humaines, annulations, coûts extrêmes, outils rarement utilisés et nouvelles erreurs. Échantillonnez des traces pour une revue régulière, avec anonymisation et durée de conservation définie. Toute modification du modèle, des instructions, du schéma d’un outil, du serveur MCP ou de la base documentaire doit relancer les tests pertinents.

Ces évaluations doivent être versionnées avec les instructions et les exemples. Le guide complet du prompt engineering approfondira cette discipline d’itération, du cas de test à la comparaison de versions.

Cas d’usage pertinents pour les agents IA

Recherche et veille sourcée

L’agent décompose une question, recherche plusieurs sources, suit les indices, extrait les preuves, signale les contradictions et produit un dossier cité. La valeur vient de l’adaptation de la stratégie à ce qui est découvert. Les garde-fous essentiels sont la liste de domaines, la traçabilité des extraits, la distinction entre preuve et hypothèse et une date limite de fraîcheur.

Support client avec actions contrôlées

L’agent retrouve le dossier, résume l’historique, consulte les règles, propose une réponse et prépare une action. Les cas simples peuvent être automatisés avec des plafonds. Les exceptions sont transmises avec un résumé et les preuves. L’objectif n’est pas de remplacer tous les conseillers, mais de réduire les recherches répétitives et d’améliorer la continuité.

Opérations et traitement de dossiers

Pour un dossier variable, l’agent peut identifier les pièces manquantes, interroger plusieurs systèmes, appliquer des règles déterministes et préparer les étapes suivantes. Il convient lorsque les dossiers partagent un objectif, mais pas exactement le même parcours. Les écritures restent isolées derrière des outils étroits et des validations adaptées au risque.

Développement logiciel

Un agent de code peut explorer un dépôt, localiser les fichiers concernés, modifier, exécuter des tests et analyser les erreurs. Le dépôt et le bac à sable fournissent des retours rapides et vérifiables, ce qui rend ce domaine particulièrement adapté. Limitez les chemins accessibles, les commandes, le réseau, les secrets et toute opération de déploiement.

Analyse et préparation de décisions

L’agent rassemble des données, exécute des calculs, compare des scénarios et prépare un mémo. L’humain conserve la décision lorsque les impacts sont juridiques, financiers, médicaux ou humains. L’agent doit séparer les faits observés, les hypothèses, les calculs et les recommandations.

Quand ne pas utiliser un agent

• Le processus est stable et se traduit facilement en règles.
• Une erreur unique peut avoir un impact irréversible majeur.
• Il n’existe pas de moyen observable de vérifier le résultat.
• Les outils n’offrent pas de permissions granulaires ou d’annulation.
• Le volume, la latence ou le coût rendent la boucle non rentable.
• Les données nécessaires ne peuvent pas être utilisées dans le cadre prévu.
• L’organisation ne possède ni propriétaire métier ni équipe d’exploitation.

Pour relier ces choix à un projet concret et à ses obligations, le guide IA générative en entreprise : déploiement, RGPD et AI Act aborde la gouvernance, les données et la conduite du changement.

Plan de déploiement en quatre étapes

1. Cadrer un résultat vérifiable

Choisissez une tâche fréquente, assez complexe pour justifier l’IA, mais limitée. Définissez le déclencheur, le résultat attendu, les utilisateurs, les données, les erreurs acceptables et l’escalade. Mesurez le processus actuel : temps, coût, taux de reprise et qualité. Sans référence, vous ne saurez pas si l’agent apporte une amélioration.

2. Construire un copilote observable

Commencez par la lecture et la préparation. L’agent propose, l’humain valide et exécute. Enregistrez les corrections et motifs de refus. Ce mode révèle les données manquantes, les règles implicites et les vrais cas limites. Il constitue en même temps le premier corpus d’évaluation.

3. Automatiser les segments à faible risque

Automatisez seulement les classes de cas dont la réussite est mesurée. Ajoutez des seuils, outils étroits, clés d’idempotence et possibilités d’annulation. Conservez l’approbation pour les exceptions et effets sensibles. Augmentez progressivement le périmètre à partir des résultats, pas d’une impression générale.

4. Industrialiser et gouverner

Attribuez un propriétaire métier, un propriétaire technique et un responsable des risques. Versionnez instructions, outils, modèles, serveurs MCP et jeux de tests. Organisez la surveillance, la rotation des secrets, la réponse aux incidents, la revue des accès et la suppression des données. Documentez la procédure de désactivation. Une automatisation agentique est un service vivant, pas un prompt livré une fois.

Dans un contexte professionnel, cette industrialisation doit être alignée avec la gouvernance des données, le RGPD et l’AI Act. Le guide IA générative en entreprise traite ces dimensions au-delà de l’architecture technique.

Checklist avant de mettre un agent en production

Objectif et périmètre

• L’objectif, les critères de réussite et les cas hors périmètre sont écrits.
• Le besoin justifie une décision dynamique plutôt qu’un workflow classique.
• Un propriétaire métier peut arbitrer les cas ambigus.
• Le comportement attendu en cas d’incertitude est défini.

Outils et données

• Chaque outil possède un schéma, un propriétaire et un niveau de risque.
• Les entrées sont validées côté serveur et les sorties sont bornées.
• Les permissions sont limitées à l’utilisateur, au tenant et à la tâche.
• Les opérations d’écriture sont idempotentes ou réversibles.
• Les secrets ne sont jamais placés dans le contexte du modèle.
• Les serveurs MCP tiers ont été vérifiés, épinglés et inventoriés.

Boucle et sécurité

• Le nombre d’étapes, la durée, le coût et les tentatives sont limités.
• Les actions sensibles nécessitent une approbation contextualisée.
• Les contenus externes sont traités comme non fiables.
• La mémoire durable possède des règles d’écriture, validation et suppression.
• Un arrêt d’urgence et une révocation des accès sont disponibles.
• Les journaux masquent les données sensibles sans perdre l’audit utile.

Évaluation et exploitation

• Un jeu de tâches couvre succès, limites, erreurs et attaques.
• Le résultat, la trajectoire, le coût, la latence et la sécurité sont mesurés.
• Les versions candidates sont comparées avant déploiement.
• Les corrections humaines et incidents enrichissent les évaluations.
• Des alertes détectent boucles, coûts anormaux et outils inhabituels.
• Une procédure de retour arrière a été testée.

FAQ sur les agents IA et MCP

Quelle est la différence entre une IA générative et un agent IA ?

Une IA générative produit du contenu à partir d’une entrée. Un agent est une application qui utilise un modèle dans une boucle pour choisir des actions, appeler des outils, observer leurs résultats et poursuivre un objectif. Le même modèle peut alimenter un chatbot sans outil ou un agent multi-étapes.

MCP est-il obligatoire pour créer un agent ?

Non. Un agent peut appeler des fonctions internes ou des API sans MCP. Le protocole devient utile pour standardiser des intégrations réutilisables entre plusieurs applications, ou pour exploiter un serveur compatible existant. Pour trois outils internes stables, une intégration directe est souvent plus simple.

MCP remplace-t-il les API ?

Non. Un serveur MCP s’appuie fréquemment sur des API et les présente selon un contrat adapté aux applications d’IA. Les API restent le mécanisme d’accès au service. MCP ajoute une couche standard de découverte, de schémas, de transport et de négociation des capacités.

Quelle différence entre MCP et A2A ?

MCP relie principalement une application d’IA à des outils, ressources et prompts fournis par un serveur. A2A organise la découverte et la communication entre agents qui conservent leur propre logique. Un agent peut utiliser MCP pour ses outils, puis A2A pour déléguer une mission à un autre agent.

Qu’est-ce qu’un serveur MCP ?

C’est un programme local ou distant qui expose des capacités selon le Model Context Protocol. Il peut fournir des outils exécutables, des ressources ou des modèles de prompts. Il doit appliquer ses propres contrôles d’accès et ne doit recevoir que le contexte nécessaire à l’opération.

Un agent IA peut-il agir sans validation humaine ?

Oui pour des actions bornées, réversibles, bien évaluées et à faible impact. Une validation reste nécessaire pour les actions sensibles ou exceptionnelles. Le bon niveau dépend du risque, de la qualité mesurée, du rayon d’impact et des obligations de l’organisation.

Comment empêcher un agent de boucler ?

Imposez un nombre maximal d’étapes et d’appels, un délai, un budget et une limite de répétition. Détectez les actions identiques et erreurs consécutives. Définissez une sortie « non résolu » avec escalade. Ne laissez pas le modèle être seul juge de sa poursuite.

Le RAG est-il une mémoire ?

Pas au sens strict. Le RAG récupère des connaissances pertinentes depuis une collection. La mémoire conserve des éléments issus d’interactions ou de décisions antérieures. Les deux peuvent utiliser une base vectorielle, mais leurs règles de sélection, de gouvernance et de durée de vie doivent rester distinctes.

Pourquoi ne pas donner tous les outils à l’agent ?

Un grand catalogue peut augmenter les tokens, la latence, les erreurs de sélection et la surface d’attaque. Exposez uniquement les capacités utiles à la tâche. Utilisez un routage ou une découverte contrôlée pour charger les outils spécialisés lorsque le besoin est établi.

Comment choisir entre un agent unique et plusieurs agents ?

Commencez par un agent unique. Séparez seulement lorsqu’il existe une vraie frontière de contexte, de permissions, d’expertise ou de propriété. Le multi-agent ajoute des messages, des échecs de coordination, du coût et une évaluation plus difficile. Il doit résoudre un problème observé, pas anticiper une complexité hypothétique.

Quelles métriques suivre en production ?

Suivez le taux de réussite vérifiée, les corrections et escalades humaines, les appels d’outils invalides, les refus de politique, le nombre d’étapes, la latence, le coût, les boucles interrompues et les incidents. Segmentez ces métriques par cas d’usage et version.

Conclusion : automatiser moins, mais mieux

Les agents IA deviennent utiles lorsque la tâche exige une adaptation réelle : chercher, comparer, choisir un outil, vérifier puis ajuster. Leur valeur ne vient pas d’une autonomie maximale, mais d’une délégation bien dessinée. Un workflow déterministe doit conserver ce qu’il sait faire. Le modèle doit intervenir sur les décisions ambiguës. L’humain doit rester présent aux frontières de risque.

Le function calling fournit le contrat entre le modèle et votre code. MCP facilite la réutilisation des outils et du contexte. A2A ouvre la collaboration entre agents. Ces protocoles ne remplacent ni l’architecture, ni les permissions, ni les évaluations. Commencez avec un objectif mesurable, un agent, quelques outils en lecture et un journal structuré, minimisé et expurgé des secrets et données inutiles. Ajoutez l’autonomie uniquement lorsque les preuves montrent qu’elle améliore le résultat sans dépasser votre tolérance au risque.

Sources officielles

• OpenAI, nouveaux tarifs GPT-5.6 et Fast mode, 30 juillet 2026.
• Google AI for Developers, Gemini 3.6 Flash et 3.5 Flash-Lite.

• Anthropic, Building effective agents, distinction entre workflows et agents, architectures composables.
• Anthropic, Trustworthy agents in practice, principes de contrôle humain, sécurité, transparence et vie privée.
• Anthropic, Demystifying evals for AI agents, méthodes d’évaluation des trajectoires et résultats.
• OpenAI, Function calling, flux d’appel d’outil et schémas de fonctions.
• OpenAI, Agents SDK, boucle, état, orchestration, garde-fous et traçage.
• OpenAI, MCP and Connectors, connexions MCP distantes, approbations et risques.
• Model Context Protocol, Architecture overview, hôtes, clients, serveurs, couches et primitives.
• Model Context Protocol, spécification 2026-07-28, protocole sans état et négociation par requête.
• Model Context Protocol, changements de la révision 2026-07-28, migrations et incompatibilités.
• Model Context Protocol, Security Best Practices, autorisation, jetons, SSRF et isolation.
• Google Developers Blog, Developer’s Guide to AI Agent Protocols, complémentarité entre MCP et A2A.
• A2A Protocol, spécification 1.0, découverte, messages, tâches et sécurité.
• NIST, AI Risk Management Framework, cadre volontaire de gestion des risques en cours de révision.
• NIST, AI Agent Standards Initiative, interopérabilité, identité et sécurité des agents.
• Mistral, registre de Prompts et Skills dans Studio, 9 juillet 2026.

Sources et état des standards vérifiés le 2 août 2026. Les protocoles et SDK évoluent rapidement : vérifiez la révision supportée par vos clients et serveurs avant toute mise en production.