API X : la fin du gratuit utile, et pourquoi les développeurs doivent revoir leur manière de faire

Pendant longtemps, beaucoup de développeurs ont vu l'API Twitter, puis X, comme une porte d'entrée assez simple pour brancher un bot, faire un peu de veille, récupérer des posts, suivre quelques comptes ou intégrer un flux dans un site. Ce n'était pas forcément toujours parfait, mais la logique restait lisible : on regardait un plan, on voyait ce qu'il permettait, et on développait autour. Aujourd'hui, ce n'est plus vraiment ce monde-là.

La page officielle développeur de X présente désormais l'API comme une offre pay-per-use, autrement dit un accès facturé à l'usage, avec des crédits achetés à l'avance, une consommation suivie en direct dans la console, et une tarification qui dépend des endpoints utilisés. X ne met plus en avant un accès gratuit réellement exploitable comme base naturelle pour les petits projets de lecture ou d'agrégation.

Le changement n'est pas juste cosmétique. Il modifie la façon de penser une intégration. Avant, on pouvait raisonner en plan mensuel. Maintenant, il faut raisonner en consommation, en coût par type de requête, en lecture de ressources, en cache, et surtout en optimisation. La documentation officielle explique clairement que les crédits sont débités au fur et à mesure des appels, que les coûts varient selon les endpoints, et que les tarifs exacts se consultent dans le Developer Console.

Ce qui change vraiment

Le point clé, c'est que X a déplacé le centre de gravité de son offre. La présentation actuelle est très claire : l'API X moderne est vendue comme une API à tarification flexible basée sur l'usage, sans abonnement obligatoire, sans engagement, et avec suivi des dépenses en temps réel.

Dit plus simplement : l'époque où l'on pouvait considérer l'accès gratuit comme la base par défaut pour lire des données sur X est terminée. Il a bien existé des formules self-serve plus lisibles, avec des paliers du type Free, Basic et Pro. D'ailleurs, la documentation actuelle le rappelle indirectement en mentionnant encore les legacy subscription packages (Basic or Pro) pour les comptes qui peuvent basculer vers le pay-per-use ou revenir à leur ancien plan depuis la console.

Autrement dit, l'ancien monde n'a pas totalement disparu dans les coulisses, mais le nouveau message public de X est limpide : la référence produit, maintenant, c'est le pay-per-use.

Le gratuit, dans les faits, n'est plus le vrai point d'entrée

C'est probablement la phrase la plus simple à retenir : pour un développeur qui veut lire des posts, surveiller des comptes, faire de la recherche, agréger des contenus, récupérer des images, ou simplement faire tourner un petit outil de monitoring, le gratuit n'est plus le socle pratique à partir duquel on construit sereinement.

La page de pricing officielle ne présente pas un tableau grand public avec un vrai volume gratuit confortable. Elle présente un système de crédits, de coûts par endpoint, de suivi budgétaire, de déduplication et de plafond d'usage mensuel sur les lectures.

X précise même que les offres pay-per-use sont soumises à un plafond mensuel de 2 millions de Post reads, ce qui montre bien que le cœur économique de l'offre est désormais pensé autour de la consommation facturable de ressources, et non autour d'un "petit accès gratuit sympa pour commencer".

Ancienne logique vs nouvelle logique

Voici la lecture la plus simple du basculement.

Ce tableau vient directement de la façon dont X présente désormais son produit : "pay only for what you use", "credit-based pricing", "per-endpoint pricing", "no subscriptions", "real-time tracking", avec en parallèle la mention explicite de legacy subscription packages Basic or Pro.

Ce que X facture maintenant, et pourquoi cela change la manière de coder

Le vrai tournant, ce n'est pas seulement qu'il faut payer. C'est qu'il faut désormais penser son code autour du coût.

La documentation officielle distingue clairement deux choses :

• les rate limits, qui limitent la fréquence des appels ;
• la facturation, qui dépend de ce que tu demandes réellement et des ressources retournées.

Ça change beaucoup de choses. Avant, beaucoup de développeurs regardaient surtout la limite technique : combien d'appels par 15 minutes, combien par jour, combien par mois. Aujourd'hui, ça ne suffit plus. Une intégration peut très bien rester dans les limites techniques et coûter plus que prévu si elle relit sans cesse les mêmes timelines, refait des recherches inutiles ou repagine trop large.

Le message implicite est simple : avec X, la question n'est plus seulement "combien d'appels puis-je faire ?", mais "qu'est-ce que mes appels vont réellement me coûter ?".

La déduplication : un détail technique qui devient central

L'un des éléments les plus intéressants dans la documentation actuelle, c'est la déduplication sur 24 heures.

X explique que si une ressource facturable, par exemple un post ou un user, a déjà été chargée et facturée une fois dans la journée UTC, une nouvelle demande sur cette même ressource dans cette même fenêtre ne génère normalement pas de nouveau coût. La fenêtre se réinitialise à minuit UTC, et X précise que cela s'applique aux ressources facturables, même s'il s'agit d'une "soft guarantee" et non d'une garantie absolue en toutes circonstances.

C'est un détail important, parce qu'il pousse les développeurs à coder autrement :

