J'ai commencé à travailler avec le Model Context Protocol (MCP) avant sa sortie officielle dans IBM Maximo Application Suite (MAS) 9.2. J'ai même développé mon propre serveur MCP pour MAS, sujet que j'ai traité dans une série d'articles de blog (Le problème de la communication avec Maximo), afin d'aider à connecter les agents IA à Maximo Manage. Depuis, de nombreuses personnes au sein de la communauté s'y intéressent pour les équipes Maximo.

La plupart des discussions ont porté sur l'arrivée du MCP dans MAS 9.2, mais je souhaite expliquer ici le fonctionnement du serveur MCP, son architecture et la manière dont il permet aux agents IA d'interagir en toute sécurité avec Maximo. J'aborderai les concepts clés et leur importance pour les équipes souhaitant utiliser le MCP dans leurs propres environnements Maximo.

La place du serveur MCP

Si vous n'avez pas lu ma série d'articles et que vous ne savez pas ce qu'est un MCP, je vais faire un bref rappel.

Le serveur MCP se situe entre les agents IA et les API de Maximo Manage. Dans MAS 9.2, il peut servir l'agent Asset Lifecycle Management (ALM) intégré - où ALM désigne les composants IA déployés au sein du service IA, ainsi que d'autres solutions basées sur l'IA telles qu'Insights, Reliability, et plus encore. L'ALM et les ressources associées sont les services IA réels qui interagissent avec Maximo via le MCP, offrant des capacités intelligentes à travers toute la suite.

Cependant, cela ne se limite pas à cet agent intégré. Il peut également prendre en charge des agents externes, y compris les agents appartenant aux clients ou d'autres frameworks d'agents, tels qu'IBM Bob, Claude et OpenAI, à condition qu'ils se connectent via la route et le modèle d'authentification pris en charge.

Pour faire simple : Manage demeure la source de référence, et le serveur MCP sert de passerelle pour les agents vers certaines fonctionnalités de Manage.

Manage expose déjà des spécifications OpenAPI. Dans MAS 9.2, le serveur MCP utilise ces spécifications pour identifier les fonctionnalités disponibles en tant qu'outils d'IA. Manage assure le suivi des définitions d'outils et le serveur MCP interroge Manage pour obtenir les mises à jour. Par défaut, cette interrogation a lieu toutes les 10 minutes, bien que cet intervalle puisse être configuré.

Le processus d'interrogation utilise des ETag. Manage conserve son propre ETag pour les modifications des spécifications d'outils. Le serveur MCP conserve un ETag en mémoire. Lorsque ces valeurs diffèrent, le serveur MCP actualise sa liste d'outils et récupère les spécifications OpenAPI actuelles. C'est ainsi que les ajouts, les mises à jour et les suppressions sont intégrés au catalogue d'outils destiné aux agents.

Les outils utilisent également des définitions d'entrée et de sortie structurées. La présentation mentionne des objets d'entrée et de sortie Pydantic, qui offrent aux agents un schéma plus strict à suivre (j'en ai parlé dans La couche opérationnelle : de la découverte à l'action). Il ne s'agit pas simplement d'un détail d'implémentation. Les agents se comportent mieux lorsqu'ils reçoivent un contrat étroit et explicite plutôt qu'une vaste surface d'API.

La sécurité suit le modèle Maximo

L'un des meilleurs choix de conception ici est que MCP ne crée pas un système de sécurité distinct de celui de Maximo. L'authentification et l'autorisation continuent de suivre les modèles habituels de MAS et de Manage.

Pour le chemin de l'agent intégré, l'interface utilisateur envoie un jeton JWT x-access-token avec la demande d'outil. Le serveur MCP envoie ce jeton au fournisseur d'identité (Core IDP) pour authentification, reçoit le contexte utilisateur, puis transmet l'identifiant utilisateur à Manage lors de l'appel de l'outil. Manage reste le seul à décider si cet utilisateur est autorisé à effectuer l'action.

Cela signifie qu'un utilisateur valide n'est pas automatiquement autorisé à appeler tous les outils MCP. Si un utilisateur ne doit pas être en mesure d'appeler un outil ou d'accéder à une configuration d'IA spécifique, cette restriction s'applique toujours lorsque la requête passe par MCP.

Pour les agents externes, MAS 9.2 prend en charge l'authentification via des clés d'API Maximo ou des jetons JWT. Les clés d'API sont généralement privilégiées pour les intégrations où un agent unique nécessite un ensemble de permissions cohérent. Les jetons JWT sont plus adaptés lorsque l'agent doit agir au nom de différents utilisateurs.

La communication interne entre MCP, Manage et Core utilise des certificats MAS. L'idée n'est pas que MCP contourne les contrôles de l'entreprise. Il offre aux agents un accès à Maximo tout en maintenant les contrôles habituels en place.

Les agents externes font partie de la conception

L'approche « Apportez votre propre agent » (Bring Your Own Agent) est l'un des aspects les plus intéressants de cette version.

