David Zebrowitz Directeur des services de conseil en données et analyse
Partager cet article

Le 1er août 2026, de nombreux espaces de travail Azure Synapse perdront le chemin réseau qu’ils utilisent actuellement pour accéder à leur propre stockage et à leurs secrets. Les opérations concernées cesseront alors de fonctionner jusqu’à ce qu’une migration soit effectuée. Déterminer si votre environnement est touché ne prend que quelques minutes. La mesure corrective consiste en une migration planifiée vers un nouvel espace de travail, sans interruption de service, et il est encore temps d’exécuter cette transition de façon structurée si les démarches commencent dès maintenant.

Ce que les décideurs doivent savoir

La date limite est ferme. Le 1er août 2026, les espaces de travail Synapse qui dépendent du mécanisme retiré perdront l’accès à leur stockage ou à Azure Key Vault, ce qui empêchera l’exécution des opérations concernées.

Il ne s’agit pas d’un cas particulier. La configuration à risque correspond à l’architecture généralement mise en place lorsque les recommandations de sécurité pour Synapse Link sont suivies. Les organisations ayant renforcé leur sécurité sont davantage susceptibles d’être concernées.

Pour plusieurs organisations, la correction implique une reconstruction de l’environnement. Le paramètre requis ne peut être activé qu’au moment de la création de l’espace de travail. Les environnements touchés doivent donc être migrés vers un nouvel espace de travail plutôt que simplement reconfigurés.

Les clients de Microsoft Dynamics 365 sont directement touchés. Les organisations utilisant Synapse Link pour Dataverse, y compris Finance and Supply Chain Management et les applications de gestion de la relation client, représentent la plus grande population concernée.

Il est encore temps d’agir si les travaux commencent maintenant. La migration peut être réalisée en parallèle, sans interruption de service, à condition d’être planifiée bien avant l’échéance plutôt que dans les dernières semaines.

Ce qui est retiré

Aujourd’hui, un espace de travail Synapse accède généralement à un compte Azure Storage ou à Azure Key Vault au moyen d’une identité gérée combinée à une exception de pare-feu. Cette exception correspond à l’autorisation des services approuvés (« trusted services »), qui permet au service Synapse d’accéder au stockage ou à Key Vault parce qu’il est considéré par Microsoft comme un service de première partie. Cette autorisation sera supprimée le 1er août 2026.

Le modèle de remplacement repose sur les réseaux privés. Au lieu d’utiliser une exception de pare-feu, l’espace de travail accède au stockage et à Key Vault au moyen d’un réseau virtuel géré et de points de terminaison privés gérés. Il s’agit d’un modèle de sécurité plus robuste. Le principal défi réside dans les efforts requis pour migrer vers cette architecture.

Cette modification n’entraînera pas une dégradation progressive. Sans intervention, les connexions qui dépendent actuellement de l’exception de services approuvés cesseront de fonctionner. Un espace de travail incapable d’accéder à son stockage ou à ses secrets ne peut tout simplement plus fonctionner. Il s’agit d’une échéance qui risque d’interrompre des charges de travail en production, et non d’un simple exercice de maintenance.

Pourquoi ce changement touche les déploiements standards plutôt que des cas particuliers

Il est normal de penser que seuls les environnements hautement sécurisés sont touchés. En pratique, c’est l’inverse. La configuration à risque est généralement le résultat normal d’une mise en œuvre conforme aux recommandations.

Lorsqu’une organisation déploie Synapse Link pour Dataverse, la documentation de Microsoft recommande de configurer le pare-feu du compte de stockage de destination sur Réseaux sélectionnés. Cette étape est appropriée après la configuration initiale, puisque le compte de stockage ne devrait pas demeurer accessible depuis Internet. Les services Azure approuvés sont alors autorisés afin que Synapse puisse continuer à accéder au compte. Cette combinaison, soit un pare-feu restrictif associé à l’exception des services approuvés, correspond précisément au modèle qui est retiré.

Les organisations à risque ne sont donc pas celles qui ont adopté une configuration inhabituelle. Il s’agit plutôt de la majorité ayant suivi les meilleures pratiques de sécurité. Un compte de stockage entièrement ouvert, qui n’est techniquement pas touché, n’est généralement présent que dans des environnements de démonstration ou des environnements dont la sécurité n’a jamais été renforcée.

