Notebooks Fabric : le guide pratique pour piloter Spark et la data science

Les notebooks Microsoft Fabric sont l’environnement interactif intégré pour explorer, prototyper et orchestrer des workloads Spark et machine learning directement dans Fabric. Le verdict est simple : utilisez un notebook Fabric dès que vous avez besoin d’itérer rapidement sur du code (exploration de données, feature engineering, tests de requêtes T-SQL), et réservez les jobs séparés ou les pipelines dédiés aux traitements industrialisés qui tournent sans supervision humaine.

Trois usages reviennent sans cesse chez les équipes data qui adoptent Fabric :

• Préparation de données : nettoyage, jointures et transformations avant chargement dans un lakehouse.
• Prototypage de modèles ML : test d’algorithmes sur un échantillon avant industrialisation via Spark distribué.
• Validation de requêtes T-SQL : vérification rapide d’une logique métier sur un entrepôt avant de la coder en dur dans un pipeline.

Deux repères techniques cadrent ce choix. D’un côté, Microsoft documente précisément les kernels disponibles et leur cas d’usage pour éviter les mauvais choix d’architecture dès le départ. De l’autre, les limites connues des notebooks imposent un plafond de taille par notebook et une durée d’exécution maximale par job, ce qui exclut d’emblée certains traitements trop lourds pour cet environnement.

Points clés

Un notebook Fabric bien architecturé repose sur trois décisions prises avant d’écrire la première ligne de code : le kernel, le runtime, et la stratégie de session.

Table des matières

• Kernels, modes et choix de runtime : quel environnement pour quel travail
• Créer, importer et versionner un notebook dans Fabric
• Écrire du code Spark propre : cellules, magic commands et modularité
• Paramétrer la session Spark : %%configure et gestion des bibliothèques
• Accéder au lakehouse et gérer les ressources embarquées
• Automatiser l’exécution : pipelines, API et intégration continue
• Limites connues et dépannage rapide des notebooks Fabric
• Perspective Biworks : industrialiser les notebooks et se former aux bons réflexes
• Ce qui compte vraiment quand on adopte les notebooks Fabric
• Faire de vos notebooks Fabric un actif durable, pas un prototype jetable
• Sources
• Questions fréquentes

Kernels, modes et choix de runtime : quel environnement pour quel travail

Choisir le bon kernel avant d’écrire la première ligne de code évite bien des refactorisations. Fabric propose plusieurs kernels dans ses notebooks, chacun taillé pour un usage précis, et le guide de sélection Microsoft reste la référence pour trancher rapidement.

• Python convient au prototypage léger, aux scripts d’automatisation et aux traitements qui ne nécessitent pas de distribution.
• Spark (PySpark, Spark SQL) s’impose pour tout traitement distribué sur de gros volumes, notamment le nettoyage et la transformation de données à l’échelle du lakehouse.
• T-SQL permet d’interroger directement un entrepôt Fabric sans changer de contexte, pratique pour valider une logique métier avant de la coder ailleurs.
• Scala et SparkR restent disponibles pour les équipes qui migrent des charges existantes ou qui ont des compétences historiques sur ces langages.

Au-delà du kernel, le mode d’affichage change la façon de travailler en équipe. Le mode Develop ouvre l’édition complète pour l’auteur du notebook. Le mode Run only limite les collaborateurs à l’exécution sans modification, utile pour partager un notebook de reporting sans risquer une édition accidentelle. Edit et View complètent ce spectre pour la relecture et la collaboration asynchrone, un peu comme des rôles de permission sur un document partagé.

Le choix du runtime pèse tout autant que le kernel. Runtime 1.3 reste stable et largement déployé, mais Runtime 2.0 apporte des versions plus récentes, notamment Spark 4.1, Python 3.13 et Java 21, avec des optimisations comme le Native Execution Engine qui accélère certains calculs distribués, d’après la documentation des runtimes Fabric.

Point de vigilance : avant tout déploiement en production, vérifiez systématiquement quelle version est officiellement disponible en disponibilité générale (GA). Une migration précipitée vers une version encore en préversion expose à des régressions difficiles à diagnostiquer sur des workloads critiques.

Créer, importer et versionner un notebook dans Fabric

