Contexte et motivations
GitLab.com voit son trafic augmenter de plusieurs fois en 2026, selon les prévisions internes. Cette hausse provient principalement des agents de codage automatisés qui interrogent les API, les interfaces web et les opérations Git via HTTPS. Pour préserver la stabilité du service, la société a décidé d’appliquer des plafonds de requêtes différenciés selon le type d’abonnement et le niveau d’authentification.
Nouveaux plafonds de requêtes
À compter du 19 octobre 2026, les requêtes non authentifiées seront limitées à 60 par heure et à 100 par minute pour chaque adresse IP. Les utilisateurs authentifiés bénéficient de seuils plus élevés : 5 000 requêtes/heure (100 /min) pour le plan Free, 15 000 requêtes/heure (1 250 /min) pour le plan Premium et 25 000 requêtes/heure (2 000 /min) pour le plan Ultimate. Les limites s’appliquent tant aux appels API qu’aux requêtes web et aux opérations Git. Un dépassement entraîne la réponse HTTP 429 avec l’en‑tête Retry-After indiquant le délai de reprise.
HTTP/1.1 429 Too Many Requests
RateLimit-Remaining: 0
Retry-After: 3600
Les plans Premium et Ultimate conservent leurs seuils actuels jusqu’en janvier 2027, offrant ainsi une période de transition de trois mois.
Mécanismes de mise en œuvre et suivi
GitLab organise deux fenêtres d’application temporaire le 7 et le 14 octobre 2026, de 8 h à 12 h PT, afin que les équipes détectent les points de friction avant le basculement définitif. Les développeurs peuvent suivre leur consommation via l’en‑tête RateLimit-Remaining présent dans chaque réponse API. Un tableau de bord dédié, prévu plus tard dans l’année, affichera l’usage cumulé par projet et par abonnement.
Pour les charges dépassant les seuils standards, GitLab prépare une option d’achat d’allocations supplémentaires. Les modalités restent à préciser, mais le modèle suggère un tarif à la demande similaire aux extensions de capacité cloud.
Implications pour les outils automatisés
Les agents d’IA qui accèdent à des dépôts payants sans authentification seront relégués au plafond anonyme de 60 requêtes/heure, ce qui peut réduire drastiquement leur efficacité. La documentation recommande donc d’utiliser des jetons d’accès personnel, OAuth ou des jetons de job CI/CD pour basculer le trafic vers les limites supérieures. En outre, les bonnes pratiques incluent la mise en cache des réponses fréquentes, le regroupement des appels (batching) et la limitation du polling continu. Ces mesures diminuent le risque de déclencher le code d’erreur 429 et améliorent la latence perçue par les utilisateurs finaux.
Les restrictions s’appliquent uniquement à GitLab.com. Les instances Self‑Managed ou Dedicated conservent le contrôle total de leurs propres politiques de débit, ce qui laisse aux organisations la liberté d’ajuster les seuils en fonction de leurs besoins internes.
