X ne publie plus les rate limits de l'API Twitter par palier

Quels sont les rate limits de l'API Twitter en 2026 ?

Rien dans la documentation actuelle de X ne fixe les rate limits de l'API Twitter par palier d'abonnement. Les tableaux en ligne sont organisés par endpoint et scindés en deux colonnes, une pour les limites par app qui s'appliquent quand vous vous authentifiez avec un bearer token, et une pour les limites par utilisateur qui s'appliquent avec les tokens utilisateur OAuth 1.0a ou OAuth 2.0. Chaque chiffre ci-dessous vient de docs.x.com/x-api/fundamentals/rate-limits, consulté le 12 septembre 2026.

Les fenêtres font 15 minutes sauf mention contraire dans l'entrée. Voici les endpoints qu'un projet d'écoute ou de surveillance touche réellement.

Deux entrées de ce tableau méritent qu'on s'y arrête. Recent search donne 450 requêtes à une app mais seulement 300 à un utilisateur, donc le bearer token app-only est l'identifiant le plus solide pour la surveillance. Full-archive search est gouverné autant par une limite à la seconde que par une limite par fenêtre, ce qui veut dire qu'un travail de rattrapage a besoin d'un sleep entre les appels plutôt que d'une rafale suivie d'une attente.

À quels paliers s'appliquent les rate limits de l'API Twitter ?

X exploite désormais deux niveaux commerciaux, le paiement à l'usage et Enterprise, et les paliers d'abonnement Free, Basic et Pro que les vieux guides citent encore ont disparu. Le changelog date la bascule. X a annoncé le pilote de tarification au paiement à l'usage le 20 octobre 2025 et a lancé cette tarification le 6 février 2026, Basic et Pro restant alors disponibles, puis a migré les abonnés Basic après le 1er juin 2026 et les abonnés Pro après le 1er septembre 2026. Les tableaux de rate limits ci-dessus ne portent aucune colonne de palier, et c'est la réponse honnête à "quelles sont les limites sur Basic". Il n'y a pas de Basic.

Là où X sépare encore par niveau, les chiffres ressemblent à ceci.

Où X se contredit-il sur ces chiffres ?

Trois pages en ligne sur docs.x.com se contredisent, et les écarts ne sont pas cosmétiques.

Le premier porte sur le nombre de règles de filtered stream. La page d'introduction au filtered stream place Enterprise à "25,000+" règles par projet. La page tarifaire Enterprise, qui décrit le même produit, la place à "5,000+ rules". Les deux pages étaient en ligne le 12 septembre 2026 et aucune ne renvoie à l'autre comme correction.

Le deuxième porte sur la longueur de requête des comptages de posts. Le tableau des rate limits liste /2/tweets/counts/all avec une note "1024 query length". La page du constructeur de requêtes de comptage indique "Your query can be 512 characters long for pay-per-use customers, or up to 4,096 characters for Enterprise customers", couvrant les deux endpoints de comptage avec un seul chiffre. Une requête écrite sur 1 024 caractères contre /2/tweets/counts/all tient donc dans la limite d'une page et dépasse celle de l'autre.

Le troisième est une référence morte. Les deux constructeurs de requêtes de recherche et le constructeur de règles du filtered stream vous disent que vos limites dépendent de votre niveau d'accès et renvoient à /x-api/getting-started/about-x-api pour le détail. Cette page ne contient plus de section sur le niveau d'accès. Elle présente des capacités, des versions d'API, des ressources et la tarification au paiement à l'usage, et rien qui nomme un palier. La page docs.x.com/fundamentals/rate-limits porte la description "Understand X API rate limits across access tiers and endpoints" et ne liste ensuite aucun palier, seulement un lien vers le tableau des endpoints.

La leçon pour qui budgète un projet : traitez le tableau par endpoint comme le document qui fait foi et les pages rédigées comme périmées.

Comment lire les en-têtes de rate limit ?

X renvoie trois en-têtes sur chaque réponse, et ce sont la seule source de vérité en temps réel.

