Throttling SharePoint Online : comprendre l’erreur 429 pendant une migration
Toute migration SharePoint finit par rencontrer le throttling. Ce n’est pas une panne : c’est SharePoint qui protège le tenant. La question est de perdre le moins de temps possible.
En bref
SharePoint Online répond 429 (trop de requêtes) ou 503 (serveur occupé) avec un en-tête Retry-After quand un utilisateur, une application ou un tenant dépasse son quota. Il faut attendre exactement ce délai, réduire la concurrence, puis remonter lentement : relancer trop tôt prolonge le blocage.
Ce que SharePoint renvoie
- 429 Too Many Requests : le quota de requêtes est dépassé.
- 503 Server Too Busy : le service est chargé ; même traitement.
- Retry-After : le nombre de secondes à attendre avant la prochaine requête.
Les quotas s’appliquent à l’utilisateur, à l’application et au tenant. Point souvent ignoré : les adresses contoso.sharepoint.com, contoso-my.sharepoint.com (les OneDrive) et contoso-admin.sharepoint.com partagent le même quota. Migrer des sites et des OneDrive en parallèle ne double pas le débit.
Ce que nous avons mesuré
Sur une migration dans un même tenant, le 7 octobre 2026, nous avons relevé 13 épisodes de throttling en 35 minutes, avec des pauses de 35 à 150 secondes demandées par SharePoint. Les sites et les OneDrive du tenant ont été freinés à 0,4 seconde d’écart : la preuve d’un quota commun.
Le coût ne venait pas des pauses elles-mêmes, mais du cycle : remonter à pleine vitesse en une minute, être freiné de nouveau quelques minutes plus tard, repartir pour une longue pause.
La bonne réaction
- Respecter le Retry-After à la secondeRelancer plus tôt renvoie un nouveau 429, compte dans le quota et allonge le blocage. Toutes les requêtes vers le tenant s’arrêtent pendant la pause, pas seulement celle qui a été refusée.
- Diviser la concurrence par deux, une foisLes requêtes en vol reçoivent souvent leur 429 ensemble : elles ne comptent que pour un épisode.
- Ne pas revenir au rythme refuséFixer un plafond temporaire un cran sous le niveau qui a déclenché le throttling.
- Remonter lentementUne requête simultanée de plus toutes les 30 secondes sans refus, et le plafond relâché d’un cran toutes les 10 minutes.
- Rejouer la même requêteSans la reconstruire, pour que l’opération reprenne exactement où elle s’est arrêtée.
C’est ce que fait Tauri Migration, avec un seul « portail » par tenant pour les sites, les OneDrive et l’administration. Le journal affiche une ligne par épisode, par exemple : Throttling sur contoso.sharepoint.com : pause de 30 s demandée par le serveur, concurrence 4 → 2 (remontée jusqu’à 3 au plus).
Aller plus vite sans être freiné
| Levier | Effet |
|---|---|
| Migrer en dehors des heures ouvrées du tenant | Les utilisateurs ne consomment plus le quota commun |
| Se connecter par certificat (application seule) | Le quota d’une application remplace celui d’un utilisateur |
| Réduire les requêtes simultanées à 2 ou 3 | Moins d’épisodes, souvent plus rapide au total |
| Limiter les versions migrées | Moins d’écritures dans la cible |
| Importer les nouveaux fichiers par paquets | La SharePoint Migration API écrit côté Microsoft |
| Identifier le trafic | Microsoft recommande un User-Agent de la forme NONISV|Société|Application/Version |
Questions fréquentes
Le throttling peut-il faire échouer une migration ?
Deux postes de migration vont-ils deux fois plus vite ?
Testez sur votre propre tenant
L'essai de 14 jours migre 10 % de chaque bibliothèque, avec versions, métadonnées et permissions. Après souscription, une relance incrémentale migre le reste.