HTTP QUERY est là. Faut-il réécrire vos endpoints de recherche ?

Vous expédiez probablement la « recherche » en POST vers /search avec un corps JSON parce que vos filtres ne tiennent pas dans une URL. Ça marche — mais vous avez renoncé à la cacheabilité, brouillé votre observabilité et enseigné à chaque client un schéma de payload sur mesure. La nouvelle méthode HTTP QUERY vise à corriger cela : une requête sûre, idempotente, qui autorise un corps comme POST, mais n’entend pas changer d’état comme GET. Le débat a refait la une cette semaine, avec de nouveaux articles explicatifs et des fils enflammés. Évitons l’ergotage et tranchons : devez-vous adopter QUERY en 2026 ?

Ce que QUERY change — et pourquoi c’est important

Aujourd’hui, vous avez trois mauvais choix pour des lectures complexes :

• GET avec une URL trop longue et un encodage bancal de filtres structurés (au risque de heurter les limites de proxy et de vous créer des casse‑têtes de signature).
• POST qui « lit » sur le plan sémantique, ce qui casse la mise en cache par défaut, induit les WAF en erreur et brouille votre analytique.
• Faire votre propre RPC sur POST et prier pour que le vous‑du‑futur se souvienne des règles.

QUERY propose une quatrième voie : traiter les lectures complexes comme des opérations sûres et idempotentes avec un corps de requête. Ça a l’air ennuyeux. Ça ne l’est pas. C’est l’occasion de regagner en performance, de réduire vos factures cloud et de remettre d’équerre la sémantique de votre API.

Les bénéfices concrets, chiffrés

• Gains côté CDN et cache d’edge : les applications très orientées recherche voient couramment 30–60 % des requêtes totales frapper des endpoints de lecture. Même un taux de hit d’edge conservateur de 20–30 % sur QUERY peut retirer 30–80 ms à la latence p95 et réduire de 10–25 % le CPU côté origin pour les charges de listes/recherche.
• WAF et observabilité plus clairs : Sûre + idempotente implique un traitement par défaut différent. Vous obtenez des tableaux de bord plus lisibles, des limites de débit plus simples et moins de temps passé à ajuster des règles pour laisser passer des POST inoffensifs.
• Meilleure ergonomie côté clients : plus de gymnastique d’URL. Les agents et SDK peuvent envoyer des filtres structurés sans ré‑encoder du JSON en chaînes de requête.

Mais il y a des pièges. Les middleboxes, navigateurs, SDK et spécifications ont été bâtis autour de GET/POST. QUERY est nouveau, donc il y a des angles vifs. Cartographions‑les.

Cadre de décision d’un CTO pour adopter QUERY

1) Quel est votre profil de problèmes réel ?

• Si votre trafic de lecture est dominé par des listes et facettes à faible cardinalité et fortement cacheables (ex. : navigation de catalogue, flux top‑N), QUERY offre un vrai ROI.
• Si vos lectures sont très personnalisées avec peu de réutilisation (ex. : tableaux de bord par utilisateur, états éphémères d’agents IA), les gains de cache seront limités ; n’attendez pas des miracles.
• Si vous luttez contre des limites de longueur d’URL via des proxies ou contre des complications de signature en GET, le corps de QUERY règle cela proprement.

2) Votre chemin réseau peut‑il transporter une nouvelle méthode ?

Beaucoup d’infrastructures laissent tomber ou maltraitent par défaut des verbes inconnus. Avant de vous engager, exécutez un test de transit de méthode sur chaque saut :

• SDK clients et piles mobiles : vérifiez qu’ils autorisent des méthodes arbitraires et ne les convertissent pas silencieusement en POST. Les navigateurs modernes et fetch acceptent des méthodes non standard, mais cela déclenchera un prévol CORS en cross‑origin.
• Edge/CDN : Cloudflare, Akamai et Fastly peuvent transmettre des méthodes inconnues ; les mettre en cache est une étape distincte, explicite, de configuration.
• Équilibreurs de charge et passerelles API : AWS ALB/NLB, API Gateway, GCP Load Balancers, NGINX, Envoy et HAProxy peuvent transmettre des méthodes arbitraires, mais des jeux de règles WAF peuvent bloquer par défaut. Testez avec un endpoint synthétique qui réémet :method.
• Service mesh : Envoy/Istio prennent en charge des méthodes personnalisées, mais vérifiez les route matchers, RBAC et filtres d’authz qui peuvent énumérer les verbes.

