MCP : un accélérateur pour automatiser les processus métier complexes

L'intelligence artificielle est aujourd'hui capable d'analyser des documents, de comprendre des images ou de générer du code. Pourtant, dans de nombreux projets, ces capacités ne suffisent pas à automatiser un processus métier de bout en bout.

C'est précisément le constat fait lors d'un projet d'automatisation de la mise à jour de schémas techniques.

Le cas d'usage est bien connu des bureaux d'études : lorsqu'une installation est réalisée sur le terrain, il est fréquent que certains éléments diffèrent du plan initial. Les équipes annotent alors les modifications directement sur les schémas, généralement en rouge, avant de transmettre les documents au bureau d'études, qui doit reprendre une à une toutes les annotations pour mettre à jour les fichiers d'origine.

Cette étape est essentielle : les documents livrés au client doivent refléter fidèlement la réalité du terrain. Mais elle est aussi particulièrement chronophage. Selon les équipes ayant porté le projet, cette mise à jour pouvait mobiliser un collaborateur pendant près d'une semaine sur un dossier. Un travail minutieux, répétitif et peu valorisant, qui mobilise des profils dont l'expertise est attendue sur des tâches à plus forte valeur ajoutée.

‍

Une première version qui fonctionnait déjà

L'application développée importe les schémas annotés et les fichiers techniques correspondants, puis laisse l'IA rapprocher les annotations des bons documents, identifier les modifications demandées et préparer les changements. Cette première version s'appuyait sur des modèles de vision et des appels à un LLM, sans architecture agentique construite.

Les résultats étaient encourageants. En revanche, dès qu'il fallait aller au-delà de l'analyse pour automatiser réellement le processus, les limites apparaissaient rapidement. Comprendre une modification est une chose ; l'exécuter dans le logiciel de conception en est une autre.

Le vrai levier : connecter l'IA au logiciel métier

C'est à ce stade que l'équipe a intégré un serveur MCP (Model Context Protocol), permettant à l'application d'utiliser directement les fonctions exposées par le logiciel métier.

Le changement a été implémenté en quelques semaines, sans modifier le modèle de langage sous-jacent. Selon les équipes ayant porté le projet, l'application est devenue nettement plus performante dès l'intégration du MCP.

Le principal gain n'est donc pas venu d'un modèle plus capable, mais de sa capacité à agir directement dans l'environnement de travail existant, plutôt que de produire une recommandation qu'un utilisateur devait ensuite appliquer manuellement.

La leçon qu'on n'attendait pas : arrêter de sur-concevoir les outils

L'enseignement le plus contre-intuitif du projet ne porte pas sur l'intégration du MCP, mais sur la manière de concevoir les outils mis à disposition de l'agent.

L'équipe avait d'abord développé des fonctions très spécifiques au métier : des commandes dédiées permettant, par exemple, d'insérer directement certains composants techniques. Sur le papier, cette approche semblait la plus pertinente. Dans les faits, elle s'est révélée moins efficace que prévu.

Les meilleures performances ont été obtenues en laissant l'agent utiliser les fonctions génériques déjà exposées par le MCP — insérer une ligne, créer une forme — plutôt que des commandes conçues pour un cas d'usage précis.

Le retour d'expérience est clair : lorsqu'une primitive générique existe déjà, il est souvent préférable de l'utiliser plutôt que de reconstruire un outil métier spécifique. Les primitives génériques sont plus simples à combiner, plus robustes et évitent de multiplier les cas particuliers que l'agent doit apprendre à gérer.

Le modèle raisonne, le framework agit

Le projet rappelle également une distinction essentielle dans les architectures agentiques : choisir un LLM ne revient pas à choisir un système agentique.

Le modèle produit le raisonnement : il comprend, interprète, propose et décide de l'action à réaliser. Le framework agentique, lui, orchestre les différentes étapes : il pilote le raisonnement, sélectionne les outils, gère leur enchaînement et supervise leur exécution.

Sur ce projet, cette orchestration reposait sur le SDK de Claude, tandis que le MCP permettait à l'agent d'interagir directement avec le logiciel métier.

Cette distinction est importante. Lorsque les performances d'un agent plafonnent, la première question n'est pas forcément de changer de modèle de langage. Il est souvent plus pertinent d'examiner les outils mis à disposition de l'agent, leur orchestration et les règles qui gouvernent leur utilisation.

‍