Créer un notebook depuis l’interface Fabric prend quelques secondes : depuis un espace de travail, sélectionnez « Nouveau », puis « Notebook », et l’éditeur s’ouvre avec un kernel Python par défaut que vous pouvez changer immédiatement. Les développeurs habitués à VS Code peuvent aussi travailler localement puis synchroniser leur code vers l’espace de travail Fabric, ce qui évite de sacrifier son environnement de développement habituel.

1. Créer : depuis l’UI Fabric ou via l’extension VS Code compatible, en choisissant le kernel adapté au projet.
2. Importer : les notebooks au format .ipynb s’importent directement, ce qui facilite la migration depuis Jupyter, Databricks ou un autre environnement Spark.
3. Exporter : le même format .ipynb permet de récupérer le code pour l’archiver ou le partager hors de Fabric, mais attention, les sorties de cellules (graphiques, tableaux affichés) ne sont pas systématiquement conservées dans les workflows Git.
4. Versionner : connecter l’espace de travail à un dépôt Git structure le suivi des modifications et ouvre la porte à une vraie industrialisation.

Côté Git, Fabric génère un fichier notebook-content.py qui représente le code source du notebook sous une forme lisible par les outils de diff classiques. C’est ce fichier qui doit rester au centre de vos revues de code, plutôt que le format .ipynb brut, souvent illisible en diff parce qu’il mélange code, métadonnées et sorties binaires.

Conseil de pro : structurez votre dossier Git par domaine fonctionnel (ingestion, transformation, modélisation) plutôt que par type de notebook. Cela facilite la revue de code et limite les conflits de fusion quand plusieurs data engineers travaillent en parallèle.

Les fichiers volumineux placés dans le dossier Resources d’un notebook méritent une attention particulière : ils gonflent l’historique Git sans apporter de valeur de traçabilité, et il est souvent préférable de les exclure du versioning via un .gitignore ciblé, en les gérant plutôt comme des artefacts stockés dans le lakehouse.

Écrire du code Spark propre : cellules, magic commands et modularité

Un notebook qui grossit sans discipline devient vite illisible, et c’est le piège le plus fréquent chez les équipes qui découvrent Fabric. La première règle à retenir : ne modifiez jamais l’attribut de langage d’une cellule dans les métadonnées. Utilisez plutôt les commandes magiques %%sql, %%pyspark, %%spark ou %%sparkr pour changer de langage cellule par cellule sans casser la cohérence du fichier source.

• Placez toujours %%configure en première cellule du notebook, jamais au milieu, pour que Fabric applique les paramètres de session avant toute exécution de code.
• Regroupez la logique répétitive dans des fonctions ou des classes plutôt que de la dupliquer cellule après cellule.
• Externalisez les traitements complexes dans des notebooks auxiliaires appelés via %run, une approche que les bonnes pratiques de développement notebook chez endjin recommandent explicitement pour éviter ce que leurs consultants appellent le « notebook monstre ».
• Documentez le schéma des données attendues directement dans le code (schema-as-code) plutôt que dans un fichier séparé qui finit par se désynchroniser.

Cette logique de modularisation change concrètement la maintenance d’un projet. Un notebook « maître » qui orchestre trois ou quatre notebooks spécialisés (ingestion, nettoyage, modélisation) se relit et se débogue bien plus facilement qu’un fichier unique de deux mille lignes où tout le monde a peur de toucher à quoi que ce soit.

Côté productivité individuelle, l’éditeur Fabric embarque IntelliSense et une intégration proche de Pylance pour l’autocomplétion Python, ce qui réduit les erreurs de syntaxe et accélère l’écriture. Les aides Copilot intégrées aux notebooks vont plus loin : complétions contextuelles, suggestions de correction et un chat capable de proposer des corrections de code directement dans la cellule active. Pour un data scientist qui explore un nouveau jeu de données, ce type d’assistance raccourcit sensiblement le temps entre l’idée et le test.

Conseil de pro : si un notebook dépasse une vingtaine de cellules actives, c’est souvent le signal qu’il faut le scinder. Un notebook maître avec des appels %run reste plus lisible qu’un monolithe, même si cela demande un peu plus de discipline organisationnelle au départ.

Paramétrer la session Spark : %%configure et gestion des bibliothèques

