Databricks

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 1 sur 15. Pendant des années, les entreprises ont payé deux fois pour stocker exactement la même data, juste pour satisfaire à la fois leurs ingénieurs machine learning et leurs business analysts. Stocker de la data brute dans un système et la copier dans un autre crée des prises de tête de synchronisation sans fin. Databricks règle ça en introduisant une approche unifiée appelée le Data Lakehouse. Historiquement, les organisations séparaient leur architecture data en deux chemins distincts. D'abord, elles construisaient des Data Lakes. Ce sont des systèmes de cloud storage pas chers et très scalables, parfaits pour stocker des quantités massives de données non structurées. Les data scientists les adorent pour entraîner des modèles de machine learning. Mais les Data Lakes sont horribles pour faire des requêtes SQL rapides et fiables. Pour résoudre ça, les entreprises ont introduit les Data Warehouses pour leurs équipes de business intelligence. Ça crée une charge opérationnelle énorme. Prends l'exemple d'une startup en pleine croissance. Ses data engineers balancent leurs event logs bruts dans un bucket de cloud storage. Ils y font tourner leurs scripts Python. Mais l'équipe finance a besoin de dashboards. Du coup, les ingénieurs doivent construire des pipelines complexes pour extraire cette data, la transformer et la charger dans un Data Warehouse séparé. L'entreprise paie le stockage deux fois. Elle paie pour le compute nécessaire pour déplacer la data. Et au moment où la data arrive dans le warehouse, elle est déjà obsolète. Databricks élimine complètement ce pipeline avec l'architecture Data Lakehouse. Un Lakehouse combine le stockage pas cher et flexible d'un Data Lake avec la fiabilité et les performances d'un Data Warehouse. Il garde ta data dans un format unique et ouvert, directement dans ton cloud storage. Tu ne la copies pas dans une base de données propriétaire. À la place, Databricks ajoute une couche transactionnelle directement au-dessus de ton Data Lake existant. Voici le point clé. Ta data reste à un seul endroit, mais différents professionnels interagissent avec elle exactement comme ils en ont besoin. Les data scientists peuvent écrire du Python ou du Scala pour entraîner des modèles directement sur les fichiers bruts. En même temps, les business analysts peuvent lancer des requêtes SQL haute performance sur cette même data pour alimenter leurs outils de reporting. Les gens pensent souvent à tort que Databricks est juste une autre base de données SQL ou simplement un wrapper managé autour d'Apache Spark. Ce n'est ni l'un ni l'autre. C'est une Data Intelligence Platform complète. En fusionnant le lake et le warehouse, tu fusionnes aussi la sécurité et la gouvernance. Dans l'ancien modèle, tu devais gérer les permissions d'accès dans le cloud storage pour les ingénieurs, et séparément dans le Data Warehouse pour les analystes. Avec Databricks, une couche de gouvernance unifiée gère le contrôle d'accès pour chaque table, fichier et modèle de machine learning. Tu définis une politique d'accès à la data une seule fois, et elle s'applique partout, peu importe le langage ou l'outil utilisé pour la requêter. La vraie puissance de l'architecture Lakehouse, ce n'est pas juste d'économiser de l'argent sur des pipelines de stockage redondants ; c'est que tes modèles d'intelligence artificielle et tes dashboards financiers regardent enfin exactement les mêmes chiffres, exactement au même moment. Si tu veux aider à faire vivre le podcast, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci pour ton écoute, et continue à développer !

Bonjour, ici Alex de DEV STORIES DOT EU. Databricks, épisode 2 sur 15. Si ton entreprise utilise plusieurs workspaces pour traiter les données, tu as probablement plusieurs endroits où tu gères les permissions de sécurité. Cette fragmentation est un risque majeur de non-conformité, car maintenir les policies synchronisées entre des environnements déconnectés repose entièrement sur des mises à jour manuelles. Unity Catalog élimine ce risque en changeant radicalement la façon dont la gouvernance des données fonctionne dans Databricks. Avant d'expliquer la mécanique, il faut dissiper une idée reçue très répandue. Unity Catalog n'est pas un dictionnaire de données passif. Ce n'est pas juste une liste de tables où les utilisateurs vont lire des descriptions. C'est le policy engine central qui applique activement les règles de sécurité sur toute ton architecture. Unity Catalog résout le problème persistant de savoir exactement qui a accès à quoi. Il fournit un modèle de sécurité unifié basé sur le standard ANSI SQL. Au lieu de configurer séparément les rôles d'identité cloud, les permissions au niveau du workspace et les contrôles d'accès au niveau du cluster, tu utilises des commandes familières comme grant et revoke directement sur tes données et tes assets d'intelligence artificielle. Comme Unity Catalog se situe au niveau du compte, plutôt que d'être lié à un workspace individuel, tu définis une règle de sécurité une seule fois. Cette règle est ensuite appliquée instantanément et universellement à tous les workspaces attachés à ce catalogue. Imagine une situation où un auditeur demande à un CTO de prouver exactement qui a requêté une table spécifique contenant des numéros de carte de crédit mardi dernier, et d'identifier chaque rapport en aval qui utilise actuellement ces numéros. Historiquement, pour répondre à ça, il fallait parser des logs système décousus à travers différents outils, lire manuellement les jobs de transformation planifiés, et espérer qu'aucune étape intermédiaire n'ait été oubliée. Unity Catalog gère ça nativement grâce à ses deux prochains piliers : l'audit intégré et le lineage automatisé. Premièrement, il capture des logs d'audit détaillés au niveau utilisateur, out of the box. Chaque fois qu'un utilisateur ou un service principal accède à des données, le catalogue enregistre l'événement. Voici le point clé. Unity Catalog ne se contente pas de suivre qui a requêté une table ; il suit ce qui arrive aux données ensuite grâce au lineage automatisé. Pendant que tes pipelines planifiés tournent, le système lit en continu les plans d'exécution et construit une carte des flux de données. Il suit quelles tables sources alimentent quels datasets intermédiaires, jusqu'aux dashboards finaux. Il suit ça à la fois au niveau de la table et au niveau de la colonne. Quand l'auditeur pose des questions sur les données de carte de crédit, tu n'as pas besoin de deviner. Tu regardes le graphe de lineage et tu vois instantanément chaque étape de transformation et chaque point d'accès. Le dernier pilier majeur est le partage sécurisé des données. Les organisations ont souvent besoin de partager des datasets avec des fournisseurs externes ou des business units séparées. Au lieu d'exporter des fichiers plats ou de dupliquer des données dans des buckets de stockage cloud séparés, Unity Catalog intègre un protocole appelé Delta Sharing. Ça te permet d'accorder à des tiers un accès gouverné aux données en temps réel sans les copier. Le consommateur externe lit les données sur place, et son accès est loggé et contrôlé par exactement le même cerveau central. La vraie valeur d'Unity Catalog, c'est qu'il supprime complètement le fossé dangereux entre l'écriture d'une policy de sécurité sur papier et son exécution réelle à travers des silos de données isolés. C'est tout pour cet épisode. Merci pour ton écoute, et continue de builder !

