L'automatisation peut rendre un processus commercial plus rapide et plus cohérent.
Une nouvelle commande peut automatiquement mettre à jour le stock.
Un paiement réussi peut automatiquement créer un reçu.
Une demande complétée peut automatiquement notifier l'employé responsable.
Un nouvel enregistrement peut automatiquement déclencher plusieurs actions à travers différents systèmes.
Mais il y a un problème qui devient de plus en plus important à mesure que ces processus se développent :
Que se passe-t-il si le même événement atteint le système deux fois ?
Au début, cela peut sembler être un problème technique mineur.
Ce n'est pas le cas.
Un événement dupliqué peut entraîner un client étant facturé deux fois, un stock étant réduit deux fois, deux messages étant envoyés, ou la même demande étant traitée plus d'une fois.
La partie difficile est que des événements dupliqués peuvent se produire même lorsque chaque système fonctionne normalement.
Des processus automatisés fiables doivent donc être conçus en tenant compte de cette possibilité.
Pourquoi le même événement peut arriver deux fois
Imaginez qu'un système de paiement informe le système d'une entreprise qu'un paiement a été effectué.
Le système de l'entreprise reçoit le message et commence à le traiter.
Mais avant que le système de paiement ne reçoive la confirmation que le message a été traité avec succès, la connexion est interrompue.
Le système de paiement ne sait pas si le message a été traité.
Il envoie à nouveau le même message.
Maintenant, le système de l'entreprise a reçu le même événement deux fois.
Du point de vue de l'expéditeur, le renvoyer est raisonnable.
Du point de vue du système récepteur, la même instruction est apparue deux fois.
Si le système traite chaque message comme un événement complètement nouveau, il peut effectuer l'action deux fois.
C'est pourquoi dire simplement “traiter chaque événement” n'est pas suffisant pour un processus automatisé fiable.
Le système doit également déterminer s'il a déjà traité cet événement.
Donner à chaque événement une identité unique
L'une des manières les plus simples de résoudre ce problème est de donner à chaque événement un identifiant unique.
Par exemple, un événement représentant un paiement complété pourrait contenir un identifiant qui est unique à cet événement.
Lorsque le système le reçoit, il peut vérifier si cet identifiant a déjà été traité.
S'il ne l'a pas été, le système effectue l'action requise.
S'il l'a été, le système ne répète pas l'action.
Au lieu de cela, il peut traiter le message comme un duplicata en toute sécurité.
Cela crée une règle simple :
Le même événement ne devrait produire le même résultat qu'une seule fois.
L'important est que le système ait un moyen fiable de reconnaître l'événement.
Utiliser uniquement des informations telles que le nom d'un client ou le montant d'un paiement n'est généralement pas suffisant car différents événements peuvent avoir les mêmes informations.
L'identifiant doit représenter l'événement lui-même.
Pourquoi une simple vérification de base de données n'est pas toujours suffisante
Une mise en œuvre courante est :
Vérifiez si l'événement existe dans la base de données.
S'il n'existe pas, effectuez l'action.
Enregistrez l'événement comme traité.
Le problème apparaît lorsque deux copies du même événement arrivent presque en même temps.
Les deux processus peuvent vérifier la base de données avant que l'un d'eux n'ait enregistré l'événement.
Les deux voient qu'il n'existe pas.
Les deux continuent.
L'action est effectuée deux fois.
C'est pourquoi la protection contre les doublons doit être conçue comme partie intégrante de l'opération réelle plutôt que d'être ajoutée comme un simple contrôle avant.
Le système a besoin d'un moyen de rendre la vérification et l'enregistrement de l'événement fiables même lorsque plusieurs demandes arrivent ensemble.
L'action elle-même nécessite une protection
Il y a un autre problème important.
Supposons que le système reconnaisse avec succès les événements en double.
C'est utile, mais l'action commerciale réelle doit également être gérée avec soin.
Imaginez un processus automatisé qui reçoit un événement de commande et réduit ensuite le stock.
Si l'événement est enregistré comme traité avant que la mise à jour du stock ne réussisse, un échec au mauvais moment peut créer un problème différent.
Le système peut croire que l'événement a été complété même si l'action réelle ne s'est jamais produite.
S'il enregistre l'événement seulement après que l'action réussisse, un autre problème peut apparaître si l'action réussit mais que le système échoue avant d'enregistrer ce succès.
Une automatisation fiable nécessite donc une gestion soigneuse à la fois de l'événement et de l'action commerciale.
Différentes actions nécessitent une protection différente
Toutes les actions automatisées n'ont pas le même risque.
Envoyer un e-mail deux fois est ennuyeux.
Facturer un client deux fois peut être grave.
Créer le même dossier d'employé deux fois peut causer des problèmes dans d'autres systèmes.
Réduire le stock deux fois peut créer un inventaire inexact.
La conception doit donc prendre en compte ce qui se passe si une action est répétée.
Par exemple, mettre à jour le statut d'un client de « en attente » à « approuvé » peut être sûr à répéter car le résultat final est le même.
Ajouter 100 unités à un solde de compte est différent. Répéter cette opération change le résultat.
Cette distinction est importante lors de la conception d'une automatisation fiable.
Utiliser un enregistrement unique pour protéger une action
Une approche pratique consiste à faire dépendre les opérations importantes d'une référence commerciale unique.
Supposons qu'une commande ait une référence de commande unique.
Lorsque le système reçoit un événement pour traiter cette commande, il peut utiliser la référence pour s'assurer que l'opération pertinente ne peut pas être créée deux fois.
Ceci est particulièrement utile pour des actions telles que :
Créer une facture
Enregistrer un paiement
Créer un envoi
Créer une demande de maintenance
Créer un compte employé
Mettre à jour l'inventaire
La base de données peut faire respecter l'unicité de la référence plutôt que de se fier uniquement au code de l'application.
Cela donne au processus une autre couche de protection.
Que se passe-t-il si le processus s'arrête à mi-chemin ?
Un processus automatisé fiable doit également prendre en compte l'achèvement partiel.
Imaginez qu'un événement de commande déclenche trois actions :
Mettre à jour le stock
Créer une facture
Notifier le client
La première action réussit.
La deuxième action réussit.
Le système s'arrête ensuite avant d'envoyer la notification.
Lorsque le processus redémarre, il ne doit pas exécuter aveuglément les trois actions à nouveau.
Le système doit savoir quel travail a déjà été effectué.
Cela peut être géré en enregistrant l'état du processus et en concevant chaque action de manière à ce qu'elle puisse être réessayée en toute sécurité.
L'idée clé est que un échec temporaire ne doit pas forcer l'ensemble du processus à recommencer depuis le début.
Le réessai fait partie de l'automatisation fiable
Les échecs sont inévitables.
Un service distant peut être indisponible.
Une connexion réseau peut échouer.
Un serveur peut redémarrer.
Une base de données peut temporairement rejeter une demande.
Pour cette raison, les processus automatisés doivent souvent réessayer les actions échouées.
Mais les réessais créent un autre risque de duplication.
Si une action réussit mais que le système ne reçoit pas de confirmation, il peut essayer l'action à nouveau.
Cela signifie qu'un mécanisme de réessai doit être combiné avec une protection contre les doublons.
Le système doit être capable de demander :
« Cette action s'est-elle déjà réellement produite ? »
Si la réponse est oui, il ne doit pas exécuter l'action à nouveau.
C'est l'une des principales différences entre un processus qui fonctionne simplement dans des conditions normales et un qui est conçu pour rester fiable lorsque les choses tournent mal.
Tenir un registre de ce qui s'est passé
Un processus fiable doit laisser derrière lui un enregistrement clair.
Pour chaque événement important, le système doit être capable de déterminer :
Quand l'événement a été reçu
Quel événement c'était
S'il avait déjà été traité
Quelles actions ont été complétées
Quelles actions ont échoué
S'il y a eu une nouvelle tentative d'action
Quel était le résultat final
Cela rend les problèmes beaucoup plus faciles à enquêter.
Sans un tel enregistrement, un employé peut voir que quelque chose s'est produit deux fois mais n'avoir aucun moyen de comprendre pourquoi.
Avec un enregistrement clair, l'entreprise peut identifier si la cause était un événement répété, une nouvelle tentative, une défaillance du système ou une erreur dans le processus lui-même.
Concevoir autour de l'échec au lieu de supposer le succès
Une erreur courante lors de la construction de processus automatisés est de concevoir uniquement pour le chemin réussi.
Le processus est imaginé comme :
L'événement arrive → l'action se produit → le processus se termine.
Les systèmes réels ne sont pas si simples.
Un processus plus réaliste est :
L'événement arrive → l'action commence → quelque chose peut échouer → l'action peut devoir être réessayée → l'événement peut arriver à nouveau → le système doit toujours produire le bon résultat final.
Concevoir pour ces conditions dès le départ rend l'automatisation beaucoup plus fiable.
Cela rend également les changements futurs plus faciles car le processus a déjà des règles claires pour gérer des situations inattendues.
Là où la protection contre les doublons est la plus importante
Tous les processus automatisés n'ont pas besoin du même niveau de protection.
La priorité la plus élevée devrait généralement être accordée aux actions ayant un effet commercial ou financier direct.
Les exemples incluent :
Paiements et remboursements
Changements d'inventaire
Changements de compte client
Dossiers des employés
Factures
Commandes
Demandes de livraison
Demandes de service
Changements d'accès
Une notification de doublon peut être facile à corriger.
Une transaction financière en double peut ne pas l'être.
Comprendre les conséquences de la répétition aide à déterminer où une protection plus forte est nécessaire.
Rendre l'automatisation fiable
Le véritable objectif de la protection contre les doublons n'est pas simplement d'éviter une erreur technique.
Il s'agit de rendre l'automatisation fiable.
Les employés devraient pouvoir compter sur le système sans vérifier constamment si une action s'est produite une fois, deux fois ou pas du tout.
Les clients ne devraient pas avoir à contacter une entreprise parce qu'un processus automatisé les a facturés deux fois.
Les gestionnaires devraient pouvoir faire confiance aux enregistrements d'inventaire et financiers.
Les équipes de maintenance ne devraient pas recevoir plusieurs demandes identiques parce que le même événement de machine a été répété.
Une automatisation fiable ne consiste donc pas seulement à réduire le travail manuel.
Il s'agit de garantir que le travail automatisé produit le bon résultat même en cas de problèmes de communication, de nouvelles tentatives et de pannes système.
Une meilleure façon de concevoir des processus automatisés
Lors de la conception d'un nouveau processus automatisé, le chemin normal de réussite ne devrait pas être la seule chose à considérer.
La conception doit également poser la question :
Que se passe-t-il si le même événement arrive deux fois ?
Que se passe-t-il si l'action réussit mais que la confirmation est perdue ?
Que se passe-t-il si le processus s'arrête à mi-chemin ?
Que se passe-t-il si la même action est réessayée ?
Comment le système sait-il ce qui s'est déjà passé ?
Quelles actions sont sûres à répéter ?
Quelles actions ne doivent jamais se produire deux fois ?
Ces questions peuvent ne pas être visibles pour l'utilisateur final.
Elles sont néanmoins ce qui sépare un simple flux de travail automatisé d'un flux de travail fiable.
Un processus bien conçu ne suppose pas que les messages arriveront exactement une fois ou que chaque système répondra toujours correctement.
Il suppose que des problèmes se produiront et s'assure que le résultat final reste correct.
C'est la base de l'automatisation fiable basée sur des événements.
L'objectif n'est pas simplement de faire fonctionner un processus sans intervention humaine.
L'objectif est de le rendre sûr à faire confiance lorsque personne n'observe chaque étape.