Un document de position à contre-courant affirmant que le récit dominant de la convergence OT/IT commet une erreur de catégorie. La technologie opérationnelle et la technologie de l'information devraient partager des chaînes d'outils, des pratiques et du personnel, mais leur distinction architecturale reflète des différences fondamentales en matière de physique, de modes de défaillance et de limites de confiance qu'aucun outil ne peut dissoudre. Le bon modèle est asymétrique : distinction architecturale avec unification opérationnelle, médiée par une couche de démarcation délibérée.
Préambule
Une expression particulière a acquis le statut d’axiome industriel au cours de la dernière décennie : Convergence OT/IT. Il apparaît dans les livres blancs des fournisseurs, dans les cadres de conseil stratégique, dans les discours de conférences industrielles et dans les présentations qui justifient des programmes de transformation de plusieurs millions de dollars. L’expression suggère que la séparation historique entre la technologie opérationnelle – les systèmes de contrôle qui déplacent la matière physique – et la technologie de l’information – les systèmes qui déplacent les informations sur la matière – était une condition transitoire produite par des accidents de l’histoire organisationnelle, et qu’une pratique d’ingénierie mature dissoudra cette distinction.
Cet article soutient que le discours sur la convergence, pris dans sa forme dominante, est erroné. Pas partiellement faux, pas occasionnellement faux, mais structurellement faux d'une manière qui produit des échecs architecturaux lorsqu'il est traité comme un principe de conception.
L’argument n’est cependant pas une défense du récit plus ancien – la doctrine de l’écart d’air, le fondamentalisme du modèle Purdue, la position selon laquelle l’OT et l’informatique appartiennent à des traditions d’ingénierie incommensurables qui doivent être rigoureusement séparées. Ce récit plus ancien a également échoué, pour les raisons que cet article examinera. Les systèmes industriels modernes ne peuvent pas fonctionner comme si les domaines IT et OT étaient isolés les uns des autres ; les réalités opérationnelles de la sécurité de la chaîne d’approvisionnement, de l’observabilité, du cycle de vie des logiciels et du déploiement du personnel nécessitent un niveau d’unification que nie l’ancien récit.
La position correcte est plus nuancée que les deux extrêmes. L’OT et l’IT diffèrent au niveau architectural – dans leurs objectifs d’optimisation, leurs modèles de confiance, leur sémantique de défaillance, leurs échelles de temps et leurs propriétés de réversibilité – et que ces différences ne sont pas des artefacts de l’histoire de l’organisation mais le reflet de faits physiques et opérationnels qu’aucun choix d’ingénierie ne peut dissoudre. Ils doivent rester architecturalement distincts. Dans le même temps, les pratiques opérationnelles qui les entourent — contrôle de version, sécurité de la chaîne d'approvisionnement, observabilité, automatisation du déploiement, développement du personnel — devraient être unifiées. Le lieu de cette unification est la couche de démarcation entre les deux domaines : en termes industriels, la passerelle.
La position peut être énoncée de manière compacte : distinction architecturale, unification opérationnelle. Cet article développe l’argumentation en huit sections. La première caractérise le récit de convergence et identifie ce qui y est correct. La seconde établit les propriétés architecturales qui distinguent l’OT de l’IT et soutient que ces propriétés sont essentielles et non accidentelles. La troisième diagnostique l’erreur conceptuelle dans le récit de convergence comme une erreur de catégorie. La quatrième examine les analogies historiques – les récits de convergence dans d’autres domaines – et les schémas par lesquels ils ont échoué. Le cinquième affronte les contre-arguments les plus forts. La sixième décrit le bon modèle architectural et le rôle de la couche de démarcation. Le septième discute des implications pour la pratique de l’ingénierie. Le huitième réaffirme et défend la thèse.
Le public visé est l'architecte, le responsable de l'ingénierie ou le stratège technique à qui l'on demande d'engager une organisation industrielle dans un programme de convergence et qui sent que le programme n'est pas tout à fait correct mais ne peut pas expliquer pourquoi.
Le récit de la convergence
Un argument clair nécessite une caractérisation claire de la position à laquelle on s’oppose. Le récit de convergence, dans sa forme dominante, contient ce qui suit :
La séparation historique entre OT et IT a été produite par des accidents organisationnels (écosystèmes de fournisseurs distincts, traditions d'ingénierie distinctes, processus d'approvisionnement distincts) plutôt que par une nécessité technique sous-jacente.
À mesure que les systèmes OT adoptent des protocoles standards (TCP/IP, OPC UA, MQTT), des systèmes d'exploitation standards (Linux, dans diverses variantes en temps réel et embarquées) et du matériel standard (x86 et ARM plutôt que des contrôleurs propriétaires), la base technique de la distinction s'érode.
Les pratiques opérationnelles cloud natives (intégration continue, observabilité, infrastructure en tant que code, orchestration de conteneurs) s'appliquent aussi bien aux charges de travail OT qu'informatiques.
Le point final mature de cette trajectoire est une architecture unifiée dans laquelle les charges de travail OT s’exécutent sur la même infrastructure, sont gérées par les mêmes outils et sont exploitées par le même personnel que les charges de travail informatiques. La distinction entre les deux devient une curiosité historique.
Plusieurs éléments de ce récit sont corrects, et la position avancée dans cet article les concède explicitement.
Il est vrai que les protocoles standards ont largement remplacé les protocoles propriétaires au niveau des couches supérieures de la communication industrielle. OPC UA [1] est devenu le protocole d'interopérabilité de facto pour les données d'usine, remplaçant des dizaines d'équivalents propriétaires. MQTT [2] domine la télémétrie vers le nord. TCP/IP est universel. La surface protocolaire qui distinguait l’OT de l’IT il y a une génération s’est considérablement dissoute.
Il est exact que les pratiques opérationnelles développées à l’origine pour les applications cloud natives s’appliquent aux charges de travail OT avec des résultats productifs. L'orchestration de conteneurs [3], la gestion de la configuration GitOps, l'observabilité basée sur OpenTelemetry [4] et les cadres de sécurité de la chaîne d'approvisionnement tels que SLSA [5] et Sigstore [6] ne sont pas simplement transférables aux déploiements industriels : ce sont des améliorations par rapport aux pratiques opérationnelles qui les ont précédés.
Il est vrai que la mobilité du personnel entre l’OT et l’IT augmente et que c’est sain. L’isolement historique de l’ingénierie OT des pratiques logicielles plus larges a produit des déficits documentés en termes de sécurité, de qualité du code et de maturité opérationnelle. L'échange de personnel et de pratiques entre les domaines a réduit ces déficits.
Là où le discours sur la convergence tourne mal, c’est dans sa conclusion. À partir des prémisses correctes selon lesquelles les protocoles ont convergé, les pratiques devraient converger et le personnel doit se mélanger, le récit tire la conclusion erronée que les architectures devraient également converger. Cette déduction ne suit pas. La distinction architecturale entre OT et IT ne se réduit pas à la distinction de protocole ou à la distinction de pratique ; elle reflète des propriétés qui survivent à la convergence des protocoles et des pratiques car elles ne sont pas des propriétés au niveau du protocole ou de la pratique.
La section suivante établit quelles sont ces propriétés.
Convergence pressure versus architectural separability
bar chartLes propriétés architecturales qui doivent rester distinctes
Ce qui distingue l’OT de l’IT, au niveau de l’architecture, n’est pas une liste de technologies mais un ensemble de propriétés structurelles qui sont valables quelle que soit la technologie qui les met en œuvre. Sept de ces propriétés méritent un examen explicite.
2.1 Le temps comme préoccupation architecturale de premier ordre
Dans les systèmes informatiques, le temps est, à de rares exceptions près, une contrainte douce. Une requête Web qui prend 200 ms est acceptable ; celui qui prend 2 s est dégradé mais fonctionnel ; celui qui prend 20 s est cassé mais généralement pas catastrophique. Le système est conçu en fonction d'objectifs statistiques de niveau de service (latence du 99e centile, latence du 99,9e centile) et une dégradation progressive sous charge est une vertu.
Dans les systèmes OT, le temps est une contrainte importante. Une boucle de contrôle de mouvement qui ne respecte pas son délai de 1 ms ne produit pas de résultat dégradé ; cela produit un résultat erroné, voire dangereux. Le système est conçu en fonction du temps d'exécution le plus défavorable, et non en fonction de distributions statistiques. Une dégradation progressive n'est pas une vertu mais un danger, car le système physique contrôlé ne se dégrade pas progressivement : il continue de fonctionner et l'absence d'entrée de contrôle correcte ne produit pas une réponse lente mais une réponse incorrecte.
Edward A. Lee de Berkeley a soutenu, au cours de deux décennies d’études sur les systèmes cyber-physiques [7][8], que cette différence n’est pas une différence quantitative dans les exigences de latence mais une différence qualitative dans la façon dont le temps entre dans l’architecture. Dans les systèmes informatiques, le temps est une propriété de performance. Dans les systèmes OT, le temps est une propriété d’exactitude. Les implications de cette distinction s'étendent à la conception de langages de programmation, d'ordonnanceurs, de protocoles de communication et de techniques de vérification. Ils ne peuvent pas être occultés en traitant une charge de travail OT comme une « charge de travail informatique à faible latence ».
Le discours sur la convergence traite systématiquement la latence comme une propriété quantitative que résoudront un matériel plus puissant et de meilleurs réseaux. Le diagnostic posé au niveau du doctorat est que la latence est un symptôme ; la propriété sous-jacente est le déterminisme, et le déterminisme est qualitativement différent d'une faible latence.
2.2 Modes de défaillance et asymétrie des conséquences
Lorsqu'un système informatique tombe en panne, le mode de défaillance est généralement la perte de disponibilité ou d'intégrité des informations. Les conséquences sont économiques (interruption de service, perte de transactions, atteinte à la réputation) et sont, dans l’écrasante majorité des cas, réversibles. Lost transactions can be replayed. Les données corrompues peuvent être restaurées à partir d'une sauvegarde. Les déploiements ayant échoué peuvent être annulés.
Lorsqu'un système OT tombe en panne, le mode de défaillance est généralement la perte du contrôle physique. Les conséquences incluent d’éventuels dommages aux équipements, à l’environnement ou à la vie humaine et sont, dans de nombreux cas, irréversibles. Un contrôleur qui libère le mauvais produit chimique, ouvre la mauvaise vanne ou commande la mauvaise trajectoire du moteur produit un effet physique qui ne peut pas être annulé en inversant une configuration.
Cette asymétrie de conséquence a des implications architecturales qu’aucun outil opérationnel ne peut dissoudre. Le régime de vérification auquel un système OT doit satisfaire avant son déploiement est qualitativement différent du régime de vérification qu'un système informatique doit satisfaire. Le processus de gestion du changement est différent. Le modèle de confiance est différent. Les modes de défaillance acceptables — fail-safe, fail-secure, fail-operational — n'ont pas d'analogues informatiques propres, car les systèmes informatiques n'ont généralement qu'un seul mode de défaillance, qui est fail-unavailable, et l'indisponibilité est rarement une condition de sécurité.
Le discours sur la convergence traite cette asymétrie comme un problème d’outillage : de meilleurs tests, une meilleure observabilité, un meilleur retour en arrière. Le diagnostic posé au niveau du doctorat est que l’asymétrie est structurelle et ne peut être effacée par l’outillage. Un système dont la défaillance peut libérer des matières radioactives, nuire à un travailleur ou contaminer un bassin versant n'est pas une version plus critique d'un système dont la défaillance peut faire perdre une transaction ; il s'agit d'une catégorie différente de système, nécessitant des primitives architecturales différentes.
2.3 Modèles de confiance : basés sur la zone ou basés sur l'identité
Les architectures modernes de sécurité informatique ont largement convergé vers une confiance basée sur l’identité. Le paradigme Zero Trust [9] soutient qu'aucune confiance implicite ne doit être accordée en fonction de la position du réseau ; chaque demande doit être authentifiée et autorisée sur la base de l'identité de son auteur. Ce modèle est approprié pour les systèmes informatiques, où les demandes sont généralement générées par des utilisateurs humains ou des comptes de service identifiables, et où le coût de la surcharge d'authentification est supportable.
Les systèmes OT ne correspondent généralement pas à ce modèle. Les initiateurs du trafic OT sont généralement des processus (contrôleurs, lecteurs, capteurs) sans identité naturelle au sens informatique du terme. Les protocoles qu'ils utilisent n'ont pas été conçus pour l'authentification. Les budgets de latence dans lesquels ils fonctionnent ne peuvent généralement pas prendre en charge la surcharge cryptographique de l'authentification par message. Le modèle de confiance apparu dans OT, codifié dans l'architecture de référence Purdue Enterprise [10] et affiné dans la norme CEI 62443 [11], est basé sur la zone : la confiance est accordée en fonction de la zone réseau dans laquelle réside un appareil, et les limites entre les zones sont appliquées par des conduits dont les protocoles et l'accès sont explicitement définis.
Le discours sur la convergence tend à considérer la confiance basée sur les zones comme une forme primitive de confiance basée sur l’identité, en attente de mise à niveau. Le diagnostic posé au niveau du doctorat est que la confiance basée sur les zones n’est pas primitive ; il est adapté aux types de systèmes qu’il régit. La confiance basée sur l'identité nécessite une identité, et les entités situées aux niveaux les plus bas d'un système industriel (un transmetteur de température, un commutateur de proximité, un solénoïde) n'ont pas d'identité naturelle. Les forcer à adopter un modèle identitaire produit des cérémonies sans sécurité ; la fourniture du certificat, la rotation et la révocation deviennent des frais administratifs sans gains de confiance correspondants.
L'architecture mature combine les deux modèles : la confiance basée sur l'identité au-dessus de la couche de démarcation (côté informatique), la confiance basée sur les zones en dessous (côté OT) et le contrôle explicite à la frontière. Il s’agit du modèle déjà codé par la norme CEI 62443, et la pression exercée par le discours de convergence pour l’abandonner au profit d’une confiance universelle basée sur l’identité représente une régression architecturale.
2.4 Asymétrie du cycle de vie
Un système informatique typique a un cycle de vie mesuré en années : trois à cinq pour le matériel, des mois à un an pour les versions logicielles majeures, des semaines ou des mois pour les correctifs de sécurité. Le cycle de vie suppose un engagement continu avec le système : il sera mis à jour fréquemment, remplacé régulièrement et mis hors service dans un horizon de planification.
Un système OT typique a un cycle de vie mesuré en décennies. Un contrôleur industriel déployé en 2005 peut encore être opérationnel en 2035. Le matériel, le micrologiciel, la configuration et la documentation doivent tous être pris en charge à cet horizon. La logique économique de dépréciation des équipements industriels, la logique réglementaire de sécurité des procédés et la logique opérationnelle de disponibilité des installations poussent toutes dans le sens d’une longue durée de vie.
Cette asymétrie a des implications architecturales faciles à sous-estimer. Les dépendances logicielles acceptables en informatique – s’appuyant sur des services cloud qui peuvent être obsolètes, sur des bibliothèques dont l’état de maintenance peut changer, sur des protocoles dont les spécifications peuvent évoluer – sont inacceptables en OT, car l’horizon temporel sur lequel le système OT doit fonctionner dépasse l’horizon de maintenance des dépendances. La réponse architecturale consiste à minimiser les dépendances externes, à privilégier les protocoles avec des spécifications stables depuis longtemps et à concevoir pour un fonctionnement hors ligne avec une dépendance limitée aux services distants.
Le discours sur la convergence tend à ignorer cette asymétrie en supposant que les cycles de vie eux-mêmes convergeront, c'est-à-dire que les systèmes OT adopteront des cycles de vie typiques de l'informatique. Le diagnostic posé au niveau du doctorat est que ce n’est pas possible, car les cycles de vie ne sont pas des choix techniques mais le reflet de calendriers d’amortissement du capital, de régimes réglementaires et d’exigences de continuité opérationnelle qui ne sont pas soumis aux préférences techniques.
2.5 Réversibilité
La propriété de réversibilité diffère entre OT et IT d’une manière qui est liée à l’asymétrie du mode de défaillance mais qui est logiquement distincte. En informatique, la plupart des actions sont réversibles : une modification de configuration peut être annulée, un déploiement peut être annulé, une transaction peut être annulée. Le modèle architectural du déploiement atomique avec restauration automatisée, au cœur de la pratique moderne du cloud natif, dépend de la réversibilité.
En OT, de nombreuses actions sont irréversibles au niveau du système. Un moteur qui a tourné vers une nouvelle position ne peut pas revenir en arrière pour annuler la rotation ; la nouvelle position est l'état du système. Un produit chimique qui a été ajouté à un processus ne peut pas être annulé. Une soudure réalisée ne peut pas être défaite. Le système de contrôle peut inverser ses commandes, mais les effets physiques des commandes passées persistent.
Cette asymétrie a des implications architecturales directes. Le modèle de déploiement typique de l'informatique (déployer, observer, restaurer si nécessaire) ne correspond pas à l'OT. Un changement d’OT qui produit des effets physiques involontaires ne peut pas être corrigé en annulant le changement. La réponse architecturale consiste à investir dans la vérification avant le déploiement, plutôt que de revenir en arrière après le déploiement. La simulation Hardware-in-the-loop, la vérification formelle des propriétés de sécurité et le déploiement par étapes avec validation physique explicite sont des pratiques spécifiques à l'OT qui n'ont pas d'équivalent informatique direct.
Le récit de convergence importe le modèle informatique d’observation et de retour en arrière dans des contextes OT où il est structurellement inapplicable. Ce n’est pas une question de maturité opérationnelle, c’est une question de réalité physique.
2.6 Déterminisme versus performance statistique
Les systèmes informatiques sont généralement optimisés par rapport à des mesures de performances statistiques : débit médian, latence de queue, taux d'erreur aux centiles. La machinerie mathématique de la théorie des files d'attente, les modèles architecturaux de délestage et de dégradation progressive, ainsi que la pratique opérationnelle des objectifs de niveau de service présupposent tous que la meilleure caractérisation des performances est statistique.
Les systèmes OT sont généralement optimisés par rapport à des mesures de performances déterministes : temps d'exécution dans le pire des cas, garanties strictes en temps réel, gigue limitée. La machinerie mathématique de l'analyse de la programmabilité, les modèles architecturaux de planification à priorités fixes et de conception axée sur les délais, ainsi que la pratique opérationnelle du comportement certifié dans le pire des cas présupposent tous que les performances doivent être caractérisées de manière déterministe.
Ce n'est pas la même propriété que la propriété time-as-correctness de la section 2.1 ; il s'agit d'une propriété architecturale connexe mais distincte. Un système peut avoir des délais stricts en temps réel (Section 2.1) et également être caractérisé statistiquement — la propriété de déterminisme (cette section) exige que l'architecture elle-même exclue toute variation statistique dans les dimensions pertinentes. L’argument de bout en bout appliqué au temps – la position selon laquelle les garanties temporelles ne peuvent pas être synthétisées de manière fiable à partir de primitives ne garantissant pas le temps – implique que le déterminisme doit être conçu à partir du bas de la pile, et non ajouté au sommet.
Le discours sur la convergence tend à considérer le déterminisme comme un cas particulier de faible latence, adressable par un meilleur matériel et des SLO plus stricts. Le diagnostic posé au niveau du doctorat est que le déterminisme n'est pas une extension quantitative d'une faible latence mais une propriété architecturale qualitative nécessitant différentes primitives de conception.
2.7 Rayon de souffle et confinement
Le rayon d’action d’une panne dans un système informatique est généralement limité par le système lui-même. Une défaillance dans un service de paiement entraîne des échecs de paiement ; un échec dans un service de recherche entraîne des échecs de recherche. Le monde physique n’est pas affecté ; le préjudice se limite au domaine de l’information.
Le rayon d’explosion d’une défaillance dans un système OT s’étend de par sa conception au monde physique. Une panne dans un système de contrôle du réseau électrique provoque des pannes de courant. Une panne dans un système de contrôle du traitement de l’eau produit de l’eau contaminée. Une défaillance dans un système de contrôle des transports produit des collisions. Le rayon de l'explosion est déterminé par le système physique sous contrôle, et non par le système de contrôle lui-même.
Cette asymétrie a des implications sur la conception architecturale des limites de confiance, de la segmentation et du confinement. Un système OT doit être conçu en partant du principe que sa défaillance entraînera des conséquences physiques, et l'architecture doit être structurée pour limiter ces conséquences – via des systèmes de verrouillage, des fonctions instrumentées de sécurité, une isolation physique, etc. L’architecture informatique typique, qui ne prévoit pas de confinement physique parce que les pannes informatiques ne l’exigent pas, est structurellement inadéquate lorsqu’elle est importée dans l’OT.
L'erreur conceptuelle : une erreur de catégorie
Le diagnostic erroné du récit de convergence n’identifie pas encore quel genre d’erreur il commet. Plusieurs diagnostics sont possibles : le récit pourrait être empiriquement erroné, techniquement mal informé ou culturellement biaisé. Le diagnostic avancé ici est qu'il commet une erreur de catégorie au sens de Gilbert Ryle [12] : il traite deux choses comme des membres d'une même catégorie qui, en fait, appartiennent à des catégories différentes, et les inférences tirées de ce traitement sont systématiquement fausses.
L'erreur de catégorie consiste à traiter un système de contrôle comme un service.
Un service, au sens informatique du terme, est un artefact logiciel qui accepte des demandes, produit des réponses et se caractérise par son contrat fonctionnel, ses propriétés de performance et sa disponibilité. Les services sont composés via des API. Ils évoluent horizontalement. Ils sont exploités par rapport à des objectifs de niveau de service. Les modèles architecturaux de conception orientée services (couplage lâche, apatride, idempotence, messagerie asynchrone) conviennent aux services.
Un système de contrôle, au sens OT, est un artefact logiciel qui participe à une boucle de rétroaction avec un processus physique. Il n'accepte pas les demandes au sens informatique ; il observe l'état physique et produit des sorties de contrôle. Il se caractérise non pas par un contrat fonctionnel mais par une spécification théorique du contrôle : marges de stabilité, rejet des perturbations, précision du suivi, temps de réponse. Il n’évolue pas horizontalement : il y a un processus physique à contrôler. Il est exploité non pas en fonction des SLO de disponibilité, mais en fonction des exigences de sécurité et de fiabilité dérivées des risques physiques du processus.
Lorsque le récit de convergence traite un système de contrôle comme un service, il importe des modèles architecturaux appropriés aux services et les applique à des systèmes qui ne sont pas des services. Les modèles échouent non pas parce qu’ils sont mal mis en œuvre, mais parce qu’ils sont catégoriquement mal appliqués. Le contrôle apatride est incohérent : le contrôle nécessite fondamentalement l’État. Les commandes idempotentes adressées à un actionneur physique sont incohérentes : l'état d'un actionneur évolue avec chaque commande, quelle que soit l'identité de la commande au niveau informatique. La composition des services ne reflète pas la structure d'un système de contrôle, qui est déterminée par la physique plutôt que par les contrats API.
L’erreur de catégorie explique pourquoi les architectures axées sur la convergence produisent si souvent des systèmes qui fonctionnent en développement et échouent en production. L'environnement du développeur, où le processus physique contrôlé est absent ou simulé, ne présente pas les propriétés qui distinguent le contrôle du service ; l'environnement de production, où le processus physique est présent et conséquent, présente pleinement ces propriétés.
L’erreur est réversible, mais seulement en reconnaissant que l’OT et l’IT sont des catégories différentes et en concevant en conséquence.
Analogies historiques : quand les récits de convergence échouent
Le récit de la convergence OT/IT n’est pas unique. Il appartient à une famille de récits de convergence qui sont apparus, avec plus ou moins de confiance, au cours de plusieurs décennies d’histoire de l’informatique. L’examen de la famille permet de clarifier à la fois pourquoi les récits sont constamment attrayants et pourquoi ils échouent constamment.
Le discours selon lequel « tous les systèmes deviennent distribués », très répandu dans les années 1990, soutenait que le succès des systèmes distribués rendrait obsolètes les systèmes centralisés. Le récit prédisait que les bases de données distribuées, les systèmes de fichiers distribués et le calcul distribué remplaceraient leurs prédécesseurs centralisés. Le bilan empirique est mitigé. Certaines charges de travail ont été distribuées ; d’autres sont restés obstinément centralisés parce que la centralisation était, pour ces charges de travail, le bon choix architectural. Le théorème CAP [13] en fournit une explication formelle : la distribution et la cohérence ne sont pas librement composables, et les charges de travail nécessitant une forte cohérence en cas de panne restent centralisées pour des raisons que les préférences techniques ne peuvent pas changer.
Le discours selon lequel « tous les logiciels deviennent Web », très répandu dans les années 2000, soutenait que les applications natives seraient remplacées par les applications Web. Le récit prédisait que l'informatique locale migrerait vers le navigateur, que les différences entre les systèmes d'exploitation deviendraient inutiles et que les applications de bureau rejoindraient la carte perforée de la préhistoire de l'informatique. Les données empiriques révèlent encore une fois une tendance plus complexe. Les applications Web ont capturé de nombreuses charges de travail, mais les applications natives ont persisté pour les charges de travail nécessitant une intégration matérielle étroite, un fonctionnement hors ligne ou une interface utilisateur riche. La convergence a été partielle et non totale.
Le discours selon lequel « le cloud va tout absorber », très répandu dans les années 2010, affirmait que l'informatique sur site se dissoudrait dans le cloud computing. Le récit prédisait que les centres de données se videraient, que les appareils de pointe deviendraient des terminaux minces et que le cloud deviendrait le substrat universel. Les données empiriques montrent à nouveau une convergence partielle suivie d'un contre-mouvement. L'adoption du cloud est importante, mais le mouvement de l'edge computing (voir [14] pour une enquête) représente une redistribution explicite du calcul hors du cloud, motivée par des aspects économiques de latence, de souveraineté et de bande passante que le récit de convergence n'a pas modélisé de manière adéquate.
Une tendance émerge à travers ces exemples. Les récits de convergence sont systématiquement biaisés en faveur de la prédiction de l’homogénéisation et sous-estiment systématiquement les forces qui maintiennent l’hétérogénéité architecturale. Les forces ne sont pas toujours les mêmes, mais elles partagent une structure commune : elles reflètent des réalités physiques, économiques ou opérationnelles qui ne sont pas soumises aux préférences techniques, et les récits de convergence qui les ignorent produisent des architectures qui échouent lorsque les réalités se réaffirment.
Le récit de la convergence OT/IT s’inscrit dans cette famille. Il sous-pondère les propriétés architecturales identifiées dans la section 2 – propriétés qui reflètent des réalités physiques et opérationnelles non soumises aux préférences techniques. Sa trajectoire empirique suivra probablement le modèle suivant : convergence partielle dans les domaines où la convergence est réalisable (outillage, pratique, personnel), suivie d'une réaffirmation de la distinction dans les domaines où la convergence est irréalisable (architecture, modèle de confiance, cycle de vie).
Faire face aux contre-arguments
Un plaidoyer sérieux doit s’attaquer aux formes les plus fortes de la position à laquelle il s’oppose. Cette section aborde quatre contre-arguments que les partisans de la convergence soulèvent régulièrement.
5.1 L’argument de la convergence des protocoles
OPC UA, MQTT et TCP/IP ont unifié efficacement la communication OT et IT. La distinction protocolaire s’est dissoute et la distinction architecturale suit.
L’argument est en partie correct et surtout faux. Les protocoles ont en effet convergé vers les couches supérieures. Mais la convergence des protocoles n’est pas une convergence architecturale. OPC UA est un protocole de bridging ; il permet à deux domaines architecturaux distincts d'échanger des données sans les fusionner. L’existence d’une langue commune entre deux cultures n’implique pas que les cultures soient identiques. Les francophones et les germanophones peuvent tous deux communiquer en anglais sans devenir la même culture ; Les systèmes OT et IT peuvent tous deux communiquer en OPC UA ou MQTT sans devenir la même architecture.
Le point le plus profond est que les distinctions architecturales identifiées dans la section 2 – sémantique temporelle, modes de défaillance, modèles de confiance, cycle de vie, réversibilité, déterminisme, rayon de souffle – ne sont pas des propriétés au niveau du protocole. Ce sont des propriétés des systèmes qui utilisent les protocoles. Deux systèmes utilisant OPC UA peuvent avoir des propriétés architecturales totalement différentes selon ce qu'ils font avec le protocole.
5.2 L'argument de la convergence Linux
Les automates modernes fonctionnent sous Linux. Les passerelles industrielles modernes fonctionnent sous Linux. Le noyau qui exécute les charges de travail OT est le même que celui qui exécute les charges de travail informatiques. La distinction OS a disparu et la distinction architecturale suit.
L’argument repose sur une prémisse vraie – Linux est effectivement devenu omniprésent dans l’informatique industrielle – et tire une conclusion incorrecte. Le noyau partagé n'implique pas une architecture partagée, car le régime opérationnel sous lequel le noyau s'exécute diffère profondément entre les contextes OT et IT.
Un système Linux configuré en OT fonctionne généralement avec le correctif PREEMPT_RT [15], avec des cœurs de processeur isolés dédiés aux charges de travail en temps réel, avec des démons non temps réel désactivés, avec une isolation explicite des ressources basée sur un groupe de contrôle et avec des paramètres de noyau réglés pour le déterminisme plutôt que le débit. Un système Linux configuré par l'informatique fonctionne avec le planificateur de stock, avec tous les cœurs disponibles pour une charge de travail générale, avec l'ensemble complet de services systemd et avec des paramètres de noyau réglés pour le débit plutôt que pour le déterminisme. Les deux systèmes utilisent la même source de noyau, de la même manière qu’une voiture de course de Formule 1 et une berline urbaine utilisent le même principe de moteur à combustion interne – vrai à un niveau de description, profondément trompeur au niveau de description qui compte pour les décisions techniques.
5.3 L'argument du cloud natif
L'orchestration de conteneurs, les maillages de services, les plateformes d'observabilité et GitOps ont prouvé leur valeur à l'échelle hyperscale. Il n’y a aucune raison pour que ces pratiques ne s’appliquent pas à l’ergothérapie. La distinction opérationnelle s’est dissoute et la distinction architecturale suit.
La prémisse de l'argument est correcte et la position avancée dans cet article l'admet explicitement. Les pratiques opérationnelles cloud natives s'appliquent de manière productive à l'OT. La question diagnostique est de savoir quelle conclusion s’ensuit.
La conclusion qui s’ensuit est celle d’une unification opérationnelle et non d’une convergence architecturale. La même chaîne d'outils qui gère les charges de travail informatiques peut gérer les charges de travail OT, avec une configuration appropriée. La même plateforme d'observabilité peut ingérer la télémétrie des deux domaines. Le même contrôleur GitOps peut gérer la configuration dans les deux domaines. C’est ce que la position avancée ici appelle unification opérationnelle, et c’est sans ambiguïté bénéfique.
Ce qui ne s’ensuit pas, c’est que les propriétés architecturales des charges de travail OT deviennent celles des charges de travail IT. Une charge de travail OT conteneurisée est toujours soumise à des délais stricts en temps réel, à des modes de défaillance irréversibles et à un cycle de vie de 20 ans. Le conteneur est un véhicule de déploiement, pas une transformation architecturale. Le fait que la même chaîne d’outils gère les deux domaines n’efface pas les différences entre les charges de travail exécutées par la chaîne d’outils.
5.4 L'argument du personnel
Les ingénieurs OT et les ingénieurs informatiques apprennent mutuellement leurs disciplines. Les équipes interfonctionnelles sont de plus en plus courantes. La distinction culturelle se dissout et la distinction architecturale suit.
La prémisse de l’argument est correcte et bienvenue. L’isolement historique de l’ingénierie OT de la pratique logicielle plus large était malsain dans les deux sens. Sa dissolution constitue un gain net.
La conclusion ne s’ensuit cependant pas, car les distinctions architecturales ne sont pas des artefacts culturels. Un ingénieur électricien qui apprend Python et un développeur backend qui apprend la logique à relais élargissent tous deux leur gamme, mais les systèmes qu'ils conçoivent doivent toujours respecter les propriétés architecturales des domaines pour lesquels ils conçoivent. Une équipe culturellement unifiée peut construire des systèmes architecturalement distincts ; en effet, c'est le bon modèle. La relation culture-architecture n’est pas symétrique.
Le bon modèle : distinction architecturale et unification opérationnelle
La position avancée ici n’est pas négative. Having argued that the convergence narrative fails, the paper must articulate the model it advocates in place of convergence. Le modèle comporte trois composantes.
Premièrement, une démarcation architecturale explicite entre les domaines OT et IT. L'architecture de référence Purdue Enterprise [10] et la CEI 62443 [11] fournissent déjà le cadre conceptuel : des zones avec des limites de confiance explicites, des conduits avec des protocoles explicites et des points de démarcation où les flux de données sont acheminés. Ce cadre doit être préservé et modernisé, et non abandonné. La modernisation consiste à remplacer l’hypothèse historique d’isolement physique par l’hypothèse contemporaine de contrôle explicite : les données circulent entre les zones, mais cela via des conduits délibérés, observables et contrôlables.
Second, asymmetric data flow across the demarcation. Telemetry flows from OT to IT in high volume; control flows from IT to OT in low volume and through carefully gated channels. L'asymétrie reflète l'asymétrie des conséquences (Section 2.2) et de la réversibilité (Section 2.5) : un paquet de télémétrie mal formé peut être abandonné en toute sécurité, tandis qu'une commande de contrôle mal formée peut produire des effets physiques irréversibles. The two flows should not be implemented symmetrically; they should reflect their differing safety and trust requirements.
Troisièmement, l'unification opérationnelle au-dessus de la couche de démarcation. La chaîne d'outils qui gère les charges de travail OT (gestion de la configuration, automatisation du déploiement, observabilité, sécurité de la chaîne d'approvisionnement) doit être la même chaîne d'outils qui gère les charges de travail informatiques, avec une configuration appropriée pour les propriétés spécifiques au domaine. Cette unification réalise les avantages des pratiques opérationnelles cloud natives sans compromettre les distinctions architecturales que les pratiques elles-mêmes ne dissolvent pas.
Le lieu naturel de la couche de démarcation, dans les déploiements industriels, est la passerelle. Un article précédent de cette série [14] soutenait que la passerelle est devenue le point d'équilibre de la vague de l'informatique de pointe ; l’argument ici est que la passerelle est également le point d’équilibre de la relation architecturale OT/IT. C’est le point où les deux domaines se rencontrent, où les flux de données sont médiés, où les frontières de confiance sont franchies sous contrôle explicite et où la chaîne d’outils opérationnels obtient une visibilité sur les deux côtés sans dissoudre la distinction entre eux.
Ce n’est pas une coïncidence fortuite. La passerelle se trouve à un emplacement architecturalement important précisément parce que son emplacement reflète la structure sous-jacente du problème : un point de médiation entre deux domaines qui partagent le trafic mais pas l'architecture.
Implications pour la pratique
La position avancée ici a des implications directes pour plusieurs catégories de pratique de l’ingénierie.
Pour la conception organisationnelle, cela implique que la prescription du récit de convergence – fusionner les organisations OT et IT – est en partie correcte et surtout fausse. The two organizations should share leadership, share tooling, share processes, and share personnel where the skills transfer. They should not be merged in their accountability for the architectural properties of their respective domains. La fonction d'ingénierie OT conserve la responsabilité des propriétés architecturales des systèmes OT, même lorsque la chaîne d'outils opérationnels est unifiée.
Pour l'approvisionnement, cela implique que la convergence des fournisseurs (sélectionner un seul fournisseur pour l'infrastructure OT et informatique) est généralement un mauvais choix. Les fournisseurs qui excellent dans l’infrastructure informatique ne sont pas, à de rares exceptions près, ceux qui excellent dans l’infrastructure OT. Les propriétés architecturales qui comptent du côté OT ne sont pas celles pour lesquelles les fournisseurs informatiques optimisent, et vice versa. Le bon modèle d'approvisionnement sélectionne les fournisseurs appropriés pour chaque domaine et investit dans la couche de démarcation qui les relie.
Pour la conception de logiciels, cela implique que les charges de travail qui franchissent la frontière OT/IT doivent être conçues avec l'asymétrie explicitement modélisée. Une charge de travail qui traite la télémétrie OT et l'expose aux consommateurs informatiques est structurellement différente d'une charge de travail qui accepte les commandes informatiques et les traduit en actionnement OT. Les deux ne doivent pas être confondus, même s’ils sont implémentés dans le même cadre conteneurisé.
Pour l'architecture de sécurité, cela implique que le modèle Zero Trust doit être adopté du côté informatique et le modèle basé sur des zones conservé du côté OT, avec une politique explicite au niveau de la couche de démarcation traduisant entre eux. Il convient de résister à la pression visant à étendre universellement le Zero Trust aux environnements OT lorsqu’elle produit des cérémonies sans gain de sécurité.
Pour la gestion du cycle de vie, cela implique que l'hypothèse d'un long cycle de vie des systèmes OT doit être respectée dans la conception des intégrations inter-domaines. Un service informatique qui s'intègre aux systèmes OT doit être conçu pour le cycle de vie informatique du côté informatique et pour le cycle de vie OT du côté OT, la couche d'intégration étant conçue pour relier les deux. La tentation d’imposer un cycle de vie informatique plus court du côté de l’OT, au nom de l’agilité, produit des systèmes que l’environnement OT ne peut pas supporter.
Argument final
La position peut être énoncée de manière compacte. Le récit de la convergence observe des prémisses correctes – selon lesquelles les protocoles, les pratiques et le personnel s’unissent au-delà de la fracture OT/IT – et tire une conclusion erronée, selon laquelle les architectures devraient également s’unifier. La distinction architecturale entre OT et IT ne se réduit pas à la distinction de protocole ou à la distinction de pratique ; il reflète les propriétés de la physique, les modes de défaillance, la confiance, le cycle de vie et la réversibilité qui survivent à la convergence des protocoles et des pratiques car ils opèrent à un niveau différent. Traiter un système de contrôle comme un service est une erreur de catégorie au sens de Ryle, et les échecs architecturaux qui résultent de cette erreur sont systématiques.
Le bon modèle est asymétrique : distinction architecturale aux niveaux où les distinctions sont réelles, unification opérationnelle aux niveaux où l'unification est réalisable et bénéfique, et une couche de démarcation délibérée à laquelle les deux domaines se rencontrent. Le lieu de cette démarcation, dans les déploiements industriels, est la porte d'entrée. Les investissements qui découlent de ce modèle – dans des primitives architecturales appropriées au domaine, dans une infrastructure de médiation au niveau de la couche de démarcation, dans des outils opérationnels partagés au-dessus de la démarcation – produisent des systèmes qui sont meilleurs que les systèmes que produiraient l’orthodoxie de la convergence ou l’orthodoxie de l’espace aérien.
La recommandation est directe. Résistez au discours de convergence qui conseille l’homogénéisation architecturale ; adoptez-le là où il conseille l’unification opérationnelle ; investir dans la couche de démarcation où les deux se rencontrent. Le résultat n’est pas un compromis mais une architecture plus solide que ce que l’une ou l’autre des positions pures donnerait.
Les mondes OT et IT ne deviendront pas un. Ils partageront de plus en plus une chaîne d’outils, une culture et une main-d’œuvre. La distinction restante – architecturale, fondée sur des principes et durable – n'est pas un résidu à éliminer mais une structure à préserver.
References
[1] Fondation OPC. Spécification d'architecture unifiée OPC, parties 1 à 100. 2008 à aujourd'hui.
[2] OASIS. MQTT version 5.0. Norme OASIS, 2019. ISO/IEC 20922:2016 couvre MQTT 3.1.1.
[3] B. Burns et coll. "Borg, Omega et Kubernetes." Communications de l'ACM, 59(5), 2016.
[4] Projet OpenTelemetry. Spécification OpenTelemetry. CNCF, 2019-présent.
[5] Google et coll. Niveaux de chaîne d'approvisionnement pour les artefacts logiciels (SLSA). Open Source Security Foundation, 2021-présent.
[6] Fondation Linux. Sigstore : signature de logiciels pour tout le monde. 2021-présent.
[7] E.A. Lee. "Systèmes cyber-physiques : défis de conception." 11e Symposium international de l'IEEE sur l'informatique distribuée en temps réel orienté objets et composants (ISORC), 2008.
[8] E.A. Lee. "L'informatique a besoin de temps." Communications de l'ACM, 52(5), 2009.
[9] Institut national des normes et de la technologie. Architecture Zero Trust. Publication spéciale NIST 800-207, 2020.
[10] T.J. Williams. L'architecture de référence Purdue Enterprise. Purdue Laboratory for Applied Industrial Control, 1992. ISA-95 (ANSI/ISA-95.00.01) fournit la formalisation contemporaine.
[11] Commission électrotechnique internationale. CEI 62443 : Réseaux de communication industriels — Sécurité des réseaux et des systèmes. 2009 à aujourd'hui (norme en plusieurs parties).
[12] G. Ryle. Le concept de l'esprit. University of Chicago Press, 1949. (Le chapitre 1 présente l'erreur de catégorie.)
[13] S. Gilbert et N. Lynch. "Conjecture de Brewer et faisabilité de services Web cohérents, disponibles et tolérants aux partitions." ACM SIGACT Actualités, 33(2), 2002.
[14] Série technique Modibus. "Du cloud à la périphérie : un examen critique des raisons pour lesquelles le calcul migre vers la couche passerelle." 2026.
[15] T. Gleixner et I. Molnar. PREEMPT_RT : correctifs de préemption en temps réel pour le noyau Linux. Linux Foundation, https://wiki.linuxfoundation.org/realtime/
[16] E.A. Lee et S.A. Seshia. Introduction aux systèmes embarqués : une approche des systèmes cyber-physiques. MIT Press, 2e éd., 2017.
[17] J. H. Saltzer, D. P. Reed et D. D. Clark. «Arguments de bout en bout dans la conception de systèmes». Transactions ACM sur les systèmes informatiques, 2(4), 1984.
[18] JH Saltzer et MD Schroeder. "La protection des informations dans les systèmes informatiques." Actes de l'IEEE, 63(9), 1975.
[19] ME Conway. "Comment les comités inventent-ils?" Datamation, 14(5), 1968. (Source de la loi de Conway.)
[20] R. M. Lee, M. J. Assante et T. Conway. Analyse de la cyberattaque sur le réseau électrique ukrainien. SANS ICS / E-ISAC, 2016.
[21] N. Fallière, L. O. Murchu et E. Chien. Dossier W32.Stuxnet. Symantec Security Response, 2011.
[22] M. Krotofil et J. Larsen. "Faites basculer le livre de poche : pirater des usines chimiques." DEF CON 23, 2015.
[23] J. Slowik. Évolution des attaques ICS et perspectives d'événements perturbateurs futurs. Dragos, 2019.
[24] E. Byres, A. Ginter et J. Langill. Comment Stuxnet se propage — Une étude des chemins d'infection dans les systèmes basés sur les meilleures pratiques. Tofino Security / Abterra / SCADAhacker, 2011.
[25] N.G. Leveson. Ingénierie d'un monde plus sûr : pensée systémique appliquée à la sécurité. MIT Press, 2011. (Traitement fondamental de la sécurité en tant que problème de contrôle.)
[26] J. Raison. Erreur humaine. Cambridge University Press, 1990. (Source du modèle de causalité des accidents « fromage suisse », pertinent pour l'analyse des défaillances des OT.)
[27] Société internationale d'automatisation. ANSI/ISA-95.00.01 : Intégration du système de contrôle d'entreprise — Partie 1 : Modèles et terminologie. 2010.
[28] R.Anderson. Ingénierie de sécurité : Un guide pour créer des systèmes distribués fiables. 3e éd., Wiley, 2020. (Chapitres sur la sécurité des systèmes de contrôle.)
[29] Série technique Modibus. "Les arguments en faveur des conteneurs dans l'industrie : pourquoi Docker est la base idéale pour les logiciels industriels modernes." 2026.
[30] Série technique Modibus. « MQTT vs OPC UA : quel protocole pour quelles données ? » 2026.
Cet article fait partie de la série technique Modibus. Modibus conçoit le niveau passerelle, la couche de démarcation architecturale au niveau de laquelle les domaines OT et IT se rencontrent sous un contrôle explicite. La plate-forme MB213 prend en charge les modèles de flux de données asymétriques, les primitives de médiation et les outils opérationnels décrits dans la section 6. Pour une discussion technique ou des demandes de renseignements sur la plate-forme, contactez [info@modibus.com](mailto:info@modibus.com).