x-rate-limit-limit: 900
x-rate-limit-remaining: 847
x-rate-limit-reset: 1705420800

x-rate-limit-limit est le plafond de la fenêtre en cours, x-rate-limit-remaining est ce qu'il reste, et x-rate-limit-reset est un horodatage Unix qui indique quand la fenêtre bascule. Franchissez le plafond et vous obtenez un 429 avec ce corps :

{
  "errors": [{
    "code": 88,
    "message": "Rate limit exceeded"
  }]
}

L'erreur code: 88 a survécu à toutes les réécritures de cette API depuis la v1.1, il vaut donc mieux la tester explicitement plutôt que de se fier au seul code de statut. Le conseil de récupération de X consiste à lire x-rate-limit-reset, attendre cet horodatage, puis appliquer un backoff exponentiel.

Les rate limits sont-ils la même chose que votre facture ?

Non, et X énonce la séparation directement : les rate limits contrôlent la fréquence des requêtes pour la stabilité du système, tandis que la facturation à l'usage fait payer les données récupérées. Vous pouvez rester sous chaque rate limit et dépenser quand même, et vous pouvez atteindre un rate limit sans dépenser un centime de plus.

Les lectures sont facturées par ressource renvoyée, pas par requête. Un post lu coûte $0,005 et un utilisateur lu coûte $0,010. Les ressources sont dédupliquées dans une fenêtre de 24 heures UTC, donc récupérer deux fois le même post dans la journée n'est facturé qu'une fois, et X qualifie cette déduplication de garantie souple plutôt que de promesse. La formule au paiement à l'usage est plafonnée à 3 millions de posts lus par cycle de facturation mensuel, quelle que soit la douceur de votre rythme de requêtes. Le tableau complet des coûts, côté écriture compris, est détaillé dans la note sur les tarifs de l'API X.

Quelle limite arrête vraiment un projet de surveillance ?

Le plafond mensuel de posts lus, pas la limite de requêtes par fenêtre. Recent search à 450 requêtes par 15 minutes avec 100 résultats par requête fait 45 000 posts par fenêtre sur le papier, de quoi épuiser une enveloppe de 3 millions de posts en moins d'une journée d'interrogation continue. Le plafond de requêtes est généreux ; le plafond de ressources est le budget.

Cela change la forme d'une bonne requête. Les règles étroites qui renvoient peu de correspondances coûtent peu, et une règle large qui attrape un mot courant brûle l'enveloppe pendant votre sommeil. Le filtered stream est l'instrument le moins cher pour une couverture continue parce qu'il ne livre que ce qui correspond à vos règles, et garder ces règles ne coûte rien. Bien les écrire relève de la même compétence que rédiger une bonne requête de recherche, ce que couvre la référence sur les opérateurs de recherche avancée de X.

L'autre moitié du calcul, c'est que X n'est qu'un réseau. Une question d'achat posée sur X l'est généralement aussi sur Reddit et Hacker News, et ces plateformes mesurent l'accès autrement, comme le montre la comparaison des rate limits de l'API Reddit. Les équipes parties de l'API X qui ont ensuite chiffré l'écart de couverture finissent plutôt par écouter sur plusieurs réseaux que par payer pour en élargir un seul.

Questions fréquentes

Quel est le rate limit de l'API de recherche X ?

Recent search sur /2/tweets/search/recent autorise 450 requêtes par 15 minutes avec un bearer token app-only et 300 par 15 minutes avec un token utilisateur, en renvoyant 10 résultats par défaut et 100 au maximum. Full-archive search sur /2/tweets/search/all autorise 1 requête par seconde et 300 par 15 minutes et par app, en renvoyant 10 résultats par défaut et 500 au maximum.

X a-t-il encore un palier Free ?

Pas en tant que produit documenté. X a lancé la tarification au paiement à l'usage le 6 février 2026 et sa documentation d'accès actuelle vous fait créer un compte, créer une app et enregistrer vos identifiants sans nommer le moindre palier. Le mot "Free" ne survit que dans les entrées du changelog, dont la note du 22 août 2025 qui a retiré POST /2/users/:id/likes et POST /2/users/:id/following du palier Free.

