Pourquoi l’accès au back-office PrestaShop est-il bloqué après la suppression d’un pack de langue ?

Un dirigeant supprime un pack de langue devenu inutile dans l’onglet Localisation du back-office PrestaShop, pour alléger l’administration ou nettoyer une boutique multilingue. Quelques minutes plus tard, impossible de se reconnecter : écran blanc, erreur fatale PHP, ou redirection en boucle vers la page de connexion. Ce scénario est fréquent et touche aussi bien les petites boutiques mono-langue que les configurations multiboutique avec plusieurs langues actives. La cause est presque toujours la même : un employé administrateur était rattaché à la langue supprimée, et PrestaShop ne gère pas automatiquement ce cas de figure.

Comprendre la cause technique du blocage

Dans PrestaShop, chaque employé (compte back-office) possède un champ id_lang dans la table ps_employee. Ce champ détermine la langue d’affichage de l’interface d’administration pour cet utilisateur. Lorsqu’un pack de langue est supprimé via Localisation > Langues, PrestaShop retire les traductions associées (fichiers de langue, valeurs dans ps_lang) mais ne vérifie pas systématiquement si un ou plusieurs employés pointent encore vers l’id_lang supprimé.

Résultat : au moment de la connexion, le contrôleur AdminLoginController tente de charger les traductions correspondant à l’id_lang de l’employé. Comme cette langue n’existe plus dans la table ps_lang, le système ne trouve aucun fichier de traduction à charger. Selon la version de PrestaShop (1.6, 1.7, 8.x) et le mode d’erreur PHP configuré, cela se traduit par :

• Une erreur fatale de type Notice ou Fatal error: Uncaught Exception mentionnant une langue introuvable.
• Une page strictement blanche si l’affichage des erreurs PHP est désactivé en production (ce qui est la configuration recommandée pour un site live).
• Une boucle de redirection vers /admin.../index.php sans message explicite.

Ce comportement est documenté de façon indirecte dans la documentation officielle PrestaShop sur la gestion des traductions et des employés, qui recommande de vérifier les dépendances avant toute suppression de langue en production.

Vérifier le diagnostic avant toute action

Avant de modifier quoi que ce soit, il est nécessaire de confirmer l’origine du blocage pour éviter une intervention inutile sur d’autres composants (cache, droits de fichiers, extension tierce). Trois vérifications rapides :

• Activer temporairement l’affichage des erreurs PHP dans le fichier config/defines.inc.php (passer PS_MODE_DEV à true) pour voir le message d’erreur exact. Cette étape doit être annulée immédiatement après le diagnostic, car elle expose des informations sensibles sur un site en production.
• Consulter la table ps_lang via phpMyAdmin ou un client SQL pour vérifier que l’id_lang supprimé n’apparaît plus, et noter les id_lang restants (par exemple id_lang = 1 pour le français restant).
• Consulter la table ps_employee et repérer la colonne id_lang pour chaque compte administrateur. Si un employé a comme valeur l’id_lang supprimé (par exemple 2, alors que seul 1 existe désormais), le diagnostic est confirmé.

Corriger le problème en base de données

La correction ne nécessite pas de réinstaller PrestaShop ni de restaurer une sauvegarde complète si le reste du site fonctionne normalement. Elle se fait par une requête SQL ciblée, à exécuter via phpMyAdmin, Adminer ou tout outil de gestion de base fourni par l’hébergeur.

La requête type consiste à réassigner l’id_lang valide restant à tous les employés concernés :

• UPDATE ps_employee SET id_lang = 1 WHERE id_lang = 2; (en adaptant les identifiants à la configuration réelle de la boutique, 1 étant l’id_lang du français ou de la langue restante, 2 étant celui qui a été supprimé).

Avant d’exécuter cette requête, il est impératif de réaliser une sauvegarde de la table ps_employee (export SQL ciblé), l’opération ne prenant que quelques secondes même sur une base de plusieurs milliers d’employés. Une fois la mise à jour effectuée, la connexion au back-office doit redevenir immédiatement accessible, sans vidage de cache supplémentaire dans la majorité des cas.

Alternative : réinstaller le pack de langue supprimé

Si la langue supprimée était utilisée pour l’affichage de contenus front-office (fiches produits traduites, CMS) et pas uniquement pour l’administration, la réinstallation du pack est préférable à la simple réassignation en base. Deux méthodes :

• Via Localisation > Langues > Importer une langue, en resélectionnant le pack officiel correspondant dans le catalogue PrestaShop (si la boutique dispose encore d’un accès internet sortant et que le pack existe toujours dans le dépôt officiel).
• Via import manuel d’un fichier .xml ou .gzip précédemment exporté, si une sauvegarde du pack avait été réalisée avant suppression (bonne pratique systématique avant toute suppression de langue).

Cette réinstallation recrée l’entrée dans ps_lang avec un nouvel id_lang, ce qui ne résout pas forcément automatiquement le lien avec les employés : il faut généralement vérifier à nouveau la table ps_employee après réinstallation pour confirmer la cohérence des identifiants.

Points de vigilance pour éviter la récidive

Plusieurs précautions limitent ce risque lors de la gestion courante des langues :

• Ne jamais supprimer une langue directement en production sans avoir vérifié au préalable, via une requête SQL simple, qu’aucun employé n’y est rattaché (SELECT id_employee, id_lang FROM ps_employee).
• Créer systématiquement une sauvegarde de la base de données complète avant toute opération de suppression de langue, module ou thème, même pour une action jugée mineure.
• Tester sur un environnement de préproduction (copie de la boutique) avant toute manipulation en base de langues sur un site générant du chiffre d’affaires.
• Documenter les id_lang utilisés par chaque employé dans un tableau de suivi interne, particulièrement utile sur les configurations multiboutique où plusieurs langues coexistent.

Quand solliciter un accompagnement externe

Cette procédure reste accessible à un administrateur à l’aise avec phpMyAdmin et les sauvegardes SQL. En revanche, si la boutique combine plusieurs boutiques (multiboutique), des modules de traduction tiers, ou si l’erreur persiste après réassignation en base, l’intervention d’un prestataire PrestaShop expérimenté évite les manipulations hasardeuses sur une base de production. Performeer PrestaShop met en relation les dirigeants de TPE et PME avec des prestataires qualifiés, de façon neutre et sans engagement, pour sécuriser ce type d’incident technique et éviter qu’il ne se reproduise.