Mettez en place un canari de 48 heures qui émet des QUERY vers une route no‑op sur votre chemin de production et surveillez :

• 4xx/5xx par saut (edge, LB, gateway, service)
• Remappage de méthode inattendu (substitution POST/GET)
• Blocages WAF et challenges de protection bot

3) Avez‑vous besoin du support navigateur — ou est‑ce du server‑to‑server ?

Si votre front‑end appellera QUERY depuis le navigateur, acceptez le coût CORS et du prévol. Les méthodes non simples déclenchent une requête OPTIONS à chaque appel cross‑origin sauf si elle est mise en cache. Sur des interfaces à forte cadence, ce bruit se ressent.

• Atténuation : co‑localisez votre API sous le même eTLD+1 que votre application pour éviter complètement CORS, ou mettez agressivement en cache le prévol avec Access-Control-Max-Age (p. ex., 600–3600 secondes lorsque c’est sûr).
• Si vous ne pouvez pas éviter le cross‑origin, mesurez le taux de prévol ; dans de nombreuses SPA, 30–50 % des premières lectures par route déclencheront un prévol sans réglage.

4) Votre stratégie de cache et de clés a‑t‑elle du sens pour QUERY ?

Les caches indexent par méthode + URL (+ parfois en‑têtes/corps). Avec QUERY, le corps de votre requête participe désormais à l’identité de cache. C’est puissant — et dangereux.

• Canonicalisez les corps de requête : triez récursivement les clés JSON et supprimez les tableaux vides et les null pour que des filtres sémantiquement identiques se rencontrent dans le cache au lieu de se fragmenter.
• Bornez la cardinalité : ajoutez une normalisation imposée côté serveur (p. ex., bridez la taille de page à 100, top‑N de facettes) pour éviter des explosions de « clés de cache non bornées ».
• Négociation de contenu : si votre endpoint peut renvoyer plusieurs représentations, assurez‑vous que Vary est dimensionné correctement ; n’incluez pas par mégarde des en‑têtes larges qui font chuter votre taux de hit.
• Configuration CDN : la plupart des CDN ne mettent pas en cache le non‑GET par défaut. Vous aurez besoin de règles explicites ou de logique programmable à l’edge pour mettre en cache QUERY. Commencez avec un TTL court (p. ex., 10–60 s) et augmentez progressivement.

5) La description de votre API, la génération de code et vos clients suivront‑ils ?

OpenAPI 3.1 énumère les méthodes et n’inclut pas encore QUERY. Beaucoup de générateurs supposent les verbes standards.

• Contournement à court terme : documentez les endpoints QUERY comme des POST dans OpenAPI avec une extension x-http-method et implémentez la vraie QUERY au niveau de la gateway. Générez les clients sur POST ; basculez vers QUERY sous le capot pour les parcours d’appel S2S d’abord.
• Envisagez une double exposition : offrez temporairement POST et QUERY. Utilisez POST pour les clients navigateur si la friction CORS est élevée ; routez le server‑to‑server via QUERY pour le cache et la sémantique.
• N’oubliez pas l’ergonomie des SDK : normalisez les objets de filtres et proposez un builder stable afin que les clients ne génèrent pas des corps uniques mais équivalents qui ruinent votre cache.

6) Vos mécanismes d’auth, WAF et rate limits sont‑ils sensibles à la méthode ?

Les piles de sécurité font couramment des cas particuliers de GET vs POST. QUERY héritera probablement d’attentes proches de GET mais avec un corps qui pourrait perturber vos références.

• Réglage WAF : inspectez les limites de taille de corps et les parseurs. Si vous parsez du JSON pour la détection d’anomalies uniquement sur POST, étendez‑le à QUERY sinon vous manquerez des menaces. À l’inverse, n’alertez pas excessivement sur des payloads QUERY bénins et ne plombez pas votre p95.
• Modèle CSRF : QUERY est sûre, mais les navigateurs peuvent toujours l’envoyer avec des identifiants. Maintenez votre stratégie CSRF (cookies same‑site, jetons à double envoi pour les routes qui modifient l’état). Ne listez pas en blanc sur la seule base de la méthode.
• Rate limits : créez des buckets séparés pour QUERY afin d’éviter d’affamer les mutations sous des quotas partagés. Les méthodes sûres peuvent avoir des plafonds plus élevés avec un lissage de rafales plus strict.

