retell ai n8n : orchestrer un agent vocal en PME en 2026

En bref

• Une intégration retell ai n8n demande une instance n8n, un compte Retell AI, une clé API et un agent configuré. Un numéro Retell ou importé s’ajoute pour les appels sortants.
• Retell AI conduit la conversation et gère l’appel. n8n reçoit les événements, exécute les actions métier et traite les résultats.
• Trois voies couvrent les besoins documentés : le nœud Retell AI, les webhooks et les appels directs à l’API Retell AI.
• La mise en production exige une URL publique sécurisée, une vérification des requêtes entrantes, des actions idempotentes, des alertes et une reprise sur erreur testée.
• L’automatisation perd son intérêt lorsque les appels restent rares, que les règles changent fréquemment ou qu’un jugement humain demeure nécessaire.

Une personne reçoit les appels, recherche une fiche, vérifie une disponibilité, saisit un compte rendu, puis avertit un collègue. Avant de construire une intégration retell ai n8n, il faut chiffrer cette réalité : qui intervient, combien de fois par semaine, quelles données circulent et quelles décisions engagent l’entreprise.

Cette cartographie détermine la place de chaque outil. Retell AI porte la conversation téléphonique. n8n orchestre les déclencheurs, les actions et les traitements en aval. Le choix entre nœud, webhook et appel d’API dépend ensuite du moment où n8n doit agir : avant l’appel, pendant l’échange ou après sa clôture.

En bref

Les prérequis viennent avant les bénéfices : accès à n8n, compte et clé API Retell AI, agent configuré, URL publique pour les fonctions appelées en direct et numéro compatible pour les appels sortants.

Le nœud Retell AI sert aux opérations exposées par son paquet. Un webhook reçoit une Custom Function ou un événement. Un appel direct à l’API couvre une opération absente du nœud ou exigeant un contrôle plus fin.

Chaque appel doit porter un identifiant de corrélation relié à l’exécution n8n et au call_id Retell. La supervision suit au minimum les erreurs HTTP, les délais dépassés, les doublons, les appels non aboutis et les branches restées sans réponse. Une reprise ne doit jamais répéter aveuglément l’action métier.

Avant de connecter retell ai n8n : vérifier que le processus s’y prête

Cartographier l’appel, les actions humaines et les données échangées

Prenez un appel représentatif et déroulez-le sans raccourci. Notez son déclencheur, l’identité de la personne appelée ou appelante, les informations consultées, les décisions prises, les écritures effectuées et la suite donnée.

Ajoutez la fréquence hebdomadaire et les exceptions. Une opération répétée avec des entrées structurées se prête mieux à un workflow qu’un échange rare dont chaque issue dépend du contexte. Recensez aussi les systèmes touchés : CRM, agenda, messagerie, base interne ou service accessible par API. Leur documentation doit confirmer les opérations possibles et leur mode d’authentification.

Définir ce qui doit rester sous contrôle humain

Une confirmation de disponibilité issue d’un système à jour peut suivre une règle déterministe. Une remise commerciale, un conseil sensible ou une décision prise à partir d’informations contradictoires réclame un contrôle humain.

Prévoyez le passage de relais dès le cadrage : quel événement l’impose, quelles données accompagnent la demande et qui la reprend. Si le workflow échoue, Retell AI doit suivre une consigne explicite, par exemple annoncer l’impossibilité de terminer l’action et orienter la conversation vers le canal retenu.

Reconnaître les cas où l’automatisation n’est pas rentable

Renoncez ou réduisez le périmètre lorsque le volume d’appels ne couvre pas le coût de construction et de supervision, lorsque les règles changent plus vite que le workflow, ou lorsque les données sources restent trop incomplètes.

Le même constat vaut si chaque erreur impose une enquête longue, si aucune personne ne peut traiter les alertes ou si le consentement et la conservation des données ne peuvent pas être encadrés. Un compte rendu assisté, validé par une personne, peut alors coûter moins cher à maintenir qu’une action entièrement automatisée.

Choisir l’architecture Retell AI–n8n avant de construire le workflow

Retell AI gère l’agent vocal et les appels. n8n enchaîne les systèmes, applique les règles et conserve la trace des traitements. Cette séparation doit rester lisible dans l’architecture et dans les responsabilités d’exploitation.

