Migration PC SOFT dans l'industrie

Une application WinDev de production ne se migre pas comme un outil de bureau. Elle pilote des terminaux d'atelier, dialogue parfois avec des automates, et son arrêt, même de quelques heures, se répercute directement sur la production. La contrainte n'est donc pas seulement applicative, elle est temporelle et opérationnelle.

Cette page détaille les points de vigilance propres à un contexte industriel, que nous intégrons systématiquement dans le cadrage d'un projet de migration en atelier.

Cette contrainte se retrouve à des degrés divers dans la plupart des secteurs manufacturiers : agroalimentaire, métallurgie, plasturgie, logistique industrielle. Le point commun n'est pas le métier lui-même, c'est la présence d'un flux physique continu que l'informatique doit accompagner sans jamais l'interrompre sans préavis.

Les contraintes propres à l'atelier

Un environnement d'atelier impose des conditions que l'on ne retrouve pas dans un bureau : postes parfois partagés entre plusieurs opérateurs, terminaux durcis exposés à la poussière ou aux vibrations, connexion réseau qui peut être instable selon les zones du site. Une application de gestion classique n'anticipe pas toujours ces conditions, alors qu'une application industrielle doit les intégrer dès la conception de l'interface cible.

Le rythme de travail compte aussi : un opérateur en cadence n'a pas le temps de naviguer dans plusieurs écrans pour valider une opération. L'ergonomie de l'application cible doit reproduire, au minimum, la rapidité de saisie de l'existant.

S'ajoute à cela une question de compétences : les opérateurs d'atelier ne sont pas toujours à l'aise avec un changement d'interface, surtout s'il intervient sans accompagnement. Prévoir une période de formation courte et un support de proximité au moment de la bascule réduit fortement le risque de rejet ou d'usage incorrect du nouvel outil dans les premières semaines.

Terminaux, scan et mode déconnecté

Les terminaux d'atelier et les douchettes de scan posent une contrainte spécifique : ils doivent souvent continuer à fonctionner même en cas de coupure réseau temporaire, avec une synchronisation différée dès que la connexion revient. Toutes les architectures cibles ne gèrent pas ce mode déconnecté avec la même rigueur, ce qui doit être vérifié avant de choisir la technologie de remplacement, pas après le déploiement.

Le matériel lui-même mérite d'être audité en parallèle du logiciel : un terminal ancien peut ne pas être compatible avec certaines stacks modernes, ce qui ajoute un volet de renouvellement matériel au projet.

La gestion des conflits de synchronisation, lorsque plusieurs terminaux ont travaillé hors ligne avant de resynchroniser leurs données, est un point technique qui mérite d'être testé en conditions réelles avant la mise en production, pas seulement validé en théorie. Un scénario de reprise après coupure prolongée fait partie des tests que nous menons systématiquement sur ce type de projet.

Interfaces machines et automates

Une application industrielle communique fréquemment avec des automates programmables, des systèmes de supervision ou des machines de production via des protocoles industriels spécifiques. Ces interfaces sont souvent le résultat de développements ponctuels, réalisés au fil des besoins, sans documentation centralisée.

Les identifier et les qualifier avant la migration est indispensable : une interface machine mal recensée, et c'est une ligne de production qui s'arrête le jour de la bascule sans que personne n'en comprenne immédiatement la cause.

Ces interfaces posent aussi une question de compétence rare : peu de développeurs maîtrisent à la fois le développement applicatif et les protocoles industriels utilisés pour dialoguer avec les automates. Identifier cette compétence tôt dans le projet, en interne ou chez un prestataire spécialisé, évite un goulot d'étranglement qui apparaît souvent tard, au moment où l'interface doit être testée en conditions réelles.

Fenêtres de bascule et continuité de production

Contrairement à une application de bureau, une bascule industrielle ne peut pas s'improviser un jour ouvré quelconque. Elle se planifie dans une fenêtre de maintenance, un arrêt de ligne programmé ou une période de moindre activité, avec un plan de retour arrière testé et prêt à être déclenché si un problème survient.

Cette contrainte de calendrier structure l'ensemble du projet : elle impose souvent une migration module par module ou ligne par ligne, plutôt qu'une bascule générale à une date unique.

Le plan de retour arrière n'est pas une simple précaution théorique : il doit être testé avant la bascule réelle, dans les mêmes conditions, pour vérifier qu'il peut effectivement être déclenché dans le temps imparti par la fenêtre de maintenance. Un plan de retour arrière qui n'a jamais été testé n'est, en pratique, pas un filet de sécurité fiable.

Cette planification se construit avec les équipes de production elles-mêmes, pas uniquement avec la direction informatique : ce sont elles qui connaissent les créneaux réellement disponibles et les opérations qui ne tolèrent aucune interruption, même de quelques minutes.

Traçabilité et conformité

De nombreux secteurs industriels imposent une traçabilité stricte des lots, des opérations et des contrôles qualité. La migration doit préserver cette traçabilité sans rupture dans l'historique, et documenter précisément la correspondance entre l'ancien système et le nouveau pour les besoins d'audit.

• Agroalimentaire : traçabilité des lots et des dates limites de consommation.
• Pharmaceutique : traçabilité des numéros de lot et des contrôles qualité.
• Aéronautique et automobile : traçabilité des pièces et des opérations de contrôle.

Cette exigence se cadre dès le début du projet, au même titre que la cartographie fonctionnelle, pas comme une contrainte annexe traitée à la fin.