Vous êtes peut-être encore en vacances, en train de profiter de la plage, du soleil, de discrètement mater des nanas ou des nonos derrière vos lunettes de soleil (blague censurée par le comité de rédaction), de siroter une bière tout en préparant le barbecue de ce soir ou encore d’enflammer le dancefloor du camping « Chez Maurice » à Béziers… N’en demeure pas moins que la rentrée approche ! Et ce n’est pas pour faire le rabat-joie mais il va bien falloir s’y préparer !
Votre enfant vous serine déjà pour avoir la stack complète de Marvel (cartable Iron Man, trousse Captain America, stylo bille Hulk…). Car on a beau dire, la rentrée, c’est toujours un moment particulier. Un moment où on se stuff et on prend tout plein de bonnes résolutions pour bien commencer. Vous ne sentez pas comme une odeur de madeleine de Proust dans l’air ?
Si lui a le droit d’aborder cette rentrée avec engouement, pourquoi pas vous ? Après tout, vous aussi vous avez le droit de faire une belle liste de fournitures et de prendre de bonnes résolutions pour vos projets BI.
Liste des fournitures
- Un Tableau Server prêt à l’emploi (on ne revient pas sur les spécifications techniques, vous les trouverez ici)
- Des utilisateurs
- De l’huile de coude
- Un peu de temps et de motivation
Introduction
Si vous êtes ici, vous connaissez certainement déjà un peu Tableau Server et ses fonctionnalités. Vous savez qu’il s’agit de mettre des rapports et des données en libre-service sur un espace web. Qu’il y a pléthores de possibilités pour les utilisateurs (interaction, édition, administration, abonnements…) et le tout via le navigateur !
Quand on lit la liste des features, on a des étoiles dans les yeux mais il ne nous faut pas plus de quelques minutes pour redescendre sur Terre et voir émerger des dizaines de questions tournant autour de la méta-question suivante : « Comment puis-je l’organiser pour que cela réponde à MON besoin ? ». Et ce besoin, s’articule souvent autour des notions de droits d’accès au contenu et de gouvernance.
ATTENTION : Dans cet article, je ne prétends pas donner la recette miracle applicable tout le temps et partout, ce d’autant plus qu’il existe plusieurs manières d’arriver au même résultat (la meilleure façon d’y arriver dépend de vos enjeux et de vos contraintes). Je propose simplement un exemple qui a pour but d’alimenter votre réflexion sur l’organisation et l’utilisation de Tableau Server.
La structure (sit(h)es, projets, groupes, utilisateurs)
On fait tomber la, tomber la chemise capuche (vanne non approuvée par la direction) et on se lance !
La première chose à bien comprendre, c’est le découpage de Tableau Server. On retrouve en premier lieu une notion de « Sites ». Ces sites sont des espaces entièrement cloisonnés les uns des autres. Autrement dit le contenu d’un site (projets, utilisateurs, classeurs, groupes…) n’est pas visible sur un autre site. Quelque chose d’assez pratique lorsqu’il s’agit de s’assurer que nos différentes équipes (commerces, finance, contrôle de gestion…) n’aient aucun moyen de voir des choses qui ne les concernent pas.
Et là vous allez me dire (parce que je commence à vous connaitre un peu quand même), « Oui mais la direction, eux ils veulent tout pouvoir voir ». Et bien sachez qu’en tant qu’administrateur tout puissant du serveur, vous pouvez, dans votre grande magnanimité accorder à un utilisateur lambda (entendre par là non administrateur) l’accès à plusieurs sites.
Ces sites contiennent par défaut un projet intitulé « Défaut » (ils ne sont pas allés chercher bien loin pour le nommer celui-ci). Libre à vous d’en créer d’autres en fonctions de vos besoins (un pour les différentes entités d’une équipe par exemple). Ces « Projets » peuvent être perçus comme des « dossiers » dans lesquels vous (ou d’autres) pourront déposer des classeurs (contenant des vues ou TdB) et des sources de données consultables (ou non) par les différents utilisateurs du site.
Et là, je vous vois venir, alors OUI il est possible d’accorder différents droits d’accès pour ces projets.
Pour cela, il va falloir s’intéresser de plus près aux utilisateurs et aux groupes.
Les utilisateurs
Contrairement à ce qu’on peut croire, lorsque l’on nait sur Tableau Server, nous ne naissons pas tous libres et égaux en droits. Lors de l’ajout d’un utilisateur, il est possible de lui définir un « rôle », rôle qui peut être différent selon les différents sites auxquels cet utilisateur a accès.
En général, on est un peu frileux sur les droits d’accès, et beaucoup auraient tendance à doter les utilisateurs lambda d’un simple rôle d’interacteur. Personnellement, je préfère leur confier le rôle d’éditeur pour deux raisons :
- Il est possible de restreindre des droits dans des projets mais pas d’outre-passer son rôle utilisateur
- Ce serait dommage de ne pas leur laisser cette marge de manœuvre permettant d’améliorer constamment les tableaux de bord en fonction de leurs besoins immédiats
Cela permet d’enrichir l’expérience utilisateur, de stimuler une communauté active et NON, définitivement NON ce n’est pas ingouvernable (vous le verrez dans la partie « Exemple »)
Quoiqu’il en soit, un rôle n’est pas une fatalité, vous pourrez à tout moment changer le rôle d’un utilisateur.
Les groupes
La première chose que l’on a envie de faire quand on a des utilisateurs, et en particulier quand on commence à en avoir un certain nombre avec des profils d’utilisation de Tableau Server différents, c’est de les regrouper. C’est clairement plus facile pour pouvoir donner des droits d’accès différents à nos projets (on ne va quand même pas configurer les droits d’accès de 50 utilisateurs pour chaque projet). Ah, et attention, un utilisateur peut appartenir à plusieurs groupes. Prenez donc votre bâton de berger (non je ne parle pas du saucisson) et guidez vos mout…euh utilisateurs vers les groupes qui leur correspondent.
Pourquoi des utilisateurs peuvent-ils appartenir à plusieurs groupes ? Parce que ces groupes peuvent être utilisés pour définir de la sécurité à la donnée. Oui, vous avez bien entendu. Ça veut dire quoi ? Ça veut dire qu’à partir du même jeu de données et pour chacun des rapports qui s’appuient sur cette source, chaque utilisateur n’aurait accès qu’à son périmètre (utile pour les commerciaux non ?).
Et là-dessus, il y a une petite subtilité : il n’y a pas de système hiérarchique des groupes nativement dans Tableau ! Les groupes se font « à plat » et la hiérarchie, si vous en voulez une devra être logique. Autrement dit, c’est à vous de penser et de designer vos groupes pour que cette hiérarchie fonctionne.
Le « Default » de Tableau Server
Lorsque vous utilisez Tableau Server, vous vous retrouverez toujours avec un site nommé « Défaut ». Par ailleurs, chaque site contiendra un projet lui-même également nommé « Défaut ». Ce site et ces projets ne sont ni supprimables, ni re-nommables. Quand vous êtes atteints de troubles obsessionnels compulsifs comme moi, c’est excessivement énervant.
Mais heureusement, il existe une solution de recyclage !
Premièrement, le site défaut, on peut s’en servir comme un site technique et un site de tests. Du coup, on n’y donne pas accès aux utilisateurs.
Ensuite pour les projets « Défaut », on les rend invisibles auprès des utilisateurs. Seuls nous, les élus (les administrateurs), peuvent les voir. Et par conséquent, on peut s’en servir comme une zone technique où des classeurs peuvent être stockés de manière temporaire pour faire de la recette par exemple.
Exemple
Si vous lisez cette partie j’imagine que c’est très certainement pour une des raisons suivantes (n’hésitez pas à m’en faire part dans les commentaires)
- Tout ce que j’ai écrit avant c’est du charabia, vous ne voyez toujours pas comment organiser votre Tableau Server,
- Vous êtes curieux (j’en doute),
- Par défis, lorsque j’ai dit qu’on pouvait laisser les droits d’édition et que cela restait gouvernable (très probable),
- Parce que vous ne supportez pas les tâches inachevées (très probable également).
Dans cet exemple, je détaille pour une équipe et une division de cette équipe l’organisation des projets et des groupes qui peut être faite.
Je dispose donc de 4 projets, dont 3 visibles par des utilisateurs lambda.
- Un projet « Corporate » contenant les rapports et les sources de données publiés, validés, certifiés et maintenus par l’IT.
- Un projet « Custom Reports » contenant des classeurs et sources de données propres aux utilisateurs lambda et personnels. Une sorte de sandbox permettant aux différents utilisateurs de jouer, créer et d’aménager l’existant selon leurs besoins sans que ce contenu soit visible par les autres utilisateurs. Néanmoins, nous ne garantissons pas la véracité et la conformité de ce qui s’y trouve. Par ailleurs, les rapports trop anciens et non utilisés y sont supprimés régulièrement.
- Un projet « Shared » permettant à des utilisateurs avancés de partager avec d’autres divisions et/ou leurs équipes des dérivés des rapports existants ou de nouveaux rapports.
- Un projet « Default » uniquement visible par les administrateurs, utilisé à des fins techniques.
La vue côté utilisateur lambda
Notez que cet utilisateur ne voit ni le projet « Défaut », ni de classeur dans le dossier « Custom Report » puisqu’il n’en a publié aucun ici (alors qu’il en existe 7 comme on peut le voir avec le screenshot réalisé en tant qu’admin).
En termes de groupes, je dissocie plusieurs choses. Les groupes servant à définir les autorisations au niveau des projets. Ici trois groupes :
- Le groupe « Admin » qui a tous les droits possibles
- Le groupe « Sharers » qui a des droits avancés de publication dans les projets « Shared » et « Custom »
- Le groupe « Viewers » qui a des droits limités sauf pour le projet « Custom » où ils peuvent publier.
Il y a ensuite les groupes me permettant de faire de la sécurité à la donnée. Ici j’ai deux niveaux de sécurité. Un niveau à l’échelle de la région commerciale et un niveau à l’échelle de l’Etat.
Notez que je préfixe tous mes groupes pour mieux les retrouver et savoir de quoi il s’agit. Par ailleurs, je crée deux groupes « All » qui me permettront aisément de donner accès à tout le contenu aux personnes concernées (c’est plus facile à administrer que de mettre la direction dans tous les groupes en même temps). Par ailleurs, c’est utile lorsqu’il existe une hiérarchie logique dans nos niveaux de sécurité à la donnée et c’est plus simple qu’ajouter l’utilisateur à chacun des groupes.
Vision « ALL »
Permet d’ajouter un membre à tous les états ou régions.
Vision « R »
Permet d’ajouter un membre à une Région. Combiné à « ALL_State », cela permet d’ajouter l’utilisateur à tous les États de cette région.
Alors vous me direz et l’édition alors ? Le clou du spectacle, là où vous m’attendez au tournant. Et bien comme je disais dans la section « les utilisateurs », je me sers de la notion de groupe pour définir des droits d’édition différents. Si bien qu’un utilisateur lambda n’a pas accès à la fonction « enregistrer » sur un rapport du projet « Corporate ».
En revanche, il peut « Enregistrer sous » dans les projets pour lesquels il a le droit de sauvegarder ses modifications (création d’un nouveau TdB, d’une histoire…). Et devinez quoi ? Vu qu’on a publié notre source de données, les droits d’accès aux différentes régions et aux différents Etats sont conservés !
C’est pas beau ça ?
Alors évidemment, vous me direz, mais le projet « Custom » ça va vite devenir un dépotoir. Comment on fait pour éviter la prolifération de classeurs laissés à l’abandon ?
Alors plusieurs précisions. Premièrement, tous ces rapports s’appuient sur une même source de données. Du coup, la place occupée est relativement marginale. De plus, vous pouvez régler la taille maximale d’espace disque à allouer à chaque site. Malgré tout, il est vrai qu’il vaut mieux passer un bon coup de balais de temps en temps. En ce cas plusieurs options s’offrent à vous. Vous pouvez définir les règles du jeu en stipulant que les classeurs non utilisés depuis plus de X temps seront supprimés. Et du coup, je vous invite à consulter l’outil de monitoring du serveur.
Sinon, il vous reste toujours votre arme préférée, L’ULTIMATUM. Demandez aux utilisateurs eux même de faire le ménage en créant un nouveau projet « Custom » et en leur demandant de déplacer le contenu qu’ils souhaitent conserver d’ici 3 minutes. Passé ce délai, supprimez l’ancien projet.
Pour conclure, je répéterai qu’il existe pléthores de solutions que ce soit en termes de découpage (sites / projets) ou en termes de gestion de son contenu. L’exemple présenté n’a pas pour ambition de présenter LA solution magique ; il existe d’autres façons de procéder tout aussi pertinentes ainsi que d’autres façons d’obtenir le même résultat. Cet exemple est donc perfectible. Ne perdez pas de vue qu’il ne s’agit que d’un exemple, dont le but est de vous donner des pistes sur l’utilisation que vous pouvez faire de Tableau Server pour répondre à VOS besoins.
Sections commentaires non disponible.