Certains clients utiliseront l'agent ALM intégré d'IBM. D'autres ont déjà investi dans leurs propres agents ou souhaitent adopter un modèle hybride où les agents IBM et les agents externes interagissent avec Maximo. Le serveur MCP prend en charge ce modèle élargi, ce qui est très prometteur !

Pour connecter un agent externe, le client a besoin de deux éléments : la route MCP exposée en externe et une méthode d'authentification. La route est automatiquement exposée via OpenShift, et l'agent envoie soit une clé d'API Maximo, soit un en-tête x-access-token, selon le mode d'authentification choisi.

Cela signifie que les fonctionnalités de Maximo peuvent être mises à la disposition d'agents externes via un protocole standard de l'industrie plutôt que par une intégration ponctuelle. Pour les clients disposant déjà de plateformes d'IA, c'est probablement l'un des aspects les plus pratiques de MAS 9.2. Ils peuvent conserver leur stratégie d'agent tout en continuant à utiliser Maximo comme système d'enregistrement gouverné.

Les outils MCP sont des API, mais toutes les API ne sont pas des outils

Un aspect intéressant de cette conception est que tous les outils MCP dans Manage sont des API REST, mais que toutes les API Maximo ne sont pas des outils MCP.

Cette distinction est importante. Maximo possède une surface d'API très étendue. Donner accès à l'intégralité de cette surface à un agent serait coûteux, complexe et risqué. L'agent aurait un schéma trop vaste à traiter, trop de chemins possibles et trop de risques de faire des choix inappropriés.

Les outils MCP constituent une couche plus sélective. Ils exposent les fonctionnalités destinées aux agents, accompagnées d'une description, d'un schéma et d'annotations qui aident l'agent à déterminer quand et comment les appeler.

MAS 9.2 organise les outils MCP de Manage en cinq grandes catégories.

Outils de configuration IA

Les outils de configuration IA reposent sur les configurations IA activées dans Manage. Les types d'inférence pris en charge par les services IA installés incluent la classification, la similarité, l'assistant, la recherche documentaire et l'analyse de conditions.

La fonctionnalité d'assistant est particulièrement intéressante car elle peut servir d'outil d'amorçage. Elle peut interpréter une requête en langage naturel et déduire la structure de l'appel API REST correspondant. Dans certains cas, ce flux est divisé en deux outils : l'un pour déduire la requête API et l'autre pour l'exécuter. Cette séparation permet à l'agent de montrer à l'utilisateur ce qu'il s'apprête à faire avant de passer à l'étape suivante.

Les outils de configuration IA utilisent une liste blanche gérée dans la table MAXAICFGTOOL. Une fois qu'une configuration IA prise en charge est activée, elle peut devenir automatiquement disponible en tant qu'outil. Cela diffère de plusieurs autres types d'outils, pour lesquels une étape de déploiement explicite est nécessaire.

Les descriptions sont ici cruciales. La description de la configuration IA devient celle de l'outil, et l'agent utilise ce contenu pour décider si l'outil est adapté à la demande de l'utilisateur. Une description vague complique la planification, tandis qu'une description précise offre un meilleur guidage à l'agent.

Outils de structure d'objet

Les structures d'objet sont puissantes, mais leurs schémas peuvent être gigantesques. Une structure d'objet de type ordre de travail, actif ou emplacement peut contenir de nombreuses opérations et champs. Transmettre l'intégralité de ce schéma à un agent n'est généralement pas la méthode la plus adaptée. J'ai moi-même rencontré de nombreux problèmes de fenêtre de contexte lors de la création de mon propre serveur MCP.

Les outils OS résolvent ce problème en extrayant des outils plus ciblés à partir du modèle de structure d'objet global. Au lieu d'exposer toutes les capacités d'une structure d'objet d'actif, un outil OS peut se concentrer sur une opération précise, comme le déplacement d'un actif ou la déclaration d'un temps d'arrêt.

Outils de script

Les scripts d'automatisation sont l'un des moyens les plus courants pour les clients et les partenaires d'étendre Maximo. MAS 9.2 intègre ce modèle d'extension au sein du modèle MCP.

Les outils de script suivent la même approche générale que les scripts pour les API REST. Les variables de script littérales deviennent le schéma de requête. Un schéma de réponse peut être ajouté lorsque le script renvoie une sortie structurée, en utilisant le paramètre responseBody. Seuls les scripts actifs sont déployés en tant qu'outils MCP.  

Outils de workflow

Les outils de workflow offrent aux équipes un moyen plus graphique d'exposer les flux métier aux agents. C'est utile dans les situations Maximo où des actions importantes sont déjà modélisées sous forme de workflows plutôt que sous forme de code.

La prise en charge concerne uniquement les workflows non interactifs. Cela signifie des workflows composés de nœuds, de nœuds de condition et d'actions. Les workflows qui dépendent de boîtes de dialogue contextuelles ou de questions interactives ne font pas partie de cette première version.

Le schéma de requête est simple : un élément href qui identifie l'enregistrement sur lequel le workflow doit s'exécuter. Comme pour les scripts et les outils OS, cet enregistrement peut provenir d'une requête précédente de l'assistant.

