Agent IA vs chatbot : la différence se trouve dans la boucle d’action

Les étiquettes commerciales brouillent souvent la frontière. La question utile n’est pas « ce produit utilise-t-il un grand modèle ? », mais « qui contrôle l’enchaînement des étapes ? ». Dans un chatbot simple, l’application collecte un message et affiche une réponse. Dans un workflow, le code décide du prochain nœud. Dans un agent, le modèle participe à cette décision en fonction de l’objectif et des observations.

Une interface conversationnelle peut masquer l’un ou l’autre de ces systèmes. Inversement, un agent peut travailler sans chat visible, par exemple en inspectant un dépôt, en modifiant quelques fichiers et en lançant des tests. La forme de l’écran ne détermine donc pas le degré d’agentivité.

Le modèle interprète la situation et propose la prochaine action. Les instructions fixent le rôle, les priorités et les limites. Les outils donnent accès à des observations ou à des mutations réelles. L’état conserve ce qui a été tenté et obtenu. La boucle d’exécution décide enfin s’il faut appeler un outil, transférer la tâche, demander une approbation ou terminer.

Les garde-fous entourent toutes ces briques. Ils peuvent filtrer une entrée, borner les outils disponibles, exiger une validation humaine avant une action sensible, contrôler une sortie structurée ou interrompre une boucle trop longue. Aucun garde-fou isolé ne remplace l’authentification, l’autorisation et les protections classiques du logiciel.

L’autonomie ajoute de la souplesse, mais aussi du coût, de la latence et des chemins difficiles à prévoir. Un formulaire validé, un calcul fiscal, une règle de permission ou une migration de schéma ne gagne rien à être réinterprété à chaque exécution. Lorsque les étapes et exceptions peuvent être énumérées clairement, le code déterministe reste plus facile à tester et à auditer.

Un agent devient pertinent quand les entrées sont peu structurées, que la prochaine étape dépend d’un jugement contextuel et que plusieurs outils peuvent servir l’objectif. Même alors, commencez par un seul agent borné. N’introduisez plusieurs agents que si les instructions ou surfaces d’outils deviennent réellement trop complexes pour une boucle unique.

Lire un dépôt, créer un brouillon et supprimer des données n’ont pas le même risque. Définissez les permissions par outil et par environnement. Les actions réversibles peuvent être automatisées plus largement ; les opérations coûteuses, publiques ou destructives doivent passer par une approbation explicite et une cible résolue.

Prévoyez aussi une sortie de secours : nombre maximal de tours, budget, délai, transfert humain et journal d’événements. Un agent fiable ne se mesure pas à sa capacité à continuer indéfiniment, mais à sa capacité à reconnaître une condition d’arrêt et à expliquer l’état exact de la tâche.

Une réponse convaincante peut masquer un mauvais appel d’outil ou une modification incomplète. L’évaluation doit partir de tâches représentatives et vérifier l’état final : fichiers attendus, enregistrements corrects, tests, absence d’effets de bord et conformité aux permissions.

Mesurez séparément la réussite de la tâche, les erreurs d’outil, les reprises, les demandes d’approbation, le coût, la latence et la qualité du compte rendu. Conservez les traces nécessaires à l’analyse tout en minimisant les données sensibles. Les échecs réels doivent rejoindre un corpus de régression avant de modifier l’orchestration.