Une plateforme de suivi des liens enregistre ce qui arrive à vos liens. Un webhook, c’est la plateforme qui prévient vos autres systèmes au moment où cela se produit, sans attendre que quelqu’un consulte un tableau de bord. C’est cette combinaison qui fait apparaître un nouveau lien de campagne dans votre CRM dès sa création, ou qui met à jour un ticket quand un lien secret est ouvert.
Pour choisir une plateforme de suivi des liens avec intégrations par webhook, il faut aller au-delà de la mention « webhooks disponibles » : quels événements elle envoie, comment elle les sécurise, et ce qu’elle n’envoie pas. Ce guide couvre tout cela, explique comment construire un récepteur fiable et indique quand l’API est le meilleur outil.
À quoi servent les webhooks d’une plateforme de liens
Trois usages reviennent sans cesse.
- Synchroniser les systèmes. Un lien créé dans la plateforme apparaît dans la fiche de campagne de votre CRM ou de votre outil de gestion de projet, avec son slug et sa destination, sans que personne ait à le copier.
- Déclencher des processus. Un lien secret ouvert marque une transmission comme terminée ; un lien détruit sans que le destinataire l’ait confirmé ouvre un incident.
- Alimenter un entrepôt de données. Les événements arrivent dans une file d’attente, puis dans une table, où ils rejoignent le reste de vos données.
Les webhooks ne sont pas faits pour compter. Un tableau de bord qui incrémente un nombre à chaque webhook s’écartera du rapport de la plateforme dès la première livraison relancée ou retardée. Utilisez l’API ou un export pour les chiffres, et les webhooks pour les actions.
Quels événements rechercher
Les plateformes n’émettent pas toutes les mêmes événements. Demandez la liste, pas la fonctionnalité.
| Famille d’événements | Événements typiques | Utile pour |
|---|---|---|
| Cycle de vie des liens | créé, modifié, supprimé | Synchronisation avec le CRM, piste d’audit, repérage des modifications accidentelles |
| Cycle de vie des secrets | créé, ouvert, détruit | Confirmation de transmission, déclenchement d’incidents |
| Événements de clic | par clic ou par lots | Automatisation en temps réel, à fort volume |
| Événements de domaine | vérifié, certificat émis | Alertes d’exploitation |
Les webhooks de LinkPilot couvrent le cycle de vie des liens (link.created, link.updated, link.deleted) et celui des secrets (secret.created, secret.viewed, secret.burned). Les données de clic sont disponibles par l’API de statistiques et l’export CSV, et non par un webhook à chaque clic. Pour la plupart des équipes, c’est la bonne répartition : les clics sont des données de reporting à fort volume, alors que les événements de cycle de vie sont ceux qui doivent déclencher quelque chose.
Si votre processus a réellement besoin d’une réaction à chaque clic, vérifiez que la plateforme les regroupe par lots ou en limite le débit. Sinon, vous construirez un récepteur qui tombera la première fois qu’un post deviendra viral.
Ce qu’il faut évaluer d’autre
- La signature. Chaque livraison doit porter une signature calculée avec un secret que vous détenez, pour que votre endpoint puisse rejeter les requêtes falsifiées. Une plateforme qui envoie des webhooks non signés vous demande de faire confiance à n’importe quelle requête POST.
- Les nouvelles tentatives et l’ordre. Renseignez-vous sur le nombre de nouvelles tentatives après un échec de livraison et sur la période qu’elles couvrent, et partez du principe que les événements peuvent arriver dans le désordre.
- Les identifiants d’événement. Un identifiant unique par événement est ce qui rend l’idempotence possible.
- La gestion des endpoints. Plusieurs endpoints par espace de travail, des abonnements par événement et un journal de livraison lisible quand quelque chose ne va pas.
- L’API à côté. Les webhooks pour les déclencheurs, l’API pour tout le reste. Vérifiez que la création de liens, les statistiques et les exports sont tous accessibles par programme et que les clés peuvent être limitées à un périmètre. L’API de LinkPilot utilise des clés bearer
lp_live_et est disponible sur tous les forfaits. - L’accès de l’équipe. Savoir qui peut ajouter un endpoint de webhook compte, car un endpoint reçoit des données. Les rôles doivent permettre à un administrateur de gérer les endpoints et en tenir tous les autres à l’écart.
Construire un récepteur qui ne tombe pas
- Vérifiez d’abord la signature. Calculez la signature attendue à partir du corps brut et de votre secret, comparez en temps constant, et rejetez tout ce qui échoue avant l’analyse.
- Accusez réception vite. Renvoyez un 2xx en une ou deux secondes. Faites le vrai travail depuis une file d’attente, pour qu’un CRM lent ne provoque pas de nouvelles tentatives.
- Stockez les identifiants d’événement et ignorez ceux que vous avez déjà vus. Les nouvelles tentatives sont normales ; un double traitement est un bug de votre côté.
- Associez les champs explicitement. Reprenez dans votre propre schéma le slug, la destination, les tags et les horodatages dont vous avez besoin. Ne stockez pas la charge utile entière comme source de référence : c’est une notification, pas un enregistrement.
- Journalisez chaque livraison avec son identifiant et son résultat. Quand le journal de la plateforme indique « livré » et que votre système dit qu’il ne s’est rien passé, vous pourrez retrouver où elle est allée.
- Déclenchez une alerte en cas de silence. Si un endpoint qui reçoit habituellement des événements toutes les heures reste muet pendant une journée, quelque chose a cassé d’un côté ou de l’autre.
Testez avec un endpoint de préproduction et la livraison de test de la plateforme avant la première vraie campagne. Créez un lien, modifiez-le, supprimez-le, et regardez les trois événements arriver.
Protéger les données
Les charges utiles des webhooks décrivent des liens et des secrets, pas des personnes. Gardez-les ainsi.
- N’incluez jamais de données personnelles dans les slugs ou les tags, car elles voyageront dans chaque charge utile concernant ce lien.
- Restreignez l’endpoint au trafic de la plateforme par la signature et, quand c’est possible, par l’adresse source.
- Stockez le secret de signature dans un gestionnaire de secrets, pas dans le fichier de configuration du récepteur, et renouvelez-le à intervalles réguliers. Si vous devez transmettre ce secret au prestataire qui construit le récepteur, envoyez-le par un lien secret à usage unique. Le guide sur le secret de signature des webhooks couvre cette transmission.
- Pensez au consentement quand des données de clic partent vers un CRM. Un enregistrement de clic rattaché à un client est une donnée personnelle au sens de la plupart des règles de protection de la vie privée.
Mesurer l’intégration elle-même
- Le taux de livraisons réussies, d’après le journal de la plateforme.
- Le délai de traitement, de l’horodatage de l’événement à l’enregistrement dans votre système.
- Le taux de doublons, qui doit être faible mais jamais nul.
- Le rapprochement : une fois par semaine, comparez le nombre de liens et les totaux de clics de l’API avec ce que contiennent vos systèmes. Un écart signale une livraison perdue ou un bug dans le récepteur.
Une plateforme de suivi des liens avec webhooks fait participer vos liens au reste de vos outils. Choisissez-en une qui signe ce qu’elle envoie, vous dit exactement quels événements existent et vous donne une API pour les chiffres. Construisez ensuite le récepteur en considérant les nouvelles tentatives comme le cas normal, parce que c’en est un.