🤖 AI

A Process Harness for Uplifting Legacy Workflows to Agentic BPM: Design and Realization in CUGA FLO

Ce document introduit le « harnais de processus » (process harness), un mécanisme qui intègre une couche agentique régie par des politiques autour des moteurs de flux de travail déterministes existants afin de permettre le BPM Agentique, rigoureusement défini par le modèle Tâche-Décision-Flux (TDF) et réalisé dans le système CUGA FLO pour équilibrer la conformité structurelle avec une autonomie adaptative encadrée par des politiques.

Auteurs originaux : Fabiana Fournier, Lior Limonad

Publié 2026-06-26

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Fabiana Fournier, Lior Limonad

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez une ligne d'assemblage d'usine très stricte et à l'ancienne. Cette ligne est construite pour être parfaite : elle suit une carte fixe, chaque étape est préprogrammée et elle ne fait jamais d'erreurs. Cependant, elle est aussi incroyablement rigide. Si une boîte arrive et qu'elle ne correspond pas à la taille standard, ou si une nouvelle règle apparaît soudainement de la part du gouvernement, la machine s'arrête, se casse ou nécessite l'intervention d'un humain pour venir la réparer manuellement.

C'est ainsi que fonctionne la plupart des logiciels de gestion d'entreprise (appelés BPM) aujourd'hui. Ils sont excellents pour les tâches de routine, mais terribles pour gérer les surprises.

Maintenant, imaginez que vous puissiez donner à cette usine un « superviseur intelligent » capable de lire, de réfléchir et de porter des jugements, mais qui ne peut pas toucher au tapis roulant ni modifier les engrenages de la machine. Ce superviseur peut seulement crier des instructions aux opérateurs humains ou suggérer de petits détours, mais la machine reste celle qui dirige le jeu.

Ce document présente un nouveau système appelé CUGA FLO qui fait exactement cela. Il appelle ce système un « Process Harness » (un harnais de processus).

Voici comment cela fonctionne, décomposé en concepts simples :

1. L'idée centrale : Le Harnais

Pensez à un cheval. Le cheval est le moteur (l'ancien système de flux de travail). Le harnais est l'équipement que l'on met sur le cheval pour le guider. Vous ne remplacez pas le cheval ; vous ajoutez simplement une couche de contrôle par-dessus.

L'ancienne méthode : Pour gérer une surprise, il fallait redessiner tout le plan de l'usine (le code du logiciel) avant que la surprise ne survienne.
La nouvelle méthode (CUGA FLO) : Vous gardez l'usine exactement telle quelle. Vous enveloppez un « Harnais de processus » autour d'elle. Ce harnais utilise l'IA (plus précisément des modèles de langage étendus ou LLM) pour surveiller le processus. Lorsque le processus atteint un point de contrôle spécifique, l'IA intervient, réfléchit à la situation en se basant sur un ensemble de règles écrites (politiques), et suggère la marche à suivre.

2. Les trois « Assistants Intelligents »

Le document explique que ce harnais utilise trois types différents d'assistants IA, chacun ayant un travail spécifique. Ils sont comme une équipe de gestionnaires spécialisés :

L'Agent de Tâche (L'Ouvrier) :
- Travail : Effectuer le travail réel.
- Analogie : Imaginez qu'une tâche soit « Vérifier le score de crédit du demandeur ». Dans l'ancien système, un script informatique faisait cela. Désormais, l'Agent de Tâche lit les documents financiers désordonnés, les comprend et calcule le score.
- Règle : Il a une politique stricte : « Vous pouvez calculer le score, mais vous n'êtes pas autorisé à dire "Approuvé" ou "Rejeté". » Cette décision appartient à quelqu'un d'autre.
L'Agent de Décision (Le Agent de Circulation) :
- Travail : Décider quel chemin prendre à une bifurcation.
- Analogie : La ligne d'assemblage se divise en deux chemins : « Approuver » ou « Rejeter ». L'Agent de Décision regarde le score que l'Agent de Tâche vient de produire. Il vérifie les règles (ex : « Si le score est supérieur à 0,6, allez à gauche »). Il indique ensuite à la machine quel chemin prendre.
- Règle : Il s'assure que la décision est logique et respecte la politique écrite.
L'Agent de Flux (Le Gestionnaire d'Urgence) :
- Travail : Modifier la carte pendant que le processus est en cours.
- Analogie : C'est le plus puissant des trois. Imaginez une trappe spéciale (un crochet) sur la ligne d'assemblage. Si une situation spécifique se produit (comme un client VIP ou une urgence réglementaire), l'Agent de Flux intervient. Il peut dire : « Sautez les trois prochaines étapes », « Arrêtez la ligne » ou « Ajoutez une nouvelle étape juste ici ».
- Règle : Il ne peut faire que ce qui est explicitement autorisé par une « Politique de Crochet » (Hook Policy). Il ne peut pas changer la carte de manière aléatoire ; il doit suivre les règles.

