Comment prévenir les hallucinations de l'IA dans la logique API avec la boucle Générer-Valider

Pour prévenir les hallucinations de l'IA dans la programmation d'API, les ingénieurs doivent utiliser une boucle Générer-Valider : génération d'IA bornée, vérifications de syntaxe et de structure conformes aux attentes de la norme IEC 61131-3, et tests dynamiques face au comportement simulé de l'équipement. Dans OLLA Lab, cela signifie que les suggestions de l'IA sont examinées dans un environnement de langage à contacts (Ladder) basé sur le Web, puis testées par rapport à la logique du scénario, aux états des E/S et au comportement du jumeau numérique avant toute décision de déploiement en conditions réelles.

L'IA n'échoue pas en automatisation industrielle parce qu'elle est « mauvaise en code ». Elle échoue parce que la logique API n'est pas seulement du code ; c'est un comportement de contrôle déterministe lié à des équipements physiques, à la synchronisation des cycles de balayage et aux conséquences des défaillances.

Cette distinction est importante. Un barreau de langage à contacts peut sembler plausible tout en étant opérationnellement erroné.

Lors d'un benchmark interne chez Ampergon Vallis, la génération de langage à contacts assistée par IA sans contrainte a produit des défauts de contrôle critiques dans 42 % des tâches complexes de séquençage de contrôle moteur. Cela inclut des doubles affectations destructrices de bits, une gestion invalide des permissifs et une ambiguïté dans les états de séquence. Méthodologie : 31 tâches de génération bornée impliquant des modèles de démarrage/arrêt moteur, d'auto-maintien, de marche en tête/suiveur et de réinitialisation de défaut ; le comparateur de référence était le comportement de contrôle attendu examiné par des ingénieurs dans les spécifications de scénario ; fenêtre temporelle janvier-mars 2026. Cette mesure soutient un point précis : il est dangereux de faire confiance à une génération sans restriction sans validation. Elle ne soutient pas une affirmation générale sur tous les outils d'IA, toutes les tâches API ou tous les fournisseurs.

La réponse pratique n'est pas de « ne jamais utiliser l'IA ». C'est de forcer l'IA à intégrer un flux de travail de validation. En termes industriels, cela signifie des garde-fous syntaxiques, un contexte de scénario et une simulation dynamique avant que quoi que ce soit n'approche les E/S physiques. L'optimisme n'est pas une philosophie de contrôle.

Les grands modèles de langage (LLM) hallucinent dans la logique Ladder parce qu'ils génèrent des modèles statistiquement probables, alors que les API exécutent une logique déterministe sous des contraintes strictes de cycle de balayage et d'état.

Un LLM prédit quelle séquence d'instructions semble plausible à partir des données d'entraînement. Un API ne se soucie pas de ce qui semble plausible. Il évalue la logique dans un ordre d'exécution défini, avec de vraies étiquettes (tags), un vrai timing et de vraies conséquences. C'est là que réside le décalage fondamental.

La norme IEC 61131-3 définit des langages de programmation API et des attentes structurelles standardisés, mais elle ne sauve pas un modèle d'une mauvaise compréhension du comportement de l'installation, des limites des dialectes des fournisseurs ou de l'intention de la séquence. Un barreau généré peut être syntaxiquement familier et violer tout de même la philosophie de contrôle. La syntaxe n'est pas la déployabilité.

Défaillances logiques courantes de l'IA dans le travail API

- Ignorance du cycle de balayage : Le modèle suppose un modèle d'événement de type logiciel au lieu d'une exécution cyclique. Cela apparaît souvent sous forme de conditions de concurrence, de verrouillage inapproprié ou d'un comportement de sortie dépendant d'un ordre d'exécution que l'API ne fournit pas réellement.

- Mélange de dialectes : Le modèle mélange les styles d'instructions, les conventions d'adressage ou la sémantique des fonctions entre les fournisseurs. Rockwell, Siemens, les environnements dérivés de Codesys et d'autres ne sont pas interchangeables simplement parce que le barreau « semble correct ».

- Cécité physique : Le modèle ne peut pas intrinsèquement raisonner sur le temps de déplacement d'une vanne, la décélération d'une pompe, le battement d'un capteur, le rebond de contact ou l'hystérésis d'un actionneur, à moins que ces contraintes ne soient explicitement modélisées et testées.

- E/S ou étiquettes inventées : Le modèle crée des adresses, des verrouillages ou des bits d'état qui n'existent pas dans le récit de contrôle. C'est courant lorsque les invites (prompts) sont vagues et que le système est autorisé à improviser.

