Cas d’usage · Recherche
Un notebook qui devient un job planifié, gouverné et suivi
Vos data scientists explorent dans Jupyter ou VS Code. Quand un notebook donne un résultat utile, il devient un job planifié et versionné dans Git, avec ses droits, ses coûts et son suivi, sans être réécrit. Le datalab reste le lieu de l’exploration ; graal prend le relais pour la production.
Le défi
L’exploration fonctionne, la production attend
- Des notebooks prometteurs qui ne tournent que dans l’espace de leur auteur.
- Une mise en production qui passe par une réécriture, et souvent par une autre équipe.
- Des droits, des coûts et des traces à justifier projet par projet.
- Un datalab qui doit rester libre pour explorer.
Comment graal le traite
Du notebook au traitement planifié
Étape 01
Explorer
Jupyter et VS Code s’ouvrent dans le navigateur, derrière votre SSO, avec accès aux tables du lakehouse et au stockage S3 du projet.
Étape 02
Versionner
Le notebook est enregistré dans le dépôt Git du projet. Chaque modification est un commit, relisible et réversible.
Étape 03
Planifier
Le même notebook s’exécute tel quel en job. Il s’enchaîne à d’autres étapes dans un workflow planifié, avec reprises et alertes.
Étape 04
Suivre
À chaque run, le notebook exécuté est conservé avec ses sorties ; les modèles produits entrent au registre.
Étape 05
Gouverner
Droits et coûts par projet, validation humaine avant le passage en production : chaque mise en service a un responsable.
Le scénario type : une équipe d’études ou de recherche qui explore dans un datalab, et dont quelques traitements doivent désormais tourner chaque semaine, avec un responsable et un budget. graal ne remplace pas le datalab, il le complète : ce qui a été exploré d’un côté s’industrialise de l’autre, sans changer d’outil de travail.
Onyxia est un datalab libre (licence MIT), développé par l’INSEE et soutenu par la DINUM. graal le complète : Onyxia pour explorer, graal pour industrialiser.
Ce que vous obtenez
- Des notebooks en production sans réécriture
- Un historique Git de chaque traitement
- Des runs planifiés, suivis et relancés automatiquement en cas d’échec
- Des coûts et des droits lisibles, projet par projet
Ce qui reste chez vous
- Les notebooks et leur historique Git
- Les données, sur votre stockage S3
- Les notebooks exécutés et les modèles
Capacités mobilisées
- Notebooks
Jupyter et VS Code derrière votre SSO.
- Orchestration et calcul
Jobs notebook, workflows, cron, reprises et alertes.
- Machine learning
Registre des modèles produits par les runs.
- Gouvernance
Droits, coûts et validation par projet.
- Ouverture
Git, API REST et formats ouverts.
Questions fréquentes
Faut-il abandonner notre datalab ?
Non. Les deux cohabitent : le datalab pour explorer, graal pour planifier, gouverner et suivre ce qui passe en production. Ils peuvent s’appuyer sur le même stockage S3.
Nos notebooks doivent-ils être réécrits ?
Non. Un notebook s’exécute tel quel en job ; ses paramètres se passent au lancement, et le notebook exécuté est conservé avec le run.
Qui peut passer un traitement en production ?
Les personnes à qui le projet en donne le droit. Vous pouvez exiger une validation humaine avant chaque mise en production.
Industrialisez vos premiers notebooks
En 8 semaines, un premier traitement exploré passe en production, dans votre infrastructure.