+160 XP

Agents vs workflows vs automations : choisir le bon niveau d'autonomie

# Agents vs workflows vs automations : choisir le bon niveau d'autonomie

Une équipe support a passé trois semaines à construire un « agent IA » pour trier les emails entrants. Il appelait le modèle sur chaque message, le laissait décider quoi faire, et coûtait 400 $ par mois. Quand ils l'ont remplacé par un pipeline fixe (détecter la langue, résumer, classer par mot-clé), il tournait en une fraction du temps, ne coûtait presque rien, et a cessé de faire des erreurs de classement bizarres.

La leçon : la plupart des tâches n'ont pas besoin d'un agent. La compétence, c'est de savoir quand elles en ont besoin.

Le spectre de l'autonomie

Voyez l'automatisation comme un potentiomètre, pas comme un interrupteur. À gauche, vous décidez chaque étape. À droite, l'IA décide. Il y a trois arrêts utiles sur le chemin.

1. Automation (aucune décision par l'IA)

Une séquence fixe d'étapes que vous avez écrites à l'avance. La machine les suit exactement. Aucun modèle ne décide de quoi que ce soit.

Exemple : quand un fichier arrive dans un dossier, le renommer avec la date du jour et le sauvegarder. Des outils comme Zapier, Make ou un simple script font ça. Zéro IA.

2. Workflow (l'IA dans des emplacements fixes)

Vous contrôlez toujours les étapes et leur ordre. Mais à des points précis, vous appelez un modèle d'IA pour faire un travail : résumer, classifier, extraire, réécrire. Le modèle remplit un emplacement. Il ne choisit pas ce qui se passe ensuite.

Exemple : un email arrive → l'IA écrit un résumé d'une ligne → l'IA le classe en « facturation », « ventes » ou « autre » → votre code le range dans le dossier correspondant. Le modèle fait deux tâches. Votre code décide du chemin.

C'est là que l'équipe support aurait dû commencer.

3. Agent (l'IA décide des étapes)

Un agent est un modèle qui décide quoi faire ensuite, en boucle, en utilisant des tools (des fonctions qu'il peut appeler, comme « chercher sur le web » ou « envoyer un email »). Vous lui donnez un objectif, pas un script. Il choisit des actions, voit les résultats, et choisit à nouveau jusqu'à ce que l'objectif soit atteint.

Exemple : « Résoudre cette réclamation client. » L'agent lit le ticket, décide de consulter la commande, découvre qu'un remboursement est nécessaire, appelle le tool de remboursement, puis rédige une réponse. Vous ne lui avez pas indiqué cet ordre d'étapes. Il l'a choisi.

Pourquoi plus d'autonomie coûte plus cher

Chaque arrêt vers la droite ajoute trois coûts.

L'argent. Les agents appellent le modèle de nombreuses fois par tâche (une fois par décision). Un workflow l'appelle un nombre fixe et réduit de fois. En 2026, les appels aux modèles sont moins chers qu'avant, mais un agent qui boucle 15 fois coûte toujours environ 15x un appel unique.

La vitesse. Chaque décision est un aller-retour vers le modèle. Plus de décisions, plus d'attente. Un workflow fixe avec deux appels est rapide de façon prévisible.

La prévisibilité. C'est le point majeur. Dans un workflow, vous connaissez le chemin exact. Dans un agent, le chemin change à chaque exécution. Cette flexibilité est tout l'intérêt, mais elle signifie aussi que l'agent peut boucler indéfiniment, appeler le mauvais tool, ou « résoudre » un problème d'une manière que vous n'aviez jamais prévue.

L'équipe engineering d'Anthropic l'a dit clairement dans son guide largement partagé : construisez la chose la plus simple qui fonctionne, et n'ajoutez de l'autonomie que lorsqu'une approche plus simple ne suffit pas. À lire : Building Effective Agents.

Une règle de décision réellement utilisable

Posez ces questions dans l'ordre. Arrêtez-vous au premier « oui » qui correspond.

1. Les étapes et leur ordre ne changent-ils jamais ? → Utilisez une simple automation. Pas besoin d'IA.

2. Les étapes sont-elles fixes, mais certaines demandent du jugement (résumer, classifier, extraire) ? → Utilisez un workflow avec de l'IA dans ces emplacements.

3. La tâche est-elle différente chaque fois, si bien que les étapes ne peuvent pas être connues à l'avance ? → Là, envisagez un agent.

Un dernier filtre avant de vous engager sur un agent :

> Pouvez-vous écrire les étapes pour 80 % des cas ? Si oui, construisez un workflow et traitez les 20 % restants manuellement. Si vous ne pouvez vraiment pas prévoir les étapes, un agent justifie son coût.

Exemples côte à côte

| Tâche | Meilleur choix | Pourquoi |

|---|---|---|

| Renommer et sauvegarder des fichiers | Automation | Les étapes ne changent jamais, aucun jugement |

| Résumer et classer des emails support | Workflow | Ordre fixe, l'IA se contente de résumer et classifier |

| Transformer des notes de réunion en compte rendu formaté | Workflow | Une étape IA, un template |

| Rechercher une entreprise sur de nombreuses sources et rédiger une note | Agent | Les étapes dépendent de ce qu'il trouve |

| Déboguer un script en échec en essayant des correctifs jusqu'à ce qu'il passe | Agent | Impossible de prévoir quel correctif fonctionne |

| Réserver un voyage avec des contraintes floues | Agent | Nécessite d'explorer des options et de s'adapter |

Remarquez le schéma : les agents brillent quand le chemin est inconnu. Si vous pouvez dessiner l'organigramme, vous n'avez pas besoin d'un agent.

À quoi ressemble vraiment une boucle d'agent

L'idée de base est simple. Un agent est une boucle : le modèle choisit un tool, vous l'exécutez, vous réinjectez le résultat, vous répétez jusqu'à la fin. Voici la forme, indépendamment du fournisseur :

python
# Vendor-neutral agent loop (pseudocode-ish)
tools = {
    "search_orders": search_orders,
    "issue_refund": issue_refund,
    "send_reply": send_reply,
}

messages = [{"role": "user", "content": "Resolve ticket #4821"}]

while True:
    # Le modèle regarde la conversation et décide :
    # soit appeler un tool, soit donner une réponse finale.
    response = model.generate(messages, available_tools=tools.keys())

    if response.tool_call:
        name = response.tool_call.name
        args = response.tool_call.args
        result = tools[name](**args)          # vous exécutez la vraie fonction
        messages.append(response)             # on enregistre ce que le modèle voulait
        messages.append({"role": "tool",      # on réinjecte le résultat
                         "content": result})
    else:
        print(response.text)                  # réponse finale, c'est terminé
        break

Cette boucle while True est exactement la raison pour laquelle les agents sont moins prévisibles. C'est le modèle, pas votre code, qui choisit search_orders ou issue_refund à chaque passage. Cette même forme fonctionne avec l'OpenAI Agents SDK, le Claude Agent SDK et l'ADK de Google. Les blocs d'approfondissement par fournisseur couvrent les spécificités de chacun. Ici, c'est l'idée qui nous intéresse.

Deux garde-fous que vous devriez toujours ajouter à une boucle réelle :

  • Une limite d'étapes (par exemple, arrêter après 10 appels de tools) pour qu'elle ne boucle pas indéfiniment.
  • Des points de validation sur les tools à risque (émettre des remboursements, envoyer des emails, supprimer des données) pour qu'un humain confirme avant l'action.

Vérification des acquis

1. Quelle est la caractéristique déterminante qui distingue un agent d'un workflow ?

2. Dans l'exemple des emails de l'équipe support, pourquoi remplacer l'agent par un pipeline fixe était-il le meilleur choix ?

3. Quel scénario est le meilleur candidat pour un véritable agent plutôt qu'un workflow ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les réponses correctes sur ce qui définit un « agent » tel que décrit dans la leçon.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les réponses correctes sur le spectre de l'autonomie et le choix du bon niveau.

Sélectionnez toutes les réponses correctes.

Erreurs fréquentes

Se jeter d'abord sur un agent. Ça fait moderne et impressionnant. C'est généralement le mauvais point de départ. Commencez à gauche du potentiomètre et n'allez à droite que contraint.

Appeler un workflow un « agent ». Le marketing brouille ces mots. Si vos étapes sont fixes et que le modèle remplit juste des emplacements, c'est un workflow, et c'est bien. On ne vous retire pas de points pour ne pas avoir utilisé un agent.

Donner trop de tools à un agent. Un modèle qui choisit parmi 30 tools fait plus d'erreurs qu'un modèle qui choisit parmi 4. Gardez un toolset réduit et un objectif étroit.

Pas d'interrupteur d'arrêt. Un agent sans limite d'étapes ni plafond budgétaire peut faire grimper les coûts et prendre des actions étranges. Plafonnez-le toujours.

Une décision détaillée

Disons que vous voulez traiter les factures entrantes.

  • Extraire le fournisseur, le montant et la date d'échéance. Prévisible, demande du jugement → étape de workflow (extraction par IA).
  • Signaler les factures de plus de 10 000 $ pour revue. Règle fixe → automation, pas d'IA.
  • Classer dans le bon dossier projet. Si les dossiers correspondent proprement à un champ, automation. S'il faut lire la facture et raisonner sur le projet concerné, une petite étape de classification en workflow.
  • Relancer un fournisseur par email au sujet d'un montant contesté, en plusieurs échanges, jusqu'à résolution. Imprévisible, multi-tours, adaptatif → c'est la seule partie qui pourrait justifier un agent.

L'ensemble est à 90 % du workflow et de l'automation, avec un agent seulement sur la marge désordonnée. C'est une conception saine.

Points clés

  • Commencez simple, n'allez à droite que contraint. Automation → workflow → agent. Chaque pas vers la droite ajoute du coût, de la latence et de l'imprévisibilité.
  • Utilisez le test de l'organigramme. Si vous pouvez dessiner les étapes à l'avance, construisez un workflow, pas un agent. Les agents sont pour les tâches où le chemin est réellement inconnu.
  • Un workflow avec de l'IA dans des emplacements fixes n'est pas un choix inférieur. Pour résumer, classifier et extraire, c'est moins cher, plus rapide et plus fiable qu'un agent.
  • Quand vous construisez un agent, plafonnez-le. Ajoutez une limite d'étapes, une limite de budget, et une validation humaine sur les tools à risque avant qu'il n'agisse.
  • Gardez un toolset réduit. Moins de tools et un objectif étroit, c'est moins de mauvais virages.

Articles liés

Les articles récents du blog qui s'appuient sur cette leçon.