Qu'est-ce qu'un workflow agentique ? Comment en construire un qui planifie, agit et évalue

Un workflow agentique est un système multi-étapes où un modèle de langage ne se contente pas de répondre une fois : il planifie, choisit des outils, exécute des actions, vérifie le résultat et décide de la suite jusqu’à ce que la tâche soit terminée. En pratique, cela signifie combiner une couche de raisonnement LLM avec l’appel d’outils, un environnement d’exécution réel et une boucle d’évaluation. Si vous construisez des agents de codage, des agents de recherche ou une automatisation interne qui doit s’adapter en cours de tâche, c’est généralement l’architecture que vous construisez réellement.

Qu’est-ce qu’un workflow agentique ?

Un workflow agentique est le modèle derrière les systèmes d’IA qui peuvent progresser dans une tâche au lieu de s’arrêter à la génération de texte. Au lieu de demander une réponse unique à un modèle et de la renvoyer à l’utilisateur, vous laissez le modèle opérer dans une boucle contrôlée :

1. Lire l’objectif et l’état actuel.
2. Planifier l’étape suivante.
3. Appeler un outil ou exécuter du code.
4. Observer le résultat.
5. Évaluer si la tâche est terminée.
6. Répéter si nécessaire.

Cela diffère d’un workflow fixe, où chaque étape est pré-écrite dans le code. Dans un workflow fixe, vous décidez du chemin à l’avance. Dans un workflow agentique, le modèle décide de la prochaine action à entreprendre dans les limites que vous fournissez.

Cette distinction est importante car de nombreuses tâches de développement réelles ne sont pas linéaires. Un agent de codage peut avoir besoin d’inspecter des fichiers avant de savoir quel test exécuter. Un agent de recherche peut avoir besoin de chercher deux fois parce que la première source était incomplète. Un agent de navigation peut avoir besoin de se remettre d’un échec de connexion ou d’une mise en page modifiée. Ce sont des problèmes de workflow, mais ils nécessitent une adaptation.

En quoi un workflow agentique est-il différent d’un agent IA ?

Les gens utilisent souvent les deux termes de manière interchangeable, mais il est plus utile de les séparer :

• Un workflow agentique est le modèle d’exécution.
• Un agent IA est le produit ou le système construit sur ce modèle.

Vous pouvez avoir un workflow agentique très ciblé qui ne fait que trier les tickets de support, ou un agent IA plus large qui coordonne la planification, l’utilisation d’outils, la mémoire et les points de contrôle d’approbation pour de nombreuses tâches.

Si vous voulez une règle pratique, utilisez workflow lorsque vous parlez d’architecture et de flux de contrôle, et utilisez agent lorsque vous parlez du système orienté utilisateur.

Quelles sont les parties essentielles d’un workflow agentique ?

La plupart des systèmes de production finissent par avoir les cinq mêmes parties.

1. Planificateur

Le planificateur transforme une instruction large en la prochaine action concrète. Parfois, c’est une étape de planification explicite qui produit une liste de tâches. Parfois, c’est implicite et se produit à chaque tour d’appel d’outil. Dans les deux cas, le modèle a besoin de suffisamment de contexte pour décider s’il doit lire, écrire, chercher, exécuter ou s’arrêter.

Une bonne planification ne signifie pas générer un long plan pour chaque requête. Cela signifie garder la prochaine action lisible. Pour les tâches courtes, une planification en une étape suffit. Pour les tâches plus longues comme les refontes de dépôt, l’automatisation de navigateur ou la révision de documents, un plan explicite réduit les allers-retours inutiles.

2. Couche d’outils

Les outils sont l’interface du workflow avec le monde. Une couche d’outils solide est généralement étroite et prévisible. Par exemple :

• read_file(path)
• write_file(path, content)
• search_files(query)
• run_command(cmd)
• fetch_url(url)

Les petits outils sont plus faciles à appeler correctement pour le modèle, plus faciles à journaliser et plus faciles à sécuriser. Les grands outils « tout-en-un » semblent pratiques au début mais deviennent difficiles à déboguer car vous ne pouvez pas dire si les échecs proviennent de la décision du modèle, de l’implémentation de l’outil ou du système externe derrière.

3. Environnement d’exécution

