Convertir YAML en TOML en Ligne
Convertis ta configuration YAML en TOML, gratuitement, dans ton navigateur.
title = "My Project" version = "1.0.0" [server] host = "localhost" port = 8080 [database] host = "db.example.com" name = "myapp"
Cas d'utilisation
De Docker et GitHub Actions vers Rust et Hugo
Migration Jekyll vers Hugo
Convertis le front matter YAML de Jekyll en TOML pour migrer ton contenu vers Hugo.
Python moderne
Extrait la configuration depuis YAML pour l'adapter a pyproject.toml selon le standard PEP 621.
100% prive
Ton YAML ne quitte jamais ton navigateur. Aucun serveur, aucune inscription.
Instantane
Conversion en temps reel avec detection immediate des erreurs de syntaxe YAML.
Comment ça marche
Trois étapes, sans complications
Colle ton YAML
Colle le YAML dans l'editeur. Compatible avec docker-compose.yml, les workflows GitHub Actions, les playbooks Ansible et tout YAML 1.2 valide.
Conversion en TOML
Le convertisseur transforme les maps et listes YAML en sections et tableaux TOML. Tout se passe dans ton navigateur, rien n'est envoye.
Copie ou telecharge le TOML
Recupere le TOML pret pour Cargo.toml, pyproject.toml, Pipfile, hugo.toml ou tout outil acceptant TOML v1.0.
FAQ
Des questions ?
Les scenarios les plus courants sont : la migration de projets Python de requirements.txt + setup.cfg (format legacy) vers pyproject.toml (le standard moderne defini par PEP 517/518/621), ou une partie de la configuration peut exister en YAML (comme les workflows CI/CD) et tu veux normaliser les sections de configuration en TOML. C'est aussi frequent lors de la migration de sites Jekyll (front matter YAML) vers Hugo (front matter TOML prefere). Enfin, les equipes adoptant Rust ont souvent des configurations CI/CD en YAML (GitHub Actions) a refleter dans Cargo.toml pour gerer les features ou les membres du workspace.
docker-compose.yml definit des services, reseaux et volumes en YAML. Bien qu'il n'existe pas d'equivalent TOML natif pour Docker Compose (Docker n'accepte que YAML pour son format Compose), convertir docker-compose.yml en TOML peut etre utile comme representation intermediaire : certains projets Rust utilisent TOML comme configuration d'infrastructure propre (par exemple, configurations de serveurs avec tokio, actix-web ou tauri), et avoir la meme structure de services en TOML facilite l'integration. La conversion genere du TOML valide avec des sections [[services]] pour les tableaux d'objets.
Les workflows GitHub Actions (.github/workflows/*.yml) ont une structure specifique (on, jobs, steps) qui ne correspond pas directement a la structure de pyproject.toml ([project], [tool.X], [build-system]). Cependant, il est courant de vouloir extraire des parties du workflow - comme la matrice de versions Python, les dependances de test ou la configuration des outils - pour les inclure dans pyproject.toml. Cet outil convertit le YAML complet en TOML structurel ; a partir du TOML resultant tu peux selectionner et adapter les sections pertinentes a ajouter a ton pyproject.toml.
L'operation inverse de Hugo vers Jekyll : le front matter YAML de Jekyll est delimite par --- au debut et a la fin du fichier Markdown. Pour migrer vers Hugo avec du front matter TOML, extrais le bloc YAML entre les ---, convertis-le en TOML avec cet outil, et remplace les delimiteurs --- par +++. Les champs courants (title, date, tags, categories, draft) se traduisent directement. Les permalinks specifiques a Jekyll et les layouts peuvent necesiter un mapping manuel vers les equivalents Hugo (url, type, layout).
Certaines fonctionnalites YAML n'ont pas de correspondance directe en TOML. Les ancres et alias YAML (&anchor et *alias) sont resolus avant la conversion, de sorte que le TOML resultant contient les valeurs etendues, pas les references. Les documents YAML multiples (separes par ---) n'ont pas d'equivalent TOML, car TOML est toujours un document unique. Les cles avec des types speciaux (dates comme cles de map, cles avec des caracteres speciaux) peuvent necessiter des guillemets en TOML. Les valeurs null YAML (~ ou null) sont representees comme des chaines vides ou omises en TOML, car TOML n'a pas de type null natif (TOML 1.0 n'inclut pas null).
Le TOML genere est syntaxiquement valide selon la specification TOML 1.0 et peut etre analyse par toml-rs (le parser Rust utilise par Cargo) ou d'autres bibliotheques TOML standard. Cependant, la compatibilite semantique avec Cargo.toml depend du fait que le YAML d'entree modelise correctement la structure d'un manifest Cargo : [package], [dependencies], [dev-dependencies], [[bin]], [[lib]], etc. Si ton YAML modelise deja cette structure, le TOML resultant sera un Cargo.toml valide. S'il vient d'une source differente (comme docker-compose.yml), le TOML resultant necessitara une adaptation manuelle.
Convertir YAML en TOML : migrer Docker et GitHub Actions vers l'ecosysteme Rust et Hugo
La conversion de YAML en TOML est un flux moins courant que la direction inverse, mais elle a des cas d'utilisation bien definis dans l'ecosysteme de developpement moderne. Le plus pertinent est l'adoption de TOML comme standard de configuration en Python : pyproject.toml, defini par PEP 518 en 2016 et etendu par PEP 517 (systeme de build), PEP 621 (metadonnees du projet, 2021) et PEP 660 (builds editables), a progressivement remplace setup.py, setup.cfg et requirements.txt comme configuration centrale des projets Python modernes. Des outils comme Poetry, Hatch, Flit et PDM utilisent pyproject.toml comme source de verite. Si un projet Python existant a une partie de sa configuration en YAML - par exemple, les versions Python supportees definies dans un workflow GitHub Actions, ou la configuration de tox en YAML - la convertir en TOML pour la centraliser dans pyproject.toml est une amelioration de la maintenabilite.
Dans l'ecosysteme Rust, Cargo.toml est le coeur du projet : il definit le nom du crate, la version (suivant le Semantic Versioning), les auteurs, l'edition Rust (2015, 2018, 2021, 2024), les dependances avec versions semver, les features optionnelles du crate, les cibles (binaires, bibliotheques, exemples, tests, benchmarks) et la configuration du workspace pour les projets monorepo. Quand une equipe adopte Rust pour un nouveau service dans une infrastructure qui utilise deja YAML intensivement (docker-compose.yml pour le developpement local, manifests Kubernetes pour la production, GitHub Actions pour le CI/CD), elle peut avoir besoin d'extraire des parties de cette configuration YAML pour les inclure dans Cargo.toml. L'exemple le plus pratique : le workflow GitHub Actions definit la matrice de versions Rust a tester (stable, beta, nightly) ; cette information peut vouloir se refleter dans le Cargo.toml du workspace.
La migration de contenu entre generateurs de sites statiques est le scenario le plus concret pour YAML vers TOML. Jekyll, cree par Tom Preston-Werner en 2008 et le moteur de GitHub Pages, a popularise le concept de front matter YAML delimite par --- dans les fichiers Markdown. Hugo, le generateur de sites statiques le plus rapide (ecrit en Go, avec des temps de build typiques en millisecondes pour des milliers de pages), a adopte TOML comme format de front matter prefere dans ses premieres versions, bien qu'il supporte aussi YAML et JSON. Migrer un site de Jekyll vers Hugo - une migration populaire chez les developpeurs recherchant de meilleures performances pour les grands sites - necessite de convertir le front matter YAML de chaque fichier Markdown au format TOML avec des delimiteurs +++. Pour un site avec des centaines d'articles, cela se automatise avec des scripts Python (PyYAML + toml) ou Node.js (js-yaml + @iarna/toml), en utilisant cet outil pour valider la conversion de cas individuels.