Read this guide in

Guide pour la migration de Tableau Server à Tableau Cloud Migration

Points clés à retenir

Plus de 90% des nouveaux clients Tableau choisissent désormais Tableau Cloud, portés par l’innovation, le ROI, la sécurité et la scalabilité.
Une migration réussie se déroule en trois phases : Préparation, Exécution et Validation & Monitoring.
Les environnements de petite taille (moins de 20 classeurs) peuvent être migrés manuellement ; les environnements plus importants doivent s’appuyer sur le Content Migration Tool (CMT), le Migration SDK ou la Migration App de Tableau.
Les plannings de rafraichissement , les permissions et les abonnements ne sont pas transférés automatiquement : ils doivent être recréés dans Tableau Cloud.
Les tests constituent le facteur de réussite le plus critique : les tests de régression, de performance, fonctionnels et de qualité des données doivent avoir lieu avant la mise en production, et se poursuivre après.
Après la migration, un monitoring continu est indispensable, car Tableau Cloud applique des mises à jour automatiquement, ce qui peut introduire des régressions sans préavis.

Pourquoi les organisations migrent-elles vers Tableau Cloud ?

Tableau Server était autrefois le déploiement par défaut, mais la tendance s’est inversée : aujourd’hui, plus de 90 % des nouveaux clients Tableau choisissent Tableau Cloud, et une part croissante des clients Server existants migrent également. Selon Scott Smith, Senior Product Manager chez Salesforce, cette décision s’appuie généralement sur quatre grands leviers.

Innovation

Tableau Cloud fonctionne toujours sur la dernière version disponible : les nouvelles fonctionnalités, y compris les capacités d’IA de Tableau comme Tableau Pulse et Tableau Agent, sont accessibles à vos équipes dès leur sortie, sans aucun projet de mise à niveau à mener.

Un ROI plus élevé

Passer à l’analytique en tant que service supprime la charge liée à l’hébergement et aux coûts matériels. Les organisations constatent également des gains de productivité grâce à des outils comme Tableau Pulse, qui augmente le volume de décisions pilotées par la donnée et la valeur globale tirée des investissements analytiques.

Sécurité

Tableau Cloud hérite de la posture de confiance de Salesforce et de son équipe de sécurité unifiée, ainsi que de certifications de conformité comme SOC 2 et HIPAA, disponibles pour chaque client simplement en utilisant la plateforme, sans configuration supplémentaire.

Scalabilité

Tableau Cloud s’appuie sur des pods répartis mondialement, garantissant performance et résilience quel que soit l’emplacement des utilisateurs. Plutôt que de mener des cycles de planification de capacité IT pour du nouveau matériel, les organisations peuvent simplement ajouter des utilisateurs et les rendre opérationnels le jour même.

Les trois phases d’une migration vers Tableau Cloud

Une migration réussie se décompose en trois phases : la Préparation (planification et mise en état de préparation), l’Exécution (la migration technique proprement dite) et la Validation & Monitoring (confirmer que tout fonctionne, et que cela continue de fonctionner). Voici le détail des huit étapes du processus.

Phase 1 : Préparation

Étape 1 : Planifier votre migration

Avant de toucher à Tableau Cloud, passez en revue cette checklist de pré-migration :

Type de migration : décidez entre un « lift & shift » complet ou une migration partielle. Dans les deux cas, vous basculerez probablement vers une version plus récente de Tableau au passage.
Multi-environnements ou site unique : Tableau Cloud propose un site unique, à la différence des multiples environnements Dev/Test/Prod de Server. La plupart des organisations recréent cette structure à l’aide de dossiers de projets (le multi-site est aussi possible, mais nécessite une discussion de licence avec Salesforce).
Sources de données : recensez chaque base de données, application et source de fichiers, et vérifiez lesquelles sont prises en charge par Tableau Cloud. Les sources on-premise nécessitent Tableau Bridge ; les sources cloud peuvent souvent se connecter directement une fois autorisées. Vérifiez également combien de classeurs utilisent des sources de données intégrées (plutôt que publiées).
Authentification : choisissez entre le TableauID natif (avec MFA) ou votre fournisseur d’identité existant ; l’intégration IdP est requise quelle que soit la méthode SAML (Okta, Salesforce, Google, etc.).
Extensions Server : recensez toutes les extensions Tableau Server utilisées et vérifiez qu’elles sont prises en charge sur Tableau Cloud.
Nettoyage du contenu : utilisez la vue « Stale Content » de Tableau Server pour identifier les classeurs, sources de données et flows inutilisés avant la migration ; le stockage cloud n’est pas gratuit, et le contenu inutilisé depuis plus de 13 mois peut généralement être laissé de côté.
Calendrier : il s’agit généralement d’un projet piloté par l’IT, et non par le métier. Alignez-vous avec les parties prenantes métier sur un calendrier qui minimise les perturbations.
Sauvegarde : effectuez une sauvegarde complète du contenu de votre Tableau Server comme filet de sécurité avant de décommissionner quoi que ce soit.

