Claude Fable 5 vs Opus 5 : quel modèle choisir pour vos agents IA ?
Fable 5 ou Opus 5 ? Choisissez selon la difficulté de la mission et le coût par tâche réussie — pas le modèle le plus puissant partout.
11 min de lecture
En 2026, presque n’importe quel processus logiciel peut recevoir une couche d’intelligence artificielle. Ce n’est pas pour autant une bonne idée.
Une règle métier simple n’a pas besoin d’un agent autonome. Un agent capable de naviguer dans une codebase n’a, à l’inverse, aucun intérêt s’il est réduit à suivre une séquence totalement figée.
La question utile n’est pas « peut-on y mettre de l’IA ? ». C’est :
À quel moment le système doit-il prendre une décision qu’il est difficile de prévoir à l’avance ?
Automatisation, workflow IA et agent IA : la différence essentielle
Ces approches peuvent parfois produire exactement le même résultat. La différence se trouve dans la manière d’y arriver, et surtout dans qui choisit ce qui se passe ensuite.
Automatisation
Le code · Chemin figé
CI verte → déployer → notifier
Workflow IA
Le code · Une étape IA
Classer un ticket, puis router
Workflow agentique
Code et modèle · Chemin partiel
Diagnostiquer un échec CI, choisir les outils
Agent autonome
Le modèle · Dans des limites
Corriger une régression, proposer un patch
Automatisation déterministe
Une séquence définie à l’avance. Pull request fusionnée, CI verte, release, déploiement, notification. Le logiciel sait déjà quoi faire. Rien à interpréter.
Workflow avec une étape IA
Le logiciel orchestre toujours le processus. Un modèle intervient pour comprendre une donnée non structurée : classer un feedback, extraire un sujet, estimer une sévérité. L’IA n’a pas le volant.
Workflow agentique
Le cadre général reste fixé. Certaines parties deviennent dynamiques : analyser une erreur CI, choisir quels logs lire, formuler une hypothèse, modifier le code, relancer les tests.
Agent autonome
L’agent reçoit un objectif, un contexte, des outils, des permissions et des limites. Il décide ensuite d’une part importante du processus, jusqu’à une condition d’arrêt ou une validation humaine.
On entend parfois qu’un système utilisant un LLM est automatiquement un agent. Ce n’est pas le cas. Un workflow peut appeler un modèle dix fois tout en restant déterministe.
Appel IA
Agent
Le code décide de l’enchaînement
Le modèle choisit une partie du chemin
Une ou plusieurs étapes figées
Une boucle observer → agir → réévaluer
Coût et latence prévisibles
Nombre d’appels variable
Testable comme un pipeline
À évaluer sur le résultat et les contraintes
1. Quand utiliser une automatisation classique
L’automatisation déterministe reste une des meilleures solutions lorsqu’un processus peut être décrit précisément. Elle est rapide, peu coûteuse, testable, reproductible, simple à auditer et relativement facile à maintenir.
Elle fonctionne particulièrement bien lorsque les données sont structurées et les règles stables.
Synchroniser deux systèmes
Un utilisateur est créé → créer son profil dans le CRM. Aucune IA nécessaire.
Déployer une application
Si la branche est main et si les tests sont verts → lancer le déploiement. Demander à un modèle « penses-tu que nous devrions déployer ? » n’ajoute rien.
Appliquer une règle métier
Si facture supérieure à 10 000 € → validation obligatoire. Une règle financière ou de permission doit généralement rester déterministe.
Notifier un événement
Une release est publiée → envoyer le message d’équipe. Le déclencheur et l’action sont déjà connus.
2. Quand ajouter une étape IA dans un workflow
L’IA devient utile lorsque le processus est prévisible mais que certaines données ne le sont pas. « Comprends ce que cet utilisateur veut dire » se résout mal avec des conditions.
Le modèle agit alors comme un composant spécialisé. Il analyse. Le logiciel décide du processus.
Exemple support :
Email reçu → classification → extraction du produit → détection de l’urgence → validation du format → routage déterministe.
Cette architecture suffit souvent pour classer des tickets, résumer des conversations, extraire des données, générer une première version d’un texte, analyser des logs, enrichir des champs ou transformer du langage naturel en données structurées.
3. Quand passer à un workflow agentique
Les workflows deviennent difficiles à maintenir lorsqu’ils accumulent trop de branches : si erreur A alors X, si B alors Y, si C avec contexte D alors Z, sinon vérifier E, puis éventuellement F.
Un système agentique est plus adapté lorsqu’une partie du processus doit raisonner sur le contexte actuel pour choisir l’action suivante.
Sur un incident, un workflow fixe peut collecter les logs, le statut des services et les dernières releases. Ensuite, selon le problème, il faudra inspecter une base, regarder un commit, vérifier une API, comparer un incident précédent, lancer un test ou lire une doc. L’ordre dépend des informations découvertes.
C’est le bon usage d’un agent à l’intérieur d’un cadre : le logiciel pose les limites, le modèle choisit les investigations.
4. Quand utiliser un agent autonome
Un agent autonome est pertinent pour les missions ouvertes : nombre d’étapes inconnu, plusieurs stratégies possibles, résultats intermédiaires qui changent la suite, outils différents, tentatives qui peuvent échouer, besoin de réévaluer la stratégie.
Le développement logiciel est un excellent exemple. Pour « mets à jour cette librairie et adapte l’application aux breaking changes », personne ne sait à l’avance combien de fichiers changeront, quelles APIs ont bougé, quels tests casseront, ni si la documentation devra être consultée.
Cette boucle peut s’arrêter sur une réussite, un blocage, une limite d’itérations, une limite de coût, ou le besoin d’une validation humaine.
Comparaison : automatisation, workflow IA, agent
| Critère | Automatisation | Workflow IA | Workflow agentique | Agent autonome |
|---|---|---|---|---|
| Chemin | Fixe | Fixe | Partiellement dynamique | Très dynamique |
| Décisions IA | Aucune | Localisées | Régulières | Centrales |
| Coût | Faible | Faible à moyen | Moyen à élevé | Potentiellement élevé |
| Latence | Très faible | Faible à moyenne | Moyenne | Variable |
| Prévisibilité | Très élevée | Élevée | Moyenne | Plus faible |
| Flexibilité | Faible | Moyenne | Élevée | Très élevée |
| Audit | Très simple | Bon | Plus complexe | Observabilité nécessaire |
| Tests | Classiques | Tests + evals IA | Evals de workflow | Evals de trajectoires |
| Imprévus | Faible | Limitée | Bonne | Très bonne |
Ces valeurs sont relatives. Un agent rapide avec deux outils peut coûter moins cher qu’un workflow qui envoie un modèle frontier sur un énorme contexte. Le tableau montre une tendance, pas une loi.
Coût, latence, prévisibilité, traces
Plus d’autonomie signifie souvent plus d’exécution. Une automatisation fait un traitement. Un workflow IA fait un ou plusieurs appels modèle. Un agent enchaîne réflexion, outil, résultat, nouvelle décision.
La métrique utile n’est pas « combien coûte un appel à Claude ou GPT ? ». C’est combien coûte une mission terminée correctement.
Il faut donc suivre les tokens, le nombre d’appels modèle, les appels d’outils, les retries, les recherches et la durée totale.
La latence suit la même logique. Un workflow déterministe peut répondre en quelques millisecondes. Un agent peut avoir besoin de plusieurs tours. C’est acceptable si la tâche aurait pris trente minutes à un humain. C’est beaucoup moins acceptable si l’utilisateur attend le résultat d’un clic.
Pour une automatisation, un log simple suffit : trigger, condition, action, résultat. Pour un agent, il faut reconstruire l’exécution : outils, paramètres, résultats, erreurs, retries, changements d’état, validations, coûts, durée.
L’objectif n’est pas de récupérer une « pensée secrète » du modèle. Il faut une trace claire de ce que le système a réellement fait.
Les validations humaines restent essentielles
Autonomie et contrôle humain ne s’opposent pas. Un agent peut lire, analyser, chercher, tester et préparer des modifications, puis demander une approbation avant un déploiement, une suppression, un e-mail externe, une publication, un paiement ou un changement de permission.
L’autonomie ne signifie pas « le modèle fait ce qu’il veut ». Elle signifie : le modèle dispose d’une zone de décision précisément définie, appliquée par le logiciel, pas seulement par un prompt.
Pourquoi l’architecture hybride est souvent la meilleure
Dans une architecture robuste, il est rarement nécessaire de tout transformer en agent.
Le code garde
L’IA prend
Permissions, budgets, schémas
Comprendre une intention
Transactions et sécurité
Comparer des options
Contraintes métier invariantes
Chercher, proposer, analyser
L’humain garde les décisions critiques : déployer, autoriser une dépense, accepter une modification majeure, publier un contenu sensible.
Exemple : traiter un bug logiciel
Mission : « Un utilisateur signale que l’import CSV ne fonctionne plus depuis la dernière release. »
Automatisation
Créer un ticket, attacher les logs, notifier l’équipe. Utile, mais le système n’investigate pas.
Workflow IA
Résumer le bug, classer la sévérité, identifier le composant probable, générer une checklist. Plus utile, mais le chemin reste fixe.
Agent
Lire le ticket, inspecter les logs, chercher le code d’import, vérifier les changements récents, reproduire, proposer une correction, tester, demander une review. Le chemin varie selon ce qu’il découvre.
Ce qui tranche
Si vous savez déjà les cinq étapes, restez sur un workflow. Si l’investigation doit s’adapter, l’agent a un vrai avantage.
Faut-il plusieurs agents ?
Pas forcément. Le multi-agent devient intéressant pour séparer des responsabilités : développeur, reviewer, tests, puis validation humaine. Ou plusieurs explorations en parallèle, puis un juge.
Cela peut apporter des perspectives indépendantes, une spécialisation, une review et un peu de parallélisme. Cela augmente aussi le coût, la complexité, les transferts de contexte et les risques de coordination.
Ne construisez pas dix agents tant qu’un seul agent correctement outillé n’a pas montré ses limites.
Les pipelines sont particulièrement utiles lorsque le processus est récurrent mais que certaines étapes restent intelligentes : mission → agent développeur → tests → agent reviewer → corrections → approbation humaine.
Le pipeline définit la structure. Les agents restent libres à l’intérieur de certaines étapes. C’est une combinaison nette : orchestration déterministe à l’extérieur, intelligence adaptative à l’intérieur.
C’est l’un des principes de Stellary : pipelines, revues, boucles de correction et validations humaines, avec une traçabilité des runs. Les agents y sont des opérateurs du workspace, avec rôles, outils, modes d’autonomie et traces, plutôt qu’un chat déconnecté du projet.
Quelle architecture choisir ?
01
Le processus peut-il être entièrement décrit par des règles ?
Oui
02
Une étape doit-elle comprendre du contenu non structuré ?
Non
Automatisation classique
Oui
Workflow avec étape IA
Non
03
Le processus global peut-il rester structuré ?
Oui
Workflow agentique
Non
04
L’agent a-t-il des limites, permissions et conditions d’arrêt claires ?
Oui
Agent autonome borné
Non
Repenser le problème avant de l’automatiser
| Cas | Architecture |
|---|---|
| Synchroniser deux outils | Automatisation |
| Envoyer une notification | Automatisation |
| Déployer après une CI réussie | Automatisation |
| Classifier des tickets | Workflow IA |
| Résumer une réunion | Workflow IA |
| Extraire des informations d’un document | Workflow IA |
| Analyser un bug | Workflow agentique |
| Diagnostiquer une CI | Workflow agentique |
| Corriger du code puis tester | Workflow agentique |
| Recherche complexe | Agent |
| Explorer une codebase sur une mission ouverte | Agent |
| Review indépendante de plusieurs solutions | Pipeline multi-agent |
Les erreurs les plus fréquentes
Un agent parce que c’est possible
Si dix lignes de code fiables suffisent, gardez-les. L’agent est parfois une solution trop lourde à un problème déjà résolu.
Confondre appel LLM et agent
Texte → modèle → résumé n’est pas un agent. C’est un appel IA dans un workflow.
Trop d’outils
Plus l’agent a d’outils, plus il doit choisir. Des outils mal différenciés augmentent erreurs, latence, tokens et difficulté d’évaluation.
Autoriser par prompt
Une consigne dans le prompt n’est pas un garde-fou. Les permissions doivent être appliquées par le logiciel.
Oublier les limites
Itérations max, budget, durée, nombre d’erreurs, escalade humaine. Sans arrêt, une boucle peut consommer sans produire de valeur.
Multi-agent trop tôt
Le multi-agent doit résoudre une limitation réelle, pas illustrer un organigramme.
Comment évaluer un système agentique
Tester uniquement la réponse finale est insuffisant. Il faut regarder la qualité, la fiabilité, le coût d’une mission réussie, la latence, la trajectoire d’outils, l’efficacité du nombre d’appels, le respect des permissions, et ce qui se passe quand un outil échoue.
Cette observabilité devient décisive dès qu’une plateforme orchestre plusieurs agents. Stellary insiste notamment sur la persistance des runs, outils, validations, coûts et traces, pour rendre l’activité agentique gouvernable plutôt que magique.
La bonne question n’est pas « combien d’autonomie peut-on donner à l’IA ? ». C’est : où l’autonomie apporte-t-elle réellement quelque chose ?
Vous pouvez alors monter progressivement : automatisation → workflow avec étape IA → workflow agentique → agent autonome → orchestration multi-agent. Chaque niveau doit résoudre une vraie contrainte du précédent.
Consultez aussi comment gérer des agents IA sans perdre le contrôle, l’orchestration d’agents et le guide des automatisations.
FAQ
Quelle est la différence entre un agent IA et une automatisation ?
Une automatisation suit des règles prédéfinies. Un agent IA peut choisir dynamiquement certaines actions selon le contexte et les résultats obtenus pendant son exécution.
Quelle est la différence entre un workflow IA et un agent IA ?
Dans un workflow IA, le logiciel contrôle généralement l’enchaînement des étapes. Dans un agent, le modèle contrôle une partie significative du chemin d’exécution.
Quand utiliser un agent IA ?
Un agent devient pertinent lorsque le problème contient beaucoup d’incertitude, que le nombre d’étapes est difficile à prévoir, ou que plusieurs outils doivent être utilisés de manière adaptative.
Est-ce qu’un agent IA coûte plus cher qu’une automatisation ?
En général, il peut coûter davantage car il peut enchaîner plusieurs appels modèle et plusieurs appels d’outils. La métrique importante reste le coût d’une mission réussie par rapport à la valeur produite.
Faut-il toujours ajouter une validation humaine ?
Non. Les opérations à faible risque et réversibles peuvent être automatisées. Les actions sensibles, coûteuses, externes ou irréversibles devraient généralement avoir un contrôle supplémentaire.
Est-ce qu’un système multi-agent est meilleur ?
Pas nécessairement. Plusieurs agents peuvent apporter spécialisation, parallélisation ou review indépendante, mais ils augmentent aussi la complexité, la consommation et les besoins de coordination.
Peut-on combiner automatisations et agents ?
Oui, et c’est souvent l’architecture la plus robuste. Les automatisations encadrent le workflow ; les agents n’interviennent que là où l’adaptation ou le jugement sont nécessaires.