Bonjour, ici Alex de DEV STORIES DOT EU. Databricks, épisode 3 sur 15. Le meilleur moyen de faire exploser ton budget cloud, c'est de laisser un énorme serveur tourner à vide tout le week-end. Tu veux de la puissance de calcul exactement quand tu en as besoin, et zéro facturation quand tu ne t'en sers pas. C'est exactement ce qu'on aborde aujourd'hui : naviguer dans le Workspace et le Compute. Ton point d'entrée dans Databricks, c'est le Workspace. Vois le Workspace comme l'environnement unifié où ton équipe organise tous ses assets Databricks. Il fournit une interface web pour gérer tes notebooks, tes objets de données, tes expérimentations de machine learning et les ressources de compute sous-jacentes. Le Workspace rassemble tous tes outils collaboratifs dans une seule vue organisée, ce qui permet à différentes équipes d'interagir avec les mêmes données sous-jacentes sans se marcher sur les pieds. Sous le capot, Databricks repose sur une architecture découplée. Tes données sont stockées de manière persistante dans un object storage cloud, tandis que le compute utilisé pour traiter ces données est démarré de manière totalement séparée. Cette séparation des responsabilités détermine ta facturation. Comme le compute est isolé du storage, tu provisionnes et tu paies des instances de serveurs uniquement quand tu fais tourner du code activement. Une fois le travail terminé, le compute s'éteint, mais tes données restent stockées en toute sécurité et accessibles. Pour gérer cette puissance de traitement, Databricks propose différents types de ressources de compute adaptées à des workflows spécifiques. Le premier, c'est le cluster All-Purpose. Tu l'utilises pour du travail interactif et ad-hoc. Disons qu'un data analyst a besoin d'un environnement performant pour requêter un milliard de lignes un mardi après-midi. Il démarre un cluster All-Purpose, y attache son notebook et commence à explorer. Pour éviter les mauvaises surprises de facturation le week-end, ces clusters utilisent l'auto-termination. Si l'analyste rentre chez lui à 17 heures et laisse le notebook ouvert, le cluster surveille sa propre inactivité et s'éteint automatiquement après une limite de temps définie. Voici un point clé concernant l'automatisation. Une erreur fréquente que font les équipes, c'est de planifier des pipelines de production automatisés pour qu'ils tournent sur ces clusters All-Purpose interactifs. Évite de faire ça. Les clusters All-Purpose ont un coût d'utilisation plus élevé, et faire tourner plusieurs workflows différents sur un cluster interactif partagé peut introduire des conflits de librairies ou des problèmes de ressources. À la place, les pipelines de production devraient utiliser des Job clusters. Un Job cluster est complètement éphémère. Quand un pipeline automatisé est déclenché, le job scheduler de Databricks provisionne un Job cluster dédié strictement à ce workload. Il exécute le code, et à la seconde même où le job se termine, le cluster s'éteint de lui-même. Ça garantit une isolation stricte des ressources pour ton pipeline et t'assure de payer le tarif de compute le plus bas possible pour les tâches automatisées. Enfin, si ton workload est purement analytique, tu peux utiliser un SQL warehouse. C'est une ressource de compute optimisée spécifiquement pour exécuter des commandes SQL et des requêtes de dashboards. Si tu utilises des Serverless SQL warehouses, Databricks gère automatiquement le compute sous-jacent. Il scale up instantanément quand un pic de requêtes arrive, et scale down quand la file d'attente se vide, ce qui t'enlève complètement le besoin de configurer l'infrastructure toi-même. Associer le bon type de compute à la nature exacte de ta tâche, c'est le moyen le plus efficace de garantir que ton infrastructure cloud reste performante pendant les heures de pointe et ultra rentable une fois le travail terminé. C'est tout pour cet épisode. Merci de ton écoute, et continue à coder !

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 4 sur 15. Tu construis un data lake, mais en quelques mois, plus personne ne sait où se trouvent les données de production, à qui elles appartiennent, ou si une table spécifique est vraiment safe à query. La différence entre un data lake impeccable et un data swamp ingérable tient exactement sur trois niveaux. Aujourd'hui, on s'intéresse à l'organisation de tes données : l'Object Model. Unity Catalog met de l'ordre dans tes données grâce à une hiérarchie stricte et prévisible. Le container de plus haut niveau, c'est le metastore, qui contient les metadata de ton organisation. Mais tes interactions quotidiennes reposent sur le namespace principal à trois niveaux. Chaque query que tu écris cible un asset en utilisant le format catalog point schema point object. Le premier niveau, c'est le catalog. Ça définit une frontière large pour les data assets. Tu utilises généralement les catalogs pour séparer logiquement les environnements, comme avoir un catalog pour la production et un autre complètement séparé pour le développement. Le deuxième niveau, c'est le schema, qu'on appelle aussi une database. Les schemas vivent à l'intérieur des catalogs et organisent les datasets associés. Tu pourrais créer un schema pour les events bruts ingérés et un autre pour l'analytics affiné. Le troisième niveau, c'est l'object lui-même. C'est ta table, une view, ou un volume qui contient des fichiers non tabulaires. En imposant cette naming convention en trois parties, Unity Catalog donne à chaque donnée une adresse claire et sans ambiguïté. Quand un analyste fait une query sur production point sales point customers, l'emplacement, l'étape du lifecycle et le but de cette data sont instantanément évidents. Voici le point clé. Une fois que tu arrives au niveau de la table, tu dois comprendre comment Unity Catalog interagit avec ton vrai storage. Il y a deux types principaux de tables : les managed tables et les external tables. Les managed tables sont le comportement par défaut. Quand tu crées une managed table, Unity Catalog possède à la fois les metadata et la data sous-jacente. Il gère le layout des fichiers et manage tout le lifecycle de la data. Les vrais fichiers sont sauvegardés dans une storage location désignée que tu configures au niveau du metastore, du catalog ou du schema. Les external tables fonctionnent différemment. Tu utilises une external table quand tu as des fichiers qui sont déjà dans un bucket de cloud storage et que tu veux les laisser exactement là où ils sont. Avec une external table, Unity Catalog enregistre la structure et gouverne l'accès, mais il ne possède que les metadata. Tu gardes le contrôle total sur les fichiers physiques. Cette distinction devient critique pendant les opérations destructives. Imagine un scénario où un data engineer exécute accidentellement une commande drop table. S'il drop une managed table, Unity Catalog retire la table du metastore et supprime automatiquement les fichiers sous-jacents de ton cloud storage. La data est détruite. S'il drop une external table, Unity Catalog supprime simplement le lien des metadata. La table disparaît de l'interface de ton workspace, mais les fichiers bruts dans ton cloud storage restent parfaitement intacts et intouchés. Utilise toujours des managed tables quand tu veux que le catalog optimise et gouverne tout le lifecycle du storage, et réserve les external tables pour la data que tu dois protéger d'une suppression accidentelle ou partager directement avec d'autres systèmes externes. Merci d'avoir écouté. J'espère que tu as appris quelque chose de nouveau.

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 5 sur 15. Tu peux facilement restreindre qui voit une colonne dans une base de données relationnelle, mais comment tu gères le contrôle d'accès sur un bucket de cloud storage rempli de milliers de PDF bruts ? La réponse : maîtriser les données non structurées avec les volumes. Avant de voir comment ils fonctionnent, dissipons une confusion fréquente. Les volumes servent uniquement à l'accès aux fichiers basé sur le chemin. Ils ne sont pas faits pour les données tabulaires. Si tu requêtes des lignes et des colonnes avec SQL, tu utilises une table. Si tu lis des images, des documents texte ou des fichiers audio, tu utilises un volume. Un volume est un objet dans Unity Catalog. Il représente un espace de stockage logique dans ton environnement cloud. En créant un volume, tu places tes données non structurées exactement dans le même périmètre de sécurité que tes tables structurées. Au lieu de gérer des identity policies dans AWS ou des attributions de rôles dans Azure juste pour lire un fichier, tu contrôles l'accès avec des permissions standards directement dans Databricks. Prends l'exemple d'un hôpital qui entraîne un modèle de machine learning pour détecter des anomalies sur des radios. Ils ne peuvent pas mettre des milliers d'images haute résolution dans une table de base de données. Ils doivent les stocker sous forme de fichiers bruts dans un cloud object storage. Comme ce sont des dossiers patients très sensibles, une gouvernance stricte est cruciale. En plaçant les radios dans un volume Databricks, l'équipe d'ingénierie peut contrôler exactement quels data scientists ont le droit de lire ce répertoire spécifique. Il y a deux types de volumes : managed et external. Un volume managed est entièrement géré par Databricks. Quand tu en crées un, tu ne spécifies pas de chemin de stockage. Databricks alloue simplement de l'espace dans la storage location par défaut assignée à ton schéma actuel. Tu uploades tes fichiers directement dedans. Si jamais tu drop un volume managed, Databricks supprime aussi les fichiers sous-jacents. Ça les rend idéaux pour des fichiers de workspace temporaires ou des données générées entièrement dans tes pipelines Databricks. Un volume external pointe vers un répertoire de cloud storage existant que tu possèdes déjà. D'abord, tu enregistres un chemin de cloud storage comme external location dans Unity Catalog. Ensuite, tu crées un volume par-dessus. Ça te donne une gouvernance stricte sur les données produites par d'autres systèmes. Si une autre application écrit des fichiers de logs dans un bucket Azure Data Lake, un volume external permet aux utilisateurs de Databricks de lire ces fichiers de manière sécurisée. Si tu drop un volume external, les métadonnées sont supprimées, mais les fichiers sous-jacents dans ton bucket cloud restent complètement intacts. Cette approche basée sur le chemin est exactement ce dont l'IA moderne a besoin. Les librairies de machine learning open-source s'attendent généralement à lire des données depuis un file system local. Elles ne savent pas comment s'authentifier avec des interfaces de cloud storage propriétaires. Les volumes résolvent ça en exposant un chemin de répertoire qui ressemble et se comporte comme un dossier local standard. Ton script d'entraînement de modèle ouvre simplement un chemin de fichier. Unity Catalog intercepte cette requête et vérifie les permissions de l'utilisateur de façon transparente. Voici l'idée clé. Les volumes éliminent le décalage entre la façon dont tu gouvernes tes bases de données structurées et la façon dont tu sécurises tes fichiers bruts, ce qui te permet de faire tourner des workloads de machine learning sur des données non structurées sans contourner la sécurité de l'entreprise. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 6 sur 15. Si tes data engineers continuent de coller des clés d'accès cloud directement dans leurs scripts, ton entreprise est à une erreur d'une fuite de données massive. La solution pour connecter en toute sécurité ton workspace et ton cloud storage sans exposer de secrets, c'est Bulletproof Cloud Security : External Locations. Quand un utilisateur se connecte à Databricks, il utilise un identity token. Ce token prouve son identité au workspace. Mais cette identité ne signifie absolument rien pour ton cloud provider sous-jacent, que ce soit AWS, Azure ou Google Cloud. Pour lire un fichier depuis un bucket cloud, le workspace lui-même doit s'authentifier auprès de l'infrastructure cloud. Historiquement, les développeurs contournaient ce problème en hardcodant les clés IAM cloud directement dans leurs notebooks ou leurs variables d'environnement. Ça crée une grave faille de sécurité, car n'importe qui avec un accès en lecture au code peut voler les clés. Unity Catalog résout ça grâce à une abstraction stricte en deux parties. La première partie, c'est le Storage Credential. Un Storage Credential représente un mécanisme d'authentification et d'autorisation directement lié à ton cloud provider. Il correspond à un rôle IAM dans AWS, à une Managed Identity dans Azure, ou à un Service Account dans Google Cloud. Au lieu de donner des clés cloud brutes à un développeur, ton administrateur cloud accorde des privilèges d'accès à ce Storage Credential. Unity Catalog détient l'autorité pour assumer ce rôle, gardant le credential réel totalement hors de portée des utilisateurs du workspace. Maintenant, un Storage Credential seul, c'est trop large. Ce rôle IAM pourrait avoir la permission d'accéder à des dizaines de buckets différents dans ton environnement cloud. C'est là qu'intervient la deuxième partie. Une External Location associe un Storage Credential à un chemin de cloud storage spécifique, comme une URI de bucket S3 ou un chemin de container Azure Data Lake Storage. Elle définit exactement où ce credential est autorisé à opérer. Tu peux voir ça comme une frontière géographique pour tes cloud credentials. Prends un scénario concret. Un développeur doit analyser des system logs stockés dans un bucket S3 hautement sécurisé. Dans une configuration legacy, un admin générerait des clés d'accès AWS et les enverrait au développeur, en espérant qu'il ne va pas accidentellement commit ces clés dans un repository de code public. Avec Unity Catalog, le workflow change complètement. L'admin crée un Storage Credential configuré avec un rôle IAM qui peut lire le bucket cible. Ensuite, l'admin crée une External Location pointant strictement vers le chemin S3 contenant les system logs, et y attache ce Storage Credential. Enfin, en utilisant du SQL standard, l'admin accorde au développeur la permission de lire des fichiers exclusivement sur cette External Location. Quand le développeur lance une query sur les logs, Unity Catalog intervient et gère l'authentification cloud de manière transparente pour lui. Le développeur ne voit jamais de clé AWS. Il ne gère pas de secrets et ne configure pas de cloud profiles. Il fait juste une query sur le chemin autorisé. Plus tard, tu peux créer des external tables ou des external volumes directement par-dessus cette location pour mieux organiser les données. Si le développeur passe dans une autre équipe, l'admin révoque simplement son grant sur l'External Location dans Databricks. La configuration IAM cloud sous-jacente reste complètement intacte. Voici l'idée clé. Les External Locations découplent la sécurité de ton infrastructure cloud de ta gouvernance quotidienne des accès aux données. En gardant les rôles IAM en dehors du code utilisateur et en les ancrant à des chemins explicites, tu garantis que chaque requête de données est auditée, sécurisée et entièrement restreinte aux données que tu as l'intention de partager. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 7 sur 15. Les data engineers passent un temps fou juste pour éviter que leurs scripts d'ingestion d'API fragiles ne plantent. Quand un endpoint change sa logique de pagination ou qu'un rate limit baisse, ton pipeline plante, et tu passes l'après-midi à déboguer du JSON au lieu de construire des data models. La solution à cette prise de tête spécifique, c'est Lakeflow Connect. Avant de voir comment ça marche, clarifions une confusion fréquente sur les noms. Databricks propose Lakeflow Jobs et Lakeflow Connect. Lakeflow Jobs gère l'orchestration, c'est-à-dire qu'il exécute des tâches dans un ordre précis. Lakeflow Connect, lui, sert strictement à l'ingestion. C'est le mécanisme pour récupérer de la raw data depuis des systèmes externes vers ton environnement Databricks. À la base, Lakeflow Connect fournit des Managed Connectors. Ce sont des intégrations natives, conçues sur mesure pour les applications d'entreprise et les bases de données. D'habitude, quand tu as besoin de pull de la data depuis des systèmes externes, tu écris du code Python custom. Ce code doit gérer l'authentification, s'occuper des retries quand le serveur coupe la connexion, tracker quels records ont déjà été ingérés, et parser une pagination complexe. Les Managed Connectors éliminent toute cette couche d'infrastructure custom. Databricks gère le compute sous-jacent, les interactions avec l'API, et le state tracking nécessaire pour les lectures incrémentales. Comme Lakeflow Connect tourne sur du compute serverless, tu n'as pas besoin de configurer ou de gérer des clusters juste pour pull de la data. Le service scale automatiquement en fonction du volume de data entrante. Il s'intègre aussi directement avec Unity Catalog, ce qui veut dire que la data que tu ingères est immédiatement gouvernée et dispo pour être requêtée. Prends un besoin classique. Ton équipe marketing a besoin de data Salesforce à jour dans ton lakehouse. Si tu build ça from scratch, tu pourrais passer une semaine à écrire un script custom qui requête l'API Salesforce. Tu dois écrire la logique pour rester sous les limites strictes de l'API, gérer les refresh de tokens, et merger les updates dans tes tables Delta existantes sans dupliquer de records. Avec un Managed Connector dans Lakeflow Connect, tu bypasses complètement le code custom. Tu fournis les credentials de connexion, tu sélectionnes les objets Salesforce spécifiques que tu veux tracker, et tu définis un catalog et un schema de destination. Le setup prend quelques minutes. Databricks prend le relais sur l'exécution. Il pull le snapshot historique initial de ta data, puis passe à la capture en continu des changements incrémentaux au fur et à mesure. Voici le point clé. En déplaçant le workload d'ingestion vers un Managed Connector, tu arrêtes de maintenir des scripts de polling. Quand la spécification d'une API externe change, Databricks met à jour le connecteur en arrière-plan. Ton pipeline continue simplement de tourner. Ça te libère pour te concentrer sur la vraie business logic, comme transformer de la raw data en tables agrégées ou entraîner des modèles de machine learning, au lieu de babysitter un script d'extraction cassé. La vraie valeur de Lakeflow Connect, ce n'est pas juste le setup rapide, mais la suppression définitive du code d'ingestion custom de ton backlog de maintenance. Si tu veux aider à faire vivre l'émission, tu peux chercher DevStoriesEU sur Patreon et nous soutenir là-bas. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 8 sur 15. Tu as un pipeline ETL complexe où une table se met à jour toutes les heures, une autre en continu, et où l'orchestration des dépendances nécessite des centaines de lignes de code de state-management. Et si tu pouvais simplement déclarer les tables finales que tu veux, et laisser le moteur construire l'infrastructure pour les garder à jour ? C'est le principe de l'Automated ETL avec des Declarative Pipelines. Dans un pipeline impératif traditionnel, tu dis exactement au système comment faire son job. Tu écris le code pour gérer les checkpoints, gérer les retries, mapper les dépendances et provisionner les clusters. Les pipelines déclaratifs inversent ce modèle. Tu indiques simplement à quoi doit ressembler la table finale, généralement avec une requête SQL standard ou une fonction Python. Le moteur sous-jacent construit le graphe d'exécution, gère l'infrastructure et les state transitions automatiquement. Pour que ça marche, Databricks s'appuie sur deux types de tables spécifiques. Une erreur courante est de les traiter comme interchangeables. Elles ne le sont pas. Tu dois clairement séparer tes données d'événements append-only de tes agrégations complexes. Le premier type, c'est la Streaming Table. Les Streaming Tables sont conçues strictement pour un processing incrémentiel et append-only. Elles lisent en continu ou en batch depuis une source de données, traitent uniquement les nouveaux records, et les ajoutent à la cible. Imagine le traitement d'un stream massif de clics web venant de Kafka. Tu écris une requête pour peupler une Streaming Table à partir de ce topic Kafka. Tu n'écris pas de code pour tracker les offsets ou mémoriser quels messages ont déjà été lus. Le pipeline maintient le state en interne, garantissant que chaque clic est traité exactly once, même si le système redémarre. Maintenant, la deuxième partie. Une fois que tu as tes raw events stockés en toute sécurité, tu as généralement besoin de les transformer. C'est là qu'interviennent les Materialized Views. Alors que les Streaming Tables gèrent l'ingest initial des nouvelles données, les Materialized Views sont conçues pour les agrégations complexes, les jointures, et les records qui s'updatent ou se suppriment avec le temps. Pour en revenir à nos clics web, tu as besoin d'un dashboard exécutif quotidien montrant le total des clics groupés par région. Tu définis une Materialized View qui fait un select sur ta Streaming Table et lance l'agrégation. Quand le pipeline tourne, le moteur évalue la Materialized View. Il détermine la façon la plus efficace de mettre la vue à jour. S'il peut calculer les changements de manière incrémentale, il le fera. Si un full recompute est nécessaire, il le gère automatiquement. Tu n'écris jamais la logique qui dicte quand rafraîchir ou comment merger les nouvelles agrégations. Voici l'idée clé. Parce que tu définis à la fois les Streaming Tables et les Materialized Views de manière déclarative, le moteur Databricks comprend tout le lineage de tes données. Il sait que la Materialized View dépend de la Streaming Table. Il les relie ensemble dans un graphe de pipeline unifié. Si un compute node plante en plein processing, le pipeline s'appuie sur ce graphe pour faire pause, faire un retry, et reprendre sans dupliquer de records ni corrompre le dashboard final. Ta codebase n'est plus encombrée par du scaffolding opérationnel. Elle ne contient plus que la pure business logic qui définit comment la data circule de la source à la destination. C'est tout pour cet épisode. Merci de ton écoute, et keep building !

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 9 sur 15. Si ton traitement de données de nuit repose sur une chaîne de cron indépendants, tu espères en gros que l'étape précédente s'est terminée à temps. Tu navigues à l'aveugle. Pour arrêter les échecs silencieux et garantir l'ordre d'exécution, tu as besoin d'une Master Orchestration avec les Lakeflow Jobs. D'abord, une petite distinction. Les Lakeflow Pipelines gèrent les dépendances de données au niveau des tables. Les Lakeflow Jobs, sur lesquels on se concentre maintenant, orchestrent les tasks au niveau macro. Dis-toi que les pipelines déplacent les données dans le warehouse, pendant que les jobs enchaînent les notebooks, les scripts Python et les modèles de machine learning dans un workflow plus large. Un job dans Databricks, c'est le conteneur global de ton orchestration. À l'intérieur de ce conteneur, tu définis plusieurs tasks. Une task, c'est une unité de travail isolée. Ça peut être exécuter un notebook Databricks, soumettre une application Spark, faire tourner un projet dbt, ou lancer une requête SQL. En reliant ces tasks entre elles, tu construis un graphe d'exécution où une task ne démarre que quand ses prérequis spécifiques sont terminés avec succès. Prenons un scénario pratique pour voir comment le control flow gère la fiabilité. Tu as un process quotidien qui ingère des données brutes, vérifie leur qualité, les transforme et alerte l'équipe si quelque chose tourne mal. Tu commences par définir une task d'ingestion. Ensuite, tu lies une task de data quality qui tourne strictement après la fin de l'ingestion. Voici le point clé. Au lieu d'écrire une gestion d'erreurs custom dans ton code Python pour décider de la suite, tu utilises le control flow natif du job. Tu ajoutes une task de condition if-else juste après le check de qualité. La condition évalue une variable renvoyée par ta task de data check. Si la donnée est propre, le job suit la branche if et déclenche ta task de transformation en aval. Si la donnée est corrompue, le job prend la branche else et déclenche une task webhook qui ping un channel Slack. Tu gères aussi l'état en utilisant les conditions de task run-if. Tu peux configurer une task d'alerte pour qu'elle s'exécute uniquement si la task précédente a complètement échoué, pendant que le reste du pipeline s'arrête en toute sécurité. Ça évite la cascade classique d'échecs silencieux, où une étape d'ingestion cassée déclenche silencieusement l'entraînement d'un modèle de machine learning sur des tables complètement vides. Pour initier ce workflow, tu appliques un trigger. Les jobs peuvent tourner à la demande, sur un intervalle planifié classique, ou en continu. Ils peuvent aussi s'exécuter en fonction d'un événement, comme l'arrivée d'un nouveau fichier dans un bucket de cloud storage externe. Une fois déclenché, Databricks offre une observabilité intégrée. Tu n'as pas à deviner où une erreur s'est produite. La plateforme enregistre un historique complet des runs avec une vue matricielle, te montrant exactement quelle task a réussi, quelle task a bloqué, et combien de temps chaque étape a pris. Tu peux configurer des notifications au niveau du job ou de la task pour envoyer des emails automatisés ou des webhooks au moment où l'état d'exécution change. La vraie valeur de ce modèle d'orchestration, c'est de déplacer la gestion des erreurs de tes scripts individuels vers l'infrastructure de la plateforme, pour garantir que ton système sache exactement comment router l'exécution quand les choses cassent inévitablement. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 10 sur 15. Déplacer des données hors de ton data lake juste pour que ton équipe de business intelligence puisse y exécuter des requêtes, c'est lent, cher et complètement inutile. Tu finis par maintenir des pipelines fragiles juste pour copier des données d'un système à un autre, ce qui introduit des délais et double tes coûts de stockage. C'est exactement le problème que Databricks SQL résout. On croit souvent à tort que Databricks est strictement réservé aux data engineers et aux data scientists qui écrivent du Python ou du Scala. Databricks SQL vient clarifier tout ça. C'est un workspace dédié, construit entièrement pour les pros du SQL. Prends l'exemple d'une équipe de business intelligence qui migre depuis un data warehouse legacy. Historiquement, elle attendait que les ingénieurs fassent tourner des jobs d'extraction pendant la nuit pour charger les données du data lake vers le data warehouse. C'est seulement après qu'elle pouvait commencer à créer des rapports. Databricks SQL élimine toute cette couche d'extraction. Il permet aux analystes de lancer des requêtes ANSI-SQL standard directement sur le data lake. Tu profites du scale massif du stockage open lake, mais tu interagis avec lui via l'interface rapide et familière d'un data warehouse relationnel traditionnel. Le moteur qui fait tourner ces requêtes, c'est le Serverless SQL Warehouse. Un SQL warehouse, c'est simplement une ressource de compute configurée spécifiquement pour les workloads SQL. Dans les anciennes architectures, tu devais provisionner des clusters manuellement, configurer des règles de scaling, et attendre plusieurs minutes que les machines virtuelles démarrent avant de lancer une requête. Voici le point clé. Comme ces SQL warehouses sont serverless, la couche de compute démarre presque instantanément. Elle fait un scale-out automatique quand tes analystes lancent de gros workloads concurrents, et elle s'éteint toute seule quand les requêtes sont terminées. La gestion de l'infrastructure est complètement abstraite, ce qui laisse les analystes se concentrer uniquement sur leurs données. Pour écrire et exécuter ces requêtes, la plateforme fournit un éditeur SQL intégré. C'est l'interface principale pour explorer les données. Dans l'éditeur, les utilisateurs peuvent écrire du SQL standard, parcourir les data catalogs, examiner les schémas de tables et voir l'historique d'exécution. Quand une requête renvoie des données, l'analyste n'a pas besoin de les exporter pour les comprendre. Il peut créer des visualisations directement dans l'éditeur et les organiser dans des dashboards personnalisés qui se mettent à jour automatiquement. La plateforme inclut aussi une fonctionnalité d'alerting. Les analystes peuvent écrire une requête qui vérifie une métrique spécifique, et configurer le système pour envoyer un e-mail ou une notification web si cette métrique dépasse un seuil défini. Beaucoup d'organisations ont déjà des outils de visualisation en place. Databricks SQL s'intègre directement avec des outils tiers standards comme Power BI et Tableau. Ces applications externes se connectent au Serverless SQL Warehouse et traitent le data lake exactement comme si c'était une base de données haute performance. Le vrai changement ici, c'est fondamentalement la proximité avec tes données. En amenant du compute de niveau data warehouse et du SQL standard directement sur le data lake, tu arrêtes de copier des données et tu commences à analyser ta single source of truth au moment même où elle atterrit. C'est tout pour cet épisode. Merci de m'avoir écouté, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 11 sur 15. Si trois départements différents créent trois dashboards différents pour suivre les revenus, et qu'ils ramènent trois chiffres différents à la réunion de direction, tu n'as pas un problème de data pipeline. Tu as un problème de semantic layer. La solution, c'est d'établir un semantic layer comme source unique de vérité, et dans Databricks SQL, tu fais ça en utilisant les Metric Views. La data brute est rarement structurée comme les utilisateurs métiers l'imaginent. Les tables de la base de données contiennent des noms de colonnes obscurs, des joins complexes et des logs de transactions bruts. Un semantic layer comble ce fossé en traduisant cette data sous-jacente en concepts métiers familiers. Regardons un scénario classique où ça casse. Ton équipe marketing et ton équipe finance font toutes les deux du reporting sur les Monthly Active Users. Le marketing écrit une query dans son dashboard qui compte tous ceux qui ont ouvert l'application. La finance écrit une query différente dans un outil séparé qui compte uniquement les utilisateurs qui ont terminé une transaction. Les deux équipes appellent leur métrique Monthly Active Users. Quand les chiffres se contredisent, la confiance de l'organisation dans la data s'effondre. Définir les Monthly Active Users comme une Metric View dans Unity Catalog règle ça pour toujours. Pour comprendre pourquoi, on doit clarifier ce qu'est vraiment cette feature. Une Metric View, ce n'est pas la même chose qu'une SQL View standard. Une SQL View standard sauvegarde simplement une query qui renvoie des rows et des colonnes brutes, laissant à l'utilisateur final le soin de décider comment faire la somme, la moyenne ou grouper cette data plus tard. Une Metric View est beaucoup plus stricte. Elle impose des calculs d'agrégation et une dimensionnalité spécifiques directement au niveau du catalog. Quand tu crées une Metric View, tu verrouilles la logique métier exacte. Tu définis la mesure, comme un distinct count d'ID utilisateurs basé sur des critères de transaction spécifiques. Tu définis aussi les dimensions autorisées. Ça veut dire que tu dictes explicitement que cette métrique peut seulement être découpée par des attributs spécifiques, comme la date de transaction, la région de l'utilisateur ou le type de device. Voici le point clé. Une fois que cette Metric View est publiée dans Unity Catalog, elle devient la seule définition qui fait autorité pour les Monthly Active Users dans toute l'entreprise. Quand les analystes se connectent à Databricks SQL, ils n'écrivent pas de logique custom pour agréger la data. Ils ne font pas de joins sur les tables et n'écrivent pas de clauses where pour filtrer les états actifs. Ils font simplement une query sur la Metric View. Ça découple complètement la définition de la métrique de la presentation layer. Peu importe si le marketing utilise Tableau, si la finance utilise Power BI, et si l'équipe produit utilise les dashboards natifs de Databricks. L'outil de business intelligence demande juste la métrique, et Databricks effectue le calcul prédéfini côté serveur. Parce que la logique vit de façon centralisée dans Unity Catalog, c'est impossible pour différents départements d'inventer accidentellement leurs propres calculs. Ils récupèrent tous exactement le même chiffre, ce qui garantit une cohérence parfaite dans toute l'organisation. La vraie puissance d'un semantic layer, ce n'est pas l'efficacité technique ; c'est de sortir la logique métier des outils downstream déconnectés pour l'intégrer directement dans les fondations de la data platform elle-même. C'est tout pour cet épisode. Merci de ton écoute, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 12 sur 15. Et si ton directeur commercial pouvait juste envoyer un message à ton data warehouse pour obtenir des business insights instantanés, sans jamais avoir à soumettre un ticket à l'équipe data ? Les requêtes data ad-hoc interrompent constamment les workflows d'engineering, et les utilisateurs métiers détestent attendre des jours pour une simple query. La solution à ce bottleneck, c'est une feature de Databricks qui s'appelle Genie Spaces, et qui fait partie de leur offre AI/BI plus globale. AI/BI est un produit de business intelligence basé sur un système d'IA composite. Il est conçu pour comprendre la sémantique spécifique de tes données. Genie Spaces sert d'interface conversationnelle pour ce système. Un Genie Space ressemble à une application de chat classique, mais il est directement connecté à ton data warehouse. Les utilisateurs métiers tapent leurs questions en langage naturel, et Genie répond avec de vraies données, des visualisations et des réponses. Quand les gens entendent parler d'une IA qui fait des queries sur des données, ils s'inquiètent tout de suite des hallucinations. Ils partent du principe que le modèle va deviner les noms de colonnes, inventer des metrics, ou renvoyer des réponses fausses avec aplomb. Genie évite ça en s'appuyant entièrement sur les metadata gouvernées et stockées dans ton Unity Catalog. Il n'envoie pas un prompt à l'aveugle à un modèle de langage générique. L'IA est ancrée dans ton vrai schema, tes data types, tes relations de foreign keys, et les metrics prédéfinies que ton équipe a mises en place. Pour que ça marche, un analyste crée et configure d'abord le Genie Space. Il sélectionne les datasets pertinents dans Unity Catalog et fournit un ensemble d'instructions. Il peut ajouter des exemples de queries, définir une terminologie métier spécifique, et clarifier les termes ambigus. Par exemple, il peut dire au système que quand un utilisateur parle de « client actif », ça désigne spécifiquement un client qui a acheté dans les 90 derniers jours. Ce setup initial limite le scope de l'IA à un domaine bien défini. Quand une question est posée, le système orchestre plusieurs étapes. Il lit le prompt en langage naturel et vérifie le contexte fourni. Il fait correspondre l'intention de l'utilisateur aux tables et colonnes exactes du catalog. Ensuite, il génère une query SQL précise, exécute cette query sur le compute engine Databricks SQL, et formate les résultats. Prends l'exemple d'un responsable commercial non technique qui utilise un Genie Space préparé. Il tape : « Montre-moi les ventes en Europe par produit pour le dernier trimestre. » Le système parse la demande en se basant sur son entraînement. Il reconnaît « Europe » comme une dimension de région, localise les tables de produits, et traduit « dernier trimestre » en un filtre de date précis. En quelques secondes, l'IA génère le SQL, l'exécute, et renvoie un chart interactif qui montre la répartition. Si le manager répond ensuite : « Maintenant, exclus l'Allemagne », Genie modifie la query sous-jacente et met à jour le chart instantanément, tout en gardant le contexte conversationnel. Ce workflow change fondamentalement la façon dont les requêtes ad-hoc sont gérées. Les data engineers et les analystes passent une énorme partie de leur semaine à écrire des queries SQL one-off pour les stakeholders. Déplacer cette exploration vers Genie Spaces donne aux stakeholders métiers des réponses immédiates, tout en libérant du temps d'engineering pour des tâches complexes. En plus, tout le process reste complètement gouverné. Genie respecte strictement tous les contrôles d'accès au niveau des rows et des columns définis dans Unity Catalog. Si l'utilisateur qui pose la question n'a pas la permission de voir des données financières sensibles, l'IA ne va tout simplement pas faire de query dessus. Voici le point clé. L'efficacité de l'exploration conversationnelle des données est déterminée par la qualité de ton data model et de tes metadata sous-jacentes, et pas seulement par l'intelligence du modèle de langage. C'est tout pour cet épisode. Merci de ton écoute, et keep building !

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 13 sur 15. L'entraînement d'un modèle de machine learning, c'est la partie sympa, mais le déployer sous forme d'API REST hautement disponible et sécurisée, c'est là que la plupart des projets de data science vont mourir. Passer d'une expérience dans un notebook à un endpoint prêt pour la production nécessite de configurer le scaling, le load balancing et une gouvernance stricte. Pour résoudre ça, tu utilises Mosaic AI Model Serving. Cette feature offre une interface unifiée pour déployer, gouverner et requêter des modèles d'IA. On croit souvent à tort que Databricks Model Serving est réservé aux modèles que tu entraînes toi-même dans Databricks. C'est faux. En réalité, ça agit comme une AI Gateway centrale. Ça gère trois types de modèles distincts : les custom models, les foundation models et les modèles externes. D'abord, les custom models. Ce sont les modèles que tu buildes, que tu loggues avec MLflow et que tu enregistres dans Unity Catalog. Model Serving provisionne un conteneur serverless, charge les dépendances de ton modèle et l'expose sous forme d'API REST. Tu ne gères pas l'infrastructure. Ça scale up quand le trafic augmente et ça scale down à zéro quand c'est inactif. Deuxièmement, les foundation models hébergés par Databricks. Ce sont de gros modèles open-source que Databricks héberge sur du compute optimisé. Tu as un accès instantané à des architectures dernier cri sans te soucier du provisioning de GPU. Troisièmement, les modèles externes. C'est là que tu configures des endpoints qui pointent vers des services tiers. Pourquoi router le trafic externe via Databricks au lieu d'appeler directement les providers externes ? Pense à la gouvernance et au contrôle des coûts. Imagine que ta boîte veut utiliser GPT-4 pour une application interne. Si chaque développeur hardcode une clé API dans son script, tu perds en visibilité. Tu ne peux pas monitorer strictement les coûts, gérer les rate limits, ou appliquer des filtres pour empêcher les employés d'envoyer des données clients sensibles à un provider externe. En routant toutes les requêtes via Mosaic AI Model Serving, tu forces ce trafic à passer par une gateway unique et sécurisée. Tu gères un seul set de credentials. Tu appliques des contrôles d'accès via Unity Catalog, en dictant exactement qui ou quoi peut requêter le modèle. Tu as aussi un tracking centralisé de l'utilisation, des erreurs et de la latence. Le flux logique est simple. Tu définis un serving endpoint dans Databricks. Pour un custom model, tu fais pointer l'endpoint vers un modèle MLflow enregistré et tu définis la taille du compute et les limites de scaling. Databricks gère la conteneurisation automatiquement. Pour un modèle externe, tu fournis le nom du provider externe et une clé API stockée de manière sécurisée. Une fois l'endpoint actif, tes applications downstream envoient un payload JSON standard via une requête HTTP à l'URL de l'endpoint. La réponse revient dans un format cohérent, que le modèle tourne sur du compute serverless Databricks ou qu'il soit hébergé dans un data center externe. Voici le point clé. Mosaic AI Model Serving supprime la friction du déploiement tout en garantissant la sécurité. Ça standardise ta couche applicative, pour que ton code client ne communique qu'avec un seul endpoint Databricks, totalement abstrait de l'endroit ou de la façon dont le modèle sous-jacent est hébergé. Au fait, si tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 14 sur 15. Tu as dix mille logs bruts de support client qui dorment dans une table de base de données, et le business a besoin qu'ils soient résumés et catégorisés par sentiment d'ici la fin de la journée. Normalement, extraire ce genre d'insight demande un pipeline Python complexe, une gestion rigoureuse des clés API, et une logique de batching custom pour envoyer le texte à un Large Language Model. Et si tu pouvais exécuter tout ce workload avec une simple commande de base de données ? C'est exactement le problème que résolvent les AI Functions, qui intègrent les LLMs directement dans tes requêtes SQL. Les AI Functions font le pont entre la Generative AI dernier cri et la data analytics du quotidien. Elles prennent une capacité qui demande d'habitude une ingénierie spécialisée en machine learning et la mettent entre les mains de n'importe qui sachant écrire du SQL. Au lieu de construire une infrastructure séparée pour extraire la data, l'envoyer à un modèle et réécrire les prédictions, les AI Functions amènent le modèle directement là où la data se trouve déjà. L'outil principal pour ça, c'est une commande built-in qui s'appelle A I query. Tu l'utilises exactement comme une fonction de traitement de texte standard dans un select statement. Tu fournis le nom de l'endpoint du modèle que tu veux utiliser, et ensuite tu fournis le prompt. Pour en revenir à ces dix mille logs de support, ton workflow devient trivial. Tu écris une requête qui sélectionne ton customer ID et le texte du log. Ensuite, tu ajoutes une nouvelle colonne en utilisant la fonction A I query. Ton prompt dit au modèle de lire le texte, d'extraire la plainte principale, et de déterminer si le sentiment est positif, neutre ou négatif. Tu passes la colonne qui contient le texte brut de ton log dans ce prompt. Quand tu exécutes la requête, le moteur de base de données distribue automatiquement cette demande. Il traite chaque ligne à travers le Large Language Model spécifié. Le modèle évalue le texte et renvoie le résumé et le sentiment. Comme tout ça se passe en SQL, l'output arrive sous forme de colonnes structurées standard. Tu peux immédiatement filtrer les résultats pour n'afficher que le sentiment négatif, faire un join de ces résultats avec une table de facturation client, et faire un aggregate de la data pour trouver quel produit cause le plus de frustration. Voici l'insight clé. Tu pourrais penser que donner aux data analysts l'accès à des Large Language Models signifie distribuer des clés API sensibles dans toute ton organisation. Ce n'est pas le cas. Les AI Functions sont étroitement intégrées à Databricks Model Serving. Les connexions réelles aux modèles externes, ou aux modèles open-source self-hosted, sont configurées par les administrateurs au niveau de la plateforme. Le data analyst ne voit jamais une clé API, un token ou un secret. Il fait juste référence au nom de l'endpoint préconfiguré dans sa requête. Toute l'opération reste complètement sécurisée. Chaque requête est logguée, et tous les contrôles d'accès appliqués à la data et aux modèles sont strictement appliqués par le governance framework de la plateforme. En supprimant la friction de l'infrastructure et le credential management, tu changes la nature de l'exploration de la data. Tu transformes l'analyse complexe de texte non structuré en une simple opération de filtrage, ce qui upgrade instantanément la puissance analytique de toute ton équipe. Merci de m'avoir écouté. Prenez soin de vous, tout le monde.

