Ce convertisseur de Markdown en HTML transforme du Markdown simple en HTML propre et prêt à l’emploi pendant la saisie. Un petit analyseur Markdown fonctionne dans votre navigateur : aucune donnée n’est envoyée à un serveur.
Tapez ou collez sur la gauche. La sortie apparaît sur la droite, soit en HTML brut, soit sous forme d'aperçu rendu. Pas d'attente, pas de bouton de soumission, pas de rechargement de page.
Ce qu'il convertit :
- Titres, paragraphes, gras, italique, barré, liens, images, guillemets et règles horizontales
- Listes ordonnées, non ordonnées et imbriquées, ainsi que des listes de tâches de style GitHub avec des cases à cocher
- Tables de canalisation, y compris l'alignement des colonnes à partir de la ligne
:---: - Blocs de code fermés, mis en évidence dans l'aperçu avec highlight.js (EN)
- Notes de bas de page (
[^1]) et listes de définitions - Présentation YAML, qui est supprimée du haut du document
- HTML brut en ligne, qui passe inchangé
Construit pour de vrais flux de travail. L'éditeur a des numéros de ligne, une barre d'outils de formatage, et un bon undo / redo. Tab insère deux espaces. Les caractères appariés comme **, _ et les backticks se ferment automatiquement autour du texte sélectionné. Votre brouillon est sauvegardé dans le navigateur et restauré au rechargement.
Le panneau de sortie vous donne les options suivantes : copier du HTML brut, copier un document HTML autonome complet avec des styles incorporés, copier du texte brut, copier le Markdown original ou télécharger le résultat sous forme de fichier .html.
Le mode sombre est inclus. Les panneaux sont redimensionnables. La position de défilement se synchronise entre l'éditeur et l'aperçu. Les documents de plus de 20 000 caractères sont toujours convertis, avec un court délai et un badge d'avertissement.
Comment utiliser ce convertisseur Markdown en HTML
- Collez votre Markdown dans le panneau de gauche, ou cliquez sur Sample pour charger un document qui utilise toutes les fonctionnalités prises en charge.
- Utilisez la barre d'outils pour mettre une sélection en gras, en italique ou en code, ou pour insérer des titres, des listes, des citations, des liens, des images, des blocs de code et des notes de bas de page.
- Basculez entre l'onglet HTML, qui affiche le balisage généré, et l'onglet Aperçu, qui le restitue.
- Cliquez sur Copier HTML pour un fragment que vous pouvez coller dans un CMS, ou Copier entièrement pour une page complète avec une petite feuille de style intégrée.
- Cliquez sur Télécharger pour enregistrer la sortie sous le nom
converted.html.
Un court document GFM comme celui-ci :
## Release notes
- [x] Tables with **alignment**
- [ ] ~~Autolinks~~
| Feature | Status |
|:--------|-------:|
| Footnotes[^1] | Done |
[^1]: Rendered at the bottom of the document.Sort comme :
<h2 id="release-notes">Release notes</h2>
<ul>
<li><input type="checkbox" disabled checked> Tables with <strong>alignment</strong></li>
<li><input type="checkbox" disabled> <del>Autolinks</del></li>
</ul>
<table>
<thead>
<tr><th style="text-align:left">Feature</th><th style="text-align:right">Status</th></tr>
</thead>
<tbody>
<tr><td style="text-align:left">Footnotes<sup><a href="#mdconv-fn-1" id="mdconv-fnref-1">[1]</a></sup></td><td style="text-align:right">Done</td></tr>
</tbody>
</table>
<div class="mdconv-footnotes">
<ol>
<li id="mdconv-fn-1">Rendered at the bottom of the document. <a href="#mdconv-fnref-1">↩</a></li>
</ol>
</div>Les titres reçoivent un id généré à partir de leur texte, donc les liens d'ancrage fonctionnent immédiatement.
Ce que l'outil ne fait pas
- Les URL nues ne sont pas transformées en liens. Écrivez-les comme
[text](url). - L'onglet HTML affiche votre balisage exactement tel que généré, y compris tout HTML brut que vous avez tapé. Seul le volet Aperçu passe par un nettoyage de la liste d'autorisation qui supprime les scripts, les gestionnaires d'événements et les URL non sécurisées avant le rendu.
- La coloration syntaxique est appliquée uniquement dans l'aperçu. Le code HTML copié contient des blocs
<pre><code class="language-js"> - Si vous n'avez besoin que des mots, le convertisseur de HTML en texte supprime à nouveau les balises.
Qu'est-ce qu'un convertisseur Markdown en HTML ?
Un convertisseur de Markdown en HTML est un outil d'analyse qui prend du texte brut écrit dans la syntaxe Markdown et sort du balisage HTML valide.
Ce n'est pas un éditeur de texte, et il ne se contente pas d'afficher du texte formaté sur un écran. Il produit les balises HTML (EN) qu'un navigateur ou un système de contenu peut afficher.
L'outil se situe entre deux états du même document. L'un est lisible par une personne, l'autre est lisible par une machine.
- Source Markdown : texte brut écrit à la main ou généré dans un éditeur
- Étape d'analyse : lit la syntaxe et en construit la structure
- Stage de rendu : écrit le balisage HTML final
John Gruber a publié Markdown en 2004 (EN), construit autour d'une idée simple : l'écriture doit rester lisible sous forme de texte brut tout en se convertissant proprement en balisage structuré.
Le terme apparaît partout dans les outils de développement maintenant. Les fichiers Readme, les constructeurs de sites statiques, les applications de notes et les plateformes de documentation s’appuient tous sur une version de cette même étape de conversion.
Qu'est-ce que CommonMark et comment définit-il la conversion de Markdown en HTML ?
CommonMark (EN) est une spécification formelle pour la syntaxe Markdown qui définit, exemple par exemple, exactement ce qu'un convertisseur doit produire pour une entrée donnée.
Original Markdown n’a jamais eu cette garantie. Deux convertisseurs pourraient lire le même fichier et renvoyer deux résultats différents, ce qui constitue tout le problème que CommonMark a tenté de résoudre.
Spécification de CommonMark
Chaque règle dans la spécification est livrée avec un exemple fonctionnel. Les en-têtes, les listes, l'accent et la syntaxe des liens reçoivent chacun une définition précise et testable plutôt qu'une description vague.
- Les structures imbriquées, comme une liste à l'intérieur d'un bloc de citation, sont épelées au lieu d'être laissées à la conjecture
- Les analyseurs peuvent être vérifiés directement par rapport à la spécification, un processus que la communauté appelle des tests de conformité.
- Des outils comme Babelmark (EN) permettent aux développeurs de comparer comment différents analyseurs rendent la même entrée côte à côte
La plupart des bibliothèques activement maintenues, y compris markdown-it (EN) et cmark (EN), sont construites selon cette spécification plutôt que la syntaxe originale de 2004.
GitHub rend chaque issue, pull request et fichier readme via sa propre implémentation de la spécification, cmark-gfm (EN). L'objectif est de maintenir un formatage cohérent sur toute la plateforme.
GitHub Flavored Markdown Extensions
GitHub Flavored Markdown (EN), abrégé en GFM, est un superensemble strict de CommonMark. Tout ce que CommonMark supporte fonctionne toujours, GFM ajoute juste une poignée d'extensions dont GitHub a besoin.
| Extension | Ce qu'il ajoute |
|---|---|
| Tableaux | Syntaxe de table délimitée par des tuyaux |
| Listes de tâches | Éléments de case à cocher dans une liste |
| Biffé | Style de texte double tilde |
| Liens automatiques | Les URL nues sont automatiquement transformées en liens cliquables |
GitLab a construit son propre dialecte comparable, GitLab Flavored Markdown (EN), en grande partie pour la même raison que GitHub a créé GFM : la syntaxe spécifique à la plate-forme nécessite son propre livre de règles testé.
Comment un convertisseur Markdown en HTML analyse et affiche-t-il le texte ?
Un convertisseur Markdown en HTML fonctionne en deux étapes. Il analyse le texte source dans une représentation structurée, puis rend cette structure en balises HTML.
La méthode qui gère la première étape décide de presque tout le reste : la vitesse, la précision et la capacité de l'outil à gérer une syntaxe désordonnée ou profondément imbriquée.
Analyse basée sur Regex
Les analyseurs basés sur des expressions régulières analysent le texte ligne par ligne, en faisant correspondre des modèles comme # pour un titre ou * pour l'emphase.
- Rapide sur des documents courts et bien formés
- Problèmes avec les structures imbriquées, comme une liste à l'intérieur d'un guillemet
- Était l'approche dominante avant l'existence de CommonMark
Showdown (EN) et le Markdown.pl original utilisent tous deux cette méthode, et cela se voit dans la façon dont ils sont parfois en désaccord les uns avec les autres sur les cas extrêmes.
Analyse basée sur AST et Tokenizer
Les analyseurs basés sur Tokenizer divisent d'abord l'entrée en jetons, puis créent une arborescence de syntaxe abstraite avant que quoi que ce soit ne soit rendu.
C'est une approche vraiment différente. L'analyseur comprend la structure complète du document avant d'écrire une seule balise HTML.
| Approche | Poignées d'imbrication | Vitesse typique | Exemple |
|---|---|---|---|
| Regex-based | Faible sur l'imbrication profonde | Très rapide sur le texte simple | Showdown |
| À base d’AST | Poignées imbriquées nativement | Rapide, légèrement plus coûteux | markdown-it |
Le volet d'aperçu intégré de VS Code (EN) fonctionne sur markdown-it en interne. Il s'appuie sur cette architecture de tokenisation pour une gestion cohérente des listes imbriquées à l'intérieur des citation de bloc.
Qu'est-ce qui rend un convertisseur Markdown en HTML rapide ou précis ?
La vitesse vient du peu de travail que l'analyseur fait par caractère. La précision provient de la mesure dans laquelle la sortie correspond aux tests de conformité de la spécification CommonMark.
Ces deux objectifs vont dans des directions différentes plus souvent que ce à quoi les gens s’attendent. Un analyseur d'expression régulière dépouillé peut dépasser un tokenizer complet sur du texte simple, puis s'effondrer au moment où l'entrée devient désordonné.
Chiffres clés :
- La version actuelle de CommonMark est version 0.31.2 (EN), publiée en janvier 2024
- La spécification contient 652 exemples de conformité intégrés, chacun associant une entrée Markdown avec la sortie HTML exacte qu'un analyseur conforme doit générer.
- La spécification GFM (EN) est versionnée à 0.29-gfm, dernièrement publiée formellement en 2019, et elle fonctionne toujours comme référence de GitHub pour le rendu GFM
Un analyseur qui obtient de bons résultats par rapport à ces exemples de conformité est, par définition, plus précis. Celui qui ignore entièrement la spécification, comme le Showdown original, n'a pas de tel benchmark à vérifier.
La décision de GitLab de publier sa propre spécification a suivi la même logique que celle utilisée par GitHub pour GFM : un livre de règles documenté et testable bat un livre de règles informel à chaque fois qu'un analyseur est mis à jour.
Comment les convertisseurs Markdown vers HTML gèrent-ils la sécurité et l'assainissement ?
Markdown permet le HTML brut à l'intérieur d'un document par conception, et ce HTML brut est passé directement à travers la plupart des convertisseurs, à moins que quelque chose ne le retire.
C'est exactement l'ouverture dont un attaquant a besoin. Un champ de commentaire, une page wiki ou un fichier readme qui accepte Markdown d'une source non fiable peut contenir une balise de script directement dans la page rendue.
Outils et bibliothèques de désinfection
L'assainissement est généralement une étape séparée de la conversion, pas quelque chose de cuit dans l'analyseur lui-même.
- Tag allowlisting strips scripts, attributs de gestionnaire d'événements, et tout ce qui est en dehors d'un jeu de balises approuvé
- DOMPurify (EN), maintenue par le groupe de recherche sur la sécurité Cure53, est la bibliothèque que la plupart des projets JavaScript utilisent après la conversion.
- Certains convertisseurs, comme Showdown, offrent une option de nettoyage intégrée, bien qu'elle soit beaucoup moins complète qu'une bibliothèque dédiée.
Cette étape s'exécute généralement sur le backend (EN), juste avant que le HTML converti ne soit stocké ou servi, plutôt que de faire confiance au navigateur pour détecter tout ce qui est dangereux.
Le Top 10 OWASP de 2021 (EN) classe les failles d’injection au troisième rang. Cette catégorie comprend les attaques de script intersite. L’étude a recensé 274 228 occurrences dans les applications testées.
La bibliothèque markdown-js (EN) contient maintenant un avis « non maintenu » dans son dépôt, et son paquet npm a publié un avis de déni de service d'expression régulière (EN). C'est une conséquence directe de sa conception basée sur les expressions régulières.
Quel convertisseur Markdown en HTML convient à votre plateforme ?
Le bon convertisseur se résume généralement au langage que votre pile exécute déjà, pas à un meilleur choix universel.
| Outil | Plate-forme | Méthode d &apos ; analyse | Appui au GFM |
|---|---|---|---|
| Marked.js (EN) | JavaScript | Tokenizer-based | Construit dans |
| Python-Markdown (EN) | Python | Regex avec des crochets d'extension | Via les extensions |
| Kramdown (EN) | Ruby | Analyseur récursif descendant | Partiel |
| Pandoc (EN) | Cross-language | À base d’AST | Via les options du lecteur |
Convertisseurs de JavaScript
Marked.js et Showdown s'exécutent tous les deux dans le frontend (EN), convertissant Markdown en HTML directement dans le navigateur sans aller-retour sur le serveur.
- Marked.js se concentre sur la vitesse et une conformité plus étroite avec CommonMark
- Showdown précède CommonMark et offre un drapeau sanitize intégré
- Les deux s'installent via npm et se glissent dans une compilation JavaScript (EN) existante avec presque aucune configuration
Convertisseurs de Python
Python-Markdown est le choix standard dans les projets Python, et il est livré comme un paquet pip plutôt que comme un binaire autonome.
Architecture basée sur les extensions : la gestion de la syntaxe de base reste minimale, et des fonctionnalités comme les tableaux ou les notes de bas de page sont ajoutées en tant que modules d'extension séparés.
Les générateurs de documentation comme MkDocs (EN) se construisent directement sur le dessus plutôt que d'écrire leur propre analyseur.
Convertisseurs de Ruby
Kramdown et Redcarpet (EN) couvrent tous deux des projets Ruby, bien qu'ils s'appuient sur des architectures internes différentes.
Kramdown lit plus près d'un superensemble de Markdown, supportant les listes de définition et les listes d'attributs en ligne que CommonMark ne définit pas.
Redcarpet échange une partie de cette flexibilité contre une vitesse d’analyse brute, ce qui explique pourquoi il apparaît toujours dans les anciens pipelines de documentation Rails.
Devriez-vous utiliser un convertisseur en ligne, une bibliothèque, une API ou un plugin ?
La méthode d'accès est aussi importante que l'analyseur lui-même, puisqu'elle décide où la conversion a lieu et qui doit la maintenir.
Convertisseurs en ligne
Des outils comme Dillinger (EN) et HackMD s'exécutent entièrement dans un onglet du navigateur, aucune installation requise.
- Avantages : zéro configuration, bon pour un document unique, aucune dépendance à suivre
- Cons : ne convient pas aux pipelines automatisés, coller du contenu sensible dans un site tiers est une réelle préoccupation
D'autres outils de navigateur à usage unique suivent le même modèle pour différents formats. Un convertisseur de Word en HTML transforme les documents en balises, et un générateur de tableaux HTML construit des tables sans aucun Markdown.
Bibliothèques et API
L'installation d'une bibliothèque (Marked.js, Python-Markdown, Kramdown) place la conversion directement dans un processus de construction ou une requête de serveur.
Une API (EN) hébergée fait le même travail sans ajouter de dépendance à gérer, au coût d'un appel réseau et, généralement, d'une limite d'utilisation.
- Avantages : évolue avec l'application, pas d'étape manuelle, fonctionne à l'intérieur de pipelines automatisés
- Inconvénients : une bibliothèque a toujours besoin de mises à jour de version, une API a toujours besoin d'une solution de secours pour les temps d'arrêt
Plugins de CMS
Un plugin enveloppe un convertisseur dans une plateforme de contenu existante, de sorte que les éditeurs peuvent écrire en Markdown sans quitter l'interface qu'ils utilisent déjà.
Avantages : aucune étape de construction séparée pour les auteurs de contenu, expérience d'édition familière.
Inconvénients : le plugin n'est à jour que si son mainteneur le maintient. Les plugins abandonnés sont une source courante des lacunes de nettoyage couvertes précédemment.
Comment convertir Markdown en HTML en code, étape par étape ?
La conversion de Markdown en HTML avec une bibliothèque suit à peu près le même ordre dans presque tous les outils, qu'il s'exécute dans un onglet du navigateur ou dans un pipeline de compilation.
Le fait de sauter une étape, en particulier l'assainissement, est à l'origine de la plupart des erreurs de conversion réelles.
- Installez ou chargez le convertisseur. Ajoutez la bibliothèque via npm, pip, ou un gem, ou ouvrez un outil basé sur un navigateur si aucune étape de construction n'existe.
- Passez la source Markdown dans l'analyseur. C'est généralement un appel de fonction unique, quelque chose comme
marked.parse(text)oumarkdown.markdown(text). - Définissez la saveur et les extensions avant le rendu. Décidez si les tableaux GFM, les notes de bas de page ou les listes de tâches doivent être actifs pour ce document.
- Désinfecter la sortie. Exécutez le code HTML brut dans un désinfecteur dédié avant qu'il n'atteigne un modèle ou une base de données.
- Insérez le code HTML terminé. Déposez-le dans un modèle, un champ de contenu ou directement dans la page.
Sauter la quatrième étape est l'erreur la plus courante dans cette séquence. C'est aussi l'étape que la plupart des tutoriels de démarrage rapide laissent complètement de côté.
La plupart des convertisseurs regroupent l'analyse et le rendu en un seul appel de fonction, ce qui cache le fait que deux étapes distinctes se déroulent en dessous.
Comment intégrer un convertisseur Markdown en HTML dans un site Web ou un CMS ?
L'intégration signifie généralement que l'étape de conversion disparaît dans un processus de construction, de sorte que personne n'exécute un convertisseur à la main.
L'endroit où cette étape réside réellement, et quand elle se déclenche, change en fonction de la plate-forme sous laquelle elle se trouve.
Générateurs de site statique
Les générateurs de sites statiques exécutent le convertisseur une fois, au moment de la construction, et mettent en cache le code HTML résultant plutôt que de le convertir à chaque requête de page.
- Hugo utilise Goldmark par défaut (EN), un analyseur entièrement compatible avec CommonMark
- Jekyll utilise Kramdown par défaut (EN), exécutant son mode d'entrée GitHub Flavored Markdown hors de la boîte
- Les deux mettent en cache la sortie convertie, donc une page n'est reconvertie que lorsque son fichier source change réellement
Le propre site de documentation de Kubernetes (EN) tourne sur Hugo, convertissant ses fichiers sources Markdown en HTML statique servi sur kubernetes.io.
La conversion au moment de la compilation acquiert de la vitesse au moment de la requête. Le compromis est une étape de reconstruction à chaque fois que le contenu source change.
Plateformes de documentation
Docusaurus (EN) prend un chemin différent. Il exécute Markdown et MDX (EN) via un pipeline remark (EN) et rehype avant que React ne rende une page.
MDX permet à un document de mélanger du Markdown ordinaire avec des composants React intégrés, quelque chose qu'aucun des convertisseurs Ruby ou Python n'a couvert auparavant.
| Plate-forme | Analyseur par défaut | Gestion de HTML brut |
|---|---|---|
| Hugo | Goldmark | Dépouillé à moins que le mode dangereux ne soit activé |
| Jekyll | Kramdown (mode GFM) | Passé par défaut |
| Docusaurus | Remarque et pipeline MDX | Géré en tant que JSX, pas en HTML brut |
MkDocs, construit sur la bibliothèque Python-Markdown évoquée précédemment, suit le modèle de générateur statique plutôt que le modèle MDX.
Quand un convertisseur Markdown en HTML échoue-t-il ou produit-il des erreurs ?
Un convertisseur Markdown vers HTML se décompose à des limites prévisibles : syntaxe imbriquée, saveurs incohérentes et HTML brut qui est dépouillé sans aucun avertissement.
Rien de tout cela ne signifie que l'outil lui-même est cassé. Cela signifie que l'entrée supposait une fonctionnalité que l'analyseur n'a jamais été configuré pour supporter.
Erreurs de conversion courantes
La syntaxe imbriquée produit les échecs les plus visibles. Une liste placée à l'intérieur d'une citation peut se réduire en un seul paragraphe plat au lieu de rester imbriquée.
- Une table écrite en syntaxe GFM est rendue comme un paragraphe simple et sans style sur un analyseur strict CommonMark-only, puisque les tables ne font pas partie de la spécification de base.
- Les notes de bas de page disparaissent silencieusement sur tout analyseur qui n'a jamais ajouté cette extension
- Une liste en vrac, avec des lignes vides entre les éléments, enveloppe chaque élément dans sa propre balise de paragraphe, modifiant l'espacement de manière inattendue
Même les outils de GitHub ne sont pas immunisés contre la dérive. Le projet cmark-gfm a eu des problèmes ouverts où la version HTML publiée de sa spécification était désynchronisée avec le fichier de spécification sous-jacent. Cela a cassé les liens d'exemple numérotés sur lesquels les gens se fiaient pour référence.
Limitations structurelles et gustatives
Les incohérences de saveur causent plus d'échecs silencieux que des erreurs pures et simples. Le convertisseur ne lance pas d'avertissement, il rend juste quelque chose de légèrement faux.
La propre documentation de Jekyll indique clairement que CommonMark diffère du Markdown original et ne supporte pas toutes les fonctionnalités exclusives de Kramdown, y compris les listes d'attributs en ligne de bloc.
- Blocs HTML bruts : dépouillés par l'analyseur Goldmark de Hugo à moins que le mode "non sécurisé" ne soit activé
- Syntaxe Kramdown uniquement : ignorée entièrement par un analyseur CommonMark strict
- Substitutions typographiques : guillemets et tirets intelligents appliqués de manière incohérente entre les convertisseurs qui ne partagent pas le même ensemble d'extensions
Certains documents doivent être rendus de manière identique partout, d'un fichier readme à un site de documentation en passant par un résumé d'e-mail. Pour ceux-ci, choisir une saveur et tester directement contre elle est plus important que de choisir l'analyseur le plus rapide.
Questions fréquentes : Convertisseur de Markdown en HTML
En quoi Markdown diffère-t-il du HTML en tant que format ?
Markdown est une syntaxe de texte clair légère, tandis que HTML est le langage de balisage complet que les navigateurs lisent réellement.
Un seul symbole Markdown, comme un astérisque, se développe en plusieurs balises HTML lors de la conversion. Markdown reste lisible sans être rendu, le HTML brut le fait rarement.
Qui a créé Markdown et pourquoi est-ce important pour les outils de conversion ?
John Gruber a publié Markdown en 2004, visant à ce que le texte reste lisible même avant la conversion.
Chaque convertisseur Markdown vers HTML moderne honore toujours cet objectif original : source lisible, sortie propre. CommonMark a plus tard formalisé sa syntaxe en une spécification testable.
La conversion de Markdown en HTML est-elle gratuite et l'open source est-il important ?
La plupart des convertisseurs de Markdown en HTML, y compris Marked.js, Python-Markdown et Kramdown, sont libres et open source.
L'open source est important ici parce que la précision s'améliore grâce aux tests de conformité publics par rapport à CommonMark. Les options payantes existent principalement sous forme d’API hébergées avec des limites d’utilisation.
Comment vérifier ou tester que la sortie HTML est correcte ?
Exécutez la sortie du convertisseur contre la suite de tests de conformité de CommonMark (EN), ou comparez les résultats entre les analyseurs en utilisant Babelmark (EN).
Pour les pipelines personnalisés, inspectez d'abord visuellement les listes imbriquées, les tableaux et les blocs HTML bruts, car c'est là que la sortie est le plus souvent interrompue.
Que devriez-vous réparer en premier lorsqu'un convertisseur Markdown en HTML se casse ?
Un convertisseur Markdown en HTML se casse le plus visiblement aux lacunes d'assainissement, de sorte que la réparation de la couche de sécurité prend la priorité sur les décalages de saveur ou les bizarreries de syntaxe imbriquée. Une balise de script non sécurisée atteignant une page active comporte des enjeux beaucoup plus élevés qu'une seule table mal rendue.
- Nettoyez la sortie HTML brute avant toute autre chose
- Confirmez que le style Markdown correspond aux documents sources
- Test de la syntaxe imbriquée edge cases last
Verrouiller un pipeline à CommonMark strict pour corriger les incohérences de saveur coûte des extensions GitHub Flavored Markdown comme les tables et les listes de tâches, à moins qu’un plugin ne les restaure par la suite.
Une fois que le balisage converti est stable, les équipes acheminent généralement cette sortie via un HTML Beautifier (EN) pour normaliser le retrait avant le déploiement.