GitLab.com : les quotas d'API changent le 19 octobre

À partir du 19 octobre 2026, les quotas d'API de GitLab.com dépendront de l'abonnement souscrit. Annoncé le 17 septembre sur le blog de l'éditeur, ce changement touche d'abord les comptes gratuits et le trafic non authentifié, plafonné à 60 requêtes par heure et par adresse IP. Les offres Premium et Ultimate suivront en janvier 2027. Une dernière fenêtre de test est prévue ce mercredi 14 octobre.

Un calendrier en deux temps

GitLab explique que les limites s'appliqueront par utilisateur et par groupe de premier niveau. Le calendrier annoncé est le suivant :

• 19 octobre 2026 : comptes Free et requêtes non authentifiées ;
• janvier 2027 : abonnements Premium et Ultimate.

Un utilisateur membre de plusieurs groupes bénéficie du plafond le plus élevé auquel il a accès : appartenir à un groupe Ultimate donne droit aux limites Ultimate. Seul GitLab.com est concerné ; les instances GitLab Self-Managed et GitLab Dedicated conservent les limites fixées par leurs opérateurs.

Quels plafonds ?

Le billet d'annonce ne donne qu'un chiffre précis, celui du trafic anonyme : 60 requêtes par heure et par IP, quelle que soit l'origine de la requête, y compris une automatisation liée à un compte payant qui ne s'authentifie pas.

Pour le trafic authentifié, la documentation de GitLab.com détaille des limites par offre, présentées comme proposées et pas encore en vigueur : 5 000 requêtes par heure (rafales de 100 par minute) en Free, 15 000 par heure (1 250 par minute) en Premium et 25 000 par heure (2 000 par minute) en Ultimate. La limite horaire prime sur la limite de rafale.

Ce qui ne change pas

Selon GitLab, la navigation dans l'interface, l'éditeur, les opérations git push et git pull et l'exécution des pipelines CI/CD dans les limites de l'offre ne sont pas concernés. L'accès à ses propres données et leur export restent garantis. L'éditeur estime que la plupart des utilisateurs ne verront pas de différence, mais que les automatisations intensives et certains usages gratuits pourraient atteindre les nouveaux plafonds.

Tester avant la bascule

GitLab a programmé deux fenêtres de prévisualisation, les 7 et 14 octobre de 15 h à 19 h UTC, pendant lesquelles les nouvelles limites sont activées puis désactivées. Les requêtes authentifiées des clients Premium et Ultimate n'y sont pas soumises. C'est l'occasion de repérer les scripts, intégrations ou jobs qui interrogent l'API sans jeton.

Un dépassement renvoie une erreur HTTP 429 accompagnée d'en-têtes RateLimit-* et d'un en-tête Retry-After indiquant le délai d'attente. L'en-tête RateLimit-Remaining permet de suivre la consommation de la fenêtre en cours.

Les recommandations de GitLab

• Authentifier les appels avec un jeton d'accès personnel, un jeton OAuth ou le jeton de job CI/CD, pour basculer sur les limites de l'offre ;
• Réduire le volume grâce au regroupement, au cache et à la pagination, en évitant les boucles d'interrogation serrées ;
• Appliquer un recul exponentiel en cas d'erreur 429 plutôt que de relancer immédiatement ;
• Contacter limits@gitlab.com pour un besoin durable au-delà des plafonds ou une intégration incapable de s'authentifier.

L'éditeur prévoit aussi, d'ici la fin de l'année, une vue de consommation dans le produit et la possibilité d'acheter de la capacité supplémentaire. Pour les équipes qui pilotent leur infrastructure depuis GitLab, avec OpenTofu ou Terraform, un audit des appels d'API non authentifiés s'impose avant le 19 octobre.