Dans cet article
01

Une demande de support, deux types de travail

Prenons un message fictif : « Mon colis est arrivé abîmé, pouvez-vous m’aider ? » L’application peut authentifier le client, retrouver ses commandes et appliquer les règles de retour de manière déterministe. Interpréter une description ambiguë ou trouver le passage pertinent dans plusieurs documents peut bénéficier d’un modèle. Émettre un remboursement reste une action distincte avec autorisation et règles propres.

Une conception peut combiner les approches : du code pour la séquence stable, un modèle pour une interprétation limitée. Introduisez un agent seulement si la prochaine action dépend réellement de ce qui vient d’être appris : demander une photo, consulter le suivi ou une politique produit. Si chaque demande suit les trois mêmes appels, un workflow fixe est généralement plus facile à expliquer et tester.

Repère visuel / 01

Adapter l’autonomie au travail

La distinction utile : qui choisit la prochaine étape ?

  1. Workflow déterministe

    États connus et règles explicites. L’application définit la séquence.

  2. Étape assistée par modèle

    Interpréter une entrée variable dans une séquence maîtrisée.

  3. Agent

    Choisir les outils et planifier dans un périmètre autorisé.

02

Classifier le travail avant de choisir un agent

Les workflows déterministes conviennent aux états connus, règles stables et effets qui doivent être répétables. Les modèles aident pour langage ambigu, classification, extraction ou génération d’options lorsque les règles deviennent fragiles.

Un agent ajoute planification et choix d’outils. Cela n’est utile que si la tâche ne peut être bornée comme une séquence plus simple et si la surface d’échec supplémentaire peut être observée et contrôlée.

03

Construire une échelle d’autonomie

Commencez par une assistance qui propose tandis qu’une personne décide. Autorisez ensuite des actions contraintes avec outils allow-listés, arguments validés, budgets et approbation pour les étapes à forte conséquence. L’exécution autonome complète doit être la dernière promotion, pas le défaut du prototype.

Chaque niveau exige des critères de promotion fondés sur qualité d’évaluation, taux d’exception, réversibilité et capacité d’exploitation. Une conversation fluide ne prouve pas qu’un workflow peut porter des conséquences métier.

Repère visuel / 02

Une échelle d’autonomie

Passer au niveau suivant lorsque l’évaluation et la reprise le permettent.

  1. Proposer

    L’assistant prépare. Une personne décide.

  2. Agir sous contraintes

    Outils autorisés, entrées validées et approbation si nécessaire.

  3. Déléguer une tâche bornée

    Observer l’exécution et conserver une possibilité d’arrêt explicite.

04

Contrôler outils, état et fallback

Traitez sortie du modèle et arguments d’outils comme des entrées non fiables. Appliquez l’autorisation hors du modèle, isolez le contexte tenant, bornez boucles et dépense, et tracez les décisions sans journaliser de contenu personnel inutile.

Définissez le comportement lorsque modèle, outil ou fournisseur est indisponible. Un fallback sûr peut mettre le travail en file humaine, appliquer une règle déterministe ou s’arrêter avant un effet irréversible.

05

Intégrer les conditions d’arrêt à la conception

Donnez au processus un état explicite : reçu, collecte de preuves, précision attendue, prêt à relire, terminé ou transmis. Limitez appels d’outils, durée et tentatives répétées. Lorsque les preuves se contredisent ou qu’un outil échoue constamment, l’étape suivante doit être une transmission prévue plutôt qu’un appel improvisé supplémentaire.

La confiance déclarée par le modèle n’est ni un contrôle d’accès ni un critère de mise en service. Vérifiez dans l’application champs requis, preuve de politique et permissions. Lorsqu’une approbation est nécessaire, liez-la à l’action exacte et revérifiez le dossier avant exécution. Sinon, une personne peut valider un montant et une étape ultérieure en exécuter un autre. Le schéma décrit ce contrôle applicatif ; une consigne seule ne l’impose pas.

Processus / chemin de décision

D’une demande à une action contrôlée

Workflow support proposé. Les contrôles métier sont exécutés par l’application ; l’agent n’approuve pas lui-même son action.

Demande → identité → preuves → action proposée

Preuves complètes et action autorisée ?

  • Oui

    1. Obtenir l’approbation si nécessaire
    2. Revérifier → exécuter une fois → tracer le résultat
  • Non / limite atteinte

    1. Ne pas exécuter l’action proposée
    2. Demander une précision ou transmettre avec les preuves
06

Évaluer le travail abouti, pas une conversation convaincante

Comparez workflow fixe et agent sur les mêmes dossiers. Notez réussite correcte, interventions humaines, outils utilisés et tentatives d’action non autorisée. Distinguez une transmission justifiée d’un échec : demander le numéro de commande manquant peut être le bon résultat.

Inspectez les traces pour repérer boucles inutiles et outils appelés sans information nouvelle. Un modèle plus capable peut améliorer l’interprétation sans changer la meilleure structure du processus. Conservez la conception la plus simple qui couvre le besoin ; élargissez l’autonomie lorsque réussites et échecs sont compris. Un assistant qui prépare régulièrement une décision vérifiable peut apporter davantage qu’un agent cherchant à tout terminer sans supervision.

FAQ / DÉCISIONS

Questions fréquentes

Un agent est-il plus capable qu’un workflow ?+

Il est plus flexible, pas automatiquement plus fiable ou utile. La capacité compte seulement si le cas l’exige et si l’organisation peut gouverner l’incertitude ajoutée.

Découvrir nos services IA, agents et RAG ↗