Activating Office 365 groups is not an option

 I see a lot of different reactions when it comes to Office 365 groups. But there is one thing that unites close from every IT department I know : deactivate it, hide it ! (and pray for users to not get aware of its existence). Caricature ? Maybe

Reasons ?

  • We are not ready
  • We can’t control everything yet
  • We have difficulties matching every tool with a use case
  • We only want users to have the tools we decided they needed

Here is why those arguments are irrelevant in my opinion.


Everything is built upon groups

This is SaaS. Microsoft is deciding (with feedback from users of course) what the future is. And Microsoft decided the future will be built upon groups.

Lots of features have rolled out, some others are rolling out right now. And not only for first release customers. The only way to go back to good old SharePoint Sites : stop Office 365.

We are building technical debt

Technical debt is something we fight a lot as developers. Every problem, every bug that we just hide will come back one day. And it will be far more difficult to fix. We all know what happens when we shut down some work because we have other priorities. We will always have other priorities.

One day we will have to activate it,  whether there is no more ability to stop it or because no tool works without. And it is going to hurt. A lot.

This is the perfect moment to prepare

Features are rolling out, one by one. It is easy to stay tuned, news after news. We still have time. The perfect moment to try it. To get feedback from users. To check which tools we prefer for our usages. To build our adoption strategy. We may be surprised, as users may prefer groups to the big SharePoint template we spent months building.

All the time we spend creating SharePoint branding that will be obsolete in 6 months. All the energy we spend trying to hide O365 features. We could be monitoring usages, communicating, building adoption strategies, building tools to do what groups don’t do.

What’s wrong with giving tools to users ?

Everything that is rolling out now is just a set of extra tools users can have. Why so much hate ? It’s like IT departments want to tell people a list of scenarios with a tool attached to each one. We want to control everything. We are control freaks. There are reasons we build procedures, of course. But sometimes we should let go.

Maybe users know better than us what they need. Maybe they are used to massive tooling in there private life. Maybe they are now using Slack + Dropbox + Trello and have the same features but without you monitoring it. Maybe they just need a go and will be delighted to use those tools. Maybe not. The best way to know is to go for it, and get feedback. Feedback, iterative or lean strategies are not only for startups !

What is the worst case scenario ?

Users creating an important amount of groups, and information is not well organized ? Users creating groups they shouldn’t create ? Users uploading top secret documents in external groups ?

We can have power users with a global vision of the team and responsible for organizing work and data. Those people are already organizing other content in their team.

We can classify groups to remind users about what content should be in each group. We will soon be able to apply policies with each classification.

Users are adults with responsibility on their actions. We don’t block  every action that could be possibility dangerous if maybe someone was doing something very stupid. Or it is not yet the case in my country. We should stop doing that in IT every day, treating users as brainless children.

If you really need to ensure some documents will never ever possibly get out of your company, there are true solutions.

So what now ?

We don’t have to use everything now. We don’t have to love every feature. We don’t have to stop everything we had and migrate to groups. But we have to get used to them. And I think we will finally love using them.

Why and how we started contributing to Patterns & Practices

Our journey with Patterns & Practices

Our journey with Patterns & Practices started when we first saw the project on GitHub, maybe two years ago. We already had our own internal framework so we just checked what this new tool could do for us. It clearly didn’t cover all our use cases, and we would still have to use our own framework.

Then I came to Ignite in 2015, and I saw Vesa Juvonen presenting the provisioning framework. It was like “Damn, it has grown a lot!”. We started using it as nugget package. It was still not covering all our use cases, but we were migrating our code slowly. As a lot of people were using this project, we found PnP functions more tested than ours, and it was great. We still had our framework tho, but it was disappearing.

But we still had issues:
        We couldn’t debug when we had a problem
        We had to wait for fixes, so we copied PnP functions in our framework to fix them for ourselves
        We had to go to GitHub and browse files to understand fully all we could do with this framework


