Modifier

Partager via

Utiliser Azure Synapse Analytics pour concevoir une solution BI d’entreprise

Power BI
Azure Synapse Analytics
Azure Data Factory
Microsoft Entra ID
Stockage Blob Azure

Cet article explique comment transférer des données d’un entrepôt de données local vers un environnement cloud, puis utiliser un modèle décisionnel (BI) pour servir les données. Vous pouvez utiliser cette approche comme objectif final ou une première étape vers une modernisation complète avec des composants basés sur le cloud.

Ce guide s’appuie sur le scénario de bout en bout Azure Synapse Analytics. Ce processus utilise des pipelines Azure Synapse Analytics pour ingérer des données d’une base de données SQL dans des pools SQL. Ensuite, il effectue une transformation de données pour l’analyse. Cet article se concentre sur les pipelines Azure Synapse Analytics, mais vous pouvez également utiliser des pipelines Azure Data Factory ou des pipelines Fabric Data Factory pour effectuer ces tâches.

Quand utiliser cette architecture

Vous pouvez utiliser différentes méthodes pour répondre aux besoins de l’entreprise en matière de décisionnel d’entreprise. Différents aspects définissent les exigences métier, comme les investissements technologiques actuels, les compétences humaines, la chronologie de la modernisation, les objectifs futurs, et si vous avez une préférence pour la plateforme en tant que service (PaaS) ou le logiciel en tant que service (SaaS).

Tenez compte des approches de conception suivantes :

  • A lakehouse dans Microsoft Fabric

  • Fabric et Azure Databricks pour les clients qui ont déjà investi dans Azure Databricks et Power BI et souhaitent moderniser avec Fabric

  • Décisionnel entreprise pour les petites et moyennes entreprises qui utilisent un écosystème Azure SQL et Fabric

  • Entreposage de données entièrement sur Fabric pour les clients qui préfèrent SaaS

L’architecture de cet article part du principe que vous utilisez l’entrepôt de données Azure Synapse Analytics comme couche persistante du modèle sémantique d’entreprise et que vous utilisez Power BI pour le décisionnel. Cette approche PaaS offre la flexibilité nécessaire pour répondre aux différentes exigences et préférences de l’entreprise.

Architecture

Diagramme montrant l’architecture bi d’entreprise avec Azure Synapse Analytics.

Téléchargez un fichier Visio de cette architecture.

Workflow

Source de données

Ingestion et stockage de données

Analyse et rapports

Components

Ce scénario utilise les composants suivants :

  • azure SQL Database est un serveur SQL PaaS hébergé par Azure. Cette architecture utilise SQL Database pour illustrer le flux de données pour le scénario de migration.

  • Data Lake Storage fournit un stockage cloud flexible pour les données non structurées utilisées pour conserver les résultats de la migration intermédiaire.

  • azure Synapse Analytics est un service d’analytique d’entreprise pour l’entreposage de données et les systèmes Big Data. Azure Synapse Analytics sert de stockage principal de calcul et de stockage persistant dans la modélisation sémantique et la maintenance de l’entreprise.

  • Power BI Premium est un outil décisionnel qui présente et visualise les données dans ce scénario.

  • Microsoft Entra ID est une suite de solutions réseau et d’identité multicloud qui prend en charge le flux d’authentification et d’autorisation.

Architecture simplifiée

Diagramme montrant l’architecture simplifiée d’entreprise BI.

Détails du scénario

Dans ce scénario, une organisation dispose d’une base de données SQL qui contient un entrepôt de données local volumineux. L’organisation souhaite utiliser Azure Synapse Analytics pour effectuer une analyse, puis fournir ces insights via Power BI aux utilisateurs et à l’analytique.

Authentification

Microsoft Entra ID authentifie les utilisateurs qui se connectent aux tableaux de bord et applications Power BI. L’authentification unique connecte les utilisateurs à la source de données dans un pool provisionné Azure Synapse Analytics. L’autorisation se produit sur la source.

Chargement incrémentiel

