Workflow IA après panne : retrouver l’effet avant de reprendre

Le traitement extrait un montant, une personne valide et le workflow écrit dans une application métier. La connexion se coupe avant l’enregistrement du résultat local. Le dossier reste en attente, alors que la cible peut déjà avoir appliqué l’opération. Relancer tout le traitement crée un risque de double effet ; le fermer comme réussi sans preuve masque une situation encore indéterminée.

En pratique, la reprise doit retrouver ce qui a été préparé, autorisé et effectivement constaté avant de choisir son prochain geste. Une proposition enregistrée ne prouve pas son application ; une intention d’appel ne prouve pas son échec. La transformation d’un processus métier avec l’IA doit donner à chaque étape un état et une sortie conservée, puis traiter explicitement l’incertitude de la frontière distante.

Seize scénarios sur deux fichiers SQLite indépendants interrompent le parcours avant ou après l’effet de sa cible fictive. La préparation est fixée à la main ; aucun modèle IA ni API distante n’intervient. Les exceptions injectées et reconnexions vérifient des transitions locales, sans certifier un moteur d’exécution durable. L’accompagnement IA sur mesure de Dawap peut partir de cette fenêtre d’incertitude pour qualifier l’identifiant d’opération, la consultation de résultat et le contrat de répétition offerts par votre SI.

Pour qui une panne laisse un dossier ambigu

Identifier la rupture entre travail préparé et effet métier

Le problème apparaît lorsqu’un dossier combine analyse documentaire, validation et écriture dans un système séparé. Une panne peut survenir avant la préparation, après son enregistrement ou après l’appel de la cible. Ces moments ne demandent pas la même reprise. L’équipe doit savoir quelle preuve manque, quelles données sont conservées et quelles capacités restent autorisées avant de proposer un bouton relancer.

La cible fictive reçoit une opération OP36 pour le dossier W36, avec 120 unités sans valeur économique réelle. Le journal conserve proposition, approbation, intention et reçu. Cette séparation rend visible une panne après effet mais avant reçu. Dans une application réelle, le contrat doit porter ressource métier, identifiant d’action et paramètres utiles au rapprochement, sans déduire la réussite d’un simple changement de statut d’écran.

Définir le sens de reprendre pour chaque étape

Reprendre peut signifier réutiliser une proposition, retrouver un résultat distant, demander une nouvelle validation ou s’arrêter pour investigation. Recommencer depuis l’entrée n’est qu’une option parmi ces gestes. Le responsable du processus choisit lesquels conservent la décision de la personne et la cohérence du dossier. Une reconstruction doit également indiquer ce qu’elle a abandonné de l’ancien parcours et pourquoi cette différence est acceptable.

Un traitement de lecture sans conséquence métier peut tolérer une nouvelle analyse, selon son coût et ses sources. Une écriture déjà préparée exige de préserver son identité et son contenu. Une compensation éventuelle constitue encore une opération métier, avec ses propres droits et effets. Elle ne doit pas être appelée automatiquement pour faire ressembler un dossier ambigu à un dossier qui n’a jamais commencé.

Séparer préparation, intention et résultat constaté

Enregistrer ce que chaque état permet réellement de conclure

Prepared signifie que la proposition est conservée. Approved signifie que l’approbation du banc correspond à son contenu. Intent signifie que le journal a enregistré le projet d’écrire, sans savoir nécessairement ce que la cible a fait. Done possède un reçu rapproché. Ces noms décrivent les informations acquises, pas une promesse de succès ni un permis de passer directement à l’étape suivante.

La reprise ne considère pas intent comme un échec. Deux cas peuvent posséder ce même état local avec un effet cible différent. W36-07 a déjà produit l’opération, W36-08 n’a rien envoyé ; le lookup est indisponible dans les deux essais. Ils reçoivent effect_unknown. Le service suspend donc le geste sans prétendre savoir lequel des deux faits se cache derrière son journal incomplet.

Choisir ce qui traverse le redémarrage

La sortie de préparation, sa révision, la décision et le reçu doivent pouvoir être retrouvés après perte de la mémoire du worker. Une simple variable locale ou un log de diagnostic ne constitue pas nécessairement cette source de reprise. Le laboratoire ferme puis rouvre les connexions aux fichiers conservés. Il montre que ces données restent lisibles dans ces conditions, sans tester les garanties d’un stockage après panne matérielle.

La documentation Temporal sur l’exécution de workflow décrit le replay à partir de l’historique d’événements. Ce mécanisme organise la reprise selon les contraintes de sa plateforme. Notre programme n’utilise ni Temporal ni son historique ; il conserve quelques états dans SQLite. Les garanties d’un runtime choisi doivent être vérifiées dans son intégration effective avec les activités et les effets métier.

Conserver la proposition que la personne a validée

Éviter qu’un nouveau calcul remplace silencieusement l’ancienne décision

Une extraction IA peut produire une autre proposition lors d’un nouvel appel, même lorsque le dossier porte le même nom. Le modèle, le prompt ou la source peuvent avoir changé. Si la personne avait validé le premier résultat, la reprise ne peut pas attribuer cette validation au second sans contrôle. Il faut distinguer conservation d’une décision et nouvelle instruction du dossier, avec leurs responsabilités respectives.

{"amount":120,"dossier":"W36","sourceRevision":1}

Le banc conserve cette proposition exacte et son approbation. Chaque scénario prépare une seule fois ; après interruption, la reprise retrouve la valeur au lieu de fabriquer une deuxième sortie. Ce comptage prouve seulement le comportement du programme sur une valeur fixe. Il ne mesure pas une économie d’appels LLM ni la variabilité d’une extraction, car aucun modèle n’est lancé dans cette expérience.

Décider quand la sortie conservée devient impropre

Une proposition persistée ne reste pas automatiquement applicable pour toujours. Son contrat peut dépendre d’une pièce, d’une règle et d’une ressource métier datées. Le processus doit nommer ces dépendances et décider quand leur changement exige un réexamen. Le laboratoire conserve sourceRevision à 1 et refuse une nouvelle écriture lorsque la révision courante injectée vaut 2 ; il ne recalcule pas lui-même la nouvelle proposition.

La documentation LangGraph sur la persistance présente des checkpoints associés à l’exécution et à son thread. Un checkpoint aide à retrouver un état, mais son existence ne démontre pas que la proposition correspond encore à la source ou à l’approbation courante. Aucun graphe LangGraph n’est exécuté ici ; cette vérification métier doit rester explicite quel que soit le support retenu.

Écrire l’intention avant de toucher la cible

Donner une identité stable au geste qui va sortir du workflow

Le journal enregistre intent avant l’appel d’OP36. Cette étape permet de retrouver quel geste était prévu si l’exécution s’interrompt autour de la frontière distante. L’identifiant reste celui de l’opération métier ; il ne change pas à chaque tentative réseau. Le dossier conserve le contenu exact qui lui est associé, afin qu’un résultat ultérieur puisse être rapproché à la demande initiale.

Cas concret : W36-04 s’interrompt après intention mais avant envoi. À la reprise, le lookup local constate l’absence d’OP36 dans la cible. Le contrat idempotent fictif est actif, l’autorisation et la source sont inchangées ; le workflow transmet alors la même opération. Un seul effet et un seul appel cible sont comptés. La répétition de intent_saved dans le journal reflète cette reprise, pas deux écritures métier.

Reconnaître la fenêtre que le journal ne ferme pas

Enregistrer l’intention puis appeler la cible crée une fenêtre entre deux systèmes. La transaction du premier ne couvre pas automatiquement l’effet du second. Le programme peut tomber avant l’envoi, après son application ou après réception de la réponse. Un état local unique ne distingue pas tous ces moments. La recette doit provoquer ces coupures plutôt que déduire le résultat de l’ordre idéal du code.

Notre cible SQLite est un deuxième fichier, sans transaction commune au journal. Elle rend cette séparation observable dans le laboratoire, mais ne reproduit pas des réponses réseau retardées ou une cohérence éventuelle. La production doit examiner publication, accusé et lecture de statut dans son propre contrat. Une absence momentanée dans une recherche distante ne suffit pas toujours à prouver qu’une opération n’a jamais été reçue.

