Interfaces SAP/MES/atelier : OPC UA, SAP MII, PCo et risques OT/IT

En synthèse

Les interfaces SAP/MES/atelier ne sont pas un sujet d’intégration technique secondaire. Dans un environnement industriel, elles constituent souvent le système nerveux de l’usine digitale : elles transportent les ordres, les statuts d’opération, les consommations, les résultats qualité, les paramètres machine, les événements OPC UA, les étiquettes, les lots, les confirmations et parfois les données nécessaires à la libération produit.

La difficulté tient au fait que ces flux traversent des frontières organisationnelles rarement alignées : ERP, MES, automatisme, infrastructure, cybersécurité, méthodes, qualité, production et support. Une interface peut être techniquement disponible tout en étant fonctionnellement inutilisable si la source de vérité est floue, si les règles de reprise ne sont pas définies ou si l’équipe de run ne sait pas diagnostiquer l’incident.

Une interface robuste se conçoit donc comme un processus industriel critique. Le protocole — RFC, IDoc, API, OPC UA, fichier, base SQL, SAP MII, SAP PCo ou middleware — vient après la clarification du déclencheur, du propriétaire de la donnée, de la granularité, du scénario de reprise et des critères de supervision.

Remettre la responsabilité métier au centre de l’interface

Le premier piège consiste à déléguer l’interface aux seules équipes techniques. Or la plupart des incidents visibles en production proviennent d’une ambiguïté métier : qui décide du statut d’un ordre ? Qui est responsable d’une quantité corrigée ? Le MES peut-il créer un lot ou doit-il uniquement consommer un lot SAP ? Une mesure machine peut-elle être retraitée ? Une déclaration partielle doit-elle clôturer l’opération ?

Ces questions ne relèvent pas du protocole. Elles relèvent de la gouvernance process. Sans décision explicite, chaque système interprète le flux selon sa propre logique, puis les équipes support découvrent l’écart après go-live.

Fenlynks recommande de produire une fiche d’interface qui commence par le processus couvert, les décisions métiers et les cas d’exception, avant de détailler le format technique.

Définir la source de vérité donnée par donnée

Dans les architectures SAP/MES, le terme « source de vérité » est souvent utilisé trop largement. Il ne suffit pas de dire que SAP est maître des données. SAP peut être maître de l’ordre, le MES maître de l’exécution, l’équipement maître de l’événement machine et le laboratoire maître du résultat de contrôle. La granularité doit être plus fine.

Pour chaque donnée critique, il faut définir le système auteur, le système consommateur, les règles de modification, les seuils d’écart acceptables, le mode de correction et le propriétaire métier. À défaut, les écarts s’accumulent : ordre présent dans SAP mais absent du MES, lot existant dans le MES mais non réconcilié dans SAP, quantité produite différente de la quantité confirmée, statut qualité incohérent entre stock et atelier.

Traiter OPC UA comme un modèle d’information, pas comme un simple tuyau

OPC UA est souvent abordé comme une connectivité machine. La vraie question est le modèle d’information exposé : quels nœuds sont lisibles, quelles valeurs sont historisées, quelle fréquence est utile, quels tags sont fiables, quels états machines ont un sens métier, et comment les changements d’état sont interprétés.

Un tag qui remonte une valeur de température, un compteur ou un état de ligne ne crée pas de valeur en soi. Il faut définir si cette donnée sert à libérer un lot, calculer une performance, déclencher une alerte, alimenter un eBR, générer une non-conformité ou simplement contextualiser un événement.

Sur le terrain, les dérives viennent souvent d’une table de mapping insuffisamment gouvernée : noms de tags non standardisés, unités incohérentes, valeurs nulles non interprétées, changements automates non répercutés, ou absence de versioning du modèle.

Sécuriser SAP MII / PCo par le run, pas uniquement par le développement

SAP MII et SAP PCo peuvent jouer un rôle utile dans la collecte, la transformation et l’orchestration de flux industriels. Leur risque principal n’est pas leur capacité technique, mais leur maintenabilité : transactions non documentées, jobs critiques connus d’un seul expert, destinations non supervisées, logs difficiles à exploiter, absence de tests de non-régression.

Un environnement MII/PCo doit être traité comme un actif critique. Il faut un catalogue des flux, une cartographie des dépendances, une politique de transport, des scénarios de reprise, un monitoring lisible par le support et une distinction claire entre incident technique et incident métier.

Dans une logique premium, la question n’est pas « faut-il remplacer MII ? ». La question est « quels flux portent encore une valeur, quels flux exposent l’usine, quels flux doivent être modernisés, et dans quel ordre ? »

Tester les reprises avant de tester le nominal

Un flux nominal fonctionnera souvent en recette. Les vrais risques apparaissent sur timeout, double envoi, message rejeté, valeur incomplète, équipement indisponible, SAP verrouillé, changement de statut tardif, décalage horaire ou correction opérateur.

Chaque interface critique doit avoir un scénario de rejeu. Il faut savoir si le rejeu est automatique, manuel, interdit, conditionné ou contrôlé par un workflow. Il faut aussi définir si le système doit être idempotent : recevoir deux fois le même événement ne doit pas doubler une consommation ou créer deux confirmations.

Les cas de reprise doivent être écrits dans le cahier de recette. S’ils ne sont pas testés avant go-live, ils seront découverts en production, généralement au pire moment : changement d’équipe, fin de poste, clôture de lot, expédition urgente ou audit qualité.

Mettre en place un modèle de support OT/IT exploitable

Le support d’une interface SAP/MES/atelier échoue lorsque personne ne possède la vision de bout en bout. L’automaticien voit le tag disponible, l’équipe MES voit un message rejeté, SAP voit une erreur applicative, et le métier voit une ligne bloquée. Le temps de diagnostic explose.

Un modèle de support efficace définit les niveaux de diagnostic : disponibilité équipement, disponibilité PCo, transaction MII, middleware, message SAP, donnée fonctionnelle, décision métier. Il définit aussi les seuils d’escalade, les personnes d’astreinte, la documentation minimale et les indicateurs de récurrence.

Le run doit être conçu avant le go-live, pas reconstruit après plusieurs semaines d’incidents.

Matrice de décision

La matrice suivante permet de différencier les interfaces qui doivent être industrialisées en priorité de celles qui peuvent rester plus simples.

Exemple concret anonymisé

Dans un contexte de production batch, une interface de confirmation remontait les consommations réelles du MES vers SAP. Le flux nominal fonctionnait, mais une correction opérateur après clôture partielle générait un écart entre quantité consommée MES et mouvement de stock SAP. L’incident n’était pas technique : le scénario métier de correction tardive n’avait pas été arbitré.

La résolution n’a pas consisté à « corriger l’interface », mais à définir une règle de gestion : fenêtre de correction autorisée, rôle de validation, statut de l’ordre, type de mouvement SAP, trace d’audit, scénario de rejeu et message d’erreur compréhensible par le support. Le gain principal a été la réduction du temps de diagnostic et la suppression des corrections manuelles non gouvernées.

Questions de direction

• Avons-nous une cartographie exhaustive des flux SAP/MES/OT réellement critiques pour la production ?
• Pour chaque flux, savons-nous qui possède la donnée, qui peut la corriger et comment elle est réconciliée ?
• Les scénarios de panne, double envoi, timeout, rejet SAP et reprise manuelle ont-ils été testés ?
• Le support dispose-t-il d’une procédure de diagnostic de bout en bout, compréhensible hors équipe projet ?
• La trajectoire MII/PCo est-elle pilotée par criticité métier ou par opportunisme technologique ?

Checklist opérationnelle

• Cartographier les flux par processus industriel, pas uniquement par système.
• Définir source de vérité, déclencheur, fréquence, format, règle de rejet et règle de reprise.
• Tester timeout, double exécution, coupure réseau, rejet SAP et correction métier.
• Mettre en place un monitoring orienté support, avec responsabilités OT/IT explicites.
• Classer les flux MII/PCo en maintenir, sécuriser, simplifier ou moderniser.

Conclusion

La robustesse d’une interface SAP/MES ne dépend pas d’abord du protocole choisi. Elle dépend de la qualité des décisions métiers, de la clarté des responsabilités, de la capacité à tester les cas dégradés et de la maturité du run. Dans une usine digitale, l’interface n’est pas une ligne technique dans un planning : c’est un actif opérationnel critique.