Nœud Retell AI, webhook ou appel direct à l’API : quel mécanisme pour quelle opération

Besoin	Mécanisme adapté	Point de vigilance
Lancer un appel depuis n8n	Nœud Retell AI ou API Retell AI	Conserver le call_id et traiter tout refus de création
Exécuter une action pendant la conversation	Webhook n8n appelé par une Custom Function Retell	Répondre dans le délai attendu et valider les paramètres
Lire ultérieurement le résultat	Get Call par nœud ou API	Attendre que les champs différés existent
Réagir à l’analyse post-appel	Webhook call_analyzed	Dédupliquer l’événement avant toute écriture métier
Couvrir une opération absente du nœud	Appel direct à l’API	Gérer explicitement authentification, erreurs et évolution de l’API

Le paquet officiel se nomme n8n-nodes-retellai, bien qu’il s’installe dans la rubrique Community Nodes. Sa documentation donne une vue générale des opérations. Elle ne dispense pas de contrôler l’API lorsque le comportement attendu dépasse ce que le nœud expose.

Instance auto-hébergée ou version infogérée : exposition publique, secrets et maintenance

La version infogérée réduit la charge liée au conteneur, à la base de données et aux montées de version. Il reste à gérer les credentials, les workflows, les alertes et les accès.

Une instance auto-hébergée donne davantage de contrôle sur le réseau et le stockage. Elle impose aussi de maintenir l’URL publique, TLS, les sauvegardes, la base, la clé de chiffrement et, le cas échéant, les workers. Retell bloque les URL localhost, les plages d’adresses privées et les adresses de métadonnées cloud pour les Custom Functions.

Le choix se tranche donc sur la capacité d’exploitation réelle. Une équipe incapable de surveiller et de mettre à jour l’infrastructure ne gagne rien à l’héberger elle-même.

Workflow unique ou workflows découpés : isoler le temps réel du traitement post-appel

Gardez dans le chemin synchrone uniquement ce qui sert immédiatement à la conversation : réception, vérification, lecture ou écriture métier indispensable, puis réponse à Retell AI.

Placez l’analyse, les notifications, l’alimentation d’un rapport et les traitements lourds dans des workflows séparés. Cette découpe réduit le nombre de causes capables de bloquer une réponse en direct. Elle facilite aussi la reprise d’un traitement post-appel sans rejouer la conversation.

Traitement synchrone ou file d’attente : arbitrer selon le délai acceptable

Une Custom Function attend une réponse utilisable pendant l’appel. Son chemin critique doit donc rester synchrone et court.

Une file d’attente convient aux opérations différées qui supportent l’attente. Chaque message doit porter le call_id, l’identifiant de corrélation et une clé d’idempotence. Sur une instance n8n exploitée en mode queue, tous les workers doivent partager la même clé de chiffrement pour lire les credentials.

Surveillez la profondeur de la file, l’âge du plus ancien élément, les échecs des workers et les messages traités plusieurs fois. Si un worker tombe, le message reste à reprendre selon le mécanisme retenu, sans reproduire une écriture déjà validée.

Règle déterministe ou modèle de langage : réserver le modèle aux données réellement ambiguës

Le modèle de langage choisit et renseigne les arguments décrits dans une Custom Function. n8n doit néanmoins revalider ces valeurs avant d’agir.

Une règle déterministe convient aux formats, plages, autorisations et états métier. Utilisez le modèle pour interpréter une formulation ambiguë, puis faites confirmer toute action sensible par des règles ou une personne. Cette séparation rend la recette reproductible et les erreurs explicables.

Étape 1 : Préparer Retell AI et l’instance n8n

Vérifier les comptes, l’agent, le numéro et l’accès réseau

Il faut une instance n8n Cloud ou auto-hébergée, un compte Retell AI et une clé API. Le brief documentaire disponible n’établit aucune version minimale de n8n. Vérifiez donc la compatibilité du paquet dans un environnement de préproduction avant toute montée de version.

Pour un appel sortant, préparez aussi un agent, puis un numéro géré par Retell ou importé. Les restrictions internationales peuvent varier selon le numéro et le fournisseur téléphonique.

