IA agentique et applications web : usages, risques et méthode

Les applications web ont longtemps été conçues autour d’un principe simple : une personne ouvre un écran, remplit un formulaire, clique sur un bouton et consulte un résultat. L’essor de l’IA agentique introduit une autre manière d’utiliser un service numérique. Par « IA agentique », on désigne ici un système capable d’interpréter un objectif, d’utiliser éventuellement des outils et d’enchaîner des étapes avec un degré variable d’autonomie.

Un agent IA peut rechercher des informations dans plusieurs sources, préparer une action et, dans certains cas, l’exécuter.

Faut-il pour autant remplacer les applications web par des chatbots ? Certainement pas. Pour certaines entreprises, le changement important est ailleurs : une application web devra peut-être répondre à deux modes d’usage. Elle devra rester claire et accessible pour les humains, tout en exposant des actions et des informations que des agents pourront utiliser de manière contrôlée.

Une application web ne sera plus seulement un écran

Un agent IA ne se contente pas de produire une réponse. Selon les outils auxquels il est connecté, il peut rechercher dans une base documentaire, consulter un agenda, qualifier une demande dans un CRM ou préparer un message. Les interfaces web deviennent alors une porte d’accès à des services et à des workflows, et non plus seulement un ensemble de pages à parcourir.

Le W3C explore ces scénarios dans des travaux et présentations prospectifs : les agents pourraient devenir un intermédiaire entre l’utilisateur et les services en ligne. Ces travaux évoquent notamment des fonctions structurées -par exemple « rechercher une commande » ou « créer une demande »- qu’un site pourrait exposer, afin qu’un agent ne soit pas obligé de deviner le fonctionnement d’une interface à partir de son apparence. Il ne s’agit pas encore d’une norme web adoptée, ni d’une feuille de route définitive.

Cette évolution ne condamne pas les écrans classiques. Elle renforce au contraire l’importance d’une application bien structurée : données compréhensibles, actions explicites, droits correctement séparés et parcours capables d’indiquer ce qui vient d’être fait.

Trois niveaux d’automatisation à ne pas confondre

Toutes les applications n’ont pas besoin d’un agent autonome. Il est utile de distinguer trois niveaux.

1. L’assistance informative

L’application répond à une question, retrouve une information ou résume un document. Elle ne modifie pas les données métier. C’est souvent le meilleur point de départ : le risque est limité et les résultats peuvent être vérifiés par l’utilisateur.

2. Le workflow automatisé

Les étapes sont connues à l’avance. Par exemple : recevoir une demande, extraire quelques informations, vérifier des critères, créer une tâche et demander une validation. L’intelligence artificielle peut faciliter l’extraction ou la qualification, tandis que le déroulement reste largement déterministe.

3. L’agent qui choisit certaines étapes

L’agent analyse la situation, sélectionne les outils utiles et adapte son parcours. Cette souplesse peut être intéressante lorsque les demandes sont variées, mais elle augmente aussi l’incertitude, la latence, le coût et le besoin de supervision.

Dans son guide consacré aux agents, Anthropic recommande de commencer par l’architecture la plus simple. C’est un retour d’expérience d’un fournisseur, pas une règle universelle. Pour une PME, un processus bien défini sera souvent plus contrôlable et plus facile à auditer qu’un agent auquel on demanderait de gérer un parcours complet.

Prenons un exemple : une demande reçue par le service commercial peut être résumée et classée par une IA, puis transformée en fiche CRM après validation d’un collaborateur. Cette première étape est très différente d’un agent autorisé à modifier seul les données client, à envoyer des messages et à créer des engagements commerciaux.

Le vrai chantier : connecter les bons outils

Un agent n’apporte pas beaucoup de valeur s’il ne peut agir que sur une conversation isolée. Son intérêt apparaît lorsqu’il peut accéder aux bonnes informations et aux bonnes fonctions : CRM, messagerie, agenda, stockage documentaire, outil de support ou application de facturation.

Cela ne signifie pas qu’il faut donner un accès général à tous les systèmes. Chaque intégration devrait préciser :

• les actions autorisées ;
• les données accessibles ;
• l’identité de la personne à l’origine de la demande ;
• la durée de l’autorisation ;
• les limites de volume et de coût ;
• les traces conservées ;
• les conditions de validation humaine.

Des protocoles comme le Model Context Protocol et les travaux autour de l’interopérabilité entre agents cherchent à faciliter ces connexions. Ils évoluent encore : leur adoption, leur compatibilité et leurs mécanismes de sécurité ne sont pas garantis dans tous les environnements. Ils ne remplacent ni l’authentification, ni les règles métier, ni la responsabilité de l’entreprise. Une intégration plus simple à brancher peut aussi rendre plus simple l’accès à un outil mal protégé.

L’interface devra montrer ce que fait l’agent

Une interface conversationnelle peut être pratique pour formuler une demande, mais elle ne doit pas masquer le déroulement du traitement. Lorsqu’un agent intervient dans une application web, l’utilisateur doit pouvoir comprendre :

• quel objectif a été interprété ;
• quelles informations ont été utilisées ;
• quelles actions ont déjà été exécutées ;
• quelle action est proposée ensuite ;
• ce qui nécessite une validation ;
• comment interrompre ou annuler le processus.

Cette transparence est particulièrement importante pour l’envoi d’un message, la modification d’une fiche client, la création d’un engagement ou toute opération difficile à annuler. Une validation humaine n’est utile que si la personne dispose des informations nécessaires pour décider réellement.

