Page mise à jour le
Ce que l'API permet
Ce que WooCommerce expose réellement
Repris de la documentation publique de l'éditeur, pas d'une plaquette commerciale. Le lien vers cette documentation est en bas de page.
Lire et écrire commandes, produits et clients
La documentation v3 décrit la création, la lecture, la mise à jour et la suppression des commandes, des produits (y compris variations et catégories), des clients, des coupons et des remboursements. Une commande reçue peut donc partir vers la compta ou l'atelier sans ressaisie, et un stock corrigé ailleurs peut revenir sur la fiche produit. Les listes arrivent par pages de dix éléments par défaut ; au-delà, il faut enchaîner les pages. Les montants reviennent en texte à deux décimales, pas en nombre, ce qui évite les arrondis silencieux.
Être prévenu dès qu'une commande change
WooCommerce peut envoyer une notification vers une adresse que vous contrôlez à chaque sujet souscrit : création, mise à jour, suppression d'une commande, d'un produit, d'un client. C'est ce qui permet de réagir tout de suite au lieu d'interroger la boutique toutes les cinq minutes. Les livraisons sont journalisées côté boutique, ce qui sert à diagnostiquer un envoi manqué. Sans cette notification, on peut toujours lire les commandes, mais on les découvre en retard — exactement le décalage que l'automatisation est censée supprimer.
Clés d'accès liées à un compte WordPress
Les clés se créent dans WooCommerce > Réglages > Avancé > REST API, pour un utilisateur WordPress précis, en lecture, écriture, ou les deux. Les droits de la clé suivent ceux de cet utilisateur : si le compte n'a pas le droit de modifier un produit, la clé non plus. Si l'utilisateur est supprimé, la clé cesse de fonctionner et n'est pas transférée. C'est une contrainte de sécurité utile, et une source d'incident classique quand on « nettoie » des comptes WordPress sans regarder les intégrations.
Notes de commande et actions d'envoi
On peut ajouter une note interne à une commande, relire l'historique, et déclencher l'envoi du détail ou d'une notification au client depuis l'API. Utile pour tracer ce qu'un agent a fait — « stock vérifié, colis préparé » — sans ouvrir l'admin. Ce n'est pas un fil de discussion avec le client : c'est le journal de la commande, celui qu'on relit six semaines plus tard quand un litige arrive.
Documentation de l'API REST WooCommerce v3 (nouvel onglet) — Référence officielle v3 : commandes, produits, clients, webhooks, clés. Consultée le 21-08-2026. Les permaliens personnalisés y sont exigés ; HTTPS y est recommandé.
Trois automatisations concrètes
Ce qu'on met en place avec
Trois situations réelles, décrites comme du travail plutôt que comme de la technique.
Facturer sans retaper la commande
À chaque commande payée, un agent lit le numéro, les lignes, l'adresse et le total, puis prépare la facture dans votre outil de compta. Il ne l'envoie pas tout seul si un avoir ou un litige est en cours : il vous la présente. Le paiement déjà encaissé par la boutique n'est pas réclamé une seconde fois. La boutique reste la source de la vente ; la compta reste la source de la facture.
Tenir le stock à deux endroits sans se tromper
Quand un produit part, la quantité disponible ailleurs — entrepôt, tableur, ERP — doit baisser. L'agent écrit la nouvelle quantité dans WooCommerce, ou l'inverse selon l'endroit qui fait foi. Un écart de stock n'est pas tranché automatiquement : il est isolé et remonté. Deux sources qui « gagnent » en même temps finissent par vendre ce que vous n'avez plus.
Prévenir l'atelier sans ouvrir l'admin
Une commande « en cours » déclenche un message vers l'atelier ou le canal d'équipe, avec les lignes et le délai annoncé. Quand le statut passe à expédié, le client reçoit le suivi ; l'agent s'arrête. Si le transporteur renvoie un incident, le dossier reprend plutôt qu'un second message identique. L'atelier n'a pas à se connecter à WordPress pour savoir quoi préparer ce matin.
Limites
Ce que cette intégration ne fera pas
Les contraintes qu'on rencontre pour de vrai. Les découvrir maintenant coûte une lecture ; les découvrir en cours de projet coûte le projet.
Les permaliens par défaut bloquent l'accès
La documentation officielle est nette : les permaliens WordPress par défaut ne suffisent pas. Il faut des permaliens personnalisés, WooCommerce 3.5 ou plus, WordPress 4.4 ou plus. Un hébergement qui coupe certaines méthodes HTTP, ou un pare-feu du type ModSecurity mal réglé, renvoie des erreurs 501. Avant de construire quoi que ce soit, on vérifie qu'un appel authentifié à la boutique répond. Sinon le projet s'arrête au premier test.
La boutique ne connaît pas votre compta
WooCommerce sait qu'une commande est payée selon son propre statut, pas selon le virement arrivé sur votre compte. Un paiement hors boutique, un avoir partiel, une commande recréée à la main : l'API les transmet tels quels. Relier la boutique à la compta sans règle de rapprochement, c'est recopier des statuts, pas tenir une caisse. La règle se décide chez vous, pas chez WooCommerce.
Ce que tiennent les extensions n'est pas garanti
L'API documentée couvre le cœur WooCommerce. Un champ ajouté par une extension de livraison, de facturation française ou de points de fidélité n'apparaît que si cette extension l'expose. Beaucoup ne le font pas. On le vérifie produit par produit plutôt que de promettre « tout ce qui est à l'écran ». Les données visibles dans l'admin et les données accessibles depuis l'extérieur sont deux listes distinctes.
Ce que brancher WooCommerce demande vraiment
Une clé en lecture suffit pour observer. Écrire des commandes ou des stocks demande une clé d'écriture, un compte WordPress qui ne sera pas supprimé par inadvertance, et un HTTPS qui tient. On commence par un flux unique — commande payée vers facture, ou stock vers boutique — et on n'ajoute le suivant que lorsque le premier a tenu une semaine sans doublon. Le travail n'est pas d'installer un connecteur : c'est de décider quelle source gagne quand les deux désaccordent.
Vos questions
Faut-il quitter WordPress pour automatiser la boutique ?
Non. L'intérêt de WooCommerce est précisément qu'on s'y branche sans migrer le catalogue. Changer de boutique, c'est reprendre les produits, les commandes, les comptes clients et les habitudes de l'équipe — trois coûts que l'automatisation ne remplace pas. On ne recommande un changement que si la boutique n'expose aucun moyen d'accès fiable, ce qui n'est pas le cas ici dès que les permaliens sont corrects et qu'une clé existe. La question utile n'est pas « quel CMS » mais « quelle information doit sortir de la boutique, et vers où ».
Une commande payée part-elle toute seule en comptabilité ?
Techniquement, l'API permet de lire la commande au moment où son statut change, et d'en créer la facture ailleurs. Décider de l'envoyer sans relecture est un choix de métier, pas une obligation de l'outil. Un avoir en cours, un client qui a déjà un compte, un paiement hors boutique : trois cas où partir tout seul crée un doublon ou une relance injuste. Le réglage sain est de préparer la pièce et de ne passer en envoi automatique que le palier que vous avez vu fonctionner tel quel, sur des cas réels.
Que se passe-t-il si un plugin ajoute des champs ?
Ces champs restent dans WordPress tant que l'extension ne les publie pas dans l'API. Beaucoup d'extensions françaises de facturation ou de points relais tiennent leurs données à part. Avant de promettre une synchro « complète », on liste les champs dont vous avez besoin et on vérifie, un par un, s'ils sortent. Ceux qui ne sortent pas se récupèrent autrement — export, table dédiée, ou on les laisse dans la boutique. Inventer qu'ils sont disponibles fait échouer le projet au milieu.
Une idée en tête ?
Réservez un rendez-vous ou écrivez-nous — réponse sous 24 h.