Le design agentique : concevoir des systèmes qui décident

Depuis deux ans, une partie croissante de ce que fait un produit numérique n'est plus déclenchée par un clic. C'est déclenché par un agent : un modèle de langage auquel on a donné des outils, une autonomie et un périmètre. Cette bascule change le métier de designer plus profondément que ne l'ont fait le responsive, le mobile ou le design system.

Cet article pose le cadre que j'utilise pour concevoir ces produits. Il est né d'un constat simple : la plupart des méthodes de design que nous utilisons supposent que l'utilisateur initie l'action. Dès qu'une machine agit à sa place, ces méthodes deviennent insuffisantes.

Le déplacement : de l'écran à la règle de décision

Concevoir un écran revient à répondre à trois questions : qu'est-ce qu'on montre, dans quel ordre, avec quelle hiérarchie visuelle. Ces questions restent valables. Elles ne suffisent simplement plus.

Concevoir un système agentique demande d'y ajouter trois questions d'une autre nature :

• Quelles décisions la machine peut-elle prendre sans nous ?
• À quel moment rend-elle la main, et comment le signale-t-elle ?
• Comment l'utilisateur reprend-il le contrôle quand elle s'est trompée ?

Aucune de ces trois questions ne se résout dans un outil de maquette. Elles se résolvent dans le modèle mental du produit, et elles se vérifient en production, sur des données réelles.

Les trois niveaux d'autonomie

La question qui revient systématiquement en atelier : « jusqu'où on laisse l'IA décider ? ». Il existe trois réponses possibles.

In the loop

L'humain valide chaque action avant exécution. L'agent propose, l'humain dispose. C'est le niveau le plus coûteux en attention, mais le seul acceptable quand l'action est irréversible et engage l'utilisateur vis-à-vis d'un tiers — un email envoyé, une commande passée, un document signé.

On the loop

L'agent exécute, l'humain supervise et peut interrompre. Ce niveau suppose une interface de supervision réelle : un journal lisible, une alerte quand quelque chose sort de l'ordinaire, un bouton d'arrêt qui fonctionne vraiment. Sans ces trois éléments, « on the loop » n'est qu'un « out of the loop » qu'on n'assume pas.

Out of the loop

L'agent exécute seul, on ne regarde que le résultat agrégé. C'est le bon niveau pour les tâches à faible coût d'erreur et haute réversibilité : trier, classer, enrichir, pré-remplir.

Le critère de choix : coût de l'erreur × réversibilité

L'erreur la plus fréquente consiste à choisir ce niveau en fonction de la maturité technique de l'équipe. « On n'est pas encore prêts, on reste in the loop partout. » C'est confortable, et c'est un mauvais critère : il produit des produits uniformément friqués, où l'utilisateur valide autant une suggestion de tri qu'un envoi client.

Le bon critère combine deux variables :

• Le coût de l'erreur : que perd-on si l'agent se trompe ? Du temps, de l'argent, de la crédibilité, une relation commerciale ?
• La réversibilité : peut-on revenir en arrière, et en combien de temps ?

Trois exemples pour rendre le raisonnement concret.

Trier des messages entrants par priorité. Coût faible, totalement réversible : out of the loop, sans hésiter. Demander une validation ici est une friction pure.

Envoyer un email de prospection. Coût modéré, mais strictement irréversible : in the loop. L'agent rédige, l'humain envoie.

Déclencher une commande fournisseur sur seuil de stock. Coût élevé, mais réversible sous 24 heures : on the loop, avec notification immédiate et fenêtre d'annulation.

Ce raisonnement se mène tâche par tâche, jamais produit par produit. Une même application contient légitimement les trois niveaux — et c'est même le signe qu'elle a été conçue sérieusement plutôt que par principe.

Le livrable : un tableau, pas une maquette

Sur mon dernier projet, le document le plus utilisé par l'équipe n'était pas un fichier de design. C'était un tableau à quatre colonnes, une ligne par action automatisable.

