Peux-tu clôturer mon trajet et vérifier les frais ?

Orchestration, workflow et contrôle du processus

Introduction — Relier des capacités ne suffit pas

Stéphane : Mon trajet est toujours ouvert alors que j’ai restitué le vélo. Peux-tu le clôturer et vérifier les frais ?
Assistant Bikaroo : Je dois d’abord identifier le trajet, vérifier son état, consulter la procédure applicable, contrôler les preuves de restitution et déterminer si une régularisation nécessite une validation.

Les chapitres précédents ont progressivement ajouté des capacités autour du LLM :

• le RAG permet de retrouver une procédure ;
• les outils permettent de consulter ou de modifier les systèmes ;
• MCP peut standardiser l’exposition de ces capacités.

La demande de Stéphane exige plusieurs étapes, des décisions, un état persistant, des règles métier, des contrôles d’autorisation et parfois une intervention humaine. Certaines tâches peuvent bénéficier du LLM, tandis que les règles critiques et les transactions doivent rester déterministes.

L’orchestration coordonne ces éléments. Elle détermine comment le traitement progresse, se suspend, reprend, échoue ou s’arrête.

Ce chapitre s’intéresse donc moins à la capacité d’un modèle à choisir une action qu’à la manière dont l’application impose un déroulement contrôlé.

Ce que vous allez apprendre

À la fin de ce chapitre, vous pourrez :

• expliquer le rôle d’un orchestrateur dans une solution d’IA ;
• distinguer décision probabiliste, règle déterministe, workflow et autonomie agentique ;
• concevoir un état de processus explicite, persistant et reprenable ;
• gérer branches, erreurs, retries, compensations, budgets et conditions d’arrêt ;
• choisir un mécanisme d’orchestration adapté et observer le processus de bout en bout.

Comprendre le rôle de l’orchestrateur

Coordonner plutôt qu’exécuter seul

Un orchestrateur est le composant qui coordonne les étapes d’un traitement.

Ses décisions portent sur trois choses. Il conduit le flux — quelle étape exécuter ensuite, quel modèle ou outil utiliser, quelles informations placer dans le contexte, quelle règle métier appliquer. Il place les points de contrôle — quand demander une clarification, une confirmation ou une approbation. Il gère les suites — comment traiter un résultat ou une erreur, quand réessayer, compenser, escalader ou arrêter, et comment conserver l’état du processus.

L’orchestrateur n’est pas nécessairement un produit distinct. Il peut être implémenté sous forme :

• de code applicatif ;
• de machine à états ;
• de moteur de workflow ;
• de plateforme d’orchestration ;
• d’une combinaison de règles déterministes et d’appels de modèles.

Comment une demande devient une prochaine action

Lorsqu’un utilisateur écrit :

prompt
Clôture mon trajet et vérifie les frais.

l’orchestrateur ne reçoit pas automatiquement une liste d’étapes prêtes à exécuter. Il reçoit d’abord une demande en langage naturel.

Son premier rôle est de construire une situation de décision pour le modèle. Il rassemble les éléments utiles : la demande de l’utilisateur, l’état actuel du dossier, les outils disponibles, les règles applicables, les limites d’autorisation, le budget d’exécution et les conditions d’arrêt.

Le LLM ne reçoit donc pas seulement la phrase de Stéphane. Il reçoit une vue contrôlée de la situation.

Il peut alors répondre sous une forme structurée, par exemple :

{
  "nextAction": "get_current_trip",
  "reason": "Le trajet concerné doit être identifié avant toute clôture.",
  "requiredArguments": {
    "memberId": "MEM-10482"
  }
}

L’orchestrateur reprend alors le contrôle. Il vérifie que l’action existe, que l’utilisateur a le droit de l’exécuter, que les arguments sont valides, que l’action respecte le processus prévu et qu’aucune confirmation humaine n’est requise.

Si tout est conforme, l’orchestrateur appelle le système concerné. Le résultat devient une observation :

{
  "tripId": "TRIP-84219",
  "status": "OPEN",
  "bikeReturned": true
}

Cette observation est ajoutée à l’état du processus. L’orchestrateur peut alors construire un nouveau contexte et rappeler le LLM pour décider de l’étape suivante.

La boucle continue jusqu’à ce qu’une condition terminale soit atteinte : objectif rempli, validation humaine requise, information manquante, budget dépassé, erreur non récupérable ou arrêt explicite.

