Normes opérationnelles pour une plateforme de données unifiée

Cet article aide les décideurs à établir des normes opérationnelles pour développer et utiliser des produits de données sur une plateforme de données unifiée.

Les organisations doivent décider de la façon dont les domaines de données rendent les données disponibles via OneLake et les transforment en produits de données approuvés pour la réutilisation au sein de l’organisation. La gouvernance centrale doit établir des normes à l’échelle de l’organisation. Les domaines de données doivent posséder leurs produits de données et prendre des décisions d’implémentation dans ces limites.

Les normes cohérentes réduisent les duplications inutiles et aident les consommateurs à trouver et à utiliser des données fiables avec une protection appropriée. Cet article traite de la prise de données, de la transformation, de la publication, de la consommation, de la gestion du cycle de vie, de la sécurité et des exceptions.

1. Collecte de données

Quelles normes doivent régir l’ingestion des données ? L’organisation doit définir des normes précisant quelles données sources doivent être mises à disposition via OneLake et quelles méthodes privilégier pour les rendre disponibles. Ne mettez les données sources à disposition via OneLake que si elles répondent aux besoins d’un produit de données approuvé ou d’un cas d’usage analytique.

1.1 Méthodes d’ingestion des données

Comment les domaines de données doivent-ils rendre les données sources disponibles via OneLake ? L’organisation doit préférer les modèles qui réduisent le déplacement inutile des données.

• Les raccourcis doivent constituer la méthode à privilégier lorsque les données prises en charge peuvent rester à leur emplacement source.
• La mise en miroir doit être le modèle préféré pour les sources prises en charge lorsque Fabric a besoin d’un accès synchronisé à une base de données ou un catalogue externe.
• Le déplacement des données doit être utilisé lorsque Fabric nécessite une copie des données et que les raccourcis ou la mise en miroir ne répondent pas aux exigences.

Les domaines de données peuvent choisir une autre méthode d’ingestion approuvée lorsque la méthode privilégiée ne répond pas aux exigences. Consultez Unifier les données à l’aide des raccourcis et de la mise en miroir OneLake.

1.2 Sources de données

Comment intégrer différentes sources de données ? Les domaines de données doivent mettre leurs données de sortie fiables à disposition via OneLake, plutôt que de recréer des traitements équivalents dans Fabric sans avantage organisationnel mesurable.

• Microsoft 365 : Microsoft 365 doit normalement rester le système de référence pour le contenu collaboratif. Les domaines de données doivent intégrer le contenu Microsoft 365 à la plateforme de données unifiée uniquement lorsqu’un produit de données approuvé l’exige, par exemple pour une analyse structurée.

• Bases de données opérationnelles : les bases de données opérationnelles doivent rester optimisées pour les charges de travail transactionnelles. Les domaines de données ne doivent pas autoriser les charges de travail analytiques ou IA à interroger directement une base de données opérationnelle, sauf si le propriétaire de la base de données a approuvé la charge de travail attendue et établi les contrôles requis.

• Plateformes de données existantes : les lacs de données existants et les plateformes de transformation, comme Azure Databricks, doivent rester en place lorsqu’elles continuent de répondre aux exigences de l’organisation. Toute migration ou recréation dans Fabric doit apporter un avantage organisationnel mesurable. Consultez raccourcis, Mise en miroir d’Unity Catalog d’Azure Databricks et intégrer OneLake à Azure Databricks.

2. Transformation des données

Comment transformer des données en produits de données ? L’organisation doit définir une plateforme de transformation privilégiée afin de limiter les duplications inutiles de fonctionnalités. Microsoft Fabric peut servir de plateforme par défaut lorsqu’elle répond aux exigences du produit de données. Les plateformes existantes, telles que Azure Databricks, doivent rester en cours d’utilisation lorsqu’elles fournissent des fonctionnalités requises ou représentent un investissement organisationnel établi.

