> ## Documentation Index
> Fetch the complete documentation index at: https://docs.famulor.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Rédaction de prompts
> Structurez, resserrez et améliorez le prompt que votre assistant suit à chaque appel
Que votre assistant s'appuie sur un prompt système unique ou sur un [flux](/fr/flow-builder/overview) 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](/fr/assistants/overview).
## 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 :
```text theme={null}
## Identity
Who the assistant is, which company it represents, what it specializes in.
## Style
Tone, formality, sentence length, how it handles humor or empathy.
## Knowledge
The facts it needs on hand — products, prices, policies, hours.
## Guidelines
Rules it must always follow (verify identity before sharing account
details, never promise a delivery date, one question at a time).
## Response patterns
Step-by-step handling for specific situations — pricing questions,
objections, what to say while a tool call is running.
## Limits
What it must never do, and what to say instead.
```
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 :
| Vague | Précis |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| « Aidez les clients avec leurs questions de facturation. » | « Quand un appelant mentionne une question de facturation, demandez son numéro de facture (format INV-XXXXX), puis recherchez son compte. » |
| « Soyez amical. » | « Reconnaissez ce que l'appelant a dit avant de répondre — ne passez pas directement à la question suivante. » |
| « Gérez les objections. » | « Si l'appelant dit qu'il n'est pas intéressé, demandez ce qui devrait changer pour que ça ait du sens — ne répétez pas l'argumentaire. » |
É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](/fr/assistants/built-in-tools#transferts).
* **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](/fr/assistants/knowledge-base).
## Rédiger des conditions claires pour les outils et les transferts
Chaque [outil intégré](/fr/assistants/built-in-tools) et chaque bord de [flux](/fr/flow-builder/nodes) 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 :
```text theme={null}
## Tools
- check_availability — before offering any appointment time.
- book_appointment — only once the caller confirms a slot, with their
name and email.
- Transfer to Sales — when the caller asks for a quote or pricing.
```
[Milian](/fr/assistants/milian-copilot) 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](/fr/assistants/knowledge-base). 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
| Erreur | Correction |
| ------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Trop vague (« soyez serviable ») | Ajoutez des règles concrètes et des exemples de formulation |
| Trop rigide — tout est scripté | Donnez des consignes et des exemples, pas une transcription |
| Surcharge d'informations | Déplacez la documentation de référence vers une base de connaissances |
| Instructions contradictoires | Relisez le prompt dans l'ordre — une règle ultérieure ne doit jamais contredire une règle antérieure |
| Aucune règle pour les questions inattendues | Ajoutez l'un des schémas de repli ci-dessus |
| Déclencheurs d'outil ou de transfert vagues | Nommez la situation exacte, pas « quand c'est approprié » |
## Déployer et itérer
Aucun prompt n'est terminé au lancement — traitez-le comme un document vivant.
É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.
Utilisez le bouton **Test** de l'éditeur pour une vérification rapide en voix ou en chat, ou configurez des [Simulations](/fr/assistants/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.
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.
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 :
| Symptôme | Correction probable |
| ----------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Réponses génériques, uniformisées | Ajoutez des exemples précis et des scénarios nommés |
| Les informations requises continuent de manquer | Listez exactement quoi collecter, et dans quel ordre |
| Les transferts arrivent trop tôt ou trop tard | Resserrez la formulation de la condition de transfert |
| Affirme quelque chose qui n'est pas vrai | Ajoutez une règle explicite du type « dites que vous ne savez pas plutôt que de deviner » |
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](/fr/assistants/conversation-quality#garde-fous) comme filet de sécurité pour ce qui reste.
Voir [Rédiger pour l'oral](/fr/assistants/prompting-for-speech) pour que les numéros de téléphone, les dates et autres détails prononcés sonnent juste, et [Exemples de prompts](/fr/assistants/example-prompts/overview) pour des points de départ prêts à adapter.