wp postmark:stats --domaine=exemple.fr --jours=7 : cette commande n’existe dans aucune extension du dépôt officiel, mais elle peut être écrite en une trentaine de lignes de PHP pour qui gère plusieurs sites sous Postmark et veut éviter d’ouvrir un tableau de bord différent pour chacun d’eux.
Postmark expose une API REST complète pour consulter les statistiques de livraison, mais son interface web, pensée pour un compte à la fois, devient vite un point de friction dès qu’une agence supervise plusieurs domaines d’envoi. L’idée : ramener cette information dans le terminal, au même endroit que les autres commandes d’exploitation quotidienne.
Créer une commande wp-cli personnalisée
WP-CLI permet d’enregistrer une commande personnalisée depuis un plugin ou un fichier chargé via wp-cli.yml, en s’appuyant sur WP_CLI::add_command(). La commande a besoin d’une classe qui implémente la logique d’appel à l’API Postmark et formate le résultat pour un affichage lisible en terminal.
class Postmark_Stats_Command {
public function stats( $args, $assoc_args ) {
$token = getenv( 'POSTMARK_SERVER_TOKEN' );
$jours = $assoc_args['jours'] ?? 7;
$response = wp_remote_get(
'https://api.postmarkapp.com/stats/outbound/bounces?count=100',
array(
'headers' => array(
'X-Postmark-Server-Token' => $token,
'Accept' => 'application/json',
),
)
);
if ( is_wp_error( $response ) ) {
WP_CLI::error( $response->get_error_message() );
}
$data = json_decode( wp_remote_retrieve_body( $response ), true );
WP_CLI::log( sprintf( 'Rebonds sur %d jours : %d', $jours, $data['TotalCount'] ?? 0 ) );
}
}
WP_CLI::add_command( 'postmark', new Postmark_Stats_Command() );Étape 1 : préparer les jetons d’API par domaine
Chaque domaine d’envoi Postmark dispose de son propre jeton de serveur. Pour couvrir un parc de plusieurs sites, la commande doit accepter un paramètre identifiant le domaine et retrouver le bon jeton, stocké dans une variable d’environnement ou un fichier de configuration séparé du dépôt de code, jamais commité.
Étape 2 : interroger les trois métriques utiles
Trois appels à l’API suffisent pour couvrir l’essentiel de la supervision quotidienne : le nombre de rebonds (/stats/outbound/bounces), le taux d’ouverture agrégé (/stats/outbound/opens) et le nombre d’envois totaux (/stats/outbound). Multiplier les appels au-delà de ces trois métriques alourdit la commande sans apporter d’information réellement actionnable au quotidien.
Étape 3 : fixer des seuils d’alerte adaptés au parc
Un taux de rebond acceptable pour un site n’a pas la même signification pour tous les projets d’un parc : un site e-commerce avec des adresses clientes ponctuelles tolère un taux plus élevé qu’une newsletter à base d’abonnés fidèles. La commande gagne à accepter un seuil configurable par domaine plutôt qu’un seuil unique appliqué à l’ensemble du parc.
- Un taux de rebond supérieur à 5 % mérite une vérification manuelle de la liste d’envoi.
- Un taux supérieur à 10 % justifie une alerte immédiate, le domaine d’envoi risquant une mise en liste noire.
- Une baisse brutale du taux d’ouverture peut signaler un problème d’authentification (SPF, DKIM) plutôt qu’un désintérêt des destinataires.
Étape 4 : automatiser l’exécution régulière
Une fois la commande fiable, elle s’intègre à une tâche planifiée du serveur qui l’exécute chaque matin pour l’ensemble des domaines du parc, avec une sortie au format JSON via l’option native --format=json de WP-CLI, réutilisable par un script de notification existant.
wp postmark stats --domaine=exemple.fr --jours=7 --format=jsonUne métrique qu’on ne consulte jamais n’a aucune valeur, même si l’API qui la fournit est irréprochable.
En résumé
Une commande wp-cli personnalisée qui interroge Postmark ramène la supervision de la délivrabilité au même endroit que le reste de l’exploitation d’un parc de sites, sans multiplier les onglets de tableau de bord. La configuration DNS de délivrabilité reste un sujet distinct, à traiter en amont : cette commande suppose que SPF, DKIM et DMARC sont déjà correctement en place sur chaque domaine.
