IA générative au téléphone : trois garde-fous avant la production.

Nous voyons trop d’équipes confondre démonstration et service. Un LLM au téléphone n’est pas prêt parce qu’il répond bien en test. Il est prêt quand son périmètre est borné, sa supervision humaine réelle, et sa trace exploitable après coup.

Sans ces trois garde-fous, vous n’industrialisez pas une capacité. Vous exposez la marque, le juridique et le parcours client à des réponses non maîtrisées. Le sujet n’est pas la performance du modèle. Le sujet est le contrôle opérationnel, la preuve et la reprise en main quand la conversation dévie.

Bornage du périmètre

Le bot doit savoir ce qu’il peut dire. Il doit aussi savoir ce qu’il doit refuser. Tout le reste sort du champ. Un LLM généraliste, laissé libre, improvise vite sur les sujets sensibles. Au téléphone, cette improvisation devient une promesse, une erreur ou une fuite d’information.

Le bornage ne se limite pas à une liste de réponses attendues. Il doit couvrir les intentions autorisées, les actions permises, les sujets interdits et les cas de bascule vers un humain. Sinon, le modèle comble les vides avec des formulations plausibles, mais non validées. C’est là que naissent les écarts: un remboursement évoqué trop tôt, une donnée personnelle répétée, une exception contractuelle inventée.

Demandez : "Pouvez-vous me montrer la matrice exacte des intentions autorisées, des refus et des escalades ?" Exigez un critère vérifiable dans le contrat ou la recette: chaque intention doit être versionnée, testée et associée à un comportement de refus explicite. Le piège classique est la zone grise. Son symptôme: le bot répond avec assurance sur un cas limite, puis l’éditeur parle de “comportement probabiliste” après coup.

Demandez aussi : "Qui valide chaque modification du périmètre, et où voit-on l’historique des versions ?" Sans versioning des règles, vous ne saurez jamais quel bot parlait à quel moment, ni avec quelle autorisation. Une modification sans journal d’audit crée une rupture de preuve, même si l’interface semble inchangée.

Supervision humaine réelle

Une supervision affichée n’est pas une supervision. Il faut un humain capable d’intervenir pendant l’échange, pas après. Le monitoring différé rassure les comités. Il ne protège pas le client en direct.

La reprise doit être immédiate et sans perte de contexte. Si le conseiller reprend l’appel comme s’il découvrait le dossier, la promesse d’automatisation se transforme en friction. Le bon dispositif transmet l’historique, l’intention détectée, les données déjà collectées et le motif de transfert. Sinon, le client répète tout, et l’expérience se dégrade au moment précis où le système prétend aider.

Un bot sans reprise humaine immédiate n’est pas autonome. Il est surtout incontrôlé.

Posez des questions concrètes : "Qui voit les conversations en temps réel ?" et "Quel signal déclenche la reprise humaine ?" Exigez un seuil mesurable, par exemple un transfert en moins de quelques secondes sur mot-clé sensible, silence prolongé ou doute de classification. Le piège précis, c’est la supervision décorative: un tableau de bord consulté après coup. Son symptôme est simple: l’incident est découvert dans les rapports, jamais pendant l’appel.

Demandez aussi : "Le conseiller récupère-t-il le contexte complet, y compris les derniers échanges et les champs déjà remplis ?" Vérifiez contractuellement que la reprise conserve la session, l’horodatage et le motif d’escalade. Sans cette continuité, l’humain devient un second niveau de saisie, pas un filet de sécurité.

Traçabilité complète

Chaque réponse doit être auditable a posteriori. Pas seulement le transcript brut. Il faut la version du modèle, les règles appliquées, les sources utilisées, et les filtres de sécurité actifs. Sans cela, vous ne pourrez pas expliquer une réponse litigieuse.

La traçabilité sert à reconstruire une interaction contestée, pas à produire un simple historique de conversation. Dans un appel vocal, le transcript seul ne suffit pas. Il manque le contexte de routage, les paramètres de sécurité, les prompts système, les éventuelles récupérations documentaires et les décisions de refus. Sans ces éléments, une réponse paraît sortie de nulle part, et personne ne peut dire si le problème vient du modèle, de l’intégration ou de la règle métier.

Demandez : "Pouvez-vous exporter, pour chaque appel, le transcript, les métadonnées, la version du modèle et les décisions de routage ?" Exigez un export horodaté, corrélé par identifiant unique, et lisible hors de l’outil. Le piège précis: des logs fragmentés entre plusieurs consoles. Son symptôme est immédiat: impossible de reconstituer la séquence exacte quand un client conteste une réponse.

Demandez aussi la durée de conservation, les droits d’accès et la capacité de restitution bout en bout. Si l’éditeur ne sait pas restituer une conversation complète avec ses paramètres, vous n’avez pas de preuve exploitable. Vous avez seulement des traces partielles, utiles pour l’exploitation quotidienne, mais faibles face au juridique ou à l’audit.

Gouvernance de mise en production

Le vrai sujet n’est pas de lancer vite. Le vrai sujet est de lancer sous contrôle. Une mise en production sérieuse exige un comité de décision clair, des critères de sortie du pilote, et un droit d’arrêt immédiat. Sans cela, l’expérimentation devient une production déguisée.

Le passage en production doit reposer sur des seuils mesurables. Taux d’escalade acceptable. Zéro réponse hors périmètre sur les cas critiques. Traçabilité complète sur un échantillon testé. Temps de reprise humaine compatible avec l’attente client. Ces critères évitent les débats d’opinion. Ils transforment un ressenti de qualité en contrôle vérifiable, et ils donnent un cadre pour arrêter avant que l’écart ne devienne visible pour les clients.

Demandez : "Qui a le droit de couper le service, et en combien de temps ?" Exigez un rollback documenté, avec retour à une version précédente du bot, des règles et des connecteurs. Le piège précis est l’incident mal classé. Son symptôme: une erreur de modèle est traitée comme un bug d’intégration, puis personne ne corrige la bonne couche.

Demandez aussi un tableau de qualification des incidents séparant modèle, règles, données et intégration. Sans cette séparation, le pilotage se brouille. Vous ne saurez pas si le problème vient d’un prompt, d’une base documentaire, d’un flux téléphonique ou d’un paramètre de sécurité trop permissif.

Le contrat doit refléter le contrôle

Le contrat doit reprendre le périmètre, la supervision et la traçabilité. Sinon, vous laissez des zones d’ombre à l’exécution. Un engagement commercial sans cadre technique précis crée des attentes impossibles à tenir. Et une promesse impossible finit toujours en arbitrage défensif.

Faites inscrire les responsabilités d’édition, de supervision et de conservation des traces. Faites préciser les engagements de disponibilité des journaux, des exports et des historiques de configuration. Faites aussi valider les clauses de réversibilité. Si le dispositif s’arrête, vous devez récupérer les conversations, les paramètres, les règles et les preuves utiles pour continuer à opérer ou à auditer.

Demandez : "Quelle annexe opérationnelle décrit les garde-fous, les seuils d’escalade et les preuves conservées ?" Exigez un document contractuel séparé des conditions générales, avec les responsabilités nommées et les délais de restitution. Le piège précis est le contrat trop abstrait. Son symptôme: tout semble couvert en réunion, puis rien n’est opposable quand il faut prouver qui a fait quoi.

Sans cette annexe, le téléphone devient un canal d’exposition. Avec elle, vous gardez la maîtrise du service, des preuves et des sorties de crise. Le contrat cesse d’être une promesse générale et devient un instrument de contrôle réellement exploitable.