Un webhook est une méthode basée sur les événements permettant à un système d’en informer un autre lorsqu’un événement important se produit. Plutôt qu’attendre qu’une seconde application interroge à plusieurs reprises pour savoir si des données ont été modifiées, l’application source envoie une requête HTTP vers une URL prédéfinie dès que l’événement survient. Concrètement, un webhook agit comme un rappel automatisé entre systèmes. Il transforme un événement métier, un événement de plateforme ou un événement de flux de travail en une notification immédiate de machine à machine qu’une autre application peut recevoir et traiter.

Ce modèle simple est devenu l’un des schémas d’intégration les plus utilisés dans les logiciels modernes. Les plateformes de paiement utilisent les webhooks pour signaler les paiements réussis, les transactions échouées et les remboursements. Les plateformes d’hébergement de code s’en servent pour avertir les outils de déploiement des envois de code, des demandes de fusion ou des modifications de problèmes. Les services de messagerie les utilisent pour transmettre les événements de messages entrants. Les produits SaaS s’en servent pour synchroniser les comptes, les tickets, les commandes, les abonnements, les alertes et les flux d’automatisation. Comme ce mécanisme est léger et rapide, les webhooks sont souvent l’un des premiers outils que les équipes adoptent lorsqu’elles souhaitent que différents systèmes réagissent les uns aux autres en temps réel.

Comprendre les webhooks

Définition d’un webhook

Un webhook est généralement un point de terminaison HTTP configurable par l’utilisateur qui reçoit des notifications d’événements d’une autre plateforme. La plateforme émettrice est informée de l’URL à appeler et des événements qui doivent déclencher une transmission. Lorsqu’un événement sélectionné se produit, la plateforme regroupe les données de l’événement dans une requête et l’envoie vers le point de terminaison cible. L’application réceptrice valide ensuite la requête, interprète la charge utile et décide de la prochaine action à entreprendre.

C’est pourquoi un webhook est souvent décrit comme un rappel d’événement, un point de terminaison de notification d’événement ou un mécanisme d’intégration par envoi de données. Contrairement à une API polyvalente, conçue pour que les clients demandent des données à tout moment, un webhook est destiné à ce que la plateforme pousse les données vers l’extérieur lorsqu’un événement se produit réellement. Cette différence confère aux webhooks une grande partie de leur valeur opérationnelle.

Pourquoi les webhooks sont devenus si courants

Les webhooks se sont popularisés car de nombreux systèmes métier fonctionnent mal lorsque chaque application connectée doit effectuer des interrogations répétées pour obtenir des mises à jour. Les interrogations répétées augmentent les requêtes inutiles, consomment les limites d’API, ajoutent de la latence entre le moment où un événement se produit et celui où un autre système le détecte, et génèrent une charge de traitement supplémentaire des deux côtés. Les webhooks résolvent ce problème en confiant la responsabilité de la notification à la source de l’événement.

Ce modèle de poussée de données est particulièrement utile dans les systèmes distribués où le temps est un critère essentiel. Lorsqu’un paiement est validé, un système de commandes peut devoir lancer immédiatement la préparation de la commande. Lorsqu’un client soumet un formulaire, un CRM peut créer instantanément un prospect. Lorsqu’un dépôt de code est mis à jour, un pipeline CI/CD peut démarrer automatiquement. Dans tous ces cas, le modèle webhook réduit le temps d’attente et permet aux différents systèmes de fonctionner comme des parties d’un même processus métier continu.

C’est pourquoi les webhooks sont fréquemment utilisés même dans les architectures qui reposent encore sur les API à d’autres fins. Une API peut servir à interroger ou modifier des ressources, tandis qu’un webhook permet d’informer les systèmes connectés qu’une modification a déjà eu lieu. Ensemble, ils forment un schéma d’intégration pratique basé sur les requêtes et les événements.

Les intégrations de webhooks permettent à une application d’informer immédiatement un autre système lorsqu’un événement sélectionné se produit.

Fonctionnement d’un webhook

Déclencheur d’événement, URL de rappel et transmission

Le flux de base d’un webhook commence par une source d’événements. Il peut s’agir d’un service de paiement, d’une plateforme cloud, d’un service de messagerie, d’un dépôt de code, d’un système ERP ou de toute autre application capable d’envoyer des notifications. Un administrateur ou un développeur configure une URL de rappel du côté récepteur, et la plateforme émettrice enregistre cette destination comme point de terminaison pour la transmission des événements.