And then, we decided to fork the project (we are using PnP-Sites-Core as a fork, as this is the project we use the most). When you know git (and I really recommend reading at least the first three chapters of the git documentation if you are new to it), it is really fast to set up your environment for development.

Our contribution workflow is:


1.      We locally clone our fork
2.      When we want to do some changes, we create a branch for this change that we merge to master when it’s ready
3.      We have a dev branch, created from the tracked PnP-Sites-Core dev branch
4.      When we have something interesting to propose we create a branch, get the commits from our master branch and create the pull request

We then just have to regularly get updates from PnP repositories, and reference our fork as a submodule in other projects.

This new approach has some advantages:
        Our whole team has a better understanding of how the project works
        We can debug
        We don’t have to wait for official fixes
        We can add our own code directly into the framework
        It’s exciting to take part of a bigger community 

5 pull requests merged so far, and a 6th waiting 🙂


Gérer la mobilité des internes sur SharePoint (et autres), avec Azure AD Application Proxy

Dans un contexte de mobilité et BYOD, on désire de plus en plus ouvrir l’accès aux ressources « on premise » en dehors de l’entreprise. Si ADFS reste la référence pour l’ouverture aux externes, l’équipe Azure de MS a développé récemment un proxy applicatif permettant de se connecter en SSO  sans mise en place d’infrastructure ou reconfiguration de l’application « on premise ».

Votre application (ici un portail SharePoint) est tout simplement publiée comme une APP sur votre portail 365. L’authentification est transparente, en interne comme en mobilité.

On peut, bien sur, panacher avec ADFS pour les « vrais » externes qui n’auraient pas de compte dans un AD approuvé.

Le Principe

Dans le cas d’un utilisateur externe, on ne peut pas recourir à l’authentification intégrée sans VPN, et on recourt généralement à ADFS :


Si l’utilisateur externe (ou en mobilité) est référencé dans un annuaire AD, il existe une alternative à ADFS, présentée dans le cadre de ce post :


On évite ainsi :

  • De déployer ADFS
  • De recourir à un formulaire d’authentification ou autre custom provider

Le pré-requis est d’avoir synchronisé les utilisateurs avec notre tenant 365. On centralise alors l’authentification sur le tenant, et cette identitée « online » pourra être convertie en SSO en une identité interne via ce proxy applicatif.

Par exemple, dans le cas de l’authentification windows intégrée, « » peut être utilisé comme « MCNEXT\Emmanuel.issaly »

Configuration 365

Si votre annuaire est déjà synchronisé avec azure AD (c’est un prérequis), Vous pouvez sauter ce chapitre. Sinon, créez un tenant Office 365 de test (un tenant de dev MSDN suffit)


Créez une adresse admin facile à mémoriser, ici j’ai pris

Sur ce tenant « eissaly », allez activer Azure AD par la tuile d’admin :


Vous devez synchroniser les utilisateurs de votre domaine local avec un domaine online. Dans mon cas, étant déjà pris, j’ai ajouté un suffixe UPN « » à mon AD de tests sp2013.local. Emmanuel ISSALY est alors identifié par SP2013\eissaly *ou*

Pour déclarer et vérifier le domaine dans azure, allez dans « Domains » du tenant 365 :


Une fois le domaine vérifié, on peut lancer la synchronisation d’un serveur quelconque de notre lab avec ADCONNECT. C’est en fait un FIM customisé (au sens qu’il fonctionne correctement). Il vous faudra le compte admin 365 et le compte admin du domaine local.


Pour que l’application proxy fonctionne, il faut une licence Basic ou Premium AAD pour chaque utilisateur.
Activez le premium trial, ce qui vous donnera 100 licences.


Publication de l’application SharePoint

Publication azure

 Nous allons publier notre SharePoint on prem comme une APP dans 365 :
Allons dans « Applications » de notre Azure AD, et faisons « ADD »



Puis s’offre à nous l’option de télécharger ce nouveau connecteur :


Déployez-le sur un serveur 2012 R2 qui a accès à internet. Le serveur de synchro qui fait déjà AD connect est une bonne destination pour lui !

Suite à l’activation de ce connecteur, on a d’autres options dans la configuration de notre application :

1.- Une URL publique générique, ou l’adresse publique de votre domaine :



2. et la patte interne, en windows intégré :


à noter que l’équipe azure AD travaille sans cesse à proposer de nouveau mappings, et l’on peut même maintenant convertir l’identité online à une identité non windows (via la délégation Kerberos)

Configuration HTTPS / Kerberos

Pour que cela marche, il faut quand même quelques contraintes, en l’occurrence une délégation contrainte Kerberos (KCD)

  1. Créer le SPN du portail (nom court nom long et compte de pool d’appli)

setspn –S http/portal sp_app

setspn –S http/ sp_app

2. Autoriser la délégation KCD sur le serveur qui héberge le connecteur :

Sur un contrôleur de domaine, Propriétés sur l’ordinateur, onglet délégation, autoriser la délégation :


Puis ajoutez le SPN (on le trouve par le compte de pool)


Vous devriez à présent obtenir un ticket kerberos en appelant votre site SharePoint.
Attention, il faut que le DNS appellé soit une IP (A record), pas un alias !


Le site SharePoint étant déclaré sur le tenant, on peut y accèder par un clic de tout périphérique connecté à Internet :


De ce fait, que l’on soit à l’intérieur du LAN, ou d’un appareil mobile (ici Chrome + Android) connecté à office online, l’expérience utilisateur est maintenant la même, quelque soit l’environnement
(pas de prompt, Windows intégré dans notre cas)


 Comment ça marche



  1. L’utilisateur tape l’url du site SharePoint
  2. AAD proxy fait de la pré-auth : si vous êtes déjà connecté online, on obtient un jeton, sinon il vous prompte pour votre profil online.
  3. Dans tous les cas, le jeton obtenu est envoyé au proxy.
  4. Le connecteur extrait du jeton l’UPN (lidentifiant utilisateur)
  5. Le connecteur fait une demande de jeton Kerberos de la part de l’utilisateur
  6. Si la delegation est autorisée, le jeton est émis.
  7. Le connecteur envoie alors la requete et son jeton comme si on était “interne »
  8. La page est renvoyée au navigateur

Il est également possible de customiser le ticket kerberos pour que le login arrivant sur l’application ne soit pas l’email, ou soit un login différent du login online (typiquement pour se connecter à un système non Windows) :


Sur ce schéma, je me connecte entant que à 365, mais j’arrive en tant que Contoso\joed sur l’application ciblée par ce connecteur.

Intégrer Yammer à SharePoint : Yammer Embed et API REST

Yammer offre deux modes pour son intégration aux sites et applications tierces : Yammer Embed ou une API REST. Voici un descriptif des possibilités offertes par chacun.

Yammer embed

Mode simplifié d’ajout de Yammer à un contenu HTML :

  • Un javascript Yammer à référencer
  • Un bloc HTML comme conteneur
  • Une fonction d’appel avec options

<div id="embedded-feed" style="height:800px;width:400px;"></div>

<script type="text/javascript" src=""></script>
<script type="text/javascript"> yam.connect.embedFeed({
container: "#embedded-feed",
network: "",
feedType: "group",
feedId: "2211345"});

Note : il est possible d’obtenir cela très facilement en l’exportant directement à partir d’un groupe Yammer ou en utilisant l’utilitaire de configuration fourni par Yammer.

Fonctionnalités offertes

Les fonctionnalités offertes sont exactement les mêmes qu’à l’intérieur d’un flux Yammer :

  • Lecture de messages
  • Ecriture de messages avec pièces jointes
  • Like
  • Suivi
  • Partage
  • Réponse
  • Ajout de sujets
  • Se l’envoyer par email

Le rendu est fait dans une iframe dont la hauteur et la largeur sont fixes.

Les options disponibles

  • Réseau auquel se connecter
    Par défaut le réseau actif de l’utilisateur
  • Forcer la connexion au réseau principal de l’utilisateur, même s’il vient de visiter un réseau externe
  • ID du groupe Yammer utilisé par défaut lors de la saisie d’un nouvel élément
  • Texte à afficher dans la zone de saisie avant que l’utilisateur ait commencé à écrire son message
  • Type de flux :
    • MyFeed = flux de l’utilisateur
    • Group = choix d’un groupe à afficher par ID
    • User = choix d’un utilisateur à afficher par ID
    • Topic = choix d’un sujet à afficher par ID
    • Open Graph = commentaires sur l’élément courant (par exemple une page d’article ou un document). Plusieurs paramètres complémentaires sont disponibles pour permettre de choisir l’élément commenté, les métadonnées associées au poste…
  • Si le composant utilise le SSO

Modification de l’apparence

Le composant sera affiché dans une iframe et peut être sujet à modifications dans le futur : il ne faut pas chercher à modifier son apparence.

Il est néanmoins possible d’indiquer :

  • Si le header doit être affiché (nom du réseau)
  • Si le footer doit être affiché (option de déconnexion)
  • Si le nom du réseau doit être caché dans le header : si le header est affiché, alors il indiquera un message neutre comme « Conversations Yammer » plutôt que d’indiquer le nom du réseau


Une api REST permet d’intégrer Yammer comme souhaité au sein de n’importe quelle application. L’apparence est alors complètement personnalisable puisque tout est à la charge du développeur.

Une documentation très complète et claire est fournie sur le site de développement Yammer.


Il faut :

  1. Enregistrer l’application dans Yammer
  2. S’authentifier en utilisant le bouton Yammer ou en OAuth.

Une ID d’application est nécessaire pour la connexion. Tous les utilisateurs devront accepter l’application.

Limites d’appels

Le nombre de requêtes par utilisateur et par application est limité. Une erreur sera retournée lorsque l’utilisateur dépassera cette limite. La limite est différente selon le type d’élément demandé :

  • Messages = 10 requêtes en 30 secondes
  • Notifications = 10 requêtes en 30 secondes
  • Tous les autres = 10 requêtes en 10 secondes


Voici les différentes possibilités offertes par l’API REST :


Type de requête Description Commentaires
  Derniers messages Il est possible de récupérer tout le thread ou uniquement le premier message de chacun.

·        Tous

·        Flux de l’utilisateur

·        Top

·        Suivis

·        Envoyés

·        Messags privés

·        Reçus

  Messages d’un thread
  Messages liés à un sujet
  Ecrire un nouveau message ·        Corps du message

·        ID du groupe dans lequel poster

·        ID du message pour la réponse

·        Utilisateur à qui envoyer le message en privé

·        S’il s’agit d’un broadcast

·        Sujets

·        Pièces jointes

·        Objet opengraph associé

  Envoyer une copie d’un message par email à l’utilisateur courant
  Liker un message
  Supprimer un message Par ID
  Unliker un message

Corps d’un message

  • Parsed : les URL sont telles quelles, les mentions d’utilisateurs sont mises sous la forme user:id
  • Plain : les URL sont telles quelles, les mentions utilisateurs sont sous la forme « Nom complet »
  • Rich : HTML à afficher, avec les balises <a></a> pour les URL

Propriétés d’un message

  • ID
  • ID de l’utilisateur ayant posté
  • Date de création
  • ID du réseau
  • Type de message
  • Type de sender
  • URL
  • ID du groupe
  • Body
  • ID de thread
  • Type de client (web, app…)
  • ID des utilisateurs notifiés
  • Message privé ou publique
  • Pièces jointes
    • ID
    • Type
    • Nom
    • Description
    • ID du réseau
    • URL
    • URL de la miniature
    • Type d’objet
    • Nom de l’objet
    • URL de l’hôte
    • HTML à afficher
  • LikedBy : nombre + liste des utilisateurs


