wp deploy theme — la commande existait déjà sur nos projets, mais elle s’arrêtait toujours au même endroit : le nouveau CSS était bien sur le serveur, et pourtant les visiteurs continuaient à voir l’ancienne mise en page pendant de longues minutes. La cause n’était jamais le serveur d’origine, mais le cache du CDN placé devant lui, qui continuait de servir une version périmée des fichiers statiques.
Ce point de friction revenait à chaque déploiement un peu pressé : le développeur teste en navigation privée pour contourner son propre cache navigateur, valide, referme son terminal, et oublie la case « purger Cloudflare ». Nous avons fini par intégrer cette purge directement dans la commande de déploiement plutôt que de compter sur la mémoire de chacun.
Comprendre ce qui bloque réellement
Cloudflare, comme la plupart des CDN, met en cache les ressources statiques (CSS, JS, images) selon des règles de cache définies par en-têtes HTTP ou par des règles de page configurées côté tableau de bord. Un déploiement qui modifie le contenu d’un fichier sans changer son nom — un style.css qui reste style.css — laisse le CDN convaincu qu’il n’y a rien de neuf à récupérer.
Deux solutions existent : renommer systématiquement les fichiers avec un hash de version (ce que fait wp_enqueue_style avec un numéro de version en paramètre), ou purger explicitement le cache après chaque déploiement. Sur un thème qui n’utilise pas encore de système de build avec hash automatique, la purge reste la solution la plus rapide à mettre en place.
Créer une commande WP-CLI personnalisée
Plutôt que d’appeler l’API Cloudflare à la main avec curl après chaque mise à jour, nous avons écrit une commande personnalisée enregistrée via WP_CLI::add_command :
// mu-plugins/wpcli-cloudflare-purge.php
if ( defined( 'WP_CLI' ) && WP_CLI ) {
WP_CLI::add_command( 'cloudflare purge', function( $args, $assoc_args ) {
$zone_id = getenv( 'CF_ZONE_ID' );
$token = getenv( 'CF_API_TOKEN' );
$response = wp_remote_post(
"https://api.cloudflare.com/client/v4/zones/{$zone_id}/purge_cache",
[
'headers' => [
'Authorization' => "Bearer {$token}",
'Content-Type' => 'application/json',
],
'body' => wp_json_encode( [ 'purge_everything' => true ] ),
]
);
if ( is_wp_error( $response ) ) {
WP_CLI::error( $response->get_error_message() );
}
WP_CLI::success( 'Cache Cloudflare purgé.' );
} );
}
Enchaîner déploiement et purge dans un seul script
Le script de déploiement, exécuté après un rsync vers le serveur de production, se termine désormais par un appel à cette nouvelle commande :
rsync -avz --delete ./dist/ user@serveur:/var/www/site/wp-content/themes/theme-client/ssh user@serveur "wp cache flush --path=/var/www/site"pour vider le cache objet WordPress.ssh user@serveur "wp cloudflare purge --path=/var/www/site"pour vider le cache CDN.
Un seul script, une seule commande à lancer, et plus aucune purge oubliée depuis sa mise en place sur nos projets utilisant Cloudflare comme CDN devant WordPress.
Restreindre la purge aux ressources modifiées
Purger la totalité du cache à chaque déploiement fonctionne, mais cela génère un pic de trafic direct vers le serveur d’origine pendant quelques secondes, le temps que le CDN reconstitue son cache. Sur un site à fort trafic, nous préférons cibler uniquement les fichiers modifiés grâce au paramètre files de l’API :
'body' => wp_json_encode( [
'files' => [
'https://exemple.fr/wp-content/themes/theme-client/style.css',
'https://exemple.fr/wp-content/themes/theme-client/script.js',
],
] ),
Cette approche ciblée réduit la charge sur l’origine tout en garantissant que les visiteurs voient immédiatement la nouvelle version des fichiers concernés.
Limites à connaître
- Le compte Cloudflare doit disposer d’un jeton d’API avec les droits de purge du cache, distinct du jeton global du compte pour limiter les risques en cas de fuite.
- La propagation d’une purge sur l’ensemble du réseau Cloudflare prend un peu de temps, de l’ordre de quelques dizaines de secondes, ce qui reste largement acceptable pour un déploiement planifié.
- Purger trop souvent le cache complet d’un site à fort trafic peut créer une charge ponctuelle sur le serveur d’origine, à surveiller si les déploiements sont fréquents.
En résumé
Une purge de cache CDN oubliée coûte souvent plus cher en confusion côté client (« votre mise à jour ne s’affiche pas ! ») que le temps nécessaire pour l’automatiser. Intégrer cet appel directement dans la commande de déploiement WP-CLI supprime ce point de friction une fois pour toutes.
