Ce qu’il vaut vraiment la peine d’automatiser avec l’IA dans une usine

Ce qui décide du sort d’un projet d’IA en usine, ce n’est presque jamais la modélisation. C’est de nommer le type de problème que vous avez, de vérifier que vos données d’exécution peuvent le porter, et de concevoir ce qui se passe quand le modèle se trompe.

Règles, machine learning, optimisation et modèles de langage : à quel problème correspond quoi

Les règles et les statistiques viennent en premier, et méritent plus de respect qu’on ne leur en accorde. Si une règle qu’un ingénieur sait écrire capte l’essentiel de la valeur, la comparaison honnête pour n’importe quel modèle se fait contre cette règle, pas contre l’absence de solution.

Le machine learning gagne sa place là où la relation entre les entrées et le résultat est réelle mais que personne ne sait l’écrire : des dizaines de paramètres procédé qui interagissent, un défaut qui dépend du lot de matière, de l’hygrométrie ambiante et de la position dans l’empreinte. Il connaît les conditions qu’on lui a montrées et ne dit rien d’utile sur des conditions qu’il n’a jamais vues.

L’optimisation est une discipline différente, que l’on étiquette couramment à tort comme de l’IA. Ordonnancer une usine à capacité finie, séquencer pour minimiser les changements de série, affecter des opérateurs habilités : ce sont des problèmes sous contraintes avec une fonction objectif. Ils n’ont besoin d’aucun exemple étiqueté, mais ils exigent des temps de cycle et des contraintes honnêtes, qui doivent généralement être mesurés plutôt que supposés. Pour la planification, un solveur capable d’exprimer vos vraies contraintes d’outillage et de séchage est presque toujours le bon outil, car planifier est un problème de contraintes et non un problème de prédiction.

Les modèles de langage sont les derniers arrivés et leur domaine de pertinence est précis. Ils conviennent au travail qui a la forme d’un document ou d’une conversation : lire une demande entrante et en rédiger une version structurée, condenser un long historique de maintenance en quelque chose qu’un technicien peut lire avant de marcher jusqu’à la machine, répondre à ce qu’une instruction de travail dit d’un réglage. Ce ne sont pas des instruments de mesure : demander à un LLM de prédire la défaillance d’un roulement à partir de données vibratoires, c’est se servir d’un marteau pour visser.

Les données dont un projet d’IA en usine a réellement besoin

Un modèle a besoin d’exemples qui associent une situation à un résultat, avec assez de contexte pour distinguer une situation d’une autre : un signal ou un ensemble de conditions rattachés à un ordre de fabrication, une machine, un outil, un lot de matière, un opérateur, et un horodatage qui soit vrai. L’horodatage compte plus qu’on ne le croit. Si les déclarations sont saisies en fin d’équipe, tous les événements de cette équipe partagent une heure approximative, et tout ce qui dépend d’une séquence ou d’une durée apprend l’habitude de saisie plutôt que le procédé.

Du côté des résultats, c’est généralement pire. La maintenance prédictive a besoin de défaillances enregistrées comme des défaillances, avec une cause et une date, et non comme un arrêt non planifié dont le champ motif est vide. La prédiction qualité a besoin de rebuts déclarés sur l’opération et sur le type de défaut qui les a causés, pas agrégés dans un chiffre mensuel. La prévision a besoin d’un historique de consommation qui n’a pas été silencieusement réécrit par des corrections de stock. Dans la plupart des usines, les entrées vivent dans l’historian et les résultats dans un cahier de maintenance ou le tableur d’une seule personne.

Le test n’est pas le nombre de gigaoctets stockés dans l’historian, mais votre capacité à extraire, pour une ligne et une famille de produits, une année de lignes où chacune porte les conditions et le résultat, et où deux personnes qui connaissent le procédé s’accordent à dire que ces lignes sont justes. Si cette extraction demande une semaine de réconciliation manuelle, le projet n’est pas le modèle ; c’est l’enregistrement. C’est pourquoi la qualité des données du MES et de l’historian est la contrainte limitante, et aucune sophistication de modélisation ne rattrape ce qui n’a jamais été capté.

Prévision de la demande et des consommations, là où le retour est le plus proche

C’est en général la prévision qui a le chemin le plus court vers l’argent, parce que l’alternative est visiblement faible : la plupart des usines reprennent l’an dernier et ajoutent un pourcentage, ou demandent un chiffre aux ventes qui est en réalité un objectif. Un modèle utilisant l’historique de commandes, la saisonnalité, le mix clients, le pipeline ouvert et les effets calendaires bat cela sur les articles à demande régulière et répétitive. Sur les articles intermittents et pilotés par affaire, souvent la majorité des références et une faible part du volume, il ne le bat généralement pas, et une prévision de référence naïve ou de type Croston est difficile à battre. La version honnête commence par segmenter le catalogue et laisse ces articles à une politique de stock et au jugement.

