Erreur country_module_list.xml PrestaShop : la solution

Vous ouvrez votre back-office PrestaShop un matin et là, avant même d’avoir bu votre café, un bloc rouge s’affiche en haut de page. “Error found : Start tag expected, ‘<‘ not found in country_module_list.xml file.” Puis un deuxième. Puis un troisième. Le genre de message qui donne envie de refermer l’ordinateur et de faire semblant que tout va bien. Bonne nouvelle : votre boutique tourne probablement très bien côté clients. Ce bug concerne uniquement le back-office et il a une explication précise et des solutions concrètes. Je vais vous expliquer ce qui se passe vraiment, pourquoi c’est lié à l’API PrestaShop Addons, et comment corriger l’erreur country_module_list.xml une bonne fois pour toutes.

D’où viennent ces messages d’erreur ?

Ce que PrestaShop fait en coulisses

PrestaShop, dans ses versions 1.6 et 1.7, contacte régulièrement l’API du marketplace PrestaShop Addons pour récupérer trois listes de modules. La première, country_module_list.xml (ou default_country_modules_list.xml selon les versions), contient les modules suggérés selon votre pays. La deuxième, must_have_module_list.xml, liste les modules considérés comme indispensables par PrestaShop. La troisième, modules_native_addons.xml, recense les modules natifs disponibles sur la Marketplace. Ces fichiers sont stockés localement dans le dossier /config/xml/ de votre installation et mis à jour automatiquement par PrestaShop à chaque connexion au back-office. C’est là que ça coince.

Quand l’API Addons est en maintenance ou inaccessible

Quand le site PrestaShop Addons passe en maintenance, que l’API est temporairement indisponible, ou que les endpoints retournent une réponse invalide (une page HTML d’erreur au lieu du XML attendu), PrestaShop écrit quand même cette réponse dans les fichiers locaux. Résultat : les fichiers XML se retrouvent corrompus. Ils contiennent du HTML, une page d’erreur 503, ou simplement du texte non structuré au lieu d’un XML bien formé. Au prochain chargement du back-office, PrestaShop tente de lire ces fichiers, échoue à les parser, et affiche les messages d’erreur que vous connaissez. C’est un bug connu et documenté sur GitHub et les forums officiels PrestaShop depuis des années. Il revient à chaque maintenance ou incident côté Addons.

Le rôle exact de ces fichiers XML

Ces trois fichiers servent uniquement à alimenter la section Modules > Module Manager de votre back-office, pour afficher des suggestions de modules depuis la Marketplace. C’est une fonctionnalité de mise en avant commerciale, pas un composant critique de votre boutique. Vos commandes, vos produits, vos clients, votre caisse : rien de tout ça ne dépend de ces fichiers. La boutique côté visiteurs tourne normalement. Seul le back-office affiche ces erreurs, ce qui est déjà suffisamment agaçant pour qu’on s’en occupe.

Est-ce que votre boutique est en danger ?

Non. C’est la première chose à clarifier parce que ces messages rouges font peur. Un client qui passe commande en ce moment ne voit rien, ne subit rien. Le panier fonctionne, le paiement passe, les emails de confirmation partent. Ces erreurs XML sont strictement cantonnées au module manager du back-office. Elles n’affectent pas les performances du front-office, ne corrompent pas votre base de données, et ne compromettent pas la sécurité de votre site. C’est gênant visuellement et potentiellement stressant, mais ce n’est pas une urgence critique. Cela dit, autant régler le problème proprement plutôt que de le subir à chaque connexion. Si vous avez des doutes sur la santé technique globale de votre boutique, l’article sur la configuration PrestaShop avec Cloudflare peut aussi vous intéresser pour sécuriser et optimiser votre infrastructure.

Comment corriger l’erreur : les solutions

Solution rapide : remplacer le contenu des fichiers XML corrompus

C’est la solution la plus simple et la plus rapide. Connectez-vous à votre serveur via FTP ou SSH et naviguez jusqu’au dossier /config/xml/ de votre installation PrestaShop. Vous y trouverez les fichiers en question. Ouvrez-les un par un et remplacez leur contenu intégral par ce XML minimal valide :

