Un webhook est un simple point d’entrée HTTP que l’on expose pour que d’autres services notifient une extension en temps réel, plutôt que de la faire interroger elle-même régulièrement une API tierce. La question n’est pas de savoir si Zapier ou Make font bien leur travail — ils le font très bien — mais à partir de quel volume, de quelle criticité ou de quel besoin de contrôle il devient plus pertinent de s’en passer et d’exposer sa propre route.
Cette décision revient régulièrement sur des projets d’extension métier connectés à un CRM, un outil de facturation ou une plateforme d’automatisation externe. Zapier et Make simplifient énormément la mise en relation de deux systèmes sans écrire de code d’intégration — mais cette simplicité a un coût, en argent et parfois en fiabilité, qu’il vaut mieux évaluer avant de s’y engager durablement.
Comment fonctionnent réellement ces outils d’automatisation
Zapier et Make (anciennement Integromat) reposent sur deux mécanismes de déclenchement : le webhook entrant, où le service tiers notifie directement Zapier ou Make dès qu’un événement se produit, et le polling, où l’outil interroge régulièrement une API à intervalle fixe (souvent une à quinze minutes selon le plan tarifaire) pour détecter un changement. La plupart des intégrations « prêtes à l’emploi » avec WordPress passent par du polling, faute de webhook natif exposé par le CMS pour chaque type d’événement.
Cette latence de polling, invisible pour un usage marketing (synchronisation de contacts, par exemple), devient gênante pour un usage transactionnel : un client qui valide une commande et attend une confirmation immédiate ne devrait pas dépendre d’un cycle de vérification de plusieurs minutes.
Le vrai coût caché : la facturation à la tâche
Zapier facture au nombre de « tâches » exécutées par mois, Make au nombre d’« opérations ». Un flux qui semble simple — recevoir une commande, créer un contact CRM, envoyer une notification Slack, mettre à jour une feuille de calcul — peut consommer quatre tâches par exécution. Multiplié par un volume de commandes qui grossit avec le succès du client, la facture suit une pente bien plus raide que prévu au moment du choix initial de l’outil.
Exposer sa propre route REST comme alternative
Quand le flux devient central au métier du client, ou que son volume dépasse quelques centaines d’événements mensuels, exposer un point d’entrée REST maison reprend la main sur la latence et le coût :
add_action( 'rest_api_init', function () {
register_rest_route( 'commande/v1', '/webhook-crm', array(
'methods' => 'POST',
'callback' => 'commande_recevoir_webhook_crm',
'permission_callback' => 'commande_verifier_signature_webhook',
) );
} );
function commande_verifier_signature_webhook( WP_REST_Request $request ) {
$signature_recue = $request->get_header( 'x-signature' );
$corps = $request->get_body();
$signature_calculee = hash_hmac( 'sha256', $corps, WEBHOOK_SECRET );
return hash_equals( $signature_calculee, $signature_recue );
}
function commande_recevoir_webhook_crm( WP_REST_Request $request ) {
$donnees = $request->get_json_params();
// Traitement immédiat, sans polling ni file d'attente tierce.
do_action( 'commande_evenement_crm_recu', $donnees );
return new WP_REST_Response( array( 'statut' => 'recu' ), 200 );
}La vérification de signature via hash_hmac() est indispensable : un point d’entrée webhook exposé publiquement, sans authentification, devient une porte ouverte pour injecter de fausses données dans le système.
Quand garder Zapier ou Make malgré tout
La bascule vers du code maison n’est pas systématiquement justifiée. Zapier ou Make restent le bon choix quand :
- Le flux connecte des dizaines d’outils différents et change fréquemment au gré des besoins métier, sans budget de développement dédié.
- Le volume reste faible et ne justifie pas le coût de maintenance d’un code d’intégration propre.
- Les personnes qui pilotent le flux ne sont pas des développeurs et doivent pouvoir modifier la logique elles-mêmes via une interface visuelle.
- Le besoin est temporaire ou expérimental, avant de valider qu’un flux mérite un investissement plus poussé.
Un critère de décision simple
La question à poser n’est pas « Zapier ou code maison », mais « qu’est-ce qui coûterait le plus cher si ce flux tombait en panne pendant une heure, un jour, une semaine ? ». Pour un flux marketing de synchronisation de newsletter, une panne d’une heure ne change rien. Pour une confirmation de commande ou un flux de facturation, chaque minute de latence ou d’indisponibilité a un coût direct, ce qui penche nettement vers un webhook maîtrisé en interne.
Un outil no-code n’est jamais un problème en soi : le problème apparaît quand un flux critique dépend d’un service qu’on ne maîtrise pas et qu’on paie à la tâche.
Ce qu’il faut retenir
Zapier et Make restent d’excellents choix pour prototyper une intégration ou connecter des outils périphériques sans écrire de code. Dès qu’un flux devient critique pour le métier du client, avec un volume conséquent ou une exigence de latence faible, exposer une route REST personnalisée, sécurisée par signature, redonne le contrôle sur la fiabilité et le coût à long terme — au prix d’une maintenance qui devient alors la responsabilité de l’équipe technique, plus de celle d’un service tiers.