Lorsqu’un événement souscrit se produit, la plateforme crée une transmission webhook et l’envoie vers le point de terminaison configuré. Dans de nombreuses implémentations, la requête est une requête HTTP POST contenant des données structurées au format JSON, des paramètres de formulaire ou des champs spécifiques à la plateforme. La requête inclut généralement des en-têtes, des métadonnées, des identifiants d’événements, des horodatages ainsi que des signatures ou champs de vérification pour aider le système récepteur à valider l’émetteur et à interpréter correctement la charge utile.

Une fois que la requête parvient au service récepteur, l’application vérifie son authenticité, analyse les données de l’événement, enregistre la transmission et exécute la logique métier. Cela peut inclure la mise à jour d’une base de données, la création d’un ticket, le lancement d’un flux de travail, l’envoi d’une alerte, la modification de l’état d’une commande ou le transfert de l’événement vers une file d’attente de messages pour un traitement complémentaire.

Charges utiles, en-têtes et traitement des événements

Bien que la conception des webhooks varie selon les plateformes, beaucoup suivent une structure similaire. La charge utile contient des informations sur l’événement lui-même : ce qui s’est passé, quand cela s’est produit et quelle ressource a été affectée. Les en-têtes de requête peuvent identifier le type d’événement, fournir un identifiant de transmission et inclure une signature à des fins de vérification. Le point de terminaison récepteur lit ces champs et les associe à la logique requise par le flux de travail métier ou applicatif.

Dans une implémentation robuste, le traitement des événements est divisé en étapes. Le point de terminaison reçoit l’événement, réalise l’authentification et une validation de base, enregistre ou accuse réception de l’événement rapidement, puis le traite en toute sécurité en arrière-plan ou via un moteur de flux de travail contrôlé. Ce schéma permet de réduire les échecs de transmission et empêche un traitement lent de provoquer des dépassements de délai inutiles ou des tentatives de renvoi en double.

La puissance d’un webhook réside dans sa capacité à transformer un changement en action. Dès qu’un système constate un événement important, il peut immédiatement en informer un autre système au lieu d’attendre d’être interrogé.

Fonctions clés des webhooks

Notification d’événements en temps réel

La fonction fondamentale d’un webhook est la notification d’événements en temps réel ou quasi temps réel. Elle permet aux plateformes de communiquer les changements au moment où ils se produisent, au lieu de dépendre de vérifications planifiées. Cela rend les intégrations plus réactives et aide les systèmes métier à réagir plus rapidement aux activités des clients, aux changements d’état de la plateforme ou aux signaux opérationnels.

Dans de nombreux environnements, cette fonction fait la différence entre une coordination retardée et une automatisation continue. Un webhook peut avertir un système d’expédition dès qu’un paiement est validé, alerter une plateforme de surveillance en cas d’incident, informer un CRM du changement de statut d’un prospect ou prévenir un outil de collaboration qu’un nouvel enregistrement nécessite une intervention humaine. L’application réceptrice n’a pas besoin de détecter l’événement ultérieurement car le système source le signale directement.

Automatisation des flux de travail entre systèmes

Les webhooks constituent également un pont d’automatisation pratique. Ils ne se contentent pas d’annoncer des événements ; ils peuvent déclencher des actions de suivi entre différentes applications. Un webhook issu d’une plateforme de commerce électronique peut lancer l’acheminement des commandes. Un webhook d’une plateforme de tickets peut créer un flux de support technique. Un webhook d’un système de déploiement peut déclencher des tests, des notifications ou des modifications d’infrastructure. Cette capacité fait des webhooks un élément central de nombreuses plateformes d’intégration d’entreprise, low-code et no-code.

Comme les événements webhook sont généralement liés à des actions et des états spécifiques, ils s’intègrent naturellement dans les moteurs de flux de travail. Plutôt que de mettre en place des tâches de synchronisation permanentes, les équipes peuvent concevoir des étapes pilotées par les événements qui ne réagissent qu’en cas d’événement significatif. Cela rend l’automatisation plus efficace et plus facile à aligner sur les processus métier réels.

Synchronisation des systèmes et mise à jour des états

