Planification de l’implémentation de Power BI : déployer du contenu

Cet article vous aide à déployer du contenu dans le cadre de la gestion de cycle de vie du contenu. Il est principalement destiné à :

• Administrateurs Fabric : administrateurs chargés de superviser Fabric dans l’organisation. Les administrateurs Fabric pourraient avoir besoin de collaborer avec d’autres administrateurs, tels que ceux qui supervisent Microsoft 365 ou Azure DevOps.
• Centre d’excellence (COE) et équipes BI : les équipes qui sont également responsables de la supervision de Power BI au sein de l’organisation. Ces équipes comprennent des décideurs qui déterminent la manière de gérer le cycle de vie du contenu Power BI. Ces équipes peuvent également inclure des gestionnaires de mise en production qui gèrent le cycle de vie des versions du contenu et des ingénieurs qui créent et gèrent les composants nécessaires pour utiliser et prendre en charge efficacement la gestion de cycle de vie.
• Créateurs de contenu et propriétaires de contenu : les utilisateurs qui créent du contenu qu’ils souhaitent publier sur le portail Fabric afin de le partager avec d’autres personnes. Ces personnes sont responsables de la gestion de cycle de vie du contenu Power BI qu’elles créent.

La gestion de cycle de vie est constituée de l’ensemble des processus et des pratiques que vous utilisez pour gérer le contenu depuis sa création jusqu’à sa mise hors service. À la troisième étape de la gestion du cycle de vie, vous validez les modifications de contenu, ce qui implique une validation effectuée à la fois par les créateurs de contenu et les utilisateurs. Dans la quatrième étape, vous déployez du contenu pour que les consommateurs l’utilisent.

Pour partager du contenu Power BI avec des consommateurs, vous devez d’abord publier (ou déployer) le contenu dans un espace de travail Fabric. Le déploiement de contenu implique également le déplacement de ce contenu entre les environnements, comme le déploiement d'un espace de travail de développement vers un espace de travail de test, ou d'un espace de travail de test vers un espace de travail de production.

L’image suivante illustre le cycle de vie du contenu Power BI et met en évidence la quatrième phase au cours de laquelle vous déployez le contenu.

Vous déployez du contenu à deux moments clés pendant le cycle de vie du contenu :

• Lorsque vous publiez du contenu dans un espace de travail de développement. À ce stade, vous publiez du contenu pour valider vos modifications.
• Lorsque vous promouvez du contenu entre deux espaces de travail (par exemple, la promotion du contenu d’un espace de travail de développement vers un espace de travail de test). À ce stade, vous déployez du contenu lorsqu’il est prêt pour la phase suivante (par exemple, lorsque le nouveau contenu est prêt à être testé).

Les sections suivantes décrivent les approches que vous pouvez adopter pour publier ou promouvoir du contenu.

Décider de la façon dont vous allez publier du contenu

Lorsque vous développez du contenu sur votre ordinateur local, vous devez publier ce contenu dans un espace de travail de développement dans le portail Fabric. Vous publiez généralement ce contenu lorsque vous souhaitez effectuer une validation des modifications que vous avez apportées.

Les sections suivantes décrivent les approches que vous pouvez adopter pour publier ou promouvoir du contenu.

Publier avec Power BI Desktop

Power BI Desktop permet aux utilisateurs de publier des modèles sémantiques et des rapports de leur ordinateur local vers un espace de travail dans le portail Fabric. Cette approche est la façon la plus simple de publier du contenu. Toutefois, elle ne peut pas être automatisée.

Envisagez d’utiliser cette approche dans les cas suivants :

• Les créateurs de contenu préfèrent contrôler manuellement la publication de contenu sur le portail Fabric.
• Les créateurs de contenu utilisent Power BI Desktop pour développer et gérer du contenu.
• Les créateurs de contenu ne connaissent pas Azure DevOps ou Git.
• Le contenu comprend uniquement des modèles sémantiques ou des rapports.

Publier avec des outils tiers

Les outils tiers permettent aux créateurs de contenu de publier un modèle sémantique en utilisant le point de terminaison lecture/écriture XMLA de l’espace de travail. Par exemple, un créateur de contenu utilise l’éditeur tabulaire pour développer et gérer des métadonnées du modèle, telles que le TMDL (langage de définition de modèle tabulaire) ou les fichiers .bim.

