Back-office PrestaShop inaccessible : retrouver l’accès sans rien casser

Plus de connexion au back-office, plus de commandes traitées : les paiements arrivent, mais personne ne peut expédier. Un back-office PrestaShop inaccessible est pourtant rarement une grosse panne. C’est souvent un cookie, un mot de passe, une adresse oubliée, ou une protection qui fait son travail.

Le message affiché dit presque toujours où chercher. Partez de lui : chaque message a sa section, selon votre version (1.6 à 9), avec ce que vous pouvez tenter seul et le point où il vaut mieux s’arrêter.

Quel message voyez-vous ?

Impossible de se connecter ? Derrière un back-office PrestaShop inaccessible, on trouve en général l’une de ces causes : adresse d’administration changée, mot de passe refusé ou compte désactivé, cookie ou IP qui change, jeton de sécurité périmé, erreur du serveur. Chaque ligne du tableau renvoie à sa section, et les 5 règles qui suivent passent avant tout essai.

Ce que vous voyez	Cause la plus probable
Page introuvable en tapant /admin admin 404, admin page not found	Le dossier d’administration a un nom unique, donné à l’installation.
« Pour des raisons de sécurité, vous ne pouvez pas vous connecter tant que vous n’avez pas : … » For security reasons, you cannot connect to the back office until you have…	Dossier /install encore présent, ou dossier admin pas renommé.
« Ce compte employé n’existe pas, ou le mot de passe est erroné. » The employee does not exist, or the password provided is incorrect. 1.7 à 9 (1.6 : « Compte employé inexistant, ou mauvais mot de passe. »)	Mauvais e-mail ou mot de passe, ou compte désactivé : même message.
E-mail de réinitialisation absent, « … toutes les 360 minutes seulement », « Votre demande de réinitialisation a expiré » 1.7 à 9 (message propre à la 1.6 dans la section)	6 h entre deux demandes, lien de plus de 24 h, ou e-mails bloqués.
Retour à la page de connexion, sans message login loop 1.6 à 8	Cookie périmé, http et https mélangés, IP qui change.
« Le protocole SSL est activé. Veuillez utiliser le lien suivant… (https://) » bloquant en 9	Adresse tapée en http.
Déconnecté au bout de 15 minutes ou d’une heure 1.6 à 8	Inactivité, sans la case « Rester connecté ».
« Vous avez été déconnecté pour des raisons de sécurité » You have been logged out for security reasons 9 uniquement	Session supprimée, ou IP changée depuis la connexion.
« Clé de sécurité invalide », « Jeton non valide » Invalid security token, Invalid token, The CSRF token is invalid « Jeton non valide » : 1.7 à 9	Favori ou vieil onglet ; à chaque clic après une migration : configuration.
Trop de redirections ERR_TOO_MANY_REDIRECTS	Cloudflare en SSL « Flexible », certificat absent ou expiré, réglages SSL en base.
Erreur 403 ou 406 en enregistrant	Pare-feu de l’hébergeur ou de Cloudflare.
Menus en 404 (index.php/…) 1.7 à 9	Réécriture d’adresses cassée (.htaccess du dossier admin, nginx).
Erreur 500 ou page blanche sur l’admin seulement diagnostic guidé, sur une autre page	Cache, module, droits d’écriture, mémoire.
Mot de passe changé sans vous, employé ou session inconnus, dossier admin disparu	Possible piratage : ne touchez à rien.

Si votre message n’est pas dans le tableau, appelez le 09 72 03 59 17 ou décrivez-nous la panne.

Avant de toucher à quoi que ce soit

1. Commencez par ce qui ne modifie rien : navigation privée, adresse en https.
2. Avant de modifier un fichier, téléchargez-en une copie.
3. Avant toute requête dans la base, un export complet (phpMyAdmin > Exporter, ou l’outil de sauvegarde de l’hébergeur). Toute la base, pas une table.
4. Une modification à la fois. Si elle ne change rien, annulez-la avant d’essayer autre chose.
5. Ne publiez jamais l’adresse du back-office ni le contenu de parameters.php ou settings.inc.php, sur un forum comme dans un formulaire.

Quelle version avez-vous, sans back-office ?

À la racine de la boutique	Version
un dossier var/	1.7.4 ou plus récente (8 et 9 compris)
un dossier app/, sans var/	1.7.0 à 1.7.3
ni app/ ni var/	1.6

Le numéro exact, en lecture seule : config/settings.inc.php, ligne _PS_VERSION_ (1.6) ; config/autoload.php, même ligne (1.7.0 à 1.7.4) ; app/AppKernel.php, ligne const VERSION (1.7.5 à 8.0) ; src/Core/Version.php (8.1 et plus).

Vous ne trouvez plus l’adresse du back-office (admin 404)

Taper votre-boutique.fr/admin mène à une page introuvable (« admin 404 », « admin page not found »). C’est normal : l’adresse du back-office n’est pas /admin.

Pourquoi ce n’est pas /admin

PrestaShop renomme le dossier d’administration pour le cacher aux robots : admin, trois chiffres, puis des caractères aléatoires (6 en 1.6 et 1.7, 16 depuis la 8). Cela se fait à la première ouverture de la page de connexion en 1.6, 1.7 et 8, à la fin de l’installation en 9.

Retrouver le dossier

Premier réflexe, sur votre ordinateur habituel : tapez « admin » dans la barre d’adresse, l’historique du navigateur propose souvent l’adresse complète.

Sinon, regardez les fichiers (le nom n’est pas dans la base). À la racine, cherchez le dossier qui contient themes/, filemanager/ et un index.php où figure define('_PS_ADMIN_DIR_'. L’adresse du back-office est celle de la boutique suivie de ce nom (exemple dans la documentation officielle sur la connexion au back-office).

« Vous ne pouvez pas vous connecter tant que… »

Il suit une installation ou une restauration incomplète. Faites seulement ce que le message liste. Copiez /install sur votre ordinateur, supprimez-le du serveur, puis renommez admin en admin suivi de chiffres et de lettres. En 9, videz ensuite le contenu de var/cache/prod/ et var/cache/dev/ : d’après le code, le nom du dossier y est mémorisé.

En 9, « The admin folder could not be renamed into… » vient de l’installateur : un problème de droits, probablement (propriétaire des fichiers, Docker), à corriger côté serveur, pas en passant tout en 777.

Le dossier a disparu

Si aucun dossier ne correspond et que vous n’avez rien supprimé, ne restaurez rien. Hébergeurs et antivirus mettent parfois en quarantaine un dossier infecté, l’un des signes de piratage. Lisez d’abord la section piratage.

Mot de passe admin refusé ou oublié : « Ce compte employé n’existe pas… »

De la 1.7 à la 9, le refus s’affiche ainsi : « Ce compte employé n’existe pas, ou le mot de passe est erroné. » (en anglais : « The employee does not exist, or the password provided is incorrect. »). En 1.6 : « Compte employé inexistant, ou mauvais mot de passe. » Il ne dit pas lequel des deux, c’est voulu. Trois causes : mauvaise adresse e-mail (un ancien prestataire a pu créer le compte avec la sienne), mauvais mot de passe, ou compte désactivé.

Après une mise à jour vers la 9, un compte resté en MD5 (aucune connexion en 1.7 ni en 8) serait refusé : passez par « Mot de passe oublié » ou la commande de la 9.2.

Si vous êtes certain du mot de passe et que personne ne l’a changé, arrêtez-vous là et lisez les signes de piratage. Reprendre l’accès par la base ne fermerait pas la porte d’entrée.

Mot de passe oublié : 24 h, 6 h et les e-mails

• 1.6 : PrestaShop génère un nouveau mot de passe et vous l’envoie en clair par e-mail ; changez-le dès la connexion. Trop tôt, il répond « Vous ne pouvez regénérer votre mot de passe que toutes les 360 minute(s) ».
• 1.7, 8 et 9 : un lien, valable 24 h par défaut. Trop ancien : « Votre demande de réinitialisation a expiré. Veuillez recommencer. » Trop tôt : « … toutes les 360 minutes seulement ».
• Partout : une demande toutes les 360 minutes (6 h) par défaut ; redemander plus tôt ne sert à rien.

Si l’e-mail n’arrive pas, regardez les spams, puis vérifiez que la boutique envoie encore ses e-mails de commande. Si elle n’en envoie plus, c’est ce problème à régler en premier (PrestaShop n’envoie plus d’e-mails). Un compte désactivé ne reçoit rien non plus.

Le plus sûr, si un associé ou votre ancien prestataire a un compte super-administrateur : il change votre mot de passe dans Paramètres avancés > Équipe (Administration > Employés en 1.6).

PrestaShop 9.2 : la commande console

Depuis PrestaShop 9.2.0, publiée le 30/09/2026, une commande officielle change le mot de passe sans passer par phpMyAdmin, avec un accès SSH. Depuis la racine de la boutique : bin/console suivi de prestashop:employee:change-password. Lancée sans option, elle demande l’e-mail, puis deux fois le nouveau mot de passe. L’option --password le laisserait dans l’historique du shell ; la documentation de la commande la déconseille aussi.

En dernier recours : changer le mot de passe admin par phpMyAdmin

Détail par version, pour les personnes à l’aise avec phpMyAdmin

Le mot de passe est dans la colonne passwd de la table des employés (préfixe de vos tables, puis employee). On ne modifie qu’une ligne, celle de votre e-mail :

• 1.6 : le MD5 de la clé _COOKIE_KEY_ (config/settings.inc.php) suivie du nouveau mot de passe (fonction MD5 de phpMyAdmin).
• 1.7 et 8 : un hachage bcrypt généré sur le serveur (fonction password_hash de PHP, en SSH). Un MD5 construit avec la clé cookie_key de app/config/parameters.php est encore accepté, puis converti à la connexion suivante.
• 9 : bcrypt seulement. La connexion au back-office de la 9 ne passe plus par la vérification MD5 : d’après le code, un MD5 serait refusé.

Vérifiez que la colonne active vaut 1, ne touchez pas à id_profile, et changez le mot de passe depuis le back-office une fois connecté.

Vous revenez sans cesse à la page de connexion (login loop)

Vous saisissez vos identifiants, la page se recharge, vide, sans message. De la 1.6 à la 8, PrestaShop réagit ainsi quand il ne reconnaît pas votre session. Quatre essais, dans l’ordre :

1. Navigation privée, ou suppression des cookies du seul domaine de la boutique.
2. Adresse tapée en https. Depuis la 1.7.8, avec le SSL sur tout le site, le cookie d’administration ne circule qu’en https : un vieux favori en http peut suffire à tourner en rond. En 9, « Le protocole SSL est activé » bloque même la connexion (sauf depuis l’IP de maintenance ou le serveur).
3. Une connexion fixe. « Vérifier l’adresse IP du cookie », activée par défaut, vous déconnecte si votre IP change (4G, VPN, IPv6). Derrière Cloudflare ou un proxy, l’IP vue par PrestaShop peut changer sans vous : la correction est celle de la section PrestaShop 9 (vraie IP transmise par l’hébergeur), jamais la suppression de la vérification.
4. Le cache vidé par FTP : contenu de var/cache/prod/ et var/cache/dev/ (1.7.4 et plus), ou de app/cache/ (1.7.0 à 1.7.3). Le contenu, pas les dossiers. Puis un seul rechargement.

Si la boucle résiste à la navigation privée et au https, la cause est dans les réglages SSL enregistrés en base (détail plus bas, étape 3), ou dans le serveur. La correction se fait dans phpMyAdmin, base exportée au préalable (règle 3), ou vous nous la confiez.

Déconnecté au bout de 15 minutes ou d’une heure

Sans « Rester connecté », PrestaShop vous déconnecte après une période d’inactivité : 15 minutes en 1.6 et de la 1.7.0 à la 1.7.7, une heure en 1.7.8 et en 8. En 9, la durée dépendrait de la configuration PHP de l’hébergeur. Cochez « Rester connecté », sauf sur un poste partagé : la session suit alors la « Durée de vie du cookie back-office » (Paramètres avancés > Administration ; Administration > Préférences en 1.6), 480 heures par défaut.

Après un déménagement ou un changement de domaine

Une boucle apparue le jour d’un changement d’hébergeur ou de domaine peut venir de vieux cookies, du cache, ou d’un fichier de configuration (parameters.php, settings.inc.php) qui n’est plus celui de la boutique. Ne régénérez surtout pas la clé du site (voir plus bas) : si les quatre essais échouent, c’est un cas pour nous.

« Vous avez été déconnecté pour des raisons de sécurité » (PrestaShop 9)

Ce message (« You have been logged out for security reasons ») n’existe qu’en PrestaShop 9. Deux cas :

1. Votre session a été supprimée de la table des sessions employés : par un autre administrateur (Paramètres avancés > Sécurité), ou parce qu’elle était périmée et a été effacée avec « Effacer les sessions expirées manuellement ». Une nouvelle connexion suffit.
2. Votre IP a changé depuis la connexion, avec « Vérifier l’adresse IP du cookie » activé (Paramètres avancés > Administration). Reconnectez-vous depuis une connexion stable.

Un message qui revient à chaque clic, même depuis le bureau, trahit souvent un proxy : derrière Cloudflare, PrestaShop voit peut-être l’IP du proxy plutôt que la vôtre. L’hébergeur doit transmettre la vraie IP des visiteurs ; décochez la vérification IP le temps de cette correction, puis recochez-la.

Regardez aussi la liste des sessions employés (Paramètres avancés > Sécurité, depuis la 8, voir la page Sécurité de la documentation officielle). Une session que personne chez vous n’a ouverte relève de la section piratage.

« Jeton non valide » ou « Clé de sécurité invalide » (invalid token)

Un clic dans le back-office, et vous tombez sur « Clé de sécurité invalide » (« Invalid security token ») ou, sur les pages récentes de la 1.7 à la 9, « Jeton non valide » (« Invalid token »). En 1.6, seul le premier existe.

Rien n’est cassé. Chaque lien du back-office porte un jeton de sécurité propre à votre compte ; sans le bon jeton, le lien vient d’un favori, d’un vieil onglet, ou d’un site piégé. D’où les boutons « Je comprends les risques et je veux vraiment afficher la page » (pages classiques) ou « Oui, je comprends les risques » (pages récentes), et « Sortez-moi d’ici ! ». Ne confirmez que si vous venez de cliquer vous-même sur un lien du back-office.

• La bonne méthode : fermez les onglets du back-office, déconnectez-vous, videz les cookies du domaine, repartez du tableau de bord.
• À chaque clic, juste après une migration : la clé du site ou la configuration ne correspond probablement plus à la boutique.

Récapitulatif : ce qui change d’une version à l’autre.

Redirections, 403 ou erreur serveur sur l’admin seulement

La boutique s’affiche, l’administration renvoie une erreur 500 ou une page blanche : le message exact est au journal, var/logs/ en 1.7.4 et plus, app/logs/ de la 1.7.0 à la 1.7.3. Videz le cache par FTP, une fois. Sans effet, suivez le diagnostic guidé de l’erreur 500 dans le back-office.

« Trop de redirections » (ERR_TOO_MANY_REDIRECTS)

Du plus sûr au plus délicat :

1. Cloudflare : en mode SSL/TLS « Flexible », passez en « Full (strict) » si le serveur a un certificat valide, celui de Let’s Encrypt activé chez l’hébergeur par exemple ; « Full » seulement pour un certificat auto-signé. Une erreur 526 ou 525 juste après : le certificat du serveur est absent, expiré ou non reconnu, voyez l’étape 2.
2. Certificat absent ou expiré : réinstallez-le depuis le panel de l’hébergeur.
3. Sinon, les réglages SSL enregistrés en base ne correspondent plus au serveur : correction dans phpMyAdmin après l’export de la règle 3, ou nous la faisons pour vous. Ce sont PS_SSL_ENABLED et, jusqu’en 8, PS_SSL_ENABLED_EVERYWHERE, colonne value de la table de configuration (préfixe de vos tables, puis configuration) ; avec plusieurs boutiques, chaque nom peut avoir plusieurs lignes. Notez leurs valeurs, puis passez-les à 0 : l’accès revient, mais les liens de la boutique repassent en http. Si PS_COOKIE_SAMESITE (depuis la 1.7.8) vaut None, passez-le à Lax en même temps. Remettez les valeurs notées dès que la cause est corrigée (certificat, Cloudflare ou hébergeur).

Erreur 403 ou 406 en enregistrant

Le pare-feu applicatif de l’hébergeur ou de Cloudflare bloque une requête qu’il juge suspecte. Envoyez l’heure, la page et l’action au support de l’hébergeur : il retrouvera la règle. Une protection par mot de passe ou par IP posée sur le dossier admin peut aussi bloquer.

Menus en 404 (index.php/…)

Depuis la 1.7, une partie du back-office passe par des adresses en index.php/… (index.php/configure/… dès la 1.7.3, index.php/sell/… dès la 1.7.5). En 404, elles signalent une réécriture d’adresses cassée : .htaccess du dossier admin disparu ou modifié, ou nginx sans règles équivalentes. Remettez le .htaccess d’origine de votre version (archive officielle de la même version), après copie de l’actuel ; sous nginx, voyez avec l’hébergeur.

Et si ce n’était pas une panne ?

Un intrus qui a changé votre mot de passe provoque le même refus qu’une faute de frappe. Arrêtez-vous si vous voyez l’un de ces signes :

• un compte employé inconnu (Paramètres avancés > Équipe), surtout récent ;
• votre mot de passe ne marche plus, et personne ne l’a changé ;
• une session employé inconnue dans Paramètres avancés > Sécurité (8 et 9) ;
• un fichier override/controllers/admin/AdminLoginController.php que vous n’avez pas posé ;
• des modules que personne ne reconnaît ;
• le dossier d’administration disparu, ou mis en quarantaine par l’hébergeur.

Les conseils de forum à ne pas suivre

Ils rouvrent l’accès vite, et laissent derrière eux une faille ou une boutique cassée.

• Supprimer la vérification IP dans Cookie.php. Fichier du cœur, écrasé à la mise à jour, et protection retirée pour tous les comptes. À la place : faire transmettre la vraie IP.
• Allonger le délai de déconnexion dans AdminController.php. Même défaut ; la case « Rester connecté » obtient ce résultat sans toucher au code.
• Taper son mot de passe dans un générateur MD5 en ligne. Vous le confiez à un inconnu, et la 9 refuserait ce MD5. La commande de la 9.2, un bcrypt généré sur votre serveur (1.7 à 9) ou, en 1.6, la fonction MD5 de phpMyAdmin font mieux.
• Déposer un script de réinitialisation par FTP. Oublié sur le serveur, il donne la main à n’importe qui ; phpMyAdmin, base exportée avant, ne laisse pas de porte ouverte.
• Régénérer cookie_key ou _COOKIE_KEY_. Les mots de passe encore en MD5 deviennent faux (tous en 1.6 ; en 1.7 et 8, ceux qui n’ont pas encore été convertis, clients compris), et, jusqu’à la 8, les liens classiques du back-office changent de jeton. À la place : ne jamais y toucher.
• Remplacer les fichiers du back-office, ou réinstaller PrestaShop. Des fichiers d’une autre version cassent le reste. À la place : lire le journal.
• Mettre les droits en 777. Tout processus peut alors écrire partout ; c’est le propriétaire des fichiers qu’il faut corriger.
• Désactiver « Protection des jetons dans le back-office ». On retire la défense contre les liens piégés pour faire taire un message ; repartir du tableau de bord suffit.

Questions fréquentes sur le back-office PrestaShop inaccessible

Comment se connecter au back-office PrestaShop, et quelle est son adresse ?

C’est l’adresse de la boutique suivie du dossier d’administration : admin, trois chiffres et des caractères aléatoires. Ce n’est pas /admin. Sans favori, cherchez par FTP le dossier qui contient themes/, filemanager/ et un index.php définissant _PS_ADMIN_DIR_.

Comment changer le mot de passe admin PrestaShop sans accès au back-office ?

Le lien « Mot de passe oublié » ou un autre super-administrateur ; en 9.2 avec SSH, la commande prestashop:employee:change-password ; phpMyAdmin en dernier, après un export complet. Mot de passe changé sans vous ? Pensez d’abord au piratage.

Combien de temps est valable le lien de réinitialisation ?

24 heures par défaut, en 1.7, 8 et 9. Une nouvelle demande n’est acceptée que 360 minutes (6 h) après la précédente. En 1.6, pas de lien : un nouveau mot de passe arrive en clair, à changer aussitôt.

Que veut dire « Jeton non valide » (invalid token) ?

Le lien ouvert ne porte pas le jeton de sécurité de votre session : favori, ancien onglet, lien reçu par e-mail. Ne confirmez que si vous venez de cliquer sur un lien du back-office ; sinon, repartez du tableau de bord.

Pourquoi suis-je déconnecté toutes les heures ?

En 1.7.8 et en 8, sans « Rester connecté », la session s’arrête après une heure d’inactivité (15 minutes avant la 1.7.8). En 9, cela dépendrait de la configuration PHP de l’hébergeur. Cochez « Rester connecté », sauf sur un poste partagé.

Je n’ai accès qu’au panel de l’hébergeur : que puis-je faire ?

Presque tout ce qui est sans risque : le gestionnaire de fichiers remplace le FTP (dossier admin, /install, cache), phpMyAdmin exporte la base. Pour une requête sur la base, ou sans SSH pour la commande de la 9.2, faites-vous aider.

Combien coûte un dépannage quand le back-office est inaccessible ?

Chez CYBERIAL, dès 150 € HT, avec un prix fixe validé avant toute intervention. Pour une boutique bloquée, réponse en moins d’une heure, 7j/7, de 8 h à 22 h, au 09 72 03 59 17.

Vous préférez qu’on s’en occupe ?

Le formulaire ci-dessous suffit pour un back-office PrestaShop inaccessible : l’adresse de la boutique (celle que voient vos clients), le message affiché et, si vous la connaissez, votre version. Choisissez « Mise à jour qui a tout cassé » si l’accès a sauté après une mise à jour, « Erreur 500 / Page blanche » si l’administration affiche une erreur ou une page vide, « Site piraté / Malware » si vous avez vu un signe de piratage, sinon « Autre ». N’écrivez ni mot de passe ni adresse d’administration dans le formulaire.

Pour aller plus vite que le formulaire, appelez le 09 72 03 59 17 (7j/7, de 8 h à 22 h). Une fois l’accès rétabli, pour un suivi régulier de la boutique : maintenance PrestaShop à 69 € HT/mois, sans engagement.