- Omission des chemins de défaillance : Le modèle gère le chemin nominal et néglige les déclenchements, les réinitialisations, les retours de preuve, le comportement de temporisation ou les conditions de redémarrage. Les installations sont impitoyables envers une logique qui ne fonctionne que lorsque tout va bien.

Pourquoi l'exécution déterministe change la norme de preuve

La logique de contrôle déterministe doit être prouvée par un comportement observable, et non acceptée par une confiance stylistique.

En automatisation industrielle, « correct » signifie que la séquence se comporte comme prévu dans les états normaux, anormaux, de démarrage, d'arrêt et de récupération. Cette preuve nécessite plus qu'une simple compilation. Elle nécessite une observation de l'état dans le temps.

C'est aussi pourquoi la génération d'IA sans restriction ne satisfait pas aux attentes de traçabilité et de vérification associées au travail de sécurité fonctionnelle selon des normes telles que l'IEC 61508. Les obligations du cycle de vie de sécurité exigent une spécification, une vérification et des preuves documentées. Un paragraphe confiant provenant d'un modèle n'est pas une preuve. C'est, au mieux, un brouillon.

La boucle Générer-Valider est un flux de travail d'ingénierie borné dans lequel l'IA peut proposer une logique de contrôle, mais où la logique n'est acceptée qu'après des contrôles structurels et une validation dynamique par rapport au comportement attendu de la machine.

Ce n'est pas une préférence philosophique. C'est une méthode de confinement des risques de contrôle.

En pratique, la boucle sépare trois choses qui sont souvent confondues par négligence :

• la génération de brouillon,
• l'examen déterministe,
• et la validation du comportement.

Cette séparation est saine. Tout comme le fait de ne pas laisser un modèle probabiliste prétendre qu'il est un ingénieur de mise en service.

L'architecture de validation en 3 étapes

1. Génération contextuelle L'IA est contrainte par une philosophie de contrôle définie, une carte d'E/S, un dictionnaire d'étiquettes, un objectif de séquence et un contexte de danger. Si ces entrées sont manquantes, le modèle comble les lacunes par probabilité. La probabilité est utile dans le langage ; elle est moins charmante dans un démarreur de moteur.
2. Garde-fous de syntaxe et de structure La sortie est vérifiée pour la conformité linguistique, la compatibilité des instructions, la validité des étiquettes et les défauts structurels tels que des affectations contradictoires, des verrouillages ambigus ou des transitions de séquence invalides. L'IEC 61131-3 est pertinente ici en tant que cadre linguistique, bien que les détails d'implémentation spécifiques au fournisseur comptent toujours.
3. Simulation dynamique La logique est exécutée par rapport à un processus ou un modèle de machine simulé afin que l'ingénieur puisse observer les transitions d'E/S, le comportement temporel, les conditions d'alarme, les verrouillages et les réponses aux défaillances au fil du temps. C'est le moment où « semble correct » devient « se comporte correctement », ou échoue en essayant.

Ce que signifie « Simulation-Ready » opérationnellement

Un ingénieur « Simulation-Ready » n'est pas simplement quelqu'un qui sait écrire une syntaxe Ladder. Un ingénieur « Simulation-Ready » peut prouver, observer, diagnostiquer et renforcer la logique de contrôle face à un comportement de processus réaliste avant qu'elle n'atteigne un processus réel.

Cette définition est comportementale, pas aspirationnelle.

En termes pratiques, le travail « Simulation-Ready » comprend :

• définir à quoi ressemble un comportement de séquence correct,
• tracer l'état des étiquettes par rapport à l'état de l'équipement,
• injecter des défaillances et des conditions anormales,
• réviser la logique après une défaillance observée,
• et documenter pourquoi le comportement révisé est plus robuste.

C'est là qu'OLLA Lab devient opérationnellement utile. Il fournit un environnement basé sur le Web pour construire une logique Ladder, exécuter une simulation, inspecter les variables et les E/S, et comparer l'état du Ladder au comportement du scénario dans un cadre contenu. C'est un environnement de répétition pour les tâches de validation, pas un raccourci pour éviter l'expérience sur site.

OLLA Lab positionne l'assistance par IA comme une couche de coaching et de suggestion bornée à l'intérieur d'un flux de travail de simulation défini, et non comme une autorité autonome sur la conception du contrôle.

Cette distinction est importante car la génération sans restriction est exactement là où les hallucinations prospèrent.