Lorsque vous exécutez un processus d’extraction, de transformation, de chargement (ETL) automatisé ou d’extraction, de chargement, de transformation (ELT), vous devez charger uniquement les données qui ont changé depuis l’exécution précédente. Ce processus est appelé charge incrémentielle. À l’inverse, une charge complète charge toutes les données. Pour effectuer une charge incrémentielle, déterminez comment identifier les données modifiées. Vous pouvez utiliser une approche de valeur de marque d’eau élevée, qui suit la dernière valeur d’une colonne date-heure ou d’une colonne entière unique dans la table source.

Vous pouvez utiliser tables temporelles dans SQL Server. Les tables temporelles sont des tables avec version système qui stockent l’historique des modifications de données. Le moteur de base de données enregistre automatiquement l’historique de chaque modification dans une table d’historique distincte. Pour interroger les données historiques, vous pouvez ajouter une clause FOR SYSTEM_TIME à une requête. En interne, le moteur de base de données interroge la table d’historique, mais cette opération est transparente pour l’application.

Les tables temporelles prennent en charge les données de dimension, qui peuvent changer au fil du temps. Les tables de faits représentent généralement une transaction immuable, comme une vente. De ce fait, il n’est pas utile de conserver l’historique des versions du système. Au lieu de cela, les transactions ont généralement une colonne qui représente la date de transaction. La colonne peut être utilisée comme valeur de filigrane. Par exemple, dans l’entrepôt de données AdventureWorks, les tables SalesLT.* ont un champ LastModified.

Voici le flux général du pipeline ELT :

  1. Pour chaque table de la base de données source, effectuez le suivi de l’heure de coupure lors de l’exécution du dernier travail ELT. Stockez ces informations dans l’entrepôt de données. Lors de la configuration initiale, toutes les heures sont définies sur 1-1-1900.

  2. Lors de l’étape d’exportation des données, l’heure de coupure est transmise sous la forme d’un paramètre à un ensemble de procédures stockées dans la base de données source. Ces procédures stockées interrogent tous les enregistrements modifiés ou créés après le délai d’arrêt. Pour toutes les tables de l’exemple, vous pouvez utiliser la colonne ModifiedDate.

  3. Lorsque la migration des données est terminée, mettez à jour la table qui stocke les heures de coupure.

Pipeline de données

Ce scénario utilise l’exemple de base de données AdventureWorks comme source de données. Le modèle de chargement incrémentiel des données garantit que seules les données modifiées ou ajoutées après l’exécution du pipeline la plus récente sont chargées.

Outil de copie pilotée par les métadonnées

L’outil de copie intégré piloté par les métadonnées dans les pipelines Azure Synapse Analytics charge de manière incrémentielle toutes les tables contenues dans la base de données relationnelle.

  1. Utilisez une interface de l’Assistant pour connecter l’outil Copier des données à la base de données source.

  2. Une fois connecté, configurez le chargement incrémentiel ou le chargement complet pour chaque table.

  3. L’outil Copier des données crée les pipelines et les scripts SQL nécessaires pour générer la table de contrôle. Cette table stocke les données, telles que la valeur ou la colonne de filigrane élevée pour chaque table, pour le processus de chargement incrémentiel.

  4. Une fois ces scripts exécutés, le pipeline charge toutes les tables d’entrepôt de données sources dans le pool dédié Azure Synapse Analytics.

Capture d’écran montrant l’outil de copie pilotée par les métadonnées dans Azure Synapse Analytics.

Avant que l’outil charge les données, il crée trois pipelines pour itérer sur les tables de la base de données.

Les pipelines effectuent les tâches suivantes :

  • Comptez le nombre d’objets, tels que les tables, à copier dans l’exécution du pipeline.

  • Itérer sur chaque objet à charger ou copier.

  • Une fois qu’un pipeline effectue une itération sur chaque objet, il effectue les tâches suivantes :

    • Vérifie si une charge delta est requise. Sinon, le pipeline termine une charge complète normale.

    • Récupère la valeur de filigrane élevée de la table de contrôles.

    • Copie les données des tables sources dans le compte intermédiaire dans Data Lake Storage.

    • Charge des données dans le pool SQL dédié via la méthode de copie sélectionnée, telle que la commande PolyBase ou Copy.

    • Met à jour la valeur de filigrane élevée dans la table de contrôles.