Les workflows actifs et activés peuvent être déployés en tant qu'outils MCP, et leurs descriptions aident l'agent à comprendre quand les utiliser.

Outils de route API

Le dernier type d'outil est celui des outils de route API. Il s'agit d'outils fournis par IBM, principalement destinés à des fonctionnalités d'administration ou de niveau système plutôt qu'à une logique métier définie par le client.

L'outil de schéma API en est un exemple. D'autres outils de ce type pourraient être développés par IBM en tant qu'outils système, comme un agent capable de répondre à des questions sur les produits installés, les modules complémentaires, les solutions sectorielles, les langues ou les informations de mise à niveau.

Cette catégorie ne dispose pas d'interface utilisateur pour la configuration par les clients. Les clients et les partenaires disposent déjà d'outils de script, de workflow et de structure d'objet pour leurs propres extensions. Les outils de route API doivent être considérés comme des briques de base fournies par IBM pour des fonctionnalités opérant en arrière-plan.

Un impératif pour tout type d'outil

Quel que soit le type d'outil, le constat est le même : la description de l'outil fait office de manuel pour l'agent.

Cela semble simple, mais c'est probablement là que se jouera le succès ou l'échec de nombreuses implémentations. Un agent n'a pas seulement besoin d'un point de terminaison. Il doit savoir à quoi sert l'outil, quand l'utiliser, quelles informations sont nécessaires et quelles variantes il prend en charge.

Il est important de définir les annotations avec soin. Les administrateurs peuvent marquer un outil comme étant en lecture seule ou destructif, et l'agent peut utiliser cette information avant de décider de la marche à suivre. Si un outil se contente de récupérer des données, l'agent peut le considérer comme peu risqué. Si l'outil modifie un enregistrement, lance un flux de travail ou exécute un script, l'agent a une bonne raison de faire une pause et de demander confirmation. L'annotation ne contrôlera pas tous les agents externes, mais elle fournit aux agents bien conçus un avertissement clair avant toute action.

C'est là que l'expérience sur Maximo reste déterminante. Les meilleurs catalogues d'outils MCP ne seront pas ceux qui exposent tout, mais ceux qui sélectionnent les bonnes opérations, leur attribuent des schémas précis et rédigent des descriptions qui ressemblent à des instructions émanant d'une personne maîtrisant parfaitement le processus.

Pourquoi est-ce utile pour les clients Maximo ?

Le serveur MCP dans MAS 9.2 ne se limite pas à l'ajout d'IA dans Maximo. Il s'agit d'offrir aux agents IA un modèle opérationnel contrôlé au sein même de Maximo.

Sans MCP, un client souhaitant connecter un agent à Maximo doit décider quelle part de l'API exposer, comment décrire chaque action, comment gérer l'authentification, comment maintenir à jour les définitions des outils et comment empêcher l'agent d'effectuer des opérations inappropriées. MCP apporte une structure plus standardisée à ces préoccupations.

Pour les équipes utilisant déjà des configurations IA, le processus d'exposition des outils peut être automatisé dès lors que la configuration est active et prise en charge. Pour les équipes disposant de personnalisations Maximo avancées, les scripts et les flux de travail peuvent devenir des outils appelables par l'agent sans avoir à abandonner les modèles d'extension habituels. Pour les équipes développant leurs propres agents, le modèle d'accès externe et d'authentification par clé API ou JWT facilite l'intégration de Maximo dans une architecture IA plus large.

Le résultat est une passerelle pratique entre la logique métier existante de Maximo et la nouvelle couche d'agents. Cela ne rend pas la gouvernance moins importante ; au contraire, cela la rend plus visible. Les descriptions d'outils, les schémas, les autorisations et les annotations deviennent partie intégrante de la planification du travail de l'agent.

C'est la bonne direction. Les agents d'entreprise ont besoin de plus que de simples réponses. Ils ont besoin d'actions délimitées, de contrats clairs et d'un accès qui respecte le système d'enregistrement. Le serveur MCP de MAS 9.2 offre aux équipes Maximo une base solide pour ce type de travail agentique.

MORE Community Logo
Live from the MORE community

Your Maximo questions probably already have answers

See what Maximo users are asking, answering, and solving right now.

Unlock the Ultimate Guide to IBM Maximo Application Suite (MAS)

Discover everything you need to know to modernize your asset management strategy.

Inside, you’ll learn:

  • What’s new in IBM Maximo Application Suite 9.0
  • Key differences between Maximo 7.6 and MAS
  • How AppPoints and OpenShift change the game
  • Industry use cases across energy, manufacturing, and transportation
  • Step-by-step guidance for upgrading and migration readiness
Cover of 'The Ultimate Guide to MAS Maximo Application Suite' by Naviam featuring a man in a yellow construction helmet and safety vest holding a tablet.
×

ActiveG, BPD Zenith, EAM Swiss, InterPro Solutions, Lexco, Peacock Engineering, Projetech, Sharptree, and ZNAPZ have united under one brand: Naviam.

You’ll be redirected to the most relevant page at Naviam.io in a few seconds — or you can go now.

Read Press Release