Depuis deux ans, tout ce qui est automatisé s'appelle un agent. C'est commode pour vendre et catastrophique pour décider. Parce que ces deux choses n'ont pas la même nature, ne coûtent pas la même chose, ne cassent pas de la même façon, et ne se pilotent pas pareil.
Voici comment je fais la distinction en clientèle, sous forme de questions qu'on me pose vraiment.
« Concrètement, c'est quoi la différence ? »
Une automatisation exécute une suite d'étapes que tu as écrites. Quand un événement arrive, elle fait A, puis B, puis C. Elle peut avoir des conditions — si le montant dépasse mille euros, alors D. Mais toutes les branches ont été prévues par un humain. Elle est déterministe : mêmes entrées, mêmes sorties, toujours.
Un agent reçoit un objectif et une boîte à outils. À chaque étape, il décide quoi faire ensuite en fonction de ce qu'il vient de constater. Il peut appeler un outil, lire le résultat, changer d'avis, en appeler un autre. Il n'y a pas de chemin écrit à l'avance ; il y a un but, des moyens, et des limites.
La différence tient en un mot : le jugement. Une automatisation ne juge pas, elle applique. Un agent juge, et c'est précisément pour ça qu'on l'appelle — et précisément pour ça qu'il faut l'encadrer.
« Pourquoi mes automatisations cassent tout le temps ? »
Parce qu'elles sont fragiles à la forme, pas au fond.
Une chaîne qui lit un e-mail de commande et en extrait la référence produit avec une expression régulière fonctionne parfaitement — jusqu'au jour où un client écrit sa référence différemment, ajoute une pièce jointe au lieu de la coller, ou répond dans un fil au lieu d'ouvrir un nouveau message. La chaîne ne comprend pas, elle reconnaît des motifs. Un motif qui change, c'est une chaîne qui casse.
Il y a un bon côté à cette fragilité : elle est bruyante. Ça tombe en erreur, quelqu'un est alerté, on répare. Un agent placé au même endroit n'aurait pas cassé. Il aurait deviné, mal, et personne ne s'en serait aperçu avant plusieurs semaines. Entre les deux modes de défaillance, celui qui fait du bruit est souvent préférable.
« Alors je dois choisir ? »
Non, et c'est le point le plus important de cet article. Dans les processus réels, presque tout se traite avec les deux.
Le découpage que j'applique systématiquement :
- La mécanique va dans la chaîne. Déclenchement, récupération, transformation de format, écriture en base, envoi, notification, journalisation. Tout ce qui est reproductible et vérifiable. C'est moins cher, c'est plus rapide, c'est testable, et ça donne le même résultat à chaque exécution.
- Le jugement va dans l'agent. Classer une demande qui ne rentre dans aucune case, extraire une information d'un texte écrit librement, rédiger une réponse adaptée au contexte, décider si un dossier mérite une escalade humaine.
Un agent appelé au bon endroit dans une chaîne bien construite, c'est une brique de trois lignes dans un workflow qui en compte quarante. C'est la bonne proportion. Quand je vois un agent qui pilote l'ensemble du processus, y compris les étapes triviales, je sais qu'on va payer cher, attendre longtemps, et déboguer à l'aveugle.
Trois exemples de découpage
Traitement des factures fournisseurs. La chaîne surveille la boîte mail, détecte la pièce jointe, la stocke, appelle l'OCR, écrit dans l'outil comptable, notifie. L'agent intervient sur un seul point : lire le document extrait et décider à quel compte et à quel centre de coût l'affecter quand le libellé est ambigu. Le reste n'a aucun besoin de jugement.
Support client de niveau 1. La chaîne reçoit le message, l'enregistre, vérifie le contrat associé, envoie l'accusé de réception, archive. L'agent lit la demande, cherche dans la base de connaissances, et rédige un projet de réponse — ou classe en « à traiter par un humain » quand il n'a pas de quoi répondre. Cette dernière capacité, savoir dire qu'il ne sait pas, est ce qui sépare un agent utilisable d'un agent dangereux.
Veille concurrentielle. La chaîne collecte les sources selon un calendrier, déduplique, stocke. L'agent lit et décide ce qui mérite d'être remonté cette semaine — un tri que personne n'arrive à formuler en règles fixes, et qu'un humain fait en trois secondes par article.
Dans les trois cas, la chaîne représente l'essentiel du travail de construction. L'agent porte la valeur qu'on ne savait pas coder.
Ce qui change en pratique
Les conséquences opérationnelles sont concrètes.
- Le coût. Une chaîne coûte quelques centimes d'exécution. Un agent consomme des jetons à chaque tour de boucle, et il peut boucler. Sur un gros volume, l'écart n'est pas marginal.
- Le débogage. Une chaîne se relit étape par étape. Un agent laisse une trace de raisonnement qu'il faut savoir lire, et deux exécutions identiques peuvent diverger.
- Le test. Une chaîne se teste avec quelques cas. Un agent se teste avec un jeu de cas représentatifs qu'il faut construire, et qu'il faut rejouer à chaque changement de modèle ou de consigne.
- Les garde-fous. Un agent a besoin de limites explicites : nombre d'étapes maximum, outils autorisés, seuil au-delà duquel il passe la main. Sans ça, il finira par prendre une décision que personne ne lui avait confiée.
La question à te poser sur ton prochain processus
Prends une étape et demande-toi : est-ce que je peux écrire la règle en trois phrases, sans dire « ça dépend » ?
Si oui, c'est de la chaîne. Ne mets pas d'IA dessus, tu paierais plus cher pour un résultat moins fiable. Si non, tu tiens l'endroit où un agent a du sens — et probablement le seul.