De l'UX à l'AX : concevoir des produits pour l'ère des agents IA

Il y a une phrase que l'on entend de plus en plus souvent en atelier produit : « On pourrait ajouter un agent IA ici. »

Sur le papier, l'idée paraît simple. Un champ de saisie, une interface de chat, quelques actions automatisées, et le produit donne l'impression de passer dans une nouvelle génération. La démo fonctionne. L'effet « waouh » arrive vite. Pendant quelques minutes, tout le monde voit très bien la scène.

Puis les questions arrivent.

Qu'a le droit de faire l'agent ? Sur quelles données travaille-t-il ? Peut-il envoyer un email ? Modifier un dossier client ? Générer une recommandation commerciale ? Déclencher une validation ? Qui relit ? Qui assume l'erreur ? Que garde-t-on en historique ? Que montre-t-on à l'utilisateur quand l'agent doute ?

C'est souvent à ce moment-là que le sujet quitte le registre de la démo pour entrer dans celui du produit.

Les produits numériques changent de rôle. Ils affichent, guident, organisent encore des parcours, bien sûr. Mais une partie de leur valeur se déplace vers l'action assistée : lire une situation, proposer une suite, préparer une décision, parfois exécuter une tâche dans un cadre donné.

L'interface devient alors un point de passage entre une intention humaine et une chaîne d'actions plus ou moins automatisées.

Cette évolution change profondément la manière de concevoir un produit.

Quand l'interface commence à agir

Pendant des années, l'UX a surtout cherché à rendre les parcours plus lisibles : réduire les frictions, clarifier les boutons, simplifier les formulaires, hiérarchiser les informations.

Ce travail reste essentiel. Un produit confus avec de l'IA devient un produit confus avec plus de puissance.

Avec les agents IA, une nouvelle couche apparaît. L'utilisateur arrive avec une intention, parfois formulée en langage naturel, parfois déduite de son contexte. Le système doit l'aider à passer de cette intention à une suite d'actions compréhensibles.

Dans un outil de vente, cela peut prendre la forme d'un agent qui prépare une synthèse client avant un rendez-vous. Dans un back-office, il peut repérer les dossiers incomplets et suggérer la prochaine étape. Dans une plateforme SaaS, il peut analyser une baisse d'usage, formuler une hypothèse, puis préparer un plan de relance.

Le design porte alors sur la délégation.

Cette bascule est subtile. Elle oblige à décrire ce que l'utilisateur confie au système, ce que le système peut faire seul, ce qu'il doit demander avant d'agir, et ce qui reste explicitement humain.

J'aime bien parler d'AX, pour Agent Experience. Le terme vaut surtout comme repère de travail : comment un utilisateur collabore-t-il avec une intelligence capable d'agir dans le produit ?

Une délégation se conçoit

Le piège classique consiste à partir du modèle. On choisit un LLM, on branche deux API, on rédige un prompt, puis on cherche les cas d'usage.

Dans les projets bien cadrés, le chemin part du terrain.

Prenons un tableau de bord de performance. Beaucoup d'équipes rêvent d'un agent capable de répondre à une question comme : « Pourquoi mon taux de conversion baisse depuis trois semaines ? »

La réponse utile dépend de beaucoup d'éléments moins visibles que le modèle : qualité des données, plan de marquage, règles métier, périodes comparées, événements commerciaux, changements de campagne, limites statistiques. Elle dépend aussi de la manière dont l'agent expose son raisonnement.

Une réponse utile pourrait ressembler à ceci :

L'intérêt tient à la structure du raisonnement. L'utilisateur voit ce qui a été comparé, les signaux utilisés, les limites de l'analyse, et la prochaine action possible. Il peut contester, compléter, valider.

Un prompt isolé produit rarement ce niveau de fiabilité. Il faut une architecture autour : données propres, permissions, journal des actions, critères de confiance, scénarios d'échec, possibilité de reprendre la main.

C'est moins spectaculaire en atelier. C'est ce qui rend le produit utilisable après la démonstration.

La confiance se joue dans les détails

La confiance dans un produit IA se construit dans des éléments très ordinaires.

• Un bouton « valider avant envoi ».
• Un historique des actions.
• Une source affichée sous une recommandation.
• Un niveau de certitude visible.
• Une option « annuler ».
• Un message clair quand l'agent manque d'information.
• Une séparation nette entre suggestion et exécution.

Ces détails paraissent modestes. Ils décident pourtant de l'adoption.

Dans une interface classique, une erreur de conception crée souvent une friction. Dans un produit agentique, elle peut créer une perte de contrôle. L'utilisateur doit sentir que l'agent travaille dans un cadre compréhensible, avec des limites lisibles. Dès que le système agit trop vite, trop loin, ou avec trop peu d'explications, la confiance baisse.

La transparence doit être pensée comme une fonction du produit, pas comme une couche ajoutée en fin de projet.

