La couche de raisonnement : Les grands modèles de langage (LLM), les agents et le MCP

Guide pratique destiné aux intégrateurs de systèmes, aux équipementiers et aux ingénieurs en automatisation – 2e partie

En partenariat avec Thomas Strigl, PDG de realvirtual.io

À propos de l'auteur : Thomas Strigl est PDG de realvirtual.io et possède plus de 18 ans d'expérience dans le domaine des logiciels de simulation et d'automatisation.

Cliquez ici pour accéder à la première partie de cette série d'e-books, « De la visualisation à l'action » : Unity, les systèmes d'information des machines, les agents d'IA et le Digital Twin industriel.

La première partie de cette série d'e-books a présenté les fondements architecturaux d'un système moderne d'informations sur les machines : la convergence des signaux en temps réel des machines, du contexte MES, de la documentation structurée et des interfaces spatiales en 3D au sein d'une interface opérationnelle unique. Elle a également examiné comment le nouveau règlement européen sur les machines et les nouvelles normes, telles que l'Asset Administration Shell (AAS), orientent la documentation des machines vers des formats structurés et lisibles par machine. Ce sont précisément ces fondements — données liées aux composants, documentation versionnée et état contextualisé des machines — qui permettent aux agents d'IA et aux grands modèles linguistiques d'être utilisés dans des environnements industriels.

Ce deuxième et dernier volet de cette série d'e-books s'appuie sur cette architecture pour examiner la « couche de base » : comment les systèmes d'IA peuvent accéder à un contexte opérationnel et documentaire fiable, et comment des protocoles tels que le MCP s'intègrent dans la pile du système d'information des machines.

Le problème de mise à la terre

Une première approche courante pour intégrer des modèles linguistiques de grande envergure dans des contextes industriels consiste à ajouter un chatbot à un système existant — un site web, un portail d'assistance ou une HMI. Dans la pratique, cette approche présente des limites.

À lui seul, un modèle linguistique n'a pas accès à l'état actuel de la machine, à l'ordre de fabrication en cours ni à la documentation spécifique du fabricant. Sans ce contexte, ses réponses s'appuient sur des données d'entraînement, qui peuvent être génériques, voire obsolètes, et qui ont peu de chances de prendre en compte la machine en question.

C'est ce qu'on appelle généralement le problème de mise à la terre. Pour qu'un modèle d'apprentissage profond (LLM) puisse produire des résultats utiles dans un contexte industriel, il a généralement besoin d'un accès structuré à trois éléments : l'état en temps réel de la machine, le contexte opérationnel pertinent et la documentation du fabricant.

L'architecture à quatre couches décrite dans la première partie répond assez bien à cette exigence. Les signaux indiquent l'état actuel. Le MES fournit le contexte opérationnel. La documentation constitue une source d'information faisant autorité. La scène 3D offre le cadre spatial dans lequel tout cela peut être présenté.

Le MCP en tant que modèle d'intégration

Le protocole MCP (Model Context Protocol) est une norme ouverte qui définit comment les outils et les sources de données peuvent être mis à la disposition des modèles linguistiques de manière cohérente. Il définit la manière dont un client se connecte à un serveur, la manière dont le serveur fait connaître ses capacités, et la manière dont le modèle les utilise. Bien que le MCP ait été initialement conçu pour les outils de développement généraux, ce modèle s'adapte assez bien à l'intégration industrielle, où le problème sous-jacent — fournir un accès cohérent à un ensemble hétérogène de systèmes sous-jacents — est similaire.

La plupart des usines combinent des automates programmables (PLC) de différents fournisseurs, un système MES, une plateforme de gestion documentaire et un historien. En l'absence d'une couche standard, chaque nouveau client doit être intégré individuellement à chacun de ces systèmes. Avec MCP, chaque système sous-jacent peut être intégré une seule fois dans un serveur MCP et mis à disposition via une interface uniforme accessible à tout client compatible.

Dans le cadre d'un Digital Twin industriel, trois catégories de serveurs MCP revêtent une importance particulière :

