Agent ou flux de travail ? Séparer la réflexion de l’exécution dans l’IA d’entreprise

L’IA agente est le terme à la mode en ce moment. Donnez à un LLM quelques outils, ajoutez-lui une mémoire, connectez-le à des systèmes d’entreprise, laissez-le décider de la prochaine action à entreprendre, et le résultat est alors qualifié d’agent IA. Cependant, il y a un problème : les systèmes d’entreprise ne peuvent pas fonctionner uniquement sur des décisions probabilistes. Lorsqu’une IA interagit avec les données des fournisseurs, les processus financiers, les données ERP, les validations ou d’autres opérations critiques, certaines choix peuvent rester flexibles tandis que d’autres ne le sont pas.

Un projet de gestion des fournisseurs basé sur RAG, LangGraph, MCP, des validations humaines et Amazon Bedrock a abouti à une idée directrice : l’agent doit décider de ce qui doit être fait, tandis que l’application doit contrôler la manière dont cela se produit. Tout le reste de la conception découle de cette séparation.

Pourquoi l’agent ne devrait pas tout faire

Imaginez une demande d’intégration d’un fournisseur : créer ce fournisseur, valider ses informations, vérifier la politique d’achat et l’envoyer à SAP. En théorie, un agent entièrement autonome pourrait interpréter cette demande, rechercher des documents internes, valider les données, déterminer s’une approbation est nécessaire, se connecter à SAP, créer le dossier et réessayer en cas d’échec.

Cela est techniquement possible, mais architecturalement peu attrayant. Un LLM fonctionne de manière probabiliste : la même entrée peut suivre des chemins de raisonnement légèrement différents, et les modèles, les prompts ainsi que le contexte évoluent constamment. Cette flexibilité est excellente pour interpréter ce que veut dire une personne, mais elle est inadaptée à l’exécution de transactions commerciales critiques. Un modèle ne devrait pas décider si une transaction dans une base de données doit être confirmée, inventer sa propre stratégie de réessai, juger si l’autorisation peut être omise ou détenir des identifiants SAP. La réflexion et l’exécution sont donc séparées.

Flux de travail contre agents

Ces deux termes sont souvent confondus, mais la différence est importante. Un flux de travail d’IA suit un parcours pour l’essentiel prédéfini :

Request
   ↓
Validate
   ↓
Retrieve Policies
   ↓
Evaluate
   ↓
Approval
   ↓
Create Supplier
   ↓
Publish Integration Event

L’application connaît chaque état et chaque transition. Un agent IA dispose d’une plus grande liberté pour choisir ce qui vient ensuite :

User Request
      ↓
     LLM
      ↓
Reason about intent
      ↓
Choose next capability
   ↙    ↓     ↘
Search Validate Request Approval

Ce libre arbitre a de la valeur, mais il devient risqué lorsque l’agent accède à l’infrastructure transactionnelle. La conception préférée combine les deux modèles.

Raisonnement agentiel en haut, exécution déterministe en bas

À un niveau élevé, l’architecture ressemble à ceci :

USER
                      │
                      ▼
                 FastAPI API
                      │
                      ▼
                 LangGraph
                Agent Workflow
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        RAG        Reasoning     Tools
          │
          ▼
   Amazon OpenSearch
          │
          ▼
     AWS Bedrock
                      │
                      ▼
                MCP Boundary
                      │
                      ▼
               Application API
                      │
                      ▼
              Domain / Use Cases
                      │
              ┌───────┴───────┐
              ▼               ▼
          PostgreSQL         AWS SQS
                                │
                                ▼
                               SAP

Une frontière se distingue clairement : le LLM se trouve au-dessus de la couche d’application. Il peut interpréter les demandes, raisonner, récupérer des connaissances, recommander des actions et solliciter des outils. Il ne contrôle pas la transaction.

Où les agents trouvent leur place

Le raisonnement probabiliste s’avère utile dans quelques domaines spécifiques.

Compréhension de l’intention

Les utilisateurs n’écrivent pas des appels API parfaitement structurés. Un utilisateur pourrait dire qu’il doit intégrer ACME pour une opération au Brésil et souhaite savoir si tout est conforme. Cette phrase mélange intention, contexte et ambiguïté, et un LLM est très doué pour la transformer en quelque chose que l’application peut utiliser :

