Pendant deux ans, la question posée à l’IA générative était : « que sais-tu répondre ? » Elle devient : « que peux-tu faire ? » Le déplacement est considérable. Un assistant qui se trompe produit une réponse à corriger. Un agent qui se trompe produit une action à rattraper — un ticket mal routé, une commande créée en double, un accès ouvert à tort. Ce n’est plus le même métier, et ce ne sont plus les mêmes exigences.
Cette bascule ne dépend pas d’abord de la puissance des modèles. Elle dépend de ce qui les entoure : le contexte auquel ils accèdent, les outils qu’ils peuvent appeler, les règles qui les encadrent, les workflows dans lesquels ils s’inscrivent et les contrôles qui les surveillent. Autrement dit, elle relève de l’architecture et de la gouvernance du système d’information, pas de la seule technologie d’IA.
De l’assistant à l’agent
Trois niveaux se sont succédé, et ils coexistent aujourd’hui dans la plupart des organisations.
L’assistant répond. On lui pose une question, il produit un texte. Il ne connaît du contexte que ce qu’on lui fournit dans la conversation, et il ne touche à rien. Sa valeur est réelle mais bornée : il fait gagner du temps de rédaction et de recherche.
Le copilote assiste dans un outil. Il voit ce que l’utilisateur voit — un ticket ouvert, un document en cours, une fiche client — et propose : une reformulation, un classement, une réponse type. La décision et le geste restent humains.
L’agent poursuit un objectif. Là où le copilote propose, l’agent enchaîne. Concrètement, un agent sait :
- interpréter un objectif exprimé en langage naturel ou déclenché par un événement ;
- rassembler le contexte dont il a besoin, en interrogeant des documents et des systèmes ;
- appeler des outils — une API, une requête, une transaction applicative ;
- enchaîner plusieurs étapes, en tenant compte du résultat de chacune ;
- exécuter une action qui modifie l’état d’un système ;
- s’arrêter et demander une validation humaine lorsque les conditions le prévoient.
Ce dernier point est souvent traité comme un détail. C’est en réalité le cœur du sujet : un agent utile en entreprise n’est pas un agent qui décide de tout, c’est un agent qui sait où s’arrêter.
Pourquoi les workflows deviennent essentiels
Un agent livré à lui-même est une démonstration, pas un dispositif de production. Pour produire de la valeur durablement, il doit s’inscrire dans quelque chose qui existait avant lui.
Il lui faut un processus : une séquence d’étapes connue, avec un début, une fin et des états intermédiaires identifiables. Il lui faut des règles — ce qui est permis, ce qui ne l’est pas, dans quelles conditions. Il lui faut des droits : un agent agit toujours au nom de quelqu’un ou de quelque chose, et le périmètre de ce mandat doit être explicite, restreint et révocable. Il lui faut des systèmes existants à interroger et à mettre à jour, avec les contraintes d’intégration que cela suppose. Il lui faut une logique d’escalade, pour les situations qu’il ne sait pas traiter — et il faut qu’il sache les reconnaître. Il lui faut enfin des contrôles : des vérifications avant action, des traces après.
Le partage est simple à formuler. L’agent apporte la capacité de raisonnement et d’action ; le workflow apporte le cadre opérationnel. L’un sans l’autre ne tient pas : un agent sans workflow est ingouvernable, un workflow sans agent reste rigide dès que la situation sort du cas nominal.
C’est pourquoi les organisations qui avaient déjà investi dans la structuration de leurs processus — catalogues de services, circuits de validation, référentiels à jour — avancent nettement plus vite sur l’IA agentique. Non parce qu’elles ont de meilleurs modèles, mais parce que le cadre existait.
Les principaux cas d’usage
Les usages qui tiennent en production se ressemblent : un processus déjà structuré, des données accessibles, un périmètre d’action délimité.
Opérations IT et ITSM. C’est le terrain le plus mûr, parce que les processus y sont documentés et les outils instrumentés. Un agent peut qualifier un incident à partir de sa description, le catégoriser, l’enrichir avec l’historique de l’équipement ou de l’utilisateur, le router vers la bonne équipe, chercher dans la base de connaissances, proposer une résolution, déclencher une action de remédiation connue — redémarrage d’un service, réinitialisation d’un compte — et escalader lorsque le diagnostic reste incertain. La qualification et le routage sont souvent les premiers gains : ils sont fréquents, peu risqués et mesurables.
Services internes. Gestion des demandes, onboarding d’un nouvel arrivant, questions RH, demandes d’achat, rapprochements en finance, demandes d’accès et d’habilitations. Ces processus traversent plusieurs applications et comportent beaucoup d’étapes de collecte et de relance — exactement ce qu’un agent adossé à un portail de services traite bien. Les habilitations, en revanche, appellent une prudence particulière : ouvrir un droit est facile, en mesurer les conséquences l’est moins.
Service client. Qualification d’une demande entrante, recherche du contexte dans le dossier et l’historique, préparation d’une réponse soumise à un conseiller, exécution des actions de suivi, mise à jour du dossier. Le schéma le plus solide reste celui où l’agent prépare et où l’humain valide, au moins tant que la qualité mesurée ne justifie pas d’aller plus loin.
Processus métiers. Collecte d’informations auprès de plusieurs sources, contrôle de cohérence, préparation d’un dossier de validation, orchestration entre applications qui ne se parlent pas directement. C’est souvent là que l’écart avec l’automatisation classique est le plus net : les règles fixes traitent le cas nominal, l’agent absorbe la variabilité.
Orchestration : le vrai sujet
La valeur ne vient pas du modèle seul. Elle vient de la capacité à faire tenir ensemble des données, des outils, des APIs, des workflows, plusieurs agents éventuellement, et des points de validation humaine. C’est un problème d’intégration et de gouvernance avant d’être un problème d’IA.
Cette couche d’orchestration peut s’appuyer sur des environnements que les organisations exploitent déjà : plateformes de gestion de services et de workflows comme ServiceNow, outils d’automatisation comme n8n ou Power Automate, services d’orchestration des grands fournisseurs cloud, ou APIs métier exposées par le système d’information. Aucune de ces plateformes ne règle à elle seule la question : elles fournissent un socle d’exécution, de traçabilité et de droits, sur lequel la logique agentique vient se poser.
Le choix de ce socle se pose dans les mêmes termes que n’importe quelle décision d’architecture : ce qui existe déjà, ce que les équipes savent exploiter, ce que le contrat de service exige, ce que la réversibilité impose. Nous l’instruisons de façon indépendante, sans présupposé d’éditeur — c’est le sens de notre travail sur l’intégration au système d’information.
Jusqu’où automatiser ?
Toutes les actions ne se confient pas de la même manière. Il est utile de raisonner par niveaux d’autonomie croissants, et de les attribuer action par action plutôt que globalement.
- Lecture — l’agent consulte, restitue, synthétise. Aucun effet de bord.
- Suggestion — il propose un classement, une réponse, une décision. L’humain choisit.
- Préparation d’action — il constitue le dossier, remplit le formulaire, rédige la demande. Rien n’est envoyé.
- Exécution sous validation — il agit, mais seulement après un accord explicite tracé.
- Exécution autonome — il agit seul, dans un périmètre défini et sous surveillance.
Le niveau retenu dépend de cinq facteurs : le risque attaché à une erreur, la criticité du processus concerné, la réversibilité de l’action — annuler un routage de ticket n’a pas le même coût qu’annuler un paiement —, la qualité des données disponibles, et la traçabilité que le dispositif permet réellement d’obtenir.
Une règle simple s’en déduit : une action irréversible sur un processus critique ne devrait pas dépasser le niveau 4, quelle que soit la qualité mesurée de l’agent. Et l’autonomie se gagne progressivement, à mesure que les mesures s’accumulent — elle ne se décrète pas au démarrage.
Qualité et évaluation des agents IA
Un agent qui agit doit être évalué plus strictement qu’un assistant qui répond. C’est le point que les démonstrations réussies font oublier, et celui qui décide du passage en production.
L’évaluation commence par des critères d’acceptation explicites : qu’est-ce qu’une bonne qualification d’incident, une bonne préparation de dossier, un bon refus de traiter ? Ces critères se traduisent en jeux de tests construits sur des scénarios métier réels, cas limites compris — demandes ambiguës, données manquantes, formulations inhabituelles.
Il faut ensuite éprouver la robustesse : que fait l’agent quand une API ne répond pas, quand un droit lui est refusé, quand deux sources se contredisent ? Deux familles d’erreurs méritent un traitement distinct — les hallucinations, où l’agent produit une information non fondée, et les erreurs d’outil, où il appelle la bonne fonction avec de mauvais paramètres, ou la mauvaise fonction. La seconde est plus dangereuse, parce qu’elle produit un effet réel.
Ces jeux d’évaluation deviennent ensuite des tests de non-régression : un changement de modèle, de prompt, d’outil ou de version de plateforme peut dégrader silencieusement un comportement qui fonctionnait. L’évaluation humaine reste nécessaire là où le jugement métier ne se réduit pas à une règle — mais elle doit être échantillonnée et cadrée, pas laissée à l’impression générale.
En production, le dispositif repose sur trois piliers : le monitoring des taux d’échec, d’escalade et de reprise humaine ; la supervision par des équipes qui savent interrompre un agent et reprendre la main ; et la traçabilité de chaque décision — quel contexte, quel outil appelé, quel paramètre, quel résultat, quelle validation. Sans cette trace, aucun incident n’est analysable, et aucune responsabilité n’est établissable.
C’est exactement le périmètre de notre expertise en évaluation et qualité des systèmes IA, et le prolongement naturel des pratiques de tests et de recette que nous appliquons aux programmes de transformation.
Une architecture de référence
La chaîne se lit de gauche à droite, et chaque maillon peut faire échouer l’ensemble.
Utilisateur ou événement — une demande formulée, ou un déclencheur automatique : ticket créé, seuil franchi, dossier reçu.
Agent IA — interprète l’objectif, décide de la marche à suivre, choisit les outils.
Contexte et RAG — documents, référentiels, historique : ce que l’agent doit savoir pour ne pas inventer.
Outils et APIs — les gestes qu’il peut poser, strictement énumérés, avec les droits qui vont avec.
Workflow — le cadre : états, règles, transitions, escalades.
Validation — le point d’arrêt humain, quand le niveau d’autonomie retenu l’exige.
Action — l’effet réel sur un système, et son accusé de réception.
Monitoring — la mesure continue, qui alimente à la fois la supervision quotidienne et les décisions d’élargissement du périmètre.
Une trajectoire pragmatique
Six temps, dans cet ordre, pour éviter aussi bien le pilote sans suite que l’industrialisation prématurée.
Identifier. Repérer les processus à fort volume, déjà structurés, où la variabilité pénalise l’automatisation classique. Le critère n’est pas l’appétence technologique, c’est la répétition et la friction.
Cadrer. Délimiter le périmètre d’action, les droits, le niveau d’autonomie visé et les critères d’acceptation. C’est ici que se décide l’essentiel du risque.
Prototyper. Construire une version restreinte sur des cas réels, pour mesurer l’écart entre l’intention et le comportement observé — pas pour démontrer la faisabilité, qui est acquise.
Orchestrer. Raccorder l’agent aux workflows, aux systèmes et aux circuits de validation existants. C’est l’étape la plus longue, et celle que les démonstrations escamotent.
Évaluer. Constituer les jeux de tests, mesurer, corriger, réévaluer. Aucun élargissement d’autonomie sans mesure préalable.
Industrialiser. Superviser, tracer, maintenir, faire évoluer — et traiter l’agent comme un composant applicatif ordinaire, avec son cycle de vie et sa dette.
Ce qui décide vraiment du résultat
Le passage de l’assistance à l’exécution ne se joue pas dans la puissance des modèles. Il se joue dans la qualité de l’orchestration, dans la précision des règles, dans la solidité des contrôles et dans l’intégration au système d’information. Les organisations qui réussiront ce passage ne seront pas celles qui auront adopté la technologie le plus tôt, mais celles qui auront su délimiter ce qu’elles confient, mesurer ce qui se produit, et garder la main sur ce qui compte.
C’est un sujet d’architecture, de processus et de gouvernance — c’est-à-dire un sujet de conseil autant que de technologie.
Nous instruisons ces trajectoires au croisement de deux expertises : les agents IA et l’automatisation intelligente. Si le sujet se pose chez vous, le plus utile est d’en parler à partir de vos propres cas d’usage.
