IA dans l'industrie : enjeux, défis et pièges réels — au-delà de la hype

Le constat — la majorité des POC ne tiennent pas en production

Depuis 2017, l’industrie investit massivement dans l’intelligence artificielle. Les annonces se multiplient : maintenance prédictive, vision pour la qualité, copilots pour l’ingénierie, optimisation énergétique. Et pourtant, les chiffres publiés par les cabinets d’analyse convergent vers un même constat troublant : la majorité des projets d’IA n’atteignent jamais leurs objectifs métier. Gartner cite couramment 85 % d’échec ; McKinsey, dans son rapport annuel State of AI, montre que l’adoption progresse mais que le passage à l’échelle reste l’exception.

Le ratio est encore plus défavorable dans l’industrie. Les données OT sont fragmentées, les automates restent en production 20 ans, les contraintes de sécurité fonctionnelle interdisent les boucles fermées ML → procédé, et le coût d’un faux positif sur une ligne de production se chiffre en heures d’arrêt.

Pourtant l’écart ne vient pas d’un problème d’algorithmes. Les modèles existent, ils sont matures, ils sont accessibles. Six enjeux structurants déterminent le passage du POC à la production. Cet article les nomme — sans les enjoliver.

Enjeu 1 — La donnée industrielle est rarement prête

Le mythe : « on a déjà 20 ans de données SCADA, il suffit d’entraîner un modèle dessus ».

La réalité que rencontre tout data scientist le premier jour :

Friction	Manifestation
Sources dispersées	4 à 7 historians différents par site (OSIsoft PI, AVEVA Historian, Wonderware, Ignition, exports CSV ad hoc, Excel partagés)
Pas de labels	Très peu de jeux annotés (« cette défaillance était de tel type »). Les rapports d’incident sont en texte libre.
Compression destructive	Les algorithmes de compression historian (PI Compression, AVEVA Swinging Door) écartent les points jugés « redondants ». Pour une analyse vibratoire, on a perdu l’information avant même de la chercher.
Échantillonnage incohérent	Un tag à 1 s, un autre à 5 min, un troisième en événementiel. Sans rééchantillonnage propre, impossible de corréler.
Métadonnées absentes	`TIC_2301` n’a pas de signification sans le P&ID. Les data scientists doivent reconstituer l’unité physique, la plage, la criticité.
Capteurs en dérive	Un capteur vieux de 10 ans envoie déjà des valeurs biaisées de quelques %. Le modèle entraîné sur ces données reproduit le biais.

D’où la règle empirique citée dans tous les retours d’expérience publics : 60 à 80 % du temps d’un projet IA industriel sert à préparer la donnée. Avant tout modèle, il faut :

Un catalogue de données unifié (Microsoft Purview, Apache Atlas, Collibra)
Un modèle d’information structuré (OPC UA Information Models, IEC 61850 en énergie, ISA-95 en manufacturing)
Un historian moderne ou time-series database (InfluxDB, TimescaleDB, Aveva PI System en mode non-compressé, ou time-series cloud type Azure Data Explorer)
Une gouvernance : qui valide la qualité, qui labélise les incidents, qui retire les outliers, qui versionne les datasets

Sans ces fondations, le meilleur modèle dérive en trois mois.

Enjeu 2 — Brownfield et legacy : deux horloges qui ne tournent pas à la même vitesse

Le cycle de vie d’un site industriel : 20 à 30 ans pour les automates, 30 à 50 ans pour les vannes, les pompes et les structures. Le cycle de l’IA : 6 à 18 mois pour qu’un modèle se périme.

Cette dissonance crée trois contraintes que beaucoup de POC ignorent :

L’IA ne pilote pas un procédé sensible directement. Un modèle qui propose un setpoint doit passer par l’opérateur, puis — s’il a un impact safety — par une fonction instrumentée de sécurité validée IEC 61511. Aucune boucle fermée IA → SIS sans révision complète de l’étude SIL. Voir la fiche IEC 61511 pour le détail.
Les PLC en production ne parlent pas nativement à des modèles ML. Le pont passe par OPC UA, MQTT Sparkplug ou un edge gateway. Le déploiement edge devient un sous-projet en soi (containerisation ONNX/TF Lite, gestion des dépendances, mise à jour à distance, supervision).
Les contrats vendeurs limitent les modifications. Beaucoup de garanties OEM (Siemens, Emerson, Honeywell, ABB) prévoient une perte de support si l’on connecte un « 3rd party software » à leur DCS sans accord. À négocier dès l’appel d’offres — souvent oublié, source de blocage à la mise en service.

