Adèle

Un agent qui se contente de répondre à des questions apporte peu de choses. L'intérêt commence quand il agit sur les données, et c'est aussi à ce moment-là que le risque apparaît.

Un recruteur répète les mêmes gestes toute la journée : retrouver une annonce, filtrer des candidatures, appeler quelqu'un, replanifier un entretien, relancer. Chacun de ces gestes prend une ou deux minutes. Mis bout à bout, ils occupent l'essentiel du temps de travail.

Automatiser la lecture est simple. Automatiser l'écriture, c'est-à-dire créer, modifier et envoyer, demande beaucoup plus de précautions. Un modèle qui se trompe en lecture donne une réponse fausse et on la corrige. Un modèle qui se trompe en écriture abîme les données d'un client.

Il fallait aussi que tout cela fonctionne au téléphone, avec de vrais candidats et en temps réel.

La mémoire entre les tours d'outils

« Les appels de cette semaine », puis « rappelle le premier ». Si le contexte ne conserve que les identifiants des résultats précédents et pas les données associées, l'agent ne sait plus qui est « le premier ». Il repose la question, ou il désigne la mauvaise personne.

La correction passe par les outils. J'ai standardisé le format de retour de tous les outils : un même contenant, une même clé d'identité, un même libellé. Cette normalisation corrige d'un seul coup la mémoire entre les tours, le masquage des données personnelles et la qualité des résumés.

L'interruption au téléphone

Quand un candidat coupe la parole, arrêter la lecture audio ne suffit pas. Le modèle croit avoir prononcé toute sa phrase et poursuit comme s'il avait été écouté. Il faut tronquer son historique et lui indiquer où la lecture s'est réellement arrêtée. Le calcul se fait sur l'audio effectivement entendu, pas sur l'audio envoyé, parce que la téléphonie met le son en tampon.

Sans cette correction, le décalage s'accumule à chaque interruption et l'agent finit par répondre à la question précédente.

Un prompt système qui grossit

Un prompt système qui enfle indique presque toujours des outils mal conçus : on écrit en langage naturel ce qui aurait dû être une contrainte de schéma. Corriger les outils permet de raccourcir le prompt, ce qui améliore à la fois la fiabilité, la latence et le coût.

Ce qui n'apparaît qu'en production

Les fournisseurs de téléphonie rejouent leurs webhooks. C'est documenté et c'est normal. Deux appelants peuvent aussi confirmer le même créneau à deux cents millisecondes d'intervalle. Ces situations ne se présentent pas en démonstration, elles se présentent une fois le service ouvert aux utilisateurs. Le traitement est classique : rendre chaque opération idempotente, et poser un verrou là où deux écritures peuvent se croiser.