Un workflow fiable conserve l’état métier hors de son exécution
Un journal d’exécution raconte ce qui s’est passé pendant un passage. Il ne suffit pas à dire où en est réellement un avis, un document ou une commande après une coupure.
Note de méthode · 30 septembre 2026 · Illustrée par l’étude de veille des marchés publics
Le problème : « exécuté » ne veut pas dire « traité »
Dans une veille multi-source, un avis peut arriver depuis BOAMP, TED ou une alerte IMAP. Un passage peut récupérer les métadonnées, puis échouer lors du téléchargement d’un DCE. Un autre peut lire les pièces mais recevoir une réponse IA invalide. Si l’on ne conserve que l’état global « le workflow a tourné », ces deux cas deviennent difficiles à distinguer. Rejouer toute la chaîne risque alors de multiplier les doublons ; ne rien rejouer risque de perdre un avis.
Une identité stable pour chaque élément
Chaque avis a besoin d’une clé métier stable et d’une provenance. La référence publique seule peut ne pas suffire : la source, les lots et la version consultée comptent aussi. Le registre rapproche les avis déjà vus et distingue un contenu inchangé d’une mise à jour. Cette distinction permet de réutiliser un résultat encore valide sans masquer une nouvelle pièce ou une échéance modifiée.
Un état durable, séparé de l’orchestrateur
Dans le cas documenté, n8n orchestre les étapes tandis que PostgreSQL conserve l’état partagé. L’enregistrement métier peut indiquer qu’une collecte a réussi, qu’une extraction attend une reprise, qu’une analyse est invalide ou qu’une synthèse est prête pour examen humain. Cette mémoire traverse les exécutions. Elle sert aussi à réserver le travail : deux passages concurrents ne doivent pas qualifier simultanément le même avis.
Relancer seulement l’étape nécessaire, avec la même clé métier, et vérifier avant toute écriture si son résultat est déjà présent et toujours valable.
Les erreurs n’ont pas toutes la même réponse
Une plateforme temporairement indisponible appelle une nouvelle tentative. Un PDF scanné illisible peut exiger un autre mode d’extraction ou un examen manuel. Une réponse du modèle hors du format attendu doit être rejetée, pas interprétée comme une qualification négative. Les erreurs de transport, de contenu et de validation doivent donc rester distinctes dans l’état.
Idempotence et cache sous condition
Une opération est idempotente si la répéter ne crée pas un deuxième avis ni une deuxième action. Cela demande une clé stable, une vérification avant insertion et, pour les écritures liées, une transaction adaptée. Un résultat en cache n’est réutilisable que si les pièces et les règles pertinentes n’ont pas changé. La disponibilité d’un ancien résultat ne prouve pas sa validité actuelle.
Le dernier contrôle reste humain
Le système prépare une sélection reliée aux sources, aux passages probants et aux réserves. Il ne décide pas de répondre à un marché. L’équipe vérifie les pièces officielles, la date, le lot et sa capacité à intervenir. Cette limite n’est pas une faiblesse du workflow : c’est une décision explicite sur la responsabilité.
Pour voir les sources, les versions, le DCE et l’IA locale dans leur contexte, consultez l’étude détaillée de veille des marchés publics. Les principes de permissions et de journalisation sont développés sur la page Sécurité & données.