Maintenance prédictive ponts roulants : fédéré sans transfert
Maintenance prédictive des ponts roulants par apprentissage fédéré
Les données vibratoires des ponts roulants de trois aciéries (usines A, B et C, chacune équipée de 50 ponts) ne peuvent pas être centralisées sur un serveur unique pour l'entraînement, en raison des exigences de conformité des données et de confidentialité des procédés. L'approche d'apprentissage fédéré retenue : chaque usine entraîne localement un modèle prédictif LSTM sur son serveur GPU, puis transmet uniquement 512 Ko de poids de modèle au serveur central à chaque itération. Le serveur agrège les mises à jour via l'algorithme FedAvg et les redistribue. Après 100 itérations de communication, le modèle converge avec un F1 = 0,91, proche du score F1 = 0,93 obtenu par un entraînement centralisé (écart de seulement 2 %). En revanche, un entraînement indépendant sur une seule usine (données de 50 ponts) n'atteint qu'un F1 = 0,85. L'apprentissage fédéré améliore donc le F1 de 0,85 à 0,91 tout en préservant la confidentialité des données.
Les modèles de maintenance prédictive des ponts roulants reposent sur de vastes ensembles de données couvrant diverses conditions de fonctionnement et modes de défaillance. Or, dans la pratique, un utilisateur de ponts roulants (usine) ne dispose généralement que de 20 à 80 appareils, un volume insuffisant pour entraîner un modèle prédictif LSTM RUL de haute précision (F1 ≈ 0,85 pour une usine isolée). La centralisation des données de plusieurs usines pour l'entraînement améliore certes la précision (F1 = 0,93), mais se heurte aux exigences réglementaires de sortie des données (loi sur la sécurité des données, loi sur la protection des informations personnelles) ainsi qu'aux impératifs de confidentialité des procédés de fabrication. L'apprentissage fédéré (Federated Learning, FL) permet une collaboration multi-usines selon le principe « les données ne se déplacent pas, seuls les modèles circulent ». Environnement expérimental : PyTorch 2.1.0 + framework Flower 1.7.0, 3 clients équipés chacun d'une RTX 4090, et un serveur central sur CPU.
Déroulement de l'apprentissage fédéré
L'algorithme FedAvg (moyenne fédérée) est utilisé : à l'itération t, ① le serveur central distribue le modèle global W_t aux 3 clients ; ② chaque client entraîne le modèle sur ses données locales pendant E = 5 époques (Batch = 64, lr = 0,001, optimiseur SGD) et obtient la mise à jour ΔW_i ; ③ le client transmet ΔW_i (uniquement les incréments de poids, 512 Ko/fois) au serveur central ; ④ le serveur calcule W_{t+1} = W_t + ∑(n_i/N)·ΔW_i (n_i étant le volume de données du client i, N le volume total) ; ⑤ le processus est répété sur T = 100 itérations. Le temps de communication par itération est d'environ 2 secondes (transfert réseau + entraînement local), soit un temps total d'environ 8 minutes pour les 100 itérations.
Comparaison des précisions
| Schéma | Volume de données | F1Score | MAPE | Données hors site | Volume de transfert |
|---|---|---|---|---|---|
| Indépendant par usine (Usine A) | 50 appareils × 24 mois | 0.85 | 18.2% | Non | 0 |
| Centralisé(Agrégation de trois usines) | 150 appareils × 24 mois | 0.93 | 14.3% | Oui(Données complètes) | TBNiveau |
| Apprentissage fédéré(Trois usines FL) | 150Unité×24Mois | 0.91 | 15.1% | Non(Poids uniquement) | ~50MB |
| Apprentissage fédéré(Non IID+Amélioré) | 150Unité×24Mois | 0.92 | 14.8% | Non(Poids uniquement) | ~50MB |
L'apprentissage fédéré atteint un F1 de 0,91 contre 0,93 pour l'approche centralisée, soit un écart de seulement 2 %. En appliquant une stratégie d'optimisation non-IID (lorsque les distributions de données varient d'une usine à l'autre, un terme proximal est ajouté à la fonction de perte locale, conformément à l'algorithme FedProx), le F1 s'améliore à 0,92. L'entraînement isolé d'une seule usine donne un F1 de 0,85 ; l'apprentissage fédéré a donc gagné 0,06 point (6 points de pourcentage), offrant une précision proche de celle de l'approche centralisée tout en préservant la confidentialité des données.
Données non-IID : défis et solutions
Le défi central de l'apprentissage fédéré réside dans les données non-IID (non indépendantes et identiquement distribuées) : les modèles de ponts roulants, les conditions de fonctionnement et les distributions de pannes varient d'une usine à l'autre (l'usine A présente principalement une dégradation des roulements dans l'atelier de laminage à chaud ; l'usine B, de la piqûre sur les engrenages dans l'atelier de laminage à froid ; l'usine C, des pannes à haute température dans l'atelier de coulée). L'algorithme FedAvg standard converge lentement dans un scénario non-IID (150 tours nécessaires contre 80 en contexte IID), et le F1 du modèle global chute de 0,91 à 0,87. Solutions adoptées : ① micro-ajustement local — après transmission du modèle global, un entraînement supplémentaire de 5 époques est effectué côté client (adaptation aux décalages de distribution) ; ② augmentation des données — les clients partagent les statistiques de distribution des caractéristiques (sans partager les données) afin d'aligner les espaces de représentation. Grâce à ces mesures, le F1 en contexte non-IID remonte à 0,90.
Optimisation de l'efficacité de communication
Le coût de communication constitue le principal goulot d'étranglement pour le déploiement pratique de l'apprentissage fédéré. Le volume de données transmises passe de l'ordre du téraoctet en approche centralisée à 50 Mo en apprentissage fédéré (100 tours × 512 Ko), mais une optimisation reste nécessaire sur les sites industriels à bande passante limitée (réseau public 4G avec un débit montant d'environ 10 Mbit/s). Comparaison pratique de quatre stratégies d'optimisation :
| Stratégie d | Volume de communication/Itération | F1Score | F1Perte | Domaine d'application |
|---|---|---|---|---|
| Baseline(FP32Gradient complet) | 512KB | 0.910 | Référence | Bonnes conditions réseau(Réseau industriel dédié) |
| Top-k Sparsification(k=10%) | 51KB | 0.907 | -0.003 | Bande passante limitée(4G/5GRéseau public) |
| INT8Quantification | 128KB | 0.909 | -0.001 | Bande passante limitée mais acceptable FP16 |
| Local Epoch=10(60Itération) | 512KB | 0.902 | -0.008 | Latence réseau élevée(Interprovincial) |
| Fed Async Asynchrone Agrégation | 512KB | 0.884 | -0.026 | Clients hétérogènes(Déconnexions fréquentes) |
Recommandation : combinaison de la quantification INT8 (128 Ko/tour, perte de F1 de 0,1 %) et d'un entraînement local sur 10 époques (60 tours, perte de F1 de 0,8 %). Le volume de communication est réduit à 25 % de la référence, pour un F1 global de 0,90.
Protection de la vie privée par confidentialité différentielle
Même en ne transmettant que les gradients du modèle plutôt que les données brutes, le risque d'attaque par fuite de gradients subsiste (Deep Leakage from Gradients, Zhu et al., 2019). La confidentialité différentielle (DP) y remédie en ajoutant un bruit gaussien aux gradients : perturbed_grad = clip(grad, C) + N(0, sigma^2 * C^2 * I). Dans cette expérience, le clipping des gradients est fixé à C = 1,0 et l'écart type du bruit à sigma = 0,01, ce qui correspond à un budget de confidentialité epsilon = 8 (référence ISO/IEC 27701, un epsilon ≤ 10 étant jugé acceptable). Le DP-SGD fait passer le F1 de 0,91 à 0,89 (soit une perte de 2 %), en échange d'une garantie de confidentialité démontrable.
Validation en conditions réelles d'exploitation
Projet d'apprentissage fédéré pour la maintenance prédictive des ponts roulants mené auprès de trois filiales d'un groupe sidérurgique (usines A, B et C), référence KL-FL-2024-001, de mars 2025 à mars 2026. Chaque usine a équipé 50 ponts roulants de capteurs PCB 352C33, de passerelles KL-EDGE-200 et de modèles LSTM. Après la mise en service de l'apprentissage fédéré : le F1 de prédiction du RUL à l'usine A passe de 0,83 à 0,90 (+7 pts), à l'usine B de 0,87 à 0,91 (+4 pts), et à l'usine C (où les pannes haute température en coulée sont rares) de 0,79 à 0,88 (+9 pts). C'est à l'usine C que l'amélioration est la plus marquée, grâce aux données de dégradation des roulements et des engrenages fournies par les usines A et B, qui ont permis de compléter les modes de défaillance à haute température. L'entraînement centralisé (en supposant les données regroupables) atteint un F1 de 0,93 ; l'apprentissage fédéré n'accuse qu'un écart de précision de 2 % tout en garantissant la conformité réglementaire, les données ne quittant jamais l'usine.
Comparaison complète : apprentissage fédéré, centralisé et mono-site
| Critère de comparaison | Indépendant par usine | Entraînement centralisé | Apprentissage fédéré Fed Avg | Fédéré+DP(epsilon=8) |
|---|---|---|---|---|
| F1Score | 0.85 | 0.93 | 0.91 | 0.89 |
| Données hors site | Non | Oui(TBNiveau) | Non(Poids uniquement) | Non(Poids bruités) |
| Risque de conformité | Aucun | Élevé (Loi sur la sécurité des données) | Faible | Minimal(Prouvable) |
| Volume de transfert | 0 | TBNiveau | 50MB | 50MB |
| Durée totale d'entraînement | 15min | 45min | ~8min(Communication) | ~9min |
| Exigences matérielles | GPU d'usine unique | Cluster GPU central | GPU propre à chaque usine | Propre à chaque usine GPU |
| Domaine d'application | Usine unique avec données suffisantes | Données centralisables | Données non exportables | Exigences de conformité élevées |
Questions fréquentes
Q : Mon usine ne dispose que de 10 ponts roulants : l'apprentissage fédéré a-t-il un intérêt avec si peu de données ?
A : Oui. Même avec un volume de données réduit (10 appareils), la participation à l'apprentissage fédéré reste bénéfique. Le modèle global exploite les données multi-sites pour identifier des schémas de dégradation génériques, tandis que le fine-tuning local sur le client à faible volume adapte le modèle générique aux équipements spécifiques. Dans les tests étendus de cette expérience : un site avec 10 appareils (F1=0,72) atteint F1=0,87 après intégration à l'apprentissage fédéré, soit un gain de 15 points.
Q : Comment la sécurité des communications est-elle garantie dans l'apprentissage fédéré ?
A : Les mesures de sécurité suivantes sont recommandées : ① Chiffrement des gradients — utilisation du DP-SGD (ε=8) avec ajout de bruit gaussien (σ=0,01) avant l'envoi des poids, afin de prévenir les attaques par fuite de gradients ; ② Chiffrement des communications — TLS 1.3 pour empêcher toute interception ; ③ Authentification des clients — certificats x.509 en reconnaissance mutuelle, seuls les clients autorisés participent à l'agrégation.
Q : Que se passe-t-il si le réseau d'une usine est instable et que la connexion est interrompue en cours de route ?
A : Le framework Flower prend en charge l'agrégation asynchrone (FedAsync) et un mécanisme de tolérance aux pannes : le serveur central applique un délai d'attente (60 secondes par défaut), puis ignore le client défaillant et poursuit l'agrégation avec les mises à jour des autres clients. Le client déconnecté peut demander le dernier modèle global à sa reconnexion. Dans cette expérience, une déconnexion aléatoire d'un client (probabilité de 10 %) a été simulée : le F1 final passe de 0,91 à 0,88 (perte de 3 %), ce qui reste supérieur au 0,85 obtenu en mode indépendant.
Q : Le déploiement de l'apprentissage fédéré impose-t-il une plateforme matérielle uniforme entre les usines ?
A : Non. Le framework Flower prend en charge les clients hétérogènes (Linux/Windows, GPU/CPU, PyTorch/TensorFlow). Chaque usine s'entraîne avec son propre matériel : usine A avec RTX 4090 (3 min/cycle), usine B avec RTX 3060 (5 min/cycle), usine C avec CPU (15 min/cycle). Le serveur central applique une stratégie d'agrégation synchrone basée sur « le client le plus rapide + 30 % d'attente ».