La commande %%configure reste l’outil central pour ajuster une session Spark sans toucher aux paramètres globaux de l’espace de travail. Elle permet notamment de définir le lakehouse par défaut (defaultLakehouse) et divers paramètres runtime dès la première cellule du notebook.

%%configure
{
  "defaultLakehouse": {
    "name": "lakehouse_ventes"
  },
  "conf": {
    "spark.sql.shuffle.partitions": "200"
  }
}

Ce type de configuration évite de redéfinir le contexte à chaque exécution et rend le notebook portable d’un environnement à l’autre, à condition d’adapter le nom du lakehouse cible.

Le High Concurrency mérite d’être activé dès que plusieurs notebooks légers doivent partager une même session Spark active. Concrètement, plutôt que de démarrer un cluster à chaque exécution, ce qui coûte du temps et du calcul, les notebooks partagent une session commune et peuvent même échanger des variables via des vues temporaires globales (global temp views). C’est particulièrement utile pour des équipes qui exécutent de nombreux petits notebooks d’exploration dans la journée, où le coût de démarrage répété d’un cluster devient vite disproportionné par rapport au travail réel effectué.

• Activez High Concurrency pour les charges de travail interactives et fréquentes, pas pour les jobs batch isolés qui tournent une fois par nuit.
• Stockez vos fichiers JAR directement dans le lakehouse ou référencez-les via spark.jars.packages plutôt que de les réinstaller à chaque session.
• Suivez les recommandations Microsoft sur les bonnes pratiques Spark pour réduire le temps de publication d’un environnement personnalisé, un point souvent sous-estimé qui peut ralentir des cycles de déploiement entiers.

Conseil de pro : avant de publier un nouvel environnement custom en production, testez-le d’abord sur un espace de travail de développement isolé. Un environnement mal configuré qui échoue à la publication bloque potentiellement toute une équipe pendant que le déploiement se refait.

Accéder au lakehouse et gérer les ressources embarquées

Un notebook Fabric monte automatiquement le lakehouse associé, ce qui rend les chemins ABFSS relatifs accessibles directement dans le code sans configuration réseau supplémentaire. Lire ou écrire un fichier Delta depuis PySpark revient alors à manipuler un chemin logique plutôt qu’une URL de stockage complexe, un vrai gain de simplicité par rapport à des architectures Spark classiques où chaque accès réseau doit être configuré manuellement.

Le dossier Resources intégré à chaque notebook sert à embarquer de petits fichiers utiles au code (configurations, échantillons de test, dictionnaires de référence). Mais ce mécanisme a des limites précises qu’il faut connaître avant d’en abuser :

• Quota de 500 Mo pour l’ensemble des ressources d’un notebook.
• Limite de 100 Mo par fichier individuel.
• Accès programmatique via la commande notebookutils.nbResPath, documentée dans les utilitaires notebook Microsoft.

Les ressources embarquées dans un environnement partagé (plutôt que propres à un seul notebook) suivent une logique différente et servent surtout aux dépendances communes à plusieurs projets d’une même équipe.

La stratégie la plus robuste consiste à ne jamais transformer le dossier Resources en dépôt de données. Dès qu’un fichier de sortie dépasse quelques dizaines de mégaoctets, mieux vaut l’écrire directement dans une table Delta du lakehouse ou déléguer le traitement à un job Spark dédié. Le NotebookUtils facilite justement cette gestion de fichiers via ADLS Gen2 et OneLake, avec en prime une gestion des secrets par Azure Key Vault pour éviter de stocker des identifiants en clair dans le code.

Automatiser l’exécution : pipelines, API et intégration continue

Un notebook qui fonctionne en interactif ne devient utile à l’échelle d’une organisation que le jour où il s’exécute sans intervention humaine. Fabric propose plusieurs niveaux d’exécution, du test cellule par cellule jusqu’à l’orchestration complète via API.

1. Exécution interactive : Run cell, Run all ou Run selected pour tester une portion précise de code, avec des indicateurs de statut visuels (succès, échec, en cours) qui permettent de suivre l’avancement sans quitter l’éditeur, comme le détaille la documentation sur l’exécution des notebooks.
2. Orchestration programmatique : notebookutils.notebook.run() déclenche un notebook depuis un autre, tandis que runMultiple() permet d’exécuter plusieurs notebooks en parallèle dans une logique de DAG, avec passage de paramètres entre chaque étape.
3. Intégration pipeline : un notebook s’insère comme activité dans un pipeline Fabric, ce qui permet de le déclencher sur un planning ou en réaction à un événement, au même titre qu’une activité de copie de données.
4. Déploiement CI/CD : les variables de bibliothèque (variable library) permettent de remplacer dynamiquement des paramètres selon l’environnement cible (dev, test, production), et les pipelines de déploiement Fabric gèrent la promotion contrôlée entre espaces de travail.