Type de requête Requête Commentaires
  Utilisateurs du réseau Paginée, triée par nombre de messages, nombre de followers ou alphabétiquement
  Utilisateur courant
  Utilisateur par ID
  Utilisateur par email
  Utilisateurs d’un groupe Paginée, triée par nombre de messages, nombre de followers ou alphabétiquement
  Utilisateurs ayant utilisé un sujet
  Utilisateurs ayant liké un message
  Relations pour l’utilisateur courant ou par ID Supérieurs, subordonnés et collègues
  Créer un utilisateur
  Inviter un utilisateur au réseau Yammer actif
  Ajouter une relation
  Supprimer un utilisateur
  Modifier un utilisateur

Propriétés d’un utilisateur

  • Email
  • ID
  • Réseau : ID, Nom, Domaines
  • Etat
  • Activation : Date, auto activé ou non
  • Nom complet
  • URL du profil
  • Image de profil (48×48)
  • Date de naissance
  • S’il est administrateur
  • Statistiques : nombre de followers, nombre de personnes suivies
  • Poste
  • Département
  • Emplacement
  • Téléphone de travail
  • Téléphone mobile
  • Intérêts
  • Résumé
  • Expertise
  • Diplômes
  • Entreprises précédentes


Type de requête Requête Commentaires
  Groupes suggérés
  Rejoindre un groupe
  Quitter un groupe
  Supprimer une suggestion de groupe


Type de requête Requête Commentaires
  Utilisateurs suggérés pour le suivi
  Vérifier si on suit un utilisateur
  Vérifier si on suit un thread
  Vérifier si on suit un sujet
  S’abonner à un élément
  Se désabonner d’un élément
  Supprimer une suggestion d’utilisateur à suivre


Type de requête Requête Commentaires
  Notifications de l’utilisateur courant
  Recherche Faire des requêtes de recherche, comme dans le portail Yammer
  Liste des réseaux auxquels l’utilisateur a accès

Mise en oeuvre de l’API Exchange sur un compte Office 365


Exchange Web Services (EWS) est une API multiplateforme qui permet aux applications d’accéder aux boites (emails, réunions, calendriers, contacts…) et de les gérer à partir d’Exchange Online dans le cadre Office 365 ou On Premise dans le cadre d’Exchange Server. De plus, cette API permet de stocker ou récupérer des données sur un compte Exchange, offrant une grande souplesse dans la gestion et la manipulation des éléments de messagerie Exchange pour un utilisateur, un groupe d’utilisateurs ou une organisation entière.


Les applications EWS peuvent accéder aux éléments d’une boîte en envoyant au serveur Exchange (online ou on premise) une requête dans un message XML basé sur le protocole SOAP. Le message SOAP est incorporé dans un message HTTP lors d’un échange application/serveur Exchange. Capture


  • Un ordinateur exécutant Microsoft Exchange Server 2007 SP1 (ou version ultérieure) ou un accès à Exchange Hosted Services.
  • Framework .Net 3.5 (ou version ultérieure)
  • Assembly de l’API : Microsoft.Exchange.WebServices.dll
  • Visual studio 2008 (ou version ultérieure) avec les composants C#

Connexion au serveur Exchange

Pour établir une connexion à EWS, il faut créer un objet ExchangeService et se connecter au serveur d’accès client Exchange (CAS) en utilisant un compte avec un accès suffisant. Pour se connecter il est nécessaire de renseigner le nom du compte ainsi que son mot de passe. Une fois la connexion établie, toutes actions réalisées sur les éléments Exchange sont accessibles depuis l’objet ExchangeService.

ExchangeService _exchangeService = new ExchangeService(ExchangeVersion.Exchange2013)
    Credentials = new WebCredentials("userName", "password")

_exchangeService.AutodiscoverUrl("", RedirectionUrlValidationCallback);

private bool RedirectionUrlValidationCallback(string redirectionUrl)
    Uri redirectionUri = new Uri(redirectionUrl);
    return redirectionUri.Scheme == "https";

Exchange Autodiscover

Le service Autodiscover d’Exchange fournit à l’application cliente un moyen facile pour configurer automatiquement une connexion avec une entrée utilisateur minimale : adresse de messagerie et mot de passe. Ce service est généralement utilisé pour trouver automatiquement l’URL d’un point de terminaison EWS.

