Des notebooks sur du compute isolé
Python sur vos données gouvernées, dans un notebook qui démarre en quelques secondes, s'exécute sur son propre compute isolé et est détruit quand vous le fermez. Pas de kernel partagé, aucune copie sur un ordinateur portable.
Son propre compute isolé
Chaque session de notebook démarre dans une microVM isolée avec une enveloppe déclarée de CPU, de mémoire et de stockage — jamais de kernel partagé, et détruite à la fin de la session.
Accès aux données gouverné
Les notebooks lisent via l'ontologie sous la même identité et la même politique que toute autre charge de travail : personne n'obtient de porte dérobée privée vers le Lakehouse.
Réactifs et reproductibles
Changez une valeur et tout ce qui en dépend se réexécute ; les dépendances sont déclarées avec le notebook, qui se comporte donc de la même façon pour la personne suivante qui l'ouvre.
Un notebook, c'est là où un analyste ou un data scientist travaille réellement : écrire un peu de Python, regarder les données, les tracer, décider quoi faire. La partie délicate a toujours été de savoir où ce code s'exécute et ce qu'il peut atteindre. Ici, il s'exécute à l'intérieur de la plateforme, sur du compute qui n'appartient à personne d'autre, sur des données que vous êtes déjà autorisé à voir — et il ne laisse rien derrière lui.
À lire si vous êtes analyste, data scientist ou ingénieur et que vous avez besoin de vrai code sur de vraies données, dans un environnement que votre équipe sécurité peut valider.
Les notebooks sont des environnements Python interactifs qui s'exécutent à l'intérieur de la plateforme sur du compute isolé par session, lisent des données gouvernées et ancrées dans l'ontologie via les mêmes permissions que toute autre charge de travail, avec des dépendances reproductibles et sans runtime persistant à compromettre.
Toute organisation qui prend l'analytique au sérieux finit avec des notebooks, et toute équipe sécurité finit par s'en inquiéter : un serveur Jupyter partagé qui accumule des identifiants, ou pire, une copie des données sur l'ordinateur portable de quelqu'un. Les notebooks de Scrydon ferment ces deux brèches. Chaque session reçoit son propre compute isolé avec une enveloppe déclarée de CPU, de mémoire et de stockage ; le runtime est géré par la plateforme et en lecture seule ; les données sont atteintes via l'ontologie et la même politique d'accès que celle qu'applique le reste de la plateforme ; et quand la session se termine, l'environnement est détruit. Les notebooks sont réactifs plutôt que du type exécutez-les-cellules-dans-l'ordre : une valeur modifiée met à jour tout ce qui en dépend — et c'est ce qui fait d'un notebook quelque chose que l'on peut transmettre à un collègue en toute confiance.
Notebooks dans la plateforme Scrydon
Une architecture souveraine unique et intégrée. Voici où se situe Notebooks — mis en évidence au sein de la pile complète avec laquelle il fonctionne.
L'AI OS pour les humains et les agents IA
Couche d'ontologie et couche sémantique : un modèle unique et connecté pour vos données, connaissances et processus
Le meilleur des data lakes, des entrepôts de données et de la recherche réuni
Agents IA, flux de travail et automatisations qui s'exécutent à travers vos systèmes
Intégrez via A2A, MCP, systèmes existants et sources de données
Fédération de domaines sécurisée, partage de données de confiance et intelligence au-delà des frontières
Fondations Souveraines
Notebooks en détail
Analytique
Des données qui dorment dans des entrepôts et des dashboards que personne ne lit sont des données inexploitables. La couche Analytique change cela — en donnant aux bonnes personnes la bonne information sans qu'elles aient à la demander. Chaque métrique est ancrée dans l'ontologie Cognitive Enterprise, de sorte qu'un chiffre d'affaires n'arrive jamais isolé. Des données en contexte — pas seulement dans des dashboards.
Les décideurs obtiennent une vue en direct de l'entreprise — performance financière, santé opérationnelle, statut des achats — sans attendre qu'une équipe data prépare un rapport.
- Notebooks interactifs : Environnements Python et SQL avec un accès complet aux données de votre lakehouse — sans aucun déplacement de données.
- Dashboards visuels : Reporting prêt à l'emploi, toujours à jour, actualisé automatiquement au rythme de l'activité — pas de rafraîchissement manuel, pas de chiffres obsolètes.
- Analytique agent-native : Les agents IA peuvent interroger, synthétiser et agir sur les insights de manière autonome — bouclant la boucle entre analyse et action.
Cortex est l'interface en langage naturel qui relie la conversation humaine à l'ensemble des capacités de l'AI OS. Parlez à vos données, déclenchez des workflows complexes et interrogez votre knowledge graph — le tout en langage courant, sans barrière technique.
- Conscient de l'ontologie : Comprend la structure de votre enterprise knowledge graph, ce qui permet des réponses précises et sensibles au contexte.
- Déclencheurs de workflow : Décrivez ce que vous voulez obtenir et Cortex route automatiquement la demande vers les processus Human + AI Orchestrator appropriés.
- Entrée multimodale : Accepte du texte, des documents et des données structurées, en ancrant les réponses dans vos données d'entreprise réelles plutôt que dans les connaissances génériques d'un LLM.
- Piste d'audit : Chaque conversation est journalisée, attribuable et vérifiable — répondant aux exigences de conformité des secteurs réglementés.
Le Lakehouse est la fondation de données haute performance qui sous-tend la Cognitive Enterprise. Il est bâti sur StarRocks — un moteur de requêtes MPP vectorisé ultra-rapide offrant une analytique en moins d'une seconde, des mises à jour en temps réel et une forte concurrence — et interroge directement les tables ouvertes Apache Iceberg, fusionnant la flexibilité d'un data lake avec la vitesse d'un entrepôt sous un même toit souverain.
- Tables Iceberg ouvertes : Interrogez directement Apache Iceberg et d'autres formats de table ouverts — vos données restent les vôtres, sans verrouillage propriétaire ni déplacement de données.
- OLAP fulgurant : Le moteur vectorisé, l'optimiseur basé sur les coûts et les vues matérialisées de StarRocks alimentent du SQL en temps réel — des dashboards au raisonnement des agents — sans duplication de données.
- Vector Search intégré : Stockez et interrogez des embeddings aux côtés des données traditionnelles, rendant le Lakehouse instantanément prêt pour les charges de travail IA.
Ce que font les notebooks ici
Un notebook, ici, est un environnement Python interactif qui s'ouvre à l'intérieur de la plateforme, à côté des données, plutôt que sur un ordinateur portable ou un serveur partagé quelque part ailleurs. Vous écrivez du code, interrogez le Lakehouse via l'ontologie, tracez le résultat, puis changez d'avis — et comme le notebook est réactif, modifier une valeur réexécute tout ce qui en dépend, au lieu de laisser une sortie périmée en haut et une sortie fraîche en bas. L'environnement est décrit par le notebook lui-même : les dépendances dont il a besoin sont déclarées avec lui, si bien que le collègue qui l'ouvrira le mois prochain retrouve le même environnement plutôt qu'un casse-tête. Quand un notebook a prouvé quelque chose, il peut être promu en pipeline planifié sur la même plateforme au lieu d'être réécrit par une autre équipe dans un autre langage.
S'exécuter dans la plateforme — Le notebook s'exécute à côté des données, à l'intérieur de votre périmètre — rien n'est exporté vers un ordinateur portable pour être analysé.
Démarrer propre, à chaque fois — Une session démarre son propre compute avec des dépendances déclarées : aucune dérive entre ce que vous avez exécuté et ce qu'exécute un collègue.
Réagir au changement — Modifiez une cellule et chaque cellule dépendante se met à jour, au lieu de laisser un état périmé sur lequel le lecteur suivant trébuchera.
Devenir des pipelines — Un notebook qui a prouvé quelque chose peut être promu en pipeline planifié plutôt que réécrit de zéro.
Pourquoi la gouvernance des notebooks est un problème de sécurité
Demandez à une équipe sécurité ce qui l'empêche de dormir en matière d'analytique : les notebooks arrivent vite dans la conversation. L'arrangement habituel est un serveur de notebooks à longue durée de vie que tout le monde partage : il accumule des paquets, des identifiants et l'état d'autres personnes, et une seule compromission atteint tout cela. L'alternative vers laquelle la plupart des organisations dérivent est pire — la plateforme est pénible, alors quelqu'un exporte un extrait et l'analyse sur un ordinateur portable, et la copie que personne ne gouverne est celle qui quitte le bâtiment.
Il y a un second problème, plus discret. Un résultat qui ne peut pas être réexécuté ne peut pas être vérifié, et un chiffre qui ne peut pas être vérifié ne devrait pas éclairer une décision que quelqu'un devra défendre devant un conseil d'administration ou un régulateur. « Ça marchait quand je l'ai lancé » n'est pas une preuve.
Les deux problèmes deviennent plus aigus dès qu'un agent IA écrit et exécute son propre code. À ce moment-là, l'isolation cesse d'être un confort d'analyste et devient un contrôle — le même argument, et le même point de passage, que la sandbox dans laquelle s'exécutent les agents.
Les kernels partagés accumulent — Un serveur de notebooks à longue durée de vie collecte des identifiants, des paquets et l'état d'autres personnes ; une seule compromission atteint tout cela.
La vraie fuite, c'est le portable — Quand la plateforme est pénible à utiliser, les analystes exportent un extrait — la copie que personne ne gouverne est celle qui quitte le bâtiment.
Irréproductible, donc invérifiable — Si un résultat ne peut pas être réexécuté, il ne peut pas être contrôlé, et il ne devrait pas éclairer une décision qu'il faudra défendre.
Les agents ont besoin du même point de passage — Dès qu'un agent IA exécute du code, l'isolation et la politique cessent d'être un confort d'analyste et deviennent un contrôle.
Compute isolé, données gouvernées, rien ne reste derrière
Ouvrir un notebook démarre une session à part entière : l'accès est vérifié, le compute isolé est démarré, le notebook et ses dépendances déclarées sont chargés, et la connexion aux données est établie sous votre identité. L'enveloppe de compute est explicite — CPU, mémoire et stockage temporaire sont déclarés, le runtime est géré par la plateforme et en lecture seule, et l'environnement entier est détruit à la fin de la session. Il n'y a pas de kernel partagé entre les utilisateurs, ni d'hôte à longue durée de vie à durcir.
Démarrage d'un notebook : accès vérifié, compute isolé démarré, dépendances installées, données connectées. Le profil de compute est énoncé plutôt que supposé — et le runtime est en lecture seule et géré par la plateforme.
Les données sont atteintes via l'ontologie sous la même identité, la même politique et la même journalisation que toute autre charge de travail : un notebook n'est donc jamais un chemin privé vers le Lakehouse — la gouvernance des données s'applique ici exactement comme aux tableaux de bord et aux agents. Et comme les dépendances viennent de l'intérieur du périmètre, le même notebook démarre sur un cloud souverain, on-premises ou sur un réseau en air-gap, sans aucun service extérieur à appeler.
Isolation par session — Chaque notebook reçoit sa propre microVM avec un profil de ressources explicite ; le runtime est géré par la plateforme et en lecture seule.
Un seul modèle d'accès — Les données sont atteintes via l'ontologie sous votre identité — les mêmes permissions, la même journalisation et le même point de passage DLP que toute autre charge de travail.
Éphémère par construction — L'environnement n'existe que le temps de la session. Il n'y a pas d'hôte de notebooks à longue durée de vie à durcir, corriger ou compromettre.
Souverains partout — Les mêmes notebooks s'exécutent sur un cloud souverain, on-premises ou sur un réseau déconnecté, sans aucun service extérieur à appeler.
Questions fréquentes
Qu'est-ce qu'un notebook souverain ?+
Comment chaque notebook est-il isolé ?+
Les notebooks peuvent-ils atteindre n'importe quelle donnée du Lakehouse ?+
Les résultats sont-ils reproductibles ?+
Un notebook peut-il devenir un pipeline de production ?+
Les notebooks fonctionnent-ils quand le réseau est déconnecté ?+
Quel est le lien avec Cortex ?+
Explorer la plateforme
À lire aussi
Vous préférez écrire ? Envoyez un e-mail à hello [at] scrydon.com et nous vous répondrons.
Partenaires
