Quand j'aborde un projet d'IA pour la maintenance, la première question que je pose toujours est : les données de l'usine sont-elles prêtes ? C'est la clé. Vous pouvez avoir les meilleurs algorithmes du monde, mais sans une maturité donnée suffisante, le projet s'enlisera. Dans cet article, je partage ma méthode pragmatique pour évaluer la maturité donnée d'une usine — ce que je regarde, comment je mesure, et quelles actions prioriser pour passer de données brutes à une solution IA fiable et exploitable.
Pourquoi évaluer la maturité donnée avant tout
J'ai vu trop de projets démarrer par le choix d'un modèle ou d'une plateforme cloud (Azure, AWS, Google Cloud, ou des solutions industrielles comme Siemens MindSphere, PTC ThingWorx) sans vérifier l'état réel des données sur le terrain. Le résultat : pilotes qui n'aboutissent pas, modèles qui génèrent des prédictions inutilisables, délais et coûts qui explosent. L'évaluation de maturité donnée permet de :
- prioriser les chantiers à fort retour sur investissement (fiabilité des capteurs, intégrité des données) ;
- estimer le coût réel et le temps nécessaire avant d'alimenter un modèle IA ;
- définir un plan d'action concret (collecte, qualité, gouvernance, stockage, sécurité, compétences).
Les dimensions que j'analyse systématiquement
Pour être exhaustive et pragmatique, j'organise l'évaluation autour de six dimensions :
- Disponibilité des données : capteurs, historiques, archivage.
- Qualité des données : bruit, valeurs manquantes, précision et calibrage.
- Sémantique et métadonnées : noms de tags, unités, arborescence asset-wise.
- Intégration et accès : connectivité (SCADA, OPC UA, MQTT), latence, API.
- Gouvernance et sécurité : droits, traçabilité, RGPD/ISO27001/IEC62443.
- Compétences et processus : équipes, routines de maintenance, culture data-driven.
Un cadre simple de maturité donnée
J'utilise souvent une matrice 0–4 pour chaque dimension. Voici un tableau que j'emploie comme référence quand j'évalue une usine :
| Score | Description |
|---|---|
| 0 | Pas de données disponibles ou collection très sporadique (papier, fichiers Excel non centralisés). |
| 1 | Données collectées manuellement ou via systèmes hétérogènes, historique limité, accès compliqué. |
| 2 | Collecte automatisée basique (SCADA/PLC), mais qualité variable et peu de métadonnées. |
| 3 | Données historisées avec bonnes pratiques de taggage, pipelines ETL et accès standard (OPC UA, Historian, MQTT). |
| 4 | Plateforme data mature : modèle asset, métadonnées riches, gouvernance, monitoring qualité et accès sécurisé pour analytics/IA. |
Checklist détaillée : ce que je teste sur le terrain
Sur le terrain (ou via des workshops), je vérifie concrètement :
- Présence d'un Historian : y a-t-il un PI System, Wonderware Historian, ou utilisation d'une base temporelle type InfluxDB ? Quel est l'horizon historique disponible (jours, mois, années) ?
- Fréquence et granularité : les mesures sont-elles en seconde, minute ou 10 minutes ? L'IA que vous voulez déployer nécessite-t-elle de la haute fréquence (vibrations) ou de la basse fréquence (compteurs d'énergie) ?
- Synchronisation temporelle : horodatage cohérent entre assets ? Des dérives d'horloge peuvent fausser tout apprentissage supervisé.
- Valeurs manquantes et outliers : quel est le pourcentage d'anomalies/NaN ? Sont-elles corrélées à des périodes de maintenance ou des pannes ?
- Sémantique : les tags sont-ils compréhensibles ? Exemple : "Pmp1_Freq_Hz" vs "T1" — la première est exploitable, la deuxième demande du travail de mapping.
- Events et labels : avez-vous des historiques de pannes, d'interventions ou de défauts horodatés ? Sans labels, certains cas d'usage (classification) sont difficiles.
- Flux d'ingestion : les pipelines ETL sont-ils documentés ? Utilisez-vous des outils comme NiFi, Kafka, Azure Data Factory ?
- Sécurité et accès : qui peut accéder aux données ? Les accès sont-ils tracés et audités ?
- Qualité de la documentation : schémas d'asset, plans de capteurs, procédures de maintenance disponibles ?
Métriques simples pour quantifier la maturité
Pour rendre l'évaluation actionnable, je calcule quelques métriques basiques :
- Taux de disponibilité des tags : pourcentage de points mesurés sans interruption sur une période donnée.
- Taux d'absence/NaN : proportion de données manquantes à corriger.
- Ratio tags documentés : nombre de tags associés à une description utile / total tags.
- Présence de labels : nombre d'événements pannes exploitables / nombre d'événements attendus.
- Temps moyen d'accès : latence depuis la requête jusqu'à la donnée (pour les cas temps réel).
Exemples concrets de problèmes récurrents et solutions
Voici des situations que j'ai rencontrées et comment je les ai traitées :
- Capteurs non calibrés : un signal de température monotone parce que le capteur était défectueux. Action : audit capteurs, remplacement, et mise en place d'un check de plausibilité automatisé.
- Tags dupliqués ou mal nommés : plusieurs points mesuraient la même variable avec noms différents. Action : nettoyage et standardisation via naming convention (ex : ISA-95 adapté) et un dictionnaire de données central.
- Historique incomplet : seulement 3 mois de données alors qu'il faut 24 mois pour détecter des patterns saisonniers. Action : combiner sources (Historian + fichiers d'archive) et lancer une politique de rétention long terme.
- Pas de labels pour pannes : impossibilité d'entraîner un modèle supervisé. Action : définir un plan de labeling via équipes de maintenance (formulaire simple dans CMMS), et déployer une phase de pseudo-labeling/analyse non supervisée pour démarrer.
Plan d'action type selon le score de maturité
En pratique, voici ce que je recommande selon le score moyen obtenu :
- Score 0–1 : Priorité à la collecte et à la centralisation. Installer Historian ou une solution cloud-historian, former les équipes sur l'acquisition des données. Projet IA = PoC long et coûteux.
- Score 2 : Travailler la qualité et les métadonnées. Déployer pipeline ETL, naming convention, contrôles qualité automatiques. Pilote IA possible sur cas simple (détection d'anomalie non supervisée).
- Score 3 : Lancer des pilotes IA ambitieux, avec labeling ciblé et MLOps léger. Mesurer KPIs métier (MTTR, MTBF) et industrialiser progressivement.
- Score 4 : Industrialisation complète : MLOps, monitoring des modèles en production, rétroaction vers GMAO/CMMS et intégration dans les process décisionnels.
Quelques conseils concrets pour accélérer la montée en maturité
Pour finir, des astuces que j'applique systématiquement :
- Commencer par un cas d'usage restreint et à fort impact (pompe critique, moteur, compresseur) plutôt que d'attaquer l'usine entière.
- Impliquer la maintenance dès le départ : ils sont les meilleurs pour labelliser et valider les hypothèses.
- Automatiser les contrôles qualité : scripts de détection d'outliers, dashboards de santé des données via Grafana ou Power BI.
- Mettre en place une gouvernance simple (data owner par équipement) et un dictionnaire de données accessible.
- Prévoir la cybersécurité industrielle (segmentation, VPN, authentification forte) avant d'exposer des APIs pour analytics.
Évaluer la maturité donnée n'est pas une fin en soi mais le premier investissement qui conditionne la réussite d'un projet d'IA en maintenance. En suivant une approche structurée — mesurer, prioriser, corriger et industrialiser — vous transformerez des données souvent sous-exploitées en leviers concrets pour réduire les pannes, optimiser les interventions et prolonger la durée de vie des équipements.