Pour aller plus loin sur l’architecture qui permet d’exposer des données vers un modèle ML sans casser la posture cyber : Échanger des données entre 2 automates OT.

Enjeu 3 — Physique, ML pur, hybride : le choix qui change tout

Le débat fondamental. Et le choix par défaut « on prend un modèle deep learning » est rarement le bon.

Approche	Avantages	Limites	Quand l’utiliser
Modèle physique (first-principles)	Explicable, robuste hors-distribution, fonctionne avec peu de données, audit possible	Calibration complexe, nécessite expertise procédé profonde, lent à mettre au point	Procédés bien modélisés (thermodynamique, transferts thermiques, dynamique des fluides) — colonnes de distillation, échangeurs, réacteurs
Machine Learning pur	Découvre des patterns non-évidents, scale avec le volume de données, rapide à prototyper	Boîte noire, dérive en cas de changement opératoire, peu robuste hors-distribution, audit difficile	Vision (qualité, détection de défauts), patterns acoustiques (rotating equipment), NLP industriel (extraction de procédures, génération de specs), prédictions sur grands flux historiques
Hybride physics-informed ML (PINN, neuro-symbolique)	Combine robustesse physique + flexibilité ML, requiert moins de données, plus explicable	Plus complexe à concevoir, peu d’outils packagés, expertise rare	Procédés bien modélisés physiquement mais avec dérives non-linéaires ou phénomènes mal capturés (encrassement, vieillissement catalyseur, fatigue mécanique)

En 2026, le hybride physics-informed ML émerge comme pattern dominant pour les procédés continus (chimie fine, pétrochimie, énergie). Les modèles ML purs restent dominants pour la vision et le NLP industriel — cas d’usage où la physique ne donne pas d’équation analytique.

L’erreur classique : appliquer du deep learning à un problème de régulation alors qu’un PID bien réglé fait mieux pour 1/100 du coût.

Enjeu 4 — MLOps industriel : le talon d’Achille

Un modèle qui tourne en lab est à 10 % du chemin. Les 90 % restants : le faire vivre en production.

Le cycle MLOps industriel :

   Données brutes → Préparation → Entraînement → Validation → Déploiement edge
                                                                    ↓
   Re-entraînement ← Drift detection ← Monitoring ← Inférence temps-réel

Points spécifiquement industriels que la plupart des plateformes cloud ne couvrent pas :

Drift detection continue. Les conditions opérationnelles changent : nouvelle matière première, changement de saison, vieillissement des équipements, modification d’un setpoint. Sans détection automatique de la dérive, le modèle se dégrade silencieusement. Outils répandus : Arize AI, Fiddler, Evidently AI, WhyLabs.
Déploiement edge. Modèle compilé pour cible spécifique (ONNX runtime, TensorFlow Lite, OpenVINO). CPU/GPU/TPU choisi selon la latence requise : vision temps réel = 10 à 50 ms par image, optimisation énergétique = 1 à 15 min.
Versioning conjoint : modèle + données d’entraînement + code de préparation, tout doit être versionné ensemble (DVC, MLflow, Git LFS). Reproduire un modèle 18 mois après est une exigence d’audit EU AI Act.
Rollback automatique. Si un nouveau modèle dégrade les KPI mesurés en production, retour au précédent — sans intervention humaine. Très peu de plateformes industrielles gèrent ça en standard.

Plateformes edge industrielles courantes :

Siemens Industrial Edge + Industrial Edge Management (orchestration)
NVIDIA EGX / IGX (vision et inférence performante, jusqu’au temps réel deep learning)
AWS Panorama (vision sur site, intégration AWS)
Microsoft Azure Stack Edge (généraliste, intégration Azure ML)
Phoenix Contact PLCnext (containers Docker exécutés sur l’automate lui-même)

Enjeu 5 — La nouvelle surface d’attaque cyber