Modèle de transformation : l’architecture Medallion doit être le modèle préféré lorsque les données bénéficient d’un affinement progressif. Les domaines de données doivent utiliser uniquement les étapes de qualité requises pour produire un produit de données fiable.

Consultez Vues matérialisées de lakehouse dans Fabric, Architecture de médaillon lakehouse dans Fabric et Analytique de bout en bout avec Microsoft Fabric.

3. Publication

Quels éléments doivent être en place pour publier un produit de données ? Un produit de données peut être constitué d’une ou de plusieurs ressources techniques qui, ensemble, fournissent une offre métier prise en charge. Chaque produit de données publié doit avoir un propriétaire responsable, une finalité métier prise en charge, une utilisation prévue, un processus d’accès et un statut de qualité. Lorsque les consommateurs dépendent d’une disponibilité rapide des données, le produit doit également définir un engagement opérationnel.

• Contrôles de sécurité : les contrôles de sécurité requis doivent être en place avant la publication. Les produits de données sensibles doivent disposer de la classification et des exigences de traitement requises. Consultez Étiquettes de confidentialité Purview.

• Métadonnées : l’organisation doit définir des métadonnées minimales pour les produits de données publiés. Les consommateurs doivent être en mesure de déterminer le domaine de données propriétaire, le propriétaire responsable, l’utilisation prise en charge, l’engagement de qualité et les exigences d’accès. Consultez Balises dans Fabric et Métadonnées personnalisées dans Purview.

• Traçabilité des données : les informations de traçabilité disponibles doivent être suffisamment détaillées pour comprendre les dépendances importantes en amont et évaluer les répercussions en aval. Voir Lineage dans Fabric.

4. Découverte

Comment les consommateurs doivent-ils trouver des produits de données ? Les produits de données publiés doivent être faciles à trouver par défaut. Utilisez le catalogue OneLake pour la découverte Fabric native. Représentez un produit de données dans Catalogue unifié Microsoft Purview lorsqu’il nécessite un contexte métier d’entreprise ou une gouvernance dans l’ensemble du patrimoine de données.

Consultez la vue d’ensemble du catalogue OneLake et les produits de données dans Le catalogue unifié.

5. Approbation

Comment les consommateurs doivent-ils déterminer si un produit de données est digne de confiance pour la réutilisation ? L’approbation dans Fabric peut aider les consommateurs à évaluer le niveau de garantie offert par les éléments qui constituent un produit de données. L’organisation doit définir des significations et des exigences cohérentes pour chaque niveau d’approbation.

• La promotion doit indiquer que le domaine de données propriétaire recommande la réutilisation du produit de données.

• La certification doit indiquer qu’un réviseur autorisé a confirmé que le produit de données répond aux normes organisationnelles définies.

La publication ne devrait pas nécessiter de certification. La publication établit le seuil organisationnel minimal permettant la réutilisation des données dans des conditions prises en charge. La certification offre une assurance supplémentaire. Consultez Approbation dans Fabric.

6. Consommation approuvée

Quand les consommateurs peuvent-ils utiliser un produit de données sans approbation supplémentaire ? Les produits de données peuvent prendre en charge de nombreux modes de consommation, notamment l’analytique, les applications, l’ancrage de l’IA et les agents. Les mêmes normes approuvées d’utilisation et de sécurité s’appliquent indépendamment de la technologie utilisée. Le domaine de données responsable doit définir les utilisations prises en charge par chaque produit de données publié. Les consommateurs doivent pouvoir utiliser le produit de données sans approbation supplémentaire lorsque leur utilisation proposée se situe dans ces limites.

L’organisation doit définir des utilisations qui nécessitent toujours une révision supplémentaire. Ces utilisations doivent inclure les situations dans lesquelles la consommation modifie sensiblement le niveau de risque associé aux données, par exemple leur divulgation à des tiers ou leur utilisation dans des scénarios d’IA ayant des conséquences importantes.

