Notebooks vs scripts, et l'art de profiler

Le notebook n'est pas ton ennemi

Le réflexe backend, c'est de mépriser Jupyter : état global mutable, cellules exécutées dans le désordre, pas de tests, du JSON indiffable en git. Tout est vrai. Et pourtant le notebook est le bon outil pour explorer : feedback immédiat, graphiques inline, itération à la seconde sur des données chargées une fois.

La règle des équipes saines :

• Notebook = exploration, analyse ponctuelle, prototypage, communication de résultats ;
• Script/module testé = tout ce qui est exécuté plus d'une fois ou par quelqu'un d'autre (pipeline, entraînement, serving).

Le travail du MLE, c'est précisément la migration notebook → code de prod : extraire les fonctions, les typer, les tester, paramétrer ce qui était codé en dur.

Profiler : mesure, ne devine pas

En data, l'intuition de perf est presque toujours fausse (la lenteur est rarement où on croit : souvent I/O, sérialisation, ou une conversion de types silencieuse). Les outils, du plus simple au plus fin :

1. time.perf_counter() autour d'un bloc — le réflexe minimal ;
2. %timeit (notebook) — micro-benchmarks fiables avec répétitions ;
3. cProfile + snakeviz — qui appelle quoi, combien de fois ;
4. py-spy — profiler sans instrumenter, attachable à un process en prod (le perf top du Python) ;
5. memray — pour la mémoire (les 10 Go du DataFrame de la leçon pandas).