Le prompt initial ne devient donc pas directement un workflow complet. Il déclenche une boucle contrôlée dans laquelle le LLM propose, l’orchestrateur vérifie, l’application exécute et l’état du processus conserve ce qui a réellement eu lieu.

Répartir les responsabilités sans les redéfinir

Le chapitre 6 a déjà établi la frontière fondamentale : le LLM propose, l’application contrôle et le système métier conserve la vérité opérationnelle. L’orchestration ne change pas cette répartition ; elle l’applique à un traitement composé de plusieurs étapes.

Dans ce chapitre, le point nouveau est donc la coordination dans le temps. L’orchestrateur décide quelle capacité mobiliser, conserve l’état du dossier, impose les règles et sait quand suspendre, reprendre ou arrêter. Le LLM interprète les situations ambiguës ; les workflows et règles traitent les décisions déterministes ; les tools consultent ou modifient les systèmes ; les humains clarifient, approuvent et prennent en charge les exceptions.

Combiner décisions probabilistes et règles déterministes

Une décision souple

Certaines tâches acceptent une réponse probabiliste :

Classer la demande de Stéphane :
- trajet resté ouvert
- contestation de frais
- vélo endommagé
- autre

Le LLM peut aider à interpréter le langage et proposer la catégorie la plus probable.

Une règle obligatoire

D’autres décisions doivent produire le même résultat pour les mêmes données :

Si montant de régularisation > 50 €
→ approbation d’un responsable obligatoire

Cette règle doit être codée ou configurée explicitement.

Une architecture hybride

LLM
→ interprète le langage
→ extrait ou classe
→ propose

Règles et workflow
→ vérifient
→ imposent l’ordre
→ autorisent ou bloquent

Systèmes métier
→ exécutent les transactions

Construire le processus Bikaroo

Décomposer l’objectif

À ce stade, il faut distinguer deux choses.

D’un côté, l’équipe qui conçoit le service peut décomposer le cas métier en grandes étapes attendues. Cette décomposition donne une structure au processus Bikaroo :

1. identifier le membre
2. retrouver le trajet concerné
3. vérifier son état actuel
4. consulter la procédure applicable
5. collecter les preuves de restitution
6. décider si la clôture peut être exécutée
7. demander confirmation si nécessaire
8. clôturer le trajet
9. recalculer les frais
10. préparer ou approuver la régularisation
11. notifier Stéphane

De l’autre côté, pendant l’exécution, le LLM ne doit pas nécessairement produire tout ce plan d’un seul coup. Il peut proposer la prochaine action utile, puis attendre l’observation suivante.

Construire le contexte à chaque étape

Le contexte du modèle n’est pas préparé une fois pour toutes.

L’orchestrateur peut construire un contexte différent à chaque appel :

Étape d’interprétation
→ demande de Stéphane + historique utile

Étape de lecture de procédure
→ question reformulée + passages RAG

Étape de synthèse finale
→ état du processus + résultats validés + décisions humaines

Il doit éviter d’accumuler tous les échanges et tous les résultats.

Il peut :

• sélectionner les éléments utiles ;
• résumer des étapes terminées ;
• masquer les données sensibles ;
• séparer faits vérifiés et hypothèses ;
• conserver les preuves en dehors du prompt ;
• reconstruire le contexte à partir d’un état fiable.

Sélectionner modèles et outils

Une orchestration peut utiliser plusieurs modèles :

modèle compact
→ classification simple

modèle plus puissant
→ interprétation complexe

modèle d’embedding
→ recherche documentaire

modèle visuel
→ analyse d’une photo de preuve

Elle peut aussi ne présenter au LLM que les outils pertinents :

list_member_trips
get_trip_status
get_bike_return_event
close_open_trip
calculate_trip_fees
prepare_fee_adjustment

Les outils sans rapport avec le cas restent invisibles.

Cette sélection réduit :

• le risque d’appel inapproprié ;
• l’ambiguïté ;
• le coût en tokens ;
• la latence ;
• la surface d’attaque.

Conserver un état explicite

La conversation ne suffit pas

Quand une demande se traite en plusieurs étapes, l’application doit savoir où elle en est.

Dans le cas de Stéphane, elle doit pouvoir répondre à des questions très concrètes :

