Comment ça marche ?

Solution : Information, pas erreur. Vos lignes XML avaient des ordres de champs différents. Nous avons pris l'ordre de la première ligne comme référence. Le XML reconstitué reste 100% valide — l'ordre des champs n'a pas d'importance sémantique pour Google, Akeneo, SFCC ou Magento.

Solution : Votre XML contient des balises type <sale_price/> ou <upc/> (vides, auto-fermantes). En pratique, ce n'est pas un problème : WooCommerce, PrestaShop, Magento, Akeneo et autres systèmes d'import traitent l'absence d'un champ comme « ne pas modifier la valeur existante » — le même comportement qu'une balise vide. Si vous voulez forcer un effacement, écrivez « 0 » ou un espace dans la cellule.

Solution : Votre XML contient des balises vides qui ne portent que l'attribut servant à nommer leur colonne, par exemple ‹custom-attribute attribute-id="badge"/›. Leur cellule est vide, et une cellule vide n'écrit rien : elles ne seront pas dans le XML reconstruit. Si elles servaient à effacer une valeur à l'import, effacez-la dans l'outil de destination.

Solution : Sans modification de votre part, le XML reconstruit doit être structurellement identique. Si ce n'est pas le cas (ordre des éléments, attributs perdus), contactez le support avec votre fichier d'origine — c'est un bug à corriger.

Solution : Vous avez sans doute déposé le .excelify.zip tel que téléchargé : un tableur enregistre data.csv à côté de l'archive, jamais dedans, donc le .zip contient toujours les valeurs d'origine. La page Reconstruction vous le signale. Choisissez « Fichiers séparés » et déposez votre data.csv modifié avec skeleton.json.

Solution : Le CSV et le skeleton.json déposés ne viennent pas du même export, ce qui arrive vite quand plusieurs exports s'accumulent dans Téléchargements (data.csv, data (1).csv…). Reprenez les deux fichiers du même bundle. Ajouter ou supprimer des colonnes reste permis.

Solution : La reconstruction s'arrête quand des cellules remplies ne peuvent pas être écrites : une colonne ajoutée pour une langue, un site ou un élément numéroté que le fichier d'origine n'a pas (custom-attribute[seo_url][de-DE], image-group[3]), une colonne de travail au nom libre (« À vérifier »), une valeur tapée sur une ligne d'un autre type (colonne _type), des valeurs sans en-tête (tapées à côté du tableau, ou sous un en-tête effacé : « colonne sans en-tête, colonne F »), ou une colonne en double dont les copies diffèrent (une copie de sauvegarde : seule la plus à gauche serait écrite). La page liste les colonnes et les lignes. Une colonne de travail peut rester : reconstruisez quand même. Pour une nouvelle langue ou un nouveau site, ajoutez-le à un élément du XML d'origine, puis transformez de nouveau ce fichier. Gardez une seule colonne par nom, et un en-tête au-dessus de chaque colonne remplie.

Solution : Une cellule contient un caractère de contrôle (U+0001, U+001B…), invisible dans le tableur, souvent arrivé avec un copier-coller depuis un autre logiciel ou une page web. XML l'interdit : un import refuserait le fichier entier. La page indique la colonne, les lignes et le code du caractère. Reconstruisez quand même pour les retirer (le reste du texte est gardé), ou retapez ces cellules. Les sauts de ligne collés depuis Word ou PowerPoint ne bloquent pas : ils s'écrivent comme des sauts de ligne.

Solution : Pas de souci : ExcelifyXML détecte l'encodage automatiquement (BOM, déclaration <?xml encoding="..."?> ou contenu du fichier) et convertit en UTF-8 avant traitement. Il lit aussi les encodages déclarés d'Europe centrale, grecs, turcs, baltes, cyrilliques, japonais, chinois et coréens (Windows-1250 à 1258, ISO-8859, Shift_JIS, EUC-JP, GBK, GB18030, Big5, EUC-KR…), sous leurs autres noms aussi (latin1, cp1252, cp932, UHC…). Même un fichier dont la première ligne annonce un autre encodage alors qu'il a été enregistré en UTF-8, ou annonce UTF-8 alors qu'il est en Windows-1252, est lu correctement. Un encodage déclaré qu'ExcelifyXML ne sait pas lire exactement (Mac Europe centrale, EBCDIC…) est refusé sans utiliser de crédit : enregistrez le fichier en UTF-8.

Solution : Le forfait gratuit accepte les fichiers jusqu'à 4 Mo ; le forfait VIP jusqu'à 30 Mo (envoi direct sécurisé, sans conservation). Au-delà de 30 Mo, contactez-nous pour un traitement Enterprise sur mesure. Quelle que soit sa taille, un fichier peut contenir jusqu'à 1,5 million d'éléments XML, imbriqués sur 100 niveaux au plus : au-delà, découpez-le en plusieurs fichiers.

