Industrie 5.0 et supervision humaine (Human-in-the-Loop) pour la validation de la logique API par IA

Dans l'industrie 5.0, la supervision humaine (Human-in-the-Loop ou HITL) est l'acte d'ingénierie consistant à vérifier que la logique de contrôle générée par IA se comporte de manière sûre vis-à-vis des contraintes physiques des équipements avant son déploiement. OLLA Lab soutient cette validation en permettant aux ingénieurs de tester la logique à contacts (ladder) en simulation, d'inspecter le comportement des E/S, d'injecter des pannes et de comparer l'intention du code avec le comportement de la machine en 3D ou en VR.

L'assistance par IA dans l'automatisation n'est pas entravée par un manque de génération de syntaxe. Elle est limitée par le fait que le contrôle industriel est physique, déterministe et sensible aux défaillances. Un barreau de logique ladder peut sembler plausible tout en commandant une machine vers un état dangereux.

Cette distinction est importante car l'industrie 5.0 ne consiste pas à supprimer l'humain de la production. Le cadre défini par la Commission européenne replace le travailleur humain au centre, avec la résilience, la collaboration et la complémentarité homme-machine comme principes fondamentaux plutôt que comme des éléments de langage décoratifs.

Un récent test de résistance interne chez Ampergon Vallis renforce ce point : sur 500 séquences de contrôle moteur générées par IA, les sorties brutes des LLM ont systématiquement produit une logique nécessitant une correction humaine avant une validation sûre en simulation, avec des erreurs fréquentes concernant l'anti-rebond, les permissifs et les hypothèses de sécurité (fail-safe). Méthodologie : 500 générations de requêtes-réponses pour des tâches de démarrage/arrêt moteur et de verrouillage, comparées à une logique de référence rédigée par des instructeurs, évaluées sur une période de test interne de 30 jours. Cette mesure soutient une affirmation limitée : une sortie d'IA non révisée n'est pas prête pour le déploiement en matière de validation de contrôle. Cela ne signifie pas que l'IA est inutile dans l'automatisation. Elle est utile. Mais elle ne constitue pas un argument de sécurité.

L'industrie 4.0 mettait l'accent sur la connectivité, l'automatisation et l'intégration cyber-physique. L'industrie 5.0 ajoute un centre de gravité différent : l'opérateur humain, l'ingénieur et le décideur restent essentiels à une production résiliente.

Il ne s'agit pas d'un ajustement marketing. C'est une distinction systémique. L'industrie 4.0 était souvent résumée par la connectivité machine-machine, les cellules autonomes et l'idéal de « l'usine noire ». L'industrie 5.0, en particulier dans le contexte politique européen, s'oriente vers l'humano-centrisme, la durabilité et la résilience (Commission européenne, 2021).

Pour les ingénieurs en contrôle-commande, l'implication pratique est directe. L'ingénieur n'est plus seulement celui qui écrit la logique. Il devient celui qui valide si la logique générée est physiquement cohérente, opérationnellement sûre et récupérable dans des conditions anormales. La syntaxe est bon marché. Le jugement déterministe ne l'est pas.

C'est ici que le terme Human-in-the-Loop (supervision humaine) nécessite de la rigueur. Dans cet article, HITL ne signifie pas « une personne a jeté un coup d'œil au résultat ». Cela signifie qu'un ingénieur a :

• examiné la séquence de contrôle logiquement,
• vérifié celle-ci par rapport au comportement de l'équipement,
• vérifié la réponse de sécurité (fail-safe) dans des conditions anormales,
• et confirmé que l'état de la machine et l'état du programme ladder restent alignés.

Tout le reste n'est que théâtre opérationnel.

Les LLM génèrent du texte probable. Les API exécutent une logique déterministe par rapport à des E/S réelles et aux contraintes du cycle de balayage (scan-cycle). Ce décalage est le problème central.