• Un serveur d'état des machines qui fournit en temps réel les valeurs des signaux, les états d'alarme, les positions des variateurs et l'historique récent — s'appuyant sur la couche de signaux existante (OPC UA, Beckhoff ADS, MQTT, S7 ou une couche de streaming basée sur WebSocket).
• Un serveur MES qui met à disposition les commandes, les lots, les indicateurs clés de performance (KPI) et les enregistrements qualité, via des API REST, des intermédiaires de messagerie ou des requêtes directes à la base de données.
• Un serveur de documentation qui met à disposition l'ensemble structuré de la documentation numérique — notices d'utilisation, schémas, déclarations de conformité, versions logicielles, procédures de maintenance — consultable et accessible par référence de composant, code d'erreur ou en langage naturel.

Un modèle LLM connecté à ces trois serveurs dispose d'une base solide pour fournir des réponses pertinentes. Pour répondre à une question telle que « Pourquoi la ligne 3 s'est-elle arrêtée ? », il suffit de consulter l'état des alarmes, d'identifier le composant concerné, de consulter la section correspondante du manuel consacrée au dépannage, puis de présenter le résultat en mettant en évidence le composant concerné dans l'HMI 3D. Le résultat s'appuie sur des systèmes réels plutôt que sur les données d'entraînement du modèle.

L'architecture de référence de la section 6, décrite dans la première partie de cette série d'e-books, s'applique directement à cette couche. Les services de signalisation, MES et de documentation qui y sont décrits sont gérés par des serveurs MCP qui les mettent à disposition via une interface uniforme. Un LLM ou un moteur d'exécution d'agent — fonctionnant en local, sur un serveur en périphérie ou dans un cloud privé, selon la politique de données du client — se connecte à ces serveurs. Les réponses qui en découlent s'appuient sur la situation actuelle, le contexte actuel et des documents faisant autorité.

L'HMI 3D se situe au sommet de la pile et s'adresse à deux types d'utilisateurs : l'opérateur et les outils basés sur l'IA. Les outils d'IA l'utilisent à la fois comme surface de présentation (pour mettre en évidence les éléments pertinents pour une réponse) et comme surface de confirmation (pour afficher les actions proposées en vue d'une vérification humaine). L'HMI est développée dans Unity — ce qui inclut l'importation CAO, la cinématique, le mappage des signaux et les métadonnées des composants que le moteur d'exécution utilisera — et est fournie soit sous forme de version native Unity pour ordinateur de bureau, tablette, RA/VR ou PC industriel, soit sous forme d'HMI 3D accessible via un navigateur, basée sur Three.js pour les déploiements WebGL. Le même fichier de scène créé dans Unity, exporté au format GLB avec des identifiants de composants cohérents, convient aux deux cibles de diffusion.

L'environnement C# ouvert d'Unity prend en charge l'inférence en direct, via Sentis et ONNX, comme expliqué dans l'e-book « Design, Simulate, Deploy » : Pourquoi l'uniformité est essentielle pour les Digital Twins industriels — et pour servir d'interface avec les environnements d'exécution externes. Pour la plupart des projets d'intégration, séparer l'environnement d'exécution de l'agent de l'HMI constitue l'approche la plus simple, MCP servant de limite d'intégration.

Documentation et mise à la terre

On constate un chevauchement notable entre les orientations réglementaires et les exigences techniques relatives aux résultats des modèles de langage de grande échelle (LLM) ancrés dans la réalité.

Historiquement, la documentation a toujours été considérée comme un coût lié à la prestation de services : elle est produite parce qu’elle est obligatoire, mais on y a rarement recours. En vertu du règlement (UE) n° 2023/1230, la documentation peut être fournie sous forme numérique ; dans ce cas, elle doit être structurée, accessible en ligne et faire l'objet d'une gestion du cycle de vie pendant au moins dix ans ou pendant toute la durée de vie de la machine — généralement cette dernière, étant donné que les machines industrielles sont rarement mises hors service au terme de la période minimale prévue par la réglementation. Une fois présentée sous cette forme, cette documentation présente également des caractéristiques qui en font un support idéal pour les modèles linguistiques : elle est structurée, identifiable par composant ou code d'erreur, et bénéficie de l'autorité du constructeur.

Un LLM basé sur la documentation réellement fournie par le fabricant est moins susceptible de générer des procédures inexactes ou des références de pièces inventées, car ses réponses peuvent être rattachées à des sections spécifiques de la documentation. Cela pourrait également s'avérer pertinent pour la traçabilité et pour l'intégration avec les obligations en matière de journalisation et d'enregistrement des décisions que le règlement impose pour les logiciels liés à la sécurité.