• le membre a-t-il été identifié ?
• le trajet concerné a-t-il été retrouvé ?
• son état officiel a-t-il été vérifié ?
• la preuve de restitution a-t-elle été contrôlée ?
• la clôture a-t-elle déjà été exécutée ?
• le recalcul des frais est-il terminé ?
• une approbation humaine est-elle encore attendue ?

C’est cela que l’on appelle ici l’état du processus.

Exemple :

{
  "caseId": "CASE-2026-1842",
  "memberId": "MEM-10482",
  "selectedTripId": "TRIP-84219",
  "tripStatusBefore": "OPEN",
  "returnEvidenceVerified": true,
  "confirmationReceived": true,
  "tripClosureStatus": "SUCCEEDED",
  "feeReviewStatus": "PENDING_APPROVAL",
  "currentStep": "WAITING_FOR_MANAGER_APPROVAL"
}

Cet état ne doit pas dépendre uniquement du texte de la conversation.

Il doit être stocké dans une structure fiable afin de permettre :

• la reprise après interruption ;
• l’audit ;
• la prévention des doubles actions ;
• la gestion des erreurs ;
• l’affichage de la progression ;
• la corrélation entre événements ;
• la séparation entre faits, décisions et messages.

État conversationnel et état de processus

État conversationnel
→ ce qui a été dit
→ préférences de formulation
→ clarifications

État de processus
→ identifiants vérifiés
→ étapes terminées
→ décisions prises
→ autorisations
→ résultats transactionnels

Les deux peuvent interagir, mais ils ne doivent pas être confondus.

Gérer les branches et les décisions

Un workflow contient souvent des branches.

Un seul trajet correspond à la demande ?
├── oui → poursuivre
└── non → demander une clarification

Le trajet est-il encore ouvert ?
├── oui → vérifier les preuves
└── non → expliquer le statut actuel

La régularisation dépasse-t-elle le seuil autorisé ?
├── oui → approbation humaine
└── non → poursuivre automatiquement

Les conditions critiques doivent être évaluées à partir de données validées et de règles explicites.

Gérer les erreurs et les reprises

Distinguer les types d’échec

Une erreur n’est pas l’autre, et chacune appelle une réponse différente — réessayer, demander une précision, escalader ou renoncer. L’orchestrateur doit donc les distinguer :

• erreur technique temporaire ;
• erreur technique permanente ;
• erreur métier ;
• donnée absente ;
• ambiguïté ;
• absence d’autorisation ;
• confirmation refusée ;
• approbation rejetée ;
• état d’exécution incertain.

Retry contrôlé

Un retry automatique est envisageable lorsque :

erreur temporaire
+
opération sûre à rejouer
+
limite de tentatives respectée

Il faut éviter de rejouer aveuglément une opération d’écriture.

Idempotence

Une opération idempotente peut être répétée sans multiplier son effet.

Exemple :

close_open_trip(
  tripId = "TRIP-84219",
  idempotencyKey = "CASE-2026-1842-CLOSE"
)

La clé d’idempotence permet au système de reconnaître une tentative déjà traitée.

Compensation

Un processus distribué ne bénéficie pas toujours d’une transaction globale.

Si plusieurs étapes ont réussi avant un échec, il faut parfois appliquer une compensation.

trajet clôturé
+
régularisation impossible
→ créer une tâche d’exception
→ ne pas rouvrir automatiquement le trajet sans règle explicite

Une compensation n’est pas forcément l’inverse exact d’une action. Elle peut consister à :

• annuler une réservation ;
• créer une écriture corrective ;
• marquer un dossier incomplet ;
• demander une intervention humaine ;
• notifier une équipe.

État incertain

requête envoyée
→ timeout
→ résultat inconnu

Il doit vérifier l’état réel du système avant de réessayer.

Définir des conditions d’arrêt et des budgets

Un processus ne doit pas progresser indéfiniment.

Ces limites bornent trois ressources. Le temps — timeout global et par étape, durée maximale d’attente humaine, date d’expiration du dossier. Le volume — nombre maximal d’appels d’outils, de retries et de tokens. L’argent — un budget financier explicite.

Exemple :

maximum 8 appels d’outils
maximum 2 retries pour une lecture
aucun retry aveugle pour une écriture
expiration après 7 jours sans réponse

Ces limites sont déterministes et doivent être observables.

Intégrer l’humain dans la boucle (human-in-the-loop)

L’humain peut intervenir à plusieurs endroits.

