Convertisseur PowerShell vers XML
Colle des objets PowerShell ou des hashtables. Récupère du XML propre.
Ce que fait cet outil
Si tu as déjà eu besoin de caser une config PowerShell dans un fichier XML — pour une ressource DSC, une tâche MSBuild, un template app.config ou un fixture SoapUI — tu connais la musique. Tu finis soit par lancer ConvertTo-Xml et à rogner les moches wrappers <Object Type="..."> à la main, soit par utiliser Export-CliXml et à récupérer un payload CLIXML que personne en dehors de PowerShell ne sait lire. Colle ton PowerShell ici et tu récupères du XML bien formé qu'un parser XML classique acceptera — pas de bruit <Property Name="...">, pas de tags de type CLIXML, juste les données.
L'outil comprend les formes que le code PowerShell utilise vraiment. Un PSCustomObject devient un élément avec des enfants nommés d'après chaque propriété. Un hashtable @{ Name = "Ava" } se comporte pareil. Un tableau créé avec @(...) devient un élément conteneur avec un enfant par item. Les valeurs [PSCustomObject] imbriquées dans un objet parent passent comme des éléments imbriqués, pas comme des blobs stringifiés. Les booléens ($true, $false) et les nombres gardent leurs types natifs dans la sortie ; $null devient un élément auto-fermant vide pour que la forme reste prévisible au lieu de faire disparaître le champ silencieusement.
Certaines particularités du langage sont gérées comme un humain s'y attendrait. Les chaînes entre guillemets doubles passent sans expansion des marqueurs d'interpolation comme $var — on préserve ce que tu as collé, littéralement. Les here-strings (@" ... "@) sont traitées comme du contenu texte multi-lignes. Les dates écrites [datetime]"2026-04-21" sortent en chaînes ISO-8601. Les noms de propriété qui contiennent des tirets reçoivent un nom d'élément sûr (PowerShell te laisse écrire "User-Agent" = "..." dans un hashtable, ce qui est illégal comme tag XML brut — on convertit pour que la sortie reste parseable). La forme reste fidèle à l'entrée ; le XML reste utilisable.
Comment l'utiliser
Trois étapes. Ça marche pareil que tu colles un seul hashtable ou tout un script de configuration.
Colle ton PowerShell (ou essaie l'exemple)
Lâche ton script dans l'éditeur de gauche. Un simple [PSCustomObject]@{...}, un hashtable imbriqué, un tableau @(...) d'objets, ou un bloc de config complet — tout passe. Clique sur Charger un exemple si tu veux un payload de commande réaliste pour commencer.
Pas besoin de retirer les commentaires, supprimer les blocs param() ou nettoyer le script avant. Colle ce que tu as. On lira seulement les littéraux d'objet et on ignorera le reste.
Clique sur Convertir
Clique sur le bouton vert Convertir. L'outil parcourt la structure PowerShell, préserve chaque propriété et chaque item de tableau, et construit le XML en une passe. Tu verras un bref indicateur de chargement pendant l'exécution.
Copie le XML
Le panneau de droite se remplit de XML indenté que n'importe quel parser conforme acceptera. Balance-le dans ta configuration DSC, ton fichier MSBuild, ou là où tu en as besoin.
Quand ça sert vraiment
Rédiger des payloads de configuration DSC
Tu as un hashtable PowerShell qui décrit la configuration d'un nœud et il te faut une version XML pour un consommateur non-DSC ou pour la doc. Colle, convertis, terminé — fini de materner la sortie de ConvertTo-Xml.
Fichiers de variables de pipeline Azure DevOps
Les pipelines attendent parfois un groupe de variables en XML. Colle le hashtable PowerShell que tu maintiens déjà, récupère du XML qui tombe directement dans <code>variables.xml</code> — sans édition manuelle.
Exporter des payloads de journal d'événements Windows
Quand tu construis un enregistrement d'événement en PowerShell comme PSCustomObject et qu'il faut le passer à un pipeline de logging qui ingère du XML, ça t'évite d'écrire un sérialiseur maison. La forme imbriquée passe sans changement.
Templates de base app.config / web.config
Transforme un hashtable de settings PowerShell en <code>app.config</code> de départ que tu peux éditer à la main. Plus rapide que de le générer from scratch et ça garde les clés synchronisées avec tes scripts.
Questions fréquentes
En quoi c'est différent de lancer ConvertTo-Xml sur mon objet ?
ConvertTo-Xml emballe tout dans une enveloppe générique <Object Type="..."><Property Name="..."> — lisible par PowerShell, moche partout ailleurs. Cet outil émet les noms de propriétés comme de vrais éléments XML, donc la sortie ressemble à du XML écrit à la main. Pas d'indirection <Property Name>, pas d'attributs de type qui encombrent.
Est-ce que ça produit du CLIXML comme Export-CliXml ?
Non — et c'est le but. Export-CliXml produit du CLIXML, un format spécifique à PowerShell conçu pour revenir dans PowerShell. Si tu dois passer le XML à un système qui n'est pas PowerShell (un service Java, un lecteur de config, un pipeline validé par XSD), CLIXML n'est pas la bonne forme. Cet outil te donne du XML simple et lisible à la place.
Je peux coller un fichier .ps1 complet ou juste des littéraux d'objets ?
Colle ce que tu as. Si le script contient un seul littéral d'objet assigné à une variable, c'est ça qui sort. S'il y a plusieurs hashtables ou PSCustomObjects au niveau racine, chacun sort comme son propre élément. Les corps de fonctions, blocs param(), imports et lignes Write-Host sont ignorés — seules les formes de données comptent.
Comment sont gérés $null, $true, $false et les tableaux vides ?
$null devient un élément auto-fermant vide pour que la forme reste cohérente (au lieu que le champ disparaisse). $true et $false deviennent les chaînes littérales true et false. Un @() vide devient un élément conteneur vide. Comme ça, les outils en aval voient toujours la même structure, même quand certains champs sont non-renseignés.
Et les clés de hashtable qui ne sont pas des noms XML valides — tirets, espaces, qui commencent par un chiffre ?
Des clés comme "User-Agent" ou "2024-Q1" sont légales dans un hashtable PowerShell mais illégales comme noms d'éléments XML bruts. On les réécrit en forme sûre (en gardant l'original comme attribut quand ça a du sens) pour que la sortie reste parseable. Si ça compte pour ton consommateur, jette d'abord un œil aux tags générés.
Mon code est-il stocké ?
Le code est envoyé au backend pour la conversion et n'est pas persisté — on ne log pas le payload. Si le script est vraiment sensible (credentials de prod, chemins internes), nettoie-le avant de coller, comme tu le ferais avec n'importe quel outil en ligne.
Autres outils qui peuvent te servir
PowerShell vers XML n'est qu'une pièce du puzzle. Ces outils vont bien avec :