La liste des opérateurs de recherche avancée de X : ce que le champ web accepte, ce que l'API rejette

À quoi ressemble la liste complète des opérateurs de recherche avancée de X ?

Deux jeux documentés composent la liste des opérateurs de recherche avancée de X : les champs que le centre d'aide de X expose via le formulaire de recherche avancée sur x.com, et les opérateurs que la documentation développeur de X définit pour les endpoints de recherche v2. Les deux jeux se recoupent sur les mots-clés, les comptes et la langue, puis divergent sur les dates, les seuils d'engagement et la géographie, parce que le champ de recherche web a gardé la syntaxe de l'API standard v1.1 retirée pendant que v2 recevait de nouveaux noms d'opérateurs. Vérifiez de quel côté de cette séparation vous êtes avant d'écrire un seul caractère.

Rôle	Opérateur	Ce qu'il trouve	Recherche web	X API v2
Contenu	keyword	Un mot tokenisé dans le corps du post	Oui	Oui
Contenu	"exact phrase"	Les mots dans cet ordre	Oui	Oui
Contenu	#hashtag	Le hashtag, correspondance exacte	Oui	Oui
Contenu	$cashtag	Un symbole boursier	Non vérifié	Oui
Contenu	url:	Un token dans le lien ou dans le lien déplié	Non vérifié	Oui
Contenu	lang:en	La langue que X a attribuée au post	Oui	Oui, conjonction requise
Contenu	-term, OR, ( )	Exclure, alterner, grouper	Oui	Oui
Comptes	from:handle	Les posts écrits par ce compte	Oui	Oui
Comptes	to:handle	Les réponses adressées à ce compte	Oui	Oui
Comptes	@handle	Les posts qui mentionnent ce compte	Oui	Oui
Comptes	list:id	Les posts des membres d'une Liste	Non vérifié	Oui
Comptes	retweets_of:handle	Les reposts de ce compte	Non	Oui
Comptes	is:verified	Les posts d'un auteur vérifié	Non vérifié	Oui, conjonction requise
Comptes	bio:, bio_name:	Le texte du profil de l'auteur	Non	Enterprise Powerstream uniquement
Engagement	min_faves:25	Au moins 25 likes	Oui	Rejeté avec un 400
Engagement	min_retweets:10	Au moins 10 reposts	Oui	Rejeté avec un 400
Engagement	min_likes:25	Au moins 25 likes	Non	Oui
Engagement	min_reposts:10	Au moins 10 reposts	Non	Oui
Engagement	min_replies:3	Au moins 3 réponses	Non vérifié	Oui
Dates	since:2026-08-01	Les posts à partir de ce jour	Oui	Non, utilisez start_time
Dates	until:2026-09-01	Les posts avant ce jour	Oui	Non, utilisez end_time
Dates	start_time, end_time	Des bornes en ISO 8601	Non	Oui, paramètres de requête
Dates	since_id, until_id	Des bornes par ID de post	Non	Oui, paramètres de requête
Médias	has:media, has:images, has:videos, has:links	Une pièce jointe ou un lien	Non vérifié	Oui, conjonction requise
Médias	has:hashtags, has:cashtags, has:mentions, has:geo	Cette entité présente quelque part	Non vérifié	Oui, conjonction requise
Médias	is:retweet, is:reply, is:quote	Le type de post	Non vérifié	Oui, conjonction requise
Médias	-is:nullcast	Écarte les posts uniquement sponsorisés	Non	Oui, négation obligatoire
Géo	near:"San Francisco, CA"	Les posts tagués près d'un lieu	Oui	Non
Géo	within:15mi	Le rayon, va avec near:	Oui	Non
Géo	place:seattle	Un lieu tagué	Non	Oui
Géo	place_country:US	Un code pays ISO	Non	Oui
Géo	point_radius:[2.355128 48.861118 16km]	Un cercle autour d'une coordonnée	Non	Oui
Géo	bounding_box:[-105.30 39.96 -105.17 40.09]	Un rectangle de coordonnées	Non	Oui
Fils	conversation_id:1334987486343299072	Tous les posts d'un fil	Non	Oui
Fils	in_reply_to_tweet_id:, quotes_of_tweet_id:, retweets_of_tweet_id:	Les réponses, citations et reposts d'un post	Non	Oui
Fils	context:, entity:	Les annotations thématiques propres à X	Non	Oui, entity: sur recent search uniquement