Prévoir une URL publique pour les fonctions appelées pendant la conversation

Une Custom Function doit viser une URL valide et publiquement accessible. L’URL du webhook n8n doit recevoir la méthode choisie, généralement POST, et répondre à Retell AI.

Avant l’ouverture réseau, définissez TLS, la vérification de signature, la taille maximale acceptée, le délai d’exécution et la réponse en cas d’indisponibilité. Une simple URL publique sans contrôle exposerait directement une action métier.

Séparer les environnements de recette et de production

Utilisez des agents, URLs, credentials et données distincts lorsque l’organisation le permet. L’URL de test du nœud Webhook n8n ne fonctionne que lorsque le workflow écoute un événement de test ou s’exécute manuellement. L’URL de production exige un workflow publié.

La supervision doit distinguer les deux environnements. Une alerte de recette sert au diagnostic. Une alerte de production doit désigner la personne qui tranche entre reprise, traitement manuel et suspension du workflow.

Étape 2 : Installer le nœud Retell AI et tester l’authentification

Installer le paquet officiel n8n-nodes-retellai

Dans n8n, ouvrez Settings, puis Community Nodes. Cliquez sur Install, saisissez n8n-nodes-retellai, lisez l’avertissement de sécurité et confirmez l’installation.

Le paquet observé dans la source fournie portait la version 0.2.5. Contrôlez la version réellement disponible, puis consignez-la dans la recette et lors de chaque montée de version.

Créer le credential sans exposer le jeton

Dans Retell AI, ouvrez Settings, puis API Keys, et copiez la clé concernée. Dans n8n, ouvrez Credentials, créez un credential RetellAI, collez la clé et enregistrez-le.

Ne placez la clé ni dans un nœud Code, ni dans une expression, ni dans un export de workflow. n8n chiffre les credentials enregistrés dans sa base avec une clé générée au premier lancement. Sur une instance auto-hébergée, sauvegardez et maîtrisez cette clé, sans quoi une restauration de la base peut laisser les secrets illisibles.

Interpréter la réussite ou l’échec du test d’authentification

Le credential officiel ajoute la clé dans l’en-tête Authorization: Bearer …, puis appelle GET https://api.retellai.com/get-concurrency. Une réponse positive montre que Retell accepte la clé sur ce point d’accès. Elle ne garantit pas les autorisations ni le comportement de toutes les opérations futures.

Si le test renvoie Invalid API Key, recopiez la clé depuis le tableau de bord et retirez tout espace parasite. Si l’erreur persiste, journalisez le code HTTP et le contexte technique sans inscrire le secret dans les journaux.

Préparer la supervision des erreurs d’installation et de credential

Alertez sur l’échec du test, l’impossibilité de charger le nœud après une montée de version et les réponses d’authentification refusées en production. Associez l’alerte à la version du paquet et de n8n.

En cas d’échec, suspendez les déclenchements qui écriraient dans un système métier. Une reprise contrôlée commence après validation du credential et sur une exécution de recette, puis se poursuit sur les éléments restés en attente.

Étape 3 : Faire exécuter une Custom Function Retell par n8n

Déclarer un nom unique, une méthode, une URL publique et un schéma de type object

Dans l’agent Retell AI, créez une Custom Function. Donnez-lui un nom unique composé de lettres et de tirets bas, par exemple get_order_status, puis rédigez une description qui indique quand l’appeler.

Choisissez GET, POST, PUT, PATCH ou DELETE et saisissez l’URL publique du webhook. Pour POST, PUT et PATCH, définissez le corps avec le formulaire ou un schéma JSON dont le niveau supérieur porte "type": "object". Précisez les propriétés, leurs types et les champs obligatoires. Un champ décrit sera renseigné par le modèle de langage, tandis qu’une valeur const sera appliquée directement.

Créer un webhook POST n8n et choisir entre le corps name, call, args et le mode args only

Ajoutez un nœud Webhook réglé sur POST. Dans sa forme par défaut, Retell transmet :

{
  "name": "get_order_status",
  "call": {
    "call_id": "identifiant_fourni_par_retell"
  },
  "args": {
    "reference": "valeur_produite_pendant_le_test"
  }
}

