Notebooks Marimo

Notebooks Python réactifs, isolés et gouvernés, limités à un espace de travail et à ses données gérées.

Les notebooks Marimo sont des notebooks Python réactifs exécutés dans votre cluster Scrydon. Ils appartiennent à un espace de travail, utilisent les mêmes règles d'accès que la plateforme et n'exigent pas de stack data science séparée.

Ouvrir d'abord, démarrer le calcul à la demande

L'ouverture d'un notebook est séparée de l'exécution Python. Scrydon authentifie la page, lit le document et affiche immédiatement les cellules Marimo natives et modifiables, sans démarrer de noyau ni allouer de machine isolée. Le statut reste Non connecté.

Le calcul démarre de deux façons :

Connecter prépare un runtime isolé, réconcilie les dépendances et connecte le noyau sans exécuter de cellule.
Exécuter une cellule hors connexion suit la même préparation, puis transmet cette exécution une seule fois lorsque le noyau est prêt.

Les deux chemins affichent les phases : autorisation, provisionnement du calcul isolé, chargement de la source, synchronisation des dépendances, connexion au stockage gouverné et prêt. Les clics répétés, les nouvelles tentatives du navigateur et les onglets concurrents ne créent pas de runtimes en double.

Les modifications effectuées avant la connexion font partie de la source envoyée au runtime. Ouvrir ou modifier le document n'installe aucun paquet et ne crée aucune délégation de stockage.

Périmètre et identité

Un notebook appartient à un espace de travail et agit au nom de l'utilisateur qui l'a ouvert :

le document ouvert ne reçoit aucun droit de calcul ou de stockage ;
lors d'une demande de calcul, Scrydon crée une délégation courte, liée au notebook et à la génération du runtime, uniquement dans un broker de confiance ;
le noyau Python ne reçoit ni jeton bearer, ni mot de passe de base de données, ni secret cloud, ni identité Dapr, ni jeton Kubernetes ;
chaque lecture et écriture revérifie l'appartenance et les politiques actives, applique les masques de colonnes et produit un événement d'audit.

Il n'existe aucun super-utilisateur marimo-admin qui contourne la gouvernance.

SDK `scrydon`

La bibliothèque Python scrydon est préinstallée :

from scrydon import tables

tables.list()
df = tables.read("suppliers", limit=10_000)
tables.write("suppliers", df, mode="append")
tables.create(
    "supplier_risk_scores",
    scores_df,
    classification="internal",
    exist_ok=True,
)

Les masques et filtres sont appliqués côté plateforme. Si votre rôle voit une valeur masquée, tables.write refuse de la réécrire afin d'éviter de corrompre la donnée.

Les objets de l'espace de travail sont aussi disponibles via des opérations bornées et l'interface standard fsspec :

from scrydon import fsspec, storage

with fsspec.open("workspace://reports/summary.json", "rb") as source:
    summary = source.read()

content, digest = storage.read_bytes_with_digest("reports/summary.json")
storage.write_bytes(
    "reports/summary.json",
    updated_content,
    expected_sha256=digest,
)

Le digest attendu empêche un onglet ou un job d'écraser une version plus récente. Relisez la version courante, fusionnez vos changements, puis réessayez.

Le SDK expose également les instances d'ontologie, la recherche de connaissances, les intégrations LLM, les embeddings, l'OCR, la transcription, la synthèse vocale et les outils activés par l'organisation. Les identifiants fournisseurs restent côté serveur.

Création, partage et réactivité

Dans Analytics → Notebooks, créez un notebook à partir du modèle, importez un fichier Marimo .py ou installez un notebook fourni par un pack. Les notebooks sont limités à l'espace de travail.

La réactivité Marimo réexécute les cellules dépendantes lorsqu'une entrée change. Un membre qui ouvre un notebook partagé exécute les requêtes avec sa propre identité et ses propres masques ; il ne reçoit pas les résultats mis en cache d'un utilisateur plus habilité.

Jobs de notebook

Un lancement de pipeline utilise un workload isolé neuf et à usage unique. Il ne réutilise ni les variables, ni les fichiers, ni le noyau de la session interactive. Le workload est supprimé après succès, échec ou annulation.

Pour une planification stable ou un déclencheur de production, appelez ce job depuis un workflow ou une automatisation.

Dépendances Python et sortie réseau

Le runtime part d'une image épinglée. Les dépendances propres au notebook sont dérivées des métadonnées standard de Marimo, y compris un bloc PEP 723, puis réconciliées avec uv avant que le noyau soit déclaré prêt.

marimo et scrydon sont gérés par la plateforme. Vous pouvez conserver des contraintes de version compatibles dans les métadonnées PEP 723, mais le code du notebook ne peut ni installer une autre version ni demander des extras pour ces paquets. Si le notebook exige une version plus récente que celle du runtime, la préparation signale des métadonnées de dépendances invalides au lieu de démarrer un noyau incompatible.

Pour ajouter un paquet :

ajoutez son import ou déclarez-le dans le bloc PEP 723 ;
choisissez Connecter ou exécutez la cellule ;
Scrydon résout l'environnement avant l'exécution.

Ne dépendez pas d'un paquet installé manuellement mais absent de la source : un runtime de remplacement et un job repartent toujours de l'image épinglée.

Pour PyPI public, la politique de sortie de l'organisation doit autoriser pypi.org et files.pythonhosted.org. Un hôte refusé fait échouer la préparation avant l'exécution de la cellule.

Consultez Gouvernance de la sortie réseau des notebooks pour configurer les domaines autorisés.

Échecs et reprise sûre

Isolation indisponible : aucun niveau de calcul qualifié ne satisfait la politique. Scrydon ne bascule jamais sur le processus Analytics.
Dépendance refusée : l'index ou l'hôte de téléchargement n'est pas autorisé.
Préparation échouée ou expirée : choisissez Réessayer. Une nouvelle génération clôturée remplace et nettoie l'ancienne.
Conflit de source : un autre onglet ou job a enregistré une version plus récente. Rechargez et fusionnez.
Connexion obsolète : reconnectez-vous après un remplacement ou la suppression pour inactivité. L'ancien bail ne peut pas rejoindre le nouveau runtime.

Après la frontière d'exécution, Scrydon ne rejoue jamais automatiquement une cellule dont le résultat est ambigu.

À retenir

L'ouverture du document est rapide et sans calcul.
Connecter prépare un noyau sans exécuter de cellule.
Exécuter hors connexion prépare le même runtime et transmet la cellule sélectionnée une seule fois.
Le runtime est isolé selon la politique active et ne contient aucun secret de plateforme.
Les jobs utilisent toujours un calcul neuf et à usage unique.