Ce que nos beta-testeurs ont cassé, deuxième passe : le silence qui bloquait tout

Après un premier test utilisateur réel, 21 retours écrits ont fait remonter un défaut invisible en interne : un type d'étape entier n'était traité nulle part dans le moteur. La chaîne se figeait, silencieusement, en attendant une réponse qui ne venait jamais.

Après notre première semaine de beta, un second test utilisateur réel a produit 21 retours écrits. Le plus sérieux n'était pas visible dans nos propres essais : un type d'étape entier, celui qui pose une question et attend la réponse, n'était traité nulle part dans le moteur. La chaîne s'arrêtait, silencieusement, sans jamais reprendre.

Le symptôme : une chaîne qui se fige sans le dire

Le cadrage d'un projet pose parfois une question à l'utilisateur avant de continuer. Dans un cas précis, le brief se mettait à s'écrire avant même que la personne n'ait lu la question posée : le moteur avançait comme si la réponse était déjà donnée, alors qu'elle ne l'était pas. Un testeur pressé n'aurait rien remarqué avant de découvrir, plus tard, un document qui ne correspondait pas à ce qu'il avait réellement voulu dire.

Pourquoi ça n'était jamais arrivé chez nous

En interne, un type d'étape rarement déclenché passe facilement entre les mailles d'une relecture de code centrée sur les cas fréquents. Il a fallu un vrai utilisateur, dans une vraie conversation, prenant le temps de vraiment répondre à une vraie question, pour que le défaut se manifeste, exactement le genre de scénario qu'un test écrit à la va-vite en interne aurait sauté sans même s'en rendre compte. La correction impose une règle simple : la chaîne s'arrête et reprend sans jamais rejouer une étape déjà passée, et en cas de doute, elle avance plutôt que de bloquer indéfiniment un enchaînement complet.

Un choix retiré plutôt qu'ajouté

Le même test a fait remonter un signal inverse : un sélecteur de modèle d'IA, présenté tôt dans le parcours, n'aidait personne à décider. Le retour de la beta a été net, le défaut du moteur suffit, la plupart des gens n'ont ni l'envie ni les moyens de juger entre deux modèles d'IA à ce stade du parcours. Le sélecteur a été retiré de ce point précis plutôt que d'être amélioré : la meilleure correction, parfois, retire un choix au lieu d'en ajouter un. C'est un réflexe qui va à l'encontre de l'instinct produit habituel, ajouter une option de plus pour satisfaire tout le monde, et qui demande une vraie discipline pour rester en place une fois le calme revenu.

Ce que la télémétrie a montré, et pas les emails

Les retours écrits disent ce que quelqu'un a ressenti ; la télémétrie anonyme dit ce qui s'est réellement passé, étape par étape, avant que le blocage n'arrive. C'est le croisement des deux qui a permis de localiser le défaut en une journée plutôt qu'en devinant à partir d'une description approximative du problème. Sans la télémétrie, le seul indice aurait été un utilisateur frustré racontant que « rien ne se passe », une phrase qui ne dit rien du point exact où le moteur s'est tu.

Ce qui reste ouvert

Tous les défauts remontés par un test utilisateur ne se corrigent pas le jour même. Certains attendent une décision produit plus large avant d'être tranchés, et nous préférons le dire plutôt que de prétendre que tout est résolu. C'est le même principe que nos benchmarks publient nos défaites : montrer ce qui a cassé compte autant que montrer ce qui marche.