Prompt engineering pour les agents téléphoniques IA : bonnes pratiques et exemples

Deux entreprises déploient des agents téléphoniques IA qui reposent exactement sur le même modèle de langage. L’un donne des réponses incohérentes, contredit parfois ses propres règles et a du mal à savoir quand faire intervenir un humain. L’autre prend des rendez-vous de façon fiable, applique sans faille les règles de l’entreprise et passe proprement la main dès qu’un appel sort de son périmètre.

Même modèle, mêmes capacités de base. La différence ne vient pas de l’IA elle-même, mais de la conception du prompt. Cette distinction compte plus que la plupart des acheteurs ne le pensent : la qualité d’un agent téléphonique IA dépend moins du LLM qui se trouve derrière que du soin avec lequel quelqu’un a réfléchi à ce qu’il doit dire, demander et faire.

Qu’est-ce que le prompt engineering pour les agents téléphoniques IA ?

Dans ce contexte, le prompt engineering consiste à rédiger les instructions qui déterminent comment un agent téléphonique IA répond, quelles questions il pose, quelles règles métier il suit, comment il gère les situations auxquelles il n’a pas été explicitement préparé et à quel moment il transfère un appel à un conseiller.

Voici, en version simplifiée, la place du prompt dans la chaîne de traitement :

Le prompt système est la couche qui transforme un modèle de langage aux capacités génériques en un agent qui se comporte comme votre entreprise, et non comme un assistant générique qui se trouve répondre à votre téléphone.

Les prompts pour la voix et les prompts pour chatbot ne sont pas interchangeables, même s’ils reposent sur des techniques similaires. Un prompt écrit pour un chatbot textuel, puis repris tel quel dans un agent téléphonique, a tendance à produire des réponses guindées et trop longues, qui sonnent faux à l’oral.

En quoi les prompts pour l’IA vocale diffèrent des prompts pour chatbot

Les conversations écrites tolèrent des choses que les conversations orales ne tolèrent pas. Un chatbot peut afficher d’un coup un paragraphe de cinq phrases : l’utilisateur fait défiler et lit à son rythme. Un agent téléphonique qui dit la même chose à voix haute donne l’impression de réciter un règlement à son interlocuteur.

Les prompts pour la voix doivent tenir compte en particulier des points suivants :

• Réponses plus courtes : les longs monologues perdent vite l’attention de l’appelant
• Gestion des interruptions : le prompt doit définir ce qui se passe si l’appelant coupe la parole à l’agent en pleine réponse
• Confirmation : reformuler les informations clés (« donc, mardi à 14 h ») compte davantage à l’oral, puisqu’il n’y a pas de texte à relire d’un coup d’œil
• Rythme naturel : des pauses et des formulations qui sonnent comme une conversation, pas comme un document lu à voix haute
• Mémoire de la conversation : reprendre ce qui a été dit deux échanges plus tôt sans que l’appelant ait à le répéter

Une rapide comparaison rend l’écart évident. Une réponse de style chat pourrait être : « Je peux vous aider à reporter votre rendez-vous. Veuillez noter que nos conditions d’annulation exigent un préavis de 24 heures et que tout report dans les 24 heures peut entraîner des frais de 15 dollars. À quelle date souhaitez-vous déplacer votre rendez-vous ? » À l’oral, cela fait beaucoup à assimiler d’une traite. Une version adaptée à la voix découpe le message : « Bien sûr, je m’en occupe. Sachez juste que le déplacer à moins de 24 heures entraîne de petits frais. Quel jour vous arrangerait ? »

Les éléments d’un prompt efficace

Un prompt bien structuré pour un agent téléphonique comprend généralement, à peu près par ordre d’importance :