La valeur apparaît en aval plutôt que dans la prévision elle-même : les stocks de sécurité bougent, le moment d’achat des articles à long délai d’approvisionnement change, et les changements de série en urgence qui ruinent un planning deviennent plus rares. Un pourcentage de précision de prévision sur une diapositive n’est pas un bénéfice ; la couverture de stock en jours et le nombre d’expéditions en urgence, oui.

Maintenance prédictive, uniquement là où le mode de défaillance est réellement prévisible

Tout repose ici sur le fait que la défaillance se développe progressivement et laisse une signature dans quelque chose de mesurable. Dégradation de roulement, balourd, désalignement, colmatage progressif d’un filtre ou d’un circuit de refroidissement, dérive de la pression hydraulique, courant moteur qui monte peu à peu sur la même opération : cela se développe sur des semaines ou des mois, parfois seulement des heures, ce qui est le plus souvent trop tard pour justifier une instrumentation, et se voit dans la vibration, le courant, la température ou la pression. Un modèle sait les voir, et souvent un seuil bien choisi aussi, raison pour laquelle la comparaison avec des statistiques simples compte particulièrement ici.

Une carte d’automate qui lâche, un outil cassé par une plaquette défectueuse, un dommage dû à une erreur d’opérateur : ces événements sont de fait instantanés, et aucun modèle ne les prédit à partir d’une tendance qui n’existe pas.

La deuxième condition est que l’alerte doit acheter du temps utilisable. Si la pièce a un long délai d’approvisionnement et que la ligne ne peut pas s’arrêter avant le week-end, l’investissement rentable est une politique de pièces de rechange, pas un modèle. Déterminez la fenêtre d’intervention avant le budget de capteurs.

Prédiction qualité et réduction des rebuts

La qualité est l’endroit où se trouve généralement le plus d’argent et où les exigences en données sont les plus fortes. La version séduisante prédit, à partir des conditions pendant la production, quelles pièces ou quels lots sont à risque, afin que quelqu’un puisse corriger avant que le rebut ne soit produit plutôt que de le découvrir au contrôle final.

Cela fonctionne quand le procédé est instrumenté à la résolution de ce que vous voulez prédire, et quand le rebut porte un vrai code cause rattaché à l’opération. Cela échoue silencieusement quand le rebut est déclaré en fin d’ordre de fabrication sur l’ordre dans son ensemble, car le modèle ne peut alors pas savoir quelles conditions ont produit quel défaut.

Une étape sans gloire se rembourse avant tout modèle : saisir les motifs de rebut à la machine, au moment où cela se produit, dans une courte liste de causes que l’opérateur reconnaît. Beaucoup d’usines qui demandent de la prédiction qualité découvrent à partir de ces seules données qu’un petit nombre de causes représente l’essentiel de la perte, et éliminent la plus grosse par une modification technique. C’est un bon résultat, pas un projet raté.

L’IA pour l’ordonnancement de production : pourquoi c’est un problème d’optimisation et non de prédiction

Si le plan dérape chaque semaine, la cause est rarement un manque d’intelligence et généralement un manque de contraintes. Ce qui change les choses, c’est un ordonnanceur qui respecte l’outillage partagé, les familles de changement de série, les habilitations des opérateurs, les temps de polymérisation et les fenêtres de maintenance que vous comptez tenir.

L’apprentissage aide ici d’une seule manière, étroite mais réelle : les temps de cycle. Un planning bâti sur des temps standards que personne n’a remesurés depuis des années est précis sur les mauvais chiffres, et les durées réelles captées par le MES peuvent mettre à jour ce avec quoi l’ordonnanceur planifie. Jugez une proposition d’ordonnancement sur les contraintes qu’elle sait exprimer et sur sa vitesse de replanification quand quelque chose casse ; un plan qui met une nuit à se régénérer se fait écraser à la main lors de la réunion du matin.

Détection d’anomalies sur les signaux énergétiques et procédé

La détection d’anomalies apprend à quoi ressemble le normal et signale l’écart. Elle convient aux signaux continus où vous disposez de beaucoup de bon comportement et de peu de défauts étiquetés : consommation électrique par cycle, consommation d’air comprimé, performance d’un groupe froid, un signal procédé dont la forme est stable quand tout va bien.

