Télécharger les sites web qui utilisent GraphQL

À propos de GraphQL

GraphQL est une spécification plutôt qu’un produit, ce qui en fait un objet inhabituel à enregistrer dans un dataset au niveau des sites. Personne ne l’installe comme on installe une extension. Une équipe décide que son front-end ira chercher les données au travers d’un langage de requête typé adressé à un point d’accès unique, et ce que nous détectons est le résidu de cette décision dans le code que le navigateur télécharge.

La décision est architecturale, donc le signal l’est aussi. Un site qui utilise le langage de requête a un front-end découplé de sa couche de données, une chaîne de compilation qui empaquette du JavaScript, et des ingénieurs qui ont choisi un style d’API plutôt que d’accepter ce qu’un système de gestion de contenu produisait. Le commerce headless, les interfaces qui ressemblent à des applications et les plateformes de contenu qui alimentent plusieurs front-ends ont tous tendance à atterrir ici. Les sites vitrines rendus côté serveur, non. La présence marque un site bâti par une équipe de développement, et pour un fournisseur qui vend à des équipes de développement cette distinction vaut plus que le décompte brut.

La gouvernance relève de GraphQL Foundation au sein d’une fondation open source plus large, la spécification porte la licence MIT, et l’implémentation de référence ainsi que les bibliothèques clientes qui l’ont diffusée sont écrites en JavaScript. Publié en 2015 après avoir été développé à l’intérieur d’une grande plateforme sociale, le langage de requête n’a pas de numéro de version qui compte sur le terrain, parce que la spécification évolue par ajouts et qu’aucun client n’annonce une version à une page, ce qui explique que notre fiche ne montre aucune donnée de version.

En octobre 2026 nous détectons GraphQL sur 66 948 sites, dont 57 822 que nous localisons en Allemagne, avec un mélange de domaines qui penche vers .com. Une concentration de cette taille dans un seul pays vient en général d’un petit nombre de grandes plateformes, d’hébergeurs ou de générateurs de sites qui livrent le même paquet sur de nombreux sites clients, plutôt que d’autant de décisions d’ingénierie indépendantes. Quiconque se sert de la colonne pays pour argumenter sur l’adoption nationale devrait d’abord vérifier sur quelles plateformes se trouvent les domaines, parce qu’un seul système de boutique ou constructeur de sites largement utilisé peut à lui seul déplacer un chiffre national.

La détection a un plafond infranchissable qu’il vaut la peine de comprendre avant d’acheter. Nous pouvons voir le langage de requête quand un point d’accès est référencé dans le JavaScript livré, quand une bibliothèque cliente connue est empaquetée, ou quand un point d’accès public répond de la façon attendue. Une grande part de l’usage réel est invisible, parce qu’une bonne partie se passe entre serveurs, à l’intérieur d’applications mobiles, ou derrière une passerelle qui remet au navigateur tout autre chose. Le décompte mesure l’usage visible par le navigateur, et le navigateur n’est qu’un consommateur parmi plusieurs.

C’est précisément cet écart qui rend la liste utile en agrégat plutôt qu’au cas par cas. Confirmer un domaine ne demande qu’une requête. Dimensionner la population des front-ends pilotés par API, la découper par plateforme et par pays, la regarder croître face aux solutions rendues côté serveur, et en extraire le sous-ensemble qui fait aussi tourner un framework ou un système de commerce donné sont autant de questions qui portent sur un ensemble. Les fournisseurs d’outils pour développeurs, les entreprises d’infrastructure d’API et les analystes qui couvrent l’architecture front-end veulent la forme de l’ensemble, pas l’une de ses lignes.