Convertisseur URL vers Markdown

Parce qu’un modèle de langage qui lit du HTML brut dépense l’essentiel de son budget de contexte sur des éléments qui ne portent aucun sens : attributs de classe, conteneurs imbriqués, scripts en ligne, balises de suivi. Sur une page typique, le texte utile représente une petite fraction des octets.

Le Markdown conserve la structure qui compte, titres, listes, tableaux, liens, et supprime tout le reste. Le résultat pèse généralement trois à dix fois moins que le HTML source et se raisonne bien plus facilement. Si vous avez déjà collé une page web dans une conversation et vu la réponse devenir vague, c’est la raison, et c’est la correction.

Il tente d’abord d’isoler le corps rédactionnel, en cherchant un élément main ou article, puis un conteneur dont la classe évoque un contenu d’article. Si rien de tout cela n’existe, il se rabat sur le body débarrassé de la navigation, de l’en-tête, du pied de page et des colonnes latérales.

Il retire aussi les scripts, les styles et les commentaires avant toute conversion. Cette étape compte plus qu’il n’y paraît : les cadriciels modernes sérialisent des charges applicatives entières dans des balises script, et un convertisseur qui ne les supprime pas d’abord produit un fichier rempli de JSON qu’aucun humain n’a écrit et dont aucun modèle n’a besoin.

C’est la même idée, appliquée depuis l’extérieur. Un nombre croissant de sites, dont celui-ci, servent une version Markdown de n’importe quelle page en ajoutant .md à son URL, pour que les agents récupèrent directement du texte propre. C’est une bonne convention et nous pensons que davantage de sites devraient l’adopter.

La plupart ne l’ont pas fait. Cet outil existe pour le reste du web : il produit le même résultat pour n’importe quelle page, sans que l’éditeur ait eu à faire quoi que ce soit. Si vous gérez un site, servir vos propres versions .md reste strictement préférable, parce que vous contrôlez la sortie et que l’agent n’a besoin d’aucun intermédiaire.

Non. Le convertisseur récupère la page en visiteur anonyme : il ne voit donc que ce que voit un lecteur déconnecté. Une page qui exige une authentification reviendra sous forme d’écran de connexion ou d’erreur, et c’est un choix de conception qu’on ne contourne pas.

Certaines pages publiques refuseront aussi. Les sites protégés par des dispositifs anti-robots agressifs peuvent rejeter une requête automatisée même quand le contenu est ouvert, et quelques-uns serviront une page de vérification à la place. Dans ce cas, l’outil le signale franchement plutôt que de renvoyer un fichier partiel qui paraît correct jusqu’à ce qu’on le lise.

Oui. Titres, listes ordonnées et non ordonnées, tableaux, liens, emphases et blocs de code survivent tous à la conversion, parce que ce sont les éléments qui portent du sens et non de la présentation. Les liens sont réécrits en URLs absolues par rapport à la page source, afin de rester résolvables une fois le texte sorti de votre site.

Ce qui ne survit pas, c’est la mise en page : dispositions en colonnes, images flottantes et tout ce qui repose uniquement sur le style s’aplatissent en ordre linéaire. C’est volontaire. Un modèle lit le texte en séquence, et reproduire fidèlement une mise en page visuelle produirait du bruit plutôt que de l’information.

Les usages courants sont de le coller dans un assistant pour résumer ou interroger, de l’donner à un agent comme matériau de référence, et d’archiver une page sous une forme qui reste lisible et comparable. Comme la sortie est du texte brut, elle s’intègre aussi proprement dans un dépôt, une application de notes ou un gabarit de prompt.

Un usage moins évident consiste à relire vos propres pages. Lire son contenu dépouillé de son design est un exercice sans pitié : des sections qui semblaient substantielles se révèlent tenir en trois phrases, et les passages sur lesquels un modèle butera sautent aux yeux. C’est une façon rapide de voir votre page comme une machine la voit.