Dernière vérification : 8 septembre 2026

Sources : X Help Center, How to use advanced search, pied de page estampillé 2026 X Corp, lu le 8 septembre 2026. Documentation développeur de X, Search Operators et Build a query, lus le 8 septembre 2026.

Quels opérateurs fonctionnent dans le champ de recherche web gratuit sans clé d'API ?

Quatorze opérateurs portent un Oui dans la colonne web ci-dessus parce que le centre d'aide de X les confirme, et toutes les autres entrées web sont des déductions. Cette page documente les champs du formulaire de recherche avancée, puis renvoie vers deux recherches préconstruites dont les URLs écrivent la syntaxe en toutes lettres : New Years -Resolution lang:en near:"San Francisco, CA" within:15mi since:2013-12-30 until:2014-01-02 et #WorldCup lang:en near:"Brazil" within:15mi until:2014-07-31. Traitez ces deux URLs comme la référence web et testez vous-même tout ce qui va au-delà.

X pose une condition d'accès. Son centre d'aide indique que la recherche avancée "is available when you're logged in to X.com," (est disponible quand vous êtes connecté à X.com), donc le champ de recherche web est gratuit, mais pas sans compte.

Quels opérateurs de X ne fonctionnent qu'à travers l'API ?

Les fils, les annotations et la géographie précise sont réservés à l'API, parce que ces opérateurs visent des ID de post et une géométrie de coordonnées pour lesquelles le formulaire web n'a aucun champ. conversation_id: sort toutes les réponses d'un fil, context: correspond aux annotations thématiques propres à X, et point_radius: prend une longitude, une latitude et un rayon. Passez par l'API quand votre question porte sur la forme d'une conversation plutôt que sur les mots qu'elle contient.

La longueur de la requête est le vrai plafond de l'API. La documentation de X limite une requête recent search en self-serve à 512 caractères, celle de full-archive à 1 024 et celle d'enterprise à 4 096, et toute la chaîne compte. Le calcul pour une liste de mots-clés tient sur une ligne :

Characters = (variants x average variant length) + (OR joins x 4) + (parentheses x 2)

Vingt variantes d'un nom de produit de 12 caractères en moyenne, jointes par OR dans un seul groupe :

(20 x 12) + (19 x 4) + 2 = 240 + 76 + 2 = 318 characters

Il reste 512 moins 318 = 194 caractères pour lang:, -is:retweet et le reste sur le palier self-serve de recent search. Le full-archive double la place, à 1 024. Budgétez d'abord les filtres et dépensez ce qui reste en variantes, et lisez ce que coûte l'API X par palier et comment fonctionnent ses quotas de requêtes avant de vous engager sur cette voie.

Où passent les 512 caractères d'une requête recent search

Variantes (20 x 12 caractères)240

Jonctions OR (19 x 4)76

Parenthèses2

Restant pour les filtres194

Comment fixer des seuils d'engagement dans la recherche X ?

X utilise des noms différents pour le même seuil sur chaque surface, et sa propre référence d'opérateurs le dit dans un encadré d'avertissement : "The equivalent operators on X web search are named min_faves: and min_retweets:. Those names are not valid in the X API and will be rejected with a 400 error. Use min_likes: and min_reposts: instead." (Les opérateurs équivalents dans la recherche web de X s'appellent min_faves: et min_retweets:. Ces noms ne sont pas valides dans l'API X et seront rejetés avec une erreur 400. Utilisez min_likes: et min_reposts: à la place.) min_replies: garde son nom des deux côtés. Chacun prend un entier positif ou nul et fonctionne aussi bien sur recent search que sur full-archive.

Les seuils coupent le bruit et coupent l'intention d'achat en même temps. Quelqu'un qui demande une recommandation d'outil récolte deux likes, pas deux cents, donc min_faves:50 supprime exactement les posts qui méritent une réponse. Montez les seuils pour le suivi des concurrents et des crises, et mettez-les à zéro ou omettez-les quand vous chassez l'intention.

Comment chercher une plage de dates exacte sur X ?