Une fois que le modèle décide d’agir, quelque chose doit exécuter l’action. Pour tout workflow qui écrit des fichiers, installe des paquets, exécute du code ou ouvre des sessions de navigateur, cet environnement a besoin d’isolation.

C’est là qu’un sandbox entre en jeu. Novita Agent Sandbox est conçu pour cette couche d’exécution : un environnement séparé où les actions de l’agent peuvent s’exécuter sans toucher directement au système hôte. C’est la différence entre « le modèle a suggéré une commande » et « le workflow a exécuté cette commande en toute sécurité ».

4. État et mémoire

Un workflow agentique a besoin d’une mémoire de travail entre les étapes. Cela inclut généralement :

• l’état de la conversation
• les sorties des outils
• les fichiers intermédiaires
• les journaux d’exécution
• un bloc-notes ou un plan court

Sans état, chaque étape devient une ingénierie de prompt sans état, et le système s’effondre dès que la tâche s’étend sur plus d’une action.

5. Boucle d’évaluation

C’est la partie que de nombreuses équipes ajoutent trop tard. Le workflow a besoin d’un moyen de juger si une étape a réussi et si la tâche est terminée. Dans un workflow de codage, cela peut signifier que les tests passent. Dans un workflow de recherche, cela peut signifier que la réponse cite suffisamment de sources fiables. Dans un workflow de navigateur, cela peut signifier que l’état d’interface utilisateur attendu est visible.

Sans évaluation, « agentique » se transforme souvent en « continue d’appeler des outils jusqu’à expiration du délai ».

Pourquoi la planification est importante dans la construction de workflows agentiques

La plus grande erreur dans la construction de workflows agentiques est de supposer que le modèle doit improviser tout à partir de zéro à chaque tour.

Cela crée généralement trois problèmes :

• le modèle revisite les mêmes fichiers ou URLs à plusieurs reprises
• l’utilisation des outils devient bruyante et coûteuse
• le workflow perd une condition d’arrêt claire

Un meilleur modèle est une planification légère combinée à une exécution ancrée. Laissez le modèle décider de la prochaine action, mais faites-le en fonction d’une tâche explicite, d’un état actuel visible et d’un petit ensemble d’outils autorisés. Cela maintient la flexibilité là où elle est utile et la supprime là où elle ne l’est pas.

Dans les workflows de codage, la planification ressemble souvent à ceci :

1. Identifier les fichiers concernés.
2. Lire l’implémentation actuelle.
3. Décider du changement minimal.
4. Effectuer la modification.
5. Exécuter la vérification.
6. Soit s’arrêter, soit réparer.

C’est toujours agentique, car le modèle peut bifurquer lorsque le dépôt le surprend. Mais cela ne vagabonde pas.

Comment l’utilisation des outils devrait-elle fonctionner dans un workflow agentique ?

L’utilisation des outils doit être explicite, typée et observable.

Si votre modèle prend en charge l’appel de fonction, utilisez-le. L’API LLM de Novita expose un point de terminaison compatible OpenAI et documente directement l’appel de fonction, ce qui est le moyen le plus propre de laisser le modèle choisir parmi les outils sans dépendre d’un analyse syntaxique fragile.

Quelques règles rendent l’utilisation des outils beaucoup plus fiable :

• Gardez les noms d’outils concrets.
• Utilisez des schémas avec des champs obligatoires.
• Renvoyez des résultats complets, y compris les erreurs.
• Journalisez chaque appel, argument et sortie.
• Rendez les actions destructrices rares et faciles à verrouiller.

La couche d’outils doit également refléter les limites réelles. Par exemple, ne donnez pas à un agent de codage un méga-outil appelé edit_repo_and_run_tests. Séparez les étapes de lecture, d’écriture et d’exécution afin que le modèle puisse récupérer lorsque quelque chose échoue.

Pourquoi l’exécution de code a-t-elle besoin d’un sandbox ?

Un workflow agentique qui n’exécute jamais rien peut souvent rester à l’intérieur d’un serveur d’application ordinaire. Dès qu’il commence à exécuter des commandes shell, installer des dépendances, gérer des fichiers téléchargés ou naviguer sur le web ouvert, vous avez besoin d’isolation.

Le sandboxing résout deux problèmes différents :

• Sécurité : le code généré et les sorties des outils peuvent être erronés, hostiles ou simplement imprévisibles.
• État : les tâches multi-étapes ont besoin d’un espace de travail persistant où les fichiers, les paquets et l’historique d’exécution survivent entre les tours.