L’approbation d’une utilisation ne doit pas impliquer l’approbation d’une autre. Par exemple, un produit de données approuvé pour les rapports internes ne doit pas être automatiquement approuvé pour la publication externe. Un produit de données approuvé pour l’ancrage de l’IA ne doit pas être automatiquement approuvé pour un agent capable d’effectuer des actions ayant des conséquences importantes.

7. Cycle de vie des produits de données

Comment les domaines de données doivent-ils gérer les produits de données dont dépendent les consommateurs ? Les produits de données publiés créent des dépendances que le domaine de données propriétaire doit gérer. L’organisation doit établir des normes pour les changements et la mise hors service afin que les consommateurs puissent planifier les interruptions et les transitions si nécessaire. Ensemble, les exigences de publication et les engagements de cycle de vie établissent le contrat entre le domaine de données propriétaire et les consommateurs du produit de données.

7.1 Fiabilité

Quelles normes de fiabilité doivent s’appliquer aux produits de données publiés ? L’organisation doit établir des exigences de fiabilité en fonction de l’impact métier d’un produit de données devenant indisponible ou perdant des données. Les domaines de données doivent appliquer ces exigences au produit de données complet plutôt que de supposer que la fiabilité de OneLake ou d’un autre composant de plateforme fournit le niveau de protection requis.

• Classification de la fiabilité : l’organisation doit définir des exigences de fiabilité pour chaque niveau de criticité métier. Les domaines de données doivent s’assurer que le produit de données complet répond aux exigences applicables.

• Exigences de récupération : le domaine de données propriétaire doit s’assurer que le produit de données complet répond aux exigences de fiabilité associées à sa criticité métier. La conception de récupération doit tenir compte du produit de données et des dépendances nécessaires à son utilisation. Les produits de données critiques pour l’entreprise doivent avoir un processus de récupération testé.

• Fabric exigences de capacité : les domaines de données doivent s'assurer que la capacité de Fabric partagée n'empêche aucun produit de données affecté de répondre à ses exigences de fiabilité. Utilisez une capacité distincte lorsqu’un produit de données nécessite des contrôles au niveau de la capacité qui ne doivent pas s’appliquer à d’autres produits.

Ne considérez pas la réplication OneLake comme un mécanisme complet de récupération des produits de données. Chaque produit de données critique pour l’activité doit disposer d’une stratégie de récupération couvrant ses données et les éléments Fabric nécessaires. Consultez les recommandations relatives à la récupération d’urgence et à la protection des données OneLake, ainsi que les recommandations de récupération d’urgence propres à chaque expérience Fabric.

7.2 Modifications

Comment les domaines de données doivent-ils gérer les modifications qui affectent les consommateurs ? Les domaines de données responsables doivent gérer les changements incompatibles en fonction de l’impact métier du produit de données. Avant d’apporter une modification entraînant un changement cassant, les équipes doivent identifier les consommateurs concernés et prévoir une période de transition proportionnée aux répercussions.

Les engagements en matière de gestion des modifications doivent être renforcés à mesure que les dépendances et la criticité métier augmentent. Un produit de données largement réutilisé qui prend en charge un processus métier critique doit avoir des exigences de modification plus fortes qu’un produit de données avec une utilisation limitée.

Les domaines de données doivent utiliser lignage et l’analyse d’impact disponibles pour identifier les dépendances techniques. Ils doivent également tenir compte des dépendances métier connues que la traçabilité technique ne capture pas. Consultez Fabric analyse d’impact.

7.3 Retraite

Comment un domaine de données doit-il mettre hors service un produit de données publié ? L’organisation doit définir des exigences minimales pour le retrait des produits de données. Avant le retrait, le domaine de données propriétaire doit évaluer les dépendances actives et prévoir une période de transition proportionnée aux répercussions sur l’activité.

