Qu’est-ce que l’i3X ? La norme qui rend les données d’usine exploitables par l’IA

i3X (Industrial Information Interoperability eXchange) est la spécification d’API ouverte et indépendante des éditeurs, publiée par CESMII, pour interroger des données industrielles contextualisées à travers une seule interface. La version 1.0 a été publiée sur GitHub le 9 juin 2026 et annoncée le 18 juin 2026, avec le soutien de 44 fournisseurs de technologies pour l’industrie. Elle vise à mettre fin au chaos des API qui empêche les données d’usine d’être exploitables par l’IA. Si vous utilisez déjà une connectivité OPC UA ou Kepware, i3X ajoute par-dessus la couche de requête prête pour l’IA. Elle ne remplace pas l’existant.

Fait partie de notre série IA pour la fabrication. À lire aussi : Unified Namespace · IA prédictive vs IA générative dans l’industrie

Je commence par le moment où cela est devenu concret pour moi. Huit systèmes connectés, des tableaux de bord en temps réel partout, et j’étais toujours incapable de dire quel ordre tournait quand l’outil a commencé à dériver. Connecté, et aveugle. Cet écart, entre posséder des données et pouvoir répondre à une question avec, est exactement ce que l’i3X vient combler. Si vous avez déjà OPC UA ou un Unified Namespace, la question utile n’est pas ce qu’est l’i3X dans l’absolu. C’est où l’i3X s’insère dans ce que vous avez déjà. C’est tout l’objet de la suite.

Le chaos des API : la prolifération des silos de données industrielles

L’i3X existe parce qu’une usine faisant tourner cinq plateformes de données et cinq applications IT ou IA peut se retrouver avec jusqu’à vingt-cinq intégrations sur mesure, le problème n fois m souvent décrit comme le « chaos des API ». Chaque historian, MES, système qualité et outil de maintenance parle sa propre API propriétaire. Reliez cinq sources à cinq consommateurs et vous entretenez vingt-cinq ponts fragiles, faits à la main, dont chacun casse dès qu’un éditeur modifie son interface. L’i3X est une initiative d’API commune et ouverte qui répond à un défi d’interopérabilité croissant dans les architectures industrielles modernes, où chaque éditeur de plateforme et chaque fournisseur de solution livre sa propre interface. Pour les développeurs qui travaillent avec plusieurs éditeurs, chaque nouveau système ajoute une complexité d’intégration qui freine l’innovation.

Le secteur se trompe systématiquement sur un point. Il accuse les protocoles. Mauvaise cible. Les protocoles sont réglés depuis des années. Une équipe correcte lit les données de presque n’importe quel automate, historian ou base en une semaine. Si connecter une machine prend encore des mois, ce n’est pas à cause du câble. C’est que chaque application a besoin de données mises en forme, nommées et contextualisées différemment, et que personne ne s’est mis d’accord sur une façon commune de les demander.

« Connecter une machine prend encore des mois, et tout le secteur continue d’accuser les protocoles. Mauvaise cible. Les protocoles sont réglés depuis des années. »

C’est précisément ce qui bloque l’IA. Un grand modèle de langage ou un agent autonome ne vaut que les données qu’il peut atteindre et auxquelles il peut se fier. Quand chaque source expose des tags bruts et non contextualisés derrière une API maison, votre stratégie IA repose sur un socle de données qui n’a jamais été conçu pour elle, et c’est pour cela que tant de projets d’IA industrielle s’enlisent au purgatoire du pilote. La prolifération des silos de données dans des piles logicielles hétérogènes n’est pas un désagrément. C’est ce qui sépare votre usine de la portabilité applicative, et votre usine de l’IA.

Les connexions se comportent aussi autrement que ne le supposent la plupart des business cases. Elles ne s’additionnent pas, elles se multiplient. La dixième intégration vaut mieux que la première, parce qu’elle a neuf autres avec lesquelles se croiser. Courez après la couverture brute et vous obtiendrez un mur de lignes vertes qui ne répondent à rien.

Qu’est-ce que l’i3X ? L’Industrial Information Interoperability eXchange