Envisagez d’utiliser cette approche dans les cas suivants :

• Les créateurs de contenu préfèrent contrôler manuellement la publication de contenu sur le portail Fabric.
• Les créateurs de contenu utilisent un outil tiers pour développer et gérer le contenu.
• Le contenu sera publié dans un espace de travail qui utilise le mode de licence Premium par utilisateur (PPU), la capacité Premium ou la capacité Fabric.
• Les créateurs de contenu ne connaissent pas Azure DevOps ou Git.
• Le contenu comprend uniquement des modèles sémantiques.

Publier avec l’actualisation de OneDrive

OneDrive permet aux créateurs de contenu en libre-service de publier automatiquement des modèles sémantiques ou des rapports dans un espace de travail du portail Fabric à l’aide de l’actualisation de OneDrive. Les créateurs de contenu peuvent enregistrer des fichiers Power BI Desktop (.pbix) dans une bibliothèque partagée dans OneDrive. La bibliothèque partagée peut également être une bibliothèque de documents SharePoint ou Microsoft Teams.

Envisagez d’utiliser cette approche dans les cas suivants :

• Les créateurs de contenu souhaitent automatiser la publication de contenu sur le portail Fabric.
• Les créateurs de contenu ne connaissent pas Azure DevOps ou Git.
• Les créateurs de contenu effectuent le contrôle de version du contenu à l’aide de OneDrive ou SharePoint.
• Les créateurs de contenu enregistrent des modèles sémantiques et des rapports sous forme de fichiers .pbix.
• Le contenu comprend uniquement des modèles sémantiques ou des rapports.

Publier avec l’intégration de Fabric Git

L’intégration Git de Fabric est une fonctionnalité exclusive aux capacités Fabric qui permet aux créateurs de contenu de synchroniser une branche à partir d’un référentiel Git distant vers un espace de travail Fabric. Vous pouvez utiliser l’intégration Git avec Azure DevOps pour synchroniser du contenu à partir d’Azure Repos ou déployer du contenu à l’aide d’Azure Pipelines (décrit dans la section suivante).

Pour résumer, le contenu validé et envoyé vers le référentiel distant est automatiquement publié dans l’espace de travail via ce processus de synchronisation. L’un des principaux avantages de cette approche est qu’elle vous permet de coupler vos processus de gestion du contrôle de code source avec la publication de contenu. Par exemple, elle permet une restauration plus facile des modifications ou des versions entières d’une solution.

Envisagez d’utiliser cette approche dans les cas suivants :

• Les créateurs de contenu connaissent Azure DevOps et Git.
• Les créateurs de contenu utilisent Azure DevOps pour la collaboration et le contrôle de code source.
• Les créateurs de contenu enregistrent des modèles sémantiques et des rapports en tant que fichiers projet Power BI (.pbip).
• Le contenu sera publié dans un espace de travail sur une capacité Fabric.
• Le contenu est composé des types d’éléments pris en charge par la fonctionnalité d’intégration Git.
• Le contenu n’a pas d’étiquettes de confidentialité.

Publier avec Azure Pipelines

Azure Pipelines automatise par programmation le test, la gestion et le déploiement du contenu. Lorsqu’un pipeline est exécuté, les étapes du pipeline s’exécutent automatiquement. Azure Pipelines est plus complexe et nécessite plus de temps et d’efforts pour la configuration par rapport à d’autres approches, mais il permet le plus de contrôle et de flexibilité pour orchestrer le processus de déploiement.

Envisagez d’utiliser Azure Pipelines pour orchestrer le déploiement de contenu dans les cas suivants :

• Les créateurs de contenu connaissent Azure DevOps et les API REST Fabric.
• Les créateurs de contenu utilisent Azure DevOps pour la collaboration et le contrôle de code source.
• Les créateurs de contenu n’utilisent pas l’intégration Git Fabric.

Azure Pipelines et d’autres outils basés sur le code peuvent déployer du contenu de manière programmatique en utilisant un ou plusieurs des API ou points de terminaison suivants :

• Les API REST Power BI : il existe différents points de terminaison d’API REST Power BI que vous pouvez utiliser pour déployer du contenu. Les API REST Power BI prennent uniquement en charge les types d’éléments Power BI.
  • Importer : vous pouvez publier des éléments pris en charge à l’aide des API REST Power BI pour importer un fichier source valide dans un espace de travail (tel qu’un fichier .pbix).
  • Déployer : vous pouvez déployer des éléments pris en charge, en les promouvant d'un espace de travail à un autre s'ils sont des étapes dans un pipeline de déploiement.
