Commencer par ce que l’on cherche à améliorer
« Nous voulons un agent IA. » La demande est compréhensible : les démonstrations donnent à voir des systèmes capables de chercher, raisonner et agir. Pour concevoir une solution utile, il reste pourtant à préciser le travail attendu. Quelle tâche prend trop de temps ? Où les erreurs se produisent-elles ? Quelle décision arrive trop tard ? Qui utilisera le résultat ?
Une équipe qui prépare chaque semaine le même rapport et une équipe qui enquête sur des incidents imprévisibles rencontrent des difficultés différentes. Elles peuvent mobiliser des modèles similaires, mais leur donner un rôle très différent dans le processus.
Chez Logbrain, nous partons de ces situations. Notre rôle consiste à relier les enjeux métier aux choix techniques, puis à vérifier que l’architecture retenue apporte un bénéfice à la hauteur de son coût et de sa complexité.
Workflow ou agent : qui choisit la prochaine étape ?
Dans un workflow, le code organise le parcours : les étapes, les conditions de passage et les branches possibles sont définies. Certaines étapes peuvent faire appel à un modèle pour extraire une information, classer un document ou rédiger une synthèse. Le processus peut fonctionner sans intervention humaine et comporter des boucles ; il conserve une orchestration prévue à l’avance.
Dans un agent, le modèle choisit dynamiquement la prochaine action à partir d’un objectif et des résultats obtenus. Il peut consulter un outil, examiner sa réponse, poursuivre une piste ou terminer. Cette liberté s’exerce dans le périmètre fixé par l’application : outils accessibles, permissions, durée et validations requises. Cette distinction d’orchestration est notamment décrite par Anthropic dans « Building effective agents ».
Agrandir le schéma. Le schéma montre deux mécanismes de décision. Leur pertinence dépend du travail à accomplir ; une même application peut utiliser les deux.
Un exemple : comprendre les coûts cloud
Prenons un cas illustratif : une entreprise souhaite mieux comprendre sa facture cloud. Deux besoins apparaissent derrière cette demande.
Produire un rapport régulier
Chaque semaine, il faut récupérer les dépenses, les répartir par projet, comparer les périodes et signaler les variations qui dépassent des seuils convenus. Les calculs reposent sur des règles connues. Un workflow permet de les expliciter, de les tester et de produire le rapport dans un format stable.
Un modèle peut ensuite rédiger un commentaire à partir des chiffres validés. Sa tâche est bornée : expliquer les variations présentes dans les données. Les montants, les comparaisons et les règles d’alerte restent calculés par le système.
L’intérêt à vérifier est concret : temps de préparation réduit, moins de corrections, meilleure lisibilité pour les responsables de projet. Il faut aussi examiner les cas difficiles, comme des données de facturation incomplètes ou des ressources mal rattachées à une équipe.
Investiguer une hausse inhabituelle
Une responsable demande ensuite : « Pourquoi les coûts de ce projet ont-ils augmenté alors que son activité semble stable ? » La réponse peut nécessiter plusieurs recherches : comparer les services, examiner les ressources concernées, rapprocher les dates d’un déploiement ou identifier un changement d’usage.
Un agent peut être pertinent si les résultats d’une recherche déterminent la suivante. Il reçoit un périmètre de comptes et de projets, des outils de consultation et un objectif précis. On attend de lui une explication étayée, qui distingue les faits observés, les hypothèses et les informations manquantes.
Le gain attendu porte ici sur le temps d’investigation et la qualité du diagnostic. Une recommandation d’arrêt ou de redimensionnement demande ensuite un examen des dépendances et des conséquences métier. Une ressource peu sollicitée peut, par exemple, servir à la reprise d’activité.
Combiner les approches quand le besoin le justifie
Dans cet exemple, un workflow peut collecter les données et détecter un écart. Une investigation agentique intervient sur les situations qui demandent une exploration. Le système rassemble ensuite les éléments dans un ticket, qu’une personne examine avant toute action sensible.
Cette répartition permet de préciser les responsabilités : les règles assurent les traitements connus, l’agent explore l’incertitude, et les validations encadrent les changements. Elle a également un coût d’intégration. Pour un faible volume ou des écarts simples à expliquer, une procédure plus légère peut rester suffisante.
La fréquence d’exécution et l’interface constituent d’autres choix. Un déclenchement nocturne, une demande dans Teams ou une conversation dans Slack peuvent appeler le même processus. Ces modes d’accès ne déterminent pas, à eux seuls, s’il s’agit d’un workflow ou d’un agent.
Les questions qui orientent l’architecture
Quelle part du travail est prévisible ?
Décrire quelques cas réels aide à séparer les opérations récurrentes des décisions qui dépendent de découvertes successives. Cette distinction permet de placer l’autonomie là où elle pourrait apporter un bénéfice, et de conserver des règles explicites là où elles répondent au besoin.
Quelles seraient les conséquences d’une erreur ?
Une synthèse interne, une réponse envoyée à un client et une modification d’infrastructure n’engagent pas les mêmes conséquences. Les permissions et les validations doivent refléter ces différences. Il faut définir les situations où le système s’arrête, demande une information ou transmet la main.
Les données et les outils permettent-ils de répondre ?
Une investigation dépend de la qualité des informations disponibles. Des coûts sans rattachement aux projets, des journaux incomplets ou des droits trop larges compliquent le travail. L’accès aux outils doit préserver le périmètre de chaque utilisateur et de chaque équipe. Le modèle ne remplace ni cette organisation ni les contrôles d’accès.
L’équipe pourra-t-elle faire vivre la solution ?
L’exploitation comprend le suivi des erreurs, l’évolution des outils, la gestion des accès et la réévaluation après un changement de modèle. Une architecture doit être compréhensible par les personnes qui la maintiendront. La documentation, les traces d’exécution et les procédures de reprise font partie du choix initial.
Mesurer un ROI qui tient compte du travail réel
Le coût d’un appel au modèle ne suffit pas à évaluer la solution. Le calcul doit intégrer la conception, l’intégration, l’hébergement, les outils, les évaluations et la maintenance. Il faut aussi compter le temps passé à vérifier les résultats et à reprendre les tâches qui échouent.
Nous proposons de comparer les approches sur des cas représentatifs, avec des critères définis avant l’essai :
- Résultat exploitable : la tâche est-elle correctement accomplie, avec les éléments nécessaires pour utiliser la réponse ?
- Temps total : combien de temps s’écoule jusqu’au résultat validé, reprises humaines comprises ?
- Coût par tâche réussie : quel coût complet pour obtenir un résultat qui satisfait les critères attendus ?
- Maîtrise : les accès, les limites d’exécution et les validations sont-ils respectés ?
- Usage réel : les équipes s’en servent-elles, et le temps libéré est-il effectivement réinvesti ?
Sur une période donnée, une estimation du ROI peut rapprocher les bénéfices valorisés des coûts complets de la solution. Les hypothèses doivent rester visibles. Une heure économisée représente une capacité libérée ; elle devient une économie financière lorsque l’organisation peut effectivement la convertir. Les bénéfices de qualité ou de réduction du risque demandent, eux aussi, une méthode d’évaluation explicite.
Un essai peut ainsi conclure qu’un agent apporte une meilleure couverture des cas complexes, mais qu’un workflow répond mieux au volume courant. Il peut aussi montrer que la priorité est d’améliorer les données avant d’automatiser davantage.
Et plusieurs agents ?
Répartir un travail entre plusieurs agents mérite d’être étudié lorsque des recherches peuvent avancer indépendamment ou que des contextes spécialisés doivent être séparés. Cela ajoute des échanges, de la coordination et des évaluations à mener. Le retour d’expérience d’Anthropic sur son système de recherche illustre ce compromis dans un contexte précis de recherche parallèle.
Pour un projet donné, il reste à vérifier que cette répartition améliore le résultat. Le nombre d’agents ou d’outils n’est pas un indicateur de valeur en soi. La comparaison porte sur la qualité obtenue, le délai, le coût et la capacité à diagnostiquer les échecs.
Notre approche : cadrer, éprouver, transmettre
Une première étape consiste à définir le besoin avec les équipes métier et techniques : résultat attendu, contraintes, risques et situation de départ. Nous pouvons ensuite comparer des options sur un périmètre limité et sur les mêmes cas, y compris les exceptions.
L’essai doit permettre une décision : poursuivre, ajuster l’architecture ou renoncer à une piste. Lorsqu’une approche est retenue, le passage en production inclut les responsabilités d’exploitation, les contrôles, le suivi des coûts et le transfert de connaissances.
Le niveau d’autonomie se choisit en fonction du problème. Sa valeur se vérifie dans les résultats et dans la capacité des équipes à les utiliser.
Vous avez un processus à améliorer ou une expérimentation à cadrer ? Parlons de votre situation. Nous pouvons vous aider à poser les critères de choix et à construire un essai qui permette de décider.
Sources et prolongements
- Anthropic — Building effective agents : distinction entre workflows et agents, et principes de conception.
- Anthropic — How we built our multi-agent research system : retour d’expérience sur une architecture de recherche parallèle.
