API sur site autonome : REST API, Webhook et intégration de systèmes tiers
1. WordPress REST API : comprendre d’abord les capacités par défaut
Depuis la version 4.7, WordPress intègre nativement le REST API, sans plugin. Le format des endpoints est https://votre-domaine/wp-json/wp/v2/posts : ouvrez-le dans un navigateur pour voir la liste des articles au format JSON. Cette API est publique par défaut : n’importe qui peut lire vos articles, vos pages et votre bibliothèque de médias. C’est à la fois un avantage (intégration facile) et un risque (exposition de données internes).
Les opérations d’écriture (créer un article, modifier une commande, ajouter un utilisateur) exigent une authentification. WordPress prend en charge deux méthodes : les mots de passe d’application (Application Passwords, simples, générés dans le profil utilisateur, adaptés aux appels depuis votre propre serveur) et OAuth 2.0 (complexe, adapté à l’autorisation d’applications tierces). Pour connecter votre site à votre propre CRM, les mots de passe d’application suffisent. Ne codez pas en dur le mot de passe du compte admin dans le code pour aller plus vite.
Cadre de décision : devez-vous lire ou écrire des données dans WordPress ? En lecture seule (liste d’articles, historique de commandes), une requête GET avec un mot de passe d’application suffit. En écriture (créer une commande, mettre à jour un utilisateur, envoyer un Webhook), il faut des requêtes POST/PUT, avec des droits minimaux : par exemple, accordez uniquement le droit « modifier les commandes », pas « gérer tous les réglages ». Pour choisir votre stack technique, voir Stack technique crater.
| Endpoint | Méthode | Utilité | Exigences de certification |
|---|---|---|---|
| /wp-json/wp/v2/posts | GET | Lire la liste des articles | Public (publiés) |
| /wp-json/wp/v2/posts | POST | Créer un article | Mot de passe d’application |
| /wp-json/wc/v3/orders | GET | Lire les commandes WooCommerce | Clé client |
| /wp-json/wc/v3/orders | POST | Créer une commande | Clé client |
| /wp-json/wp/v2/users | GET | Lire la liste des utilisateurs | Mot de passe administrateur |
| /wp-json/wp/v2/media | POST | Téléverser une image | Modifier les mots de passe ci-dessus |
2. Webhook : les notifications en temps réel pilotées par les événements
Un Webhook et une API REST, c’est la même chose mais dans l’autre sens. Avec REST, c’est vous qui allez chercher les données sur le serveur distant. Avec un Webhook, c’est le serveur distant qui pousse les données vers vous dès qu’un événement se produit. Par exemple, quand WooCommerce reçoit une nouvelle commande, il envoie une requête POST à l’URL que vous avez renseignée dans la configuration du Webhook, avec le détail de la commande en JSON dans le body. Plus besoin d’interroger le serveur toutes les minutes pour savoir s’il y a une nouvelle commande : elle arrive automatiquement.
WooCommerce prend en charge les Webhooks nativement. Ajoutez-en un dans WooCommerce → Réglages → Avancé → Webhooks. Vous devez renseigner : l’événement déclencheur (création de commande, mise à jour de commande, annulation de commande), l’URL de réception (un endpoint sur votre propre serveur, par exemple https://votre-domaine/wp-json/custom/v1/new-order) et la méthode de signature (HMAC-SHA256, avec une clé secrète pour vérifier que la requête vient bien de WooCommerce et non d’un tiers malveillant).
Un constat contre-intuitif :Si un Webhook échoue, vous ne le savez probablement jamais. Quand WooCommerce envoie un Webhook et que votre serveur répond 500, il réessaie plusieurs fois (5 tentatives maximum par défaut, avec un intervalle croissant). Mais si les 5 tentatives échouent, il abandonne : vous n’avez reçu aucune donnée et vous n’avez reçu aucune alerte. C’est pourquoi les données critiques ne peuvent pas reposer uniquement sur les Webhooks : il faut une récupération planifiée en filet de sécurité. Pour l’intégration CRM, voir Intégration CRM pour site e-commerce.
| Événement | WooCommerce Hook | Destination | Priorité |
|---|---|---|---|
| Nouvelle commande créée | woocommerce_order_created | CRM + notification Slack | Maximal |
| Changement de statut de commande | woocommerce_order_status_changed | E-mail client + mise à jour CRM | Élevée |
| Paiement réussi | woocommerce_payment_complete | Mise à niveau de l’adhésion | Élevée |
| Remboursement initié | woocommerce_order_refunded | Marquage CRM + notification comptabilité | Moyenne |
| Nouvel utilisateur inscrit | user_register | Liste d’e-mailing | Moyenne |
| Mise en ligne/retrait d’un produit | woocommerce_product_set_visibility | Synchronisation du stock | Faible |
III. Récupération planifiée via REST : le filet de sécurité pour le rapprochement
Le Webhook assure la notification en temps réel à la seconde près, mais vous devez impérativement ajouter une récupération planifiée pour le rapprochement. La méthode est simple : écrivez un script WP-Cron qui s’exécute toutes les heures, appelle l’API REST WooCommerce pour récupérer les commandes créées ou mises à jour dans l’heure écoulée, puis les compare aux commandes déjà présentes dans votre base de données. Si le Webhook a manqué une commande (par exemple parce que votre serveur renvoyait un 502 au moment de la réception), la récupération planifiée la rattrape.
Les paramètres de requête de la récupération planifiée doivent inclure un horodatage. Par exemple GET /wp-json/wc/v3/orders?after=2026-09-21T10:00:00&per_page=100 renvoie toutes les commandes postérieures à 10 h, par pages de 100. Si la réponse contient 100 éléments, c’est qu’il y en a probablement d’autres : continuez à paginer. Une fois la récupération terminée, dédupliquez par ID de commande : ignorez celles déjà en base, insérez les autres. C’est la logique de rapprochement la plus simple qui soit.
Exemple concret : un mercredi à 15 h, le certificat SSL du serveur expire et renvoie une erreur 525 pendant 40 minutes. Pendant ce temps, les Webhooks de 3 nouvelles commandes échouent tous. Avec les Webhooks seuls, ces 3 commandes sont perdues. Mais avec une récupération planifiée toutes les heures, la tâche de 16 h récupère les 3 commandes manquées et les clients reçoivent leur e-mail de confirmation. Pour configurer la surveillance, voir Surveillance et alertes du site.
| Mode de synchronisation | Fréquence | Latence | En cas d’échec |
|---|---|---|---|
| Push Webhook | Déclenché par événement | Quelques secondes | L’autre partie abandonne après 5 tentatives |
| Récupération planifiée toutes les heures | Chaque heure pile | Quelques minutes | Nouvelle tentative automatique en cas d’échec |
| Rapprochement complet quotidien | Chaque jour à 3 h du matin | Quelques jours | Génère un rapport d’écarts à vérifier manuellement |
| WebSocket en temps réel | Temps réel | De l’ordre de la milliseconde | Reconnexion nécessaire si la connexion tombe |
IV. Authentification et sécurité : la clé côté backend, la signature pour vérifier les requêtes
L’erreur de sécurité la plus fréquente en intégration d’API est de mettre la clé API dans le JavaScript frontend. N’importe qui ouvre son navigateur, appuie sur F12 → onglet Network, voit votre clé et s’en sert pour appeler votre API à volonté. La bonne méthode : le frontend n’appelle que les interfaces de votre propre serveur, et c’est le serveur qui ajoute la clé API côté backend avant de transmettre au tiers. Ce proxy backend peut être un point de terminaison REST personnalisé WordPress, ou un simple service Node.js/Python.
Vous devez vérifier la signature à la réception d’un Webhook. Quand WooCommerce envoie un Webhook, il ajoute un en-tête HTTP X-WC-Webhook-Signature : c’est une signature HMAC-SHA256 du corps, calculée avec votre Webhook Secret. Vous recalculez la même signature dans votre point de terminaison de réception, vous la comparez à celle de l’en-tête, et vous ne traitez que si elles correspondent. Si elles diffèrent, la requête est falsifiée : renvoyez directement 403. Sans vérification de signature, n’importe qui peut envoyer de fausses commandes à votre point de terminaison, et votre CRM se remplit de prospects indésirables.
Exemple concret : vous recevez les Webhooks HubSpot, quelqu’un découvre votre URL de réception et construit une fausse requête POST « nouveau prospect ». Sans vérification de signature, ce faux prospect entre dans HubSpot, le commercial le suit pendant un moment avant de découvrir qu’il est faux. Avec la vérification HMAC, la requête HubSpot porte la bonne signature, la fausse requête a une signature incorrecte et se fait bloquer par un 403. Pour les détails de l’intégration CRM, voir Intégration CRM pour site e-commerce.
| Point de sécurité | Erreur à éviter | Bonne pratique |
|---|---|---|
| Emplacement de la clé API | Dans le JS frontend | Dans une variable d’environnement serveur |
| Proxy de requêtes | Le frontend appelle directement l’API tierce | Le frontend appelle votre serveur, le backend transmet |
| Vérification de signature du Webhook | Pas de vérification, traitement dès réception | Comparaison HMAC-SHA256 avec l’en-tête |
| HTTPS | Réception des Webhooks en HTTP | HTTPS obligatoire, TLS 1.2 minimum |
| Liste blanche d’IP | Aucune restriction d’IP source | Liste blanche selon les plages d’IP officielles du tiers |
| Log d’erreur | Aucun enregistrement en cas d’échec | Toutes les réponses non 2xx sont journalisées |
V. Liste des intégrations tierces courantes
Un site autonome intègre généralement cinq types d’outils tiers : CRM (HubSpot, Salesforce, Zoho), emailing (Mailchimp, ConvertKit, Klaviyo), passerelles de paiement (Stripe, PayPal), outils d’analyse (Google Analytics 4, Hotjar) et support client (Intercom, Zendesk). Chaque type se connecte différemment, mais le principe reste le même : privilégiez le Webhook quand c’est possible (temps réel), et ajoutez une récupération planifiée pour les données critiques (en secours).
Ne vous lancez pas dans le développement d’une intégration sur mesure. Vérifiez d’abord si un plugin existe dans la bibliothèque WordPress : HubSpot a son plugin officiel, Mailchimp aussi, et Stripe dispose de l’extension officielle WooCommerce. Un plugin existant couvre 80 % des besoins ; pour les 20 % restants (le mappage de champs personnalisés, par exemple), complétez avec un Webhook ou du code sur mesure. Développer vous-même la connexion entre deux systèmes demande souvent plus de 20 heures de débogage, alors qu’installer un plugin existant prend une heure. Pour choisir votre plugin CRM, voir Des leads du site au CRM.
| Type de système | Solution recommandée | Mode de connexion | Temps estimé |
|---|---|---|---|
| CRM (HubSpot) | Plugin officiel + Webhook | Synchronisation automatique par le plugin | 2 à 4 heures |
| Emailing (Mailchimp) | Plugin officiel | Ajout automatique à la liste à l’inscription | 1 à 2 heures |
| Paiement (Stripe) | Extension officielle WooCommerce | Synchronisation du statut de commande par Webhook | 1 à 2 heures |
| Analyse (GA4) | Plugin Site Kit by Google | Suivi automatique côté front | 30 minutes |
| Support (Intercom) | Plugin de chat officiel | Extrait de code côté front | 30 minutes |
| ERP personnalisé | Intégration REST développée en interne | Récupération planifiée + Webhook | Plus de 20 heures |
FAQ — Questions fréquentes
Quelle différence entre REST API et Webhook, et lequel choisir ?
Faut-il installer un plugin pour utiliser WordPress REST API ?
Où stocker une API Key, et peut-on l’utiliser côté front ?
Comment vérifier qu’une requête Webhook reçue est authentique ?
Que faire si un Webhook échoue ?
Pour connecter un système tiers, faut-il un plugin existant ou du code sur mesure ?
Pour conclure
En intégration API, ce n’est pas la complexité qui compte, c’est la fiabilité. Un seul objectif : ne perdre aucune donnée, garder des états corrects, et pouvoir diagnostiquer en cas de problème. Le Webhook est rapide mais peu fiable, le REST est plus lent mais maîtrisable ; c’est en combinant les deux que l’on obtient une solution de production. Utilisé seul, chacun finira par perdre des données à un moment ou un autre.
Trois étapes pour passer à l’action : pour les intégrations critiques, utilisez le Webhook pour la notification en temps réel et ajoutez la vérification HMAC côté réception ; ajoutez une récupération REST planifiée toutes les heures pour le rapprochement, afin de rattraper automatiquement ce que le Webhook a manqué ; placez toutes les clés API dans des variables d’environnement côté back-end, le front-end n’appelant que l’interface proxy de votre propre serveur.
Une phrase à retenir : un webhook, c’est une notification instantanée ; le REST, c’est un rapprochement régulier. Se fier aux seules notifications sans jamais vérifier, c’est entendre la sonnette sans jamais ouvrir la boîte aux lettres.