Télécharger les sites web qui utilisent Quill

À propos de Quill

Un éditeur de texte enrichi fait partie des rares composants front-end qui vous disent à quoi sert un site. Personne ne charge Quill pour afficher une page marketing. La bibliothèque apparaît là où les gens écrivent sur le site au lieu d’y lire : zones de commentaires, tickets d’assistance, outils internes, back-offices de publication, prises de notes, messagerie, partout où du contenu est produit plutôt que consommé.

La conception technique explique pourquoi les équipes le choisissent. Paru en 2014 sous licence BSD et écrit en JavaScript, l’éditeur représente un document comme une suite d’opérations plutôt que comme un bloc de balisage, ce qui donne à une application un contrôle programmatique sur le contenu et une base exploitable pour l’édition collaborative. Des formats, des modules et des thèmes sur mesure l’étendent, et il ne lie pas l’application environnante à un framework particulier.

En octobre 2026 nous détectons l’éditeur sur 10 265 sites dans la catégorie Rich text editors, dont 3 817 aux États-Unis, avec .com comme suffixe dominant. La répartition reflète les endroits où les produits logiciels sont conçus et vendus plutôt que là où se concentre le web généraliste, ce à quoi on peut s’attendre de la part d’un composant qui n’apparaît qu’une fois qu’un site a un utilisateur authentifié ou un formulaire qui mérite d’être pris au sérieux.

Le comportement des versions renforce le constat. Les données contiennent 16 versions, et 1.3.6 est celle que nous voyons le plus souvent, une concentration sur une lignée de publication de longue durée plutôt qu’un étalement sur les plus récentes. Les éditeurs coûtent cher à remplacer, parce que le contenu stocké est façonné par le modèle de document de l’éditeur lui-même, si bien qu’une migration touche aux données historiques et ne se réduit pas à remplacer une dépendance. Les équipes repoussent ce chantier, et le report se lit comme une population installée sur une lignée éprouvée bien après l’apparition de travaux plus récents.

Deux limites méritent d’être énoncées. La première est que la plupart des éditeurs se trouvent derrière une authentification et que nous explorons ce qui est accessible publiquement, donc une grande part des déploiements réels nous échappe par construction. La seconde est l’empaquetage : les applications qui compilent l’éditeur dans un fichier applicatif unique ne laissent rien de reconnaissable dans la page. Ces deux effets jouent dans le même sens, ce qui veut dire que le décompte est un plancher et que la population visible penche vers les formulaires ouverts au public et vers les sites qui chargent la bibliothèque comme une ressource séparée.

Dans ces limites, la liste répond à des questions qu’une requête domaine par domaine ne peut pas traiter. Les fournisseurs qui vendent de l’infrastructure de collaboration, de la modération, du filtrage de spam ou du stockage de contenu veulent savoir quels sites acceptent ne serait-ce que du contenu rédigé par les utilisateurs, puisque c’est la condition d’entrée de toute la catégorie. Les chercheurs en sécurité veulent la population parce que les éditeurs sont une source récurrente de problèmes d’assainissement, et une faille d’assainissement pèse à proportion du nombre de sites qui exposent le composant. Les projets d’éditeurs concurrents veulent connaître la taille et la géographie du parc installé avant de décider si un chemin de migration vaut la peine d’être construit. Toutes ces questions portent sur une population, elles se règlent à partir d’un extrait et pas domaine par domaine.