Le formulaire n'a jamais été le produit
Beaucoup d'applications de travail obligent une personne à traduire une intention simple en suite de recherches, de champs, de tickets et de validations. « Merci de modifier l'adresse de ce client » peut devenir la recherche du bon dossier, un formulaire rempli de codes obscurs, un message à une autre équipe, puis une vérification tardive que la modification a réellement eu lieu. Lorsque cette expérience est pénible, un agent IA semble être le remplaçant évident de l'application.
Cette conclusion confond la porte d'entrée et le bâtiment derrière elle. Un agent peut rendre la demande plus facile à formuler et exécuter un ensemble limité d'étapes. Il a toujours besoin de données fiables, du droit d'agir, de règles pour les exceptions et d'une trace durable de ses actions. Ce ne sont pas des détails d'interface conversationnelle. Ce sont des choix de produit, d'exploitation et de gouvernance.
La question utile n'est donc pas : « Quelle application les agents vont-ils tuer ? » C'est : « Quel travail existe seulement parce que les personnes compensent en permanence un workflow médiocre ? » Cette question conduit à une meilleure discussion de conception et à une décision d'investissement plus honnête.
Faits et éléments vérifiables : les agents créent une nouvelle surface de contrôle
Le cadre de gestion des risques IA du NIST considère l'IA comme un système sociotechnique, et non comme un modèle isolé. Ses quatre fonctions, gouverner, cartographier, mesurer et gérer, invitent les équipes à examiner les personnes, le contexte, les données et les conséquences autour du système. Le profil du NIST consacré à l'IA générative applique cette logique aux systèmes qui produisent du contenu et interagissent avec des utilisateurs.
Ce cadrage devient essentiel lorsqu'un agent appelle des outils. Le Top 10 de l'OWASP pour les applications utilisant des LLM décrit notamment l'injection de prompt et l'autonomie excessive. Un système relié à des outils peut recevoir des instructions non fiables, entreprendre une action au-delà de son périmètre ou exposer des informations par une connexion mal conçue. Une réponse fluide ne prouve pas que ces frontières sont solides.
Le contexte juridique et économique invite aussi à ne pas présenter l'agent comme un substitut magique à chaque application. L'AI Act européen adopte une approche fondée sur le risque ; les responsabilités applicables dépendent de la finalité prévue et du rôle du système. Le Stanford AI Index suit de son côté l'adoption et les éléments économiques. Ces deux références rappellent qu'un intérêt massif ou un usage répandu ne prouvent pas qu'un workflow précis est fiable, utile ou prêt à fonctionner avec autonomie.
Analyse : ce qu'un agent change réellement
Un agent est surtout utile lorsqu'il retire le travail de traduction entre l'intention d'une personne et une tâche bien définie. Il peut réunir des informations issues de systèmes autorisés, appliquer des règles déjà explicitées par l'organisation, préparer une proposition, poser une question précise lorsqu'une donnée manque et diriger une exception vers la bonne personne. La conversation visible n'est que la porte d'entrée du workflow.
C'est pourquoi les agents révèlent si vite les mauvais processus. Imaginons un collaborateur du support qui recopie la même information client dans trois systèmes. Un agent peut supprimer cette répétition. Mais si ces systèmes ne s'accordent pas sur le dossier faisant autorité, l'agent a mis au jour un problème de gouvernance des données, sans le résoudre. Si finance et support interprètent une règle différemment, l'agent ne fait qu'exécuter l'ambiguïté plus vite.
Le passage des démos aux vrais workflows d'agents IA suppose donc de définir la mission avant de célébrer le modèle. Écrivez le déclencheur, les données autorisées, le résultat attendu, les actions permises et la condition qui envoie le cas ailleurs. Cette spécification paraît moins spectaculaire qu'une démo, mais c'est là qu'un produit utile commence.
Analyse : les applications portent toujours des responsabilités nécessaires
Les applications établies ne sont pas de simples écrans que les personnes supportent. Elles portent souvent le système de référence, les contrôles d'identité et de droits, les règles transactionnelles, l'historique d'audit, les rapports, les obligations de conservation et des données réconciliées. Un agent peut rendre ces capacités plus simples à utiliser ; une conversation ne les remplace pas.
Le schéma le plus solide au départ consiste généralement à placer l'agent devant l'application, plutôt qu'à lui demander de jouer l'application. L'agent reçoit la demande courante, explique les informations nécessaires et prépare ou réalise uniquement les actions autorisées. Le produit sous-jacent enregistre la modification et conserve les contrôles. Un humain examine les cas inhabituels, sensibles ou contestés.
Cette répartition rend aussi les incidents plus faciles à analyser. L'équipe peut voir quel système a fourni un fait, quelle règle a été appliquée, quelle action a été proposée, qui a validé une exception et comment annuler une erreur. Sans cette chaîne, « l'agent s'en est occupé » n'est pas une réponse opérationnelle.
Contre-argument et limites : parfois, l'écran est le meilleur outil
Les agents ne sont pas la meilleure interface pour toutes les tâches. Une personne a besoin d'un écran lorsqu'elle doit comparer beaucoup d'options, examiner une chronologie, modifier un dossier dense ou apprendre un processus grâce à des repères visuels stables. Un analyste achats qui évalue des fournisseurs ne devrait pas devoir reconstituer un tableau depuis une conversation. Un spécialiste de la paie ne devrait pas s'en remettre à un résumé en langage naturel pour vérifier une modification irréversible.
Un agent ne doit pas non plus devenir un contournement pour une application qui a besoin d'une maintenance produit ordinaire. Un libellé confus, un filtre de recherche défaillant ou l'absence d'action groupée peuvent mériter une amélioration directe de l'interface. Ajouter un agent par-dessus peut cacher la douleur à quelques personnes tout en la conservant pour les autres. Cela crée aussi un second parcours à tester, sécuriser, maintenir et expliquer.
Le niveau de risque change également la réponse. Un agent de rédaction sans accès à des systèmes sensibles peut fonctionner avec un cadre léger. Un agent qui modifie un compte client, formule une recommandation de prix ou déclenche un paiement exige des limites explicites, une journalisation et une véritable voie d'escalade. L'autorité d'un agent doit être explicite ; sans cela, l'autonomie n'est qu'un mot plus agréable pour désigner une exposition non maîtrisée.
Mon point de vue : les meilleurs produits proposeront plusieurs interfaces
Je n'anticipe pas un monde sans applications. J'anticipe des produits solides qui exposent leurs capacités par l'interface adaptée au travail. Utilisez un écran pour comparer et inspecter. Utilisez un workflow structuré lorsque le contrôle, la prévisibilité et la formation comptent. Utilisez un agent lorsqu'une personne a besoin d'aide pour exprimer son intention ou réaliser une tâche bornée entre des systèmes connus.
L'erreur stratégique serait de faire de « l'agent » l'objectif. L'objectif est de réduire le travail évitable, de clarifier les décisions et d'améliorer le service sans perdre la responsabilité. Un agent mérite sa place lorsqu'il rend ce résultat plus probable. Il ne la mérite pas seulement parce qu'il donne une allure moderne à une ancienne interface.
Prochaine action pratique : cartographier un parcours avant de remplacer quoi que ce soit
Choisissez une demande fréquente d'un client ou d'un collaborateur. Suivez-la depuis la première phrase prononcée jusqu'au dossier final qui prouve que le travail est terminé. Relevez chaque relais, saisie répétée, contrôle de règle, attente et correction manuelle. Demandez aux personnes qui font le travail où elles perdent du temps et où elles ont besoin de certitude plutôt que de vitesse.
Classez ensuite les constats dans trois catégories. Premièrement, supprimer directement les étapes inutiles. Deuxièmement, améliorer l'application lorsqu'un écran clair ou une règle résout le problème. Troisièmement, identifier une occasion d'agent bornée : une mission avec des données autorisées, un résultat mesurable, des actions définies et un responsable pour les exceptions.
Pour cette troisième catégorie, rédigez un contrat d'exploitation d'une page. Indiquez le déclencheur, les systèmes que l'agent peut lire, les actions qu'il peut réaliser, celles qu'il ne doit jamais réaliser, les preuves qu'il doit conserver et la personne qui peut l'arrêter. C'est une traduction pratique du relais humain décrit dans concevoir un passage de relais humain utile.
L'exercice peut montrer que la bonne réponse n'est pas un agent. C'est un résultat utile. Il évite à l'équipe d'automatiser un désaccord ou de construire une façade conversationnelle autour d'un problème qui exige d'abord un responsable.
Sources
- NIST AI Risk Management Framework(lien externe, nouvel onglet) - cadre de gestion des risques IA de la conception à l'évaluation.
- NIST Generative AI Profile(lien externe, nouvel onglet) - recommandations de gestion des risques propres aux systèmes d'IA générative.
- OWASP Top 10 for LLM Applications(lien externe, nouvel onglet) - risques de sécurité pour les systèmes qui utilisent des grands modèles de langage et des outils.
- Règlement (UE) 2024/1689(lien externe, nouvel onglet) - texte officiel de la réglementation européenne de l'IA fondée sur le risque.
- Stanford AI Index Report 2025 - Economy(lien externe, nouvel onglet) - données d'adoption et économiques utiles pour distinguer l'intérêt de la valeur opérationnelle.
