Refactorisation d’une ancienne application industrielle : quand est-elle pertinente et comment la mener sans risque pour la production ?

Pourquoi ce sujet est important aujourd’hui

La refactorisation d’une ancienne application industrielle n’est plus une question d’esthétique du code ou de confort de maintenance. C’est désormais une décision qui engage la continuité de la production, la prévisibilité des coûts et l’étendue des responsabilités du propriétaire du système. Sur de nombreux sites, les applications de pilotage, les outils opérateur et les couches de communication ont été développés pendant des années sans architecture cohérente d’ensemble, souvent autour d’équipements, de bibliothèques et de mécanismes d’intégration dont le support est limité ou a déjà pris fin. Cette situation peut être tolérée un certain temps, mais seulement jusqu’au moment où chaque modification supplémentaire commence à coûter plus cher que la fonctionnalité elle-même. À partir de là, la véritable question n’est plus de savoir s’il faut intervenir sur l’ancienne application, mais si l’organisation maîtrise encore son comportement en conditions de production.

L’importance du sujet tient au fait que, dans les systèmes industriels, la dette technique devient très vite une dette opérationnelle. Si l’application est difficile à reproduire, dépend de quelques personnes clés, ne dispose pas de tests de non-régression fiables, ou si sa logique mélange des fonctions de production avec des fonctions de sécurité et de diagnostic, alors chaque incident coûtera plus cher qu’un problème comparable dans un système bureautique. La conséquence ne se limite pas à l’arrêt de production. Il faut aussi compter le coût d’intervention de la maintenance, le risque de contournements inadaptés mis en place sous la pression du temps, la difficulté à démontrer la diligence requise après modification, ainsi que la complexité à distinguer ce qui relevait d’un défaut antérieur de ce qui résulte de l’intervention de l’équipe projet. Pour un manager ou un responsable produit, le critère pratique est simple : si le temps nécessaire et l’incertitude liés au déploiement de petites évolutions augmentent plus vite que leur valeur métier, l’application est entrée dans un état où la décision de refactoriser doit être prise en connaissance de cause, et non reportée jusqu’à la première défaillance critique.

La plupart des erreurs apparaissent lorsque la refactorisation est traitée comme une modernisation « sans impact sur le procédé », alors qu’en réalité elle modifie la manière dont le système prend ses décisions. En pratique, une intervention en apparence limitée suffit : remplacement d’un composant de communication, refonte de l’ordonnancement des tâches, modification de la logique de mise en mémoire tampon des données capteurs, ou réorganisation de la séquence de démarrage après redémarrage. Sur le papier, il s’agit d’un simple nettoyage technique. Dans l’atelier, ces changements peuvent pourtant modifier le moment d’émission d’un signal, l’ordre de levée des interverrouillages, la réaction en cas de perte de communication ou le comportement de l’application après une coupure d’alimentation. C’est précisément là que la refactorisation rejoint l’évaluation concrète du risque lié au changement : la question n’est pas de savoir si le code est « meilleur », mais si, après modification, la machine, la ligne ou le poste continuent à se comporter de manière prévisible en fonctionnement normal, en situation perturbée et après remise en service.

Un bon test de maturité de la décision consiste à vérifier si l’équipe est capable de tracer la frontière entre une modification de la structure interne de l’application et une modification d’une fonction importante pour le procédé ou pour la sécurité. Si cette frontière ne peut pas être décrite au niveau des signaux, des états et des conditions de transition, le projet est risqué, quelle que soit la qualité du prestataire. En environnement industriel, les situations les plus sensibles sont celles où l’application intervient dans la séquence de démarrage, d’arrêt, de réarmement des défauts, d’acquittement des alarmes, ou lorsqu’elle interagit avec des dispositifs de coupure d’énergie et des interverrouillages. À ce stade, il n’est plus seulement question d’architecture logicielle, mais aussi de protection contre le démarrage intempestif et du point de savoir si l’analyse couvre également l’installation électrique, la logique de commande et les dépendances entre équipements. C’est précisément à ce moment qu’une refactorisation apparemment locale cesse d’être une tâche informatique pour devenir une modification technique exigeant un cadre décisionnel complet, souvent avec l’appui d’un bureau d’études techniques.

