DataGyver #6 : Les notebooks sont-ils obsolètes ?
Les notebooks traditionnels, oui. Mais une nouvelle génération d'outils révolutionne complètement l'expérience.
Hello ! Vous êtes 772 à me suivre, merci pour votre confiance !
Après plusieurs années à regarder mes collègues se battre avec les conflits Git de Jupyter, les états cachés qui cassent la reproductibilité, et la gymnastique pour déployer un simple prototype, j'ai découvert Marimo et ça change tout.
Le problème que personne ne veut avouer
36% des notebooks Jupyter sur GitHub ne s'exécutent pas. Cette statistique de reproductibilité fait mal, mais elle reflète notre réalité quotidienne : ordre d'exécution chaotique, variables fantômes, JSON impossible à merger proprement.
Le format .ipynb de Jupyter est le coupable principal. Ce mélange JSON/métadonnées/outputs crée des conflits Git apocalyptiques. L'état caché est l'autre fléau : variables définies dans une cellule supprimée, ordre d'exécution non-linéaire, résultats qui dépendent de l'historique invisible.
L'architecture révolutionnaire de Marimo
Marimo résout ces problèmes fondamentaux avec des innovations techniques vérifiables :
1. Python pur : Les notebooks sont stockés en fichiers .py standards, éliminant les conflits JSON. Le versioning Git devient naturel.
2. Réactivité native : Contrairement à Jupyter qui maintient un état global persistent, Marimo recalcule automatiquement les cellules dépendantes lors de modifications. Plus d'états cachés possibles. C’est instantané et très appréciable.
3. SQL first-class : Marimo intègre des cellules SQL natives avec support DuckDB par défaut, plus connecteurs PostgreSQL, MySQL, SQLite, Snowflake et BigQuery. Aucune extension requise. Magique !
4. IA intégrée : Assistant IA avec support GitHub Copilot, OpenAI, Anthropic, Google Gemini et Ollama, il y en a pour tous les goûts :)
5. Déploiement unifié : Un même notebook peut être :
Notebook interactif (
marimo edit)Application web (
marimo run)Script Python (
python notebook.py)
Adoption vérifiée en production
Stanford Linear Accelerator (SLAC) utilise Marimo pour leurs workflows de recherche scientifique. Marimo Labs a levé 5 M$ en série A, confirmant la traction commerciale. De plus, les 15K étoiles GitHub en 10 mois indiquent une adoption rapide et ça se comprend.
Cas concret : simulateur de prêt immobilier
Pour illustrer les capacités de Marimo, j'ai développé un simulateur de prêt complet :
Ce simulateur démontre :
Comparaison de 3 scénarios avec paramètres en temps réel
Graphiques réactifs (capital restant, intérêts, répartition)
Export des données intégré
Déploiement immédiat via
marimo run
Plus impressionnant : le même fichier .py sert de notebook de développement ET d'application web de production. Zéro conversion, zéro duplicata.
Marimo vs l'écosystème existant
Marimo vs Jupyter :
SQL natif vs extensions multiples
Fichiers .py vs JSON complexe
Réactivité automatique vs état global
Déploiement direct vs nbconvert + framework
Marimo vs Streamlit :
Même fichier développement/production vs séparation
Réactivité granulaire vs re-exécution complète (voir partielle)
Support notebook natif vs approche script
Passer à l'action
Pour l’installation, rien de plus simple : pip install marimo
Il est possible de faire un test immédiat : marimo tutorial intro (en gros 10 minutes pour comprendre)
Migration strategy :
Phase test (1 semaine) : Convertir un notebook existant avec
marimo convertPhase pilote (1 mois) : Nouveau projet from scratch en Marimo
Phase adoption (3 mois) : Migration progressive des projets actifs
Trois cas d'usage immédiats :
Dashboards internes remplaçant Streamlit
Analyses récurrentes avec paramètres variables
Prototypes clients déployables en production
Limitations actuelles
Marimo reste jeune (lancé fin 2023) avec un écosystème d'extensions plus limité que Jupyter. Certains widgets spécialisés nécessitent des adaptations. La migration demande l'apprentissage du paradigme réactif.
Mais les gains sont mesurables : reproductibilité garantie, conflits Git éliminés, déploiement simplifié.
🚀 Actualité Side Projects : SQLMastery
J’ai décidé d’ajouter à ma Newsletter une partie actualité sur les quelques side projects que j’ai en ce moment. Aujourd’hui je fais un point sur SQLMastery et sur l’évolution du POC vers la production.
Le projet a traversé trois incarnations : prototype Gradio, app développée avec Claude, puis POC Replit... Et après l’effet Waou, l’effet WTF. L’app nécessite (pas mal) de travail pour être mise en prod. Mais au moins cette base m'a permis d'identifier les vrais besoins utilisateurs.
Refonte complète en cours : Architecture Flask modulaire, sécurité niveau entreprise (JWT, rate limiting), monitoring avec alertes, et suite de tests complète.
Beta test : 127 candidatures récoltées ! Je sélectionne 20 profils pour la beta privée. Les autres candidats auront un accès anticipé via cette newsletter avant l'ouverture publique.
Timeline : Beta fermée fin juillet, feedback intégré en août, lancement progressif septembre.
Si vous voulez tirer pleinement profit de cette newsletter, je vous propose un petit défit : Installez Marimo et convertissez un de vos notebooks Jupyter. Mesurez la différence en termes de reproductibilité et facilité de déploiement.
Le simulateur de prêt est open source - n'hésitez pas à le forker pour vos propres besoins !
À bientôt, Gaël
Ressources :