Le disque est plein, et tout en pâtit
Tu essaies d’uploader une image dans la médiathèque WordPress, rien ne se passe. Tu tentes d’envoyer un email depuis le site, il ne part jamais. Parfois pire : le back-office affiche une erreur 500, ou carrément un 507 “Insufficient Storage”. Ce n’est pas un bug isolé. C’est le symptôme d’un disque serveur saturé — l’espace de stockage alloué à ton hébergement est plein, ou presque.
Le 507 est une erreur HTTP peu connue mais sans ambiguïté : le serveur ne peut plus écrire de nouvelles données. Pas d’upload, pas de sauvegarde, parfois même plus d’écriture en base de données. Ça sonne grave, mais dans l’immense majorité des cas c’est réparable en moins d’une heure, sans perte de données, à condition de nettoyer dans le bon ordre. Voici comment repérer ce qui bouffe l’espace et le libérer proprement.
Pourquoi le disque se remplit
L’espace disque ne disparaît jamais d’un coup — il se grignote sur des semaines ou des mois, souvent à cause d’automatismes qu’on a oubliés :
- Logs qui s’accumulent : erreurs PHP, logs d’accès, logs de sécurité (fail2ban, ModSecurity) tournent en continu et peuvent peser plusieurs Go sur un site ancien.
- Sauvegardes locales empilées : un plugin de backup qui stocke ses archives sur le même serveur au lieu de les envoyer vers un stockage externe (S3, Google Drive) — classique sur les configurations mal réglées.
- Cache de page et cache d’objet non purgé : LiteSpeed Cache ou WP Rocket génèrent des fichiers HTML statiques pour chaque page, chaque langue, chaque variante — sans purge automatique, ça enfle.
- File d’attente d’emails bloquée : quand la file de mail sortant (mail queue) déborde, elle stocke les messages en attente sur disque, souvent invisible dans l’interface.
- Médiathèque non optimisée : des images en 8000×6000 px jamais compressées, des vidéos hébergées en direct au lieu d’être sur YouTube ou Vimeo.
- Révisions d’articles et transients WordPress : la table
wp_postspeut contenir des centaines de versions inutiles d’un même article, etwp_optionsdes dizaines de milliers de transients expirés. - Copies de staging ou d’anciens thèmes oubliés dans un sous-dossier après une migration ou un changement d’agence.
Le point commun : rien de tout ça ne se voit dans le tableau de bord WordPress. Il faut aller inspecter le serveur directement.
1. Vérifier l’espace disque réel (cPanel, Plesk, SSH)
Avant de nettoyer, mesure. Sur cPanel, l’indicateur “Disk Usage” en page d’accueil donne le pourcentage utilisé. Sur Plesk, c’est dans “Abonnements” > vue d’ensemble. Si tu as un accès SSH sur Plesk ou SSH sur Gandi, la commande la plus rapide est :
df -hElle affiche l’usage disque par partition. Si / ou /home affiche 95-100 %, c’est confirmé. Ensuite, pour savoir quels dossiers pèsent le plus lourd :
du -sh /home/utilisateur/* | sort -rh | head -20Cette commande liste les 20 plus gros éléments du répertoire, triés du plus lourd au plus léger. En général, trois dossiers ressortent : wp-content/uploads, logs, et un dossier de sauvegardes.
2. Nettoyer les logs et fichiers temporaires
C’est le gain le plus rapide et le moins risqué. Repère les logs volumineux :
find / -name "*.log" -size +50M 2>/dev/nullUn fichier error_log de plusieurs centaines de Mo est courant sur un site qui tourne depuis des années avec un plugin qui spamme des erreurs PHP en boucle — souvent lié à un plugin cassé après une mise à jour. Tu peux vider le contenu sans supprimer le fichier (utile s’il est encore utilisé par un processus actif) :
> /chemin/vers/error_logVérifie aussi le dossier /tmp de ton hébergement, souvent oublié, qui accumule des sessions PHP et des fichiers d’upload interrompus.
3. Traquer les sauvegardes stockées sur le serveur
C’est souvent LA cause principale sur un site qui traîne depuis 2-3 ans. Un plugin comme UpdraftPlus ou Duplicator, mal configuré, stocke ses archives complètes (fichiers + base) directement dans wp-content/updraft ou similaire, sans jamais les transférer vers un stockage distant. Chaque sauvegarde peut peser 1 à 5 Go selon la taille du site. Multiplie par des dizaines de sauvegardes automatiques hebdomadaires jamais purgées, et tu obtiens un disque plein en quelques mois.
La correction : configure le plugin pour pousser les sauvegardes vers un stockage externe (Google Drive, Dropbox, S3), et règle une rétention stricte (garder les 3-4 dernières seulement, supprimer le reste). Supprime manuellement les anciennes archives locales une fois vérifié qu’elles existent bien ailleurs.
4. Purger le cache et optimiser la base
Le cache de page (LiteSpeed, WP Rocket, W3 Total Cache) génère des fichiers statiques pour accélérer le chargement — voir notre guide de configuration LiteSpeed — mais sans purge régulière, ces fichiers s’accumulent, notamment sur un site multilingue ou avec beaucoup de variantes de pages. Vide le cache depuis le plugin, ou directement le dossier wp-content/cache en SSH.
Côté base de données, les révisions d’articles, commentaires spam et transients expirés gonflent la base WordPress elle-même (fichier .sql en cas de sauvegarde, et taille réelle en base). Le nettoyage se fait proprement avec WP-Optimize — voir notre guide pour nettoyer la base sans rien casser.
5. Compresser et externaliser les médias lourds
Si wp-content/uploads est le dossier le plus lourd, deux leviers : compresser les images existantes avec un plugin dédié (comparatif complet dans notre article sur les plugins d’optimisation d’images), et déplacer les vidéos vers YouTube/Vimeo en embed plutôt que de les héberger en direct — un fichier vidéo de 200 Mo pèse plus qu’un an de logs.
6. Vérifier la file d’attente d’emails
Si les emails ne partent plus en plus des uploads qui échouent, la file d’attente SMTP locale peut être saturée. C’est un symptôme annexe du disque plein, mais aussi une cause indépendante si la configuration d’envoi est mauvaise — voir notre guide SMTP pour WordPress. Une fois l’espace disque libéré, relance le service mail (systemctl restart exim ou équivalent selon l’hébergeur) pour vider la file bloquée.
Tableau récapitulatif
| Cause | Où regarder | Solution |
|---|---|---|
| Logs volumineux | error_log, logs cPanel/Plesk | Vider ou purger avec rotation automatique |
| Sauvegardes locales empilées | wp-content/updraft ou équivalent | Externaliser + limiter la rétention |
| Cache de page non purgé | wp-content/cache | Purger via le plugin de cache |
| Base gonflée (révisions, transients) | Table wp_posts, wp_options | Nettoyer avec WP-Optimize |
| Médiathèque lourde | wp-content/uploads | Compresser images, externaliser vidéos |
| File mail bloquée | Queue SMTP serveur | Libérer l’espace puis redémarrer le service mail |
FAQ
Le 507 peut-il abîmer ma base de données ?
Non, en général la base reste intacte : l’erreur bloque l’écriture, elle ne corrompt pas les données existantes. Mais si le disque est plein pendant une opération d’écriture en cours (mise à jour, import), il vaut mieux vérifier l’intégrité de la base après coup avec WP-Optimize.
Pourquoi mon hébergeur ne m'a pas prévenu ?
Certains hébergeurs mutualisés n’envoient une alerte qu’à 95-100 % d’usage, parfois jamais. Sur un hébergement premium ou VPS avec monitoring, configure toi-même une alerte à 80 % pour anticiper.
Combien d'espace disque un site WordPress classique consomme-t-il ?
Un site vitrine avec peu de médias tient facilement en 1-2 Go. Un site e-commerce avec des centaines de fiches produits et des sauvegardes peut monter à 10-20 Go. Au-delà, il faut auditer régulièrement.
Le 507 est-il lié à la lenteur du site ?
Indirectement oui : un disque saturé ralentit les écritures et peut aggraver un site déjà lent. Une fois l’espace libéré, la performance générale s’améliore souvent d’elle-même.
Faut-il changer d'hébergeur si ça se reproduit ?
Si le quota disque est structurellement trop petit pour ton activité, oui — voir notre guide pour changer d’hébergeur sans perdre son SEO. Mais dans la majorité des cas, un nettoyage régulier suffit à éviter la récidive.
Quand passer la main à un pro
Si le nettoyage ne libère pas assez d’espace, si tu n’as pas d’accès SSH, ou si tu hésites à supprimer un fichier de peur de casser le site — arrête-toi là. Un prestataire de maintenance peut auditer l’usage disque en quinze minutes, mettre en place une purge automatique des logs et sauvegardes, et éviter que le problème revienne dans six mois. Le 507 n’est jamais une fatalité : c’est un signal qu’il manque un entretien régulier, pas juste un fichier à effacer.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy