Qu'est-ce qui arrive ?

Découvrez les fonctionnalités et les changements comportementaux dans les prochaines versions de Azure Databricks.

Power BI connexions seront migrées vers ADBC

Power BI prévoit de passer toutes les connexions Power BI à Arrow Database Connectivity (ADBC) en juillet 2026. Pour éviter les interruptions, Databricks recommande de basculer vos modèles sémantiques de développement et de préproduction vers ADBC maintenant et de valider vos charges de travail.

Le pilote ADBC pour Power BI sur Azure Databricks a été en préversion publique depuis octobre 2025. Depuis février 2026, toutes les nouvelles connexions dans Power BI Desktop et les service Power BI utilisent ADBC par défaut. Les connexions existantes continuent d’utiliser ODBC, sauf si vous les mettez à jour manuellement.

Consultez Configurer le pilote ADBC ou ODBC pour Power BI.

L’autorisation utilisateur pour Databricks Apps sera bientôt disponible pour les espaces de travail avec le profil de sécurité de conformité activé

Au début de juin 2026, l’autorisation utilisateur pour Databricks Apps sera automatiquement activée pour les espaces de travail avec le profil de sécurité de conformité activé. L’autorisation utilisateur permet aux applications d’agir avec l’identité de l’utilisateur de l’application, afin que les applications puissent accéder aux ressources au nom de l’utilisateur tout en appliquant les autorisations existantes de l’utilisateur.

Consultez l’autorisation utilisateur.

Les autorisations des objets de l'espace de travail seront bientôt héritées de tous les groupes de comptes.

Dans une prochaine version, les autorisations d’objet de l’espace de travail sont héritées de tous les groupes de comptes, pas seulement les groupes directement affectés à l’espace de travail. Les utilisateurs principaux héritent des autorisations sur les objets du workspace, tels que les travaux, les blocs-notes, les dossiers, les requêtes et les tableaux de bord, de tous les groupes dont ils sont membres, indépendamment de leur affectation au workspace. Les utilisateurs doivent toujours être affectés à l’espace de travail pour utiliser ces autorisations.

Cette modification active également les octrois d’autorisations inactifs (« orphelins »). Il s’agit d’octrois d’autorisations qui restent sur un groupe après sa suppression d’un espace de travail. Aucune nouvelle autorisation n’est ajoutée, mais les subventions orphelines existantes deviennent actives, ce qui peut donner aux membres de l’espace de travail un accès inattendu. Par exemple, si un groupe « Sous-traitants » a été supprimé d’un espace de travail mais qu’il a toujours accès à un dossier, tout membre de l’espace de travail dans « Sous-traitants » accède à ce dossier.

Databricks recommande d’examiner les autorisations de votre espace de travail. Utilisez le bloc-notes suivant pour identifier les octrois d’autorisations inactifs dans vos espaces de travail :

Bloc-notes d’analyse des autorisations orphelines

Obtenir un ordinateur portable

Les jetons d’accès personnels limités seront bientôt disponibles par défaut pour les espaces de travail avec le profil de sécurité de conformité activé

Les jetons d’accès personnels délimités seront disponibles par défaut pour les espaces de travail avec le profil de sécurité de conformité activé fin mai 2026.

Les jetons d'accès personnels délimités restreignent les autorisations d'un PAT à des opérations d'API spécifiques en assignant une ou plusieurs étendues d'API, plutôt que d'accorder un accès complet de l'identité à l'espace de travail.

Consultez Authentifier avec les jetons d'accès personnel d'Azure Databricks (obsolete).

Les groupes de systèmes d’espace de travail auront bientôt des subventions de droits fixes

Dans une prochaine version, les groupes de systèmes d’espace de travail (users et admins) auront des allocations fixes de droits qui ne peuvent pas être modifiées. Lorsque cette modification prend effet :

• Le users groupe n’aura aucun droit.
• Le admins groupe dispose de tous les droits d’espace de travail.
• Les droits existants sur le users groupe sont automatiquement migrés vers un groupe cloné, de sorte que les utilisateurs actuels conservent leur accès.

Il s’agit d’un changement cassant pour les clients qui utilisent l’automatisation (Terraform, les API SCIM d’espace de travail ou les scripts) pour gérer les droits sur les groupes système. Ces flux de travail doivent être mis à jour pour cibler des groupes réguliers à la place.

Un paramètre d’adhésion sera bientôt disponible. Pour plus d’informations, consultez Changer l’accès par défaut de l’espace de travail en accès consommateur.

ai_parse_document sera bientôt disponible par défaut pour les espaces de travail avec le profil de sécurité de conformité activé

ai_parse_document sera disponible par défaut pour les espaces de travail avec le profil de sécurité de conformité activé et les contrôles HIPAA, HITRUST, C5 et TISAX sélectionnés à la mi-mai 2026.

Utilisez ai_parse_document pour analyser du contenu structuré à partir de documents non structurés, notamment des fichiers PDF, images, Word documents et PowerPoint.

Consultez Fonction ai_parse_document.

Changement comportemental à venir : VOID colonnes incluses dans les lectures de table Delta

À la mi-juin 2026, Delta Lake prendra entièrement en charge les VOID colonnes. Auparavant, les colonnes VOID étaient silencieusement ignorées par les lectures DataFrame basées sur le chemin (par exemple spark.read.format("delta").load(path)) et les requêtes de rétrogradation temporelle. Après cette modification, ces requêtes incluent des VOID colonnes dans la sortie.

Les requêtes qui dépendent du nombre de colonnes ou de la position, telles que INSERT INTO ... SELECT *, peuvent échouer ou produire des résultats incorrects après cette modification. Passez en revue les requêtes qui lisent à partir de tables Delta Lake avec des colonnes VOID pour vous assurer qu'elles gèrent correctement les colonnes supplémentaires.

Voir VOID type.

Changement de rupture à venir : comportement par défaut pour la suppression d'un pipeline dans Unity Catalog.

Dans une prochaine version, le comportement par défaut lors de la suppression d’un pipeline catalogue Unity change. Actuellement, la suppression d’un pipeline supprime également toutes les vues matérialisées, tables de streaming et vues associées. Après cette modification, les tables associées sont conservées, mais inactives une fois le pipeline supprimé. L’API va également changer pour conserver par défaut les tables, mais en définissant le champ cascade sur true, cela annulera ce comportement par défaut et maintiendra le comportement actuel.

Le cascade champ est maintenant disponible. Pour conserver le comportement actuel de la suppression de toutes les tables lors de la suppression d’un pipeline, mettez à jour votre code pour définir cascade=true.

Consultez Supprimer un pipeline et Supprimer un pipeline.

Le déploiement Git pour les applications Databricks sera bientôt disponible pour les espaces de travail avec le profil de sécurité de conformité activé.

Au début de mai 2026, le déploiement Git pour Databricks Apps sera automatiquement activé pour les espaces de travail avec le profil de sécurité de conformité activé. Déployez des applications directement à partir d’un dépôt Git pour simplifier votre flux de travail CI/CD.

Consultez Déployer une application Databricks.

Nouvelle activation par défaut de l’éditeur SQL et mise hors service de l’éditeur SQL hérité

Le nouvel éditeur SQL est généralement disponible depuis octobre 2025. Dans le cadre de la transition vers le nouvel éditeur, les modifications suivantes sont planifiées :

• À compter de la fin de mai 2026 : le nouvel éditeur SQL sera activé par défaut pour tous les espaces de travail. La possibilité de désactiver la fonctionnalité au niveau de l’espace de travail n’est plus disponible. Les utilisateurs individuels pourront toujours basculer leurs requêtes vers l’éditeur SQL hérité une fois cette période commencée.
• À compter de la fin de juillet 2026 : l’éditeur SQL hérité sera mis hors service. Tous les utilisateurs utiliseront le nouvel éditeur SQL, et l’opt-out individuel ne sera plus disponible.

