GitLab plafonne : authentifiez vos appels

Ce qui se passe

GitLab annonce, sous la signature de Sam Wiskow, que les limites de débit de GitLab.com vont s'aligner sur l'abonnement. L'argument avancé est la charge : l'entreprise s'attend à la voir croître plusieurs fois cette année, notamment sous l'effet des automatisations et des agents que ses clients bâtissent dessus.

Le calendrier se déroule en deux temps :

Une fenêtre d'essai — ce que les équipes d'exploitation appellent un brownout — active les nouvelles limites puis les retire. Rien d'autre ne change pendant ce temps : le but est de voir ses propres charges de travail à l'œuvre plusieurs semaines avant l'échéance.

La règle à retenir

Une requête authentifiée relève des limites de votre formule, calculées pour chaque utilisateur et chaque groupe racine. Une requête qui arrive sans le moindre identifiant tombe à 60 requêtes horaires, comptées par adresse IP, où qu'elle parte — y compris une automatisation lancée contre un compte payant mais dépourvue de jeton.

Si vous appartenez à plusieurs groupes racine, votre limite est celle de l'abonnement le plus élevé auquel vous avez accès.

Les valeurs par formule sont publiées dans la documentation des limites de débit. GitLab affirme les avoir fixées d'après l'usage réel et les pratiques de plateformes comparables : la limite Free et l'allocation anonyme suivent la norme du secteur, Premium et Ultimate se situent plus haut.

Ce que ça change concrètement

Le changement se voit surtout sur les dépôts publics très sollicités et sur les intégrations bricolées qui interrogent l'API en boucle sans jamais s'authentifier. Elles passeront de fonctionnelles à bloquées, sans qu'une seule ligne ait changé chez vous.

En revanche, rien ne bouge pour GitLab Self-Managed ni pour GitLab Dedicated : ces limites restent celles de votre exploitant. Et l'accès à vos données comme à vos dépôts, export compris, reste hors périmètre.

Comment s'y prendre

1. Authentifier les appels. Un jeton d'accès personnel, un jeton OAuth, ou celui du job CI/CD : il suffit d'un des trois pour sortir la requête de l'allocation anonyme et la placer sur celle de votre formule.
2. Se situer. L'en-tête RateLimit-Remaining indique ce qu'il reste de la fenêtre en cours. GitLab annonce pour plus tard cette année une vue produit montrant la consommation par rapport à la formule.
3. Gérer le refus. Un dépassement renvoie HTTP 429 avec un en-tête Retry-After. Un client qui relit les en-têtes de sa réponse se répare donc largement tout seul ; un recul exponentiel récupère plus vite qu'un renvoi immédiat.
4. Revoir les appels. Pagination, regroupement et mise en cache pèsent lourd, et l'interrogation en boucle serrée consomme l'allocation très vite.

Pour un dépôt public trop sollicité, trois options sont citées : demander aux automatisations tierces de s'authentifier, rendre le projet privé quand son public n'est pas celui qui l'appelle, ou monter d'abonnement. Une capacité achetable au-delà des limites de formule est annoncée pour plus tard dans l'année — contact : limits@gitlab.com.

Source : Rate limits on GitLab.com are changing, GitLab, 17 septembre 2026.