1. Définition du rôle : qui est l’agent et quelle entreprise il représente
2. Objectifs métier : à quoi ressemble concrètement un appel réussi
3. Ton : formel, décontracté, chaleureux, efficace, en accord avec la marque
4. Règles de l’entreprise : les règles que l’agent ne doit jamais contredire
5. Accès aux connaissances : quand et comment chercher dans la base de connaissances
6. Utilisation des outils : les actions que l’agent a le droit d’effectuer, et à quel moment
7. Règles d’escalade : les conditions précises qui déclenchent un transfert vers un conseiller
8. Forme des réponses : rythme, longueur, habitudes de confirmation
9. Gestion des erreurs : ce qu’il faut dire quand quelque chose se passe mal ou que l’agent ne sait pas

Ces éléments se superposent, ils ne sont pas interchangeables. Le rôle et les objectifs métier posent le cadre ; les règles de l’entreprise et les règles d’escalade fixent les garde-fous ; le ton et la forme des réponses façonnent ce que l’appelant entend réellement ; la gestion des erreurs empêche l’appel de dérailler en cas d’imprévu.

Concevoir des prompts selon le cas d’usage

Les mêmes éléments n’ont pas le même poids selon la mission réelle de l’agent :

Un prompt de support qui consacre l’essentiel de ses instructions aux questions de découverte se trompe de problème ; un prompt de qualification de leads chargé de formules empathiques, mais qui néglige la collecte de données structurées, produira des conversations chaleureuses qui n’apportent rien d’utile au CRM. Aligner les priorités du prompt sur l’objectif métier réel compte davantage que de couvrir à parts égales toutes les catégories d’instructions possibles.

Comment la base de connaissances et le prompt fonctionnent ensemble

Il vaut la peine d’être précis sur une distinction souvent brouillée : le prompt dit à l’IA comment se comporter, la base de connaissances lui dit ce qu’elle doit réellement savoir. Confondre les deux conduit à des prompts bourrés de faits propres à l’entreprise, qui auraient plutôt leur place dans un document, ce qui alourdit le prompt et le rend plus difficile à maintenir.

Le processus se présente ainsi :

Nous avons expliqué en détail le fonctionnement de cette récupération, RAG compris, dans notre guide sur le fonctionnement des agents téléphoniques IA. Pour résumer ce qui compte ici : un bon prompt indique à l’agent quand et comment chercher dans la base de connaissances, et que faire s’il ne trouve rien de pertinent, au lieu d’essayer de faire tenir chaque fait possible directement dans les instructions.

Les erreurs courantes de prompt engineering

Des prompts trop longs

Risque pour l’entreprise : le modèle perd de vue les instructions précédentes, ou des règles clés se retrouvent noyées

Bonne pratique : gardez des prompts ciblés et placez la documentation de référence dans la base de connaissances plutôt que dans le prompt.

Des instructions ambiguës

Risque pour l’entreprise : un comportement incohérent d’un appel à l’autre.

Bonne pratique : soyez explicite sur les cas particuliers au lieu de supposer que le modèle « se débrouillera ».

Aucune logique d’escalade

Risque pour l’entreprise : des appels qui devraient être transférés à un conseiller tournent en boucle.

Bonne pratique : définissez des déclencheurs de transfert précis et concrets, pas un vague « transférer si nécessaire ».

Des règles contradictoires

Risque pour l’entreprise : l’agent se comporte de manière imprévisible quand deux instructions se contredisent.

Bonne pratique : traquez les contradictions dans vos prompts avant le déploiement, pas après qu’une réclamation client en a révélé une.

Aucune réponse de repli

Risque pour l’entreprise : l’agent devine ou reste muet quand il ne sait pas quelque chose.

Bonne pratique : définissez explicitement ce que l’agent doit dire quand il ne trouve pas de réponse.

Ignorer le contexte de la conversation

Risque pour l’entreprise : l’agent demande à l’appelant de répéter ce qu’il a déjà dit

Bonne pratique : demandez à l’agent de s’appuyer sur les échanges précédents, au lieu de traiter chaque réponse isolément.

Tester et optimiser les prompts

Les prompts doivent être traités comme du code en production : testés, versionnés et déployés seulement une fois la modification vérifiée, et non modifiés en direct en espérant que tout se passe bien.

