Pourquoi et comment utiliser Microsoft Graph API ?

Pourquoi et comment utiliser Microsoft Graph API

Microsoft revendique aujourd’hui plus de 100 million d’utilisateurs actifs de sa suite collaborative cloud Office 365. Aussi, pour différentes raisons, il est important de pouvoir extraire les données d’Office 365. Pour cela, Microsoft propose une solution : l’API Microsoft Graph.

Dans un premier temps, je vais expliquer à quels besoins peut répondre Microsoft Graph. Ensuite, je vous montrerai comment créer une application utilisant cette API.

Pourquoi et comment utiliser Microsoft Graph API

Microsoft Graph permet de se connecter à de nombreuses ressources liées à Office 365 (utilisateurs, discussions, calendriers, groupes, …). La dénomination « Graph » vient du fait que toutes ces ressources sont interconnectées, formant un réseau d’objets.

Par exemple, pour un utilisateur donné, Graph permet d’accéder à ses messages, son calendrier, ses fichiers, mais également aux groupes auxquels il appartient. Cet utilisateur est également associé à un manager, à un ou plusieurs appareils (PC, téléphone, etc..), et d’autres choses encore… Ces interconnexions permettent d’imaginer beaucoup de scénarii d’utilisation.

Pourquoi utiliser Microsoft Graph ?

Sur son site, Microsoft fournit toute une liste d’exemples permettant d’illustrer le potentiel de Graph. Je vais en détailler deux que je trouve particulièrement intéressants.

Développement d’application de planification de rendez-vous

Le premier est le développement d’une application de planification automatique de rendez-vous. L’application permet de proposer des créneaux de rendez-vous en fonction de la disponibilité, du statut d’absence du bureau, des salles de réunions et des documents associés. On peut facilement voir la valeur ajoutée de Graph dans ce cas-là. L’agrégation des données collaboratives permet de créer une application qui améliore la collaboration elle-même. Ce scénario de création de rendez-vous peut s’appliquer dans beaucoup de situations (CRM, Helpdesk, etc…).

Création de rapports personnalisés

Le second est la création de rapports personnalisés modélisant les données d’Office 365. Pour connaitre la valeur ajoutée et le ROI d’une brique du système d’information, il est nécessaire d’effectuer des mesures. La collaboration n’échappe pas à cette règle. L’investissement pour la mise en œuvre d’Office 365 peut être assez conséquent (coût des licences, gouvernance) et beaucoup d’entreprises ne savent pas si la plateforme est bien utilisée. Par conséquent, il est essentiel de mesurer son adoption.

Graph propose toute une liste de rapports (au format CSV) d’usages et d’activités associés aux différents outils d’Office 365 (Outlook, OneDrive, SharePoint, Skype for Business, etc…). Cela permet de définir des tableaux de bord, certes assez basiques, mais dont les informations donnent une vision claire de l’utilisation des différents outils.

Exploiter Graph

On peut cependant aller plus loin dans la démarche. Comme je l’ai dit au début de l’article les objets de Graph sont interconnectés. Pour exploiter pleinement Graph, il me parait intéressant de coupler ces différents rapports avec d’autres ressources fournies par l’API (par exemple en couplant le rapport d’activité Outlook avec la ressource « Fichiers » pour identifier les types de fichiers les plus envoyés en pièces-jointes).

Il est donc assez aisé de trouver des usages à Microsoft Graph. Nous allons maintenant voir comment le déployer facilement.

Comment utiliser Microsoft Graph ?

La question de la sécurité

La première problématique qui se pose, à l’instar de tout projet informatique, est celle de la sécurité. N’importe quel utilisateur ne doit pas accéder à n’importe quelle ressource. Par exemple, un utilisateur ne doit pas accéder à la boite mail d’un autre utilisateur. Pour utiliser Microsoft Graph, il faut au préalable inscrire une application Azure Active Directory sur le portail Azure (pour la procédure détaillée suivre ce lien). C’est cette application qui permet de définir les droits d’accès à chaque ressource. L’administrateur va définir selon le besoin, les différentes ressources accessibles.

C’est également cette application Azure Active Directory qui donne le contexte d’authentification (jeton) permettant d’accéder aux ressources. Ainsi, une application métier qui ne possède pas ce jeton, ne pourra pas accéder aux données de Graph.

La simplicité via une URL unique

