Configurer un connecteur de données signifie généralement lire la documentation API et remplir chaque champ manuellement. Avec Operator, vous décrivez ce que Fin doit rechercher ou mettre à jour, et Operator rédige un nouveau connecteur ou répare un connecteur défaillant. Utilisez cet article pour apprendre ce qu’Operator peut configurer, comment revoir et tester ses propositions, et les limites à connaître.

Chaque modification arrive sous forme de proposition. Vous la révisez, approuvez chaque appel de test, et choisissez de la publier ou de la sauvegarder comme brouillon. Operator ne peut pas modifier un connecteur ni appeler une API seul.

Note : Operator est inclus avec l’extension Pro. Pour discuter avec Operator, vous devez avoir la permission Can access Fin Operator. Pour appliquer une modification de connecteur, vous avez aussi besoin des permissions Fin AI Agent & Automation et Can access Developer Hub.

Si vous débutez avec les connecteurs de données, commencez par Comment configurer des connecteurs de données.

Comment créer ou réparer un connecteur de données avec Operator

Tout le processus se déroule dans un chat Operator, de la première demande au connecteur publié.

Étape 1 : Demandez à Operator

Dans un chat Operator, décrivez ce que Fin doit faire. Par exemple :

« Créez un connecteur qui recherche une commande Shopify par son numéro. »
« Fin dit qu’il ne trouve pas la commande. Pouvez-vous réparer le connecteur Get Order ? »

Étape 2 : Operator enquête

Avant de proposer quoi que ce soit, Operator peut rechercher des informations dans votre espace de travail :

Recherchez vos connecteurs et lisez la configuration complète de chacun.
Lisez la réponse de test enregistrée ou la réponse simulée d’un connecteur.
Voyez quels workflows, procédures et macros utilisent un connecteur.
Vérifiez les taux de réussite récents et l’historique d’exécution. Il voit le statut et le temps, pas ce qui a été envoyé ou reçu.
Listez les attributs qu’il peut utiliser dans la requête ou comme cibles de mappage.
Listez vos jetons d’authentification par nom et type. Il ne voit jamais le secret.

Étape 3 : Examinez la proposition

La proposition apparaît dans le chat sous forme de carte Data connector.

L’en-tête affiche le nom du connecteur et un badge New, Live, Draft ou Paused. Un renommage montre l’ancien nom barré.
API affiche la méthode, l’URL, les données d’entrée, les en-têtes, la charge utile, le test et les jetons d’authentification.
Data affiche les champs de réponse, le code Python et les mappages d’objets.
Fin affiche l’invite que Fin lit et le public cible.
Security affiche le paramètre d’authentification client.
Pour une modification, la carte montre les changements par rapport à la version en ligne. Les sections inchangées commencent repliées, et chaque section indique le nombre de lignes ajoutées et supprimées.
Les jetons d’authentification sont affichés uniquement par leur nom.

Étape 4 : Approuvez le test

Avant qu’un test ne soit lancé, Operator affiche une carte intitulée Test « nom du connecteur » avec les valeurs qu’il enverra.

Vérifiez les valeurs. Rien n’est envoyé tant que vous n’avez pas cliqué sur Run test. Cancel l’arrête.
Le test appelle la vraie API. Le résultat s’affiche par exemple « Test réussi (HTTP 200) » ou « Test échoué (HTTP 401) ».
Operator lit la réponse et l’utilise pour configurer les champs de réponse.

Operator peut aussi poser une question test à Fin dans une conversation de prévisualisation, comme le ferait un client. Cela montre si Fin sélectionne le connecteur et comment il utilise la réponse. En prévisualisation, Fin répond comme si les modifications en attente du connecteur étaient déjà appliquées, et il utilise la réponse de test enregistrée ou simulée plutôt que d’appeler l’API.

Important : Les tests envoient de vraies requêtes au système connecté. Si un connecteur crée, met à jour ou supprime des données, le tester effectue cette modification. Utilisez des enregistrements de test. Operator demande votre approbation avant chaque test.

Étape 5 : Appliquez la modification

Vous choisissez comment la modification est appliquée :

Sur un connecteur en ligne, le bouton principal est Publish. Save as draft (ou Update draft, si un brouillon existe) se trouve dans le menu.
Sur un connecteur nouveau, brouillon ou en pause, le bouton principal est Save as draft (ou Update draft). Publish est dans le menu.
Publish demande d’abord « Prêt à publier ? ». Il reste désactivé tant que le test d’Operator n’a pas réussi, sauf si le connecteur utilise une réponse simulée. Une modification qui ne touche pas la requête (URL, méthode, en-têtes, corps, entrées et jetons d’authentification) conserve le test réussi précédent du connecteur.
Une suppression affiche un bouton rouge Delete et un avertissement indiquant que l’action est irréversible.
L’icône de la corbeille (Discard change) supprime la proposition.
Apply all applique toutes les modifications du chat. Un nouveau connecteur devient un brouillon, et une modification conserve son état en ligne ou brouillon actuel.

Si quelqu’un a modifié le connecteur pendant que la proposition était en attente, la carte indique « Cette modification est basée sur une version obsolète » et l’application demande « Appliquer malgré les modifications plus récentes ? ». Les modifications plus récentes sont écrasées uniquement si vous cliquez sur Apply anyway.

Étape 6 : Après application

Un message « Modifications appliquées avec succès » s’affiche, et le journal du chat indique « Vous avez appliqué 1 modification » avec le connecteur marqué Published ou Draft. Cliquez sur le nom du connecteur pour ouvrir sa page de paramètres. Chaque modification appliquée apparaît aussi dans le journal d’activité des coéquipiers sous « Proposition Operator appliquée ».

