Votre usine dispose de données. Cela ne signifie pas pour autant qu’elle soit prête pour l’IA.

Un responsable de production peut généralement se prévaloir de plusieurs années d' machine les registres, les rapports de qualité, les dossiers de maintenance et les relevés des capteurs, stockés un peu partout au sein de l'entreprise. Sur le papier, l'usine semble disposer exactement de ce dont un projet d'IA industrielle a besoin : de grandes quantités de données opérationnelles accumulées au cours de la production quotidienne.

Le premier essai pilote révèle souvent une réalité moins réjouissante. Les noms des machines diffèrent d’un système à l’autre, les horodatages ne concordent pas, les notes de maintenance sont stockées sous forme de texte libre, et la base de données qualité enregistre un défaut sans conserver les conditions de processus qui l’ont précédé. Les ingénieurs comprennent la signification de chaque valeur car ils connaissent la ligne de production, le produit et l’historique de l’équipement, mais un système d’IA ne voit que des mesures isolées dont la signification n’a jamais été explicitée.

Les entreprises industrielles sont rarement confrontées à une absence totale de données. Elles rencontrent des difficultés parce que les informations dont elles disposent ont été collectées à des fins de maintenance, de contrôle, de conformité ou de reporting, plutôt que pour l'apprentissage automatique, ce qui fait qu'une grande partie de ces données est fragmentée, mal étiquetée et déconnectée du contexte opérationnel nécessaire à la prise de décisions fiables.

Une mesure ne constitue pas encore un savoir-faire industriel

Une température de 82 degrés, un pic de vibration ou une augmentation soudaine de la consommation d'énergie peuvent sembler significatifs, bien qu'aucune de ces valeurs ne puisse être interprétée correctement prise isolément. Une même température peut indiquer un fonctionnement normal lors d’une étape de production et l’apparition d’un défaut lors d’une autre, tandis qu’un profil de vibrations qui semble inhabituel pour une machine peut s’avérer tout à fait normal après un changement d’outil ou lorsque un matériau différent entre dans le processus.

Pour qu’un modèle d’IA puisse reconnaître ces distinctions, la mesure doit être mise en relation avec la machine qui l’a générée, le produit en cours de fabrication, la recette et le mode de fonctionnement, l’outil installé à ce moment-là et les événements qui ont suivi. Il peut également avoir besoin d’informations concernant l’équipe de travail, les conditions ambiantes, le lot du fournisseur, l’historique de maintenance et le fait qu’un ingénieur ait ou non temporairement modifié un paramètre.

Ce sont ces informations contextuelles qui permettent de replacer un signal dans un contexte industriel exploitable. Sans elles, un modèle risque de mettre en évidence des relations statistiques qui semblent convaincantes, tout en confondant les variations normales de la production avec des signes de défaillance ou de mauvaise qualité.

Une usine peut donc collecter des milliards de données et ne pas pour autant disposer des informations nécessaires pour répondre à une question relativement simple : dans quelles conditions précises ce processus commence-t-il à générer des défauts ?

Les données d'usine ont été conçues pour répondre à différents objectifs

La difficulté réside tout d'abord dans l'architecture des opérations industrielles. Les automates programmables ont été conçus pour contrôler les machines, les historiens pour conserver les signaux de séries chronologiques, les systèmes d’exécution de la fabrication pour gérer la production et les plateformes d’entreprise pour traiter les commandes, les matériaux et les finances. Les équipes chargées de la qualité, de la maintenance et de l’ingénierie ont souvent mis en place des applications supplémentaires en fonction de leurs propres besoins, créant ainsi un environnement dans lequel chaque système remplit une fonction légitime, mais décrit la même usine de manière différente.

L'identifiant attribué à une machine dans le système de maintenance peut ne pas correspondre à l'étiquette utilisée dans l'historique. Un produit peut porter un nom en ingénierie, un autre en production et un troisième dans le système commercial, tandis que les modifications apportées à un composant peuvent être consignées dans un document sans pour autant être reflétées de manière cohérente dans les données collectées sur la ligne de production.

Cette fragmentation n'empêche pas toujours les employés de travailler, car les équipes expérimentées apprennent à cerner les correspondances entre les systèmes. Elles savent que “ Ligne 4 ”, “ L04 ” et un numéro d'inventaire interne désignent le même équipement, et elles se souviennent qu'un capteur a été remplacé lors d'un arrêt particulier, même si ce changement n'a jamais été consigné de manière structurée.

L'IA ne peut pas s'appuyer sur ces connaissances informelles à moins que l'organisation ne les recense. Le modèle a besoin d'identités, de relations et de définitions cohérentes qui relient les données d'un système à l'autre ; sinon, une grande partie du sens de l'usine reste enfermée dans l'expérience de chaque salarié.