Pour de nombreuses équipes, le deuxième point est tout aussi important que le premier. Un workflow qui édite du code, exécute des tests, corrige l’échec et relance la vérification n’est pas possible si chaque étape démarre à partir d’une machine propre.

C’est pourquoi l’architecture pratique est généralement :

• API LLM pour la planification et la sélection d’outils
• Environnement sandbox pour l’exécution et la persistance

Novita s’intègre naturellement à cette séparation : l’API LLM agit comme la couche de planification et d’appel d’outils, tandis que Agent Sandbox gère l’environnement d’exécution réel.

Comment évaluer un workflow agentique ?

L’évaluation doit se faire à deux niveaux.

Évaluation au niveau de l’étape

La dernière action a-t-elle fonctionné ?

Exemples :

• La commande s’est-elle terminée avec succès ?
• L’API a-t-elle renvoyé du JSON valide ?
• Le fichier attendu a-t-il été créé ?
• La page du navigateur contenait-elle l’élément cible ?

Évaluation au niveau de la tâche

Le workflow a-t-il résolu le problème de l’utilisateur ?

Exemples :

• Les tests passent-ils après le changement de code ?
• Le résumé répond-il à la question de recherche avec des preuves ?
• L’automatisation a-t-elle terminé la transaction sans nettoyage manuel ?

Les workflows solides utilisent les deux. Si vous n’évaluez que la sortie finale, vous manquez des signaux d’échec évidents pendant l’exécution. Si vous n’évaluez que les étapes, le workflow peut accomplir une longue série d’actions localement valides et échouer quand même à la tâche réelle.

Une architecture pratique pour construire des workflows agentiques

Voici l’architecture par laquelle la plupart des équipes devraient commencer :

1. Une requête utilisateur entre dans votre application.
2. Votre contrôleur envoie l’objectif, l’état et les outils disponibles à un LLM.
3. Le LLM renvoie soit une réponse directe, soit un appel d’outil.
4. Votre contrôleur exécute l’outil dans un sandbox ou un autre environnement contrôlé.
5. Le résultat de l’outil est ajouté à l’état de la conversation.
6. Un évaluateur vérifie l’achèvement, l’échec ou les points d’approbation.
7. La boucle continue jusqu’à ce que le workflow soit terminé ou bloqué.

Cette boucle de contrôleur peut être simple. Dans de nombreux cas, un seul processus d’orchestration suffit. Vous n’avez pas besoin d’un système multi-agents dès le premier jour. Commencez avec un planificateur, quelques outils bien définis, un environnement sandbox et un évaluateur clair.

Exemple : un contrôleur de workflow agentique en Python

L’exemple ci-dessous montre la forme de la boucle de contrôle. Il utilise l’API compatible OpenAI de Novita pour l’appel d’outils. Les fonctions d’exécution sont à vous d’implémenter par rapport à votre propre environnement ou sandbox.

import json
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.novita.ai/openai",
    api_key=os.environ["NOVITA_API_KEY"],
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "Read a file from the workspace",
            "parameters": {
                "type": "object",
                "properties": {"path": {"type": "string"}},
                "required": ["path"],
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "run_command",
            "description": "Run a shell command in the sandbox",
            "parameters": {
                "type": "object",
                "properties": {"cmd": {"type": "string"}},
                "required": ["cmd"],
            },
        },
    },
]


def read_file(path: str) -> str:
    # Implement this against your own workspace or sandbox filesystem.
    raise NotImplementedError


def run_command(cmd: str) -> str:
    # Implement this against your sandbox runtime.
    raise NotImplementedError


dispatch = {
    "read_file": read_file,
    "run_command": run_command,
}


def run_workflow(task: str, model: str) -> str:
    messages = [
        {
            "role": "system",
            "content": (
                "You are a workflow controller. Use tools when needed, "
                "check results after each action, and stop when the task is complete."
            ),
        },
        {"role": "user", "content": task},
    ]

    while True:
        response = client.chat.completions.create(
            model=model,
            messages=messages,
            tools=tools,
            tool_choice="auto",
        )

        message = response.choices[0].message
        messages.append(message)

        if not message.tool_calls:
            return message.content

        for call in message.tool_calls:
            fn = dispatch[call.function.name]
            args = json.loads(call.function.arguments)
            result = fn(**args)
            messages.append(
                {
                    "role": "tool",
                    "tool_call_id": call.id,
                    "content": result,
                }
            )