Solution : Votre fichier contient deux documents XML mis bout à bout (deux pages d'un export, deux fichiers concaténés) alors qu'un fichier XML n'a qu'un élément racine. Transformez chaque partie séparément, ou placez-les toutes dans un même élément racine. Aucun crédit n'est utilisé : le fichier est refusé plutôt que de laisser de côté, sans le dire, tout ce qui suit la première racine.

Solution : Elle est acceptée quand elle renvoie seulement à une DTD externe, par exemple ‹!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.069/cXML.dtd"›. ExcelifyXML ne télécharge jamais cette DTD : il garde la ligne dans le fichier skeleton.json et la réécrit à sa place dans le XML reconstruit. Une déclaration qui définit elle-même des entités ou des éléments, entre crochets [ … ], est refusée pour la sécurité du service, sans utiliser de crédit : supprimez-la, puis remettez-la dans le XML reconstruit. Si elle définit des entités que le fichier utilise (&nom;), remplacez d'abord chacune par le caractère lui-même ou par sa référence numérique : sans la déclaration, elles seraient reprises comme du texte. Les entités que seule la DTD définit (&nbsp;, &eacute;…) sont refusées aussi, avec leur ligne : remplacez-les par leur référence numérique (&#160;, &#233;) ou par le caractère lui-même. Les listes de propriétés d'Apple (fichiers plist) restent refusées, sans utiliser de crédit : chaque clé n'y est reliée à sa valeur que par leur ordre, que le CSV ne garde pas.

Solution : Votre tableur attend l'autre séparateur (Excel français = point-virgule, anglophone = virgule). Choisissez le bon dans « Options avancées », sous l'aperçu de la page Upload, ou réparez le fichier ouvert via Données → Convertir → Délimité dans Excel. La reconstruction retrouve seule le séparateur, quel qu'il soit.

Solution : Certaines balises de votre XML contiennent du texte entrecoupé d'autres balises (ex. ‹string›Appuyez ‹b›ici‹/b› pour continuer‹/string›). Un CSV ne peut pas représenter ce mélange : les sous-balises (ici « b ») deviennent des colonnes, mais le texte autour (« Appuyez », « pour continuer ») n'est pas repris et manquera dans le XML reconstruit. Modifiez ces valeurs-là directement dans le fichier XML d'origine ; toutes les autres lignes se modifient normalement dans le CSV.

Solution : Votre fichier contient plusieurs listes (par exemple plusieurs listes de prix ou plusieurs entrepôts SFCC) et les lignes choisies ne disent pas à quelle liste elles appartiennent : le XML reconstruit les mélangerait. Transformez chaque liste dans un fichier séparé : vous gardez une ligne par prix ou par produit. Vous pouvez aussi choisir, dans l'aperçu, sous « Pas la bonne ligne ? », l'élément qui regroupe chaque liste (par exemple pricebook) : chaque liste devient alors une seule ligne aux colonnes numérotées, qui dépasse vite les 16 384 colonnes qu'Excel garde (l'aperçu le signale). Aucun crédit n'est débité dans ce cas.

Solution : Le format « CSV » classique d'Excel (comme celui de LibreOffice sous Windows ou d'Excel en ligne) ne sait pas écrire tous les caractères : l'arabe, le chinois, le grec, le cyrillique… deviennent « ? » à l'enregistrement, et même les accents quand l'ordinateur est réglé dans une autre langue (polonais, grec, japonais…). À la reconstruction, ExcelifyXML compare les « ? » du fichier à ceux de votre XML d'origine et s'arrête quand des caractères ont été remplacés. Il ne les voit pas tous : un mot tapé dans un autre alphabet devient « ???? », un accent isolé dans un tout petit fichier passe inaperçu. Le plus sûr : enregistrez avec « CSV UTF-8 (délimité par des virgules) » (Excel sous Windows) ou « CSV UTF-8 » (Excel pour Mac) ; Google Sheets et Numbers enregistrent déjà en UTF-8. Les autres encodages (Mac Roman, Windows dans une autre langue) sont reconnus automatiquement.

Solution : Ouvert par double-clic, un CSV est lu par Excel comme des nombres et des dates : « 00123 » devient « 123 », un EAN devient « 3,61235E+12 » (ses derniers chiffres sont perdus), « 1-2 » devient « 01-févr ». Ouvrez plutôt le CSV par Données › À partir d'un fichier texte/CSV, puis « Transformer les données », en donnant le type « Texte » à ces colonnes. L'écran de transformation indique les colonnes concernées, et la reconstruction s'arrête si un code est passé en notation scientifique, si une date est apparue dans une colonne qui n'en avait pas ou si une date a changé de format (« 2026-09-01 » devenu « 01/09/2026 »).

Solution : Un tableur ne garde qu'un nombre limité de colonnes : 16 384 dans Excel et LibreOffice, 1 000 dans Numbers. Excel garde aussi au plus 32 767 caractères par cellule (Google Sheets 50 000). Ce qui dépasse est coupé dès l'ouverture du CSV, même sans modification : un produit et ses milliers de variantes, plusieurs entrepôts ou listes de prix en colonnes numérotées, une très longue description HTML. L'aperçu et l'écran de transformation le signalent, et la reconstruction s'arrête si le CSV revient coupé ; « Reconstruire quand même » écrit le XML sans ce qui a été coupé. Trop de colonnes : dans l'aperçu, sous « Pas la bonne ligne ? », choisissez une balise de ligne qui donne des lignes plus étroites (par exemple variant plutôt que product), ou découpez le fichier XML (une liste par fichier). Valeurs trop longues : modifiez-les dans le fichier XML d'origine plutôt que dans le tableur.