Le champ de recherche web accepte since: et until: avec des dates YYYY-MM-DD, et l'API n'accepte ni l'un ni l'autre. since:2026-08-01 until:2026-09-01 renvoie août dans le champ web ; la même plage dans l'API passe par les paramètres de requête start_time et end_time en ISO 8601, avec since_id et until_id comme équivalents par ID de post. Le centre d'aide de X confirme que l'archive web remonte au premier post public de 2006, et l'API découpe ça en recent search sur 7 jours pour tout développeur et full-archive jusqu'à 2006 pour les paliers payants.

Les plages sont semi-ouvertes dans le champ web, donc until:2026-09-01 s'arrête avant le 1er septembre au lieu de l'inclure. Ajoutez un jour à votre date de fin quand un rapport doit compter le dernier jour.

Quels opérateurs médias et géo fonctionnent encore ?

Tous les opérateurs has: et is: sont documentés pour l'API et aucun pour le champ web, donc la colonne médias est l'endroit où la plupart des guides se trompent. Le tableau de migration de X fait correspondre les anciens noms de la standard v1.1 aux nouveaux : filter:links est devenu has:links, filter:media est devenu has:media, filter:images et filter:twimg sont devenus has:images, et filter:retweets est devenu is:retweet. Le champ de recherche web descend de cette famille héritée, et c'est pour ça que la syntaxe filter: circule encore et que rien de tout ça n'apparaît dans la documentation actuelle de X.

La documentation de X se contredit aussi sur la vidéo. La référence Search Operators liste has:video_link pour les vidéos natives de X, tandis que l'introduction de Search Posts et le tableau de migration listent tous les deux has:videos. Essayez has:videos d'abord et gardez le repli sous la main, parce que l'une des deux pages est périmée et X ne dit pas laquelle.

La géographie se sépare proprement. near: plus within: appartiennent au champ web, place:, place_country:, point_radius: et bounding_box: appartiennent à l'API, et aucune des deux paires ne fonctionne de l'autre côté.

Trois requêtes qu'un marketeur lance sur X

Intention d'achat, champ web, opérateurs vérifiés uniquement :

("looking for" OR "recommend a" OR "alternative to" OR "switching from") (CRM OR "help desk" OR helpdesk) lang:en since:2026-08-25 -from:YourBrand

Signaux de départ chez un concurrent, champ web, seuils activés pour ne faire remonter que les posts avec de la traction :

(@Competitor OR Competitor) (cancelled OR canceling OR "switching to") lang:en min_faves:5 since:2026-06-01 until:2026-09-01

La même chasse à l'intention via l'API, où tous les noms d'opérateurs changent :

("looking for" OR "any recommendations" OR "alternative to") ("project management" OR "task tracker") lang:en -is:retweet -is:nullcast -has:links min_likes:2

L'ordre des opérations décide de ce que chacune renvoie. X combine AND avant OR, donc apple OR iphone ipad s'évalue comme apple OR (iphone ipad), et les parenthèses des trois requêtes ci-dessus portent la structure au lieu de la décorer. La logique booléenne générique au-delà de ça relève des règles derrière AND, OR et NOT ; cette page reste sur la syntaxe propre à X.

Quels opérateurs n'ont pas pu être vérifiés ?

Dix familles d'opérateurs n'apparaissent dans la documentation de X que comme noms retirés de la standard v1.1, ce qui les rend non vérifiés plutôt que fonctionnels : toute la famille filter:, source:, card_name:, card_domain:, include:antisocial, include:sensitive_content, filter:follows, filter:has_engagement, filter:trusted et le paramètre de requête geocode. L'aperçu de migration de X liste chacun d'eux sous une colonne Standard avec la colonne v2 laissée vide, et l'endpoint standard v1.1 n'existe plus.

Le champ de recherche web n'a jamais migré vers les noms de v2, il a donc hérité de cette famille ancienne en entier, et X ne publie aucune liste de ce qui a survécu. Lancez chaque opérateur contre une requête dont vous savez déjà qu'elle renvoie des résultats et comparez les compteurs. Tout ce qui renvoie l'ensemble non filtré est ignoré plutôt qu'appliqué.

RedReplier surveille X aux côtés de Reddit, Bluesky, Facebook et Hacker News au même endroit, classe ce qu'il trouve par intention d'achat, et explique avec de l'IA pourquoi chaque mention a été signalée. Sa surveillance de X prend des mots-clés et un site web au lieu d'une chaîne de requête, et elle expose une API et un serveur MCP pour Claude Code, Cursor et n'importe quel client MCP standard. La pratique dans laquelle tout ça s'inscrit, c'est le social listening, et la version faire ou acheter de la question, c'est faire tourner soi-même une API de social listening.

