Compiler Explorer et la promesse d’URL pérennes

• Compiler Explorer utilisait au départ une approche consistant à stocker tout l’état directement dans l’URL
• Les URL devenant trop longues, le service de raccourcissement d’URL goo.gl de Google a été adopté, ce qui a entraîné une architecture complexe avec plusieurs redirections
• À partir de 2018, en raison des limites de longueur des URL et des difficultés de maintenance, l’outil est passé à une architecture reposant sur un stockage interne basé sur S3 et DynamoDB
• Mais avec l’arrêt de goo.gl par Google en août 2025, il devient nécessaire de gérer soi-même la pérennité des anciens liens raccourcis
• À ce jour, plus de 12 000 liens legacy ont été sauvés, ce qui montre l’importance de la préservation des connaissances en programmation et d’une exploitation de service durable

---

Pérennité des liens Compiler Explorer et leur histoire

Conception initiale et raisons de l’adoption de goo.gl

• En 2012, Compiler Explorer a adopté une architecture qui encodait directement dans l’URL tout l’état du compilateur
• Plus les informations d’état augmentaient, plus les URL devenaient excessivement longues
• Pour raccourcir les URL, le service de raccourcissement goo.gl de Google a été mis en place en 2014
  • Il fournissait des liens courts au format goo.gl/abc123, qui redirigeaient vers l’URL longue d’origine avant de restaurer l’état
• L’interdiction des liens raccourcis par Stack Overflow en 2016 a imposé des contraintes à cette approche
  • Tous les liens fondés sur goo.gl ont été concernés en raison du risque de dissimulation de liens malveillants
• Comme il ne voulait pas stocker les données des utilisateurs, un contournement provisoire a consisté à créer un chemin interne au format godbolt.org/g/abc123
  • L’accès à godbolt.org/g/abc123 redirigeait ensuite vers goo.gl/abc123
  • Puis, au final, vers l’URL longue sur godbolt.org
  • Cette succession de redirections a rendu l’architecture plus complexe
• Par la suite, l’utilisation de l’API Google a permis de simplifier en partie le mécanisme de redirection

Mise en place d’un stockage interne et gestion des liens

