Les usages
Une notification webhook a été perdue : faut-il rejouer l’événement ou recalculer l’état ?
Pour vous si… Administrateur d’un raccord qui a manqué des changements dans un espace collaboratif.
Repères documentaires au 8 novembre 2026.
Notre avis
Nous commencerions par déterminer ce que la notification devait maintenir : un état courant ou l’historique d’une action. Pour synchroniser des droits actuels, relire la source de référence peut être plus sûr que rejouer aveuglément un événement ancien. Pour une action métier qui ne doit se produire qu’une fois, il faut aussi identifier ce qui a déjà été exécuté.
Ce qui change le choix
Si le fournisseur garantit un autre mécanisme documenté de reprise, examinez sa portée avant d’ajouter un second rapprochement.
Dans l’ordre
- Créer un objet fictif
- modifier deux fois pendant une interruption simulée autorisée
- reprendre
Pourquoi ce choix
- Rejouer un ancien partage peut contredire une révocation plus récente.
- L’état courant et la trace historique n’appellent pas la même reprise.
Une notification échouée peut rester sans reprise
GitHub documente un service de webhooks qui ne relivre pas automatiquement les livraisons échouées. C’est un exemple officiel du protocole, pas une caractéristique attribuée aux suites de notre sélection. Pour votre connecteur, faites préciser la politique réelle : nouvelles tentatives, durée de conservation des événements, notification d’échec et possibilité de relance autorisée. L’absence d’erreur visible dans la destination ne prouve pas que tous les événements lui sont parvenus.
Un ancien événement peut rétablir un état périmé
Exemple fictif : lundi, un document est partagé avec un partenaire ; mardi, ce droit est retiré. La notification du lundi manque et celle du mardi arrive. Rejouer ensuite le partage sans vérifier l’état courant peut contredire la révocation. Si le but est de maintenir les accès actuels, comparez les identifiants et les droits présents dans la source avec la destination. Si le but est de conserver une trace des deux décisions, gardez l’ordre et les dates sans réappliquer nécessairement leurs effets.
Décider une reprise bornée
Demandez pour un événement fictif son identifiant, sa date, sa tentative de livraison et son résultat cible. Avant de le rejouer, recherchez une exécution déjà réussie : une réponse perdue n’est pas forcément une action perdue. Après reprise, rapprochez le document ou la conversation concernée avec la source. Pour un faible volume, un examen manuel des écarts peut être plus proportionné qu’un mécanisme automatique général. Si le service ne permet ni inventaire de référence ni historique exploitable, conservez cette limite avant de qualifier la synchronisation de fiable.
À vérifier
Analyse de sources publiques et méthode éditoriale ; aucun compte, logiciel, export ou incident réel testé. Les exemples sont fictifs. Les conditions exactes de votre version et de votre contrat restent à confirmer.
Preuves et sources
Les faits documentaires et déclarations sont distingués de nos avis et méthodes. Comment nous travaillons.
Fait documentaire — GitHub documente l’absence de relivraison automatique des livraisons webhook échouées pour son service.
Daté du 8 novembre 2026. Périmètre : Exemple technique uniquement ; politique de la suite collaborative à vérifier. Limite : Exemple du service GitHub ; politique et durée de reprise de votre connecteur à vérifier sans transposition.
Source lue le 8 novembre 2026. Exemple de service sans relivraison automatique des webhooks échoués
Exemple du service GitHub ; politique, durée et mécanisme de reprise propres à votre connecteur à vérifier.
Notre méthode — Prévoyez un rapprochement avec l’état de référence ; ne supposez pas qu’un flux de notifications constitue à lui seul un inventaire complet. Le parcours de réception est proposé, pas exécuté.
Daté du 8 novembre 2026. Périmètre : Administrateur d’un raccord qui a manqué des changements dans un espace collaboratif.. Limite : Avis conditionnel, sans test produit ni validation juridique du cas particulier.