Clarification

response
Deux trajets correspondent. Lequel souhaitez-vous faire vérifier ?

Confirmation

response
Confirmez-vous la clôture du trajet TRIP-84219 ?

Approbation

response
La régularisation de 72 € dépasse le seuil automatique. Un responsable doit l’approuver.

Exception

response
Les preuves disponibles ne permettent pas de conclure. Le dossier est transféré à Marie.

Suspendre et reprendre

Lorsqu’une approbation est nécessaire, le processus peut rester suspendu plusieurs heures ou plusieurs jours.

Pour reprendre un dossier plus tard, l’orchestrateur doit se souvenir précisément de ce qui était en suspens. Il conserve :

• l’étape en attente ;
• le dossier concerné ;
• la personne ou le rôle attendu ;
• la date limite ;
• les éléments soumis ;
• la décision reçue ;
• la trace de reprise.

Répondre tout de suite ou reprendre plus tard

Toutes les étapes ne se déroulent pas pendant que l’utilisateur regarde l’écran.

Certaines demandes peuvent recevoir une réponse immédiate : lire l’état d’un trajet, calculer un montant simple, reformuler une procédure ou poser une question de clarification.

D’autres étapes demandent d’attendre :

• une confirmation de Stéphane ;
• une approbation d’un responsable ;
• une réponse du système de facturation ;
• la fin d’un traitement plus long ;
• un événement externe.

C’est ici que l’état du processus devient indispensable. Si le traitement s’arrête temporairement, l’application doit savoir pourquoi elle attend, ce qu’elle attend, pendant combien de temps, et à quelle étape reprendre.

Exemple :

{
  "jobId": "JOB-9912",
  "caseId": "CASE-2026-1842",
  "status": "WAITING_FOR_APPROVAL",
  "resumeAt": "FEE_ADJUSTMENT_DECISION"
}

EN PRATIQUE

Lorsque la décision ou l’événement attendu arrive, l’orchestrateur ne recommence pas depuis le début. Il reprend à partir de l’état enregistré.

Choisir le bon mécanisme de processus

Une fois que l’on comprend qu’un processus doit conserver un état, gérer des règles, attendre parfois un humain et reprendre après erreur, une nouvelle question apparaît : faut-il vraiment construire tout cela avec une boucle LLM, ou existe-t-il un mécanisme plus simple ?

La réponse dépend du type de chemin à contrôler. Un processus très prévisible peut rester dans du code applicatif. Un processus avec des statuts explicites peut utiliser une machine à états. Un processus avec approbations, délais et audit peut justifier un moteur de workflow. Une boucle agentique n’est utile que lorsque le chemin doit réellement s’adapter à des observations imprévues.

Le message important est :

Un processus multi-étapes n’est pas automatiquement un agent.

Code applicatif

Adapté lorsque :

• la séquence est courte ;
• la logique est stable ;
• les étapes sont fortement intégrées ;
• les besoins de reprise et de visualisation restent simples.

Machine à états

Adaptée lorsque :

• les états et transitions sont explicites ;
• le traitement doit être repris ;
• les branches sont limitées mais importantes ;
• l’état métier doit être visible.

Moteur de workflow ou BPMN

Un moteur de workflow convient lorsque le processus est structuré et connu d’avance : plusieurs acteurs, des approbations, des timers, des événements, des tâches humaines, des compensations, et un fort besoin d’audit et de visualisation.

Autonomie agentique

Elle devient pertinente lorsque :

• le chemin exact ne peut pas être entièrement prédéfini ;
• le système doit observer un résultat et choisir une nouvelle action ;
• plusieurs stratégies acceptables existent ;
• l’exploration apporte une valeur réelle ;
• des budgets et règles d’arrêt encadrent cette autonomie.

Ce chapitre ne développe pas encore cette boucle. Elle sera définie au chapitre suivant.

Combiner les mécanismes

Une architecture réaliste peut utiliser :

workflow déterministe
→ impose les étapes critiques

LLM
→ interprète les demandes et documents

sous-processus agentique
→ traite une recherche ouverte et bornée

humain
→ approuve les décisions sensibles

Le choix n’est donc pas nécessairement exclusif.

Préserver les processus métier

Un processus réglementé peut imposer :

ordre précis
séparation des rôles
approbations
seuils
délais
preuves
journalisation