L’i3X, Industrial Information Interoperability eXchange, est une définition d’API commune, ouverte et indépendante des éditeurs, portée par CESMII (The Smart Manufacturing Institute), qui normalise la façon dont toute application accède à l’information industrielle contextualisée, quelle que soit la plateforme en dessous. CESMII l’a menée à une version 1.0 finalisée en juin 2026 ; la spécification et son outillage vivent sur le site officiel i3X et sur GitHub. Parce que l’i3X est indépendante des éditeurs, une application écrite pour elle continue de fonctionner d’une plateforme à l’autre, ce qui donne une interopérabilité qui passe à l’échelle au lieu d’un empilement d’intégrations uniques.

CESMII est inhabituellement direct sur l’intention. Dans ses propres termes, l’API commune existe pour banaliser l’accès aux données, en laissant les éditeurs de plateformes libres de se différencier par leurs capacités. Le résultat attendu est une floraison d’applications portables, comme les API communes des appareils ont produit des magasins d’applications plutôt qu’une bibliothèque de pilotes.

Le plus rapide pour comprendre l’i3X, c’est par ce qu’elle n’est pas :

• Ce n’est pas un protocole de transport. Elle ne sort pas les octets d’un automate. OPC UA, MQTT et leurs pairs le font déjà bien.
• Ce n’est pas un broker de messages. Elle ne remplace ni votre bus d’événements ni votre Unified Namespace.
• Ce n’est ni un historian ni une base de données. Elle ne stocke pas vos données.

L’i3X est la couche de requête normalisée posée au-dessus de tout cela. Connectez votre tableau de bord, votre outil de BI ou votre agent IA une fois au standard i3X, et il continue de fonctionner quand vous changez le middleware ou le broker en dessous. Connectez-le plutôt au format propriétaire d’un éditeur, et vous reconnectez chaque fois que cet éditeur change d’avis. Ce seul basculement, de plusieurs API propriétaires vers une seule ouverte et contextualisée, est tout l’enjeu.

Comment fonctionne l’i3X : une API commune indépendante des éditeurs

L’i3X définit un jeu de primitives serveur de base, regroupées en quatre capacités : exploration, requête, mise à jour et abonnement. Les méthodes d’exploration, de requête et d’abonnement sont obligatoires pour un serveur conforme, la mise à jour est optionnelle. Ensemble, elles forment le socle qui donne à une application une manière prévisible et typée de travailler avec le modèle d’information d’une usine :

• Découvrir les espaces de noms exposés par un serveur.
• Explorer les définitions de types d’objets, pour savoir à quoi ressemble vraiment un « ordre de fabrication » ou une « machine ».
• Récupérer des instances précises de ces objets.
• Naviguer dans les relations hiérarchiques entre elles.
• Interroger des valeurs, courantes et historiques.
• S’abonner aux changements et aux événements.
• Mettre à jour des valeurs courantes ou historiques, là où le serveur le permet.

Ce jeu de primitives est la raison technique pour laquelle l’i3X est dite « prête pour l’IA ». Un agent IA ne veut pas d’un torrent de tags anonymes. Il a besoin de découvrir ce qui existe, de comprendre le type et le sens de chaque objet, de parcourir les relations entre eux et d’obtenir à la fois la valeur en direct et son historique, le tout par un contrat unique et cohérent. Un accès structuré, découvrable et typé est ce qui transforme des données brutes en quelque chose sur quoi un modèle peut raisonner au lieu d’halluciner autour. La pièce manquante n’a jamais été le câblage. C’est l’arête, le lien qui transforme une mesure en fait, et seul le sens l’apporte.

Une limite mérite d’être dite clairement, car elle façonne chaque projet. La primitive de mise à jour écrit des valeurs, courantes ou historiques. La spécification ne définit aucune opération pour créer, modifier ou supprimer des types d’objets, des objets ou des relations. La création du modèle reste entièrement du ressort de la plateforme, et c’est pourquoi la question de savoir qui écrit votre modèle compte davantage que celle de la plateforme qui le sert.

L’i3X transporte aussi l’origine d’un type. Les métadonnées de chaque objet comprennent typeNamespaceUri et sourceTypeId, deux champs obligatoires, afin qu’un client puisse remonter un type jusqu’à sa définition d’origine, qu’il s’agisse d’une companion specification OPC UA, d’un espace de noms ISA-95 ou de celui d’un éditeur. Le pointeur est normalisé. Ce qu’aucune partie de la spécification ne fait, c’est obliger deux sites à pointer vers la même définition, ou vérifier que la définition référencée a bien été respectée.

i3X Explorer et l’outillage pour les développeurs

Autour de la spécification, il existe un outillage réel. ACE Technologies publie l’i3X Explorer officiel, multiplateforme, un client graphique pour parcourir l’espace d’adressage de n’importe quel serveur i3X conforme. Il y a un point de terminaison de démonstration public avec une page Swagger, un serveur MCP open source (voir plus bas), et la version 1.0 est livrée avec une spécification OpenAPI, une bibliothèque cliente Python et une suite de tests de conformité qui classe une implémentation selon quatre verdicts : conformité 1.0 complète, conformité 1.0 avec système de types immature, compatibilité 1.0 ou non conforme.

Le deuxième verdict est le plus intéressant. Une implémentation peut passer chaque test de la suite et être malgré tout signalée comme portant un système de types léger, ce qui revient à voir CESMII reconnaître, dans son propre outillage, qu’une API conforme et une API modélisée sont deux choses différentes. La spécification et les documents de référence vivent dans le GitHub public de CESMII, où se trouvent aussi la gouvernance et le modèle de contribution open source.

i3X et OPC UA : où se place chaque standard

L’i3X ne remplace pas OPC UA. OPC UA sort les données des machines à la périphérie, et l’i3X normalise la façon dont les applications IT et IA interrogent des données déjà contextualisées au-dessus. Les deux opèrent à des couches différentes et résolvent des problèmes différents.

Si vous exploitez aujourd’hui une connectivité OPC UA, très souvent via Kepware, la question que vous poserez vraiment est de savoir si l’i3X remplace votre couche OPC UA existante. Elle ne la remplace pas. Elle la complète. OPC UA continue de faire ce qu’il fait bien : une acquisition fiable et en temps réel depuis l’atelier. L’i3X se place au-dessus comme interface de requête côté applications, de sorte que la pile analytique et les agents IA cessent de se soucier de l’historian ou du broker d’où venaient les données. Votre investissement en périphérie reste exactement où il est.

Le modèle d’accès aux données : où se situe l’i3X dans la pile

CESMII place l’i3X dans ce qu’elle appelle le Data Access Model, en comparant la pile technique de l’i3X à celle d’un navigateur web ordinaire. La comparaison mérite d’être gardée. Un navigateur ne va pas chercher des octets sur un contrôleur de disque, il demande un document à une couche bien définie au-dessus. L’i3X joue le même rôle pour l’information industrielle. OPC UA et MQTT font le gros du travail sur les couches basses, côté périphérie, et l’i3X opère au-dessus, là où les données ont déjà reçu structure et sens. La spécification est explicite : l’information qui atteint l’API est supposée avoir été traitée au préalable par des fonctions de contextualisation. Vue ainsi, l’opposition « i3X contre OPC UA » se dissout. Ce sont des voisines dans la même pile, pas des rivales pour le même barreau.

i3X et l’Unified Namespace : la couche de requête manquante

Un Unified Namespace gère le publish-subscribe en temps réel, piloté par les événements, sur MQTT ou NATS. L’i3X ajoute l’interface de lecture et de requête normalisée qu’un UNS n’a jamais été conçu pour offrir aux systèmes IT et analytiques. Les deux sont complémentaires, mais il y a ici une subtilité que la plupart des explications sautent, et elle compte énormément pour l’IA.

Un Unified Namespace est vraiment bon pour la télémétrie : une température, une charge machine, un compteur de cycles, où la valeur la plus récente remplace simplement l’ancienne. L’ennui commence quand le même arbre unique est traité comme la source de vérité pour les données transactionnelles aussi, c’est-à-dire les ordres de fabrication, les versions de recettes, les enregistrements de lots et les résultats qualité. Ces données ont une vie. Une équipe comptabilisée comme bonne est rebutée deux jours plus tard quand la qualité rattrape son retard. L’enregistrement est créé, corrigé, parfois annulé, et son historique est tout l’intérêt (davantage là-dessus dans From Signal to Structure). Versez les deux types de données dans un même espace de dernière valeur et la télémétrie aura l’air correcte pendant que les données transactionnelles pourriront en silence.

« MQTT ne garde que la dernière valeur. Un ordre n’est pas une dernière valeur. Son historique est tout l’intérêt. »

Il y a aussi un problème plus profond. Même quand un broker délivre une valeur parfaitement, il ne peut pas vous dire que cette valeur est juste. Deux systèmes publient. L’un dit que le lot faisait 100, l’autre 240. Le broker transmet les deux avec un horodatage impeccable et ne dit jamais lequel est faux. La distribution a été réglée il y a longtemps. La vérité, non. Propre n’est pas synonyme de vrai, et un schéma qui fait applaudir une keynote doit encore survivre à un bon de commande un mardi.

C’est pourquoi l’i3X compte pour plus qu’un confort. Elle donne à l’IT, à l’analytique et à l’IA une interface de requête normalisée sur des données contextualisées, courantes et historiques, avec les relations intactes, posée au-dessus du broker de messages plutôt qu’à sa place. Un UNS à arbre unique est un excellent bus de télémétrie et une piètre source de vérité. Lue de haut en bas, la pile ressemble à ceci : clients IT et IA, puis la couche d’API i3X, puis le broker de messages au cœur de votre UNS, puis l’harmonisation des données et les convertisseurs de protocoles, et enfin la couche OT.

i3X et l’IA : le lien avec MCP (Model Context Protocol)

Si MCP est la grammaire qui permet à un agent IA de se connecter à une source de données, l’i3X est le vocabulaire de l’usine : les définitions partagées de ce que sont réellement un ordre de fabrication, un lot ou une machine. Ensemble, ils rendent les données industrielles utilisables par des agents IA. Le Model Context Protocol est un standard ouvert pour connecter des agents IA à des outils et à des données, et l’i3X est ce qui donne à cette connexion quelque chose de sensé à se dire.

Les deux s’articulent délibérément. L’i3X 1.0 est livrée avec un serveur MCP officiel, publié sur GitHub et npm, qui fonctionne avec n’importe quel point de terminaison i3X conforme. Une question en langage naturel peut recevoir une réponse sur une usine réelle : l’agent découvre le modèle, interroge les données et renvoie une réponse ancrée dans le contexte propre à l’usine. HighByte a montré un résultat comparable sous un autre angle. Dans sa démonstration publique, un agent construit dans Microsoft Foundry se connecte au serveur i3X du HighByte Intelligence Hub en n’utilisant que la spécification OpenAPI i3X, et travaille sur des données d’usine modélisées sans aucune intégration sur mesure.

C’est aussi là que la discipline compte, et là que j’emploie le terme DefensibleAI. Ratez la couche du dessous et l’IA au-dessus donnera des réponses fluides et assurées sur des données qui se contredisent en silence ; à la première contestation d’une recommandation, il n’y aura aucun moyen de montrer comment elle a été obtenue. Posez de l’IA sur un système qui a consigné le quoi mais jamais le pourquoi, et l’agent héritera du même angle mort. L’ordre sur lequel j’insiste est simple. Séparation d’abord, découverte ensuite, intelligence en dernier. L’i3X est ce qui rend la couche de découverte digne de confiance, pour que la couche d’intelligence soit redevable.

« L’IA au-dessus donne des réponses fluides et assurées sur des données qui se contredisent en silence. Et à la première contestation d’une recommandation, il n’y a aucun moyen de montrer comment elle a été obtenue. Séparation d’abord. Découverte ensuite. Intelligence en dernier. »

De la bêta à l’i3X 1.0 : historique des versions et contenu

