Une intégration reçoit d’abord une mise à jour d’adresse, puis un événement indiquant que le client a toujours son ancienne adresse. Si elle applique les deux messages dans leur ordre d’arrivée, la fiche devient obsolète. Le problème n’est pas que le second événement soit faux : il peut être valide et correspondre à un changement antérieur.
Gérer des événements reçus dans le désordre suppose de distinguer le moment où un changement s’est produit de celui où il a été reçu, puis de déterminer quelle source permet d’établir la valeur à privilégier. Il n’existe pas de règle universelle fondée sur la date. La décision dépend du type d’événement, de la manière dont les données sont générées et du système qui en fait autorité.
Pourquoi des événements arrivent dans le désordre
Une file de messages, un webhook ou un processus d’intégration peuvent introduire un délai entre la génération d’un événement et son traitement. Les livraisons peuvent être relancées, traitées en parallèle ou emprunter des chemins présentant des latences différentes. Ainsi, deux événements concernant la même entité peuvent arriver dans un ordre différent de leur ordre de création. Ils peuvent également être transmis plusieurs fois si l’émetteur réessaie après ne pas avoir reçu de confirmation.
L’ordre peut être préservé au sein d’un flux donné, mais pas entre plusieurs flux. Par exemple, les modifications d’un compte peuvent être réparties entre des partitions, tandis que celles de ses commandes sont traitées indépendamment. Ne partez pas du principe qu’une file ou une API garantit un ordre global, sauf si cette propriété est documentée et respectée dans le parcours réel.
Les conséquences dépendent du contenu :
- Un événement représentant un état complet décrit l’état d’une fiche à un moment donné. Appliqué plus tard, un état ancien peut remplacer des champs plus récents.
- Un événement delta décrit une modification, par exemple l’ajout d’une étiquette ou l’incrémentation d’un compteur. Le rejeter parce qu’il est ancien peut faire perdre une modification légitime qui n’avait pas encore été appliquée.
Avant de choisir une règle, déterminez si les messages représentent des états complets, des modifications partielles ou une combinaison des deux. La stratégie adaptée à la mise à jour d’un profil ne conviendra pas forcément à une opération financière ou à une transition de commande.
Réception, horodatage de l’événement et séquence métier
L’heure de réception indique quand le système consommateur a observé le message. Elle permet de mesurer le délai et d’ordonner ce qui a été reçu par ce consommateur, mais ne prouve pas quand le changement initial a eu lieu.
L’horodatage de l’événement est censé refléter le moment où le changement s’est produit ou a été enregistré. Il peut être utile au diagnostic, mais dépend des horloges, de leur précision et des conventions de l’émetteur. Deux systèmes peuvent avoir des horloges désynchronisées, et un événement généré lors d’une reprise peut porter une heure qui ne reflète pas précisément l’ordre métier. Une date plus récente ne suffit pas, à elle seule, à établir la précédence.
La séquence métier exprime l’ordre important pour une entité : par exemple, la version 12 d’une fiche succède à la version 11, ou une opération est confirmée après une autre. Si le système source fournit une version monotone ou un numéro de séquence fiable associé à la même entité, c’est généralement un indicateur plus solide que l’heure. Vérifiez toutefois sa portée : cette valeur peut être réinitialisée, être locale à un processus ou ne pas permettre de comparer les modifications de différentes entités.
Enregistrez ces valeurs séparément. Ne réutilisez pas un champ unique nommé « date » pour déterminer la précédence, mesurer les retards et conserver une trace d’audit : chaque usage exige une interprétation claire.
Reconnaître une mise à jour obsolète sans perdre de changements valides
Une mise à jour n’est obsolète que par rapport à une règle définie et à l’état actuel connu du consommateur. Par exemple, si celui-ci a conservé la version 18 d’un client et reçoit un état complet de la version 16, il peut le rejeter comme antérieur. En revanche, il ne devrait pas écarter automatiquement un delta valide parce que son horodatage est plus ancien : il peut ajouter une information absente de l’événement ultérieur.
Pour évaluer chaque message, vérifiez :
- L’identité et la portée : l’entité, le champ ou l’agrégat concerné. Deux modifications peuvent être indépendantes et ne pas nécessiter de choisir entre elles.
- Le type et la version : le message contient-il un état complet ou un delta, et sa séquence peut-elle être comparée à celle déjà appliquée ?
- Les préconditions : la transition est-elle valide à partir de l’état actuel ? Un changement vers « expédiée » ne devrait pas annuler sans explication une commande déjà « livrée ».
- L’autorité : quel système peut déterminer la valeur de ce champ ? Une mise à jour de profil et une correction provenant du système maître n’ont pas nécessairement le même poids.
La comparaison et l’écriture doivent être cohérentes. Si deux consommateurs lisent la version 16 et tentent tous deux d’enregistrer des changements, une vérification effectuée avant l’écriture peut devenir obsolète. Utilisez une mise à jour conditionnée par la version observée, ou une opération équivalente dans le stockage. Le consommateur pourra ainsi détecter que la fiche a changé avant la validation de sa propre mise à jour.
Critères de résolution des conflits
Privilégiez l’indicateur le plus fiable réellement disponible ; ne créez pas de hiérarchie fictive à partir de champs qui ne garantissent pas l’ordre. Ces critères peuvent être combinés, à condition que leur signification soit documentée :
- Version ou séquence par entité : acceptez l’état complet si la version progresse ; ignorez une version déjà appliquée ou antérieure. Définissez la marche à suivre en cas de saut, de réinitialisation ou de version manquante.
- État et transition autorisée : validez la modification au regard d’une machine à états ou de règles métier. Une transition invalide doit entraîner un examen, et non devenir silencieusement une mise à jour.
- Autorité par champ : attribuez chaque donnée à un système responsable. Si deux sources peuvent légitimement modifier le même champ, établissez une politique explicite, par exemple un examen ou une priorité convenue, plutôt qu’une règle improvisée du « dernier message reçu ».
- Comparaison du contenu : appliquez des deltas idempotents lorsque c’est possible et évitez de remplacer une fiche entière par un message partiel. Si l’événement ne permet pas de savoir ce qui a changé, consultez la source de vérité avant d’écraser des données.
La règle du « dernier enregistrement gagnant » peut convenir à des champs peu critiques si les horloges et la politique sont suffisamment maîtrisées. Ce n’est pas une règle neutre : elle peut effacer des changements valides et masquer des conflits. Pour les décisions sensibles, mieux vaut conserver les deux versions ou bloquer la résolution automatique.
Que faire en l’absence de séquence fiable
Lorsque l’émetteur ne fournit pas de version comparable, n’essayez pas de déduire un ordre exact à partir de l’heure de réception. Choisissez une réponse proportionnée aux conséquences d’une erreur :
- Consulter l’état actuel auprès du système source avant la mise à jour, si une API de lecture fiable existe. Cela réduit la dépendance à un message en retard, même s’il faut tenir compte du fait que la lecture et l’écriture peuvent aussi entrer en concurrence avec des changements ultérieurs.
- N’appliquer que les champs indépendants si l’événement indique clairement ce qui a été modifié. Conservez les autres valeurs et évitez les remplacements complets.
- Mettre le conflit en attente de rapprochement si le contexte manque ou si la donnée est importante. Conservez le message, l’entité et le motif de la décision pour permettre un examen.
- Définir la priorité des sources lorsque les règles métier déterminent quel système fait autorité pour une donnée. Communiquez cette règle aux équipes et examinez ses exceptions.
Une file d’examen ou une consultation ultérieure ne doit pas devenir une zone d’attente invisible. Déterminez qui traite ces cas, comment les tentatives sont relancées et quel indicateur signale leur résolution. S’il est impossible de trancher automatiquement, rendre l’incertitude visible est plus sûr que de présenter comme actuelle une donnée douteuse.
Tests et journaux pour vérifier le comportement
Testez le contrat d’intégration, et pas seulement le parcours idéal. Pour une même entité, envoyez deux modifications dans l’ordre inverse ; répétez un événement déjà traité ; retardez-en un lors d’une nouvelle tentative ; et faites en sorte que deux mises à jour soient écrites presque simultanément. Incluez des versions identiques, manquantes ou inattendues si ces cas sont possibles à la source.
Vérifiez non seulement la valeur finale, mais aussi la décision prise : accepté, ignoré comme doublon ou événement obsolète, fusionné, mis en attente ou rejeté en raison d’une transition invalide. Assurez-vous que les messages répétés ne produisent pas d’effets supplémentaires et que des événements valides ne sont pas perdus à cause d’une règle fondée uniquement sur les dates.
Enregistrez l’identifiant de l’événement, l’entité, la source, la version ou séquence disponible, l’heure de l’événement et celle de réception, les versions avant et après, ainsi que le motif de la décision. Évitez d’inclure des données personnelles inutiles dans les journaux. Surveillez l’ancienneté des messages et le volume des conflits : leur hausse peut signaler des retards, des nouvelles tentatives ou un changement chez l’émetteur, et pas nécessairement une défaillance du consommateur.
Décisions à prendre avant la mise en service de l’intégration
- Chaque message représente-t-il un état complet, un delta ou les deux types ?
- Quel champ établit la précédence, et qui garantit sa portée et sa continuité ?
- Quel système fait autorité pour chaque donnée, et quelles modifications chaque source peut-elle accepter ?
- Comment éviter les doublons et les écritures concurrentes qui invalident une vérification ?
- Que se passe-t-il en cas de séquence manquante, de transition invalide ou de conflit ambigu ?
- Qui examine les cas mis en attente, et comment mesurer le délai avant leur résolution ?
En pratique, il s’agit d’utiliser l’indicateur d’ordre le plus fiable disponible, de limiter chaque événement aux données qu’il modifie réellement et de rendre l’incertitude explicite. Un message retardé peut ainsi être reconnu sans écarter aveuglément des changements légitimes ni laisser une ancienne mise à jour écraser l’état en vigueur.