Un modèle de langage prédit le jeton (token) suivant à partir de modèles présents dans les données d'entraînement. Il n'exécute pas de cycle machine, ne contrôle pas de périphérique de terrain et ne raisonne pas intrinsèquement à partir de l'inertie des actionneurs, des conventions de câblage ou du temps mort des processus. La programmation de contrôle selon la norme CEI 61131-3 vit dans un monde d'exécution ordonnée, d'état explicite et de causalité observable. Le travail de sécurité fonctionnelle selon des normes telles que la CEI 61508 est encore plus strict.

Le résultat est prévisible. La logique ladder générée par IA semble souvent structurellement compétente tout en restant opérationnellement incomplète. Elle peut produire des barreaux. Elle ne peut pas garantir un comportement machine sûr. Ce sont des accomplissements différents.

Les 3 risques physiques que le code IA ignore couramment

#### 1. L'inertie mécanique

La logique IA suppose souvent que la désactivation d'un bit de sortie signifie que la machine s'est arrêtée. Les systèmes physiques sont moins obéissants.

Les convoyeurs continuent sur leur lancée. Les équipements rotatifs possèdent une inertie. Les axes pneumatiques dépassent leur cible. Une tête de préhension robotisée ne s'arrête pas instantanément simplement parce que le barreau est devenu faux. Si les permissifs en aval supposent un arrêt instantané, les collisions et les blocages deviennent faciles à écrire et coûteux à expliquer.

#### 2. Hystérésis des capteurs et bruit

La sortie de l'IA spécifie fréquemment mal l'anti-rebond, la zone morte et la validation du signal.

Les capteurs réels « broutent ». Les détecteurs de niveau oscillent près du seuil. Les cellules photoélectriques scintillent en fonction de la géométrie du produit. Les valeurs analogiques dérivent, saturent et présentent des pics. Une séquence de contrôle qui réagit à chaque transition comme si l'instrument était un démonstrateur de théorèmes produira au mieux des déclenchements intempestifs et au pire un séquençage instable.

#### 3. Câblage de terrain normalement fermé et conventions de sécurité

Les modèles d'IA gèrent régulièrement mal la différence entre la vérité logique et l'interprétation de l'état de sécurité sur le terrain.

Un circuit d'arrêt normalement fermé, une chaîne de permissifs saine ou un dispositif de sécurité par manque de tension ne correspondent pas simplement aux hypothèses simplistes du type « 1 signifie actif ». Il s'agit d'un mode de défaillance courant car le modèle voit des symboles ; l'usine voit une philosophie de câblage.

Le déterminisme est non négociable car le contrôle industriel est jugé sur un comportement reproductible dans des conditions définies, et non sur la ressemblance du code généré avec des exemples antérieurs.

Un cycle d'API s'exécute dans une séquence connue. Les entrées sont lues, la logique est résolue, les sorties sont mises à jour et le comportement temporel est évalué dans un cycle reproductible. Les fonctions liées à la sécurité exigent une discipline encore plus stricte concernant les états définis, la couverture de diagnostic et la réponse aux pannes. La norme CEI 61508 existe précisément parce que « probablement correct » n'est pas une catégorie de conception acceptable pour les systèmes dangereux.

Cela ne signifie pas que l'IA n'a pas sa place dans le travail sur API. Cela signifie que l'IA doit intervenir en amont de la validation, et non en aval. La génération de brouillons peut être utile. Le veto déterministe doit rester sous contrôle humain.

Ce contraste mérite d'être mis en évidence : génération de brouillon contre veto déterministe. L'un est une assistance. L'autre est une responsabilité.

La supervision humaine (Human-in-the-Loop) signifie qu'un ingénieur vérifie que la logique générée commande le système physique en toute sécurité, prend en compte le comportement réel de l'équipement et se met en sécurité dans des conditions anormales avant le déploiement.

Cette définition est intentionnellement étroite. Elle est observable. Elle peut être auditée. Elle évite le flou habituel entourant ce terme.

En termes opérationnels, la validation HITL comprend :

• la vérification que les permissifs, les déclenchements et les verrouillages correspondent à la philosophie de contrôle,
• la vérification que le comportement de démarrage, d'arrêt et de réinitialisation des pannes est déterministe,
• la confirmation que les hypothèses sur les dispositifs de terrain correspondent au câblage réel et aux modes de défaillance,
• le test des états anormaux tels que la perte de capteur, les retours d'information bloqués et les mouvements retardés,
• et l'examen de la capacité de la machine à atteindre un état sûr lorsque cela est attendu.