Pour en savoir plus sur le nouvel éditeur SQL, consultez Écrire des requêtes et explorer les données dans le nouvel éditeur SQL. Si vous avez des questions sur cette transition, contactez votre équipe de compte.

Modification de l’ordre de tri de l'API des tableaux de bord de liste

Le 4 mai 2026, une nouvelle version de l’API List Dashboards modifie l’ordre de tri des résultats. Les tableaux de bord sont retournés dans l’ordre chronologique inverse par date de dernière modification, avec le tableau de bord le plus récemment modifié en premier, au lieu de l’ordre alphabétique par titre.

Il s’agit d’une modification importante pour les utilisateurs qui paginent les résultats à l’aide de next_page_token. Les jetons générés par une version précédente de l’API ne sont pas valides avec la nouvelle version. Si vous utilisez un jeton à partir d’une version précédente, l’API retourne une erreur :

Invalid page_token: this token was generated by a previous/different API version. Please retry without page_token.

Pour continuer la pagination après cette modification, démarrez une nouvelle requête sans .next_page_token

Lakebase sera activé par défaut pour les espaces de travail avec le profil de sécurité de conformité

Le 30 avril 2026 ou après le 30 avril 2026, Lakebase sera activé par défaut pour les espaces de travail avec le profil de sécurité de conformité lorsque la norme de conformité est définie sur HIPAA, C5, TISAX ou None.

Consultez la conformité Lakebase.

Modifications apportées à l’ouverture des jetons de destinataire du partage Delta

Le partage delta pour les destinataires ouverts passe à un nouveau format d’URL spécifique au destinataire. La date de transition a été mise à jour et est maintenant le 1er juillet 2026. Les nouveaux jetons créés le 1er juillet 2026 utilisent automatiquement le nouveau format d’URL. Cette modification améliore la sécurité réseau et permet aux destinataires de configurer des stratégies réseau et des règles de pare-feu spécifiques aux destinataires.

Pour Azure Chine, la transition sera annoncée ultérieurement.

Les nouvelles URL incluent l’ID de destinataire dans le domaine :

https://<recipient-id>.delta-sharing.westus.azuredatabricks.net/api/2.0/delta-sharing/metastores/<metastore-id>

Pour référence, les URL créées avant cette modification ne contiennent pas l’ID du destinataire.

https://westus.azuredatabricks.net/api/2.0/delta-sharing/metastores/<metastore-id>

Les anciennes URL continueront de fonctionner pendant une période donnée. La durée spécifique dépend du type de destinataire et de la date de création du jeton. Les fournisseurs de données doivent passer au nouveau format d’URL avant que l’ancien format d’URL ne devienne pas valide.

Partage de la fédération OIDC :

Les fournisseurs de données doivent vérifier que leurs destinataires utilisent le nouveau format d’URL avant le 1er juillet 2027. À compter du 1er juillet 2026, les fournisseurs peuvent trouver la nouvelle URL dans l’interface utilisateur de partage Delta. Après le 1er juillet 2027, l’ancien format d’URL n’est pas valide.

Partage de jeton d'accès :

La classification des données sera bientôt disponible par défaut pour certains espaces de travail avec le profil de sécurité de conformité activé

À la mi-mars 2026, la classification des données sera disponible par défaut pour les espaces de travail avec le profil de sécurité de conformité activé et les contrôles HIPAA sélectionnés.

La prise en charge d’EventBridge sera bientôt disponible pour les événements de fichiers fournis dans les files d’attente fournies

Fin février 2026, EventBridge prendra en charge les événements de fichier provenant des files d’attente liées aux emplacements S3. Actuellement, les événements de fichier ne peuvent être configurés qu’à l’aide de SNS ou en acheminant les événements de stockage directement vers SQS.