Gérer des éléments Email

La gestion Email nécessite un objet ExchangeService connecté, et il y a six actions principales possibles avec un Email :

  • Création
  • Envoi
  • Transmission
  • Réponse
  • Suppression
  • Sauvegarde

Chacune de ces actions sont implémentées en utilisant un objet EmailMessage.

Création et envoi d’un email

Pour cette fonction, le principe est de créer un objet EmailMessage, remplir les champs, puis envoyer le courriel (avec sauvegarde du message dans le dossier « Eléments envoyés »). Le code C# ci-dessous montre comment créer l’objet EmailMessage et envoyer un email.

EmailMessage message = new EmailMessage(_service)
    Subject = "SubjectText",
    Body = "BodyText"


Transmission d’un email

Cette fonction s’applique à un objet EmailMessage existant, soit un message reçu et acquis depuis le serveur Exchange, soit un objet préalablement créé. Pour cet exemple, nous utiliserons l’objet EmailMessage précédemment créé. Le code C # ci-dessous montre comment transmettre un message électronique.

string messageBodyPrefix = "This message was forwarded by using the EWS Managed API";
EmailAddress[] addresses = new EmailAddress[1];
addresses[0] = new EmailAddress("");
message.Forward(messageBodyPrefix, addresses);

Répondre à un email

Tout comme la transmission d’un message, la réponse à un message s’applique à un objet EmailMessage existant. Une fois de plus, pour l’exemple nous prendrons l’objet précédemment créé pour appeler la méthode de réponse.

string myReply = "This is the message body of the email reply.";
bool replyToAll = true;
message.Reply(myReply, replyToAll);

Suppression d’un email

Cette fonction s’applique à un objet EmailMessage existant. La méthode dispose de 3 modes de suppression :

  • SoftDelete : L’élément ou le dossier sera déplacé vers la corbeille. Articles et dossiers dans la corbeille peuvent être récupérés.
  • HardDelete : L’élément ou le dossier seront supprimés définitivement
  • MoveToDeletedItems : L’élément ou le dossier seront déplacés vers le dossier « Deleted Items » de la boîte aux lettres.

Dans l’exemple suivant, nous utiliserons le mode de suppression, MoveToDeletedItems.


Récupération de messages depuis Exchange

Les actions présentées précédemment peuvent être appliquées à une collection d’objets EmailMessage obtenue depuis le serveur Exchange. Pour cela, il faut spécifier le dossier cible et le nombre d’éléments souhaité. L’exemple suivant illustre comment récupérer les mails depuis la boite de reception.

FindItemsResults results = _service.FindItems(WellKnownFolderName.Inbox,
                                                    new ItemView(int.MaxValue));
foreach (EmailMessage msg in results)
   // traitement sur chaque message

Gérer des éléments Contacts

Comme pour les emails, la gestion des contacts nécessite un objet ExchangeService connecté.

Récupération des contacts depuis Exchange

Pour récupérer les éléments de contact à partir d’Exchange, il faut spécifier le dossier Contacts en utilisant l’énumération WellKnownFolderName et le nombre de contacts à récupérer à partir d’Exchange. Le code C# ci-dessous montre comment récupérer les éléments de contact à partir d’Exchange. Dans ce cas on récupère tous les contacts d’Exchange (spécifier une valeur plus petite réduit le nombre d’articles retournés par le serveur).

FindItemsResults results = _service.FindItems(WellKnownFolderName.Contacts,
                                 new ItemView(int.MaxValue));
foreach (Contact ctc in results)
    // traitement sur chaque contact

Créer un contact

Le principe est le même que pour les emails, on crée un objet Contact, on remplit les champs puis on sauvegarde le contact.

Contact _contact = new Contact(_service);
_contact.DisplayName = "John Doe";
_contact.EmailAddresses[EmailAddressKey.EmailAddress1] = "";

Supprimer un contact