<?xml version="1.0" encoding="UTF-8"?>
<modules/>

Faites cette opération pour chacun des trois fichiers concernés : country_module_list.xml (ou default_country_modules_list.xml), must_have_modules_list.xml, et modules_native_addons.xml. Une fois sauvegardés, videz le cache PrestaShop depuis Paramètres avancés > Performances, puis reconnectez-vous au back-office. Les erreurs doivent avoir disparu. Le problème avec cette solution : si l’API Addons retombe en maintenance, PrestaShop va de nouveau écraser ces fichiers avec du contenu corrompu et les erreurs reviennent. Pour tenir sur la durée, passez à la solution suivante.

Solution durable : passer les fichiers en lecture seule

Après avoir remis un XML valide dans les fichiers, bloquez leur modification en les passant en lecture seule. Via SSH, exécutez ces commandes depuis la racine de votre installation PrestaShop :

chmod 444 config/xml/must_have_modules_list.xml
chmod 444 config/xml/default_country_modules_list.xml
chmod 444 config/xml/modules_native_addons.xml

Avec les droits 444, PrestaShop peut lire ces fichiers mais ne peut plus les écraser. Quand l’API Addons retourne une réponse invalide, la tentative d’écriture échoue silencieusement et vos fichiers XML restent propres. C’est la solution que je mets en place sur la plupart des boutiques que je gère : simple, propre, sans impact sur le fonctionnement. Si vous n’avez pas d’accès SSH, vous pouvez modifier les droits via votre client FTP (FileZilla par exemple) en faisant un clic droit sur le fichier et en choisissant “Droits d’accès au fichier”.

Solution radicale : désactiver les appels API Addons

Si vous ne voulez plus jamais que PrestaShop tente de contacter l’API Addons pour ces listes, vous pouvez désactiver ces appels en surchargeant la classe Tools de PrestaShop. C’est une solution plus technique qui nécessite de créer un fichier de surcharge dans /override/classes/Tools.php. Elle est pertinente si vous gérez une boutique en production stable sur PrestaShop 1.6 ou 1.7 et que vous n’avez de toute façon aucun intérêt à voir des suggestions de modules Addons dans votre back-office, ce qui est souvent le cas des boutiques matures qui installent leurs modules manuellement. Pour aller plus loin sur les optimisations techniques de votre back-office, consultez aussi cet article sur la correction des URLs problématiques dans PrestaShop, un autre classique qu’on croise souvent sur les boutiques 1.7.

Comment éviter que ça revienne

Si vous avez appliqué le chmod 444, vous êtes tranquille. Mais si vous repassez sur ces fichiers pour une raison ou une autre (mise à jour, migration), pensez à réappliquer les droits. L’autre point à garder en tête : ce bug est structurellement lié aux vieilles versions de PrestaShop. Les versions 1.6 et 1.7 utilisent un mécanisme de communication avec l’API Addons qui n’est plus aligné avec ce que retourne l’API aujourd’hui. PrestaShop 8 gère ça différemment. Si votre boutique tourne encore sur une version ancienne, c’est un argument de plus pour envisager une migration : pas parce que cette erreur est critique, mais parce qu’une boutique sur une version non maintenue accumule ce genre de petits problèmes au fil du temps.

Conclusion

L’erreur country_module_list.xml PrestaShop fait partie de ces bugs qui stressent inutilement alors qu’ils ne cassent rien de critique. La cause est connue : l’API Addons qui retourne une réponse invalide lors d’une maintenance ou d’un incident. Les solutions sont accessibles même sans être développeur. XML valide + chmod 444, et c’est réglé. Si vous n’êtes pas à l’aise avec le FTP ou SSH, ou que vous préférez déléguer ça à quelqu’un qui connaît PrestaShop, je peux intervenir rapidement sur votre boutique. Ce genre de correction prend rarement plus d’une heure.