Consultez Utilisation d’une file d’attente fournie pour S3.

Nouvelle logique de découpage pour les tables de chronologie des travaux

À compter du 19 janvier 2026, les tables de chronologie des tâches utilisent une nouvelle logique de découpage alignée sur les heures de l'horloge. Les tranches de temps s’alignent désormais sur les limites d’heure d’horloge standard (17h00-18h00, 18h00-19h00, etc.) au lieu d’intervalles d’une heure en fonction de l’heure de début du déroulement. Les nouvelles lignes utilisent la nouvelle logique de découpage, tandis que les lignes existantes restent inchangées.

Consultez la logique de découpage alignée sur l’heure de l’horloge.

Mises à jour de navigation de l’Explorateur de catalogues

L’Explorateur catalogue recevra bientôt des améliorations de navigation pour simplifier les flux de travail et vous aider à découvrir et à gérer plus efficacement les ressources de données.

Navigation simplifiée :

L’onglet Catalogues duplicatifs est supprimé pour réduire la redondance et se concentrer sur une seule surface de navigation de catalogue. DBFS et l'action Envoyer des commentaires se déplacent dans le Pour une disposition plus propre.

Nouvelle section Suggérée :

Un nouvel onglet Suggéré de la page d’accueil de l’Explorateur de catalogue met en évidence les objets fréquemment utilisés, par exemple les objets pour les utilisateurs de première fois et les favoris des utilisateurs. Cela vous permet de vous réengager rapidement avec des actifs importants ou de trouver des points de départ utiles.

Points d’entrée consolidés :

Les fonctionnalités connexes sont regroupées sous des catégories plus claires pour réduire le bruit visuel et améliorer la détectabilité :

• Gouverner : point d’entrée pour les étiquettes régies, l’administration du métastore et la classification des données
• Connexion : points d’entrée pour les emplacements externes, les données externes, les informations d’identification et les connexions
• Partager : points d’entrée pour le partage Delta et les salles propres

Ces regroupements remplacent les sous-onglets dispersés et créent une architecture d’informations plus intuitive et évolutive.

Partage de fédération Lakehouse et stockage par défaut

Delta Sharing on Lakehouse Federation est en version bêta, ce qui permet aux fournisseurs de données Delta Sharing de partager des catalogues et des tables étrangers. Par défaut, les données doivent être temporairement matérialisées et stockées sur le stockage par défaut (préversion privée). Actuellement, les utilisateurs doivent activer manuellement le partage Delta pour le stockage par défaut : fonctionnalité d’accès étendu dans la console de compte pour utiliser le partage de fédération Lakehouse.

Après Delta Sharing for Default Storage – L’accès étendu est activé par défaut pour tous les utilisateurs Azure Databricks, delta Sharing on Lakehouse Federation sera automatiquement disponible dans les régions où le stockage par défaut est pris en charge.

Consultez Stockage par défaut dans Databricks et Ajouter des schémas ou des tables étrangers à un partage.

Recharger la notification dans les espaces de travail

Dans une prochaine version, un message pour recharger l’onglet de votre espace de travail s’affiche si l’onglet de votre espace de travail a été ouvert depuis longtemps sans actualisation. Cela vous aidera à vous assurer que vous utilisez toujours la dernière version de Databricks avec les dernières fonctionnalités et correctifs.

Le partage delta pour les tables sur le stockage par défaut sera bientôt activé par défaut (bêta)

Cette mise à jour de stockage par défaut pour le partage Delta offre des fonctionnalités de partage étendues, ce qui permet aux fournisseurs de partager des tables sauvegardées par défaut par le stockage sur n’importe quel destinataire delta Sharing (ouvert ou Azure Databricks), y compris les destinataires utilisant le calcul classique. Cette fonctionnalité est actuellement en version bêta et nécessite que les fournisseurs activent manuellement le partage Delta pour le stockage par défaut – Accès étendu dans la console de compte. Bientôt, cette option sera activée par défaut pour tous les utilisateurs.

