MCP : comment les assistants IA travaillent avec les plateformes

Un modèle de langage en sait beaucoup sur le monde et rien sur votre plateforme. Il ne connaît ni les inscriptions du jour ni l’ébauche sur laquelle la rédaction travaille en ce moment. Pour pouvoir travailler avec, il lui faut une connexion. Jusqu’ici, chacune de ces connexions était une pièce unique : une intégration pour cet assistant et ce système, une autre pour la paire suivante. Avec dix assistants et dix systèmes, cela fait cent intégrations, et chacune demande de la maintenance.

Une langue commune

Le Model Context Protocol, MCP en abrégé, définit comment un assistant IA communique avec un autre système. Il a été présenté fin 2024 comme standard ouvert. Il est aujourd’hui pris en charge par les assistants des grands fournisseurs de modèles de langage comme par les environnements de développement courants. Depuis décembre 2025, il appartient à l’Agentic AI Foundation, sous l’égide de la Linux Foundation, et donc plus à aucun fournisseur en particulier. Un système qui parle MCP est accessible à tous ces assistants. Cent intégrations deviennent vingt : dix assistants et dix systèmes qui se sont mis d’accord sur la même langue.

Comment l’assistant et le système dialoguent

D’un côté se trouve l’application dans laquelle vous travaillez, par exemple l’assistant d’un fournisseur ou un environnement de développement. De l’autre, une plateforme ou un service. Par l’interface MCP, le système indique ce qu’il propose :

• Outils : des actions que l’assistant peut déclencher, par exemple créer une ébauche ou interroger des données.
• Ressources : des contenus à lire, par exemple des pages, des documents ou des enregistrements.
• Modèles de prompts : des tâches préparées que le système fournit d’emblée.

Chaque outil porte une description en langage courant. C’est grâce à elle que le modèle reconnaît quel outil correspond à la question, puis l’appelle. Le système fait le reste. Il vérifie l’authentification, récupère les données et renvoie le résultat. La réflexion revient au modèle de langage derrière l’assistant, le système ne fait qu’exécuter. Si les deux tournent sur la même machine, ils communiquent directement ; par le réseau, cela passe par HTTP, avec une authentification OAuth.

La connexion elle-même se configure rapidement. Si vous utilisez vous-même un assistant, vous lui accordez l’accès lors de la connexion et définissez ce qu’il a le droit de faire. Ensuite, il travaille avec ces autorisations, pas avec votre compte. C’est différent lorsqu’un agent travaille de manière autonome avec la plateforme, par exemple dans un processus automatisé. L’interface MCP figure alors dans la configuration de son système d’agents (souvent appelé harness). C’est là qu’est défini comment l’agent s’authentifie et quels outils il peut utiliser, avec ses propres identifiants plutôt que ceux d’une personne. De manière simplifiée, cela ressemble à ceci :

{
    "agent": "agent-x",
    "mcp": {
        "stack": {
            "url": "https://stack.votreentreprise.ch/mcp",
            "auth": {
                "type": "oauth2",
                "client_id": "agent-x",
                "client_secret": "${STACK_AGENT_SECRET}"
            },
            "tools": ["page.read", "page.draft", "data.query"]
        }
    }
}

La configuration règle l’accès. La manière dont l’agent doit utiliser les outils figure dans son prompt système, en langage courant :

Vous êtes l’agent X et préparez des pages promotionnelles dans le Stack CMS d’Exemple SA.

Par l’interface « stack », vous accédez aux pages et aux données de vente.
- Lisez une page avec page.read avant de proposer quoi que ce soit à son sujet.
- Récupérez les chiffres de vente avec data.query, jamais de mémoire.
- Ne créez des modifications que sous forme d’ébauches avec page.draft.
  Publier ne fait pas partie de votre tâche, c’est la rédaction qui valide.
- S’il vous manque une information, demandez-la au lieu de l’inventer.

La configuration détermine ce que l’agent peut atteindre, le prompt système la manière dont il l’utilise. Ce qu’il a réellement le droit de modifier, c’est toujours la plateforme qui le décide.

Ce que l’assistant a le droit de faire

MCP règle la manière dont l’assistant et le système communiquent. Il ne règle pas ce que l’assistant a le droit de voir et de modifier. C’est la plateforme qui en décide, et c’est là que nous intervenons dans le stack :

• L’assistant reçoit ses propres autorisations, distinctes des comptes utilisateur. Vous configurez individuellement ce qu’il peut lire et modifier.
• S’il veut modifier quelque chose, vous recevez d’abord un aperçu. Vous acceptez ou rejetez, et chaque modification peut être annulée. Il n’existe pas d’outil pour publier.
• Le choix du modèle de langage qui travaille derrière l’assistant est une décision à part. S’il utilise le modèle d’un fournisseur externe, ses requêtes partent chez ce fournisseur. Si vous ne le souhaitez pas, vous utilisez un modèle que nous exploitons en Suisse.
• Si l’assistant appelle un outil du stack, par exemple pour traduire, cet outil travaille avec le glossaire du mandant et avec les modèles que nous exploitons en Suisse.

Où nous utilisons MCP dans le stack

Avec la prochaine génération du stack, que nous déployons à partir de 2027, une interface MCP fait partie de l’équipement de base de chaque plateforme. Ces usages sont prévus :

• Rédaction : votre propre agent lit les pages et les blocs dans le Stack CMS, crée des ébauches et pré-remplit les versions linguistiques. La rédaction vérifie et valide comme pour toute autre ébauche.
• Données : des questions sur les données derrière la plateforme, posées en langage courant, par exemple : quelles organisations se sont inscrites pour la première fois cette année ? L’assistant interroge les données et établit une analyse sur demande.
• Agents visiteurs : chaque site web sur le stack reçoit une interface MCP publique et un fichier llms.txt. Les recherches IA lisent ainsi les contenus publiés de manière structurée, au lieu de les deviner à partir de la mise en page. L’agent et le modèle de langage sont exploités par l’autre partie, pas par nous.

En interne, nous travaillons déjà ainsi : nos assistants lisent les tickets et la documentation directement dans Jira et Confluence via MCP. Mais un assistant ne répond qu’aussi bien que ses sources le lui permettent. C’est pourquoi nous constituons pour nos projets une documentation qu’il peut interroger de manière fiable, avec une indication de source pour chaque affirmation.

Ce que MCP laisse ouvert

MCP simplifie l’accès. Le standard ne dit pas si un assistant doit utiliser une plateforme, quelles données il peut voir ni qui valide au bout du compte. Nous clarifions ces points avec vous pour chaque plateforme, avant que le premier agent ne se connecte. La page L’IA dans le stack montre concrètement comment un agent travaille dans le système de gestion de contenu.