Cela devient encore plus important dans le contexte européen. Les règles de transparence de l'AI Act vont pousser les entreprises à rendre certains usages de l'IA plus explicites. Les produits qui auront intégré cette exigence dès la conception auront moins besoin de corriger leur expérience à la dernière minute avec des mentions juridiques mal placées.

Un utilisateur fait confiance quand il dispose de points d'appui : sources, hypothèses, limites, validation possible. Sans ces points d'appui, il subit une boîte noire avec une belle interface.

Une mémoire exploitable

Les agents IA posent un autre problème, plus discret : la mémoire.

Un agent qui travaille sur une tâche complexe accumule du contexte. Il lit des documents, interprète des signaux, propose des options, reçoit des validations, exécute une partie du travail. Si rien n'est structuré, cette mémoire reste coincée dans une conversation.

Quelques semaines plus tard, personne ne sait vraiment pourquoi une recommandation a été suivie.

C'est un sujet que l'on sous-estime souvent. Les entreprises ont déjà du mal à garder une mémoire propre de leurs décisions produit. Avec l'IA, ce défaut peut prendre de l'ampleur. Les échanges deviennent plus nombreux, les versions se multiplient, les hypothèses circulent vite.

La réponse tient dans une pratique simple : matérialiser les étapes importantes.

Ce vocabulaire peut sembler très opérationnel. Il est pourtant central. Un produit agentique sérieux doit permettre de reconstituer ce qui s'est passé. Pour préserver la maîtrise, mais aussi pour faciliter la maintenance, l'audit, la formation, la reprise du dossier par une autre équipe.

Dans un outil métier, cela peut prendre la forme d'un fil d'activité lisible : « l'agent a analysé ces données », « il a proposé ces trois actions », « l'utilisateur a validé celle-ci », « le système a exécuté telle opération », « tel point reste à vérifier ».

Cette mémoire devient une pièce de l'expérience.

Le retour du cadrage

L'IA donne une impression de vitesse. Elle encourage parfois les mauvaises habitudes : construire avant de comprendre, automatiser avant de cadrer, ajouter une couche intelligente sur un processus flou.

Le travail produit devient plus exigeant.

Avant de concevoir un agent dans une plateforme, il faut revenir aux questions de base :

• Quelle intention utilisateur sert-on vraiment ?
• Quelle tâche mérite d'être déléguée ?
• Quel niveau d'autonomie est acceptable ?
• Quelles données sont fiables ?
• Quelles actions doivent rester sous validation humaine ?
• Quel risque accepte-t-on en cas d'erreur ?
• Comment mesure-t-on la qualité du résultat ?

Ces questions paraissent simples. En atelier, elles font vite apparaître les angles morts.

Une équipe peut découvrir que les données CRM sont incomplètes. Qu'un processus de validation varie selon les régions. Que personne ne sait qui tranche en cas de désaccord entre le métier et la technique. Que l'agent imaginé en démonstration suppose en fait trois intégrations, deux arbitrages juridiques et une refonte du plan de permissions.

Ce moment est précieux.

Il évite de transformer une intuition séduisante en chantier fragile. Il permet de définir un premier périmètre utile : une tâche bornée, une source de données claire, un utilisateur identifié, une validation humaine visible, un indicateur de réussite.

Un agent robuste part souvent de là : une délégation précise, bien limitée, avec une valeur visible.

Les points à regarder avant de lancer

Si je devais auditer un produit IA avant son lancement, je regarderais d'abord quelques points très concrets.

La donnée d'abord. Est-elle propre, accessible, gouvernée ? Un agent alimenté par une donnée instable produira des réponses instables avec beaucoup d'assurance.

Les permissions ensuite. L'agent peut-il lire, écrire, envoyer, supprimer, modifier ? Chaque verbe compte. Lire un dossier client et envoyer un email au client n'ont pas le même poids.

La validation humaine. À quel moment l'utilisateur reprend-il la main ? Une recommandation peut être automatique. Une action engageante mérite souvent une validation explicite.

La traçabilité. Peut-on relire ce que l'agent a fait, avec quelles sources, quelles hypothèses, quelle décision humaine ? Si la réponse reste floue, le produit sera difficile à maintenir.

La mesure enfin. Un produit agentique doit être évalué sur autre chose que le volume d'usage. Il faut regarder la qualité des recommandations, le taux d'acceptation, les corrections humaines, les erreurs évitées, le temps réellement gagné, la satisfaction des équipes.

L'architecture produit prend ici une place très concrète : elle organise les droits, les données, les décisions, les garde-fous et les preuves. Elle permet à l'agent de travailler dans un cadre utile, lisible et maintenable.

Les prochains mois vont voir apparaître beaucoup d'interfaces « avec IA ». Certaines impressionneront en démonstration. Les plus utiles auront été conçues avec patience : intention claire, données fiables, rôles explicites, garde-fous visibles, mesure continue.

Le reste fera probablement de belles démos.