Une responsable sans expérience du code a créé un négociateur IA avec Codex : ce qui a fonctionné dans les prompts

Si vous avez déjà essayé de créer un interlocuteur IA jouant un rôle, vous connaissez le principal défaut : au bout de deux répliques, il se met à approuver tout ce que vous dites. L'équipe de l'université d'entreprise KORUS Consulting a résolu ce problème pour un simulateur de négociation. Le plus curieux, c'est que l'outil a été conçu par Ksenia Kalabushkina, responsable de la formation, qui affirme n'avoir jamais écrit une seule ligne de code. Voyons quelles techniques fonctionnent ici et lesquelles vous pouvez reprendre dans vos propres produits.

Pourquoi un simulateur était nécessaire

L'idée est simple. La compétence de négociation ne se consolide que par la pratique, mais s'entraîner sur un vrai client est trop risqué : une formulation maladroite coûte des délais, du périmètre et de la confiance. S'entraîner avec des collègues n'est pas non plus une solution : les gens se connaissent, se ménagent et ne jouent pas un adversaire dur, évasif ou pressé.

Il faut donc un adversaire disponible à tout moment, qui tient son rôle et fournit une analyse après la conversation. L'utilisateur choisit un cas, un rôle, une durée, une méthodologie d'évaluation et un style : coopération ou compétition. Ensuite commence un duel vocal de dix minutes. L'IA répond à voix haute, désigne le vainqueur à la fin et analyse les coups forts, les risques et les moments décisifs. L'évaluation repose sur cinq critères : progression vers l'objectif, conduite de la conversation, travail sur les intérêts, argumentation et échanges, qualité des accords.

Comment on a appris au modèle à ne pas céder

C'est la partie la plus utile pour les développeurs. Les auteurs ont employé plusieurs techniques.

Première technique : séparer les rôles. Pendant le duel, le modèle joue uniquement l'adversaire et ne donne aucun conseil à l'utilisateur. Une fois le duel terminé, une requête distincte reçoit la transcription complète et agit comme évaluateur, avec la consigne « n'évalue que ce que confirme la transcription ». Un seul modèle peine à négocier et à être un coach objectif en même temps, d'où deux prompts différents.

Deuxième technique : le comportement évolue dans le temps. Au début, l'adversaire dévoile le contexte et résiste à une conclusion prématurée. Vers la fin, il propose des solutions en package et vérifie les engagements. Passé dix minutes, il aide à consigner l'accord ou à reconnaître honnêtement qu'il n'y a pas d'accord. Ainsi, le modèle ne clôt pas l'exercice après deux répliques polies.

Troisième technique : ne pas fournir la méthodologie en bloc. Le livre de Vladimir Tarassov « L'art de la lutte managériale » a été découpé en fragments thématiques : travail sur les intérêts, questions, conditions des concessions, formalisation des accords. Avant de répondre, le service sélectionne plusieurs fragments proches de la réplique en cours et les transmet au modèle. Il s'agit en somme d'un RAG classique, qui réduit le risque de conseils généraux au lieu d'une réaction aux mots précis.

Quatrième technique : tester le comportement, pas l'élégance du prompt. Les auteurs conseillent de préparer un jeu de provocations : « mettons-nous simplement d'accord », « je suis d'accord sur tout », « finissons maintenant ». Un bon adversaire ne sort pas de son rôle, ne révèle pas ses intérêts cachés et ramène la conversation aux conditions.

Une réalisation sans programmeur

La pile technique a été choisie volontairement simple : une page web, un petit serveur Node.js, l'API OpenAI pour le texte et la voix, Supabase pour le stockage, GitHub pour les versions et Vercel pour la publication. Le travail s'est fait via Codex. L'ordre : d'abord une description d'une page du parcours utilisateur, puis la répartition des exigences en obligatoires, confortables et futures. Le premier pas avec un développeur IA consiste à lui demander de reformuler la tâche et de poser des questions, plutôt que d'écrire du code tout de suite. Chaque étape est vérifiée par un lancement : d'abord un duel textuel sans base de données ni voix, puis le reste.

À retenir en particulier pour la clé API : elle est stockée dans une variable d'environnement sur le serveur et ne doit apparaître ni sur GitHub, ni dans des captures d'écran, ni dans des échanges. Si vous utilisez des supports méthodologiques internes, retirez-en les données personnelles, les noms de clients et les conditions commerciales avant de les envoyer à un modèle externe.

Limites et conclusion

Cette histoire comporte des réserves. Il s'agit du récit des auteurs eux-mêmes, sans mesures indépendantes : on ignore combien de personnes ont réellement progressé. Le vainqueur est désigné par le modèle lui-même, et de telles évaluations tendent à la subjectivité. De plus, tout le service repose sur une seule API externe. Une partie du matériel de notre source s'interrompt à la section sur la connexion du modèle ; le déploiement et les astuces de vibe coding ne sont donc pas traités ici.

La conclusion pratique dépasse la négociation. Si vous créez un simulateur IA ou un agent jouant un rôle, séparez celui qui « joue » de celui qui « évalue », injectez les connaissances par portions et testez le système avec des provocations plutôt qu'avec des dialogues réussis. Pour un product manager, c'est aussi l'exemple d'une collaboratrice non technique qui valide une hypothèse en quelques soirées : d'abord le scénario, ensuite les outils.