C’est quoi la « data quality » ? (Et pourquoi ce n’est pas ce que vous croyez)
Quand on parle de « data quality » dans les conférences ou les articles de blog, on sort rapidement des Framework — DAMA, ISO 8000, six dimensions de la qualité. C’est propre, structuré, théorique.
La réalité que j’ai vécue sur mes projets aéronautiques ressemble à quelque chose de bien moins glamour.
Un collègue qui part à la retraite, un autre qui change de service, etc… laissent souvent derrière eux un fichier Excel difficilement maintenable: Quarante onglets, des cellules fusionnées partout, des colonnes dont personne ne sait ce qu’elles mesurent exactement, des macros qui tournent sur une version d’Excel qui n’existe plus. Et toi, tu dois exploiter ce fichier pour construire un modèle de maintenance prédictive.
C’est ça, la « data quality » dans l’industrie ; ce n’est pas un problème de framework, c’est un problème de tableur hérité que personne n’a jamais pensé à documenter ou à structurer !
Dans cet article, on va démystifier la « data quality » — ce que c’est vraiment, pourquoi c’est critique, et comment l’évaluer concrètement sur vos données industrielles.
La définition académique vs. la réalité terrain
La définition académique décrit la data quality selon six dimensions : exactitude, complétude, cohérence, actualité, validité, unicité. C’est utile pour structurer une démarche dans une grande organisation.
La réalité terrain, c’est autre chose. Dans l’industrie, les problèmes de qualité des données se manifestent presque toujours sous quatre formes concrètes.
Le manque de données. Le système n’a tout simplement pas enregistré ce dont vous avez besoin. Le capteur était mal positionné, le système d’acquisition n’était pas encore installé ou les données ont été effacées. Vous construisez votre modèle sur 6 mois de données là où il en faudrait 3 ans.
Les tableurs mal structurés. C’est de loin le problème le plus fréquent dans l’industrie. Des fichiers créés pour être lus par des humains, pas traités par des machines. Des tableaux croisés dynamiques comme source de données. Des colonnes dont le nom change selon l’onglet. Des cellules qui contiennent du texte libre à la place d’une valeur numérique.
Les trous inexpliqués. Une série temporelle qui s’arrête pendant 6 mois sans explication puis qui repart. Était-ce une panne capteur ? Un remplacement de composant non documenté ? Une migration de système ? On ne sait pas — et cette incertitude contamine toute l’analyse.
Les formats inconnus ou incohérents. Des dates au format américain dans un fichier français. Des décimales avec des points dans certaines lignes et des virgules dans d’autres. Des valeurs numériques stockées en texte. Des unités qui changent en cours de fichier sans que personne ne l’ait signalé.
Pourquoi un tableur mal structuré est le pire ennemi de vos données
Parmi ces quatre problèmes, les tableurs mal structurés méritent une attention particulière parce qu’ils sont à la fois les plus répandus et les plus difficiles à maintenir.
Un fichier avec des données manquantes, Python vous le signale immédiatement — des NaN apparaissent, des alertes s’affichent. Un fichier mal structuré, lui, s’importe sans erreur. Tout semble normal. Et c’est là le danger.
Voici les symptômes les plus fréquents.
Les en-têtes sur plusieurs lignes. Excel les affiche joliment avec des cellules fusionnées. Python les importe en colonnes « Unnamed: 3 » et « Unnamed: 4 » — et vous passez une heure à comprendre quelle colonne correspond à quoi.
Les totaux et sous-totaux mélangés aux données. La ligne 47 est une vraie mesure. La ligne 48 est un total calculé. La ligne 49 est une moyenne. Python les traite toutes comme des données — et vos calculs statistiques sont faux.
Les unités dans les cellules. « 125 MPa » au lieu de « 125 ». Python importe une chaîne de caractères là où vous attendez un nombre.
Les commentaires dans les données. Une cellule qui contient « N/A — capteur en panne ce jour-là » au lieu d’être vide. Python ne sait pas quoi en faire.
import pandas as pd
import numpy as np
# Charger un fichier Excel "hérité" typique
df = pd.read_excel('suivi_maintenance.xlsx', sheet_name='Données')
# Premier réflexe : audit rapide
print("=== AUDIT DU FICHIER ===n")
print(f"Dimensions : {df.shape[0]:,} lignes × {df.shape[1]} colonnes")
print(f"nTypes de colonnes :")
print(df.dtypes)
print(f"nValeurs manquantes :")
print(df.isnull().sum()[df.isnull().sum() > 0])
print(f"nAperçu des premières lignes :")
print(df.head(5))
# Détecter les colonnes numériques importées en texte
# (signe classique d'un problème de format dans le fichier source)
cols_object = df.select_dtypes(include='object').columns
print(f"nColonnes texte (potentiellement numériques) : {list(cols_object)}")
for col in cols_object:
tentative = pd.to_numeric(df[col], errors='coerce')
taux_conversion = tentative.notna().mean()
if taux_conversion > 0.5:
print(f" ⚠️ '{col}' : {taux_conversion:.0%} des valeurs "
f"sont numériques → colonne mal typée")Les 5 dimensions de la data quality — version terrain
Oublions les frameworks académiques. Voici les 5 questions concrètes à se poser sur n’importe quel dataset industriel.
1. Est-ce que mes données sont complètes ?
Complètes ne signifie pas « sans valeur manquante » — ça signifie « est-ce que j’ai assez de données pour répondre à ma question ? ». 6 mois d’historique pour modéliser un phénomène annuel, ce n’est pas complet. 50 capteurs dont 30 sont quasi-constants, ce n’est pas complet sur les grandeurs utiles.
# Taux de complétude par colonne
taux_completude = (1 - df.isnull().mean()) * 100
print("Complétude par colonne :")
print(taux_completude.sort_values().round(1))
# Alerte si moins de 80% de données disponibles
colonnes_insuffisantes = taux_completude[taux_completude < 80]
if len(colonnes_insuffisantes) > 0:
print(f"n⚠️ Colonnes insuffisantes (< 80%) :")
print(colonnes_insuffisantes)2. Est-ce que mes données sont cohérentes ?
Cohérentes signifie que la même grandeur est mesurée de la même façon partout. Si la colonne « température » est en °C dans les 6 premiers mois et en °F dans les 6 suivants — à cause d’un changement de système d’acquisition — vos données ne sont pas cohérentes. Et Python ne vous le dira pas spontanément.
# Détecter les ruptures de distribution dans le temps
# Un changement brutal de moyenne ou d'écart-type signale souvent
# un problème de cohérence (changement de capteur, recalibrage...)
if 'timestamp' in df.columns and 'temperature' in df.columns:
df_temp = df.set_index('timestamp').sort_index()
# Découper en tranches mensuelles
stats_mensuelles = df_temp['temperature'].resample('M').agg(['mean', 'std'])
print("Statistiques mensuelles — température :")
print(stats_mensuelles.round(2))
# Alerte si la moyenne change de plus de 20% d'un mois à l'autre
variation = stats_mensuelles['mean'].pct_change().abs()
mois_suspects = variation[variation > 0.20]
if len(mois_suspects) > 0:
print(f"n⚠️ Ruptures de distribution détectées :")
print(mois_suspects)3. Est-ce que mes données sont exactes ?
Exactes signifie que les valeurs sont dans des plages physiquement plausibles. Une température moteur à -500°C ou à 5000°C n’est pas une vraie mesure — c’est un code d’erreur du système d’acquisition. Ces valeurs aberrantes contaminent vos statistiques et faussent vos modèles.
# Détection de valeurs aberrantes par la méthode IQR
def detecter_aberrantes(serie, seuil=3.0):
"""
Identifie les valeurs au-delà de seuil × IQR.
Robuste aux distributions non gaussiennes — idéal pour données industrielles.
"""
Q1 = serie.quantile(0.25)
Q3 = serie.quantile(0.75)
IQR = Q3 - Q1
borne_basse = Q1 - seuil * IQR
borne_haute = Q3 + seuil * IQR
aberrantes = serie[(serie < borne_basse) | (serie > borne_haute)]
return aberrantes, borne_basse, borne_haute
cols_numeriques = df.select_dtypes(include=[np.number]).columns
print("Détection de valeurs aberrantes :")
for col in cols_numeriques:
aberrantes, b_basse, b_haute = detecter_aberrantes(df[col].dropna())
if len(aberrantes) > 0:
print(f" {col} : {len(aberrantes)} valeurs hors "
f"[{b_basse:.1f}, {b_haute:.1f}]")4. Est-ce que mes données sont actuelles ?
Actuelles signifie que l’historique disponible correspond à l’état actuel du système. Si votre modèle de maintenance est entraîné sur des données d’un composant de génération précédente — avant une modification de design ou un changement de fournisseur — il ne sera peut-être pas valide sur les composants actuels.
# Vérifier la fraîcheur des données
if 'timestamp' in df.columns:
date_derniere_donnee = df['timestamp'].max()
date_premiere_donnee = df['timestamp'].min()
duree_historique = date_derniere_donnee - date_premiere_donnee
print(f"Première donnée : {date_premiere_donnee.date()}")
print(f"Dernière donnée : {date_derniere_donnee.date()}")
print(f"Durée historique : {duree_historique.days} jours "
f"({duree_historique.days/365:.1f} ans)")5. Est-ce que mes données sont documentées ?
C’est la dimension la plus sous-estimée — et la plus critique sur les projets industriels à long terme. Que mesure exactement cette colonne ? Avec quel capteur ? Depuis quelle date ? Qu’est-il arrivé le 14 mars quand il y a eu ce saut inexpliqué ?
Sans documentation, chaque nouvel ingénieur qui touche au projet repart de zéro. Et dans 6 mois, cet ingénieur c’est peut-être vous.
import json
# Template de documentation minimale à remplir sur chaque dataset
DOCUMENTATION = {
'fichier' : 'suivi_maintenance_2024.xlsx',
'date_creation' : '2024-01-15',
'responsable' : 'Bureau méthodes',
'colonnes' : {
'timestamp' : 'Horodatage UTC, 1 mesure/heure',
'temperature' : 'Température capteur principal, °C',
'vibration' : 'Accélération RMS, g',
'statut' : '0=normal, 1=alarme, 9=données invalides',
},
'evenements_connus': [
'2024-03-14 : recalibrage capteur température',
'2024-06-01 : remplacement composant — remise à zéro compteur',
],
'taux_completude' : '94%',
'periode' : '2024-01-01 → 2024-12-31',
}
print(json.dumps(DOCUMENTATION, indent=2, ensure_ascii=False))La data quality n’est pas un problème technique
C’est le point que j’aurais voulu comprendre plus tôt.
On pense souvent que la data quality se résout avec des outils — un meilleur système d’acquisition, un ETL plus robuste, un pipeline de nettoyage automatisé. Ces outils aident. Mais ils ne résolvent pas le problème fondamental.
La data quality est un problème organisationnel et humain.
Le tableur mal structuré hérité d’un collègue retraité ce n’est pas un problème technique, c’est un problème de pratiques de travail. Le format de date incohérent entre deux services ce n’est pas un bug logiciel, c’est l’absence de convention partagée. Le trou de 6 mois dans les données sans explication ce n’est pas une panne capteur, c’est l’absence de processus de documentation des incidents.
Python peut détecter ces problèmes et souvent les corriger partiellement. Mais la vraie solution, c’est de mettre en place des pratiques qui empêchent ces problèmes de se produire en amont.
Trois règles simples à appliquer dès maintenant :
Une ligne = une observation. Une colonne = une variable. Pas de totaux, pas de sous-totaux, pas de commentaires mélangés aux données.
Chaque fichier de données a un fichier de documentation associé — même minimal. Qui a créé ce fichier, que contient chaque colonne, quels événements connus peuvent avoir affecté les données ?
Chaque anomalie détectée est documentée au moment où elle est découverte. Pas après. Dans 6 mois vous aurez oublié et la personne qui reprend le projet perdra une semaine à comprendre ce que vous avez mis 5 minutes à noter.
Conclusion
La data quality, ce n’est pas un framework en six dimensions réservé aux DSI des grandes entreprises. C’est une réalité quotidienne pour tout ingénieur qui touche à des données industrielles.
Un tableur hérité mal structuré, des données manquantes sans explication, des formats incohérents entre deux services. Ces problèmes ne font pas la une des conférences data mais ils représentent 60 à 80% du temps réel passé sur un projet d’analyse.
Les reconnaître, les quantifier, et les corriger méthodiquement c’est ça, la data quality appliquée à l’industrie. Pas un problème de technologie. Un problème de méthode.
🚀 Vous souhaitez aller plus loin ?
Téléchargez le Pack Complet « De Facto »
J’ai condensé une méthode dans le ‘De Facto Data Automation Kit’:
• 📊 des données capteurs brutes utilisées dans le challenge 7 jours ;
• 🐍 le script Python de nettoyage ;
• ✅ la checklist de contrôle des données ;
• 📈 l’exemple avant/après ;
• 🔧 les scripts des 7 étapes du challenge ;
• 📄 le guide complet.
En attendant, j’aimerais connaître votre réalité de terrain
💬 Quel est le problème de qualité de données le plus frustrant que vous ayez rencontré dans votre carrière ? Dites-le moi en commentaire — je lis tout.
Laisser un commentaire