Un plus grand nombre de capteurs ne suffira pas à pallier une base de données insuffisante

Lorsqu'un projet d'IA industrielle manque d'informations utiles, la réaction instinctive consiste souvent à installer des capteurs supplémentaires. Dans certains cas, cela s'avère nécessaire, notamment lorsqu'un paramètre physique important n'a jamais été mesuré, mais il se peut que l'usine collecte déjà suffisamment de signaux et qu'elle soit simplement incapable de les interpréter dans leur ensemble.

L'ajout de nouveaux appareils dans un environnement fragmenté peut accroître le volume de données sans pour autant améliorer la compréhension. L'entreprise reçoit des flux supplémentaires de données sur les vibrations, la pression et la température, mais reste incapable de déterminer quel ordre de fabrication était en cours lorsque l'anomalie s'est produite, ni si le composant concerné a par la suite échoué au contrôle qualité.

Avant d'étendre son réseau de capteurs, un fabricant doit déterminer quelle décision l'application d'IA est censée faciliter et quelles informations seraient nécessaires pour prendre cette décision en toute fiabilité. La prévision d'une défaillance d'un outil nécessite des données différentes de celles requises pour optimiser la consommation d'énergie, tandis que l'identification de la cause d'un défaut de surface peut exiger une combinaison de paramètres de processus, de l'historique des matériaux, de l'état de la machine et de données d'imagerie.

En commençant par la question opérationnelle, on évite que le projet ne se transforme en un simple exercice de collecte aveugle. L'objectif n'est pas de créer le plus grand lac de données possible, mais de préserver les relations qui expliquent ce qui s'est passé en production.

Les archives historiques donnent souvent une image déformée de la réalité

Les systèmes d'IA industriels apprennent à partir des exemples dont ils disposent, mais l'historique d'une usine est rarement équilibré ni complet. Une machine bien entretenue génère des années de données d'exploitation normales et relativement peu d'exemples de défaillances. Les pannes graves ne surviennent qu'occasionnellement, tandis que les problèmes mineurs sont corrigés par des techniciens expérimentés avant même de devenir des incidents officiels.

L'ensemble de données ainsi obtenu contient une grande quantité de données de production courantes et seulement un petit nombre d'événements que le modèle est censé reconnaître. Même ces exemples peuvent s'avérer peu fiables, car les codes d'erreur ont été saisis de manière incohérente, les notes de maintenance manquent de détails ou encore différents techniciens ont utilisé des descriptions différentes pour un même problème.

Les pratiques opérationnelles évoluent également. Une machine peut être équipée de nouveaux outils, logiciels ou composants, et le matériau fourni aujourd’hui peut se comporter différemment de celui utilisé lors de la collecte des données historiques. Un modèle entraîné sur des données passées peut perdre de sa pertinence, même si sa précision technique semblait autrefois solide.

Cela rend le traitement des données industrielles plus complexe que la simple suppression des lignes en double dans une base de données. Les ingénieurs et les opérateurs doivent déterminer si les enregistrements reflètent toujours le processus actuel, quels événements ont été correctement identifiés et dans quels cas l'absence d'un incident enregistré traduit simplement le fait qu'une intervention a eu lieu à temps.

L'histoire de l'usine n'est pas un récit neutre de la production. Il s'agit d'un compte rendu subjectif, influencé par les changements d'équipement, le jugement humain et les habitudes de reporting des différentes équipes.

Les informations non structurées contiennent souvent l'explication qui manque

Certaines des connaissances industrielles les plus précieuses ne se trouvent pas dans une base de données de capteurs. Elles apparaissent dans les commentaires de maintenance, les registres d'équipe, les photos d'inspection, les plans techniques, les rapports des fournisseurs et les échanges entre opérateurs expérimentés.

Un enregistrement numérique peut indiquer que les vibrations ont augmenté avant l'arrêt d'une machine, tandis que la note de maintenance explique qu'un roulement de rechange provenant d'un nouveau fournisseur avait été installé deux semaines plus tôt. Un système qualité enregistre un écart dimensionnel, mais un rapport d'équipe mentionne que le matériau était particulièrement difficile à usiner ce matin-là.

Ces liens sont précisément ce dont l'IA a besoin, mais les informations sont souvent stockées dans des fichiers PDF, des notes manuscrites ou des applications incompatibles. Le jargon industriel ajoute une complication supplémentaire, car les abréviations, la terminologie locale et les surnoms donnés aux machines peuvent être évidents pour le personnel, tout en restant incompréhensibles en dehors d'un site donné.

