Évolution des limites de débit sur GitLab.com

GitLab.com héberge des millions de projets pour des équipes de toutes tailles qui ont besoin d'une plateforme fiable. La demande est en forte croissance, et nous prévoyons que la charge de la plateforme se multipliera cette année. Des limites prévisibles sont donc indispensables pour que GitLab.com reste performant pour tous ses utilisateurs, y compris pour les charges de travail liées à l'automatisation et aux agents que les équipes développent sur la plateforme.

Pour préserver ces performances à mesure que nous évoluons, nous mettons à jour le fonctionnement des limites de débit. À compter du 19 octobre 2026, les limites de débit sur GitLab.com seront alignées sur votre niveau d'abonnement. Les comptes gratuits et les requêtes non authentifiées seront concernés en premier, dès le 19 octobre. Les abonnements GitLab Premium et GitLab Ultimate suivront en janvier 2027.

Ce qui change

Les limites sont alignées sur votre abonnement. Chaque abonnement (Gratuit, GitLab Premium et GitLab Ultimate) dispose de ses propres limites, appliquées par utilisateur et par groupe principal. La mise à jour entre en vigueur le 19 octobre pour l'abonnement Gratuit et en janvier 2027 pour les abonnements GitLab Premium et GitLab Ultimate.

Une fois connecté, vous bénéficiez de la limite maximale. Une requête authentifiée est soumise aux conditions de votre abonnement ci-dessous. Les requêtes envoyées sans identifiants sont limitées à 60 requêtes par heure et par adresse IP.

Les limites par abonnement sont publiées dans notre documentation relative aux limites de débit.

Changements prévus pour le 19 octobre

Avant l'entrée en vigueur des nouvelles limites de débit, deux fenêtres de prévisualisation, destinées au trafic de l'édition Gratuite et non authentifié, sont programmées les 7 et 14 octobre de 15 h 00 à 19 h 00 UTC. Les requêtes des abonnements GitLab Premium et GitLab Ultimate ne sont pas concernées, puisque leurs limites n'évolueront qu'en janvier. Notez que les requêtes non authentifiées sont plafonnées quelle que soit leur origine, y compris les automatisations exécutées sur un compte payant sans identifiants. Ces fenêtres de prévisualisation (également appelées « brownouts ») sont de courtes périodes planifiées pendant lesquelles nous activons puis désactivons les nouvelles limites de débit. Aucun autre aspect du service ne change pendant cette période. L'objectif est de vous donner un aperçu concret du comportement de vos propres charges de travail en conditions réelles, plusieurs semaines avant l'application définitive de ces nouvelles limites.

Le 19 octobre, les nouvelles limites entreront en vigueur.

Nous avons défini ces limites en analysant l'usage réel de GitLab.com. La quasi-totalité des utilisateurs se situe déjà en deçà des nouvelles limites et ne remarquera aucun changement. Nous avons également tenu compte des pratiques du marché : les limites de l'édition Gratuite et le seuil pour les requêtes anonymes correspondent aux normes du secteur, tandis que les abonnements GitLab Premium et GitLab Ultimate bénéficieront de limites plus importantes, à des niveaux que d'autres plateformes réservent à leurs offres entreprise, voire ne communiquent pas publiquement.

En cas de limite de débit presque atteinte

Si vous constatez que vous approchez d'une limite, authentifiez vos requêtes. Il s'agit généralement d'un changement mineur : l'utilisation d'un jeton d'accès personnel, d'un jeton OAuth ou du jeton de job CI/CD suffit à faire basculer une requête du seuil anonyme de 60 requêtes par heure vers les limites de votre abonnement, qui sont bien plus élevées.

Examinez ensuite la façon dont vous appelez l'API. Le traitement par lots, la mise en cache et la pagination permettent d'optimiser considérablement votre consommation, tandis qu'une boucle d'interrogation trop fréquente épuise rapidement votre quota. En cas de dépassement, vous recevrez une réponse HTTP 429 accompagnée d'un en-tête Retry-After indiquant le délai d'attente : un client qui lit ses propres en-têtes de réponse se corrige donc en grande partie tout seul. Une stratégie de backoff exponentiel permet de récupérer plus rapidement qu'une nouvelle tentative immédiate.