La référence aux exigences normatives ne prend réellement son sens qu’à ce stade, car les normes ne remplacent pas la décision de conception, mais elles en structurent le périmètre. Si la modification peut influer sur les conditions de démarrage, d’arrêt, de reprise après perturbation ou sur les mesures de protection, elle doit être évaluée comme une modification du risque, et non comme une simple maintenance du code. Si l’intervention touche une logique en interaction avec la coupure d’énergie, les interverrouillages ou la séquence d’accès en sécurité, elle ouvre naturellement aussi le champ des exigences relatives à la protection contre le démarrage intempestif. Du point de vue des responsabilités, l’essentiel n’est donc pas seulement de savoir « s’il faut refactoriser », mais si l’organisation est capable de démontrer qu’elle connaît les limites de la modification, qu’elle dispose de critères d’acceptation fondés sur le comportement du procédé et qu’elle sait distinguer une remise en ordre du système d’une modification qui exige une évaluation du risque du changement selon l’ISO 12100 complète, ainsi qu’une coordination avec la conception de l’installation et les essais sur site.

Où le coût ou le risque augmente le plus souvent

Dans la refactorisation d’une ancienne application industrielle, la hausse la plus importante des coûts provient rarement du code lui-même. La source du problème est généralement une mauvaise qualification de la modification : l’équipe la traite comme une remise en ordre de la structure du programme, alors qu’en réalité le comportement du système dans le temps, l’ordre des opérations ou les conditions de transition entre états sont modifiés. En environnement de production, une telle erreur a des conséquences directes sur le projet. Le planning ne correspond plus au périmètre réel, les tests sont prévus pour une fonctionnalité informatique et non pour le déroulement du procédé, et la responsabilité du résultat se dilue entre la maintenance, l’automatisme et le fournisseur du logiciel. Le critère pratique est ici simple : si, après la modification, il faut à nouveau confirmer la séquence de démarrage, d’arrêt, de reprise après perturbation ou la réaction aux signaux issus des circuits de protection, il ne s’agit plus d’une « refactorisation sûre » au sens organisationnel, mais d’une modification susceptible de générer un risque pour la production et d’exiger un autre mode d’approbation.

Le deuxième domaine typique d’augmentation des coûts tient à une décision de conception prise sans vision complète des dépendances. Les anciennes applications industrielles sont souvent étroitement imbriquées avec la configuration de l’automate, les actionneurs, la supervision, l’archivage des données et les procédures opérateur. Dans la documentation, cela apparaît comme un seul système, mais en pratique il s’agit de couches développées pendant des années par différentes équipes. Une refactorisation destinée à améliorer la lisibilité du code ou à faciliter la maintenance ultérieure peut modifier sans qu’on s’en aperçoive la signification des temporisations, des conditions d’interverrouillage, des valeurs par défaut après redémarrage ou du mode de gestion d’une erreur de communication. La conséquence n’est pas seulement une correction technique, mais aussi le coût des arrêts, des essais supplémentaires sur site et des désaccords sur le point de savoir si le défaut existait déjà ou s’il a été introduit par la modification. C’est pourquoi, avant de décider, il convient d’évaluer non pas la seule ampleur de la modification, mais le nombre et la criticité des interfaces : combien de signaux, de recettes, de modes de fonctionnement et de contournements d’exploitation dépendent du fragment de code à remanier. Plus ces points sont nombreux, moins une refactorisation menée « au passage » d’une autre tâche a de sens, en particulier dans des environnements d’automatisation industrielle fortement couplés.

