# « Erreur de connexion à la base de données » : quand un thème s’effondre sous la charge
> Diagnostic d'un thème qui multiplie les requêtes non mises en cache et provoque une erreur de connexion à la base lors d'un pic de trafic soudain.
- Auteur : Clément Hadrot
- Publié le : 2025-04-16
- Mis à jour le : 2025-04-16
- Catégorie : Thèmes
- URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/erreur-connexion-base-donnees-theme-surcharge/
## L’essentiel
- L'erreur affichée masque souvent un problème de volume de requêtes, pas un problème réseau
- Des requêtes redondantes dans le thème s'ajoutent sous forme cumulée à chaque pic
- Un cache objet et une réduction ciblée des requêtes suffisent sans toucher au serveur
« Erreur d'établissement d'une connexion à la base de données. » Ce message, affiché à la place du site entier, est apparu brutalement un mardi matin, quelques minutes après qu'un lien vers l'article du blog a commencé à circuler largement sur les réseaux sociaux. Aucune modification récente n'avait pourtant été apportée au thème ni à l'hébergement.
Ce billet suit la démarche symptôme → diagnostic → correctif → prévention pour ce cas précis. Il ne traite ni l'optimisation du serveur lui-même, ni la configuration de la base de données MySQL : uniquement ce qui, dans le thème, a transformé un pic de trafic en panne complète.
## Symptôme : une panne totale, pas une lenteur progressive
Contrairement à une dégradation progressive attendue sous forte charge, le site est passé d'un fonctionnement normal à une page d'erreur générique en quelques minutes. Ce basculement brutal est un indice important : il pointe vers un épuisement d'une ressource à seuil, comme le nombre maximal de connexions simultanées autorisées par le serveur MySQL, plutôt qu'une simple saturation progressive du processeur.
## Diagnostic : des requêtes non mises en cache qui se multiplient
Les journaux de requêtes lentes de MySQL, activés temporairement pour l'investigation, ont révélé qu'un seul chargement de page frontale déclenchait plus de 340 requêtes SQL. En creusant le thème, la cause est apparue dans plusieurs endroits : des appels à `get_posts()` répétés dans le pied de page, la barre latérale et l'en-tête, chacun exécutant une nouvelle requête à chaque chargement, sans aucune mise en cache intermédiaire.
```
// Trouvé trois fois, dans trois fichiers différents du thème
function afficher_articles_recents() {
$articles = get_posts( array(
'numberposts' => 5,
'post_type' => 'post',
) );
foreach ( $articles as $article ) {
echo '' . esc_html( $article->post_title ) . '';
}
}
```
Sous trafic normal, ce genre de redondance passe inaperçu : le serveur absorbe sans peine quelques centaines de requêtes par seconde. Sous un pic soudain, chaque visiteur supplémentaire multiplie les mêmes requêtes redondantes, jusqu'à saturer le nombre de connexions simultanées autorisées par la configuration MySQL — d'où l'erreur affichée à tous les visiteurs suivants, y compris ceux qui ne demandaient rien de coûteux.
### Confirmer l'hypothèse avec Query Monitor
L'extension Query Monitor, activée en environnement de préproduction sous une charge simulée avec un outil comme `k6`, a confirmé la piste : les trois fonctions identifiées représentaient à elles seules plus de 60 % du temps total de génération de la page, principalement à cause de leur absence totale de mise en cache.
> L'essentiel à retenir : L'erreur affichée masque souvent un problème de volume de requêtes, pas un problème réseau ; Des requêtes redondantes dans le thème s'ajoutent sous forme cumulée à chaque pic ; Un cache objet et une réduction ciblée des requêtes suffisent sans toucher au serveur
## Correctif : mutualiser et mettre en cache les requêtes redondantes
La première étape a consisté à fusionner les trois appels redondants en un seul, exécuté une fois par chargement de page et partagé entre les trois zones d'affichage via une variable statique. La seconde étape, plus déterminante, a introduit un cache objet persistant avec `wp_cache_get()` et `wp_cache_set()`, couplé à Redis déjà disponible côté hébergement mais jusque-là inutilisé par le thème.
```
function afficher_articles_recents() {
$cle = 'articles_recents_footer';
$articles = wp_cache_get( $cle, 'theme_agence' );
if ( false === $articles ) {
$articles = get_posts( array(
'numberposts' => 5,
'post_type' => 'post',
) );
wp_cache_set( $cle, $articles, 'theme_agence', 15 * MINUTE_IN_SECONDS );
}
foreach ( $articles as $article ) {
echo '' . esc_html( $article->post_title ) . '';
}
}
```
Après déploiement de ce correctif, le nombre de requêtes SQL par chargement de page est tombé de 340 à 28 — un facteur supérieur à dix, mesuré directement dans Query Monitor sur la même page. Un test de charge reproduisant les conditions du pic initial n'a plus provoqué la moindre erreur de connexion.
### Vérifier les autres emplacements à risque
- Recherche systématique des appels à `WP_Query`, `get_posts()` et `get_terms()` dans les fichiers globaux du thème (en-tête, pied de page, menus)
- Vérification que chacun de ces appels dispose bien d'une durée d'expiration de cache adaptée à sa fréquence de changement réelle
- Ajout d'une purge de cache ciblée lors de la publication d'un nouvel article, via `save_post`
## Prévention : ne jamais laisser un thème interroger la base sans filet
Ce type d'incident se prévient en amont, avant même qu'un pic de trafic ne survienne. Un thème destiné à un site à fort potentiel de viralité — blog, actualité, communiqué de presse — devrait systématiquement passer par un audit de requêtes avant sa mise en production, pas seulement après un incident.
> Faites un test de charge simulé avant chaque mise en production d'un thème pour un client dont le contenu peut devenir viral. Un pic de trafic n'est jamais le bon moment pour découvrir une requête non mise en cache.
## En résumé
Le message « erreur de connexion à la base de données » ne signale pas toujours un problème d'hébergement : il peut tout aussi bien révéler un thème qui multiplie des requêtes redondantes sans aucune mise en cache. Un audit ciblé avec Query Monitor, suivi d'une mise en cache objet des appels les plus fréquents, transforme un site fragile face au succès en un site capable d'absorber un pic sans broncher.