

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Qu'est-ce que le MCP ?
<a name="what-is-mcp"></a>

LLMs fonctionnent en prédisant une réponse à une question en fonction de leurs données d'entraînement. Cela signifie que le LLM ne peut fournir des réponses que sur les données et les événements qu'il a déjà vus. Des méthodes telles que la génération augmentée de récupération (RAG) et les bases de connaissances vous permettent d'inclure des données contextuelles. Cependant, si vous demandiez à un LLM quelles seront les prévisions météorologiques de demain ou combien de clients figurent dans votre base de données, il hallucinerait probablement ou ne serait pas en mesure de fournir une réponse, car ces questions ne relèvent pas des connaissances préétablies du LLM. Pour être en mesure de répondre à ce type de questions, un agent doit avoir accès à des fonctionnalités externes, à des données et APIs en dehors du contexte natif du LLM.

## Comprendre les outils
<a name="understanding-tools"></a>

**Nous pouvons donner au LLM l'accès à des systèmes et à un contexte supplémentaires grâce à des outils.**Les *outils* sont des fonctions confiées au LLM pour atteindre un objectif clair. Un outil peut appeler une API, interroger une base de données, effectuer des opérations de calcul, exploiter un sandbox de code, effectuer une recherche sur le Web et même invoquer un autre système d'IA ou agent-as-a-tool. Chaque outil doit inclure une description indiquant au LLM ce que fait l'outil, quand l'utiliser et quels paramètres il accepte. Cela permet au LLM de prendre des décisions nuancées quant à l'outil ou à la combinaison d'outils à invoquer en fonction des entrées de l'utilisateur. Le LLM est informé des outils mis à la disposition de l'agent, ce qui lui permet de générer des réponses demandant à l'agent d'invoquer l'outil. Par exemple, lorsque vous demandez au LLM combien de clients se trouvent dans votre base de données, le LLM renvoie une réponse à l'agent demandant d'exécuter l'`query_database`outil avec des paramètres d'entrée spécifiques. Le LLM détermine l'outil à invoquer et les entrées pour l'appel d'outil. L'agent exécute ensuite l'outil, qui convertit l'entrée en langage naturel en un appel de fonction syntaxiquement correct et exécute la requête. L'agent invoque l'outil ou les outils en fonction des instructions du LLM, et ces résultats sont renvoyés au LLM. Cela tire parti de la capacité du LLM à raisonner plutôt qu'à saisir du texte et à sélectionner les outils appropriés pour le travail.

L'image suivante montre comment chaque agent gère son propre ensemble d'outils pour chaque cible.

