GitLab.com durcit ses limites de débit en fonction de l'abonnement à partir d'octobre
En bref
- À partir du 19 octobre 2026, GitLab.com impose des limites de débit alignées sur l'abonnement : 60 requêtes/heure pour les utilisateurs non authentifiés, bien davantage pour les plans payants.
- Les requêtes authentifiées bénéficient de limites nettement plus génériques selon le tier d'abonnement, avec une transition progressive (Free en octobre, Premium/Ultimate en janvier 2027).
- Deux fenêtres de test sont prévues (7 et 14 octobre) pour que les utilisateurs ajustent leurs workflows avant application définitive.
- La mesure vise à maintenir la stabilité de la plateforme face à une augmentation attendue de la charge, notamment liée aux agents IA.
Ce que dit la source
GitLab affirme que la demande sur sa plateforme croît rapidement et anticipe une multiplication de la charge cette année. Pour maintenir la performance globale, GitLab.com alignera les limites de débit sur les tiers d'abonnement : les requêtes non authentifiées seront limitées à 60 par heure par adresse IP, tandis que les utilisateurs authentifiés bénéficieront de plafonds nettement plus élevés, déterminés par leur plan (Free, Premium ou Ultimate), appliqués par utilisateur et par groupe de haut niveau.
- Le seuil de 60 requêtes/heure pour l'accès anonyme correspond à environ une requête par minute, jugé restrictif pour les réseaux partagés (école, bureau).
- GraphQL s'avère plus efficace que l'API REST pour les agents IA, permettant de récupérer des centaines de résultats au lieu de dix, réduisant ainsi la consommation de tokens et le nombre de requêtes.
- GitLab Self-Managed et Dedicated ne sont pas affectés ; il s'agit d'une modification exclusive de GitLab.com.
- Les limites sont déterminées sur la base d'une analyse réelle de l'utilisation : GitLab affirme que la majorité des utilisateurs opèrent déjà sous ces nouveaux seuils.
- GitLab travaille sur un mécanisme de capacité achetable au-delà des limites standard, dont les détails seront communiqués plus tard dans l'année.
- Un utilisateur peut accéder à la limite la plus généreuse parmi tous les groupes auxquels il appartient (principe du tier maximal).
Dans les commentaires
Débat partagé et pragmatique : plusieurs commentateurs reconnaissent la nécessité de cette mesure face aux agents IA et au scraping, certains la rapprochent des restrictions antérieures de Docker sur les pulls non authentifiés. D'autres soulevant des préoccupations légitimes sur l'impact sur les petites équipes, les réseaux partagés ou les intégrations sans authentification.
- Plusieurs commentateurs relèvent que 60 requêtes/heure est restrictif pour un IP mutualisée (école, bureau, entreprise) où plusieurs personnes accèdent simultanément à GitLab en navigant ou exécutant des workflows.
- Un argument récurrent concerne les agents IA et le scraping : certains y voient la cause principale, d'autres soulignent que GraphQL réduit drastiquement le problème (contexte entrant dense, jointures cross-type gratuites) et devrait être privilégié par rapport à REST.
- Quelques commentateurs expriment du scepticisme sur le messaging de GitLab, notamment en questionnant le ton de la communication (« Claude a écrit le communiqué de presse ») et en pointant les limites pratiques : validation du comportement de rate-limiting sans créer de charge, anonymat des intégrations légitimes.
- Un utilisateur note que les instances self-hosted (Forgejo) deviennent attractives précisément pour éviter ce cycle de restrictions.
- Une friction mineure concerne la clarté : les endpoints API non standard (`/raw/HEAD/`) seront-ils aussi limités, ou seulement les endpoints REST/GraphQL documentés ?
Notre lecture
À surveiller pour les équipes utilisant GitLab.com, surtout si elles s'appuient sur des CI/CD lourdement automatisés ou sur des accès anonymes. Concrètement, l'authentification est la réponse directe ; GraphQL est un levier pour les agents IA. Le changement n'affecte pas les self-hosted ni les Dedicated, ce qui renforce l'attrait de ces options pour qui cherche à éviter un cycle de restrictions. La fenêtre de test en octobre est utile : c'est le moment de vérifier ses patterns réels. Pas d'urgence immédiate pour la majorité des équipes standard.