Pour les intégrateurs, on constate concrètement que le travail de préparation d'une documentation numérique structurée — qui sera de toute façon nécessaire — permet également de produire un support pouvant servir de base aux outils basés sur les grands modèles de langage (LLM). Ces deux initiatives se complètent plutôt que de se faire concurrence pour obtenir des budgets distincts.

Les grands modèles de langage (LLM) : des accélérateurs de développement

Réduire les coûts liés aux travaux d'intégration

Jusqu'à présent, la discussion a présenté les grands modèles de langage (LLM) comme des consommateurs de données de Digital Twins — des outils qui analysent l'état en temps réel, consultent la documentation et répondent aux opérateurs. Il existe un deuxième rôle qui a des conséquences plus directes sur la rentabilité des intégrateurs : Les grands modèles de langage (LLM) comme catalyseurs du développement du jumeau numérique lui-même.

La mise en place d'un Digital Twin intégré nécessite un travail considérable, qui, bien que simple sur le plan technique, prend beaucoup de temps. Code d'adaptation entre la couche de signal et la scène 3D. Clients REST ou OPC UA pour le MES. Mise en correspondance des variables de l'automate programmable et des identifiants des composants. Graphiques, tableaux de bord et petits composants d'interface utilisateur spécifiques à un projet dans l'HMI. Travail sur le schéma visant à harmoniser les sections de la documentation avec les éléments de la scène. Aucune de ces tâches n'est particulièrement difficile ; elles sont manuelles, répétitives et propres à chaque projet.

Les outils de codage assistés par le LLM peuvent réduire la charge de travail liée à ce type de tâches : génération d'adaptateurs pour une nouvelle API MES, création de composants graphiques, et établissement de correspondances entre les tables de signaux et les hiérarchies cinématiques. Cela ne signifie pas que les intégrateurs cessent d'écrire du code, mais que les tâches d'intégration courantes prennent moins de temps. Cela revêt une importance particulière dans le contexte industriel, car la multitude de petits morceaux de code de liaison spécifiques à chaque projet a toujours été l'une des principales raisons pour lesquelles les projets d'intégration sont coûteux.

Pourquoi les interfaces normalisées sont-elles importantes ?

Cet effet s'accentue lorsque les interfaces sous-jacentes sont normalisées. Les serveurs MCP qui exposent l'état des machines, les données MES et la documentation constituent des cibles plus faciles pour le développement assisté par des modèles de langage (LLM) que les API sur mesure créées ad hoc. La combinaison d'interfaces standardisées et d'un développement assisté par des modèles de langage (LLM) facilite la création de Digital Twins intégrés.

Les limites du code généré par les grands modèles de langage

Il convient de noter deux limites. Le code généré par un LLM est un projet, et non un produit fini ; pour le code lié à la sécurité ou aux systèmes de contrôle, les mêmes processus de révision et de validation s'appliquent que pour tout autre code. Et cette accélération concerne principalement les tâches d'intégration et de visualisation, et non la logique de contrôle sous-jacente, qui reste du ressort des ingénieurs en automatisation utilisant des outils éprouvés.

Dissocier la création de contenu de la diffusion

Dans ce contexte, une bonne pratique architecturale consiste à séparer l'environnement de création de l'artefact final. L'environnement de création est Unity, la plateforme de référence pour les Digital Twins industriels, utilisée comme éditeur par le constructeur de machines pour importer des fichiers CAO, définir la cinématique, configurer les modèles de comportement et associer la documentation aux composants. Unity offre la gamme complète d'outils, le processus d'importation de fichiers CAO, la prise en charge de la cinématique et de la physique, ainsi que les cibles de compilation multiplateformes dont les projets industriels ont besoin. Le produit livré fonctionne toutefois dans l'environnement du client pendant toute la durée de vie de la machine et présente l'avantage d'être ouvert et auto-hébergable : il s'agit d'une visionneuse basée sur un navigateur, développée à l'aide de technologies web standard (Three.js, TypeScript) et utilisant un format de scène standard (GLB). Le visualiseur web realvirtual.io, dont la pile de création basée sur Unity alimente un moteur d'exécution web open source sous licence AGPL, est un exemple concret de ce modèle actuellement en production.