Sa force est de réagir à ce que personne n’avait anticipé. Sa faiblesse est qu’elle dit seulement que quelque chose est inhabituel, jamais ce qui ne va pas, et une usine qui reçoit des alertes inexpliquées apprend à les ignorer. Le travail de conception n’est pas le détecteur mais l’aiguillage : quelles alertes vont à qui, quelle est la première vérification, et comment la réponse est enregistrée pour que la prochaine alerte de même forme arrive avec son historique.

L’IA dans la vente et l’administration des ventes, là où le travail a la forme d’un document

Le versant commercial d’une entreprise industrielle tourne sur des documents et des conversations : demandes, cahiers des charges, devis, accusés de réception, questions de livraison, réclamations. C’est là que les modèles de langage s’insèrent vraiment, parce que le travail consiste à lire, extraire, rédiger et résumer.

Concrètement : une demande entrante analysée en référence, quantité, date souhaitée et exigences particulières, avec les devis précédents affichés à côté. Un fil d’e-mails condensé en une fiche CRM portant l’engagement pris et la prochaine action.

Deux règles empêchent que cela tourne mal. Le modèle rédige et une personne envoie, au moins tant que le taux d’erreur n’est pas connu dans ce flux de travail. Et tout ce qui est factuel, prix, délai, stock, date promise, vient du système de référence et non du modèle, qui doit citer une valeur retrouvée et jamais en générer une. Une automatisation CRM qui invente un délai est pire que rien, car elle engage l’entreprise.

Chiffrer le gain avant d’acheter quoi que ce soit

Nommez la perte dans des unités que votre usine suit déjà : coût de rebut mensuel sur la famille de produits concernée, heures d’arrêt non planifié sur la machine goulot multipliées par ce que vaut une heure à cet endroit en marge sur coût variable plutôt qu’en taux horaire machine, transport en urgence, stock immobilisé dans les articles qu’une prévision ferait bouger, heures par semaine passées à ressaisir d’un système à l’autre.

Estimez ensuite, de façon pessimiste, quelle part de cette perte l’application pourrait plausiblement adresser. La maintenance prédictive n’élimine pas les arrêts ; au mieux elle convertit une partie des arrêts non planifiés en arrêts planifiés, pour les modes de défaillance qu’elle couvre. Un modèle qualité ne supprime pas le rebut ; il raccourcit le temps entre le moment où un procédé dérive et celui où quelqu’un s’en aperçoit.

Si ce chiffre honnête, rapporté à un coût complet sur la durée de vie que vous prévoiriez réellement, intégration et personnes qui feront tourner le système comprises, ne franchit pas le seuil que votre direction financière applique à tout autre investissement de cette taille, le projet est une expérience scientifique. C’est permis, mais il faut alors le financer et le juger comme tel.

Ce que coûte vraiment l’intégration

Le modèle est en général la partie bon marché ; le coût se loge dans les raccords. Récupérer les signaux sur les machines vient d’abord, et un parc réel est hétérogène : certains équipements parlent OPC UA, d’autres Modbus ou un protocole série, certains offrent un contact sec, et certains automates fermés exigent un capteur rétrofité sur la broche, le circuit hydraulique ou la ligne d’alimentation. Ensuite, la sortie doit atterrir quelque part qui déclenche une action : un écran que l’opérateur regarde déjà, un bon de travail créé en maintenance, une contrainte transmise à l’ordonnanceur, un blocage posé en qualité.

Vient ensuite la réconciliation des données de référence que personne ne chiffre. Des références qui diffèrent d’un suffixe d’un système à l’autre, des unités de mesure qui ne correspondent pas, une nomenclature tenue à deux endroits, des identifiants machine qui ont changé quand la ligne a été réimplantée. Rien de tout cela n’est difficile et tout cela prend plus de temps que le logiciel. Une proposition qui chiffre le modèle et laisse les raccords en « intégration à cadrer » n’est pas un prix.

Qui exploite le modèle, et que se passe-t-il quand il se trompe

Tout modèle déployé a besoin d’un responsable nommé, et la question à poser en achat est qui, dans votre organisation, ce sera. Cette personne doit savoir sur quoi il a été entraîné, quelles conditions sortent de ce périmètre, pourquoi il a produit une sortie donnée, et comment le retirer de la boucle sans arrêter la production. Un modèle qui cesse de répondre doit retomber sur ce qui pilotait le procédé avant lui, le plan d’échantillonnage, le seuil, le contrôle opérateur, et non sur une porte ouverte ou une ligne bloquée. Décidez lequel des deux avant la mise en service.