Une autre fonction essentielle est la synchronisation intersystèmes. De nombreuses organisations utilisent simultanément plusieurs plateformes SaaS, bases de données internes, outils de messagerie, systèmes d’analyse et applications de service. Lorsque l’un de ces systèmes modifie un enregistrement, met à jour un état ou termine une transaction, les autres systèmes peuvent avoir besoin d’être informés immédiatement. Les webhooks permettent à ces mises à jour de se propager sans longs intervalles d’interrogation ni exportations manuelles répétées.

Cela est particulièrement utile pour la facturation par abonnement, la gestion du cycle de vie des utilisateurs, la réponse aux incidents, le support client, la logistique et le DevOps. Un système n’a pas besoin de comparer constamment deux ensembles de données pour détecter un changement. À la place, l’événement devient le déclencheur de synchronisation, et la plateforme réceptrice décide comment mettre à jour ses propres enregistrements ou flux de travail en conséquence.

Les webhooks sont couramment utilisés pour prendre en charge la notification d’événements, l’automatisation et la synchronisation des systèmes entre applications connectées.

Valeur systémique des webhooks

Réduction de la charge d’interrogation et meilleure efficacité

L’un des plus grands avantages systémiques des webhooks est l’efficacité. Dans un modèle d’interrogation, les systèmes connectés peuvent être amenés à envoyer des requêtes répétées pour vérifier si des changements ont eu lieu. Même en l’absence d’événement, ces requêtes consomment de la bande passante, du temps de calcul, des quotas d’API et des ressources de traitement. Les webhooks réduisent cette charge car les messages ne sont envoyés qu’en cas d’événements pertinents.

Cela améliore la scalabilité dans les environnements où de nombreux systèmes interagissent fréquemment. Au lieu de milliers de vérifications périodiques sur plusieurs intégrations, l’architecture s’oriente vers une communication déclenchée par les événements. Cela réduit souvent le bruit, limite les requêtes inutiles et optimise l’utilisation des ressources d’infrastructure. L’avantage est encore plus marqué lorsque la fréquence des événements est inférieure à la fréquence d’interrogation nécessaire pour obtenir une réactivité similaire.

Réactivité accrue et meilleure expérience utilisateur

Les webhooks améliorent également le temps de réaction. Si un processus métier dépend d’une détection rapide des changements, attendre le prochain cycle d’interrogation peut entraîner des retards. Un client peut avoir payé, mais la préparation de la commande n’a pas encore débuté. Un ticket peut avoir été escaladé, mais les alertes ne sont pas à jour. Un déploiement peut avoir échoué, mais le canal des incidents n’a pas été prévenu. Les webhooks réduisent cet écart en transmettant les événements dès que la plateforme source les émet.

Cette réactivité accrue améliore l’expérience utilisateur de multiples manières. Les utilisateurs reçoivent leurs confirmations plus tôt, les flux de support progressent plus rapidement, les équipes internes voient les changements d’état en temps opportun et les tableaux de bord système reflètent la réalité avec moins de retard. Dans les systèmes orientés client, cela fait la différence entre un flux de travail automatisé et un flux lent ou déconnecté.

Conception d’intégration renforcée dans les systèmes pilotés par les événements

Au-delà de l’efficacité et de la réactivité, les webhooks renforcent un modèle architectural piloté par les événements. Plutôt que de considérer chaque intégration comme une suite de vérifications manuelles et de tâches planifiées, les organisations peuvent concevoir des systèmes autour d’événements métier tels que la création de commande, le paiement de facture, la fermeture de ticket, le déclenchement d’alarme matérielle ou la mise à jour de dépôt de code. Cela rend la logique d’intégration plus modulaire, car chaque événement peut être associé aux systèmes concernés.

Cette architecture est précieuse même lorsque le webhook lui-même est simple. L’événement peut devenir le déclencheur pour les files d’attente, les fonctions sans serveur, les moteurs de flux de travail, les API internes, les systèmes de journalisation et les pipelines d’analyse. Autrement dit, le webhook n’est souvent que la première étape, mais il constitue la passerelle qui lance le reste de l’automatisation.

La véritable valeur systémique d’un webhook ne se limite pas à l’envoi de données. Il permet aux applications distribuées de fonctionner comme un processus coordonné en réagissant aux événements avec beaucoup moins de retard et de gaspillage de ressources.

Considérations de sécurité, de fiabilité et d’exploitation

Vérification des signatures et sécurité des points de terminaison

Puisque les webhooks transmettent automatiquement des données d’un système à un autre, la sécurité est essentielle. Un service récepteur ne doit pas faire confiance à toutes les requêtes entrantes qui prétendent être des notifications d’événements. La plupart des implémentations sérieuses de webhooks utilisent donc des méthodes de vérification telles que les secrets partagés, les signatures de requête, le transport HTTPS ou des règles de validation spécifiques à la plateforme. Ces mécanismes permettent de confirmer que la requête provient bien du fournisseur attendu et que la charge utile n’a pas été altérée lors de la transmission.

La sécurité du point de terminaison est également importante sur le plan opérationnel. L’URL réceptrice doit être exposée, surveillée et documentée avec précaution. Les équipes doivent contrôler les accès, protéger les secrets, journaliser les transmissions et éviter d’écrire des gestionnaires de webhook qui exécutent des actions à risque avant validation de la requête. Dans les environnements matures, les points de terminaison webhook sont traités comme des interfaces d’intégration de production et non comme des scripts de rappel jetables.

Nouvelles tentatives, idempotence et gestion des échecs

Une conception fiable de webhook dépend également de la gestion des échecs. Les réseaux peuvent tomber en panne, les services dépasser leur délai de réponse, les dépendances devenir indisponibles et les récepteurs renvoyer parfois des erreurs. C’est pourquoi de nombreux fournisseurs de webhooks prennent en charge les nouvelles tentatives ou les flux de réémission lorsqu’un point de terminaison n’accuse pas réception d’une requête avec succès. Du côté récepteur, les applications ont souvent besoin d’une logique de traitement idempotente, afin que le même événement puisse être traité en toute sécurité plusieurs fois sans générer d’actions métier en double.

Cela est particulièrement crucial dans les paiements, la messagerie, la gestion des commandes et l’automatisation de l’infrastructure. Si un événement de paiement réussi arrive deux fois, le récepteur ne doit pas expédier la même commande deux fois. Si un événement de ticket est relancé, le récepteur ne doit pas créer d’enregistrements en double. Les bons consommateurs de webhooks stockent donc les identifiants d’événements, suivent l’état de traitement et séparent l’accusé de réception des effets secondaires en aval dans la mesure du possible.

L’observabilité est un autre aspect de la fiabilité. Les équipes doivent journaliser les transmissions entrantes, enregistrer le statut des réponses, conserver les procédures de reprise lorsque c’est possible et mettre en place une surveillance interne des échecs de webhook. Un webhook n’est utile que si l’événement parvient à sa destination et est traité correctement.

Gestion des versions et contrôle des modifications

À mesure que les plateformes évoluent, les formats de charge utile des webhooks, les schémas d’événements et le comportement de transmission peuvent également changer. Les systèmes matures considèrent donc les webhooks comme des interfaces versionnées. Ils documentent la structure de charge utile attendue, valident les champs obligatoires et gèrent les mises à jour avec précaution lorsque les fournisseurs introduisent de nouveaux formats d’événements ou versions d’API.

Ce point est important car les webhooks sont souvent profondément intégrés dans l’automatisation métier. Une modification de schéma mal gérée peut rompre silencieusement les flux de travail en aval si le récepteur se base sur un ancien format de charge utile. Un contrôle des modifications clair, une analyse défensive et une conception d’intégration respectueuse des contrats permettent de réduire ce risque.

Une conception de webhook sécurisée et fiable inclut généralement la vérification des signatures, la journalisation des transmissions, la prise en charge des nouvelles tentatives et le traitement idempotent des événements.

Cas d’usage courants des webhooks

Plateformes SaaS et automatisation métier

L’un des domaines d’application les plus courants des webhooks est l’intégration SaaS. Les plateformes CRM, les outils de support technique, les systèmes de commerce électronique, les services de facturation, les systèmes marketing et les plateformes de collaboration génèrent tous des événements métier que d’autres systèmes peuvent avoir besoin de consommer. Les webhooks permettent à ces plateformes d’informer les applications internes, les moteurs de flux de travail, les plateformes d’automatisation ou les services partenaires lors de modifications d’enregistrements ou d’actions réalisées.

Dans ce contexte, les webhooks sont souvent utilisés pour connecter des outils cloud sans nécessiter de couches d’intégration personnalisées lourdes. Un événement de création de prospect peut lancer un flux marketing. Un événement de signature de contrat peut mettre à jour un CRM. Un événement de modification d’abonnement peut synchroniser la facturation et le contrôle d’accès. Cela rend les webhooks particulièrement utiles dans les organisations qui dépendent de nombreuses applications spécialisées fonctionnant ensemble.

Systèmes de paiement, commerce électronique et abonnements

Les paiements sont l’un des cas d’usage les plus évidents des webhooks, car de nombreux événements importants se produisent de manière asynchrone. Un paiement peut être validé après authentification du client, un remboursement peut être émis ultérieurement, un litige peut être ouvert ou une facture d’abonnement peut échouer après le processus de paiement initial. Les webhooks permettent aux plateformes de paiement de transmettre ces événements aux systèmes des commerçants afin que le statut de commande, la préparation, la comptabilité et les notifications client restent alignés sur les résultats réels de la transaction.

Les entreprises de commerce électronique et d’abonnements dépendent fortement de ce modèle car il prend en charge la synchronisation continue des états. Plutôt que de supposer que l’état visible lors de la demande de paiement initial est définitif, le commerçant utilise les événements webhook pour gérer le cycle de vie réel de la transaction. Cela réduit les erreurs métier et aide les systèmes en aval à réagir correctement aux modifications ultérieures.

DevOps, contrôle de code source et pipelines CI/CD

Les webhooks sont également profondément intégrés dans les outils de développement. Les plateformes de contrôle de code source peuvent envoyer des événements webhook lors d’un envoi de code, de l’ouverture d’une demande de fusion, de la mise à jour de problèmes ou de la modification des paramètres du dépôt. Les systèmes CI/CD et outils de déploiement écoutent ces événements et réagissent automatiquement en exécutant des tests, en construisant des artefacts, en mettant à jour des environnements de prévisualisation ou en envoyant des messages de statut sur les canaux de collaboration.

Ce domaine d’application montre comment les webhooks renforcent la rapidité opérationnelle. Les développeurs n’ont pas besoin d’appuyer sur un bouton chaque fois qu’une modification de dépôt doit déclencher un pipeline. L’événement lui-même devient le déclencheur, et le reste du flux de travail démarre automatiquement. C’est l’une des raisons pour lesquelles les webhooks sont considérés comme un schéma fondamental dans la livraison de logiciels modernes.

Messagerie, alertes et notifications opérationnelles

Les services de messagerie, les plateformes de téléphonie et les systèmes d’alerte utilisent les webhooks pour signaler les messages entrants, les événements d’appel, les accusés de réception de livraison, les changements d’état et les incidents. Un webhook peut transmettre un événement de message à un CRM, envoyer une mise à jour de statut d’appel à un système de tickets ou acheminer les alertes de surveillance vers un flux de travail de réponse aux incidents. L’application réceptrice peut ensuite agir en fonction du contexte métier et pas seulement des données brutes de l’événement.

Cela est particulièrement utile dans les environnements opérationnels où différents canaux doivent être coordonnés rapidement. Un webhook peut faire office de pont entre une plateforme de surveillance et un système d’astreinte, entre un service de messagerie et un centre de support ou entre une plateforme de gestion de périphériques et un moteur de notifications. Dans tous ces cas, le webhook agit comme le point d’entrée des événements pour un processus de réponse plus large.

Partout où différentes plateformes doivent réagir au même moment métier, les webhooks offrent l’un des moyens les plus simples et pratiques de les connecter.

Comparaison des webhooks avec les API et l’interrogation périodique

Webhook vs modèle de requête API

Un webhook ne remplace pas une API. Les deux ont des finalités différentes. Une API permet au client de demander, créer, mettre à jour ou supprimer des ressources à la demande. Un webhook permet à une plateforme d’informer un autre système qu’un événement s’est produit. Dans de nombreuses intégrations, le webhook fournit le signal et l’API assure l’action de suivi détaillée.

Par exemple, un webhook peut avertir le récepteur qu’une commande a été mise à jour, tandis que le récepteur appelle ensuite une API pour récupérer les détails complets de la commande ou exécuter une autre action. Cela signifie que webhooks et API sont souvent complémentaires plutôt que concurrents. Le webhook apporte l’urgence et la conscience de l’événement, tandis que l’API assure le contrôle et l’interaction directe avec les ressources.