Ceci est intentionnellement minimal. En production, vous ajouteriez également :

• une politique de réessai pour les erreurs transitoires
• des délais d’attente et des limites de budget
• une approbation humaine pour les actions sensibles
• des journaux d’étapes structurés
• un évaluateur au niveau de la tâche avant l’achèvement final

Quel modèle utiliser comme planificateur ?

Pour un workflow agentique, le modèle planificateur n’a pas seulement besoin d’intelligence brute. Il a besoin de la bonne forme :

• appel d’outil fiable
• comportement stable en contexte long
• forte capacité à suivre les instructions
• latence prévisible en profondeur multi-tours

Si vous voulez un point de départ open-weight sur Novita, Qwen3 Coder 30B A3B Instruct est une option pratique pour la planification de workflow et l’utilisation d’outils orientée codage. La page actuelle des modèles de Novita répertorie un accès compatible OpenAI, la prise en charge de l’appel de fonction, la prise en charge des sorties structurées et une fenêtre de contexte hébergée de 160K. Pour de nombreuses tâches d’automatisation interne et de codage, cela suffit pour construire une première version sérieuse avant de passer à un planificateur plus grand ou plus spécialisé.

Le bon modèle dépend toujours du travail. Pour les workflows larges et lourds en raisonnement, choisissez d’abord la qualité de planification. Pour l’automatisation à volume élevé, la latence et le coût peuvent être aussi importants que la force des benchmarks.

Modes de défaillance courants dans les workflows agentiques

La plupart des échecs ne sont pas dramatiques. Ils sont répétitifs et coûteux.

Surabondance d’outils

Si chaque capacité devient sa propre dépendance distante, le workflow passe plus de temps à coordonner qu’à faire un travail utile.

Règles d’arrêt faibles

Si le système ne sait jamais quand « terminé » est vrai, il continue de générer une étape de plus.

Mauvaise gestion des erreurs

Si les outils renvoient des messages vagues comme « échec » au lieu d’une sortie exploitable, le modèle ne peut pas récupérer.

Absence de limite de sandbox

Le workflow peut fonctionner en développement, puis devenir dangereux dès qu’il touche à des fichiers réels, des identifiants ou des systèmes externes.

Pas d’évaluateur

L’agent semble occupé mais ne prouve jamais que la tâche a été correctement accomplie.

Quand ne pas utiliser un workflow agentique ?

N’en construisez pas simplement parce que le terme est populaire.

Vous n’avez probablement pas besoin d’un workflow agentique si :

• la tâche est une génération unique
• le chemin est fixe et change rarement
• un programme traditionnel peut décider chaque étape à moindre coût
• il n’y a pas besoin d’utilisation d’outils ou d’exécution

Par exemple, si votre application prend toujours une entrée de formulaire, appelle un prompt et renvoie un email formaté, un workflow LLM ordinaire est plus simple et meilleur.

Les workflows agentiques sont rentables lorsque l’environnement peut surprendre le système et que le système doit encore continuer.

FAQ

Un workflow agentique est-il la même chose que l’appel de fonction ?

Non. L’appel de fonction est un mécanisme à l’intérieur du workflow. Le workflow complet a également besoin de flux de contrôle, d’état, d’exécution et d’évaluation.

Ai-je besoin de plusieurs agents pour construire des workflows agentiques ?

Non. La plupart des équipes devraient commencer avec une seule boucle de contrôleur et quelques outils. Les conceptions multi-agents sont utiles plus tard, mais elles ne sont pas le point de départ par défaut.

Quel est le contrôle de sécurité le plus important ?

Pour les workflows qui exécutent du code ou touchent à des systèmes externes, le contrôle le plus important est un environnement d’exécution isolé combiné à des permissions d’outils étroites.

Quelle est la pile prête pour la production la plus simple ?

Une bonne première pile est : une API LLM compatible OpenAI, un petit registre d’outils, un environnement sandbox et un évaluateur capable de décider quand la tâche est réellement terminée.

Articles recommandés

• Que sont les agents de codage ? Comment ils fonctionnent et comment en construire un
• Qu’est-ce qu’un sandbox pour agent IA ?
• Agent vs Workflow : différences clés et compromis pratiques