Heures ouvrées, sans astreinte
On ne fait pas d’astreinte et on ne vous en promet pas. Une panne signalée un soir ou un week-end est prise en charge à la reprise des heures ouvrées.
Dépannage PrestaShop en urgence : boutique en panne ou piratée
Erreur 500, page blanche, tunnel de commande bloqué, site piraté : pour un dépannage PrestaShop, un incident critique est pris en charge sous 2 heures ouvrées par un développeur, que vous soyez client ou non. On intervient là où votre site se trouve, chez votre hébergeur actuel, et on remet l’organisation au propre une fois les commandes reparties.
Notre façon d’intervenir
Dépannage PrestaShop : d’abord relancer la boutique, ensuite remettre de l’ordre
Sur les boutiques qu’on héberge, rien ne part en production depuis un poste de développeur : chaque correction passe par un dépôt Git, une préproduction et un déploiement automatisé. Quand un site qui n’est pas chez nous tombe en panne ou se fait pirater, on ne commence pas par monter tout ça. Ce serait des jours de travail pendant que la boutique ne vend plus.
On intervient donc là où le site se trouve : en FTP ou en SSH, chez votre hébergeur actuel, avec les accès que vous nous transmettez. On lit les journaux d’erreurs, on isole la cause, on corrige ce qui empêche de vendre. Chaque intervention est tracée avec le temps passé, comme sur nos maintenances.
Une fois la boutique relancée, on reprend les choses dans l’ordre : dépôt Git, préproduction, sauvegardes hors de l’infrastructure, supervision par Minty Monito, et si c’est pertinent un hébergement sur Kubernetes, serveurs en France. C’est le chemin d’une reprise de site PrestaShop, que vous enchaînez ou non : c’est vous qui décidez de la suite.
Délais
Un incident critique pris en charge sous 2 heures ouvrées
Site en panne, tunnel de commande bloqué, faille exploitée : c’est ce qu’on appelle un incident critique. Un développeur ouvre le dossier dans ce délai, pendant les heures ouvrées.
Client ou pas encore client
Pas besoin de contrat pour nous appeler. 36 Factory n’était pas client le jour de son incident de sécurité : la maintenance de ses sept boutiques est venue après.
Voir le projetVous parlez au développeur
Pas de chef de projet entre vous et la personne qui corrige : c’est Maxime ou Yannick qui lit vos journaux d’erreurs et vous dit ce qu’il a trouvé.
De PrestaShop 1.6 à 9.2
On maintient encore des boutiques 1.6, comme celle de Micro Mobility jusqu’à sa refonte en PrestaShop 9, mise en ligne le 20 juillet 2026.
Voir le projet
Les pannes
Erreur 500, page qui ne répond plus, site piraté : les pannes PrestaShop qu’on a dépannées
Des cas rencontrés sur des boutiques qu’on a reprises, avec la cause qu’on a fini par trouver. Chacun est raconté en détail sur notre blog.
Une erreur 500 une fois sur deux
Deux modules embarquent la même librairie dans des versions différentes. PrestaShop ne gère aucune dépendance entre modules : la version chargée dépend de l’ordre des hooks, donc de la page consultée, et le 500 va et vient.
Des appels AJAX qui échouent
Trois octets invisibles, un BOM UTF-8 au début d’un fichier de traduction d’un module tiers, et deux appels AJAX du front tombent en « headers already sent ».
Un tunnel de commande inaccessible
Aucune erreur PHP, et pourtant le checkout ne s’affiche plus : une règle de redirection SEO importée des mois plus tôt s’exécute dans un hook si précoce qu’elle neutralise le contrôleur natif.
Une création de compte impossible
Le tunnel affiche deux formulaires client dans la même page, et le module de reCAPTCHA invisible écrit toujours dans le premier id trouvé. La création de compte échoue sur un captcha que personne ne voit.
Un site PrestaShop piraté
Un scan anti-malware rapide passe à côté des webshells les mieux cachés : dans des dossiers de traduction, derrière de faux fichiers de classe ou de faux scripts d’upgrade. On les cherche un par un, puis on durcit l’installation.
Des accents cassés après une restauration
Le client mysql négocie souvent latin1 par défaut : à l’import d’un dump, tout l’UTF-8 ressort doublement encodé, alors que les contrôles de volume restent verts.
Sur le blog
Six pannes PrestaShop racontées jusqu’à leur cause
On publie nos dépannages quand ils peuvent servir à d’autres : le symptôme, le chemin du diagnostic, le correctif et le garde-fou posé pour que ça ne revienne pas.
- Deux modules, une même librairie : le 500 qui tombe une fois sur deux
- BOM UTF-8 dans un module : quand 3 octets cassent l’AJAX
- Des redirections SEO qui écrasent les pages natives et cassent le checkout
- Un reCAPTCHA invisible qui bloque la création de compte
- Webshells camouflés dans un module PrestaShop : les détecter
- Le double encodage UTF-8 à l’import d’un dump MySQL
En deux temps
Pendant l’urgence, puis une fois la boutique relancée
Corriger sur place n’est pas une façon de travailler, c’est une façon de sortir de la panne. Voici ce qui change entre les deux temps.
| Critère | Pendant l’urgence | Une fois la boutique relancée |
|---|---|---|
| Où on intervient | Sur votre hébergement actuel, en FTP ou en SSH | Dans un dépôt Git, testé en préproduction avant la production |
| Objectif | Que la boutique reprenne les commandes | Que la panne ne se reproduise pas |
| Sauvegardes | Copie des fichiers et de la base avant de modifier quoi que ce soit | Sauvegarde complète hors infrastructure, sous 72 heures ouvrées à la reprise |
| Surveillance | Journaux d’erreurs lus à la main | Minty Monito : disponibilité, commandes, versions des modules comparées à la base CVE, fichiers suspects |
| Hébergement | Celui que vous avez, tel quel | Gardé s’il est sain et à votre nom, sinon Kubernetes en GitOps, serveurs en France |
Deux reprises après incident
Ce que ça a donné chez 36 Factory et Galerie Auto Direct
36 Factory nous a confié sept boutiques PrestaShop après un incident de sécurité, avec des failles exploitées sur plusieurs d’entre elles. On a d’abord refermé les points d’entrée, activé l’authentification à deux facteurs, renouvelé les secrets et durci les serveurs, sans couper les boutiques. Un mois après, elles tournaient sur Kubernetes ; deux mois plus tard, le multiboutique passait en PrestaShop 8.2. Aucune nouvelle intrusion depuis la reprise.
Galerie Auto Direct arrivait avec un site sans maintenance suivie, sans dépôt de code ni environnement de développement. Repris en juin 2026, remis en ordre en un mois : accès récupérés, dépôt GitLab et environnement Docker reconstruits, sécurisation, consentement Axeptio, suivi GA4 dédoublonné, HT/TTC du panier corrigé, commande sans compte activée.
Votre site vient d’être piraté ? Notre page Mon site a été piraté, que faire ? donne les premiers réflexes, et ceux à éviter, avant qu’on prenne la main.
Après le dépannage
Pour que la prochaine panne se voie avant vos clients
Le dépannage relance la boutique. Si vous voulez que ça tienne, voici ce qu’on met en place ensuite.
Reprise de site : accès récupérés et sauvegarde hors infrastructure sous 72 heures ouvrées.
Découvrir la repriseMaintenance : un volume de jours à l’année, consommé à votre rythme, dès 6 jours par an (350€ HT par mois en moyenne).
Découvrir la maintenanceHébergement Kubernetes piloté en GitOps, serveurs en France.
Découvrir l’hébergementMinty Monito, notre supervision, incluse dans toute maintenance.
Découvrir Minty Monito
Questions
Vos questions sur le dépannage PrestaShop
Ce qu’on nous demande quand une boutique vient de tomber.
Mon site PrestaShop affiche une erreur 500, que faire ?
Notez l’heure et la page concernée, puis transmettez-nous un accès FTP ou SSH : la cause est en général écrite dans les journaux d’erreurs du serveur ou de PrestaShop. Si le 500 va et vient selon les pages, pensez à un conflit entre modules : c’est le cas qu’on raconte dans notre article sur deux modules qui embarquent la même librairie.
Mon PrestaShop a été piraté, par quoi commencer ?
Ne restaurez rien et ne supprimez rien vous-même : les fichiers suspects permettent de retrouver le point d’entrée. Faites une copie des fichiers et de la base, puis transmettez-nous un accès FTP ou SSH. Un développeur prend le dossier sous 2 heures ouvrées, client ou non, cherche les portes dérobées (webshells) là où les scans rapides ne regardent pas, puis referme la faille. Chez 36 Factory, les sept boutiques ont été sécurisées sans être coupées.
Intervenez-vous le soir ou le week-end ?
Non, on ne fait pas d’astreinte. Un incident critique est pris en charge sous 2 heures ouvrées ; une panne signalée le week-end est traitée à la reprise des heures ouvrées. On préfère le dire que promettre une disponibilité qu’une équipe resserrée ne peut pas tenir.
Faut-il être client Mintfull pour un dépannage ?
Non. On dépanne aussi des boutiques qu’on ne connaît pas encore, sur leur hébergement actuel. 36 Factory n’était pas client le jour de son incident ; la maintenance et l’hébergement sont venus après.
Pourquoi intervenir en FTP alors que vous déployez tout depuis Git ?
Parce que monter un dépôt Git et une chaîne de déploiement prend du temps que votre boutique n’a pas quand elle est en panne. Pendant l’urgence, on corrige sur place et on trace chaque modification. Ensuite, on remet un dépôt propre : chez Galerie Auto Direct, le dépôt GitLab et l’environnement Docker ont été reconstruits après la reprise.
Faut-il changer d’hébergeur après un dépannage ?
Pas pendant l’urgence. On corrige d’abord sur votre hébergement actuel, en FTP ou en SSH. Ensuite, s’il est sain et à votre nom, on le garde ; sinon, on propose une migration planifiée. Chez 36 Factory, le passage sur notre hébergement Kubernetes a eu lieu un mois après la sécurisation.
Dépannez-vous les anciennes versions de PrestaShop ?
Oui, de 1.6 à 9.2. On a maintenu le PrestaShop 1.6 de Micro Mobility de février 2024 jusqu’à sa refonte en PrestaShop 9, avec plus de 200 tickets traités. Une vieille version se dépanne comme une récente ; la question de la migration vient après.
Témoignages
Ils nous font confiance pour leur performance e-commerce
Ce que disent les e-commerçants qui nous ont confié leur boutique.
Garance Hurlet
Responsable marketing, Pure Filters
Nous sommes très satisfaits de notre collaboration avec Mintfull Agency pour l’évolution de notre site internet. […] Les échanges ont toujours été fluides, les conseils pertinents et le suivi irréprochable. Une agence sérieuse que nous recommandons sans hésiter pour la qualité de son travail et de son accompagnement.
Mathilde Charetier
Responsable e-commerce, Atelier du quai
Très satisfaite de Mintfull ! Ils nous ont accompagnés pour la correction de failles de sécurité sur 3 de nos Prestashop et ont été très réactifs. Je recommande vivement 🙂
Clémence Bricon
Fondatrice, Maison Clémence
J’ai confié la gestion de mon site e-commerce à Maxime de Mintfull Agency, et ça a été une vraie bouffée d’air frais. En à peine une semaine, il a tout compris, tout optimisé, et depuis tout roule parfaitement. Réactif, pro, rigoureux et toujours de bonne humeur, il est devenu un vrai partenaire de confiance. Je recommande les yeux fermés !
Douglas Studient
Directeur Général, IPLN (client de 2021 à 2026)
Maxime et son équipe nous accompagne depuis 2021 dans tous nos projets de dev front et back end pour nos plateformes ( Prestashop et Symfony).Une equipe jeune, dynamique, fiable et force de proposition. C’est assez rare de trouver des partenaires avec qui il est possible de collaborer dans la durée.Merci Mintfull !
Damien Deyna
Chargé d’affaires, ETIP Composites
Nous avons fait appel à Mintfull pour la refonte complète et l’optimisation de notre site internet, la mission s’est parfaitement déroulée ! Maxime est réactif, disponible et force de proposition. Nous sommes très satisfaits du résultat et recommandons fortement Maxime et ses équipes !
Votre boutique PrestaShop est en panne ?
Décrivez le symptôme, la page concernée et votre hébergeur. Un développeur prend le dossier sous 2 heures ouvrées. Pour une panne en cours, le téléphone reste le plus direct : 06 45 29 90 44.
Signaler une panne Réserver un rendez-vous