Dans de nombreuses usines, la scène est la même : des automates programmables (API/PLC) installés il y a 15, 20 voire 30 ans, qui pilotent encore des équipements critiques. Ils tournent jour et nuit, sans faillir… jusqu’au jour où une carte lâche, où le fournisseur annonce l’arrêt définitif des pièces détachées, ou pire, où une faille de cybersécurité est exploitée.
Face à cette réalité, une question s’impose : comment moderniser ces systèmes d’automatisation sans mettre en danger la production, ni exploser les coûts et les délais ?
Un parc d’automates vieillissant, un risque désormais stratégique
Dans l’industrie, les cycles de vie des équipements sont longs. De nombreux sites s’appuient encore sur :
- des automates propriétaires dont l’OS et l’outillage de programmation ne sont plus maintenus,
- des bus de terrain fermés, difficiles à diagnostiquer et à intégrer avec les outils modernes,
- des PC industriels sous Windows XP ou 7, restés en l’état pour « ne pas casser ce qui fonctionne ».
Jusqu’à récemment, ce choix pouvait se défendre : les systèmes anciens étaient considérés comme stables, “déconnectés du monde” et amortis de longue date. Mais le contexte a profondément changé :
- la pression sur la disponibilité des lignes est maximale, avec des objectifs OEE ambitieux,
- les directions générales demandent une intégration accrue entre OT (atelier) et IT (ERP, MES, BI),
- les cyberattaques ciblant les environnements industriels se multiplient, avec des impacts potentiellement majeurs sur la production et la sécurité.
Résultat : maintenir des automates obsolètes n’est plus seulement une contrainte technique. C’est un risque business.
Pourquoi il est temps de passer à des architectures ouvertes et sécurisées
Moderniser son automatisation ne consiste pas uniquement à remplacer un automate par un modèle plus récent. C’est l’occasion de repositionner l’architecture de contrôle et de supervision autour de trois axes :
- Interopérabilité : bascule vers des standards ouverts (OPC UA, MQTT, Profinet, Ethernet/IP…) facilitant les échanges entre machines, SCADA, MES et outils d’analyse.
- Cybersécurité : intégration de mécanismes de sécurité dès la conception (segmentation réseau, durcissement des équipements, gestion des identités et des mises à jour).
- Scalabilité : possibilité d’ajouter de nouveaux équipements, de nouveaux capteurs, ou des briques d’IA/maintenance prédictive sans refonte complète de l’existant.
Dans les faits, les industriels qui migrent vers des architectures ouvertes observent généralement :
- une réduction des temps d’arrêt non planifiés grâce à une meilleure supervision et à un diagnostic plus rapide,
- un gain de temps lors des changements de série ou des reconfigurations de ligne,
- une baisse du TCO (Total Cost of Ownership) liée à la standardisation du matériel et des compétences.
Reste une inquiétude centrale : comment basculer sans mettre la production en péril ?
Les risques réels d’une migration mal maîtrisée
Les projets de migration d’automates échouent rarement pour des raisons purement techniques. Les difficultés viennent souvent de la préparation insuffisante et de la sous-estimation des impacts.
Les risques principaux identifiés sur le terrain sont :
- Perte de fonctionnalités “cachées” : comportements spécifiques implémentés au fil des ans, jamais documentés, et dont personne ne se souvient… jusqu’à ce qu’ils disparaissent après la migration.
- Temps d’arrêt prolongés : bascule planifiée sur un week-end qui se prolonge, faute de tests réalistes en amont ou de plan de retour arrière crédible.
- Incompatibilités avec des équipements périphériques : variateurs, capteurs, systèmes de pesée, contrôles qualité qui reposent sur des protocoles propriétaires ou des timings très serrés.
- Résistance des équipes : automaticiens, maintenance, opérateurs, peu associés en amont, qui découvrent le nouveau système le jour J, avec une courbe d’apprentissage sous-estimée.
La bonne nouvelle : ces risques peuvent être largement maîtrisés avec une approche structurée, inspirée des meilleures pratiques de l’ingénierie système et des retours d’expérience des sites déjà passés par cette étape.
Méthodologie de migration : une feuille de route en étapes clés
Un projet de migration réussi commence rarement par le choix d’un automate. Il commence par un diagnostic et une cartographie.
1. Cartographier l’existant, sans rien oublier
L’objectif n’est pas uniquement de lister les automates. Il s’agit de documenter l’ensemble de la chaîne de contrôle :
- automates installés, versions de firmware, IDE utilisés,
- équipements connectés (I/O, variateurs, robots, systèmes de vision, HMI…),
- réseaux et bus de terrain (Profibus, Modbus, CAN, asi, réseaux propriétaires…),
- interfaces avec le reste du SI (SCADA, MES, ERP, bases de données, systèmes de traçabilité).
Cette phase est souvent l’occasion de redécouvrir des éléments « oubliés » : une liaison série avec un équipement critique, une logique de sécurité partiellement câblée, ou des scripts tournant sur un vieux PC industriel.
2. Qualifier les risques et prioriser les zones à migrer
Plutôt que de tout changer d’un coup, il est généralement plus pertinent de prioriser :
- les automates en fin de vie (EoL) ou dont les pièces ne sont plus disponibles,
- les zones de production à forte criticité business (goulots d’étranglement, lignes à forte marge),
- les segments les plus exposés au risque cyber (liaisons OT/IT, télémaintenance, accès distants).
Cette priorisation permet de bâtir un plan pluriannuel réaliste, aligné avec les arrêts de maintenance et les capacités de financement.
3. Définir l’architecture cible “ouverte et sécurisée”
C’est à ce stade que les choix techniques structurants doivent être faits :
- standardisation sur 1 à 2 gammes d’automates pour tout le site,
- choix des protocoles de communication (OPC UA, MQTT, Profinet, etc.),
- définition d’une architecture réseau segmentée (cellules de production, DMZ industrielle, accès distants sécurisés),
- règles de développement logiciel (naming, structuration des blocs, gestion des versions).
L’enjeu est de construire une cible suffisamment standardisée pour réduire la complexité et les coûts de maintenance, sans figer l’avenir.
4. Prototyper et tester en environnement hors production
Transposer un programme d’automate ancien vers un automate moderne “au kilomètre” est rarement une bonne idée. Mieux vaut :
- identifier un périmètre pilote (machine isolée, maquette d’armoire, jumeau numérique si disponible),
- reprendre la logique en la documentant et en la structurant (fonctions, blocs réutilisables),
- tester les scénarios normaux, dégradés et de sécurité en environnement contrôlé,
- impliquer les équipes de maintenance et les opérateurs dans les tests.
Cette phase pilote permet de valider les choix d’architecture, la performance des réseaux, la compatibilité des équipements, et de mesurer la courbe d’apprentissage réelle des équipes.
5. Organiser la bascule et sécuriser le redémarrage
La bascule ne devrait jamais être un saut dans le vide. Quelques principes issus des retours d’expérience :
- planifier la migration sur un arrêt déjà prévu, avec un temps tampon réaliste,
- mettre en place un plan de retour arrière documenté et testé (capacité à revenir sur l’ancien automate en cas de blocage majeur),
- prévoir une présence renforcée des automaticiens et de l’intégrateur pendant les premières heures de redémarrage,
- enregistrer et analyser les incidents post-démarrage pour ajuster rapidement les paramètres et les programmes.
Une fois cette première migration maîtrisée, les itérations suivantes deviennent plus rapides et plus fiables, car l’organisation a capitalisé sur une méthode et des standards communs.
Intégrer la cybersécurité dès la conception, pas en “surcouche”
La modernisation des automates est le moment idéal pour corriger un biais historique : l’ajout de la cybersécurité en fin de projet, comme une contrainte supplémentaire. Dans un environnement connecté, cette approche ne fonctionne plus.
Quelques axes concrets, applicables dès la phase de design :
- Segmentation réseau : séparer clairement les réseaux de supervision, de contrôle, de sécurité machine et les accès distants. Limiter les flux au strict nécessaire.
- Gestion des accès : définir des profils d’utilisateurs, éviter les comptes partagés “admin” sur les automates, mettre en place une traçabilité des actions critiques.
- Mises à jour et correctifs : planifier des fenêtres de mise à jour logicielle et firmware, avec des procédures de test, au lieu de laisser des systèmes inchangés pendant 10 ans.
- Durcissement des configurations : désactiver les services non utilisés, changer les mots de passe usine, limiter les ports ouverts par défaut.
- Supervision de la sécurité OT : déployer des sondes ou outils adaptés aux environnements industriels pour détecter les comportements anormaux sur les réseaux de contrôle.
Cette démarche est d’autant plus efficace qu’elle est menée en coopération étroite entre les équipes OT, IT et RSSI. Les projets de migration sont une opportunité rare de les faire travailler ensemble autour d’un objectif commun.
Retours d’expérience : trois situations fréquentes sur le terrain
Les cas concrets permettent de mieux visualiser les enjeux et les leviers.
Site agroalimentaire multi-lignes
Un groupe agroalimentaire s’appuyait sur une douzaine de lignes de conditionnement, équipées de différents automates propriétaires en fin de vie. Pièces détachées rares, documentation partielle, et un objectif : réduire de 20 % les temps d’arrêt non planifiés.
La stratégie retenue :
- standardisation progressive sur une gamme unique d’automates et un protocole Ethernet temps réel,
- migration ligne par ligne, calée sur les renouvellements d’équipements de dosage et de pesée,
- mise en place d’un SCADA unifié et d’un OPC UA pour l’échange de données vers le MES.
Résultat sur 24 mois : disponibilité globale des lignes +6 points, temps moyen de diagnostic divisé par 2 grâce à une meilleure remontée d’alarmes et de données process.
Usine de pièces automobiles, forte contrainte de cadence
Un site de production de pièces automobiles disposait de lignes automatisées anciennes, avec des automates obsolètes mais extrêmement optimisés pour la cadence. La crainte majeure : perdre cette performance en migrant.
Les choix déterminants :
- création d’un jumeau numérique simplifié de la section la plus critique pour tester les nouvelles logiques de contrôle,
- migration d’abord sur une seule machine “miroir”, en maintenant une ligne complète en production avec l’ancien système,
- calibrage fin des temps de cycle et des échanges réseau avant généralisation.
Le site a finalement intégré la nouvelle architecture sans perte de cadence, en gagnant en flexibilité sur les changements de référence.
Site chimique, exposition accrue au risque cyber
Un site chimique, soumis à des contraintes réglementaires fortes, avait vu se multiplier les accès distants non maîtrisés (télémaintenance, supervision à distance…). Avec des automates et PC de supervision non à jour, le niveau de risque cyber était jugé critique.
La réponse :
- migration progressive des automates les plus exposés vers des modèles supportant des protocoles sécurisés,
- mise en place d’une DMZ industrielle et de sauts de rebond pour tous les accès distants,
- segmentation fine entre les réseaux de sécurité instrumentée (SIS) et de contrôle classique (BPCS).
Au-delà du renouvellement technique, c’est la gouvernance des accès OT qui a été revue, avec une visibilité accrue du RSSI sur les flux entre l’usine et l’extérieur.
Checklist opérationnelle pour préparer une migration sans rupture
Pour passer à l’action, une checklist synthétique peut servir de base de travail aux responsables industriels et à leurs équipes.
- Inventorier tous les automates, PC industriels, réseaux et interfaces OT/IT existants.
- Identifier les éléments en fin de vie ou non supportés par les fournisseurs.
- Cartographier les flux de données critiques, y compris les accès distants et la télémaintenance.
- Prioriser les zones à migrer en fonction de la criticité business, du risque cyber et des contraintes de maintenance.
- Définir une architecture cible standardisée, basée sur des protocoles ouverts et une segmentation réseau adaptée.
- Choisir des partenaires (intégrateurs, constructeurs) capables de s’engager sur des résultats, pas seulement sur des moyens.
- Lancer un pilote sur un périmètre maîtrisé, avec objectifs mesurables (disponibilité, temps de diagnostic, facilité de changement de format…).
- Formaliser les standards de programmation, de documentation et de gestion de versions des automates.
- Intégrer la cybersécurité dans toutes les étapes : conception, déploiement, exploitation, maintenance.
- Prévoir un plan de formation pour les automaticiens, la maintenance et les opérateurs, avec un accompagnement de proximité au démarrage.
- Mettre en place des indicateurs de suivi post-migration : disponibilité, MTTR, incidents de sécurité, coûts de maintenance, satisfaction des équipes.
La modernisation des systèmes d’automatisation n’est plus un sujet que l’on peut repousser indéfiniment. C’est une transformation progressive, à piloter comme un projet industriel à part entière, avec un cap clair : des architectures ouvertes, sécurisées et maîtrisées, au service de la performance opérationnelle.