{
  "intent": "supplier_onboarding",
  "supplier": "ACME",
  "country": "BR",
  "requires_policy_validation": true
}

À partir de là, le logiciel déterministe prend le relais.

Récupération des connaissances d’entreprise avec RAG

L’intégration dépend des politiques internes : documents requis, règles fiscales, exigences spécifiques à chaque pays, restrictions en matière d’achats et seuils d’approbation. Plutôt que de remplir ces documents dans des prompts ou d’en coder rigoureusement chaque règle, le système peut les récupérer :

Question
   ↓
Embedding
   ↓
Amazon OpenSearch
   ↓
Relevant Policy Chunks
   ↓
LLM Context
   ↓
Reasoning

Une deuxième limite s’applique ici. La récupération des informations fournit un contexte et ne doit pas influencer les décisions commerciales. Il est utile de trouver une politique stipulant que les fournisseurs dépassant un certain seuil nécessitent une approbation. L’application de cette approbation doit rester gérée par la logique habituelle du programme.

Où les workflows sont plus efficaces

Lorsque la demande a été comprise, supposons qu’il faille créer un fournisseur. Le processus peut comprendre des étapes telles que celles-ci :

Validate Supplier
      ↓
Check Duplicate
      ↓
Check Authorization
      ↓
Persist Supplier
      ↓
Publish Integration Event
      ↓
Wait for SAP Result

Un LLM ne devrait pas improviser cela. Le flux de travail doit définir les garanties d’exécution : validation, autorisation, idempotence, prévention des doublons, tentatives de réexécution, journaux d’audit, limites des transactions et gestion des erreurs. Ce sont des problématiques d’ingénierie logicielle, et l’ingénierie des prompts n’a rien à y voir.

Pourquoi LangGraph

Pour l’orchestration, LangGraph a été choisi car il offre des transitions d’état explicites, au lieu d’une boucle ouverte où un agent décide constamment quel outil appeler ensuite. Conceptuellement, le graphe ressemble à ceci :

START
  │
  ▼
Understand Intent
  │
  ▼
Retrieve Policies
  │
  ▼
Evaluate Request
  │
  ├───────────────┐
  │               │
  ▼               ▼
Approval Needed?  No Approval
  │               │
  ▼               │
Human Approval    │
  │               │
  └───────┬───────┘
          ▼
     Request Action
          │
          ▼
         END

Dans les nœuds sélectionnés, le modèle conserve sa liberté de raisonnement, tandis que le graphe limite dans quelle mesure ses conclusions peuvent influencer le système. Le résultat est une autonomie encadrée : liberté au sein de limites architecturales clairement définies.

L’intervention humaine a plusieurs significations

Les discussions sur l’IA d’entreprise se réduisent souvent à « il suffit d’inclure une personne dans le processus ». Pourtant, les humains peuvent intervenir pour différentes raisons, et au moins deux types d’approbation méritent d’être distingués.

Approbation commerciale

Le processus métier lui-même exige une validation, que l’IA soit impliquée ou non :

Supplier
   ↓
Compliance Check
   ↓
Manager Approval
   ↓
Creation

Approbation de l’outil d’IA

Une deuxième approbation est nécessaire car l’agent souhaite effectuer une action sensible :

Agent
  ↓
"Create supplier"
  ↓
Tool requires confirmation
  ↓
Human approves
  ↓
Application executes

Ces deux problématiques sont différentes. L’une relève du domaine technique et l’autre de la gouvernance de l’IA. Les mélanger provoque de la confusion architecturale.

Pourquoi MCP est important

Un agent qui travaille avec des systèmes d’entreprise a besoin d’outils, mais exposer l’infrastructure directement au LLM crée des risques inutiles. La meilleure approche consiste à utiliser un outil MCP :

Agent
  ↓
MCP Tool
  ↓
Application API
  ↓
Use Case
  ↓
Domain
  ↓
Infrastructure

et évite de relier l’agent à une base de données :

Agent
  ↓
PostgreSQL

ou directement à SAP :

Agent
  ↓
SAP