L’objet call apporte le contexte disponible, dont l’identifiant et la transcription accumulée au moment de la requête. Si vous activez Payload: args only, les arguments arrivent directement à la racine. Le workflow doit traiter une seule forme par fonction et vérifier la signature sur ce même corps brut.

Revalider la présence, le type, la plage et le format des paramètres reçus

Ajoutez un nœud If ou une logique équivalente. Contrôlez la présence des champs obligatoires, leur type, leurs bornes et, lorsque nécessaire, leur expression régulière. Vérifiez aussi que le nom de fonction reçu correspond au chemin attendu.

Le schéma Retell guide la production des arguments. Il ne constitue pas une validation métier. Une valeur correcte sur le plan JSON peut viser une ressource inexistante ou une action interdite.

Exécuter l’action métier avec un nœud dédié ou un nœud Code

La branche valide appelle le service métier au moyen de son nœud documenté ou de son API. Employez un nœud Code uniquement lorsque les nœuds disponibles ne couvrent pas la transformation requise.

Conservez le call_id, l’identifiant de corrélation, l’opération demandée et le résultat. Écartez les données inutiles des journaux. Si le service métier ne répond pas, coupez l’action et dirigez le workflow vers une réponse d’erreur maîtrisée.

Renvoyer un objet JSON en 2xx ou une erreur non-2xx explicite

Configurez le nœud Webhook pour répondre avec Respond to Webhook. Placez un nœud de réponse sur chaque branche.

Une réussite doit renvoyer un code compris entre 200 et 299 et, si Retell doit remplir des variables de réponse, un objet JSON :

{
  "status": "found",
  "reference": "valeur_validee"
}

La branche invalide renvoie un code non-2xx et un objet d’erreur stable, sans détail interne ni secret. Retell convertit les corps de réponse en chaîne pour le modèle, mais seul un objet JSON peut alimenter ses variables de réponse.

Tester avec l’URL temporaire puis publier l’URL de production

Dans n8n, lancez Listen for Test Event ou exécutez le workflow, puis placez l’URL de test dans la Custom Function. Déclenchez ensuite la fonction depuis un appel ou un chat de test Retell. Inspectez le corps reçu, le chemin suivi et la réponse.

Après la recette, publiez le workflow et remplacez l’URL temporaire par l’URL de production. Rejouez le parcours complet. Surveillez la première exécution de production et vérifiez que l’agent exploite réellement la réponse.

Surveiller les délais, les formats invalides et les chemins sans réponse

Créez des alertes sur les délais dépassés, les codes non-2xx, les schémas refusés et les réponses incompatibles. Contrôlez aussi les chemins qui n’atteignent pas Respond to Webhook.

Selon la documentation n8n, un workflow qui se termine normalement sans exécuter ce nœud renvoie un message standard avec HTTP 200. Ce succès technique peut cacher l’absence de résultat métier. Une erreur avant la première réponse renvoie HTTP 500 et peut déclencher un nouvel essai côté Retell.

Étape 4 : Déclencher un appel Retell AI depuis un workflow n8n

Préparer l’agent sortant et les numéros au format E.164

L’opération exige une clé API, un agent prêt pour les appels sortants et un numéro Retell ou importé. Fournissez from_number et to_number au format E.164.

L’agent associé au numéro sortant sera utilisé par défaut. override_agent_id peut le remplacer. Vérifiez cette association en recette afin d’éviter qu’un appel parte avec un agent ou une consigne inadaptés.

Lancer Create Phone Call et conserver le call_id

Appelez l’opération Create Phone Call depuis le nœud ou directement depuis l’API. Une création acceptée renvoie notamment un call_id et le statut initial registered.

Enregistrez ces valeurs avant de lancer une étape dépendante. Un appel enregistré par l’API n’est pas encore un appel abouti. La supervision doit suivre les transitions ultérieures et signaler un statut bloqué ou un échec.

Associer un identifiant de corrélation à l’exécution n8n

Créez l’identifiant de corrélation avant l’appel, puis conservez-le avec le call_id, la ressource métier et l’exécution n8n. Il relie ensuite la création, les événements, Get Call et l’analyse post-appel.