En pratique, les projets les plus coûteux sont souvent ceux dans lesquels l’équipe ne découvre les exigences réelles qu’au moment de la mise en service. L’exemple typique est la refonte d’un module séquentiel qui, selon sa description, « fait la même chose, mais plus proprement ». Après déploiement, on constate pourtant que la version précédente contenait des comportements non documentés compensant les imperfections de l’installation : maintien bref d’un signal, tolérance à un capteur retardé, ordre spécifique d’acquittement d’une alarme ou condition dont dépend l’accès en mode service. Dans le code, cela ressemblait à une erreur ou à de la dette technique, mais pour le procédé c’était un élément de stabilisation. Si la refactorisation supprime de tels mécanismes sans en avoir identifié la fonction, le coût apparaît immédiatement : le nombre d’interventions après mise en service augmente, le temps de réception s’allonge et il faut reconstituer la logique sous la pression de l’exploitation. Il faut donc aussi apprécier la pertinence d’une refactorisation à l’aune de la capacité à reconstituer le comportement du système existant. Si l’organisation ne dispose pas d’un registre des événements, de descriptions fiables des modes de fonctionnement et de scénarios de test fondés sur le procédé réel, il faut d’abord construire cette base d’évaluation, puis seulement décider d’une refonte.

Cette question conduit directement à une évaluation pratique du risque lié aux modifications lorsque celles-ci affectent des fonctions de protection, des séquences d’accès sécurisé, la commande du mouvement des actionneurs ou le comportement de l’installation après une coupure puis un retour d’alimentation. Dans un tel périmètre, le coût d’une erreur ne se limite pas aux corrections logicielles, car se pose aussi la question de la responsabilité liée à l’autorisation de remise en service de la modification. Si l’application fonctionne avec des systèmes hydrauliques, pneumatiques ou des solutions telles que la commande bimanuelle, la frontière entre refactorisation et modification technique devient encore plus étroite et impose de vérifier que les hypothèses de conception des moyens de protection n’ont pas été remises en cause. C’est précisément à ce stade qu’il est pertinent de recourir à des méthodes structurées d’évaluation du risque selon l’ISO 12100, y compris à l’approche utilisée en pratique sur la base de l’ISO/TR 14121-2, et, pour les systèmes hydrauliques, également aux exigences de conception structurées par la NF EN ISO 4413. Il ne s’agit pas de formalisme pour le formalisme, mais d’une règle de décision simple : si la modification peut avoir un effet sur la sécurité du procédé ou de l’exploitation, son coût doit être calculé en incluant la validation, les essais sur site et le régime de responsabilité, et non pas uniquement le temps de travail du programmeur.

Comment aborder le sujet en pratique

En pratique, l’intérêt d’une refactorisation d’une ancienne application industrielle ne se juge pas à l’attrait technologique du changement, mais à sa capacité à réduire simultanément le risque d’exploitation tout en gardant la maîtrise du déploiement. Pour un manager et un responsable produit, cela implique un simple changement de perspective : la vraie question n’est pas de savoir s’il « vaut la peine de remettre le code en ordre », mais si l’état actuel de l’application complique réellement la maintenance, les essais, la correction des défauts ou l’introduction de modifications ultérieures conformes aux exigences. Si la réponse est oui, la refactorisation est pertinente, mais uniquement dans une mesure qui peut être dissociée de l’activité de production et évaluée sur la base d’effets mesurables. Un bon critère de décision consiste ici à comparer deux coûts : celui du maintien de l’application en l’état, incluant les arrêts, le temps de diagnostic, la dépendance à des personnes clés et le risque de modification erronée, et celui d’une refonte maîtrisée avec essais, validation et mise en service. Sans cette comparaison, le projet échappe généralement au contrôle, car l’équipe finance le nettoyage du code sur un budget prévu pour les fonctionnalités, tandis que la responsabilité des conséquences sur l’installation reste indéterminée.