Pourquoi la correction exige généralement une reconstruction

Le paramètre qui permet d’utiliser les points de terminaison privés gérés est le réseau virtuel géré de l’espace de travail. Cette propriété ne peut être activée qu’au moment de la création de l’espace de travail. Microsoft n’offre aucun moyen de l’activer après coup.

Azure Synapse managed virtual network settings screenshot

Figure 1 - Le réseau virtuel géré Synapse n’est pas activé

Par conséquent, si un espace de travail n’a pas été créé avec cette option activée, le paramètre ne peut pas être modifié dans le portail Azure. Dans la pratique, la correction consiste à déployer un nouvel espace de travail avec le réseau virtuel géré activé dès le départ, puis à migrer les composants existants. Chaque espace de travail Synapse possède également son propre compte de stockage principal contenant les requêtes enregistrées, les pipelines et d’autres artefacts, ce qui complique davantage toute tentative de réutilisation de l’environnement existant.

Comment déterminer si vous êtes touché

Cette évaluation peut être réalisée dès aujourd’hui, sans coût, en quelques minutes, et permet d’établir clairement si votre environnement est concerné.

Commencez par identifier le compte de stockage associé. Il s’agit du compte de stockage de destination utilisé par Synapse Link. Vous pouvez le trouver dans le portail Power Apps Maker sous Azure Synapse Link pour Dataverse, puis dans les détails du lien. Copiez la valeur affichée sous « Storage Account ».

Avec le nom du compte approprié, exécutez la commande Azure CLI suivante. Un accès Lecteur au compte de stockage est suffisant.

az storage account show --name <landingStorageAccount> --query "{publicNetworkAccess:publicNetworkAccess, defaultAction:networkRuleSet.defaultAction, bypass:networkRuleSet.bypass, privateEndpoints:length(privateEndpointConnections)}" -o table

Interprétez ensuite les résultats selon les scénarios suivants :

  • Si vous obtenez : Deny with bypass: AzureServices and privateEndpoints: 0, et que l’espace de travail associé ne possède pas de réseau virtuel géré, alors l’environnement est à risque et une reconstruction est requise avant le 1er août 2026. Vérifiez l’état du réseau virtuel géré dans la page Vue d’ensemble du portail Azure.
  • Si vous obtenez : defaultAction: Allow, alors le pare-feu n’est pas utilisé comme mécanisme de contrôle principal. Il n’existe donc aucune dépendance aux services approuvés et cette modification particulière ne vous touche pas.
  • Si un point de terminaison privé est déjà configuré et que l’espace de travail dispose d’un réseau virtuel géré, alors vous avez déjà effectué la migration et aucune action supplémentaire n’est requise.

Le deuxième scénario mérite toutefois une nuance. Si le compte de stockage accepte le trafic provenant de tous les réseaux, la fin du mécanisme de services approuvés ne vous affectera pas le 1er août 2026. Toutefois, cela signifie également que votre compte demeure ouvert à tous les réseaux, ce qui représente un risque de sécurité en soi. Dès que ce compte sera correctement limité à des réseaux sélectionnés, vous reviendrez dans la configuration à risque. Un compte ouvert reporte simplement l’échéance; il n’élimine pas les travaux nécessaires.

Nous recommandons tout de même de planifier l’adoption du modèle basé sur les réseaux privés selon un calendrier maîtrisé afin de renforcer la sécurité sans subir la pression d’une échéance.

Pour confirmer cette configuration dans le portail Azure, ouvrez la page Accès réseau public du compte de stockage. L’état à risque correspond à un accès réseau public activé avec l’option Réseaux sélectionnés. Du côté de Synapse, consultez la page Vue d’ensemble. Si le champ Réseau virtuel géré affiche « Non », il s’agit du paramètre qui ne peut plus être modifié après la création de l’espace de travail et qui justifie généralement une reconstruction.