Étape 2 : Identifier le contenu et ses éléments à tester

Avant de migrer, cartographiez ce qui devra être testé après coup, en collaboration avec les utilisateurs, les développeurs et les testeurs à travers l’entreprise :

Reporting institutionnel : les rapports critiques utilisés au quotidien pour les opérations.
Reporting en libre-service : les tableaux de bord créés par les utilisateurs et fréquemment utilisés pour l’analyse.
Contenu analytique embarqué : les tableaux de bord Tableau intégrés dans d’autres applications ou portails destinés aux clients.

Les Admin Views de Tableau Server peuvent être utiles ici, en révélant des métadonnées d’usage comme la date de dernier accès et le nombre de vues. Pour une vision plus complète, certaines organisations combinent l’API Data Extract de Tableau avec d’autres données (comme les logs d’accès) pour construire des vues d’usage personnalisées.

Une fois la migration effectuée, prévoyez de tester ces éléments précis pour chaque tableau de bord :

Les visualisations (les graphiques s’affichent correctement, sans changement de mise en forme non désiré)
La représentation des données (les données affichées correspondent à la source sous-jacente)
La structure des feuilles de calcul (rien n’a bougé au point d’affecter la vue du tableau de bord)
Les fonctionnalités (les interactions fonctionnent comme attendu)
Les valeurs de filtres et de paramètres (rien n’a été modifié pendant la migration)
La performance (temps de chargement dans des scénarios réalistes)

Étape 3 : Créer et configurer un site Tableau Cloud

La création du site est prise en charge par Tableau. À partir de là, vous configurerez l’authentification, Bridge, les extensions, les intégrations, les connected apps et l’accès mobile, autant d’éléments bien documentés directement sur le site de Tableau.

Phase 2 : Exécution

Étape 4 : Migrer les sources de données et les classeurs vers Tableau Cloud

Avant de migrer, assurez-vous que Tableau Bridge est configuré pour les sources de données locales (les sources cloud peuvent se connecter directement). Notez que les sources de données gérées par Bridge doivent être publiées séparément, elles ne peuvent pas être intégrées dans des classeurs et ne s’actualiseront pas automatiquement via Bridge.

Il existe deux façons de déplacer le contenu, selon la taille de l’environnement :

Migration manuelle pour les petits environnements (moins de 20 classeurs), téléchargez chaque classeur depuis Tableau Server et importez-le individuellement dans Tableau Cloud.
Content Migration Tool (CMT) pour les environnements plus importants. Cet outil nécessite des droits d’administration sur Server comme sur Cloud, ainsi qu’un accès aux deux environnements depuis un même poste. Le CMT déplace les sites, projets et classeurs, mais présente des limites connues concernant les utilisateurs, les groupes, les paramètres de site, les permissions, et les états verrouillés des projets, ainsi que les abonnements, et peut rencontrer des difficultés avec de très gros volumes d’objets.

Les plannings d’actualisation des extracts ne sont pas transférés de Tableau Server vers Tableau Cloud. Pendant la migration de vos projets, portez une attention particulière aux classeurs contenant des sources de données intégrées (c’est le bon moment pour les repointer vers une nouvelle source) ainsi qu’à vos sources de données publiées en général.

Étape 5 : Recréer les plannings d’actualisation dans Tableau Cloud

Les plannings d’actualisation ne se transférant pas automatiquement, vous devrez les recréer dans Tableau Cloud pour chaque source de données et chaque classeur qui en a besoin, en respectant autant que possible la fréquence, le jour et l’heure d’origine. Selon le type de source, Tableau Bridge peut être nécessaire pour maintenir des connexions en direct vers des données on-premise.

Deux points sont facilement oubliés à ce stade :

Tableau Prep Flows : vérifiez que les tâches planifiées des flows ont bien été migrées.
Abonnements aux classeurs : confirmez que les abonnements ont bien été transférés afin que les utilisateurs continuent de recevoir leurs classeurs programmés.

Étape 6 : Configurer les permissions et l’accès au contenu pour les utilisateurs migrés

Migrer les utilisateurs n’est que la moitié du travail; ils doivent aussi avoir accès au bon contenu. Si les permissions ne se sont pas transférées correctement, procédez comme suit :

