Leçon 3 — Notebooks et méthode de travail
Un notebook est un document où alternent des cellules de code, leurs résultats et du texte explicatif. C'est l'outil de travail par défaut de l'expérimentation en IA, il explique une partie de l'adoption de Python dans la recherche, et il tend un piège que presque tout le monde se prend au moins une fois.
Pourquoi les notebooks ont remplacé les scripts
Le travail en machine learning n'est pas linéaire. Vous chargez des données, vous regardez, vous ne comprenez pas une distribution, vous tracez un graphique, vous corrigez une colonne, vous relancez le modèle, vous changez un réglage. Ce cycle est fait d'aller-retours.
Un script ordinaire impose de tout réexécuter depuis le début à chaque modification. Quand le chargement des données prend deux minutes, cela devient insupportable : vous passez la journée à attendre.
Un notebook garde les variables en mémoire entre les exécutions. Vous chargez les données une fois, puis vous itérez sur les cellules suivantes autant que vous voulez. Les graphiques s'affichent à côté du code qui les produit, et le raisonnement reste lisible des semaines plus tard.
C'est aussi ce qui en fait un excellent support de communication : un notebook bien tenu est à la fois l'analyse, sa démonstration et son rapport.
Jupyter en local, Colab dans le navigateur
Deux façons de travailler, avec un arbitrage simple.
| Jupyter en local | Google Colab | |
|---|---|---|
| Installation | Python et bibliothèques sur votre machine | rien, un navigateur suffit |
| Processeur graphique | celui que vous possédez | GPU prêté gratuitement |
| Données confidentielles | restent chez vous | transitent chez un tiers |
| Session | permanente | expire après une période d'inactivité |
| Bon pour | projets durables, données sensibles | apprendre, essayer, partager |
Pour apprendre, commencez par Colab. Les bibliothèques sont déjà installées, le GPU est offert, et vous évitez la première heure décourageante passée à faire fonctionner un environnement. Pour un projet réel, surtout avec des données que vous n'avez pas le droit d'envoyer ailleurs, il faut un environnement local — c'est l'objet de la leçon 5.
Le piège : l'état caché
Voici le problème que tout le monde rencontre, et il vaut la peine de le comprendre avant de le vivre.
Les cellules d'un notebook s'exécutent dans l'ordre que vous choisissez, pas dans l'ordre où elles sont écrites. Rien ne vous empêche d'exécuter la cellule 5, puis la 2, puis de modifier la 3 et de relancer la 5. La mémoire garde le résultat de tout cela, et le document affiché ne raconte plus ce qui s'est réellement passé.
Conséquence : un notebook peut afficher des résultats corrects et être incapable de les reproduire. Vous le fermez, vous le rouvrez le lendemain, vous exécutez tout de haut en bas, et il plante — ou pire, il donne un autre résultat.
Avant de faire confiance à un résultat, ou de le montrer à quelqu'un : redémarrez le noyau et exécutez tout de haut en bas. Si cela ne repasse pas, le résultat n'existe pas. Cette habitude coûte trente secondes et évite des conclusions fausses présentées en réunion.
Les autres pièges, plus discrets
Le notebook devenu logiciel. Un notebook de huit cents lignes avec vingt fonctions dedans n'est plus un carnet d'expérimentation, c'est une application mal rangée. Dès qu'un morceau de code est réutilisé, il doit sortir dans un fichier .py importé par le notebook. Le notebook garde l'exploration, le fichier garde la logique.
L'absence de gestion de versions utilisable. Un notebook est un fichier JSON contenant le code, les résultats et des métadonnées d'exécution. Deux versions diffèrent sur des centaines de lignes même si vous n'avez changé qu'un mot, ce qui rend les comparaisons Git illisibles. Vider les sorties avant d'enregistrer, ou utiliser un outil dédié, rend les révisions à nouveau lisibles.
Le chemin absolu. C:\Users\vous\Bureau\donnees.csv fonctionne chez vous et nulle part ailleurs. Un chemin relatif au projet est la seule forme partageable.
Comment travailler proprement, en pratique
Une méthode qui fonctionne et qui n'a rien de compliqué :
- Un notebook par question, pas un notebook pour tout le projet. « Explorer les données », « comparer trois modèles », « analyser les erreurs » sont trois documents.
- Numérotez-les :
01-exploration.ipynb,02-nettoyage.ipynb. L'ordre de lecture devient évident pour quelqu'un d'autre — et pour vous dans trois mois. - Sortez le code réutilisé dans un dossier
src/et importez-le. - Fixez les graines aléatoires au début, sinon deux exécutions ne donnent pas le même résultat et vous ne saurez pas si une amélioration vient de votre changement ou du hasard.
- Redémarrez et exécutez tout avant de conclure quoi que ce soit.
- Quand le projet doit tourner tout seul, sortez du notebook : un modèle qui doit être réentraîné chaque nuit appartient à un script versionné et testé, pas à un carnet. C'est le sujet du cours MLOps.
En trois phrases
Le notebook s'est imposé parce que le travail en IA est fait d'aller-retours et qu'il garde les variables en mémoire entre deux exécutions, ce qu'un script ne fait pas. Son défaut est l'état caché : les cellules s'exécutant dans l'ordre que vous voulez, un notebook peut afficher un résultat qu'il est incapable de reproduire, ce que seul un redémarrage suivi d'une exécution complète permet de vérifier. Il reste l'outil de l'exploration, et tout code réutilisé ou automatisé doit en sortir.
Suite — Leçon 4 : scikit-learn, l'interface qui a tout standardisé →