![Chaque agent gère son propre ensemble d'outils pour chaque cible.](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/mcp-strategies/images/agent-tool-management.png)


L'extension de l'accès aux outils peut présenter des défis pour les solutions d'IA agentic :
+ Si chaque développeur crée son propre outil pour les mêmes fonctionnalités externes, les efforts sont dupliqués et les méthodes d'interaction avec ces fonctionnalités externes ne sont pas standardisées. Cela produit des implémentations incohérentes entre vos agents. Bien que vous puissiez résoudre ce problème en développant des outils standard dans des bibliothèques et en les distribuant, cela manque de gouvernance centralisée. Cela complique l'application des politiques de sécurité, le suivi de l'utilisation des outils, la gestion des versions entre les équipes ou le respect des normes organisationnelles. En outre, lorsque vous intégrez des outils directement à l'agent, vous devez redéployer votre agent chaque fois qu'un nouvel outil est créé ou qu'un outil existant est mis à jour.
+ Fournir des outils à un LLM consomme sa fenêtre contextuelle. *La fenêtre contextuelle* représente le nombre de *jetons* (unités de texte LLMs traitées, représentant généralement des mots, des parties de mots ou des signes de ponctuation) qu'un modèle peut prendre en compte à tout moment. LLMs ont une limite de fenêtre contextuelle. Les outils et leur documentation utilisent cette fenêtre contextuelle limitée ainsi que les instructions du système et celles des utilisateurs. Lorsque la fenêtre contextuelle se remplit, les performances LLMs peuvent être dégradées en raison de multiples facteurs : difficulté à identifier les informations pertinentes, complexité accrue du traitement et capacité de raisonnement réduite. Le défi est d'autant plus grand lorsque les définitions d'outils, les instructions du système et l'historique des conversations se disputent un espace limité dans les fenêtres contextuelles, car ils sont fournis à chaque appel de LLM.

Ainsi, le nombre d'outils et la manière dont ils sont documentés ont un impact direct sur les performances du LLM, telles que le temps de réponse et la précision.

Le MCP établit une norme universelle pour connecter les agents à des capacités externes. Il est communément appelé « USB-C pour les applications d'IA ». Au lieu d'enregistrer les outils directement auprès des agents, les serveurs MCP servent d'intermédiaire pour héberger les outils découverts et invoqués via [JSON-RPC 2.0](https://www.jsonrpc.org/specification). Au lieu d'ajouter des dizaines ou des centaines d'outils différents à votre agent et de les maintenir au fil du temps, MCP vous permet d'enregistrer des serveurs MCP qui encapsulent les outils auxquels votre agent peut accéder. Cette approche normalise la manière dont les outils sont empaquetés, présentés et invoqués. Cela peut aider à relever les défis d'échelle et de gouvernance liés à l'utilisation des outils au sein de vos agents. Il dissocie également le développement et les opérations des agents des outils qu'il utilise pour les capacités externes.

La figure suivante montre les agents utilisant le protocole MCP pour accéder à des ressources externes.

![Utilisation du protocole Model Context pour accéder à des ressources externes.](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/mcp-strategies/images/mcp-external-resources.png)


Cependant, la norme MCP ne résout pas tous les problèmes de mise à l'échelle et de gouvernance. La mise en œuvre de serveurs MCP doit être associée à des stratégies efficaces de conception d'outils, d'hébergement et de gouvernance d'entreprise. Ce guide fournit les meilleures pratiques pour chaque stratégie afin de vous aider à créer et à utiliser MCP dans le cadre de vos solutions d'IA agentic.

## Quand utiliser le MCP
<a name="when-to-use-mcp"></a>

MCP fournit une infrastructure stratégique pour étendre vos initiatives d'intelligence artificielle agentique. En centralisant la gestion et la gouvernance des outils, les serveurs MCP réduisent le coût cumulé de création et de maintenance d'intégrations personnalisées entre plusieurs agents. Cela permet d'augmenter les rendements au fur et à mesure que votre écosystème d'agents se développe.

Le MCP fait probablement partie de votre stratégie lorsque :
+ Vous avez besoin d'une gouvernance centralisée pour la manière dont les agents accèdent aux systèmes et services de l'entreprise, tels que les bases de données APIs, les outils internes et les intégrations tierces.
+ Les développeurs passent trop de temps à écrire des intégrations personnalisées qui ne sont pas cohérentes entre les implémentations.
+ Vous disposez d'outils dupliqués susceptibles de répondre à des fonctionnalités communes.
+ Vous souhaitez proposer vos outils ou données propriétaires à des consommateurs externes ou à des systèmes agentiques tiers via des interfaces MCP normalisées et gouvernées, afin de débloquer de nouvelles sources de revenus tout en préservant la sécurité et le contrôle.

Après avoir décidé que les serveurs MCP feront partie de votre stratégie, déterminez si les implémentations de serveurs MCP open source existantes répondent à vos besoins, si elles doivent être améliorées ou si vous devez créer des serveurs personnalisés. De nombreuses implémentations de serveurs MCP prédéfinies sont disponibles dans des référentiels publics et couvrent des fonctionnalités courantes telles que l'accès au système de fichiers, la navigation sur le Web, les bacs à sable de code, l'accès aux bases de données et les intégrations d'API.

Dans de nombreux cas, les serveurs MCP préexistants sont suffisants. Par exemple, AWS fournit un serveur MCP distant géré qui fournit aux assistants et aux agents IA un accès sécurisé et authentifié Services AWS via des interactions en langage naturel. [Serveur AWS MCP](https://docs.aws.amazon.com/aws-mcp/latest/userguide/what-is-mcp-server.html) Vous pouvez l'utiliser Serveur AWS MCP pour effectuer des AWS tâches complexes en plusieurs étapes en combinant un accès en temps réel à la AWS documentation, des appels d'API syntaxiquement corrects et des flux de travail prédéfinis appelés [Agent SOPs](https://docs.aws.amazon.com/aws-mcp/latest/userguide/agent-sops.html) qui suivent les meilleures pratiques. AWS AWS les teste en permanence Serveur AWS MCP pour s'assurer que les agents clients peuvent les utiliser avec succès.

Vous devez tester ces serveurs MCP existants avec vos agents afin de déterminer s'ils répondent à vos besoins d'utilisation. Si un agent ne parvient pas à terminer les flux de travail, génère des réponses incorrectes ou sous-optimales, ne parvient pas à gérer des processus complexes en plusieurs étapes, ou ne respecte pas les meilleures pratiques ou considérations de sécurité spécifiques à un domaine, vous devez envisager des améliorations dans plusieurs domaines.

Lorsque les serveurs MCP existants ne répondent pas entièrement à vos besoins et qu'ils ont du mal à utiliser correctement les outils existants ou à produire des réponses précises, envisagez ces approches d'amélioration avant de créer des serveurs personnalisés :
+ **Enrichissez le contexte** de l'agent : si votre agent peine à utiliser correctement ou efficacement les outils d'un serveur MCP existant, pensez à compléter ces définitions d'outils par de la documentation ou des exemples supplémentaires. Cela permet de fournir un contexte supplémentaire au LLM.
+ **Ajoutez des outils complémentaires** : étendez les serveurs MCP existants avec des outils qui accèdent à des données organisationnelles ou à un contexte supplémentaires dont les agents ont besoin pour mener à bien les flux de travail.
+ **Améliorez les sous-jacents APIs** : simplifiez votre service APIs pour le rendre plus convivial en matière de LLM en réduisant la complexité des paramètres, en diffusant des messages d'erreur plus clairs et en proposant des valeurs par défaut judicieuses que les agents peuvent utiliser.

Alors que l'utilisation des implémentations de serveurs MCP existantes accélère le développement de fonctionnalités communes, la création de serveurs MCP personnalisés est une nécessité lorsque votre cas d'utilisation nécessite des fonctionnalités spécialisées. Les serveurs MCP personnalisés vous aident à encapsuler l'expertise du domaine, à appliquer les normes organisationnelles, à améliorer la fiabilité des agents pour les flux de travail complexes et à garantir la conformité aux exigences de sécurité. Envisagez de créer un serveur MCP personnalisé dans les situations suivantes :
+ Flux de **travail spécifiques au domaine — Les flux** de travail en plusieurs étapes nécessitant une expertise du domaine doivent être encapsulés dans des outils MCP personnalisés lorsque les connaissances nécessaires ne sont pas capturées dans la documentation de l'API. ****Par exemple, au lieu de laisser les agents orchestrer des pipelines de données de santé complexes qui doivent valider la conformité à la loi HIPAA (Health Insurance Portability and Accountability Act), anonymiser les informations personnelles et passer au format [HL7 FHIR](https://hl7.org/fhir/), fournissez un `process_patient_data` outil qui intègre directement l'expertise du domaine. Cela élimine la dépendance à l'égard du LLM pour orchestrer et exécuter correctement les étapes du flux de travail, ce qui améliore la cohérence et la conformité.
+ **Abstractions de la voie dorée : les** agents peuvent avoir du mal à mettre en œuvre des approches optimales car ils ne disposent pas d'un contexte organisationnel et optent par défaut sur des modèles de base plutôt que sur les meilleures pratiques organisationnelles. Dans ces scénarios, vous pouvez appliquer des normes prescriptives en matière de coûts, de performances ou de sécurité en encapsulant ces voies privilégiées dans des outils MCP personnalisés. Par exemple, au lieu de laisser les agents déployer une infrastructure avec des paramètres par défaut qui peuvent être peu sécurisés ou inefficaces, fournissez un `deploy_secure_infrastructure` outil qui intègre directement les normes de votre entreprise.
+ **Orchestration multiservice complexe** : au lieu de demander à l'agent d'orchestrer des flux de travail complexes en essayant de déduire la séquence et le jeu de services appropriés à utiliser à chaque étape, vous pouvez créer cette logique de manière déterministe dans un outil MCP. Vous souhaiterez peut-être également fournir une expertise sur les modèles d'intégration de services optimaux dont l'agent n'est peut-être pas au courant. ****Cela peut également améliorer la précision et l'efficacité de vos agents.
+ **Bonnes pratiques spécifiques aux services** : cela est courant pour les outils axés sur la sécurité qui aident les agents à mettre en œuvre des politiques de chiffrement, des contrôles d'accès et des modèles de conformité spécifiques au service auquel ils accèdent via l'outil d'agent. En outre, si certaines bonnes pratiques opérationnelles spécifiques à un service ne sont pas évidentes, l'utilisation d'un serveur MCP peut vous aider à vous assurer qu'elles sont mises en œuvre et qu'elles ne sont pas laissées à l'appréciation d'un agent.