Les grands modèles linguistiques peuvent aider à extraire et à organiser une partie de ces informations, même s’ils nécessitent encore un vocabulaire contrôlé et des liens vers des données opérationnelles faisant autorité. La transformation d’une note de technicien en événement structuré n’est utile que si l’entreprise est en mesure de l’associer à l’actif, au composant, à l’heure et à l’ordre de fabrication appropriés.

Il ne s'agit pas simplement de numériser des documents. Il s'agit de préserver le sens qu'ils renferment et de le relier au processus physique qu'ils décrivent.

La mise en contexte est la tâche que la plupart des pilotes sous-estiment

Les projets d'IA industrielle sont souvent présentés comme des initiatives de développement de modèles ; les équipes consacrent donc beaucoup de temps à comparer des algorithmes, tout en considérant la préparation des données comme une tâche technique préliminaire. Dans la pratique, le travail le plus exigeant consiste à relier les signaux aux actifs, aux produits, aux événements et aux conditions de processus sous une forme permettant une utilisation cohérente.

Ce processus est appelé « contextualisation ». Il permet de situer les données au sein de l'usine plutôt que de les considérer comme des valeurs isolées ; ainsi, une mesure de pression correspond à la pression enregistrée à une étape précise d'un cycle de production donné, sur une machine identifiée, lors du traitement d'un lot de matière défini selon une recette enregistrée.

Une fois ces relations établies, une même infrastructure peut prendre en charge plusieurs applications. Les ingénieurs peuvent analyser les écarts de qualité, les équipes de maintenance peuvent comparer le comportement des équipements et les responsables énergétiques peuvent distinguer la consommation productive du gaspillage. Les jumeaux numériques et les agents d'IA peuvent également s'appuyer sur une structure opérationnelle commune, plutôt que de devoir créer une interprétation distincte de l'usine pour chaque projet.

L'alternative consiste en une série de projets pilotes isolés, dans lesquels chaque équipe nettoie et reconnecte les mêmes sources pour un cas d'utilisation très spécifique. La démonstration peut aboutir, mais le travail ne peut pas être transposé à plus grande échelle, car les données sous-jacentes restent fragmentées et chaque nouvelle application part du même point de départ difficile.

Des études récentes menées dans le secteur industriel continuent de mettre en évidence que le « big data » industriel, la collecte hétérogène de données et la gestion efficace des données comptent parmi les principaux obstacles à un déploiement fiable de l'IA, en particulier lorsque les systèmes doivent fonctionner de manière sûre et transparente dans des environnements à haut risque.

La qualité des données doit être définie d'un point de vue opérationnel

Les discussions au sein des entreprises sur la qualité des données portent souvent sur l'exhaustivité, l'exactitude et la cohérence. Ces aspects sont importants dans le secteur industriel, mais les données industrielles doivent également être évaluées à l'aune du processus physique.

Un capteur peut fournir des valeurs techniquement valides tout en étant mal étalonné. Un horodatage peut être enregistré correctement dans un système, mais s'avérer inutile lorsqu'une autre application utilise une horloge différente. Un état de machine qualifié de “ en marche ” peut englober la mise en service, les essais et l'exploitation productive, même si ces conditions ne devraient pas être analysées conjointement.

Les personnes les plus proches de la production sont donc indispensables. Les ingénieurs de données peuvent identifier les lacunes et les incohérences, mais ce sont les opérateurs, les spécialistes de la maintenance et les ingénieurs de procédés qui sont à même de déterminer si un signal est physiquement plausible et si son interprétation varie en fonction de conditions spécifiques.

Cette collaboration permet également d'éviter une erreur courante consistant à utiliser un ensemble de données statistiquement « propre » qui ne reflète pas correctement le processus. Le fait de supprimer une valeur aberrante apparente peut faire disparaître le premier signe d'un défaut, tandis que le calcul de la moyenne des mesures sur une période choisie de manière opportuniste peut masquer l'événement bref à l'origine d'un défaut.

La préparation à l'IA ne peut être certifiée par le seul service informatique. Elle dépend de la cohérence entre les données techniques et la réalité opérationnelle.

C'est la gouvernance qui détermine si l'on pourra se fier à ces données par la suite

Un modèle d'IA peut partir d'un ensemble de données soigneusement préparé, puis perdre progressivement de sa fiabilité à mesure que l'usine qui l'entoure évolue. Les capteurs sont remplacés, les recettes sont modifiées, les produits évoluent et les systèmes reçoivent des mises à jour logicielles, souvent sans que ces changements ne soient communiqués à l'équipe en charge du modèle.

