Par Chahid Naoufel

Publié le · Modifié le · Vérifié le

Les points essentiels

  • Ce guide traite comme scénario de risque la capacité d’un agent web à lire une page, choisir des champs, saisir des valeurs et déclencher des actions.[2]
  • La compatibilité commence par un formulaire accessible et sémantique.[2]
  • CAPTCHA, OTP et confirmations sont des contrôles à évaluer sans les présenter comme garanties universelles.[1][2]
  • Un agent opérant dans une session connectée peut disposer des droits accordés à cette session.[1][2]
  • Nous recommandons une confirmation explicite avant paiement, consentement, publication ou suppression.

Concevoir pour une intention vérifiable

Un parcours agentique ne doit pas être optimisé pour contourner les protections. Il doit rendre l’intention, les données, les erreurs et l’action finale suffisamment explicites pour un humain comme pour un outil d’assistance.[1][2]

La même discipline améliore souvent l’accessibilité : labels associés, types de champs corrects, messages d’erreur reliés et progression compréhensible.[2]

Scénarios à tester sur un agent et un produit identifiés

  • Interprétation de la page ou de sa représentation structurée.[1][2]
  • Association des données disponibles aux champs.[1][2]
  • Échec sur un libellé ambigu, un composant non standard ou un changement de contexte.[1][2]
  • Réaction à des instructions malveillantes présentes dans la page.[1][2]
  • Portée réelle des cookies, de la session et des permissions.[1][2]
  • Écart entre soumission techniquement réussie et intention confirmée de l’utilisateur.[1][2]

Séparer assistance, préparation et engagement

Pré-remplissage

Autorisez la préparation tout en montrant clairement les valeurs et leur provenance.[1][2]

Soumission faible impact

Ajoutez résumé, détection d’erreurs et possibilité d’annulation.

Action sensible

Exigez une confirmation humaine fraîche et liée à l’action exacte.[1][2]

Paiement ou contrat

Ne déléguez pas silencieusement consentement, authentification forte ou acceptation juridique.[1][2]

Tester les principales frictions

Tester les principales frictions
ÉlémentBon signalÉchec fréquent
LabelAssocié au champPlaceholder seul
FormatType et exempleRègle invisible
ErreurMessage lié et actionnableCouleur seule
ÉtapeProgression et résuméContexte perdu
SoumissionAction nomméeBouton générique
ConfirmationObjet et conséquenceValidation implicite

Vérifier quels navigateurs et modes sont réellement disponibles

Fonctions, pays, plateformes, comptes et niveaux d’abonnement évoluent. Consultez la documentation du produit au moment du test et ne transformez pas une démonstration, une annonce ou un prototype abandonné en capacité générale.[1][2]

Suivre le remplissage de bout en bout

Compréhension et préparation

L’agent identifie l’objectif, ouvre la bonne page, associe les données aux champs et demande les éléments manquants. Les libellés, types et relations sémantiques réduisent les interprétations risquées.[2]

Validation et soumission

Le serveur contrôle formats et autorisations, puis la page présente un résumé compréhensible. L’utilisateur confirme l’action exacte et reçoit une preuve ou une erreur exploitable.[2]

Ce que les agents changent dans l’achat et l’inscription

Une partie de la comparaison et de la saisie peut se produire hors de la page prévue par le marketing. L’offre doit donc rester explicite dans le contenu, les données structurées et les systèmes de disponibilité, tandis que consentement et engagement restent attachés à une confirmation.[1][2]

Identifier les frictions qui bloquent humains et agents

  • Libellé absent ou ambigu.[1][2]
  • Composant personnalisé sans équivalent sémantique.[1][2]
  • Erreur signalée uniquement par couleur.[1][2]
  • État perdu entre deux étapes.[1][2]
  • Prix ou condition révélés après la soumission.[1][2]
  • Session ou consentement implicite.[1][2]
  • CAPTCHA sans voie accessible.[2]
  • Bouton dont l’action réelle est imprécise.[1][2]

Préserver authentification et paiement à forte assurance

OTP, authentification forte et 3-D Secure

Un agent peut préparer le parcours, mais le facteur d’authentification et la validation doivent rester liés à la personne, au montant et au bénéficiaire. Ne transmettez pas silencieusement un secret ou un code.[1][2]

Confirmation et annulation

Affichez récapitulatif, conséquences, frais et politique d’annulation avant l’engagement. Fournissez ensuite une preuve et une voie de correction compréhensibles sans dépendre de l’agent.[1][2]

Évaluer standards et interfaces sans abandonner le Web

MCP, API ou protocoles de commerce peuvent fournir une interface structurée, mais ils ajoutent identité, autorisation, version et gouvernance. Le formulaire accessible reste une voie universelle et un point de contrôle utile.[2]

Mesurer et gouverner un trafic agentique incertain