Une revue de code rapide ne suffit pas. Un fil de discussion ne suffit pas. Si l'ingénieur n'a pas observé le comportement par rapport à un modèle de système simulé ou physique, la boucle n'est pas fermée.

Un ingénieur Simulation-Ready (prêt pour la simulation) est celui qui peut prouver, observer, diagnostiquer et durcir la logique de contrôle face à un comportement de processus réaliste avant que cette logique n'atteigne un processus réel.

Ce n'est pas un synonyme de « connaît la syntaxe ladder ». C'est un seuil plus strict.

Un ingénieur Simulation-Ready peut :

• mapper les tags et les E/S vers un modèle de machine ou de processus,
• définir à quoi ressemble un comportement correct avant le début des tests,
• observer la divergence entre l'état du ladder et l'état de l'équipement,
• injecter des pannes délibérément plutôt que d'attendre qu'elles surviennent par accident,
• réviser la logique après une défaillance,
• et documenter pourquoi la révision réduit le risque.

C'est la différence entre la maîtrise théorique et l'utilité en mise en service.

Les ingénieurs pratiquent le HITL en toute sécurité en validant la logique générée ou rédigée dans un environnement de simulation à risque maîtrisé avant tout déploiement réel.

C'est là qu'OLLA Lab devient opérationnellement utile. OLLA Lab est un environnement de formation à la logique ladder et au jumeau numérique basé sur le Web qui permet aux utilisateurs de construire une logique ladder dans le navigateur, d'exécuter une simulation, d'inspecter les E/S et les variables, de travailler sur des scénarios industriels réalistes et de comparer le comportement de la logique avec des modèles d'équipement 3D ou VR. En termes limités, c'est un environnement de répétition pour la validation et la pratique du dépannage.

Cela est important car la plupart des ingénieurs juniors ne peuvent pas apprendre ces leçons en toute sécurité sur des équipements sous tension, des convoyeurs actifs, des skids de pompage ou des cellules robotisées. Le coût de l'apprentissage sur du matériel réel est souvent un équipement endommagé, une perte de temps ou une perturbation opérationnelle évitable.

La boucle Génération-Validation dans OLLA Lab

Un flux de travail HITL pratique dans OLLA Lab peut suivre quatre étapes :

#### Étape 1 : Générer une base de référence

Utilisez l'éditeur ladder et, le cas échéant, GeniAI pour rédiger une logique ladder de base pour un scénario défini tel qu'un palettiseur, un convoyeur, une station de pompage ou une séquence CVC.

L'objectif ici n'est pas l'acceptation aveugle. L'objectif est d'accélérer la création du premier brouillon afin que le vrai travail — la validation — puisse commencer.

#### Étape 2 : Lier la logique à l'équipement simulé

Mappez les tags, les entrées, les sorties et les variables pertinentes vers le modèle de scénario dans l'environnement de simulation d'OLLA Lab, y compris les vues 3D ou WebXR si disponibles.

C'est le moment où la logique abstraite commence à rencontrer les conséquences physiques. De nombreuses erreurs restent invisibles jusqu'à ce qu'une sortie soit liée à un mouvement, un délai ou une dépendance de séquence.

#### Étape 3 : Injecter des pannes et observer le comportement de défaillance

Utilisez le panneau des variables pour forcer des conditions anormales telles que :

• des transitions de capteurs défaillantes,
• un retour d'information retardé,
• un comportement bruyant des entrées discrètes,
• des excursions analogiques,
• ou des états de permissifs incorrects.

Observez ensuite si la séquence s'arrête en toute sécurité, se bloque en toute sécurité ou se poursuit de manière incorrecte. Une bonne validation ne consiste pas à prouver le chemin nominal.

#### Étape 4 : Appliquer la correction humaine

Révisez la logique ladder dans l'éditeur pour ajouter des mesures de sécurité déterministes telles que :

