Passer d'un PLC legacy à une solution modulaire sans arrêter la production est un exercice délicat que j'ai réalisé plusieurs fois au cours de ma carrière. C'est un équilibre entre contraintes opérationnelles, sécurité fonctionnelle, et impératifs de modernisation. Dans cet article, je partage ma méthode pragmatique, les techniques qui fonctionnent sur le terrain et les pièges à éviter. Mon objectif : vous donner un guide actionnable pour réussir une migration incrémentale, minimiser les risques et améliorer progressivement l'architecture d'automatisation.

Pourquoi migrer sans arrêt de production ?

La pression pour moderniser vient souvent de plusieurs directions : obsolescence matérielle, coûts de maintenance élevés, intégration difficile avec des systèmes SCADA/IIoT, ou besoin de flexibilité pour des projets d'efficacité énergétique. Or, l'arrêt de production pour une migration complète est rarement acceptable — coûts financiers, risques commerciaux et contraintes logistiques rendent la migration à chaud la meilleure option.

Je privilégie donc une approche par phases : analyser, prototyper, dupliquer, basculer localement, puis étendre. Cela nécessite une planification rigoureuse mais offre l'avantage de réduire l'impact opérationnel tout en apportant rapidement des bénéfices.

Évaluer l'existant : l'étape souvent sous-estimée

Avant toute modification, il faut cartographier précisément le système legacy :

  • liste des automates et versions de firmware,
  • topologie des E/S (centralisées vs distribuées),
  • protocoles de communication (Modbus, Profibus, EtherNet/IP, Profinet, OPC-UA),
  • interfaces opérateurs et scripts spécifiques,
  • boucles de sécurité et dépendances critiques.

    • J'insiste toujours sur la collecte de logs historiques et d'ordres de maintenance : ils révèlent les points faibles et les modules sujets à pannes. Une analyse de risque (FMEA simplifiée) oriente ensuite les priorités de migration.

    Stratégies pour migrer sans arrêt

    Voici les approches que j'utilise le plus souvent, avec leurs avantages et contraintes.

  • Proxy/Gateway : insérer un équipement intermédiaire qui traduit la communication entre le PLC legacy et le nouveau système. Idéal pour ajouter supervision IIoT sans toucher à la logique critique.
  • Dual-run (hot running) : faire fonctionner en parallèle le PLC legacy et la nouvelle plateforme sur des points non critiques, comparer entrées/sorties puis basculer progressivement.
  • Déport d'E/S : remplacer les modules d'E/S locaux par des I/O distribuées compatibles tout en gardant le cerveau PLC en place. Permet une modernisation matérielle en gardant la logique intacte.
  • Encapsulation de logique : réimplémenter des sous-fonctions dans des automates modulaires ou des contrôleurs edge et les connecter en mode parallèle pour vérification avant bascule.

    • Architecture modulaire recommandée

    Mon parti pris : séparer clairement contrôle, sécurité et supervision/data. Un schéma type que je déploie :

  • Contrôleurs modulaires (machines/process) basés sur des PLC modernes ou PAC (ex : Siemens S7-1500, Rockwell ControlLogix, Schneider Modicon) pour la logique de procédé.
  • Contrôleur de sécurité dédié (ex : Pilz, Siemens F-SoE) pour les fonctions SIL/PL.
  • Edge gateways et concentrateurs IIoT (ex : HMS, Moxa, Beckhoff) pour normaliser les protocoles et transmettre les données vers SCADA/Cloud via OPC-UA/MQTT.
  • Layer d'E/S distribuée pour rapprocher la connectique capteurs/actionneurs et réduire les câblages.

    • Techniques pratiques de bascule incrémentale

    Sur le terrain, j'applique ces tactiques pour minimiser l'impact :

  • Shadowing : faire tourner la nouvelle logique en lecture seule (sans actionner les sorties) et comparer ses décisions avec le PLC legacy pendant des jours/semaines.
  • Test sur banc : répliquer les séquences critiques sur un testeur dynamique ou une cellule d'essai. Les simulateurs de signaux (analogiques, numériques) sont très utiles pour reproduire conditions réelles.
  • Bascules locales avec permission : réaliser des bascules sur des sous-ensembles non critiques durant des fenêtres d'opération contrôlées, avec possibilité de rollback immédiat.
  • Monitoring renforcé : ajouter des métriques temps-réel et des alarmes spécifiques pour détecter toute divergence dès qu'elle apparaît.

    • Cas concret : migration d'une ligne de production

    Sur une ligne d'emballage, nous avons d'abord installé des gateways EtherNet/IP–Modbus pour collecter les données du PLC legacy. Ensuite :

  • nous avons déployé des I/O EtherCAT distribuées pour une section de convoyage (sans remplacer la logique centrale),
  • la nouvelle logique de positionnement a été développée et exécutée en shadow mode pendant 2 semaines,
  • après validation, la section a été basculée en mode commande par le contrôleur modulaire, avec rollback possible en 30 secondes grâce à un bypass physique,
  • progressivement, d'autres sections ont suivi : entraînements, dosage, puis supervision complète.

    • Résultat : zéro arrêt de production planifié, réduction des temps d'intervention matériels de 40% et meilleures capacités de diagnostic.

    Tests, validation et assurance qualité

    Les tests ne sont pas une option. Je recommande :

  • tests unitaires sur blocs fonctionnels du nouveau code,
  • tests d'intégration en shadow et en simulation,
  • tests d'interfaces pour chaque protocole et chaque I/O,
  • tests de performance pour s'assurer que le nouveau système répond aux contraintes cycliques.

    • Documentez chaque test et conservez les enregistrements. Ils serviront aussi de preuve lors d'audits sécurité ou qualité.

    Cybersécurité et sécurité fonctionnelle

    Mettre à jour l'automatisme sans prendre en compte la cybersécurité serait une erreur majeure. Mes règles pratiques :

  • segmenter le réseau OT/IT, utiliser des firewalls industriels,
  • mettre en place des gateways sécurisées (VPN, certificats) pour les accès distants,
  • gérer les comptes et droits via une politique d'authentification centralisée,
  • valider la sécurité fonctionnelle : toute modification impactant des fonctions de sécurité doit suivre le cycle V, avec réanalyse risque et tests SIL/PL.

    • Formation, documentation et acceptation opérationnelle

    Enfin, je ne peux insister assez sur l'importance d'associer les équipes opérationnelles dès le départ. Formation pratique, guides de procédures pour bascule et rollback, et sessions d'acceptation en conditions réelles garantissent l'appropriation.

    Approche Avantages Limites
    Gateway/Proxy Faible intrusion, rapide à déployer Ne remplace pas l'obsolescence matérielle
    Dual-run Comparaison en temps réel, sécurité Complexe à synchroniser, surcharge monitoring
    Déport d'E/S Réduction câblage, modernisation progressive Nécessite compatibilité physique et timings

    Si vous préparez une migration, commencez par un pilote ciblé sur une sous-section non critique : c'est là que l'on apprend le plus, à moindre risque. Si vous souhaitez, je peux vous aider à construire une check-list personnalisée pour votre site ou revoir votre architecture existante pour identifier les points d'optimisation.