Le user-agent et les schémas de navigation ne suffisent pas toujours à attribuer une session. Mesurez réussite, erreurs, confirmations, annulations et abus par parcours, puis conservez les hypothèses d’identification distinctes des faits serveur.[1][2]

Commencer par un mode observation ou lecture seule

Faites exécuter le parcours sans soumission réelle, enregistrez les étapes proposées et comparez-les aux règles attendues. Autorisez ensuite une écriture bornée sur un environnement de test, puis la production seulement si erreurs, confirmations, arrêt et reprise ont été éprouvés.[1][2]

Tester les contenus qui tentent de détourner l’agent

Instruction injectée dans la page

Un texte visible, caché ou récupéré peut demander à l’agent d’ignorer sa politique, d’exfiltrer une donnée ou de changer de destinataire. Séparez contenu non fiable, règles et appels d’outils, puis validez les paramètres côté serveur.[1][2]

Redirection ou téléchargement hostile

Limitez domaines, types de fichiers, navigation et ouverture d’application. Une redirection valide pour un humain peut déplacer l’agent vers un contexte où la session ou les données ne doivent pas suivre.

Conserver une preuve complète de chaque action

  • Demande initiale et identité autorisée.[1][2]
  • Données et paramètres présentés à la confirmation.[1][2]
  • Réponse du serveur et identifiant de transaction.[1][2]
  • Clé d’idempotence ou protection contre le double envoi.[1][2]
  • Événements d’audit minimisés et accessibles au support.[2]
  • Délai et moyen d’annuler ou de corriger lorsque possible.[1][2]

Garde-fous et points de contrôle

  • Moindre privilège par domaine.[1][2]
  • Séparation lecture et écriture.[1][2]
  • Validation serveur de toutes les entrées.[1][2]
  • Protection CSRF et anti-abus.[1][2]
  • Confirmation humaine pour impacts élevés.[1][2]
  • Journal d’action sans secrets.[1][2]

Déployer par étapes

  • Auditer au clavier et avec lecteur d’écran.[1][2]
  • Tester navigateur standard puis agent.[1][2]
  • Documenter les étapes bloquées.[1][2]
  • Corriger sémantique et erreurs.[1][2]
  • Ajouter des confirmations proportionnées.[1][2]
  • Surveiller abus et taux d’échec.[1][2]

Mesurer le résultat complet

  • Taux de complétion humain et assisté.[1][2]
  • Erreurs par champ.[1][2]
  • Abandons par étape.[1][2]
  • Actions annulées.[1][2]
  • Fraude et tentatives automatisées.[1][2]
  • Temps de résolution.[1][2]

Vérifier les textes et la version du produit

Les règles, modèles, tarifs et interfaces évoluent. Les sources officielles ci-dessous doivent être relues au moment de la décision, avec les contrats et paramètres du compte réellement utilisé.[1][2]

Questions fréquentes

Un agent peut-il remplir un formulaire ?

Cela dépend du produit, de la page, des protections et des autorisations. Vérifiez la documentation du navigateur ou de l’agent nommé et testez le parcours réel.[2]

Faut-il supprimer les CAPTCHA ?

Non. Évaluez le risque et conservez une voie accessible ; ne supprimez pas un contrôle uniquement pour faciliter un agent.[2]

Un agent peut-il payer ?

Certains systèmes peuvent préparer ou déclencher un achat, mais paiement et authentification doivent conserver les validations requises.[1][2]

Comment détecter ce trafic ?

User-agent et logs sont des indices incomplets. Combinez serveur, session, comportement et déclarations officielles.[1][2]

MCP remplace-t-il le formulaire ?

Non. Une interface structurée peut compléter le parcours web, avec ses propres règles d’autorisation.[2]

Quelle première amélioration ?

Des labels explicites, des types natifs, des erreurs compréhensibles et un résumé avant l’action finale.[1][2]

Sources

  1. Forms tutorial — W3C. Consulté le . ↩1↩2↩3↩4↩5↩6↩7↩8↩9↩10↩11↩12↩13↩14↩15↩16↩17↩18↩19↩20↩21↩22↩23↩24↩25↩26↩27↩28↩29↩30↩31↩32↩33↩34↩35↩36↩37↩38↩39↩40↩41↩42↩43↩44↩45↩46↩47↩48↩49↩50↩51↩52↩53↩54
  2. OWASP Top 10 for LLM Applications — OWASP GenAI Security Project. Consulté le . ↩1↩2↩3↩4↩5↩6↩7↩8↩9↩10↩11↩12↩13↩14↩15↩16↩17↩18↩19↩20↩21↩22↩23↩24↩25↩26↩27↩28↩29↩30↩31↩32↩33↩34↩35↩36↩37↩38↩39↩40↩41↩42↩43↩44↩45↩46↩47↩48↩49↩50↩51↩52↩53↩54↩55↩56↩57↩58↩59↩60↩61↩62↩63↩64↩65

Poursuivre votre lecture