Cette dernière étape change réellement la donne pour les équipes qui viennent d’un monde de scripts isolés. Plutôt que de copier manuellement un notebook de développement vers la production, avec tous les risques d’erreur que cela implique, le pipeline de déploiement applique les règles de promotion définies à l’avance et remplace automatiquement les paramètres sensibles (chaînes de connexion, noms de lakehouse) selon l’environnement.

Un point à ne pas négliger : la promotion vers la production doit systématiquement passer par une étape de validation automatisée, même légère (tests unitaires sur les fonctions extraites, vérification du schéma de sortie). Sans cela, le pipeline CI/CD ne fait que déplacer le risque plus loin dans la chaîne au lieu de le réduire.

Limites connues et dépannage rapide des notebooks Fabric

Certaines limites techniques ne sont pas négociables et il vaut mieux les connaître avant de concevoir une architecture entière autour d’un notebook. Les limites documentées par Microsoft fixent plusieurs plafonds précis :

• Taille maximale du contenu d’un notebook : 32 Mo.
• Affichage riche d’un DataFrame limité à 10 000 lignes ou 5 Mo, au premier seuil atteint.
• Maximum de 256 cellules par notebook.
• Durée d’exécution maximale d’un job : 7 jours.

Ces seuils ne sont pas arbitraires : ils protègent la stabilité globale du service contre des notebooks devenus incontrôlables. Un data scientist qui affiche un DataFrame de plusieurs millions de lignes directement dans une cellule prend le risque de saturer la mémoire de l’interface, sans gain d’information réel par rapport à un simple échantillonnage. La bonne pratique consiste à écrire les résultats intermédiaires volumineux dans une table Delta et à n’inspecter qu’un échantillon représentatif dans le notebook lui-même.

Côté dépannage, trois catégories de problèmes reviennent le plus souvent :

• Conflits de librairies : une version de package incompatible avec le runtime actif provoque des échecs silencieux à l’importation ; vérifiez toujours la compatibilité runtime avant d’ajouter une dépendance.
• Timeouts de session : une session Spark inactive trop longtemps se ferme automatiquement, ce qui interrompt un job en cours ; le High Concurrency limite ce risque pour les charges interactives fréquentes.
• Logs d’exécution incomplets : pensez à activer les journaux détaillés dès la phase de développement, plutôt qu’après un premier incident en production, pour disposer d’un historique exploitable.

Perspective Biworks : industrialiser les notebooks et se former aux bons réflexes

Les interventions de Biworks chez ses clients font remonter un constat récurrent : la plupart des difficultés viennent moins du notebook lui-même que de l’absence de séparation claire entre développement et production. Un notebook testé en interactif dans un espace de travail unique, sans variable library ni pipeline de déploiement, finit tôt ou tard par casser une exécution planifiée au moment où on s’y attend le moins.

Biworks accompagne les équipes IT et data sur trois axes concrets :

• Audit d’architecture Fabric : revue des choix de kernel, de runtime et de configuration de session pour identifier les points de fragilité avant qu’ils ne coûtent cher en production.
• Déploiement et sécurisation cloud Microsoft : mise en place de pipelines CI/CD, gestion des accès et conformité des environnements Azure sur lesquels reposent les notebooks Fabric.
• Formation certifiée Qualiopi : montée en compétence des équipes vers la certification PL-300 sur Power BI, en complément direct des compétences Fabric développées dans cet article.

Nos recommandations opérationnelles les plus fréquentes chez les clients : séparer systématiquement les espaces de travail dev et production, instrumenter l’observabilité des jobs Spark dès le premier déploiement, et packager le code métier en modules réutilisables plutôt qu’en notebooks isolés. Ce sont exactement les ateliers d’audit et les formations sur mesure que propose Biworks aux équipes qui veulent passer du prototypage à une exploitation fiable de Fabric.