Questions fréquentes

La recherche avancée de X fonctionne-t-elle sans connexion ?

Non. Le centre d'aide de X indique que la recherche avancée est disponible quand vous êtes connecté à X.com. La recherche ne coûte rien, mais elle demande un compte, donc un navigateur déconnecté ou un scraper non authentifié n'obtient aucun résultat du champ web.

Pourquoi min_likes: échoue-t-il dans le champ de recherche web ?

Le champ web et l'API utilisent des noms différents pour ce seuil. La référence d'opérateurs de X dit que min_likes: et min_reposts: sont les noms de l'API et que min_faves: et min_retweets: sont les noms de la recherche web, et que les noms web renvoient une erreur 400 depuis l'API. Changez de paire selon la surface que vous interrogez.

Jusqu'où remonte la recherche X ?

Jusqu'au premier post public de 2006 dans le champ web, d'après le centre d'aide de X. L'API découpe cette archive : recent search couvre les 7 derniers jours pour tout développeur, et full-archive search atteint 2006 pour les clients en paiement à l'usage et enterprise.

Puis-je utiliser near: et within: avec l'API X ?

Non. near: et within: sont des opérateurs réservés au champ de recherche web. Leurs équivalents dans l'API sont place:, place_country:, point_radius:[longitude latitude radius] et bounding_box:.

C'est has:videos ou has:video_link ?

X documente les deux. Sa page Search Operators liste has:video_link pour les vidéos natives de X, tandis que son introduction Search Posts et son tableau de migration de v1 vers v2 listent has:videos. Testez les deux contre une requête dont vous savez qu'elle renvoie des posts vidéo et gardez celui qui change le nombre de résultats.

Pourquoi ma requête renvoie-t-elle moins de posts que prévu ?

Les opérateurs qui exigent une conjonction sont la cause habituelle. La documentation de X indique que des opérateurs comme has:media, is:retweet et lang: ne peuvent pas tenir seuls dans une requête, il leur faut donc au moins un opérateur autonome à côté, comme un mot-clé ou from:. La deuxième cause, c'est la précédence : AND lie plus fort que OR, donc mettez des parenthèses autour de chaque groupe OR.

La limite de caractères de l'API X compte-t-elle les caractères ou les tokens ?

L'API X compte des caractères, pas des tokens, et la chaîne de requête entière compte dans la limite, opérateurs compris. Le recent search self-serve plafonne à 512 caractères, le full-archive double ce chiffre à 1 024, et l'enterprise monte à 4 096. Placer d'abord les opérateurs à conjonction obligatoire comme lang: et -is:retweet laisse plus de caractères pour les variantes de mots-clés.

Pourquoi -is:nullcast a-t-il besoin d'un signe moins devant lui ?

is:nullcast seul n'est pas un opérateur valide de l'API X, la documentation impose la négation -is:nullcast. Écrit ainsi, il retire les posts uniquement sponsorisés et garde les posts organiques dans le résultat. Il n'existe aucune forme positive pour demander directement les posts nullcast.

Comment vérifier si un opérateur X non vérifié, comme source: ou filter:trusted, fonctionne encore ?

On le teste sur une requête dont on connaît déjà le résultat, une fois avec l'opérateur et une fois sans, puis on compare le nombre de posts. Si le chiffre ne bouge pas, X ignore l'opérateur au lieu de l'appliquer. Ce test est nécessaire parce que X ne publie aucune liste des opérateurs retirés du standard v1.1 qui ont survécu à la transition.

Pourquoi d'anciens guides de recherche X listent-ils des opérateurs qui ne renvoient plus rien aujourd'hui ?

Beaucoup de guides reprennent les noms retirés du standard v1.1, comme toute la famille filter:, source: et card_name:, parce que ces noms fonctionnaient autrefois et n'ont jamais été formellement marqués obsolètes sur la plupart des sites qui les listent. La table de migration de X ne traduit qu'une partie de ces noms vers des noms v2 comme has:links ou is:retweet, et laisse la colonne v2 vide pour le reste. Mieux vaut tester tout opérateur incertain avant de construire une requête autour de lui.