RGPD et IoT industriel : ce que les équipes de maintenance prédictive doivent savoir

L'angle mort de la conformité

Vos capteurs de vibration ne collectent pas de données personnelles — vraiment ?

La plupart des ingénieurs d'atelier considèrent le RGPD comme un problème marketing et RH. Mais dès que votre système de maintenance prédictive enregistre des actions d'opérateurs, des schémas d'équipe, des affectations d'équipements liées au personnel ou même des adresses IP provenant de passerelles IoT, vous traitez des données personnelles au sens de l'Article 4 du RGPD.

Une enquête 2025 du Comité européen de la protection des données a révélé que 43 % des déploiements IoT industriels présentaient au moins une lacune de conformité RGPD dont ils n'avaient pas conscience. Les amendes ne sont pas théoriques : un fabricant allemand a été sanctionné de 1,2 M€ en 2025 pour un système de surveillance qui suivait les performances individuelles des opérateurs sans consentement approprié.

Où la PdM rencontre les données personnelles

Voici ce qui compte réellement comme données personnelles dans un contexte de maintenance prédictive :

Clairement personnel

Identifiants de connexion des opérateurs et journaux de session
Registres d'affectation d'équipes liés à des individus
Affectations d'ordres de travail (« L'Opérateur Schmidt a remplacé le roulement de l'Actif 41 »)
Jetons de notification push des applications mobiles
Adresses e-mail pour le routage des alertes

La zone grise

Paramètres de fonctionnement des machines pendant des équipes spécifiques (peuvent identifier les opérateurs indirectement)
Journaux de maintenance avec noms de techniciens
Registres de badges d'accès corrélés aux événements d'équipement
Flux vidéo de zones de machines (même si destinés à la surveillance des équipements)

Pas des données personnelles

Lectures brutes de vibration, température, pression provenant des capteurs
Prédictions des modèles ML et scores d'anomalie
Indices de santé des équipements
Métriques de production agrégées

Six principes pour une PdM conforme au RGPD

1. Minimisation des données — collecter ce qui est nécessaire

Le principe : Ne traiter que les données personnelles adéquates, pertinentes et limitées à ce qui est nécessaire (Article 5(1)(c)).

En pratique :

Les données de capteurs n'ont pas besoin d'une attribution d'opérateur. Une lecture vibratoire de la Pompe 7A concerne la pompe, pas la personne qui la fait fonctionner.
Si votre intégration GMAO intègre des noms d'opérateurs dans les ordres de travail, décidez : avez-vous besoin du nom pour la PdM, ou simplement du fait que la maintenance a été effectuée ?
Supprimez les adresses IP des journaux de connexion MQTT/OPC-UA sauf si vous en avez besoin pour l'audit de sécurité.

L'approche de Prevly : Les lectures de capteurs sont stockées uniquement avec asset_id et tenant_id. Aucune identité d'opérateur n'est attachée aux données de séries temporelles. Les ordres de travail référencent des rôles, pas des individus, sauf si le client active explicitement le suivi du personnel.

2. Limitation de la finalité — définir le pourquoi

Les données de capteurs collectées à des fins de maintenance prédictive ne peuvent pas être réutilisées pour la surveillance des performances des opérateurs sans une base juridique séparée. Cela semble évident, mais cela se produit constamment quand :

Un responsable d'usine demande « quelle équipe a le plus de défaillances d'équipements ? »
Les RH demandent des journaux de maintenance pour évaluer les temps de réponse des techniciens
Une assurance veut des données d'incidents au niveau des opérateurs

Bonne pratique : Documentez vos finalités de traitement dans un Registre des Activités de Traitement (RAT) avant le déploiement. L'accord de traitement des données (DPA) de Prevly limite explicitement le traitement à la prédiction de la santé des équipements et à l'optimisation de la maintenance.

3. Rétention — ne pas thésauriser les données

Le principe : Les données personnelles doivent être conservées pas plus longtemps que nécessaire (Article 5(1)(e)).

Le défi avec la PdM : Les modèles ML s'améliorent avec plus de données historiques. Un Weibull-RNN pour la prédiction de durée de vie résiduelle bénéficie de plus de 2 ans d'historique de défaillances. Mais avez-vous besoin de 2 ans de journaux d'opérateurs ?

Stratégie de rétention en niveaux : | Type de données | Stockage chaud | Archive froide | Suppression | |---|---|---|---| | Lectures de capteurs | 90 jours | 2 ans (S3 Parquet) | Après expiration de l'archive | | Prédictions ML | 1 an | 3 ans | Après expiration de l'archive | | Journaux d'audit (avec IDs utilisateur) | 90 jours | 1 an | Suppression obligatoire | | Ordres de travail des opérateurs | 30 jours | Selon exigences légales | Selon politique | | Statistiques agrégées | Indéfini | — | Jamais (anonymisées) |

