Comment repérer l'« AI-washing » en usine : une liste de contrôle pour la mise en service virtuelle

L'« AI-washing » dans l'automatisation industrielle se produit lorsque des outils d'analyse ou de génération de code sont commercialisés comme une intelligence de contrôle sans prouver leur comportement déterministe face aux contraintes physiques des procédés. Un test pratique consiste en la mise en service virtuelle : si la logique ne peut être validée par rapport à un modèle numérique réaliste avant le déploiement, la valeur revendiquée de l'IA n'est pas encore une valeur d'ingénierie.

Dans le secteur manufacturier, l'IA est souvent vendue comme si la prédiction et le contrôle étaient une seule et même chose. Ce n'est pas le cas. Un tableau de bord qui identifie des anomalies est utile ; un système capable d'influencer le comportement d'une machine en toute sécurité, tout en respectant les cycles de scrutation, les verrouillages et les contraintes de défaut, relève d'une problématique différente.

Un récent benchmark interne d'Ampergon Vallis a révélé que 68 % des séquences Ladder générées par LLM pour la gestion de pompes omettaient la logique nécessaire pour traiter l'hystérésis mécanique et le comportement de transition stable [Méthodologie : n=50 séquences générées pour des tâches de gestion de pompes en tête/en attente, comparateur de référence = logique prête pour la mise en service révisée par un ingénieur, période = janvier-mars 2026]. Cette mesure soutient un point précis : la logique de contrôle générée par IA et non révisée manque fréquemment de détails essentiels au déploiement. Elle ne soutient pas l'affirmation générale selon laquelle tout travail sur automate programmable (PLC) assisté par IA est dangereux ou de faible valeur.

Cette distinction est cruciale car la mise en service est le moment où les promesses vagues se heurtent à l'acier, à l'eau, à l'inertie et aux conséquences réelles. Le marketing quitte généralement la pièce avant ce stade.

L'« AI-washing » dans l'automatisation industrielle est la pratique consistant à présenter des outils d'analyse ordinaires, de l'automatisation basée sur des règles ou de la génération de code non validée comme s'il s'agissait d'une intelligence industrielle fiable. Dans le domaine des technologies opérationnelles (OT), ce terme est important car les conséquences d'une surestimation des capacités sont physiques, et non purement administratives.

Une définition technique exploitable est plus étroite que la définition commerciale générale :

- L'« AI-washing » est l'étiquetage d'un outil comme étant « piloté par l'IA » alors qu'il lui manque un ou plusieurs des éléments suivants :

• la conscience de l'exécution du contrôle déterministe,
• une interaction traçable avec des E/S réelles ou simulées,
• une validation par rapport au comportement du procédé ou aux contraintes de l'équipement,
• un mode de défaillance délimité et un repli déterministe.

Cette distinction sépare deux catégories souvent confondues lors des achats :

- Intelligence en lecture seule : détection d'anomalies, prévision, tableaux de bord, notation de maintenance, classification des tendances. - Influence de contrôle en lecture/écriture : recommandation de points de consigne, génération de séquences, propositions d'actions de contrôle ou orchestration autonome affectant l'état de la machine.

Les outils en lecture seule peuvent rester précieux. Le problème commence lorsqu'un outil en lecture seule ou vaguement probabiliste est vendu comme s'il pouvait participer en toute sécurité à un contrôle déterministe. Un graphique de tendance ne peut pas exécuter une condition permissive. Un modèle de langage ne devient pas conscient du cycle de scrutation simplement parce qu'une présentation indique « industriel ».

Une correction pratique que les ingénieurs devraient effectuer rapidement

Toute revendication « IA » n'est pas fausse. Beaucoup sont simplement non délimitées. La question n'est pas de savoir si un fournisseur utilise l'apprentissage automatique ; la question est de savoir si la capacité revendiquée a été validée là où le comportement du procédé, le timing et la gestion des défauts importent.

L'« AI-washing » menace la sécurité fonctionnelle lorsque des sorties probabilistes sont autorisées à influencer des systèmes déterministes sans structure de supervision validée. La norme IEC 61508 concerne la sécurité fonctionnelle tout au long du cycle de vie, y compris la spécification, la conception, la vérification, la validation et la gestion des défaillances systématiques. Ce n'est pas un environnement favorable aux revendications vagues d'autonomie.

Le conflit d'ingénierie fondamental est simple :

• Les modèles d'IA sont probabilistes.
• Les automates (PLC) et les fonctions de sécurité instrumentées sont déterministes par conception.