Charger des données dans un pool SQL Azure Synapse Analytics

L’activité de copie copie les données de la base de données SQL dans le pool SQL Azure Synapse Analytics. Dans Azure, la base de données SQL de cet exemple utilise le runtime d’intégration Azure pour lire les données de la base de données SQL et écrire les données dans l’environnement intermédiaire spécifié.

L’instruction de copie charge ensuite les données de l’environnement intermédiaire dans le pool dédié Azure Synapse Analytics.

Utiliser des pipelines Azure Synapse Analytics

Les pipelines dans Azure Synapse Analytics définissent un ensemble ordonné d’activités pour terminer un modèle de charge incrémentiel. Les déclencheurs manuels ou automatiques démarrent le pipeline.

Transformer les données

L’exemple de base de données de cette architecture de référence est petit, de sorte que les tables répliquées qui n’ont aucune partition ne sont créées. Pour les charges de travail de production, les tables distribuées peuvent améliorer les performances des requêtes. Pour plus d’informations, consultez Conseils pour la conception de tables distribuées dans Azure Synapse Analytics. Les exemples de scripts exécutent les requêtes via une classe de ressource de statique.

Dans un environnement de production, envisagez de créer des tables intermédiaires qui ont une distribution de tourniquet. Ensuite, transformez et déplacez les données dans des tables de production qui ont des index columnstore en cluster, ce qui offre les meilleures performances de requête globales. Les index columnstore sont optimisés pour les requêtes qui analysent de nombreux enregistrements.

Les index Columnstore ne s’exécutent pas de manière optimale pour les recherches singleton ou recherchent une seule ligne. Si vous devez effectuer des recherches singleton fréquentes, vous pouvez ajouter un index non cluster à une table, ce qui augmente la vitesse. Toutefois, les recherches singleton sont généralement moins courantes dans les scénarios d’entrepôt de données que les charges de travail de traitement des transactions en ligne. Pour plus d’informations, consultez tables d’index dans azure Synapse Analytics.

Notes

Les tables columnstore cluster ne prennent pas en charge les types de données varchar(max), nvarchar(max) ou varbinary(max). Si vous utilisez ces types de données, envisagez un segment de mémoire ou un index cluster. Vous pouvez également envisager de placer ces colonnes dans une table distincte.

Utiliser Power BI Premium pour accéder, modéliser et visualiser des données

Power BI Premium prend en charge plusieurs options pour se connecter aux sources de données sur Azure. Vous pouvez utiliser des pools provisionnés Azure Synapse Analytics pour effectuer les tâches suivantes :

  • Importation : les données sont importées dans le modèle Power BI.
  • DirectQuery : les données sont extraites directement du stockage relationnel.
  • Modèle composite : combinez l’importation pour certaines tables et DirectQuery pour d’autres.

Ce scénario utilise le tableau de bord DirectQuery, car il présente une petite quantité de données et une faible complexité du modèle. DirectQuery délègue la requête au puissant moteur de calcul en dessous et utilise des fonctionnalités de sécurité étendues sur la source. DirectQuery garantit que les résultats sont toujours cohérents avec les données sources les plus récentes.

Le mode d’importation fournit le temps de réponse de requête le plus rapide. Envisagez le mode d’importation si :

  • Le modèle s’adapte entièrement à la mémoire de Power BI.
  • La latence des données entre les actualisations est acceptable.
  • Vous avez besoin de transformations complexes entre le système source et le modèle final.

Dans ce cas, les utilisateurs finaux veulent un accès complet aux données les plus récentes sans retard dans l’actualisation de Power BI, et ils veulent toutes les données historiques, qui dépassent la capacité du jeu de données Power BI. Un jeu de données Power BI peut gérer 25 à 400 Go en fonction de la taille de capacité. Le modèle de données du pool SQL dédié se trouve déjà dans un schéma en étoile et ne nécessite pas de transformation. DirectQuery est donc un choix approprié.