Passer à GitLab Premium ou GitLab Ultimate augmente également les limites, par utilisateur et par groupe principal.

Si vous avez besoin d'une limite plus élevée de manière permanente, nous travaillons actuellement à la mise en place d'une option permettant d'acheter de la capacité au-delà des limites standard de votre abonnement ; les détails seront communiqués en fin d'année. Si vous êtes concerné, contactez notre équipe commerciale ou envoyez un e-mail à limits@gitlab.com en nous indiquant vos besoins.

Résumé

Les limites de débit visent à empêcher qu'une charge de travail isolée ne puisse impacter les performances de la plateforme pour tous les autres utilisateurs. Ces changements ne ciblent pas les tâches authentifiées courantes, ce qui signifie que la quasi-totalité des utilisateurs ne remarquera aucun changement dans son quotidien. Naviguer dans l'interface, travailler dans votre éditeur, effectuer des opérations Git et exécuter des pipelines CI/CD dans le cadre de votre abonnement resteront identiques. Seules certaines automatisations importantes et quelques charges de travail sur l'abonnement Gratuit atteindront les nouveaux plafonds.

Ce qui ne change pas :

• Vous pouvez toujours accéder à vos propres données et dépôts et les exporter.
• Les limites de GitLab Self-Managed et GitLab Dedicated restent gérées par votre opérateur. Ce changement ne concerne que GitLab.com.
• Nous vous préviendrons avant d'apporter d'autres modifications.

Rappel : pensez à authentifier vos requêtes vers GitLab.com pour bénéficier de limites plus élevées.

FAQ

Comment savoir si ce changement me concerne ?

Comparez votre pic de trafic sur une minute avec les limites publiées pour votre abonnement. La plupart des utilisateurs sont en deçà de ces seuils. Le signal le plus rapide est l'en-tête RateLimit-Remaining dans vos réponses API, qui indique la part restante de votre fenêtre actuelle. Nous travaillons également à l'intégration d'une vue produit, prévue pour la fin d'année, qui permettra de visualiser votre consommation par rapport aux limites de votre abonnement.

Mon projet est public et génère beaucoup de trafic. Quelles sont mes options ?

Trois pistes s'offrent à vous : authentifiez les automatisations qui appellent votre projet pour qu'elles bénéficient de limites dédiées plutôt que du quota anonyme. Passez le projet en privé si le trafic ne provient pas du public auquel il est destiné, afin de bloquer tout accès anonyme. Enfin, passez à GitLab Premium ou GitLab Ultimate pour bénéficier de limites plus élevées.

Que se passe-t-il si je suis membre de plusieurs groupes principaux ?

Votre limite utilisateur correspondra au niveau d'abonnement le plus élevé dont vous disposez. Si vous êtes membre d'un groupe GitLab Ultimate, vous bénéficierez de la limite de GitLab Ultimate.

Que se passe-t-il lorsque j'atteins une limite ?

Vous recevez une réponse 429 Too Many Requests accompagnée des en-têtes RateLimit-* et d'un en-tête Retry-After. Attendez le délai indiqué avant de relancer la requête.

Mon intégration ne peut pas s'authentifier. Que faire ?

Contactez-nous à l'adresse limits@gitlab.com. Il existe des cas d'usage anonymes légitimes, un badge de statut public étant l'exemple le plus évident. Si vous craignez qu'une intégration dont vous êtes responsable soit concernée, contactez-nous.

Cette modification s'applique-t-elle à GitLab Self-Managed ou GitLab Dedicated ?

Non. Ce changement ne concerne que GitLab.com.

Ressources complémentaires

• Limites de débit par abonnement
• Authentification de vos requêtes API
• Vous avez des questions ? Contactez notre équipe commerciale ou envoyez un e-mail à limits@gitlab.com.