Je retiens pyjanitor, ftfy, ydata-profiling, Great Expectations et Pandera. Chacune règle un vrai problème du nettoyage de données Python : colonnes sales, texte cassé, anomalies invisibles, règles qualité et validation avant mise en production.
Pourquoi pandas seul devient vite pénible ?
Pandas reste excellent, je l’utilise tout le temps. Mais dès que le nettoyage devient sérieux, ça devient vite verbeux. Le souci, ce n’est pas pandas. Le vrai problème, c’est l’accumulation de petites corrections dispersées partout dans des notebooks, des scripts, des cellules copiées-collées, puis légèrement modifiées selon le fichier du jour.
Au début, ça va. On renomme deux colonnes, on remplace trois valeurs manquantes, on corrige un format de date. Puis les règles s’empilent. Les noms de colonnes ne suivent plus aucune logique. Un fichier arrive avec First Name, un autre avec first-name, un troisième avec FIRST_NAME. Les emails contiennent des espaces invisibles. Les statuts client sont écrits actif, Actif, active. Et là, on commence à ajouter des bouts de code partout.
J’ai vu ça chez un client sur des exports CRM. Chaque équipe avait son “petit nettoyage” avant d’envoyer les données plus loin. Résultat, personne ne savait vraiment quelle version était fiable. Les valeurs manquantes étaient traitées différemment selon les fichiers. Les chaînes mal encodées passaient parfois en production. Les catégories étaient corrigées à la main. Les MultiIndex, ces index pandas à plusieurs niveaux, devenaient impossibles à relire trois semaines plus tard.
Comme on dit à Brive, un bon plan de marquage vaut mieux qu’un bon reporting ! Si besoin, consultez moi - faites appel à un super consultant en tracking client et server side.
Le plus dangereux, c’est l’absence de contrôle qualité avant l’étape suivante du pipeline. Un pipeline, c’est juste l’enchaînement des traitements data, de l’import jusqu’à l’usage final. Si une donnée douteuse passe au mauvais moment, elle contamine les analyses, les dashboards, parfois même les modèles d’IA.
Les bonnes bibliothèques Python de nettoyage ne remplacent pas pandas. Elles l’encadrent. Elles rendent le travail plus lisible, plus testable, moins fragile. Pyjanitor aide à écrire des transformations propres. Ftfy répare les textes encodés n’importe comment. Ydata-profiling permet de voir rapidement les problèmes d’un jeu de données. Great Expectations et Pandera servent à poser des règles pour éviter que des données douteuses passent en production.
Comment transformer un CSV en rapport exécutif ?
Le vrai gain, ce n’est pas de nettoyer plus vite une fois. C’est de transformer le nettoyage en processus reproductible, au lieu de bricoler à la main à chaque nouveau fichier.
Comment rendre le nettoyage plus lisible ?
Pyjanitor rend le nettoyage plus lisible parce qu’il ajoute à pandas une API chaînable, claire et proche du langage métier.
Le principe est simple. Au lieu de réassigner dix fois le même DataFrame avec df = df… partout dans le notebook, on compose une suite d’opérations qui se lit de haut en bas. C’est ce qu’on appelle le method chaining. Chaque méthode renvoie un DataFrame, donc on peut enchaîner la suivante.
Dans la vraie vie, ça change beaucoup de choses. Un pipeline relu trois mois plus tard doit raconter ce qu’il fait. J’ai souvent vu chez des clients des notebooks impossibles à reprendre parce que chaque nettoyage était caché dans une cellule différente. Une cellule pour renommer les colonnes, une autre pour supprimer les lignes vides, une autre pour corriger un champ texte. Là, on remet de l’ordre.
Pyjanitor est utile sur des cas très fréquents :
- Clean_names() uniformise les noms de colonnes, par exemple Nom Client devient nom_client.
- Collapse_levels() aplatit les colonnes MultiIndex, souvent créées après un groupby ou un pivot.
- Les fonctions sur les valeurs manquantes aident à repérer, remplacer ou filtrer les données absentes.
- Les transformations ligne par ligne rendent certains nettoyages plus explicites.
- Les jointures conditionnelles permettent de joindre deux tables autrement que sur une égalité stricte.
import pandas as pd
import janitor
df_propre = (
pd.read_csv("clients.csv")
.clean_names()
.remove_empty()
.drop_duplicate_columns(column_name="email", nth_index=1)
.assign(
pays=lambda df: df["pays"].str.strip().str.upper(),
email=lambda df: df["email"].str.strip().str.lower()
)
)Assign() vient de pandas, mais il s’intègre très bien dans la chaîne. Je l’utilise souvent pour standardiser une colonne sans casser la lecture du pipeline.
| Noms de colonnes sales | Renommer avec df.columns ou rename() à plusieurs endroits | Utiliser clean_names() directement dans la chaîne |
| MultiIndex après agrégation | Reconstruire les noms de colonnes à la main | Utiliser collapse_levels() pour aplatir proprement |
| Pipeline illisible | Multiplier les cellules et les réassignations | Composer un enchaînement clair avec pyjanitor |
Comment réparer les textes et catégories ?
Ftfy répare les textes mal encodés, et c’est souvent la première chose à faire avant de standardiser les catégories.
Le problème classique, c’est le mojibake. C’est le nom un peu moche qu’on donne aux textes affichés avec le mauvais encodage. Vous vouliez lire “é”, vous récupérez “é”. Vous vouliez “à”, vous avez “à ”. Dans les données réelles, je vois aussi des caractères invisibles, des espaces à largeur nulle, des apostrophes bizarres, ou du texte encodé deux fois après être passé dans plusieurs outils.
Ftfy est très utile sur des données web scrapées, des vieux exports CSV, des contenus utilisateurs, ou des bases qui ont traversé plusieurs systèmes. C’est typiquement le genre de problème qu’on découvre trop tard, quand un dashboard affiche deux catégories qui devraient être identiques.
L’API est simple : ftfy.fix_text(s). Je lui donne une chaîne de caractères, il tente de réparer l’encodage et quelques problèmes Unicode. Unicode, c’est le standard qui permet de représenter les caractères dans quasiment toutes les langues. Quand un outil l’interprète mal, vos textes deviennent sales.
Mais ftfy ne fait pas de magie métier. Il peut réparer “café” en “café”, mais il ne décide pas si “client actif”, “active” et “Actif ” veulent dire la même chose. Ça, c’est de la standardisation de catégories, et je le fais ensuite avec pandas.
from ftfy import fix_text
# Je répare d'abord les textes mal encodés
df["commentaire"] = df["commentaire"].map(fix_text)
# Ensuite seulement, je standardise les catégories
df["statut"] = (
df["statut"]
.map(fix_text)
.str.strip()
.str.lower()
.replace({
"client actif": "actif",
"active": "actif",
"actif": "actif",
"client inactif": "inactif",
"inactive": "inactif",
"inactif": "inactif"
})
)L’ordre compte vraiment. Je répare le texte, ensuite je standardise. Si je fais l’inverse, je risque de créer des règles de remplacement pour des valeurs qui n’auraient jamais dû exister.
Ce nettoyage semble minuscule. Franchement, c’est rarement la partie la plus sexy d’un projet data. Mais chez un client, j’ai déjà vu un simple “Actif” mal encodé créer des regroupements faux, des dashboards incohérents et des segments marketing cassés. Quelques lignes comme celles-là évitent beaucoup de bruit.
Comment voir les problèmes avant trop tard ?
Ydata-profiling sert à voir rapidement les problèmes de qualité avant d’écrire trop de code de nettoyage. C’est souvent le premier réflexe que j’ai juste après l’ingestion d’un fichier CSV, d’une table SQL ou d’un export un peu douteux.
Ydata-profiling, anciennement pandas-profiling, génère un rapport exploratoire à partir d’un DataFrame pandas. Un DataFrame, c’est simplement une table en mémoire, avec des lignes et des colonnes. Le rapport vous donne une vue assez directe de ce qui cloche, sans avoir à écrire dix cellules de notebook pour vérifier chaque colonne à la main.
Dans ce rapport, je regarde surtout ces signaux-là :
- Les valeurs manquantes, pour voir quelles colonnes sont vraiment exploitables.
- Les doublons, surtout quand une ligne est censée représenter un client, une commande ou un événement unique.
- Les distributions déséquilibrées, par exemple une variable avec 98 % de la même valeur.
- Les variables catégorielles avec forte cardinalité, c’est-à-dire trop de valeurs différentes, comme des libellés saisis librement.
- Les corrélations, utiles pour repérer des colonnes redondantes ou suspectes.
- Les types détectés, parce qu’une date lue comme du texte, ça arrive tout le temps.
- Les valeurs extrêmes, qui peuvent être de vraies anomalies ou juste des cas métier rares.
from ydata_profiling import ProfileReport
profile = ProfileReport(df, title="Data quality report")
profile.to_file("data_quality_report.html")Je le place juste après l’ingestion, avant les grosses règles de nettoyage. C’est important. Ydata-profiling ne remplace pas l’analyse métier. Il ne sait pas si un montant négatif est une erreur, un remboursement ou une règle comptable normale. Il sert plutôt de détecteur rapide de signaux faibles. Il vous aide à choisir où concentrer l’effort.
Dans un workflow propre, je m’en sers pour repérer les colonnes inutilisables, confirmer les doublons, voir quelles colonnes méritent un nettoyage avec pyjanitor, lesquelles ont besoin de ftfy pour corriger du texte mal encodé, et lesquelles doivent passer par des règles de validation plus strictes. J’ai vu des équipes gagner des heures juste avec ça, parce qu’elles arrêtaient de nettoyer au hasard.
Voir les problèmes, c’est déjà beaucoup. Mais ça ne suffit pas. Le vrai sujet ensuite, c’est d’empêcher ces problèmes de revenir à chaque nouvel import.
Comment bloquer les mauvaises données ?
Great Expectations et Pandera permettent de bloquer les mauvaises données en transformant les règles qualité en contrôles exécutables. C’est ça le point clé. Au lieu de “faire confiance” à un fichier CSV, une table SQL ou un DataFrame, je pose des règles, et le pipeline s’arrête si les données ne les respectent pas.
Great Expectations fonctionne avec des “expectations”, c’est-à-dire des attentes explicites sur vos données. Une colonne doit exister. Un type doit être respecté. Une valeur doit appartenir à une liste. Une clé doit être unique. Un email doit matcher une regex, donc un modèle de texte. Une distribution ne doit pas dériver trop fortement par rapport à l’historique. C’est très pratique quand la qualité doit être visible par plusieurs équipes, parce que l’outil génère des rapports HTML, les fameux Data Docs, et peut lancer des checkpoints dans Airflow, Prefect ou d’autres orchestrateurs. Il marche avec pandas, Spark et des bases SQL.
import great_expectations as gx
df = gx.from_pandas(df)
df.expect_column_values_to_not_be_null("email")
df.expect_column_values_to_be_unique("customer_id")
result = df.validate()
Pandera, lui, est plus “schema-first”. Je déclare le schéma attendu d’un DataFrame pandas, puis je valide. Colonnes, types, valeurs autorisées, nullables, bornes min ou max… Tout est dans le code Python, donc c’est très naturel dans un pipeline data. Je l’utilise souvent aux frontières du pipeline, juste après ingestion ou juste avant écriture. Ça évite de propager une erreur bête pendant 12 étapes, ce que j’ai déjà vu chez un client avec une colonne prix passée en texte après un export Excel.
import pandera as pa
from pandera import Column, Check, DataFrameSchema
schema = DataFrameSchema({
"age": Column(int, Check.ge(18), nullable=False),
"status": Column(str, Check.isin(["active", "inactive"]), nullable=False),
})
validated_df = schema.validate(df)
Ma règle simple : Pandera est excellent dans du code Python data, surtout avec pandas. Great Expectations devient très fort quand je veux documenter, partager et industrialiser les contrôles qualité.
| Bibliothèque | Usage principal | Meilleur moment dans le pipeline | Bénéfice concret |
| pyjanitor | Nettoyage lisible des DataFrames | Après chargement des données | Code plus propre et transformations plus faciles à relire |
| ftfy | Correction des problèmes d’encodage texte | À l’ingestion | Moins de caractères cassés et de textes inutilisables |
| ydata-profiling | Analyse automatique de la qualité | Avant nettoyage ou audit | Vue rapide des valeurs manquantes, doublons et anomalies |
| Great Expectations | Contrôles qualité documentés | Avant production ou entre étapes critiques | Règles partageables, rapports HTML et blocage automatisé |
| Pandera | Validation de schémas pandas | Aux frontières du pipeline Python | Erreurs détectées tôt, directement dans le code |
Et si vos données arrêtaient de casser vos analyses ?
Pour moi, le bon nettoyage de données Python, ce n’est pas empiler des fonctions pandas jusqu’à ce que ça passe. C’est organiser le travail. pyjanitor rend les transformations lisibles. ftfy répare les textes avant qu’ils polluent les catégories. ydata-profiling montre vite où sont les problèmes. Great Expectations et Pandera posent des garde-fous pour éviter les mauvaises surprises en production.
Le vrai bénéfice, c’est simple : vous passez moins de temps à corriger les mêmes erreurs, et plus de temps à exploiter des données fiables pour vos analyses, vos modèles IA et vos décisions business.
FAQ
- Quelle bibliothèque Python choisir pour nettoyer un DataFrame pandas ?
Je choisirais pyjanitor si le besoin principal est de rendre le nettoyage plus lisible. Il garde la logique pandas, mais ajoute des fonctions pratiques comme clean_names() et une écriture chaînable beaucoup plus agréable à maintenir. - À quoi sert ftfy dans un pipeline data ?
ftfy sert à réparer les textes mal encodés et certains problèmes Unicode. C’est très utile sur des données web, des exports anciens ou des contenus utilisateurs. Je l’utilise avant de standardiser les catégories, sinon on nettoie parfois sur une base déjà abîmée. - ydata-profiling remplace-t-il une analyse exploratoire ?
Non, pas vraiment. ydata-profiling accélère l’analyse exploratoire en montrant rapidement les valeurs manquantes, doublons, distributions, corrélations et anomalies possibles. Mais il ne remplace pas le jugement métier. Il aide surtout à savoir où regarder en premier. - Great Expectations et Pandera font-ils la même chose ?
Ils se recoupent, mais je ne les vois pas exactement pareil. Pandera est très pratique pour valider des schémas de DataFrame directement dans du code Python. Great Expectations va plus loin sur la documentation, les rapports HTML, les Data Docs et l’intégration dans des pipelines orchestrés. - Faut-il utiliser toutes ces bibliothèques dans un même projet ?
Pas forcément. Je pars du problème. Si les colonnes sont sales, pyjanitor. Si le texte est cassé, ftfy. Si je veux comprendre vite la qualité d’un dataset, ydata-profiling. Si je veux empêcher les mauvaises données d’entrer dans le pipeline, Great Expectations ou Pandera.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en Tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’accompagne des équipes data, marketing et produit sur des sujets très concrets : fiabiliser la donnée, automatiser les contrôles, industrialiser les workflows et rendre les analyses vraiment exploitables. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez mettre de l’ordre dans vos données et vos automatisations, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.