Que se passe-t-il quand un workflow s’exécute deux fois ou échoue en cours de route ?

Une nouvelle tentative doit savoir ce qui s’est déjà passé.

Une demande peut arriver deux fois. Une personne peut valider deux fois. Une connexion peut échouer alors qu’une partie du workflow s’est déjà exécutée. Ce sont des situations différentes : avant de répéter quoi que ce soit, identifiez la demande, l’action prévue et la preuve de son résultat.

L’exemple conserve la fiche et redemande.

Dans la démo du navigateur, réinitialisez et lancez « Nouvelle intervention ». Cochez « Simuler un échec de connexion sur cette validation », puis « Valider la réponse de démo ». Examinez « Connexion en pause » et son historique. Sélectionnez « Rétablir la connexion d’exemple », relisez le texte et validez. Le bouton de rétablissement décoche la case d’échec pour que la validation suivante puisse terminer l’exemple.

Qu’est-ce qui est conservé, et qu’est-ce qui ne peut pas se répéter ?

Les informations manquantes restent manquantes après le rétablissement. Si une demande incomplète est validée après le rattrapage, elle revient à « En attente de précisions ». Une nouvelle tentative n’invente pas de zone, ne confirme pas de rendez-vous et ne reçoit pas la réponse d’un client.

Un vrai échec partiel est plus difficile.

Imaginez un workflow connecté qui met à jour une fiche d’intervention, puis perd la confirmation avant d’enregistrer la réussite en local. Son statut local peut être incertain alors même que la destination a changé. Répéter tout le workflow pourrait répéter un effet externe.

C’est un cas de production hypothétique ; l’exemple Fireflax ne le simule pas. Une vraie mise en place a besoin d’identifiants durables pour les demandes et les actions prévues, d’un historique conservé des résultats, de vérifications de la destination et d’une règle pour les résultats incertains. La mémoire du navigateur et la correspondance du texte des messages ne suffisent pas à elles seules.

Le kit de démarrage hors ligne conserve un fichier local et propose une commande de pause explicite, mais cela reste une répétition en un seul processus. Il n’établit ni des nouvelles tentatives simultanées sûres, ni une livraison exactement une fois, ni une disponibilité en production, ni un retour arrière entre systèmes.

Utilisez cette checklist de rattrapage.

1. Mettez en pause et conservez. Arrêtez le workflow concerné selon la procédure convenue. Conservez la demande, les versions, l’erreur et les preuves du résultat.
2. Examinez la destination. Vérifiez si le message, la fiche ou l’autre changement prévu a eu lieu. Classez-le comme fait, non fait ou incertain.
3. Évitez un renvoi à l’aveugle. Levez l’incertitude avec la personne responsable et les preuves du système. Vérifiez les identifiants de demande et d’action ainsi que la règle anti-doublon.
4. Rétablissez avec le responsable des autorisations. Réparez ou réautorisez la connexion réelle si nécessaire. Rétablir l’accès n’autorise pas à rejouer toutes les actions.
5. Relisez à nouveau. Revérifiez la dernière demande et tout changement de conversation, de brouillon ou de préférence de contact. Obtenez une nouvelle validation si nécessaire.
6. Vérifiez un seul résultat prévu. N’exécutez que la prochaine action autorisée, examinez son résultat et notez ce qui s’est passé avant de reprendre le travail normal.

Désignez le responsable et le suppléant de ces étapes. Réinitialiser une fiche interne ne peut pas annuler un message déjà envoyé. Toute correction ou annulation demande ses propres autorisations et des limites confirmées.

Gardez les preuves avec la passation.

Les exécutions conservées sur le code source et sur le kit de démarrage couvrent chacune cinq cas définis, dont la validation répétée et la validation en échec avec rattrapage. Elles consignent les entrées synthétiques, les états exacts et l’historique. La suite séparée de 21 tests du dépôt vérifie aussi le rattrapage des informations manquantes. Ces contrôles limités étayent les descriptions ci-dessus ; ils ne garantissent pas la livraison.