Webhooks de publication : déclencher un rebuild Netlify ou Vercel

Sur un site JAMstack généré à partir de contenus WordPress, la question revient systématiquement en fin de projet : comment le site se met-il à jour quand un auteur publie un article ? Sans mécanisme dédié, la réponse est simple et décevante : il ne se met pas à jour du tout, le HTML ayant été généré une fois pour toutes au moment du build. Le webhook de publication comble ce manque, en notifiant la plateforme d’hébergement dès qu’un contenu change.

Cet article couvre la mise en place du webhook côté WordPress, le filtrage des événements pertinents, et la prévention des rafales de builds sur les sites à publication fréquente — sans entrer dans le sujet voisin, mais distinct, de l’ISR (régénération incrémentale), qui évite justement d’avoir à reconstruire le site entier.

Créer le webhook côté Netlify ou Vercel

Les deux plateformes proposent un « Build Hook » : une URL unique, à usage interne, qui déclenche un nouveau build dès qu’elle reçoit une requête POST. Sur Netlify, cette URL se génère depuis les paramètres de build du site (Site settings → Build & deploy → Build hooks) et ressemble à :

https://api.netlify.com/build_hooks/60f1a2b3c4d5e6f7a8b9c0d1

Sur Vercel, le principe est identique via Project Settings → Git → Deploy Hooks, avec une URL de la forme https://api.vercel.com/v1/integrations/deploy/.... Dans les deux cas, l’URL doit rester secrète : quiconque la connaît peut déclencher un build, sans authentification supplémentaire.

Déclencher le webhook depuis WordPress

Le hook transition_post_status est le plus fiable pour détecter une publication, car il capture tous les changements de statut, y compris une republication après dépublication, ce que publish_post seul ne couvre pas toujours correctement.

add_action( 'transition_post_status', function ( $new_status, $old_status, $post ) {
    if ( 'publish' !== $new_status || 'publish' === $old_status ) {
        return;
    }

    if ( ! in_array( $post->post_type, array( 'post', 'page', 'product' ), true ) ) {
        return;
    }

    wp_remote_post( 'https://api.netlify.com/build_hooks/60f1a2b3c4d5e6f7a8b9c0d1', array(
        'timeout'  => 5,
        'blocking' => false,
    ) );
}, 10, 3 );

Le paramètre blocking => false évite de faire attendre l’auteur pendant que la requête HTTP part vers Netlify : l’enregistrement de l’article dans l’administration ne doit jamais être ralenti par un appel réseau externe.

Filtrer les événements pour éviter les builds inutiles

Sans filtrage, chaque enregistrement automatique de brouillon (WordPress en effectue régulièrement pendant la rédaction) ou chaque modification mineure peut déclencher un build complet, coûteux en temps et parfois facturé au nombre de minutes de build selon le plan choisi.

• Ne déclencher que sur une transition explicite vers publish, jamais sur un simple save_post qui se déclenche à chaque sauvegarde de brouillon.
• Restreindre aux types de contenu réellement affichés sur le site statique (exclure les CPT internes ou les formulaires, par exemple).
• Ignorer les mises à jour mineures si le projet dispose d’un système de statut de révision, pour ne pas rebuilder à chaque correction typographique postérieure à la publication.

Éviter les rafales de builds

Sur un site à plusieurs auteurs, il n’est pas rare que trois ou quatre articles soient publiés à quelques minutes d’intervalle, ce qui déclencherait autant de builds complets si rien ne les regroupe. La solution la plus simple consiste à différer légèrement le déclenchement via un événement planifié WP-Cron, avec un anti-rebond basé sur un transient :

function monsite_planifier_rebuild() {
    if ( ! wp_next_scheduled( 'monsite_declencher_rebuild' ) ) {
        wp_schedule_single_event( time() + 120, 'monsite_declencher_rebuild' );
    }
}
add_action( 'monsite_publication_detectee', 'monsite_planifier_rebuild' );

add_action( 'monsite_declencher_rebuild', function () {
    wp_remote_post( 'https://api.netlify.com/build_hooks/60f1a2b3c4d5e6f7a8b9c0d1', array(
        'timeout'  => 5,
        'blocking' => false,
    ) );
} );

wp_next_scheduled() garantit qu’un seul événement de rebuild est en attente à la fois : si trois publications surviennent en deux minutes, une seule tâche planifiée déclenche un unique build, deux minutes après la première publication du lot.

Un point d’attention : la fiabilité de WP-Cron

WP-Cron ne s’exécute qu’au chargement d’une page du site, pas selon un vrai calendrier système. Sur un site à faible trafic, la tâche planifiée peut donc se déclencher avec un retard notable. Pour un site où la fraîcheur du build compte, je préfère désactiver DISABLE_WP_CRON et déclencher WP-Cron via une tâche cron système réelle toutes les minutes, garantissant une exécution régulière indépendante du trafic.

Le webhook de publication est un mécanisme volontairement simple : il ne sait pas ce qui a changé, seulement qu’il faut reconstruire. Sur un catalogue de plusieurs milliers de pages, ce manque de granularité devient vite le principal argument pour passer à une régénération incrémentale plutôt qu’à un rebuild complet systématique.

En résumé

Un webhook de publication déclenché depuis transition_post_status, filtré sur les bons statuts et types de contenu, puis différé de quelques minutes pour absorber les rafales, couvre la majorité des besoins d’un site statique à publication modérée. Au-delà d’un certain volume de contenus ou d’une fréquence de publication élevée, le coût d’un rebuild complet pousse naturellement vers des solutions de régénération plus ciblées.