Un partenaire logistique devait consulter, chaque nuit, l’état des commandes en cours depuis un script batch écrit en Python. La première réaction a été de générer une clé consommateur et un secret WooCommerce classiques depuis WooCommerce › Réglages › Avancé › API REST. Mais le partenaire, pour des raisons internes à son propre système d’information, préférait s’authentifier de façon plus simple, sans gérer de signature OAuth, avec un identifiant qu’il pourrait révoquer lui-même en cas de doute.
La réponse la plus adaptée n’était pas une extension supplémentaire, mais une fonctionnalité du cœur de WordPress lui-même : les mots de passe d’application, intégrés depuis la version 5.6, qui permettent une authentification HTTP Basic classique sur l’ensemble de l’API REST, y compris les points d’accès exposés par WooCommerce.
Étape 1 : vérifier que le site tourne bien en HTTPS
Les mots de passe d’application ne fonctionnent que sur une connexion chiffrée, sauf en environnement de développement local explicitement reconnu comme tel par WordPress. Sans HTTPS valide en production, l’écran de génération n’apparaît tout simplement pas dans le profil utilisateur, ce qui constitue un premier signal de configuration à vérifier avant de chercher plus loin une hypothétique erreur de permission.
Étape 2 : créer un compte dédié au rôle limité
Plutôt que de générer un mot de passe d’application sur le compte administrateur du site, mieux vaut créer un utilisateur dédié à cette intégration, avec le rôle shop_manager si l’accès doit couvrir la gestion des commandes et du catalogue, ou un rôle personnalisé plus restreint si seule la lecture est nécessaire. Cette séparation permet de révoquer l’accès du partenaire sans toucher au compte administrateur, et de suivre précisément, dans les journaux, quelles actions proviennent de cette intégration.
Étape 3 : générer le mot de passe d’application
Depuis l’écran de profil de ce compte dédié (Utilisateurs › Profil), la section « Mots de passe d’application » propose de nommer le mot de passe, par exemple integration-logistique-nuit, avant de cliquer sur « Ajouter un nouveau mot de passe d’application ». WordPress affiche alors la valeur générée une seule fois, sous une forme groupée par blocs de quatre caractères pour faciliter la copie ; il faut la stocker immédiatement dans un gestionnaire de secrets, car elle ne sera plus jamais réaffichée en clair par la suite.
Étape 4 : tester l’authentification en ligne de commande
Un simple appel avec curl permet de valider la configuration avant d’écrire la moindre ligne d’intégration :
curl https://exemple.fr/wp-json/wc/v3/orders \
-u "integration-logistique:xxxx xxxx xxxx xxxx xxxx xxxx"
Le nom d’utilisateur reste celui du compte WordPress, tandis que le mot de passe transmis est bien le mot de passe d’application généré, espaces compris ou non selon l’implémentation cliente ; la plupart des bibliothèques HTTP acceptent les deux formats indifféremment.
Étape 5 : implémenter l’appel depuis un script PHP
Pour une intégration interne écrite en PHP, la même authentification HTTP Basic s’implémente sans bibliothèque tierce, avec wp_remote_get() si le script tourne dans un contexte WordPress, ou une requête HTTP classique sinon :
$identifiants = base64_encode( 'integration-logistique:xxxxxxxxxxxxxxxxxxxxxxxx' );
$reponse = wp_remote_get( 'https://exemple.fr/wp-json/wc/v3/orders?status=processing', array(
'headers' => array(
'Authorization' => 'Basic ' . $identifiants,
),
) );
if ( ! is_wp_error( $reponse ) && 200 === wp_remote_retrieve_response_code( $reponse ) ) {
$commandes = json_decode( wp_remote_retrieve_body( $reponse ), true );
}
Ce que ce mode d’authentification ne remplace pas
Les mots de passe d’application ne conviennent pas à tous les usages. Ils s’appuient sur les permissions du compte WordPress utilisé pour se connecter, sans granularité fine par point d’accès comme le permettent les clés consommateur WooCommerce, qui distinguent lecture seule et lecture-écriture au moment de leur création. Pour une intégration nécessitant des permissions très précises, ou pour un usage massif côté place de marché, les clés consommateur restent souvent le choix le plus adapté.
- Toujours nommer explicitement chaque mot de passe d’application généré, pour identifier immédiatement l’intégration concernée en cas de révocation d’urgence.
- Vérifier régulièrement, depuis l’écran de profil, la date de dernière utilisation affichée à côté de chaque mot de passe d’application, un bon indicateur d’une intégration devenue obsolète.
- Ne jamais partager un mot de passe d’application par mail en clair, même en interne : un lien vers un gestionnaire de secrets partagé reste la bonne pratique.
Un mot de passe d’application révoqué en un clic, sans toucher au mot de passe principal du compte, vaut largement l’effort de créer un utilisateur dédié pour chaque intégration externe, même quand le partenaire semble de confiance au départ.
En résumé
Pour une intégration simple en lecture ou en écriture standard sur l’API REST WooCommerce, les mots de passe d’application évitent d’introduire une dépendance supplémentaire ou une gestion de signature complexe, tout en restant révocables individuellement. Le partenaire logistique a pu brancher son script batch en moins d’une heure, avec un compte dédié qu’il suffira de désactiver le jour où la collaboration prendra fin, sans jamais avoir eu accès au compte administrateur du site.