Un modèle d’IA est un actif. Comme tout actif déployé en production, il est attaquable. Cinq vecteurs spécifiques à connaître :

Model poisoning. Un attaquant qui peut injecter des données dans le pipeline d’entraînement peut biaiser le modèle. Exemple théorique : empoisonner les données vibratoires pour qu’un modèle de maintenance prédictive ignore une dérive sur un équipement critique. Mesure : signer cryptographiquement les datasets et tracer les ingestions.
Adversarial examples. Modifier subtilement une image ou un signal d’entrée pour tromper le modèle. Eykholt et al. ont démontré en 2018 (article « Robust Physical-World Attacks on Deep Learning Visual Classification ») qu’un autocollant sur un panneau de signalisation suffit à faire qu’un système de vision le classifie comme un autre. Applicable aux systèmes de vision industrielle.
Supply chain ML. Utiliser un modèle open-source pré-entraîné contenant une backdoor. Anthropic a publié en janvier 2024 une étude (« Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training ») montrant qu’un modèle entraîné à se comporter normalement sauf sur un trigger spécifique reste indétectable par les méthodes de fine-tuning classiques. Mesure : sourcer les modèles uniquement depuis des registries certifiés et signés.
Extraction de modèle / inversion. Interroger un modèle exposé en production permet, avec suffisamment de requêtes, de reconstituer son comportement (clonage) voire des éléments du dataset d’entraînement (privacy attacks). Mesure : rate limiting, monitoring des patterns de requêtes, isolation du modèle dans la DMZ industrielle.
Prompt injection (pour les LLM industriels / copilots). Injecter dans un prompt utilisateur des instructions qui modifient le comportement du modèle. Particulièrement risqué pour les copilots qui génèrent du code PLC : un fournisseur malveillant pourrait injecter dans une documentation des instructions pour produire du code vulnérable. Mesure : isoler le contexte utilisateur, filtrer les inputs, valider manuellement tout code généré avant déploiement.

Cadre IEC 62443 applicable : ces enjeux ne sont pas spécifiquement traités dans la 4-1 / 4-2 actuelle, mais la révision 2026 de la série commence à les intégrer. En attendant, traiter le modèle ML comme un composant IACS standard et lui appliquer le SL-C(2) ou SL-C(3) selon la criticité du procédé qu’il informe.

Enjeu 6 — Le ROI difficile à quantifier

Le piège classique : on déploie l’IA, mais on ne sait plus mesurer ce qu’elle apporte.

Trois sources de difficulté de mesure :

Comparaison contrefactuelle. Il faut savoir ce qui se serait passé sans IA. Sur un parc d’équipements, on peut faire de l’A/B testing (un sous-ensemble équipé, un autre non) mais ça suppose une période d’observation longue, souvent 12 à 18 mois.
Attribution. Un gain de disponibilité de 2 % peut venir de l’IA, ou d’un changement de procédure opérateur, ou d’un nouveau capteur installé en même temps, ou d’une saison particulière. Isoler la contribution IA est rare et exige une discipline statistique que peu de directions industrielles ont en interne.
Coûts cachés. Le modèle est l’iceberg visible. MLOps, infrastructure cloud, mise à jour, retraining, formation des opérateurs, maintenance des datasets, support des sondes de monitoring : ces postes représentent souvent 3 à 5 fois le coût initial de développement du modèle. Beaucoup de business cases s’écroulent au moment où ces coûts apparaissent en année 2.

Métriques business à instrumenter avant lancement (baseline 6 à 12 mois) :

Disponibilité / OEE (Overall Equipment Effectiveness)
Taux de rebuts qualité
Consommation énergétique spécifique (kWh / unité produite)
Coût de maintenance et MTBF
Temps de cycle
Nombre d’événements ESD non planifiés

Sans baseline rigoureuse documentée avant le projet, l’ROI sera toujours contestable — soit par celui qui veut prouver le succès, soit par celui qui veut prouver l’échec.

EU AI Act — calendrier et applicabilité industrielle

Premier cadre réglementaire mondial pour l’IA. Règlement (UE) 2024/1689, adopté en juin 2024, entré en vigueur le 1er août 2024, application progressive sur 36 mois.