Capture d’écran montrant le tableau de bord dans Power BI.

Utilisez Power BI Premium pour gérer des modèles volumineux, des rapports paginés et des pipelines de déploiement. Tirez parti du point de terminaison Azure Analysis Services intégré. Vous pouvez également avoir une capacité dédiée avec une proposition de valeur unique.

Lorsque le modèle BI augmente ou que la complexité du tableau de bord augmente, vous pouvez basculer vers des modèles composites et importer des parties de tables de recherche via tables hybrides, et importer des données prédéfinies. Vous pouvez activer mise en cache des requêtes dans Power BI pour les jeux de données importés et utiliser tables doubles pour la propriété du mode de stockage.

Dans le modèle composite, les jeux de données servent de couche directe virtuelle. Lorsque les utilisateurs interagissent avec des visualisations, Power BI génère des requêtes SQL vers des pools SQL Azure Synapse Analytics. Power BI détermine s’il faut utiliser un stockage en mémoire ou DirectQuery en fonction de l’efficacité. Le moteur décide quand passer de la mémoire à DirectQuery et envoie la logique au pool SQL Azure Synapse Analytics. Selon le contexte des tables de requête, ils peuvent agir comme des modèles composites mis en cache (importés) ou non mis en cache. Vous pouvez choisir la table à mettre en cache en mémoire, combiner des données à partir d’une ou plusieurs sources DirectQuery, ou combiner les données sources DirectQuery et les données importées.

Quand vous utilisez DirectQuery avec un pool provisionné Azure Synapse Analytics :

  • Utilisez Azure Synapse Analytics mise en cache du jeu de résultats pour mettre en cache les résultats de requête dans la base de données utilisateur pour une utilisation répétitive. Cette approche améliore les performances des requêtes en millisecondes et réduit l’utilisation des ressources de calcul. Les requêtes qui utilisent des jeux de résultats mis en cache ne consomment pas d’emplacements d’accès concurrentiel dans Azure Synapse Analytics. Elles ne sont donc pas comptabilisées par rapport aux limites de concurrence existantes.

  • Utilisez Azure Synapse Analytics vues matérialisées pour précomputer, stocker et gérer des données comme une table. Les requêtes qui utilisent toutes les données ou un sous-ensemble des données dans des vues matérialisées peuvent obtenir des performances plus rapides sans avoir à référencer directement la vue matérialisée définie pour l’utiliser.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

La modernisation du cloud introduit des problèmes de sécurité, tels que les violations de données, les infections par les programmes malveillants et l’injection de code malveillante. Vous avez besoin d’un fournisseur de cloud ou d’une solution de service capable de répondre à vos préoccupations, car des mesures de sécurité insuffisantes peuvent créer des problèmes majeurs.

Ce scénario traite les problèmes de sécurité les plus exigeants en utilisant une combinaison de contrôles de sécurité en couches : réseau, identité, confidentialité et contrôles d’autorisation. Un pool provisionné Azure Synapse Analytics stocke la plupart des données. Power BI accède aux données via DirectQuery via l’authentification unique. Vous pouvez utiliser Microsoft Entra ID pour l’authentification. Il existe également des contrôles de sécurité étendus pour l’autorisation des données dans les pools approvisionnés.

