Maintenance prédictive IA : sécuriser une fab côté DSI

1 000 particules par mètre cube au maximum, de taille supérieure ou égale à 0,1 µm : limite de la classe ISO 3 selon le tableau 1 de la norme ISO 14644-1:2015.

Cette valeur situe l’exigence de propreté d’une salle blanche ISO 3. Elle ne décrit ni la disponibilité des équipements ni la qualité du vide dans une chambre de procédé : une fab peut respecter sa classification particulaire et subir une dérive machine qui compromet la stabilité d’une opération de lithographie.

Le risque reste discret. Dans une fab optique / semi-conducteurs utilisant une étape de lithographie sous vide, une pompe peut continuer à fonctionner alors que le temps nécessaire pour atteindre la pression attendue augmente progressivement. La maintenance prédictive IA, fondée sur l’intelligence artificielle, doit permettre d’examiner cette dérive avant qu’elle impose un arrêt, sans ouvrir une nouvelle brèche informatique dans l’installation.

La dérive du vide, un sujet commun à la maintenance et à la DSI

Concentrons-nous sur ce seul problème : un groupe de pompage perd progressivement sa capacité à établir le vide attendu. La difficulté consiste à distinguer une dégradation réelle d’un changement normal de conditions opératoires.

Une courbe de pression ne suffit pas. Le comportement observé dépend notamment de la recette, de l’état initial de la chambre et de la séquence de chargement des wafers, ces fines tranches de matériau utilisées comme substrats de fabrication.

Pour le responsable de production, la question est de savoir si le prochain lot pourra passer dans des conditions maîtrisées. Pour le technicien, il faut déterminer ce qui justifie une vérification de la pompe plutôt qu’une recherche de fuite ou un contrôle du capteur.

Le directeur des systèmes d’information, ou DSI, intervient sur la disponibilité et la circulation des données. Le responsable de la sécurité des systèmes d’information, ou RSSI, doit s’assurer que cette circulation ne compromet ni la commande des équipements ni la confidentialité des recettes.

Leur intérêt est commun : une alerte exploitable, issue d’un dispositif qui ne perturbe pas le procédé. Le modèle ne doit jamais devenir un passage obligé pour faire fonctionner la machine.

Avant l’algorithme, établir une référence comparable

La première étape n’est pas l’achat de capteurs. C’est la définition d’un cycle de pompage normal, avec les équipes procédé, maintenance et le constructeur lorsque son intervention est nécessaire.

Comparer des séquences réellement comparables

Je propose de commencer par un diagnostic des historiques disponibles. Il faut relier les courbes de pression aux états machine et aux interventions, puis vérifier si les cycles peuvent être regroupés par conditions opératoires suffisamment proches.

Un simple identifiant de famille de recette peut parfois suffire. Il évite alors d’exposer au système d’analyse les paramètres confidentiels du procédé, à condition que ce regroupement conserve les différences utiles au diagnostic.

On peut ensuite examiner le temps d’atteinte d’un seuil de pression validé par l’équipe procédé. Selon l’instrumentation disponible, la température ou le courant du groupe de pompage peuvent compléter cette lecture, sans devenir des preuves isolées de défaillance.

Vérifier la donnée avant de lui faire confiance

Un décalage d’horodatage fausse les rapprochements. Une mesure figée peut, elle, donner l’illusion d’une stabilité parfaite alors que l’équipement évolue réellement.

L’état du capteur, les unités, la fréquence d’acquisition et les périodes manquantes doivent donc être documentés. Ce travail de maintenance industrielle précède le choix du modèle : une donnée douteuse doit produire un signal de qualité insuffisante, pas une recommandation assurée.

Il faut aussi consigner les changements techniques. Après remplacement d’une pompe ou modification approuvée du procédé, l’ancienne référence peut devenir inadaptée sans qu’une nouvelle panne soit en cause.

Une architecture prédictive qui ne commande pas la machine