C’est pourquoi la première décision ne devrait pas être « on réécrit » ou « on laisse tel quel », mais la définition du périmètre du changement. Dans une approche mature, on distingue la partie qui concerne uniquement la structure du logiciel de celle qui affecte la logique du procédé, les séquences de démarrage, d’arrêt, les modes de fonctionnement, la communication avec les entraînements et le comportement après une perturbation de l’alimentation. Cette distinction a un effet direct sur les coûts et sur l’organisation. Une modification limitée à la couche de structuration du code peut être menée sur un cycle plus court et avec une implication moindre des équipes de maintenance. En revanche, une modification qui touche au comportement de la machine ou de la ligne exige déjà un plan d’essais sur site, une fenêtre d’intervention, une procédure de retour arrière et une désignation explicite de l’autorité qui valide la remise en exploitation. Il est utile, à ce stade, de mesurer non seulement le temps d’exécution des travaux de développement, mais aussi le temps nécessaire pour rétablir le système après une tentative infructueuse, le nombre de zones couvertes par les essais de non-régression et le temps requis pour diagnostiquer un écart après la mise en service. Ce sont ces indicateurs qui montrent si la refactorisation réduit réellement le risque du projet, et pas seulement si elle améliore le confort de travail de l’équipe de développement. Dans ce type de démarche, une bonne gestion de projet conditionne directement la maîtrise des interfaces, des essais et des décisions de remise en service.

Un exemple concret, typique des anciennes applications de commande, est celui d’un code contenant de nombreux fragments dupliqués pour les interverrouillages de mouvement, la gestion des alarmes et les transitions entre mode manuel et mode automatique. L’équipe souhaite les unifier, car l’organisation actuelle freine les évolutions et crée des divergences entre postes. Une telle décision n’a de sens qu’après avoir vérifié que cette harmonisation ne modifie pas les conditions dans lesquelles un actionneur reçoit l’autorisation de mouvement, et qu’après redémarrage de l’automate aucune séquence différente de restauration de l’état n’apparaît. Si l’application pilote aussi des vannes, des entraînements ou des systèmes comportant de l’énergie accumulée, même une refactorisation apparemment « interne » peut basculer dans le champ de l’évaluation du risque de modification selon l’ISO 12100 et nécessiter une analyse de la protection contre le démarrage intempestif. Dans ce cas, une pratique raisonnable consiste à réaliser la refactorisation par étapes : d’abord reproduire le comportement dans un environnement d’essai, puis isoler les modules sans modifier la logique, ensuite vérifier sur l’installation avec un scénario de retour arrière préparé. Cela limite la responsabilité opérationnelle et permet d’interrompre le déploiement avant que le problème n’affecte la production.

Ce n’est qu’à ce stade qu’une référence normative devient nécessaire, car les normes ne remplacent pas la décision technique, mais elles structurent le moment où la modification cesse d’être un simple travail de développement. Si la refactorisation a une incidence sur les moyens de protection, les conditions d’accès en sécurité, la coupure d’énergie ou le comportement des systèmes après arrêt et redémarrage, elle entre naturellement dans le champ d’une évaluation pratique du risque de modification, menée de manière structurée, y compris avec l’approche connue de l’ISO/TR 14121-2. Lorsqu’un risque de démarrage intempestif apparaît, il faut alors vérifier non seulement le code lui-même, mais aussi la logique de coupure et de rétablissement de l’énergie, ce qui conduit directement aux questions associées à l’ISO 14118. Si, en outre, l’application est liée à l’hydraulique ou au pneumatique, l’évaluation ne peut pas faire abstraction des hypothèses de conception de ces systèmes, car une séquence de commande erronée peut compromettre leur fonctionnement sûr indépendamment de la conformité du programme lui-même ; dans ce cas, il devient également justifié de se référer aux exigences structurant la conception des systèmes hydrauliques. En pratique, cela signifie une chose : l’étendue de la refactorisation n’est pas déterminée par l’élégance de la solution, mais par la limite de responsabilité quant au comportement sûr de l’installation après modification.

Points de vigilance lors du déploiement

Le déploiement d’une refactorisation d’une ancienne application industrielle est le moment où même une décision d’architecture correcte peut se transformer en problème opérationnel. Tout l’intérêt de la démarche s’arrête là où la modification améliore le code, mais dégrade la prévisibilité du fonctionnement de l’installation ou étend la responsabilité de l’équipe au-delà de ce qui a été identifié et validé. L’erreur la plus fréquente consiste à traiter le déploiement comme une simple publication d’une nouvelle version. En environnement de production, il ne s’agit pas seulement de savoir si l’application fonctionne, mais aussi si, après la modification, tous les états transitoires se comportent à l’identique : démarrage après coupure d’alimentation, redémarrage des communications, restauration des recettes, gestion des alarmes, des interverrouillages et des modes manuels. Le critère pratique est simple : si l’équipe n’est pas capable de décrire sans ambiguïté quels comportements doivent rester inchangés après le déploiement, c’est qu’elle ne réunit pas encore les conditions d’une mise en service sûre.