Un plan de migration pragmatique

Phase 0: Inventaire et baseline (2 semaines)

• Dressez l’inventaire de tous les endpoints de lecture avec corps aujourd’hui (POST‑utilisé‑comme‑GET). Classez‑les par RPS et cacheabilité (taux de répétition, personnalisation, tolérance TTL).
• Établissez la latence p50/p95 actuelle, le temps CPU côté origin et les taux de hit CDN pour ces endpoints. Exposez un tableau de bord ventilé par méthode et route pour que les gains soient visibles.

Phase 1: Durcissement du chemin et canari (2–4 semaines)

• Exécutez le canari de transit de méthode de bout en bout. Corrigez les règles WAF et gateway. Ajoutez des étiquettes de méthode aux logs, traces et métriques.
• Apprenez à votre edge à mettre conditionnellement en cache le non‑GET. Sur Fastly, cela signifie une logique VCL/Compute@Edge ; sur Cloudflare, Workers/Rulesets. Commencez avec une propriété de staging et des clés synthétiques basées sur le hash d’un corps canonicalisé.

Phase 2: Double‑routez le meilleur candidat (4–6 semaines)

• Exposez votre recherche la plus RPS et la plus propice au cache à la fois en POST et en QUERY vers un unique handler. Normalisez les corps de requête côté serveur vers une représentation canonique avant d’atteindre le stockage.
• Routez d’abord le trafic server‑to‑server vers QUERY (services internes, cron, agents). Gardez les navigateurs en POST jusqu’à avoir mesuré l’impact CORS/prévol.
• Activez des TTL d’edge conservateurs pour QUERY (10–60 s). Surveillez les explosions de clés et les hot keys.

Phase 3: Étendre et optimiser (en continu)

• Déployez sur les 2–3 endpoints suivants si vous observez ≥15 % de décharge d’origine et ≥20 ms d’amélioration p95 sans pics d’erreurs.
• Augmentez les TTL lorsque la correction le permet ; ajoutez une invalidation douce via un rafraîchissement en arrière‑plan pour éviter les bouffées de stale après expiration de TTL.
• Resserrez les quotas : donnez à QUERY un bucket plus grand mais des rafales par IP plus strictes pour protéger l’infra de recherche lors de pics d’événements.

Détails d’ingénierie sur lesquels vous allez buter (à corriger maintenant)

Règles de canonicalisation

Mettez en œuvre une fonction unique et partagée qui transforme un objet de filtre arbitraire en une séquence d’octets canonique :

• Triez les clés récursivement, supprimez les tableaux vides et les null, forcez les nombres à un format fixe, bridez les plages selon des bornes imposées côté serveur.
• Sérialisez en JSON compact (sans espaces) et hashez (p. ex., SHA‑256) pour la composante de clé de cache.
• Documentez publiquement ces règles afin que les clients puissent prédire le comportement et éviter les ratés de cache.

Pagination et cohérence

QUERY rend tentante la mise en cache des résultats paginés. Faites‑le, mais définissez la cohérence :

• Si vous promettez « majoritairement frais », ciblez un TTL de 10–30 s et acceptez une légère dérive sur des inventaires très changeants.
• Si vous avez besoin de read‑your‑writes, ne mettez pas en cache les vues spécifiques à l’utilisateur ou ajoutez un contournement de cache quand la session comporte des écritures récentes (p. ex., dans les 5 s).
• Utilisez une pagination stable à curseur ; incluez le curseur dans la canonicalisation pour éviter de mélanger des pages incompatibles.

Correction de recherche et backends vectoriels

Si vous êtes en façade de backends hétérogènes (SQL pour les filtres, base vectorielle pour la pertinence), centralisez la fusion dans le handler QUERY. Cachez uniquement le classement final fusionné, pas les partiels, sauf bénéfice avéré à empiler des caches partiels. En pratique, la plupart des équipes sur‑ingénierent ceci ; commencez simple.

Analytics et SLO