Cela ne rend pas l'IA inutilisable dans les environnements industriels. Cela signifie que toute interaction entre une recommandation probabiliste et une exécution déterministe doit être explicitement délimitée, révisée et architecturée avec un comportement d'état sûr. « Ça fonctionne généralement » n'est pas un argument de sécurité.

Les 3 façons courantes dont l'« AI-washing » contourne la discipline de sécurité

1. Injection asynchrone de points de consigne Un service non déterministe écrit ou recommande des valeurs sans tenir compte de l'ordre d'exécution de l'automate, du timing des tâches ou de l'état du procédé. Même lorsque le chemin d'écriture est indirect, le résultat peut être un comportement de boucle instable ou une corruption de séquence.
2. Inondation d'alarmes et dilution des priorités Les alertes prédictives peuvent ajouter du bruit à la charge de travail de l'opérateur si elles ne sont pas rationalisées par rapport à une véritable philosophie d'alarme. La discipline des alarmes de type ISA-18.2 et EEMUA existe pour une raison. Plus d'alertes ne signifie pas une meilleure conscience. Souvent, c'est l'inverse.
3. Perte de conscience de l'état lors des transitions Les cycles de mise sous tension, la perte de communication, les tags obsolètes et la latence du réseau révèlent si un système comprend réellement l'état de la machine. Un modèle qui perd le contexte lors d'un redémarrage n'est pas « adaptatif ». Il est confus au pire moment possible.

Pourquoi le veto déterministe est important

Un veto déterministe est la limite stricte qui empêche la logique consultative ou générée de violer les contraintes de procédé, les verrouillages ou les enveloppes de fonctionnement sûres. En termes pratiques, cela signifie :

• L'IA peut proposer.
• La logique déterministe doit décider.
• Les fonctions de sécurité restent en dehors de la discrétion de l'IA.

Ce n'est pas être anti-IA. C'est assurer une supervision adulte pour des systèmes équipés de moteurs.

Le moyen le plus rapide d'identifier l'« AI-washing » est de tester si l'intelligence revendiquée survit au contact de la réalité du contrôle. Si un fournisseur ne peut pas répondre clairement à ces cinq questions, la charge de la preuve a été discrètement transférée à votre équipe de mise en service.

Liste de contrôle de diagnostic de l'« AI-washing »

| Critère | Que demander | À quoi ressemble une réponse crédible | Signe d'alerte | |---|---|---|---| | 1. Conscience du cycle de scrutation | L'outil prend-il en compte l'ordre d'exécution de l'automate, le timing de mise à jour et l'état de la séquence ? | Le fournisseur peut expliquer comment les sorties sont évaluées par rapport au comportement de scrutation, au timing des tâches et aux transitions d'état. | « L'IA génère la logique automatiquement » sans discussion sur l'ordre d'exécution. | | 2. Liaison à la physique | La logique a-t-elle été testée par rapport au comportement réaliste de l'équipement (inertie, hystérésis, friction, gravité, retard de fluide) ? | La validation inclut un modèle numérique ou un scénario où la réponse physique peut être observée et les défauts injectés. | La validation se limite à des vérifications de syntaxe, des tests unitaires ou une revue de code statique. | | 3. Repli déterministe | Si le service d'IA échoue, se déconnecte ou produit des absurdités, que se passe-t-il ? | Le système dispose d'un comportement de repli délimité, d'une visibilité pour l'opérateur et d'un état sûr défini. | La récupération dépend de l'improvisation manuelle ou de la disponibilité du cloud. | | 4. Causalité des E/S | L'équipe peut-elle tracer une décision logicielle jusqu'aux changements de tags, aux sorties et à la réponse de l'équipement ? | Il existe une relation de cause à effet observable entre l'état de la logique et l'état simulé ou physique de la machine. | L'outil explique les décisions en prose mais ne peut pas montrer les conséquences au niveau des relais ou des tags. | | 5. Vérifiabilité de la mise en service | La logique générée peut-elle être testée dans des conditions normales, anormales et limites avant la FAT ou la SAT ? | Le flux de travail inclut la simulation, l'injection de défauts, la révision et des critères d'acceptation documentés. | « Nous validons en production avec la supervision de l'opérateur. » Ce n'est pas de la validation ; c'est de l'optimisme avec un casque de chantier. |

Ce que cette liste de contrôle mesure réellement

