Migration PCS7 v7 vers v9 : plan en 6 phases sans casser la production pharma

Sur un site pharma suisse, arrêter une ligne de production une journée coûte entre 80'000 et 250'000 CHF selon le produit. Migrer le SCADA est rarement une priorité tant que tout fonctionne. Sauf que Siemens a annoncé la fin du support standard de PCS7 v7 en 2020, l'arrêt du support étendu en 2025, et que Windows Server 2008 (sur lequel tournent encore beaucoup de v7) ne reçoit plus aucun patch. Sur le terrain, nous voyons régulièrement des sites en v7.1 SP2 avec 12 à 15 ans de production accumulée, des lots GMP validés, et une peur légitime de tout casser.

Ce guide décrit la méthodologie en six phases que nous appliquons chez nos clients pharma de Suisse romande pour migrer vers PCS7 v9.1 sans perdre une seule heure de run de production. Les chiffres et exemples viennent de projets réels, anonymisés.

Pourquoi migrer maintenant, vraiment

La fin du support n'est pas un argument suffisant pour un comité d'investissement pharma. Ce qui fait basculer la décision, c'est presque toujours une combinaison de trois facteurs.

D'abord la sécurité. Un PCS7 v7 sur Windows Server 2008 est exposé à des CVE non patchées, et l'auditeur Swissmedic ou FDA pose la question depuis 2022. Sur un site, nous avons vu un audit interne lever 14 non-conformités liées à l'obsolescence, dont 4 critiques. Le coût de remédiation court terme dépassait celui d'une migration complète.

Ensuite la compatibilité matérielle. Les nouveaux serveurs HPE ou Dell ne sont plus certifiés pour Server 2008, et les drivers manquent. Quand un disque lâche, on ne trouve plus de pièce de rechange compatible BIOS.

Enfin l'intégration MES et data historian. PCS7 v9 expose nativement OPC UA avec sécurité certificat, ce que la v7 ne fait que via add-ons fragiles. Si vous déployez un MES type Werum PAS-X ou Körber, la v9 devient un prérequis technique et non un confort.

Notre offre [automation industrielle](/services/automation) et [architecture de systèmes](/services/architecture) intègre cette analyse coût-bénéfice dans le cadrage initial.

Les risques réels d'une migration ratée

Avant de parler méthode, il faut nommer les vrais risques. Trois catégories nous occupent.

La perte de run en production. Un FB modifié sans test exhaustif peut générer un comportement déterministe différent (typiquement sur les regulators PID après recompilation v9). Sur un bioréacteur ou un lyophilisateur, cela se traduit par un lot écarté, donc 200'000 à 800'000 CHF perdus.

Les écarts GMP. Toute modification du système de contrôle automatisé doit être validée selon GAMP 5. Une migration mal documentée invalide la qualification existante. L'auditeur demande alors une re-validation complète, ce qui ajoute 6 à 9 mois au projet.

La perte de l'historique. Les bases PH (Process Historian) v7 et v9 ne sont pas binairement compatibles. Une mauvaise stratégie de migration archivistique fait perdre 5 à 10 ans de données de batch, ce qui est inacceptable pour la traçabilité GxP.

Phase 1, audit de l'existant (2 à 4 semaines)

L'audit n'est pas un inventaire de licences. C'est une cartographie technique et fonctionnelle complète. Nous documentons systématiquement.

Le hardware AS (Automation System) avec références CPU exactes, taille mémoire, charge cyclique réelle. Une CPU 417-4H à 78 pour cent de charge ne supportera pas l'ajout de blocs de communication OPC UA en v9.

Les versions de firmware sur chaque rack ET200, chaque CP 443-1, chaque coupleur PROFIsafe. Les listes de compatibilité Siemens entre firmware AS et version PCS7 sont strictes et conditionnent la migration.

Le code automate par charge fonctionnelle. Un projet PCS7 v7 contient typiquement 40 à 200 CFC, 100 à 500 SFC, et 20 à 80 faceplates personnalisés. Tous ne migrent pas avec le même effort. Les blocs custom écrits en SCL ou CFC inline demandent une attention particulière.

L'architecture réseau, en différenciant les bus terrain (PROFIBUS DP, PROFINET IO), le bus système et le bus terminal. Les redondances H-System ajoutent une couche de complexité sur la phase de bascule.

Sortie de cette phase, un dossier d'audit de 60 à 120 pages avec une matrice de risques par item. Sans cela, le chiffrage du projet est de la voyance.

Phase 2, cadrage et architecture cible (3 à 5 semaines)

Cette phase produit la spécification fonctionnelle de l'environnement v9.1. Quatre décisions structurent tout le reste.