Ajoutez QUERY à vos signaux clés (golden signals) et budgets d’erreurs. Ne l’enterrez pas sous « autres ». Créez des tableaux de bord qui séparent clairement la performance par méthode et la décharge d’origine. Pour la réponse aux incidents, assurez‑vous que les runbooks et les pages de statut côté client connaissent QUERY ; vous aurez moins de fausses alertes si votre équipe peut voir qu’une règle de cache spécifique à QUERY se comporte mal plutôt que « l’API est lente ».

Ergonomie des SDK et des agents

Les agents sont des clients bruyants. De petites différences de sérialisation font exploser les caches. Livrez un client léger qui :

• Canonicalise les corps de requête côté client avant envoi.
• Applique des valeurs par défaut conservatrices : tailles de page bornées, filtres dédupliqués, ordre de champs stable.
• Relance prudemment avec backoff exponentiel en cas de pépins réseau (QUERY est idempotente — exploitez‑le).

Arbitrages à ne pas balayer d’un revers de main

• Maturité de l’écosystème : les outils, OpenAPI et les SDK prêts à l’emploi ne parlent pas encore pleinement QUERY. Vous écrirez du glue code et des extensions. Prévoyez le temps.
• Coût du prévol navigateur : si votre front‑end est cross‑origin, attendez‑vous à 1 RTT supplémentaire sur les appels à froid à moins de restructurer l’hébergement ou d’ajuster le cache CORS.
• Surprises de middleboxes : certains réseaux d’entreprise et anciens proxies s’étrangleront encore sur des verbes inconnus. Gardez des fallback POST pour les parcours critiques jusqu’à ce que votre télémétrie prouve qu’il est sûr de les retirer.
• Discipline de correction du cache : une fois que les corps participent aux clés de cache, la moindre négligence coûte cher. Sans canonicalisation et garde‑fous, vous transformerez votre CDN en machine à explosion de clés.

À quoi ressemble un bon résultat au final

Après un déploiement rigoureux, voici ce que vous devriez voir sur vos graphes :

• Principales routes de recherche et de navigation passées de POST à QUERY (ou doublement exposées), avec des taux de hit d’edge entre 20–40 % et un CPU côté origin en baisse de 10–25 % sur les chemins de lecture.
• p95 sur listes/recherches en baisse de 30–80 ms pour les utilisateurs globaux ; pics de queue réduits pendant les montées de trafic.
• Alerting plus propre : faux positifs WAF en baisse ; pages d’incident capables d’isoler rapidement des régressions spécifiques à QUERY.
• Adoption SDK : 80 %+ des services internes et des agents utilisent le client canonique, avec des payloads favorables au cache.

Où les équipes nearshore s’insèrent

C’est un projet parfait pour un pod nearshore focalisé : réseau, passerelles, logique d’edge, ergonomie des SDK et ajustements d’observabilité. C’est transversal et nécessite un chevauchement horaire avec les équipes US pour toucher la configuration edge en sécurité (nous visons environ 6–8 heures de chevauchement). Le travail n’est pas glamour, mais il s’amortit via des économies d’infra et un modèle mental plus simple pour tous ceux qui bâtissent sur votre API.

Recommandation

Si votre produit a aujourd’hui un trafic de lecture significatif en POST‑avec‑corps, pilotez QUERY ce trimestre. Commencez en server‑to‑server, gardez des fallback POST côté navigateur jusqu’à ce que votre histoire CORS soit propre, et imposez la canonicalisation dès le premier jour. Utilisez des règles de cache explicites, surveillez votre espace de clés et rendez les gains visibles pour la finance et le produit. Si vos lectures sont surtout personnalisées ou proches des écritures, vous pouvez attendre — mais cessez d’ajouter de nouveaux endpoints POST‑comme‑GET. Concevez‑les comme des QUERY maintenant, même si vous exposez temporairement POST pour compatibilité.

Points clés

• QUERY vous offre des sémantiques proches de GET avec un corps de requête — parfait pour des lectures complexes sans hacks d’URL.
• Gains réels : 20–40 % de taux de hit sur les bons endpoints, 10–25 % de décharge d’origine et 30–80 ms gagnés sur le p95.
• Points durs : middleboxes, lacunes OpenAPI/SDK, prévol CORS et discipline des clés de cache.
• Adoptez par phases : canarisez la méthode, double‑routez les endpoints majeurs, commencez en S2S, puis étendez aux navigateurs.
• N’attendez pas que l’écosystème soit parfait — gardez simplement des fallbacks POST et publiez des règles de canonicalisation.