Les interfaces classiques restent indispensables. Elles sont souvent plus rapides pour une tâche connue, plus accessibles pour certains utilisateurs et plus faciles à contrôler. Une bonne application web combinera donc plusieurs modes d’interaction plutôt que d’imposer une conversation avec l’IA.

De nouveaux risques pour les applications web

Un agent connecté à des outils peut être influencé par une instruction malveillante placée dans une page web, un e-mail ou un document. C’est le principe de l’injection indirecte : un contenu consulté par l’agent peut tenter de lui faire exécuter une action qui ne correspond pas à la demande de l’utilisateur.

Les risques ne s’arrêtent pas là. Il faut aussi anticiper :

• l’accès excessif à des données clients ou internes ;
• l’utilisation d’un mauvais outil ou d’un mauvais compte ;
• l’exécution d’une action avec trop de privilèges ;
• la propagation d’une erreur dans plusieurs applications ;
• la fuite de données dans les journaux ou les contextes envoyés au modèle ;
• l’augmentation imprévisible du nombre d’appels et donc du coût.

L’OWASP propose, dans un référentiel de menaces et de bonnes pratiques — et non dans une norme réglementaire — des catégories comme le détournement des objectifs, le mauvais usage des outils, les abus d’identité et de privilèges, l’empoisonnement de la mémoire ou du contexte et les défaillances en cascade parmi les risques propres aux applications agentiques.

La réponse ne consiste pas à chercher un modèle qui ne ferait jamais d’erreur. Elle consiste à réduire les conséquences d’une erreur : permissions minimales, comptes séparés, validation des entrées et des sorties, limites de durée et de budget, journalisation, tests d’injection et mode manuel de secours.

Données personnelles et responsabilité

Une application agentique peut réunir en quelques secondes des informations issues de plusieurs systèmes. Cette capacité est utile, mais elle rend plus difficile la maîtrise des flux de données. Une PME doit savoir quelles données sont transmises, à quel fournisseur, pour quelle finalité, pendant combien de temps et avec quelles mesures de protection.

La CNIL et l’EDPB rappellent que l’utilisation de données personnelles dans les systèmes d’intelligence artificielle doit être examinée au regard du RGPD. Le fait qu’une donnée soit accessible ou publiée ne suffit pas à écarter les obligations applicables. Selon la qualification du système et son usage, l’AI Act peut entraîner des obligations de transparence, de documentation, de supervision humaine, de gestion des risques ou de robustesse, avec une application progressive.

La responsabilité ne disparaît pas parce qu’une décision a été préparée par un agent. L’organisation devrait identifier clairement les responsabilités, conserver des traces proportionnées et prévoir une possibilité de correction ; les obligations précises dépendent du traitement, du secteur et du niveau de risque. Dans les domaines sensibles, la qualification juridique et l’analyse des risques doivent précéder le déploiement. Ces indications sont informatives et ne constituent pas un avis juridique.

Comment préparer une application web « agent-ready » ?

Il n’est pas nécessaire de reconstruire tout un système d’information pour commencer. Une démarche progressive est préférable.

1. Cartographier les tâches

Lister les demandes répétitives, les données mobilisées, les outils utilisés et les conséquences d’une erreur. Une tâche de recherche documentaire n’a pas le même niveau de risque qu’une suppression ou qu’un paiement.

2. Choisir un cas mesurable et réversible

Commencer par une assistance interne, une qualification ou une préparation soumise à validation. Définir avant le test le temps attendu, le taux d’erreur acceptable, le coût par tâche et les situations qui imposent un transfert humain.

3. Exposer des actions explicites

Une API documentée et des fonctions métier clairement définies sont en général plus contrôlables qu’une automatisation qui reproduit des clics dans une interface ; elles doivent néanmoins être testées et sécurisées. Chaque action doit être validée, limitée et journalisée.

4. Séparer la proposition de l’exécution

L’agent peut préparer une modification ou un message. L’application décide ensuite si l’action est autorisée, si une confirmation est requise et si l’identité de l’utilisateur est suffisante.

5. Tester avant d’élargir

Tester les erreurs de contexte, les instructions malveillantes, les droits insuffisants, les pannes de connecteur et les dépassements de budget avec des données non sensibles. Ne donner accès à de nouvelles fonctions qu’après l’analyse des résultats.

L’avenir ne sera pas sans interfaces

L’IA agentique pourrait multiplier les manières d’utiliser les applications web si son adoption se confirme. Un utilisateur pourra demander un résultat plutôt que suivre chaque étape, tandis qu’un agent pourra coordonner plusieurs services. Mais les applications qui résisteront le mieux à cette évolution ne seront pas celles qui auront simplement ajouté un chatbot.

Elles seront lisibles, accessibles, bien documentées et capables de distinguer une information, une proposition et une action. Elles conserveront des permissions limitées, des validations compréhensibles et un fonctionnement de secours lorsque le modèle ou un connecteur devient indisponible.

Pour une PME, la bonne question n’est donc pas : « Quel agent va remplacer notre application ? » Il faut plutôt demander : « Quelles tâches pouvons-nous rendre plus simples, avec quelles données, quelles limites et quelle responsabilité ? » Une application prête à accueillir des agents devrait d’abord être une application métier fiable, gouvernable et utile aux humains.