Ce guide a commencé comme un livre blanc destiné aux responsables de l'ingénierie d'une grande banque canadienne. Ils ne partaient pas de zéro. Ils avaient des agents sur LangGraph en pré-production : des points de contrôle vers Postgres, des sous-graphes pour des rôles spécialisés, `interrupt()` configurés pour la révision humaine. Ils avaient lu la documentation et construit des choses concrètes. Alors, quand je suis arrivé pour parler d'orchestration, un ingénieur principal a posé la seule question qui vaille : « Nous avons déjà LangGraph. Il a la persistance, il a l'humain dans la boucle, il a l'état. Pourquoi mettrions-nous autre chose au milieu ? » Il y a une mauvaise façon de répondre à cette question, et la plupart des fournisseurs l'adoptent. La mauvaise réponse est tribale : mon runtime contre le vôtre, mon logo sur le diagramme d'architecture. Cette réponse mérite le haussement de sourcils qu'elle provoque. Je dois également divulguer ma position avant d'aller plus loin : je travaille chez Camunda, et l'une des réponses possibles dans ce guide est la catégorie de produit que mon employeur vend. Tenez compte de mon parti pris en conséquence. J'essaierai de regagner votre confiance en étant précis sur les compromis, en nommant honnêtement les alternatives et en vous disant quand vous n'avez besoin de rien de tout cela. La bonne réponse est une séparation des préoccupations. Les frameworks d'agents sont excellents pour la boucle interne : le cycle de raisonnement, de sélection d'outils et de mémoire qui transforme un objectif en actions. Ils sont structurellement inadaptés à la gestion de la boucle externe : l'ensemble des obligations qu'une institution assume, qu'un LLM soit impliqué ou non. La réponse dont la banque avait besoin n'était pas de tout remplacer. C'était un plan de contrôle qui orchestre les agents construits sur n'importe quel framework, et une ligne claire sur quelle boucle possède quoi. Ce guide est ce livre blanc, généralisé. ## La boucle interne et la boucle externe La boucle interne est ce qu'un framework exécute entre la réception d'une tâche et la production d'un résultat. Assembler le prompt, raisonner sur l'objectif, choisir un outil, l'appeler, lire la sortie, mettre à jour la mémoire, décider de boucler à nouveau. LangGraph, CrewAI et l'OpenAI Agents SDK sont vraiment bons à cela, et ils s'améliorent rapidement. Je n'ai aucun intérêt à les remplacer, et vous non plus. Si votre équipe est productive avec LangGraph, c'est un atout. La boucle externe est tout ce que l'institution est obligée d'envelopper autour de ce cycle. Ce n'est pas de l'intelligence. C'est de la responsabilité. Les deux boucles ont des propriétaires différents, des durées de vie différentes et des publics différents.  | Boucle interne (gérée par le framework d'agent) | Boucle externe (gérée par le plan de contrôle) | |---|---| | Raisonnement et planification | Piste d'audit qui existe sans journalisation personnalisée | | Sélection et invocation d'outils | Approbation humaine avec identité et autorisation | | Assemblage du prompt et gestion du contexte | SLA, escalades et timers durables | | Mémoire à court terme et épisodique | Politique en tant que données, gérée par la conformité | | Auto-correction et nouvelle tentative en cas de mauvaise sortie | Gestion des versions et migration du travail de longue durée | | Production de sortie structurée et d'artefacts | Investigation des incidents en un seul endroit | | Choix du modèle et économie des tokens | Annulation atomique et compensation | L'affirmation importante n'est pas que les frameworks manquent de ces fonctionnalités aujourd'hui. C'est qu'ils sont structurellement le mauvais endroit pour les héberger. Un framework s'exécute à l'intérieur de votre processus applicatif. Son magasin d'état existe pour que le graphe puisse reprendre, pas pour qu'un auditeur puisse attester. Son contexte d'autorisation est ce que votre application a transmis. Sa durée de vie est celle d'un déploiement. Les exigences de la boucle externe sont institutionnelles : elles doivent survivre aux processus, aux déploiements, aux réorganisations d'équipes et parfois au framework lui-même. Un checkpointer LangGraph est une excellente pièce d'ingénierie pour la reprise. Il n'a jamais été conçu pour être une preuve. Les garde-fous de l'OpenAI Agents SDK s'exécutent dans le même processus que l'agent qu'ils protègent, ce qui est précisément l'endroit où un contrôle ne devrait pas se trouver. Pour être juste, les plateformes hébergées autour de ces frameworks (LangSmith, LangGraph Platform et leurs équivalents) ajoutent une réelle observabilité et des outils d'opérations. Mais ce qu'elles ajoutent est orienté développeur et lié au framework. Le public de la boucle externe inclut des personnes qui n'ouvriront jamais un visualiseur de traces : les responsables de la conformité, l'audit interne, les opérations et, à terme, un régulateur. ## Les cinq obligations de la boucle externe Lorsque j'ai rédigé le livre blanc original, j'ai continué à réduire la liste jusqu'à ce qu'il ne reste que les obligations qui avaient survécu au contact de véritables révisions. Cinq l'ont fait. ### 1. Une piste d'audit qui existe sans journalisation personnalisée Le test est simple : pouvez-vous reconstituer ce qui s'est passé sans qu'aucun développeur n'ait eu à se souvenir de le journaliser ? Si la réponse dépend d'appels `logger.info()` parsemés dans le code de l'agent, vous n'avez pas de piste d'audit. Vous avez un journal, tenu par des volontaires. Les questions d'un auditeur sont spécifiques. Qui a initié ce cas ? Que savait le système à chaque étape ? Quelle version de quelle politique a été évaluée, avec quelles entrées ? Qui a approuvé l'action, et sous quelle autorité ? Les logs d'application ne répondent à aucune de ces questions de manière fiable. Ils sont échantillonnés, tournés selon des politiques de rétention mesurées en jours, mutés par la configuration du pipeline et façonnés par ce qu'un développeur a jugé intéressant un jeudi à 16h. Reconstituer un cas à partir d'eux est de l'archéologie, et l'archéologie est ce que l'on fait quand la civilisation n'a pas su tenir de registres. Un plan de contrôle inverse cela. Lorsque chaque étape d'un processus est une transition d'état dans un moteur, l'historique est un sous-produit de l'exécution. La piste ne peut pas s'éloigner de la réalité car la piste est la façon dont la réalité a été exécutée. C'est le seul argument le plus fort en faveur de ce modèle, et cela ne coûte rien de plus au moment du développement. Vous l'obtenez en plaçant le travail à l'intérieur de ce qui enregistre, au lieu de demander à ce qui fonctionne de se souvenir aussi d'écrire. ### 2. Humain dans la boucle avec identité et autorisation Chaque framework propose désormais une primitive de pause. LangGraph a `interrupt()`. D'autres ont des équivalents. Une pause n'est pas une approbation. Une approbation est une pause plus un modèle d'autorisation, et le modèle d'autorisation est la partie difficile. Une véritable approbation institutionnelle signifie : un ensemble défini de personnes qui peuvent approuver cette action spécifique, résolu à partir d'un annuaire, non codé en dur. Quatre yeux (maker-checker) où la personne qui a initié le cas ne peut pas être la personne qui l'approuve. Routage basé sur le montant, où une exception de 2 000 $ va à un chef d'équipe et une exception de 200 000 $ va à un responsable désigné. Délégation lorsque l'approbateur est en vacances, et escalade lorsque personne n'agit. Et un enregistrement immuable de qui a cliqué exactement, quand, sur quelle version des données du cas. Rien de tout cela n'est le travail d'un framework, et les frameworks ne l'essaient pas, à juste titre. Mais cela doit être le travail de quelqu'un. L'état intermédiaire dangereux est une primitive de pause connectée à n'importe quel canal pratique, ce qui explique comment les approbations finissent par être des messages Slack. Je reviendrai sur cet échec ci-dessous, car je l'ai vu se produire. ### 3. Le temps comme citoyen de première classe Les frameworks d'agents pensent en tours. Les institutions pensent en jours. Un cas de litige attend onze jours une réponse du commerçant. Une exception de prêt reste chez un souscripteur pendant un long week-end. Un rafraîchissement KYC est soumis à un délai réglementaire. Dans la vie d'un de ces cas, la fenêtre de contexte est depuis longtemps passée, le pod a redémarré deux fois, le modèle derrière l'agent a eu une mise à jour de version, et l'application a été déployée quatre fois. La boucle externe doit survivre à tout cela sans que personne ne s'en aperçoive. Cela signifie des timers durables, pas `setTimeout()` et pas une tâche cron lisant une table que vous avez écrite un vendredi. Cela signifie des SLA modélisés comme des données avec des chaînes d'escalade attachées : si l'approbation n'est pas accordée dans les 48 heures, notifier le manager ; à 72 heures, rediriger. Cela signifie qu'un cas peut dormir pendant trois semaines sans coût et se réveiller exactement là où il en était. Les moteurs d'exécution durable et les moteurs BPMN font cela nativement, car tous deux ont été construits par des personnes qui ont été appelées lorsque la version maison est tombée en panne. Les frameworks s'améliorent en matière de persistance, mais la persistance pour la reprise est une promesse plus petite que le temps en tant que primitive de modélisation avec une sémantique d'escalade. ### 4. Politique en tant que données, gérée par la conformité Voici la phrase que j'ai répétée dans plus de réunions que toute autre : la vérification budgétaire ne vit pas à l'intérieur du modèle. Si votre limite de dépenses est une phrase dans un prompt système (« n'approuvez jamais de remboursements supérieurs à 500 $ »), vous n'avez pas de contrôle. Vous avez une requête, faite poliment, à un système stochastique, dans un canal où une entrée contradictoire peut également écrire. L'injection de prompt est l'échec spectaculaire, mais l'échec banal est pire : même lorsque le modèle se conforme à chaque fois, vous ne pouvez pas le prouver. « Nous avons dit au modèle » n'est pas une phrase que vous voulez dire à l'audit interne. > Commentaire de révision : une politique que vous ne pouvez pas montrer en cours d'évaluation est indiscernable d'une politique que vous n'avez pas. Les auditeurs l'ont compris bien avant l'existence des LLM. Le modèle est la politique en tant que données, évaluée en dehors du modèle, avant ou après l'action de l'agent, mais jamais à l'intérieur de celui-ci. Des tables de décision (DMN si vous êtes dans le monde BPMN, mais un service de règles ou même un module de politique bien testé est également admissible) que la conformité peut lire, versionner et modifier sans déploiement de code. L'agent propose : « rembourser 650 $, voici mon raisonnement. » La politique dispose : montant supérieur au seuil, acheminer vers l'approbation humaine. La division du travail est claire. Le modèle fournit un jugement. La table fournit des limites. Lorsque la limite change, la conformité modifie une ligne, le changement est versionné, et aucun ingénieur de prompt n'est impliqué. ### 5. Opérabilité L'obligation la moins glamour, et celle qui décide si le système survit à la deuxième année. Quatre capacités, toutes ennuyeuses, toutes essentielles. Mettre en pause et reprendre sans perdre le contexte : pas seulement la mémoire de l'agent, mais l'ensemble du cas, y compris ses timers et ses approbations en attente. Migration des instances en cours : vous avez déployé la version 3 du processus, mais 4 000 cas sont toujours en cours sur la version 1, et certains d'entre eux s'exécuteront pendant des semaines ; vous avez besoin d'outils pour mapper l'ancien état sur les nouvelles définitions ou pour laisser les versions s'épuiser côte à côte, délibérément. Annulation atomique : lorsqu'un cas doit mourir, tout meurt avec lui, des actions de compensation sont déclenchées pour les étapes déjà validées, et aucun agent orphelin ne continue d'appeler des outils dans le vide. Et un seul endroit pour enquêter : lorsque les opérations demandent « où est le cas 8842 et pourquoi est-il bloqué », la réponse devrait être un seul écran, pas un grep à travers quatre services et un fil Slack. Les frameworks n'ont presque rien à dire à ce sujet, et c'est très bien. Ce n'est pas leur préoccupation. Cela doit être la vôtre. ## Le plan de contrôle est un rôle, pas un produit Tout ce qui précède décrit un rôle. Au moins trois familles de technologies peuvent le remplir, et j'ai vu les trois fonctionner. La comparaison honnête est plus importante que la catégorie dans laquelle se trouve mon employeur. #### Option A : un moteur BPMN Camunda, Flowable et leurs équivalents. Les points forts correspondent presque un à un aux cinq obligations, car les moteurs de workflow ont été construits pour exactement cette classe de problèmes deux décennies avant l'existence des agents. L'historique d'exécution est natif et complet. Les tâches humaines avec identité, groupes de candidats et quatre yeux sont intégrées. Les timers et les escalades sont des éléments de modèle que vous pouvez désigner. L'externalisation des politiques a une réponse de premier ordre dans les tables de décision. Des outils de migration d'instances existent parce que les processus de longue durée l'ont rendu nécessaire. Et le modèle de processus est lisible par des non-ingénieurs, ce qui semble anodin jusqu'au jour où la conformité valide l'artefact exécutable réel au lieu d'une page Confluence qui s'en est éloignée. Deux autres propriétés sont importantes à l'échelle institutionnelle, et elles sont la raison pour laquelle cette catégorie continue de remporter les évaluations de l'industrie réglementée auxquelles je participe. Premièrement, l'échelle ici est prouvée plutôt que projetée : les moteurs de cette famille exécutent déjà des processus clés dans certaines des plus grandes banques, assureurs et détaillants du monde, et la génération actuelle a été réarchitecturée précisément pour des charges de travail à haut débit et à l'échelle horizontale, ce qui signifie que le trafic d'agents que vous prévoyez est inférieur au trafic de paiement que ces moteurs gèrent déjà. Deuxièmement, la surface de gouvernance est un produit, pas un projet : des outils d'opérations pour enquêter sur une instance bloquée, rejouer un incident ou migrer dix mille cas en cours existent sur étagère, avec un fournisseur responsable. Lorsqu'un agent se comporte mal à 2h du matin, la différence entre « ouvrir la console d'opérations » et « grepper le magasin d'événements » est la différence entre un incident et une panne. Les coûts sont réels. Vous exécutez un moteur, et les moteurs ont un poids opérationnel. BPMN a une courbe d'apprentissage, et certains développeurs ont une réaction allergique à tout ce qui ressemble à des diagrammes-as-code. Une discipline de modélisation est requise ; un modèle BPMN bâclé se dégrade exactement comme un code bâclé, juste plus visiblement. #### Option B : un runtime d'exécution durable Temporal, Restate et les équivalents cloud-native. Ce sont d'excellentes pièces d'ingénierie avec la sémantique de durabilité la plus forte de l'industrie : historiques basés sur les événements, relecture déterministe, timers et pauses de plusieurs semaines comme primitives de première classe, et API de versioning pour l'évolution des workflows. Si votre organisation est axée sur le code et allergique aux modèles visuels, c'est une manière légitime de remplir ce rôle, et des équipes que je respecte l'ont fait. Les lacunes sont institutionnelles plutôt que techniques. L'historique des événements existe pour rendre la relecture correcte, pas pour faciliter la vie d'un auditeur ; il est orienté développeur, et un responsable de la conformité ne peut pas lire un workflow Go. La gestion des tâches humaines avec identité résolue par annuaire, quatre yeux et délégation est à construire par vous-même. L'externalisation des politiques est à construire par vous-même (la plupart des équipes ajoutent OPA ou un service de règles, ce qui fonctionne mais ajoute une intégration que vous devez également gouverner). Vous pouvez absolument construire la boucle externe sur Temporal. Prévoyez simplement le fait que vous la construisez, et non que vous la configurez. #### Option C : une machine à états maison disciplinée Postgres, une colonne `state`, des workers, une table d'outbox. Ne laissez personne vous dire que c'est toujours faux. Pour un processus avec un volume modeste et une équipe stable, c'est souvent la bonne première étape, et je l'ai vu bien faire. Pas de nouvelle infrastructure, contrôle total, chaque ligne comprise. Le compromis est que la discipline est porteuse et que la discipline se dégrade. Vous réimplémenterez les timers durables, l'escalade et le versioning, chacun à environ 80 % correctement. La piste d'audit n'est aussi bonne que votre réviseur de code le plus faible. Et le problème majeur est la migration en cours : le mode de défaillance n'est pas le premier jour, c'est le dix-huitième mois, lorsque la version 3 du processus rencontre 4 000 instances toujours en cours d'exécution sur la version 1 et qu'il n'y a pas d'outillage, seulement un très long canal d'incident. | Obligation | Moteur BPMN | Exécution durable | Fait maison | |---|---|---|---| | Piste d'audit sans journalisation personnalisée | Native | Partiel (historique de relecture, orienté développeur) | À construire | | Tâches humaines avec identité, quatre yeux | Native | À construire | À construire | | Timers durables, SLA, escalade | Native | Natif (escalade : à construire) | À construire | | Politique en tant que données, éditable par non-développeur | Native (tables de décision) | À ajouter (OPA, service de règles) | À construire | | Migration d'instances en cours | Outils existants | API existantes, effort requis | L'incident du 18e mois | | Lisible par la conformité | Oui | Non | Non | | Coût opérationnel et d'apprentissage | Moteur + courbe BPMN | Cluster + règles de déterminisme | Le plus bas au départ, se complexifie | Choisissez en fonction de qui est votre organisation, pas uniquement sur ce tableau. Mais choisissez délibérément, car l'option par défaut (la boucle externe nulle part, étalée sur le code de l'application) est la seule option qui échoue toujours. ## Le modèle d'intégration : orchestrer, ne pas remplacer La crainte de la banque, raisonnable à première vue, était que l'ajout d'un plan de contrôle signifiait la réécriture de leurs agents. Ce n'est pas le cas, et toute architecture qui l'exige est erronée. Le modèle qui fonctionne maintient chaque agent dans son framework natif et place le modèle de processus au-dessus d'eux.  Le processus est l'agent, pas un appel à un agent à côté. Cette phrase est toute la conception. Du point de vue de l'institution, l'unité qui compte est le processus de bout en bout : résoudre le litige, ouvrir le compte, examiner la lettre de crédit. Ce processus est ce qui est audité, ce qui porte le SLA, ce sur quoi un régulateur pose des questions. La boucle LLM est une activité à l'intérieur de celui-ci, pas le conteneur autour. Inversez cela (code d'application avec un agent au centre, appelant occasionnellement un workflow) et chaque obligation de la boucle externe retombe dans le code d'application, ce qui est le point de départ de ce guide. Concrètement, pour un cas de litige : 1. Le plan de contrôle démarre une instance de cas avec une clé métier et un ID de corrélation. À partir de ce moment, il y a un historique. 2. Une étape déterministe collecte les données du compte. Pas d'agent. C'est une recherche. 3. Le plan de contrôle invoque l'agent de triage comme une tâche. L'agent vit dans son propre runtime (LangGraph, CrewAI, quel que soit le choix de l'équipe) et est atteint via A2A en tant qu'agent pair, ou ses capacités sont exposées comme des outils via MCP. La boucle interne s'exécute entièrement à l'intérieur du framework : raisonnement, appels d'outils, mémoire. Le plan de contrôle voit une tâche en cours, puis un artefact revenir. 4. La proposition de l'agent atterrit dans les variables de processus. Une table de décision l'évalue : montant, niveau client, score de fraude. En dessous du seuil, procéder automatiquement. Au-dessus, une tâche humaine est créée pour le bon groupe d'approbateurs, avec quatre yeux appliqués et un timer d'escalade de 48 heures armé. 5. Approuvée, l'étape d'exécution s'exécute. Chaque transition, y compris la tâche de l'agent et l'identité de l'approbateur, est déjà dans l'historique. Personne n'a rien journalisé. La limite du protocole est ce qui rend cela agnostique au framework. A2A donne au plan de contrôle un moyen standard de confier une tâche à un agent qu'il n'héberge pas et de recevoir des artefacts en retour, l'équipe de l'agent conservant la pleine propriété de sa pile ; j'ai décrit les mécanismes, la découverte de cartes et les modes de défaillance dans le [guide de terrain A2A](/fr/guides/a2a-field-guide/). MCP couvre les cas en forme d'outil. Les équipes conservent leurs frameworks, leurs évaluations, leurs pipelines de déploiement. L'institution obtient une seule colonne vertébrale. Ce modèle est aussi l'endroit où les agents se rentabilisent. Dans une preuve de concept de financement du commerce, le déplacement de l'examen des documents vers une étape d'agent a fait passer l'examen des lettres de crédit de plusieurs heures à quelques secondes. L'agent a produit ce chiffre. Le plan de contrôle est ce qui a rendu ce chiffre utilisable en production : chaque document examiné a laissé un événement d'audit, chaque exception a été acheminée vers une personne ayant autorité, et les cas de deux semaines ont survécu à chaque déploiement intermédiaire. ## Quand vous n'avez pas besoin d'un plan de contrôle Cette section est la raison pour laquelle vous devriez faire confiance au reste. Un plan de contrôle n'est pas gratuit. Vous ajoutez un moteur à opérer, un modèle ou un artefact de workflow à versionner, de la latence à chaque limite, et un deuxième système que votre équipe d'astreinte doit comprendre. Ne payez pas cela pour un chatbot. Vous n'avez pas besoin d'un plan de contrôle lorsqu'un humain examine 100 % de la sortie avant que quoi que ce soit ne se produise (un assistant de rédaction n'est pas un système autonome, quoi que dise la présentation commerciale). Vous n'en avez pas besoin pour les outils de développement internes, les prototypes ou tout ce dont la pire défaillance est un mauvais paragraphe. Vous n'en avez pas besoin pour la génération à un coup sans effets secondaires. Dans tous ces cas, le framework seul, ou aucun framework du tout, est la bonne quantité d'architecture. Une étape plus tôt, demandez-vous si vous avez besoin d'un agent en premier lieu. Mon heuristique, tirée d'un article que j'ai écrit sur l'open banking, est de compter les outils et la déviation dans le chemin : « lorsque vous avez ce niveau de déviation où vous pouvez utiliser trois outils contre 10 outils, c'est là que l'IA agentique est mieux adaptée. » Trois outils et un chemin prévisible, c'est un programme. Écrivez du code, ou modélisez un workflow déterministe, et obtenez le déterminisme gratuitement. Dix outils, une grande variance dans ce dont chaque cas a besoin, un jugement sur lequel utiliser dans quel ordre : c'est là que la boucle interne gagne ses tokens. J'ai vu des équipes déployer un agent, avec tout son fardeau d'évaluation, sur un flux qui était trois instructions `if` déguisées. Le plan de contrôle devient nécessaire lorsque les obligations de la boucle externe cessent d'être théoriques. L'argent ou les engagements se déplacent sans qu'un humain ne touche chacun d'eux. Le travail survit à une fenêtre de contexte et à un déploiement. Un régulateur, ou votre propre fonction d'audit, peut demander « pourquoi le système a-t-il fait cela » et s'attendre à une réponse. Les agents de plus d'une équipe doivent se composer en un seul processus. Deux ou plus de ces éléments, et la question n'est plus de savoir si vous avez une boucle externe, mais seulement si elle est délibérée ou accidentelle. ## Ce qui se brise lorsque la boucle externe vit à l'intérieur du framework Trois échecs, généralisés à partir de systèmes réels que j'ai examinés. Détails modifiés, structure intacte. #### La piste d'audit qui est morte avec le pod Une équipe a construit un pipeline d'agents qui assemblait sa trace de raisonnement complète en mémoire et écrivait un enregistrement consolidé à la fin de chaque exécution. Conception propre, facile à lire, jusqu'à ce qu'un pod soit tué par OOM en cours d'exécution après que l'action ait déjà été effectuée. Résultat : une opération exécutée sans trace de la raison. Le magasin de points de contrôle contenait l'état du graphe nécessaire à la reprise, mais l'état de reprise n'est pas une attestation, et la politique de rétention de ce magasin avait été définie par un défaut d'infra que personne n'avait lu. La solution n'était pas une meilleure journalisation. C'était de déplacer l'achèvement de chaque étape dans un moteur où l'enregistrement n'est pas facultatif, de sorte qu'un crash peut perdre le futur mais jamais le passé. #### L'approbation qui était un emoji Slack Humain dans la boucle, implémenté comme un message à un canal ; un pouce levé de n'importe qui dans le canal reprenait le graphe. La démo était magnifique. Puis les questions : qui a exactement approuvé le cas 4417 ? Cette personne était-elle autorisée pour ce montant ? Le message a-t-il été modifié après la réaction ? Que se passe-t-il lorsque l'approbateur part et que son compte est désactivé ? Et celle qui a mis fin à la revue de conception : la politique de rétention de l'espace de travail supprimait les messages après 90 jours, ce qui signifiait que la preuve d'approbation avait une durée de vie plus courte que les prêts qu'elle approuvait. Une approbation est un événement d'autorisation avec une identité attachée. Un emoji de réaction n'est ni l'un ni l'autre. #### La vérification budgétaire qui vivait dans le prompt système Un agent de remboursement avec sa limite exprimée comme une instruction de prompt système. Un exercice de red-team l'a contourné en une journée avec une injection anodine. Mais la découverte qui importait était le contrefactuel : même si le modèle avait tenu bon à chaque fois, l'institution ne pouvait pas démontrer l'application. Il n'y avait aucun artefact à montrer, aucun log d'évaluation, aucune politique versionnée. Déplacer la limite dans une table de décision évaluée après la proposition de l'agent a transformé un comportement non prouvable en un contrôle avec preuve. Le prompt mentionne toujours la limite, par courtoisie envers le modèle. La table est ce qui l'applique. > Commentaire de révision : chacun de ces systèmes fonctionnait en démo. La boucle externe est invisible dans les démos, car les démos ne plantent pas, ne sont pas auditées et ne fonctionnent pas pendant trois semaines. ## Ce que les régulateurs demandent réellement Aucun des documents importants ici ne dit « agent ». Ils n'en ont pas besoin. Lisez-les comme des exigences sur la boucle externe et la correspondance est directe. C'est une lecture mesurée, pas une alerte ; la plupart de ces attentes sont des choses qu'un système bien géré souhaite de toute façon. La directive E-23 mise à jour de l'OSFI sur la gestion des risques liés aux modèles (finale en septembre 2025, effective le 1er mai 2027, pour toutes les institutions financières sous réglementation fédérale au Canada) inclut explicitement l'IA et l'apprentissage automatique et demande une gouvernance du cycle de vie : inventaire, conception, examen, déploiement, surveillance et responsabilité claire, proportionnelle au risque. Un système agentique qui vit entièrement à l'intérieur du code d'application fait de presque chacune de ces attentes un projet de documentation manuel. Un plan de contrôle fait de la plupart d'entre elles un sous-produit : l'inventaire est l'ensemble des définitions de processus et de décisions déployées, le cycle de vie est l'historique des artefacts versionnés, la surveillance est les propres données opérationnelles du moteur. La loi européenne sur l'IA place l'évaluation de la solvabilité des personnes physiques à l'annexe III, ce qui fait d'un agent de décision de crédit un système à haut risque ; ces obligations sont devenues exécutoires le 2 août 2026. L'article 12 exige des journaux d'événements générés automatiquement, ce qui correspond à l'obligation un de ce guide en langage réglementaire (« automatique » est le mot clé ; la journalisation volontaire ne qualifie pas). L'article 14 exige une surveillance humaine efficace, ce qui correspond à l'obligation deux, y compris la partie où la surveillance signifie une personne ayant autorité et la capacité d'intervenir, et non une personne en copie sur un canal. SR 11-7, la directive de la Réserve fédérale sur le risque de modèle, est la référence pour les banques américaines depuis 2011, et sa définition d'un modèle (une approche quantitative qui traite les entrées en estimations, appliquée aux décisions) couvre confortablement un agent piloté par LLM. Sa principale exigence est un défi efficace : validation indépendante, documentation et inventaires. Vous ne pouvez pas contester efficacement un système dont le chemin de décision n'existe que dans les logs d'application et les fichiers de prompt. Vous pouvez contester un modèle de processus, une table de décision et un historique d'exécution, car ce sont des objets inspectables avec des versions. Le modèle commun aux trois : les régulateurs convergent vers la gouvernance du cycle de vie, les enregistrements automatiques et une surveillance humaine responsable. Ce sont exactement les choses que la boucle interne ne peut pas fournir et que la boucle externe existe pour fournir. Les institutions qui séparent les boucles constateront que la conformité découle principalement de l'architecture. Les institutions qui ne le font pas exécuteront un processus de paperasse parallèle qui décrit un système qu'elles ne peuvent pas réellement voir. ## La version en un paragraphe Les frameworks d'agents (LangGraph, CrewAI, l'OpenAI Agents SDK) sont excellents pour la boucle interne : raisonnement, sélection d'outils, assemblage de prompts, mémoire. Ils sont structurellement inadaptés à la gestion de la boucle externe : la piste d'audit qui existe sans journalisation personnalisée, l'approbation humaine avec identité et quatre yeux, le temps en tant que citoyen de première classe, la politique en tant que données gérées par la conformité, et l'opérabilité du travail de longue durée. La réponse n'est pas de tout remplacer ; c'est un plan de contrôle qui orchestre les agents dans le framework dans lequel ils ont été construits, accessibles via A2A ou MCP, avec le modèle de processus comme artefact gouverné. Le processus est l'agent, pas un appel à un agent à côté. Remplissez ce rôle avec un moteur BPMN, un runtime d'exécution durable, ou une machine à états maison disciplinée, en étant conscient de ce que chacun rend natif et de ce que chacun rend votre problème. Ignorez tout cela pour les prototypes et les outils révisés par des humains, et ignorez entièrement l'agent lorsque trois outils et un chemin prévisible signifient que vous devriez simplement écrire du code. Adoptez-le avant la première fois qu'un auditeur, un régulateur ou votre propre revue d'incident pose une question à laquelle vos logs ne peuvent pas répondre. ## Références - BSIF, [Directive E-23 : Gestion du risque de modèle (2027)](https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/guideline-e-23-model-risk-management-2027), finale en septembre 2025, effective le 1er mai 2027. - Loi européenne sur l'IA, [Annexe III : systèmes d'IA à haut risque](https://artificialintelligenceact.eu/annex/3/) et [Article 12 : tenue de registres](https://artificialintelligenceact.eu/article/12/) ; obligations de l'Annexe III exécutoires à partir du 2 août 2026. - Réserve fédérale, [SR 11-7 : Guide sur la gestion du risque de modèle](https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm) (2011). - Blog Camunda, [L'IA agentique au service de l'Open Banking](https://camunda.com/blog/2025/12/agentic-ai-puts-open-banking-to-work/), source de l'heuristique trois outils contre dix citée ci-dessus. - Blog Camunda, [Utiliser A2A pour atteindre vos objectifs commerciaux, partie 1](https://camunda.com/blog/2026/02/using-a2a-to-achieve-your-business-goals-pt-1/) et [partie 2](https://camunda.com/blog/2026/02/using-a2a-to-achieve-your-business-goals-pt-2/), ma description co-écrite du modèle d'intégration agent-à-agent. - [Spécification du protocole A2A](https://a2a-protocol.org/) et [Protocole de Contexte de Modèle](https://modelcontextprotocol.io/), les deux couches d'interopérabilité référencées dans le modèle d'intégration. - [Documentation LangGraph](https://langchain-ai.github.io/langgraph/) (persistance et `interrupt()`), [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/) et [documentation Temporal](https://docs.temporal.io/), pour les capacités de boucle interne et d'exécution durable discutées. - Sur ce site : [le guide de terrain A2A](/fr/guides/a2a-field-guide/).