• Les API REST Fabric : il existe différents points de terminaison d’API REST Fabric que vous pouvez utiliser pour déployer du contenu. Les API REST Fabric prennent en charge les types d’éléments Power BI et Fabric.
  • Créer : vous pouvez créer des éléments pris en charge à l’aide des API REST Fabric avec une définition d’élément valide.
  • Mise à jour depuis Git : vous pouvez mettre à jour un espace de travail avec du contenu à partir d’un référentiel distant connecté à l’aide de l’intégration Git.
• Points de terminaison de lecture/écriture XMLA : vous pouvez créer ou modifier des modèles sémantiques à l’aide de points de terminaison XMLA avec un fichier model.bim valide. Les points de terminaison XMLA vous permettent de déployer des modifications sur des objets de modèle spécifiques au lieu de l’ensemble du modèle. Azure Pipelines peut utiliser des outils tiers (comme l’interface de ligne de commande de l’éditeur tabulaire) pour déployer des modèles sémantiques à l’aide des points de terminaison XMLA.

En plus des tests automatisés, l’intégration d’Azure Pipelines à Power BI vous aide à atteindre l’intégration continue et le déploiement continu (CI/CD).

Lors de l’utilisation d’Azure Pipelines, les propriétaires de pipelines peuvent personnaliser les déclencheurs, les étapes et les fonctionnalités pour répondre aux besoins de déploiement. Par conséquent, le nombre et les types de pipelines varient en fonction des exigences de la solution.

Il existe trois types d’Azure Pipelines que vous pouvez configurer pour tester, gérer et déployer votre solution Power BI.

• Pipelines de validation
• Pipelines de build
• Pipelines de mise en production

Pipelines de validation

Les pipelines de validation effectuent des vérifications de qualité de base des modèles de données avant leur publication dans un espace de travail de développement. En règle générale, les modifications d’une branche du référentiel distant déclenchent la validation par le pipeline de ces modifications à l’aide de tests automatisés.

Parmi les exemples de tests automatisés, citons l’analyse du modèle de données à la recherche de violations de règles de meilleures pratiques à l’aide de Best Practice Analyzer (BPA) ou l’exécution de requêtes DAX sur un modèle sémantique publié. Les résultats de ces tests sont ensuite stockés dans le référentiel distant à des fins de documentation et d’audit. Les modèles de données qui échouent à la validation ne doivent pas être publiés. Au lieu de cela, le pipeline doit informer les créateurs de contenu des problèmes.

Pipelines de build

Les pipelines de build préparent les modèles de données pour la publication sur le service Power BI. Ces pipelines combinent les métadonnées de modèle sérialisées dans un fichier unique publié ultérieurement par un pipeline de mise en production. Un pipeline de build peut également apporter des modifications aux métadonnées, comme la modification des valeurs de paramètres. Les pipelines de build produisent des artefacts de déploiement qui se composent de métadonnées de modèle de données (pour les modèles de données) et de fichiers de projet Power BI (.pbip) prêts à être publiés dans le service Power BI.

Pipelines de mise en production

Les pipelines de mise en production publient ou déploient du contenu. Une solution de publication comprend généralement plusieurs pipelines de mise en production, en fonction de l’environnement cible.

• Pipeline de mise en production de développement : ce premier pipeline est déclenché automatiquement. Il publie le contenu dans un espace de travail de développement une fois les pipelines de build et de validation réussis.
• Pipelines de mise en production et de test : ces pipelines ne sont pas déclenchés automatiquement. Au lieu de cela, ils sont déclenchés à la demande ou lorsqu’ils sont approuvés. Les pipelines de mise en production et de test déploient le contenu dans un espace de travail de test ou de production, respectivement, après approbation de la mise en production. Les approbations de mise en production garantissent que le contenu n’est pas déployé automatiquement dans une phase de test ou de production avant d’être prêt. Ces approbations sont fournies par les gestionnaires de mise en production, qui sont responsables de la planification et de la coordination de la publication de contenu dans les environnements de test et de production.

Déterminer la façon dont vous allez promouvoir le contenu entre les espaces de travail

Lorsque vous utilisez différents environnements pour le développement, le test et la production, vous devez déployer du contenu dans les trois environnements. Il existe différents outils et approches que vous pouvez adopter pour promouvoir le contenu entre les espaces de travail, en fonction de votre flux de travail et de vos besoins spécifiques.

Les sections suivantes décrivent les approches que vous pouvez adopter pour promouvoir le contenu entre les espaces de travail.

Déployer avec des pipelines de déploiement Fabric

Les pipelines de déploiement vous permettent de configurer deux étapes ou plus (telles que le développement, le test ou la production) et de déployer du contenu Fabric entre ces étapes. Un administrateur de pipeline affecte un seul espace de travail Power BI unique à chaque étape du pipeline de déploiement. La façon dont vous utilisez des pipelines de déploiement dépend de la façon dont vous avez décidé de configurer et d’utiliser des espaces de travail.

Envisagez d’utiliser des pipelines de déploiement dans les cas suivants :

• Le contenu est déployé vers des espaces de travail avec un mode de licence de capacité PPU, Premium ou Fabric.
• Les types et scénarios d’éléments de contenu sont pris en charge par les pipelines de déploiement.

Envisagez une autre approche que les pipelines de déploiement dans les cas suivants :

• Vous préférez déployer du contenu à partir d’un référentiel distant, par exemple à l’aide d’Azure Pipelines.
• Vous envisagez d’utiliser l’intégration Git pour synchroniser différentes étapes avec différentes branches de votre référentiel distant, au lieu de déployer le contenu.

La façon la plus simple d’utiliser un pipeline de déploiement consiste à publier tout le contenu dans un seul espace de travail et à le promouvoir vers des étapes ultérieures au sein d’un seul pipeline de déploiement. Le diagramme suivant illustre cette première approche pour déployer du contenu à l’aide d’un pipeline de déploiement.

En résumé, un créateur de contenu publie généralement du contenu à l’étape initiale du pipeline. Ensuite, pour promouvoir le contenu aux étapes ultérieures, un administrateur de pipeline déclenche un déploiement. Lorsqu’un déploiement se produit, le pipeline de déploiement déploie les métadonnées de contenu d’un espace de travail à l’autre.

Lorsque vous séparez le contenu par type d’élément dans différents espaces de travail, vous allez utiliser des pipelines de déploiement distincts pour déployer ce contenu. Vous pouvez lier du contenu entre des espaces de travail avec plusieurs pipelines de déploiement en utilisant la liaison automatique. La liaison automatique entre les pipelines de déploiement garantit que le contenu reste lié à l’élément approprié à l’étape correspondante. Par exemple, le rapport de l’étape de développement reste lié au modèle à l’étape de développement de l’autre pipeline de déploiement. Toutefois, vous pouvez également éviter le comportement de liaison automatique si votre scénario nécessite de lier du contenu entre les espaces de travail avec un modèle différent.

Le diagramme suivant illustre cette deuxième approche pour déployer du contenu à l’aide de plusieurs pipelines de déploiement.

En résumé, le déploiement de contenu à l’aide de plusieurs pipelines de déploiement est similaire à l’utilisation d’un seul pipeline. Une différence clé est que vous pouvez éventuellement lier du contenu connecté entre les espaces de travail et les pipelines de déploiement à l’aide de la liaison automatique. Sinon, elle est identique à la première approche.

Les pipelines de déploiement sont un outil flexible et simple qui permet d’améliorer la gestion du cycle de vie du contenu pour les scénarios en libre-service et d’entreprise.

L’accès à l’espace de travail et au pipeline de déploiement est nécessaire pour les utilisateurs effectuant un déploiement. Nous vous recommandons de planifier l’accès au pipeline de déploiement afin que les administrateurs de pipeline puissent afficher l’historique du déploiement et comparer le contenu. Lorsque vous collaborez avec plusieurs créateurs de contenu, envisagez de restreindre l’accès au pipeline aux responsables de mise en production ou aux propriétaires techniques les mieux adaptés pour superviser les processus de déploiement et de mise en production.

En outre, envisagez d’utiliser des règles de déploiement afin de définir différentes configurations pour les éléments de différentes phases. Par exemple, vous souhaiterez peut-être qu’un modèle sémantique dans l’espace de travail de développement récupère des données à partir de la base de données de développement, tandis que le modèle sémantique dans l'espace de travail de production récupère des données à partir de la base de données de production.

