LLM et MCP : brancher l’IA sur le SI, pas à côté

Beaucoup d’ETI ont « mis un LLM ». En pratique : un onglet ChatGPT, parfois un copilote sur la GED. Les gens s’en servent pour rédiger un mail. Pas pour finir un dossier.

Le trou, ce n’est pas le modèle. C’est qu’il n’a pas les mains dans le SI. Alors on recopie un numéro de contrat, on attend, on recolle la réponse dans l’outil métier. Deux minutes ici, cinq là. Au bout d’une semaine, on a laissé tomber.

MCP (Model Context Protocol) sert à ça : donner au LLM des outils, pas un roman. Un outil « lire le stock ». Un outil « ouvrir un ticket ». Un outil « chercher dans la base documentaire ». Chaque outil a un droit. Le modèle demande. Le SI répond. Ou refuse.

Ce n’est pas magique. C’est de l’intégration. Les développeurs connaissent déjà ça, sous d’autres noms.

Deux chaînes, pas la même

1. Métier
2. Chat LLM
3. Copier-coller
4. SI (ERP, tickets, GED)

La donnée voyage dans le presse-papier. Pas de droit, pas de journal, pas d’hébergement décidé.

1. Métier
2. LLM
3. MCP
4. Outils bornés
5. SI

Lecture, parfois écriture, toujours un scope. On sait qui a appelé quoi.

Le RAG (chercher dans des documents) reste utile. Il ne remplace pas un outil. Un contrat trouvé dans une GED, ce n’est pas un mouvement de stock. Les deux se cumulent. On mélange souvent les deux dans la même démo. Puis on s’étonne que « l’IA hallucine un stock ». Elle n’a jamais vu le stock. Elle a inventé.

Ce que MCP change pour un développeur

Les équipes ont passé un an à coller des API autour de tel ou tel modèle. Un plugin Copilot. Un GPT custom. Un webhook maison. Au changement d’éditeur, on recommence.

MCP, c’est un contrat d’outils. On expose une fois : nom, entrée, sortie, droit. Le client LLM — Claude, un outil interne, demain un autre — s’y branche. Le développeur ne « fait pas de l’IA ». Il fait ce qu’il fait déjà : une façade propre sur le SI, avec auth et traces.

C’est pour ça que ça les intéresse, ceux qui ont déjà repris un projet pourri. Pas le slide. Le filet.

• Lire Stock, contrat, ticket ouvert, dernier déploiement. Souvent le premier palier. Le moins dangereux.
• Agir Créer un ticket, brouillon de réponse, demande d’approbation. Rarement « écrire dans l’ERP » du premier coup.
• Tracer Qui a demandé l’outil, à quelle heure, avec quel identifiant. Sans ça, le RSSI arrête le sujet. À raison.

Trois règles qu’on pose tôt, sinon ça dérape :

1. Pas d’outil « faire tout ». Un verbe, un objet.
2. Le LLM n’a pas le mot de passe SAP. Il a un compte de service, limité.
3. L’humain valide ce qui sort du SI et ce qui y rentre. Surtout l’écriture.

Trois cas, sans nommer les clients

Les dossiers ci-dessous sont anonymisés. Sur un sujet sensible, un accord de confidentialité se signe avant d’ouvrir les accès.

Support, mutuelle — le mail qui n’en finissait plus

Le métier rédigeait des réponses à partir de trois bases : un wiki, des PDF, l’outil de tickets. Un copilote « sur la doc » existait déjà. Il citait le mauvais avenant. Normal : pas le contrat en vigueur, juste le PDF le plus proche.

Ce qu’on a branché :

• un outil MCP pour lire le contrat actif (identifiant adhérent, pas une recherche floue) ;
• un outil pour lister les tickets ouverts du même dossier ;
• un outil pour déposer un brouillon dans le ticketing, pas l’envoyer tout seul.

Le LLM rédige. L’agent relit. Il n’invente plus le numéro d’avenant : il l’a lu. Le développeur n’a pas « entraîné un modèle ». Il a exposé trois appels, avec le même annuaire que le reste du SI. Hébergement du modèle en région européenne. Les outils, eux, n’ont jamais quitté le réseau interne.

Résultat, mesuré bêtement : moins d’allers-retours « vous n’avez pas le bon avenant ». Pas une révolution. Un dossier qui avance.