Salut, c'est Alex de DEV STORIES DOT EU. Databricks, épisode 15 sur 15. Ton chatbot standard est poli, informatif et complètement passif. Il peut t'expliquer comment réparer un pipeline cassé en se basant sur un manuel, mais il ne peut pas vraiment réparer le pipeline à ta place. Passer d'une IA qui fait juste la conversation à une IA qui exécute activement des tâches demande un changement fondamental d'architecture. Ce changement, c'est le AI Agent Framework. Mettons tout de suite les choses au clair sur une confusion fréquente. On confond souvent les simples applications RAG, ou Retrieval-Augmented Generation, avec les vrais agents. Une application RAG, c'est en gros un moteur de recherche avec un modèle de langage par-dessus. Elle récupère des documents et les résume. Elle ne fait que lire. Un vrai AI Agent possède des tools. Il peut écrire. Il peut faire tourner des requêtes SQL, trigger des jobs, et appeler des APIs externes. Il modifie l'état de tes systèmes. Le Databricks Agent Framework fournit l'infrastructure pour build, évaluer et deploy ces agents autonomes de manière sécurisée dans le Lakehouse. Le mécanisme central ici, c'est le tool calling combiné au multi-step reasoning. Au lieu de juste générer une réponse en une seule passe, le modèle de langage agit comme un moteur de raisonnement. Tu lui donnes un but et un set de tools, qui sont en gros des fonctions que tu as définies. L'agent décide quel tool utiliser, attend le résultat, puis décide de ce qu'il doit faire ensuite. Imagine un agent conçu pour monitorer des data pipelines. Quand une erreur se produit, l'agent ne reste pas juste là à attendre un prompt de l'utilisateur. Le framework lui permet de trigger un workflow. D'abord, l'agent a besoin de contexte. Il utilise un custom tool que tu lui as fourni pour lancer une requête SQL sur tes system logs dans Databricks. Le framework exécute cette requête et renvoie le résultat à l'agent. Et c'est là qu'est le point clé. L'agent évalue ces logs, identifie la root cause de l'erreur, puis passe à l'étape suivante. Il se rend compte que l'équipe d'ingénierie doit être au courant. Donc, il sélectionne un autre tool, une intégration API avec l'application de chat de ta boîte. Il appelle ce tool pour rédiger et envoyer un message qui détaille l'erreur exacte et le fix proposé. C'est ça, le multi-step reasoning en action. L'agent a planifié une séquence, exécuté du code, observé le résultat et communiqué ce résultat, le tout de façon autonome. Donner à un modèle de langage la capacité d'exécuter des requêtes et de trigger des APIs est un énorme risque de sécurité si c'est mal géré. C'est pour ça que l'approche de Databricks couple étroitement le Agent Framework avec Unity Catalog. Quand tu fais un deploy d'un agent en utilisant Databricks Model Serving, tu ne lui donnes pas un accès total à ton infrastructure. Tu enregistres tes tools comme des fonctions spécifiques dans Unity Catalog. Unity Catalog applique une gouvernance stricte sur ce que ces fonctions peuvent faire. Si tu donnes à un agent un tool pour requêter des tables de logs, Unity Catalog s'assure qu'il ne peut lire que ces tables spécifiques. Si le modèle de langage hallucine et essaie d'utiliser le tool SQL pour drop une base de données de production, le framework l'arrête parce que la fonction sous-jacente n'a pas les permissions nécessaires. L'agent est strictement limité par les règles de gouvernance de ton Lakehouse. Cette capacité transforme le Lakehouse d'une couche de stockage passive en un environnement actif et automatisé. Pour conclure cette série, je t'encourage à aller voir la documentation officielle et à essayer de build toi-même un agent de tool calling tout simple. Si tu veux suggérer des sujets pour notre prochaine série, passe sur devstories dot eu. La transition des chatbots aux agents est le changement décisif dans la façon dont on build des applications d'IA aujourd'hui. C'est tout pour cet épisode. Merci pour ton écoute, et keep building !