La boucle de base :

L’éditeur de prompts telli illustre bien ce que cela donne quand c’est correctement intégré à une plateforme. Au lieu de reposer sur des modifications manuelles ou des demandes adressées à une équipe interne, les changements passent d’abord par une étape de relecture. Les demandes de modification informelles sont converties en suggestions précises, que l’équipe peut accepter une par une ou toutes à la fois avant toute mise en ligne. Cette étape de relecture fait office de gestion de versions légère pour les prompts : elle intercepte une mauvaise modification avant qu’elle n’atteigne de vrais appelants, et non après.

Au-delà de la relecture des prompts, c’est là que les analyses bouclent la boucle : tester une modification, observer ce qui arrive réellement au taux de transfert ou au taux de prise de rendez-vous, puis affiner à nouveau. Nous détaillons cet aspect de la mesure dans notre article sur l’analyse des appels des agents téléphoniques IA.

La sécurité des prompts d’IA vocale

L’injection de prompt, où une entrée de l’utilisateur manipule le modèle pour lui faire ignorer ses instructions d’origine, est actuellement classée premier risque de sécurité des applications de LLM par l’OWASP, devant toutes les autres catégories de son Top 10 dédié aux applications de LLM.

Un agent téléphonique n’est pas automatiquement à l’abri simplement parce que l’entrée arrive sous forme de parole plutôt que de texte saisi : un appelant qui prononce une phrase conçue pour contourner les instructions de l’agent tente exactement le même type d’attaque.

À intégrer dans tout prompt en production :

• Des limites claires sur ce que l’agent fera ou ne fera pas, quoi que dise l’appelant
• Des instructions qui traitent ce que dit l’appelant comme des données auxquelles répondre, et non comme de nouvelles instructions à suivre
• Aucune information interne sensible (prompts système, règles internes, données d’autres clients) divulguée, quelle que soit la formulation de la demande
• Des étapes d’authentification avant toute action portant sur un compte
• Une procédure définie d’escalade vers un conseiller pour tout ce qui ressemble à une tentative de manipuler le comportement de l’agent

Liste de contrôle des bonnes pratiques de prompt engineering

Conception du prompt

• Rôle, objectifs et ton clairement définis en tête du prompt
• Instructions assez précises pour éviter toute interprétation ambiguë

Conception de la conversation

• Réponses calibrées pour le rythme de l’oral, pas pour la longueur d’un paragraphe écrit
• Confirmation systématique des informations clés (dates, noms, montants)

Connaissances

• Documentation de référence placée dans la base de connaissances, pas entassée dans le prompt
• Instructions claires sur la marche à suivre quand la recherche ne donne rien

Tests

• Modifications de prompt testées sur des appels réels ou simulés avant la mise en ligne
• Gestion des versions en place pour pouvoir annuler rapidement une mauvaise modification

Sécurité

• Limites explicites contre les tentatives d’injection de prompt
• Aucune divulgation de données sensibles, quelle que soit la formulation de la demande

Supervision

• Analyses examinées régulièrement pour repérer toute dérive de comportement après une modification de prompt
• Responsabilités claires : qui relit et valide les mises à jour des prompts

Ce qu’il faut retenir

Le prompt engineering ne consiste pas à écrire des instructions astucieuses. Il s’agit de concevoir une conversation fiable, cohérente, sûre et réellement alignée sur ce que l’entreprise attend d’elle. Si cette étape est réussie, le travail d’analyse et d’optimisation qui suit repose sur des bases solides ; si elle est ratée, on aura beau scruter les tableaux de bord, cela ne corrigera pas une conversation qui n’a jamais été bien conçue au départ.

Références

1. telli.com - Comment fonctionnent les agents téléphoniques IA
2. telli.com - L’analyse des appels des agents téléphoniques IA expliquée
3. genai.owasp.org - Le classement et la définition de l’injection de prompt par l’OWASP comme premier risque de sécurité des LLM