D’après le Codex de la fonction wp_remote_post(), le délai d’attente par défaut d’une requête HTTP sortante déclenchée par WordPress est de cinq secondes. Pour une méthode d’expédition personnalisée qui interroge en temps réel l’API d’un transporteur afin de calculer un tarif exact au moment de la validation du panier, ce chiffre a des conséquences directes sur l’expérience du tunnel de commande : au-delà de cette durée, la requête est interrompue et l’extension doit prévoir un comportement de repli.
Ce billet explique comment fonctionne l’API HTTP de WordPress dans ce contexte, comment ajuster ses délais d’attente correctement, sans entrer dans le choix du transporteur lui-même.
L’API HTTP de WordPress, une couche d’abstraction unique
Plutôt que d’utiliser directement les fonctions cURL de PHP, WordPress fournit une couche d’abstraction commune, wp_remote_get() et wp_remote_post(), qui choisit automatiquement le transport disponible sur le serveur (cURL en priorité, sinon les flux natifs de PHP) et applique un jeu d’arguments par défaut cohérent sur toute l’installation.
Ajuster le délai d’attente pour un appel spécifique
Le délai d’attente se règle via l’argument timeout, passé en secondes dans le tableau d’arguments de la requête. Il ne doit jamais être modifié globalement pour l’ensemble du site, ce qui ralentirait toute autre requête sortante, mais ciblé précisément sur l’appel à l’API du transporteur :
$reponse = wp_remote_post( 'https://api-transporteur.exemple/tarifs', [
'timeout' => 8,
'body' => wp_json_encode( [
'poids' => $poids_colis,
'code_postal' => $code_postal_destination,
] ),
'headers' => [ 'Content-Type' => 'application/json' ],
] );
if ( is_wp_error( $reponse ) ) {
// repli sur un tarif fixe préconfiguré
}Le retour de wp_remote_post() est soit un tableau de réponse, soit un objet WP_Error en cas d’échec, y compris en cas de dépassement du délai d’attente. Tester systématiquement is_wp_error() avant de lire le corps de la réponse évite une notice PHP sur une valeur absente.
Pourquoi allonger le délai n’est pas toujours la bonne réponse
Augmenter le timeout à trente secondes pour « laisser le temps » à une API transporteur lente déplace le problème plutôt que de le résoudre : un client qui valide son panier reste bloqué sur une page de chargement pendant tout ce délai si l’API transporteur ne répond pas. Le bon réflexe consiste à fixer un délai raisonnable, entre cinq et dix secondes, et à prévoir un tarif de repli préconfiguré si l’appel échoue, plutôt que de faire attendre le client indéfiniment.
Mettre en cache les tarifs obtenus
- Mettre en cache la réponse de l’API transporteur pour un couple poids/destination donné, via l’API Transients de WordPress
- Fixer une durée de cache cohérente avec la fréquence de mise à jour réelle des tarifs du transporteur
- Invalider ce cache manuellement en cas de changement connu de grille tarifaire
$cle_cache = 'tarif_transp_' . md5( $poids_colis . $code_postal_destination );
$tarif = get_transient( $cle_cache );
if ( false === $tarif ) {
$tarif = appeler_api_transporteur( $poids_colis, $code_postal_destination );
set_transient( $cle_cache, $tarif, HOUR_IN_SECONDS );
}Ce que dit la documentation officielle sur les arguments par défaut
La page de référence de wp_remote_post() sur developer.wordpress.org liste l’ensemble des arguments disponibles : timeout, redirection, httpversion, blocking. L’argument blocking à false mérite une attention particulière, car il déclenche la requête sans attendre la réponse, ce qui n’a aucun sens pour un calcul de frais de port qui doit être affiché immédiatement au client.
En résumé
Un calcul de frais de port en temps réel dépend d’un service externe dont la latence échappe totalement au contrôle du site. Ajuster précisément le délai d’attente de wp_remote_post(), combiné à un mécanisme de repli et à une mise en cache raisonnable, évite qu’une lenteur ponctuelle du transporteur ne bloque tout le tunnel de commande.
