Agent IA ou automatisation classique : comment choisir ?

Un client envoie un email pour savoir où en est sa commande. Pour lui répondre, il faut comprendre sa demande, retrouver la commande, consulter son statut et rédiger un message. Faut-il confier l’ensemble à un agent IA ?

Pas nécessairement. Certaines étapes relèvent de règles explicites, d’autres de la compréhension du langage. Le bon choix consiste souvent à les traiter différemment, plutôt qu’à donner la totalité du parcours à un modèle.

Utilisez des règles pour ce que vous savez décrire précisément. Introduisez de l’IA là où l’interprétation est utile. Donnez de l’autonomie uniquement lorsque le bénéfice justifie les contrôles supplémentaires.

Trois approches qu’il faut distinguer

L’automatisation classique

Un workflow exécute des étapes prévues à l’avance. Par exemple : lorsqu’un formulaire arrive, vérifier les champs, chercher un client dans le CRM, créer un dossier si aucun doublon n’existe, puis notifier une équipe.

Le chemin peut comporter des conditions et des boucles. Il reste défini par des règles écrites. Cette approche convient bien aux calculs, aux transferts de données structurées, aux contrôles de format et aux décisions dont les critères sont explicites.

Elle peut être construite dans un outil comme n8n ou directement en code. Le choix de l’outil ne change pas sa logique fondamentale.

Le workflow enrichi par l’IA

Le parcours reste prédéfini, mais une étape utilise un modèle : extraire des informations d’un texte, classer une demande, résumer un document ou proposer une réponse.

Un système qui demande à un modèle de classer un email, puis suit une branche prédéfinie, n’a pas besoin d’être présenté comme un agent autonome. Cette solution est souvent suffisante. Les entrées, les sorties attendues et les points de contrôle sont plus faciles à délimiter.

L’agent IA

Le terme recouvre des produits variés. Dans cet article, il désigne un système où le modèle peut choisir les prochaines étapes et les outils à appeler pour atteindre un objectif, dans un cadre défini.

L’agent peut décider de rechercher une information, d’interroger une autre source puis de demander une précision. Cette souplesse devient intéressante lorsque les parcours possibles sont nombreux et difficiles à énumérer. Elle introduit aussi de nouvelles questions : combien d’étapes autoriser, quelles actions permettre et comment détecter une mauvaise décision ?

Décomposer un cas concret : le suivi de commande

Reprenons l’email du client. Une architecture raisonnable peut séparer le traitement en cinq étapes.

Comprendre le motif. Si le client a choisi « suivi de commande » dans un formulaire, une règle suffit. Dans un email libre mêlant plusieurs sujets, un modèle peut proposer une catégorie et extraire une référence.

Vérifier les informations. La référence doit correspondre au format attendu. Surtout, le demandeur doit être autorisé à consulter la commande. Cette vérification relève du système applicatif, pas de l’appréciation du modèle.

Lire le statut. Le statut provient du logiciel de gestion ou du transporteur. Le modèle ne doit pas le déduire à partir d’un ancien message ni inventer une date de livraison manquante.

Préparer la réponse. Pour un statut standard, un modèle de message peut suffire. Une IA devient utile lorsque l’on souhaite adapter la formulation à un échange plus long, à partir des seules informations vérifiées.

Valider les cas particuliers. Une contestation, une demande de remboursement ou une incohérence de données peut nécessiter une reprise humaine. Le parcours doit prévoir cette sortie, avec le contexte nécessaire pour éviter au conseiller de recommencer toute la recherche.

Dans cet exemple, l’IA apporte de la valeur à l’interprétation et éventuellement à la rédaction. Un agent capable de modifier librement les commandes ajouterait une autonomie dont le besoin n’est pas encore démontré.

Reconnaître les situations où un agent peut être utile

L’approche agentique mérite d’être étudiée lorsque trois conditions sont réunies :

• la prochaine action dépend d’informations découvertes en cours de traitement ;
• plusieurs outils ou sources peuvent être nécessaires, dans un ordre variable ;
• le résultat peut être évalué et les actions suffisamment encadrées.

