Microsoft revendique aujourd’hui plus de 100 millions 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.
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.
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..). Vous pouvez également utiliser Graph avec PowerApps et Power Automate pour des cas qui ne seraient pas couverts par les connecteurs.
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 ».
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.