La stratégie matérielle. Soit on conserve les AS et on ne migre que la partie OS/ES (option dite "OS-only migration"), soit on remplace aussi les CPU. La première option permet une bascule en 4 à 8 heures par AS, la seconde demande un arrêt de 24 à 72 heures et une re-qualification fonctionnelle.

Le choix Windows Server. PCS7 v9.1 supporte Server 2019 et 2022. Pour un site avec horizon 10 ans, nous recommandons systématiquement Server 2022, plus aligné avec les politiques IT corporate.

La stratégie de virtualisation. Hyper-V reste la référence Siemens, mais VMware vSphere est validé depuis v9.0. Si l'IT site est full VMware, autant rester homogène pour l'exploitation.

L'intégration MES, historian et active directory. Trop de migrations échouent parce que ces dépendances sont découvertes en phase de test. Les interfaces doivent être documentées dès le cadrage.

Le livrable est un FDS (Functional Design Specification) signé par production, qualité, IT et automation. Sans ces quatre signatures, ne lancez pas la suite.

Phase 3, environnement de test miroir (4 à 8 semaines)

C'est la phase où l'on construit physiquement la nouvelle plateforme, mais hors production. L'objectif est d'avoir un système v9.1 qui fonctionne avec une copie du code v7, simulant la totalité de la chaîne.

Nous installons un AS de test (souvent une CPU 410-5H pour rester cohérent avec la cible), des serveurs OS et ES virtualisés, et nous restaurons une image récente du projet de production. La conversion v7 vers v9 se fait via le PCS7 Migration Tool, qui automatise environ 80 pour cent du travail.

Les 20 pour cent restants sont les vrais sujets. Faceplates avec ActiveX obsolètes (à remplacer par WPF), scripts VBS qui doivent être convertis ou réécrits, alarms shelf custom à reconnecter, intégrations OPC DA à migrer vers OPC UA.

Cette phase produit aussi le harnais de test. Nous écrivons typiquement 200 à 600 cas de test fonctionnels, structurés par charge automatisme. Cela paraît énorme, c'est en fait le minimum pour rester crédible face à un auditeur GxP.

Phase 4, migration par lot avec tests non-régression (6 à 16 semaines)

Plutôt que migrer tout en bloc, nous découpons en lots fonctionnels cohérents. Sur un site pharma typique, cela donne 5 à 12 lots correspondant à des unités de procédé (préparation, transfert, fermentation, formulation, conditionnement primaire).

Pour chaque lot, le cycle est identique. Conversion du code v7 vers v9 sur l'environnement de test, exécution des cas de test associés, correction des écarts détectés, revue de code croisée entre deux automaticiens, signature qualité du dossier de test.

Les tests non-régression sont ce qui distingue une migration sérieuse d'une migration optimiste. Concrètement, nous comparons trace par trace les valeurs PID, les temps de cycle SFC, les déclenchements d'alarmes entre v7 et v9 sur les mêmes scénarios. Un écart supérieur à 0,5 pour cent sur un setpoint demande investigation.

C'est aussi pendant cette phase que se découvrent les surprises. Un FB de calcul de ratio qui retournait NaN dans certaines conditions sous v7 et qui retourne désormais 0 sous v9, parce que la gestion des float a changé. Sur un dosage produit, cela peut créer un OOS (Out Of Specification). Nous l'avons vu, l'écart représentait 30'000 CHF de produit perdu en simulation.

Notre équipe [CQV pharma](/services/cqv) intervient sur cette phase pour produire les protocoles IQ, OQ, PQ et la matrice de traçabilité GAMP 5.

Phase 5, qualification et préparation bascule (4 à 6 semaines)

Une fois tous les lots testés en environnement miroir, on prépare la bascule. Cette phase couvre trois dimensions.

La qualification formelle. Exécution des protocoles IQ (Installation Qualification), OQ (Operational Qualification), PQ (Performance Qualification) sur l'environnement cible. Chaque résultat est tracé, signé, archivé. Un site pharma sérieux génère ici 800 à 1500 pages de documentation.

La formation des opérateurs et techniciens maintenance. Les nouveautés v9 (faceplates redesigned, nouvelle gestion alarmes, OPC UA) demandent typiquement 8 à 16 heures de formation par profil. Ne pas faire l'impasse, c'est ce qui génère les appels nocturnes les premières semaines après bascule.

Le plan de rollback. Avant chaque bascule de lot en production, on doit pouvoir revenir à v7 en moins de 2 heures si un problème majeur apparaît. Cela suppose des images systèmes prêtes, des procédures testées, et idéalement une fenêtre de bascule pendant un arrêt programmé.

