GitLab plafonne les requêtes des agents IA sur GitLab.com à partir du 19 octobre
À partir du 19 octobre 2026, GitLab.com limite les requêtes selon l’abonnement — 60 requêtes/heure par IP anonyme, 5 000/heure en Free, jusqu’à 25 000/heure en Ultimate — pour contenir la charge des agents IA et de l’automatisation. Authentifiez vos scripts et vos agents, et vérifiez vos pics avant les fenêtres de test des 7 et 14 octobre.
17 septembre 2026. GitLab annonce que les limites de débit de GitLab.com seront désormais alignées sur le niveau d’abonnement. 7 et 14 octobre 2026. Deux fenêtres de test, appelées brownouts, activeront brièvement les nouveaux plafonds de 15 h à 19 h UTC. 19 octobre 2026. Les limites entrent en vigueur pour le trafic Free et non authentifié, les paliers Premium et Ultimate suivant en janvier 2027. Pourquoi c’est important : la charge portée par les agents de codage et l’automatisation explose, et GitLab choisit de la réguler par paliers plutôt que de laisser une seule charge ralentir la plateforme pour tout le monde.
Les nouveaux plafonds, chiffrés
Le changement introduit deux limites par plan pour le trafic authentifié : une limite soutenue, mesurée à l’heure, et une limite en rafale, mesurée à la minute. C’est la limite soutenue qui gouverne l’usage au long cours.
| Plan | Limite soutenue (par heure) | Limite en rafale (par minute) |
|---|---|---|
| Non authentifié | 60 par IP | — |
| Free | 5 000 | 100 |
| Premium | 15 000 | 1 250 |
| Ultimate | 25 000 | 2 000 |
Le plafond anonyme de 60 requêtes par heure et par IP est la rupture la plus brutale : il s’applique où que vienne la requête, y compris à une automatisation qui tape sur un compte payant sans s’authentifier. La limite en rafale n’est pas un rythme tenable — envoyer au rythme maximal pendant une heure entière épuise le quota soutenu en environ 50 minutes en Free, 12 minutes en Premium et 12,5 minutes en Ultimate. En clair : la rafale est un plafond pour les pics courts, pas une cadence de croisière.
Pourquoi maintenant
La motivation tient en une phrase du billet officiel : la demande « grimpe rapidement » et la charge de la plateforme devrait « croître de plusieurs fois cette année ». Le moteur de cette croissance est nommé sans détour — l’automatisation et les charges d’agents que les équipes construisent sur la plateforme. GitLab a déjà publié des limites dédiées pour son serveur MCP, la porte d’entrée standard des agents de codage, et ce changement généralise la logique : un agent qui scrute l’API en boucle serrée consomme du quota comme un utilisateur humain, mais sans fatigue.
La comparaison assumée avec les plateformes voisines est instructive. GitLab affirme avoir fixé la limite Free et l’allocation anonyme « au niveau de la norme du secteur », tandis que Premium et Ultimate sont « plus généreux, à des niveaux que d’autres plateformes réservent à leurs paliers entreprise ou ne publient pas du tout ». Autrement dit, le plafond anonyme est volontairement punitif pour pousser les intégrations à s’authentifier, et les paliers payants sont calibrés pour ne pas pénaliser le travail humain normal.
Le signal de fond est que les agents ne sont plus une charge anecdotique. Un humain fait quelques dizaines d’appels d’API par session ; un agent de codage enchaîne des centaines de requêtes — lecture de fichier, soumission de revue, interrogation du statut d’un pipeline — sans jamais s’arrêter. GitLab avait déjà introduit des limites dédiées pour son serveur MCP, l’interface standard des agents, et cette annonce étend la même logique à toute l’API. La nouveauté n’est pas technique, elle est comptable : pour la première fois, le coût d’un agent se mesure en quota d’API, pas en siège.
L’économie du changement est assumée. GitLab abaisse de fait le palier anonyme à presque zéro — 60 requêtes par heure, c’est de quoi afficher un badge de statut, guère plus — tout en rendant les quotas Premium et Ultimate assez généreux pour que les équipes payantes n’y pensent jamais. Le message adressé à la longue traîne des scrapers non authentifiés et des agents en Free est direct : authentifiez-vous et montez de gamme, ou soyez limités.
Ce qui change concrètement pour vos pipelines
Au franchissement d’une limite, GitLab.com répond par un HTTP 429 Too Many Requests avec un en-tête Retry-After indiquant le délai d’attente, et des en-têtes RateLimit-Limit, RateLimit-Remaining et RateLimit-ResetTime sur toutes les réponses, limitées ou non. Un client qui lit ses propres en-têtes « se corrige en grande partie lui-même », note GitLab : attendre le délai de Retry-After, puis reculer exponentiellement, récupère plus vite qu’une nouvelle tentative immédiate.
Deux pièges méritent l’attention. Le premier est le CI/CD non authentifié : un script qui appelle l’API sans personal access token, sans jeton OAuth ou sans job token retombe sur l’allocation anonyme de 60 requêtes/heure. Le second est la polling en boucle : un agent qui interroge un statut toutes les secondes brûle un quota mensuel en quelques heures. GitLab conseille de regrouper les appels, de mettre en cache, de paginer et d’honorer Retry-After — et de surveiller RateLimit-Remaining pour ralentir avant l’épuisement.
Les nouveaux paliers ne remplacent pas les limites actuelles, ils s’y ajoutent. La documentation précise que « la limite la plus basse s’applique » : le trafic API authentifié reste par exemple plafonné à 2 000 requêtes par minute tous plans confondus. En Ultimate, la rafale de 2 000 par minute rejoint donc la limite existante ; en Free et Premium, c’est la rafale du plan qui frappe la première. Pour une charge d’agent, cela signifie deux étages de plafonds à surveiller, pas un.
# Lire les en-têtes de quota avant d'insister
curl -s -D - -o /dev/null \
-H "PRIVATE-TOKEN: $GITLAB_TOKEN" \
"https://gitlab.com/api/v4/user" \
| grep -iE 'ratelimit|retry-after'Les limites d’IA ne sont d’ailleurs pas nouvelles : la table actuelle plafonne déjà les requêtes GitLab Duo aiAction à 160 par tranche de huit heures, un avant-goût de la régulation par usage qui se généralise aujourd’hui.
Ce que ça ne change pas
Le périmètre est important à délimiter pour éviter la panique. Le changement ne concerne que GitLab.com : GitLab Self-Managed et GitLab Dedicated gardent des limites contrôlées par l’opérateur. Les données et dépôts restent exportables à tout moment. Et le travail humain ordinaire — naviguer dans l’interface, pousser et tirer avec git, exécuter le CI/CD dans son plan — « continue exactement comme aujourd’hui ». GitLab estime que « presque tous les utilisateurs sont déjà dans les nouvelles limites ».
Les brownouts des 7 et 14 octobre sont précisément là pour valider cette hypothèse : pendant ces fenêtres, les nouveaux plafonds sont activés puis désactivés, sans autre changement de service. C’est le moment de mesurer le comportement réel de vos charges avant la date ferme du 19 octobre.
Verdict
Si vous faites tourner des agents de codage ou de l’automatisation contre GitLab.com, authentifiez-les immédiatement avec un personal access token ou un jeton CI/CD : c’est le changement qui déplace une charge de l’allocation anonyme de 60 requêtes/heure vers le plafond de votre plan, mille fois plus élevé. Mesurez vos pics pendant les brownouts des 7 et 14 octobre, et repérez les charges Free lourdes qui toucheront le plafond soutenu. Si votre intégration ne peut authentifier que par exception légitime, écrivez à [email protected] avant la date butoir plutôt qu’après. Si vous êtes sur GitLab Self-Managed ou Dedicated, ce changement ne vous concerne pas — mais surveillez vos propres agents : la pression qui a poussé GitLab à réguler frappera aussi votre instance.