• des temporisateurs anti-rebond,
• des corrections de maintien (seal-in),
• une logique d'arrêt de sécurité,
• des vérifications de preuve de mouvement,
• des alarmes de temporisation,
• et des verrouillages explicites.

La contribution humaine n'est pas une édition cosmétique. C'est l'insertion d'un jugement d'ingénierie là où le brouillon généré manquait de réalisme physique.

Une séquence de convoyeur ou de palettiseur est un exemple utile car elle expose rapidement les erreurs de synchronisation, de mouvement et de verrouillage.

Supposons qu'une séquence générée par IA démarre un convoyeur lorsqu'un produit est détecté en amont et l'arrête lorsque la zone en aval est occupée. Sur le papier, la logique peut sembler cohérente. En simulation, le défaut apparaît : le capteur en aval « broute », le convoyeur continue sur sa lancée après l'arrêt, et la séquence se réactive avant que la zone ne soit réellement libérée. Le résultat est un blocage ou une collision dans le modèle 3D.

Un validateur humain détecterait cela en vérifiant trois points :

• si le capteur nécessite un anti-rebond ou une confirmation d'état,
• si le comportement d'arrêt du convoyeur inclut un temps de décélération physique,
• et si la logique de redémarrage nécessite une condition de libération déterministe plutôt qu'un simple bit transitoire.

Un modèle correctif compact inclut souvent une logique de confirmation retardée. Par exemple :

[Langage : Schéma à contacts (Ladder)] // Logique anti-rebond corrigée par l'humain |---[ Capteur_Physique ]-------[ TON : Temporisateur_On_Delay, 50ms ]---| |---[ Temporisateur_On_Delay.DN ]-----( Signal_Valide_Verrouillé )------|

Ce fragment de code n'est pas une solution universelle. Il illustre un point plus large : l'ingénieur ajoute une discipline temporelle et physique que le brouillon généré omet souvent.

La simulation VR et 3D construit un jugement utile car elle permet aux ingénieurs de voir les conséquences physiques d'une mauvaise logique sans payer pour ces leçons sur des équipements réels.

Cette expression — « cicatrices de guerre » — doit être manipulée avec précaution. Elle ne signifie pas théâtralité ou gamification. Elle signifie une exposition répétée aux modèles de défaillance : conditions de concurrence (race conditions), omissions de verrouillage, faux permissifs, mauvaise conception de réinitialisation et comportement de redémarrage dangereux. La conséquence visuelle accélère la compréhension.

Lorsqu'un ingénieur junior voit un convoyeur virtuel se bloquer, un palettiseur entrer en collision ou une séquence de pompe échouer à transiter parce que le retour d'information n'arrive jamais, la leçon devient causale plutôt qu'abstraite. L'état du ladder, l'état des variables et l'état de l'équipement peuvent être comparés directement. C'est exactement le type de modèle mental que le travail de mise en service exige.

La recherche sur la formation technique basée sur la simulation et l'immersion soutient généralement cette direction lorsque l'environnement est lié au réalisme des tâches, au retour d'information et à la pratique répétable plutôt qu'à la nouveauté seule. Le qualificatif important est évident : l'immersion est utile lorsqu'elle améliore l'observation diagnostique. Un casque seul n'est pas une pédagogie.

Les ingénieurs doivent documenter un corpus compact de preuves d'ingénierie, et non une galerie d'interfaces attrayantes.

Un artefact de validation crédible doit inclure exactement six éléments :

1. Description du système Définissez la machine ou le processus contrôlé, l'objectif opérationnel et les principales E/S.
2. Définition opérationnelle du « correct » Indiquez ce qui doit se passer, dans quel ordre, dans quelles conditions, et à quoi ressemble une défaillance sûre.
3. Logique ladder et état de l'équipement simulé Montrez les barreaux pertinents, les tags et la condition de la machine simulée correspondante.
4. Le cas de panne injecté Identifiez la condition anormale introduite, telle que le broutage d'un capteur, la perte de retour d'information, une vanne bloquée ou un dépassement de plage analogique.
5. La révision effectuée Documentez le changement de logique exact, y compris les temporisateurs, les verrouillages, la gestion d'état, les alarmes ou les corrections de permissifs.
6. Leçons apprises Expliquez ce que le brouillon original a manqué et pourquoi la révision reflète mieux la réalité physique et opérationnelle.

