Certaines intégrations ne vous envoient pas des mises à jour. Elles vous envoient du bruit. Reconstruire la vérité à partir de celui-ci.

Les webhooks ont une promesse simple. Quelque chose change, vous êtes appelé, vous réagissez. Cette promesse rend les intégrations faciles à appréhender, jusqu'à ce que vous en construisiez une contre un système qui ne vous envoie pas des changements. Il vous envoie des fragments de changements. Et les fragments ne vous disent pas ce qui s'est réellement passé.

L'écart entre ce que vous attendez et ce qui arrive

Quand vous vous intégrez à un système qui déclenche un événement séparé pour chaque propriété d'un objet, vous ne recevez pas des mises à jour. Vous recevez un flux de notifications atomiques sans contexte partagé, sans ordre garanti, et sans enveloppe vous indiquant qu'elles appartiennent au même ensemble.

Un enregistrement de contact est mis à jour. Cinquante propriétés changent. Cinquante appels webhook quittent le système source. Ils arrivent à votre endpoint éparpillés dans le temps, dans le désordre, certains dupliqués, certains retardés. Aucun d'eux ne dit que ceci fait partie de la même mise à jour. Aucun ne vous dit quand la mise à jour est terminée. Ils arrivent simplement, une propriété à la fois, et attendent que vous compreniez ce qu'ils signifient ensemble.

Multipliez ça par plusieurs enregistrements mis à jour en l'espace d'une seconde. Ingérable.

À toute échelle significative, ce flux devient un torrent. Le bruit n'est pas occasionnel. C'est l'état par défaut de l'intégration.

Ce qui casse quand vous traitez naïvement

Le réflexe naturel est de traiter chaque appel à son arrivée. Une propriété change, vous l'écrivez. Une autre propriété change, vous l'écrivez. La logique est simple, et elle semble correcte.

Elle ne l'est pas.

Ce que vous écrivez dans votre base de données n'est pas l'état de l'objet après la mise à jour. Vous écrivez une séquence d'états partiels, chacun reflétant un moment différent d'un changement qui n'a pas encore fini d'arriver. Si deux appels arrivent dans le désordre, vous écrasez une valeur récente avec une valeur plus ancienne. Si un appel arrive deux fois, vous traitez le même changement deux fois. Si votre traitement prend plus de temps que l'intervalle entre les appels, vous travaillez sur un état qui est déjà obsolète au moment où vous avez terminé.

Votre base de données semble synchronisée. Elle ne l'est pas. Elle reflète le bruit, pas la réalité.

La décision qui a tout réglé

Le premier réflexe était d'absorber les appels et de reconstruire l'état à partir des fragments. Ça n'a pas fonctionné. HubSpot ne les envoyait pas dans l'ordre et ne les envoyait pas dans une fenêtre temporelle prévisible. Il n'y avait aucun moyen fiable de savoir quand un lot d'appels était complet, parce que HubSpot ne le savait pas non plus.

La solution n'est pas venue de l'extérieur de HubSpot. Elle est venue de l'intérieur.

Nous avons construit un workflow directement dans HubSpot qui écoute les sauvegardes d'objets et met à jour une seule propriété personnalisée que nous contrôlions. Cette propriété avait un seul but : être le signal. Nous ignorions complètement tous les autres webhooks. Quand cette propriété personnalisée était mise à jour, nous savions que la sauvegarde était terminée. Nous récupérions l'état complet de l'objet directement depuis l'API et mettions à jour notre côté une seule fois, proprement, depuis une source de vérité unique.

Le bruit était toujours là. Nous avions simplement arrêté de l'écouter.

Ce que ça a produit

Zéro perte de données. Aucun traitement en double. Aucune condition de course. Un système qui traite chaque mise à jour d'objet exactement une fois, depuis un état complet et précis, peu importe ce que HubSpot envoie entre-temps.

Plus important encore, le système est devenu simple. Un signal. Une récupération. Une écriture. La complexité du comportement des webhooks de HubSpot est devenue invisible pour tout ce qui se trouvait en aval.

Pourquoi est-ce important au-delà d'une seule intégration ?

Quand une intégration est fondamentalement cassée, le réflexe est de construire un récepteur plus intelligent. Absorber davantage, réconcilier davantage, gérer chaque cas limite depuis l'extérieur.

Ce réflexe est mauvais.

La bonne question est de savoir si le système source lui-même peut être amené à produire un meilleur signal. Dans la plupart des plateformes, vous avez plus de contrôle que vous ne le pensez. Un workflow, une propriété personnalisée, un champ calculé, quelque chose à l'intérieur du système que vous possédez et qui condense un comportement imprévisible en un seul événement propre que vous contrôlez.

Le bruit ne disparaît pas. Vous arrêtez simplement de l'écouter. Et parfois, c'est la seule solution qui fonctionne vraiment.

Victoire Habamungu

Ingénieur logiciel spécialisé en systèmes de données, architecture distribuée et ingénierie de plateforme.

Share post: