Toute surface agentique digne de confiance est répétée avec de vraies personnes avant de toucher à de vraies conséquences. La phrase semble évidente, jusqu’à ce qu’on regarde comment la plupart des organisations en lancent une. On construit l’agent, on le teste contre un cahier des charges, on le montre à la direction, puis on le déploie. Et la première fois qu’il rencontre un vrai client, un vrai cas limite, un vrai employé agacé qui passe outre sa suggestion, c’est aussi la première fois qu’on découvre comment il se comporte sous pression. À ce stade, ce n’est plus une répétition. C’est en direct, et l’erreur devient un incident de production plutôt qu’une leçon.
Répétition : drôle de mot pour parler de logiciel, mais c’est le bon. Une troupe de théâtre ne donne pas la première le soir même où elle termine la mise en place. Elle joue la pièce, mal, devant une poignée de gens qui ont le droit de dire « ça n’a pas porté » sans que le spectacle soit annulé. Une répétition ne sert pas à attraper des bogues. Elle sert à attraper les moments où la chose fonctionne exactement comme prévu et produit quand même la mauvaise impression, la mauvaise confiance, le mauvais résultat, parce que la conception n’a jamais tenu compte de la façon dont une vraie personne allait réagir.
Les systèmes agentiques exigent la même discipline, pour une raison précise : ils posent des jugements, pas seulement des calculs. Une fonctionnalité classique marche ou ne marche pas. Un agent décide quand escalader, quand agir seul, quand s’expliquer, quand se taire. Ce sont des décisions relationnelles autant que techniques, et une décision relationnelle ne se teste qu’en la plaçant devant les humains qu’elle touchera. Pas une liste de contrôle d’assurance qualité, pas un jeu d’évaluation synthétique : votre vraie équipe, dans une pièce, qui regarde la chose trancher et qui réagit honnêtement.
Voilà pourquoi Paracosm traite l’étape du prototype comme une répétition, pas comme une démo. Une démo est faite pour avoir l’air finie. Une répétition est faite pour être interrompue : mise sur pause en pleine interaction pour que quelqu’un demande « attends, pourquoi il a fait ça? », rembobinée pour qu’une autre personne essaie le même scénario et voie si la réponse est la même, mise à l’épreuve avec le cas limite que quelqu’un dans la pièce voit déjà venir parce qu’il l’a vécu avec un humain qui faisait le même travail. Rapid Launch existe précisément pour mettre quelque chose de réel devant les gens assez vite pour que cette répétition ait lieu avant que les enjeux soient réels : un prototype fonctionnel en deux semaines, conçu pour être contesté, pas applaudi.
L’habitude que ça construit vaut plus que n’importe quel prototype. Les équipes qui répètent avant de lancer développent une compétence que la plupart des organisations ne cultivent jamais délibérément : remarquer l’écart entre ce qu’un système devait faire et ce qu’il fait réellement aux gens autour de lui, pendant que cet écart coûte encore peu à combler. Les équipes qui sautent directement à la production deviennent très bonnes dans une autre compétence : expliquer, après coup, pourquoi personne ne l’a vu venir.
Une démo est faite pour avoir l’air finie. Une répétition est faite pour être interrompue.
Rien de tout ça ne remplace les tests en conditions réelles une fois la chose lancée. Ce n’est pas un substitut à la surveillance, aux boucles de rétroaction ou au travail de gouvernance qui garde un système agentique redevable après le lancement. C’est l’étape d’avant : celle qui détermine si le système que vous lancez a vraiment été testé contre un humain, ou seulement contre un cahier des charges. Une habitude surpasse presque toutes les autres stratégies de gestion du risque en transformation agentique, et c’est celle-ci : répéter avec les gens concernés, volontairement, avant que la salle perde le droit de dire « ça n’a pas porté ».