Ce qui compte vraiment quand on adopte les notebooks Fabric

La plupart des guides sur les notebooks Fabric s’attardent sur l’interface et les fonctionnalités visibles, alors que les décisions qui déterminent réellement le succès d’un projet se prennent en amont : quel kernel, quel runtime, quelle stratégie de session. Un notebook mal calibré sur ces trois axes coûte des heures de débogage bien avant que le code lui-même ne devienne le problème.

Le conseil le plus répété, garder les runtimes à jour et vérifier la disponibilité générale avant tout déploiement, reste sous-appliqué en pratique. Beaucoup d’équipes restent sur un runtime ancien par prudence, alors que les gains de performance du Native Execution Engine sur Runtime 2.0 justifient largement un test contrôlé en environnement de développement.

Ma conviction, forgée par l’observation de nombreux projets Fabric : la vraie ligne de démarcation entre un notebook de prototypage et un actif industrialisable n’est pas la qualité du code Python ou Spark, mais la discipline autour du versioning Git et de la séparation des environnements. Un data scientist brillant qui ignore ces deux points produira un travail impossible à maintenir six mois plus tard. Priorisez d’abord la structure, ensuite l’optimisation du code.

Faire de vos notebooks Fabric un actif durable, pas un prototype jetable

Un notebook qui fonctionne en développement mais que personne n’ose toucher en production n’a résolu que la moitié du problème. Biworks accompagne les entreprises et cabinets qui veulent transformer leurs premiers essais Fabric en architecture fiable : audit de l’existant, mise en place de pipelines de déploiement, sécurisation des accès cloud Microsoft, et montée en compétence des équipes via des formations certifiées Qualiopi éligibles CPF.

Contrairement à un apprentissage en autodidacte via la documentation seule, un accompagnement structuré permet d’éviter les écueils classiques, tels que les notebooks monstres, l’absence de séparation dev/prod et les environnements mal configurés, dès les premiers projets plutôt qu’après un incident coûteux. Pour les équipes qui visent la certification PL-300 tout en travaillant sur des cas concrets liés à Fabric et Power BI, la formation Power BI complète et certifiante éligible CPF constitue un point d’entrée naturel. Pour les organisations qui cherchent d’abord un diagnostic technique de leur architecture Fabric, le guide pratique Fabric pour les professionnels IT détaille les prestations de conseil disponibles. Demandez un audit de votre environnement Fabric actuel pour identifier vos prochaines étapes concrètes.

Sources

• Fabric notebook selection guide – Microsoft Learn

Questions fréquentes

Qu’est-ce qu’un notebook dans Microsoft Fabric ?

Un notebook Fabric est un environnement de code interactif intégré à l’espace de travail, qui permet d’exécuter du Python, du Spark ou du T-SQL pour explorer des données, prototyper des modèles et orchestrer des traitements légers.

Microsoft Fabric et Databricks : quelle différence pour un projet Spark ?

Fabric s’oriente vers la consommation BI et l’intégration native avec Power BI, tandis que certaines organisations conservent Databricks comme couche d’ingénierie ML pour des charges très lourdes, selon les analyses comparatives disponibles sur le sujet.

Comment exécuter un notebook dans Fabric ?

Depuis l’interface, utilisez Run cell, Run all ou Run selected en mode interactif, ou déclenchez le notebook via une activité de pipeline, l’API notebookutils.notebook.run(), ou un planning automatisé.

À quoi sert vraiment Microsoft Fabric ?

Fabric unifie ingénierie de données, notebooks Spark, entrepôt et reporting Power BI dans une seule plateforme, ce qui évite de multiplier les outils pour couvrir l’ensemble du cycle de vie de la donnée. Les équipes qui veulent structurer cette adoption trouveront un cadrage complet dans le guide Microsoft Fabric pour les entreprises.

Quelle est la limite de taille d’un notebook Fabric ?

Un notebook Fabric ne peut pas dépasser 32 Mo de contenu, et l’affichage riche d’un DataFrame est plafonné à 10 000 lignes ou 5 Mo, selon la documentation officielle des limitations.

Recommandation

• Dataflow Gen2 dans Microsoft Fabric : guide pratique 2026
• Guide data visualisation : de débutant à praticien
• Concepts de data analytics : le guide pratique pour décideurs