Microsoft Graph ou endpoints REST traditionnels : un guide de décision pour 2026

La question est légèrement fausse

Tout ceux qui connectent une application à Microsoft 365, Entra ID, Teams ou les données d’Outlook finissent par se demander s’il s’agit de « REST API ou Microsoft Graph ? ». Cela semble être un choix équitable entre deux options, mais ce n’est pas tout à fait le cas. Microsoft Graph est lui-même une REST API. Ce que les gens entendent généralement, c’est ceci :

Faut-il continuer à utiliser les anciennes endpoints REST par service (Azure AD Graph, l’API REST d’Outlook, SharePoint REST, EWS et autres), ou passer à l’API Microsoft Graph unifiée ?

En 2026, cette question est soumise à des délais réels. Microsoft a passé environ trois ans à mettre fin aux API fragmentées et à orienter tout le monde vers Graph, et certaines de ces fermetures ont lieu dans quelques semaines à peine. Vous y trouverez la liste des noms classés, un état des lieux de ce qui fonctionne encore, une comparaison côte à côte, ainsi qu’un processus de décision que vous pouvez appliquer tant aux nouvelles versions qu’aux anciennes intégrations.

Classification des noms

REST est un style architectural, ce n’est pas un produit à installer. Une API qui utilise des verbes HTTP tels que GET, POST, PATCH et DELETE, qui traite les éléments en tant que ressources via des URL, et qui échange généralement du JSON peut légitimement se qualifier de RESTful. Selon cette définition, Microsoft Graph, Azure AD Graph, l’API REST Outlook désormais obsolète et SharePoint REST relèvent toutes de cette catégorie.

Microsoft Graph est l’unique API REST qui couvre à la fois Microsoft 365 et Entra ID. Il n’est plus nécessaire de passer d’un point de terminaison pour les e-mails à un autre pour les fichiers, puis à un troisième pour les données de répertoire. Tout se trouve sous https://graph.microsoft.com/ : utilisateurs, groupes, e-mails, calendriers, conversations Teams, fichiers, alertes de sécurité, ainsi que des agents IA plus récemment.

Ainsi, la comparaison pertinente concerne Graph unifié par rapport aux interfaces REST anciennes spécifiques à chaque service. La situation actuelle de ces API anciennes est très importante, car la situation a évolué rapidement au cours de l’année écoulée.

Ce qui fonctionne encore en 2026

Si l’un de vos services continue d’appeler graph.windows.net, vous êtes déjà en retard ; à partir de mi-juillet 2026, cette possibilité disparaîtra dans quelques semaines. L’ancienne API REST d’Outlook n’est plus disponible depuis plus de deux ans. L’accès via EWS par des tiers à Exchange Online sera également interrompu cet automne. Presque tous les arguments qui justifiaient autrefois le maintien d’un point de terminaison REST natif ont expiré ou vont bientôt l’être.

Microsoft a déjà reporté plusieurs de ces dates par le passé, il est donc nécessaire de vérifier la date limite actuelle sur Microsoft Learn avant de planifier une migration en conséquence. Cependant, l’orientation générale reste inchangée depuis des années : tout doit être intégré dans Graph.

Graph face aux anciens points de terminaison

Trois différences sont les plus importantes dans le travail quotidien.

Authentification

Pendant plus d’une décennie, les systèmes hérités ont accumulé une multitude d’options d’authentification : Basic Auth, NTLM, Kerberos, ainsi que le Azure Access Control Service sur lequel reposaient les compléments de SharePoint. Pour les charges de travail Microsoft 365, toutes ces solutions ont été abandonnées. Graph n’a jamais accepté que l’OAuth 2.0 via Microsoft Entra ID. Cela offre une seule méthode pour obtenir des tokens, un seul modèle de permissions et un seul endroit pour auditer qui peut accéder à quoi. Les administrateurs bénéficient ainsi d’une amélioration en matière de sécurité, tandis que les développeurs disposent d’une API plus performante.

Requêtes et agrégation

Une seule requête Graph, comme celle ci-dessous, peut filtrer, trier et afficher les e-mails en une seule requête :

GET https://graph.microsoft.com/v1.0/me/messages
    ?$select=subject,receivedDateTime,from
    &$filter=receivedDateTime ge 2026-07-01T00:00:00Z
    &$top=25
    &$orderby=receivedDateTime desc

Face aux endpoints plus anciens et moins flexibles, le même résultat nécessitait souvent plusieurs appels ciblés ou des filtres côté client. En ajoutant $batch, il est possible d’regrouper jusqu’à 20 opérations indépendantes en une seule requête HTTP, en combinant lectures et écritures sur des types de ressources complètement différents.

Régulation du débit

Graph applique plusieurs limites en même temps : par application pour tous les locataires, par locataire pour toutes les applications, et par application au sein d’un seul locataire. Les chiffres exacts varient selon le service, la messagerie, les fichiers, les dossiers et Teams ayant chacun leurs propres plafonds. Dès que vous atteignez la première limite, vous obtenez 429 Too Many Requests accompagné d’une en-tête Retry-After indiquant le temps d’attente requis. Par rapport aux anciennes API, où le throttling était souvent non documenté et où l’on découvrait les limites en production, c’est un progrès significatif. Le conseil reste valable : utilisez $select pour ne récupérer que les champs nécessaires, préférez les requêtes par lots et les requêtes delta aux requêtes en boucle, et respectez toujours Retry-After plutôt que de réessayer immédiatement.

Où Graph n’est pas encore la meilleure solution

Graph ne couvre pas encore tout, et certains cas exigent réellement une API différente.

• Gestion détaillée des sites SharePoint. Les détails complets au niveau des permissions, certaines opérations sur les groupes de site, ainsi que des parties de la gestion des schémas de types de contenu et de listes ne sont disponibles que via SharePoint REST sous _api/web/.... Les projets SharePoint matures utilisent généralement Graph pour les tâches quotidiennes liées aux fichiers, aux listes et aux lecteurs, et n’ont recours à SharePoint REST que pour ce qui manque.
• Composants web SPFx. L’environnement d’exécution du SharePoint Framework fournit déjà un contexte SharePoint REST prêt à l’emploi, ce qui en fait souvent le moyen le plus simple pour les personnalisations au sein de la page, même si le même composant web peut également appeler Graph.

Exchange Server local. La restriction de octobre 2026 ne s’applique qu’à Exchange Online, donc EWS continue de fonctionner avec Exchange local. Pour une configuration de messagerie entièrement locale, le véritable choix réside entre EWS ou une migration vers Exchange Online en premier.

Tâches administratives massives ponctuelles. Le nettoyage en masse des permissions, l’établissement de rapports pour les comptes utilisateurs et la provisionnement à grande échelle des sites sont souvent effectués à l’aide d’outils de niveau supérieur tels que PnP PowerShell, qui utilise lui-même un mélange de Graph et de SharePoint REST en interne.

Hors ces cas limités, un projet entièrement nouveau n’a que peu de raisons techniques de commencer à utiliser l’un des anciens points d’accès par service cette année, puisque la plupart sont déjà hors ligne ou en voie de disparition.

Comment décider

Évaluez toute nouvelle intégration en vous posant ces questions :

1. S’agit-il d’une nouvelle version ? Utilisez Microsoft Graph. Les nouvelles fonctionnalités y sont déployées en premier, et c’est la seule plateforme dans laquelle Microsoft continue d’investir.
2. Une application existante appelle-t-elle Azure AD Graph, l’API REST d’Outlook ou des compléments SharePoint basés sur ACS ? Outlook REST et ACS ont déjà dépassé leur période de support, et Azure AD Graph sera retiré le 31 juillet 2026. Traitez cela comme une tâche urgente.
3. Une application tierce utilise-t-elle EWS avec Exchange Online ? Microsoft commencera à bloquer ces appels le 1er octobre 2026. Commencez dès maintenant à passer aux points de terminaison de messagerie et de calendrier de Graph.
4. Avez-vous besoin d’une fonctionnalité de SharePoint que Graph ne dispose pas encore ? Utilisez SharePoint REST pour cette seule requête et Graph pour tout le reste. Consultez d’abord la documentation SharePoint-in-Graph, car la liste des fonctionnalités manquantes continue de se réduire.

L’environnement est-il uniquement local ? EWS et d’autres protocoles locaux restent valables dans ce cas. Graph est conçu pour le cloud et ne peut pas se connecter directement aux serveurs Exchange ou SharePoint locaux.

Pour presque tout le monde, cela se résume à une règle : utilisez Microsoft Graph, à moins d’avoir une raison spécifique et documentée de ne pas le faire.

La même requête, alors et maintenant

Voici l’appel Outlook REST v2.0 désormais obsolète, présenté uniquement à des fins de comparaison :

GET https://outlook.office.com/api/v2.0/me/messages
Authorization: Bearer {token}

Cet endpoint répond depuis mars 2024 avec HTTP 410 Gone. La version Graph de la même requête se présente comme suit :

GET https://graph.microsoft.com/v1.0/me/messages?$select=subject,from,receivedDateTime&$top=10
Authorization: Bearer {token}

SharePoint REST, qui est toujours pris en charge, lit les éléments de liste de la manière suivante :

GET https://{tenant}.sharepoint.com/sites/{site}/_api/web/lists/getbytitle('Documents')/items
Authorization: Bearer {token}
Accept: application/json;odata=verbose

Lorsque Graph prend en charge la même opération, l’appel devient :

GET https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items
Authorization: Bearer {token}

Les mécanismes HTTP restent identiques dans les deux époques. Ce que Graph ajoute, c’est une seule URL de base, un seul modèle d’authentification et une seule convention JSON, quel que soit le service Microsoft 365 auquel on s’adresse.

Migrer hors d’une API obsolète

Si vous venez de réaliser que quelque chose dans votre tenant dépend encore d’une API en cours de suppression, suivez cette liste :

1. Découvrez ce qui l’appelle réellement. Entra propose deux recommandations, « Migrer les applications » et « Migrer les principaux de service », qui indiquent les utilisations réelles d’Azure AD Graph observées dans votre tenant au cours des 30 derniers jours. Cela est bien supérieur aux suppositions basées sur le code source.
2. Cartographiez les permissions de manière explicite. Les permissions obsolètes ne se traduisent pas un par un en scopes Graph. Faites appel aux références officielles de Microsoft pour la correspondance des permissions, plutôt que de supposer que deux scopes ayant des noms similaires sont équivalents.
3. Transférer l’authentification vers MSAL. Tout ce qui utilise encore l’ancienne bibliothèque d’authentification Azure AD (ADAL) doit être migré séparément, car ADAL n’est plus pris en charge depuis des années.
4. Changer les SDK, pas seulement les URLs. Les SDK officiels Graph pour .NET, JavaScript et TypeScript, Python, Java, Go et PowerShell gèrent automatiquement le regroupement des requêtes, les tentatives de réessai et la pagination. Évitez d’écrire manuellement des appels HTTP sauf si c’est absolument nécessaire.
5. Faire attention aux versions bêta. Si une fonctionnalité n’est disponible que sur l’endpoint Graph beta, son interface peut changer à tout moment. Prévoyez cela ou attendez que la fonctionnalité soit disponible en version générale.
6. Détecter les erreurs 429 en environnement de test. Effectuez des tests de charge avec des volumes de requêtes réalistes afin de rencontrer les limites de throttling avant vos utilisateurs.
7. Inscrivez la date limite réelle dans votre calendrier, et vérifiez-la contre la documentation en ligne de Microsoft juste avant de vous y fier. Ces dates ont déjà changé par le passé, il convient donc de considérer toute date que vous obtenez indirectement, y compris celle indiquée sur cette page, comme provisoire.

Graph est également l’outil de gestion des agents IA

Il existe une autre raison pour laquelle cet écart continue de s’agrandir. Graph devient le plan de contrôle de l’écosystème des agents IA de Microsoft. En 2026, Microsoft a ajouté des points de terminaison Graph pour gérer les agents et applications Copilot de Microsoft 365, tenir un inventaire des agents, et obtenir des rapports plus détaillés sur l’utilisation de Copilot, ainsi que des fonctionnalités liées à des licences plus récentes comme Agent 365. Rien de tout cela n’existe sur Azure AD Graph, Outlook REST ou EWS, et cela n’existera jamais. Si votre organisation envisage de développer des extensions Copilot ou des agents personnalisés, c’est encore un chemin qui mène uniquement à Graph.

Où cela vous mène

La question posée dans le titre a une réponse assez claire en 2026 :

• Vous lancez quelque chose de nouveau sur Microsoft 365 ou Entra ID ? Utilisez Microsoft Graph. Il n’existe plus de cas où un projet nouveau devrait être initié via une API REST spécifique à un service obsolète.
• Vous maintenez une intégration plus ancienne ? Comparez-la avec le tableau de statut ci-dessus. Si elle fait appel à Azure AD Graph, Outlook REST, des compléments SharePoint basés sur ACS ou à un accès EWS de tierce partie, vous êtes confronté à des délais à respecter, certains d’entre eux étant très proches.
• Vous manquez d’une fonctionnalité SharePoint dans Graph ? Utilisez SharePoint REST uniquement pour cette requête spécifique et conservez tout le reste sur Graph.

En 2018, lorsque Microsoft faisait réellement fonctionner plusieurs interfaces REST concurrentes en même temps, le débat « REST API ou Graph » était tout à fait pertinent. Aujourd’hui, il s’agit principalement de mise en ordre. La consolidation est presque achevée, et les alternatives n’ont plus beaucoup de temps devant elles.