Parle pendant qu'il travaille : pourquoi notre agent accepte les interruptions

Une de nos premières testeuses avançait sur une longue tâche quand elle a tapé une correction dans le chat — sans rien arrêter. Elle nous a dit après que le moment lui avait fait un bien inattendu : l'autre outil d'agent qu'elle utilise l'oblige à arrêter le run d'abord avant d'accepter un nouveau message. « Devoir l'arrêter juste pour lui parler, c'était absurde », a-t-elle dit, « comparé à ça ».

Elle a raison, et la différence n'est pas un petit raffinement d'UX. Elle vient d'une décision de design prise tôt et qu'on continue d'appliquer : un agent est un collègue, pas une machine. Tu interromps un collègue en pleine phrase et il intègre ça. Tu ne le redémarres pas.

Pourquoi « arrête d'abord » est le mauvais défaut

Obliger l'utilisateur à stopper un run avant de parler a trois coûts, tous payés par l'utilisateur :

• La correction arrive trop tard. Le moment où tu remarques que l'agent déraille est exactement celui où tu devrais parler. Forcer l'arrêt, c'est le regarder brûler du temps et des tokens sur le mauvais chemin pendant que tu cherches le bouton stop.
• Arrêter détruit l'état. Un run stoppé ne reprend pas — tu repars de zéro, ou pire, tu récupères un stub « annulé » et tu réexpliques le contexte. Ta correction de trajectoire en vol te coûte tout le travail en cours.
• Ça inverse qui sert qui. « La machine ne peut pas t'entendre tout de suite, reviens plus tard » — c'est le confort de la machine, pas le tien.

Comment le nôtre marche vraiment

Quand tu envoies un message pendant qu'un run est en cours, trois choses se passent dans l'ordre :

1. Tes mots sont sauvegardés d'abord. Le message atterrit dans l'historique de la conversation immédiatement — avant que quoi que ce soit soit dispatché. Ton intention est durable à partir de cette seconde ; aucune file, aucun buffer, aucun timing ne peut la perdre.
2. Il est délivré à la prochaine frontière d'étape. L'agent ne lâche pas ce qu'il tient en plein appel d'outil — il lit ton message à la prochaine pause naturelle, comme quelqu'un qui finit sa pensée puis prend ta remarque.
3. Ça corrige le cap, ça ne redémarre pas. Tout ce que le run a déjà fait reste. Ton message est une correction de trajectoire appliquée à une tâche en mouvement, pas un reboot.

Le principe en dessous : la durabilité de l'intention de l'utilisateur passe avant le confort du système. Une fois les mots sauvegardés, tout ce qui est en aval est une question de timing — et le timing peut être rendu gracieux. Une intention non sauvegardée, elle, ne se récupère pas du tout.

À quoi ça ressemble en pratique

L'exemple le plus clair est déjà public. Dans l'histoire de l'horloge, la demande du fondateur a pivoté deux fois pendant que l'agent travaillait — « en fait, fais-en une version HTML », puis « package-la comme une web app installable ». Chaque intervention a atterri en plein run et a infléchi la trajectoire. Personne n'a appuyé sur stop ; l'app livrée a été façonnée par des corrections délivrées en vol.

La version quotidienne, plus subtile, est plus banale et plus précieuse : tu es à dix messages dans une tâche de recherche, tu le vois construire la mauvaise comparaison, tu tapes « compare plutôt avec X » — et tu le regardes tourner sans perdre les huit bonnes sources qu'il avait déjà réunies.

Le principe voyage

Cette semaine, on s'est posé la même question de l'autre côté : qu'est-ce qui se passe quand c'est nous qui t'interrompons — un redémarrage de serveur pour un deploy ? La réponse honnête s'est révélée être la même règle. Pendant les deploys, le serveur accepte maintenant les injections en plein run (tes mots sauvegardés survivent et le run suivant les reprend en contexte) tout en ne mettant en pause que les démarrages de nouveaux runs. Rejeter une saisie que l'utilisateur avait déjà tapée aurait été notre confort qui passe avant ton intention — exactement l'inversion critiquée plus haut, juste déguisée en ops.

On ne prétend pas que c'est nouveau — les interruptions mises en file, c'est comme ça que les bons systèmes marchent depuis toujours. C'est juste rare dans l'UX des agents, où « arrête la machine pour lui parler » est devenu la norme. On est contents d'être le défaut ennuyeux et correct.