Cette fonction s’applique à un objet Contact existant. La méthode dispose de 3 modes de suppression :

  • SoftDelete : L’élément ou le dossier sera déplacé vers la corbeille. Articles et dossiers dans la corbeille peuvent être récupérés.
  • HardDelete : L’élément ou le dossier seront supprimés définitivement.
  • MoveToDeletedItems : L’élément ou le dossier seront déplacés vers le dossier « Deleted Items » de la boîte aux lettres.

Dans l’exemple suivant, nous utiliserons le mode de suppression, MoveToDeletedItems.


Aller plus loin

Les actions présentées précédemment sont un échantillon des fonctionnalités disponibles dans un contexte Exchange. Il est possible par exemple de :

  • Naviguer entre les différents dossiers de la boite de messagerie et les manipuler
  • Manipuler le calendrier, créer et gérer des réunions ou RDV
  • Manipuler des pièces jointes
  • Gérer des conversations
  • Créer et gérer des alertes ou notifications

Un recueil d’exemples très complet est disponible via le lien suivant et présente une grande partie des fonctionnalités proposées par le service Exchange :

Power BI Pour Office 365

Suite à la Présentation IT CAMP de SQL 2014 et Power BI Pour Office 365 par Franck Mercier, voici un résumé des fonctionnalités de Power BI Pour Office 365.


POWER BI pour Office 365 est composé de plusieurs éléments qui constituent la suite BI incluse dans Excel et qui permet de stocker vos Workbooks dans le Cloud grâce au Site Power BI.

A noter que certaines fonctionnalités ci-dessous ne sont pas présentes seulement dans Power BI pour Office 365, elles sont en faites présentes dans Excel qui lui-même est l’élément principal de la suite Power BI.

On peut donc séparer les éléments en 2 Parties:
1. Excel : rapatrier des données, les modéliser et les visualiser/ analyser.
2. Cloud : partager des rapports sur le Site Power BI qui est une option d’Office 365. Accessibilité via mobile, tablette. Trouver des infos grâce à Q&A, automatiser le rafraichissement des rapports…

Voici un résumé des différents éléments que regroupe Power BI pour Office 365, ainsi que les versions minimum nécessaire :


POWER QUERY « ETL » pouvant   se connecter à tout type de données interne ou externe Excel 2010
POWER PIVOT Modélisation des données pouvant   se connecter à de nombreuses sources de données utilisant un moteur en   mémoire très performant Excel 2010
POWER VIEW Visualisation des données principalement   de type charte / histogramme en mode “Dynamique” Excel 2013
POWER MAP Visualisation des données géographique   sur carte 3D en mode “Dynamique” Excel 2013


POWER BI SITE Stockage et partage des   rapports, support bientôt HTML5 (SharePoint Online Amélioré) Office 365 Option Power BI
POWER BI MOBILE App Visualisation des rapports   sur tablette et téléphone Office 365 Option Power BI
POWER BI Q & A Outil inclus dans le site   web pour poser des questions en « langage naturel » (ex : Français   courant) avec réponse en graphique Office 365 Option Power BI
DATA MANAGEMENT GATEWAY / DATA REFRESH Data Catalog ET passerelle entre   les documents dans le Cloud et les sources de données « On Promise »   pour rafraichir les données. Office 365 Option Power BI

Je ne reviendrai pas sur les différents modules d’Excel dont nous avons déjà parlé (Power Query, Power Pivot, Power View and Power Map) et pour lequel nous pouvons déjà trouver pas mal d’articles, Tutos et autre Webcasts.

Je vais faire un focus sur les éléments de Power BI inclus dans Office 365 qui vous permettent de faire de la BI Online et/ou en Cloud Hybride.

Voici tout d’abord l’architecture de Power BI qui est je le rappelle encore une version Preview et qui peut donc être modifié, il vient d’ailleurs d’être enrichi du DATA REFRESH :


Comme d’écrit plus haut, nous voyons bien les deux parties – Excel sur la droite et Cloud sur la gauche – qui complète la Suite Power BI dans Office 365.