Échéance	Ce qui s’applique
2 février 2025	Pratiques interdites (manipulation cognitive, scoring social, etc.) — Articles 5. Obligation d’alphabétisation IA du personnel concerné — Article 4.
2 août 2025	Obligations pour les modèles GPAI (General-Purpose AI), gouvernance, autorités nationales, sanctions applicables — Chapitre V, VII, XII.
2 août 2026	Application générale du règlement. Systèmes IA à haut risque (Annexe III) : obligations complètes.
2 août 2027	Systèmes IA intégrés comme composant de sécurité dans des produits déjà soumis à harmonisation (Annexe I : machines, jouets, dispositifs médicaux, etc.).

Quatre catégories de risque :

Risque inacceptable → interdit. Notation sociale, manipulation comportementale exploitant des vulnérabilités, reconnaissance biométrique à distance en temps réel par les autorités (avec exceptions limitées), etc.
Haut risque → fortes obligations : gestion des risques (Article 9), gouvernance des données (Article 10), documentation technique (Article 11), tenue de journaux (Article 12), transparence (Article 13), supervision humaine (Article 14), exactitude/robustesse/cybersécurité (Article 15).
Risque limité → obligations de transparence (informer l’utilisateur qu’il interagit avec une IA).
Risque minimal → pas d’obligation (jeux, filtres anti-spam, etc.).

Cas industriels qui tombent en « haut risque » (Annexe III ou Annexe I) :

IA composant de sécurité d’une machine (Règlement Machines (UE) 2023/1230 → Annexe I AI Act)
IA dans la gestion d’infrastructures critiques (eau, énergie, gaz, transport, fourniture chauffage — Annexe III §2)
IA dans des dispositifs médicaux (Règlement (UE) 2017/745 MDR → Annexe I AI Act)
IA dans la sécurité des produits soumis à la Directive ATEX, à la Directive Équipements sous Pression, etc.

Sanctions (Article 99) :

Pratiques interdites : jusqu’à 35 M€ ou 7 % du CA mondial
Manquement aux obligations des opérateurs de systèmes à haut risque : jusqu’à 15 M€ ou 3 % du CA mondial
Informations incorrectes aux autorités : jusqu’à 7,5 M€ ou 1,5 % du CA mondial

Le règlement s’applique aux fournisseurs et aux utilisateurs (« déployeurs ») de systèmes IA. Un site industriel qui utilise une IA fournie par un tiers porte une partie des obligations — notamment la supervision humaine et la conservation des journaux.

ISO/IEC 42001 et NIST AI RMF — les référentiels de management

Deux frameworks complémentaires se sont imposés en 2023-2024.

Aspect	ISO/IEC 42001:2023	NIST AI RMF 1.0
Type	Norme système de management — certifiable par tierce partie	Framework / guide — non-certifiable
Publié	Décembre 2023	Janvier 2023
Origine	ISO/IEC JTC 1/SC 42	NIST (USA), Department of Commerce
Structure	Annexe A : ensemble de contrôles structurés par objectif (A.2 à A.10)	4 fonctions : Govern, Map, Measure, Manage
Compatibilité ISO existante	Forte — High-Level Structure d’ISO, intégrable avec ISO 9001 / 27001 / 14001	Indépendante mais conçue pour s’intégrer aux pratiques existantes
Compatibilité EU AI Act	Très forte — candidate au statut de norme harmonisée sous le AI Act	Référence aux États-Unis et pour les fournisseurs internationaux
Usage type	Certification organisationnelle, audit tiers (équivalent ISO 27001 pour l’IA)	Self-assessment, gap analysis, due diligence

En pratique en 2026, une organisation industrielle qui développe ou intègre de l’IA doit viser ISO/IEC 42001 + alignement EU AI Act. NIST AI RMF reste utile comme grille d’analyse interne et pour les opérations transatlantiques.

Quelques cas réels (publics)

Pour ne rien inventer, voici quelques cas documentés publiquement par leurs auteurs.

Succès partagés publiquement