Les implications plus larges pour l'Industrie 4.0

Dans l'ensemble, ces effets ont des répercussions plus larges sur l'Industrie 4.0. L'un des obstacles courants aux projets d'intégration réside dans le coût lié à l'interconnexion de systèmes hétérogènes. À mesure que ce coût diminue, le Digital Twin gagne en attractivité en tant que plateforme d'intégration : il ne s'agit plus seulement d'un outil de visualisation, mais d'une couche où convergent les signaux, les données d'entreprise, la documentation et la visualisation. Pour les intégrateurs de systèmes, c'est là que réside le véritable intérêt des Digital Twins : il ne s'agit pas tant d'un produit fini en soi que d'un point de convergence de tous les autres éléments.

Les agents de production — Un éventail

Le terme « agent » recouvre toute une gamme de comportements présentant des profils de risque très différents. Il est utile de préciser de quoi il s'agit.

• Les outils de diagnostic en lecture seule constituent la catégorie la plus restreinte. Ils surveillent l'état, consultent la documentation et répondent aux questions. Ils n'écrivent pas dans les systèmes de contrôle. Un opérateur demande pourquoi une ligne s'est arrêtée ; le système analyse l'état de l'alarme, recherche le code dans le manuel et fournit une explication. C'est un bon point de départ et, pour de nombreux cas d'utilisation, également une bonne conclusion.
• Au milieu, on trouve des outils de conseil. Ils surveillent l'état du système et proposent des actions — un changement de consigne, une tâche de maintenance, un réglage de paramètre — mais ne les exécutent pas. L'opérateur valide ou rejette chaque proposition. L'HMI 3D peut servir de surface de validation, en affichant le composant concerné et la modification proposée dans leur contexte spatial avant que toute écriture n'ait lieu. Ce modèle permet de préserver le rôle de l'humain dans le processus décisionnel tout en recourant à l'intelligence artificielle pour le diagnostic.
• À l'extrémité la moins contraignante, on trouve les systèmes d'exécution qui écrivent dans des automates programmables, modifient des recettes ou transmettent des commandes sans qu'une intervention humaine ne soit nécessaire pour chaque action. Cela est techniquement possible dans certains cas, mais soulève des considérations supplémentaires au regard du nouveau règlement sur les machines. La cybersécurité constitue désormais une exigence essentielle en matière de santé et de sécurité au titre de l'annexe III, et les fonctions de sécurité fondées sur l'IA relèvent explicitement de la liste des machines à haut risque prévue par le règlement, ce qui nécessite une évaluation de la conformité plus stricte. Toute voie permettant à un système basé sur un modèle de langage de grande échelle (LLM) d'écrire dans un système de contrôle constitue également une voie d'attaque potentielle. Ces systèmes doivent généralement être conçus avec le même soin que tout autre composant d'un système de commande disposant d'un accès en écriture, y compris en ce qui concerne les obligations en matière de journalisation et d'enregistrement des données que la réglementation impose pour les logiciels liés à la sécurité.

Une approche courante pour les premiers projets consiste à opter par défaut pour un mode « lecture seule », à passer ensuite à un mode « consultatif » nécessitant une confirmation explicite de l'opérateur, et à considérer toute fonctionnalité permettant d'effectuer des actions comme un composant du système de contrôle soumis aux mêmes procédures de révision et de validation que le code du PLC.

Un point de départ pratique pour les intégrateurs

Pour les intégrateurs qui se demandent par où commencer, une approche progressive s'avère généralement plus efficace qu'une approche trop ambitieuse.

Une première mise en œuvre concrète pourrait inclure :

• Utilisation d'un projet de machine existant : Commencez par une machine qui dispose déjà d'une HMI 3D et pour laquelle un dossier de documentation structuré est en cours d'élaboration conformément au règlement (UE) 2023/1230.
• Mise à disposition de la documentation via un serveur MCP : Regroupez l'ensemble de la documentation dans un seul serveur MCP permettant la recherche par identifiant de composant.
• Connexion de l'HMI 3D aux services de documentation : Configurez l'HMI 3D existante de manière à ce que la sélection d'un composant affiche automatiquement la section correspondante du manuel.
• Ajout d'une interface IA reliée à la terre : Intégrer un panneau de discussion à côté de la vue 3D à l'aide d'un modèle de langage générique (LLM) ancré dans la documentation du serveur MCP.