Les fabricants doivent donc disposer d'une maîtrise claire des sources de données importantes. Quelqu'un doit savoir ce que signifie une variable, comment elle est générée et à quel moment sa définition change. L'historique des étalonnages, les périodes manquantes et les corrections manuelles doivent rester visibles et ne pas disparaître lors de la préparation.

La traçabilité est également importante. Lorsqu’un système d’IA recommande une intervention de maintenance ou identifie un risque lié à la qualité, les ingénieurs doivent savoir quelles données ont contribué à ce résultat et si ces données proviennent de sources fiables. Cela revêt une importance particulière lorsque la recommandation a des implications en matière de sécurité, de conformité ou de décision de production coûteuse.

Une base de données d'usine ne doit pas présenter une version idéalisée de la réalité, débarrassée de toute incertitude. Elle doit indiquer les cas où les informations sont incomplètes, estimées ou affectées par un changement d'équipement, afin que le modèle et ses utilisateurs puissent considérer les résultats avec la prudence qui s'impose.

Les sites industriels désaffectés nécessitent une approche sélective

Rares sont les fabricants capables de renouveler l'ensemble de leur infrastructure technologique avant de se lancer dans l'IA, et les usines bien établies disposent souvent de machines issues de plusieurs générations, ainsi que d'interfaces et de systèmes propriétaires qui n'ont jamais été conçus pour échanger des informations.

Attendre que la modernisation soit achevée reviendrait à repousser indéfiniment la mise en place d'applications utiles. Tenter de tout connecter d'un seul coup peut s'avérer tout aussi contre-productif, car le programme se transforme alors en un projet d'infrastructure coûteux sans retour opérationnel clair.

Une approche plus crédible commence par un problème de production dont la valeur économique est bien comprise. L'entreprise recense les données nécessaires à son analyse, identifie les lacunes les plus importantes et établit un contexte commun suffisamment solide pour prendre correctement en charge ce cas d'utilisation. Le travail doit tout de même respecter des normes et une architecture pouvant être étendues ultérieurement, mais il n'est pas nécessaire de résoudre toutes les incohérences historiques au sein de l'usine.

Par exemple, un fabricant cherchant à réduire les défauts sur une ligne de production peut, dans un premier temps, établir des liens entre les réglages des machines, les résultats qualité, les lots de matières premières et certains événements de maintenance. Une fois ces relations établies, cette même structure peut être étendue aux lignes adjacentes ou réutilisée dans le cadre de la maintenance prédictive.

Cela permet de constituer une base de données grâce à des avancées opérationnelles, plutôt que par le biais d'un programme de préparation de longue haleine dont la valeur reste abstraite.

Un « data lake » n'est pas synonyme de données accessibles

De nombreuses entreprises ont déjà regroupé d'importants volumes d'informations industrielles sur des plateformes cloud ou dans des référentiels centraux. Il s'agit là d'une étape importante, mais le simple fait de regrouper physiquement ces données ne les rend pas pour autant automatiquement compréhensibles ou exploitables.

Un « data lake » peut contenir des données provenant de tous les sites tout en conservant les mêmes incohérences dans la nomenclature, les relations manquantes et les incertitudes quant à la propriété des données qui existaient dans les systèmes d'origine. Les équipes disposent ainsi d'un espace centralisé pour effectuer leurs recherches, mais elles peuvent néanmoins passer des semaines à déterminer quels champs sont pertinents et si les différentes usines mesurent le même processus de manière comparable.

L'IA ne se contente pas d'un simple espace de stockage. Elle a besoin de données faciles à trouver, accessibles selon les autorisations appropriées, interopérables entre les systèmes et réutilisables, accompagnées d'une description suffisante pour préserver leur sens. Les modèles sémantiques, les graphes de connaissances et les « data fabrics » industriels sont de plus en plus utilisés pour représenter ces relations, même si la terminologie importe moins que la fonction qu'ils remplissent.

La couche utile est celle qui permet à un modèle de comprendre qu'un capteur donné appartient à une machine spécifique, que cette machine a effectué une opération sur un produit défini et que le composant ainsi obtenu a ensuite reçu une note de qualité particulière.

Siemens, par exemple, décrit les « data fabrics » industriels comme un moyen de relier des sources fragmentées et d'apporter le contexte nécessaire à l'IA, tandis que son architecture d'IA industrielle, plus large, relie la collecte de données en atelier à la contextualisation et à l'utilisation inter-domaines.

Les agents IA repoussent encore plus loin la barre

Un modèle prédictif qui génère une alerte de maintenance inexacte peut faire perdre du temps à un ingénieur. Un agent d'IA qui agit sur la base de données peu fiables peut entraîner un problème opérationnel bien plus grave.

