Un workflow IA met à jour une opportunité, puis perd la connexion avant de recevoir la confirmation. Doit-il recommencer ?
S’il s’arrête, le dossier reste incomplet. S’il relance toute la mission, il peut créer une deuxième tâche, doubler une note ou envoyer deux messages. Ce risque apparaît dès qu’un travail traverse plusieurs outils.
Un système fiable doit reprendre après un incident sans confondre une nouvelle intention avec une nouvelle tentative.
Un délai dépassé ne prouve pas un échec
Une requête peut ne jamais avoir atteint le service, ou avoir été exécutée sans que sa réponse revienne. Relancer peut donc répéter l’effet.
L’opération doit être idempotente : rejouer la même demande ne produit pas un deuxième effet. AWS et Stripe appliquent ce principe au moyen d’une clé d’idempotence.[1][2]
Donner une identité stable à chaque intention
Chaque action reçoit une clé stable dès son déclenchement. Toutes les reprises de cette même intention conservent la clé ; une nouvelle décision humaine en reçoit une nouvelle.
Après un rendez-vous, la mise à jour CRM, la tâche et le brouillon sont trois opérations distinctes, sans clé générale commune.
Une bonne clé :
- identifie une seule opération logique ;
- reste identique pendant ses reprises ;
- change lorsqu’une nouvelle intention est formulée ;
- ne contient aucune donnée personnelle inutile.
Conserver un journal vérifiable
La clé reconnaît l’opération. Un journal durable indique son état, son étape, sa version validée, son identifiant externe et la raison d’un blocage.
Si une clé terminée revient, le résultat existant est renvoyé. Si son contenu diffère, sa réutilisation est bloquée. Microsoft recommande aussi de conserver l’identifiant traité afin d’ignorer un message répété.[2][3]
Matrice de reprise après incident
| État observé | Preuve disponible | Reprise | Humain |
|---|---|---|---|
| Aucune trace | Aucun effet commencé | Démarrer | Non, si autorisé |
| En cours, avant action | Journal arrêté avant l’appel | Reprendre l’étape | Non |
| Terminé | Résultat conservé | Retourner l’existant | Non |
| Résultat externe retrouvé | Référence côté outil | Réconcilier, poursuivre | Selon sensibilité |
| Résultat externe incertain | Réponse perdue | Ne pas répéter | Oui |
| Même clé, contenu différent | Version incompatible | Bloquer | Oui |
Cet artefact force l’équipe à définir la preuve attendue avant d’automatiser la reprise.
Exemple PME, à titre illustratif
Après un rendez-vous, le workflow prépare un compte rendu, propose des champs CRM, crée une tâche et conserve un email en brouillon.
Le CRM accepte les champs, mais le worker s’arrête avant d’enregistrer la réponse. Au redémarrage, il recherche la modification liée au dossier et à la version validée. S’il la retrouve, il conserve son identifiant et continue sans réécrire les champs.
La tâche possède sa clé. L’email reste en brouillon : reprendre sa génération ne vaut jamais autorisation d’envoi. Si son destinataire ou sa version change, le workflow s’arrête.
Tester les coupures, pas seulement le chemin normal
Les tests doivent provoquer une panne avant l’appel, après l’envoi mais avant la réponse, après l’effet mais avant le journal, pendant deux traitements concurrents, avec un contenu modifié et avec un événement ancien.
Il faut compter les effets réels dans l’outil destinataire. Une mention locale « terminé » ne prouve pas qu’une tâche unique existe.
Limites
L’idempotence ne répare ni mauvaise décision ni donnée fausse : elle évite de répéter un effet. Sans clé native, il faut rapprocher le journal du résultat externe. Sans identifiant fiable, l’incertitude doit rester visible et être transmise à une personne plutôt que masquée par une relance.
Perspective Pulse
Un employé IA fiable montre ce qui a été fait, reprend au bon endroit et s’arrête si l’effet reste incertain. Les outils existants sont conservés ; journal et clés rendent leur coordination vérifiable.
Le Diagnostic Pulse peut cartographier un workflow créant tâches, brouillons ou mises à jour CRM, puis repérer où une réponse perdue risque de dupliquer une action.
Sources
[1] https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/ [2] https://docs.stripe.com/api/idempotent_requests [3] https://learn.microsoft.com/en-us/azure/architecture/patterns/idempotent-consumer