Vous pouvez déclencher des déploiements manuellement ou par programmation à l’aide des API REST Power BI. Dans les deux cas, vous devriez définir un processus clair et robuste sur le moment où vous promouvez le contenu à chaque étape et la façon de restaurer des modifications involontaires.

Effectuer manuellement un déploiement

Vous pouvez déployer du contenu manuellement à l’aide du pipeline de déploiement Fabric. Vous pouvez choisir de déployer tout le contenu ou de sélectionner des éléments. Le déploiement sélectif peut être bénéfique lorsque du contenu est prêt à passer à l’étape suivante, mais que certains éléments sont toujours en cours de développement ou de validation. En outre, vous pouvez effectuer un déploiement descendant lorsque des modifications de contenu existent dans une étape ultérieure, mais pas dans une étape antérieure.

Lorsque vous effectuez un déploiement manuel, vous pouvez comparer les étapes pour identifier les modifications de contenu dans la fenêtre révision des modifications. Cette approche est particulièrement utile lorsque vous n’utilisez pas de référentiel distant Git pour le contrôle de code source.

Utiliser les API REST Power BI pour effectuer un déploiement

Vous pouvez utiliser les API REST Power BI pour déployer du contenu à l’aide d’un pipeline de déploiement. L’utilisation des API REST offre un avantage : vous pouvez automatiser le déploiement et l’intégrer à d’autres outils, comme Azure Pipelines dans Azure DevOps.

Déployer avec Azure Pipelines

Azure Pipelines vous permet d’orchestrer le déploiement entre toutes les étapes. Avec cette approche, vous utilisez les API REST Fabric pour déployer et gérer du contenu, en utilisant différents pipelines Azure, tels que la validation et les pipelines de mise en production.

Envisagez d’utiliser Azure Pipelines dans les cas suivants :

• Vous souhaitez centraliser l’orchestration du déploiement à partir d’Azure DevOps.
• Les créateurs de contenu utilisent Azure DevOps pour collaborer et pour le contrôle de code source.

Envisagez une autre approche que Azure Pipelines dans les cas suivants :

• Les créateurs de contenu ne connaissent pas Azure DevOps ou les déploiements basés sur du code.
• Le contenu inclut des types d’éléments qui n’ont pas de définition ou de format de fichier source pris en charge, comme les tableaux de bord.

Il existe deux approches différentes pour déployer du contenu avec Azure Pipelines. Soit elles orchestrent des pipelines de déploiement, soit elles déploient du contenu dans un espace de travail sans pipeline de déploiement.

Orchestrer des pipelines de déploiement Fabric à l’aide d’Azure Pipelines

Dans cette approche, les pipelines de mise en production orchestrent le déploiement de contenu sur les espaces de travail de test et de production à l’aide de pipelines de déploiement. Le contenu est promu via des espaces de travail de développement, de test et de production dans Fabric.

Le diagramme suivant montre comment orchestrer des pipelines de déploiement à partir d’Azure Pipelines.

En résumé, les créateurs de contenu publient du contenu dans l’espace de travail dans la première étape du pipeline de déploiement. Ensuite, un gestionnaire de versions approuve le déploiement, ce qui déclenche un pipeline Azure. Ce pipeline utilise les API REST Power BI pour promouvoir du contenu entre les étapes, afin que les métadonnées soient déployées sur un autre espace de travail. L’un des avantages de cette approche est que vous pouvez orchestrer le déploiement de plusieurs types d’éléments Fabric via des pipelines de déploiement, car certains types d’éléments sont développés dans le portail Fabric et ne peuvent donc pas être déployés uniquement par Azure Pipelines.

Déployer du contenu en utilisant uniquement Azure Pipelines

Vous pouvez également déployer du contenu dans un espace de travail à partir d’Azure DevOps à l’aide d’Azure Pipelines. Cette approche n’utilise pas de pipelines de déploiement. Au lieu de cela, elle utilise des pipelines de mise en production pour déployer des fichiers sources ou des fichiers de métadonnées à l’aide des API REST Fabric ou Power BI, ou des points de terminaison XMLA en lecture/écriture. En règle générale, ces fichiers sont stockés dans un dépôt Git Azure Repos.

Le diagramme suivant illustre la façon dont vous déployez du contenu en utilisant uniquement Azure Pipelines.

