Le poste tourne encore. Il fait tourner LabVIEW 8 sous Windows XP, avec des cartes d'acquisition PCI qui ne se vendent plus, et la seule personne qui comprenait la séquence est partie depuis des années. Un ingénieur a décrit exactement cette situation sur le forum NI Community en avril 2026, en demandant comment estimer l'effort de mise à niveau d'un tel montage. Beaucoup d'ateliers de production ont un poste de ce type. La question est rarement « LabVIEW, bon ou mauvais ? ». Elle est : que faire de celui-ci, et du suivant ?
Cet article s'appuie sur des discussions techniques publiques et sur notre expérience du développement de logiciels de test. Il ne plaide pour aucun outil. Il donne une méthode de décision, les options qui existent aujourd'hui et les pièges de la migration.
1. Ce que disent les ingénieurs
Les ingénieurs décrivent le problème avec leurs propres mots. L'un d'eux, cherchant sur Hacker News un logiciel moderne d'automatisation de test en janvier 2026, résumait : « I'm happy to assemble the sequence logic myself if needed, but I'd love to avoid reinventing orchestration and run history/reporting from scratch » (fil). La compatibilité des instruments est l'autre thème récurrent : « VISA/SCPI is supposed to be cross-compatible but in reality that's hardly the case aside from *IDN and the basics » (EEVblog, juin 2026).
Les éditeurs bougent aussi. En juillet 2025, Emerson a annoncé un assistant IA ajouté à LabVIEW et TestStand. Rester sur l'environnement NI reste une option vivante, pas une impasse.
2. Le vrai problème est rarement le langage
Quand un poste existant devient pénible, les causes profondes que nous trouvons sont généralement architecturales, pas liées à LabVIEW lui-même :
- appels d'instruments, limites, logique de séquence et rapports mélangés dans un seul programme ;
- limites codées en dur dans les diagrammes ou les propriétés d'étapes, sans historique de versions ;
- drivers liés à un seul modèle d'instrument et une seule carte d'interface ;
- résultats stockés dans des fichiers locaux, sans lien avec le logiciel embarqué, la révision matérielle ou le poste ;
- un système d'exploitation et un runtime qu'on ne peut plus installer sur du matériel neuf.
Réécrire le même mélange en Python reproduit les mêmes problèmes dans un nouveau langage. L'objectif d'une migration est la structure décrite dans notre guide du script au séquenceur: séquence, limites, drivers d'instruments et résultats séparés.
3. Trois stratégies : conserver, encapsuler, réécrire
3.1 Conserver et stabiliser
Garder LabVIEW/TestStand, mais corriger ce qui fait mal : sortir les limites dans des fichiers externes versionnés, mettre le code en gestion de versions, isoler l'accès aux instruments dans des drivers, passer à un runtime et un système d'exploitation supportés.
Adapté quand : l'équipe a les compétences LabVIEW, le poste est qualifié et stable, les produits ont une longue durée de vie restante et les licences sont déjà en place.
3.2 Encapsuler : un orchestrateur moderne autour des modules existants
Conserver le code de mesure validé (VI ou DLL) et l'appeler depuis un nouveau séquenceur, ou l'inverse : laisser TestStand appeler des modules Python pour les nouvelles étapes. TestStand permet d'appeler des modules de code écrits dans plusieurs langages ; voir la présentation de TestStand.
Adapté quand : certaines étapes sont difficiles à revalider (mesures étalonnées, timing complexe), mais que vous voulez développer la suite dans un environnement plus ouvert. C'est souvent la voie la moins risquée.
3.3 Réécrire sur une base ouverte
Construire un nouveau programme en Python ou dans un autre langage généraliste, avec un framework de test ouvert.
Adapté quand : la plateforme ne peut plus tourner sur du matériel supporté, le poste est de toute façon repensé, ou une flotte de postes doit partager une base de code commune et versionnée.
Schéma décrit : la migration progressive (« strangler pattern »)
Imaginez l'ancien programme comme une grande boîte à gauche et le nouveau comme une boîte vide à droite. Entre les deux, une fine couche d'adaptation. Étape par étape, des groupes de tests passent de gauche à droite : d'abord les rapports, puis les drivers d'instruments, puis les séquences, une famille de produits à la fois. À chaque étape, le poste produit des résultats de production. L'ancienne boîte rétrécit jusqu'à pouvoir être retirée. Pas de bascule « big bang » sur un week-end.
4. Le paysage open source, en bref
Ce sont des références techniques neutres, ni recommandations ni partenaires :
- pytest: le framework de test Python généraliste. Excellent pour la structure, les fixtures et la CI ; le séquencement de production (messages opérateur, numéros de série, données poste) demande un travail supplémentaire.
- OpenHTF: un framework Python pour le test matériel, avec phases, mesures et limites.
- OpenTAP: un projet open source d'automatisation de test avec un séquenceur à plugins.
- PyVISA: l'accès Python aux instruments via VISA. Les utilisateurs signalent aussi de vrais problèmes terrain, comme des sessions longues qui commencent à renvoyer des timeouts après des heures ou des jours (PyVISA, ticket n° 948).
- Orchestrateurs plus récents: d'autres orchestrateurs open source, plus récents, existent aussi ; comparez-les sur les mêmes critères que les frameworks établis.
Pour l'interopérabilité des instruments, l' IVI Foundation maintient les spécifications VISA et IVI sur lesquelles reposent la plupart de ces outils.
5. Critères de choix
Notez chaque option selon ces critères, pour votre poste et pas dans l'absolu :
| Critère | Question à poser |
|---|---|
| Coût de revalidation | Combien d'étapes faut-il requalifier si le code change ? |
| Compétences | Qui maintiendra cela dans cinq ans, et que sait-il faire ? |
| Couverture instruments | Des drivers existent-ils pour chaque instrument, ou faut-il les écrire ? |
| Test en parallèle | Peut-on partager les instruments entre plusieurs produits en toute sécurité ? |
| Interface opérateur | Existe-t-il une IHM de production, ou faut-il la construire ? |
| Traçabilité | Chaque résultat enregistre-t-il version logicielle, version des limites, poste et numéro de série ? |
| Déploiement | Peut-on reconstruire le poste de zéro à partir de la gestion de versions ? |
| CI | Les séquences peuvent-elles tourner automatiquement sur un banc à chaque changement de logiciel embarqué ? |
| Licences et dépendance | Combien coûte chaque nouveau poste, et peut-on changer de fournisseur plus tard ? |
Le test en parallèle mérite une vérification spécifique. Partager une carte d'acquisition entre plusieurs produits est aussi une question fréquente côté NI (NI Community, septembre 2025), et c'est autant de travail en Python : le verrouillage des ressources doit être conçu, quel que soit l'outil.
6. Exemple chiffré : estimer l'effort de migration
Valeurs d'illustration, pour montrer la méthode, pas une référence.
Un poste compte 120 étapes de test sur 4 variantes de produit, avec 9 types d'instruments.
- Classer les étapes. Disons 80 simples (régler, mesurer, comparer), 30 avec gestion de timing ou de protocole, et 10 étalonnées ou critiques en métrologie.
- Affecter un poids par classe à partir de vos propres données passées, par exemple 1, 3 et 8 unités d'effort.
- Effort pour les étapes = 80 × 1 + 30 × 3 + 10 × 8 = 80 + 90 + 80 = 250 unités.
- Ajouter les drivers : 9 types d'instruments ; si 6 ont déjà des drivers ouverts maintenus et que 3 demandent un nouveau driver à 10 unités chacun, ajouter 30 unités.
- Ajouter la revalidation : pour chaque étape, une campagne de corrélation comparant anciens et nouveaux résultats sur les mêmes pièces. Si la corrélation prend 0,5 unité par étape, ajouter 60 unités.
- Total : 250 + 30 + 60 = 340 unités.
L'enseignement est dans la répartition : les 10 étapes critiques coûtent presque autant que les 80 simples. C'est l'argument pour les encapsuler d'abord et les réécrire en dernier, voire jamais.
7. Corrélation : prouver que le nouveau programme mesure la même chose
Avant que le nouveau programme ne remplace l'ancien, faites tourner les deux sur le même lot de pièces et comparez, étape par étape :
- le même verdict bon/mauvais sur chaque pièce ;
- des écarts de mesure analysés comme une étude de biais : le décalage moyen par étape doit être négligeable devant la tolérance et statistiquement non significatif (comparaison appariée sur les mêmes pièces), et la dispersion des écarts cohérente avec la répétabilité de chaque poste (gauge R&R sur les deux) ;
- le même comportement sur des pièces connues mauvaises, y compris des échantillons volontairement défectueux.
Des pièces qui changent de verdict près d'une limite sont attendues ; des décalages systématiques ne le sont pas. Consignez l'étude dans la qualification du poste ; notre guide sur la qualification de banc de test, FAT et SAT explique comment la cadrer, et ATP vs QTP précise quels tests relèvent de l'acceptation et lesquels de la qualification.
8. Erreurs fréquentes
- Traduire le code ligne à ligne. On garde l'ancienne architecture et on perd les points forts de l'ancien outil.
- Tout migrer d'un coup. Une bascule « big bang » sur un poste de production transforme chaque bug en arrêt de ligne.
- Sous-estimer les drivers. Les problèmes de compatibilité d'instruments reviennent sans cesse sur les forums techniques ; budgétez-les explicitement.
- Oublier l'opérateur. Un framework puissant sans écran opérateur clair échoue en atelier.
- Pas d'étude de corrélation. Sans elle, personne ne peut prouver qu'un nouveau « bon » vaut un ancien « bon ».
- Perdre le savoir implicite. Les temporisations et contournements non documentés de l'ancien code cachent souvent un vrai comportement matériel. Comprenez pourquoi chacun existe avant de le supprimer.
9. Check-list avant de décider
- Inventaire : étapes, variantes, instruments, cartes d'interface, versions de l'OS et du runtime.
- Liste des irritants : qu'est-ce qui fait vraiment mal (coût, matériel, compétences, traçabilité, vitesse) ?
- Étapes classées par risque de revalidation.
- Disponibilité des drivers vérifiée pour chaque instrument.
- Stratégie choisie : conserver, encapsuler ou réécrire, par poste ou par groupe d'étapes.
- Architecture cible écrite : séquence, limites, drivers et résultats séparés.
- Plan de migration par incréments, le poste produisant à chaque étape.
- Protocole de corrélation défini, échantillons connus mauvais compris.
- Interface opérateur et rapports validés avec la production.
- Périmètre de requalification convenu avant la bascule.
10. La place du matériel
La migration logicielle est souvent l'occasion de revoir la couche physique : accès aux signaux, injection de défauts, pilotage de l'alimentation. Les breakout boxes facilitent les mesures de corrélation, un banc compact comme notre Mini HIL test bench permet de développer et valider les nouvelles séquences sur du matériel réel avant la production, et notre guide sur l' architecture d'un banc HIL montre comment les couches s'articulent. Nos propres logiciels de test reposent sur une base Python, avec une intégration TestStand ou LabVIEW quand les postes d'un client l'exigent.
Vous envisagez de moderniser un poste de test existant ? Dites-nous ce qu'il fait tourner et ce qui coince, nous vous aiderons à choisir entre conserver, encapsuler et réécrire. Demander un devis