• stocker les IDs déjà vus ;
• éviter de rescanner l'historique complet ;
• travailler avec since_id ou des curseurs ;
• mettre en cache les lectures récentes ;
• limiter les champs demandés au strict nécessaire.

En clair, l'API X moderne récompense les intégrations sobres et intelligentes. Plus ton code évite le gaspillage, plus ton budget reste maîtrisable.

Ce principe de sobriété dans les appels API n'est pas sans rappeler ce que j'évoquais dans mon article sur le Concierge Digital : un bon assistant numérique ne multiplie pas les requêtes inutiles, il optimise chaque interaction pour en tirer le maximum de valeur.

Les rate limits existent toujours, mais ce n'est plus toute l'histoire

Les limites de requêtes n'ont pas disparu. X publie toujours ses rate limits par endpoint, souvent sur des fenêtres de 15 minutes ou sur 24 heures. La documentation officielle affiche par exemple des quotas sur des endpoints comme la recherche récente, la lecture de posts, la publication de posts ou la lecture de timeline utilisateur.

Mais ces chiffres ne suffisent plus à raconter la vraie contrainte. Le vrai sujet n'est plus seulement de rester sous une limite technique, mais de ne pas transformer une intégration banale en aspirateur à crédits.

Pour dire les choses simplement : autrefois, tu surveillais surtout le quota. Maintenant, tu surveilles le quota et la facture.

Pourquoi ce changement peut avoir des avantages

Ce nouveau modèle n'est pas seulement une contrainte. Il a aussi une logique produit assez claire.

D'abord, X met en avant le fait qu'il n'y a pas d'abonnement obligatoire, pas de contrat, pas d'engagement, et pas de minimum de dépense. Pour certains usages ponctuels, cela peut être plus souple qu'un gros plan mensuel fixe.

Ensuite, le suivi budgétaire est plus direct :

• solde de crédits visible ;
• recharge automatique configurable ;
• suivi des coûts en direct ;
• contrôle de la consommation dans la console développeur.

Pour une entreprise qui veut une visibilité opérationnelle précise, ou pour un projet qui consomme par pics plutôt qu'en continu, cette logique peut se défendre.

Pourquoi ce changement complique la vie de beaucoup de petits projets

Là où ça se corse, c'est pour tous les outils modestes qui vivaient très bien avec un modèle plus simple.

• Un script qui récupère des images.
• Un petit outil de veille.
• Un bot de curation.
• Un site qui affiche un flux.
• Un dashboard qui surveille quelques comptes.
• Un service maison qui interroge X deux ou trois fois par jour.

Tous ces usages doivent maintenant être pensés avec une vraie logique d'économie d'appels. Il faut limiter les champs, éviter les doublons, stocker les IDs, construire des syncs incrémentaux, prévoir le budget, surveiller la console, et accepter que même un petit usage de lecture ne soit plus naturellement "gratuit de fait".

C'est probablement là que beaucoup de développeurs sentent le plus le changement : non pas parce que l'API serait devenue inutilisable, mais parce qu'elle demande désormais une discipline de consommation qu'on ne demandait pas forcément avant à ce niveau.

On retrouve un peu cette problématique dans l'article sur la limitation des résultats Google : quand une plateforme dominante restreint l'accès à ses données, c'est tout un écosystème de petits outils qui doit se réinventer.

Ce que cela veut dire, très concrètement

Si tu développes aujourd'hui autour de X, il faut presque partir d'une règle simple :

Chaque requête doit avoir une raison claire d'exister.

Ça veut dire :

• interroger une timeline au lieu d'une recherche large quand c'est possible ;
• ne pas recharger ce que tu as déjà ;
• limiter le nombre de champs ;
• utiliser les mécanismes incrémentaux ;
• suivre l'usage réel dans la console ;
• considérer l'API X comme une ressource budgétaire, pas comme un simple tuyau technique.

Dans cette logique, la qualité d'une intégration ne se mesure plus seulement à sa robustesse ou à sa rapidité. Elle se mesure aussi à sa sobriété.

C'est d'ailleurs un réflexe que les développeurs qui travaillent avec les APIs d'IA populaires connaissent déjà bien : chaque appel à un modèle a un coût en tokens, et optimiser ses prompts est devenu une compétence à part entière. L'API X suit maintenant la même philosophie.

En résumé

L'API X a changé de philosophie. L'ancien réflexe qui consistait à se dire "je vais commencer gratuitement et je verrai ensuite" ne correspond plus vraiment à la manière dont la plateforme est désormais présentée et monétisée.

La documentation officielle pousse aujourd'hui un modèle pay-per-use, avec crédits prépayés, tarification par endpoint, suivi en temps réel, déduplication sur 24 heures, et plafond mensuel de lecture pour les offres concernées. Elle mentionne encore les anciens plans Basic et Pro comme formules legacy, mais le message principal est ailleurs : le standard actuel, c'est l'usage facturé.

Et au fond, c'est sans doute ça la vraie phrase à retenir :

Sur X, l'époque du gratuit utile pour faire de la lecture API de manière confortable est derrière nous.

Si le sujet des APIs et de l'évolution des plateformes t'intéresse, tu peux aussi lire mon retour sur Codex ou comment j'utilise l'IA pour coder un DAW : dans les deux cas, la question du coût des outils et de la sobriété des intégrations est au centre.