Une boutique publiée en janvier 2020 relève de la génération PrestaShop 1.7, celle qui a rompu avec le thème historique et imposé une refonte des surcharges à chaque montée de version. Cinq ans plus tard, la question n’est plus la mise en ligne mais la dette : un socle de cette époque accumule des modules dont l’éditeur a parfois disparu. Le dossier associe pour cette raison la maintenance et l’hébergement sur un même contrat, ce qui place le serveur et le code sous la même responsabilité plutôt que de les répartir entre deux prestataires qui se renvoient les incidents.
Maintenance et hébergement liés
Séparer les deux revient à arbitrer, à chaque lenteur, entre un défaut applicatif et une limite serveur — arbitrage qu’aucun des deux prestataires n’a intérêt à trancher. Les réunir supprime la discussion : la même équipe lit les journaux PHP et les métriques machine, et une requête lente se corrige là où elle naît.
Un catalogue de produits importés
Vendre des produits allemands premium suppose des fiches où la provenance, la composition et les équivalences de format comptent autant que le prix. Ce sont des attributs, pas du texte libre : déclarés comme tels, ils restent filtrables et réutilisables. Noyés dans une description, ils cessent d’être exploitables dès que le catalogue grandit.
Une trajectoire de version tenue
Un socle de 2020 n’est pas figé : PrestaShop a publié depuis plusieurs versions majeures. Le suivi consiste à garder les surcharges documentées et les modules dans des versions encore soutenues, pour que la montée reste un chantier planifiable et non une réécriture forcée par un incident.
Ce dossier documente un site e-commerce PrestaShop publié en janvier 2020, accompagné en maintenance et en hébergement. Il ne publie ni volume de commandes, ni chiffre d’affaires, ni taux de conversion : ces données n’ont pas été fournies par le client et n’auraient aucune valeur de preuve sans son accord. Les explications ci-dessus portent sur ce que les fonctions documentées impliquent techniquement.