Le data engineer IoT industriel travaille sur un terrain que les autres data engineers ne connaissent pas, et l'entretien doit le couvrir. Les données viennent d'automates, de SCADA et d'historians comme AVEVA PI, passent par OPC UA ou MQTT, puis rejoignent une base de séries temporelles ou un lakehouse sur Azure ou AWS. On recrute ce profil dans l'aéronautique, l'énergie, la chimie, l'agroalimentaire, souvent pour des projets de maintenance prédictive, de suivi énergétique ou de TRS.
Le piège vient des profils data venus du web. Ils traitent une mesure de capteur comme un clic : un événement unique, horodaté proprement, toujours exploitable. Sur le terrain, un historian compresse les valeurs, les horloges dérivent, une mesure peut être marquée de mauvaise qualité, et le réseau de l'usine reste séparé de celui du siège pour des raisons de sécurité. L'expérience réelle s'entend quand la personne parle de ces contraintes sans qu'on les lui souffle.
Pour la partie sécurité de l'entretien technique, associez si possible un automaticien ou le responsable de la sécurité industrielle à l'entretien. Le PDF contient 30 questions sur six axes, un cas de 20 minutes sur la surveillance de compresseurs et une grille de notation de 1 à 4.
Ce qui relie les automates au cloud dans une usine
Historians (AVEVA PI et autres)
Des bases spécialisées qui archivent les mesures de l'usine depuis des années. AVEVA PI System, ex-OSIsoft PI, domine dans les grands groupes, avec son Data Archive pour les valeurs et son Asset Framework pour décrire les équipements. On croise aussi AspenTech IP.21, Canary ou l'historian d'Ignition. Vérifiez que la personne sait que PI compresse les données.
OPC UA
Le protocole standard pour lire les données des automates et des systèmes de supervision. Il décrit chaque machine avec un modèle d'information et chiffre les échanges par certificats. Son prédécesseur OPC DA, lié à Windows, subsiste sur les lignes anciennes.
MQTT et Sparkplug B
Un protocole léger de messagerie : les équipements publient sur un courtier, les applications s'abonnent. Sparkplug B ajoute un format de message et la gestion de l'état de connexion des équipements. MQTT sert souvent de colonne vertébrale entre l'atelier et le cloud, parfois sous le nom de Unified Namespace.
Passerelles et edge
Des logiciels installés en usine qui traduisent les protocoles, filtrent les données et les gardent en mémoire si le réseau tombe : Kepware, Ignition Edge, Azure IoT Operations, AWS IoT Greengrass. Leur déploiement sur des dizaines de sites fait partie du poste.
Bases de séries temporelles
InfluxDB, TimescaleDB, Azure Data Explorer ou l'Eventhouse de Microsoft Fabric stockent des milliards de mesures datées et calculent vite des moyennes par intervalle. Le choix dépend du volume, de la durée de conservation et du langage de requête que l'équipe maîtrise.
Services IoT des clouds
Azure IoT Hub et Azure IoT Operations, AWS IoT Core et IoT SiteWise reçoivent les flux des usines. Plusieurs services ont été retirés ces dernières années, dont Azure Time Series Insights, AWS IoT Analytics et AWS IoT Events. Un CV qui les cite décrit une architecture antérieure, ce qui reste une expérience utile.
MES et modèle ISA-95
Le MES suit la production : ordres de fabrication, lots, rebuts. La norme ISA-95 décrit la hiérarchie site, atelier, ligne, équipement. Relier une mesure au lot produit à ce moment-là passe par ces deux sources.
Sécurité OT
Le réseau de l'usine est séparé de l'informatique de gestion par zones, selon la norme IEC 62443, avec une DMZ industrielle entre les deux. La directive NIS 2 renforce ces exigences pour beaucoup d'industriels. Un data engineer doit concevoir ses flux dans ce cadre.
Le poste se trouve à la frontière de l'informatique industrielle (OT) et de la data. Dans un grand groupe industriel, le data engineer rejoint souvent une équipe centrale qui raccorde les usines une par une à une plateforme commune, avec des historians déjà en place depuis longtemps. En ESN ou en cabinet d'ingénierie, il intervient sur des projets de maintenance prédictive ou de suivi énergétique et doit composer avec des sites aux équipements très hétérogènes. Les offres demandent souvent PI System, OPC UA et un cloud (Azure plus souvent qu'AWS dans l'industrie française), et parfois des déplacements en usine. L'entretien doit vérifier la compréhension des contraintes OT autant que la technique data.
Points de contrôle pour l'entretien d'un data engineer IoT
- Historians et protocoles industriels (PI, OPC UA, MQTT)
- Traitement des séries temporelles et qualité du signal
- Architecture edge et transport vers le cloud
- Modèle d'actifs et contexte de production
- Sécurité OT/IT et segmentation réseau
- Exploitation et coûts d'une ingestion multi-sites
Des questions tirées du terrain industriel, du tag compressé à la coupure réseau
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Vous extrayez un an de données d'un tag PI pour un data scientist. Il trouve des trous et des valeurs en escalier. Que lui expliquez-vous ?
Une bonne réponsePI n'archive pas toutes les mesures : le filtrage par exception puis la compression (algorithme swinging door) ne gardent que les changements significatifs. Les valeurs enregistrées sont donc irrégulières, et entre deux points l'interpolation est valable pour un signal continu, pas pour un tag déclaré en escalier (step). La personne choisit en connaissance de cause entre valeurs enregistrées et valeurs interpolées, repère les états numériques comme I/O Timeout ou Bad qui marquent de vrais trous, et vérifie les réglages de compression avec l'équipe process.
Signal d'alerte« Les données sont corrompues », ou un rééchantillonnage avec report de la dernière valeur sur tous les tags sans connaître leur nature.
Question 2 · confirmé
Un capteur remonte une température chaque seconde, un autre toutes les dix minutes. Comment les alignez-vous pour une analyse ?
Une bonne réponseUne grille de temps commune en UTC, avec une agrégation adaptée à chaque signal : moyenne, minimum et maximum par intervalle pour le signal rapide, interpolation ou dernière valeur connue avec un écart maximal pour le signal lent. Les indicateurs de qualité sont conservés et on n'interpole pas à travers un long trou. Côté outils, time_bucket dans TimescaleDB, make-series en KQL ou resample dans pandas.
Signal d'alerteUne jointure sur les horodatages exacts, qui ne ramène presque aucune ligne, ou une moyenne appliquée aussi aux signaux d'état.
Question 3 · confirmé
OPC UA ou MQTT pour remonter les données d'une ligne de production : comment positionnez-vous les deux ?
Une bonne réponseOPC UA est le standard client-serveur des automates et des SCADA, avec un modèle d'information riche, des abonnements réglés par intervalle d'échantillonnage et bande morte, et une sécurité par certificats. MQTT est un protocole de publication par courtier, léger, adapté au transport vers le cloud et aux consommateurs multiples, mais sans format de message imposé. Une architecture courante lit en OPC UA au plus près des machines, puis une passerelle (Kepware, Ignition, passerelle edge) publie sur un courtier MQTT. La personne sait qu'OPC UA prévoit aussi un mode PubSub au-dessus de MQTT.
Signal d'alerte« MQTT remplace OPC UA », ou aucune notion de niveau de QoS ni de courtier.
Question 4 · confirmé
L'équipe IT propose de connecter directement la plateforme cloud aux automates pour lire les données. Qu'en pensez-vous ?
Une bonne réponseC'est à proscrire. Le réseau industriel est découpé en zones (modèle de Purdue, zones et conduits de l'IEC 62443) avec une DMZ industrielle entre l'OT et l'IT. Les flux partent de l'usine vers l'extérieur, jamais l'inverse, souvent depuis un historian répliqué en DMZ, en lecture seule, parfois à travers une diode. On évite aussi d'ajouter de la charge sur des automates qui pilotent la production. La décision se prend avec le responsable de la sécurité OT.
Signal d'alerteOuvrir un port ou un VPN vers les automates, ou « c'est en lecture seule, donc sans risque ».
Question 5 · confirmé
La liaison entre l'usine et le cloud tombe pendant six heures. Que deviennent les mesures, et que doit faire votre pipeline au retour ?
Une bonne réponseLes mesures sont gardées sur place par un mécanisme de stockage et retransmission (store and forward) dans la passerelle, le connecteur ou l'historian, avec un tampon dimensionné pour la durée de coupure visée, et des sessions MQTT persistantes en QoS 1. Au retour, les données arrivent en retard et en désordre : le pipeline se fonde sur l'horodatage source, écrit sans doublon sur la clé tag et horodatage, et recalcule les agrégats des fenêtres touchées. Les alertes déclenchées pendant la coupure sont qualifiées comme telles.
Signal d'alerteAccepter la perte des six heures, ou calculer les agrégats sur l'heure d'arrivée des messages.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Profil usine ou profil cloud, et la frontière avec l'automaticien
Expérience en usine ou cloud d'abord : quel profil privilégier ?
Tout dépend de la maturité de votre plateforme. Si les usines ne sont pas encore raccordées, un profil qui connaît les historians, OPC UA et les contraintes de sécurité OT vous fera gagner des mois. Si la plateforme cloud existe et qu'il s'agit d'ajouter des sites, un data engineer cloud solide peut apprendre le terrain, à condition d'être accompagné par un automaticien. Les questions sur la compression PI et la segmentation réseau montrent vite le niveau OT.
Que recouvre le mot historian dans une offre d'emploi ?
Un historian est une base qui archive en continu les mesures des capteurs et des automates d'une usine, souvent sur des dizaines d'années. AVEVA PI System, l'ancien OSIsoft PI, est le plus répandu dans les grands groupes, devant IP.21 d'AspenTech, Canary ou les historians intégrés aux SCADA. Une offre qui le mentionne attend que le candidat sache en extraire des données sans le surcharger et comprenne sa logique de compression.
Comment construire un test technique sur des données de capteurs ?
Donnez un fichier de mesures réalistes : deux capteurs à des fréquences différentes, un compteur cumulé avec une remise à zéro, quelques valeurs marquées de mauvaise qualité et un trou de plusieurs heures. Demandez une consommation horaire et une moyenne alignée sur une grille commune. En une heure, vous voyez si la personne pondère par le temps, traite la qualité et signale les trous au lieu de les combler en silence.
Data engineer IoT et automaticien : qui fait quoi ?
L'automaticien programme et maintient les automates et la supervision, et décide de ce qui peut être lu sur le réseau industriel. Le data engineer IoT récupère ces données par les interfaces prévues, les transporte, les met en qualité et les rend exploitables pour l'analyse. Il ne modifie pas les automates. Sur un projet, les deux travaillent ensemble sur la liste des tags, les unités, les fréquences et les règles de sécurité.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