Industrie — le stock, sans donner les clés de l’ERP

À l’atelier, on appelait la logistique pour un SKU. La logistique ouvrait l’ERP. Dix minutes, parfois plus si la personne était en réunion.

La tentation, côté projet : « on connecte l’IA à SAP, elle saura ». Non. Un LLM qui écrit dans un ERP, c’est un incident en retard.

Là, un seul outil, lecture : stock par référence, dépôt, délai. Compte de service lecture seule. Journal des appels. Le modèle reformule pour l’atelier (« 12 pièces à Gennevilliers, prochaine entrée jeudi »). Il ne lance pas d’ordre de transfert.

Le développeur a tenu bon sur le refus d’écriture. C’est souvent le vrai livrable.

Éditeur logiciel — la garde, sans SSH pour tout le monde

Une équipe petite. Les incidents de nuit : on se passait le post-mortem à l’oral. Les juniors n’avaient pas les accès prod, donc ils attendaient.

Outils MCP, encore une fois bornés : derniers logs d’un service, dernier déploiement, état des sondes. Pas de shell. Pas de secret. Le LLM aide à trier (« ça ressemble à la bascule de 23 h, timeout sur l’API X »). L’astreinte confirme.

Intérêt pour les développeurs, ici, c’est eux les utilisateurs. Ils ont arrêté de bricoler un bot Slack qui parsait des logs avec une regex oubliée. Un protocole, des droits, un journal. Ils peuvent dormir un peu mieux. Un peu.

Où ça casse, si on va trop vite

On a vu le même film que sur les PoC IA de 2024.

Le métier veut « un assistant qui fait tout ». On lui pose vingt outils. Personne ne sait lequel a raison. Les traces sont illisibles. Un outil écrit dans le SI « pour aller plus vite ». Un jour, ça écrit trop vite.

Autre classique : tout envoyer dans un LLM public, y compris un extrait de contrat. Le MCP n’interdit pas ça tout seul. Le cadrage si. Région, quoi sort, quoi reste. En France, cette conversation arrive au premier comité, pas à la recette.

Dernier point, un peu ingrat : sans propriétaire métier, MCP ne sauve rien. Un outil « créer un ticket » que personne n’ouvre, c’est un chatbot de plus. Un FDE à disposition sert souvent à franchir ce trou — rester jusqu’à ce que les trois outils soient dans le quotidien, puis transmettre.

Une mise en place sans théâtre

On ne commence pas par « la plateforme IA ». On commence par un verbe.

1. Un cas — un dossier type, pas « tout le support ».
2. Deux ou trois outils — lire d’abord. Écrire plus tard, ou jamais.
3. Un LLM — région et coût d’inférence écrits. Pas un compte perso.
4. Un journal — qui a appelé, quoi, quand.
5. Une semaine de vrai usage — si personne ne s’en sert, on coupe, on ne « enrichit » pas.

C’est le même réflexe que sur une reprise ou de l’IA métier : périmètre gelé, recette, run. MCP n’est pas une exception. C’est une façon propre de brancher le modèle.

Les développeurs, dans ce schéma, ne sont pas une variable d’ajustement. Ce sont ceux qui savent quel appel est sûr, lequel est une mine. Les laisser hors de la pièce, et ne parler qu’au métier et au modèle, ça donne des démos. Pas des outils.

Questions courantes

Faut-il MCP si on a déjà un RAG ?

Si l’usage s’arrête à « trouve-moi le paragraphe », non, pas tout de suite. Si quelqu’un doit ensuite faire quelque chose dans un outil, oui. Sinon le copier-coller revient.

Ça marche avec n’importe quel LLM ?

L’intérêt du protocole, c’est justement de ne pas marier le SI à un seul chat. Encore faut-il que le client LLM parle MCP, et que vos outils tiennent debout. Le modèle se change. Les outils, moins souvent.

Combien de temps pour un premier usage ?

Un process étroit, des accès propres, deux outils en lecture : parfois une poignée de jours. Un SI sans API, sans authentification unique, sans journal : davantage. On le dit au diagnostic, pas après.

Si le sujet est un PoC LLM déjà là, qui n’entre pas dans le SI, un diagnostic sert à voir s’il manque un modèle plus gros — rarement — ou trois outils et quelqu’un pour les faire vivre.