1. Le signal faible qui n’en est plus un

Cette semaine, l’actualité la plus structurante pour l’intégration de l’IA dans les produits n’est pas un nouveau chatbot, mais le passage des agents du texte à l’action. Visa a officiellement connecté son infrastructure de paiement à ChatGPT, ce qui permet à des agents IA de sélectionner des produits et de finaliser des transactions sans intervention humaine[1]. Dans le même mouvement, l’entreprise a présenté le Universal Commerce Protocol (UCP), une spécification pensée pour standardiser la communication entre agents IA, systèmes de paiement et marchands[1].

Le message est clair : on ne parle plus seulement de générer du contenu ou de résumer des documents. On entre dans une phase où le LLM devient une couche d’interface entre un utilisateur, des outils et des systèmes métiers. Pour les équipes produit, cela change la nature même de l’intégration : il ne s’agit plus d’ajouter une barre de chat, mais de concevoir des parcours où l’IA peut lire, décider et agir.

Cette bascule est importante parce qu’elle rapproche les produits IA d’un cas d’usage immédiatement monétisable : la transaction. Là où le RAG améliore la pertinence et où le fine-tuning affine le comportement, l’agent relie la réponse à une action concrète, mesurable, et donc plus directement utile au business[5].

2. Pourquoi les produits IA changent de catégorie

Pendant deux ans, la plupart des produits “IA” ont été des surcouches conversationnelles : FAQ augmentée, aide à la rédaction, recherche interne, support client assisté. Le RAG a dominé parce qu’il résolvait un problème simple et prioritaire : donner au modèle un accès fiable à la connaissance de l’entreprise. Databricks, par exemple, pousse ce paradigme avec des outils activés, des index de recherche IA et la capacité de citer les documents utilisés dans la réponse[3].

Les agents franchissent une étape supplémentaire. Ils ne se contentent pas de répondre à une question ; ils choisissent un outil, exécutent une action, puis enchaînent si nécessaire. C’est ce que formalise aussi Databricks dans son approche no-code : un LLM équipé d’outils peut sélectionner la fonction appropriée, interroger un index documentaire, puis exporter l’agent vers une application déployable[3]. Autrement dit, l’IA n’est plus une fonctionnalité décorative. Elle devient une couche d’orchestration.

Cette évolution crée trois différences produit très concrètes :

  • Le coût de l’erreur augmente. Une mauvaise réponse est gênante ; une mauvaise action peut coûter de l’argent, créer un litige ou déclencher une fraude.
  • La qualité doit être observable. Il ne suffit pas d’évaluer la “fluidité” d’une réponse. Il faut suivre le taux de réussite des outils, les échecs de récupération, les boucles d’action et les validations humaines.
  • La gouvernance devient centrale. Si un agent peut acheter, modifier, envoyer ou réserver, il faut des garde-fous de permission, de traçabilité et d’arrêt d’urgence.

L’intégration d’IA dans les produits sort donc du champ de la génération pour entrer dans celui du contrôle opérationnel. C’est plus ambitieux, mais aussi beaucoup plus risqué.

3. L’enjeu réel : fiabilité, sécurité et standardisation

L’annonce de Visa met en lumière un point souvent sous-estimé : la vraie difficulté n’est pas de faire parler un agent, mais de lui faire agir dans un environnement économique réel[1]. Un agent de paiement doit gérer l’identité, l’autorisation, la confirmation, la détection d’abus et les contraintes réglementaires. Sans standard, chaque intégration devient un projet spécifique, fragile et coûteux.

C’est précisément là que l’idée d’un protocole comme l’UCP prend de la valeur. En cherchant à standardiser les échanges entre agents, marchands et infrastructures de paiement, Visa attaque un problème classique des produits IA : l’interopérabilité[1]. Si chaque système impose ses propres schémas d’appel, ses propres permissions et ses propres formats de contexte, l’agent reste enfermé dans une démonstration. Avec un protocole partagé, il peut devenir une brique réutilisable.

Mais cette promesse n’efface pas les limites techniques. Les agents restent dépendants de plusieurs points de fragilité bien connus :

  • hallucinations sur les données ou sur le choix d’un outil ;
  • erreurs de contexte quand l’historique est trop long ou incomplet ;
  • enchaînements non fiables dans les tâches multi-étapes ;
  • surface d’attaque élargie via le prompt injection, les outils connectés ou les permissions excessives.

Dans les produits réels, le bon design n’est donc pas “tout confier à l’agent”, mais définir ce que l’agent peut faire seul, ce qu’il doit proposer, et ce qui doit rester validé par un humain. C’est souvent la différence entre un prototype convaincant et un produit exploitable.

4. En pratique

Pour les équipes produit, cette actualité dessine une stratégie très concrète : utiliser l’IA non pas comme un slogan, mais comme une architecture progressive.

  • Commencer par le RAG avant l’agent. Si le produit ne sait pas encore répondre correctement à partir de sa propre connaissance, ajouter des actions ne fera qu’amplifier l’instabilité. Le socle doit d’abord être la recherche fiable, la citation des sources et la qualité des réponses[3][5].
  • Limiter les actions à fort risque. Autoriser un agent à rédiger un panier, préremplir un formulaire ou proposer une réservation est plus sûr que lui laisser exécuter une commande sans contrôle. Les tâches transactionnelles doivent être graduellement ouvertes, avec validation humaine au bon moment[1].
  • Instrumenter la fiabilité comme une métrique produit. Il faut suivre des indicateurs concrets : taux de récupération correcte, taux de réussite des outils, nombre d’interventions humaines, temps gagné par tâche et taux d’erreurs bloquantes. Sans cela, impossible de distinguer un vrai gain opérationnel d’une simple démonstration séduisante.