Un agent vocal ne doit jamais citer un prix de mémoire

Un agent vocal qui annonce un loyer faux à un prospect n'a pas eu un problème d'intelligence artificielle. Il a eu un problème d'architecture : quelqu'un lui a laissé un chemin par lequel un chiffre pouvait lui arriver sans passer par la source de vérité.

Sur une démonstration d'agent vocal que je développe pour le secteur immobilier, la base documentaire que l'agent consulte compte 28 documents — 22 fiches de biens et 6 documents d'agence —, soit 776 lignes de texte, environ trente par fiche. Dans les 22 fiches de biens, le seul caractère numérique qui subsiste est le code de typologie à l'intérieur de l'identifiant technique du document : t2, t3, t4. Pas un prix, pas une surface, pas un diagnostic énergétique, pas une année de construction. Et cette absence n'est pas le fruit d'une relecture attentive : c'est un filtre du programme qui fabrique ce corpus, et qui écarte tout élément contenant un chiffre. Personne ne peut oublier de l'appliquer, parce que personne ne l'applique à la main.

C'est toute la thèse de cet article. La garantie qu'un agent ne racontera pas n'importe quoi sur vos prix n'est pas une phrase prudente écrite dans son personnage. C'est une frontière mécanique.

Par quel chemin un agent vocal sait ce qu'il sait

Quand un agent vocal répond à une question, l'information qu'il utilise vient d'un de ces trois endroits. C'est la distinction la plus utile à tenir, et c'est celle que la plupart des projets ne posent jamais explicitement.

« Déterministe » veut simplement dire : à question identique, réponse identique, toujours. C'est du code ordinaire, pas de l'IA. L'agent décide quand l'appeler ; il ne décide pas ce qu'il renvoie.

Trois sources possibles, et une seule qui ne ment jamais

Le piège, c'est que les deux premières sources fonctionnent très bien pour tout le reste. Un modèle qui décrit l'ambiance d'un quartier, qui reformule une procédure ou qui rassure un interlocuteur hésitant fait un travail excellent. Une base documentaire qui retrouve la bonne page de conditions rend un vrai service. Le problème n'est pas la technologie, il est catégoriel : ces deux sources sont approximatives par nature, et un prix n'admet pas d'approximation.

D'où la règle unique que j'applique, et qui tient en une ligne dans le personnage de l'agent comme dans le code : tout chiffre passe par l'outil déterministe ; l'ambiance, le quartier, l'agence passent par la base documentaire.

Pourquoi une consigne ne suffit pas

On pourrait s'arrêter là et se contenter de l'écrire dans les instructions de l'agent. Je l'écris d'ailleurs, dans la description même de l'outil de détail : « NE JAMAIS citer un prix ou une caractéristique de mémoire. » Mais une instruction donnée à un modèle de langage est une demande polie, pas une garantie. Le modèle la suit la plupart du temps. « La plupart du temps » est acceptable pour le ton d'une réponse ; ça ne l'est pas pour un montant que votre prospect va noter.

Surtout, la consigne ne protège de rien si le chiffre est déjà dans le document que l'agent vient de lire. Un modèle à qui l'on interdit d'inventer un prix, mais à qui l'on sert une fiche qui contient déjà le loyer, lira ce loyer. Il ne l'aura pas inventé, il l'aura récité. Et plus tard, quand le loyer aura bougé dans votre logiciel de gestion sans que la fiche soit régénérée, il le récitera encore. L'erreur la plus coûteuse n'est pas celle qui invente : c'est celle qui cite fidèlement une source périmée.

Le filtre qui refuse tout élément chiffré

La réponse est donc en amont, au moment où le corpus est fabriqué. Ce corpus n'est pas écrit à la main : il est généré depuis le catalogue, sans aucune intervention d'un modèle de langage, par un script qui reproduit les 28 documents à chaque exécution. Et ce script porte la garantie sous une forme qu'on ne peut pas contourner :

function figureFreeHighlights(p) {
  return p.pointsForts.filter((pf) => !hasDigit(pf));
}

Deux lignes. Tout point fort contenant un chiffre est éliminé avant d'entrer dans le document. Même logique sur les autres champs : l'accroche du bien est écartée si elle contient un nombre, et les métadonnées en tête de fichier ne portent aucun champ chiffré. Le pied de chaque fiche rappelle enfin à l'agent, dans le document lui-même, que les chiffres exacts se demandent à l'outil.

L'écart entre les deux approches se résume ainsi : une consigne dans le personnage espère un comportement, un filtre dans le générateur produit un fait. Le second se vérifie en une commande, sur les 776 lignes, à tout moment.

Ce que l'outil renvoie, et surtout ce qu'il ne renvoie jamais

L'outil de détail lit le catalogue et renvoie un objet dont la liste des champs est écrite en dur dans le code — une trentaine : référence, ville, quartier, surfaces, nombre de pièces, prix, charges, honoraires, taxe foncière, équipements, contraintes, exposition, classe énergie, année, chauffage, disponibilité. Il ne renvoie jamais l'enregistrement brut de la base.

