Ressources

Repères pour mieux comprendre la convergence IT/OT

Des thèmes, guides et notes de réflexion pour aider les organisations à structurer leurs environnements opérationnels critiques.

Comprendre la convergence IT/OT

Pourquoi le rapprochement entre systèmes opérationnels et IT transforme les architectures, les risques et la gouvernance.

Pendant des décennies, l'IT et l'OT ont évolué séparément — des cultures, des priorités et des cycles de vie différents. L'IT privilégie la flexibilité, les mises à jour fréquentes et la connectivité. L'OT privilégie la stabilité, la disponibilité et la continuité opérationnelle.

La convergence change cet équilibre. Les systèmes terrain sont maintenant connectés aux réseaux d'entreprise, aux plateformes infonuagiques et aux outils d'analyse. Cette connectivité apporte de la visibilité — mais elle expose aussi des systèmes qui n'ont pas été conçus pour être connectés.

Bien gérer cette convergence, c'est comprendre les deux mondes : leurs contraintes, leurs dépendances et leurs priorités respectives — avant de concevoir, connecter ou sécuriser quoi que ce soit.

Vous reconnaissez cette situation? Discutons-en →

Moderniser sans compromettre l'exploitation

Les facteurs à considérer avant de connecter, migrer ou remplacer des systèmes opérationnels critiques.

Moderniser un système OT n'est pas la même chose que moderniser un système IT. En IT, une migration mal planifiée cause des inconvénients. En OT, elle peut arrêter une ligne de production, interrompre un service critique ou créer un risque pour la sécurité des personnes.

Avant toute intervention, il faut comprendre : quelles sont les dépendances réelles du système? Quelles sont les fenêtres de maintenance disponibles? Quels sont les impacts d'une interruption, même brève? Le système cible est-il compatible avec les contraintes temps réel existantes?

La modernisation maîtrisée, c'est évoluer sans déstabiliser — en séquençant les changements, en documentant chaque étape et en impliquant les équipes terrain dès le départ.

Vous reconnaissez cette situation? Discutons-en →

L'OT, c'est quoi exactement?

Tout système qui mesure, contrôle ou actionne quelque chose dans le monde physique — capteurs, automates, domotique, IoT, sites distants — c'est de l'OT.

L'OT regroupe tous les systèmes informatiques qui interagissent directement avec le monde physique — bien au-delà des usines et des salles de contrôle traditionnelles.

Un thermostat intelligent, un système de contrôle d'accès, une caméra de surveillance réseau, un capteur de pression sur une conduite, un automate de signalisation ferroviaire, un système de navigation maritime — tous sont de l'OT.

Ce qui les distingue de l'IT : une interruption n'est pas juste un inconvénient. Elle peut avoir des conséquences physiques, opérationnelles ou sécuritaires directes.

En environnement OT, la cybersécurité ne doit jamais primer sur la sécurité machine ni sur la sécurité physique des personnes. Ces deux priorités sont non négociables — toute mesure de sécurité informatique qui les compromet est une mauvaise mesure, peu importe sa justification technique. C'est pourquoi l'OT demande une approche fondamentalement différente de l'IT.

Vous reconnaissez cette situation? Discutons-en →

Pourquoi documenter les flux IT/OT

Matrices de flux, dépendances, accès fournisseurs et cartographie : des bases essentielles pour sécuriser et maintenir.

On ne peut pas sécuriser ce qu'on ne connaît pas. Et en environnement IT/OT, les flux sont souvent mal documentés, voire inconnus — communications entre automates, accès fournisseurs, interfaces avec les systèmes d'entreprise, protocoles hérités.

Documenter les flux, c'est cartographier qui parle à qui, sur quel protocole, avec quel niveau d'accès et pour quelle raison. C'est identifier les dépendances implicites, les accès non contrôlés et les chemins de communication qui n'auraient jamais dû exister.

C'est aussi recenser les actifs terrain — équipements, contrôleurs, capteurs, passerelles — pour éviter le shadow OT : ces systèmes présents sur le réseau, fonctionnels, mais inconnus de l'équipe responsable. Un actif non répertorié est un actif non surveillé, non maintenu et non sécurisé.

Cette documentation devient la base de tout : segmentation réseau, contrôles d'accès, réponse aux incidents, audits et évolution de l'architecture. Sans elle, chaque décision repose sur des hypothèses — pas sur des faits.

Vous reconnaissez cette situation? Discutons-en →

Référentiels IT/OT

NIST, Purdue, ISA/IEC 62443, ITSG (Canada) : comment les utiliser sans les appliquer mécaniquement.

Les référentiels IT/OT sont des outils — pas des recettes. NIST SP 800-82 couvre la sécurité des systèmes OT. Le modèle Purdue structure les niveaux d'une architecture IT/OT. ISA/IEC 62443 encadre la sécurité des systèmes d'automatisation. ITSG (Canada) fournit des guides applicables aux systèmes sensibles dans le contexte canadien.

Mais aucun référentiel ne connaît votre environnement, vos contraintes terrain, vos systèmes hérités ou vos priorités opérationnelles. Appliqués mécaniquement, ils peuvent mener à des décisions inadaptées — voire contre-productives.

L'approche RĒSUNIX consiste à utiliser ces cadres comme points de repère et non comme listes de contrôle — en les adaptant au contexte réel du mandat. D'autres référentiels sectoriels ou réglementaires peuvent également s'appliquer selon les besoins du client.

Vous reconnaissez cette situation? Discutons-en →

Formation des équipes

Créer un langage commun entre IT, OT, ingénierie, opérations, maintenance et gestion.

L'un des plus grands défis de la convergence IT/OT n'est pas technique — c'est humain. Les équipes IT et OT ont des cultures, des priorités et des vocabulaires différents. Ce qui est évident pour un automaticien ne l'est pas pour un administrateur réseau, et vice versa.

La formation chez RĒSUNIX n'est pas un cours standard. Elle est construite selon les besoins réels : qui a besoin de comprendre quoi, pour prendre quelles décisions, dans quel contexte opérationnel.

L'objectif est concret — que les équipes IT comprennent les contraintes terrain, que les équipes OT comprennent les enjeux cyber, et que la gestion dispose d'une lecture commune des risques et des priorités. Un langage partagé, c'est la base d'une architecture qui tient dans le temps.

Vous reconnaissez cette situation? Discutons-en →