Un directeur des opérations nous a montré deux montages pour le même processus. Le premier : un workflow n8n d'une quarantaine de nœuds, avec une vingtaine de branches conditionnelles, qui traitait les demandes entrantes du service client. Le second : le même processus confié à un agent, à qui on décrit l'objectif et à qui on donne cinq outils. Le premier tournait depuis un an et plus personne n'osait y toucher. Le second marchait huit fois sur dix, et personne ne savait expliquer les deux autres.
Aucun des deux n'était le bon choix, parce que la question n'avait pas été posée dans le bon ordre. « IA agentique ou automatisation » n'est pas un arbitrage technologique. C'est une question sur le processus : combien de chemins différents mènent au résultat, et êtes-vous capable de les écrire. Voici le critère, appliqué à quatre processus réels, et le test à faire avant d'engager un budget.
IA agentique : ce que le mot change, en pratique
Laissons la définition de côté et regardons ce qui diffère à l'exécution. Trois propriétés séparent une IA agentique d'une automatisation, et elles se constatent en lisant le montage.
On lui donne un objectif, pas une procédure. Une automatisation reçoit une suite d'étapes : lire la ligne, vérifier le champ, appeler l'API, écrire le résultat. Un agent reçoit un but — « réponds à cette demande client en t'appuyant sur nos procédures » — et c'est lui qui décide des étapes.
Il choisit ses outils et leur ordre. Vous lui exposez des capacités : chercher dans la base documentaire, lire une fiche client, créer un ticket, escalader. À chaque tour, il décide laquelle appeler et avec quels paramètres, au vu de ce qu'il a déjà obtenu. Deux dossiers voisins peuvent produire deux séquences différentes.
Il tourne en boucle jusqu'à un critère d'arrêt. Observer le résultat de son dernier appel, décider du suivant, recommencer. C'est cette boucle qui fait l'autonomie, et c'est elle qui rend le comportement non reproductible.
La conséquence pratique tient en une phrase : une automatisation exécute un chemin, un agent en cherche un. Vous n'achetez pas une technologie plus avancée, vous achetez le droit de ne pas écrire le chemin — et vous perdez la garantie de savoir lequel sera pris.
Le critère de décision : pouvez-vous écrire l'arbre ?
Un seul test tranche la majorité des cas. Prenez le processus et essayez d'écrire son arbre de décision à la main, sur une feuille. Pas le code : les conditions et leurs branches.
Si vous y arrivez, la réponse est : des règles. Un arbre que vous savez dessiner est un arbre qu'un workflow exécutera plus vite, pour moins cher, et de façon identique à chaque passage. Appeler un modèle pour reproduire une condition que vous savez écrire, c'est payer une inférence pour faire un test sur un champ.
Si vous n'y arrivez pas, cherchez d'abord pourquoi. Il y a deux raisons possibles, et une seule justifie un agent.
Raison 1 : le processus n'a jamais été décrit
C'est le cas le plus fréquent, et le plus mal diagnostiqué. L'arbre est écrivable, simplement personne ne l'a écrit. Les règles vivent dans la tête de deux personnes, elles n'ont jamais été formalisées, et l'agent est appelé à la rescousse pour éviter ce travail d'explicitation.
Le problème, c'est qu'un agent ne fait pas disparaître ce travail. Il le déplace dans un prompt, où il devient non testable. Un processus mal décrit confié à un agent produit un agent qui se trompe exactement comme vos équipes se trompent, sans qu'on puisse pointer la ligne fautive. La bonne séquence est l'inverse : écrire les règles, automatiser ce qui est écrit, et regarder ce qui reste.
Raison 2 : l'arbre est inécrivable par nature
Là, l'agent gagne. Trois signes le disent :
- L'entrée est du langage libre. Un mail de client, un compte rendu, un document scanné. Il n'y a pas de champ à tester, il y a un sens à extraire.
- Le nombre de cas est ouvert. Non pas quarante branches, mais une combinatoire que personne ne peut énumérer — et dont une partie n'a encore jamais été vue.
- Le chemin dépend de ce qu'on trouve en route. L'étape trois n'est décidable qu'au vu du résultat de l'étape deux. Un workflow sait le faire avec des branches ; passé quelques niveaux d'imbrication, il devient illisible et plus personne n'y touche.
Un quatrième critère décide ensuite du périmètre, pas de la technologie : ce que coûte une erreur. Plus elle coûte cher, moins l'agent doit exécuter seul — il propose, un humain valide. Cette variable fixe le niveau de supervision, et elle est indépendante des trois précédentes.
Quatre processus, quatre verdicts
Les relances d'impayés : règles
Une facture a une date d'échéance, un montant, un statut de paiement. La relance à J+7 n'est pas un jugement, c'est une date. Le seul endroit où un modèle apporte quelque chose, c'est la rédaction du message quand le client a répondu quelque chose d'ambigu. Le reste est un workflow adossé à un calendrier, et c'est ainsi que nous montons l'automatisation des relances d'impayés. Confier ce processus à un agent, c'est rendre non déterministe un enchaînement qui n'avait aucune raison de l'être.
La qualification des leads entrants : mixte
Le formulaire donne des champs : taille d'entreprise, secteur, budget déclaré. Ça se teste. Le champ « décrivez votre besoin » ne se teste pas : c'est du texte libre, et c'est pourtant là que se trouve l'information qui décide si le lead vaut un appel. Le montage qui tient : un workflow déterministe qui fait le scoring sur les champs structurés, et un seul appel au modèle pour ranger l'intention du texte libre dans une liste fermée de catégories. Le modèle rend une étiquette, pas une décision.
Le support de niveau 1 : agent, à périmètre serré
Les demandes arrivent en langage libre, elles se recoupent sans se ressembler, et la réponse dépend à la fois de la base de connaissance et de la fiche du client. L'arbre est inécrivable : c'est un cas d'agent. À condition de borner son périmètre — il cherche, il rédige, il propose un geste commercial, mais il ne l'exécute pas au-delà d'un seuil. Au-delà, il escalade.
Le reporting de conformité : règles
Rassembler des preuves depuis quatre systèmes, vérifier qu'aucune ne manque, produire un document daté. Chaque étape est une requête. Une IA agentique y ajouterait de l'incertitude sur un livrable dont toute la valeur tient à ce qu'il soit reproductible d'un trimestre à l'autre.
Le motif se lit sur les quatre : l'agent gagne là où l'entrée est du texte et le chemin imprévisible. Il perd partout où la donnée est structurée et la règle connue.
Le montage mixte : le modèle appelé là où il y a du jugement
Dans la pratique, le bon dispositif est rarement l'un ou l'autre. C'est un workflow déterministe qui garde le contrôle du processus, et qui appelle un modèle sur les deux ou trois étapes qui demandent du jugement.
Ce montage a quatre avantages qu'aucune architecture purement agentique ne donne.
- Il est testable. Les étapes déterministes se vérifient une fois pour toutes. Il ne reste à surveiller que les appels au modèle.
- Son coût est prévisible. Vous connaissez le nombre d'appels par dossier, donc le volume de tokens. Un agent en boucle, non : la même tâche peut coûter trois appels ou quinze.
- Il se répare. Quand ça casse, on sait à quel nœud. Un agent qui se trompe demande de relire une trace pour reconstituer son raisonnement.
- Il se durcit avec le temps. Chaque fois qu'un cas traité par le modèle se révèle être une règle stable, on le sort du prompt et on le passe en condition. Le périmètre confié au jugement se réduit à mesure que le processus mûrit, au lieu de grossir.
C'est aussi le montage qui a la meilleure structure de coût. Le poste qui dérape sur un agent n'est pas la construction, c'est la facture mensuelle d'inférence et le temps humain de supervision : nous avons posé la mécanique de calcul dans notre décomposition du prix d'un agent IA en production.
Ce que l'autonomie coûte en plus
Un agent n'est pas une automatisation en mieux. C'est une automatisation qui échange de la prévisibilité contre de la couverture. Quatre lignes au débit.
Le non-déterminisme. Deux exécutions sur la même entrée peuvent diverger. Vos tests ne peuvent plus comparer une sortie attendue à une sortie obtenue ; ils doivent vérifier des propriétés — le champ est rempli, l'identifiant existe vraiment en base, le montant est dans la plage autorisée.
Le coût variable. Le nombre d'appels dépend du dossier. Sans plafond d'itérations et sans plafond de dépense par tâche, un seul cas pathologique tourne en boucle et coûte plus qu'une journée entière de production normale.
L'observabilité obligatoire. Un agent sans traces est un agent qu'on débranche à la première anomalie, faute de pouvoir expliquer ce qui s'est passé. Il faut journaliser les entrées, les outils appelés, leurs réponses et la décision finale. Ce n'est pas une option, et c'est du travail de construction.
La dérive silencieuse. Un workflow qui casse s'arrête et alerte. Un agent qui se dégrade continue de rendre des résultats plausibles. Le seul remède est une mesure continue : taux d'escalade, taux de correction humaine, coût par dossier. Sans indicateur suivi, la dégradation se découvre par une réclamation client.
Tester avant de décider : vingt dossiers, deux montages
Le débat se tranche par la mesure, et la mesure est à portée en quelques jours.
Prenez vingt dossiers réels et représentatifs, dont au moins cinq cas tordus — ceux dont vos équipes disent « celui-là, il faut le regarder ». Traitez-les à la main une fois, et notez la bonne réponse pour chacun. Vous avez votre référentiel.
Montez ensuite les deux versions dans leur forme la plus simple. La version à règles : les cinq ou six conditions les plus évidentes, sans chercher l'exhaustivité. La version avec appel au modèle : un prompt, les outils nécessaires, rien de plus. Faites passer les vingt dossiers dans chacune.
Quatre nombres en sortent, et ils suffisent à décider :
- la couverture : combien de dossiers traités correctement sans intervention ;
- le taux d'escalade : combien sont renvoyés à un humain, ce qui est un bon comportement et pas un échec ;
- le taux d'erreur silencieuse : combien rendent une réponse fausse sans la signaler. C'est le seul nombre disqualifiant ;
- le coût par dossier : appels au modèle et tokens consommés, divisés par le volume traité.
Si la version à règles couvre quinze dossiers sur vingt et escalade les cinq autres, vous n'avez pas besoin d'un agent : vous avez besoin de traiter cinq cas à la main, ou d'un appel au modèle sur la seule étape qui bloque. Si elle en couvre six quand l'agent en couvre seize, la question est tranchée aussi — et vous repartez avec le référentiel qui servira à surveiller la dérive.
Les six questions à trancher avant de lancer un agent
- L'arbre de décision a-t-il été écrit, au moins une fois ? Si non, ce n'est pas un projet d'agent, c'est un projet de formalisation de processus.
- L'entrée est-elle structurée ou libre ? Des champs appellent des règles. Du texte appelle un modèle.
- Que coûte une erreur, chiffré ? C'est ce montant qui décide si l'agent exécute ou s'il propose.
- Quel est le critère d'arrêt, et quel est le plafond ? Nombre d'itérations et dépense maximale par dossier, écrits dans la configuration et pas dans une intention.
- Qui traite ce que l'agent escalade, et combien d'heures par semaine ? Avec un nom en face. Un dispositif dont la file d'escalade n'a pas de propriétaire se débranche en trois mois.
- Quel indicateur mesure le succès à 90 jours ? Couverture, erreur silencieuse, coût par dossier. Un chiffre relevé avant le démarrage, sinon la rentabilité restera une opinion.
Si vous hésitez sur un processus précis, c'est l'exercice qu'on fait en premier au cadrage de nos agents IA sur mesure : l'arbre sur une feuille, les vingt dossiers, puis le verdict. Parfois c'est un agent. Souvent c'est un workflow avec deux appels au modèle bien placés, et le dire tôt fait gagner plus de temps que n'importe quel prompt.