L’explicabilité n’est pas une préoccupation philosophique en atelier, c’est une condition d’adoption. Une recommandation qui dit quel signal a bougé, de combien, et par rapport à quelle référence, est suivie d’effet. Un score sans justification se fait écraser, et dès lors que l’écrasement devient routinier, le système est de la décoration.

Le trop-plein d’alertes détruit la confiance plus vite que les détections manquées, pour la même raison que le sur-rejet sur un poste de contrôle : une fausse alerte est visible immédiatement et de tous, un défaut échappé reste invisible jusqu’à la défaillance. Dimensionnez le taux d’alertes sur l’attention réellement disponible en atelier, et aiguillez la bande d’incertitude vers une personne, pas vers la ligne.

Gouvernance, dérive et la charge d’entretien que personne ne budgète

Un modèle est un instantané de votre procédé au moment où il a été entraîné, et votre procédé bouge : un nouveau fournisseur, un outil rénové, une révision de pièce, une réimplantation de ligne, un mix produits modifié, un capteur remplacé par un autre légèrement différent. Chacun peut décaler les entrées au point que le modèle d’hier soit discrètement faux aujourd’hui, et le mode de défaillance n’est pas un message d’erreur mais des conseils progressivement moins bons.

Surveillez les entrées autant que les sorties, car la dérive des entrées se voit avant la dégradation des résultats. Conservez un jeu de test de cas réels mis de côté, cas limites compris, pour qu’un nouveau modèle puisse être comparé honnêtement à celui en service. Versionnez le modèle et enregistrez quelle version a produit quelle recommandation ; après un réentraînement, les sorties d’hier viennent d’un autre juge.

Et budgétez l’effort récurrent. Un modèle en production est un actif entretenu, plus proche d’un équipement de production que d’un rapport acheté. Si personne n’a de temps alloué au réentraînement, à la revue des alertes et à la vérification que les données arrivent toujours, il se dégradera jusqu’à ce que plus personne ne l’utilise.

Un premier projet réaliste, avec des critères de recette

Choisissez une perte nommée sur une ligne ou une famille de produits, énoncée comme une phrase contenant un chiffre : nous rebutons tant sur cette opération, nous perdons tant d’heures de goulot sur cette machine, nous portons tant de stock parce que nous ne savons pas prévoir cette famille. Si le projet ne peut pas être énoncé ainsi, il n’est pas prêt.

Avant d’acheter quoi que ce soit, faites l’extraction de données. Une année, une ligne, conditions et résultats sur les mêmes lignes, deux personnes qui connaissent le procédé confirmant qu’elles sont justes. Puis comparez à l’alternative simple : un seuil, une carte de contrôle, ou le jugement du planificateur actuel.

Écrivez les critères de recette en unités d’usine avant la mise en service, par paires, pour que l’arbitrage soit explicite. Pour la maintenance prédictive, un nombre annoncé de modes de défaillance couverts détectés avec au moins une semaine d’avance, contre un nombre plafonné de fausses alertes par mois. Pour la prévision, une réduction annoncée de la couverture de stock en jours sur les familles modélisées sans augmentation des ruptures. Pour la qualité, une réduction annoncée du rebut sur l’opération visée par rapport aux mêmes mois l’an dernier, avec les modifications de procédé consignées à côté.

Nommez le responsable, le comportement en cas de défaillance et le calendrier de réentraînement dans le même document, et fixez une date de revue avec une option honnête d’arrêter. Un premier projet qui se termine par une décision de ne pas étendre, prise sur des faits, est un succès. Un pilote qui devient une démonstration permanente n’en est pas un.

Où Meta Smart Factory s’inscrit

Meta Smart Factory est modulaire, et cela compte ici parce que le module IA et machine learning se pose au-dessus de la couche d’exécution plutôt qu’à côté d’elle. Le MES fournit les événements et le contexte, la connectivité IIoT et OPC UA fournit les signaux machines, la Qualité fournit les rebuts avec leurs causes, la Maintenance fournit l’historique des défaillances, et l’APS consomme la sortie quand la réponse est un planning plutôt qu’une prédiction.

Vous pouvez commencer par un module face à une contrainte nommée et ajouter le suivant une fois le premier réellement utilisé. Ce qu’aucune plateforme ne supprime, c’est la partie difficile : se mettre d’accord sur le sens des chiffres, faire saisir les causes à la machine, et décider qui est responsable d’un modèle quand il se trompe. Parler de cet enchaînement pour une usine précise est une première conversation plus utile qu’une démonstration, car une démonstration fonctionne toujours.