Avec la première forme, l’application contrôle toujours l’authentification, l’autorisation, la validation, les règles métier, l’audit, les transactions et l’idempotence. MCP devient une frontière entre le raisonnement de l’IA et les capacités de l’entreprise. L’agent exprime l’intention, tandis que l’application est responsable de l’exécution.

SAP ne doit pas dépendre du fonctionnement continu du LLM

Les systèmes externes tombent en panne. SAP peut être indisponible, le réseau peut se couper, un service intermédiaire peut atteindre sa limite de temps, et le fournisseur du LLM peut également être hors ligne. Exécuter tout cela de manière synchrone au sein d’un cycle d’agent rend la résilience difficile. C’est pourquoi on utilise des messages asynchrones avec AWS SQS. Au lieu de cela :

Agent
  ↓
SAP
  ↓
Wait...
  ↓
Timeout

le flux devient :

Agent
  ↓
Application
  ↓
Persist State
  ↓
AWS SQS
  ↓
Integration Worker
  ↓
SAP

La transaction commerciale n’attend plus que SAP réponde immédiatement. Un opérateur gère les tentatives répétées, les retards, les files de messages échoués, l’observabilité et le traitement idempotent, et ces garanties proviennent de logiciels déterministes et non d’un modèle.

Une architecture hybride

Lorsque ces limites sont établies, qualifier le système simplement d’agent IA n’est plus approprié. Il s’agit d’une architecture hybride :

┌─────────────────────────────┐
│     PROBABILISTIC LAYER     │
│                             │
│ LLM                         │
│ RAG                         │
│ Intent Understanding        │
│ Reasoning                   │
│ Tool Selection              │
└──────────────┬──────────────┘
               │
        Controlled Boundary
               │
┌──────────────▼──────────────┐
│     DETERMINISTIC LAYER     │
│                             │
│ Application Use Cases       │
│ Domain Rules                │
│ Authorization               │
│ Validation                  │
│ Transactions                │
│ Idempotency                 │
│ Messaging                   │
│ Integrations                │
└─────────────────────────────┘

Cette distinction est essentielle pour l’IA agente d’entreprise.

L’architecture logicielle reste importante

Une erreur courante avec l’IA générative est de penser que l’architecture traditionnelle n’a plus d’importance. Au contraire, elle en a davantage. Un système capable de raisonner dynamiquement et de choisir des actions a besoin de limites plus strictes quant à ce que ces actions peuvent faire. Le DDD, le CQRS, l’architecture hexagonale, l’authentification, l’autorisation, les messageries, l’observabilité, la résilience et l’idempotence s’appliquent toujours. L’IA n’en élimine aucune. Elle ajoute simplement un composant probabiliste qui doit fonctionner en toute sécurité à leurs côtés.

Agent ou flux de travail ?

La réponse est les deux. Utilisez des agents là où l’incertitude et la capacité de raisonnement ajoutent de la valeur, et des flux de travail déterministes là où la prévisibilité et les garanties sont cruciales. Un modèle mental utile :

AI AGENT
                 │
                 │ decides WHAT
                 ▼
        ┌─────────────────┐
        │ Controlled Tool │
        │    Boundary     │
        └────────┬────────┘
                 │
                 │ requests
                 ▼
          APPLICATION
                 │
                 │ decides HOW
                 ▼
             DOMAIN
                 │
                 ▼
        INFRASTRUCTURE

Le LLM ne devrait pas devenir l’architecture elle-même. Il devrait y participer.

Où l’autonomie est utile

La question pertinente n’est pas de savoir quelle autonomie on peut accorder à un modèle, mais plutôt où cette autonomie crée de la valeur. L’autonomie convient pour interpréter une demande vague, rechercher parmi de nombreux documents internes, raisonner en fonction du contexte et proposer la prochaine action. Elle ne convient pas pour ignorer les règles métier, gérer des transactions ou conserver des identifiants de base de données de production.

L’objectif est une autonomie contrôlée, ce qui, dans les systèmes d’entreprise, signifie combiner le raisonnement par l’IA probabiliste avec une ingénierie déterministe. La question suivante se pose naturellement : lorsque l’agent doit accéder à SAP ou à une base de données, à quoi devrait ressembler cette frontière exactement ?