NI Emerson (ex National Instruments) recommande une mise à jour "urgente" de NI-PAL. Une vérification simple peut permettre d'éviter des dysfonctionnements de vos équipements de mesure après certaines mises à jour Windows, à partir du 10 novembre 2026.

Dans le cadre de notre veille technique et de notre partenariat de plus de 25 ans avec NI Emerson, MESULOG souhaite partager une information importante concernant la sécurité et le bon fonctionnement des systèmes de mesure et de test automatisés.

NI a identifié plusieurs vulnérabilités affectant NI-PAL, un composant logiciel utilisé par de nombreux drivers NI. Un correctif est disponible et son installation ne nécessite généralement pas de modifier les applications LabVIEW, TestStand ou les versions des drivers NI existants.

Au-delà de l'aspect cybersécurité, cette mise à jour mérite une attention particulière : à partir du 10 novembre 2026, les mises à jour de sécurité Windows bloqueront le chargement des anciennes versions de NI-PAL sur les postes où la protection contre les drivers vulnérables est active, avec des conséquences directes sur le fonctionnement des bancs de test.

1. Qu'est-ce que NI-PAL et à quoi sert-il ?

NI-PAL (NI Platform Abstraction Layer) est un composant logiciel de bas niveau utilisé par de nombreux drivers NI. Il fournit des services techniques communs permettant aux drivers de communiquer avec le système d'exploitation et d'accéder aux ressources nécessaires au fonctionnement des équipements de mesure.

Prenons l'exemple d'un banc de test automatisé utilisant une carte d'acquisition NI :

• LabVIEW ou TestStand pilote les séquences de test et les opérations de mesure.
• NI-DAQmx assure la communication avec la carte d'acquisition.
• NI-PAL fournit des services système utilisés par les drivers NI.
• Windows gère les ressources du système et les échanges avec le matériel.

Cette présentation simplifiée permet de comprendre pourquoi NI-PAL peut être installé sur un ordinateur sans que son utilisateur en ait connaissance. NI-PAL est notamment susceptible d'être présent sur les PC équipés de drivers NI-DAQmx, NI-VISA, NI-RIO ou d'autres composants logiciels NI Emerson. Il peut également rester installé sur un PC même lorsque les équipements NI ne sont plus utilisés.

Le point important : ce n'est pas l'utilisation de LabVIEW ou TestStand qui détermine si vous êtes concerné, mais la présence d'une version vulnérable de NI-PAL sur votre système.

2. Quelle est la vulnérabilité identifiée ?

NI Emerson a publié plusieurs bulletins de sécurité concernant NI-PAL, notamment la vulnérabilité CVE-2026-18485, qui affecte les versions 26.3.1 et antérieures sous Windows 11 et 10 64 bits. Seules les installations sous Windows sont concernées.

Cette vulnérabilité peut permettre une élévation de privilèges, c'est-à-dire l'obtention de droits système supérieurs à ceux normalement accordés à un utilisateur. Il est toutefois important de préciser que son exploitation nécessite un accès local authentifié à l'ordinateur. Il ne s'agit donc pas d'une faille directement exploitable à distance depuis Internet par un utilisateur non authentifié.

Cela permet de relativiser le risque, notamment sur certains bancs de test industriels fonctionnant sur des réseaux isolés et disposant d'accès utilisateurs contrôlés. Cette restriction ne supprime cependant pas le risque de sécurité, et NI recommande l'installation du correctif.

Local Privilege Escalation in NI-PAL — CVE-2026-18485

Consulter le bulletin de sécurité NI — CVE-2026-18485

3. Pourquoi anticiper la date du 10 novembre 2026 ?

Microsoft maintient une liste de drivers présentant des vulnérabilités connues, dont le chargement peut être bloqué par les mécanismes de sécurité de Windows. Certaines anciennes versions de NI-PAL sont concernées par ce dispositif.

À partir du 10 novembre 2026, les mises à jour de sécurité Windows bloqueront le chargement du composant NI-PAL dès lors que la protection correspondante est activée.

Pour un banc de test industriel, les conséquences possibles sont notamment :

• Des équipements NI qui ne sont plus reconnus dans NI Measurement & Automation Explorer (NI MAX).
• Des erreurs de communication avec les instruments ou les cartes d'acquisition.
• Des applications LabVIEW ou TestStand ne parvenant plus à accéder aux équipements.
• Une indisponibilité temporaire du banc de test ou du moyen d'essai.

Le risque concerne particulièrement Windows 11, sur lequel la liste de blocage des drivers vulnérables est activée par défaut. Sous Windows 10, cette protection peut également être activée selon la configuration de sécurité de l'entreprise.

Cela ne signifie pas que tous les bancs de test vont cesser de fonctionner le 10 novembre. Il s'agit d'une évolution de sécurité Windows qui peut affecter certaines installations utilisant une version vulnérable de NI-PAL. L'objectif est donc d'anticiper cette situation plutôt que de découvrir un problème lors d'une prochaine mise à jour du système.

4. Quels systèmes sont susceptibles d'être concernés ?

Nous recommandons cette vérification aux utilisateurs de PC Windows équipés de composants logiciels NI Emerson, notamment :

• Les bancs de test automatisés développés avec LabVIEW ou TestStand.
• Les systèmes d'acquisition utilisant des équipements PXI, PCI, PCIe ou CompactDAQ.
• Les postes équipés de drivers NI-DAQmx, NI-VISA ou NI-RIO.
• Les applications industrielles de supervision ou de pilotage utilisant des équipements NI.
• Les systèmes de mesure anciens, même lorsqu'ils ne font plus l'objet de mises à jour régulières.

Les applications développées par MESULOG peuvent également être concernées lorsque leur environnement Windows comprend des drivers NI utilisant NI-PAL. Il ne s'agit pas d'une vulnérabilité propre aux applications développées par MESULOG, mais d'un composant d'infrastructure fourni par NI Emerson.

5. Comment vérifier si votre PC nécessite la mise à jour ?

La vérification prend moins d'une minute et ne nécessite aucune modification de votre installation. Sur votre PC Windows :

1. Ouvrez l'Explorateur de fichiers.
2. Accédez au dossier C:\Windows\System32\drivers.
3. Recherchez le fichier nipalk.sys.
4. Faites un clic droit sur ce fichier, puis sélectionnez Propriétés → Détails.
5. Consultez le champ Version du produit.

