Si vous avez déjà exécuté un script pour rechercher, copier ou synchroniser des fichiers dans SharePoint, vous avez peut-être déjà rencontré ce problème : soudain, les requêtes se bloquent et vous obtenez des messages d'erreur à la place des résultats. Vous êtes en train de copier des supports pédagogiques ou de travailler de manière ultra-efficace dans SharePoint avec trois navigateurs. Et soudain, vous vous retrouvez face à une page blanche.
Microsoft appelle cela du « throttling » ; il ne s'agit pas d'un bug, mais d'une mesure de sécurité délibérée mise en place par le service.
Qu'est-ce que la limitation de débit exactement ?
SharePoint Online limite le nombre d'appels API et d'opérations que vous pouvez effectuer au cours d'une période donnée. Cela permet de garantir la rapidité et la fiabilité du service pour tous les utilisateurs, même lorsqu'une application individuelle envoie soudainement un nombre beaucoup trop élevé de requêtes.
Si vous dépassez cette limite, SharePoint Online réagit de deux manières. Si vous travaillez directement dans le navigateur, vous êtes redirigé vers une page d'avertissement et votre action échoue. Si vous utilisez Microsoft Graph, CSOM ou REST, vous recevez un code d'erreur 429 (« Too many requests ») ou 503 (« Server Too Busy »). Pour ces deux codes d'erreur, SharePoint envoie un en-tête « Retry-After » qui indique le délai d'attente avant de pouvoir réessayer. Important à savoir : les requêtes refusées comptent également dans votre quota. Si vous ignorez ce délai d'attente, vous risquez d'être soumis à des restrictions encore plus strictes.
Si une application continue de dépasser systématiquement les limites, Microsoft peut la bloquer complètement. L'application n'affichera alors plus que le code d'erreur 503, et le locataire en sera informé via le Centre de notifications d'Office 365.
Qui est le plus exposé au risque ?
Pour un utilisateur lambda travaillant de manière interactive dans SharePoint, la limitation de débit est rare. Dans la plupart des cas, cela concerne du code personnalisé : des composants Web personnalisés, des affichages de listes complexes, des outils de synchronisation ou des scripts traitant de grandes quantités de données. Le fait de faire tourner simultanément plusieurs processus de synchronisation sur différents appareils peut également suffire à atteindre une limite.
Microsoft applique à cet égard des limites à différents niveaux : par utilisateur, par locataire et par application. Un utilisateur peut par exemple effectuer au maximum 3 000 requêtes toutes les cinq minutes, tandis que les applications au sein d'un locataire se voient attribuer un quota d'unités de ressources qui dépend du nombre de licences. Les heures de pointe au bureau ou à l'école augmentent en outre le risque de ralentissement, tandis que la nuit et le week-end, la capacité est généralement plus importante.
Comment éviter la limitation de débit ?
Microsoft formule quelques recommandations concrètes à l'intention de ceux qui développent ou gèrent eux-mêmes des applications qui communiquent avec SharePoint :
- Limitez le nombre de requêtes simultanées et évitez les pics soudains de trafic.
- Dans la mesure du possible, privilégiez Microsoft Graph plutôt que CSOM ou REST. Graph est l'API la plus récente et consomme généralement moins de ressources pour une même opération.
- Tenez compte de l'en-tête « Retry-After » et des nouveaux en-têtes « RateLimit », qui vous indiquent à l'avance à quel point vous êtes proche de votre limite.
- Veillez à ce que votre trafic soit identifiable : enregistrez un AppID et un AppTitle pour votre application et ajoutez une chaîne User-Agent correcte. Le trafic non identifiable bénéficie d'une priorité moindre que le trafic qui s'identifie correctement.
- Pour analyser de grandes quantités de fichiers, privilégiez les requêtes delta avec un jeton. Non seulement cette méthode est plus efficace, mais elle consomme également moins de ressources par appel.
Et si ça tournait mal ?
Si votre établissement scolaire ou votre organisation se retrouve bloqué, cela est dû à un trafic excessif, prolongé et structurel. Microsoft vous en informe toujours via le Centre de messages, en précisant la cause du problème et en indiquant qui vous devez contacter pour lever le blocage.
Pour les établissements scolaires qui exécutent eux-mêmes des outils ou des scripts sur SharePoint ou OneDrive, par exemple à des fins de reporting, de sauvegarde ou d'automatisation, il est donc utile de vérifier si ceux-ci sont conformes aux recommandations de Microsoft. Vous éviterez ainsi qu'un outil pratique ne provoque soudainement des ralentissements pour l'ensemble de l'organisation.
Pour plus d'informations :
Avoid getting throttled or blocked in SharePoint Online | Microsoft Learn
