Un DCS obsolète, c'est une épée de Damoclès : pièces introuvables, compétences qui disparaissent, risque d'arrêt non planifié. Migrer fait peur, car sur une unité continue l'arrêt coûte cher. La bonne nouvelle : un basculement bien préparé peut se faire dans une fenêtre courte, voire à chaud, sans perte de recettes ni de données.
Sommaire
Pourquoi repousser une migration coûte plus cher que la faire
Un système de contrôle en fin de support accumule des risques silencieux : cartes d'entrées-sorties qu'on ne trouve plus qu'en occasion, stations d'ingénierie sur des OS non maintenus, et une poignée de personnes qui savent encore comment il fonctionne. Le jour où l'une de ces briques lâche, l'arrêt n'est plus planifié — il est subi. C'est exactement le mécanisme que nous décrivons dans notre article sur l'obsolescence des automates.
Sur une unité continue, une heure d'arrêt non planifié se chiffre couramment en dizaines de milliers d'euros. Une migration planifiée, elle, se déroule dans une fenêtre maîtrisée — c'est toute la différence entre subir et décider.
La question n'est donc pas « faut-il migrer ? » mais « comment migrer sans transformer le remède en nouvelle panne ? ». La réponse tient d'abord dans la préparation, bien avant le jour du basculement. C'est le cœur de notre offre de migration & rétrofit.
Faire l'état des lieux avant de parler solution
Beaucoup de migrations dérapent parce qu'on a sauté l'étape la plus ingrate : comprendre finement l'existant. Un système en production depuis 15 ou 20 ans a presque toujours dérivé de sa documentation d'origine. Reconstituer la réalité — ce que fait réellement l'application, boucle par boucle — est un préalable non négociable.
- Relever et vérifier la totalité des entrées-sorties, y compris les signaux « oubliés »
- Récupérer les recettes, consignes, seuils d'alarme et paramètres de régulation
- Cartographier les interfaces avec les autres systèmes (SIS, MES, historian)
- Reconstituer ou mettre à jour l'analyse fonctionnelle
Sur un site chimique, un relevé sérieux révèle qu'une dizaine de pour cent des I/O documentées ne correspondent plus au terrain : capteurs déposés, forçages permanents oubliés, boucles modifiées « en vitesse » lors d'un arrêt. Migrer sans ce nettoyage, c'est recopier fidèlement les erreurs dans le système neuf.
Les trois stratégies de basculement
1. L'arrêt planifié (big bang)
On profite d'un arrêt programmé pour remplacer l'ensemble. C'est la stratégie la plus simple techniquement, mais elle exige que tout soit testé en amont : le moindre imprévu pendant la fenêtre d'arrêt se paie en heures de production perdues. Elle suppose un FAT/SAT impeccable.
2. La migration progressive (par tranches)
On bascule unité par unité, ou boucle par boucle, en faisant cohabiter ancien et nouveau système via des passerelles. Plus long et plus complexe, mais l'impact sur la production est étalé et réversible. C'est souvent le bon compromis sur un procédé continu qui ne peut pas s'arrêter longtemps.
3. La migration à chaud (hot cutover)
Le nouveau système est câblé en parallèle, testé, puis on transfère la conduite sans interrompre le procédé. C'est la plus exigeante — elle ne s'improvise pas — mais c'est parfois la seule option acceptable. Elle demande une expérience réelle de la mise en service sous contrainte de production.
Ce qui fait la réussite d'un basculement
Quelle que soit la stratégie, la migration se gagne avant le jour J, en ingénierie et en tests. Les basculements ratés ont presque toujours les mêmes causes : un existant mal documenté, des I/O non vérifiées, et l'absence de plan de repli.
- Application testée en simulation avant de toucher au procédé (FAT)
- Loop check complet réalisé sur site (vérification physique des boucles)
- Recettes et paramètres de régulation rejoués et validés
- Plan de repli documenté pour revenir en arrière en cas d'imprévu
- Bonnes personnes présentes pendant la fenêtre, y compris l'exploitation
Sous-estimer le câblage et le marshalling. Beaucoup de retards viennent non pas du logiciel, mais d'erreurs de raccordement découvertes trop tard. La vérification physique des boucles n'est jamais une formalité — voir notre article dédié au FAT/SAT.
Migrer, c'est aussi l'occasion de moderniser
Un rétrofit bien mené ne « refait pas à l'identique ». C'est le bon moment pour rationaliser les alarmes, intégrer la sûreté fonctionnelle dès la conception plutôt qu'après coup, préparer la cybersécurité OT et livrer une documentation propre. Le système que vos équipes exploiteront pour les 15 prochaines années mérite mieux qu'un copier-coller de l'ancien.
C'est aussi le moment de reprendre la supervision : des vues opérateur claires réduisent la charge mentale et les erreurs de conduite, un bénéfice qui dure bien au-delà du projet.
Combien de temps, combien ça coûte ?
Il n'existe pas de prix « au mètre » : le coût dépend du nombre de boucles, de la plateforme cible, du niveau de sécurité et des contraintes d'arrêt. C'est pourquoi nous chiffrons chaque migration après un diagnostic — voir notre page tarifs. Le meilleur point de départ reste un échange technique : demandez un diagnostic gratuit.
En résumé : la migration n'est pas un saut dans le vide si elle est préparée. C'est un projet d'ingénierie où l'essentiel du travail se fait avant le basculement — et où le plan de repli est votre meilleure assurance.