Le LLM peut intervenir dans des tâches ciblées :

• comprendre une demande ;
• extraire des données ;
• classifier un dossier ;
• résumer des preuves ;
• rédiger une explication.

Le workflow conserve la maîtrise des étapes obligatoires et des décisions critiques.

Observer l’exécution

Une orchestration doit produire une trace exploitable.

Il faut notamment journaliser :

caseId
étape
état avant et après
entrée validée
sortie
modèle et version
outil et version
règle appliquée
décision humaine
durée
coût
erreur et retry
résultat final

Une timeline peut montrer :

09:00 demande reçue
09:00 membre identifié
09:01 trajet sélectionné
09:01 procédure récupérée
09:02 confirmation demandée
09:04 confirmation reçue
09:04 trajet clôturé
09:05 frais recalculés
09:05 approbation requise
11:12 régularisation approuvée
11:13 notification envoyée

L’observabilité permet de répondre à des questions précises :

• quelle étape a échoué ?
• quelle donnée a déclenché une branche ?
• quel outil a produit le résultat ?
• pourquoi une approbation a-t-elle été demandée ?
• le modèle a-t-il proposé une action ensuite refusée ?
• le processus a-t-il repris après un événement ?

Scénario complet — Clôturer le trajet et vérifier les frais

START
 ↓
Identifier Stéphane
 ↓
Retrouver les trajets récents
 ↓
Un seul trajet correspond ?
 ├── non → demander une clarification → WAIT
 └── oui
 ↓
Lire le statut actuel du trajet
 ↓
Trajet déjà clôturé ?
 ├── oui → vérifier uniquement les frais
 └── non
 ↓
Récupérer la procédure applicable par RAG
 ↓
Vérifier l’événement de restitution et l’état du vélo
 ↓
Preuves suffisantes ?
 ├── non → créer une tâche pour Marie → WAIT
 └── oui
 ↓
Demander confirmation à Stéphane
 ↓
Confirmation reçue ?
 ├── non → STOP
 └── oui
 ↓
Clôturer le trajet avec une clé d’idempotence
 ↓
Vérifier le résultat dans le système de flotte
 ↓
Calculer les frais corrigés
 ↓
Régularisation nécessaire ?
 ├── non → notifier Stéphane
 └── oui
       ↓
   Montant sous le seuil automatique ?
   ├── non → approbation humaine → WAIT
   └── oui
       ↓
   Exécuter la régularisation
 ↓
Notifier Stéphane
 ↓
END

Certaines étapes interprètent du langage ou des documents. Les conditions, autorisations, transactions et preuves restent contrôlées par des composants déterministes.

Éviter les anti-patterns

Les erreurs d’orchestration ne viennent pas seulement d’un mauvais choix de technologie. Elles apparaissent surtout lorsqu’un composant reçoit une responsabilité qu’il ne peut pas garantir. Dans un prototype, ces défauts peuvent rester discrets : le scénario est court, l’état tient encore dans la conversation et une personne peut corriger manuellement un écart. Dans un processus réel, la même faiblesse peut provoquer une étape sautée, une action exécutée deux fois ou un dossier qu’il devient impossible de reprendre proprement.

Les anti-patterns suivants correspondent donc à des pertes de contrôle très concrètes. Pour chacun, il faut regarder non seulement ce qui semble plus simple à construire, mais aussi ce qui se passe lorsqu’une réponse varie, qu’un appel échoue, que le traitement reprend plus tard ou qu’une exception métier apparaît.

Utiliser le LLM comme moteur de workflow unique

Un LLM peut interpréter une situation et proposer la prochaine action, mais il ne doit pas devenir à lui seul la séquence, la règle métier et l’état du processus. Une sortie probabiliste n’offre pas les mêmes garanties qu’une transition explicitement contrôlée.

Cela expose notamment le processus à quatre problèmes :

• une étape critique peut être oubliée — le modèle peut passer directement d’une observation à une action qui paraît logique sans exécuter un contrôle intermédiaire obligatoire ;
• le même dossier peut suivre des chemins différents — deux exécutions proches peuvent produire des décisions différentes, ce qui devient problématique lorsqu’une règle métier doit rester stable ;
• la reprise devient fragile — après une interruption, il n’existe pas forcément de point de reprise fiable indiquant quelles étapes ont réellement été validées ou exécutées ;
• l’audit devient difficile — si le déroulement dépend principalement des réponses successives du modèle, il devient plus compliqué d’expliquer quelle règle a autorisé une action et pourquoi une transition précise a été choisie.