Cette liste de contrôle ne mesure pas à quel point une démonstration est impressionnante. Elle mesure si un outil peut survivre à un flux de travail de mise en service. C'est le seuil utile, car la mise en service expose l'écart entre la syntaxe générée et le comportement de contrôle déployable.

« Prêt pour la simulation » doit être défini de manière opérationnelle, et non aspirationnelle. Un ingénieur « prêt pour la simulation » peut prouver, observer, diagnostiquer et renforcer la logique de contrôle par rapport au comportement réel du procédé avant qu'il n'atteigne un procédé en direct.

Cette définition concerne le comportement, pas le langage de CV. En pratique, un flux de travail « prêt pour la simulation » inclut la capacité de :

• construire ou réviser la logique Ladder par rapport à un objectif de contrôle clair,
• lier la logique aux E/S observables et aux états de l'équipement,
• tester les séquences normales et les conditions anormales,
• injecter des défauts délibérément,
• comparer le comportement attendu avec la réponse simulée réelle,
• réviser la logique sur la base de preuves,
• documenter ce que signifie « correct » avant le déploiement.

C'est la distinction qui compte : syntaxe contre déployabilité. Beaucoup de gens peuvent dessiner un barreau. Peu peuvent expliquer pourquoi une condition permissive a échoué, dans quel état la machine devrait entrer ensuite, et comment prouver que la révision a corrigé le défaut sans en créer un nouveau.

La preuve d'ingénierie qui démontre réellement la compétence

Si un ingénieur souhaite démontrer une capacité crédible avec une logique de contrôle assistée par IA ou écrite manuellement, l'artefact doit être un ensemble compact de preuves d'ingénierie, et non une galerie de captures d'écran.

Utilisez cette structure :

Énoncez les critères d'acceptation en termes observables : conditions de démarrage, conditions d'arrêt, verrouillages, alarmes, timing, comportement de sécurité.

Documentez la condition anormale introduite : défaillance de capteur, vanne bloquée, entrée bruitée, retour différé.

1. Description du système Définissez la machine ou le procédé, les E/S principales, les états de fonctionnement et l'objectif de contrôle.
2. Définition opérationnelle de « correct »
3. Logique Ladder et état de l'équipement simulé Montrez la logique parallèlement à l'état résultant de la machine ou du procédé en simulation.
4. Le cas de défaut injecté
5. La révision effectuée Enregistrez le changement de logique et pourquoi il était nécessaire.
6. Leçons apprises Expliquez ce que la défaillance a révélé sur la conception de la séquence, la gestion des états, le timing ou les hypothèses de procédé.

Ce format est plus difficile à falsifier car il impose la causalité. L'ingénierie s'améliore généralement lorsque les captures d'écran cessent d'être traitées comme des preuves.

La mise en service virtuelle prouve le ROI en réduisant l'incertitude coûteuse avant la FAT, la SAT ou le démarrage en direct. La mesure financière pertinente n'est pas la vitesse à laquelle un outil génère du code. C'est de savoir si la logique résultante réduit les cycles de révision, les retards de test et les risques liés à l'équipement pendant la mise en service.

Une définition délimitée aide ici :

- Un ROI mesurable dans la mise en service signifie une réduction quantifiable d'un ou plusieurs des éléments suivants :

• heures de FAT,
• révisions de logique SAT,
• retards de démarrage,
• contraintes ou dommages matériels causés par des erreurs de contrôle évitables,
• retouches d'ingénierie causées par des cas limites non testés.

Ce cadrage est cohérent avec la littérature sur les jumeaux numériques industriels et la mise en service virtuelle, qui positionne généralement la simulation comme une méthode pour une découverte plus précoce des défauts, une validation des séquences et un effort de mise en service physique réduit. Les économies exactes varient considérablement selon le type de procédé, la fidélité du modèle, la portée et la discipline de l'équipe. Cette variabilité doit être énoncée clairement.

Pourquoi le volume de code généré est la mauvaise métrique

Les lignes de logique générées par minute ne sont pas un KPI de mise en service. Ce sont, au mieux, un KPI de rédaction. Si un outil d'IA produit dix barreaux rapidement et que six d'entre eux nécessitent des retouches après des tests dynamiques, l'avantage de vitesse apparent s'effondre en dette de mise en service.

Le filtre de ROI pratique est simple :

• La logique peut-elle être exécutée par rapport à un modèle de procédé réaliste ?
• Les défauts peuvent-ils être injectés en toute sécurité ?
• L'équipe peut-elle observer la cause à effet au niveau des tags et de l'équipement ?
• Les révisions peuvent-elles être effectuées avant le déploiement physique ?