Résultats attendus

Le résultat est une machine qui permet à l'opérateur de poser une question, d'obtenir une réponse s'appuyant sur la documentation du fabricant et de voir le composant concerné mis en évidence dans la vue 3D. Il n'y a ni états de contrôle, ni actions autonomes, ni nouvelle infrastructure d'automatisation. Les avantages — diminution du nombre d'appels au service d'assistance, amélioration des taux de résolution dès la première intervention, accès facilité à l'expertise du fabricant — sont tangibles, et les risques sont limités.

Pour les intégrateurs qui souhaitent découvrir à quoi peut ressembler un tel système dans la pratique, une démonstration publique d'une HMI 3D accessible via un navigateur et exploitant des données de signaux en temps réel est disponible à l'adresse web.realvirtual.io/demo. L'architecture sous-jacente — Unity comme environnement de développement, une pile web ouverte pour la mise en production et un système de Version Control standard tel que Gitea pour le stockage du package produit pendant toute la durée réglementaire de dix ans — constitue un modèle que les intégrateurs peuvent adopter et adapter à leurs propres projets.

À partir de là, d'autres étapes peuvent être ajoutées progressivement. Un serveur MCP de la couche de signal permet de poser des questions sur l'état en temps réel. Une connexion au système de gestion de la fabrication (MES) permet d'obtenir des informations sur les commandes en cours. Les recommandations de l'interface utilisateur, confirmées par l'opérateur dans l'HMI 3D, permettent d'étendre davantage le système sans en modifier le profil de risque fondamental. Chaque étape peut être testée et annulée individuellement.

Une architecture qui prend en charge à la fois la conformité et l'IA

Le précédent livre électronique se terminait par cette remarque : les Digital Twins constituent autant un investissement organisationnel que technique ; ainsi, la mise en service virtuelle, par exemple, n'apporte de la valeur ajoutée que si les processus connexes sont prêts à évoluer. On peut faire ici la même remarque.

Deux tendances se rejoignent actuellement chez les intégrateurs. La directive sur les machines est connue depuis 2023, mais les travaux concrets de préparation en vue de la date d'entrée en vigueur fixée au 20 janvier 2027 — avec de nouvelles dispositions obligatoires en matière de cybersécurité et la possibilité désormais explicite de recourir à une documentation numérique structurée assortie d'une gestion du cycle de vie — passent désormais de la phase de planification à celle de mise en œuvre. Parallèlement, les outils d'IA génèrent une demande en données structurées et fiables. Ces projets peuvent être menés séparément, mais les travaux sous-jacents se recoupent largement. L'architecture à quatre couches décrite dans la première partie prend en charge à la fois l'opérateur et tout outil d'IA ajouté ultérieurement. Une documentation numérique structurée, élaborée à des fins de conformité réglementaire, constitue également une base utile. L'HMI 3D peut servir de surface unifiée pour tous ces éléments.

Les avantages opérationnels décrits dans la première partie — diagnostic plus rapide, seuils d'expertise moins élevés, diffusion d'informations contextualisées, assistance à distance efficace — s'appliquent quel que soit le contexte réglementaire. Les intégrateurs situés hors de l'UE, ou travaillant sur des systèmes non couverts par la réglementation relative aux machines, bénéficient des mêmes avantages opérationnels grâce à cette même architecture, sans que le délai réglementaire ne constitue un facteur contraignant. Cette architecture se suffit à elle-même sur le plan opérationnel ; la réglementation ne fait que préciser le calendrier pour le marché européen.

Le fonctionnement autonome n'est pas le premier résultat attendu. Un point de départ plus réaliste consiste en une machine qu'un opérateur peut interroger, qu'un intégrateur peut prendre en charge et qu'un fabricant peut maintenir à jour pendant la période réglementaire de dix ans. Les outils et les normes nécessaires à la construction d'une telle machine sont déjà disponibles, et la majeure partie du travail de base correspond à des tâches que les intégrateurs doivent de toute façon accomplir.