Skip to main content
Que votre assistant s’appuie sur un prompt système unique ou sur un flux construit à partir de nœuds agent, le même savoir-faire s’applique : le modèle ne connaît que ce que vous lui dites. Un prompt clair et bien structuré est l’un des plus grands leviers dont vous disposez sur la qualité des appels — souvent plus que le modèle ou la voix choisis.
Cette page porte sur la rédaction de bonnes instructions. Pour savoir où vit le prompt système, et quand privilégier un flux plutôt qu’un prompt unique, voir Prompt système ou générateur de Flow.

​
Structurer votre prompt en sections nommées

N’écrivez pas un seul long paragraphe. Découpez le prompt en sections étiquetées, chacune avec un seul rôle. C’est plus facile à écrire, plus facile à mettre à jour ensuite sans rien casser d’autre, et plus facile à suivre pour le modèle :
Les sections peuvent être réutilisées entre assistants et modifiées indépendamment, sans toucher au reste du prompt.

​
Soyez précis, pas vague

« Soyez serviable et professionnel » ne donne au modèle aucune prise concrète. Associez chaque règle à un exemple concret : Évitez aussi l’excès inverse. Scripter chaque phrase possible supprime la fluidité naturelle qui rend un assistant vocal agréable — donnez des règles et des exemples, pas une transcription à réciter.

​
Gérer ce que vous n’avez pas anticipé

Tout prompt finit par rencontrer une question qu’il ne couvre pas. Décidez à l’avance comment l’assistant doit réagir — choisissez un schéma (ou combinez-les) :
  • Par défaut, puis transférer. « Si vous ne connaissez pas la réponse, dites-le clairement et proposez de mettre l’appelant en relation avec quelqu’un qui la connaît », puis appuyez-vous sur le transfert d’appel.
  • Poser une question de clarification. « Si la demande n’est pas claire, posez une courte question de relance avant de décider comment l’orienter. »
  • Vérifier d’abord la base de connaissances. Si vous en avez connecté une, demandez à l’assistant de la consulter avant de se rabattre sur un transfert — voir Bases de connaissances.

​
Rédiger des conditions claires pour les outils et les transferts

Chaque outil intégré et chaque bord de flux n’est fiable qu’à la hauteur du texte de condition décrivant quand il doit se déclencher. Des conditions vagues produisent un comportement vague. Deux niveaux de détail valides pour une condition de fin d’appel, selon le degré de contrôle souhaité :
  • Simple : « Terminez l’appel une fois que toutes les questions ont reçu une réponse et que l’appelant n’a plus besoin d’aide. »
  • Détaillé : « Terminez aussi l’appel après une réservation réussie, un au revoir explicite, ou quand la conversation est clairement terminée — mais jamais pendant que l’appelant parle encore. »
La même précision s’applique à une condition de transfert : décrivez exactement ce que l’appelant dit ou demande, pas seulement « quand c’est approprié ». Redites ensuite la même chose dans le prompt lui-même. Une courte section nommant chaque outil et le moment où il s’applique donne à l’assistant une référence ordonnée unique — ça vaut les quelques lignes supplémentaires dès que plus d’un outil pourrait plausiblement se déclencher :
Milian peut aider à rédiger et resserrer ce type de texte de condition à partir d’une description simple de votre processus — décrivez ce qui doit se passer, et demandez une instruction courte, façon checklist, que vous pouvez coller directement dans le champ.

​
Quelle longueur doit avoir un prompt ?

  • Court (environ 50–200 mots) — assistants simples, à objectif unique.
  • Moyen (environ 200–500 mots) — plusieurs scénarios, chacun avec une règle claire.
  • Long (500+ mots) — ralentit le modèle et augmente le risque qu’il perde le fil d’une instruction antérieure.
Si vous vous surprenez à coller un catalogue produit, une longue FAQ ou des politiques détaillées, déplacez plutôt ce contenu vers une base de connaissances. Les bases de connaissances sont consultables, n’allongent pas le prompt à chaque appel, et peuvent être mises à jour sans toucher à l’assistant.

​
Erreurs courantes de rédaction de prompts

​
Déployer et itérer

Aucun prompt n’est terminé au lancement — traitez-le comme un document vivant.
1

Couvrez d'abord les cas courants

Écrivez des instructions claires pour vos scénarios les plus fréquents avant de traquer chaque cas limite. Un prompt qui gère bien la majorité des appels réels vaut mieux qu’un prompt qui gère à moitié tout.
2

Testez avant que quelqu'un d'autre ne l'entende

Utilisez le bouton Test de l’éditeur pour une vérification rapide en voix ou en chat, ou configurez des Simulations pour dérouler automatiquement des scénarios courants, des cas limites et un ou deux appelants difficiles avant que le prompt n’en rencontre un vrai.
3

Passez en production et observez de près

Examinez de près les nouvelles transcriptions d’appel juste après le lancement — elles montrent exactement où l’assistant a hésité, deviné, ou mal géré une situation.
4

Affinez à partir de ce que vous avez observé

Ajoutez l’exemple, la règle ou le repli précis qui aurait corrigé chaque raté. De petites modifications ciblées valent mieux que réécrire tout le prompt.
Quelques symptômes courants et leur correction habituelle : Couvrir intégralement tous les appels possibles n’est pas un objectif réaliste — le langage est trop varié pour ça. Visez à réduire l’écart progressivement, et appuyez-vous sur les garde-fous et un transfert vers une personne comme filet de sécurité pour ce qui reste.
Voir Rédiger pour l’oral pour que les numéros de téléphone, les dates et autres détails prononcés sonnent juste, et Exemples de prompts pour des points de départ prêts à adapter.