Comment interpréter le résultat ?

Une version ancienne ne signifie pas que votre installation a été compromise. Elle indique simplement que le composant doit être corrigé.

6. Comment effectuer la mise à jour ?

NI propose une mise à jour ciblée vers NI-PAL 2026 Q3 (26.5) ou une version ultérieure corrigée. Cette intervention ne nécessite normalement pas :

• De changer de version de LabVIEW.
• De changer de version de TestStand.
• De mettre à jour l'ensemble des drivers NI.
• De modifier le code source de vos applications de mesure.

Exception : les postes équipés de caméras utilisant NI-IMAQdx 19.5 ou antérieur, qui nécessitent une mise à jour préalable de Vision Acquisition Software (voir « Cas particulier : caméras et NI-IMAQdx » ci-dessous).

NI annonce une rétrocompatibilité avec les versions de NI-PAL jusqu'à la version 17.0 au minimum. L'installation prend généralement environ une minute et nécessite un redémarrage du PC.

Les instructions officielles et le correctif sont disponibles sur le site de NI : NI — Mise à jour de sécurité NI-PAL : instructions officielles

Quelques précautions pour les bancs de test industriels

Même si la mise à jour est annoncée compatible, MESULOG recommande de prendre quelques précautions sur les installations en exploitation :

• Vérifier la configuration logicielle existante.
• Prévoir une sauvegarde ou une possibilité de restauration.
• Planifier l'intervention pendant une période adaptée.
• Redémarrer le PC après installation.
• Vérifier la reconnaissance des équipements NI.
• Effectuer un essai fonctionnel représentatif du banc de test.

Cas particulier : caméras et NI-IMAQdx

NI a documenté une incompatibilité entre NI-PAL 2026 Q3 (26.5) et les versions 19.5 et antérieures de NI-IMAQdx, le driver installé avec Vision Acquisition Software pour les caméras USB, GigE Vision, Camera Link, etc. Le symptôme est sans ambiguïté : après la mise à jour, les caméras n'apparaissent plus dans NI MAX, et ne sont donc plus accessibles depuis LabVIEW.

Sur un poste équipé de caméras, il faut donc relever les versions installées avant toute intervention : dans NI MAX, Mon système › Logiciels, puis sélectionner NI-IMAQdx et NI-PAL.

• LabVIEW 2017 à 2020 : installer Vision Acquisition Software 20.0 ou ultérieure via NI Package Manager, vérifier que NI-IMAQdx 20.0 est bien présent, puis contrôler la détection des caméras.
• LabVIEW 2014 à 2016 : NI-IMAQdx 20.0 ne prend pas en charge ces versions. Deux options : migrer vers LabVIEW 2017 ou ultérieur, ou conserver une combinaison existante (NI-IMAQdx 17.5 avec une version de NI-PAL compatible), au prix du correctif de sécurité.
• Caméras FireWire (IEEE 1394) : leur prise en charge a été retirée dans NI-IMAQdx 20.0. Ces systèmes peuvent devoir rester sur une combinaison antérieure.

Point d'attention : NI ne documente pas, à ce jour, de procédure de retour arrière pour NI-PAL. Retrouver une configuration fonctionnelle peut imposer de désinstaller l'ensemble des logiciels NI puis de réinstaller les versions précédentes. Une sauvegarde ou une image disque du poste avant intervention prend ici tout son sens.

Consulter l'article NI : caméras non détectées dans NI MAX après la mise à jour NI-PAL 2026 Q3

7. MESULOG peut vous accompagner

Depuis plus de 25 ans, MESULOG accompagne les industriels dans le développement de logiciels de mesure, l'automatisation des essais et le pilotage de bancs de test, notamment autour des technologies NI. Notre expertise des environnements LabVIEW, TestStand, NI-DAQmx, NI-VISA et des architectures de mesure industrielles nous permet d'intervenir sur des installations existantes, y compris lorsqu'elles n'ont pas été développées par nos équipes.

Notre volonté : Mesure, Tratement, Descision. De la mesureau au traitement pour extraire l'information utile et permettre de prendre une descision. 

Dans le cadre de cette mise à jour NI-PAL, nous pouvons vous accompagner pour :

• Identifier les installations concernées — vérifier les versions de NI-PAL et des drivers NI présents sur vos systèmes.
• Évaluer les risques de compatibilité — analyser les contraintes éventuelles liées à votre environnement logiciel, à vos équipements ou à l'ancienneté de votre banc de test.
• Préparer et réaliser la mise à jour — vous assister dans l'installation du correctif, en tenant compte des contraintes d'exploitation de votre installation.
• Valider le bon fonctionnement du système — vérifier les communications avec les équipements, les acquisitions et les principales fonctions de votre banc après intervention.

Notre objectif n'est pas simplement d'appliquer une mise à jour informatique, mais de préserver la disponibilité et la fiabilité de vos moyens de mesure et de test. Cet accompagnement s'adresse aussi bien à nos clients historiques qu'aux industriels exploitant des installations NI développées par d'autres intégrateurs.

8. Synthése par MESULOG

Les systèmes dotés de NI-PAL 26.3.1 ou version antérieure sont affectés et doivent être mis à jour. La liste de blocage des drivers vulnérables est activée par défaut sous Windows 11 mais pas sous Windows 10, bien que les paramètres aient pu être modifiés par le client ou le service informatique. La mise à jour NI-PAL assure une rétrocompatibilité avec les versions de NI-PAL jusqu'à la version 17.0 au minimum

9. Une occasion de vérifier la pérennité de vos systèmes de test

Cette actualité illustre une réalité des systèmes de mesure industriels : leur fonctionnement ne dépend pas uniquement de l'application logicielle ou du matériel d'acquisition. Les drivers, bibliothèques et composants du système d'exploitation participent également à la fiabilité de l'ensemble.

Le suivi de ces composants fait donc partie des bonnes pratiques permettant de maintenir les performances et la disponibilité d'un banc de test tout au long de son exploitation. Dans le cas de NI-PAL, une simple vérification permet d'identifier les installations concernées et de préparer sereinement la mise à jour.

Vous souhaitez vérifier votre installation ou être accompagné dans cette démarche ? Les équipes MESULOG sont à votre disposition pour vous conseiller, analyser votre configuration et vous accompagner dans la mise à jour et la validation de vos systèmes de mesure.

