MCP : le protocole qui permet à une IA de parler à vos logiciels

Par Nicolas Peter · 9 septembre 2026 · vulgarisation, technique, IA

Il existe un sujet technique dont on parle beaucoup en anglais, presque pas en français, et qui décide pourtant de la façon dont l’intelligence artificielle s’installera — ou non — dans les outils de votre entreprise.

Il s’appelle MCP, pour Model Context Protocol. C’est une convention qui décrit comment un modèle d’IA peut se brancher sur un logiciel pour y lire des informations et y déclencher des actions.

Ce n’est pas un produit et cela ne s’achète pas. C’est une grammaire commune. Et comme toutes les grammaires communes, son intérêt ne vient pas de sa sophistication mais du nombre de gens qui la parlent.

Le problème qu’il résout

Un modèle de langage, seul, ne sait rien de votre entreprise. Il ne connaît ni vos clients, ni vos stocks, ni vos factures. Pour être utile dans un process, il faut lui donner accès à vos outils.

Jusqu’à présent, chaque accès se construisait à la main. Vous vouliez qu’un assistant consulte votre CRM ? Il fallait écrire le pont. Votre outil de facturation ? Un autre pont. Votre messagerie ? Un troisième. Et si vous changiez de modèle d’IA, tout était à refaire — parce que chaque fournisseur avait sa propre façon de décrire les outils disponibles.

C’est le problème classique du M × N : M modèles, N logiciels, et M × N ponts à construire et à maintenir.

MCP transforme cela en M + N. Chaque logiciel expose ses capacités une fois, dans un format standard. Chaque modèle sait lire ce format. Le pont n’a plus à être écrit pour chaque combinaison.

Pour une entreprise, la conséquence est directe : vous n’êtes plus lié au fournisseur d’IA que vous avez choisi l’an dernier. Si un autre modèle devient meilleur ou moins cher, vos connexions restent valables.

Ce que la révision de juillet 2026 a changé

La spécification a connu une évolution importante le 28 juillet 2026, et elle va dans un sens qui intéresse directement les entreprises.

Le protocole est passé d’une architecture avec état — une connexion ouverte entre le modèle et l’outil, maintenue pendant toute la session — à une architecture sans état, où chaque requête voyage seule en transportant tout ce dont elle a besoin.

Cela paraît ésotérique. Ce ne l’est pas. Une connexion permanente est difficile à faire passer derrière un pare-feu d’entreprise, difficile à répartir sur plusieurs serveurs, et difficile à auditer. Des requêtes indépendantes se comportent comme du trafic web ordinaire : on sait les router, les filtrer, les tracer et les répartir.

Trois autres évolutions vont dans la même direction.

L’authentification d’entreprise est prise en charge de façon formelle, avec une migration vers des mécanismes d’identité adaptés aux organisations plutôt qu’aux développeurs isolés.

Le routage par en-têtes permet à une passerelle de savoir ce qu’une requête demande sans avoir à en ouvrir le contenu — ce qui est la condition pour poser des règles de sécurité et des journaux d’audit.

La mise en cache est explicite : une réponse peut indiquer combien de temps elle reste valable, ce qui évite d’interroger un système métier vingt fois pour la même information.

La feuille de route publiée pour 2026 confirme la priorité : audit, authentification unique, comportement des passerelles, portabilité des configurations. Ce sont exactement les sujets que pose une direction informatique, pas ceux que pose un développeur qui bricole.

Une politique de dépréciation a également été posée : douze mois minimum avant qu’une fonctionnalité retirée cesse d’être supportée. C’est un détail, et c’est un signe de maturité.

Pourquoi ça vous concerne, même si vous n’écrirez jamais une ligne de code

Trois raisons.

La première : vous n’êtes pas enfermé. C’est la question que nous posons systématiquement avant de choisir une brique technique. Un standard ouvert signifie que vous pouvez changer de fournisseur sans tout reconstruire. C’est rare, et ça vaut la peine d’être exigé.

La deuxième : vos logiciels métier vont s’y mettre. De plus en plus d’éditeurs exposent leurs fonctions dans ce format. Concrètement, cela veut dire que brancher une automatisation intelligente sur votre outil de gestion coûtera de moins en moins cher, parce que le travail d’interface aura déjà été fait par l’éditeur.

La troisième, et c’est la plus importante : le sujet devient une question de gouvernance. Une fois qu’un modèle peut lire vos données et déclencher des actions, la question n’est plus technique — elle est : qui a le droit de faire quoi, et comment le sait-on ? C’est exactement ce que la dernière révision cherche à outiller.

Ce que nous en faisons

Nous utilisons ce protocole pour relier nos propres outils. Cela ne change rien à notre position de fond, qui reste la même depuis toujours : un standard ouvert est préférable à une intégration propriétaire, à qualité égale.

Mais nous ne le mettons pas partout. Pour un flux simple et stable — recopier une information d’un outil à un autre —, une connexion directe reste plus simple, plus rapide et moins chère. MCP prend son intérêt quand un modèle doit décider quoi consulter, pas quand le chemin est écrit d’avance.

C’est la même règle que pour les agents : la souplesse a un prix, et on ne la paie que lorsqu’on en a besoin.

À surveiller

Le protocole évolue vite, et sa révision de juillet a introduit des changements de fond. C’est le signe d’un standard jeune.

Pour une PME, cela ne justifie pas d’attendre — les usages courants sont stables — mais cela justifie une précaution que nous appliquons à toute dépendance externe : savoir ce qui se passe si la brique change. Un flux bien construit isole cette dépendance à un seul endroit, pour que sa mise à jour ne se propage pas partout.