> ## 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.

# Bonnes pratiques du générateur de Flow

> Les schémas qui fiabilisent vos flows en production

Des schémas pratiques pour construire des [flows](/fr/flow-builder/overview) fiables : libellés de connexions, structuration des agents, validation des données et tests avant la mise en production.

## Rédigez des libellés de connexion clairs

Rédigez les libellés des connexions comme des **conditions claires 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`](/fr/flow-builder/nodes#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](/fr/quickstart#2-testez-le-dans-le-navigateur) 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. Il permet d'identifier rapidement l'étape qui ne se comporte pas comme prévu.

## Utilisez des outils asynchrones pour les requêtes lentes

Pour les webhooks lents, activez **Run asynchronously** et configurez des phrases d'attente : la conversation peut continuer pendant l'exécution de la requête. Voir le [nœud outil](/fr/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](/fr/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.