RFC 10008 : la nouvelle méthode HTTP qui fait repenser les vitrines headless

En juin 2026, l'IETF a publié un nouveau standard HTTP dont presque personne ne parle dans le monde du frontend e-commerce. La RFC 10008 définit une nouvelle méthode HTTP : QUERY. Cela paraît anodin. Je crois que ça ne l'est pas.

Le problème que QUERY résout

Tout frontend headless vit de requêtes. Recherche, filtrage à facettes, listes de produits, requêtes GraphQL, personnalisation - au fond, ce sont toutes des requêtes structurées vers un point d'accès de données. Jusqu'à présent, nous n'avions exactement que deux options pour cela, et toutes deux sont insatisfaisantes.

GET est sémantiquement le bon choix : cacheable, safe (ne déclenche aucun changement d'état), idempotent (peut être répété sans risque). Mais la requête doit tenir dans l'URL. La RFC 9110 recommande de rester sous 8 000 octets de longueur d'URL - avec des structures de filtres complexes, des requêtes GraphQL imbriquées ou des recherches personnalisées, ce plafond arrive vite. De plus, les paramètres de requête finissent dans les logs, les journaux de proxy et l'historique du navigateur. Peu souhaitable pour des paramètres un tant soit peu sensibles.

POST résout le problème d'URL : la charge utile va dans le corps, de taille arbitraire, sans limite d'URL. Mais POST n'est sémantiquement ni safe ni idempotent - la couche HTTP ne peut pas savoir si un POST répété est inoffensif ou s'il déclenche un changement d'état. Conséquence : les CDN et les proxys edge ne cachent pas POST. C'est exactement pour cela qu'aujourd'hui presque chaque requête GraphQL contourne le CDN et frappe directement l'origine. Persisted queries, hachage de requêtes, contournements de CDN - ce sont tous des correctifs pour ce décalage fondamental. J'ai expliqué pourquoi de tels contournements finissent par coûter cher dans notre bilan composable sans détour.

Ce que QUERY fait différemment

La RFC 10008 comble cet écart avec une nouvelle méthode HTTP qui combine les deux propriétés. La définition formelle (résumé, §2, tableau 1 de la RFC) :

• Charge utile dans le corps - comme POST, pas de limite d'URL, pas de fuite via l'URL
• Explicitement safe - QUERY n'a aucun effet de bord ; le serveur peut le considérer comme une garantie
• Explicitement idempotente - un client HTTP, un proxy ou un CDN peut répéter des requêtes QUERY sans risque

Ce n'est pas une subtilité sémantique. C'est le fondement sur lequel les CDN et les caches edge prennent leurs décisions de mise en cache. Avec QUERY, des recherches complexes et des requêtes de filtrage peuvent à nouveau être mises en cache à la périphérie - la clé de cache inclut le corps de la requête et ses métadonnées (§2.7). La charge sur l'origine baisse, la latence baisse, les vitrines deviennent plus rapides sans aucune modification de la couche de logique métier.

La RFC 10008 introduit également le champ d'en-tête Accept-Query (§3). Il rend découvrable par les machines les formats de requête qu'un point d'accès prend en charge - une base propre pour la découverte de format, au lieu d'hypothèses codées en dur côté client.

Une remarque importante côté CORS : parce que QUERY ne figure pas dans la liste des méthodes safelistées CORS du standard Fetch du WHATWG, elle déclenche une requête de préflight (§4, considérations de sécurité). Ce n'est pas un bug ; c'est la conséquence attendue d'une nouvelle méthode. Il faut en tenir compte côté navigateur.

Être honnête sur le chemin d'adoption

GraphQL-over-QUERY ne fait pas partie de la RFC 10008 et n'est pas encore standardisé. La RFC 10008 définit la méthode, pas les formats de charge utile. La manière dont les clients GraphQL adopteront QUERY sera une discussion à part. Je le mentionne ici parce que cela pourrait, à moyen terme, rendre superflus les contournements par persisted queries - comme une possibilité, pas comme une promesse.

Et même quand les clients seront prêts : les serveurs, les CDN, les reverse proxys et les navigateurs doivent tous prendre en charge QUERY avant que le standard soit utilisable en production de façon utile. C'est un chemin de plusieurs années. Si j'en parle maintenant, ce n'est pas parce que QUERY sera prêt pour la production demain. C'est parce que le bon moment pour réfléchir à un standard n'est pas celui où il a déjà été déployé partout.

Pourquoi c'est une question stratégique - pas seulement technique

C'est là que ça devient intéressant, et c'est là que la décision d'architecture que nous avons prise chez Laioutr me paraît importante.

Si vous avez construit un frontend headless en tant que logiciel sur-mesure - votre propre projet Next.js, une application Nuxt, votre propre couche d'API - vous devrez implémenter le support de QUERY dans chaque vitrine individuellement. Toucher à la couche de transport. Repenser la logique de cache. Gérer CORS et le préflight. Définir des stratégies de retry. Configurer les clés de cache. Tout tester. Par projet. Encore et encore, pour chaque client, pour chaque vitrine.

Ce n'est pas un problème technique résolu une fois pour toutes. C'est un problème de multiplication : autant de projets que de vitrines.

Si vous construisez sur une plateforme, votre point de départ est différent. Chez Laioutr, nous abstrayons la couche de données et de transport. Nos clients composent des sections et des blocs - ils ne câblent pas d'appels HTTP à la main. La plateforme possède la couche où QUERY devient pertinente.

Ce que cela signifie en pratique : dès que l'écosystème sera prêt - serveurs, CDN, navigateurs, clients GraphQL - nous pourrons adopter le standard de manière centralisée. Chaque vitrine sur Laioutr en profite sans qu'un seul client ne touche à son code. Pas de 50 tickets de migration en parallèle. Pas de divergence entre projets anciens et récents. C'est la même logique qui nous permet de rendre possible un changement de fournisseur sans replateforming complet - la plateforme absorbe le changement, pas le client.

Nous préparons la plateforme à cela dès aujourd'hui. Non pas parce que QUERY passe en production demain, mais parce que les décisions d'architecture censées rester élastiques plus tard doivent être prises tôt.

Ce que cela signifie pour vous - aujourd'hui

Si vous construisez en headless sur du logiciel sur-mesure, la RFC 10008 n'est pas une priorité opérationnelle aujourd'hui. Mais c'est un bon moment pour poser deux questions.

Première question : qui, dans votre architecture, possède la couche de transport ? Si la réponse est « nous-mêmes - par projet », c'est un signal sur le type d'efforts que des changements de protocole comme celui-ci vont engendrer. L'indépendance du frontend devient un critère d'achat pour exactement ces raisons - plus à ce sujet dans notre récap hebdomadaire.

Deuxième question : lesquels de vos contournements actuels - persisted queries, hachage de requêtes, contournements de CDN - résolvent en réalité un problème qu'un fondement HTTP plus propre ferait disparaître de lui-même ?

Une plateforme de gestion du frontend n'est pas là pour vous retirer ces questions. Elle est là pour que vous n'ayez pas à encoder vos réponses dans du code de couche de transport.

La RFC 10008 est publiée : https://www.rfc-editor.org/rfc/rfc10008.html. Auteurs : J. Reschke (greenbytes), J. M. Snell (Cloudflare), M. Bishop (Akamai). Standards Track, juin 2026.

Si vous construisez en headless et voulez comprendre concrètement ce que QUERY signifie pour votre architecture - écrivez-moi ou réservez une démo.

Construire sur une base indépendante du frontend

Composable Headless Frontend · Performance & Core Web Vitals · Agentic Frontend Management Platform

Questions fréquentes sur la RFC 10008

Qu'est-ce que la RFC 10008 ?

La RFC 10008 standardise la méthode HTTP QUERY : une méthode de requête sûre et idempotente comme GET, mais qui peut porter un corps de requête comme POST. Elle comble l'écart de longue date entre GET (sans corps, longueur d'URL limitée) et POST (un corps, mais ni sûr, ni idempotent, ni cacheable).

Qu'est-ce que la méthode HTTP QUERY change pour les frontends headless ?

Une storefront peut envoyer des requêtes complexes de recherche, de filtrage et de type GraphQL dans un corps de requête, tandis que la réponse reste cacheable et idempotente. Pour les pages de listing produit, la recherche à facettes et le search-as-a-service, cela signifie un cache au niveau CDN que POST ne pouvait jamais offrir, sans entasser l'état dans des URL toujours plus longues.

HTTP QUERY est-il identique à GraphQL via GET ?

Non. GraphQL via GET ne fonctionne que pour de petites requêtes, car toute la requête doit tenir dans l'URL et les limites de longueur d'URL sont vite atteintes. HTTP QUERY porte la requête dans le corps sans limite de taille pratique et est défini comme sûr et idempotent, de sorte que les intermédiaires et les CDN peuvent mettre la réponse en cache.

Quand pouvons-nous utiliser la RFC 10008 en production ?

L'adoption dépend du déploiement de la prise en charge côté client, serveur et CDN. La voie pragmatique aujourd'hui est la détection de fonctionnalité avec repli sur POST : utiliser HTTP QUERY là où toute la chaîne le prend en charge, et revenir à POST ailleurs, pour que rien ne casse.