Tout coder dans un workflow rigide

L’erreur inverse consiste à vouloir représenter toute la compréhension du problème sous forme de branches déterministes. Cela fonctionne bien pour les règles stables, mais beaucoup moins bien dès que l’entrée est du langage naturel ou qu’une situation peut être formulée de nombreuses manières.

Le risque se déplace alors vers la complexité du workflow :

• le langage naturel est mal absorbé — une demande qui exprime la bonne intention avec une formulation imprévue peut ne correspondre à aucune branche prévue ;
• les branches se multiplient — chaque variante, exception ou combinaison de cas ajoute de nouvelles conditions et rend le processus de plus en plus difficile à lire ;
• les cas ambigus sont mal traités — une règle rigide doit trancher alors que la bonne réponse serait parfois de reformuler, demander une précision ou interpréter le contexte.

Le bon compromis consiste donc à laisser au LLM les décisions souples tout en conservant les transitions obligatoires et les règles critiques dans le workflow.

Conserver l’état uniquement dans le prompt

Le prompt est un contexte de travail pour un appel de modèle, pas un registre fiable de ce qui s’est réellement passé. Si l’état du dossier n’existe que dans la conversation envoyée au LLM, le système confond ce que le modèle lit avec ce que l’application sait officiellement.

Cette confusion a plusieurs conséquences :

• l’état peut être perdu ou déformé — un résumé, une reconstruction du contexte ou l’omission d’un ancien échange peut faire disparaître une information nécessaire ;
• le contexte grossit au fil du traitement — conserver tout l’historique pour ne rien perdre augmente progressivement la quantité d’informations à transmettre et à traiter ;
• la reprise ne peut pas être garantie — après un arrêt, l’application ne dispose pas nécessairement d’un état structuré indiquant précisément ce qui est terminé, en attente ou encore exécutable ;
• le dialogue peut être confondu avec la vérité opérationnelle — le fait qu’une ancienne réponse indique « trajet clôturé » ne prouve pas que la transaction correspondante a réellement réussi dans le système métier.

L’état persistant doit donc conserver les faits et transitions validés ; le prompt n’en reçoit que la vue utile à la décision courante.

Réessayer sans vérifier les effets

Un retry n’est pas une simple répétition technique. Si le premier appel a effectivement modifié le système mais que sa réponse s’est perdue ou qu’un timeout est survenu, relancer aveuglément la même action peut l’exécuter une seconde fois.

Dans le processus Bikaroo, cela peut produire :

• des actions exécutées deux fois — une opération déjà réussie est rejouée parce que l’orchestrateur n’a pas vérifié son effet ;
• un double remboursement ou une double régularisation — une transaction financière répétée produit un effet métier réel, pas seulement un doublon technique ;
• des états incohérents — l’orchestrateur peut croire qu’une étape a échoué alors qu’un système métier l’a déjà enregistrée, puis continuer le processus depuis une hypothèse fausse.

Avant de réessayer une action ayant des effets, l’orchestrateur doit donc vérifier l’état réel et s’appuyer, lorsque c’est possible, sur des opérations idempotentes.

Ne définir aucune condition d’arrêt

Une boucle d’orchestration doit savoir non seulement comment continuer, mais aussi quand elle n’a plus le droit ou plus d’intérêt à continuer. Sans état terminal, budget ou limite de retry, chaque nouvelle observation peut simplement déclencher un appel supplémentaire.

Le processus risque alors de :

• tourner en boucle — le modèle et les outils peuvent revenir plusieurs fois sur les mêmes décisions sans progresser ;
• accumuler des coûts et de la latence — chaque itération consomme de nouveaux appels de modèles ou de services sans garantir une meilleure issue ;
• répéter inutilement des appels — une même recherche, vérification ou tentative peut être rejouée faute de limite explicite ;
• laisser des dossiers sans conclusion claire — le traitement continue ou reste suspendu sans atteindre un état comme DONE, WAITING_FOR_USER, ESCALATED ou FAILED.

Les conditions d’arrêt font donc partie du processus dès sa conception ; elles ne sont pas une protection ajoutée après coup.

Appeler “agent” tout processus multi-étapes