Ce détail a l'air cosmétique. Il ne l'est pas. Le jour où votre catalogue gagne une colonne « marge de négociation » ou « nom du vendeur », un outil qui renvoie l'objet entier la transmet à l'agent, qui pourra la prononcer à voix haute devant un prospect. Un outil dont les champs sont énumérés ne transmet rien de nouveau tant que je n'ai pas ajouté la ligne moi-même. La liste des champs est une décision commerciale déguisée en détail technique.

Un champ mérite une mention à part : le prix charges comprises, calculé côté serveur. Je ne laisse pas l'agent additionner un loyer et des charges. Une addition faite par un modèle de langage est une addition probable.

L'outil qui compte

Le second outil est une recherche filtrée : vingt-cinq critères cumulatifs — transaction, type, ville, quartier, bornes de budget et de surface, nombre de pièces, équipements, étage, classe énergie, disponibilité. Il renvoie trois choses : le nombre total de correspondances, le nombre de résultats effectivement joints, et les résultats eux-mêmes, plafonnés.

« J'en ai trois dans votre budget »

Ce total change complètement la qualité de la conversation, et c'est le point à retenir si vous n'en retenez qu'un. Sans lui, un agent qui reçoit trois fiches ne sait pas s'il en existe trois ou quatre-vingts : il décrit prudemment ce qu'il a sous les yeux, et l'interlocuteur sent le flottement. Avec lui, il dit « j'en ai trois qui correspondent, je vous les présente » ou « j'en ai quarante-sept, resserrons ». Le premier est un catalogue qui parle. Le second est quelqu'un qui vous aide.

Un agent vocal embarqué sur un site pilote l'écran sans jamais recevoir son état en retour : il travaille à l'aveugle. Lui donner un décompte fiable est la façon la moins chère de lui rendre la vue — et quand ce câblage se rompt, il se rompt sans erreur et sans trace.

Le piège : ce qui ressemble à une métadonnée et finit en texte

Une erreur que j'ai payée, et qu'il n'y a aucune raison de repayer. Chaque document porte des métadonnées en tête de fichier : identifiant, ville, quartier, type, transaction. Elles ressemblent à des filtres de recherche. On imagine naturellement pouvoir demander « les documents dont la ville vaut Lyon ».

Non. Dans la chaîne de traitement réelle, ces métadonnées ne sont pas indexées comme des champs structurés : elles finissent en texte ordinaire, dans le premier fragment du document. Elles influencent la recherche par le sens, elles ne la filtrent pas. Tout filtrage exact — une ville, un budget, une typologie — doit passer par l'outil déterministe. Croire l'inverse produit exactement le genre de résultat qui a l'air juste et qui ne l'est pas.

Ce que ça change quand le catalogue bouge

C'est l'intérêt le plus concret de cette architecture. Quand un prix change dans votre système de gestion, l'outil déterministe renvoie la nouvelle valeur dès l'appel suivant. Rien à régénérer, rien à réindexer, aucun délai. Le corpus documentaire, lui, ne bouge pas : puisqu'il ne contient aucun chiffre, il ne peut pas être périmé sur un chiffre.

Cette propriété a un prérequis, et il est exigeant : il faut une source de vérité, une seule, réellement à jour. Si vos prix vivent dans trois fichiers et un logiciel qui ne se parlent pas, aucun agent vocal ne réglera ça — il exposera le problème plus vite et à voix haute. C'est un travail qui se fait avant, sur les données et les intégrations, et c'est souvent lui le vrai chantier : c'est aussi ce que raconte cette étude de cas.

Ce que je vérifie avant de laisser un agent parler à un prospect

• Un chiffre peut-il atteindre l'agent autrement que par un outil ? Si oui, par quel chemin, et pourquoi.
• La base documentaire contient-elle un prix, une surface, un diagnostic ? La vérification doit être une commande, pas une relecture.
• L'outil renvoie-t-il une liste de champs énumérée, ou l'enregistrement brut de la base ?
• La recherche renvoie-t-elle le nombre total de correspondances, ou seulement les résultats joints ?
• Un identifiant inconnu produit-il une erreur explicite, ou un silence que l'agent comblera tout seul ?
• Le corpus se régénère-t-il par une commande, ou a-t-il été écrit à la main une fois pour toutes ?

Cette liste ne parle presque pas d'intelligence artificielle. C'est normal : la fiabilité d'un agent vocal ou d'un agent IA se joue en grande partie dans la plomberie qui l'entoure, pas dans le modèle. Le modèle est bon. C'est le chemin des données jusqu'à lui qu'il faut tenir.

Si vous envisagez un agent en contact avec vos clients et que la question « et s'il dit n'importe quoi sur nos tarifs » est celle qui vous retient, prenons trente minutes pour regarder où vivent vos chiffres aujourd'hui, et par quels chemins ils pourraient arriver jusqu'à lui.