En résumé, les créateurs de contenu valident et envoient les modifications de contenu vers un référentiel Git distant dans Azure Repos. Ce contenu est utilisé par Azure Pipelines pour le déploiement. Une fois que le gestionnaire de versions approuve le déploiement spécifique, Azure Pipelines déploie du contenu dans l’espace de travail, soit à l’aide des API REST Power BI (autrement dit, pour les fichiers .pbix), des API REST Fabric (autrement dit, pour les définitions d’éléments) ou des points de terminaison XMLA (c’est-à-dire pour les fichiers model.bim). Un pipeline Azure distinct existe pour chaque espace de travail.

Cette approche ne nécessite pas de licences Fabric ou Premium lorsque vous publiez uniquement des fichiers Power BI Desktop avec les API REST Power BI. Toutefois, cela implique davantage d’efforts et de complexité de configuration, car vous devez gérer le déploiement en dehors de Power BI. Les équipes de développement qui utilisent déjà DevOps pour des solutions de données en dehors de Power BI connaîtront sans doute cette approche. Les équipes de développement qui utilisent cette approche peuvent consolider le déploiement de solutions de données dans Azure DevOps.

Déployer avec l’intégration de Fabric Git

Lorsque vous utilisez l’intégration Git, vous pouvez synchroniser différentes branches vers différents espaces de travail au lieu de publier ou de déployer du contenu, explicitement. De cette façon, vous pouvez avoir des branches distinctes pour les espaces de travail de développement, de test et de production. Dans ce scénario, la branche principale se synchronise avec l’espace de travail de production. Vous déployez ensuite du contenu entre les espaces de travail en effectuant une demande de tirage pour fusionner la branche de développement dans la branche de test (pour effectuer le déploiement sur l’espace de travail de test) ou pour fusionner la branche de test dans la branche principale (pour effectuer le déploiement dans l’espace de travail de production).

Le diagramme suivant illustre la façon dont vous déployez du contenu à l’aide de l’intégration Git Fabric pour synchroniser des branches vers différents espaces de travail. Par souci de simplicité, le diagramme n’inclut pas les détails de la branchement ou de la fusion du contenu.

En résumé, les créateurs de contenu valident et envoient les modifications de contenu vers un référentiel Git distant dans Azure Repos. Les créateurs de contenu ouvrent des demandes de tirage (pull request – PR) pour demander à fusionner leurs modifications dans une branche spécifique. Selon la stratégie de branchement, différentes branches sont connectées à différents espaces de travail. Une fois les modifications fusionnées dans une branche, les créateurs de contenu synchronisent l’espace de travail avec le référentiel Git distant pour afficher les dernières modifications apportées au contenu de cet espace de travail.

Tenez compte de cette approche dans les cas suivants :

• Vous souhaitez orchestrer le déploiement entre les espaces de travail à l’aide de votre stratégie de branchement et de fusion.
• Vous n’avez pas l’intention d’utiliser des pipelines de déploiement Azure Pipelines ou Fabric afin d’orchestrer les déploiements pour tester et produire.
• L’espace de travail ne contient pas d’éléments non pris en charge ni de scénarios.
• Le contenu n’a pas d’étiquettes de confidentialité.

Décider comment gérer les activités post-déploiement

Après le déploiement, il existe différentes activités de post-déploiement qui doivent être gérées. La plupart de ces activités peuvent être gérées par programmation, par exemple par un pipeline Azure ou un notebook, et les API REST Power BI et Fabric. Par exemple, vous pouvez définir par programme les informations d’identification de la source de données, gérer l’actualisation planifiée et déclencher des actualisations après un déploiement de métadonnées. Toutefois, certaines tâches nécessitent une intervention manuelle, telle qu’une configuration initiale ou la mise à jour d’une application Power BI.

Vérifiez que vous identifiez toutes les activités post-déploiement pertinentes pour votre contenu et que vous décidez de la façon dont elles seront gérées.

Une fois que vous avez planifié la façon dont vous allez déployer du contenu, vous devez ensuite prendre en compte la façon dont vous allez le prendre en charge et le surveiller.

Liste de contrôle : lors de la planification du déploiement du contenu, les décisions clés et les actions incluent :

Contenu connexe

Dans le prochain article de cette série, découvrez comment planifier et concevoir du contenu dans le cadre de la gestion de cycle de vie du contenu.