Au sein d'OLLA Lab, l'assistant GeniAI est destiné à soutenir l'intégration, l'explication, les suggestions correctives et l'assistance à la logique Ladder dans un environnement structuré qui contient déjà le cadrage du scénario, la visibilité des étiquettes et des outils de simulation. La valeur pratique n'est pas que GeniAI « écrit du code parfait ». Il ne le fait pas. La valeur réside dans le fait que les suggestions peuvent être examinées par rapport aux conditions connues du scénario au lieu d'être acceptées comme du texte flottant.

Ce que font les garde-fous en pratique

Dans un flux de travail borné OLLA Lab, les suggestions de l'IA peuvent être contraintes par :

Par exemple, un scénario de contrôle moteur, de séquençage de pompe, de CVC ou de skid de processus définit ce que la logique est censée accomplir.

• Des objectifs spécifiques au scénario

Les entrées, sorties, valeurs analogiques et étiquettes d'état sont visibles et liées au scénario plutôt qu'inventées à la demande.

• Des mappages d'E/S connus

L'ingénieur travaille à partir de la signification explicite des étiquettes, des verrouillages, des permissifs et du comportement de séquence attendu.

• Des dictionnaires d'étiquettes et une philosophie de contrôle

Les scénarios peuvent inclure des attentes d'état anormal telles que les chaînes d'arrêt d'urgence, les retours de preuve, la logique de temporisation, les seuils d'alarme et le comportement de réinitialisation.

• Des notes sur les dangers et la mise en service

La logique suggérée peut être exécutée, mise en pause, basculée et observée plutôt qu'admirée à une distance de sécurité.

• Le mode simulation et l'inspection des variables

C'est une utilisation plus étroite et plus crédible de l'IA. Le modèle est utile lorsqu'il est forcé d'opérer dans les mêmes contraintes qu'un ingénieur junior serait censé respecter.

### Un exemple compact : permissifs inventés versus génération bornée

Supposons qu'on demande à une IA d'« écrire une séquence de démarrage de pompe avec gestion des défauts ». Dans un environnement sans restriction, elle peut inventer un permissif tel que `PUMP_READY_FB`, supposer un chemin de réinitialisation et créer un bit de temporisation qui n'existe pas dans la base de conception.

Dans un scénario OLLA Lab borné, l'ingénieur peut comparer cette suggestion avec :

• les étiquettes réellement disponibles,
• l'objectif de séquence documenté,
• le retour de preuve attendu,
• et la réponse simulée de l'équipement.

La correction est souvent simple. Les conséquences de ne pas la corriger ne le sont pas.

Les ingénieurs testent la logique générée par IA contre des jumeaux numériques en exécutant la séquence de contrôle proposée en simulation, en observant les changements d'état au fil du temps et en comparant le comportement du Ladder au comportement attendu de la machine ou du processus dans des conditions normales et anormales.

Un jumeau numérique n'est pas une enveloppe 3D décorative. Dans ce contexte, c'est une couche de simulation dynamique utilisée pour tester si la logique de contrôle survit au contact avec la réalité du processus.

Cette définition opérationnelle est importante car « jumeau numérique » est souvent utilisé comme vocabulaire de prestige. Ici, cela signifie quelque chose d'observable : la logique pilote un système modélisé, et le système modélisé expose si la logique est réellement valide.

Ce qu'il faut observer pendant la validation

Lors de la validation d'une logique assistée par IA dans OLLA Lab, les ingénieurs doivent inspecter :

La sortie ne s'active-t-elle que lorsque les permissifs sont réellement satisfaits ?

• La causalité entrée-sortie

Les temporisateurs, les transitions et les réinitialisations se comportent-ils correctement au fil des cycles de balayage et des changements d'état ?

• Le timing de la séquence

La logique confirme-t-elle l'état de l'équipement, ou se contente-t-elle de le supposer ?

• Le comportement du retour de preuve

Les conditions anormales sont-elles verrouillées, annoncées et réinitialisées de manière contrôlée ?

• La gestion des alarmes et des déclenchements

Si l'IA suggère des comparateurs, des seuils analogiques ou un comportement PID, ces réponses restent-elles stables sous des valeurs de processus changeantes ?

• La réponse analogique et PID

Après une défaillance, le système revient-il à un état sûr et prévu, ou redémarre-t-il dans la confusion ?

• La logique de récupération

Utilisation du panneau des variables pour tracer la causalité

Le panneau des variables dans OLLA Lab est utile car il transforme la logique Ladder en un modèle d'état observable.

Au lieu de demander seulement si un barreau est vrai, l'ingénieur peut inspecter :

• les valeurs des étiquettes,
• les transitions d'entrée,
• les états de sortie,
• les valeurs analogiques,
• les variables liées au PID,
• et le comportement du scénario au fur et à mesure que la simulation s'exécute.

Cette visibilité est essentielle pour déboguer la logique générée par IA. La plupart des hallucinations ne deviennent évidentes que lorsque la séquence est forcée de s'expliquer au fil du temps.

Tester les conditions anormales, pas seulement le comportement nominal

La logique générée par IA doit être testée sous injection de défaillances, pas seulement dans des conditions de démarrage idéales.

Dans OLLA Lab, cela signifie utiliser les commandes de simulation et les changements d'état du scénario pour provoquer la logique :

• supprimer un permissif,
• retarder un retour de preuve,
• forcer l'état d'un capteur,
• faire varier une entrée analogique,
• ou créer une condition de redémarrage après un déclenchement.

Si la séquence s'effondre sous une condition anormale modeste, le problème n'est pas que le simulateur est dur. Le simulateur est poli au nom de l'installation.

Une erreur de logique Ladder hallucinée par l'IA semble souvent structurellement familière mais contient une logique d'état contradictoire qu'un examen déterministe rejetterait.

Un exemple courant est le problème de la double bobine ou de l'affectation contradictoire, où la même sortie ou le même bit de mémoire est piloté à plusieurs endroits sans stratégie de séquençage contrôlée.

### Exemple : commande moteur contradictoire versus logique d'auto-maintien validée

Modèle halluciné par l'IA : affectations contradictoires

Langage : Schéma à contacts (Ladder)

Barreau 1 : | START_PB STOP_PB OL_OK MOTOR_RUN | |----] [-------]/[------] [--------------------( )-----|

Barreau 2 : | FAULT_RESET MOTOR_RUN | |----] [----------------------------------------( )-----|

Pourquoi cela échoue : La même sortie est affectée dans plusieurs barreaux avec des intentions différentes. Selon l'ordre de balayage et la logique environnante, le deuxième barreau peut écraser l'état du premier. Le résultat est un comportement ambigu, surtout lors des conditions de réinitialisation et de redémarrage.

Modèle validé : auto-maintien explicite avec chemin de réinitialisation contrôlé

Langage : Schéma à contacts (Ladder)

Barreau 1 : | STOP_PB OL_OK FAULT_CLEAR START_PB MOTOR_RUN | |----]/[------] [------] [----------] [----------------------( )-----| | MOTOR_RUN | |----------------------------] [----------------------------------|

Barreau 2 : | FAULT_ACTIVE MOTOR_RUN_LATCH_RST | |----] [----------------------------------------------------( )-------------|

Pourquoi c'est mieux : La commande de marche est maintenue par un chemin d'auto-maintien explicite, tandis que la gestion des défauts est séparée dans une stratégie de réinitialisation ou d'inhibition définie. L'implémentation exacte variera selon la plateforme et la philosophie de contrôle, mais le principe est stable : une intention d'état, un chemin contrôlé.

Le point n'est pas que chaque double affectation est toujours invalide dans chaque environnement fournisseur. Le point est que l'IA introduit souvent une logique d'état contradictoire sans comprendre les conséquences du balayage. C'est la partie que les ingénieurs doivent détecter.

Les ingénieurs doivent documenter un ensemble compact de preuves d'ingénierie montrant que la logique a été spécifiée, testée, a échoué là où c'était approprié, révisée et re-testée par rapport à un comportement observable.

Une galerie de captures d'écran ne suffit pas. Elle prouve seulement qu'un écran a existé.

Utilisez cette structure :

Spécifiez ce que signifie un comportement correct en termes observables : conditions de démarrage, permissifs, transitions de séquence, alarmes, déclenchements et comportement de récupération.

Documentez la condition anormale introduite : retour retardé, permissif échoué, excursion analogique, événement d'arrêt d'urgence, battement ou temporisation.

1. Description du système Définissez la cellule de processus, la machine ou le scénario. Indiquez l'équipement, l'objectif de la séquence et les E/S pertinentes.
2. Définition opérationnelle de « correct »
3. Logique Ladder et état de l'équipement simulé Incluez l'implémentation Ladder et l'état correspondant de la machine ou du processus simulé pendant l'exécution.
4. Le cas de défaillance injectée
5. La révision effectuée Montrez exactement ce qui a changé dans la logique et pourquoi.
6. Leçons apprises Indiquez ce que le test a révélé sur la conception de la séquence, la gestion des défaillances, les hypothèses de timing ou les défauts générés par l'IA.

Ce style de documentation est plus précieux que des visuels polis car il démontre le jugement d'ingénierie. Les employeurs et les examinateurs n'ont pas besoin d'une autre capture d'écran d'un barreau. Ils ont besoin de la preuve que le barreau a survécu à l'interrogatoire.

La boucle Générer-Valider est soutenue par des distinctions établies dans le contrôle industriel, la sécurité fonctionnelle et la validation basée sur la simulation plutôt que par une norme unique « solution miracle ».

Le soutien pertinent provient de plusieurs couches :

Normes et fondements techniques

• IEC 61131-3 soutient le besoin de discipline linguistique dans la programmation API, y compris des modèles de programmation définis et des attentes d'implémentation à travers les contrôleurs industriels.
• IEC 61508 soutient le besoin de traçabilité, de vérification et de rigueur du cycle de vie dans les systèmes électriques, électroniques et programmables liés à la sécurité.
• La littérature sur les conseils et pratiques de sécurité d'exida renforce constamment le fait que la vérification, l'indépendance de l'examen et la validation documentée comptent plus que la fluidité apparente du codage.
• La littérature sur les jumeaux numériques et la simulation en ingénierie industrielle, systèmes de processus et systèmes cyber-physiques soutient l'utilisation de modèles dynamiques pour tester le comportement de contrôle avant le déploiement.
• La littérature sur les facteurs humains et la formation immersive soutient la simulation comme un environnement utile pour répéter des tâches opérationnelles complexes, surtout là où la pratique sur système réel est coûteuse, dangereuse ou opérationnellement contrainte.

Ce que cela justifie et ne justifie pas

Cet ensemble de preuves justifie l'utilisation de la simulation et de l'assistance par IA bornée comme un flux de travail de réduction des risques pour la validation du contrôle.

Il ne justifie pas de prétendre que :

• la logique API générée par IA est intrinsèquement sûre,
• la simulation remplace la mise en service,
• les jumeaux numériques garantissent le succès sur le terrain,
• ou qu'un environnement de formation confère une certification, une compétence sur site ou une conformité formelle par association.

Ce sont des affirmations différentes. Certaines d'entre elles sont des erreurs coûteuses.

Les ingénieurs doivent utiliser OLLA Lab comme un environnement de répétition et de validation pour les tâches de contrôle à haut risque qu'il est difficile de pratiquer en toute sécurité sur des équipements réels.

C'est le positionnement produit crédible.

OLLA Lab combine un éditeur Ladder basé sur navigateur, un mode simulation, une visibilité des variables et des E/S, des exercices basés sur des scénarios, une interaction machine de type jumeau numérique, des outils analogiques et PID, et un support de coaching par IA dans un seul environnement. L'avantage pratique est que les ingénieurs peuvent passer de l'écriture de la logique à l'observation des conséquences.

Utilisé correctement, OLLA Lab soutient des travaux tels que :

• valider les séquences de moteurs et de pompes,
• tester les verrouillages et les permissifs,
• observer le comportement des alarmes et des déclenchements,
• tracer la réponse analogique et PID,
• comparer l'état du Ladder à l'état de l'équipement simulé,
• et réviser la logique après injection de défaillances.

Ceci est particulièrement utile pour les ingénieurs en début de carrière et les programmes de formation, car les employeurs ne peuvent pas confier à moindre coût les risques de mise en service réelle à des novices. Les installations ne sont pas des stages pour une logique non validée.

Ce pour quoi OLLA Lab ne devrait pas être positionné :

• un substitut à la mise en service sur site,
• une garantie d'employabilité,
• un parcours de certification de sécurité,
• ou la preuve que le code généré est prêt pour la production par défaut.

C'est un environnement borné pour apprendre et valider le comportement d'ingénierie avant l'exposition sur le terrain. C'est déjà un cas d'utilisation sérieux.

Les hallucinations de l'IA dans la logique API sont mieux traitées comme un problème de risque de contrôle, et non comme un inconvénient de rédaction d'invites (prompts).

Le remède est la boucle Générer-Valider : contraindre le contexte de génération, faire respecter la discipline structurelle et tester le comportement par rapport à la réalité du processus simulé. Dans ce flux de travail, l'IA peut être utile. En dehors, l'IA n'est souvent qu'une conjecture fluide portant un casque de chantier.

Pour l'automatisation industrielle, la norme est simple : si la logique ne peut pas être observée, testée en défaillance, révisée et re-prouvée avant le déploiement, elle n'est pas prête. L'installation finira par effectuer l'examen de toute façon, généralement avec moins de patience.

- NIST AI Risk Management Framework (AI RMF 1.0) - Aperçu de la norme IEC 61131-3 (PLCopen) - Page de la norme ISO/IEC 42001 sur les systèmes de gestion de l'IA - Aperçu de la sécurité fonctionnelle IEC 61508 - ACM Digital Library pour la littérature sur la vérification logicielle