Agents IA en production : la boucle, les outils et les garde-fous

On parle d'« IA agentique » dès qu'un modèle ne se contente plus de répondre, mais choisit une action : chercher dans une base, appeler une API, écrire un fichier, puis regarder le résultat et décider de la suite. Sur une démo, c'est magique. En production, c'est un programme dont une partie du flux de contrôle est écrite par un modèle probabiliste. Il faut donc le traiter comme tel.

Commencer par se demander s'il faut un agent

Beaucoup de besoins « agentiques » sont en réalité des workflows : une suite d'étapes connues à l'avance, où le modèle intervient pour classer, extraire ou rédiger. Un workflow est plus rapide, moins cher, testable et prévisible. L'agent se justifie quand le chemin dépend vraiment de ce qu'on découvre en route : diagnostiquer un incident, explorer un dépôt de code, répondre à une question qui demande plusieurs recherches enchaînées.

La boucle, sans magie

Sous le capot, tout agent est la même boucle : on envoie au modèle la conversation et la liste des outils, il répond soit par un texte final, soit par une demande d'appel d'outil ; on exécute l'outil, on lui renvoie le résultat, et on recommence. Tout l'enjeu est dans ce que l'on met autour de cette boucle.

export async function runAgent(task: string, tools: Tool[], opts = { maxSteps: 12, maxCostUsd: 0.5 }) {
  const messages: Message[] = [{ role: "user", content: task }];
  let cost = 0;

  for (let step = 0; step < opts.maxSteps; step++) {
    const reply = await model.complete({ messages, tools: tools.map((t) => t.schema) });
    cost += reply.usage.costUsd;
    trace.step({ step, reply }); // every decision is logged and replayable

    if (reply.type === "final") return reply.text;
    if (cost > opts.maxCostUsd) throw new BudgetExceeded(cost);

    const tool = tools.find((t) => t.name === reply.call.name);
    const args = tool?.input.safeParse(reply.call.args); // validate, never trust
    if (!tool || !args?.success) {
      messages.push(toolError(reply.call, "Unknown tool or invalid arguments"));
      continue;
    }
    if (tool.irreversible) await requireHumanApproval(tool.name, args.data);

    messages.push(toolResult(reply.call, await tool.run(args.data)));
  }
  throw new StepLimitReached(opts.maxSteps);
}

Des outils étroits, typés et idempotents

La qualité d'un agent dépend d'abord de ses outils. Un outil « exécuter du SQL » donne au modèle tous les pouvoirs et toutes les occasions de se tromper. Un outil « chercher les commandes d'un client par numéro » fait une seule chose, avec des paramètres validés et un résultat compact. Le modèle choisit mieux quand le menu est court et que chaque plat est clairement décrit.

• Un schéma strict pour chaque outil, vérifié côté serveur : le modèle propose, le code dispose.
• Des résultats courts et structurés : renvoyer 5 lignes utiles plutôt que 5 000 qui noient le contexte.
• Des outils idempotents : si l'agent rejoue un appel, rien ne doit être fait deux fois.
• Des erreurs lisibles renvoyées au modèle, pour qu'il corrige au lieu de tourner en rond.

Les garde-fous qui ne sont pas négociables

Un agent sans limites finit toujours par trouver la boucle infinie ou la facture surprise. Je pose systématiquement un nombre maximal d'étapes, un budget en coût et en temps, et une validation humaine pour toute action irréversible : envoyer un e-mail, payer, supprimer, publier. Les permissions de l'agent sont celles de l'utilisateur qui l'a lancé, jamais plus.

Mesurer avant de croire

Un agent qui marche sur trois exemples n'a rien prouvé. Je constitue un jeu d'évaluation d'une cinquantaine de tâches réelles, avec le résultat attendu, et je le rejoue à chaque changement de prompt, d'outil ou de modèle. Je suis le taux de réussite, le nombre moyen d'étapes et le coût par tâche. Les traces de chaque exécution servent à comprendre les échecs : dans la grande majorité des cas, le problème vient d'un outil mal décrit, pas du modèle.

En résumé

• Workflow d'abord, agent quand le chemin est vraiment imprévisible.
• Peu d'outils, étroits, typés, idempotents.
• Limites d'étapes et de budget, validation humaine pour l'irréversible.
• Traces complètes et jeu d'évaluation rejoué à chaque changement.