L’i3X est passée d’une bêta en avril 2026 à une spécification 1.0 complète, publiée le 9 juin et annoncée le 18 juin 2026. Cette date compte. Beaucoup de contenus encore en circulation décrivent l’i3X comme « alpha » ou pré-version. Ce n’est plus le cas. Elle est finalisée et prête à être implémentée dès aujourd’hui.

Le paquet 1.0 livre l’outillage complet nécessaire pour construire et vérifier une vraie implémentation :

• Guide d’implémentation
• Spécification OpenAPI
• Suite de tests de conformité
• i3X Explorer mis à jour
• Bibliothèque cliente Python
• Serveur MCP
• Documentation du SDK

Il y a encore une chose à savoir avant de bâtir un plan autour. CESMII a indiqué que la définition de l’API est désormais stable et que, jusqu’à l’établissement d’un nouveau mandat fin 2026 pour lancer les travaux sur vNext, seuls les sujets de documentation et de démonstration seront traités. Les changements de spécification et les nouvelles fonctions iront dans vNext. Pour un projet qui démarre maintenant, cela signifie que l’interface ne bougera pas sous vos pieds cette année, et qu’il existe une fenêtre identifiée pour ce que vous auriez voulu différent.

La 1.0 va donc bien au-delà d’un livre blanc. C’est une spécification accompagnée de l’outillage, des tests et des clients de référence nécessaires pour passer en production. Pour un standard émergent, c’est inhabituellement complet, et c’est ce qui fait de l’i3X un pari raisonnable.

Qui adopte l’i3X ? Éditeurs, écosystème et déploiements réels

L’annonce de la 1.0 cite 44 fournisseurs de technologies pour l’industrie derrière le standard. Le contexte de la spécification nomme les plateformes d’où viennent ses contributeurs : HighByte, Inductive Automation, Rockwell Automation, Siemens et ThinkIQ, avec plus de cinquante ans d’expérience cumulée dans les logiciels d’information industrielle. Le groupe de travail comprend aussi AWS, Microsoft, Georgia-Pacific et GE Appliances, ce qui l’empêche d’être la couche marketing d’un seul éditeur. Parmi les implémentations en service, HighByte expose un serveur i3X depuis son Intelligence Hub, permettant aux applications de parcourir, lire, écrire et s’abonner à des données modélisées via le standard. L’i3X Explorer d’ACE Technologies, évoqué plus haut, donne aux développeurs un client prêt à l’emploi pour tester ces serveurs.

Soutenir un standard et le livrer sont deux comptes différents. Les interfaces i3X vérifiables publiquement restent bien moins nombreuses que les 44 fournisseurs cités dans l’annonce, ce qui est normal quelques mois après une 1.0 et bon à savoir quand on planifie.

L’attention des analystes a suivi. Colin Masson, d’ARC Advisory Group, a publié une analyse détaillée de la façon dont l’i3X comble le déficit d’ingénierie du contexte dans les data fabrics industrielles, et dans l’annonce de la 1.0, Matthew Littlefield de LNS Research a noté que l’i3X est à la fois implémentée par les fournisseurs de technologies et déployée par les utilisateurs finaux.

Qui se cache derrière CESMII et le Smart Manufacturing Mindset ?

CESMII, The Smart Manufacturing Institute, est l’institut américain dédié à la production intelligente. Fondé en 2016 et financé par le département de l’Énergie des États-Unis, ce consortium à but non lucratif totalise un engagement d’investissement de 201 millions de dollars, provenant des fonds du DOE et de contributions publiques et privées. Son siège programmatique et administratif est l’UCLA, et il fait partie du réseau d’instituts Manufacturing USA. L’i3X est l’un des produits du programme Smart Manufacturing plus large de ce consortium, et c’est pourquoi elle est gouvernée comme un standard ouvert plutôt que détenue par une seule entreprise. CESMII inscrit ce travail dans ce qu’elle appelle le Smart Manufacturing Mindset, dont l’i3X est la pièce interopérabilité.

Intégrer l’i3X à votre pile OT/IT existante : un chemin d’adoption concret

