Agents IA ou automatisations classiques : la question ne se résume pas à choisir l’outil le plus moderne. Une automatisation déterministe exécute une suite connue. Un agent utilise un modèle pour choisir des étapes, des outils ou une stratégie. Cette liberté peut aider face à une entrée imprévisible, mais elle augmente aussi le coût, la latence et le risque d’erreur.
Je commence toujours par le scénario le plus simple qui produit un résultat vérifiable. L’agent n’arrive qu’au moment où les règles fixes deviennent réellement insuffisantes.
Agents IA : de quoi parle-t-on exactement ?
Un agent reçoit un objectif, observe un état, choisit une action et peut recommencer jusqu’à un résultat ou une limite. Le modèle ne produit plus seulement du texte : il peut sélectionner un outil, remplir des paramètres, lire la réponse et décider de la suite.
Cette boucle n’est pas automatiquement intelligente ni sûre. La qualité dépend des outils exposés, des permissions, des données, du modèle, des limites et de l’évaluation. Un agent mal borné peut répéter une action, utiliser le mauvais fichier ou transformer une hypothèse en décision.
Ce que fait mieux une automatisation classique
Pour renommer un fichier, envoyer un rapport à heure fixe, convertir un format ou appeler une API avec des règles stables, un workflow déterministe est souvent supérieur. Il est rapide, prévisible, moins coûteux et plus facile à auditer.
- les mêmes entrées doivent produire le même parcours ;
- les erreurs sont connues et gérées explicitement ;
- chaque étape possède un journal clair ;
- les permissions sont limitées à l’action prévue ;
- un test peut couvrir chaque branche.
Les principes de workflow documentés par n8n illustrent cette logique d’étapes et de déclencheurs. Le même raisonnement s’applique à un script, une tâche planifiée ou un outil no-code.
Quand l’agent devient utile
L’agent gagne en intérêt lorsque l’entrée varie fortement et qu’il faut interpréter avant d’agir : classer une demande libre, choisir une documentation, proposer une procédure de diagnostic ou préparer une synthèse à partir de plusieurs sources.
Je lui confie d’abord une recommandation, pas une action irréversible. Par exemple, il peut proposer la catégorie d’un ticket avec ses raisons. Une règle ou un humain valide ensuite le changement.
| Besoin | Choix initial | Pourquoi |
|---|---|---|
| copie quotidienne d’un fichier | automatisation | chemin connu et testable |
| résumer des tickets hétérogènes | LLM encadré | interprétation de texte |
| choisir parmi plusieurs outils | agent borné | décision dépendante du contexte |
| supprimer des données | workflow avec validation humaine | conséquence difficile à annuler |
Le meilleur système est souvent hybride
Je laisse au modèle la partie ambiguë et aux règles la partie sensible. L’agent peut extraire une intention et préparer des paramètres. Un workflow vérifie le schéma, les droits, les limites et demande une confirmation avant l’action.
Cette séparation réduit la surface d’erreur. Elle rend aussi le système plus facile à expliquer : on sait ce que le modèle a proposé et ce que le code a autorisé.
Commencer par les permissions
Un agent ne devrait pas recevoir un accès administrateur « au cas où ». Je crée des outils minuscules : lire un dossier précis, rechercher une référence, préparer un brouillon, ajouter une ligne dans une table dédiée. Chaque outil valide ses entrées côté serveur.
Les outils d’agent documentés par OpenAI reposent également sur une définition explicite des capacités disponibles. L’important n’est pas le nombre d’outils, mais leur périmètre et la preuve de leur exécution.
Le coût caché des boucles
Une tâche automatisée exécute cinq étapes et s’arrête. Un agent peut relire, réfléchir, rappeler un outil et recommencer. Chaque boucle consomme du temps, des jetons et parfois des appels payants.
Je fixe un nombre maximal d’étapes, un budget, un délai et des conditions d’arrêt. Une réponse partielle clairement signalée vaut mieux qu’une boucle qui consomme sans progresser.
Évaluer autre chose que la démonstration
Une vidéo montre souvent le meilleur cas. Je prépare au contraire des entrées banales, ambiguës, incomplètes et contradictoires. Je mesure :
- la réussite complète de la tâche ;
- le nombre d’étapes et le coût ;
- les appels d’outil incorrects ;
- les refus justifiés ;
- la capacité à demander une information manquante ;
- la qualité du journal et des preuves.
Je rejoue le même jeu après chaque changement de modèle ou de prompt. Sans ce contrôle, une amélioration apparente sur un cas peut casser trois scénarios silencieusement.
Les données et la mémoire
Un agent qui accumule l’historique peut dépasser la fenêtre utile et réintroduire d’anciennes informations. Je sépare la mémoire de travail, les préférences durables et les documents. Chaque catégorie possède une durée de conservation et une méthode d’effacement.
Pour les documents, un RAG local correctement testé est souvent préférable à l’injection permanente de tout un dossier. Le guide sur la VRAM, la RAM et le contexte rappelle aussi que la capacité maximale n’est pas un objectif.
Une grille de décision en sept questions
- le parcours peut-il être écrit sous forme de règles ?
- l’entrée exige-t-elle une interprétation de langage naturel ?
- une erreur peut-elle être annulée facilement ?
- quelles permissions minimales sont nécessaires ?
- comment la réussite sera-t-elle mesurée ?
- quel budget et quelle durée maximale sont acceptables ?
- où une validation humaine doit-elle intervenir ?
Si les règles couvrent 95 % des cas, je conserve l’automatisation et j’isole les exceptions. Si le classement des exceptions demande réellement du jugement linguistique, j’ajoute un modèle à cet endroit précis.
Les signaux d’un agent inutilement complexe
- le modèle choisit toujours le même outil ;
- les entrées ont déjà un schéma stable ;
- le workflow serait plus court que le prompt ;
- personne ne peut expliquer la condition d’arrêt ;
- la démonstration n’inclut aucun échec ;
- les permissions dépassent largement le besoin ;
- le journal ne permet pas de reproduire la décision.
Verdict BlackFury
Je choisis une automatisation classique dès que le chemin est connu. J’ajoute un LLM pour interpréter une entrée non structurée. Je n’emploie un agent que lorsqu’il doit réellement choisir entre plusieurs actions et que ce choix est mesurable, borné et réversible. La sophistication doit résoudre une difficulté réelle, pas seulement moderniser le vocabulaire du projet.