N’utilisez pas le numéro de téléphone comme identifiant technique principal. Il peut réapparaître dans plusieurs appels et augmente l’exposition de données personnelles dans les journaux.

Gérer un échec de création sans déclencher de doublon

Si Create Phone Call renvoie une erreur réseau ou HTTP, ne concluez pas immédiatement que Retell n’a rien créé. Une coupure peut survenir après la prise en compte de la requête.

Avant tout nouvel essai, recherchez l’état à partir des identifiants disponibles ou placez la demande en examen. Une clé d’idempotence métier et une table de correspondance limitent le risque de rappeler deux fois la même personne. L’alerte doit contenir l’identifiant de corrélation, le code reçu et l’état de la reprise.

Étape 5 : Récupérer et exploiter les résultats de l’appel

Choisir entre interrogation de Get Call et webhook call_analyzed

Get Call convient lorsqu’un workflow doit consulter explicitement un appel connu. Le webhook call_analyzed convient à un traitement déclenché après l’analyse.

Le webhook évite les interrogations répétées, mais réclame vérification de signature et déduplication. Get Call donne davantage de contrôle sur le moment de lecture, au prix d’une planification et d’un arrêt explicite des consultations.

Récupérer le statut, la durée, la transcription et les journaux de fonctions

Avec le call_id, Get Call peut restituer le statut, la durée, la transcription complète, l’enregistrement, les métriques de latence et les journaux des fonctions. Ne copiez dans n8n que les champs nécessaires au traitement.

Journalisez la présence ou l’absence de chaque donnée attendue. Une transcription absente ne doit pas devenir une chaîne vide interprétée comme une conversation sans contenu.

Attendre la fin de l’appel avant les données différées

Plusieurs champs, dont la transcription complète et l’enregistrement, n’arrivent qu’après la fin de l’appel. Les champs personnalisés issus de l’analyse post-appel peuvent rester vides si l’appel n’a pas été connecté ou si aucune conversation n’a eu lieu.

Le workflow doit donc vérifier l’état de l’appel avant d’écrire un compte rendu définitif. S’il manque une donnée différée, il attend, reprogramme une lecture bornée ou route le dossier vers un contrôle humain.

Transmettre les résultats aux services métier sans supposer leur compatibilité

Un CRM, un agenda, une notification ou un rapport peut recevoir les données si son nœud ou son API documente l’opération et l’authentification nécessaires. La présence d’un service dans n8n ne garantit ni le champ voulu ni son format.

Mappez chaque donnée, sa source, sa destination et sa règle de mise à jour. Surveillez les refus d’authentification, les limites de l’API et les erreurs de validation. En cas d’échec, gardez l’événement source disponible pour une reprise ciblée.

Journaliser les données absentes et reprendre le traitement sans doublon

Enregistrez le call_id, l’identifiant de corrélation, le type d’événement, l’état du traitement et la clé d’idempotence. Si call_analyzed revient ou si une exécution est relancée, contrôlez cette clé avant toute écriture.

Une donnée absente doit produire un état distinct, par exemple « attente », « appel non connecté » ou « contrôle humain ». Cette distinction évite qu’une reprise transforme une absence légitime en erreur permanente.

Sécuriser et superviser l’intégration Retell AI–n8n

Conserver la clé API dans les credentials chiffrés de n8n

Stockez la clé Retell dans le credential prévu. Limitez l’accès aux personnes et workflows qui en ont besoin, puis définissez une procédure de remplacement.

Sur une instance auto-hébergée, sauvegardez la clé de chiffrement n8n séparément de la base et protégez-la comme un secret d’infrastructure. Testez la restauration en préproduction. Une sauvegarde non restaurable ne couvre aucun incident.

Vérifier X-Retell-Signature avant tout traitement métier

Retell documente la vérification de X-Retell-Signature avec la clé API portant le badge webhook. Le calcul doit utiliser le corps brut exact. Une re-sérialisation JSON peut invalider la signature.

Rejetez la requête avant toute lecture ou écriture métier si la vérification échoue. Retell documente aussi l’adresse IP 100.20.5.228 pour une liste d’autorisation, mais ce contrôle réseau complète la signature et ne la remplace pas. La procédure complète figure dans la documentation Retell sur la sécurisation des webhooks.

