> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ouraicalling.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Meilleures pratiques

> Les schémas qui fiabilisent vos flows en production

## Rédigez vos étiquettes comme des descriptions d'outils

Les étiquettes des connexions deviennent littéralement des descriptions d'outils pour le LLM : rédigez-les comme des **conditions vues du point de vue de l'appelant** :

* ✅ `caller confirms they are an existing customer`
* ✅ `caller wants to cancel or reschedule`
* ❌ `yes`, `path A`, `continue`

Veillez à ce que les étiquettes d'un même niveau soient **mutuellement exclusives** et couvrent les cas réalistes. Si deux étiquettes se chevauchent, le routage revient à un tirage à pile ou face.

## Gardez des agents petits et centrés sur une seule tâche

Un agent = une mission (qualifier, répondre aux questions de facturation, réserver). Des instructions courtes et ciblées par agent sont plus efficaces qu'un méga-agent avec un mur de texte. Les transferts ne coûtent rien : n'hésitez pas à en abuser.

## Validez les données avec des nœuds de collecte, pas avec des prompts

Les e-mails et numéros de téléphone transcrits depuis la voix sont bruités. Les nœuds `collect` confirment et valident les informations (« C'était bien m-e-y-e-r ? ») et ne poursuivent qu'en cas de succès. Donnez toujours un nom clair à la **variable** (`callback_phone`, et non `var1`) : ces noms apparaissent tels quels dans les webhooks et le détail des appels.

## Concevez les chemins d'échec

* Donnez à chaque nœud `collect` une connexion `failed` qui mène quelque part de sensé (un transfert vers un humain ou un au revoir poli).
* Définissez volontairement le `fallback` d'un transfert à chaud : `continue` pour les transferts optionnels, `cold_transfer` quand l'appelant *doit* absolument joindre quelqu'un.
* Terminez chaque branche par un nœud `end` avec une formule de clôture adaptée.

## Testez avec des appels web, observez les événements

Lancez des [appels de test depuis le navigateur](/quickstart#2-test-it-with-a-web-call) après chaque modification. Dans la vue détaillée de l'appel, le journal des événements affiche les transitions entre nœuds, les appels d'outils, les résultats de collecte et les résultats de transfert : lisez-le comme une pile d'appels lorsque le flow se comporte mal.

## Utilisez des outils asynchrones au-delà de \~2 secondes

Un appel d'outil synchrone gèle la conversation. Marquez les webhooks lents en `async` et configurez des phrases d'attente : l'assistant reste réactif pendant que la requête s'exécute. Voir le [nœud outil](/flow-builder/nodes#tool).

## Commencez par le prompt, passez au flow quand c'est nécessaire

Prototypez d'abord le comportement avec un simple [prompt système](/assistants/overview). Quand l'appel se structure en phases distinctes ou nécessite une capture de données garantie, transposez cette structure dans un flow : les nœuds d'agent dont les instructions sont vides héritent du prompt système, si bien que la migration se fait progressivement.