Rôles prédéfinis : utilisez les rôles de site intégrés de Tableau Cloud (Viewer, Explorer, Analyst, Publisher) pour une base rapide.
Contrôle granulaire (facultatif) : définissez des permissions au niveau du projet, du classeur ou de la source de données pour un accès plus fin.
Accès aux projets : affectez les utilisateurs aux projets pertinents ; ils ne verront que le contenu des projets auxquels ils appartiennent.
Partage de contenu (facultatif) : permettez aux propriétaires de contenu de partager directement certains classeurs ou sources de données avec des utilisateurs ou des groupes.
Sécurité au niveau des lignes : revoyez et revalidez les permissions et calculs RLS après la migration.

Phase 3 : Validation & Monitoring

Étape 7 : Tester et valider votre migration

Une fois la migration terminée, la priorité passe aux tests ; il s’agit de prouver, avec des résultats documentés, que le passage a été un succès. Tableau permet généralement de faire fonctionner Server et Cloud en parallèle durant cette période, ce qui rend possible une comparaison directe.

Tests de régression côte à côte
Comparer directement le contenu Server et Cloud permet de faire ressortir :

Les différences visuelles
Les différences de données dans les feuilles de calcul
Les différences de métadonnées (types et valeurs de filtres, types et valeurs de paramètres, nombre de colonnes, etc.)
Les problèmes fonctionnels (par exemple, des tableaux de bord qui ne s’ouvrent pas)

Les résultats doivent être documentés pour justifier la fiabilité de la migration, et les tableaux de bord doivent être certifiés une fois validés, ce qui renforce la confiance et la fiabilité perçue par les parties prenantes.

Tests de performance
Une fois qu’un tableau de bord s’ouvre correctement, la performance est généralement le point suivant remarqué par les utilisateurs. Les parties prenantes métier s’attendront à ce que Tableau Cloud égale ou dépasse la vitesse de Tableau Server ; les tests de performance par rapport à des SLA définis sont donc essentiels.

Tests fonctionnels
Confirmez que les tableaux de bord et les vues s’ouvrent correctement, s’actualisent comme prévu, et que la navigation par filtres, paramètres et sélection de marques se comporte comme attendu.

Tests de qualité des données
Trois vérifications comptent le plus ici :

Comparer les données visualisées avec les tables de la base de données back-end
Valider les données agrégées et au niveau ligne par rapport aux règles métier définies
Confirmer que les utilisateurs ne voient que les données auxquelles ils sont autorisés à accéder

Certification ou décertification du contenu
Les parties prenantes métier ont besoin d’avoir confiance dans le fait que les tableaux de bord restent exacts, à jour et fiables après la migration. La certification dynamique et la décertification lorsqu’un problème survient permettent aux équipes de détecter les erreurs avant qu’elles ne soient remarquées par les parties prenantes. Deux niveaux s’appliquent généralement : la certification des sources de données pour les développeurs/Creators, et la certification des tableaux de bord pour l’ensemble des utilisateurs du contenu.

Étape 8 : Monitoring continu post-migration

Terminer la migration est une étape importante, pas une ligne d’arrivée. Tableau Cloud applique ses mises à jour automatiquement, ce qui signifie que de nouvelles fonctionnalités peuvent arriver sans préavis, parfois accompagnées de régressions non intentionnelles. Les tests continus (quotidiens, hebdomadaires, ou selon le rythme adapté à votre organisation) doivent porter sur :

L’intégrité et la fiabilité des données : confirmer que les tableaux de bord et sources de données continuent de s’alimenter correctement, y compris via des tests SQL sur des sources comme Snowflake, Databricks ou des fichiers CSV.
L’optimisation de la performance : valider le respect des SLA en conditions réelles de charge utilisateur simultanée.
La validation fonctionnelle des tableaux de bord : vérifier les filtres, paramètres et calculs personnalisés après chaque mise à jour forcée.
Les tests de régression : comparer les tableaux de bord avant et après chaque mise à jour Cloud, ces dernières étant largement hors de votre contrôle.
La conformité réglementaire : vérifier que les paramètres de sécurité et les permissions d’accès restent correctement appliqués ; l’outil Admin Insights de Tableau Cloud aide à suivre les rôles des utilisateurs et l’activité de connexion.

Les outils de migration natifs de Tableau

Tableau Migration SDK

Lancé début 2024, le Migration SDK permet aux équipes techniques d’automatiser et de personnaliser leur propre processus de migration des utilisateurs, groupes, contenus (sources de données et classeurs) et structures de gouvernance vers Tableau Cloud. Il est conçu pour des équipes à l’aise avec Python et .NET, et, comme tout chemin de migration, nécessite tout de même une validation dédiée des données post-migration, que Tableau n’automatise pas nativement à grande échelle.

Tableau Migration App

Lancée fin 2024 en réponse aux retours clients, la Migration App est un outil open source destiné aux organisations disposant d’environnements plus modestes et ne disposant pas des ressources techniques nécessaires pour utiliser le SDK directement.

