La vraie limite GitHub d'un agent IA : 80 par minute, pas l'âge du compte

Vous lancez un agent sur un bug, vous vous éloignez, et vous revenez à des erreurs au lieu d'une pull request. L'explication habituellement avancée est que votre compte GitHub est trop récent. Cela vaut la peine de vérifier, car GitHub publie ses limites en détail et l'ancienneté du compte n'en fait pas partie.

Voici ce que dit réellement la documentation, et lequel des chiffres publiés est celui qu'un agent autonome rencontre en premier.

Les deux chiffres que tout le monde cite, et pourquoi aucun n'est votre problème

La documentation REST de GitHub est sans ambiguïté sur les limites principales. Soixante requêtes par heure si vous n'êtes pas authentifié. Cinq mille par heure avec un jeton d'accès personnel. Les GitHub Apps obtiennent cinq mille comme minimum d'installation.

Cinq mille par heure, c'est généreux pour un agent. Lire un dépôt, planifier un changement et ouvrir une pull request ne représente pas des dizaines de milliers d'appels. Si vous heurtez un mur au cours d'une seule session, la limite principale n'est presque certainement pas le mur que vous avez heurté.

Nulle part sur cette page, ni dans la section des limites secondaires qui l'accompagne, l'ancienneté du compte n'apparaît comme un facteur. Ni comme multiplicateur, ni comme palier, ni comme note. Cette page comportait auparavant un tableau de tranches d'ancienneté avec le comportement décrit pour chacune, et ce tableau a été supprimé plutôt qu'assoupli, car il ne s'agissait pas d'une approximation d'un mécanisme réel. Il n'existe aucun mécanisme documenté.

La limite qui correspond exactement à un agent

Les limites secondaires de GitHub sont les plus intéressantes, et l'une d'elles est façonnée précisément comme le travail autonome : pas plus de 80 requêtes génératrices de contenu par minute, et pas plus de 500 par heure.

Générer du contenu signifie créer des choses. Des commits, des pull requests, des issues, des commentaires, des fils de revue. Une personne qui code à la main en produit une poignée par heure. Un agent qui travaille sur un refactor à travers une douzaine de fichiers, en commitant au fur et à mesure et en commentant sa propre pull request, peut en produire des dizaines en une minute sans que rien ne soit anormal.

Cinq cents par heure est le plafond le plus contraignant des deux. Un agent qui boucle sur un dépôt, ou plusieurs agents partageant un même jeton, l'atteindra bien avant que le budget de cinq mille requêtes de lecture ne soit entamé. Les limites publiées qui l'accompagnent valent la peine d'être connues pour la même raison : cent requêtes simultanées partagées entre les API REST et GraphQL, neuf cents points par minute sur REST, et quatre-vingt-dix secondes de temps de traitement pour chaque soixante secondes de temps réel.

La solution n'est pas un compte plus ancien. C'est moins d'écritures, mais plus grosses : un commit plutôt que huit, un commentaire récapitulatif plutôt qu'un commentaire continu, et un jeton par agent plutôt qu'un jeton partagé entre eux.

L'authentification à deux facteurs obligatoire échoue dans l'autre sens

Cette page disait auparavant qu'un compte sans 2FA était un candidat plus probable pour une mise en attente de sécurité qui pourrait figer un agent en pleine tâche. La documentation décrit quelque chose de proche de l'inverse, et la différence change ce que vous devriez faire.

GitHub sélectionne les comptes pour la 2FA obligatoire en fonction de l'activité de contribution : selon ses termes, votre compte est sélectionné si vous avez effectué une action montrant que vous êtes un contributeur. Les comptes sélectionnés bénéficient d'une période d'inscription de 45 jours, puis d'un délai de grâce de 7 jours, après quoi le compte ne peut plus être utilisé sur le site tant que la 2FA n'est pas activée.

Voici la partie qui compte ici. Un compte verrouillé ne peut pas autoriser de nouvelles applications ni créer de nouveaux jetons d'accès personnels. Les jetons existants continuent de fonctionner, délibérément, car ils soutiennent l'automatisation dont les gens dépendent.

Ainsi, un agent déjà en cours d'exécution avec un jeton émis ne s'arrête pas lorsque le compte se verrouille. Ce qui s'arrête, c'est votre capacité à lui en émettre un nouveau, ou à connecter un nouvel outil. La panne survient à la prochaine rotation plutôt qu'en pleine tâche, ce qui est une façon bien plus discrète de perdre une journée. Activez la 2FA avant d'avoir besoin d'un nouveau jeton, pas après.

Pourquoi le jeton est toute la frontière de sécurité

Tout ce que fait l'agent, il le fait en votre nom. Lire, commiter, déclencher des exécutions de workflows, tout cela est authentifié par une seule chaîne de caractères, et tout cela est attribué à votre compte dans l'historique.

Ce qui fait de la portée que vous accordez à ce jeton le seul contrôle réel que vous ayez, et c'est une décision prise une fois et assumée. Un jeton limité à un seul dépôt limite les erreurs d'un agent à un seul dépôt. Un jeton limité à tout ce que vous pouvez atteindre, non. Étant donné que le même jeton porte également le budget de génération de contenu décrit ci-dessus, un jeton par agent est à la fois une mesure de sécurité et une mesure de débit.

Ce que contient réellement l'étagère de comptes ici

Puisqu'il s'agit d'une place de marché, les choses précises qui méritent d'être énoncées concernent notre propre stock plutôt que les outils.

L'étagère GitHub contient 64 annonces actives provenant de 30 vendeurs, et les commandes terminées sur celle-ci s'élèvent à 213 lignes de commande réparties sur 20 produits distincts, c'est donc petit mais réellement actif. En lisant les 64 titres, environ la moitié annonce l'authentification à deux facteurs, à peu près le même nombre inclut l'accès par e-mail, et plusieurs indiquent clairement qu'un jeton d'accès personnel classique est inclus. Les anciennetés annoncées vont de dix jours à trois ans. Une annonce est un abonnement Copilot plutôt qu'un compte.

Ce qui ne peut pas être dit, c'est ce que vaut l'une quelconque de ces étiquettes. La méthode habituelle ici consiste à comparer le stock étiqueté d'un vendeur avec le stock non étiqueté du même vendeur, et sur une étagère de 64 annonces, aucun vendeur ne détient assez des deux pour que la comparaison fonctionne. Les multiples à l'échelle de l'étagère semblent spectaculaires et ne veulent rien dire, ils ne sont donc pas publiés.

La garantie sur cette étagère est de douze heures en médiane, ce qui est court pour un achat dont toute la valeur est un identifiant que vous n'avez pas encore testé. Émettez un jeton et effectuez un appel authentifié dès que le compte arrive.

Une note sur les outils concernés

La moitié des suggestions de recherche autour du nom dans le titre de cette page sont des comparaisons : cet agent contre celui-là, et contre un troisième. Le nom lui-même est utilisé pour plus d'un projet open source, ce qui vaut la peine d'être su avant de suivre un tutoriel écrit pour un autre.

Rien de ce qui précède ne dépend de celui que vous avez choisi. Tout agent qui écrit dans un dépôt le fait via un jeton, dépense le même budget de génération de contenu et hérite du même état de compte. C'est la partie durable.

Les étagères de comptes IA ici sont bien plus minces que celle de GitHub et plus minces que ce que l'article en direct laissait entendre : les plus fournies sont les comptes GPT avec 61 annonces, Grok avec 26 et DeepSeek avec 17, tandis que plusieurs étagères nommées ne contiennent rien du tout. Sur les 16 735 annonces actives du site, exactement une mentionne Claude dans son titre, et c'est une annonce Gmail plutôt qu'une annonce de compte IA.

Les limites citées tout au long proviennent de la documentation officielle de GitHub sur les limites de débit, qui est la seule source qui reste à jour. Les comptes avec jetons et état d'authentification à deux facteurs décrits dans l'annonce se trouvent sous comptes GitHub.