Maintenance et pannes

De trois semaines pour une boutique restée proche du standard, à deux mois pour une boutique très modifiée. Ce n'est pas le nombre de produits qui fait la durée, mais la quantité de code ajouté par-dessus PrestaShop au fil des ans — les surcharges — et de modules à traiter. D'où l'inventaire préalable, qui donne une fourchette ferme plutôt qu'un ordre de grandeur.

Pour une migration depuis une vieille version, la 8 reste la cible raisonnable : ses modules sont mûrs et stables. La 9 est intéressante en création, où l'on part de zéro sans passif à gérer. Ce n'est pas une règle absolue — cela dépend des modules dont vous dépendez.

Ceux encore maintenus, oui, parfois moyennant une licence à jour. Les autres — et il y en a toujours — demandent un arbitrage : remplacer par un équivalent, reprendre le code, ou supprimer la fonction si elle ne sert plus. L'inventaire liste chaque cas avec son coût.

Non. Tout se fait sur une copie, et seule la bascule finale est instantanée. L'ancienne version reste accessible en secours après le basculement.

Sur une 1.6, non : elle ne reçoit plus de correctifs de sécurité, il n'y a rien à appliquer. Sur une 1.7 en fin de vie, on gagne du temps mais pas indéfiniment. C'est un report, pas une solution — et le report a un coût qui augmente.

Une fois la boutique à jour, la tenir à jour représente environ une heure par mois. C'est exactement ce que couvre un contrat de maintenance — et c'est beaucoup moins cher que la montée qu'on finit par devoir payer.

L'engagement porte sur 4h ouvrées. En dehors, cela dépend de ma disponibilité — je préfère l'annoncer clairement plutôt que promettre une astreinte permanente que je ne tiendrais pas. Une astreinte réelle se contractualise, c'est ce que couvre la formule de maintenance la plus complète.

Ne nettoyez rien avant d'avoir copié l'état actuel : les traces de l'intrusion sont ce qui permet de trouver par où elle est entrée. Changez les mots de passe d'accès au serveur et à la base, mettez la boutique en maintenance si les paiements sont en jeu, et appelez.

Au temps réellement passé, avec une estimation donnée après le diagnostic et avant toute correction. La plupart des pannes se règlent en deux à quatre heures ; une boutique compromise demande une journée ou plus, parce qu'il faut aussi refermer l'entrée.

Je vous le dis, avec les éléments pour le leur démontrer : journaux, horodatages, mesures. C'est souvent le livrable le plus utile — un hébergeur répond rarement à « mon site est lent », toujours à une trace d'erreur datée.

Vous choisissez une formule et payez par carte. Vous recevez aussitôt un message qui liste les accès dont j'ai besoin — back-office, accès techniques au serveur (FTP ou SSH), hébergeur — et la première intervention a lieu sous 24h ouvrées. Elle commence toujours par le même geste : une sauvegarde complète, avant de toucher à quoi que ce soit.

Oui, depuis votre espace Stripe, sans justification ni préavis. Une précision qui compte : à l'arrêt, vous gardez la boutique dans l'état où elle est, à jour, avec ses sauvegardes. Un contrat de maintenance qui laisserait derrière lui une installation qu'un autre ne peut pas reprendre serait un piège, pas un service.

Un service externe interroge le site chaque minute depuis plusieurs pays ; une indisponibilité déclenche une alerte immédiate, de jour comme de nuit. Le délai d'intervention dépend de la formule : 48h en Essentiel, 12h en Performance, 2h en Premium. Ce délai court à partir de l'alerte, pas de votre appel — c'est tout l'intérêt de la surveillance.

Non, et les deux ne traitent pas les mêmes pannes. L'hébergeur répond du serveur ; la maintenance répond de PrestaShop qui tourne dessus — une mise à jour qui casse un module, un cache qui sert une page périmée, une commande qui n'envoie pas son email. Si votre hébergement est manifestement sous-dimensionné, je le dis, et je vous oriente.

Ce site est consacré à PrestaShop, et ces formules sont pensées pour lui : elles supposent de connaître son rythme de versions, ses surcharges — le code ajouté par-dessus le logiciel au fil des ans — et son cache. Je travaille aussi sur d'autres environnements, mais ce n'est pas le sujet ici. Et pour une boutique PrestaShop, vous avez tout intérêt à choisir quelqu'un dont c'est le terrain quotidien.

Non. La maintenance d'une boutique se fait à distance par nature : les accès sont les mêmes depuis n'importe où, et une panne à 2h du matin ne se règle pas en voiture. La plupart des boutiques que je suis sont ailleurs en France. Le déplacement garde son sens pour une formation d'équipe ou un cadrage de refonte, pas pour un correctif.

La règle est l'heure : en dessous, c'est inclus — un affichage à corriger, un bloc à ajouter, un module à régler. Au-dessus, c'est un chantier, devisé à part : développement spécifique, montée de version, migration. La frontière est annoncée avant de commencer, jamais découverte sur la facture.

À tout moment, depuis votre espace Stripe ou en me le demandant. Le changement prend effet à l'échéance suivante, au prorata s'il y a lieu. Dans les faits, c'est souvent le sens inverse de celui qu'on attend : une boutique stabilisée redescend d'un cran, parce qu'elle n'a plus besoin du délai le plus court.

Les correctifs de sécurité et les petites mises à jour, oui — c'est même l'essentiel de ce qui justifie un contrat. Le passage d'une grande version à une autre, non : il faut tester les modules un par un et prévoir un retour arrière, donc un chantier à part, mené d'abord sur une copie de la boutique. Ce qui est inclus, en revanche, c'est de vous dire quand il devient déraisonnable d'attendre.