Voir Limitations.

Mises à jour des adresses IP publiques du plan de gestion des flux sortants

Azure Databricks met à jour les adresses IP publiques du plan de contrôle sortant , ainsi que les balises de service Azure, pour améliorer la sécurité et la disponibilité des zones. Ces modifications font partie d’une mise à jour du plan de contrôle qui a commencé à être déployée le 20 mai 2025.

Si votre organisation utilise des pare-feu de ressources pour contrôler l’accès entrant :

• Si vos règles de pare-feu font référence à la balise Azure Databricks service, aucune action n’est requise.
• Si vous autorisez des adresses IP publiques de plan de contrôle spécifiques, vous devez ajouter toutes les adresses IP du plan de contrôle sortant avant le 26 septembre 2025.

Les adresses IP du plan de contrôle sortant précédentes continuent d’être prises en charge.

Modification du comportement pour l'option de liste de répertoire incrémentielle de l'Auto Loader

Dans une prochaine version de Databricks Runtime, la valeur de l’option de chargement automatique déconseillée cloudFiles.useIncrementalListing sera définie par défaut sur false. La définition de cette valeur false entraîne l’exécution d’un répertoire complet à chaque exécution du chargeur automatique. Actuellement, la valeur par défaut de l’option cloudFiles.useIncrementalListing est auto, demandant au chargeur automatique d’effectuer une tentative optimale pour détecter si une liste incrémentielle peut être utilisée avec un répertoire.

Pour continuer à utiliser la fonctionnalité de liste incrémentielle, définissez l’option cloudFiles.useIncrementalListing sur auto. Lorsque vous définissez cette valeur sur auto, Auto Loader tente d’effectuer une liste complète toutes les sept listes incrémentielles, ce qui correspond au comportement de cette option avant cette modification.

Pour en savoir plus sur la liste des répertoires du chargeur automatique, consultez Configurer des flux de chargeur automatique en mode de référencement d’annuaire.

Modification du comportement lorsque les définitions de jeu de données sont supprimées des pipelines déclaratifs Spark Lakeflow

Une prochaine version des pipelines déclaratifs Lakeflow Spark modifiera le comportement lorsqu’une vue matérialisée ou une table de diffusion en continu est supprimée d’un pipeline. Avec cette modification, la vue matérialisée supprimée ou la table de diffusion en continu ne sera pas supprimée automatiquement lors de l’exécution de la prochaine mise à jour du pipeline. Au lieu de cela, vous pourrez utiliser la commande DROP MATERIALIZED VIEW pour supprimer une vue matérialisée ou la commande DROP TABLE pour supprimer une table de diffusion en continu. Après avoir supprimé un objet, l’exécution d’une mise à jour de pipeline ne récupère pas automatiquement l’objet. Un nouvel objet est créé si une vue matérialisée ou une table de diffusion en continu avec la même définition est re-ajoutée au pipeline. Toutefois, vous pouvez récupérer un objet à l’aide de la commande UNDROP.

Le champ sourceIpAddress dans les journaux d’audit n’inclut plus de numéro de port.

En raison d’un bogue, certains journaux d’audit d’autorisation et d’authentification incluent un numéro de port en plus de l’adresse IP dans le champ sourceIPAddress (par exemple, "sourceIPAddress":"10.2.91.100:0"). Le numéro de port, qui est enregistré en tant que 0, ne fournit aucune valeur réelle et n’est pas cohérent avec le reste des journaux d’audit Databricks. Pour améliorer la cohérence des journaux d’audit, Databricks prévoit de modifier le format de l’adresse IP pour ces événements de journal d’audit. Cette modification sera progressivement déployée à partir de début août 2024.

Si le journal d’audit contient une sourceIpAddress dont la valeur est 0.0.0.0, il est possible que Databricks arrête sa journalisation.