La phrase de jugement
Pandas reste l’outil de l’analyste sur une machine ; dès que le volume dépasse la RAM, ou que le pipeline doit être partagé entre plusieurs nœuds, on change d’outil — on n’optimise plus le DataFrame.
Cette phrase tient l’entretien. Le reste est la nuance, pas un catalogue.
Ce que « ne suffit plus » veut dire concrètement
Trois signaux, pas un benchmark Twitter :
- Le jeu utile ne tient pas en mémoire après un typage raisonnable (
usecols, category, Parquet). Les chunks ne suffisent plus parce que le résultat lui-même, ou le join, explose.
- Le temps d’une itération dépasse le délai de décision. Un correctif de règle à 45 minutes le rend inobservable. Ce n’est plus un problème de syntaxe.
- L’exécution doit être celle d’une plateforme : reprise, isolation, plusieurs téraoctets, plusieurs équipes. Là, ce n’est plus Polars dans un notebook.
Où vous allez, sans en faire un débat religieux
- Polars (ou DuckDB) : même machine, souvent la même question, moteur lazy, moins de copies, plus proche de SQL / Arrow. Premier réflexe quand Pandas est lent mais que tout tient encore, ou presque, sur un poste ou un job unique.
- Spark (ou l’équivalent de la plateforme) : dès que vous avez besoin d’un cluster, d’un catalogue, d’un ordonnanceur. Le coût opérationnel n’est pas un détail — c’est pour ça qu’on ne « met pas Spark » sur 800 Mo.
- La base : parfois le bon outil n’est pas un DataFrame. Une agrégation que Postgres ou BigQuery fait en place évite d’extraire.
Vous ne fuyez pas Pandas par snobisme. Vous le quittez quand la contrainte n’est plus l’API, c’est la machine ou l’organisation.
La relance
« Vous avez déjà réécrit un job Pandas ? »
Répondez par le critère, pas par le framework : « le join ne tenait plus ; on a poussé le filtre et l’agrégation dans le moteur colonnaire ; Pandas n’a gardé que le contrôle. » Un candidat qui cite Spark sans avoir mesuré la RAM n’a pas tranché, il a suivi une mode.