Automate obsolète : préparer l’étude de migration

Préciser ce qui est obsolète et ce qui reste à vérifier

Le mot « obsolète » peut recouvrir plusieurs difficultés : fourniture devenue incertaine, support limité, environnement logiciel ancien ou composant qui ne répond plus au besoin. Dans votre dossier, indiquez le problème constaté et son origine. Séparez une information du constructeur, une réponse de fournisseur et une inquiétude interne.

Pour chaque élément concerné, rassemblez les références complètes et versions déjà documentées. Demandez une confirmation datée du statut applicable, des possibilités de fourniture ou de réparation et des conditions de support. Une annonce concernant une gamme ne décrit pas automatiquement tous ses modules ; une fin de commercialisation ne donne pas une date d’arrêt de fonctionnement de votre machine.

Un guide Siemens de janvier 2026, consacré à une architecture précise d’automatisation de tunnel, renvoie à des correspondances par composant et domaine d’application. Il décrit aussi les limites de l’assistant utilisé. Cet exemple illustre la nécessité de vérifier le cas installé ; ses solutions ne sont pas transposables à toutes les machines.

Références : Siemens — Guide de migration pour l’automatisation de tunnels S7-400H vers S7-1500H

Qualifier les projets logiciels déjà détenus

Le guide de migration Siemens de mai 2017 inclut, dans la préparation, les composants, les logiciels de projet, les communications et les systèmes tiers. Nous retenons cette démarche d’inventaire ; ses versions et tableaux de compatibilité anciens ne permettent pas de choisir une solution en 2026.

Dressez une liste des archives de projet et documents déjà détenus : nom, date, version du logiciel annoncée, équipement associé et origine. Notez séparément ce qui établit leur correspondance avec la machine actuelle. La présence d’un fichier ne prouve ni qu’il est complet et exploitable, ni qu’il décrit la version en service.

Le dossier doit rendre visibles les inconnues : projet absent, dernière modification non documentée, version non confirmée ou accès technique restant à organiser. L’étude précisera comment les lever et avec quelles compétences. Ne présumez pas qu’un programme manquant pourra être récupéré ou converti ; ce guide ne fournit aucune procédure de connexion ou de transfert sur la machine.

Références : Siemens — Guide de migration SIMATIC S7-300/S7-400 vers S7-1500 et TIA Portal

Cartographier les dépendances de la commande

La préparation décrite par Siemens dépasse le seul contrôleur : elle examine aussi les entrées-sorties, la conduite et les communications. Pour votre consultation, nous proposons une ligne par composant ou échange important. Écrivez : fonction concernée, équipement et version connus, document qui le décrit, information manquante, puis question à résoudre pour la migration.

L’objectif est de rendre chaque dépendance examinable. « Réseau existant à conserver » reste trop vague si les équipements qui échangent, les données attendues et les versions documentées ne sont pas identifiés. Une interface inconnue doit apparaître dans le périmètre de l’étude.

• Entrées-sorties : périphérie concernée, signaux et fonctions associés, schémas disponibles et éléments dont la conservation reste à vérifier.
• IHM, ou interface homme-machine : projet disponible, échanges avec l’automate, modes de marche, réglages et alarmes à retrouver.
• Variateurs et autres équipements : références documentées, rôle dans la machine et informations échangées avec la commande.
• Équipements voisins : origine et destination des données, commandes ou autorisations échangées, documents et interlocuteurs disponibles.
• Fonctions liées à la sécurité, si présentes : éléments identifiés et périmètre d’analyse à confier aux personnes compétentes, sans les assimiler à de simples échanges de production.

Références : Siemens — Guide de migration SIMATIC S7-300/S7-400 vers S7-1500 et TIA Portal

Exemple fictif : une IHM et un poste de pesage

Une PME envisage la migration de l’automate d’une machine de conditionnement. L’IHM permet de choisir un format ; un poste de pesage voisin renvoie une information utilisée par le cycle. Une archive de l’automate est retrouvée, mais son lien avec la dernière modification n’est pas établi. Cet exemple est fictif et ne décrit aucune réalisation cliente d’Azemeca.

La cartographie distingue trois questions. L’archive correspond-elle à la version réellement utilisée ? Le projet de l’IHM est-il disponible et exploitable ? Comment l’échange avec le poste de pesage est-il décrit, et quelles conditions de fonctionnement devront être vérifiées après migration ?

Une proposition portant uniquement sur la référence du nouvel automate laisse ces questions ouvertes. Cela ne signifie pas qu’il faut remplacer l’IHM ou le poste de pesage : leur maintien, leur adaptation ou leur remplacement restent à étudier. Le dossier permet de demander les constats et essais nécessaires pour trancher.

La demande devient alors plus précise : étudier la migration en conservant les fonctions de choix de format et d’échange avec le pesage, signaler les adaptations nécessaires et définir les preuves attendues. Elle ne présume ni de la solution matérielle, ni d’une conversion automatique du programme.

Relier le périmètre aux vérifications de la machine

Pour chaque fonction à conserver, faites préciser les éléments repris, les interfaces affectées et la manière dont le résultat sera vérifié. Prévoyez les conditions d’essai, les documents attendus et les responsabilités. Si une information manque, indiquez quelle décision en dépend et comment ce point sera instruit avant de confirmer le projet.

Dans sa notice ED 6289 de décembre 2017, l’INRS présente une démarche pour conduire une modification de machine en service en fonction des besoins. Une migration de commande s’inscrit dans cet examen du projet : ses effets sur les fonctions et la sécurité de l’équipement doivent être étudiés selon le cas. La validation d’un échange informatique ne vaut pas validation de toute la machine.

Le guide de cahier des charges accessible ci-dessous aide ensuite à formuler des exigences vérifiables. Si le maintien de la machine elle-même reste en discussion, commencez par la comparaison rétrofit ou remplacement : la cartographie de commande apporte des informations à cet arbitrage, sans le remplacer.

Références : INRS — Amélioration des machines en service — ED 6289

Préparer une demande d’étude de rétrofit

Transmettez le problème d’obsolescence identifié, la liste des références et fichiers connus, la cartographie des échanges et les fonctions à conserver. Ajoutez les évolutions souhaitées et les points encore inconnus. Vous disposez ainsi d’une base pour convenir d’un examen de l’existant, avant de figer le matériel et le calendrier.

Pour échanger avec Azemeca sur le rétrofit d’une machine, présentez ce dossier et les contraintes de votre projet. Le périmètre de l’étude et les compétences à mobiliser, y compris en automatisme si le besoin le nécessite, se précisent selon l’installation. Aucune faisabilité de migration ne peut être déduite du seul nom de l’automate.