Douze heures : c’est l’intervalle par défaut auquel WordPress vérifie, pour chaque site, la disponibilité d’une nouvelle version du cœur, des extensions et des thèmes installés. Ce mécanisme, invisible pour l’administrateur d’un site isolé, devient un poste de charge à part entière lorsqu’il est multiplié par mille sites hébergés sur la même infrastructure.
Ce billet détaille ce que ce mécanisme représente concrètement pour un hébergeur qui dimensionne sa capacité sortante, sans entrer dans la configuration individuelle d’un site pour le désactiver, un sujet déjà traité par ailleurs sous l’angle de la personnalisation d’un site unique.
Le mécanisme de vérification, tel qu’il fonctionne réellement
WordPress planifie, via le système de tâches cron interne, un événement wp_version_check qui interroge l’API https://api.wordpress.org/core/version-check/ pour connaître la dernière version stable du cœur. Deux tâches complémentaires, wp_update_plugins et wp_update_themes, effectuent le même type d’appel respectivement vers api.wordpress.org/plugins/update-check/ et api.wordpress.org/themes/update-check/, en transmettant la liste des extensions et thèmes installés sur le site.
Ces trois événements sont programmés par défaut à un intervalle de douze heures via le hook twicedaily, mais leur déclenchement effectif dépend du système de cron WordPress, lui-même déclenché à chaque visite d’un site si aucun cron système n’a été configuré en remplacement. Sur un parc mutualisé où beaucoup de sites reçoivent un trafic irrégulier, ce détail change la répartition réelle de la charge dans le temps : les appels ne sont pas uniformément répartis sur la journée, ils se concentrent aux heures de plus fort trafic.
Ce que représente ce trafic à l’échelle d’un hébergeur
Sur un parc de mille sites actifs, en comptant une moyenne de deux appels sortants complets par site et par jour (cœur, extensions, thèmes regroupés dans le même appel dans la majorité des cas), l’infrastructure gère environ deux mille requêtes HTTPS sortantes quotidiennes vers les serveurs de l’API officielle. Chaque appel ouvre une connexion TLS, attend une réponse JSON, puis la traite côté PHP avant de la stocker en transitoire dans la base de données via l’option update_core, update_plugins ou update_themes.
Ce trafic reste modeste en bande passante brute, mais il pèse sur trois ressources moins visibles : le nombre de connexions sortantes simultanées autorisées par le pare-feu ou le proxy sortant, le temps de traitement PHP consommé pendant l’attente de la réponse de l’API, et le volume d’écritures en base de données généré par la mise à jour des options de transitoires à chaque cycle.
Un effet cumulatif plus qu’un pic ponctuel
Contrairement à un pic de trafic entrant provoqué par une campagne marketing, cette charge est diffuse et permanente. Elle ne provoque pas d’incident isolé facilement identifiable, mais elle occupe en permanence une part de la capacité sortante et des ressources PHP du serveur, part qui n’est plus disponible pour servir des visiteurs réels.
- Sur un serveur qui exécute le cron WordPress via une requête HTTP interne à chaque visite, chaque déclenchement de
wp_version_checkajoute un aller-retour PHP supplémentaire à une requête qui, sans cela, aurait été plus rapide. - Le stockage des résultats en transitoire dans
wp_optionsajoute des lignes qui, cumulées sur mille sites, gonflent une table déjà sensible aux performances de lecture sur un mutualisé. - Un serveur DNS ou un proxy sortant mal dimensionné peut se retrouver, lui, réellement saturé si les intervalles de vérification de plusieurs centaines de sites convergent par hasard vers les mêmes plages horaires.
Ce que les hébergeurs de grande taille mettent en place
Plutôt que d’agir site par site, un hébergeur qui gère plusieurs milliers d’installations WordPress a intérêt à raisonner au niveau de l’infrastructure de sortie : dimensionner le proxy sortant ou le pare-feu applicatif pour absorber ce trafic prévisible, et surveiller son évolution dans le temps à mesure que le parc grandit, plutôt que de le découvrir a posteriori lors d’un incident de saturation.
| Ressource impactée | Effet observé à mille sites |
|---|---|
| Connexions sortantes simultanées | Pic notable aux heures de forte affluence du parc |
| Temps PHP consommé par requête cron interne | Quelques dizaines de millisecondes ajoutées par déclenchement |
| Volume de la table wp_options | Croissance continue liée aux transitoires de mise à jour |
Un mécanisme invisible sur un site isolé peut devenir un poste de charge mesurable dès lors qu’il est multiplié par plusieurs centaines d’installations sur la même infrastructure.
En résumé
Le mécanisme de vérification des mises à jour de WordPress n’est ni un défaut ni une anomalie : il fait partie du fonctionnement normal du cœur, et il est nécessaire à la sécurité du parc. Mais sa multiplication par mille sites en fait un poste de charge à part entière pour l’infrastructure d’un hébergeur, qui gagne à le surveiller et à le dimensionner en amont plutôt qu’à le découvrir lors d’un pic de saturation sortante inexpliqué.
