Sur le papier, c'est une conversion un pour un. Ça ne l'est jamais.

Les migrations de ce genre sont présentées comme des conversions un pour un. On prend l’ancien système, on reproduit ce qu’il fait dans du nouveau matériel et du nouveau logiciel, et on le rend en se comportant exactement de la même manière. Un périmètre net, facile à vendre — sur la page de couverture, ça se lit comme un copier-coller avec un budget en pièce jointe.

Il existe un type particulier de sous-système qui prouve discrètement que cette page de couverture a tort, et une fois qu’on s’est battu avec un, on se met à le voir partout : un vieil automate Mitsubishi de la série FX, un programme écrit dans les années 1990, en langage à contacts (ladder), sous GX Developer — l’ancienne génération du logiciel de programmation MELSEC de Mitsubishi. Le travail consiste à le faire passer dans un ABB 800xA, reconstruit sous forme de module de commande et codé en schéma à blocs fonctionnels (FBD) plutôt qu’en langage à contacts. « Même comportement, nouvelle plateforme. » Voilà la consigne. Et voici où la consigne s’épuise.

« Un pour un » est une phrase commerciale, pas une phrase d’ingénierie

Je ne pense pas que quiconque mente en appelant ça du 1:1. Du côté du client, c’est vrai : mêmes boutons, même séquence, même sortie, la ligne tourne comme elle l’a toujours fait. C’est le résultat qu’il paie, et c’est une façon juste de le décrire.

Mais même résultat et même logique sont deux métiers différents, et c’est dans l’écart entre les deux que se cache l’essentiel du travail. Trois choses, dans un sous-système comme celui-ci, ouvrent cet écart. Aucune ne figure sur la page de couverture.

Un : le langage à contacts et le FBD ne raisonnent pas de la même façon

Le langage à contacts et le FBD ne sont pas deux dialectes d’une même langue. Ce sont deux façons différentes d’imaginer une machine. Le langage à contacts se lit comme des barreaux de contacts et de bobines, le courant circulant de gauche à droite — un modèle mental qui avait du sens à l’époque où il décrivait de véritables armoires à relais. Le FBD se lit comme des signaux circulant à travers des blocs. Générations différentes, instincts différents.

Traduire l’un dans l’autre n’a donc rien de mécanique, dans aucun des deux sens. Un motif qui forme un barreau évident en langage à contacts peut devenir un amas maladroit de blocs en FBD, et quelque chose de propre en FBD redeviendrait un fouillis de barreaux. Le piège, c’est qu’on peut généralement faire correspondre la sortie alors que la structure sous-jacente finit par ne ressembler en rien à l’originale — ce qui ressemble à une réussite jusqu’au moment où un cas limite se comporte différemment. Reproduire le comportement exact, c’est la partie réellement difficile. Pas parce que la nouvelle plateforme ne sait pas le faire, mais parce que prouver que la nouvelle version se comporte à l’identique exige de comprendre l’ancienne bien plus en profondeur que de la lire simplement de haut en bas.

Deux : les parties sans équivalent

Une partie de ce sur quoi s’appuient ces vieux programmes n’a tout bonnement aucun jumeau dans le 800xA. Ça ne se traduit pas ; il faut le reconstruire à la main, et on ne découvre chaque cas qu’en lisant attentivement.

• Les instructions de saut. Le langage à contacts utilise des sauts conditionnels (CJ) pour passer des sections entières de logique — et tout ce qui se trouve à l’intérieur d’une section sautée conserve son dernier état plutôt que de se réinitialiser, y compris les temporisations, qui se figent au lieu de s’effacer. Il n’existe pas d’instruction de saut équivalente à insérer dans le FBD, donc ce flux de contrôle doit être réexprimé sous forme d’ordre d’exécution et de conditions de validation — un modèle mental différent, pas une instruction échangée. Reproduisez le comportement « figer, ne pas réinitialiser », sinon vous avez introduit une différence silencieuse sur un cas limite.
• Les réglages physiques câblés dans la logique. Toutes les consignes ne vivent pas dans le code. Certaines valeurs — comme les préréglages de temporisation — étaient ajustées sur la machine elle-même au moyen de potentiomètres physiques. Sur le FX, ces potentiomètres ne contiennent pas la valeur directement : ils atterrissent dans des registres de données spéciaux (D8030/D8031), et le programme les met à l’échelle pour en faire un préréglage. Dans le nouveau monde, ils deviennent des paramètres dans le module de commande, ce qui force une décision que l’original n’a jamais consignée : qu’est-ce qui était censé rester réglable sur le terrain, et qu’est-ce qui n’était simplement que la façon dont on faisait en 1995 ?
• Les relais auxiliaires spéciaux. Ces programmes s’appuient sur des relais système de la série M8000 — par exemple M8028, qui commute la base de temps d’un bloc de temporisations — pour façonner certaines parties de la logique. Ce sont des bits système propres à la plateforme. Le 800xA possède ses propres mécanismes, donc chaque usage doit être compris pour ce qu’il faisait réellement, puis recréé avec ce que la nouvelle plateforme propose — jamais simplement recopié tel quel.

Trois : le modèle d’intégration caché à l’intérieur du « 1:1 »

C’est celui qui n’est pas visible avant qu’on aille le chercher, et un cahier des charges « à l’identique » est le document le plus mal placé pour l’attraper.

Un contrôleur ne travaille jamais seul. Il dialogue avec tout ce qui l’entoure — d’autres contrôleurs, les E/S, la ligne au sens large — et la façon dont il dialogue fait partie de ce qu’il fait, même si rien de tout cela n’apparaît quand on lit le programme de haut en bas. L’hypothèse tacite intégrée dans un cahier des charges 1:1, c’est que cette conversation se reporte intacte. Souvent, elle ne le fait pas. Passez d’une plateforme vieille de plusieurs décennies à une plateforme moderne et le modèle d’intégration lui-même peut changer : la façon dont ce coin du système se connecte à tout le reste, et ce dont cette connexion est même faite.

Mesurez ce que cela signifie. Même fonction sur le terrain, un système nerveux différent derrière. On ne peut pas répliquer une liaison qui n’existe plus sous la même forme — il faut repenser la façon dont la chose communique avec le reste du système, et c’est du vrai travail que la page de couverture n’a jamais chiffré. Ça n’a rien d’exotique. C’est juste invisible depuis le listing du programme, ce qui est précisément la raison pour laquelle un cahier des charges écrit à partir de ce listing continue de passer à côté.

Comment je lis un programme écrit avant ma naissance

Je suis encore assez tôt dans ce métier pour qu’un programme à contacts des années 1990 me soit réellement étranger — j’ai 21 ans, environ dix-huit mois d’expérience. Je n’allais jamais surpasser un tel code par l’expérience. Alors je m’appuie sur l’outillage, délibérément, et je vais dire comment, parce que la méthode fait la moitié de l’intérêt.

L’idée, c’est de sortir l’ancien programme de son environnement natif pour le mettre sous une forme simple et lisible — l’exporter en PDF, ou dans n’importe quel format qui préserve ce que la logique fait réellement — puis d’utiliser un modèle d’IA comme aide à la lecture (en veillant à travailler sur une plateforme de ML interne à l’entreprise, hébergée sur site — et seulement après avoir vérifié que c’est validé avec votre entreprise, le client et toute autre partie dont les données sont concernées) : explique-moi ceci section par section, avec des extraits annotés que je peux vérifier directement face aux barreaux. Cela transforme un programme que personne n’a touché depuis des décennies en une carte lisible. À partir de là, on détermine quelles parties ne survivront pas au passage — les sauts, les éléments spéciaux, les préréglages fixés sur le terrain — et on raisonne sur la façon dont un bloc donné de langage à contacts devrait être reconstruit en FBD.

Je tiens à être honnête sur les limites, parce qu’un public de l’automatisation se méfiera à juste titre de tout cela. L’IA se trompe parfois. Elle devine l’intention, parfois avec une assurance qu’elle n’a pas méritée. C’est une aide à la lecture et un partenaire de réflexion, pas une autorité — chaque conclusion est vérifiée face au programme réel et au comportement réel avant d’approcher de près ou de loin le nouveau code. Mais comme moyen de transformer un artefact opaque des années 1990 en quelque chose sur quoi on peut raisonner en jours plutôt qu’en semaines, l’outil gagne sa place. C’est exactement le travail facile pour lequel l’outillage est bon : ne pas prendre la décision d’ingénierie, juste débroussailler pour qu’on puisse la prendre.

La même astuce, pointée vers la réponse

Lire l’ancien programme n’en est que la moitié. L’autre moitié, c’est prouver que le nouveau correspond — et la même approche fonctionne là aussi. On exporte les deux programmes vers du texte qui reflète leur logique — le langage à contacts et le FBD chacun déversés en PDF, ou n’importe quel format qui préserve ce que le code fait réellement — et on les fournit tous les deux à une IA en même temps, en lui demandant de les comparer logiquement et fonctionnellement et de signaler où ils divergent. Elle ne reconstruira rien à votre place, mais c’est un deuxième lecteur rapide et infatigable : le barreau qui n’a pas survécu au passage, le cas limite que le FBD traite différemment, la sortie qui a discrètement changé — elle vous les signale pour que vous alliez les traquer. Même réserve qu’avant : chaque signalement est vérifié face au comportement réel avant qu’on lui fasse confiance. Mais pointer l’outillage sur les deux côtés à la fois transforme « est-ce que ça correspond ? » d’une semaine de relecture croisée manuelle en quelque chose sur quoi on peut itérer en une après-midi.

Ce qu’il faut retenir

Une migration un pour un est réelle du fauteuil du client et une fiction de celui de l’ingénieur, et les deux peuvent être vraies à la fois. Le danger, ce n’est pas l’étiquette — c’est quand les gens qui cadrent le travail y croient.

Alors voici ce qu’un travail de ce genre enseigne, et ce qu’il vaut la peine de faire sur le prochain avant de toucher au moindre barreau : quand quelque chose est vendu comme un pour un, partez à la chasse aux trois endroits où il ne peut pas l’être.

• L’écart de paradigme — partout où l’outil source et l’outil cible raisonnent différemment (langage à contacts vers FBD), le comportement est difficile à prouver, pas seulement à écrire.
• Les orphelins — les éléments propres à la plateforme et sans équivalent (sauts, relais système, préréglages fixés sur le terrain) qui doivent être reconstruits à la main.
• Le modèle d’intégration — la façon dont la chose communique avec tout ce qui l’entoure, qu’un cahier des charges « à l’identique » adore supposer inchangée alors qu’elle ne l’est pas.

Trouvez ces trois éléments tôt. Chiffrez-les honnêtement. Alors « un pour un » cesse d’être un mensonge qu’on découvre à mi-parcours et devient un plan que l’on peut réellement assumer. L’étiquette n’a jamais été le problème — c’est d’y croire qui l’était.