Au stade de la décision de déploiement, il faut distinguer une modification techniquement réversible d’une modification qui, une fois mise en service, crée un nouvel état de référence et rend le retour en arrière plus difficile. Cela a des conséquences directes sur le coût et le calendrier. Une refactorisation qui exige la mise à jour simultanée des automates, de la supervision, du serveur de données et des interfaces avec les systèmes de niveau supérieur cesse d’être une simple tâche de développement ; elle devient une modification de production coordonnée, avec de multiples points de défaillance. C’est pourquoi, avant le déploiement, il est judicieux d’adopter un critère d’acceptation fondé non pas sur la déclaration « les tests sont passés », mais sur la capacité à retirer la modification de manière maîtrisée dans un délai acceptable pour le procédé. S’il n’existe pas de procédure de retour fiable, rien ne permet d’affirmer que le risque est maîtrisé. En pratique, il est préférable de mesurer non pas une « qualité du déploiement » abstraite, mais des indicateurs tels que le temps nécessaire pour rétablir la version précédente, le nombre d’interfaces dépendantes de la modification et le nombre de fonctions dont la conformité peut être vérifiée sur l’installation sans intervenir sur la production.

Un bon exemple est celui d’une refactorisation qui rationalise la gestion des exceptions et des messages d’erreur, tout en modifiant en parallèle l’ordre d’initialisation après le redémarrage du système. Sur le poste d’essai, tout paraît correct, car les équipements sont disponibles immédiatement et le procédé ne fonctionne pas en charge. Dans l’usine, ce même code peut toutefois lancer la séquence à un autre moment qu’auparavant, ce qui entraîne une perte de synchronisation avec les entraînements, une mauvaise interprétation des signaux de disponibilité ou l’arrêt d’un lot de matière dans un état intermédiaire. Un tel incident ne signifie pas nécessairement une panne au sens technique, mais il génère un coût lié à l’arrêt, aux rebuts, au redémarrage et à la responsabilité supplémentaire associée à la décision de reprise. C’est précisément à ce stade que la question de la refactorisation rejoint l’évaluation du risque de modification selon l’ISO 12100 en pratique : non pas lorsque la modification est importante, mais lorsque ses effets ne peuvent plus être contenus dans la seule couche logicielle.

La limite de responsabilité devient encore plus nette lorsque l’application agit sur les fonctions de protection, la logique d’autorisation de mouvement, les séquences de délestage, l’arrêt et le redémarrage après perturbation. Dans ce cas, la comparaison des versions du code ou un test fonctionnel réalisé par l’intégrateur ne suffisent plus. Il faut une évaluation structurée pour déterminer si la modification change le niveau de risque et si elle ne remet pas en cause les hypothèses de fonctionnement sûr de la machine ou de l’installation. C’est le moment naturel d’entrer dans le champ de l’identification des dangers selon l’ISO 12100, ainsi que des pratiques appliquées à l’évaluation du risque de modification, et, dans les cas plus complexes, une approche méthodique connue par l’ISO/TR 14121-2 peut s’avérer utile. Si l’application commande des systèmes hydrauliques ou pneumatiques, il faut en outre vérifier si la nouvelle logique ne modifie pas les conditions de maîtrise sûre des énergies et l’ordre des mouvements ; dans ce cas, les exigences de conception propres à ces systèmes comptent également, et pas seulement la conformité du programme lui-même. Pour l’équipe projet, cela signifie une chose : le déploiement ne peut être considéré comme prêt que lorsque le périmètre des responsabilités techniques, d’exploitation et de conformité a été défini avant la mise en service, et non après le premier incident. Dans les situations les plus sensibles, un audit de sécurité des machines et des lignes de production permet aussi de vérifier la cohérence entre la modification logicielle et le comportement réel de l’installation.