BMW — AIQX. Depuis 2019, BMW déploie « AIQX » (Artificial Intelligence Quality Next) dans plusieurs usines, notamment Regensburg et Dingolfing. Système de vision automatisée pour le contrôle qualité de pièces. Communiqué et présenté par BMW comme cas industriel emblématique.
Siemens Industrial Copilot. Annoncé en 2024, premier assistant génératif pour la génération de code TIA Portal. Démonstrations publiques en 2024-2025, déploiements terrain encore limités à mi-2026 — les retours opérationnels publiés sont anecdotiques.
Anheuser-Busch InBev. La brasserie communique publiquement sur l’usage de maintenance prédictive ML sur ses lignes d’embouteillage, en partenariat avec Microsoft. Détails opérationnels chiffrés peu publiés.

Échecs publics retentissants

GE Predix (2014-2020). Ambition de plateforme IIoT/AI globale, présentée comme « le système d’exploitation de l’industrie ». GE a annoncé plusieurs milliards de dépréciations sur sa division GE Digital sur la période. Démantèlement progressif : Predix a été cédée, GE Digital recentré, plusieurs activités vendues. Cause publiquement reconnue par GE : difficulté de productiser une plateforme générique vendable hors de la base installée GE.
IBM Watson Health. Plusieurs milliards investis sur une décennie via acquisitions (Phytel, Explorys, Truven Health Analytics, Merge Healthcare). En janvier 2022, IBM a annoncé la cession de ses actifs Watson Health à Francisco Partners. Cause publiquement reconnue : décalage entre les attentes commerciales et la performance réelle des modèles sur des cas d’usage cliniques.

Leçon transversale des échecs publics : la productisation d’une plateforme IA générique est beaucoup plus difficile que ne le suggèrent les démonstrations. Les succès industriels se construisent sur des cas d’usage étroits, bien définis, avec un ROI mesurable, et un effort d’intégration assumé sur 18-36 mois.

Les 7 pièges classiques

Démarrer par la technologie au lieu du cas d’usage métier. « On prend Azure AI » avant d’avoir défini le KPI à améliorer et la baseline à mesurer. Inverser systématiquement : KPI → baseline → cas d’usage → données → modèle → techno.
Sous-estimer la préparation des données. Allouer 60 % du budget projet à la donnée, pas 60 % au modèle. Le data engineering coûte plus cher que le data science.
Pas de proof-of-test sur données historiques avant POC live. Avant de mobiliser des équipes opérationnelles, démontrer que le modèle se serait comporté correctement sur 12-24 mois de données passées (backtesting). Un modèle qui ne passe pas le backtest ne passera jamais le live.
Pas de critères go/no-go quantitatifs définis au lancement. Sans seuils objectifs (par exemple : pas plus de 5 % de faux positifs sur 3 mois consécutifs), un POC qui ne marche pas est continué pour des raisons politiques et finit par épuiser le budget.
Couplage IA et procédé sans validation safety. Un modèle d’IA ne pilote pas une fonction instrumentée de sécurité. Période. Voir IEC 61511 §11.2.3 sur les exigences applicables aux outils d’aide à la décision intégrés au SIS.
Pas de propriétaire identifié du modèle après le go-live. Qui maintient ? Qui re-entraîne ? Qui décide d’un retrait ? Qui audite sous EU AI Act ? À nommer dès la conception, pas après la mise en production.
Communication marketing avant retour terrain. Annoncer publiquement un succès IA sans 12 mois de validation en production est statistiquement un risque réputationnel. Les succès qui tiennent dans la durée sont ceux qui ont été testés en silence d’abord.

Pour aller plus loin

Hub IA dans l’industrie — cas d’usage, plateformes vendeurs, architectures, réglementation détaillée
Hub Cybersécurité OT — la nouvelle surface d’attaque ML appliquée aux ICS
Article Échanger des données entre 2 automates OT — l’architecture qui s’applique aussi pour exposer un modèle ML à un automate

Une dernière chose. L’IA n’est pas une révolution industrielle — c’est une couche d’outils nouvelle, déployée sur des couches existantes (procédé, automatisation, sécurité fonctionnelle, cybersécurité) qu’elle ne remplace pas. Les sites qui réussissent leur IA sont ceux qui maîtrisent d’abord ces couches sous-jacentes. Les autres entrent dans la statistique des 85 % de Gartner — non parce que l’IA ne marche pas, mais parce que les fondations n’étaient pas prêtes.