Une modification publiée fonctionne comme tout connecteur créé manuellement, et Fin commence à l’utiliser immédiatement dans les conversations. Un brouillon n’a aucun effet sur les conversations tant qu’il n’est pas publié. Les clients ne voient jamais Operator ni ses propositions.

Ce qu’Operator peut configurer

Nom et description — Les coéquipiers voient la description dans les paramètres du connecteur.
La requête — URL, méthode, en-têtes et corps. L’URL doit être HTTPS.
Données d’entrée — Les valeurs que Fin collecte auprès du client, comme un numéro de commande. Chaque entrée a un nom, un type et une description, est marquée obligatoire ou optionnelle, et peut avoir une valeur par défaut.
Jetons d’authentification — Operator peut attacher ou détacher des jetons existants. Chaque jeton est envoyé comme un en-tête distinct.
Champs de réponse — Construits à partir d’une réponse de test ou simulée. Ils déterminent quels champs Fin voit, leur nom, leur format, et comment les valeurs codées sont traduites en mots. Un bloc de code Python peut aussi remodeler la réponse.
Une réponse simulée — Un exemple de corps de réponse, utilisé pour construire les champs de réponse avant que l’API puisse être testée.
Mappages d’objets — Écrire les valeurs de réponse dans les attributs de conversation, utilisateur ou objet personnalisé.
Comment Fin l’utilise — Si Fin peut choisir le connecteur seul, l’invite que Fin lit pour décider quand l’utiliser, si Fin peut écrire via ce connecteur, et un public construit à partir de segments.
Vérification client — Si Fin appelle le connecteur uniquement pour les clients ayant passé la vérification d’identité.

Astuce : Operator place les attributs Intercom, comme l’email du client, directement dans la requête plutôt que de les ajouter comme données d’entrée. C’est la configuration recommandée. Chaque donnée d’entrée ajoutée par Operator est une valeur que Fin collecte auprès du client.

Limitations connues

Crédits Operator — Les chats Operator utilisent des crédits Operator comme tout autre travail Operator.
Vous appliquez chaque modification — Operator ne peut pas publier, sauvegarder ou supprimer un connecteur lui-même.
Les tests envoient de vraies requêtes — Si un connecteur crée, met à jour ou supprime des données, le tester effectue cette modification dans le système connecté. Utilisez des enregistrements de test.
Jetons — Operator ne peut pas voir les valeurs des jetons d’authentification, ni créer, modifier ou supprimer des jetons. Ajoutez un nouveau jeton dans les paramètres d’authentification, puis demandez à Operator de l’attacher. Gardez les clés API dans les jetons, pas dans l’URL ou le corps, où Operator peut les lire.
L’application remplace les modifications de brouillon non publiées — Operator construit sa modification sur la version en ligne. L’appliquer, que ce soit avec Publish ou Save as draft, remplace toutes les modifications de brouillon faites dans l’éditeur depuis. Publiez ou supprimez d’abord vos propres modifications de brouillon.
Les connecteurs en ligne ne peuvent pas être supprimés — Operator peut supprimer uniquement les connecteurs brouillons ou en pause. Pour supprimer un connecteur en ligne, mettez-le d’abord en pause dans ses paramètres. Operator ne peut pas mettre en pause, reprendre, dupliquer ou archiver des connecteurs, ni revenir à une version antérieure.
Connecteurs MCP — Operator ne peut pas modifier, tester ou supprimer les connecteurs provenant d’un serveur MCP. Gérez-les dans les paramètres du serveur MCP.
Pas de modèles — Operator ne peut pas installer un connecteur à partir d’un modèle.
Types d’entrée — Operator ne peut pas ajouter de valeurs d’entrée statiques, ni les types d’entrée liste et objet.
Versions — Les modifications de connecteur d’Operator s’appliquent directement au connecteur. Elles ne peuvent pas être ajoutées à une Fin Release.
Prévisualisation Fin — Quand Operator pose une question test à Fin, Fin utilise la réponse de test enregistrée ou simulée plutôt que d’appeler l’API. Les suppressions en attente ne sont pas prévisualisées, et une modification sans réponse de test ou simulée n’a rien à retourner.

Si un connecteur échoue dans les conversations après sa publication, consultez Comprendre les erreurs des connecteurs de données.

FAQ

Pourquoi le bouton Publish est-il désactivé ?

Il n’y a pas de test réussi sur la dernière version de la modification. Modifier l’URL, la méthode, les en-têtes, le corps, les entrées ou les jetons d’authentification annule un test précédent. Demandez à Operator de lancer un test, ou utilisez une réponse simulée. Save as draft fonctionne toujours.

Pourquoi un test échoue-t-il avec un 401 alors que le connecteur fonctionne dans les conversations ?

Les tests ne portent pas d’identité d’utilisateur final, donc les connecteurs qui vérifient l’identité du client ne peuvent pas réussir un test. Les jetons de type USER envoient leur valeur de test statique à la place.

Que peut voir Operator dans mon connecteur ?

Operator ne voit jamais les valeurs des jetons d’authentification. Il voit l’URL, le corps et le bloc de code en entier, comme le Developer Hub vous les montre, et seulement les quatre premiers caractères des valeurs d’en-tête. Dans les réponses de test, tout jeton ou identifiant que l’API renvoie est masqué.

Créer et réparer des connecteurs de données avec Operator