Astuces pour réussir sa migration vers Tableau Cloud

Benny Benford, ancien CDO de Jaguar Land Rover, partage ces enseignements tirés du pilotage d’une migration Server vers Cloud dans un contexte réel.

Concentrez-vous sur la valeur apportée par la migration, pas seulement sur la performance. Les équipes ont souvent tendance à se focaliser sur la performance et l’usage de la plateforme. Laissez Tableau gérer la performance, et concentrez vos efforts sur la valeur que la donnée apporte à l’organisation.
Impliquez votre communauté. Profitez de la migration pour interroger les utilisateurs sur leurs points de friction. Vous ne pourrez pas tout résoudre, évitez donc de trop promettre, mais l’implication elle-même construit de la confiance.
Saisissez l’occasion de restructurer. Jaguar Land Rover a utilisé sa migration pour repenser la structure de son site et son modèle de sécurité, en s’appuyant sur des années d’expérience Tableau accumulée et les retours directs de sa communauté.
Testez, testez, testez. Migrer sans tester ne vous laisse aucun moyen de confirmer que tout fonctionne réellement comme prévu.
Faites de la communauté un acteur de la migration. Présentez les choses ainsi : « vous nous avez signalé le problème X, nous le corrigeons, mais nous avons besoin de votre aide pour le tester ». Impliquer les utilisateurs dans les tests renforce leur adhésion et fait émerger des problèmes que vous auriez sinon manqués.

Comment Wiiisdom accompagne une migration vers Tableau Cloud

Wiiisdom pour Tableau propose de la validation automatisée, de la certification et décertification, ainsi qu’un monitoring continu à grande échelle, conçus pour détecter et résoudre les problèmes avant même que les parties prenantes métier ne les remarquent. Concrètement, cela signifie :

Définir des stratégies de test : planifier la complexité et la cadence des tests (horaire, quotidienne, hebdomadaire, mensuelle).
Des tests continus : combiner tests automatisés, monitoring et intégration CI/CD pour des cycles de développement plus rapides et une détection plus précoce des problèmes.
Des alertes en temps réel : via email, Slack, Microsoft Teams ou intégrations par webhook, pour permettre aux équipes de résoudre les problèmes de façon proactive.
Un suivi historique : documenter les règles de test et leurs résultats dans le temps, ce qui facilite les audits et les exigences réglementaires tout en révélant les tendances de long terme.

Questions fréquentes

1. Les plannings d'actualisation de Tableau Server sont-ils transférés vers Tableau Cloud ?

Non. Les plannings d’actualisation ne migrent pas automatiquement. Chaque source de données ou classeur nécessitant une actualisation doit voir son planning recréé manuellement dans Tableau Cloud, en respectant la fréquence, le jour et l’heure d’origine.

2. Quelle est la différence entre le Content Migration Tool, le Migration SDK et la Migration App ?

Le Content Migration Tool (CMT) est conçu pour les environnements de grande taille et déplace les sites, projets et classeurs, bien qu’il présente des limites concernant les utilisateurs, les groupes et les permissions. Le Migration SDK, lancé en 2024, permet aux équipes techniques (via Python et .NET) de construire un processus de migration entièrement personnalisé. La Migration App, lancée plus tard la même année, est un outil open source destiné aux organisations plus modestes ne disposant pas des ressources techniques pour utiliser directement le SDK.

3. Comment migrer un environnement Tableau de petite taille vers Tableau Cloud ?

Pour les environnements comptant moins de 20 classeurs, la migration manuelle est généralement la plus simple : téléchargez chaque classeur depuis Tableau Server et importez-le directement dans Tableau Cloud. Les environnements plus importants doivent plutôt s’appuyer sur le Content Migration Tool, le Migration SDK ou la Migration App.

4. Que faut-il tester après une migration vers Tableau Cloud ?

Quatre types de tests comptent le plus : les tests de régression (comparaison de Server et Cloud côte à côte), les tests de performance (par rapport à des SLA définis), les tests fonctionnels (ouverture, actualisation et réponse aux filtres/paramètres des tableaux de bord) et les tests de qualité des données (validation des données par rapport à la source et aux règles d’accès).

5. Pourquoi les tests doivent-ils continuer après la fin de la migration ?

Tableau Cloud applique ses mises à jour automatiquement, et les organisations ne peuvent pas contrôler quand ces mises à jour ont lieu. Les nouvelles fonctionnalités peuvent parfois introduire des régressions ; des tests continus, portant sur l’intégrité des données, la performance, les fonctionnalités et la régression, sont donc nécessaires pour détecter les problèmes avant qu’ils n’atteignent les parties prenantes métier.

Télécharger le PDF complet