Les agents sont conçus pour extraire des informations, raisonner à travers différents systèmes et déclencher des actions avec un minimum de supervision directe. Dans le secteur industriel, ils peuvent préparer des ordres de fabrication, ajuster les plannings, recommander des modifications de processus ou coordonner une intervention suite à un incident sur un équipement. Leur utilité dépend de leur accès à des informations qui ne doivent pas seulement être disponibles, mais aussi correctement mises en relation et suffisamment à jour.

Un agent qui constate une alarme sans savoir que la machine est en mode maintenance peut déclencher une intervention inutile. Un agent qui consulte une consigne de travail obsolète peut recommander une procédure qui n'est plus d'actualité, tandis que des identifiants d'actifs incohérents peuvent l'amener à consulter l'historique d'une machine erronée.

À mesure que l'IA industrielle gagne en autonomie, le coût d'un contexte insuffisant augmente. Une personne peut souvent se rendre compte qu'une information semble erronée parce qu'elle contredit son expérience ; un agent, quant à lui, peut poursuivre son chemin en toute confiance pendant plusieurs étapes, à moins que les données de base et les règles de fonctionnement ne mettent en évidence cette incohérence.

C'est pourquoi la préparation des données industrielles devient une question de confiance plutôt qu'une simple question d'accès technique. Les systèmes agentiques ont besoin d'un contexte fiable, tant au niveau des produits que des opérations, pour que les entreprises puissent leur permettre d'agir en toute confiance.

Commencez par la décision, pas par l'ensemble de données

Une évaluation pratique de l'état de préparation commence par le choix de la décision que l'entreprise souhaite améliorer. L'équipe doit préciser qui prend cette décision aujourd'hui, sur quelles informations cette personne s'appuie, ce qui constitue un résultat correct et quelles sont les conséquences d'une mauvaise décision.

Ce n'est qu'à ce moment-là que le fabricant doit vérifier si les données nécessaires existent, s'il est possible de les relier entre elles et si les exemples historiques sont représentatifs. Cela permet de distinguer une véritable lacune dans les données d'une lacune contextuelle, qui nécessite souvent une documentation et une intégration plutôt que l'ajout d'un capteur supplémentaire.

L'entreprise a également besoin d'une base de référence. Si l'objectif est de réduire les temps d'arrêt imprévus, elle doit connaître les temps d'arrêt actuels, l'effort de maintenance et les taux de fausses alarmes avant de mettre en place le modèle. Sans cette comparaison, un projet pilote d'IA pourrait s'avérer impressionnant sur le plan technique sans pour autant apporter d'amélioration mesurable aux opérations.

Le premier déploiement doit rester suffisamment proche de l'équipe de production pour permettre une analyse rapide des erreurs. Les ingénieurs et les opérateurs doivent pouvoir comprendre comment le modèle est parvenu à sa conclusion, remettre en question les hypothèses erronées et identifier les changements dans le processus que le pipeline de données n'a pas pris en compte.

Lorsque le cas d'utilisation s'avère utile, l'entreprise peut exploiter ces mêmes relations entre les données plutôt que de repartir de zéro. C'est ainsi que des informations industrielles isolées deviennent un atout réutilisable.

La préparation des données est une capacité opérationnelle

On conseille souvent aux usines de nettoyer leurs données avant d'adopter l'IA, comme si la préparation était un projet pouvant être mené à bien et clôturé. Or, les environnements industriels ne restent pas assez longtemps immuables pour que cette interprétation soit valable.

De nouvelles machines arrivent, les fournisseurs changent, les produits sont repensés et les opérateurs découvrent de meilleures façons de mener à bien le processus. Chaque modification altère la signification ou la pertinence de certaines données, ce qui signifie que la contextualisation, la gouvernance et le contrôle qualité doivent se poursuivre une fois que le modèle est mis en production.

Les entreprises les mieux placées pour développer l'IA industrielle ne seront pas nécessairement celles qui disposent des bases de données historiques les plus volumineuses. Ce seront celles qui savent d'où proviennent leurs informations opérationnelles, comment celles-ci s'articulent avec le processus physique et qui est responsable lorsque ces relations évoluent.

Une usine est prête pour l'IA lorsque ses données permettent de prendre une décision en laquelle les ingénieurs ont confiance, et non pas simplement parce qu'un tableau de bord indique que des millions d'enregistrements ont été collectés. Tant que ces signaux ne sont pas mis en relation avec les machines, les matériaux, les événements et les résultats, l'entreprise dispose certes d'une abondance de données, mais manque cruellement de connaissances.