Pandas 2.0 : ce que tout Data Analyst doit savoir sur la nouvelle version

Pandas avant 2.0 : les limites qui frustraient tout le monde

Pandas a longtemps souffert de deux problèmes principaux. D'abord, les performances : sur des DataFrames de plusieurs millions de lignes, certaines opérations devenaient péniblement lentes comparées à des outils comme Polars ou DuckDB. Ensuite, le comportement imprévisible du SettingWithCopyWarning : ce message que tout le monde a vu et que personne ne comprenait vraiment.

Pandas 2.0 s'attaque directement à ces deux problèmes.

PyArrow comme backend : ce que ça change

Le changement le plus structurel de Pandas 2.0 est la possibilité d'utiliser Apache Arrow comme backend de stockage des données, à la place du backend NumPy traditionnel. Arrow est un format colonnaire en mémoire conçu pour être rapide et interopérable entre différents outils.

En pratique, ça signifie :

• Moins de mémoire utilisée grâce à un stockage plus efficace, notamment pour les chaînes de caractères
• Des performances nettement meilleures sur les opérations de filtrage, de groupby et de jointure
• Une interopérabilité native avec d'autres outils Arrow comme DuckDB, Polars, ou les fichiers Parquet

import pandas as pd

# Créer un DataFrame avec le backend PyArrow
df = pd.read_csv('donnees.csv', dtype_backend='pyarrow')

# Ou convertir un DataFrame existant
df_arrow = df.convert_dtypes(dtype_backend='pyarrow')

# Les types Arrow sont préfixés avec [pyarrow]
print(df_arrow.dtypes)
# nom         string[pyarrow]
# age          int64[pyarrow]
# montant     double[pyarrow]

Copy-on-Write : la fin du SettingWithCopyWarning

Le SettingWithCopyWarning était l'une des sources de confusion les plus fréquentes en Pandas. Il apparaissait quand vous tentiez de modifier un sous-ensemble d'un DataFrame et que Pandas n'était pas sûr que la modification affecterait l'original ou une copie.

Pandas 2.0 introduit le Copy-on-Write (CoW) pour régler ce problème définitivement. Avec CoW, tout sous-ensemble d'un DataFrame est toujours traité comme une copie indépendante. Modifier une copie ne modifie jamais l'original.

import pandas as pd
pd.options.mode.copy_on_write = True  # Activer CoW (sera par défaut en Pandas 3.0)

df = pd.DataFrame({'A': [1, 2, 3], 'B': [4, 5, 6]})
sous_ensemble = df[df['A'] > 1]

# Avec CoW, cette modification n'affecte pas df
sous_ensemble['B'] = 99

print(df)    # df est inchangé
print(sous_ensemble)  # seul sous_ensemble est modifié

Ce comportement sera activé par défaut dans Pandas 3.0. En attendant, vous pouvez l'activer manuellement pour préparer votre code à la migration.

Les nouveaux types de données nullable

Pandas 2.0 améliore aussi la gestion des valeurs manquantes avec des types entiers et booléens qui supportent nativement les NA (Not Available), contrairement au comportement historique qui convertissait les entiers en flottants dès qu'une valeur manquante apparaissait.

# Avant Pandas 2.0 : un NA dans une colonne entière force la conversion en float
df_avant = pd.DataFrame({'age': [25, None, 30]})
print(df_avant.dtypes)  # age    float64 (conversion forcée)

# Avec les nouveaux types nullable
df_apres = pd.DataFrame({'age': pd.array([25, None, 30], dtype='Int64')})
print(df_apres.dtypes)  # age    Int64 (entier nullable)

Ce qui a changé dans l'API : les points de vigilance

Pandas 2.0 a supprimé certaines fonctionnalités dépréciées. Si vous avez un code existant, voici les changements qui peuvent casser votre code :

• Suppression de DataFrame.append() : utilisez pd.concat() à la place
• Suppression de swaplevel() sur les axes d'un groupby : reorganisez vos opérations
• Changement du comportement de fillna() : la propagation entre dtypes a changé dans certains cas
• Les index non homogènes sont maintenant rejetés dans plus de situations

Faut-il migrer maintenant ?

Si vous maintenez un code Pandas en production, voici ma recommandation pratique :

• Mettez à jour vers Pandas 2.x sur un environnement de test et lancez votre suite de tests. La plupart des codes "raisonnables" fonctionnent sans modification.
• Activez pd.options.mode.copy_on_write = True pour identifier les endroits de votre code qui dépendent du comportement d'avant.
• Testez le backend PyArrow sur vos cas d'usage les plus gourmands pour mesurer le gain de performance réel sur vos données.

Pour les nouveaux projets, démarrez directement avec les nouveaux types nullable et le backend PyArrow si votre usage le justifie. Vous économiserez une migration future.

Pandas vs Polars : la vraie question

Avec Pandas 2.0, l'écart de performance avec Polars (la bibliothèque qui a beaucoup fait parler d'elle ces deux dernières années) se réduit significativement, notamment avec le backend PyArrow. Pour la grande majorité des Data Analysts, Pandas 2.0 reste le bon choix : l'écosystème est plus mature, la documentation plus riche et la compatibilité avec les autres outils (Scikit-learn, Matplotlib, Power BI via Python) reste meilleure.

Polars mérite l'attention si vous travaillez sur des volumes vraiment très importants (plusieurs dizaines de millions de lignes) ou si la performance est votre contrainte principale. Mais pour la plupart des projets data analytics, Pandas 2.0 fait très bien le travail.