4. Isolation multi-tenant — vos données restent les vôtres

Dans un SaaS multi-tenant, le plus grand risque RGPD n'est pas un pirate — c'est un bug logiciel qui expose les données du Tenant A au Tenant B.

Exigences pour une isolation de niveau RGPD :

Sécurité au niveau des lignes (RLS) : Chaque requête de base de données est automatiquement limitée au tenant authentifié. Pas de filtrage au niveau applicatif — imposé par la base de données.
Chiffrement au repos : Clés de chiffrement par tenant (ou au minimum, isolation logique par tenant avec AES-256).
Isolation réseau : Les tenants premium peuvent nécessiter une infrastructure dédiée (le RGPD ne l'impose pas, mais les secteurs à forte aversion au risque l'exigent).
Piste d'audit : Qui a accédé à quelles données, quand. Le SOC 2 Type II vous donne cela comme effet secondaire.

5. Transferts transfrontaliers — où vivent vos données ?

Post-Schrems II, le transfert de données personnelles hors de l'UE nécessite des Clauses Contractuelles Types (CCT) ou une décision d'adéquation.

Pour l'IoT industriel, cela compte quand :

Votre fournisseur cloud a des centres de données hors de l'UE
Votre fournisseur PdM traite des données dans une région non-UE
Des dispositifs edge transmettent des diagnostics au système de support américain d'un fournisseur

Solution : Choisissez une plateforme avec des options de résidence des données en UE. L'infrastructure de Prevly fonctionne par défaut dans des régions UE, avec des garanties de résidence des données dans le DPA.

6. Droits des personnes concernées — oui, même pour les ingénieurs

Vos ingénieurs de maintenance ont le droit de :