3. Le « FRAME » (Le Livre de Règles)

Comment s'assurer que l'IA ne devienne pas folle ? Le document introduit le FRAME.

Considérez le FRAME comme un immense livre de règles lisible par l'humain (écrit en langage clair, comme un fichier Markdown). Chaque fois qu'un assistant IA prend une décision, il doit d'abord consulter ce livre de règles.

L'Agent de Tâche vérifie les « Règles de Tâche ».
L'Agent de Décision vérifie les « Règles de Routage ».
L'Agent de Flux vérifie les « Règles d'Urgence ».

Si l'IA tente de faire quelque chose qui n'est pas autorisé dans le livre de règles, le système l'arrête. Cela garantit que l'IA est « encadrée » par des règles humaines, et ne se contente pas d'inventer des choses.

4. L'exemple de l'approbation de prêt

Le document prouve l'efficacité de cette méthode avec un exemple d'Approbation de Prêt :

L'Ouvrier (Agent de Tâche) lit une demande de prêt et calcule un score de crédit.
L'Agent de Circulation (Agent de Décision) voit que le score est élevé (0,82) et dit : « D'accord, cela semble bon, allons sur le chemin "Approuver" ».
Le Gestionnaire d'Urgence (Agent de Flux) voit que le numéro d'identification du demandeur est « 4321 ». Même si le score est élevé, le livre de règles stipule : « L'ID 4321 est banni en raison d'une nouvelle réglementation ».
Le Résultat : L'Agent de Flux outrepasse la décision de l'Agent de Circulation. Il utilise un « Crochet » pour sauter instantanément vers le chemin « Rejeter », en sautant toutes les étapes d'approbation.

Pourquoi est-ce génial ? Dans l'ancien système, vous auriez dû intégrer un chemin spécial pour l'« ID 4321 » dans le logiciel il y a des années. Avec CUGA FLO, vous mettez simplement à jour le fichier texte (la politique) aujourd'hui, et le système gère la situation immédiatement sans réécrire le code.

5. Pourquoi cela importe (Le « Meilleur des deux mondes »)

Le document soutient que cela résout un problème majeur :

Les anciens systèmes sont sûrs et structurés, mais ne peuvent pas s'adapter aux nouveautés.
L'IA pure peut s'adapter à tout, mais elle est risquée, imprévisible et difficile à auditer.

CUGA FLO combine les deux. L'« Moteur » (l'ancien logiciel) garantit que la structure est sûre et suit la carte. Le « Harnais » (l'IA) ajoute la capacité de s'adapter, de raisonner et de gérer les imprévus, mais uniquement dans les limites strictes du livre de règles.

Résumé

Le document présente CUGA FLO comme un moyen de mettre à niveau les anciens logiciels d'entreprise rigides pour les transformer en systèmes intelligents et adaptables sans jeter l'ancien logiciel. Il y parvient en enveloppant le vieux système dans un « Harnais de processus » qui utilise trois types d'agents IA (Ouvriers, Agents de Circulation et Gestionnaires d'Urgence) qui sont strictement régis par un livre de règles écrit par l'humain (le FRAME). Cela permet aux entreprises de gérer automatiquement les situations inattendues tout en conservant un registre strict et auditable de chaque décision.

Résumé Technique : Un Harnais de Processus pour l'Élévation des Flux de Travail Hérités vers le BPM Agentique

1. Énoncé du Problème

Les systèmes de Gestion des Processus Métiers (BPM) conventionnels, bien qu'ils fournissent des garanties structurelles rigoureuses, souffrent de deux limitations fondamentales dans les environnements dynamiques :

Régime de Monde Fermé : Toute déviation par rapport au chemin nominal doit être anticipée et modélisée explicitement lors de la conception. Les situations imprévues (ex: changements réglementaires, profils de demandeurs inédits) forcent le système à des états d'erreur ou nécessitent une intervention humaine, menant souvent à des « contournements » qui court-circuitent les processus formels.
Exécution de Tâches Rigide : Les tâches de service reposent sur des scripts fixes incapables de s'adapter à des entrées non structurées, tandis que les tâches utilisateur introduisent des contraintes de débit. Le moteur lui-même manque de capacité de raisonnement ouvert ou d'adaptation contextuelle.

Bien que les Grands Modèles de Langage (LLM) offrent un raisonnement ouvert, les paradigmes d'intégration actuels sont insuffisants. Le paradigme « IA augmentée » (LLM au sein de tâches spécifiques) laisse le flux de contrôle global rigide. Inversement, le paradigme « LLM-en-tant-que-Planificateur » (LLM générant des plans d'exécution en dehors du moteur) manque de mécanismes pour garantir la conformité structurelle, l'auditabilité ou l'adhérence aux politiques de conformité. Il existe un besoin pour un système qui réconcilie la rigidité structurelle de l'exécution de workflow déterministe avec le raisonnement adaptatif des agents régis par des politiques, sans remplacer les moteurs de workflow existants.

2. Méthodologie : Le Harnais de Processus et le Modèle TDF

Le document présente le Harnais de Processus (Process Harness), un mécanisme qui superpose une couche d'agents régie par des politiques sur un moteur de workflow déterministe existant. Cette couche intercepte des points de contrôle désignés pour apporter raisonnement, adaptation et supervision, tandis que le moteur conserve l'autorité structurelle.

Le fondement conceptuel est le modèle Tâche–Décision–Flux (TDF), qui décompose le raisonnement du LLM à travers trois types d'agents distincts, limités par des politiques :

TaskAgent (Agent de Tâche) : Responsable de l'exécution de tâches exigeant une forte intensité de connaissances. Il remplace les scripts codés en dur par une exécution LLM régie par une politique, raisonnant au sein d'une politique de tâche spécifique ( $C_T$ ) pour produire des sorties métier.
DecisionAgent (Agent de Décision) : Responsable du routage par passerelle par cas. Il remplace l'évaluation statique de conditions par un raisonnement LLM limité par une politique de décision ( $C_D$ ). Crucialement, il impose une étape de détermination déterministe de la condition avant le raisonnement pour garantir que la condition de la passerelle est explicitement évaluée.
FlowAgent (Agent de Flux) : Responsable de l'adaptation du flux au runtime via un mécanisme de crochet (hook) principalisé. Il intercepte des flux de séquence désignés (crochets) et raisonne sous des politiques de crochet ( $C_F$ ) pour recommander des interventions structurelles (ex: sauter, échanger, terminer ou modifier la topologie).

Cadre de Gouvernance (FRAME) :
Tout le raisonnement des agents est délimité par le FRAME ( $F$ ), un ensemble agrégé de documents de politique lisibles par l'humain. Cela garantit une « autonomie encadrée », où les agents opèrent dans des contraintes explicites et auditables. Une couche de gouvernance secondaire, action_permissions ( $\phi$ ), énumère explicitement quels types d'interventions structurelles un FlowAgent est autorisé à ordonner, séparant le raisonnement du LLM des capacités d'exécution du moteur.

Architecture (CUGA FLO) :
Le document présente CUGA FLO comme la première réalisation du modèle TDF.

Découplage : La couche de raisonnement (FlowAgent et ses sous-agents) est entièrement découplée de la couche d'exécution (WorkflowEngine) via un Pont de Protocole de Contexte de Modèle (MCP Bridge) (implémenté comme un serveur FastMCP).
Interaction : Le moteur de workflow pilote l'exécution et marque des pauses aux points de contrôle (tâches, passerelles, crochets) pour invoquer des rappels (execute_task, route_gateway, evaluate_hook). Le FlowAgent traite ces appels en utilisant la ControlPointFlowKnowledge (modèle de processus, état, historique) et retourne des recommandations structurées.
Exécution : Le moteur de workflow impose la conformité structurelle, appliquant les recommandations du FlowAgent (ex: recâblage des flux pour skip_to ou remove_node) sans rejouer les nœuds déjà exécutés.

3. Contributions Clés

Le document apporte cinq contributions spécifiques :

Paradigme du Harnais de Processus : Introduit un mécanisme pour élever les systèmes de workflow conventionnels vers le BPM Agentique, caractérisé par la conformité structurelle, la responsabilité par politique et l'adaptabilité au runtime.
Modèle Tâche–Décision–Flux (TDF) : Propose une décomposition conceptuelle formelle du raisonnement LLM en trois types d'agents (Tâche, Décision, Flux), chacun ayant des rôoles et des contraintes de politique distinctes.
Instanciation de FRAME : Formalise l'ensemble de politiques agrégées ( $F$ ) régissant les processus TDF, démontrant comment le partitionnement des politiques entre les types d'agents assure la séparation des préoccupations au niveau du LLM.
Réalisation CUGA FLO : Présente la première implémentation du harnais de processus, dotée d'un mécanisme de crochet pour l'adaptation au runtime et d'un pont MCP qui découple le raisonnement du moteur de workflow remplaçable.
Démonstration Empirique : Valide le modèle à l'aide d'un workflow d'approbation de prêt qui exerce les trois types d'agents ainsi qu'un crochet de priorité réglementaire, montrant comment un crochet peut outrepasser une décision de passerelle basée sur un critère différent (ex: l'ID du demandeur) sans modifier la politique de la passerelle.

4. Résultats et Évaluation

Le document démontre le système à travers une étude de cas de workflow d'approbation de prêt :

Cas Nominal : Une vérification de crédit standard (TaskAgent) produit un score ; un DecisionAgent route selon un seuil ; un FlowAgent confirme la continuation via un crochet.
Cas de Priorité Réglementaire : Un demandeur avec un score élevé (ID 4321) est orienté vers l'approbation par le DecisionAgent basé sur le score. Cependant, un crochet du FlowAgent intercepte le flux "oui", applique une politique réglementaire (basée sur l'ID) et ordonne une intervention de type skip_to vers le chemin de rejet.
Résultat : Le système gère avec succès la « longue traîne » des variantes rares et spécifiques au contexte (priorités réglementaires) sans modifier le modèle BPM sous-jacent. Le DecisionAgent et le FlowAgent opèrent sous des politiques distinctes, garantissant que la logique de routage et la logique de priorité réglementaire sont indépendamment auditables.

Les résultats confirment que le harnais de processus peut réconcilier les exigences impératives (imposées par le moteur) avec les exigences normatives (imposées par les agents régis par des politiques), permettant une adaptation en "monde ouvert" tout en maintenant l'intégrité structurelle.

5. Signification et Revendications

Le document affirme que le Harnais de Processus représente une nouvelle forme d'instrumentation pour les systèmes d'IA d'entreprise. Sa signification réside dans :

Réconciliation de la Tension : Il résout le compromis entre rigidité structurelle et flexibilité ouverte en séparant la topologie du processus (fixe, imposée par le moteur) de l'adaptation du processus (dynamique, régie par des politiques).
Modernisation Incrémentale : Il permet aux organisations de transformer leurs systèmes de workflow existants en systèmes pleinement agentiques de manière incrémentale et réversible, sans déplacer le moteur sous-jacent.
Responsabilité : Contra irement aux approches de type "LLM-en-tant-que-Planificateur" où les traces d'exécution peuvent être non déterministes ou non liées à un modèle, CUGA FLO fournit un substrat de responsabilité concret. Chaque appel LLM est associé à un document de politique directeur, et chaque intervention est enregistrée dans la connaissance du processus liée à des éléments de processus spécifiques, permettant l'auditabilité et le diagnostic de non-conformité.
Adaptation au Monde Ouvert : Il déplace la gestion des exceptions d'une activité de conception en monde fermé (modéliser chaque chemin d'erreur possible) vers une capacité de runtime en monde ouvert, où l'ensemble des situations gérables est défini par la capacité de raisonnement des documents de politique.

Les auteurs positionnent CUGA FLO comme la première réalisation du manifeste du BPM Agentique, fournissant un cadre pragmatique pour que les organisations évoluent de l'IA augmentant le BPM vers un plein BPM Agentique où les agents gouvernent le processus de bout en bout.