• Déclencheur — qu'est-ce qui lance l'action : un événement, une planification, une demande explicite ?
• Autonomie — in / on / out of the loop, avec la justification en une phrase.
• Repli — que se passe-t-il quand la donnée manque, quand le quota est atteint, quand le modèle échoue ?
• Trace — que peut relire l'utilisateur après coup pour comprendre ce qui s'est passé ?

Ce tableau se remplit en atelier, avant la première maquette, avec le métier et les développeurs dans la même pièce. Il produit trois effets.

Les désaccords sortent tôt. Deux personnes d'accord sur « on automatise la relance » cessent de l'être dès que la colonne Autonomie est remplie. Ce désaccord aurait resurgi de toute façon — autant qu'il coûte une heure d'atelier plutôt que trois semaines de développement.

Les écrans deviennent presque mécaniques. Une fois les quatre colonnes arbitrées, la maquette découle du tableau. Elle se dessine plus vite et se discute moins.

Les cas d'erreur sont conçus, pas subis. La colonne Repli force à traiter l'échec comme du produit. C'est probablement son apport le plus sous-estimé : dans la plupart des projets, les états dégradés sont découverts en recette et traités comme de la dette.

La réversibilité comme condition d'adoption

Une observation qui revient sur tous les produits agentiques que j'ai vus tourner : l'adoption d'une fonctionnalité automatisée ne dépend presque jamais de sa qualité. Elle dépend de ce qui se passe quand elle se trompe.

Un utilisateur qui sait revenir en arrière essaie. Un utilisateur qui ne sait pas revenir en arrière lit, hésite, et fait à la main.

Beaucoup d'actions d'agent sont pourtant réellement irréversibles. Trois formes de réversibilité fonctionnent quand l'annulation stricte est impossible :

• Le délai de rattrapage. L'action est décidée immédiatement, exécutée dans trente secondes. Techniquement trivial, et cela couvre la quasi-totalité des regrets réels.
• Le brouillon par défaut. L'agent produit, l'utilisateur envoie. L'irréversibilité se déplace vers un geste humain volontaire, ce qui la rend acceptable.
• La visibilité avant engagement. Afficher le coût, le nombre d'éléments concernés et un échantillon du résultat avant de lancer. On ne peut pas annuler, mais on a pu renoncer.

Aucune de ces trois formes ne rend l'action techniquement réversible. Toutes rendent la décision réversible pour l'utilisateur. C'est cette perception qui détermine si l'automatisation est utilisée ou contournée.

Ce qui ne se délègue pas

Un modèle génère aujourd'hui vingt écrans plausibles en trente secondes. Il ne sait toujours pas dire lequel des vingt répond à un problème réel.

Ce n'est pas une limite temporaire liée à la génération actuelle de modèles. C'est structurel : un modèle optimise une réponse à partir d'un énoncé, et il n'a pas accès à ce qui manque dans l'énoncé. Or c'est presque toujours là que se joue un projet.

« Les utilisateurs ne trouvent pas la fonctionnalité » est un énoncé. Il produit une refonte de navigation. « Les utilisateurs cherchent une fonctionnalité qu'ils n'auraient pas dû avoir à chercher » est un autre énoncé. Il produit une automatisation. Même symptôme, deux problèmes différents, deux produits différents.

Aucun outil ne fait ce passage à votre place, parce qu'il demande d'aller regarder un contexte qui n'est écrit nulle part : ce que les gens font vraiment, ce qu'ils contournent, ce qu'ils n'osent pas dire en réunion.

La conséquence pratique est plutôt bonne pour le métier. La partie industrialisable du design s'automatise, et ce qui reste est la partie qui avait le plus de valeur depuis le début — à condition d'accepter de passer plus de temps sur le problème que sur la solution.

Par où commencer

Si vous travaillez sur un produit qui embarque des agents, un exercice d'une heure suffit à démarrer : listez chaque action que votre produit peut déclencher sans intervention humaine, et remplissez les quatre colonnes. Déclencheur, autonomie, repli, trace.

Vous découvrirez probablement deux choses. Que certaines actions sont beaucoup plus autonomes qu'elles ne devraient l'être. Et que la colonne Repli est, sur la moitié des lignes, encore vide.