Télécharger les sites web qui utilisent Chicago Boss

À propos de Chicago Boss

Erlang est né de la commutation téléphonique, où les processus plantent en permanence sans que le système ait le droit de s’en apercevoir, et pendant un temps plusieurs personnes ont tenté de transposer ce modèle de fiabilité dans le développement web ordinaire. Chicago Boss fut l’une de ces tentatives. Écrit en Erlang, publié sous licence MIT par Evan Miller, avec une première version publique en 2010, il a pris la forme des frameworks que les développeurs web connaissaient déjà : modèle-vue-contrôleur, gabarits à la manière de Django, routage d’URL, un mappeur objet couvrant plusieurs bases de données, les sessions, le courrier et l’internationalisation, et par-dessus une gestion réseau entièrement asynchrone qui rendait les connexions de longue durée bon marché plutôt qu’exotiques.

Adopter un framework pareil en disait plus sur l’équipe que sur le site. Personne n’arrive à un framework web Erlang en parcourant des tutoriels pour débutants. Soit l’équipe avait déjà des exploitants à l’aise avec cet environnement d’exécution, soit elle avait un produit dont les besoins de concurrence rendaient l’environnement digne du problème de recrutement qu’il posait, et poser par-dessus une couche de forme familière était une manière de rendre ce choix vivable pour les développeurs qui devaient travailler dedans. Le public visé par ce framework est en grande partie passé à Elixir et à son propre framework web, qui offrait le même environnement d’exécution avec une surface plus accueillante, si bien que les déploiements qui subsistent ont plutôt tendance à être des systèmes anciens entretenus par ceux qui les ont bâtis.

Les frameworks côté serveur forment une classe de technologies difficile à détecter, et être honnête là-dessus compte davantage que n’importe quel chiffre qu’on y attache. Un framework côté serveur n’est visible que lorsqu’il s’annonce lui-même : un en-tête de réponse, un nom de cookie, un format de session, une page d’erreur par défaut, une convention d’URL. Un proxy inverse, un réseau de diffusion ou une politique d’en-têtes resserrée peut faire disparaître chacun de ces signes sans qu’une seule ligne de code applicatif change. En octobre 2026 notre décompte pour cette empreinte s’établit à 1, et la lecture correcte est celle des sites qui laissent encore fuir une signature identifiable, plutôt que celle des sites qui font tourner le framework.

C’est précisément cet écart de détection qui fait qu’une liste constituée vaut mieux que des suppositions. Une requête domaine par domaine confirme une intuition sur un seul hôte. La liste de tous les domaines où la signature survit est un inventaire d’installations de longue durée sur cet environnement d’exécution, et c’est ce qu’il vous faut si vous vendez de la maintenance pour lui, si vous étudiez comment les populations de frameworks vieillissent et disparaissent, ou si vous cherchez des systèmes dont les propriétaires ont un problème de migration qu’ils n’ont pas encore planifié.