La deuxième problématique est à mon sens celle de la simplicité. L’API Graph se compose d’une URL REST unique (https://graph.microsoft.com). Pour chaque appel, on définit également la version de Graph utilisée (1.0 ou beta), la ressource à laquelle on souhaite accéder (par exemple /users pour accéder à la liste des utilisateurs), et d’éventuels paramètres de requêtes (?$filter=startswith(displayName,’J’) pour remonter tous les utilisateurs dont le nom commence par la lettre J). La réponse HTTP est au format JSON, un standard utilisable dans la majorité des langages informatiques dont l’avantage principal est sa simplicité.

Voici un exemple d’URL complète de requête Graph :
https://graph.microsoft.com/v1.0/users?$filter=startswith(displayName,'J')

Graph permet de lire des données (GET) mais également de créer des enregistrements. En effet, grâce au protocole HTTP, il est possible de faire du POST. Un bon exemple est l’envoi d’emails avec la ressource (me/messages) en passant en paramètre la structure JSON du message.

Pourquoi et comment utiliser Microsoft Graph API

La portabilité

La troisième problématique est la portabilité. Les environnements techniques diffèrent selon les systèmes d’information et les technologies utilisées sont multiples. REST permet de répondre à cette problématique car il est utilisable dans la majorité des langages informatiques. Microsoft fournit de nombreux exemples de code et des SDK pour utiliser Graph (.NET, Javascript, PHP, Android, etc..).

Pour tester l’API, Microsoft fournit un outil en mode web simple et puissant : le Graph Explorer. Il permet d’effectuer des requêtes Graph et d’interpréter les résultats facilement.

Il y a donc beaucoup d’avantages à utiliser Microsoft Graph. J’y ajouterais cependant quelques bémols.

Quelques bémols…

Microsoft déploie de nouvelles versions de Graph tous les mois et les changements sont souvent majeurs. Il est donc important de suivre le changelog de Microsoft et d’effectuer de la veille sur l’API beta.

Les ressources de Graph sont, à mon sens, très orientées métier (collaboratif). Un administrateur Office 365 n’y trouvera pas toujours les informations qu’il cherche. Le meilleur exemple est la ressource « email ». Graph permet d’obtenir les données stockées dans une boite mail mais ne gère pas les données globales transitant sur Exchange Online. Pour récupérer des informations d’administration il est préférable d’utiliser d’autres API spécifiques à chaque outil plus orientées « Administration ».

A l’heure actuelle, l’API ne permet pas (dans la version 1.0) d’accéder à certaines ressources comme Teams.

Vous connaissez désormais les bases de Microsoft Graph. L’API étant perpétuellement en mouvement, de nouveaux scénarii d’utilisation apparaitront probablement dans un futur proche pour exploiter pleinement le potentiel d’Office 365.

Risques et facteurs clés de la collaboration en entreprise

smartview-risques-facteurs-clés-collaboration-entreprise
smartview-risques-facteurs-clés-collaboration-entreprise

Risque majeur #1 de la collaboration en entreprise : laisser la messagerie « gérer » la collaboration 

Faites une petite expérience à l’occasion : marchez librement sur un endroit plat, sans aucun obstacle, sans aucun risque à l’horizon (un espace vert, une plage, un terrain de sport)… puis fermez les yeux. Essayer de continuer à marcher dans une direction sûre sans ouvrir les yeux. Et comptez. Vous serez surpris de ‘voir’ qu’arrivé(e) à 10-15-20 pas, vous aurez envie d’ouvrir les yeux…. ou de vous arrêter.

Maintenant faites la même chose avec votre outil de messagerie préféré. Fermez-le, continuez à travailler librement et comptez combien d’heures (ou de minutes) vous pouvez vous en passer. Généralement, vous ne tiendrez pas une demi-journée. Pourtant, sauf quelques cas rares, le monde ne va pas s’arrêter si vous ne répondez pas dans l’heure (voire la minute) à vos correspondants.

C’est bien là le désastre qu’a provoqué la messagerie dans son usage en entreprise ; plus qu’un outil de travail (par ailleurs fort simple et pratique), elle constitue pour chaque collaborateur une « drogue dure » difficile à combattre.

La messagerie est devenue la « killer app » parfaite depuis plus de 20 ans !

Elle sature les collaborateurs de messages pas toujours pertinents et elle cannibalise leur temps (certains collaborateurs passent plus de 30% de leur temps à lire et écrire des messages; faites l’expérience de votre côté et mesurez…). Votre temps est précieux, or bon nombre de ces messages ne méritaient pas (vraiment) d’être lus ou écrits.

Elle entraîne un « zapping » permanent, peu propice à la concentration et à l’échange. Or la majorité des « travailleurs du savoir » (pour reprendre l’expression de Peter DRUCKER) créent de la valeur pour l’entreprise dans un état de concentration sur un sujet donné à un moment donné. L’e-mail empêche généralement d’atteindre ce niveau de concentration, de créer du savoir et de prendre des décisions complexes de haut niveau.

Elle sert d’écran d’accueil, d’agenda, de fil rouge de la journée pour les collaborateurs. Or les collaborateurs ont besoin d’établir leur propre plan d’action pour être efficaces et de prioriser les sujets réellement urgents / importants dans leur agenda. La messagerie les en détourne sans cesse (accentuant l’effet de procrastination sur les sujets complexes mais essentiels demandant un vrai effort dans la durée).

Un outil asynchrone mal utilisé

Elle est utilisé comme un outil synchrone (en temps réel) alors que c’est un outil asynchrone (différé). Ajoutez à cela les notifications visuelles (de type pop-up) ou pires, sonores (bienvenue à la fête foraine) et vous êtes totalement sous contrôle de votre e-mail. Imaginez-vous passer la journée à côté de votre boite aux lettres pour voir si le facteur est passé ou passera; c’est exactement ce que nous faisons avec l’e-mail…

La messagerie n’est pas centrée sur le partage ni sur la sécurisation des informations (c’est une sorte de fax !). Elle conduit à la dissémination des informations et à l’absence de capitalisation des connaissances. La messagerie n’est pas faite pour gérer des informations mais pour en envoyer / recevoir. C’est un peu comme confondre une boite aux lettres avec une bibliothèque. Les systèmes d’archives, personnels et non partagés ne sont que des pis-aller. C’est une erreur profonde de considérer les archives de messagerie comme des informations personnelles : ce sont les éléments de travail associés à la fonction de la personne qui doivent être mutualisés et capitalisés par l’entreprise. Combien d’informations utiles perdues lors d’une migration, d’un crash de disque dur ou d’un départ d’un collaborateur ?

La messagerie est devenue au fil du temps un véritable problème pour la collaboration en entreprise…

Mais de tous les défauts exposés précédemment, le plus grave c’est que la messagerie empêche l’émergence des autres outils et des bonnes pratiques collaboratives.
En saturant le temps utiles des collaborateurs, en leur donnant l’illusion qu’ils « gèrent » des informations et les relations avec un fax, la messagerie empêche l’entreprise de progresser vers une collaboration dont elle a pourtant profondément besoin.