Cette structure est bien plus convaincante que des captures d'écran avec des légendes du type « labo palettiseur terminé ». L'achèvement n'est pas une preuve. Le diagnostic, lui, l'est.

L'IA doit servir d'assistant pour la rédaction, l'explication et le support à l'itération, tandis que l'ingénieur reste responsable de la validation, du raisonnement sur les pannes et du jugement de déploiement.

Cela s'aligne plus proprement avec le modèle de l'industrie 5.0 que n'importe quelle position extrême. L'ingénieur n'est pas remplacé par un générateur de texte, et le générateur de texte n'est pas hors sujet. Le rôle utile est une assistance limitée au sein d'un flux de travail de validation contrôlé par l'humain.

Dans OLLA Lab, cela signifie que GeniAI peut aider à réduire les frictions lors de l'intégration, expliquer les concepts ladder et soutenir la création de brouillons. Le mode simulation de la plateforme, le panneau des variables, la structure des scénarios et les vues de jumeau numérique fournissent ensuite l'environnement où ces brouillons sont testés, remis en question et corrigés. De manière productive, ce n'est pas « l'IA écrit l'usine ». C'est « l'IA rédige ; l'ingénieur vérifie ».

OLLA Lab s'intègre comme un environnement de répétition limité pour les tâches de mise en service à haut risque qui sont trop coûteuses, trop dangereuses ou trop perturbatrices sur le plan opérationnel pour être pratiquées d'abord sur des équipements réels.

Ses fonctions pertinentes dans ce flux de travail incluent :

• la construction de logique ladder dans un éditeur basé sur navigateur,
• la simulation de l'exécution logique sans matériel,
• la surveillance des tags, des E/S, des valeurs analogiques et des variables liées au PID,
• la sélection de scénarios industriels réalistes,
• la comparaison du comportement de la logique avec des vues d'équipement 3D ou VR,
• et la révision de la logique après des pannes observées.

Ce positionnement est important. OLLA Lab n'est pas un proxy de certification, pas une revendication SIL, et pas un substitut à la mise en service spécifique au site selon des procédures formelles. C'est un environnement contrôlé pour apprendre et répéter les comportements de validation que les projets réels exigent.

L'industrie 5.0 ne réduit pas le besoin d'ingénieurs en contrôle-commande. Elle renforce le besoin d'ingénieurs capables de valider une logique assistée par IA face à la réalité physique, à l'exécution déterministe et au comportement de sécurité.

La distinction centrale est simple : l'IA peut générer un texte de contrôle plausible, mais elle ne peut pas assumer la responsabilité du comportement de la machine. La supervision humaine (Human-in-the-Loop) comble cette lacune en vérifiant si la logique fonctionne non seulement syntaxiquement, mais aussi opérationnellement.

Un ingénieur Simulation-Ready n'est donc pas seulement quelqu'un qui sait écrire de la logique ladder. C'est quelqu'un qui peut prouver, observer, diagnostiquer et durcir cette logique avant qu'elle n'atteigne un processus réel. La valeur pratique d'OLLA Lab se situe exactement là : en tant qu'environnement à risque maîtrisé où les ingénieurs peuvent répéter la validation, injecter des pannes, comparer l'état du ladder à l'état de l'équipement et construire le type de jugement que les usines ont rarement le temps d'enseigner en douceur.

- U.S. Bureau of Labor Statistics (BLS) – Occupational Outlook Handbook - Deloitte Insights – 2025 Manufacturing Industry Outlook - The Manufacturing Institute & Deloitte – Talent and workforce research - European Commission – Industry 5.0 - IEC 61131-3 standard overview (IEC) - IEC 61508 functional safety standard overview (IEC) - ISO 10218 industrial robot safety standard overview (ISO) - International Federation of Robotics – World Robotics reports - IFAC-PapersOnLine journal homepage - Sensors journal – industrial digital twin and monitoring research