Si la réponse est non, les « économies d'IA » sont encore hypothétiques. Le terrain est l'endroit où les économies hypothétiques vont pour être auditées.

Ce que la mise en service virtuelle valide et que la revue statique ne peut pas faire

La revue statique peut détecter les erreurs de syntaxe, les omissions évidentes et certaines contradictions logiques. Elle ne peut pas valider pleinement le comportement dynamique tel que :

• la mise en scène instable des pompes,
• le broutage causé par des entrées bruitées,
• les conditions de course dans les transitions d'étape,
• les temporisateurs de preuve ou de debounce manquants,
• les mauvais seuils d'alarme,
• l'interaction PID avec un retard de procédé réaliste,
• le comportement de redémarrage après interruption,
• le comportement de verrouillage en cas de défaillance partielle.

Ce ne sont pas des cas limites exotiques. Ce sont des travaux de mise en service ordinaires.

OLLA Lab est utile ici en tant qu'environnement de validation délimité pour la répétition de la logique, l'observation des E/S et les tests de jumeaux numériques avant de toucher à l'équipement réel. Il doit être traité comme une couche de vérité pour la logique non révisée, et non comme un substitut au jugement de l'ingénieur.

Un flux de travail pratique ressemble à ceci :

1. Commencez par un récit de contrôle, pas une acceptation aveugle du code

Si un assistant IA génère une description de séquence ou un projet de logique Ladder, définissez d'abord :

• l'objectif de la machine,
• les permissives requises,
• les états de séquence attendus,
• les conditions anormales qui doivent être gérées,
• la réponse de sécurité.

Cela évite l'erreur courante de valider la sortie de texte au lieu de valider le comportement de la machine.

2. Construisez la logique Ladder dans l'éditeur basé sur navigateur

L'éditeur Ladder d'OLLA Lab prend en charge les catégories d'instructions de base utilisées dans le travail sur automate, notamment :

• contacts et bobines,
• temporisateurs et compteurs,
• comparateurs et mathématiques,
• opérations logiques,
• instructions PID.

C'est ici que la logique de projet devient inspectable. La logique générée qui semblait plausible dans le texte devient souvent moins impressionnante lorsqu'elle est rendue sous forme de structure de séquence réelle.

3. Liez la logique à un scénario avec un comportement d'équipement observable

OLLA Lab inclut des simulations basées sur des scénarios et des environnements de type jumeau numérique dans des contextes industriels. Le point utile n'est pas la nouveauté visuelle. Le point utile est que l'ingénieur peut observer si l'état du Ladder et l'état de l'équipement concordent.

Des exemples de ce qu'il faut tester incluent :

• les permissives de démarrage/arrêt du moteur,
• la rotation des pompes en tête/en attente,
• la réponse au bourrage de convoyeur,
• le séquençage des mélangeurs,
• les seuils analogiques et les points de déclenchement,
• la réponse PID dans des conditions de procédé changeantes,
• le comportement d'arrêt d'urgence ou de chaîne de défauts.

4. Utilisez le mode simulation et le panneau des variables pour inspecter la causalité

Le mode simulation permet à l'ingénieur d'exécuter la logique, d'arrêter la logique, de basculer les entrées et d'observer les sorties et les états des variables sans matériel. Le panneau des variables offre une visibilité sur :

• les entrées et sorties,
• les états des tags,
• les valeurs analogiques,
• les variables liées au PID,
• la sélection de scénarios et les changements d'état.

Ceci est important car les erreurs générées par l'IA ne sont souvent pas syntaxiques. Elles sont causales. Le barreau s'active, mais la machine n'aurait pas dû bouger. Ou la machine ne bouge pas, et la permissive manquante est enterrée trois conditions en amont.

5. Injectez les conditions de défaut délibérément

Un environnement de validation utile doit prendre en charge les tests d'état anormal. Dans OLLA Lab, cela signifie utiliser le comportement des scénarios, la manipulation des variables et les tests de séquence pour exposer :

• les entrées bruitées,
• le retour de preuve différé,
• les permissives échouées,
• les conditions d'alarme,
• la dérive analogique ou le franchissement de seuil,
• les blocages de séquence.

C'est là que l'affirmation « l'IA l'a écrit » devient hors de propos. La logique survit au comportement défaillant ou elle ne le survit pas.

6. Révisez la logique et documentez la correction