Retrouver le reçu quand le journal manque de résultat

Rapprocher avant d’augmenter le nombre de tentatives

W36-05 applique OP36 dans la cible, puis s’interrompt avant d’enregistrer le reçu local. La reprise cherche cette opération, retrouve son contenu et conserve son reçu avec receipt_reconciled. Elle ne renvoie aucune écriture. Le résultat est completed avec un effet, un appel et une préparation. Le workflow termine à partir d’un fait retrouvé, plutôt qu’à partir d’une hypothèse sur la panne.

Lorsque le lookup devient indisponible dans W36-07, le même effet existe mais le journal reste intent. Le verdict effect_unknown conserve cette incertitude et suspend la reprise. Le délai d’attente ou le nombre de tentatives doit avoir un propriétaire et un seuil d’escalade définis dans le service réel. Une attente sans décision exploitable reporte le problème sur le support et laisse les dossiers s’accumuler.

Ne pas transformer une preuve contradictoire en réussite

W36-15 trouve OP36 avec un contenu différent de la proposition conservée. Le verdict effect_conflict ne ferme pas le dossier comme réussi. Un identifiant connu ne suffit pas si la demande et le résultat ne correspondent plus. Le service doit préserver les deux preuves et instruire l’écart, avec des accès limités aux données de rapprochement et une procédure qui n’ajoute pas une deuxième opération pour masquer le conflit.

Paradoxalement, suspendre la reprise peut mieux préserver le résultat métier qu’un worker qui paraît progresser à chaque relance. Le coût caché d’une clôture forcée comprend recherche des doublons, corrections manuelles et justification de décisions. La supervision doit distinguer attente technique, effet inconnu et conflit avéré. Les trois états ne demandent ni la même priorité ni les mêmes droits pour le geste suivant.

Rejouer la même opération avec le même contenu

Vérifier le contrat idempotent au-delà du nom de la clé

La cible du laboratoire conserve OP36 comme clé unique, avec paramètres et reçu. Une nouvelle demande identique retrouve le résultat ; une demande sous cette clé avec 121 unités au lieu de 120 est refusée. W36-16 appelle directement la cible après clôture pour éprouver ces deux comportements. Il compte trois appels au total et un seul effet. Cette sonde n’est pas une nouvelle décision du workflow.

La référence AWS sur les retries et l’idempotence distingue identifiant d’intention et paramètres associés. Elle décrit le refus d’une demande qui reprend le même identifiant avec une intention différente. Le contrat réel doit aussi préciser portée de la clé, conservation et réponses tardives. Une chaîne de caractères appelée idempotency_key ne prouve pas que toutes les opérations d’une API possèdent ces garanties.

Fermer le rejeu lorsque le contrat n’est pas établi

W36-09 reprend après intention, avant envoi, avec contrat idempotent désactivé dans le banc. Le lookup trouve une absence, mais la politique locale suspend le nouvel appel : replay_not_supported. C’est un choix conservateur du laboratoire, pas une obligation universelle. Dans une cible réelle, un résultat négatif peut arriver avant une ancienne requête retardée ; il faut justifier la sécurité d’une nouvelle tentative avec le contrat disponible.

Le workflow ne crée pas un nouvel identifiant pour sortir de cette incertitude. Ce geste ferait passer une reprise pour une opération distincte. Le responsable métier peut décider une nouvelle action après rapprochement, mais elle doit avoir sa propre décision et sa relation avec la précédente. Le budget de reprise doit intégrer les appels de statut et les escalades, plutôt que mesurer seulement le coût de l’analyse initiale.

Réexaminer source et autorisation avant une nouvelle écriture

Conserver les conditions de la proposition pendant l’attente

W36-10 change la source après approbation ; W36-11 retire l’autorisation d’écrire ; W36-12 remplace l’approbation par un autre contenu. Les trois essais ferment l’appel avant intention, avec zéro effet cible. La reprise doit établir que la proposition reste celle qui a été validée et que le prochain geste demeure permis. Une validation ancienne ne donne pas au worker un droit permanent sur la ressource.

La révision courante et le droit sont injectés par le laboratoire au nouveau tour. Aucun connecteur d’habilitation ni document réel n’est interrogé. Une production doit identifier leur source d’autorité et les vérifier au point qui décide l’écriture. Les dépendances peuvent inclure règle applicable, cible, montant et version de dossier. Le seuil de validité relève du processus ; il ne doit pas être inventé pour obtenir davantage de reprises automatiques.

Préserver un effet déjà constaté malgré une condition devenue caduque

Exemple concret : W36-13 change la source après application de l’effet, avant reçu local. Le rapprochement conserve ce reçu et renvoie completed_source_changed. Il ne prétend pas que l’ancienne proposition serait encore admissible pour une nouvelle écriture. Il constate une opération déjà appliquée et signale le changement. Si le métier exige une correction, celle-ci devra être instruite comme une nouvelle décision.

W36-14 retire le droit d’écrire après l’effet. Le programme retrouve le reçu et termine sans nouvelle écriture. Cette autorisation fictive porte seulement sur un prochain envoi ; elle ne représente pas les droits de lecture du reçu. Le système réel doit définir ces deux capacités séparément. Empêcher une nouvelle action ne doit pas effacer un fait déjà produit, et enregistrer ce fait n’autorise pas sa répétition.

Seize scénarios après interruption et reconnexion

Placer les interruptions autour des preuves conservées

Le programme provoque une exception aux points choisis, ferme ses connexions puis les rouvre sur les fichiers. Les cas avant et après effet sont séparés, tout comme source modifiée, autorisation retirée et preuve contradictoire. Chaque résultat comprend étape locale, préparation, effets, appels et événements. La cible comptabilise les demandes reçues distinctement des opérations appliquées, ce qui permet de voir une reprise sans confondre appel et effet.

Les seize cas préparent une seule fois. Les unités, identifiants et interruptions sont fictifs. Le nombre d’effets correspond à la table de la cible locale ; il ne compte aucun appel de modèle. Le tableau présente effets et appels dans cet ordre. Les journaux des scénarios après effet utilisent receipt_reconciled, alors que le parcours nominal termine avec receipt_saved.

Comparer les cas qui partagent un état mais pas la même réalité

W36-07 et W36-08 reçoivent le même verdict d’incertitude, alors que leur cible contient respectivement un et zéro effet. Cette paire vérifie que le worker ne devine pas à partir d’une intention locale. W36-05 possède un résultat vérifiable et peut terminer sans renvoi. Le contraste aide le responsable à décider ce qui demande un moyen de rapprochement plutôt qu’un mécanisme de retry plus agressif.

La sonde W36-16 retrouve d’abord le reçu pour la même proposition, puis refuse le contenu différent. Son état local reste done avec le reçu initial ; le verdict final de la sonde ne transforme pas cette opération passée en échec. Les preuves doivent conserver cette chronologie. Le statut du dernier appel, le résultat du dossier et les effets déjà appliqués constituent des informations différentes.

Délimiter la preuve du laboratoire local

Ne pas attribuer à la reconnexion les garanties d’un runtime complet

Les deux fichiers sont manipulés avec SQLite 3.53.1. L’interruption est une exception contrôlée ; le processus Python ne subit pas de destruction OS ni de panne électrique. Les connexions sont rouvertes dans le même programme. Le résultat ne mesure donc pas la résistance du stockage à un arrêt matériel, la disponibilité d’un cluster ou la reprise après migration du code de workflow.

Le changement d’état et son événement de diagnostic sont enregistrés par deux commits locaux successifs. Aucun arrêt entre eux n’est injecté. Une production doit choisir les éléments qui exigent une conservation atomique, notamment sortie, état et preuve de décision. Le laboratoire n’établit pas une garantie globale de journal exhaustif. Il ne remplace pas la recette de la transaction, du stockage et du runtime retenus.

Tester les conditions distantes et les traitements concurrents

Le lookup lit une table locale cohérente après commit, sans réponse tardive. Le programme ne teste pas un statut éventuellement cohérent ni la conservation limitée d’une clé par un fournisseur. Aucun worker concurrent ne tente la même opération. La clé primaire assure l’unicité dans le parcours séquentiel exécuté ; elle ne démontre pas seule que tout le contrat de demande, effet et reçu fonctionne sous concurrence réelle.

Une recette de production doit aussi provoquer changement de version, double livraison de message et coupure au point réellement distant. Pour un outil de réservation ERP, elle vérifie pièce, quantité et référence d’opération selon l’interface disponible, sans supposer qu’une recherche par dossier constitue un reçu. Un ancien checkpoint peut porter un schéma que le nouveau code ne sait plus interpréter. Le déploiement doit conserver une stratégie de migration ou de traitement des dossiers déjà ouverts.

Erreurs fréquentes dans la reprise d’un dossier IA

Confondre le dernier statut technique avec le résultat métier

Une erreur réseau peut suivre une opération appliquée. Un worker terminé peut avoir seulement préparé une proposition. Le support doit retrouver les preuves propres à chaque étape avant de relancer ou fermer le dossier. Un signal faible est une augmentation des relances accompagnée de davantage de corrections métier, malgré un tableau de bord technique redevenu vert. Le processus doit rendre visible l’effet qu’il essaie de préserver.

Créer une nouvelle clé à chaque relance empêche la cible de reconnaître le geste initial. Rejouer l’analyse peut ensuite modifier les paramètres tout en conservant l’ancien accord. Ces deux erreurs se renforcent : le résultat paraît neuf, alors que le dossier porte encore une décision passée. La reprise doit conserver identité et sortie, ou ouvrir explicitement une nouvelle instruction avec le lien vers les faits antérieurs.

Transformer l’absence de preuve en permission de recommencer

Un lookup indisponible n’établit pas l’absence d’effet. Une recherche par libellé peut trouver une opération semblable produite par un autre traitement. Le contrat de rapprochement doit nommer identifiant, périmètre et paramètres vérifiés. Si cette preuve manque, le service conserve l’incertitude et attribue la résolution. Une personne ne doit pas avoir à cliquer plusieurs fois pour découvrir si la première tentative avait réussi.

Un autre signal apparaît lorsque des dossiers restent longtemps en attente sans motif distinct ni responsable. Le retry masque alors une dette de décision et consomme des appels sans information nouvelle. Il faut définir une limite de tentatives, un délai de revue et un chemin manuel qui conserve l’opération concernée. L’escalade reçoit proposition, intention et observations, plutôt qu’un message générique demandant de tout recommencer.

Plan d’action pour une reprise explicable

Le contrat décrit entrée, sortie et preuve conservée de chaque étape. La responsabilité du dossier appartient au processus, même lorsque préparation et écriture dépendent de services différents. L’instrumentation relie proposition, approbation, tentative et reçu. Le repli conserve un effet inconnu sans le convertir en échec ; les personnes autorisées doivent pouvoir retrouver les observations nécessaires à la prochaine décision.

1. Cartographier les frontières avant les retries. Listez calculs, validations et effets, puis identifiez leurs stockages et transactions. Distinguez la sortie qui peut être recalculée de celle qui a déjà soutenu une décision. Nommer les fenêtres ambiguës permet de choisir où enregistrer une intention et quelle preuve rechercher après interruption.
2. Conserver la décision et ses dépendances. Stockez proposition, versions sources et approbation liée au contenu. Vérifiez ressource et droit avant une nouvelle écriture. Définissez les changements qui exigent un réexamen, puis gardez l’ancienne décision comme fait historique sans la déplacer silencieusement sur une sortie nouvellement générée.
3. Établir le contrat de la cible. Vérifiez clé d’opération, égalité de paramètres, conservation du reçu et comportement des répétitions. Testez la lecture de statut et sa cohérence, avec réponses tardives et droits nécessaires. Si la reprise sûre n’est pas prouvée, suspendez ce geste et attribuez le rapprochement au responsable convenu.
4. Couper autour de l’effet puis rapprocher les preuves. Injectez interruption avant envoi, après application et après reçu. Ajoutez indisponibilité du statut et contenu contradictoire. Comptez effets, appels et préparations séparément. Conservez aussi un parcours favorable afin de vérifier que les restrictions n’empêchent pas toute clôture utile.
5. Organiser l’exploitation des dossiers ouverts. Fixez délais d’escalade et limites de tentatives, avec procédure manuelle et accès aux observations. Préparez changement de version et retour arrière du code. La reprise doit retrouver un état explicable pour chaque dossier, y compris lorsque le worker ou la configuration qui l’a ouvert ne sont plus disponibles.

Le rollback doit préciser ce qui peut revenir en arrière : code d’étape, configuration et ouverture de nouvelles missions. Il ne supprime pas un effet métier passé par simple restauration du service. La responsabilité d’une compensation doit rester explicite, avec sa décision et sa traçabilité. La recette de retour vérifie les sorties et dépendances des dossiers ouverts avant de remettre leurs reprises en circulation.

Commencez par une frontière où résultat et rapprochement sont observables. Différez les écritures dont la cible ne permet pas encore d’expliquer une interruption ambiguë. Le nombre de workers ou la vitesse de relance ne corrige pas ce manque. L’amélioration utile consiste à rendre une prochaine décision possible sans perdre la proposition validée ni confondre les tentatives avec les opérations réellement appliquées.

Guides pour états, qualification et validation en attente

Préserver le dossier comme unité de travail

Le dossier métier IA avec états et exceptions fixe les sorties et responsabilités du processus complet. La reprise présentée ici précise les fenêtres autour d’une écriture. Le dossier conserve les preuves entre préparation et clôture, sans être réduit à la dernière tentative technique d’un composant.

La qualification des demandes avec routage et abstention distingue information suffisante et orientation à revoir. Rejouer après panne doit conserver cette décision ou expliquer son réexamen. Une nouvelle classification ne doit pas déplacer un dossier déjà validé vers une autre file sans laisser la trace de ce changement.

Réexaminer la validité d’une décision avant un prochain effet

La validation IA pendant une attente et après expiration précise les dépendances qui rendent une approbation encore utilisable. La reprise après interruption ajoute une question distincte : le geste a-t-il déjà été appliqué ? Les deux contrôles se rencontrent avant nouvel envoi, mais un reçu passé reste un fait à conserver.

La séparation de proposition, autorisation et résultat aide aussi le support à choisir un interlocuteur. Une donnée source changée appelle son propriétaire, une permission retirée le système d’habilitation, et un effet ambigu la capacité de rapprochement de la cible. Le processus transmet les preuves utiles à chacun, avec les accès convenus et un statut que la personne responsable du dossier peut expliquer.

Conclusion : reprendre depuis les faits conservés

Le journal doit distinguer une proposition, une intention et un reçu correspondant. Après panne, le prochain geste dépend des faits retrouvés et des conditions courantes. Une intention sans résultat local peut cacher une opération déjà appliquée ; une proposition enregistrée peut avoir perdu sa validité. La reprise conserve ces différences pour éviter une relance qui modifie la décision ou répète l’effet.

Les seize scénarios exécutés gardent une préparation par cas et séparent appels et effets de la cible fictive. Le reçu retrouvé termine le dossier sans nouvel envoi ; son indisponibilité conserve l’incertitude. Le laboratoire utilise deux fichiers SQLite avec exceptions contrôlées et reconnexion. Il ne prouve ni génération IA, concurrence, transport distant ou garanties d’un runtime durable.

La conception de processus métier intégrant l’IA doit relier états, approbations et contrats de cible. Les fenêtres de panne sont testées au niveau des systèmes effectivement utilisés, avec limites de reprise et procédure de résolution. Le responsable dispose ainsi d’un dossier dont il peut expliquer l’avancement, la suspension et le résultat conservé.

Pour reprendre une opération interrompue après son envoi, notre expertise IA sur mesure peut qualifier les moyens de rapprochement avec l’application cible et tester les coupures autour de son reçu. Lorsque le résultat reste inaccessible, le dossier conserve l’identifiant, les paramètres et un responsable de résolution. La reprise doit ensuite respecter les droits et sources courants, sans effacer un effet passé ni renvoyer une écriture sur la seule absence de confirmation locale.