Enfin, le nombre d’étapes ne dit rien sur le degré d’autonomie du système. Un processus peut être long, appeler plusieurs tools et utiliser un LLM tout en suivant un chemin largement défini par le workflow. Employer trop tôt le mot agent brouille alors la distinction que nous cherchons justement à construire entre orchestration contrôlée et autonomie agentique.

ERREUR

Un workflow qui suit des transitions prédéfinies reste un workflow, même s’il appelle un LLM.

En résumé

Objectif utilisateur
        ↓
Orchestrateur
        ↓
État de processus persistant
        ↓
┌─────────────┬─────────────┬─────────────┬─────────────┐
│ LLM         │ RAG         │ Outils      │ Workflow    │
│ interprète  │ documente   │ agissent    │ contrôle    │
└─────────────┴─────────────┴─────────────┴─────────────┘
        ↓
Humains, sécurité, observabilité et audit

Le message essentiel est :

L’orchestration transforme des capacités isolées en un processus contrôlé. Elle attribue au LLM les décisions souples et conserve les règles critiques, l’état et les transactions dans des composants déterministes.

Vérifiez votre compréhension

Question 1 — Quel est le rôle de l’orchestrateur ?

Réponse : Il coordonne la progression, construit le contexte utile, applique les règles, gère l’état et décide quand poursuivre, attendre, compenser, escalader ou arrêter.

Question 2 — Pourquoi un processus multi-étapes n’est-il pas automatiquement un agent ?

Réponse : Un workflow peut suivre des étapes et branches conçues à l’avance. L’agent ajoute un choix adaptatif répété de la prochaine action en fonction des observations.

Question 3 — Quelle différence existe entre état conversationnel et état de processus ?

Réponse : Le premier conserve ce qui a été dit ; le second enregistre les identifiants vérifiés, étapes, décisions, autorisations et résultats transactionnels.

Question 4 — Pourquoi une règle critique ne doit-elle pas être confiée uniquement au LLM ?

Réponse : Parce qu’elle doit produire un résultat reproductible, testable et auditable pour les mêmes données. Elle doit être codée ou configurée de manière déterministe.

Question 5 — Quand un retry automatique est-il acceptable ?

Réponse : Lorsqu’une erreur semble temporaire, que l’opération est idempotente ou vérifiable et qu’un budget de retries est défini.

Question 6 — Pourquoi un timeout crée-t-il parfois un état incertain ?

Réponse : L’opération distante peut avoir abouti sans que l’accusé de réception soit revenu. Il faut réconcilier l’état avant toute nouvelle tentative.

Question 7 — À quoi sert une compensation ?

Réponse : Elle réduit ou neutralise l’effet d’étapes déjà exécutées lorsqu’une transaction globale distribuée n’est pas possible.

Question 8 — Comment un workflow reprend-il après une approbation humaine ?

Réponse : Il persiste son état, crée une tâche corrélée, attend une décision puis reprend à partir de l’étape et de la version d’état appropriées.

Question 9 — Quand un moteur BPMN apporte-t-il une valeur supérieure à du code simple ?

Réponse : Pour les processus longs, visibles par le métier, avec timers, responsabilités humaines, approbations, exceptions, audit et compensation.

Question 10 — Quelles informations faut-il tracer pour auditer un processus ?

Réponse : L’identifiant du dossier, les étapes, entrées, sorties, règles, modèles, outils, décisions, validations humaines, durées, coûts, erreurs et état final.

Transition vers le chapitre suivant

L’orchestration décrite dans ce chapitre impose un déroulement contrôlé : étapes, règles, état, validations, reprises et conditions d’arrêt. Elle permet à Bikaroo de traiter une demande complexe sans laisser le LLM improviser le processus.

Dans certains cas, le chemin ne peut toutefois pas être décrit entièrement à l’avance. Le système doit poursuivre un objectif borné, observer ce qu’il obtient, choisir la prochaine action utile, mettre à jour son état, puis recommencer jusqu’à atteindre un résultat ou une condition d’arrêt.

L’orchestration contrôle alors l’exécution. L’agentivité apparaît lorsque le système peut adapter plusieurs fois son chemin à partir de nouvelles observations, dans les limites d’un mandat explicite.

Cette boucle contrôlée introduit la notion d’agent.

Le prochain chapitre sera :

Chapitre 9 — Peux-tu préparer le dossier complet ?

Qu’est-ce qu’un agent IA ?