Le but n'est pas de regarder l'IA échouer pour le sport. Le but est d'identifier les omissions, de réviser la logique et de laisser derrière soi des preuves de la raison pour laquelle la révision était nécessaire.

Un exemple compact :

Exemple textuel d'une correction Ladder :

• Ajouter un temporisateur de debounce TON à une entrée de cellule photoélectrique bruitée.
• Utiliser le bit « done » du temporisateur, plutôt que l'entrée brute, pour permettre la transition.
• Retester la séquence sous un broutage d'entrée répété pour confirmer un comportement stable.

Ce genre de correction est banal, ce qui est précisément la raison pour laquelle il compte. Les problèmes de mise en service sont souvent constitués d'omissions ordinaires.

Ce qu'OLLA Lab prend en charge, et ce qu'il ne prend pas en charge

Une revendication de produit délimitée est une revendication crédible.

OLLA Lab prend en charge :

• la pratique de la logique Ladder dans un éditeur basé sur le Web,
• les tests basés sur la simulation,
• la visibilité des E/S et des variables,
• la validation de scénarios de type jumeau numérique,
• les flux de travail d'apprentissage guidé,
• l'expérimentation analogique et PID,
• la répétition basée sur des scénarios de séquençage, verrouillages, alarmes et gestion des défauts.

OLLA Lab ne fournit pas par lui-même :

• la compétence sur site,
• la certification,
• la qualification SIL,
• la preuve automatique de préparation au terrain,
• l'exemption de revue d'ingénierie ou d'obligations de cycle de vie de sécurité.

Cette limite protège le lecteur contre les revendications excessives.

L'approvisionnement devrait demander des preuves liées au comportement de mise en service, et non à la qualité de la présentation. Si la preuve la plus solide d'un fournisseur est une capture d'écran de tableau de bord ou une démo de logique générée sans injection de défaut, l'évaluation est incomplète.

Utilisez des questions comme celles-ci :

• Quelle partie du flux de travail est consultative, et quelle partie peut influencer l'action de contrôle ?
• Comment l'exécution déterministe est-elle protégée contre la sortie probabiliste ?
• Quel est l'état de repli si le service d'IA est indisponible ou incorrect ?
• La logique ou la recommandation a-t-elle été validée par rapport à un modèle de procédé réaliste ?
• Le fournisseur peut-il démontrer l'injection de défauts et le comportement de récupération ?
• Quelle preuve existe-t-il que l'outil réduit l'effort de FAT/SAT plutôt que de déplacer le travail en aval ?
• Comment la philosophie des alarmes, les verrouillages et le comportement de redémarrage sont-ils gérés ?

Un fournisseur qui ne peut pas répondre à ces questions peut toujours avoir un produit d'analyse utile. Il ne devrait simplement pas être acheté comme s'il s'agissait d'une intelligence de mise en service.

L'« AI-washing » dans l'automatisation industrielle est mieux identifié en testant si une capacité revendiquée survit à la réalité du contrôle déterministe. La question décisive n'est pas de savoir si un outil utilise l'IA. C'est de savoir si ses sorties peuvent être validées par rapport au comportement du cycle de scrutation, aux contraintes physiques, à la causalité des E/S et aux états de procédé défaillants avant le déploiement.

La mise en service virtuelle est le filtre pratique car elle convertit les revendications de capacité vagues en comportement d'ingénierie observable. C'est là que la vraie valeur apparaît, et là où l'innovation factice manque généralement de vocabulaire.

OLLA Lab s'intègre dans ce flux de travail en tant qu'environnement délimité pour construire, simuler, observer, tester les défauts et réviser la logique de contrôle par rapport à des scénarios réalistes. C'est un cas d'utilisation sérieux. Il n'a pas besoin d'embellissement.

Expert en automatisation industrielle et systèmes de contrôle, spécialisé dans la validation de la sécurité fonctionnelle et l'intégration de nouvelles technologies dans les environnements OT.

Cet article a été vérifié pour sa conformité aux normes d'ingénierie industrielle (IEC 61508, IEC 61131-3) et pour l'exactitude des concepts de mise en service virtuelle.

- IEC 61131-3: Automates programmables — Partie 3 : Langages de programmation - Famille de normes de sécurité fonctionnelle IEC 61508 - Cadre de gestion des risques liés à l'IA du NIST (AI RMF 1.0) - Contexte de la politique Industrie 5.0 de l'UE - Vue d'ensemble des jumeaux numériques (NIST)