Le domaine de données propriétaire doit identifier un remplacement approuvé lorsqu’il en existe un. Il doit supprimer l’approbation lorsque les consommateurs ne doivent plus créer de nouvelles dépendances. Les consommateurs existants doivent recevoir un avis suffisant avant la fin de l’accès.

8. Sécurité des produits de données

Comment les exigences d’autorisation doivent-elles s’appliquer lorsque les produits de données sont consommés ? Un nouveau chemin de consommation ne doit pas affaiblir la protection requise par le produit de données source. L’organisation doit classifier les modes de consommation approuvés en fonction du maintien ou non de l’efficacité des exigences d’autorisation du produit de données.

8.1. Autorisation source conservée

Quand un modèle de consommation conserve-t-il l’autorisation du produit de données source ? Un modèle de consommation peut s’appuyer sur l’autorisation du produit de données source lorsqu’il conserve l’identité du consommateur et continue d’appliquer les restrictions d’accès requises.

Par exemple, si un produit de données de vente restreint chaque vendeur aux clients affectés, le modèle de consommation doit conserver cette restriction pour chaque consommateur. Les organisations doivent valider chaque mode approuvé avant d’autoriser son utilisation pour consommer des données à accès restreint.

Consultez Agents de données Fabric, Power BI et Serveur MCP OneLake.

8.2. Nouvelle limite d’autorisation

Quelles normes s’appliquent lorsqu’un mode de consommation doit établir une nouvelle limite d’autorisation ? Un mode de consommation qui ne préserve pas les exigences d’autorisation du produit de données source doit établir une nouvelle limite d’autorisation offrant une protection équivalente. L’organisation ne doit pas approuver ce mode pour les données à accès restreint s’il ne peut pas fournir cette protection.

Cette situation se produit généralement lorsqu’un service crée une autre représentation des données ou accède aux données sources par le biais d’une identité d’application partagée.

• Indexes : un index de recherche crée une autre représentation des données sources. Les données restreintes dans l’index doivent rester protégées en fonction des exigences d’autorisation du produit de données source. L’organisation doit valider la façon dont les autorisations sources sont représentées et appliquées dans l’index plutôt que de supposer que les contrôles d’accès OneLake protègent automatiquement le contenu indexé. Consultez OneLake Indexer, contrôle d’accès au niveau du document et Recherche Azure AI meilleures pratiques de sécurité.

• Identités de service ou partagées : lorsqu’un service consommateur accède à un produit de données par le biais d’une identité de service au lieu de l’identité du consommateur, l’autorisation source s’applique à cette identité de service. La solution consommatrice doit appliquer toutes les exigences d’autorisation au niveau du consommateur imposées par le produit de données. Consultez Authentification pour les outils du protocole de contexte de modèle (MCP) et Utiliser l’authentification de principal de service avec l’agent de données Fabric.

9. Exceptions aux normes

Quelles exceptions un domaine de données peut-il approuver ? L’organisation doit définir les normes que les domaines de données peuvent adapter et celles qui nécessitent une approbation centrale.

• Les domaines de données doivent avoir l’autorité d’approuver les exceptions qui affectent uniquement leur budget ou leur modèle d’exploitation local. Ils ne doivent pas approuver les exceptions qui affaiblissent les exigences à l’échelle de l’organisation en matière de sécurité ou de conformité réglementaire. L’approbation centrale doit également être requise pour les exceptions qui affaiblissent les exigences d’interopérabilité à l’échelle de l’organisation ou la norme minimale de publication du produit de données.

• La gouvernance centrale doit être responsable des normes à l’échelle de l’organisation et les examiner à mesure que les fonctionnalités de Fabric et les pratiques organisationnelles évoluent. Les domaines de données doivent communiquer les dérogations récurrentes afin qu’elles soient prises en compte lors de ces examens. Les exceptions répétées peuvent indiquer qu’une norme organisationnelle doit changer.