Partager via

Éviter d’être limité ou bloqué dans SharePoint Online

Découvrez la limitation dans SharePoint Online et découvrez comment éviter d’être limité ou bloqué.

Est présent familier ? Vous exécutez une application ( par exemple, pour analyser des fichiers dans SharePoint Online), mais vous êtes limité. Ou pire encore, vous êtes bloqué. Que se passe-t-il et quelles sont les possibilités pour faciliter l'arrêter ?

Qu’est-ce que la limitation ?

SharePoint Online utilise la limitation pour maintenir les performances et la fiabilité optimales du service SharePoint Online. La limitation limite le nombre d’appels ou d’opérations d’API dans une fenêtre de temps pour éviter la surutilisation des ressources.

Remarque

Les mises à jour récentes apportées à cet article améliorent la transparence des règles de limitation existantes dans le système

Que se passe-t-il lorsque vous obtenez limitées dans SharePoint Online ?

Lorsque les limites d’utilisation sont dépassées, SharePoint Online limite les demandes supplémentaires de ce client pendant une courte période.

Pour les demandes effectuées par un utilisateur directement dans le navigateur, SharePoint Online vous redirige vers la page d’informations sur les limitations et les demandes échouent.

Pour les requêtes effectuées par une application, y compris les appels Microsoft Graph, CSOM ou REST, SharePoint Online retourne le code HTTP status 429 (« Trop de requêtes ») ou 503 (« Serveur trop occupé »), et les requêtes échouent.

  • HTTP 429 indique que l’application appelante a envoyé trop de demandes dans une fenêtre de temps et a dépassé une limite prédéterminée.
  • HTTP 503 indique que le service n’est pas prêt à gérer la demande. La cause courante est que le service rencontre davantage de pics de charge temporaires.

Dans les deux cas, un Retry-After en-tête est inclus dans la réponse, indiquant la durée pendant laquelle l’application appelante doit attendre avant de réessayer ou d’effectuer une nouvelle demande. Les demandes limitées étant comptabilisées dans les limites d’utilisation, le fait de ne pas respecter Retry-After peut entraîner davantage de limitation.

Si l’application incriminée continue de dépasser les limites d’utilisation, SharePoint Online peut bloquer complètement l’application ou des modèles de demande spécifiques de l’application ; Dans ce cas, l’application continue d’obtenir le code d’état HTTP 503 et Microsoft informe le locataire du bloc dans l’Centre de messages Office 365.

Unités de ressources

Certaines limites sont mesurées en termes de coûts d’API. Les API Microsoft Graph ont un coût d’unité de ressource prédéterminé par demande :

Unités de ressources par demande Opérations
1
  • Requête d’élément unique, telle que l’obtention d’un élément
  • Delta avec un jeton
  • Télécharger le fichier à partir d’un élément de lecteur
    		•
    2
  • Requête multi-élément, telle que les enfants de liste, à l’exception de delta avec un jeton
  • Créer, mettre à jour, supprimer et charger
    		•
    5
  • Toutes les opérations de ressources d’autorisation, y compris $expand=permissions
    		•

    Remarque

    Nous nous réservons le droit de modifier le coût unitaire de la ressource API.

    Limitation d'utilisateurs

    La limitation limite le nombre d’appels et d’opérations effectués collectivement par les applications pour le compte d’un utilisateur afin d’éviter la surutilisation des ressources.

    Cela dit, il est rare qu’un utilisateur soit limité dans SharePoint Online. Le service est robuste et il est conçu pour gérer un volume élevé. Si vous êtes limité, 99 % du temps, cela est dû à du code personnalisé, tel que des composants WebPart personnalisés, des affichages de liste et des requêtes complexes, ou des applications personnalisées exécutées par les utilisateurs. Cela ne signifie pas qu'il n'existe pas d'autres moyens de se faire étrangler, mais qu'ils sont moins courants. Par exemple, un utilisateur synchronisant une grande quantité de données sur 10 ordinateurs en même temps peut déclencher une limitation.

    Catégorie Type de limitation Intervalle de temps Limite
    Utilisateur Requêtes 5 min 3,000
    Utilisateur Entrée 1 H 50 Go
    Utilisateur Sortie 1 H 100 Go
    Utilisateur Demande de jeton de délégation 5 min 50
    Utilisateur E-mails de partage externe 1 H 200

    Remarque

    Les limites affichées sont des valeurs par défaut. Microsoft peut modifier ces limites à tout moment. Votre expérience peut varier

    Limitation des locataires

    Certaines limites de limitation sont appliquées au niveau du locataire pour garantir que les opérations effectuées collectivement ne surutilisent pas les ressources.

    Lorsqu’un client active multigéographique, chaque zone géographique obtient ses propres limites (mesure d’utilisation non partagée entre les zones géographiques). Pour les limites qui dépendent du nombre de licences, le nombre total de licences utilisateur client est utilisé (nombre total d’utilisateurs sur toutes les zones géographiques).

    Catégorie Type de limitation Intervalle de temps Nombre de licences clientes Limite
    Tenant Unités de ressources 5 min 0 - 1,000 18,750
    Tenant Unités de ressources 5 min 1,001 - 5,000 37,500
    Tenant Unités de ressources 5 min 5,001 - 15,000 56,250
    Tenant Unités de ressources 5 min 15,001 - 50,000 75,000
    Tenant Unités de ressources 5 min 50,000+ 93,750
    Tenant Attribuer une étiquette de confidentialité 5 min aucune licence liée 100
    Tenant PeopleManagerAPIs 5 min 0 - 1,000 3,000
    Tenant PeopleManagerAPIs 5 min 1,001 - 5,000 6 000
    Tenant PeopleManagerAPIs 5 min 5,001 - 15,000 9,000
    Tenant PeopleManagerAPIs 5 min 15,001 - 50,000 12,000
    Tenant PeopleManagerAPIs 5 min 50,000+ 15 000

    Remarque

    Les limites affichées sont des valeurs par défaut. Microsoft peut modifier ces limites à tout moment. Votre expérience peut varier

    Limitation de l’application

    Outre la limitation par compte d’utilisateur, des limites sont également appliquées aux applications dans un locataire.

    Chaque application a ses propres limites dans un locataire, qui sont basées sur le nombre de licences achetées par organisation (voir les plans répertoriés dans les limites SharePoint pour les licences incluses). Chaque requête effectuée par une application sur tous les points de terminaison d’API, y compris Microsoft Graph, CSOM et REST, compte pour l’utilisation de l’application.

    SharePoint fournit différentes API. Différentes API ont des coûts différents en fonction de la complexité de l’API. Le coût des API est normalisé par SharePoint et exprimé par unités de ressources. Les limites de l’application sont également définies à l’aide d’unités de ressources.

    Pour les applications multilocataires :

    1. Chaque locataire hébergeant l’application est considéré comme distinct, fonctionnant indépendamment des autres. Par conséquent, chaque application est soumise à ses propres limites d’utilisation au sein de chaque locataire, comme défini ci-dessus.
    2. La consommation d’unités de ressources par l’application doit être mesurée par locataire et par application. Cela garantit que chaque paire client-application reste dans les limites de ressources autorisées spécifiées pour ce locataire particulier.
    3. Si l’application atteint sa limite de ressources au sein d’un locataire, cette occurrence n’affectera pas les autres instances de l’application fonctionnant dans différents locataires. L’utilisation des ressources de chaque locataire est isolée, ce qui empêche l’impact interlocataire.
    Catégorie Type de limitation Intervalle de temps Nombre de licences clientes Limite
    Par application par locataire Unités de ressources 24 H 0 - 1,000 1 200 000
    Par application par locataire Unités de ressources 24 H 1,001 - 5,000 2 400 000
    Par application par locataire Unités de ressources 24 H 5,001 - 15,000 3 600 000
    Par application par locataire Unités de ressources 24 H 15,001 - 50,000 4,800,000
    Par application par locataire Unités de ressources 24 H 50,000+ 6 000 000
    Par application par locataire Unités de ressources 1 min 0 - 1,000 1,250
    Par application par locataire Unités de ressources 1 min 1,001 - 5,000 2 500
    Par application par locataire Unités de ressources 1 min 5,001 - 15,000 3,750
    Par application par locataire Unités de ressources 1 min 15,001 - 50,000 5,000
    Par application par locataire Unités de ressources 1 min 50,000+ 6,250
    Par application par locataire Entrée 1 H aucune licence liée 400 Go
    Par application par locataire Sortie 1 H aucune licence liée 400 Go
    Par application par locataire API de partage spécifiques 5 min aucune licence liée 300

    Remarque

    Les limites affichées sont des valeurs par défaut. Microsoft peut modifier ces limites à tout moment. Votre expérience peut varier

    Autres limites

    Catégorie Type de limitation Intervalle de temps Limite
    Conteneurs SharePoint Embedded Unités de ressources 1 min 3,000
    Par site Lien anonyme 5 min 3,000
    Par site Sortie anonyme (télécharger) 2 H 100 Go
    Par site E-mails de partage externe 1 H 200

    Remarque

    Les limites affichées sont des valeurs par défaut. Microsoft peut modifier ces limites à tout moment. Votre expérience peut varier

    Comment gérer la limitation ?

    Voici un résumé rapide des meilleures pratiques pour gérer la limitation :

    • Réduire le nombre de demandes simultanées
    • Éviter les pics de demande
    • Choisissez les API Microsoft Graph sur CSOM et LES API REST lorsque cela est possible
    • Utilisez les en-têtes HTTP Retry-After et RateLimit
    • Décorez votre trafic afin que nous sachions qui vous êtes (voir la section sur les meilleures pratiques en matière de décoration de trafic, plus d’informations à ce sujet ci-dessous)
    • Envisagez d’utiliser Graph Data Connect pour SharePoint pour l’analytique de site à grande échelle
    • Comprendre si la hiérarchisation des services dans SharePoint est adaptée à votre scénario

    Comme indiqué précédemment, Microsoft Graph est des API cloud qui disposent des dernières améliorations et optimisations. En général, Microsoft Graph consomme moins de ressources que CSOM et REST pour obtenir les mêmes fonctionnalités. Par conséquent, l’adoption de Microsoft Graph peut améliorer les performances de l’application et réduire la limitation.

    Si vous rencontrez une limitation, nous avons besoin de l’en-tête HTTP Retry-After pour garantir un délai minimal jusqu’à ce que la limitation soit supprimée. Les RateLimit en-têtes HTTP vous envoient des signaux précoces lorsque vous êtes proche des limites, et vous pouvez réduire de manière proactive les requêtes pour éviter d’atteindre la limitation.

    Delta avec un jeton est le moyen le plus efficace d’analyser le contenu dans SharePoint, et nous parlons plus en détail des meilleures pratiques d’analyse des applications. Pour aider les applications qui suivent les instructions, nous réduisons le coût de l’unité de ressources des demandes delta avec un jeton à 1 unité de ressources, bien qu’il s’agisse d’une requête à plusieurs éléments. La requête delta sans jeton est considérée comme une requête multi-élément et coûte 2 unités de ressources par demande.

    Dans le traitement par lots, les demandes d’un lot sont évaluées individuellement par unités de ressources.

    CSOM et REST n’ont pas de coût d’unité de ressource prédéterminé, et ils consomment généralement plus d’unités de ressources que les API Microsoft Graph pour obtenir les mêmes fonctionnalités. En plus des limites d’unités de ressources, CSOM et REST sont également soumis à d’autres limites de ressources internes. Par conséquent, si les applications appellent CSOM et REST, elles peuvent subir une limitation plus importante que les limites décrites dans ce document. Nous vous recommandons vivement de choisir les API Microsoft Graph plutôt que les API CSOM et REST lorsque cela est possible.

    Étant donné que les limites d’application sont en unités de ressources, le taux de requêtes réel, par exemple les requêtes par minute, dépend du choix de l’API de l’application et du coût d’unité de ressource d’API correspondant. En général, vous pouvez estimer le taux de demandes à l’aide d’une moyenne de 2 unités de ressources par demande et diviser les limites d’unités de ressources par 2 pour obtenir le taux de demandes estimé.

    Bien que chaque application ait ses limites au sein d’un locataire et que nous permettons aux locataires d’exécuter plusieurs applications, plusieurs applications exécutées sur le même locataire partagent le même compartiment de ressources et, dans de rares cas, peuvent entraîner une limitation du débit quand un trop grand nombre d’applications envoient des demandes à la fois.

    En-tête Retry-after

    Lorsque les applications rencontrent une limitation, SharePoint Online retourne un en-tête HTTP Retry-After dans la requête indiquant la durée en secondes pendant laquelle l’application appelante doit attendre avant de réessayer ou d’effectuer une nouvelle demande.

    Le respect de la Retry-After en-tête HTTP est le moyen le plus rapide de gérer les limitations, car SharePoint Online détermine dynamiquement le bon moment pour réessayer.

    Les demandes limitées étant comptabilisées dans les limites d’utilisation, le fait de ne pas respecter Retry-After peut entraîner davantage de limitation. En d’autres termes, les nouvelles tentatives agressives fonctionnent contre les applications appelantes, car même si les appels échouent, ils comptent toujours dans les limites d’utilisation. Le respect de l’en-tête HTTP Retry-After garantit le délai le plus court et réduit les quotas de perte dans les requêtes limitées.

    En-têtes RateLimit - préversion

    En plus de l’en-tête Retry-After dans la réponse aux demandes limitées, SharePoint Online renvoie également les en-têtes RateLimit IETF pour les limites sélectionnées dans certaines conditions afin d’aider les applications à gérer la limitation de débit. Nous recommandons aux applications de tirer parti de ces en-têtes pour éviter d’atteindre la limitation.

    • RateLimit-Limit contient la limite dans la fenêtre de temps actuelle.
    • RateLimit-Remaining indique le quota restant dans la fenêtre active.
    • RateLimit-Reset indique le nombre de secondes jusqu’à ce que le quota soit réapprovisionné.

    Remarque

    Ces en-têtes sont actuellement en version bêta et peuvent être modifiés. Au moment de l’adoption des en-têtes, la spécification IETF était en brouillon. L’implémentation actuelle est basée sur le brouillon-03 de la spécification IETF. Il est possible que des modifications soient apportées lorsque la spécification est finale, et nous nous adapterons à ces modifications à l’avenir.

    Les en-têtes RateLimit sont retournés sur la base des meilleurs efforts, de sorte que les applications peuvent ne pas recevoir les en-têtes dans toutes les conditions. En outre, il existe d’autres limites qui ne sont pas présentées dans les en-têtes RateLimit , de sorte que les applications peuvent être limitées même avant d’atteindre la limite décrite dans les en-têtes RateLimit . Voici la liste des limites pour lesquelles nous prenons en charge les en-têtes RateLimit. Les stratégies et les valeurs sont susceptibles d’être modifiées :

    limit Condition valeur limite Description
    Unité de ressource d’application de 1 minute Utilisation >= 80 % de la limite Unité de ressources Lorsqu’une application consomme 80 % ou plus de sa limite d’application d’une minute, la limite restante et la réinitialisation sont retournées.

    Voici quelques exemples pour vous aider à comprendre les en-têtes RateLimit :

    • Une application a consommé 90 % de son quota d’unités de ressources (1 080 sur 1 200) et sa consommation est comprise dans toutes les limites qui s’y appliquent. La demande réussit et les en-têtes RateLimit sont retournés.

      HTTP/1.1 200 Ok
RateLimit-Limit: 1200
RateLimit-Remaining: 120
RateLimit-Reset: 5

    • Une application a consommé 100 % de son quota d’unités de ressources. Elle est donc limitée en raison de cette stratégie. La requête est limitée et les RateLimit en-têtes sont retournés. Le Retry-After correspond au RateLimit-Reset. Il existe des cas où retourne Retry-After une valeur plus petite. Dans ce cas, la règle générale est d’honorer la plus grande des deux valeurs.

      HTTP/1.1 429 Too Many Requests
Retry-After: 31
RateLimit-Limit: 1200
RateLimit-Remaining: 0
RateLimit-Reset: 31

    • Une application a consommé 90 % de son quota d’unités de ressources, mais sa consommation a déjà atteint d’autres limites que les RateLimit en-têtes ne prennent pas en charge. Dans ce cas, la requête est limitée et les RateLimit en-têtes ne sont pas retournés pour éviter toute confusion, bien que la condition de renvoi des en-têtes soit remplie.

      HTTP/1.1 429 Too Many Requests
Retry-After: 9

    Pour plus d’informations, consultez Empêcher la limitation dans votre application à l’aide des en-têtes RateLimit dans SharePoint Online

    Comment décorer votre trafic HTTP ?

    Le trafic correctement décoré sera prioritaire sur le trafic qui n’est pas correctement décoré.

    Quelle est la définition du trafic non corrigé ?

    • Le trafic n’est pas corrigé s’il n’existe aucune chaîne AppID/AppTitle et User Agent dans les appels d’API à SharePoint Online. La chaîne User-Agent doit être dans un format spécifique, comme décrit ci-dessous.
    • Si vous développez une application web qui s’exécute dans le navigateur, la plupart des navigateurs modernes n’autorisent pas le remplacement de la chaîne de l’Agent utilisateur et vous n’avez pas besoin de l’implémenter.

    Quelles sont les recommandations ?

    • Si vous avez créé une application, la recommandation est de vous inscrire et utiliser AppID et AppTitle. Cette option garantit la meilleure expérience globale et le meilleur parcours pour toute résolution de problème futurs. Incluez également les informations de chaîne de l’agent utilisateur, comme défini à l’étape suivante.

      Remarque

      Référez-vous à la Documentation sur l’identité de Microsoft, telle que la page Démarrage rapide : Inscrire une application avec la plateforme d’identités Microsoft pour obtenir des informations sur la création d’une application Azure AD.

    • Veillez à inclure la chaîne User-Agent dans votre appel d’API à SharePoint avec la convention d’affectation de noms suivante

    Type Agent utilisateur Description
    Application ISV ÉDITEUR DE LOGICIELS|CompanyName|AppName/Version Identifiez en tant qu’éditeur de logiciels indépendants et incluez le nom de la société, le nom de l’application séparé par un caractère de canal, puis ajoutez le numéro de version séparé par une barre oblique
    Application d’entreprise NONISV|CompanyName|AppName/Version S’identifier en tant que NONISV et inclure le nom de la société, nom de l’application séparées par un caractère de canal, puis ajoutez le numéro de version séparé par un caractère barre oblique
    • Si vous créez vos propres bibliothèques JavaScript, qui sont utilisées pour appeler des API SharePoint Online, veillez à inclure les informations User-Agent à votre requête HTTP et à inscrire éventuellement votre application web en tant qu’application, le cas échéant.

    Remarque

    Le format de la chaîne de l’agent utilisateur étant censé suivre RFC2616, suivez les instructions ci-dessus sur les séparateurs appropriés. Il est également bon d’ajouter la chaîne d’agent utilisateur existante avec les informations demandées.

    Scénarios de limitation courants dans SharePoint Online

    Les causes les plus courantes de limitation dans SharePoint Online par l'utilisateur sont le modèle objet côté client (CSOM) ou Representational State Transfer (REST) du code qui effectue des actions trop trop souvent.

    • Trafic occasionnel

      Une charge constante ou des requêtes complexes répétitives sur SharePoint Online doivent être optimisés pour un faible impact. Ne pas suivre les meilleures pratiques pour obtenir la numérisation des applications qui traitent des fichiers en bloc est susceptible de provoquer une limitation. Ces applications incluent des moteurs de synchronisation, des fournisseurs de sauvegarde, des indexeurs de recherche, des moteurs de classification, des outils de protection contre la perte de données et tout autre outil qui tente de raisonner sur l’intégralité des données et d’y appliquer des modifications.

    • Trafic fastidieuse

      Un processus unique dépasse considérablement les limites de limitation, continuellement, sur une longue période.

      • Services web vous permet de créer un outil pour synchroniser les propriétés de profil utilisateur. L'outil met à jour les propriétés de profil utilisateur en fonction des informations à partir de votre système de ressources humaines (RH) de métier (LOB). L'outil effectue des appels à une fréquence de trop élevée.
      • Vous exécutez un script de test de charge sur SharePoint Online et vous êtes limité. Le test de charge n’est pas autorisé sur SharePoint Online.
      • Vous avez personnalisé votre site d'équipe sur SharePoint Online, par exemple, en ajoutant un indicateur d'état de la page d'accueil. Cet indicateur d'état des mises à jour fréquemment, qui provoque la page à rendre trop grand nombre d'appels au service SharePoint Online - cela déclenchée limitation.
      • L'exécution du client OneDrive synchronisation en même temps que des applications de migration ou des applications qui explorent des sites et réécrivent des données peut entraîner des volumes de demandes élevés susceptibles de déclencher un étranglement.

    • Cas d’utilisation non pris en charge

      L’utilisation non prise en charge de SharePoint Online peut entraîner une limitation. L’utilisation de SharePoint et OneDrive comme service intermédiaire entre Microsoft 365 et un autre référentiel est un exemple de cas d’utilisation non pris en charge.

    • La création de plusieurs ID d’application pour la même application

      Ne créez pas d’AppID distincts où les applications effectuent essentiellement les mêmes opérations, telles que la sauvegarde ou la protection contre la perte de données. Les applications qui s’exécutent sur le même locataire partagent finalement les mêmes ressources que le locataire. Historiquement, certaines applications ont essayé cette approche pour contourner la limitation des applications, mais ont fini par épuiser la ressource du locataire et entraîner la limitation de plusieurs applications dans le locataire.

    Limites spécifiques au scénario

    Lors de l’authentification dans l’application uniquement avec l’autorisation Sites.Read.All

    Lorsque vous utilisez des API de recherche SharePoint Online avec une authentification d’application uniquement et que l’application dispose de l’autorisation Sites.Read.All (ou plus forte), l’application est inscrite avec des autorisations complètes et est autorisée à interroger tout votre contenu SharePoint Online (y compris le contenu OneDrive Entreprise privé de l’utilisateur).

    Pour garantir que le service reste rapide et fiable, les requêtes utilisant cette autorisation sont limitées à 25 requêtes par seconde. La requête de recherche retourne une réponse HTTP 429. Lorsque vous attendez la récupération de la limitation, vous devez vous assurer de suspendre toutes les requêtes de recherche que vous pouvez envoyer au service à l’aide d’une autorisation d’application uniquement similaire. L’exécution d’appels supplémentaires lors de la réception de réponses de limitation étend le temps nécessaire à l’annulation de la limitation de votre application.

    Lors de la recherche à l’aide d’autorisations d’utilisateur déléguées

    La recherche avec des autorisations d’utilisateur déléguées se produit lorsqu’une application envoie une demande de requête de recherche avec les autorisations de l’utilisateur connecté. Voici quelques exemples de demandes déléguées : la zone de recherche d’une page SharePoint, un composant WebPart basé sur la recherche ou une application personnalisée incorporée dans une page SharePoint, et une requête de flux de travail Power Automate pour les informations d’élément.

    Pour garantir la stabilité du service, le service limite les demandes d’utilisateur déléguées qui dépassent 10 demandes par seconde et par utilisateur. Cette limite par utilisateur limite les agrégats pour toutes les demandes de toutes les applications. Si un seul utilisateur envoie plus de 10 requêtes de recherche par seconde, une requête HTTP 429 est retournée. L’application demandeuse doit attendre la durée du délai d’expiration spécifié dans l’en-tête de réponse avant d’envoyer les demandes suivantes. Lors de la conception d’applications basées sur la recherche, de pages SharePoint et de flux de travail, les implémenteurs doivent s’assurer que la page et l’application ne dépassent pas 10 demandes par seconde au total et gèrent 429 réponses de limitation. Pour plus d’informations et de conseils sur la conception de page et l’optimisation de la recherche, voir Optimiser les demandes de recherche dans les pages de site moderne SharePoint Online et Utiliser l’outil Diagnostics de page pour SharePoint Online.

    Lors de la recherche des résultats de recherche de personnes

    Lors d’une recherche à l’aide d’une source de résultats qui demande des résultats à des personnes, nous pouvons limiter toutes les demandes dépassant une limite de 25 requêtes par seconde organization. Cette limite s’applique à toutes les requêtes CSOM et REST de recherche SharePoint à l’aide de la source de résultats « Résultats de la Personnes locale » prête à l’emploi ou d’une source de résultats de recherche de personnes personnalisée.

    Si vous avez des applications ou des composants qui entraînent la limitation de vos demandes de recherche de personnes, nous vous recommandons de :

    1. Déterminez si les demandes sont nécessaires pour votre application. Par exemple, si vous utilisez un site de recherche personnalisé, qui effectue de nombreuses requêtes simultanées, case activée si certaines de ces requêtes peuvent être supprimées sans impact significatif sur l’expérience de recherche de votre organization. Vous pouvez également essayer notre expérience de recherche de personnes moderne dans Recherche Microsoft en effectuant une recherche à partir de la page de démarrage SharePoint. La recherche de personnes dans Recherche Microsoft a été optimisée pour de meilleures performances et des résultats plus pertinents.
    2. Évitez d’effectuer des demandes simultanées. Par exemple, au lieu d’émettre 10 requêtes en même temps, émettez-les de façon consécutive. N’émettez la requête suivante qu’une fois la requête précédente terminée. Vous devrez peut-être mettre en cache ces résultats si vous en avez besoin rapidement, par exemple un chargement de page.
    3. Essayez de consolider les requêtes en une seule requête. Par exemple, au lieu d’effectuer 10 requêtes simultanées pour WorkEmail:user1@constoso.com, WorkEmail:user2@constoso.com,..., WorkEmail:user10@contoso.com, essayez la requête unique, WorkEmail:user1@constoso.com WorkEmail:user2@constoso.com ... WorkEmail:user10@contoso.com.
    4. Envisagez d’utiliser l’API Microsoft Graph si un scénario à volume élevé de demandes (plus de 25 demandes par seconde) est vraiment nécessaire.

    Lors de l’accès aux sites OneDrive

    Lorsqu’un client effectue des tentatives excessives d’accès à de nombreuses collections de sites OneDrive qui n’existent pas, nous pouvons limiter les demandes à partir de l’adresse IP de ce client. Le client reçoit une réponse HTTP 429 lors de l’accès à une collection de sites OneDrive pendant la période de limitation.

    Clients multigéographiques et limitation

    Lorsqu’un client active la limitation, chacun obtient ses propres limites (mesure d’utilisation non partagée entre les zones géographiques). Pour les limites qui dépendent du nombre de licences, le nombre total de licences utilisateur client est utilisé (nombre total d’utilisateurs sur toutes les zones géographiques).

    Que faire si vous êtes bloqué dans SharePoint Online ?

    Le blocage est la forme la plus extrême de limitation. Nous bloquons rarement un locataire, sauf si nous détectons un trafic excessif à long terme susceptible de compromettre l’intégrité globale du service SharePoint Online. Un blocage est appliqué pour empêcher que ce trafic nuise aux performances et à la fiabilité de SharePoint Online. Un blocage placé au niveau du client ou de l’application, empêche le processus en cause d’être exécuté jusqu’à ce que vous corrigiez le problème. Si nous bloquons votre abonnement, vous devez intervenir et modifier les processus en cause pour que le blocage soit levé.

    Si nous bloquons votre abonnement, nous vous informerons du blocage dans l’Centre de messages Office 365. Le message décrit la cause de la limitation, fournit des instructions sur la façon de résoudre le problème et vous donne les coordonnées de la personne à contacter pour que la limitation soit levée.

    Voir aussi