Pour un industriel qui exploite déjà une connectivité OPC UA, très souvent via Kepware, adopter l’i3X consiste à ajouter une couche de requête contextualisée par-dessus, pas à réarchitecturer la pile OT. C’est là que la plupart des articles s’arrêtent et que le travail concret commence. Voici le chemin que nous suivons avec nos clients dans nos projets de fabrication numérique :

1. Évaluez la maturité de votre connectivité. Cartographiez l’existant : historians, Unified Namespace, acquisition OPC UA et Kepware. L’i3X suppose qu’une acquisition fiable existe déjà. Elle ne l’arrache pas.
2. Contextualisez les données avec des modèles d’information. Les tags bruts prennent sens grâce aux modèles. Utilisez les Smart Manufacturing Profiles de CESMII, ou une structure alignée sur l’ISA-95 qui garde chaque ordre de fabrication en trois enregistrements distincts : la définition du produit (la recette), la demande d’opérations (le plan) et la performance d’opérations (le résultat réel). Recette, plan et performance, jamais mélangés.
3. Exposez les données contextualisées via un serveur conforme i3X. C’est de la configuration, pas du code. Un connecteur balaie ce qu’un système expose déjà, le fait correspondre à un profil standard avec l’aide de l’IA au moment de la conception seulement, et génère une configuration vérifiée que votre middleware existant exécute. Il ne touche jamais au flux en direct. La première machine d’un type est un vrai chantier. La centième prend quelques minutes.
4. Connectez vos clients IT, analytiques et IA via le standard, y compris les agents fondés sur MCP, à une seule interface stable.

« De la configuration, pas du code. Il ne touche jamais au flux en direct. La première machine d’un type est un vrai chantier. La centième prend quelques minutes. »

Sous ces quatre étapes se tient le point stratégique : le schéma est l’actif. La configuration, ce sont des données. Vous les versionnez, les relisez, les restaurez et vous en êtes propriétaire. C’est cela, la souveraineté. La souveraineté ne tient pas à l’endroit où tournent les serveurs. Elle tient à qui possède le modèle qui définit ce qu’est un ordre de fabrication et ce que signifie le TRS. Vous pouvez louer ce modèle dans la plateforme d’un éditeur et, le jour où le contrat s’arrête, repartir avec les lignes en laissant le sens derrière vous. Ou le garder comme votre propre schéma fondé sur un standard. Quand Schneider Electric a annoncé, le 30 juin 2026, un accord pour acquérir Cognite pour 3,1 milliards de dollars, c’est-à-dire la couche posée au-dessus des données d’usine, ce choix a cessé d’être abstrait. Possédez le cerveau, ne le louez pas. L’i3X est ce qui rend cette possession praticable. La même logique vaut pour votre piste d’audit. Si l’historique qui prouve ce qui s’est passé peut être discrètement modifié, ou réside dans un magasin contrôlé par l’éditeur, il n’est pas vraiment le vôtre.

Quand l’i3X est (et n’est pas) le bon choix

L’i3X convient bien aux environnements multi-éditeurs, au développement d’applications portables, à l’intégration en brownfield, ainsi qu’à l’analytique multi-sites et aux tableaux de bord TRS où la cohérence entre usines est l’objectif. Ce n’est pas le bon outil pour des boucles de commande temps réel strictes, pour du streaming d’événements à très haut débit, ni pour une usine mono-plateforme où il n’y a encore rien avec quoi interopérer. Savoir où elle n’a pas sa place fait partie du fait de bien s’en servir.

Si vous cartographiiez votre propre usine demain, quelle connexion unique débloquerait le plus de réponses que vous ne pouvez pas obtenir aujourd’hui ?

À propos de l’auteur

Tobias Lante est AI Agent Architect for Manufacturing chez Transition Technologies PSC, où il travaille à rendre les données d’usine exploitables, et défendables, pour l’IA. Sur LinkedIn, il publie une série suivie sur l’Industrial DataOps et l’i3X, dont From Signal to Structure, What Each Connection Is Worth et The Graph Comes Out of the Schemas. Son commentaire sur le lancement de la bêta i3X a également été repris dans l’épisode Hannover Messe 2026 du podcast Frenus « Best of LinkedIn: Smart Build & Manufacturing ». Suivez son travail sur LinkedIn.