Conception de Workflows Agentiques : de l'Automatisation Démo à la Fiabilité en Production

Points clés

• Une démo ne devient un vrai workflow que lorsqu'elle peut survivre à de mauvaises entrées, à des pannes partielles et à des limites de policy sans improviser vers le risque.
• Le vrai problème de conception n'est pas l'intelligence du modèle. C'est la manière dont vous structurez l'état, le contexte, le périmètre des outils, les validations et la reprise avant l'exécution.
• La revue humaine n'est pas un pansement pour systèmes faibles. C'est souvent le contrôle qui permet de livrer une automatisation utile beaucoup plus tôt.
• Les workflows agentiques fiables séparent la planification, l'autorisation et l'exécution, afin qu'un même step ne puisse pas à la fois "décider" et "agir".
• puppyone aide lorsque la fiabilité du workflow dépend de paquets de contexte gouvernés, plutôt que d'une reconstruction de preuves dispersées à chaque run.

Le problème caché de l'opérateur dans la plupart des démos d'agents

Beaucoup de démos d'agents paraissent meilleures qu'elles ne le sont réellement, parce qu'un opérateur humain prend discrètement en charge une partie du travail :

• nettoyer l'entrée avant que l'agent ne la voie
• repérer qu'un contexte est obsolète
• choisir quel outil est sans danger
• décider si le résultat est suffisant
• arrêter l'exécution avant qu'elle ne provoque des dégâts

C'est pour cela que la première mise en production semble souvent déroutante. Rien ne s'est "mystérieusement cassé". Le workflow a simplement perdu la couche humaine invisible qui le faisait paraître plus fiable qu'il ne l'était.

C'est aussi pour cela qu'un bon design de workflow agentique commence par une question directe :

Que se passe-t-il lorsque l'opérateur est occupé et que l'entrée est désordonnée ?

Si la réponse est : "le prompt va gérer ça", vous avez encore une démo.

L'article d'Anthropic sur effective context engineering for AI agents est utile ici parce qu'il déplace l'attention de la formulation du prompt vers l'état complet du contexte qui façonne le comportement. Les workflows de production échouent exactement à cet endroit : non pas parce que le modèle "oublie" une phrase, mais parce que le workflow lui a donné le mauvais état, les mauvais outils ou aucune frontière claire.

La grille de production : six surfaces de contrôle à concevoir délibérément

Avant d'ajouter davantage d'outils ou de personas d'agents, mettez sous tension ces six surfaces de contrôle :

Ce tableau est volontairement peu spectaculaire. Les workflows fiables se construisent avec une clarté peu spectaculaire.

Le AI Risk Management Framework du NIST est utile comme grille de gouvernance, car il ramène sans cesse vers la traçabilité, les contrôles et la gestion du cycle de vie. Cela s'applique directement aux workflows d'agents : vous devriez pouvoir expliquer quelles preuves ont été utilisées, quels outils étaient exposés, quel contrôle a été appliqué et pourquoi le système a continué ou s'est arrêté.

La séparation la plus importante : séparer la planification de l'action

L'une des façons les plus rapides de rendre un workflow d'agents dangereux consiste à laisser le même step décider et exécuter.

Par exemple :

• "Lis le ticket et envoie la réponse finale au client"
• "Vérifie la transaction et approuve le remboursement"
• "Résume le problème et modifie la configuration de production"

Cela semble efficace. En réalité, cela fusionne jugement et action dans un seul bloc en forme de prompt.

Un schéma plus robuste en production est :

1. collecter les preuves
2. proposer un plan
3. vérifier la policy ou demander une approbation
4. exécuter une action étroite
5. écrire une trace d'audit

Cela paraît plus lent, mais c'est généralement plus rapide à déboguer, plus sûr à déployer et plus facile à faire évoluer. Le workflow devient inspectable parce que chaque step a un rôle distinct.

Si votre workflow ne peut pas produire un artefact révisable entre "penser" et "agir", c'est un signal de mauvais design. Cet artefact peut être petit :

• un résumé de plan
• un diff structuré
• une étiquette de risque
• une action proposée avec score de confiance et IDs de preuves

Le sujet n'est pas la bureaucratie. Le sujet est de rendre visible la couture décisionnelle avant qu'un effet de bord ne se produise.

Concevoir l'état pour la reprise, pas pour l'héroïsme

Les workflows de production devraient être reprenables par défaut. Cela signifie que le système doit savoir ce qui a déjà été fait, ce qu'il attend, et ce qui peut être rejoué sans danger.

Un état illustratif peut ressembler à ceci :

{
  "run_id": "wf_2026_04_02_1842",
  "status": "awaiting_approval",
  "current_step": "execute_change",
  "evidence_bundle_id": "ctx_8842",
  "proposal": {
    "action": "update_policy_exception",
    "reason": "ticket matches approved template",
    "confidence": 0.78
  },
  "approval": {
    "required": true,
    "requested_from": "ops-reviewers",
    "requested_at": "2026-04-02T14:20:00Z"
  },
  "side_effects": [
    {"step": "collect_context", "status": "complete"},
    {"step": "propose_plan", "status": "complete"}
  ]
}

