Publier un article ne devrait jamais être suivi d’un message Slack du type « le nouvel article n’apparaît pas encore, c’est normal ? ». C’est pourtant ce qui se produisait sur un site d’actualités sportives régionales dont le front, un site Next.js consommant l’API REST WordPress, ne se reconstruisait que lorsqu’un développeur pensait à relancer manuellement le build après chaque publication.
Le projet reposait sur une reconstruction intégrale du front à chaque nouvel article, sans revalidation incrémentale, un choix fait à l’origine pour sa simplicité. Le problème ne venait pas de cette architecture en elle-même, mais de l’absence totale de déclenchement automatique entre l’instant de la publication dans WordPress et le lancement du build côté front.
Le point de départ : un hook sur la publication
Le hook natif publish_post constitue le point d’ancrage le plus direct pour instrumenter ce déclenchement, sans dépendre d’une extension tierce ni d’une file d’attente complexe à mettre en place pour un premier jet fonctionnel :
add_action( 'publish_post', 'declencher_build_front_headless', 10, 2 );
function declencher_build_front_headless( $id_article, $article ) {
$reponse = wp_remote_post( 'https://ci.exemple.fr/api/v1/build/declencher', array(
'headers' => array(
'Authorization' => 'Bearer ' . get_option( 'jeton_declenchement_build' ),
'Content-Type' => 'application/json',
),
'body' => wp_json_encode( array( 'id_article' => $id_article ) ),
'timeout' => 5,
) );
if ( is_wp_error( $reponse ) ) {
error_log( 'Échec du déclenchement de build : ' . $reponse->get_error_message() );
}
}
Ce hook se déclenche à chaque publication initiale, mais pas systématiquement à chaque mise à jour d’un article déjà publié : un besoin distinct, traité séparément avec le hook post_updated filtré sur le statut, pour éviter de reconstruire l’ensemble du front à chaque correction typographique mineure.
Sécuriser le point d’entrée côté pipeline
Le point d’entrée qui reçoit cette requête doit vérifier le jeton transmis avant de déclencher quoi que ce soit, faute de quoi n’importe qui découvrant l’URL du déclencheur pourrait lancer des builds à volonté, avec un coût direct en minutes de calcul consommées :
- Un jeton unique, stocké en variable d’environnement côté WordPress et côté pipeline, jamais commité dans le code source.
- Une limite de fréquence sur le déclenchement, pour absorber une rafale de publications programmées à la même minute sans lancer un build par article.
- Un journal des déclenchements horodatés, utile pour diagnostiquer un délai anormal signalé par l’équipe éditoriale.
Regrouper les publications rapprochées en un seul build
Publier trois articles à quelques minutes d’intervalle ne doit pas lancer trois builds complets consécutifs sur un front reconstruit intégralement à chaque fois. Une fenêtre de regroupement courte, de l’ordre d’une minute, absorbe ce cas fréquent lors de sessions de publication groupées :
declencher_build_avec_regroupement() {
dernier_appel=$(cat /tmp/dernier-declenchement 2>/dev/null || echo 0)
maintenant=$(date +%s)
if [ $((maintenant - dernier_appel)) -lt 60 ]; then
echo "Build déjà planifié récemment, on ignore ce déclenchement"
exit 0
fi
echo "$maintenant" > /tmp/dernier-declenchement
npm run build && npm run deploy
}Mesurer le délai réel, pas seulement le supposer
Avant automatisation, l’équipe estimait le délai de mise en ligne « autour de cinq minutes », une estimation approximative qui masquait des écarts importants selon le moment de la journée. Une fois le déclenchement automatisé mis en place, un suivi horodaté entre l’instant de publication WordPress et la disponibilité effective du contenu côté front a permis de mesurer un délai moyen ramené à moins de trois minutes, contre six minutes avec l’ancien processus manuel, incluant le temps de réaction humaine avant même le lancement du build.
Ce que ce déclenchement ne résout pas
Ce mécanisme ne raccourcit pas la durée du build lui-même : un front qui met quatre minutes à se reconstruire intégralement continuera de mettre quatre minutes, que le déclenchement soit manuel ou automatique. Réduire ce temps de build passe par une revalidation incrémentale ou un système de cache plus fin côté front, un chantier distinct de l’automatisation du déclenchement traitée ici.
Automatiser le déclenchement d’un build ne remplace jamais la question de sa durée : les deux problèmes se résolvent séparément, et confondre l’un avec l’autre mène à optimiser le mauvais maillon de la chaîne.
En résumé
Relier la publication d’un article WordPress à la reconstruction automatique d’un front headless ne demande qu’un hook natif, un jeton d’authentification simple et une fenêtre de regroupement pour absorber les publications rapprochées. Le gain se mesure moins en confort qu’en délai réel de mise en ligne, un indicateur qui mérite d’être suivi dans la durée plutôt que supposé une fois pour toutes.