Voici quelques-unes des questions de sécurité courantes :

  • Définissez qui peut voir les données.

    • Assurez-vous que vos données sont conformes aux directives fédérales, locales et d’entreprise pour atténuer les risques de violation des données. Azure Synapse Analytics fournit plusieurs fonctionnalités de protection des données pour assurer la conformité.

  • Déterminez comment vérifier l’identité d’un utilisateur.

    • Utilisez Azure Synapse Analytics pour contrôler qui peut accéder aux données via contrôle d’accès et d’authentification.

  • Choisissez une technologie de sécurité réseau pour protéger l’intégrité, la confidentialité et l’accès de vos réseaux et données.

  • Choisissez des outils pour détecter et vous avertir des menaces.

    • Utilisez Azure Synapse Analytics fonctionnalités de détection des menaces, telles que l’audit SQL, la détection des menaces SQL et l’évaluation des vulnérabilités pour auditer, protéger et surveiller les bases de données.

  • Déterminez comment protéger les données dans votre compte de stockage.

    • Utilisez des comptes stockage Azure pour les charges de travail qui nécessitent des temps de réponse rapides et cohérents ou qui ont un nombre élevé d’opérations d’entrée/sortie par seconde. Les comptes de stockage peuvent stocker tous vos objets de données et avoir plusieurs options de sécurité de compte de stockage .

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Cette section fournit des informations sur la tarification des différents services impliqués dans cette solution et mentionne les décisions prises pour ce scénario avec un exemple de jeu de données. Utilisez cette configuration de départ dans la calculatrice de prix Azure , puis ajustez-la pour qu’elle corresponde à votre scénario.

Azure Synapse Analytics

Azure Synapse Analytics est une architecture serverless que vous pouvez utiliser pour mettre à l’échelle vos niveaux de calcul et de stockage indépendamment. Les ressources de calcul entraînent des coûts en fonction de l’utilisation. Vous pouvez mettre à l’échelle ou suspendre ces ressources à la demande. Les ressources de stockage entraînent des coûts par téraoctet, de sorte que vos coûts augmentent à mesure que vous ingérez des données.

Pipelines Azure Synapse Analytics

Trois composants principaux influencent le prix d’un pipeline :

  • Activités du pipeline de données et heures du runtime d’intégration
  • Taille et implémentation du cluster de flux de données
  • Frais d’opération

Pour plus d’informations sur la tarification, consultez l’onglet Data Integration sur tarification d’Azure Synapse Analytics.

Le prix varie en fonction des composants ou des activités, de la fréquence et du nombre d’unités d’exécution d’intégration.

Pour l’exemple de jeu de données, qui utilise le runtime d’intégration hébergé par Azure standard, l’activité copier des données sert de cœur du pipeline. Il s’exécute quotidiennement pour toutes les entités (tables) de la base de données source. Le scénario ne contient pas de flux de données. Et cela n’entraîne pas de coûts opérationnels, car les pipelines exécutent moins d’un million d’opérations par mois.

Pool et stockage dédiés Azure Synapse Analytics

Pour l’exemple de jeu de données, vous pouvez provisionner 500 unités d’entrepôt de données (DWU) pour offrir une expérience fluide pour les charges analytiques. Vous pouvez conserver le calcul pendant les heures de travail à des fins de création de rapports. Si la solution passe en production, utilisez la capacité de l’entrepôt de données réservée comme stratégie économique. Utilisez différentes techniques pour optimiser les métriques de coût et de performances.

Pour plus d’informations sur la tarification d’un pool dédié Azure Synapse Analytics, consultez l’onglet d’entreposage de données sur tarification d’Azure Synapse Analytics. Dans le modèle de consommation dédié, les clients entraînent des coûts pour chaque DWU approvisionné, par heure de temps d’activité. Prenez également en compte les coûts de stockage des données, notamment la taille de vos données au repos, les instantanés et la géoredondance.

Stockage d'objets blob

Envisagez d’utiliser la capacité réservée stockage Azure pour réduire les coûts de stockage. Avec ce modèle, vous bénéficiez d'une remise si vous réservez une capacité de stockage fixe pendant un ou trois ans. Pour plus d’informations, consultez Optimiser les coûts pour le stockage d’objets blob avec une capacité réservée. Ce scénario n’utilise pas de stockage persistant.

Power BI Premium

Ce scénario utilise espaces de travail Power BI Premium avec des améliorations de performances intégrées pour répondre aux besoins analytiques exigeants.