Il ne s'agit pas d'obtenir un schéma parfait. Il s'agit d'expliciter.

Dès qu'un workflow porte un état de ce type, plusieurs choses positives apparaissent :

• les retries peuvent viser un seul step au lieu de rejouer l'ensemble du run
• les opérateurs voient immédiatement pourquoi le workflow est en pause
• les humains examinent un objet compact au lieu de reconstruire un historique de chat
• les journaux d'audit peuvent relier les actions aux preuves et à l'état de décision

C'est le passage de "espérons que l'agent s'en souvienne" à "le workflow est reprenable par conception".

Human-in-the-loop fonctionne mieux sur la couture de décision

Les équipes ajoutent souvent l'approbation humaine trop tard et au mauvais endroit. Elles demandent à un reviewer de relire tout ce que l'agent a déjà lu, ce qui transforme l'automatisation en travail manuel déguisé.

Le meilleur schéma consiste à placer l'humain là où le risque métier se concentre :

• avant une écriture destructive
• avant une communication externe
• avant une exception de policy
• avant une action basée sur une preuve faible

Et il faut ensuite lui présenter quelque chose d'assez compact pour permettre une décision rapide :

La revue humaine doit réduire le risque, pas rejouer le workflow original à la main.

Si le reviewer ne peut pas comprendre l'action proposée en moins d'une minute, le problème se situe généralement plus tôt : trop de contexte, un modèle d'état faible ou un contrat d'action peu clair.

Une forme de workflow qui tient mieux en production qu'elle n'en a l'air

Vous n'avez pas besoin d'une énorme plateforme d'orchestration pour déployer quelque chose de fiable. Un workflow petit mais explicite va déjà très loin :

trigger:
  source: inbound_request

steps:
  - collect_context
  - compact_evidence
  - propose_plan
  - check_policy
  - request_approval_if_needed
  - execute_one_narrow_action
  - write_audit_log
  - return_summary

fallbacks:
  on_missing_context: ask_for_more_input
  on_low_confidence: route_to_human
  on_tool_failure: retry_once_then_pause
  on_policy_violation: block_and_log

Ce qui rend cette forme solide, ce n'est pas la sophistication. C'est le fait que chaque step n'a qu'un seul travail et que chaque transition risquée possède un point d'arrêt propre.

Pour une première release, c'est souvent suffisant.

Où puppyone s'insère dans la fiabilité du workflow

Beaucoup de workflows agentiques échouent avant même que le modèle ne commence, parce que chaque run doit réassembler des preuves provenant de trop de systèmes :

• le système de tickets contient une version du problème
• la policy est stockée ailleurs
• la dernière note d'exception se trouve dans le chat
• l'agent reçoit un empilement bruyant de récupérations partielles

Ce problème n'est pas vraiment du "raisonnement d'agent". C'est un problème d'assemblage de contexte.

puppyone est utile lorsque vous voulez qu'un step du workflow consomme un paquet de contexte gouverné plutôt que de reconstruire les preuves à chaque exécution. En pratique, cela aide à :

• garder le contexte cohérent d'un step à l'autre
• exposer des tranches de contexte différentes selon les rôles ou les outils
• accélérer la revue humaine parce que le paquet de preuves est déjà structuré
• relier l'état du run à des IDs de contexte stables pour une revue ultérieure

Cela ne remplace pas la conception du workflow. Cela réduit l'une des plus grandes sources de fragilité : un contexte incohérent au moment d'agir.

Ce qu'il faut supprimer de la version un

Si vous cherchez à rendre un workflow d'agents sûr pour la production, éliminez ces éléments avant le lancement :

• des accès outils trop larges "au cas où"
• des écritures autonomes sans artefact intermédiaire révisable
• une logique de retry qui peut rejouer deux fois le même effet de bord
• des règles d'approbation qui n'existent que dans le prompt
• des paquets de contexte trop volumineux pour être revus rapidement par un humain

La version un doit être petite, lisible et facile à arrêter.

Cela signifie généralement moins d'autonomie que ce que la démo suggérait. Tant mieux. Une autonomie bornée est plus facile à faire confiance, à mesurer et à améliorer.

FAQ

Q1. Ai-je besoin d'un moteur de workflow avant de lancer mon premier workflow agentique ?

Non. Il vous faut un état explicite, une séparation claire entre planification et action, et un chemin de pause propre lorsque la confiance est faible ou qu'une approbation est nécessaire.

Q2. Quelle est l'erreur la plus fréquente en conception de workflows agentiques ?

Chercher à maximiser l'autonomie trop tôt. Cela produit des démos impressionnantes, mais un comportement fragile en production tant que l'état, les frontières d'outils, les approbations et la reprise ne sont pas clairement définis.

Q3. Quand un workflow doit-il escalader vers un humain ?

Quand l'action est destructive, sensible à la policy, peu fiable ou difficile à annuler. La revue humaine fonctionne le mieux sur la couture de décision, pas après que l'effet de bord a déjà eu lieu.