Webhook vs interrogation périodique

Le modèle webhook est également différent de l’interrogation périodique. L’interrogation impose à l’application réceptrice de demander régulièrement au système source si des changements ont eu lieu. Les webhooks inversent cette responsabilité : le système source envoie la notification lorsque l’événement se produit. Cela réduit généralement le volume de requêtes et améliore la ponctualité, notamment pour les événements asynchrones ou irréguliers.

L’interrogation périodique conserve toutefois son utilité dans certaines situations : surveillance de secours, rapprochement périodique ou environnements où l’envoi sortant de webhooks n’est pas possible. Mais dans la plupart des intégrations pilotées par les événements, les webhooks offrent un mécanisme plus efficace et plus réactif pour la notification des changements.

Conclusion

Pourquoi les webhooks sont essentiels

Un webhook est un mécanisme d’intégration pratique piloté par les événements qui permet à une application d’en informer automatiquement une autre lorsqu’un événement se produit. Ses fonctions clés incluent la notification d’événements, le déclenchement de flux de travail et la synchronisation intersystèmes. Sa valeur systémique réside dans la réduction de la charge d’interrogation, l’amélioration du temps de réaction et la prise en charge d’architectures pilotées par les événements plus structurées dans les environnements logiciels modernes.

C’est pourquoi les webhooks sont présents dans autant de plateformes aujourd’hui. Ils sont largement utilisés dans l’automatisation SaaS, le traitement des paiements, les pipelines DevOps, les systèmes de messagerie, les flux d’alertes et les intégrations d’entreprise. Bien que son concept soit simple, son impact opérationnel peut être significatif lorsque les webhooks sont conçus avec une sécurité adaptée, une journalisation, une gestion des nouvelles tentatives et une logique métier appropriée. Dans de nombreux systèmes réels, le webhook est le moment où l’événement d’une plateforme devient une action dans une autre.

FAQ

Un webhook est-il identique à une API ?

Non. Un webhook et une API sont liés mais pas identiques. Une API est généralement utilisée lorsque le client souhaite demander ou manipuler des ressources à la demande. Un webhook est utilisé lorsqu’une plateforme veut informer un autre système qu’un événement s’est produit. L’un est piloté par les requêtes, l’autre par les événements.

Dans de nombreuses intégrations, ils fonctionnent ensemble. Un webhook peut signaler qu’un changement a eu lieu, et une API peut ensuite être utilisée pour récupérer les détails complets ou réaliser des actions de suivi.

Un webhook utilise-t-il systématiquement HTTP POST ?

De nombreux systèmes de webhooks utilisent HTTP POST, notamment lorsque des charges utiles structurées comme JSON doivent être transmises dans le corps de la requête. Cependant, les détails d’implémentation varient selon le fournisseur, et certaines plateformes prennent également en charge d’autres styles de requête ou schémas spécifiques.

L’essentiel n’est pas le verbe HTTP exact. Le point clé est que la plateforme émettrice adresse une requête HTTP sortante vers un point de terminaison configuré lorsqu’un événement se produit.

Pourquoi la sécurité des webhooks est-elle importante ?

La sécurité des webhooks est cruciale car le point de terminaison récepteur peut déclencher des actions métier réelles telles que la mise à jour d’enregistrements, l’expédition de commandes, l’envoi de notifications ou le lancement de flux de travail. Si le récepteur accepte des requêtes non authentifiées, un attaquant pourrait envoyer des événements falsifiés et entraîner des traitements incorrects.

C’est pourquoi les conceptions sérieuses de webhooks utilisent HTTPS, la vérification des signatures, la gestion des secrets, la journalisation des transmissions et une validation rigoureuse des requêtes avant d’exécuter la logique métier.

Quel est le principal avantage d’un webhook ?

Son principal avantage est une communication pilotée par les événements en temps opportun. Un webhook permet à un système d’en informer un autre dès qu’un événement se produit, ce qui réduit le besoin d’interrogations périodiques répétées et permet une automatisation, une synchronisation et une réaction plus rapides.

Cela améliore à la fois l’efficacité technique et la réactivité métier, notamment dans les environnements où plusieurs plateformes doivent rester alignées sur des changements d’état en quasi temps réel.