Hébergement PrestaShop. Dimensionné sur votre catalogue, tenu les jours de pic.

Parce que PrestaShop s'installe à peu près partout, et que cela ne se voit qu'après. Sur une offre partagée, tout va bien jusqu'au jour où le catalogue grossit. Les lenteurs deviennent intermittentes, les imports de produits tournent mal, le processeur sature aux heures de pointe, et une campagne qui marche fait tomber la boutique. Ce sont ces signaux qui décident du passage à un serveur dédié, pas un nombre de visites. Nous faisons de l'hébergement infogéré : nous dimensionnons l'infrastructure sur votre catalogue et sur vos jours de pic, puis nous l'exploitons pour vous. Ce qui reste chez vous, c'est le code et les modules.

Le sujet est réel, et il est technique. PrestaShop 8 est construit sur la version 4.4 de Symfony, la brique logicielle qui porte son back-office. Cette version-là a atteint sa fin de vie chez son éditeur, donc la branche 8 de PrestaShop ne reçoit plus les correctifs de sécurité de Symfony. Votre boutique ne devient pas inutilisable du jour au lendemain et personne ne vous demandera de migrer dans le mois. En revanche, le compte à rebours a commencé, et il vaut mieux choisir la date de la montée que la subir après un incident. De notre côté, nous durcissons le système, nous filtrons ce qui arrive sur vos serveurs et nous traitons en priorité les failles critiques qui touchent votre pile. Ce travail vous protège pendant l'intervalle. La montée de version, elle, referme le sujet.

Le cœur a changé de socle : la 9 est passée à Symfony 6.4, la version au support long, et plusieurs composants internes ont été remplacés au passage. Les modules qui s'appuyaient dessus doivent donc être repris, tout comme les contrôleurs écrits sur mesure pour votre boutique. Cinq fonctions ont aussi disparu du cœur en 9.0, dont la gestion avancée des stocks et la livraison multi-adresses : une boutique qui les utilise a un arbitrage métier à rendre avant tout calendrier technique. Il y a enfin une conséquence côté serveur, puisque reconstruire les fichiers du front demande Node 20 : l'environnement n'est plus seulement du PHP. Nous montons la 9 sur une préproduction, votre équipe ou votre agence y rejoue le catalogue et le tunnel de commande, et c'est vous qui fixez la date de bascule.

C'est la question à poser à tout hébergeur qui vous vend du cache, et la règle ne souffre pas d'exception. Le panier, la connexion client et les pages de commande ne sont jamais mis en cache, parce que leur contenu appartient à un seul visiteur. Nous les excluons du cache dès la mise en service. Quand une page de catalogue doit afficher un bloc à jour, votre panier en haut à droite par exemple, ce bloc est assemblé à part au moment de servir la page, et le reste continue de partir du cache. C'est cette séparation qui permet de mettre un catalogue entier en cache sans jamais toucher à une commande.

Une sauvegarde ne vaut que ce que vaut sa restauration. Deux serveurs de sauvegarde, installés dans deux pays européens et chez des fournisseurs autres que celui de votre production, gardent en permanence au moins neuf points de restauration : un par jour sur sept jours glissants, plus deux bimensuels, le 1er et le 16. À partir de nos offres d'infogérance avancées, nous rejouons chaque année une restauration complète, avec vous, à la date que vous choisissez. Vous assistez au retour de la boutique, et vous en connaissez le délai réel. Côté délais, quand un incident rend la boutique inaccessible, nous intervenons sous 30 minutes en heures ouvrées, du lundi au samedi, et sous 6 heures le reste du temps. La nuit et le week-end, une urgence déclenche une alerte SMS et l'intervention commence. La ligne d'appel 24/7, celle qui vous permet de nous joindre vous-même à trois heures du matin, se souscrit en option.