Un dernier élément doit également être vérifié. La même logique liée aux services approuvés s’applique à tout Azure Key Vault auquel l’espace de travail accède à travers un pare-feu. Même si votre compte de stockage n’est pas concerné, un Key Vault accessible par ce mécanisme demeure soumis à la même échéance.

Deux conclusions fréquentes, mais erronées

Certaines informations visibles dans le portail Azure peuvent sembler rassurantes alors qu’elles ne le sont pas.

La première concerne l’accès réseau public. Voir l’état « Activé » n’implique pas nécessairement que la ressource est accessible à tous. Lorsque l’option Réseaux sélectionnés est utilisée, le portail affiche également « Activé ». Le point de terminaison public existe toujours, mais il est protégé par un pare-feu restrictif. C’est précisément cette combinaison qui est visée par le retrait du mécanisme actuel.

La deuxième concerne les points de terminaison privés côté stockage. Si votre équipe a ajouté un point de terminaison privé au compte de stockage, il est naturel de croire que Synapse en bénéficie automatiquement. Ce n’est pas le cas. Un espace de travail sans réseau virtuel géré continue d’utiliser le point de terminaison public et l’exception des services approuvés. Le point de terminaison réellement requis est un point de terminaison privé géré créé à partir de l’espace de travail Synapse lui-même.

Qui est le plus touché

Les organisations les plus touchées sont les clientes de Microsoft Dynamics 365 utilisant Synapse Link.

Ce changement concerne largement Synapse Link pour Dataverse, notamment Finance and Supply Chain Management ainsi que les applications de gestion de la relation client. Aucune organisation ne devrait présumer qu’elle est exemptée.

Plusieurs de ces équipes ne sont pas spécialisées dans Azure. Elles ont adopté Synapse Link parce qu’il s’agissait de l’approche recommandée pour transférer les données Dynamics 365 vers un lac de données, et non pour gérer la complexité du réseautage Synapse.

Bon nombre de ces organisations ont récemment migré d’Export to Data Lake vers Synapse Link ou Fabric Link. Les équipes ayant opté pour Synapse Link et n’ayant pas activé le réseau virtuel géré devront maintenant envisager une nouvelle migration.

Ce que la correction implique

Puisque le réseau virtuel géré ne peut être activé qu’au moment de la création de l’espace de travail, la seule approche consiste à déployer un nouvel espace de travail doté de cette fonctionnalité et à y migrer les composants existants.

Cette migration n’exige pas d’interruption de service. Le nouvel espace de travail peut être exploité en parallèle avec l’environnement actuel jusqu’au moment choisi pour le basculement.

L’ampleur des efforts dépend de votre environnement. Un espace de travail qui utilise uniquement Synapse Link et des tables externes peut être migré relativement simplement. À l’inverse, un environnement comportant des pools SQL dédiés et de nombreux pipelines nécessitera davantage d’efforts et de validation.

La principale source de travail et de risque se situe généralement en aval : un nouvel espace de travail implique habituellement un nouveau nom d’hôte et de nouvelles connexions. Toutes les dépendances utilisant l’ancien environnement doivent donc être recensées et redirigées.

Comment Alithya peut vous aider

Le diagnostic présenté ci-dessus peut être effectué par votre équipe. La reconstruction et la migration représentent toutefois un tout autre défi.

La différence entre une transition maîtrisée sans interruption de service et un projet réalisé dans l’urgence repose essentiellement sur la planification et l’expérience.

Notre pratique Microsoft Azure et Données a développé des approches de remédiation spécifiquement conçues pour cette transition. Notre évaluation de préparation Synapse confirme précisément la situation de votre environnement, identifie les impacts sur les systèmes en aval et fournit un plan de migration accompagné d’une estimation adaptée à vos espaces de travail.

Nous pouvons ensuite vous accompagner dans la migration parallèle et le redéploiement des connexions selon un calendrier qui protège vos opérations tout en vous permettant de respecter l’échéance du 1er août 2026 avec une marge confortable.

Nous contacter pour découvrir comment Alithya peut soutenir la remédiation de votre environnement Synapse.

Préparé par la pratique Données et Microsoft Azure d’Alithya. Les affirmations techniques ont été validées à partir de Microsoft Learn en juin 2026.

Références