Accéder à leurs données personnelles (Article 15)
Rectifier des données inexactes (Article 16)
Effacer (« droit à l'oubli ») leurs données (Article 17)
Portabilité des données — exporter leurs données dans un format lisible par machine (Article 20)

Si un ingénieur quitte l'entreprise et demande la suppression, votre système PdM peut-il supprimer son nom des ordres de travail historiques tout en préservant l'historique de maintenance ?

Concevez pour cela dès le premier jour. Il est beaucoup plus difficile de mettre en conformité RGPD après coup que de l'intégrer dès le départ.

La liste de contrôle

Avant de déployer la maintenance prédictive dans l'UE :

[ ] Entrée RAT pour le traitement des données PdM. Créez une entrée dédiée dans votre Registre des Activités de Traitement couvrant toutes les données liées à la PdM : lectures de capteurs, prédictions ML, ordres de travail et toute donnée liée aux opérateurs. Incluez la base juridique (généralement l'intérêt légitime pour la surveillance des équipements, le consentement pour le suivi des opérateurs), les catégories de données, les destinataires et les durées de conservation. C'est obligatoire en vertu de l'Article 30 pour les organisations de 250+ employés, et fortement recommandé pour les plus petites.
[ ] DPA signé avec votre fournisseur PdM. Votre Accord de Traitement des Données doit préciser le rôle du fournisseur (sous-traitant), les types de données traitées, les mesures de sécurité, la divulgation des sous-traitants ultérieurs et les procédures de suppression des données à la résiliation du contrat. En vertu de l'Article 28, vous êtes tenu d'utiliser uniquement des sous-traitants présentant des garanties suffisantes. Demandez le rapport SOC 2 Type II ou le certificat ISO 27001 le plus récent du fournisseur comme preuve.
[ ] Cartographie des flux de données montrant les déplacements des données de capteurs et personnelles. Schématisez chaque saut : capteur → passerelle edge → ingestion cloud → base de données → pipeline ML → moteur d'alerte → canaux de notification. Pour chaque saut, notez si des données personnelles sont présentes, quel chiffrement est utilisé en transit (TLS 1.2+) et si des données traversent des frontières nationales. Cette cartographie est essentielle pour une AIPD et pour répondre aux enquêtes des autorités de contrôle.
[ ] Politique de rétention avec suppression automatique des données personnelles. Ne comptez pas sur un nettoyage manuel. Configurez des règles de rétention automatisées : lectures de capteurs archivées à 90 jours, journaux d'audit avec IDs utilisateur supprimés à 12 mois, références d'opérateurs dans les ordres de travail anonymisées lors de la résiliation. Testez le processus de suppression — exécutez-le en environnement de test et vérifiez que les données personnelles sont réellement supprimées des sauvegardes dans un délai défini (le RGPD n'exige pas une suppression immédiate des sauvegardes, mais vous avez besoin d'un calendrier documenté).
[ ] RLS vérifiée — isolation multi-tenant testée, pas seulement documentée. Effectuez des tests de pénétration ciblant spécifiquement l'accès aux données entre tenants. Cela signifie : s'authentifier en tant que Tenant A, tenter d'interroger les données du Tenant B via chaque point d'API, connexion directe à la base de données et fonction d'export. La sécurité au niveau des lignes au niveau de la base de données doit rendre cela impossible quels que soient les bugs applicatifs. Documentez les résultats des tests.
[ ] Consentement aux cookies sur les tableaux de bord web. Oui, le tableau de bord de maintenance compte. S'il fonctionne dans un navigateur et définit des cookies ou utilise des analytics (même internes), vous avez besoin d'une bannière de consentement conforme au RGPD avec des options granulaires d'acceptation/refus. Les cookies « strictement nécessaires » (authentification de session) ne nécessitent pas de consentement ; les cookies analytics et de traçage oui.
[ ] Plan de notification de violation — signalement à l'autorité de contrôle dans les 72 heures. Définissez la chaîne d'escalade : qui détecte la violation, qui évalue la gravité, qui notifie le DPO, qui dépose auprès de l'autorité de contrôle. L'horloge de 72 heures démarre quand vous prenez « conscience » de la violation — pas quand vous finissez l'investigation. Préparez le modèle de notification avec les champs requis par votre autorité de contrôle.
[ ] AIPD réalisée si traitement à grande échelle ou prise de décision automatisée. Une Analyse d'Impact relative à la Protection des Données est obligatoire en vertu de l'Article 35 lorsque le traitement crée un risque élevé — ce qui inclut la surveillance à grande échelle (milliers de capteurs, plusieurs installations) et les décisions automatisées affectant des individus (ex. affectation d'ordres de travail, métriques corrélées aux performances). L'AIPD doit identifier les risques, les mesures d'atténuation et l'acceptation du risque résiduel.

Erreurs courantes à éviter

Trois schémas causent systématiquement des problèmes RGPD dans les déploiements IoT industriels :

Traiter toutes les données de capteurs comme non personnelles par défaut. Les données de vibration brutes sont effectivement non personnelles. Mais dès que vous les combinez avec des plannings d'équipes, des connexions d'opérateurs ou des affectations de maintenance, elles deviennent des données personnelles par association. L'approche la plus sûre : gardez les données de capteurs et les données du personnel dans des entrepôts de données séparés, joints uniquement quand explicitement nécessaire et avec une finalité documentée.

Se fier au contrôle d'accès au niveau applicatif. Si votre isolation multi-tenant est appliquée dans le code applicatif (« WHERE tenant_id = ? »), un seul bug expose tous les tenants. La sécurité au niveau des lignes en base de données est le standard de niveau RGPD — elle impose l'isolation au niveau de l'exécution des requêtes, indépendamment de la logique applicative. Chaque requête, chaque appel API, chaque export est limité par la base de données elle-même.

Pas de capacité de suppression des données personnelles. De nombreux systèmes PdM sont architecturés pour un stockage en séries temporelles append-only, excellent pour l'entraînement ML mais problématique pour le droit à l'effacement du RGPD. Concevez votre schéma de sorte que les identifiants d'opérateurs dans les ordres de travail et les journaux d'audit puissent être anonymisés (remplacés par « deleted_user_ ») sans détruire l'historique de maintenance dont vos modèles ML ont besoin.

Conclusion

Le RGPD n'est pas anti-innovation. C'est un cadre qui vous oblige à réfléchir à l'architecture des données — ce que vous devriez faire de toute façon pour un système PdM en production. Les entreprises qui traitent la conformité comme une contrainte de conception (pas une réflexion après coup) finissent avec des architectures plus propres, une meilleure gouvernance des données et des systèmes auxquels leurs clients font réellement confiance.

Prevly a été construit RGPD-first : sécurité au niveau des lignes, rétention en niveaux, résidence des données en UE, analytics conditionnées au consentement et API d'export des données. Parce que dans l'IoT industriel, la confiance n'est pas optionnelle — c'est le prérequis pour votre premier pilote.

Lectures complémentaires : Maintenance prédictive sur site ou dans le cloud · PdM pour la fabrication de dispositifs médicaux · Surveillance OPC-UA en lecture seule