Quelqu'un dans la salle va le dire. Habituellement vers la vingtième minute, habituellement la personne la plus technique, et habituellement sans malice : on a déjà Claude. Pourquoi on ne bâtirait pas ça nous-mêmes ?
La réponse honnête, c'est que vous pouvez en bâtir une bonne partie, rapidement, et je préfère le dire tout haut que prétendre le contraire. Donnez un après-midi et une clé d'API à un ingénieur compétent et il vous remettra un robot conversationnel qui joue un acheteur sceptique. Ce sera réellement impressionnant. Il tiendra son personnage, résistera, et improvisera des objections que vous n'aviez pas scriptées. Tous ceux qui le verront seront un peu ravis.
Cette démonstration est réelle. Elle représente aussi environ quatre pour cent du travail, et les quatre-vingt-seize pour cent restants sont invisibles d'où vous êtes quand vous la voyez.
La démonstration n'est pas la partie difficile
Le jeu de rôle est ce que les grands modèles de langage font naturellement de mieux. Vous demandez à un système entraîné sur du dialogue humain de produire du dialogue humain. Il joue sur ses forces, et il n'a presque besoin d'aucune structure pour être convaincant pendant dix minutes.
Alors si vous bâtissez la démonstration, vous conclurez que le problème est facile. Cette conclusion est le piège, parce que la démonstration répond à une question que personne dans votre entreprise n'a posée. Personne n'a besoin d'un jeu de rôle convaincant. Les gens ont besoin de savoir si un représentant s'est amélioré, de combien, sur quoi précisément, et si le chiffre qu'ils regardent veut dire la même chose ce mois-ci que le mois dernier.
C'est un problème de mesure, pas un problème de conversation. Et la mesure, c'est là que les grands modèles de langage sont les plus faibles.
Demandez-lui de noter, et le sol bouge
Voici ce qu'on découvre à la troisième semaine, pas à la première. Prenez une seule transcription et demandez au modèle de la noter selon une grille. Puis redemandez-lui. Vous obtiendrez un chiffre différent.
Pas radicalement différent. Juste assez. Un 6 devient un 7. Un cadre qui ressortait comme une faiblesse ressort maintenant comme adéquat. Rien n'a changé dans la conversation, seulement l'exécution.
C'est fatal d'une façon qui met du temps à devenir évidente, parce que toute la valeur d'une note tient dans la comparaison. Vous demandez si ce représentant s'est amélioré depuis le trimestre dernier, si cette succursale est en retard sur l'autre, si le coaching fonctionne. Chacune de ces questions est une soustraction entre deux chiffres. Si les chiffres oscillent d'eux-mêmes, la soustraction n'est que du bruit, et vous avez bâti un générateur de nombres aléatoires très coûteux avec une belle interface.
L'échec est silencieux, et c'est ce qui le rend dangereux. Il ne génère pas d'erreur. Il ne plante pas. Il produit un chiffre plausible chaque fois, et il faudra des mois avant que quelqu'un remarque que la courbe de tendance n'a jamais rien voulu dire.
Ce qu'il faut réellement pour garder une note immobile
Stabiliser une note n'est pas un problème de rédaction de consignes qu'on règle une fois. C'est une grille avec des paliers définis, des règles de départage pour le milieu ambigu, un traitement explicite des cas qui brisent la grille, et surtout une suite de tests de régression qui s'exécute chaque fois qu'on touche à quoi que ce soit.
Celle de Parlare compte 880 tests en date d'août 2026, actuellement au vert, zéro échec. Elle s'exécute à chaque changement du moteur de notation. Quand un scénario est ajouté, quand une règle de cadre est ajustée, quand une version de modèle bouge sous nos pieds, c'est cette suite qui nous dit si une note veut dire aujourd'hui ce qu'elle voulait dire la semaine dernière.
Je veux être précis sur la raison pour laquelle ce chiffre compte, parce qu'il se lit facilement comme de la vanité. Ce n'est pas une mesure de l'intelligence du produit. C'est une mesure du nombre de façons dont nous avons déjà vu la notation dériver, chacune attrapée une fois puis clouée au sol pour qu'elle ne revienne pas. Chaque test là-dedans existe parce que quelque chose a bougé qui n'aurait pas dû.
Personne ne bâtit ça pour une démonstration interne. Non pas par incapacité, mais parce que la démonstration n'en a pas besoin et que le besoin ne devient visible qu'après avoir livré à de vrais utilisateurs et commencé à prendre des décisions avec le résultat. À ce moment-là, vous avez une note à laquelle les gens font confiance dans un système qui ne le mérite pas encore.
Puis le reste arrive
Supposons que vous réglez la constance. Vous avez une note stable. Les questions commencent alors, et ce sont les questions ordinaires que tout vrai utilisateur pose dans les deux premières semaines.
Qu'est-ce que je devrais pratiquer ensuite ? Parlare regarde le cadre où le représentant obtient sa plus faible note dans tout son historique, exige au moins trois séances notées avant d'agir sur le signal, ignore tout ce qui dépasse déjà 7,5, et exclut les trois derniers éléments pratiqués pour qu'on ne lui redonne pas le même exercice. Les nouveaux utilisateurs sans historique retombent sur la faiblesse qu'ils ont nommée à l'intégration, et cette amorce s'estompe automatiquement dès qu'une vraie mesure existe. C'est une seule fonctionnalité. C'est une page de règles, toutes discutables, chacune issue d'une décision que quelqu'un a dû prendre et défendre.
Est-ce que ça devient plus difficile à mesure que je m'améliore ? La difficulté du client potentiel suit la maîtrise mesurée du représentant sur le cadre que ce scénario entraîne, bornée pour qu'une seule bonne séance ne débloque pas immédiatement l'interlocuteur le plus coriace. Un outil de pratique dont la difficulté ne bouge jamais cesse d'être de la pratique après deux semaines.
Qu'est-ce que mon équipe fait réellement ? Qui a pratiqué, quoi, avec quelles notes, et si la tendance monte. L'assignation, pour qu'un responsable puisse mettre un scénario devant une personne précise. L'achèvement, pour qu'il voie que ça a eu lieu. C'est la partie qui décide si l'outil est utilisé tout court, et elle n'a rien à voir avec l'IA.
Où sont les scénarios ? Parlare en livre vingt et un pour les services financiers seulement, chacun rattaché à une ligne d'affaires, chacun écrit pour qu'un banquier reconnaisse la situation plutôt que l'idée qu'un fournisseur de formation s'en fait. Un renouvellement hypothécaire avec choc de taux et une offre concurrente sur la table. Le risque de transfert intergénérationnel quand l'enfant adulte déplace le compte. La renégociation d'une facilité de crédit devenue trop petite pour l'entreprise. Écrire ça n'est pas du travail d'ingénierie. C'est du travail de domaine, et c'est la partie qui prend des années plutôt que des semaines.
Le quatrième mois
La construction interne échoue rarement. Elle s'arrête, simplement.
Le fournisseur du modèle retire la version sur laquelle tout avait été ajusté, et les notes se déplacent sous un système sans suite de régression pour l'attraper. Un nouveau produit sort et a besoin de scénarios, et la personne qui sait les écrire est ailleurs. Quelqu'un demande la vue gestionnaire et c'est un trimestre de travail que personne n'avait chiffré. L'ingénieur qui l'a bâti change d'équipe, et ce qu'il laisse derrière, c'est un fichier de consignes sans tests et personne qui comprenne entièrement pourquoi telle ligne s'y trouve.
Rien de tout cela n'est un échec de compétence. C'est ce qui arrive aux outils internes chiffrés comme une démonstration puis discrètement priés de se comporter comme un produit. La construction n'a jamais été la partie coûteuse. C'est la prise en charge qui l'est.
Quand vous devriez le bâtir
Il existe une version où bâtir est le bon choix, et je préfère la nommer que prétendre qu'elle n'existe pas.
Si la qualité des conversations est véritablement au cœur de la façon dont votre entreprise se démarque, si vous avez une équipe capable d'en assurer la prise en charge pendant des années plutôt qu'un ingénieur avec quelques heures libres, et si vous voulez que la grille encode quelque chose de propriétaire qu'aucun fournisseur ne pourrait vous vendre, alors bâtissez-le. Vous obtiendrez mieux que tout ce que vous pourriez acheter, parce que ce sera le vôtre.
Ce qui ne fonctionne pas, c'est l'entre-deux : bâtir parce que la démonstration avait l'air facile, puis découvrir la facture d'entretien une fois que tout le monde est passé à autre chose. C'est la version qui coûte le plus cher et livre le moins, et c'est de loin la plus courante.
La question qui vaut la peine d'être posée dans la salle n'est donc pas est-ce qu'on peut bâtir ça. Vous le pouvez. C'est : qui est responsable de la grille de notation dans dix-huit mois, et qu'arrive-t-il à chaque chiffre du système le jour où cette personne part ?
Si cette question a une réponse assurée, bâtissez-le. Sinon, vous ne choisissiez jamais vraiment entre bâtir et acheter. Vous choisissiez entre acheter et commencer.
Voilà le résultat qu'une construction interne doit reproduire, et reproduire à l'identique la prochaine fois que la même transcription passe. Pas le jeu de rôle au-dessus, qui est la moitié facile. Les trois chiffres, le comportement nommé derrière chacun, le geste correctif précis, et la garantie qu'un 3 veut dire aujourd'hui ce qu'il voulait dire le trimestre dernier. Quand nous avons changé la grille en août 2026, nous avons refait la base de référence délibérément et l'avons datée, parce qu'un changement de notation qu'on ne peut pas pointer du doigt est indiscernable d'une dérive.
« La pratique, pas la formation » n'est pas un slogan. C'est la différence entre une équipe qui sait expliquer à quoi ressemble l'excellence et une équipe qui l'exécute quand la vente ou la relation est en jeu. Les cadres ne sont pas la partie difficile. Tout le monde a les cadres. La partie difficile, c'est de les rendre automatiques, et la seule chose qui y soit jamais parvenue, c'est la pratique délibérée avec une rétroaction assez précise pour qu'on puisse agir. C'est tout le produit.