Des workflows agentiques qui ne cassent pas : appel d’outils, humain dans la boucle, et les coutures entre systèmes

L’automatisation des processus métier et un agent IA sont vendus comme la même chose, et ce n’est pas le cas. L’automatisation est un pipeline fixe : l’étape deux suit toujours l’étape un, de la même façon. Un agent est une boucle où le modèle décide quelle étape vient ensuite, selon ce qu’un appel d’outil vient de renvoyer. Les deux ont leur place - ce dont une entreprise a réellement besoin la plupart du temps, c’est de l’automatisation avec un ou deux points de décision agentiques, pas un agent qui prend chaque décision.

L’architecture sous-jacente, dans les deux cas, détermine si ça survit au contact des vraies données : comment on nourrit le modèle en contexte, comment on récupère une réponse dans une forme à laquelle le code peut faire confiance, comment le modèle va chercher dans d’autres systèmes, et où une personne doit encore dire oui. C’est cette plomberie, pas le choix du modèle, qui occupe l’essentiel d’un projet pour moi.

1. Ingénierie de contexte : donner au modèle la bonne tranche, pas tout

L’ingénierie de contexte est le travail peu glamour de décider ce que le modèle voit lors d’un appel donné - quels enregistrements, quels tours précédents, quelles instructions - et, tout aussi important, ce qu’il ne voit pas. Déverser tout l’historique d’un client ou un document entier dans le prompt à chaque fois n’est pas du sérieux ; c’est du bruit qui éloigne la vraie question de l’attention du modèle et gonfle discrètement le coût de chaque appel.

Le schéma qui tient la route ressemble plus à un problème de recherche qu’à un problème de mémoire : récupérer les deux ou trois enregistrements pertinents pour cette étape précise, résumer ce qui précède au lieu de le rejouer mot pour mot, et laisser l’agent demander plus seulement quand il en a besoin. Un workflow qui tire fiablement les cinq bonnes lignes parmi dix mille bat celui qui fourre les dix mille et espère.

2. Les sorties structurées et l’appel d’outils/fonctions sont la vraie interface

Un modèle qui répond en texte libre et qu’on parse avec une regex, c’est là que ces builds échouent silencieusement en production. Les sorties structurées - un schéma JSON dans lequel le modèle est forcé de répondre - et l’appel d’outils/fonctions - le modèle demande une fonction précise avec des arguments typés au lieu de décrire une action en prose - permettent à votre code de faire assez confiance à une réponse pour agir sans qu’un humain relise chaque sortie.

Je valide le schéma à la sortie du modèle, puis encore une fois avant qu’il n’atteigne un vrai système, car un modèle peut produire du JSON syntaxiquement valide qui reste faux pour la règle métier en jeu - une quantité négative, une date dans le passé, une devise que le compte ne supporte pas. Le schéma attrape les erreurs de forme ; une seconde couche de validation, ennuyeuse, attrape celles qui sont du JSON valide et pourtant fausses.

3. Embeddings et base vectorielle - seulement quand la recherche est vraiment le job

Les embeddings et une base vectorielle se justifient quand la tâche est vraiment du retrieval : trouver les trois tickets support les plus proches de ce nouveau, trouver la clause d’un contrat la plus proche de cette question. C’est le mauvais outil pour un petit ensemble fixe d’enregistrements qu’une requête de base de données normale couvre déjà - j’ai vu une base vectorielle boulonnée sur un workflow qui avait onze catégories possibles, là où une table de correspondance aurait été plus rapide, moins chère et plus facile à déboguer.

Quand c’est le bon outil, ce qui a vraiment besoin de soin n’est pas le modèle d’embedding - c’est ce qui est découpé, comment, et à quel point l’index reste frais après un changement du document source. Une recherche vectorielle sur des chunks périmés donne une réponse assurée et fausse, et rien dans la sortie de l’agent ne vous dit que c’est arrivé.

4. Humain dans la boucle et orchestration d’API : là où ça casse vraiment

La panne que je vois le plus n’est pas un mauvais raisonnement du modèle - c’est la couture entre deux systèmes : un appel API qui expire et que l’agent relance deux fois, envoyant une commande en double ; un webhook qui se déclenche avant que l’étape précédente ait fini d’écrire ; un appel d’outil qui réussit côté fournisseur mais dont la réponse reçue par l’agent indique un échec. Orchestrer des appels entre CRM, facturation et e-mail, c’est décider ce qui se passe en cas de timeout ou d’échec partiel avant que ça arrive en production, pas après.

Tout ce qui envoie de l’argent, supprime un enregistrement ou envoie un e-mail à un client passe par une étape de confirmation humaine avant de partir - non parce que le modèle est globalement peu fiable, mais parce que le coût d’une action automatique fausse est asymétrique avec le coût d’un clic de plus. Je préfère qu’une personne approuve vingt actions correctes par jour plutôt que l’agent envoie automatiquement une facture fausse.

Conclusion : l’agent est les 10% faciles

Choisir un modèle et écrire le premier prompt est vraiment la partie facile d’un workflow agentique. Le contexte qu’on lui donne, le schéma qu’on valide, la recherche vectorielle qui ne tourne que quand il faut, la logique de relance à travers trois API, et cette unique étape qu’un humain continue d’approuver - voilà les 90% restants, et ce sont eux qui décident si l’automatisation fonctionne encore un mardi dans six mois avec des données que personne n’a testées. Écrivez via le formulaire le processus que vous voulez automatiser, et je vous dirai quels sont les 10% qui relèvent de l’agent et les 90% qu’il faut vraiment construire.