- Bienvenue sur MassiveHoster Forum.
Libérez votre créativité
Messages récents
#1
Discussions générales / MassiveHoster, Avantages et In...
Dernier message par MassiveHoster - Fév 11, 2026, 06:48 PMDepuis mi-2025, de nombreux utilisateurs rejoignent MassiveHoster après avoir vécu une expérience mitigée chez certains autres hébergeurs très connus qui font l'objet de baisse de qualité ou de hausses tarifaires.
Bien sûr, avant de choisir MassiveHoster, une question légitime se pose pour être sûr de faire le bon choix de fournisseur...
"Quels sont les avantages concrets de MassiveHoster, mais aussi ses inconvénients ?"
Chez MassiveHoster, nous prônons la transparence totale !
Plutôt que de « vendre du rêve » , nous préférons exposer clairement nos points forts, notre philosophie technique, mais aussi nos "spécificités" ou pour certains, nos "inconvénients".
Voici tout ce que vous devez savoir sur notre offre d'hébergement avant de passer commande...
Résumé des Avantages de MassiveHoster
1. Une infrastructure de pointe (matériel de 2026)
Contrairement à d'autres fournisseurs, nous ne cherchons pas à appâter les nouveaux clients avec des promesses de ressources irréalistes, mais nous travaillons à maintenir et améliorer constamment les performances ainsi que la stabilité de nos solutions pour convenir à la majorité des besoins attendus d'un service d'hébergement mutualisé.
Début-2026, MassiveHoster a fait un grand pas en avant en déployant une toute nouvelle infrastructure très haute performance (matériel récent de pointe, RAM DDR5, etc), assurant une réactivité optimale pour les sites de ses utilisateurs.
2. Performances et Technologies
Tout en cherchant à maintenir des tarifs attractifs, MassiveHoster fait tout pour sélectionner les meilleures technologies du marché.
Notre interface de gestion moderne est équivalente à des solutions comme cPanel, pour ses fonctionnalités et son ergonomie. Elle vous permet de réaliser des tâches complexes et de gérer vos sites avec une grande simplicité. Voici un aperçu de la version "English", mais notre interface est aussi traduite intégralement en "Français"...
En effet, pour pouvoir maintenir des tarifs prédictibles, nous avons choisi de ne pas utiliser le célèbre cPanel (considéré comme le leader, mais devenu impayable), car depuis leur rachat par un grand groupe en 2019, ils pratiquent des hausses tarifaires annuelles injustifiées, tous les ans au 1er janvier, ce qui n'est pas aligné aux valeurs de MassiveHoster qui cherche à proposer des tarifs accessibles.
Dans votre interface d'hébergement MassiveHoster sont inclus de nombreux outils premium tels que, entre autres :
Grâce au système CloudLinux OS Pro, chaque compte utilisateur est cloisonné en termes de ressources (CPU/RAM...).
De plus, en complément de nombreuses dispositions sécuritaires, vos sites sont sécurisés par Imunify360 qui est, selon nous, la meilleure Suite de Sécurité pour l'hébergement de sites Web incluant entre autres :
- un anti-malware automatique live
- un firewall intelligent
- la correction automatique des failles de sécurité PHP / Kernel
- etc.
Grâce à une infrastructure connectée via le plus vaste réseau d'Europe, nos utilisateurs bénéficient de la meilleure protection anti-DDoS du marché européen, et ce, car notre DC s'appuie sur de larges capacités de bande passante excédentaire.
Enfin, la sécurité de vos données figure parmi nos priorités absolues...
Contrairement à d'autres hébergeurs qui réalisent leurs sauvegardes dans une salle de serveurs située à proximité des serveurs de production (donc, exposées au même risque d'incendie par exemple), MassiveHoster sauvegarde vos données dans plusieurs datacenters géographiquement distants.
En cas d'incident majeur comme un sinistre affectant le datacenter principal, cela nous permettrait d'assurer la restauration intégrale de vos services, sans perte majeure.
5. Pour les Agences et Réseaux de sites : grande flexibilité
En souscrivant à un plan Premium chez MassiveHoster, vous disposez d'un compte principal (mini-revendeur) et de la possibilité de créer 8 sous-comptes cloisonnés pouvant chacun avoir des accès / mots de passe distincts.
Pour chaque sous-compte, il est possible de choisir une adresse IP différente. Il s'agit d'adresses IP Failover authentiques liées directement à votre machine, sans système de proxy instable. Un atout majeur pour la confidentialité entre les sites, pour vos clients et pour le référencement SEO, sans sacrifier la stabilité de vos sites hébergés.
6. Un Support Technique Expérimenté et Disponible 7j/7
Notre équipe est disponible tous les jours par tickets et via notre forum de discussion.
Lorsque cela est nécessaire, nous dépassons volontiers notre rôle de simple hébergeur Web, dans la limite du raisonnable bien sûr
Il est fréquent que nous jouions un rôle de "conseiller" et que nous assistions les utilisateurs bien au-delà du périmètre classique d'un hébergeur, par exemple en répondant à toutes les questions et en donnant des conseils pour les problématiques de...
- dépannage d'erreurs (WordPress, PHP, etc)
- nettoyage et sécurisation de sites WordPress
- optimisation des performances, etc.
Transparence sur nos spécificités ("Inconvénients")
1. L'interface de gestion
L'interface d'hébergement fournie étant différente de cPanel, un court temps d'adaptation peut être nécessaire aux utilisateurs qui étaient attachés à cPanel. Néanmoins, notre interface est complète en termes de fonctionnalités et notre support reste disponible 7j/7 pour toute question et pour tout accompagnement.
D'après notre expérience, ~99% de nos clients venant de cPanel s'habituent pleinement à leur nouvelle interface MassiveHoster dans la première journée d'utilisation.
2. La politique des Inodes (fichiers et dossiers)
Pour garantir la stabilité et les performances de tous nos hébergés, nous demandons à nos utilisateurs de ne pas dépasser un certain seuil d'utilisation d'inodes (détails sur notre Page Tarifs).
Cette politique concernant les inodes nous permet d'éviter les abus subis par de nombreux hébergeurs "illimités" concurrents qui finissent souvent, à terme, par souffrir de dysfonctionnements, de ralentissements et d'instabilités en tout genre.
De même, cette mesure de contrôle des inodes nous permet de conserver des tarifs stables, sans augmentations régulières du prix de renouvellement comme cela se voit chez d'autres fournisseurs d'hébergement.
Finalement, notre politique concernant le inodes n'est pas vraiment un inconvénient, mais plutôt une mesure raisonnable et un gage de qualité pour nos clients sur le long terme.
3. Usage du stockage
Nos solutions étant avant tout optimisées pour les performances d'hébergement de sites Web, elles ne sont pas destinées au stockage de masse, par exemple :
- archivage de fichiers volumineux comme des photos au format RAW
- hébergement d'intranet ou cloud personnel
- streaming de vidéos volumineuses
- stockage de sauvegardes de tout type, etc.
Cette mesure nous permet de préserver les performances de disques, et donc au final, la stabilité de votre hébergement de site Web, ainsi que maintenir des services de backup fiables.
Migration et Prochaines étapes
Intéressé par MassiveHoster ?
Si vous le souhaitez, n'hésitez pas à ouvrir un ticket de support pour nous communiquer les détails concernant vos sites existants et/ou un accès temporaire (ou capture d'écran) de votre précédent panel d'hébergement...
Notre équipe pourra vous aider à calculer la consommation d'inodes de vos sites ; ou faire le calcul pour vous sans intervention de votre part.
Ensuite, en souscrivant à un plan Premium, notre équipe pourra prendre en charge gratuitement la migration de l'ensemble des sites et comptes mails hébergés sur un plan concurrent.
Vous pouvez réclamer votre prestation de migration offerte jusqu'à 30 jours après commande
Pour vous faire un avis sur nos services sans prise de risque, n'hésitez pas à profiter de notre garantie Satisfait ou Remboursé de 14 jours (offerte hors travaux de migration). Ce délai de 14 jours vous laisse le temps de découvrir votre nouvelle interface de gestion d'hébergement, ainsi qu'effectuer quelques tests de performance avant de prendre la décision de migrer vos sites les plus critiques vers votre nouvel hébergement MassiveHoster !
Pour en savoir plus sur MassiveHoster...
🎥 Découvrez notre présentation vidéo détaillée pour tout savoir en moins de 5 minutes :
Voir la vidéo sur YouTube
🌟 Consultez les avis certifiés de nos clients :
Voir les avis sur Trustpilot
Merci pour votre lecture.
Notre équipe reste à votre entière disposition sur ce forum ou via ticket pour toute autre question ou remarque, n'hésitez pas !
Bien sûr, avant de choisir MassiveHoster, une question légitime se pose pour être sûr de faire le bon choix de fournisseur...
"Quels sont les avantages concrets de MassiveHoster, mais aussi ses inconvénients ?"
Chez MassiveHoster, nous prônons la transparence totale !
Plutôt que de « vendre du rêve » , nous préférons exposer clairement nos points forts, notre philosophie technique, mais aussi nos "spécificités" ou pour certains, nos "inconvénients".
Voici tout ce que vous devez savoir sur notre offre d'hébergement avant de passer commande...
Résumé des Avantages de MassiveHoster
1. Une infrastructure de pointe (matériel de 2026)
Contrairement à d'autres fournisseurs, nous ne cherchons pas à appâter les nouveaux clients avec des promesses de ressources irréalistes, mais nous travaillons à maintenir et améliorer constamment les performances ainsi que la stabilité de nos solutions pour convenir à la majorité des besoins attendus d'un service d'hébergement mutualisé.
Début-2026, MassiveHoster a fait un grand pas en avant en déployant une toute nouvelle infrastructure très haute performance (matériel récent de pointe, RAM DDR5, etc), assurant une réactivité optimale pour les sites de ses utilisateurs.
2. Performances et Technologies
Tout en cherchant à maintenir des tarifs attractifs, MassiveHoster fait tout pour sélectionner les meilleures technologies du marché.
- Stockage 100% NVMe :
MassiveHoster vous propose du stockage NVMe, y compris pour les fichiers PHP et Assets, pas uniquement pour stocker les bases MySQL.
Cette technologie est très coûteuse, mais beaucoup plus performante que le SSD classique.
De plus, nous n'utilisons que des serveurs physiques haute performance, sans virtualisation, sans intermédiaire logiciel et donc, avec accès direct aux performances des machines pour un maximum de réactivité et de stabilité !
En effet, le fait est qu'actuellement, la virtualisation ne peut pas encore égaler les performances du matériel brute.. sinon, plus aucun hébergeur ne proposerait de serveurs dédiés physiques / Bare Metal dans leur catalogue - Technologie RAMfs :
Grâce à différents mécanismes RAMfs, nous mettons automatiquement vos fichiers en cache directement dans la mémoire vive, assurant une vitesse d'exécution quasi-instantanée pour les fichiers régulièrement consultés. - Cache Avancé :
Pour vos sites WordPress, nous vous offrons AccelerateWP (plugin de cache premium fork basé sur WP Rocket) ainsi que Redis Object Cache. N'hésitez pas à solliciter notre support technique qui se fera un plaisir de vous assister pour leur mise en place !
Notre interface de gestion moderne est équivalente à des solutions comme cPanel, pour ses fonctionnalités et son ergonomie. Elle vous permet de réaliser des tâches complexes et de gérer vos sites avec une grande simplicité. Voici un aperçu de la version "English", mais notre interface est aussi traduite intégralement en "Français"...
En effet, pour pouvoir maintenir des tarifs prédictibles, nous avons choisi de ne pas utiliser le célèbre cPanel (considéré comme le leader, mais devenu impayable), car depuis leur rachat par un grand groupe en 2019, ils pratiquent des hausses tarifaires annuelles injustifiées, tous les ans au 1er janvier, ce qui n'est pas aligné aux valeurs de MassiveHoster qui cherche à proposer des tarifs accessibles.
Dans votre interface d'hébergement MassiveHoster sont inclus de nombreux outils premium tels que, entre autres :
- Softaculous :
pour l'installation en 1 clic et la gestion de vos CMS comme WordPress. - JetBackup5 :
pour consulter et restaurer en toute autonomie l'une des sauvegardes régulières réalisée par nos serveurs de backup. - PHP X-Ray :
pour diagnostiquer précisément les scripts ou plugins qui ralentissent vos sites.
Grâce au système CloudLinux OS Pro, chaque compte utilisateur est cloisonné en termes de ressources (CPU/RAM...).
De plus, en complément de nombreuses dispositions sécuritaires, vos sites sont sécurisés par Imunify360 qui est, selon nous, la meilleure Suite de Sécurité pour l'hébergement de sites Web incluant entre autres :
- un anti-malware automatique live
- un firewall intelligent
- la correction automatique des failles de sécurité PHP / Kernel
- etc.
Grâce à une infrastructure connectée via le plus vaste réseau d'Europe, nos utilisateurs bénéficient de la meilleure protection anti-DDoS du marché européen, et ce, car notre DC s'appuie sur de larges capacités de bande passante excédentaire.
Enfin, la sécurité de vos données figure parmi nos priorités absolues...
Contrairement à d'autres hébergeurs qui réalisent leurs sauvegardes dans une salle de serveurs située à proximité des serveurs de production (donc, exposées au même risque d'incendie par exemple), MassiveHoster sauvegarde vos données dans plusieurs datacenters géographiquement distants.
En cas d'incident majeur comme un sinistre affectant le datacenter principal, cela nous permettrait d'assurer la restauration intégrale de vos services, sans perte majeure.
5. Pour les Agences et Réseaux de sites : grande flexibilité
En souscrivant à un plan Premium chez MassiveHoster, vous disposez d'un compte principal (mini-revendeur) et de la possibilité de créer 8 sous-comptes cloisonnés pouvant chacun avoir des accès / mots de passe distincts.
Pour chaque sous-compte, il est possible de choisir une adresse IP différente. Il s'agit d'adresses IP Failover authentiques liées directement à votre machine, sans système de proxy instable. Un atout majeur pour la confidentialité entre les sites, pour vos clients et pour le référencement SEO, sans sacrifier la stabilité de vos sites hébergés.
6. Un Support Technique Expérimenté et Disponible 7j/7
Notre équipe est disponible tous les jours par tickets et via notre forum de discussion.
Lorsque cela est nécessaire, nous dépassons volontiers notre rôle de simple hébergeur Web, dans la limite du raisonnable bien sûr
Il est fréquent que nous jouions un rôle de "conseiller" et que nous assistions les utilisateurs bien au-delà du périmètre classique d'un hébergeur, par exemple en répondant à toutes les questions et en donnant des conseils pour les problématiques de...
- dépannage d'erreurs (WordPress, PHP, etc)
- nettoyage et sécurisation de sites WordPress
- optimisation des performances, etc.
Transparence sur nos spécificités ("Inconvénients")
1. L'interface de gestion
L'interface d'hébergement fournie étant différente de cPanel, un court temps d'adaptation peut être nécessaire aux utilisateurs qui étaient attachés à cPanel. Néanmoins, notre interface est complète en termes de fonctionnalités et notre support reste disponible 7j/7 pour toute question et pour tout accompagnement.
D'après notre expérience, ~99% de nos clients venant de cPanel s'habituent pleinement à leur nouvelle interface MassiveHoster dans la première journée d'utilisation.
2. La politique des Inodes (fichiers et dossiers)
Pour garantir la stabilité et les performances de tous nos hébergés, nous demandons à nos utilisateurs de ne pas dépasser un certain seuil d'utilisation d'inodes (détails sur notre Page Tarifs).
Cette politique concernant les inodes nous permet d'éviter les abus subis par de nombreux hébergeurs "illimités" concurrents qui finissent souvent, à terme, par souffrir de dysfonctionnements, de ralentissements et d'instabilités en tout genre.
De même, cette mesure de contrôle des inodes nous permet de conserver des tarifs stables, sans augmentations régulières du prix de renouvellement comme cela se voit chez d'autres fournisseurs d'hébergement.
Finalement, notre politique concernant le inodes n'est pas vraiment un inconvénient, mais plutôt une mesure raisonnable et un gage de qualité pour nos clients sur le long terme.
3. Usage du stockage
Nos solutions étant avant tout optimisées pour les performances d'hébergement de sites Web, elles ne sont pas destinées au stockage de masse, par exemple :
- archivage de fichiers volumineux comme des photos au format RAW
- hébergement d'intranet ou cloud personnel
- streaming de vidéos volumineuses
- stockage de sauvegardes de tout type, etc.
Cette mesure nous permet de préserver les performances de disques, et donc au final, la stabilité de votre hébergement de site Web, ainsi que maintenir des services de backup fiables.
Migration et Prochaines étapes
Intéressé par MassiveHoster ?
Si vous le souhaitez, n'hésitez pas à ouvrir un ticket de support pour nous communiquer les détails concernant vos sites existants et/ou un accès temporaire (ou capture d'écran) de votre précédent panel d'hébergement...
Notre équipe pourra vous aider à calculer la consommation d'inodes de vos sites ; ou faire le calcul pour vous sans intervention de votre part.
Ensuite, en souscrivant à un plan Premium, notre équipe pourra prendre en charge gratuitement la migration de l'ensemble des sites et comptes mails hébergés sur un plan concurrent.
Vous pouvez réclamer votre prestation de migration offerte jusqu'à 30 jours après commande
Pour vous faire un avis sur nos services sans prise de risque, n'hésitez pas à profiter de notre garantie Satisfait ou Remboursé de 14 jours (offerte hors travaux de migration). Ce délai de 14 jours vous laisse le temps de découvrir votre nouvelle interface de gestion d'hébergement, ainsi qu'effectuer quelques tests de performance avant de prendre la décision de migrer vos sites les plus critiques vers votre nouvel hébergement MassiveHoster !
Pour en savoir plus sur MassiveHoster...
🎥 Découvrez notre présentation vidéo détaillée pour tout savoir en moins de 5 minutes :
Voir la vidéo sur YouTube
🌟 Consultez les avis certifiés de nos clients :
Voir les avis sur Trustpilot
Merci pour votre lecture.
Notre équipe reste à votre entière disposition sur ce forum ou via ticket pour toute autre question ou remarque, n'hésitez pas !
#2
Discussions générales / Comment gérons-nous les plaint...
Dernier message par MassiveHoster - Déc 26, 2025, 11:00 AMChez MassiveHoster, nous cherchons à aider toutes les activités légales à entreprendre librement sur le Web.
Cependant, en tant qu'infogérant (intermédiaire technique), nous restons soumis à des contraintes pratiques et légales strictes imposées notamment par la loi et nos partenaires (datacenters, bureaux d'enregistrement de noms de domaine, etc).
Ce post a pour but de vous expliquer en toute transparence le parcours d'un signalement "Abuse" ou d'une plainte "Légale" ; pourquoi nous devons parfois agir rapidement et de façon stricte ; et surtout comment vous protéger EN AMONT pour éviter qu'un simple signalement ne se transforme en suspension de service ou pire, en clôture définitive de votre relation commerciale avec MassiveHoster.
1. Comprendre le rôle de chacun : Datacenter, MassiveHoster et Vous !
Il est crucial tout d'abord de comprendre la chaîne de responsabilité :
La nuance importante à garder à l'esprit :
aux yeux du Datacenter, VOUS n'êtes pas leur client. NOUS (MassiveHoster) le sommes. Si un site pose problème, le Datacenter ne va pas chercher à vous contacter. Il va nous menacer de couper le serveur entier (impactant des centaines d'autres clients) si nous ne résolvons pas le problème sous 24h à 48h maximum.
C'est cette contrainte qui nous oblige à agir rapidement et de manière stricte à tout signalement Abuse ou Légal.
2. Rappel de vos obligations en tant qu'hébergé : des Mentions Légales véridiques et vérifiables !
C'est la règle n°1 pour assurer le maintien en ligne de votre site Web en cas de signalement.
Pour qu'un plaignant (ou une autorité) puisse vous contacter directement sans passer par l'hébergeur, vous devez être joignable.
Vos sites doivent impérativement afficher une page "Mentions Légales" contenant des informations véridiques et vérifiables. C'est-à-dire, au moins celles-ci :
- Identité du Directeur de la Publication / Responsable légal de la publication :
Nom, Prénom (et Raison Sociale si société).
- Adresse Postale réelle :
Où le courrier est relevé (pas une fausse adresse ou boîte postale non surveillée).
- Adresse(s) Email de contact fonctionnelle(s) :
Plusieurs de préférence et relevées régulièrement.
- Hébergeur technique :
Mention de "MassiveHoster" comme "Hébergeur (intermédiaire technique pour l'infogérance)", avec lien vers notre page de contact "https://massivehoster.com/contact". Cela nous permet de réceptionner certains signalements avant la procédure d'Abuse ou Légale prévue par le datacenter ; ce qui nous permet de communiquer avec vous (notre client), afin de trouver rapidement des solutions sans impliquer le Datacenter.
⚠️ Attention aux "Personas", aux "Fausses informations" et aux "Mentions légales volontairement incomplètes" :
En plus d'être strictement puni par la loi et faisant l'objet de vérifications et sanctions graves (cf. en France, DGCCRF), si vous utilisez de fausses identités (par exemple pour le SEO) et qu'une plainte arrive, le plaignant constatera qu'il ne peut pas vous joindre. Il se retournera alors contre l'un des intermédiaires techniques (nous, MassiveHoster, ou le plus souvent, le Datacenter et le Registrar) en nous mettant en demeure d'agir.
Conséquence :
si le plaignant n'a pas été en mesure de vous identifier directement ou si vous ne répondez pas, nous pourrions être contraints d'au moins suspendre le site pour protéger notre infrastructure / les autres utilisateurs, et nous protéger légalement (nous, MassiveHoster et le Datacenter).
C'est pour ces raisons que nous devons également nous montrer stricts avec les éditeurs de sites que nous soupçonnons d'utiliser délibérément leurs hébergeurs (nous, MassiveHoster, ou notre fournisseur Datacenter) comme une sorte d'intermédiaire légal, pouvant faire office de tampon en cas de signalement Abuse ou plainte Légale.
⚠️ Si nous jugeons qu'une telle pratique est avérée, par exemple par la présence de Mentions Légales mettant en avant l'Hébergeur (nous MassiveHoster et/ou le Datacenter) SANS mettre en avant le Responsable éditorial légal / Directeur de publication (Vous), nous nous réservons le droit :
- si aucune procédure (Abuse ou Légale) n'est en cours, d'exiger une régularisation immédiate en complétant les Mentions légales de chaque site concerné
- et/ou si une procédure a déjà été engagée (Abuse et/ou Légale, impliquant ou non le Datacenter), de suspendre tout service et de clôturer définitivement toute relation commerciale entre Vous et MassiveHoster.
3. Bonne pratique DNS conseillée : proxy Cloudflare pour le Web et service tiers pour les e-mails...
Pour les éditeurs soucieux de gérer eux-mêmes en direct tous les éventuels signalements dont ils pourraient faire l'objet, sans risquer d'impliquer MassiveHoster ou le Datacenter qu'il emploie, et afin de protéger le serveur hébergeant leur site d'une suspension globale, cette configuration peut s'avérer utile :
A. Activez le Proxy Cloudflare (nuage orange)
En passant votre site derrière Cloudflare, vous masquez l'IP réelle du serveur d'hébergement.
Avantage :
il ne s'agit pas de vous cacher pour être anonyme. Néanmoins, dans cette configuration, les signalements automatiques (bots, copyright) sont d'abord envoyés à Cloudflare, en premier lieu avant escalade au Datacenter. Cloudflare agit comme premier intermédiaire technique au lieu du Datacenter employé par MassiveHoster, et il vous transmet la plainte en direct. Cela vous laisse généralement plus de temps pour réagir avant que la plainte ne soit remontée à notre Datacenter et donc, avant menace de couper tout le serveur (24 à 48h max). Cette méthode vous permet de gérer ces signalements de manière plus directe au premier abord, sans l'intermédiaire immédiat de MassiveHoster. De même, Cloudflare, en tant que votre fournisseur direct (contrairement à MassiveHoster qui reste un intermédiaire technique) pourrait se montrer plus souple que MassiveHoster à dossier égal. MassiveHoster est en effet soumis aux nombreuses contraintes détaillées précédemment, contrairement à Cloudflare qui est lui-même maître dans ses propres Datacenters.
B. Externalisez vos Emails (Serveurs MX)
C'est un point souvent oublié. Si vous utilisez Cloudflare Proxy pour le Web, mais que vos emails partent du serveur d'hébergement (MassiveHoster), l'adresse IP réelle peut être exposée via les champs DNS de type MX (plus d'infos via votre tableau de bord Cloudflare). Il convient donc soit d'utiliser une adresse email @alternative (par exemple, Gmail) ou d'utiliser un service de mails IMAP et SMTP tiers pour lequel vous êtes le client direct (Google Workspace, etc).
Conseil :
utilisez un service de messagerie tiers (Google Workspace, Gmail, Zoho, ProtonMail...).
Pourquoi ? En cas de plainte pour SPAM ou contenu litigieux, c'est le fournisseur de mail qui gère, sans mettre en péril votre site web hébergé chez nous.
4. Le Parcours d'un Signalement "Abuse" (que va-t-il se passer ?)
Voici ce qui se passe chronologiquement quand nous recevons une alerte :
Étape 1 : Réception de la plainte par le Datacenter
Le Datacenter reçoit un signalement (Phishing, Contrefaçon, Contenu illicite, Malware).
La réaction du Datacenter : ils nous transfèrent le signalement et nous donnent un délai (souvent un maximum de 24h) pour résoudre le problème, sous peine de désactiver l'IP du serveur.
⚠️ À ce stade et une fois que Nous et/ou le Datacenter sommes engagés, nous ne pouvons d'ores et déjà plus donner aucune garantie quant à l'issue positive ou négative de la procédure. C'est-à-dire, savoir si nous serons en mesure ou non de continuer, à l'avenir, à héberger le site ayant fait l'objet d'un signalement. C'est pourquoi il est si important de toujours être en ordre, EN AMONT, pour éviter que n'importe quel signalement ne remonte à l'Hébergeur (nous MassiveHoster et/ou le Datacenter).
Étape 2 : Notre intervention (médiation)
Nous analysons la demande.
- Si c'est de toute évidence avéré (phishing, malware) :
nous suspendons le site préventivement pour protéger l'infrastructure et nous vous notifions.
- Si c'est un litige de contenu (Droit d'auteur, Diffamation...) :
nous vous contactons immédiatement (Ticket avec notification par Email) en vous demandant de supprimer le contenu faisant l'objet de la plainte sous 12 heures maximum.
Dans tous les cas de figure, un signalement implique obligatoirement que notre équipe vérifie la présence de Mentions légales complètes et plausibles sur l'ensemble des sites de l'utilisateur concerné, en rappelant qu'il doit être joignable par au moins 2 canaux afin d'être en mesure de répondre lui-même aux plaintes concernant les sites pour lesquels il est le responsable légal.
Étape 3 : Votre réaction (décisive)
- Scénario A (réponse réactive) :
vous répondez rapidement, vous supprimez tout contenu litigieux. Nous transmettons l'info au Datacenter. Sans retour de leur part sous quelques jours, nous pouvons dans la plupart des cas considérer que le dossier est fermé.
- Scénario B (absence de retour) :
vous ne répondez pas et/ou vos mentions légales restent non conformes. Le délai du Datacenter expire. Nous sommes obligés de suspendre votre site pour éviter que le Datacenter ne coupe le serveur entier.
Étape 4 : l'escalade légale (critique)
Si un avocat ou un huissier nous met en demeure (nous, MassiveHoster et/ou le Datacenter), par exemple parce que vous étiez injoignable (fausses mentions légales ou informations de contact insuffisantes), nous devenons "partie prenante" et risquons (nous, MassiveHoster et/ou le Datacenter) d'être assignés en justice au tribunal pour une audience destinée à répondre aux accusations évoquées.
Comme vous pourrez le comprendre, c'est une situation que nous (MassiveHoster et le Datacenter) cherchons à éviter, en cas de signalement pouvant conduire à des complications légales :
- La loi (LCEN) nous oblige à agir promptement pour faire cesser le trouble.
- En tant qu'intermédiaire technique, nous sommes contraints de suspendre immédiatement le site (même sans décision de justice), notamment pour protéger nos fournisseurs (Datacenter, Registrar...).
- Nous pourrons être contraints de transmettre vos informations d'identification (Logs, IP, Paiement) aux autorités compétentes, au Datacenter/Registrar et/ou au plaignant sur ordonnance sur simple demande du Datacenter/Registrar ou toute demande d'une institution légale.
- Conséquences finales : suspension définitive du service pour le site / domaine concerné, et dans le pire des cas, rupture définitive de la relation commerciale entre (Vous) l'éditeur du site / responsable légal du litige, et (Nous) MassiveHoster / infogérant intermédiaire technique.
En résumé
MassiveHoster est votre partenaire technique, pas un juge ni un censeur. L'une de nos priorités est d'héberger vos sites et de les maintenir en ligne autant que possible. Mais notre priorité absolue reste la stabilité de notre infrastructure pour l'ensemble des utilisateurs.
Pour éviter tout litige ou suspension de service...
- Soyez prudent :
évitez tout contenu potentiellement problématique (les lois s'étendent aussi à Internet).
- Soyez identifiable :
la publication d'un site Internet de manière 100% anonyme est interdite et la loi oblige tout éditeur à s'identifier au travers de ses mentions légales.
- Soyez joignable :
publiez de vraies Mentions Légales complètes avec au moins deux canaux de contact infaillibles.
- Soyez l'utilisateur direct du Datacenter :
utilisez Cloudflare (Proxy Web) + Emails externes (MX) pour être directement l'utilisateur lié au Datacenter diffusant votre site (sans intermédiaire technique comme MassiveHoster l'est en tant qu'infogérant).
- Soyez réactif :
surveillez vos emails, vos courriers postaux, vos tickets support... (si possible, quotidiennement).
Nous restons à votre entière disposition pour tout complément, par ticket support ou ci-dessous sur le forum.
Merci pour votre collaboration.
L'équipe MassiveHoster.
Cependant, en tant qu'infogérant (intermédiaire technique), nous restons soumis à des contraintes pratiques et légales strictes imposées notamment par la loi et nos partenaires (datacenters, bureaux d'enregistrement de noms de domaine, etc).
Ce post a pour but de vous expliquer en toute transparence le parcours d'un signalement "Abuse" ou d'une plainte "Légale" ; pourquoi nous devons parfois agir rapidement et de façon stricte ; et surtout comment vous protéger EN AMONT pour éviter qu'un simple signalement ne se transforme en suspension de service ou pire, en clôture définitive de votre relation commerciale avec MassiveHoster.
1. Comprendre le rôle de chacun : Datacenter, MassiveHoster et Vous !
Il est crucial tout d'abord de comprendre la chaîne de responsabilité :
- Le Datacenter :
il loue les serveurs physiques et le réseau. Il a une politique stricte concernant les signalements "abuse", afin de protéger ses ranges d'adresses IP, et encore plus stricte concernant les demandes légales (courriers d'avocat) afin de se protéger d'actions judiciaires.
En complément, le bureau central d'enregistrement des noms de domaine (Registrar), peut aussi être impliqué dans un signalement Abuse ou plainte Légale, tout comme le Datacenter. - MassiveHoster (hébergeur infogérant) :
nous sommes l'intermédiaire technique. Nous louons des serveurs au Datacenter et réservons des noms de domaine au Registrar pour vous offrir un service clé en main. Nous ne sommes pas le propriétaire du Datacenter ni le Registrar agréé qui sont les organismes qui ne devraient être saisis par tout plaignant qu'en dernière instance. - Vous (l'éditeur du site) :
vous êtes le responsable légal et éditorial de votre site et du contenu qui y est publié. Ni nous (MassiveHoster), ni le Datacenter ni le Registrar ne sommes au courant du contenu qui est publié sur votre site et nom de domaine. Contenu dont vous seul êtes responsable.
La nuance importante à garder à l'esprit :
aux yeux du Datacenter, VOUS n'êtes pas leur client. NOUS (MassiveHoster) le sommes. Si un site pose problème, le Datacenter ne va pas chercher à vous contacter. Il va nous menacer de couper le serveur entier (impactant des centaines d'autres clients) si nous ne résolvons pas le problème sous 24h à 48h maximum.
C'est cette contrainte qui nous oblige à agir rapidement et de manière stricte à tout signalement Abuse ou Légal.
2. Rappel de vos obligations en tant qu'hébergé : des Mentions Légales véridiques et vérifiables !
C'est la règle n°1 pour assurer le maintien en ligne de votre site Web en cas de signalement.
Pour qu'un plaignant (ou une autorité) puisse vous contacter directement sans passer par l'hébergeur, vous devez être joignable.
Vos sites doivent impérativement afficher une page "Mentions Légales" contenant des informations véridiques et vérifiables. C'est-à-dire, au moins celles-ci :
- Identité du Directeur de la Publication / Responsable légal de la publication :
Nom, Prénom (et Raison Sociale si société).
- Adresse Postale réelle :
Où le courrier est relevé (pas une fausse adresse ou boîte postale non surveillée).
- Adresse(s) Email de contact fonctionnelle(s) :
Plusieurs de préférence et relevées régulièrement.
- Hébergeur technique :
Mention de "MassiveHoster" comme "Hébergeur (intermédiaire technique pour l'infogérance)", avec lien vers notre page de contact "https://massivehoster.com/contact". Cela nous permet de réceptionner certains signalements avant la procédure d'Abuse ou Légale prévue par le datacenter ; ce qui nous permet de communiquer avec vous (notre client), afin de trouver rapidement des solutions sans impliquer le Datacenter.
⚠️ Attention aux "Personas", aux "Fausses informations" et aux "Mentions légales volontairement incomplètes" :
En plus d'être strictement puni par la loi et faisant l'objet de vérifications et sanctions graves (cf. en France, DGCCRF), si vous utilisez de fausses identités (par exemple pour le SEO) et qu'une plainte arrive, le plaignant constatera qu'il ne peut pas vous joindre. Il se retournera alors contre l'un des intermédiaires techniques (nous, MassiveHoster, ou le plus souvent, le Datacenter et le Registrar) en nous mettant en demeure d'agir.
Conséquence :
si le plaignant n'a pas été en mesure de vous identifier directement ou si vous ne répondez pas, nous pourrions être contraints d'au moins suspendre le site pour protéger notre infrastructure / les autres utilisateurs, et nous protéger légalement (nous, MassiveHoster et le Datacenter).
C'est pour ces raisons que nous devons également nous montrer stricts avec les éditeurs de sites que nous soupçonnons d'utiliser délibérément leurs hébergeurs (nous, MassiveHoster, ou notre fournisseur Datacenter) comme une sorte d'intermédiaire légal, pouvant faire office de tampon en cas de signalement Abuse ou plainte Légale.
Pratique strictement interdite sur nos services, comme indiqué dans nos Conditions générales d'utilisation (cf. 8. Client Obligations and Responsibilities > Legal Notice).
⚠️ Si nous jugeons qu'une telle pratique est avérée, par exemple par la présence de Mentions Légales mettant en avant l'Hébergeur (nous MassiveHoster et/ou le Datacenter) SANS mettre en avant le Responsable éditorial légal / Directeur de publication (Vous), nous nous réservons le droit :
- si aucune procédure (Abuse ou Légale) n'est en cours, d'exiger une régularisation immédiate en complétant les Mentions légales de chaque site concerné
- et/ou si une procédure a déjà été engagée (Abuse et/ou Légale, impliquant ou non le Datacenter), de suspendre tout service et de clôturer définitivement toute relation commerciale entre Vous et MassiveHoster.
3. Bonne pratique DNS conseillée : proxy Cloudflare pour le Web et service tiers pour les e-mails...
Pour les éditeurs soucieux de gérer eux-mêmes en direct tous les éventuels signalements dont ils pourraient faire l'objet, sans risquer d'impliquer MassiveHoster ou le Datacenter qu'il emploie, et afin de protéger le serveur hébergeant leur site d'une suspension globale, cette configuration peut s'avérer utile :
A. Activez le Proxy Cloudflare (nuage orange)
En passant votre site derrière Cloudflare, vous masquez l'IP réelle du serveur d'hébergement.
Avantage :
il ne s'agit pas de vous cacher pour être anonyme. Néanmoins, dans cette configuration, les signalements automatiques (bots, copyright) sont d'abord envoyés à Cloudflare, en premier lieu avant escalade au Datacenter. Cloudflare agit comme premier intermédiaire technique au lieu du Datacenter employé par MassiveHoster, et il vous transmet la plainte en direct. Cela vous laisse généralement plus de temps pour réagir avant que la plainte ne soit remontée à notre Datacenter et donc, avant menace de couper tout le serveur (24 à 48h max). Cette méthode vous permet de gérer ces signalements de manière plus directe au premier abord, sans l'intermédiaire immédiat de MassiveHoster. De même, Cloudflare, en tant que votre fournisseur direct (contrairement à MassiveHoster qui reste un intermédiaire technique) pourrait se montrer plus souple que MassiveHoster à dossier égal. MassiveHoster est en effet soumis aux nombreuses contraintes détaillées précédemment, contrairement à Cloudflare qui est lui-même maître dans ses propres Datacenters.
B. Externalisez vos Emails (Serveurs MX)
C'est un point souvent oublié. Si vous utilisez Cloudflare Proxy pour le Web, mais que vos emails partent du serveur d'hébergement (MassiveHoster), l'adresse IP réelle peut être exposée via les champs DNS de type MX (plus d'infos via votre tableau de bord Cloudflare). Il convient donc soit d'utiliser une adresse email @alternative (par exemple, Gmail) ou d'utiliser un service de mails IMAP et SMTP tiers pour lequel vous êtes le client direct (Google Workspace, etc).
Conseil :
utilisez un service de messagerie tiers (Google Workspace, Gmail, Zoho, ProtonMail...).
Pourquoi ? En cas de plainte pour SPAM ou contenu litigieux, c'est le fournisseur de mail qui gère, sans mettre en péril votre site web hébergé chez nous.
4. Le Parcours d'un Signalement "Abuse" (que va-t-il se passer ?)
Voici ce qui se passe chronologiquement quand nous recevons une alerte :
Étape 1 : Réception de la plainte par le Datacenter
Le Datacenter reçoit un signalement (Phishing, Contrefaçon, Contenu illicite, Malware).
La réaction du Datacenter : ils nous transfèrent le signalement et nous donnent un délai (souvent un maximum de 24h) pour résoudre le problème, sous peine de désactiver l'IP du serveur.
⚠️ À ce stade et une fois que Nous et/ou le Datacenter sommes engagés, nous ne pouvons d'ores et déjà plus donner aucune garantie quant à l'issue positive ou négative de la procédure. C'est-à-dire, savoir si nous serons en mesure ou non de continuer, à l'avenir, à héberger le site ayant fait l'objet d'un signalement. C'est pourquoi il est si important de toujours être en ordre, EN AMONT, pour éviter que n'importe quel signalement ne remonte à l'Hébergeur (nous MassiveHoster et/ou le Datacenter).
Étape 2 : Notre intervention (médiation)
Nous analysons la demande.
- Si c'est de toute évidence avéré (phishing, malware) :
nous suspendons le site préventivement pour protéger l'infrastructure et nous vous notifions.
- Si c'est un litige de contenu (Droit d'auteur, Diffamation...) :
nous vous contactons immédiatement (Ticket avec notification par Email) en vous demandant de supprimer le contenu faisant l'objet de la plainte sous 12 heures maximum.
Dans tous les cas de figure, un signalement implique obligatoirement que notre équipe vérifie la présence de Mentions légales complètes et plausibles sur l'ensemble des sites de l'utilisateur concerné, en rappelant qu'il doit être joignable par au moins 2 canaux afin d'être en mesure de répondre lui-même aux plaintes concernant les sites pour lesquels il est le responsable légal.
Étape 3 : Votre réaction (décisive)
- Scénario A (réponse réactive) :
vous répondez rapidement, vous supprimez tout contenu litigieux. Nous transmettons l'info au Datacenter. Sans retour de leur part sous quelques jours, nous pouvons dans la plupart des cas considérer que le dossier est fermé.
- Scénario B (absence de retour) :
vous ne répondez pas et/ou vos mentions légales restent non conformes. Le délai du Datacenter expire. Nous sommes obligés de suspendre votre site pour éviter que le Datacenter ne coupe le serveur entier.
Étape 4 : l'escalade légale (critique)
Si un avocat ou un huissier nous met en demeure (nous, MassiveHoster et/ou le Datacenter), par exemple parce que vous étiez injoignable (fausses mentions légales ou informations de contact insuffisantes), nous devenons "partie prenante" et risquons (nous, MassiveHoster et/ou le Datacenter) d'être assignés en justice au tribunal pour une audience destinée à répondre aux accusations évoquées.
Comme vous pourrez le comprendre, c'est une situation que nous (MassiveHoster et le Datacenter) cherchons à éviter, en cas de signalement pouvant conduire à des complications légales :
- La loi (LCEN) nous oblige à agir promptement pour faire cesser le trouble.
- En tant qu'intermédiaire technique, nous sommes contraints de suspendre immédiatement le site (même sans décision de justice), notamment pour protéger nos fournisseurs (Datacenter, Registrar...).
- Nous pourrons être contraints de transmettre vos informations d'identification (Logs, IP, Paiement) aux autorités compétentes, au Datacenter/Registrar et/ou au plaignant sur ordonnance sur simple demande du Datacenter/Registrar ou toute demande d'une institution légale.
- Conséquences finales : suspension définitive du service pour le site / domaine concerné, et dans le pire des cas, rupture définitive de la relation commerciale entre (Vous) l'éditeur du site / responsable légal du litige, et (Nous) MassiveHoster / infogérant intermédiaire technique.
En résumé
MassiveHoster est votre partenaire technique, pas un juge ni un censeur. L'une de nos priorités est d'héberger vos sites et de les maintenir en ligne autant que possible. Mais notre priorité absolue reste la stabilité de notre infrastructure pour l'ensemble des utilisateurs.
Pour éviter tout litige ou suspension de service...
- Soyez prudent :
évitez tout contenu potentiellement problématique (les lois s'étendent aussi à Internet).
- Soyez identifiable :
la publication d'un site Internet de manière 100% anonyme est interdite et la loi oblige tout éditeur à s'identifier au travers de ses mentions légales.
- Soyez joignable :
publiez de vraies Mentions Légales complètes avec au moins deux canaux de contact infaillibles.
- Soyez l'utilisateur direct du Datacenter :
utilisez Cloudflare (Proxy Web) + Emails externes (MX) pour être directement l'utilisateur lié au Datacenter diffusant votre site (sans intermédiaire technique comme MassiveHoster l'est en tant qu'infogérant).
- Soyez réactif :
surveillez vos emails, vos courriers postaux, vos tickets support... (si possible, quotidiennement).
Nous restons à votre entière disposition pour tout complément, par ticket support ou ci-dessous sur le forum.
Merci pour votre collaboration.
L'équipe MassiveHoster.
#3
Annonces officielles / Effectif réduit du 17 décembre...
Dernier message par MassiveHoster - Déc 02, 2025, 03:00 PMC'est avec 15 jours d'avance que nous tenions à vous informer que l'équipe sera en effectif réduit du 17 décembre au 2 janvier, histoire de souffler un peu et vous revenir plus fort en 2026.
Ce break partiel pourrait affecter le délai de réponse aux tickets...
De même, pendant cette période, nous ne pourrons pas assurer toutes les prestations « out of the scope » que nous avons l'habitude d'offrir à nos utilisateurs.
Cela inclut par exemple,
- des interventions d'amélioration des webperfs,
- les prestations offertes pour la migration de sites,
- le débogage de plugins, etc.
L'équipe reste néanmoins d'astreinte pour la surveillance serveurs et tous les besoins critiques.
Nous encourageons donc nos utilisateurs qui auraient besoin de migrations ou d'autres interventions à contacter le support sans délai afin de planifier cela au plus vite !
Merci pour votre compréhension, collaboration et tous vos soutiens de 2025.
Nous vous souhaitons d'excellentes fêtes de fin d'année, reposantes, avec plein de bonnes résolutions pour 2026 ✨
Ce break partiel pourrait affecter le délai de réponse aux tickets...
De même, pendant cette période, nous ne pourrons pas assurer toutes les prestations « out of the scope » que nous avons l'habitude d'offrir à nos utilisateurs.
Cela inclut par exemple,
- des interventions d'amélioration des webperfs,
- les prestations offertes pour la migration de sites,
- le débogage de plugins, etc.
L'équipe reste néanmoins d'astreinte pour la surveillance serveurs et tous les besoins critiques.
Nous encourageons donc nos utilisateurs qui auraient besoin de migrations ou d'autres interventions à contacter le support sans délai afin de planifier cela au plus vite !
Merci pour votre compréhension, collaboration et tous vos soutiens de 2025.
Nous vous souhaitons d'excellentes fêtes de fin d'année, reposantes, avec plein de bonnes résolutions pour 2026 ✨
#4
MassiveHoster Academy / Erreur 500 : Fatal error Out o...
Dernier message par MassiveHoster - Nov 03, 2025, 10:05 AMLes messages d'erreur du type "Fatal error: Out of memory" signifient que WordPress tente d'utiliser plus de mémoire RAM que ce qui lui est actuellement accordé par le serveur et/ou votre configuration de WordPress.
Ce type d'erreur est plus courant avec les sites WordPress qui utilisent des plugins ou des constructeurs de pages (Page Builder) particulièrement consommateurs en mémoire, comme Elementor.
Pour résoudre ce problème, nous allons vous guider sur la façon d'augmenter cette limite de mémoire, côté serveur (PHP) et côté WordPress.
Il y a deux étapes principales à suivre :
1. Augmenter la Memory Limit dans "Select a PHP version" dans votre compte d'hébergement
Une fois dans l'onglet « Sélectionner une version de PHP » depuis votre interface d'hébergement, cliquez sur "Options".
Recherchez l'option memory_limit. Si ce n'est pas déjà fait, changez la valeur actuelle au maximum de 1024M.
2. Augmenter la Memory Limit dans wp-config.php
Même si vous augmentez la limite via votre compte d'hébergement, WordPress a ses propres constantes de mémoire WP_MEMORY_LIMIT qu'il va essayer de respecter, ce qui reste un plafond supplémentaire posant problème si votre site WordPress est très consommateur de mémoire.
Il est donc recommandé de les définir à une valeur élevée également côté CMS.
Pour cela, connectez-vous à votre site via FTP ou le Gestionnaire de fichiers (File Manager) de votre compte d'hébergement.
Localisez le fichier wp-config.php à la racine de votre installation WordPress.
Ouvrez ce fichier et ajoutez les lignes suivantes juste avant la ligne
/* That's all, stop editing! Happy publishing. */ :
Les valeurs de WP_MEMORY_LIMIT doivent toujours être inférieures aux valeurs de PHP Memory_Limit pour éviter tout dépassement qui engendreraient des erreurs 500.
Donc puisque la valeur maximale de PHP Memory_Limit est de 1024M, la valeur optimale maximale de WP_MEMORY_LIMIT est 768M.
Une fois cette optimisation réalisée, vous ne devriez plus rencontrer cette erreur, car 768M est largement suffisant pour l'immense majorité des sites WordPress.
Si vous désirez améliorer encore plus votre consommation de mémoire, nous vous recommandons de :
- vérifier que "opcache" est actif via l'accueil de votre PHP Selector
- activer et installer Redis (voir notre tutoriel)
- si pas déjà fait, installer et activer un système de cache comme AccelerateWP (tutoriel)
Pour toute question, n'hésitez pas à répondre au sujet ci-dessous en vous inscrivant à notre forum.
Ce type d'erreur est plus courant avec les sites WordPress qui utilisent des plugins ou des constructeurs de pages (Page Builder) particulièrement consommateurs en mémoire, comme Elementor.
Pour résoudre ce problème, nous allons vous guider sur la façon d'augmenter cette limite de mémoire, côté serveur (PHP) et côté WordPress.
Il y a deux étapes principales à suivre :
1. Augmenter la Memory Limit dans "Select a PHP version" dans votre compte d'hébergement
Une fois dans l'onglet « Sélectionner une version de PHP » depuis votre interface d'hébergement, cliquez sur "Options".
Recherchez l'option memory_limit. Si ce n'est pas déjà fait, changez la valeur actuelle au maximum de 1024M.
2. Augmenter la Memory Limit dans wp-config.php
Même si vous augmentez la limite via votre compte d'hébergement, WordPress a ses propres constantes de mémoire WP_MEMORY_LIMIT qu'il va essayer de respecter, ce qui reste un plafond supplémentaire posant problème si votre site WordPress est très consommateur de mémoire.
Il est donc recommandé de les définir à une valeur élevée également côté CMS.
Pour cela, connectez-vous à votre site via FTP ou le Gestionnaire de fichiers (File Manager) de votre compte d'hébergement.
Localisez le fichier wp-config.php à la racine de votre installation WordPress.
Ouvrez ce fichier et ajoutez les lignes suivantes juste avant la ligne
/* That's all, stop editing! Happy publishing. */ :
Code Sélectionner
define( 'WP_MEMORY_LIMIT', '768M');
define( 'WP_MAX_MEMORY_LIMIT', '768M' );Les valeurs de WP_MEMORY_LIMIT doivent toujours être inférieures aux valeurs de PHP Memory_Limit pour éviter tout dépassement qui engendreraient des erreurs 500.
Donc puisque la valeur maximale de PHP Memory_Limit est de 1024M, la valeur optimale maximale de WP_MEMORY_LIMIT est 768M.
Une fois cette optimisation réalisée, vous ne devriez plus rencontrer cette erreur, car 768M est largement suffisant pour l'immense majorité des sites WordPress.
Si vous désirez améliorer encore plus votre consommation de mémoire, nous vous recommandons de :
- vérifier que "opcache" est actif via l'accueil de votre PHP Selector
- activer et installer Redis (voir notre tutoriel)
- si pas déjà fait, installer et activer un système de cache comme AccelerateWP (tutoriel)
Pour toute question, n'hésitez pas à répondre au sujet ci-dessous en vous inscrivant à notre forum.
#5
Annonces officielles / Re : Annonce concernant la sta...
Dernier message par MassiveHoster - Oct 24, 2025, 11:14 AM[Annonce & Opportunité]
IMPORTANT pour tous les utilisateurs MassiveHoster.
Nous y sommes et grâce à votre collaboration, nous allons pouvoir mitiger la surcharge d'infrastructure que nous n'avions pas pu anticiper !
L'infrastructure de base dont nous ne pouvions connaître les limites réelles a atteint sa pleine capacité début-octobre, alors que nous étions toujours en train de finaliser quelques dernières optimisations pour les performances des sites hébergés, inclut la fin du développement de notre « Cache Booster » : partition ultra-rapide aux ressources dédiées au stockage de vos fichiers "wp-content/cache".
Nous n'avons pas attendu très longtemps pour conclure que l'infrastructure avait atteint sa capacité idéale, mais un choix se présentait à nous...
Dans quel ordre réaliser ces actions ?
① finaliser le déploiement du Cache Booster qui devait stabiliser l'infrastructure en réduisant la charge sur la partition principale
② stopper les améliorations et scaler immédiatement l'infrastructure en doublant les ressources à disposition
Puisque la première option semblait bien plus rapide à déployer et avec effet immédiat sans devoir solliciter la collaboration de nos hébergés, nous avons choisi de mettre le focus sur la finalisation en urgence du Cache Booster.
Mais c'était sans compter sur la complexité actuelle des plugins de cache WordPress.
Ce qui devait être une simple automatisation d'un déplacement de dossier s'est transformé en un système complexe :
~ 5000 lignes de code,
8 scripts indépendants,
génération de fichiers de processing en CSV...
le tout basé en grande partie sur des commandes WP CLI exécutées individuellement sur les comptes utilisateurs via "su", pour chaque instance de Cache Booster 😵�💫
Aujourd'hui, le système fonctionne bien et les résultats côté performance sont assez impressionnants sur la visite de cache à froid. Certains tests de TTFB sont presque divisés par 10.
Le problème, c'est le temps.
Les imprévus ont allongé le délai de déploiement du Cache Booster et donc, le temps que nous pouvions allouer au scaling de l'infrastructure.
Pendant ce temps-là, environ 20 sites WordPress se créaient chaque jour sur l'infrastructure déjà borderline... de nouveaux sites embarquant tous des CRONs et du trafic qui, chaque jour, ont rajouté de la pression sur l'infrastructure existante. Pression que hélas, le Cache Booster n'a pas su compenser une fois déployé sur +80% des sites WordPress hébergés disposant d'un plugin de cache, malgré un très joli gain de performances sur les pages en cache.
Le souci, c'est que la consommation des ressources d'un serveur ne se limite pas à l'immense majorité du trafic / des visiteurs qui sont servis :
il y a les requêtes MySQL exécutées par les sites en arrière plan ;
les sauvegardes de données ;
le scan des fichiers anti-malware ;
l'import de produits eCommerce et d'innombrables autres types de tâches... ♾
Face à l'expérience acquise, nous sommes forcés de le reconnaître... notre choix stratégique n'était pas le bon.
Si vous avions eu toutes ces informations dans les mains, nous aurions remis le Cache Booster à plus tard, et priorisé le déploiement d'une nouvelle infrastructure. Mais ça, nous n'aurions pas pu l'anticiper si facilement.
Résultat, nous venons d'expérimenter quelques jours d'instabilité avec des micro-coupures (pour la plupart) et dernièrement, une saturation plus sérieuse de MySQL, trop sollicité, dont l'usage augmente chaque jour sans solution de repli disponible ; ce qui crée des perturbations plus notables que nous mitigeons manuellement à chaque fois, mais qui restent évidemment inacceptables à moyen terme.
Nous nous excusons sincèrement pour cela.
Tout cela étant dit, nous sommes enfin prêts à vous proposer, à court terme, une stabilisation de votre situation individuelle en planifiant avec chaque utilisateur qui en fait la demande, le déplacement de leur(s) compte(s) vers la nouvelle infrastructure !
L'avantage pour vous ?
Une stabilisation rapide, car forcément, la nouvelle infrastructure n'est pas victime de surcharge et le trafic y sera calme pendant plusieurs mois.
L'avantage pour nous ?
Nous permettre de transférer les +15% de surplus de sites Web hébergés sur la première infra vers la seconde infra, et donc nous aider à stabiliser la situation globalement.
L'inconvénient pour vous ?
Hélas, même si le transfert des comptes complets est assuré par notre équipe en toute transparence (sites, mails, settings avancés, etc), il vous sera nécessaire d'apporter un changement à votre configuration * DNS * chez votre registrar (changement de * NS * ou * d'adresse IP *), dès que le changement de serveur sera confirmé par notre équipe.
Pour profiter du transfert de vos comptes vers la nouvelle infra, veuillez ouvrir un Ticket au support (icône d'enveloppe sur la page d'accueil de notre site) et/ou envoyez un DM à @MassiveHoster en mentionnant l'adresse email de votre compte client pour nous aider à faire le lien.
L'équipe vous reviendra ensuite pour planifier le transfert au mieux et vous donnera tous les détails sur la manière de procéder.
Si vous êtes intéressé, ne tardez pas à nous le faire savoir, car comme vous pouvez le comprendre, l'offre de transfert reste plus particulièrement valable tant que la situation sur l'infrastructure d'origine n'est pas encore redevenue optimale.
Vous avez jusqu'au 28 octobre pour nous faire part de votre désir d'être migré si vous le souhaitez.
Si le changement de DNS est trop contraignant ou si vous pensez pouvoir patienter un peu plus, soyez sûr que tout est fait pour stabiliser l'ensemble (infra d'origine incluse) le plus rapidement possible... ! ✅
...après tout, il y a un peu plus de 3 semaines, alors que nous hébergions ~10% à 15% de sites en moins, l'infrastructure se portait plutôt bien.
Ces complications nous aurons appris une information essentielle :
« Où se situe notre limite avant de devoir scaler ? »
Nous savons maintenant, précisément, à partir de combien de plans d'hébergement "vendus" nous devons déclencher la création de nouveaux serveurs Web.
Et nous comptons bien nous servir de cette précieuse information pour améliorer le service fourni à moyen et à long terme, et éviter ce genre d'expérience très désagréable pour tout le monde !
L'équipe attend vos Tickets et DM sans tarder si vous êtes candidat pour un transfert 🤝😉
Merci pour votre collaboration et compréhension.
À très bientôt !
IMPORTANT pour tous les utilisateurs MassiveHoster.
Nous y sommes et grâce à votre collaboration, nous allons pouvoir mitiger la surcharge d'infrastructure que nous n'avions pas pu anticiper !
L'infrastructure de base dont nous ne pouvions connaître les limites réelles a atteint sa pleine capacité début-octobre, alors que nous étions toujours en train de finaliser quelques dernières optimisations pour les performances des sites hébergés, inclut la fin du développement de notre « Cache Booster » : partition ultra-rapide aux ressources dédiées au stockage de vos fichiers "wp-content/cache".
Nous n'avons pas attendu très longtemps pour conclure que l'infrastructure avait atteint sa capacité idéale, mais un choix se présentait à nous...
Dans quel ordre réaliser ces actions ?
① finaliser le déploiement du Cache Booster qui devait stabiliser l'infrastructure en réduisant la charge sur la partition principale
② stopper les améliorations et scaler immédiatement l'infrastructure en doublant les ressources à disposition
Puisque la première option semblait bien plus rapide à déployer et avec effet immédiat sans devoir solliciter la collaboration de nos hébergés, nous avons choisi de mettre le focus sur la finalisation en urgence du Cache Booster.
Mais c'était sans compter sur la complexité actuelle des plugins de cache WordPress.
Ce qui devait être une simple automatisation d'un déplacement de dossier s'est transformé en un système complexe :
~ 5000 lignes de code,
8 scripts indépendants,
génération de fichiers de processing en CSV...
le tout basé en grande partie sur des commandes WP CLI exécutées individuellement sur les comptes utilisateurs via "su", pour chaque instance de Cache Booster 😵�💫
Aujourd'hui, le système fonctionne bien et les résultats côté performance sont assez impressionnants sur la visite de cache à froid. Certains tests de TTFB sont presque divisés par 10.
Le problème, c'est le temps.
Les imprévus ont allongé le délai de déploiement du Cache Booster et donc, le temps que nous pouvions allouer au scaling de l'infrastructure.
Pendant ce temps-là, environ 20 sites WordPress se créaient chaque jour sur l'infrastructure déjà borderline... de nouveaux sites embarquant tous des CRONs et du trafic qui, chaque jour, ont rajouté de la pression sur l'infrastructure existante. Pression que hélas, le Cache Booster n'a pas su compenser une fois déployé sur +80% des sites WordPress hébergés disposant d'un plugin de cache, malgré un très joli gain de performances sur les pages en cache.
Le souci, c'est que la consommation des ressources d'un serveur ne se limite pas à l'immense majorité du trafic / des visiteurs qui sont servis :
il y a les requêtes MySQL exécutées par les sites en arrière plan ;
les sauvegardes de données ;
le scan des fichiers anti-malware ;
l'import de produits eCommerce et d'innombrables autres types de tâches... ♾
Face à l'expérience acquise, nous sommes forcés de le reconnaître... notre choix stratégique n'était pas le bon.
Si vous avions eu toutes ces informations dans les mains, nous aurions remis le Cache Booster à plus tard, et priorisé le déploiement d'une nouvelle infrastructure. Mais ça, nous n'aurions pas pu l'anticiper si facilement.
Résultat, nous venons d'expérimenter quelques jours d'instabilité avec des micro-coupures (pour la plupart) et dernièrement, une saturation plus sérieuse de MySQL, trop sollicité, dont l'usage augmente chaque jour sans solution de repli disponible ; ce qui crée des perturbations plus notables que nous mitigeons manuellement à chaque fois, mais qui restent évidemment inacceptables à moyen terme.
Nous nous excusons sincèrement pour cela.
Tout cela étant dit, nous sommes enfin prêts à vous proposer, à court terme, une stabilisation de votre situation individuelle en planifiant avec chaque utilisateur qui en fait la demande, le déplacement de leur(s) compte(s) vers la nouvelle infrastructure !
L'avantage pour vous ?
Une stabilisation rapide, car forcément, la nouvelle infrastructure n'est pas victime de surcharge et le trafic y sera calme pendant plusieurs mois.
L'avantage pour nous ?
Nous permettre de transférer les +15% de surplus de sites Web hébergés sur la première infra vers la seconde infra, et donc nous aider à stabiliser la situation globalement.
L'inconvénient pour vous ?
Hélas, même si le transfert des comptes complets est assuré par notre équipe en toute transparence (sites, mails, settings avancés, etc), il vous sera nécessaire d'apporter un changement à votre configuration * DNS * chez votre registrar (changement de * NS * ou * d'adresse IP *), dès que le changement de serveur sera confirmé par notre équipe.
Pour profiter du transfert de vos comptes vers la nouvelle infra, veuillez ouvrir un Ticket au support (icône d'enveloppe sur la page d'accueil de notre site) et/ou envoyez un DM à @MassiveHoster en mentionnant l'adresse email de votre compte client pour nous aider à faire le lien.
L'équipe vous reviendra ensuite pour planifier le transfert au mieux et vous donnera tous les détails sur la manière de procéder.
Si vous êtes intéressé, ne tardez pas à nous le faire savoir, car comme vous pouvez le comprendre, l'offre de transfert reste plus particulièrement valable tant que la situation sur l'infrastructure d'origine n'est pas encore redevenue optimale.
Vous avez jusqu'au 28 octobre pour nous faire part de votre désir d'être migré si vous le souhaitez.
Si le changement de DNS est trop contraignant ou si vous pensez pouvoir patienter un peu plus, soyez sûr que tout est fait pour stabiliser l'ensemble (infra d'origine incluse) le plus rapidement possible... ! ✅
...après tout, il y a un peu plus de 3 semaines, alors que nous hébergions ~10% à 15% de sites en moins, l'infrastructure se portait plutôt bien.
Ces complications nous aurons appris une information essentielle :
« Où se situe notre limite avant de devoir scaler ? »
Nous savons maintenant, précisément, à partir de combien de plans d'hébergement "vendus" nous devons déclencher la création de nouveaux serveurs Web.
Et nous comptons bien nous servir de cette précieuse information pour améliorer le service fourni à moyen et à long terme, et éviter ce genre d'expérience très désagréable pour tout le monde !
L'équipe attend vos Tickets et DM sans tarder si vous êtes candidat pour un transfert 🤝😉
Merci pour votre collaboration et compréhension.
À très bientôt !
#6
MassiveHoster Academy / AccelerateWP, comment l'instal...
Dernier message par MassiveHoster - Oct 15, 2025, 08:19 AMEn tant qu'utilisateur du CMS WordPress, vous n'êtes pas sans savoir que l'activation d'un plugin de cache est indispensable pour tout site accessible publiquement, afin d'offrir une bonne expérience à ses visiteurs, mais aussi préserver les ressources de votre compte d'hébergement web.
D'après nos statistiques, environ 50% des sites WordPress n'utilisaient aucun plugin de cache, ce qui représente un important gaspillage de ressources et, dans le cadre d'un hébergement mutualisé, impact indirectement les performances et la stabilité des sites voisins. C'est pourquoi nous convions chaque utilisateur à activer sur l'ensemble de leurs sites WordPress, un plugin de cache efficace.
Pour vous aider dans cette démarche, nous vous offrons AccelerateWP (un fork de WP Rocket) qui peut être installé et activé en 3 clics depuis votre panel d'hébergement MassiveHoster.
Comment installer AccelerateWP chez MassiveHoster ?
Pour commencer, rendez-vous sur la page d'accueil de votre interface de gestion MassiveHoster et cliquez sur l'icône « AccelerateWP ».
Le système va scanner tout votre compte d'hébergement à la recherche de sites WordPress (patience, cela peut prendre quelques minutes...).
Une fois tous vos sites WordPress détectés, au survol d'un site, cliquez sur l'icône en forme d'engrenage (Paramètres) à côté du site que vous désirez optimiser.
Cochez ensuite la case « AccelerateWP » et apprêtez-vous une nouvelle fois à patienter un peu...
La récupération du plugin sur les serveurs de CloudLinux, l'installation / activation du plugin et l'optimisation initiale de votre site peuvent prendre quelques minutes...
Vous recevrez enfin une confirmation que l'installation et l'activation se sont bien déroulées.
Pour terminer, rendez-vous dans le tableau de bord de ce site WordPress pour découvrir qu'AccelerateWP est maintenant présent, comme n'importe quel autre plugin, dans ce dashboard WordPress...
À ce stade, votre cache est d'ores et déjà actif pour ce site WordPress !
Pour aller plus loin, en cliquant sur Paramètres / Settings, vous pouvez configurer les paramètres avancés d'AccelerateWP, comme :
Bravo, vous venez d'améliorer grandement l'expérience utilisateur de votre site et la consommation de ressources de votre compte d'hébergement.
Pour toute question ou remarque, n'hésitez pas à répondre à cette discussion. L'équipe est disponible pour toute demande concernant AccelerateWP ainsi que l'optimisation des performances de votre hébergement.
Pour aller plus loin, n'hésitez pas à découvrir le Redis Object Cache et comment l'activer sur un site WordPress ?
D'après nos statistiques, environ 50% des sites WordPress n'utilisaient aucun plugin de cache, ce qui représente un important gaspillage de ressources et, dans le cadre d'un hébergement mutualisé, impact indirectement les performances et la stabilité des sites voisins. C'est pourquoi nous convions chaque utilisateur à activer sur l'ensemble de leurs sites WordPress, un plugin de cache efficace.
Pour vous aider dans cette démarche, nous vous offrons AccelerateWP (un fork de WP Rocket) qui peut être installé et activé en 3 clics depuis votre panel d'hébergement MassiveHoster.
Comment installer AccelerateWP chez MassiveHoster ?
Pour commencer, rendez-vous sur la page d'accueil de votre interface de gestion MassiveHoster et cliquez sur l'icône « AccelerateWP ».
Le système va scanner tout votre compte d'hébergement à la recherche de sites WordPress (patience, cela peut prendre quelques minutes...).
Une fois tous vos sites WordPress détectés, au survol d'un site, cliquez sur l'icône en forme d'engrenage (Paramètres) à côté du site que vous désirez optimiser.
Cochez ensuite la case « AccelerateWP » et apprêtez-vous une nouvelle fois à patienter un peu...
La récupération du plugin sur les serveurs de CloudLinux, l'installation / activation du plugin et l'optimisation initiale de votre site peuvent prendre quelques minutes...
Vous recevrez enfin une confirmation que l'installation et l'activation se sont bien déroulées.
Pour terminer, rendez-vous dans le tableau de bord de ce site WordPress pour découvrir qu'AccelerateWP est maintenant présent, comme n'importe quel autre plugin, dans ce dashboard WordPress...
À ce stade, votre cache est d'ores et déjà actif pour ce site WordPress !
Pour aller plus loin, en cliquant sur Paramètres / Settings, vous pouvez configurer les paramètres avancés d'AccelerateWP, comme :
- la minification CSS/JS
- le report du JavaScript
- le lazyload des images
- le préchargement du cache
- l'optimisation de la base de données
- l'activation d'un CDN
- la réduction des heartbeats...
Bravo, vous venez d'améliorer grandement l'expérience utilisateur de votre site et la consommation de ressources de votre compte d'hébergement.
Pour toute question ou remarque, n'hésitez pas à répondre à cette discussion. L'équipe est disponible pour toute demande concernant AccelerateWP ainsi que l'optimisation des performances de votre hébergement.
Pour aller plus loin, n'hésitez pas à découvrir le Redis Object Cache et comment l'activer sur un site WordPress ?
#7
Support Technique / Erreur PrestaShop : DBALExcept...
Dernier message par MassiveHoster - Oct 08, 2025, 01:25 PMLes versions anciennes de PrestaShop comme la 1.7 peuvent rencontrer des problèmes de compatibilité avec les bases de données MySQL / MariaDB récentes (comme la version 11.4+), entraînant des erreurs comme DBALException lors de la détection de la version du serveur et SQLSTATE[HY000] [2026] pour des problèmes SSL.
Ces erreurs sont souvent liées à une configuration automatique défaillante de Doctrine lors d'une installation manuelle ou via Softaculous. Doctrine est le composant gérant les connexions à la base de données.
Des solutions existent, comme spécifier manuellement la version du serveur et désactiver la vérification SSL, permettant de faire fonctionner PrestaShop 1.7 sur des infrastructures modernes.
Contrairement à des CMS plus flexibles comme WordPress, PrestaShop 1.7 manque de portabilité, mais les versions 8 et 9 résolvent en grande partie ces problèmes grâce à des mises à jour de Doctrine.
En 2025, PrestaShop 1.7 est obsolète (sortie en 2016), tandis que PrestaShop 8 (début 2023) et PerstaShop 9 (juin 2025) supportent mieux les versions actuelles de MySQL / MariaDB.
Le Problème Rencontré
Si vous gérez un site PrestaShop 1.7 sur un hébergement avec une version récente de MariaDB (comme 11.4), vous pourriez voir apparaître l'erreur suivante lors de l'accès au back-office ou pendant des opérations impliquant la base de données :
Cette erreur est souvent accompagnée d'une sous-erreur liée à SSL :
Ces messages indiquent que PrestaShop, via Doctrine, échoue à détecter automatiquement la version de la base de données et rencontre un problème avec la configuration SSL/TLS lors de la connexion.
La Cause du Problème
PrestaShop 1.7 utilise une version plus ancienne de Doctrine (environ 2.x), qui n'est pas optimisée pour les versions récentes de MySQL / MariaDB.
MySQL et MariaDB ont évolué avec des changements subtils (comme des mots-clés réservés ou des comportements SSL par défaut), rendant la détection automatique capricieuse. Sur des hébergements modernes comme ceux de MassiveHoster, où MariaDB 11.4+ est un standard, PrestaShop tente une connexion SSL par défaut, mais échoue si le chemin des certificats n'est pas accessible ou mal configuré (d'où l'erreur "invalid directory").
Les anciennes versions de PrestaShop sont particulièrement sensibles à ces incompatibilités, contrairement à des CMS comme WordPress, qui gèrent mieux la portabilité et détectent automatiquement les connexions sans intervention manuelle.
Cela représente un inconvénient majeur de PrestaShop 1.7 : il n'arrive pas toujours à déterminer comment se connecter correctement à MySQL/MariaDB, alors que la majorité des CMS (Magento, Joomla, Drupal, etc) y parviennent sans accroc.
La Solution Étape par Étape
Pour résoudre cela, modifiez le fichier app/config/doctrine.yml de votre installation PrestaShop 1.7. Ajoutez ou modifiez les lignes suivantes sous la section dbal > connections > default :
Cette configuration contourne la détection automatique et désactive la vérification SSL pour les connexions locales, sans compromettre la sécurité.
PrestaShop 1.7, lancée en 2016, commence à montrer son âge en 2025, surtout face à des infrastructures à jour comme MariaDB 11.x. Bien que des solutions existent pour la maintenir opérationnelle, il est recommandé de migrer vers des versions plus récentes pour une meilleure compatibilité et sécurité.
Compatibilité avec MariaDB dans PrestaShop 1.7
PrestaShop 1.7 supporte officiellement MySQL 5.7 minimum, mais MariaDB (fork de MySQL) pose souvent des problèmes au-delà de 10.2. Des utilisateurs rapportent des ralentissements ou des échecs de connexion avec MariaDB 10.6 ou 11.x, dus à des divergences comme le cache de requêtes ou les modes SQL stricts. Par exemple, sur des forums, des migrations vers MariaDB 10.5 ont amélioré les performances, mais nécessitent des ajustements manuels pour éviter les erreurs DBALException.
Inconvénients de PrestaShop Comparé à d'Autres CMS
Contrairement à WordPress, qui est hautement portable et s'adapte automatiquement à diverses versions de MySQL/MariaDB sans intervention, PrestaShop 1.7 requiert souvent des tweaks manuels. WordPress détecte et ajuste les connexions via wpdb, gérant même les SSL par défaut sans erreurs courantes. Cela rend PrestaShop moins "plug-and-play", un point critiqué dans la communauté, où des threads sur les forums soulignent des migrations compliquées post-mises à jour du serveur.
Évolution dans PrestaShop 8 et 9
PrestaShop 8, sortie début 2023 (octobre 2022 pour la version initiale), et PrestaShop 9, lancée en juin 2025, intègrent Doctrine DBAL 3.x+, offrant un meilleur support pour MariaDB 10.2 minimum jusqu'aux versions récentes (11.x testées).
Ces versions résolvent en grande partie les problèmes de détection automatique et de SSL, grâce à une gestion plus robuste des plateformes.
Des tests communautaires confirment une compatibilité accrue, avec moins d'erreurs rapportées. Par exemple, PrestaShop 9 supporte PHP 8.4 et optimise les connexions pour des environnements modernes, rendant les ajustements manuels rares.
Si vous utilisez encore PrestaShop 1.7, une mise à jour vers 8 ou 9 est vivement conseillée pour éviter l'obsolescence et bénéficier de fonctionnalités modernes comme des interfaces utilisateurs et d'admin améliorées, ainsi que des performances et une sécurité renforcée.
Conseils pour les Hébergements Modernes
Sur des plateformes comme MassiveHoster ou EasyHoster, vérifiez toujours la version MariaDB via phpMyAdmin.
Si des erreurs persistent après la solution ci-dessus, n'hésitez pas à prendre contact avec le support technique pour obtenir plus d'assistance.
En 2025, soyez conscient que la version de PrestaShop 1.7 devient sérieusement obsolète et envisagez une update aussi rapidement que possible pour éviter tout inconvénient d'incompatibilité avec les hébergeurs qui mettent à jours leurs solutions.
Des outils comme le module 1-Click Upgrade et des solutions de sauvegardes comme JetBackup5 (disponible chez MassiveHoster) peuvent faciliter le passage à PrestaShop 8 ou 9, préservant vos données, modules et nécessitant principalement un travail au niveau de votre thème/webdesign PrestaShop.
Ces erreurs sont souvent liées à une configuration automatique défaillante de Doctrine lors d'une installation manuelle ou via Softaculous. Doctrine est le composant gérant les connexions à la base de données.
Des solutions existent, comme spécifier manuellement la version du serveur et désactiver la vérification SSL, permettant de faire fonctionner PrestaShop 1.7 sur des infrastructures modernes.
Contrairement à des CMS plus flexibles comme WordPress, PrestaShop 1.7 manque de portabilité, mais les versions 8 et 9 résolvent en grande partie ces problèmes grâce à des mises à jour de Doctrine.
En 2025, PrestaShop 1.7 est obsolète (sortie en 2016), tandis que PrestaShop 8 (début 2023) et PerstaShop 9 (juin 2025) supportent mieux les versions actuelles de MySQL / MariaDB.
Le Problème Rencontré
Si vous gérez un site PrestaShop 1.7 sur un hébergement avec une version récente de MariaDB (comme 11.4), vous pourriez voir apparaître l'erreur suivante lors de l'accès au back-office ou pendant des opérations impliquant la base de données :
Code Sélectionner
Whoops, looks like something went wrong.
(4/4) DBALException
An exception occured while establishing a connection to figure out your platform version.
You can circumvent this by setting a 'server_version' configuration valueCette erreur est souvent accompagnée d'une sous-erreur liée à SSL :
Code Sélectionner
(3/4) DriverException
An exception occurred in driver: SQLSTATE[HY000] [2026] TLS/SSL error: invalid directoryCes messages indiquent que PrestaShop, via Doctrine, échoue à détecter automatiquement la version de la base de données et rencontre un problème avec la configuration SSL/TLS lors de la connexion.
La Cause du Problème
PrestaShop 1.7 utilise une version plus ancienne de Doctrine (environ 2.x), qui n'est pas optimisée pour les versions récentes de MySQL / MariaDB.
MySQL et MariaDB ont évolué avec des changements subtils (comme des mots-clés réservés ou des comportements SSL par défaut), rendant la détection automatique capricieuse. Sur des hébergements modernes comme ceux de MassiveHoster, où MariaDB 11.4+ est un standard, PrestaShop tente une connexion SSL par défaut, mais échoue si le chemin des certificats n'est pas accessible ou mal configuré (d'où l'erreur "invalid directory").
Les anciennes versions de PrestaShop sont particulièrement sensibles à ces incompatibilités, contrairement à des CMS comme WordPress, qui gèrent mieux la portabilité et détectent automatiquement les connexions sans intervention manuelle.
Cela représente un inconvénient majeur de PrestaShop 1.7 : il n'arrive pas toujours à déterminer comment se connecter correctement à MySQL/MariaDB, alors que la majorité des CMS (Magento, Joomla, Drupal, etc) y parviennent sans accroc.
La Solution Étape par Étape
Pour résoudre cela, modifiez le fichier app/config/doctrine.yml de votre installation PrestaShop 1.7. Ajoutez ou modifiez les lignes suivantes sous la section dbal > connections > default :
Code Sélectionner
# Adaptez à votre version MariaDB, ex. '10.6' pour compatibilité
server_version: '11.4'
# Désactive la vérification SSL (PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT)
options:
1007: false - Vérifiez votre version MariaDB :
via phpMyAdmin > homepage de phpMyAdmin > Version du serveur - Sauvegardez avant modification : copiez le fichier original pour pouvoir le restaurer si besoin
- Effacez manuellement le cache : supprimez les dossiers /var/cache/dev/ et /var/cache/prod/ (sans passer par la corbeille)
- Testez : rechargez votre site ou /admin/ ; si l'erreur persiste, essayez '10.4' ou une autre version correspondante pour des questions de compatibilité
Cette configuration contourne la détection automatique et désactive la vérification SSL pour les connexions locales, sans compromettre la sécurité.
PrestaShop 1.7, lancée en 2016, commence à montrer son âge en 2025, surtout face à des infrastructures à jour comme MariaDB 11.x. Bien que des solutions existent pour la maintenir opérationnelle, il est recommandé de migrer vers des versions plus récentes pour une meilleure compatibilité et sécurité.
Compatibilité avec MariaDB dans PrestaShop 1.7
PrestaShop 1.7 supporte officiellement MySQL 5.7 minimum, mais MariaDB (fork de MySQL) pose souvent des problèmes au-delà de 10.2. Des utilisateurs rapportent des ralentissements ou des échecs de connexion avec MariaDB 10.6 ou 11.x, dus à des divergences comme le cache de requêtes ou les modes SQL stricts. Par exemple, sur des forums, des migrations vers MariaDB 10.5 ont amélioré les performances, mais nécessitent des ajustements manuels pour éviter les erreurs DBALException.
Inconvénients de PrestaShop Comparé à d'Autres CMS
Contrairement à WordPress, qui est hautement portable et s'adapte automatiquement à diverses versions de MySQL/MariaDB sans intervention, PrestaShop 1.7 requiert souvent des tweaks manuels. WordPress détecte et ajuste les connexions via wpdb, gérant même les SSL par défaut sans erreurs courantes. Cela rend PrestaShop moins "plug-and-play", un point critiqué dans la communauté, où des threads sur les forums soulignent des migrations compliquées post-mises à jour du serveur.
Évolution dans PrestaShop 8 et 9
PrestaShop 8, sortie début 2023 (octobre 2022 pour la version initiale), et PrestaShop 9, lancée en juin 2025, intègrent Doctrine DBAL 3.x+, offrant un meilleur support pour MariaDB 10.2 minimum jusqu'aux versions récentes (11.x testées).
Ces versions résolvent en grande partie les problèmes de détection automatique et de SSL, grâce à une gestion plus robuste des plateformes.
Des tests communautaires confirment une compatibilité accrue, avec moins d'erreurs rapportées. Par exemple, PrestaShop 9 supporte PHP 8.4 et optimise les connexions pour des environnements modernes, rendant les ajustements manuels rares.
Si vous utilisez encore PrestaShop 1.7, une mise à jour vers 8 ou 9 est vivement conseillée pour éviter l'obsolescence et bénéficier de fonctionnalités modernes comme des interfaces utilisateurs et d'admin améliorées, ainsi que des performances et une sécurité renforcée.
Conseils pour les Hébergements Modernes
Sur des plateformes comme MassiveHoster ou EasyHoster, vérifiez toujours la version MariaDB via phpMyAdmin.
Si des erreurs persistent après la solution ci-dessus, n'hésitez pas à prendre contact avec le support technique pour obtenir plus d'assistance.
En 2025, soyez conscient que la version de PrestaShop 1.7 devient sérieusement obsolète et envisagez une update aussi rapidement que possible pour éviter tout inconvénient d'incompatibilité avec les hébergeurs qui mettent à jours leurs solutions.
Des outils comme le module 1-Click Upgrade et des solutions de sauvegardes comme JetBackup5 (disponible chez MassiveHoster) peuvent faciliter le passage à PrestaShop 8 ou 9, préservant vos données, modules et nécessitant principalement un travail au niveau de votre thème/webdesign PrestaShop.
#8
Support Technique / Erreur : Unable to delete tras...
Dernier message par MassiveHoster - Oct 08, 2025, 08:49 AMVous désirez supprimer des fichiers ou des dossiers hébergés dans un répertoire de cache tel que /wp-content/cache/ ou /var/cache/, par exemple, dans l'objectif de vider manuellement votre cache de fichiers, mais vous recevez une erreur similaire à celle-ci ?
Unable to delete trash/files/filename.ext.Abc123Xyz789: invalid cross-device link
Unable to delete files
Cela signifie que pour vous offrir de meilleures performances, nos systèmes ont décidé d'héberger vos fichiers de cache dans notre solution propriétaire « Cache Booster » (une partition dédiée destinée à offrir le meilleur débit I/O à ces fichiers de cache).
Malheureusement, cette solution n'est pas compatible avec la « Mise en corbeille ».
La solution pour supprimer les dossiers/fichiers désirés est de décocher l'option de « mise à la corbeille » (Move to Trash), comme illustré ci-dessous.
Vous serez alors autorisé à supprimer les dossiers/fichiers sans erreur.
Unable to delete trash/files/filename.ext.Abc123Xyz789: invalid cross-device link
Unable to delete files
Cela signifie que pour vous offrir de meilleures performances, nos systèmes ont décidé d'héberger vos fichiers de cache dans notre solution propriétaire « Cache Booster » (une partition dédiée destinée à offrir le meilleur débit I/O à ces fichiers de cache).
Malheureusement, cette solution n'est pas compatible avec la « Mise en corbeille ».
La solution pour supprimer les dossiers/fichiers désirés est de décocher l'option de « mise à la corbeille » (Move to Trash), comme illustré ci-dessous.
Vous serez alors autorisé à supprimer les dossiers/fichiers sans erreur.
#9
Annonces officielles / Re : Annonce concernant la sta...
Dernier message par MassiveHoster - Oct 06, 2025, 09:51 AM[Update 📢]
Fin de semaine dernière, nous avons communiqué sur le fait que nous avions constaté des perturbations qui nous ont conduit à déterminer qu'il était temps de scaler techniquement l'infrastructure :
rien d'anormal en termes d'utilisation, nous avons simplement rencontré la limite de ce qui pouvait être encaissé avec les moyens mis en place.
Bien que de nouvelles optimisations vont venir alléger la charge du serveur sous 48h (cf. « Cache Booster », voir ci-dessous), nous devons ASAP doubler les ressources à disposition pour assumer les nouvelles commandes qui arrivent en nombre à un rythme inattendu !
Les travaux finaux sur la V1 de notre « Cache Booster » sont en cours (là, en ce moment...).
Ce système développé en interne va notamment placer la plupart des « wp-content/cache » et cache PrestaShop sur une partition séparée disposant de sa propre bande passante I/O, afin d'alléger le reste et offrir plus de réactivité à la plupart des sites mis en cache.
Les graphiques et logs de ce lundi matin sont une seconde confirmation qu'il n'est pas trop tôt pour passer à cette 2e phase (détails ci-dessous).
Tous ces travaux sont en cours et nous faisons au plus vite !
Dans l'intervalle, malheureusement, certaines perturbations inhabituelles peuvent encore être constatées.
Par exemple, en lisant les rapports de ce lundi matin, nous avons pu constater qu'hier soir, des lenteurs ont été expérimentées sur notre infrastructure pendant exactement 25 minutes :
- à 22:00,
tous les dimanches, nous lançons un second backup complet de toutes les bases de données MySQL.
Ce second système de backup développé en interne est hebdomadaire et est utile pour notre second DRP, car chez MassiveHoster, nous n'avons pas seulement un, mais deux DRP pour sécuriser vos données au cas (rare) où le premier système de backup (JetBackup5) serait éventuellement défaillant.
On s'inspire de la règle du 3-2-1 pour les sauvegardes, pour ne jamais avoir à dire à un client que nous avons perdu ses données 💀 😱
C'est cher, mais dormir tranquille n'a pas de prix !
- à 23:12,
le serveur a expérimenté une charge trop élevée due à un cumul de "consommation légitime" de nos utilisateurs, alors que le backup de toutes les bases MySQL était toujours en cours...
- à 23:15,
notre script de surveillance de charge automatisé à "*/5" (vous savez, celui développé récemment) a été alerté et s'est mis en mode surveillance avancée
- à 23:20,
voyant que la charge du serveur ne revenait pas à la normale, notre script a mis le serveur en mode « protection » pour éviter un DOWN en réduisant la charge générée par les utilisateurs du serveur et les principaux processus consommateurs.
(c'est le moment où, sans une telle automatisation, un technicien aurait dû sortir du lit pour agir à la main)
- à 23:37,
la charge du serveur était revenue en dessous du seuil critique, et la vie du serveur a progressivement repris son cours normalement...
- à 1:38,
le backup des bases MySQL s'est terminé avec succès, laissant place au backup des fichiers, planifié à 2h, et qui était encore en cours (à 7:58 au moment d'écrire ce rapport), car défini en basse priorité (donc volontairement lent).
Donc, désolé à tous pour les quelques perturbations expérimentées hier soir 🙏 Elles sont directement liées au fait que l'infrastructure soit pleinement utilisée depuis moins d'une semaine, alors que nous n'avons pas encore eu le temps de finaliser les toutes dernières optimisations.
Nous sommes conscients que la situation actuelle peut générer des perturbations aux moments où des tâches lourdes sont exécutées en parallèle, comme ici, pendant les indispensables backups MySQL... ce qui n'est pas normal, et c'est en cours de résolution 🤞
Le déploiement d'une seconde infrastructure a déjà débuté...
Cependant, puisque nous faisons le choix de configurer nos serveurs manuellement (les technologies évoluant très vite) pour éviter toute erreur d'automatisation et conserver la meilleure qualité possible, ce travail nécessite plusieurs jours :
entre 5 et 10 jours pour pouvoir annoncer un nouveau serveur 100% stable et suffisamment testé.
L'équipe est sur tous les fronts et est au maximum pour continuer de vous offrir un service aussi stable et performant que possible sur ce format, jeune et à tarifs compétitifs.
Le support est disponible par Ticket et/ou DM pour tout complément.
Merci pour votre patience et collaboration... on y retourne ! 🔥
Fin de semaine dernière, nous avons communiqué sur le fait que nous avions constaté des perturbations qui nous ont conduit à déterminer qu'il était temps de scaler techniquement l'infrastructure :
rien d'anormal en termes d'utilisation, nous avons simplement rencontré la limite de ce qui pouvait être encaissé avec les moyens mis en place.
Bien que de nouvelles optimisations vont venir alléger la charge du serveur sous 48h (cf. « Cache Booster », voir ci-dessous), nous devons ASAP doubler les ressources à disposition pour assumer les nouvelles commandes qui arrivent en nombre à un rythme inattendu !
Les travaux finaux sur la V1 de notre « Cache Booster » sont en cours (là, en ce moment...).
Ce système développé en interne va notamment placer la plupart des « wp-content/cache » et cache PrestaShop sur une partition séparée disposant de sa propre bande passante I/O, afin d'alléger le reste et offrir plus de réactivité à la plupart des sites mis en cache.
Les graphiques et logs de ce lundi matin sont une seconde confirmation qu'il n'est pas trop tôt pour passer à cette 2e phase (détails ci-dessous).
Tous ces travaux sont en cours et nous faisons au plus vite !
Dans l'intervalle, malheureusement, certaines perturbations inhabituelles peuvent encore être constatées.
Par exemple, en lisant les rapports de ce lundi matin, nous avons pu constater qu'hier soir, des lenteurs ont été expérimentées sur notre infrastructure pendant exactement 25 minutes :
- à 22:00,
tous les dimanches, nous lançons un second backup complet de toutes les bases de données MySQL.
Ce second système de backup développé en interne est hebdomadaire et est utile pour notre second DRP, car chez MassiveHoster, nous n'avons pas seulement un, mais deux DRP pour sécuriser vos données au cas (rare) où le premier système de backup (JetBackup5) serait éventuellement défaillant.
On s'inspire de la règle du 3-2-1 pour les sauvegardes, pour ne jamais avoir à dire à un client que nous avons perdu ses données 💀 😱
C'est cher, mais dormir tranquille n'a pas de prix !
- à 23:12,
le serveur a expérimenté une charge trop élevée due à un cumul de "consommation légitime" de nos utilisateurs, alors que le backup de toutes les bases MySQL était toujours en cours...
- à 23:15,
notre script de surveillance de charge automatisé à "*/5" (vous savez, celui développé récemment) a été alerté et s'est mis en mode surveillance avancée
- à 23:20,
voyant que la charge du serveur ne revenait pas à la normale, notre script a mis le serveur en mode « protection » pour éviter un DOWN en réduisant la charge générée par les utilisateurs du serveur et les principaux processus consommateurs.
(c'est le moment où, sans une telle automatisation, un technicien aurait dû sortir du lit pour agir à la main)
- à 23:37,
la charge du serveur était revenue en dessous du seuil critique, et la vie du serveur a progressivement repris son cours normalement...
- à 1:38,
le backup des bases MySQL s'est terminé avec succès, laissant place au backup des fichiers, planifié à 2h, et qui était encore en cours (à 7:58 au moment d'écrire ce rapport), car défini en basse priorité (donc volontairement lent).
Donc, désolé à tous pour les quelques perturbations expérimentées hier soir 🙏 Elles sont directement liées au fait que l'infrastructure soit pleinement utilisée depuis moins d'une semaine, alors que nous n'avons pas encore eu le temps de finaliser les toutes dernières optimisations.
Nous sommes conscients que la situation actuelle peut générer des perturbations aux moments où des tâches lourdes sont exécutées en parallèle, comme ici, pendant les indispensables backups MySQL... ce qui n'est pas normal, et c'est en cours de résolution 🤞
Le déploiement d'une seconde infrastructure a déjà débuté...
Cependant, puisque nous faisons le choix de configurer nos serveurs manuellement (les technologies évoluant très vite) pour éviter toute erreur d'automatisation et conserver la meilleure qualité possible, ce travail nécessite plusieurs jours :
entre 5 et 10 jours pour pouvoir annoncer un nouveau serveur 100% stable et suffisamment testé.
L'équipe est sur tous les fronts et est au maximum pour continuer de vous offrir un service aussi stable et performant que possible sur ce format, jeune et à tarifs compétitifs.
Le support est disponible par Ticket et/ou DM pour tout complément.
Merci pour votre patience et collaboration... on y retourne ! 🔥
#10
Annonces officielles / Annonce concernant la stabilit...
Dernier message par MassiveHoster - Oct 02, 2025, 09:08 AMNous avons reçu cette nuit plusieurs notifications mentionnant des pics de charge sur l'infrastructure actuelle.
L'analyse des logs est claire :
l'utilisation faite du service est dans la norme, mais nous atteignons les limites de ressources de l'infrastructure actuelle. Autrement dit, nous venons de rencontrer le plafond de l'infrastructure actuelle.
Ces données complètes et fiables sont d'ailleurs l'occasion de faire les comptes et d'évaluer concrètement la rentabilité du projet qui, nous pouvons déjà vous le dire, est positive ✔️ sans pour autant être gargantuesque.
Cette évaluation va nous permettre d'aller de l'avant !
À très court terme (en urgence même !) nous devons déployer globalement notre solution de « Cache Booster », déjà en test sur un échantillon de sites depuis quelques semaines. Ce déploiement sera accompagné d'une automatisation qui encourage par e-mail chaque site WordPress dénué de plugin de cache à activer AccelerateWP ou toute autre solution de cache.
L'objectif de cette ultime action vise à stabiliser la consommation de ressources de l'infrastructure actuelle.
En parallèle, nous allons planifier, dès la semaine prochaine, le provisionnement de deux fois plus de ressources pour satisfaire la demande élevée de nouveaux plans d'hébergement. Demande qui risque encore de croître pendant les mois d'octobre et novembre qui, de notre expérience, sont assez intenses dans le secteur de l'hébergement web.
En résumé, le projet passe les étapes et suit son cours, avec quelques balbutiements inévitables en cours de route, bien qu'il offre un rapport qualité-prix qui reste très correct pour une première année de vie, il nous semble ? 🤔
À ce stade et avec toute l'expérience acquise sur ce format, nous espérons que l'année prochaine sera encore meilleure pour MassiveHoster et ses utilisateurs.
Nous vous tiendrons informés ici lorsque les différents déploiements auront été réalisés.
Souhaitez-nous bonne chance !
Merci pour votre confiance 🙏
L'analyse des logs est claire :
l'utilisation faite du service est dans la norme, mais nous atteignons les limites de ressources de l'infrastructure actuelle. Autrement dit, nous venons de rencontrer le plafond de l'infrastructure actuelle.
Ces données complètes et fiables sont d'ailleurs l'occasion de faire les comptes et d'évaluer concrètement la rentabilité du projet qui, nous pouvons déjà vous le dire, est positive ✔️ sans pour autant être gargantuesque.
Cette évaluation va nous permettre d'aller de l'avant !
À très court terme (en urgence même !) nous devons déployer globalement notre solution de « Cache Booster », déjà en test sur un échantillon de sites depuis quelques semaines. Ce déploiement sera accompagné d'une automatisation qui encourage par e-mail chaque site WordPress dénué de plugin de cache à activer AccelerateWP ou toute autre solution de cache.
L'objectif de cette ultime action vise à stabiliser la consommation de ressources de l'infrastructure actuelle.
En parallèle, nous allons planifier, dès la semaine prochaine, le provisionnement de deux fois plus de ressources pour satisfaire la demande élevée de nouveaux plans d'hébergement. Demande qui risque encore de croître pendant les mois d'octobre et novembre qui, de notre expérience, sont assez intenses dans le secteur de l'hébergement web.
En résumé, le projet passe les étapes et suit son cours, avec quelques balbutiements inévitables en cours de route, bien qu'il offre un rapport qualité-prix qui reste très correct pour une première année de vie, il nous semble ? 🤔
À ce stade et avec toute l'expérience acquise sur ce format, nous espérons que l'année prochaine sera encore meilleure pour MassiveHoster et ses utilisateurs.
Nous vous tiendrons informés ici lorsque les différents déploiements auront été réalisés.
Souhaitez-nous bonne chance !
Merci pour votre confiance 🙏