Pour plus d’informations, consultez tarification de Power BI.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

  • Utilisez un pipeline de mise en production Azure DevOps et GitHub Actions pour automatiser le déploiement d’un espace de travail Azure Synapse Analytics dans plusieurs environnements. Pour plus d’informations, consultez intégration continue et livraison continue pour un espace de travail Azure Synapse Analytics.

  • Placez chaque charge de travail dans un modèle de déploiement distinct et stockez les ressources dans les systèmes de contrôle de code source. Vous pouvez déployer les modèles ensemble ou individuellement dans le cadre d’un processus d’intégration continue et de livraison continue (CI/CD). Cette approche simplifie le processus d’automatisation. Cette architecture comporte quatre charges de travail principales :

    • Serveur d’entrepôt de données et ressources associées
    • Pipelines Azure Synapse Analytics
    • Ressources Power BI, notamment des tableaux de bord, des applications et des jeux de données
    • Scénario simulé de site local vers le cloud

  • Envisagez la préproduction de vos charges de travail dans la mesure du possible. Déployez votre charge de travail à différentes étapes. Exécutez des vérifications de validation à chaque étape avant de passer à la phase suivante. Cette approche envoie des mises à jour à vos environnements de production de manière contrôlée et réduit les problèmes de déploiement imprévus. Utilisez déploiement bleu-vert et stratégies de mise à jour des de mise à jour des environnements de production en direct.

  • Utilisez une stratégie de restauration pour gérer les déploiements ayant échoué. Par exemple, vous pouvez automatiquement relancer un déploiement antérieur réussi à partir de votre historique de déploiement. Utilisez l’indicateur --rollback-on-error dans Azure CLI.

  • Utilisez azure Monitor pour analyser les performances de votre entrepôt de données et la plateforme d’analytique Azure entière pour une expérience de supervision intégrée. Azure Synapse Analytics fournit une expérience de supervision sur le portail Azure pour présenter des insights à la charge de travail de votre entrepôt de données. Utilisez le portail Azure pour surveiller votre entrepôt de données. Il fournit des périodes de rétention configurables, des alertes, des recommandations et des graphiques personnalisables et des tableaux de bord pour les métriques et les journaux.

Pour plus d’informations, consultez les ressources suivantes :

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’efficacité des performances.

Cette section fournit des détails sur les décisions de dimensionnement pour prendre en charge ce jeu de données.

Pool provisionné Azure Synapse Analytics

Vous pouvez utiliser différentes configurations d’entrepôt de données .

DWU Nombre de nœuds de calcul Nombre de distributions par nœud
DW100c 1 60
-- TO --
DW30000c 60 1

Pour voir les avantages du scale-out des performances, en particulier pour les DWU plus volumineuses, utilisez au moins un jeu de données de 1 To. Pour trouver le meilleur nombre de DWU pour votre pool SQL dédié, essayez de monter en puissance et de descendre en puissance. Exécutez des requêtes qui ont différents nombres de DWU après avoir chargé vos données. La mise à l’échelle est rapide, ce qui vous permet d’expérimenter facilement différents niveaux de performances.

Trouver le meilleur nombre de DWU

Pour un pool SQL dédié au développement, sélectionnez un petit nombre de DWU comme point de départ, par exemple DW400c ou DW200c. Surveillez les performances de votre application pour chaque nombre de DWU. Supposons une échelle linéaire et déterminez la quantité dont vous avez besoin pour augmenter ou diminuer les DWU. Continuez à effectuer des ajustements jusqu’à ce que vous atteigniez le niveau de performances requis par vos activités.

Mettre à l’échelle un pool SQL Azure Synapse Analytics

Pour obtenir des fonctionnalités d’optimisation des performances et de scalabilité des pipelines dans Azure Synapse Analytics et de l’activité de copie que vous utilisez, consultez guide de performances et d’extensibilité de l’activité de copie.

Pour plus d’informations, consultez les ressources suivantes :

Power BI Premium et Fabric

Cet article utilise la capacité Power BI Premium F64 pour illustrer les fonctionnalités bi. Les capacités Power BI dédiées dans Fabric vont de F64 (8 vCores) à F1024 (128 vCores).

Pour déterminer la capacité dont vous avez besoin :

  • Évaluer la de charge sur votre capacité.
  • Installez l’application de métriques de capacité Fabric pour une surveillance continue.
  • Envisagez d’utiliser des techniques d’optimisation de capacité liées à la charge de travail.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes