La vague agentique ne suggère plus — elle orchestre des workflows, exécute des actions et prend des décisions dans des systèmes transactionnels critiques.
Si les données doivent être gouvernées, les processus qui les produisent et les consomment doivent l'être également — avec les mêmes rigueur, traçabilité et responsabilités.
HITL — Human in the Loop — devient le seul point de responsabilité réelle dans un workflow agentique. Sans gouvernance, ce point devient le point d'échec.
Les données sont produites, transformées et consommées par des processus. Gouverner les données sans gouverner les processus qui les produisent, c'est traiter les symptômes et ignorer les causes. Avec l'IA agentique, cette lacune devient critique.
Un processus KYC mal conçu génère des données client incorrectes, quelle que soit la qualité du système de stockage en aval. La mauvaise qualité de la donnée a presque toujours une cause processus : saisie manuelle sans contrôle, étape de validation contournée, règle métier non documentée. Gouverner la donnée sans gouverner le processus revient à filtrer l'eau sans réparer la tuyauterie.
Quand un agent IA exécute une action dans un système — créer un ticket, modifier une configuration, envoyer une notification — la question "qui est responsable ?" n'a de réponse que dans le processus formalisé. Sans RACI processus clair, la responsabilité est nulle part. Avec l'agentique, cette absence devient un risque réglementaire documenté (DORA Art. 5.2, EU AI Act Art. 9).
Un agent IA sans processus documenté détermine lui-même ses limites d'action — ce qui est précisément ce qu'un dispositif de gouvernance cherche à éviter. Le processus formalisé et validé par le métier est le seul fondement légitime d'une politique d'agent : il définit ce que l'agent peut faire, jusqu'où il peut décider seul et à quel moment il doit attendre la validation humaine.
L'unité de production tend à évoluer vers des binômes humain-flotte d'agents. Les cadres SAFe, Scrum et squads deviennent des structures à repenser si l'essentiel du temps passe en supervision, pas en production. La gouvernance des processus précède la gouvernance des agents — elle en est la condition nécessaire.
Processus qui créent, transforment ou suppriment des données critiques : onboarding client (KYC), facturation, reporting financier, collecte risk. Ces processus doivent être gouvernés avec un Process Owner identifié, des règles qualité documentées à chaque étape et un lineage processus → donnée traçable. La gouvernance data et la gouvernance des processus data sont inséparables.
Processus partiellement ou totalement exécutés par des agents IA : traitement des demandes de support, pipeline de déploiement IT, analyse de risque automatisée, réconciliation de données. Ces processus requièrent un Agent Catalog, une politique d'agent documentée (Agent Policy), des guardrails définis et des points HITL explicitement positionnés.
Processus où humain et agent se partagent les étapes selon la complexité et le risque : instruction crédit, gestion d'incident majeur, processus réglementaire. Ce sont les plus complexes à gouverner car la frontière de responsabilité est mouvante. Le BPMN augmenté IA (voir P.05) est l'outil de formalisation adapté.
Tout processus exécuté partiellement ou totalement par un agent IA doit être : documenté (BPMN ou équivalent), validé par le Process Owner métier, associé à une politique d'agent (scope, outils autorisés, points HITL), auditable (logs, traces de décision) et réversible (procédure de rollback documentée). Ces 5 attributs ne sont pas négociables pour les processus critiques — ils sont imposés par DORA et l'EU AI Act.
On ne peut pas gouverner ce qu'on ne voit pas. Le Process Mining extrait des événements des systèmes d'information (logs, traces, timestamps) pour reconstruire les processus tels qu'ils s'exécutent réellement — pas tels qu'ils ont été conçus. La différence est toujours surprenante.
Un processus documenté en 7 étapes révèle en réalité 40 à 200 variantes d'exécution réelles. Certaines sont légitimes (cas particuliers), d'autres sont des contournements non documentés, d'autres encore sont des erreurs qui se perpétuent. Le Process Mining cartographie toutes ces variantes avec leur fréquence et leur coût relatif. C'est la première donnée indispensable avant tout projet d'automatisation ou d'agentification.
Les délais d'attente entre deux étapes sont précisément mesurables : "98% du temps de traitement d'un sinistre est passé en attente entre l'étape de validation expert et la saisie dans le système, non dans le traitement lui-même." Ces données objectives remplacent les perceptions et permettent de prioriser les chantiers d'automatisation sur les vrais bottlenecks, pas sur les supposés.
Le Process Mining révèle les cas où des étapes obligatoires ont été sautées (validation KYC non effectuée, contrôle qualité contourné, double approbation manquante), les délais réglementaires non respectés (SLA clients, obligations DORA), et les actions exécutées hors séquence. Ces violations, invisibles sans outils, constituent des risques réglementaires documentés.
Une fois les variantes et goulots cartographiés, le Process Mining permet d'identifier les étapes à forte valeur d'automatisation : étapes répétitives à faible variabilité, étapes de routage et classification, étapes de vérification par règles. Cette sélection factuelle évite d'agentifier les mauvais candidats — et d'aggraver des processus déjà défaillants.
Extraire les event logs des systèmes sources (ERP, CRM, ITSM, workflows). Chaque événement = un triplet (Case ID, Activity, Timestamp). Qualité des logs = qualité du diagnostic. Un système sans logs structurés ne peut pas être miné.
Reconstruire automatiquement le modèle de processus réel (BPMN ou Petri net) depuis les logs. Comparer avec le processus documenté — l'écart est systématiquement significatif. Identifier les variantes, leur fréquence et leur coût.
Comparer les cas réels au modèle cible (réglementaire, processus validé). Calculer un score de conformité par cas et identifier les violations. C'est la fondation du monitoring continu de conformité — particulièrement critique pour DORA et EU AI Act.
Identifier les Quick Wins (variantes à éliminer, goulots à résorber), concevoir le processus cible, déployer en test A/B, mesurer l'impact. Puis monitorer en continu : le Process Mining passe de l'analyse de projet au monitoring opérationnel permanent.
N'agentifier que des processus dont les variantes ont été cartographiées et les violations réglementaires résolues. Agentifier un processus non maîtrisé revient à automatiser un chaos — avec une vitesse d'exécution multipliée par 10.
Chaque pattern agentique implique un niveau de gouvernance différent. La gouvernance des processus doit s'adapter au pattern utilisé — pas l'inverse. Connaître ces patterns est indispensable pour positionner correctement les points de contrôle humain.
Pipeline avec orchestration codée en dur — pas de LLM pour le routing. Chaque agent traite sa partie et passe le relais dans un flux déterministe et reproductible. Exemple : Agent 1 (Classification) → Agent 2 (Enrichissement CMDB) → Agent 3 (Routing équipe) → Agent 4 (Création ticket JIRA).
Distribution aux agents en parallèle, puis collecte et synthèse par un agent agrégateur. Exemple (IT) : analyse de sécurité d'une PR en parallèle — Agent SAST + Agent SCA + Agent Secrets + Agent DAST → rapport consolidé avec criticité globale.
L'orchestrateur évalue après chaque cycle si la condition d'arrêt est atteinte. Exemple : agent de capacity planning qui itère en ajustant CPU/RAM jusqu'à trouver le sizing optimal selon des métriques de performance définies. Risque critique : boucle infinie si la condition d'arrêt est mal définie.
L'agent s'interrompt à des checkpoints prédéfinis pour attendre validation, correction ou input humain. Essentiel pour décisions à fort enjeu. Exemple : pipeline de déploiement production — l'agent prépare et teste, mais attend la validation du Release Manager avant le cutover (freeze period, communication client).
La chaîne de responsabilité est le principal enjeu organisationnel. Quand un agent code, un autre teste, un troisième déploie — qui est responsable ? Le HITL devient le seul point de responsabilité claire. Sans lui, la chaîne de responsabilité est rompue, et l'ACPR (secteur financier) commence à se positionner sur ce sujet.
La notation BPMN standard ne suffit plus dès qu'un agent IA intervient dans un processus. Elle doit être enrichie pour représenter explicitement qui décide (humain ou agent), avec quelle politique d'agent, et où se positionnent les points de contrôle obligatoires.
Dans le diagramme BPMN, créer des swimlanes dédiées par acteur : Humain (collaborateur nommé ou rôle), Agent IA (nommé depuis l'Agent Catalog), Système automatique (API, trigger). La lane de l'agent indique visuellement son scope d'action — ce qui doit rester dans sa lane et ce qui en sort constitue les points d'interface à gouverner.
Chaque tâche exécutée par un agent porte une annotation documentant : le nom de l'agent dans l'Agent Catalog, les outils autorisés pour cette tâche (read-only / lecture-écriture / action irréversible), le prompt ou la règle de déclenchement, le niveau d'autonomie (assisté / supervisé / autonome) et la politique de guardrails actifs.
Un événement intermédiaire spécifique (losange avec icône humaine) matérialise chaque point HITL. Il porte : le rôle humain requis, la SLA de réponse, le comportement de l'agent en cas de non-réponse (attente / escalade / annulation), et les critères de validation. Ces checkpoints sont non-négociables sur les processus critiques et soumis à audit réglementaire.
Les flux de données entre agent et système portent une annotation indiquant : quel log est produit, où il est stocké, quelle est sa durée de rétention (DORA requiert 5 ans pour les systèmes TIC critiques), et si la donnée est soumise au RGPD (PII). Cette annotation permet de vérifier d'un coup d'œil la conformité auditabilité du processus.
Pour chaque action irréversible exécutée par un agent (déploiement, envoi de communication, modification de configuration), un sous-processus de rollback est documenté dans le BPMN. Ce n'est pas optionnel pour les processus critiques — c'est une exigence de l'EU AI Act Art. 9 (risk management) et une bonne pratique DORA.
Diagramme BPMN augmenté avec lanes, HITL et annotations Agent Policy
Fiche Agent Policy par agent déployé (scope, outils, guardrails, rollback)
RACI humain-agent documenté et validé par le Process Owner
Le RACI traditionnel distribue les responsabilités entre humains. L'agentique crée une rupture : l'agent peut être Responsible d'une tâche, mais il ne peut jamais être Accountable. Cette distinction est fondamentale — et juridiquement déterminante. Elle restructure entièrement la gouvernance des processus.
Un agent IA peut être Responsible d'une tâche. Il ne peut jamais être Accountable. L'accountability — la responsabilité finale et inaliénable du résultat — reste toujours et irréversiblement chez un humain nommé. C'est le fondement de la gouvernance des processus agentiques, et la position de DORA (Art. 5.2), de l'EU AI Act (Art. 9) et de l'ACPR (secteur financier).
| Rôle RACI | Définition étendue | Peut être un agent ? |
|---|---|---|
| R · Responsible | Exécute la tâche | ✓ Oui |
| A · Accountable | Répond du résultat final | ✗ Jamais |
| C · Consulted | Apporte son expertise | ✓ Oui (RAG) |
| I · Informed | Reçoit l'information | ✓ Oui |
| S · Supervisor | Nouveau rôle — surveille l'agent en temps réel | ✗ Humain uniquement |
| V · Validator | Nouveau rôle — valide au HITL checkpoint | ✗ Humain uniquement |
Quand un agent code, un autre teste, un troisième déploie — le HITL (Human in the Loop) devient le seul point de responsabilité. Point d'attention : comment l'ACPR va-t-elle se positionner ? Cette question est ouverte et constitue un risque réglementaire actif pour les établissements financiers déployant des agents en 2026.
Rôle existant étendu. Responsable de la gouvernance du processus hybride humain-agent. Valide le BPMN augmenté, signe la politique d'agent (Agent Policy), définit les critères de qualification des HITL checkpoints. Répond de la conformité réglementaire du processus devant le régulateur. Ne peut pas déléguer ce rôle à un agent.
Profil issu du Benchmark Cigref 2026 : surveille en temps réel les outputs des agents sur les processus critiques, détecte les dérives comportementales (hallucinations, boucles, anomalies), déclenche les escalades HITL et les rollbacks. Remplace partiellement le middle management de production dans les équipes agentiques. C'est le "pilote" des workflows automatisés.
Conçoit l'architecture d'orchestration des agents (MCP, APIs, sécurité), définit les politiques d'agent au niveau technique (RBAC, guardrails, NHI — Non Human Identity), s'assure de l'alignement entre le BPMN augmenté métier et l'implémentation technique. Travaille en binôme avec le Process Owner et le CDO.
D'après le Benchmark Agentic for Tech 2026 : le modèle agentique fait évoluer l'équipe SAFe (7–9 personnes) vers des "pods" de 2 à 4 personnes très expérimentées. Les rôles de chef de projet et responsable d'application perdent une partie de leur périmètre, alimentant un risque de perte de sens pour le middle management. La gouvernance des processus doit intégrer cette dimension RH — le change management processus est indissociable du change management humain.
Le déploiement de l'IA agentique ne modifie pas seulement les outils — il restructure profondément le modèle opérationnel. Le TOM agentique cible doit être conçu, pas subi. Il repose sur 4 dimensions indissociables : Organisation, Processus, Technologie, Gouvernance.
L'IA assiste les humains — suggestions, génération de contenu, recherche d'information. Les processus existants ne changent pas fondamentalement. L'organisation et le modèle managérial restent inchangés. C'est l'état de la grande majorité des organisations en 2026.
Des agents IA exécutent des tâches définies dans des processus formalisés avec supervision humaine. Les équipes SAFe évoluent vers des "pods" de 3 à 5 personnes. Le Process Owner est nommé, l'Agent Catalog est actif, la comitologie intègre les agents. C'est la cible réaliste à 2 à 3 ans pour les grandes organisations avec budget dédié.
Les processus sont conçus pour être exécutés par défaut par des agents, la présence humaine étant l'exception (HITL sur décisions critiques uniquement). Les "pods" de 2 à 4 personnes expérimentées supervisent des flottes d'agents. Horizon 2028–2030 pour les organisations pionnières. Requiert une gouvernance processus mature comme prérequis.
Pods de 3 à 5 personnes (Process Owner + Superviseur agents + Data Engineer + Expert métier). CoE IA central pour les standards et l'architecture. Nouveau rôle System Team pour la conformité des agents en production.
Tout processus agentique a son BPMN augmenté validé avant déploiement. Agent Catalog maintenu à jour. Agent Policy V1 pour chaque agent. Gate d'approbation obligatoire avant passage en production.
MCP (Model Context Protocol) pour l'exposition des outils, IAM 3 couches (AuthN + AuthZ + Secrets), NHI (Non Human Identity) pour chaque agent, observabilité temps réel (traces, logs, coûts), guardrails V1 actifs sur tous les agents de production.
Comité IA mensuel (CDO + CISO + Process Owners), revue Agent Portfolio trimestrielle (valeur, risques, conformité), rapport annuel IA au COMEX, procédure d'urgence de suspension d'agent documentée et testée.
L'IA agentique est fortement dépendante de la qualité des données et de la maturité documentaire. Un agent RAG sur un dictionnaire de données incomplet ou des golden sources non identifiées produira des outputs non fiables. Score Cigref BP2 ≥ 3 sur les domaines impactés est le seuil minimal avant agentification.
Les processus candidats à l'agentification doivent avoir été cartographiés par Process Mining — variantes documentées, violations résolues, bottlenecks identifiés. Agentifier un processus non maîtrisé crée un risque majeur : les défauts existants sont exécutés à la vitesse des agents.
Selon la méthodologie FinDiT/Agentic 2026 : avant le premier POC agentique en production, les fondations de confiance doivent exister — Agent Policy V1, Agent Catalog V1, guardrails V1, auditabilité V1, workflow de validation outil/vendor. Ce "POC-ready pack" est non-négociable pour les environnements critiques.
La transformation vers un TOM hybride requiert un niveau de sponsorship identique à celui d'un programme de gouvernance data — et pour les mêmes raisons. Sans budget dédié, sans Process Owner libéré de 20% de son temps et sans décision COMEX documentée, le TOM agentique reste un projet pilote sans impact organisationnel.
Ne jamais construire un TOM théorique avant d'avoir livré des POCs. Le TOM final doit être validé à partir des apprentissages réels des POCs (#1 à #4), pas d'une vision abstraite. Un TOM conçu en chambre sans expérimentation terrain est presque toujours inadapté à la réalité opérationnelle.
Un processus non maîtrisé agentifié devient un chaos exécuté à grande vitesse. Process Mining d'abord. BPMN augmenté ensuite. Agent Policy uniquement après.
Quel que soit le niveau d'autonomie de l'agent, un Process Owner humain nommé répond du résultat. Cette règle est juridique, réglementaire et organisationnelle. Elle n'a aucune exception.
Les checkpoints humains sont définis dans le BPMN augmenté avant le déploiement. Les ajouter après un incident est 5 fois plus coûteux et génère une perte de confiance des métiers difficile à récupérer.
Chaque agent déployé en production est documenté dans un catalogue centralisé — exactement comme les données critiques dans un data catalog. Sans cela, le dispositif de gouvernance est aveugle à sa propre flotte d'agents.
+41% de bugs si l'IA n'est pas encadrée (METR 2025). Les gains de ×3 à ×10 en productivité ne s'obtiennent qu'avec une gouvernance processus solide comme fondation. Sans elle, les agents amplifient les défauts existants — avec une vitesse d'exécution et une échelle qui rendent les corrections exponentiellement plus coûteuses.