Contactez MESULOG

Références techniques

• NI — Required NI-PAL Security Update
• NI — Bulletin de sécurité CVE-2026-18485
• NI — Caméras non détectées après la mise à jour NI-PAL 2026 Q3 (NI-IMAQdx)

Article rédigé le 22 octobre 2026 sur la base des informations publiées par NI Emerson. Les recommandations officielles de NI restent prioritaires et peuvent évoluer.

10. Service de mise à jour NI : mise à jour urgente

le 27/10/2026 nous avons constaté la publication de la mise jour urgente via le Service de mise à jour NI.

C'est la méthode la plus simple et que nous recommandons pour mettre à jour NI-PAL driver 2026 Q3. Cette mise à jour corrige la vulnérabilité CVE-2026-18485 d'élévation de privilèges locale dans le driver du noyau NI-PAL.

Sélectionner "Driver NI (NI-PAL) 2026 Q3 et cliquer sur le bouton "Installer"

L’arrivée des IA génératives dans le développement logiciel nous amène à repenser une question que nous pensions pourtant bien maîtriser : comment préserver le patrimoine logiciel d’une entreprise dans le temps ?

Cette réflexion est née récemment lors d’un échange avec notre équipe de développement.

Nous parlions d’IA générative, de Claude Code, de ChatGPT Codex, de Git / SVN, de documentation et surtout de la façon dont nous devrions structurer nos futurs projets.

La discussion nous a amenés à une question assez simple :

Qu’est-ce qu’une entreprise doit réellement préserver pour être capable de maintenir un logiciel dans 3, 5 ou 10 ans ?

Historiquement : préserver le code et son environnement de développement

Pendant longtemps, nous avons essentiellement conservé deux choses : le code source et l’environnement permettant de le développer et de le reconstruire.

Le premier élément paraît évident. Git, SVN et les autres systèmes de gestion de versions nous permettent de conserver l’historique des sources et de revenir précisément à un état donné du logiciel.

Mais le code seul n’est déjà pas suffisant.

Il faut également être capable de retrouver l’environnement qui permet de le compiler, de l’exécuter, de le tester et de générer les livrables.

Lorsque cet environnement de développement est virtualisé, conserver la machine virtuelle permet par exemple de préserver l’OS, les versions des outils, les dépendances et les configurations spécifiques.

Bref, de retrouver plusieurs années plus tard l’environnement technique du développeur.

L’équation était finalement assez simple :

Code source + environnement de développement = nous pensions avoir l’essentiel.

L’IA générative introduit un troisième élément : le contexte

Avec l’utilisation croissante des IA génératives pour développer des logiciels, je pense qu’il faut désormais ajouter quelque chose à cette équation :

le contexte… et l’IA qui l’interprète.

Car lorsqu’un développeur travaille avec une IA, le code produit ne dépend plus uniquement de son environnement de développement.

Il dépend aussi des informations données au modèle : besoins fonctionnels, contraintes métier, architecture logicielle, règles de développement, décisions techniques, échanges importants avec l’IA, corrections successives, historique des choix…

Tous ces éléments participent désormais, directement ou indirectement, à la production du code.

Le code devient ainsi, en partie, le résultat d’un environnement de connaissances.

Conserver les sources ne signifie plus nécessairement conserver tout le projet

C’est probablement le point qui nous interroge le plus.

Imaginons que nous devions reprendre un projet dans cinq ans.

Nous avons conservé son dépôt Git.

Nous avons conservé la machine virtuelle permettant de retrouver exactement son environnement de développement.

Nous avons même conservé sa documentation.

Mais nous avons perdu le contexte utilisé pendant son développement assisté par IA : les décisions, les règles données au modèle, certains échanges importants et les raisons ayant conduit à tel ou tel choix d’architecture.

Avons-nous réellement conservé tout ce qui est nécessaire pour reprendre efficacement le projet ?

Je pense que la réponse est de moins en moins évidente.

Le dépôt comme mémoire du projet, et plus seulement du code

Cette réflexion nous amène donc à regarder différemment nos dépôts logiciels.

Un dépôt ne devrait peut-être plus seulement être la mémoire du code.

Il pourrait également devenir la mémoire structurée du contexte nécessaire pour comprendre ce code, le maintenir et continuer à le faire évoluer.

Il ne s’agit évidemment pas de conserver aveuglément toutes les conversations avec une IA.

L’enjeu est plutôt d’identifier ce qui constitue réellement la connaissance du projet et mérite d’être capitalisé : règles, contexte, décisions d’architecture, choix techniques, informations nécessaires à la reprise du développement, mais aussi tests, documentation et processus d’intégration et de build.

Nous ne parlons donc plus seulement de sauvegarder du code.

Nous parlons progressivement de préserver un patrimoine logiciel composé du code, de son environnement et de la connaissance qui a permis de le produire.

Un nouvel enjeu pour le maintien en condition opérationnelle des logiciels

L’objectif reste finalement celui de n’importe quelle équipe de développement : assurer le maintien en condition opérationnelle de ses logiciels dans la durée.

On pourrait le résumer par un test assez simple :

Dans trois ans, un développeur qui ne connaît pas le projet doit pouvoir retrouver le code, son environnement et son contexte, comprendre les décisions prises et poursuivre son développement avec les outils d’aujourd’hui… ou ceux de demain.

Nous avons appris à versionner le code.

Nous avons appris à préserver les environnements de développement.

Avec les IA génératives, nous allons devoir apprendre à versionner le contexte qui permet de produire le logiciel.

Et c’est peut-être l’un des prochains défis du génie logiciel

Sherlock Holmes était probablement un bon développeur LabVIEW

Lors des NI Days Paris 2026, j'ai eu le plaisir d'animer, avec Amaury Laurent, une présentation consacrée à un sujet que tous les développeurs connaissent : la mise au point d'applications LabVIEW.

Article écrit par Luc DESRUELLE président des sociétés Nerys et MESULOG, LabVIEW Architecte, LabVIEW Champion et TestStand Developpeur.

En préparant cette intervention, une évidence s'est imposée : Sherlock Holmes aurait probablement été un excellent développeur.

Pourquoi ?

Parce que la recherche d'un bug ressemble rarement à un exercice de programmation. C'est avant tout une enquête.

Lorsque survient un dysfonctionnement, la méthode est souvent la même :

