Trois pannes en trois jours chez l’hébergeur Fritz Managed IT : ce qu’il faut savoir sur les limites de stockage, les sauvegardes, les pare-feu et les bots quand on gère un site WordPress
- Le 29 octobre 2026, le logiciel d’hébergement a bloqué le portail financier steuerratschlag.eu : il occupait 36,3 Go alors que le forfait n’en autorisait que 25. En cause, d’anciennes sauvegardes – une seule archive pesait 17,2 Go.
- Le 31 octobre 2026, toute connexion au tableau de bord WordPress se terminait par « Internal Server Error » : le pare-feu ModSecurity de l’hébergeur coupait les pages de plus de 1 Mo, après qu’une extension d’analyse eut fait gonfler le tableau de bord.
- Un assistant IA a trouvé la cause dans le journal d’erreurs ; une fois l’extension désactivée, la connexion a refonctionné.
- Toujours le 31 octobre 2026, le site est retombé par intermittence : des bots issus de réseaux de centres de données l’interrogeaient parfois plus de dix fois par seconde. Le blocage de onze réseaux dans le fichier .htaccess du serveur a mis fin à la surcharge.
Le portail financier steuerratschlag.eu a été inutilisable trois fois en trois jours. Deux fois, des mécanismes de protection de l’hébergeur Fritz Managed IT se sont déclenchés – provoqués par l’encombrement du site lui-même. La troisième fois, des bots ont surchargé le serveur.
D’abord le site a été totalement hors ligne, puis l’accès à l’arrière-boutique WordPress a disparu, et enfin il s’est effondré sous des requêtes automatisées massives. Par souci de transparence : steuerratschlag.eu appartient, comme NETZ-TRENDS, à l’éditeur Dr K. Korosides. Nous relatons ce cas parce qu’il est typique de nombreux petits sites WordPress hébergés en Allemagne – et parce que les messages d’erreur ne révèlent presque rien de ce qui se passe réellement.
Panne 1 : stockage rempli à 142 %
Tard dans la soirée du 29 octobre 2026, steuerratschlag.eu n’affichait plus qu’une erreur « 503 Service Unavailable ». Les fichiers statiques comme robots.txt arrivaient encore, mais plus WordPress lui-même. Dans l’interface d’administration Plesk, l’abonnement apparaissait comme « Suspendu ».
Plesk est une interface de gestion de serveur web, un « panneau de contrôle ». Elle permet de gérer dans le navigateur ce qui exigerait sinon des commandes sur le serveur : créer des domaines et des boîtes mail, téléverser, renommer ou supprimer des fichiers dans un gestionnaire de fichiers, gérer bases de données, sauvegardes et certificats de sécurité, lire les journaux du serveur web. Un « abonnement » dans Plesk est un forfait d’hébergement réservé avec des limites fixes, par exemple pour l’espace de stockage.
Pourquoi les hébergeurs en ont besoin
Un hébergeur fait souvent tourner sur un même serveur des centaines de sites de clients différents. Ceux-ci ne doivent pas avoir accès à l’administration système de tout le serveur (accès root), mais doivent pouvoir gérer leur propre espace sans appeler le support pour chaque détail. Un panneau de contrôle sépare proprement les espaces clients, fait respecter les limites réservées et automatise les tâches de routine : créer de nouveaux forfaits, renouveler des certificats, installer des mises à jour de sécurité. Développer un tel logiciel en interne n’est rentable que pour les grands fournisseurs. Les hébergeurs plus modestes achètent donc des licences auprès de Plesk ou de son concurrent cPanel. Il existe aussi des alternatives libres et gratuites comme ISPConfig ou Froxlor, qui demandent toutefois davantage de compétences techniques.
Quelle est sa diffusion
Selon le service de statistiques W3Techs (au 1er novembre 2026), Plesk fait tourner 41,4 % des sites web dont le panneau de contrôle est détectable de l’extérieur. Seul hPanel, l’interface maison du grand hébergeur Hostinger, est plus répandu, avec 54,2 % ; cPanel atteint 1,8 %. Plus un site est important, plus Plesk est fréquent : parmi les 1 000 sites les plus visités dont l’interface est détectable, sa part atteint 84,6 %. Mais sur la plupart des sites, l’interface n’est pas détectable du tout – ces chiffres ne décrivent donc qu’une partie du marché. Plesk fonctionne sur serveurs Linux comme Windows.
Qui est derrière
Plesk est né vers 1999-2000 à Novossibirsk, en Russie, et a ensuite appartenu entre autres à SWsoft puis Parallels. Il est aujourd’hui développé par Plesk International GmbH, basée à Schaffhouse (Suisse). L’entreprise appartient au groupe WebPros, auquel appartient aussi cPanel ; l’actionnaire majoritaire de WebPros est, depuis 2020, l’investisseur financier CVC Capital Partners (historique de l’entreprise, en anglais).
✔ Les points forts de Plesk
- Utilisation entièrement dans le navigateur, sans connaissance de la ligne de commande.
- Beaucoup d’outils réunis dans un seul forfait, dont un WordPress Toolkit pour les mises à jour et les sauvegardes.
- Fonctions de protection intégrées comme le pare-feu web ModSecurity et des blocages d’IP automatiques après des accès suspects – exactement les mécanismes qui se sont déclenchés sur steuerratschlag.eu.
- Un accès de secours aux fichiers quand WordPress lui-même refuse de répondre : l’extension fautive a pu être désactivée via le gestionnaire de fichiers alors même que l’arrière-boutique était inaccessible.
✘ Ce qu’on reproche à Plesk
- Des prix de licence en hausse : selon une analyse du média spécialisé webhosting.today (en anglais), les prix catalogue ont augmenté d’environ 50 à 60 % entre 2020 et 2024 selon le forfait. L’hébergeur IONOS a introduit en 2025 des frais Plesk de 5 livres sterling par mois pour les clients disposant d’un serveur virtuel, invoquant une hausse significative des coûts de licence (The Register, en anglais). Ces coûts finissent par retomber sur les gestionnaires de sites.
- Peu de concurrence : Plesk et cPanel, les deux panneaux sous licence les plus connus, appartiennent au même groupe.
- Failles de sécurité : un logiciel massivement déployé sur de nombreux serveurs est une cible de choix. En 2012, des attaquants ont exploité une faille dans d’anciennes versions de Plesk, touchant selon les rapports environ 50 000 domaines.
- Erreurs opaques&160;: les fonctions de protection se déclenchent automatiquement mais indiquent rarement pourquoi. Sur steuerratschlag.eu, le blocage, la coupure du pare-feu et le blocage d’IP n’ont affiché que des pages d’erreur sans information – la cause n’apparaissait que dans les journaux.
Pour steuerratschlag.eu, Plesk a été l’outil décisif dans les trois pannes : c’est là qu’étaient consignés l’usage du stockage et les journaux d’erreurs et d’accès.
La cause est apparue dans Plesk : le site occupait 36,3 Go, comptabilisés comme 35,4 Go d’espace web dans les statistiques – soit 142 % du forfait de 25 Go du pack « Web Débutant ». Plesk peut suspendre automatiquement un abonnement en cas de dépassement – une fonction standard du logiciel, paramétrée par l’hébergeur pour ses forfaits.
L’espace était presque entièrement occupé par des copies de sauvegarde : une sauvegarde complète réalisée le 28 octobre par l’outil Plesk « WP Toolkit », pesant 17,2 Go, ainsi que des sauvegardes de l’extension UpdraftPlus datant de 2020 et 2026, totalisant plus de 11 Go. Après le nettoyage du 30 octobre, le site n’occupait plus que 4,3 Go, environ 17 % du forfait.
Panne 2 : le pare-feu bloque le tableau de bord
Deux jours plus tard, le 31 octobre, le site se chargeait de nouveau normalement pour les visiteurs. Mais la connexion à l’arrière-boutique WordPress échouait : après avoir cliqué sur « Se connecter », une page d’erreur brute « Internal Server Error » apparaissait, invitant à contacter l’administrateur à « root@localhost » – un texte standard du serveur web Apache qui n’explique rien.
La cause figurait dans le journal d’erreurs du serveur. La connexion elle-même fonctionnait. C’est seulement au chargement du tableau de bord que le pare-feu web ModSecurity, qui tourne sur le serveur avec un jeu de règles du fournisseur Comodo, s’est déclenché. Il indiquait « Response body too large (over limit of 1048576) » : la page dépassait 1 Mo, le pare-feu l’a coupée.
C’est l’extension Query Monitor qui avait fait gonfler le tableau de bord. Il s’agit d’un outil pour développeurs qui ajoute à chaque page de l’arrière-boutique les requêtes en base de données, les erreurs PHP et d’autres données de diagnostic. Pour les administrateurs connectés, il accroche à chaque page un grand panneau d’analyse, avec toutes les requêtes en base, les hooks (points d’accroche pour extensions) et les scripts. Sur un site comptant beaucoup d’extensions comme steuerratschlag.eu, cela dépasse facilement la limite de 1 Mo. Les visiteurs ordinaires ne voient jamais ce panneau, ce qui explique que le site ait continué de fonctionner normalement alors que le tableau de bord, lui, non. D’après la date du fichier, Query Monitor avait été installé ou mis à jour le 27 octobre 2026, deux jours avant les problèmes.
Le diagnostic n’était pas certain au départ. Les autres suspects ont été écartés : le dossier des extensions must-use (mu-plugins, chargées automatiquement en permanence par WordPress) ne contenait que trois petits fichiers inoffensifs, et rien d’autre n’attirait l’attention dans le dossier des extensions. Impossible de vérifier directement si Query Monitor était alors actif : la base de données était inaccessible dans Plesk, et le WordPress Toolkit de Plesk ne s’ouvrait pas.
L’extension a été désactivée sans accès à l’arrière-boutique&160;: Claude a renommé, dans le gestionnaire de fichiers de Plesk, le dossier « query-monitor » en « query-monitor_deaktiviert ». Quand WordPress ne trouve plus le dossier d’une extension, il la désactive aussitôt – et l’opération se défait à tout moment en redonnant son nom d’origine au dossier. WordPress peut ensuite afficher brièvement un message indiquant que l’extension a été désactivée parce que le fichier n’existe plus ; c’est normal. Au cas où la connexion serait restée bloquée, les extensions Jetpack et Site Kit figuraient ensuite sur la liste des suspects. Cela n’a pas été nécessaire : après le renommage, la connexion a immédiatement refonctionné. Au quotidien, Query Monitor n’est pas nécessaire et reste désactivée.
La configuration type de ModSecurity (en anglais) ne prévoit en réalité que 512 Ko – le serveur de steuerratschlag.eu autorise donc le double. Pour les pages dépassant la limite, cette configuration type recommande de laisser passer le reste sans le vérifier (« ProcessPartial »), afin de ne pas casser des pages légitimes. Sur le serveur de steuerratschlag.eu, d’après le journal, le dépassement a au contraire entraîné l’interruption de la requête.
C’est Claude, l’assistant IA de l’entreprise américaine Anthropic avec lequel la rédaction travaille, qui a trouvé la cause. Il a d’abord vérifié si le site était accessible depuis l’extérieur, puis conseillé un test depuis une autre connexion, avant de lire finalement le journal d’erreurs dans Plesk. C’est là que se trouvait l’entrée décisive.
Pendant la recherche de la panne, Plesk redirigeait à plusieurs reprises vers sa page de connexion – une adresse qui, au premier coup d’œil, paraît suspicieusement longue. Elle reste toutefois lisible&160;: au début figure le nom du serveur de l’hébergeur, suivi de « :8443 », le port habituel pour l’administration Plesk, puis « login_up.php », la page de connexion de Plesk. Le long reste après « success_redirect_url= » indique seulement à Plesk où rediriger après la connexion, par exemple vers le gestionnaire de fichiers d’un dossier précis. L’essentiel est que la barre d’adresse affiche exactement le nom du serveur de l’hébergeur – sinon il pourrait s’agir d’une fausse page cherchant à capter des identifiants.
Panne 3 : des bots surchargent le serveur
Dans l’après-midi du 31 octobre 2026, steuerratschlag.eu est redevenu par moments inaccessible&160;; une page d’erreur 500 apparaissait par intermittence, et l’arrière-boutique WordPress répondait extrêmement lentement. Le soupçon logique&160;: le stockage se remplit de nouveau. Claude a donc passé en revue, dossier par dossier, les emplacements typiques où traînent de vieux fichiers dans le gestionnaire de fichiers de Plesk. Le dossier des sauvegardes WordPress et la corbeille Plesk étaient vides, le dossier « wp-snapshots » ne contenait qu’un sous-dossier vide datant de 2016, et le dossier de l’extension de sauvegarde BackWPup contenait trois fichiers minuscules totalisant moins de 1 Ko.
L’espace occupé se trouve presque entièrement dans des images datant de 2014, liées dans des articles et devant donc rester en place. Seuls 23 thèmes inactifs (modèles de mise en page), pesant environ 70 Mo, et six extensions inactives pourraient encore libérer un peu de place. Ce n’est pas nécessaire avec un forfait de 25 Go – et cela n’avait rien à voir avec la troisième panne.
La cause figurait dans les journaux d’accès du serveur, dans Plesk&160;: le site était massivement sollicité par des bots, des programmes automatisés, parfois à plus de dix requêtes par seconde. Deux groupes se distinguaient&160;:
- Des bots de scraping (programmes qui aspirent du contenu en masse)&160;: des centaines d’adresses IP parcouraient d’anciennes pages d’étiquettes (/tag/…), par exemple sur les caisses d’épargne-logement ou la fraude fiscale à la Société Générale. Les adresses provenaient de quelques réseaux de centres de données.
- Des serveurs du réseau Amazon&160;: des dizaines de machines réclamaient sans cesse les mêmes nouveaux articles et images, parfois plusieurs fois par seconde.
Chacune de ces requêtes oblige WordPress à recalculer la page depuis la base de données. Sur un petit forfait d’hébergement, cette charge suffit à mettre le serveur à genoux.
Le remède&160;: Claude a bloqué onze réseaux de centres de données suspects dans le fichier .htaccess, le fichier de configuration du serveur web Apache. L’entrée figure dans un bloc repéré « Bot-Sperre » tout en haut du fichier et peut être retirée à tout moment. Les vrais lecteurs et le moteur de recherche Google ne sont pas concernés. Depuis 17 h 15, les bots bloqués n’apparaissent plus dans le journal. Depuis, la page d’accueil, la connexion et les pages d’étiquettes se chargent en une à trois secondes.
Blocages d’IP : une protection à double tranchant
Pour l’éditeur, un troisième désagrément s’est ajouté&160;: selon lui, sa propre connexion internet a été exclue par le serveur deux fois en une semaine. Le site ne se chargeait alors plus depuis sa propre ligne, tout en restant accessible depuis d’autres connexions. Ce n’est qu’en passant par un VPN (réseau privé virtuel), qui achemine le trafic via un autre serveur, qu’il a pu de nouveau accéder à l’arrière-boutique.
De tels blocages automatiques sont courants sur les serveurs d’hébergement et ont de bonnes raisons d’exister&160;: ils repoussent les attaques sur les pages de connexion, où des bots testent en masse des mots de passe. Fritz Managed IT indique dans son espace client s’appuyer sur une détection comportementale, un antivirus et une équipe de sécurité disponible 24 heures sur 24. Mais celui qui saisit lui-même plusieurs fois des identifiants erronés peut être victime de ces mêmes protections – et doit alors demander un déblocage au support, joignable, selon l’espace client, du lundi au vendredi de 9 h à 17 h.
Le 31 octobre aussi, l’éditeur a de nouveau été touché&160;: alors que steuerratschlag.eu se chargeait de nouveau normalement depuis l’extérieur, les requêtes depuis son navigateur échouaient immédiatement, tandis que netz-trends.de, hébergé ailleurs, restait accessible. Explication la plus probable&160;: le pare-feu de l’hébergeur avait bloqué son adresse IP après les nombreuses requêtes de la journée – dues aux rechargements répétés de l’arrière-boutique et aux vérifications effectuées pendant la recherche de panne. De tels blocages se résolvent souvent d’eux-mêmes après 15 à 60 minutes&160;; sinon, un déblocage par le support permet d’y remédier.
Ce qu’on peut en retenir
- Ne jamais laisser des sauvegardes en permanence sur le même espace web&160;: les stocker ailleurs et n’en conserver que quelques-unes.
- Vérifier régulièrement l’usage du stockage dans l’interface d’hébergement, pas seulement une fois bloqué.
- N’activer les extensions de développeur comme Query Monitor que pour dépanner, puis les désactiver.
- Face à une « Internal Server Error », lire d’abord le journal d’erreurs du serveur – c’est là que se trouve la cause, pas sur la page d’erreur.
- Vérifier régulièrement les journaux d’accès pour repérer des bots suspects et bloquer via .htaccess les réseaux de centres de données qui submergent le site.
- Désactiver une extension suspecte sans accès à l’arrière-boutique&160;: renommer son dossier dans le gestionnaire de fichiers de l’hébergeur – annulable en renommant à l’identique.
- En cas de suspicion de blocage d’IP, tester le site via les données mobiles ou une autre connexion, et signaler sa propre adresse IP au support.
Les trois pannes sont désormais résolues. Cela n’est pas sans conséquence pour un portail d’actualité&160;: tant que le site est hors service, le trafic et les revenus publicitaires font défaut.
Questions fréquentes
Que signifie « 503 Service Unavailable » ?
Le serveur est accessible mais ne peut pas livrer la page pour le moment. Chez steuerratschlag.eu, c’était dû au blocage automatique déclenché par le dépassement du forfait de stockage.
Que signifie « Internal Server Error » ?
L’erreur 500 signifie qu’un problème est survenu pendant la génération de la page. Dans le cas de steuerratschlag.eu, le pare-feu ModSecurity a interrompu la livraison parce que le tableau de bord dépassait 1 Mo.
Faut-il supprimer Query Monitor ?
Non. Il suffit de n’activer l’extension qu’en cas de besoin. Au quotidien, elle n’est pas nécessaire.
Comment repérer si des bots surchargent un site ?
Dans le journal d’accès (access log) du serveur&160;: de nombreuses requêtes par seconde provenant de quelques réseaux de centres de données, souvent sur d’anciennes pages d’étiquettes ou d’archives, sont un signe typique. Les lecteurs normaux ne demandent jamais plusieurs pages par seconde.
Sources et date
- Statistiques Plesk, gestionnaire de fichiers ainsi que journaux d’accès et d’erreurs du serveur de steuerratschlag.eu, 29 au 31 octobre 2026 (analyse propre)
- ModSecurity, configuration recommandée (modsecurity.conf-recommended, en anglais)
- Query Monitor dans l’annuaire des extensions WordPress
- Fritz Managed IT, informations de l’espace client (au 31 octobre 2026, en allemand)
- Plesk – site de l’éditeur et page Wikipédia consacrée à Plesk (consultées le 1er novembre 2026)
- W3Techs : parts de marché des panneaux web (au 1er novembre 2026)
- webhosting.today : évolution des prix des licences Plesk, 2017–2024
- The Register : IONOS introduit des frais Plesk (2 octobre 2025)
Recherche et données arrêtées au 31 octobre 2026.
Note de transparence : des outils assistés par l’IA ont été utilisés pour la recherche, la structuration et la rédaction de cet article. Les sources utilisées sont indiquées dans l’article. La publication n’intervient qu’après validation éditoriale manuelle. Traduction de l’article original en allemand paru sur NETZ-TRENDS.de.