Phase 6, bascule production (1 à 4 semaines)

La bascule réelle est la phase la plus stressante mais aussi la plus courte si tout le reste a été bien fait. Nous procédons toujours par lot fonctionnel et toujours pendant des fenêtres de production planifiées (CIP/SIP, changement de campagne, week-end maintenance).

Pour chaque lot, le déroulé type est, sur 16 à 24 heures. Sauvegarde complète v7 (image système plus dump base de données plus archives historian récentes). Bascule physique du PG sur la nouvelle ES, chargement du projet v9 validé, transfert AS avec contrôle CRC, démarrage progressif en mode supervisé. Tests de production sur un sous-ensemble (typiquement un équipement non critique du lot d'abord), puis montée en charge progressive sur 8 à 12 heures.

Pendant les 72 premières heures, nous maintenons une astreinte renforcée avec automaticien sur site. Au-delà de J+30 sans incident majeur, nous considérons le lot comme stabilisé.

Sur notre dernier projet pharma à Vaud, 9 lots migrés en 14 mois, zéro lot écarté, zéro arrêt non programmé. Ce résultat n'a rien d'exceptionnel, c'est le standard quand la méthode est appliquée.

Pièges fréquents que nous voyons systématiquement

Trois pièges reviennent dans presque tous les projets ratés que l'on nous demande de récupérer.

Le premier, sous-estimer les faceplates custom. Ce sont souvent des ActiveX écrits il y a 12 ans par un intégrateur qui n'existe plus. Leur migration peut représenter 30 à 50 pour cent de l'effort total et les mauvaises surprises se cumulent.

Le second, négliger l'historian. Les bases Process Historian v7 doivent être migrées avec un outil dédié, et le contrôle d'intégrité doit être documenté. Sinon, vous perdez l'archivage GxP et l'auditeur le détecte.

Le troisième, vouloir tout migrer en une fois. C'est plus rapide sur le papier, et c'est exactement comme cela qu'on se retrouve avec une ligne arrêtée trois jours et une re-validation complète à faire.

Retour d'expérience Suisse romande

Sur 4 projets pharma menés ces dernières années dans la région lémanique et l'arc jurassien, le coût total moyen d'une migration v7 vers v9 (hors hardware AS si conservé) tourne autour de 380'000 à 750'000 CHF pour un site moyen (1 à 3 procédés, 4 à 8 AS). La durée totale, audit à fin de bascule, est de 9 à 18 mois.

L'erreur classique consiste à comparer ce chiffre au coût d'achat des licences (40'000 à 80'000 CHF). Ce ratio 1 pour 8 entre licences et projet réel n'a rien d'anormal sur un environnement GMP, c'est la qualification qui pèse.

Si vous démarrez ce type de projet, parlons-en. Notre équipe a fait cette migration sur des sites Roche, Lonza et plusieurs CDMO romandes, et nous savons exactement où sont les os. Vous trouverez quelques [références sectorielles](/references) et notre [contact](/contact) sur le site.

Voir aussi notre [secteur pharma](/secteurs/pharma) pour le périmètre complet de nos prestations GMP.

Questions fréquentes

Combien de temps dure réellement une migration PCS7 v7 vers v9 sur un site pharma ?

Entre 9 et 18 mois pour un site moyen, audit à fin de bascule. Les sites multi-procédés avec lyophilisation, fermentation et formulation peuvent dépasser 24 mois. La phase la plus longue est rarement la technique, c'est presque toujours la qualification GAMP 5 qui fixe le rythme.

Peut-on migrer sans changer les automates AS ?

Oui, c'est même souvent recommandé. PCS7 v9.1 supporte les CPU 41x série classique à condition que le firmware soit dans la bonne plage. L'option "OS-only migration" permet de réduire les coûts hardware d'environ 40 pour cent et limite la fenêtre d'arrêt par lot à 4-8 heures au lieu de 24-72 heures.

Quelle est la principale cause d'échec d'une migration PCS7 ?

L'absence d'environnement de test miroir représentatif. Les équipes qui testent directement sur la production découvrent les écarts trop tard, doivent rollback, perdent confiance, et le projet dérape de 6 à 12 mois. Investir 60'000 à 120'000 CHF dans un environnement de test sauve 3 à 5 fois ce montant en évitement de dérapage.

Faut-il refaire toute la qualification GMP après migration ?

Non, sauf si vous changez la fonctionnalité du système. Une migration de version maîtrisée se traite comme un change control GAMP 5, avec impact assessment, tests non-régression documentés, et requalification ciblée sur les modules impactés. C'est typiquement 30 à 50 pour cent de l'effort d'une qualification initiale, pas 100 pour cent.