Par exemple, un assistant de recherche interne peut devoir identifier les documents pertinents, comparer leurs versions et demander quelle entité du groupe est concernée avant de répondre. L’ordre des recherches n’est pas toujours prévisible.

En revanche, calculer une remise à partir d’un barème, synchroniser un champ entre deux outils ou envoyer une relance à une échéance précise ne justifie pas, à lui seul, cette architecture.

Avant de choisir la technologie, assurez-vous que le processus mérite d’être automatisé. Notre méthode pour choisir un premier processus métier permet de cadrer le volume, les exceptions et le gain attendu.

Tester la qualité sur des cas que vous connaissez

Une démonstration réussie ne suffit pas à évaluer un système. Constituez un jeu de cas représentatifs, avec les réponses ou les actions attendues : demandes simples, formulations ambiguës, informations absentes, contradictions et tentatives de faire sortir le système de son rôle.

Gardez une partie de ces cas à l’écart des ajustements du prompt. Ils serviront à vérifier qu’une amélioration apparente ne vient pas seulement d’une adaptation aux exemples déjà vus.

Mesurez la qualité de chaque étape. Une réponse bien formulée peut reposer sur la mauvaise commande. Une bonne catégorie peut conduire à une action inappropriée. Distinguez notamment :

• les erreurs d’extraction ou de recherche ;
• les réponses non étayées par les sources disponibles ;
• les actions incorrectes ;
• les demandes inutilement transmises à un humain ;
• le temps nécessaire pour vérifier et corriger le résultat.

Ne traitez pas une « confiance à 95 % » déclarée par le modèle comme une probabilité fiable. Un score n’est utile à la décision que si son comportement a été évalué sur votre tâche.

Encadrer les actions indépendamment du modèle

Un prompt ne remplace pas les permissions du logiciel. Le serveur doit limiter les outils disponibles, vérifier les paramètres et contrôler les droits de l’utilisateur avant chaque action.

Le contenu d’un email ou d’un document reste une donnée externe, même s’il contient une phrase comme « ignore les instructions précédentes ». Le système ne doit pas lui accorder le pouvoir de modifier ses permissions ou de choisir un destinataire d’export.

Pour un premier déploiement, des outils en lecture seule et des réponses préparées pour validation constituent un périmètre observable. Si des écritures sont nécessaires, prévoyez une validation adaptée à leurs conséquences, une protection contre les doublons et une trace des changements.

Ajoutez aussi des limites concrètes : nombre maximal d’étapes, durée d’exécution, coût par traitement et arrêt en cas de répétition. Une intervention humaine doit rester possible lorsque les sources ne permettent pas de conclure.

Comparer le coût d’un dossier correctement terminé

Le prix d’un appel au modèle n’est qu’une composante du coût. Il faut ajouter les recherches, les appels aux outils, les reprises, les contrôles humains et la maintenance des intégrations.

Comparez donc le coût d’un dossier correctement terminé, et non celui d’une réponse générée. Une solution moins chère par appel peut devenir plus coûteuse si ses réponses demandent davantage de relecture.

La latence compte également. Une recherche autonome en plusieurs étapes peut être acceptable pour préparer un rapport, mais pénalisante pour une réponse attendue pendant un échange client.

Une progression simple pour décider

Commencez par le parcours le plus contraint qui permet de rendre le service. Testez d’abord les règles seules, puis une étape IA ciblée. N’ajoutez la sélection autonome d’outils que si les limites du parcours prédéfini sont clairement identifiées.

Cette progression fournit une comparaison utile : ce que l’IA améliore, ce qu’elle complique et les situations dans lesquelles elle doit s’effacer. Pour organiser cette première version, définissez une hypothèse, un parcours utilisateur complet et un protocole de test avant le développement.

Vous hésitez entre un workflow, un assistant et un agent ? Apportez-nous quelques demandes représentatives. Nous pourrons partir du travail à accomplir et des actions autorisées, avant de choisir l’architecture.