Rendre les actions idempotentes avant d’activer les retries Retell

Les nouveaux essais d’une Custom Function peuvent suivre une erreur réseau, un délai dépassé ou une réponse 4xx ou 5xx. Chaque essai répète la requête.

Retell accepte un max_retry compris entre 0 et 5, avec 0 par défaut d’après la documentation fournie. Activez une valeur supérieure uniquement si le point d’entrée supporte les doublons. La clé d’idempotence peut combiner le call_id, le nom de la fonction et un identifiant stable de l’action.

Alerter sur les délais, codes HTTP, doublons et échecs d’appel

Une alerte utile appelle une décision. Associez donc chaque événement à une action :

Événement	Contrôle	Action attendue
Délai dépassé	Durée du chemin synchrone	Basculer vers la réponse de repli et examiner le service lent
HTTP 4xx	Corps et validation	Corriger l’entrée ou l’authentification avant reprise
HTTP 5xx	État de l’action métier	Vérifier si l’écriture a eu lieu avant de relancer
Doublon	Clé d’idempotence	Ignorer l’écriture répétée et conserver la trace
Appel non abouti	Statut Retell	Appliquer la règle métier de rappel ou de clôture
Signature invalide	Corps brut et en-tête	Rejeter la requête et examiner l’origine

Inspecter et relancer une exécution échouée avec discernement

n8n sait filtrer les exécutions selon leur état, puis relancer une exécution échouée avec le workflow actuellement enregistré ou sa version d’origine. L’accès à certaines données d’exécution personnalisées dépend du plan.

Avant la relance, vérifiez les effets déjà produits. Rejouer un envoi de notification reste souvent acceptable. Rejouer une création de rendez-vous, un débit ou un appel sortant exige un contrôle d’idempotence.

Superviser la file d’attente et partager la même clé de chiffrement entre workers

Si l’instance auto-hébergée utilise des workers, distribuez la même clé de chiffrement à chacun. Sans elle, un worker peut recevoir une exécution sans parvenir à déchiffrer son credential.

Surveillez aussi les workers indisponibles, les éléments anciens et les échecs répétés. Une procédure de reprise doit préciser qui remet un élément en file, comment il vérifie les effets précédents et quand il arrête les tentatives.

Recetter les cas d’échec propres à Retell AI et n8n

Tester le corps enveloppé et le mode args only séparément

Envoyez d’abord un corps contenant name, call et args. Vérifiez que le workflow lit les arguments sous args. Activez ensuite Payload: args only dans un test distinct et confirmez la lecture à la racine.

Chaque cas doit laisser une exécution identifiable. Une forme inattendue déclenche une réponse non-2xx, une alerte de format et aucune action métier.

Vérifier les réponses JSON destinées aux variables Retell

Testez un objet JSON valide, une chaîne et un corps vide. Seul l’objet doit alimenter les variables de réponse Retell.

Vérifiez les noms et types attendus. Si l’objet ne respecte pas le contrat, le workflow doit journaliser l’écart et empêcher que l’agent présente une donnée erronée comme un résultat confirmé.

Contrôler la limite par défaut de 15 000 caractères

Le résultat d’une Custom Function est limité par défaut à 15 000 caractères dans la documentation des Custom Functions de Retell. Testez une réponse proche du plafond et une réponse qui le dépasse.

Réduisez le corps au résultat utile à la conversation. Les détails volumineux suivent un traitement post-appel ou restent dans le système source. L’alerte doit identifier la fonction et la taille produite, sans recopier inutilement les données.

Détecter un HTTP 200 trompeur sans résultat métier

Créez volontairement une branche qui termine sans atteindre Respond to Webhook. n8n peut alors renvoyer son message standard avec HTTP 200.

La recette doit vérifier le contenu attendu, et non le seul code. Si le champ métier manque, marquez l’exécution en échec fonctionnel, alertez et empêchez l’agent d’interpréter le 200 comme une réponse exploitable.

Tester un HTTP 500, un délai dépassé et une requête répétée

Provoquez une erreur avant Respond to Webhook, puis une exécution plus lente que le délai admis. Rejouez enfin la même requête avec les mêmes identifiants.