Que signifie un HTTP 429 sur l'API X ?

Cela signifie que vous avez dépassé un rate limit sur cet endpoint dans la fenêtre en cours. Le corps de la réponse porte code: 88 et le message "Rate limit exceeded". Lisez l'en-tête x-rate-limit-reset pour connaître l'horodatage Unix de réinitialisation de la fenêtre, et ne réessayez pas avant.

Les rate limits se comptent-ils par app ou par utilisateur ?

Les deux, et celui qui s'applique dépend de votre mode d'authentification. Les requêtes au bearer token comptent sur la limite par app, et les requêtes au token utilisateur OAuth 1.0a ou OAuth 2.0 comptent sur la limite par utilisateur de cette personne. Plusieurs endpoints ne publient qu'une des deux colonnes, ce qui veut dire que l'autre mode d'authentification n'y est tout simplement pas proposé.

Combien de règles de filtered stream puis-je faire tourner ?

Un projet au paiement à l'usage obtient 1 000 règles de 1 024 caractères maximum chacune, sur une connexion unique, avec une livraison plafonnée à 250 posts par seconde. Enterprise porte la longueur de règle à 2 048 caractères et autorise plusieurs connexions. Le nombre de règles Enterprise est justement le point où les pages de X se contredisent, à 25 000+ dans l'introduction au filtered stream et 5 000+ sur la page tarifaire Enterprise.

Les rate limits s'appliquent-ils à l'endpoint d'usage lui-même ?

Oui. GET /2/usage/tweets, l'endpoint qui rapporte votre propre consommation de posts, est plafonné à 50 requêtes par 15 minutes et par app et n'offre aucune limite par utilisateur. Interroger sa propre dépense coûte peu, mais reste soumis à la comptabilité, alors lisez-le selon un calendrier plutôt qu'avant chaque appel.

Combien coûte un Post read sur l'API X ?

Un Post read coûte 0,005 $ et un user read coûte 0,010 $, facturés par ressource renvoyée plutôt que par requête. X déduplique les ressources sur une fenêtre de 24 heures en UTC, donc récupérer le même Post deux fois dans la journée ne compte qu'une fois, même si X qualifie cette déduplication de garantie souple plutôt que de promesse. Le plan pay-per-use plafonne les Post reads à 3 millions par cycle de facturation, quel que soit le rythme des requêtes.

Quand X a-t-il retiré les paliers Basic et Pro ?

X a lancé la tarification pay-per-use le 6 février 2026, Basic et Pro restant disponibles, puis a déprécié les deux. Les abonnés Basic ont migré après le 1er juin 2026 et les abonnés Pro après le 1er septembre 2026, ne laissant qu'Enterprise et le pay-per-use. Les guides plus anciens qui citent encore des limites Basic ou Pro décrivent une structure tarifaire qui n'existe plus.

Pourquoi le rate limit par utilisateur dépasse-t-il parfois le rate limit par app ?

Il n'y a pas de règle unique. Sur /2/tweets, un token d'app obtient 3 500 requêtes par 15 minutes contre 5 000 pour un token utilisateur, et /2/tweets/:id suit le même schéma avec 450 contre 900. La recherche récente fonctionne à l'inverse, avec 450 par app contre 300 par utilisateur, l'identifiant le plus fort dépend donc de l'endpoint appelé et non d'une hiérarchie fixe entre authentification app et utilisateur.

Quel est le moyen le moins coûteux de faire tourner une surveillance continue sur X ?

Le filtered stream, pas l'interrogation répétée de search. La recherche récente, à 450 requêtes par 15 minutes et 100 résultats par appel, peut renvoyer jusqu'à 45 000 Posts par fenêtre sur le papier, de quoi épuiser une allocation mensuelle de 3 millions de Posts en moins d'une journée d'interrogation continue. Le filtered stream ne délivre que ce qui correspond à vos règles, et conserver ces règles ne coûte rien, un jeu de règles bien ciblé couvre donc le même terrain pour une fraction des reads.