Un développeur reçoit un jour un message inquiet : « le site plante dès qu’on importe le catalogue produits ». Le thème est correct, le plugin d’import est réputé fiable, le code ne contient aucune erreur visible. Le problème vient d’ailleurs : l’hébergement mutualisé sur lequel tourne le site limite la mémoire PHP à 128 Mo et coupe tout script qui dépasse trente secondes d’exécution. L’import de plusieurs milliers de produits ne tient simplement pas dans ces contraintes.
Cette anecdote illustre un malentendu fréquent chez les clients, et parfois chez les développeurs eux-mêmes : le mutualisé n’est pas un hébergement WordPress au rabais, c’est un hébergement générique adapté à des usages précis. En sortir de son périmètre naturel produit des symptômes qui ressemblent à des bugs, alors qu’il s’agit de limites d’infrastructure.
Ce que le mutualisé fait très bien
Pour un site vitrine, un blog, ou même une petite boutique avec un catalogue de quelques dizaines de produits, le mutualisé remplit parfaitement son rôle. Les hébergeurs sérieux y intègrent un cache de page basique, un pare-feu applicatif générique, et une sauvegarde quotidienne mutualisée sur l’ensemble du serveur. Le rapport service rendu sur prix reste imbattable pour ce type de projet.
La simplicité de gestion joue aussi en sa faveur : pas de mise à jour système à suivre, pas de configuration nginx à maintenir, une interface graphique suffit pour l’essentiel des opérations courantes comme la création d’une base de données ou l’ajout d’un sous-domaine.
La limite de mémoire PHP, premier mur invisible
La directive memory_limit de PHP fixe la quantité de mémoire qu’un script peut consommer avant d’être arrêté avec une erreur fatale. Sur un mutualisé d’entrée de gamme, cette limite tourne souvent autour de 128 Mo, parfois moins. Un import CSV volumineux, une génération de miniatures en masse après changement de thème, ou certains constructeurs de pages gourmands peuvent facilement dépasser ce plafond.
Le symptôme classique est une page blanche, ou une erreur Allowed memory size exhausted dans les logs si l’hébergeur les rend accessibles. Contrairement à un VPS, il est rarement possible d’augmenter cette limite au-delà d’un certain seuil fixé par l’hébergeur, même en modifiant le fichier wp-config.php.
Les tâches cron interrompues
WordPress s’appuie sur un mécanisme de cron déclenché à chaque visite (wp-cron), ou sur un vrai cron système si celui-ci est désactivé et remplacé par une tâche planifiée côté hébergeur. Sur un mutualisé, cette tâche planifiée tourne souvent avec les mêmes limites de temps d’exécution qu’une requête web classique — généralement entre trente et soixante secondes.
Une sauvegarde complète, une synchronisation avec un service tiers, ou un traitement par lot dans une extension d’e-commerce peuvent nécessiter davantage de temps. Le script est alors interrompu en plein milieu, ce qui laisse parfois des données incohérentes plutôt qu’une simple erreur propre.
Comment le repérer
- Une extension de sauvegarde qui s’arrête toujours au même pourcentage.
- Un import de produits qui traite toujours le même nombre de lignes avant de s’interrompre.
- Une synchronisation avec une caisse ou un ERP qui échoue systématiquement passé un certain volume.
Les extensions et modules PHP restreints
Certains hébergeurs mutualisés désactivent des fonctions PHP jugées risquées comme exec() ou shell_exec(), ce qui bloque des extensions qui en dépendent pour générer des PDF ou convertir des images. D’autres n’installent pas certaines extensions PHP comme imagick, remplacée par la seule bibliothèque GD, moins performante pour le traitement d’images lourdes.
Sur un mutualisé, la question à poser n’est pas « est-ce que ça marche en local », mais « est-ce que l’hébergeur autorise ce que ce plugin a besoin de faire ». La réponse ne figure presque jamais dans la documentation du plugin lui-même.
Quand basculer vers autre chose
Trois signaux indiquent qu’il est temps de changer de type d’hébergement : des erreurs de mémoire ou de timeout qui reviennent malgré l’optimisation du code, un besoin de contrôler précisément la configuration serveur (version de PHP spécifique, module manquant), ou un trafic qui commence à saturer les ressources partagées de façon visible aux heures de pointe. Dans ces trois cas, un VPS correctement administré, ou une offre infogérée avec des limites plus généreuses, résout le problème à la racine plutôt que de multiplier les contournements.
En résumé
Le mutualisé n’est pas un hébergement de seconde zone, c’est un outil calibré pour un usage précis. Le reconnaître évite de blâmer à tort une extension ou un thème, et permet d’orienter le client vers la bonne solution avant que les symptômes ne deviennent des crises. Bien identifier ces limites en amont d’un projet fait gagner un temps considérable en support après la mise en ligne.