Attendez un HTTP 500 dans le premier cas, une alerte de délai dans le second et une absence de seconde écriture dans le troisième. Conservez l’état de chaque exécution et la décision de reprise.

Valider la reprise sans répéter l’action métier

Après chaque échec simulé, inspectez le système cible avant de relancer. La reprise doit sauter une action déjà commise, reprendre une étape différée ou demander une validation humaine lorsque l’état reste incertain.

La documentation n8n sur les exécutions décrit le filtrage et la relance. Votre procédure doit ajouter le contrôle métier que l’outil ne peut pas déduire seul.

Encadrer les enregistrements, transcriptions et données d’appel

Déterminer les obligations applicables avant la mise en production

Le territoire, le type d’appel, sa finalité et les personnes concernées déterminent les règles applicables. Faites valider les obligations relatives à la voix artificielle, au démarchage, au consentement, à l’enregistrement et à la conservation.

Les conditions Retell placent ces responsabilités chez le client. Elles évoquent notamment l’information sur l’usage d’une voix d’IA et, selon le droit applicable, la notification ou le consentement préalable à l’enregistrement. Elles ne remplacent pas une analyse juridique locale.

Informer les personnes appelées et recueillir le consentement requis

Insérez l’information exigée au moment approprié dans le parcours d’appel. Si un consentement doit précéder l’enregistrement ou une action, le workflow doit conserver l’état de ce consentement et bloquer la branche concernée en cas de refus.

Recettez les interruptions, silences et réponses ambiguës. Le modèle de langage ne doit pas transformer une absence de refus en consentement lorsque la règle applicable demande un accord explicite.

Choisir une durée de conservation et un mode de stockage par agent

Le guide Retell consulté en 2026 indique une conservation indéfinie par défaut et des réglages par agent. Les options documentées sont :

Réglage	Valeurs documentées
Durée de conservation	1, 3, 7, 30, 60, 90, 180, 365 ou 730 jours, ou conservation permanente
Mode Everything	Toutes les données concernées
Mode Everything except PII	Retell conserve les données après retrait des informations personnelles identifiables
Mode Basic Attributes Only	Attributs de base uniquement

Ces valeurs décrivent une configuration technique. Elles ne fixent aucune durée légale. Choisissez la durée et le mode après avoir défini la finalité, les obligations applicables et les besoins de preuve.

Limiter les données transmises à n8n et aux services en aval

Ne transférez que les champs nécessaires. Un CRM peut recevoir un statut et une synthèse sans recevoir l’enregistrement complet. Un agenda peut recevoir un créneau sans conserver toute la transcription.

Appliquez cette réduction dans le mapping des nœuds, les journaux, les alertes et les exports d’exécution. Si une étape échoue, l’alerte doit identifier le dossier sans reproduire son contenu sensible.

Surveiller les accès et l’effacement selon les règles retenues

Journalisez les accès administratifs, limitez les droits sur les credentials et contrôlez les exports. Une demande d’effacement doit couvrir Retell, n8n et chaque service en aval qui a reçu les données.

Testez cette chaîne. Si un système ne sait pas effacer ou retrouver une donnée à partir de l’identifiant de corrélation, la politique de conservation reste inapplicable en pratique.

Ce qu’il faut retenir

Automatisez lorsque le parcours d’appel reste stable, que les données sources sont maîtrisées, que les décisions peuvent être encadrées et qu’une personne assume les alertes. Une URL publique sécurisée, une signature vérifiée et une reprise sans doublon forment des prérequis de production.

Choisissez le nœud ou l’API pour déclencher et consulter les appels, le webhook pour agir pendant la conversation ou recevoir un événement, puis séparez le temps réel des traitements différés. L’auto-hébergement convient à une organisation capable d’exploiter l’infrastructure. La version infogérée réduit cette charge sans supprimer la supervision du workflow.

Avant d’ouvrir n8n, formalisez un appel représentatif de bout en bout. Écrivez les données d’entrée, les décisions, les erreurs acceptables, le responsable de chaque reprise et les critères de recette. Décidez enfin qui intervient lorsque Retell AI ou le workflow ne peut pas terminer l’action attendue.