La sécurité ne se résume pas au chiffrement. Dans les systèmes OT, c’est-à-dire les technologies opérationnelles qui surveillent et pilotent les équipements industriels, l’architecture doit d’abord limiter les chemins susceptibles d’atteindre la commande.

Collecter sans créer un accès de retour incontrôlé

La méthode que j’appliquerais privilégie une collecte à partir d’une interface approuvée par le constructeur ou d’un historien existant. Ajouter des requêtes directement sur un contrôleur sans vérifier leur charge et leur compatibilité serait une mauvaise première étape.

Le chemin de collecte mérite un examen précis. Une interface présentée comme étant « en lecture seule » ne garantit pas, à elle seule, une séparation réseau suffisante.

Une zone intermédiaire dédiée, des flux explicitement autorisés et des comptes distincts réduisent l’exposition. Le système d’analyse n’a pas besoin de pouvoir modifier une consigne de vide pour détecter une dérive.

La série IEC 62443, consacrée à la cybersécurité des systèmes d’automatisation et de contrôle industriels, fournit un cadre utile pour raisonner en zones et conduits. Son emploi doit être adapté au périmètre réel, sans présenter l’installation d’une passerelle comme une certification globale.

Maintenir le service lorsque la liaison tombe

Pour une entreprise implantant ou exploitant une fab en Afrique, le choix entre calcul local et service distant dépend du site concerné. La qualité de la connectivité, les conditions de support et les règles de transfert des données doivent être vérifiées, jamais supposées à partir du seul pays.

Une interruption de liaison doit rester tolérable. Une analyse locale et un stockage tampon dimensionné peuvent préserver l’observation, tandis que les automatismes et protections existants restent autonomes.

Le RSSI devra également examiner l’accès du prestataire : autorisation nominative, durée limitée et journalisation des actions. Les exigences de localisation ou de transfert transfrontalier des données sont à confirmer selon le droit applicable et les contrats, notamment lorsque les informations révèlent des capacités de production sensibles.

Cas hypothétique : une alerte avant le prochain lot

Imaginons une fab optique / semi-conducteurs située sur un site africain, avec une salle blanche ISO 3 et un équipement de lithographie électronique sous vide. Ce cas est hypothétique ; il illustre une démarche, pas une mission réalisée.

Le groupe de pompage atteint encore la pression requise. Pourtant, sur des séquences comparables, son temps de descente en pression s’écarte progressivement de la référence.

Le système détecte cette évolution. Il vérifie d’abord la qualité des mesures et le contexte de recette, puis présente au technicien les cycles concernés et les signaux qui contribuent à l’alerte.

Il ne conclut pas automatiquement : « pompe à remplacer ». Une fuite, un dégazage inhabituel ou un défaut de mesure peuvent produire une évolution voisine et nécessitent des vérifications différentes.

Le technicien dispose alors d’une orientation de contrôle à confronter aux procédures du constructeur. L’équipe procédé évalue, de son côté, si les conditions restent acceptables pour le lot suivant.

La disponibilité d’une pièce modifie l’arbitrage. Si l’approvisionnement du groupe de remplacement dépend d’une importation longue sur ce site, l’anticipation sert à préparer l’intervention et à discuter du calendrier de production, jamais à autoriser un fonctionnement hors limites validées.

La classification ISO 3 reste un sujet distinct. Elle ne prouve pas que le vide est conforme ; toute intervention doit néanmoins respecter les procédures de propreté et de remise en service applicables à la zone concernée.

Mesurer l’utilité de l’IA, pas seulement sa précision

Une alerte techniquement correcte peut arriver trop tard. Une autre, répétée sans explication, peut être ignorée même lorsqu’elle signale une véritable anomalie.

Le pilote doit donc commencer en mode observation, sans action automatique sur l’équipement. Les alertes sont confrontées aux contrôles terrain et aux décisions prises, avec une trace des hypothèses confirmées ou écartées.