Passons donc à chaque éléments :


Power BI Site est une app pour SharePoint Online, il permet de visualiser et organiser les documents Excel d’une meilleur façon qu’une simple librairie SharePoint. Il inclut également toutes les autres fonctionnalités propres à Power BI dont nous allons parler ci-dessous.


Une application propre à Power BI pour Office 365 qui permet de visualiser les rapports stockés sur le site Power BI. L’application est pour le moment seulement disponible sur le Windows Store, une application IPad serait en cour de développement. Power View est actuellement le meilleur outil pour la visualisation sur App grâce à sa visualisation Dynamique.
L’application est gratuite sur le Windows Store, cependant elle permet de visualiser seulement des rapports stockés dans le Site Power BI.


Cette fonctionnalité permet de poser des questions sur le Site Power BI en langage courant et de visualisé la réponse sous forme de rapport graphique. Pour le moment Q&A est basé seulement sur quelques Workbooks proposés par Microsoft ce qui ne permet pas de vraiment tester la qualité des résultats. Nous reviendrons donc sur ce module lorsqu’une version plus complète sera disponible.


Ce module permet de faire du Reporting en mode Cloud Hybride – j’entends par là le fait d’avoir vos rapports dans Office 365 donc dans le Cloud et d’avoir vos sources de données sur site donc « On Promise » – sans créer une infrastructure complexe.

Le DMG vous permet de créer une passerelle entre les deux environnements.

Pour faire simple, à partir du centre d’administration du Site Power BI vous aller créer une « Passerelle » sécurisée entre votre rapport et le server de donnée source. La création de la passerelle sur le Site Power BI génère une clé unique qu’il faudra installer manuellement sur le Server de donnée source à l’aide d’un agent (une seule fois).

Une fois la passerelle installée il est donc possible de visionner en mode Excel web App un rapport stocké dans Power Bi for Office 365 (un SharePoint Online amélioré) et de rafraichir directement les données!

*A Noter que les crédentials de connections au source qui sont « On Promise » peuvent être stockés dans le Cloud ou « On Promise », donc aucune données ou crédential ne seront stockés dans le Cloud si vous le désirez.
Par contre si votre Workbook contient un modèle Power Pivot celui ci sera stocké dans le Cloud, privilégié donc un modèle SSAS Tabular dans ce cas.

Le DMG permet également de pouvoir se connecter grâce à Power Query à des données « On Promise » qui seront mis à disposition des utilisateurs sous la forme d’un flux Odata. On peut imaginer des Vues qui seront créées par l’IT pour les utilisateurs, par exemple Vue Client, Vente… et mis à disposition sur le Site Power BI pour la Self BI !
Grace à la passerelle créée, les utilisateurs pourront importer les données et créer leurs propres rapports, et ce, même en étant en dehors du réseau de l’entreprise.

Data refresh

Process du flow de donnée au travers du DMG (décrit ci-dessus) qui permet le rafraichissement manuel ou automatique des données des rapports comme dans SharePoint, fonctionnalité très attendu par la communauté et qui vient d’être ajoutée à la Suite Power BI. Il permet de planifier le Refresh automatique des Workbooks et Data Catalog sur le Site Power BI.



Power BI est aujourd’hui une suite complète qui permet de créer ses propres rapports entièrement dans Excel, partager les rapports et automatiser le refresh. Nous sommes donc bien dans le Self-Service BI !
Il y a encore des limitations concernant la taille maximum des fichiers Excel mais cette limitation tant à diminuer (aujourd’hui 250MB pour la visualisation d’un Workbook, 30MB pour le Refresh des données via Power BI).

L’interface du Site Power BI étant différent de SharePoint Online il peut être déroutant au premier abord mais comme tous les nouveaux outils quelques minutes de prise en main seront nécessaires. Espérons que les utilisateurs prendront le temps nécessaire car le Site est avant tout fait pour eux.

D’autres articles suivront dès que possible pour détailler les modules ci-dessus avec quelques tutoriaux.

Essayer Power Bi c’est ici :