Une API relie une boutique, un CRM, un logiciel de gestion ou une application mobile. Les webhooks transmettent des événements en quasi-temps réel : commande créée, paiement confirmé, facture émise. Mal sécurisés, ces échanges peuvent exposer des données, provoquer des doublons ou déclencher des actions non autorisées. Voici une méthode opérationnelle pour les responsables techniques et les PME.
1. Cartographier les échanges avant de modifier le code
Pour chaque intégration, documentez l’émetteur, le destinataire, les données, le protocole, la fréquence, le propriétaire de la clé et les conséquences d’une panne. Distinguez les API consultées à la demande des webhooks reçus automatiquement. Ne transférez que les champs nécessaires : une notification de paiement n’a généralement pas besoin d’inclure l’intégralité d’une fiche client.
2. Authentification : limiter les privilèges et protéger les secrets
Exigez HTTPS, une authentification adaptée au fournisseur (OAuth 2.0, clé d’API ou jeton court) et des autorisations minimales. Ne placez jamais une clé secrète dans un dépôt Git, une application mobile distribuée ou une URL. Conservez-la dans un gestionnaire de secrets ou dans la configuration serveur, avec des accès restreints. Prévoyez rotation et révocation des clés, notamment lorsqu’un prestataire quitte le projet.
Une clé d’API identifie souvent un client logiciel mais ne remplace pas à elle seule l’autorisation sur chaque ressource. Vérifiez systématiquement qu’un utilisateur peut réellement accéder à la commande ou au dossier demandé.
3. Vérifier l’authenticité des webhooks
Lorsque le fournisseur propose une signature HMAC, calculez la signature attendue à partir du corps brut de la requête et du secret partagé, puis comparez-la en temps constant. Respectez strictement le format et l’algorithme documentés par ce fournisseur : les implémentations varient. Vérifiez aussi l’horodatage ou l’identifiant d’événement pour réduire les risques de rejeu. Ne vous fiez pas uniquement à l’adresse IP source.
Exemple de traitement fiable
- Recevoir la requête sur une route HTTPS dédiée.
- Contrôler la taille du message, la signature et l’horodatage selon la documentation officielle.
- Enregistrer l’identifiant d’événement avec une contrainte d’unicité.
- Mettre le travail en file d’attente et retourner rapidement le code HTTP attendu par le fournisseur.
- Traiter l’événement de manière idempotente, journaliser le résultat et déclencher une alerte en cas d’échecs répétés.
4. Éviter les commandes et factures en double
Un fournisseur peut renvoyer un webhook lorsqu’il ne reçoit pas d’accusé de réception. Votre système doit donc accepter plusieurs livraisons du même événement sans créer plusieurs factures ni changer plusieurs fois un stock. Utilisez une clé d’idempotence ou un identifiant d’événement unique en base de données. Pour les paiements, vérifiez l’état auprès du prestataire avant de considérer une commande comme réglée. Une simple page de retour du navigateur n’est pas une preuve de paiement.
5. Résister aux pannes et surveiller les intégrations
Définissez des délais d’attente, des tentatives limitées avec attente progressive, une file d’échecs à rejouer et un tableau de bord. Journalisez l’identifiant d’événement, la durée, le statut et une référence de corrélation, mais masquez les secrets et données personnelles. Testez les scénarios : fournisseur indisponible, événement en retard, doublon, message malformé, secret expiré et interruption réseau.
6. Checklist de recette avant la mise en production
- Inventaire des endpoints et propriétaires tenu à jour.
- HTTPS, authentification et autorisations testés.
- Secrets hors du code source et procédure de rotation disponible.
- Signature webhook vérifiée sur le corps brut, selon le fournisseur.
- Protection contre les rejeux et traitement idempotent.
- Gestion des erreurs, retries, alertes et reprise documentées.
- Tests d’intégration réalisés en environnement de préproduction.
- Politique de conservation des journaux et accès limités.
7. Cas concret : boutique WooCommerce reliée à un ERP
Lorsqu’une commande est payée, le système doit associer l’identifiant de transaction à la commande, confirmer le paiement par une source de confiance, puis transmettre une seule fois la mise à jour à l’ERP. Si l’ERP ne répond pas, la tâche reste en attente et peut être rejouée sans dupliquer l’écriture. Cette logique vaut aussi pour les CRM, logiciels scolaires et systèmes de réservation.
Documentation technique à consulter
Consultez l’OWASP API Security Top 10, la documentation API WooCommerce et les principes des webhooks WooCommerce. Les détails de signature et de réessai doivent toujours être vérifiés dans la documentation de votre prestataire de paiement.
Faire auditer votre intégration
Si vos commandes, factures ou notifications se perdent entre plusieurs logiciels, 3Vision Group peut étudier votre architecture, identifier les points de rupture et proposer un plan de sécurisation ou une application métier adaptée. Pour cadrer le projet, consultez également notre guide du cahier des charges d’un logiciel métier.