Trois critères méritent une attention particulière : le nombre d’alertes injustifiées, le délai utile laissé aux équipes et la capacité à expliquer la recommandation. Une note de performance globale du modèle ne remplace pas ces observations.

Il faut aussi éviter un piège méthodologique. Mélanger aléatoirement des cycles voisins entre apprentissage et évaluation peut donner une impression trompeuse de robustesse ; une validation sur une période ultérieure est généralement plus proche de l’usage réel.

Les pannes documentées peuvent être rares. Dans ce cas, détecter un écart au fonctionnement habituel est souvent plus défendable que promettre une durée de vie restante précise.

Mes sept années d’expérience dans différents environnements industriels nourrissent une conviction : la valeur d’une prédiction tient à la décision qu’elle permet de préparer. Je préfère une dérive clairement expliquée et vérifiable à une date de panne calculée avec une assurance que les données ne justifient pas.

De la GMAO à une décision documentée avec TENGENN LMAI®

La GMAO, gestion de maintenance assistée par ordinateur, organise les interventions, les pièces et leur historique. Elle reste indispensable, mais son seul enregistrement des travaux ne permet pas nécessairement de rapprocher une dérive de pression, un contexte de cycle et une hypothèse technique.

Certaines GMAO disposent de modules analytiques. La distinction utile ne porte donc pas uniquement sur le nom du logiciel, mais sur sa capacité à transformer les observations en diagnostic vérifiable et en décision préparée.

C’est dans cette continuité que s’inscrit TENGENN LMAI®, la solution logicielle intégrant l’IA que je porte. L’approche LMAI® vise à compléter l’organisation de la maintenance par le diagnostic, l’anticipation et l’aide à la décision, avec des fonctions à valider selon les données et les interfaces accessibles sur le site.

Pour notre groupe de pompage, l’objectif serait de relier l’alerte aux éléments qui la justifient, puis aux vérifications et à l’intervention retenues. La comparaison GMAO vs LMAI® éclaire cette complémentarité ; elle ne justifie pas de remplacer un outil existant qui remplit correctement son rôle.

Je peux accompagner le diagnostic des données et du fonctionnement du pompage, puis le cadrage d’un pilote sécurisé avec vos équipes. L’intégration de notre solution TENGENN LMAI® se discuterait ensuite sur cette base, avec des critères d’acceptation et un responsable clairement désigné pour chaque décision.

Questions fréquentes

Faut-il ajouter des capteurs sur tout le groupe de pompage ?

Pas systématiquement. Les courbes de pression et les états machine existants peuvent permettre un premier travail, à condition que leur qualité et leur résolution conviennent à la dérive recherchée.

Un capteur supplémentaire doit répondre à une incertitude identifiée. Son installation doit aussi être compatible avec l’équipement, les procédures de propreté et les prescriptions du constructeur.

L’IA peut-elle arrêter automatiquement la lithographie ?

Ce n’est pas l’objectif du pilote proposé. L’analyse prédictive conseille les équipes ; les protections et automatismes validés conservent leurs fonctions.

Toute action automatique ultérieure demanderait une étude spécifique des risques et une validation formelle. Une alerte probabiliste ne devient pas, par simple paramétrage, une fonction de protection.

Peut-on démarrer sans historique de panne exploitable ?

Oui, en limitant la promesse. Une référence de fonctionnement sain peut aider à repérer des écarts, mais elle ne suffit pas à identifier toutes les causes ni à calculer une échéance fiable de défaillance.

Le retour du technicien devient alors essentiel pour qualifier les alertes et enrichir progressivement la connaissance. C’est ainsi que le pilote gagne en crédibilité, sans transformer chaque anomalie en arrêt prescrit.

Vous observez une dérive des temps de pompage sur une étape de lithographie, sans savoir quelles données exploiter ni comment les sortir de la zone machine ? Contactez-moi directement sur mon profil LinkedIn, Eries Emmanuel Dianou : je vous propose un échange pour cadrer les vérifications utiles et les conditions d’un pilote compatible avec votre fab.