• auditionner les témoins (les utilisateurs) ;
• collecter les indices (logs, traces, captures d'écran) ;
• reproduire la scène du crime ;
• établir plusieurs hypothèses ;
• éliminer méthodiquement les mauvaises pistes.

Comme l'écrivait le célèbre détective :

« Quand vous avez éliminé l'impossible, ce qui reste, aussi improbable soit-il, doit être la vérité. »

Aujourd'hui, un nouvel assistant a rejoint l'équipe d'enquête : l'intelligence artificielle. Elle peut analyser des fichiers de traces, rechercher des corrélations, résumer des milliers de lignes de logs ou proposer des pistes d'investigation en quelques secondes.

Mais, comme le docteur Watson auprès de Sherlock Holmes, elle assiste l'enquêteur sans le remplacer. La compréhension du contexte, l'esprit critique et la validation des hypothèses restent l'affaire du développeur.

Les développeurs expérimentés savent que les bugs les plus complexes se résolvent rarement par intuition. Ils se résolvent par l'observation, la logique et une bonne dose de persévérance.

Finalement, derrière chaque application qui fonctionne correctement se cache souvent une petite enquête digne du 221B Baker Street.

Pour ceux qui souhaitent découvrir cette approche appliquée à LabVIEW, ainsi que quelques techniques modernes d'analyse de traces assistées par l'IA, la présentation complète des NI Days Paris 2026 est désormais disponible sur le site MESULOG.

Un grand merci à Amaury Laurent pour m'avoir accompagné dans cette présentation.

Merci également à la communauté LabVIEW, aux forums d'assistance et à tous ceux qui partagent depuis des années leurs expériences, leurs analyses et parfois leurs enquêtes les plus improbables. Une partie de cette conférence leur doit beaucoup.

la présentation est disponible sur notre site NIDays 2026 : LabVIEW Debugging Tips and Tricks

LabVIEW Debugging : la mise au point n'est pas un art, c'est une enquête

Retour d'expérience présenté aux NI Days Paris 2026 Par Luc DESRUELLE, certifié LabVIEW Architecte, LabVIEW Champion

LabVIEW Debugging : méthodologie, outils NI et intelligence artificielle pour diagnostiquer efficacement les applications industrielles

Lors des NI Days Paris 2026, j'ai eu le plaisir d'animer avec Amaury Laurent une session consacrée à un sujet que tous les développeurs connaissent : la mise au point d'applications LabVIEW.

Le débogage est probablement l'activité la plus universelle du métier d'ingénieur logiciel. Pourtant, c'est également l'une des plus mal comprises. Trop souvent, lorsqu'un bug apparaît, la réaction consiste à modifier du code jusqu'à ce que le problème semble disparaître.

Cette approche fonctionne parfois.

Mais elle ne permet pas de comprendre.

Et lorsqu'on ne comprend pas, le problème finit toujours par revenir.

Qu'est-ce qu'un bug ?

Au cours de ma carrière, j'ai entendu des centaines de fois les mêmes phrases :

• « Chez moi ça marche. »
• « C'est normal, c'est codé comme ça. »
• « C'est bon, j'ai corrigé. »

Ces réponses traduisent généralement une réaction instinctive face à un problème.

Or un bug est rarement un simple défaut de programmation.

C'est souvent un écart entre :

• ce que le client attend,
• ce que le cahier des charges décrit,
• ce que le développeur croit avoir développé,
• et ce que le système exécute réellement.

La première étape consiste donc à abandonner l'intuition pour adopter une démarche d'enquête.

La meilleure mise au point est celle que l'on évite

Une part importante des défauts logiciels ne provient pas d'une erreur algorithmique.

Ils sont la conséquence directe d'une absence de méthode :

• architecture mal définie,
• code peu lisible,
• absence de documentation,
• gestion d'erreur incomplète,
• manque de traçabilité,
• absence de tests.

Chez MESULOG et NERYS, nous défendons une approche simple :

prévenir plutôt que corriger.

Cela passe notamment par :

• l'utilisation d'architectures éprouvées (QMH, DQMH),
• des règles de développement partagées,
• l'analyse statique du code avec VI Analyzer,
• des revues de code régulières,
• une gestion d'erreur systématique,
• des fichiers de diagnostic et de journalisation.

Un logiciel doit être conçu en pensant dès le premier jour à sa future mise au point.

Déboguer, c'est mener une enquête

La mise au point suit une démarche comparable à une investigation.

Lorsque le bug apparaît :

1. Écouter les utilisateurs et reformuler précisément le problème.
2. Catégoriser le dysfonctionnement.
3. Collecter les indices disponibles.
4. Reproduire le problème.
5. Formuler des hypothèses.
6. Tester ces hypothèses.
7. Corriger.
8. Valider.
9. Documenter.

Cette méthodologie peut sembler évidente.

Pourtant, elle est souvent remplacée par une succession d'essais aléatoires qui compliquent encore davantage l'analyse.

Comme dans une enquête, tous les indices ne sont pas forcément vrais.

Un message d'erreur est parfois une conséquence et non la cause du problème.

Une correction n'est valide que lorsqu'elle explique l'ensemble des faits observés.

Les fichiers de traces sont devenus une mine d'informations

Les applications modernes produisent une quantité importante de données de diagnostic :

• journaux applicatifs,
• fichiers de log,
• traces systèmes,
• crash dumps,
• événements Windows,
• rapports LabVIEW.

Ces informations sont devenues indispensables pour comprendre le comportement réel d'un système.

Lorsqu'elles sont correctement conçues, elles permettent souvent d'identifier rapidement l'origine d'un dysfonctionnement.

Nous recommandons systématiquement de mettre en place :

• un journal des erreurs,
• un journal de diagnostic,
• une historisation des événements utilisateurs,
• des informations de contexte facilitant l'analyse.

Une erreur sans contexte est rarement exploitable.

Une erreur enrichie d'informations pertinentes devient un indice précieux.

Intelligence artificielle : révolution ou simple gadget ?

L'un des sujets les plus discutés pendant les NI Days concernait l'utilisation de l'intelligence artificielle dans la mise au point logicielle.

Mon retour d'expérience est clair.

L'IA apporte une valeur considérable lorsqu'il s'agit :

• d'analyser des volumes importants de fichiers de log,
• d'interpréter des messages d'erreur complexes,
• de corréler des événements,
• d'expliquer rapidement certains comportements.

En quelques secondes, un assistant IA peut analyser des milliers de lignes de traces.

C'est un gain de productivité considérable.

Mais l'IA possède également une limite fondamentale :

elle ne connaît pas votre contexte métier.

Elle ne connaît pas votre architecture.

Elle ne connaît pas vos contraintes industrielles.

Elle ne connaît pas l'historique du projet.

Elle ne connaît pas l'intention du développeur.

L'expertise humaine reste indispensable pour interpréter correctement les résultats.

L'avenir n'est donc pas l'humain ou l'IA.

L'avenir est la collaboration entre les deux.

L'IA apporte la puissance de calcul.

L'ingénieur apporte le contexte.

Les nouveautés LabVIEW 2026 facilitent le travail des développeurs

LabVIEW continue d'évoluer pour améliorer l'expérience de débogage.

Parmi les nouveautés particulièrement intéressantes présentées lors de cette session :

• activation du débogage sur l'ensemble d'un projet,
• conservation des valeurs après exécution,
• amélioration de la gestion des sondes et points d'arrêt,
• nouvelles capacités de journalisation des erreurs non câblées,
• outils de visualisation améliorés.

Ces évolutions vont dans le bon sens : réduire le temps nécessaire pour comprendre un comportement inattendu.

Le cas particulier des fuites mémoire

Parmi les problèmes les plus difficiles à diagnostiquer figurent les fuites mémoire.

Les symptômes sont souvent trompeurs :

• ralentissements progressifs,
• instabilités aléatoires,
• redémarrages après plusieurs jours ou semaines,
• consommation mémoire croissante.

Les causes sont généralement connues :

• tableaux construits sans limite,
• chaînes concaténées indéfiniment,
• files d'attente non maîtrisées,
• références non libérées,
• historiques de graphiques trop importants.

La difficulté réside rarement dans la correction.

Elle réside dans l'identification précise du mécanisme responsable.

C'est là que des outils comme VI Profiler, DETT, RT Utilities ou les moniteurs système deviennent indispensables.

Conclusion

Après plus de vingt ans passés à développer des systèmes de test et de mesure, ma conviction reste la même : la mise au point n'est pas une activité de correction. C'est une activité de compréhension.

Le rôle du développeur n'est pas simplement de supprimer un symptôme.

Son rôle est de comprendre pourquoi un système ne se comporte pas comme prévu.

Lorsqu'une équipe adopte cette philosophie, les bugs deviennent moins nombreux, les corrections plus rapides et les logiciels plus robustes.

Finalement, mettre au point une application, ce n'est pas corriger du code.

C'est mener une enquête jusqu'à trouver une explication rationnelle à ce qui est observé.

Et comme dans toute enquête, les meilleurs résultats sont obtenus lorsque les indices, les outils et l'expérience travaillent ensemble.

50 ans de NI, 40 ans de LabVIEW, 25 ans de MESULOG & NERYS : l’histoire d’une révolution technologique…

Quand l’ingénierie logicielle a changé de langage

En 2026, le monde du test, de la mesure et de l’automatisation célèbre un double anniversaire exceptionnel : 50 ans de NI (National Instruments, aujourd’hui NI – Emerson) et 40 ans de LabVIEW, son logiciel emblématique. Fondée en 1976 à Austin par James Truchard, Bill Nowlin et Jeff Kodosky, NI est née avec une vision simple mais radicale : permettre aux ingénieurs de mieux interagir avec le monde réel grâce à des outils capables de mesurer, piloter et comprendre les systèmes physiques.  

Dix ans plus tard, en 1986, cette vision prend forme avec : LabVIEW (Laboratory Virtual Instrument Engineering Workbench). Jeff Kodosky, souvent surnommé “le père de LabVIEW”, introduit alors une idée révolutionnaire : et si les ingénieurs pouvaient programmer comme ils pensent ? Non plus uniquement avec des lignes de code textuelles, mais un code Graphique avec des flux de données visuels, des blocs fonctionnels et une logique graphique.  LabVIEW n’est pas seulement un nouveau logiciel, il est une nouvelle philosophie de développement, pensé par des ingénieurs pour des ingénieurs.

LabVIEW : bien plus qu’un langage, une nouvelle manière de concevoir

À une époque où le développement logiciel était souvent réservé aux spécialistes de langages textuels complexes, LabVIEW a démocratisé la création de systèmes avancés :

• Pilotage d’instruments
• Acquisition de données
• Automatisation de bancs de test
• Contrôle temps réel
• FPGA
• Vision industrielle
• Analyse avancée

Là où d’autres écrivaient des milliers de lignes de syntaxe, LabVIEW permettait de visualiser les interactions entre signaux, capteurs, calculs et décisions. Cette approche a profondément marqué l’industrie. Avec l’arrivée du PXI, CompactRIO, TestStand, VeriStand et des architectures distribuées, NI a progressivement bâti un écosystème complet allant du prototype au déploiement industriel massif.  

Pourquoi LabVIEW a été visionnaire : il anticipait déjà l’ère de l’IA

Aujourd’hui, l’intelligence artificielle générative fascine par sa capacité à produire du code. Mais en réalité, la philosophie de LabVIEW portait déjà depuis 40 ans cette ambition fondamentale : réduire la friction entre l’idée de l’ingénieur et son implémentation technique. Autrement dit : transformer l’intention technique en système fonctionnel plus rapidement. C’est précisément ce que recherchent aujourd’hui les outils d’IA générative : accélération, assistance, réduction des erreurs et productivité. LabVIEW a toujours poursuivi ce même objectif, mais avec une approche spécialisée “ingénierie système test et mesure”.

Nigel™ : l’IA selon NI, spécialisée pour l’ingénierie

En 2026, NI pousse cette logique encore plus loin avec NI Nigel™ AI, présenté dans l’écosystème LabVIEW+ Suite. Là où des IA généralistes comme ChatGPT ou Claude excellent dans la polyvalence, Nigel apporte un avantage stratégique majeur : une IA contextualisée dans le monde NI :

• Structures LabVIEW,
• TestStand,
• Drivers,
• Séquences de test,
• Architectures de mesure,
• Réutilisation de modèles d’ingénierie.

NIGEL est une “IA générative de code… mais orientée test & mesure.” Dans cette logique, Nigel n’est pas une rupture avec LabVIEW : C’est son évolution naturelle. LabVIEW a permis de visualiser la logique. Nigel vise à accélérer sa création.

MESULOG & NERYS : 25+ ans à concevoir des systèmes de test et mesure

Depuis plus de deux décennies, MESULOG et NERYS incarnent cette philosophie sur le terrain. Notre expertise ne consiste pas uniquement à "faire du LabVIEW ou du TestStand”. Elle consiste à industrialiser l’intelligence logicielle appliquée au test et à la mesure. Notre signature est de « Transformer les besoins complexes de test en valeur mesurable. Nos domaines d'expertises chez MESULOG & Nerys :

• Bancs de test automatisés
• Machines spéciales
• LabVIEW Windows / RT / FPGA
• TestStand
• Systèmes PXI / cRIO
• Data acquisition
• Traçabilité
• Analyse avancée
• Industrial Data Platform (VASCO + InfluxDB)
• IA appliquée aux systèmes de mesure
• Cyber sécurisation des architectures industrielles

L’avenir : du développeur pur à l’ingénieur chef d’orchestre des technologiques

Les prochaines années ne verront pas disparaître les ingénieurs. Elles verront évoluer leur rôle. Demain l’ingénieur ne codera pas moins. Il orchestrera mieux IA générative, Architecture, Validation, Cybersécurité, Traçabilité et Robustesse.

Pourquoi célébrer NI aujourd’hui ?

Parce que NI n’est pas seulement une entreprise technologique. C’est l’un des rares acteurs à avoir profondément modifié la manière dont les ingénieurs pensent leurs systèmes.

• 50 ans de NI : Une révolution dans le test et la mesure.
• 40 ans de LabVIEW : Une révolution dans le développement logiciel orienté ingénierie.

Conclusion

LabVIEW a été conçu par des ingénieurs pour des ingénieurs. Il a révolutionné la productivité dans le test et la mesure. Aujourd’hui, avec Nigel et l’IA spécialisée, cette vision entre dans une nouvelle phase. Chez MESULOG & NERYS, nous sommes fiers d’accompagner cette évolution. Des premiers bancs LabVIEW aux plateformes industrielles intelligentes de demain.

Bon anniversaire NI.

Bon anniversaire LabVIEW.

Et surtout : place aux 40 prochaines années d’innovation.

par Luc Desruelle, LabVIEW Champion, expert produit NI, certifié LabVIEW Architecte, certifié TestStand Développeur et Président des sociétés Mesulog et Nerys

MESULOG renforce son expertise en conception de bancs de test automatisés : deux experts certifiés NI TestStand Architect

Précurseur en France dans l’adoption de NI TestStand, MESULOG s’impose depuis plus de 25 ans comme une référence incontournable dans l’architecture de systèmes de test industriels complexes.

Aujourd’hui, nous sommes fiers d’annoncer une nouvelle étape dans cette dynamique d’excellence : deux de nos développeurs viennent d’obtenir la certification NI TestStand Architect (CTA), le plus haut niveau d’expertise sur l’architecture TestStand : Damien LAMY et Adrien ANDRIEU

Cette reconnaissance vient renforcer notre capacité à concevoir des architectures de test toujours plus robustes, évolutives et industrialisables, au service des environnements R&D, validation et production.

Rencontrer nos architectes pour créer des bancs de test automatisés intégrant IA, migration Windows 11, conformité cyber et réduction drastique des temps de développement.

Une certification d’excellence au service de l’industrie

La certification TestStand Architect valide une maîtrise avancée de :

• l’architecture logicielle de systèmes de test complexes
• la conception de frameworks industriels robustes
• l’industrialisation et la pérennisation des bancs de test
• la gestion avancée des données et du reporting
• les bonnes pratiques de développement industriel

Une expertise essentielle pour répondre aux enjeux de fiabilité, traçabilité et performance des systèmes de test modernes.

Pourquoi une certification TestStand est-elle importante pour nos clients ?

Elle garantit un développement dans les règles de l’art, reconnu par NI, et assure des solutions robustes. Grâce à nos modules logiciels réutilisables, nous réduisons de 60 % le temps de développement d’interfaces opérateur, mêlant médias interactifs et KPIs avancés (First/Last Pass Yield). Nos architectures gèrent la diversité des produits à tester et la diversité des instruments à piloter pour des bancs qui s'adaptent à la production. Notre savoir-faire électronique et électrotechnique nous permet de vous accompagner dans la sélection du matériel, l'adaptation à vos contraintes produits et la réalisation des coffrets ou armoires de tests.

En plus, nos experts facilitent la migration Windows 11 et la mise en conformité au Cyber Resilience Act. 

Une expertise collective unique chez MESULOG

Cette réussite s’inscrit dans une culture forte de la certification et de l’excellence technique.

Chez MESULOG, l’ensemble de nos développeurs sont certifié sur les technologies clés de l’écosystème NI :

• 3 certifications NI LabVIEW Développeur (CLD)
• 3 certifications NI TestStand Développeur (CTD)
• 3 certifications NI LabVIEW Architecte (CLA)
• 2 certifications NI TestStand Architecte (CTA)
• 1 certification NI Professionnel Instructions pour nos formation NI LabVIEW & NI TestStand (CPI)
• 1 reconnaissance LabVIEW Champion

Une densité d’expertise rare en France, qui garantit à nos clients un très haut niveau de maîtrise sur l’ensemble de la chaîne de test.

Dans les systèmes logiciels, la gestion du temps est un enjeu fondamental. Journalisation, traçabilité, synchronisation inter-systèmes, APIs, cybersécurité, bases de données distribuées, analyse de logs : tous reposent sur une représentation cohérente et normalisée de la date et de l’heure.

Parmi les standards existants, l'ISO 8601 est la référence technique internationale.

Pourquoi normaliser les dates ?

Les formats locaux comme :

• Ambiguïté internationale 04/05/2026 = 4 mai ou 5 avril ? par exemple le 01/12 est-il le 12 janvier Anglais ou le 01 décembre Français?
• Tri incohérent : Un classement textuel simple ne garantit pas l’ordre chronologique.
• Difficultés d’intégration : Les échanges entre applications, langages ou systèmes multi-pays deviennent fragiles.

L'ISO 8601 : structure officielle

Le format recommandé est : YYYY-MM-DDTHH:MM:SS Par exemple 2026-04-26T14:35:08

Décomposition :

Pourquoi le T est important ?

Le caractère T n’est pas cosmétique : il distingue officiellement la composante date de la composante horaire selon la norme ISO 8601.

• Ecriture correcte ISO : Le format correcte est : YYYY-MM-DDTHH:MM:SS, exemple 2026-04-26T14:35:08
• Il existe une alternative, au format YYYY-MM-DD HH:MM:SS, qui n'est pas strictement ISO, et dont un exemple est 2026-04-26 14:35:08. Ce second format reste fréquent (SQL, logs industriels), mais n’est pas la forme normalisée stricte. Il est souvent utilisé pour écrire des dates depuis LabVIEW vers les bases de données en SQL avec le driver ODBC.

Gestion des fuseaux horaires : point critique des développeurs

L’absence de fuseau peut provoquer des erreurs majeures dans :

• architectures cloud,
• systèmes embarqués,
• microservices,
• corrélation d’événements cybersécurité,
• pipelines de données internationaux.

UTC (recommandé) utilisation de la lettre Z pour Zulu Time = UTC

Bonnes pratiques de développement

1. Stockage

Toujours privilégier UTC pour :

• bases de données SQL par exemple, ou Access mdb,
• NoSQL,
• logs serveur,
• événements sécurité.

2. Affichage

Convertir ensuite vers le fuseau utilisateur.

3. API

Toujours transmettre : 2026-04-26T12:35:08Z

Exemples concrets par langage

Python :

JavaScript

SQL (SQL Server)

Erreurs fréquentes

• Oublier le fuseau : 2026-04-26T14:35:08
• Mélanger heure locale et UTC : Cause classique d’écarts de plusieurs heures.
• Utiliser des formats régionaux : 26/04/26

ISO 8601 et cybersécurité

Dans les systèmes d’analyse de sécurité :

• SIEM,
• détection d’incidents,
• forensic,
• corrélation réseau,

la précision temporelle est essentielle.

Une erreur de fuseau ou de format peut :

• fausser une chronologie d’attaque,
• compliquer l’investigation,
• rendre des preuves moins robustes.

ISO 8601 étendu : millisecondes et microsecondes

Usage :

• haute fréquence,
• acquisition rapide,
• instrumentation,
• événements réseau,
• systèmes temps réel.

Application du format pour les développeurs

• Standard robuste : YYYY-MM-DDTHH:MM:SS.sssZ
• Exemple : 2026-04-26T14:35:08.123Z

Conclusions

ISO 8601 n’est pas seulement un format de date : c’est un standard d’interopérabilité.

Pour un développeur, son adoption permet :

Avantages clés :

• compatibilité internationale,
• tri chronologique natif,
• robustesse API,
• cohérence base de données,
• meilleure analyse de logs,
• sécurité accrue,
• réduction des erreurs de conversion.

Règle simple :

• Pour les machines : 2026-04-26T14:35:08Z
• Pour les humains : Convertir à l’affichage.
• Stocker en UTC, transmettre en ISO 8601, afficher selon le contexte utilisateur.
• Dans un environnement logiciel moderne, bien gérer le temps n’est pas un détail technique : c’est une exigence d’architecture.

Conçu par Mesulog pour s’intégrer nativement dans l’environnement TestStand, le module InteractiveZone permet de remplacer et d’améliorer les Step Types Popup standards de TestStand. Il transforme l’expérience opérateur en proposant des interfaces plus interactives, modernes et intuitives, directement intégrées au cœur de vos séquences de test.

Grâce à l'InteractiveZone, les développeurs TestStand peuvent concevoir des interfaces dynamiques capables de communiquer efficacement avec les utilisateurs, tout en dépassant les limitations des popups natifs. Le module facilite la création d’interactions riches et personnalisées, adaptées aux besoins spécifiques des applications de test automatisé.

L’InteractiveZone permet d’afficher et de gérer facilement différents types de contenus : messages, images, vidéos, GIF, ainsi que des interfaces de saisie avancées. Le module intègre également une gestion multi-langue, permettant d’adapter dynamiquement les contenus et les interactions en fonction de la langue de l’opérateur. Les utilisateurs peuvent interagir via des champs texte, des entrées numériques ou des choix guidés par boutons, offrant ainsi une expérience utilisateur fluide, personnalisée et optimisée.

Flexible et puissant, ce module TestStand s’adapte à tous les cas d’usage : affichage d’instructions, validation opérateur, collecte de données ou assistance en temps réel. L'InteractiveZone constitue ainsi une solution idéale pour moderniser les interfaces opérateur et améliorer la productivité dans les environnements de test.

Une intégration fluide et flexible

L'InteractiveZone s’adapte à différents modèles de processus (séquentiel, batch ou parallèle). Il peut être utilisé aussi bien dans une interface LabVIEW que sous forme de fenêtre contextuelle, garantissant une expérience cohérente en phase de développement comme en production.

Sa palette dédiée de StepTypes permet une mise en œuvre rapide et intuitive :

• Informations : diffusion de contenu sans interaction requise
• Questions : interaction via boutons (jusqu’à 4 choix)
• Request String / Number : saisie utilisateur personnalisée
• Idle : réinitialisation de la zone interactive

Une expérience utilisateur optimisée

InteractiveZone améliore significativement la communication entre le système et l’opérateur. En rendant l’interface plus vivante et interactive, il facilite la compréhension des procesus, réduit les erreurs et augmente l’efficacité globale. Modulaire, personnalisable et puissant, InteractiveZone est la solution idéale pour moderniser vos interfaces opérateur et offrir une expérience utilisateur à forte valeur ajoutée.

L’intelligence artificielle générative s’impose progressivement dans les environnements industriels et de développement. C’est dans ce contexte que NI Emerson a présenté Nigel™ AI Advisor, le premier assistant IA spécifiquement conçu pour le domaine du test et de la mesure. Luc Desruelle, LabVIEW Champion, expert produit NI, certifié LabVIEW Architecte et directeur de la société Mesulog, a eu le grand plaisir de coanimer cette présentation aux côtés de Shauna L. Rae, afin de faire découvrir Nigel™ AI Advisor, ses usages concrets et sa vision à long terme.

Un assistant IA intégré à l’écosystème NI Emerson

Lors de cette session, nous avons notamment abordé :

• l’intégration native de Nigel™ AI Advisor dans l’écosystème des outils NI Emerson ;
• ses fonctionnalités actuelles ;
• la feuille de route et les évolutions à venir ;
• des démonstrations concrètes dans LabVIEW et TestStand.

Contrairement aux assistants IA généralistes, Nigel™ AI Advisor est directement intégré aux environnements de développement NI, ce qui lui permet de comprendre et d’analyser le code graphique, ainsi que les contextes matériels et logiciels propres au test et à la mesure.

IA générative : enjeux, limites et bonnes pratiques

La présentation a également été l’occasion d’aborder — avec sérieux et une touche d’humour — plusieurs sujets clés autour des IA génératives, notamment :

• la température des modèles LLM et son impact sur les réponses ;
• les phénomènes d’hallucinations ;
• les biais potentiels liés aux bases de données d’entraînement ;
• la sécurité des échanges de données ;
• la valeur réelle des IA lorsqu’elles sont spécialisées ;
• le rôle stratégique des assistants IA pour rester compétitif dans les environnements de développement (EDI).

Une expertise métier au cœur de Nigel™ AI Advisor

Nigel™ AI Advisor est un assistant de type LLM, basé sur les technologies OpenAI, mais enrichi et spécialisé grâce à l’expertise unique de NI Emerson. Il s’appuie sur une base de données de solutions matérielles et logicielles construite sur plusieurs décennies d’expérience dans le test et la mesure. Cette expertise métier est un facteur clé pour fournir des réponses pertinentes, exploitables et adaptées aux contraintes industrielles, là où les outils généralistes atteignent rapidement leurs limites.

Un véritable accélérateur de développement

Si les outils d’IA générative présentent encore certaines limites, leur valeur devient tangible lorsqu’ils sont spécialisés et correctement intégrés. Nigel™ AI Advisor s’impose déjà comme un assistant efficace pour :

• documenter et analyser des applications existantes ;
• accélérer les phases de développement ;
• identifier la meilleure configuration matérielle ;
• générer des exemples de code d’acquisition adaptés aux besoins réels.

Accéder à la présentation complète

La présentation complète de Nigel™ AI Advisor est disponible dans la page LUGE 2025.4 : Retour d'expérience sur l'assistant IA Nigel

Une décision d’ingénierie, pas une simple mise à jour IT  En 2026, la question n'est plus d'anticiper la fin du support de Windows 10 (intervenue en octobre 2025), mais de gérer l'obsolescence critique de vos moyens de production et de R&D. Pour les bancs de test et les systèmes automatisés, migrer vers Windows 11 est devenu le garant de la fiabilité des essais et de la conformité réglementaire. 

Au-delà de l'accompagnement, MESULOG s'engage à vos côtés pour transformer cette contrainte en une opportunité de modernisation, en concevant des solutions sur mesure adaptées à vos environnements de mesure les plus exigeants. 

Windows 11 : Un changement structurel du socle industriel 

Windows 11 introduit un durcissement de la sécurité qui modifie les règles d’exécution des logiciels industriels.  

Le constat : Un système fonctionnel sous Windows 10 peut présenter des blocages ou des dégradations silencieuses sous Windows 11 s'il n'a pas été préparé. 

Pourquoi vos bancs de mesure sont-ils si sensibles ? 

Les environnements industriels cumulent des facteurs de complexité qui ne pardonnent pas l'improvisation : 

• Accès matériel bas niveau : Pilotage des châssis PXI, des cartes DAQ ou des bus de terrain (EtherCAT, CAN). 
• Dépendance Drivers : Nécessité de Runtimes spécifiques et souvent anciens. 
• Cycle de vie long : Maintien des logiciels sur 15 ou 20 ans. 
• Traçabilité : Interconnexions critiques avec les MES et bases de données. 
• L'enjeu n'est pas seulement informatique : un banc instable, c'est un arrêt de production, des données de test invalides et une exposition réglementaire accrue.

Cybersécurité & Conformité : Le nouveau standard 

• Défense en profondeur  Windows 11 généralise des mécanismes comme le Smart App Control (blocage des exécutables non fiables) et l'ancrage matériel TPM 2.0. Ce ne sont pas des options décoratives, mais des barrières indispensables contre les attaques visant l'OT (Operational Technology). 
• L'impact du Cyber Resilience Act (CRA)  Le cadre réglementaire européen impose désormais que les produits numériques soient maintenus et sécurisés sur tout leur cycle de vie. Exploiter un système basé sur un OS non supporté (Windows 10) devient engage votre responsabilité lors d'un audit de conformité ou en cas d'incident. 

La méthodologie MESULOG : Un processus en 4 étapes

Migrer un système industriel ne se résume pas à cliquer sur "Mettre à jour". 

1. Audit global : Analyse de compatibilité matérielle, inventaire des drivers (NI-DAQmx, VISA) et analyse des architectures (32 vs 64 bits). 
2. Modernisation : Migration d’applications vers le 64 bits, mise à niveau LabVIEW / TestStand et intégration de modules avancés (TS Semiconductor Module). 
3. Durcissement maîtrisé : Configuration des politiques de sécurité Windows sans bloquer les processus industriels. 
4. Validation & Non-régression : Tests intensifs pour garantir que vos résultats de mesure 2026 sont identiques à ceux de 2024. 

Si vous êtes amateur de match de foot ou de rugby, vous avez forcément déjà vu des arbitres équipés d’un système audio de la société VOGO. L’entreprise, spécialisée dans le développement de systèmes de communication audio et de diffusion live & replay vidéo, propose notamment des systèmes radio VOKKERO, conçus et développés pour les professionnels du sport (arbitres, médecins, coachs, analystes vidéo), et les équipes terrain de l’industrie (en particulier BTP, industries bruyantes, transports, énergies et sécurité) et de l’audiovisuel.

La signature de ces systèmes ? Ils sont dotés d’un filtre de bruit breveté, qui rend la communication et le travail possible dans des environnements très bruyants tels que les stades, les usines, les chantiers et les lieux de spectacles/tournages.

Afin de garantir une fiabilité irréprochable, ces produits sont systématiquement soumis à des tests rigoureux. MESULOG, spécialisée dans le développement de logiciels de tests et de mesure pour l’industrie, a accompagné VOGO dans le déploiement de procédures de tests automatisées, sous NI TestStand, pour tout un écosystème de produits

Télécharger la newsletter  (lire en ligne)