• À partir de 2018, les limites de longueur des URL et l’inconfort lié à la compression des données sont devenus des problèmes récurrents
• Mise en place d’une structure de stockage interne reposant sur S3 et DynamoDB
  • Les entrées sont hachées puis stockées sur S3 sous forme de documents JSON
  • Lorsqu’on accède à un lien court (godbolt.org/z/hashbit), le mapping est recherché dans DynamoDB
  • Un mécanisme de contrôle a été ajouté pour contourner les cas où la valeur de hachage contenait des mots inappropriés, notamment en ajoutant un élément aléatoire
  • Cela a permis de traiter les problèmes de liens fondés sur des hachages inappropriés, avec des bugs rencontrés au passage (par ex. issue #1297)
• Le format d’adresse godbolt.org/g/abc123 reste toujours pris en charge aujourd’hui
• Malgré la communication officielle de Google, le service goo.gl est passé en lecture seule et doit être totalement arrêté en août 2025
• Les liens raccourcis fondés sur goo.gl ne pourront donc plus être résolus
• Comme les liens du type godbolt.org/g/abc123 peuvent voir leur durée de vie prolongée via une gestion directe, un travail structuré de sauvetage a été lancé sur ce format

Collecte massive et archivage des liens legacy

• Récemment, les liens legacy ont été explorés et mis en base de données à partir de toutes les sources possibles (recherche, dumps de données, logs web, etc.)
  • API de recherche web Google
  • API GitHub
  • Logs des serveurs internes
  • Dumps de données Stack Overflow sur archive.org
  • Données de pages web archivées sur Archive.org
• Environ 12 298 liens raccourcis ont pu être restaurés
• En interne, l’utilisation d’une base de données de liens propre a commencé à remplacer goo.gl (PR associée : #7724)
• Les liens godbolt.org/g/abc123 qui n’ont pas encore été découverts continueront d’être collectés et préservés
• Si la communauté connaît encore des liens non enregistrés, elle est invitée à y accéder directement ou à prévenir les administrateurs afin d’enrichir la base de données

Philosophie du projet et importance de posséder son infrastructure

• Ce cas montre le risque qu’il y a à dépendre uniquement de la pérennité d’un service externe (comme Google) pour une infrastructure critique
• La gestion des liens raccourcis et la structure de sauvegarde n’étaient qu’une solution provisoire ; promettre de véritables URL permanentes suppose de gérer soi-même l’ensemble du service
• En sauvant ces anciens liens comme dans une forme d’archéologie numérique, on réalise que chacun d’eux est la trace d’un partage de connaissances, d’une question ou d’une explication de concept
• Cet effort de stockage et de préservation est aussi directement lié à l’archivage de l’histoire de la communauté de la programmation
• Si vous tombez sur un ancien lien Compiler Explorer, cliquer dessus dès maintenant peut contribuer à la préservation des connaissances sur Internet
• Cette fois, en s’appuyant sur une infrastructure contrôlée directement plutôt que sur un tiers, il devient possible de tenir la promesse de pérennité

Disclaimer

• Ce texte a été rédigé par un humain, avec recours à un LLM pour la recommandation de liens et la vérification grammaticale

[GN⁺]

Avis Hacker News

• Avant 2010, l’idée que les liens duraient pour toujours semblait aller de soi, donc j’utilisais activement les favoris du navigateur, mais avec le temps j’ai constaté que beaucoup de favoris devenaient en pratique inutilisables à cause de la dégradation des liens (link rot), puis j’ai pris l’habitude d’enregistrer les pages web en PDF, et après la popularisation du mode lecture (Reader view), je suis passé à une méthode consistant à copier le contenu depuis ce mode et à l’enregistrer dans des fichiers RTF
  • J’utilise l’extension SingleFile pour archiver toutes les pages que je visite, la configuration est assez simple, mais il faut faire attention au fait que cela prend beaucoup d’espace de stockage, par exemple mon répertoire d’archives de pages web atteint 1,1 To lien GitHub de SingleFile
  • En installant l’extension de navigateur officielle Web Archive, on peut configurer l’archivage automatique de toutes les pages visitées
  • Ma méthode consiste à retenir les informations importantes ou au moins l’endroit où je peux les retrouver, et comme je suis toujours en vie, on peut dire que ça marche plutôt bien
  • Je me demande s’il existe une extension de navigateur qui redirige automatiquement vers web.archive.org lorsqu’un lien expire
  • Il y a aussi la possibilité d’utiliser le format WARC avec WebRecorder infos sur WARC, WebRecorder
• Collaborer avec le projet Goo.gl d’ArchiveTeam pourrait être utile détails du projet, les raccourcisseurs d’URL étaient vraiment une idée détestable présentation d’URLTeam
  • D’après l’état en temps réel du projet, 7,5 milliards d’URL goo.gl ont été découvertes sur 42,5 milliards lien vers l’état en direct
  • ArchiveTeam a probablement procédé par force brute sur les URL raccourcies Goo.gl plutôt que de s’appuyer sur des liens « connus », donc la plupart ou la totalité des URL de Compiler Explorer doivent se trouver dans leurs données, d’où l’idée que ça vaudrait le coup de les contacter
• L’idée que les URL durent pour toujours relevait d’un idéal, mais en réalité 99 % des URL ne sont pas permanentes, donc je me demande s’il ne vaut pas mieux construire la technologie en partant du principe que l’infrastructure n’est pas durable, plutôt que de continuer à se battre dans un combat perdu d’avance
  • Oui, il faut construire la technologie en supposant que l’infrastructure n’est pas permanente, et je pense aussi qu’il faut éviter d’utiliser un service de raccourcissement d’URL comme s’il s’agissait d’une infrastructure
  • L’URN (Uniform Resource Name) est un système conçu pour donner une identité à une ressource indépendamment de son emplacement, mais il n’a jamais percé, et les services de raccourcissement d’URL n’ont fait qu’essayer vaguement quelque chose de similaire sans vraiment réaliser ce concept explication Wikipédia sur l’URN
  • Les noms de domaine changent souvent de propriétaire, et même des URL qui paraissent permanentes peuvent avec le temps se transformer en liens de phishing malveillants
  • Une URL n’identifie que l’emplacement d’une ressource sur le réseau, pas la ressource elle-même, donc elle n’a aucune raison d’être permanente ni unique, c’est précisément pour cela qu’on parle d’« Uniform Resource Locator », et c’est en réponse à ce problème que le Digital Object Identifier a été inventé en 1997
• Il y a quelque chose de poétique dans le fait d’abuser des services de raccourcissement de liens comme d’une base de données, puis de devoir ensuite retrouver ces précieux liens aux quatre coins d’Internet
  • Le but initial d’un raccourcisseur d’URL est de transformer une URL longue en URL courte, le vrai problème, ce sont plutôt les gens qui abusent des domaines pour dissimuler du spam, des arnaques ou des sites illégaux derrière des URL raccourcies
  • Eux aussi semblent s’en être servis uniquement pour compresser l’URL, c’était en fait leur URL elle-même qui contenait l’état du compilateur comme une « base de données »
• https://killedbygoogle.com/, Google Go Links (2010~2021) était un service de raccourcissement d’URL de Google qui a fonctionné environ 11 ans avant d’être arrêté il y a 4 ans, et les clients Google Workspace pouvaient aussi utiliser des domaines personnalisés
  • Empêcher simplement la création de nouvelles URL raccourcies (« minting new ones ») au moment de la fermeture du service ne me semble pas très grave, ce qui est bien plus injustifiable, c’est de désactiver aussi les URL déjà créées, d’autant plus que Google continue apparemment à utiliser cette fonctionnalité en interne dans certaines applications
• La deuxième chose qui m’a sauté aux yeux, c’est la mention « Cet article a été écrit par un humain, mais les suggestions de liens et la vérification grammaticale ont été faites par un LLM », j’ai l’impression d’assister au début d’une nouvelle tendance
  • Il est intéressant de voir que les gens sentent qu’ils doivent ajouter ce genre de mention
  • Personnellement, je n’en vois absolument pas la nécessité, si le contenu se suffit à lui-même, cela devrait être suffisant, et si sa qualité est médiocre, peu importe qu’il ait été généré par une IA ou écrit par un humain, les personnes qui veulent ce genre de mention semblent probablement l’utiliser comme une sorte d’outil de jugement par procuration, en considérant le contenu généré par IA comme intrinsèquement de moindre qualité faute de pouvoir évaluer elles-mêmes le contenu
• Je suis surpris que Google cherche à supprimer même la version en lecture seule, je me demande s’ils craignent un risque juridique lié au maintien de redirections de liens privés
  • Je ne connais pas les détails exacts en interne, mais il est possible qu’ils veuillent couper un service qui dépend de bibliothèques ou de runtimes anciens ou vulnérables, et au fond, même si le coût est minime, ils choisissent quand même de l’arrêter pour réduire les dépenses, ce qui donne l’impression qu’ils ne se soucient ni de la bonne volonté de l’entreprise ni des promesses passées
• Je me demande s’il n’existerait vraiment aucun moyen de demander à un employé de Google d’extraire de la base de données uniquement les URL raccourcies qui redirigent vers godbolt.org
• Pour être honnête, à moins qu’une fondation suffisamment bien financée n’intervienne, Compiler Explorer et godbolt.org semblent eux aussi condamnés à ne pas durer éternellement, et peut-être qu’un jour toutes les informations finiront abstraites et encapsulées dans un gigantesque modèle avec d’énormes paramètres
  • Jusqu’ici, nous nous en sommes bien sortis, cette semaine marque le 13e anniversaire, et même si tous les sponsors arrêtaient leur soutien, nous avons accumulé assez de fonds pour tenir encore un peu plus d’un an, nous réfléchissons aussi récemment à créer une fondation, en réalité le point faible n’est pas le manque d’argent mais le fait qu’une seule personne (moi) constitue un point de défaillance unique
  • C’est vrai, désormais le moment où un lien Compiler Explorer cessera de fonctionner coïncidera vraiment avec la disparition de Compiler Explorer lui-même, d’ici là les liens resteront vivants, et je considère surtout les liens Compiler Explorer laissés dans les rapports de bugs comme très précieux, moi aussi j’inclus directement le code dans le rapport avec ce type de lien, ainsi que le compilateur et la version utilisés, je ne pense pas que Compiler Explorer disparaisse bientôt, mais rendre ainsi un rapport de bug autonome permet de se prémunir contre une disparition inattendue
  • Cela me rappelle la blague selon laquelle, d’après le théorème du no-hiding, l’information survit éternellement
• Même maintenir un domaine a un coût, donc je ne vois pas comment une URL pourrait durer éternellement, je me demande si la disparition des URL n’a pas aussi quelque chose de positif, l’humanité préserve spécialement les informations jugées précieuses, et le reste disparaît naturellement dans l’histoire
  • Mais les historiens veulent justement davantage de ces données « inutiles », car elles permettent de mieux comprendre la vie réelle et son contexte à l’époque, si l’on pouvait prendre une machine à remonter le temps, je me demande comment les historiens d’ici mille ans regarderont cette période où la plupart des informations ont disparu avec l’effacement des médias numériques
  • Je suis moi aussi d’accord avec l’idée qu’il peut y avoir de bons côtés à la disparition des URL, j’ai écrit à ce sujet sur l’évanescence d’Internet